Claude Code Superpowers完全ガイド｜v6のマルチハーネス開発方法論【2026年最新】

株式会社TIMEWELLの濱本です。

半年前にこの記事の初版を書いたとき、Superpowersは「Claude Codeに規律を取り戻すための、ある個人のオープンソースプラグイン」でした。ところが2026年7月時点でリポジトリの説明文を開くと、そこには「An agentic skills framework & software development methodology that works.」と書かれています¹。プラグインではなく、動く開発方法論。この一文の変化が、この半年でSuperpowersに起きたことをそのまま表しています。

GitHubのスターは本稿執筆時点で約25万7千、フォークは約2万3千に達し、Claude Code向けというより「AIコーディング全般の型」として広がりました¹。しかも対応先はClaude Codeだけではありません。CursorやAntigravity、GitHub Copilot CLIなど複数のハーネスで同じスキルが動くようになっています。個人の便利ツールから、組織で標準化できる開発規律へ。今回のリライトは、その現在地を一次情報で確かめながら書き直したものです。自社がこうした開発標準化に踏み出せる段階かを先に測りたい方は、AI導入準備度の無料診断を入り口にしてみてください。

Superpowersとは何か（プラグインから「開発方法論」へ）

Superpowersは、Jesse Vincent氏（GitHubアカウント名 obra）と、同氏が関わる「Prime Radiant」チームが開発しているMITライセンスのオープンソースです¹。初版で私は「Anthropicの元エンジニアが単独で公開したプラグイン」と紹介していましたが、いまは個人プロジェクトというより、チーム体制で継続的にメンテナンスされる公開資産になっています。この違いは地味に見えて重要で、企業が業務に組み込むうえでの継続性や信頼性に直結します。

中身の本質は変わっていません。Markdown形式のSKILL.mdに「AIへの命令書」を書き溜めた集合体で、セッション開始時にメタスキルが注入され、Claudeが必ずスキルを参照してから動くように仕向けます。テスト駆動開発（TDD、失敗するテストを先に書いてから実装するやり方）と体系的なデバッグを軸に、要件の精緻化から設計、計画、実装へと段階を追わせます。合成可能なスキル群として設計されている点が、Superpowersが「型」として機能する理由です。

呼び名が「プラグイン」から「方法論（methodology）」へ変わったのは、単なる言葉遊びではないと感じています。プラグインは入れるかどうかの話ですが、方法論はチームがどう働くかの話です。AIに自由に書かせると品質が安定しないという現場の悩みに対し、Superpowersはツールを足すのではなく、開発の進め方そのものに規律を敷いてきます。だからこそ、導入の議論も「便利だから入れる」ではなく「うちの開発フローをこの型に寄せるか」という、一段重い意思決定になります。私はこの重さこそが、企業にとってはむしろ扱いやすい変化だと考えています。判断の対象がツール選定ではなく開発プロセスの設計に移るからです。

「当時→現在」：この半年で何が変わったか

初版を書いた2026年2月と現在では、前提がほぼ総入れ替えになりました。まず対応範囲。当時は事実上Claude Code専用でしたが、いまは複数ハーネス対応が最大の売りです。次にモデル。当時の記事は「Opus 4.7（当時の想定フラッグシップ）」と「Sonnet 4.7」を前提に書いていましたが、現在のフロンティア上位はOpus 4.8、エージェント開発の主力は2026年6月30日にリリースされたClaude Sonnet 5、上位の一般提供モデルとして直近で再展開されたFable 5、という布陣に変わっています²³。GitHubスターも当時の約5万7千から約25万7千へと桁が動きました¹。

設計思想にも見直しが入りました。旧版で私は「フローチャート（GraphViz形式のdigraph）で手順を渡すと遵守率が上がる」という点を強く推していました。ところがv6.0.0の全面書き直しで、ブートストラップのダイアグラムは散文へ置き換えられています⁴。理由はコストです。図で手順を渡すのは分かりやすい反面、トークンを食います。同じ効果を散文でより安く出せるなら、そちらを取るという判断でした。GraphViz礼賛を続けていた旧版の記述は、現行の実装と食い違うため撤回します。

