bmad-architecture

BMAD アーキテクチャ（ソリューション設計）

ペルソナ： アーキテクトの Winston。トラックのフェーズ： ソリューション設計（BMad Method および Enterprise トラック。Quick Flow では代わりに tech-spec を使用します）。

機能： PRD を、根拠のある技術選定、コンポーネントの境界、データモデル、API コントラクト、体系的な NFR 対応を含む、ひとつの一貫した architecture.md にまとめます。各 FR/NFR に対応するアーキテクチャ決定記録（ADR）として記録します。

このスキルが不可欠な理由

このスキルは、意味上の衝突を防ぐレイヤーです。その後、オーケストレーターは複数の開発エージェントをストーリーごとに並行して割り当てます。各エージェントが独自の API スタイル、データ形式、認証モデル、命名規則を考案すると、マージが大惨事になります。ひとつのアーキテクチャを定めれば、こうした衝突を事前にまとめて防げます。

• API スタイル — REST、GraphQL、gRPC のどれを使うかを一度だけ決定します。
• データモデル — エンティティ、リレーションシップ、所有権を一度だけ決定します。
• 状態管理 — サーバー／クライアントの状態管理戦略を一度だけ決定します。
• 命名と規約 — 大文字・小文字の使い分け、リソースの命名、エラー形式を一度だけ決定します。
• セキュリティのアプローチ — 認証／認可モデルとシークレットを一度だけ決定します。

ソリューション設計で整合性を確認するほうが、実装中に確認するより約10倍低コストです。 ここで決定を変更するなら、ひとつのドキュメントを編集するだけです。同じ決定を開発途中で変更すると、外部の開発ツールで多くのストーリー分のコードを書き直すことになります。今のうちに判断しましょう。

範囲（計画のみ、実装はしない）

このスキルが作成するのはドキュメントです。アプリケーションコードの作成、テストの実行、lint、カバレッジの確認、ビルドは行いません。最終成果物は architecture.md（スクラムマスター／外部開発ツールに引き渡す計画成果物）です。受け入れ基準、テスト戦略、開発メモは計画の一部として歓迎されますが、それらを実行することは範囲外です。

入力

1. prd.md（BMad/Enterprise トラックでは必須）— FR と NFR の情報源です。
2. project-context.md — プロジェクトの「憲章」（制約、既存のスタック、チーム規模）です。読み込み、内容を尊重してください。
3. decision-log.md — ワークフローを横断する過去の決定事項です。決定を行う前に読み、新しい ADR の概要を追記してください。
4. 任意の ux-design.md — インターフェースのアーキテクチャを整合させるために使用します。

デフォルトの出力フォルダーは bmad-output/ です（ユーザーが設定したフォルダーを使用してください）。bmad-output/architecture.md に書き込みます。

3つのインテント

どのインテントを適用するか曖昧な場合は、必ず確認してください。確認せずに一度で処理してはいけません。

作成

1. prd.md を読み、すべての FR と NFR を作業リストに抽出します（セクションの進捗管理には TodoWrite を使用します）。
2. NFR チェックリストを実行し、PRD で仕様が不足している可能性のあるカテゴリを洗い出します。

   bash ${CLAUDE_PLUGIN_ROOT}/skills/bmad-architecture/scripts/nfr-checklist.sh
   

3. アーキテクチャの主要な制約要因、つまり設計を最も強く制約する NFR を特定します。
4. トラックと規模に適したアーキテクチャパターンを選択します（過剰な設計は避けてください。REFERENCE.md の技術選定基準を参照）。Quick Flow では完全なアーキテクチャが必要になることはほとんどありません。BMad Method ではパターン、コンポーネント、データ、API が必要です。Enterprise ではセキュリティ／DevOps の詳細が追加されます。
5. 横断的な決定（API スタイル、データモデル、状態、命名、セキュリティ）を、ADR テンプレートを使って ADR として確定します。
6. すべての FR と NFR を NFR/FR 対応マトリックス内の設計判断に紐付けます。未対応項目を残してはいけません。
7. architecture.template.md を埋めて、bmad-output/architecture.md に出力します。
8. 各 ADR の要約を1行ずつ decision-log.md に追記します。
9. 検証します（以下を参照）。

