コードレビューとは

コードレビューとは、ある人が書いたコードの変更を、別の人が読んで確かめる作業のことです。読み方は「こーどれびゅー」、英語では code review と書きます。目的は、不具合を見つけることに加えて、読みやすさや設計の一貫性を保ち、チームの中で知識を共有することにあります。

判断の目安としてよく引かれるのが、Googleが公開しているThe Standard of Code Review（Google Engineering Practices）です。そこでは、変更が完璧でなくても、システム全体のコードの健全さを確実に良くする状態になっていれば、レビュアーは承認に傾けるべきだとしています。「完璧なコードはなく、より良いコードがあるだけ」という考え方です。

同じ文書は、技術的な事実とデータが、意見や個人の好みより優先されるとも述べています。好みの違いで差し戻すのではなく、根拠を示して話し合うのが基本です。

多くの現場では、プルリクエストの画面でレビューを行います。流れはおおむね次のとおりです。

• 書いた人が変更をまとめ、何のための変更かを説明文に書いて依頼する
• レビュアーが差分を読み、気になる行にコメントを付ける
• 書いた人が修正するか、そうした理由を返信する
• 問題がなくなったらレビュアーが承認し、取り込む

待ち時間も品質に関わります。Speed of Code Reviews（Google Engineering Practices）は、レビュー依頼への応答は長くても1営業日以内、つまり遅くとも翌朝一番が目安だとしています。返事が遅いとチーム全体の進みが落ち、急かされて質の低い変更が通りやすくなる、というのがその理由です。

What to look for in a code review（Google Engineering Practices）は、レビュアーが確かめる項目を次のように挙げています。

• 設計：変更の各部分のつながりが筋の通ったものになっているか
• 機能：書いた人の意図どおりに動くか。境界の値や並行処理の問題はないか
• 複雑さ：必要以上に複雑になっていないか。今は要らない汎用化をしていないか
• テスト：適切な単位のテストがあり、そのテスト自体が正しいか
• 名前・コメント・スタイル：名前が分かりやすいか、コメントが「何を」より「なぜ」を説明しているか、規約に沿っているか
• ドキュメント：使い方や手順が変わるなら、説明書きも更新されているか

加えて、割り当てられた行はすべて読むこと、変更をシステム全体の中で眺めること、良い点も伝えることが勧められています。

AIコーディングエージェントの出力は文法的に整っていることが多く、ざっと眺めるだけでは問題が見えにくくなります。上の観点に、次の確認を足すと漏れが減ります。

• 頼んだ範囲だけが変わっているか：git diff --stat で変更されたファイルの一覧を見て、依頼と関係のないファイルが混ざっていないかを先に確かめます。
• 存在する関数やライブラリを使っているか：もっともらしい名前の、実在しない関数やオプションが書かれることがあります。公式ドキュメントで確かめます。
• テストを弱めていないか：テストが通らないとき、実装ではなくテストの期待値の側を書き換えてしまう例があります。テストファイルの差分は特に注意して読みます。
• 鍵や個人情報が入っていないか：動作確認のために書いた値が、そのまま残っていないかを見ます。

逆に、AIをレビュアーとして使う方法もあります。その場合は「セキュリティの観点で」「境界値の扱いだけ」のように見る観点を絞って頼むと、指摘がぼやけにくくなります。依頼文の例はAIへのレビュー依頼文例集：観点指定で精度を上げるにまとめています。

• 誤解：レビューはバグ探しだけ → 実際：読みやすさ、設計、テストの妥当性も対象です。知識をチームに広げる役割もあります。
• 誤解：承認されたら不具合はない → 実際：承認は、読んだ範囲で問題が見つからなかったという判断です。動作の確認は自動テストや回帰テストと組み合わせて行います。
• 誤解：完璧になるまで承認してはいけない → 実際：全体の健全さを確実に良くするなら承認に傾ける、というのが前述の指針の立場です。細かな磨き込みは任意の指摘として伝えます。
• 誤解：AIがレビューすれば人は読まなくてよい → 実際：AIの指摘にも誤りや見落としがあります。取り込むかどうかの最終判断は人が持ちます。

• 変更を小さくする：Small CLs（Google Engineering Practices）は、100行ほどならたいてい妥当、1000行はたいてい大きすぎるとしています。ただし最終的にはレビュアーの判断で、同じ200行でも50ファイルに散っていれば大きすぎることが多い、とも書かれています。
• 任意の指摘には印を付ける：直さなくても承認できる細かな点は、先頭に Nit: と付けて伝えると、必須の指摘と区別できます。
• 根拠を添えて書く：「好みではない」ではなく、規約やドキュメント、再現手順を示します。
• 受け入れ条件と照らし合わせる：何ができれば完了かが受け入れ基準として決まっていれば、機能の確認がぶれません。

• 回帰テスト
• 受け入れ基準
• 技術的負債
• プロンプトインジェクション
• プルリクエスト
• CI/CD

• AIへのレビュー依頼文例集：観点指定で精度を上げる
• AIが書いたコードのテストとレビュー：鵜呑みにしないための基本動作
• AIが生成したコードのセキュリティ確認：最低限のチェックリスト

• The Standard of Code Review（Google Engineering Practices）
• What to look for in a code review（Google Engineering Practices）
• Speed of Code Reviews（Google Engineering Practices）
• Small CLs（Google Engineering Practices）

Q1. コードレビューとは何ですか？
書かれたコードの変更を、書いた本人以外が読んで確かめる作業です。不具合を見つけるだけでなく、読みやすさや設計の一貫性を保ち、チームで知識を共有する目的もあります。多くの場合、プルリクエストの画面で行います。

Q2. どんな状態なら承認してよいのですか？
Googleの公開している指針では、完璧でなくても、システム全体のコードの健全さを確実に良くする状態であれば承認に傾けるべきだとしています。細かな改善点は、直さなくてもよい指摘として分けて伝えます。

Q3. レビューでは何を見ればよいですか？
設計、意図どおりに動くか、必要以上に複雑でないか、テストがあり正しいか、名前やコメントが分かりやすいか、説明書きが更新されているか、が主な観点です。AIが書いたコードでは、頼んだ範囲以外の変更が混ざっていないかも確かめます。

Q4. 1回のレビューで見る量はどのくらいが目安ですか？
Googleの指針では、100行ほどならたいてい妥当で、1000行はたいてい大きすぎるとしています。行数だけでなく、変更が何ファイルに散っているかも読みやすさに影響します。

Q5. AIにレビューを任せてもよいですか？
観点を絞った補助としては役立ちますが、AIの指摘にも誤りや見落としがあります。指摘を参考にしつつ、取り込むかどうかの判断は人が差分を読んで行います。