効率的なバッチ処理戦略

CCA-F 試験のタスクステートメント 4.5「効率的なバッチ処理戦略を設計する」は Domain 4（Prompt Engineering & Structured Output、20% の比重）内にあり、ブループリント上でワークロードの形状について明示的に問う唯一のタスクステートメントだ。試験は、アーキテクトが大量の作業を同期型 Messages API 呼び出しから非同期型 Message Batches API に移行すべき状況を認識できるか、custom_id を使用して何千もの結果をアプリケーションレコードに相関付ける方法、50% バッチ割引と 24 時間 SLA がビジネスのレイテンシ要件とどう相互作用するか、そして各アイテムのエラーをバッチ全体を失敗させずに処理する方法をテストする。コミュニティの合格報告は一貫して、「コストを節約するために常にバッチを使用する」という受験者がレイテンシに敏感なシナリオ設問で失点し、「安全のために常にリアルタイムを使用する」という受験者がスループットとコストのシナリオ設問で失点すると指摘している。

本学習ノートは、CCA-F 受験者がアーキテクチャレベルで設計することが求められるバッチ処理の全領域を解説する。Message Batches API のプリミティブ、50% 割引と 256 MB / 100,000 リクエストの構造的制限、24 時間の完了 SLA と 29 日の結果保持ウィンドウ、custom_id の相関コントラクト、アイテムごとの params を持つリクエスト配列の形状、processing_status と in_progress_requests のポーリングパターン、レイテンシ許容度とボリュームをバッチ対リアルタイムに対応付ける判断マトリックス、アイテム単位のエラー対バッチレベル失敗のセマンティクス、失敗した custom_id の値のみを再送信する再試行戦略、スループット飽和戦術、そしてバッチ設計を最も多く扱う二つの CCA-F シナリオ（structured-data-extraction と claude-code-for-continuous-integration）を扱う。トラップセクション・練習アンカー・五問の FAQ が本章節を締めくくる。

Message Batches API とは何か — Claude のための非同期バルク推論

Message Batches API は Anthropic プラットフォームの専用エンドポイントであり、Messages API リクエストのリストを受け取り、それらを Claude に対して非同期で処理し、バッチが完了したら照合された結果を返す。同期型 Messages API とはアーキテクチャ的に別物だ：バッチ経由で送信されたリクエストは元の HTTP 呼び出しでレスポンスを返さない；代わりに、アプリケーションはバッチを送信し、バッチ識別子を受け取り、後でポーリングするか結果の準備ができたという通知を受け取る。

Message Batches API は、本番での Claude ワークロードの大部分がインタラクティブでないという事実から生まれている。ドキュメントレイクを構造化抽出でバックフィルする・前日のトランスクリプトの夜間レビューを実行する・研究データセットを処理する・一万件の受信申請をスコアリングする——これらのワークロードはどれも 2 秒でのレスポンスを必要としない。作業が正確で、コストが低く、スループットが高いことが必要だ。バッチ API はこれらのトレードオフを明示的にするアーキテクチャ的プリミティブだ。

同期型 Messages API vs 非同期型 Batch API を一文で表すと

同期型 Messages API はインタラクティブなレイテンシに最適化されたリクエスト・レスポンスパイプであり、Message Batches API はスループットとコストに最適化された送信・収集キューだ。どちらかのエンドポイントで有効なすべてのリクエストボディは、もう一方でも有効だ——モデル・メッセージ・ツール・system prompt・JSON スキーマ・tool_choice・max_tokens・temperature など、すべて同一だ。変わるのはレスポンスがいつどのように到着するかだけだ。

バッチ処理の利用ケース — 大量抽出・非同期レビュー・データセット処理

CCA-F シナリオ設問はバッチに適したワークロードを非常に具体的にフレーム化する。これらのフレームを素早く認識することが試験当日の正答への最速ルートだ。

大量構造化データ抽出

標準的なバッチワークロードは、ドキュメントコーパスにわたる構造化データ抽出だ：候補者スキーマに解析する一万件の履歴書・分類タクソノミーでラベル付けする五万件のサポートチケット・ベンダーを考慮した JSON 形状に抽出する十万件の請求書。各ドキュメントは独立しており（ドキュメント間の依存性なし）、各抽出は同じ prompt テンプレートにドキュメントごとの content 置換を持ち、ビジネスの締め切りは即時ではなく翌日だ。これは structured-data-extraction CCA-F シナリオクラスターが最も重点的にテストする形状だ。

非同期マルチパスレビュー

マルチパスレビューアーキテクチャ（タスク 4.6）はしばしば作業を二〜三つの異なる prompt に送る——抽出、次に品質チェック、次に照合パス。レビューサイクルが大きなコーパスにわたって夜間または週次で実行される場合、各パスをバッチ化することがデフォルトだ。バッチ API が第一パスを処理し、結果が第二パスにシードされ、続く。パス間のレイテンシは秒ではなく時間で測られ、50% 割引は各パスで積み重なる。

データセットのラベリングと評価

