小さいPRで信頼を積む：Claude Codeの変更を1目的に刻んでレビューを通す

「このPR、あとで見とくね」

そう言われて3日放置されたPR、僕にも何本もあります。中身は800行。10個のファイルにまたがって、機能追加とリファクタとtypo修正が全部入り。レビュアーは開いた瞬間に「これは時間のあるときに…」とタブを閉じる。気持ち、わかります。僕も人のそういうPRを閉じてきました。

逆に、20行しか変わっていないPRは秒で承認されます。差分が頭に全部入るから、「これは安全」と即断できる。PRが通るかどうかは、コードの賢さじゃなくて「レビュアーが頭の中に収められるか」で決まるんですよね。

Claude Codeを使うと、ここがさらにシビアになります。AIは1時間で大量の差分を生み出せる。放っておくと、誰も読み切れない巨大PRが量産される。だから「小さく刻んで、証拠を添えて出す」技術が、AI時代のレビューでは効いてきます。

この記事の要点

• 小さいPRが強いのは3つ。レビューしやすい・壊れにくい・戻しやすい。この3つが信頼の正体です。
• ルールは1つだけ覚えればいい。1PR=1目的。「ついでに」を1個も混ぜない。
• 大きい変更は「土台→中身→仕上げ」の順で刻む。先に安全な準備を出し、本命を最後に小さく出す。
• AIに任せた差分こそ、テスト結果とdiffの要約を添える。レビューを「感想戦」から「検証作業」に変える。
• 証拠は盛りすぎない。レビュアーが30秒で判断できる量に絞るのがちょうどいい。

なぜ小さいPRだと信頼が積まれるのか

理由を3つに分けると腑に落ちます。

1つ目、レビューしやすい。 人がコードを読むとき、頭の中に「いま何を確認しているか」を保持できる量には限界があります。20行なら全部抱えられる。500行は無理です。読み切れないPRは、結局「動いてるっぽいからOK」で通る。それはレビューじゃなくて、ただのスタンプです。

2つ目、壊れにくい。 変更が小さいほど、壊れる範囲も小さい。1目的に絞ったPRなら、不具合が出ても原因はそのPRの中にしかありません。逆に機能追加とリファクタを混ぜると、バグが出たとき「どっちが原因？」の切り分けに半日溶けます。

3つ目、戻しやすい。 本番で問題が出たとき、いちばん速い対処は「そのPRをrevert」です。1PR=1目的なら、revertしても巻き添えがない。でも複数の目的が入っていると、戻したい変更と一緒に、残したい変更まで消える。これが怖くて、結局「前に進んで直す」しかなくなる。

この3つは、そのまま信頼の積み方です。小さいPRを安全に通す人は、「この人のPRは読めば分かるし、何かあっても戻せる」と思われる。レビュアーの心理的な負担が軽いから、次も気持ちよく見てもらえる。信頼って、行数の少なさから積まれるんですよね。

観点	大きいPR（混在）	小さいPR（1目的）
レビュー時間	長い・後回しにされる	短い・すぐ見てもらえる
バグの切り分け	原因が複数候補で難しい	このPR内に限定できる
rollback	巻き添えが出る	revert一発で安全
AIに任せたとき	差分が爆発して読めない	1目的なら追える

鉄則は「1PR=1目的」

小さいPRを作るコツは、行数を数えることじゃありません。**「このPRの目的は1文で言えるか」**を自問することです。

「記事下のCTAリンクを正しい商品に直す」。これは1目的。OKです。「CTAを直して、ついでにこのコンポーネントの型を整理して、あと気になってたtypoも」。これは3目的。アウトです。

「ついで」が混ざる気持ちはよくわかります。同じファイルを開いてるんだから、ついでに直したくなる。でも、その「ついで」が後でレビュアーを苦しめます。CTA修正を見たいだけなのに、無関係な型整理まで読まされる。最悪なのは、その型整理が原因でバグが出て、CTA修正ごとrevertされること。

僕のルールはシンプルです。作業中に「お、これも直したい」と思ったら、メモに書いて別PRにする。 その場では触らない。これだけで、PRが勝手に膨らむのを止められます。

