BMAD-METHODをClaude Codeで使う手順 — 役割エージェントとスキルの動かし方

BMAD-METHOD(BMad Method)は、AIコーディングツールにスキルとして導入するMITライセンスのOSSで、要件整理から設計、実装、レビューまでを一本の流れに載せます。Claude Codeにはnpx skills addかプラグインマーケットプレイスで入り、/bmad-buildのようなスラッシュコマンドで呼び出します。

Analyst、PM、Architectといった役割エージェントは現在も用意されています。ただし現行のドキュメントは、全員を順番に呼ぶ流れを前提にしていません。変更の大きさに合わせて、計画の深さを選ぶ作りです。この記事では、導入から最初の変更、大きな作業の分け方、Claude Code側で足しておきたい設定までを順に進めます。

BMad Methodは何を提供するか

BMad Methodは「アジャイルなAI駆動開発」を掲げる手法です。コーディングアシスタントが暗黙の前提をそのままコードにしてしまう問題に対し、エージェントとワークフローが重要な判断を明示し、後続の作業の文脈として残す、というのが狙いです。

特徴は次の4点に整理できます。

README上、BMad Method本体のほかに、スキルやエージェントを作るBMad Builder、創造的な発想を支えるCreative Intelligence Suite、企業向けテストを足すTest Architect、エピック全体を無人で回すBMad Loop、ゲーム開発向けのGame Dev Studioが公式モジュールとして並んでいます。この記事が扱うのは本体のBMad Methodです。

役割エージェントは5体、呼び出しはスキル名

BMad Methodモジュールを入れると、名前付きのエージェントが5体入ります。スキルIDで読み込み、メニューのコードで作業を選びます。

コードはエージェントごとに意味が変わります。CRはAnalystなら競合分析、Developerならコードレビューです。技術文書担当のPaigeは休止中で、その役目だった「プロジェクトコンテキスト」はAnalystのPCコードかbmad-project-contextの直接呼び出しで使えます。

起動方法は2通りあります。ワークフローが決まっているならスキル名を直接打ち、すでにエージェントと話している最中に別の作業へ移るときはメニューのコードを使います。

エージェントのほかに、どのプロジェクトでも使えるコアスキルが8本あります。ヘルプ役のbmad、出力を別の推論手法で見直すbmad-advanced-elicitation、差分や文書を複数の観点で検査するbmad-review、ブレインストーミング、調査、アイデアの検証、複数エージェントの討論などです。

Claude Codeへの導入手順

導入方法は2つあり、1つのスキルには片方だけを使います。同じスキルを両方で入れると、コマンドが重複します。前提は、スキル対応のAIコーディングツールと、セットアップやPythonスクリプトに使うuvです。Skills CLI経由の場合はNode.js、npm、Gitも要ります。

経路1: Skills CLI

プロジェクトのディレクトリで実行します。

npx skills add bmad-code-org/BMAD-METHOD

対話でコーディングツールと入れるスキルを選びます。セットアップとヘルプ用のbmad、モジュールの記録用bmod-core-toolsとbmod-methodは含めます。名前を指定して最小構成で入れるなら、次のように並べます。

npx skills add bmad-code-org/BMAD-METHOD \
  --skill bmad --skill bmod-core-tools --skill bmod-method \
  --skill bmad-build --skill bmad-ticket

経路2: Claude Codeのプラグインマーケットプレイス

Claude Codeのセッション内で、マーケットプレイスを登録します。

/plugin marketplace add bmad-code-org/bmad-plugins

Claude Codeの/plugin marketplace addは、owner/repo形式のGitHubリポジトリを登録元として受け付けます。登録後、bmad-method(開発ワークフロー)とbmad-core-tools(bmadハブを含む単体スキル)をプラグインとして入れます。更新もマーケットプレイス側の手順で行います。チームでプラグインを配る運用はClaude Codeプラグインマーケットプレイスの必須化と自動更新設定にまとめています。

セットアップと動作確認

どちらの経路でも、最後にプロジェクトのフォルダでClaude Codeを起動し、bmadスキルにセットアップを頼みます。

bmad setup
bmad status

bmad setupは共有のランタイムとモジュールのスクリプトを_bmad/に置きます。bmad statusでバージョンを確認できます。生成物は_bmad-outputに出力され、作業単位(initiative)を設定している場合はその中のフォルダに入ります。

スキルのファイルはClaude Codeでは.claude/skills/に置かれ、ディレクトリ名がスキル名です。たとえばbmad-agent-dev/はbmad-agent-devとして登録されます。インストール結果の一覧はこのディレクトリを開けばわかります。

