AI SRE障害調査のevidence-grounded diagnosis／誤診・棄権評価

AIをSREの障害調査へ投入する場合、評価すべき対象は「もっともらしい根本原因を説明できるか」だけではない。運用上重要なのは、観測可能な証拠から原因候補をどこまで絞り込めたか、競合仮説やデコイを排除できたか、証拠不足のときに誤って断定せず棄権・追加観測へ移れたか、そして修復を行う場合に安全性を検証できたかである。したがってAI SREの診断品質は、evidence-grounded diagnosis、false attribution、abstention、missing telemetry、remediation verificationを分離して評価する必要がある。

障害時のログ、メトリクス、トレース、構成変更、デプロイ履歴、依存関係、アラートは、同じ症状に対して複数の原因仮説を支持し得る。AIが相関だけで原因を断定すると、症状に近いコンポーネントや直近変更を誤って根本原因とみなす危険がある。診断結果には、少なくとも「どの観測が仮説を支持するか」「どの観測が競合仮説を弱めるか」「観測されていない情報は何か」を残すべきである。

SREBench系の環境には、疑わしいデプロイが実際の根本原因ではないデコイを含め、単純なパターン一致ではなく因果的な切り分けを要求する設計がある。SREGymも、複数レイヤの故障、ambient noise、metastable/correlated failureを含む高忠実度のfailure drillを重視している。これらは、AI SRE評価で「正答したか」だけでなく、ノイズや紛らわしい証拠の下で診断を維持できるかを測る必要性を示す。

false attributionは、障害症状と同時に観測されたイベントを根本原因へ短絡することで起きる。代表例は、直近deploy、CPU高騰、特定podのrestart、下流serviceのerror増加などを、反証確認なしに原因へ昇格させるケースである。

運用評価では、正しいroot causeの命中率だけでなく、誤った原因を確信付きで提示した割合を別に追跡するべきである。誤診は単なる「不正解」ではなく、誤ったrollback、restart、configuration change、traffic shiftなどの介入につながるためである。特に自動修復を許可する設計では、診断誤りと操作リスクを掛け合わせて評価する必要がある。

証拠が足りない状態での棄権は失敗ではない。診断に必要なtelemetryが欠けている、複数仮説が同程度に残る、観測が相互矛盾する、対象環境の権限やtool coverageが不足する場合、AIは「原因確定」と「追加調査が必要」を区別すべきである。

AURORAの研究では、因果信頼度とepistemic uncertaintyに基づく二重gateを用い、条件を満たさない場合はlocal remediationを棄権して上位tierへdiagnostic payloadを送る設計が提示されている。これは特定方式の一般的優位を保証するものではないが、運用設計上、abstentionを明示的な成功経路として扱えることを示す。

評価指標には、少なくとも次を分離する必要がある。

• correct diagnosis: 十分な証拠に基づき正しい原因へ到達した。
• false attribution: 誤った原因を確定的に提示した。
• justified abstention: 証拠不足を認識し、必要な追加観測または人間へのescalationを示した。
• unnecessary abstention: 診断可能な証拠があるのに判断を放棄した。
• unsafe action: 診断確度や安全条件が不足したまま変更操作へ進んだ。
• verified recovery: 変更後に症状消失だけでなく、要求された機能・健全性を再検証した。

2026年のSRE系benchmarkは、live system、fault injection、Kubernetes、microservice、functional verifierなど現実性を高める方向へ進んでいる。一方で、環境、tool set、telemetry、fault distribution、judge、time/token budgetはbenchmarkごとに異なる。Incident-Arenaは実運用に近いephemeral Kubernetes環境とfunctional verifierを採用しつつ、20 tasksでのfrontier agent成績が64.3%未満と報告している。SREGymは90の問題を持ち、fault/noiseの種類によってend-to-end能力に大きな差が出ると報告している。

したがって、特定benchmarkの高得点を「本番障害の診断精度」や「自動修復の安全性」の保証として扱ってはならない。ベンチマーク結果は、対象fault class、観測可能性、操作権限、採点条件、再試行条件を伴う限定的な証拠として扱う。

本番導入では、診断と変更操作を同一権限で直結させない。少なくとも、read-only investigation、hypothesis/evidence記録、confidence/uncertainty判定、change approval、bounded remediation、post-action verificationを分離する。AIが使用した証拠とtool resultを監査可能に残し、原因仮説と実施操作の対応を追跡できるようにする。

特に自動操作を許す場合は、reversibleでscopeの狭い操作から始め、変更前condition、変更対象、rollback条件、変更後verificationを固定する。観測不足や競合仮説が残る場合は、人間承認または追加観測へ戻す。診断agentが「解決した」と宣言したこと自体をrecoveryの証拠にしない。

この設計でも、telemetry自体が誤っている場合、観測経路が欠落している場合、複数障害が同時発生する場合、権限不足で必要なtoolを使えない場合、未知のfailure modeの場合には診断不能になり得る。また、LLM judgeを含む評価はjudge biasや採点仕様の影響を受ける。sandboxで安全だったremediationが本番のデータ量、依存関係、traffic、組織固有policyの下でも安全とは限らない。

「AI SREは障害原因を自動的に特定できる」と一般化しない。安全な表現は、「特定の観測・tool・fault distributionの下ではAI agentが障害診断と修復を実行できる例があるが、本番利用では証拠追跡、誤診評価、棄権、権限制御、変更後検証を独立して設計・評価する必要がある」である。

• benchmark上の診断能力が、各組織固有のtelemetry品質・runbook・権限モデル・障害分布へどの程度transferするか。
• 長期運用でのfalse attribution率、unnecessary abstention率、human escalation負荷。
• compound incident、partial observability、stale telemetry、tool failureが同時に起きた場合の安全境界。
• ベンダー固有agentの公開benchmark結果と、商用構成・tenant固有設定の性能差。
• 診断agentとremediation agentを分離した場合の総合的なMTTR、安全性、運用コストのトレードオフ。

• SREGym: A Live Benchmark for AI SRE Agents with High-Fidelity Failure Scenarios, arXiv:2605.07161 / ACM CAIAS 2026. https://arxiv.org/abs/2605.07161
• Incident-Arena: Getting agents to the last nine of reliability, arXiv:2610.00648, 2026-09-30. https://arxiv.org/abs/2610.00648
• An Uncertainty-Aware Resilience Micro-Agent for Causal Observability in the Computing Continuum (AURORA), arXiv:2605.10718, 2026-05-11. https://arxiv.org/abs/2605.10718
• SRE-Bench README (deterministic incident environment; red-herring scenario; investigation/remediation lifecycle). https://github.com/himashree56/SRE-Bench
• Parity SREBench About (simulated cluster state and LLM-judge limitations are material to interpretation). https://sreben.ch/about
• Arvo Aurora repository (product/OSS implementation context; not independent efficacy evidence). https://github.com/Arvo-AI/aurora
• Arvo comparative Kubernetes benchmark (vendor-authored; self-curated scenario limitation must be retained). https://www.arvokas.io/benchmark