BigQuery無料枠の内訳：サンドボックスの60日制限と課金が始まる境目・検証環境を無料で回す設計

BigQueryを触ってみたいが、いきなり請求が立つのは避けたい。この段階で最初に当たるのが無料枠とサンドボックスです。両者は同じものではなく、さらに90日の無料トライアルが混ざって説明されるため、どこまでが本当に無料なのかが見えにくくなっています。2026年8月17日時点の公式ドキュメントをもとに、費目ごとの内訳と課金が始まる境目、無料の内側で検証環境を回す設計を整理します。

まとめ：無料枠は毎月1TiBと10GiB、サンドボックスは60日で消える

先に結論を置きます。BigQueryの無料枠は期限のない恒久的な枠で、毎月「処理されるクエリデータ1TiB」と「ストレージ10GiB」です。無料トライアルが終わったあとも消えません。学習や小規模な検証であれば、この範囲を出ずに動かし続けられます。

一方のサンドボックスは、その無料枠をクレジットカードも請求先アカウントもなしに試すための入口でした。額面は同じ1TiBと10GiBですが、テーブルとビューとパーティションが60日で自動的に消え、DML文とストリーミング挿入とData Transfer Serviceが使えません。定期実行を組んで貯め続ける用途には向かない設計です。

課金が始まる境目は3つに絞れます。月1TiBのスキャンを超えたとき、保存量が10GiBを超えたとき、そして請求先アカウントを有効にして無料枠の対象外の費目を使い始めたとき。この3つを押さえたうえで、ドライランと最大課金バイト数とカスタムクォータを重ねれば、無料の内側に留まっているかを事前に確かめながら進められます。

無料枠とサンドボックスと無料トライアルの三つを最初に切り分ける

混ざりやすい3つを、先に別のものとして並べます。ここを取り違えたまま設計すると、90日後に環境ごと止まる事故につながります。

期限のない無料枠は毎月1TiBの分析と10GiBの保存で数える

公式の料金ページは、無料枠をGoogle Cloudの無料枠の一部と位置づけ、その使用量上限が「無料トライアル期間中だけでなく、期間終了後も適用される」と明記しています。つまり期限で切れる性質のものではありません。上限は月あたりストレージ10GiB、クエリ（分析）で処理されるデータ1TiBの2本立てです。

超えた分だけが従量課金です。無料枠と有料が排他なのではなく、毎月の請求から一定量が差し引かれる形だと捉えてください。仕組みから確認したい場合は、BigQueryのサーバーレス構造と採用判断を先に読んでおくと、なぜスキャン量で課金されるのかが腑に落ちます。

サンドボックスはクレジットカードなしで無料枠だけを試せる入口です

サンドボックスは、公式ドキュメントの表現では「クレジットカードや請求先アカウントなしでBigQueryを試せる」評価用の環境でした。無料枠と同じ10GiBのアクティブストレージと月1TiBの処理データが使えます。支払い手段を登録せずに済むため、社内の承認を待たずに手元で検証を始めたい場面では入口として機能します。

ただし「無料枠を使える環境」であって「無料枠そのもの」ではありません。後述する4つの制限はサンドボックス側の話で、請求先アカウントを持つ通常のプロジェクトには付きません。同じ1TiBでも使える機能の範囲が違います。

九十日で三百ドルの無料トライアルは終了時に停止される全く別の枠

3つめが無料トライアルです。公式ドキュメントによれば、90日間で300ドル分のクレジットが付与され、申し込み時には支払い手段の登録が求められます。トライアル中に自動で課金されることはありませんが、期間内に有料アカウントへ切り替えないと請求先アカウントが閉じられ、紐づくプロジェクトとリソースが停止されます。

ここが最も誤解されやすい箇所でした。300ドルのクレジットはBigQuery以外にも使える一時的な原資で、無料枠のように毎月戻ってくるものではありません。両者は同時に使えるため、90日のあいだは「クレジットで支払われている分」と「無料枠で課金されていない分」が混在します。90日後に請求が跳ねる話は、この混在を分けずに使い切った結果です。

