AIコードの"あとしまつ"を何十件もやって気づいたこと
Cursor、Bolt、Lovableで作ったプロトタイプを本番品質に仕上げる依頼を受け続けて見えた、AI生成コードに共通する問題と、本番化に本当に必要なプロセスを整理する。
「AIで作ったWebアプリがあるんですが、本番に出せますか？」
この相談が急増したのは2025年の後半からだ。Cursor、Bolt.new、Lovable、v0——AIコーディングツールの進化で、プロトタイプを作れる人が爆発的に増えた。
問題は、その先だった。
画面はできている。ボタンも動く。デモでは好評。でも本番に公開しようとすると、誰もが同じ壁にぶつかる。セキュリティ、認証、決済、エラー処理、データベース設計——AIが生成しなかった「残り30%」が埋まらない。
この相談を受けるたびに、同じ作業を繰り返している自分に気づいた。やっていることはほぼ毎回同じだ。それなら、サービスとして体系化した方がいい。
これが「AIのあとしまつ」を作った理由だ。
何十件もやって見えた、AI生成コードの共通パターン
AIが生成するコードには、ツールや指示内容に関係なく、驚くほど共通したパターンがある。何十件もの「あとしまつ」をやる中で、以下の5つに収束した。
1. 認証がザルになっている
最も多い問題がこれだ。
AIはログイン画面を作ってくれる。だが、その裏のセキュリティが甘い。トークンの有効期限が設定されていない、パスワードリセットのフローが不完全、APIエンドポイントが認証なしでアクセスできる——こうした問題が、ほぼ100%の確率で存在する。
ログイン画面が「ある」ことと、認証が「機能している」ことは全く別の話だ。
2. データベースの設計が場当たり的
AIは「動くように」データベースを設計する。だが「運用できるように」は設計しない。
具体的には：
- インデックスが設定されていない（データが増えると急激に遅くなる）
- リレーションが正規化されていない（同じデータが複数テーブルに散在する）
- マイグレーションの仕組みがない（スキーマを変更するとデータが消える）
- バックアップの設計がない
Supabaseを使っているケースが多いが、Supabaseのデフォルト設定はセキュリティ的に甘い部分がある。Row Level Securityが無効のまま公開されているプロジェクトも少なくない。この問題が多すぎたので、Supabase Risk Checkという無料診断ツールも作った。
3. エラーが握りつぶされている
AIが書くコードの多くは、エラーをcatchしてconsoleに出力するだけ。ユーザーには何が起きたのかわからない。決済処理が失敗しても画面上は何も起きない、というケースも実際にあった。
本番で動かすなら、エラーは「起きるもの」として設計する必要がある。ユーザーへの通知、リトライの仕組み、ログの収集——これらはAIが自発的に実装することはまずない。
4. 環境の分離ができていない
開発環境と本番環境の区別がない。APIキーがコードにハードコードされている。.envファイルがGitHubにプッシュされている。ステージング環境がない。
これは技術的な問題というより、運用の問題だ。AIは「今動くコード」を書くが、「チームで安全に運用するための構造」は作らない。
5. パフォーマンスの考慮がゼロ
データが10件のときは快適に動く。だが100件、1,000件になると途端に重くなる。画像の最適化がされていない。APIコールが無駄に多い。バンドルサイズが肥大化している。
プロトタイプのデモでは気づかない。ユーザーが増えてから気づく。
「あとしまつ」のプロセスが固まるまで
最初の数件は、相談ごとにゼロから調査していた。だが何十件もやると、チェックすべき項目と修正パターンが固まってくる。
結果的に、以下のプロセスに収束した：
Phase 1：診断（1〜2日）
コードを受け取り、上記5つの観点でリスクを洗い出す。この段階で「本番に出しても問題ないか」「何を直す必要があるか」「どのくらいかかるか」がわかる。
Phase 2：修正（1〜2週間）
認証の修正、DB設計の見直し、エラーハンドリングの追加、環境分離、パフォーマンス改善。案件によって濃淡はあるが、やることのベースは同じ。
Phase 3：デプロイ＆引き渡し（1〜2日）
本番環境へのデプロイ、ドメイン設定、SSL証明書、監視の設定。何がどう動いているかのドキュメントも渡す。
このプロセスを「最短2週間」で回せるようにしたのが、あとしまつというサービスだ。
なぜサービスにしたのか
正直に言えば、一つひとつの依頼を個別対応しても回せた。だがサービスにした理由が2つある。
1つ目は、相談者が増えすぎたこと。
Vibe Codingの普及に伴い、この問題を抱える人は今後も増え続ける。個別対応では追いつかない。プロセスを定型化して、診断ツールも作ることで、効率よく対応できるようにした。
2つ目は、「何を直せばいいかわからない」人が多いこと。
プロトタイプが動いている状態で「何が問題か」を自分で判断できる人はほとんどいない。「動いている＝大丈夫」と思っている。まず問題を可視化する仕組みが必要だった。Supabase Risk Checkのような無料ツールを入口にして、自分でもリスクを確認できる状態を作った。
この問題は今後も続く
AIコーディングツールは今後も進化する。生成されるコードの品質も上がるだろう。
だが、「プロトタイプと本番の間にギャップがある」という構造は変わらない。AIが進化しても、認証設計、データ保全、運用設計といった「ビジネスのコンテキストに依存する判断」は人間がやる必要がある。
AIで「作れる」人が増えた分、「仕上げられる」人の価値は上がっている。
AIで作ったプロトタイプが手元にある方は、まずSupabase Risk Checkでリスクを確認するか、あとしまつで相談してほしい。