【速報】Zenith Live 2026現地レポート(第三部)

【第三部】技術解説

こんにちは、エーピーコミュニケーションズ 0-WANの山根です。 Zenith Live'26参加レポートの第三部です。第一部では、Zenith Live'26全体の雰囲気やキーノート全体のあらすじを中心に紹介しました。第二部では、今回発表された新機能やアップデートを中心に、Zscaler Zero Trust AI Security、AI Access Graph、AI Broker、AI Endpoint Security、AI Guard、AI Red Teamingなどの概要をまとめました。第三部となる今回は、少し技術寄りに踏み込みます。ただし、いきなり細かい話をするのではなく、今回の発表を理解するうえで重要になる考え方を整理しながら、

なぜAI時代に従来のセキュリティだけでは足りないのか
AI Agentとは何が危険なのか
MCP/MCP Serverとは何か
AI Access Graphがなぜ重要なのか
AI Broker/MCP Brokerは何を制御するのか
AI Endpoint SecurityやAI Guardはどこを守るのか
これらがゼロトラストとどうつながるのか

を、できるだけわかりやすく解説していきます。できる限り現地で参加している他パートナーの皆様も、今回の発表を整理して消化できるように記事を書いていきたいと思います。

ZenithLive26全リンク集

第一部はこちら ⇒techblog.ap-com.co.jp
第二部はこちら ⇒techblog.ap-com.co.jp
第三部はこちら ⇒techblog.ap-com.co.jp
第四部はこちら ⇒techblog.ap-com.co.jp

今回の発表で一番大きく感じた変化

今回のZenith Live'26で繰り返し語られていたのは、AIは単なる「便利なツール」ではなくなりつつある、という点です。これまでは、人間がブラウザーでSaaSやWebアプリにアクセスし、必要な情報を入力し、結果を受け取る世界が中心でした。セキュリティも、人間のアクセスをどう守るか、デバイスをどう守るか、データをどう守るか、ネットワークをどう分離するか、という考え方が中心でした。

しかしAI Agentの登場によって、前提が変わります。人間が操作するのではなく、AI Agentが人間の代わりに情報を読み、判断し、外部システムにアクセスし、ツールを実行し、データを加工し、場合によっては業務処理そのものを実行するようになります。つまり、守るべき対象が「人間のアクセス」だけではなくなります。 AI Agentそのものが、新しいアクセス主体になります。ここが非常に重要です。

キーノートでは「The tools are the workforce.」という印象的なメッセージがありました。直訳すると「ツールが労働力になる」という意味です。これは、非常に強いメッセージだと感じました。これまでは、ツールは人間が使うものでした。しかしこれからは、ツールやAgentが、人間の代わりに仕事を進める存在に変わることを強調しています。これは正にパラダイムシフトです。そうなると、セキュリティや対象とする認証認可の考え方も変わります。つまりは「誰がログインしたか」だけでは足らなくなるということです。

これからは、

どのAI Agentが動いたのか
そのAgentは誰の権限で動いたのか
どのMCP Serverに接続したのか
どのToolを呼び出したのか
どのデータにアクセスしたのか
そのデータは機密情報なのか
その操作は本当に業務上必要なのか
そのプロンプトやレスポンスは安全なのか

まで見なければいけません。これらをシステムにおいて実現するには、全通信を統合するプラットフォームにおいて可視化、監視、分析、調査、認証認可、制御をしなければなりません。ここに、今回の発表の本質があると感じました。

従来のセキュリティ製品だけでは、なぜ足りないのか

今回の発表で非常にわかりやすかったスライドの一つが、「AI Visibility is Fragmented」です。

