Cloudflare Workflowsのjurisdictionでインスタンスの実行と保存をEU内に限定する

Cloudflare Workflowsのjurisdictionでインスタンスの実行と保存をEU内に限定する

Cloudflare Workflowsに、インスタンスの実行と保存の場所を限定するjurisdictionが加わりました。Freeプランのアカウントでeuを設定し、作成後に変えようとしたときのエラー、古いWranglerでの扱い、作り直す手順などを確かめました。
2026.11.15

どうも!オペ部の西村祐二です!

EUのユーザーのデータを扱う処理をCloudflare Workflowsで動かすとき、実行する場所とデータを保存する場所をEU内に限定したい場面があります。2026年10月27日のChangelogで、Workflowにjurisdictionを設定できるようになりました。

設定はWranglerの設定ファイルに1行足すだけです。ただし、jurisdictionはWorkflowを作るときに決まり、後から変えられません。この記事では、Freeプランのアカウントで jurisdiction: "eu" を設定し、設定の確認方法、作成後に変えようとしたときの挙動、古いWranglerで作ったときの扱い、作り直す手順を確かめます。あわせて、script_name で参照する側に書いた場合とローカル開発での扱いも確かめます。

今回の変更点

  • 対象バージョン / 日付: 2026-10-27のChangelog。Wrangler 4.152.0以上が必要です
  • 変更の要点: Workflowに jurisdiction を設定すると、そのWorkflowのインスタンスは指定した地域の中で実行され、データもその中に保存されます。GDPRや、米国政府機関向けクラウドサービスの認証制度であるFedRAMPのような、データの所在に関する要件に対応するための機能です
  • 指定できる値: eu(欧州連合)、us(米国)、fedramp(FedRAMP Moderateのデータセンター)
  • 設定する場所: workflows バインディング、または exports で宣言したWorkflow(今回試したのは workflows バインディングだけです)
  • 公式ドキュメント: Data location

Data locationのページには、次の点も書かれています。

  • jurisdictionは作成時に決まり、後から変えられません
  • Workflowの設定(settings)はjurisdictionの外に保存されます
  • Workerは、jurisdictionを付けたWorkflowのインスタンスを、どこからでも作成・管理できます。Cloudflareがリクエストに応答する地域を制御したい場合は、Regional Servicesを検討するよう書かれています
  • ローカル開発ではjurisdictionは無視されます
  • script_name と一緒には指定できません

次の図は、上の記述を自作の概念図にしたもので、公式の構成図ではありません。

自作した、Workflowsのjurisdictionの概念図。wrangler.jsoncのworkflowsにjurisdiction: euを書いてWrangler 4.152.0以上でデプロイすると、Cloudflare上でWorkflowインスタンスはjurisdiction euの中で実行され、インスタンスのデータもそこに保存される。Workflowの設定はjurisdictionの外に保存される。Workerはバインディング経由でどこからでもインスタンスを作成・管理できる。jurisdictionはWorkflowの作成時に決まり、後から変更できない

wrangler.jsoncに1行足してdescribeで確かめる

wrangler.jsonc の workflows に jurisdiction を足します。

wrangler.jsonc
{
  "name": "blog-verify-wf-jurisdiction",
  "main": "src/index.js",
  "compatibility_date": "2026-10-27",
  "workers_dev": false,
  "preview_urls": false,
  "workflows": [
    {
      "name": "blog-verify-wf-eu",
      "binding": "EU_WORKFLOW",
      "class_name": "EuWorkflow",
      "jurisdiction": "eu"
    }
  ]
}

公開URLは使わないので、"workers_dev": false と "preview_urls": false も入れています。TOMLで書く場合も、workflows の各エントリに jurisdiction = "eu" を足します(ChangelogにTOMLの例があります)。

デプロイ後のjurisdictionは wrangler workflows describe で確認できます。

npx wrangler workflows describe blog-verify-wf-eu

新しく作るWorkflowに付けるだけなら、これで終わりです。ここからは、作成後に変えようとした場合、古いWranglerを使った場合、作り直す手順、別のWorkerから参照する場合、ローカル開発の順に確かめます。

試した環境

  • Wrangler 4.156.0(比較用に4.151.3)
  • Node.js v24.21.0(Linuxのコンテナ)
  • Cloudflare(Freeプラン)のアカウント
  • 検証用に作ったWorkerとWorkflowは、確認後に削除しました

検証に使ったのは、step.do 2つと2秒の step.sleep 1つだけを持つWorkflowです。ローカル開発の確認用に、インスタンスを作る fetch ハンドラも入れています。

src/index.js
import { WorkflowEntrypoint } from "cloudflare:workers";

export class EuWorkflow extends WorkflowEntrypoint {
  async run(event, step) {
    const first = await step.do("record start", async () => ({ startedAt: new Date().toISOString() }));
    await step.sleep("short wait", "2 seconds");
    return await step.do("finish", async () => ({ ...first, params: event.payload }));
  }
}

