VibeCodingが更に進化！？GitHubが開発したSpec駆動開発ツールSpec KitでToDoアプリを作ってみた

summary

2025年9月にGitHubからSpec駆動開発（Spec-Driven Development）を支援するためのツールであるSpec Kitがオープンソースでリリースされました。今回はこれを使って開発を行い簡単なToDoアプリを作ってみました

出来たもの

まずは、出来たものを見せたいと思います。以下のようなToDoアプリを2-3時間程度で作ることが出来ました。ソースコードもhttps://github.com/serverless-operations/todo-app-using-spec-kitに上がっているので興味があれば参考にしてみてください。

VibeCodingが抱えている課題とは？

Claude Codeなどの登場によって新たにAIを使ったプログラミングのアプローチであるVibeCodingが流行っています。これは大規模言語モデルを作って自然言語で作りたいものをAIに指示することでAIに実装を行ってもらうアプローチです。

ある程度簡単に作りたいものが簡単に形にできてしまう一方で成果物に対するメンテナンス性やセキュリティなどの品質面で課題を抱えてしまうデメリットがあります。AIが自動に作ってしまうためにソースコードとしてはメンテナンス性の低いものになってしまったり、セキュリティに考慮されていない実装となってしまったり、しっかりと人間がソースに対してチェックをすることに時間を割く必要があります。

Spec駆動開発が解決したもの

Spec駆動開発はこのVibeCodingの手法にちゃんとした仕様書とそれを元にタスクを定義するフローを差し込むためのツールです。これによってより人間の意図を細かく反映した高品質なコードをAIで作ることが可能になります。当たり前といえば当たり前の手法です。人間の世界のコーディングでも仕様書は必要になるので、まあ、必要だよねというフローです。VibeCodingをやる際にもしっかりとCLAUDE.mdなどで仕様をまとめて、より品質の高いコードにするアプローチは取られていましたがこれをより体系化したツールと考えるのが良いでしょう。

Spec Kitが提供しているもの

現在、Spec KitはClaude Code, GitHub Copilot, Gemini CLIに対応していますがこれらに対して仕様書作成のフェーズを差し込んでくれるコマンドを提供してくれます。具体的には以下のとおりです

/specify: 何を作りたいかを自然言語で入力するコマンドです。何をなぜ作りたいのかを描くことで、spec.mdというファイルを作ります。その中にはそのアプリのシナリオ、必須の機能や大まかなタスクが生成されます
/plan: 使用したい技術スタックを入力します。「TypeScriptベースで、フロントエンドはReact Router V7, バックエンドのAPIにはExpress.js, データベースはSQLiteを使います」といった形で入力します
/tasks: tasks.mdという詳細なタスクリストを生成してくれます。これを元にAIにコーディングを実施してもらいます。

実際のSpec Kitを使ったToDOアプリ開発フロー

/specify

今回はClaude Codeを選択して以下のような仕様を/specifyに入力しました。

# 作りたいもの
ToDo管理アプリを作りたいです。私はよくやることを忘れてしまうのでそれを書き留めておける軽量なToDoアプリがほしいです。
# 必要なもの
## 1. タスク一覧画面（List View）
- 登録されたタスクを一覧表示する。
- 各タスクには以下の情報を表示すること。
- 期限（Deadline）
- 内容（Content）
- 各タスクに対して以下の操作を行える。
- 削除ボタン（ゴミ箱アイコン）: 押下するとタスクを削除する。
- 編集ボタン（鉛筆アイコン）：編集画面に遷移し、タスク内容を変更できる。
- 完了ボダン（完了ボタン）：ステータスが完了へ変更して、完了タスク一覧へ移動する
## 2. タスク登録画面（Registration View）
- 新規タスクを登録できる。
- 登録項目は以下とする。
- 内容（必須）
- 期限（必須）
- 入力後、登録ボタンで保存し、一覧画面へ戻る。
## 3. タスク編集画面（Edit View）
- 既存タスクの情報を編集できる。
- 編集可能項目は以下とする。
- 内容
- 期限
- 保存後、一覧画面へ戻る。
## 4. 完了タスク一覧画面
- 完了したタスクの一覧が表示される
- 表示項目は以下とする
- 内容
- 期限
## 非機能要件
- 認証・認可機能は不要。
- 利用環境は利用者のローカル PC 上のみを想定する。

