# エンジニアに相談・引き継ぐときの準備 — AIで作ったアプリを、他人が触れる状態にする > Claude CodeやLovableで作ったアプリをエンジニアに相談・引き継ぐとき、何を準備すれば見積もりが早く正確になるかを解説します。渡すべき5つの情報、渡してはいけないもの、見積もりが高くなる典型パターン、そして相談時に聞かれることの先取り。 - 公開日: 2026-08-06 - 著者: 友田 陽大 - タグ: バイブコーディング, 発注, 個人開発, 受託開発 - URL: https://tomodahinata.com/blog/handing-over-ai-app-to-engineer - カテゴリ: AIで作ったアプリの運営 - 総合ガイド: https://tomodahinata.com/blog/ai-app-pre-launch-guide-for-non-engineers ## 要点 - 引き継ぎの費用は「コードの量」ではなく「分からなさ」で決まる。何がどこにあるか整理されているだけで見積もりは大きく下がる - 渡すべきは5つ — リポジトリ、使っている外部サービスの一覧、環境変数の項目名（値ではない）、動いているURL、そして「何が正しい動作か」 - 鍵の値そのものを渡してはいけない。項目名だけ伝え、値は必要になった時点で安全な経路で。相談段階では不要 - 見積もりが高くなる典型は3つ — 動作の正解が誰にも分からない、本番と手元の差分が不明、そして「全部作り直し」と言われる状態 - 「作り直したほうが早い」は必ずしも正しくない。動いているものには実績があり、優先順位をつけて直すほうが安いことが多い --- 「エンジニアに相談したいけど、何を聞けばいいのか分からない」 これは、この分野でいちばんよく聞く言葉です。そして——**分からなくて構いません**。こちらから質問します。 ただ、いくつか先に用意しておくと、**見積もりが早く、安く、正確になります**。この記事はそのためのものです。 --- ## 1. 費用を決めるのは「コードの量」ではない まず、直感に反する事実から。 引き継ぎや調査の費用は、コードの行数では決まりません。**「分からなさ」で決まります**。 エンジニアが見積もりを出すとき、内部でやっているのはこういう計算です。 ``` 作業の量 ＋ 分からないことの量 × リスク ``` 2項目が効きます。「たぶん1日で終わるけど、何が起きるか分からないから3日分もらっておこう」——これは不誠実ではなく、**分からないものに対する誠実な見積もり**です。 逆に言えば、**分からないことを減らせば、見積もりは下がります**。しかも、減らす作業のほとんどはあなた自身にしかできません。 --- ## 2. 渡すべき5つ ### （1）コードの置き場所 GitHub のリポジトリURL、または招待です。 **GitHubを使っていない場合**（Lovable や Bolt の中だけで作っている場合）は、まずエクスポートして GitHub に置くところから始まります。これ自体は各サービスの機能で数分です。 **リポジトリが分からない場合**も、正直にそう伝えてください。「どこにあるか分からない」は、この分野では珍しくありません。 ### （2）使っている外部サービスの一覧 これが意外と価値があります。 ``` 例: - ホスティング: Vercel - データベース・認証: Supabase - 決済: Stripe - メール送信: Resend - AI: Anthropic Claude API - アクセス解析: Google Analytics ``` 分からなければ、AI に聞けば作れます。 ```text このプロジェクトが使っている外部サービスを全部洗い出して、 それぞれ「何のために使っているか」を1行で説明した一覧を作ってください。 package.json、環境変数、コード内の呼び出し先URLから判断してください。 ``` ### （3）環境変数の「項目名」リスト（値は渡さない） **値そのものは渡しません。項目名だけです。** ``` 例: NEXT_PUBLIC_SUPABASE_URL NEXT_PUBLIC_SUPABASE_ANON_KEY SUPABASE_SERVICE_ROLE_KEY STRIPE_SECRET_KEY STRIPE_WEBHOOK_SECRET RESEND_API_KEY ``` これだけで、エンジニアは「何が必要か」「どこに危険がありそうか」を把握できます。上のリストを見た時点で、`SUPABASE_SERVICE_ROLE_KEY` に `NEXT_PUBLIC_` が付いていないことが確認できる——といった具合です。 値が必要になるのは、実際に手元で動かす段階です。そのときはパスワード管理ツールの共有機能など、安全な経路で渡します。**メールやチャットに直接貼るのは避けてください。** ### （4）動いているURL 本番のURL。動いていなくても、動いていた頃のURLがあれば伝えてください。 テスト用のアカウントを1つ用意してもらえると、さらに早く進みます。 ### （5）「何が正しい動作か」 ← 最も価値がある **これがいちばん重要で、そしてあなたにしか書けません。** エンジニアはコードを読めば「何をしているか」は分かります。しかし「**何をすべきか**」は分かりません。それを知っているのはあなただけです。 書き方は箇条書きで十分です。 ``` 例: - 利用者は自分の投稿だけ編集できる。他人の投稿は見えるが編集はできない - 有料プランの人だけ、エクスポート機能が使える - 月末に、その月の集計をメールで送る - 同じメールアドレスで2回登録はできない - 退会したら、投稿は残るが名前は「退会済みユーザー」になる ``` コードを読んでも、これらが「仕様」なのか「バグ」なのかは判別できません。たとえば「他人の投稿が編集できてしまう」状態を見つけたとき、それが**バグなのか、そういう仕様なのか**は、あなたに聞くしかない。 **この一覧があるだけで、見積もりは目に見えて下がります。** リスクの見積もり分が減るからです。 --- ## 3. 渡してはいけないもの **鍵やパスワードの値。** 相談段階では不要です。項目名だけで十分です。 **顧客の個人情報を含む本番データ。** 動作確認のためにデータが必要な場合でも、まずはテスト用の架空データで足ります。本番データを渡すなら、それ自体が個人情報の第三者提供にあたるので、契約と手続きが必要になります。 **「全部のパスワードが書いてあるメモ」。** 見たことがありますが、これは渡す側にとっても危険です。必要な範囲だけを、必要な時点で。 --- ## 4. 見積もりが高くなる3つのパターン 先に知っておくと、避けられます。 ### パターン1: 何が正しい動作なのか、誰にも分からない 前章の（5）が無い状態です。 このとき、エンジニアは「直したら別の何かが壊れるかもしれない」というリスクを抱えます。動作を1つ変えるたびに「これは意図した仕様なのか」を確認する必要が出ます。 **対策**: 「必ず成り立つべきこと」を10個でいいので書き出す。 ### パターン2: 本番と手元のコードが一致しているか不明 「デプロイしたのがどのバージョンか分からない」「途中から管理画面で直接いじった」という状態です。 このとき、まず**調査から始める**必要があります。動いているものと、手元にあるものが違うかもしれないので。 **対策**: いま動いているものが、どのコードから来たのかを確認しておく。GitHub と連携してデプロイしているなら、たいていは最新のコミットです。 ### パターン3: 本番データが入っているのに、テスト環境が無い 実ユーザーのデータが入った1つの環境しか無いと、**すべての作業が本番作業**になります。試すこともできません。 慎重に進めるぶん、時間がかかります。 **対策**: これは自分で用意するのが難しいので、正直に伝えてください。「テスト環境を作るところから」が最初の作業になります。 --- ## 5. 「作り直したほうが早い」は本当か 相談すると、こう言われることがあります。「これは作り直したほうが早いですね」 **必ずしも正しくありません。** 判断の材料を書いておきます。 ### 動いているものが持っている価値 すでに動いているアプリには、コードには書かれていない価値があります。 - **実際にユーザーがどう使うかが分かっている** - **必要な機能と、不要だった機能が分かっている** - **すでにデータが入っている** 作り直すと、これらの知見も一度失われます。「同じものをもう一度作る」つもりが、実際には「一度学んだことをもう一度学び直す」ことになりがちです。 ### 判断の分かれ目 **直すほうが安いケース** - 問題が特定の箇所に集中している（決済まわりだけ、認可まわりだけ） - 全体の構造自体は素直で、追加もしやすい - すでにユーザーがいて、止められない **作り直すほうが安いケース** - 同じ問題が全ファイルに散らばっている - そもそも要件が変わっていて、作るものが違う - ユーザーがまだいない、または極少数 ### 順序としての提案 いきなり「作り直し」を決める前に、**まず優先度つきの所見を出してもらう**のが順序です。 「どこが危ないか」「直すならどのくらいか」「作り直すならどのくらいか」を並べてから決める。判断材料が無い状態で作り直しを決めると、たいてい高くつきます。 --- ## 6. 相談で聞かれることを、先に用意しておく 初回の相談でだいたい聞かれることです。答えを用意しておくと、その場で話が進みます。 **「いま何人くらい使っていますか？」** 0人なのか、10人なのか、1万人なのか。取れる手段が全く変わります。0人なら止めて直せます。 **「お金は動いていますか？」** 決済があるかどうか。あるなら優先度が跳ね上がります。 **「個人情報は預かっていますか？」** メールアドレスだけでも該当します。 **「いちばん困っていることは何ですか？」** 「なんとなく不安」でも構いません。むしろそれが正直な答えなら、そう言ってください。 **「いつまでに、どうなっていたいですか？」** 期限があるなら、優先順位の付け方が変わります。 **「予算感はありますか？」** これは答えづらい質問ですが、**上限だけでも伝えてもらえると早い**です。予算に収まる範囲で何ができるかを組み立てられます。「まだ分からない」も立派な答えで、その場合は選択肢を段階的に出します。 --- ## 7. 引き継ぎ資料をAIに作らせる ここまでの内容の大部分は、AI に作らせられます。 ```text このプロジェクトについて、エンジニアに引き継ぐための資料を作成して ください。私は非エンジニアなので、専門用語には短い説明を添えてください。 含めてほしい内容: (1) このアプリが何をするものか（3行程度） (2) 使っている技術と外部サービスの一覧（それぞれ何のために使っているか） (3) 環境変数の項目名の一覧と、それぞれ何のための値か ※ 値そのものは絶対に書かないでください (4) 主要な機能と、それぞれの画面/URLの対応 (5) データベースのテーブル一覧と、それぞれ何を保存しているか (6) デプロイの方法（どこにどうやって公開されているか） (7) 現時点で分かっている不具合・未完成の箇所 (8) このコードを読んで気づいた、注意が必要な箇所 これを1つのMarkdownファイルとして書き出してください。 ``` これを実行して出てきたものを、**自分で1回読んでください**。読んで「違う」と思ったところを直す。それだけで、かなり正確な引き継ぎ資料になります。 そして（5）の「何が正しい動作か」だけは、AI には書けません。ここはあなたが書き足してください。 --- ## 8. 準備チェックリスト **相談前に** - [ ] コードの置き場所を確認した（GitHubのURL、または未整備であることを把握した） - [ ] 使っている外部サービスの一覧を作った - [ ] 環境変数の項目名リストを作った（値は含めない） - [ ] 動いているURLを確認した - [ ] 「必ず成り立つべきこと」を10個書き出した - [ ] 現在のユーザー数、決済の有無、個人情報の有無を整理した - [ ] いちばん困っていることを1行で言えるようにした **作業を依頼する段階で** - [ ] 秘密保持契約について確認した - [ ] リポジトリへのアクセス方法を決めた（招待、権限の範囲） - [ ] 鍵の受け渡し方法を決めた（安全な経路で） - [ ] 作業完了後に鍵を作り直す前提を共有した --- ## まとめ - 費用を決めるのはコードの量ではなく「分からなさ」。整理するだけで見積もりは下がる - 渡すべきは5つ — リポジトリ、外部サービス一覧、環境変数の項目名、動いているURL、「何が正しい動作か」 - 最後の1つが最も価値があり、あなたにしか書けない - 鍵の値は相談段階では不要。項目名だけで判断材料としては十分 - 「作り直したほうが早い」は必ずしも正しくない。まず優先度つきの所見を出してもらってから決める そして最後に。**準備が完璧でなくても相談して構いません。** 「何も分からない状態です」から始まる相談はごく普通で、その場合は現状の把握から一緒にやります。 現状を自分で確かめてから相談したい方は、[無料セルフ診断](/vibe-coding/checkup)（20問・登録不要）を先に通してみてください。その結果をそのまま引き継ぎ資料の一部として使えます。 技術面で何を確認すべきかは [AIで作ったアプリを公開する前に](/blog/ai-app-pre-launch-guide-for-non-engineers) にまとめています。