開発方針を相談する

AI で作ったプロトタイプを、事業で使えるシステムに育てる方法

デモから本番へ。AI 生成プロトタイプを、継続利用できるプロダクトに変える手順。

この記事の結論

Vibe Coding で作ったシステムが、本番で使えない理由 では「なぜ本番で詰まるのか」を整理しました。この記事はその続編として、詰まったプロトタイプを、捨てずに本番へ育てる手順 を扱います。

min's に持ち込まれる相談のうち、AI で作ったプロトタイプを「全部作り直す」が必要な案件は多くありません。多くの場合、重要な部分だけ作り直し、残りはプロトタイプを継続利用する のが最短で最も安いルートです。

ただし、その判断と作業順序は経験がないと難しい。誤った順序で改修すると、半年経っても本番投入できないまま、改修費だけ膨らんでいきます。この記事では、min's が実際に支援するときの 7 ステップを公開します。

ステップ 1: 診断 (1〜2 週間)

最初の 1〜2 週間は、コードを書きません。

OpenAI のドキュメントによれば、Codex は独立したクラウドサンドボックスでテストやリンタを実行できる設計とされています (Introducing Codex / OpenAI)。Claude Code も、ローカルのファイルシステムを直接たどってコードベースを理解する設計です (Claude Code docs / Anthropic)。診断フェーズではこれらの AI ツールを活用し、1 人のエンジニアでも 1 リポジトリの全体像を 3〜5 日で把握できる ようになりました。

診断のアウトプットは、たいてい以下の 3 つです。

  1. 充足マップ: 本番化チェックリスト 10 項目 × OK / 要改修 / 要作り直し
  2. 影響範囲マップ: 改修対象が他のどこに影響するかの依存図
  3. 優先順位リスト: 重要度 × 改修コストで並べた改修候補一覧

このアウトプットを発注者と一緒にレビューし、次のステップに進むかを判断します。

ステップ 2: 残す / 作り直す / 捨てる の仕分け

診断が終わったら、コードを 3 つに分けます。

区分例判断基準
残すLP、管理画面の見た目、CRUD、メール送信整合性リスクが低く、改修頻度も低い
作り直す認証、権限、決済、予約、請求、在庫整合性が崩れたら事業に直撃する
捨てる使われていない機能、過剰な管理画面運用観察で 1 ヶ月以上触られていない

「捨てる」の判断は意外と重要です。プロトタイプ段階で勢いで作った機能のうち、半分近くは実運用で使われていないことがあります。残しておくとテスト・保守コストだけが掛かり続けるので、勇気を持って削ります。

事業上の被害: 全部残そうとすると、保守費用が増えるだけでなく、新規機能追加のたびに「触っていない機能」の互換性確認が必要になり、改善速度が落ちます。

ステップ 3: 5 つの基盤領域の再設計 (1〜2 週間)

本番化案件で、ほぼ常に作り直しが入る 5 領域があります。

認証・テナント分離

「ログインできる」から「自社の他のお客さんのデータを見られない」境界まで作り込む。Clerk、Supabase Auth、Firebase Auth、Auth0 のいずれかをベースに、テナント識別子とロールを認証時点で確定させます。

権限境界

画面の if 文ではなく、データアクセス層 (Supabase RLS、Firestore Rules、Repository 層) で強制する設計に変える。

データモデル

状態フィールド 1 つで持つステータス管理を、イベント履歴 (append-only) + 状態派生に切り替える。請求、予約、契約など履歴が重要な業務では特に効果が大きい。

決済

Stripe Webhook の冪等性キー、解約フロー、返金の扱いを、設計段階から織り込む。Webhook が複数回届く前提でテーブルを設計します。

監査ログ

主要な状態変更 (作成・編集・削除・ステータス変更・課金) を、別テーブルに append-only で記録する仕組みを入れる。Domain Event / Outbox パターンが現実的な実装です。

これらは多くの場合、コードのほんの一部 (全体の 5〜15% 程度) ですが、この部分だけは妥協してはいけません。残りのコードはプロトタイプのまま使い続けられます。

ステップ 4: 重要パスの作り直し (2〜4 週間)

ステップ 3 の設計を、実コードに落とし込んでいきます。

