アイデアを「動くもの」にする。検証期のAI試作と費用の全体像

このガイドは、「誰の、どんな悩みを、どう解決するか」が一文で言え、需要の手がかりも掴め、サービス名とドメインまで決めた人のためのものです。構想はもう固まっています。ここから先で必要なのは、頭の中にあるアイデアを実際に触れる「動くもの」に変えることと、自己資金300万円という現実的な予算の中で、どこまでが自分でできて、どこから先に見積もりが必要になるのかを、感覚ではなく数字で把握することです。

なお「自己資金300万円」という数字は、絶対条件ではなく目安です。個人が本業を続けながらMVP開発に踏み出す際によく見られる金額帯の中央値に近い水準として置いています。手元資金が200万円でも400万円でも、このガイドの考え方（削れない機能とそうでない機能を仕分ける、月次支出から資金が何ヶ月分持つかを逆算する）はそのまま使えます。金額そのものより、「自分の資金で何ヶ月分の活動を支えられるか」という時間軸の感覚を掴むことがこのガイドの目的です。

このガイドを読み終える頃には、AIを使った試作（MVP（実用最小限の製品））を自分の手で動かせる状態になっているか、あるいは「自分では無理」という判断を根拠を持って下せているはずです。そしてもし外部に発注する必要が出てきた場合には、見積もりの金額が高いのか妥当なのかを判断でき、削るべき機能の交渉もできる状態になります。次の「開発期」ガイドでは、内製か外注かの判断が固まった前提で、実際の発注準備・契約・法務やお金の整備に進みます。

なお、このガイドではSTEP1〜STEP8の各所で「副業でリベンジに挑む会社員」「士業・医療職からのスピンオフ」「店舗経営者」という3つの読者像を具体例として使っています。これは3人のうち誰か1人だけを想定読者にしているという意味ではありません。あなたがどのタイプに近くても、他の2タイプの具体例の中に、自分の状況にそのまま置き換えられる考え方が混ざっていることが多いので、「自分と違う例だから」と読み飛ばさずに目を通しておくと、思わぬヒントが見つかります。特に、複数店舗・複数事業者への展開を考えている人向けの論点（STEP4-4）は、ジャンルを問わず「評判が広がって他の人にも使いたいと言われる」可能性がある人全員に関わる内容です。

このガイドの全体地図

• STEP1：作り方の方針を決める（STEP1-1〜1-4）
• STEP2：AIと一緒に試作する（STEP2-1〜2-6）
• STEP3：予算感を掴む（STEP3-1〜3-5）
• STEP4：本番に近づける・安全を確保する（STEP4-1〜4-5）
• STEP5：自分で無理なときの見極め（STEP5-1〜5-5）
• STEP6：見積もりを取る・費用の妥当性を確認する（STEP6-1〜6-6）
• STEP7：見落としがちな費用を確認する（STEP7-1〜7-8）
• STEP8：交渉する（STEP8-1）

STEP1：作り方の方針を決める

STEP1-1：ノーコードとAIコーディングどちらから始めるか判断する

土日にサービス作りの時間を確保できても、最初の分岐で選択を誤ると、その週末をまるごと無駄にしてしまいます。ノーコードツールで組み立てるのか、AIに指示を出しながらコードを書かせるバイブコーディングで進めるのかは、あなたが作りたいものの複雑さと、将来どこまで機能を広げたいかによって変わります。

やること：

1. 自分のサービスに「他にはない独自ロジック」がどれくらいあるかを書き出す。例えば「予約の空き状況を自動計算する」「利用者ごとに異なる料金を出し分ける」のように、既存のテンプレートには無い条件分岐が1つでもあれば、それは独自ロジックとしてカウントする。個人向けSaaSを作ろうとしている副業会社員であれば、「利用者Aと利用者Bのマッチング条件を複数の属性で絞り込む」「利用者ごとの進捗ステータスに応じて表示を出し分ける」のような処理も独自ロジックに該当する。士業・医療職からのスピンオフであれば、税務の控除計算や保険点数の算定ロジックのように、条件分岐そのものが業務知識と一体化しているケースが多く、この場合は独自ロジックの「数」だけでなく「複雑さ」も同時に見積もっておく必要がある。逆に「フォームを置いて内容を一覧表示するだけ」ならノーコードの標準機能で足りることが多い
2. ノーコードの制約（デザインの自由度、外部連携の可否、将来の拡張性）を確認する。特に「今は使わないが半年後に欲しくなりそうな機能」が候補ツールの拡張範囲に入っているかを見ておくと、後から作り直す手戻りを防げる
3. どちらで始めても後戻りできる範囲かを見積もる。土日2回分（合計4日程度）で「今の選択が間違っていた」と分かる規模に留めておくと、選び直しのコストを抑えられる

詳しくは → ノーコードとAIコーディング、非エンジニアはどちらから始めるべきか

完了の目安： 自分がノーコードとAIコーディングのどちらから始めるか、理由込みで人に説明できる状態になっていること。

STEP1-2：非エンジニアの最初の一歩を知る

店舗経営者であれば「来店予約をカレンダーで管理したい」、副業会社員であれば「マッチングサービスを形にしたい」というように、頭の中にあるアイデアは具体的でも、それをAIへの指示に変える最初の一歩でつまずく人がほとんどです。まず必要なのは大きな設計図を描くことではなく、AIと一緒に手を動かして「これなら進められる」という感触を得ることです。

副業でリベンジに挑む会社員（ペルソナA）の多くは、数年前に一度挫折した経験を引きずったまま「また同じところでつまずくのでは」という不安を抱えています。これは士業や医療職からのスピンオフ（ペルソナB）や店舗経営者（ペルソナC）が抱える「専門知識はあるが技術は初めて」という不安とは、実は性質が異なります。ペルソナBやCにとっては純粋な「未知への不安」ですが、ペルソナAにとっては「一度失敗した場所にもう一度足を踏み入れる」という、マイナスの記憶からの再出発です。この違いを自分自身が認識しておくだけでも、最初のつまずきに対する心の構えが変わります。

技術的な操作という意味では、AIに指示を出して画面が変化する経験をまだ一度もしていなければ、スタート地点は全員同じところにあります。プロンプトを打ち込む、結果を見る、直す、というボタン操作のレベルに関しては、過去の経験の有無で差が出ることはほとんどありません。ただし、これは「心理的な負荷まで同じ」という意味ではありません。ペルソナAには、未経験者にはない「またダメだった」という上乗せの恐怖があります。操作を覚えるスタートラインは同じでも、そこに乗せている荷物の重さは違う、というのが実態に近い表現です。この「今のAIは当時とどう違うのか」という具体的な検証は、STEP5-2で当時と今のやり取りを比較しながら扱います。ここでは「操作の土台は同じだが、抱えている不安の重さは人によって違って当然だ」と知っておくだけで十分です。

やること：

1. パソコンとブラウザだけで始められる環境を用意する
2. 最初の指示（プロンプト）を1つだけ書いて、AIに動くものを作らせてみる。例えば店舗経営者なら「来店予約を入力するとカレンダーに表示される画面を作って」、副業会社員が個人向けマッチングサービスを考えているなら「利用者の一覧を表示して、条件で絞り込める画面を作って」のように、自分の本命サービスに近い一文でまず試してみると、その後の手応えが本命につながりやすい
3. エラーが出ても止まらず、AIに「このエラーが出た」とそのまま伝える練習をする

詳しくは → プログラミング未経験でもAIと一緒に試作を作る、最初の一歩

完了の目安： 何か1つでも「AIに指示を出して、画面に変化が起きた」経験をしていること。

STEP1-3：最初に作る練習台を選ぶ