オフラインモデル評価パイプライン——一千件の prompt のホールドアウトテストセットを Claude に通してメトリクスを計算する、またはタクソノミーを比較するためにトレーニングセットを再ラベリングする——は典型的なバッチワークロードだ。人間が待っておらず、ボリュームは高く、コストは繰り返しで増幅され、レイテンシ要件は事実上存在しない。

CI/CD バルク分析

claude-code-for-continuous-integration シナリオでは、夜間パイプラインが前日のプルリクエスト全体で変更されたすべてのファイルを分析したり、トリアージラベルのためにすべてのオープンな issue をレビューしたりすることがある。これらは非インタラクティブ・大量・翌日締め切りの典型的なバッチ候補だ。ただし、コミットのたびに PR ごとに実行する同じパイプラインは開発者が待っているため同期型 Messages API 呼び出しが必要だ。

Message Batches API の構造 — 単一 API 呼び出しで複数リクエストを送信する

バッチ送信は requests 配列を本文に持つ単一の HTTP POST だ。配列の各要素は、呼び出し側が定義した custom_id でラップされた完全でスタンドアロンの Messages API リクエストだ。バッチ全体は一つの送信として成功または失敗するが、内部のリクエストは独立して処理・スコアリングされる。

リクエスト配列の形状

requests の各要素には二つのトップレベルフィールドが含まれる：

• custom_id — 呼び出し側が選択した文字列（バッチ内でユニーク）。このリクエストとその最終的な結果を相関付けるために使用される。
• params — この個別リクエストの完全な Messages API ボディ：model・max_tokens・messages、オプションで system・tools・tool_choice・temperature、その他の標準的な Messages API パラメーター。

すべての custom_id はそのバッチ内でユニークでなければならない；重複は送信時に拒否される。custom_id の値は呼び出し側が定義する文字列だ——Anthropic がそれを生成することは決してない。これはバッチ設問で最も見落とされがちなアーキテクチャ上の事実だ。

送信レスポンス

バッチを送信すると、エンドポイントはバッチ ID・processing_status（初期値は in_progress）・リクエスト数（total・processing・succeeded・errored・canceled・expired）、および作成日時・有効期限タイムスタンプを含むバッチオブジェクトを返す。このバッチオブジェクトは完了をポーリングし後で結果を取得するために使用するハンドルだ。

構造的制限

Message Batches API はバッチごとに二つの構造的上限を適用する：

• バッチごとに最大 100,000 リクエスト。
• バッチごとに最大 256 MB の総ペイロードサイズ。

より多くのボリュームを必要とするバッチは複数の送信に分割する。両方の上限はハードだ——いずれかが超過した場合、送信は拒否される。

バッチ価格設定 — リアルタイム API 呼び出しに対する 50% コスト削減

バッチ処理の経済的根拠は、同じモデルへの同期型 Messages API 呼び出しと比較した入力・出力トークンの 50% 割引だ。これは試験が迷いなく知ることを求める見出しの数字であり、シナリオ設問が設定するすべての「バッチ対リアルタイム」コスト計算の転換点だ。

割引の適用方法

50% 割引はトークンレベルの請求に適用される——バッチされたリクエスト内の入力トークン・出力トークン・（該当する場合は）キャッシュされたトークンはすべて同期レートの半額で請求される。割引はサポートされている Claude ファミリー内でモデルに依存しない——Haiku・Sonnet・Opus のバッチトークンはすべて各同期価格から同じ 50% 削減を受ける。割引はリベートではなく；請求時に適用される。

割引が適用されないもの

割引はモデル推論トークンにのみ適用される。構造的なバッチ制限（100,000 リクエスト・256 MB）は変わらない。24 時間 SLA を免除しない。システムの非バッチ部分には適用されない——パイプラインがバッチ前にアイテムをプリスコアリングするためにリアルタイム呼び出しを行う場合、そのプリスコアリング呼び出しは全額の同期価格で請求される。

経済的判断のフレーミング

アーキテクチャレベルでは、50% のバッチ割引は三つの条件が同時に成立する場合に最も重要だ：（a）絶対ドルの差が重要になるほどボリュームが十分に高い；（b）個別の結果を人間が待っていない；（c）24 時間 SLA がビジネスの締め切りと両立する。三つのうちいずれかが成立しない場合、50% 割引は注意散漫であり、真のアーキテクチャ的選択は他にある。

バッチ SLA — 24 時間の処理保証と利用可能ウィンドウ

Message Batches API のサービスレベルのコミットメントは、送信されたバッチが 24 時間以内に完了することだ。この数字は 4.5 タスクステートメント全体で最もトラップの多い事実であり、受験者は毎回の試験でこれに対してスコア付きのポイントを失っている。

「24 時間以内」は上限であり目標時間ではない

24 時間 SLA は通常条件下でプラットフォームがバッチを完了するための最大時間だ。バッチの大多数——特に小さなもの——は数分から数時間で完了する。「24 時間以内」は「24 時間のマーク」を意味しない。すべてのバッチがちょうど 24 時間かかると仮定する答えは誤りだ。SLA は「通常は 24 時間よりはるかに速いが最大 24 時間かかることがある」という正しいフレーミングだ。

