OpenAI Batch APIとは｜50%安い非同期処理の使い方と料金

OpenAI Batch APIは、即座に応答を受け取る必要がないリクエストを1つのファイルにまとめて投げ、結果をあとからファイルで受け取るための仕組みです。公式ガイドは冒頭で「送信するリクエスト群を非同期にまとめることで50%低いコスト、同期APIとは別枠の大幅に高いレート制限、そして明確な24時間のターンアラウンドを得られる」と説明しており、即時応答を必要としない処理に向いたサービスだと位置づけています（OpenAI公式 Batch APIガイド、2026年9月20日取得）。

つまり判断基準はシンプルで、応答を待っている人間がいない処理なら、同じモデル・同じプロンプトのままコストを半分に落とせる可能性があります。逆に、チャット画面やフォームの送信ボタンの向こうで誰かが待っている処理には使えません。この記事では、料金差の実額、入力ファイルの作り方から結果の取り出しまでの4ステップ、バッチが取りうる8つの状態、レート制限の3本立て、そして標準処理・Flex・Fastモードとの使い分けまでを、公式ドキュメントの記述に沿って整理します。

OpenAI Batch APIとは｜非同期でまとめて投げる仕組み

OpenAI Batch APIとは、複数のAPIリクエストを1行1件のJSONLファイルにまとめてアップロードし、非同期に実行させて結果をファイルで回収する処理方式のことです。

通常のAPI利用では、1リクエストを送って1レスポンスを待ちます。Batch APIはこの流れを分解し、「リクエストの束をファイルとして預ける」「実行が終わるまで待つ」「結果ファイルをダウンロードする」という3つの局面に分けます。呼び出し側はレスポンスを待ち続ける必要がなく、処理はOpenAI側のキューで進みます。

公式ガイドは、同期エンドポイントを直接使う場合と比べたBatch APIの差分として、コスト効率（同期APIに対して50%のコスト割引）、レート制限の余裕（同期APIに比べて大幅なヘッドルーム）、完了までの速さ（各バッチは24時間以内に完了し、多くの場合はもっと早い）の3つを挙げています。詳細はBatch APIガイドに記載されています。

ここで注意したいのは、24時間という数字が「必ずかかる時間」ではなく「完了保証の上限側の目安」として書かれている点です。公式の表現は「各バッチは24時間以内に完了する（多くの場合はもっと早い）」であり、所要時間の下限は示されていません。設計上は24時間かかる前提でスケジュールを組み、早く終わったら得をする、と考えるのが安全です。

なお、どのAPIを選んでも「API種別そのものへの追加料金」は発生しません。料金ページには「Responses API、Chat Completions API、Realtime API、Batch API、Assistants APIは個別に課金されない。トークンは選択したモデルの入力・出力レートで課金される」と明記されています（OpenAI公式 料金ページ、2026年9月20日取得）。割引はあくまでBatch用の単価表として反映されます。

Batch APIが向く処理・向かない処理の分かれ目

Batch APIが向く処理とは、応答を待っている利用者がおらず、結果を数時間から24時間後に受け取っても業務が成立する処理のことです。

公式ガイドは、バッチ処理が役立つユースケースとして、評価（eval）の実行、大規模データセットの分類、コンテンツ資産の埋め込み生成、大量のオフライン動画レンダリングジョブのキューイングを挙げています。いずれも「今すぐ1件」ではなく「まとめて大量に」という性質を持つ仕事です。詳細はBatch APIのOverviewで確認できます。

実務に引き直すと、向いているのは次のような処理です。夜間に走らせる商品説明文の一括生成、問い合わせログ数万件のカテゴリ分類、記事本文のベクトル化、プロンプト変更前後の品質比較テスト。いずれも「朝までに終わっていればよい」性質があります。

逆に向かないのは、チャットUIの応答、フォーム送信直後のバリデーション、音声対話、ユーザー操作に連動したリアルタイム要約など、待ち時間がそのまま体験の質になる処理です。こうした用途では標準処理か、後述するFastモードを検討します。

判断を1行にすると、「その結果を人間が画面の前で待っているか」です。待っているなら同期、待っていないならBatch。この線引きだけで、料金とアーキテクチャの大半が決まります。モデル自体の選び方で迷う場合は、ChatGPT最新モデルの違いと使い分け｜2026年の最新情報もあわせて読むと整理しやすくなります。

