5分で読める

はじめに

先週の木曜日、午後11時。私はAIエージェントにダッシュボードのデータ可視化パネルをデザインするよう依頼しました。エージェントは「完了した」と言いました。

git diff で確認してみると——12個のファイルが変更されていました。そのうち5個はモーダルコンポーネントとまったく無関係でした。サイドバーレイアウトのCSSは丸ごと書き換えられ、削除されるはずのなかったユーティリティ関数のファイルは消えていました。3箇所でスタイルの競合が発生していました。

画面の前で2分間、沈黙しました。怒りではありませんでした。深い疲労感でした。

振り返って計算してみました。過去3ヶ月間、AIエージェントにコンポーネント作成、スタイル修正、プロトタイプ制作——あらゆる作業を任せていました。トークン料金は日本円にして約15,000円。そして、エージェントが生み出したバグを修正するのに費やした時間——100時間以上でした。

そんなときにGitHub Trendingで見つけたのが Superpowers です。203,000 Stars、18,100 Forks、MITライセンス。読み始めて10分後、立ち上がって部屋の中を歩き回りました。そのパワフルさに驚いたのではなく——作者が私とまったく同じ苦しみを経験し、それをエージェントに装着可能な"プロセス外骨格"として形にしていたからです。

対象読者

この記事は以下のような方におすすめです：

AIコーディングエージェント（Cursor、Claude Code、GitHub Copilotなど）を毎日のプロジェクトで活用している
エージェントの「書きっぷりが速いけど、ミスも多い」というジレンマに悩んでいる
TDDやコードレビューといったソフトウェア工学のベストプラクティスをAIエージェントにも適用したい
203k Starsの注目プロジェクトが実際に何を解決するのかを短時間で理解したい
Superpowersの導入を検討しているが、コストやトレードオフも含めて判断したい

AIエージェントの3つの問題

AIコーディングエージェントを使い込めば使い込むほど、3つの問題に直面します。

1. フライング（Requirements Skipping）

ダッシュボードを「デザインして」と一言頼んだだけで——エージェントはデスクトップかモバイルかも聞かず、デザインシステムの確認もせず、既存ページのコンポーネントツリーも調べずに、いきなり数百行のコードを生成し始めます。書かせてみたら、こちらの意図とはまったく違うものになっている——そんな経験はないでしょうか。

2. 逸脱（Context Wandering）

AIエージェントは作業中に「ついでに」関係のないモジュールを「最適化」し始めます。ポップアップの間隔を調整してほしいだけなのに、デザインシステム全体の変数テーブルが書き換えられている。ボタンを1つ追加しただけなのに、レイアウトモジュールが丸ごとリファクタリングされている。AIに「頑張っている」ことは否定できません。しかし、その頑張りの方向がこちらの意図とまったく一致していないのです。

3. 成功の過剰宣言（Premature Success）

エージェントは「完了した」と言います。出力には「タスク成功」と表示されます。しかし、実際に実行してみるとStorybookがエラーを吐き、単体テストはパスせず、ダークモードのスタイルは考慮されていません。「確認ダイアログ付きモーダルコンポーネントを実装して」と頼んだら「できた」と言うが、そのコンポーネントが依存するUIライブラリがそもそもプロジェクトにインストールされていない——そんなことが日常的に起こります。

核心的な矛盾：AIエージェントは本質的に「高スループットのコードテキスト生成器」ですが、ソフトウェア工学に必要なのは「低エントロピーのインクリメンタルデリバリー」です。この2つは本質的に相反します。エージェントのコード生成速度が速ければ速いほど、あなたがハマる落とし穴の頻度も上がります。速度は解決策ではありません。速度は拡大鏡です。あなたのプロセスに元々あった問題を、10倍に拡大するだけです。
— Source: 本稿執筆者の実体験より

なぜ長いプロンプトでは解決できないのか

私も試しました。本当に試したのです。

300行のプロジェクトインストラクションファイルを書きました。制約条件、実例、禁止事項を盛り込み、システムプロンプトも最適化しました。

効果は？多少ありました。持続性は？ありませんでした。

エージェントは断続的に古い癖に戻ります。まるで「とても賢いけど、こちらの話をまったく聞いていない同僚」のようです。「関係のないファイルを勝手に変更しないで」と伝えても、5ターンも会話が進めばコンテキストウィンドウがロールして忘れてしまいます。「先にテストを書いて」と言うと「はい」と答え、実際には assert true とだけ書いてある。