結果保持ウィンドウ

バッチが完了すると、結果は作成から最大 29 日間取得可能だ。保持ウィンドウの後、結果は削除され回復できない。長期保存が必要なアプリケーションは、有効期限前に自身のシステムオブレコードに結果を引き出して保存しなければならない——バッチ結果は耐久性のあるアーカイブではない。

期限切れバッチ

バッチが最大処理ウィンドウ（24 時間）内に完了しない場合、expired の終端状態に移行する。完了しなかった内部のリクエストは expired リクエスト数にカウントされ、バッチ内の部分的な成功は依然として custom_id によって取得可能だ。期限切れバッチは再開できず、失敗または期限切れのアイテムは新しいバッチとして再送信しなければならない。

custom_id フィールド — バッチリクエストをアプリケーションレコードに相関付ける

custom_id コントラクトはバッチ API とアプリケーションデータベースの間のアーキテクチャ的な橋だ。これを間違えることが最も一般的な実装レベルのバッチミスだ。

custom_id は常に呼び出し側が定義する

custom_id はあなたが選択する。Anthropic ではない。バッチリクエストには「システム生成」の識別子はない。意味のある custom_id を供給しない場合、相関付けできない結果セットを受け取ることになり、リクエストの順序（API 境界を越えて安定していることが保証されていない）のような脆弱な発見的手法からアイデンティティを再構築しなければならない。

安定したキーから custom_id を導出する

本番の実践は主キーから custom_id を導出することだ。チケットラベリングバッチには ticket-{{id}} を使用する。履歴書解析バッチには resume-{{uuid}} を使用する。マルチパスレビューには pass{{n}}-{{record_id}} を使用する。これにより結果ストリームがデータベースに対して自明に結合可能になる。

各バッチ内でのユニーク性

custom_id の値は単一のバッチ送信内でユニークでなければならない。バッチをまたいでユニークである必要はないが、バッチをまたいだ再利用はコードの悪臭だ——同じ作業を二回送信していることを示唆する。バッチ N の失敗したアイテムをバッチ N+1 に再試行する場合、データベースのアップサート論理が同じレコードへの更新として扱うよう同じ custom_id の値を使用する。

順序付けよりも相関付け

結果の順序がリクエストの順序と一致すると決して仮定しないこと。バッチ API はリクエストを最も効率的な順序で処理し、結果ストリームは自由にインターリーブまたは並べ替えられる。常に custom_id で相関付ける；配列インデックスで行わない。

バッチ結果のポーリング — 完了ステータスの確認と結果の取得

バッチの完了はプッシュ通知を待つのではなく、バッチの processing_status フィールドをポーリングすることで検出する。CCA-F ではポーリングパターンを認識し、適切なポーリング頻度を選択することが求められる。

処理ステータスの値

各バッチはトップレベルの processing_status を持ち、以下を経過する：in_progress（作業はまだ行われている）・canceling（キャンセルリクエストが処理中）・ended（すべてのリクエストが完了・エラー・キャンセル・期限切れで終端状態に達した）。processing_status が ended になったら結果の取得準備ができている。

リクエストレベルのカウント

バッチオブジェクト内の request_counts ブロックは processing・succeeded・errored・canceled・expired のカウントを追跡する。これらのカウントはバッチの進行に伴い更新され、結果を取得せずに部分的な成功と完全な失敗を区別できる。

ポーリング頻度のガイダンス

ほとんどのバッチは 24 時間ウィンドウよりずっと前に完了するため、指数バックオフのポーリング頻度が標準だ：最初の数分は 30 秒ごとにポーリングし、次に 1 分ごと、次に 5 分ごと、SLA ウィンドウの末尾では約 15 分ごとに上限を設定する。ステータスエンドポイントを毎秒叩くのは無駄だ；1 時間ごとにポーリングすると完了後に長い無駄なギャップが生じる可能性がある。5〜15 分ごとのシンプルなスケジュールポーリングほとんどのパイプラインに適切だ。

結果の取得

processing_status が ended になったら、専用の結果エンドポイントが改行区切り JSON（JSONL）ストリームを提供する。元のリクエストごとに 1 行、各行に custom_id のタグが付く。各行には成功時の message またはアイテム単位の失敗時の error ブロックのいずれかが含まれる。29 日の保持ウィンドウ内に JSONL ストリームをシステムオブレコードに取り込む。

バッチリクエスト構造 — アイテムごとの custom_id と params を持つ requests 配列

トップレベルの配列形状を超えて、アイテムごとの params オブジェクトは専用の注意を払う価値がある。CCA-F 試験は受験者が各バッチされたリクエストが完全なスタンドアロンの Messages API 呼び出しであることを理解しているかをテストするからだ。

各アイテムは独自の system prompt・ツール・モデルを持てる

バッチ API はリクエスト全体の均一性を強制しない。アイテム 1 が Sonnet と一つのツールセットを使用し、アイテム 2 が Haiku と別のツールセットを使用し、アイテム 3 が Opus でツールなしを使用するバッチを送信できる。各アイテムの params は独立している。実際にはほとんどのバッチは均一な params を持つ（ワークロードが「N 個の入力に同じ prompt テンプレートを実行する」であるため）が、不均一性はサポートされており、時には有用だ（例：一つの送信内で低複雑度のアイテムを Haiku に、高複雑度のアイテムを Sonnet にルーティングする）。