Batch APIの料金は標準処理とどれだけ違うのか

Batch APIの料金とは、同一モデルの標準処理単価とは別に用意されたBatch専用の単価表のことです。

料金ページには、Standard pricingとBatch pricingが別々の表として掲載されています。以下は同ページから、短いコンテキストでの入力・出力単価（いずれも100万トークンあたり、米ドル）を抜き出したものです。適用条件は「短コンテキスト、従量課金、2026年9月20日時点のOpenAI公式 料金ページの表示」です。

モデル	標準 入力	標準 出力	Batch 入力	Batch 出力
gpt-6-astra	$10.00	$50.00	$5.00	$25.00
gpt-5.6-sol	$4.00	$20.00	$2.00	$10.00
gpt-5.6-terra	$2.00	$12.00	$1.00	$6.00
gpt-5.6-luna	$0.20	$1.20	$0.10	$0.60
gpt-5.5（272Kコンテキスト未満）	$5.00	$30.00	$2.50	$15.00

表を見てわかるとおり、掲載された各行でBatch側の単価は標準側のちょうど半分になっています。ガイド本文の「同期APIに対して50%のコスト割引」という記述と、料金表の実数が一致している形です。なお、gpt-5.5の行には「272Kコンテキスト未満」という条件が付いており、長いコンテキストには別の単価が設定されています。

料金表には入力・出力のほかにキャッシュ入力やキャッシュ書き込みの列もあり、Batch表にもキャッシュ入力の単価が併記されています。単価の桁が小さいモデルほど、割引の絶対額より「1回のジョブで何百万トークン流すか」が効いてきます。モデル世代ごとの価格差を先に確認したい場合は、GPT-6 Astraとは｜GPT-5.6との違い・料金・使い分けを解説とGPT-5.5全モデル比較と料金｜GPT-4oとの違い・選び方【2026年7月最新】が参考になります。

なお、ここで扱っているのはAPIの従量課金であり、ChatGPTの月額プランとは別の会計です。個人や社内利用でどちらを選ぶべきか迷う場合は、ChatGPT料金プラン完全比較｜Free・Go・Plus・Pro・Businessの違いと選び方・2026年の最新情報で前提を揃えてから比較してください。

Batch APIで使えるエンドポイントと対応モデル

Batch APIで使えるエンドポイントとは、JSONLの各行のurlフィールドに指定できるAPIパスのことです。

公式ガイドは、現時点で利用可能なエンドポイントとして、/v1/responses、/v1/chat/completions、/v1/embeddings、/v1/completions、/v1/moderations、/v1/images/generations、/v1/images/edits、/v1/videosを列挙しています。テキスト生成だけでなく、埋め込み、モデレーション、画像生成、動画生成までが同じ仕組みに乗る点が実務では効いてきます（Batch APIガイド）。

エンドポイントごとの個別条件も明記されています。動画生成については、Batchが対応するのはPOST /v1/videosのみであること、リクエストはmultipartではなくJSONで送ること、アセットは事前にアップロードして参照を本文へ渡すこと、画像を手がかりにする生成ではinput_referenceをfile_idまたはimage_urlを持つオブジェクトとして渡すこと、そしてバッチ生成された動画をダウンロードできる期間がバッチ完了後24時間に限られることが示されています。

モデレーションについては、すべてのリクエストボディにinputフィールドを含める必要があり、プレーンテキストのほかomni-moderation-latestを使ったテキスト・画像のコンテンツ配列も受け付ける一方、stream=trueを設定したリクエストはBatchワーカー側で拒否されると書かれています。同期のモデレーションエンドポイントと同じ挙動です。

対応モデルについて、ガイドは「Batch APIは当社のほとんどのモデルで広く利用できるが、すべてではない」とし、使用するモデルがBatch APIに対応しているかはモデルリファレンスで確認するよう案内しています。記憶や過去記事のモデル一覧で判断せず、投入前にリファレンス側を見るのが確実です。古いモデルを使い続けている場合は、OpenAI モデル非推奨化戦略｜2026年の最新情報もあわせて確認しておくと移行計画を立てやすくなります。

