Cloudflare 22：R2 ― 取り出し料金ゼロの、S3 互換ファイル置き場

取り出し料金は、引っ越しも難しくする

egress 料金には、もう1つ見えにくい問題があります。データの引っ越しを難しくすることです。

たとえば、あるクラウドに 10TB のファイルを置いているとします。別のクラウドのほうが安い、あるいは使いたい機能がある、と分かっても、移すには 10TB 全部を外へ出す必要があります。その量の egress 料金が、一度にかかります。

その結果、「移したほうが長い目で見れば安いのに、移す費用が高くて動けない」という状態が生まれます。これをベンダーロックイン（特定の会社から離れられなくなること）と呼びます。データを入れるのは無料、出すのは有料、という形は、まさに「入りやすく出にくい」仕組みになっているのです。

Cloudflare は、この egress 料金を以前から問題にしてきました。回線の費用は、実際には量が増えるほど安くなるのに、利用者には高い単価で請求されている、という主張です。R2 は、その主張を自分たちの製品で示したもの、と考えると成り立ちが分かりやすいでしょう。

一言でいうと：取り出し料金ゼロの、S3 互換の置き場

R2 を一言でいうと、「外へ出す量に料金がかからない、S3 と同じ使い方ができるオブジェクトストレージ」です。

図の3本の矢印を、1ページ目と比べてください。行き先が利用者でも、別のクラウドでも、他社の CDN でも、転送料は0円です。

これで、「人気が出るほど請求が怖い」「引っ越せない」という2つの問題が、どちらも小さくなります。見られた回数に応じて「読む操作」の料金はかかりますが、単価は小さく、動画のような大きなファイルでも、1回読むのは1回の操作です。ファイルの大きさで料金が膨らむことはありません。

S3 と同じ使い方ができるので、「S3 を使っていたけれど、配信の転送料が重い」というサービスが、配る部分だけ R2 に移す、という使い方もよく見られます。

オブジェクトストレージ：バケットに、キーでファイルを置く

R2 を使う前に、オブジェクトストレージの考え方を押さえておきましょう。パソコンのフォルダとは少し違います。

キーの中の / は、実はただの文字です。オブジェクトストレージにフォルダはありません。images/cat.jpg と images/dog.jpg は、たまたま名前の頭が同じなだけの、別々のオブジェクトです。

ただ、一覧を取るときに「images/ で始まるものだけ」と頭の文字（prefix）を指定できるので、フォルダのように扱えます。管理画面でもフォルダのように表示されます。

普通のファイルシステムとの違いをまとめると、次のようになります。

「一部だけ書き換える」ことができないので、ログのように少しずつ追記するデータには向きません。一度作ったら丸ごと読むファイルに向いた置き場です。

出し入れの入口は3つ

R2 のバケットには、3つの入口からアクセスできます。

どの入口から置いたオブジェクトも、同じバケットの同じオブジェクトです。たとえば、夜間のバックアップの道具が S3 API で置いたファイルを、昼間に Worker から読んで加工し、公開 URL で配る、ということができます。

Worker のバインディングは、Cloudflare の中で完結するいちばん速くて簡単な入口です。アプリの中で「利用者が上げた画像を保存する」「権限を確かめてから画像を返す」といった処理は、こちらで書きます（後の使い方のページ）。

S3 互換 API は、Cloudflare の外から使うための入口です。次のページで見ます。

公開 URL は、ファイルを誰でも見られるように配るための入口です。その次のページで見ます。

バケットは、既定では非公開です。何も設定しなければ、外からは誰も読めません。公開したいときだけ、公開 URL の入口を明示的に開けます。

S3 互換：今の道具は「接続先」を変えるだけ

R2 は、Amazon S3 と同じ API に対応しています。そのため、S3 用に作られた道具やライブラリが、接続先を変えるだけで R2 に使えます。

変えるのは、主に3つです。

import { S3Client, PutObjectCommand } from "@aws-sdk/client-s3";

const s3 = new S3Client({
  region: "auto",
  endpoint: `https://${ACCOUNT_ID}.r2.cloudflarestorage.com`,
  credentials: { accessKeyId: KEY_ID, secretAccessKey: SECRET },
});
await s3.send(new PutObjectCommand({ Bucket: "my-app", Key: "backup/2026-09.zip", Body: data }));

S3 のすべての機能に対応しているわけではないので、特殊な機能を使っている道具では確かめが必要です。

S3 から R2 へ引っ越すための仕組みも用意されています。まとめて移す機能や、R2 に無いファイルを読まれたときにだけ S3 から取ってくる機能（少しずつ移す）があります。

公開して配る：独自ドメインをつなぐ

画像や動画を、Web サイトから誰でも見られるように配りたいことはよくあります。そのための入口が公開 URLです。方法は2つあります。

本番では、独自ドメインをつなぐ方法を使います。バケットの設定で、Cloudflare に登録しているドメイン（01号）のサブドメインを指定するだけです。こうすると、ファイルへのリクエストが Cloudflare の網を通るので、次のことができます。

キャッシュが効くと、R2 まで読みに行く回数そのものが減るので、「読む操作」の料金も下がります。

