Azure OpenAI Batch APIとは？半額運用の条件とJSONL実装手順

Azure OpenAI の Batch API（グローバルバッチ）は、多数の推論要求を1つのファイルにまとめて非同期で処理する仕組みです。応答は即座には返りません。その代わり、Microsoft Learn は「24時間の目標ターンアラウンドで、グローバル標準デプロイより50%低コスト」と明記しています（2026年8月時点）。この記事では、Global-Batch デプロイの作り方、JSONL入力の書式と200MB・10万要求という上限、ジョブ状態の監視実装、そして半額という単価差が実際に得になる処理量と締切条件を、公式ドキュメントの実測値から整理します。

まとめ：24時間の待ち時間と半額課金が釣り合う業務条件

結論を先に示します。バッチを採用するかどうかは、処理量の大きさではなく「結果を明日まで待てるか」で決まります。単価は半分になりますが、返ってくる時刻を制御する手段がないためです。ジョブは投入順に処理されるわけではなく、24時間以内という目標値も保証ではありません。

逆に、締切が翌営業日以降にある処理なら、迷わずバッチに寄せてよい領域です。蓄積済みの問い合わせ履歴を一括分類する、月次で数万件の文書を要約する。こうした「溜めてから流す」処理は、エンキュートークンという専用クォータで動くため、本番のチャット応答のスループットを一切削らずに半額で回せます。

実装面で最初に押さえる数字は3つです。入力は1ファイル200MBまで、1ファイルあたり10万要求まで、完了ウィンドウは24h以外を指定するとジョブが失敗します。この3点を外すと、ジョブ作成の時点でつまずきます。

採用を見送るべき場面もはっきりしています。対話応答、締切が24時間を切る夜間バッチ、そして数分以内に結果が必要な画面連動処理。これらは半額の魅力よりも待ち時間の不確実性が上回るため、グローバル標準デプロイか、容量を確保するPTUによる予約課金のどちらかで組むほうが破綻しません。

Batch APIの処理方式とグローバル標準デプロイに対する課金・待ち時間の差

まず、Batch API がどの層の話なのかを固定しておきます。モデルもAPIの呼び出し形式も通常と同じで、違うのは「デプロイの種類」と「要求の渡し方」だけです。

非同期キュー方式の処理フローと24時間ターンアラウンドの目標値

通常のオンライン推論は、1回のHTTP要求に対して1回の応答が返ります。バッチは違います。要求をJSONL形式のファイルにまとめ、ファイルをアップロードし、そのファイルIDを指定してジョブを作成する。処理が終わるまでの間、クライアント側は何も待ちません。

Microsoft Learn は「このサービスは24時間以内にバッチ要求を処理することを目的としている」と記載しつつ、同じ段落で「時間がかかるジョブは期限切れにならない」とも明記しています（2026年8月時点）。つまり24時間はSLAではなく目標値です。ジョブはいつでも取り消せて、取り消した場合は残りの作業が破棄され、すでに完了した分の結果が返り、その完了分だけが課金対象になります。

締切から逆算して「26時間前に投入すれば間に合う」という前提を置いた運用は成立しません。バッチに載せてよいのは、遅延が業務を止めない処理だけです。

グローバルバッチとデータゾーンバッチのリージョン差とデータ所在地

バッチのデプロイ種別は2つあります。Microsoft Foundry ポータルでは Global-Batch と Data Zone Batch として表示されます。違いは処理される場所の広さです。

グローバルバッチは、保存データこそ指定したAzureジオグラフィ内に留まるものの、推論処理自体は任意のAzure OpenAIロケーションで実行される可能性があります。2026年8月時点の提供リージョン表には japaneast を含む22リージョンが並び、gpt-5.4系からgpt-4o-miniまで幅広くチェックが入っています。

データゾーンバッチは処理範囲を米国内・EU内といったデータゾーンに閉じる代わりに、提供リージョンが12に絞られます。同表に japaneast の行はありません。加えて francecentral や swedencentral では gpt-5系のチェックが空欄で、gpt-4.1系・o3-mini系のみという状態です。国内データセンターでの処理を社内規程で求められている場合、この表の差がそのまま採用可否になります。モデル別・リージョン別の提供状況は変動が速いため、設計時点で必ず一次情報を引き直してください。

エンキュートークンという専用クォータがオンライン処理を止めない理由

バッチのクォータは、通常のTPM（1分あたりトークン数）とは別枠で「エンキューされたトークン」という単位で管理されます。ファイルを送信した時点でファイル内のトークン数がカウントされ、ジョブが最終状態に達するまでその総量に対して計上され続けます。