手順1: 入力となるJSONLファイルを組み立てる

JSONLファイルとは、1行につき1つのJSONオブジェクトを書き並べたテキストファイルのことです。

バッチは.jsonlファイルから始まります。各行には、個々のAPIリクエストの詳細を書きます。行に持たせるのは、結果を突き合わせるためのcustom_id、HTTPメソッドを示すmethod、呼び出し先を示すurl、そして実際のリクエスト内容であるbodyです。bodyの中身は、そのエンドポイントを同期で叩くときのパラメータと同じ形で書けます。

ここで外せない制約が2つあります。1つは、各リクエストが一意のcustom_idを持たなければならないこと。もう1つは、1つの入力ファイルには単一のモデルへのリクエストしか含められないことです。モデルを混在させたい場合は、モデルごとにファイルとバッチを分けます。

ファイルサイズにも注意が要ります。後述のとおり入力ファイルの上限は200MBです。公式ガイドは、マルチモーダルなモデレーションリクエストなどでbase64のかたまりを直接埋め込むのではなく、リモートアセットをimage_urlで参照するほうが、JSONLファイルを上限より十分下に保ちやすいと助言しています。

出力側の構造をここで設計しておくと後が楽になります。custom_idに社内のレコードIDをそのまま入れておけば、結果ファイルを読み込んだあとの突き合わせが単純なキー参照で済みます。逆に連番だけを振ると、後から元データに戻すための対応表が別途必要になります。レスポンスのJSON構造を固定したい場合は、OpenAI APIの構造化出力の使い方｜JSON Schemaで固定する手順の設計をbody側へ組み込んでおくと、後処理のパースが安定します。

手順2: Files APIでアップロードしてバッチを作成する

Files APIとは、OpenAIのサーバへファイルをアップロードし、以後はファイルIDで参照できるようにするAPIのことです。

公式ガイドは、ファインチューニングと同様に、まず入力ファイルをアップロードしてバッチ起動時に正しく参照できるようにする必要があると説明し、.jsonlファイルをFiles APIでアップロードするよう案内しています。アップロード時のpurposeにはbatchを指定します。

アップロードが成功すると、入力ファイルオブジェクトのIDが返ります。次はそのIDをinput_file_idに渡してバッチを作成します。このとき指定するのがendpointとcompletion_windowです。公式ガイドは「現時点でcompletion windowは24hにしか設定できない」と明記しています。あわせて、任意のmetadataパラメータでカスタムメタデータを付与できます。

metadataは運用上の目印として便利です。APIリファレンスによれば、metadataはオブジェクトに付与できる16組のキーと値のセットで、キーは最大64文字、値は最大512文字の文字列です（Batchesリファレンス）。ジョブ名、実行日、対象データのバージョンなどを入れておくと、ダッシュボードやAPIから後で絞り込めます。

バッチ作成のリクエストを送ると、バッチに関するメタデータを持つBatchオブジェクトが返ります。ガイドに掲載されたレスポンス例では、id、endpoint、input_file_id、completion_window、status、output_file_id、error_file_id、各種タイムスタンプ、request_countsといったフィールドが並んでいます。このidが、以降の状態確認やキャンセルで使う識別子になります。

手順3: バッチの状態を確認して完了を待つ

バッチのstatusとは、Batchオブジェクトが現在どの処理段階にあるかを示す文字列フィールドのことです。

バッチはいつでも状態を確認でき、確認のたびにBatchオブジェクトが返ります。statusの値は8つで、公式のBatch APIガイドには各値の説明表が掲載されています。ここでは各値に、その説明と、対応するタイムスタンプ（Batchesリファレンス）を並べます。

status	対応するタイムスタンプ	公式ガイドの説明
validating	created_at	バッチ開始前に入力ファイルを検証している
failed	failed_at	入力ファイルが検証に失敗した
in_progress	in_progress_at	入力ファイルの検証に成功し、バッチを実行中
finalizing	finalizing_at	バッチが完了し、結果を準備している
completed	completed_at	バッチが完了し、結果を取得できる
expired	expired_at	24時間の時間枠内に完了できなかった
cancelling	cancelling_at	キャンセル処理中（最大10分かかる場合がある）
cancelled	cancelled_at	キャンセルされた

