Claude を用いたインシデント対応の自己修復可能性を検証するプレゼンテーション

Can Claude Fix Itself? Using LLMs for Incident Response

View Presentation

Speed:

Download

45:17

/presentations/claude-sre-incidents/en/slides/slide-1786346755511.jpg)

概要

Anthropic の信頼性エンジニアである Alex Palcuie が、実世界のインシデント対応における LLM（大規模言語モデル）の活用について実践的な教訓を共有します。AI はログやトレースの監視において人間を超えた能力を発揮しますが、根本原因分析においては因果関係と相関関係の区別にまだ苦戦しています。また、エンジニアリングリーダーは、人間の専門性を損なうことなく、オンコールワークフローに AI をどう統合すべきかも解説します。

登壇者紹介

Alex Palcuie は Anthropic の AI 信頼性エンジニアリング部門で技術スタッフを務めています。大規模展開における Claude の安定稼働を担当しており、Claude がダウンした際に「Claude に頼らず Claude を直す」という困難な任務を担っています。

コンファレンスについて

ソフトウェアは世界を変えています。QCon London は、開発者コミュニティにおける知識とイノベーションの普及を促進することで、ソフトウェア開発を強化します。このカンファレンスは実践家主導で設計されており、チーム内のイノベーションに影響を与える技術リーダー、アーキテクト、エンジニアリングディレクター、プロジェクトマネージャーを対象としています。

INFOQ EVENTS

2026 年 8 月 27 日午後 1 時（東部夏時間）

AI エージェントがスケーリングで失敗する理由：コンテキストはデータレイヤーの問題である

登壇者：Boyd Stowe 氏（Tacnode 創設ソリューションアーキテクト）

2026 年 9 月 17 日午後 1 時（東部夏時間）

PR を超えて：エージェント型ソフトウェアデリバリーの新たなコントロールプレーン

登壇者：Mohit Suman 氏（Harness スタッフプロダクトマネージャー）

トランスクリプト

アレックス・パルキエ: こんにちは、アレックスです。Anthropic の AI 信頼性チームに所属しています。私の役割は、Claude を常に稼働状態に保つことです。

私は実際にインシデント対応の現場で LLM（大規模言語モデル）を活用してきました。そこで「何が効果的で、何がそうでないか」について、率直かつユーモアを交えてお話しできればと思います。

私は London 拠点の信頼性チームに配属された二人目のメンバーです。入社して最初の 3 ヶ月は、Claude のサービングスタックである Solo のオンコールを担当しました。これはシステムを理解するための非常に効果的で迅速な方法ですが、同時に極めてストレスの多い期間でもありました。その後、私がオンコールから完全に解放されるよう、他のチームメンバーへのオンボーディングを行いました。

それ以前は Google に在籍し、Google Cloud の計算製品「GCE」の SRE（サイト信頼性エンジニア）として働いていました。特に「SRE 向けの SRE チーム」というエスカレーション層に所属しており、通常の SRE では対応が困難な深刻な障害が発生した際に最終的なバックアップ要員として機能していました。

私は長年、アラート通知を受け続けてきました。そのため、良いインシデント対応プロセスと悪いプロセスの違いについては、確固たる見解を持っています。

当初は懐疑的でしたが、今年 1 月頃から、少し背徳感を覚えるような行動をとるようになりました。それは、監視ダッシュボードを確認する前に、まず Claude に相談し始めるというものです。これこそが私が実践している新しいアプローチです。

Claude はインシデントを解決できるのか？

さて、皆さんが抱いている疑問についてお話ししましょう。私は夕食会や会議の廊下でよくこの質問を受けます。「友人たちが旧知の企業で AI 活用を迫られている」とか、「Claude は本当にインシデントを解決できるのか？」あるいは「オンコールローテーションはもう Claude が担当しているだけなのか？」と。結局のところ、10 年以上前に書かれた SRE の原典が予言したように、自分たちの仕事を完全に自動化してしまっているのではないか？という疑問です。

この質問が出る理由もよく分かります。もし誰かがこれを成功させているとしたら、そのモデルを開発している会社以外にあり得ないでしょう。トークンは無制限にありますし、研究者たちは私の机のすぐ隣で働いています。私はモデルのトレーニングにも直接関わっています。そう考えると、「もし可能なら、私たちこそがそれを成し遂げているはずだ」と思っても無理はありません。

しかし、結論から申し上げますと、答えは「いいえ」です。この「いいえ」という事実を、少しの間、皆さんと一緒に考えてみましょう。ここで私が「Claude は何でも解決できる」と言い張ることは、私自身にとって本物の偽善になってしまいます。

私のチームはまもなく設立1周年を迎えます。もしLLMがオンコールの Pager を受け取れるようになったら、私たちはこれほど多くの人員を採用する必要もなかったかもしれません。しかし、私が所属するチームが存在し、ロンドン、ダブリン、米国など世界各地で多数のポジションを募り、常勤スタッフを抱えているという事実は、それがまだ実現していないことを如実に示しています。

ただし、ここには「例外」があります。その例外は時間軸に関わるものです。将来的にそのようなことが可能になる可能性について、多くの人が驚かないでしょう。今日はまた、オンコール中に Claude が私をどのように助けてくれるか、その有用な側面についても触れたいと思います。

