Coroni LLC
メニュー
← Contents

調査ノート / AI活用

Claude Codeのsuperpowersは何を変えるのか — 反応と実利用から考える

superpowersは、コーディングエージェントへ設計、TDD、デバッグ、レビューの順序を守らせるSkill群です。 工程を言語化することで作業の再現性を上げる考え方は興味深い一方、すべての変更へ同じ重さで適用すると時間やtokenの負担が先に立つ場合があります。

この記事では、公式が説明する現行仕様、英語圏・日本語圏の利用者の反応、coroniのリポジトリで確認した一次体験を混ぜずに整理し、試す条件を考えます。

公開・最終確認：2026年7月25日 ・ 読了目安：12分

1. superpowersとは何か

公式READMEが示すsuperpowersは、便利なpromptを選ぶだけのcollectionではありません。対話で要件を固め、計画し、作業場所を分け、Redから始め、原因を調べ、reviewと検証を通す一連の開発方法論です。各段階を独立したSkillにし、必要なときにエージェントが読み込む構造を取っています（公式README）。

作者Jesse Vincentは、Claude Codeのplugin systemが公開された2025年10月9日に初期版を公開しました。ローンチ時からbrainstorm、plan、implement、git worktree、RED/GREEN TDD、subagentによる実装とreviewが中核にありました（作者のローンチ記事）。

現在の呼び出し方は初期記事と同じではありません。v5.1.0で旧slash commandの/brainstorm、/write-plan、/execute-planは削除され、対応するSkillを直接使う形になりました（v5.1.0 release）。過去記事に残るcommandを現行手順として読み替えると、評価対象の版がずれます。

2026年7月25日時点のREADMEはClaude Code、Codex App・CLI、OpenCode、Gemini CLIなど複数のagentを挙げています。ただし、subagent機能がない環境では別の実行Skillへfallbackするなど、同じSkill名でも実装能力は一様ではありません（v5.0.1のtool mapping）。Gemini CLI対応が一度外れた後にv6.2.0で復帰した経緯もあり、対応一覧は時点付きで読む必要があります（v6.2.0 release）。

  1. 1

    brainstormingで要件と選択肢を小分けに確認する

  2. 2

    合意した設計から、検証可能な実装計画を作る

  3. 3

    必要ならgit worktreeで作業場所を分離する

  4. 4

    失敗testを先に見てから最小実装を加える

  5. 5

    体系的デバッグとreviewで原因・仕様適合を確認する

  6. 6

    test、lint、buildなど実行証拠を得て完了を判断する

brainstorming
役割：要件と代替案を確認する
注意：決定済み・短いtaskでは再質問が重くなる
test-driven-development
役割：失敗を先に観測し、実装契約を固定する
注意：testしにくい対象や試作では準備コストが目立つ
systematic-debugging
役割：症状から根本原因へ調査順序を置く
注意：軽微な修正でも同じ深さで使うと時間が増える
using-git-worktrees
役割：変更場所とbranchを分離する
注意：作成後のcwdや絶対pathまでは自動で保証しない
subagent-driven-development
役割：taskごとに実装とreviewの文脈を分ける
注意：context重複とtoken消費が増える場合がある

2. 数字で見る広がり

GitHub Repository APIから2026年7月25日時点で取得した値では、Starは260,668、Forkは23,251でした。open issueとpull requestの合計はRepository APIのopen_issues_countで319です（GitHub Repository API）。一方、pull requestを除くopen issueのみの件数は154です（GitHub Search API）。両者は同じ指標ではありません。Repository APIのcreated_atは2025-10-09T19:45:18Z（UTC）で、JSTでは2025年10月10日4:45です。これは作者のローンチ記事の公開日である2025年10月9日とは別の事実です。同APIのpushed_atは2026-07-24T21:21:36Z（UTC）で、JSTでは2026年7月25日6:21です。ライセンスはMITでした（GitHub Repository API）。数値は関心の広さと活動状況の手がかりにはなりますが、生成物の正しさや個別teamとの相性を証明しません。

coreリポジトリのskills/直下は14ディレクトリで、再帰的に数えたSKILL.mdも14件です。41という数は補助文書やscriptを含む一階層下のentry数です。別のmarketplace、lab、archive済みrepositoryを合算せず、一次資料で数え方を確認できない「86 Skill」は現在値として採用していません（coreリポジトリ）。

