AIコーディングエージェントに「依頼したら、いきなりコードを書き始める」問題を感じたことはないでしょうか。仕様確認なし、テストなし、計画なしでコードを量産し、結局はバグの修正に時間を取られる——「速く動くもの」は作れても「正しく動くもの」は苦手、というのがAIエージェントの弱点です。Superpowers(スーパーパワーズ)は、この弱点を「プロの開発作法をスキルとして自動注入する」という発想で克服する、オープンソースのスキルフレームワークです。作者はJesse Vincent氏(Prime Radiant)、ライセンスはMIT。GitHubで約246,000スター(2026年7月時点)という、スキル系OSSとしては桁違いの支持を集めています。
この記事を読むと、①Superpowersで結局何ができるのか(AIエージェントに仕様確認・TDD・サブエージェント駆動開発を自動注入し、数時間の自律開発を回す)、②どんな課題を解決するのか(AIエージェントの「いきなりコードを書く」問題)、③何を代替できるのか(毎回「TDDで」「テストを先に」と指示する手作業、属人的な開発プロセス)が分かります。AIエージェント全般の地図を先に押さえたい方は、AIエージェントフレームワーク徹底比較2026を合わせて読むと、Superpowersがどの層を担うのかが立体的に掴めます。
- ・Superpowersは、AIコーディングエージェントにプロの開発作法を注入するスキルフレームワーク(MIT・約246,000★)。
- ・仕様確認→計画→TDD→サブエージェント駆動→レビュー→完了処理の7ステップを自動実行。
- ・14のスキルが状況に応じて自動連携。Markdown1ファイルで独自スキルも追加できる。
- ・TDDを強制し、テストで正当化されないコードは削除。YAGNI原則も自動適用。
- ・Claude Code・Cursor・Codex・Gemini CLI・Copilot CLIに対応。導入はほぼ1コマンド。
1. Superpowersとは:AIエージェントに“プロの作法”を注入するスキルフレームワーク
Superpowersは、公式の言葉を借りれば「実際に機能する、エージェント型のスキルフレームワーク兼ソフトウェア開発方法論」です。ひとことで言えば、AIコーディングエージェントに「プロのエンジニアがやっている作法」を後付けする外部脳。導入すると、エージェントは依頼を受けても即座にコードを書き始めず、まず一歩下がって「あなたは本当は何を作ろうとしているのか」を問い直すようになります。
ここで鍵になるのが、Superpowersのアプローチが「プロンプトエンジニアリング」ではなく「スキル注入」である点です。ユーザーが毎回「TDDで進めて」「テストを先に書いて」「計画を立てて」と指示する必要はありません。エージェントが、タスクの状況に応じて自分で適切な行動規範(スキル)を選び、呼び出す——この自動性が本質です。
Superpowersが立っている場所を整理すると、次の3つを1つに束ねた点が新しいと言えます。
・スキル注入:毎回の指示なしに、構造化ワークフローが自動で起動する
・TDD強制:RED-GREEN-REFACTORを徹底し、テストなしの実装を許さない
・サブエージェント駆動:計画を分担して並行実行し、数時間の自律開発を可能にする
- ・Superpowers=AIエージェントに「プロの開発作法」をスキルとして注入するフレームワーク。
- ・「毎回指示する」プロンプト運用でなく、エージェントが自分で作法を選ぶのが核心。
なお、Superpowersが乗る土台である「Claude Codeのスキル/ハーネス」という仕組みそのものを深掘りしたい方は、Claude Code完全ガイド2026を合わせて読むと、Superpowersが何を拡張しているのかが分かりやすくなります。
2. なぜ必要か:AIエージェントの「いきなりコードを書く」問題を解決する
Superpowersが解決するのは、AIコーディングエージェントが構造的に抱える「作法の欠如」です。通常のエージェントは、依頼を受けた瞬間にコードを書き始めます。仕様の確認も、テストの設計も、計画の立案もない。結果として「動くけど意図と違う」コードが量産され、手戻りが発生します。
具体的な弱点はこうです。
・仕様が曖昧なまま実装開始:何を作るべきかを詰めずに書き始める
・テストが後回し/省略:動作の裏づけがないまま「動いた」ことにする
・長時間作業で計画から逸脱:文脈が劣化し、当初の意図からズレていく
・「動いた」の自己申告で完了:客観的な検証がないまま終わったことにする
・「念のため」の不要コード:使いもしない実装が積み上がる
Superpowersは、これらを一つひとつ、明確なスキルで潰します。従来の課題と解決策を対応させると、こうなります。
| 従来の課題 | Superpowersによる解決策 |
|---|---|
| 仕様が曖昧なまま実装開始 | brainstormingスキルでソクラテス式に質問 |
| テストが後回し/省略 | TDDスキルでRED-GREEN-REFACTORを強制 |
| 長時間作業で計画から逸脱 | サブエージェント駆動で各タスクを独立実行 |
| メインブランチを汚す | git worktreeで隔離環境を自動構築 |
| 「動いた」の自己申告で完了 | テスト通過と2段階レビューで客観判定 |
| 不要な「念のため」コード | YAGNI原則を自動適用 |
- ・Superpowersはエージェントの振る舞いを大きく変えるため、初回はテンポが遅く感じることがある。
- ・ただし計画に時間を投じることで後段のやり直しが激減し、トータルでは時短になるケースが多い。
この課題が効いてくるのは、扱うコードが「重要」で、かつ作業が長時間に及ぶほどです。使い捨てのスクリプトなら作法は要りませんが、本番のコードベースを、数時間かけて育てる場面では、「いきなり書く」ことの手戻りコストが跳ね上がります。Superpowersは「速さ」を少し犠牲にして「正確さ」を取る——その割り切りが刺さるのは、まさにこうした重要な開発です。
3. 7ステップの構造化ワークフロー:brainstorm→plan→TDD→review
Superpowersを導入したエージェントは、次の7ステップの構造化ワークフローを自動的に実行します。各ステップは前提条件を検証してから次に進むため、計画とのズレが起きにくいのが特徴です。
仕様の抽出・設計精練"] --> B["2. using-git-worktrees
隔離環境の構築"] B --> C["3. writing-plans
実装計画の作成"] C --> D["4. subagent-driven-development
サブエージェント駆動実装"] D --> E["5. test-driven-development
RED-GREEN-REFACTOR"] E --> F["6. requesting-code-review
コードレビュー"] F --> G["7. finishing-a-development-branch
完了処理・マージ判断"] G -.->|"次の機能開発"| A
各ステップで何が起きるのか、要点を追いましょう。
① brainstorming(仕様の抽出):コードを書く前に、エージェントがユーザーへ質問を投げかけます。「認証方式は? OAuthかパスワードか」「セッション管理はJWTかCookieか」——ソクラテス式に掘り下げ、設計ドキュメントを生成します。ポイントは読み切れる長さのチャンクに分割して提示し、ユーザーが全体像を把握したうえで承認できること。エージェントは推測でコードを書かず、必ず確認する——「速さ」より「正確さ」を取る思想がここに表れます。
② using-git-worktrees(隔離環境の構築):設計承認後、git worktreeで隔離ブランチを自動作成し、既存テストがクリーンに通ることを確認してから作業を始めます。メインブランチを汚さず、安全に開発できます。
③ writing-plans(実装計画の作成):READMEの原文が計画の粒度を端的に表現しています。「趣味が悪く、判断力がなく、プロジェクト文脈を知らず、テストを嫌がる、熱意だけのジュニアエンジニアでも追従できる明確さ」。各タスクは2〜5分で完了する粒度に分解され、対象ファイルの正確なパス・書くべきコードの全体像・検証ステップが明記されます。この細かさが、次のサブエージェント駆動を成立させる鍵です。
④〜⑦(サブエージェント駆動→TDD→レビュー→完了):計画の各タスクをサブエージェントが分担し(第4章)、TDDで実装し(第5章)、重大度別にレビューし(第5章)、最後に人間が完了処理を判断します。完了処理では、全テストの通過を確認したうえで、マージ/PR作成/ブランチ維持/破棄の4択をユーザーに提示します。
- ・各ステップが前提条件を検証してから進むため、途中で計画から逸脱しにくい。
- ・完了処理は「人間に最終判断を委ねる」設計。エージェントが勝手にmainへマージしない。
4. 主要スキルとサブエージェント駆動開発
Superpowersには14のスキルが含まれ、各スキルは SKILL.md ファイルとして実装されています。エージェントは状況に応じて適切なスキルを呼び出します。主なものを整理します。
| カテゴリ | 代表スキル | 役割 |
|---|---|---|
| テスト | test-driven-development | RED-GREEN-REFACTORサイクル(アンチパターン集付き) |
| デバッグ | systematic-debugging | 根本原因を追う体系的デバッグ |
| デバッグ | verification-before-completion | 修正が本当に完了したかの検証 |
| 仕様・計画 | brainstorming / writing-plans | ソクラテス式の設計精練・詳細な実装計画 |
| 協働 | subagent-driven-development | 2段階レビュー付きの高速イテレーション |
| 協働 | requesting/receiving-code-review | レビューの依頼と体系的な反映 |
| ブランチ | using-git-worktrees / finishing-a-development-branch | 隔離開発とマージ判断 |
| メタ | writing-skills / using-superpowers | 独自スキルの作成ガイドと入門 |
このなかでも、Superpowersの自律性を支えるのがサブエージェント駆動開発です。実装計画の各タスクに対して個別のサブエージェントを起動し、各サブエージェントがタスクを実装したうえで2段階レビュー(仕様準拠チェック→コード品質チェック)を通過してから先に進みます。この流れを図にすると次のようになります。
ポイントは、各サブエージェントがフレッシュな文脈で起動することです。長時間の連続作業でも、1つの巨大な文脈を引きずらないため、文脈の劣化(話が長くなるほど精度が落ちる現象)が起きにくい。「計画を細かく割り、フレッシュな担当に配り、2段階で検品する」——この分業が、人間の介入なしに数時間の自律開発を成立させています。同様にタスク分割と自律実行を重視するOpenHandsと比べると、Superpowersは特定フレームワークではなく「既存のコーディングエージェントに作法を注入する」層である点が異なります。
そして、スキルはMarkdownファイル1つで記述できます。複雑な設定や拡張機構は不要で、エージェントが自然言語の指示として読み込んで実行します。writing-skillsスキル(=スキルの書き方を教えるスキル)を使えば、自社の開発フローを独自スキルとして追加でき、/plugin updateで新スキルが自動的に使えるようになります。プロトコルに沿って拡張する発想は、MCPサーバー構築ガイドとも通じるものがあります。
5. TDD強制とコードレビュー:品質を担保する仕組み
Superpowersの中核であり、最も特徴的なのがTDDの強制です。エージェントは次のサイクルを徹底します。
・RED — まず失敗するテストを書く
・GREEN — テストを通す最小限のコードを書く
・REFACTOR — リファクタリングして整える
・COMMIT — コミットして次のテストへ
ここで効いてくるのが、「テストの前に書いたコードは削除される」という強い規律です。テストで正当化されない実装は残さない。これがSuperpowers最大の制約であり、最大の強みでもあります。あわせてYAGNI(You Aren’t Gonna Need It)原則が自動適用され、「念のため」の不要な実装が排除されます。
- ・テストで裏づけられないコードは削除される。「とりあえず書く」が通用しない。
- ・その代わり、動くコードには必ずテストが付き、YAGNIで無駄が削がれる。
もう一つの品質担保がコードレビューです。タスク間でレビューを実行し、問題を重大度別に分類します。
| 重大度 | 動作 | 例 |
|---|---|---|
| Critical | ブロッキング、即修正必須 | テスト失敗、セキュリティ欠陥 |
| Major | 強く推奨 | パフォーマンス問題、誤った抽象化 |
| Minor | 任意対応 | コメント不足、命名の改善 |
重要なのは、Criticalが出たら、それを解決するまで次のタスクに進めないという設計です。問題を先送りにせず、その場で潰す。この「重大な問題はブロッキング」というルールが、長時間の自律開発でも品質が崩れない歯止めになっています。「テスト通過」という客観的な事実だけを完了の根拠にする——「動いた」という自己申告を許さない姿勢が、Superpowersの品質の源泉です。
6. 導入:Claude Code等へのインストールと動作確認
Superpowersは主要なAIコーディングツールに対応しています。最も簡単なのがClaude Codeの公式マーケットプレイス経由で、コマンド一発です。
# Claude Code(公式マーケットプレイス)
/plugin install superpowers@claude-plugins-official
カスタマイズ版や派生スキルを使いたい場合はコミュニティ版を、他ツールを使う場合は各方式を選びます。主要プラットフォームの導入方法を整理します。
| プラットフォーム | 導入方法 |
|---|---|
| Claude Code(公式) | /plugin install superpowers@claude-plugins-official |
| Claude Code(コミュニティ) | /plugin marketplace add obra/superpowers-marketplace → /plugin install |
| Cursor | /add-plugin superpowers(またはマーケットプレイスで検索) |
| Codex / OpenCode | INSTALL.mdをエージェントにフェッチさせる |
| GitHub Copilot CLI | copilot plugin marketplace add obra/superpowers-marketplace |
| Gemini CLI | gemini extensions install https://github.com/obra/superpowers |
派生スキルやカスタマイズ済みのワークフローを使いたい場合は、公式ではなくコミュニティ版マーケットプレイスを登録してからインストールします。
# Claude Code(コミュニティ版:派生スキル・カスタマイズを使う場合)
/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers
Claude Code以外のツールも、ほぼ1〜2コマンドで導入できます(Codex / OpenCodeのみ INSTALL.md をエージェントにフェッチさせる方式)。
# GitHub Copilot CLI
copilot plugin marketplace add obra/superpowers-marketplace
# Gemini CLI
gemini extensions install https://github.com/obra/superpowers
導入後は、本当にスキルが起動しているかを確認しましょう。新しいセッションで次を試します。
・新しいセッションを開始する
・「この機能を計画して」と依頼する → エージェントが質問を返してくればbrainstormingスキル発動
・「このバグをデバッグして」と依頼する → エージェントが仮説検証ステップを提示すればsystematic-debuggingスキル発動
「1コマンドで導入 → 計画を頼んで質問が返れば成功」——この手軽さで、エージェントの動きが根本から変わります。もしエージェントがいきなりコードを書き始める場合は、セッションが古いか、プラグインが有効化されていない可能性があります。アップデートは /plugin update superpowers で、新スキルが自動的に使えるようになります。
7. 導入判断・運用のベストプラクティス
最後に、導入すべきかの判断材料と運用のコツを整理します。まず適性から。
| ユースケース | 適性 | 理由 |
|---|---|---|
| 新規機能の実装 | 高 | 仕様抽出から計画まで体系的に進む |
| バグ修正 | 高 | systematic-debuggingで根本原因を追える |
| 大規模リファクタリング | 高 | サブエージェント駆動の並列処理が活きる |
| ワンライナースクリプト | 低 | オーバーヘッドが大きすぎる |
| PoC・実験コード | 中 | TDD強制が重く感じる場面がある |
向いている人
・重要なコードベースを、品質を保って育てたい
・AIに数時間の自律開発を任せ、手戻りを減らしたい
・チーム開発で、レビュー品質を平準化したい
・Claude Code等を使っており、1コマンドで開発作法を底上げしたい
慎重に判断すべきケース
・捨てるコード(実験・PoC・ワンライナー)が中心(強制が重い)
・トークン消費を最小化したい(レビュー・サブエージェントで消費は増える)
・エージェントの挙動を完全に手動制御したい(Superpowersは自動で作法を差し込む)
運用のベストプラクティスも押さえておきましょう。最重要は、brainstormingフェーズで手を抜かないこと。ここでの質問にしっかり答えると後段が安定し、逆に省略すると計画も実装も崩れます。次に、レビューでCriticalが出たら、他タスクを進めずに先に解決すること。そして、チームで使うならworktreeブランチの命名規則を共有しておくと衝突を防げます。
- ・「プロセスを買う」フレームワーク。トークン消費は増えるが、手戻り削減で総コストは下がることが多い。
- ・捨てるコードには不向き。本番・重要コードから順に適用するのが賢い。
- ・brainstormingを省略しない。ここが後段の品質を左右する。
Superpowersは、AIコーディングの土台であるClaude Codeのスキル機構の上に成り立っています。その全体像はClaude Code完全ガイド2026で、他のエージェントフレームワークとの位置づけはAIエージェントフレームワーク徹底比較2026で押さえておくと、Superpowersを過不足なく使えます。
まとめ
Superpowersは、AIコーディングエージェントに「プロのエンジニアの作法」を注入するスキルフレームワークです。仕様確認→計画→TDD→サブエージェント駆動→レビュー→完了処理という7ステップの構造化ワークフローを自動で回すことで、「速く動くもの」は得意だが「正しく動くもの」は苦手、というAIの弱点を、プロセスの強制で克服します。
- ・Superpowersは、AIエージェントにプロの開発作法を注入するスキルフレームワーク(MIT・約246,000★)。
- ・7ステップワークフローと14スキルが自動連携し、ユーザーは特別な操作なしで恩恵を受ける。
- ・TDDを強制し、テストで正当化されないコードは削除。YAGNIで無駄も排除する。
- ・サブエージェント駆動+2段階レビューで、数時間の自律開発と品質を両立する。
- ・重要なコードベース・チーム開発に刺さる。PoCやワンライナーにはオーバーヘッドが大きい。
「AIに任せると品質が下がる」という固定観念は、Superpowersのようなプロセス注入型OSSで覆りつつあります。重要なコードベースほど、その恩恵は大きい。まずは公式マーケットプレイスから1コマンドで導入し、エージェントの動きの違いを体感してみてください。エージェント全般の地図はAIエージェントフレームワーク徹底比較2026を、土台となるClaude CodeはClaude Code完全ガイド2026を、スキル拡張の発想はMCPサーバー構築ガイドを、それぞれ合わせて読むと理解が立体化します。
参照ソース
・obra/superpowers (GitHub) — 公式リポジトリ。スキル・ワークフロー・インストール方法の一次ソース(MIT License)。
・Superpowers for Claude Code(Jesse Vincent氏のブログ) — 作者による設計思想の解説。
・Claude Plugin Marketplace(公式) — Claude Code向けの公式配布ページ。