はじめに
こんにちは、エーピーコミュニケーションズ iTOC事業部 BzD部 0-WANの片桐です。
今回から、ZDX（Zscaler Digital Experience）の機能を深掘りする連載を開始します。最初のテーマは Web Probe です。
「アプリケーションにアクセスできない」「ページの表示が遅い」——こうした問い合わせを受けたとき、まず確認したいのはそのアプリが正常に応答しているかどうかです。
ZDX Web Probeは、ユーザーのデバイス上のZscaler Client Connector（ZCC）からアプリケーションへHTTPリクエストを送信し、可用性と応答性能を継続的にモニタリングします。
Web Probeは ZDX Standardライセンスから利用可能 です。
つまり、ZDXをお使いの方であれば追加ライセンスなしで活用できる機能です。
ZDXの基本でありながら、適切に設定すれば障害の初動対応を大きく効率化できます。ぜひ本記事を参考に活用いただければと思います。
注意事項： 本記事は筆者個人の技術的な知見と検証に基づいた内容です。弊社の公式見解や性能保証を示すものではありません。正確な仕様や最新情報については、Zscaler公式ドキュメントをご確認ください。
1. Web Probeの動作の仕組み
Web Probeは、ZCCが HTTP/HTTPS GETリクエスト をアプリケーションに送信し、返ってきたHTTPステータスコードで稼働状態を判定するプローブです。
たとえば internal.company.com を監視する場合、ZCCがログインページにHTTPS GETを送信し、アプリケーションがSSOプロバイダーへのリダイレクト（HTTP 302）で応答すると、ZDXはこれを「正常」と記録します。
Web Probeはアプリケーションにログインするわけではなく、「フロントドア」が期待どおりに応答するかで可用性を判定する仕組みです。
1-1. SSL/TLSのターミネート
Web Probeのリクエストは 常にTLS/SSLがターミネート されます。組織でSSLをbypassするポリシーを設定していても、
Web Probeに対しては オーバーライド されます。理由は2つあります。
1つ目は 正確な計測のため です。ZIA Public Service Edgeがサーバー応答時間や可用性のメトリクスを収集するには、通信の中身を確認する必要があります。
2つ目は スマートキャッシングのため です。多数のユーザーが同じアプリにプローブを送信するとサーバーに負荷が集中しますが、Zscalerはプローブ応答を集約する「スマートキャッシング」でこれを防いでおり、その実現にはSSL復号が不可欠です。
なお、Deep Tracing中はプローブリクエストがZIA Web Insightsにも記録されるため、ZDXダッシュボードに加えてZIAのログを活用し、より多角的な分析が可能になります。
2. 収集されるメトリクス
2-1. Page Fetch Time（ページ取得時間）
アプリケーションがページを読み込むのにかかる合計時間です。内訳として PAC解析時間、DNS時間、TCP接続時間、SSLハンドシェイク時間、サーバー処理時間 で構成されます。対象はトップレベルのページドキュメントのみで、画像やCSS等のサブリソースは含まれません。
Advanced Plusサブスクリプションでは、これらのメトリクスの一部でセグメント別（Client - PSE、PSE - App等）の個別グラフとしても表示することが可能です。
2-2. Zscaler Time to First Byte（TTFB）
リクエスト送信からサーバーの最初の1バイトを受信するまでの時間です。Page Fetch Timeがページ取得完了までの合計であるのに対し、TTFBは初期応答の速さを示します。
2-3. Availability（可用性）
設定した「成功」とみなすHTTPステータスコードが返れば100%、タイムアウトや想定外のレスポンスは0%として記録されます。
各メトリクスのグラフには 過去7日間のデータに基づくベースライン が表示され、「いつもと比べて遅い」という相対的な異常を検知しやすくなっています。
3. 設定のポイント
3-1. 成功とみなすHTTPステータスコード
デフォルトではSuccessful responses (200-299)と304 Not Modifiedが成功として登録されています。すべてを成功扱いにすると誤検知の原因になるため、アプリが実際に返すコードを確認し、不要なものは除外しておくのがおすすめです。
3-2. プローブ対象URLの選び方
監視対象のURLは、アプリケーションの認証方式によってアプローチが変わります。
認証が不要なWebアプリケーションの場合は、トップページ等を指定し、200 OKが返ることを直接監視するのがシンプルです。
認証が必要なWebアプリケーション（SaaS等）の場合は、未認証のリクエストに対してSSOプロバイダーへのリダイレクト（HTTP 302等）を返すのが一般的です。
この場合、アプリの「フロントドア」を監視対象とし、リダイレクトが正しく返ることで正常性を判定します。
3-3. リダイレクト追従
Follow redirectを有効にすると最大追従回数（デフォルト5回）までリダイレクトを辿ります。SSO認証チェーンが長いアプリでは調整が必要です。
3-4. プローブ頻度
実行間隔はサブスクリプションで異なり、Standardは15分、それ以外（Microsoft 365 / Advanced / Advanced Plus）は5分です。
ユーザーあたりのアクティブプローブ数にも上限があり、Standardで3、Advanced Plusで100です。詳細はRanges & Limitationsを参照してください。
4. まとめ
Web Probeは、ZDXの中でも最も基本的な監視機能ですが、Alertなどの設定と組み合わせて適切に設定することで「ユーザーから問い合わせが来る前にアプリの異常に気づける」状態を作れます。
特に運用上のポイントとなるのは、成功とみなすHTTPステータスコードの精査と監視対象URLの適切な選定です。
この2つが甘いと、アプリが落ちているのに「正常」と判定されたり、逆に正常なのにアラートが飛んだりと、監視の信頼性が損なわれます。
また、ZDXでは主要SaaS向けに定義済みアプリケーションが用意されていますが、自社で独自に利用しているSaaS（ZIA経由）やプライベートアプリ（ZPA経由）もカスタムアプリケーションとして監視対象に追加できます。
Web Probeで「アプリが応答しているか」は分かりますが、「経路のどこで遅延が起きているか」までは判断できません。次回は、ユーザーからアプリまでの経路をホップ単位で可視化する Cloud Path Probe を解説します。
おわりに
私たち0-WANは、ゼロトラスト製品を中心とした、マルチベンダーでのご提案で、お客様の経営課題解決を支援しております。
「ゼロトラストってどうやるの？」「製品を導入したけれど使いこなせていない気がする」「ZDXを導入したいが、どこから手をつければいいか分からない」等々、どんな内容でも支援いたします。お気軽にご相談ください。