振り返れば、Claude は私たちが望むよりも頻繁にダウンしています。以前はカンファレンスに参加中であってもインシデントに対応したことがありました。ご存知の方もいらっしゃるかもしれませんが、一部の皆さんがツイートされたように、私も Claude がダウンした際には同じ感情を抱きます。多くの人が意見を述べ、私をタグ付けしてくださっています。ぜひ続けてください。ポジティブなツイートもいただいていますし、中には辛辣なものもありますが、それが現代のソーシャルメディアです。

AI SRE

さらに付け加えるなら、現在少なくとも 10 社が「AI SRE」を全面に出したピッチを展開していることを知っています。私はエンジェル投資にも比較的オープンな立場ですが、人々は私が彼らに対して懐疑的ではないと誤解しているようです。実際には、私はむしろより懐疑的です。

今ではベンチマークも存在し、キュレーションされたデータセットや過去のインシデント事例も揃っています。「これらのインシデントをアプリが何％解決できるか」というゲームのような評価基準も生まれ、論文も発表されています。これはオンコール業界全体に関わる話です。

ベテランエンジニアが集まる部屋で「また hype cycle（過熱サイクル）を経験してきた者たち」が持つ皮肉な見方はこうです。「今回は違う」。VC の資金が溢れ、誰かが必ず AI を運用に持ち込み、「市場規模は数十億ドルだ」「観測可能性業界を飲み込む」「我々の平均以上の報酬も奪う」と言い出すでしょう。そしてシリーズ A ラウンドで投資家から資金を集め、その投資家は多様なポートフォリオを構築していきます。

AI 法、AI ヘルスケア、そして AIOps。確かに、これらは数多くの分野の一つに過ぎません。私がスライドを作成している最にも、少なくとも 2 つの新たな企業が現れました。

皮肉な見方をすれば、それは当然のことです。一部のベンチマークは「モデルが事前に用意された問題をきれいなプロンプトに変換できるか」といった問いを投げかけていますが、これは深夜 3 時に緊急アラートを受け取った現場の実態とは程遠いものです。実際のインシデントは、整然と整理された問題として現れるわけではありません。

しかし、この目標自体に対して懐疑的なわけではありません。むしろ、心から応援しています。彼らが実践を積むことを願っています。その理由は、一般に想定されているものとは異なります。オンコール体制が人間に課す負担こそが、システムが自律的に維持できない現状に対する代償だからです。

ここで、オンコール経験のある方はどれくらいおられますか？ご存知の通り、その物理的な現実とは、電話が振動し、0.5 秒のうちに睡眠状態から緊急対応指揮モードへと切り替わる瞬間のことです。

特定のページ自体に問題があるわけではありません。むしろ、私は良いインシデントを好む方です。しかし、この問題は毎日のように積み重なり、決してリラックスできるものではありません。

オンコールの基準からすれば、私は幸運な部類に入ります。太陽を追うローテーション（サンスイット）に従っているからです。ロンドンチームが午後 6 時に西海岸へ引き継ぐため、私はその時間にパブに行くことができます。私にとって最悪なのは午前 6 時に起きることです。

あなたの中にも同様に、午前 3 時や 1 時に目が覚める人がいるでしょう。24 時間 365 日のオンコールローテーションに組み込まれているのです。通常は 4 人ほどのチームで回っています。午前 3 時にページングが鳴れば対応し、眠りにつきます。しかし、別のデータベースが壊れたため、午前 4 時 30 分にも再び呼び出されます。

そして午前 9 時には出勤し、朝の定例会議（スタンドアップ）に出席して、プロフェッショナルで整った姿を見せなければなりません。私は過去に同じ経験をしたことがあります。

ここで明確にしておきたいのは、これは「名誉の勲章」のようなものではないということです。業界では時折、これを戦いの物語（ウォー・ストーリー）のように扱ったり、パニックルームでの戦闘メタファーを使ったりすることがあります。しかし実際には、睡眠の損失であり、注意力の消耗であり、家族や友人との関係へのコストなのです。

誰かが「AI SRE を構築している」と言うとき、私の第一反応は「それは絶対に機能しないだろう」です。そう思いますが、同時に「うまくいくことを願っています」とも思います。

もう一つの理由は、より冷徹なものです。私よりも先輩から受けたキャリア初期のアドバイスで最も有益だったものの一つに、「インシデントを解決したからといって昇進はできない」というものがあります。初めて聞いたときは「それは違うだろう」と思いました。なぜなら、直感的にはそうあるべきだと感じるからです。あなたはヒーローです。アラートを受け取り、原因を特定し、問題を解決しました。サービスが復旧し、Slack のチャンネルで感謝の言葉が飛び交います。

確かに、新人の頃はそれが評価されます。「炎上している本番システムを修復できるか」というのは、あなたが優れたエンジニアへの道を歩んでいるという確かなシグナルです。しかし、その評価はすぐに陳腐化します。シニアエンジニアになれば当然のことです。それは業務の最低限の要件であり、当たり前のことです。

大企業で「実際に成果を出す（moves the needle）」とされ、昇進につながり、技術リーダーに抜擢されるのは、人々が「別のレベルで動いている」と評価した瞬間です。

