Workers KVとは？エッジのKey-Valueストア

《 Cloudflare完全ガイド 目次へ 》

前ページのR2は、画像や動画のようなファイルを丸ごと預ける場所でした。しかし、プログラムが本当に頻繁に読むのは、もっと小さなデータです。サイトの設定、機能のオン・オフ、リダイレクトの対応表、利用者ごとの表示言語――どれも数十バイトから数キロバイト程度の値ですが、リクエストのたびに読み込まれます。

こうした小さなデータを、世界中のどこからでも数ミリ秒で読み出すための仕組みがWorkers KVです。R2が「大きいものをたまに取り出す」ための場所だとすれば、KVは「小さいものを何度も読む」ための場所です。

このページで分かること

• Key-Valueストアとは何か
• KVがなぜ世界中から速く読めるのか（中央ストアとエッジキャッシュ）
• 結果整合性という割り切りと、その注意点
• 無料枠・料金・制限
• 向いている用途と、選んではいけない用途

Key-Valueストアとは

Key-Value（キー・バリュー）ストアは、名前（キー）と中身（値）の組だけでデータを管理する、最も単純な保存の仕組みです。

キー: "config:site-title"      →  値: "KayのLogBook"
キー: "user:1234:lang"         →  値: "ja"
キー: "feature:new-checkout"   →  値: "on"

できることは3つだけです。キーを指定して値を書く（put）、キーを指定して値を読む（get）、キーを指定して消す（delete）。「値が100より大きいものを探す」といった条件検索はできません。

制約が強い代わりに、動作は非常に単純で速くなります。表を設計し、列を決め、インデックスを張り……といったデータベースの手間もありません。まさに「名前を付けて置いておく箱」です。

KVの仕組み

KVが世界中から速い理由は、保存する場所と読む場所を分けているところにあります。

書き込みは、Cloudflareの中央データセンターへ送られます。ここがデータの正本です。

読み取りは違います。あるキーが初めて読まれると、その拠点に値がキャッシュされ、以降その拠点からの読み取りはキャッシュから返されます。第1章で扱ったCDNのキャッシュと同じ考え方を、ファイルではなくデータに適用したものだと考えてください。

そのため、よく読まれるキーほど速くなります。世界中で使われているキーは、世界中の拠点にキャッシュが行き渡り、どこからでも数ミリ秒で返るようになります。

結果整合性という割り切り

この構造には、避けられない副作用があります。値を書き換えても、各拠点のキャッシュが切れるまで古い値が返るということです。

Cloudflareの公式ドキュメントは、変更が他の拠点に見えるまで「最大60秒以上かかる場合がある」と明記しています。キャッシュの保持時間（cacheTtl）の既定値が60秒であるためで、この値を長くすればさらに速くなる代わりに、反映はより遅くなります。

このように「いつかは全拠点で同じ値になるが、その瞬間は揃っていないかもしれない」という性質を結果整合性（eventual consistency）と呼びます。KVを使うかどうかは、多くの場合この一点で決まります。

• 「1分古い値が返っても困らない」データ → KVが最適
• 「書いた直後に必ず新しい値でなければ困る」データ → KVは不適

たとえば在庫数や残高のように、読んだ瞬間の正しさが必要なデータをKVに置いてはいけません。それらは第5章のDurable Objects、あるいは次ページのD1の担当です。

料金と無料枠

2026年8月時点の料金です。KVには読み書きの転送料（エグレス）は掛かりません。

料金表を見れば、KVの設計思想がはっきり分かります。書き込みは読み取りの10倍高く、無料枠では1日1,000回しか書けません。読み取り中心の使い方を前提にした料金体系です。

なお課金は「キー単位」で数えられます。まとめて100件を読む操作は、100回分として計算されます。存在しないキーを読んだ場合も1回に数えられ、管理画面やWranglerからの操作も同様に課金対象です。

制限

KVのデータは名前空間という単位でまとめます。用途ごとに名前空間を分け、Workerの設定でそれぞれを結び付けて使います。

同一キーへの書き込みは毎秒1回までです。アクセスカウンターのように、同じキーを高頻度で更新する用途には構造的に向いていません。

向いている用途・向かない用途

向いている用途

• サイトやアプリの設定値（タイトル、表示切り替え、外部APIのエンドポイントなど）
• 機能フラグ（新機能を一部の利用者にだけ見せる、といった切り替え）
• リダイレクトの対応表（旧URLから新URLへの何万件もの変換表）
• 許可リスト・拒否リスト（IPアドレスや会員IDの判定）
• 利用者ごとの設定（表示言語、テーマなど、書き換え頻度が低いもの）
• 外部APIの応答のキャッシュ（毎回問い合わせずに済ませる）

向かない用途

• カウンター、在庫数、残高など、書いた直後の正しさが必要なもの → Durable Objects
• 条件を指定した検索や集計（「登録日が今月のユーザー」など） → D1
• 同じキーを毎秒何度も書き換える処理 → Durable Objects
• 大きなファイルの保存（25MiBを超えるもの、そもそも画像や動画） → R2

初心者が注意するポイント

• 書いた直後に読むと古い値が返ることがあります：管理画面で値を変えたのに反映されない、というのは多くの場合これです。最大60秒待ってから確認してください
• 無料枠の書き込みは1日1,000回です：読み取りの10万回に比べてかなり少ないので、書き込みが多い設計になっていないか早い段階で確認してください
• 一覧取得（list）は高価です：書き込みと同じ単価で、全キーを走査する用途には向きません。キーの名前を工夫して（例：user:1234:lang）、直接読める設計にしてください
• キーの設計が後から効いてきます：接頭辞で用途を分けておくと、一覧取得の絞り込みや移行が楽になります
• 秘密情報の保管場所ではありません：APIキーやパスワードは、Workersのシークレット機能を使ってください
• 削除も1日1,000回の枠内です：大量のキーを整理する作業は、枠を意識して分割してください

関連サービス

• Workers：KVを読み書きする実行環境。バインディングでつながる
• Durable Objects：書いた直後の正しさが必要なデータの担当
• R2：ファイルそのものを置く場所（前ページ）
• D1：条件検索や集計ができるデータベース（次ページ）

• Cloudflare CDN：KVのキャッシュと同じ考え方でファイルを配る仕組み（第1章）

• ストレージの使い分け：R2 / KV / D1 / Durable Objects の選び方（第6章のまとめ）

まとめ

• Workers KVは、キーと値だけを扱う最も単純な保存の仕組み
• 書き込みは中央へ、読み取りは各拠点のキャッシュから返るため、読むほど速くなる
• その代わり、変更が全拠点に行き渡るまで最大60秒以上かかる（結果整合性）
• 無料枠は1日あたり読み取り10万回・書き込み1,000回。書き込みは読み取りの10倍高い
• 設定値・機能フラグ・変換表・許可リストなど、読み多め・書き少なめの用途に向く
• カウンターや在庫のように、書いた直後の正しさが必要なデータには使わない

ここまでのR2とKVは、どちらも「決めた名前で取り出す」保存でした。しかし実際のアプリケーションでは、「今月登録した利用者を一覧する」「注文と商品を突き合わせる」といった問い合わせが必要になります。次のページでは、そのための本格的なデータベース――D1を見ていきます。

次に読む

• D1とは？サーバーレスSQLiteデータベース
• R2とは？エグレス無料のオブジェクトストレージ

→ ガイドの目次に戻る

※本記事の情報は 2026年8月時点のものです。