更新は、もう一度bmad setupを頼みます。モジュールごとのバージョンを調べ、新しい版があればnpx skills updateを実行し、新しい設定項目を尋ね、改名や削除されたスキルの片付けまで進めます。手でnpx skills updateを実行したときも、後からbmad setupを実行します。

最初の変更を/bmad-buildで実装する

日常の中心はbmad-buildです。一文でも、Issueのリンクでも、仕様書でも、チケットでも渡せます。コードベースと上流の計画文書を調べたうえで、計画、実装、レビュー、修正まで進めます。

/bmad-build ログイン検証で空のパスワードを通してしまうバグを直す

流れは次の5段階です。

扱う大きさの目安は、1回あたり、テストを除いて約500行の追加・変更、数ファイルです。それを超えるなら先に計画を立てます。明らかで低リスクの編集なら、BMadを通さずエージェントに直接頼む選択肢も文書に書かれています。

レビューの深さはquick(レビュアー1人)とthorough(観点の異なる複数人)の2種類です。bmad-buildの既定はquickで、bmad-code-reviewの既定はthoroughです。呼び出すときにthoroughと添えれば、その回だけ切り替えられます。

後回しにされた項目は、作業単位のフォルダか出力フォルダのdeferred-work.mdに残ります。1回の実行は1つの目標に絞られ、独立した複数の目標を渡すと、残りがここに回されるためです。実行後に開いて、次の/bmad-buildの入力に使えます。

Claude Code側で足しておきたい権限の線引き

bmad-buildはローカルへのコミットまで進めます。プッシュや共有ブランチへの反映まで任せたくない場合は、Claude Codeの権限ルールで線を引きます。次はプロジェクトの.claude/settings.jsonに置く例です。

{
  "permissions": {
    "deny": [
      "Bash(git push *)"
    ]
  }
}

これでBMadのスキルが走っている間も、git pushはClaude Codeの側で拒否されます。差分を読んでから自分で押す運用になります。

大きな作業は仕様、チケット、実装、振り返りに分ける

1回で収まらない作業は、先に意図を固めます。BMad Methodの考え方は「意図が十分に定義されているならbmad-specに渡し、そうでなければ定義できるまで他のスキルで詰める」です。

意図がまだ定義できていない場合の手段は、足りないものによって分かれます。

• 良いアイデアかどうかの確信がない: bmad-brainstorming、bmad-forge-idea
• 判断の根拠が足りない: bmad-deep-recon
• 製品が何かを文書にしたい: bmad-product-brief、bmad-prfaq
• 複数人の合意や承認が要る: bmad-prd
• 複数のエピックが従う共有の決定: bmad-ux、bmad-architecture

bmad-specには入力量の制約があります。一度に読み込める目安は数万トークン、約40ページ分で、それを大きく超える資料の山を渡すと重要な部分が黙って抜け落ちるため、事前に要約します。仕様書には、目的、機能(意図と成功条件)、制約、スコープ外、成功の指標の5項目が入ります。

仕様を渡したbmad-ticketは、エピックを一緒に計画して作業順に並べ、tickets.tomlにストーリーを記録します。bmad-buildは1回に1チケットを扱い、完了を示すところまでは自分で進めません。チケットはbuilt状態で止まり、完了にするのは人間の操作です。ここがBMad Methodの要所で、実装の完了判定をエージェントに任せない設計です。

人の入力を待たずに1セッション分を回すbmad-build-autoもあります。重要な実装判断が固まった後に使うスキルで、次のストーリーを選んだりバックログを管理したりはしません。

既存のコードベースでは、CLAUDE.mdを整えるところから

すでにあるプロジェクトでは、コードそのものが最大の情報源です。BMad Methodの文書は、コードで読み取れることをテキストで重ねて渡すと矛盾やコンテキストの肥大を招く、と述べています。そのため、導入直後に重い計画文書を作るのではなく、小さな変更ならbmad-buildに直接頼む流れを勧めています。

エージェントに伝えたい事柄が足りないときは、bmad-project-contextを使います。リポジトリのルートのAGENTS.mdに、検証済みの短い指示ブロックを書き込むスキルです。

/bmad-project-context agentが毎回テストランナーを間違える

書き込む前に完全なブロックを見せ、承認を求めます。ブロックは<!-- bmad:context -->と<!-- /bmad:context -->の間に置かれ、マーカーの外は変更されません。コミットも行いません。

Claude Codeは、CLAUDE.mdが無いプロジェクトではAGENTS.mdを読みます。すでにCLAUDE.mdがある場合は、bmad-project-contextが@AGENTS.mdのインポート1行を提案し、検証します。次の形です。

@AGENTS.md
 
## Claude Code固有の指示
- 変更後は必ず`npm test`を実行し、結果を報告する

