AIエージェント時代のゼロトラスト｜ユーザーではなくエージェントが最弱リンクになる

結論：AIエージェントは「新しい社員」ではなく「高速に動く非人間ID」である

AIエージェントの導入が進むほど、企業のゼロトラスト設計は人間ユーザー中心から、AIエージェント中心へ広げる必要がある。

2026年6月のZscaler Zenith 2026に関するTechRadar報道では、Zscaler CEO Jay Chaudhry氏が、従来はユーザーが最弱リンクだったが、いまはAIエージェントが最弱リンクになりつつある、という趣旨の警鐘を鳴らしたと報じられている。報道では、AIエージェントが自律的に判断し、メール、データベース、ブラウザ、拡張機能、プラグイン、MCP/A2Aのような接続先を通じて、機械速度で動く点が論点になっている。

本記事では、この発言や製品発表の詳細をZscaler公式一次ソースとして断定するのではなく、報道をきっかけに、企業がAIエージェント導入前に見直すべきゼロトラストの実務論点を整理する。

重要なのは、AIエージェントを「便利なチャット」や「デジタル社員」として雑に扱わないことだ。実務上は、AIエージェントは次のような存在として設計すべきである。

• 人間ではないが、業務データへアクセスする
• 人間ではないが、SaaSやAPIを操作する
• 人間ではないが、判断、分類、起票、送信、更新を実行する
• 人間ではないが、ログ、権限、責任分界が必要になる

つまり、AIエージェントは「非人間ID」であり、ユーザーアカウント、サービスアカウント、APIキー、OAuthアプリ、MCPサーバーと同じく、棚卸しと制御の対象である。

従来のゼロトラストと何が違うのか

NIST SP 800-207のゼロトラストは、ネットワーク境界を暗黙に信頼せず、アクセスごとに主体、端末、資産、権限、ポリシーを評価する考え方である。この考え方自体は、AIエージェント時代にも有効である。

しかし、AIエージェントが業務に入ると、評価すべき対象が増える。

従来のゼロトラスト	AIエージェント時代に追加すべき観点
人間ユーザーのID	AIエージェント、サービスアカウント、APIトークン
端末の状態	エージェントの実行環境、ブラウザ拡張、MCPサーバー
アプリ単位のアクセス	ツール単位、操作単位、データ項目単位のアクセス
通信元と通信先	エージェントが呼び出す外部API、SaaS、LLM、検索先
操作ログ	プロンプト、ツール呼び出し、参照データ、実行結果
ユーザー教育	プロンプト注入、外部文書、代理実行へのガードレール

AIエージェントは、ひとつの画面だけで完結しない。メールを読み、CRMを参照し、チケットを起票し、Slackへ通知し、場合によってはデータベースを更新する。だからこそ「ユーザーがログインできるか」だけではなく、「エージェントがどの操作を、誰の権限で、どこまで実行できるか」を制御する必要がある。

なぜAIエージェントは最弱リンクになり得るのか

1. 機械速度で動く

人間は迷う、確認する、疲れる、止まる。一方で、AIエージェントは設計次第で連続実行できる。誤った指示、過剰な権限、外部から注入されたプロンプトが組み合わさると、短時間で大量の検索、送信、更新、削除が起きる可能性がある。

2. 権限を借りて動く

AIエージェントは、何らかのユーザー権限、サービスアカウント、OAuth許可、APIキーを使って動く。権限が広すぎると、AIが本来不要なデータまで参照できる。前回の記事で扱ったMicrosoft 365 CopilotのSearchLeak報道も、AIが既存権限を前提にデータへアクセスする点が重要な論点だった。

3. 外部入力を解釈する

AIエージェントは、メール、Webページ、PDF、チャット、チケット、社外文書など、外部入力を読む。そこに悪意ある指示や紛らわしい文面が混ざると、プロンプト注入や意図しないツール実行につながる。

4. ログが設計されていないと追跡できない

人間の操作ログは残していても、AIのプロンプト、参照文書、ツール呼び出し、出力、承認者、失敗理由まで記録していない企業は多い。ログがなければ、誤送信や過剰アクセスが起きても原因を追えない。

