DESIGN.mdテンプレート実例：仕様書の章立てと書き込み例
要件定義書で全体像を固めたら、次は「具体的にどう動くか」を仕様書にまとめます。個人開発でそのまま使えるDESIGN.mdの章立てと、実際の書き込み例を紹介します。
最終更新: 2026-07-23・読了目安 約3分
DESIGN.mdとは何か
DESIGN.mdとは、リポジトリのルートなどに置く、その時点でのアプリの仕様をまとめたMarkdownファイルです。要件定義書が「何のために作るか」という全体像を扱うのに対し、DESIGN.mdは「具体的にどんな画面・機能を、どう動かすか」という詳細を扱います。要件定義書の書き方で決めた目的とスコープを、実装可能な粒度まで落とし込む役割です。
ファイル名やMarkdownという形式にこだわる必要はありませんが、リポジトリに常駐する1つの文書として置いておくと、AIコーディングエージェントに新しい作業を頼むたびに「このファイルを読んでから進めて」と伝えるだけで前提を共有できるという利点があります。実装前に設計をドキュメント化する考え方はAI活用に限った話ではなく、Googleのエンジニアリング組織でも設計ドキュメント（デザインドック）文化として広く実践されています（参考：「Design Docs at Google」）。
章立てのテンプレート
個人開発規模のDESIGN.mdは、次の章立てで十分機能します。
- 概要：このアプリが何をするものか、1段落で説明
- 画面一覧：存在する画面と、それぞれの役割
- 主要機能の詳細：画面ごとの入力項目・表示内容・操作
- データの形：扱うデータの項目と型（例：タスクは「タイトル・期限・完了フラグ」を持つ）
- やらないこと：スコープ外として明記する機能
- 受け入れ基準：何をもって完成とみなすかの判定リスト
書き込み例：タスク管理アプリの場合
実際にどの程度の粒度で書けばよいか、簡単な例で見てみましょう。
- 概要：今日やるべきタスクだけを表示し、完了したら消えていく1画面のタスク管理アプリ。
- 画面一覧：ホーム画面（1画面のみ。設定画面や履歴画面は今回は作らない）。
- 主要機能の詳細：タスクをテキストで入力して追加できる。一覧はチェックボックス付きで表示する。チェックを入れると一覧から消える（削除ではなく非表示扱い）。
- データの形：タスクは「本文（文字列）・作成日時・完了フラグ（真偽値）」を持つ。
- やらないこと：期限設定・通知・カテゴリ分け・複数デバイス間の同期は今回のスコープ外。
- 受け入れ基準：タスクを追加すると一覧に表示される／チェックを入れると一覧から消える／ページを再読み込みしても未完了タスクが残っている。
このくらいの粒度であれば、AIコーディングエージェントは画面数・データの持ち方・完了の扱いについて推測する必要がなくなり、意図に近い実装を返しやすくなります。
実装が進んだら更新する
DESIGN.mdは一度書いたら終わりではありません。実装を進める中で「やっぱりこの機能も必要だった」「この項目は不要だった」と気づくことは自然に起こります。気づいた時点でDESIGN.mdを更新し、常に「今の実装の実態」と一致させておくことが重要です。ズレたままのDESIGN.mdは、後でAIに参照させたときにかえって誤った前提を伝えてしまいます。
機能追加やリファクタリングを頼む際も、まずDESIGN.mdの該当箇所を更新してから指示を出す順番を習慣化すると、AIとの対話全体が安定します。頼み方の具体例はリファクタリングの頼み方でも扱っています。仕様書と合わせてREADMEも実態に一致させておくと、後から見返したときの理解がさらにスムーズになります。詳しくはREADMEとドキュメントをAIに書かせて維持するで解説しています。
よくある失敗パターン
- 章立てを埋めることが目的化する：全項目を無理に埋めようとして、実態のない仕様を書いてしまう。わからない箇所は「未定」と正直に書く方が安全です。
- データの形を曖昧にする：「タスク情報を持つ」だけでは項目が定まらず、AIが独自に項目を補ってしまいます。
- 更新を怠る：実装が仕様書から乖離したまま放置し、後で参照したときに誤解のもとになる。
よくある質問
Q1. DESIGN.mdはどのくらいの粒度で書けばよいですか？
AIコーディングエージェントが画面数・データの持ち方・完了の扱いを推測しなくて済む粒度が目安です。この記事のタスク管理アプリの例のように、画面一覧・主要機能・データの形・やらないことまで具体的に書くと、意図に近い実装を返しやすくなります。
Q2. 章立ての項目を全部埋められません。どうすればよいですか？
無理に埋めようとせず、決まっていない箇所は「未定」と正直に書いてください。実態のない仕様を書いてしまうと、後でAIに参照させたときにかえって誤った前提を伝えてしまいます。
Q3. DESIGN.mdはいつ更新すればよいですか？
実装中に「この機能も必要だった」「この項目は不要だった」と気づいた時点で更新します。機能追加やリファクタリングを頼む前に、まずDESIGN.mdの該当箇所を直してから指示を出す順番を習慣化すると安定します。