【Zscaler】Claude CodeからZIA情報を調べる：Zscaler MCPサーバーを検証してみた

こんにちは。Zscaler Aces 認定エンジニアの太田です。

Zscalerを運用していると、「あの設定、いまどうなってたっけ？」と管理画面を開く場面、1日に何度かありますよね。前回の記事では、管理画面の一覧をスプレッドシートに書き出す作業をZIA APIとGASで自動化しました。

今回はその続きです。Zscaler公式コミュニティが公開したMCPサーバーをClaude Code（Anthropic社の、ターミナルで動くAIエージェント）に組み込んで、管理画面を開かずに、日本語で聞くだけでZIAの情報がどこまで取れるのか試してみました。クラウドアプリの一覧、URLのカテゴリ、ポリシーの横断確認。セットアップも含めて、分からないことはClaude Codeに聞きながら進めています。結果から言うと、3つとも聞けば答えは返ってきました。ただし、聞き方で返ってくるものが変わる、ポリシーの判定はAIの解釈になる、といった押さえておきたい点もあります。

※検証は2026年9月時点、MCPサーバーは v0.15.4、読み取り専用モードです。

目次

1. Zscaler公式コミュニティが公開したClaude Codeプラグインとは
2. セットアップ（分からないことは聞く）
3. 聞いてみた①：クラウドアプリの一覧
4. 聞いてみた②：このURLのカテゴリ
5. 聞いてみた③：このURL、うちの環境ではどう扱われる？
6. どこまで取れたか
7. こんなことができそう
8. おわりに

1. Zscaler公式コミュニティが公開したClaude Codeプラグインとは

MCP（Model Context Protocol）は、AIと外部システムをつなぐ共通規格です。AIが外部の道具を使うときの「共通の差し込み口」だと思ってください。Zscaler MCPサーバーは、この規格でZscalerとつなぐもので、ZIA・ZPA・ZDXなどに対応しています。前回はエンドポイントを自分で調べてPostmanで叩きましたが、その「APIを叩く」ところをAIに任せられる、というイメージです。仕組みとしては、APIを呼ぶのはMCPサーバー、返ってきた結果を読んで答えるのがClaude Code、という分担です。AIがZIAの中を直接見ているわけではありません。MITライセンスでGitHubに公開されていて、要望や不具合はIssuesで受け付けています。

使う前に、3つだけ押さえておいてください。

• デフォルトは読み取り専用。一覧・参照系のツール（list_* get_* など）だけが動いて、作成・更新・削除はできません。書き込みを有効にするには –enable-write-tools と –write-tools “<パターン>”（許可するツールの一覧）の2つが必要で、片方だけでは動きません
• Public Preview（正式版前の公開プレビュー）です。READMEに「本番環境へのデプロイは避けて」とあります
• Zscalerの「公式製品」ではありません。Anthropic社の公式カタログに載っていて、作者もZscaler社なので私も最初は公式製品だと思い込んでいたのですが、サポートポリシーにはこうあります

This is a community-driven, open source project. While it is not an official Zscaler product, it is actively maintained by Zscaler.

（コミュニティ主導のオープンソースプロジェクトです。Zscalerの公式製品ではありませんが、Zscalerが活発に維持しています）

「公式カタログに載っている」と「公式製品」は別、ということです。問い合わせはGitHubのIssuesが基本ですが、契約者は通常のサポート窓口にも相談できる、とも書かれています。検証やデモで使う分には問題ありませんが、お客様の環境に入れる話になるなら、ここは先に伝えておいたほうがよさそうです。

2. セットアップ（分からないことはそのまま聞いてみる）

項目	内容
検証日	2026年9月
OS	Windows 11
Claude Code	2.1.265
Zscaler MCPサーバー	v0.15.4（読み取り専用）
Python	3.11以上、uv / uvx（MCPサーバーはPython製で、uvx で起動します）

導入は、Claude Codeを起動して、このコマンドを打つだけです。

/plugin install zscaler@claude-plugins-official

