📋

spec-workflow-mcpとは？Claude CodeでKiroのような仕様駆動開発を実現

2025/09/10に公開

Model Context Protocol

はじめに

AI駆動開発において「仕様駆動開発（Spec-Driven Development）」が注目を集めていますよね。

そんな仕様駆動開発のアプローチの一つとして、 spec-workflow-mcp が登場しました。
このツールはKiroのような体系的な開発フローをMCP（Model Context Protocol）サーバーで実現してくれます。

本記事では、このMCPサーバーの導入方法と、実際にどのように仕様駆動開発を進めるかを詳しく解説します。

KiroとSpec-workflow-mcpの違い

基本的な違い

Kiro（Amazon）

IDEアプリ（VS Codeベース）
月額 $0〜（無料枠は招待待ち。また無料枠は月50回までのvibe requests）
AIモデルは Claude Sonnet 4.0、3.7

https://kiro.dev/pricing/

🔗 2025/8/15に有料プランを公開

spec-workflow-mcp

MCPサーバーで動作 (Claude Code以外にも対応)
オープンソースで無料で使用可能 (GPL-3.0)
AIモデルは使用するAIクライアント（Claude、Cursor等）のものを使用
Web UIまたはVSCode拡張機能を通じて、プロジェクトの進捗を視覚的に確認可能

spec-workflow-mcp は、Model Context Protocol（MCP）サーバーとして動作し、Claude Codeをはじめとする様々なAIツールと統合することで、仕様駆動型の開発プロセスをサポートしてくれます。

前身プロジェクト

spec-workflow-mcpは、claude-code-spec-workflowの進化版で、より洗練された形でMCPサーバーとして実装されています。

Claude Codeの課題も解決

仕様駆動開発はClaude Code特有の課題も解決してくれます。

Claude Codeで長時間開発している時、会話のコンテキスト長が上限に達すると「auto-compaction」が走り、教えた仕様やルール、過去の決定事項が圧縮され、生成精度が著しく低下するという経験はありませんか？

CLAUDE.mdファイルに記録しない限り、会話内で決めた仕様は要約・圧縮されてしまい、詳細な内容を後から正確に参照することが困難になります。

Kiroやspec-workflow-mcpのような仕様駆動開発ツールは、仕様書やタスクをファイルとして永続化することで、この課題を根本的に解決し、いつでも続きから作業を再開できるようになります。

spec-workflow-mcpの主な機能

1. 構造化された3段階の開発フロー

Requirements（要件定義） → Design（設計） → Tasks（タスク実装）

この流れに沿って開発を進めることで、仕様と実装の一貫性を保ちます。

2. リアルタイムダッシュボード

Web UIまたはVSCode拡張機能を通じて、プロジェクトの進捗を視覚的に確認できます。
タスクの完了状況、承認待ちのドキュメント、全体の進捗率などが一目でわかります。

3. 承認ワークフロー

各フェーズ（要件、設計、タスク）ごとに承認プロセスを設けることで、品質を担保しながら開発を進められます。

4. AI との永続的な連携

.spec-workflowディレクトリに保存された仕様書やタスクは、AIが常に参照できるため、一貫性のある開発を継続できます。

5. マルチプラットフォーム対応

AI Tools: Claude Code CLI、Claude Desktop、Cursor、OpenCode、Cline、Continue
OS: Windows、macOS、Linux
言語: 日本語含む11カ国語に対応

プロジェクト構造

spec-workflow-mcpは、プロジェクトに以下のディレクトリ構造を自動生成します。

your-project-folder/
  .spec-workflow/
    steering/             # プロジェクト全体の方針
      product.md          # 製品ビジョン
      tech.md             # 技術的な決定事項
      structure.md        # プロジェクト構造
    specs/                # 各機能の仕様書
      {機能名}/
        requirements.md   # 要件定義
        design.md         # 設計書
        tasks.md          # タスクリスト
    approval/             # 承認管理
      {機能名}/
        {document-id}.json # 承認状態の追跡

1. Claude Code用のspec-workflow-mcp導入手順

Claude Code CLI設定

🔗 MCP Client Setup

# MCPをClaude Codeに追加するコマンド
claude mcp add spec-workflow npx @pimzino/spec-workflow-mcp@latest -- /path/to/your/project

claude実行時に、自動起動にしたい場合は --AutoStartDashboard のオプションを追加します。

claude mcp remove spec-workflow # インストール済なら削除

