Claude Codeとペアプロ｜AIを相棒にして任せすぎない開発の型

「ここのバグ直しといて」とだけ頼んだら、Claude Codeが30分後に12ファイルを書き換えて戻ってきました。

バグは確かに直っていた。でも、ついでに認証まわりを「ちょっと整理」されていて、ログインが丸ごと壊れていたんです。

賢いのに、なんでこうなる。理由はシンプルで、僕が「何をしないか」を一度も言わなかったからでした。

ペアプログラミングって、相手が人間でも、黙って全部任せたらだいたい事故ります。AIならなおさら。今日は、Claude Codeを「代筆マシン」じゃなくて「ちゃんと働く相棒」にするための、役割分担と進め方を、僕がやらかした失敗込みで書きます。

この記事の要点

• Claude Codeは「コードを書かせる道具」ではなく「作業を進める相棒」。目的・制約・合否判定は人間が握り、調査・差分・テスト実行・レビュー補助を任せる。
• 基本ループは 探索 → 計画 → 実装 → 検証 の4つ。いきなり「作って」はだいたいズレる。
• 最初のプロンプトに 目的・範囲・禁止事項・検証方法 の4点を入れるだけで、暴走がほぼ消える。
• 危ない操作（削除・本番DB・課金・force push）はプロンプトでお願いせず、CLAUDE.md や permission/hook で止める。
• 任せるのは「失敗しても戻せる小さい仕事」から。1バグ・1テスト・1コンポーネントで十分。

まず「運転席」を決める

ペアプロで最初に決めるのは、どっちがハンドルを握るか、です。

実装スピードだけ見るとClaude Codeに全部投げたくなります。実際めちゃくちゃ速い。でも、「何のために直すか」「どこまでやっていいか」「これでマージしていいか」の判断は、人間に残しておくのが安全です。ここを渡すと、冒頭の「ログイン全壊」みたいなことが起きます。

僕が今使っている分担はこんな感じです。

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

この表のミソは、左側（判断）を絶対に手放さないことです。右側（手を動かす作業）はどんどん任せていい。むしろ任せたほうが速い。

公式のClaude Code概要でも、Claude Codeはコードベースを読み、ファイルを編集し、コマンドを実行できる「エージェント型」のツールだと説明されています。要するに普通のチャットAIより手が長い。手が長いぶん、行き先を間違えると遠くまで全力で走っていきます。だから運転席が大事なんです。

この記事はClaude Code入門ガイドの次に読む実践編のつもりで書いています。入門でインストールと初回起動を終えた人が、「で、どう一緒に作業するの?」の答えにできる内容にしました。

最初の10分で土台を整える

作業に入る前のちょっとした準備で、その日の品質がだいぶ変わります。Claude Codeのベストプラクティスでも「検証できる手段を渡す」「探索・計画・実装を分ける」が強調されています。僕は毎回この3つだけ確認します。

1つ目はブランチ。mainで直接やらない。必ず作業用ブランチか worktree を切ります。事故ったとき git checkout . で全部戻せる状態にしておくと、心理的にすごく楽です。

2つ目は**CLAUDE.md**。メモリ機能の公式説明にある通り、CLAUDE.md は毎セッション自動で読まれる「常設の指示書」です。ここに「やってほしいこと」と「絶対にやるな」を書いておくと、毎回プロンプトで念押ししなくて済みます。

3つ目は検証コマンド。テストがなくても、せめて型チェックかビルドのコマンドは渡す。「動いたかどうか」をAI自身が確かめられる手段を持たせるためです。

僕の CLAUDE.md の中身はだいたいこんな感じです。

# 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.md を100行近くまで膨らませて、結局いちばん大事な「.envを読むな」が効かなくなったことがあります。短く、効くものだけ。よく使う反復手順は、いまのClaude CodeならSkillsとして別ファイルに切り出せます。

基本ループは「探索 → 計画 → 実装 → 検証」

いきなり「作って」と頼むと、要件の解釈がズレたまま実装が走って、できあがってから「そうじゃない」が発覚します。これがいちばん時間を溶かすパターン。

なので僕は、必ずこの順番でやります。

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

ポイントは「計画」と「実装」の間に一回立ち止まること。ここで方向が合っているか確認すれば、手戻りが激減します。

最初のプロンプトは長文じゃなくていい。ただし目的・範囲・禁止事項・確認方法の4点は必ず入れます。

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

この「禁止」の行が、冒頭の事故を防ぐ命綱です。僕は「認証方式の変更」を禁止に入れ忘れて、それで一度ログインを壊しました。以来、この1行は儀式みたいに毎回書いています。

計画が返ってきたら、すぐ承認せずに絞ります。

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

TDD(テスト駆動開発、先に失敗するテストを書いてから実装する進め方)を使うなら、この「先に再現テスト」が特に効きます。テストが先にあると、AIの実装が正しいかどうかを人間が悩まなくて済む。テストが赤から緑に変わったかを見るだけでいいからです。

コピペで試せる、小さな判定関数

いきなり本番コードで練習すると、失敗したとき被害が大きい。なので最初は、小さな判定関数を題材にするのがおすすめです。

下のコードは「この変更、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"; // 小さくてテスト済みなら直接やらせてOK
}

describe("decideClaudeMode", () => {
  it("小さくテスト済みの変更は直接やらせる", () => {
    expect(
      decideClaudeMode({
        changedFiles: 1,
        touchesSecrets: false,
        hasReliableTests: true,
      }),
    ).toBe("direct");
  });

  it("広い変更はまず計画を出させる", () => {
    expect(
      decideClaudeMode({
        changedFiles: 5,
        touchesSecrets: false,
        hasReliableTests: true,
      }),
    ).toBe("plan-first");
  });

  it("秘密情報に触る変更は人間レビュー必須", () => {
    expect(
      decideClaudeMode({
        changedFiles: 1,
        touchesSecrets: true,
        hasReliableTests: true,
      }),
    ).toBe("human-review");
  });
});