すると以下のようなspec.mdファイルを生成してくれます（一部抜粋）。これは完成形なのですが、まずはこのファイルをチェックして完成させることが重要です。[NEEDS CLARIFICATION]というマーカーが出てくるのですが、これが開発にあたって懸念点となることをSpeck Kitが提案してくれます。例えば以下のような形です。

- FR-013: System MUST handle task persistence [NEEDS CLARIFICATION: persistence method not specified - browser storage, local file, database?]
- FR-014: System MUST display deadlines in [NEEDS CLARIFICATION: date format not specified - MM/DD/YYYY, DD/MM/YYYY, relative dates?]

これらの質問に回答して[NEEDS CLARIFICATION]をすべてクリアにします。

# Feature Specification: TODO Task Management System
## User Scenarios & Testing
### Primary User Story
As a user, I want to manage my daily tasks with deadlines so that I can track what needs to be done and what has been completed. I need to create tasks with content and deadlines, edit them when plans change, mark them as complete when finished, and review my completed work.
### Acceptance Scenarios
1. Given the user is on the task list view, When they click the add task button, Then they are taken to the registration view where they can enter task content and deadline
2. Given a task exists in the list, When the user clicks the edit button (pencil icon), Then they can modify the task's content and deadline
3. Given a task exists in the list, When the user clicks the complete button, Then the task status changes to complete and moves to the completed tasks list
4. Given a task exists in the list, When the user clicks the delete button (trash icon), Then the task is removed from the system
5. Given the user is on the task list view, When they click the completed tasks link, Then they see all tasks marked as complete
6. Given the user is entering a new task, When they submit without content or deadline, Then an error message indicates the missing required fields
### Edge Cases
- What happens when a user tries to submit an empty task form? → System displays validation errors for required fields
- How does system handle invalid date formats for deadlines? → System validates date input and shows appropriate error message
- What happens when user tries to edit a non-existent task? → System shows error and redirects to task list
- How are tasks sorted in the list view? → Tasks are sorted by deadline (earliest deadline first)
## Requirements
### Functional Requirements
- FR-001: System MUST display a list view showing all active (non-completed) tasks
- FR-002: Each task in the list MUST display its content and deadline
- FR-002a: Tasks with deadlines within 3 days MUST display with yellow highlighting and a warning message (e.g., "期限が近づいています")
- FR-002b: Tasks with overdue deadlines MUST display with red highlighting and an alert message (e.g., "期限を過ぎています")
- FR-003: System MUST provide a link/button to navigate to the completed tasks view
- FR-004: Each task MUST have a delete button (trash icon) that removes the task from the system
- FR-005: Each task MUST have an edit button (pencil icon) that navigates to the edit view
- FR-006: Each task MUST have a complete button that changes task status to completed
- FR-007: System MUST provide a registration view for creating new tasks
- FR-008: Task registration MUST require content (mandatory field)
- FR-009: Task registration MUST require deadline (mandatory field)
- FR-010: After successful task registration, system MUST return user to the list view
- FR-011: System MUST provide an edit view for modifying existing tasks
- FR-012: Edit view MUST allow modification of task content
- FR-013: Edit view MUST allow modification of task deadline
- FR-014: After saving edits, system MUST return user to the list view
- FR-015: System MUST provide a completed tasks view showing all tasks marked as complete
### Non-Functional Requirements
- NFR-001: System MUST NOT require user authentication or authorization
- NFR-002: System MUST operate entirely on local PC without external dependencies
- NFR-003: System MUST provide immediate feedback for user actions (delete, complete, save)
### Key Entities
- Task: Represents a user's todo item with the following attributes:
- Content: The description of what needs to be done
- Deadline: The date by which the task should be completed
- Status: Current state of the task (active or completed)
- Unique identifier: System-generated ID for edit/delete operations
- 作成日時: タスクが作成された日時（YYYY年MM月DD日 HH:mm形式）
- 完了日時: タスクが完了とマークされた日時（YYYY年MM月DD日 HH:mm形式）
---
## Review & Acceptance Checklist
### Content Quality
- [x] No implementation details (languages, frameworks, APIs)
- [x] Focused on user value and business needs
- [x] Written for non-technical stakeholders
- [x] All mandatory sections completed
### Requirement Completeness
- [x] No [NEEDS CLARIFICATION] markers remain
- [x] Requirements are testable and unambiguous
- [x] Success criteria are measurable
- [x] Scope is clearly bounded
- [x] Dependencies and assumptions identified

