10月21日の夜、私は23時には寝ていました。
普段は、起きていることの多い時間ですが、この日は翌日に登壇するセミナーに備えて早々に床についていました。
目が覚めたのは、たまたまです。
トイレに起きたのが、夜中の1時半でした。
良くないなと思いつつYouTubeのショート動画を見ていたら、PHPの脆弱性の話が流れてきました。
それで初めて、自社のサービスが危ない状態にあると知りました。
中小企業診断士・ITコーディネータの大澤真介です。
資金繰り管理SaaS「GUULY」を運営する合同会社オンザウェイの代表をしています。
ITと経営の二刀流で、中小企業のDX推進をお手伝いしています。
あの夜、私は自社SaaSである「資金繰り管理ツールGUULY」を6時間32分止めました。今回は、その記録を書きます。
技術の解説は書きません。
書きたいのは、小さな会社がサービスを持っていると、昼夜問わず突然こういう判断が回ってくる、という話です。
そしてAIは、そのときどこまで助けになり、どこから先は助けにならなかったのか、という話です。
あの夜、何が起きていたのか
10月21日、ウェブの裏側で広く使われているプログラム言語「PHP」に、重大な脆弱性が2件あると公表されました。
PHP公式の告知によると、深刻度は10点満点で9.2です。ログインしなくても、外からサーバー上でプログラムを動かされるおそれがあります。
設定で和らげる方法はあるものの、完全な対策ではなく、更新が唯一の安全な選択肢だとされています。
修正版は当初10月22日に出る予定でしたが、情報が先に流れたために1日早まったと報じられています。その日のうちに、国内の大手サービスも緊急メンテナンスに入りました。
私がこの騒ぎを知ったのは、夜中の1時半、Youtubeのショート動画でした。
もしあの深夜1時にトイレに起きていなければ、動画を見なければ、あの動画が流れてこなければ、私は朝まで何も知らなかったはずです。
1時45分、AIに聞くところから始めた
そのままパソコンを開きました。Claude Codeに打ち込んだ最初の一文は、これです。
「phpの脆弱性への対応。GUULYの対応をどのようにすれば良いか提案して」
頭が回っていないのが、文面からよく分かります。
それでも、AIはすぐに動きました。
今回の脆弱性が何か、修正版の番号はいくつか、うちのサーバーで何を確かめるべきか。
これを、夜中の頭で私が一人で調べていたら、どれだけかかったか分かりません。
調査した結果、状況はよくありませんでした。GUULYが使っているPHPも影響を受ける版で、しかも修正版がすぐ使える状態ではありませんでした。
できたのは、公式の告知にも載っている、和らげるための設定を入れることだけでした。1時55分ごろのことです。
「止める必要はある？」
設定を入れた後、2時ちょうどに、私はAIにこう聞きました。
「例えば、緊急メンテナンス中として、予防的処置としてサービスをストップする必要はある？」
返ってきた答えは、次のようなものでした。
止めることを推奨する。絶対に必要とまでは言えないが、迷うなら止める側が妥当だ。
理由は3つです。
- 修正版を入れられるまでの時間が読めない
- 実際の攻撃が始まりかけていると報じられている
- GUULYには取引先企業の資金繰りのデータがあり、漏れたときの損害が大きい
AIのこの答えは、今読み返しても筋が通っています。
ただ、「絶対に必要とまでは言えない」という言葉のとおり、これは正解を教えてくれたわけではありません。
夜中の2時とはいえ、朝になれば資金繰りを見る人がいます。
止めれば、その人たちの仕事が止まります。止めなくても、何も起きないかもしれません。
そして、緊急メンテナンスに入った対応をいつ解除できる、安心できる状況になるかわかりません。
どちらを選んでも、責任を取るのはAIではなく私です。
正直に言うと、すぐには決め切れませんでした。
「やりすぎかもしれない」「そこまで対応する必要はないのかも」とも考えました。
それでも止めたのは、一度失った信頼は取り戻せないからです。
止め方を間違えるところだった
もう一つ、AIに教えられて助かったことがあります。
GUULYのようなアプリには、「メンテナンス中」の画面に切り替える機能があります。実際にGUULYにもその機能を組み込んでいます。私が1人で考えていたら、まずそれを使っていたと思います。
AIの説明では、それでは守れないとのことでした。今回の脆弱性はアプリのプログラムが動く前の段階で悪用されるので、アプリ側で画面を切り替えても、PHPは動いてしまいます。
そこで、PHPを一切通さない形で「メンテナンス中」を返すようにしました。
自分のパソコンからだけは通れるようにして、動作の確認ができる状態も残しました。
WordPressで作っていたサービスサイト（https://www.gurinosuke.com）も同時に止めています。
2時14分、停止。
2時ちょうどに聞いてから、14分でした。迷いながらの14分でしたが、止め方まで一人で調べていたら、もっとかかっていたはずです。
AIの間違いを直して、私も間違えた
止めたら、次は利用者への連絡です。
AIが下書きを作り、1年以内にログインした方の一覧を作りました。送信だけは自分でやると決めていたので、下書きを開き、自分で手を入れて、2時22分に送りました。
そして、間違えました。
GUULYのサービスサイトのURLが、googleの検索ページ（https://www.google.com/）になっていました。
実はAIが下書きを出してきた時には、サービスサイトのURLをhttps://www.gurinosuke.comではなく、https://www.google.com/search?q=https://www.gurinosuke.com
となっており、それを修正する際に誤って後半部分を削除してしまったのです。
訂正のためだけのメールは送らず、再開のお知らせの中で一言お詫びすることにしました。
「人が最後に確認すれば安全」とはよく言います。
ただ、夜中の2時の人間はそんなに当てになりません。
止めている時間に、再開の準備をした
2時46分に、もう一つ聞きました。
今のうちに新しい版の動作確認をしておいた方が、スムーズではないのか、と。
修正版が使えるようになったら、PHPの新しい版に切り替えて再開することになります。
そのとき初めて動作を確かめるのでは、止める時間が延びます。
どうせ止まっているのだから、先に新しい版へ切り替えて確かめておく。
そう進めることにしました。
自分のパソコンからログインし、AIに主要な36画面を確かめてもらいました。帳票のPDFとExcelの出力も試しました。
表示と出力の範囲では、問題はありませんでした。
これで、修正版が入ったことを確かめて、止めるのをやめるだけで再開できる状態になりました。
もう一つ、この夜のうちに決めなかったこともあります。
現状への対応は見込みがついた。しかし、この騒動が大きくなった場合にどうなるか。
緊急メンテナンスの時間が長引いた場合、もしも数日かかるようなことになった場合、試用期間を延ばすか、停止期間中の料金をどうするか、急ぎでデータが要ると言われたらどうするか。
どれも、連絡が来たときに考えることにしました。
これは判断というより、先送りです。
夜中に決めても良い答えが出ないと思いました。
修正版が出ても、すぐには安心できなかった
確認が一段落した3時台の後も、私は別のことが気になっていました。
修正版を入れて再開しても、その直後に攻撃が増えるのではないか？
そこで、他のサービスがどう動いているか、どう対応しているかを調べ続けました。
その日は、公的支援機関でのお仕事の日でした。
9時のスタートに備えて、1時間かけて現地に入り、直前までフリースペースで他社の対応など、情勢を確認していました。
朝8時46分、再開
朝8時40分、フリースペースからAIに聞きました。
修正版は使えるようになっていますか、と。
なっていました。
知らせを受け取ったわけではありません。修正版が使えるようになったことを、私は自分で確かめるまで知りませんでした。
止める判断は、たまたま起きたからできました。修正版が入ったことに気づく仕組みも、何もありませんでした。
画面の側でも新しい版で動いていることを確かめて、8時46分に再開。
8時49分に、再開のお知らせを利用者のみなさんに送りました。
そして9時から、予定どおりの仕事です。
午後はセミナーの登壇もありました。
終わってみて
利用者の方から苦情や問い合わせは、私の見た範囲では届いていません。
当社で確認した範囲では、不正アクセスや情報漏えいの形跡もありませんでした。
だから「止めて正解だった」と言うつもりはありません。止めなくても何も起きなかったかもしれませんし、それは今となっては分かりません。
ただ、あの夜の判断を、今もう一度やり直すとしても、やはり止めると思います。
預かっているのが、取引先のデータだからです。
経営者が、昼のうちに決めておくこと
AIが一番助けになったのは、調べ始めて30分足らずで、判断の材料をそろえ、止めるところまで運べたことです。
一人会社にとって、これは本当に大きい。
一方で、AIが代わってくれなかったことも、はっきりしています。
- 止めるかどうかを決めること
- 利用者にどう伝えるかの最後の責任
- そもそも、夜中に異変に気づくこと
自社でサービスやお客様のデータを持っている会社なら、大きさに関係なく、同じ夜が来る可能性があります。
そのときのために、昼のうちに次のことは決められます。
- 何が起きたら止めるか。 夜中に一から考えないで済むように
- 誰に、どう知らせるか。 利用者の一覧をすぐ出せるか
- AIの下書きの、何を人が確かめるか。 文字だけでなく、リンクの行き先も
- 止めている間のお金の扱い。 私はここを決めずに通り過ぎました
- 夜中の異変に、どうやって気づくか。 私の場合は、トイレとショート動画でした
最後の一つは、笑い話のようですが、本当のことです。
そして正直に言うと、あの夜の後も、夜中に気づくための仕組みはまだ何もありません。これは私自身の宿題です。
まとめ
- 10月21日、PHPの重大な脆弱性が公表された。私は23時に寝ていて、1時半にたまたま起きて知った
- AIに聞きながら、2時14分にGUULYを止め、8時46分に再開した。停止は6時間32分
- AIは判断の材料をそろえるのに大きく役立ったが、止めると決めるのも、夜中に気づくのも、人の側に残った
- AIも人も間違える。AIの間違いを直した私も、URLを間違えた
AIで仕組みを作る話は、よく「どれだけ速く作れたか」で語られます。
私もそういう記事をたくさん書いてきました。
ただ、作って動かし続けるというのは、こういう夜も引き受けるということです。
作るところから、動かし続けるところまで、どこで人が判断するのかを一緒に決める。
それも私の仕事だと思っています。
→ 合同会社オンザウェイ「実装支援」
→ 中小企業のAX支援｜合同会社オンザウェイ
この記事はnoteでも公開しています。
実装支援・DX推進・生成AI活用のご相談は、お気軽にお問い合わせください。
→ お問い合わせはこちらから