Batch APICost OptimizationLLM API

LLMバッチAPI完全ガイド：半額で数百万トークンを処理する方法（2026年版）

約1分

毎晩5,000リクエストを処理し、所要2時間のジョブがあり、出力を誰も翌朝まで見ない——そんなケースを想像してください。しかも、そのジョブにリアルタイム価格を支払っています。なぜなら、いつの間にか「API」が「同期API」になり、50%割引のバッチエンドポイントがアーキテクチャに組み込まれることはなかったからです。

これは2026年のLLM予算で最も多いコスト漏れです。遅延を許容できるワークロードにリアルタイム料金を支払っているのです。現在、主要プロバイダーはすべて非同期ワークロードを約**50%**割引します——LLMバッチAPI市場は半額で標準化されました。OpenAIのバッチAPIは約24時間の完了ウィンドウ、AnthropicのMessage Batchesは約1時間のウィンドウ、Geminiのバッチティア、そしてDeepSeekは同じアイデアをピーク/オフピーク価格に組み込んでいます。見逃されたままの節約分があります。このガイドはそれを取り戻すためのものです。バッチAPIとは何か、プロバイダー別の比較表、そのまま使えるワークフロー、バッチとリアルタイムの判断基準、そしてバッチの節約をキャッシュとルーティングで積み重ねる組み合わせの計算です。

バッチAPIとは

要点：バッチとは「今送信して、後で回収し、半額を支払う」こと——主要プロバイダーはすべて同じ形に標準化されています。

仕組みはどこでも同じです。リクエストのファイル（JSONL）を送信すると、プロバイダーがキューに入れ、キャパシティに余裕があるときに処理し、バッチが完了した時点で結果を受け取ります。ストリーミングもインタラクティブなレイテンシもありません——割引は柔軟性への対価です。

2026年のプロバイダー別比較表：

プロバイダー割引完了ウィンドウ備考
OpenAI約50%約24時間リファレンス実装
Anthropic約50%約1時間4社の中で最速のウィンドウ
Gemini約50%フレキシブルティアバッチはFlex推論ティアに対応
DeepSeekオフピーク価格ピーク/オフピークウィンドウ時計ベースで同じアイデアを実装、2026年8月より有効

プロバイダー間比較が詳細を追跡しています。パターンは同一です——待てるなら半額です。

バッチ処理で実際にコストが削減される理由

要点：請求書で最大の項目を50%オフにするのは、最適化ではなく価格設定の決定です。

計算は意図的に退屈なものです。月額請求が$1,000で、その60%が遅延許容ワーク（eval、インデックス作成、エンリッチメント、夜間生成）だとします。その$600をバッチに移すと：**月$300、年間$3,600の節約、品質の変化はゼロ。**出力トークンは同一で、違うのは到着するタイミングだけです。

この計算を正直に保つ注意点が2つあります：

  1. **割引はプラットフォームレベルではなく、プロバイダーレベルで適用されます。**統合エンドポイントは基盤となるプロバイダーと同じ請求を行います——バッチ料金はバッチ料金のまま透過されます。当社のコスト最適化プレイブックで全レバーのスタックを解説しています。バッチはエンジニアリングコストが最も低いレバーです。
  2. **バッチは無料ではありません。**半額になるだけです。残りの半分は依然としてキャッシュとルーティングの恩恵を受けます——これが後述のセクション5で扱う積み重ねの計算です。

バッチワークフローの構築方法

要点：ワークフローは4つのパーツ——送信、冪等性、回収、リカバリ——で構成され、リカバリが誰もがスキップするパーツです。

プロバイダー非依存の骨組みです——リクエスト形式はchat completionsエンドポイントのドキュメントに従います：

import json
from openai import OpenAI

client = OpenAI()  # point at your provider or unified endpoint

# 1. Build the JSONL request file
with open("batch.jsonl", "w") as f:
    for i, task in enumerate(tasks):
        f.write(json.dumps({
            "custom_id": f"task-{i}",          # idempotency key — never omit
            "method": "POST",
            "url": "/v1/chat/completions",
            "body": {"model": "gpt-4o-mini", "messages": task["messages"]},
        }) + "\n")

# 2. Submit once — the custom_id makes retries safe
batch = client.batches.create(input_file=upload(batch_path), endpoint="/v1/chat/completions")

# 3. Poll or webhook until complete, then map results back by custom_id
# 4. Recover: failed rows get re-queued into the NEXT batch, not re-run inline

本番グレードを維持する4つのルール：

  1. **custom_idが契約です。**冪等性こそがリトライを安全にします。これがないと、送信中にネットワークが一時的に途切れただけで処理が重複し、請求が2倍になります。
  2. **順序ではなくIDで回収します。**バッチの結果は任意の順序で到着します。custom_idを自社のレコードにマッピングしないと、ジョインを2回間違えて書くことになります。
  3. **スケールではWebhookがポーリングに勝ります。**完了コールバックが「5分ごとにチェック」ループを置き換えます。エラーコードのリファレンスが、どの失敗がリトライ可能かを示します。
  4. **リカバリはキューであって、ハックではありません。**失敗した行は次のバッチサイクルに戻します。失敗をインラインで再実行するチームは、バッチのレート制限を痛い目を見て発見するチームです。

選択方法：バッチ vs リアルタイム

要点：判断は1つの質問——この処理は待てるか？——に集約され、答えが常に「いいえ」となる明確な例外が2つあります。

判断ルールを率直に述べると：

  • 処理は1時間待てますか？ バッチにします。
  • 1日待てますか？ ウィンドウが最も安く合うプロバイダーのバッチにします。
  • ユーザーが待っていますか？ 絶対にバッチにしません。
  • エージェントループですか？ 絶対にバッチにしません。

