目次
この記事のポイント
- Matt Pocock Skills は単一リポジトリ内で
docs/agents/を真実の源にする「設定寄りの手法」 - BMad Method は Brief → Spec → Architecture → Stories を Markdown 資産として残す「プロセス寄りの手法」
- 両者は対立ではなく、組織規模・既存コードの有無・判断の重みで使い分けが成立する
- ハイブリッド：Matt Pocock 流の単一リポジトリ設定の上に、BMad 流の意思決定資産を重ねるのが SAP×AI 案件の現実解
01WHAT 「スキルを渡す」と「判断を資産化する」の根本的な違い
AI エージェントを組織に導入するとき、多くのチームが「どのツールを使うか」「どのモデルを選ぶか」で議論を始めます。しかし本番運用に入って 2〜3 か月後に立ち上がるのは、ツール選定ではなくエージェントがどこで何を書くか、判断の根拠がどこに残るかという 2 つの論点です。この 2 つに対するアプローチが、Matt Pocock 流と BMad Method の決定的な違いを生みます。
Matt Pocock の /setup-matt-pocock-skills は「スキルを渡す」設計寄りの手法です。リポジトリ内に docs/agents/issue-tracker.md・domain.md・triage-labels.md の最大 3 ファイルと、CLAUDE.md または AGENTS.md の ## Agent skills ブロックを書き、スキル本体は一切編集しません。スキルが同じ設定を読むため、エージェントの挙動はリポジトリ単位で一貫します。
BMad Method は「判断を資産化する」プロセス寄りの手法です。Clarify（Brief）→ Plan（Spec・Architecture）→ Build（Stories・Code）→ Verify（Tests・Review）→ Learn（Retrospective）の 5 フェーズを循環させ、各段階の判断を Markdown に残します。誰が読んでも判断根拠を辿れる状態が、リポジトリを横断して蓄積されます。
比較表：Matt Pocock Skills と BMad Method の 8 つの観点
両者の差を 1 枚の表に整理します。同じ「AI エージェント運用」でも、立ち位置が大きく違うことが分かります。
| 観点 | Matt Pocock Skills | BMad Method |
|---|---|---|
| 中心思想 | エージェントに skills を渡す | 判断を Markdown 資産として残す |
| 中心成果物 | docs/agents/ 配下の 3 ファイル | Brief → Spec → Architecture → Stories |
| 適用単位 | 単一リポジトリ | エピック / プロジェクト全体 |
| 導入コスト | 低（/setup-matt-pocock-skills 数十分） | 中（初回セットアップ + モジュール選定） |
| 既存コード | ゼロからの立ち上げ or 単一リポ前提 | 既存コードベース向けフローあり |
| 組織スケール | 小〜中規模 | 中〜大規模、複数エージェント並行 |
| 監査・再現性 | スキルが同じ設定を読むため挙動が一貫 | 意思決定が Markdown で残るため追跡可能 |
| 弱点 | 判断の履歴は残らない | 単一リポ前提を破ると設定が散らばる |
共通点：どちらも「AI に判断させる範囲を明示する」哲学
Matt Pocock 流と BMad Method は対立するように見えて、哲学の根は同じです。「AI に判断させる範囲」を明示的に定義し、人間と機械の責任境界を設計として残す。Matt Pocock 流はこれを docs/agents/ の 3 ファイルで、BMad Method は Brief → Spec → Stories の流れで実現します。視点が違うだけで、目指す方向は同じです。
両者の弱点と、相互補完の可能性
Matt Pocock 流の弱点は判断の履歴が残らないことです。issue-tracker.md は「どこに何を書くか」だけを定め、「なぜそう書いたか」は記録しません。一方、BMad Method の弱点は単一リポジトリ前提を破ると設定が散らばることです。Brief・Spec・Stories が複数リポジトリに分散すると、横断検索が難しくなります。
この 2 つの弱点は恰好の相互補完点になります。Matt Pocock 流の docs/agents/ を真実の源として整備し、その上に BMad 流の Brief / Spec / Architecture を docs/briefs/・docs/specs/・docs/adr/ として積み上げる。両者が同じリポジトリ内にあれば、エージェントは docs/agents/ で動き方を読み、docs/specs/ で判断根拠を読む——これは SAP×AI 案件で実際に機能するハイブリッド構成です。
02POINTS 組織規模別の選び方 5 ステップ
ここからは両者を組織規模別に選ぶ 5 ステップを整理します。「正解は 1 つ」ではなく、規模・既存コード・判断の重みで使い分けるのが現実的です。
- ①個人開発・プロトタイプMatt Pocock 流で十分です。
/setup-matt-pocock-skillsを 1 回走らせてdocs/agents/3 ファイルを書き、CLAUDE.mdまたはAGENTS.mdに## Agent skillsブロックを置く。所要時間は 30 分程度で、判断の履歴までは要らない場面に向きます。 - ②スタートアップ・小チーム（5 人以下）Matt Pocock 流を土台に、BMad の Brief / PRD 部分だけ取り込みます。
docs/briefs/に 1 段落の Brief を残し、レビューで参照する形にすれば、軽量さを保ったまま判断の痕跡が残ります。Plan や Stories は省略可。 - ③中規模チーム（10〜30 人）・新規プロダクトBMad Method フルセットを採用します。Brief → Spec → Architecture → Stories の流れで判断の履歴を残し、Verify → Learn の振り返りで次イテレーションの閾値調整をします。Matt Pocock 流はリポジトリ設定の補助として併用。
- ④大規模・エンタープライズ・既存 SAPMatt Pocock 流で各リポジトリの
docs/agents/を整備し、その上に BMad 流の意思決定資産をレイヤー化します。FI/CO/MM/SD のような業務領域ごとに Brief / Spec をモジュール化し、複数チームが参照できる共通フォーマットに揃えます。 - ⑤両方を併用する場合の現実解
docs/agents/issue-tracker.mdに BMad の Spec / Architecture ディレクトリへの参照を 1 行だけ追記します。これにより、エージェントは「Spec があるなら参照、なければ従来通り」というルールで動けます。設定とプロセスの橋渡しはこの 1 行で済みます。
第 5 ステップのブリッジは「1 行だけ」
両者を併用する場合の最大の罠は、設定とプロセスの両方を丁寧に整えようとして結局運用が破綻することです。現実解は docs/agents/issue-tracker.md の末尾に「Spec は docs/specs/ を参照、Architecture は docs/adr/ を参照」と 1 行だけ書くこと。エージェントはそれを実行時に読み、判断の重みによって BMad 成果物を参照します。残りは現場で育てます。
導入順序の現実解
両方を導入する場合の現実的な順序は「Matt Pocock 流を先に 1 リポジトリで立ち上げ、BMad 流の Brief / Spec を部分的に重ねる」です。Matt Pocock 流は単一リポジトリで完結するため、最初の実験が容易です。一方 BMad 流はプロジェクトを横断する意思決定資産を扱うため、初手で全社展開すると運用が追いつきません。1 リポジトリで両者を動かし、効果が確認できたら横展開する——この順序が ADT の SAP×AI 案件で安定して機能しています。
03INSIGHT SAP×AI 案件でのハイブリッド運用の現実解
SAP×AI の案件は、Matt Pocock 流と BMad Method の両方が活きる典型例です。前者はリポジトリ単位の設定で AI エージェントの挙動を揃え、後者は業務判断（FI 設定・MM 購買プロセス・SD 販売プロセス）の履歴を資産化します。SAP の領域では暗黙の前提が特に多く、判断の履歴が残らないと後年の保守で必ず詰まります。
ADT の推奨ハイブリッド構成は次の通りです。Matt Pocock 流で docs/agents/ を整備し、エージェントに「FI の会社コードは docs/specs/fi-org.md 参照、MM の購買組織は docs/specs/mm-org.md 参照」のようなルールを渡す。BMad 流で各 Spec をモジュール別に作成し、Brief と Stories は案件のサブエージェントが参照できる形で残す。AI エージェントが S/4HANA の標準 API を叩く前に、必ず該当 Spec を読むフローにすることで、誤転記のリスクを下げます。
姉妹記事として、Matt Pocock 流の設定フローを深掘りした AIエージェント時代のSkills設計：Matt Pocock流・単一リポジトリ運用の設計図 と、BMad Method の 5 フェーズを解説した BMad Methodとは？AI駆動アジャイル開発で意思決定を「資産」として残す手法 があります。両者を併せて読むことで、本記事の比較表が現場で使える運用パターンの選択肢になります。
AI が業務ロジックを直接実行しない設計思想は AIエージェントとワークフローの使い分け：Build Process AutomationとHuman-in-the-loopの設計 で、LLM 実行基盤の選択肢は SAP BTP CAP入門：Cloud Application Programming Modelで作るS/4HANA拡張アプリ と ローカルLLMで実現する、安全なSAP×AI活用 でそれぞれ解説しています。
豆知識：BMad は商標・Matt Pocock 流は流派名
BMad と BMAD-METHOD は BMad Code, LLC の登録商標（TRADEMARK.md で運用指針が公開）ですが、Matt Pocock 流はあくまで通称で、商標として保護された名称ではありません。記事中で「Matt Pocock 流」と書くときは原文（aihero.dev）での名称を尊重し、彼の思想の要約である点を併記するのが誠実な書き方です。
まとめ
- Matt Pocock 流は単一リポジトリの設定で AI エージェントの挙動を揃える「設定寄りの手法」
- BMad Method は Brief → Spec → Architecture → Stories を Markdown 資産として残す「プロセス寄りの手法」
- どちらも「AI に判断させる範囲を明示する」哲学を共有し、規模・既存コード・判断の重みで使い分けが成立する
- 個人・小チームは Matt Pocock 流、中・大規模・既存 SAP はハイブリッド運用が現実解
- ハイブリッド時のブリッジは
docs/agents/issue-tracker.mdに 1 行だけ Spec / Architecture への参照を書く - 初手は 1 リポジトリで両者を動かし、効果が確認できたら横展開する
04FAQ よくある質問
両方を同時に使うべきですか？
必須ではありません。最初の 1 リポジトリでは Matt Pocock 流で立ち上げ、意思決定の重みが増えたら BMad の Brief / Spec を docs/agents/ と並行して書き始めるのが低リスクです。両方を混ぜる場合は docs/agents/ を真実の源、BMad の成果物を参照という役割分担を崩さないでください。設定とプロセスのブリッジは docs/agents/issue-tracker.md の 1 行で済みます。
既存 SAP プロジェクトにはどちらが合いますか？
BMad Method の Start in an Existing Codebase フローが適合します。BMad の bmad-project-context スキルで既存構造を把握し、Brief / Spec を既存コードに合わせて書きます。Matt Pocock 流はリポジトリ単位で setup を 1 回済ませる形になるため、エージェントの挙動統一を補助的に併用します。両者の併用が SAP×AI 案件の現実解です。
投資対効果（ROI）の観点で選ぶべき基準は？
判断の履歴が資産になるかどうかが ROI の分水嶺です。判断が繰り返され、前提が変わる領域（SAP 移行、規制対応、複数年運用）なら BMad が投資対効果を出します。判断が安定し、同じスキルが何度も走る領域なら Matt Pocock 流が軽量で済みます。1 リポジトリに両者を併用する場合、Matt Pocock 流が 30 分、BMad 流が初回セットアップで半日〜1 日が目安です。
社内で統一すべきですか？
完全統一は不要です。Matt Pocock 流の単一リポジトリ設定はリポジトリごとに独立なので、リポジトリ単位で選択できます。BMad 流の意思決定の Markdown 資産はプロジェクトをまたいで検索・参照できる必要があるため、共通フォーマットを決めたほうが運用が楽になります。ADT では Spec の見出しレベル（背景・要件・設計・影響範囲・リスク）を全社で統一しています。
出典・参考
- aihero.dev — /skills/setup-matt-pocock-skills（Matt Pocock） https://www.aihero.dev/skills-setup-matt-pocock-skills
- GitHub — bmad-code-org/BMAD-METHOD（BMad Method 公式） https://github.com/bmad-code-org/bmad-method
- docs.bmad-method.org — Choose a Planning Path（計画パスの選び方） https://docs.bmad-method.org/plan/choose-a-planning-path/
- docs.bmad-method.org — Start in an Existing Codebase（既存コードベース向け導入） https://docs.bmad-method.org/existing-codebases/start-in-an-existing-codebase/
※本記事は上記の公開情報をもとに、アラディンテクノロジー株式会社編集部が独自に整理・考察したものです。内容は執筆時点（2026-09-27）の情報です。Matt Pocock 流のセットアップ手法と BMad Method は活発に更新されており、最新仕様はそれぞれの原文（aihero.dev / docs.bmad-method.org）でご確認ください。考察部分は当社の見解であり、特定の製品・導入を推奨するものではありません。