ツール使用はバッチ内で動作するが、単一ターンのみ

バッチは各リクエストの params で tools と tool_choice をサポートし、strict: true のツール呼び出しで強制的にスキーマ準拠した出力を生成するためのメカニズムだ。バッチがサポートしないのは、マルチターンの agentic loop だ——バッチされたリクエストの途中で tool_use 結果を観察し、Claude が使用するために tool_result を注入し直す方法はない。各バッチアイテムは単一の Messages API 呼び出しだ。タスクが agentic loop を必要とする場合（ファイルを読む・判断する・別のファイルを読む）、バッチは適切なプリミティブではなく、run() または手動ループを使用した同期型 Messages API が必要だ。

ストリーミングはサポートされていない

バッチ API はストリーミングをサポートしない。各アイテムのレスポンスは全体として返される；サーバー送信イベントもインクリメンタルトークンも生成中の可観測性もない。ストリーミング出力が本当に必要なワークロード（チャット UI・ライブダッシュボード）については、同期型 Messages API が唯一の答えだ。ストリーミング関連の内部はCCA-F のスコープ外だが、バッチがストリーミングできないというアーキテクチャ的制約はスコープ内だ。

バッチ対リアルタイムの判断マトリックス — レイテンシ許容度・コスト感度・ボリューム

タスク 4.5 で最もテストされる概念は、バッチと同期型 Messages API の判断だ。CCA-F はこの判断を三つの軸に沿ってフレーム化する：レイテンシ許容度・コスト感度・ボリューム。

軸 1: レイテンシ許容度

個別の結果が数秒以内に返ってこなければならない場合（インタラクティブ UI・ライブカスタマーサポート・エージェント内の同期ツール呼び出し）、同期型 Messages API だけが正しい答えだ——バッチは個別アイテムのレイテンシを保証できない。個別の結果が数分から数時間かかっても問題ない場合（夜間バックフィル・週次レビュー・夜間抽出）、バッチが可能だ。ビジネスが 24 時間以内に結果がいつ届くかを本当に気にしない場合、バッチが好ましい。

軸 2: コスト感度

バッチは同じモデルの同期よりトークンごとに常に 50% 安い。絶対コストが主要な要因で、レイテンシが許可する場合、バッチが勝つ。コストが速いレスポンスのビジネス価値と比べて無視できる場合（例：重要なチケットを解決するカスタマーサポートエージェント）、50% 割引に関わらず同期が勝つ。

軸 3: ボリューム

バッチは大量の作業のために設計されている。単一バッチは一度の送信で 100,000 リクエストを運べ、セット全体で HTTP と認証のオーバーヘッドを分散する。同期型 Messages API は少量のリクエスト・レスポントラフィックのために設計されている。一日十件のリクエストであればどちらでも動作するが、インタラクティブユーザーのいない一日一万件のリクエストにはバッチが正しいプリミティブだ。

2×2 の思考モデル

試験当日に受験者が頭の中で描ける簡略化した 2×2 マトリックス：

高ボリューム・高レイテンシ許容——右下の象限にきれいに入る CCA-F シナリオはバッチを答えとして期待する。

コストのクイック見積もり

Sonnet でリクエストごとに平均 2,000 入力トークンと 500 出力トークンで週に 100 万件のリクエストのワークロードでは、同期対バッチのコスト差は相当なものだ。50% のバッチ割引はリクエストごと 2,500 トークンの全荷重に適用され、週ごとに請求される。シナリオは正確なドル金額の計算を受験者に求めないが、「相当」が「レイテンシが許すときはバッチが正しいアーキテクチャ的選択」を意味することの認識は求められる。そのスケールでデフォルトを同期にすることはアンチパターンだ。

バッチにおけるエラー処理 — アイテム単位のエラー対バッチレベルの失敗

バッチ API のエラーは明確に二つのカテゴリに分かれており、CCA-F は受験者がそれらを区別できるかをテストする。

アイテム単位のエラー

アイテム単位のエラーは、バッチ内の特定のリクエストが失敗したがバッチ全体は継続したことを意味する。結果ストリームはその custom_id に対して message ではなく error ブロックを含む。一般的なアイテム単位のエラーの原因：そのリクエストの不正な params・その特定の入力に対するコンテンツフィルターのトリガー・モデル固有の拒否。アイテム単位のエラーは request_counts の errored カウントに反映される。

バッチレベルの失敗

バッチレベルの失敗は、送信自体が処理できなかったことを意味する——最も一般的なのは構造的違反（100,000 リクエストの上限超過・256 MB ペイロード上限超過・送信内の重複した custom_id の値・トップレベルの不正な JSON・送信時の認証失敗）による。バッチレベルの失敗は送信時に拒否され、in_progress 状態に入らない。

期限切れリクエスト