これはエージェントのせいではありません。「プロセス規律」というアーキテクチャレベルで保証されるべきものを、テキストによる「お願い」に委ねていた側の問題です。

重要な洞察：Superpowersの核心的な設計思想は——エージェントに理屈で説得しようとしない。プロセス外骨格を装着させる。各ステップに検証があり、チェックポイントがあり、スキップは許されない。
— Source: Superpowers公式ドキュメントより要約

Superpowersの作者は、より良いプロンプトテンプレートを作ったわけではありません。ソフトウェア工学のベストプラクティス——要件明確化、ワークスペース分離、タスク分割、TDD、コードレビュー、ブランチ完了処理——を、すべてスキップ不可能なステップとして実装したのです。

🔗 Source: Superpowers GitHub

具体的な7ステップワークフロー

Superpowersを装着したAIエージェントは、以下の7ステップを強制されます。

Step 1 — ブレインストーミング（要件確認）

エージェントはコードを書き始める前に止まります。そして質問を投げかけてきます：「このダッシュボードはデスクトップ向けですか、モバイル向けですか？使用するデザインシステムは？既存ページのコンポーネントツリー構造は？対応すべきブレークポイントは？」——「フライング」の問題は、この最初のゲートで阻止されます。

Step 2 — ワークツリー（作業分離）

「まず隔離されたワークスペースを作成します」——これがワークツリーです。メインのブランチには触れません。レイアウトモジュールにも触れません。グローバルスタイルにも触れません。エージェントは完全なサンドボックス内で作業します。「逸脱」が物理的に隔離されます。

Step 3 — プランニング（タスク分割）

「ダッシュボードをデザインする」という大雑把な1行ではなく、src/components/Modal/index.tsx の85行目以降にダークモード対応を追加、既存の3つのStorybookテストを実行して既存コンポーネントを破壊しないことを確認——という粒度まで具体化します。各タスクは2〜5分で完了できるサイズに分割されます。

Step 4 — サブエージェント（並行実行）

分割された各タスクは、独立したサブエージェントによって実行されます。

Step 5 — TDD（テスト駆動開発）

これは最も強力なステップです。エージェントはまず必ず失敗するテストを書きます。赤信号（テスト失敗）を確認してから、ようやくそれを通過させるコードを書くことが許されます。緑信号（テスト通過）を確認した後、リファクタリングできます。テストをスキップする？プロセスが先に進みません。「成功の過剰宣言」は、TDDの赤信号も緑信号も一度も点灯していないエージェントが「完了した」と言えない仕組みで防がれます。

Step 6 — コードレビュー

セキュリティ上の脆弱性？即差し戻し。論理的な欠陥？マージをブロック。スタイルの問題？マークはするがブロックはしない。

Step 7 — フィニッシング（完了処理）

完全な検証を実行した上で、4つの選択肢が提示されます：マージ／PR／保存／破棄。あなたが選びます。

一言で言えば：Superpowersは「ソフトウェア工学的規律」を人間のチェックリストから、エージェントの実行パスに変換したものです。エージェントが従わない？次のステップに進めない。それだけです。

4層アーキテクチャ

Superpowersはシンプルなフォルダ構成ではありません。4つの層で設計されています。

層	役割
配布層（Distribution）	スキルを異なるエージェントに搭載。複数プラットフォームに同一のスキルを配布
強制層（Enforcement）	エージェント起動時にプロジェクトインストラクションを直接注入。最初の指示は「ルールを遵守せよ」
実行層（Execution）	ブレインストーミング、TDD、ワークツリー、サブエージェント、コードレビュー——すべて呼び出し可能なスキルファイルとして実装
検証層（Verification）	Hooksとテストで、各スキルが実際のエージェントセッションで遵守されているかを確認

従来のスキルシステムは「工具箱を隅に置いてある。エージェントは使ってもいいし、使わなくてもいい」というものでした。Superpowersは「工具箱を玄関に置き、『ここから道具を取らなければドアは開かない』と書いてある」状態を作り出します。

さらに特筆すべきはメタスキルループの存在です。Superpowersには writing-skills というスキルが含まれており、これを使って新しいSuperpowersスキルの書き方を学べます。「セキュリティチェックのステップが足りない」と感じたら、自分でスキルを書いてワークフローに追加できます。このフレームワークは自己進化できるのです。

🔗 Source: Superpowers Architecture Docs

正直な欠点

私自身、Superpowersの支持者です。しかし、その完璧さを称えるつもりはありません。

トークン消費が2〜3倍に増加

