バイブコーディングの試作を開発会社に引き継ぐとき、渡すべき7つのもの

「バイブコーディングで動くところまで作った試作を、そろそろ開発会社に相談して本番品質にしてもらいたい」——そう考えたとき、多くの人が最初につまずくのは「何を渡せば、話が伝わるのか」という点です。動くコード一式を送りさえすれば、あとは開発会社が全部読み解いてくれるだろう、と考えてしまいがちですが、実際にはそう単純ではありません。

この記事では、バイブコーディングの試作を開発会社に引き継ぎ、本番化を依頼するときに渡すべき7つの資材と、渡す順序・伝え方を解説します。

この記事で分かること

試作を開発会社に引き継ぐときの最大の壁は、「動くものは見せられるが、なぜそう作ったかを説明できない」という状態です。この記事では、その壁を越えるために準備しておくべきものを整理します。

結論を先に示すと、渡すべきものは次の7つです。

• 動くコード一式とリポジトリへのアクセス権（前提として最低限必要）
• プロンプトのやり取りの履歴（何を意図してその実装になったかの記録）
• 使っているデータの構造と、実データのサンプル（本番で扱うデータの形）
• 外部サービス・APIキーの一覧と契約状況（見えない依存関係の全体像）
• 今の試作でできること・できないことの自己申告メモ（AIと自分だけが知っている限界）
• 想定ユーザー数・利用シーンの見込み（スケールの前提を揃えるため）
• 予算感と、削ってもよい機能の優先順位（現実的な着地点を早く決めるため）

これらは、どれも「試作を作った本人にしか分からない情報」という共通点があります。開発会社は動くコードを読めば実装の詳細は把握できますが、「なぜこの設計にしたのか」「どこまでが仮の実装で、どこからが本気で作った部分か」は、コードだけからは読み取れません。まず、なぜこのギャップが生まれるのかから見ていきましょう。

なお、引き継いだ後に本番品質へ引き上げる際の技術的な視点については、バイブコーディングの試作を、本番品質に引き上げる3つの視点で詳しく解説しているので、あわせて参考にしてほしい。この記事は、その前段階——「開発会社に何を渡せば、話がスムーズに進むか」に焦点を当てる。

なぜ「動くコードを送るだけ」では伝わらないのか

バイブコーディングで試作を作る過程では、AIとの対話を通じて、無数の小さな判断が積み重なっています。「この画面はまず簡易版でいい」「ここのエラー処理は後回しにする」「このデータは今はハードコードで仮置きしている」——こうした判断は、作っている本人の頭の中には自然に残っていますが、コードそのものには残りません。

開発会社のエンジニアが、いきなりリポジトリを渡されて「これを本番化してください」と言われたとき、最初にやることは「このコードが何を意図して書かれたか」を推測する作業です。コメントが少なく、変数名も試作段階の思いつきのままだと、この推測にかなりの時間がかかります。見積もりを出す前の調査だけで数日〜1週間かかることも珍しくありません。この調査時間は、当然ながら見積もり金額にも跳ね返ります。

つまり、引き継ぎ資材を用意する目的は「開発会社に気を遣うため」ではなく、「調査の時間を減らし、その分を実際の開発に振り向けてもらうため」です。ここを理解しておくと、以下の7つが単なる事務作業ではなく、費用と納期に直結する準備だと分かるはずです。

なお、この調査時間は開発会社側の見積書では「要件整理」「要件定義」といった工程名で計上されることが多く、引き継ぎ資材が薄いほどこの工程の工数が膨らむ構造になっています。逆にいえば、資材の準備は「タダ働きの事前奉仕」ではなく、見積もりに反映される実質的なコスト削減策だと捉えると、準備にかける時間の意味が変わってくるはずです。

渡すもの1：動くコード一式とリポジトリへのアクセス権

最低限の前提として、動くコード一式と、それを管理しているリポジトリ（GitHubなど）へのアクセス権が必要です。当たり前に思えるかもしれませんが、実際には次のような抜け漏れがよく起きます。

• ローカルにしかコードがなく、Gitで管理されていない
• Gitで管理はしているが、リモートリポジトリに push していない
• 複数のバージョンが混在していて、どれが最新か本人も分からなくなっている

