—·
全てのコンテンツは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つのレイヤーが含まれるべきです。
「ログがあること」と「ログが使えること」を混同しないでください。MITREの研究が示す通り、セキュリティ対策は単一のイベントではなく、コンポーネント全体にわたるシステム挙動を考慮しなければなりません（MITRE ATLAS OpenClaw investigation）。ログからアクションチェーンを再構築できなければ、インシデント対応は憶測の域を出ません。
ログはエラー記録のためではなく、エージェントの実行チェーンを再構築するために設計してください。すべてのツール呼び出しと判断を認可コンテキストに紐づけ、「1回の実行＝1つの再構築可能なイベントグラフ」を稼働基準としましょう。
ブラスト・ラジアス・スコーピング（影響範囲の限定）は、自律性のリスクを運用可能な形に変換するものです。「エージェントが誤った行動をとったり、ツールが侵害されたりした場合、データ、システム、ビジネスワークフロー全体で想定される最大の被害は何か？」を問うプロセスです。
多段階で自己修正を行うエージェントは、一度のミスが連鎖的な被害を招く可能性があります。そのため、OWASPは「一つの安全でない判断が、さらなるアクションの連鎖を引き起こすリスク」を低減する制御を推奨しています（genai.owasp.org resource）。
実務的な導入における影響範囲の限定は、以下の4つの観点で測定可能な制限を設けるべきです。
これらを定義した上で、障害モードを想定した訓練（タイムアウト時の停止、ポリシー違反の出力に対するブロック、ツール出力の改ざんへの耐性テスト）を行ってください。目的は被害の最大値を定義するだけでなく、ランタイムにおいて「停止、隔離、承認、ロールバック」が正しく機能することを証明することにあります。
スケールさせる前に影響範囲の限定を完了させてください。「エージェントが暴走した場合の最大被害を把握しているか」「実行ごとにその被害を強制・証明できるか」が、本番稼働のGo/No-Go判定基準です。
自己修正能力はエージェント型AIの生産性を高める一方で、被害を拡大させる要因にもなります。したがって、ゼロトラストにおいては「自律性」をバイナリスイッチではなく、制御可能なパラメータとして扱います。
実務的な制御として「エージェント境界の強制」を導入してください。許可リスト外のツール呼び出しや、スコープ外の書き込みを試みた場合、システムは即座にブロック・記録し、必要に応じて人間のレビューにルーティングします。IMDAのガバナンスフレームワークも、監視はパイロット終了後の後付けではなく、システムライフサイクルの一部であるべきだと強調しています（IMDA governance framework PDF）。
自己修正の限界を安全制御として捉えてください。反復回数に上限を設け、すべてのステップで許可リストを強制し、ポリシー違反や影響範囲を超える試みがあった場合は、即座に人間へエスカレーションしてください。
エージェント型AIを導入する運用者は、以下のチェックリストを標準としてください。
もし一つだけ優先順位をつけるなら、この順序を守ってください：アクセスサーフェス・マップ作成 → ツール許可リスト → 監査ログ → 影響範囲の限定。この手順を踏むことで、エージェント型AIの導入は、定性的なリスク議論から、エンジニアリングによって制御された監査可能な rollout（展開）へと変わります。
エージェント型AIの導入がプロトタイプから本番ワークフローへ移行する中、企業内での標準化が急務です。次四半期には、以下の成果を目標としてください。
リスクとデリバリーを管理する立場の方は、今すぐ明確なオーナーシップを割り当ててください。「すべてのエージェントのステップは、認可決定に遡れなければ実行させない」――これをルールにすることです。