いきなり本命のサービスから作り始めると、慣れない操作と本気のアイデアが同時に押し寄せて挫折しやすくなります。士業や医療職からのスピンオフ（ペルソナB）を考えている人ほど、本業の合間の限られた時間で「練習」と「本番」を同時にやろうとして疲弊しがちです。これは士業・医療職に限った話ではなく、店舗の閉店後の時間を使って作業する店舗経営者（ペルソナC）にとっても同じ構図です。「本業の隙間時間しか使えない」という制約は職種を問わず共通しており、だからこそ本命と切り離した小さな練習台を用意する意味があります。副業でリベンジに挑む会社員（ペルソナA）の場合は、本業の勤務時間とは完全に切り離せる分だけ時間の確保は比較的しやすいものの、逆に「本命に近いテーマで練習してしまい、失敗したときのダメージが本命に直結する」というリスクがあります。個人向けSaaS（例えば習い事の先生と生徒をマッチングするようなサービス）を考えているなら、練習台はその中核ロジック（マッチング条件の絞り込みなど）を含まない、もっと単純な「利用者一覧を表示するだけの画面」程度に留めておくと、練習で心が折れても本命への影響を最小限にできます。

やること：

1. 本命のサービスとは別に、小さな練習用テーマを1つ決める（例：自分の業務で使っているExcel管理表をWebアプリ化してみる。店舗経営者なら「毎日手書きしている来店予約メモをWebフォーム化する」程度の小さなお題でも十分。副業でマッチング系サービスを考えている会社員なら「自分の友人リストを一覧表示して、条件で絞り込むだけの画面」のように、本命の中核ロジックを含まない縮小版から始めるとダメージを抑えられる。士業・医療職スピンオフであれば「顧客名簿を一覧表示するだけの画面」のように、報酬計算や算定ロジックを一切含まない台帳的な練習台から始めると、専門知識の検証と操作の練習を混同せずに済む）
2. 練習台には「本番と同じ技術構成」を使う（本番で使うつもりのAIツールで作る）
3. 練習台が動いたら、そこで得た手応えを本命のサービスに転用する

詳しくは → 最初に作るものは何がいいか。バイブコーディングの練習台の選び方

完了の目安： 練習台となるテーマが1つ決まり、本命のサービスと切り離して着手できる状態になっていること。

STEP1-4：使うツールを比較する

ChatGPT、Claude、専用のAIコーディングツールと選択肢が多く、店舗経営者（ペルソナC）のようにITの専門用語に馴染みが薄い人ほど「結局どれを使えばいいのか」で足が止まります。ここで大事なのは最強のツールを探すことではなく、自分の作りたいものに対して「今すぐ使い始められる」ツールを1つ選ぶことです。

やること：

1. 自分が作りたいものの規模（1画面だけか、複数画面の業務システムか）を確認する
2. 候補ツールの料金プランと無料枠を比較する
3. まずは1つだけ選び、他のツールとの比較は後回しにする

詳しくは → ChatGPT・Claude・AIコーディングツール、非エンジニアはどれを選ぶべきか

完了の目安： 使うツールが1つに決まり、アカウント登録まで済んでいること。

STEP2：AIと一緒に試作する

STEP2-1：プロンプトの基本形を知る

思いつくままに「いい感じのアプリを作って」と指示しても、AIは何を作ればいいか判断できません。特に店舗経営者（ペルソナC）が「予約管理を楽にしたい」といった漠然とした要望を持ち込む場合、その要望をAIが実装できる粒度まで具体化する型を知っているかどうかで、試作の完成度が大きく変わります。副業でリベンジに挑む会社員（ペルソナA）が個人向けマッチングサービスを考えている場合も同様で、「いい感じのマッチングアプリを作って」ではAIは動けません。「利用者Aがプロフィールを登録すると、条件が近い利用者Bを最大5件、一致度の高い順に表示する」のように、入力と出力を具体的な一文に落とし込む作業は、業種を問わず最初の壁になります。

やること：

1. 「誰が」「何のために」「何を入力して」「何が返ってくるか」の4点を1つの指示文にまとめる。例えば予約管理ツールなら「お客様が来店希望日時を入力すると、既存の予約と重複していないかを確認し、空いていれば予約完了、埋まっていれば別の候補日時を3つ提示する」のように、入力と出力のペアで具体化する。個人向けマッチングサービスなら「利用者がプロフィールを登録すると、条件が近い利用者を一致度順に一覧表示する」のように、同じ型で具体化できる
2. 最初から完璧な指示を書こうとせず、まず動く最小限の指示を出す（例：「日付を入力すると空き・満席だけを表示する」という最小形からスタートし、候補日時の提示は次の指示で足す）
3. 出てきた結果を見てから、指示文に条件を1つずつ追加していく

詳しくは → アプリを作るためのプロンプトの書き方、最初に知っておきたい型

完了の目安： 自分のサービスの核となる機能について、AIに渡す指示文を1つ書き切れていること。

STEP2-2：AIとの対話を繰り返して改善する

一度の指示で完成形が出てくることはほとんどありません。副業でリベンジに挑む人（ペルソナA）が過去に挫折した理由の一つは、「一発で完成させよう」として、うまくいかないと諦めてしまうパターンです。AIとの対話は本質的に「試して、直して、また試す」の繰り返しだと知っておくことが、継続の土台になります。

やること：

1. 一度に直す範囲を「1機能」または「1つの不具合」に絞る
2. 動いたら次の要望を足す、というサイクルを小さく回す
3. 変更前の状態がわかるように、動いた時点の区切りを意識する

詳しくは → AIとの対話を繰り返して試作を改善していく、基本的な進め方

完了の目安： 「指示 → 結果確認 → 修正指示」のサイクルを、自分の力で3周以上回せていること。

非エンジニアが自分の手でAIに試作を組ませるという進め方自体、本当に現実的なのか気になる人もいるはずです。非エンジニアでもAIで試作は作れるのかでは、その現実味と「どこまでが試作で、どこからが本番化なのか」という線引きを扱っています。

STEP2-3：AIの回答を鵜呑みにしない確認をする

AIは自信満々に、実際には存在しない仕様や間違ったロジックを提示してくることがあります（ハルシネーションと呼ばれる現象です）。これは士業や医療職からのスピンオフ（ペルソナB）にとって特に注意が必要な点で、専門知識に関わる計算やルールをそのままAIに実装させると、業務上のルールと微妙にずれた仕様が紛れ込むことがあります。ただしこれは専門職に限った話ではありません。店舗経営者（ペルソナC）がSTEP1-1で洗い出した「独自ロジック」、例えば予約の空き状況を自動計算する処理でも、AIは平気で誤った判定を紛れ込ませます。実際にありがちな失敗が、「実際には満席なのに、時間帯の重複判定が甘く空きありと表示してしまう」というパターンです。見た目には正常に動いているように見えるため、検算をしない限り気づけません。

ここで「3パターンで検算する」という目安を示していますが、この「3」という数字自体に絶対的な根拠があるわけではありません。重要なのは件数よりも、検算すべき値の「種類」を漏れなく洗い出すことです。具体的には、①典型的な値（最も頻繁に発生するケース）、②境界値（条件分岐がちょうど切り替わる値。例えば控除額の上限ちょうど、予約枠がちょうど埋まる瞬間）、③例外値（通常想定しない組み合わせ。例えば複数の控除が同時に重なる、時間帯が数分だけ重複する）という3つの「種類」をまず洗い出し、その種類ごとに具体的な数値を1つずつ当てはめていく、という順序で考えると、単に「3回試せばいい」という表面的な理解を避けられます。専門職であれば、この境界値・例外値の洗い出しそのものが、実は発注先への引き継ぎ資料（STEP5-1で扱う「専門知識の引き継ぎコスト」）の土台にもなります。

やること：

1. AIが提示したロジックのうち、自分の専門知識や独自ルールに関わる部分は必ず自分の目で検算する。まず「典型的な値」「境界値」「例外値」という3つの種類を意識して、自分の業務の中でそれぞれに該当する具体的な数値を洗い出す。そのうえで、AIの出力と手計算の結果を1件ずつ突き合わせる。例えば税理士が報酬シミュレーターを作るなら「標準的な収入額（典型値）」「控除の合計がちょうど上限に達するケース（境界値）」「複数の控除が同時に重なり端数が出るケース（例外値）」の組み合わせで検算するイメージ。医療職であれば投薬量計算や保険点数算定のように、体重や年齢の境界をまたぐケース・複数の加算条件が重なるケースを含めて検算する。店舗経営者の予約管理ツールであれば「通常の空き枠（典型値）」「ちょうど埋まる境界のケース（境界値）」「時間帯が数分だけ重複するケース（例外値）」の組み合わせで、実際の予約状況とAIの表示結果を突き合わせる
2. 「本当にこの仕様で合っているか」をAI自身にも聞き返してみる
3. 不安な箇所は小さなテストデータで実際に動かして確認する

