最終更新：2026年4月27日
※本記事は継続的に最新情報へアップデートしています。

AIエージェントのゼロトラスト設計｜ID・権限・監査ログで暴走を防ぐ

AIエージェントの価値は、どこまで任せられるかで決まる。しかし企業の強さは、どこで止められるかで決まる。
AIがMCPで外部ツールに接続し、A2Aで他エージェントと連携する時代において、必要なのはプロンプトの工夫だけではない。AIエージェントにも専用IDを持たせ、最小権限で動かし、重要操作には人間承認を置き、すべての判断と実行を監査できるようにする。本記事では、AIエージェント時代のゼロトラスト設計を、専用ID・最小権限・ツールスコープ・人間承認・監査ログ・サンドボックスの6つの観点から整理する。

📖 読了時間 12分｜🎯対象：AIエージェント導入を検討する経営者・CTO・情シス・開発責任者｜🛠 難易度：★★☆

✅ 先に結論

結論：AIエージェントにもゼロトラストが必要であり、AIを「信頼する対象」ではなく「検証し続ける実行主体」として扱う
判断軸：専用ID、最小権限、ツールスコープ、人間承認、監査ログ、サンドボックスの6点で設計する
注意点：AIエージェントに人間のアカウントや広すぎるAPI権限を使わせると、事故時に責任分界と原因追跡が困難になる

この記事の著者・監修者　ケニー狩野(Kenny Kano)

Arpable 編集部(Arpable Tech Team)

株式会社アープに所属するテクノロジーリサーチチーム。人工知能の社会実装をミッションとし、最新の技術動向と実用的なノウハウを発信している。
役職：(株)アープ取締役。Society 5.0振興協会・AI社会実装推進委員長。中小企業診断士、PMP。著書『リアル・イノベーション・マインド』▶ 詳細はこちら

Toggle

何を守る設計なのか

AIエージェントのゼロトラスト設計とは、AIを信用しないための仕組みではない。AIが安全に働ける境界線を引くための設計である。

ある中堅企業で、営業支援AIエージェントが導入されたとします。AIは顧客情報を読み、過去の提案書を参照し、見積書の下書きを作り、社内チャットで承認依頼を出していました。導入から3か月、生産性は確かに上がっていました。

ところが、ある朝、AIが本来送るべきではない相手に、案件情報を含む見積書案を送ろうとしていたことが発覚しました。担当営業のアカウントで動いていたため、ログ上は「人間が操作した」ように見えました。情シス部門が原因究明に動きましたが、AIがどの文書を参照し、なぜその宛先を選んだのか、誰が承認したのか――記録が十分に残っていませんでした。

AIが間違えたとき、誰の権限で操作したのか。どの文書を読んだのか。なぜその宛先へ送ろうとしたのか。どの時点で人間が承認したのか。

これらを追えなければ、AI導入は便利な実験で止まり、本番運用には進めません。

第2回で扱ったプロンプトインジェクション2.0は、「騙されたAIが、権限を使って業務を実行してしまう攻撃」でした。第3回となる本記事では、その対策として、AIエージェントをどう検証し、どう統制し、どう監査するかを扱います。

定義

AIエージェントのゼロトラスト設計とは、AIエージェントに専用ID・最小権限・ツールスコープ・人間承認・監査ログ・サンドボックスを与え、すべての入力・判断・実行を検証可能にする設計である。

ゼロトラストは「不信」ではなく「検証」である

ゼロトラストという言葉は、しばしば「何も信じない」と誤解されます。しかし本質は、むやみに疑うことではありません。

重要なのは、信頼を前提にせず、毎回検証することです。

従来のセキュリティでは、社内ネットワークの内側を比較的安全な領域とみなし、外側からの攻撃を防ぐ考え方が中心でした。しかしクラウド、SaaS、リモートワーク、API連携が広がると、「内側だから安全」という前提は崩れます。

AIエージェントでも同じです。

AIが社内で動いているから安全なのではありません。AIが有名なモデルだから安全なのでもありません。AIが正しい意図で作られたから安全なのでもありません。

安全にするには、AIが何を読み、どの権限で、どのツールを使い、どの判断をし、どの操作をしたのかを検証できる必要があります。

なぜ今重要なのか

AIエージェントは、人間が確認するより速く、広く、絶え間なく動く。だからこそ、権限設計の失敗は一度のミスで全社規模のインシデントへ広がる。

AIエージェントにとって、権限は力です。

