エンジニアに相談・引き継ぐときの準備 — AIで作ったアプリを、他人が触れる状態にする

「エンジニアに相談したいけど、何を聞けばいいのか分からない」

これは、この分野でいちばんよく聞く言葉です。そして——分からなくて構いません。こちらから質問します。

ただ、いくつか先に用意しておくと、見積もりが早く、安く、正確になります。この記事はそのためのものです。

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 に聞けば作れます。

このプロジェクトが使っている外部サービスを全部洗い出して、
それぞれ「何のために使っているか」を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 に作らせられます。

このプロジェクトについて、エンジニアに引き継ぐための資料を作成して
ください。私は非エンジニアなので、専門用語には短い説明を添えてください。

含めてほしい内容:

(1) このアプリが何をするものか（3行程度）
(2) 使っている技術と外部サービスの一覧（それぞれ何のために使っているか）
(3) 環境変数の項目名の一覧と、それぞれ何のための値か
    ※ 値そのものは絶対に書かないでください
(4) 主要な機能と、それぞれの画面/URLの対応
(5) データベースのテーブル一覧と、それぞれ何を保存しているか
(6) デプロイの方法（どこにどうやって公開されているか）
(7) 現時点で分かっている不具合・未完成の箇所
(8) このコードを読んで気づいた、注意が必要な箇所

これを1つのMarkdownファイルとして書き出してください。

これを実行して出てきたものを、自分で1回読んでください。読んで「違う」と思ったところを直す。それだけで、かなり正確な引き継ぎ資料になります。

そして（5）の「何が正しい動作か」だけは、AI には書けません。ここはあなたが書き足してください。

8. 準備チェックリスト

相談前に

• コードの置き場所を確認した（GitHubのURL、または未整備であることを把握した）
• 使っている外部サービスの一覧を作った
• 環境変数の項目名リストを作った（値は含めない）
• 動いているURLを確認した
• 「必ず成り立つべきこと」を10個書き出した
• 現在のユーザー数、決済の有無、個人情報の有無を整理した
• いちばん困っていることを1行で言えるようにした

作業を依頼する段階で

• 秘密保持契約について確認した
• リポジトリへのアクセス方法を決めた（招待、権限の範囲）
• 鍵の受け渡し方法を決めた（安全な経路で）
• 作業完了後に鍵を作り直す前提を共有した

まとめ

• 費用を決めるのはコードの量ではなく「分からなさ」。整理するだけで見積もりは下がる
• 渡すべきは5つ — リポジトリ、外部サービス一覧、環境変数の項目名、動いているURL、「何が正しい動作か」
• 最後の1つが最も価値があり、あなたにしか書けない
• 鍵の値は相談段階では不要。項目名だけで判断材料としては十分
• 「作り直したほうが早い」は必ずしも正しくない。まず優先度つきの所見を出してもらってから決める

そして最後に。準備が完璧でなくても相談して構いません。 「何も分からない状態です」から始まる相談はごく普通で、その場合は現状の把握から一緒にやります。

現状を自分で確かめてから相談したい方は、無料セルフ診断（20問・登録不要）を先に通してみてください。その結果をそのまま引き継ぎ資料の一部として使えます。

技術面で何を確認すべきかは AIで作ったアプリを公開する前に にまとめています。