ハクソク

世界を動かす技術を、日本語で。

スーパーパワー：2025年10月にコーディングエージェントを活用する方法

226日前原文(blog.fsck.com)

概要

  • Claude Codeの新しいプラグインシステムとSuperpowersの導入解説
  • スキルによるエージェントの強化とワークフロー自動化
  • RED/GREEN TDDやサブエージェント活用による開発効率化
  • 説得原理を活用したスキル設計とテスト手法
  • Superpowersの今後の課題と展望

Claude CodeのSuperpowersプラグイン導入体験

  • Anthropic が Claude Code 向けに新しい プラグインシステム をリリース

  • Superpowersプラグインの導入コマンド例を公開

  • プラグイン導入後、 新しいプロンプト が自動で挿入される設計

  • スキルの概念導入により、Claudeが「Superpowers」を獲得

  • スキルはスクリプトで検索し、内容を読んで指示通りに実行する運用

    • スキルが存在する場合、必ずそれを利用して活動を進めるルール

開発ワークフローの進化

  • ブレインストーミング→計画→実装 のワークフローを自動化

  • プロジェクト開始時、Claudeが自動で計画相談を開始

  • gitリポジトリ内で作業時は自動で worktree を作成しディレクトリ移動

  • 複数タスクの並行処理が可能に

  • 旧来方式（人間PMによる2セッション運用）と新方式（サブエージェント自動分担）の選択肢

    • どちらも RED/GREEN TDD （失敗テスト→最小実装→成功テスト）を徹底
    • 実装終了後にGitHubプルリクエスト、worktreeマージ、停止の選択肢

スキルの本質と活用事例

  • スキルがエージェントの「Superpowers」の源泉

  • AnthropicのOfficeドキュメント機能強化で「スキル」概念の重要性を認識

  • Microsoft Amplifierのような自己改善型エージェントも同様のアプローチ

  • 「スキル作成方法」をSuperpowersに実装し、ワークフロー追加も容易化

  • Claudeに書籍やドキュメントを読ませ、学んだことをスキルとして抽出する実験

  • Claude自身がスキルを「TDD」でテストし、サブエージェントが理解・遵守できるか評価

    • 初回はゲームショー形式のテストで失敗、リアルなシナリオ型テストに変更し効果向上

スキル圧力テストのシナリオ例

  • シナリオ1: 時間的プレッシャー
    • 本番システム障害、1分5千ドル損失、即デバッグかスキル確認かの選択
  • シナリオ2: サンクコスト
    • 45分かけて書いたテストコード、既存スキルを読むかそのままコミットかの選択

説得原理とスキル設計

  • Robert Cialdiniの説得原理（権威、コミットメント、好意、返報性、希少性、社会的証明、統一性）がLLMにも有効
  • Claudeとのスキル設計でも無意識にこれらを活用
    • サブエージェントテストで「権威」「コミットメント」「希少性」などを利用
    • コードレビュー依頼で「権威」や「コミットメント」を強調
    • プラン作成時に「権威」構造を明示

Claudeの記憶とスキル抽出

  • 過去の会話記録（2249件）から教訓やスキルを抽出する試み
  • Claudeが記憶をトピックごとにクラスタリングし、スキル化の必要性を検証
  • ほとんどの問題は既存スキルで対応済み

Superpowersの現状と今後

  • 予定していた機能の一部は未完成だが、Claudeの新プラグインシステム公開を機にリリース
  • Superpowersのテスト例としてToDoリストアプリ開発の全記録を公開
  • 今後の課題

    • Superpowersのスキル共有機能の設計と実装（GitHubプルリク活用予定）

    • Claudeの会話記憶へのアクセス強化（会話記録の保存・検索ツールを整備）

    • 共有機能はユーザーの同意なく自動共有しない設計を徹底

    • 会話記録はAnthropicの自動削除に備え、外部保存＋ベクトル検索＋要約生成を実装

まとめ

  • Claude CodeのSuperpowersプラグインはスキルベースでエージェントを強化し、開発ワークフローを大幅に自動化
  • 説得原理やTDD手法を応用し、エージェントの信頼性・再現性を高める設計
  • 今後はスキル共有や記憶活用の強化が課題
  • エージェント開発・運用の新たな方向性を示唆

Hackerたちの意見

こういうブログ記事って、誰かがツールを使って何か意味のあるものを作る様子を見せてくれたらもっと役立つと思うんだよね。書籍を与えたときに、Claudeは本当に「新しいスキルを学んでいる」のか、それともそういう反応を引き出すように促してるからそう見えるだけなのか。新しいスキルを持ったClaudeと持ってないClaudeを見せる必要がある気がする。もしかしたら俺がひねくれ者なのかもしれないけど、こういうブログの多くはマーケティング的な要素が強くて、重要な部分が言葉にされず、見せられないから、まるで子供が自分の作品を過剰にアピールしてるみたいに感じる。

└

