# エージェントシステム運用 ## 定義 エージェントシステム運用(Agent System Operations, AgentOps)は、LLM ベースのエージェントシステムの**信頼性・安全性・制御可能性**を維持するための運用技術の体系である。[[AIOps]] の子領域として位置づけられるが、従来の AIOps がマイクロサービスやクラウドインフラを対象とするのに対し、AgentOps はエージェントシステム**自体**を運用対象とする。([[@2026__arXiv__Agent System Operations - Categorization, Challenges, and Future Directions]]) **AgenticOps との区別**: AgenticOps(Agentic Operations)はエージェントを使って**従来のシステムを**保守する取り組み。AgentOps はエージェントシステム**を**保守する——対象と手段が逆転している(Table I)。 AgentOps は 4 つの主要段階で構成される: 1. **モニタリング**: メトリクス・ログ・トレース + モデルデータ(アテンションマップ・トークンロジット) + チェックポイントデータ 2. **異常検知**: Intra-Agent / Inter-Agent の 2 軸タクソノミーに沿った検知 3. **根本原因局所化**(= 失敗帰属): トラジェクトリ再生・因果トレース・LLM 裁定の 3 カテゴリ 4. **解決**: 実行前予防 / 実行中修正 / 実行後復旧の 3 クラス ## 横断的知見 - **AgentOps は SRE → AIOps → MLOps の延長線上に位置するが、「確率的 LLM が実行エンジン」という前提で既存手法の適用範囲が制限される**: [[AIOps]] は検知・箇所特定・RCA・緩和の 4-level taxonomy を確立し、[[agentic SRE]] はそれをクラウド SRE の文脈で具体化した。AgentOps は同じ 4 段階(監視→検知→局所化→解決)を持つが、監視対象がメトリクス/ログ/トレースを超えてモデルデータ・チェックポイントデータへ拡張され、異常検知の正解定義が「統計的逸脱」でなく「意味的タスク失敗」に移る。Figure 6 が示すように、トレースが構造的実行パス(マイクロサービス)から意味的決定パス(エージェント)へと変化することが差異の核心。(Source: [[@2026__arXiv__Agent System Operations - Categorization, Challenges, and Future Directions]]) - **エージェント間(Inter-Agent)異常は既存研究でほぼ未整備で、AgentOps の最大の新規貢献**: 本 wiki の [[AIOps]]・[[agentic SRE]]・[[根本原因分析]] は主にサービス障害・マイクロサービス RCA を扱い、単一エージェントの異常(幻覚・行動エラー)が時折言及されてきた。本サーベイが初めてエージェント間の 4 種の異常タイプ(タスク仕様・オーケストレーション・通信・終了)を体系化し、Table VIII が示すように既存ベンチマーク 6 種はすべて Intra-Agent に偏りエージェント間異常のカバレッジが不十分であることを定量的に示す。本 wiki の [[エージェント運用安全性]] が扱う「検証ゲート」は Intra-Agent の行動異常とセキュリティ異常への対処が主で、Inter-Agent のオーケストレーション異常や通信異常への対処設計は未整備——AgentOps の提供するタクソノミーが足場になる。(Source: [[@2026__arXiv__Agent System Operations - Categorization, Challenges, and Future Directions]]) - **「実行前予防」が AgentOps の解決で最も重要な新方向として浮上する**: 本 wiki の [[根本原因分析]]・[[障害緩和]] は主に障害発生**後**の診断・回復を扱う。AgentOps は LLM の確率的性質から「事後対応だけでは運用負荷が過大」として、Task Re-specification・Plan Verification・Action Space Restriction という実行前予防クラスを前面化する。[[エージェント運用安全性]] が提案する保証契約 `Ck` の `Gk`(迂回不能ゲート)・Plan Verification・Action Space Restriction は、AgentOps の実行前予防クラスの具体実装として読み直せる。3 つの視点——AgentOps(フレームワーク)・[[エージェント運用安全性]](形式装置)・[[agentic SRE]](能力評価)——が「実行前に契約を確認し、違反を防ぐ」という同一原理を異なる粒度で記述する。(Source: [[@2026__arXiv__Agent System Operations - Categorization, Challenges, and Future Directions]], [[@2026__arXiv__Large Language Models for Agentic NetOps and AIOps - Architectures, Evaluation, and Safety]]) - **AgenticOps の産業実証: [[Bian Que]] は「コンテキスト組み立て」をエージェントから分離することで従来システム O&M の自動化に成功した**: AgentOps サーベイが分類する AgenticOps(エージェントを使って従来システムを保守)の代表的産業実装として [[Bian Que]] が挙げられる。Bian Que は推論エンジンとしての LLM の性能が十分でも、適切なデータ・知識を選択するオーケストレーション能力が律速であるという根本認識から、Skill という外在化されたコンテキスト仕様を導入した。この設計は AgentOps サーベイが Intra-Agent 異常として挙げる「意図漂流(幻覚・無関係情報への固着)」を構造的に抑止する機構として解釈できる——エージェントが「何を調べるか」を自由に推論する代わりに Skill が事前拘束するからである。KuaiShou の 6 ヶ月本番デプロイでアラート量 75% 削減・RCA 精度 80% を達成し、AgenticOps のスケール実証として重要な参照点となる。(Source: [[@2026__arXiv__Bian Que - An Agentic Framework with Flexible Skill Arrangement for Online System Operations]] §1, §2, §3.2) - **LLM アプリケーション失敗モード分類は AgentOps の監視対象を具体化する**: [[@2026__IEEE CAI__A System-Level Taxonomy of Failure Modes in Large Language Model Applications]] は、推論失敗、入力/コンテキスト失敗、システム/運用失敗の 3 層で、計画崩壊、コンテキスト喪失、競合指示、ツール/API エラー、マルチエージェント通信破綻、コスト起因劣化を列挙する。AgentOps サーベイが示す監視→異常検知→根本原因局所化→解決の 4 段階は、これらを運用上の検知対象と復旧対象に変換する枠組みとして読める。特に Inter-Agent 異常は、CAI 論文の「通信破綻」と「共有状態の消失/上書き」によって具体的な症状を持つ。(Source: [[@2026__arXiv__Agent System Operations - Categorization, Challenges, and Future Directions]], [[@2026__IEEE CAI__A System-Level Taxonomy of Failure Modes in Large Language Model Applications]]) - **AIRE (AI Reliability Engineering) は AgenticOps の産業フレームワークとして提唱された**: [[Peter Jausovec]](SREcon25 EMEA)が示した AIRE は、MCP サーバを介して Azure/AWS/GCP/GitHub/Slack へアクセスする複数エージェントの協調構成であり、AgentOps サーベイが定義する「AgenticOps(エージェントを使って従来システムを保守)」の典型実装に対応する。AIRE の「Awareness → Investigation → Resolution」の3段は、AgentOps の「監視 → 異常検知 → 根本原因局所化 → 解決」のうち人手介在を最小化する方向に絞ったサブセットと読める。[[kagent]](Kubernetes ネイティブ・CNCF サンドボックス)は宣言的設定でこの構成を実現し、「各エージェントが独立してツールアクセスを実装する」アンチパターンを MCP による共有ツールレイヤーで解消する。(Source: [[@2025__SREcon25EMEA__From 4 Hours to 8 Minutes with AI Agents that Transform SRE Incident Response]]) - **インシデント調査エージェントの実務失敗は「Rabbit holes」「データ品質」「エージェント過負荷」「未知の失敗」の 4 カテゴリに集約される**: Budichenko(SREcon26)が本番オンコール経験から整理した失敗分類(p.9)は、AgentOps サーベイの Intra-Agent 異常タクソノミーと重なりを持つ。(1)**Rabbit holes**(低優先度アラートへの過剰深堀り・調査スコープのクリープ・ノイズ解析の泥沼)は「意図漂流(幻覚・無関係情報への固着)」に対応する。(2)**データ品質**問題(ガベージイン-ガベージアウト・ツール断片化)は AgentOps の監視が前提とするデータ品質への依存の問題。(3)**エージェント過負荷**(単一エージェントのコンテキスト溢れ・汎化しすぎて優先順位付け不能)は「コンテキスト喪失」失敗モードに対応し、Inter-Agent 協調の欠如は「通信破綻」に対応する。(4)**未知の失敗**は「制約なしの自律性」であり AgentOps の「Action Space Restriction」が対処策となる。実務観察が AgentOps 理論の失敗分類を底から裏付ける形になっている。(Source: [[@2026__SREcon26Americas__AI Agents for Incident Investigation - The Good, The Bad, and The Ugly]] p.9) - **インシデント調査に必要なデータ量(ログ・メトリクス・トレース・知識ベース)とAIコンテキストウィンドウの間に根本的な容量ギャップがある**: Budichenko(p.10)は「We want(必要なもの)」対「We have(実際に使えるもの)」の比較図で、ログ・メトリクス・トレース・知識ベースの 4 種のデータをすべて読み込むには AI のコンテキストウィンドウが圧倒的に小さいことを示した。これは AgentOps の「モニタリング」段階における本質的制約であり、[[エージェントシステム運用]]サーベイが「非 LLM で疑惑領域を絞り込んでから LLM に渡す」2 段構成を推奨する根拠ともなる。本 wiki の [[特徴量削減]](MetricSifter)が古典的手法での前処理を提案するのと同じ動機である。単一エージェントにすべてのデータを渡す設計は「エージェント過負荷」を確実に引き起こす。(Source: [[@2026__SREcon26Americas__AI Agents for Incident Investigation - The Good, The Bad, and The Ugly]] p.10) - **「解決」段階は単一メカニズムでは解けず、事後診断と実行時介入の連動が要る、という具体的反例が現れた**: 本ページの「解決」段階(実行前予防/実行中修正/実行後復旧の 3 クラス)は静的な分類だったが、[[エージェント修復]](AgentTether)はこの分類が単純な切り分けでは不十分であることを示す実証例を与える。事後診断のみ(実行後復旧に相当)で τ-bench 全体の修復率は 43.09%→60.16% まで改善するが、実行時介入(実行中修正)を加えるとさらに 69.11% まで伸び、しかも「一度きりの診断フィードバックは tool-call ステップ 13 で追従率 50% を割るまで減衰する」という定量的理由がある(Figure 3)。すなわち「実行後復旧」の効果は「実行中修正」なしには再実行中に失われる——3 クラスは独立した選択肢ではなく、直列に連動させる必要がある。(Source: [[@2026__arXiv__AgentTether - Graph-Guided Diagnosis and Runtime Intervention for Reliable LLM Agent Operations]] §II Finding 2, §IV-B/D) - **根本原因局所化のグラフ化は「意味的決定パス」の粒度をさらに具体化する一実装として読める**: 本ページの横断的知見は「トレースが構造的実行パス(マイクロサービス)から意味的決定パス(エージェント)へ変化する」ことを AgentOps の核心差異として記録していた。AgentTether の Transition Unit(観測・信念・行動・フィードバックの周期)とその依存エッジからなる Critical Transition Graph は、この「意味的決定パス」を明示的にグラフ構造として実装した具体例であり、根本原因局所化(§VI)の「トラジェクトリ再生・因果トレース・LLM 裁定」の 3 カテゴリのうち因果トレース系列の一実装に位置づけられる。(Source: [[@2026__arXiv__AgentTether - Graph-Guided Diagnosis and Runtime Intervention for Reliable LLM Agent Operations]] §III-C) ## 未解決の問い - AgentOps の 4 段階サイクルは概念的に整理されているが、ステージ間の誤差伝搬——異常検知の偽陽性が根本原因局所化に誤った起点を与え、解決が誤ったコンポーネントに作用する——をどう設計で防ぐか。([[根本原因分析]] の「評価は RCA 研究の最大の不安定要因」と接続) - Inter-Agent 異常のうち終了異常(neural howlround / undercommitment)は、エージェントが自律的に停止を判断する設計と相反する——自律性と停止制御のトレードオフをどう実装するか。([[エージェント運用安全性]] の「能力が低いまま安全な契約は成立するか」と接続) - モデルデータ(アテンションマップ・トークンロジット)を監視シグナルとして活用する AgentOps の方向は、ローカル展開オープンソース LLM を前提とする。API 経由のクローズドモデル(GPT-4o 等)を使うシステムでは白箱観測ができない——この現実的制約でも AgentOps のフレームワークは成立するか。 - 根本原因局所化の 2 段階フレームワーク(非 LLM で疑惑領域絞り込み → LLM-as-a-Judge)は、長期タスクでコンテキスト長が増えると LLM ベース精度が低下する問題(Figure 11)への処方として有望だが、非 LLM 側の絞り込み精度が 2 段目の品質を律速する。絞り込みのカバレッジ-コスト設計はどうあるべきか。 - Aegis(24843 障害)・MASFT(1642 障害)等の大規模ベンチマークは Hermes・Magentic-One 等のフレームワークで自動生成されているが、自動生成トラジェクトリは本番エージェントシステムの失敗分布を再現しているか。産業実環境での AgentOps ベンチマークはどう設計できるか。 - [[Bian Que]] の [[Flexible Skill Arrangement]] は Skill という外在化されたコンテキスト仕様でエージェントの「意図漂流」を事前拘束するが、この設計はどこまで汎化するか。Skill ライブラリが膨大になったとき、キーワードベース MATCH は精度を維持できるか。AgentOps の視点で言えば、Skill のメンテナンス自体が新たな AgentOps 対象になる可能性はあるか。([[@2026__arXiv__Bian Que - An Agentic Framework with Flexible Skill Arrangement for Online System Operations]] Appendix C) - LLM アプリケーションの 15 失敗モードは分類としては有用だが、AgentOps の運用サイクルへ落とすには、各失敗モードに対応する検知信号、根本原因局所化手順、解決アクションを定義する必要がある。どの失敗モードが白箱モデルデータを必要とし、どれが入出力ログとツール実行トレースだけで検知できるか。 ## 関連 - ソース: [[@2026__arXiv__Agent System Operations - Categorization, Challenges, and Future Directions]] / [[@2026__IEEE CAI__A System-Level Taxonomy of Failure Modes in Large Language Model Applications]] / [[@2026__arXiv__AgentTether - Graph-Guided Diagnosis and Runtime Intervention for Reliable LLM Agent Operations]] - 概念: [[AIOps]] / [[agentic SRE]] / [[エージェント運用安全性]] / [[エージェント修復]] / [[異常検知]] / [[根本原因分析]] / [[障害緩和]] - 隣接 concept: [[SRE AI Autonomy Levels]] / [[Fault Localization]] / [[インシデント管理]] / [[テレメトリ]] - 関連 MOC: [[LLM4SRE - MOC]] / [[AIOps - Failure Detection - MOC]] ## 出典 - [[@2026__arXiv__Agent System Operations - Categorization, Challenges, and Future Directions]](§I-IX 全体、特に §II 異常タクソノミー・§III AgentOps 定義・§IV モニタリング・§V 異常検知・§VI 根本原因局所化・§VII 解決・§VIII ベンチマーク) - [[@2026__IEEE CAI__A System-Level Taxonomy of Failure Modes in Large Language Model Applications]](3 層 15 失敗モード、評価ギャップ、本番ギャップ、設計原則) - [[@2026__arXiv__AgentTether - Graph-Guided Diagnosis and Runtime Intervention for Reliable LLM Agent Operations]](§I エージェント修復の定式化、§II Motivation の定量分析、§III-A〜D 手法、§IV 評価)