米国の大手テクノロジー企業の多くでは、毎週リリースされるコードの大部分を機械が書くようになっています。エンジニアの仕事はAIが生成したコードのレビューへとシフトしており、そのレビューではAIへの高評価が並んでいます。リーダー層は、AI生成コードを自社エンジニアが書くコードよりも品質が高いと評価しており、その明快な構造、統一されたスタイル、提出時点での明らかなバグの少なさを称賛しています。
しかし、同じコードが実際に動き出すと、話は変わります。過去1年で本番環境でのインシデントは増加しており、シニアエンジニアたちはAIが生成したコードの修正に費やす時間が増え続けています。多くの組織では、過去6か月間にAIコードが原因で少なくとも1件の本番障害が発生しており、リリース後すぐに修正対応を迫られるケースも相当数に上っています。
検証より先に訪れる信頼
この問題の根本には、早い段階で形成される信頼があります。多くのチームが、AI生成コードをコードを一行ずつ確認せずに本番環境へデプロイすることが多いと答えています。コードが読みやすいためレビューを素通りしやすく、本来であればセキュリティ上の欠陥を発見できるはずの検査工程が機能しなくなっているのです。
LLMが生成するコードは、クリーンで予測可能な条件下では正常に動作します。弱点が現れるのは、エッジケース、並行処理、非推奨APIの呼び出し、複雑な状態変化といった場面です。こうした問題はソースコードの中に潜んだまま、実際のユーザーがシステムを利用したときに初めて表面化します。プルリクエストを確認するレビュアーが、これらを見つけ出せる可能性は非常に低いと言わざるを得ません。
負荷がかかって初めて現れるセキュリティ上の欠陥
過去6か月間で、新たに持ち込まれたセキュリティ脆弱性の影響を受けた組織は約3割に上っています。インテグレーション障害、コンプライアンス上の問題、データ整合性の問題も同様の割合で発生しており、ほとんどの組織がこの期間に少なくとも一つの障害事例を抱えており、複数の事例を持つ組織も少なくありません。
New Relicの調査によると、AI生成コードはピアレビューを経た人間作成コードと比較して、重大なランタイム問題を約2倍の頻度で引き起こしているとのことです。障害は多数の小さな問題が同時多発的に広がる形で発生します。それぞれの問題は本番データに痕跡を残します。スキーマのずれやサービス間のエラーレート上昇はインテグレーションの破綻を示し、認証やトレースデータの不審なパターンはセキュリティ上の脆弱性を露呈させます。共通しているのは、これらの兆候がいずれもデプロイ後、つまりレビュー段階をとっくに過ぎた時点で現れるという点です。
レビュー時の検査が持つ限界
レビュアーが読むのはソースコードです。一方、本番環境が生み出すのはトレースデータです。ソースコードはコードがどのように構築されているかを示しますが、トレースデータはそのコードが実際の負荷、実際の依存関係、実際のエッジケースのもとでどう振る舞うかを示します。AIコーディングツールはソースコードのみからコードを生成しており、ランタイムの状況を把握できません。この乖離こそが、AIコードがレビューで受ける高評価と実際の本番環境での振る舞いとの差を生んでいる理由です。
後始末を担うのは経験豊富なスタッフです。サイト信頼性エンジニアやDevOpsエンジニアたちは、検証不十分なまま本番環境に達した機械の出力をトリアージし、リファクタリングする作業に、週の労働時間の最大3分の1を費やしていると報告しています。本来であればより難易度の高い課題に充てられるはずの、チームの最上位層が担う時間が失われているのです。
オブザーバビリティの早期化
調査対象のリーダーたちの間では、オブザーバビリティへの支持がほぼ全会一致の水準に達しています。彼らはランタイム監視をAI生成コードには欠かせないものとして位置づけており、ログやトレースといったテレメトリをコードに直接組み込むようAIにプロンプトで指示するケースも増えています。何をログに記録し、何をアラートの対象にするかという判断が、開発者のプロンプト作成という上流工程へと移行しつつあります。
こうした動きの背景にあるスピード向上の恩恵は本物であり、その成果は収益にも反映されています。だからこそ採用が拡大し続けているのです。AIが書いたコードは多くの組織で正式な本番ポリシーの対象となっており、シニアエンジニアのコードと同様に顧客向けサービスにも適用されています。調査対象の組織の中で、この慣行を禁止しているところは一つもありませんでした。
翻訳元: https://www.helpnetsecurity.com/2026/06/15/ai-generated-code-review-issues/
