要約

  • Cloudflareの公開料金では、R2のStandardとInfrequent Accessはいずれも外向き転送料が1 GB当たり0ドル。一方、Infrequent Accessには1 GB当たり0.01ドルの取り出し料があり、操作料もStandardより高い。転送無料は請求全体の無料を意味しない。Cloudflareの料金文書
  • Cloudflareは、Rcloneを使ってR2のオブジェクトをローカルにコピーする手順を公開している。持ち出す方法は文書化されているが、それだけでは移行時間、業務の継続、移行先での完全な代替を実証したことにはならない。CloudflareのRclone文書

料金表のゼロは、何をゼロにしているのか

CloudflareのR2を評価する際には、最初に二つの問いを分けたい。データを外に送るといくら請求されるのか。そして、別の環境に移って同じ仕事を続けるには、いくらとどれだけの時間が必要なのか。前者には公開料金表が答える。後者には、顧客自身の利用形態と移行の実測が欠かせない。

2026年9月19日に確認した資料では、R2は外向き転送に対する料金を両ストレージクラスとも0ドルと表示している。これは単なる言い換えではなく、転送量に比例する特定の料金項目がゼロであるという条件だ。大量のデータを扱う利用者にとって、この項目を見積もりから外せる意味はある。ただし、本稿はその日に料金が引き下げられたと報じるものではない。過去の料金との比較や、変更の発効日は確認していない。

また、データを送信するという行為を、課金上も一つの処理と考えると判断を誤る。外向き転送に対する料金と、データを取り出す料金、読み出しなどの操作に対する料金は別の項目である。転送料の単価がゼロでも、その転送を行うための処理が別の課金対象になる可能性は残る。R2のInfrequent Accessは、この違いが料金表に直接表れる例だ。

重要なのは、無料という言葉を否定することではない。どの単位について、どの範囲で無料なのかを明確にすることである。外向き転送料がないことを評価しながら、移行の総費用は別に算定する。この二つは矛盾しない。

安い保管単価と高い操作単価は同時に存在する

Cloudflareの料金文書に記載された単価は次の通りだ。金額は米ドルで、取得時点の公開条件である。個別契約や実際の請求額を示すものではない。

課金項目 Standard Infrequent Access
保管、1 GB-month当たり 0.015ドル 0.01ドル
Class A操作、100万回当たり 4.50ドル 9.00ドル
Class B操作、100万回当たり 0.36ドル 0.90ドル
外向き転送、1 GB当たり 0ドル 0ドル

Infrequent Accessの保管単価はStandardより0.005ドル低く、比率では3分の1低い。一方、Class Aの単価は2倍、Class Bは2.5倍となる。この比較は二つのクラスの単価差であって、時間の経過による値上げや値下げを表してはいない。

Class Aには概ね書き込み、一覧取得、変更に関する操作が、Class Bには読み出しやメタデータの読み出しに関する操作が含まれる。ただし、ある移行作業がそれぞれ何回の課金対象操作を発生させるかは、この区分だけでは決まらない。オブジェクトの数を知っていても、その数字をそのまま請求上の操作回数に置き換えることはできない。

さらにInfrequent Accessには、1 GB当たり0.01ドルのデータ取り出し料と、30日間の最低保管期間がある。Standardには最低保管期間がない。保管単価だけならInfrequent Accessが低いという事実と、利用全体でも安いという結論の間には、こうした条件が入る。

これはInfrequent Accessが不利な商品だという意味ではない。アクセスが少ない使い方と多い使い方を区別する理由が、料金体系そのものにあるということだ。保管費の節約が大きく、取り出しと操作の負担が小さい利用形態なら、低い保管単価には意味がある。逆に、低頻度という想定を置いたデータでも、実際には頻繁に読み出しているなら、名前ではなく利用実績で比較する必要がある。

5ドルの保管費差は、500 GBの取り出し料で消える

単価の関係を見やすくするため、1,000 GB-monthの保管量を仮定する。ここでは保管費とInfrequent Accessの取り出し料だけを計算し、無料枠、操作料、課金単位の切り上げ、最低保管期間に伴う調整、税、割引などは含めない。顧客の実際の請求書でも、実施した移行の結果でもない。

