Compatibility flags

Compatibility flags は特定の機能を有効にします。デフォルトではまだ有効でない今後の変更を Workers チームのテストに協力したいときや、コードが依存する変更だけを据え置きつつ、ほかの互換性変更は適用したいときに使えます。

Compatibility flags には、デフォルトで有効になる日付が付いていることがよくあります。Worker に compatibility_date を指定すると、その日付までの各種 Compatibility flags をまとめて有効にできます。

compatibility_flags の一覧を指定し、特定の変更を有効または無効にできます。

Compatibility flags は、Worker の Wrangler 設定ファイル で設定できます。

次の例は、後述 の formdata_parser_supports_files フラグを有効にします。指定日 2021-09-14 時点では、このフラグはまだデフォルトで有効ではありません。compatibility_flags に指定すると、それでも有効にできます。compatibility_flags は、過去にデフォルトになった変更を無効にするときにも使えます。

{
	// Opt into backwards-incompatible changes through September 14, 2021.
	"compatibility_date": "2021-09-14",
	// Also opt into an upcoming fix to the FormData API.
	"compatibility_flags": [
		"formdata_parser_supports_files"
	]
}

compatibility_date = "2021-09-14"
compatibility_flags = [ "formdata_parser_supports_files" ]

Compatibility flags は、Cloudflare ダッシュボード ↗ の Workers 設定で更新できます。

Compatibility flags は、Worker のアップロード時に Workers Script API または Workers Versions API のリクエスト本文 metadata フィールドで設定できます。

Runtime APIs として、増え続けている一部 の Node.js API を直接使えます。自分のコードにポリフィルを足す必要はありません。

互換性日付が 2026-08-04 以降の場合、Workers と Pages プロジェクトでは nodejs_compat と nodejs_compat_v2 がデフォルトで有効になります。組み込みのランタイム API とポリフィルは、追加の設定なしで使えます。これらの互換性日付では、これらのフラグは使われません。既存プロジェクトは、互換性日付を更新するときにフラグを削除する必要はありません。

互換性日付が 2026-08-04 より前の場合は、オプトインするために Wrangler 設定ファイル に nodejs_compat 互換性フラグ を追加します。

{
	"compatibility_flags": [
		"nodejs_compat"
	]
}

compatibility_flags = [ "nodejs_compat" ]

互換性日付が 2026-08-04 以降で Node.js 互換 を完全にオフにするには、有効化フラグがあれば削除します。次に no_nodejs_compat と no_nodejs_compat_v2 の両方を追加します。設定例は Node.js 互換性フラグ を参照してください。

互換日が 2026-08-04 以降の Worker では、nodejs_compat と nodejs_compat_v2 の両方がデフォルトで有効です。これらの互換日では、互換日が同じ挙動を有効にするため、フラグは使いません。Wrangler、Miniflare、Cloudflare Vite プラグイン、Workers Vitest プラグインは、ランタイム起動時にこの冗長なフラグを無視します。既存プロジェクトは、互換日を更新するときにフラグを削除する必要はありません。新しい設定では省略してください。

互換日 2026-08-04 以降で Node.js 互換を完全にオフにするには、あれば nodejs_compat と nodejs_compat_v2 を削除し、次の両方のフラグを追加します。

{
	"compatibility_flags": [
		"no_nodejs_compat",
		"no_nodejs_compat_v2"
	]
}

compatibility_flags = [ "no_nodejs_compat", "no_nodejs_compat_v2" ]

Node.js の AsyncLocalStorage API は、Workers で特に便利な機能です。AsyncLocalStorage API だけを有効にするには、nodejs_als Compatibility flag を使います。

{
	"compatibility_flags": [
		"nodejs_als"
	]
}

compatibility_flags = [ "nodejs_als" ]

新しいフラグから順に並びます。

remove_nodejs_compat_eol_v24 が有効なとき、Node.js 24.x でサポート終了した API は削除されます。

このフラグは、2028-04-30 以降に remove_nodejs_compat_eol フラグが有効なとき自動で有効になります。

remove_nodejs_compat_eol_v22 が有効なとき、Node.js 22.x でサポート終了した API は削除されます。

このフラグは、2027-04-30 以降に remove_nodejs_compat_eol フラグが有効なとき自動で有効になります。

このフラグが設定されているとき、Python Workers は Python 3.14 を使います。通常はこのフラグを手動で有効にする必要はなく、Python のバージョンは互換性日付または Worker に基づいて選ばれます。

有効なとき、未対応の TLS オプション（例: checkServerIdentity）を tls.connect() または new TLSSocket() に渡すと、黙って無視せず ERR_OPTION_NOT_IMPLEMENTED を投げます。

python_process_pth_files フラグが設定されているとき、Python Workers は起動時に python_modules/ ディレクトリの .pth ファイルを site.addsitedir() ↗ で処理します。パッケージは sys.path を宣言的に拡張でき、サブディレクトリの追加や import フックの登録などができます。このフラグがない場合、python_modules/ 内の .pth ファイルは無視されます。

このフラグは、一部のパッケージが必要とするトップレベルの entropy コンテキストマネージャーをランタイムから workers-py ↗ へ移します。

このフラグを設定する場合は、workers-py バージョン 1.1.3 以降を使ってください。

diagnostics_channel_has_subscribers_getter が有効なとき、node:diagnostics_channel の Channel.hasSubscribers と TracingChannel.hasSubscribers は、boolean を直接評価する読み取り専用 getter プロパティになり、Node.js の動きに揃います。

以前は hasSubscribers はメソッドとして登録されており、ch.hasSubscribers() のように括弧付きで呼ぶ必要がありました。このフラグが有効なとき、ch.hasSubscribers は関数呼び出しなしで boolean を返し、Node.js のドキュメント ↗ と揃います。

このフラグには nodejs_compat が必要です。

有効なとき、Workflow のステップが NonRetryableError を投げると、投げられた例外の message と name プロパティは汎用の終了文字列に置き換わらず保持されます。

以前は、カスタムメッセージ付きの NonRetryableError を投げると、元のエラーメッセージは失われ、"The execution of the Workflow instance was terminated, as a step threw an NonRetryableError and it was not handled" に置き換わっていました。

import { WorkflowEntrypoint, NonRetryableError } from "cloudflare:workers";

export class MyWorkflow extends WorkflowEntrypoint {
  async run(event, step) {
    await step.do("my-step", async () => {
      throw new NonRetryableError("custom error message");
      // Without this flag: error.message === "The execution of the Workflow instance was terminated, as a step threw an NonRetryableError and it was not handled"
      // With this flag: error.message === "custom error message"
    });
  }
}

workflows_preserve_non_retryable_error_message フラグが有効なときは、元のエラーメッセージと名前が残るため、Workflow コードでのデバッグと特定のエラー処理がしやすくなります。

enhanced_error_serialization が有効なとき、structuredClone() または V8 直列化で直列化するエラーは、より多くのエラー型に対応し、エラーオブジェクトの独自プロパティも含みます。

有効なとき、エラーの復元ではデフォルトで元のスタックトレースは保持されない点に注意してください。

以前は基本的な Error 型だけが直列化され、エラーオブジェクトに付けた独自プロパティは直列化で失われていました。

containers_pid_namespace が設定されているとき、コンテナは隔離された PID 名前空間を使います。コンテナの ENTRYPOINT は PID 1 になります。

未設定のとき、コンテナはコンテナを含む仮想マシン（VM）と PID 名前空間を共有します。コンテナの ENTRYPOINT は PID 1 にならず、VM 上で動いている（コンテナの一部ではない）ほかのプロセスも見えます。

encoder_stream_spec_compliant_backpressure が有効なとき、TextEncoderStream と TextDecoderStream は WHATWG Encoding Standard ↗ どおり、readable 側の high water mark を 0 にします。

high water mark が 0 だと、readable 側は最初からバックプレッシャーがかかっており、リーダーが pull するまで書き込みは正しくブロックします。以前の high water mark のデフォルトは 1 で、起動時に pull() が走り、書き込みの前にバックプレッシャーが解除されていました。

writable_stream_spec_compliant_writer が有効なとき、writer のロックと解放まわりのいくつかの WritableStream 仕様準拠の問題が直り、WHATWG Streams Standard ↗ に揃います。

enable_global_performance_classes が有効なとき、グローバルスコープで次のクラスが使えます。PerformanceEntry、PerformanceMark、PerformanceMeasure、PerformanceResourceTiming、PerformanceObserver、PerformanceObserverEntryList。

これらのクラスは enable_nodejs_perf_hooks_module フラグでも暗黙的に有効になります。

