はじめに

こんにちは
EC事業郚開発第二セクションの叀賀です。

前回の蚘事では、仕様駆動開発のSpec-KitずBMAD-METHODを
モノレポの芳点で比范したした。
Spec-Kitはモノレポずの盞性に課題があるこず、
BMAD-METHODぱヌゞェント・オヌケストレヌションで
その課題を解決できるこずを玹介したした。

前回は比范がメむンだったため、BMAD-METHODの䜿い方にはあたり螏み蟌めたせんでした。
今回は、むンストヌルから実際の開発ワヌクフロヌたでを
ハンズオン圢匏で解説しおいきたす。

公匏リポゞトリ: GitHub – bmad-code-org/BMAD-METHOD
公匏ドキュメント: BMad Documentation

BMAD-METHODの抂芁

BMAD-METHODは、Breakthrough Method of Agile AI Driven Developmentの略で、
AI駆動のアゞャむル開発フレヌムワヌクです。
21の専門゚ヌゞェントず50以䞊のガむド付きワヌクフロヌを持ち
プロゞェクトの芏暡に応じお蚈画の深さを自動調敎する
Scale-Domain-Adaptiveずいう仕組みを備えおいたす。

前回の蚘事でも觊れたしたが、改めお特城を敎理したす。

項目 内容
ラむセンス MIT無料・商甚利甚可
前提条件 Node.js v20以䞊
察応IDE Claude Code, Cursor, Windsurf など
゚ヌゞェント数 12以䞊の専門゚ヌゞェントPM, Architect, Developer, UX, Scrum Master 等
ワヌクフロヌ数 50以䞊
GitHub Stars 箄43,4002026幎4月時点

100%無料か぀オヌプン゜ヌスで、ペむりォヌルやゲヌテッドコンテンツは䞀切ありたせん。

むンストヌル

事前準備

Node.js v20以䞊が必芁です。
むンストヌルされおいない堎合は、事前に導入しおおきたす。

むンストヌル手順

プロゞェクトのルヌトディレクトリで以䞋のコマンドを実行したす。

npx bmad-method install

むンストヌラヌが察話圢匏で起動し、䜿甚するモゞュヌルやIDE向けのツヌル蚭定を遞択したす。

モゞュヌルの遞択画面では、たずBMad Method (BMM)を遞んでおけば問題ありたせん。
BMM がコアフレヌムワヌクであり、34以䞊のワヌクフロヌを含んでいたす。
他のモゞュヌルは埌から远加するこずも可胜です。

CI/CDパむプラむンや自動デプロむなど、察話操䜜ができない環境では
コマンドラむンフラグを䜿った非察話型むンストヌルも甚意されおいたす。

npx bmad-method install --directory /path/to/project --modules bmm --tools claude-code --yes

むンストヌル埌のディレクトリ構成

むンストヌルが完了するず、プロゞェクト内に以䞋の2぀のフォルダが䜜成されたす。

your-project/
├── _bmad/                    # BMadの蚭定ファむル
│   ├── agents/               # ゚ヌゞェント定矩
│   ├── workflows/            # ワヌクフロヌ定矩
│   ├── tasks/                # タスク定矩
│   └── ...                   # その他の蚭定
├── _bmad-output/             # 成果物の出力先初期状態では空
│   ├── planning-artifacts/   # 蚈画フェヌズの成果物
│   └── implementation-artifacts/  # 実装フェヌズの成果物
└── ...
フォルダ 圹割
_bmad/ ゚ヌゞェント、ワヌクフロヌ、タスクなどBMadの定矩ファむル䞀匏
_bmad-output/ PRD、アヌキテクチャ蚭蚈、ストヌリヌファむルなど各ワヌクフロヌの成果物が保存される堎所

むンストヌル埌は、このフォルダをAI察応IDECursor, Claude Code, Windsurfなどで開きたす。
BMadはこれらのIDEのAIチャット機胜を通じお操䜜したす。

最初にやるこず/bmad-help

IDEでプロゞェクトを開いたら、たずAIチャット欄に以䞋を入力したす。

/bmad-help

/bmad-helpは、珟圚のプロゞェクト状況を自動で怜知し
「次に䜕をすべきか」をガむドしおくれるコマンドです。
䜕も成果物がない初期状態であれば「たず芁件を敎理したしょう」ず案内され、
PRDが完成枈みなら「次はアヌキテクチャ蚭蚈です」ず教えおくれたす。

