Superpowersとは
皆さんは、こちらのプラグインをご存知でしょうか？
詳しい解説や導入方法は公式や先人たちの記事に委ねるとして、おおまかに説明すると次のようなものです。
- 最近人気を集めている、AIエージェントによる開発（AI駆動開発）のためのフレームワーク
- Claude Codeのプラグインとして提供されている（公式マーケットプレイスから入れられる。CodexやGemini CLIなど、ほかのエージェントにも対応）
- 中身の中心は「スキル」の集まり。要件を聞き出す
brainstorming、実装計画を立てるwriting-plans、テスト駆動開発を強制するtest-driven-development、原因を体系的に調べるsystematic-debugging、レビューを依頼するrequesting-code-reviewなどがある - 加えて、セッションの開始時にスキルの使い方を読み込ませるフックがあり、AIは作業に入る前に必ず該当するスキルを確認し、それに従って動く。スキルは「推奨」ではなく「必須の手順」として扱われる
- 開発プロセスの規律（設計してから作る・テストを先に書く・検証してから完了と言う）を徹底的に守りながら実装する
流れとしては、人が関わるのは主に最初の設計（spec）と実装計画（plan）の承認で、そのあとはAIが計画に沿って自律的に実装・テスト・レビューを回していきます。
私がSuperpowersの存在を知ったのはごく最近で、まだ1か月くらいしか経っていません。それでも使ってみてとても良かったので、個人開発で使った感想と、業務で使うことを考えたときに思ったことを残しておきます。
個人開発で使ってみた感想
自律性が高く、長時間のタスクを任せられる
一度計画を承認すれば、あとはAIが自律的に実装・テスト・レビューを何時間もかけて進めてくれます。開発規律を守りながら徹底的にやるので、実行時間自体は長くなります。自分しか使わない個人用のアプリでも、1つの計画を承認した後のAIの稼働時間（人が考えている時間などは含めず、AIが動いていた時間だけ）が連続1時間を超えたり、アプリ全体で通算10時間以上になったりすることはざらにあります。長いタスクを丸ごと任せられるのは大きな強みです。
なお、その間ずっと流れていく画面を眺めているのは時間の無駄ですし暇を持て余します。全然関係のない別のタスクを進めるのが良いと思います。仕事じゃないならYouTubeを見るなり読書するなり自由に過ごすのもありでしょう。
完成度が非常に高く、その思想どおり開発規律を守りながら高品質なアプリができる
プラグインとしての完成度も非常に高いです。brainstorming で要件を丁寧に引き出してくれるのも良いのですが、私が特に完成度の高さを感じたのは次の点です。
TDD（テスト駆動開発）を徹底する
実装は必ず「失敗するテストを書く → 失敗することを確かめる → 最小限の実装でテストを通す」の順で進みます。テストより先に書かれたコードは消して書き直させるほどの徹底ぶりで、「とりあえず動くものを作って、テストは後で」ということが起きません。
そして、これが実際に品質の高さにつながっています。すべての振る舞いにテストが付いた状態で開発が進むので、後から機能を足したり作りを変えたりして既存の部分を壊しても、その場でテストが落ちて気づけます。人が触って確かめる段階まで不具合が残っていることも少なく、手戻りが少ないと感じました。
スラッシュコマンドを打たなくても、スキルが自動でトリガーされて適切に進行する
AIは作業に入る前に、該当するスキルがないかを必ず確認します。新しい機能を作ろうとすれば brainstorming が、不具合があれば systematic-debugging が、実装に入れば test-driven-development が、人が何も指示しなくても呼ばれます。どのスキルをいつ使うかを人が覚えておく必要がなく、普通に会話しているだけで正しい手順に乗ってくれます。
コードレビューまでちゃんとやる
サブエージェント駆動ではタスクごとに、そして最後にブランチ全体に対して、レビューを行います。このレビューは、実装したエージェントとはコンテキストを共有しない、独立したエージェントが行います。
実装したエージェント自身に見直させると、自分が書いた経緯や思い込みに引っ張られて、問題を見落としがちです。実装の経緯を何も知らない別のエージェントに、そのタスクの要件や差分など必要なものだけを渡してレビューさせるほうが、ずっと多くの問題を見つけてくれます。この「コンテキストを共有しない独立したエージェントによるレビュー」の有用性は普段から感じていたところで、それがSuperpowersには最初から組み込まれています。
こうして、「設計してから作る」「テストを先に書く」「第三者の目でレビューする」「検証してから完了と言う」といった、人間がやると面倒でついサボりがちな規律を、AIが本当に毎回守ります。結果として、出来上がるアプリの品質はかなり高いと感じました。
サブエージェント駆動で開発できる。ただし、条件によってはなかなか推奨されない
私はこのサブエージェント駆動に、Superpowersの特徴の中でも特に注目していました。
subagent-driven-development では、計画のタスクごとに新しいサブエージェントを立ち上げて実装させ、独立したエージェントがそのつどレビューします。メインのエージェントは全体の進行役に徹するので、コンテキストが実装の細部で埋まっていかず、何時間もの長い実行でも計画から外れずに進んでくれます。
しかし、実際に使ってみると、このサブエージェント駆動になかなかならない場面がありました。
AIは計画を書き終えると、実装に入る前に次のどちらで進めるかを聞いてきます。
- Subagent-driven: タスクごとにサブエージェントが実装し、そのつどレビューする
- Native: 今のセッションで自分が全タスクを実装し、最後にブランチ全体を1回だけレビューする
このとき、計画の内容からどちらかを推奨してきます。
私の場合、Dockerで完全に動かせるアプリを作ったときは、多数のタスクをサブエージェント駆動で進めました。一方で、AWSのサーバーレス・マネージドサービス中心のバックエンドがあり、GPSを使うために屋外でのテストが必要な機能も持つAndroidアプリを作ったときは、ほぼNativeが推奨されてサブエージェント駆動にはなりませんでした。ローカルで完結しない場合、途中で人の確認や人にしかできない操作が入る場合、タスク同士の依存関係が強い場合には、Nativeになりがちな印象です。
サブエージェント駆動とタスクごとのレビューの恩恵は、作るものの技術選定やアーキテクチャによっては十分に受けられない点に注意が必要です。
永続化されるのはspecとplanだけなので、状態を残す工夫が要る
ここは勘違いのなきように、1つのplanの中では、状態の管理はしっかりしています。 planの実行中は、どのタスクまで終わったか・途中で何を判断したかを一時的なファイル（ledger）に記録しながら進むので、途中でセッションが切れても、そこから再開できます。中断にはかなり強いです。
ただし、このledgerはplanの実行が終わると消され、次のplanには引き継がれません。そして、planより上の単位、つまりspec（サブプロジェクト）やプロジェクト全体の単位では、状態を永続化する仕組みがありません。ファイルとして残るのは、specとplanの文書そのものだけです。
実際の開発では、1つのspecが複数のplanに分かれることがよくあります。planの切り方はAIが提案してくれるもので、規模が大きくて1つのplanに収まらないときに分かれることもあれば、フロントエンドとバックエンドのように作る対象ごとに分かれることもあります。さらにその上位でも、brainstorming の途中で「大きいのでサブプロジェクトに分けましょう」「この機能は後回しにしましょう」とAIから提案されることが多いです。ところが、分けたあとにspecが作られるのは直近の1つだけで、残りは順番が来て改めて brainstorming するまでspecがありません。
つまり、図のplanより上にあたる情報（全体の分け方・後回しにしたもの・どのspecのどのplanまで進んで次に何をやるのか・途中で分かったことのうち次のplan以降に効くもの）は、会話の中にしか残りません。
一方で、planやspecの区切りではセッションを切り替えたくなります。終わったplanのやり取りや捨てた案、エラーの出力などでコンテキストが汚染されると、AIの判断の精度が落ちるからです。特にサブエージェント駆動にならなかったときはコンテキストが汚染されやすいです。コンテキストをきれいに保つために切り替えたいのに、切り替えると実装済み以外の情報が消えるので、会話の外に永続化しておく工夫が要ります。
なぜこうなっているのかというと、想像にはなりますがSuperpowersの関心はあくまで開発規律を守ることにあり、plan、specより上の、プロジェクトをどう分けてどう管理するかなどといった部分は開発者に委ねられているからだと思っています。
独自のドキュメントや進め方を組み込みやすく、開発者の好みに合わせやすい
ただ、開発者に委ねられているということは、裏を返せば、Superpowersがspecとplan以外のドキュメントにほとんど口を出さないということでもあります。そのため、足りない部分を独自のドキュメントで補いやすく、独自の進め方を組み込んでもうまく順応してくれます。
私は、プロジェクト全体の状態（分け方・後回しにしたもの・進み具合・次にやること）を書くファイルをリポジトリのルートに置き、セッションの最初に読ませ、specやplanの区切りで更新させています。これで、区切りごとに気軽にセッションを切り替えられるようになりました。ほかにも、次のようなものを組み合わせて使っています。
- Superpowersに入る前に、その枠組みの外で要件定義・画面一覧・画面遷移図・画面モック（HTML）を別途作っておき、
brainstormingの材料にする - 上記は
brainstormingやそれ以降で変更が決まれば更新する - 決定の記録（ADR）を残し、「なぜこうなっているか」を後から辿れるようにする
- 後回しにしたレビューの指摘や機能をGitHubのissueに書き出し、次の
brainstormingで範囲を決めるときに見る
いずれもSuperpowersの流れと衝突することなく、自然に組み込めました。ドキュメントの体系や進め方を、開発者の好みに合わせやすいと感じました。
これらの具体的な中身や運用の仕方は、後日、別の記事でも紹介できればと思います。
Markdownファイルが多すぎて、全部は読めない
Superpowersで開発したプロジェクトの行数を拡張子ごとに数えてみると、ソースコードよりもMarkdownのほうがはるかに多いことがわかります。主要な拡張子だけを抜き出すと、次のとおりです。
.py |
.kt |
.ts |
.vue |
.md |
うちplan | |
|---|---|---|---|---|---|---|
| Androidアプリ（バックエンドを含む） | 5,004 | 12,594 | 1,291 | — | 50,835 | 41,073 |
| Webアプリ（バックエンドを含む） | 11,872 | — | 2,793 | 1,801 | 32,309 | 28,461 |
なお、数えたのはgit管理下の永続的なファイルだけです。planの実行中に使われる .superpowers/ 以下のledgerなどの一時的なファイルや、git管理外の作業用のファイルは含めていません。それでもこの量です。
どちらも、Markdownの行数がソースコードの2〜3倍になっています。そして、その大半はplanです。
なぜこうなるのかというと、planがあまりにも徹底的だからです。writing-plans は「文脈を知らないエンジニアでも迷わず実装できる」ことを目指して、タスクごとに正確なファイルパス・完全なコード・確かめ方まで書きます。つまり、planのファイルにはテストと実装のソースコードがほぼそのまま書かれています。実際、planの中のコードブロックの行数を数えると、Androidアプリのほうで約3万2千行、Webアプリのほうで約2万1千行ありました。
実装の前にplanを承認することになっていますが、正直、これを全部読むなんて考えられません。
追記（直近のアップデートについて）
この記事の執筆最後のAIレビューで指摘を受けたのですが、Superpowersのv6.4.2（2026-09-25）で writing-plans の方針が変わったそうです。私自身はまだ未確認ですが、これによってplanには完全なコードを書かず、関数のシグネチャ・テストのアサーション・specで決まっている値など、実装を担当するAIが自分では決められないことだけを書くようになったようです。関数の中身は、実装の段階でAIが書きます。リリースノートによると、planの作成時間は約4分の1、トークンは約3分の1になったそうです。
上の行数は、それより前のバージョン（v6.4.1まで）で作ったplanによるものです。今のバージョンでは、planの量はかなり減っているはずです。
AI自身がテストできないものが挟まると、一気に面倒になる
SuperpowersはTDDを徹底します。そのため、ローカルでDockerなどを使いながら、テストがコードとコマンドだけで完結するものにはめっぽう強いです。
一方で、実機での確認が必要だったり、AIがクラウドを十分に操作できなかったりするケースでは、途端に面倒になります。AIが自分で確かめられない部分は人が確認することになり、そのたびに作業が止まります。
たとえば、AWSでマネージドサービスをふんだんに使ったサーバーレス構成の場合、ローカルだけではテストが完結しないことが多いです。AIに強い権限を持たせてCLIで実際にデプロイ・確認させるくらいのことができないと、Superpowersの強みが活きません。
モバイルアプリでも同じことが起きました。最初はReact Nativeで作っていたのですが、JSとネイティブ（Kotlin）のつなぎ目の部分はどちらの自動テストからも漏れ、そのたびに端末をつないで人が手で確かめる必要がありました。実際、人が実機で確認する項目の半分以上は、JSとネイティブが正しくつながっているか（配線）を見るだけのものでした。途中でKotlinのネイティブアプリに作り直したところ、JVM上のテスト（Robolectric）とエミュレーターでAI自身が確かめられる範囲が大きく広がりました。Superpowersで開発するなら、AIが自分でテストできるかどうかを、技術選定の段階から考えたほうがいいと感じています。
Autoモードでの実行が基本になるので、暴走が少し心配
SuperpowersではAIが長時間のタスクを実行するため、コマンドの実行などの操作を途中で人が一つひとつ承認することは現実的ではありません。そのため、Claude CodeのAutoモードで、操作の承認をAIの判断に任せて進めることになります。
Claude CodeのAutoモードは、デフォルトでもコマンドの実行などをチェックして、危険そうなものは止めてくれます。それでも、何時間も無人で動かすとなるとやはり怖いです。Claude Codeのサンドボックスの設定を使ったり、Dev Containerで隔離したりと、AIの判断に頼らない物理的な仕組みで守ることを考えておくべきだと思います。
業務利用を考えるにあたっての考察
ここからは、業務で使うことを考えたときに思ったことです。
私はまだ業務での開発経験が浅く、Superpowersを業務で使った実績もありません。以下は個人開発での経験をもとにした想像によるところが大きいので、一つの考え方として参考程度に読んでいただければと思います。
「顧客・利用者との調整」と「Superpowersでの開発」は、時間の尺度も責任の重さも違うのではっきり分ける
企業がアプリを作る場合、SIであれば、顧客と要件を詰めて法的な責任のある契約を結んでから着手することになります。自社で使うアプリであっても、社内で開発者と利用者が別の人・別の組織であることは多く、そうなると仕様をしっかり合わせる必要があります。
ここで、人と人との調整になると、途端に時間の尺度が大きくなります。決定権のある人がいないと決まらない、返信が来ない、などいろいろあるでしょう。
一方で実装は、前述のとおりAIの稼働時間が通算10時間以上になることはあっても、人どうしの調整に比べればずっと速く進みます。人が手を動かす時間に限れば、さらに短く済みます。Superpowersに限らず、この手のツールは途中で長く止まることを想定していないでしょう。AIが開発者に仕様について質問してくることはありますが、それにすぐ答えられることが前提になっています。答えられなければ止まるしかなく、AIに任せる効果が弱まります。
時間だけでなく、責任の重さも違います。顧客向けであれば、合意した内容がそのまま契約上の責任につながりますし、業界や会社ごとの商習慣に合わせた書式や手続きも求められます。これに対して、Superpowersのspecやplanは、AIが実装するための文書です。前述のとおりplanにはソースコードが大量に書かれていて、顧客と合意するための文書としてはそもそも向いていません。
そこで、時間の尺度も責任の重さも違うこの2つははっきり分け、Superpowersを使う範囲は後者（開発）に限るのが良いと考えています。
- Superpowersのspecとplanは、開発者とAIが合意するためのものと割り切る
- 顧客・利用者向けの要件定義は別のドキュメントとし、Superpowersの枠外で作って、Superpowersへの入力として与える
開発者が前後を取り持ち、仮決めでAIのスピードを止めない
分けたうえで、前後をつなぐのが開発者の役目です。実装のフェーズに入ってからはAIの前で開発者がステークホルダーとして振る舞い、AIの質問にその場で答えながらアプリを作ります（そのため、AIの質問にその場で答えられるだけの材料が揃ってから着手します）。
とはいえ、要件定義書だけでAIの質問にすべて答えられるとは限りません。細かいところで顧客・利用者との合意に漏れがあった、あるいはやっぱり変えたほうがいいと思った、という場面は必ず出てきます。そのたびに顧客・利用者に確認していては、AIによる開発のスピードが台無しになります。
そこで、開発者がAIのスピードに合わせて柔軟に仮決めをし、AIにはそのまま進めてもらいます。仮決めした点は、あとから顧客・利用者に説明して事後承認を得ます。ダメと言われたら、そこで戻せばいいのです（もちろん、契約の中核に関わるような部分は別ですが）。
こうした進め方ができるのは、AI駆動開発（で使われる開発手法）が総じて後からの変更に強いからです。TDDでテストが揃っていれば、仮決めした部分を戻したり作り直したりしても、壊れたところはすぐにわかります。
これは決してウォーターフォールではありません。顧客・利用者と抜け漏れなく定義し切ってから着手するのではなく、後から変えられる前提で細かいところは仮決めし、AIを止めずに進めることが大事だと思います。
前の工程でもAIは使う。ただしSuperpowersとは別に
Superpowersを使うのは後の工程（開発）だけといっても、前の工程（顧客・利用者との調整）でAIを使わないという意味では決してありません。 要件の整理、議事録からの論点の洗い出し、要件定義書や画面モックの作成など、こちらはこちらでAIを使う余地は大いにあります。ただ、Superpowersは国や業界、会社、組織の慣習や力学に沿ってはいないので、前の工程に合ったAI駆動の進め方（スキルや手順）を独自に作るべきだと考えています。
画面モックは顧客・利用者と要件をすり合わせる時点で特に作っておいたほうがいいと思います。「バイブ商談」という言葉もあるように、今はAIを使えばモックはその場ですぐに作ったり編集したりできます。文章だけの要件よりも実際の画面を見ながらのほうが認識のずれに早く気づけますし、そのモックは、どんな画面にどんな機能があるかを伝える材料として、Superpowersへの入力にもなります。（なお、画面モックは個人開発でも自分の考えを整理するのに有効であり、実際私も事前に作っています。）
ここで、画面モックの目的はあくまでも機能に抜け漏れがないことを確認することであり、詳細設計でもデザインでもないということに留意が必要かと思います。バックエンドに変更が及ばない、デザインだけの変更であれば、基本的に後からでも簡単にできるので、見栄えにこだわる必要はありません。そもそもモックをその場で雑に作っていいのは、それが後の工程でコードそのものは使わない使い捨てだからです。後の工程に渡すのは、どんな画面にどんな機能があるかという中身であって、モックのコードそのものではありません。
チームで開発すること自体を目的にしない
AIが大きなタスクを長時間、自律的にこなせるようになり、開発に必要な人数は確実に減っているでしょう。下手にタスクを人に分けると、かえって効率が悪くなります。チームで開発すること自体が目的になってタスクを小さく割り、かえって結合が大変になるのでは本末転倒です。タスクは割りますが、割ったタスクはAIが全部やればいいのです。
もちろん規模次第で、マイクロサービスのように独立している部分ごとに人を分けるのは良いと思います。ただ、目的と手段が逆にならないようにしなければなりません。
AIが開発を担っても、初級エンジニアで務まるようになるかは疑問
AIは簡単なタスクほど得意で、そこはAIが人に取って代わります。そして人に残るのは、難しい判断だけです。実際、個人開発でSuperpowersを使っていても、人が判断する場面の数は少ないものの、そのひとつひとつは難しいものが多い印象です。要所要所の判断の責任は重く、「AIが推奨しているから、全部それでいいや」で済むものではありません。
このように、AIが簡単な仕事を引き受けるほど、人が担う仕事の量は減る一方で、平均するとむしろ難しくなります。私はこれを「ハブとマングースの法則」と呼んでいて、詳しくは以前に別の記事で紹介しました。
「AIを使えば誰でもできるでしょ？」というのは、「優秀な部下がいれば、管理職は誰にだって務まるでしょ？」と言っているのと同じです。部下がどれだけ優秀でも、何をやらせるかを決め、出てきたものを判断し、その責任を負うのは管理職です。AIを使った開発でも、その役割を担うのは人であり、それには相応の経験と判断力が要ります。管理職は、このあたりをしっかり認識して人材管理やアサインを考えるべきでしょう。
暴走への備えは、よりしっかりと
個人開発の感想でも述べたとおりですが、仕事であればなおさらです。組織内に専門のチームを置くのも良さそうです。ルールと物理的な仕組みの両面から、ガバナンスを効かせなければなりません。
品質保証の考え方
業務の場合は品質保証がより重要になってくるかと思います。SuperpowersはTDDによりテストを徹底的に行いますが、テストの結果などは実行中に一時的に記録されるだけで、デフォルトではplanに沿った実装と最終レビューが終わった時点で削除されます。「AIがテストして大丈夫だと言っていたので大丈夫です、記録は残っていませんが」とは言えませんし、どのような記録をどう残すかは会社や業界の慣習による部分もあると思うので、何らかの工夫が必要でしょう。
まとめ
- 自律性が高く、長時間のタスクを丸ごと任せられる。その間は画面の前で待たずに別のことをする
- Superpowersは完成度が非常に高い。TDDの徹底、スキルの自動トリガー、独立したエージェントによるコードレビューによって、開発規律をAIが本当に守ってくれるので、高品質なものができる
- サブエージェント駆動は、Dockerで完結するようなアプリでは活きるが、ローカルで完結しない場合や、人の確認・依存関係が多い場合はNativeが推奨されがち
- 永続的なドキュメントはspecとplanだけなので、複数のサブプロジェクトにまたがる開発やセッションの切り替えに備えて、全体の状態を残す工夫が要る。一方で、独自のドキュメントや進め方とは衝突せず、開発者の好みに合わせやすい
- planにソースコードが大量に書かれるので、Markdownがソースコードの2〜3倍になり、全部は読めない
- AIが自分でテストできない部分が挟まると一気に面倒になる。また、Autoモードでの長時間の実行が基本になるので、物理的な安全策を用意したい
- 業務では、時間の尺度も責任の重さも違う「顧客・利用者との調整」と「Superpowersでの開発」をはっきり分ける。開発者が前後を取り持ち、仮決めと事後承認でAIのスピードを止めない
- 前の工程でもAIは使う。それぞれの慣習や力学に合わせ、Superpowersとは別の進め方を作る
- チームで開発すること自体を目的にしない
- AIが簡単な仕事を引き受けるほど、人に残る判断は難しくなる。初級エンジニアで務まるようになるかは疑問
- 暴走への備えは、ルールと物理的な仕組みの両面から、よりしっかりと
- テストの結果はデフォルトでは残らないので、品質保証のための記録を残す工夫が要る