nodejs_compat が有効なとき、互換性日付が 2026-03-17 以降の Workers ではこのフラグが自動で有効になります。

enable_nodejs_child_process_module フラグは、Workers で node:child_process モジュールのスタブを使えるようにします。

nodejs_compat が有効なとき、互換性日付が 2026-03-17 以降の Workers ではこのフラグが自動で有効になります。

node:child_process API の詳細は Node.js のドキュメント ↗ を参照してください。

enable_nodejs_perf_hooks_module フラグは、Workers で node:perf_hooks モジュールを使えるようにします。このフラグはグローバルな Performance クラス（PerformanceEntry、PerformanceMark、PerformanceMeasure、PerformanceResourceTiming、PerformanceObserver、PerformanceObserverEntryList）も暗黙的に有効にします。

nodejs_compat が有効なとき、互換性日付が 2026-03-17 以降の Workers ではこのフラグが自動で有効になります。

node:perf_hooks API の詳細は Node.js のドキュメント ↗ を参照してください。

enable_nodejs_readline_module フラグは、Workers で node:readline モジュールのスタブを使えるようにします。

nodejs_compat が有効なとき、互換性日付が 2026-03-17 以降の Workers ではこのフラグが自動で有効になります。

node:readline API の詳細は Node.js のドキュメント ↗ を参照してください。

enable_nodejs_repl_module フラグは、Workers で node:repl モジュールのスタブを使えるようにします。

nodejs_compat が有効なとき、互換性日付が 2026-03-17 以降の Workers ではこのフラグが自動で有効になります。

node:repl API の詳細は Node.js のドキュメント ↗ を参照してください。

enable_nodejs_tty_module フラグは、Workers で node:tty モジュールのスタブを使えるようにします。

nodejs_compat が有効なとき、互換性日付が 2026-03-17 以降の Workers ではこのフラグが自動で有効になります。

node:tty API の詳細は Node.js のドキュメント ↗ を参照してください。

enable_nodejs_v8_module フラグは、Workers で node:v8 モジュールのスタブを使えるようにします。

nodejs_compat が有効なとき、互換性日付が 2026-03-17 以降の Workers ではこのフラグが自動で有効になります。

node:v8 API の詳細は Node.js のドキュメント ↗ を参照してください。

enable_nodejs_worker_threads_module フラグは、Workers で node:worker_threads モジュールのスタブを使えるようにします。

nodejs_compat が有効なとき、互換性日付が 2026-03-17 以降の Workers ではこのフラグが自動で有効になります。

node:worker_threads API の詳細は Node.js のドキュメント ↗ を参照してください。

このフラグは WebSocket の binaryType プロパティのデフォルト値を制御し、バイナリフレームが message イベントへどう届くかを決めます。フラグが有効なとき、binaryType のデフォルトは "blob" で、バイナリフレームは Blob ↗ として届きます。WebSocket 仕様 ↗ と標準のブラウザー動作に揃えます。フラグがないときは、binaryType のデフォルトは "arraybuffer" で、バイナリフレームは ArrayBuffer ↗ として届きます。これはランタイムの従来の動きです。

binaryType プロパティ自体は、フラグに関係なくすべての WebSocket で使えます。値を代入すると、その WebSocket のデフォルトを上書きします。

const resp = await fetch("https://example.com", {
  headers: { Upgrade: "websocket" },
});
const ws = resp.webSocket;

// Opt back into ArrayBuffer delivery before calling accept().
ws.binaryType = "arraybuffer";
ws.accept();

ws.addEventListener("message", (event) => {
  // event.data is an ArrayBuffer for binary frames.
});

移行の準備ができておらず、Worker 内のすべての WebSocket で ArrayBuffer をデフォルトのままにしたい場合は、Wrangler 設定ファイル に no_websocket_standard_binary_type フラグを追加してください。

このフラグは Durable Object のハイバネート可能な WebSocket webSocketMessage ハンドラーには影響しません。そちらはバイナリデータを常に ArrayBuffer として受け取ります。

queue_expose_error_codes が有効なとき、Queue 操作にはエラーコードや原因など詳細なエラー情報が含まれ、キュー関連のエラーをプログラムから扱い・診断しやすくなります。

サーバーが WebSocket Close フレームを送ると、Workers ランタイムは対応する Close フレームを自動で送り、close イベントを発火する前に readyState を CLOSED にします。これは WebSocket 仕様 ↗ とブラウザーの動きに揃えます。

以前は、サーバー起点の Close フレームを受け取っても WebSocket は CLOSING のままで、アプリケーション自身が close() を呼ぶ必要がありました。このフラグが有効なときは、close イベントハンドラー内で close() を呼ぶ必要はありません。クローズハンドシェイクはランタイムが自動で処理します。

const [client, server] = Object.values(new WebSocketPair());
server.accept();

server.addEventListener("close", (event) => {
  // readyState is already CLOSED — no need to call server.close().
  console.log(server.readyState); // WebSocket.CLOSED
  console.log(event.code); // 1000
  console.log(event.wasClean); // true
}, { once: true });

ハンドラー内で close() を呼んでも、その呼び出しは黙って無視されます。互換性日付を更新しても、Close フレームに手動応答している既存コードは壊れません。

自動クローズは WebSocket のプロキシと干渉することがあります。Worker がクライアントとバックエンドの間をプロキシする場合、以前の動きではバックエンドの Close フレームをランタイムが接続を切らずに観察でき、クライアント側のクリーンなクローズを Worker が調整する時間がありました。このパターン向けに、accept() はオプション allowHalfOpen を受け取ります。ws.accept({ allowHalfOpen: true }) を呼ぶと、互換性フラグに関係なく以前のハーフオープン動作に戻ります。

const [client, server] = Object.values(new WebSocketPair());

// Opt into half-open mode for proxying
server.accept({ allowHalfOpen: true });

server.addEventListener("close", (event) => {
  // With allowHalfOpen true, readyState is still CLOSING here,
  // giving you time to coordinate the close on the other side.
  console.log(server.readyState); // WebSocket.CLOSING

  // Manually close when ready.
  server.close(1000, "done");
}, { once: true });

WebSocket コンストラクターに対応するオプションはありません。new WebSocket で作った WebSocket は、このフラグの適用後は常に Close へ自動応答します。この方法で作った WebSocket は自動で「accept」されるため、accept() にオプションを渡す機会がありません。new WebSocket で作りつつハーフオープンが必要な場合は、代わりに fetch() を使ってください。

// This does not allow half-open:
let ws = new WebSocket("wss://example.com");

// But you can do this instead:
let resp = await fetch("https://example.com", {
  headers: { "Upgrade": "websocket" }
});
if (!resp.webSocket) {
  throw new Error("WebSocket handshake not accepted");
}
let ws = resp.webSocket;
ws.accept({ allowHalfOpen: true });

詳細は WebSocket API のドキュメント を参照してください。

text_decoder_cjk_decoder が有効なとき、CJK エンコーディングのオーバーライドと Big5 リードバイト処理には、従来の ICU 専用パスではなく専用の CJK TextDecoder 実装を使います。CJK テキストデコードの仕様準拠が上がります。

unhandled_rejection_after_microtask_checkpoint が有効なとき、unhandledrejection イベントの処理はマイクロタスクチェックポイントが終わるまで遅れます。後のマイクロタスクで rejection ハンドラーが付く複数ティックの Promise チェーンでの誤発火を避けます。

以前は、現在のチェックポイント内のすべてのマイクロタスクが処理される前に未処理 rejection の処理が走り、実際には処理されている Promise に対して誤った unhandledrejection イベントが出ることがありました。

websocket_close_reason_byte_limit が有効なとき、reason 文字列を UTF-8 エンコードしたサイズが 123 バイトを超えると、WebSocket.close() は SyntaxError の DOMException を投げます。WHATWG WebSocket 仕様 ↗ と RFC 6455 セクション 5.5 ↗ が求める動きです。

以前の Workers は、close reason の長さを検証せず任意に長くできました。

delete_all_deletes_alarm フラグが設定されているとき、Durable Object のストレージで deleteAll() を呼ぶと、保存済みデータに加えて有効なアラームも削除されます。以前は deleteAll() はユーザーが保存したデータだけを削除し、アラームの削除には別途 deleteAlarm() が必要でした。この変更は KV バックエンドと SQLite バックエンドの両方の Durable Objects に適用されます。

text_decoder_replace_surrogates が有効なとき、UTF-16le の TextDecoder は孤立サロゲートを U+FFFD（Unicode 置換文字）に置き換えます。Encoding Standard ↗ が求める動きです。以前は孤立サロゲートはそのまま通り、整形式でない文字列になっていました。

