はじめに
マルチエージェントの技術的オーケストレーションの話でも、Plan Modeの使い方の話でもない。日常のコーディング作業でClaude Codeとどう協調するか、そしてEMとしてその協調を「チーム文化」に設計するかという話だ。
ペアプログラミングは効果が高いと分かっていながら、シニアエンジニアのキャパシティを圧迫するという理由で諦めているチームは多い。Claude Codeが変えたのはここだ。コードベース全体のコンテキストを持つAIペアを、全員のエンジニアが持てるようになった。
ドライバー／ナビゲーター——Claude Codeとの役割分担パターン
Kotlin/Androidエンジニアのブロガー、Eugen Martynovが実践しているのはシンプルな役割分担だ。
ドライバー（Claude）: コード実装、調査、広範な推論
ナビゲーター（人間）: 指示・方向決定、レビュー・修正指示、最終検証
「私は必要なものを説明し、Claudeがコードを生成する。レビューして方向修正し、調整される。この継続的なフィードバックループが機能している」と彼は書いている。
この役割分担が特に力を発揮するのは、「何をすべきか」は分かるが実装の全体像に自信がない領域や、新しいAPIや未知のライブラリを使う探索的な作業だ。
Sze Wongがブログで紹介しているPDF描画バグの修正事例が具体的で分かりやすい。「かっこの位置がずれる」という問題に対して3回のフィードバックループを経た。第1回でClaudeが過度に単純化した実装を提案し、第2回でカスケードパターンを説明して改善されたがエッジケースで失敗し、第3回で完全に機能するソリューションに到達した。彼はこう書いている——「私は一行もコードを書かなかったのに、深く技術的だった」。思考と方向性決定が人間の価値だという気づきだ。
コントロールを取り戻す——失敗パターンから学ぶ
Martynovの実践には失敗の記録も含まれている。これがペアプログラミングパターンを理解する上で最も重要な部分だ。
暗黙知の見落としという失敗もあった。Kotlinのsuspend関数のバイトコード変換において、ソース解析ベースのアプローチが脆弱であることに1週間気づかなかった。Claudeはコードを読んで判断したが、コンパイル後の実行時挙動という暗黙知を持っていなかった。次のプロンプトがこのリスクを減らす。
今の実装で「なぜこのアプローチを選んだか」を説明して。
他のアプローチで起きうる問題、特にランタイム挙動に関連する リスクがあれば具体的に教えて。
並行作業でのコントロール喪失も別の問題だ。「並行した複数の変更では監督が難しかった。git worktreesは状況を悪化させた」と彼は書いている。並行作業を判断する基準は技術的な複雑さではなく、「人間が各ストリームを適切にレビューできる粒度か」にある。
コントロールを取り戻すべきシグナルもある。Claudeが確認なしに一気に実装を進め始めたとき、変更のスコープが当初の想定を超え始めたとき、エラーを修正しようとして別のエラーが連鎖し始めたときだ。最後のケースでは「やめる」と明示的に伝えて立ち止まることが重要になる。
スキル低下のリスクも、この文脈で正面から認識しておく必要がある。「Claudeに実装を任せながら、なぜそうなるのかを問い続けないと、エンジニア自身のスキルが停滞する」とMartynovは指摘している。「任せた」と「委譲した」は違う。コードの生成をClaudeが担っていても、なぜその実装になるのかを理解するプロセスをエンジニアが経ているかどうかが分岐点だ。ナビゲーターとして機能しているかどうかが問われる。
暗黙知を言語化する——Research-Plan-Implementワークフロー
コントロールを保ちながら効果を最大化するワークフローとして、Boris Tane（ナレッジベース）が実践するResearch-Plan-Implement 3フェーズがある。
プランなしで実装させると「Claudeが早期に合理的だが誤った仮定を行い、15分かけてその上に構築する」という失敗パターンに陥る。3フェーズに分けることでこれを防ぐ。
Phase 1: Research（調査）
「この機能を実装する前に、関連する既存のコードパターンと 制約を全て調べて。調査結果をresearch.mdにまとめて」
Phase 2: Planning（計画） 「上記の調査に基づいて、実装計画をplan.mdに書いて。 アプローチの詳細、変更するファイル、トレードオフを含めて。 コードはまだ書かないで」
Phase 3: Implementation（実装） 「計画を確認した。plan.mdに従って全て実装して」
このワークフローの本質は、研究フェーズで設計の意図・過去の失敗経験・運用上の制約といった暗黙知を言語化することにある。Claudeの推論の外側にある知識を、テキストとして渡す行為が品質を決める。
複雑な実装ではダブルレビュー戦略も有効だ。1つ目のClaudeセッションで実装計画を作り、2つ目のセッションで「スタッフエンジニア視点」でその計画をレビューさせる。異なるセッションが異なる視点を提供し、自己評価バイアスを排除できる。
チーム全体への展開——EMが設計する「全員にシニアペアを渡す」仕組み
個人の実践をチームに広げる設計は、EMの仕事だ。
CLAUDE.mdにペアリングの粒度ルールを定義するところから始めるといい。
# CLAUDE.md（ペアプログラミングルール）
<h2>Pair Programming Rules</h2> - 30分以内で終わる作業は直接実装してOK - 1時間以上かかる作業は必ずResearch→Plan→Implementの3フェーズで - スコープが曖昧な場合は実装前に「これは何を変えないか」を確認する - 3回連続でエラーが続いたら一度立ち止まって計画を見直す
「Task Diary」で個々のエンジニアの学びを組織知に変えることもできる。
作業完了後にClaude Codeへ:
「今日の作業を振り返って、以下をtask-diary.mdに記録して： - 何を試みたか - 何がうまくいったか（次回も使えるパターン） - 何が失敗したか（次回避けるべきパターン） - このプロジェクト固有の知識でCLAUDE.mdに追加すべきことはあるか」
このTask Diaryを1on1やランチMTGで共有し合う文化を作ることで、「Claude Codeとの上手い付き合い方」が組織のナレッジとして蓄積される。Martynovの「並行作業でコントロールを失った」「暗黙知をClaudeは持っていない」という学びは、チーム全体に共有できる知識だ。
効果の指標としてはリードタイムが分かりやすい。Rakutenは複数のClaude Codeセッションを並行して実行し、新機能の平均リードタイムを24営業日から5営業日に短縮した。ペアプログラミング導入の効果をDORAのリードタイムで測定することが、EMとして取り組みを評価する最初の足がかりになる。
Anthropicの実験では16エージェントが並行してRust製Cコンパイラ（Linuxカーネルをコンパイル可能）を約2,000セッションで構築した事例も報告されている。Claude Codeは単純なタスクを肩代わりするだけでなく、複雑なシステムを人間と協調して設計できる。「シニアエンジニアのペアが必要だが確保できない」という作業が今のチームにあるなら、そこにClaude Codeを割り当てると何が変わるかを問いかける価値がある。
まとめ
ペアプログラミングが機能しているかどうかは、エンジニアがナビゲーターとして機能しているかどうかで決まる。コードを書いているのがClaudeであっても、「なぜそうするのか」を判断しているのが人間であれば、それはペアプログラミングだ。
ドライバー/ナビゲーターの役割分担から始め、コントロールを取り戻すシグナルをチームで共有し、Task DiaryでClaude Codeとの知見を組織に蓄積する。EMが設計すべきのはこの文化だ。
コメント