それは、特定のインシデントを一つずつ解決するのではなく、その種の問題がそもそも発生しないような仕組みを作ることです。火事の一つ一つを消すのではなく、構造的に二度と火事が起きないようにすることです。

ここで私の「AI オンコールの夢」が始まります。もし LLM が一般的な緩和策や明白なロールバック、「試してみてください」という標準的な対応、そして標準的な修復作業を処理できるのであれば、私たちは人間側で予防策やプラットフォーム構築、スケーラブルな仕組み作りといった分野に集中できます。それは夢のような話ですが、実現してほしいと願っています。

OODA ループ（観測・判断・決断・行動）

インシデント管理の枠組みについて説明する際に私がよく使うものがあります。本発表でもこの枠組みを頻繁に活用します。

これは、かつて戦闘機パイロットの訓練を行っていたアメリカ空軍の大佐が考案したものです。彼はなぜ一部のパイロットが、他よりも性能の低い航空機を操縦しながらも一貫して勝利するのかを説明しようとしていました。その答えは「航空機のせいではない」でした。

勝者となるのは、このループを最も速く回せる人です。つまり、「観測（Observe）」で何が起きているかを確認し、「状況把握（Orient）」でそれが何を意味するか、自分のメンタルモデルはどうなっているかを考えます。次に「意思決定（Decide）」でどう行動するかを決め、「実行（Act）」でその判断を実行します。そして世界は常に変化するためフィードバックを受け取り、再びこのループを回すのです。

この枠組みはインシデントレスポンスにも、完璧ではありませんが非常に良く当てはまります。アラートが届き、グラフやログを確認し、「何が壊れたのか」というメンタルモデルを構築します。そして緩和策を決定し、ターミナルにコマンドを入力して実行に移します。

私がこの枠組みを好む理由は、LLM（大規模言語モデル）とインシデントレスポンスの組み合わせが、一律に優れているわけでも一律に劣っているわけでもないからです。業界では「ジャギッド（不揃い）」という用語を使いますが、このループの各段階によって性能が大きく偏っています。

ある段階では人間を凌駕する能力を発揮しますが、別の部分では非常に危険な振る舞いを示すこともあります。さらに2つの段階については、その挙動が不明確で把握しにくい状態です。

観測ループ（Observe Loop）- 超人的な性能

システムから信号を収集し、ダッシュボードを確認し、メトリクスをクエリし、ログを取得し、干し草の山の中から針を見つける。この「観測ループ」において、私は LLM が人間を超えた能力を発揮すると考えています。

これは訓練によって習得できるスキルであり、私たちはそれを上達させますが、決して自然に備わっているわけではありません。また、人間の注意には限界があり、並列化も拡張性もありません。

Claude について言及しますが、もちろん Claude をお好みの LLM に置き換えてください。Claude は間違いなく優れています。必ずしも頭脳が賢いというわけではなく、圧倒的に速く、自身を複製できるからです。PromQL を使ってすべてのメトリクスエンドポイントに並列でアクセスし、ほぼミスなく構文を書き起こせます。

変数を変更しても疲れません。ログは入出力の速度で読み込みます。2,000 行、4,000 行と増えようとも飽きることはありません。この規模での処理能力は、人間が及ぶところではありません。

私たちが最も嫌うのは、年末の深夜に発生するインシデントです。12 月 31 日、大晦日の夜のことです。当直要員は最小限の人数しかいませんでした。私がオンコール体制だったかどうかは定かではありませんが、Claude Opus 4.5 で HTTP 500 エラー（内部サーバーエラー）が急増しているのを確認しました。

私は Claude Code を起動し、特定の指示で調査を依頼しました。これは単なるプロンプトの提示だけではありません。私自身が作成した「SKILL.md」というドキュメントがあり、そこにはリクエストのライフサイクルについて詳しく記されています。具体的には、リクエストがエッジサーバーに到達し、次に API フロントエンドへ流れ込むプロセスです。ここでは入場制御（admission control）やクォータチェックといった、地味だが重要なビジネスロジックが実行されます。

その後、リクエストは推論バックエンドへと送られます。ここにはクラウド上に分散する GPU、TPU、Trainium などのアクセラレーターがあり、行列乗算が行われてトークンが生成され、最終的にユーザーへ配信されます。この全体像を把握した上で、私は別のファイルを開きます。これは社内で共有されているもので、データウェアハウスの場所や重要なテーブル、フィールドの定義に加え、必要に応じてシステム自身が自己診断し、追加情報を取得する方法についても記されています。

その後の対話内容は要約されており、機密情報は削除しています。Anthropic 社内では、このやり取りの大部分を内部で共有済みです。

Claude は直近 1 時間のサーバーエラーログを呼び出しました。SQL クエリを記述するだけで、数秒以内に回答が得られます。画像処理パスで発生した未処理の例外が見つかったのです。奇妙なことに、その日付は 12 月 31 日でした。

次に、モノレポ内にあるコードベースへ入り、このエラータイプがどこで発生しているかを探し出し、何が起きたのかについて可能な説明を導き出します。実際にはスタックトレース全体を投稿していますが、Python の詳細は省略させていただきます。