5. 責任分界が曖昧になりやすい

AIが下書きし、人が送信したのか。AIが自動送信したのか。AIが分類し、人が承認したのか。AIが勝手に更新したのか。ここが曖昧なままでは、事故時に運用も法務も止まる。

中小・中堅企業が確認すべき7項目

1. AIエージェント台帳を作る

まず、社内で動いているAIエージェント、RAG、チャットボット、MCPサーバー、業務自動化スクリプト、OAuthアプリ、API連携を一覧化する。

項目	記録する内容
名称	エージェント名、ツール名、連携名
管理部署	情シス、DX、営業、CS、開発など
実行環境	SaaS、社内サーバー、クラウド、端末、ブラウザ拡張
利用ID	人間ID、サービスアカウント、APIキー、OAuthアプリ
参照データ	メール、CRM、会計、ファイル、チケット、DB
実行できる操作	読み取り、作成、更新、削除、送信、外部連携
ログ	何が、どこに、何日保存されるか

台帳がない状態でAIエージェントを増やすと、シャドーAIとシャドーITが一体化する。

2. 人間IDと非人間IDを分ける

AIエージェントを個人アカウントで動かすと、退職、異動、権限変更、監査が難しくなる。最初から専用の非人間ID、サービスアカウント、アプリ登録で管理し、所有者と利用目的を明記する。

ただし、専用IDに強すぎる権限を与えてはいけない。読み取り専用、対象フォルダ限定、対象API限定、時間限定、承認付き更新など、最小権限を徹底する。

3. 操作単位で権限を分ける

AIに「CRMへアクセスできる」権限を与えるだけでは広すぎる。実務では、閲覧、検索、下書き、起票、更新、削除、送信を分ける。

最初は次の順番が安全である。

段階	AIに許可すること	人間の関与
1	検索、要約、分類	出力確認
2	下書き、候補提示、チケット起票案	承認後に登録
3	低リスクな起票、通知、タグ付け	事後確認
4	顧客送信、DB更新、削除	原則として人間承認

AIエージェント導入初期に、削除、送信、決裁、契約変更を自動実行させるべきではない。

4. 通信先を制限する

AIエージェントは、LLM API、検索API、SaaS、MCPサーバー、外部Webhookへ通信する。通信先を無制限にすると、情報流出や意図しない外部連携のリスクが高まる。

最低限、次を決める。

• 利用してよいLLM/API
• 接続してよいSaaS
• 外部Webhookの作成権限
• MCPサーバーの登録・承認手順
• 個人情報、契約情報、機密文書を外部送信してよい条件
• ログに残す通信先、送信量、エラー

5. プロンプトとツール呼び出しをログ化する

AIの回答だけを保存しても、監査には足りない。少なくとも次のログを残したい。

ログ	目的
入力プロンプト	何を依頼したかを確認する
参照データ	どの文書・レコードを見たかを確認する
ツール呼び出し	どのAPI・SaaSを実行したかを確認する
出力	何を生成・送信・登録したかを確認する
承認者	人間確認があったかを確認する
エラー・停止理由	想定外動作を改善する

ログは「事故後の証拠」だけではない。AIエージェントの改善、KPI測定、業務設計の見直しにも使う。

6. 停止条件を決める

AIエージェントには、動かす条件だけでなく、止める条件が必要である。

たとえば、次のような条件を事前に決める。

• 想定外の外部ドメインへ通信しようとした
• 個人情報を含む出力を外部送信しようとした
• 削除、決裁、契約変更など高リスク操作を実行しようとした
• 1時間あたりの処理件数が通常の数倍に増えた
• 根拠文書のない回答を返した
• 承認なしで顧客向けメッセージを作成・送信しようとした

停止条件がないAIエージェントは、便利な自動化ではなく、制御できない業務プロセスになる。

7. 人間の責任者を置く

AIエージェントごとに、技術責任者、業務責任者、セキュリティ責任者を決める。ひとりで兼ねてもよいが、責任が空欄であってはいけない。

