こんにちは。エンタープライズ第一本部 戦略ソリューション 1 部の英です。
普段はWebアプリやスマホアプリの案件などを担当しています。あと、趣味でAIを勉強しています。
世間ではClaude Codeが幅を利かせるなか、なぜかCodexにこだわり続けている私。
そろそろ流行りに乗らねばと思い、今回はClaude Codeの記事を書いてみます。
しかも、巷ではsuperpowersなんてものが話題になっているらしいじゃないですか。
エンジニアの英知を結集したAI駆動開発のベストプラクティス、superpowers。
これがあれば、Claude Code初心者の私でもプロ並みの開発ができるはずです。
この記事を書き終わっているころには、きっとCodex派からClaude派に寝返っているでしょう。
では、さっそくやっていきましょう。
- 1.Claude Codeとは
- 2.superpowersとは
- 3.Claude Codeの初期セットアップ
- 4.superpowersのインストール
- 5.superpowers-brainstorming
- 6.superpowers-using-git-worktrees
- 7.superpowers-writing-plans
- 8.superpowers-subagent-driven-development or executing-plans
- 9.superpowers-test-driven-development
- 10.superpowers-requesting-code-review
- 11.superpowers-finishing-a-development-branch
- 12. 動作確認
- Plan2について
- さいごに
1.Claude Codeとは
Claude Codeは、Anthropic社が提供しているAIコーディングエージェント。
ターミナル上で動作し、コードの生成・修正・調査・テスト実行などを対話形式で進めることができる。
「AIにコードを書いてもらう」だけでなく、開発作業そのものを一緒に進めることができるツール。
2.superpowersとは
superpowersは、Claude Codeをよりうまく活用するためのワークフロー集。
ブレスト、計画作成、TDD、コードレビュー依頼など、開発の各フェーズで使える“型”が用意されている。
Claude Codeに任せきりにするのではなく、人間とAIがうまく役割分担するためのベストプラクティス集。
これにより、Vibe CodingやSpec駆動開発の品質の底上げが期待できる。
参考:superpowers ※MITライセンス
superpowersは以下のワークフローで構成されています。
- 要件を整理する
- 作業環境を分ける
- 実装計画を立てる
- テストを書きながら実装する(TDD)
- レビューする
- ブランチを仕上げる
まず、brainstormingで実装したい内容を整理します。
いきなりコードを書き始めるのではなく、Claude Codeが質問をしながら、目的・仕様・代替案・懸念点を明確にします。
ここで固めた内容が、後続の設計や実装計画の土台になります。
次に、using-git-worktreesで作業用の独立した環境を作成します。
新しいブランチとworktreeを用意することで、既存の作業環境を壊さずに実装を進められます。
AIに実装を任せるうえで、安全に試行錯誤できる状態を作る工程です。
その後、writing-plansで実装計画を作成します。
変更するファイル、実装手順、検証方法を小さなタスクに分解します。
READMEでは、プロジェクト理解が浅いジュニアエンジニアでも進められるくらい明確な計画を作る、と説明されています。
After you've signed off on the design, your agent puts together an implementation plan that's clear enough for an enthusiastic junior engineer with poor taste
計画ができたら、subagent-driven-developmentまたはexecuting-plansで実装を進めます。
前者はタスクごとにサブエージェントを割り当て、仕様準拠とコード品質を確認しながら進める方式です。
後者は計画に沿ってバッチ単位で実行し、人間の確認ポイントを挟みながら進める方式です。
実装中は、test-driven-developmentによってTDDの流れが重視されます。
テストを先に書く、まだプロダクトコードがないのでテストが失敗する、テストがグリーン(正常に通過)するように実装を追加していくというRED-GREEN-REFACTORの流れです。
期待する振る舞いを先に定義することで、AIが「それっぽく動くコード」を書いて終わるのではなく、テストで確認可能な形で実装を進められます。
タスクの合間には、requesting-code-reviewでコードレビューを行います。
実装が計画に沿っているか、バグや設計上の問題がないかを確認します。
重大な問題がある場合は、次に進む前に修正する流れになります。
最後に、finishing-a-development-branchで開発ブランチを仕上げます。
テスト結果を確認し、マージするのか、Pull Requestを作るのか、ブランチを残すのか、破棄するのかを選択します。
不要になったworktreeの片付けまで含めて、開発作業を完了させます。
つまりsuperpowersは、
「考える → 分ける → 計画する → テストする → 実装する → レビューする → 仕上げる」
という堅実な開発プロセスをAIエージェントに守らせるための仕組みです。
READMEにも “The agent checks for relevant skills before any task. Mandatory workflows, not suggestions.” とあるように、強制力を持ったワークフローとして設計されています。
3.Claude Codeの初期セットアップ
社内でClaude Enterpriseのライセンスを貰ったばかりでまっさらな状態。
とりあえず挨拶してトークンを無駄遣いしておきます。
VSCodeにClaude Codeの拡張機能を入れます。
ちなみに、CodexとClaude Codeのインストール数とレビューはこんな感じ。
Claude Codeのほうがシェアも評価も高い現状。
インストールが完了すると、ログイン方法を問われます。
先ほどのClaude Enterpriseのアカウントでログインします。
接続確認が表示されるので、「承認する」を押下します。
認証コードが吐かれたので、VSCodeに戻って貼り付けます。
通りました。何やら可愛らしいキャラクターが浮かんでいます。
挨拶して無駄にトークンを消費しておきましょう。
ちなみに彼は何という名前なんだろうと調べてみたところ、「Clawd(クロード)」というそうです。
Crab(蟹)のキャラクターか。かわいいですね。よろしくね、Clawd。
次はターミナルで使うためのインストール。
Pathを通し、インストール確認。
さあ、初めての起動だ。
ターミナルの色合いを選択します。(Dark mode)
ログイン方法を選択します。
認証に成功しました。
読み飛ばす人も多いかもしれませんが、ここにとっても大事なことが書いてあります。
そんなmistakesを極力減らすのがこれから紹介するsuperpowersですね。
今回は初めての利用なので、推奨設定を選択します。
カレントディレクトリに対する権限を聞かれてます。ここは自由に操作していいのでYesを選択します。
セットアップが完了しました。
4.superpowersのインストール
公式のマーケットプレイスからインストールします。
このrepoだけでのインストールを選択します。
superpowersを手に入れました。
有効化します。
5.superpowers-brainstorming
さて、準備が整ったのでAIとブレストしてみます。
superpowers「何について議論したいんだい?」
日本語もいけるのだろうか?
ただのToDoアプリじゃつまらないので、組織向けのタスク管理ツールをテーマにしてみます。
日本語で返ってきました。
なるほど、モックを見ながら方針を決めていく方法があるそうです。せっかくなので使ってみます。
brainstorming のスキルが読みたいと言っているので許可します。
ブレストが始まりました。
中規模を選択します。
ToDoタスクの振り方、ユースケースを問われています。全部必要そうなので、そのように回答します。
あとでClaude Codeが教えてくれるのですが、「一斉12人」は「一対多」の誤字とのこと。
タスクのリマインド方法ですが、自動を選択してみます。
通知方法はサービス内にしましょう。
認証はサービス独自を選択します。
デプロイ先はAWSを想定しているのでクラウドを選択します。
タスクの進捗確認をできる人ですが、複数選択可とのことで3つ選択してみます。
スコープが広すぎるようで、MVPを聞かれています。
まあいったん一斉送信の実装から入ってほしいですね。
※MVP(Minimum Viable Product)
これは絶対に聞かれると思っていました。完了の定義です。
ここはサービス上で「対応済み」を押させる仕組みで良いでしょう。
設計の確認が始まりました。
デモアプリでMulti-AZはリッチすぎますが、プロダクト開発に使えるか評価したいので、リッチな構成でいきましょう。
「違和感ないです。」と回答します。
次はデータモデルです。
Assignmentという中間テーブルで人とタスクを紐づけていますね。そしてここでステータス管理もしています。
Notificationで通知レコードを管理する構成になっています。良いと思います。
リマインドは複数回発生する可能性があるため、このテーブルで管理します。
良い設計ですね。自分で設計するにしてもこうすると思います。
兼務とかあるとややこしくなりますが、今回はシンプル構成でいきましょう。
次はユースケースのレビューです。
ちょっと、初期開発では不要な部分があるので省略を依頼します。
次は認証・認可周りの確認です。
ここの実装を削りたいので指示します。
次はエラーハンドリング周りの確認。
次はテスト戦略です。
初期開発としては十分すぎる計画だと思います。
ここまでの内容を設計書にまとめてくれるようです。
設計書の作成が始まりました。
6.superpowers-using-git-worktrees
ローカルにgitを入れてもらい、writing-plansに引き継ぎます。
7.superpowers-writing-plans
引継ぎが終わりました。
今回はPlan1とPlan2に分かれ、Plan1でMVPを開発し、Plan2の方でデプロイ周りを計画しているようです。
ちなみに、ここまでの作業をccusageで確認。約$7でした。
$7か...個人利用だと厳しいな...。
8.superpowers-subagent-driven-development or executing-plans
次はこの計画を実行に移してもらいます。
進め方は1つのエージェントで逐次実行するか、サブエージェントを駆使してパラレルに開発するかが選べます。
今回はフルパワーが見たいので、サブエージェントを選択します。
サブエージェントのスキルが読み込まれました。
9.superpowers-test-driven-development
こっから、基本的にはYesを叩く作業になるのでスクショは一部割愛します。
(AIエージェントに許可する権限を確認しつつ)
Task 0.1が完了しました。ここまで30分くらい。
業務PCにdockerが未インストールだったため、ここで人間側にボールが渡ってきました。
ご丁寧に手順まで記載してくれているので、対応してAIエージェントにボールを戻します。
インストールが完了したので、続きを依頼します。
wslのバージョンが古くてDockerが起動できずに人間に返ってきたので、対応して続きを依頼します。
ローカルでPostgres起動、接続確認まできました。ここまで40分くらいでしょうか。
TDD用の環境セットアップが始まりました。
環境のセットアップが終わったので、ここからサブエージェントを駆使してコーディング部分を進めてもらいます。
サブエージェントでの開発に関するスキルが読み込まれました。
パスワード認証部分の仮実装が終わったようです。
TDDでテストコード→プロダクトコードの順番でコーディングが進んでいることがファイルからもわかります。
テストコードにはハッシュ化、パスの検証の正常系、異常系が書かれてます。
ちょっとテストが少ない気もしますが、あとで伏線回収するのでスルーしてください。
10.superpowers-requesting-code-review
部品の開発のたびに、コードレビューを呼んでいますね。
画像の中央付近にテスト品質に関する記載があります。
先ほどのテストケースはこの観点に通過する品質になっていることがわかります。
Test quality — Does the test verify behavior (not implementation)? Does it cover both happy path and one negative case (wrong password)? Does it avoid mocking the thing being tested?
次は権限部分のTDDが始まりました。
先に今回の3つの権限でのテストケースを作成していることがわかります。
失敗テストの作成、失敗確認、実装、成功確認というRED-GREENのサイクルを繰り返して開発が進んでいきます。
コードレビューで、prisma側の権限とアプリ内での権限で重複管理になるから、この書き方はやめてほしいとレビューで指摘を受けてますね。
そのイシューをもとに実装者が修正に入ってます。
なんだか、チーム開発っぽくなってきましたね。
11.superpowers-finishing-a-development-branch
Plan1のPhase1が終わったタイミングで、finishing-a-development-branchのスキルを読ませました。
マイグレーションテストを通してくれました。
12. 動作確認
動作確認方法を聞いて、その通りに起動します。
ログイン画面が開いたのでログインしてみます。
ログインできました。
まだ最小限の機能しかないので、引き続き開発を続けます。
全体でPhase7のうち、まだPhase1の状態です。
Phase2はタスク作成周り。
1時間かからないくらいで、Phase2が完了。
Phase3は通知周りの実装。
Phase4はリマインダー周りの実装。
Phase5はダッシュボード周りの実装。
Phase6はE2Eテストの環境構築。
E2Eを実行したところ、1件passして、2件failedになりました。
結果をコピペして、Claude Codeに返します。
2件passして、1件failedになっていました。
再度、エラーログをClaude Codeに連携して修正を依頼しました。
再実行したろころE2Eにすべて合格しました。
ちなみに、E2Eの1つ目の中身はこんな感じです。
「依頼作成 → 担当者が対応済みにする → 依頼者が進捗を確認する」一連の業務フローをブラウザ上で確認するテストになっています。
2つ目はこんな感じ。
部署管理者向けダッシュボードのE2Eテストです。
「DBを初期化→ユーザーを作成→タスクを直接DBに作成→2人分の割り当てを作成→部署管理者でログイン→ダッシュボードを開く→表示を検証(棚卸、1/2 が見えること)」という流れになっています。
3つ目はこんな感じ。
リマインダー機能のE2Eテストです。
「DBを初期化→ユーザーを作成→タスクを直接DBに作成→担当者への割り当てを作成→リマインダーAPIを実行→担当者でログイン→通知画面を確認」という流れになっています。
E2Eに通過したことを伝えると、Phase7に取り掛かりました。
数時間後、Plan1がすべて完了しました。
ちなみに、ここまでかかったコストは約$98(≒1万5千円)でした。
Plan2について
AWSへのデプロイはCodexでも容易にできるので、今回の記事では割愛させていただきます。
そのあたりの権限移譲周りについては過去の記事を参照してください。
さいごに
Codexとの比較
- Codexと比べて計画立てて自律的に走る能力が高い
- Codexと比べてコストが高い
- 自走してくれるから1日当たりの作業量が多い
- 計画を立てることにもトークンを消費する
- サブエージェントを使うと稀にハングする
ハングした際にはctrl+oで状態を確認し、ctrl+cで止めてから、再実行を依頼する必要があった。
さらに、この際にsuperpowersのサイクルから外れることがあった。
この場合、以下のように命令してsuperpowersのフローに強制的に戻してもらう必要があった。
プロンプト:ハングしているから一時停止しました。superpowersのスキルを確認してTDDでの開発を継続してください。
開発効率とコスト
ここまで約1~2日間でした。(ほかの作業をしながら裏で動かしただけ)
コストも1~2万円程度でした。
BtoC/BtoB案件の一般的な開発ではプロダクトの初期開発にかなりの時間とコストがかかります。(技術的につまることが多々ある)
これが大幅に削減できると思うと、人力開発の時代にはもう戻れないなと感じます。
採用情報
先日Xで「JTCでは社内のAI利用が進んでおらず働きにくい」みたいなのが話題になってましたが、弊社はこの数年間で各種AIツールのライセンスや申請周りがかなり整備され、めちゃくちゃ働きやすいです。AIを使って仕事したいSIの方はぜひご検討ください。。
↓ のスターを押していただけると嬉しいです。励みになります。
最後まで読んでいただき、ありがとうございました。
エンタープライズ第一本部では一緒に働いてくださる仲間を募集中です。以下のリンクからお願いします。
執筆:英 良治 (@hanabusa.ryoji)
レビュー:@miyazawa.hibiki
(Shodoで執筆されました)