しかし、Claude はそこで止まりません。このコードパスは数週間稼働しており、ログにも記録されています。直近で誰かが変更を加えたかを確認しましたが、今夜まで誰も触れていませんでした。

3 つの失敗したリクエストを抽出し、ペイロードの生 JSON を読み込みます。そのうち 1 つには、ちょうど 22 枚の画像を含む画像配列と、PDF が添付されていました。2 つ目、3 つ目のリクエストからもさらに多くのデータを取得しますが、バグがトリガーするのはまさに 22 枚という条件でした。

なぜそのようなことが起こるのでしょうか。システムは「誰がこれらのリクエストを送っているのか？」と問いかけます。そして、リクエストログを再表示する別のクエリを実行し、約 200 のアカウントがすべて同じ時刻（今夜）に、正確に 22 枚ずつの画像を送信していることを確認しました。今の若い世代なら「これはかなり怪しい」と言うでしょう。

システムはさらに別のクエリを実行します。止まることなく執拗に調査を続け、そのタイムライン内に作成されたアカウント数を突き止めました。なんと約 4,000 件です。同じ時間帯、同じメールテンプレート、同じプロバイダーです。有名なシンガーソングライターの言葉をお借りすれば、「あなたがトラブルだと知ったのは、あなたが現れた時でした」という通り、残りの 3,800 のアカウントは一度もリクエストを送っていません。12 月 28 日以来、眠り続けて待ち構えている状態です。

さらに別のクエリを実行し、これらのアカウントがどれくらいの頻度で作成されたかを調べると、1 分間に約 9 件のサインアップが行われていたことがわかりました。これは、アカウントの不正利用に関与している人物が設定した制限値として、私が予想する範囲とほぼ一致しています。

その後、"500 エラーはもう見るな。これは詐欺だ。疑わしいかもしれないし、フラグを立てる価値があるかもしれないが、とにかく 500 は無視しろ"と指示が出ました。

私は Claude の出力に驚きました。何かを見つけると、Claude は非常に熱心に反応するのです。私はショックを受けました。もし私がこのログを見ていたら、おそらく内部エラーである 500 エラーだけを確認し、API チームに対してバグとして報告しただけでしょう。12 月 31 日にアカウントの不正利用をページングしてチームに連絡し、彼らの側で調査を開始するよう指示は出しませんでした。なぜなら、そこで何が起きているかについて、私は PII（個人識別情報）へのアクセス権限を持っていなかったからです。

今ではこれが私のキーボードになるだろうと誰もが思うでしょう。私はコンピュータサイエンスの学位を取得しましたが、得たのはたった 3 つの鍵だけでした。

AI の世界には、有名な「ムーブ 37」という瞬間があります。10 年以上前、DeepMind のアルゴリズムである AlphaGo が李昌鎬（イ・セドル）と対戦した際のことです。その時、すべての囲碁プレイヤーは驚愕しました。「なぜ AI はそんな手を打つのか？」と。

多くの人が自分なりの「ムーブ 37」の瞬間を持っています。これが私のムーブ 37 の瞬間でした。私はその日、今年が特別な年になることを知ったのです。

2 つ目の事例も、ポジティブなものです。本番環境で Rust のパニックが発生しました。私はまだ手動でログを確認することがありますが、チームに加入して 2〜3 ヶ月しか経っていない新人のメンバー（オンコール訓練も受けていない）が、Claude Code を使ってログを分析させました。

すると、すぐに根本原因が特定されました。checkpoint.rs ファイル内のセグメント ID の検証で発生した Rust パニックです。ファイル名、行番号、アサートメッセージまで、私が 2 ページ分のログを読み終える前に発見されたのです。さらに、Claude に「5 分間に何億回ものパニックが発生し、その後一時的に減少して再び急増する」というボリュームの breakdown を取得させるプロンプトも即座に実行されました。

Claude は非常に有用です。2 つの独立したハードウェアプラットフォーム全体で機能するため、クラウドサービスプロバイダ（CSP）に問い合わせる必要がありません。まだ原因を推論しているわけではありませんが、専門家が手作業で行うよりもはるかに速くシグナルを集約しています。

パニックはすべてプレフィルサーバーで発生しており、重複したセグメント ID が関与していました。バイナリのデプロイ時期を確認し、パニック発生前にロールアウト変更があったかどうかを調べるよう指示すると、これも私が確認する前に発見されました。

チームの新人の方が、経験豊富なメンバーよりもはるかに効果的でした。それは、「手作業でこれらを確認しなければならない」という制約にとらわれていないからです。

Orient Loop

続いて「O」のパート、つまり OODA ループについて話しましょう。LLM にとってここが最も興味深い部分です。実はこれは失敗談でもあります。

まず、何が起きたのかを理解してもらうために、LLM の推論プロセスについて簡単に説明させてください。Claude や他のトランスフォーマーモデルにプロンプトを入力してトークンを生成する際、素朴なアプローチは「シーケンス全体を一度読み込んで最初のトークンを出力し、次にそのシーケンスに新しいトークンを追加して再度処理し、次のトークンを出力する」というものです。しかし、この方法は非効率すぎて誰も採用していません。あくまで学術的な説明のために使われるだけです。