これでMCPサーバー本体と、スラッシュコマンド20個、スキル（AIが参照する製品ごとの手順書）8カテゴリが入ります。

次は認証情報です。前回はPostmanに設定しましたが、今回はどこに何を書けばいいのか。マニュアルを探す前に、Claude Codeに聞いてみました。

Zscalerのプラグインを入れました。認証情報はどこに何を書けばいいですか。プラグインの実物（.mcp.json と .env.example）を読んで教えてください

プラグインに同梱されている .mcp.json と .env.example を読んで、答えてくれました。書く場所はプラグインフォルダの .env です。

必須のキーは以下4つです。

• ZSCALER_CLIENT_ID
• ZSCALER_CLIENT_SECRET
• ZSCALER_CUSTOMER_ID
• ZSCALER_VANITY_DOMAIN

クライアントIDとシークレットはZIdentity（Zscalerの認証基盤）のAPI Clientsで作ったクライアントから取り、シークレットは作成時にしか表示されないのでその場でコピーする、Customer IDはZPAの管理画面の会社情報から、Vanity DomainはZIdentityのログインURLの先頭部分だけ、というところまで返ってきました。APIクライアントの作り方自体は、Zscalerのヘルプ（ZIdentity > API Clients）を参照してください。

コツが1つあります。最初、ファイルを読む権限を渡さずに聞いたら、一般論で答えてきて置き場所が違っていました（settings.json と言われた）。「プラグインの実物を読んで」と頼むと正確になります。対話モードならそのまま頼めばよく、claude -p（1回だけ実行するモード）なら –allowedTools Read,Glob,Grep のように読む権限を渡します。聞くときは、根拠になるファイルを読ませるのがポイントです。

構成はこんな感じです。

認証情報はローカルの .env にだけ置いて、MCPサーバーがZIdentityでトークンを取って、OneAPI（Zscaler各サービス共通のAPI）経由で各サービスに読み取りで問い合わせます。APIクライアントに割り当てるZIAのロールも、参照のみ（View-Only）にしておくと安心です。MCPサーバーの読み取り専用とは別に、API側でも書き込みできなくなります。

※起動コマンドの uvx に –system-certs（OSの証明書ストアを信頼する）が付いています。uvx がMCPサーバー本体をPyPIから取ってくるときの設定で、Zscaler配下でSSLインスペクションが有効だと証明書がZscalerの中間CA証明書に差し替わるので、OSに入っているZscalerのルート証明書で検証できるようにしてあります。

3. 聞いてみた①：クラウドアプリの一覧

本題です。前回Postmanで取ったのは /cloudApplications/policy の一覧（app / appName / parent の列）でした。まずは特に指定せずに聞いてみます。

クラウドアプリ一覧を取ってきて

zia_list_shadow_it_apps というツールが選ばれて、アプリ名と数値IDの一覧が返ってきました。Postmanも開いていないし、エンドポイントも調べていません。

ただ、この一覧、前回取ったものとは別物です。

ZIAには見た目のよく似たカタログが2つあります。返ってきたのはShadow IT分析用で、識別子は 2424869 のような数値IDです。もう1つがポリシー用で、SSLインスペクションやWeb DLPで対象アプリを指定するときに使う、OPENAI のような正規名の一覧です。クラウドアプリの一覧を取る目的は、たいていポリシーの対象アプリの指定や棚卸しですよね。なので、欲しいのはふつう後者です。

注意したいのは、取り違えてもエラーにならないことです。今回はポリシーを一切触っていませんが、プラグイン同梱のスキルには、数値IDのほうをポリシーの対象アプリに入れると NONE に読み替えられて、ルールはできたように見えるのに何にも一致しない、と書かれています（読み取り専用なので、実際に入れて確かめてはいません）。エラーが出ないので気づきにくい、というのは覚えておいたほうがよさそうです。

聞き方を変えてみます。

ZIAのクラウドアプリケーションのポリシーカタログを一覧してください

