Workers KV Instant — API を変えずに p99 2ms 未満、代わりに制約が4つ付く

要約

Cloudflare は 2026-10-01、Workers KV に instant モードをプライベートベータで追加しました。

仕組みは、読み取り経路の差し替えです。 Cloudflare 社内で設定配布に使っている Quicksilver を読み取りに使い、Workers KV の API はそのままで高速化します。

公式の数値を整理します。 読み取りは p99 で 2ms 未満（実測 1.62ms）、classic モードの 287ms と比べて100倍以上。p95 はマイクロ秒台とされています。書き込みの複製は 300以上のエッジ拠点へ 250ms（中央値 107ms / p95 181ms / p99 256ms）。

100倍という数字は劇的ですが、重要なのは引き換えに付く制約です。4つあります。

(1) namespace 作成時に instant モードを明示する必要がある。 既存の namespace を切り替えるのではなく、新規作成時の選択です。

(2) メタデータ非対応。 getWithMetadata は null を返します。

(3) list はページネーションなしで全一致キーを1回で返す。 キー数が多い namespace では使いにくい挙動です。

(4) 書き込みは namespace あたり毎秒1回まで。

この4つを並べると、想定用途がはっきりします。 読み取りが圧倒的に多く、書き込みは稀で、キー数とデータ量が小さいもの。設定値、機能フラグ、ルーティングテーブル、A/Bテストの割り当てといった用途です。汎用のキーバリューストアとしては使えません。

価格も同じ方向を示しています。 読み取り（Class B）は $0.20 / 100万回で classic より 60%安い。一方でストレージは $100 / MB・月、namespace あたり最大 1MB・10,000 キーです。

ストレージ単価を読み替えます。 1MB で月100ドルというのは、データを置く場所としては極端に高い価格です。これは「安く大量に保存する」製品ではなく、「小さなデータを極端に速く読む」ことに全振りした価格設計です。classic KV のストレージが $0.50/GB・月（= $0.0005/MB・月）前後であることと比べると、方向性の違いがよく分かります。

提供は 2026-10-01 からプライベートベータで、申込制です。

何が変わったか

• Workers KV に instant モード（プライベートベータ、申込制）
• 読み取り経路に Quicksilver を使用。API は Workers KV のまま
• 読み取り: p99 2ms 未満（実測 1.62ms）。classic は 287ms
• 書き込み複製: 300以上のエッジ拠点へ 250ms（中央値 107ms / p95 181ms / p99 256ms）
• 制約が4つ
  • namespace 作成時に instant モードを明示
  • メタデータ非対応（getWithMetadata は null）
  • list はページネーションなしで全一致キーを1回で返す
  • 書き込みは namespace あたり毎秒1回
• 価格
  • 読み取り（Class B）: $0.20 / 100万回（classic より60%安い）
  • put / delete / list（Class A）: $0.10（公式表記のまま）
  • ストレージ: $100 / MB・月、namespace あたり最大 1MB・10,000 キー

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

この更新で見直す価値があるのは、「KV が遅いから別の手段を使っている」箇所です。

Workers で何かを作ると、設定値の置き場所に必ず悩みます。 選択肢は、コードに埋め込む（デプロイしないと変えられない）、KV に置く（遅い）、Durable Objects に置く（速いが設計が重い）、外部 DB を見る（さらに遅い）。多くのチームはコードに埋め込んで、変更のたびにデプロイするという運用に落ち着きます。

p99 2ms 未満で、250ms で全世界に反映されるなら、この判断が変わります。 設定を外に出してもレイテンシのペナルティがほぼ無く、変更が4分の1秒で全拠点に届く。 これは「デプロイせずに設定を変える」運用を現実的にします。

ただし、移行の判断は制約で決まります。確認すべき点を順に書きます。

1つ目。書き込みが毎秒1回という制限に収まるか。 設定値なら余裕で収まります。ユーザーごとのデータやセッション情報は収まりません。 ここが最初のふるい分けです。

2つ目。1MB・10,000キーに収まるか。 機能フラグなら収まります。ユーザー単位のレコードは収まりません。 「将来増えるかもしれない」データを入れるのは避けるべきです。

3つ目。getWithMetadata を使っていないか。 使っている箇所は書き換えが必要です。メタデータに入れていた情報を値の側へ移す設計変更になります。

