はじめに
Claude Code を使っていて、こんな経験はないでしょうか。
- いい感じに作ってくれるが、自分の意図したものに仕上げようとすると意外と時間がかかる
- 不具合の修正を頼んでもうまく伝わらず、結局自分で直す羽目になる
- 機能が増えるにつれて、別の機能に波及する不具合が出てくる
これは Claude Code が悪いのではなく、LLM は「すぐにアウトプットを出す」ように訓練されているため、設計・計画・テストといった「面倒だけど重要な工程」をスキップしがちなのが原因です。
AI コーディングの進化
この問題に対するアプローチは段階的に進化しています。
① Vibe Coding（プロンプト一発）
プロンプトを投げて AI にそのままコードを書かせる。構造も計画もなし。小さなスクリプトなら十分だが、規模が大きくなると設計破綻しやすい。
② スペック駆動開発（CLAUDE.md / spec.md を書く）
CLAUDE.md や spec.md にプロジェクトの方針や仕様を記述し、AI にコンテキストを与える。Vibe Coding より構造的だが、プロセスの強制力はなく、AI がスペックを無視して暴走することもある。
③ スキルフレームワーク（Superpowers など）
既製のスキルフレームワークをインストールして、エージェントに「規律」を注入する。② のスペック駆動に加えて、Brainstorming → 計画 → 実行 → レビューというプロセス全体が強制される。自分でゼロからワークフローを設計する必要がないのが最大の利点。
ざっくり言うと、① は構造なし、② は「何を作るか」のドキュメント、③ は「どう作るか」のプロセス強制です。
さらにその先: ハーネス設計
エージェントの動作基盤そのものを自分で設計・構築するアプローチもあります。コンテキスト管理（thin orchestrator パターン、状態の YAML 永続化）、タスク間の依存グラフモデリングと並列ディスパッチ、セッション復旧、ツールのサンドボックス化、カスタム MCP サーバー構築、CI/CD パイプラインへの統合——といった、オーケストレーション基盤を整える段階です。
本記事は ③ の話です。Superpowers という既製のスキルフレームワークを使って、Flutter の習慣トラッカーアプリをゼロから作ってみた過程と所感を紹介します。
作るもの
| 項目 | 内容 |
|---|---|
| アプリ | 習慣トラッカー（Habit Tracker） |
| 技術スタック | Flutter + Riverpod + SQLite（sqflite） |
| 画面構成 | 2 画面 + ボトムシート（ホーム、統計、習慣作成・編集） |
| 主要機能 | 習慣登録・デイリーチェック・カレンダーヒートマップ・統計表示 |
対象読者
- Claude Code は使ったことがあるが、Superpowers は未経験
- AI コーディングの「質」を上げたい
Superpowers の全体フロー
Superpowers は通常 7 つのフェーズで構成されています（詳細は GitHub を参照してください）。素の Claude Code が「プロンプト → いきなりコード」の 1 ステップなのに対し、Superpowers は開発チームが踏むべきプロセスを強制します。
ただし今回は、Brainstorming の中で「実装とテストのエージェントを分けること」「テストには E2E を含めること」を筆者が指定しました。その結果、通常のフローとは異なる構成になっています。以下は今回の開発で実際に辿ったフローです。
Phase 1: Brainstorming （人間のゲート）
コードを書く前に、ソクラテス式の対話で要件を詰めます。Superpowers が一度に 1 つずつ質問を投げ、2〜3 案をトレードオフ付きで提示。承認されたデザインスペックが生成されるまで先に進めません。このフェーズをスキップできない設計が最大の特徴です。
Phase 2: Write Plan （人間のゲート）
承認されたデザインスペックから、タスクリストを自動生成します。各タスクには正確なファイルパス、コードスニペット、検証コマンド、期待結果、git コミットメッセージまで含まれます。
今回は Part A と Part B の 2 パート構成で生成されました。「実装とテストを同じエージェントに書かせない」という制約は Brainstorming で筆者が指定したもので、Superpowers がそれを Plan の構造にそのまま反映しています。
Phase 3: Part A 実行 — Implementation Agent （自動）
Implementation Agent が Part A のタスクを順次実行します。プロジェクトセットアップ → DB レイヤー → モデル → リポジトリ → プロバイダー → テーマ → ウィジェット → 画面 → ナビゲーションの順に、各タスクが flutter analyze → git commit のサイクルで進みます。
各タスク完了後にはスペック準拠レビューが実行され、実装が仕様通りかを別エージェントが検証します。実際に HabitRecord モデルの copyWith() メソッド欠落がレビューで検出され、即座に修正されました。
Phase 4: Part B 実行 — Testing Agent （自動・別エージェント）
Part A の完了後、 別のエージェント（Testing Agent） が Part B のタスクを実行します。モデルのユニットテスト → リポジトリのユニットテスト（インメモリ SQLite）→ ウィジェットテスト → E2E 統合テストの順です。エージェント分離と E2E テストの採用は、どちらも Brainstorming で筆者が指定した方針です。
Phase 5: Finishing （人間のゲート）
全テストが通過した後、以下の選択肢が提示されます:
- マージ
- PR 作成
- 作業継続
- ブランチ破棄
ポイント: 人間 vs エージェント
Superpowers の設計で重要なのは、 すべてを自動化しているわけではない という点です。Phase 1（Brainstorming）、Phase 2（Write Plan）、Phase 5（Finishing）は人間の承認が必要なゲートであり、方向性の判断は常に人間が握っています。一方、実装とテストはエージェントが自動で回すため、人間は「考える仕事」に集中できます。
環境準備
前提
- Claude Code がインストール済み
- Flutter 開発環境がセットアップ済み
Superpowers のインストール
Claude Code に入った後 /plugin を実行すると、以下のような画面に切り替わります。Superpowers は Claude Code の Official Marketplace に登録されているので、"Discover" タブに移動すれば見つかるはずです。見つけたら選択（スペースキー）してインストールしてください。
インストール完了後、/reload-plugins を実行してプラグインを再読み込みすると、Superpowers のスキルが有効になります。
Phase 1: Brainstorming — 「何を作るか」を詰める
今回は、まったく空のフォルダを用意した上で、Claude Code に ブレインストーミングして と投げてみます。
すると、Claude Code が現状を把握した上で、以下のようないくつか対話型の質問をしてくれます。
アプリの形式
対象プラットフォーム
開発フレームワーク
ターゲットユーザー
個人的にいいなと感じたのは、デザインのイメージをブラウザで確認できるサンプルを作ってくれた点です。
デザイン
要件がまとまった後は、アーキテクチャ、データモデル、画面構成とナビゲーション、UI モックなどを順に確認していきました。
アーキテクチャ
Feature-first のディレクトリ構成で、Data / Providers / UI の 3 レイヤーに分離。将来クラウド同期を追加する際には、Repository の実装を差し替えるだけで済む設計です。
DB スキーマ
habits テーブルと habit_records テーブルの 2 テーブル構成。(habit_id, date) の UNIQUE 制約で重複登録を防止し、CASCADE DELETE で習慣削除時にレコードも自動削除します。
ビジュアルデザイン:「Colorful & Pop」
グラデーション背景、個別カラーのグラデーションカード、5 段階のヒートマップカラースケール——かなりポップなデザインが提案されました。
最終的に確定した仕様の要点
Superpowers との対話を通じて、MVP のスコープが想像以上にクリアに整理されました。
| MVP に入ったもの | MVP から外れたもの |
|---|---|
| 習慣 CRUD（作成・編集・削除） | クラウド同期 / ユーザーアカウント |
| デイリーチェック（done / not done） | リマインダー / プッシュ通知 |
| カレンダーヒートマップ | ダークモード |
| サマリーカード（現在のストリーク・月間達成率・最高ストリーク） | マネタイズ |
| BottomNavigationBar による 2 画面構成 | ホーム画面ウィジェット（iOS / Android） |
Phase 2: Write Plan — 実装計画の生成
承認されたデザインスペックから、タスクリストが自動生成されます。
実行計画の作成開始
実行計画の作成完了
タスクリストの全体像
生成された計画は 全 17 タスク 、大きく 2 つのパートに分かれています。
| パート | タスク数 | 内容 |
|---|---|---|
| Part A: Implementation | 13 タスク | プロジェクトセットアップから UI 実装まで |
| Part B: Testing | 4 タスク | ユニットテスト、ウィジェットテスト、E2E テスト |
Part A: Implementation（実装エージェントが担当）
| # | タスク | 主な成果物 |
|---|---|---|
| 1 | プロジェクトセットアップ | Flutter プロジェクト作成、依存関係追加 |
| 2 | データベースレイヤー |
database_helper.dart（SQLite スキーマ） |
| 3 | データモデル |
Habit, HabitRecord モデルクラス |
| 4 | Habit リポジトリ | CRUD 操作、トグル記録 |
| 5 | Stats リポジトリ & 日付ユーティリティ | ヒートマップデータ、ストリーク計算 |
| 6 | Riverpod プロバイダー | 状態管理（habits, todayRecords, stats） |
| 7 | アプリテーマ | カラーパレット、グラデーション、ヒートマップ色 |
| 8 | Habit Tile ウィジェット | グラデーションカードの個別習慣タイル |
| 9 | ホーム画面 | 今日の習慣リスト、プログレスヘッダー |
| 10 | 習慣フォーム | 作成・編集用ボトムシート |
| 11 | ヒートマップカレンダー | カレンダー形式の達成可視化 |
| 12 | 統計画面 | サマリーカード + ヒートマップ表示 |
| 13 | アプリシェル & ナビゲーション |
app.dart, main.dart, BottomNavigationBar |
Part B: Testing（テストエージェントが担当）
| # | タスク | 内容 |
|---|---|---|
| 14 | モデル & ユーティリティのユニットテスト | Habit, HabitRecord, AppDateUtils |
| 15 | リポジトリのユニットテスト | sqflite_common_ffi でインメモリ SQLite テスト |
| 16 | ウィジェットテスト | HabitTile, HeatmapCalendar |
| 17 | E2E 統合テスト | 作成・チェック・編集・削除の 4 フロー |
注目ポイント: 実装とテストのエージェント分離
この計画で注目すべきは、Plan の冒頭にある以下の制約です。
Constraint: Implementation (Part A) and Testing (Part B) MUST be executed by separate sessions or separate sub-agents. The same agent must never write both production code and its tests.
これは Brainstorming の中で筆者が指定した要件 です。人間の開発チームでも理想とされる「実装者とテスターの分離」を、エージェントレベルで実現したいと考えました。結果として Plan が Part A / Part B の 2 パート構成で生成され、制約がそのまま計画に反映されています。
同様に、 E2E テスト （Task 17）も筆者が含めるよう指定したもの です。Superpowers はこれらの指定を受けて、integration_test を使った 4 つのユーザーフローテスト（作成・チェック・編集・削除）を Plan に組み込みました。
Superpowers の良いところは、こうした人間からの設計指示をデザインスペック → Plan の流れの中で自然に吸収し、タスクレベルまで落とし込んでくれる点です。
Phase 3: Part A 実行 — Implementation Agent がコードを書く
Plan の Part A に基づいて、Implementation Agent が Task 1〜13 を順次実行し、アプリが出来上がりました。
各タスク完了後にはスペック準拠レビューが自動で走ります。今回、Part A 全体のレビューで HabitRecord モデルに copyWith() メソッドが欠落していることが検出され、即座に修正・コミットされました。こうした「仕様どおりに作れているか」の自動検証は、素の Claude Code にはない仕組みです。
Phase 4: Part B 実行 — Testing Agent がテストを書く
Part A の完了後、 別のエージェント（Testing Agent） が Part B の Task 14〜17 を実行します。「実装とテストを別エージェントにする」という構成は Brainstorming で筆者が指定したもので、実装者の思い込みがテストに漏れない構造を狙っています。
テストの種類・範囲・結果
Plan が生成したテストは 4 層構造です。
| テスト種別 | テスト数 | 実行環境 | カバー範囲 |
|---|---|---|---|
| Unit（モデル + ユーティリティ） | 89 | デスクトップ | Habit, HabitRecord, AppDateUtils |
| Unit（リポジトリ） | 56 | デスクトップ（インメモリ SQLite） | HabitRepository, StatsRepository |
| Widget | 36 | デスクトップ | HabitTile, HeatmapCalendar |
| E2E | 4 フロー | iPhone シミュレータ（iOS 26.4） | 作成・チェック・編集・削除 |
| 合計 | 185 |
E2E テストの初回実行時には 2 件のテストが失敗しました。1 つは DatabaseHelper がシングルトンのため前回のアプリ起動データが残っていた問題、もう 1 つは Flutter フレームワークのキーボードイベント関連のアサーションエラーでした。いずれもテストコードの修正（setUp での DB クリア、pumpAndSettle → pump への変更）で解決し、最終的に 4/4 全パス を確認しました。
Phase 5: Finishing — ブランチ完了
全テストが通った後、Superpowers が選択肢を提示します:
- マージ
- PR 作成
- 作業継続
- ブランチ破棄
完成したアプリ
ホーム画面
グラデーションヘッダーに日付と今日の進捗バーを表示。習慣はカラフルなグラデーションカードで一覧され、タップでチェック ON/OFF、ロングプレスで編集・削除メニューが開きます。「+」ボタンで新しい習慣を追加。
統計画面（Stats）
上部に 3 つのサマリーカード（Current Streak / This Month / Best Streak）、その下にカレンダーヒートマップ。月送りで過去の達成状況を振り返れます。ヒートマップは 5 段階のカラースケール（薄ピンク → 深紅）で達成率を表現。
習慣作成・編集（ボトムシート）
名前入力、6 色のカラーパレット、12 種のアイコンプリセットから選択。ボトムシート形式で画面遷移なしに操作が完結します。
生成されたコードの構成
lib/
├── main.dart # エントリポイント
├── app.dart # MaterialApp, BottomNavigationBar
├── core/
│ ├── database/
│ │ └── database_helper.dart # SQLite 接続 & スキーマ
│ ├── theme/
│ │ └── app_theme.dart # Colorful & Pop テーマ
│ └── utils/
│ └── app_date_utils.dart # 日付ヘルパー
└── features/
├── habits/
│ ├── data/
│ │ ├── habit_repository.dart # CRUD & トグル
│ │ └── models/
│ │ ├── habit.dart # Habit モデル
│ │ └── habit_record.dart # HabitRecord モデル
│ ├── providers/
│ │ └── habit_providers.dart # Riverpod プロバイダー
│ └── ui/
│ ├── screens/
│ │ ├── home_screen.dart # ホーム画面
│ │ └── habit_form_screen.dart # 作成・編集シート
│ └── widgets/
│ └── habit_tile.dart # 習慣カードウィジェット
└── stats/
├── data/
│ └── stats_repository.dart # 統計クエリ
├── providers/
│ └── stats_providers.dart # 統計プロバイダー
└── ui/
├── screens/
│ └── stats_screen.dart # 統計画面
└── widgets/
└── heatmap_calendar.dart # ヒートマップウィジェット
振り返り
素の Claude Code との比較
| 観点 | 素の Claude Code | Superpowers |
|---|---|---|
| 設計フェーズ | なし（いきなりコード） | Brainstorming で要件・スコープが詰まる |
| テスト | 後付け or なし | 実装とテストを別エージェントで分離（筆者が指定） |
| タスク管理 | 1 本道 | 17 タスクに分解、Part A/B の構造化 |
| 手戻り | 中盤で設計破綻しがち | デザインスペックで先に合意 |
| スコープ管理 | 際限なく膨らみがち | MVP / Out of Scope が明示される |
| 品質チェック | なし | タスクごとにスペック準拠レビューが自動実行 |
よかった点
-
構造化されたフローにそのまま乗れる
スペック駆動開発を独自に進めようとすると、フローの整備やスペックのフォーマット統一だけでかなりの手間がかかります。 Superpowers はあらかじめ定められたフローに則って進むだけで、構造化されたアウトプット（デザインスペック、実装計画、コミット単位のタスク）が自然に生成されます -
Brainstorming で具体的な画面を見ながら判断できる
デザインの方向性を言葉だけで詰めるのは難しいですが、Superpowers はブラウザで確認できるサンプル画面を生成してくれるため、「この路線で行くか」の判断が格段にしやすかったです -
E2E テストの導入で人間の確認コストが大幅に減った
これは筆者が独自に指定したものですが、E2E テストがあることで「実装されていない」「不具合が直っていない」という手戻りが減り、全体の開発時間が短縮されました
気になった点・改善の余地
-
既存プロジェクトへの途中導入はできるのか
今回はゼロからのスタートだったので Superpowers のフローにきれいに乗れましたが、すでにコードベースがあるプロジェクトに途中から導入する場合のワークフローは未検証です -
アプリが巨大化したときにどこまで制御できるのか
今回は 2 画面 + ボトムシートという小規模なアプリでした。画面数やビジネスロジックが増えたとき、Plan の粒度やサブエージェントの管理がどこまでスケールするかは気になるところです -
セキュリティ観点の診断はカバーされるのか
Superpowers のレビューはスペック準拠とコード品質が中心で、脆弱性診断やセキュリティレビューは現時点では含まれていません。本番リリースを見据える場合は別途対策が必要になります
おわりに
Superpowers は、Vibe Coding の手軽さを残しつつ、スペック駆動開発の「もう一歩先」を体験できるフレームワークでした。インストールするだけで設計・計画・実行のプロセスが整うので、自分でワークフローを組む手間なく、AI コーディングの質を引き上げられます。
少しでも気になった方は、ぜひ一度試してみてください。/plugin からインストールして、空のフォルダで ブレインストーミングして と投げるだけで始められます。
「自分はこんな使い方をしている」「こういうプロジェクトで試したらこうだった」といった話があれば、ぜひコメントで教えてください。