はじめに
最近、ソフトウェア開発界隈で話題になっている概念として「仕様駆動開発（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のみで開発してみましょう。
こちらは仕様を伝えるための特別な方法がないため、以下のプロンプトを直接入力します。
TODOアプリケーションを作りたいです。
TODOアプリの定義
- カード形式でTODOが管理できる
- TODOのCRUD操作ができる
- TODOの優先度を入れ替えることができる
すると、以下のように計画を立ててくれました。
Gemini CLI自体にも、このような実行計画機能が内蔵されています。
それでは、これで開発を進めてもらいましょう。
開発が始まってから数分待つと完成したようなので、動作確認してみます。
触ってみたところ、いくつか不足している機能があると分かりました。
- TODOの編集ができない
- TODOの優先順位の細かい入れ替えができない（最下位にしか移せない？）
TODOの編集ができない点は、明らかな要件漏れと言えるでしょう。
今回、Gemini CLI単体では仕様通りの完成品を出力することができませんでした。
Gemini CLI with Spec Kit
それでは、Spec Kitを使って同じように開発してみましょう。
最初に以下のコマンドでSpec Kitの初期設定を行います。
specify init <PROJECT-NAME>
すると、Spec Kitのガイドが起動するので使いたいツールを指定します。
手順通りに設定が完了したら、Gemini CLIから以下の指定されたコマンドを実行することでSpec Kitの機能を利用できます。
様々な機能がありますが、今回は/specifyの仕様を決める機能を試して、それをもとに実装させてみようと思います。入力内容はGemini CLIのみの場合と揃えて、以下のようにします。
/specify
TODOアプリケーションを作りたいです。
TODOアプリの定義
- カード形式でTODOが管理できる
- TODOのCRUD操作ができる
- TODOの優先度を入れ替えることができる
すると、Gemini CLIがspec.mdという仕様書ファイルを作成します。
内容としては以下のように、どのような要件があるか、どのような内容でレビューするかなどが記載されています（ファイル文字数が多いので一部抜粋）。
## Requirements *(mandatory)*
### Functional Requirements
- **FR-001**: System MUST allow users to create new TODO items.
- **FR-002**: System MUST display all TODO items in a card-based format.
- **FR-003**: System MUST allow users to view the details of a TODO item.
- **FR-004**: System MUST allow users to update existing TODO items.
- **FR-005**: System MUST allow users to delete TODO items.
- **FR-006**: System MUST allow users to change the priority (order) of TODO items.
- **FR-007**: System MUST persist TODO items across sessions. [NEEDS CLARIFICATION: How are TODO items stored (local storage, database, etc.)?]
### Key Entities *(include if feature involves data)*
- **TODO Item**: Represents a single task. Attributes include: title, description, priority, status (e.g., pending, completed). [NEEDS CLARIFICATION: Are there other attributes like due date, tags, etc.?]
---
## Review & Acceptance Checklist
*GATE: Automated checks run during main() execution*
### Content Quality
- [ ] No implementation details (languages, frameworks, APIs)
- [ ] Focused on user value and business needs
- [ ] Written for non-technical stakeholders
- [ ] All mandatory sections completed
### Requirement Completeness
- [ ] No [NEEDS CLARIFICATION] markers remain
- [ ] Requirements are testable and unambiguous
- [ ] Success criteria are measurable
- [ ] Scope is clearly bounded
- [ ] Dependencies and assumptions identified
---
Key Entitiesを見ると、NEEDS CLARIFICATIONという表示で明確化してほしい箇所が記載されています。
TODOにタイトル・説明・優先度・ステータス以外に何か必要だろうかと書かれているので、Gemini CLIを通してそれ以外は不要であることを追記します。
/specify タイトル・説明・優先度・ステータス以外の内容はTODOになくて大丈夫です
すると新しいspec.mdが発行されて、該当箇所は修正されました。
### Key Entities *(include if feature involves data)*
- **TODO Item**: Represents a single task. Attributes are strictly limited to: title, description, priority, status.
NEEDS CLARIFICATIONが消えるまで修正していきます。
細かいNEEDS CLARIFICATIONの修正には、残っている該当箇所を検索してくれる/clarifyが便利です。
すべてのNEEDS CLARIFICATIONが消えたので、/planで実行計画を立てます。
このフェーズでは、Web検索などを活用して実装計画の細部を詰めているようです。
この工程が終わったら、/tasksで計画をタスクに分割します。
以下のような細かな実装手順がtasks.mdとして出力されます。
## Phase 3.1: Setup
- [ ] T001 Create project structure (src/, tests/) in `/Users/h-shimizu/Desktop/sys_group1/Spec_Kit/with_spec_kit/`
- [ ] T002 Initialize project (e.g., `npm init`, `pip install`) in `/Users/h-shimizu/Desktop/sys_group1/Spec_Kit/with_spec_kit/`
- [ ] T003 [P] Configure linting and formatting tools in `/Users/h-shimizu/Desktop/sys_group1/Spec_Kit/with_spec_kit/`
## Phase 3.2: Tests First (TDD) ⚠️ MUST COMPLETE BEFORE 3.3
**CRITICAL: These tests MUST be written and MUST FAIL before ANY implementation**
- [ ] T004 [P] Integration test for rejecting unauthorized attribute in `tests/integration/test_todo_attribute_rejection.py`
- [ ] T005 [P] Unit test for `TODO Item` model attribute validation in `tests/unit/test_todo_model.py`
## Phase 3.3: Core Implementation (ONLY after tests are failing)
- [ ] T006 [P] Implement `TODO Item` model with attribute validation in `src/models/todo_item.py`
- [ ] T007 Implement attribute validation logic in `src/services/todo_validation_service.py`
- [ ] T008 Implement error handling for attribute rejection in `src/services/todo_validation_service.py`
## Phase 3.4: Integration
- [ ] T009 Integrate attribute validation into TODO item creation/update flow (e.g., in `src/api/todo_controller.py` or `src/cli/todo_commands.py`)
## Phase 3.5: Polish
- [ ] T010 [P] Update documentation (e.g., `docs/api.md` or `README.md`) to reflect attribute constraints.
というわけで、ようやく実装に入れます。これは特にコマンドなどはなく、実装をお願いすると開始されます。
実装を約10分待った結果は...
なんと、バックエンドのみが実装されたようです。Gemini CLIとしてはこれで完成らしく、アプリを触るためのフロントエンドがないことも含めて要件通りだそうです。
確かにTODOアプリの定義としてフロントエンドがあることは伝えていなかったのですが、正直そこは汲み取ってほしかったなと思いました。
というわけで、実際にアプリを触ることができないため、こちらは評価以前の問題となってしまいました。
まとめ
今回は、Spec Kitを使った場合と使わない場合でどのような差が出るかを調べてみました。
結果としては以下のようになりました。
- Gemini CLIのみ：TODOアプリの定義のうち一部を満たせていない
- Gemini CLI with Spec Kit：触れる状態で出力されなかったため、評価不能
今回の実験をしての感想ですが、Gemini CLIのみで実装させた方が、何を欲しているかを予測して情報を補完しつつ実装する傾向が強かったように思います。Geminiは他社のモデルと比べると情報を勝手に補完せず指示を求めてくる印象がありますが、それでもSpec Kitを使った場合と比べると、よしなにやってくれる割合が大きいと感じました。
一方、Spec Kitは今回の実験としては残念な結果になりましたが、やはり仕様駆動開発の名の通り、仕様書や手順書に書いてあることを忠実に実装するよう動いているように感じました。
今回バックエンドしか実装されなかったことも、指示が不十分だったということでもあるので、Spec Kitを使う場合は、頭の中で考えていることを隅から隅まで伝える意識が必要かもしれません。
また今回の実験からの学びとして、仕様駆動開発（SDD）も銀の弾丸ではなく、AIエージェントにどこまで自走力を求めるかによって使う・使わないを選ぶべきだということが分かりました。
参考
関連リンク
この記事はRecoChoku Engineering Blogの記事を転載したものとなります。