詳しくは → AIの回答をそのまま信じて実装する前に、確認すべきこと

完了の目安： 試作の中核ロジックについて、少なくとも一度は自分の手で検算・確認していること。

STEP2-4：非エンジニアがつまずきやすい壁を知っておく

プログラミング未経験者が最初につまずく壁には、ある程度共通のパターンがあります。事前にそれを知っておくだけで、実際にぶつかったときの「自分だけができていないのでは」という焦りを減らせます。これは特にペルソナAやCのように、ITの前提知識が薄いまま試作に飛び込む人に効きます。

やること：

1. よくあるつまずきポイント（環境構築、専門用語、エラーメッセージの読み方）を事前に一覧で把握する
2. 自分が今どのつまずきに該当しているかを照合する
3. 「みんなが通る道」だと理解した上で、1つずつ潰していく

詳しくは → 非エンジニアがバイブコーディングでつまずく、典型的な壁

完了の目安： 自分が直面しているつまずきが、典型的なパターンのどれに当たるか特定できていること。

STEP2-5：よくある3つの不具合原因を知る

昨日まで動いていたものが、今日は動かなくなっている。バイブコーディングを進めていると誰もが一度は経験する状況です。原因を知らないまま闇雲にAIに「直して」と繰り返すと、かえって状況が悪化することもあります。

やること：

1. 不具合が起きたら、まず「何を変更した直後か」を思い出す
2. よくある3つの原因パターン（設定の競合、変更の積み重ねによる矛盾、外部サービス側の変化）のどれに近いか照らし合わせる
3. 原因の見当がついたら、その部分だけをAIに絞って伝える

詳しくは → AIで作った試作が動かなくなる、よくある3つの原因

完了の目安： 不具合が起きたときに、原因の候補を絞り込んでからAIに質問する習慣がついていること。

STEP2-6：AIがバグを直せないときの対処

同じエラーを何度AIに伝えても直らず、むしろ的外れな修正を繰り返して状況が悪化していく。これはバイブコーディングで最も心が折れやすい瞬間です。ここで「自分の指示が悪いのでは」と自分を責める前に、AIが手詰まりになったときの定石の対処法を知っておくことが重要です。数年前に一度挫折した経験がある人（ペルソナA）にとっては、まさにこの「同じエラーが直らず心が折れる」瞬間が過去の挫折の引き金だったケースが多く、ここを事前に知っておくこと自体が再挑戦の支えになります。まず持っておいてほしい前提が一つあります。それは、AIが同じ修正を繰り返し失敗するのは、あなたの理解力や指示の出し方が悪いからではなく、その時点でのAIの技術的な限界（文脈を保持できる範囲や、複雑に絡み合った不具合を切り分ける精度の限界）に突き当たっているケースが大半だということです。「またここで自分はつまずくのか」ではなく「これはAIの限界であって、自分の能力の問題ではない」と一度言葉にしてみるだけで、次の一手に進みやすくなります。

ただし、「AIの限界だから仕方ない」を何にでも当てはめてしまうと、本来直せたはずの指示の粒度の問題まで見過ごしてしまいます。両者を見分ける簡単な目安があります。同じ情報（エラーメッセージ、再現手順、期待する動作）を過不足なく3回以上伝えているのに改善の兆しすら見えない場合は、AI側の限界である可能性が高いパターンです。一方で、AIに伝えるたびに違うエラーが出る、あるいは「直った」と言われても実際には別の箇所が壊れているという場合は、こちらの指示が毎回微妙に変わっている、あるいは1つの指示に複数の要求を詰め込みすぎている可能性があります。後者に心当たりがあれば、STEP2-1の「4点を1つの指示文にまとめる」型に一度立ち返り、指示を1機能・1不具合まで絞り直してから再度試すと、AIの限界なのか指示の粒度なのかの切り分けがしやすくなります。

やること：

1. 同じ修正指示を3回以上繰り返しても直らない場合は、いったん指示を止める。ここで一呼吸置き、「直せないのはAIの限界であって自分のせいではない」と一度自分に言い聞かせてから次に進むと、心が折れる前に次の手に移りやすい。ただし、毎回違うエラーが出ている場合や指示のたびに要求内容がぶれている場合は、AIの限界と決めつける前にSTEP2-1の型で指示を絞り直してみる
2. AIとの会話を最初からやり直す、または別のAIツールに同じ状況を説明してみる。ただし複数ツールを並行契約するのは費用も手間もかかるため、無理に新しいツールを契約する必要はない。多くのAIコーディングツールには無料枠や試用期間があるため、まずはそれで一度だけ試し、それでも解決しなければ最初に選んだツール1本に戻って「会話をやり直す」対処に集中する方が、ツール1つに絞るのがやっとの段階では現実的
3. それでも直らない場合は、直前に動いていた状態まで戻すことを検討する。「ゼロからやり直し」ではなく「動いていた地点まで戻るだけ」と捉え直すと、失った時間ではなく守れた進捗に意識を向けられる

詳しくは → AIがバグを直せなくなったとき、次にどうすればいいか

完了の目安： AIが同じ問題を繰り返し直せないとき、次に何をすべきかの手順を自分の中に持てていること。

STEP3：予算感を掴む

STEP3-1：自己資金300万円で何ができるかを知る

「300万円あれば何でも作れる」と考えるのも、「300万円ではAI試作の域を出ない」と考えるのも、どちらも実態からずれています。MVP（実用最小限の製品）として何を目指すかによって、300万円という金額の意味は大きく変わります。まずは金額の輪郭を掴むことが、以降のすべての判断の土台になります。

なお、ここで示す300万円の内訳（開発・運用・集客）のうち、運用費にあたる部分は、STEP7で扱う「見落としがちな費用（外部API利用料・公開後の隠れコストなど）」のための予備費と、実質的には同じ枠を指しています。STEP7冒頭で改めて示す「1〜2割を予備費に」という目安は、ここでの配分の外側に別枠で用意する追加のお金ではなく、ここでいう運用費の内訳をもう少し細かく分解したものだと理解してください。

やること：

1. 300万円のうち、開発・運用・集客にどれくらいずつ配分できそうかを大まかに把握する。店舗DXツールを例にすると、規模感の目安は大きく変わる。例えば「予約管理ツールを自店ともう数店舗程度に配る」規模であれば開発150万円前後・月々の運用費1万円程度でも収まることが多く、「複数拠点の在庫・顧客データを一元管理する」規模まで広げるなら開発だけで200万円を超えることもある。個人向けWebサービス（会員登録・マッチング機能を持つもの）を例にすると、3段階に分けて考えると自分の該当箇所がつかみやすい。第1段階の「利用者登録とマッチング機能だけのシンプルな構成」（プロフィール登録・条件検索・一致度表示のみで、決済もメッセージ機能もなし）であれば開発120万〜150万円程度が目安。第2段階の「マッチングに加えて利用者間メッセージ機能を追加した構成」であれば180万〜220万円程度に上がる。第3段階の「メッセージに加えて決済機能（月額課金またはマッチング成立時の手数料課金）まで含む構成」であれば220万〜280万円程度まで膨らむのが目安になる。自分が数年前に構想したことがあるサービスや、頭の中で漠然と描いている機能一覧をこの3段階のどれかに当てはめてみると、レンジの絞り込みがしやすい。士業・医療職の専門知識ツールであれば、診断・シミュレーション機能を中心にした単機能構成で150万〜200万円程度が目安になりやすい。このように、まず自分の規模がどのレンジに近いかを大まかに当てはめてみる
2. 自分のサービス規模に近い事例で、実現できている機能の範囲を確認する
3. 「フルスクラッチで全部作る」以外の選択肢（一部ノーコード併用など）も視野に入れる

詳しくは → 予算300万円で、現実的にどこまでの機能が作れるか

完了の目安： 300万円という金額で、自分のサービスがどのレベルまで到達できそうか大まかなイメージが持てていること。