クエリとストレージと転送の三層に分けて無料枠の内訳を数え直す

無料枠は「1TiBと10GiB」で語られがちですが、請求明細の費目はもう少し細かく分かれています。実際に無料で動く範囲は、この2つより広いというのが実測での結論でした。

クエリの1TiBは請求先アカウント単位で毎月あたまにリセットされる

料金表の記載は「0から1TiBまでFree、1TiB以上は1TiBあたり6.25ドル（per 1 month / account）」でした。単位が account である点を見落とさないでください。プロジェクトを10個作っても、同じ請求先アカウントにぶら下がっていれば1TiBを分け合う形になります。検証用にプロジェクトを分けても枠は増えません。

さらに、課金されないクエリが明記されています。エラーで終わったクエリと、キャッシュから結果が返ったクエリは課金対象外。逆に参照するテーブルあたり最小10MB、クエリあたり最小10MBが計上されるため、小さいクエリを大量に投げると想定より早く枠を削ります。

ストレージ10GiBにはBigQuery MLのモデルと訓練データも入る

ストレージ側の10GiBは、テーブルのデータだけの話ではありません。公式の無料枠の表には「BigQueryに格納されているBigQuery MLのモデルとトレーニングデータはBigQueryストレージの無料枠に含まれます」と書かれています。SQLだけで機械学習を試すつもりで大きめの訓練データを置くと、モデルと合わせて10GiBを圧迫します。

なお10GiBの枠は、論理と物理のどちらにも、アクティブと長期保存のどちらにも「毎月10GiBまで無料」として表記されていました。課金方式を変えても入口の10GiBは変わりません。

読み込みとコピーとエクスポートと削除は無料オペレーションで数えない

見落とされやすいのがここです。料金ページは「無料のオペレーション」を独立した節として持っており、データの読み込み、テーブルのコピー、データのエクスポート、そしてデータセットやテーブルやパーティションやビューの削除が挙がっています。

読み込みは、default-pipeline という共有スロットプールを使うバッチ読み込みが無料でした。エクスポートも共有スロットプールを使う限り無料で、1日あたり最大50TiBという上限が示されています。ただし読み込んだあとのストレージ料金と、書き出した先のCloud Storage料金は別に発生。「転送は無料、置いた先は有料」という切り分けです。

Storage Write APIの2TiBとRead APIの300TiBは別勘定

APIから読み書きする場合の枠は、クエリの1TiBとは別に用意されています。BigQuery Storage Write API（gRPC）は毎月2TiBまで無料で、超過分が1GiBあたり0.025ドル。Storage Read APIは各請求先アカウントにつき月300TiBまでの読み取りバイトが無料で、超過分が1TiBあたり1.10ドルでした。

加えて、一時テーブルからの読み取りでスキャンされたバイトは無料で、300TiBの枠にも計上されないと明記。クエリ結果を引き取るだけの使い方なら、Read API側の枠を心配する場面はほとんど来ません。

サンドボックスで動かない四つの機能と六十日の有効期限を押さえる

ここからはサンドボックス固有の制約を、あとから効いてくる順に並べます。

テーブルとビューとパーティションが六十日で自動的に消える仕組み

公式ドキュメントは「すべてのBigQueryデータセットにデフォルトのテーブル有効期限が設定され、すべてのテーブル、ビュー、パーティションが60日後に自動的に期限切れになる」と説明しています。手動で消さなくても、放置したものは2か月で無くなります。

検証用としては合理的な仕様ですが、社内向けのダッシュボードをここに繋ぐと、ある日を境に参照先が消えて表示が壊れます。サンドボックスで作ったものは常設しない、という線引きを最初に共有しておいてください。

DMLが動かないため更新はCREATE OR REPLACEで代替する

サンドボックスがサポートしない機能として、ドキュメントはストリーミングデータ、DML文、BigQuery Data Transfer Serviceの3つを挙げています。UPDATE、DELETE、MERGE といった行単位の書き換えが使えないということです。

