このウィキにあるいくつかのツールは、仕様駆動開発 を実践に移している。すなわち、開発者の依頼とコーディングエージェントによる実装の間に、書かれた仕様が挟まる。ただし、その仕様の位置付け方はツールごとに異なる。このページでは、そのうち 11 個、すなわち GitHub Spec Kit、Agentic SDLC Spec Kit、 Kiro、Tessl、OpenSpec、 Spec Kitty、BMAD（Breakthrough Method for Agile AI-Driven Development）、 Get Shit Done (GSD)、cc-sdd、 Conductor（Gemini CLI 拡張機能）、Spec-Flow を並べて比較する。比較には、この分野についてウィキが持つ 2 つの比較の枠組みを用いる。このページはツール同士がどこで異なるかを記録するものであり、どれを使うべきかは述べない。
ウィキがすでに持つ 2 つの枠組み
ウィキには、これらのツールを比較する 2 つの道具があり、それぞれ異なるツールの部分集合に適用されている。
- Böckeler の実装レベルは スペックファースト、スペックアンカード、スペック・アズ・ソース で説明されており、タスクの後で仕様がどうなるかを問う。スペックファーストでは、仕様は目の前のタスクのために書かれる。スペックアンカードでは、仕様は保持され、機能とともに進化していく。スペック・アズ・ソースでは、人間は仕様だけを編集し、コードには決して手を触れない。彼女はこのレベルを、2025 年後半時点の Kiro、Spec Kit、Tessl に適用した。
- 6 次元プロセス分類法 は、支援フレームワークを 6 つの次元、すなわち仕様・コンテキスト・役割・実行・検証・可搬性について 0 から 2 で採点する。その研究である プロンプトからプロセスへ：AI ソフトウェア開発エージェントを支援するフレームワークのプロセス分類法と比較評価 は、これを 6 つのフレームワークに適用した。そのうち 5 つ、すなわち Spec Kit、OpenSpec、Spec Kitty、BMAD、GSD がこのページに登場する。研究はさらに Spec-Flow も採点しており、これは普及度の低さから牽引力フィルタで除外されていたものを、意図的にサンプル外の事例として扱ったものである。各フレームワークは、単一の評価者が公式ドキュメントに基づいて採点した。研究は、スコアが独立した経験的測定ではなく著者の判断であると述べている。
根拠となるページには、Kiro、Tessl、cc-sdd、Conductor、Agentic SDLC Spec Kit の 6 次元スコアは記録されておらず、Böckeler のレベルも彼女の 3 つ以外のツールには適用されていない。
仕様はコードにとって何か
この軸で、ツール同士の違いは最もはっきりと表れる。
- Tessl はスペック・アズ・ソースの端に位置する。そこでは仕様が開発者の編集する唯一の成果物であり、コードは仕様から再生成される。生成されたコードには
// GENERATED FROM SPEC – DO NOT EDITというマーカーが付く。ドキュメント化されたコマンドには逆方向に働くものもあり、既存のコードから仕様を導き出す。Böckeler は Tessl を、彼女が調べた 3 つのツールのうち、明示的にスペックアンカードを目指し、スペック・アズ・ソースを探っている唯一のツールと読んでいる。 - Spec Kit は、GitHub によって「コードが信頼できる唯一の情報源である」から「意図が信頼できる唯一の情報源である」への転換として提示されている。それでも Böckeler は、仕様ごとにブランチを作ることから、Spec Kit はまだスペックファーストにとどまると読んでいる。
- Kiro は、Böckeler によっておおむねスペックファーストと読まれている。
- cc-sdd は、バージョン 3.0 の README で明確に異なる立場を取る。仕様はシステムの各部分の間の契約であり、コードが引き続き信頼できる唯一の情報源であって、仕様は人間とエージェントが並行して作業できるように境界を明示するものだとする。一方で、その入門ガイドは依然として仕様を、実装後に削除するのではなくコミットして残す生きたドキュメントとして扱っている。
- Conductor は、この問いをプロジェクトの把握がどこに置かれるかという形で捉える。Conductor はその把握を、一時的なチャットログから、永続的でバージョン管理された Markdown ファイルへと移す。名前の付いた成果物は
spec.mdとplan.mdである。そのうえで Automated Review が、新しいコードをこの 2 つのファイルと照らし合わせてチェックする。 - Agentic SDLC Spec Kit は、Spec Kit の仕様・計画・タスクの成果物を引き継いでおり、その
convergeステップはコードベースを仕様・計画・タスクと照らし合わせて評価する。
プロセスの形
| ツール | ドキュメント化されたフロー |
|---|---|
| Kiro | コード生成の前に、要件 → 設計 → タスク |
| Spec Kit | Specify → Plan → Tasks → Implement → Converge。implement と converge は「Converged」になるまで繰り返される。バグ修正とアイデアの評価は、別個のオプトインの入口になっている |
| Agentic SDLC Spec Kit | プロジェクト原則、任意のブレインストーミング、specify、clarify、plan、tasks、analyze、implement、converge。加えて、より軽量な変更提案ルートとセッションベースのルートがある |
| Spec Kitty | spec、plan、tasks、next、review、accept、merge |
| Spec-Flow | spec、plan、tasks、implement、optimize、ship |
| cc-sdd | ステアリング、EARS 形式の要件、設計、タスク分割、実装（コマンド形式）。バージョン 3.0 では、ディスカバリーの入口と長時間の自律的な実装が加わる |
| BMAD | 任意の分析、計画、ソリューション、実装の各フェーズと、小さなタスク向けのクイックフロー。README は、Clarify、Plan、Build and verify のいずれかから入れると説明している |
| OpenSpec | 別々のドキュメントを段階的に作るのではなく、1 つの統合された仕様と、追跡可能な変更提案 |
| GSD | 大まかな依頼を仕様と実行可能なステップに変換する、コマンドと規約の層 |
| Conductor | 機能について議論するにつれて生成されるコンテキスト、仕様、計画と、それに続く実装後の自動レビュー。プラグインとしては、厳密なコマンドの順序ではなく対話を通じて駆動される |
| Tessl | 仕様を編集し、コードはそこから生成・再生成される |
これらのフローの間には、2 つの系譜が記録されている。cc-sdd は、その設計を Kiro の仕様駆動開発に着想を得たものとしており、Kiro の仕様と互換性がある。cc-sdd は、3 つのステアリングドキュメント用のものを含むテンプレートを .kiro/settings/ ツリーの下にインストールする。Kiro 自身は、Steering ファイルを .kiro/steering/ の下に置いている。Agentic SDLC Spec Kit は Spec Kit のフォークであり、Tikal のエンジニアリングチームが保守している。Agentic SDLC Spec Kit は Agentic SDLC 12 Factors を、Spec Kit が提供する SDD プロセスの上に立つ戦略的な層として提示し、自らを開発プロセスから組織的な方法論への移行と位置付けている。
役割、コンテキスト、検証
研究が評価した 5 つのフレームワークと、サンプル外の事例である Spec-Flow の 6 次元スコアは次のとおりである。
| フレームワーク | 仕様 | コンテキスト | 役割 | 実行 | 検証 | 可搬性 | 合計 |
|---|---|---|---|---|---|---|---|
| BMAD | 2 | 2 | 2 | 1 | 2 | 1 | 10 |
| GSD | 1 | 2 | 0 | 1 | 0 | 0 | 4 |
| OpenSpec | 2 | 1 | 0 | 1 | 0 | 2 | 6 |
| Spec Kit | 2 | 1 | 1 | 1 | 1 | 2 | 8 |
| Spec Kitty | 2 | 1 | 1 | 2 | 2 | 1 | 9 |
| Spec-Flow（サンプル外） | 2 | 2 | 2 | 2 | 2 | 1 | 11 |
研究は、6 つのフレームワークの表から、プロセスの深さと可搬性の間の構造的な対立を読み取っている。可搬性で 2 を得たフレームワーク、すなわち Spec Kit と OpenSpec は、役割と検証を犠牲にしている。6 つの中で最も深いプロセスを持つ BMAD は、可搬性と実行を犠牲にしている。コンテキストに最も焦点を当てたフレームワークである GSD は、役割、検証、可搬性で 0 となっている。仕様はほぼすべてのフレームワークで 2 となるため、研究はこれを最も識別力の低い次元として扱う。役割と検証は最も二極化しており、したがって最も識別力が高い。研究は Spec-Flow から別の論点を引き出している。Spec-Flow は調べたフレームワークの中で群を抜いて普及度が低く、しかもプロセスの網羅性が最も高かった。研究はこれを、普及度とプロセスの完全性が直交していること、そして 6 つのフレームワークの集合が最も完全なものではなく最も普及したものであることを示すものと読んでいる。
各ツールは、それぞれ異なる手段でこれらのスコア、あるいはそれに相当する機能に至っている。
- 役割。 BMAD はチームという比喩を文字どおりに受け取る。デフォルトのエージェントは、アナリスト、プロダクトマネージャー、アーキテクト、開発者、UX デザイナー、テクニカルライターであり、各役割が次のフェーズへとつながるワークフローを起動する。Spec-Flow は、バックエンド、フロントエンド、データベースに特化したエージェントの間で作業を分担する。Agentic SDLC Spec Kit の共有ナレッジベースにはペルソナが含まれており、そのバンドルは 1 つのコマンドでチームの役割全体をプロビジョニングする。OpenSpec と GSD はここで 0 となる。
- 実行と隔離。 Spec Kitty は各作業パッケージを Git ワークツリー に隔離し、マージの前にレビューと受け入れを求める。評価された 6 つのフレームワークの中で、実行で 2 を得たのは Spec Kitty だけである。Spec-Flow は、テスト駆動開発を Git ワークツリーと統合している。Agentic SDLC Spec Kit は各機能をそれぞれの Git ワークツリーに隔離でき、タスクを依存グラフとしてオーケストレーションして、ウェーブ単位の並列実行または逐次実行を行い、各タスクを
[SYNC]または[ASYNC]に分類する。cc-sdd v3.0 は、ホストエージェントがネイティブなサブエージェントを持つ場合、各タスクに新しいテストファーストの実装担当と独立したレビュー担当を割り当てる。 - コンテキスト。 GSD は、コンテキストの組み立て、すなわちエージェントが何を、どの順序で、どのような枠付けの下で読むかを、明示的なエンジニアリング作業として扱う。Kiro の Steering ファイルと cc-sdd の steering コマンドは、別の形、すなわちプロダクト、技術、構造を記述するファイルとして、エージェントに常設のプロジェクトコンテキストを与える。Conductor は、プロジェクトのコンテキストをバージョン管理された Markdown ファイルに保持する。Spec-Flow は、自動コンパクションを伴う永続的なドメインメモリをディスク上に保持する。Agentic SDLC Spec Kit は、バージョン管理された
team-ai-directivesナレッジベースをプロジェクト間で同期し、そのlevelupコマンドは完了したセッションを、そのナレッジベースにフィードバックされる記録へと変換する。 - 検証。 Conductor の Automated Review は、コードレビュー、計画への準拠、ガイドラインの遵守、テストスイートの検証、基本的なセキュリティレビューという 5 つのチェックから、1 つの実装後レポートを生成する。指摘事項は High、Medium、Low に格付けされる。Spec-Flow は、段階的な品質ゲート、マルチエージェントによる投票、そしてパフォーマンス、セキュリティ、カバレッジのスキャンを適用する。Agentic SDLC Spec Kit の
convergeは、収束した時点でテストゲート、差分分析、4 本柱の品質評価を実行する。 - 人間によるゲート。 Spec Kit は、各フェーズを次のフェーズが始まる前に人間がレビューするものとして提示しており、そのリポジトリはスキルを一度に 1 つずつ呼び出すよう強く求めている。cc-sdd 自身の要約は、エージェントが仕様を書き、人間がフェーズゲートで契約を承認するというものである。そのガイドは、ツールを学んでいる間は前のフェーズを自動承認するフラグを使わないよう勧めている。Google は Conductor を、AI が労働力を提供し、開発者が自動検証に支えられつつ高レベルのアーキテクチャ上の監督を提供するものとして位置付けている。プラグインとしての Conductor は、プロジェクトのコンテキストをいつ更新するか、完了したタスクをいつチェック済みにするかを自ら判断する。
可搬性とパッケージング
ツールは、それぞれ異なる方法でエージェントに結び付く。
- Spec Kit は、
specify init --integrationによってプロジェクトごとに 1 つのエージェントに結び付けられる。そのプロセスは/speckit-*エージェントスキルとして実行され、一覧にないエージェント向けにgeneric統合も用意されている。 - Agentic SDLC Spec Kit は、フォークのリポジトリから独自の
agentic-sdlc-specify-cliをインストールする。Claude Code、GitHub Copilot、Cursor、Gemini CLI、opencode、Qwen、Codex、Windsurf、Junie を含むさまざまなエージェントを挙げており、統合がスキルモードをサポートする場合には、コマンドをエージェントスキルとしてインストールする。 - OpenSpec は、スラッシュコマンドを通じて数十のコードアシスタントをサポートすると表明している。研究はこれを、OpenSpec をエージェントの上の薄い層として位置付けるものと読んでいる。
- cc-sdd は、8 つのサポート対象エージェントを挙げており、2 つが安定版、6 つがベータ版である。スキルをインストールしても、ホストが完全な自律ループを実行できることは検証されないと注意を促している。
- BMAD は Agent Skills として、あるいは Claude Code や Codex のプラグインとしてインストールでき、さらに選ばれたワークフローを、コーディングツールの外での計画用に Gemini Gems や ChatGPT のカスタム GPT としてパッケージ化している。
- Spec Kitty は複数のエージェントで動作するが、独自のリポジトリ規約と Git ワークツリーに依存する。
- Conductor は Gemini CLI の拡張機能として始まった。2026 年 7 月に Conductor Plugin となり、スキル、ルール、MCP サーバー、フックを同梱して、もはや Gemini CLI に縛られなくなった。Google は、Conductor を利用できるツールとして Antigravity CLI と Claude を挙げている。
- Spec-Flow は主に Claude Code 向けに作られており、Gemini CLI 向けの拡張機能もある。研究がその可搬性を部分的と採点したのはこのためである。
- GSD は Claude Code 向けに作られており、研究はその可搬性を Spec Kit や OpenSpec より限定的だと述べている。
- Kiro は、他のエージェントの上の層ではなく、単体の AI IDE である。
情報源が挙げる注意点
根拠となるページでは、ほとんどのツールにそれぞれの注意点が付いている。これらは情報源が提起する懸念であり、評決ではない。
- Spec Kit: 検証が弱いところでの、成果物と実装の間のずれ。
- OpenSpec: オーバーヘッドの低さは、プロジェクトがより精緻な役割、アーキテクチャ、検証を必要とする場合には不十分かもしれない。
- Spec Kitty: 牽引力がまだ控えめであり、成熟度と普及は未知数である。
- Spec-Flow: 普及度が研究の牽引力の閾値を大きく下回っており、そのために研究の主要な集合から外された。
- BMAD: プロセスのコストと、それを使うのに必要な規律。
- GSD: チームのプロンプト規約への依存と、新しい組織への移行を示唆したリポジトリの不安定さ。
- Kiro: あるハンドブックは、測定に基づかない判断として、直感的だが扱いにくく、単発のタスクに向いていると評している。
- Tessl: スペック・アズ・ソースには、成熟した信頼できるコード生成ツールが必要である。Böckeler は、スペック・アズ・ソースがモデル駆動開発と LLM の双方の欠点を抱え込むことになるのではないかと疑問を呈している。
- cc-sdd: そのガイドは、小さな修正、1 回のやり取りで済むタスク、探索的な作業を、cc-sdd に向かないものとして挙げている。
- Conductor: その機能は測定された結果ではなく Google 自身による説明であり、それらの機能についてバージョン番号も示されていない。
分類法の研究は、この分類法が対象としたフレームワークの大半が独立した学術的評価を経ていないと指摘している。Spec Kit、OpenSpec、BMAD の各ページも、それぞれのフレームワークについてこの点を記録している。これらのフレームワークは活発に開発が続いているため、どちらの分類もスナップショットである。