エージェント型AIの運用には「ゼロトラスト」が不可欠：ツール許可リスト、監査ログ、影響範囲の限定

エージェント型AIの運用に「ゼロトラスト」は不可欠

エージェントが自ら計画を立て、ツールを呼び出し、自己修正を行うようになった今、「最小権限の原則」は単なるスローガンではなくなりました。それは、定義・測定・強制が可能な「境界線」そのものとなります。

エージェント型AIを導入するチームにとって、問われるべきはシステムが「十分に賢いか」ではありません。「エージェントの行動範囲を正確に制限できるか」「すべてのステップを検知できるか」、そして「自律的な動きが暴走した際に被害を封じ込めることができるか」こそが重要です。

本稿では、エージェント型AIのセキュリティ指針やリスクフレームワークを、現場で実行可能な「エージェントのためのゼロトラスト」チェックリストとして翻訳します。エージェントがアクセスするツールやデータの表面（アクセスサーフェス）を地図化し、行動範囲と出口制御（エグレス制御）を定義し、すべてのツール呼び出しと判断に監査可能性を求め、監査やインシデント対応に耐えうる影響範囲の限定を実施しましょう。

アシスタントが「エージェント」に進化すると何が変わるのか

エージェント型AIは、単に質問に答えるだけのチャットボットではありません。エージェントモデルでは、システムは複数のステップにわたって計画を立案し、ツールを呼び出し、外部システムを利用し、中間結果に基づいてアプローチを修正します。OWASPの「Agent Security Initiative」は、エージェントを「目標達成のために行動を起こせるシステム」と定義しています。これにより、プロンプトインジェクションのような従来の失敗だけでなく、認可、実行、制御フローの問題へと運用リスクが拡大します（OWASP Agent Security Initiative）。

この変化こそ、企業がエージェント型AIを単なる「モデルの機能」としてではなく、「運用システム」として扱うべき理由です。NIST（米国国立標準技術研究所）の「AIリスク管理フレームワーク（AI RMF）」は、技術的な性能のみに依存するのではなく、測定可能なガバナンス機能とリスクの成果を中心にリスク管理を構築することを強調しています（NIST AI RMF）。エージェントが実行権限を持つ以上、アイデンティティ、アクセス権、ログ、そしてオーバーライド（介入）という、実行経路に紐づいたガバナンスが不可欠となります。

ゼロトラストの観点から見れば、アシスタントからエージェントへの移行で避けて通れないのは、「モデルを信頼する」ことから「すべての機能呼び出しを検証する」ことへの転換です。OWASPの資料でも、権限、実行境界、行動の追跡可能性に対する強力な制御の必要性が繰り返し説かれています（OWASP Agentic AI Threats and Mitigations）。

運用者への提言

エージェントの自律性を「権限の問題」として捉えてください。品質のテストを行う前に、エージェントが何を操作できるかを定義し、すべてのステップにログを要求すること。事前に使用するツールとデータの範囲を明示できなければ、安全な導入は不可能です。

導入前に「アクセスサーフェス」を地図化せよ

ゼロトラストの第一歩はインベントリ（資産管理）です。最初に行うべきは、エージェントが動作中にアクセス可能なあらゆるツール、連携先、データセット、機能を列挙した「エージェント・アクセスサーフェス・マップ」の作成です。この土台があれば、ツール許可リストの作成や、後述する影響範囲の限定が可能になります。リスク分析を曖昧なカテゴリではなく、具体的な機能に紐づけることができるようになるためです。

OWASPのリソースでは、ツールアクセスを最優先のセキュリティ境界として扱っています。エージェントはデフォルトで任意の操作を行ってはならず、許可された操作は制限・検証されるべきです（OWASP Agentic AI Threats and Mitigations）。また「OWASP Agentic Skills Top 10」が示すように、エージェントは複数の「スキル（ツール機能）」を組み合わせるため、公開する機能ごとのリスクプロファイルを考慮する必要があります（OWASP Agentic Skills Top 10）。

運用者向けのマップには、エージェントがどのようにツールへルーティングするか（直接呼び出し、RAGによる検索、API連携）、各ツールがどのような認証情報を使用するか、そしてどの応答チャネルが次の推論ステップにフィードバックされるかを網羅してください。MITREによるAIシステムの分析では、モデルの推論時だけでなく、システムループ全体を通じて攻撃や失敗が発生しうることが指摘されています（MITRE ATLAS OpenClaw investigation）。

運用者への提言