実務上の回避策は、更新をやめて洗い替えに寄せることでした。中間テーブルを作り直す形にすれば、DMLを使わずに同じ結果へ到達できます。非対応として列挙されているのはDMLであり、テーブルを作り直す種類のステートメントは列挙に含まれていません（2026年8月時点）。

CREATE OR REPLACE TABLE sandbox_ds.daily_summary AS
SELECT
  DATE(event_time) AS event_date,
  COUNT(*) AS events
FROM sandbox_ds.raw_events
WHERE DATE(event_time) BETWEEN '2026-08-01' AND '2026-08-17'
GROUP BY event_date;

行を書き換えるのではなく、テーブルごと差し替える形。冪等性も確保しやすく、無料枠の中で何度でも回し直せます。

転送サービスが使えないため定期実行のスケジュールを組み立てられない

Data Transfer Serviceが動かないという制約は、思っているより広く効きます。Cloud StorageやAmazon S3、広告系サービスからの定期取り込みが組めないだけでなく、スケジュールされたクエリもこの仕組みの上に載っているためです。

結果として、サンドボックスでは「毎朝取り込んで集計しておく」形の自動化が作れません。手元から読み込みジョブを叩く運用です。コンソールとbqコマンドの初回操作は、BigQueryの使い方と初回のつまずきどころにまとめています。

標準のクォータと上限はサンドボックスの中でもそのまま効いてくる

4つめは、サンドボックスだから緩いわけではないという話です。ドキュメントは「すべての標準のBigQueryの割り当てと上限も適用される」としています。クエリの実行時間や1ジョブあたりの件数といった通常の制限は、無料であっても同じように掛かります。

逆に言えば、サンドボックスで動いた処理は有料化しても同じ制約の中で動きます。制限に引っかかる設計かどうかを、課金なしで先に洗い出せるという読み替えも可能です。

課金が始まる境目はスキャン量と保存量とアップグレードの三つに絞れる

どこから請求が立つのかを、入口ごとに言語化しておきます。ここが曖昧なままだと、無料と信じて回した検証が月末に請求として返ってきます。

1TiBを超えた瞬間から1TiBあたり6.25ドルで積み上がる

最初の境目はスキャン量です。米国リージョンのオンデマンド料金は1TiBあたり6.25ドルで、月内の累計が1TiBを超えた分から発生します。注意点として、料金はMB単位で切り上げられ、SELECTで選んだ列の全データが対象になります。

LIMIT句を付けてもスキャン量は減りません。結果を100行に絞っても、読みに行った列のデータ量がそのまま課金対象です。ここを知らずに巨大テーブルへ SELECT * を投げると、1回で1TiBを消し飛ばす場面があります。

10GiBを超えた保存分は時間単位の単価で日々積み上がっていく

2つめは保存量です。アクティブな論理ストレージの単価は1GiB時間あたり0.000031507ドルで、30日を720時間として換算するとおよそ0.023ドル。10GiBを超えた分が、この単価で毎時間積み上がります。

額としては小さく見えますが、止まらないという性質を持ちます。クエリを投げなくても発生するため、検証後のデータセットを消し忘れると静かに積み上がる形。論理と物理のどちらで受けるかを含む保存側の設計は、BigQueryの料金体系とコスト監視の実務で扱っています。

請求先アカウントを有効にした時点で無料枠の外側にある費目が開く

3つめが見落とされやすい境目でした。サンドボックスから有料へ切り替えると、60日の制限とDMLの制約が外れる代わりに、無料枠の対象外の費目も使えるようになります。開いた蛇口は自分で閉めない限り閉じません。

公式のアップグレード手順は、プロジェクトで請求を有効にし、料金のニーズに合わせてBigQueryのエディションを選ぶ流れです。この時点で、オンデマンドのままにするか容量モデルへ移るかが決まります。検証を続けるだけならオンデマンドが無難でした。

無料枠の対象外にあたる費目は最初の1バイトから課金されていく

無料枠が適用されるのはクエリ（分析）とストレージであって、すべての機能ではありません。料金ページは、容量ベースのスロット料金がストレージ費用やBI Engineには適用されず、ストリーミング挿入やStorage APIの使用にも適用されないと整理しています。