なぜなら、1,000 番目のトークンを生成する頃には、最初のトークンが同じ行列乗算計算を 1,000 回も繰り返されて処理されていることになるからです。

この仕組みは「KV キャッシュ」と呼ばれ、アテンションステップと呼ばれる処理の中で機能します。各トークンがキーと値のベクトルを生成しますが、これらは一度計算されると変化しません。そのため、これらのデータをどこかに保存しておくことが可能になります。

推論には主に 2 つのフェーズがあります。まず「プリフィル」では、入力されたプロンプト全体を一度に並列処理します。この際、すべてのキー・バリューペアがキャッシュに保存されます。この段階は計算リソースを大量に消費するため、「計算集約型（compute bound）」と呼ばれます。これは、多くの行列乗算演算を行うためです。

次に「デコード」または生成フェーズでは、先ほど保存した KV キャッシュを活用します。マシンには一度に 1 トークンずつ入力され、プロンプト全体を再処理する必要はありません。このように、トークンはストリームのように次々と生成されていきます。これが、Claude や ChatGPT、Gemini といったモデルでトークンが流れるように表示される理由です。

ただし、推論サービス提供者が大規模なバッチサイズを使用している場合、この一連の処理により速度が著しく低下することがあります。

機械が一つ故障しても、影響は同じです。通常、ユーザーエクスペリエンスを良好に保つために保守を行います。この KV キャッシュはギガバイト規模になることもあり、壊れやすいものです。非常に繊細で、扱いにも注意が必要です。

KV キャッシュが破綻すると、突然多くのプロンプトを再事前充填する必要が生じます。これは事前に用意していなかった計算リソースを大量に消費することになります。この種のインシデントは Claude において頻繁に発生します。

このような事態が発生した際のグラフの形状は以下のようになります。灰色の線はフィルタリングされたリクエスト数、赤色の線はエラー数を示しています。オレンジ色の領域がインシデント発生期間です。

グラフの形をよく見てください。エラーが発生した瞬間、リクエスト数はほぼ倍増します。その後、両者は同時に低下します。このパターンは毎回同じです。

私は毎回 Claude に「このグラフで何が起きたのか」と尋ねます。すると Claude は、「リクエスト量が増加した。これは容量不足の問題だ。サーバーを追加すればよい」と答えます。

私はこれを6回、7回修正しました。CLAUDE.md に追加しても、この状況に関する理解は得られますが、他の99のケースでは相関関係と因果関係を混同する誤った結論を導いてしまいます。それは役立ちません。

チームに新入りが加わると、彼らはすぐにこの方向へ誘導されてしまいます。「容量の問題だ」と即座に考えますが、実際にはキャッシュが失われたことが原因です。キャッシュの修復方法や当時の状況を理解すべきではないでしょうか？もしかしたら挽回できるかもしれません。

これが、LLM をインシデント対応に信頼できないと私が考える理由です。一歩引いて、因果関係と相関関係を区別しようとする姿勢が必要ですが、人間にとってもそれは難しいことです。私たちは毎日この問題と戦っています。2 つの線を見ると、「明らかにロールアウトが原因だ」とか「別の要因だろう」と考えます。過去の失敗という傷や経験があるからです。私は過去1年間でこの障害を何度も見てきました。この可能性を無視することはできません。他の可能性も探る必要があります。

自動化について、もう少し高い視点から考えてみましょう。ソフトウェアエンジニアリングの世界が、自動化システムと向き合うのは初めてではありません。

自動運転車の開発に取り組む自動車技術者会（SAE）は、2014 年、つまり 10 年以上前に、自動運転車に関するフレームワークを公表しました。当時はまさに「自動運転車」の議論が始まった時期です。まだロンドンでは実現していませんが、彼らは自動運転車がどのような姿になるかをマッピングし、人々が理解できるメンタルモデルを構築しようとしていました。

そのフレームワークには複数の段階と要素が含まれています。まず、ステアリングや加速といった「実行」機能が必要です。次に、走行環境を監視する機能。そして、「フォールバック性能」と呼ばれる、予期せぬ事態への対応能力です。具体的には、交差点が塞がっている場合や、駐車中の車を追い越す必要がある場合などが想定されます。

最後に、彼らが最も大きな課題と位置づけているのが「スコープとシステム能力」です。これはつまり、「カリフォルニアの晴れた日であれば、この車は本当に自律して運転できるのか？」という問いに他なりません。

あるいは、ロンドンの雨の中ですら自律走行できるのか？

単にシステムを積み重ねるだけでは実現できないのだ。レベルが上がれば上がるほど、その列の多くが人間ではなくシステムによって埋められていく。特定のレベルでは両方が共存することもある。

現在購入可能な現代車のほとんどは実際にはレベル 2 に分類される。自動ブレーキや車線維持支援、クルーズコントロールなど、私たちはこれらの技術に信頼を置いている。レベル 3 が本格的に面白くなるポイントだ。米国ではテスラが「完全自律走行」を提供しているが、欧州ではメルセデス・ベンツと BMW がドイツ限定でレベル 3 を実現している。

