Claude Codeでペアプロする設定 — 人がdriver、Claudeがnavigatorの役割分担
plan modeとLearning・Explanatory output styleを、ペアプロのdriverとnavigatorに対応させて使い分けます。小さな実装を人に残す切り替え基準と、役割を固定する設定例を載せます。
Claude Codeに任せきりにすると、コードは速く揃いますが、中身を理解しないまま先へ進みやすくなります。ペアプログラミングの「driver(キーボードを握る人)」と「navigator(方針を見て指示する人)」の分担を持ち込むと、この問題を設定で和らげられます。
Claude Codeにペアプロという名前の機能はありません。使うのは、plan modeと組み込みのLearning・Explanatory output styleの組み合わせです。どれをどの場面で使うかは、役割をどう置くかで決まります。
役割の置き方は3通りある
ペアプロの2つの席を、Claude Codeの機能に当てはめると次の表になります。この対応づけは公式の分類ではなく、記事での整理です。
| 誰がdriverか | Claudeの席 | 使う設定 | 向く場面 |
|---|---|---|---|
| 人 | Claudeの席navigator | 使う設定plan mode | 向く場面方針を固めたい、人が自分で書きたい |
| 人とClaudeが交代 | Claudeの席両方 | 使う設定Learning style | 向く場面小さな実装を人に残して学びたい |
| Claude | Claudeの席driver(人が見張り役) | 使う設定Explanatory style | 向く場面実装は任せ、理由を読みながら確認したい |
Learningは「人が書く場所を、Claudeが選んで空ける」スタイルです。完全にdriverを人へ戻すのではなく、判断の分かれ目だけを渡します。
plan modeは「Claudeが手を出せない」navigator席
plan modeでは、Claudeはファイルを読み、シェルコマンドで調べ、計画を書きます。ただしソースの編集はしません。計画を承認するまで、編集はブロックされます。
この性質が、navigatorの条件とそのまま重なります。navigatorは方針と注意点を口にしますが、キーボードには触りません。plan modeはその状態を権限の側で作るので、Claudeが気を利かせて勝手に書き始める心配がありません。
入り方は3つあります。
# セッション中: Shift+Tab を押してステータスバーの plan mode on を確認
# 1回のプロンプトだけ plan mode にする
/plan 認証ミドルウェアの差し替え方針を出して
# 最初から plan mode で起動する
claude --permission-mode planShift+Tabは権限モードを順に切り替えます。もう一度押すと、計画を承認せずにplan modeを抜けます。
計画は人が直してから渡せる
計画が出たら、Ctrl+Gで既定のテキストエディタに開いて直接書き換えられます。ペアプロでいえば、navigatorの提案をdriverが自分の言葉に直す工程です。承認の選択肢は次の3つです。
- Yes, and use auto mode: 承認してauto modeで実装に入る
- Yes, manually approve edits: 承認し、編集を1件ずつ確認する
- No, keep planning: plan modeのまま、計画の修正点を伝える
人がdriverでいたいなら、承認しないまま計画だけ受け取り、Shift+Tabでplan modeを抜けて自分で書く運用もできます。Claudeに実装させる場合でも、2番目の「manually approve edits」を選べば、1件ずつ差分を見る席に残れます。
plan modeの詳しい挙動はClaude Code Planモード完全ガイドに書いています。
Explanatoryは、Claudeが書くときの実況
Explanatoryでは、Claudeはいつもどおりに作業し、選んだ理由をInsightブロックで添えます。ブロックにはコードベースの癖や、書いたコードの判断が2、3点入ります。
説明は会話の中に出るだけで、ファイルへコメントとして書き込まれません。実況を残したくなければ、コミットに混ざる心配はありません。
役割でいえば、Claudeがdriverで、人はnavigatorです。実況を読んで「そのラッパーは使わない方針です」と止める。この形が成立するのは、Insightが人に判断材料を渡すからです。速さを優先する場面では、説明の分だけ出力トークンが増える点に注意が要ります。
Learningは、driverの席を人に戻すスタイル
Learningは、Explanatoryと同じInsightに加えて、コードの一部を人に書かせます。定型の実装はClaudeが進めます。エラー処理、データ構造、業務ロジックのように妥当な書き方が複数ある箇所に来ると、数行を空けて止まります。
Claudeはその場所にTODO(human)というコメントを置き、何ができていて、何を書き、何を考慮するかを依頼として出します。依頼の例は次の形です(公式ドキュメントの例に沿った形)。
● Learn by Doing
Context: The upload form is in place and calls validateFile() before accepting a file.
Your Task: In upload.js, implement the case "document" branch inside validateFile(). Look for TODO(human).
Guidance: Decide on a size limit for documents and whether the file extension has to match the MIME type.Claudeはここで止まって待ちます。人がTODO(human)の位置に書き、「できました」と伝えると、Claudeは書かれたコードについてInsightを1つ返して続きに戻ります。
ペアプロの交代制に近い動きです。ただし、どこを人に残すかを決めるのはClaudeで、人ではありません。残してほしい範囲が決まっているなら、後述のカスタムスタイルのほうが狙いに合います。
plan modeとLearningを同時に使うとき
plan modeは編集をブロックするので、TODO(human)をファイルへ置く作業は、計画を承認して編集が始まってから起きるはずです。計画の段階ではInsight付きの方針説明までが対象になり、人が書く場所の指定は実装に入ってからになる、という読み方になります。公式ドキュメントにこの組み合わせを扱った記述はないため、実際の挙動は手元で確かめてください。
場面ごとの切り替え基準
迷いやすいのは、plan modeとスタイルのどちらから決めるかです。plan modeは「Claudeが編集してよいか」を決める軸で、スタイルは「どう説明し、どこを人に残すか」を決める軸です。軸が別なので、組み合わせて使えます。
| 状況 | 起点にする設定 | 理由 |
|---|---|---|
| 初めて触るリポジトリで、変更の入り口を探す | 起点にする設定plan mode + Explanatory | 理由編集なしで構造を読ませ、判断の理由も受け取れる |
| 方針は決まっていて、人が手を動かして練習したい | 起点にする設定Learning | 理由定型部分は任せ、設計判断の数行を人が書く |
| 複数ファイルにまたがる変更の影響範囲を知りたい | 起点にする設定plan mode | 理由先に計画を出させ、承認前に人が直せる |
| 定型の修正を速く終えたい | 起点にする設定既定のスタイル | 理由説明も計画も不要。Insightの分だけ出力が増える |
| 細かい確認なしに先へ進めてほしい | 起点にする設定Proactive | 理由ただし次の理由でペアプロ向きではない |
Proactiveは、Claudeが妥当な前提を置いて着手し、通常の判断では質問しないスタイルです。plan modeにも、頼まない限り切り替えません。navigatorが口を出さずに走り出す形になるので、ペアプロとは逆向きです。
1回のペアプロセッションの流れ
人がdriver寄りで進めるときの流れを、手順にすると次のようになります。
plan modeからLearningへ移るペアプロの流れ
- 1
plan modeで入り口を決める
Shift+Tabでplan modeに入り、変更したい機能の影響範囲と手順を出させます。 - 2
計画を人が直す
Ctrl+Gで計画をエディタに開き、自分が書く部分と任せる部分に分けて書き足します。 - 3
スタイルをLearningに切り替える
/output-style learningを実行します。次のメッセージから新しいスタイルが効きます。 - 4
承認して実装に入る
「Yes, manually approve edits」を選びます。TODO(human)が出たら、人が書いて伝えます。
スタイルの切り替えは、セッション途中でもできます。プロンプトキャッシュの観点では、新しいスタイルの指示が会話の中のメッセージとして届くので、システムプロンプトと過去の会話はキャッシュから読まれたままです。切り替えで会話を作り直す必要はありません。
役割を設定で固定する
毎回切り替えるのが面倒なら、設定ファイルに書き込めます。/output-styleコマンドと/configのメニューは、選択を.claude/settings.local.jsonに保存します。直接書く場合は次のとおりです。
{
"outputStyle": "Learning"
}値は大文字小文字を区別します。learningと書くと一致せず、既定のスタイルになります。/output-styleコマンドのほうは大文字小文字を無視します。
プロジェクトの端末セッションをplan modeから始めたいなら、.claude/settings.jsonで既定の権限モードを指定します。
{
"permissions": {
"defaultMode": "plan"
}
}VS Code拡張はプロジェクトの設定を開始モードに使わないので、claudeCode.initialPermissionModeをユーザー設定に書きます。
CLAUDE.mdでペアの約束ごとを書く
スタイルが決めるのは話し方と役割で、プロジェクトの事情ではありません。ペアを組むときの約束ごとは、CLAUDE.mdに書いておくと、どのスタイルでも読み込まれます。次の断片は一例です。
## ペアプロの進め方
- 新しいモジュールを作る前に、既存の似た実装を3つ以内で挙げる
- 命名と境界を決める判断は、先に選択肢を2つ出して人に聞く
- テストの期待値は人が書く。実装側は書かないCLAUDE.mdとスタイルの住み分けはClaude Codeのoutput styleとCLAUDE.md・Skillsの違いで比べています。
人に残す範囲を自分で決めるカスタムスタイル
Learningは人に残す場所をClaudeが選びます。範囲を自分で決めたいときは、カスタムスタイルを使います。.claude/output-styles/navigator.mdに次のように書きます(指示文は例です)。
---
name: Navigator
description: 人がdriver。Claudeは方針とレビューに回る
keep-coding-instructions: true
---
人が書く部分に手を出さない。依頼されるまでファイルを編集しない。
実装の前に、方針と注意点を3点以内で示す。
人が書いたコードには、まず良い点を1つ挙げてから懸念を述べる。keep-coding-instructions: trueを付けると、Claude Codeが持つソフトウェア開発向けの指示を残したまま、話し方だけを変えられます。省くと、その指示が外れます。カスタムスタイルの書き方はoutput styleを自作する実践パターン集に例があります。
組み込みのLearningとExplanatoryをプラグインとして入れる方法は、別の記事learning output styleプラグインで学習モードにするで扱っています。
効かないときに見ること
役割分担がうまく回らないとき、原因は設定の外にあることが多いです。
- スタイルは「従うべき指示」であり、強制ではありません。Claudeが手を出しすぎる場合は、スタイルの文言を強めるより、plan modeで編集をブロックするほうが確実です
- 毎回必ず起きてほしい処理(編集後の整形など)は、スタイルではなくhookで保証します
- スタイルはメインの会話とフォークにだけ効きます。サブエージェントは自分のシステムプロンプトで動くので、Learningを選んでいても、サブエージェントの出力にInsightやTODO(human)は現れません
- スタイルを自作・編集したときは、端末ではClaude Codeを再起動しないと反映されません
- ExplanatoryとLearningは出力が既定より長くなるぶん、出力トークンが増えます
まとめ
編集を権限で止めたいときはplan mode、説明を足したいときはExplanatory、小さな実装を人に残したいときはLearningを選ぶのが基本です。plan modeは編集の可否、スタイルは説明と役割の分担を決める別の軸なので、両方を重ねて使えます。
人に残す範囲まで自分で決めたいなら、カスタムスタイルの出番です。迷ったら、まずplan modeで計画を出させ、その場で人が書く部分に印をつけるところから始めると、役割の分け方が実感しやすくなります。
参照した一次ソース
この記事の記述は、次の一次ソースと照合しています。更新時に参照先が変わった場合は一覧も更新します。