Batch APIの50%割引はどのように計算されますか？例外はありますか？
割引は標準料金の入力・出力トークン両方に適用され、それぞれ半額になります。例えば、Claude Sonnetの標準入力料金が100万トークンあたり$3なら、Batch APIの入力料金は$1.50になります。出力も同様です。
注意すべき例外：プロンプトキャッシング。Batch APIとプロンプトキャッシングを同時に使用する場合、キャッシュトークンの料金ロジックはより複雑になります——詳細は現在の公式料金ページを確認してください。また、モデルによって基本料金が異なります。50%割引は一貫していますが、絶対金額は使用するモデルによります。大量使用のケースでは、デプロイ前に小規模テストで実際のコストを見積もることが、料金ページの数字だけに頼るより正確です。
Batchジョブが完了したことをどうやって知りますか？
2つの方法があります。第一にポーリング：受け取ったbatch_idを使ってステータスエンドポイントを定期的に呼び出します。現在のステータス（in_progress、ended、cancelingなど）と完了したリクエスト数が返されます。ジョブの規模に応じて、数分から1時間ごとにチェックするループを設定します。
第二にwebhook（独自のサーバーがある場合）：Batch送信時にwebhook URLを指定すると、ジョブ完了時にAnthropicがエンドポイントを呼び出します——ポーリング不要です。自動化された本番パイプラインにはwebhookがよりクリーン、スクリプト式の一回限りのジョブにはポーリングがシンプルです。どちらの方法でも、最終ステップはJSONL結果ファイルのダウンロードです。
思いもよらなかったBatch APIの使用例はありますか？
最もよく見落とされますが価値の高い用途は自動評価（eval）です。AIプロダクトを開発しているなら、モデル出力の品質を評価する必要があります——これは通常、Claudeが別のClaudeの出力を評価する（LLM-as-judgeパターン）ことを意味します。このようなジョブは通常数百から数千の評価サンプルが必要で、Batch APIに最適です。50%割引により、コストを心配せずに大規模な評価を実行できます。
もう一つよく見落とされるのは知識ベース構築です：会社のドキュメント・FAQ・商品説明を構造化フォーマットに一括変換したり、embeddingの元となるデータを事前生成したりすること。これらのタスクはリアルタイムのレスポンスを必要としませんが、RAGシステム設計における重要な準備ステップです。Batch APIを使うことで費用対効果が最も高くなります。
上級：Batch APIとプロンプトキャッシングを組み合わせるベストプラクティスはありますか？
同時に使用できますが、両者の組み合わせのロジックを理解することが助けになります。プロンプトキャッシングは、同じ長いプレフィックス（例：非常に長いシステムプロンプト）を複数のリクエストで再利用させます——最初のリクエストはフル料金、後続のリクエストはキャッシュ部分のわずかな料金のみ。Batch APIはそのすでに削減されたコストをさらに50%割引します。
最も効果的な組み合わせ：すべてのリクエストが長いシステムプロンプトまたは前置文書を共有しているが、各リクエストのユーザー入力が異なる場合。この場合、長い文書をキャッシュ可能なプレフィックスに入れ、すべてのリクエストをBatch API経由で送信します——2つの割引が重なり、共有プレフィックスのトークンコストが非常に低くなります。注意点として、Batch APIのプロンプトキャッシング動作はリアルタイムAPIと若干異なる場合があります。実際のキャッシュヒット率をテストしてコストが期待通りかを確認してください。
大量のデータ評価・訓練データのラベリング・コンテンツの一括生成など、バッチ処理タスクにClaude APIを使っているなら、不要な費用を払っているかもしれません。AnthropicのBatch APIはこのようなワークロードのトークンコストを半額にします。代わりに、結果を受け取るまで最大24時間待つ必要があります。この記事では、仕組み、使うべき場面、注意点を説明します。
標準のClaude API（リアルタイムAPI）は同期モデルです：リクエストを送り、数秒待ち、レスポンスを受け取ります。Batch APIは非同期です：数百から数万のリクエストを一度に送信し、システムが空き容量で処理し、24時間以内にすべての結果を受け取ります。
本質的な違いは時間とコストのトレードオフです。リアルタイムAPIは数秒で回答が得られますが、フルのトークン料金がかかります。Batch APIはAnthropicの都合の良いときにタスクを処理させる代わりに、50%割引が適用されます。現在、Batch APIの割引は入力・出力トークン両方に適用されます。
判断基準は一つ：このタスクに時間的な要件はあるか？ なければ、Batch APIがほぼ常により割安な選択です。
最適なシナリオ：データセットのラベリング（1万件のデータをClaudeに分類させる）、大規模なコンテンツ評価（モデル出力品質のスコアリング、自動評価実行）、一括文書処理（数百の契約書を構造化データに要約）、オフラインのコンテンツ生成（FAQや商品説明を大量に事前生成）。これらに共通するのは、各結果が数秒で届く必要はなく、今日か明日に届けばよいという点です。
向かないシナリオ：ユーザーが待っているあらゆるインタラクション（チャットボット、リアルタイムQ&A）、前のステップの結果に依存する連鎖タスク、分単位の厳しい締め切りがあるタスク。
3ステップです。まず、リクエストをJSONL形式にパッケージ化します——各行は独立したリクエストオブジェクトで、custom_id（後で結果を照合するための識別子）とAPIリクエストパラメータを含みます。次に、ファイルをBatch APIエンドポイントに送信すると、batch_idが返されます。最後に、batch_idでステータスをポーリングし（またはwebhookを設定し）、ステータスがendedになったら結果ファイルをダウンロードします。
結果もJSONL形式で、リクエストごとに1行、custom_idとレスポンス内容が含まれます。送信時にcustom_idの設計をしっかり行い、結果が届いたときに元のリクエストと正しく照合できるようにしましょう。
第一に、24時間は上限であり保証ではありません。Anthropicのドキュメントは「通常1時間以内に完了するが、最大24時間かかる場合がある」と述べています。時間的に重要な作業のクリティカルパスにBatch APIの完了時間を組み込まないでください。
第二に、Batch APIは標準APIと同じモデルをサポートしますが、すべての機能をサポートするわけではありません。ツール使用（function calling）とビジョンはBatch APIでサポートされています。新しい機能の一部はサポートが遅れる場合があるため、構築前に最新ドキュメントを確認してください。
第三に、1つのBatchにはリクエスト数の上限があります（現在100,000リクエストまたは256MB、先に達した方）。これを超える場合は、複数のBatchに分割して送信する必要があります。
リアルタイムのレスポンスを必要としないバッチ処理タスクにClaude APIを使っているなら、Batch APIを使えばモデルやプロンプトを変えずにAPIの費用を半額にできます——変わるのはリクエストの送信方法だけです。データ集約型のAIアプリケーションにとって、これは通常最も速くて手間のかからないコスト最適化手段です。