はじめに
Spec駆動開発が市民権を得てきている。
仕様をAIに定義してもらい、それをClaude Codeでぶん回す。
一度使ってみようと思ってGitHub製のSpec Kitを使ったところ非常に手応えがあってなんだか手放せなっくなったので伝えておきたい。
少しとっつきにくいが、実行する順番だけわかっていれば理解が早いのでそれについて書きたいと思います。
今回はClaude CodeにSpce Kitを入れるやり方を紹介します。
Spec Kitについて
これは、AIのコーディングエージェントを使って仕様書駆動開発に基づいてアプリケーションを構築する前提で、仕様書を出力することに特化したライブラリになっています。
Spec Kitは、そのドキュメントの中で仕様駆動開発（Specification-Driven Development）を明確に謳い、その処理のワークフローを仕様(specification)、計画(planning)、タスク作成(taskking)として定めています。
これまでの課題
自分もこれまでTODOリストなどをIssueに出力させて作っていたが、実際のところ、作る過程で考慮もれに気づいたりすることが多かった。
AIを使って使用を作成すると、1を聞いて100くらい膨らませて網羅的に定義してくれる。
その時は完璧なように見えてしまい、後々実装しながら「あ、こここうして欲しくなかったな」とか「ここ考えられてなかったな」ということに形ができてから気づくことが多かった。そういう経験をした方も多かったのではないでしょうか。
そうすると結局修正に手間がかかったり、スクラップ&ビルドで作り直す方が早い、ということになりかねなかったように思っています。
Spec Kitのインストール
最近Pythonのパッケージマネージャーとして大変イケてるuvコマンドを使って入れます。
uvコマンドのインストール
uvコマンドは下記のコマンドでインストール可能です。
# MacOS or Linux
curl -LsSf https://astral.sh/uv/install.sh | sh
# Windows
powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"
下記のコマンドでインストール可能です。
uv tool install specify-cli --from git+https://github.com/github/spec-kit.git
プロジェクトの初期化
specify init <PROJECT_NAME>
ディレクトリを指定するのですが、すでにディレクトリが存在するとエラーで弾かれます。
Directory '<PROJECT_NAME>' already exists
Please choose a different project name or remove the existing directory.
今の所削除するか名前を変えるしかなさそうです。
Spec Kitの流れ
speckit initをすると、どのコーディングエージェントで使うか、を選択します。
AIエージェント選択画面
Claude Codeを選択した場合、単にClaude Codeのカスタムスラッシュコマンドとしてインストールされます。
基本的にこの実行順序を知っていれば大丈夫です。
| フェーズ | コマンド | 内容 |
|---|---|---|
| 1 | /speckit.constitution | プロジェクトの原則を定義 |
| 2 | /speckit.specify | 仕様書を生成 |
| 3 | /speckit.clarify | （任意）曖昧な仕様をAIが質問で解消 |
| 4 | /speckit.plan | 実装計画を立案 |
| 5 | /speckit.checklist | （任意）品質チェックリスト生成 |
| 6 | /speckit.tasks | 実行タスクを生成 |
| 7 | /speckit.analyze | （任意）整合性をAIが検証 |
| 8 | /speckit.implement | 実際に実装へ移行 |
各コマンドの説明
1 /speckit.constitution プロジェクトの原則を定義
プロジェクト全体で何を重んじるか、を定義します。
対話的に決めていくこともできて、最終的にconstitution.mdファイルに出力されます。
例えばセキュリティだったり、パフォーマンスを重視する、とか、アプリケーション全体で何を重視するのかの原則を定め、憲法を制定します。
2 /speckit.specify 仕様書を生成
本丸の仕様策定です。作りたいアプリケーション像をなるべく詳しく書いてください。
3 /speckit.clarify （任意）曖昧な仕様をAIが質問で解消
個人的にはこれが結構良くて、Specifyで定義した仕様を掘り進めてくれて曖昧な仕様を指摘してくれます。
「ああ！確かにそれは考慮守れてたな」とか「確かにそれは後々問題が出るな！」ということをエンジニア視点でつっこんで聞いてくれます。
さらに、おすすめの選択は何かを提示した上で選択肢を与えてくれます。
例えば筆者の事例だと、ある工程で受注データを修正することのあるアプリケーションを作りたかったのですが、「一人のスタッフが受注をいじっている途中に、ブラウザが落ちたり長期離脱した場合にどうするのか」「受注の修正対応が違うスタッフと競合した場合にどうするのか」などの質問を受けたりしました。
4 /speckit.plan 実装計画を立案
これまでで定義した憲法、仕様書、ユーザーストーリーや要件をもとに具体的な実装計画を策定します。
技術選定やファイル構造など「どう作るか」にフォーカスして計画をまとめます。
5 /speckit.checklist （任意）品質チェックリスト生成
アプリケーションの品質を担保するためのチェックリストを作成します。
完全性、明瞭性、網羅性、測定可能性などが担保されることを目指しています。
仕様についてのユニットテストのように働きます。
6 /speckit.tasks 実行タスクを生成
planをもとにゴールや各ステップを明確にした上で具体的なタスクに落とします。
各フェーズに分かれたTODOリストのような形で出力してくれて、実装が終わったらチェックをつけてくれます。
LLMが追加のコンテキストなしで実行可能なタスクリストを生成することを目指しているため、一つ一つがこのまま実装に入れるように考慮されています。またそれにより作業を中断しても再開できるようになっています。
7 /speckit.analyze （任意）整合性をAIが検証
これまでの出力したファイルを横断的に検索し、重複検出、曖昧性検出、仕様不足検出などを行なってくれます。
8 /speckit.implement
タスクを元に実際に実装へ移行します。
終わりに
だいたい上記の流れさえ掴んでおけば、順番にコマンドを打っていけばいい感じに仕様をまとめて、タスクに落とし込み、テストなどを定義して、実装してくれる。
implimentをしながらも「ここまで進んだけど次はどうする？」「ちなみにおすすめはこれ」とか相談しながら進めてくれる。
全部英語になるので少し読むのが辛いことがあるが、Claudeにそのまま聞けば丁寧に教えてくれるし、もう少し掘り下げてアドバイスをもらいながら決めていくことができる。
まさに頼れる上級エンジニアに依頼している感じで、個人的には結構感動したし、人間のエンジニアいらんやんけ、と改めて思った。
何か作りたい方がある方はぜひ体感してほしい。
Discussion