8月26日、InfoQが「Can Claude Fix Itself? Using LLMs for Incident Response」と題した記事を公開した。AnthropicのSREがClaudeをインシデント対応に実際に活用した現場での知見と限界について、具体的なエピソードを交えながら詳しく紹介されている。
AnthropicでAIリライアビリティチームに所属するAlex Palcuieによるプレゼンテーションの書き起こしだ。元GoogleのSRE（Site Reliability Engineer）として、GCEのSREチームや「SREのためのSREチーム」（通常のSREがお手上げになったときのエスカレーション層）を経験してきた人物が、Claude自身を使ってClaudeのインシデントに対応した実体験を語っている。
結論から言う：「Claudeはインシデントを自動解決しない」
Palcuieは冒頭でこの問いに正面から答えている。「No」だ。
「我々は無制限のトークンを持ち、研究者が隣の席にいる。モデルのトレーニングにも関与している。もし誰かが実現できているなら我々のはずだが、チームは今まさに採用を続けている。LLMがポケベルを持てるなら、これほど採用する必要はない。」
Anthropicのリライアビリティチームはロンドン・ダブリン・米国で積極採用中であり、それ自体がLLMによる完全自動化が現時点では不可能であることの証左だと指摘する。
OODAループで見るLLMの「凸凹な能力」
Palcuieがインシデント対応の分析に使うフレームワークが、米空軍の戦闘機パイロット訓練から生まれたOODAループ（Observe：観察→Orient：状況判断→Decide：意思決定→Act：実行）だ。LLMはこのループ全体で均質に優秀なわけでも均質に使えないわけでもなく、フェーズによって能力が激しく乖離している、と彼は言う。業界用語では「jagged（ギザギザ）」と表現される。
本講演ではとくにObserveとOrientの2フェーズに焦点を当てて実例が語られており、DecideとActについては現時点での自動化の限界を示す背景として位置づけられている。
Observe（観察）フェーズ：超人的
最も強烈なエピソードが12月31日の話だ。Claude Opus 4.5（2025年時点のAnthropicの最上位モデルの一つ）でHTTP 500エラーが増加し、Palcuieは独自に整備したSKILL.md（リクエストのライフサイクル、エッジサーバーからAPIフロントエンド、GPUやTPUを使う推論バックエンドまでを記述したドキュメント）とデータウェアハウスの構造を学習させたClaudeに調査を依頼した。
Claudeが実行したのは以下の連鎖的な調査だ：
- SQLで直近1時間のサーバーエラーを取得 → 画像処理パスの未処理例外を特定
- モノレポのコードベースを検索し、例外の発生箇所と発火条件を特定
- 失敗リクエストのJSONペイロードを読み込み → 画像22枚とPDF添付のパターンを発見
- 同条件のリクエストを送信したアカウントを集計 → 約200アカウント、ほぼ同時刻から開始
- 同期間に作成されたアカウント数を調査 → 約4,000アカウント、同一のメールテンプレート・同一プロバイダー
- アカウント作成頻度を分析 → 毎分9件のサインアップ、残り3,800アカウントはリクエストゼロのまま待機中
Claudeの結論は「これは500エラーの問題ではなく、フラウド（不正利用）だ」というものだった。Palcuieは「私だけなら500エラーをAPIチームのバグとして報告し、12月31日にアカウント不正チームをページングすることはなかった」と認めている。タイトルにある「深夜3時のページ」もこうしたオンコールの文脈から来ており、年末年始を問わず人間が起こされ続けている現実を指している。
もう一つのエピソードでは、本番環境でRustのパニックが発生した際、経験の浅いチームメンバーがClaudeにログを渡したところ、checkpoint.rsの特定行におけるセグメントID検証の問題を、Palcuie本人がログを2ページ読み終わる前に特定した。経験者より新人の方が、Claude Codeを活用することで実質的に速かったという事実は示唆的だ。
Orient（状況判断）フェーズ：危険
一転して、Orientフェーズは「失敗の話」として語られる。このフェーズは「観察した事実が何を意味するか」を解釈・判断する段階であり、Observeフェーズとは性質が大きく異なる。Palcuieは、LLMはここで誤った推論を自信満々に提示する危険があると指摘する。事実の収集と検索は得意でも、複数の仮説を立てて優先順位をつけ、ノイズと真因を分離する「判断」のプロセスでは、もっともらしいが間違った説明を確信を持って出力する傾向がある。Observeフェーズでの超人的なパフォーマンスと対照的であるがゆえに、現場での過信は特に危険だという警告として位置づけられている。
オンコールは人間への課税である
技術的な内容と並んで、Palcuieの語りで印象的なのが「オンコール」に対する姿勢だ。
「オンコールは、我々のシステムが自律的に動けないから人間に課している税だ。」
深夜3時にページが来て、4時半にまた別のデータベース障害でページが来て、9時にスタンドアップで普通の顔をして出席する、というリアルを語りつつ、「これを武勇伝にすべきではない」と明言している。
AI SREを謳うスタートアップが10社以上存在することへの皮肉も交えながら、「ベンチマークはきれいに整形された問題を解くものだが、実際の深夜3時のインシデントはそういうものではない」と冷静に評する。それでも「うまくいってほしい、なぜなら人間がオンコールの重荷から解放されるべきだから」というスタンスは一貫している。
LLMに渡せる文脈の設計が鍵
今回のデモで際立っているのはClaudeの能力そのものもさることながら、**SKILL.mdの存在**だ。システムのアーキテクチャ、データウェアハウスの構造、自律的に情報収集する方法を事前に記述したドキュメントをプロンプトに組み込むことで、汎用的なLLMがシステム固有の文脈で動けるようになっている。どこまでの文脈をどう渡すかの設計が、インシデント対応でのLLM活用の実効性を左右する。
言い換えれば、LLMを「賢いツール」として使いこなせるかどうかは、モデルの性能以前に、自社システムの知識をどれだけ構造化してLLMに与えられるかという運用設計の問題でもある。SKILL.mdのようなドキュメントの整備は、LLM活用の前提条件として今後ますます重要になるだろう。
詳細はCan Claude Fix Itself? Using LLMs for Incident Responseを参照していただきたい。
