概要
コードレビューとは、変更をマージする前に作成者以外の視点で確認し、その確認結果をもとに、その変更をコードベースの一部として取り込んでよいかを判断する実践です。 このページでは、レビューが組織にもたらす価値から始め、レビュアーが実際に何を確認するのかを見た上で、そのチェック作業をツールがどう肩代わりしてきたかを扱い、最後に自分の変更を先にレビューする・対応しやすいコメントを書くという2つの実践的な習慣で締めくくります。プルリクエスト自体の粒度・テンプレート・タイトルやコミットの規約、そして依頼からマージまでの基本的な流れはすでに整っている前提です。それらはプルリクエストを、変更を検証可能にする土台はテストコードを参照してください。レビューが組織にもたらす価値
出荷前に欠陥を見つけることはレビューを行うわかりやすい理由であり、それ自体は本当のことです。ただし、そこで止まってしまうと、レビューが持つ価値の大部分を取りこぼします。知識の共有
変更を確認する過程で、作成者以外の誰かがその変更を理解せざるを得なくなります。なぜその変更が存在し、どう動くのかという知識が、一人の頭の中だけにとどまることはありません。
規約の育成
規約は、レビューでの「うちではこうしない」という一度きりの指摘から始まります。十分な数のレビューで繰り返されることで、次の作成者がすでに知っているルールになります。チームの共通の基準は、レビュー1回ごとに育っていきます。
非機能要求の確認
レスポンスタイム・セキュリティ上の露出・コード外のルールへの準拠は、失敗するテストとして表面化することがほとんどありません。それらを尋ねるチェックポイントは、レビューだけであることが多くあります。
品質向上
すでに動いている変更も、さらに良いものへとレビューできます。レビュアーがより良いやり方を提案すれば、「動くかどうか」の基準を守るだけでなく、その基準自体を引き上げます。
レビューで確認する観点
機能要件は、Issueの受入基準やチケットの説明として明示されていることがほとんどなので、確認作業は主に、コンパイルが通るかではなく実際に依頼された内容と差分を照らし合わせる作業になります。
非機能要件は見落としやすい観点です。遅いクエリはビルドを失敗させませんし、コンプライアンス上の欠落も例外を投げないため、わざわざ声を上げてくれないからです。
設計の適合・テストスイート・可読性は、確認作業の残りを支えます。設計の適合はその要件が追加される先のコードベースを守り、テストスイートは次にこのコードに触れる人を守り、可読性は変更を保守し続けるコストという、マージ後しばらく経つまで表に出てこないコストを隠したままにしません。
ツールがレビューの機械的なチェックを肩代わりしてきた歴史
かつては、上表のすべての観点が人間によって確認されており、レビューとはそれらすべてを目視で見つけることを意味していました。 レビューが長引く要因はいくつかありますが、そのうち最も本質的でないのが、機械がすでに作成者へ伝えられたはずのことを人間が改めて洗い出しているケースです。 lint違反・テストの不足・スタイルガイドですでに決着している命名の不一致などがその典型です。さらに悪いことに、簡単な項目と難しい項目を一緒に洗い出すとレビュアーの注意が分散し、本来判断が必要な項目こそ見落とされやすくなります。 linterやフォーマッタは、まさにこの問題への標準的な解決策として登場しました。命名・フォーマット・そして年々増えていく既知のバグパターンを、人間のレビュアーが差分を開くより前に自動でチェックします。これが現代の多くのチームが前提としている土台です。 セミコロンの付け忘れや命名の不一致を捕まえるためにレビュアーの時間が使われることは、もうありません。すでにツールがそれをやっているからです。 AIはこの発想をさらに一歩進めます。linterが固定的で一般的なルールとしか照合できないのに対し、AIによるチェックはチーム独自のコーディング規約や文脈とも照合できます。これは、以前はそのコードベースをすでに知っている人にしかできなかった種類の判断です。機械的にチェックする
正解がルール、あるいはチーム独自の規約で決まるもの。
- 命名・コーディング規約への準拠
- 変更行のテストカバレッジ
- 固定のルールセットと照合できる既知のバグ・脆弱性パターン
人間のレビュアーが担う
正解が文脈に依存する判断。
- 設計・アーキテクチャが周辺システムになじんでいるか
- 変更が実際に要件を満たしているか
- セキュリティリスクの受容とマージの最終判断
ファインディでは、この機械的なチェックをAIによるセルフレビューに任せ、プルリクエストを作成する前に実行しています。大事なのはルールで判定できる部分と人間の判断が必要な部分を分けておくことです。この考え方がAI生成コード全般にどう当てはまるかは、Agentic Workflowを参照してください。
自分の変更を先にレビューする
レビュアーに依頼する前に、初めて見るつもりで差分を読みます。距離を置くと見え方が変わります。書いているときには見えなかった間違いも、他人として変更を見直すと気づけるようになり、ここで見つけたものはすべて、他人の注意力を借りる往復ではなく、その場での修正で済みます。 差分を、自分が書いた順ではなくレビュアーが見る順、つまり上から下へファイルごとに、途中で直さずに読み通すと、最初にぶつかった1件だけでなく、レビュアーが気づくのと同じ粗い箇所に気づけます。セルフレビューチェックリストの例
レビューコメントの書き方
コメントの役目は、往復を最小限にして正しい修正にたどり着かせることです。そのためには、作成者がコメントの意味も緊急度も推測せずに行動へ移せる必要があります。 曖昧な反応は、その推測作業を作成者へ押し付けます。「これは違和感があります」だけでは、何が問題で、どこにあり、マージをブロックするのかどうかがわかりません。反応だけでなく具体的な場所と理由を書くと、コメントは先に解くべきパズルではなく、そのまま行動できるものになります。 コメントの先頭に、その重みを示す短いラベルを付けると、もう1つの推測作業をなくせます。よく使われるラベルの組み合わせは次のとおりです。関連ページ
プルリクエスト
レビューを依頼し、その結果を適用する場所。粒度・テンプレート・マージの仕組みを扱います。
テストコード
そもそも変更を検証可能にするもの。レビューがテストコードに対して確認するパターン。
Agentic Workflow
上記の機械的なチェックと判断の分担が土台とする、AI生成コード全般に対するAIと人間の広範な責任分担。
Vibe Coding
AIが生成したコードの検証責任が、レビューに届く前から人間に残り続ける理由。