アクセスサーフェス・マップを本番稼働の必須条件としてください。「このエージェントは、データソースZに対して、スコープYでツールXを呼び出せる」と示せなければ、行動を制限することも、ログを評価することもできません。

ツール許可リストでエージェントの境界を強制する

インベントリ作成後は、強制力が必要です。ツール許可リストは、エージェントが実行できるツールと操作を厳密に定義し、ツールごとに詳細な権限を絞り込むものです。これは一般的なAPI認証とは異なります。エージェントが「あなたが許可したものの中から選択できる」という、アクションレベルでの認可です。

OWASPは、意図しない能力の呼び出しを減らし、ツールの呼び出しパラメータを検証するなど、行動に伴うセキュリティリスクの軽減を求めています（OWASP Agent Security Initiative）。

ゼロトラストの考え方を適用するなら、出口（エグレス）の境界制御も不可欠です。結果をどこに送信できるか、下流でどのアイデンティティを使用できるか、どの出力を後続の行動の入力として使用できるかを制限してください。運用面では、ツール実行を制御された環境に隔離し、ネットワークポリシーを強制し、エージェントがツール出力を悪用して無許可の指示を「密輸」するのを防ぐ必要があります。

シンガポール情報通信メディア開発庁（IMDA）の「エージェント型AIのためのモデルガバナンス・フレームワーク」は、ガバナンスがエージェントのライフサイクルと監視メカニズムをカバーすべきだと明記しています。組織によって実装は異なりますが、責任の所在と制御を明確にするという運用上のニーズは共通しています（IMDA new model AI governance framework for agentic AI）。

運用者への提言

ツール許可リストをデフォルトとし、さらなる出口制限を加えてください。エージェントが「サービスアカウントが実行可能なすべてのこと」を実行できるような設計では、境界線は存在しないも同然です。

すべての判断に監査とログを要求する

監査とログのないゼロトラストは、セキュリティとは言えません。エージェント型AIにおいて、監査可能性とは、事後に「どのツール呼び出しが、どのような順序で、どのようなパラメータと権限で行われ、どのような論理に基づいて次のアクションに至ったか」を回答できることを意味します。

OWASPは、エージェントが長い実行チェーンを形成し、不正な操作が行われる機会が増えるため、行動システムに対する追跡可能性と制御を強調しています（OWASP Agentic AI Threats and Mitigations）。バークレー校のCLTCによるレポートも、リスクは場当たり的なレビューではなく、構造化された制御と証拠によって管理されるべきだと論じています（Agentic-AI-Risk-Management-Standards-Profile.pdf）。

監査グレードのログには、単なるイベントの羅列ではなく、グラフとして実行プロセスを再構築できる以下の3つのレイヤーが含まれるべきです。

1. 認可コンテキスト（ツール呼び出し承認時）：エージェントの識別子、ツール名、認可の可否、権限スコープ、使用された認証情報。
2. 実行記録（エージェントとツール実行環境の境界）：バリデーション後のツールリクエストパラメータ、外部システムのリクエストID、制御判断に必要な出力（秘密情報は除く）。
3. エージェントの判断トレース（隠れた推論の要約）：なぜそのツールを選択したかの理由、計画の遷移イベント（自己修正の理由）、実行されたポリシー境界チェックの結果。

「ログがあること」と「ログが使えること」を混同しないでください。MITREの研究が示す通り、セキュリティ対策は単一のイベントではなく、コンポーネント全体にわたるシステム挙動を考慮しなければなりません（MITRE ATLAS OpenClaw investigation）。ログからアクションチェーンを再構築できなければ、インシデント対応は憶測の域を出ません。

運用者への提言

ログはエラー記録のためではなく、エージェントの実行チェーンを再構築するために設計してください。すべてのツール呼び出しと判断を認可コンテキストに紐づけ、「1回の実行＝1つの再構築可能なイベントグラフ」を稼働基準としましょう。

影響範囲（ブラスト・ラジアス）の限定とインシデントへの備え

ブラスト・ラジアス・スコーピング（影響範囲の限定）は、自律性のリスクを運用可能な形に変換するものです。「エージェントが誤った行動をとったり、ツールが侵害されたりした場合、データ、システム、ビジネスワークフロー全体で想定される最大の被害は何か？」を問うプロセスです。

多段階で自己修正を行うエージェントは、一度のミスが連鎖的な被害を招く可能性があります。そのため、OWASPは「一つの安全でない判断が、さらなるアクションの連鎖を引き起こすリスク」を低減する制御を推奨しています（genai.owasp.org resource）。

