2025年10月20日·1 分
ジェイ・チャウドリーとZscaler：クラウド規模のために作られたゼロトラスト
ジェイ・チャウドリーがZscalerで示した、クラウド配信、ゼロトラスト、パートナー流通を用いてエンタープライズセキュリティを再構築した実践的な分析。
ジェイ・チャウドリーがZscalerで示した、クラウド配信、ゼロトラスト、パートナー流通を用いてエンタープライズセキュリティを再構築した実践的な分析。
これはジェイ・チャウドリーの伝記ではありません。Zscalerがエンタープライズセキュリティをどう再構築したか、そしてその技術的・商業的選択がなぜ重要だったかを実践的に描いた話です。
並行して学ぶことは二つあります：
モダンなエンタープライズセキュリティは、従業員がインターネットや社内アプリを安全に使えるようにする制御の集合であり、単にデータセンターの周りにより大きな壁を作ることではありません。重要なのは、誰が接続しているか、何に接続しているか、そしてその接続を許可すべきかを毎回チェックすることです。
読み終える頃には、Zscalerのコアな賭けを一文で説明でき、どの場面でゼロトラストがVPN時代の考え方を置き換えるかを認識し、流通戦略が製品設計と同じくらい重要になり得る理由がわかるでしょう。
ジェイ・チャウドリーは連続起業家で、Zscalerの創業者兼CEOとして知られています。同社は「企業ネットワークを守る」から「ユーザーとアプリをどこにいても守る」への流れを後押ししました。Zscaler以前にも複数のセキュリティ企業を立ち上げ売却しており、攻撃者の行動と企業ITの変化を間近で見てきました。
チャウドリーがZscalerで焦点を当てたのは明快でした：仕事とアプリが企業ネットワークの外（パブリックインターネットやクラウド）に移るにつれて、すべてを中央のデータセンター経由でルーティングして検査する旧来のモデルは破綻し始めた、ということです。
その変化はITチームに痛みをもたらしました：
Zscalerの創業前提は、セキュリティは建物ではなくユーザーに従うべきだ、ということでした。
目立つのは、創業者のプロダクトビジョンが初期戦略に与えた影響です：
これは単なるマーケティングの調整ではなく、製品決定、パートナーシップ、保守的な企業買い手への説明方法に影響しました。時間が経つにつれ、その明快さが「クラウド配信セキュリティ」や「ゼロトラスト」をアイデアから予算項目へと変え、導入・標準化可能にしました。
長年、企業セキュリティは単純な考えに基づいて構築されてきました："良いもの"を企業ネットワークの内側に置き、周りに壁を作る。壁の多くはオンプレのアプライアンス（ファイアウォール、Webプロキシ、侵入防止）で、いくつかのデータセンターに置かれていました。リモート従業員はVPNを使い、実質的にどこからでも内部ネットワークを延長していました。
アプリがほとんどデータセンター内にあるときは、このモデルは比較的うまく機能しました。Webトラフィックやアプリトラフィックは同じボトルネックを通り、セキュリティチームは検査・ログ・ブロックができました。
しかしモデルは二つの前提を置いていて、それが崩れ始めました：
従業員がよりモバイルになり、SaaS採用が加速するとトラフィックパターンは反転しました。カフェの利用者はOffice 365やSalesforce、ブラウザベースのツールに高速アクセスを必要とし、しばしば企業データセンターに触れずに済みます。
ポリシー施行を維持するために、多くの企業はトラフィックを"本社経由"にしました（バックホール）。その結果は予想通り：パフォーマンス低下、ユーザー不満、制御に穴を開ける圧力の高まりです。
複雑さが増しました（アプライアンス増、ルール増、例外増）。VPNは広範なネットワークアクセスを許すと過負荷でリスクが高くなります。支店や買収のたびにハードウェア展開、容量計画、壊れやすいアーキテクチャが増えました。
このギャップ—物理的ペリメーターに頼らず一貫したセキュリティが必要—が、ユーザーやアプリに追従できるクラウド配信セキュリティの出現を促しました。
Zscalerの決定的な賭けは簡単に言えるが実行は困難でした：セキュリティをオンプレ機器としてではなく、ユーザーの近くに配置されたクラウドサービスとして提供する、ということです。
ここで言う「クラウドセキュリティ」はクラウドサーバーを守るだけを意味しません。セキュリティ自体がクラウドで動くという意味です—支店でも在宅でもモバイルでも、ユーザーは近くのセキュリティPoPに接続し、そこでポリシーが適用されます。
"インライン"は目的地へ行く途中にセキュリティ検問を通すようなものです。
従業員がウェブサイトやクラウドアプリにアクセスすると、その接続は最初にサービスを経由するように誘導されます。サービスはポリシーに基づいて可能な限り検査し、リスクの高い宛先をブロックし、脅威をスキャンし、許可されたトラフィックを転送します。目標は、ユーザーが "企業ネットワークにいる" 必要なく企業グレードの保護を受けられることです—セキュリティがユーザーに追従します。
クラウド配信セキュリティはITとセキュリティチームの日常を変えます：
このモデルは、トラフィックが本社に戻るのではなく直接SaaSやインターネットに向かう今の働き方にも合致します。
第三者をインラインに置くことは本質的な懸念を生じさせます：
コアの賭けは技術だけでなく、クラウドプロバイダがグローバル規模で信頼性高く透明にポリシーを施行できるという運用上の信頼です。
ゼロトラストは単純な原則です：「社内ネットワークだから安全」とは決して仮定しない。 代わりに、誰かが誰であるか、どのデバイスか、特定のアプリやデータにアクセスしてよいかを毎回確認します。
従来のVPN思考は、一度入れば建物全体の扉が開くバッジを渡すようなものです。VPN接続後、多くのシステムはそのユーザーを"内部"と見なし、本来意図しない露出が生じます。
ゼロトラストはモデルを転換します。より近い比喩は、誰かに一つの部屋をそのタスクのためだけに許可するようなものです。ネットワークに広く参加するのではなく、許可されたアプリだけに到達できます。
契約者がプロジェクト管理ツールに2ヶ月だけアクセスする必要があるなら、ゼロトラストではその単一アプリへのアクセスを許可し、給与システムや内部管理ツールへの経路を与えません。
社員がBYODで旅行中に作業する場合、ゼロトラストポリシーは強いログインチェックを要求したり、デバイスが古い・暗号化されていない・侵害の兆候がある場合にアクセスをブロックしたりできます。
リモートワークは、セキュリティ判断が物理的オフィスネットワークではなくユーザーとアプリに従うため、より安全にしやすくなります。
ゼロトラストは買って"オンにする"一つの製品ではありません。ツールとポリシーで実装されるセキュリティの考え方です。
また"誰も信用しない"という敵対的な意味ではありません。実務では信頼は継続的に獲得される（IDチェック、デバイスの状態、最小権限で）ため、ミスや侵害が自動的に拡散しないようにします。
Zscalerは人と彼らが到達しようとするものの間に位置するクラウドの"コントロールポイント"として理解すると分かりやすいです。企業ネットワーク境界を信頼する代わりに、各接続を誰が行っているか、状況はどうかに基づいて評価し、適切なポリシーを適用します。
多くの導入は四つの単純な要素で説明できます：
概念的にはZscalerはトラフィックを二つのレーンに分けます：
この分離は重要です：一方は安全なインターネット利用、もう一方は内部システムへの精密なアクセスに関するものです。
決定は信頼できるオフィスIPアドレスに基づくのではなく、ユーザーが誰か、デバイスの健全性（管理対象か、パッチ適用か）や接続の条件に基づきます。
これをうまく行えば、公開される攻撃面を減らし、横方向の動きを制限し、アクセス制御をシンプルで一貫したポリシーモデルに変えられます。特にリモートワークやクラウドファーストのアプリ群がデフォルトになる環境で有効です。
エンタープライズセキュリティと聞くと内部システムを思い浮かべがちですが、大きなリスクはオープンなインターネット側にもあります：従業員がニュースサイトを閲覧し、メールのリンクをクリックし、ブラウザベースのツールを使い、ファイルをアップロードするという日常です。
セキュアWebゲートウェイ（SWG）はその日常的なインターネットアクセスをより安全にするためのカテゴリであり、すべてのユーザーのトラフィックを中央に送り返すことなく保護します。
簡単に言うと、SWGはユーザーとパブリックウェブの間の管理された検問所のように振る舞います。デバイスが到達するものを鵜呑みにする代わりに、ゲートウェイがポリシーと検査を適用して、悪意あるサイト、リスクの高いダウンロード、偶発的なデータ漏洩を減らします。
典型的な保護は：
多くの業務が固定オフィスから離れ、SaaS、ブラウザ、モバイルへ移行したことで勢いがつきました。ユーザーもアプリもあらゆる場所にあるとき、本社へトラフィックをバックホールするのは遅延と盲点を生みます。
クラウド配信のSWGは新しい現実に合致します：ポリシーがユーザーに従い、トラフィックは接続地点の近くで検査され、セキュリティチームは本社経由にしなくても一貫した制御を得られます。
VPNは「ネットワークにいる＝アプリに到達できる」という時代のために作られました。アプリが複数のクラウドやSaaSに散在する今、その考え方は破綻します。
アプリ中心アクセスはデフォルトを反転させます。ユーザーを内部ネットワークに落とす代わりに、そのユーザーは特定のアプリにだけ接続されます。
概念的にはブローカーされた接続のように機能します：ユーザーが自分が誰で何にアクセスしてよいかを証明すると、そのアプリへの短く制御された経路が作られます—内部のIPレンジを公開せず、ユーザーに広範な"内部"可視性を与えません。
ネットワーク分離は有効ですが、実務ではもろいことが多いです：合併、フラットなVLAN、レガシーアプリ、例外の蓄積。アプリ分離はビジネス意図に直結するため扱いやすいです：
これにより暗黙の信頼が減り、アクセスポリシーはアプリとユーザーグループで読みやすくなります。
多くのチームはVPNを一夜にして置き換えません。実務的な展開は通常：
アプリ中心アクセスがうまく行けば、すぐに効果が見えます：VPN関連のサポートチケット削減、説明しやすいアクセスルール、リモートやハイブリッド従業員にとってよりスムーズなユーザー体験—ユーザーは"先にネットワークに接続"しなくてもアプリが動くことを望みます。
優れたセキュリティ製品が自動的に企業標準になるわけではありません。実務では、ベンダが大企業へ到達し、勝ち取り、成功裏に導入されるルートの集合を流通と言います—多くの場合、他社を介して進みます。
セキュリティの流通は通常以下を含みます：
これらはオプションではありません。ベンダを予算、意思決定者、実装キャパシティへつなぐパイプです。
大企業は慎重に購入します。パートナーは：
Zscalerのようなプラットフォームでは、採用はしばしば現場での移行作業—レガシーVPNパターンの解消、アイデンティティ統合、ポリシー調整—に依存します。パートナーはその変更を実行可能にします。
クラウド配信は一次インストールからサブスクリプション、拡張、更新へとビジネスモデルを変えます。これにより流通も変わります：パートナーは単なる"ディールクローザー"ではなく、顧客成果とインセンティブが合致すれば継続的な展開パートナーになります。
パートナーインセンティブ、パートナーイネーブルメントの質（トレーニング、プレイブック、共販支援）、契約後のカスタマーサクセスの引き渡しがどれだけ明確かをよく見ること。多くの導入が失敗するのは製品が弱いからではなく、ベンダ、パートナー、顧客間の所有権が不明瞭になるからです。
セキュリティの購買はめったに"もっと良いセキュリティが必要"から始まりません。通常はネットワークの変化が古い前提を壊すときに始まります：アプリがSaaSへ移る、支店がSD-WANへ切り替える、リモートワークが常態化する。トラフィックが中央を通らなくなると、本社で全てを守るモデルは遅延、例外、盲点を生みます。
ZscalerはSASEやSSEと同じ会話でよく言及されます。これらのラベルは"どのように"セキュリティが配信されるかの変化を表しているためです：
実際の"利点の翻訳"は頭字語ではありません—運用の単純化です：オンプレの箱が減り、ポリシー更新が楽になり、データセンター経由の迂回なしでアプリへ直接アクセスできるようになります。
企業がSSE／SASE的アプローチを検討する典型的な状況：
これらのトリガーが現れると、そのカテゴリは自然に"到来"します—ネットワークが既に変わっているからです。
ゼロトラストプラットフォームの購入は比較的簡単ですが、汚れたネットワーク、継承されたアプリ、人々の実際の行動にまたがってうまく機能させることが成功の分かれ目です。
繰り返し問題になるのはレガシーアプリです。古いシステムは"ネットワーク内＝信頼"を前提にしていたり、ハードコードされたIP許可リストに依存したり、トラフィック検査で壊れたりします。
もう一つの摩擦は人間側です：チェンジマネジメント、ポリシー設計、"誰が何を所有するか"の議論。広範なネットワークアクセスから正確なアプリレベルのルールに移すことは、実際の業務のやり方を文書化させ、長年放置されたギャップを露呈させることがあります。
セキュリティが単独で動かないように調整することが重要です。関与すべきは：
低リスクなグループ（例えば単一の部署や契約者のサブセット）から始め、成功指標を事前に定義します：VPNチケットの減少、アプリアクセスの高速化、露出攻撃面の実測的な減少、可視性の向上など。
パイロットは反復的に実行します：一つのアプリカテゴリずつ移行し、ポリシーを調整して拡大します。目的は全社を実験場にせず迅速に学ぶことです。
ログとトラブルシューティングは初日から計画する：ログはどこにあり誰が問い合わせできるか、保持期間、アラートとインシデント対応の連携。ユーザーが"アプリがブロックされた"ときに助けが得られないと信頼は急速に落ちます—セキュリティモデルが正しくてもです。
よく見落とされる加速要因は内部ツールです：例外申請のポータル、アクセスレビュー、アプリ在庫、展開追跡、レポート作成の軽量な"接着アプリ"を内部で作ること。チームはベンダのロードマップを待つより、自分たちでこうしたツールを素早く作ることが多く、Koder.aiのようなプラットフォームはチャット駆動のワークフローでReactフロントエンド＋Go/PostgreSQLバックエンドの内部ツールを迅速にプロトタイプして出すのに便利です。
アプライアンスからクラウド配信プラットフォームに制御を移すと運用は簡素化される一方で、新しい失敗モードに賭けることになります。良い意思決定は"ゼロトラスト対レガシー"という単純な二択ではなく、これらの失敗モードを理解することです。
一つのプラットフォームでWebセキュリティ、プライベートアプリアクセス、ポリシー施行、ログを提供するとツールのスプロールは減りますが、リスクが集中します。契約紛争、価格変更、製品のギャップがあれば影響が広くなる可能性があります。
クラウドセキュリティはユーザーとアプリの間に一段のホップを追加します。うまく動けばユーザーはほとんど気づきませんが、あるリージョンの障害やルーティング問題が発生すると"セキュリティが原因でインターネットが使えない"という状況が起きます。これは個別ベンダの問題というより常時接続に依存することの性質です。
ゼロトラストは魔法の盾ではありません。スコープが広すぎる、厳しすぎる、グループ間で一貫しないといったポリシーは露出を増やすか業務を止めます。ポリシーエンジンが柔軟であればあるほど、運用上の規律が求められます。
段階的なロールアウトが有効です：明確なユースケース（ユーザーのサブセットや特定アプリ）から始め、レイテンシとアクセスの成果を測る。ポリシーは平易な言葉で定義し、監視とアラートを早期に実装し、冗長性（マルチリージョンルーティング、ブレイクグラスアクセス、文書化されたフォールバック）を計画します。
保護すべきデータタイプ（規制対象か一般か）を把握し、コントロールをコンプライアンス要件に合わせ、定期的なアクセスレビューを予定します。目的は恐怖に基づく購買ではなく、新しいモデルが安全かつ予測可能に失敗するようにすることです。
Zscalerの反復的教訓は集中です：セキュリティ施行をクラウドに移し、アクセスをアイデンティティ駆動にする。ベンダや開発者は一つの質問を自問してください：「他のすべてを簡単にする一つのアーキテクチャ上の賭けは何か？」答えが"状況次第"なら、後でコストや展開時間、例外で複雑さが表れます。
"ゼロトラスト"は、暗黙の信頼仮定を減らしネットワーク配線を減らし、オンプレから離れたアプリを制御するという実践的な約束に翻訳されたため機能しました。チームはバズワードではなく成果を買ってください。望む成果（例：「インバウンドアクセスなし」「アプリへの最小権限」「リモートユーザーに一貫したポリシー」）を書き、それぞれをテストできる具体的な機能にマッピングしましょう。
エンタープライズセキュリティは信頼ネットワークを通じて広がります：リセラー、GSI、MSP、市場。創業者は早期にパートナーフレンドリーな製品を作る（明確なパッケージング、予測可能なマージン、展開プレイブック、共有指標）。セキュリティ責任者もパートナーを活用してください：変更管理、ID統合、段階的移行をパートナーに任せる方が、すべてのチームを短期間でアップスキルするより実用的です。
高トラフィックのユースケース（多くの場合インターネットアクセスや単一の重要アプリ）から始め、事前と事後を測定して拡大してください。
ロールアウトでの主要な質問：
単に"セキュリティを売る"のではなく"移行パスを売る"こと。勝ち筋のストーリーは通常：痛み→最もシンプルな第一歩→測定可能な勝利→拡張。オンボーディングとレポーティングを用意して、30〜60日で価値が見えるようにしましょう。
創業者フレンドリーなパターンの一つは、コア製品に加えて迅速に作れる補助アプリ（評価ワークフロー、移行トラッカー、ROI計算機、パートナーポータル）を用意することです。既存の大規模な開発パイプラインを再構築せずにこれらを作りたいなら、Koder.aiはチャットからフルスタックアプリを"vibe-コーディング"で作るのに適しています—内部や顧客向けツールを素早く本番に出し、流通の動きに合わせて反復できます。
さらに深掘りしたい場合は /blog/zero-trust-basics と /blog/sase-vs-sse-overview を参照してください。パッケージングのアイデアは /pricing をご覧ください。
ゼロトラストは、アクセス決定を「ネットワーク内だから安全」という前提で行わず、ID、デバイスの状態、コンテキストに基づいて各リクエストごとに判断するアプローチです。実務的には：
従来のVPNはユーザーを「ネットワーク上に置く」ため、意図せず多くのシステムにアクセスできてしまうことがあります。アプリ中心のアクセスはモデルを反転させます：
「インライン」とは、トラフィックがインターネットやクラウドアプリに到達する前にセキュリティチェックポイントを通ることを指します。クラウド配信モデルではそのチェックポイントが近隣の**PoP（Point of Presence）**にあり、プロバイダは次のことができます：
目的は、本社にトラフィックを戻すことなく一貫したセキュリティを提供することです。
バックホールとは、リモートユーザーのWebやSaaSトラフィックを検査のために中央のデータセンターへ送ってから再びインターネットへ出すことです。これが失敗する理由は：
セキュアWebゲートウェイ（SWG）は、ユーザーがインターネットを閲覧したりSaaSを使ったりする際のリスクを減らすためのカテゴリです。一般的な機能は：
多くのトラフィックがインターネット向けで、ユーザーが単一のファイアウォールの後ろにいない状況で特に有効です。
クラウド配信のセキュリティは運用を簡素化できますが、依存と前提が変わります。評価すべき主なトレードオフ：
低リスクなパイロットは、狭く測定可能なスコープで行うと成功しやすいです：
目標は、会社全体を実験場にせずに素早く学ぶことです。
設定ミスは、ネットワークアクセスからアプリ／ポリシーアクセスに移行する際にチームが意図を正確に定義する必要があるため依然トップのリスクです。リスク低減策：
SSEはクラウドから配信されるセキュリティコントロール（SWGやプライベートアプリアクセスなど）を指し、ユーザー近傍で一貫した保護を提供します。SASEはそれに加えてネットワーキング（通常はSD-WAN）を組み合わせ、接続性とセキュリティを一緒に設計します。
購入観点では：
大企業は慎重に購入します。パートナーは次のように役立ちます：
強力なパートナーエコシステムが、プラットフォームを標準にするか小規模で停滞するかを左右します。