300万円という予算の中でどこまでが「試作」として作れるかが見えてきたら、次に気になるのはその先です。試作を実際に人に使ってもらえる本番システムへ仕上げる段階では、確認すべき論点がまとまって存在します。試作を本番システムに仕上げる前のチェックポイントに、事業部でPoCを本番化する際に確認すべき10のポイントが整理されています。

STEP3-2：削れない機能と後回しにできる機能を仕分ける

予算の制約がある中で全部の機能を一度に実現しようとすると、必ずどこかで予算が尽きます。自分のサービスの核となる価値（コアバリュー）と、あったら嬉しいが今は無くても成立する機能を切り分ける視点が必要です。

やること：

1. サービスの利用シーンを1つのストーリーとして書き出す
2. そのストーリーが成立するために絶対に必要な機能だけを残す
3. 残りは「あると便利だが後回しでよい」リストに移す

詳しくは → 「削れない機能」と「後回しにできる機能」を仕分ける考え方

完了の目安： 自分のサービスの機能一覧が「削れない」と「後回し」の2つに仕分けられていること。

STEP3-3：機能を削る優先順位を決める

仕分けが終わっても、「削れない」に分類した機能だけで予算を超えることはよくあります。そうなったときに何を基準に優先順位をつけるかを、あらかじめ持っておく必要があります。

やること：

1. 「削れない」機能リストの中に、さらに優先度をつける
2. 収益に直結する機能と、体験を整えるだけの機能を区別する
3. 一番優先度が低い機能から、次のリリースに回せないか検討する

詳しくは → 予算300万円で何を作るか。機能を削る優先順位のつけ方

完了の目安： 予算内に収まるところまで、機能の優先順位付けと削減ができていること。

STEP3-4：想定読者数を専門ネットワーク／地域のつながりから逆算する

自分の周囲に既にある人間関係を使って、利用者数を逆算することは、一般的な市場調査よりもはるかに現実的な数字を導きます。これはどのペルソナにも共通して使える考え方ですが、逆算の元になる「ネットワーク」の中身は立場によって変わります。

士業や医療職からのスピンオフ（ペルソナB）の強みは、業界内に既にネットワークを持っていることです。ただし、この強みを楽観的に見積もりすぎるのは禁物です。士業・医療職の業界には「守秘義務」や「同業への営業活動への忌避感」があり、人脈がそのまま見込み客に変換できるとは限りません。同業に直接「使ってください」と売り込むのは、専門職としての立場上むしろやりにくいことが多いはずです。その場合は、同業への直接営業ではなく、患者会や士業の勉強会コミュニティ、業界団体の研修会といった間接的な接点から、利用してくれそうな人数を逆算する迂回路を考えると現実的です。

店舗経営者（ペルソナC）の場合は、専門職とは違う形のネットワークがすでに手元にあります。商店会や同業者のLINEグループ、フランチャイズ本部経由のつながり、取引先の卸業者を介した同業者との接点などが、専門ネットワークに近い役割を果たします。士業のような守秘義務による制約が薄い分、こうした横のつながりを起点にした逆算がしやすいのが店舗経営者側の特徴です。例えば商店会に加盟する店舗が20店舗あり、そのうち「予約管理で困っている」と雑談で聞いたことがある店が5店舗あるなら、初期の見込み利用者数は保守的に2〜3店舗程度から逆算する、というように、身近な数から積み上げていくのが現実的です。

一方で、ゼロから集客する会社員（ペルソナA）のように、業界内の人脈をまだ持っていない場合は、逆算の起点を「専門ネットワーク」ではなく「身近な生活圏・SNSのフォロワー・過去の職場のつながり」といった、今すでに手元にある小さな輪に置き換えて考えます。人脈がゼロだと感じても、家族・友人・元同僚・SNSの知人といった「頼めば試してくれる人」は誰にでも数人はいるはずで、そこから保守的に見積もる姿勢は専門職の逆算法と変わりません。

やること：

1. 自分が直接連絡を取れる同業者・関係者の数を数える（専門ネットワークが薄い、あるいは同業への直接営業がしにくい場合は、患者会・勉強会コミュニティ、商店会・同業者のLINEグループ、あるいは家族・友人・SNSでつながっている人など「頼めば話を聞いてくれる人」の数に読み替える）
2. その中で実際に使ってもらえそうな割合を保守的に見積もる
3. その数字を元に、初期の想定利用者数のレンジを作る

詳しくは → 想定読者数・利用頻度を、自分の専門分野の人脈から逆算する方法

完了の目安： 自分の専門ネットワークを根拠にした、初期利用者数の見積もりができていること。

STEP3-5：自己資金が何ヶ月分持つか計算する

300万円という金額そのものより重要なのは、「その資金が何ヶ月分の活動を支えられるか」という時間軸の感覚です。この資金がどれだけ持つか（ランウェイ（資金が持つ期間））を把握していないと、開発の途中で資金が尽きるリスクに気づけません。

やること：

1. 開発費・運用費・生活費を分けて、月あたりの支出を試算する
2. 300万円をその月次支出で割り、何ヶ月分に相当するかを出す
3. 想定より短い場合は、STEP3-3の機能削減に戻って調整する

詳しくは → 自己資金300万円が何ヶ月分の開発・運用に持つか計算する方法

完了の目安： 自己資金が何ヶ月分の活動に相当するか、具体的な数字で把握できていること。

STEP4：本番に近づける・安全を確保する

STEP4-1：個人情報の扱いに注意する

会員登録や予約情報など、ユーザーの個人情報を扱う機能を試作に組み込む段階になったら、最低限の注意点を押さえておく必要があります。特に医療職や士業のスピンオフ（ペルソナB）では、扱う情報の性質上、守秘義務や業法上の配慮が求められる場面があり、「確認が必要」という認識を持っておくことが重要です。専門分野ごとに、まず何を疑えばいいかの手がかりだけでも把握しておきましょう。例えば税理士であれば税理士法上の守秘義務と顧客の税務情報の取り扱い、社会保険労務士であればマイナンバー（個人番号）を含む情報を扱う際の個人番号関係事務の規制、医師や看護師であれば医師法・保健師助産師看護師法に基づく守秘義務に加えて、病歴のような要配慮個人情報を扱う場合は個人情報保護法上の取得規制が絡んできます。どの領域に該当しそうかの見当がついたら、そこから先は必ず自分の専門分野の顧問弁護士や所属団体の相談窓口といった一次情報にあたり、このガイドの記述だけで判断しないことが重要です（詳細な法的判断は専門家への確認が前提になります）。

やること：

1. 試作で集めようとしている個人情報の項目を洗い出す
2. 自分の業種・専門分野に固有の守秘義務や規制がないか確認する（税理士法・社会保険労務士法・医師法・保健師助産師看護師法など、自分の資格に対応する法律名を起点に調べる)
3. 最低限のプライバシーポリシーの整備を検討する

詳しくは → 個人開発でユーザーの個人情報を扱うとき、最低限気をつけること

完了の目安： 自分のサービスが扱う個人情報の種類と、注意すべき点を把握できていること。

STEP4-2：AI生成コードのセキュリティリスクを確認する

AIが書いたコードは動いているように見えても、セキュリティ上の抜け穴が含まれていることがあります。試作の段階では見過ごされがちですが、実際に一般公開する前には最低限の確認をしておく必要があります。

やること：

1. 認証やパスワードの取り扱いなど、特にリスクの高い部分をリストアップする
2. AIに「このコードのセキュリティ上の懸念点は何か」を明示的に質問する
3. 不安が残る場合は、公開前に第三者のチェックを検討する

詳しくは → AIが生成したコード、そのまま公開して大丈夫か

完了の目安： 自分の試作におけるセキュリティ上の懸念点を、最低限洗い出せていること。

STEP4-3：試作を本番品質に引き上げる

動くことと、人に使ってもらえる品質であることの間には差があります。試作を実際にリリースできる水準まで引き上げるために、どんな視点で見直せばいいのかを知っておく必要があります。

やること：

1. 想定外の入力をしたときにエラーで壊れないか確認する
2. 表示速度や操作性など、体験面の粗さを洗い出す
3. 本番品質に必要な視点を3つの軸で整理して見直す

詳しくは → バイブコーディングの試作を、本番品質に引き上げる3つの視点

完了の目安： 試作を本番品質に近づけるための課題リストが作れていること。

