コードレビューの進め方とコメントの書き方：Claude Codeに一次レビューを任せる型

「このPR、まだレビュー終わってないですか？」

金曜の夕方、Slackでそう聞かれて画面を開いたら、差分が2,300行ありました。新機能とリファクタとtypo修正が全部入った、いわゆる全部入りPR。僕は週明けまで放置し、月曜に「LGTMです」とだけ書いて承認しました。中身はほとんど読んでいません。

正直に書きます。これは「レビューした」ではなく「レビューしたふり」です。そして、こういうPRを生むのも、こういう承認を返すのも、たいていは個人のサボりではなくチームの進め方が悪いだけなんですね。

レビューが機能しない原因は、レビュアーの能力や真面目さではありません。PRが大きすぎる、コメントの書き方が刺々しい、レビューを溜める、誰が何を見るか決まっていない——この4つです。今日はこの4つを潰す進め方と、Claude Codeに一次レビューを任せて人間が設計判断に集中する流れをまとめます。

観点ごとの「何をチェックするか」（正しさ・可読性・セキュリティ・テスト・設計）は、姉妹記事のコードレビュー チェックリスト＋Claude Codeで一次レビューを回す方法に分けてあります。この記事は「どう運用して、どうコメントを書くか」という文化と段取りに絞ります。

この記事の要点

• レビューの目的は「間違い探し」ではなく、設計のズレを早く見つけて学びを共有すること。バグ検出は副産物。
• PRは小さく出す。目安は変更400行・1テーマまで。大きいPRはレビュー品質が落ち、放置されやすい。
• コメントは「指摘」と「提案」を分け、nit: などの接頭辞で重要度を示す。命令ではなく質問の形にすると角が立たない。
• レビューは溜めない。来たら半日以内に一次反応を返す運用にすると、PRの滞留が消える。
• 機械でわかること（lint・型・テスト・差分サイズ）はCIに、文体や好みの揉めごとは規約に寄せ、人間とClaude Codeは設計の議論に時間を使う。

レビューの目的を「バグ探し」から外す

多くのチームでレビューが重くなるのは、レビューを「バグの最終防衛ライン」だと思っているからです。だから漏れが怖くて全部読もうとし、結果として時間がかかり、溜まり、形だけの承認に逃げる。

僕がチームで合意したレビューの目的は、もっと手前にあります。

1. 設計のズレを早く見つける — 実装し切る前に「その分割でいい？」を言い合う場
2. コードの背景を共有する — なぜこの実装にしたかが、レビューのやりとりで記録に残る
3. コードの所有を分散する — 自分が書いていない箇所も「読んだことがある」状態にする

バグ検出はこの過程の副産物です。本気でバグを止めたいなら、人間の目より先にテストと型チェックを置くほうがずっと確実なんですね。レビューは「人間にしかできない判断」——設計の妥当性、業務的に正しいか、半年後の自分が読めるか——にエネルギーを寄せる。この前提に立つだけで、レビューはぐっと軽くなります。

PRを小さく出す：これがレビューの9割

進め方の話で一番効くのは、テクニックでも文化でもなく、PRのサイズです。冒頭の2,300行PRは、誰がレビューしても「LGTM」になります。人間の集中力は、差分が大きくなるほど雑になるからです。

僕の目安はこうです。

差分の規模	レビューの現実	対応
〜200行	全行ちゃんと読める	そのまま出す
200〜400行	集中すれば読める	1テーマに絞れているか確認
400〜800行	後半が雑になる	分割を検討。無理なら観点を絞って依頼
800行〜	ほぼ読まれない	原則分割。生成コード等の例外のみ許可

「1 PR = 1テーマ」を守るのもセットです。リファクタと機能追加を混ぜない。混ざると、レビュアーは「この変更は新機能のため？それとも掃除？」を毎行で考えることになり、判断コストが跳ね上がります。

PRを小さくする習慣そのものは、出す側の型としてレビューで止まるPRを減らす：小さく出して自分で説明する型に詳しくまとめました。差分サイズをCIで止める仕組みも載せています。

コメントの書き方：指摘と提案を分ける

レビュー文化が壊れる二大原因のひとつが、コメントのトゲです。「ここ、なんでこう書いたんですか？」は、書いた本人にとっては純粋な質問でも、受け取る側には詰問に見えます。

僕が徹底しているのは、重要度を接頭辞で明示することです。これだけで空気が変わります。

