Claudeエージェントを並列化する前に：独立性と統合の責任を設計する

依存関係を先に図にする

二つの資料を別々に調べることは同時にできますが、資料Aの結論で資料Bの調査範囲が決まるなら順序が必要です。後から統合する人が、どの結果がどの前提で作られたかを確認できる入力仕様を持たせます。

同じコードや業務状態を複数の処理が更新する場合は、競合の責任を決めます。別々の作業場所を使うだけで、最終的な変更の衝突がなくなるわけではありません。

共有する情報を選ぶ

全履歴を全員へ渡すと費用が増え、不要な前提まで共有します。目的、制約、必要な資料、返す形式を絞る方が、結果の根拠を追いやすくなります。機密情報も、分担に必要な範囲だけを渡します。

別の処理で作った結論は独立した証拠とは限りません。同じ誤った入力を使えば同じ方向へ間違う可能性があるため、人数や結果の一致だけで正しさを判断しないようにします。

統合と再検証の時間を見積もる

待ち時間の短縮だけでなく、指示を分ける時間、矛盾を確認する時間、最終成果物の検証を含めて比較します。各部分が正しくても統合後の用途を満たさないことがあります。最終的な完了条件の担当を必ず残します。

同じ前提の誤りを共有していないか確かめる

複数の処理が同じ結論を返しても、独立して正しさを確認したとは限りません。同じ古い資料や同じ不適切な前提を与えれば、一致した誤りになる可能性があります。統合時は回答の一致だけでなく、参照元、適用条件、確認方法を比較します。独立した評価が必要な場合は、評価者へ実装側の結論を誘導する情報を与えないといった工夫も別に検討します。

並列化の利益は、最も遅い部分の時間に統合の負担を足して考えます。分担を細かくしすぎると、同じ説明の重複や、境界部分の再調査が増えます。複数の成果物を集めた後も、利用者の完了条件を満たすかを一人の責任で確認する必要があります。各部分の完了を足しただけで、全体の成功と報告しないようにします。

具体例で考える

架空の技術比較で、一方は料金、もう一方はデータ管理を調べます。

共通条件：同じ製品、地域、契約、確認日。
分担：料金の構成／データの経路。
統合：条件が一致する情報だけを同じ比較表へ載せる。

料金はAPI、データ条件は別の画面製品という組合せでは比較になりません。独立して調べられることと、そのまま一つの結論へ統合できることは違います。

確認課題と合格の目安

一つの仕事を分担する図に、依存関係、共有する条件、統合担当を追記してください。

• 前の結果を必要とする作業を並列にしていない。
• 同じ状態への変更競合を扱っている。
• 統合後の検証と費用を見積もっている。