AIで作ったアプリを開発会社へ引き継ぐには｜残す部分・直す部分・任せる範囲

AIで作ったアプリを開発会社へ引き継ぐときは、全部を作り直す前提で考える必要はありません。認証・データ権限・テスト・復旧・運用の5つの観点で、残す部分・直す部分・任せる部分を分けると、依頼の範囲と費用の桁が決まります。

画面の改善や軽い機能追加は自社でAIを使って続け、権限の試験やデータ移転だけを開発会社に頼む分け方もできます。この記事は、ChatGPT・Claude・Codex・Lovableなどで業務アプリや顧客向けアプリを作り、社員や顧客に使ってもらう前にどこまでを任せるか決めたい事業責任者・業務部門長・情シス担当の方に向けたものです。

この進め方が合う場合・合わない場合

開発会社に引き継ぐのが正解とは限りません。まず、今の使い方で外部の手が必要かどうかを確かめます。

AIで作ったアプリが本番で使えない、ということではありません。Lovableの公式ドキュメントでも、Lovable上でそのまま公開して運用する形が推奨の選択肢として案内されています（Lovable: Deployment, hosting and ownership、2026年10月8日確認）。問題になるのは、使う人が増えたときに誰が何を見てよいか、おかしくなったときに戻せるか、変更したときに誰が確かめるかが決まっていないことです。

引き継ぐ前に棚卸しするもの（コードに入らない資産）

出典: Lovable 公式

「GitHubにコードがあるので引き継げます」という状態でも、本番の動作に必要なものがそろっていないことがあります。Lovableの公式ドキュメントでは、コードのダウンロードやGitHub同期に含まれるのはソースコードとデータベースの構造（マイグレーション）までで、データベースの中身とアップロードされたファイルは別に書き出す必要があると明記されています。

利用者のアカウント情報や秘密の設定値がコードの書き出しに含まれるかどうかは、確認した公式ページには書かれていませんでした。そのため、ここは現物で確かめる項目として扱ってください。ChatGPTやClaudeのチャットで作った場合は、そもそもコードが担当者のパソコンにしかない、履歴が残っていない、ということもあります。その場合は「最新のコードがどれか」を決めるところから始めます。

コードの権利や納品物の考え方は、AI開発の納品物と権利の確認で詳しく扱っています。

残す・直す・任せるを5つの観点で分ける

出典: Supabase 公式

棚卸しが終わったら、5つの観点ごとに「今の状態」「業務で求める状態」を並べます。差が小さければ残し、差が大きければ直します。業務の知識がないと決められない部分や、間違えたときの影響が大きい部分は任せる候補になります。

下の表は説明用の記入例です。架空の経費申請アプリ（取引先2社が使う、申請者・承認者・管理者の3権限）を想定しています。

データの権限については、Supabaseの公式ドキュメントが具体的な注意を出しています。外部から読み書きできる場所にあるすべてのテーブルで行単位のアクセス制御（RLS）を有効にすること、管理用の秘密キーはその制御を通り抜けるためブラウザ側に置かないこと、の2点です（Supabase: Row Level Security、2026年10月8日確認）。LovableなどでSupabaseをデータベースに使っている場合は、引継ぎのときにまずここを確認します。

直すか作り直すかの判断自体は、既存システム一般の話としてシステムは改修か作り直しかでも扱っています。

架空の申請アプリで、権限の試験と復旧を試した結果

ここまでの判断が実際の試験でどう見えるかを確かめるため、上の記入例と同じ架空アプリを小さく作って動かしました（2026年10月8日、Python 3.14とSQLite 3.53、手元のパソコンで実行）。データはすべて架空です。

前提として、修正前の版はAIツールに作らせたコードではありません。 AIで作った試作に起こりうる「会社による絞り込みがない」状態を再現するために、執筆担当が意図的にその形で書きました。

先に「業務の期待結果」を表で決めた

試験を書く前に、誰が何をできてよいかを業務の言葉で決めました。

• 申請者は自分の申請だけ見られる
• 承認者と管理者は、自分の会社の申請だけ見られる
• 承認できるのは、同じ会社の承認者か管理者が「申請中」の申請を承認する場合だけ

この表から、一覧表示6件と承認操作6件の、合計12件の試験を作りました。

結果

修正前の版では、A社の承認者の一覧にB社の申請も並びます。画面を触って確かめても、何が見えてはいけないかを決めていなければ、それが誤りだと判断できません。見えてはいけないものを表に書いておいて、初めて確かめられるようになります。 不合格7件のうち4件はこの「見えてはいけないものが見えている」ケースでした。

復旧の手順も実際に戻して確かめた

バックアップを取り、B社の申請を誤って削除した状態を作り、バックアップから戻しました。件数は4件→2件→4件となり、戻した後の内容も最初と一致しました。

試していないこと

