なぜAIが書いたコードは壊れやすいのか？3つの構造的原因

はじめに

「AIで作ったアプリが最初は動いていたのに、機能を追加したら壊れ始めた」——私たちのもとには、こうした相談が毎週のように届きます。

AIコーディングツールの出力は、一見正しく動作するコードを生成します。しかし、規模が大きくなるにつれて問題が顕在化するケースが非常に多いのです。本記事では、AI生成コードが壊れやすい3つの構造的原因を解説します。

原因1: コンテキストの断片化

問題

AIは一度に処理できる情報量に限界があります。プロジェクトが大きくなると、ファイルAで定義した型とファイルBで使う型に不整合が生じたり、同じ機能が複数箇所で微妙に異なる実装になったりします。

実例

あるプロジェクトでは、ユーザー情報を取得する関数が4つの異なるファイルに4つの異なる実装で存在していました。それぞれ微妙にレスポンスの形が異なり、フロントエンドで表示崩れの原因になっていました。

対策

単一の情報源（Single Source of Truth） を意識した設計
共通処理はユーティリティに集約し、AIに「この関数を使って」と明示的に指示
定期的なコードレビューで重複を検出

原因2: 暗黙知の欠如

問題

経験豊富なエンジニアは、コードに書かれていない知識（暗黙知）を持っています。例えば：

「この処理は並行実行される可能性があるから排他制御が必要」
「このAPIは稀にタイムアウトするからリトライ処理を入れるべき」
「この値はユーザー入力だからサニタイズが必要」

AIはこうした暗黙知を持たないため、正常系では動くが異常系で壊れるコードを生成しがちです。

実例

予約システムで、2人のユーザーが同時に最後の1枠を予約すると、両方とも予約成功になる問題がありました。AIは予約処理のロジックは正しく書きましたが、同時アクセスの可能性を考慮した排他制御を実装していませんでした。

対策

要件定義の段階で異常系・並行処理・セキュリティ要件を明文化
AIへの指示に非機能要件を含める
重要な処理は人間がレビュー

原因3: アーキテクチャの不在

問題

AIは「この機能を作って」という指示には応えられますが、システム全体の設計方針を持っていません。その結果：

ビジネスロジックがUIコンポーネントに混在
データアクセスが至る所に散在
依存関係が複雑に絡み合い、変更の影響範囲が予測不能に

これは技術的負債と呼ばれ、機能追加のたびに指数関数的にコストが増加します。

実例

ファイル数が50を超えたあたりで、1つのバグ修正が5つの別のバグを引き起こす状態になったプロジェクトがありました。ファイル間の依存関係が整理されておらず、変更の影響範囲を把握できなくなっていたのです。

対策

最初にアーキテクチャを設計してからAIにコードを書かせる
レイヤードアーキテクチャ等のパターンを採用
定期的にリファクタリングの時間を確保

AI生成コードとの正しい付き合い方

AIコーディングツールは強力な開発支援ツールですが、設計者としての人間の役割がなくなるわけではありません。

設計は人間が行う — アーキテクチャ、データモデル、セキュリティ方針
実装はAIに任せる — 定型的なコード、ボイラープレート、テスト
レビューは人間が行う — 品質、セキュリティ、パフォーマンス

この3ステップを守ることで、AIの生産性を享受しながら、壊れにくいシステムを構築できます。

まとめ

AI生成コードが壊れやすい原因は、AIの能力不足ではなく、ソフトウェア開発に必要な「設計」と「レビュー」のプロセスが省略されていることにあります。

すでにAI生成コードで問題を抱えている方は、まず無料コード診断で現状を把握することから始めてみてください。