目次
問い合わせ履歴の分類や記事データの要約を夜間にまとめて処理するなら、ClaudeのMessage Batches が候補になります。画面で回答を待つ利用者がいない作業を非同期化し、結果を回収してから業務データへ反映する方式です。対話用APIを大量に並列呼び出しする実装から、受付・処理・回収を分けた運用へ変える必要があります。
本記事は2026年11月7日に確認した公式資料に基づく実践解説で、新機能の発表速報ではありません。Anthropic Batch processing公式ガイドは標準API価格に対する50％の料金を案内しています。ただし、仕事全体の費用や締切達成率まで半分になる保証ではありません。再送や結果の取り込みに必要な作業も含めて採否を判断します。
スポンサーリンク
即時応答の必要がない独立した処理を選ぶ
バッチへ移しやすいのは、入力一件ごとに処理が完結し、後で結果をまとめられる仕事です。過去の問い合わせへ部署ラベルを付ける例なら、利用者の操作を止めずに進められます。逆に、利用者との会話を続けながら次の質問を決める画面では、その場の応答を待つ設計が必要です。
公式は大半のバッチが1時間未満で終了すると説明していますが、処理完了には最大24時間かかり得ます。1時間という説明を納期の保証には使わず、期限と未処理時の扱いを先に決めます。朝の始業までに必須の集計なら、締切に間に合わないケースも受け入れられるかが採用条件になります。
本サイトの提案は、最初に対象件数よりも業務のを確認することです。前の回答を次の入力へ使う連続処理は、同じバッチへ入れただけでは順序を作れません。前段の結果を確定してから次のバッチを作るか、一件の入力に必要な情報をまとめる構成を選びます。
入力の台帳とAPIへ渡す要求を対応付ける
Anthropic Message Batch作成APIの要求は、requests配列の各要素へcustom_idとparamsを持たせる形です。paramsには通常のMessages APIのモデル、出力上限、メッセージなどを指定します。custom_idは同じバッチ内で一意にし、結果と元の入力を結ぶ識別子として使います。
結果は入力順で戻るとは限りません。配列の何番目かを業務データの何行目かへ対応させると、並びが変わったときに別の問い合わせへ回答を保存する危険があります。元データのID、入力の版、指示文の版、試行番号を台帳へ保存し、custom_idからそれを引けるようにすることを勧めます。
識別子へ本文や氏名を埋め込む必要はありません。英数字とハイフン、アンダースコアを使う短いIDを作り、対応表を別に管理します。形式の制限は1〜64文字です。例えばcase_0001_try1は説明用の識別子であり、どのサービスにも共通の命名規則ではありません。
スポンサーリンク
最初は小さな要求で受付と回収を通す
本サイトでは、最初に少数の代表入力で一連の処理を通すことを勧めます。APIへ受け付けられたこと、バッチIDを保存できたこと、最終結果を取得できたこと、元データへ正しく対応付けられたことを確認します。全件投入から始めると、入力形式の不備と回収処理の不具合を同時に抱えやすくなります。
公式の上限は1バッチ当たり10万要求または256MBの先に達する方です。件数だけで分割せず、シリアライズした要求全体のサイズも確認します。短文の分類と長い文書の要約では、同じ件数でも要求量が違います。上限ぎりぎりを狙うより、再送と調査がしやすい単位で区切る方が運用しやすくなります。
各要求の出力上限も用途に合わせて設定します。部署ラベルが必要な処理へ長文の説明を毎回求めると、保存量と検証の手間が増えます。一方、上限を小さくしすぎて必要な結果が途中で切れたら、成功応答であっても業務には使えません。出力の完全性はAPIの成功と別に検査します。
バッチIDを保存してから状態監視へ移る
バッチ作成の応答を受けたら、返されたIDと投入台帳を結び付けます。作成直後は処理中であり、送信関数が正常終了しただけで業務完了にはなりません。状態確認の担当を別ワーカーへ渡せるようにすれば、投入したプロセスが終了しても追跡を続けられます。
作成要求の応答が失われた場合は、成功か失敗かが不明です。直ちに同じ全件を送り直すのではなく、既存のバッチと台帳を照合する処理を用意することを勧めます。custom_idの一意性はバッチ内の条件であって、別バッチの重複作成を自動的に防ぐ仕組みだとは扱わないでください。
監視では処理中と終了を区別し、終了後に各要求の結果を確認します。ポーリングのたびに新規バッチを作らず、保存済みのIDを使います。監視の通信失敗は推論の失敗と分けて記録し、通信が戻れば同じ対象の状態確認から再開できるようにします。
スポンサーリンク
終了したバッチにも部分失敗がある
Anthropic Message Batch結果取得APIは各行にcustom_idとresultを持つ結果を返します。成功時にはMessageが入り、失敗や取り消し、期限切れの場合はその状態が返ります。バッチ全体の処理が終了したという状態を、全入力の成功へ置き換えてはいけません。
回収処理は結果の種類で分岐させます。succeededは内容を検証する候補、erroredはエラーの原因を調べる対象です。canceledとexpiredも元データの未処理状態へ対応付けます。APIに渡さなかった入力や結果に見つからないIDまで、処理済みとして数えないことが重要です。
入力の形式が誤っているエラーは、そのまま再送しても直りません。モデルやパラメーターを修正してから新しい試行として扱います。一時的な障害で再送する場合も、成功分を除き、未完了分だけから次の要求を作ります。何回試したかと最初の失敗理由を残すと、無制限の再送を避けやすくなります。
結果は一行ずつ検査して保存する
結果はJSONL形式なので、一行ずつ読み、custom_idで台帳を引き、結果の種類と内容を検査して保存する流れにします。大量の結果を一度にメモリーへ載せる必要はありません。読み取りが途中で止まった場合も、どこまで取り込んだかを保存して再開できる設計を勧めます。
保存側では、処理IDと試行をキーに同じ結果を二重登録しないようにします。例えば結果ファイルをもう一度読んだだけで、同じ問い合わせへの通知を二度発行しない構成です。推論結果の保管と利用者への通知は分け、保存が確定したものだけを次の工程へ渡します。
複数の試行が返る場合、後から届いたという理由だけで新しい正解にしないでください。入力の版が古い結果を現在のデータへ上書きしないよう、採用する試行を台帳で決めます。元の問い合わせが修正された場合は、処理した時点の入力と結果の組を残して比較可能にします。
APIの成功と分類品質を別に集計する
succeededであっても、許可していない部署名、空の回答、必要な項目の欠落があれば業務上は不合格です。まず通常のコードで形式や許可値を確認し、その後に内容を評価します。成功応答率だけでは、使える結果がどれだけ得られたかは分かりません。
評価は、代表入力と保留すべき入力を混ぜ、期待する判断を先に定めます。採点の基準自体については既存の評価記事で扱っていますが、本稿の焦点は、その入力を大量に実行しても対応付けと回収を崩さないことです。実行基盤の不具合をモデル品質の悪化として数えないようにします。
報告では投入件数、API成功件数、内容検証の合格件数、再送件数、締切までに採用できた件数を並べます。入力全体を分母にした合格率と、成功応答だけを分母にした正解率を分ければ、途中で消えたケースが数字から見えなくなることを防げます。
割引よりも採用できた一件当たりの費用を見る
半額という説明だけで採用を決めず、同じ入力と同じ設定で通常処理との差を測ることを勧めます。再送、採点、保存、運用の手間を含め、採用できた結果一件当たりの費用を比較します。これは測定方法の提案で、本サイトが実測した削減率ではありません。
出力上限や指示文を同時に変えると、処理方式の差とモデルの使い方の差が混ざります。最初は変更を一つに絞り、料金、完了までの時間、未完了率を記録してください。夜間処理へ移すことで対話用の待ち時間が減る効果も、料金とは別の価値として観察できます。
スポンサーリンク
結果の回収期限を運用の期限へ落とし込む
公式資料では、結果を取得できるのはバッチ作成から29日間です。ダウンロード可能なうちに自社の必要な結果を回収し、取得の成否を確認します。後でバッチを参照できることと、結果を再ダウンロードできることは同じではありません。
本サイトの提案として、完了を検知したら自動で回収し、業務反映が済むまで未処理の台帳を残します。期限間際になって担当者が手動で探す運用は避け、回収失敗や未確定の入力に通知を出します。再取得したファイルも同じ取り込み処理で扱い、重複を増やさないようにします。
導入は一つの夜間ジョブから始める
問い合わせ分類なら、まず少量の過去データで投入から保存まで確認し、次に一晩の処理量へ広げます。投入対象が意図した日付のデータだけであることも確認してください。期限切れ、入力エラー、回収途中の停止を意図的に想定し、誰が修正してどこから再開するかを決めます。正常系で一度動いたことを、運用の完成とは扱いません。
Message Batches APIは、待てる仕事の推論をまとめるための仕組みです。採用の判断は、料金だけでなく、締切までに必要な品質の結果を回収でき、失敗分だけをやり直せるかで行います。バッチIDと入力台帳を起点にすれば、モデル変更後も追える処理基盤へ育てられます。
スポンサーリンク
関連記事
AIの改善を勘で判断しないために 評価データと回帰テストの始め方では評価基準の設計を解説しています。
