Cloudflare One（Zero Trust / SASE）の公式チェンジログから、Gateway と Access を中心に2026年6月のアップデートをまとめます。
対象: 2026年6月掲載分（初回投稿6月4日、最終投稿6月30日）
出典: Cloudflare One Changelog
今月の注目ポイント
- Gateway ポリシー／リストのリソース単位ロール が追加され、DNS/HTTP/Network などポリシー種別ごと、さらに個別のポリシー1件・リスト1件単位で権限を委譲できるように。
- IdPフェデレーション で、1つのIDプロバイダーを組織内の複数アカウントで共有可能に。
- 新規アカウントの既定ログインが Cloudflare IdP に変更（従来はワンタイムPIN）。
- Cloudflare One クライアント（WARP）2026.6.822.0 がWindows/macOS/LinuxでGA。多数の機能が安定版に（必須認証はWindowsのみ）。
- ⚠ 運用影響あり: 2026.6.822.0 以降、クライアントのAPI通信のSNIが
api.devices.cloudflare.comに統一。SNI検査ベースのファイアウォール許可リストを使っている環境は要確認。
Gateway 関連
Gatewayポリシーとリスト向けの新しい権限・ロール（6月30日）
Cloudflare Gateway のファイアウォールポリシーと Zero Trust リストに対して、リソース単位（resource-scoped）の細かいロールを割り当てられるようになりました。アカウント全体や製品全体の権限を与えずに、特定のポリシー種別やリスト管理だけを委譲できます。さらに、これらは個別のポリシー1件・Cloudflare One リスト1件といった単一リソースにスコープを絞って付与することも可能です。
追加ロールの例:
-
Zero Trust Gateway Firewall Policies Admin（DNS/HTTP/Network を含む全ファイアウォールポリシーの閲覧・編集） -
Zero Trust Gateway DNS/HTTP/Network/Egress/Resolver Policies Admin（種別ごとの管理） -
Zero Trust Gateway Policies Admin/Zero Trust Gateway Policies Read/Zero Trust Gateway Read Only -
Zero Trust DNS Locations Admin/Zero Trust Proxy Endpoints Admin -
Zero Trust Account Lists Admin/Zero Trust Account Lists Read
既存のアカウントレベルのロール（Cloudflare Gateway、Cloudflare Zero Trust など）は引き続き有効で、後方互換性が保たれます（既存の自動化・APIトークンも影響を受けません）。
詳細
WorkersのパブリックインターネットトラフィックをGatewayポリシーでフィルタ（6月5日）
network_id: "cf1:network" のVPC Networkバインディングを使うWorkersが、パブリックインターネットへの外部通信（egress）を Cloudflare Gateway 経由で行うようになりました。これにより、既存のZero Trustトラフィックポリシー（DNS・HTTP・Network・egress）が、WARPユーザーと同様にWorkers発のトラフィックにも適用されます。デフォルトで可視化（Gatewayログへの表示）と強制（既存ポリシーの適用）が得られます。
設定は wrangler.jsonc にVPC Networkバインディングを追加するだけです。
{
"vpc_networks": [
{
"binding": "EGRESS",
"network_id": "cf1:network",
"remote": true
}
]
}
Worker側からは、バインディング経由で fetch() を呼ぶと Gateway ポリシーの対象になり、ログにも記録されます。
// パブリック宛先へのegress。Gatewayポリシーの対象となりログに残る
const response = await env.EGRESS.fetch("https://api.example.com/data");
AIプロンプト保護向けのカスタムトピック定義（6月11日）
AIプロンプト保護向けに、独自のカスタムトピックを定義できるようになりました。定義済みトピック（PII、ソースコード、ジェイルブレイク試行など）に含まれない独自・専有の概念を検出できます。自然言語でトピックを記述すると、キーワードではなく文脈に基づいてDLPが一致を判定します（例：合併協議に関する概念で、社名や「merger」の語がなくても一致）。ChatGPT、Google Gemini、Perplexity、Claude で利用可能で、Gateway HTTPポリシーでログ／ブロックできます。
詳細
Access 関連
MCPサーバーポータルでのサービストークン対応（6月26日）
自律エージェントやボットを、Accessサービストークンを使ってMCP（Model Context Protocol）サーバーポータルへ接続できるようになりました。ブラウザベースのOAuthフローなしで、サービストークンセッションからポータル経由で上流のMCPサーバーへ到達できます。
設定手順:
- ポータルのAccessアプリに、対象サービストークンにマッチする Service Auth ポリシーを追加。
- 連携する各MCPサーバーのAccessアプリにも、同じトークンにマッチする Service Auth ポリシーを追加。
- 各サーバーの「Require user auth」をオフ（
on_behalf: false）にし、ポータルが個別ユーザーのOAuthではなく管理者の資格情報を使うようにする。
ボットは CF-Access-Client-Id と CF-Access-Client-Secret ヘッダーで接続し、認可された連携サーバーのツールを利用できます。ただし個別ユーザーのOAuthが必須のままのサーバーは、サービストークンセッションから除外されます（サービストークンではユーザー単位のOAuth付与を完了できないため）。
詳細
新規アカウントで Cloudflare IdP がデフォルトに（6月18日）
新しいZero Trust組織を作成すると、既定のログイン方法として Cloudflare identity provider が追加されるようになりました（従来はワンタイムPIN／OTP）。ユーザーは既存のCloudflareアカウント資格情報で認証し、認証はそのアカウントのメンバーに限定されます。この変更は新規アカウントのみに適用され、既存組織の設定は変わりません（既存アカウントで使いたい場合は手動で有効化が必要です）。
詳細
IdPフェデレーションで複数アカウント間でIdPを共有（6月4日）
Cloudflare Access が IdPフェデレーションに対応し、1つのIDプロバイダー（例：Okta、Entra ID）を組織内の複数アカウントで共有できるようになりました。ソースアカウントで一度設定すれば、他アカウントには読み取り専用のIdP接続が提供され、ソースアカウント上のブリッジ経由で認証がルーティングされます。アカウントの参加・離脱に応じて接続が自動でプロビジョニング／削除され、受信側の接続は誤変更・削除ができません。
詳細
WARPクライアント
Cloudflare One クライアント for Windows / macOS / Linux（2026.6.822.0）（6月29日）
3プラットフォーム向けの新GAリリースで、ベータの機能が安定版に取り込まれました。
3プラットフォーム共通の主な内容:
- デバイスプロファイル／ネットワークポリシーで設定したDNSサーチサフィックスの適用
- デバイス登録を TPM／Secure Enclave で保護（ハードウェアベースのデバイス登録）
- 緊急切断（Emergency Disconnect）のローカルファイルシグナル対応（HTTPSポーリングに加え、ディスク上のファイル検知でも切断可能）
- warp-cli のデバッグコマンド追加
- ローカルDNSプロキシのDNSSECパススルー
- 組織全体設定向けの新MDMフォーマット（FedRAMPなどコンプライアンス環境の設定を簡素化）
- アンダースコアを含むホスト名の受け入れ（ChatGPTサンドボックス系アプリ対策）など多数の共通修正
プラットフォーム別:
- ダッシュボードからのクライアントバージョン管理: Windows / macOS
- MDM経由の必須認証（起動から認証完了までインターネットを遮断）、スリープ復帰時の高CPU修正: Windows のみ
運用上の注意（要確認）:
- 2026.6.822.0 以降、クライアントのAPI通信のSNIが
api.devices.cloudflare.comに統一されました（従来はzero-trust-client.cloudflareclient.comとnotifications.cloudflareclient.com）。SNI検査でトラフィックを許可している環境では、新SNIを許可リストに追加してください（旧バージョンの挙動は変わりません）。 - Linux: RHEL 展開では EPEL リポジトリ への依存が追加されました（キャプティブポータル検知のアプリ内ブラウザ認証・システムトレイアイコン用）。事前にEPELを有効化してください。
- Linux: Cloudflare Mesh が RHEL 9 / 10 に対応。あわせてホスト名ベースのルーティングにも対応。
Cloudflare One クライアント for macOS（2026.6.782.1、ベータ）（6月24日）
macOS向けの新ベータリリース。Secure Enclaveでデバイス登録を保護する、ハードウェアベースのデバイス登録を導入しました。あわせてアクセシビリティ改善、PMTUDのデフォルト有効化、アイドル後のDNSクエリ失敗の修正、各種UI修正を含みます。
詳細
その他（ネットワーク系）
すべてのルートをダッシュボードの1ページで管理（6月19日）
Cloudflareダッシュボードの「Routes」ページで、Cloudflare Mesh／Cloudflare Tunnel のルートと、Cloudflare WAN（旧 Magic WAN）／Magic Transit の静的ルートを、製品ごとに分かれた表示ではなく1つのテーブルにまとめて表示できるようになりました。インタラクティブなネットワークマップでの可視化（ECMPルート含む）、ルートの作成・編集・削除、仮想ネットワークの管理、ルートのテストが可能です。既存のルート・API・設定は変更されません（ダッシュボード上の統合表示です）。
詳細
Regional Services向けのリージョナライズドIPバインディング（6月23日）
※ Zero Trust というより Data Localization（データローカライゼーション）文脈の更新です。
Regional Services が Regionalized IP Bindings に対応し、BYOIP（Bring Your Own IP）で持ち込んだプレフィックスのトラフィックをIPレイヤーでリージョン化できるようになりました。ホスト名単位のRegional Hostnamesに対し、CIDRをリージョンにバインドし、そのアドレス宛のTLS終端・処理を該当リージョンのデータセンター内のみで行います。Regional Services および BYOIP向けRegional Servicesのエンタイトルメントが必要です。
詳細
補足
- 本記事は Cloudflare One 全体のチェンジログから、Gateway・Access を中心に整理したものです。WARPクライアント、Tunnel／Mesh、DLP、WAN などの更新も含みます。
- 各項目のリンクは Cloudflare 公式ドキュメントの該当チェンジログ投稿です。