AI が記述したコードは誰がレビューするのか?

Lee Boonstra
Software Engineer, Office of the CTO
AI 駆動型開発の普及により、ソフトウェア開発におけるボトルネックはコードを書くことからレビューすることへとシフトしました。その結果、人間のワークロードを管理するための新たなガードレールが求められています。
Google の CTO オフィスは、人間と AI エージェントが実際の業務で協業するハイブリッド モデルで運営されています。近年、ソフトウェア開発のスピードは飛躍的に向上しました。しかし、その圧倒的なスピードによって、予想だにしない課題が浮き彫りになったのです。ソフトウェアのリリースにおけるボトルネックが、コードを書くことからコードをレビューして統合することへとシフトしたのです。
膨大な pull リクエストから得た教訓
以前、ダッシュボードの全面的な刷新を含む、自社エージェントの大規模な機能開発に何日も没頭していました。このときの pull リクエスト(PR)は膨大でした。変更箇所の画面は何回スクロールしても終わりがなく、もはや 1 人のレビュー担当者がそのすべてを把握できるレベルを超えていたのです。コードを管理しやすいサイズへの分割も試みましたが、既存のワークフローは、AI が絶え間なく生成するコミットの量に対応できるように設計されていませんでした。
さらに、複数のデベロッパーが同一ファイルを同時に編集したことで、マージ コンフリクトが多発しました。そして、解きほぐせないほど複雑な依存関係の連鎖が生じてしまったのです。例えば、PR 1 は PR 2 なしではマージできず、PR 2 には PR 3 が必要なものの、PR 3 は時差のある別のレビュー担当者の承認待ちになっている、という具合です。一方で、PR 4 は簡単なものだったため、先に承認されてしまいました。関連する変更がレビュー待ちのまま放置されている間に、一部の変更だけが承認されてしまい、それがさらに深刻なコンフリクトを引き起こす泥沼に陥ったのです。
週末を迎える頃には、システム全体としてテストできるものは何もなくなっていました。メインブランチは壊れ、ステージング環境はアラートが鳴り響く混沌とした状態に。チームチャットはお互いを慰め合うだけの相互サポート グループと化していました。
日々の業務において、これは次の 3 つの形で顕著に現れました。
-
マージ コンフリクトの多発:わずか 1 時間の間に、複数のデベロッパーが同じファイルに変更を加えてしまう。
-
レビューの停滞:巨大な PR のなかに、マトリョーシカ人形のように無数のサブ PR が入れ子構造で埋め込まれ、身動きが取れなくなる。
-
コンテキストの断片化:自分がコーヒーを飲んでいる間に、チームメイトが共有ファイル内の変数をリネームしてしまう。すると、あなたのエージェントは、前日のスナップショットを引用して、存在しなくなった関数を呼び出すコードを生成してしまう。
開発スピードが加速しても、コードの総量に対するバグの発生比率は変わりません。ただ、誰が責任を負うのか、そして破綻の瞬間がどれだけ早く訪れるかが変わるだけです。この状況を乗り切るために、私たちは 3 つの重要な教訓を引き出しました。
-
技術的なガードレール:構文リンター、静的解析ルール、スキル定義、そして AI によるテストコードの自動生成を義務化し、超高速開発を支えるための安全網を構築しました。
-
オーナーシップの再定義:AI が書いた使い捨てのコードのスタイルを人間が細かくチェックすることをやめ、アーキテクチャの設計図に注力するようにしました。また、時差のあるグローバル チームにおいては、12 時間ものタイムラグを解消するために、「条件付き LGTM(テストのパスを条件に PR を承認するルール)」を導入しました。
-
AI によるレビュー ガイド:現在、すべての PR に、AI が生成した変更点の要約、システム破損のリスク予測、そして、リスク評価スコアが同梱されるようになっています。これにより、人間のレビュー担当者は、コードの全体像を見失うことなく、本当に重要なことに集中できるようになりました。
燃え尽き症候群と「承認疲れ」の防止
現場では「承認疲れ」という新たな現象が発生しています。CNBC が報じた Quantum Workplace の調査によると、AI を頻繁に使用する人は、そうでない人よりも燃え尽き症候群に陥る可能性が 45% も高いというデータがあります。そしてこれは、私たちのチームでも起きていました。細かな承認リクエスト(1 行だけのコード修正や、ツール呼び出しの微調整など)が絶え間なく続くと、デベロッパーは反射的に「承認」をクリックし始めてしまいます。これは、AI のペースに追いつこうとするあまり、成果物の正当性をチェックすることを放棄してしまうという、一種の疲弊状態と言えます。
私たちはチームを守るために、エージェントを常に監視するのではなく、構造化された境界線を設けることにしました。具体的には、デジタル クワイエット アワー(デジタル通知オフ時間)を設定し、承認リクエストが夜間や週末にまで及ばないようにしました。また、「エージェント インサイト セッション」を毎週開催し、デベロッパーたちがそれぞれの AI パートナーの行動パターンから得た知見を共有することで、個人の気づきを組織全体のナレッジへと変えています。
ガードレールのないエージェントが暴走するとどうなるか
これまでは、コードのレビューと統合の局面について取り上げてきました。しかし、エージェントに適切なガードレールを適用しないまま実環境で動作させた場合、どうなるかについて、私たちは苦い経験から学んだもう一つの教訓があります。
日常的なコード アップデートの作業中に、Antigravity の組み込み UI ブラウザの素晴らしい可能性と恐ろしい限界の両方が明らかになりました。この機能は、AI エージェントがログイン認証情報なしで開発中のアプリケーションを操作できるというもので、UX テストを自動化する上で非常に役立ちます。しかし、これを YOLO(自動承認)モードで実行すると、人間が考えるよりも遥かに速いスピードで次々とアクションを実行に移してしまうのです。
ボタンを 1 つ作成するというシンプルなプロンプトが、予期しない連鎖反応を引き起こしてしまったことがあります。新しく作成したそのボタンをブラウザ エージェントが自律的にクリックしてしまったのです。このボタンは、本来はメール送信エージェント用のものでした。URL の指定がなかったため、エージェントはハルシネーションを起こし、メールの安全対策が施されていない、廃止されたレガシー エージェントに接続してしまったのです。その結果、同僚 50 人に対して、ハルシネーション コンテンツが満載のでたらめなメールが誤送信されてしまいました。
この件で浮き彫りになったのは、私が今では「コンテキスト ハルシネーション リスク」と呼んでいるものです。AI は、十分なデータがなかった場合、コンテキストに存在する文字列を手当たり次第に流用してギャップを埋めようとすることがあります。これには、ハードコードされたメールアドレスや URL などの機密情報が含まれるケースもあります。
「たかがメール一通じゃないか」と笑い話に思われるかもしれません。しかし、エージェントが実際に取った「行動の本質」を考えてみてください。エージェントは、指示を満たすために利用可能なデータを盲目的に使って突き進みましたが、その処理が適切かどうかを判断するロジックを持っていなかったのです。これこそが、自律型システムが抱える中核的なリスクです。人間参加型でなかったり、ポリシー エンジンによる統制がない場合、エージェントは、手当たり次第にデータを使用して、ゴールに向かって最適化しようと突き進んでしまいます。ガードレールは、あれば便利なオプションではありません。ガードレールによって、便利なツールの予測不可能な動きを防止できます。
この一件を受け、私のチームではすぐに以下の改善策を講じました。
-
ツールを実行する前に権限の検証を必要とするポリシー エンジンを導入してゼロトラスト モデルを実装すること。
-
テンプレート内で名前やメールアドレスなどの個人情報(PII)をすべて {{PLACEHOLDER}} へと自動置換することで、厳格な「コンテキスト ハイジーン」を実践すること。
結局のところ、エージェントは見えないものを誤用することはできません。それから、レガシー エージェントもようやく削除することに決めました。
ボトルネックのシフト
ほんの 1 年前と比較しても、ソフトウェアの開発サイクルは劇的に高速化しました。毎朝、私の体に最初のレッドブルが効いてくるよりも早く、エージェントがドキュメントを網羅した高品質な 1,000 行のコードを出力してくれるのは素晴らしい体験です。
しかし、その圧倒的なスピードの代償として、私たちは重要な真実に直面することになりました。AI がコードを書くというこれまでのボトルネックを解消した結果、次なる制約は、その大量の成果物を人間がすべてレビューし、テストし、システムへ統合するという下流工程に移ったのです。この問題は、プロンプトの改良や AI モデルの処理速度を上げることで解決するものではありません。必要なのは、チームの協力体制を進化させ、コードレビューのあり方を見直し、そして「休むことのないツール」と人間の間に適切な境界線を敷くことなのです。
ボトルネックが解消されたのではありません。コードを書くことから、それを人間がレビューすることへと、その場所を移しただけなのです。
※この投稿は米国時間 2026 年 4 月 29 日に、Google Cloud blog に投稿されたものの抄訳です。
- CTO オフィス、ソフトウェア エンジニア、Lee Boonstra