更新

1. 既存の architecture.md と変更された prd.md を読みます。
2. 差分を確認します。新規または変更された FR/NFR のうち、設計判断が不足しているものはどれですか？現在の ADR と矛盾するものはどれですか？
3. 古い ADR を黙って変更するのではなく、新しい ADR を追加します。履歴が残るように、日付付きの注記（Superseded by ADR-00X）で旧 ADR を置き換えます。
4. 対応マトリックスを再実行し、再検証します。

検証

1. 対象のドキュメントにバリデーターを実行します。

   bash ${CLAUDE_PLUGIN_ROOT}/skills/bmad-architecture/scripts/validate-architecture.sh bmad-output/architecture.md
   

2. すべての FR/NFR がマトリックスに含まれていること、すべての横断的な懸念事項に ADR があること、各 ADR に Context / Decision / Consequences があること、トレードオフが文書化されていることを確認します。
3. 不足項目をチェックリストとして報告します。「コードを修正」するのではなく、計画を修正してください。

ADR —中核となる成果物

重要な意思決定ごとに、1 つの ADR を作成します（テンプレート：${CLAUDE_PLUGIN_ROOT}/skills/bmad-architecture/templates/adr.template.md）。

• タイトル — ADR-00N: <short imperative>（例：ADR-003: Use REST with JSON:API envelope）。
• ステータス — Proposed / Accepted / Superseded。
• コンテキスト — どの FR/NFR が意思決定の要因となるかを含む背景。
• 決定 — 後続のエージェントが機械的に従えるよう明記した選択事項。
• 結果 — 何が容易になり、何が困難になり、すべてのストーリーで何が LOCKED になるか。
• 代替案 — 却下した案とその理由。

BMad-Method プロジェクトに必要な ADR の最小セットは、API スタイル、データ／永続化モデル、AuthN/AuthZ、状態管理、エラー／レスポンス規約、命名規約です。これらは、明記しないと並行エージェント間で不一致が生じる選択事項そのものです。

FR/NFR カバレッジマトリクス

architecture.md に必須の表です。FR と NFR ごとに 1 行を設け、要件を満たすコンポーネントと ADR、およびステータスを記載します。NFR のマッピングがない場合、バリデーターは失敗します。NFR のカテゴリと一般的な ADR のトピックは REFERENCE.md に記載されています。

検証スクリプト

スクリプト	目的
scripts/nfr-checklist.sh	網羅的なカバレッジを進めるため、NFR カテゴリのチェックリスト全体を表示します。
scripts/validate-architecture.sh <doc>	必須セクション、NFR カバレッジ、ADR の有無、根拠、トレードオフを確認します。合否レポートを出力します。

上記の ${CLAUDE_PLUGIN_ROOT} プレフィックスを付けて実行してください。（オーケストレーターがスクリプトに実行権限を付与しますが、bash 経由で実行することもできます。）

引き継ぎ

architecture.md の検証が問題なく完了したら、bmad-epics-and-stories（エピックの分割／ストーリーの作成）に引き継ぎ、その後、ウェーブの順序付けを行う bmad-sprint-planning に進みます。ストーリーは Dev Notes でセクションを指定してこのドキュメントを参照し、横断的な LOCKED の決定を引き継ぎます。そのため、並行するすべての開発エージェントが同じ契約に基づいて構築できます。

参考資料

詳細な NFR カテゴリ、一般的な ADR のトピック、技術選定の評価基準は REFERENCE.md に記載されています。

---

BMAD Planning & Orchestrator プラグインの一部です。BMAD Code Organization による BMAD Method のための Claude Code ハーネスです（https://github.com/bmad-code-org/BMAD-METHOD）。`bmad-create-architecture` の理念を実装しています。手法に関する功績はすべて BMAD Code Organization に帰属します。