役割	責任
業務責任者	何を自動化し、どこまで任せるかを決める
技術責任者	実装、連携、ログ、障害対応を見る
セキュリティ責任者	権限、通信先、監査、停止条件を見る
承認者	高リスク操作の最終判断を行う

AIエージェントの導入は、情シスだけでも、現場だけでも完結しない。業務とセキュリティを同じテーブルで設計する必要がある。

30日でできるAIエージェント・ゼロトラスト点検

1〜7日目：AI利用と自動化を棚卸しする

Copilot、ChatGPT、Claude、Gemini、RAG、チャットボット、Zapier、Make、n8n、MCP、API連携、社内スクリプトを一覧化する。部門ごとに「誰が、何を、どのデータで使っているか」を確認する。

8〜14日目：非人間IDとAPIキーを洗い出す

サービスアカウント、OAuthアプリ、APIキー、Webhook、共有アカウント、退職者由来の連携を確認する。所有者が不明な連携は停止候補にする。

15〜21日目：高リスク操作を分ける

送信、削除、更新、決裁、契約変更、個人情報出力、外部共有を高リスク操作として定義する。AIが自動実行してよい操作と、人間承認が必要な操作を分ける。

22〜30日目：ログと停止条件を決める

プロンプト、参照データ、ツール呼び出し、出力、承認者、エラーをどこに保存するか決める。停止条件を定義し、少なくとも最初の1業務では人間承認付きで始める。

GXOが支援できること

AIエージェントのゼロトラスト設計は、製品選定だけでは終わらない。GXOでは、次のような論点をまとめて整理する。

• AIエージェント台帳の作成
• 非人間ID、APIキー、OAuthアプリの棚卸し
• AIに見せてよいデータ範囲の整理
• MCP/API/外部SaaS接続の権限設計
• プロンプト、ツール呼び出し、出力ログの設計
• 高リスク操作の人間承認フロー
• AI導入前のFDE+ Ready、セキュリティ診断、運用設計

AIエージェントを業務実装するなら、「何を自動化するか」と同じくらい、「何を自動化させないか」が重要である。

→ AIエージェントの権限・ログ設計を相談する

→ FDE+ ReadyでAI導入前チェックを行う

まとめ

• AIエージェントは、人間ユーザーではなく非人間IDとして管理する。
• 従来のゼロトラストに加えて、AIエージェント、MCP、APIキー、OAuthアプリ、ツール呼び出し、プロンプト、出力ログを管理対象に入れる。
• 最初は検索、分類、下書き、起票案から始め、送信、削除、更新、決裁は人間承認を残す。
• AIエージェント台帳、非人間IDの棚卸し、操作単位の権限、通信先制限、ログ、停止条件を30日で整える。
• AI導入は「便利にする設計」と「止められる設計」を同時に進めるべきである。

関連記事

• Microsoft 365 CopilotのSearchLeak報道から考える｜社内AI導入前に確認すべき権限棚卸し
• AIエージェント導入はPoCから業務実装へ｜最初の1業務を選ぶ7つの基準
• AIエージェント導入前に確認すべきMCP・ツール権限の設計
• AI導入前にSASE・ゼロトラストを見直す理由
• AIエージェントを「PoC止まり」から全社展開へ

参考資料

• TechRadar「Yesterday, a user was the weakest link. Today these agents are becoming the weakest link」 https://www.techradar.com/pro/security/yesterday-a-user-was-the-weakest-link-today-these-agents-are-becoming-the-weakest-link-zscaler-ceo-jay-chaudhry-on-why-he-believes-zero-trust-can-secure-the-ai-agents-of-the-present-and-the-future

• NIST SP 800-207「Zero Trust Architecture」 https://csrc.nist.gov/pubs/sp/800/207/final

• arXiv「Beyond Zero: Enterprise Security for the AI Era」 https://arxiv.org/abs/2605.22985

• arXiv「Caging the Agents: A Zero Trust Security Architecture for Autonomous AI in Healthcare」 https://arxiv.org/abs/2603.17419

AIエージェントを導入する前に、ID、権限、ログ、通信先、停止条件を点検しませんか。

AIエージェントの権限・ログ設計を相談する

FDE+ ReadyでAI導入前チェックを行う