進捗の粒度を知りたい場合はrequest_countsを見ます。リファレンスの説明では、このフィールドはバッチ内のステータス別リクエスト数を表し、completedは正常に完了したリクエスト数、failedは失敗したリクエスト数、totalはバッチ内の総リクエスト数です。全体の何割が終わったかは、この3つの値から算出します。

ポーリングの間隔は、24時間という完了目安に対して過剰にならない範囲で決めます。数分おきに叩いても処理が早まるわけではないため、数分から十数分に1回の確認で十分なケースが多くなります。複数バッチを並行して走らせている場合は、一覧取得にlimitとafterを使ったページングが用意されています。

手順4: 出力ファイルを取得してcustom_idで突き合わせる

出力ファイルとは、バッチ内の成功したリクエストに対する応答が1行ずつ書き込まれたJSONLファイルのことです。

バッチが完了したら、Batchオブジェクトのoutput_file_idを使ってFiles API経由で出力をダウンロードし、ローカルのファイルへ書き出します。出力の.jsonlには、入力ファイル内の成功したリクエスト1行につき1行のレスポンスが入ります。失敗したリクエストのエラー情報は別のエラーファイルに書かれ、こちらはerror_file_idから辿れます。

ここが実装で最もつまずきやすい点ですが、公式ガイドは「出力行の順序は入力行の順序と一致しない場合がある」と明言しています。そのうえで、順序に依存して結果を処理するのではなく、出力ファイルの各行に含まれるcustom_idフィールドを使って入力と出力を対応づけるよう指示しています。配列のインデックスで突き合わせる実装は、そのままだと結果の取り違えにつながります。

保存期間も設計に織り込む必要があります。ガイドには「出力ファイルはバッチ完了の30日後に自動的に削除される」と記載されています。長期保管が必要なら、自社のストレージへ取り込む工程までを一連のジョブに含めておきます。

動画生成をバッチで回した場合は、完了したバッチの結果にすでに終端状態へ到達した動画オブジェクトが含まれるとガイドは説明しています。返された動画IDを使えば、バッチ終了直後に最終アセットをダウンロードできます。ただし前述のとおり、動画をダウンロードできる期間がバッチ完了後24時間に限られる点には注意してください。

Batch APIのレート制限は標準APIと別枠で管理される

Batch APIのレート制限とは、既存のモデル別レート制限とは分離して管理される、バッチ処理専用の上限値のことです。

公式ガイドは、Batch APIのレート制限が既存のモデル別レート制限とは別であるとしたうえで、制限は3種類あると説明しています。内訳は次の表のとおりです（Batch APIガイドのRate limits）。

制限の種類	公式に示された上限	超えそうなときの対処
バッチ単位の制限	1バッチあたり最大50,000リクエスト、入力ファイルは最大200MB。embeddingsのバッチはバッチ内全リクエスト合計で最大50,000件の埋め込み入力	ファイルを分割して複数バッチにする
モデル別のキュー済みプロンプトトークン	モデルごとにバッチ処理でキューできるプロンプトトークン数の上限がある	投入を時間帯で分散する、モデルを分ける
バッチ作成のレート制限	1時間あたり最大2,000バッチ	1バッチあたりのリクエスト数を増やす

出力側については、ガイドは「Batch APIには現時点で出力トークンの上限がない」と述べています。加えて、Batch APIのレート制限が新しい別プールであるため、Batch APIの利用は標準のモデル別レート制限のトークンを消費しないと明記しています。これは、同期APIのレート制限に張り付いている状況でも、バッチ経由なら処理量を上乗せできることを意味します。

モデル別のキュー済みトークン上限は、組織のプラットフォーム設定画面から確認する運用になっています。設定画面はログインが必要なため、値そのものを外部の記事から引き写すのではなく、自組織のダッシュボードで実数を確認してください。レート制限の考え方全般はレート制限ガイドにまとまっています。

埋め込み生成をバッチで回す場合は、リクエスト数ではなく埋め込み入力の総数が効いてくる点に留意します。1リクエストに複数の入力を詰め込んでリクエスト数を減らしても、埋め込み入力の合計が上限に当たれば同じところで頭打ちになります。

