コードレビューの観点チェックリスト：何を見て、AIと人でどう分担するか

「このPR、見ました。LGTMです」

そう書いて承認した30分後、本番でログインが通らなくなりました。差分はたった20行。僕はちゃんと読んだつもりでした。でも見ていたのは「コードがきれいか」だけで、「この変更で誰がログインできなくなるか」は一度も考えていなかったんです。

レビューが浅くなるのは、真面目さが足りないからじゃありません。何を見るかが決まっていないからです。観点が頭にないまま差分をスクロールすると、人は無意識に一番ラクな「読みやすさ」だけを見て、満足して閉じてしまう。僕がそうでした。

今日は、コードレビューで実際に何を見るのかを4つの観点で固定し、そのうちどこをAIに任せ、どこを人間が握るかを分けます。あわせて、レビューしやすいPRの出し方と、相手に刺さらない指摘の書き方まで。全部、僕が事故ってから身につけた型です。

この記事の要点

• レビューで見る観点は4つに固定する：正しさ・可読性・セキュリティ・テスト。順番もこの順で見る。
• AIと人で分担する。機械でわかること（型・lint・テスト・差分サイズ・命名のブレ）はAIとCIに、設計の妥当性・業務的に正しいか・半年後に読めるかは人間が握る。
• レビューしやすいPRは、レビューの9割を決める。1PR1テーマ・400行まで、目的と検証結果を本文に書く。
• 指摘は「直して」ではなく「なぜ気になるか」を書く。重要度を must / nit で示すと、相手が迷わない。
• AIには「まだ直すな、欠陥だけ先に出せ」と頼む。レビューと修正を混ぜると、どの指摘が重要だったか見えなくなる。

レビューで見る4観点を固定する

レビューを開いたら、毎回この順番で見ます。順番に意味があって、後ろの観点ほど「壊れたときの被害が大きい」わけではなく、前の観点ほど機械に任せやすい順に並べてあります。

観点	何を見るか	主な担当	見落とすと
1. 正しさ	仕様どおり動くか、境界値・null・例外を踏むか	AIで一次、人で最終	バグがそのまま本番へ
2. 可読性	命名・関数の長さ・重複・コメントの過不足	AI＋規約	半年後に誰も触れない
3. セキュリティ	認可・入力検証・秘密情報・ログ漏れ	人が主、AIで補助	漏洩・権限すり抜け
4. テスト	変更箇所にテストがあるか、何を確認していないか	人が主	次の変更で静かに壊れる

この4つを「上から順に」見るだけで、冒頭の僕の事故は防げました。あのとき僕は2番（可読性）だけ見て、1番（正しさ）と3番（セキュリティ）を飛ばしていた。順番を決めておくと、ラクな観点に逃げられなくなります。

正しさ：仕様と差分のズレを探す

一番大事で、一番サボられるのがここです。コードが動くことと、仕様どおり動くことは別物だからです。

具体的に見るのは、境界値（0件・1件・上限）、null や undefined の通り道、例外が起きたときの挙動、そして「この変更で前まで動いていた何かが壊れていないか」（リグレッション）。差分だけ見ると新しいコードに目が行きますが、消した行・変えた行が呼ばれていた場所こそ事故の温床です。

可読性：未来の自分が読めるか

可読性は「好み」になりやすく、レビューが荒れる原因No.1です。だから僕は、好みの話はレビューに持ち込まず、規約（lintルールやフォーマッタ）に寄せます。レビューで見るのはもっと構造的なこと。この命名で意図が伝わるか、関数が一画面に収まるか、同じロジックが3か所にコピペされていないか。インデントやクォートの種類で揉めるのは時間の無駄です。

セキュリティ：UIで隠しただけになっていないか

ここは人間が一番気合いを入れる観点です。よくある落とし穴は、管理者ボタンをUIで非表示にして満足すること。サーバー側の認可（そのユーザーがその操作をしていいかの判定）が無ければ、URLを直叩きされて終わりです。あわせて、入力検証、APIキーやトークンがコードやログに混ざっていないか、エラーメッセージで内部情報を漏らしていないかを見ます。

テスト：何を確認していないかを書かせる

テストは「あるか」より「何を確認していないか」を先に見ます。変更箇所にテストが無いなら、なぜ無いのかを聞く。あるなら、それが今回の変更の核心を突いているかを見る。テストが100行増えていても、肝心の分岐を踏んでいないことはよくあります。

AIレビューと人レビューの分担を決める

