AIは開発速度を高めるが、バグは1.7倍多い

• オープンソースの470件のPR分析結果では、AIが作成したコードは人間が作成したコードより平均1.7倍多くの問題を含んでいた
• ロジックエラー・可読性の低下・セキュリティ脆弱性など主要な欠陥がAIコードで顕著に多く、特に可読性の問題は3倍以上増加
• AIコードではエラー処理の欠落・並行性エラー・命名の不一致が頻発し、レビュー負荷と運用リスクが拡大
• 原因として、ビジネスロジックの理解不足、表面的な正確さの追求、低効率なパターンの選好などが分析された
• レポートは、AIコードの品質管理体制の強化とAI認識型のコードレビュー・セキュリティ・テスト手順の導入の必要性を強調

---

AI vs Human Code Generation Report 概要

• CodeRabbitは、AIと人間が作成したコードの品質差を実証的に分析するために研究を実施
  • オープンソースのGitHub PR 470件を調査し、このうち320件はAI共同作成、150件は人間単独作成
  • すべての結果はPR 100件あたりのイシュー数に正規化し、統計的な比率比較によって問題タイプ別の発生頻度を測定
• 結果として、AIは生産性を高める一方で、エラー発生率も増加
  • AI作成PRあたり平均10.83件の問題、人間作成PRは6.45件
  • 特に深刻度の高いエラーがAIコードでより頻繁に見つかった

研究の限界

• AI作成かどうかを直接確認できないため、AI共同作成シグナル(co-authored-by) があるPRをAI作成として分類
  • シグナルのないPRは人間作成とみなしたが、完全な区別は不可能
• この限界にもかかわらず、2つのグループ間の問題パターンの統計的差異は有意に現れた
• 全体の方法論はレポート末尾で公開

主要な10の発見

• すべてのエラータイプがAIにのみ存在するわけではないが、ほとんどのカテゴリでAIコードのエラー率が高い
  • 人間とAIはどちらも同種のミスをするが、AIはより頻繁に、より大規模に発生する

• 1. 全体のイシュー数が1.7倍増加

  • AI作成PRあたり平均10.83件、人間作成PRは6.45件
  • イシューが集中したPR(outlier) がAIコードで大幅に多く、レビュー負荷が増加

• 2. 深刻度の高いエラーが増加

  • 重大・致命的な問題が1.4〜1.7倍多い

• 3. ロジックと正確性の問題が75%増加

  • ビジネスロジックのエラー、誤った依存関係、制御フローの欠陥、設定ミスを含む
  • 修正コストが高く、運用障害につながる可能性が大きい

• 4. 可読性の問題が3倍以上増加

  • 命名規則・コード構造・表現の一貫性が著しく低下
  • コードが見た目には整っていても、ローカルパターン違反が頻発

• 5. エラー処理および例外経路の欠落が2倍増加

  • nullチェック、guard条件、例外処理ロジックがしばしば欠ける
  • 実際のサービス障害に直結するタイプ

• 6. セキュリティ問題が最大2.74倍増加

  • パスワード処理の不適切さ、オブジェクト参照の脆弱性が代表例
  • 固有の脆弱性ではないが、大半のセキュリティ欠陥が拡大

• 7. 性能低下の問題は少ないがAI側に集中

  • I/Oの過剰呼び出しが約8倍多い
  • AIが明快さ重視のコードを好むため効率が落ちる

• 8. 並行性・依存関係のエラーが約2倍増加

  • 順序ミス、誤った依存フロー、並行制御の誤用が頻発

• 9. フォーマット問題が2.66倍増加

  • インデント、空白、スタイル不一致など形式的なエラーが多い
  • 自動フォーマッタやリンターを使っても、AIコードではノイズが増加

• 10. 命名の不一致が2倍増加

  • 不明瞭な名前、用語の不一致、一般的な識別子の使用が多く、レビュアーの認知負荷が上昇

問題発生の原因

• AIはビジネスロジックの理解が不足
  • 統計的パターンに基づいてコードを生成するため、システムのルールを見落とす
• 表面的な正確さ中心の生成
  • コードは見た目には正しそうでも、制御フロー保護や依存順序のエラーが存在
• リポジトリごとの慣例を順守しない
  • 命名・構造・フォーマット規則が一般化された形に変質
