コードレビュー ― PR 300行+1人承認+CODEOWNERS ― 生成AI時代のアーキテクチャ超入門

層	内容	誰が見るか
機械層	構文・型・カバレッジ・Lint・フォーマット	CI（人間は見ない）
コード層	可読性・命名・重複・責務分離・簡潔さ	レビュアー（主担当）
設計層	公開 API の安定性・アーキテクチャ整合性・拡張性	シニア・オーナー

機械で済むものはレビューで見ないのが鉄則です。「Prettier が整形していない」「空白が揃っていない」をレビューで指摘するのは人の時間を溶かすだけで、ここは CI と pre-commit で完封します。レビューはコード層と設計層だけに集中する──この割り切りができるかで、チームの速度が決まります。

PR粒度 — 小さいほど速い

レビュー時間とPR行数は線形ではなく、指数関数的に悪化します。300行の PR は60分で終わっても、1,000行の PR はまる1日レビューしても精度が出ない──これは経験則ですが、現場で例外を見たことがありません。

xychart-beta
    title "PR行数 vs 欠陥検知率（推定）"
    x-axis "PR行数" [100, 300, 500, 1000, 2000]
    y-axis "欠陥検知率(%)" 0 --> 100
    bar [95, 80, 50, 20, 5]

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が金曜に出てきて月曜まで放置

「自分の書き方と違う」を理由にblockするのは筋が悪い選択。コーディングスタイルは CI が担保し、レビューは「壊れるか壊れないか」にだけ集中する──これがチームの健全性を保つ最大の線引きです。

レビュー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が下処理をする」構図が、現時点の鉄板です。

AI時代の視点

AI 駆動開発では、レビューの役割がコードの正しさ確認からAIが書いたコードの設計妥当性確認にシフトします。AI は1時間で数百行を書きますが、「それが自プロジェクトの設計原則と整合しているか」は AI だけでは判断できない。人間レビュアーがこの判断を担わないと、設計の一貫性が静かに崩れていくのが最大のリスクです。

AI時代に有利	AI時代に不利
小さいPR + Conventional Commits	巨大PR + 自由形式コミット
AIレビュー + 人間レビューの二段構え	AIレビューなし・人間だけで全見
CODEOWNERS で設計判断を分業	「誰でもレビュー」運用
Squash マージで履歴を1PR＝1コミットに	WIP コミットが main に散らばる
人間は設計・ドメイン・UXに集中	人間がスペース・命名まで指摘

AI が PR を作る時代も目前で、「AIが書いたPRをAIレビューが最初に見て、人間は最終判断」する運用が実用化しつつあります。この構成が回るチームと回らないチームで、月間のマージ数に3〜5倍の差が出始めています。

AI 時代は人間レビュアーが設計判断に集中。それ以外は AI に任せます。

よくある勘違い①

レビューに関する誤解は、現場で頻繁に摩擦を生みます。

レビューは厳しいほど品質が上がる

度を越した厳しさは品質を下げます。PR が1週間放置される文化では、レビュー待ちの間にコンテキストが腐り、再レビューでも見落としが増える。適度に緩く・速く回す方が結果的に欠陥検知率は高いです。

レビュアーはシニアだけにすべき

ジュニアがレビューに入ることでチーム全体の成長速度が上がります。シニアは設計層、ジュニアは命名・可読性に意見を出す構図が健全。「シニアしか承認できない」はボトルネックそのもの。

よくある勘違い②

コメントは少ない方が良いPR

コメント0のPRは危険信号の可能性が高い。「誰も読んでいない」「LGTM即承認」の温床。小さい PR でも最低1〜2個の質問・確認が入るのが健全です。

Conventional Commitsは面倒

最初の1週間だけ面倒で、その後はリリースノート・SemVer判定・AIの履歴理解の3点で恩恵を受けます。導入しないチームはこの恩恵を永続的に失います。

レビューは厳しさより速さ。放置が最大の敵です。

決めるべきこと — あなたのプロジェクトでの答えは？

以下の項目について、あなたのプロジェクトの答えを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人承認」は安全に見えて最も遅い設計です。

最終的な判断の仕方

レビュー設計の本質は、人間の時間を何に使わせるかの資源配分です。レビューは最も高価な人的リソースを消費するため、機械で済むもの（フォーマット・Lint・型・カバレッジ）は全て CI に逃がし、人間は設計判断・ドメインロジック・アーキテクチャ整合性だけを見る──この線引きができるかで、チーム全体の速度が2〜3倍変わります。

現時点の鉄板は「PR 300行以内 + 1人承認 + CODEOWNERS + Squashマージ + Conventional Commits + AIレビュー下処理」です。2人承認は規制業界以外で過剰、Rebase／Merge commit は Squash と比較して優位性がほぼなく、スタイル論争は Prettier／Biome で完全に機械化します。AI 駆動開発では、人間は「設計の一貫性」という AI が苦手な領域にこそ集中すべきで、ここを外すと AI 生成コードで設計が静かに腐ります。

選定の優先順位

PR粒度を300行以内に抑える文化を作る — 分割テクニックを共有
1人承認 + CODEOWNERSで設計判断をオーナーに集約
Conventional CommitsとSquashマージで履歴を自動化可能に
AIレビューで下処理、人間は設計とドメインに集中

「レビューは速く、小さく、焦点を絞って」厳しさより回転数が勝ちます。

まとめ

本記事はコードレビューについて、PR粒度・観点・承認ルール・Conventional Commits・Squashマージ・AIレビュー下処理まで含めて解説しました。如何だったでしょうか。

PR 300行以内に抑え、1人承認+CODEOWNERSで設計判断を集約、Squash+Conventional Commitsで履歴を自動化、AIレビューで下処理。これが2026年のコードレビューの現実解です。

次回はテスト設計（テストピラミッド・契約テスト・E2E）について解説します。

シリーズ目次に戻る → 『生成AI時代のアーキテクチャ超入門』の歩き方

それでは次の記事も閲覧いただけると幸いです。