TL;DR

  • 仕様駆動開発（SDD）は「仕様 → 実装計画 → タスク分割 → 実行」の流れで迷いと手戻りを減らす開発スタイル
  • SpecKitは仕様・計画・タスク分割の支援が充実している
  • 自作プロンプトでは spec.md、plan.md、tasks.md、manual-test.md の4つに絞り込んで運用
  • AIには「不明点は推測せず質問する」と明示し、タスクはチェックボックスで進捗を見える化

はじめに

最近、仕様駆動開発（Spec-Driven Development, SDD）を試しています。
やりたいことはシンプルで、「仕様 → 実装計画 → タスク分割 → 実行」の流れを、AIと一緒にドキュメントに書き起こしてから実装に入る、というものです。

この記事では、

  • SpecKit を使って SDD を回してみた話
  • 便利さを活かしつつ、自作プロンプトに落とし込もうとしている話
  • Tips
    をまとめます。

仕様駆動開発とは

仕様駆動開発は、ざっくり言うと 「コードを書く前に、仕様（何を作るか）を中心に、実装計画とタスクに落としてから進める」開発スタイルです。

ポイントは「仕様書を書くこと」自体ではなく、次を揃えることだと思っています。

  • 合意可能な仕様（期待する振る舞い・非ゴールが明確）
  • 実装の方針（設計上の意思決定、コンポーネント責務、データモデル）
  • 実行可能なタスク（順序・粒度）

AIを使うと、この一連のドキュメント化・分解を高速に回せるのが魅力です。

SpecKit を試した

SDD系のツールはいくつかあります（例：kiro など）。その中で今回は SpecKit を試しました。

結論から言うと、めちゃくちゃ便利でした。
「仕様の叩き台を作る」だけではなく、計画とタスク分割、実行の導線まで含めて支援してくれるのが良かったです。

SpecKit の生成物

SpecKit で生成される成果物はだいたい次のような構成でした。

├── checklists
│   └── requirements.md
├── contracts
│   └── components.md
├── data-model.md
├── plan.md
├── quickstart.md
├── research.md
├── spec.md
└── tasks.md

それぞれの役割を、自分の理解で簡単に書くとこうです。

  • spec.md
    仕様の中核。目的、背景、ユーザー体験、要件、非要件（非ゴール）、制約、受け入れ条件など。
  • plan.md
    実装計画。アーキテクチャ方針、段取り、リスク、段階的な実装順など。
  • tasks.md
    実行可能なタスク分割。順序や依存が分かる形で列挙される。
  • data-model.md
    データ構造・スキーマ・永続化や整合性など、データの観点を明確化。
  • contracts/components.md
    コンポーネントやモジュールの責務・I/F・境界（いわゆる契約）を言語化。
  • checklists/requirements.md
    要件のチェックリスト。漏れやすい観点を点検する用途。
  • research.md
    調査メモ。比較検討、前提確認、未知の論点などをここに寄せられる。
  • quickstart.md
    実行・検証の導線（セットアップや最短動作確認）をまとめる用途。

SpecKit が支援してくれる開発の流れ

SpecKit が良いと感じたのは、開発の流れとして以下をサポートしてくれる点です。

  • 仕様（spec）
  • 実装計画（plan）
  • タスク分割（tasks）
  • タスク実行（チェックしながら進める）

“AIでコードを書かせる”だけだと、途中で前提が崩れたときに破綻しがちです。SpecKitはその前段（仕様・計画・分割）がしっかりあり、結果として期待するアウトプットの質が上がりました。

自作プロンプトで仕様駆動開発を試している

SpecKit は便利な一方で、プロンプトやドキュメントが重厚に感じる場面もありました。
また、既存プロジェクトの制約（アーキテクチャ、運用、チームの開発プロセス）に合わせて、自分なりに“ちょうど良い”カスタマイズをしたくなりました。

そのため、SDD用のプロンプトを自作して試しています。