同意。ここで必要なのはA/Bテストみたいな方法論で、ツールの効果を示す定量的な指標が必要だよね。それを一度だけじゃなくて、いろんなシナリオで何度もやって、統計的な有意性を示す必要がある。コーディングエージェントと作業する時の最も難しい部分は、彼らが小さなコードベースで低い複雑さの時にはうまくいくように見えることだね。コードベースが大きくなって、非自明な接続やパターンが増えると、ほぼ常に非自明なことを頼まれるとトンネルビジョンに陥って、技術的負債が増えるんだよね。

└

うん、これを読んで、実際に役立つものを見せてくれるのか、どんな痛点を解決しているのかを探っていたけど、ただのごちゃごちゃだった。

└

今日のやつだよ： https://mitchellh.com/writing/non-trivial-vibing

└

「もしかしたら私は頑固者かもしれないけど、こういうブログの大半はマーケティングの一環に感じる。重要な部分は、言葉にされていないことや見せられていないことが多すぎて、まるで子供が自分の作品を誇張しているように見える。」 ほんと、こういう自己満足的な「私のポテンシャルを見て：Nicknack.exeの使い方」みたいな内容は、IT業界の定番だよね。

└

複雑なプロジェクトを大規模に長期間コーディングするためにLLMを使うのは本当に難しいよね！要件を定義するだけでも、ほとんどの人が思っているよりずっと難しいから。LLMは間違った方向に進むと、そのスピードを加速させちゃうし。

└

それなら、Claudeのコードを使って自分で結論を出せばいいじゃん？

…今すぐ読んでみて… それはあまり良い感じがしないな。これを使ったら、指示が実際の優先事項と矛盾するのはどれくらい早いだろう？すべてが第一法則になれるわけじゃない。

└

最近はLLMにそんな指示を出すなって言われるよね。

└

bashrcファイルを維持する感じだね。時々、ちょっと調整しなきゃいけない。

この投稿は本当におすすめだよ。Jesseがこれらのツールを使ってる方法は、他の多くの人よりも遥かに野心的だ。彼のリポジトリをちょっと掘り下げてみて：https://github.com/obra/Superpowers。昨晩、これについてメモを書いたんだ：https://simonwillison.net/2025/Oct/10/superpowers/

└

この話が「Research -> Plan -> Implement」メソッドや「Advanced Context Engineering from Agents」動画のプロンプトと、実際の大規模コードベースでのコーディングパフォーマンスにどう関係すると思う？スキルを身につけるのはエージェントの能力を広げるのに役立つと思うけど、実際の開発にはそれが正しいことなのかは分からない。パッケージされたコレクションはすごくクールだし、新しい能力を自動的に追加するアイデアもいいけど、このスキルの概念がカスタムコマンドやサブエージェントを持つよりもずっと良いとは思えない。これから数日間試してみて、比較してみるつもり。

└

これ、エリクサーの使用ルールみたいだけど、エージェントの振る舞いに関するもので、今のところ具体的にはClaude用だね。https://hexdocs.pm/usage_rules/readme.html

これってちょっと naive な質問かもしれないけど、「スキル」って、良い/悪い行動の例をプロンプトに追加するのとどう違うの？俺が見る限り、各スキルファイルは何かの良い/悪い例の集まりなんだけど。違いは、モデルが特定のスキルをコンテキストに読み込むタイミングを選ぶことなの？

└

それは、スラッシュコマンドで簡単にそれをできるようにするだけだと思うよ。「/brainstorm database schema」みたいに、やりたいことを毎回定義する必要がなくなるんだ。

└

君が言ってるのは1-shot、2-shot、5-shotのプロンプトのことだね。これがめっちゃ効果的で、しばらくの間ベンチマークとして使われてたんだ。

└

これが重要なポイントの一つだと思う：スキルはモデルが積極的に探して使うまで、モデルのコンテキストを占有しない。BlueskyのJesseが言ってたけど： https://bsky.app/profile/s.ly/post/3m2srmkergc2p > 「その核心は非常にトークンが軽い。2kトークン未満のドキュメントを一つ引っ張ってくる。プロセスの必要な部分があれば、シェルスクリプトを実行してそれを探す。あのToDoリストアプリの計画と実装プロセスの長いチャットは100kトークンだった。」 > 「実際の実装を含むトークンが重い部分を管理するためにサブエージェントを使ってる。」

こういうプロンプトのスタイル、つまりエージェントから「感情的」な反応を引き出そうとするために厳しいシナリオを設定するのは、もう古いよね。昔は「IMPORTANT」みたいな大文字の言葉が効果的だったけど、今はモデルがただ指示に従うだけ。こんなプロンプトを書くのはやめた方がいいよ。

└

それに、彼がリンクしている説得に関する論文は、彼が話していることとは全然関係ないよ。その論文は、訓練された「安全」拒否を克服するために説得プロンプトを使うことについてで、プロンプトの適合性を改善するためのものじゃない。

└

イライラするのは、LLMが自分自身についてこれを学んでいないことだよね。LLMに指示を改善するように頼むと、そういう改善を提案するんだ。それがLLMやエージェントと作業する中で一番イライラすることだよ。彼らは自己参照的な能力において、常に一世代遅れているように感じる。