Claude Codeに任せるときも同じで、「いい感じに直して」と投げると、AIは親切心で周辺もリファクタしてきます。だから依頼の時点で範囲を縛る。「対象は◯◯だけ。それ以外のファイルは触らないで」と最初に書く。これをやるかどうかで、出てくる差分の大きさが段違いに変わります。

大きい変更を小さく刻む順番

「でも、どうしても大きい変更が必要なときは？」という話。新機能の追加や、設計変更は、どうしたって差分が大きくなります。そういうときは、1本の巨大PRにせず、複数の小さいPRに刻む。順番が大事です。

僕がいつも使う順番は「土台→中身→仕上げ」です。

1. 土台（準備）を先に出す。 新しい関数やユーティリティを追加するだけ、まだ誰も呼んでいない状態。これは既存の動作を1ミリも変えないので、レビュアーは安心して通せます。「追加だけ、影響なし」と書けるPRは強い。
2. 中身（本命）を小さく出す。 土台ができていれば、本命の変更は「古い処理を新しい関数に差し替える」だけになり、差分が小さくなります。ここがいちばん壊れやすいので、単独で出してレビューを集中させる。
3. 仕上げ（後片付け）を最後に出す。 使わなくなった古いコードの削除、リネーム、整形。これも「削除だけ」「整形だけ」と1目的にすると、安全に通せます。

この順番のいいところは、各PRの「目的」が毎回1文で言えることです。「ユーティリティ追加」「処理の差し替え」「旧コード削除」。どれもレビュアーが頭に入れやすい。1本の巨大PRだったら絶対に後回しにされる変更が、3本に分ければサクサク進みます。

ブランチの切り方やrebaseでのコミット整理は、別記事のGitブランチ戦略の選び方に詳しくまとめています。「どこで枝を分けて、いつ本流に戻すか」を先に決めておくと、刻んだPRがきれいに積み上がります。

AIに任せた差分こそ、証拠を添える

ここが今回いちばん伝えたいところです。

Claude Codeに任せた変更は、差分が小さくても、それだけでは信頼されません。むしろAIが作った小さなPRほど、「なぜこの変更なのか」「どこまで確認したのか」「失敗したら戻せるのか」が書かれていないと、レビュアーは安心してマージできない。AIは依頼が曖昧でも、それらしい差分を平気で作るからです。

だから、差分に**証拠（テスト結果とdiffの要約）**を添えます。これがあるだけで、レビューが「なんとなく良さそう」という感想戦から、「条件を満たしているか」を見る検証作業に変わります。

僕はこれを「レビュー用の領収書」と呼んでいます。作業した本人にしか分からないメモじゃなくて、翌日に別の人が読んでも同じ判断ができる記録のことです。最低限、次の5つが入っていれば十分。

small_pr:
  owner: "Masa"
  goal: "記事下CTAから無料PDF登録への導線を正しい商品に直す"
  changed_files:
    - "site/src/content/blog/example.mdx"
    - "site/src/pages/products.astro"
  verification:
    - command: "npm test"
      result: "passed"
    - command: "npm run lint"
      result: "passed"
  rollback:
    command: "このPRをrevert"
    risk: "スキーマ変更なし。コンテンツのみの変更。"

このYAMLはそのままPR本文に貼れます。項目はチームに合わせて変えていい。ただgoal（目的1文）changed_files（触ったファイル）verification（実行したコマンドと結果）rollback（戻し方）は、削らないほうがいいです。この4つがあると、レビュアーは「目的は1つか」「テストは通っているか」「戻せるか」を一目で確認できます。

ポイントはgoalが1文で書けること。もし1文で書けないなら、それはPRが複数目的になっているサイン。書く前に分割を考えたほうがいいです。

レビュー基準を機械で見える化する

PR本文だけだと、人によって判断がブレます。「小さいPR」の定義を、小さな関数にして共有すると運用が安定します。Claude Codeにも人間にも、同じ基準を見せられる。

// PRが「レビューしやすい小さいPR」の条件を満たすか判定する
const pr = {
  goal: "記事CTAを正しい商品に直す",
  filesChanged: 2,         // 触ったファイル数
  commands: ["npm test", "npm run lint"], // 実行した検証
  diffSummaryWritten: true, // diffの要約を書いたか
  rollbackWritten: true,    // 戻し方を書いたか
};