2つ目の例外は強調に値します。エージェントループはトークン量だけを見るとバッチ候補に見えますが、そのリクエストは因果的に連鎖しています——各呼び出しが直前の呼び出しに依存します——つまり構造上インタラクティブです。本シリーズのボイスエージェントやサポートチャットボットのアーキテクチャも同じ理由でインタラクティブです。バッチは期限のある並列化可能な処理のためのもので、その範囲は多くのチームが考えるよりも狭いものです——だからこそ、適用できる場面での50%割引は一層価値があるのです。

節約の積み重ね方：バッチ × キャッシュ × ルーティング

要点：バッチ、キャッシュ、ルーティングは掛け算になります——予算重視モデルでキャッシュ済みプレフィックスを再利用するバッチジョブは、素朴な実装の数分の一のコストで済みます。

3つのレバーは重複しません。だからこそ積み重ねられるのです：

  1. バッチ——遅延許容ワークの基本レートから50%オフ。
  2. プロンプトキャッシュ——キャッシュ済み入力プレフィックスは約0.1倍。バッチジョブは理想的なキャッシュワークロードです。同じテンプレートが何千回も実行されるため、バイト単位で安定したプレフィックスはほぼ毎回ヒットします。キャッシュガイドに仕組みがあります。バッチとの相乗効果こそが掛け算の要です。
  3. ルーティング——バッチのモデルティアもルーティングの決定です。フロンティアを測定しているからevalはフロンティアモデルで、誰も読まないからエンリッチメントは予算重視モデルで。本番最適化ドキュメントでルーティングの仕組みを解説しています。

計算例：夜間エンリッチメントジョブで10Mトークン。ミッドティアモデルの基本レート：$30。バッチ：$15。同じジョブで入力側のプレフィックスが安定して0.1倍のキャッシュにヒットする場合（トークンの80%がキャッシュされると仮定）：およそ**$4-6**。同じジョブ、同じ出力品質、1つのルーティング設定と1つの安定したプロンプトテンプレートで実現できます。クイックスタートでパイプラインを数分で接続できます。掛け算の部分こそが複利のように効いてくるのです。

請求額を膨らませるよくあるミス

要点：割引を無効にする4つの方法——それぞれが静かに50%を100%に戻します。

  1. **失敗した行で評価する。**evalはバッチの完了済み行だけに対して実行しましょう。失敗行はデータ品質の問題であり、含めると最適化の対象になる偽のスコアが生成されます。本シリーズのテストガイドのCIスタイルのeval規律がそのパターンを示しています。
  2. **結果を失効させる。**バッチの結果には保持ウィンドウがあります。休暇中に完了し、回収前に失効したジョブは、出力なしの全額ジョブです。回収はカレンダーではなく完了イベントに結び付けましょう。
  3. **バッチ固有のレート制限を無視する。**バッチのクォータはリアルタイムのクォータとは別です——同じ制限だと想定したチームは、バッチ実行中に自らの上限を発見します。
  4. 冪等性を省略する。custom_idがなければ、安全なリトライもリカバリ経路もありません——省略できる最も高価な4文字です。

FAQ

バッチAPIは実際にどれくらい節約できますか？

OpenAI、Anthropic、Geminiのバッチティアで約50%です。DeepSeekは時計ベースの同等仕組みとしてピーク/オフピーク方式を採用しています。節約はトークン単位なので、遅延許容ボリューム——ほとんどの請求書で最大の項目——に比例して拡大します。

バッチの完了にはどれくらい時間がかかりますか？

OpenAIは約24時間、Anthropicは約1時間、GeminiはFlexティアに連動し、DeepSeekのオフピークウィンドウは時計によって定義されます。期限に合うウィンドウのプロバイダーを選びましょう。割引は同じです。

バッチモードでevalを実行できますか？

はい——evalはバッチワークロードの定番です。完了済み行だけに対して実行し、キャッシュヒットのためにプロンプトテンプレートをバイト単位で安定させ、完了バッチのスコアでCIをゲートしましょう。

バッチはプロンプトキャッシュと併用できますか？

非常に相性が良いです——バッチジョブは同じテンプレートを何千回も繰り返すため、理想的なキャッシュプロファイルです。安定したプレフィックス＋バッチ＝本ガイドで解説した割引の積み重ねです。

絶対にバッチにしてはいけないワークロードは？

ユーザーが待つもの、そして因果的に連鎖するものすべてです——エージェントループやインタラクティブなボイス/チャットは構造上リアルタイムです。バッチの判断基準は「大きいか」ではなく「待てるか」です。

統合エンドポイントはバッチ割引を透過しますか？

はい——バッチ料金はプロバイダー料金であり、エンドポイントはプロバイダーと同じ請求を行います。割引はそのまま維持されます。エンドポイントの役割は1つのキーと1つのダッシュボードを提供することです。50%はプロバイダーのものであり、そのまま流れます。

まとめ

2026年のLLMバッチAPIの状況は驚くほど標準化されています。主要プロバイダーすべてで約50%オフ、唯一の差別化要因は完了ウィンドウです。戦術は機械的です——ワークロードの遅延許容部分を見つけ、バッチに移し、プレフィックスを安定させ、タスクごとにモデルティアをルーティングする——そしてバッチ、キャッシュ、ルーティングの組み合わせで、素朴な請求額より定常的に60〜80%低く抑えられます。割引は放置されたままです。問題は、あなたのアーキテクチャがそれを受け取るかどうかだけです。

請求額の遅延許容部分60%を取り出して半減させましょう。TokSpan APIキーを取得して——初回バッチに使える$5無料——ジョブごとのコストで節約を実感してください。