前回は「仕様駆動開発が本命。でも自前実装は大変だから既存ソリューションのSpec Kitを利用することにした」と言うところまでお話しました。
早速Spec Kitの基本から見ていきます。
インストールと初期設定
uvxをインストールし、
curl -LsSf https://astral.sh/uv/install.sh | sh
spec-kitのインストールと初期設定。既存プロジェクトに導入するためここではプロジェクト指定を--hereとしています。
cd cognito-example/
uvx --from git+https://github.com/github/spec-kit.git specify init --here
下記のような状態になりました
~/repositories/cognito-example$ tree -a
.
├── .claude
│ └── commands
│ ├── constitution.md
│ ├── implement.md
│ ├── plan.md
│ ├── specify.md
│ └── tasks.md
├── .specify
│ ├── memory
│ │ └── constitution.md
│ ├── scripts
│ │ └── bash
│ │ ├── check-implementation-prerequisites.sh
│ │ ├── check-task-prerequisites.sh
│ │ ├── common.sh
│ │ ├── create-new-feature.sh
│ │ ├── get-feature-paths.sh
│ │ ├── setup-plan.sh
│ │ └── update-agent-context.sh
│ └── templates
│ ├── agent-file-template.md
│ ├── plan-template.md
│ ├── spec-template.md
│ └── tasks-template.md
└── cognito-example.code-workspace
基本のワークフロー
Spec Kitのコマンドは2025/09/21時点で5つ。READMEからそのまま引き写しますが、下記のようになっています。
github/spec-kitが公開されました。AI駆動開発の本命であろう仕様駆動開発の標準化に貢献するであろうこのプロジェクトにはとても注目しています。
論理的帰結としての仕様駆動開発
かつて私も仕様書を元にAIに作成させる方法を自著の同人誌で提案したことがあります。やはり有利なのです。
まず大前提として、生成AIに作業をさせるためにはプロンプトが必要です。そのプロンプトは明確かつ必要十分の情報を保有していることが望ましいです。
そして開発プロジェクトにおいて「明確かつ必要十分の情報を保有している」プロンプトすなわちテキストとは、つまるところ仕様書です。仕様書とは設計やコーディングに必要な情報を明確かつ必要十分に記載したテキストなのですから。――常に実現できているとは限りませんが、目指してはいます。
である以上、
「いっそプロンプトとして仕様書を渡してしまえばいい」
という発想に至るのは自然な帰結でしょう。
AIに渡すプロンプトを毎回作るのは大変ですし、再現性も低いという問題があります。これはバイブコーディングの泣き所でもあります。ですが仕様書を渡すスタイルなら何度でも書き終えた仕様書を渡せば済むわけです。再利用も簡単、追跡性もばっちりです。
Go言語を用いた開発プロジェクトに仕様駆動開発を導入することの課題とソリューションの登場
さて、前述の技術同人ではIaCを仕様駆動開発（と言う名前ではありませんでしたが）で実用にたるレベルで実行することができていました。これには下記の要因があります。
- コードの規模が小さく単純 : Terraform用コードの生成であったためコードの規模がさほど大きくなく、また分岐等のロジックもごくわずかでした
- ベストプラクティスが豊富に用意されている : Terraformのコーディングは公式やAWSがベストプラクティスを用意しており、これをそのまま使うことで高品質の成果物を作成することが可能です。
- 単独開発者 : 想定が私一人でも回る規模であったため、チーム内教育のことを考えなくて済みました。
ところがこの成功体験をもとにGoプロジェクトで仕様駆動開発を実践しようとすると問題が生じました。上の条件の逆で、コードの規模が大きく複雑、取りうるアーキテクチャ・ライブラリ・ツールの数も多く、またチーム開発を想定する必要があったのです。これは必要なプロンプト（＝ドキュメント）の量を増やし、開発体制の整備にかかる時間をIaCだけのケースよりはるかに大きなものとし、しかもチーム内教育への考慮まで要求されることとなりました。
これらの課題を地力で頑張って乗り切ることは、不可能ではないまでも多大な時間を要し、かつそこまでしても普及させられると思えず、ありていに言ってあまり割に合わあい作業になりそうに思えました。
そのような状況で登場したのがKiroや今回のSpec Kit等、大手が提示するツールやプロジェクトです。まだ実験的な性格も強いようですが、おそらく開発体制の充実度合いや運用保守の強固さなどから、このタイプの提示する仕様駆動開発の採用が堅い選択になるのではないかと考えられます。
個別に最適化したほうがプロジェクトにフィットさせられるのでしょうが、現実的には、多くのプロジェクトでは人の入れ替わりや開発リソースの限界などの要因によってそう簡単ではありません。技術的な理想ではなくとも、運用や教育などの面まで含めた総合的判断においては、既存のソリューションを利用するほうがベストとなるケースが多いことでしょう。
かなり前置きが長くなりましたが、このようなわけで、独自開発ではなく既存プロジェクトに乗る方向で仕様駆動開発を試していきます。spec-kitです。
