Claude Codeでのペアプログラミング: 機能する点と機能しない点
実際のペアプログラミングには、コードを両方が見られ、リアルタイムで互いに反応し合える二人がいます。Claude Codeを使った作業はそれほど完璧には近づきませんが、一人で作業するよりは近いです。
数週間にわたり「私の代わりに書いてくれる」というセッションよりも、ペアリングセッションのように扱ってきた結果、私が学んだことです。
実際のペアリングのように機能する点
コードを書く前にアプローチを口に出して説明する。 「ルートハンドラが実行される前にトークンを検証するミドルウェア関数でこれを処理するつもりです。これについてどんな問題が見えますか？」
エージェントが必ずしも正しい問題を見つけられるとは限りません。しかし、アプローチを大声で説明することは、反応を返すだけのものにも、説明しない場合より多くの問題を捉えます。
「運転役」を入れ替える。 ときどき私はコードを書いてエージェントにレビューを依頼します。ときどきエージェントがコードを書き、私がそれをレビューします。実際には、方向性よりもレビューが行われることの方が重要です。
なぜかを説明する、何をしたかだけでなく。 「ここに入力検証を追加するのは、データベースへ渡るユーザー入力があるからです」 という説明は、「ここに入力検証を追加する」だけよりも良いコードを生み出します。エージェントは「なぜ」を使って検証ロジックの判断をより良くします。
実際のペアリングには近くない点
リアルタイムのやり取り。 人間のペアは実装途中で「待って、なぜそのやり方をするのか」と質問します。エージェントにはその直感がありません。チェックポイントの瞬間を組み込んでいなければ、理解したまま止まって問い直すことなく実装してしまいます。
場の空気を読む。 人間のペアは、あなたが何か確信がないとき、言い方でそれを見抜くことができます。エージェントにはそれはできません。自分が不確かである場合は、それを明示的に言う必要があります。
共有コンテキスト。 人間のペアは同じ会話に参加し、同じコードベースを読み、同じ問題を解決してきました。エージェントはこのセッションで伝えたことを知っています。長時間にわたる共有コンテキストの維持はあなたの責任であり、エージェントの責任ではありません。
実際のペアリングに最も近いパターン
最も生産的なペアリング風セッションは、次のリズムに従うことが分かりました：
- 「目標と自分が検討しているアプローチを説明する」
- 「エージェントが質問や懸念を挙げる」
- 「フィードバックを取り入れて私が決定する」
- 「私が決定した内容をエージェントが実装する」
- 「新しい視点で出力を確認する」
ステップ2が決定的に重要です。もしそれを省略すると（「私が説明した内容をそのまま実装するだけ」）、ペアリングの利点を失います。質問や懸念は、的外れであっても、私により慎重に考えさせます。
builtbyzac.comでの6週間のClaude Codeの運用から。
