—·
全てのコンテンツはAIによって生成されており、誤りが含まれる可能性があります。ご自身でご確認ください。
エージェント型AIは単なるチャットから「代行実行」へと進化しています。本稿では、ゼロトラストの原則をAIに応用し、IDの限定、ツール許可リストの策定、監査ログの整備を通じて、AIによる自律的な操作リスクを制御するための手法を解説します。
エージェント型AIは、単に回答を生成するだけではありません。自ら計画を立て、ツールを呼び出し、エラーが発生すれば再試行を行います。ここで直面する真のリスクは、組織が「運用上の権限」をAIに委譲してしまうことにあります。米国国立標準技術研究所（NIST）のAIリスクマネジメントフレームワーク（Source）では、こうしたAIの自律性と意思決定に伴うリスクを、組織が回避すべきものではなく、管理すべき課題として明確に定義しています。
そこで実務者が直面する本質的な問いは、「AIエージェントが特権を持つオペレーターとして振る舞う場合、ゼロトラストは何を強制すべきか」という点です。「決して信頼せず、常に検証せよ（Never trust, always verify）」というスローガンは有用ですが、エージェント型AIにおいては、これを「実行時の強制」、すなわちAIが操作を行うまさにその場所で制約を適用する仕組みへと昇華させる必要があります。
エージェントの実行ごとに、以下の3つの運用上の問いに答えられるべきです。
NISTは、AIリスクマネジメントを、ガバナンス、リスクマッピング、そして実際の利用状況や影響に見合った制御を含む体系的なプロセスとして構成しています（Source）。エージェント型システムにおいて、リスクマッピングは理論上の話ではありません。権限が付与される瞬間、すなわち「エージェントIDへの認証情報の発行」「ツール呼び出しを許可するオーケストレーションポリシー」「データの読み書きを許可する認可」といったポイントにリスクを紐付ける必要があります。継続的な検証はエンジニアリングの必須要件であり、ID境界やツール実行権限、承認プロセス、そしてフォレンジックのための可視性といった、エージェントの権限が発現する場所に強制力を持たせる必要があります。
多くのエンタープライズ導入が停滞するのはこの点です。チームはエージェントの「能力」を優先するあまり、実行ID、呼び出し可能なツール、アクセスするデータの境界、イベントを再構築するために必要なログといった「コントロールプレーン」を軽視しがちです。NISTは、エージェントシステムにおけるツール利用を、教訓と注意を要する個別の領域として特に指摘しています（Source）。
また、組織ガバナンスの観点も重要です。カリフォルニア大学バークレー校によるエージェント型AIのリスク管理に関する最新レポート（Source）は、場当たり的な判断ではなく、制御に基づいた実用的な管理の必要性を強調しています。
エージェント型AIのゼロトラストは、IDレイヤーから始まります。エージェントを共有サービスアカウントや人間の認証情報、あるいは過度に広範な権限を持つ統合ユーザーとして実行してはなりません。エージェントの役割と権限範囲を反映した「スコープ化されたID」を使用し、ワークフローや環境（開発・テスト・本番）、データドメインごとに個別のサービスプリンシパル（または同等のアカウント）を分離する必要があります。
NISTのガイダンスは、リスク管理を一般的な「モデルの安全性」ではなく、意図された利用方法や文脈に結びつけています（Source）。エージェントがアクションを実行できる場合、その文脈には「誰が（または何が）実行を許可されているか」が含まれます。チーム間で認証情報を使い回すと、特定のエージェントやワークフローへの帰属関係が曖昧になり、予防策とインシデント対応の両方が弱体化します。
公開されている事例もこのパターンを裏付けています。ITProの報道によれば、あるAIエージェントの助言がユーザーデータの漏洩につながった事例があり、ツールアクセスや統合がいかに実際の機密性に影響を及ぼすかを浮き彫りにしました（Source）。詳細は不明ですが、教訓は明らかです。実行境界が十分に制約されていない状態で自動化をシステムやデータに接続することのリスクです。
スペインのサイバーセキュリティ機関Incibeも、自律システムのセキュリティと制御を強化するための「インシデント・メタ」の教訓を指摘しています（Source）。これはゼロトラストのガイドブックではありませんが、自動化によって行動と影響範囲が変わる際、ガバナンスとセキュリティ制御も進化しなければならないことを裏付けています。
IDだけでは不十分です。次の強制ポイントは「ツール許可リスト」です。エージェント型AIにおいて「ツール」とは、チケット作成API、データベースクエリ、メール送信、ファイルアクセス、デプロイメントトリガーなど、エージェントが呼び出せる関数や統合を指します。許可リストとは、エージェントが定義済みのパラメータと出力処理を伴う、精査されたツールセットのみを呼び出せるようにすることを意味します。
NISTの出版物（Source）は、AIシステムの運用におけるセキュリティ上の考慮事項を重視しています。エージェントがツールを実行できるとき、「セキュリティ上の考慮」は抽象的な概念ではなく、入力検証、パラメータ制約、出力制限といったアクセス制御の設計そのものとなります。
各ツールの呼び出しを、以下の3つの制御を伴う「認可されたトランザクション」として扱ってください。 ・スコープ: ツールが対象とできるリソースセット（例：チケットキュー、データベーススキーマ） ・シェイプ: 許可されるリクエストパラメータと形式（例：パラメータスキーマ、最大結果サイズ） ・結果: 呼び出し後の影響（例：読み取り専用か書き込みか、「送信」か「下書き」か、自動実行か承認必須か）
OATF（Source）のようなコミュニティによる自律システムの安全な運用ガイダンスも参考になりますが、エンタープライズの要件はコミュニティの理想に頼ることはできません。検証がすべてです。エージェントが行ったすべてのツール呼び出しを証明し、それ以外のすべてをブロックできるでしょうか。
オーケストレーションプラットフォームは、「エージェントとツールの接着剤」として機能するため、許可リストの適用を複雑にします。このシステムは実質的にセキュリティ境界の一部です。NISTの「教訓」コンソーシアム（Source）は、エージェントがツールを呼び出す際にチームが具体的な運用の問題に直面しているために存在します。プラットフォームが便利なコネクタを提供していたとしても、ゼロトラストの観点からは、それらを本番環境で必須の特権として扱い、厳格に管理する必要があります。
「特権の肥大化（Privilege Creep）」は、ワークフローの変化や新しいツール統合、オーケストレーション設定のサイレントな昇格、あるいはルーチン化した承認作業を通じて、エージェントの実効権限が時間とともに拡大する現象です。ゼロトラストには、導入時の最小権限だけでなく、権限のドリフト検知と、レビューなしの拡大を防ぐ承認ゲートが必要です。
NISTのAIリスクマネジメントフレームワーク（Source）は、エージェントの権限やツール表面が進化するという現実に合わせ、継続的なリスク管理を求めています。リスク管理を一度限りのオンボーディングとして扱うと、ドリフトは避けられません。コントロールプレーンは、変更検知と再認可をサポートする必要があります。
実務上のリスクアラートは、このパターンに収束しています。ファイブアイズ（Five Eyes）諸国が警告した通り、システムが何を行い、責任がどこにあるかを適切に制御せずにエージェントを展開すると、組織は危機に陥ります（Source）。
本番データベースへの書き込み、IAMポリシーの変更、外部へのメール送信、機密データのエクスポート、デプロイの開始など、「権限に影響を与えるアクション」には承認ゲートを設けてください。詳細は組織によって異なりますが、不可逆的または影響の大きいアクションには、人間または承認されたポリシーエンジンによる明示的な承認を必須とするという設計パターンは一貫しています。
ゼロトラストは予防だけでなく、検知と応答でもあります。エージェント型AIの場合、これは「監査テレメトリ」と「証跡管理（Chain of Custody）」を意味します。インシデント発生後、エージェントの決定とツール実行の過程を再構築できなければなりません。
監査テレメトリには、最低限以下を記録すべきです。 ・エージェントID（スコープ化されたサービスアカウント）、ワークフローID、およびバージョン ・完全なツール呼び出しシーケンス：ツール名、パラメータ、および出力 ・認可の判断：なぜそのツール呼び出しが許可または拒否されたか ・人による承認の有無と承認者のID ・エージェントの実行と後続システムを紐付ける相関ID
NISTのフレームワーク（Source）は、リスク管理には制御が意図通りに適用されているという証拠が必要であるため、ドキュメント化を重視しています。BerkeleyのCLTCレポート（Source）も、監査機能は安全性エンジニアリングの一種であり、印象ではなく証拠に基づいて失敗から学ぶことを可能にすると指摘しています。
エージェントのオーケストレーションは、ツール呼び出し、計画、再試行、サブエージェント間のルーティングを管理します。これは、認可と監査可能性における「チョークポイント（ボトルネック）」となります。
よくある妥協点には注意が必要です。 ・複数のワークフローで単一のIDを使い、帰属関係を崩している ・デプロイ時にツールを許可リスト化し、実行時にレジストリを拡大している ・最終出力のみを記録し、ツール呼び出しや認可判断を記録していない ・ツール呼び出しそのものではなく「人間によるレビューメッセージ」に対して承認を行っている
NISTの「教訓」コンソーシアム（Source）が強調するように、ツール利用を単なる機能としてではなく、制御された能力として扱ってください。オーケストレーション層をIAMの変更と同じように監査し、特権の肥大化とログの欠落を防ぐことが、エージェント型AIを安全に運用するための鍵となります。
エージェント型AIに運用価値を期待するのであれば、ゼロトラスト制御は「テスト可能」であり、「強制可能」であり、「エージェントに何が許され、実際に何が行われたか」を証明できるものでなければなりません。