GitHub Spec Kit vs Kiro vs Claude Code の SDD ワークフロー

2026年の開発者がSpec-Driven Development（仕様駆動開発）のセットアップを比較する際、通常「どのモデルが最も賢いか」を問うわけではありません。「AIエージェントを、過剰な儀式（セレモニー）で埋め尽くすことなく、どのようにアラインメント（方向性の一致）を保てるか」というワークフローを問うています。

GitHub Spec Kit、AWS Kiro、およびClaude Codeのカスタムワークフローは、すべて同じ広範なアイデア——要件、設計、タスク、実装、検証——を実装していますが、ポータビリティ（移植性）、統合の深さ、そしてどの程度のプロセスを強制するかという点でトレードオフがあります。

まず概念を把握したい場合は、Spec-Driven Developmentとは何か?と、ツールに依存しないSpec-Driven DevelopmentワークフローガイドをApp Architecture文書クラスター内で参照してください。本比較記事は、アシスタントのレビューやワークフローガイドとともに、AI開発者ツールハブに位置づけられています。

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

Spec-Driven Developmentが単なる論文上の練習問題ではなくなったのは、2025年後半のどこかからでした。主要なAIコーディングベンダーはすべて、specify-plan-implement（仕様作成-計画-実装）の何らかのバージョンをリリースしており、このループの周りにどの程度の構造を追加するかで競うスタンドアロンツールのリストも増加しています。

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

SDDセットアップの比較方法

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

ポータビリティ – 仕様がリポジトリ内のプレーンなMarkdownとして存在し、来四半期に好むエージェントで動作するか？ それとも、あるIDE、あるクラウド、またはあるプロプライエタリ形式に縛られているか？

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

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

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

レビューチェックポイント – specify、plan、tasks、implementの間には、自然な人間のゲート（確認点）があるか？ レビューのないSDDは、単に遅いVibe Coding（直感コーディング）に過ぎません。

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

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

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

GitHub Spec Kit

GitHub Spec Kitは、リポジトリに仕様駆動ループのスキャフォールディングを行い、実行をすでに使用中のコーディングエージェントに委ねるオープンソースのCLIツールキットです。specify CLIは、テンプレート、スラッシュコマンド、および慣習的なフォルダレイアウトを配置します。典型的なコマンドは、constitution-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の主なセールスポイントです。要件、設計、タスクは、コードの横にある一次UIオブジェクトであり、別のCLI経由で管理するファイルではありません。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機構に統合したので、持続可能なパターンは、必要に応じて読み込まれる、specify-plan-implementチェックリストを定義するSKILL.md（または同等のもの）です。

このアプローチは最も軽量で、最もハックしやすいです。Kiro様の3ファイルレイアウトを移植し、Spec Kitのフェーズをスラッシュコマンドでミラーリングしたり、単一のリポジトリに合った最小限のワークフローを発明したりできます。Claude Codeは、常時有効なプロジェクトコンテキストのためにCLAUDE.mdを読み取り、タスクがマッチしたときにスキルを引き出します。この段階的開示により、全プロンプトで完全な憲章を読み込まずに、セッションを集中させることができます。

欠点は規律です。自分がそれらのゲートを構築しない限り、clarifyやレビューゲートを強制するものはありません。「Claude Code内のspec-driven development」に関するRedditやHacker Newsのスレッドには、誰かのスキルをコピーして一度実行し、そのスキルが遅く感じたときに非構造化のプロンプティングに戻った開発者で溢れています。Claude Code SDDは、スキルをコードのように——バージョン管理され、レビューされ、メンテナンスされる——扱う場合に機能し、一度きりのプロンプトダウンロードのように扱う場合には機能しません。

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

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

そのスキルスタックの手動構築が、上記の表が警告しているようなまさにその規律の問題に聞こえる場合、Superpowersは一見の価値があります。これは、ブレインストーミング、writing-plans、subagent-driven-development、test-driven-development、requesting-code-review、およびいくつかのサポートスキルを含むオープンソースのスキルパッケージであり、ゼロから書くものではなく、インストール可能なプラグインとして配布されています。これは「品質は完全に著者の規律に依存する」という制約に直接対処します：スキルは自動的にトリガーされ、エージェントがスキップできる任意の提案ではなく、必須のワークフローとして意図されています。

強制されるワークフローは、Spec-Driven Developmentワークフロー: 要件からコードへでカバーされる5フェーズのループに密接にマッピングされています：ブレインストーミングは曖昧なアイデアをレビュー済みの設計文書に精錬し、writing-plansはそれを小さな検証可能なタスクに分割し、subagent-driven-developmentは2段階のレビュー付きでタスクごとに新しいサブエージェントをディスパッチし、test-driven-developmentは完了とみなされる前に厳格なレッド-グリーン-リファクタを強制します。最後の部分は、ほとんどの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を望むわけではありません。2026年の比較では、常に2つの代替手段が現れます。

OpenSpec（Fission AI）は、Spec Kitよりも少ない生成ファイルを持つ変更中心のアプローチを採用しています。コミュニティベンチマークは、比較可能なタスクで実質的に低いトークン使用量を報告しており、コストは事前の構造が少ないことです。OpenSpecは、既存のコードベースを変更し、800行の計画フェーズなしでレビュー可能な仕様を望む場合に勝ちやすいです。IDE統合でKiroと競うよりも、ポータビリティでSpec Kitと競います。

BMAD-METHOD（コミュニティ）は、反対方向に押します——プロダクトオーナー、アーキテクト、開発者、レビュアーのペルソナをシミュレートするマルチエージェント、ロールベースのワークフローです。BMADは、明示的なロール分離が役立つ大規模なグリーフィールド努力では強力になりえます。しかし、それは重いです。チームは頻繁に、儀式が報われるのは調整の痛みがすでに急性の場合のみだと報告しています。

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

Spec Kittyおよびその他のコミュニティスキャフォールドは、重量においてOpenSpecとSpec Kitの間に位置します。GitHubツールチェーン全体を採用せずにテンプレートが欲しい場合、注目に値します。

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

どの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成果物の代替ではなく、それらと補完的なものです。

実用的な意思決定表

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

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

すべてのセットアップを越えて移動するプラクティスは、退屈ですが効果的です。仕様は、一度の座席でレビューできるほど小さく保つ。非ゴール（やらないこと）を明示的に書く。タスクは、人間が読めるdiffに分割する。マージ前に受け入れ基準に対して検証する。実装がより良いパスを発見したときに仕様を更新する。

特定の機能について、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ワークフローリファレンス
• Superpowers Quickstart: Install, Workflow, and Tryout – Claude Code、Cursor、Codex、および他のエージェント間でブレインストーミングからTDDまでのメソドロジーを強制するオープンソーススキルパッケージ
• Martin Fowler on SDD tools – Kiro、Spec Kit、Tesslの分析