このスライドでは、既存のセキュリティ製品がAIの一部しか見えていないことが示されていました。例えば、ID管理の仕組みは「誰がログインしたか」はわかります。しかし、そのAI AgentがどのToolを呼び出したのか、どのデータに触れたのか、どこまで細かい権限を持っていたのかまでは見えない場合があります。 EDRはエンドポイント上でAIツールが動いていることを検知できるかもしれません。しかし、そのAIがどの業務意図で動き、どのデータにアクセスし、どの外部サービスと通信しているのかまでは見えない場合があります。 Firewallはネットワーク通信を見ることができます。しかし、通信の中に埋め込まれたAIの文脈、プロンプト、Tool Call、Agentの意図までは十分に把握できない可能性があります。 DLPやCASBはデータの持ち出しやSaaS利用を制御できます。しかし、AI Agentが複数回のやり取りを通じて徐々に情報を引き出すようなケースや、意図ベースのリスク判定までは難しい場合があります。 CSPMはパブリッククラウド上のAIリソースを見つけられるかもしれません。しかし、そのAIがどのIDで動き、どのデータセットに接続し、どのアプリケーションやMCP Serverとつながっているかまでは別の問題です。つまり、AI時代のセキュリティでは「点」で見るだけでは足りません。点と点をつなげる必要があります。これが、今回Zscalerが強調していたAI Access Graphの考え方につながります。

まずMCPをざっくり理解する

ここから少し技術的な話に入ります。今回の発表で何度も出てきたキーワードの一つが、MCPです。 MCPは、Model Context Protocolの略で、AI Agentが外部のツールやシステム、データソースに接続するための仕組みです。 AI Agent単体では、社内システムのデータを取得したり、チケットを更新したり、ファイルを検索したり、クラウド上のリソースを操作したりすることはできません。そのためには、外部システムとやり取りするための「窓口」が必要です。

その窓口の一つがMCP Serverです。

イメージとしては、以下のような流れです。

    ユーザー
      ↓
    AI Agent
      ↓
    MCP Client
      ↓
    MCP Server
      ↓
    Tool/API/Database/SaaS/Cloud
      ↓
    業務システムやデータ

AI Agentが「このデータを取得したい」「この処理を実行したい」と考えたとき、MCP Serverを通じてToolを呼び出します。このToolが、非常に重要です。 Toolとは、AI Agentが実際に何かを実行するための機能です。例えば、次のようなものが考えられます。

チケットを作成する
データベースを検索する
ファイルを読み取る
ソースコードを取得する
クラウドリソースを操作する
メールを送る
設定を変更する
ユーザー情報を参照する
セグメントやポリシーを変更する

ここで問題になるのは、AI Agentが強い権限を持ったToolを呼び出せるようになると、人間が意図していない操作まで実行できてしまう可能性があることです。つまり、MCPは便利である一方で、適切に制御しなければ新しい攻撃経路にもなり得ます。

「MCP Server」＝「業務用の道具箱」として考える

私がイメージしやすかったたとえがあります。 MCP ServerはAI Agentのための「業務用の道具箱」のようなものです。AI Agentは作業者、MCP Serverは道具箱と考えます。 Toolは道具箱の中にあるドライバー、レンチ、釘、カッターなどを想像してください。作業者が適切な道具だけを使ってくれるなら便利です。しかし、例えば子供が釘やカッターなどを持つとどうでしょうか。必要以上に強力な道具まで自由に使えてしまうと大変危険です。例えば、問い合わせ対応だけを行うAI Agentに、本来不要な削除権限や管理者用Toolが渡されていたらどうでしょうか。人間であれば「この操作はまずい」と気づけますが、AI Agentは、与えられた指示やコンテキストに従ってToolを呼び出す可能性が十分にあります。このとき、プロンプトインジェクションや悪意ある入力によって、AI Agentが意図しないToolを呼び出すリスクもあります。

そのため、AI Agent時代には、次のような制御が必要になります。

Agentが使えるToolを最小限にする
どのユーザーがどのAgentを使えるかを制御する
どのAgentがどのMCP Serverに接続できるかを制御する
Tool Callをトランザクション単位で可視化する
危険なTool利用を検知する
機密データへのアクセスを制御する
実行内容を監査できるようにする

これは、まさにゼロトラストの考え方そのものです。「つながること」と「信頼すること」を分ける。 AI Agentにも、この考え方が必要になります。

MCP Brokerは何をするのか

今回の発表では、MCP Serverを前面でまとめて扱うためのMCP Brokerの考え方も紹介されました。 MCP Brokerは、MCP ServerやTool Callを制御するための中間レイヤーと考えるとわかりやすいです。ユーザーやAI Agentが直接MCP Serverへ自由にアクセスするのではなく、MCP Brokerを通してアクセスします。これにより、以下のようなことが可能になります。