24 時間 SLA が期限切れになったときにまだ processing だったリクエストは expired に移行する。バッチの processing_status は ended になり、期限切れのリクエストは結果ストリームにエラー形状で現れる。同じバッチ内の部分的な成功は影響を受けず取得可能だ。

キャンセル

バッチは実行中にキャンセルできる。キャンセルが届いたときにすでに完了していたリクエストは通常通り返される；まだ処理中だったリクエストは canceled とマークされ、エラー形状で返される。キャンセルは下流の依存関係が変わった場合（例：ターゲットスキーマが誤っており、修正された params で再送信が必要な場合）に有用だ。

失敗したバッチアイテムの再試行戦略 — 失敗した custom_id のみを再送信する

部分的な成功のセマンティクスにより、クリーンな再試行戦略が可能だ：バッチが終了した後、エラーになった custom_id の値を収集し、それらだけを含む新しいバッチを構築し、再送信する。CCA-F の再試行設計に関する設問は一貫して「失敗した custom_id のみを再送信する」という答えを「バッチ全体を再送信する」より優先して選ぶ。

再試行フロー

1. processing_status == "ended" になるまでバッチをポーリングする。
2. JSONL 結果ストリームをイテレートし、エラー結果ごとに（custom_id・error_type・original_params）の三つ組を収集する。
3. 何度再試行しても成功しない永続的なエラー（スキーマ違反・コンテンツフィルターのトリガー）を除外する。
4. 再試行可能なアイテムのみを含む新しいバッチを構築し、下流の結合が依然として整合するよう同じ custom_id の値を再利用する。
5. 再試行バッチを送信し、その識別子を別途追跡する。

同じ custom_id を再利用する理由

元の custom_id を再利用すれば、システムオブレコードへのアップサートはべき等だ：再試行結果はエラー行を成功したメッセージ行で上書きする。再試行のために新鮮な custom_id を生成すると、再試行 ID から元の ID へのマッピングテーブルを別途維持しなければならず、メリットなしに失敗モードが追加される。再利用が標準パターンだ。

一時的エラーと永続的エラーの区別

すべてのエラーが再試行する価値があるわけではない。一時的エラー（一時的なプラットフォームの問題・ピーク時の一時的なレートリミットレスポンス）は再試行から恩恵を受ける；永続的エラー（リクエストボディがスキーマに違反する・コンテンツが安全フィルターに拒否される・params に無効なモデル名が含まれる）は受けない。再試行前にエラーカテゴリを検査する——永続的なエラーの盲目的な再試行はクォータを消費し、ヒューマンエスカレーションのパスを遅延させる。

再試行は独自のバッチであり、追記ではない

「既存のバッチに追記する」操作はない。バッチが終了したら変更できない。再試行は常に新しいバッチ ID と独自の 29 日の保持ウィンドウを持つ新しいバッチだ。

スループット最適化 — 最大スループットのためのバッチ制限の活用

ワークロードが本当に大きい場合——一日数百万アイテム——スループットが支配的なアーキテクチャ的関心事となる。CCA-F は受験者が飽和パターンを知ることを期待する。

制限に近いところまでバッチを詰め込む

10 件のリクエストを含むバッチは 100,000 件のリクエストを含むバッチと同じスケジューリングオーバーヘッドを使用する。オーバーヘッドを分散するために各バッチを構造的制限（100,000 リクエストまたは 256 MB のペイロード、先に達した方）に向かって詰め込む。200,000 リクエストのワークロードを二つの 100,000 リクエストバッチに分割することは、二十の 10,000 リクエストバッチに分割するよりも効率的だ。

複数のバッチを並列で実行する

複数のバッチを同時に実行できる。500,000 アイテムを一晩で処理するパイプラインは、直列化するのではなく、五つの並列 100,000 リクエストバッチを送信すべきだ。各バッチには独自の完了 SLA があり、並列性は個々のバッチの SLA を損なわない。

シンプルなスケジューリングのためにモデルごとにグループ化する

不均一なバッチ（リクエストごとに混合モデル）がサポートされている一方で、モデルごとにバッチをグループ化するとコスト追跡・下流消費・再試行ロジックが簡略化される。バッチ内でモデルを混合する運用コストは通常、固定コストの節約よりも高い。

バッチ化前に前処理フィルタリングを行う

バッチトークンは安いが無料ではない。明らかに空または明らかに不適格なレコードを Claude に送らないよう、安価なロジック（正規表現・小さな分類器・ルールベースのトリアージ）で入力を前処理する。コスト曲線は作業を 50% 割引にするよりも作業を完全に除去するステップを報いる。

256 MB の上限に注意する

非常に大きな prompt（例：100,000 件一括でのドキュメント全文）は 100,000 リクエストより先に 256 MB に達することがある。リクエストごとの平均ペイロードが 3 KB なら、バイト上限が来る前に一つのバッチは 80,000 リクエストを保持できる。リクエストごとの平均ペイロードが 30 KB なら、上限は 8,000 リクエストで来る。先にバインドする制限に合わせてバッチサイズを設定する。

バッチ内の構造化出力 — ツール使用と JSON スキーマの適用

