「Gemini APIで大量のプロンプトを処理したいのに、標準のAPI呼び出しだとレート制限にすぐ引っかかってしまう」「毎晩同じような要約処理を走らせているだけなのに、通常料金を払い続けるのはもったいない」——そんな悩みを抱えたことはないだろうか。
結論から言うと、Gemini APIには大量のリクエストをまとめて非同期に処理し、標準(interactive)APIの50%の料金で使えるBatch APIという仕組みが用意されている。公式ドキュメントでは「The Gemini Batch API is designed to process large volumes of requests asynchronously at 50% of the standard cost」と説明されており、https://ai.google.dev/gemini-api/docs/batch-apiで仕様が公開されている。
仮の例として、社内に溜まったFAQ1,000件をGeminiに要約させたい場面を考えてみる。標準APIで1件ずつ呼び出すと、レート制限に達しやすいうえに1,000回分の待ち時間が積み上がる。Batch APIを使う場合は、この1,000件をまとめて1つのジョブとして送信し、Gemini API側の空き状況に応じて処理してもらう形になる。即時の応答が不要な処理であれば、この方式のほうが料金と手間の両面で合理的になりやすい。
この記事では、Batch APIの基本的な仕組みから、インラインリクエストとJSONL入力ファイルによるジョブ作成手順、ステータス監視、結果の取得方法、料金とレート制限の考え方までを、公式ドキュメントに記載されている内容に沿って整理する。似た名前の非同期機能であるDeep ResearchについてはGeminiのDeep Researchの使い方で扱っているので、目的に応じて読み分けてほしい。
Gemini APIのBatch APIとは何か
【完全無料】AI×SNSで成果を出す100大特典を受け取る
AIの使い方を、SNS運用の実務につなげたい方へ。LINEで特典の案内を受け取れます。
Batch APIとは、大量のGenerateContentRequestをまとめて送信し、Gemini API側が非同期に処理してくれる仕組みのことで、公式ドキュメントでは標準(interactive)APIの50%の料金で利用できると説明されている。
公式ページでは「Use Batch API for large-scale, non-urgent tasks such as data pre-processing or running evaluations where an immediate response is not required」とあり、データの前処理や評価タスクなど、即座に結果が返ってこなくても困らない用途での利用が想定されている(https://ai.google.dev/gemini-api/docs/batch-api)。
Batch APIはGoogle AIアプリの個人向けプラン(Plus・Pro・Ultraなど)とは別物で、Gemini APIを使って開発するアプリケーションやスクリプトから呼び出す開発者向けの機能である。個人向けプランと開発者向けAPIの違いを整理したい場合はGoogle AIプランの違い|Plus/Pro/Ultraの選び方も参考になる。
Batch APIと標準(interactive)APIの違い
標準(interactive)APIとは、リクエストを送るとその場で応答が返ってくる同期的な呼び出し方式のことで、Batch APIはこれとは別枠のレート制限とワークフローを持つ非同期の処理方式として設計されている。
公式ドキュメントでは、Batch APIの目標処理時間(ターンアラウンドタイム)について「The target turnaround time is 24 hours, but in majority of cases, it is much quicker」と説明されている(https://ai.google.dev/gemini-api/docs/batch-api)。目標として24時間が示されているだけで、常にこの時間内に完了すると保証されているわけではない点は押さえておきたい。
| 項目 | 標準(interactive) API | Batch API |
|---|---|---|
| 処理方式 | リクエストごとに同期的に応答が返る | 複数リクエストをまとめて非同期に処理する |
| 料金(同一モデル比較) | 基準となる標準単価 | 標準単価の50% |
| 処理時間の目安 | 通常は数秒〜数十秒 | 目標は24時間以内、多くは短時間で完了 |
| レート制限 | モデル・ティアごとのRPM/TPM/RPD | Batch専用の同時実行数・enqueued tokens上限 |
| 向いている用途 | チャットなど即時応答が必要な処理 | 大量データの前処理・評価・非緊急タスク |
普段Gemini CLIをターミナルから対話的に使っている人にとって、Batch APIの「送信してしばらく待ってから結果を受け取る」という感覚は新鮮に感じるかもしれない。Gemini CLIの基本操作はGemini CLIの使い方 インストールから無料枠の現状まで解説で扱っている。
仮の例として、100件のプロンプトをリアルタイムのチャットボットで処理する場合は標準APIが向いているが、夜間バッチでログ1万件を分類するような処理は、Batch APIに置き換えることでレート制限との戦いを避けやすくなる。
Batch APIの対象モデルと使えるタスク
対象モデルとは、Batch APIでのバッチ処理に公式ドキュメント上で対応が明記されているGeminiモデルの一覧を指し、テキスト生成・画像生成・エンベディングなど複数のモダリティにまたがっている。
公式ドキュメントには「Batch API supports a range of Gemini models. Refer to the Models page for each model’s support of Batch API. The supported modalities for Batch API are the same as what’s supported on the interactive (or non-batch) API」とあり、対応モダリティは標準APIと同じ範囲であると説明されている(https://ai.google.dev/gemini-api/docs/batch-api)。コード例ではgemini-3.8-flashが使われている。この最新Flashモデルの特徴はGemini 3.8 Flashとは?できること・制限・旧世代Flashとの違いで整理している。
テキスト生成以外にも、embeddings向けのbatches.create_embeddingsメソッドや、Nano Banana系の画像生成モデルによるバッチ生成にも公式ドキュメントは触れている。画像生成については「you can use the Batch API to get higher rate limits in exchange for a turnaround of up to 24 hours」と説明されており、通常より高いレート制限と引き換えに、最大24時間程度の処理時間を見込む形になる。
仮の例として、ブログ記事1,000本分のアイキャッチ画像をまとめて作りたい場合、1枚ずつ標準APIで生成するよりも、Batch APIで画像生成ジョブとしてまとめて送るほうが、レート制限に引っかかりにくいと考えられる。
Batch APIを使う前に準備するもの
準備するものとは、Batch APIのジョブを送信する前にあらかじめ用意しておく必要がある、課金設定・APIキー・SDKやJSONLファイルなどの要素を指す。
料金ページのプラン比較表では、Freeプランの行に対してBatch APIの単価が「Not available」となっており、Paidプランの説明には「Batch API (50% cost reduction)」という記載がある(https://ai.google.dev/gemini-api/docs/pricing)。つまりBatch APIを使うには、課金が有効なPaidプロジェクトであることが前提になっている。
実際のジョブ作成には、Python/JavaScript/Java向けの公式SDK(google-genaiなど)か、x-goog-api-keyヘッダーを付けたREST呼び出しのいずれかを使う。対話型のカスタムアシスタントを作るGeminiのGemの作り方|設定手順・使い分け・共有時の注意点とは異なり、Batch APIはサーバー側でリクエストをまとめて処理させる機能である点を混同しないようにしたい。
仮の例として、REST経由で使う場合は事前にAPIキーを発行し、環境変数GEMINI_API_KEYとしてセットしておくと、後述のcurlコマンドをそのまま実行できる。
インラインリクエストでバッチジョブを作成する手順
インラインリクエストとは、GenerateContentRequestオブジェクトのリストをバッチ作成リクエストの中に直接埋め込んで送信する方式のことで、総リクエストサイズが20MB未満の小規模なバッチに向いている。
公式ドキュメントでは「Inline requests: A list of GenerateContentRequest objects directly included in your batch creation request. This is suitable for smaller batches that keep the total request size under 20MB」と説明されている(https://ai.google.dev/gemini-api/docs/batch-api)。出力もinlineResponseオブジェクトのリストとして返ってくる。
REST版の最小例は次のようになる。
curl https://generativelanguage.googleapis.com/v1beta/models/gemini-3.8-flash:batchGenerateContent \
-H "x-goog-api-key: $GEMINI_API_KEY" \
-X POST \
-H "Content-Type:application/json" \
-d '{
"batch": {
"display_name": "my-batch-requests",
"input_config": {
"requests": {
"requests": [
{ "request": {"contents": [{"parts": [{"text": "Describe the process of photosynthesis."}]}]}, "metadata": {"key": "request-1"} },
{ "request": {"contents": [{"parts": [{"text": "Describe the process of photosynthesis."}]}]}, "metadata": {"key": "request-2"} }
]
}
}
}
}'
実行すると「Created batch job from file: batches/123456789」のようなジョブ名が返ってくる。このジョブ名は、後述するステータス監視や結果取得のときに使うことになる。
仮の例として、社内アンケートの自由記述回答50件を一括で要約したいだけなら、インラインリクエストで十分に収まるサイズになりやすい。
JSONL入力ファイルでバッチジョブを作成する手順
JSONL入力ファイルとは、1行につき1件のリクエストを書き込んだJSON Lines形式のファイルのことで、公式ドキュメントでは大規模なリクエスト群を送る際に推奨されている方式である。
公式ドキュメントには「For larger sets of requests, prepare a JSON Lines (JSONL) file. Each line in this file must be a JSON object containing a user-defined key and a request object」とあり、各行のkeyがレスポンス側でも同じ名前で返ってくると説明されている(https://ai.google.dev/gemini-api/docs/batch-api)。JSONLファイルの例は次のとおりである。
{"key": "request-1", "request": {"contents": [{"parts": [{"text": "Describe the process of photosynthesis."}]}], "generation_config": {"temperature": 0.7}}}
{"key": "request-2", "request": {"contents": [{"parts": [{"text": "What are the main ingredients in a Margherita pizza?"}]}]}}
このファイルはFiles APIでアップロードしたうえで、file_nameを指定してバッチジョブを作成する。
curl https://generativelanguage.googleapis.com/v1beta/models/gemini-3.8-flash:batchGenerateContent \
-X POST \
-H "x-goog-api-key: $GEMINI_API_KEY" \
-H "Content-Type:application/json" \
-d "{
'batch': {
'display_name': 'my-batch-requests',
'input_config': { 'file_name': '${BATCH_INPUT_FILE}' }
}
}"
仮の例として、ECサイトの商品説明文5,000件をまとめてリライトしたい場合は、5,000行のJSONLファイルを1つ用意し、Files APIにアップロードしてからバッチジョブを作成する流れになる。
Files APIへのアップロードと制限
Files APIとは、JSONLファイルなどをGemini APIにアップロードし、Batch APIをはじめとする他の機能から参照できるようにするための仕組みのことである。
公式ドキュメントでは、JSONL入力ファイルについて「This file is uploaded using the File API. The maximum allowed file size for an input file is 2GB」と明記されている(https://ai.google.dev/gemini-api/docs/batch-api)。またレート制限ページでも、Batch API向けの制限として「Input file size limit: 2GB」「File storage limit: 20GB」が挙げられている(https://ai.google.dev/gemini-api/docs/rate-limits)。アップロード自体の詳しい手順はhttps://ai.google.dev/gemini-api/docs/filesのFiles APIページにまとまっている。
仮の例として、1件あたり平均2KB程度のリクエストを50万件JSONLにまとめると、ファイルサイズはおおよそ1GB前後になる計算になり、2GBという上限にはまだ余裕がある。実際のサイズはプロンプトの長さによって大きく変わるため、送信前にwc -cなどでファイルサイズを確認しておくと安心である。
ジョブステータスの監視方法とWebhook通知
ジョブステータスとは、送信したバッチジョブが現在どの処理段階にあるかを示す状態のことで、公式ドキュメントではPENDING・RUNNING・SUCCEEDED・FAILED・CANCELLED・EXPIREDの6種類が定義されている。
公式ドキュメントによる各状態の説明は次のとおりである(https://ai.google.dev/gemini-api/docs/batch-api)。
| 状態(state) | 公式ドキュメントの説明 |
|---|---|
| JOB_STATE_PENDING | ジョブが作成され、処理開始を待っている状態 |
| JOB_STATE_RUNNING | ジョブが処理中である状態 |
| JOB_STATE_SUCCEEDED | ジョブが正常に完了し、結果を取得できる状態 |
| JOB_STATE_FAILED | ジョブが失敗し、エラー詳細を確認する必要がある状態 |
| JOB_STATE_CANCELLED | ユーザーがジョブをキャンセルした状態 |
| JOB_STATE_EXPIRED | 実行中または待機中のまま48時間を超え、結果を取得できなくなった状態 |
ジョブ名を使って定期的にポーリングする方法のほかに、公式ドキュメントでは「Gemini now supports Webhooks for processing completions asynchronously. Instead of continuously calling GET /operations, subscribe to batch.succeeded directly」とWebhookでの通知購読も案内されている。ポーリングの間隔を自前で管理したくない場合は、こちらを検討する余地がある。
仮の例として、100件のジョブを毎晩まとめて送信している運用であれば、30秒おきにポーリングし続けるよりも、Webhookで完了通知を受け取ってから次の処理に進むほうが、サーバー負荷を抑えやすい。
バッチ処理結果を取得する方法
処理結果とは、ジョブがJOB_STATE_SUCCEEDEDになったあとにresponseフィールドから取得できる、各リクエストに対するGenerateContentResponseまたはエラー情報のことである。
公式ドキュメントでは「Once the job status indicates your batch job has succeeded, the results are available in the response field. By default, batch job results are stored and available for download for 6 weeks, before they are permanently deleted」と説明されている(https://ai.google.dev/gemini-api/docs/batch-api)。インラインリクエストで作成したジョブはinlinedResponsesとしてそのまま結果が返り、JSONLファイルで作成したジョブはresponsesFileで示されるファイルをダウンロードする形になる。
結果を確認する際は、成功したレスポンスだけでなく、行ごとにエラーが含まれていないかも見ておく必要がある。公式のベストプラクティスでも「Check the batchStats for failedRequestCount after a job completes」と、失敗件数の確認が推奨されている。
仮の例として、5,000件のJSONLバッチを流した結果、そのうち数十件だけがエラーだったというケースはあり得る。全体が成功したと思い込まず、失敗件数を確認したうえで、該当分だけ再送する運用にしておくと安全である。
Batch APIの料金と50%割引の考え方
50%割引とは、同じモデル・同じトークン数で比較したときに、Batch APIの入力単価・出力単価が標準(interactive)APIのちょうど半額に設定されている、公式料金ページ記載の価格体系のことである。
公式ドキュメントでは「Pricing: Batch API usage is priced at 50% of the standard interactive API cost for the equivalent model」と説明されている(https://ai.google.dev/gemini-api/docs/batch-api)。実際の単価は料金ページに掲載されており(https://ai.google.dev/gemini-api/docs/pricing、2026年9月21日取得時点)、モデルによって次のようになっている。
| モデル | 標準(Standard)入力/出力(1Mトークンあたり) | Batch 入力/出力(1Mトークンあたり) |
|---|---|---|
| Gemini 3.8 Flash | $0.75 / $3.75(2026年内。2027年1月1日から$1.50 / $7.50) | $0.375 / $1.875(2026年内。2027年1月1日から$0.75 / $3.75) |
| Gemini 3.1 Pro Preview(プロンプト200kトークンまで) | $2.00 / $12.00 | $1.00 / $6.00 |
どちらのモデルも、標準単価をちょうど半分にした金額がBatch単価として設定されており、公式ドキュメントの「50% of the standard cost」という説明と整合している。上記はあくまで料金ページに記載された単価であり、実際の請求額は使用したトークン数やキャッシュの利用状況によって変わる。モデル別の単価やキャッシュ料金など、Batch以外も含めた料金全体の読み方はGemini API料金の読み方2026|モデル別単価・キャッシュ・無料枠・試算で詳しく扱っている。
仮の例として、Gemini 3.8 Flashで入力100万トークン・出力50万トークンを処理する場合、標準APIでは入力$0.75+出力$1.875で合計およそ$2.625になる計算だが、Batch APIであれば入力$0.375+出力$0.9375で合計およそ$1.3125になる計算になる。実際の請求額は料金ページの最新の単価を確認したうえで見積もってほしい。
Batch APIのレート制限と同時実行数
レート制限とは、一定期間内に実行できるリクエスト数やトークン数の上限のことで、公式ドキュメントによるとBatch APIは標準APIとは別枠のレート制限を持っている。
レート制限ページでは「Batch API requests are subject to their own rate limits, separate from the non-batch API calls」としたうえで、「Concurrent batch requests: 100」「Input file size limit: 2GB」「File storage limit: 20GB」という具体的な数値が示されている(https://ai.google.dev/gemini-api/docs/rate-limits)。さらに、モデルごとに同時に処理できるenqueued tokens(バッチ処理待ちのトークン数)の上限もティア別に定められている。Gemini 3.8 Flashの場合は次のとおりである。
| 利用ティア | Gemini 3.8 FlashのBatch enqueued tokens上限 |
|---|---|
| Tier 1 | 3,000,000トークン |
| Tier 2 | 400,000,000トークン |
| Tier 3 | 1,000,000,000トークン |
ティアは課金実績に応じて自動的に引き上げられる仕組みで、料金ページのプラン説明にある「higher rate limits for production deployments」という記載とも対応している。大量のジョブを継続的に流す予定がある場合は、自分のプロジェクトが今どのティアにいるかをAI Studio上で確認しておくとよい。
仮の例として、Tier 1のプロジェクトでGemini 3.8 Flashのバッチジョブを複数同時に走らせていると、enqueued tokensの合計が300万トークンに達した時点で新規ジョブの受付が制限される可能性がある。処理量が増えてきたら、ティアアップの検討やジョブの分割が選択肢になる。
ジョブのキャンセル・削除とベストプラクティス
キャンセルとは、処理中または待機中のバッチジョブに対して新規リクエストの処理を止めさせる操作のことで、公式ドキュメントではジョブ名を指定して実行できると説明されている。
公式ドキュメントでは「You can cancel an ongoing batch job using its name. When a job is canceled, it stops processing new requests」とあり、キャンセル後はジョブの状態がJOB_STATE_CANCELLEDになる(https://ai.google.dev/gemini-api/docs/batch-api)。似た操作として削除(delete)も用意されており、「You can delete an existing batch job using its name. When a job is deleted, it stops processing new requests and is removed from the list of batch jobs」と説明されている。キャンセルは状態を残したまま止める操作、削除は一覧からも消す操作、という違いになる。
公式のベストプラクティスとしては、次のような点が挙げられている。
| 項目 | 公式ドキュメントの説明 |
|---|---|
| 入力ファイルの利用 | 大量のリクエストには常にファイル入力方式を使うことが推奨されている |
| エラーハンドリング | ジョブ完了後にbatchStatsのfailedRequestCountを確認することが推奨されている |
| 送信は一度だけ | バッチジョブの作成は冪等ではなく、同じリクエストを2回送ると別々の2つのジョブが作られる |
| 大きすぎるバッチの分割 | 中間結果を早く見たい場合は、より小さなバッチに分けることが提案されている |
仮の例として、リクエストの送信中にネットワークエラーが起きたからといって、確認せずにもう一度同じ内容を送り直すと、同じ処理が二重に走るジョブが2つできてしまう。送信前にジョブが本当に作成されなかったのかを、一覧取得(batches.list)で確認してから再送する方が安全である。
よくある質問(FAQ)
- Q1. Batch APIは無料枠(Free Tier)でも使えますか?
- 公式の料金ページでは、Batch APIの入力・出力単価はFree Tierの行が「Not available」となっており、Paidプランの特徴として「Batch API (50% cost reduction)」が挙げられています。つまり課金が有効なプロジェクトでの利用が前提となっています。
- Q2. バッチジョブはどのくらいの時間で終わりますか?
- 公式ドキュメントでは目標処理時間として24時間が示されており、多くの場合はそれより短時間で完了するとされています。ただし実行中または待機中のまま48時間を超えるとJOB_STATE_EXPIREDとなり、結果を取得できなくなります。
- Q3. インラインリクエストとJSONL入力ファイル、どちらを使うべきですか?
- 公式ドキュメントでは、総リクエストサイズが20MB未満の小規模なバッチにはインラインリクエストが適しているとされ、より大きなリクエスト群にはJSONL入力ファイルの利用が推奨されています。
- Q4. バッチ処理の結果はいつまで保存されますか?
- 公式ドキュメントによると、ジョブが成功した後の結果はデフォルトで6週間ダウンロード可能な状態で保存され、その後は完全に削除されるとされています。長期保存が必要な場合は、6週間以内に自分の環境へダウンロードしておく必要があります。
- Q5. 一度に送信できるバッチジョブの数や規模に上限はありますか?
- レート制限ページでは、同時に実行できるバッチリクエスト数の上限が100件、入力ファイル1件あたりのサイズ上限が2GB、ファイルの保存容量上限が20GBとされています。さらにモデルごとに、同時に処理待ちにできるenqueued tokensの上限もティア別に定められています。
- Q6. 同じバッチジョブを2回作成してしまったらどうなりますか?
- 公式のベストプラクティスでは、バッチジョブの作成は冪等な操作ではなく、同じ作成リクエストを2回送ると別々の2つのジョブが作られると説明されています。二重送信を避けるため、送信前後で一覧取得によりジョブの有無を確認することが推奨されます。
まとめ
Gemini APIのBatch APIは、大量のリクエストをJSONL入力ファイルやインラインリクエストとしてまとめて送信し、標準(interactive)APIの50%の料金で非同期に処理してもらえる仕組みである。目標処理時間は24時間だが、待機・実行のまま48時間を超えるとJOB_STATE_EXPIREDになる点、結果の保存期間は成功後6週間である点、同時実行数やenqueued tokensにモデル・ティアごとの上限がある点は、実際に運用する前に押さえておきたいポイントである。
即時応答が不要な大量処理を抱えているなら、まずは小規模なインラインリクエストで挙動を確認し、慣れてきたらJSONL入力ファイルでの本番運用に移行していくとよい。Batch API以外のGemini APIの使い方や料金の全体像についてはGoogle AIの使い方ガイドやGoogle AI活用事例を目的別に整理|仕事・学習・SNS運用で使う方法も参考にしてほしい。
あわせて読みたい・姉妹メディア
