個人開発でもMVP仕様書は必要ですか?

実装が速くなったからこそ必要です。仕様書の目的は文書を作ることではなく、決めていない部分を無くすことにあります。決まっていない部分はAIが推測で埋め、その推測は毎回変わるため、会話を重ねるほど全体の筋が通らなくなります。1人で作る場合でも、未来の自分に対する申し送りとして機能します。

MVP仕様書には何を書けばいいですか?

サービス概要、MUST/SHOULD/WON'Tのスコープ、削る機能とその理由、画面一覧と遷移、データモデル、主要APIエンドポイント、技術スタック、外部サービスの想定コスト、1〜2時間粒度の実装ステップの9項目です。各項目は「これを書かないと起きる失敗」に対応しています。

WON'T(今回は作らないもの)はどれくらい書くべきですか?

MUSTと同じ数が目安です。種火のAI MVP仕様書ジェネレーターが出力した実際の仕様書2本では、どちらもMUST 5個に対してWON'T 5個でした。作るものと作らないものを同じ密度で決めておくと、途中で機能が膨らみにくくなります。

どんな機能が削られやすいのですか?

実際の仕様書から削られた16機能を分類すると6つの型に収まりました。精度が要る機能(3件)、外部システム連携(3件)、別プラットフォーム・配布形態(3件)、リアルタイム・同時編集(2件)、権限とマルチテナント(2件)、対象を広げる機能(2件)、人手が要る機能(1件)です。いずれも実装量に対して初期のユーザー価値が小さい領域です。

削る理由まで書く必要はありますか?

あります。理由が書かれていない削除は、後から自分で蒸し返して実装してしまうためです。実データでも削除項目16件すべてに理由が併記されていました。「工数2倍になる」「初期ユーザーには不要」のように、判断のときの前提を残しておくと、前提が変わったときだけ再検討できます。

データモデルはあとから変えればいいのでは?

データモデルだけは先に固めてください。画面もAPIもすべてがここに依存するため、後から変えると全体に波及します。他の項目は作りながら調整できますが、データモデルの変更コストだけは桁が違います。

仕様書はどう渡せばいいですか?

全文を先に渡し、そのあと実装ステップ単位で区切って進めます。1ステップごとに動作を確認してから次に行くのが確実です。まとめて全部を頼むと、途中で仕様から逸れても気づけません。

仕様書を書くのが面倒です。自動化できますか?

できます。アイデアの概要を入力すると、上記9項目を埋めたMarkdown仕様書がAIによって自動生成されます。そのままClaude CodeやCursorに貼れる形式で、実装ステップはチェックボックス付きで出力されます。ただし出力された WON'T が自分の判断と合っているかだけは、必ず自分で確認してください。

Guide / AI時代の発案ガイド

MVP仕様書で決めるのは、作らないもの。

仕様書の目的は「書くこと」ではなく「決めること」。
AIが出力した仕様書から削られた16機能を分類したら、6つの型に収まった。

01 / 目的

仕様書の目的は「書くこと」ではなく「決めること」

個人開発で仕様書を書くと聞くと、「1人なのに書類仕事?」と感じるかもしれない。だが仕様書の価値は丁寧さではなく、決定の量にある。

「タスク管理ツールを作って」とだけ伝えると、決まっていない部分は推測で埋められる。タスクに期限はあるのか、担当者は付くのか、完了したものは消えるのか。どれも決めていないので、その場の自然な解釈で実装される。問題はその推測が毎回変わることだ。修正を頼むたびに前回とは違う前提で書かれ、機能は増えているのに全体の筋が通らないコードが積み上がる。

決定が渡されていない

要望 → AIが推測で補完
修正 → 別の推測で補完
修正 → また別の推測
前提がズレ続け、筋が通らなくなる

決定が渡されている

仕様書 → 推測の余地が小さい
修正 → 同じ前提の上で修正
修正 → 同じ前提のまま
全体の一貫性が保たれる

つまり仕様書は未来の自分とAIに対する申し送りだ。そして申し送りで一番効くのは、作るものより作らないもののほうである。

02 / 一次観測

削られた16機能を分類したら6つの型に収まった