数字の桁を掴んでおくと設計しやすくなります。2026年8月時点のグローバルバッチのクォータ表では、gpt-5.4 の上限がエンタープライズ／MCA-E契約で50億、既定で2億、月次クレジットカード契約で5,000万エンキュートークンです。gpt-4.1-mini や o4-mini のように150億まで許容されるモデルもあり、モデル系統によって2桁近い開きがあります。

この枠が独立している点が、バッチを使う実務上の利点です。夜間に数千万トークンを流し込んでも、日中のチャットボットが消費するTPMには影響しません。オンライン側のクォータ設計はAzure OpenAI Service全体の料金と提供機能の側で押さえ、バッチ側はエンキュートークンだけを見ればよい形になります。

バッチデプロイの作成手順とJSONL入力ファイルの書式・容量上限

ここからは実装です。リソース作成やキー取得そのものは通常のAzure OpenAI利用と共通のため、リソース作成からPython・REST呼び出しまでの手順を前提として、バッチ固有の差分だけを追います。

Global-Batchデプロイの作成と動的クォータを有効にする判断

既存のグローバル標準デプロイをバッチに流用することはできません。デプロイ作成時にデプロイの種類として Global-Batch（またはデータゾーン版）を選び、専用のデプロイ名を発行する必要があります。JSONLの各行で指定する model には、モデル名ではなくこのデプロイ名を書きます。

作成時に判断が要るのが動的クォータです。Microsoft Learn は、エンキュートークン不足によるジョブ失敗を避けるため、すべてのグローバルバッチデプロイで動的クォータを有効にすることを推奨しています。オフの場合、デプロイは作成時に定義したエンキュートークン上限までしか要求を処理できません。オンにすると、追加容量が空いたときに日和見的により多くのクォータを使えます。

既定でオンにし、コスト上限が厳格に決まっている案件だけオフを検討する。この順序で構いません。

JSONL各行に必要なcustom_id・method・url・bodyの書き方

入力ファイルは JSON Lines 形式で、1行が1要求に対応します。必要な要素は4つです。

• custom_id：要求と応答を突き合わせるための任意のID。応答はJSONLの記述順では返らないため、この値が唯一の対応付け手段になります
• method：POST を指定します
• url：/v1/responses または /v1/chat/completions。公式の入力例はこの2系統です
• body：通常のAPI呼び出しと同じ要求本文。model にはバッチデプロイ名を入れます

制約が1つあります。バッチファイルの各行には同一のバッチデプロイ名が入っていなければなりません。別のデプロイへ振り分けたい場合は、ファイルとジョブを分ける必要があります。gpt-5.4系で要約し gpt-4.1-nano系で分類する、といった混在処理を1ジョブでは組めません。モデルごとの用途と選定軸を先に決め、モデル単位でファイルを割ってから流す設計にします。

1ファイル200MB・10万要求の上限とBlob Storage併用の分岐

入力側の上限は4つの数字で押さえられます。2026年8月時点の公式表は次のとおりです。

設計時に効くのは、ファイル数の上限がファイルの有効期限設定で20倍に変わる点です。アップロード時に expires_after を指定して14日で失効させれば、リソースあたりの入力ファイル枠が500から10,000に増えます。日次でジョブを回す運用なら、期限設定は入れておくほうが安全側です。

200MBまたは10万要求を超える場合の分岐は2つです。ファイルを分割して複数ジョブに割るか、Azure Blob Storage を入力元に使う構成（BYOS）へ切り替えるか。後者なら入力ファイルサイズは1GBまで許容され、入力ファイル数の制限も外れます。1回の処理が数十万件に達する見込みなら、最初からBlob Storage前提で組むほうが手戻りは小さく済みます。

ジョブ投入から結果回収までの実装手順と8つの状態値による監視設計

実装の流れは、ファイルアップロード、ジョブ作成、状態監視、結果回収の4工程です。工程ごとに落とし穴があります。

ファイルアップロードとcompletion_window指定の必須パラメータ

アップロードは purpose に batch を指定して行います。ファイルはアップロード直後には使えず、処理が完了するまで待つ必要があるため、ファイル状態の確認処理を挟みます。

ジョブ作成で指定するのは3つです。アップロードで得た input_file_id、エンドポイント、そして完了ウィンドウ。完了ウィンドウは 24h に設定しなければならず、それ以外の値を渡すとジョブは失敗します。将来的に短い窓が選べるようになる可能性はありますが、2026年8月時点では固定値と考えて実装してください。

エンドポイント引数は指定が必須ですが、システム側が入力ファイルを読んで chat completions か responses かを判定します。ここでの指定と入力ファイルのURLがずれていても、ファイル側の記述が優先される挙動です。

validatingからcompletedまでの状態遷移と60秒間隔のポーリング

ジョブの状態値は8つあります。validating（入力ファイルの検証中）、failed、in_progress、finalizing（結果の準備中）、completed、expired、cancelling、cancelled です。正常系は validating → in_progress → finalizing → completed の順に進みます。