• セキュリティパターンの弱化
  • 明示的な指示がなければ、古い・脆弱なコードパターンを再現
• 効率より単純さを選好
  • 反復I/O、非最適な構造を使う傾向

エンジニアリングチーム向けの対応策

• AI導入では速度向上だけでなく、品質保証体制の再設計が必要

• 1. AIに十分なコンテキストを提供

  • ビジネスルール・設定パターン・アーキテクチャ制約を明示することでエラーを削減
  • プロンプト内にリポジトリごとのガイドライン・スキーマを含める

• 2. ポリシーベースでコードスタイルを強制

  • CIのフォーマッタ・リンター・スタイルガイドで可読性の問題を予防

• 3. 正確性の安全装置を追加

  • テストの義務化、null/type検査、例外処理の標準化、guard条件の明示

• 4. セキュリティのデフォルトを強化

  • 認証情報の一元化、パスワードの直接使用を遮断、自動SAST・セキュリティリンター実行

• 5. 効率的なパターンを誘導

  • I/Oのバッチ処理、適切なデータ構造の選択、性能ヒントの提供

• 6. AI認識型PRチェックリストを導入

  • レビュー時に次の項目を確認:
    • エラー経路がカバーされているか
    • 並行制御が正確か
    • 設定値が検証されているか
    • パスワード処理方法が適切か

• 7. AIコードレビュー自動化を導入

  • レビュー疲労の増加によるバグ見落としを防ぐため、AIコードレビューツール(CodeRabbit) の活用を提案
    • レビュー品質を標準化し、確認時間・認知負荷を削減

結論

• AIコーディングツールは強力な加速装置だが、防護策のない加速は危険
• AI生成コードは変動性・エラー率・深刻度のすべてが高い
• AIを代替ではなく補完ツールとして活用し、品質・セキュリティ・テスト体制の強化が必須
• 速度と品質を両立するには、意図的なエンジニアリング管理が必要
• AIコードレビュー支援ツールの活用は品質維持に実質的な助けとなり得る

[cshj55]

1.7倍なら、思ったより少ない……？

[ds2ilz]

私もAIでコーディングしながら、似たようなことを感じています。整理された原因を見ると、人がコーディングするときに前提として持っているパターン、命名規則、エッジケース処理、ガード条件などが、コンテキストとして十分に与えられていないからではないかと思います。
なので私は、そういったものだけを集めたルールファイルを1つ作って、コーディングするときはそのファイルを必ず読んで順守するよう指示しています。すると、そのルールファイルだけを改善していけば、成果物がかなり良くなるんですよね。

[princox]

「ものすごくたくさん作れたんだから、1.7倍ならタダ同然じゃないか」という意見がありそうで怖い…

[kimjoin2]

でも速かったでしょ？っていうミームを思い出します（笑）

[GN⁺]

Hacker Newsの意見

• 私は AI以前から『vibe coding』は存在していた と思う

  • 多くの開発者が、なぜオブジェクトが null なのかを考えずに、ただ null check をベタベタ追加しているのを見てきた
  • こうしたアプローチは一部の領域では役に立つが、システム全体がこう作られると保守は悪夢になる
  • AIベースの vibe coding は、「なぜ動くのか分からないまま、画面に欲しい結果だけを見る」スタイルを 加速 している感じだ
  • 昔こういう会社で働いたことがあるが、null check で例外を握りつぶしてしまい、エラーが静かに埋もれていた
    • チームは自分たちを賢いと自画自賛していたが、実際は StackOverflowのコピペコード と古い MVP 構造で動くシステムだった
    • こういう環境では独立した思考がほとんど不可能だった
    • それでも Claude Code のようなツールは、よく設計されたコードベースの上では生産性を大きく高めてくれる
  • StackOverflow からコピペして、「だいたい動けばいい」で止まるのがまさに vibe coding だ
    • AIはその過程を 自動化 しただけだ
  • 「見たいものを見る」ではなく、「何でもいいから 画面に表示する」のほうが正確な表現だ
    • 何気なく入れた null-check は、後になって 微妙なデータ不整合 を引き起こし、原因追跡を非常に難しくする
  • 私も同意するが、vibe coding は StackOverflow 依存型の開発者をさらに速くしてしまう
    • 自分で問題を解決しないタイプの開発者がさらに増える
    • しかも以前より 信頼性はさらに低い
  • AIを使っていて一番もどかしいのは、言語ごとの 中級レベルのコードスタイル をそのままなぞることだ
    • 私は「間違ったデータを作らなければ処理する必要もない」という原則でやっているが、AIはしょっちゅうそれを破る
    • 型定義や invariant の維持 をほとんどせず、文字列と整数だけで処理しようとする
    • だから私は tab-complete ベースでAIを断続的に使い、構造的な誤りは自分で直している
    • 修正後はAIも正しい方向についてくるので、IDEとLSPの統合 がもっと良くなれば、ずっと有用になると思う

