コーディングエージェントの開発メソッドについて(Superpowers / Spec Kit / BMAD-METHOD)

Cursor や Claude Code のようなコーディングエージェントは、指示を出せばコードを書いてくれます。しかし、雑な指示で書かせたコードは品質がバラつきます。設計を飛ばす、テストを書かない、既存コードと矛盾するetc…

こうした問題を解決するために「エージェント向けのメソッド・ワークフロー」が積極的に開発されています。コードを書く前に設計を固めさせたり、テストを先に書かせたり、レビューを挟ませたりする仕組みをルールとして組み込み、人間が張り付かなくても品質を保てるようにするものです。

GitHub 上にはこの種のメソッドやフレームワークが乱立していますが、本記事では特に人気のある3つを取り上げます。

導入方法については、コーディングエージェントが使える環境内で各プロジェクトにドキュメントを配置するか、Claude CodeやCursorのプラグイン機能を使いますが、長すぎるためここでは割愛します。

参考:

CLAUDE.md / Rules / Skills / Subagentsの役割と使い分け

https://cursor.com/ja/docs/skills

プラグインについて

Superpowers

https://github.com/obra/superpowers

Superpowers のワークフローの流れ自体はシンプルです。まず brainstorming スキルが発動して、質問で要件を絞り2-3案を提示します。ここには 制約がかかっていて、人間が承認しないかぎり実装に進めません。承認が出ると writing-plans がタスクを2-5分単位に分解し、ファイルパスと検証手順を添えた計画を作ります。実装に入るとタスクごとにサブエージェントが起動し、完了時には仕様準拠と品質の2段階レビュー。最後に finishing-a-development-branch がマージ・PR・維持・破棄の4択を提示して、ブランチの後始末まで面倒を見てくれます。

ブレスト → worktree作成 → 計画 → サブエージェント実装 → レビュー → 完了

最大の特徴はTDD(テスト駆動開発)を厳しく強制する点にあります。RED-GREEN-REFACTOR をスキルとして強制し、テストなしのコードは「削除しろ」とまで言い切ります。品質保証も多層的で、2段階レビューに加え、完了主張前の検証強制や4段階の根本原因調査を行うデバッグスキルも備えています。

サブエージェントのコントロールにも力を入れています。

カスタマイズはスキルの追加・改変で行います。YAML フロントマター付き Markdown で書かれていて、ユーザー設定(CLAUDE.md 等)がスキルより優先される設計なので、チーム固有のルールの上書きも簡単です。導入は /plugin install superpowers の一発で、Claude Code や Cursor のプラグインとして動きます。

個人的には一番興味があります。既存のプロジェクトにも導入はできそうですが、どちらかというと新規のプロジェクトの方が動かしやすいかなという印象です。

Spec Kit

https://github.com/github/spec-kit

Spec Kit は GitHub 社が公式に出しているフレームワークです。他は個人プロジェクトが多いことを考えると、Githubが組織として公開・メンテナンスしているという安心感があります。

仕様を一次資産とし、コードはその実装物にすぎないと位置づけた考え方です。所謂仕様駆動開発です。

2026年現在だと、コンテキスト重視でオーソドックスな進め方なのかなという印象です。

ワークフローはスラッシュコマンドで1フェーズずつゲートを通過していく構造です。最初に /speckit.constitution でプロジェクトの「憲法」を定めます。「テストを先に書く」「過度な抽象化を禁止する」といった原則をここで宣言し、以降のすべてのフェーズを拘束する。次に /speckit.specify で機能仕様、/speckit.plan で技術計画とデータモデル、/speckit.tasks で依存関係つきのタスク一覧を作り、最後の /speckit.implement で初めてコードに触れます。

/speckit.constitution → /speckit.specify → /speckit.plan → /speckit.tasks → /speckit.implement

実装フェーズの縛りがSuperpowersより強力ではないこともあり、企業で導入する際に合意を取りやすそうな印象です。

BMAD-METHOD

https://github.com/bmadcode/bmad-method

名前と専門性を持つ複数の AI エージェントに役割分担させ、アジャイル開発の各フェーズを「専門家チーム」として回す、というアプローチです。3つの中で唯一、エージェントに人格を与えています。

ワークフローはアジャイル開発の4フェーズをそのまま踏襲しています。Analysis でアナリストがブレストとプロダクトブリーフを作り、Planning で PM と UX デザイナーが PRD と UI 設計を担当し、Solutioning でアーキテクトがシステム設計とストーリーを策定し、Implementation でデベロッパーがスプリント実装、スクラムマスターがコードレビューを行います。

Analysis → Planning → Solutioning → Implementation

それぞれのエージェントに Mary、Winston といった名前がついていて、コミュニケーションスタイルまで定義されています。複数エージェントを同時に呼び出して議論させる party mode まであるので、遊び心を感じます。

実装はストーリー単位の一括実行方式です。「途中で止めるな、完了まで一気に実行しろ」「書かれていないことは実装するな」という強い指示がワークフローに埋め込まれていて、スコープクリープを防ぎつつ一気通貫で仕上げる思想です。TDD も Red-Green-Refactor をワークフロー内の手順として指示しており、強制度は高めです。

拡張は公式モジュール(ゲーム開発、テスト設計など)で専門領域に対応でき、BMad Builder でペルソナの独自定義も可能です。

個人的な所感として、アジャイル開発の組織にいたことがないためワークフロー理解度に自信はないですが、面白いアプローチだと感じました。

まとめ

最終目的はどれも、「AI中心の開発において、品質を上げる」ことなのですが、それぞれ全く違ったアプローチや思想があり、今現在この領域は面白い時期にあると再確認しました。

再現性が高いベストプラクティスが登場するまでは、組織ごとに戦略を考えて導入していくという時期なのではないでしょうか。

私個人としても、人気のワークフローやメソッドを読み込んで学んでいきたいと考えています。