/plan

TypeScriptベースで、フロントエンドはReact Router V7, バックエンドのAPIにはExpress.js, データベースはSQLiteを使います。テストはViTestを使って と入力しました。すると以下のファイルを生成してくれます

plan.md: アプリ開発の全体設計・進め方を標準化した手順書です。「どのフェーズで何を作り、どこまでやるか」を明確にします。言語、フレームワーク、DB、テストツールからテストファーストで開発を進めていきましょうなど、開発の原則や制約を定義しています
data-model.md: コアとなるデータモデルの全てを定義したファイルです。TypeScript及びデータベースのデータスキーマ、入力チェックのルール、レスポンスデータのデータフォーマットなどを定義してくれます
contracts/openapi.yaml: Swagger形式のAPIの定義ファイルです
quickstart.md: 開発者や利用者がこの TODO タスク管理アプリをすぐに動かせるように、インストール手順・実行方法・テスト方法をまとめたドキュメントです。インストール方法やアプリの実行方法やテストの方法など。通常のOSSのREADME.mdに描くような内容が記載されます
research.md: 実装する前に、どの技術を採用するか・なぜその技術を選んだか・代替案は何だったかを体系的にまとめた設計判断の記録です。特にこちらの指示なく採用されている技術についてはチェックしましょう

これらのファイルにも[NEEDS CLARIFICATION]のマーカーが出てくる場合がありますので、内容をチェックして懸念事項を解決します。

/tasks

/planで生成したファイルが完成したら、このコマンドを実行します。そして、以下のタスクリストであるtasks.mdを生成してくれます

