検証ループが回るようになったら、次は2体目だ。
第7回で、検証ループを自分の手で作った。テスト・ビルド・実行結果を確かめる仕組みがあれば、Claudeが「できたつもり」で報告してくることは減る。ステップ1の卒業条件は、全部読むのをやめて確かめ方を渡すことだった。
ここからが第3部、ステップ2の始まりになる。ステップ2の定義は、5〜10体を指揮し、最終的な差分だけをレビューすること。ただしいきなり10体には行けない。今回扱うのは、その最初の一歩、2体目を立てることだけだ。
2体という数字を軽く見てはいけない。1体から2体に増える瞬間に、この講座で一番よくある事故が起きる。
それは、2体が同じファイルを同時に触るという事故だ。片方が保存した内容を、もう片方の保存が上書きして消す。今回はまず、この事故が起きない作法を固める。
なぜ2体にすると成果が上がるのか：相関のないコンテキスト
同じ指示を2つのウィンドウに貼るだけでは、ほとんど意味がない。
素朴な発想では、これで「2倍速」を狙いたくなる。だが同じ文脈・同じ材料から出発した2体は、だいたい同じ結論にたどり着く。速くなった気がするだけで、視点は増えていない。
“the value is actually the uncorrelated context windows...you tend to get better results this way”
筆者訳価値があるのは実は、相関のない(uncorrelated)コンテキストウィンドウにある。そうすることで、より良い結果が得られやすい。
Borisが言う「相関のないコンテキストウィンドウ」とは、それぞれが違う材料・違う担当範囲から出発するという意味だ。片方はテストコードだけを読み、もう片方は仕様書だけを読む。見ているものが違うからこそ、出てきた答えを独立した目で照らし合わせられる。
大きな調査タスクを複数のサブエージェントに割って集約する、いわゆるmap-reduce的な使い方も、同じ発想の延長線上にある。
この原則を、コード品質という場面に絞って具体化しているのが公式ドキュメントのWriter/Reviewerパターンだ。セッションA（Writer）が実装し、いったん完全に手を離す。セッションB（Reviewer）はそのコードを書いていない、真っさらな文脈で差分を読み、エッジケースや競合状態を指摘する。Aはその指摘を受けて直す。
“A fresh context improves code review since Claude won't be biased toward code it just wrote.”
筆者訳新鮮なコンテキストは、コードレビューの質を上げる。Claudeが、自分がたった今書いたコードに肩入れしないからだ。
AがBの指摘を素直に受け取れるのは、Bに「自分が書いたコードを守りたい」という肩入れがないからだ。何を渡し、何を疑わせるかという設計そのものは、独立した疑う役を組み立てる第15回で改めて扱う。
タブ分割から始める：一番簡単な2体目
最初の2体目に、難しい仕組みは要らない。ターミナルのタブをもう1枚開いて、別のClaude Codeセッションを起動するだけでいい。
“I run 5 Claudes in parallel in my terminal”
筆者訳自分のターミナルで5つのClaudeを並列に動かしている。
Borisはターミナルで5体、claude.ai/codeまで含めると5〜10体を同時に動かしていると語っている。今回の講座で目指すのは、まずその手前、2体だ。
実務でよく使うのが -p フラグ、いわゆるprint mode。対話をせず、1回の指示と結果だけをやり取りする、スクリプトや自動化に向いた起動方法だ。
$claude -p "テストを実行して失敗しているケースを一覧にして"
3 failing: test/auth.spec.ts, test/upload.spec.ts, test/session.spec.ts
ここまでは簡単だ。だが、タブを分けただけでは作業ディレクトリは同じままという点に注意がいる。ここに次の罠がある。
worktreeで物理的に分離する
タブは会話を分けるが、ファイルは分けない。同じリポジトリの同じ作業ツリーを2つのClaudeが同時に編集すれば、片方の未保存の変更を、もう片方の保存が丸ごと踏み潰す。これを防ぐのがgit worktreeだ。
worktreeは、1つのリポジトリから別のディレクトリに別ブランチをチェックアウトする仕組み。同じ.git履歴を共有しながら、作業ファイルの実体は完全に分かれる。
注意
同じ作業ツリーで2体を動かした場合
保存の順番次第で、後から保存した側が前の変更をそのまま踏み潰す。差分を見て初めて気づく頃には、片方の作業がもう跡形もない。worktreeを分けるコストは、この事故を1回避けるだけで元が取れる。
同じファイルを触らせない作法：縄張りの分け方
worktreeを分けても、同じ機能を2体に頼めば意味がない。実際の切り分けは、ディレクトリ単位、あるいは関心事の単位で行う。
職場で2人の新人に、同じ案件の記録を同時に書かせる会社はない。受け持つ案件を分けるのと同じ発想で、2体にも受け持つファイル・受け持つ機能をあらかじめ割り振る。
- 片方はテストコード、もう片方は実装コード
- 片方はフロントエンド、もう片方はAPI
- 片方は今週のリリース、もう片方は来週の調査
- 同じファイルを「念のため」両方に見せる
- なんとなくで分けて、後から衝突に気づく
- 依頼のたびに担当範囲を曖昧にする
分割の指示は、Claudeへの依頼文にもそのまま書く。「あなたはsrc/api配下だけを編集してください」と最初に明記するだけで、事故はかなり減る。
ローカルのスーパーバイザーデーモンがバックグラウンドセッションごとにworktreeを自動で隔離する仕組み。2体目以降を手動で分けるのが面倒になったら、次に読む場所。
よくある誤解と罠
- 2体目を「ダブルチェック」に使おうとする誤解。並列は速度のための仕組みで、疑う役を分けるのは第15回の話。今の段階で混ぜると、どちらも中途半端になる
- タブを分けただけでworktreeを分けず、衝突に気づかないままマージまで進んでしまう
- 体数が増えた分だけ監視の負担も増えると思い込む。第7回で検証ループを作っていれば負担は増えない。増えるのは体数ではなく、確かめ方を渡していないタスクの数
今日のまとめ
- 2体目の価値は速度ではなく、相関のない独立したコンテキストにある
- worktreeで作業ツリーを分け、担当ファイルを明確に割り振ることが2体運用の前提
- 検証ループが整っていれば、体数が増えても監視の負担は増えない
明日のアクション
自分のリポジトリでworktreeを1つ切り、2つ目のClaude Codeセッションを実際に起動してみてください。
git worktree add ../<repo>-b <branch> で作業ディレクトリを分け、「あなたは〇〇配下だけを編集してください」と担当範囲を1行で決めてから依頼を出すこと。
同じファイルを触らせていないか、作業が終わったdiffを見て確認してください。
次は、その2体が自分でテストと型チェックを確認してから報告する状態を作る。第9回、自己検証を組み込む。