仕様駆動開発(SDD)って効果あるの? Spec Kitを使ってTODOアプリを作ってみた。

AI, Gemini CLI, Spec Kit

はじめに

最近、ソフトウェア開発界隈で話題になっている概念として「仕様駆動開発(SDD)」があります。
これはその名の通り、コードを書き始める前に詳細な仕様書を作成し、その仕様書に沿って開発を進めていく手法です。
ここ10年間はアジャイル開発のように動くコードを作りながら後で仕様をまとめる方法が主流でしたが、AIの普及に伴い、AIエージェントに意図したコードを書いてもらうためのガードレールとして再注目されています。

今回はGitHub社が公開している仕様駆動開発支援ツールである「Spec Kit」を利用し、Gemini CLIを使ったバイブコーディングにおいて、利用した場合と利用しない場合で成果物にどのような差が出るのかを検証していきたいと思います。

作るもの

今回、仕様駆動開発を試すにあたって作成するアプリケーションはTODOアプリです。
TODOアプリは様々な形態がありますが、今回は以下のように定義します。

TODOアプリの定義

  • カード形式でTODOが管理できる
  • TODOのCRUD操作ができる
  • TODOの優先度を入れ替えることができる

開発環境

  • macOS Sequoia(Version: 15.1.1)
  • Gemini CLI (Version: 0.5.5, 利用モデルはGemini 2.5 Flashのみ)
  • Spec Kit (Version: 0.0.52)
  • iTerm2 (Version: 3.6.1)

開発方法

  • Gemini CLIを利用したバイブコーディング(求められない限り、追加指示はしない)
  • Spec Kit利用時・非利用時ともにGemini 2.5 Flashを使用し、モデルによる結果の差異を排除する
  • Gitを利用した作業の取り消しはしない
  • コンテキスト圧縮はAIエージェントが自動で行う場合のみ許可

完成品の評価方法

  • 最初に出力された完成品を評価する(人の指示による追加修正は行わない)
  • 実際に触ってみてTODOアプリの定義を満たしているかを中心に、使いやすさも含めて評価する

実際に開発してみる

Gemini CLIのみ

それでは最初に、Gemini CLIのみで開発してみましょう。
こちらは仕様を伝えるための特別な方法がないため、以下のプロンプトを直接入力します。

すると、以下のように計画を立ててくれました。
Gemini CLI自体にも、このような実行計画機能が内蔵されています。

Gemini_Cli_Instruction.png

それでは、これで開発を進めてもらいましょう。
開発が始まってから数分待つと完成したようなので、動作確認してみます。

todo_without_spec_kit_new.gif

触ってみたところ、いくつか不足している機能があることが分かりました。

  • TODOの編集ができない
  • TODOの優先順位の細かい入れ替えができない(最下位にしか移せない?)

TODOの編集ができない点は、明らかな要件漏れと言えるでしょう。
今回、Gemini CLI単体では仕様通りの完成品を出力することができませんでした。

Gemini CLI with Spec Kit

それでは、Spec Kitを使って同じように開発してみましょう。
最初に以下のコマンドでSpec Kitの初期設定を行います。

すると、Spec Kitのガイドが起動するので使いたいツールを指定します。

Spec_Kit_Instruction.png

手順通りに設定が完了したら、Gemini CLIから以下の指定されたコマンドを実行することでSpec Kitの機能を利用できます。

Spec_Kit_Command.png

様々な機能がありますが、今回は /specifyの仕様を決める機能を試して、それをもとに実装させてみようと思います。入力内容はGemini CLIのみの場合と揃えて以下のようにします。

すると、Gemini CLIがspec.mdという仕様書ファイルを作成します。
内容としては以下のように、どのような要件があるか、どのような内容でレビューするかなどが記載されています(ファイル文字数が多いので一部抜粋)。

Key Entitiesを見ると、 NEEDS CLARIFICATIONという表示で明確化してほしい箇所が記載されています。
TODOにタイトル・説明・優先度・ステータス以外に何か必要だろうかと書かれているので、Gemini CLIを通してそれ以外は不要であることを追記します。

すると新しいspec.mdが発行されて、該当箇所は修正されました。

NEEDS CLARIFICATIONが消えるまで修正していきます。
細かいNEEDS CLARIFICATIONの修正には、残っている該当箇所を検索してくれる /clarifyが便利です。

spec_kit_clarify.png

すべてのNEEDS CLARIFICATIONが消えたので、 /planで実行計画を立てます。
このフェーズでは、Web検索などを活用して実装計画の細部を詰めているようです。

spec_kit_plan.png

この工程が終わったら、 /tasksで計画をタスクに分割します。
以下のような細かな実装手順が tasks.mdとして出力されます。

というわけで、ようやく実装に入れます。これは特にコマンドなどはなく、実装をお願いすると開始されます。
実装を約10分待った結果は…

Spec_Kit_Output.png

なんと、バックエンドのみが実装されたようです。Gemini CLIとしてはこれで完成らしく、アプリを触るためのフロントエンドがないことも含めて要件通りだそうです。
確かにTODOアプリの定義としてフロントエンドがあることは伝えていなかったのですが、正直そこは汲み取ってほしかったなと思いました。

というわけで、実際にアプリを触ることができないため、こちらは評価以前の問題となってしまいました。

まとめ

今回は、Spec Kitを使った場合と使わない場合でどのような差が出るかを調べてみました。
結果としては以下のようになりました。

  • Gemini CLIのみ:TODOアプリの定義のうち一部を満たせていない
  • Gemini CLI with Spec Kit:触れる状態で出力されなかったため、評価不能

今回の実験をしての感想ですが、Gemini CLIのみで実装させた方が、何を欲しているかを予測して情報を補完しつつ実装する傾向が強かったように思います。Geminiは他社のモデルと比べると情報を勝手に補完せず指示を求めてくる印象がありますが、それでもSpec Kitを使った場合と比べると、よしなにやってくれる割合が大きいと感じました。

一方、Spec Kitは今回の実験としては残念な結果になりましたが、やはり仕様駆動開発の名の通り、仕様書や手順書に書いてあることを忠実に実装するように動いているように感じました。
今回バックエンドしか実装されなかったことも、指示が不十分だったということでもあるので、Spec Kitを使う場合は、頭の中で考えていることを隅から隅まで伝える意識が必要かもしれません。

また今回の実験からの学びとして、仕様駆動開発(SDD)も銀の弾丸ではなく、AIエージェントにどこまで自走力を求めるかによって使う・使わないを選ぶべきだということが分かりました。

参考

この記事を書いた人

清水日向
清水日向
24卒で株式会社レコチョクに入社。
フロントエンド・バックエンドエンジニアをしています。
三度の飯よりもEDMが好き。

AI, Gemini CLI, Spec Kit