Workers KV の jurisdictions が GA。eu / us / fedramp で保存先を固定できるが、作成後は変更不可でキャッシュは域外に出る

要約

**Workers KV の namespace jurisdictions が一般提供（GA）**になりました。KV の namespace に対して、データを永続的に保存する地理的範囲を限定できます。

指定できるのは eu / us / fedramp の3つです。fedramp は FedRAMP 準拠データセンター向けです。

npx wrangler@latest kv namespace create <NAMESPACE_NAME> --jurisdiction=eu

この機能で最も重要なのは、公式が明記している制約の方です。

(1) 読み取りは世界中の Worker から可能で、データは jurisdiction の外にある Cloudflare ネットワーク上でキャッシュされうる。 jurisdiction が縛るのは永続的な保存場所だけです。「EU 内にしかデータが存在しない」という意味ではありません。

(2) jurisdiction は namespace の作成時にしか設定できず、後から追加・変更できない。 既存 namespace を地域限定へ移すには、作り直してデータを移送する必要があります。

この2点を押さえずに「データレジデンシー対応済み」と説明すると、後で要件を満たしていないことが判明します。 データレジデンシーの要件は案件ごとに文面が違い、「保存先が域内であること」で足りる場合と、「域外を経由しないこと」まで求める場合があります。Workers KV の jurisdictions が満たすのは前者だけです。

何が変わったか

• Workers KV の namespace jurisdictions が GA（一般提供）
• 指定できるのは eu / us / fedramp の3つ
• 設定経路はダッシュボード、Wrangler、cf CLI、REST API
• jurisdiction は namespace 作成時のみ指定可能。後から追加・変更はできない
• 読み取りは世界中の Worker から可能
• jurisdiction の外にある Cloudflare ネットワーク上でキャッシュされうる（公式明記）
• 縛られるのは永続的な保存場所のみ

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

まず、自社の要件文がどちらを求めているかを確認してください。 「個人データを EU 域内に保存すること」なら、この機能で満たせます。「EU 域外のサーバーを経由しないこと」なら、キャッシュが域外に出る仕様では満たせません。 契約書や社内規程の文言を読み直す作業が先です。

GDPR の文脈では、保存場所の限定だけでは不十分な場合があります。 データの「処理」には転送も含まれるため、キャッシュを転送と見なすかどうかが論点になります。 この判断は法務マターで、技術側で結論を出すべきではありません。仕様を正確に法務へ渡すのが技術側の仕事です。「キャッシュは域外に出うる」と公式が明記していることを、そのまま伝えてください。

作成後に変更できない制約は、設計のタイミングを前倒しします。 「とりあえず作って、要件が固まったら設定する」ができません。namespace の設計時点で、データレジデンシー要件の有無を確定させる必要があります。 要件が不確実な案件では、最初から jurisdiction を指定しておく方が安全です。後から要件が出たときに移送作業が発生するよりは、最初から限定しておく方がコストが低いためです。

データ移送が必要になった場合の見積もりも、考慮しておくべきです。 KV のデータ量とキー数次第では、移送に相応の工数がかかります。本番稼働後に移送する手順（新旧 namespace の併用期間、切り替え方法）を設計しておくと、要件変更に耐えられます。

fedramp の指定は、米国政府系の調達に関わる組織のみ関係します。 国内案件では eu と us の2択と考えて問題ありません。

日本国内のデータレジデンシー要件には、この機能は答えません。 jp の指定はないため、「国内保存」が要件の案件では Workers KV は選択肢から外れます。R2 など他の製品の対応状況を別途確認する必要があります。

副業・個人活用視点

この機能自体を使う機会は限られますが、知識としては価値があります。 個人で受ける案件でデータレジデンシー要件が出ることは稀です。しかし**「出たときに即答できるか」は、信頼の差になります。**

特に、制約を正確に説明できることが差別化になります。 「Cloudflare は EU 保存に対応しています」とだけ答える人と、「保存先は限定できますが、キャッシュは域外に出る仕様なので、要件の文面を確認させてください」と答える人では、その後の仕事の任され方が変わります。公式ドキュメントに書いてあることを読んでいるかどうか、という単純な差です。

提案の場面では、「できません」を早く言えることが価値になります。 国内保存が要件なら Workers KV は使えません。この判断を設計の初期に出せれば、後戻りが発生しません。 要件を満たさない構成で進めて後から判明するのが、最も高くつくパターンです。

学習の観点では、「保存」と「転送」と「キャッシュ」を区別する習慣が身につきます。 この区別は、データレジデンシーに限らず、個人情報の取り扱い全般で効きます。どの製品のドキュメントでも、この3つがどう扱われているかを探す癖をつけると、リスクの見落としが減ります。

作成後に変更できない設定がある、という事実も一般化できます。 クラウド製品には同種の「後から変えられない選択」が点在します（リージョン、命名、暗号化キーの設定など）。構築前に「後から変えられないものは何か」を洗い出す手順を、自分のチェックリストに入れておく価値があります。