バイブコーディングでは、AIとの対話の中で試行錯誤を繰り返すため、気づけばローカルのフォルダに「app」「app_v2」「app_final」のような複数バージョンが並んでいる、という状態になりやすいものです。開発会社に渡す前に、最低でも「これが最新で動く版」という1本に整理し、Gitのコミット履歴として残しておくと、渡した後の混乱を防げます。

Gitを使ったことがない場合は、AIコーディングツール自体にGit連携機能が付いていることが多いので、渡す準備をする段階で使い方を確認しておくとよいでしょう。

準備の際にチェックしておきたい項目を、簡単なチェックリストとして挙げておきます。

• リポジトリが1つに統一されているか（複数バージョンが残っていないか）
• 最新のコミットに、動作確認済みの状態が反映されているか
• 開発会社側のアカウントを招待できる権限を、自分が持っているか（会社名義で契約していた場合など、権限が他人にある場合は要確認）
• README（このアプリが何をするものか、簡単に説明したファイル）があるか。なければ、この機会に数行だけでも書いておく

README は必須ではありませんが、「このアプリは何のために、誰向けに作ったものか」を数行書いておくだけで、開発会社側の最初の理解がスムーズになります。バイブコーディングのAIに「このプロジェクトの概要をREADMEとしてまとめて」と指示すれば、数分で下書きを作成できます。

渡すもの2：プロンプトのやり取りの履歴

コードそのものよりも、実は開発会社にとって価値が高いのが、AIとやり取りしたプロンプトの履歴です。「なぜこの機能をこう作ったのか」「途中でどんな要件変更があったのか」という経緯が、この履歴には残っています。

たとえば「予約の重複を防ぐ機能を追加して」という指示を出し、AIが特定のロジックで実装したとします。コードだけを見た開発会社のエンジニアは「なぜこの実装方法を選んだのか」が分かりませんが、プロンプト履歴があれば「この時点でユーザーからこういう要望が出たから、こう対応した」という文脈が伝わります。

すべてのやり取りを渡す必要はありません。特に重要な判断があった部分（機能追加の指示、方針転換があった箇所、エラーに対する対処のやり取り）を抜き出して、時系列の簡単なメモにまとめておくだけでも、開発会社側の調査時間は大きく短縮されます。目安としては、A4で2〜3枚程度、経緯を追える形にまとめれば十分です。

渡すもの3：使っているデータの構造と、実データのサンプル

試作で扱っているデータの構造（どんな項目を、どんな形式で保存しているか）と、実際のデータのサンプル（個人情報を含む場合はダミー化したもの）を用意しておきます。

バイブコーディングでは、AIが裏側でデータベースの設計まで自動的に行っていることが多く、作った本人がその構造を正確に把握していないケースが少なくありません。「ユーザーの名前とメールアドレスを保存している」という認識はあっても、実際には「電話番号も別のテーブルに保存されている」「同じ情報が2箇所に重複して保存されている」といった、本人も気づいていない設計になっていることがあります。

開発会社に依頼する前に、AIコーディングツールに「今のデータベースの構造を、表形式で一覧にして」と指示してみると、自分でも把握していなかった構造を可視化できます。この一覧と、数件のサンプルデータ（本番の個人情報をそのまま渡すのは避け、ダミーデータに置き換える）を用意しておくと、開発会社側は「今、何が、どこに保存されているか」を素早く理解できます。

渡すもの4：外部サービス・APIキーの一覧と契約状況

バイブコーディングで作った試作は、決済、メール送信、地図表示、AI機能など、複数の外部サービスと連携していることが多くあります。これらの外部サービスは、コードを読むだけでは全体像が見えにくい「隠れた依存関係」です。

引き継ぎ時には、次の情報を一覧にしておきます。

• 利用している外部サービス名（決済、メール配信、認証、ストレージなど）
• 各サービスの契約プラン（無料枠か有料プランか）
• APIキーの管理場所（環境変数ファイル、サービスの管理画面など）
• 各サービスの契約者本人（自分のアカウントか、法人アカウントか）

見落としがちなのが、無料枠のAPIキーをそのまま使い続けていて、本番公開後にアクセスが増えると急に利用制限に引っかかる、というケースです。開発会社側は、この一覧を見ることで「本番化にあたってどのサービスを有料プランに切り替える必要があるか」を早い段階で判断できます。実際の見積もりにも、この外部サービスの費用が上乗せされることが多いため、事前に一覧化しておくことは費用感を早くつかむ意味でも重要です。

