Skip to main content

26P-SP-00001: sddp プロジェクトコンセプト

改訂履歴​

版日付作成者章番号／章タイトル改訂内容／理由
v1.0.02026/05/10--初版作成

概要​

Spec-Driven Development Platform（以後、sddp）は、ALM（Application Lifecycle Management）のドキュメント管理領域に特化したフレームワークである。ドキュメントと User Harness を核として提供し、特定の AI ツールに依存しない。

本ドキュメントの目的​

  • プロジェクトの「Why（なぜ必要か）」と「What（何を提供するか）」を明確にする

ALM における sddp の立ち位置​

ALM の各領域には、AI 以前から人間が作り続けてきた資産がある。ソースコードには GitHub、タスクには Jira があるように、文書には sddp がある。sddp はドキュメントと、AI がその文書を活用するための User Harness を一体で提供する。

sddpのドキュメント階層​

用語ディレクトリ / 場所意味
企画・要求層docs/10_planning/ + docs/20_requirements/プロジェクトの目的（Why）と要求（What）を確定する正式文書群。10_planning は内部主導の企画・コンセプト、20_requirements は外部（クライアント等）からの要求定義
設計層docs/30_architecture/ + docs/40_skeleton/ + docs/50_detail-design/実現方法（How）を確定する正式文書群。40_skeleton（基本設計）と 50_detail-design（詳細設計）が設計の SSOT（Single Source of Truth: 唯一の真実の源泉）
品質保証層docs/60_tests/テスト計画・仕様・報告書
運用保守層docs/70_ops/運用手順・保守計画・SLO
横断記録層docs/80_adr/ + docs/90_design-docs/ + docs/98_retrospectives/意思決定・設計思考・振り返りを全層から蓄積する記録
AI作業指示層（4層外の独立領域）.kiro/specs/ 等cc-sddやruflo、cc-workflow等のAI仕様駆動開発ツールで作成される文書。使い捨て可能で、得られた設計知見は 40_skeleton / 50_detail-design に蒸留して永続化する

Why: なぜ必要か​

プロジェクトの背景​

個人開発では、企画から運用までを一貫して管理する仕組みを作る余裕がない。また、プロジェクトの規模を問わず、開発初期にウォーターフォールのように仕様を固めきるのは非現実的で、実装を回しながら判断を蓄積し、後から正本に統合していく流れ が必要になる。sddp が目指す第一の柱は、個人開発や少人数の開発でも、「アジャイル的な蓄積力」と「ウォーターフォール的なドキュメント階層」の両立を実現することである。

同等に重要な第二の柱として、文書は人間だけが読むものではなくなった。AI がコードを書き、設計意図を参照しながら開発を進める時代において、文書は AI と人間が共同で読み・書き・活用する基盤でなければならない。散逸した wiki や個人ノートに分散した文書は AI にとって「読めない」資産であり、判断根拠を辿れないまま整合性のない実装が積み重なる。sddp は、人間と AI の両方が参照できる ドキュメント と、AI ツールがその文書を活用するための User Harness を一体で提供することで、この両方の柱を実現する。

単体のAI仕様駆動開発ツールだけではこの両立は成立しない。AI仕様駆動開発ツールは特定の開発フェーズを効率化するが、企画・要求層と設計層（なぜ作るのか、何を要求するか、どう設計するのか）・横断記録層・品質保証層・運用保守層は自前管理が必要になる。仕組みがないまま開発を続けると、数ヶ月〜数年で仕様と実装が乖離し、仕様把握が困難になる（Spec Drift）。

解決したい課題​

単体のAI仕様駆動開発ツールでは、開発スタイル（ウォーターフォール/アジャイル）を問わず以下の課題が発生する。これらの課題は独立して生じるものではなく、3つの根本原因から派生している。

  • ドキュメント管理基盤の欠如 — 文書層の構造・テンプレート・整合性検証の仕組みがなく、企画から運用までのプロジェクト全体が見渡せない（→ 1-1）
  • 設計知識の定着・保全機構の欠如 — 時間の経過とともに、判断根拠・設計意図・検討過程が忘れられていく（→ 2-1 / 2-2 / 2-3）
  • 全層横断のAI連携層の欠如 — AI支援がAI作業指示層内またはセッション内に閉じており、文書層全体を横断できない（→ 3-1）

アジャイル型で顕著になるものは各行の本文内に注記する。

