Cloudflare One（Zero Trust / SASE）の公式チェンジログから、2026年8月に掲載されたアップデートを Gateway・Access を中心にまとめます。今月は、Gateway による MCP（Model Context Protocol）トラフィックの自動検出やソフトウェアパッケージのダウンロード制御といった「AI・サプライチェーン」領域の可視化強化と、Access サービストークンの運用機能（安全な形式・ローテーション猶予期間・一時停止）の拡充が目立ちました。対象は2026年8月掲載分（8月3日〜8月28日）、出典は Cloudflare One Changelog および Cloudflare 全体チェンジログです。
今月の注目ポイント
-
Gateway が MCP トラフィックを自動検出し、AI セキュリティレポートを追加。 AI エージェントが外部ツールへ接続する際の通信を可視化し、
Is MCPセレクター（ベータ）でポリシー制御できます。 - Gateway に「Traffic Source（トラフィックソース）」セレクターが追加。 Cloudflare One クライアント経由か、Mesh／WAN／プロキシエンドポイント／MCP ポータル経由かといった「入口（オンランプ）」ごとにポリシーを書き分けられます。
-
Access サービストークンの運用機能が大幅強化。 シークレットスキャンで検出しやすい
cfast_形式への変更、ローテーション時の猶予期間、トークンの一時無効化が同時期に追加されました。 - ⚠ 運用影響あり: ホスト名ルーティングの GA にあわせて、初期解決IP（token IP）の既定IPv4レンジが CGNAT レンジから Cloudflare 保有のパブリックレンジ
172.64.128.0/20へ変更されました。Chrome 142 以降の Local Network Access 制限への対応が背景で、既存ネットワークとの重複可否を確認しておくと安全です。
Gateway 関連
パッケージレジストリセキュリティでソフトウェアのダウンロードを検出・制御（8月13日）
Cloudflare Gateway が、開発者や CI/CD パイプラインによるソフトウェアパッケージのダウンロードを検出し、ポリシーで制御できるようになりました。Gateway はリクエストURLからレジストリのプロトコルを判別し、エコシステム・パッケージ名・バージョン・名前空間を抽出します。対応エコシステムは npm、PyPI、RubyGems、Cargo、Go、Maven、NuGet で、HTTPポリシーでは pkg.ecosystem / pkg.name / pkg.version / pkg.namespace / pkg.purl（API のみ）の5つのセレクターを Allow・Block アクションと組み合わせて使えます。検出はホスト名ではなくレジストリプロトコルに基づくため、パブリックレジストリでも Artifactory・Nexus などの社内プロキシでも同じように機能します。利用には TLS 復号の有効化が必要です。
詳細
MCP プロトコルの検出と AI セキュリティダッシュボード（8月12日）
Gateway が、ネットワークを流れる MCP（Model Context Protocol：AI エージェントが外部ツールやデータソースへ接続するための標準プロトコル）トラフィックを自動検出するようになりました。プロトコル固有のヘッダーやペイロードの特徴を検査して MCP リクエストを識別します。HTTPポリシーには Is MCP（experimental.is_mcp）セレクターが追加され、MCP 通信の許可・ブロック・分離（Isolate）を制御できます（本セレクターは現時点でベータであり、GA までに仕様が変わる可能性があります）。あわせて Insights & Logs > Dashboards 配下に「AI security report」ダッシュボードが追加され、MCP リクエスト総数・ユニークユーザー数・ユニークMCPサーバー数、サーバー数の時系列推移、MCP を対象とした Gateway ポリシーの一覧を確認できます。
詳細
Gateway ポリシーの Traffic Source セレクター（8月12日）
Gateway の HTTP ポリシーおよび Network ポリシーに、トラフィックが Cloudflare に到達した経路（オンランプ）を識別する Traffic Source セレクターが追加されました。API フィールドは net.onramp.type で、指定できる値は Device client（device_client：Cloudflare One クライアント／WARP）、Mesh（mesh）、Cloudflare WAN（cloudflare_wan：Magic WAN）、Clientless RDP（clientless_rdp）、Proxy endpoint（proxy_endpoint：PACファイル）、Clientless Browser Isolation（agentless_biso）、MCP portal（mcp_portal）です。これにより、たとえばクライアント経由の通信と MCP ポータル経由の通信で別々のルールを適用できます。あわせて、セッションがリモートブラウザ分離（RBI）内で動作しているかを判定する Browser Isolation セレクター（net.is_isolated）も HTTP・Network の両ポリシーで利用できるようになりました。
詳細
Access 関連
Access サービストークンのシークレットがスキャン可能な形式に（8月26日）
2026年8月26日以降に作成される Cloudflare Access サービストークンのクライアントシークレットは、cfast_[英数字40文字][チェックサム8文字] という形式になりました。先頭のプレフィックスとチェックサムにより、シークレットスキャンツールが誤検知を抑えつつ資格情報を識別しやすくなります。既存のシークレットはそのまま動作し、ローテーションは不要です。新旧いずれの形式でもクライアントIDは共通で、認証ヘッダー（CF-Access-Client-Id / CF-Access-Client-Secret）も変わりません。
詳細
サービストークンのローテーションに猶予期間を設定可能に（8月25日）
Access 管理者が、サービストークンのシークレットをローテーションする際に猶予期間を選べるようになりました。猶予期間中は新旧どちらのシークレットも有効なため、認証を中断させずに各サービスの設定を更新できます。ダッシュボードでは1時間から30日までの猶予期間を指定でき、旧シークレットを即時失効させることも可能です。APIでは RFC 3339 形式の有効期限を指定して、独自のローテーションスケジュールを組めます。
詳細
Access サービストークンの一時無効化（8月25日）
Access 管理者が、サービストークンを削除せずに一時的に無効化できるようになりました。無効化されたトークンは認証に使えなくなりますが、設定自体は残るため、後から再度有効化できます。トークンを無効化すると、ローテーションの猶予期間中だった旧シークレットも同時に停止します。資格情報の漏えいが疑われる場合の封じ込めや、自動化サービスの一時停止に利用できます。
詳細
MCP サーバーポータルが MCP 2026-07-28 仕様に対応（8月25日）
MCP サーバーポータルが、クライアント接続および上流サーバー接続の双方でステートレスな MCP 2026-07-28 仕様に対応しました。ポータルの /mcp エンドポイントは、ステートレスな 2026-07-28 のリクエストと、従来の2025年版 Streamable HTTP クライアントの両方を自動的に受け付けます。上流の Streamable HTTP サーバーへ接続する際は 2026-07-28 への対応可否を確認し、未対応であれば2025年版のハンドシェイクにフォールバックします。クライアント側と上流側のプロトコル選択は独立しているため、ポータルの設定を変えずに片側ずつアップグレードできます。なお SSE 接続は引き続きレガシープロトコルを使用します。
詳細
Access のリソース一覧がリソーススコープロールに対応（8月19日）
リソーススコープの Access ロールのみを持つメンバーが、Cloudflare ダッシュボードの Access リソース一覧ページを開き、API の一覧取得エンドポイントを呼び出せるようになりました。従来はアカウントスコープの読み取り専用ロールを追加で付与する必要があり、付与しない場合はダッシュボードで一覧がブロックされ、API は 403 を返していました。表示・取得できるのは、そのメンバーの権限ポリシーのスコープに含まれるリソースのみで、フィルタリングは Access のアプリケーション・ポリシー・サービストークン・IDプロバイダーに適用されます。Cloudflare Access App Admin ロールのメンバーの場合、ポリシー一覧には選択したアプリケーションに直接紐づくポリシーが表示され、再利用可能ポリシーはそのポリシーに対する Cloudflare Access Policy Admin ロールを持つ場合のみ表示されます。
詳細
Worker 単位・アカウント全体で Access を有効化できるように（8月14日）
Cloudflare Workers を Cloudflare Access で保護する方法が2つ追加されました。1つ目は「Worker 自体にポリシーを紐づける」方式で、ルート・カスタムドメイン・workers.dev URL といった関連するすべてのドメインやプレビューURLが、ルートやドメインの変更後も保護されたままになります（従来は各ホスト名を Access アプリケーションへ手動で追加・同期する必要がありました）。2つ目は「アカウント内のすべての Worker を既定で保護する」設定で、既存・新規を問わずサインインを必須にできます。公開したままにしたい Worker は Worker レベルのバイパスで除外します。プレビューのみを保護するか本番も含めるかを選べ、サインインできる対象は Cloudflare アカウントのメンバーシップ・メールアドレス・メールドメインで制御できます。Access を有効にすると、認証済みリクエストで ctx.access が利用でき、ctx.access.getIdentity() からユーザーのメール・名前・グループを取得できます（JWT の手動検証は不要）。wrangler dev でのローカルテストにも対応しています。
詳細
インフラ向けアプリの独立MFAが FIDO2 キーに対応（8月12日）
インフラストラクチャアプリケーションが、FIDO2 キーによる独立MFA（多要素認証）に対応しました。アプリケーション単位およびポリシー単位のMFA設定で、ssh_fido2_key、piv_key、またはその両方を許可できます。ユーザーは App Launcher から FIDO2 キーを登録し、生成されたSSH IDで接続します。SSH 用の FIDO2 キーは、ブラウザベースの WebAuthn セキュリティキーや PIV（Personal Identity Verification）キーとは別扱いである点に注意してください。
詳細
AI Gateway で ID 認識型の制御が利用可能に（8月5日）
AI Gateway が Cloudflare Access と連携し、2つの機能が使えるようになりました。1つは「ゲートウェイのエンドポイント自体を Access で保護する」ことで、特定のゲートウェイを呼び出せる相手をポリシーで制御できます。もう1つは「ID 認識型の制御」で、Access で保護されたカスタムドメイン経由で AI Gateway にトラフィックが届いた場合、認証済みユーザーの Access ID をログ・分析・ルーティング・支出制御に利用できます。これにより、ユーザー単位の支出上限の設定、ユーザーごとに利用可能なゲートウェイの制御、ログのユーザー別フィルタリングが、クライアントアプリからユーザーIDを渡さなくても実現できます。AI Gateway は検証済みの Access ユーザーIDを cf.user_id としてリクエストのメタデータに付与します。
詳細
マルチドメイン Access アプリの認可Cookie制御（8月3日）
Access 管理者が、セルフホスト型アプリケーションについて「複数の公開ホスト名に対して認可Cookieを事前設定するかどうか」を制御できるようになりました。従来は、ホスト名が5個以下のアプリケーションでは自動的に eager redirect（先行リダイレクト）が使われ、6個以上ではユーザーが各ホスト名を訪問したタイミングでCookieが発行されていました。今後はホスト名の数に関わらず、どちらの挙動も選択できます。新しい Eager redirect cookie 設定は新規アプリケーションでは既定で有効で、サインイン後に各ホスト名を経由するリダイレクトを行って CF_Authorization Cookie を設定します。ホスト名が多いアプリケーションではリダイレクトの連鎖により一部のブラウザでサインインループが起きることがあるため、その場合は設定をオフにして、ユーザーが各ホスト名を訪問した際にCookieを発行する挙動に切り替えます。
詳細
その他 Cloudflare One 更新
Cloudflare One クライアント 2026.7.1376.0 / 1377.0（8月28日）
Windows・macOS 向けに 2026.7.1376.0、Linux 向けに 2026.7.1377.0 の GA（安定版）リリースが公開されました。いずれのプラットフォームでも、一部のDNSクエリが失敗する問題（発生率は低いものの無視できない割合）を修正しています。加えて Windows 版では、インストール済みクライアントのバージョンを切り替えた際に登録情報が不正となり、接続や組織の切り替えに失敗することがあるという、まれではあるものの重大な問題も修正されています。
詳細（Windows） / 詳細（macOS） / 詳細（Linux）
Cloudflare One 仮想アプライアンスをハイパーバイザー別にダッシュボードからダウンロード（8月24日）
Cloudflare One 仮想アプライアンスを登録する際に、ハイパーバイザーを選択してダッシュボードから直接ダウンロードできるようになりました。アセットURLを調べる必要はありません。Connectors ページで「Add an appliance」→「Virtual appliance」を選び、VMware ESXi・Proxmox・libvirt/KVM のいずれかを選択すると、VMware ESXi では OVA イメージ、Proxmox と libvirt/KVM ではインストールスクリプトをダウンロードできます。「View setup guide」から各プラットフォーム向けの導入手順も開けます。すでに提供されているダッシュボードでのセルフサービス登録・ライセンスキー発行と組み合わせて利用できます。
詳細
CASB の修復ポリシーで Microsoft 365 / Google Workspace の検出結果を自動対処（8月21日）
Cloudflare CASB（API ベース＝エージェントレスで SaaS・クラウドアプリのセキュリティ設定ミスやデータ露出を継続的にスキャンするツール）に、CASB 修復ポリシーが追加されました。検出（finding）が発生した瞬間に、自動で修復するかWebhookを送信でき、手作業のトリアージが不要になります。修復は Cloudflare 自身（ファーストパーティ）が SaaS 連携のAPIに対して直接実行するもので、ポリシーが発動すると Cloudflare が外部共有設定を自動的に取り消します。現時点で修復に対応しているのは Microsoft 365 と Google Workspace のファイル共有に関する検出結果で、対象は今後拡大予定です。Webhook 送信は CASB 連携全体のすべてのポスチャ検出タイプに対応しており、Slack・ServiceNow などの任意の宛先へ送れます。1つのポリシーで修復とWebhook送信の両方を実行することも可能です。
詳細
Gateway に通さずに DLP プロファイルをテストできる「Test scan」（8月21日）
Test scan により、DLP（Data Loss Prevention：データ損失防止）プロファイルを本番トラフィックに適用する前に、サンプルコンテンツがどう評価されるかを確認できるようになりました。テキストの貼り付け、ファイルのアップロード、HARファイルのアップロードのいずれかを行い、テストしたいプロファイルを選択します。Test scan はコンテンツを DLP スキャナーへ直接送るため、Gateway ポリシーは評価されず、トラフィックが Gateway を通過することも、Gateway のアクティビティログが作成されることもありません。結果には、一致したプロファイル、検出エントリ、信頼度、一致箇所の前後の文脈、近接キーワード、ファイルのメタデータ、アンチウイルスのステータス、OCR の出力が含まれます。Test scan はすべての Cloudflare Zero Trust ユーザーが利用できますが、使えるプロファイルは Zero Trust プランに依存します。
詳細
Cloudflare One クライアント 2026.7.1343.0（8月19日）
Windows・macOS・Linux 向けに 2026.7.1343.0 の GA（安定版）リリースが公開されました。ベータ版で提供していた次の機能が安定版に入っています。(1) 再認証が必要になった際の通知が分かりやすくなり、必要に応じてアプリのウィンドウではなくブラウザへ誘導することで、作業再開までの操作を減らします。(2) HTTP/3 がブロックされる、あるいは相性の悪いネットワークでは、フォールバック順を入れ替えて HTTP/2 から先に試すよう学習・適応し、古い環境や強くフィルタリングされたネットワークでの接続までの遅延を減らします。
プラットフォーム別の主な修正は次のとおりです。
- 共通（Windows / macOS / Linux）: DNS 検索ドメインの解析失敗で接続できなくなる問題、接続済みなのにクラウドアイコンが未接続表示になる問題、競合状態による証明書エラーの表示欠落、ドッキングしたデュアルディスプレイから内蔵ディスプレイへ切り替えた際にウィンドウが黒く空になる問題、「Device not in organization」状態で別の組織へログイン・切り替えができない問題を修正。
- Windows のみ: IPC クライアント生成失敗時にシステムリソースを枯渇させ得る GUI のプロセスリークを修正。Intune でのインストール時に Microsoft Defender が誤って悪意あるものとして検知する問題を修正。ドメイン参加のポスチャチェックの信頼性を改善。
- macOS のみ: Wi-Fi のキャプティブポータルへ接続しようとした際のクラッシュを修正。
- Linux のみ: ホスト名のIPアドレスがローカルアドレスの場合に Cloudflare Mesh のホスト名ルートが機能しない問題を修正。
既知の問題として、Windows では 2026.7.1343.0 へアップグレード後に旧バージョンへダウングレードし、再登録したうえで再び 2026.7.1343.0 へ上げると、接続や組織の切り替えに失敗することがあります（warp-cli registration delete または warp-cli registration delete-all で解消します）。Linux では DNS Only モードのとき、ローカルドメインフォールバック対象の名前のクエリがシステム設定へフォールバックせず暗号化DNSサーバーへ送られることがあります（他のモードでは正常に動作します）。macOS の既知の問題はありません。
詳細（Windows） / 詳細（macOS） / 詳細（Linux）
Cloudflare Tunnel のオリジン設定をダッシュボードから構成（8月18日）
Cloudflare Tunnel の公開アプリケーションルートを追加・編集する際に、オリジンアプリケーションの設定を Cloudflare ダッシュボードから直接構成できるようになりました。これらは cloudflared がオリジンサーバーへ接続する方法を制御する設定で、従来は Cloudflare One ダッシュボードかローカルの設定ファイルからしか変更できませんでした。公開アプリケーションの編集画面で「Additional application settings」を展開すると、HTTP（カスタム Host ヘッダーの指定、チャンク転送エンコーディングの無効化）、TLS（オリジンのサーバー名、CAプール、TLSタイムアウト、TLS検証の無効化、SNIとHostの一致、オリジンへのHTTP/2の有効化）、Connection（接続タイムアウト、キープアライブのタイムアウトと接続数、TCPキープアライブ間隔、プロキシタイプ、Happy Eyeballs の無効化）の3カテゴリを設定できます。
詳細
メールセキュリティの MX 構成でポスト量子鍵交換に対応（8月17日）
Cloudflare Email Security が、メールの受信・配送に使う SMTP 接続で X25519MLKEM768 によるポスト量子ハイブリッド鍵交換に対応しました。ポスト量子ハイブリッド鍵合意に対応したプロバイダー（Google Workspace など）の前段に Email Security を配置すると、ポスト量子鍵合意を用いた TLS 1.3 接続が確立されます。受信側の MX 接続と送信側の配送接続のいずれも、相手が対応している場合に X25519MLKEM768 をネゴシエートし、「今収集して後で復号する（harvest-now, decrypt-later）」攻撃から SMTP 通信を保護します。後方互換性があり、全ユーザーで自動的に有効化されます。ポスト量子鍵合意に未対応の送受信者とは、従来どおり古典的な鍵交換で接続します。対象は Advantage、Enterprise、Enterprise + PhishGuard のすべてのパッケージです。
詳細
メールセキュリティのブロックコンテンツルール（8月12日）
Cloudflare Email Security で、管理者が独自のコンテンツベースのブロックルールを作成できるようになりました。Policies & rules 配下の新しい Blocked content から、プレーンテキストの文字列または正規表現を定義し、件名・本文・その両方のどれをスキャンするかを選んで、一致したメッセージを自動的にブロックできます。組織固有の文言や既知の悪質なフレーズ、標的型フィッシングのパターンをブロックする用途に向いています。保存前にサンプルテキストへパターンを当てて確認できる正規表現チェッカーが組み込まれており、誤検知を避けられます。一致したメッセージは malicious（悪意あり）のディスポジションが付与され、ユーザーの受信トレイには届きません。現時点でブロックコンテンツルールがサポートするアクションはブロックのみで、対象パッケージは Enterprise と Enterprise + PhishGuard です。
詳細
ホスト名ルーティングが GA に。初期解決IPの既定レンジがパブリックレンジへ変更（8月11日）
ホスト名ルーティングが一般提供（GA）になりました。静的なIPリストやルートを管理する代わりに、複数の Cloudflare One コネクタをまたいでホスト名単位でトラフィックをルーティングできます。Cloudflare Tunnel では、プライベートホスト名（例：wiki.internal.local）をトンネル配下のプライベートアプリへルーティングしたり、パブリックホスト名（例：bank.example.com）を特定のトンネル経由で egress させて専用の出口ノードに固定したりできます。Cloudflare Mesh では、プライベート／パブリックいずれのホスト名のトラフィックも Mesh ノードへ引き寄せられます。
あわせて、初期解決IP（token IP）に使われる既定のIPv4レンジが、CGNAT レンジから Cloudflare 保有のパブリックレンジへ変更されました（IPv4: 172.64.128.0/20、IPv6: 2606:4700:0cf1:4000::/64。IPv6 レンジは変更なしで、今回の制限の影響も受けません）。背景は Chrome 142 以降の Local Network Access（LNA）制限で、CGNAT アドレス（100.64.0.0/10、従来の既定値 100.80.0.0/16 を含む）へのバックグラウンドリクエストがブロックされるようになったためです。LNA は Chromium エンジンのレベルで実装されているため、Microsoft Edge・Brave・Opera など Chromium 系ブラウザ全般に影響します。初期解決IPは、Tunnel のプライベート／パブリックのホスト名ルーティング、Mesh のホスト名ルート、非HTTPSポートでの Access プライベートアプリ、egress ポリシーのホストセレクター（Domain、Host、Application、Content Categories）で利用されます。既定レンジが自ネットワークと競合する場合は、Networking > IP addresses > Address space > Custom IPs または API からカスタムレンジを設定できます。
詳細
Cloudflare Tunnel のライブログをダッシュボードでストリーミング（8月10日）
Cloudflare ダッシュボードの Networking > Tunnels で、Tunnel のログをリアルタイムにストリーミングできるようになりました。これまで Cloudflare One ダッシュボードでのみ利用できたライブデバッグ機能が、高可用性構成向けのマルチコネクタ集約ストリーミングも含めて提供されます。トンネルの詳細画面に追加された Live logs タブでは、複数の cloudflared レプリカを配置した高可用性構成でも全コネクタのログを1つのストリームにホスト名でグルーピングして統合表示でき、どのホストが出力したログかを識別できます。ログレベル、イベント種別（HTTP・TCP・UDP・cloudflared 内部）、HTTPメソッドによる絞り込みにも対応します。
詳細
Cloudflare One クライアント for Windows（2026.6.905.0）（8月10日）
Windows 向け Cloudflare One クライアントの GA（安定版）リリース 2026.6.905.0 が公開されました。スリープからの復帰後に再接続できなくなる、まれかつ断続的に発生する事象を修正したホットフィックスです。※本リリースは Windows 版のみの提供です。
詳細
Cloudflare Mesh のコンテナイメージ（8月7日）
Cloudflare Mesh のノードを Docker コンテナとして実行できるようになりました。Docker Hub で公開されている cloudflare/mesh イメージを使えば、Docker Compose、Kubernetes、その他 OCI 互換ランタイムでホストへのパッケージインストールなしに稼働させられます。イメージは amd64 と arm64 に対応し、ソースNAT を内蔵しているため VPC のルートテーブルを変更しなくても戻りのトラフィックが正しくルーティングされます。想定される構成は、Docker Compose（compose.yaml に cloudflare-mesh サービスを追加してスタック全体をプライベートネットワークへ接続）、Kubernetes StatefulSet（登録状態を永続化したスタンドアロンノード）、Kubernetes サイドカー（Pod 内のサイドカーとしてアプリを無改修で接続）、CI/CD（パイプラインでイメージを取得して Mesh に参加し、プライベート環境に対して結合テストを実行、コンテナ終了とともにノードも消滅）です。高可用性が必要な場合は、同じ Mesh ノードトークンで複数レプリカを起動すると、Cloudflare がアクティブ／パッシブで運用し自動フェイルオーバーします。
詳細
出典・対象期間
- 対象: 2026年8月掲載分（2026年8月3日〜8月28日）
- 出典: Cloudflare One Changelog および Cloudflare 全体チェンジログ
- 本記事は Cloudflare One 全体のチェンジログから、Gateway・Access を中心に、Cloudflare One クライアント（WARP）・Tunnel/Mesh・DLP・CASB・メールセキュリティ・仮想アプライアンスなどの更新を整理したものです。専門用語は必要に応じて簡単に補足しています。
- 補足: 8月1日〜10日のエントリ（8月10日の「Tunnel のライブログ」および「Cloudflare One クライアント for Windows 2026.6.905.0」、8月7日の「Cloudflare Mesh のコンテナイメージ」、8月5日の「AI Gateway の ID 認識型制御」、8月3日の「マルチドメイン Access アプリの認可Cookie制御」）は、Cloudflare One 製品グループ専用フィードのページングから漏れていたため、全体チェンジログおよび Cloudflare One ドキュメントのチェンジログから補完して収録しています。