GitHub Spec Kit、Kiro、およびClaude CodeのSDDワークフローの比較

2026年にSpec-Driven Development（SDD）のセットアップを比較する開発者は、どのモデルが最も賢いかを問うことは通常ありません。彼らが問うのは、AIエージェントを整合的に保ちつつ、過度な儀式（ceremony）に埋もれさせないワークフローは何かということです。

GitHub Spec Kit、AWS Kiro、およびClaude Codeのカスタムワークフローは、すべて同じ広範なアイデア、つまり要件定義、設計、タスク分割、実装、検証を実装していますが、ポータビリティ、統合の深さ、および強制するプロセスの量においてトレードオフがあります。

まず概念を理解する必要がある場合は、App Architecture ドキュメントクラスターの、What Is Spec-Driven Development? およびツール中立の Spec-Driven Development Workflow ガイドをお読みください。本比較記事は、アシスタントのレビューやワークフローガイドと共に、AI Developer Tools ハブに位置しています。ここでは、Hacker NewsやRedditのようなフォーラムで最も議論される3つのセットアップ、およびそれらを巡る軽量および重量級の代替案について概説します。

SDDはツールカテゴリになりつつある

2025年後半には、Spec-Driven Development（SDD）はもはや紙の上の演習ではなくなりました。主要なAIコーディングベンダーのすべてが何らかのバージョンの「指定-計画-実装」を提供しており、そのループ周りにどの程度の構造を追加するかを競うスタンドアロンツールも増えています。

重要なのは「どのツールが勝つか」という比較ではありません。プロセスの深さとポータビリティのトレードオフです。Kiroは統合されています。Spec Kitはポータブルです。Claude Codeのワークフローはハック可能です。悪いスペックは、どのラッパーを選んでもすべてのエージェントを悪化させます。良いスペックはツール間で移植可能です。

SDDセットアップを比較する方法

ツールを選ぶ前に、何に対処最適化するかを明確にしてください。チームの規模、コードベースの古さ、必要なレビューの量に応じて、同じ機能もあるセットアップでは楽に感じられ、別のセットアップでは官僚的に感じられることがあります。

ポータビリティ – スペックはリポジトリ内のプレーンなMarkdownとして保存され、次の四半期に好むエージェントと連携できますか？ それとも、特定のIDE、クラウド、または独自形式に縛られていますか？

セットアップの摩擦 – 「SDDを試してみたい」という思いから、機能する「指定-計画-タスク」ループが構築されるまでどのくらいかかりますか？ CLIスキャフォールディング、IDEのインストール、または独自のスラッシュコマンドの作成は、それぞれ異なる起動エネルギーが必要です。

スペックの品質 – ツールは正確な要件と受け入れ基準の記述を支援しますか？ それとも単に長い文書を作成するだけですか？ 構造は有用ですが、量だけでは意味がありません。

タスクの実行 – ツールは作業をレビュー可能なスライスにどのように分割しますか？ タスクは並列実行できますか？ 50項目ものタスク爆発に抵抗できますか？

レビューチェックポイント – 指定、計画、タスク、実装の間に人間のゲートはありますか？ レビューのないSDDは、単なる遅いバイブコーディングに過ぎません。

リポジトリのグラウンディング – ワークフローは、計画前にプロジェクトの慣例、decision records、ADRs、AGENTS.md、および既存のコードを読み取りますか？ グラウンディングのないエージェントは、過去の選択の背後にあるレビュー済み意図を見ないため、アーキテクチャを再発明してしまいます。

チームコラボレーション – 複数の人がプルリクエストで同じスペックアーティファクトをレビューできますか？ プロセスを書き直すことなくエージェントを混合できますか？

ロックイン – 6ヶ月後にエディタ、モデル、またはクラウドベンダーを変更した場合、何を失いますか？

GitHub Spec Kit

