2026年のおすすめ仕様駆動開発ツール

この仕様駆動開発ツールの比較では、GitHub Spec Kit、OpenSpec、Kiro、Tessl、BMAD Method、Task Master AI、CodeSpeak、Datarim、プレーンな Markdown、SpecScoreを扱います。公開されているページとリポジトリは 2026年10月30日に読みました。コマンド、ファイルの置き方、製品が何を検査するかは変わり得ます。末尾の出典が、各記述の元になったページを示します。

リポジトリで分かれる点は、仕様そのものが CI で失敗し得るかどうかです。SpecScore のウェブサイトのリポジトリでは、dogfood.yml が SpecScore CLI を導入し、プルリクエストと main へのプッシュで specscore spec lint を実行します。specstudio-skills の /score スキルは、成果物に対する手作業の AI 採点です。呼び出すのは人です。あのワークフローは呼び出しません。

GitHub Spec Kit

GitHub Spec Kit は、コーディングエージェントに手順を渡すオープンなツールキットです。Specify、Plan、Tasks、Implement、Converge と進みます。2026年9月28日付けの Spec Kit ドキュメントのホームは、各段階が Markdown の成果物を作り、次の段階がそれを読む、と述べています。

ファイルは specs/ の下の機能ディレクトリに置きます。2026年10月30日に読んだアップグレードガイドは、specs/001-my-feature/spec.md のようなパスを示し、横に plan.md と tasks.md を置きます。エージェント型 SDD のリファレンスは /speckit.analyze を、ファイルを編集せずに、仕様と計画とタスクのあいだの食い違いを報告するもの、と説明しています。/speckit.clarify と /speckit.checklist は、エージェントの中で実行する別のコマンドです。ドキュメントのホームは、準拠のゲートを足すコミュニティ拡張にも名前を挙げ、その一つが CI Guard です。

ライセンスは MIT で、公開リポジトリは github/spec-kit です。Spec Kit は、その手順が欲しく、仕様はエージェントが書いた Markdown のままでよい、というチームに向きます。SpecScore との並べ方は SpecScore vs Spec Kit にあります。

OpenSpec

Fission-AI の OpenSpec は、変更ごとにフォルダを分け、人とエージェントがコードを書く前に合意できるようにします。2026年10月30日に読んだ README は、openspec/changes/add-dark-mode/ に proposal.md、specs/ ディレクトリ、design.md、tasks.md がある例を示します。要件はプレーンな Markdown です。SHALL の文と、WHEN / THEN のシナリオです。同じ README は、30+ の AI アシスタントに対応する、と述べています。

openspec validate は、変更と仕様の構造上の問題を検査します。2026年10月30日に読んだCLI リファレンスは、検査が失敗したときのゼロ以外の終了と、CI ジョブが実行できるシェルの断片を記しています。この検査が見るのは、OpenSpec の変更と仕様の構造です。

ライセンスは MIT で、リポジトリは Fission-AI/OpenSpec です。OpenSpec は、その変更フォルダと構造の検査が欲しいチームに向きます。SpecScore vs OpenSpec を参照してください。

Kiro

Amazon Web Services（AWS）の Kiro は、エージェント型の開発環境です。エディタ、CLI、ウェブアプリからなります。2026年8月4日に更新された機能仕様のページは、一つの機能を要件、設計、タスクと進めていきます。requirements.md は EARS を使います。design.md と tasks.md がその横にあります。Quick Spec は三つを、あいだに承認で止まらず通せます。

Analyze Requirements は、設計の前に、矛盾、あいまいさ、衝突する制約、抜けを探します。その分析は Kiro の中で動きます。機能仕様のページが、製品内の検査を説明しています。

2026年10月30日に読んだKiro のライセンスは、IDE と CLI が AWS Content として、AWS Customer Agreement または別の書面による合意と、AWS Intellectual Property License の下でライセンスされる、と述べています。Kiro は、その三つのファイルの草案をこの製品に任せる人に向きます。SpecScore vs Kiro を参照してください。文型はEARS要件構文です。

Tessl

2026年10月30日に読んだTessl のドキュメントは、エージェントスキルを扱うオープンなプラットフォームを説明しています。レジストリ、ガバナンス、evals、関連するコントロールです。スキル、ルール、ドキュメントはリポジトリ内のファイルです。