## Phase 3.1: Setup
- [ ] T001 Create project structure with backend/ and frontend/ directories
- [ ] T002 Initialize backend TypeScript project with Express.js, SQLite3, and CORS dependencies
- [ ] T003 Initialize frontend React project with React Router v7 and Vite
- [ ] T004 [P] Configure ESLint and Prettier for backend in backend/.eslintrc.json
- [ ] T005 [P] Configure ESLint and Prettier for frontend in frontend/.eslintrc.json
- [ ] T006 [P] Setup Vitest configuration for backend in backend/vitest.config.ts
- [ ] T007 [P] Setup Vitest configuration for frontend in frontend/vitest.config.ts
- [ ] T008 Create shared TypeScript types in backend/src/types/task.ts
## Phase 3.2: Tests First (TDD) ⚠️ MUST COMPLETE BEFORE 3.3
CRITICAL: These tests MUST be written and MUST FAIL before ANY implementation
### Contract Tests (Backend API)
- [ ] T009 [P] Contract test GET /api/tasks in backend/tests/contract/tasks.get.test.ts
- [ ] T010 [P] Contract test POST /api/tasks in backend/tests/contract/tasks.post.test.ts
- [ ] T011 [P] Contract test GET /api/tasks/completed in backend/tests/contract/tasks.completed.test.ts
- [ ] T012 [P] Contract test GET /api/tasks/:id in backend/tests/contract/tasks.id.get.test.ts
- [ ] T013 [P] Contract test PUT /api/tasks/:id in backend/tests/contract/tasks.id.put.test.ts
- [ ] T014 [P] Contract test DELETE /api/tasks/:id in backend/tests/contract/tasks.id.delete.test.ts
- [ ] T015 [P] Contract test PATCH /api/tasks/:id/complete in backend/tests/contract/tasks.complete.test.ts
### Integration Tests
- [ ] T016 [P] Integration test: Create and retrieve task flow in backend/tests/integration/task-crud.test.ts
- [ ] T017 [P] Integration test: Complete task workflow in backend/tests/integration/task-complete.test.ts
- [ ] T018 [P] Integration test: Task validation errors in backend/tests/integration/task-validation.test.ts
- [ ] T019 [P] Integration test: Japanese date formatting in backend/tests/integration/date-format.test.ts
## Phase 3.3: Core Implementation (ONLY after tests are failing)
### Backend Implementation
#### Database & Models
- [ ] T020 Create SQLite database initialization script in backend/src/db/init.ts
- [ ] T021 [P] Create Task model with Zod validation in backend/src/models/task.model.ts
- [ ] T022 [P] Create date formatter utility for Japanese format in backend/src/utils/date-formatter.ts
#### Service Layer
- [ ] T023 Create TaskService with CRUD operations in backend/src/services/task.service.ts
- [ ] T024 [P] Create error handling middleware in backend/src/middleware/error-handler.ts
- [ ] T025 [P] Create CORS middleware configuration in backend/src/middleware/cors.ts
- [ ] T026 [P] Create request validation middleware in backend/src/middleware/validator.ts
- [ ] T027 [P] Create logging service with Winston in backend/src/services/logger.service.ts
#### API Routes
- [ ] T028 Implement GET /api/tasks route in backend/src/routes/tasks.routes.ts
- [ ] T029 Implement POST /api/tasks route in backend/src/routes/tasks.routes.ts (same file as T028)
- [ ] T030 Implement GET /api/tasks/completed route in backend/src/routes/tasks.routes.ts (same file as T028)
- [ ] T031 Implement GET /api/tasks/:id route in backend/src/routes/tasks.routes.ts (same file as T028)
- [ ] T032 Implement PUT /api/tasks/:id route in backend/src/routes/tasks.routes.ts (same file as T028)
- [ ] T033 Implement DELETE /api/tasks/:id route in backend/src/routes/tasks.routes.ts (same file as T028)
- [ ] T034 Implement PATCH /api/tasks/:id/complete route in backend/src/routes/tasks.routes.ts (same file as T028)
#### Express App Setup
- [ ] T035 Create Express app with middleware setup in backend/src/app.ts
- [ ] T036 Create server entry point in backend/src/server.ts
### Frontend Implementation
#### API Client & Services
- [ ] T037 [P] Create API client with axios in frontend/src/services/api.client.ts
- [ ] T038 [P] Create TaskService for API calls in frontend/src/services/task.service.ts
- [ ] T039 [P] Setup React Query provider in frontend/src/providers/query-provider.tsx
#### React Components
- [ ] T040 [P] Create TaskList component in frontend/src/components/TaskList.tsx
- [ ] T041 [P] Create TaskItem component in frontend/src/components/TaskItem.tsx
- [ ] T042 [P] Create TaskForm component in frontend/src/components/TaskForm.tsx
- [ ] T043 [P] Create CompletedTaskList component in frontend/src/components/CompletedTaskList.tsx
#### Pages & Routing
- [ ] T044 Create TaskListPage in frontend/src/pages/TaskListPage.tsx
- [ ] T045 Create AddTaskPage in frontend/src/pages/AddTaskPage.tsx
- [ ] T046 Create EditTaskPage in frontend/src/pages/EditTaskPage.tsx
- [ ] T047 Create CompletedTasksPage in frontend/src/pages/CompletedTasksPage.tsx
- [ ] T048 Setup React Router v7 routes in frontend/src/App.tsx
#### Custom Hooks
- [ ] T049 [P] Create useTasks hook with React Query in frontend/src/hooks/useTasks.ts
- [ ] T050 [P] Create useTask hook for single task in frontend/src/hooks/useTask.ts
- [ ] T051 [P] Create useTaskMutations hook for CRUD operations in frontend/src/hooks/useTaskMutations.ts
## Phase 3.4: Integration
- [ ] T052 Connect all backend routes to Express app
- [ ] T053 Setup database initialization on server start
- [ ] T054 Configure production build scripts in both package.json files
- [ ] T055 Create root package.json with dev/build/start scripts
- [ ] T056 Test full application flow with sample data
## Phase 3.5: Polish
- [ ] T057 [P] Unit tests for TaskService in backend/tests/unit/task.service.test.ts
- [ ] T058 [P] Unit tests for date formatter in backend/tests/unit/date-formatter.test.ts
- [ ] T059 [P] Unit tests for React components in frontend/tests/components/
- [ ] T060 [P] Performance test: Verify <100ms response times
- [ ] T061 [P] Create API documentation in docs/api.md
- [ ] T062 [P] Update README.md with setup instructions
- [ ] T063 End-to-end test using quickstart.md scenarios
- [ ] T064 Code cleanup: Remove duplication and optimize imports