渡すもの5：今の試作でできること・できないことの自己申告メモ

開発会社に「このアプリを本番化してください」とだけ伝えると、相手は動くコードを一つ一つ検証しながら、できること・できないことを洗い出す作業から始めることになります。この作業自体に工数がかかるため、見積もりの前提として時間がかかりすぎたり、逆に見落としが起きたりします。

そこで有効なのが、作った本人による「自己申告メモ」です。次のような観点で、正直に書き出しておきます。

• ちゃんと動作確認できている機能
• 一応動くが、まだ十分にテストしていない機能
• 見た目だけ作って、中身のロジックがまだ仮の状態の部分
• AIに何度指示しても直せなかった不具合や、原因が分からないエラー

特に最後の項目は、正直に書くことに抵抗を感じるかもしれません。「こんな初歩的なところでつまずいているのを知られたくない」という気持ちは自然なものですが、隠したまま引き継ぐと、開発会社が同じ問題に時間を溶かしてしまい、結果的に費用と納期に跳ね返ります。AIがバグを直せなくなったとき、次にどうすればいいかで紹介したような「AIでは解決できなかった壁」こそ、開発会社に正直に共有すべき情報です。

渡すもの6：想定ユーザー数・利用シーンの見込み

試作段階では、多くの場合「自分一人で動作確認する」ことを前提に作られています。しかし本番公開後は、想定ユーザー数によって必要な設計がまったく変わってきます。

• 月に数十人程度が使う小規模なサービスなのか
• 数百〜数千人が同時にアクセスする可能性があるのか
• 特定のタイミング（イベント開催時など）にアクセスが集中する見込みがあるのか

この見込みが曖昧なまま開発会社に相談すると、「念のため大きめの構成で見積もる」か「小さく作って後で困る」かのどちらかに偏りがちです。前者は不要なコストの上乗せに、後者は本番公開後の障害対応につながります。正確な数字を出す必要はありませんが、「まずは知人と地域の同業者、数十人規模で始めたい」といった程度の見込みを伝えるだけでも、開発会社は適切な規模の設計を提案しやすくなります。

渡すもの7：予算感と、削ってもよい機能の優先順位

最後に、そしてもっとも重要なのが、予算感と「削ってもよい機能の優先順位」です。開発会社に相談する多くの人が、予算を先に伝えることに抵抗を感じます。「先に予算を言うと、その金額まで見積もりを釣り上げられるのでは」という不安があるためです。

しかし、予算感を伝えないまま相談すると、開発会社は「フルスペックで対応した場合」の見積もりを出すことが多く、結果として金額が想定より大きく膨らみ、そこから機能を削る交渉に余計な時間がかかります。自己資金300万円前後で立ち上げを考えている場合、その前提を早い段階で共有したほうが、現実的な提案を早く引き出せます。

あわせて、「この機能は絶対に外せない」「この機能は本番化の第一弾では削ってもいい」という優先順位を、試作を作った本人の視点で整理しておきます。開発会社は技術的な難易度は判断できますが、「どの機能がサービスの核なのか」は、事業の当事者にしか判断できません。この優先順位があると、限られた予算の中で何を先に作るかの合意形成がスムーズになります。

「もっと自分で作り込んでから引き継ぐ」か「早めに引き継ぐ」か

引き継ぎのタイミングについても、迷う人が多いところです。「もう少し自分で完成度を上げてから相談したほうが、費用も抑えられるのではないか」という考えは自然に浮かびますが、実際には一概にそうとは言えません。両方の進め方にはそれぞれメリット・デメリットがあります。

どちらが正解ということはなく、扱うデータの性質によって判断が変わります。個人情報や決済情報のように、後から設計をやり直すのが難しい・リスクが大きい部分を含む試作は、早めに開発会社に見てもらったほうが安全です。逆に、画面のレイアウトや文言のように、後からいくらでも直せる部分は、自分でひととおり作り込んでから引き継いでも大きな支障はありません。

判断に迷う場合は、「もう自分では無理」と判断するタイミングの見極め方で紹介している基準もあわせて参考にしてください。「まだ頑張れる部分」と「早く専門家に見てもらうべき部分」を切り分けて考えると、引き継ぎのタイミングも判断しやすくなります。

引き継ぎがうまくいった場合と、うまくいかなかった場合の分かれ目