公表単価をそのまま掛けると、Standardの保管費は15ドル、Infrequent Accessは10ドルになる。差は5ドルだ。Infrequent Accessで課金対象となる取り出しが500 GBあれば、取り出し料は5ドルとなり、この保管費差と同額になる。取り出しが1,000 GBなら、その料金は10ドルで、Infrequent Accessの保管費と合わせて20ドルになる。

仮定するInfrequent Accessの課金対象取り出し量 Standardの保管費だけ Infrequent Accessの保管費と取り出し料だけ
0 GB 15ドル 10ドル
500 GB 15ドル 15ドル
1,000 GB 15ドル 20ドル

この表の各列は、最終請求額ではなく費用の一部分である。500 GBという数字も、どの顧客にも当てはまる損益分岐点ではない。操作料金の差を加えれば比較は変わり、Standardの無料枠などを適用しても変わる。また、GB-monthは期間を含む保管量の単位であり、取り出しのGBと単純に同じ尺度ではない。「保存データの半分を一度読めば必ず逆転する」という規則に読み替えるべきではない。

それでも、この小さな計算は料金体系の仕組みを示す。保管単価による節約は有限であり、取り出しが増えるにつれて別の料金項目が積み上がる。外向き転送料の0ドルは、この取り出し料を消さない。

操作料金も含めると、その関係を次のように整理できる。SをGB-monthで表した保管量、Aを100万回単位のClass A操作数、Bを100万回単位のClass B操作数、RをGB単位のInfrequent Accessの課金対象取り出し量とする。両クラスで同じS、A、Bが発生すると仮定した場合の、米ドル建ての単純な費用モデルである。

Standard = 0.015 × S + 4.50 × A + 0.36 × B
Infrequent Access = 0.010 × S + 9.00 × A + 0.90 × B + 0.010 × R
差額（Infrequent Access − Standard）
  = −0.005 × S + 4.50 × A + 0.54 × B + 0.010 × R

AとBは生の操作回数ではない。例えばAが1なら、Class A操作を100万回と置いている。最初のマイナス項が低い保管単価による差で、その後のプラス項が操作単価と取り出し料による差だ。保管量だけの比較が不十分な理由を、一つの式にまとめたものである。

このモデルは、公開単価を連続的に掛け算する仕組みの説明にすぎない。無料枠、請求単位の切り上げ、最低保管期間の調整、税、個別交渉による条件、クレジットや割引は除いている。移行先の費用、技術者の作業、検証、並行稼働、その他のサービス料金も除外した。同じ作業が両クラスで同じ操作数を生むという仮定も、実測した結果ではない。したがって、この式をそのまま見積書として使うべきではない。

請求額を決めるのは、容量以外の数字でもある

CloudflareはStandardだけに月間無料枠を設け、保管10 GB-month、Class A操作100万回、Class B操作1,000万回を含めている。Infrequent Accessにはこの無料枠が適用されない。また、料金文書は利用量を次の課金単位へ切り上げると説明している。無料枠と課金条件

このため、単価表での比率と実際の請求額の比率は一致するとは限らない。保管単価が3分の1低いという関係から、月額請求も3分の1低くなるとはいえない。特に無料枠の影響が相対的に大きい利用では、無料枠を除いた計算と請求額を混同しないことが重要になる。

ただし、ここで無料枠の適用範囲を勝手に補うこともできない。どの単位で利用量を集計するのか、複数の用途をどう扱うのかについて、本稿の計算は詳細な請求規則を再現していない。無料枠をどこまで使えるかは、該当する条件と請求実績で確認すべき事項である。

最低保管期間も、長期間保存するつもりのデータと、短期間で削除・変更する可能性のあるデータを同じように評価できない理由となる。Infrequent Accessの30日という条件は確認できるが、それだけを根拠に早期削除やクラス変更の具体的な請求額を算出することはしない。個別の課金規則が必要だからだ。

経営側が求めるべき数字は、総保管量一つではない。保管量、課金対象の取り出し量、Class AとClass Bの操作数、それぞれを残した比較が必要だ。同じ量のデータを持っている二つの用途でも、操作数まで同じとは限らない。容量のグラフしか見ていなければ、費用の増減を引き起こした利用行動を見落とす。

