バッチと出力制限｜「待てる処理」と「出力の長さ」を制御する

• バッチ API：結果を数時間待てる処理をまとめて依頼すると、主要ベンダーで約半額の割引が適用されます（夜間バッチ・一括変換・定期レポート向き）。
• max_tokens：出力の上限。モデルの暴走長文（「同じ内容を言い換えるだけの結論」など）を物理的に止めます。
• JSON mode・構造化出力：出力形式を固定し、「読みにくいから作り直し」を防ぎます。再生成は全トークンの再課金です。
• 分割実行：巨大な処理は分割し、失敗時のやり直し範囲を最小化します。

• max_tokens を必須化：用途別の上限表を作る（分類 50／要約 500／説明文 1,000 など）。上限に達した割合を週次で見直す。
• 構造化出力に寄せる：後処理でパースできる JSON にし、表示はアプリ側で行う。「整形のやり直し」を構造上なくす。
• バッチに移せる処理を棚卸し：即時性が不要な処理（一括タグ付け・音声書起こし後処理・定期集計）をリスト化し、バッチ API へ。
• 大きな処理は分割：100 ページの処理を 10 ページ×10 リクエストに。失敗時の再実行は失敗ブロックだけ。

• max_tokens が厳しすぎると回答が途切れる（finish_reason: length）。途切れ率を監視する。
• 「短く」と指示するだけでは長さは安定しない。字数・項目数・JSON スキーマで固定する。
• バッチ化は「入力と出力の両方」が半額になるため、術その3（キャッシュ）と重ねて効く。

これで 5 つの術はすべて解説しました。総合ページのチェックリストに戻って、自社の運用と照らし合わせてみてください。