Batch API かリアルタイム呼び出し：ワークロード別に正しいチャネルを選ぶ方法

まず2つの時間スケールを区別する

LLM 呼び出しの時間への敏感さは大きく異なります。チャット欄で返信を待つユーザーの許容度は秒単位ですが、チームの日報生成タスクの許容度は時間単位かもしれません。Batch チャネルはまさに後者のために設計されており、リクエストをキューに入れて集中処理し、より長い完了時間と引き換えに低いトークン単価を得ます。

Anthropic の [batch processing ドキュメント](https://platform.claude.com/docs/en/build-with-claude/batch-processing)と [pricing ページ](https://claude.com/pricing)はどちらも batch 価格を別途記載しています。OpenAI 側にも対応する batch と一括処理の割引があります。両者の共通点は標準価格からの割引で、違いは提出方法と完了ウィンドウにあります。

判断フレームワーク：4つの問い

1. この結果を同期的に待っている人はいるか？ はい → リアルタイム。いいえ → 次へ。
2. 結果が数時間遅れてもよいか？ よい → batch 候補。分単位必須 → リアルタイム。
3. リクエストはオフラインで列挙できる集合か？ はい（文書群、チケット群、評価サンプル群）→ batch が非常に適している。
4. 失敗時の再実行コストは高いか？ 高い → リアルタイムで即時フィードバックを得る。低い → batch で一括リトライする方が割に合う。

典型的な batch シナリオ一覧

• コンテンツ分類とタグ付け：数十万件の商品、レビュー、チケットへの統一タグ体系。
• オフラインデータクレンジング：非構造化テキストを一括で構造化フィールドに抽出。
• 回帰評価：プロンプト変更前に固定評価セットを一通り実行して比較。
• 一括要約 / 翻訳：文書ライブラリ、顧客対応記録、会議議事録のオフライン整理。
• 合成データ生成：訓練や評価用のサンプルを一括生成。

Batch の落とし穴：部分成功とリトライ

Batch ジョブは「全成功か全失敗か」ではありません。数百件のリクエストを含むジョブでは、通常いくつかがパラメータエラー、入力長超過、コンテンツポリシーなどの理由で失敗します。エンジニアリング上、次を必ず実現する必要があります：

• 結果を1件ずつ記録する。バッチ全体の成否を1つの真偽値として扱わない。
• リトライ可能と不可能を区別する：429 / 5xx はリトライ可能、400 のパラメータエラーはリトライしても無駄。
• 冪等キー：同じ業務データの重複送信が二重課金や二重書き込みを起こさないようにする。
• コストの事前試算：送信前にトークンで上限を見積もり、1回のジョブで想定外の請求が出ないようにする。

1つのゲートウェイで両チャネルを管理する

リアルタイムと batch を2つの独立したアカウント、キー、請求に分けるのは最もよくあるアーキテクチャ上の負債です。価格が変われば2箇所を直し、障害調査では2つの管理画面を行き来することになります。

Admesh のやり方は、1つの Base URL、1つのキー、1つの請求です。業務側ではタスク種別でどちらのチャネルを使うかを決め、モデルカタログと単価は常に同じバックエンド設定から取得されるため、粗利と使用量を同じ場所で確認できます。

レート制限と並行数の説明を見る →