上流工程で品質確保・実装でコスト削減：spec-workflow-mcpとobra/superpowersによるAI駆動開発環
1. はじめに
AI駆動開発において、「上流工程の品質確保」と「実装コストの最適化」を両立させることは重要な課題です。本記事では、仕様策定フェーズでは高品質なSonnet 4.5を活用し、実装フェーズでは低コストモデルに切り替えることで、品質とコストのバランスを実現する開発環境を紹介します。
この環境の特徴は以下の通りです。
上流工程での品質確保: spec-workflow-mcpとClaude Code（Sonnet 4.5）により、仕様策定・要件定義を高品質な推論能力で実施します。Webダッシュボードを通じた承認フローにより、仕様の品質を人間が確認しながら進められます。
実装フェーズのコスト最適化: obra/superpowersとClaude Code Router（OpenRouter経由）により、実装・テスト・デバッグをDeepSeek R1やGemini 3 Flashなどの低コストモデルで効率的に実行します。Gemini 3 Flashは1日1,500リクエストまで無料で利用でき、DeepSeek R1も非常に低コストです。
tmuxによるデュアルペイン構成: 左ペインでSonnet 4.5を使った仕様策定、右ペインでOpenRouterモデルを使った実装を進められます。各フェーズに最適なモデルを使い分けることで、開発全体のコストパフォーマンスを最大化します。
この構成により、上流工程では妥協のない品質を、実装フェーズでは高速な開発サイクルを実現できます。
2. システム概要
このワークフローは、以下の3つの主要コンポーネントで構成されています。
graph TB
A[開発者] --> B[tmux]
B --> C[左ペイン: オリジナルClaude Code]
B --> D[右ペイン: claude-code-router]
C --> E[spec-workflow-mcp]
E --> F[Webダッシュボード<br/>localhost:5050]
D --> G[OpenRouter API]
G --> H[Gemini 3 Flash]
G --> I[DeepSeek R1]
D --> J[obra/superpowers]
J --> E
style F fill:#e1f5ff
style E fill:#fff3cd
style J fill:#d4edda2.1. アーキテクチャの特徴
デュアルペイン構成: tmuxを使用し、上流工程（仕様策定）はオリジナルのClaude Code、実装フェーズはclaude-code-routerを使い分けることで、各フェーズに最適なモデルを活用します。
プロトコルベースの統合: MCP（Model Context Protocol）により、AIモデルと外部ツール、データソース間の標準化されたインターフェースを提供します。
リアルタイム承認フロー: spec-workflow-mcpのWebダッシュボードを通じて、仕様書のレビューと承認をインタラクティブに実施できます。
3. 主要ツールの詳細
3.1. Claude Code Router
Claude Code Routerは、Claude CodeインターフェースとAIモデル間に位置するスマートプロキシサーバーです。リクエストを傍受し、定義されたルールに基づいて異なるAIモデルプロバイダーにインテリジェントにルーティングします。今回は下記のモデルの自動切り替えは利用しませんが、設定により自動切り替えが可能になります。
コンテキストベースルーティング: タスクの種類に応じて最適なモデルを自動選択します。
default: 汎用タスクthink: 複雑な推論・設計タスクbackground: シンプルな低コスト処理longContext: 32Kトークンを超える長文処理webSearch: リアルタイムWeb検索が必要なタスクimage: 画像解析を含むマルチモーダルタスク
対応プロバイダー: OpenRouter、DeepSeek、Ollama、Gemini、Volcengineなど多様なプロバイダーに対応しています。
3.2. MCP (Model Context Protocol)
MCPは、Anthropicが発表したオープン標準フレームワークで、AIシステムと外部ツール、データソース間のデータ統合を標準化します。従来の「N×M」データ統合問題を解決し、各データソースごとにカスタムコネクターを構築する必要性を排除します。
MCPは永続的なプロトコルベースのコンテキストを提供し、入力、ツール出力、中間状態を複数のインタラクションにわたって追跡します。これにより、外部状態管理なしで複雑なエージェント動作が可能になります。
3.3. spec-workflow-mcp
spec-workflow-mcpは、仕様駆動開発のためのMCPサーバーです。以下の機能を提供します。
- 仕様解析エンジン（YAML/JSON Schema対応）
- リアルタイムWebダッシュボード
- タスク・仕様・エージェントの進捗モニタリング
- 承認システム
- CI/CD連携
ワークフロープロセス:
graph LR
A[steering-guide] --> B[create-steering-doc]
B --> C[product.md]
B --> D[tech.md]
B --> E[structure.md]
C --> F[spec-workflow-guide]
D --> F
E --> F
F --> G[create-spec-doc]
G --> H[Requirements.md]
G --> I[Design.md]
G --> J[Tasks.md]
H --> K[承認]
I --> K
J --> K
K --> L[Implementation]
style C fill:#fff3cd
style D fill:#fff3cd
style E fill:#fff3cd
style H fill:#d4edda
style I fill:#d4edda
style J fill:#d4edda3.4. obra/superpowers
superpowersは、Claude Code用のコアスキルライブラリで、TDD、デバッグ、コラボレーションパターンなど実証済みのテクニックを提供します。
主要スキル:
- brainstorming: ソクラテス式の設計改善
- writing-plans: 詳細な実装計画の作成
- executing-plans: チェックポイント付きバッチ実行
- test-driven-development: 自動アクティブ化されるTDD
- systematic-debugging: 体系的なデバッグアプローチ
- verification-before-completion: 完了前の検証
スキルは関連するタスクで自動的にアクティブ化され、スラッシュコマンド（/superpowers:brainstorm、/superpowers:write-plan、/superpowers:execute-plan）で手動起動も可能です。
4. 環境構築手順
4.1. Claude Code Routerのインストール
npm install -g @musistudio/claude-code-router初期設定用UIを起動:
ccr ui4.2. MCPサーバーのインストール
context7（コンテキスト管理）:
claude mcp add context7 -- npx -y @upstash/context7-mcp@latestserena（補助ツール）:
claude mcp add serena -- uvx --from git+https://github.com/oraios/serena serena-mcp-serverspec-workflow-mcp（プロジェクトごとに設定が必要）:
cd [プロジェクトのパス]
claude mcp add --scope project spec-workflow npx @pimzino/spec-workflow-mcp@latest -- "$(pwd)"動作しない場合はバージョンを指定:
claude mcp add --scope project spec-workflow npx @pimzino/spec-workflow-mcp@v2.0.9 -- "$(pwd)"4.3. ダッシュボードの起動
プロジェクトディレクトリで実行:
npx -y @pimzino/spec-workflow-mcp@latest . --dashboard --port 5050macOSではデフォルトポート（5000）が競合するため5050番に変更します。自動的にデフォルトのブラウザで http://localhost:5050/ が開きます。
不要になったプロジェクトのspec-workflow-mcpを削除する場合:
claude mcp list
claude mcp remove spec-workflow4.4. obra/superpowersのインストール
/plugin marketplace add obra/superpowers-marketplace
/plugin install superpowers@superpowers-marketplace4.5. プロジェクトスクリプトの作成
start-claude.sh - tmuxセッション管理:
#!/bin/bash
SESSION="myproject"
# 新しいセッションを作成
tmux new-session -d -s $SESSION
# 最初のペインでclaudeを実行
tmux send-keys -t $SESSION:0.0 "claude" C-m
# 画面を垂直分割
tmux split-window -h -t $SESSION:0
# 2つ目のペインでccr codeを実行
tmux send-keys -t $SESSION:0.1 "ccr code" C-m
# セッションにアタッチ
tmux attach-session -t $SESSION実行権限を付与:
chmod +x start-claude.shこのスクリプトにより以下が実現されます:
- 左ペイン: オリジナルのClaude Code
- 右ペイン: claude-code-router（OpenRouter接続）
上流工程のspec-workflow-mcpはオリジナルを使い、実装以降のsuperpowersはclaude-code-routerを使います。
tmuxはウィンドウを閉じてもセッションは継続するため、完全に停止する場合は以下のコマンドを実行:
tmux kill-serversetup-commands.sh - プロジェクト固有スキルの生成:
#!/bin/bash
# Skillsディレクトリのルート作成
mkdir -p .claude/skills
echo "🔧 Setting up Claude Code Project Skills..."
echo "📂 Target: .claude/skills/"
echo ""
# 関数: スキル作成 (ヒアドキュメント版)
create_skill() {
local name="$1"
local description="$2"
local content="$3"
local skill_dir=".claude/skills/$name"
local file="$skill_dir/SKILL.md"
mkdir -p "$skill_dir"
cat <<EOF > "$file"
***
description: $description
***
$content
EOF
echo "✅ Created: $name ($file)"
}
# 共通の自動実行抑止メッセージ
NO_AUTO_START_MSG="
【重要】
このコマンドを実行した直後に、**自動的にフェーズ1 (仕様策定) やその他のワークフローを開始しないでください。**
既存のファイルを確認したり、spec-workflow を読み込んだりする必要はありません。
単に設定の変更やモードの切り替えを行い、完了したら「設定を適用しました。次の指示を待機しています。」と答えて、**ユーザーからの次の具体的な指示を待ってください。**"
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# Model Switching Skills (モデル切り替え)
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# md-fast: Gemini 3 Flash
MD_FAST_CONTENT="/model openrouter,google/gemini-3-flash-preview$NO_AUTO_START_MSG"
create_skill "md-fast" \
"Switch to fast model" \
"$MD_FAST_CONTENT"
# md-think: DeepSeek R1
MD_THINK_CONTENT="/model openrouter,tngtech/deepseek-r1t2-chimera$NO_AUTO_START_MSG"
create_skill "md-think" \
"Switch to reasoning model" \
"$MD_THINK_CONTENT"
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# Workflow Skills (開発プロセス)
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
create_skill "plan" \
"Generate a generic implementation plan using Superpowers" \
"/superpowers:write-plan"
create_skill "exec" \
"Execute the current plan using Superpowers" \
"/superpowers:execute-plan"
create_skill "review" \
"Brainstorm or review code quality using Superpowers" \
"/superpowers:brainstorm"
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# Phase Skills (フェーズ実行)
# ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━
# Phase 2: 要件定義と初期セットアップ
PHASE2_PROMPT=".spec-workflow/steering/ の承認された仕様に基づき、以下のドキュメントを作成してください:
1. Requirements.md（詳細要件定義）
2. Design.md（設計書）
3. Tasks.md（実装タスク一覧）
【重要】Tasks.md の Task 1（環境構築）には、CLAUDE.md の「フェーズ 2: 詳細要件定義」セクションに記載されている**「環境構築手順 1〜8」**をそのままタスクとして定義してください。
特に scripts/ 以下のLintスクリプト作成や package.json の設定は、CLAUDE.mdのコード例をそのまま使用するよう指示してください。"
create_skill "phase2" \
"Generate Requirements, Design, Tasks docs, and setup initial environment" \
"$PHASE2_PROMPT"
# Phase 3: 実装計画
PHASE3_PROMPT="Tasks.md を読み込み、全タスク（Task 1〜最後まで）の詳細な実装計画を作成してください。
/superpowers:write-plan を使って計画を作成します。
各タスクごとに以下を明記してください:
1. 実装内容
2. 編集ファイル
3. Lint実行タイミング (npm run lint)
4. 完了条件
出力形式:
━━━ Task N: [タスク名] ━━━
1. [Step]...
"
create_skill "phase3-plan" \
"Analyze Tasks.md and create a comprehensive implementation plan" \
"$PHASE3_PROMPT"
echo ""
echo "🎉 Project Skills setup complete!"
echo "Available Skills (in .claude/skills/):"
echo " /md-fast - Switch to Gemini Flash (No Auto-Start)"
echo " /md-think - Switch to DeepSeek R1 (No Auto-Start)"
echo " /plan - Write Plan"
echo " /exec - Execute Plan"
echo " /review - Code Review"
echo " /phase2 - Scaffolding & Requirements"
echo " /phase3-plan - Implementation Planning"実行権限を付与して実行:
chmod +x setup-commands.sh.clause/skills配下にファイルが生成されます。
5. プロジェクトのファイル構成
環境構築完了時点（Task 1完了後）のプロジェクトフォルダ構造を図示します。
5.1. ディレクトリ構成図
project-root/
│
├── .claude/ # 🤖 Claude Code スキル設定
│ └── skills/ # プロジェクト固有スキル
│ ├── md-fast/
│ │ └── SKILL.md # Gemini 3 Flashへ切替
│ ├── md-think/
│ │ └── SKILL.md # DeepSeek R1へ切替
│ ├── plan/
│ │ └── SKILL.md # 実装計画作成
│ ├── exec/
│ │ └── SKILL.md # 計画実行
│ ├── review/
│ │ └── SKILL.md # コードレビュー
│ ├── phase2/
│ │ └── SKILL.md # 要件定義生成
│ └── phase3-plan/
│ └── SKILL.md # 実装計画策定
│
├── .spec-workflow/ # 📋 仕様管理 (spec-workflow-mcp)
│ ├── steering/ # フェーズ1: 仕様策定（承認済み）
│ │ ├── product.md # 製品仕様
│ │ ├── tech.md # 技術仕様
│ │ └── structure.md # 構造仕様
│ └── specs/ # フェーズ2: 詳細要件（承認済み）
│ └── todo-app/
│ ├── requirements.md # 詳細要件定義
│ ├── design.md # 設計書
│ └── tasks.md # 実装タスク一覧
├── setup-commands.sh # スキル生成スクリプト（実行済み）
└── start-claude.sh # tmuxセッション起動スクリプト5.2. 機能別ファイル分類
graph LR
subgraph A["🎯 開発フェーズ制御"]
A1[/md-fast<br/>高速モデル切替/]
A2[/md-think<br/>推論モデル切替/]
A3[/phase2<br/>要件定義生成/]
A4[/phase3-plan<br/>実装計画作成/]
end
subgraph B["⚡ 実装支援"]
B1[/plan<br/>計画作成/]
B2[/exec<br/>計画実行/]
B3[/review<br/>コードレビュー/]
end
subgraph C["📄 仕様書"]
C1[product.md<br/>製品仕様]
C2[tech.md<br/>技術仕様]
C3[structure.md<br/>構造仕様]
end
subgraph D["📋 要件定義"]
D1[requirements.md<br/>詳細要件]
D2[design.md<br/>設計書]
D3[tasks.md<br/>タスク一覧]
end
style A fill:#fff3cd,stroke:#f0ad4e,stroke-width:2px
style B fill:#d4edda,stroke:#5cb85c,stroke-width:2px
style C fill:#d1ecf1,stroke:#5bc0de,stroke-width:2px
style D fill:#f8d7da,stroke:#d9534f,stroke-width:2px5.3. ディレクトリ詳細説明
| ディレクトリ/ファイル | 役割 | 使用タイミング |
|---|---|---|
.claude/skills/ |
プロジェクト固有スキル定義 | 常時（コマンド実行時に参照） |
.spec-workflow/steering/ |
フェーズ1の仕様書 | フェーズ1完了後、常に参照可能 |
.spec-workflow/specs/ |
フェーズ2の要件定義書 | フェーズ2完了後、実装時に参照 |
package.json |
npm設定とlintコマンド | npm runコマンド実行時 |
setup-commands.sh |
スキル生成スクリプト | 初回環境構築時のみ実行済み |
start-claude.sh |
tmux起動スクリプト | Claude Code起動時 |
この構成により、仕様策定から実装、品質確認までの全フェーズをスムーズに進められる環境が整っています。
6. ToDoアプリ開発の完全フロー
実際のToDoアプリ開発を例に、具体的なワークフローを解説します。
6.1. 前提条件
プロジェクトディレクトリで実行:
npx -y @pimzino/spec-workflow-mcp@latest . --dashboard --port 5050自動的にブラウザが起動します。
Claude Code起動:
./start-claude.sh- 左ペイン: オリジナルのClaude Code
- 右ペイン: claude-code-router（OpenRouter接続）
上流工程のspec-workflow-mcpはオリジナルを使い、実装以降のsuperpowersはclaude-code-routerを使います。
6.2. フェーズ1: 仕様策定 (Steering)
6.2.1. ステップ1.1: 要件入力
ユーザーが入力:
新しいToDoアプリを作成したいです。
以下の要件でフェーズ1の仕様策定を開始してください
要件:
- シンプルなタスク管理（追加・完了・削除）
- ローカルストレージで永続化
- レスポンシブデザイン
- JavaScript（バニラJS）で実装
- Biomeでlint管理
spec-workflow-mcpを使って仕様策定から始めてください。6.2.2. ステップ1.2: Claude Codeの質問 → 回答
質問1: ユーザー層とユースケース
Claude Codeが質問:
このToDoアプリは、主にどのような目的で使用されることを想定していますか？
A) 個人の日常タスク管理（買い物リスト、家事、趣味など）
B) 仕事・プロジェクトのタスク管理（優先度や期限が重要）
C) 学習・勉強のタスク管理（課題、復習項目など）
D) シンプルなメモ・チェックリストとして（用途を限定しない汎用的なもの）
どれが最も近いですか？または別の用途がありますか？ユーザー回答: A
質問2: タスクの構造
Claude Codeが質問:
日常タスクを管理する際、タスクの情報として何が必要でしょうか？
A) タスクのテキストのみ（最もシンプル）
B) テキスト + 期限日
C) テキスト + カテゴリ（買い物、家事、趣味など）
D) テキスト + 期限日 + カテゴリ
どのレベルの情報管理が必要ですか？ユーザー回答: A
質問3: タスクの編集機能
Claude Codeが質問:
タスクを追加した後、内容を変更したくなることはありますか？
A) 編集機能は不要（削除して再追加すればOK）
B) 編集機能が欲しい（タスクのテキストを後から修正できる）
どちらが使いやすいと思いますか？ユーザー回答: A
質問4: 完了したタスクの扱い
Claude Codeが質問:
タスクを完了した後、そのタスクはどう表示されるべきでしょうか？
A) 完了したら即座に削除される（履歴は残らない）
B) 完了したタスクは取り消し線付きでリストに残り、別途削除ボタンで消せる
C) 完了したタスクは「完了済み」セクションに移動し、一括削除できる
D) その他（具体的に教えてください）
どの動作が使いやすいと思いますか？ユーザー回答: B
質問5: デザインの方向性
Claude Codeが質問:
UI/デザインのスタイルについて、どのような雰囲気を目指しますか？
A) ミニマル・モダン（白ベース、シャープなライン、マテリアルデザイン風）
B) 温かみのある優しいデザイン（柔らかい色、丸みのあるボタン）
C) ダークモード対応のクールなデザイン
D) とにかくシンプル（装飾最小限、機能的なデザイン）
どれがお好みですか？ユーザー回答: A
質問6: タスクの表示順序
Claude Codeが質問:
タスクリストの並び順はどうしますか？
A) 追加した順に上から表示（新しいタスクが下に追加される）
B) 新しいタスクが上に表示（最新が一番上）
C) 未完了タスクを上、完了済みタスクを下に分けて表示
D) その他（具体的に教えてください）
どの並び順が使いやすいですか？ユーザー回答: C
質問7: 追加の便利機能
Claude Codeが質問:
以下のような補助的な機能は必要ですか？
A) 完了済みタスクを一括削除するボタン
B) タスク数の表示（例：「3/5タスク完了」）
C) 両方とも欲しい
D) どちらも不要（本当にシンプルに保ちたい）
どれが良いですか？ユーザー回答: D
アプローチの提案
Claude Codeが提案:
これまでの要件をまとめると：
- 機能：タスクの追加・完了・削除のみ
- データ：タスクのテキストのみ
- 表示：未完了タスクが上、完了済みが下（取り消し線付き）
- デザイン：ミニマル・モダン（白ベース、マテリアルデザイン風）
- 技術：バニラJS、ローカルストレージ、レスポンシブ、Biome
***
アプローチの提案
このToDoアプリを実装する方法として、3つのアプローチが考えられます。
【推奨】アプローチB：モジュラー構成
構成：
- index.html - 構造
- styles.css - スタイル
- app.js - ロジック
メリット：
- ファイルが分離されて保守しやすい
- Biomeでのlintが効きやすい
- 将来的な拡張が容易
- それでいてシンプル
デメリット：
- 3ファイル管理が必要ユーザー回答: B
セクション1：全体アーキテクチャとファイル構成
Claude Codeが説明:
ディレクトリ構造
project-root/
├── index.html # メインHTML
├── styles.css # スタイルシート
├── app.js # アプリケーションロジック
├── biome.json # Biome設定
└── package.json # npm設定
技術スタック
- HTML5：セマンティックなマークアップ
- CSS3：Flexboxでレイアウト、CSS変数でテーマ管理
- Vanilla JavaScript (ES6+)：クラス構文、アロー関数、テンプレートリテラル
- LocalStorage API：データ永続化
- Biome：lintとフォーマット
アーキテクチャパターン
シンプルなMVC風の構成：
- Model：app.js内のデータ管理関数（LocalStorageとの同期）
- View：DOM操作とレンダリング関数
- Controller：イベントハンドラーとアプリ初期化
3ファイルのみで、外部ライブラリは一切使用しません。app.jsは即時実行関数（IIFE）またはモジュールパターンでグローバル汚染を防ぎます。
***
ここまでの構成で問題ありませんか？ユーザー回答: OK
セクション2：データ構造とローカルストレージ
Claude Codeが説明:
データモデル
各タスクは以下のシンプルなオブジェクトで表現します：
{
id: "1234567890123", // タイムスタンプベースのユニークID
text: "牛乳を買う", // タスクのテキスト
completed: false // 完了状態（true/false）
}
ストレージ設計
- キー名："todoApp_tasks"
- 保存形式：JSON文字列化した配列
- 保存タイミング：タスクの追加・完了・削除のたびに即座に保存
// 保存例
localStorage.setItem('todoApp_tasks', JSON.stringify(tasks));
// 読み込み例
const tasks = JSON.parse(localStorage.getItem('todoApp_tasks') || '[]');
データ操作の基本フロー
1. 初期化時：LocalStorageから既存タスクを読み込み
2. 追加時：配列に新オブジェクトを追加 → LocalStorage更新 → UI再描画
3. 完了時：該当タスクのcompletedを反転 → LocalStorage更新 → UI再描画
4. 削除時：配列から該当タスクを削除 → LocalStorage更新 → UI再描画
すべての操作後、必ずLocalStorageに保存し、UIを再描画することでデータとビューの整合性を保ちます。
***
このデータ設計で大丈夫ですか？ユーザー回答: OK
セクション3：UI構造とHTML設計
Claude Codeが説明:
HTML構造
<!DOCTYPE html>
<html lang="ja">
<head>
<meta charset="UTF-8">
<meta name="viewport" content="width=device-width, initial-scale=1.0">
<title>ToDoアプリ</title>
<link rel="stylesheet" href="styles.css">
</head>
<body>
<div class="container">
<header>
<h1>ToDoリスト</h1>
</header>
<div class="input-section">
<input type="text" id="taskInput" placeholder="新しいタスクを入力...">
<button id="addButton">追加</button>
</div>
<div class="task-list" id="taskList">
<!-- タスクが動的に追加される -->
</div>
</div>
<script src="app.js"></script>
</body>
</html>
タスク項目のHTML構造（JavaScriptで動的生成）
<div class="task-item" data-id="1234567890123">
<input type="checkbox" class="task-checkbox">
<span class="task-text">牛乳を買う</span>
<button class="delete-button">×</button>
</div>
完了済みタスクには.completedクラスを追加し、CSSで取り消し線を表示します。
表示ロジック
- 未完了タスク（completed: false）を先に表示
- 完了済みタスク（completed: true）を後に表示
- 各グループ内では追加順に表示
***
このUI構造で問題ありませんか？ユーザー回答: OK
以降、セクション4〜7（スタイリング方針、JavaScript実装、エラーハンドリング、レスポンシブ対応）についても同様に質疑応答を経て、全体デザインが固まります。
最終的に、Claude Codeが product.md、tech.md、structure.md を作成し、Webダッシュボード（http://localhost:5050/）で承認リクエストが表示されます。
6.2.3. ステップ1.3: Steering文書レビュー
ユーザーが入力:
/md-think
/review .spec-workflow/steering/Product.md同様に他もレビュー:
/review .spec-workflow/steering/Tech.md
/review .spec-workflow/steering/Structure.md修正が必要な場合は、具体的に指示します:
修正依頼
- エラーハンドリング: JSON.parse 時の例外処理を必須化する。
- イベントハンドリング: onclick 属性ではなく、addEventListener を使用するコード規約。
- オフライン対応: Simple Todo であるため、Service Worker を導入して完全な PWA（Progressive Web App）化を検討すると、ユーザー体験が劇的に向上します。
- CSS設計: クラス名の衝突を避けるため、BEM またはシンプルなプレフィックス（todo- など）の使用を推奨。Claude Codeが修正を反映し、新しい承認リクエストを作成します。
6.2.4. ステップ1.4: Web UIで承認
ブラウザで http://localhost:5050/ を開き、内容を確認して「承認」ボタンをクリックします。
6.3. フェーズ2: 詳細要件定義 (Requirements)
6.3.1. ステップ2.1: 要件定義書作成
ユーザーが入力:
/phase2Claude Codeが .spec-workflow/steering/ の承認された仕様に基づき、以下のドキュメントを作成します:
Requirements.md: 詳細要件定義Design.md: 設計書Tasks.md: 実装タスク一覧
6.3.2. ステップ2.2: レビューと承認
ドキュメントの作成が完了すると承認待ちになるため、その都度レビューをして修正を依頼します。
ユーザーが入力:
/review .spec-workflow/specs/todo-app/requirements.md
/review .spec-workflow/specs/todo-app/design.md
/review .spec-workflow/specs/todo-app/tasks.mdhttp://localhost:5050/ で確認し、「承認」ボタンをクリックします。
6.4. フェーズ3: 実装 (Implementation)
以降の操作は右ペインのclaude-code-router側で実施します。
6.4.1. ステップ3.1: 全体計画作成
ユーザーが入力:
/md-think
/phase3-planClaude Codeが実行:
Tasks.mdに基づき、全タスク（Task 1〜8）の詳細な実装計画を作成しました。
━━━ Task 1: 環境構築とLint設定 ━━━
1. 実装内容:
- npm init -y による初期化。
- @biomejs/biome, clang-format, glob のインストール。
- biome.json の初期化。
- .gitignore の作成（node_modules, .DS_Store, logs, approvals等）。
- scripts/ 配下に lint-all.js など計6つのLintスクリプトを CLAUDE.md の通りに作成。
- package.json に各言語向けの lint スクリプトを定義。
- setup-commands.sh を作成・実行し、.claude/skills/ 配下にプロジェクト固有スキル（/phase2, /phase3-plan 等）を生成。
2. 編集ファイル: package.json, biome.json, .gitignore, scripts/*.js, setup-commands.sh
3. Lint実行タイミング: 構成完了直後に npm run lint
4. 完了条件: npm run lint が正常終了し、.claude/skills/ 内に指示通りのスキルファイルが生成されていること。
━━━ Task 2: HTMLファイルの作成 ━━━
1. 実装内容:
- design.md に基づくセマンティックなHTML5構造の構築。
- .todo-container, .todo-input-section などのクラス付与。
- styles.css と app.js の読み込み設定。
2. 編集ファイル: index.html
3. Lint実行タイミング: ファイル作成後に npm run lint:js
4. 完了条件: ブラウザで開いた際に基本構造がエラーなく表示されること。
━━━ Task 3: CSSファイルの作成 ━━━
1. 実装内容:
- CSS変数（:root）によるカラーパレット定義。
- モバイルファーストのレスポンシブデザイン（480px以下で縦並び）。
- 完了状態（打消し線）やホバーエフェクトのスタイリング。
2. 編集ファイル: styles.css
3. Lint実行タイミング: スタイル記述完了後に npm run lint
4. 完了条件: 各デバイスサイズで意図したデザイン通りに表示されること。
━━━ Task 4: JSファイルの作成（基礎構造とModel層） ━━━
1. 実装内容:
- IIFE によるカプセル化と 'use strict' 宣言。
- localStorage を用いた永続化（loadTasks, saveTasks）。
- データ操作ロジック（addTask, toggleTask, deleteTask）の実装。
2. 編集ファイル: app.js
3. Lint実行タイミング: 関数実装後に npm run lint:js
4. 完了条件: LocalStorage との同期が try-catch 付きで正しく実装されていること。
━━━ Task 5: JSファイルの作成（View層） ━━━
1. 実装内容:
- renderTasks() の実装（未完了タスク優先のソートロジック含む）。
- textContent を使用した XSS 対策。
- 入力欄のクリア（clearInput()）。
2. 編集ファイル: app.js
3. Lint実行タイミング: レンダリングロジック追加後に npm run lint:js
4. 完了条件: タスク配列の状態が正しく DOM に反映・ソートされること。
━━━ Task 6: JSファイルの作成（Controller層と初期化） ━━━
1. 実装内容:
- イベントハンドラー（handleAddTask, handleKeyPress）の実装。
- イベント委譲を用いたリスト内（チェック、削除）のイベント管理。
- init() 関数によるアプリ起動処理の追加。
2. 編集ファイル: app.js
3. Lint実行タイミング: 全機能実装後に npm run lint
4. 完了条件: タスクの追加（Enter対応）・完了・削除がすべて正常に動作すること。
━━━ Task 7: 統合テストと動作確認 ━━━
1. 実装内容:
- 初回訪問、リロード、データ破損、レスポンシブ、XSS攻撃試行等のシナリオテスト。
- Requirements.md の受入基準に対する自己検証。
2. 編集ファイル: なし（必要に応じてバグ修正）
3. Lint実行タイミング: 最終確認として npm run lint
4. 完了条件: 全テストシナリオをパスし、Biomeエラーやコンソールエラーがないこと。
━━━ Task 8: PWA化（オプション） ━━━
1. 実装内容:
- manifest.json の作成と index.html へのリンク追加。
- sw.js による静的ファイルのキャッシュ（キャッシュファースト戦略）。
- app.js 内での Service Worker 登録。
2. 編集ファイル: manifest.json, sw.js, index.html, app.js
3. Lint実行タイミング: PWA機能追加後に npm run lint
4. 完了条件: オフライン環境でもアプリケーションが起動・表示されること。6.4.2. ステップ3.2: 環境構築実行（Task 1のみ）
ユーザーが入力:
/md-fast
/exec Task 1のみを実行してくださいClaude Codeが実行:
Task 1（環境構築・Lint設定・スキル生成）を完了しました。
実行内容:
1. npm初期化: package.json を作成
2. 基本パッケージ: @biomejs/biome, clang-format, glob をインストール
3. Biome設定: biome.json を初期化
4. 設定ファイル作成: .gitignore を適切に設定
5. Lintスクリプト作成: scripts/ 配下に6つのスクリプトを作成
6. package.json設定: npm run lint などのコマンドを定義
7. スキルセットアップ: setup-commands.sh を作成・実行し、.claude/skills/ 配下にフェーズ管理スキルを生成
これで基本的な開発環境が整いました。次は Task 2 以降の機能実装に進むことができます。6.4.3. ステップ3.3: 機能実装実行
ユーザーが入力:
/exec 残りの未完了タスクを全て実行してくださいClaude Codeが実行:
未実装の全タスク（Task 2, 3, 4, 5, 6, 7, 8）を実装・完了しました。
実装の概要
1. HTML構造: index.html をセマンティックなHTML5で作成し、todo- プレフィックスを使用した明確なクラス設計を実施しました。
2. CSSスタイリング: styles.css にCSS変数によるカラーパレット、モバイルファーストのレスポンシブデザイン、完了状態の視覚的フィードバックを実装しました。
3. JavaScript (Model/View/Controller): app.js を詳細な制約（'use strict'、innerHTML禁止等）に合わせてブラッシュアップし、LocalStorage連携、タスクのソート表示、完全なイベントハンドリングを実装しました。
4. 品質管理: npm run lint を実行し、Biome による静的解析の警告・エラーをすべて修正しました。
5. PWA化: manifest.json と sw.js (Service Worker) を作成し、オフライン対応とホーム画面への追加機能を実装しました。
完了したタスク
- Task 2: HTMLファイルの作成
- Task 3: CSSファイルの作成
- Task 4: JavaScript Model層の実装
- Task 5: JavaScript View層の実装
- Task 6: JavaScript Controller層と初期化の実装
- Task 7: 統合テストと動作確認
- Task 8: PWA化
すべてのタスクが完了し、npm run lint もパスしています。これで実装フェーズは終了です。
6.5. フェーズ4: 最終品質確認 (Final Review & QA)
6.5.1. ステップ4.1: コードレビュー
ユーザーが入力:
/md-think
/review アプリケーション本体のファイルをレビューしてClaude Codeが実行:
アプリケーション本体のファイル（index.html, styles.css, app.js）をレビューしました。
全体評価
UI/UXの基本が抑えられており、バニラJavaScriptによる堅実な実装です。PWA対応やXSS対策（textContentの使用）が含まれており、実用的なアプリとして完成度が高いです。
***
1. index.html (UI構造)
- 良い点:
- セマンティックHTML: header, input, button など適切なタグを使用しています。
- PWA対応: manifest.json と theme-color が正しく設定されています。
- クラス設計: todo- プレフィックスを一貫して使用しており、CSSのスコープが明確です。
- 改善提案:
- アクセシビリティ: input タグに id はありますが、対応する label 要素がないか、あるいは aria-label が欠けています。スクリーンリーダー利用者のために追加を検討してください。
2. styles.css (デザイン)
- 良い点:
- 変数活用: :root によるカラーパレット管理はメンテナンス性が高いです。
- レスポンシブ: モバイルデバイス（480px以下）で入力欄が縦並びになるようメディアクエリが設定されています。
- 視覚的フィードバック: 完了済みタスクの打ち消し線や、削除ボタンのホバー時の色変化（赤）など、状態が直感的に伝わります。
- 改善提案:
- 不一致の微修正: :root の --primary-color (#4a90e2) と index.html の theme-color (#2563eb) がわずかに異なります。ブランドカラーとして統一するとよりプロフェッショナルです。
3. app.js (ロジック)
- 良い点:
- カプセル化: IIFE (即時実行関数) で囲むことで、グローバル変数の汚染を防いでいます。
- セキュリティ: innerHTML を避け、document.createElement と textContent を使用して DOM を構築しており、XSS (クロスサイトスクリプティング) 対策が万全です。
- ユーザー体験: タスクのソート機能（未完了を上に表示）により、優先順位が分かりやすくなっています。
- 効率: taskList へのイベント委譲（Event Delegation）により、多数のタスクがあってもリスナーが1つで済む設計になっています。
- 改善提案:
- use strict の欠如: 最新版の修正で追加された可能性がありますが、もし入っていなければ IIFE の直後に "use strict"; を入れることで、より安全な実行環境になります。
総評
シンプルながらも「ベストプラクティスを遵守した」非常にクリーンなコードです。小規模なToDoアプリとして必要な機能が全て揃っており、保守性も良好です。6.5.2. ステップ4.2: 修正対応（必要な場合）
ユーザーが入力:
レビュー結果にある改善項目を対応して。Claude Codeが実行:
レビューで指摘された改善項目を反映しました。
- アクセシビリティ向上: index.html の入力欄に aria-label を追加し、スクリーンリーダー対応を強化しました。
- デザインの統一: styles.css の --primary-color を #2563eb に変更し、アプリ全体のテーマカラーを統一しました。
- コードの安全性向上: app.js の IIFE 内に "use strict"; を明示的に追加しました。
すべての改善項目が対応完了しました。6.5.3. ステップ4.3: 完了宣言
開発完了です。生成されたToDoアプリは以下の特徴を持ちます:
- シンプルで保守性の高いモジュラー構成
- XSS対策、エラーハンドリングを含む堅牢な実装
- PWA対応によるオフライン利用可能
- アクセシビリティに配慮したUI
- Biomeによる静的解析済み
7. メリット
7.1. コスト最適化
Claude Code Routerにより、タスクの性質に応じて最適なモデルを選択できます。例えば、Gemini 3 Flashは無料枠が大きく、コストを抑えながら高速な開発が可能です。
7.2. モデルの柔軟性
OpenRouter、Ollama、Gemini、DeepSeekなど、複数のプロバイダーとモデルを組み合わせることで、各フェーズに最適な推論能力を活用できます。
7.3. 仕様駆動開発の実現
spec-workflow-mcpのリアルタイムダッシュボードにより、仕様の承認フローが可視化され、AIと人間のコラボレーションが円滑になります。
7.4. ベストプラクティスの組み込み
superpowersプラグインにより、TDD、体系的デバッグ、完了前検証などの実証済みテクニックが自動的に適用されます。
7.5. tmuxによる並行作業
デュアルペイン構成により、仕様策定と実装を並行して進められ、開発速度が向上します。tmuxはセッション永続化により、ウィンドウを閉じても作業が継続します。
8. 課題と注意点
8.1. 学習曲線
複数のツール（Claude Code Router、MCP、spec-workflow-mcp、superpowers、tmux）の組み合わせには一定の学習コストが必要です。
8.2. プロジェクト固有設定
spec-workflow-mcpはプロジェクトごとに設定が必要で、スクリプト（setup-commands.sh）の実行も必須です。
8.3. セッション管理
tmuxセッションは永続化されるため、完全に停止する場合は明示的にtmux kill-serverを実行する必要があります。
8.4. ポート競合
macOSではデフォルトポート（5000）が使用されているため、ダッシュボードのポート変更（5050）が必要です。
9. まとめ
Claude Code Routerを中心としたこの開発環境は、AI駆動開発における3つの重要な要素を統合しています。
プロトコル標準化: MCPによる外部ツール統合の標準化
仕様駆動ワークフロー: spec-workflow-mcpによる構造化された開発プロセス
ベストプラクティスの自動適用: superpowersによる実証済みテクニックの組み込み
この環境により、IoT開発者は仕様策定から実装、品質確認まで一貫したワークフローで、AIエージェントとの効果的なコラボレーションが可能になります。特に、コンテキストベースルーティングにより、各開発フェーズに最適なモデルを活用できる点が、実用性と経済性の両立を実現しています。
今後、MCPエコシステムの拡大とともに、さらに多くの専門的なMCPサーバーやスキルが登場することで、AI駆動開発の可能性はさらに広がることが期待されます。