実務でいえば、BI Engineの予約、Editionsのスロット予約、他クラウド上のデータを参照する構成は、1TiBの無料枠と無関係に課金されます。「無料枠があるから多少は大丈夫」が通用しない領域がある、と分けて覚えてください。

無料枠の内側で検証環境を回し続けるための設計と歯止めの置き方

無料枠は運任せで守るものではなく、事前確認と上限設定で守るものでした。4つの手を重ねます。

ドライランと課金される最大バイト数の二段で1TiBを守り切る

1段目は事前確認です。ドライランを使えば、クエリを実行せずに課金対象バイト数を見積もれます。bqコマンドなら実行前に必ず挟む習慣にしておくと、桁を間違えたクエリをその場で止められます。

bq query --use_legacy_sql=false --dry_run \
'SELECT COUNT(*) FROM `myproject.sandbox_ds.raw_events`'

2段目が強制力のある上限です。BigQueryには「クエリで課金される最大バイト数」を指定する設定があり、見積もりがその値を超えるクエリは実行前に失敗します。人の注意ではなく設定で止める形になるため、複数人で触る検証環境ほど効きます。

パーティションと列の絞り込みでスキャン量を桁の単位まで落とす

そもそも読む量を減らせば、1TiBはなかなか減りません。料金ページも、パーティショニングとクラスタリングによって処理されるデータ量を削減できると案内しています。日付でパーティションを切り、必ずその列で絞る。これだけで月内の累計は大きく変わります。

列指向である以上、選んだ列の分だけ課金される性質も味方にできます。50列のテーブルから3列だけ読めば、単純計算で読む量は大きく落ちるはず。検証段階ほど SELECT * を書きがちなので、最初にルール化しておく価値があります。

10GiBに収めるためのサンプリングとテーブル有効期限の設定

保存側は、そもそも全量を置かないという判断が効きます。検証の目的が集計ロジックの確認であれば、直近1か月分や1パーセントのサンプルで足りる場面がほとんどでした。全量が要るのは性能を測るときだけです。

あわせて、データセットにデフォルトのテーブル有効期限を設定しておくと、消し忘れたテーブルが自動的に片づきます。サンドボックスでは60日が既定で入っていますが、有料化した環境では自分で設定しない限り残り続けます。

カスタムクォータで一日あたりの処理量に上限を先に置いてしまう

最後が全体の歯止めです。BigQueryはユーザーレベルまたはプロジェクトレベルでカスタムのコスト管理を設定でき、1日あたりに処理できるバイト数へ上限を掛けられます。上限に達すると、それ以上のクエリは実行されません。

月1TiBを30日で割ればおよそ34GiB。1日あたりの上限を数十GiBに設定しておけば、誰かが誤って巨大なクエリを投げても月の枠が1日で消える事態を防げます。無料枠を守る仕組みとしては最も確実な手でした。

無料のまま続けてよい条件と有料へ移すべき場面を条件で言い切る

最後に判断です。どちらが良いかではなく、どの条件でどちらを選ぶかを示します。

無料のまま続けてよいのは検証と学習と単発の集計までの範囲です

無料枠とサンドボックスで完結させてよいのは、次の3条件がすべて成り立つ場合です。第一に、扱うデータが10GiBに収まるか、収まる形へサンプリングできること。第二に、月あたりのスキャン量が1TiBに収まること。第三に、処理の実行が手動で構わないこと。

この3つを満たすなら、有料化して得られるものはほとんどありません。SQLの検証、データ構造の設計確認、提案前の実現性チェックは、この範囲で回せます。

有料へ移すべきは定期実行とDMLと六十日超えの保持が要る場面

逆に、次のいずれか1つでも当てはまったら有料へ移すべきでした。スケジュールされたクエリやData Transfer Serviceで定期実行を組みたいとき。行単位の更新や削除をDMLで書く必要があるとき。60日を超えてデータを保持したいとき。ストリーミングでリアルタイムに書き込みたいとき。