GitHub Spec Kit は、リポジトリにSDDループのスキャフォールディングを行い、すでに使用しているコーディングエージェントに実行を委ねるオープンソースのCLIツールキットです。specify CLIはテンプレート、スラッシュコマンド、および慣用的なフォルダ構成をドロップします。典型的なコマンドは、アーキテクチャ作業を開始する前に曖昧さを解決するための明示的な「clarify（明確化）」ステップを伴い、憲章-指定-明確化-計画-タスク-実装のシーケンスに従います。

Spec Kitの決定的な優位性はエージェントの独立性です。公式ドキュメントは、Claude Code、GitHub Copilot、Cursor、Gemini CLI、Codex、および他の数十のエージェントと連携するツールとして位置づけています。Markdownで一度だけスペックを書き、コードのようにコミットし、プロセスを書き直すことなく実行器を交換できます。これにより、Spec Kitは単一のベンダーに賭けずにSDDを求めているチームにとってデフォルトの推奨事項となります。

トレードオフは実在します。Spec Kitは巨大なアーティファクトツリー（憲章、スペック、計画、タスク、契約）を生成する可能性があり、マルチセッション機能ではその価値がありますが、小さなCLIの調整には重く感じられます。Hacker Newsの投稿では、そのオーバーヘッドがウォーターフォールの儀式と比較されることがよくあります。また、スペック、タスク、実装が一つのガイド付き画面に共存する完全に統合されたIDEを求めている場合、Spec Kitは弱点になります。それは既存のエディタの上にプロセスをレイヤーするものであり、それを置き換えるものではありません。

Spec Kitは、すでに好みのAIコーディングアシスタント を持っており、その上に標準化されたSDDスキャフォールディングを求めているチームに適しています。グリーンフィールド機能、マルチエージェント環境、エディタのロックインを拒否する人々にとって特に強力です。

AWS Kiro

Kiroは、VS Code / Code OSSフォークを基盤としたAWSのSDD対応IDEです。Spec Kitが既存のスタックにSDDをもたらすのに対し、KiroはSDDが目的構築された環境に値すると仮定します。プロンプトは構造化されたアーティファクトを生成します。典型的にはEARSスタイルの表記によるrequirements.md、design.md、および依存関係順のtasks.mdです。その後、エージェントが本番コードを書きます。

ガイド付き体験がKiroの主な売りです。要件、設計、タスクは、別途CLIで管理するファイルではなく、コードの隣にあるファーストクラスのUIオブジェクトです。Kiroはまた、実装が変更されたときにテスト、ドキュメント、または関連アーティファクトを更新できるイベント駆動の自動化であるAgent Hooksを提供します。この双方向ループは、Spec Kitが箱出しで提供していないものです。Spec Kitのスペックは、人間が更新するまで静的なままです。

コストは、ポータビリティとの統合の深さのトレードオフです。Kiroはそのエディタ内で実行され、AWS Bedrockバックモデルを使用し、階層型プランによるクレジットベースの価格モデルで請求されます。すでにAWSインフラを利用しているエンタープライズチームは、これを許容できるものと見なすことが多いです。しかし、ソロ開発者やマルチエディタチームにはそうかもしれません。Kiroにはまた、新しいIDEに典型的な荒々しい部分があります。拡張機能の互換性、ワークフローの驚き、および「本当に別のエディタが必要ですか？」という通常の問いです。

Kiroは、最もガイドされたSDD体験を求め、スペックネイティブIDEの採用に快適な開発者向けです。エンタープライズチーム、AWS中心の環境、およびツールチェーンを手動で組み立てることなくスペック規律を求めているAmazon Q Developerからの移行者にとって強力なオプションです。現在標準のVS Code で生活し、現在のセットアップを愛している場合、KiroはSpec Kitよりも大きな変更を求めます。

Claude Codeカスタムコマンドとスキル