「Claude Codeにレビューさせれば人はいらない」——これは半分正解で半分危険です。AIは見落としを減らす補助としては優秀ですが、公開していいかの最終判断には向きません。線引きはシンプルで、「答えが一意に決まるか」で分けます。

AI＋CIに任せる（答えが一意）	人間が握る（答えが文脈次第）
型エラー・lint違反	設計の分割は妥当か
テストの成否・カバレッジ	この仕様は業務的に正しいか
差分サイズ・命名のブレ	半年後の自分が読めるか
よくあるバグパターンの一次検出	削除・課金・本番DBに触れる変更の可否
認可漏れの「候補」洗い出し	その認可漏れが本当に問題か

僕の運用はこうです。AIに一次レビューを投げて欠陥候補を全部出させ、人間はその候補のトリアージと、機械にわからない判断に時間を使う。 AIが「ここ認可チェックが無いかも」と挙げてきたら、人間が「そこは管理画面だから本当に問題」「ここは公開APIだから仕様どおり」と判断する。この分担にしてから、レビューの所要時間が体感で半分になりました。

Claude Codeでレビューを回す土台は公式のClaude Code overviewを、GitHub側の承認・差し戻しの状態はGitHub pull request reviewsを基準にすると、レビューの結果がチームで再現しやすくなります。

AIレビューを「仕組みとして」どう回すか、コメントの書き方やチーム文化まで含めた話は、別記事のコードレビューをClaude Codeに任せる運用と書き方に分けてあります。この記事は「何を見るか」の観点に集中します。

レビューしやすいPRの出し方

ここまで観点の話をしてきましたが、実はレビューの質を一番左右するのは、レビュアーの腕でも観点表でもありません。PRそのものの出し方です。2,300行の全部入りPRは、誰がどんな観点で見ても「LGTM」になります。人間の集中力は差分が大きくなるほど雑になるからです。

僕の目安はこうです。

差分の規模	レビューの現実	出し方
〜200行	全行ちゃんと読める	そのまま出す
200〜400行	集中すれば読める	1テーマに絞れているか確認
400〜800行	後半が雑になる	分割する。無理なら観点を絞って依頼
800行〜	ほぼ読まれない	必ず分割

サイズに加えて、PR本文に最低限これだけ書きます。目的（なぜこの変更か）・変更範囲・触っていない領域・実行した検証。AIが作った小さなPRほどこの説明が抜けがちで、差分が小さくてもレビュアーは不安でマージできません。小さいPRを「証拠付き」でレビュー可能にする具体的な型は小さなPRをレビュー可能にする証拠セットにまとめたので、PRを出す側はそちらが効きます。

コピペで使うレビュー前チェックと依頼文

観点を頭で覚えても、忙しい日に必ず飛ばします。だから僕は機械にやらせています。まず、レビューを頼む前に手元で走らせるコマンド。これはNode系の例なので、Railsなら bundle exec rspec、Goなら go test ./... に置き換えてください。

# レビュー依頼の前に、差分の範囲と検証結果を自分で確認する
git diff --stat            # 変更規模を見る（400行を超えたら分割を検討）
git diff --name-only       # 触ったファイルが目的と一致しているか
npm run lint               # 可読性の機械チェック（好みの揉めごとはここで解決）
npm run typecheck          # 型エラー = 正しさの一次防衛
npm run test               # テストが通るか

次に、Claude Codeなどに一次レビューを投げる依頼文。ポイントは「まだ直すな」「重要度順で」の2つです。これを入れないと、AIは前置きの長い感想を返したり、勝手にコードを書き換え始めたりします。

このdiffを「欠陥を探す」つもりでレビューして。

範囲:
- このPRで変更したファイルだけを見る
- まだコードは書き換えないで（指摘だけ出す）

優先度の高い順に:
1. 正しさ（境界値・null・例外・リグレッション）
2. セキュリティ（認可・入力検証・秘密情報・ログ漏れ）
3. テスト不足（変更の核心に対応するテストがあるか）
4. 可読性（命名・重複・長すぎる関数）

返し方:
- 指摘を must / nit で重要度を付けて、重要な順に
- 可能ならファイルと行番号
- なぜそれが利用者やデータに影響するか
- 次に僕が実行すべき確認コマンド
- ブロッカーが無くても「今回見ていない範囲」を最後に書く

「まだ書き換えないで」を入れるのは、レビューと修正を混ぜないためです。最初のパスでAIが直し始めると、どの指摘が本当に重要だったのかが埋もれます。指摘の中身に合意してから、別タスクとして修正を依頼する。この順番を守るだけで、レビューの議論が散らからなくなります。

指摘の伝え方：刺さらないコメントの型

