Batch APIと通常の同期APIはどう使い分ける？締切と割引で判断

大量の文書を分類したり、商品説明をまとめて作ったりすると、API料金が気になってきますよね。その処理を一件ずつ人が待っていないなら、Batch APIが候補になります。まとめて依頼を送り、処理が終わってから結果を受け取る方式です。

OpenAIの公式ガイドでは、OpenAI Batch APIは同期APIより50%低い料金で、24時間の完了ウィンドウを使います。ただし、期限内に終わらなければexpiredとなり、未完了リクエストはキャンセルされます。全件の成功完了を保証するものではありません。Gemini Batch APIも標準対話料金の50%で、処理時間の目標は24時間です。実際の時間は負荷やジョブの大きさで変わり、24時間の業務締切を保証するものではありません。

ここで比べる同期APIは、通常のリクエストへその場で応答する使い方です。音声などを低遅延でやり取りする製品名の「Realtime API」とBatchの料金比較ではありません。

ただし、安くなっても締切に間に合わなければ使えません。まず「結果を何時に使うか」を決め、待てる仕事だけをBatchへ分けましょう。

人が待つ処理は通常の同期API

画面を見ている人がその場で結果を使うなら、通常の同期APIを選びます。たとえば、次の処理です。

• チャット画面の回答
• ユーザーが押したボタンへの応答
• コーディング支援
• 決済や申込の途中で必要な判定

回答を数秒から数十秒待つ操作で、いつ返るか分からないまま一日待たせるわけにはいきません。利用者が押すボタンへの応答は通常の同期APIに残し、その裏で行う大量処理にBatchを使えないか考えます。

Batch APIが向く処理

利用者の操作から切り離せる仕事なら、まとめて送れます。次のような仕事から探すとよいでしょう。

• 夜間の文書分類
• 大量の埋め込み生成
• 評価データセットの採点
• 商品説明の下書き
• 十分前に投入でき、結果回収・再処理の余裕がある要約
• 大量コンテンツの安全性チェック

どれも、投入してすぐ結果を使う必要がない仕事です。ただし「夜間処理だから大丈夫」とは限りません。結果を取り込み、失敗分をやり直す時間まで残せるかを見ます。

料金差は同じモデルで比べる

OpenAIのBatch対応エンドポイント・モデルでは、対象の入力・出力トークン料金を通常の同期処理から50%割引します。GeminiのBatchはgenerateContent APIを対象とし、対応モデルの標準料金の50%です。対象モデル・入出力の種類を料金表でそろえ、ツール利用料やストレージまで一律半額とは扱いません。

計算例として、同じモデルを使う同期APIの料金が月20万円、その半分の処理をBatchへ移せるとします。移した10万円分のモデル利用料は概ね5万円になり、移さない10万円分と合わせて約15万円です。これは料金条件をそろえた計算で、運用した実測結果ではありません。

節約額を見積もるときは、モデルの利用料に加えて、次の費用や手間も入れてください。

• 入力ファイルやジョブ作成
• 結果回収
• 失敗リクエストの再処理
• ストレージ
• 監視
• 実装変更の工数

モデル料金の割引が、そのまま運用費全体の半減になるわけではありません。処理量が少ない段階なら、仕組みを作り直す手間の方が大きくなることもあります。

たとえば先ほどの条件で、結果回収や監視に月1万円を追加し、移行の初期費用を12万円と置くなら、月の差は5万円−1万円＝4万円、初期費用の回収には3か月かかる計算です。これも仮の金額です。自分の処理量で同じ削減が続くか、締切対策の同期処理や再試行で費用が戻らないかを見て、移す範囲を決めてください。

24時間待てるかを業務SLAへ置き換える

「急ぎではない」を、業務で守る締切へ置き換えてみましょう。SLAは、サービスとして約束する応答時間などの条件です。ここでは、いつまでに使える結果が必要かを次のように書き出します。

処理	必要な完了時刻	Batch候補
チャット返信	数秒	×
深夜1時の集計を朝9時に必ず使う	8時間必達	原則×。事前投入や同期処理への切替など別の締切対策が必要
毎日の商品説明更新を翌日公開	24時間程度	条件付き。結果回収・失敗再処理まで含む余裕が必要
顧客へ30分以内に返す審査	30分	×
週次の評価ジョブ	完了枠＋結果回収・再処理の余裕	○。期限切れ時の扱いを決める

