GitHub Spec KitとKiroとClaude CodeのSDDワークフロー比較

2026年にSDD（仕様駆動開発）環境を比較する開発者は、通常、最も賢いモデルがどれかではなく、AIエージェントの対話を保ちつつ、彼らを煩雑な手続き（セレモニー）に埋もれさせずに済むワークフローがどれかを問いかけています。

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

まず概念を理解する必要がある場合は、仕様駆動開発とは何ですか？ をお読みください。また、ツール非依存の 仕様駆動開発ワークフロー ガイドは、アプリケーションアーキテクチャ ドキュメントクラスター内にあります。この比較記事は、アシスタントのレビューやワークフローガイドとともに、AI開発ツール ハブ内に位置づけられています。

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

仕様駆動開発（SDD）は、2025年後半のある時点で「論文上の演習」ではなくなりました。主要なAIコーディングベンダーはすべて、specify-plan-implement（仕様定義-計画-実装）の何らかのバージョンを提供しており、そのループ周囲にどれほど構造を加えるかという点で競うスタンドアロンツールのリストが拡大しています。

重要な比較は「どのツールが勝つか」ではありません。プロセスの深さとポータビリティの関係です。Kiroは統合型です。Spec Kitはポータブルです。Claude Codeのワークフローはハック可能です。悪い仕様は、あなたがどのラッパーを選んでもすべてのエージェントを悪くします。良い仕様はツール間で持ち運ぶことができます。

SDD環境の比較方法

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

ポータビリティ – 仕様はリポジトリ内のプレーンMarkdownとして存在し、来四半期に好むエージェントと互換性がありますか？それとも、一つのIDE、一つのクラウド、または一つの専有フォーマットに縛られていますか？

セットアップの摩擦 – 「SDDを試してみたい」から、機能するspecify-plan-tasksループまでの時間はどれくらいですか？CLIスキャフォールディング、IDEインストール、または自前のスラッシュコマンド作成には、それぞれ異なる活性化エネルギー（開始コスト）があります。

仕様の品質 – ツールは正確な要件と受け入れ基準の作成を助けますか、それとも主に長文のドキュメントを生成するだけですか？構造は有用です。量はそうではありません。

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

レビューチェックポイント – specify、plan、tasks、implementの間に自然な人間のゲートがありますか？レビューなしのSDDは、ただ遅いバイブコーディングに過ぎません。

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

チームコラボレーション – 複数の人がプルリクエストで同じ仕様成果物をレビューできますか？プロセスを書き直さずにエージェントを混合できますか？

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

GitHub Spec Kit

GitHub Spec Kit は、リポジトリに仕様駆動ループのスキャフォールディングを行うオープンソースのCLIツールキットであり、実行はすでに使用しているコーディングエージェントに委ねます。specify CLIは、テンプレート、スラッシュコマンド、および慣習的なフォルダレイアウトをドロップします。典型的なコマンドは、憲章-specify-clarify-plan-tasks-implementのシーケンスをたどりますが、アーキテクチャ作業を開始する前に曖昧性を解決するための明示的なclarifyステップが含まれています。

Spec Kitの決定的な利점은エージェント非依存性です。公式ドキュメントは、Claude Code、GitHub Copilot、Cursor、Gemini CLI、Codex、および多数の他のエージェントと互換性のあるツールとして位置づけています。仕様は一度Markdownで書き、コードのようにコミットし、プロセスを書き直すことなく実行エンジンを交換できます。これは、単一のベンダーに賭けずにSDDを行いたいチームにとってのデフォルトの推奨事項です。

トレードオフは現実的なものです。Spec Kitは、憲章、仕様、計画、タスク、契約などの大規模な成果物ツリーを生成することがあります。これはマルチセッションの機能では報われますが、小さなCLIの変更には重く感じられます。Hacker Newsのスレッドでは、そのオーバーヘッドがウォーターフォールのセレモニーと比較されることが定期的にあります。また、仕様、タスク、実装が一つのガイド付きサーフェスで統合された完全統合IDEを求めている場合、Spec Kitは弱いです。それは既存のエディタの上にプロセスをレイヤリングするだけで、エディタを置き換えるものではありません。

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

AWS Kiro

KiroはAWSによる仕様駆動IDEで、VS Code / Code OSSのフォークの上に構築されています。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 ファイルをスキル機構に統合したため、持続可能なパターンは、オンデマンドで読み込まれる、specify-plan-implementチェックリストを定義する SKILL.md（または同等物）です。