顧客データを読める。ファイルを更新できる。メールを送れる。APIを呼べる。別のエージェントに依頼できる。これらの権限は、AIを業務で役立たせるために必要です。

しかし、権限は同時にリスクでもあります。

人間であれば、違和感に気づいて手を止める場面があります。上司に確認することもあります。社内の空気や文脈から「これはおかしい」と感じることもあります。

AIエージェントは、そうした暗黙知を持ちません。与えられた目的、入力、ツール、権限の中で、最も合理的に見える行動を選びます。

だからこそ、AIエージェントに広い権限を与えるなら、その前にゼロトラスト設計が必要になります。

AIエージェントは「特権を持つ機械ID」である

AIエージェントは、社員のように見えるかもしれません。チャットで会話し、指示を理解し、仕事を進めるからです。

しかし、セキュリティ設計では、AIエージェントを人間の社員として扱うべきではありません。むしろ、特権を持つ機械IDとして扱うべきです。

人間のアカウントをAIに使わせると、事故が起きたときに操作主体が曖昧になります。営業担当者が送ったのか、AIが送ったのか。人間が判断したのか、AIが判断したのか。承認済みなのか、自動実行なのか。

この境界が曖昧になると、監査も、責任分界も、改善も難しくなります。

ここがポイント

AIエージェントには、人間とは別の専用IDを持たせる。そのIDに対して、役割、権限、利用できるツール、承認条件、ログ方針を紐づける。

OWASPが示すエージェント時代のリスク

OWASP Top 10 for Agentic Applications 2026では、AIエージェント特有のリスクとして、ASI01 Agent Goal Hijack、ASI02 Tool Misuse and Exploitation、ASI03 Identity and Privilege Abuse、ASI07 Insecure Inter-Agent Communication、ASI10 Rogue Agentsなどが整理されています。

これらに共通しているのは、AIの「回答」だけでなく、AIの「目的」「権限」「ツール利用」「エージェント間通信」が攻撃面になるという点です。

ASI10 Rogue Agentsは、正規の管理範囲を外れたAIエージェントや、想定外の振る舞いをするAIエージェントが業務に影響を及ぼすリスクとして整理されています。これは、本記事のテーマである「暴走を防ぐ」設計と直結します。

つまり、AIエージェントを安全に使うには、プロンプトだけでなく、ID・権限・ツール・通信・ログまで含めて設計する必要があります。

表1：AIエージェント時代にゼロトラストが必要になる理由
変化	起きること	必要な設計
AIがツールを使う	誤ったAPI呼び出しや外部送信が起き得る	ツールスコープ、実行権限、承認条件
AIが外部入力を読む	間接プロンプトインジェクションを受ける	入力分離、信頼境界、出力検証
AIが他エージェントと連携する	なりすましや指示改ざんが連鎖する	相手認証、通信ログ、責任分界
AIが自律的に判断する	意図しない業務実行が起きる	HITL、停止手段、監査ログ

どう設計するのか

AIエージェントのゼロトラスト設計は、専用ID、最小権限、ツールスコープ、人間承認、監査ログ、サンドボックスの6点で考える。

AIエージェントを安全に動かすには、いきなり本番環境へ接続してはいけません。まず、AIが誰として動くのか、何を読めるのか、何を実行できるのか、どこで人間が止めるのかを決める必要があります。そのうえで、OWASP Agentic Top 10のどのリスクに効く設計なのかを、次のように対応づけておくと、経営会議でも説明しやすくなります。

補足表：6つの設計原則とOWASP Agentic Top 10の対応
設計原則	特に意識したいリスク（OWASP ASI）	狙い
専用ID	ASI03 Identity and Privilege Abuse	操作主体と責任分界を明確にする
最小権限	ASI03 Identity and Privilege Abuse / ASI02 Tool Misuse and Exploitation	権限濫用時の影響範囲を狭める
ツールスコープ	ASI02 Tool Misuse and Exploitation / ASI04 Agentic Supply Chain Vulnerabilities	ツールの誤用・汚染・過剰実行を防ぐ
人間承認	ASI09 Human-Agent Trust Exploitation / ASI10 Rogue Agents	重要操作をAIだけで完結させない
監査ログ	ASI08 Cascading Failures / 全リスク共通	原因追跡と被害範囲の特定を可能にする
サンドボックス	ASI04 Agentic Supply Chain Vulnerabilities / ASI05 Unexpected Code Execution	本番前に危険な動作を検出する

6つの設計原則