その区別は、移行費用の見積もりにも効く。データを取り出す作業について、転送量だけをゼロ単価に掛けて終わりにすると、作業によって発生する他の課金を評価していないことになる。一方で、操作料が存在するという理由だけで高額な移行費用を断定するのも誤りだ。必要なのは、代表的な作業で実際に発生する利用量の確認である。

R2から外へコピーする手順はある

料金だけから「出られる」「出られない」を判断する必要はない。CloudflareはRcloneの設定と利用手順を公開しており、R2のバケットからローカルの保存先へオブジェクトをコピーする例を示している。これはR2へ取り込む説明だけではなく、R2から持ち出す方向の手順である。

同社の文書にある例は、次のコマンドだ。

rclone copy r2:user-uploads/dog.txt .

これは文書上の例であり、本稿が実行して成功を確認したコマンドではない。また、一つのオブジェクトをコピーする例を、運用中のシステム全体の移行手順と同一視するべきでもない。

文書では、S3互換ストレージ用の設定を選び、プロバイダーとしてCloudflare R2を指定する。アクセスキーID、シークレットアクセスキー、S3 APIのエンドポイントに加え、CloudflareのアカウントIDと、適切な権限・対象範囲を持つR2 APIトークンが設定上の要素となる。

これらは持ち出しを試すための具体的な条件である。料金表だけよりも、実行可能性について一段踏み込んだ情報といえる。ただし、ある顧客が必要な権限を持っているか、社内で誰が取得・管理できるか、検証用の保存先を安全に用意できるかは、別途確認する必要がある。設定要件があること自体は、Cloudflareが顧客のデータ持ち出しを妨げている証拠ではない。

Rcloneの開発側は、copyの説明で、同一のファイルを飛ばしてコピーし、コピー先のファイルを削除しないと記している。元がディレクトリーの場合は、そのディレクトリー自体ではなく中身をコピーする。また、--dry-runでコピーを実行せずに処理を確認できる。

ここにも区別が要る。コピー先を削除しないことは、コピー先に変更を加えないことと同義ではない。実際の検証では、既存の重要データに影響しない保存先を設けるべきだ。事前確認が通ったことも、データが転送された証拠ではない。転送時間、再試行の状況、完了後の内容、移行先での動作は、実行して確認する対象として残る。

さらにCloudflareの文書は、syncがコピー元にないファイルをコピー先から削除する可能性に注意を促している。同期時の注意点 copyでの持ち出し確認と、削除を伴い得る同期は同じ判断ではない。出口を試すつもりで既存の保存先を変えてしまわないよう、処理の目的と影響範囲を分ける必要がある。

この手順が公開されている以上、R2には文書化された持ち出し方法がない、と論じるのは不正確だ。正確な問いは、その方法が対象のデータと業務に対して、どの範囲まで使えるかである。

「S3互換」は、確認する範囲の出発点

Cloudflareは、移行を容易にするためR2がS3 APIを実装していると説明する一方、API機能には差があり、実装状況を示しながら対応を進めているとも説明している。CloudflareのS3 API互換性文書

この記述は、全面的な互換性を保証するものとして読むべきではない。しかし、何が足りないかを推測だけで列挙する根拠にもならない。本稿で確認した資料からは、個別の操作について対応・非対応を網羅的に判定していない。特定の機能が使えないと断定するのではなく、対象のアプリケーションが実際に使う操作とパラメーターを確認する必要がある、というところまでが妥当な結論だ。

実務上の比較単位は、「S3互換」という名称全体より小さい。どの操作を使うか、どの状態を維持する必要があるか、移行後に何を同じとみなすか。これらを対象業務ごとに定義しなければ、移行先の採否を判定できない。逆に、使っていない機能の違いを理由に、すべての移行が困難だと考える必要もない。

ファイルがコピーできることと、アプリケーションが同じ条件で動くことは、検証対象が違う。業務が必要とするメタデータ、設定、権限、識別情報などについても、何を保存し、何を再設定する必要があるかを確認することになる。これはR2に特定の欠陥があるという主張ではなく、バイト列の移動より広い意味での代替を評価するための問いである。