fetch_iterable_type_support が有効なとき、同期および非同期の iterable を fetch() の Request または Response のボディとして渡せ、正しく反復されます。

以前は Array のような同期 iterable は受け付けられても文字列化され（例: [1, 2, 3] は "1,2,3" になる）、非同期 iterable は通常のオブジェクトとして扱われ反復されませんでした。このフラグが有効なとき、iterable はストリーミングボディとして正しく消費されます。

Array は文字列化されず iterable として扱われるようになります。以前の動きに依存しているコードには破壊的変更です。

enable_nodejs_global_timers が有効なとき、setTimeout、setInterval、clearTimeout、clearInterval は refresh()、ref()、unref()、hasRef() などのメソッドを持つ Node.js 互換の Timeout オブジェクトを返し、node:timers の動きに揃えます。

このフラグには nodejs_compat が必要です。nodejs_compat が有効なとき、互換性日付が 2026-02-10 以降の Workers ではこのフラグが自動で有効になります。

タイマー API の詳細は Node.js のドキュメント ↗ を参照してください。

enable_nodejs_dgram_module フラグは、Workers で node:dgram モジュールのスタブを使えるようにします。

nodejs_compat が有効なとき、互換性日付が 2026-01-29 以降の Workers ではこのフラグが自動で有効になります。

node:dgram API の詳細は Node.js のドキュメント ↗ を参照してください。

enable_nodejs_inspector_module フラグは、Workers で node:inspector モジュールのスタブを使えるようにします。

nodejs_compat が有効なとき、互換性日付が 2026-01-29 以降の Workers ではこのフラグが自動で有効になります。

node:inspector API の詳細は Node.js のドキュメント ↗ を参照してください。

enable_nodejs_sqlite_module フラグは、Workers で node:sqlite モジュールのスタブを使えるようにします。

nodejs_compat が有効なとき、互換性日付が 2026-01-29 以降の Workers ではこのフラグが自動で有効になります。

node:sqlite API の詳細は Node.js のドキュメント ↗ を参照してください。

enable_nodejs_stream_wrap_module フラグは、Workers で node:_stream_wrap モジュールのスタブを使えるようにします。

nodejs_compat が有効なとき、互換性日付が 2026-01-29 以降の Workers ではこのフラグが自動で有効になります。

require_returns_default_export が有効なとき、require() はモジュールにデフォルトエクスポートがあればそれを返します。なければモジュール名前空間オブジェクトの変更可能なコピーを返します。

これは Node.js の require(esm) の動きに揃えます。デフォルトエクスポートがあればそれを返します。モジュールエクスポートをパッチしたい Next.js などのフレームワークで役立ちます。

以前は require() は常にモジュール名前空間オブジェクト（{default: module.exports} のようなオブジェクト）を返していました。

RPC 呼び出しのパラメーターに埋め込まれた RPC スタブの所有権セマンティクスを変え、Cap'n Web ↗ との互換性の問題を直します。

Workers RPC システム の当初、別の呼び出しの params や戻り値に埋め込まれた RPC スタブは所有権が移っていました。つまり元のスタブは暗黙に dispose され、複製が宛先に届いていました。

これは別のルールと相性が悪いです。呼び出し側では、呼び出しの params で受け取ったスタブは、呼び出しが戻ると自動で dispose されます。この 2 つが重なると、呼び出しをプロキシする（RPC の実装が同じ params をそのまま別の RPC に渡す）場合、params 内のスタブが 2 回 dispose されます。さらに最終的な受け手が呼び出し終了後も複製を残したいとき、プロキシ層のスタブが anyway dispose されて接続が切れることがあります。

このため Cap'n Web の純粋 JS 実装は、params 内のスタブは所有権を移さず複製するだけ、という動きに切り替えました。この互換性フラグは、Workers ランタイム組み込み RPC を Cap'n Web の動きに揃えます。

よくある修正対象は、Cap'n Web 経由で Durable Object からのコールバックを購読するクライアントです。この場合、クライアントアプリは Cap'n Web WebSocket 経由でステートレス Worker にコールバック関数を渡し、その Worker が Workers RPC でスタブを Durable Object に転送します。Durable Object は後でクライアントへイベントを通知するため、スタブの dup() を保存します。このフラグの前は動きませんでした。subscribe 関数自身が戻ると、ステートレス Worker 内の Cap'n Web スタブが dispose されます（呼び出しのパラメーターであり、ステートレス Worker の文脈で dup() されていないため）。そのため Durable Object が後で購読コールバックを呼ぶと、自分の側では dup() しているにもかかわらず "Error: RPC stub used after being disposed" を受け取ります。

fetch_iterable_type_support_override_adjustment が有効なとき、fetch() の Request または Response のボディとして渡したオブジェクトが同期 iterable でも、カスタムの toString または Symbol.toPrimitive メソッドを持つ場合は iterable として扱いません。代わりに文字列化したオブジェクトとして扱い、そのようなオブジェクトの以前の動きに揃えます。

このフラグは fetch_iterable_type_support フラグで導入した動きを細かくし、2026-01-15 以降に fetch_iterable_type_support が有効なとき自動で有効になります。

strip_bom_in_read_all_text が有効なとき、ストリームの readAllText() メソッドは先頭の UTF-8 Byte Order Mark（BOM）があれば取り除き、Web プラットフォーム標準の想定どおりになります。

以前は BOM が戻り文字列に含まれ、テキスト内容の解析で想定外の動きになることがありました。

enable_nodejs_cluster_module フラグは、Workers で node:cluster モジュールのスタブを使えるようにします。

nodejs_compat が有効なとき、互換性日付が 2025-12-04 以降の Workers ではこのフラグが自動で有効になります。

node:cluster API の詳細は Node.js のドキュメント ↗ を参照してください。

enable_nodejs_domain_module フラグは、Workers で node:domain モジュールのスタブを使えるようにします。node:domain は Node.js 本体でも非推奨です。

nodejs_compat が有効なとき、互換性日付が 2025-12-04 以降の Workers ではこのフラグが自動で有効になります。

node:domain API の詳細は Node.js のドキュメント ↗ を参照してください。

enable_nodejs_punycode_module フラグは、Workers で node:punycode モジュールを使えるようにします。node:punycode は Node.js 本体でも非推奨です。

nodejs_compat が有効なとき、互換性日付が 2025-12-04 以降の Workers ではこのフラグが自動で有効になります。

node:punycode API の詳細は Node.js のドキュメント ↗ を参照してください。

enable_nodejs_trace_events_module フラグは、Workers で node:trace_events モジュールのスタブを使えるようにします。

nodejs_compat が有効なとき、互換性日付が 2025-12-04 以降の Workers ではこのフラグが自動で有効になります。

node:trace_events API の詳細は Node.js のドキュメント ↗ を参照してください。

enable_nodejs_wasi_module フラグは、Workers で node:wasi モジュールのスタブを使えるようにします。

nodejs_compat が有効なとき、互換性日付が 2025-12-04 以降の Workers ではこのフラグが自動で有効になります。

node:wasi API の詳細は Node.js のドキュメント ↗ を参照してください。

enable_fast_jsg_struct が有効なとき、Workers ランタイム API が使う内部 struct 型は、オブジェクト生成時間を減らすより効率的なパターンで作られます。

ただし任意フィールドはオブジェクトから省略されず、明示的に undefined が入ります。これは観測できる動きの変化です。"key" in obj や Object.hasOwn(obj, "key") でプロパティの有無を見ているコードは動きが変わることがあります。以前はなかった任意フィールドが、いまは undefined として存在するためです。

値の確認には "key" in obj より obj.key !== undefined を使ってください。

このフラグは ctx.exports API を有効にします。Worker のトップレベルエクスポート向けに、ループバックバインディングが自動で入ります。同じ Worker 内で定義した WorkerEntrypoint や Durable Object 名前空間に、明示的なバインディングを書かずに済みます。

Wrangler 設定ファイルに次の設定がある場合、このフラグは Workers Tracing をデフォルトで有効にします。

{
	"observability": {
		"enabled": true
	}
}

フラグなし、より古い互換性日付でも、次の設定で自動トレーシングを明示的に有効にできます。

{
	"observability": {
		"traces": {
			"enabled": true
		}
	}
}

enable_nodejs_vm_module フラグは、Workers で node:vm モジュールのスタブを使えるようにします。

nodejs_compat が有効なとき、互換性日付が 2025-10-01 以降の Workers ではこのフラグが自動で有効になります。

node:vm API の詳細は Node.js のドキュメント ↗ を参照してください。

enable_nodejs_console_module フラグは、Workers で node:console モジュールを使えるようにします。

