ZscalerのIPアドレスの確認方法と送信元IPを固定する手順

Zscalerを運用していると、こうしたIPアドレスの悩みは必ず出てきます。
先に結論を言うと、Zscaler経由の通信でIPが変わるのは障害ではなく設計どおりの動きです。
確認方法・許可リストの押さえ方・送信元IPを固定する選択肢を、この順番で理解しておけば実務で困ることはまずありません。

なお、このメディアはセキュリティ人材のフリーランス（案件参画）を支援するスプラッシュエンジニアリングが運営しています。
その現場視点も交えながら、この記事では次のポイントを解説します。

読み終える頃には、ZscalerのIPまわりの疑問がスッキリ晴れて、SaaS連携や監査の設計に自信を持って臨めるはずです。

チップス

ボス、Zscaler入れたら会社のIPアドレスがコロコロ変わってて、もうパニックでしゅ…！

ボス

慌てるな。それは壊れてるんじゃない、そういう設計なんだ。仕組みから順番に叩き込んでやる。

※記事の内容をサクッと確認したい方は、以下のスライドでご確認いただけます。

Zscaler経由の通信で送信元IPアドレスがどう変わるのか

Zscaler経由の通信では、端末のIPではなく経由するクラウド側のIPが外部に見えます。

ZIAではZscalerのクラウドプロキシ側IPが送信元として見える

ZIA（Zscaler Internet Access）は、インターネット向けの通信をクラウドプロキシで中継するサービスです。
端末から出た通信は、最寄りのエンフォースメントノード（処理拠点）を経由してから目的のサイトへ届きます。
SaaSやWebサーバ側から見える送信元IPアドレスは、端末やオフィスのグローバルIPではなく、経由したノードのIPです。

押さえておきたいのは、この3点です。

この動作はローカルブレイクアウトを前提としたクラウドプロキシ型の基本で、SASE/ゼロトラストの中核でもあります。
端末IPが直接インターネットへ出ないのは、むしろセキュリティ上の利点です。

ZPAではIP到達ではなくアプリ単位でプライベートアクセスする

ZPA（Zscaler Private Access）は、社内アプリへの接続を「IP到達」ではなく「アプリ単位」で仲介する仕組みです。
従来のVPNは、社内ネットワークにIPで到達させてから目的のサーバへつなぐ発想でした。
ZPAでは、社内に置いたApp Connectorがクラウド側へ外向きに接続し、ユーザーの通信をアプリ単位で橋渡しします。

従来VPNとの違いを整理すると、こうなります。

App Connectorが受信ポートを開けないので、攻撃対象になる公開IPを持たずに済みます。
「どのIPで到達するか」ではなく「誰がどのアプリに繋がるか」で考えるのが、ZPAの発想です。

なぜIPアドレスが利用者ごとに固定されないのか

送信元IPが利用者ごとに固定されないのは、クラウド側が通信を動的に振り分けているからです。
ノードは世界中に分散して配置され、その時々の条件で最適な拠点が選ばれます。
「昨日と違うIPで出ている」という状態は、異常ではなく正常な動作です。

変動する理由は、大きく3つに分けられます。

この前提を知らないままだと、SaaS側のIP制限やジオIP判定でつまずきやすくなります。
「利用者ごとに1つのIPを割り当てる」という従来型の発想は、ここで一度手放してください。

チップス

え、じゃあ毎日IPが違うのが普通なんでしゅか…？てっきり故障かと思ってましゅた。

ボス

故障どころか、それが冗長性と最適化の証だ。IPに縛られる設計から卒業しろ、ということだな。

自分のZscaler経由のIPアドレスを確認する方法

今どのIPで外部に出ているかは、公式の確認ページを開けば数秒で分かります。

ip.zscaler.comで現在の送信元IPと接続ノードを確認する

自分の通信が今どのIPで外部へ出ているかは、Zscaler公式の確認ページですぐ分かります。
ブラウザで開くだけで、送信元IPや経由しているクラウドの情報が表示されます（Zscaler公式・My IP Address）。
特別なツールは要らないので、切り分けの第一歩としては一番手軽です。

表示される主な項目と読み方は、この3つです。

Zscalerを経由していない状態で開くと、端末やオフィスの素のIPが表示されます。
経由時と非経由時を見比べれば、通信がZscalerを通っているかどうかを確実に切り分けられます。

config.zscaler.comで利用クラウドのIPアドレス範囲を確認する

個人の送信元IPではなく、許可リスト用に「クラウド全体のIP範囲」を知りたいときはconfig.zscaler.comを使います。
ここではクラウドごとにCloud Enforcement Nodeのレンジが公開されています（Zscaler公式・Cloud Enforcement Node Ranges）。
自社がどのクラウドを契約しているかで、参照すべきレンジが変わる点だけ注意してください。

確認するときに意識したいのは、次の点です。

このページが、後述する許可リスト運用の起点になります。
個人IPの確認とクラウド全体レンジの確認は、目的がまったく別物だと覚えておいてください。

コマンドや外部サービスで確認するときの注意点

