内製と外注の線引き・本番への引き継ぎ

この章でわかること: 動く検証版(PoC)ができたあと、必ず来る分かれ道——「どこまで自分たちで持ち、どこからプロに渡すか」。その線引きの判断軸と、渡すときに揃えるべき引き継ぎ一式です。

PoC と本番は、そもそも別物

VibeCoding で作れるのは、多くの場合 PoC(概念実証) ——「この方向で合っているか」を確かめるための検証版です。ここで一度、PoC と本番の役割の違いをはっきりさせておきます。

料理にたとえるなら、PoC は 試作品の一皿。味の方向性を確かめるためのもので、一人分をその場で作れれば十分です。本番は 毎日何百人分も出し続ける店の厨房。安定して同じ味を出す仕組み、衛生管理、仕入れの継続、クレーム対応まで含めた「回り続ける体制」が要ります。同じ料理でも、求められるものがまるで違います。

観点	PoC(検証版)	本番(運用するシステム)
目的	方向性が正しいかの検証	継続して価値を出し続ける
使う人	関係者・一部の顧客	不特定多数・実際の利用者
壊れたとき	直せばよい	業務が止まる・信頼を失う
求められるもの	見た目・流れの確認	信頼性・保守・法務・運用・セキュリティ
寿命	数週間〜数か月	年単位で育て続ける

この違いは、できる/できないの伝え方で扱った「プロトタイプと本番は別物」という線引きと、まったく同じ根っこを持っています。

どこまで内製、どこからプロに渡すか

VibeCoding で自前で進めてよい範囲と、エンジニアやベンダーに渡すべき範囲は、感覚ではなく 判断軸 で決められます。下の表の「右側」に当てはまるほど、プロの手が必要だと考えてください。

判断軸	内製(VibeCoding)でOKな側	プロに渡すべき側
扱うデータの重要度	消えても作り直せる・ダミーデータ	顧客データ・失うと取り返せない情報
利用者の数	社内・関係者・少人数	不特定多数・多人数の同時利用
お金・個人情報	扱わない	決済・個人情報・機微情報を扱う
継続運用の要否	検証が終われば役目を終える	何年も動かし・直し続ける
障害時の影響	止まっても困らない	止まると業務・売上・信用に直撃
法務・規約	社内利用で完結	契約・コンプライアンス・監査の対象

一番危ないのは「お金・個人情報」の線

上の軸の中でも、決済と個人情報は特に慎重にすべき境界です。ここは事故がそのまま法的責任や信用失墜に直結します。「動いているから大丈夫」に見えても、本番で扱うなら必ず専門家のレビューを通してください。判断に迷う具体例は個人情報・著作権の注意も参照。

現実には「全部内製」か「全部外注」の二択ではありません。検証と提案は VibeCoding で速く回し、本番の作り込みはプロに渡す——この役割分担が、多くの場面でいちばん効率的です。

引き継ぎチェックリスト:何を渡すか

いざプロに渡すとなったとき、コードだけをポンと渡しても、受け取った側は「なぜこうなっているのか」が分からず、結局ゼロから作り直しになりがちです。経緯ごと渡すのがコツです。渡すべき成果物を一覧にします。

渡すもの	中身	なぜ要るか
仕様書	何を・なぜ作ったかの要件	受け手が意図を誤解しない
中間成果物・ADR	図・実装プラン・意思決定の記録	「なぜこの選択にしたか」が残る
リポジトリ(GitHub)	コード一式と変更履歴	実物と経緯をそのまま渡せる
環境変数の一覧	接続情報・鍵の項目(値は安全に別途)	動かすのに不可欠。漏れると起動しない
認証の方針	どの方式で・どうログインさせているか	差し替えが最も重いので早く共有
既知の課題	未対応・妥協した点・怪しい箇所	隠さず渡すほど信頼される

AIに引き継ぎ資料を作らせる

「このリポジトリを別のエンジニアに引き継ぎます。仕様の要約・主要な設計判断(ADR形式)・環境変数の一覧(値は伏せて項目だけ)・既知の課題を、引き継ぎ資料としてまとめて」と頼めば、AIが一式を下書きしてくれます。特に既知の課題は自分では気づきにくいので、AIに「妥協した点や本番前に直すべき箇所は?」と棚卸しさせると有効です。

鍵やパスワードそのものは渡し方に注意

環境変数は「項目名の一覧」と「実際の値」を分けて扱います。API キーやパスワードの実物を、チャットやメールに平文で貼るのは避けてください。詳しくはAPIキーをフロントに置く危険性や秘密情報をGitにコミットしないへ。

インフラ非依存に作っておくと、引き継ぎが楽になる

引き継ぎのしやすさは、渡すときの努力より、作るときの選択で大きく決まります。特定のクラウドサービスにべったり依存した作りだと、受け取った側が「この基盤ごと引っ越したい」となったとき、大手術になります。

賃貸の家具にたとえるなら、造り付けの棚は引っ越し先へ持っていけませんが、置き型の家具ならそのまま運べます。「置き型」で作っておくイメージです。

• 認証を Auth.js + 自前DB のような インフラ非依存の路線にしておくと、デプロイ先を乗り換えても認証の作りはそのまま使える
• ローカル開発環境を特定サービス前提にせず、データベースへのアクセスを抽象化しておくと、つなぐ先を選ばない

この「インフラ非依存」の具体的な組み方は、提案書から動くPoCを作るの CLAUDE.md 例で、実際の方針として書き込んでいます。

コストと体制の意思決定に、一言

内製と外注の線引きは、そのまま お金と体制の判断でもあります。企画・コンサルの立場なら、ここは黙って任せる部分ではなく、むしろあなたが主導すべき領域です。

• VibeCoding での検証は、外注の前に「何を作るべきか」を安く早く見極める投資になる。仕様がぶれたまま外注すると、手戻りのコストは桁違いに膨らむ
• 「PoC は内製、本番はベンダー」と決めたら、引き継ぎ資料の分だけ見積もりが下がる可能性を、交渉材料として持っておける
• 継続運用を誰が担うか(社内チームか、保守契約か)は、作り始める前に決めておくほど安全

こうした「できる範囲・任せる範囲」を正確に示す姿勢は、できる/できないの伝え方の線引きと地続きです。

誇張しない——道具の身の丈を正しく伝える

VibeCoding は、提案と検証を速くする道具です。本番運用に必要な信頼性・保守・法務・セキュリティのすべてを、これだけで置き換えられるわけではありません。「速く試せる」ことと「本番を任せられる」ことは別——この線を自分も相手も誠実に共有しておくことが、結局いちばん信頼されます。

なぜ大事か

多くのプロジェクトが、うまくいかないのは技術そのものより「線引きの曖昧さ」でつまずきます。どこまで自前で、どこからプロに渡すかを判断軸で決められ、渡すときに経緯ごと引き継げる——このひとつながりを押さえておくと、VibeCoding で作った検証版が「作って終わり」で終わらず、本番へと無理なくバトンを渡せます。速く試す力と、正しく手放す力。その両方を持つ人が、いちばん遠くまで進めます。

参考リンク(情報ソース)

• Architecture Decision Records(引き継ぎに効く意思決定の記録): https://adr.github.io/
• The Twelve-Factor App(移行しやすい作りの一次情報・設定と環境の分離など): https://12factor.net/
• GitHub Docs(リポジトリでコードと経緯を渡す): https://docs.github.com/ja/repositories