そのまま貼れる、MVP仕様書のテンプレート。
個人開発のWebサービス用。AIにそのまま渡せる形にしてある。小規模なら要件定義書としても使える。
当サイトの仕様書ジェネレーターは12項目の雛形で書く。ジャンルも規模も違う2本の出力を、記入例として並べた。
テンプレート全文(コピーして使う)
Markdown。エディタに貼って上から埋めていく。最初は項目を減らさないこと。埋まらない欄が残ったら、そこが「まだ決めていない箇所」だと分かるのがテンプレートの効用で、削るとその検出力が失われる。
# SERVICE_NAME ## サービス概要 誰の・何の不便が・どう消えるかを120〜200字で。1段落で言えないならまだ決まっていない。 未検証の前提: まだ確かめていないこと(例: 本当に困っている人がいるか / お金を払うか)と、誰にどう確かめるか ## MVP のスコープ ### MUST(必須・これが無いとサービスが成立しない) - 機能1 - 機能2 - 機能3 ### SHOULD(あれば良いが MVP では入れない) - 機能 ### WON'T(今回は作らない) - 機能: 作らない理由 ## 削るべき機能と理由 | 機能 | 削る理由 | |---|---| | | コスト型 / 代替型 / 時期型 のいずれかで | ## 画面一覧と遷移 | 画面 | 目的 | 主な要素 | 遷移先 | |---|---|---|---| | | | | | ## データモデル テーブル名 - id: 型 - カラム: 型 / 制約・既定値 - 関連: 他テーブルとの関係 扱う個人データ: 保存する項目 / 外部への送信先 / 保存期間(無ければ「なし」) ## 主要 API エンドポイント | メソッド | パス | 入力 | 出力 | |---|---|---|---| | GET | | | | ## 技術スタック推奨 - 言語 / フレームワーク: - DB: - ホスティング: - 理由: なぜこの構成か。個人開発で維持できる根拠 ## 外部サービス・API と想定コスト | サービス | 用途 | 利用条件(規約・無料枠・上限) | 想定月額(円) | |---|---|---|---| | | | | | 合計: 円/月(内訳の合計と一致させる) 前提: 想定ユーザー数 / 1人あたりの利用回数 / ドル建てなら換算レートと日付 ## 実装ステップ - [ ] 1. 1〜2時間で終わる単位 - [ ] 2. 終わったら動作確認できる単位で区切る - [ ] 3. 公開前の受入条件: - [ ] 例) 主要画面がスマホ幅で使える - [ ] 例) 個人データが想定外の送信先へ出ていない - [ ] 例) 想定外の入力でエラー画面にならない
※ 項目名は、種火の AI MVP仕様書ジェネレーター が出力に使っている構成をそのまま使っている(記入例は次節)。
記入例: 別ジャンルの2本を同じ雛形で並べる
このテンプレートの項目は、種火の仕様書ジェネレーターが出力に使う雛形と同じだ。ここでは種火が公開している実際の仕様書2本(アーカイブ)を記入例として並べる。
| セクション | レシピ栄養計算 | 営業支援ツール |
|---|---|---|
| サービス概要 | あり | あり |
| MVP のスコープ | あり | あり |
| MUST | あり | あり |
| SHOULD | あり | あり |
| WON'T | あり | あり |
| 削るべき機能と理由 | あり | あり |
| 画面一覧と遷移 | あり | あり |
| データモデル | あり | あり |
| 主要 API エンドポイント | あり | あり |
| 技術スタック推奨 | あり | あり |
| 外部サービス・API と想定コスト | あり | あり |
| 実装ステップ | あり | あり |
2本とも全12項目が揃っていた。片方は家庭向けのレシピ栄養計算(本文 7,233字)、もう片方は法人向けの営業支援(7,002字)で、対象も規模も違う。構成が一致しているのは、ジェネレーターがこの雛形で書くよう指定しているためで、12項目の妥当性を独立に検証した結果ではない。それでも、対象も規模も違う案を同じ枠で最後まで埋められたことは、この雛形が少なくとも記入しやすい形になっていることを示している。
なぜ WON'T をそこまで書くのか、どの機能が削られやすいのかは MVP仕様書の書き方 で扱っている。本記事は雛形と埋め方に絞る。
項目ごとの書き方と記入例
実データから、そのまま真似できる粒度の例を抜き出した。抽象度がずれると仕様書は機能しないので、粒度の見本として使ってほしい。
1. サービス概要
誰の何の不便がどう消えるかを120〜200字
レシピURLを貼るだけで栄養価を自動計算し、1日の合計と不足栄養素を表示する。手入力の手間なく食事管理を続けられる。
ポイント: 1段落で言えないなら、対象か課題のどちらかがまだ決まっていない
2. MUST
これが無いと成立しない機能を3〜5個
URL貼り付けによるレシピ取り込み / 栄養価の自動計算 / 1日分の合計表示
ポイント: 6個以上出るなら対象ユーザーが広すぎる可能性が高い
3. WON'T
作らない機能と理由を必ずセットで
モバイルアプリは作らない: Web版で十分動作し、開発工数が2倍以上になるため。PWAで対応する。
ポイント: 理由が無い削除は、2週間後の自分が蒸し返して実装してしまう
4. 画面一覧と遷移
画面ごとに 目的 / 主な要素 / 遷移先
レシピ登録画面 / URLの取り込みと結果確認 / 入力欄・プレビュー・保存ボタン / 一覧画面へ
ポイント: 画面数はスコープの代理指標。想定より多ければ切り足りていない
5. データモデル
テーブル・カラム・型・関連まで
recipes: id, url, title, servings, created_at。nutrients と1対多。
ポイント: 唯一「着手前に確定させる」項目。後から変えると画面もAPIも全部に波及する
6. 主要APIエンドポイント
メソッド / パス / 入力 / 出力
POST /recipes 入力 { url } 出力 { id, title, nutrients[] }
ポイント: 画面から必要なデータが取れるかの検算に使う。ここで矛盾が見つかる
7. 外部サービスと想定コスト
サービス名 / 用途 / 月額
栄養データベースAPI / 栄養価の取得 / 0〜1,500円
ポイント: 空欄のまま作ると、公開後に維持できない構成になっていることがある
8. 実装ステップ
1〜2時間で終わり、動作確認できる単位
1. スキーマ作成とマイグレーション 2. URL取り込みAPIの実装
ポイント: まとめて頼むと、仕様から逸れても気づけない
技術スタックの欄は「なぜこの構成か」まで書く。理由が無いと、AIが別の構成を提案してきたときに判断できない。
埋める順番 — データモデルだけ特別扱いする
上から順で構わない。ただしデータモデルだけは「あとで直す」を許さない。ここだけ変更コストの桁が違うからだ。
逆に言えば、この2つさえ決まっていれば書き始めてよい。全項目が完璧に埋まるまで着手しない、というのは仕様書の使い方として本末転倒になる。
AIへの渡し方
- 全文を先に渡す。「これがこのプロジェクトの仕様書です」と前置きして丸ごと読ませる
- 実装ステップ単位で区切る。「ステップ1だけやってください」と指定し、1つ終わるごとに動作確認する
- 仕様変更は会話ではなく仕様書のほうを直す。会話で足した要件は次のセッションで失われる
- 逸れたら仕様書を指し示す。「仕様書のデータモデルと違います」と返すだけで戻る
「タスク管理ツールを作って。あとで期限も付けたい」
「この仕様書に沿って実装します。まずステップ1(スキーマ作成)だけお願いします。期限は WON'T に入れてあるので今回は作りません」
発案から実装までの全体の流れは AI時代に個人開発で何を作るか にまとめてある。
よくある埋め方の失敗
続けて読む
- MVP仕様書の書き方 — 何を削るかの判断。本記事が雛形、あちらがスコープの決め方
- AI時代に個人開発で何を作るか — 発案から実装までの全体フロー
- Webサービスの差別化と参入障壁 — 着手前に確認する模倣耐性
- 個人開発のWebサービスがつまずく5つの型 — 設計で潰せる失敗
よくある質問
- Q. テンプレートには何の項目が必要?
- 概要 / スコープ / MUST / SHOULD / WON'T / 削る機能と理由 / 画面一覧 / データモデル / API / 技術スタック / 想定コスト / 実装ステップ の12項目。AI生成の実仕様書2本が同じ構成に収束していた。
- Q. 個人開発でも仕様書は要る?
- 実装が速くなったからこそ要る。決めていない部分はAIが推測で埋め、その推測は毎回変わるので、修正を重ねるほど筋が通らなくなる。
- Q. どこから書き始める?
- 概要から。1段落で書けないなら対象か課題が未定。次に MUST 3〜5個と WON'T 同数を決めると、以降が自動的に絞れる。
- Q. データモデルは後から変えては?
- これだけは着手前に固める。画面もAPIも依存するので、変更が全体に波及して桁違いのコストになる。
- Q. AIにどう渡す?
- 全文を先に渡し、実装ステップ単位で区切る。仕様変更は会話ではなく仕様書のほうを直す。
- Q. 想定コストは空欄でもいい?
- 埋める。空欄のまま作ると、公開後に維持できない構成になっていることがある。個人開発では月数千円が現実的な上限。
- Q. 項目を減らしてもいい?
- 最初は減らさない。埋まらない欄が「未決定の箇所」を教えてくれるのがテンプレートの効用。不要と判断したら「該当なし」と書いて残す。
- Q. 自分で書かずに生成できる?
- できる。アイデアの概要を入力すると12項目を埋めたMarkdownが生成される。ただし WON'T が自分の判断と合っているかは必ず確認する。
- Q. バイブコーディングでも仕様書は要る?
- 必要です。バイブコーディングはAIに会話で指示してコードを書かせるので、実装が速いぶん、決めていない部分はAIが推測で埋めます。その推測は依頼のたびに変わるため、修正を重ねるほど辻褄が合わなくなります。作る範囲(MUST)と作らない範囲(WON'T)、データモデル、公開前の受入条件だけでも先に書いて渡すと、作り直しが減ります。
- Q. 要件定義書のテンプレートとして使える?
- 個人開発や小規模なWebサービスなら使えます。受託開発の要件定義書は、業務要件・機能要件・非機能要件(性能・セキュリティ・運用など)を発注側と合意するための文書で、項目はもっと多くなります。このテンプレートはそのうち、作る範囲(MUST / SHOULD / WON'T)・画面・データ・API・外部サービスと費用・公開前の受入条件という、1人で作る前に決めておくべき部分に絞っています。発注や社内の承認に使う場合は、非機能要件・体制・スケジュールを書き足してください。
SUMMARY
- 主題
- 個人開発の Webサービス 用 MVP 仕様書テンプレート(そのまま貼れる雛形)と、各項目の記入例・AI への渡し方
- テンプレートの12項目
- サービス概要 / MVP のスコープ / MUST / SHOULD / WON'T / 削るべき機能と理由 / 画面一覧と遷移 / データモデル / 主要 API エンドポイント / 技術スタック推奨 / 外部サービス・API と想定コスト / 実装ステップ
- 一次観測(2026-09-04時点)
- 種火の AI MVP仕様書ジェネレーターが生成した実際の仕様書 2 本(レシピ栄養計算 7,233字 / 営業支援 7,002字)の見出しを突き合わせたところ、対象も規模も違うのに全12項目が一致していた。スコープはどちらも MUST 5 / SHOULD 4 / WON'T 5 で、WON'T が MUST と同数
- 埋める順番
- 着手前に固めるのはデータモデルとスコープ(MUST / WON'T)の2つだけ。データモデルは画面・API・実装のすべてが依存するため後から変えると全体に波及する。画面一覧・API・技術スタック・実装ステップは作りながら調整してよい
- 項目ごとの粒度
- 概要=120〜200字で誰の何の不便がどう消えるか / MUST=3〜5個(6個以上なら対象が広すぎる)/ WON'T=機能と理由をセット / 画面=目的・要素・遷移先 / データモデル=カラムと型と関連 / API=メソッド・パス・入出力 / コスト=サービス名・用途・月額 / 実装ステップ=1〜2時間で終わり動作確認できる単位
- AI への渡し方
- 全文を先に渡す → 実装ステップ単位で区切って進める → 1 ステップごとに動作確認 → 仕様変更は会話ではなく仕様書のほうを直す(会話で足した要件は次のセッションで失われる)
- よくある失敗
- MUST が10個ある(対象が広すぎる)/ WON'T が空欄(機能が際限なく増える)/ 削る理由が無い(後から蒸し返す)/ データモデルを「あとで考える」/ 想定コストが空欄(公開後に維持できない)/ 実装ステップの粒度が粗い(動作確認できない)
- 対象読者
- 個人開発者・一人法人。スコープは Webサービス に限定、ネイティブアプリ・ハードウェアは対象外
- 関連ガイド
- スコープの切り方(何を削るか): https://idea.lb-product.com/guide/mvp-spec / 全体フロー: https://idea.lb-product.com/guide/claude-code / 差別化と参入障壁: https://idea.lb-product.com/guide/moat / 失敗の型: https://idea.lb-product.com/guide/why-fail
埋まらない欄が、まだ決めていない箇所。
仕様書をAIに書かせる