Gemini in BigQueryの料金体系を完全解説【思わぬ課金を防ぐ設定】

はじめに：「AIに聞くだけ」でも課金されうるという不安

「BigQueryにAI（Gemini）が組み込まれたらしいけど、うっかり使うと高額請求が来ないか心配で、なかなか触れない」——そんな声をよく聞きます。

特に中小ECや個人事業主の方にとって、クラウドの従量課金は「気づいたら数万円」という事故が一番怖いところです。Gemini in BigQuery は確かに便利なのですが、「AIに自然言語で聞いただけ」でも、その裏で課金が発生しうるという点を知らないまま使うと、思わぬ請求につながります。

この記事では、Gemini in BigQuery の料金がどこで発生するのか、どんなケースで高額になりやすいのか、そしてそれを防ぐための具体的な設定を、できるだけかみくだいて解説します。

⚠️ 注意 料金の具体的な金額はあくまで 2026年時点の目安 です。クラウドの料金は予告なく変わります。実際に試算・運用する前に、必ず Google Cloud の公式の最新料金ページをご確認ください。

なお、自然言語からSQLを生成する機能そのものの使い方は Gemini in BigQueryで自然言語からSQLを書く（2026年版）で、BigQuery全体のコストを月1万円以内に抑えるコツは BigQueryのコストを月1万円以内に抑えるコツでそれぞれ詳しく扱っています。あわせて読むと全体像がつかみやすいはずです。

Gemini in BigQueryで課金が発生する3つのポイント

「Gemini in BigQuery」とひとことで言っても、課金は実は 複数の場所 で同時に発生します。ここを分けて理解しておくと、料金の見通しがぐっと立てやすくなります。

① AI機能そのものの利用料

まず、Gemini のアシスト機能（自然言語からのSQL生成、コードの説明、補完など）を使うこと自体に対する料金です。これは BigQuery の利用形態（オンデマンドか、容量ベースのエディションか）や契約プランによって扱いが変わります。

ポイントは、「画面上でAIに話しかける」操作にもコストが結びつきうるということです。無料で無制限に質問できるわけではない、と考えておくのが安全です。

② 生成・推論（トークン）に対する課金

ML.GENERATE_TEXT や AI.GENERATE といった関数を使って、テーブルのデータをGeminiに投げて要約・分類・抽出させる場合、処理したトークン量（入力＋出力の文字量に相当）に応じた課金 が発生します。

これは「AIにデータを読ませて何かを生成させる」たびに積み上がる費用です。100行なら小さくても、10万行のレビューを一括で要約させると、トークン量に比例して費用が膨らみます。

なお、これらの 関数の名称・構文は版によって変わります（ML.GENERATE_TEXT か AI.GENERATE か、引数の形など）。使う前に最新の公式ドキュメントで確認してください。

③ 実行するクエリのスキャン量（BigQuery本体）

意外と見落とされがちなのが、ここです。Geminiが生成してくれたSQLを 実際に実行すると、スキャンしたデータ量に対して通常どおりBigQueryのクエリ課金が発生 します。

オンデマンド課金では、スキャンしたデータ量（バイト数）に応じて課金されるのが基本です。AIが書いてくれたクエリが SELECT * で巨大テーブルを全件スキャンするようなものだった場合、AI利用料とは別に、スキャン課金がドカンと乗ってきます。

💡 補足 つまり Gemini in BigQuery のコストは「AIへの利用料・推論料」＋「生成されたSQLを動かすスキャン料」の合算で考える必要があります。片方だけ見ていると見積もりが甘くなります。

思わぬ高額になる例と、その回避

ここからは「やってしまいがちな失敗例」と、その回避策をセットで見ていきます。

例1：とりあえずAIアシストを常時オンにして使い倒す

便利だからと、社内の複数人が日常的にAIアシストへ質問を投げ続けると、利用料が地味に積み上がります。

回避策：本当にAIの助けが必要な作業（複雑なクエリの下書き、わからないエラーの説明）に絞って使う。「単純なSELECT文くらいは自分で書く」と決めておくだけで、無駄な利用を減らせます。

例2：巨大テーブルをまるごとAIに要約させる

ML.GENERATE_TEXT で、数十万行のテキストカラムを一気に処理させるパターンです。トークン課金が行数に比例するため、テスト気分で実行したつもりが大きな請求になりがちです。

生成系の関数は、テーブル（行の集合）を入力として渡すのが基本の形です。入力テーブルに prompt 列を用意し、その各行に対してGeminiが生成結果を返します。

-- ⚠ いきなり全件はNG：まず小さなテーブルで試す
-- 入力テーブルに prompt 列を用意し、TABLE で渡す
SELECT *
FROM ML.GENERATE_TEXT(
  MODEL `my_dataset.gemini_model`,
  TABLE `my_dataset.reviews_sample`,   -- prompt 列を持つ小さめのテーブル
  STRUCT(0.2 AS temperature, 256 AS max_output_tokens)
);

💡 補足 上の review_text をそのままプロンプトにしたい場合は、事前に SELECT review_text AS prompt FROM ... LIMIT 10 のような**小さな入力テーブル（またはビュー）**を作ってから渡すと、1件あたりのコスト感をつかみやすくなります。1行ずつスカラー的に呼びつつ別カラムも同時にSELECTする書き方は行スコープが混在してエラーになりやすいため避けます。

