ハポソフトの​​ブログへようこそ

Claude Codeのような​AIコーディングエージェントは​開発速度を​大幅に​向上させますが、​同時に​新たな​課題も​生み出します。​コード自体は​正しく​見えても​要件を​満たしていない、​セッションを​またぐと​コンテキストが​失われる、​大規模な​変更に​よって​設計の​一貫性が​崩れると​いった​問題です。​ 仕様駆動開発​（SDD）は​要件定義、​計画、​タスク化、​実装と​いう​構造を​導入する​ことで、​これらの​課題を​解決します。​AIに​直接プロンプトを​入力するのではなく、​チームが​事前に​要件を​定義し、​明確な​仕様に​基づいて​AIに​実行させる​アプローチです。​ 本記事では​Claude Codeで​利用​可能な​4つの​SDDツールを​比較します： ● CafeKit​（Haposoft）​ ● GitHub Spec Kit ● BMAD-METHOD ● claude-code-spec-workflow 各ツールの​ワークフロー、​強み、​トレードオフ、​そして​特に​B2Bエンタープライズチームに​最適な​シナリオに​ついて​解説します。​ Claude Codeに​おける​仕様駆動開発の​理解 多くの​チームは​Claude Codeを​シンプルな​方法で​使い​始めます。​プロンプトを​書いて​コードを​生成し、​出力を​レビューし、​不足が​あれば​プロンプトを​修正すると​いう​流れです。​これは​小規模な​機能や​独立した​タスクに​おいては​うまく​機能します。​しかし、​プロジェクトが​大型化すると​要件の​追跡が​難しくなり、​実装に​関する​決定事項が​会話の​中に​散らばり、​重要な​コンテキストが​セッション間で​失われやすくなります。​ 仕様駆動開発​（SDD）は​異なる​アプローチを​とります。​プロンプトを​指示の​主な​情報源と​して​扱うのではなく、​仕様を​開発プロセスの​基盤と​して​扱います。​要件、​実装計画、​タスク、​技術的な​決定事項が​開発前に​ドキュメント化される​ことで、​プロジェクトの​ライフサイクル全体を​通じて、​開発者と​AIエージェントの​間に​共通の​「唯一の​真実の​情報源​（Single Source of Truth）」が​生まれます。​ SDDワークフローの​仕組み すべての​フレームワークに​独自の​手法が​ありますが、​ほとんどの​SDDワークフローは​以下の​4つの​コアステージに​従います。​ ステージ 説明 要件定義​（Specify）​ 要件、​ビジネスルール、​受入基準を​定義する​ 計画​（Plan）​ 技術設計と​実装計画を​作成する​ タスク化​（Task）​ 作業を​小さく​実行可能な​タスクに​分解する​ 実装​（Implement）​ 承認された​仕様に​基づいて​コードを​生成・レビューする​ 目的は​ドキュメントを​増やす​ことでは​ありません。​曖昧さを​排除する​ことです。​要件、​計画、​タスクが​すでに​定義されていれば、​Claude Codeは​意図を​解釈する​時間を​減らし、​明確に​定義された​作業の​実行に​集中できます。​これは​複数の​ビジネスルール、​ステークホルダー、​開発イテレーションが​絡む大規模な​機能に​おいて​特に​価値を​発揮します。​ Claude Codeと​SDDの​相性が​良い​理由 AIコーディングエージェントを​利用する​際の​最大の​課題の​一つは​長期的な​一貫性の​維持です。​数日または​数週間かけて​完成させる​機能には​何百もの​要件、​決定事項、​実装の​詳細が​含まれる​場合が​あります。​その​情報の​一部は​プロンプトに、​一部は​ドキュメントに、​そして​一部は​チームメンバー間の​会話の​中に​しか​存在しません。​ SDDは​これらの​決定事項を​構造化された​ワークフローに​統合します。​仕様は​「何を」構築するかを​定義し、​計画は​「どのように」構築するかを​定義し、​タスクは​「次に​何を」実装するかを​定義します。​これに​より、​Claude Codeは​プロンプトの​履歴に​依存するのではなく、​ドキュメント化された​計画に​基づいて​作業できる​ため、​開発プロセスが​より​予測可能で​管理しやすくなります。​ Claude Code向け4つの​SDDツールの​詳細比較 CafeKit​（Haposoft）​ cafekit.haposoft.com CafeKitは​Haposoftが​開発した​オープンソースの​仕様駆動開発​（SDD）​ツールです。​この​フレームワークは​要件定義、​技術設計から​実装、​テスト、​レビューまで、​ソフトウェア開発ライフサイクル全体を​チームに​ガイドします。​本記事で​比較する​他の​SDDツールと​比較して、​CafeKitは​最も​詳細な​フェーズ構造を​提供し、​ドキュメンテーション、​品質管理、​トレーサビリティに​より​重点を​置いています。​ フェーズ​構造：6フェーズ CafeKitは​開発を​6つの​明確な​フェーズに​整理します。​各フェーズは​独自の​成果物を​生み出し、​ワークフローの​次の​ステージへの​インプットと​して​機能します。​ 要件定義 — EARS​（Easy Approach to Requirements Syntax）を​使用して​ビジネス要件を​構造化された​仕様に​変換し、​曖昧さを​排除 設計 — アーキテクチャ、​データベース設計、​API契約、​技術的な​決定事項を​定義 タスク分解 — 設計を、​複雑度の​見積もりを​含む独立して​実行可能な​タスクに​分割 実装 — 設計と​技術的制約に​従って、​各タスクの​コードを​生成 テスト — テスト計画、​テストケースを​作成し、​自動テストを​実行 レビュー — コード品質を​評価し、​仕様との​一貫性を​チェックし、​決定事項を​記録 他の​ツールとの​最大の​違いは​CafeKitが​「テスト」と​「レビュー」を​独立した​フェーズと​して​分離している​点です。​GitHub Spec Kitや​BMADが​これらの​アクティビティを​実装フェーズに​組み込むか、​メインフローの​外に​配置しているのに​対し、​CafeKitは​それらを​必須ステージと​して​扱います。​これは​厳格な​品質管理や​エンタープライズ向けの​テスト・レビュー基準への​準拠が​求められる​プロジェクトに​おいて​特に​価値が​あります。​ 主な​機能 ● 生成される​すべての​成果物​（要件定義書、​設計書、​テスト計画、​レビュー記録）に​対する​ネイティブな​日本語サポート ● フェーズ固有の​テンプレートを​備えた、​Claude Codeに​最適化された​スラッシュコマンドシステム ● コードと​並行して、​エンタープライズ形式の​ドキュメントを​自動生成 ● 実際の​オフショア開発プロジェクトで​検証された​手法に​基づいて​構築 最適な​用途 CafeKitは​小規模から​大規模プロジェクトの​両方で​効果を​発揮します。​特に、​厳格な​ドキュメント要件と​形式的なな​品質管理プロセスを​持つエンタープライズ環境で​強みを​発揮します。​詳細な​フェーズ構造は​明確な​引き継ぎが​コミュニケーションの​誤解を​減らす分散チームに​とって​価値が​あります。​各ステージで​正式な​成果物を​必要と​する​組織は​CafeKitが​自社の​ワークフローに​適合していると​感じるでしょう。​ GitHub Spec Kit github.com/github/spec-kit GitHub Spec Kitは​GitHubが​2025年9月に​リリースした​公式の​仕様駆動開発ツールです。​急速に​普及しており、​現在、​デファクトスタンダードの​最有力候補と​なっています。​現在の​バージ​ョンは​0.9.5​（2026年6月上旬時点）です。​GitHubは​これを​実験的な​プロジェクトと​して​位置付けており、​コミュニティの​フィードバックは​賛否両論です。​チームは​その​構造と​予測​可能性を​評価する​一方で、​他の​ツールと​比較して​トークン消費量が​多く、​ワークフローが​遅いと​指摘しています。​ フェーズ​構造：4フェーズ /speckit.specify → /speckit.plan → /speckit.tasks → /speckit.implement 各コマンドは​次の​フェーズに​フィードされる​成果物を​生成します。​ワークフローは​直線的ですが、​修正コマンドを​通じて​イテレーションを​サポートします。​要件定義フェーズで​要件を​キャプチャし、​計画フェーズで​アプローチを​定義し、​タスクフェーズで​作業を​単位に​分解し、​実装フェーズで​コードを​生成します。​ この​構造の​最大の​利点は​シンプルさです。​チームは​4つの​コマンドを​すぐに​学び、​最小限の​学習コストで​ツールを​使い​始められます。​しかし、​シンプルさは​CafeKitの​6フェーズアプローチと​比較して、​より​細かい​制御が​不可能である​ことを​意味します。​ テストと​レビューの​アクティビティは​独立した​フェーズと​して​明示的に​呼び出されていないため、​チームが​メインフローの​外に​独自の​品質ゲートを​構築する​必要が​あるかもしれません。​ 主な​機能 ● 20以上の​AIエージェント​（Claude Code、​GitHub Copilot、​Cursor、​Gemini CLIなど）を​サポートする​エージェント非依存設計 ● 2層の​カスタマイズ：拡張機能​（Extensions）と​プリセット​（Presets）​ ● 機能の​自動ナンバリング、​ブランチ作成、​ディレクトリ構造の​自動生成 ● 品質検証コマンド：/speckit.checklist​（仕様の​品質）と​ /speckit.analyze​（成果物間の​一貫性）​ ● 一時停止と​再開を​サポートする、​マルチステップ自動化に​対応した​YAML定義ワークフロー ● 活発な​OSSコミュニティと​迅速な​機能開発 最適な​用途 GitHub Spec Kitは​グローバルな​英語環境で​新製品を​構築する​チームに​最適です。​複数の​AIコーディングエージェントを​同時に​使用する​組織で​うまく​機能します。​OSSの​トレンドに​従う​スタートアップや​モダンな​SaaS企業は​活発な​コミュニティと​迅速な​開発ペースから​恩恵を​受けます。​最新の​SDDプラクティスに​追従する​ことを​優先する​チームは​この​ツールを​検討すべきです。​ BMAD-METHOD docs.bmad-method.org BMADは​「Breakthrough Method for Agile AI-Driven Development」の​略称で、​アジャイルの​コンテキストの​中で​仕様駆動開発を​再構築する​フレームワークです。​定義上の​特徴は​開発プロセス全体を​通じて​異なる​AIエージェントが​専門的な​役割を​担う​マルチエージェントアーキテクチャです。​この​フレームワークは​最近、​BMAD Method v6の​リリースに​伴い、​.claude/commands から​ .claude/skills に​移行し、​Claude Codeの​ネイティブ実装を​提供しています。​ フェーズ​構造：4フェーズ 分析​（Analysis）​ → 計画​（Planning）​ → ソリューション設計​（Solutioning）​ → 実装​（Implementation）​ 分析フェーズは​ビジネス要件と​ユーザーニーズの​理解に​焦点を​当てます。​計画フェーズでは​エピック、​ストーリー、​スプリント計画を​作成します。​ソリューション設計フェーズは​アーキテクチャと​技術設計を​処理します。​実装フェーズでは​コードの​生成と​テストの​実行を​行います。​ ワークフローを​直線的な​シーケンスと​して​扱う​他の​ツールとは​異なり、​BMADは​マルチエージェントシステムを​通じて​フェーズを​またいだ並列実行を​サポートします。​複数の​専門エージェントが​プロジェクトの​異なる​側面に​対して​同時に​作業できる​ため、​大規模な​チームや​長期的な​プロジェクトに​適しています。​ 主な​機能 ● 明確な​役割を​持つ21の​専門エージェント​（ビジネスアナリスト、​プロダクトマネージャー、​アーキテクト、​開発者、​スクラムマスター、​QA）​ ● 一般的な​開発シナリオを​カバーする​50以上の​ガイド付きワークフロー ● 複数の​AIツール​（Claude Code、​Cursor、​Windsurf、​GitHub Copilot）の​ネイティブ実装 ● スプリント計画、​ストーリー作成、​並列実装の​サポート ● ゲーム開発、​DevOps、​インフラなどの​専門ドメイン向け拡張パック ● スクラムおよび​アジャイル手法との​強力な​親和性 最適な​用途 BMAD-METHODは​役割が​明確に​定義された​アジャイルチーム向けに​設計されています。​要件が​複数の​スプリントに​わたって​進化する​長期プロダクト開発に​最適です。​大規模な​リファクタリングプロジェクトも、​構造化された​エージェントの​協業から​恩恵を​受けます。​専任の​プロダクトオーナーや​アーキテクトを​擁する​チームは​役割ベースの​アプローチを​自然に​活用できるでしょう。​ claude-code-spec-workflow​（Pimzino）​ github.com/Pimzino/claude-code-spec-workflow claude-code-spec-workflowは​個人開発者の​Pimzino氏に​よって​作成された、​軽量で​実用的な​SDDツールです。​現在、​GitHubで​2,544スター、​月間約5,450ダウンロード（バージョン1.5.9）を​記録しています。​この​ツールは​シンプルさを​追求して​設計されており、​ワンコマンドでの​インストールと、​実用的な​日常の​開発ワークフローに​焦点を​当てています。​著者は​現在、​MCPベースの​バージョン​（@pimzino/claude-code-spec-workflow-mcp）​へ​開発の​焦点を​移しており、​現在の​バージ​ョンは​今後の​アップデートが​少なくなる​見込みです。​ フェーズ構造 この​ツールは​作業の​種類に​応じて​2つの​独立した​ワークフローを​提供します。​ 新機能ワークフロー: 要件定義 → 設計 → タスク化 → 実装 バグ修正ワークフロー: 報告 → 分析 → 修正 → 検証 バグ修正ワークフローは​この​ツールの​最も​特徴的な​機能です。​本記事で​比較する​他の​ツールは​バグ修正専用の​フローを​提供しておらず、​新機能の​構築ではなく​イシューの​解決が​主要な​アクティビティである​保守プロジェクトに​特に​適しています。​ 主な​機能 ● ワンコマンドインストール：npx @pimzino/claude-code-spec-workflow ● バグ修正用の​独立した​ワークフロー​（報告 → 分析 → 修正 → 検証）​ ● 仕様全体の​進捗状況を​表示する​リアルタイムダッシュボード ● 最小限の​セットアップで​軽量かつ簡単に​導入可能 ● 実用的な​日常の​開発シナリオに​焦点を​当てた設計 最適な​用途 claude-code-spec-workflowは​バグ修正や​小規模な​機能追加を​中心とした​保守プロジェクトに​最適です。​重い​フレームワークに​コミットする​ことなく​SDDを​試したい​チームに​適しています。​軽量な​代替案を​探している​中小規模の​チームは​簡単に​導入できるでしょう。​グリーンフィールド開発ではなく、​既存の​プロダクトを​主に​扱う​チームは​専用の​バグ修正ワークフローを​高く​評価するはずです。​ 比較まとめ 基準 CafeKit GitHub Spec Kit BMAD-METHOD claude-code-spec-workflow 開発元 Haposoft GitHub公式 BMAD Code Organization 個人OSS (Pimzino) フェーズ数 6​（テスト、​レビューを​分離）​ 4 4 4 日本語サポート ネイティブ プリセットで​対応 限定的 なし 対応AIエージェント Claude Code 20以上​（エージェント非依存）​ Claude Code, Cursor, Windsurf, Copilot Claude Code 学習コスト 低い​ 中程度 高い​ 低い​ カスタマイズ性 中程度 高い​（拡張/プリセット）​ 高い​（21の​エージェント）​ 低い​ 現在の​ステータス アクティブ​（本番環境）​ 実験的​（v0.9.5）​ アクティブ​（v6）​ MCPへ​移行中 最大の​強み エンタープライズプロセス、​ドキュメント エージェント非依存、​標準化 マルチエージェント協業、​アジャイル バグ修正ワークフロー、​軽量 CafeKitは​ドキュメント、​品質管理、​フェーズベースの​デリバリーに​焦点を​当てています。​GitHub Spec Kitは​複数の​AIコーディングエージェントで​機能する​シンプルで​拡張性の​高い​ワークフローを​強調しています。​BMAD-METHODは​専門的な​AIロールを​中心に​構築された​アジャイルファーストの​アプローチを​とり、​claude-code-spec-workflowは​シンプルさと​日常の​実用性を​優先しています。​ 4つの​ツールは​AI支援開発の​基盤と​して​仕様を​使用すると​いう​同じ​コアアイデアを​共有しています。​違いは​どれだけの​構造を​導入するか、​そして​どの​開発課題を​優先するかです。​ほとんどの​チームに​とって、​選択は​機能の​豊富さよりも​ワークフローの​嗜好に​関係します。​最高の​ツールは​通常、​チームが​すでに​ソフトウェアを​計画、​レビュー、​デリバリーしている​方​法に​合致する​ものです。​ どの​ツールを​選ぶべきか？​ 適切な​選択は​プロジェクトの​タイプ、​チーム構成、​開発ワークフローに​よって​異なります。​以下の​表は​各シナリオに​最適な​ツールを​まとめた​ものです。​ シナリオ 推奨ツール 理由 形式な​ドキュメント要件を​持つエンタープライズプロジェクト CafeKit 専用の​テストと​レビューステージを​備えた​構造化された​6フェーズワークフロー グローバルチームに​よる​新製品開発 GitHub Spec Kit 強力な​コミュニティサポート、​エージェント非依存設計、​急速な​エコシステムの​成長 長期プロダクトを​管理する​アジャイルチーム BMAD-METHOD アジャイルおよび​スクラムプラクティスに​合わせた​役割ベースの​ワークフロー 保守プロジェクトおよび​バグ修正中心の​ワークロード claude-code-spec-workflow 専用の​バグ修正ワークフローと​最小限の​セットアップ要件 形式な​ドキュメント要件を​持つエンタープライズプロジェクト 推奨ツール: CafeKit CafeKitの​6フェーズ構造は​各ステージで​正式な​成果物を​必要と​する​エンタープライズの​デリバリープロセスに​適合しています。​要件定義書、​設計仕様書、​テスト計画、​レビュー記録は​オプションの​成果物ではなく、​ワークフローの​一部と​して​扱われます。​規制産業、​大規模な​クライアント、​または​厳格な​品質保証プロセスで​作業する​チームは​この​アプローチから​最も​恩恵を​受けます。​ グローバルチームに​よる​新製品開発 推奨ツール: GitHub Spec Kit GitHub Spec Kitは​分散環境で​新製品を​構築する​チームに​とって​強力な​オプションです。​エージェント非依存の​アーキテクチャは​幅広い​AIコーディングツールを​サポートし、​活発な​オープンソースコミュニティは​ワークフローと​ベストプラクティスを​最新に​保ちます。​モダンな​AI支援開発の​トレンドに​すでに​従っている​チームは​比較的スムーズに​導入できるでしょう。​ 長期プロダクトを​管理する​アジャイルチーム 推奨ツール: BMAD-METHOD BMAD-METHODは​すでに​アジャイルの​役割と​プロセスで​運用している​組織に​自然に​適合します。​この​フレームワークは​専門的な​AIエージェントを​通じて、​スプリント計画、​ストーリー作成、​アーキテクチャ設計、​実装を​サポートします。​これは​複数の​リリースと​進化する​要件に​またがる​プロダクトチームに​特に​有用です。​ 保守プロジェクトおよび​バグ修正中心の​ワークロード 推奨ツール: claude-code-spec-workflow 専用の​バグ修正ワークフローが​ここでの​最大の​差別化要因です。​機能開発プロセスを​保守作業に​適用するのではなく、​チームは​イシュー解決の​ために​特別に​設計された​ワークフローに​従うことができます。​軽量な​セットアップと​低い​学習コストは​小規模な​チームに​とって​実用的な​オプションでもあります。​ 複数の​SDDツールを​併用する​ことは​可能か？​ 仕様駆動開発を​導入するに​あたって、​組織が​単一の​フレームワークに​標準化する​必要は​ありません。​実際には​異なる​チームが​異なる​要件、​ワークフロー、​プロジェクトタイプを​持つことが​よく​あります。​新製品チームで​うまく​機能する​ツールが、​保守チームや​エンタープライズデリバリープロジェクトに​最適とは​限りません。​ 一般的な​アプローチは​組織全体で​単一の​標準を​強制するのではなく、​プロジェクトの​特性に​基づいて​ツールを​選択する​ことです。​例えば、​形式な​ドキュメント要件を​持つエンタープライズクライアントの​プロジェクトは​CafeKitの​構造化された​ワークフローから​恩恵を​受けるかもしれません。​新しい​アプリケーションを​構築する​プロダクトチームは​活発な​エコシステムと​エージェント非依存設計の​ため、​GitHub Spec Kitを​好むかもしれません。​主に​保守と​バグ修正に​注力する​チームは​専用の​バグ修正ワークフローに​より、​claude-code-spec-workflowが​より​実用的だと​感じるかもしれません。​ 良い​ニュースは​これらの​ツールが​相互に​排他的ではないと​いう​ことです。​ほとんどは​Claude Code内の​コマンドベースの​ワークフローと​して​機能し、​同じ​エンジニアリング組織内で​共存できます。​これに​より、​チームは​プロジェクトの​ニーズに​最も​適した​ワークフローを​採用しつつ、​使い​慣れた​AI開発環境を​使い続ける​ことができます。​ 目標は​最も​機能豊富な​フレームワークを​選ぶことでは​ありません。​目標は​チームが​より​一貫して​ソフトウェアを​デリバリーするのに​役立つワークフローを​選ぶことです。​多くの​組織に​とって、​それは​異なる​種類の​作業に​異なる​SDDツールを​使用する​ことを​含むかもしれません。​ まとめ 仕様駆動開発は​2025年後半以降、​大きく​成熟しました。​GitHub Spec Kitは​標準化と​マルチエージェントサポートで​リードしています。​BMAD-METHODは​アジャイル環境で​卓越しています。​claude-code-spec-workflowは​ユニークな​バグ修正ワークフローを​備えた​軽量な​オプションを​提供します。​CafeKitは​強力な​ドキュメントサポートを​備えた​エンタープライズグレードの​構造を​提供します。​ 最適な​選択は​プロジェクトの​タイプと​チーム構成に​よって​異なります。​ハイブリッドな​環境では​複数の​ツールを​並行して​使用する​ことが​実用的な​戦略です。​ チームで​仕様駆動開発を​試す準備は​できましたか？​ CafeKitから​始めましょう。​オープンソースですぐに​使用できます。​今すぐ​インストールして、​構造化された​AI支援開発を​体験してください。​ bash 1 GitHubリポジトリ → 組織での​SDD導入に​ついて​ご質問は​ありませんか？​お気軽に​お問い​合わせください。​経験に​基づいた​サポートを​ご提供します。​ CafeKitと​Haposoftに​ついて​ CafeKitは​ cafekit.haposoft.com で​ご利用いただけます。​導入サポート、​カスタマイズ、​または​社内トレーニングに​ついては​Haposoftまで​ご連絡ください。​ 株式会社Haposoft ● 本社：ベトナム・ハノイ ● 日本オフィス：Haposoft Japan​（東京都渋谷区恵比寿）​ ● 200名以上の​エンジニア、​ISO 9001:2015 / ISO 27001 認証取得、​AWS Select Tier Partne