結論：先に整理して渡すほど、見積もりは早く正確になる
AI（Claude Code、Cursor、Lovable、v0、Bolt など）で作ったアプリや社内の業務システムを、エンジニアに見てもらう・引き継ぐときに先に用意するものは、次の3つに集約できます。
- 何がどこにあるか — コード、外部サービス、環境変数の項目名、動いているURL、本番データとアカウント
- 何が正しい動作か — 箇条書きで十分です。これは発注する側にしか書けません
- 安全な渡し方の段取り — NDA（秘密保持契約）、必要最小限の権限、鍵は値ではなく項目名から
費用を決めるのはコードの量ではなく、「分からなさ」です。上の3つが揃っているほど、エンジニアが「分からないから多めに見ておく」分が減ります。
この記事は、コードを読まない立場で発注を判断する人——個人事業主、中小企業の経営者、CTO（技術の責任者）のいない会社で開発を任されている担当者——に向けて書いています。個人で作ったアプリにも、そのまま使えます。
準備が揃っていなくても相談はできます。分からない項目は「分からない」と書いておけば、それ自体が見積もりの材料になります。自分でどこまで把握できているかを先に知りたい場合は、無料セルフ診断（20問・登録不要）を試してみてください。答えに詰まった項目が、そのまま「分からないこと」の一覧になります。
1. 費用を決めるのは「コードの量」ではなく「分からなさ」
引き継ぎや調査の費用は、コードの行数では決まりません。私の感覚では、見積もりはおおよそこういう計算になります。
作業の量 ＋ 分からないことの量 × リスク
効いてくるのは後ろの項です。「たぶん1日で終わるが、何が出てくるか分からないので3日分見ておく」——これは水増しではなく、分からないものに対する誠実な見積もりです。
逆に言えば、分からないことを減らせば、見積もりは下がり、ぶれも小さくなります。そして減らす作業の多くは、そのアプリを使い、AIに作らせた側にしかできません。
2. 渡す資料：基本の5つ
（1）コードの置き場所
GitHub のリポジトリ（コードの保管場所）のURL、または招待です。
- Lovable や Bolt の中だけで作っている場合: どちらにも公式に GitHub と同期する機能があります。まずそれでリポジトリに出してください。Lovable の連携では、リポジトリを作る先として個人アカウントか Organization（組織アカウント）かを選べます。
- 会社の業務で使うシステムの場合: 置き場所は担当者個人のアカウントではなく、会社の Organization にしておくと後の権限管理が楽になります（理由は4章）。
- どこにあるか分からない場合: 正直にそう伝えてください。それ自体が最初に確認する項目になります。
（2）使っている外部サービスの一覧
ホスティング（公開先のサーバー）、データベース、ログイン機能、決済、メール送信、AI の API（外部の AI 機能を呼び出す窓口）など。業務システムなら、「誰の名義で契約しているか」も書き添えます（理由は3章）。
例（架空）:
- ホスティング: Vercel（契約: 会社 / 管理者: 総務の担当者）
- データベース・ログイン機能: Supabase（契約: 作った担当者の個人アカウント）
- 決済: Stripe
- メール送信: Resend
- AI: Anthropic Claude API
分からなければ、AI に下書きさせられます。
このプロジェクトが使っている外部サービスを全部洗い出して、
それぞれ「何のために使っているか」を1行で説明した一覧を作ってください。
package.json、環境変数の項目名、コード内の呼び出し先URLから判断してください。
環境変数の値は書き出さないでください。
（3）環境変数の「項目名」リスト（値は渡さない）
環境変数とは、APIキーやパスワードのようにコードの外に置いておく設定値のことです。渡すのは項目名だけで、値そのものは渡しません。
例:
NEXT_PUBLIC_SUPABASE_URL
NEXT_PUBLIC_SUPABASE_ANON_KEY
SUPABASE_SERVICE_ROLE_KEY
STRIPE_SECRET_KEY
STRIPE_WEBHOOK_SECRET
RESEND_API_KEY
項目名だけで、エンジニアは「何が必要か」「どこに危険がありそうか」の見当をつけられます（何を見ているかは、10章の「エンジニア向けの補足」に書きました）。値が必要になるのは、実際に手元で動かす段階からです。
（4）動いているURL
本番のURLです。止まっているなら、動いていた頃のURLでも構いません。ログインが必要なアプリなら、テスト用のアカウントを1つ用意しておくと話が早く進みます。
（5）「何が正しい動作か」 ← 最も価値がある
エンジニアはコードを読めば「何をしているか」は分かります。しかし「何をすべきか」は分かりません。それを知っているのは、使っている側だけです。
箇条書きで十分です。
例（架空の業務アプリ）:
- 営業担当は、自分の担当顧客だけを見られる。上長は部署全員の顧客を見られる
- 見積書は、上長が承認するまで顧客に送れない
- 受注が確定したら、在庫が自動で引き当てられる
- 同じメールアドレスで2回は登録できない
- 退職者のアカウントは無効になるが、その人が作った見積書は残る
コードを読むだけでは、これらが仕様なのかバグなのかを判別できません。たとえば「ほかの営業担当の顧客が見えてしまう」状態を見つけたとき、それが不具合なのか意図した動きなのかは、発注する側に聞くしかありません。この一覧があるだけで、「直したら実は仕様だった」というリスクの見込み分が減ります。
3. 業務で使っているシステムなら、さらに3つ
社内の業務を回しているシステムでは、コードの外側の情報が見積もりを大きく左右します。
（6）誰が、どの業務で使っているか
- 利用者は誰か（社員何人、取引先、一般の顧客）
- どの業務の、どの工程で使っているか（例: 受注 → 出荷 → 請求のうち、受注と請求）
- 止まったら何が困るか、止めてよい時間帯はあるか
止められない業務に組み込まれているほど、切り替えの手順を慎重に組む必要があり、作業の進め方が変わります。
（7）本番データの置き場所と、アカウントの名義
- 本番のデータはどこにあるか（データベース、スプレッドシート、外部サービスの中）。バックアップはあるか
- GitHub、ホスティング、データベース、ドメイン（URL の「example.co.jp」のような部分）、決済などの各アカウントは、誰の名義で、誰のメールアドレスと支払い方法で契約されているか
- 管理者としてログインできる人は誰か
一般論として、業務で使うアカウントは会社の名義（会社のメールアドレスと支払い方法）で持ち、作業する人には必要な権限だけを付ける形が望ましいと私は考えています。作った担当者の個人アカウントで契約されていると、その人が異動・退職したときに、ログインも権限の付け替えもできなくなるおそれがあるからです。名義が個人になっている場合は、引き継ぎの最初の作業として「会社名義への移管」が見積もりに入ります。なぜ名義を社内に残すのか、個人アカウントにあるリポジトリを会社の Organization に移す方法、クラウドのアカウントの持ち方は、内製か外注か、SaaSかスクラッチかの決め方の「名義」の節にまとめています。
参考までに、私が開発を担当する場合も、リポジトリとクラウドは初日から発注者の名義で作り、私はコラボレーター（共同作業者）の権限で作業します。契約が終わるときは、その権限を外すだけです。
（8）既存の資料
完璧なものでなくて構いません。
- 要件のメモ、業務マニュアル、画面のスクリーンショット
- 以前に別の会社から取った見積書や提案書
- AI とのやりとりの履歴（どんな指示で作らせたか）。意図した仕様の手がかりになります。鍵を貼ったことがあるなら、その部分は除いてから渡してください
4. 渡してはいけないもの・安全な渡し方
渡してはいけないもの
鍵やパスワードの値。 相談や見積もりの段階では不要です。項目名だけで足ります。
顧客の個人情報を含む本番データ。 動作の確認には、まずテスト用の架空データで足りないかを考えます。
個人情報保護法では、利用目的の達成に必要な範囲内で個人データの取扱いを委託し、それに伴って個人データを渡す場合、受け取る側は、第三者提供の規定の上では「第三者」に当たらないとされています（第27条第5項第1号）。ただし委託する側は、渡した個人データが安全に管理されるよう、委託先に「必要かつ適切な監督」を行わなければなりません（第25条）。本番データを渡すなら、範囲・扱い方・作業後の削除を契約で決めてからにしてください。個別の判断が必要な場合は、専門家に確認してください。
「全部のパスワードが書いてあるメモ」。 渡す側にとっても危険です。必要な範囲だけを、必要な時点で渡します。
安全な渡し方：段階ごとに広げる
| 段階 | 渡すもの | 渡し方 |
|---|---|---|
| 相談・見積もり | 2章・3章の資料、画面 | NDA を結んでから。コードは渡さなくても始められる |
| 調査 | リポジトリの閲覧 | 閲覧（Read）権限で招待する（会社の Organization に置いた場合。個人アカウントのリポジトリでは閲覧だけに絞れない） |
| 作業 | 必要な鍵の値、書き込み権限 | 鍵はパスワード管理ツールの共有機能などで。権限は作業に必要な分だけ |
| 終了 | なし | 権限を外し、渡した鍵を作り直す（再発行する） |
考え方の土台は最小権限です。米国 NIST（国立標準技術研究所）の用語集は、利用者のアクセス権を「割り当てられた作業を行うのに必要な最小限」に制限する、というセキュリティの原則として定義しています。
NDA は最初に。 秘密保持契約は、コードや資料を見せる前に結ぶのが普通です。このサイトでも、商談前の段階から NDA を締結でき、貴社のフォーマットでの締結にも対応しています。
リポジトリの権限（GitHub の場合）。 会社の判断に関わるので、少し詳しく書きます。
- 個人アカウントのリポジトリでは、共同作業者に読み取り専用の権限を付けられません。 GitHub の公式ドキュメントに明記されています。招待した人は、閲覧だけでなく書き込みもできる状態になります
- 権限を細かく分けたい場合、GitHub は Organization にリポジトリを作る（または移す）ことを勧めています
- Organization では、Read・Triage・Write・Maintain・Admin の5段階から選べます。調査の段階は Read（閲覧と議論のみ）、手を動かす段階で Write にするのが目安です。リポジトリの削除やセキュリティ設定まで含む Admin を、外部の人に渡す必要はまずありません
- 組織のメンバーではない人に、特定のリポジトリだけへのアクセスを与える「外部コラボレーター」という形があります。作業が終わったら、そのリポジトリへのアクセスを外します
鍵は作業が終わったら作り直す。 渡した鍵は、作業が終わった時点で再発行し、古いものを使えなくするのが安全です。リポジトリに鍵をコミットしてしまった場合、GitHub のドキュメントは、最初にすべきことは鍵の無効化・再発行だとしています。履歴から消す作業より先です。チャットに貼ってしまった場合も、同じように鍵の作り直しを最初に行うのが安全だと私は考えています。
5. 見積もりが決まる要因
コードの量そのものより、次の「分からなさ」のほうが見積もりを動かします。右端の列は、発注する側が事前に用意できるものです。
| 要因 | 見積もりが上がる理由 | 下げるために用意できるもの |
|---|---|---|
| 何が正しい動作か分からない | 直したら実は仕様だった、というリスクを見込むため | 「必ず成り立つべきこと」の箇条書き（2章の5） |
| 本番と手元のコードが一致しているか不明 | 何が動いているかの調査から始める必要があるため | どこから、どうやって公開しているか。管理画面で直接変えた箇所のメモ |
| 本番環境しかない（テスト環境が無い） | すべての作業が本番作業になり、慎重に進めるため | 無いなら無いと伝える。テスト環境づくりが最初の作業になる |
| お金・個人情報が動いている | 確認する範囲が広がり、優先度も上がるため | 決済の有無、預かっている個人情報の種類の一覧 |
| アカウントの名義・ログイン方法が不明 | 権限の回復や名義の移管から始めるため | アカウントの名義と管理者の一覧（3章の7） |
| 止められない業務に組み込まれている | 切り替えの手順を慎重に組む必要があるため | 利用者と業務の流れ、止めてよい時間帯（3章の6） |
| 依頼の範囲が「全部見てほしい」 | 範囲が広いほど調べる量が増えるため | いちばん困っていることと期限を1行で |
| 外部サービスや機能を把握できていない | 一つずつ調べる必要があるため | 外部サービスの一覧（2章の2） |
6. 依頼後、専門家が最初にすること
ここに書くのは一般的な流れです。
- 本番に触らずに読む — 閲覧権限でコードと設定を読み、全体の構造と危なそうな箇所の見当をつけます。
- 本番以外の環境で再現する — 手元やテスト環境でアプリを動かし、問題を実際に再現します。使うのはテスト用のデータです。
- リスクを優先度順に並べる — 「今すぐ直す（お金・個人情報・不正アクセスに関わる）」「近いうちに直す」「後でよい」のように分けます。
- 範囲を合意する — 何を直し、何を直さないか、どの順番で進めるか、直すのか作り直すのかを、所見を見ながら決めます。
この段階の成果物は「何がどれくらい危ないか」の所見で、修正そのものではありません。修正の見積もりは、範囲が決まってから出すのが順序です。
範囲・成果物・秘密保持・権利の帰属は契約書に書きます。契約形態（請負・準委任）の違いはシステム開発の契約形態の選び方にまとめています。契約書のひな形を探しているなら、IPA（情報処理推進機構）が公開している「情報システム・モデル取引・契約書」は、ユーザ企業とITベンダのどちらかにメリットが偏らない契約書を目指して作られたものです。
このサイトに頼む場合
初回の相談（30分）と見積もりは無料です。状況を伺ったうえで概算の見積もりをお出しし、精度を上げる必要がある場合に限って、有償の要件定義をご提案します。既存のコードを見ながらの相談やレビューは、スポット技術相談（1時間¥15,000〜）でお受けしています。
セキュリティの状態だけを先に確かめたい場合は、診断を使う方法もあります。引き継ぎの見積もりに必須のものではありません。内容と料金はAIで作ったアプリのセキュリティ診断にまとめています。引き継いだ後の開発や、技術の判断役そのものを任せたい場合はCTO代行・外部開発責任者をご覧ください。
7. 「作り直したほうが早い」と言われたら
相談すると「これは作り直したほうが早い」と言われることがあります。必ずしも正しくありません。
動いているシステムには、利用者がどう使うか・どの機能が要るかという知見と、すでに入っているデータがあります。作り直すと、その知見も一度手放すことになります。決める前に優先度つきの所見を出してもらい、「直して使う」「一部作り直す」「作り直す」のどれに当たるかを、直して使うか、作り直すかの判断表に照らしてください。「直す場合」「作り直す場合」の両方の見積もりを並べると、比べやすくなります。
8. 相談で聞かれること（答えを用意しておく）
初回の相談でたいてい聞かれることです。答えを用意しておくと、その場で話が進みます。
- いま何人が使っていますか？ 0人なら止めて直せます。業務システムなら、毎日使う社員の人数も
- お金は動いていますか？ 決済があれば優先度が上がります
- 個人情報を預かっていますか？ メールアドレスや氏名だけでも、「預かっている」と答えてください
- 止まったら、どの業務が困りますか？
- いちばん困っていることは何ですか？ 「なんとなく不安」でも構いません
- いつまでに、どうなっていたいですか？ 期限があれば、優先順位の付け方が変わります
- 予算の上限はありますか？ 上限だけでも分かれば、その範囲でできることを組み立てられます。「まだ分からない」も答えの一つです
9. 引き継ぎ資料を AI に作らせる
ここまでの資料の多くは、AI に下書きさせられます。
このプロジェクトについて、エンジニアに引き継ぐための資料を作成してください。
読み手には非エンジニアの経営者も含むので、専門用語には短い説明を添えてください。
含めてほしい内容:
(1) このアプリが何をするものか（3行程度）
(2) 使っている技術と外部サービスの一覧（それぞれ何のために使っているか）
(3) 環境変数の項目名の一覧と、それぞれ何のための値か
※ 値そのものは絶対に書かないでください。.env ファイルの中身も書き出さないでください
(4) 主要な機能と、それぞれの画面/URLの対応
(5) データベースのテーブル一覧と、それぞれ何を保存しているか
(6) デプロイの方法（どこに、どうやって公開されているか）
(7) 現時点で分かっている不具合・未完成の箇所
(8) コードを読んで気づいた、注意が必要な箇所
1つの Markdown ファイルとして書き出してください。
出てきたものを自分で一度読み、違うところを直してください。それだけで、かなり使える引き継ぎ資料になります。
ただし、2章の（5）「何が正しい動作か」と、3章の（6）（7）——誰がどの業務で使い、アカウントが誰の名義か——はコードからは分かりません。ここは自分で書き足します。渡す前に、出力に鍵の値が混じっていないかも必ず確認してください。
10. エンジニア向けの補足（受け取る側が最初に見るところ）
この章は、引き継ぎを受けるエンジニア向けです。発注する側は読み飛ばして構いません。
NEXT_PUBLIC_の付いた項目: Next.js では、NEXT_PUBLIC_で始まる環境変数はビルド時にブラウザへ送る JavaScript に埋め込まれ、付いていないものはサーバー側（Node.js 環境）でしか読めません。項目名の一覧で、秘密であるべき値にこの接頭辞が付いていないかを最初に見ます。- Supabase の
service_roleキー（新しい方式では secret キー）: Supabase のドキュメントは、secret キーはすべての Row Level Security（行単位のアクセス制御）を迂回し、ブラウザ・配布するアプリ・ソース管理に置いてはいけないとしています。service_roleはその旧方式です。2章の例でSUPABASE_SERVICE_ROLE_KEYにNEXT_PUBLIC_が付いていないことは、項目名だけで確認できます。 - 再現環境を先に作る: 本番の鍵ではなく、テスト用のプロジェクトと鍵で手元に再現環境を作ってから調査します。本番しか無い場合は、テスト環境づくりを最初の作業として範囲に入れます。
- デプロイ元を確かめる: 本番がどのコミット（変更の記録）から作られたかを、ホスティング側のデプロイ履歴で確かめてから手元のコードを信用します。
発注する側向けの説明は、NEXT_PUBLIC_ と service_role の解説にあります。
11. 準備チェックリスト
相談の前に
- コードの置き場所を確認した（GitHub の URL、または未整備であることを把握した）
- 使っている外部サービスの一覧を作った（業務システムなら契約の名義も）
- 環境変数の項目名リストを作った（値は含めない）
- 動いているURLを確認し、テスト用アカウントを用意した
- 「必ず成り立つべきこと」を書き出した
- 誰がどの業務で使っているか、止まったら何が困るかを整理した
- 本番データの置き場所と、各アカウントの名義・管理者を整理した
- 利用者数、決済の有無、個人情報の有無を整理した
- いちばん困っていることを1行で言えるようにした
- NDA を結んだ（2章・3章の資料を渡す前に）
作業を依頼する段階で
- リポジトリへの招待方法と権限を決めた（閲覧から始め、必要に応じて広げる）
- 鍵の受け渡し方法を決めた（メール・チャットに貼らない）
- 本番データを渡すかどうか、渡すなら扱いと削除を契約で決めた
- 作業が終わったら、権限を外して鍵を作り直すことを合意した
まとめ
- 費用を決めるのはコードの量ではなく「分からなさ」。整理して渡すだけで、見積もりは早く正確になる
- 基本の5つ（リポジトリ・外部サービス・環境変数の項目名・URL・正しい動作）に、業務システムなら「使う人と業務」「本番データとアカウントの名義」「既存の資料」を足す
- 鍵の値と本番の個人データは相談段階では渡さない。NDA、最小限の権限、終了時に権限を外して鍵を作り直す
- 依頼後の最初の成果物は修正ではなく、優先度つきの所見と範囲の合意
- 「作り直したほうが早い」は、所見を見てから判断する