はじめに

こんにちは！
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公式リポジトリ
および公式ドキュメントをご確認ください。