BigQueryの生成AI機能、歯止めなく使うと一体いくらかかるのか。Googleが用意した「1日の上限」4種を確かめる

まず初めに

SQLから生成AIを呼べると、請求額は処理する行数とトークン数に左右される。今回Googleが説明したのは、4つの日次クォータを企業の予算に合わせて下げる方法だ。既定値は存在するがかなり大きく、そのままで各社の予算を守れるとは限らない。実際に予算を超えた利用者がどれほどいたか、公式記事に数字はない。便利な関数に、歯止めを自分で調整する仕事まで付いてくるのは、なかなか手間のかかる話だ。※個人の感想です

何が起きているのか

Google CloudのソフトウェアエンジニアTushar Jaiswal氏とデベロッパーアドボケイトのAlicia Williams氏は2026年10月14日、公式ブログに「Predictable AI spend in BigQuery: Introducing cost management for generative AI functions」と題した記事を公開しました。記事によれば、BigQueryの生成AI関数(AI.GENERATE、AI.IF、AI.CLASSIFY、AI.SCOREなど)は、SQLのクエリから大規模言語モデル(LLM)を直接呼び出せる機能で、1回のクエリで数百万件のサポート問い合わせを分類したり、商品レビューごとに感情を判定したりできます。ただし、これらの関数はトークン(AIが処理する文章の単位)数に応じて課金されるため、大量のデータに適用すると費用が膨らみやすいという課題があったとしています。

今回の記事は、Googleが最近一般提供(GA)を発表した「トークン単位のコスト管理機能」を解説するものです。記事によれば、この機能はGoogle CloudのIAMあいえーえむ(Identity and Access Management、権限管理の仕組み)のクォータ(利用量の上限)機能を使い、4つの日次クォータを管理者が設定できます。「AI input tokens per day」はプロジェクト全体の入力トークンの上限で既定値は1日2,000億トークン、「AI input tokens per day per user」はユーザーごとの入力トークンの上限で既定値は1日1,500億トークンです。出力側も同様に、「AI output tokens per day」がプロジェクト全体で既定値1日200億トークン、「AI output tokens per day per user」がユーザーごとで既定値1日150億トークンとなっています。人間からすると気が遠くなる桁数だが、これはあくまで既定の「上限」であり、費用の予算に合わせて必要なら引き下げるものだ。

記事は、クォータの重要な特徴として、この上限が「グローバル」であること、つまり全リージョンの利用量を合算して計算される点を挙げています。これにより、気づかないうちに特定のリージョンだけで費用が積み上がる事態を防げるとしています。また、出力側のクォータには、AIが推論に使う「思考(thinking)トークン」も含まれる点も明記されています。対象となる関数はAI.GENERATE、AI.GENERATE_TABLE、AI.GENERATE_TEXT(別名ML.GENERATE_TEXT)、AI.CLASSIFY、AI.IF、AI.SCORE、AI.AGGの7種類で、文章の意味をベクトルに変換する「埋め込み(embedding)」関数(AI.GENERATE_EMBEDDINGやAI.EMBEDなど)は、より安価な別のモデルで動作するため対象外とされています。

管理方法については、Google Cloudコンソールの「IAM と管理」→「Quotas & System Limits」でBigQuery APIを選び、該当するクォータを引き下げる場合は、承認なしにすぐ反映されるとしています。利用量を増やす場合は同じ画面から増加を申請でき、多くは自動承認されるものの、大きな増加には簡易な審査が入るとしています。必要な権限は、Owner・Editor・Quota Administrator(roles/servicemanagement.quotaAdmin)・Service Usage Admin(roles/serviceusage.serviceUsageAdmin)のいずれかです。Cloud Quotas APIやgcloud CLI、Terraformを使えば、複数プロジェクトへ同じ上限を一括で適用することもできるとしています。

なぜ重要なのか

今回の機能が重要なのは、AIをSQLから直接呼び出せる便利さと、費用の予測しやすさを両立させる仕組みを、Google自身が「予防的(preventive)」な管理策として位置づけた点です。記事は、クラウドの請求上限(スペンドキャップ)という既存の仕組みと今回のトークンクォータの違いも説明しています。請求上限はドル単位でプロジェクト・サービスごとに設定し、しきい値に達すると利用を止めますが、即時には止まらないため多少の超過が発生することがあるとしています。一方、トークンクォータはAI機能に特化して、クエリの実行中に上限へ近づいた時点で処理を止める仕組みであり、記事は「まずトークンクォータでAI費用を管理し、プロジェクト全体の安全網として請求上限を設定する」という使い分けを推奨しています。

