# エージェント修復 ## 定義 エージェント修復(Agent Repair)は、失敗した、または失敗しつつある LLM エージェントの実行を、基盤となるエージェントモデルや環境を変更せずに、事後(post-run)または実行時(run-time)に診断し修正する技術群を指す。[[@2026__arXiv__AgentTether - Graph-Guided Diagnosis and Runtime Intervention for Reliable LLM Agent Operations]] はこれを、自動プログラム修復(automated program repair)や LLM の自己デバッグ(self-debugging)とは異なる問題として明示的に定式化する——後者が固定されたコード成果物とテストオラクルの上で動くのに対し、エージェント修復は「動的・状態を持つ・非決定的な軌跡」を対象とし、失敗にオラクルがなく、原因が遠く上流にあり、外部の状態変化を伴いうるという性質を持つ。 AgentTether はエージェント修復を人間オペレータの修復ループ(recall → diagnose → advise → supervise)を自動化するものとして位置づけ、3 つの構成要素に分解する:(1) グラフ誘導の根本原因分析による診断、(2) 診断を行動範囲限定のガイダンスへ変換し反復をまたいで状態を保持するステートフルな指示、(3) 再実行中にガイダンスの遵守が減衰するのを防ぐ保護付き実行時介入。この 3 要素すべてを備えることが「診断が実際に修復を駆動する」ための必要条件であると AgentTether は主張する(診断だけでは修復されない、という §I の中心的知見)。 [[エージェントシステム運用]] の 4 段階モデル(モニタリング → 異常検知 → 根本原因局所化 → 解決)における「解決」段階の一部を占めるが、AgentTether が示すように「解決」は実行前予防・実行中修正・実行後復旧の 3 クラスに単純に分割できるものではなく、事後診断と実行時介入を**連動させる**ことが鍵となる。 同著者グループの先行研究 PROBE([[@2026__arXiv__Debugging the Debuggers - Failure-Anchored Structured Recovery for Software Engineering Agents]])は、AgentTether が「単一エージェントの意思決定軌跡」を対象にグラフベースで定式化するのに先立ち、失敗した run のテレメトリを Telemetry Layer(構造化収集)・Diagnosis Layer(構造化診断)・Guidance Gate(範囲限定ガイダンスへの決定論的変換)の 3 段パイプラインへ一般化した。PROBE は SWE-bench(コード修復)・EnterpriseOps-Gym(エンタープライズワークフロー)・AIOpsLab(AIOps サービス緩和)という 3 つの異質なソフトウェアエンジニアリング設定を単一スキーマでカバーする点で、AgentTether(τ-bench 単一ベンチマーク)よりもドメイン横断性を先に検証した研究と位置づけられる。 ## 横断的知見 - **一度きりの診断は再実行の展開中に維持されない、という減衰現象が実証的に定量化されている**: AgentTether の Motivation 分析(Finding 2)は、事後フィードバック注入直後のフィードバック追従率が 99% でも、ツール呼び出しステップが進むにつれ急速に減衰し、全体でステップ 13 に、Banking ドメイン(最も長期・制約が厳しい)ではステップ 8 という早さで 50% を下回ることを示した(173 件の post-feedback リラン)。これは「診断を正しく行っても、それを注入するだけでは不十分」という、エージェント修復に固有の課題を裏付ける定量的証拠であり、単発のフィードバックメッセージに頼る自己反省系の手法(Reflexion 等)の限界を説明しうる。(Source: [[@2026__arXiv__AgentTether - Graph-Guided Diagnosis and Runtime Intervention for Reliable LLM Agent Operations]] §II Q2, Figure 3) - **根本原因はエージェントの意思決定軌跡上で症状より大きく上流にあり、直近性ヒューリスティックでは特定できない**: 83 件の τ-bench Banking 初回失敗実行の分析で、挙動的失敗(94%)の根本原因は最も早く違反したゴールドアクションから最終的な失敗まで中央値 4 ステップ(最大 26)離れており、79%(62/78)が症状より厳密に上流にある。この「原因が遠く上流にある」性質は、[[グラフベースRCA]] がマイクロサービス依存グラフ上で扱ってきた「アラームの伝播距離」問題と構造的に類似するが、対象が**単一エージェントの意思決定系列**である点で異なる。TU(Transition Unit)間の依存エッジ(共有アーティファクト・エラーシグネチャ)をたどる非局所的な帰属が、マイクロサービスのサービス依存グラフをたどる帰属と同じ設計原理を、全く異なる粒度(サービス間 vs. 意思決定間)に移植した例といえる。(Source: [[@2026__arXiv__AgentTether - Graph-Guided Diagnosis and Runtime Intervention for Reliable LLM Agent Operations]] §II Q1, Figure 2) - **診断コンポーネントと実行時介入コンポーネントは相補的であり、どちらか一方では効果が頭打ちになる**: コンポーネントアブレーション(Table II)は、オフライン HGT 検出器を除去すると Banking の修復率が 59.04% → 27.71% に、Repair Memory を除去すると 34.94% に低下することを示す。さらに RQ3(Table III)では、実行時介入の効果が Banking(長期・状態変化操作が多い)で有意(+10, p=0.021)である一方、Airline(正当な探索がドリフトと類似しうる)では中立になる。「診断の正確さ」と「実行時の維持」が異なる失敗モードに効くという知見は、単一のメカニズムでエージェント修復を解決しようとする設計(診断のみ・介入のみ)がいずれも部分解にとどまることを示唆する。(Source: [[@2026__arXiv__AgentTether - Graph-Guided Diagnosis and Runtime Intervention for Reliable LLM Agent Operations]] §IV-B, §IV-D) - **過剰介入(over-control)自体が新しい失敗モードになりうる**: AgentTether の Hurt ケース分析(Banking で 3 件)は、同じ Expectation deviation ガードが必須行動の周りで繰り返し発火すると、エージェントが行動を確定させず再計画を続けてしまう逆効果を報告する(平均 29.3 回の介入、Helped ケースの 11.3 回と対照)。これは [[エージェント運用安全性]] が記録してきた「予算と停止規則による過剰情報取得の抑制」の議論(assurance contract の $B$・$S$)と同型の問題を、修復コンテキストで再発見したものと解釈できる——安全性の文脈では「情報取得のしすぎ」が、修復の文脈では「介入のしすぎ」が、どちらも過剰な自律的介入の一形態として現れる。 - **オラクルフリー性が学習ベースの診断コンポーネントを実運用可能にする**: AgentTether のオフライン HGT 検出器は、失敗ラベルを一切使わず(自己教師あり)、対象ベンチマーク(τ-bench)とは独立な外部の成功のみのコーパス(TerminalBench・SWE-smith 等 21,143 軌跡)から正常実行の事前分布を学習する。この設計は、ラベル付き失敗データが恒常的に不足するという AIOps 共通の課題([[LLMによる根本原因分析]] 参照)への一つの解答であり、「正常のみから逸脱を測る」という異常検知の基本パラダイムを、TU 粒度のエージェント軌跡に適用した例である。 - **診断精度と修復(回復)成功率のギャップは、単一手法・単一著者グループの結果ではなく、エージェント修復という問題設定自体に内在する構造的性質である可能性が高い**: PROBE は 257 件の初回未解決ケースで Top-1 診断精度 65.37%・recovery rate 21.79% を報告し、診断精度の改善幅(+43.58pt)が回復率の改善幅(+12.45pt)を大きく上回る「diagnosis–recovery gap」を明示的に定式化した。AgentTether が「PROBE は障害カテゴリの特定精度は高いが修復率が低い」と先行研究として位置づけていた記述([[@2026__arXiv__AgentTether - Graph-Guided Diagnosis and Runtime Intervention for Reliable LLM Agent Operations]] §VI)は、PROBE 自身の自己分析と整合する。さらに AgentTether のフィードバック追従率減衰(diagnosis 直後 99% → ステップ 13 で 50% 未満)という知見と PROBE の診断–回復ギャップは、**現象としては異なる測定軸(時間経過に伴う遵守の減衰 vs. カテゴリ別の診断的中と実行成功の乖離)でありながら、「正しい診断は実行可能な回復の必要条件だが十分条件ではない」という同一の構造的主張に収斂する**。2 つの独立した測定(recovery rate ギャップと feedback-following 減衰)が同じ結論を支持することは、この構造的ギャップがエージェント修復という問題設定の本質的な難しさであることを強く示唆する。(Source: [[@2026__arXiv__Debugging the Debuggers - Failure-Anchored Structured Recovery for Software Engineering Agents]] §4.2, §6; [[@2026__arXiv__AgentTether - Graph-Guided Diagnosis and Runtime Intervention for Reliable LLM Agent Operations]] §II Q2, §VI) - **障害カテゴリによって「診断のしやすさ」と「修復のしやすさ」が乖離するパターンが再現している**: PROBE のカテゴリ別結果(Table 3)は、state/workflow error が診断一致 83.33% と高精度でありながら回復率はわずか 14.29% にとどまることを示し、「不正な状態を認識することは、同じ実行予算内でそれを修復することより易しい」と結論づける。これは AgentTether のコンポーネントアブレーション知見(診断コンポーネントと実行時介入コンポーネントが相補的で、どちらか一方では効果が頭打ちになる)と整合的であり、両論文とも「診断の質」と「修復の実行可能性」を単一のメカニズムで同時に解決できないことを異なる評価軸から裏付けている。 - **範囲限定(bounded)なガイダンス生成という設計は、両論文で独立に収斂した解法である**: PROBE の Guidance Gate(target・operation・verification signal・boundary condition の 4 要素を要求する Actionability Filter)と AgentTether の行動範囲限定ガイダンス(bounded, in-scope guidance)は、「診断をそのまま行動指示に変換すると根拠のない介入になりうる」という同じ懸念に対して、同一著者グループが**時系列的に連続する 2 つの論文**で同じ設計原理(grounding + actionability + scope の検証)へ収斂した例である。PROBE ではこれが決定論的なゲート(LLM を介さないルールベースの検証層)として実装されている点が、AgentTether の実行時介入(HGT 検出器 + Repair Memory)よりも軽量で監査しやすい設計になっている。 - **産業統合における「非侵襲的 side channel」という設計原則も両論文で共有される**: PROBE は Microsoft IcM のサービス診断エージェントワークフローへ、エージェントのポリシー・ツールセット・実行予算を変更せずに接続するプロトタイプを検証した(§5)。これは AgentTether が Repair Memory やガードを実行時介入として組み込む設計とは異なり、より保守的な「観測してレポートを添付するだけ」の統合形態だが、いずれも「エージェントの信頼された実行パスの外側にとどまる」という同一の産業適用原則を共有する。 ## 未解決の問い - 介入強度をドメインリスク・タスクフェーズ・モデル能力に適応させる設計は AgentTether の著者ら自身が将来課題として残している。Hurt ケースが示す「ガードの反復発火 → 再計画ループ」をどのような形式的基準で事前に検知・抑制できるか。[[エージェント運用安全性]] の予算・停止規則の形式化(assurance contract)を修復介入の文脈に持ち込めるか。 - AgentTether は τ-bench という単一ベンチマーク・3 ドメインでの評価にとどまる。コード生成・マルチエージェント協調([[マルチエージェント協調]])・本番オブザーバビリティへの一般化は未検証。特にマルチエージェント系では「どのエージェントの、どの TU が根本原因か」という帰属問題が単一エージェントの CTG よりも複雑になるはずで、Critical Transition Graph をエージェント間にどう拡張するかは開いた設計問題である。 - 診断・検証の両方に補助 LLM(アナリスト・検証者)を用いており、これらの判断への依存自体は解消されていない。CTG に基づくグラフアルゴリズムのフォールバックでこの依存をどこまで軽量化できるか。 - PROBE と AgentTether はいずれも「初回試行 1 回 + 修復試行 1 回(または反復)」という単発〜少数回の回復プロトコルで評価されている。PROBE 自身も「単発の回復可能性を測るのみで、複数ラウンドの反復回復の実践的な上限は未検証」と限界を認める(§6)。複数ラウンドの反復回復では diagnosis–recovery gap は解消されるのか、それとも累積するのか——AgentTether のフィードバック遵守減衰の知見(ステップが進むほど遵守率が下がる)を踏まえると、単純な反復回数の増加だけでは解決しない可能性が高く、検証されていない。 - PROBE は診断精度改善(+43.58pt)が回復率改善(+12.45pt)を上回る現象を実証したが、この非対称性を埋める一般的な設計原理は何か。PROBE は Guidance Gate(grounding/actionability/scope)、AgentTether は Repair Memory + 保護付き実行時介入でそれぞれ部分的に埋めているが、いずれも診断–回復ギャップを完全には解消していない(PROBE の recovery rate は診断一致率の 3 分の 1 程度にとどまる)。この非対称性は評価プロトコルの制約(固定実行予算)に起因するのか、それとも修復自体の本質的な難しさ(診断以上の情報が必要)に起因するのか、両論文からは切り分けられない。 - PROBE は診断モデル(Claude Sonnet 4.5)とタスク実行モデル(Qwen3.5-Plus)を分離しており、「recovery が診断モデル能力にどれだけ依存するか」は著者ら自身も未定量化と認めている(§6)。同一モデルでの診断・実行アブレーションが行われれば、diagnosis–recovery gap のうちどこまでが「モデル能力の問題」でどこまでが「パイプライン設計の構造的限界」かを切り分けられる可能性がある。 ## 関連 - ソース: [[@2026__arXiv__AgentTether - Graph-Guided Diagnosis and Runtime Intervention for Reliable LLM Agent Operations]] / [[@2026__arXiv__Debugging the Debuggers - Failure-Anchored Structured Recovery for Software Engineering Agents]] - 概念: [[エージェントシステム運用]] / [[エージェント運用安全性]] / [[グラフベースRCA]] / [[LLMによる根本原因分析]] / [[マルチエージェント協調]] - エンティティ: [[Chenyu Zhao]] / [[Shenglin Zhang]] / [[Dan Pei]] / [[Chetan Bansal]] / [[Saravan Rajmohan]] / [[Minghua Ma]] / [[Wenwei Gu]] / [[Yongqian Sun]] / [[Nankai University]] / [[Tsinghua University]] / [[Microsoft]] / [[AIOpsLab]] - 関連 MOC: `structures/` の AIOps・SRE 系 MOC(未リンク、人間承認待ち) ## 出典 - [[@2026__arXiv__AgentTether - Graph-Guided Diagnosis and Runtime Intervention for Reliable LLM Agent Operations]](§I Introduction のエージェント修復の定式化、§II Motivation の Finding 1/2、§III-A〜D の手法、§IV-B〜D の評価、§V Discussion) - [[@2026__arXiv__Debugging the Debuggers - Failure-Anchored Structured Recovery for Software Engineering Agents]](§1 Introduction の 3 課題の定式化、§3 PROBE の Telemetry/Diagnosis/Guidance Gate 3 層、§4 RQ1〜RQ3 の評価、§5 Microsoft IcM プロトタイプ、§6 Discussion and Limitations)