はじめに
Spec Kit（GitHub Spec Kit）による仕様駆動開発では、いきなりコードを書き始めるのではなく、「憲法（原則）→ 仕様 → 計画 → タスク」という順で設計を固めてから実装に入ります。その最後の工程が /speckit.implement、つまり AI にタスクを実装させるフェーズ です。
このコマンドは、直前に作った tasks.md（タスクリスト）を上から順に読み取り、コードを生成していきます。魔法のように一発で完成するわけではなく、一つずつ積み上げていく地道な工程です。この記事では、/speckit.implement が実際に何をしているのか、進めるうえで何が起きやすいのか、そして人間はどう関わればいいのかを、初めての方にも分かるように解説します。
仕様駆動開発の全体像や、憲法・仕様・計画・タスクの各工程については、本シリーズの前の記事で扱っています。この記事は最後の「実装」にあたります。
この記事で分かること
-
/speckit.implementが何をするコマンドなのか - タスクがどんな順序・仕組みで実装されていくのか
- 実装中によく起きるトラブルと、その対処の考え方
- AI に任せつつ、人間がどこを見ておくべきか
第1章：/speckit.implement は何をするのか
/speckit.implement は、tasks.md に並んだタスクを 依存関係の順に、上から一つずつ実装していく コマンドです。前工程で作った憲法・仕様・計画・データモデル・API 設計なども読み込み、それらに沿ってコードを生成します。
進み方はシンプルで、タスクを取り出し、コードを生成し、動作を確認して、完了したら次のタスクへ——という繰り返しです。
タスクが終わると、tasks.md のチェックボックスが - [ ]（未完了）から - [X]（完了）に変わっていきます。これによって、いま全体のどこまで進んだかが一目で分かります。
プロジェクトの原則（憲法）でテストやテスト駆動開発（TDD）を求めている場合は、テストのタスクも生成され、各タスクの後にテストが実行されます。逆に求めていなければ、テストは省かれます。テストを回すかどうかは、この段階で決まるのではなく、前の工程でどんな原則を定めたか で変わる、という点を覚えておくとよいでしょう。
/speckit.implement は、npm や python などのコマンドを 実際に自分のマシン上で実行 します。使う技術スタックのランタイム（Node.js や Python など）がローカルに入っているかを、事前に確認しておきましょう。
第2章：基本的な進め方
実装は、次の流れで進みます。
まず、対象の tasks.md を指定し、実装用のエージェント（speckit.implement）に切り替えて、「実装して」と指示します。プロンプトは凝る必要はなく、シンプルな指示で構いません。
すると AI がタスクを読み込み、フェーズごとに実装を進めていきます。フェーズが一つ終わるたびに「次のフェーズに進みますか？」と確認されることがあるので、問題なければ続行を指示します。まとめて進めたいときは「残りのタスクも続けて実装して」のように伝えると、連続して作業してくれます。
タスクは、次のようなフェーズ構成で並んでいるのが一般的です。
セットアップ（プロジェクト初期化）→ 基盤（すべてのユーザーストーリーに共通する土台）→ ユーザーストーリーごとの実装 → 最終フェーズ（パフォーマンスやセキュリティなど横断的な仕上げ）、という順で積み上がっていきます。基盤フェーズが完了するまでは各ユーザーストーリーに進めない、といった依存関係が組まれているため、順序どおりに進めるのが基本です。
第3章：実装中によく起きること
AI による実装は万能ではありません。特に長時間・多数のタスクを連続で回すと、途中で止まったりエラーになったりすることは珍しくありません。あらかじめ知っておくと落ち着いて対処できる、代表的なケースを挙げます。
- 実行がエラーで止まる／反応しなくなる：セッションが長くなると起きやすくなります。新しいチャットを開き、「このフェーズから再開して」と再開位置を指定して実行し直すと、通ることが多いです。
- 1タスクだけで止まってしまう：1個ずつしか進まないときは、「このフェーズをすべて実装して」のように、範囲を明示して指示します。
- タスクが飛び飛びで実装される：番号順どおりに進まないことがあります。多くの場合、残っているタスクや次に推奨されるステップが提示されるので、それに沿って進めれば問題ありません。
- 途中の生成がおかしい：不自然な変更は反映せずに取り消し（Undo）、チャットを開き直して再実行します。このとき、対象ファイルの指定やエージェントの切り替えが外れていないかを確認しましょう（コンテキストや使用エージェントがずれていると、うまく動きません）。
- 速度と精度のトレードオフ：より速いモデルに切り替えると進行は速くなりますが、生成の精度は下がりがちです。作業内容に応じて選ぶとよいでしょう。
最も大切なのは、惰性で「続けて」「続けて」と指示し続けないこと です。中身を見ずに回し続けると、どこかで止まっていたり、意図と違う実装が積み重なっていたりしても気づけません。すべてを精読する必要はありませんが、AI の応答をざっと確認し、「なぜ止まったのか」「正しく実装できているのか」を、自分がマネージャーになったつもりで見守るのが、うまく進めるコツです。
第4章：完了後に確認すること
すべてのタスクが完了すると、実装フェーズは一区切りです。ただし、完了＝完璧、ではありません。次のような点は、完走後に自分の目で確認しておくと安心です。
まず、動作の確認 です。可能であればアプリを起動して、画面が意図どおり表示されるか、主要な操作が機能するかを見ておくと、仕様と実装のズレに早めに気づけます。テストを設定していた場合は、その結果も確認しましょう。完了と表示されても、一部が期待どおりでないことはあります。
次に、表示される完了メッセージの解釈 です。たとえば「本番デプロイ準備完了」のような文言が出ることがありますが、これは必ずしもデプロイ環境が実際に用意されたことを意味しません。指示していない内容まで整ったかのように書かれる場合があるので、実際に何が行われたのかを確認する習慣をつけておきましょう。
まとめ
-
/speckit.implementはtasks.mdを依存順に上から実装するコマンドである -
タスクを実装し、確認し、完了（
- [X]）にして次へ、を繰り返す - テストを回すかどうかは、前工程で定めた原則（憲法）次第である
- エラーで止まったら「新しいチャットで再開位置を指定して再実行」が有効
- 惰性で回さず、マネージャー視点で応答を見守ることが成功のコツ
- 完了表示を鵜呑みにせず、実際の動作を自分で確認する
/speckit.implement は、仕様駆動開発の「憲法 → 仕様 → 計画 → タスク → 実装」という流れの最終ステップです。AI に丸投げするのではなく、各段階で人間が意図を確認しながら進めるのが、この開発スタイルの本質です。完全な自動化ではありませんが、あいまいさを減らしながら着実に形にできる点が、大きな魅力だといえるでしょう。