BMAD 手法: アジャイル AI 主導開発
Il BMAD法 （アジャイルAI駆動開発の画期的な手法） 開発における最も重要な問題の 1 つに対処する革新的な方法論 AI 支援ソフトウェア: AI の機能を超える複雑なプロジェクトを管理する方法 単一の会話セッションですか？答えはこのようなシンプルな概念にあります どれほど強力か: ドキュメントの共有、または断片化 プロジェクトドキュメントをアトミックチャンクで作成し、利用できるように最適化 AIエージェント。
BMAD は、単なるプロンプトのセットやテンプレートのコレクションではありません。 完全なフレームワーク これには 21 人の専門エージェント、50 を超えるワークフローが含まれます プロジェクトの各フェーズのガイド付きテンプレートと適応型インテリジェンス システム プロジェクトのサイズに基づいて複雑さを調整します。この記事では 理論から実践まで、具体的な例を用いてメソッドのあらゆる側面を探っていきます。 実装の。
何を学ぶか
- コンテキスト オーバーフロー問題と BMAD がそれをどのように解決するかを理解する
- ドキュメントシャーディングの概念とその重要性をマスターする
- 21 の専門エージェントとその役割について学ぶ
- プロジェクトの各フェーズに 50 以上のガイド付きワークフローを使用します
- BMAD スケール適応インテリジェンスを適用する
- Claude Code を使用してプロジェクトで BMAD を構成する
- BMAD と従来の方法論を比較する
- よくある実装ミスを回避する
シリーズ概要
| # | アイテム | 集中 |
|---|---|---|
| 1 | テクニカルパートナーとしてのクロード | セットアップと最初のステップ |
| 2 | プロジェクトのコンテキストとセットアップ | CLAUDE.mdと設定 |
| 3 | コンセプトと要件 | MVP とユーザーペルソナ |
| 4 | バックエンドとフロントエンドのアーキテクチャ | Spring Boot と Angular |
| 5 | コードの構造 | 組織と規約 |
| 6 | 高度なエンジニアリングプロンプト | 高度なテクニック |
| 7 | テストと品質 | 戦略とテストの生成 |
| 8 | 専門的な文書 | README、API、ADR |
| 9 | デプロイとDevOps | Docker、CI/CD、モニタリング |
| 10 | 進化と維持 | リファクタリングとスケーラビリティ |
| 11 | 実際のプロジェクトの統合 | クロード・コードの運用中 |
| 12 | 高度な CLI とコマンド | コマンドラインの習得 |
| 13 | カスタムスラッシュコマンドとスキル | クロードコードの拡張 |
| 14 | サブエージェントと委任 | 専門エージェントを調整する |
| 15 | フック: イベント駆動型オートメーション | イベントベースの自動化 |
| 16 | ラルフ ウィガム: 自律型 AI ループ | 反復的な自律開発 |
| 17 | BMAD メソッド: アジャイル AI 開発 (ここにいます) | アジャイルな AI 主導の方法論 |
| 18 | マルチエージェントオーケストレーション | エージェントのチームを調整する |
| 19 | コラボレーションとコワーキング AI | クロードと協力して |
| 20 | セキュリティと権限 | ワークフローを保護する |
| 21 | 監視と最適化 | 指標とパフォーマンス |
1. コンテキスト オーバーフローの問題
BMAD が存在する理由を理解するには、BMAD が解決する根本的な問題を理解する必要があります。 クロードのような言語モデルには、 限られたコンテキストウィンドウ: 会話中に「覚えられる」テキストの最大量。 200K トークン ウィンドウを備えた最も先進的なモデルであっても、実際的な制限はあります 複雑なソフトウェア プロジェクトを管理する場合に重要です。
一般的なエンタープライズ プロジェクトには、数百のソース ファイル、数十のドキュメントが含まれます。 仕様、アーキテクチャ、テスト計画、導入ガイド、API ドキュメント。 これらすべてを 1 つの会話に収めることは不可能です。 重要な部分はモデルを「薄める」必要があるため、回答の品質を低下させます。 あまりにも多くの素材に焦点を当てすぎています。
数字の問題
| 要素 | 一般的なサイズ | % コンテキスト ウィンドウ (200K) |
|---|---|---|
| 完全な要件仕様 | 20,000～50,000 トークン | 10～25% |
| アーキテクチャドキュメント | 15,000～30,000トークン | 7-15% |
| データベース スキーマ (20 テーブル) | 5,000～10,000トークン | 2～5% |
| APIドキュメント | 30,000～80,000 トークン | 15～40% |
| 完全なテスト計画 | 10,000～25,000トークン | 5～12% |
| 既存のコードベース (100 ファイル) | 10万～50万トークン | 50-250% |
| 一般的な平均プロジェクト合計 | 20万～70万トークン | 100-350% |
ご覧のとおり、中程度の複雑さのプロジェクトであっても、より多くのドキュメントが生成されます。 単一のコンテキスト ウィンドウに含めることができるよりも多くの情報が含まれます。解決策 この問題に対する従来のアプローチは不十分です。
- すべてをまとめると次のようになります。 実装に必要な重要な詳細が失われている
- 個別のセッション: プロジェクトの異なる部分間で一貫性が失われる
- 選択的にコピー＆ペースト: エラーが発生しやすい継続的な手動管理が必要
- RAG (検索拡張生成): 鋭い質問には適していますが、複雑な実装タスクには不十分です
2. ドキュメントのシャーディング: 主要なイノベーション
Il ドキュメントの共有 BMAD の中心的な概念です。アイデアはシンプルです しかし奥深い: すべてを説明しようとするモノリシックなドキュメントを作成するのではなく プロジェクトを長い文書に分割すると、BMAD はプロジェクトの各側面を次のように分割します。 自己完結型で相互接続された原子の断片 彼らはそうなることができる コンテキストを無駄にすることなく、必要なときに正確に AI エージェントに提供されます。
ドキュメント共有の原則
- 原子性: 各シャードは、単一の概念、コンポーネント、または決定を記述します。 これを完全に理解するために他のシャードを読む必要はありません。
- 自己完結型: 各シャードには、必要なすべてのコンテキストが含まれています。 その使用法。シャードが API エンドポイントを記述する場合、それには入出力スキーマが含まれます。 検証、考えられるエラーと依存関係。
- 相互接続: シャードには他のシャードへの明示的な参照が含まれています これにより、エージェントはドキュメントをグラフとしてナビゲートできるようになります。
- 最適なサイズ: 各シャードは 1 つの部分を占めるサイズに設定されています コンテキスト ウィンドウの管理可能なサイズ (通常は 2K ～ 8K トークン)、余裕を持たせる 推論とコード生成のために。
BMAD ディレクトリ構造
bmad-agent/
├── agents/ # 21 agenti specializzati
│ ├── pm-agent.md # Product Manager
│ ├── architect-agent.md # System Architect
│ ├── developer-agent.md # Developer
│ ├── ux-agent.md # UX Designer
│ ├── sm-agent.md # Scrum Master
│ ├── qa-agent.md # Quality Assurance
│ ├── devops-agent.md # DevOps Engineer
│ ├── data-agent.md # Data Engineer
│ ├── security-agent.md # Security Specialist
│ ├── tech-writer-agent.md # Technical Writer
│ ├── analyst-agent.md # Business Analyst
│ ├── design-agent.md # System Designer
│ ├── frontend-agent.md # Frontend Specialist
│ ├── backend-agent.md # Backend Specialist
│ ├── mobile-agent.md # Mobile Developer
│ ├── ml-agent.md # ML Engineer
│ ├── performance-agent.md # Performance Engineer
│ ├── migration-agent.md # Migration Specialist
│ ├── review-agent.md # Code Reviewer
│ ├── release-agent.md # Release Manager
│ └── orchestrator-agent.md # Agent Orchestrator
│
├── tasks/ # 50+ workflow guidati
│ ├── analysis/
│ │ ├── gather-requirements.md
│ │ ├── competitive-analysis.md
│ │ ├── user-persona-creation.md
│ │ └── risk-assessment.md
│ ├── planning/
│ │ ├── create-roadmap.md
│ │ ├── sprint-planning.md
│ │ ├── resource-allocation.md
│ │ └── milestone-definition.md
│ ├── architecture/
│ │ ├── system-design.md
│ │ ├── api-contract.md
│ │ ├── database-schema.md
│ │ └── integration-patterns.md
│ ├── implementation/
│ │ ├── feature-implementation.md
│ │ ├── code-generation.md
│ │ ├── refactoring-guide.md
│ │ └── testing-strategy.md
│ └── delivery/
│ ├── deployment-plan.md
│ ├── release-checklist.md
│ ├── monitoring-setup.md
│ └── post-mortem.md
│
├── templates/ # Template riutilizzabili
│ ├── prd-template.md # Product Requirements Document
│ ├── adr-template.md # Architecture Decision Record
│ ├── epic-template.md # Epic/Feature template
│ ├── story-template.md # User Story template
│ └── test-plan-template.md # Test Plan template
│
├── personas/ # Configurazioni persona
│ ├── startup-mode.md # Modalità startup lean
│ ├── enterprise-mode.md # Modalità enterprise rigorosa
│ └── solo-dev-mode.md # Modalità sviluppatore singolo
│
└── checklists/ # Checklist di qualità
├── code-review.md
├── security-audit.md
├── accessibility.md
└── performance.mdシャードの例: API エンドポイント
# API Shard: Crea Prenotazione
## Endpoint
POST /api/v1/bookings
## Descrizione
Crea una nuova prenotazione per un utente registrato.
## Autenticazione
Bearer JWT Token (ruoli: USER, ADMIN)
## Input Schema
{
"roomId": "string (UUID, obbligatorio)",
"checkIn": "string (ISO 8601, obbligatorio)",
"checkOut": "string (ISO 8601, obbligatorio)",
"guests": "number (1-10, obbligatorio)",
"notes": "string (max 500 char, opzionale)"
}
## Validazioni
1. checkOut deve essere successivo a checkIn
2. La durata minima è 1 notte
3. La durata massima è 30 notti
4. La room deve esistere e essere disponibile nel periodo
5. L'utente non deve avere prenotazioni sovrapposte
## Risposte
- 201 Created: prenotazione creata con successo
- 400 Bad Request: validazione fallita
- 401 Unauthorized: token mancante o invalido
- 404 Not Found: room non trovata
- 409 Conflict: room non disponibile nel periodo
## Dipendenze
- Shard: room-availability-service
- Shard: user-validation-middleware
- Shard: booking-entity-schema
## Test Richiesti
- Happy path con dati validi
- Validazione date (checkOut prima di checkIn)
- Room non disponibile (conflict)
- Utente non autenticato
- Prenotazione sovrappostaこのシャードには、エンドポイントの実装に必要なすべてが含まれています: 入力スキーマ、 検証、応答、依存関係、テストが必要です。これを受け取るAIエージェント シャードには、それを必要とせずに完全な実装を作成するために必要なコンテキストが含まれています プロジェクトのドキュメント全体を読むには、
3. 21人のBMAD専門エージェント
BMAD の運用の中心は次のもので構成されています。 21の専門エージェント、 それぞれに特定のスキル、システム プロンプト、ワークフローが設定されています。 ソフトウェア開発の一側面。これらのエージェントは独立した存在ではありませんが、 クロード・コードによる構成 特定の専門知識を活性化する システム プロンプトとドキュメント シャードへの選択的なアクセスを介して。
プロジェクトフェーズごとのエージェントのマップ
| 段階 | 関与するエージェント | 責任 |
|---|---|---|
| 分析 | PMエージェント、アナリスト、UXエージェント | 要件、ペルソナ、競合分析 |
| 企画 | SMエージェント、PMエージェント | ロードマップ、スプリント計画、リソース |
| 建築 | アーキテクト、デザイナー、セキュリティ | システム設計、API契約、セキュリティ |
| 実装 | 開発者、フロントエンド、バックエンド、モバイル、ML | コード、テスト、統合 |
| 品質 | QAエージェント、レビューエージェント、パフォーマンス | テスト、コードレビュー、パフォーマンス |
| 配達 | DevOps、リリース、テックライター | 導入、ドキュメント、リリースノート |
| 調整 | オーケストレーター、データ エージェント、移行 | オーケストレーション、データ、移行 |
エージェントプロフィール: PM エージェント (プロダクト マネージャー)
Il PMエージェント 要件の収集と管理を担当します 製品の。ほとんどのプロジェクトで最初に呼び出されるエージェントです そして、開発の残りすべてを推進する基本的な成果物を生成します。
# PM Agent - Product Manager
## Identita
Sei un Product Manager esperto con 15+ anni di esperienza in prodotti
software B2B e B2C. Eccelli nella raccolta dei requisiti, nell'analisi
dei bisogni degli stakeholder e nella definizione di roadmap strategiche.
## Competenze Specifiche
- Tecniche di elicitazione dei requisiti (interviste, workshop, survey)
- Framework di prioritizzazione (MoSCoW, RICE, Kano)
- Creazione di Product Requirements Document (PRD)
- Definizione di metriche di successo (KPI, OKR)
- Analisi competitiva e posizionamento
## Workflow Disponibili
1. gather-requirements: Raccolta strutturata dei requisiti
2. competitive-analysis: Analisi del panorama competitivo
3. user-persona-creation: Creazione di user personas dettagliate
4. prd-creation: Stesura del Product Requirements Document
5. roadmap-planning: Pianificazione della roadmap di prodotto
## Template
- prd-template.md: Template per il documento requisiti
- epic-template.md: Template per epic/feature
- story-template.md: Template per user stories
## Regole di Interazione
1. Fai sempre domande chiarificatrici prima di procedere
2. Quantifica i requisiti quando possibile (numeri, metriche, SLA)
3. Identifica e documenta i rischi per ogni requisito critico
4. Distingui sempre tra MUST, SHOULD, COULD e WON'T (MoSCoW)
5. Produci artefatti in formato shard per il consumo da parte di altri agentiエージェントプロフィール: アーキテクトエージェント
L'建築家エージェント PMエージェントの要件を意思決定に変換します コンクリート建築。実装を推進するアーキテクチャの断片を生成し、 テクノロジー、パターン、インターフェース、トレードオフを定義します。
# Architect Agent - System Architect
## Identita
Sei un System Architect senior con esperienza in architetture distribuite,
microservizi, event-driven e serverless. Bilanci pragmatismo e rigore
tecnico nelle decisioni architetturali.
## Competenze Specifiche
- Design di architetture scalabili (verticale e orizzontale)
- Pattern architetturali (DDD, CQRS, Event Sourcing, Hexagonal)
- API Design (REST, GraphQL, gRPC)
- Database selection (SQL vs NoSQL vs NewSQL)
- Trade-off analysis (CAP theorem, performance vs consistency)
- Security by design
## Output Attesi
Per ogni decisione architetturale, produrre:
1. ADR (Architecture Decision Record) in formato shard
2. Diagramma componenti (descrizione testuale per mermaid)
3. API contract shard per ogni interfaccia
4. Database schema shard
5. Lista di vincoli e assunzioni
## Regole
1. Ogni decisione deve avere un ADR con alternative considerate
2. Preferire soluzioni semplici a soluzioni eleganti
3. Documentare i trade-off in modo esplicito
4. Definire interfacce prima delle implementazioni
5. Considerare sempre scalabilità, sicurezza e manutenibilitàエージェントプロフィール: 開発者エージェント
Il 開発者エージェント 実際のコードを生成するのはエージェントです。 PM Agent と Architect Agent によって生成されたシャードを使用してデプロイします 機能を開発し、テストを作成し、アーキテクチャ上の制約を考慮したコードを生成します。
# Developer Agent - Full-Stack Developer
## Identita
Sei uno sviluppatore full-stack esperto con padronanza di TypeScript,
Java, Python e Go. Scrivi codice pulito, testabile e manutenibile.
Segui le best practice della community e i principi SOLID.
## Competenze Specifiche
- TypeScript/JavaScript (Node.js, Angular, React, Next.js)
- Java (Spring Boot, Hibernate)
- Python (FastAPI, Django)
- Database (PostgreSQL, MongoDB, Redis)
- Testing (Jest, JUnit, pytest)
- Clean Code e Design Patterns
## Workflow
1. Leggi lo shard della feature/endpoint da implementare
2. Leggi lo shard dell'architettura rilevante
3. Implementa il codice seguendo le convenzioni del progetto
4. Scrivi test unitari con coverage > 80%
5. Esegui lint e type check
6. Aggiorna il STATUS.md del modulo
## Regole
1. Mai usare `any` in TypeScript senza commento giustificativo
2. Ogni funzione pubblica deve avere JSDoc/JavaDoc
3. Error handling esplicito, mai catch vuoti
4. Seguire il naming convention definito in CLAUDE.md
5. Rispettare le interfacce definite dall'Architect Agentエージェントプロフィール: QAエージェント
Il QAエージェント テスト戦略を担当し、 コード品質の検証。開発者エージェントと並行して動作します。 テストケースの作成、カバレッジ分析の実行、ギャップの特定 実装の品質において。
エージェントプロフィール: スクラムマスターエージェント
Lo SMエージェント 開発プロセスを調整し、 スプリント計画を作成し、振り返りを促進し、障害を取り除きます。 BMAD のコンテキストでは、バックログの作成と維持を担当します。 シャードとタスクの優先順位付け。
他のエージェント
21 のエージェントの完全な概要
| # | エージェント | 役割 | メイン出力 |
|---|---|---|---|
| 1 | PMエージェント | プロダクトマネージャー | PRD、ユーザーストーリー、バックログ |
| 2 | 建築家エージェント | システムアーキテクト | ADR、API契約、スキーマ |
| 3 | 開発者エージェント | フルスタック開発者 | コード、単体テスト |
| 4 | UXエージェント | UXデザイナー | ワイヤーフレーム、ユーザーフロー |
| 5 | SMエージェント | スクラムマスター | スプリント計画、振り返り |
| 6 | QAエージェント | 品質保証 | テスト計画、バグレポート |
| 7 | DevOpsエージェント | DevOpsエンジニア | パイプライン、インフラストラクチャー |
| 8 | データエージェント | データエンジニア | スキーマ、移行、ETL |
| 9 | セキュリティエージェント | セキュリティスペシャリスト | 脅威モデル、監査 |
| 10 | テックライターエージェント | テクニカルライター | ドキュメント、API ガイド、README |
| 11 | アナリストエージェント | ビジネスアナリスト | 分析、指標、KPI |
| 12 | デザイナーエージェント | システムデザイナー | コンポーネント設計、パターン |
| 13 | フロントエンドエージェント | フロントエンドスペシャリスト | UIコンポーネント、状態 |
| 14 | バックエンドエージェント | バックエンドスペシャリスト | サービス、API、DB |
| 15 | モバイルエージェント | モバイル開発者 | アプリ、ネイティブ機能 |
| 16 | MLエージェント | 機械学習エンジニア | モデル、パイプライン、評価 |
| 17 | パフォーマンスエージェント | パフォーマンスエンジニア | ベンチマーク、最適化 |
| 18 | 移行エージェント | 移行スペシャリスト | 移行計画、スクリプト |
| 19 | レビューエージェント | コードレビューア | レビューメモ、提案 |
| 20 | 離型剤 | リリースマネージャー | リリースノート、変更履歴 |
| 21 | オーケストレーター エージェント | エージェントコーディネーター | タスクルーティング、同期 |
4. 50 以上のガイド付きワークフロー
各 BMAD エージェントには、事前定義されたワークフローがあります。つまり、構造化された一連のステップです。 これらは、体系的かつ再現可能な方法で複雑なタスクをエージェントにガイドします。 ワークフローにより曖昧さが排除され、タスクのあらゆる側面が確実に到着します。 複雑さに関係なく対処できます。
フェーズ別のワークフロー: 分析
分析フェーズのワークフローは、収集して構造化するように設計されています。 設計または実装作業の前に必要な情報。
# Workflow: Raccolta Requisiti Strutturata
## Prerequisiti
- Accesso al cliente/stakeholder (o documento brief)
- Template PRD (prd-template.md)
- Checklist domande standard
## Passi
### Step 1: Comprensione del Contesto
- Qual è il problema che il prodotto risolve?
- Chi sono gli utenti target?
- Quali sono i vincoli di business (budget, timeline, compliance)?
- Esistono sistemi legacy da integrare?
### Step 2: Elicitazione Funzionale
Per ogni macro-funzionalità identificata:
1. Definisci il caso d'uso principale (happy path)
2. Identifica i casi limite (edge cases)
3. Definisci i criteri di accettazione (Given/When/Then)
4. Classifica la priorità (MoSCoW)
5. Stima la complessità relativa (S/M/L/XL)
### Step 3: Requisiti Non-Funzionali
- Performance: tempi di risposta attesi (p50, p95, p99)
- Scalabilità: utenti concorrenti previsti (ora, 6 mesi, 1 anno)
- Disponibilità: SLA target (99.9%? 99.99%?)
- Sicurezza: compliance requirements (GDPR, SOC2, PCI-DSS)
- Accessibilita: WCAG livello target (A, AA, AAA)
### Step 4: Produzione Artefatti
Genera i seguenti shard:
1. shard-prd-overview.md (panoramica progetto)
2. shard-personas.md (user personas)
3. shard-requirements-functional.md (requisiti funzionali)
4. shard-requirements-nonfunctional.md (requisiti non-funzionali)
5. shard-constraints.md (vincoli e assunzioni)
6. shard-risks.md (rischi identificati)
### Step 5: Validazione
- Rivedi ogni shard per completezza
- Verifica che ogni requisito sia testabile
- Conferma le priorità con lo stakeholderフェーズ別のワークフロー: アーキテクチャ
# Workflow: System Design
## Input Richiesti
- shard-prd-overview.md
- shard-requirements-functional.md
- shard-requirements-nonfunctional.md
- shard-constraints.md
## Passi
### Step 1: Identificazione Componenti
Leggi i requisiti funzionali e identifica:
- Bounded contexts (DDD)
- Servizi principali
- Integrazioni esterne
- Layer di persistenza
### Step 2: Scelta Pattern Architetturale
Valuta e documenta in ADR:
- Monolith vs Microservizi vs Modular Monolith
- Sync vs Async communication
- SQL vs NoSQL per ogni bounded context
- Hosting: Cloud vs On-premise vs Hybrid
### Step 3: Design delle Interfacce
Per ogni servizio/modulo:
1. Definisci API contract (OpenAPI/Protobuf)
2. Definisci event schema (per comunicazione async)
3. Definisci database schema
4. Documenta in shard separati
### Step 4: Security Design
- Autenticazione: metodo e flusso
- Autorizzazione: modello (RBAC, ABAC, ReBAC)
- Encryption: at rest e in transit
- Threat model (STRIDE)
### Step 5: Produzione Shard Architetturali
1. shard-architecture-overview.md
2. shard-adr-{decisione}.md (uno per ogni decisione)
3. shard-api-{servizio}.md (uno per ogni API)
4. shard-db-{context}.md (schema per ogni bounded context)
5. shard-security-model.mdフェーズ別のワークフロー: 実装
# Workflow: Implementazione Feature
## Input Richiesti
- shard-api-{endpoint}.md (contract dell'endpoint)
- shard-db-{context}.md (schema database)
- shard-architecture-overview.md (vincoli architetturali)
## Passi
### Step 1: Analisi dello Shard
1. Leggi lo shard dell'endpoint/feature da implementare
2. Identifica dipendenze da altri shard
3. Verifica che tutte le interfacce siano definite
### Step 2: Scaffolding
1. Crea i file necessari seguendo la struttura del progetto
2. Definisci interfacce TypeScript/Java per i tipi
3. Crea stub per i metodi principali
### Step 3: Implementazione TDD
Per ogni funzionalità dello shard:
1. Scrivi il test che verifica il comportamento atteso
2. Implementa il codice minimo per far passare il test
3. Refactora mantenendo i test verdi
4. Ripeti per la prossima funzionalità
### Step 4: Integrazione
1. Verifica compatibilità con interfacce definite
2. Esegui test di integrazione
3. Verifica compliance con lo shard di architettura
### Step 5: qualità
1. Esegui linter e type checker
2. Verifica coverage > 80%
3. Documenta API con JSDoc/JavaDoc
4. Aggiorna STATUS.md5. スケール適応型インテリジェンス
BMAD の最も重要なイノベーションの 1 つは、 スケール適応型インテリジェンス: 複雑さ、形式性、厳密さのレベルを自動的に適応させる機能 プロジェクトの規模と性質に基づいてプロセスを決定します。すべてのプロジェクトではありません 21 人のエージェントと 50 のワークフローが必要です。個人的なサイドプロジェクトには エンタープライズ システムとは根本的に異なるアプローチです。
BMAD スケール レベル
| レベル | プロジェクトの種類 | アクティブエージェント | ワークフロー | 手続き |
|---|---|---|---|---|
| ドワーフ | スクリプト、ユーティリティ、単一ツール | 1 (開発者) | 最小限 | 正式な文書がない |
| マイクロ | サイドプロジェクト、プロトタイプ、MVP | 3 (PM、開発、QA) | 不可欠 | README + 基本テスト |
| 小さい | スタートアップ、小規模チーム (2-5) | 6 (PM、アーチ、開発、QA、DevOps、ライター) | 標準 | PRD + ADR + API ドキュメント |
| 中くらい | エンタープライズ製品、中規模チーム (5-15) | 12 | 完了 | 完全なドキュメント + コンプライアンス |
| 大きい | エンタープライズ、大規模チーム (15 歳以上) | すべて21日 | すべて + カスタム | 完全な正式な監査証跡 |
開発者専用モード
個人の開発者向けに、BMAD は次のモードを提供します。 開発のみ それ 複数のエージェントの責任を、合理的かつ効果的なワークフローに凝縮します。
# BMAD Solo Developer Mode
## Agenti Attivi
1. PM Agent (leggero): solo user stories e criteri di accettazione
2. Developer Agent: implementazione + testing
3. DevOps Agent: solo deployment configuration
## Workflow Semplificato
1. Definisci il problema in 1 paragrafo
2. Lista le feature principali (max 10)
3. Per ogni feature, scrivi 1 user story con criteri di accettazione
4. Implementa con TDD
5. Deploy
## Shard Minimi
- overview.md: cosa fa il progetto, per chi, perchè
- features.md: lista feature con priorità
- tech-stack.md: tecnologie scelte con motivazione
- Per ogni feature: 1 shard con interface + test criteria
## Regole
- Niente ADR formali per decisioni ovvie
- Test unitari solo per logica di business complessa
- Documentazione inline (JSDoc) invece di documenti separati
- Deploy continuo senza release formali6. BMAD ワークフローの 4 つのフェーズ
プロジェクトの規模に関係なく、BMAD は開発プロセスを組織します。 4 つの異なるフェーズに分かれており、それぞれに目的、担当エージェント、アーティファクトが含まれます 特定の出力の。最初の実行ではフェーズは連続していますが、 プロジェクトが進行してから繰り返します。
フェーズ 1: 分析
分析フェーズは、解決すべき問題を深く理解することに専念します。 PM、アナリスト、UX エージェントが協力して要件を収集し、ペルソナを定義し、 競争環境を分析し、制約とリスクを特定します。
関与したエージェント: PMエージェント、アナリストエージェント、UXエージェント
生成されたアーティファクト: PRD (製品要件文書)、ユーザーペルソナ、 以下の競合分析、リスク評価、機能要件および非機能要件 原子の破片の形態。
分析フェーズの出力は、完全に記述されたシャードのセットです。 cosa 構築する必要があり、 誰のために、まだ定義せずに として。この分離は、時期尚早な決定を避けるために不可欠です 実装の。
フェーズ 2: 計画
計画フェーズでは、要件を具体的な作業計画に変換します。 スクラム マスター エージェントと PM エージェントは協力してロードマップを定義し、組織化します。 バックログ、スプリントを計画し、タスクにリソース (エージェント) を割り当てます。
関与したエージェント: SMエージェント、PMエージェント
生成されたアーティファクト: プロジェクトのロードマップ、スプリント バックログ、マイルストーン 定義、リソース割り当てマトリックス。バックログ内の各タスクは 1 つのタスクに関連付けられます。 1 つ以上の要件シャードと、実装を担当する 1 つ以上のエージェント。
フェーズ 3: アーキテクチャ
アーキテクチャフェーズで定義されるのは、 として システムが構築されます。建築家 エージェントとデザイナー エージェントは要件を分析し、アーキテクチャ上の決定を行います 文書化された、API コントラクト、データベース スキーマ、セキュリティ モデル。
関与したエージェント: アーキテクトエージェント、デザイナーエージェント、セキュリティエージェント
生成されたアーティファクト: アーキテクチャの概要、ADR (アーキテクチャの決定) レコード)、API コントラクト、データベース スキーマ、セキュリティ モデル、統合パターン。 それぞれの決定は、検討された代替案とその理由とともに文書化されます。 選択し、設計上の決定に関する完全な監査証跡を作成します。
フェーズ 4: 実装
実装フェーズではコードが記述されます。開発者エージェント ( フロントエンド、バックエンド、モバイルのバリアント) は、前のフェーズで生成されたシャードを消費します 機能を実装し、テストを作成し、デプロイメントの準備ができたコードを生成します。 並行して、QA エージェントが品質を検証し、DevOps エージェントがインフラストラクチャを準備します。
関与したエージェント: 開発者エージェント、フロントエンド エージェント、バックエンド エージェント、 QAエージェント、DevOpsエージェント、テックライターエージェント
生成されたアーティファクト: ソースコード、テストスイート、APIドキュメント、 CI/CD パイプライン、リリース ノート、ユーザー ガイド。
┌─────────────────────────────────────────────────────────────────┐
│ FASE 1: ANALISI │
│ PM Agent ──→ Analyst Agent ──→ UX Agent │
│ Output: PRD shards, Personas, Requirements, Risks │
└──────────────────────────┬──────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────┐
│ FASE 2: PIANIFICAZIONE │
│ SM Agent ──→ PM Agent │
│ Output: Roadmap, Sprint Backlog, Milestones │
└──────────────────────────┬──────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────┐
│ FASE 3: ARCHITETTURA │
│ Architect Agent ──→ Designer Agent ──→ Security Agent │
│ Output: ADR shards, API contracts, DB schemas, Security model │
└──────────────────────────┬──────────────────────────────────────┘
│
▼
┌─────────────────────────────────────────────────────────────────┐
│ FASE 4: IMPLEMENTAZIONE │
│ Developer ──→ QA ──→ DevOps ──→ Tech Writer │
│ Output: Code, Tests, Pipeline, Documentation │
└──────────────────────────┬──────────────────────────────────────┘
│
▼
┌──────────────┐
│ DELIVERY │
│ Release + │
│ Monitoring │
└──────────────┘7. 従来の手法との比較
BMAD は何もないところから生まれるのではなく、アジャイル手法の交差点に位置します。 AI エージェントの従来の機能と新たな機能。違いを理解する 確立されたアプローチとの補完性は、いつ、どのように評価するのに役立ちます。 BMADを適用します。
BMAD と従来の方法論
| 待ってます | スクラム | カンバン | BMAD |
|---|---|---|---|
| 反復 | 固定スプリント (2 ～ 4 週間) | 連続的な流れ | アダプティブ ループ (分-時間) |
| 役割 | 人間の3つの役割 | 固定された役割はありません | 21 個の構成可能な AI エージェント |
| ドキュメント | ユーザーストーリー、バックログ | ボード上のカード | 相互接続された原子の破片 |
| フィードバック | スプリントの終了 (振り返り) | 連続（フローメトリクス） | 各反復 (自動テスト) |
| スケーラビリティ | SAFe、大規模向けLeSS | ネイティブにスケーラブル | スケール適応型インテリジェンス |
| 人的コスト | チーム全員が必要 | 柔軟なチーム | 1 オペレーター + API コスト |
| スピード | 機能あたりの週数 | 機能あたりの日数 | 1 機能あたりの時間 (ループあり) |
BMAD はアジャイル手法に代わるものではなく、むしろ 強化する。スクラムを使用しているチームは、次の目的で BMAD を採用できます。 各スプリントの実装フェーズを加速し、儀式を維持する 人間による調整と実行のための BMAD エージェントの使用のためのスクラム 個々のタスクの。
8. プロジェクトで BMAD を構成する
BMAD を既存のプロジェクトに統合するには、初期設定が必要です これにより、基本的なディレクトリ構造、構成ファイル、およびシャードが準備されます。 このプロセスは段階的に行われるように設計されており、構成から始めることができます。 最小限に抑えられますが、プロジェクトが成長するにつれて複雑さが増します。
ステップ 1: インストール
# Clona il template BMAD
git clone https://github.com/bmad-method/bmad-agent.git .bmad
# Crea la struttura di base nel progetto
mkdir -p .bmad/{agents,tasks,templates,shards}
# Copia gli agenti necessari per il livello di scala scelto
# Esempio: livello "Small" (6 agenti)
cp .bmad/agents/{pm-agent,architect-agent,developer-agent,qa-agent,devops-agent,tech-writer-agent}.md \
.bmad/agents/
# Copia i workflow rilevanti
cp -r .bmad/tasks/{analysis,architecture,implementation} .bmad/tasks/
# Configura CLAUDE.md per integrare BMAD
cat >> CLAUDE.md << 'EOF'
## BMAD Configuration
- Agents directory: .bmad/agents/
- Tasks directory: .bmad/tasks/
- Shards directory: .bmad/shards/
- Active scale: Small (6 agents)
When starting a new task, always:
1. Check which shard is relevant in .bmad/shards/
2. Follow the appropriate workflow in .bmad/tasks/
3. Produce output as new shards when generating documentation
EOFステップ 2: 初期シャードの作成
# .bmad/shards/project-overview.md
# Project Overview Shard
## Nome Progetto
BookingAPI - Sistema di Prenotazioni Online
## Problema
I piccoli hotel e B&B non hanno un sistema di prenotazione
moderno, economico e facile da integrare nei loro siti web.
## Soluzione
API REST + Widget embeddabile per la gestione prenotazioni
con calendario disponibilità, pagamenti e notifiche.
## Stack Tecnologico
- Backend: Node.js + Express + TypeScript
- Database: PostgreSQL
- Cache: Redis
- Auth: JWT + OAuth2
- Deploy: Docker + Railway
## Utenti Target
1. Proprietari di piccoli hotel/B&B (admin)
2. Ospiti che prenotano (utente finale)
3. Sviluppatori che integrano il widget (developer)
## Vincoli
- Budget: $0 infrastruttura (free tier)
- Timeline: MVP in 2 settimane
- Compliance: GDPR per dati utente
- Accessibility: WCAG 2.1 AA
## Shard Correlati
- shard-personas.md
- shard-requirements-functional.md
- shard-architecture-overview.mdステップ 3: エージェントを呼び出す
構成が完了したら、クロード コードに エージェント コンテキストと関連するシャード:
# Metodo 1: Prompt diretto con contesto agente
claude "Leggi .bmad/agents/architect-agent.md per assumere il ruolo di architetto.
Poi leggi .bmad/shards/project-overview.md e .bmad/shards/requirements-functional.md.
Segui il workflow in .bmad/tasks/architecture/system-design.md per produrre
il design architetturale. Salva ogni output come shard separato in .bmad/shards/"
# Metodo 2: Slash command personalizzato
# In .claude/commands/bmad-architect.md:
# Assume the Architect Agent role from .bmad/agents/architect-agent.md
# Read relevant shards and produce architecture design shards
/bmad-architect "Design del sistema di prenotazioni"
# Metodo 3: Combinazione con Ralph Wiggum
# PROMPT.md con istruzioni BMAD + loop autonomo
cat PROMPT.md | claude --print --dangerously-skip-permissions9. ベストプラクティスとよくある間違い
BMAD の採用は、正しく適用されると大きな利点をもたらします。 しかし、不適切に使用すると、不必要な複雑さが生じる可能性があります。 このセクションでは、コミュニティから学んだ教訓を収集し、パターンを特定します 成功と避けるべきアンチパターン。
ベストプラクティス
- 小さなことから始めましょう: マイクロまたは小規模レベルから始めて追加します 必要な場合にのみ複雑になります。エージェントとワークフローを追加する方がはるかに簡単です。 プロセスに統合されたら削除してください。
- 最初にシャードを作成し、その後にコードを記述します。 コードを書きたいという誘惑に抵抗する 透明な破片ができる前に。構造化ドキュメントへの投資は成果を上げる 実装段階では大幅に進んでいます。
- 1 つのシャード = 1 つのコンセプト: シャードに 8,000 を超えるトークンが必要な場合、 おそらく彼はあまりにも多くの概念をカバーしようとしているのでしょう。複数のシャードに分割する 小さくて相互接続されています。
- シャードを更新します。 シャードは静的なドキュメントではありません。いつ 実装により仮定が間違っていたことが判明したため、シャードを更新します 一貫性の維持に対応します。
- ラルフ・ウィガムと組み合わせる: 実装フェーズでは、ペアリング BMAD + Ralph Wiggum は非常に効果的です。BMAD は構造とシャードを提供します。 Ralph Wiggum は反復実装を行います。
よくある間違い
アンチパターン BMAD
| アンチパターン | 問題 | 解決 |
|---|---|---|
| オーバーエンジニアリング | ToDo リストに 21 人のエージェントすべてを使用する | 適切なスケールレベルを選択してください |
| モノリシックシャード | すべてを含む 20,000 以上のトークンの破片 | 2～8K トークンのアトミック シャードに分割 |
| 孤立したシャード | 他のシャードへの参照がないシャード | 各シャードには「関連シャード」セクションが必要です |
| 無限の分析 | デプロイせずにシャードを生成する | 各フェーズのタイムボックスを定義する |
| フィードバックを無視する | 実装が異なる場合はシャードを更新しないでください | スプリント終了時のシャードのレビューと更新 |
| コピー＆ペーストエージェント | プロジェクトに合わせてエージェントをカスタマイズせずに使用する | 各エージェントのプロンプトとルールをコンテキストに適応させる |
10. Claude Code CLI との統合
BMAD は、いくつかのメカニズムを通じて Claude Code とネイティブに統合します。 永続コンテキストの CLAUDE.md、呼び出し用のスラッシュ コマンド エージェント、自動化用のフック、および並列実行用のサブエージェント。
BMAD ハブとしての CLAUDE.md
# CLAUDE.md
## Progetto
BookingAPI - Sistema Prenotazioni Online
## BMAD Configuration
Scale: Small (6 agents active)
### Directory Structure
- `.bmad/agents/` - Agent configurations
- `.bmad/tasks/` - Guided workflows
- `.bmad/shards/` - Project documentation shards
- `.bmad/templates/` - Reusable templates
### Active Agents
1. PM Agent: requirements and product decisions
2. Architect Agent: system design and ADRs
3. Developer Agent: code implementation
4. QA Agent: testing strategy and execution
5. DevOps Agent: deployment and infrastructure
6. Tech Writer Agent: documentation
### Conventions
- Every new feature must start with a shard
- Every architecture decision needs an ADR shard
- Implementation follows TDD within BMAD workflows
- Shards are updated when implementation diverges
### Current Sprint
Read `.bmad/shards/sprint-current.md` for active tasks
## Comandi di Sviluppo
- `npm run dev` - Start development server
- `npm test` - Run test suite
- `npm run build` - Production build
- `npm run lint` - Lint checkBMAD エージェントのスラッシュ コマンド
# .claude/commands/bmad-pm.md
# Assume the PM Agent role from .bmad/agents/pm-agent.md
# Gather requirements and produce shards
Read .bmad/agents/pm-agent.md to understand your role.
Then follow the workflow in .bmad/tasks/analysis/gather-requirements.md.
Save all outputs as shards in .bmad/shards/.
Ask clarifying questions before proceeding.
---
# .claude/commands/bmad-architect.md
# Assume the Architect Agent role from .bmad/agents/architect-agent.md
# Design system architecture based on requirement shards
Read .bmad/agents/architect-agent.md to understand your role.
Read all shards in .bmad/shards/ that start with "requirements-".
Follow the workflow in .bmad/tasks/architecture/system-design.md.
Produce architecture shards and ADRs.
---
# .claude/commands/bmad-implement.md
# Assume the Developer Agent role from .bmad/agents/developer-agent.md
# Implement the next feature based on architecture shards
Read .bmad/agents/developer-agent.md to understand your role.
Read .bmad/shards/sprint-current.md to identify the next task.
Read the relevant API and architecture shards.
Follow the workflow in .bmad/tasks/implementation/feature-implementation.md.
Use TDD: write tests first, then implement.11. 実践例: 予約 API の BMAD
提示された概念を具体化するために、BMAD がどのように適用されるかを見てみましょう 分析段階から真のホテル予約 API の構築まで 最初のエンドポイントが実装されるまで。
分析フェーズ: PM エージェントの出力
プロジェクトの概要を指定して PM エージェントを起動すると、プロジェクトの概要が生成されます。 次の要件シャード:
- プロジェクト概要.md: コンテキスト、問題、解決策、制約
- ペルソナホテルオーナー.md: ホテルオーナープロフィール
- ペルソナゲスト.md: ご予約のお客様のプロフィール
- 要件-予約-crud.md: CRUD予約要件
- 要件-可用性.md: 可用性の計算要件
- 要件認証.md: 認証/認可要件
- 制約-予算-タイムライン.md: 予算と時間の制約
アーキテクチャフェーズ: Architect Agent の出力
Architect Agent は要件シャードを消費し、アーキテクチャ上の決定を生成します。
- アーキテクチャ概要.md: モジュール式の階層型アーキテクチャ
- adr-001-モジュラー-モノリス.md: モジュラーモノリスの使用を決定
- adr-002-postgresql.md: データベースとして PostgreSQL を選択する
- api-bookings.md: 予約API契約を完了する
- db-schema-bookings.md: 予約モジュールのデータベース スキーマ
- セキュリティモデル.md: 認証用の JWT + RBAC
実装フェーズ: 開発者エージェントの稼働
開発者エージェントがシャードを受け取ります api-bookings.md そしてワークフローに従います
最初のエンドポイントを実装するための TDD。出力はテストを含む動作するコードです
開発ループを通じて反復的に生成され、完全なものになります。
// src/bookings/booking.service.ts
// Generato dal Developer Agent seguendo lo shard api-bookings.md
import { Injectable, ConflictException, NotFoundException } from '@nestjs/common';
import { BookingRepository } from './booking.repository';
import { RoomService } from '../rooms/room.service';
import { CreateBookingDto, BookingResponse } from './booking.dto';
@Injectable()
export class BookingService {
constructor(
private readonly bookingRepo: BookingRepository,
private readonly roomService: RoomService,
) {}
/**
* Crea una nuova prenotazione verificando la disponibilità.
* @shard api-bookings.md - POST /api/v1/bookings
*/
async createBooking(
userId: string,
dto: CreateBookingDto,
): Promise<BookingResponse> {
// Verifica esistenza room
const room = await this.roomService.findById(dto.roomId);
if (!room) {
throw new NotFoundException('Room non trovata');
}
// Verifica disponibilità nel periodo
const isAvailable = await this.roomService.checkAvailability(
dto.roomId,
dto.checkIn,
dto.checkOut,
);
if (!isAvailable) {
throw new ConflictException('Room non disponibile nel periodo richiesto');
}
// Crea prenotazione
const booking = await this.bookingRepo.create({
userId,
roomId: dto.roomId,
checkIn: dto.checkIn,
checkOut: dto.checkOut,
guests: dto.guests,
notes: dto.notes,
status: 'CONFIRMED',
});
return this.toResponse(booking);
}
private toResponse(booking: any): BookingResponse {
return {
id: booking.id,
roomId: booking.roomId,
checkIn: booking.checkIn,
checkOut: booking.checkOut,
guests: booking.guests,
status: booking.status,
createdAt: booking.createdAt,
};
}
}結論
BMAD メソッドは、ソフトウェア開発に対する成熟した体系的なアプローチを表します。 AI による支援。 BMAD はドキュメント シャーディングを通じて根本的な問題を解決します コンテキスト オーバーフローを防止し、複雑なプロジェクトでも問題なく管理できるようにします。 文書化と実装の品質や一貫性が犠牲になります。
BMAD の本当の強みは、 適応力:モードから 個人サイドプロジェクトのみの開発から、21 エージェントすべてを使用したエンタープライズ構成まで、 フレームワークはプロジェクトのニーズに合わせて自然に拡張されます。テクニックと組み合わせて 自己展開用の Ralph Wiggum ループや自動化用のフックなど、 BMAD は、完全かつ効果的な AI 主導の開発システムの中核となります。
重要なポイント
- ドキュメント シャーディングはコンテキスト オーバーフローを解決します。 アトミックで自己完結型のフラグメントにより、複雑なプロジェクトを管理できます
- 21 人のエージェントがサイクル全体をカバーします。 要件分析から展開まで、あらゆる側面に専任のエージェントがいます
- 50 以上のワークフローにより曖昧さが解消されます。 構造化されたシーケンスにより完全性と再現性が保証されます
- スケール適応型インテリジェンス: フレームワークはオーバーエンジニアリングすることなくナノスケールから大規模まで拡張可能
- 4 つの反復フェーズ: 継続的なサイクルでの分析、計画、アーキテクチャ、実装
- アジャイル手法を補完するもの: BMAD はスクラムとカンバンを置き換えるのではなく、強化します
- Claude コードとのネイティブ統合: CLAUDE.md、スムーズなワークフローのためのスラッシュ コマンドとフック
次の記事では、マルチエージェントオーケストレーション: アスペクトを同時に処理するクロード コードの複数のインスタンスを調整する方法 プロジェクトのさまざまな側面、同期と競合解決の管理 そして共通の目標に向かって収束します。