Batch Processing

バッチ処理とは、構造が似ていて同じロジックで処理すべき一連のタスクを一つのリクエストにまとめ、Claudeにバッチ全体を順番に処理させることを指す。一つずつ手作業で貼り付けて回答を待ち、また次を貼り付けるのではない。これは単に「何度も尋ねる」こととは違う。単に何度も尋ねる場合、毎回指示を確認し直し、回答を待ち直す必要があるが、バッチ処理は「今回やるべきこと」を一度だけ定義し、処理すべきデータをまとめて渡す。指示は一度書くだけでバッチ全体に適用される。これは prompt chaining（プロンプトチェイニング）とも異なる。プロンプトチェイニングは一つのタスクを複数の連続した、互いに依存し合う段階に分割するが、バッチ処理は互いに独立し依存関係のない同種のタスクを複数まとめて送るものであり、処理順序が結果に影響しない。

この仕組みが必要とされるのは、職場の多くのタスクが本質的に「同じロジックを異なるデータへ繰り返し適用する」ものだからだ。20件の会議記録すべてから要点を抽出する、50通の顧客苦情メールすべてに優先度を分類する、四半期分の領収書すべての金額を照合する。この種のタスクを一件ずつ手作業で処理すると、多くの時間が同じ指示の再入力と回答待ちに費やされ、本当に必要な思考や判断には使われない。人がこの動作を20回繰り返す過程で、回数が増えるほど注意力も低下しやすく、後半になるほど細部を見落としたり入力ミスをしたりしやすくなる。これはバッチ処理が技術的に可能かどうかとは関係なく、繰り返し作業に伴う人の自然な疲労だ。バッチ処理が存在する理由は、「同じロジックを繰り返し適用する」という機械的な部分をシステムに一括で任せ、人の注意力を本当に判断が必要な少数の事柄に残すことにある。

実務では二段階で進める。第一に、タスクの性質がバッチ処理に向いているかを確認する。この一連のタスクが互いに本当に独立し依存関係がないかどうかだ（20件の会議記録それぞれを要約する場合、20個の要約同士が互いに参照し合う必要がなければバッチ処理に向く。しかし三番目の要約が一番目の内容を参照しなければどう書くべきか判断できないなら、それは独立したタスクではなく、バッチ処理ではなく prompt chaining を使うべきだ）。第二に、指示をバッチ全体に適用できる汎用的な形で書く。特定の一件だけに合わせて作られた形ではない。指示の中に特定の一件だけに当てはまる細部を入れず、同じ指示がバッチ内のどの項目に適用しても妥当であることを確認する。バッチ実行後は、いくつかの結果（通常10〜20%）を人が抽出確認し、バッチ全体の品質が一貫しているかを確かめる。一件ずつすべて照合するのではない。抽出確認の目的は「この指示がバッチ全体にとって十分に良いか」を確認することであり、あらゆる個別の誤りを見つけ出すことではない。

あなたにとって、バッチ処理が本当に節約するのは「入力回数が減る」という表面的なことだけではなく、項目間で注意力を切り替え、指示を再確認し、回答を待つたびに積み重なるコストだ。このコストはタスク数が少ないうちは目立たないが、5〜10件を超えると積み重なって相当な量になる。注意すべきは、バッチ処理が向いているのは互いに独立し一貫したルールに従うタスクである点だ。バッチの中に特別な処理を必要とする少数の例外が混じっている場合（20件の文書のうち3件だけ他と形式が異なるなど）、その例外を同じバッチ指示に無理に詰め込むと、例外に合わせるために指示全体が複雑で曖昧になりやすく、本来単純だったはずの残り17件の足を引っ張ってしまう。より良いやり方は、例外を先に選び出して個別に処理し、残りの一貫した部分だけをバッチで実行することだ。少数の例外のためにバッチ指示全体の簡潔さを犠牲にすべきではない。