もう一つ、正直に訂正しておきます。旧版には「Claude Security公開ベータが2026年4月30日にOpus 4.7と同日公開された」という記述がありました。今回、Anthropicの公式ニュースルームを当たり直したところ、その日付や同日公開という事実を一次情報では確認できませんでした³。Claude Security自体はAnthropicの製品ラインに存在しますが、公開時期の断定は取り下げます。二次情報だけで日付を書いていた点は反省点です。数字や日付は発信元の一次情報で裏を取ります。この原則を外すと、コンプライアンスを語る記事の足元が崩れます。

v6系で何が変わったか（約2倍高速・トークン約50%削減）

現行の系譜を追うと、2026年6月16日のv6.0.0が転換点でした。リポジトリを全面的に書き直したこのリリースは、公式の評価で実行が「約2倍高速」かつ「消費トークンが約50%削減」と明記されています⁴。エージェント開発でトークンは直接コストです。半分になるなら、同じ予算で倍動かせます。ここが企業導入の損益分岐に効いてきます。

中身の改善も実務的です。レビュー工程は、それまで2つのプロンプトに分かれていたものを単一の task-reviewer-prompt.md に統合し、冗長なレビュー往復を減らしました。ブレインストーミング補助にはセッション単位の認証キーとサンドボックス化したファイル配信が加わり、可視化まわりの安全性が上がっています。worktreeの置き場所も、ユーザー設定ディレクトリからプロジェクト内へ移され、リポジトリ単位で完結するようになりました⁴。細かい変更に見えますが、いずれも「企業のリポジトリで安全に回す」方向への調整です。

その後の更新は安定化とマルチプラットフォーム対応が中心でした。v6.0.2（6月17日）はインストールを壊していたevalsサブモジュールを分離し、v6.0.3（6月18日）はスクラッチファイルの置き場所を調整。v6.1.0（6月30日）ではブートストラップをさらに圧縮し、ハーネスごとの冗長な解説を削ってトークン効率を上げつつ、Codex連携を有効化しました。最新のv6.1.1（7月2日）はCodex向けフック設定の修正が主です⁴。バージョン軸で見ると、v6は「速く、安く、複数環境で安全に」という一本の線でつながっています。旧版が事実上v5以前で止まっていたことを思うと、ここは丸ごと書き足す必要がありました。

マルチハーネス対応と正しい導入コマンド

v6でいちばん大きいのは、やはり複数ハーネス対応です。リポジトリは「one set of skills, every harness」を掲げ、一組のスキルをClaude Code、Cursor、Antigravity、GitHub Copilot CLI、Kimi Code、Piで共通して使えるようにしました¹。かつて対応していたGemini CLIは、Google側のサービス終了（EOL）を受けてv6.0.0以降で完全に外れています⁴。同じ開発規律を、チームが使うツールを問わず横展開できます。これは組織標準を敷きたい立場にとって、想像以上に効きます。

導入コマンドは旧版から変わっているので、ここは正確に押さえてください。旧版に書いていた /plugin marketplace add anthropic から /plugin install superpowers という手順は、現行では正しくありません。現在の公式マーケットプレイス名は claude-plugins-official です。

ハーネス	導入コマンド
Claude Code	/plugin install superpowers@claude-plugins-official
Cursor	/add-plugin superpowers
Antigravity	agy plugin install https://github.com/obra/superpowers
GitHub Copilot CLI	copilot plugin install superpowers@superpowers-marketplace
Kimi Code	/plugins install https://github.com/obra/superpowers
Pi	pi install git:github.com/obra/superpowers

