AIエージェント・ガバナンスフレームワーク構築ガイド — エージェントドリフトを防ぐ監督設計

AIエージェント・ガバナンスフレームワークとは、AIエージェントが自律的に行動する環境において、意図しない逸脱（エージェントドリフト）を防ぐための監督・制御体系です。

マルチエージェントシステムの本番導入が加速する中、エージェントが与えられた権限を超えて行動したり、目標から静かにずれていく「ドリフト」が深刻なビジネスリスクとなっています。EU AI Act（Regulation (EU) 2024/1689）や NIST AI RMF 1.0 など、主要規制もエージェントへの人間による監督義務を明示し始めました。

本記事は、情報システム部門・AI 推進担当者を対象に、ガバナンスフレームワークの設計から実装まで 4 ステップで解説します。監督モデルの選択、ガードレール実装、ドリフト検知、セキュリティ統合の順に読み進めることで、説明可能で安全なエージェント運用の基盤を構築できます。

結論: AIエージェントの自律化が進むほど、意図しない逸脱リスクは拡大し、ガバナンスなき運用は業務障害や法的責任に直結する。

エージェントが自律的に外部ツールを呼び出し、複数タスクを連鎖実行する環境では、従来の AI 監視手法では対応しきれない新たなリスクが生じています。本セクションでは、その背景と規制動向を概観します。

エージェントドリフトとは、AIエージェントが当初設定された目標・手順・制約から徐々に逸脱し、意図しない行動を取り続ける現象です。最初は「エージェントが自律的に動けば、人間の確認コストはゼロになる」と考えがちですが、実際には監督の空白こそがドリフトを加速させ、被害が顕在化するまで誰も気づかないケースが報告されています。

業務上のリスクは、主に以下の三層で発生します。

• 意思決定の連鎖誤り: マルチエージェントシステムでは、上流エージェントの小さな判断ミスが下流に伝播し、最終出力が大きく歪む傾向があります
• 権限の自己拡張: エージェントが目標達成のために本来想定外のツールや API を呼び出し、データ漏洩・不正操作につながるリスクがあります
• 説明責任の空白: ドリフトが発生した際、どのエージェントのどのステップで逸脱が始まったかをトレースできず、監査対応が困難になります

特に注意が必要なのは、ドリフトが「急激な暴走」ではなく「緩やかな逸脱の積み重ね」として現れる点です。個々のステップは正常に見えても、タスクグラフ全体を通じると目標から大きく外れている——そのような構造的リスクが、本番稼働後に顕在化する事例が増えています。