curlや一般的なIP確認サイトで調べると、想定と違う結果になることがあります。
通信がZscalerを経由していないケースが混ざるためで、誤診断の原因になりやすい部分です。
結果を正しく読むには、その通信がどの経路で外へ出ているかを意識する必要があります。

結果がぶれる主な要因を挙げてみます。

外部サービスの数値だけを鵜呑みにすると、実態とずれた判断をしがちです。
まずは公式の ip.zscaler.com を基準にして、他の結果はあくまで補助として扱うのが安全です。

許可リスト登録に必要なZscalerのIPアドレス範囲を管理する

SaaSやサーバ側でZscalerを許可するときは、個人IPではなくクラウドのレンジを登録します。

Cloud Enforcement Node Rangesを確認して必要な範囲を許可リストに登録する

SaaSやサーバ側でZscaler経由の通信を許可するとき、登録すべきはユーザー個別のIPではありません。
許可の対象は、通信が実際に経由するCloud Enforcement Node（CEN）のレンジです。
公式のconfig.zscaler.comで、自社クラウドに該当するレンジを確認して登録します（Zscaler公式・Cloud Enforcement Node Ranges）。

登録時に絞り込むべき観点は、次の3つです。

必要以上に広いレンジを許可すると、他社のZscalerユーザーまで通してしまいます。
過剰な許可はIP制限の意味を薄めるので、対象クラウドと地域を明確にして最小限にとどめてください。

IPアドレス範囲は追加・変更される前提で運用する

Zscalerのノードレンジは、増設や構成変更にともなって追加・変更されます。
「一度登録したら終わり」という運用だと、ある日突然の疎通断につながります。
レンジは変わるものだと割り切って、変更に追従できる仕組みを設計へ組み込んでおいてください。

追従するための考え方を、3点にまとめます。

手動でIPを直書きするだけの運用は、レンジ追加のたびに漏れが出ます。
運用負債になりやすい部分なので、更新を前提とした管理方法を最初に決めておきましょう。

チップス

めんどくさいから、全部のIPをまとめて許可しちゃえばラクじゃないでしゅか？

ボス

それは他社のユーザーまで通す悪手だ。IPの直書き放置は、いずれ必ず自分の首を絞めるぞ。

SaaS側のIPアドレス制限とZscalerを両立させる設計

SaaSでIP制限をかけたいのに、Zscalerのレンジが広くて絞りきれない。
このジレンマはよく起こります。
CENのレンジ全体を許可すると、自社以外のZscaler利用組織も同じレンジから来るためです。
この矛盾を根本から解くには、送信元IPそのものを自社側に寄せる発想が必要になります。

両立を考えるときは、次の3つの軸で整理すると分かりやすくなります。

つまり「広いレンジをどう許可するか」ではなく「特定通信だけどう固定するか」に発想を切り替えます。
その具体的な手段が、次章で扱う送信元IPの固定（アンカリング）です。

送信元IPアドレスを固定したいときの選択肢

特定のSaaSにだけ固定IPで出したいニーズには、いくつかの手段が用意されています。

チップス

特定のサービスだけ、いつも同じIPで出すなんて…そんな器用なことできるんでしゅか？

ボス

できる。対象を絞れば、ちゃんと自社のIPで出せる。手段ごとに向き不向きがあるから整理してやろう。

主な選択肢を、適用条件とあわせて整理します。

こうしたSASE構築・運用を担う現場では、送信元IP設計そのものがスキルとして評価されます（Prisma Access・ZscalerによるSASE構築運用を担うセキュリティ案件）。

Source IP Anchoringで特定通信の送信元IPを組織側のIPに制御する

Source IP Anchoring（SIPA）は、特定のアプリ宛の通信だけ、送信元IPを組織側で選んだIPにする機能です。
ZIAで処理した通信を転送ポリシーでZPAのApp Connectorへ向け、そこから目的のサーバへ届けます。
このとき目的地に見える送信元IPは、App ConnectorのIPになります（Zscaler公式・Understanding Source IP Anchoring）。

利用にあたっては、次の前提を押さえておきます。

Microsoft 365など、IP制限をかけたい特定SaaSに向けて自社IPで出したい場面に向いています。
「全部固定」ではなく「必要な通信だけ固定」という考え方が、SIPAの使いどころです。

Dedicated IPで組織専用の送信元IPを利用する

Dedicated IP系のオプションは、組織専用の送信元IPを持ちたいときの選択肢です。
Zscalerでは、組織専用のソースNATアドレスをZscaler側が管理・割り当てるオプション（Zscaler-Managed Dedicated IP）があります（Zscaler公式・Understanding Zscaler-Managed Dedicated IP）。
契約はZscalerサポートへの申し込みが前提です。

導入前に押さえておきたいのは、次の点です。

「専用IPさえあれば何でも解決する」と考えると、期待とずれることがあります。
何を固定し、何は固定しないのかを整理したうえで、コストに見合うかを判断してください。

Private Service Edgeや自社管理NATで送信元IPを制御する

