AI APIバッチ推論の料金体系：非同期ジョブでコストを削減する方法

バッチ推論の価格設定は、応答のレイテンシを犠牲にする代わりに、トークンあたりの単価を下げるという仕組みです。ジョブを送信すると、プロバイダーは定義された期間内（通常は最大24時間）に処理を行い、同期型のリアルタイム呼び出しよりも安価に利用できます。このトレードオフが価値あるものかどうかは、ワークロードが待ち時間を許容できるかどうかに完全に依存します。

この記事では、OpenAIとGoogleが公開しているバッチAPIドキュメントに基づき、バッチ（非同期）推論と標準的な同期API呼び出しを比較し、どのような場合に非同期パスが製品のコスト削減につながるのか、その判断基準を解説します。

重要なポイント

• OpenAIとGeminiは、同期呼び出しよりも割引されたレートで非同期処理を行うバッチAPIを提供しています。レートは変更される可能性があるため、予算を立てる前に各プロバイダーの価格ページで現在の正確な割引率を確認してください。
• バッチ推論は、即時の応答を必要とせず、処理完了までの待ち時間を許容できるワークロードに適しています。具体的には、一括分類、埋め込み（embeddings）生成、オフライン評価、データセットのラベリング、バックフィルジョブなどが該当します。
• リアルタイムチャット、コーディングエージェント、対話型製品機能は、処理ウィンドウの存在によりライブユーザーインタラクションには適さないため、通常バッチ価格設定には向きません。
• 累積的なコスト削減を最大化するには、バッチ割引とモデル選定、およびプロンプト効率化を組み合わせるのが一般的です。その他の手法については、/models/rankings およびAI APIコスト削減ガイドを参照してください。

バッチ推論とは何か

同期API呼び出しは、モデルが生成を完了すると即座に応答を返します（通常は数秒以内）。この即時性に対してトークンあたりの料金を支払います。バッチ推論はこのモデルを反転させたもので、単一のリクエスト・レスポンスのやり取りではなく、リクエストのファイルやリストをジョブとして送信します。プロバイダーはジョブをキューに入れ、制御された期間内に処理を行い、完了後に結果を取得できるようにします。

これはモデル内部の新しい推論技術ではありません。商用および運用の契約形態が異なるだけです。プロバイダーは、空き容量やオフピーク時の容量に合わせてワークロードをスケジュールできるため、即時対応が必要なリクエストよりもトークンあたりの料金を安く設定できます。

OpenAIとGoogleの両社が、それぞれのAPIでこのパターンをドキュメント化しています：

• OpenAIのBatch APIリファレンスでは、アップロードされたリクエストファイルからバッチオブジェクトを作成し、ステータスを追跡し、ジョブ完了後に結果を取得する方法が説明されています（platform.openai.com/docs/api-reference/batch/object）。
• GoogleのGemini Batch APIドキュメントでも同様のモデルが説明されています。リクエストのバッチを送信し、ジョブが非同期で実行され、処理後に結果を取得します（ai.google.dev/gemini-api/docs/batch-api）。

プロバイダーによってメカニズム（ファイルベースの送信、ジョブオブジェクト、ステータス確認、結果取得）に若干の違いはありますが、根本的な形は「今送信し、後で回収し、同期型よりも安く支払う」という点で一貫しています。各プロバイダーのドキュメントは変更される可能性があるため、アカウントとモデルに適用される正確な処理ウィンドウと割引率を必ず確認してください。

2つのバッチAPIの仕組み

技術的なレベルでは、両プロバイダーとも同様のライフサイクルをたどります：

1. リクエストの準備。 処理したい個別の推論リクエストを組み立てます。通常はファイル形式です（OpenAIはカスタムIDでキー付けされたリクエストファイルを受け入れ、Geminiは構造化されたリクエストのバッチを受け入れます）。
2. ジョブの送信。 アップロードした入力を参照するバッチオブジェクトまたはジョブリソースを作成します。
3. 完了のポーリングまたは待機。 ジョブは、プロバイダーがドキュメントで定めた期間内に処理を終えるまで、状態（キューイング中、進行中、完了、または失敗）を遷移します。
4. 出力の取得。 完了後、出力ファイルまたは結果セットをダウンロードまたはフェッチし、各レスポンスをIDによって元のリクエストと照合します。

