SpecScore vs BMAD Method

BMAD Method（アジャイルな AI 駆動開発のための突破法）は、AI エージェントでアジャイルな提供を進めるオープンソースなやり方です。作業を明確にし、計画し、作り、検査し、決定を書き残します。プロダクト要求文書（PRD）は、何を誰のために作るかを散文で説明したものです。この方法のワークフロー図は、まず PRD を作り、次にアーキテクチャとストーリーを作ります。仕様駆動開発（SDD）は、両者が置かれるより広い考えです。振る舞いはコードより先に指定されます。SpecScore はその仕様のためのオープンソースのフォーマットであり、コマンドラインインターフェース（CLI）が付きます。継続的インテグレーション（CI）、つまり提案された変更のたびに走る自動検査は、SpecScore のファイルの構造が誤っているときに失敗できます。

最終更新：2026年10月30日

共通点。

どちらも、コードを書きながらエージェントに製品を発明させることを拒みます。
どちらも、計画の文書をリポジトリの中、作業の隣の Markdown に残します。
どちらも、実装が走り出す前に、人が計画を承認することを期待します。

BMAD Method が得意なこと。

2026年10月30日に読んだプロジェクトの README は、v6.12 を安定版、v7 を main ブランチ上のプレビューと呼んでいます。その README に書かれた v7 の日付は、すでに過ぎていました。行の名前はスナップショットとして扱ってください。

作業の大きさに合わせて手順を変える方法

README は、小さな変更はすぐビルドへ進み、大きな作業は計画を受ける、と述べます。main 上のワークフロー図は段階を書いています。PRD（PRD.md）、任意の UX 仕様、意思決定の記録を伴う architecture.md、エピックとストーリーのファイル、それからスプリントです。これは一つのプロンプトではなく、アジャイルの一巡です。

実装の前にある関門

同じ図は bmad-check-implementation-readiness を挙げます。実装の前に PASS、CONCERNS、または FAIL を返します。v6 のプロダクトマネージャーのエージェントにも validate-PRD の手順があります。これらはエージェントが実行するワークフローの関門です。任意の Markdown ツリーに向ける、別のフォーマットリンターではありません。

実際に公開されている

この方法は公開リポジトリで MIT ライセンスです。README の安定版の導入は npx bmad-method install であり、Node.js 20.12 以降と Python 3.10 以降を求めています。サイト bmadcode.com は、この方法は無料である、と述べています。

機能比較。

BMAD はプロセスです。SpecScore は、プロセスが対象にできる成果物のフォーマットです。表はその役割を比べます。

機能	BMAD Method	SpecScore
主な役割	アジャイルの方法: 着想から検証済みのコードまでのエージェント、スキル、ワークフロー	オープンな仕様フォーマット + CLI
計画の成果物	PRD、UX 仕様、アーキテクチャ、エピックとストーリー、スプリントの状態 — 2026年10月30日に読んだワークフロー図より	要件 ID を伴う、spec/ ツリーの中の着想、機能、計画、タスク
作業の検査	エージェントが実行する、準備の関門（PASS / CONCERNS / FAIL）と validate-PRD ワークフロー	CI における決定論的な specscore spec lint。`/score` は手動の AI 採点です。
要件 ID	PRD とエピックのファイルの中のストーリーと機能要件。SpecScore の REQ: slug ではありません。	REQ: slug と受け入れ基準の ID
実行環境	README が説明する v6.12 のインストーラーのための Node.js と Python	単一の Go バイナリ以外には何も要りません
ライセンス	MIT、bmad-code-org/BMAD-METHOD	CC BY 4.0 のフォーマット · Apache-2.0 の CLI

SpecScore が加えるもの。

検査はコマンドであり、方法の中の一段ではない

BMAD の準備の結果は、そのワークフローの中の判断です。SpecScore の結果はプロセスの終了コードです。dogfood.yml はすべてのプルリクエストで specscore spec lint を実行します。/score は、リポジトリに設定されたレビュアーで成果物を採点します。呼び出すのは人です。CI は呼びません。

$ specscore spec lint

features/apply-discount/README.md:0 [error] oq-section: Open Questions section not found
features/apply-discount/README.md:0 [error] index-entries: Child directory not listed in index: refunds
features/apply-discount/refunds:0 [error] readme-exists: README.md not found

3 violations found (3 errors)

フォーマットは別の方法を超えて残る

BMAD の文書は、そのワークフローによって形作られます。BMAD を走らせるのをやめても Markdown は残りますが、方法の外で形を強制するものはありません。SpecScore のツリーは契約です。BMAD を含む別のワークフローがそれを書いても、リンターは同じように適用されます。

ストーリーと要件は ID で結び付いたまま

BMAD のストーリーは文脈を先へ運ぶので、エージェントが製品を決め直さずに済みます。SpecScore はその結び付きを機械的にします。計画のタスクは REQ: slug を引き、specscore: の注記と Verifies: のコミットトレーラーが、コードを基準へ向けて指します。

使い分けの指針。

BMAD Method を選ぶのは…

役割ごとのワークフローを持つエージェントが実行する、PRD、アーキテクチャ、ストーリー、スプリントというアジャイルの一巡が欲しいとき。
準備の関門と、この方法が備えるプロダクト、アーキテクチャ、テストの視点の一団が欲しいとき。
チームのプロンプトの仕方を揃えようとしていて、その標準がこの方法のスキルであるとき。

SpecScore を使うべきなのは…

その日に BMAD のワークフローを誰も走らせなくても、見出し、リンク、状態が誤っているときに仕様が CI で失敗しなければならないとき。
一つの方法のストーリーファイルの中だけでなく、ツールをまたいで安定した要件 ID が必要なとき。
別のプロセスが対象にできるオープンソースのフォーマットが欲しいとき。

方法が、フォーマットを書ける。

BMAD が答えるのは「作業をどう進めるか」です。SpecScore が答えるのは「契約であるファイルは何か、そして CI はどうやってそれが壊れていないと知るか」です。チームは会話のために BMAD の PRD とストーリーを残し、検査しなければならない要件のために SpecScore の機能を残すことができます。

一巡には BMAD Method を。プルリクエストが検査する成果物には SpecScore を。

出典。

下の公開ページは 2026年10月30日に読みました。価格、プラン名、リリースの線は変わります。

他の比較。

同じフォーマットを、他の仕様駆動のツールと並べます。

まとめて一ページに: 2026年の仕様駆動開発ツール。

この比較は公開されているドキュメントとソースコードに基づいています。誤りや古い情報がありますか？修正issueを作成. 他のツールとの比較をご希望ですか？リクエスト.