接頭辞	意味	例
must:	直さないとマージできない	must: ここ未ログインでも通ります。認可チェックを足してください
imo: / suggest:	提案。従わなくてもいい	imo: ここ早期returnにすると読みやすいかも
nit:	些細な好み。スルー可	nit: 変数名 tmp より rawInput が分かりやすいです
q: / question:	純粋な質問	q: このリトライ、上限なしで大丈夫ですか？
praise:	良かった点	praise: このテストの切り方、参考になります

接頭辞があると、レビュイーは「全部直さなきゃ」というプレッシャーから解放されます。nit: はスルーしていい、must: だけ必ず対応、と一目で分かるからです。

書き方のコツもいくつか。命令ではなく質問や提案の形にする。「直して」より「〜にするとどうですか？」。主語をコードにする。「あなたのコードは」ではなく「このコードは」。理由を添える。「ここ修正」だけでなく「ここ、Nullになり得るので落ちます」。人ではなくコードを critique する、これがレビュー文化の基本姿勢です。

逆に、絶対に揉めるのが好みの押しつけです。「僕はこう書く」を must: で出すのは事故のもと。インデント、命名の細部、import順——こういう文体は人間が議論する話題ではなく、フォーマッタとlintに任せる領域です。揉めごとを規約とツールに逃がすほど、人間のレビューは本質に集中できます。

レビュイー側の心構え

レビューはレビュアーだけの仕事ではありません。出す側の準備で、レビューの質と速度は大きく変わります。

まず、自分で先にセルフレビューする。PRを出す前に自分の差分を上から読み、「ここ分かりにくいな」と思った箇所には自分でコメントを付けておく。// ここはパフォーマンスのため意図的にキャッシュしてます のような補足を残すだけで、レビュアーの往復が一回減ります。

次に、PR本文で文脈を渡す。何を・なぜ・どう確認したか。これがないと、レビュアーは差分から意図を逆算する羽目になります。

そして、指摘を人格攻撃と受け取らない。must: が10個付いても、それはあなたがダメなのではなく、コードにまだ伸びしろがあるだけです。逆に、納得できない指摘には議論していい。レビューは承認をもらう儀式ではなく、コードを良くする共同作業なので、レビュイーが「それは違うと思います、理由はこうです」と返すのは健全です。

レビューを溜めない運用

どれだけコメントが上手でも、3日放置されたPRは死にます。レビューが溜まる主因は、優先順位の中で「自分のコードを書くこと」がいつもレビューに勝つからです。

チームで効いたルールはシンプルでした。PRが来たら半日（営業時間4時間）以内に一次反応を返す。一次反応というのがミソで、全部読み切らなくていい。「今日中に見ます」「ここまで読みました、続きは午後」でもいい。沈黙が一番ダメなんですね。出した側は、反応がないと自分のPRが宙に浮いたまま次に進めません。

具体的には、こんな運用にしています。

• 朝イチと昼イチの2回、レビュー時間を15分ずつブロックする
• レビュー依頼はチャンネルに投げ、誰かが絵文字で「見ます」と宣言する（担当の二重化を防ぐ）
• 大きいレビューは「設計だけ先に」「細部は後で」と二段で返してよい
• 24時間動かないPRはデイリーで拾い、ペアで片付ける

レビューを溜めない一番の方法は、結局のところPRを小さくすることです。小さいPRは心理的なハードルが低く、「ちょっと見るか」と手が伸びます。ここでもサイズが効いてきます。

Claude Codeに一次レビューを任せる

ここまでの「人間がやるべきこと」を守るために、機械でできる一次レビューはClaude Codeに任せます。狙いは、人間が設計と業務判断に集中できる状態を作ることです。

Claude Codeには公式の code-review プラグインがあり、PRに対して /code-review:code-review で一次レビューを走らせられます。GitHub Actionsに組み込めば、PRが開かれた瞬間に自動で一次レビューが付きます。設定の詳細はClaude Code GitHub Actionsの公式ドキュメントを見てください。anthropics/claude-code-action@v1 を使った最小構成がこれです。

# .github/workflows/claude-review.yml
name: Claude first-pass review
on:
  pull_request:
    types: [opened, synchronize]

permissions:
  contents: read
  pull-requests: write

jobs:
  review:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
        with:
          fetch-depth: 0
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          plugin_marketplaces: "https://github.com/anthropics/claude-code.git"
          plugins: "code-review@claude-code-plugins"
          # 差分の範囲だけ見て一次レビューさせる
          prompt: "/code-review:code-review ${{ github.repository }}/pull/${{ github.event.pull_request.number }}"
          claude_args: "--max-turns 10"

