API料金が半額になるのは魅力的です。ただし、必要な締め切りを過ぎてから結果が届くなら、その安さに意味はありません。OpenRouterのBatch APIは、オフラインのテキスト処理や埋め込み生成には適していますが、対話的なリクエスト向けではありません。非同期で動作し、完了までの枠は24時間。しかも、目玉の割引が請求内のすべての項目に同じように適用されるわけではありません。
判断はシンプル:待てる処理ならBatch API
ラベリング、評価、埋め込み、蓄積したデータの要約など、結果を待てる定型的な処理にはOpenRouter Batch APIを使う価値があります。一方、ユーザー向けチャット、IDEエージェント、Web検索を組み込んだワークフロー、マルチモーダルなリクエストは、同期APIのままにしておくべきです。
OpenRouterによれば、Batchでは70種類を超えるモデルで、通常よりトークン単価が概ね50%低くなります。正式な完了枠は24時間です。ローンチ発表では、ベータ期間中の実績として中央値7分、90%が1時間以内に完了したとされています。ただし、これはSLAではなく観測値です(公式発表)。
「50%オフ」の対象を取り違えない
割引の主な対象は、モデルのトークン料金です。推論にかかる請求項目すべてが一律で安くなるわけではありません。
| 料金・制御項目 | Batch APIでの扱い |
|---|---|
| 入力・出力トークン | 通常のモデル料金のおおむね50% |
| Web検索呼び出し | 公式quickstartによると通常料金で請求 |
| プロンプトキャッシュ | モデルごとに異なるため、モデルページで確認 |
| BYOK推論 | 推論料金はプロバイダーが直接請求し、OpenRouterはBYOK手数料を別途表示 |
| 正確な適用料金 | 個別のモデルページと完了済みバッチの利用状況で確認 |
Will Cyganによるバッチ処理コストの解説では、Claude Sonnet 5の例として、入力1,000万トークン・出力200万トークンの処理が、同期では$40、バッチでは$20になると示されています。これはあくまで特定モデルでの計算であり、すべてのモデルに当てはまる料金表ではありません。
「バッチ経由では、同期レートのちょうど半額で請求される。」— Will Cygan, Batching (LLM Inference)
プロバイダーとモデルを確認する前に、削減額を予算へ織り込むべきではありません。実際に@fogelmaniaは、あるベータモデルで、バッチ処理が別のプロバイダーに振り分けられたため、同時実行した同期呼び出しより高額になったと報告しています:@fogelmaniaの投稿。これはすべてのモデルで同じ現象が起きる証拠ではなく、完了後の実コストを必ず確認すべきだという警告として捉えるべきでしょう。
Batch APIは高速なエンドポイントではなくジョブ処理
OpenRouterのBatch API発表とquickstartでは、即時応答ではなくジョブ型のワークフローとして説明されています。送信が成功すると、HTTP 202 Accepted、ステータスvalidatingのバッチIDが返されます。通常は次の状態をたどります。
validating → in_progress → finalizing → completed
このほかの終端状態は、failed、expired、cancelledです。ワーカー側では対話リクエストを開いたまま待つのではなく、バッチIDを永続化し、終端状態になるまでポーリングする設計にします。
OpenRouterはベータ期間に23万件超のバッチを処理し、完了時間の中央値は7分、90%は1時間以内だったと報告しています。ローンチ当日のある時点では、@luismmolinaも5〜8分だったとテスト結果を投稿しています(テスト投稿)。ただし、こうした観測値を24時間という計画上の境界の代わりにはできません。
手戻りを減らす実装パターン
現行のquickstartでは、JSONLファイルのアップロードではなく、インラインJSONのrequests配列を使います。各行には一意なcustom_idが必要です。このIDによって、完了した回答またはエラーを元のレコードへ対応付けます。
最小限のリクエスト形式は次のとおりです。
{
"endpoint": "/v1/chat/completions",
"model": "openai/gpt-4o",
"requests": [
{
"custom_id": "ticket-0001",
"body": {
"messages": [
{"role": "user", "content": "Classify this ticket: ..."}
]
}
}
]
}
quickstartで案内されている送信先はPOST https://openrouter.ai/api/beta/batchesです。トップレベルのエンドポイントとモデルはバッチ全体に適用されるため、API形式やモデルが異なる処理は別バッチに分ける必要があります。対応する形式には、Chat Completions、Responses、Anthropic Messages、Embeddingsがあります。
送信後はGET https://openrouter.ai/api/beta/batches/:idをポーリングします。完了したバッチでは結果がインラインで返ります。各結果にはresponseまたはerrorのいずれかが含まれ、request_countsには全件数、完了件数、失敗件数が分けて記録されます。失敗した行はcustom_id単位で再試行し、バッチ全体を機械的に再実行しないようにしましょう。
データポリシー、BYOK、URLアセットの扱いからプロバイダーの挙動が重要になる場合は、最安プロバイダーへの自動ルーティングに任せず、ドキュメント化されているプロバイダー制御で固定してください。本番導入前に、選択したモデルとプロバイダーで利用可能なBatch経路があることも確認します。
Batch APIがワークフローに合わないケース
quickstartの制限事項を見ると、Batchはテキスト中心のワークフローです。バッチリクエストでは画像、音声、動画、ファイルのコンテンツパートを受け付けません。Base64およびdata: URIのアセットは拒否され、対応するURLアセットはプロバイダーにより異なります。OpenRouter独自のWeb検索プラグインもBatchでは利用できません。
ユーザーが応答を待っている場合、モデルがローカルアップロードを読み取る必要がある場合、音声・動画を扱う場合、あるいは秒単位の応答時間目標が求められる場合は、同期APIを使います。
料金例:割引が本当に効く条件
入力1,000トークン、出力200トークンを使うサポートチケットが10,000件あるとします。合計は入力1,000万トークン、出力200万トークンです。
| 経路 | 入力 | 出力 | 合計 |
|---|---|---|---|
| 同期処理の例 | 10M × $2 = $20 | 2M × $10 = $20 | $40 |
| バッチ処理の例 | 10M × $1 = $10 | 2M × $5 = $10 | $20 |
名目上の削減額は1回あたり$20です。この例を毎週実行するなら、年間では$1,040の削減になります。ただし、復旧対応、監視、緊急時の同期フォールバックに名目上の差額以上のコストがかかるなら、実効的な削減額は小さくなります。
そのための余力も判断に入れてください。締め切りが厳格なら、24時間の完了枠と、対象を絞った再実行または同期フォールバックに残せる時間を比較します。トークン単価が安くても、締め切り後では使えないバッチは、その業務プロセスにとって安価とはいえません。
FAQ
OpenRouter Batch APIは常に半額ですか?
いいえ。OpenRouterはこの割引を、一般的かつモデル依存のものとして説明しています。Web検索の料金は通常どおりで、キャッシュの扱いはモデルにより異なり、BYOKではプロバイダーの推論費用とOpenRouterの手数料が分かれます。
OpenRouterのバッチはどれくらいで完了しますか?
サポートされる完了枠は24時間です。ベータ時の処理時間報告は参考になりますが、保証されたサービスレベルではありません。
JSONLをアップロードしたり、複数モデルを混在させたりできますか?
quickstartでは、インラインJSONのrequests配列を受け付けます。モデルとAPI形式はバッチ全体に適用されるため、モデルやエンドポイント形式が異なる場合は別々のバッチが必要です。
失敗した行だけを再試行できますか?
はい。完了済みバッチから行単位のエラーが返った場合は、各行のcustom_idを使って小さな再試行バッチを作れます。ただし、バッチ全体の失敗、期限切れ、キャンセルは、結果を取得できない可能性があるため別途扱う必要があります。
Batchと同期APIはどう使い分けるべきですか?
急ぎではないバックグラウンド処理にはBatchを選びます。結果が進行中のユーザー操作に含まれる場合や、未対応のモダリティ・ツールが必要な場合は、同期推論を選んでください。
実務上の結論:Batchは対象を選んで使う
ワークロードを移す前に、次の5点を確認しましょう。
- モデルページで、対象プロバイダーに対応したBatch経路が表示されている。
- 業務プロセスが24時間の完了枠を許容できる。
- すべての行に安定した
custom_idがあり、再試行計画がある。 - アプリケーションが完了済みの実利用量と実コストを記録している。
- 入力と結果に、それぞれの管理責任者と削除ポリシーがある。
OpenRouterのquickstartによると、バッチの入力と結果は、より早く削除しない限り30日間保持されます。不要になった終端状態のバッチは削除してください。
最初に移行するなら、顧客向けの経路ではなく、内容が固定されレビュー可能なコーパスが最適です。回答の遅延コストがトークン割引による節約を上回る場所に、いきなり導入すべきではありません。