クラウド側のNATや固定IPと組み合わせて、送信元IPを制御する構成も選べます。
Private Service Edgeを自社側に配置したり、AWSやAzure上の固定IP・NATを経由させたりする方法です。
自社のクラウド基盤を持っている組織なら、既存構成と組み合わせて柔軟に設計できます。

一般的な構成の考え方は、こうなります。

こうした構成は、ネットワークとクラウド双方の知識がそろって初めて成立します。
自社の要件・既存インフラ・運用体制を踏まえて、無理のない範囲で組み立てるのが現実的です。

ZscalerのIPアドレスまわりでよくあるトラブルと対処

現場で頻発するIP関連の事故は、原因から逆算すれば先回りして防げます。

チップス

この前、海外からのアクセス扱いでSaaSに弾かれて、半日溶かしたでしゅ…なんででしゅか？

ボス

経由ノードの所在地で判定されたな。IP起点で考えるから詰む。切り分けの型を教えてやる。

こうしたトラブル対応やログ分析は、現場で求められるスキルと直結します（ZscalerゼロトラストのQA対応・ログ分析を担う金融向け案件）。

SaaSのIPアドレス制限で弾かれる／ジオIPが海外判定される

SaaSのIP制限で弾かれたり、ジオIP判定で海外扱いされたりするのは、典型的なトラブルです。
原因は、通信が経由したノードの所在地が想定と違う地域だった、というケースが多く見られます。
まずは「今どのノードを経由しているか」を確認するところから、切り分けを始めます。

対処は次の手順で進めます。

闇雲に設定を触ると、かえって原因が分からなくなります。
「経由ノードの確認 → 固定化の検討 → SaaS側設定の見直し」という順序で進めるのが確実です。

IPアドレスが頻繁に変わり監査ログのトレースが難しい

IPが頻繁に変わると、送信元IPを起点にした監査ログの追跡は機能しにくくなります。
Zscalerでは経由ノードが動的に変わるので、IPと利用者を1対1で結ぶ前提が崩れるからです。
ここで必要なのは、IP依存の監査設計から、ユーザー起点の追跡へ発想を切り替えることです。

追跡の考え方を、3点に整理します。

ゼロトラストでは、IPアドレスは信頼の根拠になりません。
IPで追う設計から離れて、ユーザーとアクセス内容でログを相関させたほうが、追跡精度も監査対応も安定します。

Zscaler・ゼロトラストのスキルはセキュリティ案件でどう評価されるか

ここまでの技術トピックは、そのままキャリア価値につながります。
ZTNA/SASEの市場性を見ていきましょう。

チップス

中央値90万円…！ぼくのIPいじりの経験も、ちゃんとお金になるんでしゅか…？

ボス

なるとも。IP設計を実務で回せる奴は多くない。数が少ないからこそ、現場は高く買うんだ。

ZTNA/SASE運用スキルの需要とフリーランス案件の単価感

ZscalerなどのZTNA/SASE運用経験は、クラウドセキュリティ案件で高く評価される領域です。
当社が公開しているセキュリティフリーランス案件（112件、2026年8月時点）では、月額単価の中央値は90万円、レンジは50万〜180万円です。
当社の案件データの傾向として、ゼロトラスト関連は設計・構築フェーズに集中していて、上振れしやすい構造になっています。

当社案件の職種別の月額単価（中央値）は、次のとおりです。

上流や設計フェーズに関わるほど、単価は上がりやすい傾向です。
最新の案件と単価は当社のセキュリティフリーランス案件一覧で確認できます。

IP設計・許可リスト運用の実務経験が案件で強い理由

地味に見えるIP範囲の運用やアンカリング設計こそ、実は差別化になるスキルです。
SASE導入は「入れて終わり」ではなく、SaaS連携・監査・トラブル対応まで含めて初めて回るからです。
IPまわりの勘所を持つ人材は、設計から運用まで一貫して任せられる存在として重宝されます。

案件で評価されやすい実務スキルを挙げると、次のとおりです。

大規模なSASE導入では、こうしたIP設計スキルが中核として求められます（ZscalerとPalo Altoによる鉄道業界SASE導入設計・構築案件）。
Zscaler運用の経験を案件につなげたい方は、セキュリティプロ・フリーランスへの登録から始めてみてください。

まとめ：ZscalerのIPアドレスを正しく理解して案件に活かす

ZscalerのIPアドレスは、仕組みから固定化まで順番に理解すれば怖くありません。
Zscaler経由でIPが変わるのは設計どおりで、確認は ip.zscaler.com、許可リストはCENレンジが基本でした。

送信元IPを固定したいときはSource IP Anchoringなどの手段があり、トラブルはユーザー起点の発想で切り分けます。
IP設計や許可リスト運用の経験は、ZTNA/SASE案件でそのまま強みになります。

Zscaler運用の実務は、Zscalerを活用したサイバー対策室のインシデント対応・運用案件のような形で案件化しています。
自分のスキルがどう評価されるか知りたい方は、セキュリティプロ・フリーランスに登録して案件を覗いてみてください。

ボス

IPに振り回されるな。仕組みを押さえた奴が、設計も案件も制する。次はお前の番だ、チップス。