7つのステップ、各ステップでエージェントが大量のコンテキスト情報を処理。ブレインストーミングで数百行、プランニングでさらに数百行、TDDサイクル（赤→緑→リファクタリング）で最低3往復。従来1000トークンで済んでいた作業が3000トークンになります。API料金は2〜3倍。これはハードなコストです。

プロセス摩擦が顕著

3行のコードを追加したいだけのときもあります。単なる if 判定の追加です。しかしSuperpowersはブレインストーミング→プランニング→サブエージェント→TDD→コードレビュー→フィニッシングと進めさせます。壁に1本の釘を打って絵を掛けたいだけなのに、Superpowersは「まず地質調査をし、次に構造計算をし、それから建設許可を取得し、最後に監理検査を受けなさい」と言っているようなものです。

インストールの敷居は低くない

npm install で終わるものではありません。4層アーキテクチャの理解、各プラットフォーム用ハーネスの設定、プロジェクトインストラクションの優先順位調整、フックの正常動作確認——問題が起きたときの原因特定には時間がかかります。

TDDは必須——逃げられない

TDDを使わない開発スタイルの場合、Superpowersは非常に使いづらいでしょう。これは「オプション」ではありません。コアプロセスのハード制約です。

PR貢献のハードルは極めて高い

PRの94%が却下されています。この数字は一見恐ろしいですが、別の見方をすれば——プロジェクトが方法論の純粋性を維持するための代償です。「プロセスフレームワーク」が妥協を許しすぎると、いつの間にか「おすすめ集」になってしまいます。

向かないシナリオ：1回限りのスクリプト、プロトタイプの高速検証、単純なチャットレベルのタスク、Gitやテストの習慣がないチーム、トークン予算が極度に限られている場合。

🔗 Source: Superpowers GitHub Discussions

比較：Microsoft Amplifier と GitHub Speckit

比較軸	Superpowers	Microsoft Amplifier	GitHub Speckit
核心的な位置づけ	実行規律 + TDDプロセスフレームワーク	開発補助フレームワーク	要件駆動開発
制約の強さ	強い（スキップ不可）	部分的	強い
対応プラットフォーム	11プラットフォーム	主にMicrosoftエコシステム	主にGitHubエコシステム
TDD強制	はい——コアプロセス	推奨だが強制ではない	対象外
コミュニティ規模	203k Stars	小規模	小規模
インストール複雑度	中〜高	低	中
メタスキル	あり（自己進化可能）	なし	なし
トークン消費	2〜3倍	約1.5倍	1.5〜2倍

一言で言えば：AmplifierはMicrosoftエコシステムの開発アシスタント、SpeckitはGitHubエコシステムの要件駆動ツール、Superpowersは現時点で唯一、TDDとコードレビューをエージェントの実行パスに書き込んだクロスプラットフォームフレームワークです。

🔗 Source: Superpowers Comparison

導入すべき人、すべきでない人

今すぐインストールすべき人：

毎日AIエージェントを本格的なプロジェクトで使っている
エージェントの「書きっぷりが速いが、ミスも多い」という問題に本気で悩んでいる
TDDやコードレビュー、ブランチ管理といった工学的規律を尊重している
プロジェクトに中程度以上の複雑さがある
トークン料金が2〜3倍になっても、「すべての変更を自分でレビューする必要がない」ことを選びたい

先に導入を見送るべき人：

たまに小規模スクリプトをAIに書かせるだけ
トークン予算が厳しく制限されている
Gitやテストの習慣がまだない——まずはこれらの基礎を固めるべき
AIを「より速いタイピスト」として位置づけている

最終的なアドバイス：週に2回以上「エージェントは書き終えたが、自分が修正しなければならない」という経験があるなら、Superpowersを導入する価値があります。そのコストは現実的です。しかし、導入しないことのコストは、それ以上かもしれません。

🔗 Source: Superpowers Getting Started

まとめ

私はSuperpowersを導入しました。導入から3日目。

AIエージェントがコンポーネントを設計する前に、初めて質問をしてきました——

「この要件の範囲はモーダルコンポーネントのみで、グローバルレイアウトには影響しませんか？」

この一行を、私は5秒間見つめていました。

それがどれほど賢いからではありません。制約を受けたエージェントが、ついに本当のエンジニアのように働き始めたからです。

Superpowersはエージェントをより賢くするツールではありません。エージェントに規律を与えるフレームワークです。もしあなたが「エージェントに振り回されている」と感じたら——一度、試してみてください。

🔗 Superpowers GitHub