進め方として効率的なのは、「重要パスから順に、新しい基盤に乗せ替えていく」 やり方です。たとえば、

  1. 新しい認証基盤と権限境界を作る
  2. 最も重要な業務 (予約 / 申込 / 課金) を、新しい基盤で動くように書き直す
  3. 古い実装は残したまま、フラグで切り替えられる状態にする
  4. 検証が済んだら古い実装を削除する

この方法だと、開発中もプロトタイプを止めずに済みます。社内で並行運用しながら、徐々に重要パスを新しい設計に移していきます。

OpenAI の Codex は、テスト出力やターミナルログを通じて作業の検証可能性を提供する設計とされています (Introducing Codex / OpenAI)。AI で実装速度を上げながら、テスト出力を都度確認するレビューサイクルを回すと、人間の判断は「設計とリスク」に集中できます。

ステップ 5: テストの導入 (継続)

「テストが 1 行もない状態のコードベース」が、Vibe Coding 案件では珍しくありません。本番化に向けて、最低限以下のテストを入れていきます。

全部を一度に書く必要はありません。「変更が入る部分から、変更前にテストを追加する」 という TDD-light な進め方が現実的です。AI に「この関数の振る舞いを保護するテストを書いて」と頼めば、テストコードのドラフトはすぐ出ます。

ステップ 6: 監視と通知の経路を作る (1 週間)

リリース日に最低限揃えておくべき監視・通知の最小セットは以下のとおりです。

Anthropic のセキュリティ解説でも、AI を使った脆弱性管理のボトルネックは「発見」ではなく「検証・トリアージ・修正」に移っているとされています (Using LLMs to Secure Source Code / Anthropic)。運用も同じで、何かが起きたあとに対応できる経路 を作ることが、リリース日の最低ラインです。

ステップ 7: 段階リリース

いきなり全顧客に出すのではなく、段階的にロールアウトします。

フェーズ対象確認すること
社内 dogfooding開発者・PM 数名主要フローが動くか
限定 α信頼できる 1〜3 顧客業務で実際に使えるか
限定 β5〜10 顧客同時利用で整合性が壊れないか
一般リリース全顧客KPI と運用フローが回るか

各フェーズで 1〜2 週間ずつ運用し、出てきた課題を解消してから次のフェーズへ進みます。

事業上の被害: 段階リリースを省くと、本番初日に全顧客のデータが壊れるリスクを抱えることになり、ロールバックの判断と顧客対応に時間が取られます。

ここまでの 7 ステップを、自社内だけで実行するのは難しい場合があります。特に診断と仕分けには、複数の AI で作られたコードベースを読み解く経験が必要です。min's では診断フェーズだけの依頼も受けています。

AI プロトタイプの本番化診断を依頼する →

期間と費用の目安

支援内容と期間の目安を、よくあるパターンで整理します。

パターン期間費用感
診断のみ1〜2 週間30〜80 万円
診断 + 重要部分のリファクタ4〜8 週間200〜500 万円
診断 + 本番化フル支援8〜16 週間400〜1,200 万円
上記 + リリース後の継続改善月単位で並走月 30〜100 万円

費用幅が大きいのは、プロトタイプの規模 (ファイル数、機能数、外部連携数) と、残せる部分・作り直すべき部分の比率によって、必要な人月が変わるためです。診断フェーズの終了時点で、より精度の高い見積もりを出します。

min's の本番化支援スタイル

min's では、本番化の支援を「全部受託する」のではなく、発注側のチームと並走しながら、判断と重要パスだけを請け負う スタイルを取ることが多いです。具体的には、

この形だと、プロトタイプを作った開発者を活かしながら、リスクの高い部分だけプロが見る ことができます。

AI で作ったプロトタイプの本番化に不安がある方へ

min's では、Vibe Coding や AI 開発ツールで作ったプロトタイプの本番化を支援しています。

以下のような状態であれば、ご相談ください。

まずは診断 (1〜2 週間) で、改修すべき範囲と優先順位を整理します。

次に読む記事

参考

動くデモで終わらせず
本番まで持っていく開発を

AI で作りかけたもの、止まりかけている開発、新しいプロダクトの構想。 まずは現状を整理するところから、ご相談ください。

開発方針を相談する概算見積もりを依頼する