claude mcp add spec-workflow npx @pimzino/spec-workflow-mcp@latest -- /path/to/your/project --AutoStartDashboard

注意事項

-- セパレータがないとパスがnpxに渡ってしまいます。
/path/to/your/project は実際のプロジェクトのパスに置き換えてください。
一度 claude mcp add を実行している場合、再度 claude mcp add を実行するには、claude mcp remove spec-workflow の手順が必要です。

実行したら以下のメッセージが表示されます

Added stdio MCP server spec-workflow with command: npx @pimzino/spec-workflow-mcp@latest /path/to/your/project to local config
File modified: /Users/your-name/.claude.json [project: /path/to/your/project]

--AutoStartDashboard オプションありの時

Added stdio MCP server spec-workflow with command: npx @pimzino/spec-workflow-mcp@latest /path/to/your/project --AutoStartDashboard to local config
File modified: /Users/your-name/.claude.json [project: /path/to/your/project]

Windows (上記が機能しない場合):

claude mcp add spec-workflow cmd.exe /c "npx @pimzino/spec-workflow-mcp@latest /path/to/your/project"

Mac + Next.jsでの具体的な手順例

Claude CodeにMCPを追加

# 例えば、Next.jsプロジェクトが ~/Documents/my-nextjs-app にある場合〜
claude mcp add spec-workflow npx @pimzino/spec-workflow-mcp@latest -- ~/Documents/my-nextjs-app --AutoStartDashboard

これで初期設定は完了です！

2. spec-workflow-mcpの使い方

はじめに

spec-workflow-mcpは「仕様駆動開発」をサポートするツールで、以下の順番で開発を進めます

Requirements（要件） - 何を作るか
Design（設計） - どう作るか
Tasks（タスク） - 実装の細かい手順

📁 プロジェクトの構造について
プロジェクトに.spec-workflowフォルダが自動で作られます。

your-project-folder/
  .spec-workflow/           # ← これが自動生成されます
    steering/              # プロジェクト全体の方針
      product.md          # 製品ビジョン
      tech.md            # 技術的な決定事項
      structure.md       # プロジェクト構造
    specs/                # 各機能の仕様書
      {機能名}/
        requirements.md   # 要件定義
        design.md        # 設計書
        tasks.md         # タスクリスト

実際の使い方

注意ポイント

--AutoStartDashboard のオプション使用してインストールしている場合は claude を実行すると自動で spec-workflow-mcp のダッシュボードが起動します。
--AutoStartDashboard を使用していない場合は以下の手順のように claude-code と dashboard の両方を起動する必要があります。

# ターミナル1
claude

# ターミナル2
npx -y @pimzino/spec-workflow-mcp@latest /path/to/your/project --dashboard

補足

ダッシュボードだけ起動した場合の動作

# これだけ実行中
npx -y @pimzino/spec-workflow-mcp@latest /path --dashboard

# Claude Codeは未実行

✅ できること（閲覧・確認系）

既存の仕様書を見ることができる
タスクの進捗状況を確認できる
ドキュメントを読むことができる
承認リクエストの確認はできる

❌ できないこと（作成・更新系）

新しい仕様書の作成ができない
タスクの実行・更新ができない
AIとの連携作業ができない
リアルタイム更新が反映されない

💡 なぜかというと

Claude Code（MCPサーバー） ← 頭脳部分（AI処理）❌ 動いてない
　　　　↕️
ダッシュボード ← 表示部分（UI）✅ 動いてる

ダッシュボードだけ起動した状態では、新しいことはできませんが、既存のファイルは見れる状態なため、両方起動する必要があります。

方法1: 別々に起動

# ターミナル1
claude  # MCPサーバー起動

# ターミナル2
npx -y @pimzino/spec-workflow-mcp@latest /path --dashboard

方法2: 自動起動設定

# 最初から--AutoStartDashboard付きで設定
claude mcp add spec-workflow npx @pimzino/spec-workflow-mcp@latest -- /path --AutoStartDashboard

claude  # これだけで両方起動！

📝 まとめ
ダッシュボードだけだと「読み取り専用モード」みたいな感じです。
実際に開発するにはClaude Codeも一緒に起動する必要があります！

3. ダッシュボードの4つの主要機能

Spec-Workflow-MCPのダッシュボードが起動されると .spec-workflow/ が生成されます。

3-1. Steering（ステアリング）

3つのドキュメント

product.md - 製品ビジョンとゴール
tech.md - 技術的な決定事項
structure.md - プロジェクト構造のガイド

