コーディングエージェントは「PRレビューの非対称性」を逆転した
なぜ、AIを導入したにもかかわらずこのような事態に陥ってしまったのか。この疲弊の根本的な原因について、「これまで人間のために作ってきた仕組みに、AIを部分的に導入したことで生じた構造的な歪み」であると宇佐美氏は指摘する。この歪みのメカニズムを最も象徴的に表しているのが、前述した「PRのレビュープロセスの崩壊」だ。
従来のソフトウェア開発において、PRによるコードレビューの仕組みは、コードを作成する側のエンジニアと、それを審査する側のエンジニアの間に存在する「コストの非対称性」の上に成り立っていた。
新しい機能を実装し、ビジネス要件をコードに落とし込み、テストを書き、手元で動作確認を行う。PRを作成する側のコストは、数時間から数日間を要する極めて重厚なものだった。
一方、レビューを行う側のコストも決して軽くはないものの、ゼロからシステムを生み出す苦労に比べれば、相対的な負担は小さかった。この「作る側が重く、見る側が軽い」という非対称的なバランスがあったからこそ、「多大な苦労をして作られたコードに対し、レビュアーは敬意を持って丁寧に審査する」という開発文化と業務フローが機能していた。
AIコーディング登場以前のPRレビュー
しかし、コーディングエージェントの本格的な普及は、この前提を根底から破壊した。プロンプトに要件をまとめて投げるだけで、一定以上の品質を保ったコードが瞬時に生成されるようになったのだ。これにより、作る側のコストは劇的に低下し、一人のエンジニアが1日に提出できるPRの数は飛躍的に増加した。
一方で、レビュー側のプロセスやポリシーは旧態依然としたままであった。多くの企業では、「AIが生成したコードであっても、人間が書いたものと同様に他のエンジニアが1行ずつ目視で確認し、品質を担保しなければならない」というポリシーを採用している。背景の文脈を読み解き、コーディング規約に沿っているかを確認し、拡張性やセキュリティの脆弱性に目を光らせる。
AIコーディング登場以後のPRレビュー
このような状況下で何が起きるか。「エージェントに書かせるよりレビューをしている方が圧倒的にコストがかかります。そのため、慢性的にずっとレビューが追いつかないという状態が続いています。」と宇佐美氏が語る通り、生成のペースに対してレビューのペースが全く追いつかず、キューが常に溢れ返る状態が常態化してしまったのだ。
その結果、皮肉なことに、責任感が強く、真面目で経験豊富なシニアエンジニアほど、押し寄せる大量のコードレビューに真正面から立ち向かい、より疲弊していくという最悪の構造に陥っている。
この構造的な問題に対する本質的な解決策は、人間を前提とした既存の業務フローを力技で延命させることではない。「人間前提の仕組みにAIを部分的に入れるのではなく、AI前提で仕組み全体を再構築したい。」と宇佐美氏は強く主張する。業務フローの片側にだけAIを導入すれば、必ず残された人間側がボトルネックとなる。これはQA（品質保証）や承認フローなど、あらゆる組織内のプロセスに共通する現象だ。
AIを部分導入することによる弊害
具体的にどのように仕組みを再構築すべきか。例えばPRのレビューにおいて、作成側にAIを入れたのであれば、審査側にもAIを導入するべきである。AIによる静的コード解析はもちろんのこと、探索的なE2E（End-to-End）テストを実行するエージェントを導入する。これらの厳密な自動テストを通過したコードは、人間の目を通さずに自動的にメインブランチへマージし、本番環境へとデプロイしていく仕組みを構築するのだ。
もちろん、人間の確認なしで本番環境に変更を加えることに対する恐怖感は根強い。そのため、これらを安全に運用するには新たな品質保証のパラダイムが必要となる。デプロイしっぱなしにするのではなく、システムの稼働状況やエラー率、パフォーマンスメトリクスを常時監視する別のAIエージェントを走らせておく。そして、少しでも異常を検知した瞬間に、システムを自動でロールバックさせる仕組みを組み込む。
事後検知・自動復旧できる新しい開発フロー
つまり、「事前の目視によってバグの混入を100%防ぐ」という従来のパラダイムから、「包括的な自動テストと事後監視によって、問題が発生しても瞬時に検知・復旧させる」というパラダイムへと、品質保証の概念そのものを転換させなければならない。
アーキテクチャの根幹に関わる部分やセキュリティのコアロジックなど、本当にクリティカルな変更の場合のみ人間にエスカレーションする仕組みを整えれば、エンジニアを大量のレビュー作業から解放し、システムの安全性を担保することは十分に可能だ。
