バイブコーディングで作ったアプリは開発会社に引き継げる？AI自作アプリの引き継ぎ準備と脆弱性・属人化対策

2026年9月26日2026年10月4日

LovableやBolt、v0などのAIツールに話しかけながら、社内向けの予約管理や顧客リストのアプリを自分で作ってみた。便利に使えているけれど、利用者が増えてきて「このまま自分一人で面倒を見るのは不安だ」と感じ、開発会社への引き継ぎを考え始めた――。最近、こうした相談がとても増えています。

「バイブコーディングで作ったアプリを、開発会社に引き継ぐことはできるのでしょうか。セキュリティは大丈夫なのか、作った自分が辞めたら誰も触れなくなるのではと不安です」

先に結論をお伝えします。AIで作ったアプリでも、開発会社への引き継ぎは十分に可能です。ただし、引き継ぎの費用と難しさは「アプリの出来」よりも「準備の状態」で大きく変わります。コードをGitHubに移す、アカウントを会社名義にする、アプリの説明メモを書く、パスワード類を整理する――この4つを済ませてから相談すると、開発会社は状況を早く正確に判断でき、見積もりのブレも小さくなります。

この記事では、AIで自作したアプリを開発会社に引き継ぐための準備を、チェックリストと開発会社への質問例つきで解説します（ツールの機能・規約は執筆時点・2026年9月の情報です）。

バイブコーディングで作ったアプリの引き継ぎが難しくなる理由

バイブコーディングとは

バイブコーディングとは、プログラムを自分で書くのではなく、「こんな画面がほしい」「ここを直して」とAIに言葉で指示しながらアプリを作っていく進め方のことです。LovableやBolt、v0のように、ブラウザ上で指示するだけで画面・データベース・公開までまとめて用意してくれるツールが広まり、プログラミング経験のない方でも動くアプリを作れるようになりました。

これ自体はとても良い変化です。アイデアを形にして業務で試せたこと、実際に使われていることは大きな価値があり、開発会社にとっても「何を作りたいか」がはっきり分かる最高の資料になります。

引き継ぎでつまずきやすい5つのポイント

一方で、開発会社が引き継ぐときには、次のような点が壁になりやすいのが実情です。

つまずきポイント	何が困るのか
仕様書がない	何が正しい動きなのかが分からず、直してよいか判断できない
コードがツールの中にしかない	開発会社が中身を見られず、調査すら始められない
アカウントが個人のメールアドレス	担当者の異動・退職でログインできなくなる。請求先も個人のまま
パスワードやAPIキーがコードに直書き	情報漏えいの原因になり、共有するだけでも危険
テストがない	1か所直すと別の場所が壊れていないか確かめる手段がない

どれも「作った方の落ち度」ではありません。AIツールは早く動くものを作ることが得意な反面、こうした「他人が引き継ぐための準備」は、頼まない限り自動では整わないというだけです。だからこそ、引き継ぎの前に発注者側で整えておく価値があります。

AI自作アプリを開発会社に引き継ぐ準備5ステップ

ステップ1：コードをGitHubに移し、会社のアカウントで持つ

最初にやりたいのは、アプリのコードをGitHub（＝プログラムとその変更履歴を保管・共有する定番のサービス）に置くことです。GitHubに置けば、開発会社はツールにログインしなくても中身を調べられます。主要なツールには公式の連携機能があります（執筆時点）。

📰 出典：Lovable Documentation「GitHub integration」

Lovable：連携するとGitHubに新しいリポジトリ（＝コードの保管場所）が作られ、初期設定では非公開です。Lovableでの変更がGitHubへ、GitHub側の変更もLovableへ反映される双方向の同期です。連携を解除しても、GitHubのリポジトリは履歴ごと残ると説明されています

📰 出典：Bolt Help Center「GitHub for version control」

Bolt：プロジェクトから新しい非公開リポジトリを作成でき、変更は自動でコミット（＝変更履歴の記録）されます。GitHubのOrganization（＝会社・チーム単位のアカウント）にも対応しています

📰 出典：v0 Docs「GitHub」

v0：プロジェクトの設定からGitHubに接続すると、非公開リポジトリが作られ、現在のコードが送られます。保存先に個人アカウントかOrganizationかを選べます