• LovableやSupabase、実際のログインの仕組みは使っていません。行単位のアクセス制御（RLS）やログイン状態の扱いは確かめていません
• アップロードファイル、メール送信、外部サービスとの連携、秘密の設定値の移転は対象外です
• 復旧は小さなファイル1つの手動バックアップだけです。本番規模での所要時間や定期バックアップは確かめていません
• 試験は12件だけで、網羅性や性能、脆弱性の有無は評価していません

この結果から言えるのは、「業務の期待結果の表」があれば、AIでも人でも同じ試験を何度でも回せるということまでです。どのAIツールの生成コードにどれだけ不足があるかは、この試験からは分かりません。

自社でAIを使って続ける部分と、開発会社に任せる部分

出典: Claude Code 公式サイト

引継ぎは「全部渡す」か「全部自分でやる」かの二択ではありません。AnthropicのClaude Codeの公式ドキュメントでは、AIに試験やビルドなどの自分で走らせて合否を確かめられる手段を渡すこと、調べる・計画する・実装するを分けること、別のAIに差分を確認させることが推奨されています（Claude Code: Best practices、2026年10月8日確認）。つまり、上のような試験の表がそろえば、自社でAIを使った改修を安全に続けやすくなります。

この分け方で進めると、開発会社が変更を提案し、自社が確認して取り込む共同開発の形になります。Lovableの場合、GitHub（github.com）との双方向の同期は全プランで使えます。公式ドキュメントでは、変更を取り込み依頼（プルリクエスト）で確認する、手元に複製して開発者の使い慣れた道具で作業する、別のブランチで機能を試す、といった使い方が案内されています。ただし、Lovableが編集・同期するのは一度に1つのブランチだけです（Lovable: GitHub integration、2026年10月8日確認）。開発会社の変更をどのブランチで受け、いつ同期先に取り込むかを決めておけば、引継ぎ後も自社の担当者はLovable上でAIを使った改修を続けられます。

内製と外注の分け方を全体で考えたい場合は、AI開発の内製と外注の分け方も参考にしてください。

どこで運用するか（そのまま・一部移転・自社環境へ）

Lovableで作った場合、運用先は公式に3つの形が示されています。移転すれば安全になるとは限りません。移すものが増えるほど、移転作業と移転後の運用は自社や開発会社の負担になります。

Lovableのエディタ自体を自社の環境で動かすことはできない、と公式に書かれています。自社の環境へ移した後もLovableで改修を続ける場合は、GitHub同期を通じて変更を反映させる形になります。Lovable自体の特徴はLovableとはにまとめています。

公開前のレビューと受入試験で決めること

AIツールにも検査の機能はあります。Lovableには、データのアクセス制御の設定漏れや、外部部品の既知の弱点などを調べる簡易検査と、認可・入力・秘密情報の漏えい・決済・個人情報の露出などを調べる詳細な検査があります。ただし、公開時に自動で走るのは原則として簡易検査だけで、詳細な検査は手動で実行します（Lovable: Security、2026年10月8日確認）。同じページには、用途に応じたセキュリティ要件を満たすのは利用者の責任であり、標準の検査は十分なセキュリティレビューの代わりにはならない、とも書かれています。

また、Lovableの画面操作テスト（AIが実際にブラウザを操作して確かめる機能）は確認用の環境が対象です。外部のSupabaseや別のログインの仕組みを使うアプリでは、ログイン不要のページしか試せないと公式に書かれています（Lovable: Browser testing、2026年10月8日確認）。権限ごとに見える範囲を確かめたいアプリほど、この自動テストだけでは確かめきれないことになります。

公開前の確認は、次の3つに分けると抜けが見えます。

開発会社にレビューを頼む場合も、報告書には「どのバージョンのコードを、どの環境で、どの試験で確かめたか」「確かめていない範囲はどこか」を書いてもらいます。問題が見つからなかったという結果だけでは、どこまで確かめたかが分かりません。

費用の目安と依頼の形

AI革命の受託開発の公開価格は次のとおりです（すべて税別。クラウド・外部API・ライセンスなどの実費は別）。

既存コードの調査報告や要件定義書の作成は有償です。作業に入る前に範囲と金額を示し、合意してから進めます。運用開始後の保守（監視・障害対応・変更の範囲）も個別に提案し、別見積です。

他社が公開している価格も、依頼の形によって桁が違うことを知る参考になります（各社ページの記載、2026年10月8日確認。税区分は各社ページで確認してください。品質や成果を比べたものではありません）。

同じ「本番化」でも、公開価格は数十万円台から1,000万円を超えるものまで開きがあります。min'sのページでも、費用はアプリの規模と、残せるコードと作り直すコードの割合で変わると説明されています。まず「相談相手がほしいだけ」「範囲の決まった修正」「権限やデータの作り直しを含む本番化」のどれに近いかを決めると、比べる価格帯が絞れます。どの形に当たりそうか分からない段階でも、相談はできます。

