はじめに
Spec Kit（GitHub Spec Kit）で最初の実装まで終えると、次に待っているのは「その先」です。実装したのに思ったとおり動かない、新しい機能を足したい、実行するとエラーが出る——こうした場面は、開発を続けるかぎり必ず出てきます。
この記事は、そうした 実装後によく出会う3つの場面、すなわち（1）バグや仕様の抜けへの対応、（2）機能の追加、（3）エラーの解決を、一般的な考え方としてまとめた補足編です。個別の手順というより、「仕様駆動開発では、こういうときどう考えて動けばいいか」の勘所をつかむことを狙いにしています。
Spec Kit の基本フロー（憲法 → 仕様 → 計画 → タスク → 実装）については、本シリーズの前の記事で扱っています。この記事はその応用・運用にあたります。
この記事で分かること
- 実装したのに動かないとき、どこに立ち返ればいいか
- 新しい機能を追加するときの基本フロー（仕様が積み上がる仕組み）
- エラーが出たときの、AI を使った切り分け・修正の進め方
- AI の診断を鵜呑みにしないための、証拠（ログ）の渡し方
第1章：基本の考え方 ― 直すときも「仕様に立ち返る」
仕様駆動開発の一番の肝は、問題が起きたときにコードを場当たり的に直すのではなく、仕様やタスクに立ち返って直す ことです。
たとえば「機能は実装されたのに、画面にデータが表示されない」という不具合が起きたとします。原因を調べていくと、実は「データを登録するタスク」そのものが計画に含まれていなかった、というケースがあります。これはコードのバグというより タスクの抜け です。この場合、コードに直接データ登録処理を書き足すより、タスク（や仕様）側に不足を追加してから再実装する ほうが、仕様と実装がズレずに済みます。
「実装物」だけでなく「仕様・タスク」を正としてメンテナンスしていく、という発想が、Vibe Coding（対話だけで書き進めるスタイル）との大きな違いです。
原因が「バグ」なのか「タスク・仕様の抜け」なのか分からないときは、AI に「〇〇をするタスクはありましたか？」と尋ねると切り分けの助けになります。抜けが見つかれば、その分をタスクに追加すればよい、と判断できます。
第2章：新しい機能を追加する
機能追加は、特別なことをするわけではありません。最初に機能を作ったときと同じ流れ を、もう一度たどるだけです。
-
/speckit.specify… 追加したい機能の仕様書を作る -
/speckit.plan… 新しいテーブル設計や API を計画に反映する -
/speckit.tasks… 追加機能のためのタスクに落とし込む -
/speckit.implement… 実装する
このとき、仕様のディレクトリ（specs/）には 002-...、003-... と 番号付きで新しい仕様が積み上がっていきます。プロジェクトの仕様が履歴として残っていくイメージです。
憲法（Constitution）はプロジェクトで一度作れば十分で、機能を追加するたびに作り直す必要はありません。2つめ以降の機能は /speckit.specify から始めれば大丈夫です。
生成される仕様書や計画の中身は、1つめの機能のときと同じ構成（ユーザーストーリー、エッジケース、要求仕様、技術スタックなど）になります。技術スタックの記述などは、前に作った計画とほぼ同じ内容が引き継がれることが多いです。
なお、生成されるタスクの量は毎回同じではありません。機能の規模はもちろん、使用する AI モデル によっても変わります。一度に多くの文章を生成できるモデルほどタスクが細かく多くなり、そうでないモデルでは少なめになる傾向があります。タスク数の多少そのものは、良し悪しの指標ではないと考えておくとよいでしょう。
第3章：エラーが出たときの進め方
実装や起動でエラーが出るのは日常茶飯事です。大切なのは パニックにならず、まず AI に相談する ことです。自分でいきなり深追いするより、AI に原因を尋ねるほうが早いことが多くあります。
一番効くのは、エラーの本文をそのまま AI に渡す ことです。ターミナルに出たエラーログや、ブラウザの開発者ツール（デベロッパーツール）に出たエラーをコピーして、チャットに貼り付けて「これを直して」「原因を特定して」と伝えます。曖昧に説明するより、生のエラーメッセージを渡すほうが、AI は的確に対応できます。
進めるうえでのコツをいくつか挙げます。
- 原因の特定だけしたいときは質問用モード（Ask など）に切り替えると、コードを編集させずに診断だけしてもらえます。
- AI の診断は必ずしも正しくありません。 見当違いの原因を挙げてくることもあります。そんなときは、開発者ツールのネットワークタブなど 具体的な証拠 を追加で渡すと、正しい原因にたどり着きやすくなります。
- 簡単な修正は手動でやってしまってもかまいません。 「まず AI に聞く」のが原則ですが、設定値の書き換えなど明らかで小さな修正なら、自分で直すほうが速い場合もあります。
参考までに、この種のトラブルで実際によく見かける原因には、次のようなものがあります（いずれも環境しだいの一例です）。
- フロントエンドとバックエンドで 接続先の URL（ポート番号など）が食い違っている
- データベースなどの サービスが起動していない（コンテナを立ち上げ忘れているなど）
- 必要なデータが登録されていない（初期データ投入の抜け）
- コマンドを 間違ったディレクトリで実行している（1つ上の階層に戻る必要があるなど）
こうした原因は、エラーメッセージを AI に渡しながら一つずつ潰していけば、たいてい解決できます。
まとめ
- 不具合は、コードを場当たりで直すより 仕様・タスクに立ち返って 直す
- 「バグか、タスク・仕様の抜けか」は AI に尋ねて切り分ける
-
機能追加は
specify → plan → tasks → implementを再度たどるだけ -
憲法は一度作れば十分。2つめ以降の機能は
specifyから始める - エラーはパニックにならず、ログをそのまま AI に渡して 対処する
- AI の診断は鵜呑みにせず、具体的な証拠で裏づける／簡単な修正は手動でも可
最後に、仕様駆動開発ならではの感触に触れておきます。この手法では、仕様書に書かれたものを忠実に実装 します。裏を返すと、仕様に書いていないもの（たとえば画面間を行き来するためのナビゲーションなど）は、自動では作られません。Vibe Coding なら「良しなに」付いてくるようなものも、Spec Kit では必要なら仕様に足す必要があります。ある意味で素朴ですが、作られるものが仕様と一致している という安心感が、この開発スタイルの価値だといえるでしょう。