nodejs_compat が有効なとき、互換性日付が 2025-09-21 以降の Workers ではこのフラグが自動で有効になります。

node:console API の詳細は Node.js のドキュメント ↗ を参照してください。

enable_validate_workflow_entrypoint が有効なとき、Workflows が正しく定義・利用されているかを追加で検証します。設定ミスをランタイムではなくアップロード時に見つけやすくします。

enable_nodejs_fs_module フラグは、Workers で node:fs モジュールを使えるようにします。

nodejs_compat が有効なとき、互換性日付が 2025-09-15 以降の Workers ではこのフラグが自動で有効になります。

node:fs API の詳細は Node.js のドキュメント ↗ を参照してください。

enable_nodejs_os_module フラグは、Workers で node:os モジュールを使えるようにします。

nodejs_compat が有効なとき、互換性日付が 2025-09-15 以降の Workers ではこのフラグが自動で有効になります。

node:os API の詳細は Node.js のドキュメント ↗ を参照してください。

2025-09-15 以降に有効にすると、enable_nodejs_process_v2 フラグは nodejs_compat 互換性フラグとあわせて、Node.js 互換の包括的な process 実装になります。以前の最小実装は nextTick、env、exit、getBuiltinModule、platform、features だけを提供していました。

互換性日付のあとも以前の最小実装を使い続ける場合は、代わりに disable_nodejs_process_v2 フラグを設定します。

Node.js が対応する process プロパティは可能な範囲で実装し、未対応の機能は undefined のエクスポートになります。Workers 固有の実装の詳細は process のドキュメント を参照してください。

enable_nodejs_http_server_modules フラグは、Workers で node:_http_server などの Node.js HTTP サーバーモジュールを使えるようにします。

disable_nodejs_http_server_modules フラグは、これらのサーバーモジュールを使えなくします。

標準の Node.js HTTP サーバー API を使う Node.js ライブラリや既存コードとの互換性が上がります。使える機能には次が含まれます。

• HTTP サーバーを作る http.createServer()
• サーバーインスタンス向けの http.Server クラス
• サーバーレスポンスを扱う http.ServerResponse

node:http の機能を一通り使うには、このフラグを enable_nodejs_http_modules フラグと組み合わせる必要があります。

nodejs_compat が有効なとき、互換性日付が 2025-09-01 以降の Workers ではこのフラグが自動で有効になります。

Node.js HTTP API の詳細は Node.js のドキュメント ↗ を参照してください。

enable_nodejs_http2_module フラグは、Workers で node:http2 モジュールのスタブを使えるようにします。

nodejs_compat が有効なとき、互換性日付が 2025-09-01 以降の Workers ではこのフラグが自動で有効になります。

node:http2 API の詳細は Node.js のドキュメント ↗ を参照してください。

remove_nodejs_compat_eol が有効なとき、Node.js でサポート終了（End-of-Life）になった API は Workers から削除されます。無効なときは API は残りますが、動作しないスタブのことがあります。

このフラグはまとめフラグです。特定の Node.js バージョンで追加の API が EOL になると、バージョン固有の互換性フラグ（remove_nodejs_compat_eol_v22、remove_nodejs_compat_eol_v23、remove_nodejs_compat_eol_v24 など）が追加され、それぞれの日付以降はこのフラグがそれらを含意します。

nodejs_compat が有効なとき、互換性日付が 2025-09-01 以降の Workers ではこのフラグが自動で有効になります。

remove_nodejs_compat_eol_v23 が有効なとき、Node.js 23.x でサポート終了した API（EOL は 2025 年 6 月）は削除されます。

このフラグは、2025-09-01 以降に remove_nodejs_compat_eol_v24 フラグが有効なとき自動で有効になります。

strip_authorization_on_cross_origin_redirect が有効なとき、別オリジンへのリダイレクトに従うと Authorization ヘッダーは自動で取り除かれます。これは現行の Fetch API 仕様 ↗ が求める動きです。

この要件は 2022 年に Fetch 仕様へ追加され、Cloudflare Workers が当初 fetch 処理を実装したあとのことです。Workers は当初この要件を実装していなかったため、新しい動きは互換性フラグの後ろに置いています。

以前の動きは本質的に安全ではないわけではなく、状況によっては望ましいこともあります。たとえば認可が必要な API が、クライアントに資格情報を付けたまま新しいホスト名へリダイレクトしたい場合です。新しい動きでは、そのようなリダイレクトに資格情報は自動では付きません。一方、以前の動きでは信頼できないオリジンへのリダイレクトで意図せず資格情報が漏れることがありました。

以前の動きを残すには、retain_authorization_on_cross_origin_redirect フラグを設定します。

enable_nodejs_http_modules フラグは、Workers で Node.js の node:http と node:https モジュール（クライアント API のみ）を使えるようにします。

disable_nodejs_http_modules フラグは、これらのモジュールを使えなくします。

標準の node:http / node:https API で HTTP リクエストを行う Node.js ライブラリや既存コードとの互換性が上がります。使える機能には次が含まれます。

• HTTP/HTTPS リクエストを出す http.request() と https.request()
• GET リクエストを出す http.get() と https.get()
• 標準の Node.js API を持つリクエスト / レスポンスオブジェクト
• 標準の HTTP メソッド、ヘッダー、オプションのサポート

Node.js API の詳細は Node.js のドキュメント ↗ を参照してください。

expose_global_message_channel フラグが設定されているとき、Workers は MessageChannel と MessagePort のコンストラクターをグローバルに公開します。

no_expose_global_message_channel フラグが設定されているとき、Workers はこれらを公開しません。

python_no_global_handlers フラグが設定されているとき、Python Workers はグローバルハンドラーを無効にし、デフォルトのエントリポイントクラス経由での利用を強制します。

cache_no_cache_enabled 互換性フラグを有効にすると、Request インターフェイスの cache プロパティに no-cache を指定できます。この互換性フラグが無効、または cache_option_disabled が設定されている場合、Workers ランタイムは Unsupported cache mode: no-cache という TypeError を投げます。

このフラグが有効なとき、Worker から fetch() API で出すサブリクエストについて、Cloudflare のキャッシュにオリジンとの再検証を強制できます。

no-cache を指定した場合:

• すべてのリクエストにヘッダー Pragma: no-cache と Cache-Control: no-cache が付きます。

• Cloudflare がホストしていないオリジンへのサブリクエストでは、Cloudflare のキャッシュがオリジンと再検証します。

オリジンとの再検証とは、Worker のリクエストがまず Cloudflare のキャッシュで一致を探し、次のように動くことです。

• 一致がある場合、一致が fresh でも stale でも、オリジンへ条件付きリクエストを送ります。リソースが変わっていなければキャッシュ版を返します。変わっていればオリジンからダウンロードし、キャッシュを更新して返します。
• 一致がない場合、Workers はオリジンへ通常のリクエストを送り、レスポンスをキャッシュします。

cache: 'no-cache' の例:

const response = await fetch("https://example.com", { cache: "no-cache" });

cache の値は Request オブジェクトにも設定できます。

const request = new Request("https://example.com", { cache: "no-cache" });
const response = await fetch(request);

set_event_target_this フラグが設定されているとき、Workers はイベントハンドラーの this を、イベントがディスパッチされる EventTarget インスタンスに設定します。これは仕様に揃います。

no_set_event_target_this フラグが設定されているとき、Workers はイベントハンドラーの this を設定せず、undefined になります。

edgeworker へ送られるヘッダーの当初の版では、To や Cc など特定のヘッダー名は値が 1 つに切り詰められていました。set_forwardable_email_full_headers フラグが設定されているとき、Workers は Worker スクリプトへヘッダーの完全な値を受け取ります。

pedantic_wpt フラグは、Workers で Web Platform Tests（WPT）への厳密な準拠を有効にします。当初は Event と EventTarget API にだけ影響しますが、将来ほかの API にも広げます。このフラグにデフォルト有効日はありません。

AsyncLocalStorage のフレームは、現在のリクエストコンテキストに結びついた値をキャプチャできます。これは常にユーザーの制御下にあるわけではありません。ALS ストレージフレームは内部のトレーススパンと、ユーザーが渡した値の両方の伝播に使うためです。bind_asynclocalstorage_snapshot_to_request フラグが設定されているとき、ランタイムはスナップショット / バインドした関数を現在のリクエストコンテキストに結びつけます。作られたリクエストの外でバインドした関数を呼ぶとエラーになります。

do_not_bind_asynclocalstorage_snapshot_to フラグはこの動きを無効にします。

throw_on_unrecognized_import_assertion フラグは、ランタイムが認識しない import 属性を Workers がどう扱うかを制御します。以前の Workers はすべての import 属性を無視しており、仕様に揃っていません。ランタイムは、認識できない import 属性に出会うとエラーを投げることが想定されています。