表2：AIエージェントのゼロトラスト設計 6原則
原則	意味	実務での例
専用ID	AIエージェントを人間アカウントと分離する	agent-sales-draft、agent-support-readonly などの専用IDを作る
最小権限	必要なデータ・ツール・操作だけを許可する	読み取り専用、ドラフト作成のみ、削除不可にする
ツールスコープ	ツールごとに実行範囲を制限する	送信不可、承認済み顧客のみ、金額上限ありにする
人間承認	重要操作をAIだけで完結させない	外部送信、支払い、契約、権限変更は承認必須にする
監査ログ	AIの入力・判断・実行を追跡できるようにする	参照文書、プロンプト、ツール呼び出し、承認履歴を残す
サンドボックス	本番環境に直接触らせる前に検証する	ダミーデータ、検証環境、読み取り専用環境で試す

1. 専用ID：AIに「誰として動くか」を与える

AIエージェントには専用IDが必要です。

専用IDがなければ、AIの行動は人間の操作に紛れてしまいます。これは、監査上も、セキュリティ上も危険です。

AIエージェントのIDには、最低限次の情報を紐づけるべきです。

エージェント名
業務目的
所有部門
責任者
アクセスできるデータ
利用できるツール
実行できる操作
承認が必要な操作
ログ保存方針

AIエージェントを「誰が作ったかわからない便利ボット」にしてはいけません。社員番号を持つ社員のように、AIエージェントにも管理台帳が必要です。

2. 最小権限：AIに「全部読める」を許さない

AI導入のPoCでは、よく「まずは全部読めるようにしましょう」という発想が出ます。短期的には便利です。しかし本番運用では、最も危険な設計です。

AIエージェントが読むデータは、業務目的に応じて絞る必要があります。

表3：権限設計の悪い例と良い例
設計	悪い例	良い例
データアクセス	全社ファイルを読める	対象部門・対象フォルダだけ読める
顧客情報	全顧客データを検索できる	担当顧客・案件関連データだけ検索できる
メール	全メールを読み書きできる	指定ラベル・指定用途のメールだけ下書きできる
操作権限	作成・更新・削除・送信がすべて可能	下書き作成のみ。送信・削除は人間承認

AIの性能を上げるためにデータを広げるほど、事故時の影響範囲も広がります。AIエージェントのゼロトラスト設計では、便利さよりも影響範囲の制御を優先します。

3. ツールスコープ：AIに「実行ボタン」をそのまま渡さない

AIエージェントは、MCPなどを通じて外部ツールを使えるようになります。ここで重要なのは、ツールそのものを安全に設計することです。

AIに「送金する」「契約を締結する」「ユーザーを削除する」といった最終実行ツールを直接渡すのは危険です。

まずは、次のように分けるべきです。

読む
検索する
候補を作る
下書きする
承認依頼を出す
実行する

そして、AIに許可するのは原則として「候補作成」「下書き」「承認依頼」までに留めます。

{
  "name": "prepare_contract_draft",
  "description": "契約書ドラフトを作成する",
  "security_policy": {
    "require_hitl": true,
    "scope": "approved_templates_only",
    "execution_mode": "draft_only",
    "external_send": false
  }
}

これは概念例です。重要なのは、AIの能力を下げることではありません。AIの実行範囲を、業務上安全な形に整えることです。

4. 人間承認：AIに任せる場所と止める場所を分ける

AIエージェント時代のHITL、つまりHuman in the Loopは、単なる確認作業ではありません。業務リスクを止めるための関門です。

特に次の操作は、人間承認を必須にすべきです。

外部メール送信
契約書の送付
支払い申請
個人情報の出力
顧客データの更新
ユーザー権限の変更
本番環境への反映
他エージェントへの機密情報共有

AIは提案する。人間が承認する。重要操作では、この境界を崩してはいけません。

5. 監査ログ：AIの「思考の足跡」を残す

AIエージェントのログは、従来のシステムログよりも複雑です。

単に「APIを呼びました」だけでは足りません。AIが何を読み、なぜその判断に至り、どのツールを選び、誰が承認し、何を実行したのかを追える必要があります。

表4：AIエージェントで残すべき監査ログ
ログ項目	記録する内容	目的
入力ログ	ユーザー指示、外部入力、参照文書	何を根拠に判断したか確認する
判断ログ	AIの計画、選択した手順、推論要約	目的逸脱や誤判断を検証する
ツールログ	呼び出したツール、引数、戻り値	誤実行や不正利用を追跡する
承認ログ	誰が、いつ、何を承認したか	責任分界を明確にする
出力ログ	作成文書、送信内容、更新結果	外部影響を確認する