export function isSmallAndReviewable(pr) {
  return pr.goal.length > 0 &&        // 目的が1文で書かれている
    pr.filesChanged <= 5 &&           // 触ったファイルは5つ以内
    pr.commands.length >= 1 &&        // 検証コマンドを1つ以上実行
    pr.diffSummaryWritten &&          // 差分の要約がある
    pr.rollbackWritten;               // 戻し方が書いてある
}

console.log(isSmallAndReviewable(pr)); // true

これは本番コードというより、基準の見える化です。filesChanged <= 5 の数字はプロジェクトに合わせて変えてください。大事なのは、Claude Codeに「良さそうならcommitして」ではなく「この条件を満たしたらcommit候補にして」と渡すこと。曖昧な指示は曖昧な差分を生み、明確な条件は明確な差分を生みます。

レビューで何を見るか（リスク・検証・収益導線）の観点そのものは、Claude Codeレビュー運用チェックリストに分けて書きました。この記事の「小さく刻む」と、あちらの「深くレビューする」はセットで効きます。

コピペで使える：刻んでテストを通すコマンド

実際の作業フローを、コマンドで置いておきます。1目的のブランチを切って、変更して、テストとdiffを確認してから出す、までの一連です。そのままコピペして動かせます。

# 1. mainを最新にして、1目的のブランチを切る（名前に目的を入れる）
git switch main
git pull
git switch -c fix/article-cta-link

# 2. 変更したら、まず触ったファイルの数を確認する（5つ以内が目安）
git status --short

# 3. 変更の差分を自分の目で見る（出す前に必ず読む）
git --no-pager diff

# 4. 証拠を作る：テストとlintを実行（結果をPR本文に貼る）
npm test
npm run lint

# 5. diffの統計（何ファイル・何行か）を要約としてPRに添える
git --no-pager diff --stat main

# 6. 1目的のコミットにして、PRを作る
git add -A
git commit -m "fix: 記事下CTAを正しい無料PDF商品へ修正"
git push -u origin fix/article-cta-link
gh pr create --fill

最後のgh pr createはGitHub CLIのコマンドです。--fillでコミットメッセージから本文を自動生成してくれるので、そこに上のYAMLやdiff --statの結果を貼り足すと、証拠つきの小さいPRが一発で出せます。git diff --statの出力が「3 files changed」くらいに収まっていれば、それはもう「読んでもらえるPR」です。

実例：1本の大改修を3本に刻んだ話

具体的にやると、こうなります。ClaudeCodeLabで「記事下の共通CTAを、読者の段階に合わせて出し分ける」という改修をしたときの刻み方です。本来なら新コンポーネント追加＋全記事の差し替え＋旧CTA削除で、軽く数百行の差分になる変更でした。

1本目：CTAコンポーネントを追加するだけ。 まだどの記事からも呼ばれていない、追加オンリーのPR。既存の表示は何も変わらないので、レビュアーは「影響なし」で即承認。検証はnpm testが通ることと、コンポーネント単体の見た目確認だけ。

2本目：代表記事5本だけ、新CTAに差し替える。 ここが本命で壊れやすいので、全記事ではなく5本に絞って出しました。差分が小さいから、レビュアーは公開URLを5つ見るだけで判断できる。スマホ幅でボタンが押しやすいか、リンク先が正しい商品か、ここに集中してもらえる。

3本目：残り記事の一括差し替えと、旧CTAの削除。 2本目で型が確定しているので、ここはほぼ機械作業。「同じパターンの適用」と「削除」だけの1目的PRなので、安全に通せました。

もし1本の巨大PRで出していたら、間違いなく「時間あるとき見ます」で塩漬けでした。3本に刻んだら、3本とも当日中にマージできた。刻むのは遠回りに見えて、実は最短ルートなんですよね。

失敗例と落とし穴

僕がやらかしてきたパターンを正直に置いておきます。