公式ドキュメントは、状態確認の呼び出し間隔を最低60秒空けることを推奨しています。掲載されたサンプル出力でも遷移は数分刻みで、秒単位のポーリングには意味がありません。監視処理は60秒スリープのループで十分です。

取り消しの挙動も押さえておきたいところ。実行中のジョブを取り消すと、状態は最大10分間 cancelling に留まってから cancelled に変わり、その時点までの部分的な結果は出力ファイルから取得できます。誤ったプロンプトで数万件を流した場合でも、気づいた時点で止めれば損失は完了分に限定されます。

output_file_idとerror_file_idの回収とcustom_id突合

ジョブが終了状態に達すると、出力ファイルとエラーファイルが別々に生成されます。取得すべきは output_file_id と error_file_id の両方です。片方だけを見る実装にすると、一部の行だけが失敗したケースを取りこぼします。

公式サンプルも、出力ファイルIDが空のときはエラーファイルIDにフォールバックしてダウンロードする構造です。実務では両方を回収し、エラーファイルの行数が0でないかを検知条件に入れます。

回収したJSONLは、入力と同じ順序では並びません。custom_id をキーに突合する処理が前提になります。ここを順序依存で書くと、テストデータの件数が少ないうちは偶然通ってしまい、本番の数万件で結果が入れ替わる形の障害になります。設計レビューで真っ先に見るべき箇所です。

従量課金との費用比較と、半額が成立する処理量・締切条件の見極め

単価が半分という事実だけでは採用判断になりません。待ち時間という別のコストが増えるためです。ここは判断を言い切ります。

50%割引が効く前提条件と、待ち時間を金額換算した損益分岐の見方

Microsoft Learn は、グローバルバッチをグローバル標準比で50%低コストと明記しています。ただし割引が効くのはバッチデプロイに流した分だけで、同じモデルを標準デプロイで呼べば通常単価です。

判断は次の式で足ります。「バッチ化で浮く金額」と「結果が最大24時間遅れることで発生する損失」を比べる。前者は月間トークン量に単価差を掛けた額、後者は遅延が業務に与える影響の金額換算です。月間トークン量が小さい案件では、浮く金額が実装工数を下回ります。JSONL生成・ジョブ管理・突合処理に数日かかることを踏まえると、月額のモデル利用料が数万円規模に届かない段階でバッチ化する意味は薄い、というのが実務的な線引きになります。単価はAzureの価格ページ側で改定されるため、見積もりは必ず実測値で行ってください。

大量分類・要約・文書レビューでバッチ処理を採用する具体的な条件

公式が主要ユースケースとして挙げるのは、大規模データ処理、コンテンツ生成、文書のレビューと要約、カスタマーサポートの自動化、データの抽出と分析、感情分析や翻訳といったNLPタスクです。共通点は「処理対象が事前に揃っている」ことに尽きます。

実務での採用条件は3つに絞れます。処理対象が投入時点で確定していること。結果の利用が翌営業日以降でよいこと。1件ごとの応答時間ではなく総処理量でSLAが決まっていること。この3つを満たすなら、バッチを選ばない理由がありません。

典型例が、蓄積済みの問い合わせ履歴の一括分類です。過去1年分の数万件にカテゴリとセンチメントを付与する処理は、対象が確定していて締切も緩く、オンラインで回すとTPM上限に張り付いて日中の業務システムに影響します。バッチなら専用クォータで完結。こうした処理方式の切り分けを含む設計は、生成AI開発・AI受託開発の側で要件整理から引き受けています。

対話応答・締切24時間未満・埋め込み生成をバッチから外す判断基準

見送る条件も明確にしておきます。第一に、対話型の応答。これは検討の余地なく対象外です。第二に、締切が24時間を切る処理。前述のとおり24時間は目標値であって保証ではないため、「23時に投入して翌朝6時までに欲しい」という設計は破綻し得ます。夜間バッチをバッチAPIで組むのは筋が悪い、と言い切れます。

第三に、埋め込みの大量生成です。台帳段階ではバッチ向きの用途として想定していましたが、公式のバッチ手順ページに掲載されている入力例は chat completions と responses の2系統のみで、埋め込みエンドポイントを対象にした記述・入力例は確認できませんでした（2026年8月時点）。ベクトル生成の一括処理をバッチ前提で見積もるのは避け、対応可否を事前に確認するか、標準デプロイ側で並列度を上げる構成を第一候補にしてください。

迷いやすいのが、スループット確保との比較です。処理が常時流れ続けていて待てないなら予約課金、溜めて流せるなら非同期のバッチ。この2つは代替関係ではなく、締切の有無で機械的に切り分けられます。

本番運用で詰まる制約と回避策：未対応機能・クォータ枯渇・版差異

