AIコードあるある症状10選——バグ修正しても直らない本当の理由

AIに「このバグを直して」と頼む。直る。別の場所が壊れる。また頼む。直る。さっき直したはずの場所がまた壊れる。

この堂々巡りを経験した人は多いはずです。Bolt.new、Lovable、Cursor——どのツールで作っても、同じパターンに陥ります。

結論から言います。これはバグではなく、構造の問題です。

個別のバグを直しても構造が壊れたままなら、新しいバグが生まれ続けます。以下の10症状に3つ以上心当たりがあるなら、必要なのは「修正」ではなく「仕上げ」です。

症状1: 1ファイルが1000行を超えている

AIは「このファイルに追加して」と指示されると、際限なく追加します。ヘッダー、フォーム、テーブル、モーダルが全部1つのpage.tsxに詰め込まれる。コンポーネント分割という発想がそもそもない。

ファイルが巨大だと、AIが修正するとき全体を把握できず、別の箇所を壊します。修正の連鎖が起きる根本原因です。

症状2: .tsと.tsxの混在・命名の不統一

utils.ts、helper.tsx、apiClient.ts——ファイル名に一貫性がありません。JSXを含むのに.ts、含まないのに.tsx。ビルド時にだけエラーが出て原因がわからない、という典型的な症状につながります。

症状3: 同じロジックが3箇所以上にコピーされている

認証チェック、日付フォーマット、バリデーション。同じ処理があちこちにコピペされています。1箇所直しても他が直っていない。デバッグが終わらない最大の原因です。

症状4: anyだらけの型定義

TypeScriptを使っているのにanyが30箇所以上。型安全性がゼロの状態です。本番で「Cannot read properties of undefined」が頻発するなら、ほぼこれが原因です。

症状5: エラーハンドリングがconsole.logだけ

try-catchの中でconsole.log(error)して終わり。ユーザーには何も表示されず、画面が真っ白になります。正常系しか考慮されていないコードは、本番環境で必ず問題を起こします。

症状6: 環境変数がハードコーディング

APIキーやデータベースのURLがコードに直書きされている。GitHubにpushした時点で全世界に公開されます。AIコードのセキュリティリスクで詳しく書いていますが、これは最も危険な症状です。

症状7: AIに修正を頼むと別の場所が壊れる

症状1（巨大ファイル）と症状3（コピペ）の複合症状です。構造が壊れているから、1箇所の修正が別の場所に波及する。AIは「今見えているエラー」しか直さないため、修正が永遠に終わりません。

症状8: ローカルでは動くがデプロイすると動かない

環境変数の未設定、ビルド時の型エラー、サーバーコンポーネントとクライアントコンポーネントの混在。ローカルのdevモードでは見逃される問題が、本番で一気に噴き出します。最後の30%の壁の典型です。

症状9: ログインは動くが、認証が「なんちゃって」

ログイン画面はある。しかしセッション管理がない。トークン検証もない。フロントエンドで画面を切り替えているだけで、APIには誰でもアクセスできる状態。セキュリティの基本を押さえていないと、ここに気づけません。

症状10: データベースに直アクセスしている（RLSなし）

Supabaseを使っているのにRLS（行レベルセキュリティ）が全部OFF。つまりログインしたユーザーが、他のユーザーのデータを全部読める状態です。「動いている」ことと「安全に動いている」ことは別の話です。

バグではなく、構造の問題

10個の症状を見て気づいた方もいるかもしれません。どれも「コードの1行が間違っている」という話ではない。ファイル設計、型設計、セキュリティ設計——コードの土台そのものが不安定な状態です。

土台が不安定なまま個別のバグを修正しても、別のバグが生まれるだけ。ココナラで修正を繰り返すのも、AIにデバッグを頼み続けるのも、対症療法にすぎません。

必要なのは、構造を整理する「仕上げ」の工程です。

3つ以上当てはまったなら、バグ修正ではなく、コードの「あとしまつ」を検討する段階に来ています。