いずれも、工夫で回避すると設計が歪む種類の制約です。洗い替えで代替できるのは検証の間だけで、本番のデータ量と更新頻度になると破綻します。切り替えが遅れるほど、サンドボックス前提で書いた処理の作り直しは増える一方。データを集める構成そのものから設計したい場合は、データ分析基盤構築・MLOps構築支援で収集から可視化までの設計と実装を請け負っています。

アップグレードした後も六十日の有効期限がそのまま残るという罠

有料化したあとに一度は確認すべき箇所があります。公式ドキュメントは、アップグレード後に「テーブル、ビュー、パーティションなどのBigQueryリソースのデフォルトの有効期限を更新する」よう案内しています。60日という設定は、請求を有効にしただけでは外れません。

本番運用に切り替えたつもりで放置し、2か月後にテーブルが消えるという事故はここから生まれます。アップグレード直後に、データセットのデフォルトのテーブル有効期限と、既存テーブルの有効期限を両方確認してください。

外部に任せる場合は無料枠の前提をどこまで伝えると事故が減るか

外部のベンダーに検証を依頼する場面では、無料枠の前提を先に共有しておくと見積もりの精度が上がります。伝えるべきは3点。想定するデータ量、月あたりのクエリ回数と対象期間、そして定期実行が要るかどうかです。

この3点が決まれば、無料枠に収まるPoCとして組むのか、最初から請求先アカウント込みで設計するのかが分かれます。無料枠に収まる前提で握れたなら、PoC期間の基盤コストはゼロに近づきます。

よくある質問

BigQueryの無料枠は毎月リセットされますか？

されます。料金ページの表記は「per 1 month / account」で、クエリ1TiBとストレージ10GiBはどちらも月あたりの上限です。無料トライアルの期間中だけでなく、期間が終わったあとも同じ上限が適用されると明記されています。ただし単位が請求先アカウントであるため、プロジェクトを増やしても枠は増えません。

サンドボックスのままで本番運用を続けられますか？

推奨できません。テーブルとビューとパーティションが60日で消えるうえ、DML文とストリーミング挿入とData Transfer Serviceが使えないためです。定期実行も組めず、日次で更新される業務データには届きません。検証と学習の環境と割り切り、条件に触れた時点で有料へ切り替えてください。

無料枠を超えないように上限を設定できますか？

できます。手段は2つあり、1つはクエリ単位で「課金される最大バイト数」を指定する方法、もう1つはユーザーレベルまたはプロジェクトレベルでカスタムのコスト管理を設定して1日あたりの処理量に上限を掛ける方法です。前者は事故クエリを実行前に止め、後者は全体の使いすぎを止めます。両方を重ねるのが確実でした。

無料トライアルの300ドルは無料枠とは別に使えますか？

別枠として同時に使えます。無料トライアルは90日間で300ドル分のクレジットが付く時限の原資で、期限のない無料枠とは性質が異なります。期間中は無料枠で課金されない分とクレジットで支払われる分が混在するため、90日後の請求を読み違えないよう分けて把握してください。

サンドボックスで作ったデータは有料化後も残りますか？

残りますが、条件付きです。請求を有効にしただけでは60日のデフォルト有効期限が外れないため、そのままにすると作成から60日で消えます。公式ドキュメントもアップグレード後に有効期限を更新するよう案内しています。データセットの既定値と既存テーブルの両方を確認してから運用に載せてください。

関連記事

• BigQueryとは：サーバーレスDWHの仕組みと採用判断：無料枠を出たあとの製品像
• BigQueryの料金：オンデマンドとEditionsの分岐点：1TiBを超えたあとの体系
• BigQueryの使い方：コンソールとbqコマンドの初回操作：最初に触る手順の確認
• BigQuery MLでSQLだけで学習を回す：訓練データが保存枠に入る前提で
• データ分析基盤の構築：5層アーキテクチャと実装手順：本番の基盤へ広げる設計
• BigQueryの導入ステップと内製・外注の分岐：PoCから本番移行の進め方