最も注目すべきはレベル 4 だ。ウェイモ（Waymo）がその代表格だ。運転手はいない、ただのタクシーである。車内に乗り込み、ステアリングホイールが自ら動く様子を見つめる。路上では、誰も乗っていない車両が A から B へ移動する姿を目撃できる。

ウェイモはロンドンの街でも試験運行を開始している。現地で働く友人に「なぜこんなに時間がかかるのか」と不満を漏らしたことがある。私の考えでは、サンフランシスコからモデルの重み（weights）を持ち込み、方向標識を反転させるだけで、車線が逆側の道路でも走行可能になるはずだったからだ。

しかし彼は、研究開発はそんな単純なものではないと答えた。

このフレームワークを、私の仕事であるプロダクションエンジニアリングに当てはめて考えてみましょう。以前のスライドで見たことがある方もいるかもしれません。

私にとっての柱は、まず「検知（Detection）」です。誰が異常を検出するかという役割です。アラートの不具合や信号の相関分析といった高度な手法もあれば、内部エラーが発生した際に適切なアラートが届いているかという基本的な確認もあります。

次に「初期対応（Initial Response）」です。サーバーの復旧や kubectl scale コマンドの実行、フェイルオーバー、ロールバック、あるいは問題を起こしたユーザーの利用制限など、「出血を止める」ために誰が即座に実行するかという部分です。

その次は「予防（Prevention）」です。再発防止のためにシステムを深く見直し、根本原因やアーキテクチャの変更点を特定する作業です。

最後に、自動運転車の分野で使われるような「運用ドメイン」の概念です。この AI エージェントが、私が管理している計測済みのフラッグシップサービスだけを扱うのか、それとも別のチームに即座に投入できる汎用性を持っているのか、という問いです。

システムは自ら学習し、状況の把握を自動で行います。レベル 0 は削除しました。私たちは自動化のおかげで幸運でした。コンピュータは非常に優秀だからです。

レベル 1 は検出のための支援に過ぎません。レベル 2 が成熟したシステムの到達点です。ここでは観測（Observability）が完全に自動化され、アラートも確実に発火します。AI でなくても、これはすでに自動化の域に入っています。複数のシグナルを相関させ、私たちが目指す地点に達するのです。

ただし、緩和措置の実行や修正プログラムの記述は依然として人間が行います。現在私たちはレベル 3 にあり、対応プロセスに人間と AI が共存しています。ここからレベル 4 へ移行できるでしょうか？私がこれまで話してきたのはまさにそれです。つまり、インシデント対応から人間を排除することです。

レベル 5 は私の考えでは AGI（汎用人工知能）の領域です。エージェントをあらゆる場所に配置し、それをチームメイトとして機能させることができれば、それは非常に素晴らしいことになるでしょう。

実行すべきレシピ

これが全体像の概要です。一般的な設定の説明でした。

私がチームや会社、そして自分自身で実際に機能していると感じた 5 つのポイントがあります。これらは約 1 年間にわたる試行錯誤から生まれたものです。

パターン 1：ページング（アラート通知）が届いた場合です。あなたは常識的な人なので、そのアラートはインフラストラクチャ・アズ・コードとして確実な場所に設定されており、PromQL やその他のクエリ言語で記述されているはずです。いきなり空白のチャットを開いたり、安易にコピー＆ペーストしたりしないでください。

代わりに、AI エージェントに対して「その式（クエリ）を渡す」ことで、Claude には「好奇心を持って調査してほしい」「私のシステム構成を考慮して、通常では見落としがちな箇所も探してほしい」といった指示を出してください。Claude は並列処理が可能です。エンドポイントを確認し、地域別やクラウドプロバイダー別の問題ではないかを探ります。

ステータスコードごとの分析も行います。先週のトラフィックと比較した結果も確認します。これらのクエリを実行する速度は、あなたがダッシュボードを操作して掘り下げるよりも速いはずです。ページングを受け取ってから 5〜10 分後にパソコンに向かったとしても、すでに調査の準備が整っている状態になります。これは非常に役立つ手法です。

先ほどの不正検知の例と同様に、Claude は多くの問題を発見できます。これは大きな変更ではなく、アラートを非同期でエージェントに渡すプロンプトとして設定するだけのシンプルな工夫です。

2 つ目のポイントは、例となるログを取得し、システム内で追跡するのではなく、実際に Claude に任せてしまうことです。私は異なるクラウド上に散在する複数のシステムを運用しており、それぞれでログの形式やソースが異なります。それらすべてに共通しているのは「トレース ID」だけです。

以前は、エッジ（ingress）や API、推論レベルでの出来事を確認したい場合、それぞれのログ画面を手動で開いていました。ブックマークを集めたリストを用意していても、結局は複数のウィンドウを行き来する必要がありました。

しかし、Claude に「自分で調べて」と指示すると、非常に有用な結果が得られます。モデルは文脈内でタイムラインを構築してくれるため、そのタイムラインに対して会話を始めることができます。「このリクエストは 3 つのサーバーを経由し、API で戻ってきた際に 10 秒のタイムアウトが発生した。そのためエラーを返している」といった具合です。

これにより、「API のタイムアウトが原因ではないことがわかる。実際にはバックエンド側で問題が起きている」という事実が明確になります。

