Message Batches API（メッセージバッチエスエピーアイ）とは？読み方・Anthropicが提供する50%割引非同期処理APIの仕組み・使い方・通常APIとの違いを完全解説

Message Batches APIとは

Message Batches APIとは、Anthropicが提供するClaude向けの非同期バッチ処理APIで、最大100,000リクエストを単一のジョブとしてまとめて投げ、24時間以内に結果を受け取る仕組みである。最大の特徴は、通常のMessages APIに比べて入力・出力トークンの両方が一律50%引きで課金される点だ。リアルタイム性を犠牲にしても良いオフライン処理（大量の文書要約、データセット生成、評価ジョブ、データラベリングなど）であれば、コストを半分にしながら同じClaudeの品質を享受できる。

身近に例えるなら、通常のMessages APIが「コンビニのレジで1人ずつ会計する」だとすれば、Batches APIは「宅配便の集荷便でまとめて配送して、翌日までに届けばOK」というイメージだ。急ぎではないなら宅配便の方が単価は安い、というポイントです。Anthropicは「即時性を求めない処理は安く、即時性を求める処理はそれなりに、というのは合理的な料金設計だ」というスタンスを取っており、OpenAIのBatch APIやGoogleの同等機能と並んで、LLM運用コストの最適化において欠かせないツールになっている。実務では、リアルタイム性が不要な処理は積極的にBatches APIに寄せることが、Claude運用コスト削減の最も重要なポイントですと覚えておきましょう。

Message Batches APIの読み方

メッセージバッチエスエピーアイ

メッセージバッチエーピーアイ

バッチエーピーアイ（短縮表現）

Message Batches APIの仕組み

Message Batches APIは2024年10月にAnthropicが正式提供を開始した、Claudeのプラットフォーム上で動作する非同期処理エンドポイントである。リクエストを投げてもその場で応答は返らず、ジョブが「バックグラウンドで順次処理されるキュー」に登録される構造になっている。

処理フロー

Message Batches APIの処理フロー

①リクエスト一覧をJSONLで作成

→

②POST /v1/messages/batches

→

③ジョブが処理キューに登録 (status=in_progress)

→

④24h以内に完了 (status=ended)

→

⑤結果をJSONLでダウンロード

各リクエストにはcustom_idを必須で付与する必要があり、これがレスポンスとリクエストを紐付ける一意な識別子になる。custom_idがないと「どのレスポンスが何番目の入力に対応するのか」を後から特定できないため、設計上必須の概念だ。実務では「文書ID」「ユーザーID」など、業務側で意味を持つ値を使うのがポイントです。後からマッピングテーブルを差し替える事態を避けるため、最初の設計時にどんな命名規則にするかを決めておくことが重要です。

制限事項

項目	上限
1バッチのリクエスト数	100,000件
1バッチの合計サイズ	256MB
処理完了までの最大時間	24時間（実運用は1時間以内が大半）
結果の保持期間	完了後29日間
対応モデル	Opus 4.6 / Sonnet 4.6 / Haiku 4.5 など主要モデル全て

Message Batches APIの使い方・実例

基本的な使い方（Quick Start）

import anthropic

client = anthropic.Anthropic()

# バッチ作成
batch = client.messages.batches.create(
    requests=[
        {
            "custom_id": "doc-001",
            "params": {
                "model": "claude-sonnet-4-6",
                "max_tokens": 1024,
                "messages": [{"role": "user", "content": "次の文書を3行で要約してください: ..."}]
            }
        },
        {
            "custom_id": "doc-002",
            "params": {
                "model": "claude-sonnet-4-6",
                "max_tokens": 1024,
                "messages": [{"role": "user", "content": "次の文書を3行で要約してください: ..."}]
            }
        }
    ]
)
print(batch.id)  # batch_xxxx
print(batch.processing_status)  # in_progress

結果の取得

# ステータスをポーリング
import time
while True:
    b = client.messages.batches.retrieve(batch.id)
    if b.processing_status == "ended":
        break
    time.sleep(60)  # 1分ごとに確認

# 結果ストリーム取得（JSONL）
for result in client.messages.batches.results(batch.id):
    if result.result.type == "succeeded":
        text = result.result.message.content[0].text
        print(f"{result.custom_id}: {text}")
    elif result.result.type == "errored":
        print(f"{result.custom_id} ERROR: {result.result.error}")

よくある実装パターン

パターンA: 大量文書のバッチ要約

requests = []
for doc_id, doc_text in document_corpus.items():
    requests.append({
        "custom_id": doc_id,
        "params": {
            "model": "claude-haiku-4-5",
            "max_tokens": 512,
            "messages": [{"role": "user", "content": f"次を3行で要約: {doc_text}"}]
        }
    })
batch = client.messages.batches.create(requests=requests)