バッチされたリクエストは同期型 Messages API の完全な構造化出力ツールキットを継承する。CCA-F では、構造化データ抽出シナリオはほぼ常にバッチと厳密なツール使用を組み合わせる。

スキーマ保証のための厳密なツール使用

各バッチされたリクエストの params は strict: true とマークされた一つのツールを持つ tools 配列を含むことができる。そのツールへの tool_choice と組み合わせると、Claude はツールの JSON スキーマと正確に一致する出力を生成することを強制される。これは下流のコンシューマーがスキーマ準拠に依存するすべての抽出ワークロードに推奨されるアプローチだ。

バッチにおけるスキーマ適用の重要性

100,000 アイテムのバッチでは、わずか数パーセントでもスキーマドリフトが発生すると下流に数千の不正なレコードが生じる。厳密なツール使用は、スキーマ準拠を確率論的 prompt ベースの希望ではなく構造的保証にすることで、この種の失敗をなくす。バッチ抽出設問で厳密なツール使用よりも「より強い prompt 指示」を選ぶ受験者は、プログラム的適用が prompt 誘導を凌駕するというルール（コミュニティのペインポイント pp-01）でペナルティを受ける。

永続化前のバリデーション

厳密なツール使用は形状が正しいことを保証する；値が意味的に有効であることは保証しない。厳密なスキーマは regex が厳しくない限り日付文字列として「2026-13-45」を受け入れる。下流のバリデーション（日付解析・enum 所属・範囲チェック）は依然として消費パス——通常はシステムオブレコードへの永続化前——に属する。

やさしい解説: — バッチ処理の三つの類比

バッチ処理の概念は、受験者がすでに理解している物理的システムに固定すると具体的になる。三つの類比が判断・機構・再試行パターンを解説する。

類比 1: 郵便システム — 宅急便と普通郵便

同期型 Messages API の呼び出しは宅急便だ：一通の封筒を渡すと、配達員が目的地まで走り、15 分で署名入りの受け取りが返ってくる。速さに対して全額を支払っている。バッチ送信は普通郵便だ：一万通の封筒の袋を渡すと、各封筒は異なる受取人宛（各封筒には独自の custom_id が付いている）、郵便仕分けセンターが一封筒あたりの半額で夜通し処理する。特定の封筒がいつ届くか正確な分はわからないが、すべての封筒はサービスレベルウィンドウ（24 時間）内に届き、すべてが宛名ラベルでソートされて返ってくるのでメーリングリストと照合できる。一通の封筒が読めない宛名だった場合（アイテム単位のエラー）、残りは届き続ける；そのとき封筒は配達不可としてマークされて返される。袋全体が仕分けセンターに届かなかった場合（バッチレベルの失敗）、何も届かない。海外誰かへの誕生日カードに宅急便を使うのは理にかなっている；一万通のニュースレターに普通郵便を使うのは理にかなっている；誕生日カードに普通郵便を使う（一日遅れで届く）または一万通のニュースレターに宅急便を使う（一万通分の宅急便料金を払う）のはどちらもアーキテクチャ的に誤りだ。CCA-F のバッチ対リアルタイム設問はまさにこの選択だ。

類比 2: コインランドリー — セルフサービスとランドリーサービス

同期型 Messages API をセルフサービスのコインランドリーとして考えてほしい：一回分の洗濯物を入れ、待ち、サイクルを見守り、その場で畳み、90 分後に畳まれた服を持って出る。バッチ処理は洗濯代行サービスだ：一週間分の洗濯物をラベルの付いた袋に入れて（各衣類にはオーナータグ——custom_id が付いている）、立ち去り、翌日に取りに来ると一ポンドあたり半額でソートされた洗濯物が待っている——ランドリーが効率的な夜間ローテーションで他の二十件の客の袋と一緒にあなたの袋を処理するからだ。シャツ一枚が洗濯中に汚れが付いた場合（アイテム単位のエラー）、そのシャツ一枚が謝罪のメモ付きで返ってくる；残りの洗濯物は依然として畳まれて待っている。ランドリーのマシンが壊れてバッチ全体が約束のピックアップ時間を過ぎた場合、それはバッチレベルの問題であり返金または再実行が必要だ（キャンセルまたは期限切れのセマンティクス）。今夜のディナーに着るシャツには洗濯代行サービスを使わない；三家族分の月次洗濯物にセルフサービスを使わない。ワークロードとプリミティブの一致が CCA-F の判断マトリックスだ。

類比 3: レストランのディナーラッシュ対ケータリングオーダー — 実際のレイテンシ許容度