ログは、事故後のためだけにあるのではありません。ログがあることで、AIエージェントの運用を継続的に改善できます。

6. サンドボックス：本番前にAIの行動を観察する

AIエージェントをいきなり本番環境へ接続するのは避けるべきです。

サンドボックスとは、AIにとっての安全な訓練場です。本番データや本番システムに触らせる前に、ダミーデータ、読み取り専用環境、検証用SaaS、限定されたMCPツールなどで動かし、AIがどのような判断をし、どのツールをどう使い、想定外の動きをしないかを観察します。

PoCの目的は、「動くこと」を確認するだけではありません。危ない動き方をしないかを確認することでもあります。

実装アーキテクチャで見る

AIエージェントのゼロトラストは、モデル単体ではなく、入力・ID・権限・ツール・承認・ログをつなぐアーキテクチャとして実装する。

AIエージェントのセキュリティは、プロンプトに「安全に動いてください」と書くだけでは実現できません。

必要なのは、業務フロー全体に制御点を置くことです。

ここがポイント：AIエージェントの前に入力検証、横にID・権限管理、後ろに承認・監査ログを置く。AIを囲い込むのではなく、AIが通る道に検証ポイントを設計する。

表5：AIエージェント・ゼロトラストの実装レイヤー
レイヤー	役割	主な対策
入力レイヤー	AIが読む情報を分類する	外部入力と社内命令の分離、信頼境界の明示
IDレイヤー	AIを識別する	専用ID、所有者、ロール、利用目的の登録
権限レイヤー	AIができることを制限する	最小権限、スコープ、JITアクセス
ツールレイヤー	AIが使う外部機能を制御する	ドラフト限定、削除不可、外部送信不可、金額上限
承認レイヤー	重要操作を人間が止める	HITL、承認ワークフロー、二重確認
監査レイヤー	AIの行動を追跡する	入力、判断、ツール実行、承認、出力のログ

MCPとA2Aではどこを見るべきか

MCPでは、AIエージェントが外部ツールやデータに接続します。したがって、見るべきポイントは「どのツールを、どの範囲で、どの権限で使えるか」です。

MCPの基本については、既存記事のMCPとは？AIツール連携の仕組み・APIとの違い・安全な始め方を解説〖2026年版〗で整理しています。

A2Aでは、AIエージェント同士が依頼と応答をやり取りします。したがって、見るべきポイントは「相手エージェントが誰か」「どの情報を渡してよいか」「返ってきた指示をどこまで信頼するか」です。

A2Aの考え方は、A2Aとは？MCPとの違いと日本企業が見落とす前提条件〖2026年版〗で詳しく解説しています。

表6：MCP/A2Aにおけるゼロトラスト設計ポイント
対象	主なリスク	設計ポイント
MCPツール	Tool Misuse、ツール説明の汚染、過剰権限	ツール登録審査、スコープ制限、実行ログ
外部MCPサーバー	サプライチェーン汚染、信頼境界の崩壊	接続先検証、許可リスト、サンドボックス
A2A通信	なりすまし、指示改ざん、文脈汚染	相手認証、メッセージ検証、共有情報の制限
他エージェントへの委任	責任分界の曖昧化、連鎖的な誤実行	委任範囲、戻り値検証、監査ログ

運用ではどう判断するか

AIエージェントのゼロトラストは、導入時だけでなく、運用中に継続して見直す必要がある。

AIエージェントは、一度設定して終わりではありません。

利用業務が増える。接続ツールが増える。参照データが増える。連携する他エージェントが増える。こうしてAIの活動範囲が広がるほど、最初に決めた権限設計は古くなります。

したがって、AIエージェントのゼロトラスト設計では、運用中の見直しが重要です。

運用レビューのチェックポイント

表7：AIエージェント運用レビューのチェックポイント
頻度	確認項目	見るべきポイント
毎週	異常なツール呼び出し	急増したAPI呼び出し、失敗率、外部送信要求
毎月	権限の棚卸し	使われていない権限、広すぎるスコープ
四半期	業務範囲の見直し	当初目的から逸脱していないか
変更時	新ツール・新データ接続	サンドボックス検証、ログ取得、人間承認
事故時	原因追跡と停止手順	どの入力、判断、ツール実行が原因だったか

よくある失敗

AIエージェントのゼロトラスト設計で、よくある失敗は次の通りです。

