Claude Batch APIの50%割引はどこまで効くのか、料金計算機に実装しながら調べた
自作のLLM料金計算機にバッチAPIとプロンプトキャッシュの計算を組み込むため、各社のバッチ料金を調べ直した。50%割引の仕組み、キャッシュとの重ねがけの効き方、向くワークロードと向かないワークロードを正直に書く。
2026年7月に、自作のLLM API料金計算機へバッチAPIとプロンプトキャッシュの計算を足した。「バッチON/OFFのチェックボックスを1個置くだけ」のつもりで始めたのに、実装のためには各社の割引が正確にどこへ掛かるのかを把握する必要があって、結局それぞれの料金ページを読み比べる羽目になった。
この記事は、その過程で理解したClaude Batch API（Message Batches API）の話だ。先に断っておくと、自分は大量バッチを本番で回しているわけではない。Claude APIの実運用は個人サービスのAI日記生成くらいで、これは後述する通り「バッチが使えない側」のワークロードだ。だからここに書くのは運用武勇伝ではなく、計算機を正しく作るために仕様と料金を調べ尽くした人間の整理だと思ってほしい。
仕組みは単純。「即時応答を諦めると全部半額」
Batch APIは、複数のMessagesリクエストをまとめて投げて非同期で処理してもらう仕組みだ。結果は24時間以内に返る（実際にはもっと早く終わることが多い、とドキュメントにはある）。その代わり、入力も出力も**標準APIの50%**で課金される。
安くなる理屈も分かりやすい。リアルタイム応答の保証を外せば、Anthropic側は空いているキャパシティで都合よく処理できる。ユーザーが「いつでもいい」と譲る分の対価が半額、という取引だ。
具体的な単価で言うと、Claude Sonnet 5は標準で入力$2/出力$10（100万トークンあたり）なので、バッチだと$1/$5になる。ここで気づいたのが、バッチのSonnet 5は、標準のHaiku 4.5（$1/$5）とちょうど同じ単価になるということ。急ぎでない処理なら「品質を落としてHaikuにする」ではなく「Sonnetのままバッチにする」という選択肢が同じ値段で手に入る。計算機に両方並べて初めて見えた比較だった。
キャッシュとの重ねがけ。「95%削減」の数字は半分本当で半分誤解を生む
バッチ割引はプロンプトキャッシュとも併用できて、割引はキャッシュ読み取りにも掛かる。Sonnet 5のキャッシュ読み取りは通常$0.2（入力の1/10）なので、バッチと重ねると$0.1。標準入力の$2と比べれば1/20、つまり95%オフだ。計算機でもこの順で計算している（キャッシュヒット率を先に適用して、バッチ対応モデルなら全体を半額）。
ただしこの「95%」は入力の、しかもキャッシュにヒットした部分だけの話だ。出力側は最大でも50%オフまでしか下がらない。以前料金の見積もり方の記事に書いた通り、生成系のワークロードは請求の大半が出力に乗る。そういう処理では、キャッシュを完璧に効かせても請求全体は半分強までしか減らない。「最大95%削減」という宣伝文句だけ見て見積もると外す。
もうひとつ、調べていて引っかかった点。バッチは処理順もタイミングも保証されないので、キャッシュが狙い通りヒットするかはやってみないと分からない面がある。共通プロンプトをキャッシュする設計にしても、ヒット率100%を前提に見積もるのは危ない。計算機のキャッシュヒット率をスライダーにしたのはこのためで、0%と70%と100%で月額がどう変わるかを見てから判断する方が現実的だ。
計算機側で決めたこと: 一律50%と確認できたモデルだけバッチ対応にした
当初は「バッチON」で全モデルを半額にする実装だった。でも調べてみると、「すべての使用量が一律50%オフ」というシンプルな体系で確認できたのはAnthropicとOpenAIで、他のベンダーは安く回す仕組み自体はあっても、料金の掛かり方が同じ「半額チェックボックス」には素直に落とし込めなかった。
間違った数字を表示するくらいなら出さない方がいい、という判断で、計算機ではバッチ対応と確認できたモデルだけ半額にして、それ以外は「バッチ非対応」と表示するようにした。単価セルは全部手で編集できるので、自分の使うモデルの割引条件を把握しているなら上書きすれば済む。LLMの料金は本当にすぐ変わるので、この記事の具体値も鵜呑みにせず計算機か公式の料金ページで確認してほしい。
向かないワークロードの典型が、自分の本番用途だった
冒頭に書いた通り、自分がClaude APIを実運用しているのは日記サービスのAI生成機能で、ユーザーがボタンを押して結果を待つ同期処理だ。ここにバッチは使えない。「24時間以内のどこか」で返ってくる応答を待たせるUIは成立しない。
つまりバッチAPIは「使えば必ず得」ではなく、ワークロードを非同期に倒せるかどうかが全てだ。向くのは時間に追われないまとめ処理で、たとえば過去記事のメタデータ一括生成、ログの定期分析、コンテンツの一括翻訳のような類い。逆にチャットやインタラクティブな生成は、どれだけ量があっても対象外になる。
意外だったのは、最小件数の縛りがないこと。1件だけ投げても50%割引が適用される。「バッチ」という名前から大量前提のイメージがあったが、実際は「急がない処理の割引料金」と捉えた方が正しい。
設計面で効いてくる仕様は2つ。処理順序が保証されないので、リクエストと結果はcustom_idで突き合わせる前提で組むこと。そして「最悪24時間」を許容できるスケジュールにすること（失敗したら翌日リトライ、が許せるか）。APIの形はこれだけ見れば掴めると思う。
batch = client.messages.batches.create(
requests=[
{
"custom_id": f"post-{post_id}", # 結果の突き合わせに必須
"params": {
"model": MODEL,
"max_tokens": 1024,
"messages": [{"role": "user", "content": prompt}],
},
}
for post_id, prompt in prompts
]
)
# あとはbatch.idをポーリングして、ended後にresults()をcustom_idで回収する投げっぱなしにできる代わりに、送信後のリクエスト追加・変更はできない。1バッチに詰められる件数やサイズにも上限があるが、この手の制限値は改定されるので公式ドキュメントを見てほしい。
調べ終えての結論はシンプルで、バッチAPIは「コードや使い方を工夫して絞り出す削減」ではなく、**非同期を許容すると宣言するだけで貰える50%**だ。だからこそ、まず自分の処理のうちどれが非同期に倒せるかを仕分けるのが先で、金額の話はその後でいい。仕分けができたら、トークン数をLLM API料金計算機に入れてバッチのチェックを入り切りしてみると、月額でいくら違うのかが一目で分かる。