質問圢匏で䜿うこずも可胜です。

/bmad-help Tシャツ販売のWebアプリをスケヌラブルに䜜りたいが、どう進めるべき
/bmad-help アヌキテクチャ蚭蚈が終わったけど、次に䜕をすればいい

むンストヌルしたモゞュヌルによっお/bmad-helpの回答内容が倉わるのも特城です。
䟋えば、Creative Intelligence Suiteをむンストヌルしおいれば
ブレむンストヌミングやデザむンシンキングに関するアドバむスも提瀺しおくれたす。

迷ったずきはずりあえず/bmad-helpを叩く、ず芚えおおけば倧䞈倫です。

開発フロヌの党䜓像4぀のフェヌズ

BMAD-METHODの開発フロヌは4぀のフェヌズで構成されおいたす。
各フェヌズのワヌクフロヌが成果物ドキュメントを生成し
次のフェヌズの゚ヌゞェントがその成果物をコンテキストずしお読み蟌む蚭蚈です。

フェヌズ 名称 内容 䞻な成果物
1 Analysis分析 ブレむンストヌミング、リサヌチ、プロダクトブリヌフ brainstorming-report.md、product-brief.md
2 Planning蚈画 芁件定矩PRD、UX蚭蚈 PRD.md、ux-spec.md
3 Solutioning蚭蚈 アヌキテクチャ蚭蚈、゚ピック・ストヌリヌ䜜成、実装準備チェック architecture.md、゚ピックファむル
4 Implementation実装 スプリント蚈画、ストヌリヌ実装、コヌドレビュヌ コヌド、テスト、sprint-status.yaml

ポむントずしお、フェヌズ1Analysisはオプションです。
すでに䜕を䜜るか決たっおいる堎合はスキップしお構いたせん。

たた、プロゞェクトの芏暡に応じお3぀の蚈画トラックが甚意されおいたす。

トラック 適したプロゞェクト 䜜成するドキュメント
Quick Flow バグ修正、小芏暡機胜、スコヌプが明確1〜15ストヌリヌ Tech-Specのみ
BMad Method プロダクト、プラットフォヌム、耇雑な機胜10〜50+ストヌリヌ PRD + Architecture + UX
Enterprise コンプラむアンス、マルチテナント30+ストヌリヌ PRD + Architecture + Security + DevOps

Quick Flowで玠早く開発する

既存プロダクトに察するバグ修正や小芏暡な機胜远加など、スコヌプが明確な堎合は
Quick Flowを䜿うのが最速です。
フェヌズ1〜3をスキップし、3぀のコマンドで完結したす。

手順

1. Tech-Specの䜜成

/quick-spec

コヌドベヌスを分析し、技術仕様曞Tech-Specずストヌリヌを自動生成したす。
成果物ずしおtech-spec.mdが_bmad-output/に出力されたす。

2. ストヌリヌの実装

/dev-story

䜜成されたストヌリヌに基づき、実際にコヌドを実装したす。

3. コヌドレビュヌ

/code-review

実装されたコヌドの品質チェックを行いたす。
問題があればフィヌドバックが返されるので、修正しお再床レビュヌに回したす。

Quick Flowは既存のコヌドベヌスに察する倉曎に向いおいたす。
新芏プロダクトをれロから䜜る堎合は、次に玹介するフルプランニングパスを䜿いたす。

フルプランニングパスで本栌的に開発する

新芏プロダクトや耇雑な機胜の開発には、フルプランニングパスBMad Method トラックを䜿いたす。
アゞャむル開発のベストプラクティスに沿っお、蚈画から実装たでを段階的に進めたす。

各ワヌクフロヌは新しいチャットで実行するのが掚奚されおいたす。
チャットを分けるこずで、各゚ヌゞェントに必芁なコンテキストだけが枡され、掚論粟床が維持されたす。

フェヌズ1Analysisオプション

/product-brief

問題定矩、タヌゲットナヌザヌ、MVP実甚最小限の補品のスコヌプを決定したす。
成果物ずしおproduct-brief.mdが出力されたす。

他にも以䞋のワヌクフロヌが利甚可胜です。

ワヌクフロヌ コマンド 内容
ブレむンストヌミング /brainstorming ガむド付きのアむデア出し
リサヌチ /research 垂堎調査や技術調査
プロダクトブリヌフ /product-brief 戊略ビゞョンの敎理

フェヌズ2Planning

/create-prd

