副題：「何をしてよいか」を仕組みで決める
想定読者：AIガバナンス担当、CISO、IAM担当、システムアーキテクト
第1回では、AIエージェントを業務に組み込む前に答えるべき3つの問いを挙げました。誰の権限で動いているのか、何をしてよいのか、誰が止められるのか。本稿では、この3つに答えるための統制を体系化します。
1. 大原則 ― 許可の判断をAIに委ねない
エージェントの統制というと、システムプロンプトに「機密情報を外部に送信してはいけない」「削除操作は行わない」と書く方法がまず思い浮かぶかもしれません。しかし、これは統制ではありません。
第1回で見たとおり、エージェントは受信メールや外部の文書に埋め込まれた指示に影響されます。プロンプトに書いた禁止事項は、汚染された入力ひとつで上書きされうるのです。
OWASPは、過剰なエージェンシー（Excessive Agency）への対策として完全な仲介（Complete mediation）を挙げています。許可するかどうかの判断をAIに任せず、エージェントの外側、つまり接続先のシステム側で認可を行い、すべての要求をポリシーに照らして検証するという考え方です。
以降の6つの統制は、すべてこの原則に沿っています。AIがどう判断しても、仕組みの側で越えられない線を引くことが目的です。
2. 6つの統制を3段階に配置する
図1 6つの統制の配置 ― 実行前に絞り、実行中に止め、実行後に追う（© ProSol）
段階 | 統制 | 答える問い |
|---|---|---|
実行前（絞る） | ① ID・権限 | 誰の権限で動くのか |
実行前（絞る） | ② ツールの許可制 | 何をしてよいのか |
実行前（絞る） | ③ データ境界 | 何に触れてよいのか |
実行中（止める） | ④ 人間の承認 | 誰が実行前に止めるのか |
実行中（止める） | ⑤ 緊急停止・レート制限 | 異常時に誰がどう止めるのか |
実行後（追う） | ⑥ 監査ログ | 誰の権限で何をしたか説明できるか |
3. 実行前の統制 ― 能力そのものを絞る
① ID・権限
- エージェントごとに専用のIDを持たせる：複数のエージェントで1つのサービスアカウントを共用すると、操作の記録から誰が実行したかを区別できなくなる
- 利用者の権限を超えない：利用者の代わりに動くエージェントは、その利用者の権限の範囲内で実行する。OWASPも、利用者の文脈で最小限の権限によって処理を実行するよう求めている
- 期限と用途を限定した権限を使う：常時有効な広い権限ではなく、タスク単位で発行し失効させる
- 特権IDの棚卸しの対象に含める：Series 03第3回で扱ったAttack Pathの分析に、エージェントのIDも入れる
② ツールの許可制
- 許可リスト方式にする：使えるツールを明示し、それ以外は使えない設定を初期状態にする
- 汎用的なツールを避ける：任意のコマンド実行や任意のURL取得は、何でもできてしまう。「顧客IDで残高を照会する」のように用途を限定したツールを用意する
- 読み取りと更新を別のツールに分ける：照会だけが必要な業務に、更新できるツールを渡さない
- 新しいツールの接続は審査を経る：外部のツールやプラグインはサプライチェーンの一部になる（OWASP ASI04）
③ データ境界
- 権限の棚卸しを先に行う：第1回で見たとおり、社内AIアシスタントは乱れた権限を可視化する。エージェント導入の前提作業である
- 機密区分に応じて参照範囲を絞る：ラベルの付いた機密データは、業務上必要なエージェントだけが参照できるようにする
- 外部への送信先を許可リストで限定する：メール送信や外部共有の宛先を、システム側で制限する
- 外部由来の入力を「指示」ではなく「データ」として扱う：受信メールや取引先資料の内容を、エージェントへの命令として解釈させない設計にする
4. 実行中の統制 ― 止める仕組みを用意する
④ 人間の承認は「影響度」で段階をつける
すべての操作に人間の承認を求めると、承認依頼が大量に届き、中身を見ずに承認する状態になります。Series 03第1回で見たMFA疲労と同じ構造です。承認は影響の大きさに応じて段階をつけて初めて機能します。
影響度 | 操作の例 | 承認の方法 |
|---|---|---|
低 | 参照、要約、社内向けの下書き作成 | 自動実行（ログで追跡） |
中 | 社内への送信、チケット起票、定型データの更新 | 実行後に通知し、抽出して事後確認 |
高 | 外部への送信、顧客データの更新、支払・取引、権限の変更 | 実行前に人間が承認（重要なものは2名で確認） |
承認画面には、エージェントが何を根拠に、何をしようとしているのかを表示します。「承認しますか」だけでは、人間は判断できません。
⑤ 緊急停止とレート制限
- 停止の単位を2段階で用意する：特定のエージェントだけを止める停止と、すべてのエージェントを止める停止
- 停止と同時に権限を失効させる：プロセスを止めても、発行済みの権限が生きていれば操作は続きうる
- レート制限で被害の速度を抑える：単位時間あたりの送信件数や更新件数に上限を設け、異常に気付くまでの時間を稼ぐ
- 停止を判断する人を事前に決め、訓練する：Series 04第3回で扱った演習のシナリオに、エージェントの暴走を入れる
5. 実行後の統制 ― 説明できる記録を残す
⑥ 監査ログ
金融機関にとって、AIが実行した操作でも説明責任は残ります。ログは「動いた記録」ではなく、後から一連の判断を再構成できる記録として設計します。
- 起点となった指示と、その指示を出した利用者
- エージェントのIDと、権限の委任元
- 参照したデータと、外部から取り込んだ入力
- 呼び出したツール、渡した引数、得られた結果
- 承認が必要だった場合の承認者と承認時刻
この5つがそろっていれば、汚染された入力が原因だったのか、権限設計の問題だったのか、承認の見落としだったのかを切り分けられます。
統制設計チェックリスト（10項目）
- 禁止事項をプロンプトだけに頼らず、システム側で認可しているか
- エージェントごとに専用のIDを持たせているか
- エージェントの権限が委任元の利用者の権限を超えないか
- 使えるツールを許可リストで限定しているか
- 読み取りと更新のツールを分けているか
- 導入前に、参照対象となるデータの権限を棚卸ししたか
- 外部への送信先をシステム側で制限しているか
- 承認の要否を影響度で3段階に分けているか
- 個別停止・全体停止と権限失効の手順を決め、訓練しているか
- 「誰の権限で何をしたか」を再構成できるログを残しているか
まとめ
エージェントの統制は、AIに「正しく振る舞ってほしい」と願うことではありません。AIがどう振る舞っても越えられない線を、仕組みの側に引くことです。実行前に能力を絞り、実行中に止める手段を持ち、実行後に説明できる記録を残す。この3段階がそろって、はじめて業務に組み込めます。
ただし、6つの統制を個々のエージェントに実装するだけでは、組織としての管理にはなりません。次回は、ユースケースの審査からリスク分類、導入前の審査、運用監視、変更管理、インシデント対応までを一つにした、金融機関向けのガバナンスモデルを扱います。
主要出典
- OWASP GenAI Security Project「LLM06:2025 Excessive Agency」
- OWASP GenAI Security Project「OWASP Top 10 for Agentic Applications」（2025年12月）
- 金融庁「AIディスカッションペーパー（第1.1版）」（2026年3月3日）
- NIST AI 600-1「Generative Artificial Intelligence Profile」（2024年7月）
本記事は公開情報に基づく一般的な解説です。特定の製品・サービスの実装方法を示すものではありません。承認レベルの区分は一例であり、各機関の業務とリスクに応じて設定してください。