現在READMEから公式Marketplaceで提供されていることは確認できますが、掲載開始日を公式releaseから確定できません。そのため、二次記事にある特定日を確定事実にはしません。数値や配布状況は変わるため、ここでは取得日と数え方を組にして扱います。

Star
260,668
注目規模の参考値であり、品質の証明ではない
2026年7月25日取得
Fork
23,251
GitHub Repository APIのforks_count
2026年7月25日取得
リポジトリ作成日時（JST）
2025年10月10日 4:45
Repository APIのcreated_atをUTCからJSTへ換算
2026年7月25日取得
最終push日時（JST）
2026年7月25日 6:21
Repository APIのpushed_atをUTCからJSTへ換算
2026年7月25日取得
core Skill
14
skills直下かつリポジトリ全体のSKILL.mdを数えた値
2026年7月25日取得
ライセンス
MIT
GitHub Repository APIのlicense.spdx_id
2026年7月25日取得

3. 英語圏の反応

英語圏では、設計の選択肢を先に比較できること、失敗testとreviewを飛ばしにくくすることを評価する反応が見られます。一方、作者の自己評価、作者へのinterview、二次要約、独立した利用記録では証拠の強さが異なります。Starやcoverageの数字が書かれていても、raw logや比較条件がなければ一般的な効果量にはしません。

とくにv6の効率改善は、作者側の内部evalと利用者の感想を分ける必要があります。過去版での高token消費を報告する人と、v6の一貫性を評価する継続利用者が同じ議論に参加しており、どちらか一方だけで現行版の平均像は作れません。

Simon Willison

立場：肯定

ローンチ時のSkill構造、TDD、計画を読む価値を評価した。継続利用の比較実験ではなく、作者の説明を紹介する初期反応として扱う。

Simon Willisonの出典を確認

Hacker News（ローンチ記事）

立場：中立

設計先行への支持とともに、文章による工程強制の信頼性、subagent間のcontext重複、token消費、具体的な生産性計測の不足が議論された。

Hacker News（ローンチ記事）の出典を確認

Open Source Ready

立場：中立

作者はcorrectnessを優先する設計と長時間の自律実行例を説明し、別の利用者は数か月使った自動Skill発火を評価した。作者の自己評価と利用者の声は分けて読む必要がある。

Open Source Readyの出典を確認

Tommaso Nervegna

立場：肯定

3週間・8例で設計承認、TDD、review gateを評価する一方、既存workflowとの競合、git repo外、短い修正での重さも記録した。

Tommaso Nervegnaの出典を確認

DataCamp

立場：中立

Skill連携による一貫性を利点としつつ、学習曲線、初回sessionの遅さ、単純なtaskやone-off scriptには重いという制約を挙げた。

DataCampの出典を確認

Hacker News（v6）

立場：中立

v6での効率改善と一貫性を評価する継続利用者がいる一方、過去版での高token消費、現代のmodelには過剰、benchmarkのbaseline不足という反応もあった。

Hacker News（v6）の出典を確認

4. 日本語圏の反応

日本語圏で確認した記事は、導入体験や設計解説が中心でした。9件の調査ソースのうち実体験が明確なものは5件で、主な立場を批判と分類できる独立記事は確認できませんでした。ただし、検索で公開・共有されやすい記事が肯定的な導入記録へ偏る可能性があり、日本語利用者全体の支持率を表すものではありません。

肯定記事の内部にも条件があります。task規模で工程を変える、思考訓練なら自分で書く、手動確認でbugを見つける、small taskではoverheadが大きい、といった留保です。旧slash commandや当時のStar数を、現行v6の仕様・現在値として再掲しないことも重要です。

DK / Zenn

立場：肯定

small taskでは一部工程を省き、medium・largeで工程を増やす実践を紹介した。強制力を評価しながら、規模別の軽量化が必要という留保を置く。

DK / Zennの出典を確認

Peter / Zenn

立場：肯定

曖昧なpromptからTODOアプリを作り、一問一答、選択肢と推奨理由、設計からreviewまでの一貫性を評価した。記事中のcommandは旧版表記である。