種火の 📋 AI MVP仕様書ジェネレーターは、アイデアの概要から仕様書一式を書き下ろすツールだ。そこで実際に生成された仕様書から、「WON'T」と「削るべき機能と理由」に挙がった全16項目を取り出して分類してみた。

仕様書	MUST	SHOULD	WON'T
レシピ栄養計算ツール	5	4	5
営業支援ツール	5	4	5

まず目を引くのは WON'T が MUST と同数であること。ジャンルも規模も違う2本が、どちらも「作る5個・作らない5個」で揃っていた。作らないものを、作るものと同じ密度で決めるのが実務的な水準ということだ。

そして削除理由まで含めた16項目を分類すると、こうなった。

精度が要る機能 3 / 16

音声認識 / 自動最適化AI / 高度な自然言語処理

外部システム連携 3 / 16

他システムのDB統合 / メール送受信 / 外部APIでのデータ更新

別プラットフォーム・配布形態 3 / 16

ネイティブアプリ×2 / 専用インストーラー

リアルタイム・同時編集 2 / 16

複数人の同時編集 / リアルタイム通知

権限とマルチテナント 2 / 16

高度な権限・監査ログ / 複数組織管理

対象を広げる機能 2 / 16

多言語対応 / 高度なレポート

人手が要る機能 1 / 16

専門家による個別コンサル

共通するのは「実装量に対して初期のユーザー価値が小さい」こと

※ 分析対象は種火が公開している仕様書アーカイブの実データ(全文はこちら)。n は小さいが、削除理由まで含めて読めるので型の抽出には使える。

03 / 型

削られやすい機能の6つの型

自分の案でスコープを切るとき、この6つに当てはまるものから疑うと速い。

1. 精度が要る機能

音声認識・自動最適化・高度な文章解析。「80%の精度で足りるか」を問う。足りるなら正規表現や簡易ルールで代替し、残りは手動修正に回す。

削る根拠: 精度を上げる作業は青天井で、しかもユーザーは精度が上がったこと自体には気づかない

2. 外部システム連携

他サービスとのデータ統合、メール送受信、外部APIでの自動更新。実装より申請・認証・エラー処理に時間を取られる。

削る根拠: 連携先の仕様変更で壊れ続けるので、初期の保守コストが跳ね上がる

3. 別プラットフォーム・配布形態

ネイティブアプリ、専用インストーラー。Web / PWA / Docker で代替できないかを先に確認する。

削る根拠: 対応プラットフォームを1つ増やすと、実装だけでなく検証と保守も倍になる

4. リアルタイム・同時編集

複数人の同時編集、即時通知。定期ポーリングで足りないかを問う。

削る根拠: 動くところまでは速いが、競合状態と再接続の扱いはデバッグが重い

5. 権限とマルチテナント

細かい権限設計、監査ログ、複数組織対応。初期は「全員が信頼できる1チーム」を前提にする。

削る根拠: データ分離と課金ロジックが絡み、後から入れるより最初から入れないほうが安い

6. 対象を広げる機能

多言語対応、多機能なレポート画面。対象を広げる前に、1つの対象で成立させる。

削る根拠: 広げるほど、どのユーザーにとっても最短経路が長くなる

7つ目として「人手が要る機能」もあった(専門家による個別対応など)。件数は1件だが、個人開発では最も危ない型だ。自分の時間が上限になるので、ユーザーが増えるほど回らなくなる。

04 / WON'T

WON'T の書き方 — 理由なしの削除は必ず蒸し返される

実データで見て印象的だったのは、削除項目16件すべてに理由が併記されていたことだ。これは形式的な丁寧さではなく、実用上の必然だと思う。

WEAK
- モバイルアプリは作らない

STRONG
- モバイルアプリは作らない: Web版で十分動作し、開発工数が2倍以上になるため。PWA で対応

理由が無いと、2週間後の自分が「やっぱり要るのでは」と考え直して実装してしまう。
理由があれば、前提が変わったときだけ再検討できる。

書き方の型

実データの理由文はほぼ次の3パターンに収まっていた。どれかに当てはめて書けばいい。