観点どおりに欠陥を見つけても、伝え方を間違えるとレビューは険悪になります。僕も昔は「ここ、おかしくないですか？」と書いて、相手を黙らせていました。今は型を決めています。

悪いコメントは「ここが微妙です」で止まります。良いコメントは、どのファイルのどの変更が、誰のどんな行動に、どれくらい影響するかを書きます。

• 悪い: 「この関数、長くないですか」
• 良い: 「nit: この関数が80行あって分岐が深いので、半年後に触るとき怖いです。バリデーション部分を切り出すと読みやすそう。今回は必須じゃないです」

ポイントは3つ。ひとつ、重要度を接頭辞で示す。must（直さないとマージしない）、nit（好みレベル、直さなくてもいい）。これがあると、相手は全部の指摘に同じ重さで身構えなくて済みます。ふたつ、命令ではなく提案や質問の形にする。「直して」より「〜すると読みやすそう」「ここはこういう意図ですか？」。みっつ、人ではなくコードを主語にする。「あなたのミス」ではなく「このコードはこの入力で落ちます」。

重要度は実務ではもう少し細かく分けても運用しやすいです。漏洩・データ破壊・決済不能は即対応（最優先）、主要導線や認証の不具合は高、読みにくさや限定条件での崩れは中、表記ゆれは低。AIに頼むときも「最優先と高だけ先に出して」と言うと、長い指摘リストに埋もれません。

レビューの最後に「見ていないもの」を書く

良いレビューほど、最後に今回見ていない範囲を書きます。これが無いレビューは、相手に過剰な安心を与えるからです。

たとえば「型は通したが本番URLは見ていない」「ロジックは追ったがスマホ表示は確認していない」「認可は見たが負荷は見ていない」。未確認項目がはっきりしていれば、次のレビュー担当や人間がそこから引き継げます。このリストが短くなるほど、公開判断は速くなる。レビューは指摘を増やす作業ではなく、迷いを減らす作業なんですね。

よくある質問

Q. AIレビューがあれば人間のレビューは要らない？ 要りません、とは言えません。AIは型エラーやよくあるバグパターン、認可漏れの「候補」までは得意ですが、その候補が本当に問題か、設計の分割が妥当か、業務的に正しいかは文脈次第です。AIを一次フィルタ、人間を最終判断に置く分担が現実的です。

Q. 4観点を毎回全部見る時間がない。 全部を同じ深さで見る必要はありません。差分の内容で重み付けします。認証・課金・本番DBに触るならセキュリティと正しさに全力、文言修正なら可読性とリンク切れだけ、で十分です。やってはいけないのは「観点を決めずに眺める」ことだけです。

Q. 大きいPRが来て分割を頼みづらい。 分割が無理なら、レビュー範囲を観点で絞ります。「今回は正しさとセキュリティだけ見る、可読性は別途」と宣言して、見た範囲と見ていない範囲を明記する。全部を雑に見て「LGTM」と書くより、半分を本気で見るほうが事故は減ります。

Q. 指摘が多すぎて相手が萎える。 must と nit で分けて、nit は「直さなくていい」と明言します。それでも多いなら、最優先と高だけコメントして、残りは「細かいのは別途まとめます」と一言添える。一度のレビューで全部直させようとしないことです。

Q. レビューが溜まって滞留する。 来たら半日以内に「一次反応」だけ返す運用にします。全部読めなくても「ここだけ気になる、続きは午後」で滞留は消えます。完璧な一発レビューより、速い往復のほうがチームは回ります。

実際に試した結果

冒頭の「LGTMで本番ログインを壊した」事故のあと、僕はレビューのやり方を変えました。差分をスクロールする前に、正しさ・可読性・セキュリティ・テストの4つを上から順に見ると決めただけです。これで「ラクな可読性だけ見て満足する」癖が消えました。

さらにAIに一次レビューを投げて欠陥候補を出させ、人間はそのトリアージと機械にわからない判断に集中する分担にしたら、レビュー時間が体感で半分になりました。指摘は must / nit で重要度を付け、「なぜ気になるか」を書く。レビューの最後に「今回見ていない範囲」を必ず残す。地味ですが、この型にしてからレビュー起因の本番事故はゼロです。

レビューを単発の感想で終わらせず、チームの運用とコメント文化まで仕組みにしたい人はコードレビューをClaude Codeに任せる運用と書き方へ。レビューしやすいPRを出す側の型は小さなPRをレビュー可能にする証拠セットが近いです。チームのリポジトリに合わせて観点とレビューゲートを設計するなら、研修・相談から声をかけてください。