AIツールによる障害への対処に期待が高まる一方、検証では原因特定の精度は低いという結果が出た。この課題に対し、IBM Researchが開発したオープンソース評価ツールと、特定精度を95%に改善した手法を解説する。
インシデント処理時の原因調査として、ログやメトリクス(指標)を大規模言語モデル(LLM)に入力して分析させる手法が模索されている。市場には「根本原因分析を90%高速化する」とうたうAIツールも存在する。
しかし、その実態は期待を裏切るものだ。Meta Platformsが2024年に公開した実証データによれば、過去のインシデントデータを用いて独自にチューニングしたLLMであっても、初期段階での原因特定の成功率は42%にとどまる。IBMの研究部門IBM Researchが構築した検証用ツール「ITBench」でも、「Gemini 3 Pro」のような高性能モデルでさえ正しい根本原因を突き止められないことが判明した。
LLMが失敗する最大の理由は、提供されるコンテキストに潜むノイズにある。例えば、ネットワーク設定の変更と直後の取り消しといった、本来の障害とは無関係な情報が存在すると、LLMはそれに固執してしまい、真の原因である設定ミスを見逃してしまうのだ。IBM Researchが2025年に実施した検証によれば、「ReAct」などLLMに調査プロセスを自律的に実行させる手法を用いた場合、原因特定の成功率は約14%という結果に終わっている。
この実戦では使い物にならない精度を、IBM Researchは95%という実用レベルに引き上げた。その突破口は、LLMに全てを丸投げするのをやめ、システムの「トポロジー」(構成情報)を使ってAIを正しく導くというアプローチにあった。
2026年3月に開催されたテクノロジーカンファレンス「SREcon26 Americas」のセッション「From Chaos to Confidence: How SREs Can Leverage 50 (and Counting) Failure...」には、このプロジェクトを担当したIBM Researchのローハン・アローラ氏らが登壇した。セッション内で彼らはAIモデルの能力を科学的かつ定量的に評価するためのオープンソースの検証システムであるITBenchを開発し、その成果を発表した。
ITBenchはコンテナオーケストレーションツール「Kubernetes」で稼働し、「Apache 2.0」ライセンスの下、ソースコードリポジトリ「GitHub」で公開されている。ITBench内には、マイクロサービスで構成されたテスト用アプリケーションや、標準的なオブザーバビリティツール群があらかじめ用意される。評価の仕組みとしては、自動化ツール「Ansible」を利用して、不具合のあるソフトウェアを配置するなどの障害を注入し、その障害をAIエージェントがいかに迅速かつ正確に診断、緩和できるかを測定する。
評価に当たっては、AIモデルの評価で一般的に用いられる「Pass at K」(K回の試行内に正解を含められたかどうか)や、IT運用の標準指標である「Mean Time to Resolution」(MTTR:平均復旧時間)を採用した。
独自の指標として、「Mean Time to WTF」という概念が導入された。これは、AIモデルが的外れな提案や行動を取り、人間のサイト信頼性エンジニアを困惑させるまでの時間を示すものだ。AIツールの導入によってかえって現場の作業負担が増加してしまっては本末転倒であるため、運用担当者にとっての真の有用性が厳しく問われているのだ。
初期の実験では、LLM自身にデータ収集から分析、解決策の立案までを全て任せるアーキテクチャが採用されたが、前述の通り原因特定の成功率は約14%、問題解決に至る割合は約11%にとどまった。分析の結果、LLMは巨大で複雑なKubernetesシステムで迷子になり、不要な情報収集を繰り返して幻覚(ハルシネーション)を引き起こしていることが分かった。
そこで研究チームは、アプリケーションのトポロジー情報を用いて、LLMが探索できる範囲を意図的に制限する手法を考案した。アラートが発生したサービスの周辺にのみ範囲を絞り、あらかじめ定義された固定の手順に基づいてLLMに状況を共有することで、LLMが各種ツールを操作して原因を探る負担や生データを解析する負荷を軽減したのだ。結果として、この制約を与えられたAIエージェントは、3回の試行で原因を特定する割合(Pass at 3)において約95%という劇的な精度向上を達成した。
ITBenchは、過去のインシデントレポートを読み込ませることで、LLMを活用して自動的に障害シナリオを評価システム内に構築する機能も備えている。これによって、人間が手作業でコードを書かなくても評価用のテストケースを容易に拡充できる。
ITBenchが対象とするのはSRE(サイト信頼性エンジニアリング)領域だけではない。過去には、悪意のある攻撃者がGPU搭載の仮想マシンを不正に立ち上げて暗号資産のマイニングを行った事例が存在する。この異常にいち早く気付いたのはSREではなく、クラウド費用の急増を検知したFinOps(クラウド費用最適化)の担当者であったという。このように、ITBenchはセキュリティやFinOpsといった周辺領域のインシデント評価にも応用できる高い適応力を持っている。
発表時点でITBenchに実装されている障害パターンは、現実のシステム運用で想定されるトラブルの約15%をカバーしているに過ぎないという。「真に信頼できるAIアシスタント」を育てるため、開発チームはIT担当者に対し、日々の運用やCI/CDパイプラインで遭遇したインシデント事例をベンチマークに追加するよう呼び掛けている。
本稿は、USENIXが2026年4月24日に公開した動画「SREcon26 Americas - From Chaos to Confidence: How SREs Can Leverage 50 (and Counting) Failure...」を基に作成しました。
Copyright © ITmedia, Inc. All Rights Reserved.
本記事は制作段階でChatGPT等の生成系AIサービスを利用していますが、文責は編集部に帰属します。
瞬時にM365が乗っ取られる――全社員に周知すべき“新フィッシング”の教訓
MFA(多要素認証)を入れたから安心という常識が崩れ去っている。フィッシング集団「Tycoon2FA」が摘発されたが、脅威が完全になくなったというわけではない。

「サイト内検索」&「ライブチャット」売れ筋TOP5(2025年5月)
今週は、サイト内検索ツールとライブチャットの国内売れ筋TOP5をそれぞれ紹介します。

「ECプラットフォーム」売れ筋TOP10(2025年5月)
今週は、ECプラットフォーム製品(ECサイト構築ツール)の国内売れ筋TOP10を紹介します。

「パーソナライゼーション」&「A/Bテスト」ツール売れ筋TOP5(2025年5月)
今週は、パーソナライゼーション製品と「A/Bテスト」ツールの国内売れ筋各TOP5を紹介し...