> [!abstract] 概要(abstract 和訳) > LLM の推論能力が向上し続けるにつれて、LLM ベースのエージェントシステムは従来のシステムに対して柔軟性と解釈可能性において優位性を発揮し、注目を集めている。しかし、エージェントシステムは広く研究・産業応用されているにもかかわらず、従来のシステムと同様に異常に頻繁に遭遇する。これらの異常は不安定性と非安全性をもたらし、さらなる発展を妨げている。そのため、エージェントシステムの運用・保守に対する包括的かつ体系的なアプローチが急務である。残念ながら、エージェントシステムの運用に関する現行の研究は乏しい。このギャップに対処するため、我々はエージェントシステム運用に関するサーベイを実施し、分野の明確なフレームワークを確立し、課題を定義し、さらなる発展を促進することを目的とした。具体的には、本論文はまずエージェントシステム内の異常を体系的に定義し、エージェント内(intra-agent)異常とエージェント間(inter-agent)異常に分類する。次に、エージェントシステムのための新規かつ包括的な運用フレームワーク AgentOps を導入する。本論文はその 4 つの主要段階——モニタリング・異常検知・根本原因局所化・解決——の詳細な定義と説明を提供する。 ## 論文情報 - **タイトル**: Agent System Operations: Categorization, Challenges, and Future Directions - **著者**: [[Zexin Wang]], [[Changhua Pei]](連絡著者), Yuanhao Liu, Jingjing Li, [[Yintong Huo]], Quan Zhou, Haotian Si, Hang Cui, Zihan Liu, Jianhui Li, Gaogang Xie, Fei Sun, [[Dan Pei]], [[David Lo]] - **所属**: CNIC CAS・杭州高等研究院 UCAS / Tsinghua University / ICT CAS / Singapore Management University / UCAS - **掲載誌**: IEEE Transactions on Software Engineering(採択済み・刊行待ち。VOL. 00, NO. 0) - **arXiv**: arXiv:2606.01581v1 [cs.MA]、2026-06-01 投稿 - **連絡先**: Changhua Pei ([email protected]) - **資金**: 国家自然科学基金(62202445)、RGC 共同研究スキーム(62321166652) ## 概要 本サーベイは LLM エージェントシステムの運用・保守(O&M)に特化した最初の体系的フレームワーク「AgentOps」を提案する。エージェントシステムが異常に頻繁に遭遇し(例: SWE-Agent のタスク成功率が 40% 未満)不安定性・非安全性につながるという問題意識から、異常分類 → モニタリング → 異常検知 → 根本原因局所化 → 解決 という 4 段階の運用ライフサイクルを定義し、各段階の既存手法・課題・将来方向を整理する。AgentOps は **AgenticOps**（エージェントを使って従来システムを運用する）とは区別され、エージェントシステム**を**運用対象とする。 ## 問題設定 - **入力**: LLM エージェントシステムの実行データ(メトリクス・ログ・トレース・モデルデータ・チェックポイント) - **出力**: 運用の健全性保証——異常の検知・箇所特定・解決 - **前提**: エージェントシステムは確率的 LLM ベースで動き、実行軌跡が意味的・動的・構造的に従来システムと本質的に異なる。主流の ReAct パラダイムを前提とするが、複数エージェントの協調では通信・依存・オーケストレーション障害が追加発生する。 ## エージェントシステムにおける異常の分類(Section II) Figure 2 が実行フェーズ(pre-execution・execution・post-execution)× Intra-Agent / Inter-Agent の 2 軸で分類タクソノミーを整理する。 ### Intra-Agent 異常(個々のエージェント内部) **推論異常(Reasoning Anomalies)**: エージェントの後続行動を導く認知基盤の障害。幻覚が最も代表的。定義は多様——「既知の事実に矛盾する生成」(Rawte et al.)・「元プロンプトと無関係な応答」(Gallifant et al.)・コンプライアンス/望ましさ/関連性/もっともらしさの 4 特性での分類(Chakraborty et al.)・「根拠のない自信を持つ不誠実な回答」(Yang et al.)。訓練データへの感度・知識の忘却・新知識の非同期組み込みが原因で根絶困難。 **行動異常(Action Anomalies)**: ツール呼び出し・関数呼び出しの実行失敗。インターフェース不整合・誤 API 選択・遅延実行・不正パラメータ・システムレベル障害から生じる。MCP はインターフェースを標準化するが異常を完全には排除しない。攻撃者がジェイルブレークプロンプトで関数呼び出し機構を悪用するリスクもある(Wu et al.)。 **メモリ異常(Memory Anomalies)**: - **短期**: コンテキストウィンドウ制限(lost-in-the-middle / PI で位置埋め込み拡張 / CoA でマルチエージェント協調チャンク管理) - **長期/RAG**: 不正確な想起・ノイズ証拠・幻覚生成に脆弱。QE-RAG はノイズ感度、Astute RAG は内部知識と外来知識の対立を指摘。Chen et al.は技術的改善にもかかわらず RAG の精度が依然限定的と指摘。 **セキュリティ異常(Security Anomalies)**: プロンプトインジェクション・権限外ツール呼び出し・認証情報の誤用・不正身元での実行。敵対的入力・悪意あるツール出力・侵害された外部環境から誘発される。多エージェント環境では「侵害エージェントが間接的に他エージェントを不正行動させる」権限伝搬も発生。 ### Inter-Agent 異常(複数エージェント間) **タスク仕様異常(Task Specification Anomalies)**: ユーザー目標・タスク制約・エージェント役割・設定が曖昧/不完全/矛盾。不適切なロール設定は協調失敗・敵対的整合ずれ・プロンプトインジェクション脆弱性につながる(Pan et al., Platon et al.)。 **オーケストレーション異常(Orchestration Anomalies)**: 大域計画プロセスの障害——サブタスクの欠損・重複・エージェント-ツール不整合・依存関係の循環・不正ワークフロー・制約/セキュリティポリシー違反計画。単一エージェントの問題ではなく、不適切なグローバル協調・不完全なタスク理解・不安定な計画判断から出現する。 **通信異常(Communication Anomalies)**: エージェント間メッセージ交換の障害。Bronsdon がメッセージストームを典型的失敗モードとして挙げる(資源枯渇・遅延増加・タスク失敗)。AgentPrune は冗長メッセージが性能向上でなく協調効率の低下をもたらすことを観測する。 **終了異常(Termination Anomalies)**: タスク完了・結果妥当性の誤判定。 - 早期終了(premature termination): DFSDT が終了ツールを早期に呼び出す(Pan et al., Microsoft) - 過剰委任(undercommitment): エージェントがサブエージェントへタスクを繰り返し委譲して再帰無限連鎖に陥る(Zhu et al.) - Drake の「neural howlround」: 再帰的自己最適化ループで明確な終了点なしに停滞 ## AgentOps フレームワーク(Section III) **定義**: エージェントシステムの信頼性・安全性・制御可能性を維持するための運用技術の体系。 **AgenticOps との区別**: AgenticOps はエージェントを使って**従来システムを**保守する(Cisco の定義)。AgentOps はエージェントシステム**自体を**保守する(Table I)。 **運用の進化軸**(Figure 5): - 技術軸: 手動介入 → 自動化 → オブザーバビリティ → 知的分析 → 自律性 - 対象軸: 従来 IT インフラ → クラウドネイティブアプリ → AI/ML システム → エージェントシステム - SRE → AIOps → MLOps → **AgentOps** の順に対象が拡張 **従来 DevOps との比較**(Table II): | 段階 | DevOps | AgentOps | |---|---|---| | 異常検知(プロセス検証) | テキストログの逐次ブレーク検出 | 不確実性・幻覚シグナルの検出 | | 異常検知(ヘルスモニタリング) | インフラメトリクスの異常検知 | ループ・異常行動・軌跡逸脱の検出 | | 異常検知(出力検証) | フォーマット・閾値チェック | セマンティクスの LLM-as-a-judge チェック | | 根本原因局所化 | 依存グラフの静的障害局所化 | 欠陥行動/推論ループの局所化と軌跡追跡 | | システム復旧 | 事前定義 runbook の実行 | 自己修正と迅速な再評価 | | 状態ロールバック | 静的 DB スナップショットのロールバック | 直前の安定チェックポイントへのエージェント状態復元 | **解決の根本的差異**: 従来はポスト実行段階の事後対応が中心。LLM の確率的性質から障害が頻繁・予測困難なエージェントシステムでは事後対応への依存では運用負荷が過大になるため、実行前・実行中の段階介入で障害を事前防止・即時修正することを重視する。 ## モニタリング(Section IV) 従来のメトリクス・ログ・トレースに加えて**モデルデータ**と**チェックポイントデータ**が必要。 **4 種のメトリクス**: システムメトリクス(インフラ) / APM メトリクス(アプリ) / コスト関連メトリクス(API コスト・トークン消費) / RAG 関連メトリクス(検索精度・キャッシュヒット率) **トレースの本質的差異** (Figure 8): マイクロサービストレース(サービス間 API 呼び出しの安定した構造的パス)に対し、エージェントシステムのトレースは各エージェント・各ステップでの入出力と推論の高い不確実性を含む**意味的決定パス**。Figure 8 が両者の比較を示す。 **モデルデータ**: アテンションマップ・トークンロジットなどの内部状態。オープンソース LLM のローカル展開増加で白箱モデルデータの収集が現実的になった。LLM 自体から発生する推論・生成の異常を検知するために必要。 **チェックポイントデータ**: エージェントの実行状態(メモリ・環境・中間結果・実行情報)を定期保存。異常検知時に直前の安全チェックポイントにロールバックし修正フィードバックを組み込んで再実行(Figure 10)。LangGraph がチェックポイントとタイムトラベル実行をサポート。 **観測可能性ツール**(Table III 代表 15 種): LangDB / LangFuse / MLflow / Helicone / LlamaTrace / OpenLLMetry / Arize Phoenix / Literal AI / Opik / OpenInference / TruLens / LangWatch / HoneyHive / PromptLayer / AgentOpsMonitor / DeepEval / LangSmith **将来方向**: モデルデータとチェックポイントデータへの拡張。ハルシネーション確率やトークンレベル不確実性など「潜在的障害をより直接的に反映するリスク指向シグナル」が次の重要領域。 ## 異常検知(Section V) Table IV が異常種別 × 手法カテゴリ × 入出力 × 検知/緩和可否を網羅的に整理。 **推論異常検知**: 白箱/灰箱/黒箱の 3 方向 - **白箱**: SPALMA(LLM パラメータからゼロショット検知)、OPERA(アテンションマップの「部分的過信」を列方向メトリクス+確率的ペナルティ+ロールバックで緩和)、Honesty(IDK 応答 + 教師ありファインチューニング) - **灰箱**: LURE(トークンロジットから 3 原因を分析しサンプル生成して訓練)、Conformal(Conformal Prediction でトークン列ロジットから品質算出し停止規則で廃棄) - **黒箱**: Debate(複数モデルインスタンスの反復評価・更新)、CoK(複数外部知識源からの積極的クエリと推論連鎖の反復修正) **行動異常検知**: AI-Intra-Guard / MCP Guardian(ともに MCP リスクを検知) **メモリ異常検知**: PI・CoA(短期) / ReDeep・LRP4RAG(長期/RAG) **セキュリティ異常検知**: GUARDIAN(エージェントグラフをエンコーダ-デコーダで圧縮・再構成し再構成スコアで検知)、SentinelAgent(3 層階層型、グローバル→詳細) **タスク仕様異常検知**: 分類器ベース(Ambig-SWE / Semantic Entropy / SelfCheckGPT)、不確実性ベース(Ask-or-Assume / CLAMBER) **オーケストレーション異常検知**: - 単一ステップ: Introspective / API-bank / ReAct - マルチステップ: ToolLLM(depth-first 探索ベースデシジョンツリー) / Reflexion(外部フィードバック + 自己生成単体テスト) / CodeAct(計画を Python コードとして定式化) **通信異常検知**: AgentPrune(グラフ最適化で冗長通信削減) / G-Designer(グラフニューラルネットワークでトポロジー設計) **将来方向**: カテゴリをまたいだ統合・汎用化検知フレームワーク / クロスレベル検知(エージェント内→システムレベルの異常伝搬の共同モデル化) / 長期タスクのオンライン検知 ## 根本原因局所化(Section VI) AgentOps における根本原因局所化 = **失敗帰属(failure attribution)**: どのコンポーネントがどの時点で異常を初めて引き起こしたかを実行トラジェクトリに沿って特定する。Figure 11 が示すように、コンテキスト長が増えると LLM ベース手法の精度は低下するが非 LLM ベースは安定。 **Table V カテゴリ別整理**: **カテゴリ 1: トラジェクトリ再生・スペクトル分析** - 成功/失敗トラジェクトリ比較・状態-行動-エージェントタプル・統計的疑惑度 - FAMAS: スペクトル分析フレームワーク——実行ログをタプルに分解し失敗頻度・内部反復性・行動中心性を考慮するハイブリッドスコアリング関数でランキング **カテゴリ 2: 因果・構造的トレースモデリング** - GraphTracer: 情報依存グラフでエージェント間情報フローを明示的にモデル化し後方追跡でルートノードを特定。時系列レベルの因果性を超える - AgenTracer: 逆事実的再生と障害注入で合成トラジェクトリを生成し、専用小型 LLM を訓練して Who(誰)と When(いつ)の局所化を学習 - Ma et al.: 構造的因果グラフ + 逆事実推論でシステムレベル障害をエージェントと行動に帰属 **カテゴリ 3: LLM ベース帰属** - Who&When: 3 パラダイム——All-at-once(完全ログを単一パスで処理) / Step-by-step(ログセグメントを逐次入力し即時終了) / Binary Search(ログ区間の再帰二分割で LLM 判断によりエラースパンを絞り込む)。LLM の意味推論の利点は非構造化ログでの soft な推論 - AgentFail: LLM が複雑トラジェクトリの推論に苦労することを観測。タクソノミーの LLM への組み込みで局所化識別精度が約 15% 向上 - AgentDebug: タクソノミー認識分析で各ステップでのエージェント挙動を共同評価し失敗を検知してトラジェクトリを再計画 **将来方向**: 2 段階フレームワーク——第 1 段階で非 LLM モデルが疑惑領域を絞り込み、第 2 段階で LLM-as-a-Judge を適用。本論文は VAE 再構成 + LLM-as-a-Judge の試作で大半の手法が改善を示すと報告。 ## 解決(Section VII) 3 クラス × 複数手法(Table VI が各手法の対象異常種別を整理): **実行前予防的解決(Pre-execution Preventive Resolutions)**: - タスク再仕様(Task Re-specification): 曖昧目標の明確化・複雑目的の分解・成功基準の追加。CoT・ReAct・ToT が利用される - 計画検証(Plan Verification): ルールベースバリデータ・クリティックモデル・検証エージェント・人間承認による実行前チェック。AutoGen のプランナー-クリティック-実行者パターン - 行動空間制限(Action Space Restriction): 型付きツールスキーマ・サンドボックス・権限境界の定義。Toolformer と SWE-agent はツールインターフェース設計が信頼性に大きく影響することを示す **実行中修正的解決(In-execution Corrective Resolutions)**: - 観測グラウンデッド再計画(Observation-grounded Replanning): 環境フィードバックに基づく計画改訂。ReAct が代表例 - 自己修正(Self-correction): 実行中の間違い自己発見と修復。Self-Refine と Reflexion が反復フィードバックで外部パラメータ更新なしに改善 - 冗長実行と選択(Redundant Execution and Selection): 複数候補行動の生成と投票・ランキング・検証スコアリングによる最良選択。マルチエージェント討議・アンサンブル実行で使用 **実行後復旧的解決(Post-execution Recovery Resolutions)**: - ロールバックと再実行(Rollback & Re-execution): 直前チェックポイントへの復元と修正制約での再実行。LangGraph がタイムトラベル実行をサポート - メモリとスキルの更新(Memory & Skill Update): 失敗/成功実行後に経験・修正手順・再利用スキルを蓄積。Reflexion(言語的フィードバックのメモリ保存)・Voyager(スキルライブラリ構築) - ポリシーとプロンプトの改訂(Policy & Prompt Revision): 繰り返す弱点に対してプロンプト・ポリシー・ツールスキーマを実行後改訂。自動プロンプト最適化・進化的プロンプト探索 ## データセットとベンチマーク(Section VIII) Table VII: | データセット | 障害数 | 種別数 | 対象システム | |---|---|---|---| | Who&When | 184 | - | 127 多エージェント LLM システム | | MASFT | 1642 | 14 | ChatDev / MetaGPT / HyperAgent / AppWorld / AG2 / Magentic-One / OpenManus | | TRAIL | 841 | 21 | - | | AgentFail | 307 | 16 | Dify / Coze | | Aegis | 24843 | 14 | LLM Debate / MacNet / AgentVerse / Dylan / SmolAgents / Magentic-One | | AgentDebug | 200 | 17 | ALFWorld / WebShop / GAIA | Table VIII が各ベンチマークの異常タクソノミーカバレッジを示す。大半は Intra-Agent に集中し Inter-Agent 異常のカバレッジが不十分。LLM-as-evaluator に依存する評価が多い。 3 つのトレンド: (1) 障害インスタンス数の増加、(2) 障害タイプの多様化、(3) 自動データ生成・アノテーションへの移行。 ## 強み / 弱点・課題 **強み**: - LLM エージェントシステムの O&M に特化した最初の包括的フレームワーク提案 - Intra-Agent / Inter-Agent の 2 軸タクソノミーが既存研究の盲点(通信・終了異常)を整理 - DevOps / AIOps との対比可能な形で 4 段階運用サイクルを体系化 - ベンチマーク 6 種の異常タクソノミーカバレッジ比較 **弱点・課題**: - 新手法の提案ではなくサーベイとフレームワーク提案にとどまる - モニタリングと解決のベンチマーク化は依然困難(システム計装・展開環境依存) - 評価の大多数がエージェントレベル・ステップレベル精度という粗い指標に依存 - Inter-Agent 異常のベンチマークカバレッジが不十分(Table VIII) - 多くの既存手法がカテゴリ固有で異なる入力粒度・検知仮定に依存しており統合が困難