ここで大事なのは、リポジトリを個人ではなく会社のOrganizationに置くことです。すでに個人アカウントに作ってしまった場合も、GitHubの「リポジトリの移譲」機能で会社のOrganizationへ移せます。

📰 出典：GitHub Docs「リポジトリを移譲する」

移譲すると変更履歴や課題（Issue）なども一緒に移り、古いURLは新しい場所へ自動で転送されます。操作に不安がある場合は、引き継ぎ先の開発会社に一緒に作業してもらうと安心です。

ステップ2：使っているサービスとアカウントを一覧にし、会社名義に移す

AIで作ったアプリは、AIツール本体のほかに、データベース、ログイン機能、決済、メール送信、ドメインなど、複数の外部サービスの上で動いていることがよくあります。まずは表にまとめましょう。

サービスの種類	例	書き出すこと
AI開発ツール	Lovable、Bolt、v0 など	契約プラン、登録メールアドレス、月額
データベース・ログイン	Supabase、Firebase など	管理者は誰か、保存しているデータの種類
公開・ドメイン	ホスティング、独自ドメイン	更新日、支払い方法
外部連携	決済、メール配信、地図、AI API など	何に使っているか、請求先

一覧ができたら、登録メールアドレスを会社の共有アドレスに、支払いを会社のカードや請求書払いに切り替え、管理者を2人以上にします。「本人しかログインできないサービスがゼロ」の状態が、属人化対策の第一歩です。

ステップ3：アプリの説明メモを書く

開発会社が最初に知りたいのは、コードの中身よりも「このアプリは何のためのもので、誰が、どう使っているか」です。A4用紙1〜2枚で十分なので、次の項目を書き出しましょう。

アプリの目的と、使っている人・人数
主な画面と、それぞれでできること
保存しているデータ（顧客名、メールアドレス、売上など）と、個人情報の有無
「ここは絶対に変えてはいけない」業務上のルール
分かっている不具合、気になっていること
AIに出した主な指示の履歴（残っていれば）

このメモは、リポジトリの中に「README」（＝プロジェクトの説明書）として置いておくと、あとから加わる人も迷いません。最近は、AIコーディングツール向けの説明書を「AGENTS.md」という共通のファイル名で置く方法も広まっており、複数のAIツールがこのファイルを読み込んで作業の前提にします。

📰 出典：AGENTS.md 公式サイト

人向けの説明とAI向けの説明を分けて残しておくと、開発会社が引き継いだあとにAIツールを使って改修する場合にも役立ちます。

ステップ4：パスワード・APIキーを整理し、作り直す

APIキー（＝外部サービスを使うための合鍵のような文字列）やパスワードがコードの中に直接書かれていると、コードを見られる人なら誰でもそのサービスを使えてしまいます。コードを開発会社と共有する前に、次の対応をしておくと安全です。

コードに直接書かれている鍵がないか、ツールのセキュリティ機能や開発会社に確認してもらう
見つかった鍵は、ツールが用意している「Secrets」などの保管場所に移す
一度でもコードやチャットに書いた鍵は、発行元で作り直す（ローテーション）

最後の「作り直し」は見落とされがちです。鍵をコードから消しても、変更履歴やAIとのやり取りの中に残っている可能性があるため、古い鍵自体を無効にしておくのが確実です。鍵をメールやチャットで開発会社に送るのも避け、共有方法は事前に相談しましょう。

ステップ5：公開前の基本的なセキュリティ確認

「LovableなどでAIが作ったアプリに脆弱性（＝セキュリティ上の弱点）はないのか」という不安は、もっともなものです。実際に、公的な脆弱性データベースにも関連する記録があります。

📰 出典：NVD（米国国立標準技術研究所の脆弱性データベース）「CVE-2025-48757」

この記録では、Lovableで生成されたサイトについて、2025年4月15日までのバージョンで、データベースの行単位のアクセス制御（RLS：Row-Level Security＝データ1件ごとに「誰が読み書きできるか」を決める設定）が不十分な場合に、ログインしていない第三者がデータを読み書きできうる問題として登録されています。一方で、Lovable側は「アプリのデータ保護は各利用者が責任を負う」としてこの登録に異議を唱えていることも、同じ記録に明記されています。