STEP4-4：自分専用ツールが他人に使われ始めたときの壁を知る

このSTEPは、店舗・地域事業者（ペルソナC）や士業・医療職からのスピンオフ（ペルソナB）が展開の声をかけられたときの話として書いていますが、副業でリベンジに挑む会社員（ペルソナA）が個人向けSaaSを作っている場合も無縁ではありません。友人が経営する会社から「うちの部署でも使いたい」と言われたり、マッチングサービスを気に入った利用者から「知り合いのコミュニティにも入れたい」と頼まれたりするケースは実際にあります。1人・1社の想定で作ったツールが、複数の主体で使われ始めた瞬間に壁にぶつかるという構図は、ペルソナを問わず共通するため、該当しそうな人は読み進めてください。

店舗や地域事業者（ペルソナC）が自分の業務改善のために作ったツールは、評判が広がると近隣店舗や取引先から「うちでも使わせてほしい」と声がかかることがあります。1人で使う分には問題なかった作りが、複数の店舗・事業者で使われ始めた途端に壁にぶつかるのはよくあるパターンです。具体的には、予約管理ツールであれば「A店の予約とB店の予約が同じ画面に混ざって表示されないか」、顧客リストであれば「A店の顧客情報がB店の管理画面から見えてしまわないか」といった、データが店舗をまたいで漏れる問題が典型的です。これを放置したまま展開してしまうと、例えば「A店の常連客の来店履歴が、B店のオーナーの管理画面から見えてしまい、常連客本人からクレームになる」といった具体的なトラブルに直結します。信用を一度失うと、口コミで広がった評判が同じ速さで逆流しかねません。これを防ぐには、店舗ごと・事業者ごとにログインアカウントを分け、それぞれが自分のデータしか見えない仕組み（マルチテナント化と呼ばれる設計です）が必要になります。

同じ論点は士業や医療職からのスピンオフ（ペルソナB）にも当てはまります。同業の他事務所や他クリニックから「うちでも導入したい」と声がかかるケースは珍しくなく、むしろ専門職の方が顧客データの機密分離要件がより厳格に問われる場面です。顧客情報や患者情報がテナントを越えて見える設計のまま展開してしまうと、守秘義務違反に直結しかねません。展開の声がかかったタイミングで、慌てず現在の作りを点検できるようにしておきましょう。点検の粒度としては、最低限「行ごとのアクセス制御（Row Level Security）が有効になっており、他テナントの行がそもそもデータベースのクエリに乗らない構造になっているか」「バックアップやエラーログの出力先に、他テナントの個人情報が混在して書き出されていないか」の2点を確認しておくと、テナント分離の抜け漏れにかなりの確度で気づけます。

ただし、士業・医療職の機密分離はこの2点の技術的なアクセス制御だけでは終わりません。もう一段踏み込むべき論点として、「委託先管理」があります。税理士法や個人情報保護法では、業務の一部を外部（この場合はAIコーディングツールやホスティング事業者）に委託する際、委託先が個人情報を適切に扱っているかを監督する義務が委託元（つまりあなた）に課されます。具体的には、自分が使っているAIコーディングツールやクラウドの提供事業者が、入力したデータをAIの学習に再利用する設計になっていないか、データの保存場所（国内か海外か）がどこかを、各サービスの利用規約やプライバシーポリシーで確認しておく必要があります。学習利用がデフォルトで有効になっているツールも存在するため、専門職向けの機密情報を扱う場合は、学習利用をオプトアウトできる設定があるかどうかも合わせて確認しておくと安心です。

やること：

1. 今のツールが「自分専用」の作りになっている箇所を洗い出す
2. 他の店舗・事業者のデータが混ざらない仕組みが必要かを検討する（テナントごとにログインを分ける、店舗IDや事業者IDで表示データを絞り込むなど、具体的な分離方法を1つ想定してみる。最低限のチェックとして、行レベルのアクセス制御が効いているか、バックアップやログに他テナントの情報が混在していないかの2点を確認する。士業・医療職であれば、これに加えてAIコーディングツール・ホスティング事業者側のデータ学習利用の有無・データ保存場所も利用規約で確認する）
3. 展開の声がかかったときに、すぐに対応できる範囲かどうかを見極める

詳しくは → 自分だけで使っていたツールが、他の人にも使われ始めたときの壁

完了の目安： 自分のツールが複数店舗・複数事業者に展開される場合の壁を認識できていること。

STEP4-5：技術的負債を知っておく

早く動くものを作るために積み重ねた妥協は、後になって「技術的負債」（技術的負債）として重くのしかかってきます。すべてを完璧に作る必要はありませんが、どこに妥協を積んでいるかを自覚しておくことが、後の判断を楽にします。

やること：

1. 「とりあえず動けばいい」で済ませた箇所を書き留めておく
2. その妥協が後でどれくらいの手間になって返ってくるかを想像する
3. 見積もりを取る段階で、これらの妥協点も併せて伝える準備をする

詳しくは → 早く作るための妥協が、後で重荷になる「技術的負債」の正体

完了の目安： 自分の試作にどんな技術的負債が積み上がっているか、リストにできていること。

STEP5：自分で無理なときの見極め

STEP5-1：「もう無理」の判断ラインを知る

自分の力でどこまでやるべきか、どこから外部に頼るべきかの判断は、多くの人が最も迷うポイントです。感覚だけで「もう限界」と判断すると、実際にはもう少し進められたはずの局面で諦めてしまったり、逆に無理を重ねて消耗してしまったりします。一般的には「時間」「技術的な壁」「精神的な消耗」の3つの軸で判断しますが、士業や医療職からのスピンオフ（ペルソナB）には、もう1つ別の軸が加わります。それは「専門知識の引き継ぎコスト」です。発注先に自分の専門ロジック（税務計算のルール、診療報酬の算定ロジックなど)を正確に伝えられなければ、外注してもかえって手戻りが増えます。この引き継ぎに要する説明の手間そのものが、時間・技術・精神消耗のどれとも違う、専門職特有の4本目の壁になります。

この4本目の軸は、STEP2-3で行った検算作業とそのまま地続きです。検算のときに洗い出した「典型値・境界値・例外値」のリストは、実はそのまま発注先への引き継ぎ資料の骨格になります。検算作業をきちんとやっていた人ほど、発注段階での説明がスムーズになる、という関係を覚えておくと、STEP2-3の作業がここでも生きてきます。なお、この引き継ぎコストの軸は、STEP6の見積もり比較でも姿を変えて再登場します。同じ機能に見える見積もりでも、専門ロジックの引き継ぎに要する打ち合わせ回数やヒアリング工数が金額差の一因になっていることが多いため、STEP6-1・STEP6-3で見積もりの差を読み解く際は、この4本目の軸を判断材料の1つとして持っておいてください。

やること：

1. 「時間」「技術的な壁」「精神的な消耗」の3つの軸で、今の自分の状態を確認する。専門職(ペルソナB)の場合は、これに加えて「自分の専門ロジックを発注先にどれだけ正確に引き継げそうか」という4つ目の軸も確認する
2. 判断ラインの目安となる具体的な兆候を知っておく
3. 迷ったときに立ち返るための基準を1つ決めておく

詳しくは → 「もう自分では無理」と判断するタイミングの見極め方

完了の目安： 自分の状況が、外部に頼るべきラインに達しているかどうかを判断できる基準を持てていること。

STEP5-2：数年前に挫折した人は今のAIで再挑戦できるか確認（ペルソナA向け）

数年前に一度サービス作りに挑戦して挫折した経験がある人（ペルソナA）にとって、「今回もまた同じ壁にぶつかるのでは」という不安は大きなブレーキになります。しかしAIコーディングツールはこの数年で大きく進化しており、当時の挫折の原因の多くは今は解消されている可能性があります。

例えば数年前は、次のようなやり取りが典型的な挫折の引き金でした。「ログインボタンを押すとエラーになります」と伝えると、AIは「おそらく認証周りの設定が原因かもしれません、この箇所を直してみましょう」と一箇所を修正します。試すとエラーは変わらず、あるいは別の場所が新たに壊れます。もう一度「まだ直りません」と伝えると、AIは今度は別の箇所を「これが怪しいです」と修正します。これを3回、4回と繰り返すうちに、どこが本当の原因なのか、そもそも何を直したのかさえ分からなくなり、心が折れてやめてしまう。当時はこの「見当をつけては外れる」の繰り返しが典型的なパターンでした。