コスト型 — 「工数が2倍以上になるため」「実装コスト > 初期需要」。数量で言えると強い
代替型 — 「Web版で十分」「Docker Compose で十分」「静的CSVで運用可能」。代替手段まで書くのがポイント
時期型 — 「拡大後」「後発」「多言語化時に段階的に」。捨てるのではなく順番の話だと明示する

目安は MUST と同数。 MUST が5個なら WON'T も5個書く。書き出しにくければ、上の6つの型を順に当てていけば埋まる。

05 / 構成

書くべき9項目と、それぞれが防ぐ失敗

項目は「あると丁寧だから」ではなく「これを書かないとこう失敗するから」で選ぶ。

項目	書かないと起きること
サービス概要	1段落で言えないまま進み、以降の判断がすべてブレる
MUST / SHOULD / WON'T	機能が際限なく膨らむ。WON'T が最重要
削る機能と理由	2週間後の自分が蒸し返して実装する
画面一覧と遷移	スコープ過大に気づけない(画面数は規模の代理指標)
データモデル	後から変えると全部に波及する。唯一「先に固める」項目
APIエンドポイント	画面とデータの辻褄が合っているかの検算ができない
技術スタック	使うホスティングで動かないコードが出てくる
想定コスト	月額が想定を超え、それだけの理由で畳むことになる
実装ステップ	まとめて実装され、仕様から逸れても気づけない

データモデルだけは扱いが違う。 他の項目は作りながら調整できるが、データモデルの変更は画面もAPIも巻き込むので、変更コストの桁が違う。ここだけは着手前に確定させる。

06 / 不要

書かなくていいもの

仕事の要件定義書にはあるが、個人開発のMVP仕様書には要らないものもある。書く時間がそのまま無駄になるので、最初から外していい。

詳細なユースケース記述 — 画面一覧と遷移があれば足りる。1人で作るなら関係者間の認識合わせが不要
非機能要件の網羅 — 可用性99.9%のような目標は、ユーザーがゼロの段階では意味を持たない。想定コストだけ書けばいい
詳細なテスト計画 — 実装ステップごとに動作確認する運用で足りる
スケジュール・工数見積もり — 1〜2時間粒度の実装ステップがそのまま見積もりになる
体制図・役割分担 — 1人なので不要

逆に言えば、仕様書に書く価値があるのは「後から変えるのが高くつく決定」だけだ。スコープとデータモデルがそれに当たる。

07 / 渡し方

仕様書の渡し方

全文を先に渡してから、実装ステップ単位で進める。「ステップ1だけやって」と区切り、動作を確認してから次に行く。まとめて全部を頼むと、途中で仕様から逸れても気づけない。

途中で仕様を変えたくなったら、会話で伝えるのではなく仕様書のほうを直す。会話で足した要件は次のセッションで消えるが、仕様書に書けば残る。

なお、この9項目を埋めた Markdown 仕様書は自動生成できる。実装ステップはチェックボックス付きで出るので、そのまま進捗管理に使える。ただし出力された WON'T が自分の判断と合っているかだけは、必ず自分で確認すること。スコープは最後まで人間の判断だ。

📋 AI MVP仕様書ジェネレーターで作る

続けて読む

Claude Codeで何を作る? — 発案から実装までの全体フロー。最初の1本の選び方と避けるべき初手
個人開発のWebサービスはなぜ失敗するのか — 15の失敗パターンの分類。例外処理をMVPに含める理由はこちら
作りたいものがない個人開発者へ — そもそも何を作るかが決まらない段階の解き方

FAQ / よくある質問

よくある質問