引き継ぎの成否を分けるのは、多くの場合「技術力の差」ではなく、「情報の伝わり方」です。ここまで紹介した7つの資材が揃っている場合と、揃っていない場合とで、実際に何が変わるのかを整理します。

資材が揃っている場合の進み方

初回の打ち合わせで、開発会社側は動くコードとプロンプト履歴、データ構造の一覧を見ながら「ここは仮実装なので作り直しが必要」「ここはそのまま使える」という切り分けをその場で進められます。見積もりに必要な調査期間が短くて済むため、初回相談から1〜2週間程度で見積もりが提示されるケースが多くなります。予算感と機能の優先順位が事前に共有されていれば、「予算内でどこまで実現できるか」の擦り合わせも初回のうちに進められます。

資材が揃っていない場合の進み方

コードだけを渡された場合、開発会社はまず社内でコードを読み解く調査フェーズを設けることになります。この調査には、コードの複雑さにもよりますが数日から数週間かかることがあり、その期間は見積もりも確定しません。調査の途中で「この部分の意図が分からないので教えてほしい」という質問が都度発生し、やり取りが長引きます。また、想定ユーザー数や予算感が共有されていないと、開発会社は「安全側に倒した、余裕を持った規模」で見積もりを出さざるを得ず、結果として金額が想定より高く出ることがあります。

このように、引き継ぎ資材の有無は、単なる丁寧さの問題ではなく、初回相談から見積もり確定までの期間と、見積もり金額そのものに影響します。

費用感の目安：引き継ぎの準備次第で何が変わるか

引き継ぎ後の本番化費用は、試作の完成度・扱う機能の複雑さによって大きく変わるため一律には言えませんが、引き継ぎ資材の準備状況によって、見積もりまでのプロセスに次のような違いが出やすい傾向があります。

• 調査フェーズの有無：資材が揃っていれば調査フェーズが短縮され、その分の工数（人件費）が見積もりから減る可能性がある
• 手戻りの発生確率：自己申告メモで「仮実装の部分」が明示されていれば、開発会社が「完成している部分」として誤って見積もりに含めてしまう手戻りを防げる
• 外部サービス費用の見落とし：APIキーの一覧を渡していないと、後から「このサービスも有料プランへの切り替えが必要だった」と判明し、追加費用が発生することがある

見積書の内訳（工数・単価・バッファ）の読み方そのものについては、見積書の内訳（工数・単価・バッファ）の読み方で詳しく解説しているので、引き継ぎ資材を渡した後、実際に見積もりが出てきた段階であわせて確認するとよいでしょう。

また、引き継ぎ資材を整理する過程で「これは自分では判断できない」という項目が出てくることもあります。たとえば、外部サービスの契約形態がAPIの従量課金なのか定額なのか本人も把握していない、といったケースです。こうした不明点は無理に自分で調べ切ろうとせず、「ここは分からないので確認したい」とメモに残しておくだけで構いません。開発会社側もすべてが最初から明確な状態を求めているわけではなく、不明点が可視化されていること自体が、調査の出発点として価値を持ちます。

7つを準備する順番と、実際の進め方

ここまで紹介した7つを、すべて完璧に揃えてから相談する必要はありません。開発会社に依頼する現実的な進め方の目安を示します。

最初から完璧な資料を作ろうとして時間をかけすぎるより、コードと最低限のメモを持って早めに相談し、開発会社からの質問に答えながら残りの情報を揃えていく進め方のほうが、結果的に早く本番化にたどり着けます。開発会社に相談する前に決めておきたいことの全体像は、開発会社に相談する前に、決めておきたい3つのことでも整理しているので、あわせて確認しておくとよいでしょう。

引き継ぎでよくある失敗パターンと回避策

実際に引き継ぎの場面でつまずきやすいパターンを、3つ紹介します。

失敗パターン1：「全部渡したのに伝わらない」

チャットのスクリーンショットやコード全文をそのまま大量に送りつけると、かえって開発会社側が「どこが重要な情報か」を判別できず、調査の負担が増えてしまいます。情報は「量」ではなく「要点を抜き出した状態」で渡すことが重要です。上記の7つの資材は、それぞれ1〜2ページ程度にまとめる意識を持つと、渡された側も読みやすくなります。

失敗パターン2：「見た目が完成しているから、中身も完成していると誤解される」

