Cloudflare Basin が GA — Iceberg と R2 で「egress 課金のない分析基盤」を名前ごと整理した

要約

Cloudflare は 2026-10-01、Cloudflare Basin を一般提供（GA）にしました。Apache Iceberg と R2 Object Storage の上に構築したサーバーレスのデータ基盤です。

まず、名前の話を済ませます。 これは2025年の Birthday Week に「Cloudflare Data Platform」として発表されたものの改称・GA です。構成要素も改称されました。

• Basin Pipelines（旧 Cloudflare Pipelines）
• Basin Catalog（旧 R2 Data Catalog）
• Basin SQL（旧 R2 SQL）

つまり、全く新しい製品が出たわけではありません。 既存の3製品が GA になり、共通のブランド名でまとめられたという発表です。社内ドキュメントや構成図で旧名称を使っている場合、更新が必要になります。

各構成要素を見ます。

Basin Pipelines は、Workers / HTTP / Logpush からイベントを受け、SQL で変換して Iceberg テーブルまたは R2 のファイル（JSON / Parquet）へ書き込みます。 同日の changelog で、取り込み上限がストリームあたり 5 MB/s から 1 GB/s へ引き上げられました（200倍）。公式は「旧上限に収めるためだけに取り込みを複数ストリームへ分割する必要がなくなる」としています。

Basin Catalog は、マネージドな Iceberg REST カタログです。コンパクション・スナップショット失効・メタデータ最適化を自動化し、テーブルごとのコンパクションポリシーでアクセスパターンに応じた目標ファイルサイズを選べます。

この「自動化される部分」が実務的に大きいです。 Iceberg を自前で運用すると、小さなファイルが大量に溜まってクエリが遅くなる問題に必ず当たります。コンパクション（小さいファイルをまとめる）は定期実行が必要で、これを自分で組むのが Iceberg 運用の面倒な部分です。 マネージドで引き受けるなら、導入の障壁が下がります。

Basin SQL は、Iceberg テーブルに対するサーバーレスの分散クエリエンジンです。集約・JOIN・ウィンドウ関数・JSON 操作など190超の関数に対応し、Wrangler CLI / API / ダッシュボードのエディタから使えます。

課金は従量制で、取り込み・処理・クエリの実行時にのみ発生します。 時間課金やインフラ費用はありません。データ egress 課金がない点を、公式は一貫した差別化として挙げています。

エージェント文脈についても言及があります。 公式は「プロンプトからコーディングエージェントまで、データアプリケーションが増えており、そうしたものは本来リソースやデータをポーリングして待つ必要がある」と述べ、書き込み直後にクエリできることがエージェントの反復を支えるとしています。

何が変わったか

• Cloudflare Basin が GA。2025年の「Cloudflare Data Platform」の改称・一般提供
• 構成要素も改称
  • Basin Pipelines（旧 Cloudflare Pipelines）— Workers / HTTP / Logpush から受け、SQL で変換して Iceberg または R2（JSON / Parquet）へ
  • Basin Catalog（旧 R2 Data Catalog）— マネージドな Iceberg REST カタログ。コンパクション・スナップショット失効・メタデータ最適化を自動化、テーブルごとのコンパクションポリシー
  • Basin SQL（旧 R2 SQL）— サーバーレスの分散クエリエンジン。190超の関数（集約 / JOIN / ウィンドウ関数 / JSON）。Wrangler CLI / API / ダッシュボード
• Basin Pipelines の取り込み上限が 5 MB/s → 1 GB/s（ストリームあたり）
• 課金は従量制（取り込み・処理・クエリの実行時のみ）。時間課金・インフラ費用なし
• データ egress 課金なし

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

この発表で実務に効くのは、改称への対応と、Iceberg を選ぶ判断の2点です。

改称への対応を先に書きます。これは地味ですが確実に発生する作業です。

既存で Cloudflare Pipelines / R2 Data Catalog / R2 SQL を使っている組織は、社内の名称が公式と食い違います。 構成図、運用手順書、監視のダッシュボード名、新人向けの説明資料。これらに旧名称が残ります。

対応の判断としては、「急いで直さない」が妥当です。 製品名が変わっても動作は変わりません。ただし、新しく書く資料では新名称を使い、既存資料は改訂のタイミングで直すという方針を決めておくべきです。方針を決めないと、同じ組織内で2つの名前が混在し、新しく入った人が混乱します。

次に、Iceberg を選ぶ判断です。これが本質的な論点です。

ログや分析データの置き場所には、大きく3つの選択肢があります。 (1) クラウドベンダーの専用サービス（BigQuery、Redshift など）、(2) 自前のデータベース、(3) オブジェクトストレージ + 標準形式（Iceberg、Delta Lake など）。

(1) は使いやすいが、データがそのベンダーの形式に入ります。 移行しようとすると全部出し直しになり、egress 課金が移行コストとして重くのしかかります。

(3) の利点は、形式が標準であることです。 Iceberg テーブルは、Cloudflare 以外のクエリエンジンからも読めます。 つまり**「今は Basin SQL で読むが、将来別のエンジンに変えられる」**という状態を保てます。

