バイブコーディングのプロトタイプを製品化するには：「動くデモ」と「使える製品」を隔てる3つの壁
バイブコーディングで作ったプロトタイプは、そのままでは製品になりません。しかし、だからといって「全部作り直し」が正解とも限りません。結論から言うと、動くデモと業務で使い続けられる製品の間には仕様・品質・運用という3つの壁があり、製品化とはこの3つを計画的に越える作業です。そして、プロトタイプの価値の中心はコードそのものではなく「何が業務の役に立つかを検証済みである」という事実にあるため、壁がどれだけ高くても、プロトタイプ作りに費やした時間が無駄になることはありません。
本記事では、3つの壁の中身、「育てるか作り直すか」の判断軸、製品化前に確認すべきチェックリストの順に整理します。
「動くプロトタイプ」は製品開発の何割を終えているのか
バイブコーディング（vibe coding）とは、LLM（大規模言語モデル）に自然言語で指示を出し、生成されたコードを深く検証せずに採用しながら開発を進めるスタイルを指します。用語の定義と、このスタイルが生む技術負債の構造についてはAI駆動開発が生む技術負債リスクで詳しく扱っているため、本記事では「すでにプロトタイプがある」状態から先を考えます。
まず押さえるべきは、プロトタイプが検証しているのは**「何を作るべきか」という要求の部分**である、という点です。ソフトウェア開発で最も手戻りコストが大きいのは、作るべきものを取り違えることです。現場の担当者が自らAIと対話しながら「この画面で、この順番で、この情報が出れば業務が回る」ことを確かめたプロトタイプは、外部の開発会社が要件定義書から作った初版よりも、要求の面でははるかに確度が高いことが珍しくありません。
一方で、製品として使い続けるために必要な作業の多く——複数人での同時利用、権限管理、異常系の処理、データの保全、運用の引き継ぎ——は、プロトタイプ段階ではほぼ手つかずです。つまり「動くプロトタイプができた」状態は、開発の5割が終わった状態ではなく、最も不確実な工程が終わり、残りの作業が見積もり可能になった状態と捉えるのが正確です。
プロトタイプと製品を隔てる3つの壁
残りの作業は、性質の異なる3つの壁に分けて考えると整理しやすくなります。
仕様の壁：暗黙の前提が本人とAIの対話履歴にしかない
プロトタイプの「仕様」は、多くの場合、作った本人の頭の中とAIとの対話履歴にしか存在しません。「この列は空欄でも動くはず」「この日付は月末締め前提」といった暗黙の前提は、本人が異動・退職した瞬間に失われます。製品化の最初の作業は、コードを書くことではなく、プロトタイプを触りながら暗黙の前提を仕様として書き出すことです。このとき、想定外の入力（空欄・重複・過去日付・文字化けなど）に対してどう振る舞うべきかというエッジケースの洗い出しも同時に行います。
品質の壁：正常系しか確認されていない
プロトタイプは「うまくいくケース」で動作確認されています。しかし業務での利用は、想定外の入力・複数人の同時操作・途中での中断といった「うまくいかないケース」の連続です。特に確認が必要なのは、ログインと権限管理（誰が何を見られるか）、データの保全（誤操作からの復旧手段があるか）、そして扱う情報の機密性（顧客情報や個人情報を入れてよい作りか）の3点です。少人数のチームで品質をどう担保するかという観点はコードレビューと品質ゲートの最小構成でも扱っています。
運用の壁：動かし続ける仕組みがない
作った本人のPCでしか動かない、更新のたびに手作業でファイルを配る、止まったことに誰も気づけない——プロトタイプには「動かし続ける仕組み」がありません。製品化では、配布とデプロイ（利用者に届ける手段）、バックアップ、エラーの検知、そして改修を誰がどう行うかという体制までを設計します。運用の壁は技術というより体制の問題であり、後述する「誰と進めるか」の選択に直結します。
「育てる」か「作り直す」か：5つの判断軸
3つの壁を前にしたとき、既存のプロトタイプを土台ごと育てるのか、仕様だけ引き継いで作り直すのかという判断が必要になります。以下の5つの軸で評価すると、判断の再現性が上がります。
| 判断軸 | 「育てる」に寄る条件 | 「作り直す」に寄る条件 |
|---|---|---|
| データ構造 | 業務の実態に合った構造になっている | 手元ファイル前提で、複数人利用に耐えない |
| 業務ロジック | 複雑で、現場での検証が進んでいる | 単純で、書き直しのコストが小さい |
| 土台（認証・権限） | 既存の基盤（社内SaaS等）に乗っている | 認証がなく、後付けが構造的に難しい |
| 利用範囲 | 作った本人と少人数の利用にとどまる | 部門をまたぎ、障害時の影響が大きい |
| コードの状態 | 一貫性があり、AIで読み解ける規模 | 継ぎ足しが多く、挙動の再現が困難 |
ここで強調したいのは、「作り直す」判断はプロトタイプを捨てることを意味しないという点です。作り直す場合でも、プロトタイプは「実行可能な仕様書」として機能します。新しい実装が正しいかどうかを、プロトタイプの挙動と突き合わせて検証できるためです。技術負債の一般論として「何が負債で何が資産か」を切り分ける考え方は技術負債とは結局何かで整理しています。
製品化の前に確認する10項目チェックリスト
製品化に着手する前に、以下の10項目を確認することを推奨します。前半5項目は現状把握、後半5項目は製品化の設計に関わる項目です。
- 仕様の所在：プロトタイプの動作前提を説明できる資料が、対話履歴以外に存在するか
- データの所在：業務データがどこに保存され、誰がアクセスできる状態か
- 機密性：顧客情報・個人情報・取引情報が含まれているか（含まれるなら扱いの基準はあるか）
- 利用実態：誰が・どの頻度で・どの業務のために使っているか
- 停止時の影響：ツールが1週間止まった場合、業務にどの程度の支障が出るか
- 利用者の範囲：今後誰まで使わせたいか（本人のみ／チーム／部門／社外）
- 権限の要件：利用者によって見せてよい情報・操作してよい範囲が異なるか
- 既存システムとの関係：会計・販売管理など既存システムと重複・連携する部分はあるか
- 改修の担い手：完成後、誰が直し続けるのか（本人／社内の別担当／外部）
- 投資判断の基準：製品化にかける費用の上限と、それに見合う効果の見立てがあるか
このうち3・5・7のいずれかで重大な懸念がある場合——機密情報を扱い、停止の影響が大きく、権限の要件が複雑な場合——は、品質の壁を自己流で越えるリスクが大きいため、専門家のレビューを挟むことを推奨します。
誰と製品化を進めるか：内製・外注・伴走の使い分け
最後に体制の選択です。選択肢は大きく3つあります。
内製で進める：社内にエンジニアがいる場合の第一候補です。注意点は、作った本人（業務知識の保有者）とエンジニア（実装の担い手）の間で仕様の翻訳が必要になることです。プロトタイプを挟んで両者が会話する場を設計しないと、要求の確度というプロトタイプ最大の資産が失われます。
開発会社に外注する：まとまった開発力を短期間で確保できますが、「プロトタイプを仕様書代わりに渡して丸投げ」には落とし穴があります。検証済みの業務知識が要件定義の過程で削ぎ落とされやすいこと、そして完成後の改修が再び外部依存になることです。発注する場合も、作った本人がレビューに関与し続ける体制を契約に織り込むべきです。
伴走型で進める：専門家がチームに入り、製品化を進めながら改修の知識を社内に引き継ぐ形です。作った本人が業務知識を持ったまま製品化に関与でき、完成後も社内で育てられる状態を目指せるのが利点です。Tiedでもプロトタイプ製品化支援として、査定から土台の実装・引き継ぎまでを伴走型で提供しており、判断に迷う段階でのご相談も受け付けています。
まとめ
バイブコーディングで作ったプロトタイプは、要求の検証という最も不確実な工程を終えた資産です。製品化とは、その資産を仕様の壁・品質の壁・運用の壁の3つを越えて業務の基盤に据える作業であり、「育てるか作り直すか」は感覚ではなく、データ構造・業務ロジック・土台・利用範囲・コードの状態という5つの軸で判断できます。作り直す場合でも、プロトタイプは実行可能な仕様書として機能し続けます。
AI駆動開発が生むリスクの構造はAI駆動開発が生む技術負債リスク、少人数での品質担保はコードレビューと品質ゲートの最小構成、負債と資産の切り分けは技術負債とは結局何かで、それぞれ詳しく解説しています。
よくある質問
Q. プロトタイプは結局すべて作り直すことになりますか？
必ずしもそうではありません。検証済みの業務ロジックや画面の流れは資産として残し、認証・データ管理などの土台だけを再構築するケースが多くあります。また、仮にコードを作り直す場合でも、プロトタイプは「実行可能な仕様書」として機能するため、そこに蓄積された業務知識が失われるわけではありません。
Q. 非エンジニアが作ったプロトタイプでも製品化できますか？
できます。むしろ業務を最もよく知る人が作ったプロトタイプは、要求の検証という最も不確実な工程を終えている点で価値が高いといえます。製品化の際は、作った本人が持つ業務知識を仕様として明文化する工程を挟むことが重要です。
Q. 製品化にはどれくらいの期間がかかりますか？
プロトタイプの規模と目指す製品の範囲によりますが、社内ツールであれば土台の再構築とデータ移行を含めて1〜3ヶ月程度から始めるのが現実的です。一度にすべてを製品水準にするのではなく、利用者数と扱うデータの重要度が高い部分から段階的に整備する進め方を推奨します。