コードレビューの観点チェックリスト｜優先順位と伝え方

コードレビューで最初に確認すべきなのは、「仕様どおりに正しく動くか」と「安全か」です。変数名やインデントなどの見た目は、フォーマッターや静的解析ツールに任せ、人はツールでは判断できない観点に時間を使うのが、効果的なレビューの基本です。

レビューの観点を並べたチェックリストは多くありますが、実務で困るのは「全部見きれない」ことです。この記事では、観点を優先順位つきで整理し、各観点で具体的に何を見ればよいかを示します。あわせて、指摘の伝え方、レビューしやすいプルリクエストの作り方、AIが書いたコードで特に確認したい点まで解説します。

観点の優先順位

時間が限られているときほど、上から順に見るのがポイントです。読みやすさの指摘に時間を使い、境界値の不具合を見落とすのは、レビューで最も避けたいパターンです。

観点別チェックリスト

1. 仕様どおりに動くか（正しさ）

• □ チケットや仕様書の要件を、すべて満たしているか
• □ 仕様にない処理が追加されていないか
• □ 条件分岐の条件は正しいか（< と <=、&& と ||、否定の向き）
• □ 画面やAPIの動作を、実際に確認したか（必要なら手元で動かす）

差分だけでなく、変更されていない呼び出し元・呼び出し先も確認すると、影響の見落としを防げます。

2. セキュリティ

• □ 利用者の入力を、SQL・HTML・コマンドにそのまま埋め込んでいないか（SQLインジェクション・XSS・コマンドインジェクション）
• □ 権限のチェックがあるか。他人のIDを指定したとき、他人のデータが見えないか
• □ パスワード・APIキー・トークンをコードに直接書いていないか
• □ ログやエラーメッセージに、個人情報や秘密情報が出ていないか
• □ 新しく追加したライブラリは、実在し、信頼できるものか

「ログインしているか」だけでなく、「そのデータを見てよい人か」の確認漏れは、自動テストでも見つかりにくい代表的な脆弱性です。

3. エラー処理・境界値

• □ null・空文字・空のリスト・0件のときに正しく動くか
• □ 最小値・最大値・ちょうど境界の値（0、1、上限、上限+1）で正しく動くか
• □ 例外を握りつぶしていないか（catchして何もしない、ログだけで処理を続ける）
• □ 外部APIやDBが失敗・タイムアウトしたときの動きは決まっているか
• □ 日付の境界（月末・年末・うるう年・タイムゾーン）を考慮しているか

4. データの整合性・同時実行

• □ 複数の更新が、1つのトランザクションにまとまっているか
• □ 同時に2人が操作したときに、データが上書きされたり重複したりしないか
• □ リトライや二重送信で、登録や決済が重複しないか（冪等性）
• □ 途中で失敗したとき、中途半端な状態が残らないか

5. 性能

• □ ループの中でDBやAPIを呼んでいないか（N+1問題）
• □ 検索条件の列にインデックスがあるか
• □ 件数が増えたときに、全件をメモリに読み込んでいないか
• □ 不要な処理が、繰り返し実行されていないか

開発環境のデータは少ないため、性能の問題は動作確認では見つかりにくい観点です。「本番のデータ量で、この処理は何回・何件になるか」を想像しながら見ます。

6. テスト

• □ 変更した振る舞いに対するテストがあるか
• □ 正常系だけでなく、異常系・境界値のテストがあるか
• □ テストが実装の中身ではなく、振る舞いを検証しているか
• □ テストが日時・乱数・実行順に依存して、不安定になっていないか

7. 互換性・リリース

• □ APIの項目の削除や型の変更など、既存の利用者に影響する変更がないか
• □ DBのマイグレーションは、既存のデータで問題なく実行できるか。大きなテーブルで長時間ロックしないか
• □ 設定値や環境変数の追加が、リリース手順に反映されているか
• □ 問題があったときに元に戻せるか

8. 設計・読みやすさ

• □ 1つのメソッド・クラスが、複数の責任を持ちすぎていないか
• □ 名前から、何をするものかがわかるか
• □ 同じ処理が重複していないか。既存の共通処理を使えないか
• □ コメントは「なぜ」を説明しているか（「何を」はコードでわかるようにする）
• □ 将来の変更を見越しすぎた、使われない仕組みを作っていないか

ツールに任せる範囲

ツールで検出できることを、人がレビューで指摘しない仕組みにすると、レビューの時間を重要な観点に集中できます。書式の指摘は、指摘する側・される側のどちらにとっても負担が大きい割に、得られるものが少ないためです。

指摘の伝え方

指摘の重要度を、ラベルで伝える

コメントの先頭に、対応が必須かどうかを示すラベルを付けると、やりとりがスムーズになります。

英語圏では、同じ目的で「Conventional Comments」という書式（praise・nitpick・suggestion・issue・question など）も使われています。チームで使うラベルを決めておくことが大切です。

伝わるコメントの書き方

