ストレージの使い分け（R2 / KV / D1 / Durable Objects比較）

第6章では、R2・Workers KV・D1・Hyperdriveを順に見てきました。第5章のDurable Objectsも含めると、Cloudflareでデータを保存する選択肢は5つあることになります。

種類が多いのは、それぞれが得意なことを絞り込んでいるためです。1つで何でもできる万能の保存先はありません。逆に言えば、選び方の基準さえ持っていれば迷わないということでもあります。このページでは、その基準を整理します。

01このページで分かること#

• 5つの保存先の役割を一言で言うと何か
• 3つの質問で選べる判断のフロー
• 主な項目を並べた比較表
• 実際のアプリケーションでの組み合わせ方
• 料金で失敗しやすいところ

025つの選択肢を一言で#

Hyperdriveだけは性格が違い、保存先そのものではなく、外部のデータベースへの経路です。そのため以下では、まず「Cloudflareの中に保存するか、外のデータベースを使うか」を分けて考えます。

033つの質問で選ぶ#

質問1：保存したいのはファイルそのものか#

画像、動画、音声、PDF、CSV、バックアップ――「中身を検索する必要がなく、まるごと出し入れするもの」であればR2です。

ファイルに付随する情報（アップロード日時、投稿者、公開・非公開など）は、R2ではなくD1に記録し、R2にはファイル本体だけを置くのが基本の形です。

質問2：条件で検索したり、集計したりするか#

「今月の注文を一覧する」「利用者ごとの合計金額を出す」「2つの表を突き合わせる」といった処理が必要なら、データベースの出番です。

• 新しく作るなら → D1
• すでにPostgreSQL / MySQLで動いているものがあるなら → Hyperdriveを経由して既存のデータベースを使う

質問3：書いた直後に、必ず最新の値が読めなければ困るか#

ここが最後の分かれ道です。

困る場合（在庫数、残高、座席の予約、順番待ち、共同編集など）はDurable Objectsを選びます。1つのオブジェクトが1か所で動き、そこがすべての読み書きの窓口になるため、「二重に予約が入る」といった事故が構造的に起こりません。

困らない場合（サイト設定、機能のオン・オフ、リダイレクト表、表示言語など）はWorkers KVです。反映まで最大60秒以上かかる代わりに、世界中のどこからでも数ミリ秒で読み出せます。

04比較表#

05実際には組み合わせて使う#

現実のアプリケーションでは、どれか1つを選ぶのではなく、役割ごとに使い分けます。

たとえば、商品を売るサイトを作る場合はこうなります。

• 商品画像・説明のPDF → R2（ファイル本体）
• 商品情報・注文履歴・会員情報 → D1（検索・集計が必要）
• サイト設定・お知らせの表示・キャンペーンの有効/無効 → Workers KV（読むだけ、頻繁に変わらない）
• 在庫数・カート・購入処理 → Durable Objects（二重販売を防ぐ正確さが必要）

ブログであれば、記事本文と一覧をD1、画像をR2、テーマ設定やリダイレクト表をKVに置く形になります。Durable Objectsは、コメントのリアルタイム表示や同時編集を入れる段階で必要になります。

最初からすべてを使う必要はありません。多くの個人サイトは、R2とD1、あるいはKVだけで十分です。困ったときに、その困りごとに合う保存先を足していく順序で問題ありません。

06迷いやすいパターン#

「KVとD1、どちらでもできそう」

読み方で決めます。キーを指定して1件取り出すだけならKV、条件で絞り込むならD1です。両方必要なら、正本をD1に置き、よく読む結果だけをKVにキャッシュする構成が定番です。

「Durable ObjectsとD1、どちらでもできそう」

書き込みの同時性で決めます。同じデータを複数の利用者が同時に書き換え、その順序や正確さが重要ならDurable Objects。読み取りが中心で、集計やレポートが必要ならD1です。

「R2とKV、どちらでもできそう」

大きさで決めます。KVの値は25MiBまでで、しかも操作回数で課金されます。数十KBを超えるファイルはR2が適しています。

「既存のデータベースがあるが、D1に移すべきか」

移す必要はありません。Hyperdriveで既存のまま使うほうが、移行の手間もリスクもありません。D1を検討するのは、データベース自体を新しく作る場合や、既存のデータベースの運用をやめたい場合です。

07料金で失敗しやすいところ#

保存先ごとに「何で課金されるか」が違います。ここを取り違えると、想定外の請求につながります。

• R2：一覧取得（クラスA操作）が読み取りの10倍以上高い。ファイル一覧を毎回取得する作りに注意
• Workers KV：書き込みが読み取りの10倍高く、無料枠は1日1,000回。書き込み中心の使い方は成立しない
• D1：課金されるのは「調べた行数」。インデックスがなければ、1件を探すために表全体を読んだ扱いになる
• Durable Objects：起きている時間も課金対象。待機中はハイバネーションで眠らせる
• Hyperdrive：追加料金はないが、接続先のデータベース側の料金は別に発生する

共通して言えるのは、「1回のリクエストで何回の操作が走るか」を数える習慣を持つことです。1回の画面表示で10回の問い合わせが走るなら、費用も10倍で効いてきます。

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

• 1つに寄せようとしない：無理に1つで済ませると、どこかで必ず無理が出ます。役割で分けるほうが結果的に単純になります
• ファイル本体とその情報は分ける：R2にファイル、D1にその情報、が基本形です
• 正本をどこに置くかを決める：KVはキャッシュとして使い、正しい値はD1やDurable Objectsに置く、という役割分担をはっきりさせてください
• 無料枠は「日」と「月」で単位が違います：KVとD1の無料枠は1日あたり、R2は1か月あたりです
• 移行しやすい形にしておく：保存先を呼び出す部分を1か所にまとめておくと、あとから差し替えやすくなります

09関連サービス#

• Workers：すべての保存先を呼び出す実行環境
• R2 / Workers KV / D1 / Hyperdrive：第6章の各ページ
• Durable Objects：第5章。正確さが必要な状態の管理
• Queues / Workflows：保存の前後で重い処理を非同期に回す

まとめ#

• Cloudflareの保存先は5つ。それぞれ得意なことを絞り込んでいる
• 選ぶときの質問は3つ。「ファイルか」「条件で検索するか」「書いた直後の正確さが必要か」
• ファイルはR2、検索・集計はD1（既存DBならHyperdrive）、正確さはDurable Objects、速い読み取りはKV
• 実際のアプリでは組み合わせて使う。最初からすべてを使う必要はない
• 料金は保存先ごとに課金対象が違う。1リクエストあたりの操作回数を数える習慣を持つ

これで第6章「ストレージ・データベース」は完結です。データを置く場所が決まれば、そのデータを使って何をするかという話に進めます。次の第7章では、Cloudflareが力を入れているAI関連のサービスを扱います。最初は、エッジでAIモデルを動かすWorkers AIです。

次に読む#

• Workers AIとは？エッジでAIモデルを動かす
• Hyperdriveとは？既存DBを高速化する仕組み