export default {
  async fetch(request, env) {
    const url = new URL(request.url);
    if (url.pathname === "/create") {
      const instance = await env.EU_WORKFLOW.create({ params: { from: "fetch" } });
      return Response.json({ id: instance.id, status: await instance.status() });
    }
    if (url.pathname === "/status") {
      const instance = await env.EU_WORKFLOW.get(url.searchParams.get("id"));
      return Response.json(await instance.status());
    }
    return new Response("ok\n");
  },
};

Cloudflare上のインスタンスは wrangler workflows trigger で作り、ローカル開発ではこの fetch ハンドラから作りました。

jurisdictionを付けてデプロイする

上の設定で wrangler deploy を実行すると、エラーなくデプロイできました。

Uploaded blog-verify-wf-jurisdiction (1.46 sec)
Deployed blog-verify-wf-jurisdiction triggers (7.01 sec)
  workflow: blog-verify-wf-eu

wrangler workflows describe の出力に Jurisdiction: eu の行が出ました。次の画像は、次の節で us へ書き換えたデプロイが失敗し、設定から jurisdiction を消して再デプロイした後に撮ったもので、jurisdictionは eu のままです。

ターミナルでnpx wrangler workflows describe blog-verify-wf-eu | head -9を実行した画面。Name: blog-verify-wf-eu、Id、Script Name: blog-verify-wf-jurisdiction、Class Name: EuWorkflow、Jurisdiction: eu、Created Onが表示されている

インスタンスを作って状態を確かめました。

npx wrangler workflows trigger blog-verify-wf-eu '{"from":"cli"}'
npx wrangler workflows instances describe blog-verify-wf-eu latest
Duration:              2 seconds
Last Successful Step:  finish-1

Status は Completed で、インスタンスは約2秒で完了しました。record start、short wait、finish の3つ(step.do 2つと step.sleep 1つ)がすべて成功しています。

Changelogとドキュメントにプランの条件は書かれていませんが、2026年11月3日時点では、Freeプランのアカウントでもデプロイとインスタンスの実行ができました。Freeプランで作成まで試したのは eu だけで、us と fedramp を新しく作れるかは試していません。

作成後にjurisdictionは変えられない

jurisdiction を "us" にした wrangler.us.jsonc を用意し、作成済みのWorkflowに対して npx wrangler deploy -c wrangler.us.jsonc を実行すると、次のエラーで止まりました。

ターミナルでgrep '"jurisdiction"' wrangler.us.jsoncの結果が"jurisdiction": "us"と表示された後、npx wrangler deploy -c wrangler.us.jsoncがERROR The following Workflow(s) already exist with a different jurisdictionで止まり、blog-verify-wf-eu (has jurisdiction "eu", configured "us")と表示されている画面

✘ [ERROR] The following Workflow(s) already exist with a different jurisdiction:

    - "blog-verify-wf-eu" (has jurisdiction "eu", configured "us")

  A Workflow's jurisdiction is set when it is created and cannot be changed. To use a different jurisdiction, rename the Workflow(s) in your wrangler.us.jsonc, or delete the existing Workflow(s) first, which also deletes their instances.

終了コードは1で、Uploaded の行は出ず、Workerのアップロード前に止まっています。wrangler versions upload でも同じエラーになりました。エラーの後も、Workflowのjurisdictionは eu のままでした。

逆に、設定ファイルから jurisdiction の行を消してデプロイすると、警告もなく成功しました。describe では、Id と Created On は変わらず Jurisdiction: eu のままで、更新されたのは Modified On と最新バージョンのIDでした。ドキュメントにも、設定から外しても既存のjurisdictionは変わらないと書かれています。設定ファイルに書かれていなくても eu のままなので、実際の値は wrangler workflows describe で確認します。

古いWranglerではjurisdictionが無視される

jurisdictionに対応する前のWrangler 4.151.3で、jurisdiction: "eu" を書いた設定で新しいWorkflow(blog-verify-wf-old-eu)をデプロイしました。警告は出ましたが、デプロイは成功しました。

▲ [WARNING] Processing wrangler.jsonc configuration:

    - Unexpected fields found in workflows[0] field: "jurisdiction"

There is a newer version of Wrangler available (current: 4.151.3, latest: 4.156.2). Try upgrading, as it might support this configuration option.

作成されたWorkflowを4.156.0の describe で見ると Jurisdiction の行がなく、jurisdictionなしで作られていました。

この状態からWrangler 4.156.0に上げ、同じ設定でデプロイすると、jurisdictionを後から付けることになるため、先ほどと同じエラーで止まります。

    - "blog-verify-wf-old-eu" (has no jurisdiction, configured "eu")

CIなどでWranglerのバージョンを固定している場合は、jurisdictionを書く前にWranglerを4.152.0以上に上げておく必要があります。警告を見落とすと、jurisdictionなしのWorkflowができてしまい、後から付けられません。

jurisdictionを変えるには削除して作り直す

エラーメッセージには、Workflowを別の名前にするか、既存のWorkflowを削除してから作り直す方法が示されています。今回試したのは削除して作り直す方法で、別の名前にした場合に元のWorkflowとインスタンスがどう扱われるかは確かめていません。削除するとインスタンスも消えるので、残しておきたい実行結果があれば先に確認しておく必要があります。

