cloudflare-one-migrations
Zscaler・Palo Alto・古い VPN などから Cloudflare One への移行を、書き出したルールの棚卸しから対応表・段階的な展開の計画まで組ませる。元のルールを 1 本ずつ「移した／移さない（理由と影響）」で数え上げさせ、新しいルールは無効か監査の状態で作らせる
npx skills add cloudflare/skills/cloudflare-one-migrations入れる前にこのスキルがすること・注意点・SKILL.md の原文を確かめてください。解析は安全性の判定ではありません。
- インストール
- 94,504
- 実用度
- 56
- GitHub star
- 3,292
- 最終更新
- 2026/11/7
頼み方の例
そのままコピーして使えますcloudflare-one-migrationsスキルを使って、添付した Zscaler ZIA の書き出しから、Cloudflare One への対応表と移行の評価を作ってください。完全には対応しないルールと、私が決めるべき点を分けて挙げてください。Cloudflare 側の設定はまだ作らないでください。
対象のファイルや状況は、ご自身の作業に合わせて置き換えてください。
このスキルがすること
SKILL.md の記述から機械的に抽出- 外部通信・シェル実行・ファイル操作の記述は見つかりませんでした
これは安全性の判定ではありません。 SKILL.md にそう書かれているという事実だけを並べています。実際に問題があるかは使い方と文脈で決まるため、当サイトでは断定しません。導入前に SKILL.md の原文を確認してください。
SKILL.md の規模
コードブロックの言語: markdown
この解説は再確認中です。 2026年10月30日に原本（SKILL.md）が更新されており、以下の解説が現在の内容と合っていない可能性があります。最新の内容は GitHub の SKILL.md を確認してください。
いつ使うか
社内の VPN、SWG（Web の通信の検査）、SASE の製品を Cloudflare One に置き換える計画を立てるときに効きます。説明文の範囲は、評価・計画・ルールの対応付け・機能の差・展開の段取りです。
名指しされている移行元は、Zscaler ZIA、Zscaler ZPA、Palo Alto（NGFW・Prisma・GlobalProtect）、古い VPN・SWG・SD-WAN、そのほかです。
- 移行の進め方
- 7 段
- 書き出しの項目を名指しする移行元（ZIA・ZPA・Palo Alto）
- 3 製品
- 移行元ごとの落とし穴（ZIA 7・ZPA 12・Palo Alto 5）
- 24 項目
- 有効にする前の確かめ
- 6 つ
7 段の進め方
- 移行元を見極めるどの製品の、どの範囲を移すか
- 書き出しとログを求める画面の写しや文章の要約より、構造化された書き出しを優先する
- 棚卸しを作るID・グループ・アプリ・宛先・接続・各種のポリシー・例外・ヒット数・記録の要件
- 対応表を作る元の項目、行き先、確からしさ、前提、部分的な対応、手で決めること
- 依存するものから作るID の同期、接続、経路と DNS、一覧、TLS の除外、Access、Gateway、DLP、記録
- 安全に段階を踏む移行用の接頭辞、無効か監査の状態で作成、少人数で試し、ログを比べて広げる
- すべてのルールを数える移したか、「移さない」を理由と影響つきで書くか
何が何に移るか
本文の対応の目安は 4 つです。
| 移行元 | 主な行き先 |
|---|---|
| ZIA などの SWG のポリシー | Gateway の通信のポリシーと Gateway の一覧 |
| ZPA の社内アプリへの接続 | Access のアプリ、Cloudflare Tunnel、社内の経路と DNS、Access のポリシー |
| Palo Alto のルール | 通信の向き・ゾーン・オブジェクト・利用者・アプリ・復号・ヒット数を理解してから |
| 古い VPN の置き換え | Access と Cloudflare One Client（WARP）と Tunnel か Mesh。拠点間の通信が要るときだけ Cloudflare WAN |
Palo Alto のゾーンを、何も考えずに一覧へ平らにするな、と書かれています。
使わないほうがいいとき
移す先が決まっておらず、製品選びから始めたいとき
このスキルは Cloudflare One へ移すことが前提です。Cloudflare のどの製品を使うか自体を決めたい段階なら、同じ公開元の cloudflare が入口で、その表も移行の作業をこのスキルへ振り分けています。
新しく Cloudflare One を組むだけのとき
移行元の書き出しを読み、元のルールを数え上げる作りです。移行元の無い新しい設定には、同じ公開元の cloudflare-one が別にあります。
書き出しが手に入らないとき
本文は、対応付けの前に書き出しとログを求めます。画面の写しや文章の要約が、欠けているオブジェクトの書き出しを隠していないかも評価の観点に入っています。書き出しが無いままでは、このスキルの数え上げの強みが出ません。
注意点
書き換えるのは社内の通信の守り
段階ごとに、Cloudflare 側のオブジェクトの数を元の数と比べ、合わなければ止まります。unsupported・partial・unmapped・needs_identity・needs_posture・manual_review の項目は、ポリシーを有効にする前に全部見直します。
広く通す「全部許可」は作らない
接続を保つための全部許可のルールは、明示的に頼まれ、期限を切ったときを除いて作るなと書かれています。Palo Alto の any の宛先や、とても広い CIDR のルールも手で見直し、自動で受け皿を作りません。
使われていない・ヒットの無いルールを無効にしたり消したりするのは、利用者の承認があるときだけです。元のルールの順番とヒット数は残します。
1 対 1 に対応しないもの
次のものは、そのまま同じにはならないとして、決めるべき点に挙げよと書かれています。
- Zscaler の注意・警告の動きGateway にぴったりの同等は無い。黙って許可か遮断に寄せず、利用者の判断にする
- Palo Alto の App-IDアプリの判定の動きは正確には移らない。部分的な対応として印を付ける
- TLS の復号の例外同等が無いことがある。HTTP や DLP の遮断を広げる前に、検査と除外の動きを試す
- DLP のエンジンと正規表現多くは Cloudflare の DLP の設定として手で作り直す。仮置きのポリシーを完成のように有効にしない
ZPA の移行で見落としやすいこと
ZPA の落とし穴は 12 項目と最も多く、具体的な数字も出てきます。
- Access のアプリ 1 件に載せられる宛先の数は既定で 5 件です。大きなアプリの区分がある移行では、実装の前にアカウントの担当に増やすよう頼むと書かれています（上限は 50）
- 「バイパス」は Access の判定ではなく、端末側の分割トンネルの除外に当たります。ここは API で自動化できず、管理画面で手で足す作業です
- ZPA の接続のグループ 1 つに Tunnel を 1 本作り、接続の台数に合わせて cloudflared の複製を並べます。API で Tunnel を作っても、cloudflared の導入までは終わりません
- 既定で遮断する Gateway の Network の環境では、社内アプリの通信を通す許可のルールを、広い遮断より先に評価される位置に置く必要があります。無いと Access の判定の前に遮断されます
IP で縛られた相手のアプリは、出口の IP をどうするかを先に決めないと実装できない、と本文は書いています。
ID の同期が前提になる
グループで絞るルールは、SCIM でのグループの同期が前提です。SCIM が無いと、ID で絞っていた元のルールが広くなりすぎるので、利用者やメールの一覧のような代わりを足すよう書かれています。試しの段では、本物の利用者で、同期と再認証のあとにグループが合うかを確かめます。
解析では見えない、文書の読み込み
SKILL.md の解析では、外部通信・シェル実行・ファイル操作の記述は見つかっていません。ただし冒頭で、正確な設定を作る前に Cloudflare の文書と API の定義、移行元の書き出しの文書を取ってこいと指示しています。同梱ファイルはありません（2026-10-22 時点）。
インストール数の推移
日次で記録9月18日 〜 11月7日（49日分）
インストール数と 1 日あたりの増加は Skillselion が に集計した値です。上流の更新は数日おきなので、前日比ではありません。GitHub star と最終更新は に GitHub から取得しました。
併用すると強いスキル
よくある質問
最後に何が出てきますか
終わったと言う前に、元のルールの数え上げの表を作ります。移したオブジェクト、部分的な対応、移さない理由、セキュリティへの影響、手作業ごとの担当者を、ルールごとに並べます。評価のほうは、移行元・見た資料・欠けている書き出し・勧める行き先・対応の要約・危うい点・移さないもの・試しの計画・確かめ・戻し方、の 10 項目の雛形で出します。
移行元のどんな書き出しを用意すればいいですか
本文は ZIA・ZPA・Palo Alto のそれぞれに、求める書き出しを並べています。ZIA なら URL の絞り込み、ファイアウォール、SSL の検査、DLP、独自の URL の分類、拠点、GRE のトンネルなどです。Palo Alto なら、ルールと一緒にアドレスやサービスのオブジェクトとグループも書き出すよう求めています。欠けると、黙って落ちたように見えるからです。
ZIA の独自の URL の分類はそのまま移りますか
多くは IP・ドメイン・URL の別々の一覧に分かれる、と書かれています。元の分類の数ではなく、できあがる一覧の数を数えよ、という注意です。
移行元の機械はいつ止めればいいですか
本文は、止める条件を展開の準備の観点の 1 つに入れています。試しの群と拠点、並行して動かす期間、戻すときの担当、元の機械を止める条件、ログを比べる計画を、評価の段で決めておく形です。