Peter / Zennの出典を確認

kuma8088 / Zenn

立場：肯定

brainstormingを文章作成へ応用し、一問一答と小分け承認を評価した一方、思考訓練が目的なら自分で書くべきという条件も示した。

kuma8088 / Zennの出典を確認

ryugen / Zenn

立場：肯定

v4.0.2のsourceを読み、Iron Lawや合理化対策を自作Skillへ応用できると評価した。成果比較ではなく旧版の設計分析として読む。

ryugen / Zennの出典を確認

モカモカ / Zenn

立場：肯定

brainstorming、planning、TDD、subagent開発を経験ある開発者の工程として紹介した。具体的な本人利用記録は確認できず、当時のStar数やMarketplace掲載日の主張を現行factには使わない。

モカモカ / Zennの出典を確認

Serverworks

立場：中立

v5.1.0時点の設計、TDD、debug、reviewを整理し、専用の仕様管理toolとの使い分けを説明した。現行v6の性能検証ではない。

Serverworksの出典を確認

tasekino / Qiita

立場：中立

14 task、75 test、15 commitを自律的に進めた後、手動確認で3 bugと1機能不足を見つけた。自律実装の価値とE2E・手動確認の必要性を同時に示す。

tasekino / Qiitaの出典を確認

backend-notes / Qiita

立場：中立

エージェントへ詳細な手順書を渡して工程を強制する設計として解説した。本人による比較実験ではなく、v5.0.7の二段reviewと当時のStar数を扱う記事である。

backend-notes / Qiitaの出典を確認

TKA / note

立場：中立

モバイルアプリ開発で設計先行を評価しつつ、small taskの工程、時間、tokenのoverheadと、意図しない場所への変更例を記録した。未導入条件との比較はない。

TKA / noteの出典を確認

5. 指摘されている課題

課題は「品質工程があるか」だけでなく、その工程がtaskの大きさと釣り合うかに集まります。詳細なplanやcold reviewは見落としを減らす意図で設計されていますが、数行の変更でも同じagent invocationが続けば、時間とtokenは便益より目立ちます。

以下はissueとコミュニティ記録で観測された条件です。単独利用者の報告、旧版のreview構造、異なるmodelやeffortを含む比較を、現行v6の一般的な発生率やSuperpowers単独の因果へ一般化しません。

GitHub issue

工程と応答時間が膨らむ

subagent実行を含む応答の長時間化や利用停止例が報告されている。工程を増やす設計そのものが、短い変更では便益より先に見えることがある。

読み方の留保：model、effort、他pluginなど条件が混在するため、Superpowers単独の原因や現行v6での発生率は分からない。

出典を確認

GitHub issue

planが実装の適応余地を狭める

full function bodyや長いtestまでplanへ書き、20行相当が80〜100行へ膨らむというv5期の報告がある。maintainerは弱いexecutorでも品質を保つ意図的な設計だと説明した。

読み方の留保：旧版の出力例を、review構造が変わった現行v6の一般的な挙動へ置き換えない。

出典を確認

GitHub issue

決定済みでもbrainstormingへ入る

Codex AppとGPT-5.6を使った単独利用者は、26 sessions中15で自動brainstormingへ入り、詳細PRDを含む3 sessionsでも再質問されたと報告した。

読み方の留保：計数付きの現行版に近い記録だが、全利用者の発火率を示す調査ではない。

出典を確認

GitHub issue

worktree作成だけでは書込先を保証しない

探索時の絶対pathを保持したまま、worktreeではなくmain checkoutへ書き込んだ具体例が報告された。分離の作成と、その後のcwd・path確認は別の契約になる。

読み方の留保：v5からv6移行期の事例であり、現行v6.2の同一条件では再現確認されていない。

出典を確認

GitHub issue

指示されたreviewが省略される

controllerが変更をsimpleと判断してreviewやTDDを省略した旧版事例がある。文章の指示は、必ず遷移するhard state machineと同じではない。

読み方の留保：v4.3.0〜v5.0.7の旧二段review構造に基づくため、現行版の頻度には一般化しない。

出典を確認

コミュニティ

小タスクでは工程が成果より重くなる