どちらのプロバイダーもバッチジョブを即座に処理するわけではありません。これこそがこの価格モデルの要点です。ジョブはユーザーのスケジュールではなくプロバイダーのスケジュールで実行され、その引き換えとして、より低いレートで一定の遅延を受け入れることになります。製品がその遅延を許容できない場合、どれだけコスト削減が見込めてもバッチ価格設定は利用できません。

バッチ価格設定でコストが削減できるケース：判断チェックリスト

ワークロードをバッチエンドポイントにルーティングする前に、このチェックリストを使用してください：

• ワークロードが非対話型か？ データセットに対する分類パス、ドキュメントコーパスの埋め込み生成、コンテンツモデレーションのスイープ、夜間の要約ジョブなどが適しています。
• 製品がドキュメント化された処理ウィンドウを許容できるか？ ユーザーや後続のシステムが数秒から数分以内に結果を必要とする場合、バッチは適していません。
• ボリュームは十分に大きいか？ バッチ割引はトークンごとに適用されるため、絶対的な節約額はボリュームに比例します。少数のリクエストでは、どちらにしても請求額に大きな影響はありません。
• タスクはべき等か、あるいは安全に再試行可能か？ バッチジョブは非同期で実行され、部分的に失敗する可能性があるため、パイプラインは再送信や部分的な完了を処理し、後続の状態を壊さないようにする必要があります。
• オーケストレーション層はすでに非同期ジョブのポーリングをサポートしているか？ このパターンを初めて構築する場合、ジョブ送信、ステータス確認、出力照合のためのエンジニアリング時間を予算に組み込む必要があります。

項目	同期API	バッチ（非同期）API
レイテンシ	通常は数秒	数分から数時間（プロバイダーの規定ウィンドウ内）
価格	標準のトークン単価	同期型より割引されたトークン単価
最適な用途	チャット、エージェント、ライブ製品機能	一括分類、埋め込み、オフライン評価、バックフィル
失敗時の対応	呼び出し時に即時エラー	ジョブレベルのステータス確認；バッチ内の部分的な失敗の可能性
エンジニアリング負荷	単純なリクエスト・レスポンス	ジョブ送信、ポーリング、出力取得ロジックが必要
出力順序	呼び出し順序と一致	呼び出し順序ではなく、カスタムリクエストIDで照合

バッチ価格設定が適さないケース

バッチ推論は、人や後続のシステムが応答を待っている場合には不向きです。これには以下が含まれます：

• 会話型エージェントおよびチャット製品。 ユーザーは処理ウィンドウの終了後ではなく、数秒での返信を期待します。
• コーディングアシスタントおよびエージェント的なコーディングワークフロー。 Claude Sonnet 5やKimi K2.7 Codeのようなモデルに基づくツールは、開発者とモデル間の密なフィードバックループに依存しており、バッチ処理を行うとインタラクションが完全に損なわれます。
• ユーザー向け機能のリアルタイムコンテンツ生成。 Nano Banana ProやVeo 3などのAPIを通じたオンデマンドの画像や動画生成など、ユーザーが進行状況インジケーターを見ているような場合。
• サービスレベルのレイテンシ要件があるもの。 たとえその要件が緩やか（例えば1分以内）であっても、バッチウィンドウは通常数時間単位で測定されるため適していません。

パイプラインの一部がリアルタイムで、一部がそうでない場合は、作業を分割してください。対話型の部分は同期API経由でルーティングし、遅延を許容できる大量の部分（夜間の再インデックス、データセットの再ラベル付け、評価実行など）をバッチエンドポイントに送ります。

実用的なリクエストの形式

OpenAIのバッチオブジェクトとGeminiのバッチAPIではスキーマが異なるため、以下は各プロバイダーのリクエスト形式の文字通りのコピーではなく、概念的な形状として捉えてください。実装前に、現在のドキュメントで正確なフィールド名とエンドポイントを確認してください。

# 1. 各リクエストにカスタムIDを付与したファイルを作成
{"custom_id": "req-001", "method": "POST", "url": "/v1/chat/completions",
 "body": {"model": "your-selected-model", "messages": [{"role": "user", "content": "Classify this ticket."}]}}
{"custom_id": "req-002", "method": "POST", "url": "/v1/chat/completions",
 "body": {"model": "your-selected-model", "messages": [{"role": "user", "content": "Classify this ticket."}]}}

