OpenAI Batch APIとは？料金50%割引・24時間処理の導入判断

OpenAI Batch APIの要点

Batch APIは、複数のAPIリクエストをJSONLファイルへまとめ、アップロード後に非同期で処理するOpenAIの実行方式です。通常のAPIのように利用者を待たせながら1件ずつ応答するのではなく、処理結果を後からファイルで受け取ります。

公式ドキュメントが示す主な利点は、同期API比で50%の料金割引、通常とは別枠のレート制限、24時間以内の完了枠です。ここでいう24時間は最長の処理枠であり、毎回24時間かかるという意味ではありません。一方、数秒以内の応答や締切時刻を厳密に約束するオンライン機能には向きません。

仕組み：4段階で大量リクエストを処理する

処理は、①リクエストごとに一意なcustom_idを付けたJSONLを作る、②Files APIへpurpose=batchとしてアップロードする、③対象エンドポイントとcompletion_window=24hを指定してバッチを作る、④完了後にoutput_file_idから結果を取得する、という流れです。

2026年9月21日時点では、Responses、Chat Completions、Embeddings、Completions、Moderations、画像生成・編集、動画生成などが案内されています。ただし、1つの入力ファイルに混在できるのは単一モデルへのリクエストです。利用予定モデルがBatchに対応するかはモデル資料で確認する必要があります。

出力行は入力順に並ぶとは限りません。配列の位置で結合すると別顧客の結果へ誤って紐付ける危険があるため、業務側のレコードIDとcustom_idを対応させます。成功した行は出力ファイル、失敗した行はerror_file_idが指すエラーファイルで管理されます。

料金：50%割引をどう試算するか

OpenAIはBatch APIについて、同期APIと比べて入力・出力料金が50%安いと案内しています。2026年9月21日の公式料金表では、短いコンテキストのgpt-5.6-solはStandardが入力100万トークン4ドル・出力20ドル、Batchが入力2ドル・出力10ドルです。料金とモデル名は変わるため、実装時は必ず最新表を確認してください。

たとえば1日分の処理が入力1,000万トークン、出力100万トークンなら、Standardの単純計算は60ドル、Batchは30ドルです。30日間同量なら1,800ドルから900ドルへ下がります。この試算はモデル利用料だけで、JSONL生成、保存、監視、再実行、結果取込の運用費は含みません。

全処理を移せない場合は、総コスト削減率を『Batchへ移せる従量料金の比率×50%』で概算できます。従量料金の60%をBatch化できるなら、他条件が同じ場合の総削減率は約30%です。まず利用ログから、即時性を必要としないトークン量を分離する方が、リクエスト件数だけを見るより正確です。

向いているケース

Batch APIが向くのは、処理開始から結果利用までに余裕があり、同じモデルで大量の独立リクエストを実行するケースです。24時間以内という枠を業務要件が許容できれば、単価とオンライン側のレート制限を同時に改善できます。

• 夜間にまとめて行う問い合わせ分類、タグ付け、感情分析
• モデルやプロンプト変更前後の大規模評価
• 文書・商品・FAQの埋め込み再作成
• 既存データへの要約、属性抽出、データ補完
• 翌朝までに完成すればよいレポートやコンテンツ下書き
• 大量画像・動画のオフライン生成や再処理

向かないケース

ユーザーが画面で待っている会話、検索、エージェント操作、購入判定などは、完了までの待ち時間を許容しにくいため通常の同期APIが基本です。また、営業時間開始までに必ず全件を終えるなど、24時間より短い固定締切がSLAに含まれる処理も慎重に判断します。

データ保持の制約も重要です。OpenAIのデータ管理表では、/v1/batchesはAPIモデルの学習には使われない一方、デフォルトの不正利用監視ログは30日、アプリケーション状態は削除まで保持、Zero Data Retentionは対象外とされています。ZDRが必須の機密処理は、Batchへ移せると単価だけで判断できません。

• チャットや音声など、秒単位の応答が必要な機能
• 分単位の完了保証や厳格な処理順序が必要な業務
• 1件の結果を受けて次の入力を決める連続ワークフロー
• 失敗行の再実行や結果ファイル取込を運用できないチーム
• Zero Data Retentionを必須条件とするデータ

通常API・Flex・Scale Tierとの違い

通常APIはオンライン機能向け、Batchは24時間待てる大量処理向けです。Flex processingは1件ごとのAPI形式を保ったままBatch相当のトークン単価を使えますが、遅延と一時的なリソース不足を許容する必要があり、対応モデルも限定されています。ファイル単位で確実に大量処理を管理したいならBatch、既存の同期呼び出しに近い形で低優先度処理を流したいならFlexが候補です。