社内で配布する際は、この表をそのままオンボーディング資料に貼るのが手っ取り早いです。ハーネスが混在するチームでも、スキルの実体は一つなので、レビュー観点や運用ルールを一本化できます。スキル定義そのものの書き方や、社内独自スキルの設計に踏み込みたい場合は、Claude Code Skills 4.5 完全ガイドで整理した「descriptionにトリガー条件だけを書き、本体は手順に寄せる」という規約が、そのまま応用できます。

13スキルの使いどころとモデル設計（Opus 4.8 / Sonnet 5）

現行のスキルは13種です。旧版のタイトルや本文は「14種類以上」としていましたが、現行リポジトリの一覧は13で確定しています¹。数を盛らないという意味でも、ここは正しておきます。実務でどう使うかを一行ずつ添えると、次のようになります。

カテゴリ	スキル	実務での使いどころ
テスト	test-driven-development	失敗するテストを先に書かせ、実装をテストに従わせる規律の中核
デバッグ	systematic-debugging	症状から仮説、検証へと手順を踏ませ、当て推量の修正を防ぐ
デバッグ	verification-before-completion	「完了」と言う前に実際に動かして確認させ、虚偽の完了報告を潰す
協働	brainstorming	要件と制約をAIに質問させ、着手前に前提を揃える
協働	writing-plans	仕様から実装計画へ、小さなタスク粒度に分解する
協働	executing-plans	書いた計画を別セッションでレビュー関門付きに実行する
協働	dispatching-parallel-agents	依存のない複数タスクを並列のサブエージェントへ振り分ける
協働	requesting-code-review	実装後やマージ前に、要件充足を自分から確認させる
協働	receiving-code-review	レビュー指摘を鵜呑みにせず、技術的な妥当性を検証してから反映する
協働	using-git-worktrees	作業を現行ブランチから隔離し、並行作業の事故を防ぐ
協働	finishing-a-development-branch	実装完了後のマージやPR、後片付けを型どおりに締める
協働	subagent-driven-development	1タスク1サブエージェントで、独立タスクを順に実装する
メタ	writing-skills / using-superpowers	新しいスキルを作る、既存スキルを正しく呼び出すための土台

スキルは規律の器であって、実際にコードを書くのはモデルです。だからモデル設計を切り離して考えると失敗します。私の現時点の推奨は、日常のエージェント開発をClaude Sonnet 5に任せる構成です。Sonnet 5は2026年6月30日リリースで、Anthropic自身が「最もエージェント的なSonnet」と位置づけており、性能はOpus 4.8に迫るとされます²。価格は導入期間中（2026年8月31日まで）が100万トークンあたり入力2ドル・出力10ドル、以降は標準の3ドル・15ドルです²。TDDや二段レビューのように同じファイルを何度も読み書きするSuperpowersの反復には、このコスト効率がそのまま効きます。

ただし全部をSonnet 5で回すのは危険です。難度の高い設計判断や、脆弱性を扱うセキュリティ感度の高いコードは、フロンティア上位のOpus 4.8へ寄せてください。AnthropicはSonnet 5について、サイバーセキュリティ評価ではOpus 4.8などに比べて明確に劣ると述べています²。安いモデルで全域を賄うのではなく、リスクの高い局面だけ上位モデルに切り替えます。この線引きをチームのポリシーとして先に決めておくと、コストと品質のバランスが崩れません。AI生成コードそのものの脆弱性検知は、Anthropicのセキュリティ製品側に分担させる考え方が整理として楽です。運用パターンはAnthropic Claude Security 公開ベータ実装ガイドにまとめています。認証情報や環境変数の扱いはSuperpowersに任せず、ハーネス側のフックと環境分離で守るのが基本で、こちらはClaude Code 環境変数とセキュリティ完全ガイドを参照してください。開発チームに限らず全社のナレッジ活用でも同じ規律を敷くなら、AWS国内サーバーと監査ログ、ナレッジコントロールを備えたエンタープライズAI基盤のZEROCKのような選択肢もあります。

企業導入の落とし穴とWARPでの組織標準運用

