本記事について
当サイトを閲覧いただきありがとうございます。 本記事はシリーズ『生成AI時代のアーキテクチャ超入門』の「開発運用アーキテクチャ」カテゴリ第5弾として、コードレビューについて解説する記事です。
レビューは品質保証ではなく設計合意の最終関門。バグ探しと混同すると「PRは溜まる／1行コメント承認／事故は本番で発覚」の連鎖が起きます。本記事では PR 粒度・レビュー観点（設計／実装／規約の3層）・承認ルール・コミット規約を、チームが大きくなっても壊れない設計として扱います。
本記事のテーマについてさらに詳しく知りたい方は『アーキテクトの教科書』・『実践Claude Code入門』も参考にしてみてください。
そもそもコードレビューとは何か
書籍の校正・校閲を思い浮かべてください。著者が書いた原稿を別の目で読み、誤字脱字だけでなく論理の飛躍や読者にとってのわかりやすさまでチェックします。一人で書いた文章には必ず盲点があるのと同じで、一人で書いたコードにも見落としがあります。
コードレビューとは、チームメンバーが書いたコードをマージする前に別のエンジニアが確認し、設計上の問題や見落としを検出するプロセスです。GitHubのPull Request（PR）がその代表的な仕組みです。
もしコードレビューがなければ、設計の方向性のズレや潜在的なバグが本番で発覚するまで気づかれず、手戻りコストが何倍にも膨れ上がります。
なぜコードレビューが必要か
設計のズレを本番前に検出する
テストは「コードが正しく動くか」を検証しますが、「そもそもこの設計で良いのか」は機械では判定できません。レビューは設計判断の妥当性を人間が確認する最後の関門です。
知識の共有と属人化の防止
レビューを通じてチーム全員がコードベースを把握でき、特定の人しか触れない領域が生まれるのを防ぎます。バス係数（1人が欠けると止まるリスク）を下げる最も効果的な手段です。
品質基準の暗黙知を形式知にする
レビューのやり取りを通じて、チームの「良いコードとは何か」の基準が共有・言語化されていきます。
レビューで見る3つの層
レビューは「バグ探し」と思われがちですが、実際に見るべき対象は3層に分かれています。CI が機械的に担保できるものと、レビューでなければ検知できないものを混ぜないのが設計の出発点です。
| 層 | 内容 | 誰が見るか |
|---|---|---|
| 機械層 | 構文・型・カバレッジ・Lint・フォーマット | CI（人間は見ない） |
| コード層 | 可読性・命名・重複・責務分離・簡潔さ | レビュアー（主担当） |
| 設計層 | 公開 API の安定性・アーキテクチャ整合性・拡張性 | シニア・オーナー |
機械で済むものはレビューで見ないのが鉄則です。「Prettier が整形していない」「空白が揃っていない」をレビューで指摘するのは人の時間を溶かすだけで、ここは CI と pre-commit で完封します。レビューはコード層と設計層だけに集中する──この割り切りができるかで、チームの速度が決まります。
PR粒度 — 小さいほど速い
レビュー時間とPR行数は線形ではなく、指数関数的に悪化します。300行の PR は60分で終わっても、1,000行の PR はまる1日レビューしても精度が出ない──これは経験則ですが、現場で例外を見たことがありません。
| PR行数 | 現実的なレビュー時間 | 欠陥検知率 |
|---|---|---|
| 〜100行 | 10〜20分 | 高（ほぼ全て検知） |
| 100〜300行 | 30〜60分 | 中（推奨レンジ） |
| 300〜500行 | 2時間〜半日 | 低（後半が流し読みに） |
| 500行超 | 半日〜1日 | 極低（ほぼ承認の儀式化） |
| 1,000行超 | 未知数 | ほぼ見ていない |
Google の社内研究でも欠陥検知率は400行を超えた瞬間に急落することが示されています。PRは300行以内を目標に分割するのが本命の運用です。巨大 PR は「もう出したから通して」という圧力も生みやすく、品質・開発体験・レビュアーの心理の全てが悪化します。
PRは300行以内。超える場合は必ず分割するか、事前に設計合意を取ります。
大きいPRをどう分割するか
「機能が大きいから分けられない」と言われがちですが、9割のケースで分割は可能です。以下が典型的な切り分けパターンです。
| 分割軸 | 例 |
|---|---|
| 構造の準備と本体を分ける | ①ディレクトリ構造・型定義のみ → ②実装本体 |
| リファクタと新機能を分ける | ①既存コードの整理 → ②新機能追加 |
| 層で分ける | ①DBスキーマ + マイグレ → ②APIエンドポイント → ③UI |
| Feature Flagで隠す | Flag off で先行マージ → Flag on で公開 |
| 水平分割 | 同じ変更を複数ファイルに適用 → ファイル群ごとに分ける |
リファクタと新機能を同じPRに入れるのは特に筋が悪い選択です。レビュアーは「この変更は本質か、ついでか」を毎行判断することになり、レビュー時間が2〜3倍に膨れます。リファクタは先に単独 PR で通し、その上に新機能を載せる──この順番が崩れると、チーム全体の速度が落ちます。
レビューで何を見るか — 段階別の実務
「レビュー観点チェックリスト」は現場で形骸化しがちです。コードが置かれている段階で重点を変えるのが実用的で、「自分のPRがどの段階かをレビュー冒頭で宣言」するだけでも、レビュアーの読み方は大きく変わります。
| 段階 | いつのPRか | 何を重点的に見るか | 目標時間 |
|---|---|---|---|
| ①プロトタイプ | 動くか確認したい段階 | 設計方針のみ（動作・命名は二の次） | 15分 |
| ②実装 | 本番投入前の本命PR | ロジック・エラー処理・テスト | 30〜60分 |
| ③リファクタ | 機能変更なし | 既存挙動が崩れていないか | 20分 |
| ④緊急hotfix | 障害対応 | 範囲が絞られているか・戻しやすいか | 10分 |
プロトタイプ PR で「命名が長い」「関数を分けるべき」を指摘するのは段階違いで、PR 作者が「それは今回の目的ではない」と反発する元。逆に実装 PR で設計方針を後出しすると後戻りが大きいため、設計論は①の段階で決着させます。
レビュアーの観点リスト（本命）
レビューで見るべき観点は、意識しないと「読んで、なんとなくOK」の儀式化に陥ります。以下は現場で実効性のある観点で、全部を毎回見るのではなく、PRの種類に応じて重点を変えるのが実用です。
| 観点 | 具体的に何を見るか |
|---|---|
| 正しさ | 仕様通りか・エッジケース・境界値（0、1、null、空配列） |
| テスト | テストの有無・意図が伝わる名前・失敗したらどう気づくか |
| 可読性 | 命名・責務分離・関数の長さ・早期リターン |
| エラー処理 | 失敗時の挙動・ログ・ユーザーへの見え方 |
| セキュリティ | 認可チェック・入力検証・SQLインジェクション・シークレット漏洩 |
| パフォーマンス | N+1 クエリ・キャッシュ・無駄なループ |
| 後方互換性 | 公開 API 変更・DB スキーマ変更・既存クライアント影響 |
「正しさ」と「テスト」の2軸だけでも毎回見るのが最低ライン。可読性やパフォーマンスは、明らかに問題があるときだけ指摘し、「好みの域」にまで踏み込まないのがレビュー文化の健全さを保つコツです。
承認ルール — 何人・誰に承認させるか
承認者の数と属性は、小さく見えて組織のスピードを決定的に左右する設計項目です。2人承認を必須にすれば品質は上がりますが、1人目が即承認しても2人目が3日動かなければPRは3日放置されます。
| パターン | 品質 | 速度 | 向いているケース |
|---|---|---|---|
| 1人承認（誰でも） | △ | 高 | 小規模・信頼できるチーム |
| 1人承認（CODEOWNERS指定） | ○ | 中〜高 | 本命（中規模） |
| 2人承認（うち1人はCODEOWNERS） | ◎ | 中 | 金融・医療・規制業界 |
| 2人承認（全員任意） | ○ | 低 | 非推奨（ボトルネックが見えない） |
CODEOWNERS（GitHub の機能で、特定ディレクトリ／ファイルの責任者を .github/CODEOWNERS で定義）を使うと、「このディレクトリは必ずこの人の承認が必要」を機械的に強制できます。現時点では、1人承認 + 重要領域はCODEOWNERS必須が中規模チームの本命構成。2人承認は一見安全に見えて、「人数×人数でレビュー遅延が累積」するため、規制業界以外では過剰な設計です。
コミット規約 — Conventional Commits
Conventional Commits は、コミットメッセージの先頭に feat:・fix:・refactor: などのプレフィックスをつける規約です。2017年頃に広まり、現時点ではOSS・SaaSを問わず事実上の標準になっています。
| prefix | 意味 |
|---|---|
feat | 新機能 |
fix | バグ修正 |
refactor | 機能変更なしのコード整理 |
perf | パフォーマンス改善 |
docs | ドキュメントのみ |
test | テストのみ |
chore | ビルド・CI・依存更新など |
典型的な書式は feat(auth): add passkey login flow のように prefix(scope): 要約 の形。BREAKING CHANGE: 注記を本文に入れると破壊的変更フラグになります。
Conventional Commitsの旨味
Conventional Commits を採用すると、リリースノートの自動生成（semantic-release・release-please）、SemVerの自動判定（fix→patch、feat→minor、BREAKING→major）が機械化できます。「履歴が検索可能な仕様書に変わる」という副次効果も強く、AI に変更履歴を読ませるときの理解精度が大幅に上がります。
| 恩恵 | 内容 |
|---|---|
| リリースノート自動生成 | feat・fix を拾って CHANGELOG.md を機械的に生成 |
| SemVer自動判定 | feat → minor／fix → patch／BREAKING → major |
| PR絞り込み | git log --grep='^feat' で新機能だけ抽出 |
| AI理解精度 | 構造化された履歴は AI が意図を掴みやすい |
semantic-release を CI に組み込めば、main マージで自動的にタグ付け・リリースまで完結します。採用コストは最初の1週間の慣れだけで、その先は恩恵しか残らない投資です。
スカッシュマージvs履歴を残す運用
PR のマージ方式は Squash／Rebase／Merge commit の3択ですが、Squash が現代の本命です。feature ブランチで発生した100個の細かい WIP コミット（wip・fix typo・revert・wip2）が main に残ると、git blame が実質無意味になります。
| 方式 | 特徴 | 推奨ケース |
|---|---|---|
| Squash | feature の全コミットを1つに圧縮して main へ | 本命（9割のチーム） |
| Rebase | feature のコミット構造を保ったまま線形にマージ | 歴史を残したいOSS |
| Merge commit | feature の分岐もmerge点も履歴に残す | Git Flow との組み合わせ |
Squash マージの運用では、PRタイトルがそのままコミットメッセージになるため、Conventional Commitsのprefixは PRタイトルに付けるのが鉄則です。PR タイトル feat(auth): add passkey login → main 上のコミットも同じタイトル、という構造が、リリースノート自動生成と「相性が最高」です。
やってはいけないこと
レビューは仕組みだけ整えても機能しません。レビュー文化という見えない部分が崩れた瞬間、以下のアンチパターンが蔓延します。
| 鬼門 | なぜ起きる・なぜダメか |
|---|---|
| LGTM即承認文化 | 「読んでいない」をLGTMで通す。事故の温床 |
| 人格攻撃型レビュー | 「なぜこんな書き方を」と詰めるコメント。心理的安全性を崩し退職につながる |
| スタイル論争で議論が爆発 | タブ／スペース・セミコロンを毎PRで議論。Prettier／Biome で完全に機械化する |
| 過剰に厳しい承認ブロッカー | 好みの範囲まで修正を要求。PRが1週間放置される |
| レビュー応答のSLAなし | PRが金曜に出てきて月曜まで放置 |
| 「レビューは厳しいほど品質が上がる」と過剰ブロック | PR放置でコンテキスト腐敗、結果的に検知率も低下 |
| 「コメントは少ない方が良いPR」と即LGTM | 誰も読んでいないLGTM承認文化の温床 |
「自分の書き方と違う」を理由にblockするのは筋が悪い選択。コーディングスタイルは CI が担保し、レビューは「壊れるか壊れないか」にだけ集中する──これがチームの健全性を保つ最大の線引きです。
AI判断軸
| AI有利 | AI不利 |
|---|---|
| 小さいPR + Conventional Commits（AIが差分を正確に把握） | 巨大PR + 自由形式コミット |
| AIレビュー + 人間レビューの二段構え | AIレビューなし・人間だけで全見 |
| CODEOWNERS で設計判断を分業 | 「誰でもレビュー」運用 |
| Squash マージで履歴を1PR＝1コミットに | WIPコミットがmainに散らばる |
| 人間は設計・ドメイン・UXに集中 | 人間がスペース・命名まで指摘 |
- PR粒度を300行以内に抑える文化を作る — 分割テクニックを共有
- 1人承認 + CODEOWNERSで設計判断をオーナーに集約
- Conventional CommitsとSquashマージで履歴を自動化可能に
- AIレビューで下処理、人間は設計とドメインに集中
AIレビューと人間レビューの役割分担
AIコードレビュー（CodeRabbit・GitHub Copilot等）は、命名規約・未使用変数・型の不整合・セキュリティパターンの検出で人間と同等以上の精度を出します。一方、ドメインロジックの正しさ・設計判断の妥当性・ユーザー体験への影響はAIでは判断できません。
現実的な運用は「AIが全PRに自動レビュー→指摘事項を修正→人間は設計・ドメイン・UXに集中してレビュー」の二段構えです。人間のレビュー時間を高付加価値の判断に集中させる仕組みとして、AIレビューは投資対効果が高いです。
PRサイズがAIレビューの精度を決める
AIがレビューできる精度はPRのサイズに強く依存します。300行以下のPRであれば、AIは変更の全体像を把握して的確なコメントを付けられます。1,000行を超えるPRになると、AIのコンテキスト窓に収まりきらないか、収まっても注意が散漫になり、重要な問題を見逃す確率が上がります。
つまり、AIレビューの導入効果を最大化するには、PR分割の文化が前提条件です。
レビューSLA — 応答時間を数値で決める
レビュー遅延は組織の速度を直接殺します。「気づいたら見る」という緩い運用は、PRが2日放置されると書いた人のコンテキストが消えるため、レビュー品質まで落ちる二重の悪影響が出ます。
| SLA | 応答時間 | 適用範囲 |
|---|---|---|
| レビュー初回応答 | 4時間以内（業務時間） | 全PR |
| レビュー完了 | 24時間以内 | 通常PR |
| 緊急hotfix | 1時間以内 | urgent ラベル付きPR |
| 再レビュー | 当日中 | 指摘対応後の再提出 |
SLA を明示するだけで、誰もレビューしない問題が劇的に解消されます。補助として、Slack／Teamsへの自動通知（GitHub の Pull Request Reviewer 機能・pull-reminders bot）を入れ、「4時間経過でリマインド」「24時間で再通知」の自動化が現代の定石です。人のレビュー待ちは人の記憶任せにしない──これが機械化しやすく、かつ組織改善のレバレッジが高い領域です。
AIによるレビュー — 現時点の現実
2025年から AI レビューが急速に実用圏に入りました。GitHub Copilot Code Review・CodeRabbit・Codium・Graphite Reviewer などが、PR に自動でコメントを返せるようになっています。現時点でも、「人間レビュアーの代替にはならない」ものの、最初のパスで50〜70%の指摘を潰せるというのが現場の実感です。
| AIレビューが強い領域 | AIレビューが弱い領域 |
|---|---|
| 単純なバグ・null 参照・未使用変数 | ドメイン固有のビジネスロジック |
| 命名・コード規約・ドキュメント漏れ | アーキテクチャ整合性・拡張性の判断 |
| セキュリティの定型パターン | 過去の議論・設計合意との整合性 |
| テストの不足・境界値漏れ | 「この変更はそもそも必要か」 |
理想的な運用は、AIが先に機械的な指摘をすべて返す → 人間は設計とドメインロジックだけ見るという分業。「AIがレビューしたから人間不要」ではなく、「人間が設計に集中できるようにAIが下処理をする」構図が、現時点の鉄板です。
決めるべきこと — 自分のプロジェクトでの答えは？
以下の項目について、自分のプロジェクトの答えを1〜2文で言語化してみてください。曖昧なまま着手すると、必ず後から「なぜそう決めたんだっけ」が問われます。
- PR粒度の目標（300行以内を推奨）
- 承認ルール（1人／2人・CODEOWNERSの有無）
- レビューSLA（初回応答時間・完了時間）
- コミット規約（Conventional Commits採用有無）
- マージ方式（Squash／Rebase／Merge commit）
- レビュー観点の優先順位（機械化する範囲の線引き）
- AIレビューツールの採用（CodeRabbit・GitHub Copilot Code Review等）
- スタイル論争の封じ込め（Prettier／Biomeで完全機械化）
筆者メモ — 「2人承認必須」が殺したスタートアップの速度
あるスタートアップで「全PRで2人承認必須」を採用したところ、メンバーが10人を超えた時点で平均マージ所要時間が2日を超えた──という事例が業界ではよく語られます。2人目のレビュアーが他の作業で忙しいと、1人目が承認済みでも止まってしまう。結果、PRが溜まり、コンフリクトが増え、リベース地獄が始まる。
このチームは「1人承認 + CODEOWNERS に切り替え、重要ディレクトリ（決済・認証）だけ2人承認必須」に変更したところ、平均マージ所要時間が半日まで短縮されました。「品質のための2人承認」は、規制業界や決済系のコア領域では本命ですが、一律適用は組織速度の殺し屋です。品質を守りたい領域を特定し、そこだけに重装備を敷くのが現代的な設計の考え方です。
「全PR2人承認」は安全に見えて最も遅い設計です。
この記事に関連する記事
https://senkohome.com/arch-intro-devops-slo/ https://senkohome.com/arch-intro-devops-vcs/ https://senkohome.com/arch-intro-devops-deploy/
まとめ
本記事はコードレビューについて、PR粒度・観点・承認ルール・Conventional Commits・Squashマージ・AIレビュー下処理まで含めて解説しました。如何だったでしょうか。
PR 300行以内に抑え、1人承認+CODEOWNERSで設計判断を集約、Squash+Conventional Commitsで履歴を自動化、AIレビューで下処理。これが2026年のコードレビューの現実解です。
次回はテスト設計（テストピラミッド・契約テスト・E2E）について解説します。
シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方
本記事で扱った内容の詳細は GitHub - Pull Requests も合わせて参考にしてください。
それでは次の記事も閲覧いただけると幸いです。
📚 シリーズ：生成AI時代のアーキテクチャ超入門（58/89）