とはいえ SpecKit を参考にしている

自作するとはいえ、SpecKitは素晴らしくて好きなので参考にさせていただきました。 このブログもSpecKitを使うことで短時間で作ることができました。

開発の流れとして、以下を踏襲しています。

  • 仕様
  • 実装計画
  • タスク分割
  • タスク実行

自作したプロンプトと生成物

自作では、次のプロンプト（＝成果物のテンプレ）を作りました。

  • この仕様駆動開発についての説明（それぞれのドキュメントの役割など、index.md)
  • 仕様（spec.md）
  • 実装計画（plan.md）
  • タスク分割（tasks.md）
  • マニュアルテストケース作成（manual-test.md）
    自分は目視でも確認したいので、手動のテストケースを生成するようにしました。

生成物は次の通りです。

├── manual-test.md
├── plan.md
├── spec.md
└── tasks.md

役割のイメージはこうです。

  • spec.md：何を作るか（期待する挙動、非ゴール、受け入れ条件）
  • plan.md：どう作るか（方針、段取り、リスク、影響範囲）
  • tasks.md：何から順にやるか（粒度と依存、Done定義）
  • manual-test.md：どう確かめるか（手動で再現できる観点と手順）

SpecKitほどフルセットではないですが、「自分が運用できる軽さ」と「最低限の再現性」を狙っています。

Tips

1. AIに「不明点は推測せず質問して」と明示する

仕様段階で推測が混じると、後工程でズレが増えます。
最初に「不明点は仮置きせず質問する」「仮定する場合は仮定と明記する」を依頼すると、手戻りが減りました。

2. タスクはチェックボックスにして進捗を見える化する

タスクは Markdown のチェックボックスにして、完了が視覚的に分かるようにしています。
セッションを切り替えても追えるので、運用上かなり効きます。

3. タスクを適切なサイズのステップに分ける

全てのタスクを一度にお願いすると精度が悪く頻繁に手戻りが発生、反対にタスクをひとつずつ依頼すると効率が悪くなりました。 そのため適切な粒度のステップに分け、ステップ毎にタスクを依頼する運用にした結果、精度も効率も良くなりました。

4. ステップごとにセッションを切り替える

ステップ単位で会話（セッション）を分けると、精度が上がりやすいです。
また、文脈が長くなりすぎて要約（auto compact）的な挙動に入って破綻するのも避けやすいです。

5. 実装中に仕様や計画が間違っていたら、ドキュメントへ戻って直す

コードだけ直すと、次の修正でまた同じ迷いが再発します。仕様・計画・タスクのドキュメントが「現状と一致している」状態を保つのが重要でした。

6. ステップごとにコミットする

ドキュメント修正→実装→検証、の単位でコミットすると、差分の意図が明確になります。
「どの判断でどんな実装になったか」が追えるので、後からの修正が楽になります。

今後試したいこと

  • 仕様書作成の型を細かく分ける
    機能開発、バグ修正、リファクタリング、ライブラリ更新/アップデートなど、目的ごとに最適なテンプレや問いが違うはずなので、それぞれ特化したプロンプトを試したいです。
  • 生成したマニュアルテストの自動化
    Chrome DevTools MCP などを使って、manual-test.md を半自動で実行できないか試したいです。
    目視確認は残しつつも、「その場限りのE2Eテストを書いて捨てる」みたいな運用もアリかもしれないと思っています。

おわりに

SDDは迷いと手戻りを減らして、開発効率を上げるための型だと感じています。

全てのタスクを仕様駆動開発で進める必要はないと思います。AIは優秀なので簡単なタスクであればドキュメントなど作らずに一発でお願いする方が効率が良いでしょう。

AIが上手く実装してくれないな…と感じた時に仕様駆動開発で進めてみると良い効果があるかもしれません。

「自分のプロジェクトにあった仕様駆動開発をしたい！」となった時の参考になればと思います。