Claude Codeでペアプログラミングする実践ガイド｜AIに任せすぎない開発ワークフロー

Claude Codeでのペアプログラミングは、「AIにコードを書かせる」だけでは安定しません。うまくいく人は、人間が目的・制約・検証方法を握り、Claude Codeには調査、差分作成、テスト実行、レビュー補助を任せています。

公式のClaude Code概要では、Claude Codeはコードベースを読み、ファイルを編集し、コマンドを実行できるエージェント型コーディングツールと説明されています。つまり、普通のチャットAIよりも強力ですが、曖昧な指示のまま走らせると、間違った方向にも速く進みます。

この記事は、Claude Code入門ガイドの次に読む実践編です。Masaが日常の小さな修正、レビュー、テスト追加で使っている型をもとに、初心者でも再現しやすいプロンプト、作業順、失敗例までまとめます。

まず役割分担を決める

AIペアプログラミングで最初に決めるべきことは、どちらが「運転席」に座るかです。実装速度だけを見ればClaude Codeに任せたくなりますが、プロダクトの意図、リスク判断、最終承認は人間側に残した方が安全です。

役割	人間が担当すること	Claude Codeに任せること
目的設定	何を直すか、何を直さないかを決める	目的に合う変更候補を探す
調査	読むべき範囲を指定する	関連ファイル、履歴、テストを読む
実装	許可する差分範囲を決める	小さな単位でコードを書く
検証	合格条件を決める	テスト、lint、ビルドを実行する
レビュー	マージ可否を判断する	リスク、抜け漏れ、代替案を列挙する

この分担にすると、Claude Codeは「代筆者」ではなく「作業を進める相棒」になります。特に初心者は、最初から大きな機能を任せるより、1つのバグ、1つのテスト、1つのコンポーネントから始める方が学習もレビューも楽です。

なお、この記事の前提は「AIが正しいか」ではなく「正しさを確認できる形に分解できるか」です。Claude Codeに任せる範囲を小さくし、毎回の完了条件を明文化するほど、初心者でも差分を追いやすくなります。

最初の10分で整える設定

作業前の準備で品質はかなり変わります。Claude Codeのベストプラクティスは「検証できる手段を渡す」「探索、計画、実装を分ける」ことを強調しています。私は毎回、次の3点を確認します。

1つ目はブランチです。mainで直接作業せず、必ず作業用ブランチかworktreeを使います。2つ目はCLAUDE.mdです。メモリ機能の公式説明にある通り、CLAUDE.mdは毎セッションで読まれる永続的な指示です。3つ目は検証コマンドです。テストがない場合でも、最低限の型チェックやビルドを渡します。

# CLAUDE.md

## Project rules
- Before editing, summarize the files you plan to inspect.
- Prefer small diffs and explain risky changes before applying them.
- After code edits, run `npm run lint` and the narrowest relevant test.
- Do not read `.env*` files or change deployment settings without approval.

## Common commands
- `npm run lint`
- `npm run test`
- `npm run build`

このファイルは長くしすぎないことが重要です。すべての知識を詰め込むと、肝心なルールが埋もれます。よく使う反復手順は、現在のClaude CodeではSkillsとして切り出す選択肢もあります。

基本ループは探索、計画、実装、検証

Claude Codeにいきなり「作って」と頼むと、要件の解釈がずれたまま実装が進むことがあります。私は次のループを使います。

flowchart LR
  A[目的を1文で渡す] --> B[関連ファイルを探索]
  B --> C[実装計画を確認]
  C --> D[小さく編集]
  D --> E[テストと差分確認]
  E --> F{合格か}
  F -- いいえ --> C
  F -- はい --> G[PR用に要約]

最初のプロンプトは長文である必要はありません。ただし、目的、範囲、禁止事項、確認方法は入れます。

目的: ログイン後にプロフィール画面で500が出る不具合を直したい。
範囲: `src/auth` と `src/pages/profile` を中心に調べてください。
禁止: 認証方式の変更、DBスキーマ変更、`.env`の読み取りは禁止です。
進め方: まず関連ファイルを読んで原因候補を3つ出し、編集前に計画を提示してください。
検証: 既存の認証テストと `npm run lint` を実行してください。

計画が出たら、そのまま承認せずに「一番小さい差分にしてください」「テストを先に追加してください」と絞ります。TDD、つまりテスト駆動開発を使う場合は、失敗するテストを先に書かせるとレビューしやすくなります。

計画は良いですが、まず再現テストだけを書いてください。
テストが失敗することを確認してから、実装に進んでください。
本番コードの変更は1ファイルずつ提案してください。

コピペで試せる小さな検証例

練習には、本番コードではなく小さな判定関数を使うのが向いています。次の例は「Claude Codeにどこまで任せるか」を決めるための単純なルールです。pair-check.test.tsとして保存し、Vitestで実行できます。

import { describe, expect, it } from "vitest";

type ClaudeMode = "direct" | "plan-first" | "human-review";