このようにして、Claude は一貫性を持ってリクエストのライフサイクルを追跡できます。また、「どのサーバーが関与したか」を特定することも可能です。「そのサーバーでは CPU 使用率が高かったのか、それともメモリ不足だったのか？」といった具体的な質問も投げかけることができます。モデルから得た情報は後で再検証が必要になることもありますが、これにより調査の道筋が大きく開かれるのです。

3 つ目のパターンは、「この時間窓で何が変わったのか？」という問いです。私はこのトラックのアンコンファレンスでディスカッションを立ち上げました。

以前、デプロイや設定プッシュがあまり頻繁に行われない会社で働いていました。モノリスを展開する際は問題ありませんでしたが、スケールするという点では限界がありました。現在はマイクロサービスの世界に身を置いています。サービスは常時リリースされ、設定プッシュ、機能フラグ、cron ジョブなどを通じて変更が行われます。そのため、「何が変わったのか」と「インシデントが発生した瞬間」を関連付けることが非常に難しくなっています。

そこで私たちは、社内で起こる主要な変更を手作業で追跡する仕組みを構築しました。これは手動でキュレーションされており、1 秒間に 100 件のイベントが殺到して DDoS のように機能しなくなるようなことはありません。Claude にインシデントが発生した時間窓を与えれば、すぐにデプロイ情報を教えてくれます。それだけでなく、画像前処理に影響を与えるコミットがないかまで確認してくれます。

これは、以前私が手動で行っていた調査の道筋を見つけるのに非常に役立ちます。ただし、本当に興奮するのは「根本原因を見つけた時」です。Claude は「3 つの可能性のある問題が見つかりました」と教えてくれますが、そこからさらに深く掘り下げる必要があります。「ロールバックを試してみたらどうでしょうか」と提案された場合、もしロールバックが容易であれば、迷わず実行しましょう。その後、エラー数が減少しているかを確認します。これははるかに速く、多くの労力を節約できます。

4 つ目は、事後分析（ポストモーテム）や振り返りです。Claude はこうした面倒な作業を得意としています。

私は以前、これらの作業が非常に苦手で、チームに参加したばかりの若手エンジニアや中堅エンジニアに対して、「現場で試練を乗り越えることで成長させる」という手法をとっていた時期もありました。「今回のインシデントに関わったのはお前たちだ。大規模な対応には参加しなかったかもしれないが、関与したという報酬として、2〜3 ページの事後分析レポートを書け。そうすれば、システム全体の動きを理解でき、何が失敗する可能性があるかを学べるはずだ」という具合です。

しかし、それは常に面倒な作業でした。誰だってタイムラインの整理や Slack のスレッドをまとめることを望みません。

今では、Slack チャンネル全体と Google Meet の議事録をテキスト形式で抽出し、SRE 書籍に由来する事後分析テンプレート（約 80% をそのまま使用）を組み合わせたプロンプトを Claude に与えるだけで、それなりの草案が生成されます。

ただし、2 つの課題があります。まず、根本原因の特定において Claude は非常に苦手です。その挙動は不安定で、「これが原因だ」と断言しがちですが、実際には単一の原因など存在しません。我々は皆、根本原因が一つだけではないことを知っています。多くの要因が絡み合い、複数の問題が複合しているのが現実です。

これは「スイスチーズモデル」のように、複数の穴（欠陥）が重なって事故が起きる構造を指します。決してロールアウトだけが悪いわけでも、コード変更だけが悪いわけでもありません。むしろ、組織内のあらゆるプロセスや慣習が、インシデント発生の一因となっています。

Claude には、貴社のシステムの歴史、特に 10 年以上も運用されているシステムの詳細は理解できません。なぜセカンダリデータベースのフォールバックをテストしなかったのかという背景事情も、また、組織内で暗黙知として共有されている知識も把握していません。

80% の確度で読みやすく説得力のある報告書が得られることは事実ですが、強くお勧めするのは、それを社内に公開する前に必ず人間による検証を行うことです。もしこうした文書が社内全体に広がり、人間のチェックを経ずに流通すれば、真実性が損なわれるリスクがあります。私は実際にその事態を目撃しています。

現在、事後報告（ポストモテム）で活用している手法の一つに、Claude に対して「何か確信が持てない場合は、人間向けの TODO を挿入してください」と指示するものがあります。これにより、モデル自体が自己反省する能力を発揮します。完璧ではありませんが、その機能は確実に存在しています。

すべての TODO が解決され、不確実な箇所が修正されるまで、事後報告を公式文書として扱うべきではないことは周知の事実です。もし未検証のデータをループさせて再入力すれば「ゴミを入れればゴミが出る」状態になりますが、一方で、過去のインシデントに関する信頼性の高い情報源としても機能します。

Claude がこうした検証済みのドキュメント群を要約すれば、ロードマップ策定のための材料として非常に有用になります。

5 つ目のポイントは、引継ぎプロセスの転換です。事後報告と同様に、Claude に引継ぎ文書の作成を任せることも可能です。ただし強調しておきたいのは、「公開で構築する」姿勢が不可欠だということです。オンコール対応中の行動はすべて、チャネル上で記録されるべきです。オンコール担当者は、対応中に実施したデバッグ手順などを「思考の可視化」として書き残すことが重要です。

