BigQueryトークン割り当てが一般提供を開始、管理者が生成AI関数の日次トークン上限を設定可能

BigQueryトークン割り当てでできること

BigQueryトークン割り当てでは、1日あたりの上限をプロジェクト単位とユーザー単位で設けられます。ユーザー単位の上限は、組織全体ではなく、プロジェクト内の各ユーザーに適用されます。^[1]

図1　BigQueryトークン割り当てでできること

4つの割り当ては、Google Cloud Identity and Access Management（IAM）の割り当ての仕組みで管理する形です。各割り当ての1日の既定値は以下の通りです。^[1][2]

出力の割り当てには、内部の推論ステップで生成される思考トークンも含まれます。Geminiプラットフォームの請求と同じ扱いです。

BigQueryトークン割り当ての設定手順

管理者は、Google Cloudコンソールで割り当てを確認し、ワークロードの変化に合わせて変更できます。変更にサポートケースの作成は必要ありません。^[1]

図2　コンソールで扱う生成AIトークン割り当て

Quotas & System Limitsのページには、生成AIトークン割り当ての日次・プロジェクト単位の使用量が表示されます。7日や14日、30日、カスタムの期間を選べるグラフは、急増の検出や予算の見直し、新しい生成AIワークロードやデータパイプラインが全体の使用量に与える影響の確認に使えます。

Edit quotaでの上限の変更

生成AIのトークン割り当ては、IAM & Admin → Quotas & System Limitsのページにあります。変更は、必要なロールを持つ管理者がBigQuery APIで絞り込み、Name列で4つのAI割り当てを先頭に出して編集する流れです。

図3　Quotas & System Limitsでの変更手順

費用管理を厳しくしたい場合に割り当てを下げる変更は、承認なしですぐに反映されます。引き上げは同じページから申請でき、多くは自動で承認され、大きな引き上げは短い審査を経る場合があります。

AI.COUNT_TOKENSでの測定

AI.COUNT_TOKENS関数は、割り当ての値を選ぶ前に、モデルへ送る入力データの量を見積もる用途で使えます。AI.COUNT_TOKENSが返す数は入力トークンの下限で、出力や思考のトークン、AI関数が加える指示、画像などの入力は含みません。

図4　AI.COUNT_TOKENSの数に含まれないもの

AI.COUNT_TOKENSは、課金対象の生成を呼び出さずに、モデルのトークナイザーが生成するトークン数を返します。商品レビューの入力トークンを合計するコードは、以下の通りです。

-- Count the input text tokens for each product review
SELECT
  SUM(
    AI.COUNT_TOKENS(
      CONCAT('Classify the sentiment of this review as positive, negative, or neutral: ', review_text),

      endpoint => 'gemini-3.1-flash-lite').result) AS total_input_tokens
FROM
  `my_project.my_dataset.product_reviews`;

公式資料からの抜粋：Predictable AI spend in BigQuery: Introducing cost management for generative AI functions（Sizing your input data: AI.COUNT_TOKENS）。対象版・範囲：一般提供（GA）発表時の公式例。

上記のコードでは、レビュー本文の前に感情分類の指示文を付け、endpointにgemini-3.1-flash-liteを指定して数えています。結果をSUMで合計し、total_input_tokensとして返す例です。

予算からトークン割り当てを求める計算例

Gemini 3.1 Flash-Liteモデルの発表時点の公開価格は、BigQueryのバッチ処理による50%割引を反映し、入力が100万トークンあたり0.125ドルです。出力（応答と推論）は、100万トークンあたり0.75ドルに設定されています。

図5　Gemini 3.1 Flash-Liteで1日約100ドルの例

Gemini 3.1 Flash-Liteを使い、小さな試行で入力と出力の比が平均100対1なら、1日の入力は約7億5,400万トークン、出力は約754万トークンです。AI input tokens per dayとAI output tokens per dayをこの値に設定すると、プロジェクトの費用を1日100ドル付近に保つ計算です。