両ファイルの併用の考え方はAGENTS.mdとCLAUDE.mdで設定を統合する運用パターンに、AGENTS.mdが読み込まれないときの切り分けはClaude CodeでAGENTS.mdが動かない2つの原因にあります。

書き込む内容にも基準があります。リポジトリの概要、ディレクトリツリー、技術スタックの一覧は入れません。エージェントはコードを読むほうが得意で、複製はすぐ古くなるためです。入るのは、コードが語れないことだけです。組織の方針、設定ファイルでは分からない実行上の落とし穴(テストに11分かかる、先にサービスの起動が要る、など)、エコシステムの既定と違う慣習、実際に観測された失敗、コンポーネント間の規則などです。

役割エージェントとの会話、複数エージェントの討論

AnalystやPMの視点が欲しい場面では、スキルIDでエージェントを読み込み、メニューのコードで作業を指示します。

/bmad-agent-pm
PRD

2行目のPRDが、PMのメニューにあるPRDの作成・更新・検証のコードです。PRDには作成、更新、検証の3つの意図があり、どれかを伝えるか、聞かれたら答えます。PRDは「何を、なぜ作るか」までを書く文書で、実装方法は扱いません。技術的な選択はaddendum.mdに分かれます。

複数の視点をぶつけたい場合はbmad-party-modeを使います。インストールされたエージェントが同じ会話に入り、キャラクターを保ったまま意見を交わし、あなたが進行します。モードは4種類です。

1つのモデルが5人分を演じると意見が揃いやすい、とドキュメントは述べています。独立した推論を取るならsubagentですが、その分コストは高くなります。ツールが指定のモードを実行できないときは、agent-teamからsubagent、sessionへ順に切り替わります。agent-teamはClaude Code専用です。

Claude Code側でサブエージェントにどのモデルを割り当てるかは、Claude Codeサブエージェントのモデル配分設計で扱っています。

チームの規約を上乗せする

エージェントや手順の挙動を変えるときは、インストール済みのファイルではなく、_bmad/custom/の上書きファイルを使います。更新で消えないためです。自分で書く代わりに、bmad-customizeに変更内容を伝えれば、適切な場所を選んで書き、結果を検証します。

上書きの優先順位は3層です。

1. _bmad/custom/<スキル名>.user.toml: 個人用。Git管理外
2. _bmad/custom/<スキル名>.toml: チーム用。コミットする
3. スキルが持つcustomize.toml: 既定値

PMの上書き例を、ドキュメントの例に沿って示します。実際に使えるフィールドは、インストール済みスキルのcustomize.tomlで確かめます。

# _bmad/custom/bmad-agent-pm.toml
[agent]
persistent_facts = [
  "Our org is AWS-only -- do not propose GCP or Azure.",
  "file:{project-root}/docs/compliance/hipaa-overview.md",
]

persistent_factsのような配列は、既定の項目の後にチーム、個人の順で追記されます。上書きでは既定の項目を削除できません。

つまずきやすい点

スキルが一覧に出ないときは、ツール側の設定でスキルが有効かを確かめ、再起動します。入れたはずのスキルが無いときは、Skills CLIは名前を挙げたスキルだけを入れるため、--skillの指定を足して再実行し、bmad setupを実行します。

削除されたモジュールのスキルが残る場合、インストーラーは古いディレクトリを消しません。手で削除するか、スキルのディレクトリごと消して入れ直します。

過去のスキルIDのbmad-create-prdやbmad-edit-prdは、現行のスキルへの転送として解決されます。新しい作業には現行の名前を使います。以前のv6のプロジェクトは、bmadにbmad migrate methodを頼めば現行の配置に移行できます。

cc-sddとの使い分け

仕様駆動の手法としてはcc-sddも選べます。目的が違うため、併記して判断材料にします。

cc-sddの手順はcc-sddでClaude Codeの仕様駆動開発を実践するに、思想の比較はClaude CodeとKiroを比較にあります。製品の調査や合意形成の工程まで同じ道具で揃えたいなら、BMad Methodが向きます。実装の自律度を軸に選ぶなら、cc-sddのほうが一直線です。

まとめ

BMAD-METHODは、役割エージェントの寄せ集めというより、変更の大きさに合わせて工程の深さを選ぶ道具です。まず/bmad-buildで小さな変更を1つ通し、計画の承認とレビューの流れに慣れるのが近道です。その後で、複数セッションの作業にbmad-specとbmad-ticket、組織の合意が要る場面にbmad-prdを足していきます。

Claude Code側では、git pushを拒否する権限ルールと、AGENTS.mdを指すCLAUDE.mdを最初に整えておくと、スキルが自動で進める範囲を保ったまま使えます。