こんにちは、エーピーコミュニケーションズ 0-WANの山根です。 今年も、Zscalerがパートナー企業を対象に開催する「FY26 Zscaler Partner Top Sales Tour」に参加しました。 今回の開催地は前回に引き続き沖縄で実施されました。



AI時代のZero Trustは次のステージへ
セッションでは、Zscalerの最新動向だけでなく、Zero Trustの歴史や基本原則、企業に求められるセキュリティ統制、AIエージェント時代に向けた新しいセキュリティの考え方まで、幅広いテーマが取り上げられました。
今回、Zero Trustの本質や企業に求められる統制については、Zscalerの三輪さんからご説明いただきました。
Zero Trustは専門用語が多く、技術担当者以外には難しく感じられやすいテーマです。しかし三輪さんのセッションでは、歴史、税関、決済、タクシーなどの身近な題材を用いながら、「なぜ今、Zero Trustが必要なのか」を非常に分かりやすく解説いただきました。
また、Zscalerの上原さんからは、AIエージェントに対するZero Trustの必要性について、AIエージェント自身の「気持ち」や行動をイメージできる具体例とデモを交えてご説明いただきました。
いずれのセッションも、専門性の高い内容を、営業担当者がお客様との会話へ持ち帰れるレベルまでかみ砕いていただいたことが印象に残っています。
本シリーズでは、今回のPartner Top Sales Tourで得られた学びを、全2部に分けてご紹介します。
第1部では、Zero Trustがこれまでどのように進化してきたのか、そして、なぜ今あらためて経営課題として注目されているのかを整理します。
続く第2部では、AIエージェント特有のリスク、人間向けZero Trustとの違い、Zscalerが示すAI Brokerの考え方を、製造業での活用も交えて紹介します。
今回のセッションで見えた3つのテーマ
今回のPartner Top Sales Tourでは、大きく分けて次の3つのテーマが語られていました。
- Zero Trustは、単一製品ではなく企業全体のアーキテクチャである
- セキュリティは、製品の導入状況だけでなく、統制内容を説明できることが重要になる
- AIの普及により、Zero Trustの対象が人からAIエージェントへ広がり始めている
特に1つ目と2つ目は、製造業のお客様との会話でも重要になるテーマです。
製造業では、社内の業務システムだけでなく、工場ネットワーク、海外拠点、クラウドサービス、IoT機器、取引先との接続など、守るべき対象が多岐にわたります。
さらに、設計・開発、調達、生産、物流、保守といった各業務でクラウドサービスや生成AIの利用が進むことで、従来の「社内ネットワークを守る」という考え方だけでは、企業全体のリスクを把握することが難しくなっています。

これまでのセキュリティ商談では、次のような個別テーマから相談が始まることが一般的でした。
- VPNを刷新したい
- ZTNAを導入したい
- Webアクセスを保護したい
- エンドポイント対策を強化したい
- クラウドサービスの利用状況を可視化したい
もちろん、これらは現在も重要なテーマです。 一方で、今後は個別製品の導入だけでなく、次のような経営視点の相談が増えていくと考えられます。
- 取引先に対して、自社のセキュリティ統制を説明できるか
- 外部サービスや生成AIの利用を適切に管理できているか
- 機密情報がどこにあり、誰がアクセスしているかを把握できているか
- インシデントが発生した際、何が起きたのかを説明できるか
- サプライチェーン全体のリスクへ対応できているか
- 国内外の拠点で、同じ方針に基づくセキュリティ統制を実施できているか
この変化は、セキュリティが情報システム部門だけの課題ではなく、経営課題の一つになっていることを示しています。
セッションでは、SCS★3/★4への対応を例に、外部サービス統制、データガバナンス、AIガバナンスなどを組み合わせ、企業として一貫した統制を行う必要性が紹介されました。

