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

2026年にSpec駆動開発（SDD）セットアップを比較している開発者たちは、通常、どのモデルが最も賢いかを尋ねるわけではありません。彼らが求めているのは、AIエージェントをアラインメント（整合状態）に保ち、かつ彼らを繁雑な手順（ceremony）で埋め尽くさないワークフローです。

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

まず概念を把握したい場合は、「Spec駆動開発とは？」および、ツールに依存しない「Spec駆動開発ワークフロー」ガイドを「アプリアーキテクチャ」ドキュメントクラスター内で参照してください。本比較記事は、アシスタントのレビューやワークフローガイドとともに「AI開発ツール」ハブに位置付けられています。

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

Spec駆動開発（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 は、リポジトリにSpec駆動のループをスキャフォールドし、実行をすでに使用しているコーディングエージェントに委譲するオープンソースの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は、VS Code / Code OSSフォークに基づいて構築されたAWSのSpec駆動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体験を望み、SpecネイティブIDEの採用に抵抗がない開発者に向いています。エンタープライズチーム、AWS中心の環境、そしてツールチェーンを手動で組み立てることなくSpecの規律を望みAmazon Q Developerからの移行を検討している人々にとって、強力な選択肢です。もし今日VS Codeで作業し、現在のセットアップを愛しているなら、KiroはSpec Kitよりも大きな切り替えを要求します。

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

Claude Codeは、Spec KitやKiroのような単一の公式SDD製品を shipping していません。ツール自体が初心者の方は、セットアップ、権限、ローカルバックエンドについて「Claude Code インストールと設定ガイド」から始めてください。SDDパターン自体は、開発者がメンテナンスするカスタムコマンド、スキル、およびリポジトリローカルのMarkdownテンプレート内に存在します。Anthropicは、旧来の .claude/commands/*.md ファイルをSkillsメカニズムに統合したため、持続的なパターンは、オンデマンドでロードされるspecify-plan-implementチェックリストを定義する SKILL.md（または同等物）です。

このアプローチは最も軽量で、最もハック可能です。Kiro風の3ファイルレイアウトを移植したり、スラッシュコマンドでSpec Kitのフェーズを鏡写しにしたり、1つのリポジトリに合う最小限のワークフローを発明したりできます。Claude Codeは、常時オンであるプロジェクトコンテキストのために CLAUDE.md を読み取り、タスクがマッチしたときにスキルを取得します。この段階的開示（プログレッシブ・ディスクロージャ）により、全プロンプトで完全な憲章を読み込まずに、セッションに集中を保てます。

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

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

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

そのスキルスタックを手作業で構築することが、上記のテーブルが警告している「品質は完全に作者の規律に依存する」という規律問題そのものに聞こえるなら、Superpowersは一見の価値があります。これは、ブレインストーミング、計画作成（writing-plans）、サブエージェント駆動開発（subagent-driven-development）、テスト駆動開発（test-driven-development）、コードレビュー要求、およびいくつかのサポートスキルからなるオープンソースのスキルパッケージであり、ゼロから書くものではなく、インストール可能なプラグインとして配布されています。これは「品質は完全に作者の纪律に依存する」という限界に直接ターゲットを絞っています：スキルは自動的にトリガーされ、エージェントがスキップできる任意の提案ではなく、必須のワークフローとなることを意図しています。

強制されるワークフローは、「要件からコードへ：Spec駆動開発ワークフロー」でカバーされている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、およびいくつかの他のエージェント向けにプラグインマニフェストを shipping するため、同じメソドロジーは一つの .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と競合します。インストール手順、explore-propose-apply-archive（探索-提案-適用-アーカイブ）ループ、およびRedditで最も顕著になる落とし穴については「OpenSpec クイックスタート」を参照してください。

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

Tessl は、スペックを生成コードのliteralなソースとして扱い、出力を派生物（derived）としてマークし、手動編集を抑制します。これは主流ツールの中で最も強力な「スペックをソースとする（spec-as-source）」立場ですが、Tesslはベータ版であり、グループの中で最も高いプロダクトロックインを持ちます。

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

これらすべてのパターンは同じです。曖昧性が昂贵的な場合、より多くのプロセスは役立ちます。フィードバック速度がアラインメントよりも重要な場合、より多くのプロセスは害になります。ツール重さをバズに合わせてではなく、タスクサイズに合わせてください。

どの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のスキルだけではありません。ツールingは監査証跡（audit trails）の置き換えにはなりません。それらを生成しやすくするだけです。

既存コードベース、ブ라운フィールド変更。 OpenSpecまたは軽量なClaude Codeワークフロー。すべてのバグ修正に完全なSpec Kitの儀式は、ウォーターフォールのように感じます。より重い構造は、横断的な機能のために予約してください。

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

マルチエージェントオーケストレーションを実験しているチームは、エージェント間で役割を分割するためのパターンについて、SDD成果物と補完的なものであり、その置き換えではない「Oh My OpenCode Agents」も見るべきです。もしチームがIDE統合型ではなくターミナル優先のエージェントを使用している場合、[「OpenCode CLI 実践ガイド」](https://www.glukhov.org/ja/ai-devtools/opencode/opencode-cli-in-practice/ “コマンドラインからのOpenCode実践ガイド：opencode run、スクリプティング、CI自動化、エージェント、権限、ローカルモデル、および実際の失敗モード。”})は、同じ実装前の計画という規律のプロンプトレベルの軽量なバージョンを示しています – タスクが値するより多くの儀式である場合、完全なSpec Kitツリーに代わって有用です。

実践的な判断テーブル

実際に成功を決めるもの

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

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

特定の機能のためにSDDと非構造化プロンプティングの間でまだ選択中なら、「Spec駆動開発 vs バイブコーディング」を読んでください。この記事のツール比較は、機能がそもそもスペックに値すると決めた後で初めて重要になります。

悪いスペックはすべてのエージェントを悪くする。良いスペックはツールを跨いで機能する。

結論

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

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

有用なリンク

• GitHub Spec Kit ドキュメント – 公式Spec Kitワークフローリファレンス
• Superpowers クイックスタート：インストール、ワークフロー、および試用 – Claude Code、Cursor、Codex、および他のエージェント間でブレインストーミングからTDDまでのメソドロジーを強制するオープンソースのスキルパッケージ
• Martin FowlerによるSDDツールに関する記事 – Kiro、Spec Kit、およびTesslの分析