レストランのディナーサービスが同期型 Messages API だ——各テーブル（各ユーザー）が注文し 15 分以内に食事を期待する；単位あたりのコストが高くてもキッチンは注文あたりの低レイテンシに最適化されている。明日の企業イベントのケータリングオーダーがバッチ API だ——ケータリング業者は今日注文を受け、キッチンが静かな夜間に準備し、セットアップとクリーンアップを何百もの料理にわたって分散させるため一皿あたりの料金が低く、翌朝合意した時間にすべてを配達する。12 番テーブルの食客に「お客様のリゾットは 24 時間以内にプラットフォームの裁量でご用意します」とは言えない——それはビジネス上の惨事だ。イベントのクライアントに「200 皿はそれぞれディナーサービス価格でオンデマンドで調理され、それぞれ準備ができた順に届けられ、それぞれが準備できた時から始まります」とは言えない——それもビジネス上の惨事だ。各プリミティブは需要の形状に対して正しく、誤ったものを使用すると顧客体験（インタラクティブ向けにバッチを使う）または単位経済性（大量向けにリアルタイムを使う）のいずれかが破壊される。それがタスク 4.5 のアーキテクチャ全体の論旨だ。

どの類比がどの試験問題に適合するか

• 送信・収集フローに関する設問 → 郵便システムの類比。
• アイテム単位のエラー処理と再試行に関する設問 → コインランドリーの類比。
• バッチ対リアルタイムの選択に関する設問 → レストラン対ケータリングの類比。

一般的な試験トラップ

CCA-F バッチ設問は五つのトラップパターンを一貫して利用する。すべてはコミュニティの合格報告で「惜しいが誤り」の選択肢として記録されている。

トラップ 1: 「24 時間 SLA はちょうど 24 時間を意味する」

24 時間 SLA は最大値であり、目標時間ではない。ほとんどのバッチは数分から数時間で完了する。24 時間の数字を予想される完了時間として扱う答え、または 24 時間丸ごと待つことを前提に設計された下流パイプラインは誤りだ。正しいフレーミングは「通常 24 時間よりはるかに速いが、それより遅くなることは保証されない」だ。

トラップ 2: 「custom_id はシステム生成される」

custom_id は常に呼び出し側が定義する。結果をアプリケーションレコードに相関付けるために API が提供する自動識別子はない。システム生成のバッチアイテム ID をレスポンスから取り出すことを説明する答え——または大きなバッチで custom_id を完全にスキップして配列インデックスを使用する答え——はアーキテクチャ的に壊れている。常にアプリケーションの主キーから custom_id を導出する。

トラップ 3: 「バッチ API はストリーミングをサポートする」

バッチはストリーミングをサポートしない。各リクエストのレスポンスは全体として返される。インクリメンタルトークンもサーバー送信イベントもない。ストリーミングを必要とするワークロード（チャット UI・ライブダッシュボード）には同期型 Messages API だけが正しい答えだ。50% 割引のためにストリーミングを必要とするワークロードにバッチを選んだ受験者は直接ペナルティを受ける。

トラップ 4: 「バッチ API はマルチターンの agentic loops をサポートする」

各バッチされたリクエストは単一の Messages API 呼び出しだ。バッチの途中で tool_use を観察し、ツールを実行し、Claude が使用するために tool_result を注入し直すメカニズムはない。agentic loop を必要とするワークロード（ファイルを読む・判断する・別のファイルを読む）はバッチに適していない。バッチ内でのツール使用は単一ターンのみであり、通常は tool_choice を使用した厳密スキーマ抽出として行われる。

トラップ 5: 「コストを節約するために常にバッチを使用する」

50% 割引は魅力的だが、レイテンシ要件を無効にしない。インタラクティブエージェント・ライブユーザー向けアプリケーション・リアルタイム開発者フィードバックループを説明するシナリオは、コストに関わらず同期型 Messages API を必要とする。安価だからバッチをデフォルトにすることは「安全のためにリアルタイムをデフォルトにする」というアンチパターンの鏡像であり、同様にペナルティを受ける。

練習アンカー

バッチ処理の概念は CCA-F の六つのシナリオのうちの二つで最も多く登場する。以下をタスク 4.5 に関するシナリオクラスター設問のアーキテクチャの背骨として扱うこと。

Structured-Data-Extraction シナリオ

これはバッチ設計を最も直接的に扱うシナリオだ。チームは大きなドキュメントコーパスから構造化フィールドを抽出する必要がある——履歴書・請求書・契約書・サポートチケット・研究論文・規制申請書。以下をテストする設問を期待すること：与えられたボリューム/レイテンシの組み合わせに対してバッチと同期のどちらが正しいプリミティブか；スキーマ準拠を強制するためにバッチと厳密なツール使用をどう組み合わせるか；結果がソースコーパスにクリーンに結合できるよう custom_id をどう設計するか；バッチを失敗させずにアイテム単位のエラーをどう処理するか；失敗した custom_id の値のみをどう再試行するか；100,000 リクエストと 256 MB の上限に対してバッチをどうサイジングするか。期待される答えの形状はほぼ常に「厳密なツール使用抽出でバッチを送信し、完了をポーリングし、custom_id をキーとしてデータベースに JSONL 結果ストリームを取り込み、フォローアップバッチで失敗したアイテムを再試行する」だ。

Claude-Code-For-Continuous-Integration シナリオ