期限切れ・キャンセル・失敗時に何が起きるか

バッチの期限切れとは、完了予定の時間内に処理が終わらず、未完了のリクエストが打ち切られた状態のことです。

公式ガイドの説明では、時間内に完了しなかったバッチは最終的にexpired状態へ移り、そのバッチ内の未完了リクエストはキャンセルされます。一方で、すでに完了していたリクエストの応答はバッチの出力ファイル経由で利用できます。課金については「完了したリクエストで消費されたトークンについては課金される」と明記されています。期限切れになったリクエストはエラーファイルへメッセージとともに書き出され、custom_idからリクエストデータを辿れます。

途中で止めたい場合は、実行中のバッチをキャンセルできます。キャンセルを要求すると、statusは実行中のリクエストが完了するまでcancellingになり、その待ち時間は最大10分です。その後statusはcancelledへ変わります。APIリファレンスでは、キャンセルされたバッチは部分的な結果があれば出力ファイルから利用できると説明されています。

運用設計としては、この3つの終わり方をすべて正常系として扱っておくのが安全です。つまり、completedだけを前提にした後処理ではなく、expiredやcancelledでも出力ファイルとエラーファイルの両方を読み、処理済みと未処理をcustom_idで仕分ける実装にしておきます。

再実行の設計も先に決めておきます。エラーファイルから未処理のcustom_idを抽出し、そのぶんだけ新しい入力ファイルを作って再投入する流れにしておけば、全件を投げ直す無駄が避けられます。1バッチ50,000リクエストの上限を踏まえると、再投入分は元より小さなバッチになるのが普通です。

Batch・Flex・Standard・Fastモードを使い分ける

サービスティアとは、同じモデルに対して処理の速さと単価のバランスを変えて実行するための選択肢のことです。

OpenAIの公式ドキュメントには、Batch API以外にも処理の性格を変える選択肢が用意されています。Flex処理は、応答が遅くなることとリソースが一時的に利用できない場合があることと引き換えに、ResponsesまたはChat Completionsのリクエストを低コストで実行する方式です。公式は、モデル評価、データエンリッチメント、非同期ワークロードなど、本番以外や優先度の低いタスクに向くと説明しています（Flex処理ガイド）。

Flexの単価はBatch APIのレートで課金されると明記されており、プロンプトキャッシュによる追加割引も適用されます。利用するにはservice_tierパラメータにflexを指定します。ただしFlexはベータで対応モデルが限られていること、処理が遅いぶんリクエストのタイムアウトが起きやすく公式SDKの既定タイムアウトは10分であること、リソース不足時には429 Resource Unavailableが返り、そのときは課金されないことが示されています。

反対方向の選択肢がFastモードです。公式は、Fastモードが標準処理に対して最大2.5倍の速度とより安定したレイテンシを提供し、従量課金の柔軟さを保つとしています。以前のPriority processingは2026年7月30日にFast modeへ改称されました。単価は標準処理に対してトークンあたりのプレミアムが上乗せされます（Fastモードガイド）。

4つの選択肢の性格を1枚にまとめると次のようになります。

方式	指定方法	速度の性格	コストの性格
Batch API	JSONLをアップロードしてバッチ作成	各バッチは24時間以内に完了	同期APIに対して50%のコスト割引
Flex処理	service_tierにflexを指定	応答が遅く、リソース不足の可能性あり	Batch APIのレートで課金
標準処理	service_tierを指定しない	既定の同期応答	Standard pricingの単価
Fastモード	service_tierにfastを指定	標準処理に対して最大2.5倍の速さ	標準処理に対するトークン単価のプレミアム

使い分けで見落とされがちなのが、Fastモードのガイドにある注意です。そこには、ランプレート制限を避けるための実践として「大規模なETLやバッチジョブをFastモードで実行しない」と書かれています。大量処理はBatchかFlexへ寄せ、Fastは待たせられない対話用途に絞る、という役割分担が公式側の想定です。APIの呼び出し方そのものの違いを整理したい場合は、Responses APIとChat Completionsの違いと使い分けもあわせて確認してください。

仮の例: 12万件のレビュー分類をBatch APIで設計する

