「この要約エージェントが止まったら、どの業務に影響しますか？」「この社内検索APIを来週メンテナンスで止めますが、影響するエージェントはどれですか？」——AIエージェントの本番運用が進むと、こうした質問がインシデント対応や変更レビューのたびに飛んできます。そして多くの現場で、答えは「たぶん○○と△△……確認します」です。
エージェントは単体では動きません。モデル、ツール（MCPサーバーや社内API）、ナレッジ（ベクトルインデックスや社内文書）、外部SaaS、ガードレール、実行基盤が組み合わさって、初めて1つの業務を担います。しかもその組み合わせは、プロンプトやツール定義の中に散らばって書かれていて、全体を見渡せる地図がありません。
本稿では、ネットワークのNOC/TACで日常的に扱ってきた構成管理（CMDB）と依存関係マップの考え方を、AIエージェント運用に持ち込みます。構成アイテム（CI）の定義、業務サービスとの紐づけ（サービスマッピング）、依存関係からの影響範囲分析、ChangeOps・ProblemOpsと連動する更新ルール、そして”地図と実態のずれ”の検知までを、運用規律として整理します。
想定読者は、AIエージェントを本番で運用する開発・運用チーム、プラットフォームチーム、情報システム部門、AIガバナンス担当の方です。
本稿の位置づけ
本稿は、インシデント・問題・変更の3点セットを裏側で支える”土台”にあたります。ProblemOps編の影響範囲の見積もりも、ChangeOps編の衝突検知も、「何が何に依存しているか」が分かっていることを前提にしていました。既存記事との違いは次のとおりです。
| 記事 | 扱う範囲 | 本稿との違い |
|---|---|---|
| フリート運用編（9/11） | エージェントのインスタンス在庫と設定ドリフト | 「何がいくつあるか」の話。本稿は「どれとどれがつながっているか」という関係性と業務影響を扱う |
| AI-SPM（9/3） | セキュリティのためのAI資産の発見と姿勢管理 | 目的がセキュリティ。本稿は運用での切り分けと変更判断のための構成情報 |
| 変更管理（ChangeOps）編（10/12） | 変更台帳、変更カレンダー、衝突検知、MOP | 台帳は「何が変わったか」の記録。本稿は変更が「どこに波及するか」を判断するための地図 |
| 問題管理（ProblemOps）編 | 再発分析と既知のエラーDB（KEDB） | 問題の影響範囲の見積もりに、本稿の依存関係マップを使う |
一言でまとめると、フリートは「在庫表」、ChangeOpsは「作業記録」、本稿のCMDBは「配線図」です。
なぜ”止まると何が止まるか”に答えられないのか
1. 依存関係がプロンプトとコードに散らばっている
エージェントがどのツールを呼べるかはツール定義に、どのナレッジを参照するかはRAGの設定に、どのモデルを使うかは環境変数やゲートウェイの設定に書かれています。それぞれは正しく管理されていても、横断して「このエージェントの依存先一覧」を出せる場所がないのが普通です。
2. 共有資産が見えない
社内検索API、共通のガードレールサービス、1つのモデルエンドポイントは、複数のエージェントから共有されています。共有資産が止まると、一見無関係な複数のエージェントが同時に劣化します。インシデント初動で「同時に3件アラートが上がったが、共通原因は何か」が分からず、切り分けに時間を取られる典型パターンです。
3. 地図があっても古い
一度は構成図を描いたものの、ツールの追加やナレッジの差し替えに追随できず、半年後には実態と違う——という状態です。古い地図は、地図がないより危険です。影響なしと判断した変更が、実は地図に載っていない依存先を壊すからです。
規律1：構成アイテム（CI）を定義する
まず「何を地図に載せるか」を決めます。ITサービス管理では、管理対象を構成アイテム（Configuration Item：CI）と呼びます。AIエージェント運用では、次のCIクラスから始めるのが実用的です。
| CIクラス | 例 | 見落としやすい点 |
|---|---|---|
| 業務サービス | 問い合わせ一次回答、請求書チェック、社内ヘルプデスク | 技術側の名前ではなく、業務部門が使う名前で登録する |
| エージェント | 回答エージェント、要約エージェント、オーケストレーター | サブエージェントや、A2Aで呼ぶ他チームのエージェントも1つのCIとして扱う |
| モデル／エンドポイント | モデルAPI、社内ホスティングのモデル、AIゲートウェイ | エイリアス指定（latestなど）の場合、実体のバージョンも属性に持つ |
| ツール | MCPサーバー、社内API、関数ツール | ツールの先にある業務システム（基幹DB、チケットシステム）も別CIにする |
| ナレッジ | ベクトルインデックス、文書コレクション、FAQデータ | インデックスの元データ（ファイル共有、Wiki）と更新ジョブまでつなぐ |
| 外部API／SaaS | 検索API、翻訳API、外部データ提供サービス | 契約・サポート窓口・SLAを属性に持たせる |
| ガードレール | 入出力フィルタ、PII検知、ポリシーエンジン | 共有されていることが多く、単一障害点になりやすい |
| 実行基盤 | コンテナ基盤、キュー、シークレット管理、ログ基盤 | エージェントからは見えにくいが、止まると全部止まる |
粒度の決め方
粒度は「単独で止まる・変わる単位」で切ります。ツールが10個あるMCPサーバーでも、デプロイも障害も一体なら1つのCIで構いません。逆に、同じモデルでも用途ごとに別エンドポイントを使っているなら、エンドポイント単位で分けます。迷ったら、「この単位でインシデントや変更のチケットを切るか」で判断してください。
属性は最小限から
最初から属性を盛り込みすぎると、更新されずに腐ります。初期は次の5つで十分です。
- オーナー（チームと一次連絡先）
- 環境（本番／ステージング）
- 重要度ティア（後述）
- バージョンまたは版（モデルの実体バージョン、プロンプトの版、インデックスの更新日）
- 最終確認日（実態と照合した日）
規律2：業務サービスと紐づける（サービスマッピング）
CIを並べただけでは”部品表”です。「止まると何が止まるか」に答えるには、CI同士の関係と、最上位の業務サービスへのつながりが必要です。
地図は”上から”描く
技術側から描き始めると、部品は網羅できても業務とのつながりが抜けます。業務サービスから出発し、「このサービスが動くには何が必要か」を下にたどるトップダウンで描くのが原則です。NOCで回線や機器からではなく「お客様のサービス」から影響範囲を引いていたのと同じ考え方です。
関係の種類をそろえる
関係を「つながっている」の1種類で済ませると、影響分析に使えません。最低限、次の種類を区別します。
| 関係 | 意味 | 例 | 影響の伝わり方 |
|---|---|---|---|
| 提供する | エージェントが業務サービスを担う | 回答エージェント → 問い合わせ一次回答 | エージェント停止＝サービス停止または縮退 |
| 呼び出す | エージェントがツール・API・他エージェントを使う | 回答エージェント → 在庫照会MCP | 呼び出し先の停止で、該当機能が失敗 |
| 推論に使う | エージェントがモデルを使う | 回答エージェント → モデルエンドポイントA | 停止で全面停止、劣化で品質低下 |
| 参照する | エージェントがナレッジを使う | 回答エージェント → FAQインデックス | 停止で回答不能、古いと誤回答（気づきにくい） |
| 保護される | ガードレールを通る | 回答エージェント → PII検知 | 停止時にフェイルオープンかフェイルクローズかで影響が変わる |
| 上で動く | 実行基盤に載っている | 回答エージェント → コンテナ基盤 | 基盤停止で全面停止 |
あわせて、関係ごとに「代替があるか（フォールバック先のモデル、キャッシュ、人間への切り替え）」を記録しておくと、影響分析の精度が一段上がります。
重要度ティアを付ける
業務サービスに重要度ティア（例：Tier1＝顧客影響・売上影響あり、Tier2＝社内業務、Tier3＝試行・実験）を付け、依存先のCIは、つながっている業務サービスの最も高いティアを継承させます。「地味な社内APIが、実はTier1サービス3つの共通依存だった」という発見は、この継承で初めて見えてきます。
規律3：依存関係から影響範囲を引く
地図の価値は、使ったときに出ます。影響分析には2つの向きがあります。
| 向き | 問い | 使う場面 |
|---|---|---|
| 上向き（インパクト分析） | このCIが止まると、どの業務サービスが止まるか | 障害の影響範囲の宣言、変更のリスク評価、メンテナンス告知 |
| 下向き（原因候補の洗い出し） | この業務サービスが劣化したとき、疑うべきCIはどれか | インシデント初動の切り分け、ProblemOpsでの原因調査 |
障害時の使い方——”共通の親”を探す
たとえば、問い合わせ一次回答と社内ヘルプデスクの2つのサービスで、ほぼ同時に回答品質の低下アラートが上がったとします。
- 2つのサービスから下向きに依存CIを洗い出す
- 両方に共通するCI（共有のモデルエンドポイント、共通ガードレール、同じナレッジ）に絞り込む
- 共通CIの直近の変更（ChangeOpsの台帳）と稼働状況を確認する
- 原因候補が確定したら、そのCIから上向きに影響範囲を引き直し、まだアラートが出ていない影響サービスにも先回りで連絡する
ネットワーク運用でいえば、複数拠点の同時ダウンから共通の上位ルーターを特定する手順と同じです。「個別のアラートを個別に追わない」ことが、切り分けを速くする最大のポイントです。
単一障害点と共有資産を定期的に洗い出す
地図ができたら、「Tier1サービスに至る経路のうち、代替のないCI」を一覧にします。これが単一障害点です。すべてを冗長化する必要はありませんが、少なくともリスクとして認識され、オーナーが合意している状態にしておきます。
規律4：ChangeOps・ProblemOpsと連動する更新ルール
CMDBが腐る最大の理由は、「更新する担当」と「変更する担当」が別で、更新が後回しになることです。そこで、構成の更新を他のプロセスの”出口条件”に組み込みます。
| きっかけ | CMDBで行うこと | 組み込み先 |
|---|---|---|
| 新しいエージェント・ツール・ナレッジの追加 | CIの登録と、業務サービスへの紐づけ | デプロイ運用のリリース判定（未登録ならリリース不可） |
| 変更申請 | 対象CIを指定し、上向きの影響範囲を自動で添付 | ChangeOpsの変更申請テンプレート |
| 変更完了 | バージョン・版・関係の更新 | ChangeOpsの変更クローズ条件 |
| インシデント発生 | 影響CIと影響サービスを記録 | インシデント運用の起票項目 |
| 問題レコードの作成 | 原因CIを紐づけ、KEDBのエントリとCIをリンク | ProblemOpsの根本原因分析 |
| CIの廃止 | 関係の削除と、残っている依存元の確認 | 廃止手順のMOP |
“変更なくして構成更新なし、構成更新なくして変更クローズなし”
この2つを機械的に結びつけるのが理想です。変更申請でCIを選ぶと、影響範囲の業務サービスとティアが自動で表示され、それが承認区分（標準・通常・緊急）の判断材料になる。変更をクローズすると、CIの版が更新される。ここまでつながると、ChangeOps編で紹介した「依存衝突」の検知も、CMDBの関係データから自動で行えるようになります。
問題管理との連動
問題レコードとKEDBのエントリを原因CIに紐づけておくと、「このCIは過去半年で何件の問題の原因になったか」が分かります。問題の多いCIは、変更時のリスク評価を一段上げる、監視を厚くする、といった判断に使えます。
規律5：”地図と実態のずれ”を検知する
更新ルールを決めても、ずれは必ず発生します。重要なのは、ずれをゼロにすることではなく、ずれに早く気づく仕組みを持つことです。
観測データと突き合わせる
エージェントの実行トレース（OpenTelemetryのGenAIセマンティック規約に沿ったトレースや、AIゲートウェイ・MCPゲートウェイのログ）には、「実際にどのモデルを呼んだか」「どのツールを呼んだか」「どのインデックスを検索したか」が残ります。これを定期的に集計し、CMDBに登録された関係と突き合わせます。
| ずれの型 | 内容 | リスク | 対応 |
|---|---|---|---|
| 未登録の依存 | トレースには出るが、CMDBにない呼び出し | 影響分析から漏れる。最も危険 | オーナーに確認し登録。台帳外変更としてChangeOpsにも記録 |
| 使われていない依存 | CMDBにはあるが、一定期間呼ばれていない | 影響範囲を過大評価し、不要な調整が増える | 廃止候補としてオーナーに確認 |
| 版のずれ | 登録されたモデル版・インデックス更新日と実態が違う | 原因調査で誤った版を前提にしてしまう | 自動取得できる属性は自動更新に切り替える |
| オーナー不在 | オーナーのチームが解散・異動している | 障害時に連絡先がない | 四半期の棚卸しで再割り当て |
構成管理のKPI
| 指標 | 定義 | 見方 |
|---|---|---|
| 未登録依存の件数 | トレースで見つかったCMDB外の依存の数 | ゼロを目指すより、検知から登録までの日数を短くする |
| サービスマッピング率 | 業務サービスに紐づいた本番エージェントの割合 | 100%が前提。未紐づけは”誰の業務か分からない”エージェント |
| CIの鮮度 | 最終確認日が90日以内のCIの割合 | Tier1に関わるCIから優先して上げる |
| 影響範囲の的中率 | インシデントで事前に引いた影響範囲と、実際の影響の一致度 | 外れた事例は、地図の誤りとして振り返りで修正する |
| 初動の切り分け時間 | アラートから原因CI特定までの時間 | CMDB導入前後で比較すると、効果を説明しやすい |
運用サイクル——いつ、何を見るか
| 頻度 | やること | 参加者 |
|---|---|---|
| 毎日 | トレースとの突き合わせ結果（未登録依存）を確認し、オーナーに振り分ける | 運用当番 |
| 週次 | 変更レビューの場で、今週の変更の影響範囲と依存衝突を確認する | 運用、各エージェントのオーナー |
| 月次 | 単一障害点の一覧と、問題の多いCIを見直す | 運用リード、プラットフォーム |
| 四半期 | 全CIの棚卸し（オーナー、ティア、使われていない依存の廃止） | 運用リード、業務部門、AIガバナンス担当 |
よくある落とし穴
- 最初から完璧な地図を作ろうとする：全エージェントの棚卸しから始めると終わりません。Tier1の業務サービス1つを選び、その配下だけを先に描き切るほうが、早く価値が出ます。
- 手作業の構成図で済ませる：描画ツールの構成図は、作った瞬間から古くなり始めます。関係はデータとして持ち、図はそこから生成するものと考えてください。
- ナレッジを”データ”として地図から外す：ナレッジの劣化は、エラーではなく誤回答として現れるため、最も切り分けにくい障害です。インデックスと元データ、更新ジョブまで必ずCIにします。
- 外部SaaSを地図の外に置く：自社で管理できないからこそ、依存していることを明示し、障害情報の確認先とサポート窓口を属性に持たせます。
- 更新を”誰かの善意”に頼る：更新はリリース判定や変更クローズの条件に組み込まない限り、続きません。
構成管理（CMDB）チェックリスト
| 領域 | 確認項目 |
|---|---|
| CI定義 | CIクラスと粒度のルールが文書化されている／全CIにオーナー・環境・ティア・版・最終確認日がある |
| サービスマッピング | 本番エージェントがすべて業務サービスに紐づいている／関係の種類と代替の有無が記録されている |
| 影響分析 | 任意のCIから影響する業務サービスを数分以内に引ける／単一障害点の一覧がありオーナーが合意している |
| プロセス連動 | 未登録のCIはリリースできない／変更申請に影響範囲が自動添付される／変更クローズでCIが更新される |
| 問題管理連動 | 問題レコードとKEDBのエントリが原因CIにリンクされている |
| ずれの検知 | トレースとCMDBの突き合わせが定期実行されている／未登録依存の検知から登録までの日数を測っている |
| 棚卸し | 四半期ごとにオーナー・ティア・不要な依存を見直している |
よくある質問（Q&A）
Q1. 専用のCMDB製品がないと始められませんか？
始められます。最初はスプレッドシートやリポジトリ内のYAMLファイルで、CIと関係を管理しても構いません。大事なのは製品ではなく、CIの定義、関係の種類、更新ルールの3つが決まっていることです。規模が大きくなり、トレースとの自動突き合わせや変更申請との連動が必要になった段階で、既存のITSMツールやCMDB製品への統合を検討してください。
Q2. フリート管理の在庫表があれば十分ではありませんか？
在庫表は「何がいくつあるか」を答えますが、「これが止まると何が止まるか」は答えません。在庫表は本稿のCIの元データとしてそのまま使えます。そこに関係と業務サービスへのつながりを足したものが、構成管理の地図です。
Q3. エージェントが実行時に動的にツールを選ぶ場合、依存関係は描けますか？
「呼び出す可能性があるツール」（ツール定義に含まれるもの）と「実際に呼んだツール」（トレースに出たもの）を分けて記録するのが現実的です。影響分析では前者を、ずれ検知と優先度付けでは後者を使います。呼び出し頻度を関係の属性として持てば、「依存はしているが滅多に使わない」ツールの影響を過大評価せずに済みます。
Q4. 他チームや外部ベンダーのエージェントをA2Aで呼んでいます。どこまで地図に載せるべきですか？
自社で中身を管理できないものは、1つのCI（ブラックボックス）として登録し、オーナー、連絡先、SLA、障害情報の確認先を属性に持たせれば十分です。中の依存関係までは追えませんが、「依存している」ことが地図に載っているだけで、障害時の切り分けと変更時の調整が大きく変わります。
Q5. 地図の維持に手間がかかりすぎないか心配です。
手間を減らす鍵は、自動取得できる属性を増やすことと、更新を既存プロセスの出口条件にすることです。モデル版やツール呼び出しはゲートウェイやトレースから自動で取れます。人が判断すべきなのは、業務サービスとの紐づけ、ティア、オーナーの3点に絞り込めます。
まとめ——”止まると何が止まるか”を即答できる運用へ
本稿のポイントは、次の3つです。
- エージェント・モデル・ツール・ナレッジ・外部API・ガードレール・実行基盤をCIとして定義し、業務サービスから”上から”つなぐ。
- 依存関係を、障害時の”共通の親”探しと、変更時の影響範囲評価に使う。
- 更新はChangeOps・ProblemOpsの出口条件に組み込み、トレースとの突き合わせで”地図と実態のずれ”に早く気づく。
インシデント、問題、変更の各プロセスは、それぞれ単独でも機能します。しかし、すべてに共通する「何が何に依存しているか」という問いに答える地図があって初めて、3つのプロセスは速く、正確に回り始めます。ネットワーク運用で配線図のないNOCが成り立たないのと同じように、依存関係の地図のないAgentOpsも、いずれ限界を迎えます。まずはTier1の業務サービス1つから、地図を描き始めてください。
免責事項：本記事は、AIエージェントの構成管理に関する一般的な考え方を整理したものです。実際の設計・導入にあたっては、自社のシステム構成、利用しているツールやサービスの仕様、社内規程を確認のうえ判断してください。
コメント