今のAIコーディングツールでは、同じ「ログインボタンを押すとエラーになります」という報告に対して、まずエラーメッセージの文言とスタックトレース（エラーが発生するまでの処理の経路）を求め、該当するコードの該当行を突き合わせたうえで、「認証トークンの有効期限チェックの条件式が逆になっています。この1行が原因です」のように、原因箇所を一度で特定して提示してくるケースが増えています。修正も「この1行を変更してください」という具体的な提案になり、見当違いの箇所を何度も触るという事態が起きにくくなっています。

もう一つの変化は、一度の指示で作業が途切れずに続く時間（長時間タスクの継続力)が伸びたことです。数年前は「ユーザー登録画面を作って」と頼んでも数分でAIの手が止まり、その都度「続けて」と指示を出し直す必要がありましたが、今は複数の画面にまたがる機能でも、まとまった指示のまま最後まで実装が進むケースが増えています。また、エラーメッセージをそのままAIに貼り付けるだけで意図が伝わる精度も上がっており、「エラー文の意味を自分で理解してから聞き直す」という当時の手間そのものが減っています。

なお、SWE-benchのような客観的なベンチマークスコアの推移を知りたい場合はSTEP5-3で扱いますが、ここでのポイントは数値そのものより、「当時つまずいた具体的な場面が、今はどう変わっているか」を自分の記憶と照らし合わせることです。

やること：

1. 数年前に挫折した具体的な原因を思い出して書き出す
2. その原因が今のAIツールでも同じように起こるか照らし合わせる
3. 再挑戦する場合は、当時とは違う進め方を1つ意識的に取り入れる

詳しくは → 数年前にAIで挫折した人へ。今のAIならどこまでやり直せるか

完了の目安： 数年前の挫折原因が、今の環境でも同じように壁になるかどうかを確認できていること。

STEP5-3：AIコーディングの進化を把握する

AIコーディングツールの性能は数年単位で大きく変わっています。自律的にコードを書き進める仕組み（AIエージェント）の実力を測る指標の一つであるSWE-bench（AIコーディング性能の評価基準）のスコアなど、客観的な進化の度合いを知っておくと、「今のAIでどこまでできるか」の期待値を適切に設定できます。

やること：

1. 自分が最後にAIコーディングを試した時期を思い出す
2. その時期と現在で、何がどう変わったのかを確認する
3. 過度な期待も過度な不安も持たず、現実的な期待値に調整する

詳しくは → AIコーディングツールの進化、数年前と比べて何が変わったか

完了の目安： 現在のAIコーディングツールの実力について、現実的な期待値を持てていること。

STEP5-4：学習ロードマップを確認する

自分でもう少し学びながら進めたいと考えたとき、どこから何を学べばいいのか分からないまま手を止めてしまう人は少なくありません。非エンジニアが現実的に歩める学習の順序を知っておくことで、次に何をすればいいかが明確になります。

やること：

1. 今の自分がどのレベルにいるかを確認する
2. 次に学ぶべき範囲を1つだけ選ぶ
3. 学習と試作を並行して進める計画を立てる

詳しくは → 非エンジニアがバイブコーディングを学ぶ、現実的な学習ロードマップ

完了の目安： 自分が次に学ぶべきことが1つに絞れていること。

STEP5-5：情報収集先を確保する

バイブコーディングを取り巻く状況は変化が速く、独学だけでは最新の使い方に追いつきにくい領域です。継続的に情報を得られる場所を確保しておくことが、長期的な独学の支えになります。

やること：

1. 信頼できる情報源の候補をいくつか確認する
2. 定期的に情報を確認する習慣を1つ決める
3. わからないことが出たときに質問できる場を確保する

詳しくは → バイブコーディングの情報収集、どこで最新の使い方を知るか

完了の目安： 継続的に情報を得られる場所を、少なくとも1つ確保できていること。

STEP6：見積もりを取る・費用の妥当性を確認する

このSTEPは大きく3つの問いに分かれます。「なぜ会社によって見積もりが違うのか」（STEP6-1〜6-3）、「金額以外に何で比較すべきか」（STEP6-4）、「誰に頼むべきか」（STEP6-5〜6-6）です。似た話が連続するように見えますが、それぞれ問いの立て方が異なるので、自分が今どの問いに答えようとしているのかを意識しながら読み進めると、情報が整理しやすくなります。

STEP6-1：見積もりが変わる理由を知る

同じような機能に見えても、開発会社によって見積金額が大きく異なることがあります。これは足元を見られているわけではなく、見積もりを左右する要素が複数あることを知らないまま比較すると、判断を誤りやすいというだけの話です。専門知識を扱うサービス（ペルソナB）の場合、この「複数の要素」の中に、STEP5-1で挙げた「専門ロジックの引き継ぎコスト」も含まれます。開発会社が業務ロジックを理解するためのヒアリング回数や資料化の工数は、画面数や機能数だけでは見えない金額差として表れます。

やること：

1. 見積もりに影響する要素（機能の複雑さ、納期、保守範囲など)を一覧で把握する
2. 自分の要望のどの部分が金額を押し上げているかを推測する
3. 見積もりを依頼する前に、自分の要望を整理しておく

詳しくは → 同じような機能でも見積もりが変わる理由。費用を左右する要素

完了の目安： 見積金額を左右する主な要素が何かを理解できていること。

STEP6-2：見積もりの相場の幅を読む

「MVP開発 費用」で検索すると、数十万円から数千万円まで、幅の広い金額が出てきます。この幅をそのまま鵜呑みにすると、自分のケースにどの数字が当てはまるのか分からず混乱します。店舗の業務改善ツールを例にすると、予約表アプリや顧客台帳のような単機能アプリはおおむね100万〜180万円程度のレンジに収まりやすく、在庫管理や複数拠点連携のように連携先が増えるほど、同じ「業務改善ツール」でも220万〜300万円程度までレンジは上に動きます。自分のツールが「単機能で完結するか」「複数の仕組みと連携するか」のどちらに近いかを、まず当てはめてみましょう。

やること：

1. 検索して出てきた金額の幅を、機能規模別に分類してみる
2. 自分のサービスの規模がどの分類に近いかを当てはめる（予約表・顧客台帳のような単機能アプリは100万〜180万円程度、在庫連携や複数拠点対応が絡む場合は220万〜300万円程度に位置しやすい、という当てはめ方が目安になる）
3. 極端に安い・高い事例には、その理由が何かを推測する

詳しくは → 「MVP開発 費用」で検索して出てくる金額の幅、どう読むべきか

完了の目安： 検索結果の金額幅の中で、自分のケースがどのあたりに位置するかの見当がついていること。

STEP6-3：同じ要望なのに見積もりが違う理由

複数の開発会社に同じ内容を伝えたつもりでも、返ってくる見積もりが大きく異なることがあります。これは要望の伝え方や、開発会社側の解釈の幅によって起こる、よくある現象です。専門知識を伴うサービスの場合、この解釈の幅は特に大きくなりがちです。ある開発会社は業務ロジックの複雑さを軽く見積もってヒアリングを1回で済ませ、別の開発会社は入念に複数回のヒアリングを重ねて金額に反映する、というように、STEP5-1・STEP6-1で触れた「専門ロジックの引き継ぎコスト」の見積もり方そのものが会社によって割れることが、金額差の一因になっているケースがあります。

やること：

1. 自分が各社に伝えた要望の内容を見比べる
2. 金額差が「解釈の違い」によるものか「対応範囲の違い」によるものかを確認する
3. 疑問点は遠慮せず各社に問い合わせて確認する

詳しくは → 同じ要望を伝えたのに見積もりが大きく違う理由

完了の目安： 見積もりの差が生まれた理由について、自分なりの説明ができていること。

STEP6-4：複数見積もりを比較する視点

金額だけを見て発注先を決めると、後々のコミュニケーションや品質面で後悔することがあります。価格以外にどんな視点で比較すべきかを知っておくことが重要です。

やること：