Q. 個人開発でもMVP仕様書は必要?: 実装が速くなったからこそ必要。目的は文書を作ることではなく、決めていない部分を無くすこと。決まっていない部分はAIが推測で埋め、その推測は毎回変わる。
Q. 何を書けばいい?: 概要 / MUST・SHOULD・WON'T / 削る機能と理由 / 画面一覧と遷移 / データモデル / APIエンドポイント / 技術スタック / 想定コスト / 実装ステップの9項目。
Q. WON'T はどれくらい書く?: MUSTと同じ数が目安。実データの仕様書2本はどちらも MUST 5 に対して WON'T 5 だった。
Q. どんな機能が削られやすい?: 精度が要る機能3 / 外部システム連携3 / 別プラットフォーム3 / リアルタイム2 / 権限・マルチテナント2 / 対象を広げる機能2 / 人手が要る機能1。共通点は実装量に対して初期のユーザー価値が小さいこと。
Q. 削る理由まで書く必要は?: ある。理由が無い削除は後から自分で蒸し返す。実データでも16件すべてに理由が併記されていた。コスト型 / 代替型 / 時期型のどれかで書く。
Q. データモデルはあとから変えれば?: これだけは先に固める。画面もAPIも依存するので変更が全体に波及し、変更コストの桁が違う。
Q. どう渡す?: 全文を先に渡し、実装ステップ単位で区切って進める。仕様変更は会話ではなく仕様書のほうを直す。
Q. 書くのが面倒。自動化できる?: できる。アイデア概要から9項目を埋めたMarkdownが生成される。ただし WON'T が自分の判断と合っているかは必ず自分で確認する。

SUMMARY

主題: 個人開発の Webサービスで MVP 仕様書に何を書き、何を書かないか。とくにスコープの切り方(WON'T の作り方)
仕様書の目的: 文書を作ることではなく決定の量を増やすこと。決まっていない部分は AI が推測で埋め、その推測は毎回変わるため、修正を重ねるほど全体の筋が通らなくなる
一次観測(2026-08-03時点): 種火の AI MVP仕様書ジェネレーターが生成した実際の仕様書 2 本から「WON'T」と「削るべき機能と理由」の全 16 項目を抽出して分類。① ジャンルも規模も違う 2 本がどちらも MUST 5 / SHOULD 4 / WON'T 5 で、WON'T が MUST と同数だった ② 削除項目 16 件すべてに理由が併記されていた
削られやすい機能の型(16件の内訳): 精度が要る機能 3(音声認識 / 自動最適化AI / 高度な自然言語処理) / 外部システム連携 3(他システムDB統合 / メール送受信 / 外部APIでのデータ更新) / 別プラットフォーム・配布形態 3(ネイティブアプリ×2 / 専用インストーラー) / リアルタイム・同時編集 2 / 権限とマルチテナント 2 / 対象を広げる機能 2(多言語 / 高度なレポート) / 人手が要る機能 1。共通点は実装量に対して初期のユーザー価値が小さいこと
WON'T の書き方: 目安は MUST と同数。理由はコスト型(工数が2倍になる)/ 代替型(Web版で十分・Docker で十分。代替手段まで書く)/ 時期型(拡大後・後発。捨てるのではなく順番の話だと明示)のいずれかで書く。理由の無い削除は後から自分で蒸し返して実装してしまう
書くべき9項目: サービス概要 / MUST・SHOULD・WON'T / 削る機能と理由 / 画面一覧と遷移 / データモデル / 主要APIエンドポイント / 技術スタック / 外部サービスの想定コスト / 1〜2時間粒度の実装ステップ。各項目は「書かないと起きる失敗」に対応する
データモデルの特別扱い: 他の項目は作りながら調整できるが、データモデルは画面も API も巻き込むため変更コストの桁が違う。唯一「着手前に確定させる」項目
書かなくていいもの: 詳細なユースケース記述 / 非機能要件の網羅(想定コストだけでよい)/ 詳細なテスト計画 / スケジュール・工数見積もり(実装ステップが代わりになる)/ 体制図。仕様書に書く価値があるのは「後から変えるのが高くつく決定」だけで、それはスコープとデータモデル
渡し方: 全文を先に渡し、実装ステップ単位で区切って進める。1ステップごとに動作確認する。仕様変更は会話で伝えず仕様書のほうを直す(会話で足した要件は次のセッションで消える)
対象読者: 個人開発者・一人法人。スコープは Webサービスに限定、ネイティブアプリ・ハードウェアは対象外
関連ガイド: 発案から実装までの全体フロー: https://idea.lb-product.com/guide/claude-code / 失敗パターンの分類: https://idea.lb-product.com/guide/why-fail / 発案段階: https://idea.lb-product.com/guide/no-idea / 差別化と参入障壁: https://idea.lb-product.com/guide/moat

決めていない部分は、必ずあとで高くつく。

📋 仕様書をAIに書かせる