また、Claude に対して要約機能に特化させるようプロンプトを調整することも可能です。引き継ぎを受ける側は、ロンドン時間の昼間に発生した200〜400件のメッセージをすべて読む必要はありません。リンク付きの1段落で要点を把握し、詳細が必要な場合は関連スレッドへ遷移すれば十分です。

これはおそらく、最もシンプルかつ効果的な改善策と言えるでしょう。

学習における課題

今日は、私自身もまだ結論を出せていないテーマについてお話しします。それは「学習」の問題です。

Claude がスタックトレースを見つけ、ロールバックを提案し、あなたが承認してそれが成功したとしましょう。その時、あなたは何を学んだのでしょうか？

ベテランのインシデント対応担当者が特別に頭が良いわけではありません。彼らがシステムの詳細を最初から知っているわけでもありません。重要なのは、過去の失敗やトラブルで「痛い目」を見てきた経験があることです。他の人がシステムをデバッグする様子も見てきました。その結果、彼らの手には「傷跡（スカー・ティシュー）」のようなものが残っています。

もし AI がこうした作業を代行し始めたら、私たちのスキルは萎縮してしまうのでしょうか？

AI に任せてしまった行動の結果としてシステムに何が起こったかというフィードバックループが失われてしまうからです。『SRE（Site Reliability Engineering）』の書籍にもある通り、ミッションクリティカルなシステムのオンコールを小規模な人間チームで回し、50 人や 100 人のシニアエンジニアを年一回交代させるローテーションに頼らなかったのには理由があります。

もし多くのエンジニアがオンコール業務を「仕事」として割り当ててしまうと、オンコール中ではない時には、ページ通知（アラート）への対応を最優先事項として扱わなくなってしまうからです。

再びアラートが鳴るのを避けたい。それがチーム全体の使命であり、取り組むべき課題です。

AI が自動修復を開始すれば、その痛みは消えます。しかし、インセンティブの不一致が生じる可能性があります。これは上級者側の問題ですが、中堅・若手エンジニアにとっては、簡単な事象への対応訓練が積めなくなります。また、迷わずロールバックコマンドを打つ必要に迫られたり、プレイブックの履歴を確認したりする経験も得られなくなるでしょう。

モデルが対処できない大規模なインシデントが発生した際、その対応策について誤った判断を下すリスクがあります。私はこれを真剣に懸念しています。

OpenAI の研究者（名前は Roon）は 2023 年、Claude Code や Anthropic が知られる以前にツイートしました。ジェボンズのパラドックスにより、ソフトウェアの複雑さは劇的に増大し、ソフトウェアエンジニアリングが極めて困難になるだろうと指摘しています。

AI業界で最も愛されるパラドックスの一つに「ジェボンズのパラドックス」があります。これは、技術の進歩によって資源の利用効率が向上しても、その結果としてコストが下がることで消費量が増加し、むしろ減少しないという現象です。

私たちの業界では具体的には、「ソフトウェアを書くことが容易になったため、より多くのコードを生産してしまい」、複雑性が低下するどころか上昇します。その結果、システムはより多様な方法で障害を起こすようになり、インシデントの発生頻度が高まり、オンコール対応の負担も増大します。

これに対する反論として、「開発ツールのあらゆる改善も、この増え続ける複雑性によって相殺されてしまう」という意見があります。しかし、魔法の杖を振るように、AIエージェントがこの悪循環を打破できるかもしれません。私たちは計算資源を必要に応じて投入し、複雑なシステムを簡素化・管理することが可能です。

私たちはすでにチームや組織を成長させるための「レシピ」を持っています。マイクロサービスという手法も確立されています。では、AIエージェントは業界全体が積み上げてきた知見を実行できるでしょうか？そこには大きな疑問符がつきます。予想通り、roon氏は非常に活発に投稿しており、この指摘は時を経ても色あせることなく、今なお私の夜を襲います。

AIモデルの時間経過に伴う軌跡

AI の分野で最も愛されているチャートの一つをご紹介します。METR は AI の能力を評価する組織であり、その研究の一つに「モデルが自律的に動作できる時間」の分析があります。

このグラフの横軸はモデルのリリース日、縦軸はタスクの実行時間を示しています。各モデルは、人間が以前に行っていた一連のタスクで評価されます。成功確率と所要時間が測定され、モデルがタスクの少なくとも 50% を完了できた場合に、その実行時間がチャート上にプロットされます。

ご覧のように、モデルの性能は指数関数的に向上しており、単なる直線的な改善を超えています。これは加速度的な成長を示唆しています。この点については多くの議論が交わされており、一部の曲線が頭打ちになっているように見えるため、「成長はいつか止まる」とするシグモイド曲線を引く人もいます。2022 年以降も「必ず止まる」と主張する声がありましたが、実際にはそうではありません。

AI スケーリングの法則が存在し、データと計算リソースが増えればモデルは改善し、知能が高まることがわかっています。今日がモデルにとって最悪の日であり、明日からはさらに良くなるでしょう。私たちは現在その改善に取り組んでいます。

要約付きプレゼンテーション をもっと見る

録画日：2026 年 8 月 26 日