最初に結論を述べます。AIで素早く作ったコード（いわゆる vibe coding）がデモでは動くのに本番で壊れるのは、AIが「動くコード」は書けても、「壊れない構造」までは保証しないからです。 生成AIは、ハッピーパス（うまくいく場合）のコードを驚くほど速く書きます。しかし、本番で問われるのは、ネットワークが切れたら・不正な入力が来たら・同時アクセスが起きたら・攻撃されたらどうなるか、というエッジケースと敵対的条件です。ここが抜けたまま本番に出すと、壊れます。
これは「AIを使うな」という話ではありません。速く作ること自体は正しい。問題は、AIの出力をそのまま信用して本番に出すことです。本記事は、AIで作ったプロトタイプを抱えた事業者・開発者が、それを本番品質に引き上げる（ハードニングする）ための実践ガイドです。
1. 「動く」と「壊れない」は別物
近年、生成AIで素早くアプリを組み上げる「vibe coding」が広まりました。アイデアを数時間でプロトタイプにできるのは、本当に革命的です。一方で、それを本番投入したときのトラブルも増えています。業界の報告では、AI生成コードのかなりの割合が、デプロイ後に追加のデバッグを要したとされ、AIで作ったプロダクトが本番で問題を起こした事例も数多く共有されています。
なぜか。AIは、プロンプトで指示された「やりたいこと」を実現するコードを書きます。しかし本番品質のコードに必要なのは、それだけではありません。
| AIが得意なこと | 本番で追加で必要なこと |
|---|---|
| 動く機能を速く書く | 不正な入力を弾く境界の検証 |
| ハッピーパスの実装 | エラー処理・タイムアウト・リトライ |
| それらしいUIの生成 | 認証・認可・データの分離 |
| サンプルデータでの動作 | 同時アクセス・競合状態への対処 |
| 単一の処理の実装 | 全体の整合性・冪等性・監視 |
「動く」は出発点であって、ゴールではありません。 デモで動くことと、本番の負荷・攻撃・障害に耐えることの間には、大きな隔たりがあります。
2. AI生成コードが本番で壊れる「決まった場所」
幸い、AI生成コードが壊れる箇所には、強いパターンがあります。私が本番化の過程で繰り返し補強してきたのは、次の5箇所です。
① 入力検証の欠如
AIは、外部からの入力（フォーム、API、ファイル）を「正しい前提」で扱いがちです。本番では、すべての外部入力を境界で検証・サニタイズしなければ、不正データやインジェクション攻撃で壊れます。型安全な検証（TypeScript + Zod など）を境界に置くのが定石です。
② エラー処理の欠落
「うまくいく場合」のコードは書けても、失敗したときにどうするかが抜けがちです。外部APIが落ちたら、DBが混んでいたら、ネットワークが切れたら——タイムアウト、指数バックオフでの再試行、フォールバックを組み込まないと、一箇所の失敗が全体を止めます。
③ セキュリティの穴
AIは、認証・認可を「画面のif文」レベルで実装しがちです。本番では、認可はサーバ／DB側で強制しなければ、APIを直接叩かれて突破されます。ハードコードされた秘密情報、CORSの緩い設定、SQLインジェクション——これらはAI生成コードでよく見つかる穴です。
④ 状態の競合（同時実行）
単一ユーザーのデモでは見えませんが、本番では複数の処理が同時に走ります。「読んで→計算して→書き戻す」処理は競合（レース）を起こし、データが壊れます。決済なら二重課金や残高不整合に直結します。冪等性と原子的な操作で構造的に防ぐ必要があります。
⑤ テストの不在
AIは「テストも書いて」と言えば書きますが、それが意味のある境界・異常系を突いているかは別問題です。テストがなければ、改修のたびに別の箇所が壊れ、誰も怖くて触れない「塩漬けコード」になります。
3. 本番化に必要なのは「作り直し」ではなく「硬化」
「じゃあ全部作り直しか」と思うかもしれませんが、多くの場合、その必要はありません。AIで作った骨格を活かしつつ、壊れる箇所を後付けで硬化（ハードニング）するのが、最も速く安いアプローチです。
AIで作ったプロトタイプ（骨格は活かす）
│
├─ 境界に型安全な検証を足す（Zod等で外部入力を parse）
├─ エラー処理・タイムアウト・リトライ・フォールバックを追加
├─ 認可をサーバ/DB側に移し、秘密情報を環境変数/秘密管理へ
├─ 競合する処理を冪等・原子的に作り直す（決済・在庫・予約など）
├─ 意味のあるテストとCI（型チェック・静的解析・セキュリティスキャン）を整備
└─ 構造化ログ・アラートで可観測にする
↓
本番運用に耐える品質へ
私が手がけたAI動画ローカライズ基盤は、まさにこの思想で作りました。重く不安定なAI/GPU処理を「本番運用に耐える」品質まで引き上げるため、バックエンドのテストカバレッジ100%を必須化（CIで未達はビルド失敗）し、型チェック（mypy strict）・静的解析をゼロエラーに保ち、スポットGPUが強制停止されても処理を再開できる冪等な設計にしました。「速く作る」と「本番で壊れない」は、検証ゲートで両立できます。
4. 検証ファースト——「速い」を「安全」にする仕組み
ここが、私が一人 × 生成AI で開発する際の核心です。生成AIは実装を圧倒的に速くしますが、その出力をそのまま信用しない仕組みを多層で通すことで、速さを保ったまま本番品質に到達します。
| 検証ゲート | 何を防ぐか |
|---|---|
| 型安全な境界検証（Zod / TypeScript） | 不正な入力、想定外のデータ形状 |
| 自動テスト（単体・統合・E2E） | 改修による退行、異常系の見落とし |
| 静的解析・Lint（型チェック・未使用検出） | 潜在バグ、anyによる型の抜け穴 |
| セキュリティスキャン（依存・秘密情報・脆弱性） | 既知の脆弱性、漏洩した秘密情報 |
| CI/CDによる強制 | 「人がレビューを忘れる」を構造的に排除 |
| 第三者セキュリティ監査 | 攻撃者視点でしか見つからない穴 |
これは抽象論ではありません。木材流通のB2B SaaSでは、実在15ロールでの第三者ペネトレーションテストを含む4ラウンドのセキュリティ監査を経て、全221エンドポイントの認証欠落0件を実証しました。「AIが速く書いた」ではなく、「検証で固めているから、速くても本番で壊れない」——これが、AI時代の開発で発注者が確認すべき品質の根拠です。
5. 発注者のためのチェックリスト
AIで作ったプロトタイプを本番化したい、あるいはAIを活用した開発を発注したい——そのとき、相手を見極める質問です。
AI生成コード本番化の発注チェックリスト
- 「速く作る」だけでなく「安全に固める」を語れるか——検証ゲート（型安全・テスト・セキュリティ）を具体的に説明できるか。
- 本番で壊れる箇所を知っているか——入力検証・エラー処理・認可・競合・テストの5箇所に言及できるか。
- 作り直しか硬化かを正しく判断できるか——「全部作り直し」を即答せず、活かせる部分を見極められるか。
- AIの出力を検証する仕組みを持っているか——「AIが書いたからOK」ではなく、CIで機械的に品質を守るか。
- セキュリティを後付けにしないか——認可・秘密情報・PIIの扱いを設計に組み込むか。
私の立ち位置: 私は、生成AIで素早く作り、それを「型安全・テスト・セキュリティ監査・冪等性」という検証ゲートで本番品質に固めます。AIで作ったMVPの本番化、品質に不安のあるコードベースの立て直し、セキュリティ・パフォーマンスの改善——「動いてはいるが、このまま本番に出していいか不安」という段階の立て直しを、数多く手がけてきました。
よくある質問（FAQ）
Q. AIで作ったプロトタイプは、そのまま本番で使えますか？
多くの場合、そのままでは危険です。AIはハッピーパス（うまくいく場合）のコードを速く書きますが、不正入力の検証、エラー処理、認可、同時実行の競合、テストといった「本番で問われる部分」が抜けがちです。骨格は活かしつつ、これらを後付けで硬化（ハードニング）すれば、作り直さずに本番品質へ引き上げられます。
Q. AIで作ったコードは、結局すべて作り直す必要がありますか？
ほとんどの場合、作り直す必要はありません。AIで作った骨格を活かし、壊れやすい箇所（入力検証・エラー処理・認可・競合・テスト）を補強する「硬化」が、最も速く安いアプローチです。全面作り直しは、設計が根本的に破綻している場合に限られます。
Q. なぜAI生成コードはデモで動くのに本番で壊れるのですか？
「動く」と「壊れない」は別物だからです。AIは指示された機能を速く実装しますが、本番で問われるのはネットワーク断・不正入力・同時アクセス・攻撃といったエッジケースと敵対的条件です。デモはサンプルデータと単一ユーザーで成立しますが、本番の負荷・障害・攻撃には、追加の作り込み（検証ゲート）が必要です。
Q. 「速く作る」と「品質」は両立しますか？
両立します。鍵は、AIの出力をそのまま信用せず、型安全な境界検証・自動テスト・静的解析・セキュリティスキャンという検証ゲートを多層で通すこと。これにより、生成AIの速さを保ちながら本番品質に到達できます。実際に、テストカバレッジ100%を保ちつつAI/GPUパイプラインを本番運用した事例もあります。
Q. 発注先がAIを使っているか不安です。確認すべきことは？
AIを使うこと自体は問題ではなく、むしろ速さの源泉です。確認すべきは「AIの出力をどう検証するか」。型安全な境界検証、自動テスト、CI/CD、セキュリティ監査といった検証ゲートを説明できる相手なら、AIを使っても本番品質を担保できます。「AIが書いたから大丈夫」しか言えない相手は要注意です。
まとめ：速さの源はAI、安全の源は検証
AIで作ったコードを安心して本番に出すために、押さえるべきは次の通りです。
- 「動く」と「壊れない」は別物——AIは動くコードを書くが、壊れない構造までは保証しない。
- 壊れる箇所は決まっている——入力検証・エラー処理・セキュリティ・競合・テストの5箇所。
- 速く作ること自体は正しい——問題はAIの出力をそのまま信用すること。検証ゲートを通す。
- 本番化は作り直しではなく硬化——骨格を活かし、壊れる箇所を後付けで補強する。
- 発注は「速く作れるか」ではなく「速く作ったものを安全に固められるか」で選ぶ。
「AIで作ってみたが、本番に出すのが不安」「動いているが、品質・セキュリティに自信がない」——その立て直しは、私の最も得意とするところです。検証ファーストで、速さと安全性を両立させた本番品質へ、ワンストップでお引き受けします。