1. 各社の見積もりを、金額以外の項目（実績、コミュニケーションのしやすさ、保守体制など）でも比較する
2. 気になった点は事前の打ち合わせで直接質問する
3. 比較表を作って一覧で判断できるようにする

詳しくは → 個人が複数の見積もりを比較するとき、価格以外に見るべきポイント

完了の目安： 価格以外の観点も含めた比較ができる状態になっていること。

STEP6-5：フリーランスと開発会社の価格差

同じ内容を依頼しても、フリーランスに頼む場合と開発会社に頼む場合とで金額に差が生まれます。この差がなぜ生まれるのかを知っておくと、自分の予算感に合った依頼先を選びやすくなります。契約形態によってはSES（システムエンジニアリングサービス）のような仕組みが関わることもあるため、契約の性質も含めて理解しておくと安心です。

やること：

1. フリーランスと開発会社、それぞれの費用構造の違いを確認する
2. 自分の予算とプロジェクトの規模感に合っているのはどちらかを検討する
3. どちらを選ぶ場合も、契約内容の確認ポイントを把握しておく

詳しくは → フリーランスと開発会社、費用の違いが生まれる理由

完了の目安： フリーランスと開発会社、どちらに依頼する可能性が高いか自分の中で方向性が持てていること。

STEP6-6：個人開発者への発注も検討する

開発会社だけでなく、個人で開発を請け負う人への発注も選択肢の一つです。選択肢を広げることで、予算に合った依頼先が見つかる可能性が高まります。

やること：

1. 個人開発者への発注のメリットとリスクを確認する
2. 個人開発者から受け取った見積もりの読み方を確認する
3. 開発会社の見積もりと横並びで比較できるようにする

詳しくは → 開発会社だけでなく個人開発者への発注も検討する場合の見積もり比較

完了の目安： 開発会社と個人開発者、両方の選択肢を比較できる状態になっていること。

STEP7：見落としがちな費用を確認する

このSTEPでは、見積書の金額だけでは見えない「公開後にかかるお金」を扱います。外部APIの利用料、月々の運用費、公開後にしか分からない隠れコスト、予備費——これらは性質が異なるようで、実は「開発費とは別に、継続的または突発的に発生する支出」という1つの塊として捉えると理解しやすくなります。結論から言えば、300万円の予算のうち1〜2割程度をこの塊のための余力として確保しておくと、想定外の出費で資金繰りが詰まる事態を避けやすくなります。この1〜2割という幅には根拠があります。個人開発のMVPで実際に予算オーバーが起きやすい費目を挙げると、外部APIの従量課金（想定より利用者が集まったときの決済手数料やメール送信数の超過）、公開直後に見つかる仕様漏れの追加開発、そしてサーバー費用のスケールアップの3つが典型で、これらはそれぞれ数万円〜数十万円単位で予算をはみ出すことが多い費目です。300万円の1割は30万円、2割は60万円ですから、この3つの費目が重なって発生しても吸収できる水準として、1〜2割という幅を置いています。なお、この1〜2割は、STEP3-1で示した「開発・運用・集客」の配分のうち、運用費に割り当てた部分を指しています。STEP3-1で運用費として確保した金額の使いみちを、ここでもう一段具体的に分解していると考えてください。以下、それぞれの内訳を見ていきます。

STEP7-1：見積書に載らない費用項目

見積書に書かれている金額だけを予算計画に組み込むと、後から想定外の出費に気づいて慌てることになります。見積書には載りにくいものの、実際には発生しやすい費用項目を事前に知っておく必要があります。

やること：

1. 見積書の内訳を項目ごとに確認する
2. 一般的に見積書に含まれにくい費用項目のリストと照らし合わせる
3. 抜けている項目があれば、発注前に開発会社に確認する

詳しくは → 見積書に載っていない、後から発生しやすい費用の項目

完了の目安： 見積書に含まれていない費用項目が何かを把握できていること。

STEP7-2：外部APIの費用を見落とさない

決済機能や地図表示、メール送信など、外部の仕組み（API）を利用する機能には、開発費とは別に利用料がかかることがあります。この費用を見落として予算計画を立てると、公開後に想定外の支出が発生します。店舗系のツールであれば、決済や地図よりも「LINE公式アカウントAPIを使った予約通知」や「Googleカレンダー連携による予約表の自動反映」、「顧客への一斉配信機能」の方が現場感のある例として身近かもしれません。例えば来店予約が月100件、そのうち8割にLINE通知を送るとすると月80通程度になり、無料枠を超える配信数になった場合は従量課金が発生します。これらも決済・地図と同じく、利用件数や配信数に応じた従量課金が発生することが多いため、開発費とは別枠で確認しておく必要があります。

やること：

1. 自分のサービスに組み込む予定の外部機能を洗い出す（決済・地図・メール送信に加えて、店舗系ツールならLINE公式アカウントAPIやGoogleカレンダー連携なども対象に入れる）
2. それぞれの利用料金体系を確認する
3. 想定利用量に基づいた月額費用の目安を試算する

詳しくは → 決済・地図・メール送信など、外部APIにかかる費用を見落とさない

完了の目安： 利用予定の外部機能について、費用の目安を把握できていること。

STEP7-3：公開後の運用費を知っておく

サービスは公開した瞬間がゴールではなく、そこから運用費がかかり続けます。サーバーやデータの保存場所（クラウドホスティング）などの費用は、規模が小さいうちは少額でも、利用者が増えると変動します。

やること：

1. 月額運用費の内訳項目を確認する
2. 自分のサービス規模での概算費用を出す
3. 300万円の予算のうち、運用費に充てる分を確保しておく

詳しくは → 個人開発サービスの月額運用費、内訳の目安

完了の目安： 公開後の月額運用費について、大まかな金額イメージが持てていること。

STEP7-4：公開後に判明する隠れコスト

実際にサービスを公開してみないと分からない費用も存在します。事前にどんな種類の隠れコストがあり得るかを知っておくことで、公開後の資金繰りに余裕を持たせることができます。

やること：

1. 公開後に発生しやすい隠れコストのパターンを確認する
2. 自分のサービスに当てはまりそうなものをチェックする
3. 予算の一部を「予備費」として確保しておく

詳しくは → MVP公開後にかかる「見えていなかった費用」の正体

完了の目安： 公開後に発生しうる隠れコストに対して、予備費を確保できていること。

STEP7-5：開発と集客、予算配分の考え方

300万円をすべて開発に使い切ってしまうと、サービスが完成しても誰にも知られないまま終わってしまいます。開発と集客、それぞれにどれくらいの予算を配分すべきかを考えておく必要があります。

やること：

1. 開発費と集客費の配分バランスの考え方を確認する
2. 自分のサービスの性質（口コミで広がりやすいか、広告が必要かなど）を踏まえて配分を検討する
3. 配分案を数字で書き出しておく

詳しくは → 予算を開発と集客、どちらにどれくらい配分すべきか

完了の目安： 開発費と集客費のおおまかな配分比率が決まっていること。

STEP7-6：予算を追加投入すべきタイミング

サービスを進める中で、予算を追加投入すべき局面と、そうでない局面があります。判断を誤ると、伸びる見込みのないものに資金をつぎ込んでしまったり、逆に伸びるはずだった芽を予算不足で摘んでしまったりします。

やること：

1. 追加投入すべきタイミングの見極め方を確認する
2. 追加投入を見送るべきタイミングの見極め方も併せて確認する
3. 自分が今どちらの局面に近いかを定期的に確認する習慣を持つ

詳しくは → 予算を追加投入すべきタイミングと、しないほうがいいタイミング

完了の目安： 予算追加の判断基準を、自分の言葉で説明できる状態になっていること。

STEP7-7：専門知識ツールの価格設定（ペルソナB向け）

士業や医療職のスピンオフ（ペルソナB）が専門知識を活かしたツールを作る場合、価格設定は一般的な消費者向けサービスとは異なる考え方が必要です。無料の範囲と有料の範囲を分ける仕組み（フリーミアム）を採用するかどうかも含めて、専門性の価値をどう価格に反映するかを検討する必要があります。ここで見落としやすいのが、士業と医療職では収益構造そのものが異なるという点です。既に顧問契約を持っている士業であれば、ツールを顧問先への付加価値として無償に近い形で提供し、顧問料の維持・単価向上につなげるという設計が成立しやすくなります。一方、医療職は診療報酬という別会計の枠組みに縛られており、ツール単体で直接課金する設計にせざるを得ない場面が多く、混合診療規制などの制約にも注意が必要です。「専門知識」と一括りにする前に、自分がどちらの収益構造に近いかを踏まえて価格を考える必要があります。