Scale Tierは、特定モデルの処理能力を一定期間確保する大規模利用向けの契約です。予測可能な高スループットが必要な常時稼働サービスと、余裕のある処理を安く流すBatchでは、解決する課題が異なります。固定費、必要TPM、利用率まで含めて比較してください。

導入前に確認する8項目

PoCでは、割引率だけでなく、完了率と運用工数を測ります。まず1日分ではなく1時間分程度の実データを使い、成功・失敗・期限切れを含む結果取込まで通してから対象を広げると安全です。

• 対象ジョブの何%が24時間待てるか
• 入力・出力トークンのうちBatchへ移せる比率
• 利用モデルとエンドポイントがBatch対応か
• queued prompt tokensの組織別上限に収まるか
• 50,000件・200MBを超えない分割単位
• custom_idの一意性と業務レコードへの対応表
• 失敗・期限切れ・キャンセル時の再実行と二重処理防止
• 保持期間、削除、ZDR、データ所在地などの契約要件

具体例：問い合わせ分類を夜間バッチへ移す

日中に届いた問い合わせ10,000件を、翌朝までに営業・請求・技術・その他へ分類するケースを考えます。画面上の一次受付は即時に完了させ、分類だけを夜間ジョブへ分離します。各行のcustom_idには問い合わせIDと処理バージョンを含め、結果を受け取った後に分類ラベル、確信度、モデル名、トークン数、完了時刻を保存します。

失敗行だけを再投入できるようにし、同じcustom_idまたは業務IDを二重反映しない冪等性を持たせます。朝の業務開始までに未完了なら人手キューへ回す運用も決めます。費用比較では、全10,000件のモデル料金だけでなく、失敗率、再実行率、担当者の確認時間まで含む『正常分類1件あたり総原価』を記録します。

上限と失敗時の扱い

公式上限は、1バッチ50,000リクエスト、入力ファイル200MB、バッチ作成は1時間あたり2,000件です。モデルごとにキューへ積めるプロンプトトークン上限もあり、この値はPlatform Settingsで組織ごとに確認します。Batchの枠は通常APIとは別で、Batchの利用が通常のモデル別レート制限を消費しない点は大規模運用で重要です。

24時間内に完了しなかったバッチはexpiredとなり、未完了リクエストはキャンセルされます。完了済みの結果は取得でき、その処理で消費したトークンは課金されます。バッチ自体の成功・失敗だけでなく、request_countsとエラーファイルを確認し、部分成功を前提に設計する必要があります。

FAQ

Q. Batch APIは必ず24時間かかりますか？　A. いいえ。公式には多くの場合もっと早く完了するとされていますが、指定できるcompletion_windowは2026年9月21日時点で24hのみです。個別の完了時間を前提にSLAを組まない方が安全です。

Q. 品質は通常APIより下がりますか？　A. Batchは安い別モデルへ自動変更する仕組みではありません。同じモデルとパラメータを指定できます。ただし、モデル更新や非決定性を考慮し、同期処理と同じ評価データで出力を確認してください。

Q. 入力順に結果が返りますか？　A. 返るとは限りません。各行のcustom_idで突合します。

Q. 失敗したリクエストにも課金されますか？　A. 期限切れ時は完了済みリクエストで消費したトークンに課金されます。失敗理由ごとの課金と再実行可否は、エラー内容と利用明細で確認してください。

Q. Flex processingとどちらが安いですか？　A. 公式にはFlexもBatch APIレートです。ファイル単位の大量処理・別レート枠を使うならBatch、1件ずつ既存APIに近い形で呼びたいならFlexが候補です。

Q. 機密データに使えますか？　A. APIデータは明示的に共有しない限りモデル学習に使われませんが、/v1/batchesはZDR対象外です。保持と削除の要件を確認してから判断してください。

導入判断のまとめ

Batch APIは、同じモデルの品質を維持しながら、待てる処理の入力・出力料金を半分にできる明確な選択肢です。まず請求額ではなくトークン利用をオンライン処理とオフライン処理に分け、Batch化できる比率から削減余地を見積もります。

一方、24時間枠、結果順序、部分失敗、ファイル保持、ZDR非対応を受け入れられない処理は移すべきではありません。少量の実データで結果取込まで検証し、『Batch化率』『完了率』『再実行率』『正常処理1件あたり総原価』を継続して測ることが、料金表だけで終わらない導入判断になります。