AI時代のレビュー
背景
code:a
導入シナリオ,デプロイ頻度,リードタイム,変更失敗率,MTTR（復旧時間）
A: AI生成 + 手動レビューのみ,+35% (改善),-20% (改善),+45% (悪化),+25% (悪化)
B: AI生成 + 汎用AIレビュー,+30% (改善),-15% (改善),+30% (悪化),+20% (悪化)
C: AI生成 + システム認識型AIレビュー,+42% (改善),-35% (改善),-18% (改善),-10% (改善)
AIでコードを高速生成するだけでは、レビューがボトルネックとなり、潜在的なバグが production に流出することで変更失敗率が急上昇するリスクがある AIによりコード生成が劇的に高速化し、この関係が逆転しつつある AI導入後はPR数が増加し、レビューがフロー上のボトルネックとして顕在化 レビューがなくなれば、変更の意図を説明できないコードが蓄積する
AIはチートする
通らないテストコードを書き換える、削除する
実装に合わせてテストを骨抜きにする
これが「AI生成コードのレビューがなぜ必要か」の根本的な理由のひとつ
対策の方向性
プロンプトで触らないよう明示する
インターフェーステストを別コンテキストで書かせる
実装AIの文脈を渡さないことで、実装に引きずられたテストの生成を防ぐ カウシェの「計測と改善は別エージェント」と同じ思想 サーバ再起動を挟んでDBの状態を検証するなど、チートの余地を物理的に減らす設計 コードレビューが担ってきた役割
繰り返される変更による複雑性の増大を抑える
チーム内に変更内容の知識を共有
「誰かに見られるコード」のほうが丁寧に書かれる
これら4つの役割を別の手段で担保できるなら、レビュー削減の議論は前進する
アプローチ
生成段階で品質を作る
レビュー工程で品質を補強する
パイプラインで品質を保証する
本番で品質を回復できるようにする
まったく新しい何か
これまでのコードレビュー支援
新しいレビュー体験
エージェントが実装を完了した直後に、厳格な「検証」ステップを自動的に挿入するモデル
従来のリンターや静的解析を遥かに超え、エージェントが自ら作成した plan.md や spec.md と最終的な実装を照合 要件の漏れがないかを論理的に検証する
独自のエンドツーエンド・コーディングエージェント
「一撃（One-shot）」で、コード記述からテスト実行、CIのパス確認までを完遂 人間がレビューする際には「すでに動作が保証された完成品」として提示される
現れてきたパターン
差分を読み始める前に、エージェントがリポジトリ全体のコンテキストを収集
「この変更がどこに影響するか」「過去に似た箇所でどのような設計判断がなされたか」をサマリーとして提示
レビュー参加者は「何が起きているか」の認知負荷から解放され、「この変更は妥当か」に集中できる
すべての指摘に重要度を付与
カウシェの3人の専門家ペルソナによる並列レビューが具体例 シニアGoエンジニア: コード品質、規約準拠、テストカバレッジ シニアアーキテクト: 設計の整合性、セキュリティ、ドメイン知識との照合
GCP専門家: DBクエリの効率、インフラへの影響、非同期処理の冪等性 指摘のライフサイクルを追跡し、チームがどの指摘を「受け入れ」、どの指摘を「無視」したかをデータ化
AIは時間の経過とともにチーム独自のコーディング基準や暗黙の了解を学習 個人レベルの帰属管理として、関数に//A（AI記述・未レビュー）や//HIGH-RISK-UNREVIEWEDをマークする運用も提案されている（Mia Heidenstedt） レビューで見つかった問題を指摘するだけでなく、その場で解決策（パッチ）を提案
1クリックで修正を適用できる機能
指摘・修正・再レビューの往復サイクルが数分単位に短縮
レビューの線引き
線引きの軸の例
ファイル移動・リネーム、import整理、型定義移動、コンポーネント分割・統合、変数リネーム、ESLint/Prettier修正、不要コード削除、非推奨APIの機械的移行、GraphQL codegen実行結果など やり直しが効かない領域は人間レビュー必須
基盤ライブラリの追加・置換、マネージドサービスの変更、横断的関心事 コードベースの領域ごとに critical/high/medium/low を定義
認証・認可・データハンドリングなど高リスク関数を明示的にマーク
//HIGH-RISK-UNREVIEWED・//HIGH-RISK-REVIEWEDで人間レビューの必要性を可視化
AIがその関数を1文字でも変更したら、レビュー状態を未レビューに戻すよう指示する 共通する考え方
セルフマージで進めても要件・実装方針がブレない
レビューの自動改善ループ
Measure: 直近のPR統計（承認率、誤判定数、ルール発火率）を集計
Explore: リポジトリやインフラを巡回してパターンを探索
Improve: 検出ルールやパターン集を編集
Reflect: 翌日の優先順位を決め、各エージェントへの指示を残す
Audit: 全エージェントの変更を検証
毎回新しいセッションで動くため、前回の判断記録を読んでから動く
映画『メメント』のように前回の自分のメモを頼りに判断 効果スコア（効果数÷発火数）が低いルールは自動でアーカイブ 計測と改善は別エージェントに分けるのが大事
同じエージェントだと自分の改善効果を自分で計測する構造になる
SDLC全体での品質担保
1. 生成段階で品質を作る
規範と設計資産をAI可読にする（コーディング規約、過去の教訓）
path-specificなプロンプト（CLAUDE.mdなど）で文脈をリポジトリに埋め込む 一度に大きな複雑性を生成させない、人間が把握できる単位に分割
生成直後に自己検証を行う
コード複雑性の削減
将来のAIタスクの成功率にも影響する
分散システムのログを集約し「Node 1には保存されたがNode 2には保存されていない」のような抽象化された情報を提供
AIが高コストなCLIコマンドやブラウザ操作を繰り返す必要を減らす 2. レビュー工程で品質を補強する
リスクに応じてレビュー要否を切り分ける（ティア分類） レビューを専門領域ごとに分離する
複数の視点で検証する（複数モデル）
修正まで含めて自動化する
3. パイプラインで品質を保証する
非機能要件を継続的に検証
4. 本番で品質を回復できるようにする
ロールバックを高速かつ標準化
異常検知と原因特定を即時化
再注目される手法
AI Agentが大量のコードを生成しまくっていくと，それらを全て人間がチェックするのは現実的ではなくなる．人間の責任は「コードレビューでコードの良し悪しを判断する」から「成果物の検証」方向に比重が移っていく．現状では未だにレビューは非常に重要であることは確認されつつも，いくつかのセッションで「テストコードのレビューを重視」「入力と出力を定義・テストし，中間のブラックボックスは許容する」といったアプローチも聞かれた．
より将来的には抽象度はさらに上がり「テストが通ればOK」ではなく，セキュリティ・信頼性・パフォーマンスといったシステム特性 (Property) をガードレールとして定義し，それで正しさを保証するモデルに移行し，人間の役割は「コードを読む」から「特性と制約を定義する」に変わっていくだろうという予測もあった．
十分に複雑なシステムはコードレベルのデバッグが不可能になる．従来の「コードを読んで原因を特定する」デバッグから，症状とシステム特性に基づくデバッグへの移行が不可避になりつつある．
AI生成コードは安いので、複数解の探索・比較に積極的に使う 関連事例
Findy: 不要なレビューをAIにまかせてAIコーディングの環境改善を加速した Acsim: 人間レビューはもう不要？ AI と人間のレビューの線引きを決めた話 カウシェ: 全PRの83%をAIレビューだけでマージできるようにした 3人の専門家ペルソナ、自動改善ループ、思考ジャーナル
mtx2s: 人間によるコードレビューに依存しすぎない"速さと品質の両立"を開発ライフサイクル全体で支える 個人開発者向けの12原則、AIのチート傾向への対策、関数単位のレビュー帰属マーキング