GitHub CopilotやClaude Code、CursorなどのAIコーディングアシスタントが普及する前、ソフトウェア開発は「コード優先、ドキュメント次之」というモデルに従い、3つの主要な課題に直面していた：
| 課題 | 具体的な表現 | 影響 |
|---|---|---|
| 意図と実装の隔たり | 要件文書が曖昧で変更が頻繁に起こり、コードと文書は長期間乖離していました | コミュニケーションコストが高く、リファクタリングリスクが大きく、メンテナンスが困難でした |
| 協力効率の低さ | チームメンバーが要件を異なる理解しており、統一された「事実の源」が不足していました | 繰り返し作業が多く、衝突が頻繁で、納期が長い |
| 品質保証が遅れる | テストがコーディング後に行われるため、欠陥が遅れて発見され、修正コストが高い | 製品の安定性が低く、ユーザーエクスペリエンスが損なわれる |
AIコーディングツールの普及に伴い、これらの問題がさらに悪化している：AIはコードを迅速に生成できるが、全体のシステムアーキテクチャやビジネスロジックの理解が不足し、「局所的に正しく全体として間違っている」コードを生み出すことが多い；同時に、開発者がAIのヒントに過度に依存するため、コードの品質が不均一になり、保守性が急激に低下する。
規範が開発を牽引する (仕様駆動開発、SDD) は、生成型AIの時代に適した工学的開発に対応する新しいソフトウェア開発手法であり、その核心は技術者がまず簡潔でテスト可能で形式化されたシステム仕様書 (Spec) を定義し、それを人間、チーム、AIの間の「動的な契約」として、開発プロセスの唯一の事実の源とすることです。
SDD は三大革命的な変化をもたらします：
SDD は新たな概念ではなく、伝統的なソフトウェア工学の理論に基づく進化である：
| 比較の観点 | Spec-Kit (GitHub) | OpenSpec | スーパーポワーズ |
|---|---|---|---|
| コアの位置づけ | 「設計図派」：ゼロから始まる完全な計画、0-1プロジェクトに適している | 「庭師派」：既存システムの増分改良、1-nプロジェクトに適している | 「全プロセスエージェント」：要件からデリバリーまでの完全な開発プロセス管理 |
| デザインコンセプト | 「仕様は法則」（固定ルール体系）、門控プロセスと詳細なドキュメントを強調 | 「OPSX 灵活ワークフロー」（段階ではなくアクション）、変更提案を中心に、プロセスがシンプル | 「テスト優先、証拠主導」、システム化された複雑さの低減 |
| 哲学的基盤 | 深い仕様主導、プロセスの完全性と制御性を追求 | 軽量仕様主導、迅速なイテレーションとミニマリズムを追求 | 方法論主導（スキルシステム）、心理学によるAI行動の導きを強調 |
| 適用チーム | 組織が整備され、厳格なプロセス規制が行われる大規模チーム | アジャイルチーム、スタートアップ企業、迅速なイテレーションが必要なプロジェクト | 独立開発者、品質指向チーム、AIエージェントが密集するプロジェクト |
| 比較次元 | Spec-Kit (GitHub) | OpenSpec | スーパーポワーズ |
|---|---|---|---|
| 技術スタック | Python (uv パッケージマネージャー)、CLI ドライバー、複数プラットフォームをサポート | TypeScript (npm)、Web UI+CLI 複数モード、軽量 | Markdown+JavaScript プラグイン、エディタ統合、クロスプラットフォーム |
| コアフロー | 7段階の線形フロー：spec→plan→tasks→実装→検証→文書化→進化 | 3段階のインクリメントフロー：提案→適用→アーカイブ、管理規範のインクリメント | 5 ステップの閉ループプロセス：ブレインストーミング→分離→計画→TDD→レビュー |
| 規範形式 | 構造化マークダウン、複雑なシナリオと制約条件をサポート | ミニマルYAML、変更点に焦点を当て、文書量を最小化 | 自然言語＋テストケース、実行可能性と証拠検証を強調 |
| AI統合 | 15以上のAIコーディングアシスタントを内蔵し、統一インターフェース管理 | ClaudeとCopilotに集中し、軽量級統合を強調 | 深い統合GitHub Copilot、ソクラテス式対話をサポート |
| 変更管理 | 動的憲法メカニズム、バージョン管理を規範化し、完全な审计追跡 | 分離制御、合意主導、リスク制御優先 | マイクロタスク分離、自動コンフリクト解決、迅速ロールバック機構 |
| 学習曲線 | 急な、プロセス意識のあるチームに適している | 緩やかな、迅速に習得できるシナリオに適している | 中程度、テストドライブの理念を理解する必要がある |
異なるシナリオに対して、プロジェクトの種類、チーム規模、規範の複雑さなど、多角的な要因を考慮し、最適なSDDツールを選択することをお勧めします：
| 意思決定の要因 | Spec-Kitを選択 | OpenSpecを選択 | Superpowersを選択 |
|---|---|---|---|
| プロジェクトの種類 | 新規プロジェクト、エンタープライズプロジェクト | インクリメンタル変更、遺留システム | プロトタイプ開発、AI密集型 |
| チーム規模 | 10人以上、跨チーム | 3-10 人、敏捷チーム | 1-3 人、独立開発者 |
| 規範複雑度 | 高 (詳細な制約が必要) | 低 (変更点に焦点を当てる) | 中 (テストケースを強調する) |
| プロセス要件 | 厳格 (ゲートキッピング機構) | 柔軟 (インクリメンタルプロセス) | 自動化 (全プロセス) |
| 学習コスト | 高 (トレーニングが必要) | 低 (迅速に習得) | 中 (テストドライブド開発を理解する) |
Spec-Kit の核心的な革新は、規格を静的ドキュメントから実行可能な開発指示に変えることにある：
Spec-Kit の核心は七段階ゲート開発プロセス、各段階は検証可能なエンジニアリング出力に対応し、要求から実装への強い制約連鎖を形成します。各段階は厳格な順序で実行され、前段階の承認がなければ次段階に進めることはできません。
| 段階番号 | 段階名 | 核心目標 | 出力ファイル | 重要制約 |
|---|---|---|---|---|
| 1 | Constitution | プロジェクトの憲法と技術の赤線を確立 | constitution.md | 禁止事項、承認事項、許容範囲を定義；チームの合意による署名が必要 |
| 2 | 自然言語の要望を形式化された規範に変換 | spec.md | 構造化された意味テンプレートを使用し、曖昧な表現を禁止 | |
| 3 | 曖昧さを解消し、境界と例外を確認 | clarification.md | すべての曖昧な点は製品/アーキテクトによって署名確認される必要がある | |
| 4 | 設計技術的な実現経路とアーキテクチャ選定 | plan.md | には技術スタック、データフロー、依存関係図、リスク評価 | |
| 5 | Tasks | は実行可能で追跡可能な開発タスクに分割される | tasks.md | 各タスクには責任者、見積もり工数、受入基準が紐付けられる |
| 6 | Analyze | 規範の一貫性と変更の影響を検証 | 自動分析レポート | 形式化検証の成功率 ≥95%、影響範囲は視覚化される必要がある |
| 7 | Implement | AIがコードを生成し、レビューを提出 | コードの生成 + テストケース | コードはspec.mdと双方向の追跡を保ち、手動での上書きを禁止 |
すべての段階はspec CLIツールでドライブされ、各段階のデリバリオはバージョン管理に自動的に組み込まれ、审计可能、追跡可能、検証可能なエンジニアリング契約チェーンを形成
任意の段階が門控チェックを通過しなかった場合、システムは次のプロセスをブロックし、「規範が権威である」ことを保証
Spec-Kitはプロジェクト憲法 (Project Constitution) の概念を導入し、プロジェクトの「最高法」として機能：
Spec-Kitの核心的な哲学は規範が唯一の事実源であることです。すべての開発活動は規範を中心に展開されます：
Spec-Kitは、意図を明確にすることを優先し、その後に実装を考えることを強調し、従来の「実装優先」モデルと鮮明な対比を形成します：
Spec-Kitは、開発者とAIの協力モデルを再定義し、「AIによるコーディングの支援」から「規範駆動型AI開発」へと進化させます：
Spec-Kitはモジュラーで拡張可能なアーキテクチャ設計を採用し、核心は4層で、下から上へと順に以下の通り構成されています：
Spec-KitはGitHub公式のオープンソースの规格ドライブ開発（Spec-Driven Development, SDD）ツールキットです。標準化されたワークフロー（Specify → Plan → Tasks → Implement）を通じて、開発者はclaudeやopencodeなどのAIコーディングアシスタントを活用し、高品質なソフトウェアを構築し、「雰囲気コーディング」（Vibe Coding）によるコード品質のばらつきやプロセスの欠如問題を解決するのを支援します。
Spec-Kit は Python で開発されており、パッケージマネージャーおよびツールランナーとして uv を依存関係として使用します。因为它比传统的 pip/venv 更快且更易于管理。
# 安装 uv
curl -LsSf https://astral.sh/uv/install.sh | sh
# 验证安装
uv --version
# 使用 uv 安装 Spec-Kit
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git
# 验证安装
specify --version
既存プロジェクトの初期化：
# 在当前目录初始化
specify init .
# 指定特定的 AI 助手
specify init . --ai opencode
新規プロジェクトの作成と初期化:
# 基本初始化
specify init project01
# 指定特定的 AI 助手
specify init project01 --ai claude
# 指定脚本类型 (Mac/Linux默认sh，Windows默认ps，也可强制指定)
specify init project01 --script sh
初期化プロセス中のインタラクティブなプロンプト：
# 编辑 .gitignore 文件，添加以下内容（根据你使用的 AI 工具调整）
.opencode
.omo
.claude
.specify
specs
初期化が完了したら、あなたのAIコーディングアシスタントを開きます（例えば、ターミナルでopencode、claudeと入力して対応するプログラミングツールを起動するか、VS Code/Cursorでプロジェクトを開きます）。
以下のSlash Commands（スラッシュコマンド）が利用可能か確認してください：
| コマンド | 機能説明 | フェーズ |
|---|---|---|
| /speckit.constitution [必須] | プロジェクトの原則と交渉不可能な基準の確立 | 0. 準備 |
| /speckit.specify [必須] | 「何をするか」と「なぜ」を定義し、仕様文書を生成 | 1. 仕様化 |
| /speckit.clarify | 計画前に質問を通じて曖昧な要件を明確化 | 1.5 明確化 |
| /speckit.plan [必須] | 仕様と技術スタックに基づいて技術実装計画を生成 | 2. 計画 |
| /speckit.tasks [必須] | 計画を実行可能で順序付けられたタスクリストに分割 | 3. タスク分解 |
| /speckit.analyze | タスクの整合性とカバレッジを分析 | 3.5 分析 |
| /speckit.implement [必須] | タスクを実行し、コードとテストを生成 | 4. 实现 |
典型的なワークフロー例：
問題：Specドキュメントの言語とスタイルをどう指定するか？
## Communication Guidelines
- **Language**: All specifications, plans, tasks, code comments, and commit messages MUST be written in **Simplified Chinese (zh-CN); unless explicitly requested otherwise.
- **Tone**: Professional, concise, and direct.
私たちは「XXL-APIプロジェクトコードリファクタリング「例」を通じて、Spec-Kitの完全な実践プロセスを示す。
今回の改造プロジェクトは正式なオープンソースプロジェクトであり、コードの規範性と品質に要求がある。また、このリファクタリング要件は「9つの機能モジュール」、「フロントエンドとバックエンドのコードロジックの変更」を含み、合計130以上のプロジェクトファイルを修正する必要があり、中規模の粒度の要件である。今回の改造要件は一定の複雑さがある。
プロジェクトのルートディレクトリに移動し、以下のコマンドを実行して Spec-Kit 工程契約チェーンを生成します：
specify init .
実行すると、生成されます。.specify契約チェーンファイルディレクトリ：
以下のコマンドを実行して「プロジェクト憲法」（例：プロジェクト契約、技術スタックと制約、開発作業フローなど）を生成し、後続の規範とコード実装の一貫性と制御性を確保します。
# 创建项目宪法
/speckit.constitution
# 创建项目宪法，补充指定中文约束（否则默认生成 英文 内容）
/speckit.constitution 补充1条规则：所有规范文档使用中文描述
実行後、.specify/memory/constitution.md ファイルが生成され、内容は以下の通りです：
以下のコマンドを実行し、機能要件の説明を記入して「機能仕様（Spec）」を生成：
/speckit.specify 针对XXL-API项目按照如下要求重构：
1、按照下面项目规范结构，重构重构项目目录结构：
xxl-api-admin/src/main/java/com/xxl/api/admin
- /framework: 基础框架代码，包含公共的 登录、util、过滤器等组件。
- /business：业务代码，包含具体业务模块的 controller、service、model、mapper 子分层代码。
xxl-api-admin/src/main/resources/templates
- /framework：基础模板，基础框架实体 对应的。
- /business：业务模板，业务领域实体对应的。
xxl-api-admin/src/main/resources/mapper
- /framework：基础Mapper文件，基础框架实体 对应的。
- /business：业务Mapper文件，业务领域实体对应的。
2、业务代码分类判断逻辑：Java代码部分，当前 com/xxl/api/admin/controller/biz 下除了 UserController 都是 业务领域，保留User相关Java代码不变，其他按照规范调整。模板部分，当前 help.ftl、index.ftl、login.ftl 属于基础框架，其他属于业务领域；Mapper部分，当前 XxlApiUserMapper.xml 属于基础框架，其他属于业务部分。
実行後、.specify/specs/001-project-structure-refactor/spec.md ファイルが生成され、内容は以下の通りです：
以下のコマンドを実行して「技術計画」を生成：
/speckit.plan
実行後、.specify/plans/001-project-structure-refactor/plan.md ファイルが生成され、内容は以下の通りです：
以下のコマンドを実行して「タスクリスト」を生成：
/speckit.tasks
実行後、.specify/tasks/001-project-structure-refactor/tasks.mdファイルが生成され、内容は以下の通り：
以下のコマンドを実行して、分割されたタスク（tasks.md）に基づいて「コード生成」を行う：
/speckit.implement
エージェントはタスクリスト（tasks.md）に従って個々のタスクを実装し、各タスクが完了すると自動的にrequirements.mdを照合します。
すべてのタスクが完了した後、人間によるレビューで受入確認を行い、要求事項を満たしたらコードをマージ（現在、このPRはXXL-API masterブランチにマージ済み、期待通りに交付されました）。
constitution.md一旦決定したら頻繁に変更しないようにし、すべての参加者が統一されたルールを遵守することを確保するSPEC.md実装の詳細に過度に制約を設けず、AIに技術的な最適化の余地を残すこれらの段階は返工を減らす鍵であり、曖昧な点や偏りを早期に発見する方が後の修正費用を大幅に削減できる出典元：https://www.xuxueli.com/blog/?blog=ai/speckit
このコンテンツは慣性聚合(RSSリーダー)によって自動集約されています。参考としてご覧ください。 原文出典 — 著作権は原著者に帰属します。