根本原因番号内容
ドキュメント管理基盤の欠如1-1プロジェクト全体が見えない — 企画・要求層／設計層から品質保証層・運用保守層・横断記録層まで、文書層の構造・テンプレート・整合性検証の仕組みがない。各層がバラバラに整備されるか整備されないまま進み、プロジェクト全体の状態を誰も把握できなくなる
設計知識の定着・保全機構の欠如2-1仕様と実装の乖離（Spec Drift） — 各文書層間だけでなく、層内（要件↔設計↔実装）でも文書間の整合が手動で、変更漏れが発生する。変更頻度の高いアジャイル型で特に顕著
設計知識の定着・保全機構の欠如2-2判断根拠の管理が属人的 — なぜこの機能を実装したのか、要件の解釈根拠、スコープ判断の理由などを管理する仕組みがなく、担当者の記憶に依存する
設計知識の定着・保全機構の欠如2-3検討過程の散逸 — 設計判断・要件解釈・テスト方針など、文書の「結論」には残るが検討経緯が消える。ADRは意思決定を記録するが、日常的な検討・却下した選択肢は対象外。ウォーターフォール型でも設計書に全ては残らないが、アジャイル型では走り続けるため特に散逸しやすい
全層横断のAI連携層の欠如3-1AI支援がAI作業指示層内・セッション内に閉じている — 単体のAI仕様駆動開発ツールのAI支援はAI作業指示層内またはセッション内に閉じている。企画・要求層／設計層や品質保証層・運用保守層・横断記録層の文書作成・検証・波及分析を横断的に支える仕組みがない

What: sddp が提供するもの​

コア価値​

価値内容
ドキュメント管理特化ALM の中でドキュメント管理に集中する。タスク管理・コード管理・CI/CD は GitHub・Jira 等の専門ツールに委譲し、SDD-P はそこに競合しない
AIツール非依存CLAUDE.md を最大公約数として、Claude Code・Cursor・Cline・npx 経由 CLI 等の任意の AI ツールが Layer 1 文書にアクセスできる。特定ツールへの依存は持たない
生きた仕様文書は常に最新に保たれ、開発を駆動する起点となる
ライフサイクル一貫管理sddpのドキュメント階層 で統合し、層間・層内の整合性を保つ（AI作業指示層は一時展開され、知見は設計層に蒸留される）
開発スタイル非依存ウォーターフォール型／アジャイル型のどちらでも、同じドキュメント階層に正本を結晶化する

実現方法​

  • User Harness の多段構成: CLAUDE.md（全ツール共通）→ .claude/rules/ + steering（深い統合）→ スキル/hooks（Claude Code 専用自動化）の順で接続深度を選択できる
  • 蓄積と統合: ADR・Spec 等の日々の記録を定期的に正本（skeleton 等）へ統合する
  • 検証・波及分析の自動化: 文書作成・整合性チェック・波及分析をスキル/エージェントが担い、人間は設計判断と承認に集中する

提供する価値​

sddp は開発スタイル（ウォーターフォール/アジャイル）を問わず以下の価値を提供する。各価値は解決したい課題（1-1〜3-1）に対応する。「影響層」列の定義は 解決したい課題 と同じ。

番号内容対応課題影響層
◎1企画から運用までの一貫管理 — planning→architecture→skeleton→detail-design→tests→opsのドキュメント階層で、プロジェクト全体の整合性を維持する（AI作業指示層は設計層に接続）1-1全層
◎2全層間+層内の整合性を自動検証 — 企画・要求層／設計層↔AI作業指示層↔品質保証層・運用保守層の間だけでなく、層内（要件↔設計↔実装）の乖離も層別矛盾チェックと影響分析で自動検出する2-1全層
◎3即座にセットアップ — sddp init でフレームワーク環境を数分で構築1-1全層
◎4ツール非依存・非侵襲的 — GitHub/GitLab/ローカルgit等の特定サービスに依存せず、プロジェクト本体にも影響を及ぼさない1-1全層
◎5AI×人間の協働加速 — 文書作成・検証・波及分析・整合性チェックを AI のスキル/エージェント体系が自動化し、人間は設計判断と承認に集中する。企画から運用まで全フェーズで両輪を回し、片方だけでは到達できないスピードと品質を実現する3-1全層
◎6判断の追跡可能性 — 文書内コメントで解釈・前提を記録し、ADRで意思決定を構造化。全工程で判断根拠の散逸を防ぐ2-2全層
◎7検討過程の記録 — 議論の経緯や却下した選択肢は Design Doc で（決定前の議論プロセス）、決定は ADR（書式例: MADR）で記録する。アジャイル型で走り続ける際の検討散逸を防ぐ効果が特に大きい2-3全層
◎8skeletonと detail-designが設計の SSOT — 40_skeleton は機能構成・フロー・外部 IF など外部視点の基本設計を担い、50_detail-design はエンティティ詳細・CRUD・ツール仕様など実装視点の詳細設計を担う。1-1設計層
◎9蒸留による設計知見の永続化とスピード両立 — AI作業指示層の文書は使い捨て可能。AI仕様駆動開発（要件→設計→タスク→実装）で素早く実装しつつ、得られた設計知見の要点を設計層に蒸留（昇格）することで、開発スピードと Spec Drift 回避・Why保全を両立する。アジャイル型で特に効く2-1AI作業指示層
◎10AI作業指示層横断の優先順位管理 — バックログ的な仕組みで、AI作業指示層の全体像・着手順序・未着手アイデアを一元管理する。反復サイクルが多いほど効果が顕著1-1AI作業指示層
◎11テスト文書の体系管理 — テスト計画→仕様→報告のトレーサビリティを確保し、TDDだけではカバーできない品質保証の全体像を管理する1-1品質保証層
◎12運用文書の体系管理 — 運用手順・保守計画をドキュメント階層に組み込み、実装完了後のライフサイクルまで一貫して管理する1-1運用保守層

