Cloudflare Queues が jurisdictions に対応。eu / us / fedramp でメッセージの保持地域を固定できるが、作成後は変更できない

要約

Cloudflare Queues が jurisdiction（管轄地域）指定付きで作成できるようになりました。指定すると、そのキューのメッセージは1つの地域内に留まります。

指定できる値は3つです。

• eu
• us
• fedramp（FedRAMP-Moderate データセンター）

設定方法は2つです。 新しい cf CLI の --jurisdiction フラグ、または Create Queue API エンドポイントの jurisdiction パラメータ。

この機能の実質的な中身は、制約の側にあります。 公式は jurisdiction は作成時にしか設定できず、後から変更できないと明記しています。既存のキューを地域限定へ移すには、作り直してデータを移送することになります。

この形は Cloudflare 内で既に見た形です。 Workers KV の namespace jurisdictions が 2026-10-02 に GA になっており、値も同じ3つ（eu / us / fedramp）、作成後は変更できないという制約も同じです。つまり今回の変更は、Cloudflare の開発者プラットフォーム全体でデータレジデンシー対応が製品横断に広がっている流れの中にあります。KV で保存先を固定し、Queues でメッセージの保持先を固定する。同じ設計の適用範囲が増えているという読み方が正確です。

なお Workers KV のときに公式が明記していた注意点を思い出してください。 KV では「jurisdiction が縛るのは永続的な保存場所だけで、データは jurisdiction の外にある Cloudflare ネットワーク上でキャッシュされうる」と書かれていました。Queues の changelog には、これに相当する記述はありません。 メッセージがどこを通るかについての言及が無いため、「域内に留まる」の射程を公式記述以上に広げて読むべきではありません。

日付について1点補足します。 changelog エントリの URL のスラッグは 2026-09-18-queues-jurisdictions ですが、横断 RSS と製品別 RSS の pubDate はいずれも 2026-10-12 です。本記事は RSS の日付を採用しています。

何が変わったか

• Queues を jurisdiction 指定付きで作成できるようになった
• 指定可能な値は eu / us / fedramp（fedramp は FedRAMP-Moderate データセンター）
• 指定するとメッセージは1つの地域内に留まる
• 設定は cf CLI の --jurisdiction または Create Queue API の jurisdiction パラメータ
• jurisdiction は作成時にしか設定できず、後から変更できない（公式明記）
• 既存キューの移行には作り直しとデータ移送が必要
• 同系統の機能は Workers KV で 2026-10-02 に GA（同じ3値、同じ変更不可の制約）
• メッセージの経路（通過地点）についての記載は changelog に無い
• changelog の URL スラッグは 2026-09-18 だが、RSS の pubDate は 2026-10-12

業務インパクト（一般企業向け）

まず、この機能が解く問題を正確に言います。

データレジデンシーの要件は、「データがどこに保存されるか」を契約や法令で縛るものです。GDPR、FedRAMP、国内の公共調達。要件の文面は案件ごとに違いますが、**審査で聞かれるのは「保存場所を特定できるか」**です。「グローバルに分散しています」という回答は、要件がある案件では通りません。

Queues が jurisdiction に対応したということは、非同期処理のキューが審査の対象から外れなくなった、という意味です。 これまでは「キューを使うとメッセージの保持先が特定できない」という理由で、要件がある案件では Queues を避けるか、別の仕組みを立てるしかありませんでした。選択肢が増えます。

ただし、実務で効く論点は2つあります。

1つ目は、作成後に変更できないことです。

これは単なる制約ではなく、設計プロセスに影響します。 データレジデンシーの要件は、プロジェクトの最初から分かっていることが少ない類の要件です。開発が進んでから法務レビューが入り、「EU の顧客データは EU 内に留める必要がある」と言われる。その時点で既にキューが動いていたら、作り直しとデータ移送になります。

対策は2つのどちらかです。

• 要件が出る可能性のある案件では、最初から jurisdiction を付けて作る。 不要だった場合の損失は小さく、必要になった場合の救いは大きい
• キュー名とリソース定義を環境変数化しておく。 作り直しが発生しても、参照箇所を全部直す作業にならないようにする

「後から直せない設定」は、設計レビューのチェック項目にすべきです。 Workers KV も同じ制約を持っているため、Cloudflare のデータレジデンシー系機能はすべてこの性質を持つと考えて運用するのが安全です。

2つ目は、eu / us / fedramp という3択の射程です。

日本に本社がある組織にとって、この3つは直接の答えではありません。 国内にデータを留める要件がある場合、この機能では満たせません。満たせるのは、EU 顧客向けサービスを運営している場合、米国政府・公共系の調達要件がある場合です。

ここを混同すると、要件を満たしたつもりで満たせていない状態が生まれます。 「データレジデンシーに対応しました」という報告が、どの地域の要件に対する対応なのかを明示してください。

そして経路についての記載が無い点を押さえてください。 Workers KV のときは「キャッシュは域外に出る」と公式が明記していました。Queues の changelog には対応する記述がありません。無いことは「域外に出ない」の保証ではありません。 厳格な要件の案件では、サポート経由で経路について確認を取るのが筋です。公式に書かれていないことを「書かれていないから大丈夫」と読む判断は、監査で崩れます。

副業・個人活用視点

個人開発で fedramp を使う場面はまず来ません。 正直に言って、この機能はエンタープライズ寄りの要件に応えるものです。ただし、仕事の取り方として見ると使い道があります。

1つ目は、「要件に答えられる構成を知っている」こと自体が差になる点です。

AI 系の受託や相談で、「データはどこに保存されますか」という質問は必ず来ます。 多くの開発者はここで止まります。「Cloudflare に保存されます」では答えになっていません。「Workers KV は namespace 単位で eu / us / fedramp に固定でき、Queues も作成時に同じ3択で固定できます。ただし作成後は変更できないので、要件が出る可能性があるなら最初から付けて作ります」——この粒度で答えられるかどうかが、技術者としての信頼の差になります。情報自体は公式に書いてあり、読んだ人だけが答えられます。

2つ目は、「後から直せない設定」の棚卸しを仕事にできる点です。

既存システムに対して、作成時にしか決められない設定がどこにあるかを一覧にする作業は、短時間で終わり、かつ価値が明確です。jurisdiction、リージョン、namespace 名、ID 体系。どれも「後で変えればいい」と思っていると、変えられないことが分かった時点で工数が跳ねます。 この一覧を作って渡すだけで、設計レビューの受託に繋がります。

3つ目は、コンテンツの題材としての切り口です。

「GDPR 対応」という記事は無数にありますが、「作成後に変更できない設定という設計上の性質」を軸にした記事は少ないです。Cloudflare の KV と Queues が同じ3値・同じ変更不可の制約を持っているという事実は、**「ベンダーの設計思想は製品横断で一貫する」**という一般論の具体例になります。1製品の機能紹介より射程が広く、他の製品が同じ対応をしたときに書き直さずに使えます。

注意点を1つ。 3択は eu / us / fedramp です。国内にデータを留める要件には応えません。 日本の案件で「対応しています」と言うと、後で食い違います。