どのAgentがどのMCP Serverを使っているかを把握する
どのToolが呼び出されたかを記録する
Tool Callをトランザクション単位で可視化する
ユーザーやロールに応じて使えるToolを制限する
管理者ロールであっても必要最小限のToolだけに絞る
危険な操作をブロックする
Agentic RegistryとしてAgentやMCPの関係を管理する

ここで重要なのは、MCP Brokerは単なる通信中継ではないという点です。 AI Agentが何をしようとしているのかを見て、必要に応じて制御するためのポイントになります。従来のネットワークで言えば、FirewallやProxy、API Gatewayのような考え方に近い部分もあります。しかしMCP Brokerが扱う対象は、単なるIPアドレスやURLではありません。 Agent、Tool、データ、ID、意図、コンテキストです。ここが新しい部分です。

AI Agentで問題になる4つのリスク

今回の発表では、Agent時代のリスクとして、以下のような観点が示されていました。

1. Agent Sprawl

Agent Sprawlとは、AI Agentが急速に増殖し、どこで何が動いているのかわからなくなる状態です。 SaaSの利用が広がったときにShadow ITが問題になりました。生成AIの利用が広がったときにはShadow AIが問題になりました。今後は、Shadow Agentのような問題が出てくる可能性があります。開発者が作ったAgent、SaaSに組み込まれたAgent、業務部門が使い始めたAgent、ブラウザー拡張として動くAgent、ローカル環境で動くAgentなど、様々な形でAgentが増えていきます。これらを把握できなければ、守ることはできません。

2. Agentic Identities

AI Agentは人間ではありません。しかし、何らかのIDや権限を使ってシステムにアクセスします。この「非人間ID」をどう扱うかが重要になります。従来のID管理では、人間のユーザーやサービスアカウントを中心に考えていました。しかしAI Agentでは、人間、Agent、サービスアカウント、クラウドロール、MCP Server、Toolが複雑につながります。そのため、「誰がログインしたか」だけではなく、「どのAgentが、どのIDで、どのデータにアクセスしたか」を見る必要があります。

3. Agent Authorization

Agent Authorizationは、AI Agentにどこまで権限を与えるかという問題です。強力なAgentほど便利ですが、その分リスクも大きくなります。例えば、Agentがソースコードを読める、クラウド環境を操作できる、データベースを検索できる、ファイルを書き換えられる、外部に通信できる、という状態では、権限管理が非常に重要です。ここでも、最小権限の考え方が必要になります。人間に対して最小権限を適用するのと同じように、Agentに対しても最小権限を適用する必要があります。

4. Agent Intent

Agent Intentは、Agentが何をしようとしているのか、という意図の問題です。これは非常に難しい領域です。同じTool Callでも、業務上正しい操作の場合もあれば、危険な操作の場合もあります。例えば、ソースコードを検索すること自体は開発業務では普通です。しかし、その内容を外部AIサービスに送信する、機密情報を含むファイルを読み取る、認証情報を探す、実行可能なコードを生成する、といった文脈になるとリスクが変わります。つまり、単に「このAPIを呼んだ」だけではなく、「何の目的で呼んだのか」を理解する必要があります。「人間の指示だけの一方的な考えではなく、AIを介すことで目的を意識する必要がある」ここが、AIセキュリティの難しさだと思います。

AI Access Graphとは何か

今回の発表で、私が特に注目したのがAI Access Graphです。

AI Access Graphは、AIに関係するアセット同士のつながりを可視化するための考え方です。単に「AIアプリが使われている」ことを見るのではありません。 AIアプリ、AIモデル、AI Agent、MCP Server、Tool、データセット、ID、ユーザー、エンドポイント、クラウド、SaaS、ソースコードなどをつなげて見ます。ポイントは、関係性です。例えば、あるAI Agentがあったとします。そのAgentについて、以下のようなことを確認できる必要があります。

どのユーザーが使っているのか
どの端末で動いているのか
どのモデルを参照しているのか
どのMCP Serverに接続しているのか
どのToolを呼び出しているのか
どのデータセットにアクセスしているのか
どのクラウド環境で動いているのか
どのソースコードから作られているのか
どの権限を持っているのか
どのリスクがあるのか

