マイクロサービスの障害で、どこが原因かを突き止める作業をAIに任せる研究が増えています。その多くは、調べる順番や役割分担を細かく決めた「作り込み型」のエージェントです。10月27日にarXivへ投稿された論文Free to Look, Free to Reason: Simple LLM Harnesses Outdiagnose Hand-Crafted Root Cause Analysis Agentsは、この前提に疑問を投げかけました。手順を決めずにモデルへ自由に調べさせる単純な構成のほうが、正答率が高く、費用も少なかったと報告しています。運用の自動化にLLMを組み込もうとしている開発者には、設計の方針に関わる結果です。
背景と文脈
根本原因分析（RCA：Root Cause Analysis、障害が起きたときに、どのサービスや部品が発端かを突き止める作業）は、運用担当者の大きな負担です。マイクロサービス構成では呼び出しの連鎖が長く、ログやメトリクス、トレースを横断して見る必要があります。
この作業にLLM（Large Language Model、大規模言語モデル）を使う研究では、手順書をそのまま組み込む設計が主流でした。「まずアラートを確認」「次に依存関係を調べる」と段階を固定し、段階ごとに役割の違うエージェントを置く方式です。人の運用手順をなぞるので安心感があります。
ただ、各手法は自前のデータで評価されることが多く、比べる相手も少数でした。高性能なモデルに自由に調べさせた場合と比べて本当に優れているのか、はっきりしていなかったと著者らは指摘しています。
技術/ビジネス面
著者らはまず、公開されている8つのデータセットから検証済みの90件を集め、評価用のRCAtlasを作りました。6種類のモデルと3段階の推論量（reasoning effort：答える前にモデルが考える量の設定）を組み合わせて試しています。
比べたのは2つの陣営です。片方は、モデルの呼び出し方を一切決めない3つの単純な構成でした。証拠をまとめて1回だけ質問する方式、SQLでデータを調べるエージェント、OpenAIのコーディングエージェントCodexです。もう片方は、論文で発表済みの作り込み型エージェント5種と、統計や因果推論を使う従来手法でした。
結果は単純な構成の圧勝です。中位クラスの3モデルで、PR@1（1位に挙げた候補が正解だった割合）は65〜77%に達しました。作り込み型は16〜53%、従来手法は6〜39%にとどまっています。両方を試せたすべてのモデルで、この順位は変わりませんでした。
作り込み型が負けた理由も分析しています。これらはモデル呼び出しの1割から全部を、決められた手順に使っていました。事例を追うと、決め打ちの手順が診断の決め手になる証拠を飛ばしてしまう場面がありました。また、推論量を増やしても正答率は数ポイントしか上がらず、実行時間は最大7倍に伸びました。従来手法より正確な実行のうち、費用や時間の面で無駄のない組み合わせは、すべて単純な構成でした。
これからどうなるか
この結果は、エージェント設計の流行に一石を投じます。モデルが十分に賢ければ、人が手順を細かく決めるほど、かえって視野を狭めることがあるという指摘です。強いモデルは安定性を高め、対話を重ねる構成は調べる力を伸ばす、という役割の違いも示されました。
運用の自動化を作っている開発者にとっては、まず単純な構成を基準として試す価値があります。たとえば、監視データをSQLで引ける形に整え、モデルにクエリを書かせるだけの構成から始める方法です。そのうえで作り込みが本当に効くかを測れば、無駄な開発を減らせます。推論量を最大にしても効果は小さいため、費用の見積もりも見直せそうです。
一方で、評価は90件の公開事例に限られます。社内の独自システムや、権限の制約が厳しい本番環境で同じ傾向が出るかは、今後の検証を待つ必要があります。
まとめ
マイクロサービスの障害原因の特定で、手順を決めない単純なLLM構成が、作り込み型エージェントや従来手法を上回りました。1位正答率は65〜77%で、費用と時間の面でも有利でした。推論量を増やす効果は小さく、実行時間だけが伸びています。エージェントを作り込む前に、単純な基準と比べる大切さを示す研究です。
参考リンク
- Free to Look, Free to Reason: Simple LLM Harnesses Outdiagnose Hand-Crafted Root Cause Analysis Agents（arXiv）
- arXiv cs.AI 新着一覧
アイキャッチ画像: Photo by Eliott Van Buggenhout on Unsplash
