1つのエージェントを本番稼働させるたびに、障害が起きたときの影響範囲も広がります。予測モデルであれば誤った出力を返すだけですが、AIエージェント（目標を与えると自分で手順を決めて実行するAI）は、その出力にもとづいて実際に行動をしてしまうからです。
エージェントは、機密データを取得し、基幹システム（正式な記録を保持するシステム）の内容を書き換え、業務の処理を起動し、誤りを別のエージェントに引き渡すこともできます。つまりリスクは、もはやモデルの精度だけの問題ではなく、そのエージェントがどこまでの権限を持ち、どのシステムに到達でき、失敗がどれだけ速く広がるか、ということなのです。
ガバナンスのない自律性は、管理できないリスクを生みます。一方で、自律性を止めてしまうガバナンスは、ビジネスの停滞を引き起こします。目指すのは統制された自律性です。価値を生むだけの権限は与えつつ、その振る舞いが決められた範囲に収まり、追跡でき、いつでも止められる状態にすることが重要です。
CIOやAI推進の責任者は、本番稼働しているすべてのエージェントについて次の6つの問いに対して、根拠のある明確な答えを得られるように体制を整えるべきです。
- どのエージェントが実行したのか
- そのエージェントは何を許可されていたのか
- どのデータ、ツール（エージェントが呼び出す外部システムや機能）、システムを使ったのか
- その処理には、どの方針（ポリシー）が適用されたのか
- 実行した内容を再現し、その結果に至った過程を逆にたどれるのか
- いますぐ介入できるのは誰なのか
すべての統制を責任者自身が実装する必要はありません。ただし、チームに何を問うべきか、どこまでできていれば「完了」なのか、答えが曖昧なままのときに組織が何のリスクを引き受けているのかは、把握しておく必要があります。
最初の30日でつくるべきなのは、こうした問いに、そのたびに調査を立ち上げずに答えられる状態です。エージェントを定義する。権限を絞る。処理を記録する。境界を試す。止める権限を誰かに持たせる。ガバナンスは時間をかけて成熟していくものですが、本番稼働するエージェントを信頼だけで動かしてはいけません。
要点
- AIエージェントは1体ごとに、社内で独立した行為主体として扱います。氏名の分かる責任者、定義された目的、限定された適用範囲を必ず持たせます。
- 与えるのは、その適用範囲に必要なデータ、ツール、処理だけにします。アクセス権は、誰の行為か特定でき、あとから取り消せる形にします。
- 影響の大きい処理の境界は、モデルへの指示文に頼らず、実行時に同じ条件なら必ず同じ判定を返す仕組みで強制します。
- 実行の経路をすべて記録し、エージェントが何をしたのか、なぜそうしたのかを、後から再現できるようにします。
- 想定どおりに進む場合と同じ真剣さで、失敗時の挙動を試験します。そして、調査・停止・安全な復帰を実行できる担当者を割り当てます。
| 期間 | 経営が問うこと | 「完了」の状態 |
| 1〜5日目 | エージェントとその権限を特定できるか | すべてのエージェントに、固有の識別情報、責任者、限定された適用範囲、接続先システムの一覧がある |
| 6〜10日目 | 権限が実行時に強制されていると確認できるか | すべてのツールと処理が、定義済みで、誰の行為か特定でき、取り消せる権限に対応づいている |
| 11〜15日目 | 影響の大きい処理が、モデルの外側で統制されているか | 方針に反する処理を、確実に同じ判定を返す仕組みで遮断・迂回・エスカレーションできる |
| 16〜20日目 | 重要な処理をすべて後から再現できるか | 元の依頼から後続システムへの影響までを、1回の実行として一貫して追跡できる |
| 21〜25日目 | 想定どおりに進まない場合も安全に失敗するか | 既知の失敗パターンがドキュメント化・試験され、方針のしきい値に反映されている |
| 26〜30日目 | 指名された責任者が、停止と復帰を実行できるか | 指名された責任者が、停止・調査・安全な復帰を実行できる |
1〜5日目——エージェントとその権限を特定できるか
「カスタマーサポートのエージェント」「経理のコパイロット」といった漠然とした呼び名のままでは、統制できません。本番稼働するエージェントには、他と区別できる固有の識別情報と、何を許可されているのかの正確な定義が必要です。
エージェントごとに、次の内容を記録した台帳をつくります。
- 固有の識別情報、氏名の分かる責任者、業務上の目的、リスク区分
- 利用するモデル、ツール、API、データソース、後続システム
- 推奨してよい処理、自ら開始してよい処理、承認してよい処理、そして決して実行してはならない処理
- エスカレーション（担当者や上位者への引き上げ）の境界と、人が介入する条件
重要なことは具体性です。適用範囲は、実際に強制できる言葉で具体的に定義します。たとえば「承認済みのナレッジベースの内容を取得し、取引履歴を要約し、人の承認を前提に回答案を作成する」といった書き方です。ここまで具体的であれば、セキュリティ・コンプライアンス・エンジニアリングの各チームが、実装して強制できる境界として扱えます。
やってはいけないこともドキュメント化します。返金処理はできるのか。契約上の利用権限を変更できるのか。決済データを取得できるのか。承認なしに顧客へ連絡できるのか。ここに曖昧な答えが残っているなら、それは本番運用のリスクが未解決であることを示しています。
実現すべきこと： すべてのエージェントに、識別情報、責任者、明示された処理の境界、接続先の一覧がある。
6〜10日目——権限が実行時に強制されていると確認できるか
ドキュメントに書かれた適用範囲は、エージェントが実際に動く場面で組織がそれを強制できて、初めて意味を持ちます。
識別情報は、いま動いているのが誰なのかを確定させます。認可は、その主体に何が許されるのかを決めます。アクセス権は最小限にとどめ、その基準は、将来対応しうる最も広い業務範囲ではなく、そのエージェントに割り当てられた任務に置きます。参照・書き込み・実行・管理の権限は分けて扱います。あるレコードを取得できる権限が、そのまま変更や削除の権限を含んでしまう設計にはしません。
影響の大きい機能には、最も厳しい認可の要件を適用します。対象は次のようなものです。
- 基幹システムへの書き込み
- 金銭が動く取引
- 機密データへのアクセス
- 社外への連絡
- プログラムの実行
- MCPサーバー（AIが社内システムを呼び出すための標準的な接続口。Model Context Protocol）や、その他のエージェント向けの接続口を通じて公開されているツール
共用のサービスアカウントは避けます。誰の行為かが分からなくなり、アクセス権の棚卸しも信頼できなくなります。可能な範囲で、エージェントごとの資格情報、有効期間の短いトークン、条件付きアクセス、明示的なツールの許可リストを使います。
例外時の手続きは、事前に定めておきます。一時的な権限の引き上げを誰が承認できるのか、その状態をどれだけの時間まで維持できるのか、どの処理には必ず人の承認が必要なのかを明記します。認可は、判定できないときに拒否する側へ倒します。識別情報や動作している状況を確認できない場合、あるいは処理を方針に照らして評価できない場合、エージェントは自分の判断で進めるのではなく、停止するかエスカレーションします。
実現すべきこと： すべてのツール呼び出しが、定義済みの権限に照らして判定されている。引き上げられた権限は条件つきかつ期限つきで、例外には必ず指定の承認者と有効期限がある。
11〜15日目——影響の大きい処理が、モデルの外側で統制されているか
統制された自律性が実際に動き出すのは、この段階です。モデルは処理を提案できますが、その処理が許されるかどうかを、モデル自身が決めることはできません。
権限とガードレール（不適切な入力・出力を検知して止める安全装置）は、別のリスクに対応するものです。権限は、エージェントが何にアクセスできるかを定義します。ガードレールは、そのアクセスをどう使えるかを制約します。ガードレールは、検証や方針の照合といった制御を処理の流れの各所に置くことで強制します。
方針の照合は、最終回答だけでなく、処理の流れ全体に適用します。利用者の入力、検索して取り込んだ文脈情報、モデルの出力、ツールに渡す引数、提案された処理のそれぞれについて、個人情報、プロンプトインジェクション（指示を乗っ取る攻撃）、危険な内容、方針違反、禁止された振る舞いがないかを点検します。最終出力の確認だけでは、エージェントが機密データを読む場面、ツール呼び出しを組み立てる場面、影響の大きい処理を開始する場面を統制できません。
「機密データを絶対に開示しない」といった指示文をモデルに与えるだけでは足りません。悪意のある指示や、矛盾する指示は、利用者の入力、検索されたドキュメント、ツールの出力、別のエージェントなど、さまざまな経路から入り込みます。ガードレールは、エージェントと、それが読み・変更し・影響を与えうる対象との境界で強制します。
影響の大きい処理には、モデルの外側で、同じ条件なら必ず同じ判定を返す方針の照合を使います。ツールが実行される前に、取引の上限額、承認済みの送信先、必須項目、データの機密区分、人の承認の要否を検証します。処理を提案するのはモデルですが、それをシステムとして許可するかどうかを決めるのは方針を判定する層です。
実現すべきこと： 機密データが境界を越える前、あるいは影響の大きい処理が実行される前に、方針の照合が動いている。照合に失敗した場合は、あらかじめ定めた遮断・代替処理・エスカレーションのいずれかが起きる。
16〜20日目——重要な処理をすべて後から再現できるか
ガバナンスは、エージェントが何をしたのか、なぜそうしたのか、その後に何が起きたのかを再現できることに依存します。最終出力だけでは足りません。エージェントが受け取った情報、呼び出したツール、適用された権限と方針の照合、後続システムに影響した処理を含めて、実行経路の全体が見える状態が必要です。
1回の実行ごとに、次の要素を記録します。
- 元の依頼内容、モデルへの基本指示文、モデルのバージョン、方針のバージョン
- 検索して取り込んだ文脈情報、ツールの呼び出し、権限の判定結果、実行された処理
- 後続システムへの影響、人による承認、判断の上書き、介入の記録
ツール、システム、エージェントをまたいだ活動をつなぐために、突き合わせ用の識別子（相関ID）を使います。ログは改ざんから保護し、適切な保管期間を定め、監査データへのアクセスは限定します。記録を取ることで説明責任は高まりますが、それが機密情報を露出させる新しい保管庫になってはいけません。
運用の監視は、不正な使われ方、失敗、想定からのずれを示す兆候に絞ります。権限違反、ツールの異常な使われ方、繰り返しの再試行、応答時間の急な悪化、コストの異常、方針の例外適用を追跡します。それぞれの兆候は、調査する権限と責任を持つチームに振り分けます。責任者が決まっていないダッシュボードは、監督として機能しません。
実現すべきこと： セキュリティ、基盤、コンプライアンスの各チームが、重要なエージェントの実行を、元の依頼から後続システムへの影響まで再現できる。対応が必要な異常の通知が、指名された責任者に届いている。
21〜25日目——想定どおりに進まない場合も、安全に失敗するか
正常系、つまり入力が明確で、データが正しく、ツールが使え、方針に矛盾がない状態での試験で分かるのは、想定した業務の流れを完了できることだけです。ガバナンスの試験では、その条件が崩れたときに安全に失敗することも確かめる必要があります。
曖昧な依頼、欠損のあるレコード、矛盾する方針、使えないツール、古いデータ、悪意のある内容を含む検索結果、権限を超えようとする試行を試験します。最初は無害に見える処理が、後の工程でリスクになるような多段階のシナリオも含めます。
失敗の方向は2つあり、どちらも測ります。統制が弱すぎる場合と、厳しすぎる場合です。弱すぎる統制は、リスクをさらします。厳しすぎる統制は使い勝手を落とし、不要なエスカレーションを増やし、現場での定着を妨げます。
初期の本番稼働は、方針のしきい値、エスカレーションの条件、介入を発動させる条件を調整する機会として使います。業務が成功した割合だけでなく、遮断された処理、人が判断を上書きした割合、誤検知、エスカレーションにかかった時間、処理を取り消せるかどうかも併せて追跡します。
実現すべきこと： 代表的な正常系の業務で成功し、悪意ある入力と境界条件の試験を通過している。失敗パターンと方針のしきい値がドキュメント化され、リスクと価値のどちらをどこまで取るかの判断が明示されている。
26〜30日目——指名された責任者が、停止と復帰を実行できるか
建前の上では全員に責任があり、実際には誰も説明責任を負っていない。この状態では、ガバナンスは機能しません。
エージェントの性能、アクセス権、コンプライアンス、監視、障害対応のそれぞれについて、責任者を氏名で決めます。誰が異常を調査し、誰が是正措置を承認し、誰がエージェントを停止させる権限を持つのかを定義します。
切り戻し、資格情報の失効、ツールの切り離し、キルスイッチ（強制的に停止させる仕組み）の発動、人による引き継ぎ、証跡の保全、事後レビューの手順をドキュメント化します。そのうえで、実際に演習します。一度も試したことのないキルスイッチは、机上の想定にすぎません。
権限、方針の遵守状況、運用の状態、業務への影響について、見直しの頻度を決めます。エージェントの適用範囲、接続しているツール、方針は変わっていきます。ガバナンスの役割は、そのずれを障害になる前に検知することです。
実現すべきこと： 指名された責任者が、試験済みの手順と明確な決定権限にもとづいて、エージェントの停止・調査・安全な復帰を実行できる。
30日後、ガバナンスが機能している状態
30日が経った時点で、現場のチームは前述の6つの問いに、最新の記録と運用上の証跡で答えられる状態になっているべきです。答えが個人の記憶や、更新の止まった表計算ファイルに依存しているなら、その統制は機能していません。
これはガバナンスの体制として完成したものではなく、その土台です。まずは1体ごとのエージェントを、内容が読み取れて、範囲が限られていて、追跡でき、止められる状態にします。エージェントの数と範囲が広がるにつれて、こうした統制は集中的な管理と自動化を必要とするようになります。
ガバナンスのない自律性は、管理されていないリスクを生みます。自律性を止めるガバナンスは、停滞を生みます。最初の30日で用意するのは、その中間の道です。信頼を得ながら規模を広げられる、統制された自律性です。
本ブログはグローバルで公開された「The first 30 days of agentic AI governance: A practical checklist」の抄訳版です。