ignore_unrecognized_import_assertion フラグが設定されているとき、Workers は認識できない import 属性を無視します。

allow_eval_during_startup フラグが設定されているとき、Worker スクリプトの起動フェーズで eval() と new Function(text) を使えます。Worker ライフサイクルの最初で動的なコード実行ができます。

disallow_eval_during_startup フラグが設定されているとき、起動フェーズで eval() や new Function(text) を使うとエラーになります。

enable_request_signal 互換性フラグを使うと、Request オブジェクトに signal プロパティ ↗ 経由でイベントリスナーを付けられます。クライアントが Worker へのリクエストをキャンセルしたときに処理を実行できます。

cache_api_request_cf_overrides_cache_rules が有効なとき、Cache API に渡したリクエストの cf オブジェクトで指定したキャッシュ設定は Cache Rules を上書きします。これはユーザー所有またはグレークラウドのサイトにだけ適用されます。

これは fetch() API 向けの request_cf_overrides_cache_rules フラグの Cache API 版です。

enable_navigator_language フラグが設定されているとき、Workers で navigator.language プロパティが使えます。現時点では、navigator.language の値は常に en です。

disable_navigator_language フラグが設定されているとき、navigator.language プロパティは使えません。

disallow_importable_env フラグが有効なとき、Workers は cloudflare:workers モジュール経由での環境変数のインポートを許可せず、Node.js 互換が有効でもグローバルな process.env オブジェクトに環境変数を投入しません。

このフラグにデフォルト有効日はありません。

FinalizationRegistry ↗ と WeakRef ↗ の組み込みを使えるようにします。

• FinalizationRegistry は、オブジェクトがガベージコレクションされたあとに走るクリーンアップコールバックを登録できます。
• WeakRef はオブジェクトへの弱い参照を作り、他に強い参照がなければガベージコレクションできるようにします。

:::note[動作] FinalizationRegistry のクリーンアップコールバックは、リクエストライフサイクル中の任意の時点で実行されることがあり、呼び出されたハンドラーが終わったあとも走ります（ctx.waitUntil() に似ています）。これらのコールバックに関連する非同期コンテキストはありません。I/O はできず、tail Worker へのイベント送信もできません。 :::

:::caution これらの API は本質的に非決定的です。ガベージコレクションのタイミングと実行は予測できず、必須のプログラムロジックに頼らないでください。また、FinalizationRegistry に登録したクリーンアップコールバックは、ガベージコレクションが起きない場合や Worker が退避される場合など、実行されないことがあります。 :::

request_signal_passthrough フラグが設定されているとき、受信リクエストの AbortSignal は、fetch() API でサブリクエストへ転送する際にそのまま渡されます。

no_request_signal_passthrough フラグが設定されているとき、受信リクエストの AbortSignal は渡されません。

当初の URLPattern 実装は WHATWG URLPattern Standard ↗ に完全には揃っておらず、ユーザーから複数の問題が報告されていました。

urlpattern_standard が有効なとき、Workers は仕様準拠の URLPattern 実装を使います。当初の動きからの破壊的変更のため、互換性フラグの後ろに置いています。

URLPattern を使っていて、互換性日付を更新したあとに想定外の動きが出た場合は、urlpattern_original を設定すると以前の実装に戻せます。

静的アセット 付きの Worker でこの互換性フラグが有効なとき、ナビゲーションリクエスト（Sec-Fetch-Mode: navigate ヘッダーがあるリクエスト）は、完全一致するアセットが見つからなくてもアセット配信ロジックで返すことを優先します。シングルページアプリケーション（SPA）モード や カスタム 404 ページ を使うアプリで特に便利です。フォールバックページの 200 /index.html と 404 /404.html が Worker スクリプトの実行より先に返され、課金を避けられるようになります。

このフラグがない場合、ランタイムは従来どおり、静的アセットに完全一致しないリクエストでは（あれば）Worker スクリプトを実行します。

assets.run_worker_first = true が設定されている場合、この互換性フラグは効果がありません。assets.run_worker_first = true は、アセット配信ロジックより先に Worker スクリプトを実行します。

nodejs_compat_populate_process_env 互換性フラグを有効にし、あわせて nodejs_compat フラグも有効なとき、process.env にはテキストまたは JSON 値を持つバインディングの値が入ります。つまり 環境変数、secrets、version metadata のバインディングを追加していれば、それらの値を process.env から読めます。

const apiClient = ApiClient.new({ apiKey: process.env.API_KEY });
const LOG_LEVEL = process.env.LOG_LEVEL || "info";

これらの値へのアクセスが簡単になり、よくある Node.js のパターンにも揃うため、手間が減り、既存の Node.js ライブラリとの互換性にも役立ちます。

process.env 経由でこれらの値を見せたくない場合は、nodejs_compat_do_not_populate_process_env フラグを使えます。この場合も process.env 自体は使えますが、値は自動では入りません。

disallow_importable_env 互換性フラグが設定されている場合も、process.env には値が入りません。

デフォルトでは、Queues の Consumer Worker は ctx.waitUntil() に渡した Promise が解決してからメッセージを acknowledge します。この動きのため、ctx.waitUntil() を使う Queue コンシューマーはメッセージ処理が遅くなることがあります。デフォルトの動きは Queues Consumer Configuration Guide に記載しています。

次の Consumer Worker は ctx.waitUntil() を使う例です。デフォルトでは、このコンシューマーは sleep 関数が解決してからメッセージバッチを acknowledge します。

export default {
  async fetch(request, env, ctx) {
    // omitted
  },

  async queue(batch, env, ctx) {
    console.log(`received batch of ${batch.messages.length} messages to queue ${batch.queue}`);
    for (let i = 0; i < batch.messages.length; ++i) {
      console.log(`message #${i}: ${JSON.stringify(batch.messages[i])}`);
    }
    ctx.waitUntil(sleep(30 * 1000));
  }
};

function sleep(ms) {
  return new Promise(resolve => setTimeout(resolve, ms));
}

queue_consumer_no_wait_for_wait_until フラグを有効にすると、Queues コンシューマーは ctx.waitUntil() に渡した Promise の解決を待たずにメッセージを acknowledge します。ctx.waitUntil() を使うコンシューマーの性能を上げられます。フラグが有効な上記の例では、sleep 関数の解決を待たずにバッチを acknowledge します。

このフラグを使っても ctx.waitUntil() の動きは変わりません。ctx.waitUntil() は、メッセージバッチを acknowledge したあとも作業を続けられるよう、Consumer Worker の生存期間を延長します。

当初の TransformStream 実装には、最初の書き込みのあとバックプレッシャー通知が失敗するバグがありました。残念ながら修正すると、そのバグに対処していた既存コードが失敗することがあります。そのため修正を有効にする fixup-transform-stream-backpressure 互換性フラグがあります。

互換性日付が 2024-12-16 以降では、この修正はデフォルトで有効です。

元のバックプレッシャーロジックに戻すには、original-transform-stream-backpressure フラグで修正を無効にします。

Workers は Node.js スタイルの require(...) で Worker バンドル内のモジュールをインポートできます。これまでこの仕組みでは、require したモジュールがトップレベル await を使えました。これは Node.js 互換ではありません。

disable_top_level_await_in_require 互換性フラグがあると、モジュールがトップレベル await を使う場合に require() は失敗します。互換性日付が 2024-12-02 以降ではこのフラグがデフォルトで有効です。

トップレベル await を許可する元の動きに戻すには、enable_top_level_await_in_require 互換性フラグを使います。

cache_option_enabled 互換性フラグを有効にすると、Request インターフェイスの cache プロパティに値を指定できます。この互換性フラグが無効、または cache_option_disabled が設定されている場合、Workers ランタイムは The 'cache' field on 'RequestInitializerDict' is not implemented. という Error を投げます。

このフラグが有効なとき、Worker から fetch() API で出すサブリクエストのレスポンスを、Cloudflare にキャッシュしないよう指示できます。

cache_option_enabled で有効になるキャッシュオプションは 'no-store' だけです。それ以外の値を指定すると、Workers ランタイムは Unsupported cache mode: <the-mode-you-specified> というメッセージの TypeError を投げます。

no-store を指定した場合:

• すべてのリクエストにヘッダー Pragma: no-cache と Cache-Control: no-cache が付きます。

• Cloudflare がホストしていないオリジンへのサブリクエストは、Cloudflare のキャッシュをバイパスします。

cache: 'no-store' の例:

const response = await fetch("https://example.com", { cache: "no-store" });

