この記事は「コードレビューに関するTipsを投稿しよう！ by CodeRabbit Advent Calendar 2025」向けの投稿です。
コードレビューは「バグを見つける場」でもありますが、本質は チームの認知負荷を下げながら、変更の安全性を上げる仕組み だと考えています。
そしてAI駆動開発が当たり前になった今、レビューはさらに重要になりました。なぜなら「書く速度」が上がった分、「混入するリスク」も増えやすいからです（AI生成PRの課題が増える可能性を示す報告もあります）。
本稿では、レビューを“頑張り”で回すのではなく、設計して回すための実践をまとめます。
そのまま使える PRテンプレ・レビュー観点チェックリスト・コメント文例 も付けています。
目次
- 1. コードレビューを「成果が出る形」にする3つのゴール
- 2. まず直すべきは“レビューの入口”：レビュー可能なPRの作り方
- 3. レビュアーの動き方：2パス＋優先順位付け
- 4. 観点チェックリスト：AI時代に特に落ちやすい穴
- 5. コメントの書き方：摩擦を減らし、品質を上げる型
- 6. AI（例：CodeRabbit）と併走する：人間が見るべき場所を守る
- 7. チーム運用：レビューを文化でなく仕組みにする
1. コードレビューを「成果が出る形」にする3つのゴール
レビューの目的が曖昧だと、指摘が散り、疲れ、遅れます。 まずゴールを3つに固定すると運用が安定します。
-
安全性（事故を防ぐ）
仕様逸脱・脆弱性・運用事故・データ破壊の芽を早期に摘む -
可読性（将来のコストを下げる）
“今の正しさ”だけでなく、“次の変更のしやすさ”を守る -
共有（チームの学習速度を上げる）
設計意図・判断基準・暗黙知をPRに残す（属人化を減らす）
以降のTipsはすべて、この3つに収束させます。
2.まず直すべきは“レビューの入口”：レビュー可能なPRの作り方
レビューが詰まる最大原因は「レビューが難しいPR」です。
レビュアーの能力ではなく、入力（PR）を整えるだけで改善します。
2-1. PRは「最小の変更単位」にする（“差分の物語”を1本に）
- 目的が1つである（混ぜない）
- リファクタと仕様変更は分ける（混ぜると意図が読めません）
- “ついで”の修正は基本入れない（入れるなら理由を書く）
小ささの目安を数値で縛るより、「ひと目で追えるか」 を基準にする方がチームに馴染みます。
2-2. PR本文は「レビュアーの認知負荷」を減らす設計図
PR本文が薄いと、レビュアーは差分から意図を推理します（これが時間を溶かします）。
次のテンプレを使うと、レビューが速くなり、指摘の質も上がります。
✅ PRテンプレ
## 背景 / 目的
- なぜこの変更が必要か（仕様・不具合・運用課題など）
- 関連Issue / チケット（任意）
## 変更内容（What）
- 何を変えたか（箇条書きで3〜7個程度）
- 影響範囲（画面 / API / DB / バッチ / 権限 など）
## 設計の要点（Why / How）
- 判断に迷いそうな点だけ説明
- 代替案と、採用しなかった理由（あれば）
## リスクと対策
- 壊れやすい点（境界条件、互換性、データ移行、権限など）
- ロールバック方法（可能なら）
## テスト
- 実施したテスト（手動 / 自動）
- 追加したテストケース（観点）
## スクリーンショット / ログ（任意）
2-3. セルフレビューのチェックリスト（“レビュー前に落とせるバグ”は先に落とす）
- 仕様を自分の言葉で説明できるか
- 境界条件（null / 空 / 上限 / 権限 / 並行）を通したか
- ログ・エラーメッセージは運用で役立つか
- 例外系で「壊れ方」が安全か（フェイルセーフ）
- 既存の設計規約（命名・層・依存方向）に沿っているか
3. レビュアーの動き方：2パス＋優先順位付け
レビューが遅くなるのは、細部に潜る前に全体像を掴めていないことが多いです。
おすすめは「2パス方式」です。
パス1：意図と安全性（全体 → 危険箇所の特定）
- 目的と変更点はPR本文と一致しているか
- 影響範囲に漏れがないか（呼び出し元、権限、データ）
- 事故ると痛いところ（決済、権限、データ更新、外部I/O）を特定
パス2：詳細（危険箇所 → 実装の検証）
- 境界条件、例外、並行、タイムアウト、再試行
- テストの観点が“壊れ方”をカバーしているか
- 可読性：命名、責務分割、重複、依存関係
4. 観点チェックリスト：AI時代に特に落ちやすい穴
AI生成コードは見た目が整っていても、 「文脈（仕様・社内ルール・運用前提）」 が抜けることがあります。
レビュー観点を固定しておくと、品質がブレにくくなります。
✅ レビュー観点カード（優先順位つき）
| 優先 | 観点 | 具体的に見るところ | ありがちな落とし穴 |
|---|---|---|---|
| 1 | 正しさ / 仕様 | ドメインルール、計算、状態遷移 | 仕様の取り違え、条件分岐の抜け |
| 1 | 安全性 | 権限、入力検証、秘匿情報、監査 | 認可漏れ、ログに秘密が出る |
| 2 | データ整合性 | 競合、トランザクション、再実行 | 二重更新、部分失敗で壊れる |
| 2 | 運用性 | ログ、メトリクス、エラー文言 | 障害時に原因が追えない |
| 3 | 性能 | N+1、ループ内I/O、キャッシュ | 小規模では見えない劣化 |
| 3 | 保守性 | 責務、命名、重複、依存方向 | “とりあえず動く”が増殖 |
| 4 | スタイル | lint/format | ここで止めない（自動化へ） |
「スタイル指摘で止めない」だけで、レビューの滞留が目に見えて減ります。スタイルは自動化し、レビューは“意味”に集中させます。
5. コメントの書き方：摩擦を減らし、品質を上げる型
レビューが辛いのは、指摘が“正しい”かどうか以前に、伝わり方で損をするからです。
コメントは「型」を決めると、心理的安全性と品質が両立します。
5-1. コメントの型：SBI＋提案（事実→影響→提案）
- S（Situation）：どの行・どのケースの話か
- B（Behavior）：いまの挙動・実装の事実
- I（Impact）：何が困るか（バグ/運用/保守/性能）
- Suggestion：どう直すか（選択肢があるなら複数）
良い例
この処理は userId が null のときに例外になります（事実）。
本番で null が入り得るので、500になって問い合わせが増える可能性があります（影響）。
userId の存在チェックを入れるか、API契約として必須にするならバリデーションで明示するのはいかがでしょう（提案）。
もったいない例
nullチェックしてください。
5-2. “温度”を揃える：ラベル運用
指摘が増えるほど「どれが必須？」が不明確になりがちです。
そこで、コメントの先頭にラベルを付けます。
- [must]：マージ前に必ず直す（事故る/壊れる/契約違反）
- [should]：今回直すのが望ましい（保守性や運用性）
- [nit]：好みや軽微（自動化候補）
- [q]：確認質問（仕様・前提）
6. AI（例：CodeRabbit）と併走する：人間が見るべき場所を守る
このAdvent Calendarの紹介文でも、CodeRabbitはGitHub/GitLabと連携してPRを自動レビューし、オープンソースでは無料で利用できる旨が案内されています。
また公式サイトやドキュメントでも、PRレビュー支援やGitHub連携の情報が提供されています。
ここで大事なのは「AIに任せる」ではなく、AIに任せる領域を設計することです。
6-1. AIに任せると強い領域（機械的・網羅的）
- 差分要約、影響ファイルの列挙
- 命名の一貫性、未使用変数、例外処理漏れの候補出し
- テスト追加候補の提案（不足観点の洗い出し）
6-2. 人間が必ず握る領域（文脈・責任）
- 仕様とドメインルールの正しさ
- 変更の優先順位（今やるべきか／スコープは適切か）
- 運用・ロールバック・監査・責任境界
- “チームの設計規約”への適合（依存方向や境界）
6-3. AIレビューを強くする「PR本文の書き方」
AIが弱いのは“暗黙の前提”です。PR本文に以下を足すだけで、AIも人もレビュー精度が上がります。
- 不変条件（Invariant）：絶対に守るルール（例：権限、状態遷移）
- 失敗時の期待挙動：例外・タイムアウト時にどうなるべきか
- 互換性要件：既存API/DB/クライアントとの互換
- 運用前提：ログ、監査、アラート、再実行
7. チーム運用：レビューを“文化”でなく“仕組み”にする
7-1. レビューSLAを合意する
- 「いつまでに見るか」をチームで合意（例：当日中、翌営業日など）
- 緊急度ラベル（hotfix / release blocking）を用意
7-2. レビュアーを疲弊させない
- レビュー当番（ローテーション）
- 大きいPRは“事前設計レビュー”に分割（差分レビューだけにしない）
- 迷ったら「質問」に落とす（断定で殴らない）
7-3. メトリクスは“責めるため”ではなく“詰まりを見つけるため”
- レビュー待ち時間（PRが止まっている時間）
- 差し戻し回数（仕様の曖昧さが原因ならテンプレ改善）
- リリース後の不具合種別（レビュー観点の更新材料）
付録A：レビュアー用・最短チェックリスト（コピペ）
- PR本文で目的・影響範囲・テストが説明されている
- 仕様 / ドメインルールに照らして正しい
- 権限・入力検証・秘匿情報の扱いが安全
- 失敗時（例外/タイムアウト/部分失敗）が安全
- データ整合性（競合/再実行/トランザクション）が守られる
- 運用できる（ログ/監査/調査可能性）
- テストが「壊れ方」をカバーしている
- 保守性（責務/命名/依存方向）がチーム規約に沿う
付録B：コメント文例集（そのまま使えます）
[must] 仕様・正しさ
[must] ここは仕様上「〜の場合は〜」になる認識でしたが、現状だと X のときに Y になりそうです。仕様の根拠（チケット/ドキュメント）があれば合わせて確認したいです。修正方針としては A or B が考えられますが、どちらが意図に近いでしょうか？
[should] 運用性
[should] 障害時に原因特定しやすいよう、ここでエラー理由（入力値の要点や外部応答コードなど）がログに残ると助かります。秘匿情報はマスクした上で、調査に必要な最小限だけ出す形はいかがでしょう。
[q] 前提確認
[q] この処理は「再実行されない」前提でしょうか？もし再実行があり得るなら、冪等性（idempotency）をどう担保するかを確認したいです。
おわりに
コードレビューは、誰かの努力ではなく 設計で強くできます。
- PRの入口を整える
- 2パスで優先順位を付ける
- 観点チェックリストを固定する
- コメントは型で摩擦を減らす
- AIは“機械領域”に寄せ、人間は“文脈と責任”を握る
この5点だけでも、レビューの速度と品質が同時に上がり始めます。