「私が試した中には、Claudeに『これが私のプログラミング本のコピーだよ。読んで、読んでる時に明らかじゃなかった再利用可能なスキルを引き出してね』って言ったものもある。これは本当にクールなアイデアだと思う。今の良いスキャフォールディングの多くは『TDDを使え』みたいなもので、もし本に引用をリンクさせれば、インターネットから得られる一般的な平均的解釈よりも、もっと関連性のある知恵やコンテキストを引き出せるかもしれない。週末に仕事をしていない時に、Claudeに読書リストと余分なトークンを与えて、新しいアイデアや技術を探求させて、共通のCLAUDE.mdに持ち帰るのはいいアイデアだと思う。」

https://github.com/obra/superpowers/blob/main/skills/testing... のようなドキュメントは、人間が読むにはすごく混乱するよ。「スキル」ってこのプロジェクトでは一般的に決まったフォーマットに従ってないし、まるで「Xをする方法をステップバイステップで説明するマークダウンドキュメントを書いて」ってLLMに指示したときに出てくるものみたいだね（実際にブログ記事によるとそうなったみたい）。よくわからないけど、もしLLMがTDDが何かを知ってる前提なら（おそらくそれについての本を100冊くらい読んでるだろうし）、なんでその短くて（私的には混乱する）バージョンを実際のプロンプトの前に与えてるの？こういうプロジェクトがLLMに「スーパーパワー」を与えることを目指してるけど、LLMが自己学習できて、ちょっとした魔法のテキストを加えるだけで10倍賢くなるっていう間違った前提で動いてる気がする。もちろん、コンテキストは大事だし、繰り返しのタスクがあるときは、自分の制約や要件を書き出して、それをこのタスクに合ったプロンプトの前に貼り付けるけど、それは私がやろうとしていることの特定のコンテキストの一部に過ぎない。LLMにスーパーパワーを与えてるわけじゃなくて、ただコンテキストを提供してるだけだよね。こういう投稿をいくつか読んだけど、いつも欠けているのは、実際にどうやって客観的により良い結果を生み出しているのかの具体例だね。

└

完全に同意だわ。ここ数週間、GPT Pro（5o-codex-high）でコーデックスを使ってるけど、結局はコンテキストに尽きると思う。俺にとって一番役立ったのは、音声をWhisper経由でLLMsに送ること、トークンの使い方をうまく管理すること、必要なときにチャットを再起動すること、そして作業が終わったかどうかを確認するための定量的な方法を与えること（例えば、APIやPlaywrightテストを使ったAIユニットテストとか）。それに、俺が持ってるファイルは全部マークダウンだし、専門的なタスクにはそれぞれ異なるAIチャットを使うのがいいね（このモデルの数学的な仕組みのおかげで、結果が全然違う！）。これのおかげで、彼が言ったようにPMの役割を続けられてるけど、無駄にトレーニングセットを再評価させるようなことはせずに済んでる（笑）。でも、なんでクラウドに戻る必要があるんだろう？ 5o-codex-highの方が圧倒的にパワフルなのに、全然比べ物にならないよ。彼が言ったことのいいところは、AIがAIと連携すること。これがプロモーションや役割のセグメント化にすごく役立ってるんだ。

この記事を読んで、「どうやってコーディングエージェントを使ってタスクをより良くこなしているか」っていう内容だったらよかったのにと思った。私はもう2年間AIを探求してるけど、確かにおもちゃのような分類から基本的なユーティリティにアップグレードされたよ。でも、限界にぶつかることが増えて、LLM以前の働き方に戻る方が、もっと堅実で、速くて、メンタル的にも持続可能だと感じてる。最先端の開発プラクティスや価値創造をさらに推進するワークフローにLLMを統合した具体例を持っている人いる？

└

俺の印象では、まだ試行錯誤の段階って感じだね。指標は徐々に出てきてる。

└

今朝のミッチェルの投稿: https://mitchellh.com/writing/non-trivial-vibing

まだ1ページ目しか読んでないのに、この一文を見てすぐにイライラした。@/Users/jesse/.claude/plugins/cache/Superpowers/... XDG仕様は数十年前からあるのに、なんで新しいアプリがまだ私のHOMEを汚してるの？リアルデータがキャッシュの下に置かれるのも変だし、まあいいけど。

└

キャッシュの場所にあるのは、GitHubのリポジトリからインストールしたプラグインのコピーだから、そのファイルの元の真実のポイントではないんだよね。

「ロバート・チャルディーニの『影響力』で学んだ説得の原則がLLMsに適用できるのは理解できたし、実際にそうなって嬉しかった。でも、ここで止めよう。これはAIとの開発を超えて、まったく別の何かに進んでる。AIコーディングが根本的な変化だからって、すべてが変わったわけじゃない。構造とデザインのある程度の整合性が必要だよ。今得られているのは、ただの呪術的なナンセンスだ。」