今回のニュース：標準カタログにないアプリも定義できる
Cloudflareは2026年10月15日、Application Libraryのカスタムアプリ対応を発表しました。社内サービスなどの接続先をまとめ、GatewayのDNS・Network・HTTPポリシーからアプリ名で選べるようにする機能です。
公式資料確認に基づく解説で、実機の設定・遮断を検証した記事ではありません。 今回、当サイトのGateway・DNS・WAF設定は変更していません。
アプリの「名札」と、通す・止める「ルール」は別
登録の公式説明では、カスタムアプリにホスト名やIPサブネットを登録します。ただし、アプリを作成してもGatewayポリシーは作成されません。 通信を制御するには、別途その定義をポリシーから参照します。
当サイトの整理では、アプリ定義は「このサービスの接続先一覧に付ける名札」、ポリシーは「その通信をどう扱うかを決めるルール」です。名札を付けたことを、アクセス制御や安全性の確認が済んだ証拠にしないでください。
一致範囲の落とし穴：ホスト名とIPはOR条件
公式の一致条件によると、ホスト名とIPサブネットの両方を登録した場合、どちらかが一致すれば対象になります。「そのホスト名、かつ、そのIPに限る」というAND条件ではありません。ホスト名は指定ドメインのサブドメインにも一致します。
理解のための架空例として、業務ポータルAを portal.example.com、IPを説明用の 198.51.100.0/24、ポートを tcp/443 と定義した場合を考えます。
- HTTP・Networkでは、ホスト名が一致してTCP 443なら、登録IP範囲外でも対象になり得る。
- 登録IP範囲内のTCP 443なら、ホスト名が異なっても対象になり得る。
- DNSポリシーでは、アプリ定義のポート条件を使わない。 DNS問い合わせから、その後の接続先ポートを判断するわけではない。
これは資料に基づく条件の読み方で、実通信のテスト結果ではありません。広いIP範囲や上位ドメインを足すほど対象が絞られる、と考えるのは危険です。サブネットの基本はIT用語大全集も参照してください。
社内IT担当者が導入前に残す点検メモ
以下は当サイトが提案する段階的な確認案です。契約・権限・通信経路が不明な環境で、そのまま設定を変更する手順ではありません。
- 対象を棚卸しする：サービス名、管理担当、必要な接続先、利用端末、業務上の目的を結び付ける。実データや秘密値を公開の相談欄へ貼らない。
- 狙う範囲を書く：「全ポートを止めたい」のか「特定の通信だけを扱いたい」のかを分け、使うポリシーの種類と一致条件を確認する。
- 正常な依存先も調べる：ログイン、認証、コンテンツ配信など、止めると業務が壊れる接続先を区別する。
- 既存の参照先を確認する：定義を変更すると、参照しているルールの対象も変わり得る。担当外のルールへ影響しないか調べる。
- 小さく検証する：承認済みの検証環境で、対象通信・対象外通信・必要な業務動作を確認する。保存成功だけを適用成功にしない。
- 根拠と戻し方を残す：変更前後の定義、ポリシー、確認時刻、実行結果、未確認の端末を記録する。想定外の停止があれば、保護を一括解除せず担当者へ引き継ぐ。
台帳の作り方は公開システム・SaaSの棚卸しへ、誰が変更できるかの点検はアカウントと権限の管理へ進めます。
共有の認証先を一緒に止めない
公式Docsのsupport hostnamesは、認証や配信などの依存先を表します。GatewayはこれをAllowポリシーに含め、Blockポリシーでは除外する扱いです。「同じアプリの一覧に見えるから、全部まとめて遮断される」と読み替えてはいけません。
当サイトの架空例では、ポータルAとサービスBが共通の認証基盤を利用しています。ポータルAの利用制御を変えるときは、Bのログインが壊れないかも確認対象にします。対象アプリだけ見て成功・失敗を判断しない点が、運用上の注意です。
当サイトの評価：一覧の集約は便利、変更の影響も集約される
便利になるのは、接続先をアプリ単位で説明し、ルールと棚卸しを結び付けやすくなる点です。一方、公式Docsでは定義の更新が参照ルールにも反映されるため、当サイトは「一か所の修正が複数の利用箇所へ届く」影響を重視します。編集できることと、安心して変更できることは別です。
この機能は、公開サイトのWAF設定や業務アプリ内部の権限管理を置き換えるものとして扱いません。個別契約の提供可否・上限、反映時間、通信経路、実際の許可・遮断は今回未確認です。登録・ポリシー・実通信の確認を分け、確認できなかった範囲も残しましょう。