はじめに
こんにちは、セキュリティチームのHitomiです。
6月の記事で書いたURLリストの移行が、いよいよ管理画面のバナーとして降りてきました。Policies > Profiles > URL Lists を開くと、「URLリストは将来的に非推奨になります」の一文の下に、ボタンが2つ並んでいます。
これ、結局どっちを押せばええん？・・・というのが、最初に画面を見たときの正直な感想です。片方を押せばもう片方は要らないのか、押した瞬間にポリシーが変わるのか。ボタンの文言からは読み取れません。
公式ドキュメントを読み込んでみると、答えはわりとシンプルでした。
ただ、2つめのボタンの手前と、移行が終わったあとに、それぞれ落とし穴がありますのでご紹介していきます。
はじめにまとめ
- 2つのボタンは二択ではなく、移行の「1段目」と「2段目」です。
- 「宛先プロファイルに複製する」→ 適用 →「カテゴリを移行する」→ 適用、の順に両方使います。
- 初回の「宛先プロファイルに複製する」では、カスタムカテゴリの参照はまだ切り替わりません。
- カテゴリ移行を適用すると、マッチ判定がDestination Profileに切り替わります。本番はこちら！
- カテゴリ移行後に
Duplicate Againするときは要注意です。To a New Destination Profileを選ぶと、カスタムカテゴリの参照まで新しいプロファイルに差し替わった状態で保留変更に積まれます（弊社検証環境で確認）。内容を同期し直すだけならTo Override the Duplicated Destination Profileを選びましょう。
- 2段目の前に、Longest Prefix Match（最長一致）の差分だけは必ず確認しましょう。
- Destination Profileは最長一致に対応していないため、これまで隠れていたマッチが表に出てくる可能性があります。
用語メモ
- スキーム：URLの先頭の
http://やhttps://の部分 - CIDR・レンジ：IPアドレスの範囲の書き方。CIDRは
163.116.128.0/17のような表記、レンジは163.116.128.80-81のように始点と終点を書く表記 - クエリ：URLの
?以降の部分（例：?q=weather） - L7／L4：通信の階層の呼び方。L7はURLやパスまで見える階層、L4はIPアドレスとポート番号だけを扱う階層
- SNI：HTTPS通信の最初に、接続先のホスト名を伝える情報。復号しなくても宛先のドメインが分かる
URLリストとDestination Profileは何が違うの？
まず「URLリスト」は、Web宛先の条件をまとめて登録しておくリストです。LegacyとEnhancedは、そのURLリストの種類（書き方・判定ルールの違い）で、別の機能やポリシーではありません。ざっくり言うと、Legacyはシンプルな形式、Enhancedは正規表現なども使える拡張形式です。どちらもカスタムカテゴリを通じてポリシーから使われます。
今回の移行では、どちらの種類のURLリストもDestination Profileに複製します。ただし、書ける条件や「最長一致」の扱いが異なるため、移行前に自分のリストの種類を確認しておく必要があります。
Destination Profileは、URLリストの後継となる「宛先の入れ物となるプロファイル」です。Cloud Firewall側（Web以外も含むネットワーク通信を制御する機能）はNetskopeが自動で移行しますが、SWG側（Web通信を検査するプロキシ）のURLリストは管理者が自分で移す必要があり、その入口が今回の2つのボタンです。
全体像は6月の記事をどうぞ。
書ける構文はいくつか違いますが、1行ずつの書き方の差は「複製」のときに自動で変換されます。変換後の構文や大文字小文字の設定を確認したうえで、特に気をつけたいのが、リスト同士の関係で決まる「最長一致」です。
構文の違いを一覧にするとこんな感じ。
| 観点 | Enhanced URLリスト | Legacy URLリスト | Destination Profile |
|---|---|---|---|
スキーム（http://） | 記述可（port 80として評価） | ― | 記述不可。*.domain.com:80 のようにポートで表現 |
| CIDR・レンジ | そのまま記述 | ― | CIDR: RANGE: の接頭辞が必要 |
*.example.com | ― | サブドメインのみにマッチ | サブドメインと example.com 自体の両方にマッチ |
| 大文字小文字 | 全体設定（URL Case Insensitivity Match） | ― | プロファイル単位で設定 |
| Longest Prefix Match | 2021年10月より前に作成されたテナントは既定で有効 | 既定で有効 | 非対応 |
※「―」は公式ドキュメントの比較項目に記載がないもの
気をつけるのは「最長一致」
最長一致（Longest Prefix Match）とは、同じ宛先に複数の定義が当たるとき、より長く具体的な定義だけを採用する仕組みです。
URLリストで最長一致が有効な場合、同じドメインを長さの違う定義で別々のリストに書くと、長い方のリストだけが当たります。Legacyは既定で、Enhancedは2021年10月より前に作成されたテナントで既定で有効です。
たとえば www.example.com と www.example.com/somepath が別リストなら、/somepath へのリクエストには長い方だけが当たります。
Destination Profileはこの最長一致に対応していないので、短い方も当たり得ます。2つがAllowとBlockに分かれていたら、移行後にどちらが効くかはポリシーの評価順しだいです。
他の変更は、パス・ポート・クエリをどの宛先タイプにも書ける、大文字小文字をプロファイルごとに決められる、当たり方をAPIで確かめられる（後述）など、運用が楽になるものが中心です。
〜 参照元 〜
- Migrating URL Lists to Destination Profiles —「URL Lists Versus Destination Profiles」
- Netskope Release Notes Version 128.0.0 —「Destination Profile」
- Netskope Release Notes Version 134.0.0（Cloud Firewall側の移行）
- Netskope Release Notes Version 139.0.0（Destination Profile Evaluation API）
今回の移行概要
移行は「複製」と「カテゴリ移行」の2段階
公式ドキュメントは、移行を2つのステージに分けています。第1ステージがURLリストをDestination Profileとして複製すること、第2ステージが複製したDestination Profileをカスタムカテゴリに差し替えることです。
バナーに出ている2つの数字は、それぞれの残り件数です。「重複のないURLリストが◯件」が「宛先プロファイルに複製する」の残り、「URLリストを使用しているカスタムカテゴリが◯件」が「カテゴリを移行する」の残りです。
1段目「宛先プロファイルに複製する」：初回は参照が切り替わらない
- 初回の複製では、カスタムカテゴリの参照はまだ切り替わりません。公式ドキュメントは、第1ステージは次のステージまで環境に影響しないと説明しています。ただし、カテゴリ移行後に再複製する場合は、カスタムカテゴリ側に保留中の変更が積まれることがあります（後述）。
- 元のURLリストは消えません。複製されるのは「新しいDestination Profile」で、カスタムカテゴリはまだ元のURLリストを見たままです。
- 構文は、設定済みの挙動を保つように自動で書き換えられる、とされています。
2段目「カテゴリを移行する」：ここで挙動が切り替わる
カスタムカテゴリの中で参照しているURLリストを、1段目で作ったDestination Profileに差し替えます。通信の許可・ブロックをリアルタイムで決めるReal-time Protection（RTP）ポリシーなどは、カスタムカテゴリ経由でURLリストを使っているので、差し替えを適用した時点で、実際のマッチ判定がDestination Profileに切り替わります。
- Destination Profileの変更をすべて適用してからでないと、カテゴリ移行はできません。
- 更新できるのは適用済みのカスタムカテゴリだけです。
- 適用後でもロールバックできます（後述）。
〜 参照元 〜
バナーが出たら、まずやること
いきなりボタンを押す前に、移行できる状態かどうかと、自分のテナントで差分が出そうな場所を確認します。
1）保留中の変更をなくす
Netskopeでは、設定を変えても Apply Changes するまでは反映されず、それまでは「保留中の変更」として残ります。移行は、この保留がない適用済みの設定に対してしかできません。複製できるのは適用済みのURLリストだけ、カテゴリ移行できるのも適用済みのカスタムカテゴリだけです。
未適用の変更を確認し、通常の承認・変更手続きを経てApplyするか破棄します。
内容を確認せず、保留をなくすためだけに適用するのは避けましょう。
2）URLリストの種別と、最長一致が有効かを確認する
管理画面で Policies > Profiles > URL Lists を開き、New URL List をクリックします。以下の画面に表示されている「URLタイプ（完全一致／正規表現）」は、URLの照合方法を選ぶ項目です。
画面には「Enhanced」「Legacy」という名前は表示されません。
代わりに、URLタイプで「正規表現」を選べるかを確認できます。正規表現に対応しているのはEnhanced URLリストで、Legacy URLリストは対応していません。
- スクリーンショットの画面なら「正規表現」が選択肢にあるので、Enhancedと読み取れます。
Legacyなら最長一致は既定で有効、Enhancedなら2021年10月より前に作成されたテナントで既定で有効です。ただし、Custom URL Lookup Longest Match Mode で無効にできるため、既定値だけで判断せず、自分のテナントの設定も確認してください。
3）同じドメインが、別々のURLリストに分かれていないか洗い出す
最長一致の影響を受けるのは、同じドメインを長さの違う定義で別々のURLリストに書いている箇所です。特に、Allow側とBlock側のカスタムカテゴリに分かれているものを優先して洗い出します。
前回の記事の棚卸し表があれば、ここはすぐ引けるはずです。
まずやることのチェックリスト
- 保留中の変更を、通常の手続きで適用または破棄する。
- URLリストの種別（Enhanced／Legacy）と、最長一致が有効かを確認する。
- 同じドメインを別々のURLリストに書いている箇所を洗い出す（特にAllowとBlockに分かれているもの）。
〜 参照元 〜
「宛先プロファイルに複製する」を押す
初回の複製ではカスタムカテゴリの参照は切り替わりません。まとめて複製できますが、適用前には変換結果と保留中の変更を確認しましょう。
1）URLリストをまとめて複製する
URLリスト一覧で対象のURLリストを選び、「宛先プロファイルに複製する」をクリックします。一括複製の確認メッセージで複製を実行すると、進捗が表示されます。
2）変換結果を確認してから適用する
Destination Profiles ページで、作成されたDestination Profileの中身（変換後の構文）を確認してから Apply Changes します。
- Legacyテナントなら、
*.example.comのようなエントリがどう変換されたか。 - Enhancedテナントなら、スキーム付きのエントリがポート表記になっているか。
弊社検証環境（英語UI）で1件複製してみたところ、Destination ProfileはURLリストと同じ名前で作成され、Description欄に Migrated from URL List: <URLリスト名> と自動で入りました。
URLリスト一覧側は Dest Profile Migration 列が Not Duplicated から Duplicate Again: to a New Destination Profile のプルダウンに変わります。
複製したら、変換結果と保留中の変更を確認したうえで Apply Changes まで進めてください。
ちなみに、弊社検証環境では、複製後に適用しないままRevertを押すと、URLリスト側に赤字で Duplicated to: Deleted Profile と表示が残りました。
この表示を見れば、今回のように未適用の複製を取り消した場合、紐付け先がなくなったことに気づけます。
3）カテゴリ移行が終わるまで、URLリストの編集を止める
複製したあとにURLリストを編集すると、Destination Profileとの内容がズレます。移行が終わるまでの間は、URLリストの編集を控える期間として管理者間で共有しておくことをおすすめします。
どうしても編集した場合は、Duplicate Again からDestination Profileを上書きします。ただし、この Duplicate Again には選択肢が2つあり、押し間違えると不要なDestination Profileが増えます。次の節で説明します。
4）Duplicate Again は「上書き」を選ぶ
複製済みのURLリストの Duplicate Again を開くと、選択肢が2つ出てきます。
To Override the Duplicated Destination Profile：既存のDestination Profileを上書き更新するTo a New Destination Profile：別のDestination Profileを新しく作る
内容を同期し直したいだけなら、選ぶのは上の「To Override the Duplicated Destination Profile」です。
下の「新規」を弊社検証環境で押してみたところ、<URLリスト名> - v1 という名前のDestination Profileがもう1つ作られ、URLリスト側の Dest Profile Migration 列の表示が新しい - v1 の方に変わりました。カテゴリ移行前であれば、カスタムカテゴリの参照はURLリストのままで変わりません。
ただし、カテゴリ移行後に「新規」を選ぶと挙動が変わります。詳しくは「移行が終わったらどう運用するのか」で説明します。
〜 参照元 〜
「カテゴリを移行する」の前に確認すること
ここが本番前の最後の確認です。
Destination Profile Evaluation APIで「どれに当たるか」を引く
最長一致のような「リスト間の関係」は、1件ずつ構文を眺めても分かりません。そこで使えるのが、Release 139.0.0（2026年7月6日公開）で追加されたDestination Profile Evaluation APIです。リリースノートでも、URLリストからDestination Profileへの移行時の検証用途が明記されています。
- エンドポイント：
POST /api/v2/profiles/destinations/getevaluation - 入力：URL（必須）、解決済みIP（任意）、マッチコンテキスト（任意）
- コンテキストは3種類
- Application：URL・パス・クエリまで使うL7評価。HTTPと復号後のHTTPS相当
- Session：SNI・DNSベースの評価。復号前のHTTPSや、DNS分析ありのCloud Firewall相当
- Network：宛先IPとポートのみのL4評価。DNS分析なしのCloud Firewall相当
- プロキシと同じ評価ライブラリを使っているとされています
「まずやること」の3）で洗い出したURLを、Applicationコンテキストで投げます。たとえば www.example.com/somepath に対して、長い方のDestination Profileだけでなく短い方も返ってくれば、移行後は両方に当たる状態になる、ということです。
〜 参照元 〜
「カテゴリを移行する」を押したら何を確認するのか
1）まずは影響の小さいURLリスト1件から移行する
URLリストを複数選んで「カテゴリを移行する」を押すと、選んだURLリストを参照しているカスタムカテゴリがすべて自動で選択された状態で確認画面が開きます。便利ですが、影響範囲も一気に広がります。
最初は、URLリスト一覧の In Custom Category 列の数字をクリックし、そのURLリストを使っているカテゴリを選んで移行します。そのカテゴリを使うポリシーへの影響範囲も確認し、Custom Categories ページで保留中の変更内容を確認してから Apply Changes します。
2）通信の処理結果を確認してから、残りを進める
移行したカテゴリに関係する通信が、想定どおりに許可・ブロックされているかを確認します。問題がなければ、残りのURLリストを一括で移行します。
3）バナーが消えたことを確認する
1つのURLリストの移行が終わると、In Custom Category 列の数字がゼロになります。すべて終われば、URLリスト画面のバナー自体が表示されなくなります。
〜 参照元 〜
もしも、切り戻しが必要になったら
カスタムカテゴリを手で編集して、元のURLリストに戻す
公式ドキュメントでは、カテゴリ移行は適用後でもロールバックできると説明されています。方法は、カスタムカテゴリを手動で編集し、Destination Profileを元のURLリストに戻すことです。
1段目で元のURLリストは削除されていないので、戻す先は残っています。切り戻すまでの間にURLリストを編集していないことも、このとき効いてきます。
〜 参照元 〜
移行が終わったらどう運用するのか
変更はDestination Profile側で行い、URLリストは触らない
公式ドキュメントは、カスタムカテゴリから参照されなくなったURLリストを編集すると混乱の元になるため、避けるよう推奨しています。移行が終わったら、今後の変更はDestination Profile側で行います。社内の変更手順書にURLリストの手順が残っていれば、あわせて更新しておきましょう。
うっかりURLリストを編集して再複製するなら、「上書き」一択
カテゴリ移行後にURLリストを編集してしまい、Duplicate Again で反映し直したくなるケースもあると思います。このときに To a New Destination Profile を選ぶと、弊社検証環境では次のようになりました。
<URLリスト名> - v1という新しいDestination Profileが作られる- カスタムカテゴリの参照が、元のDestination Profileから
- v1に差し替わった状態で保留変更に積まれる - 元のDestination Profileはそのまま残り、ほかに参照がなければ使われないプロファイルになる
気づかずに Apply Changes すると、本番で使うプロファイルが入れ替わります。元のDestination Profileを使い続けたい場合は、カスタムカテゴリを手で開いて紐付けを戻す羽目になります。
To Override the Duplicated Destination Profile で良いと思います。再複製するなら To Override the Duplicated Destination Profile を選び、適用前に Custom Categories ページに保留変更が出ていないかも確認しましょう。そもそも移行後はURLリストを編集しない、が一番の予防策です。
URLリストの提供終了日は、まだ出ていない
2026年11月6日時点で、Netskope公式の Product EOL/EOS Announcements ページにURLリスト機能の提供終了日は掲載されていませんでした。日付が出次第、本ブログを更新します。
〜 参照元 〜
Appendix：APIでまとめて進めたい場合
URLリストが多いテナントでは、画面ではなくAPIで進めたくなると思います。公式ドキュメントには、それぞれの段階で使えるAPIが記載されていますので確認してみてください。
おわりに
最初に画面を見たときの「どっちを押せばええの？」の答えは、「両方、順番に」でした。初回の「宛先プロファイルに複製する」では、カスタムカテゴリの参照はまだ変わりません。「カテゴリを移行する」を適用すると、マッチ判定がDestination Profileに切り替わります。再複製の際は、保留変更も忘れずに確認しましょう。
実際に触ってみて踏んだのは、公式に書いていない方の落とし穴でした。カテゴリ移行後に Duplicate Again の「新規」を押すと、カスタムカテゴリの参照ごと新しいプロファイルに移る、という挙動です。移行中も移行後も、Apply Changes の前に保留変更を眺める癖をつけておくと、こういう後始末を減らせます。
参考リンク（一次情報）
- Migrating URL Lists to Destination Profiles（Netskope公式ドキュメント）
- Netskope Release Notes Version 128.0.0（Destination Profileの導入／最長一致非対応の説明）
- Netskope Release Notes Version 134.0.0（2026-02-02公開／Cloud Firewall側の移行）
- Netskope Release Notes Version 139.0.0（2026-07-06公開／Destination Profile Evaluation API）
- Netskope Product EOL/EOS Announcements（Netskope公式）
関連記事
- Netskope NG SWG Enterpriseを「使い切る」｜Destination Profileへの移行と2026年の正攻法：移行の全体像とURLリストの棚卸しはこちら。
※本記事は2026年11月6日時点のNetskope公式ドキュメント・リリースノートに基づいています。本文中で「弊社検証環境」と断っている箇所は2026年10月14日および11月6日に弊社テナント（英語UI）で確認した内容で、それ以外の移行の動作は公式ドキュメントに記載された仕様です。画面表示や仕様は今後のリリースで変わる可能性があるため、作業前に最新の公式情報をご確認ください。
