バッチの上限と期限

先に結論

1つのバッチは、10万件のリクエストまたは256MBの、先に達したほうが上限です。処理は多くが1時間以内に終わりますが、24時間で終わらなければ期限切れになります。結果をダウンロードできるのは作成から29日間で、その後もバッチ自体は見られますが結果は取れません。

上限の表

段階ごとの枠（公式のレート制限のページ）

この枠は全モデルで共有です。モデルごとの枠ではありません。

手順

1. リクエストを1件ずつ custom_id つきで並べ、バッチを作る
2. 作成時の応答に processing_status（最初は in_progress）と expires_at が入る
3. ended になるまで間隔をあけて確認する
4. 各リクエストの結果（成功・エラー・期限切れ・取り消し）を読む。入力の検証エラーは、バッチ全体の終了後に返るので、本番の前に同じ形を通常の API で1件試す

具体例：26万件を投入するときの分け方

Start 段階では、キューに置ける件数は20万件、1バッチは10万件までです。26万件を処理したいなら、10万件・10万件・6万件の3バッチに分けますが、同時にキューに置けるのは20万件までなので、3つ目は先の2つのどちらかが終わってから投入することになります。Build 段階（キュー30万件）なら3つとも一度に置けます。分けるときは、custom_id に元データの通し番号を入れておくと、結果の突き合わせが楽です。256MBの上限にも注意が要ります。1件が大きい文書（長い資料を各リクエストに含める）の場合、件数より先に大きさで上限に達します。

よくある取り違え

• 「24時間たてば結果が出る」と読む：24時間で終わらなかった分は期限切れ（expired）になる。結果が欠ける
• 「結果は消えない」と読む：ダウンロードできるのは作成から29日間まで
• 「バッチの枠はモデルごと」と読む：リクエスト毎分とキューの上限は全モデル共通
• 「入力の誤りはすぐ分かる」と読む：各リクエストの検証エラーは、バッチ全体の終了後に返る。事前に通常の API で1件試す
• 「ゼロデータ保持の契約でも使える」と読む：バッチは対象外で、29日の保持が要る

自分の環境で確かめるには

本番の前に、5件だけのバッチを作って流してみます。作成時の応答の expires_at を見て、期限が24時間後になっていること、processing_status が in_progress から ended に変わること、結果に成功・エラーの区別が付いていることを確かめます。その5件の中に、わざと入力の誤りを1件混ぜておくと、検証エラーがバッチ全体の終了後に返ることも目で確認できます。

この面で確かめていないこと

• 期限切れになったときの課金の扱い（読んでいない）
• 需要が高い時間帯の遅延の実際（公式は遅くなりうると書く）

よくある質問

次に読むページ