はじめに
Superpowers — Claude Code / Codex / OpenCode 向けのエージェンティック・スキル・フレームワーク
⭐ 40k Stars | 🍴 3k Forks | 👀 234 Watching
海外で爆発的な人気を集めているこのフレームワークを、本記事で詳しく紹介させていただきます。
2025年から2026年にかけて、AIコーディングツールは驚くべき進化を遂げました。Claude Code、Cursor、Windsurf——これらのツールは、自然言語でコードを生成できる時代を実現しました。
しかし、多くの開発者がこんな経験をしています：
「AIに任せたら、テストを書かずにいきなり実装を始めた」
「要件を確認せずに、勝手な解釈でコードを書き始めた」
「完了と言ったのに、実際には動かないコードだった」
これは 「思いつき実装」問題です。AIは指示されたことを素早く実行しますが、開発プロセスの規律を自ら守ることはありません。
本記事では、この問題を解決するフレームワーク 「Superpowers」 を徹底解説します。Superpowersの仕組みから実践的な使い方まで、スキル別に詳しく見ていきましょう。
第1章：Superpowersとは何か
「思いつき実装」問題
AIコーディングツールは強力ですが、放っておくと以下のような振る舞いをします：
| 症状 | 具体例 |
|---|---|
| 要件の飛ばし読み | ユーザーの意図を深掘りせず、表面的な指示だけで実装を始める |
| テストの省略 | 「動くコード」を最短で書こうとし、テストを後回しにする |
| 完了の早とちり | 検証せずに「完了しました」と宣言する |
| 場当たり的デバッグ | 根本原因を調べず、思いついた修正を試し続ける |
これらは「AIが悪い」のではなく、開発プロセスを強制する仕組みがないことが原因です。
Superpowersの解決アプローチ
Superpowersは、AIエージェントに開発規律を強制するフレームワークです。
核心となる考え方：
- スキルベースのワークフロー — 状況に応じて適切な「スキル」が自動的に呼び出される
- 上流から下流への強制フロー — Spec（仕様）→ Plan（計画）→ Execute（実装）→ Verify（検証）→ Finish（完了）
具体的には、Superpowersは14の「スキル」を提供し、AIエージェントがそれぞれの状況で適切なプロセスを踏むよう誘導します。
この設計により、AIは「思いつき」ではなく「プロセスに従った」開発を行います。
第2章：Superpowersのアーキテクチャ
スキルベースのアプローチ
Superpowersの中核は スキル（Skills） です。スキルとは、特定の状況で呼び出される「ワークフローの定義」です。
各スキルは以下を定義します：
- いつ使うか（トリガー条件）
- 何をするか（具体的な手順）
- どう検証するか（完了条件）
| スキルカテゴリ | 含まれるスキル | 目的 |
|---|---|---|
| 設計・合意 | brainstorming | 実装前に要件を深掘りし、設計を合意する |
| 計画化 | writing-plans | タスク粒度に分解し、検証手順を含む計画を作成 |
| 実装 | executing-plans, subagent-driven-development | 計画に沿って段階的に実装 |
| 品質保証 | test-driven-development, verification-before-completion | TDDと検証の強制 |
| デバッグ | systematic-debugging | 科学的手法による根本原因特定 |
| レビュー | requesting-code-review, receiving-code-review | レビュープロセスの標準化 |
| Git運用 | using-git-worktrees, finishing-a-development-branch | 作業分離と統合 |
テスト駆動開発の強制
Superpowersの最大の特徴の1つは、TDD（テスト駆動開発）の強制です。
test-driven-development スキルは、RED-GREEN-REFACTORサイクルを厳格に守らせます：
重要なルール：
- テストを先に書く（実装から始めない）
- 失敗を確認してから実装する
- 最小限のコードでテストを通す
- リファクタリングはテストが通った状態で行う
2段階コードレビュー
Superpowersは、サブエージェント実行後に2段階のレビューを行います：
- 仕様準拠レビュー — 計画通りに実装されているか
- コード品質レビュー — 設計、保守性、ベストプラクティス
この仕組みにより、「動くけど汚いコード」が本番に入ることを防ぎます。
検証の強制
verification-before-completion スキルは、AIが「完了しました」と宣言する前に、必ず検証を行わせます：
禁止されること：
- 検証コマンドを実行せずに「成功」と主張する
- エラーを無視して先に進む
- 「おそらく動く」という推測に基づく完了宣言
強制されること：
- 実際にテストを実行し、出力を確認する
- すべてのエラーを解決する
- 証拠に基づいて完了を宣言する
第3章：インストールと初期設定
インストール方法
Claude Code の場合（推奨）：
/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace
インストール確認：
/help
以下のコマンドが表示されれば成功です：
/brainstorm/write-plan/execute-plan
アップデート：
/plugin update superpowers
Codex / OpenCode の場合
手動セットアップが必要です。詳細は公式リポジトリの INSTALL.md を参照してください。
初期設定のポイント
Superpowersは設定ファイルなしで動作しますが、以下の運用が推奨されます：
1. プロジェクトルールの設定
.claude/rules/ ディレクトリにプロジェクト固有のルールを配置することで、Superpowersの動作をカスタマイズできます。
2. カスタムスキルの追加
独自のスキルを作成して、チーム固有のワークフローを強制できます。詳細は writing-skills スキルを参照。
第4章：主要スキル一覧
コアワークフロー
| スキル | 用途 |
|---|---|
brainstorming |
実装前に要件を深掘りし、設計オプションを検討して合意を形成 |
writing-plans |
合意した設計から、2〜5分で完了できるタスク粒度の実装計画を作成 |
executing-plans |
作成した計画を段階的に実行し、チェックポイントで確認 |
実装支援
| スキル | 用途 |
|---|---|
test-driven-development |
RED-GREEN-REFACTORサイクルの強制。すべての実装はテストから始める |
subagent-driven-development |
タスクごとに独立したサブエージェントを割り当て、2段階レビューを実施 |
dispatching-parallel-agents |
依存関係のないタスクを並列実行 |
Git運用
| スキル | 用途 |
|---|---|
using-git-worktrees |
Git Worktreeを使って作業空間を分離し、安全に開発 |
finishing-a-development-branch |
実装完了後のマージ/PR作成/クリーンアップをガイド |
品質保証
| スキル | 用途 |
|---|---|
verification-before-completion |
完了宣言前の検証を必須化。証拠なき成功主張を禁止 |
systematic-debugging |
4フェーズの根本原因分析。当てずっぽう修正を禁止 |
レビュー
| スキル | 用途 |
|---|---|
requesting-code-review |
レビュー依頼の出し方と確認観点を整理 |
receiving-code-review |
レビューコメントの理解と適切な反映をガイド |
メタスキル
| スキル | 用途 |
|---|---|
using-superpowers |
Superpowersの基本的な使い方と、スキル適用の判断基準 |
writing-skills |
新しいスキルの作成方法と、SKILL.mdの書き方 |
第5章：ユースケース別 実践ガイド
5-1. 新機能の設計と実装
シナリオ: ユーザー認証機能を追加する
Step 1: ブレインストーミング
/brainstorm ユーザー認証機能を追加したい
Superpowersが対話的に要件を掘り下げます：
「認証方式はJWT、セッション、OAuth2のどれを想定していますか？」
「パスワードリセット機能は必要ですか？」
「2要素認証は初期リリースに含めますか？」
この対話により、曖昧な「認証機能」が具体的な仕様に変わります。
Step 2: 実装計画の作成
/write-plan
ブレインストーミングの結果を基に、詳細な実装計画が作成されます：
## 実装計画: ユーザー認証機能
### Task 1: ユーザーモデルの作成
- ファイル: src/models/user.ts
- 実装: email, passwordHash, createdAt, updatedAt フィールド
- 検証: `npm test -- --grep "User model"`
### Task 2: パスワードハッシュユーティリティ
- ファイル: src/utils/password.ts
- 実装: bcryptを使用したhash/verify関数
- 検証: `npm test -- --grep "Password utils"`
### Task 3: 認証ミドルウェア
- ファイル: src/middleware/auth.ts
- 実装: JWTトークン検証、リクエストへのユーザー付与
- 検証: `npm test -- --grep "Auth middleware"`
...
各タスクは2〜5分で完了できる粒度に分割されています。
Step 3: テスト駆動で実装
/execute-plan
各タスクはtest-driven-developmentスキルに従って実行されます：
- RED: 失敗するテストを書く
- GREEN: テストを通す最小限のコードを書く
- REFACTOR: コードを改善する（テストは通ったまま）
// Step 1: RED - 失敗するテストを書く
describe('User model', () => {
it('should create a user with hashed password', async () => {
const user = await User.create({
email: 'test@example.com',
password: 'password123'
});
expect(user.passwordHash).not.toBe('password123');
});
});
// Step 2: GREEN - テストを通す
// Step 3: REFACTOR - 必要に応じて改善
ポイント: 「テストなしの実装」が物理的に不可能になります。
5-2. 難解なバグの体系的デバッグ
シナリオ: 「ログイン後にセッションが維持されない」というバグ
Step 1: 体系的デバッグの開始
バグに遭遇すると、systematic-debuggingスキルが自動的に適用されます。
禁止されること：
- 「たぶんこれが原因」で修正を試みる
- 複数の変更を一度に行う
- 原因を特定せずにコードを変更する
強制されること：
- 4フェーズの根本原因分析
Step 2: 4フェーズ分析
フェーズ1: 観察
- セッションクッキーは送信されているか？
- サーバーログにエラーはあるか？
- どの条件下で発生するか？
フェーズ2: 仮説構築
仮説A: クッキーのSameSite設定が不適切
仮説B: セッションストアの接続が切れている
仮説C: JWTの有効期限が短すぎる
フェーズ3: 検証
- 各仮説を検証するためのログを追加
- 1つずつ仮説を検証
- 根本原因を特定
フェーズ4: 修正
- 根本原因に対する最小限の修正
- 修正後の検証
- 再発防止テストの追加
ポイント: 「なんとなく直った」ではなく、原因を特定してから修正します。
5-3. コードレビューのワークフロー
シナリオ: 実装が完了し、レビューを依頼する
レビュー依頼側
# レビューを依頼
/requesting-code-review
requesting-code-reviewスキルが以下を整理します：
- 変更の概要
- 影響範囲
- 特に見てほしいポイント
- テスト結果
レビュー受領側
# レビューを受け取った
/receiving-code-review
receiving-code-reviewスキルが以下を強制します：
- 各コメントの理解（不明点は質問）
- 技術的な妥当性の検証
- 盲目的な同意の禁止
重要なルール：
- レビュアーが間違っている可能性も検証する
- 「言われたから直す」ではなく「理解して反映する」
- 不明点は必ず質問する
5-4. 並列開発とWorktree活用
シナリオ: 複数の独立した機能を並行開発する
Step 1: Worktreeで作業分離
# 機能Aの作業空間を作成
git worktree add ../project-feature-a feature/auth
# 機能Bの作業空間を作成
git worktree add ../project-feature-b feature/notifications
using-git-worktreesスキルにより、各機能は完全に分離された環境で開発されます。
Step 2: 並列エージェントの起動
/dispatching-parallel-agents
dispatching-parallel-agentsスキルが以下を管理：
- 各エージェントに独立したタスクを割り当て
- 依存関係のチェック
- 結果の統合
Step 3: 開発完了と統合
/finishing-a-development-branch
finishing-a-development-branchスキルが以下をガイド：
- マージ vs PRの選択
- コンフリクト解決
- Worktreeのクリーンアップ
ポイント: 複数機能の並行開発でも、混乱なく進められます。
5-5. カスタムスキルの作成
シナリオ: チーム固有のワークフローを強制したい
Step 1: スキルファイルの作成
writing-skillsスキルに従って、SKILL.mdを作成します：
---
name: team-pr-checklist
description: チーム固有のPRチェックリストを強制
---
## このスキルを使う条件
PRを作成する前に必ず適用する。
## 手順
1. すべてのテストが通っていることを確認
2. lint/formatが適用されていることを確認
3. 変更行数が500行以下であることを確認
4. ドキュメントが更新されていることを確認
5. セキュリティレビューが必要かどうかを判断
Step 2: スキルの配置
.claude/
skills/
team-pr-checklist/
SKILL.md
これで、PRを作成しようとすると自動的にこのスキルが適用されます。
ポイント: チームの規律を「ドキュメント」ではなく「強制」できます。
第6章：なぜSuperpowersは機能するのか
「ルール」ではなく「スキル」
多くのチームがCONTRIBUTING.mdやコーディング規約を持っています。しかし、AIはこれらを「参考にする」だけで、必ずしも従いません。
Superpowersは、ルールをスキルとして実装することで、AIがプロセスを飛ばせなくします。
| 従来のアプローチ | Superpowers |
|---|---|
| 「テストを書いてください」と指示 | テストから始めないと実装できない |
| 「レビューを受けてください」と依頼 | レビュー完了まで完了と言えない |
| 「検証してから完了にして」とお願い | 検証コマンドの実行なしに完了不可 |
スキルの自動適用
Superpowersは、状況に応じて適切なスキルを自動的に呼び出します。
開発者が「今はブレインストーミングをしよう」と明示的に指示しなくても、新機能の話が始まるとbrainstormingスキルが適用されます。
拡張性
Superpowersは14のコアスキルを提供しますが、チーム固有のスキルを追加できます。
- Marketplace: 20以上のバトルテスト済みスキル
- Lab: 実験的なスキル
- カスタム: チーム独自のワークフロー
第7章：GSD vs Superpowers — 2つのフレームワークの比較
AIコーディングの品質を高めるフレームワークとして、Superpowersの他に GSD（Get Shit Done） も注目を集めています。
比較表
| 観点 | Superpowers | GSD |
|---|---|---|
| 主な焦点 | 開発方法論の徹底（TDD、レビュー、検証） | コンテキスト劣化の防止、大規模開発の自動化 |
| アプローチ | スキルベースのワークフロー誘導 | タスクを極小化し、サブエージェントに分散 |
| アーキテクチャ | モジュラーなスキルシステム | オーケストレーター + 専門エージェント群 |
| 強み | TDD強制、コードレビュー、品質管理 | プロジェクト全体のオーケストレーション、並列実行 |
| 哲学 | 「方法論を徹底してAIの品質を上げる」 | 「AIをリードエンジニアに」 |
| インストール | /plugin install superpowers@superpowers-marketplace |
npx get-shit-done-cc |
それぞれの得意領域
Superpowersが得意なこと：
- テスト駆動開発（RED-GREEN-REFACTOR）の徹底
- コードレビューワークフロー
- 設計段階でのブレインストーミング
- 品質重視の慎重な開発
GSDが得意なこと：
- ゼロからの大規模プロジェクト立ち上げ
- 長時間にわたる開発セッション
- 複数フェーズに分割された計画的な開発
- 既存コードベースへの機能追加
連携の可能性
両者は補完関係にあります：
- GSD = 「何を・どう分割するか」のオーケストレーション層
- Superpowers = 「どう作るか」の方法論・品質層
併用の例：
-
/gsd:new-projectでプロジェクトを初期化し、ロードマップを作成 -
/gsd:plan-phase 1で最初のフェーズを計画 - 各タスクの実装時に、Superpowersの
test-driven-developmentスキルを適用 -
/gsd:verify-workで全体の検証
両方をインストールしている環境では、GSDの大局的な管理とSuperpowersの方法論的な厳密さを組み合わせることで、より高品質な開発が期待できます。
第8章：まとめ
Superpowersが実現すること
Superpowersは、AIを「言われたことをやる実行者」から 「開発規律を守るプロフェッショナル」 に変えるフレームワークです。
解決する課題：
- テストを書かない「思いつき実装」
- 検証なしの「完了宣言」
- 当てずっぽうの「場当たりデバッグ」
実現するワークフロー：
- ブレインストーミングによる要件の明確化
- テスト駆動開発の強制
- 体系的デバッグと品質保証
今日から始める
/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace
このコマンドで、あなたのAI開発に「規律」が生まれます。
参考リンク
- GitHub: https://github.com/obra/superpowers
- Marketplace: https://github.com/obra/superpowers-marketplace
- Lab（実験的スキル）: https://github.com/obra/superpowers-lab
- GSD: https://github.com/glittercowboy/get-shit-done
著者注: 本記事は2026年1月時点の情報に基づいています。Superpowersは活発に開発が進んでいるプロジェクトのため、最新の機能やスキルについては公式リポジトリをご確認ください。