4つ目。list の挙動が変わっても問題ないか。 ページネーションなしで全件返るのは、キー数が少なければ便利ですが、既存コードがページネーション前提で書かれていると挙動が変わります。

この4つを通ると、移行候補になります。 逆に言えば、既存の KV 利用をまとめて移せる製品ではありません。 「新しい KV が出たから移行しよう」ではなく、用途ごとに分類して、該当するものだけ移すという作業になります。

ここで、設計上の論点を1つ挙げます。namespace を用途で分ける必要が出てきます。

instant と classic は namespace 単位の選択なので、「速く読みたい小さなデータ」と「普通に保存したいデータ」を同じ namespace に置けません。 つまり、データの性質で namespace を分ける設計が前提になります。

これは良い制約だと考えます。 現状、KV の namespace は「アプリケーション単位」で切られていることが多く、中に性質の違うデータが混ざっています。 性質で分けると、どのデータがどういう読み書きパターンを持つかを整理することになり、設計が明示化されます。

プライベートベータという点について。 申込制なので、すぐに使えるとは限りません。 現時点でできるのは、自社の KV 利用を用途別に棚卸しして、移行候補を洗い出しておくことです。この棚卸し自体は、instant モードを使わなくても価値があります。

副業・個人活用視点

個人開発では、この更新は「設定の外部化」を可能にします。

個人で作った Workers のサービスは、設定がコードに埋まっていることが多いはずです。 理由は、KV を使うと遅くなるからではなく、そもそも設定を外に出す理由が薄かったからです。自分1人が使うなら、変更のたびにデプロイすれば済みます。

しかし、他人に使わせる段になると話が変わります。 「この値を変えたい」と言われるたびに自分がデプロイするのは、持続しません。 設定を外に出し、管理画面から変えられるようにする必要が出ます。

そのときの選択肢として、instant KV は素直です。 読み取りが速いので、リクエストごとに設定を読んでも体感に出ません。 1MB・10,000キーの制約も、個人のサービスの設定なら十分です。

ただし、コストの読み方に注意が必要です。

ストレージ $100/MB・月は、個人にとって無視できない額です。 1MB 使い切れば月100ドルです。設定値なら数 KB で収まるはずですが、「念のため大きめに」という発想で使うと危険です。 実際に使う容量を把握してから入れるべきです。

読み取り $0.20/100万回は、個人規模ではほぼ無料です。 月100万リクエストでも20セントです。コストの主体はストレージ側にあるという理解が重要です。

受託では、提案材料になるケースが限られます。

提案になり得るのは、「設定変更のたびにデプロイしている」顧客です。 この状態は意外と多く、顧客側の担当者が自分で値を変えられないために、毎回開発側へ依頼が来るという構造になっています。依頼する側も受ける側も負担です。

instant KV を使えば、「管理画面から変えると4分の1秒で全世界に反映される」仕組みが作れます。 説明しやすく、効果も体感できます。

ただしプライベートベータなので、現時点で顧客案件に入れるのは推奨しません。 申込が通るかも、いつ GA になるかも分かりません。classic KV で作っておき、instant が GA になったら namespace を切り替えるという順序が安全です。API が同じなので、切り替えのコストは低いはずです。

学習の観点では、「制約で用途を規定する」という設計に注目する価値があります。

instant モードの4つの制約は、どれも「できないこと」ですが、同時に「この製品は何のためのものか」を説明しています。 毎秒1回の書き込み、1MB の上限、メタデータ非対応。これらを見れば、設定配布用だと分かります。

これは、汎用性を上げるより制約を明示するほうが使う側に親切だという例です。 「何でも入れられます」と言われると、入れてはいけないものを入れて失敗します。 「毎秒1回しか書けません」と言われれば、書き込みが多いデータは入れません。

自分が API やライブラリを作るときにも同じことが言えます。 制約を減らして汎用化したくなりますが、制約が用途を伝えるという側面があります。 何にでも使える道具は、何に使うべきかを教えてくれません。

もう1つ、価格設計が用途を語っている点も見る価値があります。 読み取りが60%安く、ストレージが極端に高い。この価格表を見るだけで「読み取り中心・小容量」という用途が分かります。 価格は機能の説明でもある、という読み方です。