設定したら、PRを開くだけです。Claude Codeが差分を読み、懸念点をコメントとして残します。secrets.ANTHROPIC_API_KEY にAPIキーを入れておくのを忘れずに。

大事なのは、Claude Codeを一次レビュー係に限定し、自動修正係にしないことです。黙って書き換えさせると、指摘の妥当性を人間が確かめる前に差分が増えます。順番は「Claudeが指摘 → 人間が取捨選択 → 合意した分だけ修正 → テスト」。Claudeのコメントにも人間と同じ接頭辞ルールを適用させると、must: と nit: が混ざらず、レビュイーが優先度を判断しやすくなります。

レビュー観点をプロジェクトに固定したいなら、CLAUDE.md（Claude Codeに渡すプロジェクトの作業メモ）にレビュー規則を書いておきます。粒度の決め方はCLAUDE.mdは「何を書かないか」で決まるに分けてあります。観点別の具体的なチェック項目は前述のチェックリスト記事へ。

人間とClaudeの役割分担はこう整理すると分かりやすいです。

見るもの	向いている担当
lint・型・テストの合否、差分サイズ	CI（機械）
機械的なバグ、規約違反、抜けたテスト観点	Claude Codeの一次レビュー
設計の妥当性、業務的に正しいか、命名の意図	人間のレビュアー

機械でわかることをClaudeとCIに任せた分、人間は「この分割でいいか」「この権限で本当に削除させていいか」に時間を使えます。これが、レビューを速くしつつ質を上げる現実的な落とし所でした。

よくある質問

Q. PRはどのくらいの大きさまでが適切ですか？ 変更400行・1テーマを目安にしています。それを超えると後半のレビューが雑になり、放置されやすくなります。生成コードや一括リネームのような機械的変更は例外として、PR本文にその旨を書いておけば大きくても通します。

Q. 「LGTM」だけの承認はダメですか？ 中身を読んだ上でなら問題ありません。危ないのは、読まずに「LGTM」を返すこと。これを防ぐ一番の方法はPRを小さくすることで、小さければ実際に全部読めるので、LGTMが本物の承認になります。

Q. 指摘が多すぎて相手を傷つけそうで怖いです。 must: nit: のような接頭辞で重要度を示すと、相手は「全部直さなきゃ」と思わなくなります。命令ではなく質問の形にし、主語を「あなた」ではなく「このコード」にするのも効きます。良かった点に praise: を付けるのも忘れずに。

Q. Claude Codeの指摘は信用していいですか？ 一次レビューとしては有用ですが、根拠のない指摘（差分にない問題）も混ざります。CLAUDE.md に「すべての指摘はファイルと行を示す」「不明なら断定せず質問する」と書くと精度が上がります。最終判断は人間が行う前提で使ってください。

Q. レビューが溜まって回りません。どうすれば？ 半日以内に「一次反応」だけ返す運用にしてください。全部読み切る必要はなく、「ここまで読んだ」でも沈黙よりずっといいです。朝と昼にレビュー時間を15分ブロックするだけでも滞留は大きく減ります。

実際に試した結果

冒頭の2,300行PRを承認して以来、僕がチームで変えたのはたった2つです。PRを400行で切ることと、コメントに接頭辞を付けること。技術的にはゼロ円、設定変更も要りません。それでもレビューの滞留時間は体感で半分以下になりました。小さいPRは「ちょっと見るか」と手が伸びるし、nit: が付いた指摘で消耗する人もいなくなったからです。

そのあとでClaude Codeの一次レビューをCIに足したのは、人間の時間を機械的な指摘から解放するためでした。型エラーや抜けたテスト観点はClaudeが先に拾ってくれるので、人間のコメントは「この設計でいい？」に寄っていきました。

レビューを良くしたいとき、僕らはつい「レビュアーがもっと頑張る」方向を考えます。でも効いたのは逆で、頑張らなくても回る進め方を作ることでした。PRを小さく、コメントに重要度を、機械でわかることは機械に。そのうえで人間は設計を議論する。次に試すなら、まずは自分の次のPRを400行以内に収めるところから始めてみてください。導入の段取りに迷ったら、レビュー運用チェックリストも一緒にどうぞ。

チームでの仕組み化や研修については研修・相談でも受け付けています。