実務的な導入における影響範囲の限定は、以下の4つの観点で測定可能な制限を設けるべきです。

• データの影響範囲：ツールごとの到達可能なデータセット、操作（読み取り/書き込み/エクスポート）の制限、フィールドレベルの制約（PII禁止など）、実行あたりの上限数。
• システムの影響範囲：ツールごとに触れられるサービスやキュー、スループットと繰り返し制限。
• アクションの影響範囲：許可される操作タイプ、不可逆的な操作（削除など）のタグ付けと承認フロー、下流への影響（メール通知など）。
• 制御フローの影響範囲：計画あたりの最大反復回数、ループを継続または停止させる条件（タイムアウト、バリデーション失敗）、人間へのエスカレーション基準。

これらを定義した上で、障害モードを想定した訓練（タイムアウト時の停止、ポリシー違反の出力に対するブロック、ツール出力の改ざんへの耐性テスト）を行ってください。目的は被害の最大値を定義するだけでなく、ランタイムにおいて「停止、隔離、承認、ロールバック」が正しく機能することを証明することにあります。

運用者への提言

スケールさせる前に影響範囲の限定を完了させてください。「エージェントが暴走した場合の最大被害を把握しているか」「実行ごとにその被害を強制・証明できるか」が、本番稼働のGo/No-Go判定基準です。

自律性を制御する「自己修正制限」

自己修正能力はエージェント型AIの生産性を高める一方で、被害を拡大させる要因にもなります。したがって、ゼロトラストにおいては「自律性」をバイナリスイッチではなく、制御可能なパラメータとして扱います。

実務的な制御として「エージェント境界の強制」を導入してください。許可リスト外のツール呼び出しや、スコープ外の書き込みを試みた場合、システムは即座にブロック・記録し、必要に応じて人間のレビューにルーティングします。IMDAのガバナンスフレームワークも、監視はパイロット終了後の後付けではなく、システムライフサイクルの一部であるべきだと強調しています（IMDA governance framework PDF）。

運用者への提言

自己修正の限界を安全制御として捉えてください。反復回数に上限を設け、すべてのステップで許可リストを強制し、ポリシー違反や影響範囲を超える試みがあった場合は、即座に人間へエスカレーションしてください。

成功する運用のためのチェックリスト

エージェント型AIを導入する運用者は、以下のチェックリストを標準としてください。

1. 導入前のアクセスサーフェス・マップ：エージェントがアクセス可能な全ツールとデータ源、権限スコープを列挙する。
2. 全ステップでのツール許可リスト：ポリシー外の呼び出しをブロックし、実行前にパラメータを検証する。
3. 出口（エグレス）と境界の制御：ツールの出力先を制限し、侵害された出力によるピボット（横展開）を防ぐ。
4. ツール呼び出しの監査ログ：認可コンテキスト、実行記録、最小限の判断トレースをステップごとに記録する。
5. 影響範囲の限定と訓練：ツールごとの最大被害を定義し、隔離・ロールバック・停止動作をテストする。
6. 自己修正制限とエスカレーション：反復回数を制限し、ポリシー違反のアクションは人間へルーティングする。

運用者への提言

もし一つだけ優先順位をつけるなら、この順序を守ってください：アクセスサーフェス・マップ作成 → ツール許可リスト → 監査ログ → 影響範囲の限定。この手順を踏むことで、エージェント型AIの導入は、定性的なリスク議論から、エンジニアリングによって制御された監査可能な rollout（展開）へと変わります。

今後の展望：次四半期に標準化すべきこと

エージェント型AIの導入がプロトタイプから本番ワークフローへ移行する中、企業内での標準化が急務です。次四半期には、以下の成果を目標としてください。

• 監査用エビデンスパックの統一：認可コンテキスト、ログ、判断トレースをテンプレート化し、NISTのAI RMFやIMDAのガバナンス要件に対応する。
• チーム間での権限ドリフトの削減：許可リストと境界制御により、ツール公開のメカニズムを全社で一貫させる。
• 影響範囲の限定によるインシデント封じ込め：ログ用に設計した実行チェーンを活用し、迅速な停止・調査・ロールバックを実現する。

リスクとデリバリーを管理する立場の方は、今すぐ明確なオーナーシップを割り当ててください。「すべてのエージェントのステップは、認可決定に遡れなければ実行させない」――これをルールにすることです。