⚠️ 注意 生成系関数の 名称・引数・呼び出し方（ML.GENERATE_TEXT / AI.GENERATE など）は版によって異なります。実際に書く前に、必ず最新の公式ドキュメントで構文を確認してください。

回避策：いきなり全件ではなく、まず数十件規模の小さな入力テーブルで試し、1件あたりのコスト感をつかんでから本番のサイズに広げます。

例3：AIが生成したSQLを中身を見ずにそのまま実行する

AIが書いてくれたSQLは便利ですが、巨大テーブルへの全件スキャンや、パーティション・クラスタリングを無視した非効率なクエリになっていることがあります。

-- ⚠ 全件スキャンになりやすい例
SELECT * FROM `my_dataset.access_logs`;

-- ✅ 期間とカラムを絞ってスキャン量を減らす
SELECT user_id, event_name
FROM `my_dataset.access_logs`
WHERE event_date BETWEEN '2026-06-01' AND '2026-06-30';

回避策：実行前にSQLへ目を通し、SELECT * を避けて必要なカラムだけにする、WHERE で期間（パーティション列）を絞る、という基本を徹底します。これだけでスキャン量が大きく変わります。

コストを抑えるための具体的な設定

事故を防ぐ仕組みは、運用前に用意しておくのが鉄則です。「気をつける」だけでは、いつか事故が起きます。

dry_run で実行前に料金を試算する

BigQueryには、実際にはクエリを動かさず、スキャンするデータ量だけを見積もる dry_run（ドライラン）という仕組みがあります。これを使えば、実行前に「このクエリは何バイト読むのか」が分かります。

# bq コマンドで dry run（実際には課金されず、推定スキャン量だけ返る）
bq query --use_legacy_sql=false --dry_run \
  'SELECT user_id, event_name
   FROM `my_dataset.access_logs`
   WHERE event_date = "2026-06-01"'

エディタ画面でも、クエリを入力すると右上あたりに「このクエリで処理されるバイト数」の見積もりが表示されます。実行ボタンを押す前に、必ずこの数字を確認する習慣をつけましょう。

💡 補足 表示されるバイト数に、お使いのリージョンのオンデマンド単価をかければ、そのクエリ1回のおおよその料金が分かります。単価は公式の最新料金で確認してください。

コスト上限・クォータを設定する

「うっかり巨大クエリを実行してしまう」事故そのものを、設定でブロックできます。

最大処理バイト数の上限（maximum bytes billed）：1クエリでスキャンできるバイト数に上限を設けると、それを超えるクエリはエラーで止まり、課金されません。
プロジェクト/ユーザー単位のクエリ使用量クォータ：1日にスキャンできる総量に上限を設けておけば、暴走を日次で食い止められます。
予算アラート（Budgets & Alerts）：一定金額に達したらメールで通知。請求が膨らむ前に気づけます。

# 1クエリのスキャン上限を 1GB に制限する例
bq query --use_legacy_sql=false \
  --maximum_bytes_billed=1000000000 \
  'SELECT user_id FROM `my_dataset.access_logs` WHERE event_date = "2026-06-01"'

特に個人事業主や少人数のチームでは、上限を「少し低すぎるかな」と感じるくらいに設定しておくのがおすすめです。引っかかったときに上げればよいだけで、事故ったときの痛手とは比較になりません。

AIに渡す対象・範囲を絞る

生成・推論のコストは、AIに渡すデータ量で決まります。

要約・分類は 必要な行・カラムだけ に絞ってから関数に渡す
一度処理した結果はテーブルに保存し、同じデータを何度もAIに投げ直さない
まずサンプル（数十件）で精度を確かめ、満足してから全件に広げる

「AIに全部やらせる」より「下ごしらえしてからAIに渡す」ほうが、結果として安くて精度も安定します。

まとめ

Gemini in BigQuery のコストは、整理すると次の3層で考えるとシンプルです。

AI機能の利用料：話しかけること自体にコストがつきうる。必要な場面に絞る。
生成・推論のトークン料：AIに読ませるデータ量に比例。範囲を絞り、小さく試す。
クエリのスキャン料：生成されたSQLを動かすと別途発生。SELECT * と全件スキャンを避ける。

そして事故を防ぐ三本柱は、「dry_run で実行前に試算する」「上限・クォータ・予算アラートを設定する」「AIに渡す対象を絞る」。この仕組みを先に用意しておけば、「気づいたら数万円」という事態はかなり防げます。

⚠️ 注意 くり返しになりますが、本記事の金額・仕様はすべて 2026年時点の目安です。料金体系や機能名は変わることがあるため、運用前に必ず Google Cloud の公式ドキュメントと最新の料金ページで裏取りをしてください。

コスト面の基礎をもっと固めたい方は BigQueryのコストを月1万円以内に抑えるコツを、Geminiで自然言語からSQLを書く具体的な手順は Gemini in BigQueryで自然言語からSQLを書く（2026年版）を、それぞれ続けて読んでみてください。料金の不安をつぶしておけば、AIアシストは中小ECや個人事業主にとって心強い味方になってくれます。