役割
プロジェクト全体の方向性を決める基盤文書です。
すべての開発はこれに沿って進められます。

3-2. Specs（仕様書）

各仕様書の構成

specs/
  {機能名}/
    requirements.md  # What - 何を作るか
    design.md       # How - どう作るか
    tasks.md        # Steps - 実装手順

ダッシュボードでの表示

Spec Cards - 各仕様書のカード表示
Status Indicators - 進捗状況の視覚的表示
Document Navigation - 要件/設計/タスク間の切り替え

3-3. Tasks（タスク）

機能

Visual Progress Bars - 進捗バーで視覚化
Task Status - 各タスクの完了状況
Copy Prompt Button - 実装プロンプトのコピー機能

3-4. Approval（承認）

README.mdによると

create documents, request approval through the dashboard, provide feedback, and track revisions

承認プロセス

Request Approval - 承認リクエスト
Review - レビュー
Approve/Reject - 承認or却下
Feedback - フィードバック記入
Revisions - 修正の追跡

4. 機能実装の手順

プロジェクトの基盤作成から、GitHub Actionsの品質チェック機能の実装まで、一連の流れを紹介します。

補足: 以降に出てくる「ダッシュボード」はspec-workflow-mcpのダッシュボードのことです。

4-1: プロジェクト基盤作成（初回のみ）

# Claude Codeで
「spec-workflowのsteering-guideを使って、
このプロジェクトのステアリングドキュメントを作成して」

応答

⏺ spec-workflowのsteering-guideを使用して、このプロジェクトのステアリングドキュメントを作成します。

╭───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╮
│ Tool use                                                                                                              │
│                                                                                                                       │
│   spec-workflow - steering-guide() (MCP)                                                                              │
│   tools.steeringGuide.description                                                                                     │
│                                                                                                                       │
│ Do you want to proceed?                                                                                               │
│ ❯ 1. Yes                                                                                                              │
│   2. Yes, and don't ask again for spec-workflow - steering-guide commands in                                          │
│   /Documents/my-nextjs-app                                             │
│   3. No, and tell Claude what to do differently (esc)                                                                 │
│                                                                                                                       │
╰───────────────────────────────────────────────────────────────────────────────────────────────────────────────────────╯

> Yes

⏺ プロジェクトの分析を開始し、Phase 1のProduct Documentから作成を開始します。
> Yes

⏺ プロジェクトのCLAUDE.mdとREADME.mdを確認して、Product Documentを作成します。
⏺ 続けてプロジェクトの分析を行い、Product Documentを作成します。
> Yes

⏺ Product Documentの作成が完了しました。次にPhase 2のTech Documentを作成します。
> Yes

⏺ Tech Documentを作成します。
> Yes

⏺ Tech Documentの作成が完了しました。最後にPhase 3のStructure Documentを作成します。
> Yes

⏺ Structure Documentを作成します。
> Yes

⏺ すべてのステアリングドキュメントの作成が完了しました！

  作成されたステアリングドキュメント

  以下の3つのステアリングドキュメントが.spec-workflow/steering/ディレクトリに作成されました：

  1. product.md - プロダクトビジョン

  - 〇〇の製品目的とビジネス目標
  - ターゲットユーザー
  - 主要機能
  - 成功指標とKPI
  - 将来のビジョン（AI/ML統合、グローバル展開等）

  2. tech.md - 技術スタック

  - Next.js 15.3.4 + React 19.1.0 + TypeScript 5.8.3
  - Material-UI 7.1.2によるエンタープライズUIコンポーネント
  - Redux Toolkit + TanStack Queryによる状態管理
  - マルチ認証システム（JWT、Firebase、Auth0等対応）
  - パフォーマンス要件とセキュリティ基準

  3. structure.md - プロジェクト構造

  - ディレクトリ構成とファイル命名規則
  - コード組織化の原則（Single Responsibility、Modularity等）
  - インポートパターンとモジュール境界
  - コードサイズガイドライン
  - CSS Modules配置ルール

  これらのドキュメントは、今後のspec作成や開発作業の基準となるガイドラインとして機能します。

これで以下が作られます

.spec-workflow/steering/product.md
.spec-workflow/steering/tech.md
.spec-workflow/steering/structure.md

ステアリングの画面

4-2: 機能仕様書の作成

例：.github/workflowsの機能を実装する場合

「spec-workflowで'github-quality-check-workflow'という仕様書を作成して。
.github/workflowsで実行される、プッシュ時に自動実行される基本チェック機能を含めて」