向いているケース: 数千〜数万件の文書を一度に要約・分類・タグ付けしたい場合。半額で処理できるためコストインパクトが大きい。

避けるべきケース: ユーザーがリアルタイムに結果を待っているUIフロー（チャットUIの応答など）。24時間待たせるわけにはいかない。

パターンB: Prompt Cachingとの組み合わせ

requests = [{
    "custom_id": f"q-{i}",
    "params": {
        "model": "claude-sonnet-4-6",
        "max_tokens": 1024,
        "system": [{
            "type": "text",
            "text": "（巨大な共通プロンプト 10,000トークン）",
            "cache_control": {"type": "ephemeral"}
        }],
        "messages": [{"role": "user", "content": question}]
    }
} for i, question in enumerate(questions)]

向いているケース: 共通の巨大なシステムプロンプトを使う評価ジョブやQA生成。バッチ50%引き×キャッシュ90%引き＝最大95%以上のコスト削減になる。

避けるべきケース: 各リクエストでシステムプロンプトが異なる場合（キャッシュヒットしないため恩恵がない）。

アンチパターン: ステータスを毎秒ポーリング

# ⛔ 絶対NG
while True:
    b = client.messages.batches.retrieve(batch.id)
    if b.processing_status == "ended":
        break
    # 1秒ごとにAPI叩く → レート制限・無駄なリクエスト

バッチは最短でも数十分かかる前提のため、ポーリング間隔は最低1分、推奨5〜10分にすること。クラウド本番運用ならEventBridge等のスケジューラに任せ、定期的にだけステータス確認する方が筋がいい。実務では「投入時刻＋15分」を起点に5分間隔で確認する設計が現実的なポイントです。

Message Batches APIのメリット・デメリット

メリット

料金が一律50%引き：入力・出力トークンの両方が割引対象。月間数千ドル規模の処理なら数百ドル単位の節約に直結する。
大規模ジョブを1回のAPIコールで完結：100,000件まで1ジョブにまとめられるため、コード側のオーケストレーションが激減する。
Prompt Cachingと併用可能：両方の割引を重ね掛けでき、コスト最適化の幅が広い。
レート制限がリアルタイムAPIと別枠：通常APIのRPM/TPM制限とは独立して動作するため、本番システムの安定性に影響しない。
実行時間がほぼ即時のケースも多い：公式SLAは24h以内だが、実運用では1時間以内に終わることも多い。

デメリット

リアルタイム性ゼロ：チャットUIや会話型エージェントには使えない。最大24時間待たされる前提が必要。
結果の保持期間が29日：これを過ぎると結果は消えるため、自前のストレージに退避する設計が必須。
Streaming非対応：トークンを逐次受け取るストリーミング応答は使えず、最終結果のみ返ってくる。
ジョブのキャンセルは「投入直後のみ」可能：処理開始後はキャンセルできず、料金は発生する。

Message Batches APIと通常Messages APIの違い

Message Batches APIと通常のMessages APIは「Claudeに同じプロンプトを送って同じ応答を得る」という点では同じだが、設計思想と運用面で大きく異なる。下記の比較表で違いを整理する。

観点	Message Batches API	通常 Messages API
処理方式	非同期バッチ	同期（即時応答）
料金	通常価格の50%引き	表示価格通り
応答時間	最大24時間（多くは1時間以内）	数秒〜数十秒
1リクエスト当たり最大件数	100,000件 / 256MB	1件のみ
ストリーミング	非対応	対応（SSE）
代表的な用途	大量文書要約・データセット生成・評価	チャットUI・対話エージェント・コーディング支援
レート制限の枠	独立（本番APIに影響しない）	RPM/TPMの本番枠を消費

つまり「即時性を捨てれば半額になる」というシンプルな構造であり、ユースケースに応じて使い分けるのが正解です。リアルタイムが必要ない処理は積極的にBatches APIに寄せるのが、現代のClaude運用の鉄則と言える。「リアルタイム性は必須か？」を毎回問い直す習慣をチームに浸透させることが重要です。

Message Batches APIに関するよくある誤解

誤解1: 「バッチAPIは品質が下がる」

なぜそう誤解されるのか：「料金が半額になる」と聞くと、人は本能的に「品質も半分なのではないか」と推測しがちだ。クラウドインフラでも「スポットインスタンスは安いが落ちやすい」のような料金と品質のトレードオフが一般的なため、その背景知識が混同を招いている。実際にX（旧Twitter）でも「バッチAPIだと出力が雑になった」という勘違い投稿が散見される。

正しい理解：Anthropic公式ドキュメントでも明言されているとおり、バッチ処理と同期処理で応答品質に差は一切ない。同じモデル・同じパラメータで投げれば完全に同じ応答が返る。違いは「いつ返るか」だけだ。