7月25日、Mark Silvesterが「AI Root Cause Analysis Shifts from Model Reasoning to Context Engineering」と題した記事を公開した。LLMを使ったインシデントの根本原因分析（RCA）において、本当のボトルネックはモデルの推論能力ではなくコンテキスト準備にあるという実証的な知見を詳しく紹介している。なお、RCA（Root Cause Analysis）とは、システム障害やインシデントの発生原因を深掘りして特定するプロセスを指し、オブザービリティの文脈では複数のテレメトリシグナル（ログ・メトリクス・トレース）を相関させて障害の連鎖を辿る作業を意味する。

「モデルより、何を渡すかが問題だ」

オブザービリティ分野のエンジニアの間で、ある認識が広まりつつある。AIを使ったインシデントの根本原因分析において、LLMの推論能力はもはやボトルネックではない。難しいのは、モデルに渡すデータを決めるパイプライン側だ、という考え方だ。

この主張を実証しようとしたのが、オブザービリティベンダーCorootのエンジニア、Nikolay Sivkoだ。Sivkoは独自の研究の中で、LLMによるRCAを2つの仕事に分けた。「目の前のデータを推論すること」と「どのデータをどんな形でモデルに渡すかを決めるハーネス（制御基盤）」だ。「AIはRCAできるか？」という問いそのものが間違いであり、この2つを切り離して評価しなければ何もわからない、と彼は指摘している。

Corootの実験設計：誤答の原因を特定可能にする

Corootのパイプラインは、複数のシグナルを相関させてfindings（所見）にまとめ、エージェントループなしに1つのコンテキストとしてモデルに渡す設計になっている。これにより、もし誤った診断が出た場合、その責任をモデルに帰すことができる——コンテキスト不足ではなく、推論の失敗として切り分けられる。

テストシナリオは1種類。Chaos MeshのNetworkChaos機能を使い、カタログサービスとPostgresデータベース間にネットワーク遅延を注入する実験だ。クエリが遅延し、フロントエンドが502エラーを返す状態を作り出した。コンテキストには意図的に誤解を招くシグナルも含めた（ネットワーク往復時間で膨らんだクエリタイミングなど）。

このプロンプト（約9,800トークン）を11種類のモデルに対して実行し、根本原因・因果連鎖・即時対応策を問うた。

結果：フロンティアモデルはほぼ全勝、自己ホスト型は明暗が分かれた

元記事に記載されたモデル名および結果は以下のとおりだ（モデル名は元記事原文を参照されたい）。

• フロンティアモデル群はすべて正解。Chaos Meshの実験自体を特定し、実験とそのスケジュールを削除すべき点まで正しく指摘した。
• 大規模なオープンウェイトモデルも概ね同等の結果。
• 自己ホスト可能なモデルでは、一部モデルのみが根本原因を特定。より大きなパラメータ数を持つモデルが特定に失敗するケースも見られた。

モデルサイズが大きければ正解するわけではないことが示された形だ。

コスト面では、相関処理がモデル呼び出し前に完了するため、フロンティアモデルでも1回の実行コストは数セント程度にとどまるとSivkoは述べている。

エージェント型 vs 決定論的パイプライン：業界の重力はどちらへ

AI RCAのアプローチは大きく2つに分かれる。

エージェント型は、モデルにツールを与えてテレメトリデータを自律的に取得させる。事前に定義されていない異常なインシデントにも対応できる柔軟性が強みだ。一方、ZenMLやIncident.ioの事例によれば、マルチエージェントLLM調査は本番環境でのデバッグが極めて難しく、失敗時にはクリーンなスタックトレースが残らず、プロンプトの予測不能な相互作用だけが残るとされている。

決定論的パイプラインは、シグナルを事前に相関させてモデルに渡す。繰り返しの品質が安定し、評価もしやすい。DynatraceのDavis AIも、リアルタイムの依存関係マップを走査してトポロジーベースの因果分析を行うこの方向性を採用している。

Redditのエンジニアたちの議論では、完全エージェント型設計を捨てて決定論的ワークフローにLLMステップを組み込む形に移行した、という報告が複数見られる。理由として「信頼性の向上」と「トークンコストの低減」が挙げられている。

コンテキストエンジニアリングという新規律

Sivkoの結論は明快だ。AIによるRCAの推論部分は「基本的に解決済み」であり、本当の作業は「モデルを呼び出す前に、正しくコンパクトなコンテキストを準備すること」にある。

この考え方は業界全体でも共鳴している。Anthropicはエージェント向けの効果的なコンテキスト設計のベストプラクティスを公開しており、ノイズを排除して高シグナルな情報のみをモデルに渡す手法を詳述している。LangChainはエージェントアーキテクチャにおけるコンテキスト管理をフレームワークレベルで体系化し、プロンプト設計よりもデータ選択・整形の重要性を強調している。オブザービリティベンダーのMezmoは、オブザービリティ特有の大量ログ・メトリクスをどう絞り込んでLLMに渡すかという実装観点から同様の知見を発表している。三者のアプローチは出発点が異なるが、高シグナルでコンパクトなコンテキストをキュレーションすることがLLMベースの推論を信頼できるものにする中心的な規律だ、という方向に収束している。

インシデント対応にLLMを組み込もうとするチームへの実践的な示唆は、より大きなモデルを探すより、コンテキスト準備に投資した方が効果的だ、ということになる。

詳細はAI Root Cause Analysis Shifts from Model Reasoning to Context Engineeringを参照していただきたい。