ここで重要なのは、すべてを一つの製品で解決しようとしないことです。
ID、端末、ネットワーク、アプリケーション、クラウド、データ、ログなど、異なる領域の情報を組み合わせ、企業全体として統制を成立させる必要があります。
製造業のお客様への提案でも、「どの製品を導入するか」だけでなく、「どのような統制を実現し、誰に対して説明する必要があるのか」から会話を始めることが、今後さらに重要になると感じました。
なぜ従来型の境界防御だけでは難しいのか
三輪さんのセッションでは、Zero Trustを製品機能から説明するのではなく、歴史や日常生活に置き換えながら、その必要性をひも解いていただきました。
従来の企業ネットワークでは、社内と社外の間に境界を設け、社内を安全な領域として扱う考え方が一般的でした。
例えば、次のような仕組みです。
- 社内LANは安全な場所として扱う
- 社外からのアクセスにはVPNを利用する
- ファイアウォールで社内外を分離する
- Active Directoryなどの所属情報をもとに権限を付与する
- 一度認証した利用者を一定期間信頼する
この考え方は、社員やシステムが社内に集約されていた時代には有効でした。
しかし、現在の業務環境は大きく変化しています。
- 自宅や出張先からクラウドサービスを利用する
- スマートフォンやタブレットから業務を行う
- 海外拠点やグループ企業からシステムへ接続する
- 取引先や委託先とデータを共有する
- 工場設備やIoT機器がネットワークへ接続される
- 生成AIや外部SaaSへ業務データを入力する
- システムやデータが社内とクラウドへ分散する
このような環境では、「社内にいるから安全」「VPNを通っているから安全」という判断だけでは不十分です。

セッションでは、従来型のセキュリティを、村や城の仕組みに例えて説明していました。 昔は、村や城の内側にいる人を仲間として扱い、外部から来る人を関所で確認していました。 企業ネットワークも同様に、社内ネットワークの内側にいる利用者や端末を信頼し、外部との境界で防御する設計が中心でした。 しかし、正規のIDが盗まれたり、社内端末が侵害されたりした場合、攻撃者も正規利用者と同じように内部へアクセスできてしまいます。 そのため現在は、場所や所属だけを信頼するのではなく、アクセスのたびに利用者、端末、データ、行動を確認する必要があります。
Zero Trustは攻撃手法の変化とともに進化してきた



Zero Trustは、ある日突然登場した製品や技術ではありません。 攻撃手法や企業のIT環境が変化する中で、従来のセキュリティ対策だけでは不十分になったことを背景に、段階的に発展してきた考え方です。 境界防御が中心だった時代から、標的型攻撃やAPT攻撃が増加し、攻撃者がどのように侵入し、権限を取得し、内部を移動して情報を持ち出すのかを把握する必要が生まれました。 その中で、Cyber Kill ChainやMITRE ATT&CKといった考え方が活用されるようになり、入口だけではなく、攻撃活動全体を捉えることが重要になりました。 現在の攻撃では、次のような複数の段階を経て被害が発生します。
- 攻撃対象に関する情報収集
- フィッシングなどによる初期侵入
- 不正プログラムの実行
- 端末やシステム内での永続化
- 権限昇格
- 認証情報の窃取
- 社内環境内での横展開
- 情報の収集
- 外部への情報送信
- 業務停止やデータ破壊などの被害発生
ファイアウォールやVPNだけでは、この一連の活動すべてを把握することは困難です。 そのため、利用者の認証、端末状態、通信内容、データアクセス、行動履歴などを継続的に確認するZero Trustの考え方が必要になります。
「防ぐ」だけでなく、検知・対応・復旧・統治まで考える
セキュリティ対策というと、攻撃を防ぐための「Protect」に注目しがちです。 しかし、企業が考えるべき範囲は防御だけではありません。 NIST Cybersecurity Frameworkでは、次の観点からセキュリティを整理しています。
- Govern:方針や責任、リスクを統治する
- Identify:守るべき対象とリスクを把握する
- Protect:必要な保護策を実施する
- Detect:異常や攻撃を検知する
- Respond:インシデントへ対応する
- Recover:業務やシステムを復旧する
どれだけ対策を強化しても、攻撃や事故を完全にゼロにすることは困難です。 そのため、侵入を防ぐだけでなく、異常を早く発見し、影響範囲を限定し、速やかに復旧できる体制が必要です。 さらに、経営層や取引先に対して、どのような方針でセキュリティを統治しているかを説明することも求められます。 この観点からも、Zero Trustは単なるネットワーク製品ではなく、企業全体のセキュリティを設計するための考え方だと理解できます。
Zero Trustの対象はネットワークだけではない