ビフォーアフター​

Before（現状: 単体ツールでの開発）​

  • オレンジ枠（①）: ドキュメント管理基盤の欠如（1-1）— 各層が整備されずプロジェクト全体が見えない
  • グレー破線枠: 1-1の結果として各層がバラバラ。AI作業指示層のみ部分的にカバー（緑）
  • 赤枠（②）: 設計知識の定着・保全機構の欠如（2-1/2-2/2-3）— 時間とともに思想・設計が忘れられる
  • オレンジ枠（③）: 全層横断のAI連携層の欠如（3-1）— AI支援がAI作業指示層内に閉じる

After（目指す姿: sddpでの開発）​

  • 緑枠（①）: ドキュメント管理基盤（1-1）の解決 — 4層SSOTで企画から運用まで一貫管理。各層に対応する◎解決策を配置
  • 紫枠（②）: 設計知識の定着・保全（2-1/2-2/2-3）の解決 — 整合性自動検証・判断追跡・検討記録で設計知識を永続化
  • 青枠（③）: AI連携層（3-1）の解決 — AI×人間の協働加速で全層を横断
  • 太い二重線（==>）: AI連携層が文書層全体を横断する主要フロー
  • 点線（↔）: 4層SSOTと設計知識の保全が生きた仕様として循環する関係

開発スタイルへの対応とドキュメント​

sddp は単一の開発スタイルを強制せず、プロジェクトの性質に応じて ウォーターフォール型 と アジャイル型 の両方に対応する。どちらのスタイルでも同じドキュメント階層（企画・要求層 / 設計層 / 品質保証層 / 運用保守層 / 横断記録層）を共有し、AI作業指示層（使用ツールにより場所は異なる）は4層と連携する作業領域として扱う。正本（SSOT）への統合ルート がスタイル間で異なるだけである。

ウォーターフォール型（最初から固める）​

要件が比較的明確で、開発初期から企画・要求層と設計層（10_planning / 20_requirements / 30_architecture / 40_skeleton / 50_detail-design）を確定できる場合のスタイル。

  • 企画・要求層と設計層を先に完成させ、その後 AI作業指示層で詳細化・実装
  • 変更が発生した場合は ADR で記録し、該当の正本を更新
  • 向き: 規制産業、公共案件、大規模チーム、仕様が明確な既存システムの改修

アジャイル型（事後統合で結晶化）​

開発初期から企画・要求層と設計層を固めきれない場合のスタイル。日々の判断を蓄積し、定期的に正本へ統合することで仕様を育てる。

  • AI作業指示層を先に回しつつ、日々の判断を ADR（書式例: MADR ミニマル / フル版）として蓄積
  • スプリントレビュー時・マイルストーン終了時など、定期的に企画・要求層／設計層へ統合
  • 未着手アイデアは バックログ で管理し、優先順位と着手順序を可視化
  • 向き: 個人開発、スタートアップ、不確実性の高い新規案件

ドキュメント階層（軽量から正式まで）​

開発スタイルに関わらず、記録の重さに応じて書式を使い分ける。軽い書式で素早く残し、必要に応じて重い書式へ昇格させる。sddp は以下の7階層を想定する:

  • メモ（当該文書内 AsciiDoc コメント //// // ／ 90_design-docs/）— 自分用注釈・作業中メモ、PDF/HTML 出力対象外
  • Design Doc（90_design-docs/）— 議論プロセス・暫定方針の記録（未決OK）
  • ADR 軽量版（80_adr/）— MADR ミニマル版で小さな判断を記録
  • ADR 詳細版（80_adr/）— MADR v4.0 フル版で重要な判断を構造化
  • AI作業指示層（cc-sdd の場合は .kiro/specs/ 等、使用ツールにより異なる）— 機能単位の要件→設計→タスク→実装ドラフト。使い捨て可能で、知見は設計層（40_skeleton / 50_detail-design）に蒸留して永続化
  • 正式文書（10_planning / 30_architecture / 40_skeleton / 50_detail-design / 60_tests / 70_ops）— AsciiDoc構造化、PRレビュー必須