バッチ設計とは、処理対象の件数を上限に合わせて分割し、投入から結果回収までの工程を事前に決めておくことです。

ここからは仮の例です。実在の案件ではなく、公式に示された上限と単価だけを使った机上の設計として読んでください。題材は、自社サービスに寄せられたレビュー12万件を、gpt-5.6-lunaで5つのカテゴリに分類するジョブとします。1件あたりの入力を1,200トークン、出力を200トークンと仮定します。

まず分割です。1バッチあたりのリクエスト上限は50,000件なので、12万件は50,000件、50,000件、20,000件の3バッチに分かれます。1時間あたり2,000バッチという作成上限に対して3バッチは余裕があり、ここが制約になることはありません。入力ファイルは1バッチごとに作り、それぞれが200MBを超えないかをアップロード前に確認します。

次に単価計算です。この仮の例では、入力の合計は12万件×1,200トークンで1億4,400万トークン、出力の合計は12万件×200トークンで2,400万トークンになります。前掲の料金表にあるgpt-5.6-lunaの単価（OpenAI公式 料金ページ、2026年9月20日取得の短コンテキスト値）を当てはめると、標準処理は入力$28.80と出力$28.80で合計$57.60、Batchは入力$14.40と出力$14.40で合計$28.80という計算になります。差額は$28.80です。

この仮の計算はトークン数の仮定に依存するため、実際の課金額を約束するものではありません。実運用では、まず数百件だけを同期APIで流してトークン消費の実測値を取り、その平均値で見積もり直すのが現実的です。

工程としては、レビューIDをそのままcustom_idに入れてJSONLを生成し、3つのファイルをアップロードして3バッチを作成、metadataに実行日とデータバージョンを記録、数十分おきにrequest_countsを確認、completedになった順に出力ファイルを取得してレビューIDで自社DBへ書き戻す、という流れになります。expiredやcancelledで終わったバッチは、エラーファイルから未処理IDを抽出して4本目のバッチを作ります。

社内で同種の一括処理を増やしていく場合は、実行環境側の整備も効いてきます。コード生成やスクリプト実行の環境については、OpenAI Codex 使い方｜料金・始め方・Claude Codeとの違いを初心者向けに解説・2026年の最新情報とOpenAI Codex企業導入ガイド｜モデル・コスト・移行計画・2026年の最新情報が参考になります。クラウド側の調達経路を検討している場合は、OpenAI Amazon Bedrock｜2026年の最新情報も選択肢の整理に使えます。

Batch API導入でつまずきやすい5つの落とし穴

落とし穴とは、公式ドキュメントに書かれているにもかかわらず、実装時に見落とされやすい仕様上の制約のことです。

ここまでの内容のうち、実装で事故になりやすいものを整理します。順序、モデル混在、保存期間、リクエスト上限、そして終端状態の扱いの5つです。

• 出力行の順序が入力行と一致しない場合があるため、インデックスではなくcustom_idで突き合わせる
• 1つの入力ファイルには単一モデルへのリクエストしか含められないため、モデルごとにファイルを分ける
• 出力ファイルはバッチ完了の30日後に自動削除されるため、自社ストレージへの取り込みまでを工程に入れる
• 1バッチ50,000リクエスト・入力ファイル200MBの上限を、生成スクリプト側で機械的に検査する
• completedだけでなくexpiredとcancelledでも出力ファイルとエラーファイルを読む後処理にする

もう1つ、見積もりの落とし穴があります。Batchの割引はトークン単価に対するものなので、プロンプトが冗長なままバッチ化しても、削減できるのは「冗長なプロンプトのコストの半分」です。先にプロンプトを短くしてからバッチ化したほうが、削減幅は大きくなります。プロンプト設計の基本はChatGPTのプロンプトはなぜ伝わらない？書き方の5つのコツとはで確認できます。

運用体制の面では、バッチの実行記録をどこに残すかを先に決めておくと、後から「どのデータをどのモデルで処理したか」を追えます。日々の業務へAIを組み込む段取りそのものを見直したい場合は、ChatGPTを仕事で活用して業務効率化するにはどうすればいい？とChatGPTのプロジェクト機能の使い方｜ファイル・指示・チャットの整理手順が土台になります。

よくある質問（FAQ）