jurisdictionなしで作られた blog-verify-wf-old-eu を削除してから、もう一度デプロイしました。

npx wrangler workflows delete blog-verify-wf-old-eu
npx wrangler deploy

削除コマンドを実行すると Workflow "blog-verify-wf-old-eu" removed successfully. と表示され、実行中のインスタンスの終了には数分かかることがあるという注意も表示されました。

デプロイは成功し、describe には Jurisdiction: eu が出ました。Workflowの Id と Created On は新しくなっています。

作り直した直後に wrangler workflows instances list を実行すると、削除前に完了したインスタンスが1件表示されました。約3分後に、そのインスタンスIDで instances describe を実行すると、workflows.api.error.instance.invalid_id [code: 10404] のエラーが返りました。直後の一覧に表示された理由は切り分けていません。

script_nameで参照する側には書かない

script_name で別のWorkerのWorkflowを参照するバインディングに、jurisdiction を書いた場合も試しました。

wrangler.jsonc(呼び出し側)
{
  "name": "blog-verify-wf-caller",
  "main": "src/index.js",
  "compatibility_date": "2026-10-27",
  "workers_dev": false,
  "preview_urls": false,
  "workflows": [
    {
      "name": "blog-verify-wf-eu",
      "binding": "EU_WORKFLOW",
      "class_name": "EuWorkflow",
      "script_name": "blog-verify-wf-jurisdiction",
      "jurisdiction": "eu"
    }
  ]
}

Wrangler 4.156.0の wrangler deploy --dry-run はエラーなく終わりました。--dry-run を付けないデプロイでは、Workerのスクリプトがアップロードされた後にエラーになりました。

Uploaded blog-verify-wf-caller (0.92 sec)

✘ [ERROR] Workflow "blog-verify-wf-eu" has "jurisdiction" configured but references external script "blog-verify-wf-jurisdiction". Configure jurisdiction on the worker that defines the workflow.

エラーの時点でスクリプトはアップロード済みで、blog-verify-wf-caller はアカウントに残りました(後片付けの wrangler delete で削除しています)。jurisdictionは、Workflowを定義しているWorker側だけに書きます。jurisdictionを書かない正しい設定で、呼び出し側からインスタンスを作るところまでは試していないので、別のWorkerから呼べることはドキュメントの「どこからでも作成・管理できる」という記述に基づきます。

ローカル開発では無視される

wrangler dev で、jurisdiction: "eu" を書いた設定のまま fetch ハンドラの /create を呼ぶと、インスタンスが作成され、5秒後の /status は complete を返しました。開発サーバーのログにも、wrangler workflows describe --local の出力にも、jurisdictionは表示されませんでした。ドキュメントのとおり、ローカル開発ではjurisdictionは使われません。そのため、作成後に変えられない制約は、Cloudflareにデプロイした検証用のWorkflowで確かめる必要があります(ローカルで値を変えて試してはいません)。

導入前に確認したいこと

確認すること 理由
Wranglerが4.152.0以上か 4.151.3は警告だけ出してjurisdictionなしのWorkflowを作り、後から付けられなかった
既存のWorkflowか、新しく作るWorkflowか 既存のWorkflowには付けられない。別の名前にするか、削除して(インスタンスも消える)作り直す
定義側のWorkerに書いているか script_name で参照する側に書くとデプロイが失敗する。Wrangler 4.156.0の --dry-run では検出されなかった
実際のjurisdiction 設定ファイルから消しても変わらないので、wrangler workflows describe で確認する
何がjurisdictionの外に置かれるか ドキュメントによると、Workflowの設定(settings)は外に保存され、呼び出し側のWorkerの場所は制限されない(今回は確かめていない)

まとめ

  • ドキュメントによると、Cloudflare Workflowsの設定に jurisdiction: "eu" を書くと、インスタンスの実行とデータの保存がEU内に限定されます(実行場所は外から確かめていません)。2026年11月3日時点では、Freeプランのアカウントでもデプロイとインスタンスの実行ができました
  • 実際のjurisdictionは、設定ファイルではなく wrangler workflows describe で確認します
  • jurisdictionは作成時に決まります。別の値に書き換えると、wrangler deploy と wrangler versions upload はアップロード前にエラーで止まります。設定から消してもエラーにはならず、describe では作成時のjurisdictionのままでした
  • Wrangler 4.151.3では jurisdiction が警告付きで無視され、jurisdictionなしのWorkflowが作られました。jurisdictionを書く前に、Wranglerを4.152.0以上にしておく必要があります
  • jurisdictionを変えるには、wrangler workflows delete で削除して作り直します。削除するとインスタンスも消えます
  • script_name で参照する側に書くと、スクリプトのアップロード後にデプロイが失敗します。jurisdictionは定義側のWorkerにだけ書きます
  • wrangler dev ではjurisdictionは使われないので、作成後に変えられない制約はCloudflare上で確かめます

誰かの参考になれば幸いです。

参考リンク

この記事をシェアする

関連記事