Spec DrivenでAI駆動開発を加速させる - Spec Kit入門
はじめに
AIに対して工夫なしの指示だと開発に限界を感じることもあるでしょう。AIにしっかりとコンテキストを渡してあげないと、意図通りに動いてくれません。
考えられる解決策としては、自前でコンテキストや指示を書いたインストラクションMarkdownファイルを与える方法があります。個人的にはインストラクションの方が手軽なのでよくやりますが、先日以下の記事でSpec Drivenという言葉を見かけました。
ここでは、Spec Drivenについて掘り下げ、それを実現するツールであるSpec Kitについて網羅的に紹介します。
完成物デモ
記事後半ではSpec Kitを使って簡単なTODOアプリを作ってみます。
Spec Drivenとは
Spec Drivenとは「仕様駆動開発」のことで、少し前にはAI IDEのKiroが話題になりました。
巷で話題のVibe Codingの限界を解消するために生まれたようなアプローチですが、仕様を元に開発するなんてことは昔からやっています。
相違点は、仕様の作成もソフトウェアやAIがサポートしてくれる点でしょうか。別に目新しいアプローチではないですが、仕様作成までAIがサポートしているなら、活用の幅は色々ありそうです。
Spec Drivenを実現するツール
- Spec Kit(GitHubのOSS)
- Kiro(AWSのAI IDE)
他にも海外製のツールを多く見かけました。Kiroも良いとは思いますが、ウェイトリストへの登録が必要で、利用開始までしばらく待つ必要があります(プレビュー期間なのかな?)
Spec Kitとは
Spec KitとはGitHubによるOSSのツールキットで、Spec Driven Development(仕様駆動開発)を支援するツールです。
従来の開発手法では、仕様(ドキュメント)がコードに追いつかず、設計意図が曖昧になったり、AIコード生成との乖離が起こったりすることがあります。このツールキットは仕様を「生きた実行可能アーティファクト」にして、AIと協調して開発を進める方式を提案しています。
Spec Kitは2025年の8月23日にリリースされたばかりで、まだプレビュー段階だと思われます。
Spec Kitの活用場所
- ゼロイチの開発
- 既存システムへの機能追加
- レガシーシステムのモダナイゼーション
おそらくゼロイチが一番得意かと思われますが、既存プロジェクトにも導入できるので、新規の機能開発やモダナイゼーションでも活用はできそうです。
インストール方法
Spec Kitをインストールするには、uv
というRust製のパッケージマネージャーが必要です。なければ先にインストールしましょう。
# macOS, Linuxの場合
$ curl -LsSf https://astral.sh/uv/install.sh | sh
# Windows
$ powershell -ExecutionPolicy ByPass -c "irm https://astral.sh/uv/install.ps1 | iex"
uvがインストールできたら、spec-kitをインストールします。
$ uv tool install specify-cli --from git+https://github.com/github/spec-kit.git
Resolved 20 packages in 109ms
...
Installed 1 executable: specify
Spec Kitの始め方
Spec Kitはプロジェクト単位で立ち上げます。新規プロジェクトだけでなく、既にあるプロジェクトに対しても作成可能です。とりあえず作ってみましょう。
# 新規で作成する場合
$ specify init <project-name>
# 既存プロジェクト内で作成する場合
$ specify init --here
# デフォルトでは自動でgitが設定されるので、無視したい場合
$ specify init <project-name> --no-git
コマンドを実行すると、2つの入力が求められます。
- 使用するAI Assistant
- プロジェクト初期化時に生成するスクリプトファイルの種類:sh(bash/zsh) or ps(PowerShell)
一応、コンソールから入力しなくても、オプションから指定できます。
$ specify init <project-name> --ai copilot --script sh
使用できるAI Assistant
最新情報はこちらを確認いただきたいですが、現状主要なAI Assistantは使用できるようです。
- Claude Code
- GitHub Copilot
- Gemini CLI
- Cursor
- etc.
後で言及しますが、試験的に使用する場合は最初は無料枠内で使えるモデルを推奨します。
今回はGemini CLIのgemini-2.5-pro
と途中からgemini-2.5-flash
を使っています。
ディレクトリ構造
プロジェクトを作成すると以下のファイルが作成されます。
.
├── .gemini # 使用するAgentによってディレクトリが異なります
│ └── commands
│ ├── analyze.toml
│ ├── clarify.toml
│ ├── constitution.toml
│ ├── implement.toml
│ ├── plan.toml
│ ├── specify.toml
│ └── tasks.toml
└── .specify
├── memory # 記憶
│ └── constitution.md
├── scripts # ワークフローの補助
│ └── bash
│ ├── check-prerequisites.sh
│ ├── common.sh
│ ├── create-new-feature.sh
│ ├── setup-plan.sh
│ └── update-agent-context.sh
└── templates # 仕様書の雛形
├── agent-file-template.md
├── plan-template.md
├── spec-template.md
└── tasks-template.md
我々の仕事はcommandsを呼び出すだけです。commandsの中でmemory、scripts、templatesが使用されます。
使い方
ステップは大きく7つあります。仕様駆動であるため、実装までの準備が大変です。多いですが頑張りましょう。
ステップ | 内容 | コマンド |
---|---|---|
1 | プロジェクト原則の作成 | /constitution |
2 | 仕様の作成 | /specify |
3 | 仕様の明確化 | /clarify |
4 | 技術計画の作成 | /plan |
5 | タスク分割 | /tasks |
6 | 整合性チェック | /analyze |
7 | 実装 | /implement |
これらのコマンドはリリース初期の頃から増えています。
実際に簡単なアプリを作ってそれぞれ確認してみましょう。
Spec Kitを使ったサンプルアプリ
簡単にTODOアプリを作って各機能を確認していきます。
こだわるとどこまでも指示できそうですが、ここでは簡単な仕様で作成します。
/constitution:原則の作成
プロジェクトの「開発チーム憲章」のようなものを作成します。ここで決めたことは、後のコマンドで参照されます。
/constitution このアプリはTODOアプリです。シンプルで直感的に使えることを最優先とする。最小限の機能(タスクの追加・削除・完了チェック)から始め、わかりやすいUIと即時反映を実現する。開発は小さな単位で進め、繰り返し改善していくこと。
/specify:仕様の作成
仕様を作成します。「このアプリが何をするのか・なぜ必要なのか」 を整理する段階です。
開発したいプロジェクトの具体的な要件を指定しましょう。この時点では技術スタックに焦点を当ててはいけません。
/specify このアプリは、ユーザーが日常のタスクを簡単に管理できるようにすることを目的とする。ユーザーは新しいタスクを追加し、完了したタスクにチェックをつけ、不要になったタスクを削除できる。操作は直感的で即時に反映され、複雑な設定や登録を必要としない。最初のリリースでは単一ユーザー利用を想定し、ブラウザからアクセス可能な形で提供する。
/clarify:仕様の明確化
作成された仕様の中で不明瞭な部分を問い直し、仕様を補完します。今回は省略します。
/plan:技術計画の作成
技術スタックやアーキテクチャを設計します。
/plan フロントエンドは React を用い、シンプルで直感的に操作できる UI を実装する。状態管理には React Hooks を基本とし、必要に応じて Context API を利用する。
バックエンドは Go を用い、Clean Architecture に基づいて実装する。レイヤーは Entity、UseCase、Interface Adapter、Infrastructure に分割し、責務を明確に保つ。
データベースは SQLite を採用し、ORM として GORM を用いる。スキーマは単純なタスク管理(id, title, completed, created_at)を基本とする。
API は RESTful とし、フロントエンドからは JSON を介してアクセスする。基本操作はタスクの作成、取得、更新、削除を提供する。
開発環境は Docker を用意し、フロントエンドとバックエンドをコンテナで分離する。
テストはユニットテストを必須とし、重要機能については統合テストを行う。
デプロイはローカル環境での動作させる。
/tasks:タスク分割
技術計画から実行可能なタスクリストを作成するために使用します。
/tasks
/analyze:整合性チェック
仕様・計画・タスクの一貫性をチェックします。(実行し忘れました)
/analyze
/implement:実装
タスク分割で作成されたタスクリストに沿って実装を開始します。すごく時間がかかります。
/implement
備考
/implement実行後、いくつかエラーが発生したので、以下のように指示をしてエラーを解消しました。使い方は間違ってるかも。
/implement エラーを解消して。<エラー文を添付>
完成物はこちら
# 起動
$ docker compose up
使ってみての感想と懸念
良かったところ
- 完成物のコードは割と良い感じ
- 仕様が残っているので、不具合の解消が簡単
- tasksでタスク分解しているため、途中からの実行でも実装を再開できる
コーディング的な完成度は割と高い印象を受けました。レビューをする必要はありますが、このまま機能拡張しても問題ないレベルかなと思っています。不具合はもちろん出ましたが、エラー文だけ貼り付けて再実行したらピンポイントで解消してくれました。また後に言及しますが、実装を途中で止めてしまっても再開できるのはすごく良かったです。
悪かったところ
- コンテキストをかなり消費する
実はSpec Kitのモデルは最初CopilotのClaudeを使用していました。Copilotにはプレミアムリクエストという概念があるのですが、これには制限があります。Spec Kitはこれをゴリゴリ消費するのです。(1日で使い切りそう)
そこで、無料かつ100万トークンまで使えるGemini CLIを今回使いました。しかし、これでも無料枠をすぐ使い切ってしまったので、途中からgemini-2.5-flash
に切り替えて実装していました。トータルで1000万トークンくらい使ってそう。
ℹ⚡ Automatically switching from gemini-2.5-pro to gemini-2.5-flash for faster responses for the remainder of this session.
⚡ Possible reasons for this are that you have received multiple consecutive capacity errors or you have reached your daily
gemini-2.5-pro quota limit
⚡ To increase your limits, upgrade to a Gemini Code Assist Standard or Enterprise plan with higher limits at
https://goo.gle/set-up-gemini-code-assist
⚡ Or you can utilize a Gemini API Key. See: https://goo.gle/gemini-cli-docs-auth#gemini-api-key
⚡ You can switch authentication methods by typing /auth
✕ [API Error: Please submit a new query to continue with the Flash model.]
その他
作成されたアプリケーションのGoやNode.jsのバージョンが低く実装されてしまいました。バージョン指定は計画の段階で明示的に行ったほうが良さそうです。
まとめ
Spec Kitを使って仕様駆動開発をしてみました。完成物自体は割と良い感じですが、手順に少し煩わしさを感じます。また、莫大にコンテキストを消費するので、たとえAI Agentに課金していたとしてもクレジットをすぐに使い果たしてしまいそうです。お試しで使用するなら無料・無制限のモデルを使用するのが良いのではないかと思います。
また一つ思ったことですが、Spec Kitのアプローチや仕組み自体はとても単純です。コードも全て公開されています。仕様駆動というアプローチは良いとは思いますが、簡単に他のサービスに真似されそうだなという印象も受けます。Vibe Codingの過渡期的な対策にならなければ良いのですが。
完成品は良かったので、コンテキストをもっと抑えられるとなお良いですね。
Discussion