AnthropicがAI SREの限界を公式認定。「相関関係を因果関係と誤認し続ける」
Anthropicは2026年3月19日のQCon Londonで、ClaudeをSRE（サイト信頼性エンジニア）として活用する試みの限界を公式に報告しました。「相関関係を因果関係と誤認し続ける」という根本的な問題が残存しており、SREの完全代替には至らないと自社が認めた形です。AIにエラーログやアラートを読ませて原因を特定しようとしたことがある方には、直接関係する話です。
何を試みて、何が分かったか
AnthropicはClaudeを使ってClaudeのインフラ障害を修復する、いわば「AIがAIを管理する」構成を試みていました。ログやメトリクスを読ませ、警告アラートの原因を特定させ、修復アクションを実行させるという流れです。
結果として明らかになった問題は、警告の表面パターンは認識できるが、障害の根本原因を特定できないという点でした。たとえば「メモリ使用量が急増した後にレスポンスタイムが悪化した」という相関関係を見て、「メモリが原因」と判断してしまう。しかし実際の根本原因はメモリではなく、特定のクエリパターンによるロック競合だったりします。
人間のSREはこういった場面で、過去のインシデント経験やシステム全体の挙動パターン、チームが暗黙的に共有している文脈知識を総動員して「おそらくこれが本当の原因」という仮説を立てます。現在のLLMにはこの文脈理解が欠けています。
なぜ相関→因果の誤認が起きるのか
LLMは本質的にパターンマッチングで動きます。学習データの中で「Aが起きた後にBが起きた」という事例が多ければ、「A→B」という因果関係として認識します。ところがシステム障害の原因特定では、観測できる相関関係の背後にある「なぜ」を追う必要があります。
これはLLMのアーキテクチャ上の根本的な弱点です。プロンプトの改善やコンテキスト長の拡大で多少は改善できますが、今の世代のモデルでは完全に解消されていません。
Anthropic自身がこれを認めたことは注目に値します。自社モデルの限界を公開する場として、ロンドンの技術カンファレンスを選んだことからも、隠蔽ではなく技術的誠実さとして発信している姿勢が見えます。
「AI万能論」への一つの答え
2025年から2026年にかけて、「AIがソフトウェアエンジニアを代替する」「DevOpsチームが不要になる」という主張が増えてきました。Cloudflareが$1,100・1週間でNext.jsを再実装した事例など、実際にコード生成の範囲では驚くような成果が出ています。
しかしSREが担う「動いているシステムの何が壊れているか」という問いは、コード生成とは性質が異なります。コード生成は「何を作るか」が明確ですが、インシデント対応は「何が起きているか」を未知の状態から掘り下げる作業です。
今回のAnthropicの報告は、AIが向いている作業と向いていない作業の境界線をより具体的に示した事例といえます。「支援ツール止まり」が2026年のSRE領域でのAI活用の現実的な見通しになってきています。
AIに任せていい作業・任せると危ない作業
専任のSREチームがいない開発環境では、この誤認問題が静かに影響しやすい状況があります。AIがエラーの原因を断言する場面は日常的に起きています。
| 作業 | AI活用の適性 | 理由 |
|---|---|---|
| ログのサマリー作成 | 高い | パターン認識が得意 |
| アラートの緊急度分類 | 高い | 既知パターンの照合で十分 |
| 過去インシデントの類似検索 | 高い | テキスト検索に近い |
| エラーメッセージの意味解説 | 高い | 定義の説明は得意 |
| 障害の根本原因の特定 | 低い | 相関→因果の誤認が起きやすい |
| 「なぜ今このタイミングで」の特定 | 低い | 文脈依存の推論が苦手 |
| 修復手順の最終判断 | 低い | 誤った原因に基づく対処になるリスク |
「整理させる」用途はAIが得意で、「判断させる」用途は今のところ人間のチェックが必要という整理が実態に近いです。
誤認に気づくための確認方法
AIがエラーログを読んで「原因はここです」と断言した場合、以下の確認を追加で行う習慣が役立ちます。
原因の絞り込み確認
AIが「A が原因」と言ったとき、「もし A が原因でないとしたら、次に考えられる原因は何か」と追加で質問します。AIが自信を持って別の候補も挙げてくるなら、最初の断言は過信だった可能性があります。
タイミングの確認
「このエラーは以前も起きていたか、それとも今回初めてか」をAIに確認する前に、自分でログの期間を広げて確認します。AIは直近のログに引っ張られて「今回の変更が原因」と判断しやすい傾向があります。
変更との対応確認
デプロイ直後にエラーが出た場合、AIは自然に「デプロイが原因」と見なしやすいです。しかし実際はデプロイと無関係に、外部サービスのタイムアウトや依存ライブラリのバージョン競合が原因だったケースが多くあります。「デプロイを除いた場合の原因候補」という形で質問するだけで、回答の質が変わることがあります。
たとえば、Next.jsのビルドエラーをClaudeに貼り付けると、直前に編集したファイルや変更行数の多いファイルを原因として指摘しがちです。しかし実際には無関係の依存ライブラリ間のバージョン競合だったりします。AIの最初の回答を起点にしながら、確認の手を動かす習慣を持つことで誤診を減らせます。
残る疑問
今回の報告はAnthropicの自社インフラに限った話です。異なる規模・構成のシステムや、より詳細なシステム文書をコンテキストとして与えた場合に同じ問題が出るかどうかは不明です。
また、Anthropicが「限界を認めた」というより「現時点の限界を正直に共有した」ととらえる方が正確かもしれません。今後のモデル世代での改善状況を見ていく必要があります。
Discussion