3週間・8例を試した利用者は、one-line typoでもbrainstormingが始まり、工程とtoken消費が変更規模に対して過剰になり得ると記録した。設計やreviewを評価した同じ記事内の留保である。

読み方の留保：単独利用者の限られた期間の記録であり、task分類やtoken増加の一般的な閾値を示す比較実験ではない。

出典を確認

GitHub issue

品質規律とtokenコストが交換条件になる

4種類のbugfixを各5回試した限定benchmarkでは、systematic-debuggingが修正前の再現testを増やす一方、cost/runも増えた。

読み方の留保：task数が少なく、model effortやsession条件も揃っていない。倍率を別のコードベースや現行版の予測値には使えない。

出典を確認

token消費の具体例を補う報告はissue #1194にもありますが、条件差が大きいため倍率を評価値として採用していません。

6. 自分たちで使ってみて

ここからは外部コミュニティの評価ではなく、coroniのこのリポジトリに残るdesign、plan、SDD report、契約test、git履歴から直接確認できた一次体験です。他teamで同じ結果になるとは限らず、工程と結果の因果を証明する比較実験でもありません。

効いたのは、判断経路と未検証範囲を成果物へ残せたことです。一方、計画やreview reportが大きくなり、環境差やcredentialの問題は別に残りました。「工程があるから正しい」ではなく、どの確認が通り、何が未実施かを追跡しやすくなった、と捉えるのが実態に近いです。

効いた点

  • 文字拡大記事では、設計、計画、共通記事契約、本文と契約テスト、出典修正、レビュー修正が別commitになり、どの判断がいつ実装へ入ったかを履歴で追えた。
  • 契約テストはページの存在確認だけでなく、G179とリフロー要件の混同、名前付き出典、対象platformでの確認など、内容上の誤りを再発防止する形へ育った。
  • cleanupでは旧routeが残るRedを先に確認し、削除後は契約testとbuild成果物の両方で不在を確認した。移行元データを消さない境界も差分確認に残せた。
  • 反復reviewは、timeout時のabort競合、内容のない文字起こしsegment、音声開始位置と動画尺の不整合を見つけ、表記ではなくデータ不変条件の失敗testへ変えた。

摩擦点

  • 文字拡大記事では184行の設計書に対して実装計画が817行となり、本文やtest、command、期待結果まで含む計画自体が大きなレビュー対象になった。
  • 最初の完了記録後もレビュー修正が複数回続いた。不具合を拾う役割は果たした一方、完了判定と報告を更新する運用コストは小さくなかった。
  • 指定外のpnpmでlockfile差分が出たほか、Node ES moduleやmiseのwarningを繰り返し切り分けた。工程が厳密でも実行環境の固定は別途必要だった。
  • 契約test、lint、buildが通っても、credentialが必要な外部APIのlive smokeは閉じなかった。未検証を可視化できても、環境を要する確認そのものは残る。

7. まとめ — どんなチームに向くか

相性がよさそうなのは、要件に複数の解釈がある長めのfeature、test可能なコードベース、設計・実装・reviewの判断を後から追いたいteamです。人間が工程を毎回promptへ書き直さず、共通の品質基準として育てたい場合にも、Skillという分離単位は検討材料になります。

相性を慎重に見たいのは、文言修正やone-off scriptのような単純作業、詳細仕様と実装方法がすでに決まったtask、tokenや時間の上限が厳しい場面、既存の設計・CI・review workflowが強く定着しているteamです。工程が二重化すると、品質向上より調整コストが増える可能性があります。

試すなら、代表的な中規模taskを一つ選び、未導入時と比べて失敗testの有無、reviewで見つかった問題、完了までの時間、token、手戻り、未検証項目を記録すると判断しやすくなります。Star数や単発の成功談ではなく、自分たちの変更条件で観測した差を見るためです。

superpowersは万能な品質保証ではありません。工程を明示し、エージェントが省略しがちな確認を会話へ戻す仕組みとしては興味深い一方、その重さがtaskと釣り合うかを運用側で決める必要があります。全面採用か不採用かではなく、適用条件を小さく定義して評価するのが現実的です。

参考資料

公式仕様、コミュニティの利用記録、issueを区別して掲載しています。仕様、数値、issueの状態は更新されるため、評価に使う際はリンク先の最新版も確認してください。