上限に達した際の挙動も細かく説明されています。必要なクォータが既に尽きている場合、クエリは実行前に「QuotaExceeded」エラーで拒否されます。実行中に尽きた場合、max_error_ratio(許容する失敗率)に対応する関数(AI.IFなど)は、未処理行がその比率内であれば部分的な結果を返し、超えれば失敗します。一方、AI.GENERATEのような汎用関数は処理自体は成功扱いとなり、スキップされた行には生成値が入らず、status列にクォータ超過のエラーが記録される仕組みです。この挙動の違いを理解しておかないと、クォータに達した際に想定外のデータ抜けが発生する可能性があります。

私たちへの影響

この機能は、BigQueryを使って自社データにAIを適用している企業の情報システム部門やデータ分析担当者にとって、直接関係のある話です。記事は、入力データのトークン数を実際の生成コストをかけずに数えられる関数「AI.COUNT_TOKENS」を使った見積もり方法も紹介しています。たとえばレビューごとの感情分析であれば、この関数を使って事前に入力トークン数の下限を把握し、予算に見合うクォータ値を設定できるとしています。

記事は、1日の予算をおおよそ100ドルに抑えたい場合の具体的な計算例も示しています。モデルを「Gemini 3.1 Flash-Lite」とし、BigQueryのバッチ処理による50%割引が適用された価格(入力100万トークンあたり0.125ドル、出力100万トークンあたり0.75ドル)を前提に、入力と出力の比率が100対1だったとすると、1日あたりの上限はおよそ入力7億5,400万トークン、出力754万トークンになると計算しています。この例は、トークン単価と自社の利用パターンが分かれば、おおよその予算管理が可能であることを示す一例です。約100ドルは単一モデル・想定比率・記事掲載時の単価に基づく目安であり、ドル建ての固定請求上限や、対象外のAI機能を含む全費用の停止を意味しません。

一般の個人利用者がBigQueryを直接操作する機会は多くありませんが、企業がAI活用の費用を抑えながら社内システムに生成AIを組み込んでいく動きの一つとして、間接的にサービスの使い勝手やコストに影響する可能性があります。記事は、ベストプラクティスとして「まずユーザー単位のクォータから始める」「スケールさせる前に使用量を計測する」「出力トークンの上限(max_output_tokens)にも注意する」「定期的に見直す」という4点を挙げています。

初心者が知っておくべきこと

「トークンとーくん」とは、AIが文章を処理する際の最小単位のことで、日本語・英語ともに単語よりも細かい単位に分割されます。AIの利用料金の多くは、このトークンの数に応じて課金される仕組みになっています。「クォータくぉーた」とは、ある機能やサービスについて、一定期間内に利用できる量の上限のことです。今回の記事で説明されているのは、BigQueryがSQLの中でAIモデルを呼び出す際に消費するトークン数に、管理者が1日単位の上限を設定できるようになった、という内容です。

Q. 自社がBigQueryでAIを使っているかどうかを確認するには、どうすればよいですか。 A. 出典によれば、Google Cloudコンソールの「IAM と管理」→「Quotas & System Limits」でBigQuery APIを選ぶと、AI関連の4つのクォータの現在の利用量を確認できます。社内でBigQueryを利用している場合は、情報システム部門やデータ分析担当者に確認するのが確実です。

Q. 上限に達すると、それまでの分析結果も消えてしまいますか。 A. 出典によれば、上限に達すると新しいAI呼び出しが止まりますが、すでに処理が完了した行の結果が消えるという説明はありません。汎用関数の場合、処理できなかった行は値が入らず、クォータ超過のエラーが記録されるとされています。

IT Postの見方――「便利の後払い」に慣れておく話

IT Postは、今回Googleが上限の設定方法をこれだけ丁寧に説明してきたこと自体を、歓迎すべき動きだと見ている。SQLを一行書くだけでAIが大量データを処理できる便利さは本物だが、便利さの裏側にある「桁が一つ違うだけで請求額が跳ねる」という危うさを、利用者任せにせず、具体的な数字と計算例つきで示したのは誠実な対応だろう。

とはいえ、IT Postが気になるのは、この手の「事前に予算を逆算して設定してください」という説明が、結局はAIの利用料金そのものが複雑で分かりにくいという現実の裏返しでもある点だ。入力トークンと出力トークンで単価が違い、出力には思考トークンまで含まれ、バッチ処理なら割引がある——これを使いこなせる企業と、よく分からないまま既定値のまま使い続けて想定外の請求に驚く企業の差は、今後さらに広がっていくだろう。便利な機能を提供する側が、費用の計算方法までセットで丁寧に説明する姿勢は評価したいが、そもそも計算が要らないくらい分かりやすい価格設定にできないものか、とも思ってしまう。※個人の感想です

今後どうなりそうか

記事は、トークンクォータと請求上限を併用する運用方法や、AI.COUNT_TOKENSを使った見積もり手順を中心に説明しており、今後さらに細かい制御機能が追加されるかどうかについては触れていません。IT Postでは、この機能を実際に利用した企業の事例や、追加の管理機能が発表された時点で、あらためて取り上げます。