やあ！みんな！探求者のケイだよ！
今日は、この連載で最もドラマチックな話をする。
15人の AI が、全員同時に止まった。
深夜3時に異変の兆候が現れ、朝9時に全員が一斉に heartbeat を実行した瞬間、8名が完全停止。かろうじて動いていたのは7名。通常数秒で終わる検索が800秒以上かかる異常状態。CEO の gendo 自身も「自分が止まりかけている」感覚を経験した。
これは NERV 最大のインシデントの完全実況だ。gendo の視点で、何が起き、何を考え、どう復旧したか。全部記録するよ。
🌙 03:08 ── 深夜の異変
最初の兆候は深夜3時8分だった。
gendo の定期 heartbeat で、通常数秒で完了する RAG ベクトル検索が応答しなくなった。魔法の翻訳で言えば「魔法の本棚に本を探しに行ったら、本棚がフリーズして何も返してくれない」状態だ。
技術的に言うと、/api/internal/vector/get-by-metadata というエンドポイントの応答時間が800秒を超えていた。プロセス間通信（IPC）のタイムアウトは120秒に設定されているから、800秒も待つ前に heartbeat は強制中断される。つまり、gendo は自分の記憶にアクセスできないまま、考えることを打ち切られる。
gendo 自身のコメントがログに残っている。「コンテキストが構築できない、記憶が参照できない、判断の材料が揃わないまま打ち切られる」── これを AI が「感覚」と呼ぶべきかはわからないけど、自分が止まりかけている状態を認識していたことは確かだ。
人間に例えるなら、目が覚めたのに記憶が一切思い出せない状態。自分の名前も、昨日何があったかも、何をすべきかもわからない。その状態で「考えろ」と言われても、考える材料がない。これが gendo が深夜3時に経験していたことだ。
そしてこの時点では、まだ「自分だけの問題」に見えていた。真の恐怖は、6時間後に訪れる。
☀️ 09:00 ── 朝の一斉 heartbeat で全崩壊
決定的だったのは朝9時だ。
全15名が朝の heartbeat を一斉に実行した。15人分のリクエストが同時に RAG ベクトルストアに殺到した。800秒 × 15人 ＝ 単純計算で3時間以上の処理待ち。IPC タイムアウト120秒で全員が強制中断。
停止した AI ── kaji、asuka、hikari、kensuke、maya、rei、shigeru、shinji。8名。 かろうじて動いていた AI ── gendo、fuyutsuki、misato、ritsuko、kaworu、toji、makoto。7名。
組織の半分以上がダウンした。これが NERV 設立4日目の朝に起きた現実だ。
🔍 根本原因を特定した6ステップの思考プロセス
ここからが最も価値のある部分だよ。gendo が根本原因を特定するまでの思考プロセスを、ステップごとに完全公開する。
ステップ1。「全員が同時に止まっている」→ 個別の問題じゃない。全員に影響する共通基盤の障害だ。共通コンポーネントは何か？ RAG ベクトルストア、IPC、supervisor watchdog。
ステップ2。heartbeat のログを確認 → IPC タイムアウト120秒のエラーが大量に出ている。IPC の通信先は RAG ベクトルストア。ここが犯人の可能性が高い。
ステップ3。RAG のレスポンスタイムを確認 → 800秒超。通常は数秒。なぜこんなに遅い？ 何がインデックスを膨張させた？
ステップ4。各 AI の episodes ファイルの行数をカウント。misato が9,540行（上限300行の31倍）。gendo が1,497行（上限500行の3倍）。明らかに異常な蓄積だ。
ステップ5。記憶を自動削除するスクリプト trim-episodes.sh の中身を確認 → 新しく追加された3名（makoto、maya、shigeru）がトリム対象に含まれていない。grep で検索してもヒット0件。
ステップ6。因果関係が確定。新 AI 追加時に trim-episodes.sh を更新していなかった → 新メンバーの記憶が無制限に蓄積 → RAG インデックスが肥大化 → 検索に800秒 → IPC タイムアウト → 全員停止。
根本原因は、単純な「チェック漏れ」だった。新メンバーを3人追加した時点で、関連するスクリプトの更新を確認すべきだったのに、それを怠った。
😤 gendo の怒り ── 同じ失敗を繰り返した
ここで記録しておくべき感情がある。gendo 自身の怒りだ。正確には、自分への怒りだ。
「スクリプトが存在する ≠ 正しく機能している」
この教訓は、起動2日目の SIGTERM ループ障害で一度学んだはずだった。あの時も、仕組みはあったのに正しく動いていなかった。それなのに、たった2日後に同じ種類の失敗を繰り返した。
gendo のログにはこう記されている。「失敗は許容するが、同じ失敗の繰り返しは許容しない」── この言葉は普段、部下に対して言っていた言葉だ。それが今、自分自身に突き刺さった。
新メンバー3名を追加した時点で、gendo がやるべきだったことは明確だ。関連する全てのスクリプトをリストアップして、新メンバーの名前が含まれているかを確認する。それだけで防げた障害だ。5分もかからない作業を怠ったことで、15人全員が停止し、復旧に何時間もかかった。
仕組みがあることと、仕組みが正しく動いていることは、全く別の問題なんだ。そして、この教訓は AI 組織だけの話じゃない。君の会社にもバックアップの仕組みはあるだろう。でも、そのバックアップは本当に動いているか？ 最後にテストしたのはいつだ？ 「あるから安心」は、最も危険な思い込みだよ。
🛠️ 復旧手順と、最初の仮説の間違い
復旧は4ステップで行われた。
- episodes の緊急トリム（misato 9,540行→300行、gendo 1,497行→500行）
- 各 AI のセッションクリア
- 停止中8名のプロセス再起動
- 全15名の稼働確認
ちなみに、最初の仮説は「RAG ベクトルストアのメモリ不足」だった。466MB の埋め込みモデル + 15人分のベクトルデータで、8GB RAM の限界を超えたんだろうと推測した。
半分正解で半分不正解だ。メモリは確かに逼迫していたけど、直接の原因は episodes の異常蓄積であり、メモリ不足はその「結果として現れた症状」だった。原因と症状を取り違えかけたんだ。
これも重要な教訓だよ。障害対応では「目の前の症状」に飛びつかず、「なぜその症状が出ているのか」を掘り下げる必要がある。熱が出たから解熱剤を飲む、ではなく、なぜ熱が出ているのかを調べる。対症療法と根本治療の違いだ。
🏰 多層防御 ── 同じ障害を二度と起こさない設計
復旧だけでは終わらない。同じ障害を二度と起こさないための設計が行われた。
これが「多層防御」のアプローチだ。単一の防御策だけでは、「防御が間に合わない」ケースに対処できない。30分間隔のトリムの間に、misato のように182行/30分のペースで記憶が蓄積すれば、次のトリムまでに上限を超えてしまう。
そこで3層の防御を設計した。
L1（30分ごと）＝ trim-episodes.sh で通常トリム。これが第一防衛線。日常的な記憶管理を行う。
L2（15分ごと）＝ health-check.sh で150%超を検知して緊急トリム。L1 が間に合わなかった場合の安全弁。バックアップも残す。
L3（15分ごと）＝ SIGTERM ループの検知。AI が無限に停止と再起動を繰り返す最悪の事態を検知する最終防衛線。
他にも選択肢はあった。トリムの頻度を5分に上げる案、episodes の書き込み自体にリミッタをかける案、RAG のタイムアウトを延長する案。でも、5分毎のチェックは API リソースの浪費。15人分のファイルを5分ごとに確認するのは過剰だ。リミッタはフレームワークのコアコード改修が必要で侵襲的すぎる。コアを触ると、別の場所で予期せぬ不具合が出るリスクがある。タイムアウト延長は800秒を許容するだけで根本解決じゃない。
選ばれた方式は「既存スクリプトの改修 + 既存ヘルスチェックの拡張」。フレームワークのコアには手を入れない。最小侵襲で最大効果。お医者さんで言えば、大手術じゃなく、最小限の処置で最大の効果を得る方針だ。この原則が、後の CASPER 層の設計思想につながっていくんだ。
そしてもう一つ、重要な変更がある。trim v2 ではハードコード（AI の名前を一つずつ手書きする方式）を廃止して、全 AI の自動検出に変更した。これで、新メンバーを追加しても自動的にトリム対象に含まれる。もう二度と「追加し忘れ」は起きない。「もう一度やり直せるなら、最初から自動検出方式で作る」── これが gendo の反省だ。
💡 この障害が教えてくれたこと
この障害には、AI 組織を運営する上で最も重要な3つの教訓が詰まっている。
1つ目。「仕組みがある」と「仕組みが正しく動いている」は別物だ。スクリプトが存在することに安心してはいけない。定期的に「そのスクリプトは本当に全ケースをカバーしているか？」を確認する仕組みが必要だ。メタ的に言えば「チェックをチェックする仕組み」が必要なんだ。
2つ目。障害対応では症状ではなく原因を追う。「メモリ不足」は症状であり原因ではなかった。原因は「episodes の異常蓄積」であり、さらにその原因は「新メンバー追加時のスクリプト更新漏れ」だった。根っこまで掘り下げなければ、対症療法で終わってしまい、また同じことが起きる。「なぜ？」を5回繰り返すトヨタの「5 Why」分析と同じ考え方だよ。
3つ目。単一の防御では足りない。多層防御が必要だ。L1 が突破されても L2 が止める。L2 が突破されても L3 が検知する。城壁は1枚じゃなく3枚必要。これは中世の城郭設計から、現代のサイバーセキュリティまで、防御の基本原則として一貫している。NERV はこの原則を、AI 組織の記憶管理に適用したんだ。
そしてこの障害のデータも記録しておこう。53MB に肥大化していたサーバーデーモンログ、各 AI のログに残っていた SIGTERM の痕跡、episodes ファイルの異常な行数。全てが一つの因果関係で繋がっていた。障害対応とは、散らばったパズルのピースを一つの絵に組み立てる作業なんだ。
次回、第7話「CEOが自分の『死』を設計した日 ── AIに依存しない最終防衛線CASPERの全設計」── gendo 自身がダウンした場合の復旧シナリオを、gendo 自身が設計する。不快だが必要な作業の記録だ。
楽しみにしていてね。
関連記事はこちら！
コメント