このシナリオはバッチを CI/CD パイプラインのコンテキストで、より微妙に扱う。夜間スケジュールで大量のファイル・PR・issue にわたって Claude Code 分析を実行する場合だ。バッチが CI パイプライン内で正しいプリミティブである状況（スケジュールされた夜間コーパス分析）と同期型 Messages API が必要な状況（待っている開発者への PR ごとのコミットフィードバック）をテストする設問を期待すること。設問は CI での raw Messages ワークロードの Message Batches API と -p（非インタラクティブ）Claude Code 呼び出しの統合または違いを探ることもある。アーキテクチャ的判断ルール：CI タスクがイベントごとで人間が待っている場合は同期；CI タスクがスケジュールされたバルク処理の場合はバッチ。

FAQ — Message Batches API 上位 5 問

50% バッチ割引とは何か、いつ適用されるか

Message Batches API は同じモデルの同期型 Messages API レートの 50% で入力・出力・キャッシュされたトークンを請求する。割引はバッチエンドポイント経由で送信されたすべてのリクエストに自動的に適用される（Claude ファミリー全体で：Haiku・Sonnet・Opus）。割引は構造的制限（100,000 リクエスト・256 MB）または 24 時間 SLA を免除しない。CCA-F では 50% 割引はバッチ対リアルタイム設問の経済的転換点だ：レイテンシが許しボリュームが高い場合の正しいアーキテクチャ的選択だが、ユーザーが個別の結果を待っているインタラクティブワークロードにバッチを選ぶ理由にはならない。

24 時間 SLA は実際に何を意味するか

24 時間 SLA は Anthropic が通常条件下で送信されたバッチを完了することをコミットする最大時間だ。実際には、ほとんどのバッチは数分から数時間で完了する；24 時間の数字は上限であり目標ではない。バッチが 24 時間以内に完了しない場合、expired 終端状態に移行する——部分的な結果は依然として custom_id で取得可能だが、未処理のリクエストは失われ新しいバッチとして再送信しなければならない。個別の結果に 24 時間より速い保証が必要なアプリケーションは同期型 Messages API を使用すべき；「一晩」のレイテンシで問題ないアプリケーションはバッチを使用する。

バッチ結果をアプリケーションレコードにどう相関付けるか

custom_id フィールドを使用する。requests 配列の各リクエストは一意の呼び出し側定義の custom_id 文字列を持たなければならず、出力 JSONL ストリームの各結果にその同じ文字列がタグ付けされる。安定したアプリケーションの主キーから custom_id を導出し（例：ticket-{{id}} または resume-{{uuid}}）、システムオブレコードへの下流アップサートがべき等になるようにする。Anthropic は custom_id を生成しない——相関コントラクトは完全に呼び出し側にある。相関に配列インデックスまたはレスポンスの順序を使用しないこと；バッチ API は順序保存を保証しない。

バッチ内の個別リクエストが失敗した場合はどうなるか

バッチ API は部分的な成功のセマンティクスを使用する。アイテム単位のエラーはそのリクエストにのみ影響する——バッチの残りは処理を続け、成功したアイテムは通常通り返される。request_counts ブロックは succeeded・errored・canceled・expired のカウントを追跡し、結果ストリームには失敗した各 custom_id に（message ブロックではなく）error ブロックが含まれる。正しい再試行戦略は、エラーについて結果ストリームをフィルタリングし、永続的なエラー（スキーマ違反・コンテンツフィルターの拒否）を再試行から除外し、べき等なアップサートのために元の custom_id 文字列を再利用して再試行可能な custom_id の値のみを含む新しいバッチを送信することだ。

バッチと同期型 Messages API をいつ選ぶか

ワークロードが大量・非インタラクティブで、ビジネスの締め切りが秒ではなく時間または翌日で測られる場合——ドキュメントコーパスにわたる構造化抽出・夜間データセットラベリング・スケジュールされた CI/CD バルク分析・マルチパスレビューパイプライン——はバッチを選ぶ。個別の結果が低レイテンシ配信（秒）が必要な場合・人間がアクティブに待っている場合・マルチターンの agentic loop が必要なワークロードの場合・ストリーミング出力が必要な場合（チャット UI・ライブダッシュボード）は同期型 Messages API を選ぶ。CCA-F の判断ルール：最初にレイテンシを読む、次にボリューム、次にコストを考慮する。安価だからバッチをデフォルトにするか安全だから同期をデフォルトにする——ワークロードの形状に一致させずに——ことが典型的なアンチパターンだ。

参考資料

• バッチ処理 — Message Batches API: https://docs.anthropic.com/en/docs/build-with-claude/batch-processing
• 厳密なツール使用 — スキーマ保証出力: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/strict-tool-use
• 出力の一貫性向上 — 構造化出力: https://docs.anthropic.com/en/docs/test-and-evaluate/strengthen-guardrails/increase-consistency
• ツール呼び出しの処理 — tool_result フォーマットとエラーレスポンス: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/handle-tool-calls
• Claude Code を CI/CD パイプラインに統合する: https://docs.anthropic.com/en/docs/claude-code/ci-cd

関連 ExamLab 章節: ツール使用と JSON スキーマによる構造化出力, マルチインスタンスとマルチパスレビューアーキテクチャ, Claude Code CI/CD 統合, 抽出のためのバリデーション・再試行・フィードバックループ.