このような情報を点ではなく、線でつなぐのがAI Access Graphです。 AIを見つけるだけなら、比較的簡単かもしれません。しかし、そのAIがどのデータとつながり、どのIDで動き、どの権限を持ち、どのリスクを生んでいるかを理解するのは難しい。この課題に対して、AI Access Graphは非常に重要なアプローチだと感じました。

データとIDのリネージを見る重要性

AI Access Graphの本質は、データとIDのリネージを理解することだと思います。

リネージとは、ざっくり言うと「どこから来て、どこへ行くのか」というつながりです。データリネージであれば、データがどこにあり、どのシステムに渡り、どのAIに使われ、どの出力につながったのかを見ることです。 IDリネージであれば、どのユーザー、どのAgent、どのサービスアカウント、どのロール、どの権限が関係しているのかを見ることです。 AI時代には、この2つが非常に重要になります。なぜなら、AIはデータを直接扱うからです。従来のアプリケーションでは、アプリケーション側に制御ロジックがありました。ユーザーはアプリケーションを通じてデータにアクセスしていました。しかし、AI AgentやMCP Serverを使う世界では、AIが複数のToolを経由してデータにアクセスする可能性があります。その結果、従来のアプリケーション境界だけではリスクを判断しづらくなります。

例えば、以下のような問いに答えられる必要があります。

このAI Agentは、どの機密データに到達できるのか
このユーザーは、Agent経由で本来アクセスできないデータに到達できないか
このMCP Serverは、どのToolを通じて重要システムに接続できるのか
このローカルAIモデルは、企業データを学習・出力していないか
この開発支援AIは、ソースコードや認証情報に触れていないか
このAIアプリは、個人アカウントで使われていないか

これらを可視化するためには、単一のログだけでは足りません。 ID、データ、エンドポイント、クラウド、SaaS、ネットワーク、プロンプト、レスポンス、Tool Callをつなげて見る必要があります。ここにAI Access Graphの価値があります。

AI Asset Managementは何を管理するのか

AI Access Graphを成立させるためには、まずAIアセットを発見する必要があります。今回の発表では、AI Asset Managementの対象がかなり広く示されていました。

対象になるのは、例えば以下のようなものです。

パブリックAIアプリ
SaaSに組み込まれたAI機能
AIモデル
ローカルAIモデル
AI Agent
AI Assistant
MCP Server
Tool/Tool Call
データセット
ソースコードリポジトリ
クラウド上のAIサービス
ブラウザー拡張
開発支援AIツール
エンドポイント上で動くAI関連プロセス

ここで重要なのは、AIは一つの場所に存在するわけではないということです。 AIは、ブラウザーにもいます。SaaSにもいます。エンドポイントにもいます。クラウドにもいます。ソースコードにもいます。開発環境にもいます。MCP Serverにもいます。そのため、AI Asset Managementは単なるアプリ一覧ではありません。企業内に存在するAI関連アセットを横断的に発見し、関係性を整理し、リスクを把握するための土台になります。発表では、パブリックAIアプリの可視化対象が300から2,900以上に拡大されたことも紹介されていました。 AIアプリは毎日のように増えています。このスピード感を考えると、手作業での棚卸しや、申請ベースだけの管理では追いつかないと感じました。

AI Endpoint Securityとは何を守るのか

次に、AI Endpoint Securityです。

AI Endpoint Securityは、端末上で動くAI利用を可視化・制御する考え方です。ここでいうエンドポイント上のAIは、単にブラウザーで使う生成AIサービスだけではありません。今回の発表では、大きく以下のような領域が示されていました。

ブラウザー経由で利用するAI
SaaSや業務アプリに埋め込まれたAI
端末上で動くAI Agent
開発者向けAIツール
ローカルAIモデル
ブラウザー拡張
AI Assistant
AI Plugin
AI Skill