ここで egress 課金がないことが効きます。 標準形式で置いていても、取り出すのにお金がかかるなら移行は現実的ではありません。 egress が無料なら、他のエンジンから直接読む構成も、他のクラウドへ移す選択も取れます。

つまり、この製品の価値は「将来の選択肢を閉じない」ことにあります。 性能や機能で BigQuery に勝つという話ではなく、ロックインの度合いが低いという話です。

検討する際の注意点を3つ挙げます。

1つ目。Basin SQL の機能が自社のクエリに足りるかを確認すること。 190超の関数は少なくありませんが、既存の分析基盤から移すなら、使っている関数の対応を確認する必要があります。 とくに時系列の分析でベンダー固有の関数を使っている場合、書き換えが発生します。

2つ目。コンパクションポリシーを設定する前提で考えること。 マネージドで自動化されるとはいえ、テーブルごとのポリシーは自分で決めます。 「書き込みが多く読み取りが少ないテーブル」と「その逆」で適切な設定は違います。放置すると既定値で動きますが、クエリが遅いときの調整点としてここを知っておくべきです。

3つ目。取り込み上限 1 GB/s を「必要だから」ではなく「制約が外れたから」として読むこと。 多くの組織に 1 GB/s は過剰です。重要なのは、上限回避のためのストリーム分割という歪んだ設計が不要になった点です。既にストリームを分割して回避している構成があるなら、統合してシンプルにできます。

なお、Basin GA のブログ本文には「ストリームあたり最大 3GB/s」と読める記述があり、changelog の 1 GB/s と一致しません。 実装時は公式ドキュメントの Limits ページで確認してください。

副業・個人活用視点

個人開発者にとって、Basin の意味は「ログを捨てなくて済む」ことです。

個人のサービスでログを長期保存するのは、意外と悩む部分です。 選択肢は、ログサービスを使う（無料枠が小さく、すぐ有料になる）、データベースに入れる（容量が増えると遅くなる・高くなる）、捨てる（最も多い選択）。

結果として、多くの個人開発者はログを数日しか持ちません。 問題が起きたときに「先週のデータが無い」という状態になります。

R2 + Iceberg という構成なら、保存コストはオブジェクトストレージの単価です。 個人の規模なら、年単位で保存しても数ドルの範囲に収まります。クエリは実行時課金なので、普段使わなければかかりません。

この「置いておく分は安く、使うときだけ課金」という構造は、個人開発に合っています。 ログは普段見ませんが、必要なときには過去まで遡りたいものです。

具体的な使いどころを2つ。

1つ目は、アクセスログの長期保存と分析です。 自分のサービスやブログのアクセスを Workers から Pipelines へ流し、月末に Basin SQL で集計する。 分析サービスを使わずに自分で持てます。

2つ目は、自分の活動データの蓄積です。 学習時間、作業ログ、API の利用量。こうしたデータは1年経つと価値が出ます。 置き場所が安ければ、迷わず残せます。

注意点を1つ。SQL が書けることが前提です。

Basin SQL は SQL エンジンなので、分析は SQL で行います。 ダッシュボードが用意されているわけではありません。「データは溜まっているが見る手段がない」という状態になりがちです。 溜める前に、どういうクエリを書くつもりかを1つ決めておくとよいです。

受託の文脈では、提案材料として使えるケースがあります。

「ログを見たいが分析基盤がない」という顧客は多いです。 そして**「BigQuery を入れましょう」という提案は、顧客にとって重い**ことがあります。新しいクラウドの契約、権限管理、コスト管理が発生します。

すでに Cloudflare を使っている顧客なら、Basin は追加契約なしで始められます。 これは提案のハードルを下げます。

ただし、見積もりで注意すべき点があります。 SQL でのクエリ作成と、結果を見せる仕組みの工数を忘れないこと。 データを溜める部分は設定で済みますが、「顧客が自分で見られる状態」にするには、ダッシュボードか定期レポートが必要です。 ここを見積もりに入れないと、「データは入っているが誰も見ていない」という成果物になります。

学習の観点では、「標準形式を選ぶ」という判断の価値を押さえる意味があります。

Apache Iceberg のようなオープンな形式を選ぶと、短期的には不便です。 専用サービスのほうが使いやすく、機能も多いことが普通です。標準形式の利点は、将来にしか現れません。

この「将来しか価値が出ない選択」をどう評価するかは、技術選定の難しい部分です。 移行が発生しなければ、標準形式を選んだ利点はゼロです。一方で、移行が必要になったときの差は非常に大きくなります。

判断の目安としては、「そのデータを何年持つつもりか」で考えるのが現実的です。 数か月で捨てるデータなら、使いやすいほうを選べばよいです。数年持つデータなら、その間にベンダーの料金体系やサービス内容が変わる確率が高く、移行可能性に価値が出ます。 egress 課金の有無が移行の現実性を左右する、という点も併せて覚えておく価値があります。