価格の異なるモデルを1つのプロジェクトで使う場合、Google Cloudはモデルごとの予算か、料金を混ぜた計算を挙げています。トークンから金額への換算も、利用するモデルの公開されたGeminiプラットフォームの価格で行う形です。

BigQueryトークン割り当ての仕様

BigQueryの生成AI関数向けトークン割り当ては、一般提供（GA）の機能です。割り当てはグローバルで、使用量はリージョンを問わず合算される仕組みです。^[1]

図6　生成AI関数向け割り当ての条件（GA）

トークンに基づく費用管理は、発表時点で利用できます。1日の割り当ては、太平洋時間の午前0時にリセットされます。^[1][2]

キャッシュに保存されたトークンは、割り当ての対象外です。割り当ては数百万トークン単位で追跡され、それ未満の値は完全に正確には反映されない可能性があります。

プロビジョンド スループットでGemini Enterprise Agent Platformモデルを使う場合、課金はトークンの使用量に基づきません。クエリの不要なブロックを避けるため、割り当てを高い値に設定する必要があります。

割り当てを管理するロール

割り当てを管理するには、次のいずれかのロールが必要です。

割り当ては、Cloud Quotas APIやgcloud CLI、Terraformからプログラムで管理することもできます。複数のプロジェクトへ同じ歯止めを適用する方法です。

対象となる生成AI関数

割り当ては、LLMによる生成を行う次のBigQuery関数に適用されます。

エンベディング関数は、別の大幅に安価なモデルで動くため、生成AI関数向けのトークン割り当ての対象外です。対象外の関数には、AI.GENERATE_EMBEDDING（ML.GENERATE_EMBEDDINGとしても利用可能）やAI.EMBEDなどがあります。

QuotaExceeded時の動作

割り当ては新しいLLM呼び出しを止める形で適用され、クエリの成否は関数で異なります。開始前にQuotaExceededエラーで拒否されるのは、必要な割り当てが使い切り済みの場合だけです。

図7　実行中に割り当てが尽きたときの結果

必要な割り当てが使い切られていなければクエリは開始され、途中で尽きるとBigQueryは新しいLLM呼び出しを送りません。実行中のクエリが1日の割り当てを使い果たすと、生成AI関数を使う後続のクエリは、その割り当てのリセットまでQuotaExceededエラーで失敗します。

図8　開始前と実行中の割り当て切れの扱い

AI.IFのようにmax_error_ratioに対応する関数は、未処理の行が比率内なら部分的な結果を返し、超えると失敗する仕組みです。AI.GENERATEのような汎用の関数は途中で尽きても成功し、スキップされた行は生成値を持たず、statusフィールドに割り当て超過のエラーが入ります。

BigQueryトークン割り当てと費用管理手段の選び方

生成AI関数の費用の歯止めには、BigQueryトークン割り当てのほかに、Cloud Billing spend capsもあります。BigQueryトークン割り当ては予防的なAI専用の仕組みで、実行中のトークン使用量を追跡し、上限近くで新しいLLM呼び出しを止めます。^[1]

図9　トークン割り当てとspend capsの仕組みの違い

spend capとの使い分け

Cloud Billing spend capsは、プロジェクトやサービスの単位で金額を基準に動き、しきい値に達すると使用を自動でブロックできる仕組みです。ただし適用は即時ではないため、一部の超過が発生します。

図10　Google Cloudが勧める使い分け

Google Cloudは、トークン割り当てをAI費用の最初の防御線として勧めています。spend capはプロジェクト全体の安全網とするのが、同社の推奨です。

Google Cloudが挙げる進め方

Google Cloudは費用管理の進め方として、以下を挙げています。

出力トークンは割高です。日本で日次の上限を運用する場合、編集部は太平洋時間の午前0時のリセットを基準に使用量の確認時刻を決める方法を勧めます。