Claude Codeは、Spec KitやKiroのように単一の公式SDD製品を提供しません。ツール自体に慣れていない場合は、セットアップ、権限、ローカルバックエンドについてはClaude Codeインストールおよび設定ガイド から始めてください。SDDパターン自体は、開発者が維持するカスタムコマンド、スキル、およびリポジトリローカルのMarkdownテンプレートに存在します。Anthropicは古い .claude/commands/*.md ファイルをSkillsメカニズムに統合したため、永続的なパターンは、オンデマンドで読み込まれる指定-計画-実装チェックリストを定義する SKILL.md （または同等物）です。

このアプローチは最も軽量でハックしやすいものです。Kiroスタイルの3ファイル構成を移植したり、スラッシュコマンドでSpec Kitフェーズをミラーリングしたり、または単一のリポジトリに適合する最小限のワークフローを考案したりできます。Claude Codeは常時オンプロジェクトコンテキストのために CLAUDE.md を読み取り、タスクが一致する際にスキルを取得します。このプログレッシブディスクロージャーにより、すべてのプロンプトで完全な憲章を読み込まずにセッションを集中させることができます。

downsideは規律です。自身でゲートを作らない限り、明確化やレビューゲートを通すものを強制するものはありません。「Claude Code内でのスペック駆動型開発」に関するRedditやHacker Newsの投稿は、誰かのスキルをコピーして一度実行し、スキルが遅く感じたときに構造化されていないプロンプティングに戻った開発者で溢れています。Claude Code SDDは、スキルをコードのように扱うときに機能します。つまり、バージョン管理され、レビューされ、維持されるものであり、ワンタイムプロンプトダウンロードではないものです。

本格的な実装のために、Claude Skills and SKILL.md for Developers を読み、明示的なレビューチェックポイントを備えたスキルとしてフェーズをエンコードしてください。Claude Code SDDは、すでにClaude Codeで生活しており、最大限の柔軟性を求め、ワークフローを自身で維持する人にとって正しい選択です。

BMAD、OpenSpec、および他のワークフロー

すべてのチームがSpec KitのアーティファクトツリーやKiro IDEを求めているわけではありません。2026年の比較で絶えず登場する2つの代替案があります。

OpenSpec (Fission AI) は、Spec Kitよりも少ない生成ファイルで変更中心のアプローチを取ります。コミュニティベンチマークは、同等のタスクで実質的に低いトークン使用量を示していますが、その代わりにより少ない事前構造を犠牲にしています。OpenSpecは、既存のコードベースを変更し、800行の計画フェーズなしにレビュー可能なスペックを求めている場合に勝つ傾向があります。それはKiroとのIDE統合よりも、Spec Kitとのポータビリティにおいて競合します。

BMAD-METHOD (コミュニティ) は逆の方向に押し進めます。プロダクトオーナー、アーキテクト、開発者、レビュアーのペルソナをシミュレートするマルチエージェント、役割ベースのワークフローです。BMADは、明示的な役割分離が役立つ大規模なグリーンフィールド努力で強力になる可能性があります。しかし、それは重いです。チームは頻繁に、儀式がすでに深刻な調整の痛みがある場合にのみ価値を生むと報告します。

Tessl はスペックを生成コードの文字通りのソースとして扱い、出力を派生物としてマーキングし、手動編集を discourage します。これは主流ツールの中で最も強力な「スペックとしてソース」の立場ですが、Tesslは依然としてベータであり、グループの中で最も高いプロダクトロックインを伴います。

Spec Kitty および他のコミュニティスキャフォールディングは、重量においてOpenSpecとSpec Kitの間に位置します。完全なGitHubツールチェーンを採用せずにテンプレートを求めている場合、注目すべきです。

それらすべてのパターンは同じです。プロセスは曖昧性が高価なときに役立ちます。プロセスはフィードバック速度が整合性よりも重要であるときに害を及ぼします。ツール重量をハイプではなく、タスクサイズに一致させます。

どのSDDセットアップを使用すべきか？

普遍的な勝者はありません。正しいセットアップは、あなたが誰で、何を構築しており、実際にどの程度の構造を維持するかによって異なります。

ソロ開発者、既存コードベース、小規模機能。 Claude CodeスキルまたはOpenSpecから始めます。短い要件ブロック、最小限のタスクリスト、および1つのレビューチェックポイントを書きます。50行の変更のために完全なSpec Kitツリーをインストールしないでください。

ソロ開発者、グリーンフィールド機能、複数セッション。 Spec Kitまたは適切に維持されたClaude Code SDDスキル。IDEの手助けよりも永続的なアーティファクトが必要です。

小規模チーム、混合エディタ。 Spec Kit。Git内のプレーンMarkdownスペック、プルリクエストでレビューされ、各開発者が好むエージェントによって実行されます。

エンタープライズチーム、AWSネイティブ、コンプライアンス圧力。 Kiro。ガイドされたアーティファクト、要件追跡可能性、およびドキュメントとテストを実装に近づけるフック。

規制環境。 KiroまたはSpec Kit、および独自の検証チェックリスト。コンプライアンスゲートを明示的にエンコードしない限り、Claude Codeスキルだけでは不十分です。ツールは監査証跡を置き換えるものではありません。それらは単に生成を容易にするだけです。

既存コードベース、ブラウンフィールド変更。 OpenSpecまたは軽量なClaude Codeワークフロー。すべてのバグ修正に完全なSpec Kit儀式を行うことは、ウォーターフォールのように感じられます。横断的な機能のために重量級の構造を予約します。

グリーンフィールドプロダクト、多数のエージェント。 Spec Kit。Copilot、Claude Code、およびCursorがすべて同じリポジトリに触れる可能性がある場合、IDEの磨きよりもポータビリティが重要です。

マルチエージェントオーケストレーションを実験しているチームは、エージェント間で役割を分割するパターンについては[SDDアーティファクトの代替ではなく、補完的なものとして]Oh My OpenCode Agents も参照してください。

実用的な意思決定表

実際には何が成功を決定するか

ツール選択は、アーティファクトの品質よりも重要ではありません。曖昧な受け入れ基準を持つKiroの要件ファイルは、雑なClaude Codeプロンプトと同じ漂流を生み出します。50の冗長なタスクリストを持つSpec Kit計画は、どのエージェントが実装してもウォーターフォールのように感じられます。

すべてのセットアップ間で移植されるプラクティスは、退屈ですが効果的です。スペックは一度の席でレビューできるほど小さく保ちます。非目標を明示的に書き出します。タスクは人間が読める差分に分割します。マージ前に受け入れ基準に対して検証します。実装がより良い経路を発見したときにスペックを更新します。

特定の機能に対してSDDと構造化されていないプロンプティングの間でまだ選択している場合は、Spec-Driven Development vs Vibe Coding をお読みください。この記事のツール比較は、機能がそもそもスペックに値すると決定した後にのみ重要になります。

悪いスペックはすべてのエージェントを悪化させます。良いスペックはツール間を移動します。

結論

GitHub Spec Kit、Kiro、およびClaude Codeワークフローは、「セッション間でAIエージェントをどのように整合的に保つか」という同じ問いに対する3つの回答であり、ポータビリティと統合に対する異なる賭けをしています。Spec Kitはリポジトリ内のエージェント非依存Markdownを最適化します。KiroはAWSバックエージェントを持つガイド付きスペックネイティブIDEを最適化します。Claude Codeスキルは、維持される場合にのみ成功するハック可能で軽量なワークフローを最適化します。

手元の機能の曖昧性を除去できる最も浅いセットアップを選択してください。ブログ記事が指示したときではなく、調整の痛みが現れたときに構造を追加します。2026年にSDDから価値を得る開発者は、最も精巧なツールチェーンを持つ人々ではありません。彼らは実装する価値のあるスペックを書く人々です。そして、選択したツールがそれに対して実行することを許します。

有用なリンク

• GitHub Spec Kit documentation – 公式Spec Kitワークフローリファレンス
• Martin Fowler on SDD tools – Kiro、Spec Kit、Tesslの分析