• 理由を添える — 「修正してください」ではなく、「〜の場合に〜になるため」
• 具体的な案を示す — 可能なら、修正案のコードを添える
• 人ではなく、コードについて書く — 「あなたの書き方は」ではなく「この処理は」
• 質問の形を使う — 意図がわからないときは、決めつけずに「〜の意図でしょうか？」
• よかった点も伝える — よい書き方はチームに広がり、次の実装の参考になる

完璧を求めすぎない

Googleが公開しているコードレビューのガイドラインでは、「そのプルリクエストが、コードベース全体の状態を確実に良くするなら、完璧でなくても承認してよい」という考え方が示されています。好みの問題で差し戻しを繰り返すより、重要な指摘に絞り、細かな点は[nit]として伝える方が、チーム全体の開発は速くなります。

レビューしやすいプルリクエストの作り方

レビューの質は、レビューされる側の準備でも大きく変わります。

小さく分ける

一度に読む量が多いほど、レビューの精度は下がります。変更は数百行までを目安に、目的ごとにプルリクエストを分けます。

• リファクタリングと機能追加は、別のプルリクエストにする
• 大きな機能は、「DBの変更」「APIの追加」「画面」のように段階に分ける
• 自動生成されたファイルや、機械的な置換は、別のコミットに分けてその旨を書く

説明を書く

• 何のための変更か（チケットへのリンク）
• どう変えたか、なぜその方法を選んだか
• どう確認したか（テスト、画面のスクリーンショット）
• 特に見てほしい点・不安な点

レビュー依頼前のセルフチェック

• □ 自分で差分を最初から最後まで読み直したか
• □ デバッグ用のコード・コメントアウト・不要なファイルが残っていないか
• □ テストとCIは通っているか
• □ プルリクエストの説明に、確認方法を書いたか

自分で読み直すだけで見つかる指摘を減らしておくと、レビュアーは本質的な観点に集中できます。

レビューは早めに返す

レビュー待ちの時間が長いと、作成者は別の作業に移り、戻ってきたときに内容を思い出す手間がかかります。Googleのガイドラインでは、遅くとも1営業日以内に最初の反応を返すことが推奨されています。すぐに全部を見られない場合も、「今日の午後に見ます」と一言返すだけで、作成者は予定を立てやすくなります。

AIが書いたコードのレビューで、特に確認したい点

AIのコーディング支援で書かれたコードは、文法的には整っていて、一見正しく見えることが特徴です。そのため、次の点を意識して確認します。

特にテストには注意が必要です。AIが実装とテストを両方書いた場合、テストは「実装がしている動作」を確認するだけになりがちです。テストの期待値が、実装ではなく仕様から導かれているかを確認します。

また、AIが書いたコードでも、プルリクエストを出した人が内容を説明できることが前提です。レビュアーは「この部分はどういう意図ですか？」と質問し、作成者が理解しているかを確認するのも有効です。

よくある質問

Q. レビューにどれくらい時間をかけるべきですか？ A. 変更の大きさとリスクによりますが、1回のレビューで長時間続けると集中力が落ちます。大きな変更は、プルリクエストを分けてもらうか、時間を区切って複数回に分けて見るのがおすすめです。

Q. 経験の浅いメンバーは、何から見ればいいですか？ A. まずは「自分で動かして、仕様どおりか確認する」「わからない部分を質問する」から始めるのがおすすめです。質問はレビューの立派な貢献で、作成者にとっても説明を見直すきっかけになります。

Q. 指摘がたくさんある場合、全部コメントすべきですか？ A. 同じ種類の指摘が多い場合は、1か所に代表してコメントし、「他の箇所も同様です」と伝えます。設計から見直す必要がある場合は、細かな指摘を書く前に、直接話して方針をすり合わせる方が効率的です。

Q. レビュアーが見落とした不具合は、レビュアーの責任ですか？ A. レビューは不具合をゼロにする仕組みではなく、品質を高めるための共同作業です。見落としがあった場合は、チェックリストやテスト、ツールを改善するきっかけとして振り返るのが建設的です。

まとめ

• 観点は正しさ・セキュリティ → エラー処理・整合性・性能 → テスト・互換性 → 読みやすさの順に優先する
• 書式や単純な誤りはツールに任せ、人はツールで判断できない観点に集中する
• 指摘には [MUST]・[IMO]・[nit]・[Q] などのラベルと理由を添え、よかった点も伝える
• プルリクエストは小さく分け、説明と確認方法を書き、セルフチェックしてから依頼する
• AIが書いたコードは、仕様との一致・存在しないAPI・例外の握りつぶし・テストの妥当性を特に確認する

株式会社RJCでは、コードレビューを「間違いを探す場」ではなく、仲間と一緒に成長する場だと考えています。こうした知識を共有しながら、チームで開発を楽しんでいます。

株式会社RJC ― SI事業・SES事業・AI駆動開発。未経験からエンジニアに育てるのが得意な会社です。