ついで修正の混入。 いちばん多い失敗です。CTAを直すPRに、無関係なtypo修正やリファクタを入れてしまう。レビュアーは「このリファクタ、このPRに必要？」で止まる。1個でも目的が増えたら、別PRにする。

PR本文が「Claude Codeで修正しました」だけ。 これだとレビュアーが最初から全部読む羽目になります。AIが作った差分ほど、「どこを見ればいいか」「何を確認したか」を先に示す。証拠を添えるのはそのためです。

buildが通ったことだけを証拠にする。 buildは構文や依存関係の確認には有効ですが、表示崩れや動作までは保証しません。テストを実行して、その結果を添える。テストがないなら、最低限「公開URLでここを目視した」と書く。

rollbackを書かないPR。 コンテンツ修正なら「revert一発」で済むことが多い。でも、外部設定やデータ移行が絡むと話が変わります。rollbackが1行で書けないPRは、そもそも小さいPRじゃない可能性が高い。 戻し方を書こうとして手が止まったら、分割のサインです。

証拠の盛りすぎ。 これも落とし穴。スクリーンショットを10枚貼っても、レビュアーは見ません。対象URL、確認した画面幅、残ったリスクを短く書くほうが効く。領収書であって、監査報告書じゃない。

よくある質問

Q. PRはどのくらいの行数までが「小さい」ですか？ A. 厳密な行数の正解はありません。目安は「レビュアーが一度に頭へ入れられるか」。経験的には変更ファイル5つ以内、差分が数十〜200行くらいに収まると、後回しにされにくいです。それより、目的が1文で言えるかを優先してください。

Q. 機能追加とテスト追加は別PRにすべきですか？ A. そのテストが「その機能の動作を保証する証拠」なら、同じPRに入れて構いません。機能とテストはセットで1目的です。逆に、無関係な既存機能のテストを「ついで」で足すなら、別PRにします。

Q. 依存しあう変更を小さく刻むと、順番待ちで遅くなりませんか？ A. なります。だから「土台→中身→仕上げ」の順で、先に出した土台が安全（追加のみ・影響なし）になるよう設計します。安全なPRは速く通るので、後続が詰まりにくい。詰まるのはたいてい、各PRが大きくて1本ずつのレビューに時間がかかるときです。

Q. Claude Codeが勝手に大きい差分を作ってしまいます。 A. 依頼の時点で範囲を縛ってください。「対象は◯◯のファイルだけ。それ以外は触らないで」「リファクタは今回しないで」と先に書く。出てきた差分が大きすぎたら、git diff --statで確認して、目的ごとにコミットを分け直すか、依頼をやり直します。

Q. 証拠（Proof）は毎回手で書くんですか？ A. 続かないので、Claude Codeに型を渡して書かせます。「変更目的を1文、触ったファイル、実行したコマンドと結果、戻し方、をこの形で出して」と頼む。未確認なのに「確認済み」と書かせないことだけ、依頼文で釘を刺しておきます。

まとめ：実際にやってみて変わったこと

巨大PRを量産していた頃、僕のPRは「あとで見ます」の墓場でした。1PR=1目的に刻むようにしてから、いちばん変わったのはレビューが返ってくる速さです。小さいPRは怖くないから、みんな気軽に見てくれる。承認が速いと、自分も気持ちよく次へ進める。

Claude Codeを使うようになって、この効きがさらに強くなりました。AIは差分をいくらでも作れるぶん、「小さく刻んで、テストとdiffの証拠を添える」をやらないと、誰も読み切れないPRが溜まる一方になる。逆にこの型さえ守れば、AIに任せた変更でも安心して通せます。

次に変更を出すときは、コードを書く前に一度だけ自問してください。「このPRの目的は、1文で言えるか？」。言えないなら、刻むタイミングです。小さいPRは、ただ小さいだけでは価値がない。読み手が頭に収められて、壊れても戻せて、証拠で確認できるとき、初めて「信頼を積む小さいPR」になります。

手元の確認コマンドやレビュー用テンプレートをまとめて欲しいなら教材・テンプレート一覧が入口になります。チームの分岐ルールやレビュー基準ごと設計したいならClaude Code研修・導入相談で、いまの開発フローを題材に一緒に組み立てられます。