自動的に作られる流れ

仕様書 requirements.md が作成されます。.spec-workflow/specs/github-quality-check-workflow/requirements.md
承認のjsonが作成されます。　.spec-workflow/approvals/github-quality-check-workflow/approval_1757388565504_6hqzq6gf2.json
tasks.md が作成されます。

応答

⏺　spec-workflowを使用して、GitHub Actionsの品質チェックワークフローの仕様書を作成します。
> Yes

⏺ GitHub Actionsでの品質チェックワークフローについて調査し、Requirements Documentを作成します。
> Yes

⏺ Requirements Documentの作成が完了しました。承認プロセスに進みます。
> yes

⏺ Requirements Documentを作成し、承認リクエストを送信しました。承認状態を確認します。
│ Do you want to proceed?
> Yes

⏺ 📋 GitHub Actions品質チェックワークフロー仕様書作成中

  Requirements Document（要件定義書）を作成しました。現在承認待ちです。

  作成済みドキュメント

  Requirements Document (.spec-workflow/specs/github-quality-check-workflow/requirements.md)

  主な要件：
  1. 自動実行トリガー - プッシュ時・PR作成時の自動実行
  2. TypeScript型チェック - tscによる厳格な型検証
  3. ESLint静的解析 - コード品質とバグの早期発見
  4. Prettierフォーマット - コードスタイルの統一
  5. Node.js環境 - Node.js 20、Yarn 1.22.22の使用
  6. ビルドチェック - Next.jsビルドの成功確認
  7. 結果レポート - 明確なエラー表示とステータス報告

  承認が必要です

  Requirements Documentの承認をお願いします：
  - 承認ID: approval_1757388565504_6hqzq6gf2
  - ファイル: .spec-workflow/specs/github-quality-check-workflow/requirements.md

  VSCode拡張機能またはダッシュボードから承認してください。承認後、Design Document（設計書）の作成に進みます。

requirements.md が作成されます。

仕様書のページ

4-3: ダッシュボードで承認

ダッシュボードを開く

http://localhost:49824（ポート番号は起動時に表示）

仕様書のページへ移動し Github Quality Check Workflow をクリック
ドキュメントをレビューし、修正が必要であれば変更します。
承認のページへ移動し、承認をします。 jsonファイルのstatusが approved に変わります。
claude Codeで以下を実行します。

注意: 承認ページで、「即時承認」をクリックするだけでは、タスクは作成されませんでした。「承認したので、spec-workflow でタスクを作成して」を実行することで作成されました。

応答

承認したので、spec-workflow でタスクを作成して

⏺ 承認されたとのことですので、承認状態を確認してからDesign Documentの作成に進みます。
> Yes

⏺ Requirements Documentが承認されました。次にDesign Documentを作成します。
> Yes

⏺ 既存のGitHub Actions設定を確認します。

⏺ Design Documentを作成します。
> Yes

⏺ Design Documentを作成しました。承認リクエストを送信します。
> Yes

⏺ Design Documentを作成し、承認リクエストを送信しました。承認状態を確認します。
> Yes

⏺ 📋 GitHub Actions品質チェックワークフロー仕様書作成中

  Requirements Documentは承認済みです。Design Document（設計書）を作成しました。現在承認待ちです。

  作成済みドキュメント

  1. ✅ Requirements Document - 承認済み
  2. Design Document (.spec-workflow/specs/github-quality-check-workflow/design.md)

  Design Documentの概要

  アーキテクチャ設計：
  - GitHub Actionsのイベントドリブンアーキテクチャを活用
  - 並列処理による効率的な品質チェック
  - キャッシュ機能による高速化

  主要コンポーネント：
  1. Workflow Trigger - プッシュ/PR時の自動起動
  2. Environment Setup - Node.js 20とYarn環境構築
  3. Quality Checks - TypeScript/ESLint/Prettier/ビルドチェック
  4. Result Reporter - 結果レポートとGitHubステータス更新

  エラーハンドリング：
  - 各種エラーシナリオに対する適切な処理
  - 明確なエラーメッセージとファイル注釈
  - 自動リトライとタイムアウト設定

  承認が必要です

  Design Documentの承認をお願いします：
  - 承認ID: approval_1757389825428_shlmvkt97
  - ファイル: .spec-workflow/specs/github-quality-check-workflow/design.md

  ダッシュボードまたはVSCode拡張機能から承認してください。承認後、Tasks
  Document（タスク一覧）を作成し、実装可能なタスクを生成します。