別の成果物である仕様駆動開発のタイルは、tesslio/spec-driven-development-tile から公開され、Tessl のレジストリ に載っています。タイルの README は、エージェントが .spec.md を specs/ ディレクトリに、YAML のフロントマター、targets、[@test] のリンク付きで書く、と述べています。scripts/validate-specs.sh と scripts/check-spec-links.sh、そしてタイル自身を検査する GitHub Actions も記しています。

タイルのライセンスは MIT で、そのリポジトリにあります。ドキュメントはレジストリのプラットフォームを Tessl の製品と説明し、プラットフォーム全体の公開リポジトリは示していません。Tessl は、スキルを揃えるチーム、またはタイルの「コードより先に仕様」という誘導が欲しいチームに向きます。SpecScore vs Tessl を参照してください。

BMAD Method

2026年10月30日に読んだ BMAD Method リポジトリの README は、AI 駆動開発のためのアジャイルな方法を説明しています。方法を端から端まで使うことも、ブリーフ、仕様、アーキテクチャを今あるワークフローへ持ち出すこともできる、と述べています。そこで名指しされている安定ラインは v6.12 です。v7 は main ブランチのプレビューと説明されています。プロジェクトは名前を BMad と綴り、リポジトリは BMAD-METHOD です。

README の中心は、それらの計画の成果物と、それを作るエージェントスキルです。決まった仕様スキーマを CI で検査するコマンドは記していません。

ライセンスは MIT で、リポジトリは bmad-code-org/BMAD-METHOD です。そのライセンスファイルには、BMad の商標に関する注意書きもあります。この方法は、アジャイルの循環が欲しく、仕様をそれらのブリーフと仕様に残すチームに向きます。SpecScore vs BMAD Method を参照してください。

Task Master AI

Task Master AI は、AI のコーディングエージェント向けのタスク一覧です。2026年10月30日に読んだ README は PRD を勧め、置き場所は多くの場合 .taskmaster/docs/prd.txt です。task-master parse-prd がその散文をタスクに変えます。ドキュメントは、タスクの構造、依存関係、タグを扱います。

README は、PRD を入力とし、タスク一覧をエージェントが作業する対象として扱います。PRD の文言や構造を検査するリンターは説明していません。

ライセンスは Commons Clause 付きの MIT で、リポジトリは eyaltoledano/claude-task-master です。README は、Task Master を使って製品を作ることはできる、Task Master そのものを売ることやホストされたサービスとして提供することはその許諾の外だ、と述べています。PRD をタスクに分けたいチームに向きます。SpecScore vs Task Master AI を参照してください。

CodeSpeak

2026年10月30日に読んだ CodeSpeak のサイトは、エージェント型のエンジニアリング・ツールキットを説明しています。エージェントのチャットから意図を取り、その意図をコードに対応づけた構造化要件へ変え、変更のたびにその要件を強制する、と述べています。サイトは、製品全体が出るまでのあいだ、ウェブのツールがチャットから意図を回収する、とも述べています。

2026年3月3日発効の利用規約は、CodeSpeak Ltd がソフトウェアとソースコードを含む Service を保持する、と定めています。製品サイトはそのツールキットのソースリポジトリを公開していないため、このページはそのソフトウェアライセンスを名指ししません。

CodeSpeak は、会話から要件を取り、その製品の中でコードへの対応を保ちたいチームに向きます。SpecScore vs CodeSpeak を参照してください。

Datarim

4.9.0 のバージョンバッジが付き、2026年10月30日に読んだ Datarim の README は、Claude Code、Codex CLI、Cursor、Google Antigravity 向けの反復ワークフローを説明しています。/dr-prd が PRD を生成します。進行中のタスクは backlog.md に、完了した履歴は backlog-archive.md にあります。

/dr-compliance は、そのコマンドを実行したとき、実装を PRD と照合します。/dr-dream lint はナレッジベースを、矛盾、孤立した項目、リンク切れ、古い内容、重複について点検します。これらはワークフローの中のコマンドです。

ライセンスは MIT で、リポジトリは Arcanada-one/datarim です。Datarim は、README が名指しするエージェントで、その段階のあるコマンドが欲しいチームに向きます。SpecScore vs Datarim を参照してください。

プレーンな Markdown