この中でも個人的に重要だと感じたのは、開発者向けAIツールとローカルAIモデルです。開発者向けAIツールは非常に便利です。コード生成、コードレビュー、テスト作成、調査、ドキュメント作成など、開発生産性を大きく高めます。一方で、ソースコード、認証情報、設定ファイル、社内仕様、設計情報など、非常に重要な情報に触れる可能性があります。さらに、AI Agentが端末上でToolやShellを実行するようになると、従来の「ユーザーが手で操作する端末」とはリスクの性質が変わります。端末の中で、AIが自律的に動く可能性があるからです。そのため、AI Endpoint Securityでは以下のような観点が重要になります。

どのAIツールが端末で使われているか
個人アカウントでAIサービスにログインしていないか
法人アカウントのみ利用させられるか
クリップボード経由の情報持ち出しを防げるか
ローカルAIモデルが危険なファイルを含んでいないか
AI Agentが危険なToolやSkillを持っていないか
ソースコードや機密情報が外部AIに送信されていないか

この領域は、今後の企業ITにおいてかなり重要になると思います。特に開発組織では、AIツールの利用を止めることは現実的ではありません。むしろ、使わないことが競争力低下や業務効率の低下につながる可能性もあります。だからこそ、「禁止」ではなく「安全に使わせる」ための仕組みが必要になります。

Secure AI Access/AI Guardの役割

AIを安全に使わせるうえで重要になるのが、Secure AI AccessとAI Guardです。 Secure AI Accessは、AIサービスへのアクセスを制御する考え方です。従来であれば、「このWebサイトを許可するか、ブロックするか」という制御が中心でした。しかしAIでは、それだけでは足りません。同じAIサービスでも、以下のような違いがあります。

個人アカウントで使っているのか
法人アカウントで使っているのか
どの部門のユーザーが使っているのか
どのデータを入力しようとしているのか
ソースコードを送信していないか
個人情報や機密情報を送信していないか
出力結果に危険な内容が含まれていないか
業務目的に合った使い方か
攻撃的なプロンプトではないか

AI Guardは、こうしたプロンプトやレスポンスを検査し、ポリシーを適用するための仕組みとして紹介されていました。発表では、AI Guardの役割として以下の観点が示されていました。

Access Control
Data Protection
Content Moderation
Threat Protection

これらのメッセージを技術的に理解した上で意訳すると、

誰にAI利用を許可するか
どのAIサービスを使わせるか
どのデータを送ってよいか
危険な内容をブロックできるか
不適切な出力を制御できるか
業務外利用やポリシー違反を防げるか

ということになります。ここでも大事なのは、「AIを止める」ではなく「AIを安全に使わせる」という考え方です。 AI活用を進めたい事業部門と、リスクを抑えたいセキュリティ部門。この両方を成立させるためには、AI Guardのような実行時制御が重要になると感じました。

AI BrokerはAI時代の制御点になる

AI Brokerは、AI利用に関する通信や処理を仲介し、制御するための考え方です。今回の発表では、Zero Trust Exchange for AI、AI Broker、MCP/A2A、Registryといったキーワードが出てきました。ここでいうA2Aは、Agent to Agent、つまりAgent同士の通信や連携を指す文脈で使われています。これからのAI環境では、人間がAIに依頼するだけではありません。 Agentが別のAgentを呼び出すことがあります。AgentがMCP Serverを通じてToolを実行することがあります。Agentが社内データを参照し、別のシステムへ処理を渡すことがあります。そうなると、AIの通信はかなり複雑になります。

    User
      ↓
    AI Agent A
      ↓
    AI Agent B
      ↓
    MCP Server
      ↓
    Tool
      ↓
    Data/SaaS/Cloud/Private App

このような世界では、どこかに制御点が必要です。その制御点がAI Brokerです。 AI Brokerが担うべき役割は、単なる通信中継ではありません。

Agentを登録・管理する
MCP Serverを管理する
A2A通信を可視化する
Tool Callを制御する
データアクセスを判断する
プロンプトとレスポンスを検査する
ポリシーを適用する
リスクをスコアリングする
必要に応じてブロック・隔離・修復する

こうした制御点がなければ、AI Agentが増えたときに全体を管理できなくなります。この発表を聞いて、AI Brokerは将来的に非常に重要なコンポーネントになると感じました。

AI Red Teamingは「作って終わり」ではない世界への備え

AIアプリやAI Agentを安全に運用するためには、作って終わりでは不十分です。