ここまでの手順どおりに組んでも、本番投入の直前で止まる要因がいくつか残ります。事前に潰せるものばかりです。

Assistants APIとOn Your Data非対応時の設計の組み替え方

2026年8月時点で、バッチは Assistants API との統合と Azure OpenAI On Your Data 機能との統合に対応していません。この2点は公式ページに明記されています。

影響は小さくありません。社内文書を参照させる回答生成を On Your Data で組んでいる場合、そのままバッチへ載せ替えることはできません。回避策は、検索処理を自前で実装してプロンプトに文脈を埋め込み、生成部分だけをバッチに渡す形へ組み替えること。確定した文脈込みのJSONLを作ってから投入します。工程は増えますが、生成コストが半分になる規模なら見合う組み替えです。

エンキュートークン枯渇時の指数バックオフによるジョブ投入キュー

ジョブが大きすぎてエンキュートークン上限に達すると、ジョブ作成が失敗します。この対策として、一部のリージョンでは失敗を即座に返す挙動（フェイルファスト）を利用し、指数バックオフで複数のバッチジョブをキューに積む方式がサポートされています。

仕組みは単純です。ジョブ作成が枠不足で失敗したら待機時間を伸ばしながら再試行し、先行ジョブが最終状態に達してエンキュートークンが解放された時点で次のジョブが自動的に開始される。1つの巨大なジョブを作るより、分割したジョブを再試行付きで投入するほうが、クォータの上限に対して素直に流れます。数十万件規模を扱うなら、投入側にこのキュー実装を最初から入れておくのが定石です。

api-versionとモデル世代の食い違いで検証が落ちる場面

古いAPIバージョンでもバッチ自体は動きます。ただし新しいモデルは古いバージョンでは使えません。公式は例として、o3-mini は 2024-10-21 より後にリリースされたためそのバージョンではサポートされない、と説明しています。新しいモデルをバッチで使うなら v1 API を使う、というのが公式の案内です。

この食い違いは、APIバージョンを固定している現場ほど起きやすい障害です。モデルだけを新世代に差し替えてジョブが validating で落ちる、という形で表面化します。バージョン指定の考え方はapi-versionの固定と追随の判断で整理しているため、バッチ導入と同時に方針を見直しておくと事故が減ります。

よくある質問

Batch APIの検討でよく挙がる論点を、公式ドキュメントの記載に沿って5点整理します。

Azure OpenAIのBatch APIは料金がどれくらい安くなりますか？

Microsoft Learn は、グローバルバッチをグローバル標準デプロイ比で50%低コストと記載しています（2026年8月時点）。割引はバッチデプロイに流した要求にのみ適用され、同じモデルを標準デプロイで呼んだ分は通常単価です。実際の単価はAzureの価格ページ側で管理され改定もあるため、見積もり時は対象モデル・対象リージョンの最新値を確認してください。

バッチジョブが24時間を超えた場合はどうなりますか？

24時間はSLAではなく目標ターンアラウンドです。公式は「時間がかかるジョブは期限切れにならない」と明記しており、超過しても処理は継続します。状態値には expired が定義されていますが、いつでも取り消しは可能で、取り消した場合は完了済みの結果が返り、その分だけが課金対象になります。締切が厳格な処理をバッチに載せない、という設計判断のほうが確実です。

Global-BatchデプロイとPTUはどちらを選ぶべきですか？

締切の有無で切り分けます。結果を24時間待てるならバッチ、待てずに安定したスループットが要るならPTUです。バッチは単価が半額になる代わりに完了時刻を制御できず、PTUは容量を確保する代わりに使用量にかかわらず毎時課金が発生します。日中のオンライン処理をPTU、夜間の一括処理をバッチに寄せる併用構成も成立します。

入力ファイルが200MBを超える場合はどうしますか？

選択肢は2つです。ファイルを分割して複数ジョブとして投入するか、Azure Blob Storage を入力元とする構成に切り替えるかです。後者なら入力ファイルサイズの上限が1GBに広がり、入力ファイル数の制限も外れます。ファイルあたり10万要求という上限は別に存在するため、行数と容量の両方で分割条件を判定する実装にしてください。

バッチの結果が入力と同じ順序で返らないのはなぜですか？

要求が並列に処理されるためで、仕様どおりの挙動です。公式も「応答はJSONLバッチファイルで定義されている順序と同じ順序では返らない」と明記しています。各行に custom_id を必須で持たせているのはこのためで、突合はこの値をキーに行います。順序を前提にした後処理は、件数が増えた段階で破綻する種類の実装です。

関連記事

• Azure OpenAI Serviceのモデル一覧と選び方：バッチに載せるモデルをコンテキスト長と単価から選ぶときの判断材料
• Azure OpenAIのapi-versionとは？：バッチで新しいモデルを使うためのv1 API移行とバージョン固定の考え方