「承認しました」と入力

⏺ 承認ありがとうございます。承認状態を確認してクリーンアップを行い、Tasks Documentの作成に進みます。
> Yes

⏺ Design Documentが承認されました。Tasks Documentの作成に進みます。
> Yes

⏺ Tasks Documentを作成します。
> YEes

⏺ Tasks Documentを作成しました。承認リクエストを送信します。
> Yes

⏺ 📋 GitHub Actions品質チェックワークフロー仕様書完成！

  すべてのドキュメントを作成しました。最後のTasks Document（タスク一覧）の承認をお願いします。

  作成済みドキュメント

  1. ✅ Requirements Document - 承認済み
  2. ✅ Design Document - 承認済み
  3. Tasks Document (.spec-workflow/specs/github-quality-check-workflow/tasks.md)

  Tasks Documentの概要

  14個の実装タスクを定義しました：

  1. 環境構築 (Tasks 1-5)
    - GitHub Actionsディレクトリ作成
    - ワークフローファイル作成
    - Node.js環境セットアップ
    - 依存関係キャッシング
  2. 品質チェック実装 (Tasks 6-9)
    - TypeScript型チェック
    - ESLint静的解析
    - Prettierフォーマットチェック
    - Next.jsビルドチェック
  3. レポートと文書化 (Tasks 10-14)
    - ステータスレポート
    - ワークフロー文書作成
    - ローカルテストスクリプト
    - ブランチ保護設定ガイド

  各タスクには詳細な実装ガイダンス（_Prompt）が含まれています。

  承認が必要です

  Tasks Documentの承認をお願いします：
  - 承認ID: approval_1757390298921_tlzu1dbwj
  - ファイル: .spec-workflow/specs/github-quality-check-workflow/tasks.md

  承認後、spec-workflowのタスク管理システムでタスクが利用可能になります。

Point
📌 承認とタスク利用の関係

ワークフローの流れ

Requirements Document (.spec-workflow/specs/(機能名)/requirements.md) → 承認 ✅
Design Document (.spec-workflow/specs/(機能名)/design.md) → 承認 ✅
Tasks Document (.spec-workflow/specs/(機能名)/tasks.md) → 承認待ち ← 今ここ
承認後 → タスクがspec-workflowシステムに登録される
登録後 → manage-tasksコマンドでタスク管理が可能に

4-4: タスクの実行

手順

[CLI] 開始時: 「タスクX開始」と言う
[ダッシュボード] Tasks タブを開く
[ダッシュボード] 実装したいタスクの「プロンプトをコピー」ボタンをクリック
[CLI] 実装時: プロンプトボタンのテキストを貼り付ける
[CLI] 完了時: 「タスクX完了」と言う
[CLI] 確認時: 「進捗確認」と言う

実際の例（タスク3の場合）

私: "タスク3を開始"
ClaudeCode: manage-tasksでin-progressに設定

私: [プロンプトボタンのテキストを貼り付け]
ClaudeCode: コードを実装

私: "タスク3完了"
ClaudeCode: manage-tasksでcompletedに設定

私: "進捗確認"
ClaudeCode: spec-statusで進捗表示

プロンプトのコピー方法

生成されたプロンプト

Role: DevOps Engineer with expertise in GitHub Actions and CI/CD | Task: Create .github/workflows directory structure following requirement 1.1 and 5.1, ensuring proper permissions for GitHub Actions execution | Restrictions: Do not create workflow files yet, only directory structure, follow GitHub's directory naming conventions | Success: Directory .github/workflows/ exists with correct permissions, ready for workflow files

tasks.mdについてのメモ

手動で「保留中」のステータスを変更すると tasks.md の該当タスクの [] が更新されました。

保留中: [ ]
進行中: [-]
進行中: [x]

応答

> タスク1を開始

> Role: DevOps Engineer with expertise in GitHub Actions and CI/CD | Task: Create .github/workflows directory structure following requirement 1.1 and 5.1, ensuring proper permissions for GitHub Actions execution | Restrictions: Do not create workflow files yet, only directory structure, follow GitHub's directory naming conventions | Success: Directory .github/workflows/ exists with correct permissions, ready for workflow files

⏺ GitHub Actionsのワークフローディレクトリ構造を作成します。
> Yes

