Claudeのバッチ処理と対話処理：待ち時間と復旧方法で選ぶ

結果を待てる業務か確認する

夜間の文書分類は非同期に向く可能性がありますが、問い合わせ中の確認質問は即時性が重要です。同じ分類処理でも、利用場面で選択が変わります。安いかどうかだけでなく、完了期限と結果を待つ人の行動を基準にします。

バッチの仕様や料金は利用時の公式資料で確認します。非同期処理では入力と結果の保持条件も関係するため、同期処理と同じデータ管理だと決めつけないようにします。

元の入力と結果を識別子で結ぶ

結果が入力順に返ると仮定せず、個別の要求IDを使って照合します。処理に使った入力版も記録し、途中で元文書が変わった場合にどの版への結果か分かるようにします。重複したIDや欠けた結果は、そのまま保存せず検出します。

一件の失敗で全件を再送すると、成功済みの処理が重複する可能性があります。成功、再試行可能、要確認という状態を個別に持ち、再実行の範囲を絞ります。

完了と取り込みを別の状態にする

提供者側の処理が終わっても、アプリが結果を保存し終えたとは限りません。結果取得、検証、保存を別々に追跡します。取り込み途中で停止したときに再開できるようにし、処理済みの一件を識別できる設計にします。

処理中に元データが変わる場合を考える

非同期の結果が返るまでに、元文書や対象の状態が更新されることがあります。結果に入力版を付け、取り込む時点で現在の版と合うかを確認します。古い版への分類結果を、新しい本文へ無条件に付けると、モデルの出力自体が正しくても業務上は誤った状態になります。完了した結果を全て適用するのではなく、適用可能かを検証する工程を残します。

再取り込みの設計では、取得した結果ファイルの途中で停止した場合も考えます。保存済みの要求IDを識別し、同じ結果をもう一度読んでも重複した通知や更新が起きないようにします。生成側の成功と、取込側の成功を別々に記録すれば、どちらをやり直すべきかを判断できます。処理件数だけでなく、未解決の対象が残っていないかを確認します。

具体例で考える

説明用の三件の文書A、B、Cで、AとCが成功し、Bだけ入力不備になりました。

A：検証後に保存済み。
B：入力修正待ち。
C：検証後に保存済み。
再実行：Bだけを新しい入力版で処理し、元の業務IDへ関連付ける。

全体が一度終了したことと、全件の業務が完了したことは違います。未解決の一件を一覧へ残すことで、失敗が正常な空結果として消えることを防ぎます。

確認課題と合格の目安

五件の処理に部分失敗と取り込み中断を入れ、再開時に何を再実行するか決めてください。

• 入力順に依存せず照合できる。
• 成功済みの処理を不用意に繰り返さない。
• 結果の生成と保存完了を区別している。