今回の発表では、AI Application Lifecycleとして、Build、Deploy、Runの流れが示されていました。このライフサイクル全体に対して、Continuous AI Red Teamingを行う必要があるというメッセージです。 AI Red Teamingとは、AIアプリやAI Agentに対して攻撃シミュレーションを行い、弱点を見つける取り組みです。対象は、単なるモデルだけではありません。

AIモデル
AIアプリ
AI Agent
MCP Server
Tool
プロンプト
レスポンス
ガードレール
データアクセス
業務ロジック

などが対象になります。発表では、Prompt Hardening、MCP Red Teaming、Compliance Heat Map、Bring Your Own Detectorなどの考え方も紹介されていました。 Prompt Hardeningは、プロンプトをより安全にする取り組みです。例えば、AI Agentに与えるシステムプロンプトや指示が曖昧だと、想定外の動作をする可能性があります。プロンプトインジェクションに弱い設計になっている場合もあります。 MCP Red Teamingは、MCP ServerやTool Callに対して攻撃シミュレーションを行う考え方です。 AI AgentがMCP経由でどこまで危険な操作を実行できてしまうのかを確認することは、今後かなり重要になると思います。従来のWebアプリ診断や脆弱性診断とは少し違う、新しいセキュリティ検証領域が出てきていると感じました。

ソースコードスキャンとAIリスク

今回の発表では、ソースコードやクラウドランタイム環境のスキャンについても触れられていました。

AI AgentやAIアプリは、コードとして実装されます。そのコードの中に、どのモデルを使うのか、どのMCP Serverに接続するのか、どのToolを呼ぶのか、どのデータにアクセスするのか、といった情報が含まれる場合があります。そのため、AIセキュリティではソースコードスキャンも重要です。従来のソースコードスキャンでは、脆弱なライブラリやシークレット、一般的な脆弱性を見つけることが中心でした。しかしAI時代には、以下のような観点も必要になります。

AgentがどのToolを呼び出すか
MCP Serverの接続先はどこか
ガードレールが設定されているか
危険なコード実行能力を持っていないか
機密データにアクセスする処理がないか
プロンプトインジェクションに弱い設計ではないか
ローカルモデルや外部モデルをどう参照しているか

つまり、AIアプリケーションのコードを見るときには、通常のアプリケーションセキュリティに加えて、Agentの振る舞いとTool利用のリスクも見る必要があります。この観点は、今後のDevSecOpsにかなり大きく関係してくると思います。

第三部まとめ

第三部では、今回の発表を技術的な観点から整理しました。ポイントをまとめると、以下の通りです。

AI Agentは新しいアクセス主体になる
MCP ServerはAI Agentが外部Toolやデータに接続する重要な窓口になる
MCPを制御しないと、Tool Callや権限の管理が難しくなる
MCP BrokerはAgentとMCP Serverの間に制御点を作る考え方
AI Access Graphは、AI、ID、データ、Tool、MCP、クラウド、SaaS、エンドポイントの関係性を可視化する
AI Endpoint Securityは、ブラウザー、開発支援AI、ローカルAIモデル、AI Agentなど端末上のAI利用を守る
AI Guardは、AI利用時のプロンプト、レスポンス、データ、脅威、コンテンツを制御する
AI Red Teamingは、AIアプリやAgentを継続的に検証するために重要
AI Securityは、ゼロトラストの延長線上にある
AI時代こそ「接続は必要、信頼は不要」という考え方が重要になる

今回のZenith Live'26を通じて、Zscalerが目指している方向性は、単なるAIセキュリティ製品の追加ではなく、ゼロトラストアーキテクチャをAI Agent時代に拡張することだと感じました。 AIは確実に業務を変えます。そして、AIが業務を変えるのであれば、セキュリティアーキテクチャも変わる必要があります。

APCでは今後もゼロトラスト事業を推進し、Zscalerをはじめとした最新技術のキャッチアップに努めていきます。インフラ領域、ゼロトラスト領域、AI活用におけるセキュリティ、AIガバナンス、AI Agent時代のアクセス制御に課題があるお客様は、ぜひご相談ください。

APC 技術ブログ

株式会社エーピーコミュニケーションズの技術ブログです。