Vibe Coding で作ったシステムが、本番で使えない理由
AI で作ったプロトタイプを、事業で使えるシステムに変えるためのチェックリスト。
この記事の結論
- Vibe Coding は、プロトタイプや MVP を作るには非常に有効です。
- ただし、本番運用にはこの 4 つの設計が別途必要になります。
- 認証だけでなく、テナント境界と権限境界
- ハッピーパスだけでなく、例外フローと同時利用
- 画面だけでなく、監査ログ・監視・復旧手順
- AI 生成コードだけでなく、ドメインモデルと運用設計
- つまり問題は「AI で作ったこと」ではなく、運用前提を決めないまま本番投入してしまうこと です。
- すべてを作り直す必要はありません。残せる部分と、作り直すべき部分を分けるのが現実的な進め方です。
Cursor、Claude Code、Codex、Lovable など、AI 開発ツールによって、「とりあえず動くもの」を作る速度は大きく上がりました。
ここ最近、min's に持ち込まれる相談でも、「AI で動くところまでは作れたが、そのまま事業で使おうとしたら運用で詰まった」というケースが増えています。画面は動いている。デモも見せられる。それでも、本番では使えない。
ただし、Vibe Coding そのものが悪いわけではありません。むしろ、プロトタイプや MVP を素早く作るうえでは非常に強い武器です。問題は、AI で作ったプロトタイプを「事業で使える状態」にするための設計が、後回しになりやすい ことにあります。
この記事では、min's に寄せられる相談や開発・運用支援の現場で見えてきた傾向から、「動くもの」と「本番で使えるもの」の間にある段差を整理します。発注担当・事業責任者の方が「いま自社のプロトタイプを本番化していいのか」を判断できる材料を提供することが目的です。
AI 開発ツールで作れるもの、まだ人間が設計すべきもの
OpenAI は Codex を、コードベース上での機能追加、質問応答、バグ修正、レビュー用 PR 提案までを、リポジトリが読み込まれた独立したクラウドサンドボックスで実行できるソフトウェアエンジニアリング・エージェントとして説明しています (Introducing Codex / OpenAI)。Anthropic も Claude Code を、ローカルのファイルシステムを直接たどって複数ファイルを変更し、テストを実行する agentic coding system として位置づけています (Claude Code docs / Anthropic)。
実際、現場で AI が出してくれるものは、次のような領域では非常に速い。
- 画面 1 〜 2 枚分の CRUD
- 単独の API エンドポイント
- フォームのバリデーション
- ライブラリの組み合わせ・サンプル実装
- 仕様が明確な単機能 (PDF 出力、CSV 取り込み、メール送信)
ここまでは、AI に「やってほしいこと」と「制約」を渡せば、人間が書くより速く・少ない誤差で実装できます。OpenAI のドキュメントでは、複雑な調査や実装ではサブエージェントを並列に走らせ、それぞれの差分をレビューしながら統合していくワークフローも公式に想定されています (Codex Subagents / OpenAI Developers)。
一方で、AI に任せる前に、人間が決めておかなければならない領域 があります。技術的な定義だけでなく、決めずに進めたときに発注側で何が起きるかも併記します。
- ドメインモデル: 請求、在庫、シフト、契約、予約のような業務固有の概念を、後から仕様変更されても壊れにくいデータ構造と責任範囲に落とす作業。
- ここが曖昧だと、機能追加のたびに既存データとの整合性が崩れます。
- 整合性: 注文と入金と出荷、ステータスと履歴、複数テナント、複数拠点の整合性。
- ここが弱いと、二重予約、二重請求、在庫ズレといった事故につながります。
- 例外設計: 失敗するパスをどう扱うか。ロールバックするのか、人間に通知するのか、リトライするのか。
- ここがないと、エラーが起きたときに現場が手作業で復旧することになります。
- 権限境界: 誰が何を見られて、何を編集できるのか。それをデータ取得の瞬間に効かせる仕組み。
- ここが甘いと、社内担当者が触ってはいけない情報を編集できる状態になります。
- 運用設計: 何かが壊れたとき、誰が、何を見て、どこから直すのか。
- ここを決めずに本番投入すると、障害のたびに事業全体が止まります。
これらは、AI に「タスク」として与えても出てきません。事業を運用していく前提を、人間が先に決めて、AI に渡す必要がある領域です。
Vibe Coding で作ったシステムが本番で壊れるのは、AI の性能が足りないからではありません。運用前提が決まらないまま実装が走った からです。
プロトタイプと本番システムの違いは、機能数ではない
外から見ると、Vibe Coding で作ったプロトタイプは、市販の SaaS と同じくらい完成度が高く見えます。画面は綺麗、レスポンスは速い、デモシナリオは通る。
しかし、事業で「使えるもの」と何が違うのかを分解すると、機能数の差ではないことが分かります。
| 観点 | 動くもの (デモ) | 使えるもの (本番) |
|---|---|---|
| 同時利用 | 1 人で触っても通る | 複数ユーザーが同時に触っても、整合性が壊れない |
| 障害時 | エラー画面が出る | 何が起きたか追える、復旧手順がある |
| データ変更 | 直接 DB を触れる | 履歴が残り、誰がいつ変えたか分かる |
| 権限 | ログインさえできれば全部見える | 役割によって、見える範囲・編集できる範囲が分かれる |
| 例外フロー | ハッピーパスは通る | キャンセル、返金、誤入力、二重申込みが扱える |
| 業務との接続 | 画面だけで完結する | 既存業務 (Slack、Excel、メール) と繋がっている |
特に厄介なのは「同時利用」と「例外フロー」です。1 人でテストしている間は気付かないのに、2 人目のユーザーが触った瞬間にデータが壊れる、というケースは、Vibe Coding 由来のシステムで頻繁に発生します。
ローカル開発で動かしているうちは、業務固有の同時性や順序保証の問題が見えないまま完成判定してしまう、という構造の問題です。AI に「同時に 100 人触っても壊れないように」と頼んでも、何が壊れる可能性があるかを示せるのは、業務とドメインを知っている人間です。
AI 生成コードが本番運用で破綻する 8 つのパターン
ここからは、min's に持ち込まれる相談のうち、「Vibe Coding で作ったが本番で詰まった」案件で、実際に見かけた破綻を 8 つ取り上げます。診断を依頼される前にチェックしておくと、改修コストの目処が立ちやすくなります。
1. 認証は仕組みがあっても、テナント境界がない
「ログインできる」と「自社の他のお客さんのデータを見られない」は、別の問題です。Clerk や Firebase Auth、Auth0 を入れて「認証付き」になっているのに、データの取得クエリにテナント ID の条件が落ちている、というケースがあります。
複数顧客で運用する SaaS なら、認証時に必ずテナント情報を確定させ、データアクセス層 (Firestore のセキュリティルール、Supabase の Row-Level Security、TypeScript なら Repository 関数) で 強制的に絞り込む 設計が安全です。アプリ層で「毎回気をつけて WHERE を入れる」設計は、AI による差分追加や急ぎの改修が増えるほど漏れやすくなります。
事業上の被害: 最悪の場合、他社データの閲覧や情報漏えいにつながります。
2. 権限が「あとからかける」前提で組まれている
最初は管理者 1 ロールで作って、後から「閲覧専用」「店舗担当」「本社担当」を追加していくと、画面ロジックの中に if 文が増殖していきます。半年後には、「誰が何を見られるか」がコードを全部読まないと分からなくなります。
権限は、画面で出し分けるのではなく、データ取得時点で絞り込まれる形で初期設計に組み込むのが本筋です。min's の実務では、権限の後付けは「単純な機能追加」ではなく、既存実装全体の再点検に近い作業として扱っています。
事業上の被害: 社内担当者が触ってはいけない情報を編集できる状態になります。
3. ステータスを増やし続けて、組み合わせ爆発する
pending / active / paused / canceled / suspended / pending_cancel / refunded … と状態を増やすたびに、AI に「この状態のときはこう動かして」と頼みやすくはなります。ただし状態間の遷移が増えるので、修正のたびに別の遷移が壊れます。
予約、請求、契約のように履歴が重要な業務では、台帳型のイベント履歴 (append-only) を残し、現在の状態はその履歴から導出する設計が有効です。すべてのシステムで必要ではありませんが、お金や約束が動く業務では、後から効いてくる設計です。
事業上の被害: キャンセル済みなのに請求される、返金済みなのに有効扱いになる、といった事故が起きます。
4. お金と数字のロジックがアプリ層に散らばっている
請求書、CSV 出力、月次レポートが、それぞれ別のページで集計ロジックを持っていて、微妙に違う、というのは典型的な破綻です。値引きの扱い、税の丸め、為替差、返金の扱いが、画面ごとに少しずつズレている。発覚するのはたいてい、月次締めのタイミングです。
数字の責任を持つロジックは、ドメイン層に 1 箇所に集約して、画面側からは結果だけ参照する設計に統一します。これは AI に頼む前に、人間が 「お金の流れの単一の真実」をどこに置くか を決めておく仕事です。
事業上の被害: 請求書、管理画面、CSV で数字が合わず、月次締めが止まります。
5. ログも履歴もない
「いつ・誰が・何を・どの値から、どの値に変えたか」が残っていないシステムは、本番運用で詰まります。問い合わせがきても「現象を見て勘で直す」しかできず、再発防止のしようがない。
少なくとも、金が動く・個人情報が動く・契約状態が変わる イベントは、最初から監査ログを積む前提で設計します。あとから追加するのはデータベース構造を変えることになるので、本番投入前に決める方が結果的に安く済みます。
事業上の被害: 顧客から問い合わせが来ても、原因を説明できません。
6. ジョブと外部 API の冪等性が考慮されていない
バッチで送信するメール、決済 Webhook、外部 API のコールバック。これらが「同じイベントが 2 回来ても壊れない」設計になっていない Vibe Coding システムが見られます。決済 Webhook や外部 API のコールバックは、同じイベントが複数回届く前提で設計する必要があります。
外部からの入力には冪等性キー (idempotency key) を持たせ、「既に処理済みのものは無視する」テーブルを最初から用意します。これも事後追加が高くつくので、PoC でも入れておく方が無難です。
事業上の被害: 二重決済、二重送信、二重登録が起きます。
7. 監視・通知の経路がない
Vercel、Cloud Run、Lambda にデプロイしたあと、エラーログが Sentry にも Slack にも流れていない、という状態で本番投入されているケースがあります。エラーが出たら自分の Slack に来る、まで設定して初めて「運用に入った」と言えます。
最低限、エラー監視 (Sentry、Datadog)、外部 API の失敗、バッチの失敗を、誰かの手元に通知が届く形にする。リリース日から「監視している人がいる」状態を作ることが、Vibe Coding 案件では特に重要です。
事業上の被害: 顧客に指摘されるまで障害に気づけません。
8. デプロイが属人化していて、戻せない
Vibe Coding で作ったシステムは、開発者がローカルから直接サーバーに push していたり、ステージング環境がなかったりすることがあります。これが「不具合を直そうとして、別のところを壊す」事故の温床になります。
最低限、main ブランチへの merge = 自動ステージングデプロイ、タグ打ち = 本番デプロイ くらいの自動化は、本番投入前に入れる。リカバリのために前バージョンに戻せる仕組み (Vercel のロールバック、Cloud Run のリビジョン) を確認しておく。
事業上の被害: 修正のたびに別の障害が起き、改善速度が落ちます。
ここまでの項目に複数当てはまる場合、本番投入前に一度、コードと運用フローを外部の目で確認した方が安全です。min's では、AI で作ったプロトタイプのコードレビュー・設計レビューだけでも対応しています。
AI で作ったシステムを本番化する前のチェックリスト
事業で運用していくシステムを、AI で作ったプロトタイプから本番化する判断材料として、最低限見るべきポイントを整理します。発注前のセルフチェックにも使えます。
| 項目 | 確認すること | 見落としたときに起きること |
|---|---|---|
| ドメインモデル | 注文・契約・予約などが、状態・履歴・整合性を扱える形になっているか | 機能追加のたびにデータが壊れやすくなる |
| テナント境界 | データ取得時に必ずテナントが絞られるか | 他社データの閲覧・編集リスクが出る |
| 権限境界 | 役割ごとに見える範囲・編集できる範囲が定義されているか | 担当者が不要な情報を見たり編集したりする |
| 整合性 | 同時利用、注文と入金、予約と取消などの整合性が保てるか | 二重予約、二重請求、在庫ズレが起きる |
| 冪等性 | Webhook やバッチが同じイベントを 2 回受けても壊れないか | 二重送信、二重決済、二重登録が起きる |
| 監査ログ | 金銭・個人情報・契約状態の変更履歴が残るか | 問い合わせや監査に対応できない |
| エラー監視 | 本番エラーが担当者に通知されるか | 顧客に言われるまで障害に気づけない |
| デプロイ | ステージング、本番、ロールバックが定義されているか | 修正時に別の障害を起こしやすい |
| テスト | 重要フローの最低限の自動テストがあるか | 改修のたびに重要機能が壊れる |
| Runbook | 障害時に誰が、何を見て復旧するか書かれているか | 担当者不在時に復旧できない |
10 項目すべてを最初から揃える必要はありません。事業フェーズによって、優先順位を決めるのが現実的です。
| フェーズ | 優先すべき項目 |
|---|---|
| 検証中の MVP | ドメインモデル、テナント境界、権限境界、重要データの監査ログ |
| 初期顧客に提供開始 | 上記に加えて、冪等性、エラー監視、最低限の自動テスト |
| 継続課金・複数社運用 | 上記に加えて、ステージング、本番デプロイ、ロールバック、Runbook |
| 複数拠点・複数担当者で運用 | 権限設計、監査ログ、運用ドキュメント、問い合わせ対応フローを強化 |
Anthropic の創業者向けプレイブックでも、AI ネイティブ・スタートアップは Idea → MVP → Launch → Scale の段階ごとに、必要なアーキテクチャとセキュリティ実装は変わる、という考え方が示されています (The founder's playbook / Anthropic)。全部を綺麗にする必要はなく、フェーズに応じた最低ラインを引くのが現実的です。
そのプロトタイプは、直して使えるのか、作り直すべきか
AI で作ったシステムを見たとき、min's では最初に「全部作り直すべきか」ではなく、「残してよい部分」と「作り直すべき部分」を分ける ところから入ります。
| 観点 | 残しやすい部分 | 作り直しを検討する部分 |
|---|---|---|
| 画面 | LP、管理画面の見た目、単純な入力フォーム | 権限によって表示が変わる複雑な画面 |
| API | 単発の取得・更新 API | 決済、予約、請求、在庫など整合性が必要な API |
| DB | マスターデータ、単純な一覧データ | 状態遷移、履歴、金額、契約に関わるデータ |
| 外部連携 | 通知、メール送信、単純な CSV 出力 | Webhook、決済、会計、基幹システム連携 |
| インフラ | Vercel などのホスティング設定 | 環境分離、監視、ロールバック、秘密情報管理 |
すべてを捨てる必要はありません。ただし、事業上のリスクが高い部分 (右側のカラム) だけは、プロトタイプの勢いのまま本番投入せず、設計から見直した方が安全です。
セキュリティ観点での見直しについても、すべての脆弱性を最初から潰す必要はありません。Anthropic のセキュリティチームが書いた解説では、AI を使った脆弱性管理のボトルネックは「発見」ではなく「検証・トリアージ・修正」に移っているとされています (Using LLMs to Secure Source Code / Anthropic)。何が出てきたか、どれが本当に直すべきか、を判断する人間の工程に時間がかかる。Vibe Coding 由来のコードベースを本番化する仕事は、まさにこの判断作業の連続です。
min's が支援できること: レビュー、設計、本番化、運用改善
「Vibe Coding で作ったものを、min's に全部作り直してもらう」必要は、たいていの場合ありません。プロトタイプを残したまま、危ない部分だけ作り替える のが最短ルートになることが多くあります。
具体的に、min's に持ち込まれる相談の典型的なパターンは以下のとおりです。
- コードレビュー: 1〜2 週間でコードベースを読み、本番化の優先順位を整理する診断
- 設計レビュー: 認証・権限・データモデル・整合性まわりだけ作り直す
- 本番化リファクタ: 重要パスだけ作り直し、残りは Vibe Coding のものを継続利用する
- 運用設計: 監視・通知・ロールバックを入れて、最低限の保守ができる状態にする
- 継続支援: リリース後の改善 (機能追加、不具合対応、AI 機能の本番化) を月単位で並走する
「いま動いているもの」を残したまま本番化する判断は、コードと運用フローを実際に見ないと出せません。GitHub または Vercel のアクセスを共有いただいた上で、まずは状態の整理から始めるのが一般的な進め方です。
Vibe Coding を止める必要はありません。むしろ、最初の仮説検証を速く進めるには非常に有効です。min's が支援できるのは、その先にある「本番で使える状態」までの段差を埋めることです。
AI で作ったプロトタイプの本番化に不安がある方へ
min's では、Vibe Coding や AI 開発ツールで作ったプロトタイプのレビュー、本番化設計、運用改善を支援しています。
以下のような状態であれば、一度ご相談ください。
- Lovable / Cursor / Claude Code / Codex で作ったものを、これから本番に出したい
- すでにユーザーが使い始めているが、障害や手作業が増えている
- 認証、権限、決済、予約、請求まわりに不安がある
- 作り直すべきか、今のコードを活かせるか判断したい
- 開発者が抜けて、運用・改修できる人がいない
まずはコードレビュー・設計レビューだけでも対応できます。
次に読む記事
参考
- Introducing Codex / OpenAI — Codex のクラウドベース実行モデル、サンドボックス、コード生成・PR 提案の流れ
- Codex Subagents / OpenAI Developers — 複数エージェントの並列実行と統合
- Claude Code docs / Anthropic — Claude Code のファイルシステム探索、CLAUDE.md による文脈付与
- The founder's playbook / Anthropic — AI ネイティブ・スタートアップの Idea / MVP / Launch / Scale フレーム
- Using LLMs to Secure Source Code / Anthropic — AI セキュリティレビューにおける検証・トリアージ・修正の重要性