AI が生成したコードの量増大がエンジニアのレビュープロセスを変化させる

AI コーディングツールは、数分で数千行のコードを生成できるようになり、企業は機能の実装やテスト実行、不具合の修正を以前よりも迅速に行えるようになりました。しかし、AI が生成したコードが洪水のように溢れていても、最終的には人間によるレビューが必要です。大規模言語モデル（LLM）は表面にはきれいなコードに見えるものの、誤った前提条件、セキュリティ上の脆弱性、あるいはデプロイ後に初めて現れる微妙なバグといった、 sloppy なミスを隠し持っていることがあります。これらの問題を修正すれば、AI が約束する生産性の向上が台無しになってしまう恐れがあります。

企業は AI によって生成された「コードのゴミ（スロップ）」への対応として、コードレビューの方法を見直しています。新しい戦略も次々と生まれています。例えば、AI がコーディングを開始する前に計画を精査したり、専門的な AI エージェントを導入して一般的な欠陥を検出させたり、リスクの高い変更は人間がレビューするようにしたり、開発者が AI エージェントが生成したコードに対して説明責任を負うようにしたりするといったアプローチです。

この変化は、AI 生成コードの急増がエンジニアチームに新たなプレッシャーを与えている最中に訪れました。AI コード検証スタートアップである Sonar が実施した 1,100 人以上の開発者への調査では、回答者の推計によると、共有リポジトリに追加されたコードの 42% が AI の貢献によるものでした。しかしながら、開発者は AI をコードの説明やプロトタイピングには有用だと感じていたものの、その出力が正しく動作することに対して 96% が完全に信頼していないことが明らかになりました。

投資家たちは、このギャップを埋めることに大きな機会を見出しています。例えば 8 月には、AI コードレビュー専門のスタートアップである CodeRabbit が、17,000 社もの顧客（Nvidia、Indeed、BMW グループなど）に対して週に 200 万件以上のレビューを実施していると主張し、評価額 15 億ドルで 1.43 億米ドルの資金調達を行いました。

コードレビューの新時代は、AI が「より速く」かつ「より信頼性の高い」コードを提供できるかどうかを決定づけるものとなるでしょう。同時に、ソフトウェアエンジニアの間では自らの職業の未来について考える声も上がっています。「エントリーレベルのエンジニアが自らコードを書く時間を減らせば、どのようにしてコードを判断する力を身につけていくのか」という問いです。

AI コードレビューのボトルネック

AI によって生成されたコードは、ソフトウェア開発におけるボトルネックを「生成」から「レビュー」へとシフトさせています。Sonar の調査によると、開発者の 38% が AI 生成コードのレビューには同僚が書いたコードよりも多くの労力が必要だと回答しました。また、61% は「AI は一見正しく見えるが、実際には信頼性に欠けるコードを頻繁に生成する」と指摘しています。

AI 動画生成プラットフォームの Synthesia にとって、コードレビューはエンジニアリングワークフローにおいて不可欠な要素となっています。2025 年 11 月、Synthesia のエンジニア 118 名が Claude Code などの AI コーディングツールに全振りしました。同社の最高技術責任者（CTO）である Peter Hill 氏によれば、その結果としてコードの生成量が劇的に増加したといいます。

「AI が自律的に生成するコードを本当に信頼できる状態になる日が来るのか、私にはまだわかりません。」——Peter Hill, Synthesia

そのコードは慎重な検証を要します。ヒル氏によると、8 月時点でのプルリクエスト（コードベースへの提出された変更提案）の数は前年比で 120% 増加しており、その 95% に AI が生成したコードが含まれています。

繰り返される問題の一つは重複です。ヒル氏は、AI ツールがすでに存在するタスク用のコードを認識できず、文脈の制限から別のバージョンを書いてしまうことがあると指摘しています。Synthesia では、同じ関数のバリエーションが最大 10 個見つかるケースもあり、エンジニアが冗長な関数を特定して削除する必要があります。その作業が終われば、同様のミスを防ぐために AI エージェントを再トレーニングします。同社の規模において、ヒル氏は「AI に意図した出力を得させるには膨大な労力が必要だ」と述べています。

コードレビューワークフローにおける AI エージェント

一部のチームでは、AI が一行もコードを書き始める前にレビュー上の問題を未然に防ぐ取り組みを行っています。

Amazon Stores のシニアプリンシパルエンジニアであるマクラーレン・スタンリー氏は、17 年にわたる Amazon のモバイルショッピングアプリの基盤コードを近代化するために AI を活用しています。彼の 70 人規模のチームは、機能を構築するためのアーキテクチャ的バックボーンを維持することで、1,000 人以上の開発者を支えています。スタンリー氏によれば、AI がコードを書くことで、エンジニアたちは生成が始まる前に「何をすべきか」を決定する時間が増えているそうです。

その作業の多くは、「仕様書」の作成です。これは AI エージェントが何をどのように構築するかという詳細な計画のことです。コード生成前に繰り返されるミスを防ぐことは、結果的にエンジニアの時間を節約することにつながります。

スタンレー氏は、指示の抜けが原因でエージェントが誤ったバージョンのスウィフト言語で 25,000 行ものコードを生成してしまった事例を思い出します。バージョンを切り替えたことで、一度に修正できない 600 のエラーが発生しました。スタンレイはコードを破棄し、仕様を更新してエージェントを再起動させます。すると 15 分後には、正しいコードが再生成されました。