このアプローチは、最も軽量で、最もハックしやすいです。Kiroスタイルの3ファイルレイアウトを移植したり、Spec Kitのフェーズをスラッシュコマンドでミラーリングしたり、1つのリポジトリに合う最小限のワークフローを考案したりできます。Claude Codeは常時オンのプロジェクトコンテキストのために CLAUDE.md を読み、タスクが一致したときにスキルを引き出します。この段階的な開示により、すべてのプロンプトで完全な憲章を読み込むことなく、セッションを焦点化したままに保ちます。

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

本格的な実装のために、開発者向けClaude SkillsとSKILL.md をお読みください。フェーズをスキルとしてエンコードし、明示的なレビューチェックポイントを含めてください。Claude Code SDDは、すでにClaude Code内で活動しており、最大限の柔軟性を求め、ワークフローを自分で維持する準備ができている場合に正しい選択です。特にレビューゲートステップについては、Claude Codeサブエージェント が、タスクのマージ前に生成されたコードに対して独立した、分離コンテキストのレビューパスを実行できます – これは、KiroのAgent Hooksがネイティブで提供する検証ロールの軽量な代替です。

Superpowers: DIYスキルスタックのパッケージ化バージョン

そのスキルスタックの手作業が、上記のテーブルが警告しているまさにその規律の問題に聞こえるなら、Superpowers は見る価値があります。これは、ブレインストーミング、プランニング、サブエージェント駆動開発、テスト駆動開発、コードレビューのリクエスト、およびいくつかのサポートスキルを含むオープンソースのスキルパッケージであり、ゼロから書くものではなく、インストール可能なプラグインとして配布されています。これは「品質は完全に著者の規律に依存する」という制限に直接対処します：スキルは自動的にトリガーされ、オプションのエージェントがスキップできる提案ではなく、必須のワークフローとして意図されています。

強制するワークフローは、要件からコードへの仕様駆動開発ワークフロー でカバーされる5フェーズループに密接にマッピングします：ブレインストーミングは粗いアイデアをレビュー済みの設計文書に洗練し、プランニングは小さな検証可能なタスクに分割し、サブエージェント駆動開発は各タスクに対して2段階のレビューを伴う新しいサブエージェントをディスパッチし、テスト駆動開発は完成と見なされる前に厳密な赤-緑-リファクタを強制します。最後の部分は、ほとんどのClaude Code SDDスキルが気にするより厳格です – Superpowersは、失敗するテストが存在する前に書かれたコードを明示的に削除します。

自分自身で書くリポジトリローカルのスキルとは異なり、SuperpowersはClaude Code専用ではありません。Claude Code、Cursor、Codex、Gemini CLI、GitHub Copilot CLI、Devin、Factory Droid、および他のいくつかのエージェント向けのプラグインマニフェストを提供するため、同じ方法論は一つの .claude/skills/ フォルダに住むのではなく、ハーネス間であなたについて移動します。これは、自分のClaude Codeスキルを作るのと、Kiroのようなより重い、IDE専用のツールを採用するとの間の中間点です：エディタを手放したり、単一のベンダーの仕様フォーマットにコミットしたりせずに、主観的で強制されたループを手に入れられます。

Superpowersは、原理的にはClaude Codeのスキルアプローチが好きですが、レビューゲートを強制するものがないために無構造のプロンプティングにスライドし続けてしまう開発者に適しています。すでにスタックに調整されたプロジェクト固有のSDDスキルを持っている場合、より弱いフィットです – その場合、カスタマイズの小さな量を強制セレモニーの大きな量と交換することになります。

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

すべてのチームがSpec Kitの成果物ツリーやKiro IDEを求めているわけではありません。2つの代替案が2026年の比較で頻繁に登場します。

OpenSpec (Fission AI) は、Spec Kitよりも生成ファイルが少ない、変更中心のアプローチを取ります。コミュニティのベンチマークは、同程度のタスクに対して実質的に低いトークン使用量を報告していますが、引き換えに事前の構造が少なくなります。OpenSpecは、既存のコードベースを変更しており、800行の計画フェーズなしでレビュー可能な仕様を求めている場合に勝つ傾向があります。KiroのIDE統合よりも、Spec Kitのポータビリティと競争します。インストール手順、explore-propose-apply-archiveループ、およびRedditで最も顕著な落とし穴については、OpenSpecクイックスタート をご覧ください。

BMAD-METHOD（コミュニティ）は逆方向にプッシュします – プロダクトオーナー、アーキテクト、開発者、レビュアーのペルソナをシミュレートする、マルチエージェント、役割ベースのワークフローです。BMADは、明示的な役割分離が役立つ大規模なグリーンフィールドの取り組みでは強力かもしれません。しかし、重いのも事実です。チームは頻繁に、セレモニーが報われるのは、調整の痛みがすでに深刻な場合のみだと報告しています。