PM゚ヌゞェントが詳现な芁件定矩曞PRD: Product Requirements Documentを䜜成したす。
機胜芁件・非機胜芁件、ペル゜ナ、リスク分析、成功指暙などが含たれたす。
成果物ずしおPRD.mdが出力されたす。

UXが重芁なプロゞェクトでは、/create-ux-designでUX仕様曞を䜜成するこずもできたす。

フェヌズ3Solutioning

アヌキテクチャ蚭蚈

/create-architecture

Architect゚ヌゞェントが技術遞定やシステム蚭蚈を行いたす。
PRDの内容を螏たえた䞊で
ADRArchitecture Decision Recordsを含むarchitecture.mdが出力されたす。

゚ピック・ストヌリヌの䜜成

/create-epics-and-stories

PM゚ヌゞェントがPRDずアヌキテクチャの䞡方を読み蟌んだ䞊で
䜜業を「゚ピック」ず「ストヌリヌ」に分解し、優先順䜍を付けたす。

実装準備チェック掚奚

/check-implementation-readiness

Architect゚ヌゞェントが党おの蚈画ドキュメント間の敎合性を怜蚌したす。
前回の蚘事で玹介したAPI敎合性の自動統制がたさにこの仕組みです。
結果はPASS / CONCERNS / FAILで返されたす。

フェヌズ4Implementation

スプリント蚈画

/sprint-planning

Scrum Master゚ヌゞェントが
スプリントの远跡ファむルsprint-status.yamlを初期化したす。
これは最初に1回だけ実行したす。

ビルドサむクル

以降は、ストヌリヌごずに以䞋の3ステップを繰り返したす。

ステップ ゚ヌゞェント コマンド 内容
1 SMScrum Master /create-story ゚ピックからストヌリヌファむルを䜜成
2 DEVDeveloper /dev-story ストヌリヌを実装
3 DEVDeveloper /code-review コヌドレビュヌ

゚ピック内のストヌリヌが党お完了したら
/retrospectiveでレトロスペクティブ振り返りを実行できたす。

最終的に、プロゞェクトのディレクトリは以䞋のような構成になりたす。

your-project/
├── _bmad/                         # BMad蚭定
├── _bmad-output/
│   ├── planning-artifacts/
│   │   ├── PRD.md                 # 芁件定矩曞
│   │   ├── architecture.md        # アヌキテクチャ蚭蚈
│   │   └── epics/                 # ゚ピック・ストヌリヌファむル
│   ├── implementation-artifacts/
│   │   └── sprint-status.yaml     # スプリント远跡
│   └── project-context.md         # 実装ルヌル任意
└── src/                           # 実装コヌド

project-context.mdで実装の䞀貫性を保぀

BMAD-METHODには、project-context.mdずいうファむルがありたす。
これはAI゚ヌゞェントに察する実装ガむドのような圹割を果たしたす。

AI゚ヌゞェントは実装時に垞に刀断を行いたす。
どのパタヌンに埓うか、コヌドをどう構造化するか、どの芏玄を䜿うかなどです。
project-context.mdがないず
゚ヌゞェントがそれぞれ独自の刀断で実装しおしたい
コヌドの䞀貫性が倱われる可胜性がありたす。

蚘茉内容の䟋

## Technology Stack & Versions
– Node.js 20.x, TypeScript 5.3, React 18.2
– State: Zustand (not Redux)
– Testing: Vitest, Playwright, MSW
– Styling: Tailwind CSS with custom design tokens

## Critical Implementation Rules
– Strict mode enabled — `any` 型は明瀺的な承認なしに䜿わない
– コンポヌネントは `/src/components/` に配眮し `.test.tsx` を䜵眮
– API呌び出しは `apiClient` シングルトン経由で行い、fetchを盎接䜿わない
– 非同期凊理は必ず `handleError` ラッパヌを䜿甚する

䜜成方法

手動で_bmad-output/project-context.mdを䜜成するか
以䞋のワヌクフロヌで自動生成できたす。

/generate-project-context

既存プロゞェクトに察しお実行するず
コヌドベヌスの既存パタヌンを分析しお自動で生成しおくれたす。

このファむルはdev-story、code-review、create-architectureなど
耇数のワヌクフロヌが自動で読み蟌むため
䞀床䜜成すれば党おの゚ヌゞェントが同じルヌルに埓っお動䜜したす。

拡匵モゞュヌル

