「AIが書いたコードは人間より優秀」――だが本番で壊れる、なぜか？：「レビューでは高品質」の落とし穴

AIコーディングの実践拡大に伴い、開発現場では品質管理の課題も顕在化し始めている。New Relicの調査では、AI生成コードに対する評価が高いことが分かったが、一方では本番環境では問題への対応に追われている状況も明らかになった。

[＠IT]

　AI（人工知能）が生成するコードの比率は、既に無視できる水準ではない。New Relicは2026年6月10日（現地時間）、ソフトウェア開発におけるAIコーディングの利用状況や課題を調査したレポート「2026 State of AI Coding Report」について考察するブログ記事を公開。AIによるコード生成が増える中で、品質管理の在り方が問われている状況を指摘した。

　Googleは本番コードの75％がAI生成だとしているが、こうした状況はもはや業界の標準だという。調査ではエンジニアリングリーダーの67％が、週ごとのコード出力の51〜75％が、AIによって生成または大幅にリファクタリングされたものだと回答した。

　興味深いのはそうしたAI生成コードに対する現場の評価が極めて高いことだが、調査によれば、コードが本番環境に出た後には全く異なる状況が発生している。

「レビューでは高評価」だが本番で壊れる――その理由は

　調査はHanover Researchに委託したもので、米国のマネジャー職以上の技術系意思決定者200人を対象としている。

　エンジニアリングリーダーの94％は、レビュー時点でAIが生成したコードは人間が作成したコードよりも高品質だと評価している。61％が「やや高い」、33％が「かなり高い」だった。大規模言語モデル（LLM）は、プルリクエスト（PR）のレビューで評価される静的なチェックに強い。一貫した設計パターンを出力し、スタイルガイドに忠実で、明らかな構文エラーも発生しにくいためだ。

　しかし本番環境になると、以下の通り評価は著しく低下する。

• 78％の組織がAIが生成したコードに起因する障害の増加を確認
• 86％がシニアエンジニアによる緊急対応の増加を報告
• 74％が、AI生成コードの25％以上でデプロイ後の大幅な手直しが必要と回答
  （コンテキストの不備、データの不完全さ、システム全体の動作条件を理解していないことなどに起因）
• 82％が過去6カ月間にAI生成コードによる障害を経験

　レビューで「読みやすい」と評価されるコードと、本番環境で安定して動くコードは必ずしも一致しない。LLMは、正しく動作するコードを生成することは得意だ。しかし、本番環境ではネットワーク障害やレースコンディション（複数の処理が同じデータを同時アクセスする場合に、実行順序によって結果が変わる状態）、複雑な依存関係などが影響し、障害につながるケースがある。

　エンジニアリングリーダーの62％は、自社の開発チームがAI生成コードを行単位で十分に確認せず、本番環境へリリースできるほど信頼していることが多い、あるいは常に信頼していると回答した。その結果、本番環境で問題が発生した後に修正を余儀なくされるケースが増える。

　結果として、DevOpsチームやSRE（サイト信頼性エンジニアリング）チームは、障害のトリアージ、デバッグ、リファクタリングなどに追われるようになり、「AIコード清掃員」と化しているという。調査ではこうしたチームのシニアエンジニアは、週の稼働時間の最大3分の1を、AI生成コードに起因する問題への対応に費やしていることが分かった。

本番で壊れる場所は4カ所に集中

　AI生成コードは、人間が書いたコードよりも本番環境で重大な問題を引き起こしやすい。New Relicの調査では、AI生成コードに起因する問題として、次の4つの領域が挙がった。

• インテグレーション障害（30％）
  • スキーマドリフト（スキーマの予期しない変更）、上流システムとの契約違反（API仕様やデータ形式の不一致）、マイクロサービス間のエラー率上昇として発生
• コンプライアンスとガバナンス（管理体制）の問題（30％）
  • 監査証跡の欠落、未検証ライセンスの混入、ネストされた依存関係内の規制違反として発生
• データ整合性の問題（29％）
  • 気付かれにくいデータベースの劣化、トランザクション記録の重複、未処理のnull値、データテレメトリーのドリフト（収集データの変化やずれ）として発生
• 新たなセキュリティ脆弱（ぜいじゃく）性（28％）
  • 認可ロジックの欠陥、トークン管理の脆弱性、インジェクション脆弱性、サービスメッシュ内の異常動作として発生

　これらはリグレッションテスト（回帰テスト）を擦り抜けやすく、コード単体を眺めるだけでは見つけにくい。

　本番環境でのギャップが生じる原因として、「AIコーディングツールはソースコードを理解するが、トレース情報は認識できない」と同調査では指摘されている。LLMは構文は読めても、リアルタイムのトランザクションや実際のインフラ構成は見えていない。

　一方で障害対応に当たるエンジニアが「原因となったコードを書いたことも読んだこともない」という状況は発生しやすくなっているので、ソースコードを読むことは「システム理解のための持続可能な方法」ではなくなっているという。

エンジニアリングリーダーへの3つの提言

　開発速度を高めながらSLA（Service Level Agreement：サービス品質保証）を維持するための対策として、次の3点が挙げられている。

• 工数計画の見直し
  • IDE（統合開発環境）のコード補完率やデプロイ頻度だけで効率を測らず、本番で発生する手直しのコストを工数として見込む
• ガバナンスポリシーの統一
  • 自動化されたSAST（静的アプリケーションセキュリティテスト）や回帰テスト、カナリアリリースを、コードの作成に関係なく適用する
• 監視基盤の統合
  • ログ、メトリクス、イベント、トレースを単一のデータ基盤に集約し、AIが生成したコードに起因する障害を素早く特定する

---

　AIが生成するコードが人間の読める量を超えた時点で、コードを読んで品質を担保するという前提は崩れている。調査結果は、品質管理の在り方が大きな転換点を迎えていることを示している。