実行はこれだけ。

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

こういう小さいコードを題材にすると、「失敗テストを追加して」「境界値のケースを増やして」「この関数名、読みやすくして」といった頼み方の練習が、ノーリスクでできます。慣れてきたら同じ考え方を、APIハンドラ、Reactコンポーネント、バッチ処理に広げていけばいい。最初の一歩としては、この30行くらいがちょうどいいです。

実務で効く4つの使い方

僕が日常で実際に回している使い方を、効果が出やすい順に4つ。

1. 既存機能に小さい条件を足す たとえば「無料プランではCSVエクスポートを非表示にする」みたいな変更。UIとAPIの両方を直す必要があって、関連ファイルを探して、テストを足す、という一連の流れを練習できます。範囲が狭いのでレビューも楽。

2. 不具合の調査 エラーログ・再現手順・期待結果の3つを渡すと、Claude Codeは原因候補を広く拾ってきます。公式のCommon workflowsでも、再現コマンドやスタックトレースを渡すパターンが紹介されています。ここで大事なのは、AIが出した1つ目の原因に飛びつかず、「候補を3つ出して」と複数挙げさせること。1個目が見当違いなこと、わりとあります。

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

4. PR前のセルフレビュー git diff を読ませて「仕様漏れ・セキュリティ・後方互換性・テスト不足を優先して指摘して」と頼みます。GitHubのプルリクエストレビューの解説にもある通り、レビューはコメント・承認・変更要求でチームの品質を守る場です。Claude Codeは人間レビューの代わりにはならないけど、**人間が見る前の「粗取り」**には抜群に効きます。

やりがちな落とし穴と回避策

ここは僕が全部やらかしたやつです。順番に踏んできました。

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

いちばん危ないのは、表の一番下「権限の広げすぎ」と、それに付随する承認疲れです。

最初は1つ1つ確認していても、何十回も「許可しますか?」が出ると、だんだん中身を見ずにEnterを押すようになります。これが本当に怖い。破壊的な操作・デプロイ・外部APIへの書き込みは、プロンプトで「気をつけてね」とお願いするんじゃなくて、設定やフックで物理的に止めるのが堅いです。具体的なやり方は権限とサンドボックスの設定にまとめました。

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

一人で使うときと、チームで使うときは、ゴールが違います。

チームなら、Claude Codeとの会話で完結させちゃダメです。会話は消えるけど、PRは残る。だから最後に、レビューしやすい形に変換させます。僕はこのプロンプトを定型文として持っています。

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

最後の「変更しなかった範囲」が地味に効きます。レビュアーが「これも直すべきでは?」と悩む時間を先回りで消せるからです。

ただし、PR本文の下書きをAIに作らせても、最終的な言葉は人間が整える。特にセキュリティ・課金・個人情報がからむ差分では、AIの「問題ありません」を承認の根拠にしないでください。そこだけは人間が腹をくくって判断する場所です。

よくある質問

Q. Claude Codeに全部任せて、人間は寝てればいいんじゃない? A. 小さくて戻せる作業ならアリですが、判断（何を直すか・マージしていいか）まで渡すと事故ります。手を動かす作業は任せて、ハンドルは握る。これが現実的なバランスです。

Q. プロンプトは長く詳しく書いたほうがいい? A. 長さより中身です。目的・範囲・禁止事項・検証方法の4点が入っていれば、短くても十分機能します。逆に、この4点が抜けた長文より、入った3行のほうが事故りません。

Q. テストがないプロジェクトでも使える? A. 使えますが、まず「再現テストを先に書かせる」ところから始めるのがおすすめです。テストが1本でもあると、AIの実装が合っているかを目視じゃなく機械で確認できて、レビューが一気に楽になります。

Q. 危ない操作を勝手にやられないか心配です。 A. プロンプトでのお願いは破られる前提でいてください。削除・本番DB・force push・課金などは、CLAUDE.md の禁止ルールに加えて、permissionやhookで止めるのが確実です。二重に守る。

Q. 入門記事を読んだ直後でも実践できますか? A. できます。まず入門ガイドでインストールと初回起動を終えて、この記事の「探索→計画→実装→検証」を1タスクで回してみてください。1回やると感覚がつかめます。

実際に試した結果

僕が小さなNext.jsの修正でこのループを使ったら、最初から「実装して」とだけ頼んでいた頃より、差分確認の時間がはっきり短くなりました。

理由は単純で、最初に禁止事項と検証コマンドを渡したから、Claude Codeが余計なファイルに手を出さず、最後に lint とテストの結果を会話に残してくれたからです。「これ通ってる?」を自分で git diff しながら確認する手間が消えた。

一方で、テストが薄い画面まわりの修正は、いまだに人間の目視確認が必要です。ここは正直、AIに任せきれていない。だからこそ「任せる範囲を設計する」が大事なんだと、毎回思います。Claude Codeペアプログラミングは「任せる技術」じゃなくて、**「任せる範囲を決める技術」**です。

次に試すなら、今日の作業から1つだけ選んで、探索→計画→実装→検証の4ステップで回してみてください。たぶん最初の1回で「あ、これ楽だ」となります。

チーム導入やレビュー基準づくりまで整えたいなら、ClaudeCodeLabのトレーニングも用意しています。学習用の教材をまとめて見たい人は教材一覧からどうぞ。