⏺ ✅ GitHub Actionsワークフローディレクトリ構造を作成完了

  以下のディレクトリ構造を作成しました：

  .github/
  └── workflows/
      └── .gitkeep

  作成内容

  - .github/workflows/: GitHub Actionsのワークフローファイルを配置するディレクトリ
  - .gitkeep: 空のディレクトリをGitで追跡するためのファイル

  権限確認

  - ディレクトリ権限: drwxr-xr-x (755) - 適切な読み取り/実行権限
  - GitHub Actionsが正常に実行できる権限設定

  次のステップ

  このディレクトリ構造の準備が完了しました。次はワークフローファイル（quality-check.yml）を作成できます。


> タスク1完了

実装が完了すると、タスクのステータスが「完了」となります。

以降は残りのタスクのプロンプトを順次実行していきます。

> タスク2を開始

> Role: CI/CD Engineer specializing in GitHub Actions | Task: Create quality-check.yml workflow file with push/PR triggers for main, development, feature/*, fix/*, chore/* branches following requirements 1.1, 1.2, and 5.1 | Restrictions: Use Ubuntu latest runner, set Node.js 20 and Yarn 1.22.22 as environment defaults, include proper workflow concurrency settings | Success: Workflow file has correct YAML syntax, triggers are properly configured, environment variables are set

⏺ ✅ GitHub Actions quality-check.yml ワークフローファイルを作成完了！

  作成内容

  ファイル: .github/workflows/quality-check.yml

  主な設定

  トリガー設定

  - Push時: main, development, feature/, fix/, chore/* ブランチ
  - PR時: main, developmentブランチへのPR（opened, synchronize, reopened）

  環境設定

  - Runner: Ubuntu latest
  - Node.js: バージョン20
  - Yarn: バージョン1.22.22

  並行実行制御

  - 同じPRまたはブランチで新しいプッシュがあった場合、実行中のワークフローをキャンセル
  - concurrencyグループによる効率的なリソース管理

  実装済みステップ

  1. コードチェックアウト - actions/checkout@v4
  2. Node.js環境構築 - actions/setup-node@v4
  3. 依存関係キャッシュ - actions/cache@v3でnode_modulesと.next/cacheをキャッシュ
  4. 依存関係インストール - yarn install --frozen-lockfile
  5. TypeScript型チェック - yarn tsc --noEmit
  6. ESLintチェック - yarn lint
  7. Prettierフォーマットチェック - yarn fm:check
  8. Next.jsビルドチェック - yarn build
  9. 結果レポート - 実行結果のサマリー表示

  セキュリティ設定

  - 最小限の権限設定（contents: read, checks: write, pull-requests: write）
  - 10分のタイムアウト設定

  YAML構文検証

  ✅ YAML構文チェック成功 - 正しい構文で記述されています

  次のステップ

  このワークフローは、コードをプッシュまたはPRを作成すると自動的に実行されます。タスク2が完了しました！

> タスク2完了

4-5: 進捗確認

# Claude Codeで
「進捗確認」

# または

「github-quality-check-workflowの進捗状況を教えて」

応答

⏺ 全体の進捗を確認します。

⏺ spec-workflow - spec-status (MCP)(projectPath:
                                   "/Documents/my-nextjs-app", specName:
                                   "github-quality-check-workflow")
  ⎿  {
       "success": true,
       "message": "tools.specStatus.successMessage",
     … +49 lines (ctrl+r to expand)

⏺ 📊 GitHub Actions品質チェックワークフロー - 進捗状況

  全体進捗

  14.3%完了 (2/14タスク)

  [██░░░░░░░░░░░░░░░░░░] 2/14

  フェーズ別状況

  | フェーズ              | ステータス  | 詳細        |
  |-------------------|--------|-----------|
  | 📝 Requirements   | ✅ 作成済み | 要件定義完了    |
  | 🎨 Design         | ✅ 作成済み | 設計書完了     |
  | 📋 Tasks          | ✅ 作成済み | タスク一覧完了   |
  | 🔨 Implementation | 🔄 実装中 | 2/14タスク完了 |

  完了済みタスク

  1. ✅ タスク1: GitHub Actionsディレクトリ構造作成
  2. ✅ タスク2: quality-check.ymlワークフローファイル作成

  次の実装タスク

  タスク3: checkout と Node.js setup ステップの実装
  - quality-check.ymlファイルは作成済みですが、実際にはタスク2で全ステップを実装済みです
  - タスク3-9は個別ステップの実装ですが、既に完了している可能性があります

  推奨アクション

  1. タスク3-9は既にquality-check.yml内に実装済みの可能性が高いため、確認が必要
  2. タスク10以降（レポート、ドキュメント、ローカルスクリプト）から進めることを推奨

  実装を続けますか？

ダッシュボードで確認することもできます。

複数のタスクを自動で実行

以下のように指示することで、順番に実行してくれます。

> タスク4-9を順番に実行して

# または

> タスク4から順番に、実装が必要なら実装し、既に実装済みなら確認のみでcompletedに更新して

応答

> タスク4から順番に、実装が必要なら実装し、既に実装済みなら確認のみでcompletedに更新して

⏺ タスク4から順番に確認して更新していきます。
⏺ 📋 タスク4: 依存関係キャッシング設定

  確認

  quality-check.yml の行60-71を確認：
  - ✅ actions/cache@v3 実装済み
  - ✅ yarn.lockハッシュでキャッシュキー生成
  - ✅ node_modulesと.next/cacheをキャッシュ
  - ✅ restore-keys設定済み

⏺ ✅ タスク4完了 - 既に実装済み

  ---
  📋 タスク5: 依存関係インストール

  確認

  quality-check.yml の行73-78を確認：
  - ✅ yarn install --frozen-lockfile 実装済み
  - ✅ CI環境変数設定済み

⏺ ✅ タスク5完了 - 既に実装済み

  ---
  📋 タスク6: TypeScript型チェック

  確認

  quality-check.yml の行80-84を確認：
  - ✅ yarn tsc --noEmit 実装済み
  - ✅ エラー時にワークフロー失敗設定済み

⏺ ✅ タスク6完了 - 既に実装済み

  ---
  📋 タスク7: ESLintチェック

⏺ - ✅ yarn lint 実装済み（行91）
  - ✅ エラー時にワークフロー失敗設定済み

⏺ ✅ タスク7完了 - 既に実装済み

  ---
  📋 タスク8: Prettierフォーマットチェック

  確認

  - ✅ yarn fm:check 実装済み（行96）
  - ✅ エラー時にワークフロー失敗設定済み

⏺ ✅ タスク8完了 - 既に実装済み

  ---
  📋 タスク9: Next.jsビルドチェック

  確認

  - ✅ yarn build 実装済み（行103）
  - ✅ CI環境変数、NODE_ENV=production設定済み

⏺ ✅ タスク9完了 - 既に実装済み

  ---

⏺ 🎉 タスク4-9の一括更新完了！

  更新結果サマリー

  すべてのタスクが既にquality-check.yml内に実装済みでした：

  | タスク  | 内容                 | ステータス |
  |------|--------------------|-------|
  | タスク4 | 依存関係キャッシング         | ✅ 完了  |
  | タスク5 | 依存関係インストール         | ✅ 完了  |
  | タスク6 | TypeScript型チェック    | ✅ 完了  |
  | タスク7 | ESLintチェック         | ✅ 完了  |
  | タスク8 | Prettierフォーマットチェック | ✅ 完了  |
  | タスク9 | Next.jsビルドチェック     | ✅ 完了  |

  現在の進捗

  ⏺ 📊 全体進捗: 64.3%完了 (9/14タスク)

  [█████████░░░░░░░░░░] 9/14

  残りのタスク（5個）

  - タスク10: ジョブステータスレポート（quality-check.yml内に実装済み）
  - タスク11: ワークフロードキュメント作成
  - タスク12: ローカルテストスクリプト作成
  - タスク13: テストブランチでのワークフローテスト
  - タスク14: ブランチ保護ルールのドキュメント作成

  次のアクション

  タスク10も既に実装済みです（行106-123にレポート機能があります）。

  続けて残りのタスクを処理しますか？それとも特定のタスクから始めますか？

5. 便利コマンド

spec-workflowコマンド

自然言語でclaude codeに指示することで、自動でspec-workflowコマンドが実行されるように実装されていましたが、直接コマンドを実行することも可能です。

想定される使用パターン

通常のワークフロー

Claude Codeに指示 → Claude Codeがコマンド実行
例: 私「新しい仕様書を作って」 → Claude Codeがspec-workflow-guide実行

直接実行が有効な場合

全体進捗の確認: spec-list, spec-status
manage-tasks action:list → 残りタスクの詳細確認
spec-list → 他に作成した仕様書があるか確認

1. 情報確認系コマンド（頻繁に使用）

spec-list - 全仕様書の一覧確認

使用場面: 複数の仕様書を管理している時
例: "現在どんな仕様書があるか確認したい"

spec-status - 特定仕様書の詳細確認

使用場面: 進捗をダッシュボード以外で確認したい時
例: "github-quality-check-workflowの進捗を見たい"

manage-tasks action: list - タスク一覧確認

使用場面: ダッシュボードを開かずにタスク状況を確認
例: "現在のタスク一覧を見たい"

2. 新規作成系コマンド（プロジェクト開始時）

steering-guide - ステアリングドキュメント作成開始

使用場面: 新規プロジェクトや既存プロジェクトの方向性定義
例: "このプロジェクトのビジョンと技術標準を定義したい"

spec-workflow-guide - 新仕様書作成開始

使用場面: 新機能の仕様書作成を始める時
例: "ユーザー認証機能の仕様書を作りたい"

3. 手動操作系コマンド（特殊な状況）

manage-tasks (action: set-status) - タスクステータス手動更新

使用場面: 私が更新を忘れた時、複数タスクを一括更新したい時
例: "タスク10-14を全てpendingに戻したい"

delete-approval - 承認クリーンアップ

使用場面: 承認プロセスが何らかの理由でスタックした時
例: "承認が残ってしまっているのでクリーンアップしたい"

4. テンプレート確認系（カスタマイズ時）

get-template-context - テンプレート内容確認

使用場面: デフォルトテンプレートをカスタマイズしたい時
例: "requirements.mdのテンプレート構造を確認したい"

get-steering-context / get-spec-context - コンテキスト確認

使用場面: 既存のドキュメント内容を確認したい時
例: "現在のステアリングドキュメントの内容を見たい"

5. トラブルシューティング系

get-approval-status - 承認状態確認

使用場面: 承認がうまくいかない時の状態確認
例: "承認したはずなのに反映されていない"

refresh-tasks - タスクリフレッシュ

使用場面: タスクが正しく表示されない時
例: "ダッシュボードのタスクが更新されない"

6. その他の機能

Sound Notifications（音声通知）

| Sound Notifications - Configurable audio alerts for approvals and task completions

承認やタスク完了時に音で通知してくれる機能

VSCode拡張機能

VSCode内で直接spec-workflowを操作できる拡張機能も提供されています。
サイドバーからプロジェクトの状態確認や、右クリックメニューから機能へのアクセスが可能です。よりKiroでの開発体験に近づきますね！

まとめ

spec-workflow-mcpは、仕様駆動開発をMCPサーバーとして実現し、開発体験を大きく向上させてくれるツールです。

要件定義→設計→タスク実装という体系的な流れで、プロジェクトの意図や決定事項を永続化することで、数ヶ月後にプロジェクトを見返した際や、新しいメンバーがジョインした際に、なぜそう実装したのかが理解しやすくなります。

さらに、オープンソースで、使い慣れたAIツール（Claude、Cursor等）と連携しながら、ダッシュボードで進捗を可視化できる点も大きな魅力に感じました。

仕様駆動開発に興味がある方は、ぜひspec-workflow-mcpを試してみてください！

はじめに

KiroとSpec-workflow-mcpの違い

基本的な違い

Kiro（Amazon）

spec-workflow-mcp

前身プロジェクト

Claude Codeの課題も解決

spec-workflow-mcpの主な機能

1. 構造化された3段階の開発フロー

2. リアルタイムダッシュボード

3. 承認ワークフロー

4. AI との永続的な連携

5. マルチプラットフォーム対応

プロジェクト構造

1. Claude Code用のspec-workflow-mcp導入手順

Claude Code CLI設定

Mac + Next.jsでの具体的な手順例

2. spec-workflow-mcpの使い方

はじめに

実際の使い方

補足

ダッシュボードだけ起動した場合の動作

方法1: 別々に起動

方法2: 自動起動設定

3. ダッシュボードの4つの主要機能

3-1. Steering（ステアリング）

3-2. Specs（仕様書）

3-3. Tasks（タスク）

3-4. Approval（承認）

4. 機能実装の手順

4-1: プロジェクト基盤作成（初回のみ）

4-2: 機能仕様書の作成

4-3: ダッシュボードで承認

4-4: タスクの実行

4-5: 進捗確認

複数のタスクを自動で実行

5. 便利コマンド

spec-workflowコマンド

想定される使用パターン

1. 情報確認系コマンド（頻繁に使用）

2. 新規作成系コマンド（プロジェクト開始時）

3. 手動操作系コマンド（特殊な状況）

4. テンプレート確認系（カスタマイズ時）

5. トラブルシューティング系

6. その他の機能

Sound Notifications（音声通知）

VSCode拡張機能

まとめ

Discussion