AIコーディングエージェントを使うと、実装速度は上がります。
一方で、会話だけで開発を続けると「なぜこの設計にしたのか」「今回どこまで変えるのか」がセッションをまたいで失われやすくなります。
そこで、2つの個人開発で仕様駆動開発（Spec-Driven Development、以下SDD）を試しました。
SDDは、実装前に完璧な設計書を完成させる手法ではありません。
要求・判断・受け入れ条件をリポジトリ内の仕様として残し、それを人間とAIの共通コンテキストとして実装・更新する開発方法です。
本記事では、その仕様を「機能単位」で育てるSpec Kitと、「変更差分と現在仕様」に分けて育てるOpenSpecを比較します。
この記事は、次のようなエンジニアを想定しています。
-
AIコーディングエージェントを使っているが、チャットだけの仕様管理に限界を感じている
-
新規開発または既存プロダクトへSDDを導入したい
-
OpenSpecとSpec Kitのどちらを選ぶべきか、実例を基に判断したい
2026年7月20日時点で、OpenSpec側にはアーカイブ済み変更44件・正規化された仕様16件、Spec Kit側には機能仕様15件・実装計画13件・タスクリスト12件が蓄積されています。
先に結論を書くと、私の使い分けは次のとおりです。
新規プロダクトや大きな機能を、要求から丁寧に設計するならSpec Kit。既存プロダクトへ小〜中規模の変更を継続的に加えるならOpenSpec。
両方とも「AIに良い指示を出すツール」ではなく、人間とAIが共有する判断の履歴をリポジトリに残す仕組みとして使うと価値が出ました。
前提: 2つのプロジェクト
OpenSpec: FGO周回育成計画シミュレーター
既存機能へ改善を重ねるタイプのWebアプリです。機能追加、UI改善、計算ロジック修正など、独立した変更を短いサイクルで繰り返します。
リポジトリ内は、おおむね次の形です。
openspec/
├── specs/ # 現在のシステム仕様
│ └── progress-visualizer/
│ └── spec.md
└── changes/
├── progress-tier-multi-window/
│ ├── proposal.md
│ ├── design.md
│ ├── tasks.md
│ └── specs/ # 今回の変更差分
└── archive/ # 完了した変更
Spec Kit: GeoDojo
GeoGuessrの反復学習を支援するWebアプリです。Next.js、React、Drizzle、Supabaseなどを使い、ユーザーシナリオから新しい学習機能を設計して実装しています。
リポジトリ内では、プロジェクト共通の原則と機能単位の成果物が分かれます。
.specify/
└── memory/
└── constitution.md # プロジェクト共通の原則
specs/
└── 015-kana-support/
├── spec.md # ユーザー要求・受け入れ条件
├── plan.md # 技術設計
├── research.md # 技術調査
├── data-model.md
├── contracts/
└── tasks.md # 実装タスク
同じ規模・同じ条件の比較実験ではありません。OpenSpecは既存プロダクトの反復改善、Spec Kitは新規プロダクトの機能開発に使っています。
その違い自体が、各ツールの向き不向きを見つける材料になりました。
Spec Kitで良かったこと
公式ドキュメントの基本フローは、Spec → Plan → Tasks → Implementです。
実際には、プロジェクト原則を定めるConstitutionや、仕様の曖昧さを解消するClarify、成果物間の矛盾を確認するAnalyzeも組み合わせられます。
1. 「何を作るか」と「どう作るか」を分離しやすい
spec.mdにはユーザーシナリオ、優先順位、受け入れ条件、エッジケース、機能要件、成功条件を書きます。技術選定やデータ構造はplan.mdへ送ります。
この分離により、AIが要求を聞いた直後に実装方法へ飛びつくのを抑えられました。
たとえば「かな表記に対応する」という要求に対し、先に利用者がどこで困るのか、何をもって成功とするのかを固め、その後でデータソースやスキーマ変更を決められます。
2. Constitutionが設計レビューの軸になる
GeoDojoでは.specify/memory/constitution.mdに、セキュリティ、アーキテクチャ、性能、UI、技術スタックなどの原則を置いています。
機能ごとの計画にConstitution Checkが入るため、AIがその場では合理的に見える別の方式を提案しても、プロジェクト全体の方針へ引き戻せます。
長期運用では、プロンプトの工夫よりもこの固定された判断軸のほうが効きました。
3. 大きな機能でも実装前に見通せる
13件のplan.md、12件のresearch.md、13組のcontracts/が残っています。
仕様からデータモデル、API契約、テスト、タスクへ段階的に落とすので、影響範囲の広い機能でも着手前に漏れを見つけやすくなりました。
一方で、成果物が多いぶん運用コストもあります。小さな文言修正や局所的なバグ修正までフルフローに載せると、コードよりMarkdownの変更量が大きくなります。
仕様、計画、タスクの重複箇所が増えるため、実装中に判断が変わったときの同期も必要です。
OpenSpecで良かったこと
OpenSpecは公式にも「lightweight」「brownfield-first」を掲げています。
基本サイクルは、変更を提案するpropose、実装するapply、完了した変更を正規仕様へ反映するarchiveです。
1. 「現在の仕様」と「今回の差分」が分かれる
openspec/specs/には現在のシステム仕様があり、openspec/changes/<change-id>/specs/には追加・変更・削除する要件の差分が置かれます。
コードレビューで見たいのは、システム全体の説明より「今回、利用者の振る舞いがどう変わるか」です。差分仕様があることで、コードを読む前に変更意図を確認できます。
2. 既存コードへの小さな変更を回しやすい
FGO側では44件の変更を完了・アーカイブできました。1変更ごとに、次の成果物を必要な深さで作ります。
-
proposal.md: なぜ必要か、何を変えるか、影響範囲 -
design.md: 技術判断、代替案、リスク、移行方針 -
tasks.md: 実装チェックリスト -
specs/: 要件とシナリオの差分
変更フォルダを作る単位がそのまま作業単位になるので、セッションをまたいでも再開しやすく、複数のコーディングエージェントにも渡しやすいです。
3. Archiveが「完了」の定義になる
実装して終わりではなく、変更をアーカイブすると差分がopenspec/specs/の正規仕様へ反映されます。完了した44件は履歴として残り、現在の挙動は16件の正規仕様から読めます。
この構造は、変更履歴だけが増えて「結局、今どう動くのか分からない」という状態を避けやすいです。
弱点は、Archiveを怠ると正規仕様と実装がずれることです。また、既存機能をすべて最初に仕様化してくれるわけではありません。
触る領域から少しずつ仕様を育てる前提なので、導入直後はカバー範囲に濃淡があります。
30秒で選ぶなら
- コードがまだない、または大きな機能の要求から整理したい → Spec Kit
- 既存コードへPR単位の変更を積み重ねたい → OpenSpec
- 変更意図が数行で説明でき、手戻りリスクも低い → どちらも使わない
この基準で候補を決めたうえで、次の比較表から運用上の違いを確認すると判断しやすくなります。
実践比較
設計と成果物
| 観点 | Spec Kit | OpenSpec |
|---|---|---|
| 得意な場面 | 新規開発、大機能、要求が曖昧な案件 | 既存開発、継続改善、小〜中規模変更 |
| 中心単位 | 機能仕様 | 変更差分と正規仕様 |
| 基本フロー | Spec → Plan → Tasks → Implement | Propose → Apply → Archive |
| プロジェクト共通原則 | Constitutionとして明示 |
config.yamlや既存仕様・エージェント指示で補う |
| 成果物の厚さ | 厚い。調査、データモデル、契約まで展開しやすい | 必要十分。提案、設計、タスク、仕様差分が中心 |
日々の運用
| 観点 | Spec Kit | OpenSpec |
|---|---|---|
| 小変更の軽さ | フルに回すと重い | 変更フォルダ単位で回しやすい |
| 現在仕様の把握 | 機能別の成果物をたどる | 正規仕様を能力単位で読める |
| 履歴の把握 | 番号付き機能ディレクトリとGit履歴 | アーカイブ済み変更をたどれる |
| 主な運用リスク | Markdownの重複、実装変更時の同期漏れ | Archive忘れ、未仕様化領域の存在 |
迷ったときの選び方
Spec Kitを選ぶ
- まだコードがなく、プロダクトの骨格から考える
- ユーザーシナリオや成功条件が曖昧
- API、データモデル、非機能要件まで実装前にレビューしたい
- チームの設計原則をConstitutionとして強く効かせたい
- 1機能の影響範囲が広く、手戻りのコストが高い
OpenSpecを選ぶ
- すでに動いているコードへ変更を積み重ねる
- PR単位に近い粒度で変更意図を残したい
- 複数セッション、複数エージェントで作業を引き継ぐ
- 現在の仕様と変更履歴を分けて管理したい
- まず一部の機能からSDDを導入したい
併用するなら役割を重ねない
両方を同じ変更にフル適用すると、ほぼ同じ情報を別形式で管理することになります。併用するなら、たとえば次のように境界を決めるのがよさそうです。
- プロダクト立ち上げ・大規模再設計: Spec Kit
- 通常の機能追加・改善: OpenSpec
- 数行で意図が明らかな修正: どちらも使わず、Issueやコミットで管理
重要なのは、すべての変更を仕様化することではなく、仕様を書くコストより、認識ずれや手戻りを減らす価値が大きい変更を見極めることです。
まず1機能だけ試す最小フロー
どちらも最初から全機能を仕様化する必要はありません。
既存プロジェクトなら、30〜90分で実装できる独立した1機能を選ぶと、仕様作成のコストと効果を比較しやすくなります。
以下は2026年7月20日時点の最小例です。コマンドやセットアップ方法は更新されるため、実行時は各公式ドキュメントも確認してください。
OpenSpec
npm install -g @fission-ai/openspec@latest
cd existing-project
openspec init
初期化後は、対応するAIエージェント上で次のサイクルを1回だけ回します。
/opsx:propose add-small-feature
/opsx:apply
/opsx:archive
次の3点を確認します。
-
proposal.mdを読めば変更意図が分かるか -
tasks.mdから実装を再開できるか - Archive後の正規仕様が実装と一致しているか
Spec Kit
uv tool install specify-cli
specify init my-project
初期化後は、要求から実装までを次の順で進めます。
/speckit.constitution
/speckit.specify
/speckit.plan
/speckit.tasks
/speckit.implement
次の3点を確認します。
-
spec.mdから実装方法を除いてユーザー要求を表現できているか -
plan.mdがConstitutionに違反していないか -
tasks.mdだけを渡して別セッションでも実装を続けられるか
1機能を完了したら、生成されたMarkdownの量ではなく、手戻りが減ったか、途中再開が楽になったか、レビューで変更意図を説明しやすくなったかを評価します。
チームや既存プロセスへ組み込む
個人開発では、仕様ファイルを「次のセッションへ引き継ぐメモ」として扱えます。
チーム開発では、既存のIssueやPRを置き換えるのではなく、役割を分けると運用が重くなりません。
- 仕様: なぜ作るか、利用者に何が起きるか、受け入れ条件を残す
- Issue・タスク管理: 担当者、期限、進捗を管理する
- PR: コード差分と仕様差分を一緒にレビューする
- 完了処理: OpenSpecはArchive担当、Spec Kitは仕様と実装の整合確認者を決める
2〜5名程度のチームなら、まず1つの機能だけを対象にし、仕様レビューを既存のPRレビューへ含める方法から始めるのが現実的です。
運用して分かった3つのコツ
1. AIが生成した仕様をそのまま承認しない
仕様の価値は文章量ではなく、意思決定の質です。少なくとも次を人間が確認します。
- ユーザー価値ではなく実装都合の要件になっていないか
- スコープ外が明示されているか
- 受け入れ条件をテストできるか
- 既存仕様と矛盾していないか
- タスク完了が要件達成を意味するか
2. 実装中の判断変更を仕様へ戻す
実装して初めて分かる制約は必ずあります。その変更をチャットだけで済ませると、仕様はすぐに古くなります。
コードを直すのと同じ作業単位で、spec.mdやdesign.mdも更新します。
3. 「完了条件」に仕様更新を含める
OpenSpecならArchive、Spec Kitなら仕様・計画・タスクと実装の整合確認までをDoneに含めます。
ここを自動化またはレビュー項目化しないと、最初だけ立派なドキュメントが作られ、その後使われなくなります。
まとめ
OpenSpecとSpec Kitは競合というより、仕様をどの単位で管理するかが異なるツールだと感じました。
- Spec Kitは、ユーザー要求から技術計画まで段階的に深掘りし、大きな機能を作る前の不確実性を減らす
- OpenSpecは、既存システムに対する変更意図を差分として管理し、完了後に現在仕様へ統合する
GeoDojoではSpec Kitの15件の機能仕様が設計の背骨になり、FGO周回育成計画シミュレーターではOpenSpecの44件の変更履歴が継続改善の地図になりました。
AIエージェントのモデルやツールは短い周期で変わります。それでも、リポジトリに残した要求、判断、受け入れ条件は持ち運べます。
SDDの一番の価値は、特定のAIを賢くすることではなく、人間とAIが同じ文脈から何度でも開発を再開できることだと考えています。