AIで作ったアプリの現状と、引き継いでほしい範囲を相談する 初回相談は無料・30分（オンライン）です。今の構成と本番利用を止めている条件を伺い、残す・直す・任せる範囲の候補と費用の目安を相談メモでお返しします。

小規模改修で扱える範囲は小規模なシステム改修の費用と範囲、保守費の考え方はシステム保守費用の目安で詳しく扱っています。

AI革命が対応できる範囲と、公開している実績

AI革命の受託開発では、AIで作った試作の本番化に対応できます。使ったAIツールや、言語・フレームワークの種類を問わずご相談いただけます。

• 調査のみ／調査＋改修のどちらでも依頼できます。最初に、ソースコード・仕様書・環境情報の有無と、それらを使う権利を確認します
• 認証・データ権限・テスト・復旧・運用を見て、残す部分・直す部分・任せる範囲を分けます
• 自社でAIを使って改修を続けながら、権限・データ移転・本番環境など一部だけを任せる共同開発も選べます
• 会計・顧客管理などの外部サービスとの接続（外部から使える接続口＝公開API、更新の通知＝Webhook、CSVファイル）、データ移行、決済サービスを使った会員・課金の仕組みにも対応できます

一方で、AIで作ったアプリを引き継いだ実績として公開できる事例は、現時点ではありません。 公開している実績のうち、この記事の内容に近いのは薬局の事例です。複数店舗・数千人分の記録管理で、権限と確認工程を含めて開発しました。業種も題材も異なるため、同じ種類の案件の実績としてではなく、「権限と確認工程を開発の範囲に含めた例」として受託開発のページでご確認ください。

相談前に揃えておくと早いもの・送らないもの

初回相談は無料・30分（オンライン、Google Meet）です。要件が決まっていなくても大丈夫です。30分では、何を解決したいか、自社でAIを使って進められる部分と会社に頼んだ方がよい部分の切り分け、依頼の形の候補を話します。確定見積や要件定義書はその場では出しません。

相談後に、確認した現状と課題、自社で進める・頼む・やらないの切り分け、進め方の候補と費用の目安、次に必要な資料をまとめた相談メモをメールでお送りします。

よくある質問

Q. AIで作ったコードは、開発会社に引き取ってもらえないことがありますか？

コードが手元にない、最新版が分からない、使う権利がはっきりしない、という場合は先にそこを確認します。AIツールで作ったこと自体は断る理由になりません。ただし、契約しているツールやサービスの利用規約で、コードやデータの扱いに条件がある場合は、その確認が必要です。

Q. 作った担当者がもういません。それでも引き継げますか？

コードとデータにアクセスできれば、調査から始められます。担当者がいない場合、何のためにどう作ったかの説明がないため、業務の期待結果（誰が何をできてよいか）を自社で改めて決める作業が増えます。チャットでAIとやりとりした履歴が残っていれば、それも判断材料になります。

Q. 作り直した方が安いと言われました。本当ですか？

アプリによります。画面や業務の流れが合っていて、直す対象が権限や復旧に限られるなら、残した方が早いことがあります。データの持ち方そのものが業務と合っていない場合は、作り直した方が後の変更が楽になることもあります。どちらの場合も、理由を観点ごとに説明してもらってから決めてください。

Q. 引き継いだ後に、また自分たちでAIを使って直してもよいですか？

できます。その場合は、自社の変更で権限や試験がおかしくなっていないかを確かめる手順（変更後に試験を回す、取り込む前に確認する人を決める）を、引継ぎのときに一緒に決めておくと安全です。誰がどの部分を変えてよいかは、保守の取り決めにも書いておきます。

Q. 社外の人が使うアプリでなければ、引継ぎは不要ですか？

社内だけでも、部署や役職で見てよい情報が違う場合や、給与・評価・取引条件などを扱う場合は、権限の確認が必要です。逆に、社内の少人数が同じ情報を見るだけなら、標準検査とバックアップの確認で十分なこともあります。

Q. 相談するときにコードを見せる必要はありますか？

初回の30分ではコードは不要です。使ったツール、動いている範囲、困っている点が分かれば、依頼の形の候補は話せます。見積のために、相談後に構成の説明などの資料をお願いすることはあります（資料を受け取った後の提案・見積は無料です）。コードの中身を調べて報告書にまとめる調査は有償で、範囲と金額に合意してから始めます。

AIで作ったアプリを本番で使う前に

AIで作ったアプリを、そのまま使い続けるか、一部を直すか、作り直すかは、動く画面だけでは決まりません。誰が何を見てよいか、おかしくなったときに戻せるか、変更したときに誰が確かめるかを観点ごとに分けると、自社でAIを使って続ける部分と任せる部分が見えてきます。

AIで作ったアプリの現状と、引き継いでほしい範囲を相談する 初回相談は無料・30分（オンライン）です。今の構成と本番利用を止めている条件を伺い、残す・直す・任せる範囲の候補と費用の目安を相談メモでお返しします。