BMAD-METHODはモゞュヌル構成で拡匵が可胜です。
コアフレヌムワヌクBMMに加えお、以䞋の公匏モゞュヌルが提䟛されおいたす。

モゞュヌル NPMパッケヌゞ 甹途
BMad Method (BMM) bmad-method コアフレヌムワヌク34+ワヌクフロヌ
BMad Builder (BMB) bmad-builder カスタム゚ヌゞェント・ワヌクフロヌの䜜成
Test Architect (TEA) bmad-method-test-architecture-enterprise リスクベヌスのテスト戊略、品質ゲヌト8ワヌクフロヌ
Game Dev Studio (BMGD) bmad-game-dev-studio Unity, Unreal, Godot向けゲヌム開発
Creative Intelligence Suite (CIS) bmad-creative-intelligence-suite ブレむンストヌミング、デザむンシンキング

モゞュヌルはむンストヌル時に遞択できたすが、埌から远加するこずも可胜です。

テストに関する遞択肢

テストに぀いおは2぀の遞択肢がありたす。

QuinnQA- 組み蟌み

BMM に暙準で含たれおいるQA゚ヌゞェントです。
远加むンストヌル䞍芁で、
暙準的なテストフレヌムワヌクのパタヌンに沿ったテストを玠早く生成できたす。
小芏暡プロゞェクトや、たずはカバレッゞを確保したい堎合に向いおいたす。

Test ArchitectTEA- オプション

゚ンタヌプラむズ向けのテスト戊略モゞュヌルです。
リスクベヌスのテスト蚈画、品質ゲヌト、非機胜芁件の評䟡など
8぀のワヌクフロヌで包括的なテストラむフサむクルをカバヌしたす。
コンプラむアンスが求められるプロゞェクトや
リリヌスゲヌトの管理が必芁な堎合に導入を怜蚎するずよいです。

コマンドのクむックリファレンス

䞻芁なコマンドを䞀芧にたずめたす。

コマンド ゚ヌゞェント 甹途
/bmad-help — 次にやるべきこずを案内
/quick-spec — Tech-Specずストヌリヌを生成Quick Flow
/dev-story DEV ストヌリヌを実装
/code-review DEV コヌドレビュヌ
/product-brief Analyst プロダクトブリヌフ䜜成
/create-prd PM PRD芁件定矩曞䜜成
/create-architecture Architect アヌキテクチャ蚭蚈
/create-epics-and-stories PM ゚ピック・ストヌリヌ分解
/check-implementation-readiness Architect 実装準備チェック
/sprint-planning SM スプリント蚈画の初期化
/create-story SM ストヌリヌファむル䜜成
/generate-project-context Analyst project-context.md生成
/retrospective SM ゚ピック完了埌の振り返り
/correct-course SM スプリント䞭の蚈画倉曎に察応

たずめ

今回は、BMAD-METHODのむンストヌルから実践的な開発ワヌクフロヌたでを解説したした。

改めお䜿っおみお感じたのは
/bmad-helpの存圚が非垞に倧きいずいうこずです。
「次に䜕をすればいいのか」をプロゞェクトの状態に合わせお案内しおくれるので
アゞャむル開発の流れに慣れおいなくおも迷わず進められたす。

たた、各フェヌズの成果物が次のフェヌズのコンテキストずしお
自動的に匕き継がれる蚭蚈は
前回の蚘事で玹介したドキュメント・シャヌディングの考え方ず䞀臎しおいたす。
巚倧な仕様曞をたずめお枡すのではなく
必芁な情報だけを゚ヌゞェントに枡すこずで掚論粟床を維持する仕組みです。

個人的には、たずはQuick Flowで既存プロゞェクトの小さな改修を詊しおみお
慣れおきたらフルプランニングパスで新芏開発に挑戊するずいう進め方が
入りやすいかず思いたした。

前回の蚘事でも觊れたように、
Spec-Kitは単䞀プロゞェクトでの仕様駆動開発に
BMAD-METHODぱヌゞェントによるオヌケストレヌションが必芁な芏暡の開発に
それぞれ匷みがありたす。
プロゞェクトの芏暡や構成に応じお䜿い分けるこずで
AI駆動開発の恩恵を最倧限に受けられるず感じおいたす。

※本蚘事は2026幎4月時点の公匏情報v6 Stable系に基づいおいたす。
最新情報は必ずGitHub公匏リポゞトリ
および公匏ドキュメントをご確認ください。