また、二つの保存先がS3互換であるという理由だけで、サービス間の転送がサーバー側だけで完結すると仮定することもできない。本稿は、そのような経路や性能を確認していない。転送にどの設備や回線を使うのか、誰の費用になるのかは、実際に選ぶ方法で確認すべきだ。

互換性の表記には価値がある。共通の操作体系を手掛かりに、検証の対象を具体化できるからだ。ただし、それが代替の完了を表す言葉になるのは、利用する機能と運用条件について確認を終えた後である。

出口の有無を、実行結果で確かめる

ここまでの資料は、外向き転送料がゼロという条件と、オブジェクトを持ち出す手順を示している。次に必要なのは、代表的な対象で移行を実施し、その結果を業務上の要件と照合することだ。本稿はその試験を実施しておらず、特定の顧客が成功したとも失敗したとも述べていない。

試験の対象は、「取り出しやすいデータだけ」では不十分になり得る。どの範囲を代表させるかを明示し、対象外にしたデータや機能を記録する必要がある。小さな試験を行うこと自体が問題なのではない。その結果を、確認していない全体へ広げてしまうことが問題になる。

最初の段階では、持ち出しに必要な権限と、試験用の保存先を用意する。次に、実際の転送で時間と課金対象の利用量を記録する。完了後には、必要なデータと状態が移行先で利用できるかを確認する。そのうえで、アプリケーションの代表的な処理を実行し、顧客が必要とするサービス条件を満たすかを判定する。

費用の測定と技術的な判定は、別々に残す方がよい。転送自体は成功したが予算を超える場合と、予算内だが必要な処理を再現できない場合では、次の判断が違う。前者なら方法や対象範囲の見直しが論点になる。後者なら、価格を下げるだけでは解決しない。

移行先が実際の業務を引き受けられるかも独立した条件だ。保存されたデータを読めたという結果は重要だが、それだけで本番サービスの継続を確認したことにはならない。どこまで元のサービスに依存せずに動かす必要があるのかを先に決め、その範囲で判定する必要がある。意図的に一部の利用を残す移行と、完全に置き換える移行では、合格条件が異なる。

こうした確認は、必ず乗り換えるためだけに行うものではない。移行に必要な費用と時間が分かれば、利用を続ける判断にも根拠が増える。ただし、試験をしただけで交渉力が高まったと断定することはできない。別の選択肢が商業上の意味を持つには、その費用、実施可能な時期、業務上の制約が、実際の意思決定に使える程度に明らかである必要がある。

料金上の利点と市場への効果を混同しない

R2の外向き転送料がゼロであることを過小評価する必要はない。費用項目が一つ減ることと、すべての費用がなくなることは別だ。後者が成立しないからといって、前者の利点まで消えるわけではない。

同様に、移行作業が必要だからといって、それが直ちに不当な囲い込みを意味するわけではない。利用者が得ている統合の便益、データや業務の規模、自社の設計も、移行の難易度に関わる問いとなる。顧客が合理的に統合を選ぶ場合も考えられる。依存があるかどうかと、その依存が不当かどうかは、別々に証拠を求めるべき問題である。

投資家にとっても、料金表から得られる結論には限界がある。公開料金は、顧客が直面する費用構造の一部を示す。しかし、R2の収益性、顧客獲得、解約、他社の対応、市場全体の競争状態は、この資料だけでは分からない。ゼロ転送料から、Cloudflareの利益率や内部の戦略意図を逆算することはできない。

より広い競争効果を論じるには、利用者が実際にどのような行動を取ったか、代替先がどの条件で使えるようになったかなど、追加の観測が必要になる。料金の一行は、その調査の出発点にはなるが、結論そのものではない。

現時点で支持できる評価は、限定的だが明確である。R2の外向き転送料0ドルは具体的な料金上の利点であり、Cloudflareは持ち出し手順も公開している。一方、Infrequent Accessでは取り出し料、高い操作単価、最低保管期間が保管単価の低さと併存する。実行できる乗り換えかどうかは、料金表ではなく、対象業務での費用計測と移行先での動作確認によって次に確かめるべき問題だ。