AIにコードを書かせると、実装は速くなります。しかし、レビューする人間の時間は同じ速度では増えません。
数時間かかっていた修正が数分で出てくる。複数のAIエージェントが並行してPull Requestを作る。すると次に詰まるのは、コードを書く工程ではなく、その変更を本番へ入れてよいか判断する工程です。
ここで「レビューもAIに任せればよい」と考えると、別の問題が起きます。
- 重要でない指摘が大量に出る
- 存在しない問題を指摘する
- 仕様と違う修正案を自信満々に出す
- コード単体では分からない業務影響を見落とす
- AIが書いたコードを、似た前提を持つAIが追認する
必要なのは、AIレビュアーを一人増やすことではありません。決定論的な検査、AIによる意味理解、人間の判断を、変更リスクに応じて組み合わせるレビュー設計です。
この記事では、Uber、Meta、Google、GitHubの一次情報をもとに、AIコーディング時代のコードレビューを7つの原則に整理します。最後に、導入を3段階で進める手順と、そのまま使える確認項目も掲載します。
最終更新：2026年9月26日
なぜAIコーディングでレビューがボトルネックになるのか
コード生成が速くなると、変更量と変更頻度が増えます。それ自体は悪いことではありません。小さく安全な変更が増えるなら、改善の速度を上げられます。
問題は、生成された変更が次の工程へそのまま流れ込むことです。
Google Cloudが公開したDORA 2025では、回答者の90％が仕事でAIを使い、80％超が生産性向上を感じていました。一方で、AI利用はソフトウェアデリバリーの安定性と負の関係を残しています。DORAは、自動テスト、成熟したバージョン管理、速いフィードバックなどの制御が弱いと、増えた変更が不安定さを増幅すると説明しています。
参考：Google Cloud「2025 DORA Report」
これは調査上の相関であり、「AIを使うと障害が増える」という因果関係を証明したものではありません。ただ、個人の実装速度だけを上げても、組織全体のデリバリーが安全に速くなるとは限らないことは示しています。
レビューの目的を「生成されたコードを全部読む」に置くと、人間の処理能力が上限になります。目的を、変更の意図・リスク・検証証拠を確認し、本番へ進める判断をすることへ置き直す必要があります。
UberのAIコードレビューが示したこと
Uberは2025年、社内のAIコードレビュー基盤「uReview」を公開しました。同社によれば、週約6万5,000件のdiffの90％超を解析し、利用者が評価したコメントの75％が有用、投稿されたコメントの65％超が実際に対処されています。
参考：Uber「uReview: Scalable, Trustworthy GenAI for Code Review」
数字はUber自身による社内事例であり、一般的なAIレビューツールの性能を示すベンチマークではありません。重要なのは、モデル名よりも設計です。
uReviewは一回のプロンプトでレビューを完結させません。
- 対象ファイルと周辺コンテキストを選ぶ
- バグ、社内ルール、セキュリティなど専門別にコメント候補を作る
- 別の処理でコメントの品質と確信度を評価する
- 重複や、過去に価値が低かった種類の指摘を除外する
- 開発者の評価と、最終コードで対処されたかを記録する
Uberが最も重視したのは、コメント数ではなくシグナル対ノイズ比でした。初期には、可読性、細かなログ、低影響の最適化などが不評で、正しさ、例外処理、社内ベストプラクティスに関する指摘のほうが評価されました。
AIレビューでは、たくさん指摘するほど品質が高いわけではありません。誤検知が続けば、開発者は本当に重要な警告まで読まなくなります。
Metaは「全部を同じ深さで見る」前提を捨てた
Metaは、コード変更とメタデータから本番障害の可能性を予測する「Diff Risk Score」を運用しています。リスク情報を、テストの選択、レビュアー選定、リリース判断などへ利用しています。
ここから得られる示唆は、AIに合否を丸投げすることではありません。変更を一律に扱わず、リスクに応じて検証の深さを変えることです。
たとえば、文言修正と認証ロジック変更に同じレビュー工程を課すのは非効率です。逆に、決済、権限、データ移行、本番設定の変更を、通常の小さな修正と同じ承認で流すのは危険です。
AIは、リスクの候補を探し、注目すべき箇所を絞るために使う。最終的な統制は、変更内容と影響範囲に応じて設計します。
AIコードレビューを設計する7原則
原則1：レビュー前に「変更の意図」を書く
diffだけを見ても、そのコードが何を達成すべきかは分かりません。
最低限、Pull Requestに次を残します。
- 解決する問題
- 対象外にすること
- 受入条件
- 影響する利用者・システム・データ
- 失敗したときの戻し方
- 実行したテストと結果
GitHub Copilot code reviewも、Pull Requestの説明、リポジトリのカスタム指示、エージェントスキル、接続したMCPサーバーなどからコンテキストを取得できます。裏を返せば、目的や業務条件が与えられていなければ、レビューはコードの局所的な推測へ寄ります。
参考：GitHub Docs「About GitHub Copilot code review」
昨日の記事で紹介したように、AIへ同じ修正を繰り返している場合は、注意文を増やすのではなく、条件を変えたテストへ落とします。AIへの反復指摘を合格条件に変える方法も合わせて確認してください。
原則2：決定論的に検査できることをLLMへ任せない
構文、フォーマット、型、既知の脆弱性パターン、依存関係、テスト成否、カバレッジ下限などは、既存のツールで再現可能に判定できます。
これらを毎回LLMへ質問すると、結果が揺れ、実行コストも増えます。
| 検査方法 | 主に任せること | 特徴 |
|---|---|---|
| Lint・型・静的解析 | 構文、形式、既知パターン | 安価で再現性が高い |
| テスト・実行検証 | 仕様化できる入出力、回帰 | 合否を機械的に判定できる |
| AIレビュー | 文脈を要する不整合、例外処理、変更意図とのずれ | 広く探せるが誤検知がある |
| 人間レビュー | 設計、業務判断、責任、受容できるリスク | 暗黙知と最終判断を扱える |
Uberも、単純な構文や形式は従来のリンターを使い、意味理解が必要な社内ルールをLLMの対象にしています。
AIを入れる順序は、「人間が嫌う作業」ではなく、既存の決定論的検査では表現しにくく、見落としたときの価値が大きい作業から考えます。
原則3：一つの万能レビュアーを作らない
バグ、セキュリティ、パフォーマンス、社内標準では、必要なコンテキストも誤検知の許容度も違います。
Uberは、標準的なバグ、社内ベストプラクティス、アプリケーションセキュリティを別のアシスタントに分けています。これにより、目的別にプロンプト、入力、評価、しきい値を変えられます。
社内導入でも、最初から全観点を有効にしないほうが安全です。
- 例外処理の欠落
- 認証・認可の変更
- データ破壊の可能性
- 既存API契約の破壊
- 自社で頻発した障害パターン
まず1〜2種類へ絞り、正解例と誤検知例を集めます。
原則4：AIのコメントを、そのまま開発者へ流さない
AIが生成した全コメントを投稿すると、レビュー欄がノイズで埋まります。
少なくとも次の後処理を置きます。
- 同じ内容の重複をまとめる
- 重要度が低いスタイル指摘を抑制する
- 根拠となる行やルールを示せないコメントを落とす
- 確信度が低い場合は断定せず、確認事項として扱う
- 対象外ファイルや自動生成物を除外する
目標はコメント数ではなく、開発者が行動に移せる指摘の割合です。
原則5：AIにはコード外のコンテキストが見えていないと考える
Uberは、uReviewがコードだけから確認できるバグには強い一方、過去のPull Request、Feature Flag、データベーススキーマ、技術文書などを持たないため、システム設計全体の正しさを評価するのは難しいと説明しています。
コードレビューで必要な情報は、リポジトリの中だけにあるとは限りません。
- 変更の元になった障害・問い合わせ
- 業務ルールと例外
- データベース移行の順序
- 外部APIの契約
- 本番トラフィックとSLO
- 規制や個人情報の扱い
MCPなどで情報を追加すれば判断材料は増えますが、接続先が信頼できるか、どのデータを外部モデルへ送るか、権限をどう制限するかという新しいリスクも生まれます。
AIエージェントへ渡す権限と監査は、AIエージェントのセキュリティ設計で整理しています。
原則6：人間はコードの言い換えではなく、変更リスクを見る
AIが構文や局所的な不具合を確認できるようになるほど、人間は次を優先します。
- そもそも解く問題が正しいか
- アーキテクチャと責任境界は妥当か
- データ移行とロールバックが成立するか
- 障害時の影響範囲を許容できるか
- テストが実装ではなく仕様を検証しているか
- 既存機能の削除や片側修正がないか
AIの修正提案は、そのまま採用しません。GitHub自身も、Copilot code reviewが問題を見逃したり、存在しない問題を指摘したり、不正確・安全でない修正案を出したりする可能性を明記し、人間によるレビューとテストで補完するよう説明しています。
参考：GitHub Copilot Agentsの責任ある利用と制約
原則7：「何件指摘したか」ではなく、下流の結果を測る
AIレビューの導入効果を、コメント数や利用回数だけで測ると、ノイズを増やす行動が高評価になります。
測る候補は次のとおりです。
- 有用と評価されたコメントの割合
- 実際に修正されたコメントの割合
- 誤検知率と、無視されるカテゴリ
- レビュー待ち時間と、マージまでの時間
- 本番へ流出した欠陥
- 変更失敗率と復旧時間
- 人間が設計・リスク確認へ使えた時間
導入前後を比べるときは、変更規模、チーム、言語、リポジトリの性質を分けます。AI導入と同時にテストや組織体制を変えた場合、改善をAIだけの効果と断定しないことも重要です。
人とAIの役割分担
レビュー対象を次のように分けると、AIを過信せず、単なる二重チェックにもなりにくくなります。
| 対象 | 決定論的ツール | AIレビュー | 人間レビュー |
|---|---|---|---|
| 構文・型・形式 | 主担当 | 補助 | 原則不要 |
| 既知の脆弱性パターン | 主担当 | 補助 | 高リスクのみ |
| 例外処理・局所ロジック | テスト | 主担当 | 重要箇所 |
| 仕様・受入条件との整合 | テスト可能部分 | 補助 | 主担当 |
| アーキテクチャ・業務影響 | 補助困難 | 論点抽出 | 主担当 |
| データ移行・権限・本番影響 | 検査・シミュレーション | 論点抽出 | 最終判断 |
「人間が最後に全部読む」では、生成量が増えたときに破綻します。機械で確定できる部分を先に落とし、AIで探索範囲を絞り、人間の時間を高リスク判断へ集中させます。
導入は3段階で進める
段階1：Shadow運用
AIレビューを実行しますが、コメントは開発者へ自動投稿しません。既存の人間レビューと比較し、次を記録します。
- AIが見つけた有用な問題
- 人間だけが見つけた問題
- 誤検知
- 取得できなかったコンテキスト
- 1回あたりの費用と待ち時間
この段階で、対象カテゴリとしきい値を決めます。
段階2：非ブロッキング運用
有用性が確認できたカテゴリだけをPull Requestへ投稿します。AIコメントだけでマージを止めず、開発者が「有用／不要」を返せるようにします。
GitHub Copilot code reviewの承認判定は、通常は必須承認へ数えられません。AI承認を必須ルールへ使う機能も公開プレビューとして提供されていますが、最初の導入地点にはしないほうが安全です。
段階3：リスク連動運用
十分な実績が集まったら、変更リスクによってレビュー経路を変えます。
- 低リスク：自動テストとAIレビューを通し、人間はサンプリング
- 中リスク：担当者レビューを必須化
- 高リスク：専門家、セキュリティ、運用責任者の承認を追加
AIの判断だけをブロッキング条件にせず、再現可能なテストや静的解析、明示した人間承認と組み合わせます。
導入手段を選ぶときの注意
AIコードレビューの実装方法は、大きく3つあります。
開発プラットフォームの標準機能
GitHub Copilot code reviewなど、既存のPull Requestと権限管理へ統合された機能です。導入は比較的容易ですが、利用可能なモデル、除外ファイル、料金、データ処理、組織ポリシーを確認する必要があります。
外部SaaS型レビュアー
複数のGitホスティングへ対応し、レビュー特化機能を持つサービスです。コード、diff、Pull Request本文、関連チケットなど、何が外部へ送信され、保存・学習へ使われるかを契約と技術設定の両方で確認します。
自社構築
モデル、プロンプト、コンテキスト、保存先を細かく制御できます。一方で、誤検知の評価、モデル変更への追従、秘密情報の保護、監査、可用性まで自社責任になります。
公開実装を利用する場合も、READMEだけで判断せず、最終更新、実質的なコミット、テスト、Issue対応、認証情報とコードの送信先を確認します。公開リポジトリが残っていることと、現在の本番採用に適することは同じではありません。
現在の推奨は、まず既存の開発プラットフォームで非ブロッキング運用を行い、自社で多発する欠陥と不足コンテキストを測ることです。独自モデルや大規模な自社基盤への投資は、汎用ツールで解けない問題と必要な統制が明確になってから判断します。
コピペ用：AIコードレビュー導入前の確認項目
【目的】
AIレビューで減らしたい見落とし：
対象にする言語・リポジトリ・変更：
対象外にするファイル・変更：
【役割分担】
Lint・型・静的解析で判定すること：
テストで判定すること：
AIに探させること：
人間が最終判断すること：
【コンテキスト】
Pull Requestに必須の受入条件：
参照させる社内ルール：
外部モデルへ送信してよいデータ：
接続するMCP・外部システムと権限：
【評価】
有用コメント率：
誤検知率：
修正されたコメント率：
レビュー待ち時間：
本番流出欠陥・変更失敗率：
【展開条件】
Shadowから非ブロッキングへ進む条件：
対象チームを増やす条件：
停止・ロールバック条件：
評価責任者と見直し日：
最初から完璧なAIレビュアーを目指す必要はありません。見落としたくない問題を一つ選び、その問題について有用な指摘と誤検知を測るところから始めます。
結論：AIレビューの目的は、人間を消すことではない
AIコーディングによって増えるのは、コードだけではありません。判断しなければならない変更も増えます。
だから、AIコードレビューの成否は、レビュー人数を減らせたかでは決まりません。
成功と言えるのは、決定論的な検査を自動化し、AIが注目すべきリスクを絞り、人間が設計・業務影響・本番責任の判断へ時間を使えるようになったときです。
レビューを「すべての行を読む作業」から、変更の意図、リスク、検証証拠を確認する仕組みへ変える。
コードを書く速度が上がった組織ほど、この再設計が必要になります。
関連記事
- AIエージェントに本番運用を任せてよいか — コードレビューの次に増える監視・障害調査・復旧を、安全に自律化する設計を整理しています。
- AIに同じ指摘を繰り返さない依頼と検証 — 繰り返す修正を、次回から検出できる合格条件とテストへ変えます。
- 生成AI時代のSIerはどうなる？ — コード生成が安くなる中で、SIerの価値と人月ビジネスがどう変わるかを整理しています。
- AIエージェントのセキュリティ設計 — 権限、承認、監査ログ、停止方法の実務チェックリストです。
- AIエージェントを本番で任せる前の10問 — 受入条件、責任分担、総コスト、撤退条件を確認できます。
参考資料
以下は2026年9月26日に内容を確認しました。
- Uber：uReview
- Meta Engineering：Diff Risk Score
- Google Cloud：2025 DORA Report
- Google Cloud：Impact of Generative AI in Software Development
- GitHub Docs：About GitHub Copilot code review
- GitHub Docs：Responsible use of GitHub Copilot Agents
WRITTEN BY
コメント