バイブコーディングは画面のデザインまで一気に作り込めるため、見た目だけを見た開発会社が「ほぼ完成している」と誤解し、見積もりが実態より低く出てしまうことがあります。渡すもの5の自己申告メモで「見た目は完成しているが、ロジックは仮実装」という点を明示しておくことが、この誤解を防ぐ鍵になります。

失敗パターン3：「渡した後、自分は何もしなくていいと思ってしまう」

引き継ぎが完了した後も、事業の当事者にしか分からない判断（機能の優先順位、ユーザーからの要望の解釈など）は発生し続けます。渡して終わりではなく、開発会社との定例的なやり取りの中で、業務知識を伝え続ける役割が残ることを最初から理解しておくと、引き継ぎ後のコミュニケーションがスムーズになります。専門分野の業務知識をどう伝えるかについては、専門分野の業務知識を、開発会社に正確に伝える工夫で詳しく扱っています。

「専門職スピンオフ型」が引き継ぐときに特に気をつけたいこと

士業やコンサルタント、デザイナーなど、深い専門知識を持つ人が、自分の業務ノウハウをツール化した試作を引き継ぐ場合は、上記7つに加えてもう一つ意識しておきたい点があります。それは、専門知識そのものが、コードの中に「暗黙のロジック」として埋め込まれているということです。

たとえば、税理士が自分の判断基準をもとに「この条件ならA、この条件ならBと表示する」というロジックをAIに指示して実装した場合、そのロジックの妥当性そのものは、開発会社のエンジニアには判断できません。エンジニアが検証できるのは「指示された通りに動いているか」であって、「その判断基準が専門的に正しいか」ではないのです。

このケースでは、7つの資材に加えて、判断ロジックの根拠となる専門知識を、簡単な図や表にして渡すことをおすすめします。「なぜその条件分岐になっているのか」を専門用語込みで説明したメモがあると、開発会社側は「ここは専門判断が入っている部分だから、安易に処理を変更してはいけない」と認識でき、意図しない改変を防げます。専門用語が多い業界特有の発注については、専門用語が多い業界の発注で、事前に用語集を渡すべき理由でも扱っているので、あわせて確認しておくと引き継ぎの精度が上がります。

「店舗・地域事業者DX型」が引き継ぐときに特に気をつけたいこと

自分の店の業務改善のために作った試作を、同業の他店にも展開できるサービスとして本番化したい、というケースも増えています。この場合、上記7つに加えて、「自店専用に最適化されている部分」と「他店でも汎用的に使える部分」の切り分けを、引き継ぎ資材に含めておくことが重要です。

自分の店のために作った試作は、店名や営業時間、独自の商品分類などが、コードの中に直接書き込まれている（ハードコードされている）ことがよくあります。これをそのまま他店向けに展開しようとすると、店舗ごとに設定を切り替えられる仕組み（マルチテナント化）への作り直しが必要になり、想定以上に大きな改修になることがあります。この点は、自分だけで使っていたツールが、他の人にも使われ始めたときの壁でも詳しく扱っています。引き継ぎ時には「これは今のところ自店専用で作った部分です」と明示しておくことで、開発会社側が最初から汎用化を前提とした設計を提案しやすくなります。

まとめ：この記事で持ち帰れること

ここまで、バイブコーディングの試作を開発会社に引き継ぐ際の準備について見てきました。この記事で持ち帰れることは、次の2点です。

• 動くコードだけでは、開発会社に「なぜそう作ったか」が伝わらないという前提を理解し、プロンプト履歴・データ構造・自己申告メモといった「判断の記録」を残しておくことの重要性
• 予算感と機能の優先順位を早い段階で共有したほうが、現実的な提案を早く引き出せるという、相談の進め方の実践的な目安

試作を作り上げた達成感のあとには、「これを他人に説明する」という、これまでとは違う種類の作業が待っています。多くの場合、この作業は数時間〜1日程度、資料を整理する時間を取るだけで十分です。まずは今日、自分の試作について「何が動いていて、何がまだ仮の状態か」を、5行程度でいいのでメモに書き出してみることから始めてみてください。それだけでも、次に開発会社へ相談するときの心構えがずいぶん変わってくるはずです。

準備が整ったら、開発会社の頼み方カテゴリの記事もあわせて参考にしながら、初回相談に臨んでみてください。要件がまだ固まっていなくても、費用感を含めて相談することは可能です。