BMAD（Breakthrough Method for Agile AI-Driven Development）は、GitHub で公開されているマルチエージェントフレームワークであり、エージェント型ソフトウェアエンジニアリング：基盤となる柱と研究ロードマップ が繰り返し引用している。同論文は BMAD を、Anthropic の Claude Code（そのアーキテクチャはモノリシックなエージェントから専門化されたサブエージェントを生成する方式へと移行した）よりも「より包括的な例」となる、エンジニアリングされたマルチエージェントチームの例として挙げるほか、AI Teammate Lifecycle Engineering（ATLE）（Lifetime Teammates）の原則の「包括的な業界の例」としても挙げ、さらにマルチエージェントおよびアジャイルに着想を得たフレームワークを扱う専用の小節でも取り上げている。同論文はアジャイルのロールの例として Product Owner、Architect、Developer、Tester を挙げており、BMAD は「チーム」という比喩を文字どおりに受け取り、本格的なアジャイルの構造の中で複雑なプロジェクトに取り組む。
プロジェクト自身のリポジトリ bmad-code-org/BMAD-METHOD は、BMad Method を、同プロジェクトが Ai Driven Development（AiDD）と呼ぶものを行うための「アジャイルなやり方」と説明している。AiDD は、コードだけでなく取り組み全体、すなわち何を作るか、それがどのように一貫性を保つか、チームが学ぶにつれてそれがどう変わるかを指す用語として使われている。そのキャッチフレーズは、アイデアや変更要求を「考えることを手放さずに」動くソフトウェアに変えることである。存在理由として述べられているのは、コーディングアシスタントは実装には効果的だが、明言されていない前提をそのままコードにしてしまうことが多いという点であり、BMad のエージェントとワークフローは、開発者が主導権を保ったまま、重要な判断を明示的にし、それを後の作業のためのコンテキストとして保存することを目的としている。このメソッドは MIT ライセンスのもとで無料かつオープンソースであり、有料のワークフローはない。BMad および BMAD-METHOD という名称は BMad Code, LLC の商標である。
機能
事前のエージェント型計画によって PRD と設計が生み出され、続いてスクラム風のシャーディングの工程で、タスクのための焦点を絞ったコンテキストを保持する「ストーリーファイル」が作成される。専門化されたエージェントがこれらを並列に実行する。同論文は、BMAD のロールの専門化、タスクのシャーディング、高い並列性が、Structured Agentic Software Engineering（SASE）（SASE）自身の N バージョンプログラミングとオーケストレーションによく対応していると評価している。
README は、このメソッドを作業の規模に合わせて自らを調整するプロセスとして位置づけている。小さな変更はそのままビルドに進み、複雑な作業には必要な深さの計画が与えられる。同じメソッドが、週末のプロトタイプにも、何年もの歴史を持つシステムにも役立つことを意図している。その納品ループには、これに対応した入口がある。漠然とした構想は Clarify から、大きく明確なアイデアは Plan から、小さな変更は Build and verify から始まり、Learn and adjust の工程が Plan へとループして戻る。また、BMad をエンドツーエンドで使う代わりに、ブリーフ、仕様、アーキテクチャを既存の納品ワークフローに持ち込むこともできる。挙げられている利点には、チャットのたびに説明し直すのではなく引き継がれる永続的なコンテキスト、専門化された視点（プロダクト、アーキテクチャ、UX、開発、テスト）、そして判断を手放すことのない構造化されたワークフローと複数エージェントによる議論がある。また、実際に何があるのかについて検証済みのコンテキストをまず確立することで、引き継いだコードベースから始めることもできる。
プロンプトからプロセスへ：AI ソフトウェア開発エージェントを支援するフレームワークのプロセス分類法と比較評価 は、同じフレームワークをそのドキュメントに基づいて説明し、ロールとフローの両方について詳細を加えている。この研究によれば、その組織の単位は個々のエージェントではなく、モジュール、ワークフロー、スキル、アーティファクトからなるエコシステムであり、任意の分析、計画、ソリューション、実装を含むフェーズ型のフローと、小規模タスク向けのクイックフローを備えている。インストールは npx bmad-method install で行う。同研究が挙げるデフォルトのエージェントは、アナリスト、プロダクトマネージャー、アーキテクト、開発者、UX デザイナー、テクニカルライターという古典的なソフトウェア開発の機能を表しており、各ロールは次のフェーズのためのドキュメントや判断を生み出すワークフローを起動する。同研究が要点として特定しているのはこの進行であり、アーキテクチャがストーリーを方向づけ、ストーリーが実装を方向づけ、レビューと準備状況のチェックがゲートとして機能する。同研究によれば、これによって実装エージェントが短い指示だけに基づいて動作することが防がれる。
上記のインストールコマンドは同研究が示しているものである。リポジトリの現在の README は、これとは異なるインストール経路を説明している。このメソッドは npx skills add bmad-code-org/BMAD-METHOD でインストールされる Agent Skills として、あるいはプロジェクトのプラグインマーケットプレイスから入手する Claude Code または Codex のプラグインとして配布されており、スキルをサポートする AI コーディングツールと、セットアップ用の uv ツールが必要である。インストール後は、bmad ハブスキルがセットアップを実行して次に何をすべきかを案内し、bmad-build スキルは開発者が望む変更を指定して呼び出される。
採用とエコシステム
プロジェクトは中核となるメソッドのほかに、公式モジュールも公開している。BMad Builder（スキル、ワークフロー、エージェントを構築するためのもの）、創造的思考のパートナーからなる Creative Intelligence Suite、エンタープライズ向けのテスト用アドオンである BMad Test Architect、エピック全体を無人でビルド・検証し、振り返りまで実行する BMad Loop、そして Unity、Unreal、Godot、Phaser などのエンジンでのゲーム開発向けの BMad Game Dev Studio である。選ばれたワークフローは「web bundles」、すなわち Google Gemini の Gems や ChatGPT の Custom GPTs としてもパッケージ化されており、既存の Web サブスクリプションで計画を行い、その結果のアーティファクトをコーディングツールに持ち込んで実装できる。
同論文は BMAD を自ら提案する SASE と対比させ、SASE はさらに踏み込んでいると述べている。SASE は、レビューのフィードバックを永続的な MentorScript のルール（「mentorship-as-code」）に変換し、専用の環境と規律を規定する。すなわち、人間によるコーチングとオーケストレーションのための Agent Command Environment（ACE）、エージェントの実行のための Agent Execution Environment（AEE）、そしてメモリ、ライフサイクル、エージェントネイティブなツーリングのための AI Teammate Lifecycle Engineering（ATLE）／AI Teammate Infrastructure Engineering（ATIE） である。
6 次元プロセス分類法 のもとで、BMAD は仕様で 2、コンテキストで 2、ロールで 2、実行で 1、検証で 2、ポータビリティで 1 を獲得し、合計は 12 点中 10 点で、同研究が評価した 6 つのフレームワークの中で最も高い。BMAD は、そこでロールと検証を弱いままにせず中心的に扱う 2 つのフレームワークの 1 つであり、人間によるレビューポイントを挿入することで、エージェントの自律性とガバナンスとの間の緊張に部分的な答えを与えるとされる 2 つのフレームワークの 1 つでもある。同研究は、プロセスの深さとポータビリティの対立を最も示唆に富むパターンと呼び、BMAD を最も深いプロセスの事例として挙げている。そこでは、その深さがポータビリティと実行の低下を伴っている。これらのスコアは、独立した実証的測定ではなく、公式ドキュメントに基づく同研究の著者の判断を表している。
同研究が BMAD の強みとして評価しているのは、人間と AI の協働をソフトウェアチームが見慣れたプロセスに変えていること、つまりアジャイルのプラクティスを置き換えるのではなく、PRD、アーキテクチャ、エピック、ストーリー、レビューをエージェントが扱えるものにしている点である。研究の観点から述べられている脆弱性は、有効性が利用上の規律に依存し、独立した実証的評価がまだないことである。このフレームワークは構造を提供するが、その構造がいつ品質、時間、コスト、保守、アラインメントを改善するのかは、まだ測定されていない。同研究が記録している主要なリスクは、プロセスのコストとその規律の必要性である。