Zero Trustという言葉から、ネットワークアクセス制御やZTNAをイメージする方も多いと思います。 しかし、Zero Trustの対象はネットワークだけではありません。 主に次のような領域を横断して考える必要があります。
- Identity:誰がアクセスしているか
- Device:どのような端末を利用しているか
- Network:どこから、どのような経路で接続しているか
- Application/Workload:どのアプリケーションやシステムを利用するか
- Data:どのデータへアクセスするか
- Visibility:アクセスや操作を可視化できているか
- Automation:リスクに応じて制御を自動化できるか
例えば、正しいIDとパスワードでログインしていたとしても、安全とは限りません。 普段とは異なる国や端末からアクセスしている場合や、短時間で大量のファイルを取得している場合は、不正利用の可能性があります。 そのため、ログイン時点の認証だけではなく、アクセス中の行動や端末状態も継続的に確認する必要があります。 製造業では、一般社員が利用するPCだけでなく、工場端末、保守用端末、委託先アカウント、設備やIoT機器など、さまざまなアクセス主体が存在します。 誰が、どの端末から、どのシステムやデータへアクセスしているのかを整理することが、Zero Trustを検討する第一歩になります。
Zero Trustは製品ではなくアーキテクチャ
セッションでは、Zero Trustは製品ではなく「アーキテクチャ」であることが繰り返し説明されました。 CISAのZero Trust Maturity Modelでは、Zero Trustを次の5つの柱で整理しています。
- Identity
- Device
- Network
- Application/Workload
- Data
さらに、これらを横断する要素として、可視化、分析、自動化、ガバナンスなどが位置付けられています。 つまり、ZTNAを導入しただけでZero Trustが完成するわけではありません。
ID管理、エンドポイントセキュリティ、ネットワークセキュリティ、クラウドセキュリティ、データ保護、ログ分析などを組み合わせ、企業全体として一貫した方針で制御する必要があります。 例えば、利用者が業務システムへアクセスする場合には、次の情報を組み合わせて判断します。
- 利用者本人が正しく認証されているか
- 業務上、そのシステムへのアクセスが必要か
- 端末が会社の管理下にあるか
- OSやセキュリティ製品が正常な状態か
- アクセス先のデータが機密情報ではないか
- 通常とは異なる操作をしていないか
- 操作内容を記録できているか
複数の情報をもとに、その都度アクセスの可否を判断することがZero Trustの基本です。
税関に例えると理解しやすいZero Trust

三輪さんのセッションで特に分かりやすかったのが、Zero Trustを税関に例えた説明です。 税関では、パスポートを持っているという理由だけで、すべての荷物を確認せずに通過できるわけではありません。
- パスポートで本人を確認する
- 渡航履歴や申告内容を確認する
- 荷物の内容を検査する
- リスクが高い場合は追加確認を行う
- 問題がなければ速やかに通過させる
これは、Zero Trustの考え方とよく似ています。 企業システムへのアクセスでも、IDだけでなく、端末、接続経路、アクセス先、データ、行動などを確認します。 リスクが低ければ業務を妨げずにアクセスを許可し、リスクが高ければ追加認証やアクセス制限を行います。
Zero Trustは、すべての利用者を疑って業務を止める仕組みではありません。 確認すべきポイントを明確にしたうえで、問題のない利用者や通信を円滑に通し、リスクのあるアクセスだけを適切に制御する仕組みです。 難しい技術用語に偏らず、社会に存在する仕組みと結び付けて説明いただいたことで、営業担当者がお客様へZero Trustを紹介する際にも活用しやすい内容だと感じました。
情報を組み合わせることで、初めて全体像が見える
セッションでは、世界中の望遠鏡から得られた観測データを組み合わせ、ブラックホールの撮影に成功した事例も紹介されました。 一つの望遠鏡だけでは確認できなかった対象も、複数の観測データを同期・統合することで、その全体像を捉えられるようになります。
セキュリティも同様です。
- IDの認証ログ
- 端末のセキュリティ情報
- Webやクラウドへの通信ログ
- アプリケーションの操作履歴
- データへのアクセス履歴
- 脆弱性や設定不備の情報
- インシデントの検知情報
これらを個別に確認するだけでは、企業全体で何が起きているのかを判断できない場合があります。 複数の情報を関連付けることで、初めて利用者、端末、アプリケーション、データの関係性や、攻撃の兆候を把握できるようになります。 製品を増やすこと自体が目的ではなく、それぞれの製品が持つ情報をどのように連携させ、判断や対応につなげるかが重要です。
暗黙の信頼から「検証可能で説明できる信頼」へ
今回のセッションを通じて、Zero Trustの本質を最も分かりやすく表していたのが、次の考え方です。