cache の値は Request オブジェクトにも設定できます。

const request = new Request("https://example.com", { cache: "no-store" });
const response = await fetch(request);

global_fetch_strictly_public 互換性フラグが有効なとき、グローバルな fetch() 関数 は、リクエストがパブリックインターネット上で行われたかのように厳密にルーティングします。

つまり Worker 自身のゾーンへのリクエストは Cloudflare の「フロントドア」にループバックし、インターネットからのリクエストと同様に扱われます。同じ Worker へ再びループバックすることもあります。

global_fetch_strictly_public が無効なとき、そのようなリクエストはゾーンのオリジンサーバーへ送られ、URL に割り当てられた Workers は無視され、Cloudflare のセキュリティ設定もバイパスします。

これまで、誤ったリクエストコンテキストから Promise を解決でき、継続が間違ったコンテキストでスケジュールされ、エラーや診断しにくいバグにつながることがありました。

handle_cross_request_promise_resolution が有効なとき、正しいリクエストコンテキストが生きていればそこに継続をスケジュールし、すでに終わっていれば警告を出して破棄します。

HTTP メソッドは大文字であることが想定されます。fetch 仕様では、メソッドが get、post、put、delete、head、options の場合、実装はメソッドを大文字にします。それ以外のメソッド名は、一般に未認識としてエラーになります（たとえば patch はエラーで、PATCH は受け付けます）。仕様どおりではありますが、やや厳しい動きです。このフラグは、解析前にすべてのメソッドを大文字に変え、既知のメソッドなら常に認識されるようにします。

標準の動きに戻すには、no_upper_case_all_http_methods 互換性フラグを使います。

仕様準拠の複数のバグを直すため、すべての Workers API オブジェクトに Symbol.toStringTag を設定する変更を入れました。残念ながら、想定より破壊的でした。do_not_set_tostring_tag 互換性フラグは、互換性日付が 2024-09-26 以前の元の動きに戻します。

nodejs_zlib フラグは、Workers で node:zlib モジュールを使えるようにします。

nodejs_compat が有効なとき、互換性日付が 2024-09-23 以降の Workers ではこのフラグが自動で有効になります。

node:zlib API の詳細は Node.js のドキュメント ↗ を参照してください。

このフラグが有効なとき、fetch() API でサブリクエストを出す際にポートを指定すると、そのポート番号が使われます。

Cloudflare を使うサイト（「オレンジクラウド」）へのサブリクエストでは、Cloudflare のリバースプロキシが対応するポート だけを指定できます。未対応のポートを指定しようとすると無視されます。

Cloudflare を使わないサイト（「グレークラウド」）へのサブリクエストでは、任意のポートを指定できます。

例:

const response = await fetch("https://example.com:8000");

allow_custom_ports がある場合、上記の例は https://example.com:443 ではなく https://example.com:8000 を fetch します。

new WebSocket(url) で WebSocket クライアントを作る場合も、このフラグに従います。

当初の WritableStream 実装（「internal」ストリーム）では、abort() 操作は遅延して扱われ、保留中の書き込みキューは次にキューが処理されるまで空になりませんでした。コンシューマーが消費を止めるとストリームがハングすることがありました。

internal_writable_stream_abort_clears_queue が有効なとき、キューは abort() ですぐ空になり、コンシューマーが書き込み処理を止めた場合のハングを防ぎます。

response.blob.type() を呼ぶと、WHATWG 仕様 ↗ どおり、MIME タイプは content-type ヘッダーから正しく取り出されます。

fetch_standard_url フラグは、fetch() が WHATWG URL Standard ↗ の解析ルールを使うようにします。当初の実装は、URL の前に空白がある場合など、標準解析ではエラーにならない URL でも TypeError: Fetch API cannot load を投げていました。不正な URL で new Request() を呼ぶと、URL エラーはすぐに投げられます。以前は fetch() が呼ばれた時点で初めて URL エラーが投げられていました。

BYOB（Bring your own buffer）ReadableStream の当初の実装では、ストリームが閉じて読み取るデータがなくなると read() メソッドは undefined を返していました。これは標準の ReadableStream の動きと揃っていません。標準ではストリームが閉じると空の Uint8Array を返します。

internal_stream_byob_return_view フラグを使うと、BYOB の read() は標準の動きになります。

const resp = await fetch('https://example.org');
const reader = resp.body.getReader({ mode: 'byob' });
await result = await reader.read(new Uint8Array(10));

if (result.done) {
  // The result gives us an empty Uint8Array...
  console.log(result.value.byteLength); // 0

  // However, it is backed by the same underlying memory that was passed
  // into the read call.
  console.log(result.value.buffer.byteLength); // 10
}

brotli_content_encoding 互換性フラグが有効なとき、Workers は br コンテンツエンコーディングに対応し、Brotli ↗ 圧縮アルゴリズムでエンコードしたデータをリクエスト・応答できます。取得するデータ量を減らせ、元の圧縮データをクライアントへそのまま渡せます。詳細は Fetch API の ドキュメント を参照してください。

このフラグが有効なとき、Durable Object スタブと Service Bindings は RPC に対応します。これらのオブジェクトは、あらゆるメソッド名を定義しているように見えます。任意のメソッド名を呼ぶと、リモートの Durable Object または Worker サービスへ RPC が送られます。

ほとんどのアプリでは、使わなければ影響はありません。ただし、これらの型に以前はなかったメソッド名の有無を明示的に調べている既存コードは影響を受けることがあります。たとえば、バインディング を走査し、実装しているメソッドから型を自動判定するコードを実際に見ています。そのようなコードは、サービスバインディングがすべてのメソッドを実装していると見なし、別の型と誤認することがあります。これまでに見たケースでは影響は無害（実際には壊れなかった）でしたが、念のためこの変更はフラグで守っています。

unwrap_custom_thenables フラグを設定すると、Promise を受け取る各種 Workers API は、ネイティブの Promise ではないがそう扱う意図のあるカスタム thenable（then メソッドを持つオブジェクト）も正しく扱います。たとえば ExecutionContext オブジェクトの waitUntil メソッドはカスタム thenable を正しく扱い、ネイティブ Promise の代わりに使えます。

async fetch(req, env, ctx) {
  ctx.waitUntil({ then(res) {
    // Resolve the thenable after 1 second
    setTimeout(res, 1000);
  } });
  // ...
}

Durable Object スタブと Service Bindings はどちらも、グローバルな fetch() に似た fetch() メソッドを実装します。ただしリクエストは URL に基づいてルーティングされず、オブジェクトが表す宛先へ送られます。

これまで、そのような fetch() メソッドを持つ API オブジェクトには get()、put()、delete() もありました。これらは対応する HTTP メソッドを実行し、必要に応じてリクエスト / レスポンスボディの読み書きを自動で行う、fetch() の薄いラッパーでした。

これらのメソッドは何年も前のごく初期のアイデアで、実際にはドキュメント化されず、ほとんど（あるいは一度も）使われていません。fetcher_no_get_put_delete を有効にするか、互換性日付を 2024-03-26 以降にすると、Worker ではこれらのメソッドが無効になります。

この変更は、将来これらの名前で独自のカスタムメソッドを定義できるようにします。変更がなければ、組み込みヘルパーと衝突するため、独自の get、put、delete メソッドは定義できません。

queues_json_messages フラグが設定されているとき、Queue バインディングは send() または sendBatch() に渡した値を、特定の contentType がない場合はデフォルトで JSON 形式に直列化します。

グローバルな importScripts() 関数を抑制します。このメソッドは Workers のグローバルスコープに含まれていましたが、未実装と明示されていました。ただし関数があるだけで一部のライブラリで問題になることがありました。この互換性フラグは、グローバルスコープから関数を取り除きます。

Workers で Node.js の AsyncLocalStorage ↗ API を使えるようにします。

このフラグは Python のファーストクラスサポートを有効にします。Python Workers は Python の 標準ライブラリ の大半を実装し、すべての バインディング、環境変数、secrets に対応し、外部関数インターフェイス 経由で JavaScript のオブジェクトや関数と連携できます。

WebCrypto API では、RSA 鍵のアルゴリズムの publicExponent フィールドは以前 ArrayBuffer でした。このフラグを使うと、仕様どおり publicExponent は Uint8Array になります。

vectorize_query_metadata_optional が設定されていると、Vectorize のクエリ操作は、古い引数 returnVectors ではなく、returnValues と returnMetadata を個別に指定する新しい引数を受け付けます。戻り形式も変わります。ベクトル値の返却が指定されている場合、以前は入れ子のベクトルオブジェクトだった戻り値は、score が付いた平坦なベクトルオブジェクトになります。

