AIの処理コストは、リクエストを「今すぐ」ではなく「24時間以内」に許容するだけで、半分にできます。Claude・OpenAI・Geminiの主要3社はいずれも、非同期でまとめて処理する「Batch API」を提供しており、入力・出力トークンの両方が標準の50%引きになります。本記事では、3社のBatch APIの料金・上限・使いどころを公式情報で比較し、どんな業務でコストを半減できるかを実装フローまで含めて解説します。
Batch APIとは？なぜ50%も安くなるのか
Batch API（バッチAPI）は、大量のリクエストを1つのファイルにまとめて送り、プロバイダ側が空いている計算資源で非同期に処理する仕組みです。リアルタイム応答を捨てる代わりに、料金が大幅に下がります。
通常の同期API（チャットのように即座に応答が返る使い方）は、応答速度を保証するためにコストが高くなります。一方Batch APIは「24時間以内に返ればよい」という前提に立つため、プロバイダは負荷の谷間に処理を回せます。この余剰資源の活用分が、利用者には入力・出力ともに50%引きとして還元されます。
重要なのは、安くなるのは「速度の妥協」と引き換えだという点です。即時性が不要な処理——大量の文書分類、議事録の一括要約、評価データの生成、過去データの再処理など——であれば、品質を落とさずにコストだけを半減できます。
Claude・OpenAI・Gemini｜3社のBatch API徹底比較
主要3社のBatch APIを、公式ドキュメントの記載に基づいて比較します（2026年6月時点）。割引率はいずれも50%で横並びですが、1バッチあたりの上限や付加機能に差があります。
| 項目 | Anthropic（Claude） | OpenAI | Google（Gemini） |
|---|---|---|---|
| 割引率 | 入力・出力とも50%引き | 入力・出力とも50%引き | 標準APIの50% |
| 処理時間の目安 | 24時間以内（多くは1時間未満） | 24時間ウィンドウ | 24時間目安（多くはより高速） |
| 1バッチの上限 | 最大10,000リクエスト | 最大50,000リクエスト（ファイル200MBまで） | インライン20MBまで／JSONLは大規模可 |
| 特徴 | プロンプトキャッシュと割引がスタック可能 | 専用の高レート枠／1時間あたり2,000バッチ作成可 | Webhook対応（batch.succeeded購読）・OpenAI互換 |
| 主な用途 | 大規模データ処理・非緊急タスク | 評価・分類・要約・合成データ生成 | 前処理・評価などコスト重視の処理 |
注目したいのはClaudeの「割引スタック」です。プロンプトキャッシュ（繰り返す共通プロンプトを安く再利用する仕組み）とBatchの50%引きを併用でき、条件が揃えば実効コストはさらに下がります（詳しくはプロンプトキャッシュ実装ガイドを参照）。OpenAIは1バッチ5万件・専用レート枠と、大量処理のスループットに強みがあります。GeminiはWebhookでバッチ完了を受け取れるため、ポーリング不要で運用を組みやすいのが利点です。
Batch APIが効く業務シーン5選
Batch APIは「即時応答が要らない、かつ量が多い」処理ほど効果が出ます。代表的なユースケースを挙げます。
| 業務 | 内容 | Batchが向く理由 |
|---|---|---|
| 文書の一括分類・タグ付け | 問い合わせ・契約書・レビューを数千〜数万件まとめて分類 | 夜間に投げて翌朝結果でよい。即時性不要 |
| 大量議事録の要約 | 蓄積した会議録・通話ログを一括で要約 | 過去分の処理は急がない。件数が多くコスト影響大 |
| AIエージェントの評価（Evals） | テストケースを大量に流して品質を測定 | 評価は非同期で十分。回数が多く割引効果が大きい |
| 合成データ生成 | 学習・テスト用データをLLMで大量生成 | 生成は時間に余裕がある。量が膨大 |
| 過去データの再処理 | 新しいプロンプトで蓄積データを作り直す | バックフィル処理は典型的な非緊急・大量タスク |
逆に、チャットボットの応答やリアルタイム検索のようにユーザーを待たせる処理にはBatchは使えません。同期APIとBatch APIを「即時性が要るか」で使い分けるのが基本設計です。
実装の基本フロー｜4ステップ
3社とも手順の骨格は共通しています。コードはプロバイダごとに異なりますが、流れは次の4段階です。
- リクエストをまとめる：処理したい問い合わせをJSONL（1行1リクエスト）などのファイルにまとめる。OpenAI・Geminiはファイルアップロード方式、Claudeも複数リクエストを1バッチにまとめて送る。
- バッチジョブを投入する：作成したファイルを指定してバッチ処理を開始。ジョブIDが返る。
- ステータスを確認する：ジョブの進捗を問い合わせる。GeminiはWebhookで完了通知を受け取ることもできるため、定期的なポーリングを省ける。
- 結果を回収する：処理が完了したら出力ファイルから結果をまとめて取得する。
非同期前提なので、アプリ側は「投げて待つ」設計にします。結果を受け取ったら後続処理（DB保存・通知・次工程の起動）につなぐ、という組み方が定石です。
導入前に押さえる3つの注意点
料金が半分になる一方で、Batch APIには設計上の前提があります。
| 注意点 | 内容 |
|---|---|
| ① 24時間ウィンドウを前提にする | 多くは1時間以内に終わるが、保証は「24時間以内」。締切のある業務には使わない |
| ② 失敗ハンドリングを設計する | 一部リクエストが失敗してもバッチ全体は進む。出力側でエラー行を検知・再投入する仕組みを用意する |
| ③ 即時系と二系統で持つ | 同じ機能でも、ユーザー対面は同期API・裏方の大量処理はBatchと役割分担する |
コスト削減シミュレーション
たとえば月間100万件のテキスト分類を回す場合を考えます。同期APIで処理して月額60万円のトークンコストがかかっていたとすると、同じ処理をBatch APIに寄せるだけで30万円程度まで下げられる計算です（割引率50%・あくまで試算で、実際はモデルや入出力量により変動します）。
Claudeでプロンプトキャッシュも併用できる構成なら、共通プロンプト部分のコストもさらに圧縮できます。「急がない処理を洗い出してBatchへ寄せる」だけで、AI運用コストの構造を変えられるのがポイントです。
まとめ｜「急がない処理」を見つけることがコスト最適化の第一歩
Batch APIは、Claude・OpenAI・Geminiのいずれも入出力50%引きという強力なコスト削減策です。割引率は横並びなので、選定は「既存スタックとの相性」「1バッチの上限」「プロンプトキャッシュとの併用可否（Claude）」「Webhook運用のしやすさ（Gemini）」で判断します。
まず取り組むべきは、自社のAI処理のうち「即時応答が不要なもの」を棚卸しすることです。評価・分類・要約・データ生成といった裏方の大量処理は、たいてい24時間待てます。そこをBatchに寄せるだけで、品質を落とさずコストを半減できます。さらにタスクの複雑度に応じてモデルを使い分けるモデルルーティング設計と組み合わせれば、コスト最適化の効果は一段と高まります。