r2.dev の URL は、ボタン1つで有効にできる手軽さが魅力ですが、開発用という位置づけで、アクセスの回数に制限があり、キャッシュなどの機能も使えません。本番のサイトから直接リンクするのは避けましょう。

利用者ごとに見られるファイルが違う（自分の請求書だけ見られる、など）場合は、公開 URL ではなく、Worker で権限を確かめてから返すか、次のページの署名付き URL を使います。

署名付き URL：ブラウザから直接アップロードさせる

利用者に大きなファイル（動画など）をアップロードしてもらう場面を考えます。いちばん素直なのは、ブラウザ → あなたの Worker → R2 と、Worker を経由させる方法です。でも、大きなファイルは Worker のリクエストの大きさの上限にかかることがあり、Worker の処理も無駄に長くなります。

そこで使うのが署名付き URL（presigned URL）です。

署名付き URL には、「どのバケットの、どのキーに、何（PUT や GET）をしてよいか、いつまで有効か」が、秘密の鍵で作った署名として埋め込まれています。URL を持っている人は、その範囲のことだけができます。キーを変えたり、期限を延ばしたりすると、署名が合わなくなって拒否されます。

署名付き URL は S3 互換 API の機能なので、作るときは S3 の SDK や、軽いライブラリ（aws4fetch など）を使います。読み込み用（GET）の署名付き URL を作れば、非公開のファイルを、決めた人に期限付きで見せることもできます。

大事なのは、キー（置き場所の名前）はサーバー側で決めることと、期限を短くすることです。利用者にキーを決めさせると、他人のファイルを上書きされるおそれがあります。

導入：バケットを作り、Worker につなぐ

R2 を使い始める手順です。

$ npx wrangler r2 bucket create my-app

{
  "r2_buckets": [
    { "binding": "BUCKET", "bucket_name": "my-app" }
  ]
}

binding に書いた名前が、コードの env に入る名前になります。この例なら env.BUCKET です。

バケットを作るときには、データを置く地域も選べます。既定では、Cloudflare が利用状況を見て自動で選びます。法律や契約で「データを EU の中に置く」などの決まりがあるときは、その地域に限定したバケットを作れます。

手元で wrangler dev を使うと、R2 は手元の模擬版につながるので、本番のファイルを消してしまう心配なく試せます。

ほかにも、バケットには次のような設定があります。

使い方：put・get・delete・list

Worker のコードからは、env.BUCKET に対して put・get・delete・list を呼びます。

export default {
  async fetch(request: Request, env: Env): Promise<Response> {
    const key = new URL(request.url).pathname.slice(1); // 例: images/cat.jpg

    if (request.method === "PUT") {
      await env.BUCKET.put(key, request.body, {
        httpMetadata: { contentType: request.headers.get("content-type") ?? undefined },
      });
      return new Response("saved", { status: 201 });
    }

    const obj = await env.BUCKET.get(key); // 無ければ null
    if (!obj) return new Response("not found", { status: 404 });

    const headers = new Headers();
    obj.writeHttpMetadata(headers);        // 置いたときの content-type などを戻す
    headers.set("etag", obj.httpEtag);
    return new Response(obj.body, { headers });
  },
};

押さえておきたい点は次のとおりです。

このコードは説明のために短くしています。実際には、PUT の前に利用者の権限を確かめる処理が必要です。誰でも PUT できる Worker を公開すると、他人にバケットを使われてしまいます。

料金と保存クラス：払うのは「置いた量」と「操作の回数」

R2 の料金は、保存量と操作の回数の2つで決まります。egress（外へ出す量）はかかりません。2026年9月時点の主な数字は次のとおりです。料金・上限は変わるので、必ず公式の Pricing と Limits のページで確かめてください。

操作は、書く系（Class A）のほうが、読む系（Class B）より単価が高く設定されています。

R2 には、2つの保存クラスがあります。

Infrequent Access の「取り出しの料金」は、egress とは別物で、保存クラスの性質によるものです。めったに読まないものだけを入れる、という使い方を守れば安くなりますが、頻繁に読むと Standard より高くつきます。ライフサイクルのルールで「30日たったら Infrequent Access に移す」と自動化するのが定番です。

よくある落とし穴

R2 でよくつまずく点をまとめます。

「egress が無料」と聞くと、何も気にしなくてよいように感じますが、操作の回数は数えられています。特に、小さなファイル（アイコンやサムネイル）を大量に配るサイトでは、読む回数が料金の中心になります。独自ドメインとキャッシュ（02号）の組み合わせは、速さのためだけでなく、料金のためにも大切です。

他の号とのつながり

R2 は、他の多くの機能と組み合わせて使います。

よくある組み合わせは、「中身は R2、情報はデータベース」です。利用者が画像を上げたら、画像そのものは R2 に置き、「誰の、どの記事の、何という画像か」は D1 に書きます。一覧や検索は D1 で行い、表示するときだけ R2 から読みます。

画像のサイズを変えたり、形式を変えたりしたいときは、自分で Worker に書くより、31号の Images を使うほうが簡単です。