note

ADR（Architectural Decision Record）は意思決定記録という概念・用途。MADR（Markdown Any Decision Records）はその代表的な書式で、2026年現在の業界標準（v4.0）。

記述量・書式テンプレ・レビュー基準等の詳細は [26P-BD-00010: SDD-P文書規約](../skeleton/26P-BD-00010 document-standard.adoc) のドキュメント階層節を参照。

Spec の推奨構造​

AI作業指示層の文書を設計層へ蒸留するには、機能単位で要件と設計を分けた構造で記録することを推奨する。

  • 要件（何をするか）— 受け入れ基準・スコープ・対象ユーザーを記述する
  • 設計（どうするか）— インターフェース定義・型・コンポーネント構成を記述する

この構造を持つ文書は、使用するツールや言語を問わず /sddp-distill-spec スキルで設計層へ自動昇格できる。この構造を持たない場合でも SDD-P は利用できるが、設計層への蒸留は手動になる。

2つのスタイルと書式の関係​

両スタイルの違いは、ドキュメント階層をどう辿るかにある:

  • ウォーターフォール型: 正式文書を先に作り、ADR は変更点の記録として補助的に使う。設計の複雑さが高い場合は Design Doc（DN）で設計思考を整理する（任意）。AI作業指示層は詳細化・実装の作業ドラフトとして使用
  • アジャイル型: メモ → ADR → AI作業指示層 → 正式文書（設計層に蒸留） と熟成させ、事後に正本を結晶化する。設計の複雑さが高い場合は Design Doc（DN）で設計思考を整理する（任意）

どちらのスタイルでも、最終的に正式文書として残す のが sddp の責務である。開発スタイルは時期やフェーズに応じて切り替えてもよい（例: 初期はアジャイル型で回し、要件が固まった段階でウォーターフォール型に移行）。

KPI・測定指標​

主要指標​

各指標は解決したい課題に対応する。カテゴリ別に価値の実現度を追跡する。

カテゴリ指標名対応課題目標値達成状況
開発速度sddp init 実行時間（フレームワーク構築時間）1-140分 → 数分✅ 達成
整合性Spec Drift 自動検出カバレッジ2-1全層カバー🟡 進行中
追跡性主要判断のADR化率2-2, 2-3100%🟡 進行中
実用性ドッグフーディング継続期間-3ヶ月以上✅ 達成
普及外部利用者-1人以上❌ 未達成
note

測定手順・運用ルールの詳細は運用文書に委譲する。

ターゲットユーザー​

ペルソナ​

  • プライマリ: 複数プロジェクトを抱える個人開発者・小規模チーム（5〜10人）で、軽量な仕様駆動開発環境を求めている層
  • セカンダリ: AI仕様駆動開発ツールを使っていてドキュメント階層管理・全体設計の不足に課題を感じている開発者
  • ドッグフーディング対象: 開発者自身（sddp の最優先検証者）

ユーザーストーリー​

  • 個人開発者として、1人で複数プロジェクトを抱えているとき、過去の判断根拠を素早く思い出すために sddp の ADR・steering 機能を使う
  • 小規模チームメンバーとして、引き継ぎや横展開が必要なとき、planning〜ops を一貫したドキュメント階層で共有するために sddp を使う

sddp は開発プロセスを改善するためのツールであり、商用プロダクトではない。OSS として公開し、方法論として発信する。

note

企画・要求層・設計層の文書管理（planning〜skeleton）は組織固有のプロセスに依存するため汎用化が難しい。AI作業指示層（AI仕様駆動開発ツールによる作業指示書ワークフロー）は汎用的に利用可能。

参考資料​

:::tip 外部ファイルの参照例 static/files/ に置いたファイルは /files/ファイル名 でリンクできる。 原本（Word / PDF / Excel）はここに置き、MDX 文書から参照するのが基本運用。 :::

  • サンプル仕様書（PDF）— 開く　／　ダウンロード

  • サンプル仕様書（Word）— 開く　／　ダウンロード

  • [26P-SP-00002: スコープ定義](./26P-SP-00002 scope.adoc)

  • [26P-BD-00001: 技術スタック](../architecture/26P-BD-00001 tech-stack.adoc)

  • [26P-BD-00007: 機能構成表](../skeleton/26P-BD-00007 function-map.adoc)

  • [26P-AD-00002: クロスプラットフォーム配布戦略](../adr/26P-AD-00002 cross-platform-distribution.adoc)

  • [26P-AD-00007: cc-sdd文書形式のAsciiDoc統一](../adr/26P-AD-00007 asciidoc-unification-for-cc-sdd.adoc)

  • [26P-AD-00008: 対応AIツールのClaude限定化](../adr/26P-AD-00008 claude-only-ai-tool.adoc)