どちらの立場であっても、発注者にとっての教訓は同じです。AIツールで作ったアプリも、データの守り方は人が確認する必要があるということです。Lovableの公式ドキュメントでも、公開前に自動で走るセキュリティチェックや、アクセス制御の不備を知らせる機能を用意したうえで、用途に応じたセキュリティ要件を満たす責任は利用者にあると説明しています。

📰 出典：Lovable Documentation「Security」

発注者として最低限確認したいのは次の3点です。ツールのセキュリティチェック結果を開発会社にも見てもらうと、判断が早くなります。

ログインしていない人が、他人のデータを見たり書き換えたりできないか
管理者用の画面や機能が、一般の利用者から触れない状態になっているか
個人情報を扱う場合、その保管場所と、誰がアクセスできるか

なお、IPAの「情報セキュリティ10大脅威 2026」（組織編）では、「AIの利用をめぐるサイバーリスク」が初めて選ばれ、3位に入りました。AIで作ったものを社外に公開する場合は、公開前の確認を「念のため」ではなく通常の工程として考えておくとよいでしょう。

📰 出典：IPA「情報セキュリティ10大脅威 2026」

発注者・経営者として決めておくこと

開発会社に最初に頼むのは「診断」

準備ができたら、いきなり「全部直してください」と頼むのではなく、最初は現状診断（アセスメント）だけを依頼するのがおすすめです。進め方の目安は次の3段階です。

診断：コード・構成・セキュリティ・データを調べ、問題点と優先順位を報告してもらう
修正：危険度の高い問題から直す。必要に応じてテスト（＝動きを自動で確かめる仕組み）も追加する
保守：月々の見守り・更新・小さな改修を契約する

診断の結果によっては、今のアプリを直し続けるより、作り直した方が長い目で見て安く済む可能性もあります。たとえば、データの持ち方が業務に合っていない、同じ処理があちこちに重複している、使っている部品が古いといった場合です。作り直しになっても、今のアプリで固まった画面や業務の流れはそのまま「生きた仕様書」になるため、作ったことは無駄になりません。どちらが良いかは診断してみないと分からないため、両方の案と費用感を出してもらうとよいでしょう。

保守の費用がどんな項目で構成されるかは、システム保守費用の内訳の記事で解説しています。

AIツールの契約プランとデータの扱いを確認する

AIツールのプランによって、入力した内容やコードの扱いが異なる場合があります。たとえばLovableは、2026年9月9日から、Free・Proプランのプロンプトやコードなどを、オプトアウト（＝利用しないよう設定で断ること）しない限りAIの学習に使いうるとしています。Business・Enterpriseプランは初期設定で学習の対象外です（執筆時点）。

📰 出典：Lovable Documentation「Data opt-out」

業務データを扱うアプリなら、どのプランで契約し、学習利用の設定をどうするかを社内で決めておきましょう。開発会社が引き継いだあともツールを使い続けるかどうかも、このタイミングで相談しておくと安心です。

属人化を防ぐ社内ルール

引き継ぎは一度きりのイベントではありません。「作った本人が辞めたら誰も触れない」状態を繰り返さないために、次のルールを決めておくと効果的です。

アカウントは会社名義で作り、管理者は必ず2人以上にする
コードは会社のGitHubに置き、変更はそこに記録される状態を保つ
説明メモ（README）は、機能を足したら一緒に更新する
社内で新しくAIアプリを作るときは、作り始める前に上長や情シスに一声かける

注意点：AIで作ったアプリの限界を知っておく

「動いている」と「安全・安定している」は別物です。AIツールは指示された機能を作るのは得意ですが、アクセスが増えたときの動作や、想定外の使われ方まで自動で考えてくれるとは限りません
引き継いでもAIツールの便利さは失われません。開発会社がGitHub上のコードを直しつつ、発注者は引き続きツールで試作する、といった分担もツールによっては可能です
ツールの機能・規約は頻繁に変わります。この記事の内容も執筆時点のものなので、実際の設定前に各社の公式ドキュメントを確認してください