当初の WebSocket 実装が公開されたとき、Workers ランタイムは WebSocket 圧縮に対応していませんでした。これまでランタイムは Sec-WebSocket-Extensions ヘッダーを取り除くか無視していましたが、いまは WebSocket Compression RFC に完全に揃えられます。いまも多くのクライアントが Workers へ Sec-WebSocket-Extensions: permessage-deflate を送っている可能性が高いため（ブラウザーでは new WebSocket(url) が自動で付けます）、このフラグがない場合は以前の動きを維持します。

フラグがある場合、Workers ランタイムはインバウンドとアウトバウンドの両方の WebSocket 接続で WebSocket 圧縮を使えます。

ブラウザーと同様、Worker 内で new WebSocket(url) を呼ぶと Sec-WebSocket-Extensions: permessage-deflate ヘッダーが自動で付きます。非標準の fetch() API で WebSocket を取得する場合は、値 permessage-deflate の Sec-WebSocket-Extensions ヘッダーを含め、RFC-7692 ↗ で定義された圧縮パラメーターを付けられます。

Web Crypto API で仕様に揃える追加のエラーチェックを行い、安全でない可能性のある鍵パラメーターを拒否します。

• RSA 鍵生成では、boringssl が鍵を切り詰めることがあるため、鍵サイズは 128 ビットの倍数である必要があります。
• インポートした RSA 鍵のサイズは、新規生成と同様に少なくとも 256 ビット、最大 16384 ビットである必要があります。
• インポートした RSA 鍵の公開指数は、よく使う値 [3, 17, 37, 65537] に制限されます。
• 仕様に揃え、空でない usages 付きの公開 ECDH 鍵をインポートしようとするとエラーを投げます。

Compression Streams API で追加のエラーチェックを行い、DecompressionStream に末尾データがある、または圧縮データ全体を渡す前に閉じられた場合にエラーを投げます。

このフラグは Fetch API でアセットをリクエストするときのキャッシュの動きを変えます。request.cf オブジェクトで指定した cacheEverything や cacheTtl などのキャッシュ設定は、設定されている Cache Rules より優先されます。

このフラグは、request.cf オブジェクトの不要なプロパティを減らし、Workers のリクエストを簡潔にします。

フラグが有効なとき（2023-08-01 以降のデフォルト、または no_cf_botmanagement_default を設定した場合）、アカウントが Bot Management を使えるときだけ、Worker の request.cf に Bot Management オブジェクト が含まれます。

フラグが無効なときは、アカウントに Bot Management の権限があるかに関係なく、デフォルトの Bot Management オブジェクトが含まれます。

WHATWG は URLSearchParams オブジェクトの delete() ↗ と has() ↗ メソッドに、クエリパラメーターの削除をより精密に制御できる追加の任意引数を導入しました。引数は任意ですが、指定するとメソッドの動きが変わるため、既存コードが壊れるリスクがあります。互換性日付が 2023 年 7 月 1 日以降なら、この互換性フラグはデフォルトで有効です。

既存コードが壊れる例として、Array の forEach() で削除するパラメーターを反復する場合を考えます。

const usp = new URLSearchParams();
// ...
['abc', 'xyz'].forEach(usp.delete.bind(usp));

forEach() は渡した関数に複数のパラメーターを自動で渡します。新しい標準引数が追加される前は、これらの余分な引数は無視されていました。

いまは追加引数に意味があり、関数の動きが変わります。このフラグがある場合、上記の例は次のように変える必要があります。

const usp = new URLSearchParams();
// ...
['abc', 'xyz'].forEach((key) => usp.delete(key));

Response.redirect() で使う URL 実装を、仕様準拠（WHATWG URL Standard）に変えます。

以前は、Workers for Platforms の 動的ディスパッチ API でユーザー Worker へ HTTP リクエストを送ったとき、ユーザー Worker が例外を投げると、動的ディスパッチ Worker は本文なしの HTTP 500 エラーを受け取っていました。dynamic_dispatch_tunnel_exceptions 互換性フラグが有効なとき、例外は動的ディスパッチ Worker へ伝播します。動的ディスパッチ Worker 内の fetch() 呼び出しは同じ例外を投げます。これは サービスバインディング と Durable Objects の似た動きに揃えます。

Workers の Headers ↗ API に getSetCookie() ↗ メソッドを追加します。

const response = await fetch("https://example.com");
let cookieValues = response.headers.getSetCookie();

Enables Node.js APIs in the Workers Runtime. For compatibility dates of 2026-08-04 or later, Workers enables both nodejs_compat and nodejs_compat_v2 by default.

Note that some Node.js APIs are only enabled when your Worker's compatibility date is on or after the following dates:

Some Node.js modules are available in Workers only as non-functional stubs. These modules can be imported or required, but do not provide working implementations of the corresponding Node.js APIs. Stubs exist for compatibility with packages that check whether a module exists, and should not be used directly in application code.

The following stubs are enabled automatically only when nodejs_compat is enabled and your Worker's compatibility date is on or after the date shown:

When enabling nodejs_compat, we recommend using the latest version of Wrangler CLI, and the latest compatibility date, in order to maximize compatibility. Some older versions of Wrangler inject additional polyfills that are no longer necessary when your Worker uses a more recent compatibility date, because they are provided by the Workers runtime.

For compatibility dates of 2026-08-04 or later, nodejs_compat and nodejs_compat_v2 are not used because the compatibility date enables the same behavior. Existing projects do not need to remove these flags when updating their compatibility date. To turn off Node.js compatibility completely, remove the positive flags if present. Then add both no_nodejs_compat and no_nodejs_compat_v2.

If you see errors using a particular npm package on Workers, you should first try updating your compatibility date and use the latest version of Wrangler CLI or the Cloudflare Vite Plugin. If you still encounter issues, please report them by opening a GitHub issue ↗.

JavaScript の underlying source / sink を裏付ける、作業中の new ReadableStream() と new WritableStream() コンストラクターを追加します。

以前の new TransformStream() コンストラクターは Streams API 標準に揃っていませんでした。コンストラクターを仕様準拠にする後方非互換の変更にオプトインするには、transformstream_enable_standard_constructor を使います。streams_enable_constructors フラグと組み合わせる必要があります。

CommonJS モジュールは以前、module.exports だけではなく、モジュール名前空間（{ default: module.exports } のようなオブジェクト）をエクスポートしていました。このフラグが有効なとき、エクスポートは修正されます。

capture_async_api_throws 互換性フラグは、標準 API に揃えて、async 関数がエラーを throw したときだけ reject するようにします。逆の do_not_capture_async_api_throws フラグでは、エラーを含む async 関数はそのエラーを reject せず同期的に throw することがあります。

Workers の URL ↗ API の当初の実装は WHATWG URL Standard ↗ に完全には揃っておらず、次のような違いがありました。

• 当初の実装は連続する複数のスラッシュを 1 つのスラッシュに畳み込んでいました。

  new URL("https://example.com/a//b").toString() === "https://example.com/a/b"

• 当初の実装は https://example.com/a%%b のような不正なパーセントエンコード列に出会うと "TypeError: Invalid URL string." を投げていました。

• 当初の実装は一部の内容のパーセントエンコード / デコードが異なっていました。

  new URL("https://example.com/a%40b?c d%20e?f").toString() === "https://example.com/a@b?c+d+e%3Ff"

• 当初の実装には、後から追加された URL.canParse() ↗ などの URL 機能がありませんでした。

Worker の互換性日付を 2022-10-31 より後にするか、url_standard 互換性フラグを有効にすると、仕様準拠の URL API 実装にオプトインできます。

Response.redirect() で使う URL 実装に影響する response_redirect_url_standard 互換性フラグ も参照してください。

r2_list_honor_include フラグが設定されているとき、R2 の list オプションの include 引数が尊重されます。より古い互換性日付でこのフラグがない場合、include 引数は暗黙に include: ["httpMetadata", "customMetadata"] として動きます。

ランタイムにバグがあり、組み込み API に渡す不正な値がときどき誤って null と合体していました。本来は TypeError を投げるべきでした。dont_substitute_null_on_type_error はこの動きを直し、そのような状況で正しくエラーを投げます。

minimal_subrequests フラグが設定されているとき、Worker 自身のゾーン上のエンドポイントへ出す fetch() サブリクエスト（同一ゾーンサブリクエスト）には、適用される機能が少なくなります。もともとこれらの機能は同一ゾーンサブリクエストに適用されるべきではなく、ユーザーから見える動きの変化はごく少ない想定です。新しいフラグでは、Workers は次の動きの変化を観察することがあります。