人間のアカウントをAIに使わせる：操作主体が曖昧になり、監査できなくなる
PoCの広い権限を本番に持ち込む：検証環境で「とりあえず全部読ませてみた」設計を、そのまま本番へ持ち込むと、AIエージェントは新入社員の顔をした、広すぎる権限を持つ業務アカウントになる
ツール単位で権限を分けない：読み取りと削除、下書きと送信が同じ扱いになる
ログをツール側だけに任せる：AIの判断経路が追えない
承認ポイントを後付けにする：業務フローに組み込めず形骸化する

AI活用が失敗する組織設計の問題については、〖2026年最新〗AI活用はなぜ失敗するのか？「Agentic AI」時代の全社OS化と組織設計の教科書も参考になります。

導入チェックリスト

AIエージェントのゼロトラスト設計は、PoC前に確認すべき項目である。本番移行直前に慌てて追加するものではない。

AIエージェントを業務に入れる前に、以下を確認してください。

表8：AIエージェント・ゼロトラスト設計チェックリスト
No	確認項目	確認ポイント
1	AIエージェント専用IDを用意したか	人間アカウントと分離し、所有者と責任者を登録する
2	業務目的を明文化したか	何のために動くAIかを定義する
3	アクセス可能なデータを絞ったか	全社データではなく、必要な範囲に限定する
4	利用できるツールを棚卸ししたか	読み取り、下書き、送信、削除、更新を分ける
5	重要操作に人間承認を置いたか	外部送信、契約、支払い、削除、権限変更をAIだけで完結させない
6	監査ログを取れるか	入力、判断、ツール実行、承認、出力を追跡できるようにする
7	サンドボックスで検証したか	ダミーデータや読み取り専用環境で動作を確認する
8	緊急停止手段があるか	異常時にツール権限、外部送信、連携を止められるようにする
9	MCP/A2A連携先を検証したか	外部ツール、外部エージェント、委任先の信頼性を確認する
10	運用レビューの頻度を決めたか	権限棚卸し、ログ確認、業務範囲見直しを定期化する

このチェックリストは、第4回で扱う「AIエージェント導入チェックリスト」の中核になります。

一次情報からどこまで言えるか

一次情報が示しているのは、AIエージェントをモデル単体ではなく、ID・権限・ツール・監査の対象として管理すべきだという流れである。

ここまでの内容は、現場の感覚だけで組み立てた話ではありません。AIエージェントのゼロトラスト設計を考えるうえで、特に重要な一次情報は以下です。

NIST SP 800-207 Zero Trust Architecture：ゼロトラストを、ネットワーク境界中心ではなく、ユーザー・資産・リソース中心のセキュリティモデルとして整理
OWASP Top 10 for Agentic Applications 2026：ASI02 Tool Misuse and Exploitation、ASI03 Identity and Privilege Abuse、ASI07 Insecure Inter-Agent Communication、ASI10 Rogue Agents など、AIエージェント特有のリスクを体系化
Okta：AI agents as privileged users：AIエージェントを特権を持つ機械IDとして扱い、PAMやID管理の対象に入れるべきだと整理
Palo Alto Networks Unit 42：Agent Session Smuggling として、A2Aのようなエージェント間通信の文脈リスクを解説
NIST AI Risk Management Framework：AIリスク管理を統治・マッピング・測定・管理の観点で整理

これらの資料に共通しているのは、AIエージェントを「便利なAI機能」としてではなく、権限を持って業務に参加する実行主体として管理すべきだという点です。そこで本記事では、NISTのゼロトラスト思想とAI RMF、OWASP Agentic Top 10、OktaやUnit 42の知見を、専用ID・最小権限・ツールスコープ・人間承認・監査ログ・サンドボックスという6つの原則に落とし込んでいます。

AIエージェントセキュリティ4本シリーズの地図

本記事は第3回である。第1回で全体像を掴み、第2回で見えない命令を理解し、第3回で守る設計へ進む。

表9：AIエージェントセキュリティ4本シリーズの構成
回	テーマ	役割
第1回	AIエージェントセキュリティとは？	全体像、リスク、防御原則を整理する入口
第2回	プロンプトインジェクション2.0	AIエージェントを操る「見えない命令」の脅威を解説
第3回	AIエージェントのゼロトラスト設計	ID、権限、監査ログ、人間承認の実装思想を整理
第4回	AIエージェント導入チェックリスト	経営者・CTO・情シスが使える実務チェックリスト