今度は zia_list_cloud_app_policy が選ばれて、正規名の一覧が返ってきました。列は APP / APP_NAME / PARENT で、前回Postmanで /cloudApplications/policy から取ったものと同じ内容です。前回の「取得」の部分は、これで置き換わりました。さっき 2424869 だった「OpenAI」は、こっちでは OPENAI です。

プラグインには、この2つのカタログを使い分ける知識（スキル）が同梱されています。聞き方が正確なら、AIがどちらを見るべきか判断してくれます。逆に、曖昧に聞けば曖昧なほうが返ってきます。

4. 聞いてみた②：このURLのカテゴリ

「www.niandc.co.jp」のURLカテゴリを調べてください

いつもは管理画面のURL Lookupを開く操作ですが、聞いたら16秒ほどで返ってきました。Professional Services、セキュリティ警告なし。テナント側のカスタムカテゴリも確認しますか、と次の確認を提案してくるのは、管理画面にはない動きです。

5. 聞いてみた③：このURL、うちの環境ではどう扱われる？

カテゴリが分かっても、実際にどう扱われるかは別です。管理画面だと、URLフィルタリング、SSLインスペクション、Web DLP、ファイアウォールと画面を開いて、上から順にルールを追うことになります。手間がかかりますよね。

このプラグインには、その手順がスラッシュコマンドとして入っています。

/investigate-url www.niandc.co.jp

結果はこうでした（ルール名は匿名化するよう指示しています）。

ZIA上のポリシー種別	該当ルール番号	ルール上のアクション
URLフィルタリング	No.7	ALLOW
SSLインスペクション	No.8	DECRYPT
Web DLP	No.2	モニタリングのみ
クラウドファイアウォール	No.6	ALLOW

ルールを並べるだけでなく、「ルールNo.4は無効なのでスキップ」「ルールNo.1は対象範囲が限定されていて不一致」と、スルーされるルールも含めて説明してくれました。上から順に条件を見て当たるかどうか判断する、いちばん手間なところまでやってくれました。

ただし、これはAIの解釈で、Zscalerのポリシーエンジンの判定ではありません。コマンドの中身を見ると、URLフィルタリング、SSLインスペクション、Web DLP、ファイアウォールのルール一覧をそれぞれ取ってきて、Claude Codeが順序や条件を読んで当たりそうなルールを推定する、という作りです。判定を返すツールがあるわけではないので、実行するたびに調べる範囲が変わることもありました。どのポリシーを見にいくか絞るには十分ですが、最終判断は管理画面で確認してください。

6. どこまで取れたか

聞いたこと	取れたか	補足
認証情報はどこに何を書く？	⭕	プラグインのファイルを読ませれば正確
クラウドアプリの一覧	⭕	ただしカタログが2種類。ポリシー用途なら「ポリシーカタログ」と言う
このURLのカテゴリ	⭕	管理画面のURL Lookupの代わりになる
このURL、うちではどう扱われる？	△	絞り込みには使える。最終判断は管理画面で
カタログの総件数	❌	MCPではページ上限が返るだけ。SDKで取った（この章の後半）

前回の記事でやったのは、Postmanで取ったJSONをGASでスプレッドシートの表にするところまでで、定期実行はまとめで「できそう」と触れただけでした。今回の方式なら、claude -p で同じプロンプトをタスクスケジューラから回して、出力をファイルに残せます。同じプロンプトを3回実行して出力が一致することを確認しました（出力の形式をプロンプトで固定しておくのがコツです）。その場で聞くのは今回の方式、スプレッドシートの表にして残すのは前回の方式、と分けて使えるので、置き換えではなく、選択肢が1つ増えた形ですね。

なお、大量データはMCPではなくSDKで取るほうが向いていました。3章のカタログは合わせて9万件超あります。試しにこう頼んでみると、

クラウドアプリケーション一覧をすべて取得して、アーティファクト機能でDBを作成して

Claude Codeが「MCP経由で全件を会話に流すのは非現実的」と自分で言い出して（ポリシー用が46,115件、Shadow IT用が46,132件）、ZscalerのSDKで全件をファイルに書き出すほうに切り替えました。そのうえで、Claude Codeに一覧をローカルファイルへ出力させ、必要に応じて可視化用のHTMLを生成させるところまで試しました。