export function decideClaudeMode(input: {
  changedFiles: number;
  touchesSecrets: boolean;
  hasReliableTests: boolean;
}): ClaudeMode {
  if (input.touchesSecrets) return "human-review";
  if (input.changedFiles > 3) return "plan-first";
  if (!input.hasReliableTests) return "plan-first";
  return "direct";
}

describe("decideClaudeMode", () => {
  it("allows direct work for small, well-tested changes", () => {
    expect(
      decideClaudeMode({
        changedFiles: 1,
        touchesSecrets: false,
        hasReliableTests: true,
      }),
    ).toBe("direct");
  });

  it("requires a plan for broad changes", () => {
    expect(
      decideClaudeMode({
        changedFiles: 5,
        touchesSecrets: false,
        hasReliableTests: true,
      }),
    ).toBe("plan-first");
  });

  it("requires human review for secret-related work", () => {
    expect(
      decideClaudeMode({
        changedFiles: 1,
        touchesSecrets: true,
        hasReliableTests: true,
      }),
    ).toBe("human-review");
  });
});

npm install -D vitest typescript
npx vitest run pair-check.test.ts

このような小さなコードを題材にすると、Claude Codeに「失敗テストを追加して」「境界値を増やして」「関数名を読みやすくして」と頼む練習ができます。実務では同じ考え方を、APIハンドラ、Reactコンポーネント、バッチ処理に広げます。

実務で効く4つのユースケース

1つ目は、既存機能に小さな条件を足す作業です。例として「無料プランではCSVエクスポートを非表示にする」のような変更は、関連ファイルを探し、UIとAPIの両方を確認し、テストを足す練習になります。

2つ目は、不具合調査です。エラーログ、再現手順、期待結果を渡すと、Claude Codeは原因候補を広く拾えます。公式のCommon workflowsでも、再現コマンドやスタックトレースを渡すパターンが紹介されています。

3つ目は、テスト追加です。既存のテストスタイルを読ませてから「正常系、権限なし、入力不正の3ケースを追加」と頼むと、プロジェクトの書き方に寄せやすくなります。テスト戦略ガイドと組み合わせると、カバレッジの穴を見つけやすくなります。

4つ目は、PRレビュー前のセルフレビューです。git diffを読ませて「仕様漏れ、セキュリティ、後方互換性、テスト不足を優先して指摘」と依頼します。GitHubのPull request review documentationにもある通り、レビューはコメント、承認、変更要求でチームの品質を守る場です。Claude Codeは人間レビューの代替ではなく、レビュー前の粗取りに使うのが現実的です。

具体的な落とし穴と回避策

落とし穴	起きること	回避策
「いい感じに直して」と頼む	仕様にないリファクタが混ざる	範囲、禁止事項、合格条件を明記する
差分を大きくしすぎる	レビュー不能になり、バグも混ざる	1タスク1差分、先に計画を出させる
検証を任せない	見た目だけ成功したように見える	テスト、lint、ビルド、スクショ確認を指定する
CLAUDE.mdを肥大化させる	重要ルールが読まれにくくなる	何度も使う手順はSkillへ分離する
権限を広げすぎる	秘密情報や本番操作に触れる	hooksやpermissionで止める

特に危険なのは、承認疲れです。毎回すべてを承認していると、危ないコマンドも流れで許可しがちです。破壊的な操作、デプロイ、外部APIへの書き込みは、プロンプトではなく設定やフックで止める方が堅いです。詳しくは権限とサンドボックスの実践ガイドも参考にしてください。

チームで使うならPRまでを型にする

チームで使う場合は、Claude Codeとの会話だけで完結させず、PRに残る形へ変換します。最後に次のプロンプトを使うと、レビューしやすい説明になります。

この差分をPR説明用にまとめてください。
含めるもの:
- 変更の目的
- 主要な変更ファイル
- 実行した検証コマンドと結果
- レビューで特に見てほしいリスク
- 変更しなかった範囲

GitHubでは、提案変更をコメントとして残したり、会話を解決済みにしたりできます。Claude CodeにPR本文の下書きを作らせても、最終的な言葉は人間が整えます。特にセキュリティ、課金、個人情報に関係する差分では、AIの「問題ありません」を根拠にしないでください。

この記事で紹介した内容を実際に試した結果

Masaが小さなNext.js修正でこのループを使ったところ、最初から「実装して」だけ頼んだ時よりも、差分確認の時間が短くなりました。理由は単純で、最初に禁止事項と検証コマンドを渡したため、Claude Codeが余計なファイルを触らず、最後にlintとテスト結果を会話内に残したからです。一方で、テストが薄い画面修正ではまだ人間の目視確認が必要でした。結論として、Claude Codeペアプログラミングは「任せる技術」ではなく、「任せる範囲を設計する技術」です。

次に試すなら、今日の作業から1つだけ選び、探索、計画、実装、検証の4ステップで進めてみてください。チーム導入やレビュー基準づくりまで整えたい場合は、ClaudeCodeLabのトレーニングも用意しています。