• レスポンスボディは、Workers ランタイムへ送る前に日和見的に gzip されません。Worker がレスポンスボディを読むときは、これまでどおり平文で読むため、この無効化は不要な展開を防ぎます。一方 Worker がレスポンスをクライアントへそのまま渡す場合、Cloudflare の HTTP プロキシが Workers ランタイムのその側でレスポンスボディを日和見的に gzip します。Worker スクリプトから見える変化は、一部の Content-Encoding: gzip ヘッダーが出なくなることです。
• Automatic Platform Optimization は、状況によっては Worker の開始リクエストとそのサブリクエストの両方に適用されていたことがあります。いまは開始リクエストにだけ適用されます。
• リンクプリフェッチは、Worker のレスポンスにだけ適用され、Worker のサブリクエストへのレスポンスには適用されません。

global_navigator フラグが設定されているとき、Workers 内で新しいグローバル navigator プロパティが使えます。現時点では navigator.userAgent だけを公開し、値は 'Cloudflare-Workers' です。コードが Workers 環境で動いているかを確実に判定できます。

no_cots_on_external_fetch フラグは、Cloudflare Worker から外部（グレークラウド）サブリクエストを出すときに Custom Origin Trust Store を使わないようにします。

もともと、Workers API オブジェクトのプロパティはプロトタイププロパティではなくインスタンスプロパティとして定義されていました。そのため JavaScript 層でのサブクラス化が壊れ、サブクラスがスーパークラスの getter / setter を正しくオーバーライドできませんでした。このフラグは、それらの getter / setter をプロトタイプテンプレートに置く破壊的変更を制御します。

この変更は次に適用されます。

• AbortSignal
• AbortController
• Blob
• Body
• DigestStream
• Event
• File
• Request
• ReadableStream
• ReadableStreamDefaultReader
• ReadableStreamBYOBReader
• Response
• TextDecoder
• TextEncoder
• TransformStream
• URL
• WebSocket
• WritableStream
• WritableStreamDefaultWriter

もともと stub.fetch(url) で Durable Object へリクエストするとき、相対 URL を入力として受け付けていました。URL はプレースホルダー URL http://fake-host からの相対として解釈され、できた絶対 URL が宛先オブジェクトの fetch() ハンドラーへ届いていました。これは誤りで、完全な URL が必須の想定でした。このフラグは完全な URL を必須にします。

もともと fetch() に http: または https: 以外のプロトコルの URL を渡すと、黙って http: として扱っていました。たとえば fetch() は ftp: URL を受け付けるように見えますが、実際には HTTP リクエストを出していました。

Cloudflare Workers は WebSocket に対応するため、fetch() に非標準の拡張があります。ただし WebSocket ハンドシェイクを始める意図の HTTP リクエストでは、プロトコルは ws: や wss: ではなく、いままでどおり http: または https: を使ってください。

ws: と wss: の URL スキームは、WebSocket 専用の new WebSocket() コンストラクターとあわせて使うものです。fetch() の拡張は同じリクエストで HTTP と WebSocket の両方に対応する（レスポンスが WebSocket を始めるかどうかは相手次第）ため、すべてのリクエストは HTTP と見なされます。

もともと Workers ランタイムは、Streams 仕様が求めるとおりに BYOB リーダーの read() メソッド でユーザー提供の TypedArray から ArrayBuffer をデタッチしていませんでした。そのため、同じバッファーを複数の read() 呼び出しで誤って再利用できました。この変更で Workers は仕様に揃います。

ユーザーコードは、BYOB リーダーの read() メソッド に渡した ArrayBuffer を再利用しないでください。代わりに、次の例のように read() の Promise の結果を裏付ける ArrayBuffer を再利用できます。

// Consume and discard `readable` using a single 4KiB buffer.
let reader = readable.getReader({ mode: "byob" });
let arrayBufferView = new Uint8Array(4096);
while (true) {
  let result = await reader.read(arrayBufferView);
  if (result.done) break;
  // Optionally something with `result` here.
  // Re-use the same memory for the next `read()` by creating
  // a new Uint8Array backed by the result's ArrayBuffer.
  arrayBufferView = new Uint8Array(result.value.buffer);
}

後から追加された拡張メソッド readAtLeast() は常に ArrayBuffer をデタッチし、この機能フラグの設定の影響を受けません。

FormData API ↗ は、multipart/form-data 形式のデータ（特に HTTP リクエストボディ）の解析に使います。

もともと Workers ランタイムの FormData API 実装は、アップロードされたファイルを誤って文字列に変換していました。そのため formData.get("filename") は File オブジェクトではなく、ファイル内容を含む文字列を返していました。この変更で問題を直し、標準どおりファイルは File で表されます。

HTML5 標準は、終了タグを使わない void 要素として固定の集合を定義しています。<area>、<base>、<br>、<col>、<command>、<embed>、<hr>、<img>、<input>、<keygen>、<link>、<meta>、<param>、<source>、<track>、<wbr> です。

HTML5 は XML の自己閉じタグ構文を認識しません。たとえば <script src="foo.js" /> は本文なしの script 要素ではありません。いままでどおり </script> 終了タグが必要です。/> 構文は HTML5 では認識されず、> と同じ扱いになります。ただし 2000 年代初頭に普及しなかった標準である XHTML の名残として、この構文をいまも好む開発者は多くいます。

<esi:include> と <esi:comment> は HTML5 標準の一部ではなく、サーバー側 HTML 加工の技術である Edge Side Includes ↗ で使われます。これらのタグは本文を持たない想定で、XML の自己閉じ構文で書かれることがよくあります。

HTMLRewriter は ESI ではなく標準 HTML5 を解析する設計です。ただし HTMLRewriter で ESI の一部を実装できると便利です。この互換性フラグは、HTMLRewriter が <esi:include> と <esi:comment> を void タグとして扱い、正しく解析・処理できるようにします。

これらのフラグは compatibility_flags で有効にできます。ただし、特定日にデフォルトになる予定はまだありません。

デフォルトでは、Queues の Consumer Worker は ctx.waitUntil() に渡した Promise が解決してからメッセージを acknowledge します。この動きのため、ctx.waitUntil() を使う Queue コンシューマーはメッセージ処理が遅くなることがあります。デフォルトの動きは Queues Consumer Configuration Guide に記載しています。

次の Consumer Worker は ctx.waitUntil() を使う例です。デフォルトでは、このコンシューマーは sleep 関数が解決してからメッセージバッチを acknowledge します。

export default {
  async fetch(request, env, ctx) {
    // omitted
  },

  async queue(batch, env, ctx) {
    console.log(`received batch of ${batch.messages.length} messages to queue ${batch.queue}`);
    for (let i = 0; i < batch.messages.length; ++i) {
      console.log(`message #${i}: ${JSON.stringify(batch.messages[i])}`);
    }
    ctx.waitUntil(sleep(30 * 1000));
  }
};

function sleep(ms) {
  return new Promise(resolve => setTimeout(resolve, ms));
}

queue_consumer_no_wait_for_wait_until フラグを有効にすると、Queues コンシューマーは ctx.waitUntil() に渡した Promise の解決を待たずにメッセージを acknowledge します。ctx.waitUntil() を使うコンシューマーの性能を上げられます。フラグが有効な上記の例では、sleep 関数の解決を待たずにバッチを acknowledge します。

このフラグを使っても ctx.waitUntil() の動きは変わりません。ctx.waitUntil() は、メッセージバッチを acknowledge したあとも作業を続けられるよう、Consumer Worker の生存期間を延長します。

HTML5 標準は、終了タグを使わない void 要素として固定の集合を定義しています。<area>、<base>、<br>、<col>、<command>、<embed>、<hr>、<img>、<input>、<keygen>、<link>、<meta>、<param>、<source>、<track>、<wbr> です。

HTML5 は XML の自己閉じタグ構文を認識しません。たとえば <script src="foo.js" /> は本文なしの script 要素ではありません。いままでどおり </script> 終了タグが必要です。/> 構文は HTML5 では認識されず、> と同じ扱いになります。ただし 2000 年代初頭に普及しなかった標準である XHTML の名残として、この構文をいまも好む開発者は多くいます。

<esi:include> と <esi:comment> は HTML5 標準の一部ではなく、サーバー側 HTML 加工の技術である Edge Side Includes ↗ で使われます。これらのタグは本文を持たない想定で、XML の自己閉じ構文で書かれることがよくあります。

HTMLRewriter は ESI ではなく標準 HTML5 を解析する設計です。ただし HTMLRewriter で ESI の一部を実装できると便利です。この互換性フラグは、HTMLRewriter が <esi:include> と <esi:comment> を void タグとして扱い、正しく解析・処理できるようにします。