freemiumの無料枠設計は、士業・医療職にとって特に慎重さが求められます。一般的な消費者向けサービスであれば「無料枠を広げて利用者を増やし、一部を有料転換する」という設計が定石ですが、専門知識ツールの場合、無料枠を広げすぎると自分の専門知識そのものをタダで公開することになり、本業の顧問契約や診療報酬の価値を自分で毀損してしまうリスクがあります。例えば税理士が「簡易税額シミュレーター」を無料で公開する場合、ごく基本的なケース（単純な給与所得のみ）だけを無料範囲にとどめ、控除が複数重なる複雑なケースや、申告書作成につながる踏み込んだ計算は有料範囲に置く、という線引きが目安になります。無料範囲に「自分が本来報酬をもらっている業務判断そのもの」が入り込んでいないかを、価格設計の段階で一度点検しておくとよいでしょう。

やること：

1. 自分の専門知識が、利用者にとってどれだけの価値を持つかを整理する
2. 同業他社・類似サービスの価格帯を確認する
3. 無料範囲と有料範囲の線引きを検討する。顧問契約が既にある士業であれば「顧問先向けの付加価値」として位置づけられないか、診療報酬という別会計に縛られる医療職であれば「単体課金にせざるを得ないか」を、それぞれの収益構造に照らして検討する。あわせて、無料範囲に「本来報酬をもらっている業務判断」そのものが入り込んでいないかも点検する

詳しくは → 専門知識を活かしたツール、価格設定はどう考えればいいか

完了の目安： 自分のサービスの価格設定について、方向性の仮説が持てていること。

STEP7-8：使える補助金・支援制度

自己資金300万円に加えて、使える補助金や支援制度がないかを確認しておくことは、資金繰りの余裕を生みます。ただし全ての人・全てのサービスに当てはまるわけではないため、自分の状況に合った制度があるかを確認する姿勢が大切です。代表的な候補としては、ものづくり補助金、IT導入補助金、小規模事業者持続化補助金などが挙げられますが、制度は年度ごとに要件や公募スケジュールが変わるため、名前を手がかりに必ず最新の公募要領を確認してください。

店舗経営者（ペルソナC）の場合、個人事業主・小規模法人であれば小規模事業者持続化補助金の販路開拓枠がIT投資（予約システムや顧客管理ツールの開発）の対象になるケースがあり、まずはここから該当性を確認するのが現実的です。もう一つ確認しておきたいのがIT導入補助金です。こちらは「ITツールを導入して業務効率化・売上向上を図る」という主旨に沿うため、自作の予約管理ツールや顧客管理ツールであっても、登録済みのIT導入支援事業者を通す・対象ツールとして登録するといった要件を満たせば対象になり得ます。小規模事業者持続化補助金が主に販路開拓（集客・広告）寄りの用途に強いのに対し、IT導入補助金は業務システムそのものの導入費用に寄っているため、開発費用の性質によってどちらが合っているかを見比べておくとよいでしょう。いずれの制度も、公募回・申請枠によって補助率や上限額、対象経費の範囲が年度内でも変わることがあるため、店舗経営者は「小規模事業者持続化補助金」「IT導入補助金」の2つの名称を起点に、直近の公募要領を確認してください。

士業や医療職からのスピンオフ（ペルソナB）の場合は、本業側の兼業規定や利益相反規定によって、そもそも申請自体が制限されるケースもあります。兼業規定は資格や勤務形態によって根拠となる規定が異なります。勤務医の場合、まず確認すべきは勤務先の就業規則にある兼業禁止・許可制の条項です。多くの勤務医は雇用契約に基づいて病院に所属しているため、副業としてのサービス運営が就業規則上の兼業許可の対象になるかどうかが最初の関門になります。そのうえで、自分がクリニックの開設者・管理者を兼ねる立場であれば、医療法上の管理者兼務の規定も追加で確認が必要になります。つまり、雇用されている一般の勤務医であれば就業規則の兼業条項が先、開業医・管理者であれば医療法上の兼務規定が先、という順序で確認するのが実態に近い進め方です。税理士であれば税理士法上の使用人兼務に関する届出の要否が確認のとっかかりになります。補助金の対象条件だけでなく、自分の所属団体・勤務先の規程に抵触しないかも合わせて確認しておく必要があります。

やること：

1. 個人のサービス立ち上げで使える可能性のある補助金・支援制度の種類を確認する（ものづくり補助金、IT導入補助金、小規模事業者持続化補助金などが代表的な候補になる。店舗経営者は小規模事業者持続化補助金の販路開拓枠、またはIT導入補助金の対象になりやすいため、この2つを優先的に確認する）
2. 自分の状況（開業形態、事業内容など）が対象条件に当てはまるか確認する。士業・医療職の場合は、本業の兼業規定・利益相反規定に抵触しないかも併せて確認する（勤務医はまず就業規則の兼業許可の要否を確認し、自分がクリニックの開設者・管理者を兼ねる場合はさらに医療法上の兼業届も確認する。士業なら所属会への兼業届出の要否を確認する）
3. 申請にかかる手間と得られる金額を天秤にかけて判断する

詳しくは → 個人のサービス立ち上げで使える補助金・支援制度はあるか

完了の目安： 自分が使える可能性のある補助金・支援制度の有無を確認できていること。

STEP8：交渉する

STEP8-1：機能を削る交渉の進め方

見積もりが予算をオーバーしたとき、多くの人がそのまま諦めるか、無理をして予算を超えて発注してしまいます。しかし実際には、開発会社との打ち合わせの中で機能を削る交渉をすることで、予算内に収める余地が残っていることがほとんどです。作業範囲を明確にした書面（SOW（作業範囲記述書））に落とし込みながら交渉を進めることで、認識のズレも防げます。例えば店舗経営者が予約管理ツールの見積もりで150万円を提示されたケースを考えると、「複数拠点の在庫連携機能」を次フェーズに回すだけで120万円程度まで下がる、といった具体的な削減交渉が典型です。金額と機能の対応関係を具体的に示しながら交渉すると、開発会社側も削減幅を提示しやすくなります。

やること：

1. STEP3で仕分けた「後回しにできる機能」のリストを打ち合わせに持参する
2. どの機能を削れば、どれくらい金額が下がるかを開発会社に確認する（例えば「複数拠点連携機能を外すと30万円下がる」のように、機能と金額をセットで確認すると、次にどれを削るべきか判断しやすい）
3. 削った機能を含む合意内容を、作業範囲の書面に反映してもらう

詳しくは → 開発会社との打ち合わせで、機能を削る交渉をどう進めるか

完了の目安： 予算内に収まる形で、開発会社との合意ができていること。

検証期の完了条件

印刷して使える形式のチェックリストとして、AI試作の本番化チェックリストとMVP予算チェックリストも用意しています。

• 自分のサービスの核となる機能を、AIと一緒に試作として動かせている
• 試作を通じて「これはいける」という手応え、または「自分では無理」という根拠のある判断のどちらかを得ている
• 自己資金300万円が何ヶ月分の活動に相当するか、具体的な数字で把握できている
• 削れない機能と後回しにできる機能の仕分けができている
• 外部に発注する場合、見積もりの妥当性を自分で判断できる状態になっている
• 見積書に載らない費用（外部API費用、運用費、隠れコストなど)を含めた資金計画を持てている
• 機能を削る交渉を、開発会社と自分の言葉で進められる状態になっている

次のステップへ

試作を動かしてみて「これはいける」という手応えを得た人、あるいは自分の力だけでは進められないという判断に至った人は、次は本格的な開発体制を整える段階に進みます。次の「開発期」ガイドでは、内製を続けるか外注に切り替えるかの判断、開発会社への発注準備、契約の結び方、そして法務やお金まわりの整備を、検証期で得た手応えと予算感を土台にしながら手順化していきます。