締切を決めたら、入力がそろう時刻から、投入、処理、結果回収、失敗分の再処理、人による確認までを含めて逆算します。24時間枠を使うなら少なくともその枠に後処理の余裕を足し、短い締切では事前投入・同期処理への切替・未完了を許容する分岐を用意します。同期処理へ切り替える前に、Batchの状態と成功済みIDを照合し、同じ処理を二重実行しないようにします。

失敗した一件だけを再処理できるようにする

Batch全体が終わっても、すべての依頼が成功したとは限りません。失敗分だけをやり直せるよう、一件ごとの依頼に次の情報を結び付けます。

• 自分の処理ID
• 元データのID
• 使用モデル
• 実行日
• 再試行回数

結果を受け取ったら、このIDを使って元の依頼と照合します。何件返ったかだけでは、どの商品や文書が抜けたのか分かりません。

OpenAIでは、この照合に各リクエストのcustom_idを使います。公式の結果回収手順では、出力の行順が入力と同じとは限らず、成功分はoutput_file_id、失敗分はerror_file_idから取得すると説明しています。上から順に商品一覧へ貼り戻すと、別の商品の回答を保存してしまうおそれがあります。

たとえば商品A・B・Cを送り、成功ファイルにC・A、エラーファイルにBが返ったとします。これは説明用の例です。IDでCとAの保存先を確定し、Bだけを再処理候補へ分けます。入力3件が「成功2件＋失敗1件」で過不足なく対応し、IDの重複もないことを確かめてから取り込みます。どちらにも見つからないIDがあれば、その依頼は未確認として残し、成功扱いにしません。

バッチ全体を丸ごと再送すると、成功済みの処理まで二重実行する可能性があります。バッチ状態だけでなく、出力・エラーファイルを要求IDごとに照合し、失敗・期限切れの分だけ再処理できる設計にします。OpenAIでは期限切れでも完了済みの出力は取得でき、その完了分の利用料は発生します。

通常の同期APIとBatchを同じシステムで分ける

同じサービスの中でも、利用者が試す部分と、確定した指示を繰り返す部分は分けられます。ECの商品登録なら、次の組み合わせが考えられます。

通常の同期API

• 管理画面で商品説明を一件試す
• 担当者が修正指示を出す

Batch

• 確定した指示で1万商品を締切から十分前に投入
• 完了済みの結果を回収し、未完了分を照合する

一件を試して指示を直す間は、すぐ返事が欲しいところです。指示が固まったあとの1万商品は、締切に余裕があればまとめて任せられます。操作の待ち時間を増やさず、繰り返し部分の費用を下げる分け方です。

Batchへ移す前の6項目

1. 結果が必要な締切
2. 一回に処理する件数
3. 失敗一件の再試行方法
4. 結果を元データへ戻すID
5. Batch対象モデルの現行料金と対応状況
6. 入力データの種別と、入力・出力・エラー・中間生成物の保持期間、削除方法、社内規程との適合

OpenAIのBatch APIには、組織でZero Data Retention（ZDR）を有効にしていてもZDRは適用されません。Batch関連ファイルなどはそれぞれの保持方針に従います。同期APIで認められた機密データの扱いを、そのままBatchへ引き継がず、利用する提供元・エンドポイントごとに確認します。

6項目を埋められたら、まず一つの処理を移す計画にしましょう。締切やデータの扱いが決まらないうちは、割引だけを理由に投入しない方が後戻りを減らせます。

OpenAIとGeminiで共通する考え方

公式ガイドで案内される対象の処理では、OpenAI Batch APIとGemini Batch APIはいずれも、

• 非同期処理
• 標準料金より50%低い料金
• 24時間を基準とする処理時間（OpenAIは完了ウィンドウ、Geminiは目標。全件成功の保証ではない）

という特徴を持っています。

この共通点だけで実装を流用せず、対応モデル、入力方法、送信できる量の上限、結果の取り方を提供元の現行文書で確認してください。最初に選ぶなら、締切までに結果回収と再処理の余裕がある仕事を一つ。人が待つ操作は通常の同期APIに残したまま、移せる部分から費用を比べるのがおすすめです。