プレーンな Markdown とは、仕様を普通の .md ファイルにすることです。見出しと箇条書きを、コミットする場所に置きます。スキーマはありません。自分で検査を足すまでは、レビューは誰かがファイルを読むことです。

リンクすべき製品もライセンスファイルもありません。ファイルの条件は、リポジトリに適用するライセンスそのものです。プレーンな Markdown は、短いメモ、スパイク、または散文を読んでレビューするチームに向きます。SpecScore vs plain Markdown を参照してください。

SpecScore

SpecScore は仕様のフォーマットです。機能、要件、受け入れ基準を、YAML を伴う Markdown で書き、CLI がファイルを検査します。フォーマットは specscore/specscore にあります。CLI は specscore/specscore-cli にあります。

エージェントが検査できる基準の書き方は、受け入れ基準の書き方にあります。

要件、受け入れ基準、プラン、タスクを含む Markdown の機能仕様テンプレートはMarkdown の PRD テンプレートにあります。

Claude Code と Cursor での仕様駆動開発。機能ファイル、エージェント向け指示ファイル、そしてループの中の specscore spec lint については Claude Code と Cursor での仕様駆動開発。

その linter を継続的インテグレーションで実行する手順はCI で仕様を lint するにあります。

このウェブサイトのリポジトリでは、dogfood.yml がその CLI を導入し、プルリクエストと main へのプッシュで specscore spec lint を実行します。フォーマットを壊した仕様は、そのジョブを失敗させます。/score スキルは手作業の AI 採点です。頼んだときに、設定されたレビュアーを再実行します。dogfood のワークフローはそれを呼びません。

フォーマットのライセンスは CC BY 4.0 で、リポジトリは specscore/specscore です。CLI のライセンスは Apache-2.0 で、リポジトリは specscore/specscore-cli です。SpecScore は、見出し、リンク、ステータスが誤っているときに仕様を CI で失敗させたいチームに向きます。ファイルを書いたエージェントは問いません。openspec validate は、ここにある他のツールのうち、構造の検査として最も近いものです。検査するのは OpenSpec 自身の変更の形です。個別の比較は /vs/ から始まります。

選び方。

手順が案内され、プルリクエストでレビューできる Markdown が欲しいなら、GitHub Spec Kit、OpenSpec、BMAD Method、Datarim を選んでください。EARS の要件の草案をその製品に書かせるなら Kiro です。PRD をタスク一覧にしたいなら Task Master AI です。意図をその製品の中でチャットから取りたいなら CodeSpeak です。課題がエージェントスキルなら Tessl で、仕様のタイルは任意の誘導です。

仕様ファイルそのものが CI で失敗しなければならないなら、SpecScore を選んでください。このリポジトリの検査は、dogfood.yml の中の specscore spec lint です。上の一覧にあるワークフローは、仕様を書く手順として併用できます。

出典。

ページ自身が更新日を掲げている場合を除き、2026年10月30日に読みました。価格とプラン名は動くため、ここには書いていません。

• GitHub Spec Kit ドキュメント（ページの日付は 2026年9月28日）
• Spec Kit — エージェント型 SDD のリファレンス
• Spec Kit — アップグレードガイド（specs/ のパス）
• github/spec-kit — MIT ライセンス
• Fission-AI/OpenSpec — README
• OpenSpec CLI リファレンス — openspec validate
• Fission-AI/OpenSpec — MIT ライセンス
• Kiro ドキュメント — 機能仕様と EARS（2026年8月4日更新）
• Kiro — ライセンス
• Tessl ドキュメント — Tessl とは
• tesslio/spec-driven-development-tile
• Tessl の仕様駆動開発タイル — MIT ライセンス
• bmad-code-org/BMAD-METHOD — README
• BMAD-METHOD — MIT ライセンス
• eyaltoledano/claude-task-master — README
• Task Master — Commons Clause 付きの MIT
• CodeSpeak
• CodeSpeak — 利用規約（2026年3月3日発効）
• Arcanada-one/datarim — README（4.9.0 のバッジ）
• Datarim — MIT ライセンス
• specscore/specscore — dogfood.yml（specscore spec lint）
• specstudio-skills — /score スキル（手作業の AI 採点）
• specscore/specscore — CC BY 4.0
• specscore/specscore-cli — Apache-2.0