# 2. バッチジョブの送信
POST /v1/batches
{
  "input_file_id": "file-abc123",
  "endpoint": "/v1/chat/completions",
  "completion_window": "24h"
}

# 3. ジョブステータスのポーリング
GET /v1/batches/{batch_id}
# ステータスを返す: queued | in_progress | completed | failed

# 4. 完了後の出力取得
GET /v1/files/{output_file_id}/content
# 各レスポンスをcustom_idで元のリクエストと照合

プロバイダーに関係なく、エンジニアリングの基本パターンは同じです。安定したIDを持つリクエストファイルを作成し、ジョブを送信し、完了をポーリングし、元のリクエストリストと出力を照合します。ジョブ自体が成功しても個別のリクエストが失敗する可能性があるため、ジョブレベルでの部分的な失敗に対する再試行ロジックを構築してください。

バッチ割引とモデル選定の組み合わせ

バッチ価格設定は一つの手段に過ぎません。AIモデルルーティングベンチマークやAI APIコスト削減ガイドで取り上げたモデルやプロンプトレベルの決定を置き換えるものではなく、それらを補完するものです。バッチ処理に適しており、かつDeepSeek V4 Flash、GLM-5.2、Gemini 3.5 Flashのような低コストモデルで処理できるタスクであれば、どちらか一方の手法をとるよりも大きな絶対的コスト削減が見込めます。大規模な一括ジョブを単一のモデルや価格帯にコミットする前に、プロバイダーのラインナップ更新に伴い相対的な価格が変化するため、/models/rankingsで現在のモデルごとの価格とポジショニングを確認してください。

バッチサポートを導入するかどうかを検討しているチームにとって、計算は単純です。遅延を許容できるタスクの月間トークン量を推定し、ドキュメント化されたバッチ割引率と現在の同期型での支出を比較し、ジョブ送信やポーリングロジックを構築するエンジニアリングコストと比較します。ボリュームが小さい場合、割引額が複雑さの増加を相殺できない可能性があります。

制限事項

この比較は、2026年7月14日時点で観察されたOpenAIおよびGoogleのバッチAPIに関する一般的なメカニズムに基づいています。正確な割引率、処理ウィンドウの長さ、モデルごとの可用性、ファイル形式の要件はプロバイダー固有のものであり、時間の経過とともに変化するため、ここでは固定値として記載していません。予算を立てたり構築したりする前に、各プロバイダーのドキュメントで現在のバッチ価格と条件を直接確認してください。また、この記事はすべてのモデルプロバイダーのバッチサポートを網羅しているわけではありません。計画を立てる前に、選択したモデルとベンダーがバッチエンドポイントを公開しているかを確認してください。

FAQ

バッチ推論は同期呼び出しよりどれくらい安いですか？ OpenAIとGoogleの両社は、標準的な同期レートに対するバッチ処理の割引を公開していますが、正確な割合はプロバイダーと時期によって異なります。節約額を見積もる前に、利用するプロバイダーとモデルの現在の価格ページを確認してください。

バッチジョブが処理ウィンドウ内に完了しなかった場合はどうなりますか？ プロバイダーのドキュメントには、ジョブのステータス（queued、in_progress、completed、failedなど）が記載されています。完了ウィンドウを超過したジョブの扱いについては、プロバイダーによって動作が異なり、変更される可能性があるため、各プロバイダーのドキュメントを確認してください。

リアルタイムチャット機能にバッチ推論を使用できますか？ いいえ。バッチジョブは数分から数時間かかる可能性のあるウィンドウ内で非同期に処理されるため、ユーザーやシステムが即時の応答を待つようなワークロードには適していません。インタラクティブな機能には同期APIを使用し、バッチエンドポイントは遅延を許容できる大量のタスクのために予約してください。

バッチ価格設定がワークロードに適しているかを評価する場合は、モデルごとの現在の料金とランキングを比較し、エンジニアリング時間をジョブ送信とポーリングロジックに割く前に、上記のチェックリストと遅延許容タスクを照らし合わせてください。