ガバナンスフレームワークを構築する際は、ドリフトを「発生してから対処する」事後対応ではなく、設計段階で制御点を組み込む「シフトレフト」の発想が効果的です。[マルチエージェントAIとは？

「エージェントに任せすぎていないか」という問いは、マルチエージェントシステムの設計現場で繰り返し浮上します。過剰エージェント権限（Excessive Agency）とは、AIエージェントが業務目標の達成に必要な範囲を超えた権限・機能・自律性を持つ状態を指します。

問題は、権限の過剰付与が意図的ではなく「便宜上」行われるケースが多い点です。開発初期にデバッグを容易にするために広い権限を与えたまま本番移行する、あるいはエージェントスキルの追加ごとに権限スコープを見直さない、といった運用上の慣習が積み重なることで、気づかないうちに自律行動の境界線が曖昧になります。

判断の軸は次のように整理できます。

• エージェントが「読み取り専用」の情報収集タスクを担う場合は、書き込み・削除・外部送信の権限を付与しない設計が原則です
• エージェントが複数システムをまたいで処理を完結させる場合は、各ステップに承認ゲートを設け、人間が介在できる制御点を明示的に定義します
• タスクの影響範囲が不可逆（データ削除・外部発注・契約締結など）の場合は、自律実行を禁止し HITL（Human-in-the-Loop）を必須とするルールを設けます

OWASPのLLMセキュリティガイドラインでも、過剰エージェント権限はトップリスクの一つとして挙げられており、最小権限の原則（Principle of Least Privilege）の適用が推奨されています。

「自社のエージェントはどのリスク区分に該当するのか」——この問いに答えられないまま本番稼働を進めると、規制対応コストが後から膨らむ恐れがあります。

国際的な規制動向を整理すると、主要な監督義務は以下の 2 軸に集約されます。

EU AI Act（Regulation (EU) 2024/1689）の要件

2024 年 6 月 13 日に採択され、同年 7 月 12 日に欧州官報に掲載された EU AI Act は、高リスク AI システムに対して人間による監督（Human Oversight）を義務付けています。具体的な要件は次のとおりです。

• エージェントが自律的に行動する際、人間がリアルタイムで介入・停止できる仕組みの実装
• 出力の信頼性を継続的に監視するログ保全と説明可能性の確保
• 高リスク用途では適合性評価（Conformity Assessment）の実施

NIST AI RMF 1.0 の要件

2023 年 1 月 26 日に発行された NIST AI RMF 1.0（最新 Playbook は 2026 年 3 月 27 日更新）は、GOVERN・MAP・MEASURE・MANAGE の 4 機能を通じて、エージェントのリスクを継続的に評価・管理する体制を求めています。

結論: ガバナンス設計を始める前に、権限・ログ・体制の三つの基盤を整えることが不可欠です。

設計に先立ち、エージェントの権限スコープ、オブザーバビリティ基盤、ガバナンスオーナーの三点を棚卸しします。この前提が欠けると、後続のステップが形骸化しやすくなります。

ガバナンスフレームワークの構築を始める際、多くのチームは「まずポリシー文書を整備しよう」と考えがちです。しかし実際には、エージェントが現在どのような権限を持ち、何ができる状態にあるかを先に棚卸しするほうが、設計の精度が大きく上がります。

権限スコープの棚卸しとは、各エージェントが保有するアクセス権・操作権限・外部 API 接続の範囲を一覧化する作業です。具体的には以下の項目を確認します。

• データアクセス権限: 読み取り専用か、書き込み・削除まで可能か
• 外部システム連携: 呼び出し可能な API・ツール・データベースの種類と操作範囲
• Agent Skills（エージェントスキル）の一覧: 各スキルが実行できるアクションと、その影響範囲（ローカル限定か、外部サービスに波及するか）
• エージェント間の委任関係: マルチエージェントシステムにおいて、どのエージェントが他のエージェントにタスクを委譲できるか

棚卸しの結果、過剰エージェント権限（Excessive Agency）が発見されるケースは少なくありません。「便宜上、広めの権限を付与しておく」という運用が積み重なると、エージェントドリフト発生時の被害範囲が拡大します。最小権限の原則に従い、各スキルに必要な権限のみを付与するよう再設計することが重要です。

棚卸し結果は AI 部品表（AI-BOM）の一部として記録し、変更のたびに更新する運用を確立しておくと、後続のセキュリティレビューやレッドチーミングにも活用できます。

ガバナンスフレームワークが機能するかどうかは、エージェントの挙動を「見える化」できるかどうかにかかっています。AIオブザーバビリティ（AI Observability）基盤を整備しないまま監督ルールだけを定めても、ドリフトの検知も説明責任の追跡も困難です。

整備すべきログの種類は、エージェントの自律度によって異なります。単一エージェントが定型タスクを処理する構成であればシステムプロンプト・入出力・ツール呼び出し履歴の3点を収集すれば十分なケースが多く、マルチエージェントシステムで複数エージェントが連鎖動作する構成では、エージェント間の通信ログ・タスクグラフの実行トレース・各ステップの判断根拠まで記録対象を拡張する必要があります。

最低限押さえておきたい収集項目は以下のとおりです。

• 入出力ログ: プロンプト・レスポンスのペアをタイムスタンプ付きで保存
• ツール呼び出しログ: 外部 API・データベースへのアクセス記録と返り値
• エラー・例外ログ: 失敗したアクション・リトライ回数・停止理由
• コンテキストウィンドウ使用率: トークン消費量の推移（無制限リソース消費の予兆検出に有効）

ログの保存先は、コンプライアンス要件に応じて設計します。個人情報を含む出力が発生しうる業務では、ログ自体をマスキング処理してから保管する設計が求められます。

また、収集したログをガバナンス監査で活用するには、データリネージ（Data Lineage）の追跡が可能な形式で保存することが重要です。

「ガバナンスフレームワークを作ろう」と号令がかかっても、誰が最終的な責任を持つのかが曖昧なまま進んでしまうケースは少なくありません。

ガバナンスオーナーが不在だと、エージェントの権限変更やインシデント対応の判断が宙に浮き、対応が遅れる原因になります。フレームワーク構築の前に、関与するステークホルダーを整理し、意思決定の軸を明確にすることが必要です。

特定すべき主要ステークホルダー

• ガバナンスオーナー（Executive Sponsor）: エージェント運用全体の説明責任を負う。情報システム部門長や CIO クラスが担うことが多い
• AI 推進担当（AI Lead）: 技術要件とビジネス要件の橋渡し役。ユースケースごとのリスク評価を主導する
• 法務・コンプライアンス担当: EU AI Act や NIST AI RMF への適合確認、契約上の責任範囲を管理する
• 業務部門オーナー: エージェントが操作するプロセスの実務責任者。ドリフト発生時の業務影響を最初に把握する立場
• セキュリティ担当: 権限スコープの妥当性検証とインシデント対応手順の整備を担う

RACI マトリクスで役割を固定する

ステークホルダーを列挙するだけでは不十分です。各ガバナンス活動（権限変更承認・ログレビュー・インシデント対応など）について、誰が R（実行）/ A（承認）/ C（相談）/ I（通知） に当たるかを RACI マトリクスで明示します。

監督モデルの設計で最初に問うべきは、「このエージェントがどこまで自律的に動いてよいか」という一点だ。自律度を高めれば処理は速くなるが、その分だけ想定外の挙動が業務に直結するリスクも上がる。このトレードオフを曖昧にしたまま実装を進めると、後からガバナンスを後付けする羽目になる。

まず人間の関与レベルを決め、次にタスクグラフ上のどの地点で制御を挟むかを設計し、最後に承認フローとして具体化する——という順序で考えると、設計の抜け漏れが起きにくい。

最初は「すべての承認ステップに人間を介在させれば安全だ」と考えがちですが、実際には監督モデルをタスクの性質に応じて使い分けるほうが、リスク低減と業務効率の両立に効きます。

3つの監督モデルは次のように定義されます。

• HITL（Human-in-the-Loop）: エージェントが行動を実行する前に、人間が明示的に承認する。高リスク・不可逆的な操作（契約書の送付、外部APIへの書き込み等）に適用します
• On the Loop: エージェントは自律的に動作しつつ、人間はリアルタイムで監視・介入できる状態を維持する。中リスクの反復タスク（データ変換、社内通知の自動送信等）に向いています
• Outside the Loop: エージェントが完全自律で動作し、人間は事後ログを確認するのみ。低リスク・完全可逆なタスク（読み取り専用のデータ集計等）に限定します

使い分けの判断軸は「不可逆性」と「影響範囲」の2軸です。

Singapore の「Model AI Governance Framework for Agentic AI」（Version 1.

タスクグラフとは、エージェントが実行するタスクの依存関係を有向非巡回グラフ（DAG）として表現したものです。このグラフ上のどのノードに制御点を置くかを事前に設計することが、エージェントオーケストレーションのガバナンスの核心となります。

制御点を設計する際は、タスクの「可逆性」と「影響範囲」を判断軸にするのが効果的です。データの読み取りや検索など可逆性が高く影響範囲が限定的な処理の場合はエージェントに自律実行を許可し、外部 API 呼び出しや決済処理・ファイル削除など不可逆かつ影響範囲が広い処理の場合は人間の承認または一時停止ゲートを挿入します。

制御点として設計すべき主なポイントは以下の通りです。

• 入口ゲート: タスクグラフの起動時に、入力パラメータが権限スコープ内に収まっているかを検証する
• 分岐ノード: 条件分岐によって実行経路が変わる箇所に、意図しないパスへの逸脱がないかを確認するチェックを置く
• 外部システム連携ノード: 過剰エージェント権限（Excessive Agency）を防ぐため、呼び出し可能な API・ツールをホワイトリストで制限する
• 出口ゲート: タスク完了時に、出力結果が期待仕様の範囲内かをグラウンディングチェックで検証する

マルチエージェントシステムでは、サブエージェントが別のサブエージェントを呼び出す連鎖が発生します。

「エージェントが勝手に外部 API を叩いて注文を確定してしまった」—— そうした事態を防ぐために、承認フローとエスカレーション条件の事前定義が不可欠です。

承認フローは、タスクの影響範囲と可逆性を軸に設計します。具体的には以下の三段階が有効です。

• 自動実行（承認不要）: 読み取り専用・参照系の操作、影響が局所的で即時ロールバック可能なタスク
• 非同期承認（On the Loop）: 外部サービスへの書き込み、金額や数量が一定閾値を超える処理。担当者が事後レビューし、問題があれば差し戻す
• 同期承認（In the Loop）: 契約締結・個人情報の外部送信・本番環境への変更など、不可逆性が高い操作。エージェントは承認取得まで処理を停止する

エスカレーション条件は、以下のトリガーで定義するとモレが生じにくくなります。

• 信頼スコアが閾値を下回った場合（ハルシネーションリスクの上昇）
• タスクグラフ上の想定ステップ数を超過した場合
• 外部ツール呼び出しのエラーが連続した場合
• 処理対象データが機密区分に該当すると判定された場合

エスカレーション先は「即時停止 → 担当者通知 → インシデント管理ツールへのチケット起票」の順で自動化しておくと、対応漏れを防げます。

承認フローは一度設計して終わりではありません。エージェントの権限スコープや業務プロセスが変化するたびに見直し、条件を更新する運用サイクルを組み込むことが、エージェントドリフトを継続的に抑制する鍵となります。

監督設計で制御点を定めても、入出力レベルで実際に「止める仕組み」がなければ絵に描いた餅になる。プロンプトインジェクション、意図しない出力の拡散、グラウンディングの崩れ——これらはポリシー文書では防げない。ここでは、NeMo Guardrails の活用やグラウンディングチェックを含め、制御点を実効性のあるものにするための具体的な実装手順を順に解説する。

ガードレールの設計で「出力側だけ検査すれば十分」と考えがちだが、実際は入力段階での制御こそが最初の防衛線として機能する。出力フィルタはあくまで最終安全網であり、悪意ある指示がモデルの推論プロセスに入り込んだ後では、制御の難易度が大幅に上がる。

AIエージェントが外部ツールやデータソースと連携する構成では、プロンプトインジェクションの経路が大幅に増える点に注意が必要です。直接インジェクションはユーザー入力に悪意ある命令を埋め込む手口ですが、間接インジェクションはエージェントが取得する外部コンテンツ（Web ページ・ドキュメント・API レスポンス等）に攻撃命令を仕込む手口であり、検知がより難しい傾向があります。

入出力制御の主な実装ポイントは以下の通りです。

NeMo Guardrails（ニーモ・ガードレール）は、LLM の入出力に対してポリシーを宣言的に定義できるオープンソースのガードレールフレームワークです。YAML ベースの設定ファイルと Colang という専用 DSL を組み合わせることで、エージェントの振る舞いをコード変更なしに制御できます。

ポリシー適用の方法は、エージェントの自律度によって判断軸が変わります。承認フローを持つ On the Loop 構成では「禁止トピックへの応答ブロック」と「エスカレーション通知」を組み合わせ、Outside the Loop で完全自動化している場合は「出力の自動修正（リライト）」と「リトライ上限付きの自動停止」を優先して設定するのが一般的です。

具体的な実装ステップは以下の通りです。

エージェントが生成した出力をそのまま下流システムに渡してよいのか、現場の担当者が判断に迷う場面は少なくありません。

グラウンディングチェックとは、エージェントの出力が参照元のコンテキスト（RAG 取得文書・システムプロンプト・ツール呼び出し結果）に根拠を持つかを自動検証する仕組みです。不適切な出力処理（Improper Output Handling）を防ぐ最終防衛ラインとして機能します。

実装上、確認すべき観点は主に三つあります。

• 根拠整合性チェック: 出力内の主張が取得文書のどの箇所に対応するかをスコアリングし、閾値未満の場合は出力を保留または再生成する
• スコープ逸脱検出: エージェントが付与された権限スコープ外のアクション（例：読み取り専用エージェントによるデータ書き込み要求）を出力が示していないかを構造的に検証する
• ハルシネーション抑止: 出力に含まれる固有名詞・数値が、コンテキストウィンドウ内の情報に存在しない場合にフラグを立てる

実装パターンとして、NeMo Guardrails の output rails をチェーンの末尾に配置し、出力を本番システムに渡す前に自動評価するアプローチが広く用いられています。評価結果はログに記録し、AIオブザーバビリティ基盤へ転送することで、次のステップで説明するドリフト検知と連携させることができます。

結論: エージェントドリフトは放置すると業務損害に直結するため、検知・是正の仕組みを稼働前に設計しておく必要がある。

AIオブザーバビリティによるリアルタイム監視、監視指標の設計、そして異常検知後の自動停止・ロールバック手順の三層で対策を構築します。

エージェントドリフトの検知は「ログを後から見返す」アプローチで十分と考えがちですが、実際には非同期のバッチ監視では逸脱が拡大してから気づくケースが多く、リアルタイム観測のほうが被害を最小化できます。

AIオブザーバビリティ（AI Observability）とは、エージェントの推論過程・ツール呼び出し・中間出力を継続的に計測・可視化する仕組みです。従来の APM（アプリケーション性能監視）と異なり、意味的な逸脱（出力の意図ズレ・スコープ外アクション）も検知対象に含める点が特徴です。

リアルタイム異常検知の主な観測ポイントは以下の通りです。

• ツール呼び出し頻度の急増: 想定コール数を超えた場合にアラートを発火させ、無制限リソース消費（Unbounded Consumption）を抑制する
• コンテキストウィンドウ（Context Window）の利用率: 上限に近づくと推論精度が低下しやすいため、閾値を設けて自動通知する
• アウトプットの信頼スコア低下: グラウンディングチェック（Grounding Check）と組み合わせ、スコアが基準を下回った出力を隔離キューに送る
• エージェント間通信（A2A）の異常パターン: 想定外のエージェントへのリクエストや、繰り返しの失敗応答を検出する

実装上は、トレースを構造化ログとして収集し、スパン単位でエージェントの行動を記録するアーキテクチャが有効です。

監視指標の設計は、「何を測るか」を先に決めないと、膨大なログが蓄積されるだけで異常を見逃しやすくなります。

ハルシネーションと目標逸脱は性質が異なるため、それぞれ独立した指標群を設計することが重要です。

ハルシネーション監視の主要指標

• グラウンディングスコア: RAG を利用している場合は、出力と参照ドキュメントの一致率をコサイン類似度等で定量化する
• 事実整合率: エージェントが外部 API やデータベースに照会した結果と、最終出力の数値・固有名詞が一致しているかを自動照合する
• 自己矛盾検出率: 同一セッション内でエージェントが前後で矛盾する主張をした回数をカウントする

目標逸脱（エージェントドリフト）監視の主要指標

• タスクスコープ逸脱率: エージェントが実行したアクションのうち、タスクグラフで定義したスコープ外の操作が占める割合
• ツール呼び出し異常頻度: 同一ツールへの連続呼び出しや、想定外のツール組み合わせが発生した回数
• 目標達成率の推移: 短期スパンで達成率が急落している場合は、プロンプトの劣化や外部データ汚染の可能性を示す

指標の閾値設定はユースケースによって変わります。ハルシネーションの許容度が低いコンプライアンス系タスクの場合はグラウンディングスコアの閾値を厳しく設定し、探索的な調査タスクの場合は目標逸脱率の許容幅を広めに取るといった使い分けが有効です。

ドリフトを検知した後、「すぐに止めるべきか、様子を見るべきか」と判断に迷う現場は少なくありません。この迷いが対応を遅らせ、被害を拡大させる典型的なパターンです。対策は「検知→停止→ロールバック」を自動化し、人間の判断介入箇所を事前に絞り込むことです。

自動停止のトリガー設計

以下の条件をあらかじめ定義し、閾値超過時に即時停止を発動します。

• 異常スコアが設定閾値を連続 N 回超過した場合
• 外部 API コールが許可リスト外のエンドポイントに向いた場合
• タスクグラフの実行経路が承認済みパスから逸脱した場合

停止方式は「ハードストップ（即時強制終了）」と「ソフトストップ（新規タスク受付停止・実行中タスクを安全な中断点まで継続）」の 2 段階を使い分けることが推奨されます。データ破損リスクが高い操作にはハードストップ、ステートレスな処理にはソフトストップが適しています。

ロールバック手順

1. エージェントの状態スナップショットを直近の「正常確認済みチェックポイント」まで巻き戻す
2. 実行済み外部アクション（DB 書き込み・API 送信等）の補償トランザクションを発行する
3. 影響を受けたダウンストリームのエージェントやシステムに停止通知を伝播させる
4. ロールバック完了後、根本原因分析（RCA）が終わるまで再起動を保留する

再起動前のゲート条件

再稼働は「ドリフト原因の特定→システムプロンプトまたはガードレールの修正→ステージング環境での再検証」を経てから承認する運用とします。

ガードレールや監督モデルを整えても、それだけでは穴が残ります。攻撃者の視点から見れば、ガバナンスの「隙間」こそが最も狙いやすい箇所です。

そこで必要になるのが、セキュリティをフレームワークの外付けオプションではなく、構造そのものに織り込む発想です。具体的には、AI TRiSMとの整合を取りながらリスクを継続的に評価し、AI-BOMによってエージェントの構成要素を可視化・追跡することで、変更や依存関係の変化を見落とさない体制を作ります。加えて、レッドチーミングを定期的に実施して、想定外の挙動や脆弱な経路を事前に洗い出しておきます。

これらは独立した施策ではなく、互いを補完する多層構造として機能して初めて、エージェントの信頼性を実運用レベルで担保できます。

セキュリティ対策を後付けで追加すれば十分と考えがちですが、AIエージェント環境では設計段階から信頼・リスク・セキュリティを統合する AI TRiSM（AI信頼・リスク・セキュリティ管理）アプローチが実際には効果的です。

AI TRiSM は、以下の四軸でエージェントのリスクを体系的に管理します。

• Trust（信頼）: エージェントの判断根拠を AI説明可能性（XAI）で可視化し、ステークホルダーへの説明責任を担保する
• Risk（リスク）: 過剰エージェント権限（Excessive Agency）や混乱した代理人問題（Confused Deputy Problem）などのリスクを継続的に評価する
• Security（セキュリティ）: プロンプトインジェクションやメモリポイズニングへの対策を運用サイクルに組み込む
• Management（管理）: ポリシー変更・モデル更新のたびにリスク評価を再実施する仕組みを維持する

この管理サイクルを機能させる基盤として、AI部品表（AI-BOM）の整備が不可欠です。AI-BOM には次の情報を記録します。

ガバナンスフレームワークは「設計時の正しさ」だけでは不十分で、実際の攻撃シナリオで耐性を検証して初めて実効性を持ちます。AIレッドチーミングとは、敵対的な視点からエージェントの振る舞いを意図的に崩し、想定外の権限昇格やプロンプトインジェクションへの脆弱性を洗い出す実践的な検証手法です。

主な検証項目は以下の通りです。

• 直接・間接インジェクション: 外部データソース経由でシステムプロンプトを書き換えられないかを確認する
• 過剰エージェント権限（Excessive Agency）: タスクグラフの制御点を迂回して意図しない外部 API を呼び出せるかをテストする
• メモリポイズニング: エージェントの長期記憶に誤情報を注入し、後続タスクへの影響を測定する
• 混乱した代理人問題（Confused Deputy Problem）: 別エージェントへの委任フローを悪用した権限昇格を試みる

検証の深度は組織の成熟度に応じて使い分けることが有効です。内部チームによるレッドチーミングが整備されていない段階では、まず OWASP の LLM Top 10 に沿った境界テスト（Boundary Testing）から着手し、体制が整った段階で外部のバグバウンティプログラムを併用するのが現実的なアプローチといえます。