• vibe coding への批判はもっともだが、実際のところ AI以前からコード品質はひどかった

  • ほとんどのコードは遅れてリリースされ、品質も低かった
  • 素早いリリースがアイデア検証の速度を高めるなら、ある程度の不具合は受け入れられると考える人もいる
  • 最近は経営陣が「この程度の機能に、なぜ数か月もかかるのか」と尋ねるケースが増えている
  • しかし「些細な機能に時間がかかる理由」はアルゴリズムではなく、インフラと協業の構造 にある
    • AIはこうした根本問題を解決できない
  • 保守コストと複雑さは時間とともに 複利のように積み上がる
    • 短期プロジェクトなら vibe coding でもよいが、長期システムには不向きだ
  • 私は 意図的な開発者 と vibe 開発者 のバランスが重要だと思う
    • AIは vibe 側を過度に強化し、システムのバランスを崩してしまう
  • コード品質より重要なのは、ビジネス課題と技術的解決策の共同理解 だ
    • 品質が低くても、その理由とトレードオフを明確に理解していることのほうが重要だ
  • ただ、ソフトウェアを分かっていない人が開発者に「やり方が間違っている」と言うのを前向きに捉えるのは難しい

• 「AIコードは1.7倍多くの問題を作る」という話は、発見されたバグの数 にすぎない

  • 実際にはPRレビューが十分に行われていないため、AIコードの問題もかなり見逃されている
  • コードレビューは バグ探しよりも、構造の理解と共有 に重きを置くべきだという研究もある
  • 一方で、AIコードはコメントが多く読みやすいため、むしろより丁寧にレビューされるという意見もある
    • 人間が書いたコードのほうには、「これが何か分からないけど消すと壊れる」といった類いのコメントが多い

• 少し前に .NET で IComparable の実装 を Copilot に提案してもらい、数分節約できた

  • ただ、変数名を x と y で取り違えていて、1時間デバッグする羽目になった
  • 自分で書いていればそんなミスはしなかったはずだ
  • それでも最終的には、自分が書くコードとほとんど同じものだった

• 以前にも似たような状況はあった

  • エラー処理やエッジケースを無視すれば、はるかに速くリリースできたが、結局は バグの爆弾 になった
  • AIはこれを極端に押し進めているように感じる
  • 「それなら Erlang や Elixir に乗り換えるべきでは」という冗談も出ていた

• LLMベースの会社が「AIは思ったほどひどくない」と主張していたのは興味深かった

  • ただし Coderabbit は LLM コードレビュー企業なので、むしろ「AIはひどい、だからAIでレビューすべきだ」というインセンティブがある
  • 私も Copilot をレビュー用ツールとして使っているが、AIレビューはほぼ常に正確 で、人間のレビュー前にかなり役立つ

• 私は CodeRabbit をよく使うが、今でも false positive が多い

  • すでに検証済みのコードなのに、「データ検証がない」と指摘されることがある
  • それでも「それは違う」と伝えると、ツールはそれを学習して受け入れる

• 「1.7倍多い」と「1.7倍増えた」は同じ意味ではない

  • ただ、こういう数値の言い争いは結局 無意味な争い のように感じる

• Agentic AI coding は単なるツールであり、使い方を誤れば当然誤った結果になる

  • 成功した活用例として、Python の justhtml の例を勧めたい
  • ただし、「使えないなら無能だ」といった白黒思考は問題だ
    • AIを有用だと感じるかどうかは、単に 経験の違い にすぎない

• 記事タイトルの「AIコードが1.7倍多くの問題を作る」という表現は不正確だ

  • 実際には バグではなく、フォーマットや命名の問題 まで含めた「問題」になっている
  • バグの数値自体は記事内に明記されていない