Q1. Batch APIを使うと、結果が出るまで24時間待つことになりますか。

公式ガイドは「各バッチは24時間以内に完了する（多くの場合はもっと早い）」と記載しています。つまり24時間は完了までの目安の上限側であり、常にその時間がかかるという意味ではありません。ただし下限は示されていないため、スケジュールは24時間かかる前提で組むのが安全です。詳細はBatch APIガイドを確認してください。

Q2. Batchの割引を受けるために、別途申し込みや契約変更は必要ですか。

料金ページには、Responses API、Chat Completions API、Realtime API、Batch API、Assistants APIが個別に課金されず、トークンは選択したモデルの入力・出力レートで課金されると書かれています。割引はBatch用の単価表として反映される形で、記事執筆時点の公式ドキュメントに申し込み手続きの記載はありません。

Q3. 1つのバッチに複数のモデルへのリクエストを混ぜられますか。

混ぜられません。公式ガイドは、各入力ファイルが単一のモデルへのリクエストのみを含められると明記しています。複数モデルを使いたい場合は、モデルごとに入力ファイルとバッチを分けて作成します。エンドポイントもバッチ作成時に1つ指定するため、エンドポイントが異なる場合も同様に分割が必要です。

Q4. 出力ファイルの行順は入力ファイルと同じになりますか。

同じになるとは限りません。公式ガイドは、出力行の順序が入力行の順序と一致しない場合があるとしたうえで、順序に依存せず各行に含まれるcustom_idで入力と出力を対応づけるよう案内しています。配列のインデックスで結合する実装は、結果の取り違えの原因になります。

Q5. 結果ファイルはいつまでダウンロードできますか。

公式ガイドには、出力ファイルがバッチ完了の30日後に自動的に削除されると記載されています。動画生成をバッチで実行した場合は別の条件があり、バッチ生成された動画のダウンロード可能期間はバッチ完了後24時間までと示されています。長期保管が必要なら、自社ストレージへ取り込む工程まで含めて設計してください。

Q6. バッチが期限切れになったら、それまでの処理はどうなりますか。

公式ガイドの説明では、時間内に完了しなかったバッチはexpired状態へ移り、未完了のリクエストはキャンセルされます。完了済みリクエストの応答は出力ファイルから利用でき、完了したリクエストで消費されたトークンについては課金されます。期限切れのリクエストはエラーファイルに書き出され、custom_idからリクエストデータを辿れます。

Q7. Batch APIとFlex処理は、どちらを選べばよいですか。

公式ドキュメントの位置づけで選び分けます。Batch APIは大量のリクエストをファイルで預ける方式で、各バッチは24時間以内に完了します。Flex処理はResponsesまたはChat Completionsの個別リクエストをservice_tierにflexを指定して実行する方式で、単価はBatch APIのレートで課金されますが、ベータで対応モデルが限られ、リソース不足時には429が返ります。件数がまとまっていてファイル化できるならBatch、逐次呼び出しの形を保ちたいならFlex、という整理になります。

まとめ

OpenAI Batch APIは、応答を待つ人間がいない処理を、同じモデルのまま半分の単価で回すための仕組みです。公式ガイドは50%のコスト割引、同期APIとは別枠のレート制限、24時間以内の完了という3点を差分として挙げています。使える入口は、テキスト生成から埋め込み、モデレーション、画像、動画まで8つのエンドポイントに広がっています。

実装で押さえるべき骨格は4ステップです。1行1リクエストのJSONLを作り、Files APIでアップロードし、completion_windowを24hにしてバッチを作成し、完了後に出力ファイルをcustom_idで突き合わせる。この流れのなかで、単一モデル制約、200MBと50,000リクエストの上限、出力順序の非保証、30日での自動削除という4つの仕様を設計に織り込んでおけば、大きな作り直しは避けられます。

そして、Batch・Flex・標準処理・Fastモードは対立する選択肢ではなく、待ち時間の許容度で棲み分ける道具です。大量処理はBatchかFlexへ、待たせられない対話はFastか標準処理へ。この配分を先に決めてから実装に入ると、料金とレート制限の両方が同時に楽になります。単価や上限は更新されるため、本番投入の前に、公式のBatch APIガイドと料金ページで最新の値を確認してください。