コードが完成した後は、専門的な AI エージェントが人間が入る前に最初のチェックを担当します。

AWS（Amazon Web Services）のシニアプリンシパルエンジニアであるデイビッド・ヤナセク氏は、同社ではエージェントを使って、コードが動作するかテストしたり、元の計画と照合したり、セキュリティ上の欠陥がないか確認したりすることを、人間によるレビューの前に行っていると語っています。

AI 生成コードの量が増えるにつれて、この最初のパスはより重要になります。非営利ソフトウェアプロバイダーである Bonterra では、エンジニアが約 290 名いますが、CTO のタヌージャ・コルプレア氏によると、AI を導入してから 3 ヶ月間で提案された変更件数が 3 倍に増えました。レビュー対象となるコードは 10 倍になり、レビュー時間も 3 倍となりました。これにより、エンジニアがすべての行を精査するのは現実的ではなくなっています。

「私たちは、コードレビューがチェックされていないモデルの出力を受け入れるゴミ箱になることを許しません。」—サマル・アバス（Temporal）

Bonterra のエージェントは、コードを承認された設計、セキュリティルール、コーディング規約、アクセシビリティ要件と比較し、結果に対する自信度を報告します。スコアが低い場合や問題が検出された場合は、変更は人間に引き継がれます。支払い処理、個人情報、またはその他の機密システムに関わるコードについては、必ず人間のレビューが行われます。

「コードの読み込みはエージェントが、判断は人間が行う」とコルプレア氏は語る。

Synthesia もまた、AI エージェントを活用して、どこで人間のレビューが必要かを判断しています。エンジニアが設定した基準に基づき、リスクの高い変更にはより厳重な審査が課されます。エラーメッセージの修正は、顧客データを扱うコードや中核となるビジネスルールの変更と比べればリスクは低いです。それでもなお、5% 未満の変更しか人間によるレビューをスキップしていません。

「いつか、生成されたコードを本当に信頼できる段階に到達するのだろうか」とヒル氏は疑問を呈します。

自動レビューが行われても、最終的なコードに対する責任の所在が変わるわけではありません。

ソフトウェアコンサルティングファーム Making Sense のチーフ AI アーキテクトである JD Raimondi 氏によれば、機械が生成するコード量がエンジニアが精査できる範囲を超えると、人間の承認は「形だけの承認」になりかねないと指摘しています。つまり、エンジニアは機能が動作することを確認し、コードをざっと読み、その背後にある判断の根拠を理解しないまま承認してしまう可能性があるのです。

オープンソースの開発プラットフォームである Temporal は、コード提出者自身に責任を負わせる方針をとっています。CEO のサマル・アバス氏は、AI の導入によりコード量とレビューにかかる時間がともに増加していると述べています。同社の「Send Back（差し戻し）」ポリシーでは、エンジニアはエージェントの設計判断や、予期せぬ状況への対処方法を自らの言葉で説明しなければなりません。そうでなければレビュアーは却下します。

「私たちは、コードレビューを管理されていないモデル出力の捨て場にしてはならないと拒否しています」とアバス氏は語っています。

新人エンジニアに対する AI のトレーニング

AI の台頭により、エンジニアの業務はコードを書くことから、それを評価する方向へとシフトしています。これに伴い、企業は新人エンジニアがどのようにして経験を積むべきかを見直しています。

Making Sense 社のジュニアエンジニアたちは、AI によって最も大きな生産性向上を遂げている一方で、Raimondi は彼らが「手を動かす」ことで得ていた学習機会が減っていることへの懸念を示しています。同コンサルティングファームでは、新人が顧客のニーズや機能の実装方法を決めるプロセスに関与させ、単に AI の出力をチェックするだけにとどめないよう工夫しています。

IBM では、AI を活用して新入社員に早期から難易度の高い課題を与えています。自動化と AI 担当のゼネラルマネージャーである Neel Sundaresan 氏によると、近年の卒業生たちは、以前はシニアエンジニア向けだった製品機能やプロジェクトに取り組んでいます。AI がコードの実装とテストを支援しますが、もし失敗した場合、新人が原因を特定し修正した上で、最終承認のためにシニア開発者に引き継ぎます。Sundaresan 氏によれば、AI はかつてシニアエンジニアが必要だったタスクの 70〜80% を新人が遂行できるよう支援できるとのことです。

Synthesia 社は主にミドルおよびシニアレベルのエンジニアを採用しています。経験の浅い社員は、シニアの同僚と AI エージェントと共に働きながら、プロジェクトの一部を担当し、同時に「成功したコードとは何か」を定義する力を養っています。

Bonterra では、これまで新人エンジニアの教育に用いられていた明確なコーディングタスクの多くを、現在ではエージェントが担当しています。新人は熟練した同僚と共に成果物の責任を負う立場となり、エージェントへの指示や出力に対する疑問提起、そして最終結果に対する責任の所在を明確にする学習を行います。このアプローチにより、新人エンジニアはキャリアアップに必要なスキルと知識を築くことができると同氏は述べています。

「業界が新人の採用を止めてしまえば、業界はシニアを生み出すことをやめることになる」と、Korlepra 氏は指摘しています。