spec-workflow-mcpを使ってみたら気に入ったので、紹介する

背景: LLM Agentと仕様書駆動開発

• LLM Agentが発展してきたものの、完全なバイブコーディングは厳しいことが分かってきた
  • 仕様を満たしていないものが出来上がったり、メンテナンスがしにくい作りになっていることもしばしば
• そこで、仕様書駆動開発(Spec-driven Development)の考え方をベースにしたKiroが登場した
  • 考え方は今後の時代に非常に合っていそう
• Kiroで仕様書駆動開発を試したが、体験はよかった
  • Claude CodeはAuto Compact後に色々情報を忘れてしまう問題があるが、仕様書駆動開発ではその情報を思い出させやすい
  • 仕様書駆動開発なしで「ちゃんとログを書いて」とClaude Codeに指示するのもありと言えばありだが、型に沿って勝手にやってくれるほうが気楽である
• しかし、Claude Codeなどを日常的に使っている自分としては固定のIDEに縛られたくない
  • やはりiTerm2の上でtmux生活が落ち着く...

Kiroの対抗馬

• IDE以外で仕様書駆動開発を提供しているツールはいくつかある
  • gotalab/claude-code-spec
    • 日本人の方が作られている、Claude Codeに限らず多様なLLM Agent向けにスラッシュコマンドを提供する
  • github/spec-kit
    • GitHub公式ということもあり、期待値は高い。ただ、登場からまだ2週間ということもあり、作りがちょっとまだ荒いところが目立つ
    • スラッシュコマンドやスクリプトの置き場所などのカスタマイズもまだできない
      • scriptsディレクトリなどをリポジトリ内に平然と置かないで欲しい...
  • Pimzino/claude-code-spec-workflow
    • claude-code-spec-workflowで始める仕様書駆動開発 - 弁護士ドットコム株式会社 Creators’ blog経由で知った
• どれもスラッシュコマンドをベースにしており使いやすそうではあるが、カスタマイズ性やClaude Code以外でも使えるポータビリティなどのことはアレコレ考えた

spec-workflow-mcpでの仕様書駆動開発の体験がよかった

claude-code-spec-workflowを紹介していた記事の中で、最近はmcpとして切り出したspec-workflow-mcpというのがあるのを知った。

色々試してみてよかったので、気に入ったポイントを書いてみる。

導入が簡単

• claude mcp add spec-workflow npx @pimzino/spec-workflow-mcp@latest /path/to/your/projectでよい
• MCPなので、Claude Code以外でも導入が簡単

まあまあ固く作られている

• 状態管理はmarkdownではなくJSONで保存されており、そのJSONはTypeScriptのコード経由で基本触られる。そのため、状態管理が壊れることなどが少なく固く作られているのは好印象
• 状態管理をしているJSONの例は以下

{
  "id": "approval_1756920919672_0zq26gp9f",
  "title": "素数判定Condition - 設計書",
  "filePath": ".spec-workflow/specs/prime-number-condition/design.md",
  "type": "document",
  "status": "needs-revision",
  "createdAt": "2025-09-03T17:35:19.672Z",
  "category": "spec",
  "categoryName": "prime-number-condition",
  "respondedAt": "2025-09-03T17:38:52.194Z",
  "comments": [
    {
      "type": "selection",
      "comment": "これなに? このパターン、どういうのか知らない",
      "timestamp": "2025-09-03T17:37:01.386Z",
      "selectedText": "- **Opaque Struct Pattern**: `ConditionType`の定義に従い、新しい条件タイプを追加",
      "highlightColor": {
        "bg": "rgba(255, 235, 59, 0.3)",
        "border": "#FFEB3B",
        "name": "#ffeb3b"
      },
      "id": "comment_1756921021386_vv30aiozx"
    }
  ]
}

仕様のやり取りをするWebサーバーが立ち上がる

ここが結構好き。実際にcchookで適当に試した際のPull Requestも貼っておきます。

npx -y @pimzino/spec-workflow-mcp@latest /path/to/your/project --dashboardで以下のダッシュボードが立ち上がります。最近作った仕様書やそれに紐付くタスクの完了具合などが分かる。VSCodeの拡張もあるが、iTerm2とChromeのみで生きていきたいので、Webサーバーとしてダッシュボードが立ち上がるほうが好みなのだ。

プロダクト全体に関わるSteeringもさっと見れる。プレビューやその場での編集もサポートしている。

仕様書(Specs)の一覧。ここだと適当に「素数の時だけ何かするモード」と「ずんだもんモード」の仕様書を遊びで書いてみている。

実際に出来上がる仕様書もかなりKiroっぽい感じ。

仕様書のレビューも画面上からできる。レビューが通らないと、実装が開始されないので安心感がある。LLM Agentが書いたコードは最近だとdifitを使うことも多いが、仕様書駆動開発に関してだとこの画面のほうがレビューがしやすいと思った。

レビューコメントも書きやすい。

仕様書を元にタスクを生成するとこんな感じ。これもかなりKiroっぽい。N個のタスクのうちM個が完了している、などが分かる。

仕様書駆動開発の良さを感じられた

• Claude Codeにあれこれやらせた後に「あっ、そういうことじゃなくって...」と指摘をすると、コンテキストも増えるしClaude Codeがうまく動けなくなることも多い
  • Specの時点で指摘できるので、Claude Codeにとっても混乱が少なくて済む
• Auto Compactが怖くなくなる
  • Claude CodeはAuto Compactの後は物忘れ状態になってしまうが、Specsによるタスク定義やTaskによるタスクの進捗がしっかり残っているので、Auto Compactの後にアホになったな...と感じることは減った
  • 仕様やタスク定義が終わったら別セッションを立ち上げても情報量としては十分持っていると感じる
• 「次のステップは...」と考えずに済む
  • 新しいフレームワークを使い出すと、そのやり方を覚えないといけないが「このステップが終わったら次はこれです」とMCPが案内してくれるので、フレームワークのやり方を頭に叩き込まなくてもやれるのがよい

まとめ

仕様書駆動開発自体はいいものだなと思っていましたが、特定のベンダーなどに限定されずに実行しやすい環境が揃ってきたのはユーザーにとってはいいことですね。仕様書を書くのがまだ自分は上手くないなと感じることも多いので、その方向の技術も磨いていきたいと思いました。