Claude Code を使った記事執筆法：superpowers の意外な使い方
この記事が役立つ方
- Claude Code を使っている人
- ブログ記事、企画書、提案書など何らかのアウトプットが必要な人
- superpowers プラグインを「開発専用」だと思っている人
前提知識: Claude Code の基本的な使い方
3行のメモがあった。
修正するときは必ずデバッガー関連のスキルを使おう
これだけ。本当にこれだけ。
「このメモ、記事にできそうだな。何から始めればいいかな」と Claude Code に聞いてみた。
すると superpowers:brainstorming が呼び出された。
なぜこのスキルが呼び出されたのか。superpowers には「何かを作るタスクなら brainstorming を最初に使え」というルールがあります。「記事にできそう」＝「作りたい」と判断されたわけです。
「え、それ違くない？ brainstorming って仕様書作るやつでしょ？」
正直そう思った。でも、普段から仕様書作成でよく使っていたスキルだ。対話の質は信頼している。「一度やってみるか」と続けてみた。
結果、4841文字の Zenn 記事ができた。
この記事では、なぜ brainstorming がブログ執筆にも使えるのか、その仕組みを分解して説明します。
superpowers、入れてる？
「superpowers って何？」という人もいるかもしれません。Claude Code のプラグインで、便利なスキルがまとめて入っています。
入れていない人は、1コマンドでインストールできます。
claude plugins:install superpowers
インストールしたら Claude Code を再起動してください。ちゃんと入ったか確認したい場合は、以下のコマンドを実行します。
claude plugins:list
superpowers が表示されれば OK です。
brainstorming の呼び出し方
呼び出し方は2つあります。
スラッシュコマンド（楽）
/superpowers:brainstorm
/sup まで打てば補完が効きます。引数なしでも OK で、スキルが「何について考えたい？」と聞いてきます。
自然言語で呼び出す
superpowers:brainstorming を使って、技術ブログのネタを考えたい
会話の流れで呼び出したいときはこちらが便利です。
どちらでも同じスキルが起動します。私はスラッシュコマンド派。タイプ数が少ないから。
対話で何が起きるか
brainstorming が始まると、一方的に「はい、これが答えです」とは言ってきません。代わりに質問が飛んできます。
質問は1つずつ
Claude: このブログ記事のターゲットは誰ですか？
A) プログラミング初心者
B) Claude Code を使い始めた人
C) AI ツールに興味がある人
推奨は B です。理由は〜
一度に5つも6つも質問されることはありません。1つ答えたら、次の1つ。このテンポが心地いい。
選択肢を選ぶだけじゃない
ここがポイントです。選択肢をポチッと選ぶだけでも進みますが、自分の考えを添えると、次の質問が変わります。
あなた: B だけど、「何らかのアウトプットが必要な人」という観点も入れたい
すると Claude は「なるほど、じゃあ次はこの角度から聞きますね」という感じで質問を調整してくる。
これ、壁打ち相手がいる感覚に近い。一人で「うーん」と唸ってるより、圧倒的に思考が進む。
構成は小出しで確認される
ある程度対話が進むと、構成案が出てきます。ただし、一気に全部は出しません。
Claude: セクション1の構成です。この方向で良いですか？
[200-300文字の構成案]
「ここまで合ってる？」と確認しながら進むから、最後に「全然違う」とならない。
正直に言うと、誤解していた
ここで白状する。私はこのスキルの説明を読んで「開発専用だな」と決めつけていた。
description にはこう書いてある：
creating features, building components, adding functionality, or modifying behavior
機能を作る、コンポーネントを作る、動作を変更する。どう読んでも開発の話だ。
「PRD 書くときに使うやつね」で終わっていた。もったいないことをしていた。
スキルの中身を見て、腹落ちした
「なんでブログ記事にも使えるの？」と思うだろう。私も最初は不思議だった。
スキルの中身を見たら、理由がわかった。
原則1: 一問一答で深掘り
Ask questions one at a time to refine the idea
「一度に複数聞かない」というルールです。これは開発に限った話ではなく、どんなテーマでも使える対話の基本形になります。
原則2: 選択肢で思考を整理
Prefer multiple choice questions when possible
「どうしたいですか？」より「A, B, C どれ？」の方が答えやすいですよね。これも普遍的な原則です。
原則3: 複数アプローチを提示
Propose 2-3 different approaches with trade-offs
「正解はこれ」と押し付けません。選択肢を出して、トレードオフを説明します。記事の構成を考えるときも同じことをやりますよね。
原則4: 小出しにして確認
Present design in sections, validate each
一気に完成品を出しません。少しずつ見せて「ここまで OK？」と確認します。
気づいただろうか。
これ、「開発の手法」じゃない。「対話のプロトコル」だ。
入力が「作りたい機能」でも「書きたい記事」でも、プロセスは同じ。
開発以外でも、そのまま使える
| 原則 | 開発だと | 記事執筆だと |
|---|---|---|
| 一問一答 | 要件を1つずつ確認 | 論点を1つずつ整理 |
| 選択肢提示 | 技術選定 | 切り口の選択 |
| 複数アプローチ | 設計パターンの比較 | 記事構成の比較 |
| 小出し確認 | 仕様の段階的承認 | 章ごとのレビュー |
「機能を作る」を「記事を作る」に置き換えるだけです。
結局このスキルは、「曖昧なアイデアを構造化するプロトコル」 なのです。
ブログ以外にも使える
「曖昧なアイデアを構造化する」場面なら、何にでも使えます。
- 企画書・提案書: 「こういうことやりたいんだけど」を言語化
- 学習ノート: 「何がわからないか」がわからない状態を整理
- 振り返り: 「何が良くて何がダメだったか」を構造化
共通するのは、頭の中にはあるけど、言葉になっていないものです。
brainstorming は対話で引き出してくれます。一人で唸るより、ずっと楽です。
とはいえ、使い分けはある
補足しておく。自分で唸りながら書くドキュメントにも価値がある。
時間はかかる。でも実力がつく。
「思考力を鍛えたい」なら、自分で書くべきだ。その苦しみが力になる。
一方で「早くアウトプットして人に伝えたい」なら、対話で引き出して、文章化はツールに任せる。これも一つの正解。
どっちが正しいという話じゃない。目的で使い分ければいい。
まとめ
インストール
claude plugins:install superpowers
呼び出し
/superpowers:brainstorm
または自然言語で superpowers:brainstorming を使って〜 と入力します。
なぜ汎用的に使えるか
- 中身は「対話のプロトコル」です
- 一問一答、選択肢、小出し確認——どれも開発に限りません
- 選択肢を選ぶだけじゃなく、考えを伝えると質問が変わります
- 「曖昧→構造化」の場面なら、何にでも使えます
3行のメモが5000文字の記事になった。brainstorming、開発以外にも使ってみてほしい。
Discussion