- AIが生成するコードの量と規模が指数関数的に増加する中、従来の手動コードレビュー方式はもはや有効ではない状況
- AI導入率が高いチームでは作業完了量が21%増加し、PRマージは98%増えた一方で、PRレビュー時間は91%増加するという逆説的な現象が発生
- コードを直接確認する代わりに、**仕様と受け入れ基準（Acceptance Criteria）**をレビューする上流の検証へと人間の役割を移すべき
- 単一の検証ゲートではなく、多重エージェント競争、決定論的ガードレール、BDD、権限システム、敵対的検証などスイスチーズモデルに基づく多層信頼構造が必要
- 「速くデプロイし、すべてを観測し、さらに速く戻す」方式が、遅いレビューの後に本番でデバッグすることに代わる新たなパラダイム
人間はすでにコードレビューをさばけなくなっている
- PRは何日も放置され、形式的な承認が行われ、レビュアーが500行のdiffをざっと眺めるのが現実
- コードレビューは品質ゲートと見なされているが、行単位のレビューなしで何十年もソフトウェアを出荷してきたチームは存在し、コードレビューが一般化したのは2012〜2014年ごろ
- レビューがあっても障害は起こり、その対応としてfeature flag、段階的ロールアウト、即時ロールバックのような仕組みを構築してきた
すべてのコードを読むことをあきらめるべき
- AI導入率が高いチームでは、変更件数と変更サイズの2つが同時に指数関数的に増加している
- 1万人以上の開発者、1,255チームのデータに基づく（Faros分析）
- 開発者はAI生成コードのレビューには、同僚のコードレビューよりより多くの労力が必要だと感じている
- 手動コードレビューではこの戦いに勝てず、コードレビューは現在の作業形態に合わない過去の承認ゲートである
AIコードレビューも依然として「レビュー」にすぎない
- AIがコードを書き、AIがレビューするなら、見栄えのよいレビューUIを出す理由はない
- AIコードレビューツールは時間を稼いでくれるだけであり、こうしたレビューは**開発サイクルの左側（shift left）**へ移動していく
- CIリソースを無駄にし、レビューサイクルの合間にバージョン管理を行う理由はない
- エージェントがコードを書く環境では、「新しい目」とは同じ盲点を持つ別のエージェントにすぎず、価値は承認ゲートではなく反復ループにある
- 「一度AIが間抜けなことをするのを見たのだから、常に確認しなければならない」という本能は、手動検証が可能だった時代には合理的だったが、現在の規模ではもはや実行不可能
コードレビューから意図（Intent）レビューへ転換
- 人間のチェックポイントは**上流（upstream）**へ移動させるべき
- ソフトウェア開発ではチェックポイントが移動してきた前例がある：ウォーターフォールのサインオフ → 継続的インテグレーション（CI）
- **仕様駆動開発（Spec-driven development）**がAI協業の主要な方式として台頭している
- 人間は仕様、計画、制約条件、受け入れ基準をレビューすべきであり、500行のdiffをレビューする必要はない
- 新しいパラダイムでは、**仕様が信頼できる唯一の情報源（source of truth）**となり、コードは仕様の産物となる
- コードをレビューするのではなく、ステップと検証ルール（verification rules）、コードが満たすべき契約（contract）をレビューする
- Human-in-the-loopの承認は「これを正しく書けたか？」から**「正しい制約条件で正しい問題を解いているか？」**へ移る
- 最も価値ある人間の判断は、コード生成後ではなく最初の1行が生成される前に発揮される
多層の信頼を構築する — スイスチーズモデル
- LLMは指示にうまく従わず頻繁に逸脱し、自己検証すら信頼できない（コードが燃えている最中でも自信満々に「動く」と答える）
- 解決策はLLMに検証を頼むことではなく、検証するスクリプトを書かせること — 判断から成果物への転換
- 信頼は層として積み上げる構造であり、スイスチーズモデルに従って不完全なフィルターを何層にも重ね、穴が一直線に並ばないようにする
Layer 1: 複数案の比較
- 1つのエージェントに正解を求める代わりに、3つのエージェントに異なる方法で試させ、最良の結果を選ぶ
- 選択は手動である必要はなく、最も多くの検証ステップを通過したもの、最小のdiff、新しい依存関係を追加しないものなどの基準で順位付けできる
- 選択肢のコストはソフトウェアエンジニアリング史上最も低い水準にある
Layer 2: 決定論的ガードレール
- 作業を検証する決定論的な方法が必要 — テスト、型チェック、契約検証など、意見ではなく事実だけを扱うもの
- LLMに「これできた？」と尋ねる代わりに、一連のpass/fail成果物を生成する検証ステップを定義する
- ガードレールの階層構造：
- コーディングガイドライン — カスタムリンターで実装可能
- 組織全体の不変ルール — ハードコードされた認証情報、APIキー、トークン禁止などの交渉不可事項
- ドメイン契約 — フレームワーク、サービス、コードベース領域ごとのルール（例：決済ドメインではすべての金額にMoney型を使用）
- 受け入れ基準（Acceptance Criteria） — タスクごとの固有基準
- 検証ステップはコードを書く前に定義すべきであり、すでにあるものを確認するために後から作るべきではない
- エージェントがコードとテストの両方を書くなら、問題を移動させただけにすぎず、検証基準は実装ではなく仕様から出るべき
Layer 3: 人間が受け入れ基準を定義する
- 人間が価値を加える地点は、上流で成功の定義を与えることにある
- **BDD（Behavior-Driven Development）**が新たな関連性を持つ
- 自然言語で期待される振る舞いを記述し、それをテストとして自動化する方式
- 以前はコードも書かなければならなかったため、仕様作成が追加作業のように感じられたが、エージェント環境では仕様が一次成果物になる
- 人間が仕様を書き、エージェントが実装し、BDDフレームワークが検証する — 失敗しない限り実装を読む必要はない
- 人間が得意なのは、「正しさ」の定義、ビジネスロジックとエッジケースのエンコード、何が問題になりうるかを考えること
- 人間が書き、機械が検証する受け入れ基準こそが本当に重要なゲート
Layer 4: 権限システムをアーキテクチャにする
- エージェントが何に触れられ、何がエスカレーションを必要とするかは、アーキテクチャ上の意思決定であるべき
- ほとんどのエージェントフレームワークは権限を**オールオアナッシング（all-or-nothing）**で扱うが、細分化が重要
- ユーティリティ関数のバグを修正するエージェントに、インフラ設定へのアクセス権は不要
- テストを書くエージェントに、CIパイプラインの変更権限は不要
- 範囲は、エージェントが有用な作業をできる限りでできるだけ狭くすべき
- 例：「utils/dates.pyの日付パースのバグ修正」というタスクなら、そのファイルとテストファイルのみアクセスを許可
- エスカレーショントリガーも重要：認証ロジックの変更、データベーススキーマ変更、新しい依存関係の追加など、特定のパターンはエージェントの確信度に関係なく自動的に人間のレビューを発火させる
Layer 5: 敵対的検証
- 責任の分離：1つのエージェントが作業し、別のエージェントが検証する — 互いを信頼しないことが核心
- QAチームがエンジニアリングマネージャーに報告してはならず、コード作成者だけがレビューしてはならないのと同じ古くからあるパターン
- アーキテクチャとして強制可能：コーディングエージェントは検証エージェントが何を確認するかを知らず、検証エージェントはコードを修正できない — 設計上、敵対的
- さらに進めるなら、3つ目のエージェントが1つ目のエージェントの成果物をエッジケースや失敗モードを狙って破壊しようとする — すべての変更にレッドチーム/ブルーチーム自動化を適用する
「良いコード」の意味が変わりつつある
- エージェントシステムのインセンティブは単純で、与えられたタスクを完了し、指示した人を満足させること — 長期的な正確性やビジネス要件が本質的な動機ではない
- これを制約条件にエンコードすることが人間の役割
- エージェントが生成し、エージェントが読むコードでは、「良いコード」の形はより標準化され、新しいコードベースで提供すべき方向付けは減っていく
- 未来の方向性：「速くデプロイし、すべてを観測し、さらに速く戻す」
- 対照的なのは、「ゆっくりレビューし、どうせバグを見逃し、本番でデバッグする」
- 機械をより多く読んで勝つことはできず、判断が本当に重要な上流で機械を上回る思考が必要
- エージェントがコードをうまく扱えるなら、人間がそのコードを読めるかどうかはもはや重要ではない
25件のコメント
コードレビューがボトルネックだから、レビューをしないことにしようっていうのは斬新すぎて笑えますねｗｗｗｗｗｗ
AI以前は、そもそもコードレビューが本当にうまく機能していたのか、みんな気になっているのではないでしょうか。
コードレビューを素早く熱心に行う組織は、実際かなりまれでした。
多くの開発者は、AI以前からコードレビューが怠慢で、滞りがちで、雑でした。
私の経験では、米国のテック企業は教科書どおりで、国内を含む海外はひどいものでした。
逆に言えば、レビューが徹底しているほど業務ストレスは大きく、ひどいレビューは比較的ゆるかったです
レビューがなくなるのは、行動への報酬の結果だと思います。
会社が求めているのが
低いエラー率ならレビューをより強く求めるでしょうし、
機能の迅速なリリースならレビューは次第に省略されていくでしょう。
レビューがなくなるという話は、企業が好むのは機能の迅速なリリースだと感じますね。
でも、私が投資家でもそう求める気がします（笑）
よく分かりません。レビューがボトルネックになったからといって、レビューをしないようにするのは本分を忘れているように思えます。むしろ、実装時間が短くなった分だけレビュー時間を必須で割り当てるほうが良い方法になるのではないかと思います。
試してみる価値のある発想ではありますが、まだ時期尚早だという見方が支配的なようですね
ブラックボックスを積み上げ続けようってこと？
コードはただブラックボックスのように作っておいて結果だけ見よう、という話ですが……果たしてこれが望ましい方向なのかは疑問です。私は、いつか既存のAI作成コードを全面的にひっくり返す時が必ず来ると思います。
「FSDが賢くなったのだから、ドライバーは眠っていてもよい」と言うのと似たような問題として考えられますね。
技術的には次第にそういう時代が来る気はしますが、果たして責任というハードルをどう乗り越えるのかが重要だと思います。
私はコードレビューが最低限の安全装置ではないかと思います。
より上位の概念である意図の検証は、なぜ人がやるんでしょうか……？
実際、プログラミング言語でコーディングさせる必要すらないでしょう
AIに同じプロンプトを渡すとしたら、その成果物をレビューするというのは、モデルの性能をテストすることに近いのではないか、という気がしますね。
結論を先に決めておいて、LLMに書かせたように見える。詭弁だ。
プロダクション経験がまったくないように見える
ただの夢みたいな話ですね。
時間が経つほど、ドキュメント化にもあまり意味がなくなって、レビューも厳格にやるようになるのでは？
そうですね〜。こんな議論を生み出して考えさせる文章というだけでも、意図は十分伝わっていましたね。
翻訳記事です: https://rosetta.page/post/…
そもそもplan段階で弾ける問題なんですよね
コードを手で書く過程では、開発者は自然に企画もし、設計もし、探索もし、理解もし、テストもし、セルフレビューもし、問題が発生したときの事後対応までを暗黙的かつ並行的に進めながら、各側面を自然に調整しているものです。だからこそ、テストやレビューが多少不足していても、ある程度は回っていたのだと思います。
しかし手で書く過程をなくしてしまうと、暗黙的に存在していたプロセスに明示的な境界を設けなければなりません。コードを書いた主体とレビューする主体がさらに分離されるため、コミュニケーションの非効率も増します。コード作成主体への信頼もより低くなるので、レビューコストもまた増加します。
doorman's fallacyという概念に近いのではないかと思います。私も会社でよく悩んでいたテーマですが、いいですね。個人的に作っているハーネスにも導入してみるべきだと思いました
レビューは徐々に簡素化し、その分テストを厳格にしていく方向へ少しずつ移っていくのではないかと思います。
単にコードレビューをなくそうというのではなく、より上位の概念である意図と、その意図が正しく機能したかを明示的に確認できる成果物を対象にレビューしよう、ということのようですね。
現時点では、設計・アーキテクチャレベルではなく、コード実装のディテールをブラックボックスとして維持することは望ましいと思います。
そのブラックボックスが積み重なって、AIですらまともに手を付けられない状況にまでつながることもあり得ると思います。みんな利便性に酔いしれすぎている気がします。いつか大きな事故が起きると思います。
私も上の方の意見に同意します。ある日突然、モデルが人間のコードのうちどこかを誤って学習していた部分が見つかり、それがこれまでコードに反映されていたことに気付いたら？ その日がすべてをひっくり返す日になるかもしれません..
どれだけ最新モデルが優秀でも、SWEベンチマークで満点を「常に」（6 nine, 0.999999）取れないなら、可能性は開かれていると思います。
意図レビュー。いい言葉ですね。
AIによって高速化する時代にどう対応すべきか悩んでいたのですが、
コードレビューに対する新しい視点を与えてくれる良い文章です！