Superpowersは強力ですが、そのまま全社配布すると必ず問題が出ます。WARP経由の支援で繰り返し見てきた落とし穴は4つです。第一に権限肥大。スキルの一部はbash実行やworktree操作、ファイル削除を前提にします。情シスのポリシーと突き合わせずに配ると、本番リポジトリで想定外の操作が走りかねません。事業部ごとに許可するスキルと禁止するスキルを切り分け、ハーネス側の設定で権限スコープを縛るのが安全です。

第二にTDD強制の形骸化。test-driven-developmentスキルには「失敗するテストを先に書かないと実装コードを書いてはならない」という鉄の掟があります。スピード優先の現場ではこれをガイドラインに格下げしたくなりますが、そうすると結局AI任せの実装に戻り、品質が劣化します。守らせるか、明示的に外すかの二択にしたほうが、チームの混乱は少ないです。第三に人間承認ゲートのスキップ。要件精緻化と設計のフェーズは、本来は人間が方針に合意するための関門です。ここをAI内部のレビュアーだけに任せると、誤った前提のまま実装が進み、検証段階で大きな手戻りが出ます。少なくとも設計と検証には、シニアエンジニアの承認権限を残すべきです。

第四にレビュー往復とサブエージェントのコスト管理。subagent-driven-developmentは1タスクごとにサブエージェントを起動するため、上位モデルをデフォルトにすると推論コストが想定より膨らみます。タスクサイズの上限を決め、軽い修正はSonnet 5に振り分けるなど、モデル別のコストポリシーを先に握っておく必要があります。この論点はClaude Code エージェントチーム運用ガイドでも掘り下げました。Superpowersのサブエージェント構成を自社ワークフローへ移植したい場合は、Claude Agent SDK実装ガイドも足がかりになります。

こうした設計を、入れて配るだけで済ませないのがWARPの役割です。TIMEWELLのAI導入コンサルティングWARPでは、Superpowersのv6系を前提に、貴社のリポジトリ構造や情シス要件に合わせた「組織標準の運用設計」を一緒に組み立てています。具体的には、既存リポジトリと開発フローの監査（権限、TDD強制、レビュー体制）、公式マーケットプレイス経由での配布と社内ガイドライン整備、Opus 4.8とSonnet 5を含むモデル別のコストと責務設計、設計と検証への人間承認の組み込み、開発チーム向けの半日から1日のワークショップです。Superpowersを社内に投げ込んだものの、誰がオーナーで、どこまで自動化していいのかが曖昧、という相談が最近特に増えています。30分のオンライン相談で現状を伺い、次の一歩を整理させてください。まずは個別相談からお声がけください。

ツールとしてのSuperpowersを追いかけていた半年前と違い、いま向き合っているのは「開発の型をどう組織に根づかせるか」という問いです。方法論として成熟した今こそ、導入の巧拙が差になります。焦って全社展開する前に、まず一つのチームで型を回し切ってみてください。私はそれが、遠回りに見えて一番速い道だと考えています。

---

株式会社TIMEWELL 濱本 隆太

Footnotes

1. obra/superpowers, GitHub repository（現行の説明文・スキル一覧・導入コマンド・スター数・ライセンス・作者）. https://github.com/obra/superpowers ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

2. Anthropic, "Introducing Claude Sonnet 5"（2026-06-30、位置づけ・価格・Opus 4.8との比較）. https://www.anthropic.com/news/claude-sonnet-5 ↩ ↩² ↩³ ↩⁴

3. Anthropic, Newsroom（Sonnet 5・Fable 5・Claude Science・Claude for Teachers等の一次インデックス。Claude Security公開ベータの日付は本稿執筆時点で未確認）. https://www.anthropic.com/news ↩ ↩²

4. obra/superpowers, Releases（v6.0.0〜v6.1.1の変更履歴・性能改善・ハーネス追加・散文化）. https://github.com/obra/superpowers/releases ↩ ↩² ↩³ ↩⁴ ↩⁵