Tessl は、仕様を生成コードの直感的なソースとして扱い、出力を派生ものとマークし、手動編集を抑制します。これは主流ツールの中で最強の「仕様をソースとする」立場ですが、Tesslは依然としてベータ版であり、グループの中で最も高い製品ロックインを伴います。

Spec Kitty や他のコミュニティスキャフォールドは、重さにおいてOpenSpecとSpec Kitの間に位置します。完全なGitHubツールチェーンを採用せずにテンプレートを求めている場合、注目する価値があります。

gstack は、仕様レイヤーのさらに一歩先に行きます：コーディングエージェントを完全な仮想エンジニアリングチーム – プロダクトレビュー、アーキテクチャおよび設計レビュー、ブラウザQA、セキュリティ監査、およびリリース-デプロイリリースチェーン – でラップします。これにより、仕様は骨格ではなく、強制される複数の段階の一つになります。これはClaude Codeと他の9つのエージェントで動作し、ガイドは、Spec Kit（またはOpenSpec）に計画の骨格を所有させ、gstackが仕様ツールが強制しないレイヤーを提供する方法をカバーしています。

それらすべてに共通するパターンは同じです。曖昧性が高コストな場合、より多くのプロセスが助けになります。フィードバック速度が整より重要である場合、より多くのプロセスが害になります。ツールの重さは、ハイプではなく、タスクのサイズに合わせます。

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

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

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

Claude Codeのスキルアプローチを望むが、自分のレビューゲートを常にスキップしてしまう。 カスタムスキルをゼロから書く代わりに、Superpowersをインストールしてください。その日のあなたの規律に依存しない、強制されたブレインストーミング-計画-実装-レビューループのために、プロジェクト固有のチューニングのいくつかを犠牲にします。

ソロ開発者、グリーンフィールド機能、複数セッション。 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の磨きよりもポータビリティが重要になります。

マルチエージェントオーケストレーションを実験しているチームは、エージェント間で役割を分割するパターンについて、Oh My OpenCode Agents も見るべきです – SDD成果物への置き換えではなく、それと相補的なものです。チームがIDE統合ではなくターミナルファーストのエージェントを実行している場合、OpenCode CLI実践ガイド は、同じ計画-実装前の規律のより軽量な、プロンプトレベルのバージョンを示しています – 完全なSpec Kitツリーがタスクが許容するセレモニーよりも多い場合に有用です。

実用的な意思決定テーブル

何が実際に成功を決めるか

ツール選択は、成果物の品質ほど重要ではありません。曖昧な受け入れ基準を持つKiroの要件ファイルは、雑なClaude Codeプロンプトと同じくらいの乖離を生みます。50の冗長なタスクを列挙するSpec Kitの計画は、どのエージェントが実装してもウォーターフォールのようになります。

すべてのセットアップで持ち運べる実践は、退屈ですが効果的です。仕様は1回の座席でレビューできるほど小さく保つ。非目標を明示的に書く。タスクを人間が読める差分に分割する。マージ前に受け入れ基準に対して検証する。実装がより良いパスを発見したときに仕様を更新する。

特定の機能についてSDDと無構造のプロンプティングのどちらを選ぶべきかまだ迷っている場合、仕様駆動開発 vs バイブコーディング をお読みください。この記事のツール比較は、機能が仕様を値打ちとするかどうかを決定した後にのみ意味があります。

悪い仕様はすべてのエージェントを悪くします。良い仕様はツール間で持ち運ぶことができます。

結論

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

対象の機能について曖昧性を除去するのに十分な、最も浅いセットアップを選定してください。ブログ記事があなたにそう言ったからではなく、調整の痛みが現れたときに構造を追加してください。2026年にSDDから価値を得る開発者は、最も洗練されたツールチェーンを持つ者ではありません。彼らは、実装する価値のある仕様を書く – そして、選んだツールがそれに対して実行させる者です。

関連リンク

• GitHub Spec Kitドキュメント – 公式Spec Kitワークフローリファレンス
• Superpowers クイックスタート：インストール、ワークフロー、試行 – Claude Code、Cursor、Codex、および他のエージェント間でブレインストーミングからTDDまでの方論を強制するオープンソーススキルパッケージ
• gstack：主観的なAIソフトウェアエンジニアリングスタック – 完全な仮想エンジニアリングチームのオプション、およびそれがSpec Kit、OpenSpec、Superpowersとどのように結合するか
• Martin FowlerによるSDDツールについて – Kiro、Spec Kit、Tesslの分析