Zero Trustは、暗黙の信頼を、検証可能で説明できる信頼へ反転する。
従来は、社内にいる、同じ会社に所属している、VPNを通っているといった条件が、信頼の根拠として使われていました。 しかし現在は、次のような客観的な情報をもとに判断する必要があります。
- 誰がアクセスしたのか
- どの端末を利用したのか
- 何の業務目的でアクセスしたのか
- どのデータへアクセスしたのか
- どのような操作を行ったのか
- ポリシーに基づいて許可されたのか
- 操作記録や証跡が残っているか
これは、単にアクセスを検証するだけではありません。 インシデント発生時や取引先からの確認時に、自社の統制がどのように機能しているかを説明できる状態を作ることでもあります。 Zero Trustは、「Never Trust, Always Verify」という言葉で知られています。
今後はそれに加えて、
Verify:検証する
Record:記録する
Explain:説明する
という観点が重要になると感じました。
お客様との会話で意識したいこと
例えば、製造業のお客様へZero Trustをご提案する場合、最初から特定の製品や機能を説明するよりも、現在の業務やリスクを確認することが重要です。 次のような質問が考えられます。
- 海外拠点やグループ会社から、どのように社内システムへ接続していますか
- 工場の保守作業を行う委託先は、どのような権限を持っていますか
- 設計図面や製造データへのアクセス履歴を確認できますか
- 退職者や異動者の権限を速やかに変更できていますか
- 端末の安全性に問題が発生した場合、アクセスを自動的に制限できますか
- クラウドサービスや生成AIへ、どのようなデータが送信されているか把握していますか
- インシデント発生時に、影響範囲を特定できるログが残っていますか
- 取引先からセキュリティ体制の説明を求められた際、根拠を示せますか
これらの質問を通じて、Identity、Device、Network、Application、Dataのどこに課題があるのかを整理できます。 Zero Trustは、すべての環境を一度に刷新する考え方ではありません。 現在の課題や優先度を明確にし、重要な業務やデータから段階的に統制を強化していくことが現実的です。
まとめ
今回のPartner Top Sales Tourを通じて、Zero Trustは特定の製品を導入することではなく、企業全体の信頼をどのように設計し、検証し、記録し、説明するかというアーキテクチャであることを、あらためて理解できました。 特に印象に残ったポイントは、次の3点です。
- 場所や所属を理由に、アクセスを暗黙的に信頼しない
- ID、端末、ネットワーク、アプリケーション、データを横断して判断する
- 統制の実施状況を記録し、経営層や取引先へ説明できる状態を作る
例えば、製造業でいうと、IT環境だけでなく、工場、OT、IoT、海外拠点、委託先、サプライチェーンなど、複雑な環境を考慮する必要があります。 そのため、「どの製品を導入したか」だけでなく、「誰が、何に、どのような条件でアクセスできるのか」「その判断と操作を説明できるのか」という視点が、今後さらに重要になると考えます。 三輪さんからは、Zero Trustの歴史、本質、アーキテクチャとしての考え方を、身近な例を交えながら非常に分かりやすく解説いただきました。 製品機能だけではなく、Zero Trustが必要とされる背景から理解できたことで、営業担当者としてお客様へどのように説明すべきかを考える、大変有意義な機会となりました。
次回の第2部・最終回では、上原さんからご説明いただいたAIエージェント特有のリスクと、人間向けZero Trustとの違い、Zscalerが提示する「AI Broker」について、具体的なデモ内容と製造業での活用イメージを交えながら紹介します。