これでコーディングの準備は完了です。コーディングエージェントに開発を始めてください。各タスクに入る前にタスクの番号を宣言してほしい。完了したらチェックを付けていって　と指示を出して開発を開始してもらいました。

AIによる実装の流れ

後は通常のVibeCodingと同じ流れです。しっかりとタスクをこなすとタスクリストにチェックを付けていってくれることがわかります。

そしてテストファーストでの開発を行うという宣言通りまずはテストコードを書きながら開発を進めてくれています。

バックエンドの開発が終わるとテストを回して、テストが落ちたところは修正を実施、最終的にはcurlを使って動作確認をして問題ないことまでチェックしてくれます

そしてフロントエンドの実装とバックエンドのつなぎこみを行ってローカルサーバーを立ち上げてくれました。開発完了です。

画面を見てみましょう。めっちゃCorsエラー出てる。。指示したのに。。

というわけで、Corsエラー修正の指示をだして無事開発完了です。

まとめ

しっかりと仕様をまとめてコーディングを行えたおかげで、通常のVibeCodingに比べるとかなり手戻りの量が減って早く実装が終わったという感触です。（これ人間がコーディングする場合でも全く同じですが笑）しかし、AIによるコーディングの根本的な課題感が大きく解決したわけではないのかなとも感じました。プロダクション環境でメンテナンスしていくコードの作りや仕組みは設計思想に基づいて詳細まで管理されていくべきですし、AIが書いたコードを読んで合理的なものになっているのかを判断するのにも時間がかかりました。当然、使いこなすにはシニアレベルのスキルが必要になるでしょうし、エンジニアの仕事の質は変われども量は減らないというのが一番感じた部分です。

とはいえ、まだまだ黎明期のアプローチでもありますので今後これが業界にどのような影響を与えていくのは非常に楽しみです。ちょっとネガディブな感想を書いてしまいましたが、僕自身はAIによるコーディングを多面的に見た時にポジティブに捉えられる部分もたくさんあると考えています。特にプロトタイプを作るケースにおいては大きな効率化が図れますし、ビジネスの進め方にはすでにポジティブな影響が出ているでしょう。初学者の方がAIエージェントで個人開発をして全く売れないアプリをつくるというのも経験としてすごく良いことだと思います。

いろんな側面からAIによるコーディングに関わりながら今後も良い付き合い方を模索していきたいなと感じました。