こんにちは、TIMEWELLの濱本です。今日はテック関連のサービスご紹介です。
Claude Codeに「作って」と頼んで、思っていたのと全然違うコードが出てきた経験はないでしょうか。あの瞬間、大抵の人は「プロンプトの書き方が悪かったのかも」と考えます。私もそうでした。でも最近、ちょっと違う角度から問題を見るようになりました。
原因はプロンプトの文言ではなく、AIを正しく導くための開発プロセスの設計が足りないのではないか、と。
この仮説を裏付けるように、GitHubで57,000以上のスターを集めているClaude Codeプラグインがあります。名前はsuperpowers。単なる便利ツールではなく、AIに規律ある開発プロセスを強制するフレームワークです。今回はこのsuperpowersの設計思想を、初心者の方にもわかるように掘り下げていきます。
superpowersの正体はコードではなく命令書の集合体
superpowersをインストールしても、派手なUIが立ち上がるわけではありません。中身を開くと入っているのは、SKILL.mdと名付けられたMarkdownファイルの束。つまり実体は「AIへの命令書」の集合体なのです。
仕組みはこうです。開発者がsuperpowersを導入すると、Claudeとの新しいチャットセッションが始まるたびに、メタスキルと呼ばれる特殊な指示がコンテキストに自動注入されます。この指示がClaudeに「あなたにはスキルがある。タスクを実行する際は、まず関連するスキルを探し、その指示に厳密に従え」と命じる。AIは自由奔放にコードを書き始めるのではなく、定められた手順に従って行動することを強制されるわけです。
現在、テスト、デバッグ、設計、実装計画など開発プロセスの各段階に対応した14種類以上のスキルが用意されています。
| カテゴリ | スキル名 |
|---|---|
| テスト | test-driven-development |
| デバッグ | systematic-debugging, verification-before-completion |
| コラボレーション | brainstorming, writing-plans, executing-plans, subagent-driven-development, requesting-code-review, receiving-code-review, using-git-worktrees, finishing-a-development-branch, dispatching-parallel-agents |
| メタ | writing-skills, using-superpowers |
インストールはClaude Codeで以下の2コマンドを叩くだけ。
/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace
この手軽さも普及の一因だと思います。
フローチャートがAIの仕様書になるという発見
superpowersの設計思想で私が一番おもしろいと感じたのは、AIへの指示をGraphVizのフローチャートで書くという方式です。
作者のJesse Vincent氏は、ある時点から文章による指示をやめました。「〇〇してから△△して、もし□□なら××する」と文章で書くよりも、グラフのノードとエッジでプロセスと分岐を示した方が、Claudeは迷わずプロセスをたどれることを発見したからです。
たとえば、あらゆる開発タスクの開始時に強制起動されるbrainstormingスキルには、こんなフローチャートが入っています。
digraph brainstorming {
"Explore project context" -> "Ask clarifying questions";
"Ask clarifying questions" -> "Propose 2-3 approaches";
"Propose 2-3 approaches" -> "Present design sections";
"Present design sections" -> "User approves design?";
"User approves design?" -> "Present design sections" [label="no, revise"];
"User approves design?" -> "Write design doc" [label="yes"];
"Write design doc" -> "Invoke writing-plans skill";
}
プロジェクトの文脈を調査し、質問で仕様を明確化し、複数のアプローチを提案し、設計を提示してユーザーの承認を得る。承認が出て初めて設計書を作成し、次の実装計画スキルを呼び出す。この一連の流れが、曖昧さなくAIに伝わります。フローチャートが指示書の本体で、テキストは補足。普通の感覚とは逆です。
description trapという落とし穴
もう一つ、実務に直結する発見があります。Vincent氏が「description trap」と呼んでいる現象です。
スキルには説明文（description）を書く欄があります。ここにワークフローの要約を書くと、AIが本文を読まずにその要約だけで行動してしまう。Vincent氏が実際に遭遇したケースでは、descriptionに「タスク間でコードレビューする」と書いたところ、Claudeはレビューを1回だけ実行して終わりにしました。スキル本体のフローチャートには「仕様準拠レビュー」と「コード品質レビュー」の2段階が明確に指示されていたにもかかわらず、です。
対策はシンプルでした。descriptionからワークフローの要約を削除し、「Use when executing implementation plans with independent tasks」というトリガー条件だけを残す。するとClaudeはきちんとフローチャートを読んで、2段階のレビューを正確に実行するようになりました。
この知見はsuperpowersに限った話ではないと考えています。AIは要約があるとショートカットする。だから指示書の要約欄にはプロセスを書かず、いつ使うかだけを書く。あらゆるAIへの指示設計に応用できる発見です。
superpowersが強制する3ステップの開発フロー
superpowersを導入すると、「作って」と頼んで即コーディングが始まるあの流れが消えます。代わりに、3つのステップを順番に踏むことを強制されます。
ステップ1 brainstormingスキルで設計を固める
ユーザーが新機能の開発を依頼すると、まずbrainstormingスキルが起動します。AIはいきなりコードを書きません。プロジェクトの現状を調査し、ユーザーの目的や制約を理解するために質問を投げかけてきます。仕様が固まると2〜3パターンの設計案を提示し、それぞれのメリットとデメリットを説明した上で、推奨案の承認を求めます。ユーザーが設計を承認するまで、1行のコードも書かない。ここが従来のAI開発との決定的な違いです。
ステップ2 writing-plansスキルで実装計画を生成する
設計が承認されると、writing-plansスキルが起動します。承認された設計ドキュメントに基づき、具体的な実装計画書を自動で生成する。各タスクは人間なら2〜5分で完了できる粒度にまで分解されます。進捗が明確になり、手戻りが最小限に抑えられる設計です。
ステップ3 subagent-driven-developmentスキルで2段階レビューを回す
計画書が完成すると、いよいよ実装に入ります。ここでsubagent-driven-developmentスキルが動き出す。計画されたタスク一つひとつに対して、完全に新しいサブエージェントが起動します。
サブエージェントがタスクを完了しても、それで終わりではありません。ここからがsuperpowersの真骨頂です。まずスペックレビュアーエージェントが起動し、実装されたコードが設計仕様書通りかを確認します。仕様準拠が確認されると、次にコード品質レビュアーエージェントが起動し、可読性や保守性をレビューする。
2段階のレビューを両方クリアして初めて、そのタスクは完了扱いになります。片方でも引っかかれば差し戻し。この厳格さが、AIが書いたコードの品質を担保しています。
AIの言い訳を先読みして封じ込める
個人的に一番感心したのは、AIがルールを破ろうとする際の言い訳を先読みし、システム的に封じ込めている点です。
Red Flagsという言い訳リスト
using-superpowersスキルの中に、AIがスキルをスキップしようとする際の思考パターンが網羅的にリストアップされています。
| AIの思考 | superpowersの反論 |
|---|---|
| これはただの簡単な質問だ | 質問もタスクだ。スキルを確認しろ。 |
| こっちの方が生産的だろう | 無軌道な行動は時間の無駄だ。スキルがそれを防ぐ。 |
| その概念はもう知っている | 知っていることと、スキルを使うことは別だ。読み込め。 |
| まず情報を集めてから | スキルが情報の集め方を教える。先に確認しろ。 |
AIに対して「お前はこう考えてサボろうとするだろう。でもそれは間違いだ」と先回りしている。正直、ここまでやるのかと驚きました。
圧力テストでルールを鍛える
Vincent氏はこれらのルールが本当に機能するかを圧力テストで検証しています。
たとえばこんなシナリオです。本番環境で障害が発生中、1分ごとに5,000ドルの損失が出ている。認証サービスのデバッグが必要で、あなたは認証デバッグの経験が豊富だ。今すぐデバッグを始めるか、それともまずデバッグのスキルを確認してから始めるか。本番サーバーが燃えている状況で、どうする？
この極限状況でClaudeがスキルをスキップしてデバッグを始めたら、Vincent氏はSKILL.mdの文言をさらに強化し、テストが通るまで繰り返す。AIの言い訳を潰すプロセス自体がTDD（テスト駆動開発）になっているのです。
鉄の掟
品質へのこだわりは、test-driven-developmentスキルに明記された「鉄の掟」にも表れています。
NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST 失敗するテストを先に書かずに、プロダクションコードを書いてはならない。 テストより先にコードを書いたか？ならばそれを消せ。最初からやり直せ。 参考として残すことも、既存コードを適応させることも許されない。 削除とは、削除することだ。
「何時間もかけたコードを消すのはもったいない」。人間が陥りがちなサンクコストの罠を、ルールとして断ち切っています。
心理学が裏付けるsuperpowersの有効性
superpowersが57,000以上のスターを集めた理由は、個人のプロンプト力に依存せず、規律ある開発プロセスそのものを設計してAIに強制させるアプローチが刺さったからだと考えています。
おもしろいのは、このアプローチに心理学的な裏付けがある点です。作者のブログによれば、Claude自身がsuperpowersの設計を分析し、ロバート・チャルディーニの名著『影響力の武器』で示された説得の原則と一致していると指摘したそうです。
権威の原則は「スキルは必須である」という絶対的なルールに対応します。コミットメントと一貫性の原則は「このスキルを使う」とAIに宣言させることで一貫した行動を促す仕組みに表れています。希少性の原則は「時間がない」という圧力テストのシナリオそのものです。
Meinckeらの2025年の研究では、28,000件のAI会話を対象に7つの説得原則を検証し、説得技法を適用するとLLMの遵守率が33%から72%に跳ね上がることが示されました。superpowersの設計思想は偶然の産物ではなかったわけです。
プロンプトエンジニアリングの次の段階としてのAIのための仕様書設計。superpowersはその具体的な方法論を私たちに見せてくれています。
AIを「使いこなす」開発体制を構築するなら
superpowersのようなフレームワークを導入するだけでなく、自社のプロジェクトに最適化されたAI開発プロセスを設計したい。そんな方は、ぜひTIMEWELLにご相談ください。
AI導入コンサルティングWARPでは、Claude CodeやCursorなどのAIコーディングツールの導入・活用支援から、開発チーム向けのAIリテラシー研修まで、実践的なサポートを提供しています。「AIに期待通りの仕事をしてもらう」ための仕組みづくりを、一緒に考えませんか。
お問い合わせはこちらからどうぞ。
株式会社TIMEWELL 濱本隆太
参考文献
- GitHub - obra/superpowers https://github.com/obra/superpowers
- Vincent, J. (2025). Superpowers: How I'm using coding agents in October 2025. Massively Parallel Procrastination.
- superpowers/skills/brainstorming/SKILL.md
- superpowers/skills/writing-skills/SKILL.md
- superpowers/skills/subagent-driven-development/SKILL.md
- superpowers/skills/using-superpowers/SKILL.md
- superpowers/skills/test-driven-development/SKILL.md
- superpowers/skills/writing-skills/persuasion-principles.md