同じアプリが2つの識別子を持つことが、一覧でそのまま見えます（46,115件のうち46,083件はShadow IT IDと突き合わせできました）。「MCPで聞くか、SDKで取るか」を人が決めなくても、今回はAIが量を見て切り替えてくれました。

7. こんなことができそう

ここからは、試してはいないけれど、できそうだなと思っていることです。

• 「今朝からつながらないと言っているユーザー、何が起きてる？」と聞いて、ZCCの状態からZDX、ZPA、ZIAまで一気に切り分けてもらう。プラグインには /troubleshoot-user というコマンドが入っていて、まさにその手順が定義されています
• 「この設定、いつからこうなってたの？」に、監査ログとパラメータの差分を突き合わせて答えてもらう。監査ログを取るツールはまだMCPに入っていないので、APIで取ってきたCSVを読ませる形になりそうですが、「誰が・いつ・何を変えたか」を日本語で聞けたら、運用の景色がだいぶ変わります
• 定期実行した差分を、毎朝チャットに「昨日変わった設定」として流してもらう
• お客様との定例の前に、「先月の変更点をまとめて」と頼んで、報告の下書きを作ってもらう
• 新しく運用に入るメンバーが、手順書を探す前に「これってどう確認するんだっけ？」と聞ける環境にする

読み取り専用で「聞く」ところまでは、今回でだいたい確かめられました。次は「聞いた結果をどう運用に組み込むか」ですね。

8. おわりに

• /plugin install 1コマンドで入る。認証情報の書き方も、プラグインのファイルを読ませて聞けば分かる
• クラウドアプリの一覧、URLカテゴリ、ポリシーの横断確認は、日本語で聞くだけで答えが返ってきた
• ただしカタログが2種類あるので注意。曖昧に聞けば曖昧なほうが返ってくる
• ポリシーの判定はAIの解釈。絞り込みに使い、最終判断は管理画面で
• 前回「できそう」と書いた定期実行は、claude -p で形にできる。出力はファイルに残せる
• Zscaler社がGitHubで公開・維持しているOSS。Anthropicの公式カタログに載っているが、Zscalerの公式製品ではなく、問い合わせはGitHubのIssuesが基本

最後に、「読み取り専用であること」と「外部AIに渡してよい情報であること」は別の論点です。読み取り専用でも、プロビジョニングキーや拠点のIPアドレスは取れてしまいます。デモや社内共有で使うときは、そこは分けて考えてみてください。

もう1つ、MCPが返した内容はClaude Codeの会話に入るので、MCPサーバーが取得した情報はClaude Codeのコンテキストとして扱われます。利用する契約・設定によってデータの取り扱いは異なるため、機密情報や顧客環境の情報を扱う前に、AI利用ルール、データ処理条件、保存先・共有範囲を確認してください。

次回は、製品をまたぐスラッシュコマンド /troubleshoot-user（ZCC → ZDX → ZPA → ZIA と切り分けていくもの）を試してみたいと思います。

「管理画面を開かずに聞く」が、実用に近いところまで来ているのが見えてきたのではないでしょうか。
他にもZscalerに関する運用課題やサポートが必要という読者の方は、ぜひ一度 NI+Cにご相談ください。
弊社では、お客様の運用状況やご要望に合わせ、最適な運用支援をご提案いたします。

メールでのお問い合わせはこちらから

皆様のZscaler運用が、よりスマートで快適なものになるようお手伝いできれば幸いです。

関連ブログ

• 【Zscaler】ZIA APIとGAS連携：パラメータ自動出力による運用負荷軽減術（2025年12月22日）— 本記事の前編
• Zscaler ZDX Copilotで運用はどう変わる？～AIを活用したトラブルシューティングをちょこっと検証してみた～（2025年12月24日）
• 【Zscaler】生成AI時代の新常識：ZscalerAIガードレールのご紹介（2025年12月23日）