「エンジニアに相談したいけど、何を聞けばいいのか分からない」
これは、この分野でいちばんよく聞く言葉です。そして——分からなくて構いません。こちらから質問します。
ただ、いくつか先に用意しておくと、見積もりが早く、安く、正確になります。この記事はそのためのものです。
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で作ったアプリを公開する前に にまとめています。