Spec Kitを用いたチーム開発：導入のきっかけと所感

2026年04月17日 15時00分更新

文● 柴田奏大／FIXER

　本記事はFIXERが提供する「cloud.config Tech Blog」に掲載された「Spec Kitを用いたチーム開発記録 - part 0 導入のきっかけと所感」を再編集したものです。

はじめに

　こんにちは。FIXERの柴田です。

　今回から数回に分けて、Spec Kitというツールを使ったチーム開発の取り組みについて書いていこうと思います。part 0 ということで、まずは「なぜSpec Kitを使い始めたのか」「どんなツールなのか」「最初に触ってみた所感」あたりを中心にお伝えできればと思います。

　開発プロセスの改善やツール導入を検討されている方の参考になれば嬉しいです。

Spec Kit とは

　Spec Kit は、GitHub が公開している Spec-Driven Development（仕様駆動開発） を実践するためのツールキットです。従来の開発ではコードが主たる成果物でしたが、Spec-Driven Development では仕様（Spec）を主たる成果物とし、AIを活用して仕様から設計・実装を体系的に生成していくというアプローチをとります。仕様の作成や曖昧さの解消、技術設計、コード生成といった各工程でAIが関与し、開発者はその出力をレビュー・判断することに集中できます。（Spec Kit は GitHub Copilot や Claude など複数のAIエージェント上で動作し、私たちのチームでは GitHub Copilot を使用しています）

　Spec Kitを用いた開発は、開発プロセスを4つのフェーズに分けて進められるのが大きな特徴です。その4つのフェーズを簡単にご紹介します。

　各フェーズの間には Clarify（明確化）というステップが用意されています。これはAIが仕様や設計の内容を読み解き、曖昧な点について対話的に質問を投げかけてくれるステップです。Clarify は一度だけでなく繰り返し実行でき、セキュリティやパフォーマンスなど特定の領域に焦点を当てて深掘りすることもできます。各フェーズの出力を次に進める前に精度を上げる仕組みが組み込まれているわけです。

　また、各フェーズにはゲート（品質チェックポイント）があり、チェックを通過しないと次に進めない設計になっています。この「段階的に精度を上げていく」というアプローチが、Spec Kit の最大の魅力だと感じています。

導入のきっかけ

　Spec Kitを導入した背景には、大きく2つの動機がありました。

1. 開発プロセスの効率化

　チーム開発を進めていく中で、仕様の認識ずれや設計段階での手戻りといった課題は、どのチームでも多かれ少なかれ経験するものだと思います。私たちのチームでも、仕様書のフォーマットがメンバーごとに微妙に異なっていたり、口頭で決まった仕様がドキュメントに反映されないまま実装に入ってしまったり、といったことがありました。

　Spec Kit のように「型」が決まっていれば、仕様の粒度やフォーマットが統一されますし、仕様 → 設計 → 実装の流れに一貫性が生まれます。これによって属人化を防ぎつつ、レビューの効率も上げられるのではないかと考えました。

2. AI活用・新技術への挑戦

　もうひとつの動機は、純粋に新しい開発手法を試してみたいという好奇心です。昨今、AIを使ったコーディング支援はかなり普及してきていますが、Spec Kit はコード生成だけでなく「仕様の壁打ち」や「設計の検証」にまでAIを活用している点がユニークです。

　AIが得意なのは、大量の情報を体系的に整理したり、パターンに基づいて漏れを指摘したりすることです。仕様策定や設計レビューの段階にAIを組み込むことで、開発フロー全体の品質を底上げできるのではないかと期待しています。

チームでの進め方

　実際にチームで Spec Kit を導入するにあたっては、いくつかのルールを設けながら段階的に進めています。ここでは、1つの機能（PBI）を開発する際の具体的な流れを、人がやることとAIがやることの棲み分けを意識してご紹介します。

Step 1. 要件の読み込み ― Specify で機能仕様書を生成する【AI + 人】

　まず、PBIごとにわかる範囲で仕様を整理し、Spec Kit の Specify コマンドに読み込ませます。公式ドキュメントでも強調されている通り、ここでは「何を（what）」と「なぜ（why）」に焦点を当て、技術スタックの選定は後回しにすることがポイントです。読み込ませる機能要件は、要件定義工程にて合意したPBIの内容や画面デザインなど、決定済みの仕様です。AIがビジネス目的、受入条件、ユースケース、バリデーションルール、例外処理などを体系的に整理し、ユーザーストーリーと紐づけた機能仕様書を生成してくれます。出力された仕様書は担当者がPBIの内容に沿っているか確認します。

Step 2. Clarify ― 仕様の曖昧さを解消する【AI → 人 → 顧客】

　AIが仕様書を読み解き、不明瞭な点について質問を投げかけてきます。ここでのポイントは、回答できるものとできないものを明確に分けることです。要件定義にて既に決定しているものは適切に回答し、まだ決定していないものは仕様調整事項として整理します。

　洗い出された未決定事項（＝仕様調整事項）は、チケット管理ツール上で各PBIの質問事項としてまとめたうえで、仕様調整会議(※)に持ち込みます。

　AIが「ここが決まっていない」と明確にしてくれるおかげで、会議で確認すべき論点が事前にクリアになり、打ち合わせの質と効率が大幅に向上すると期待しています。決定事項は仕様書にフィードバックし、次の Plan フェーズに進みます。

　仕様調整会議での決定を待つリードタイムが発生するため、基本的に仕様調整事項は開発目線での理想を提示して承諾いただく前提で開発を進めます。会議でNGが出た際は後から仕様の修正を行います。

※仕様調整会議とは？

　開発チーム側（PMOやリーダー陣）とお客様側（プロダクトオーナーや業務担当者）が参加し、開発側だけでは判断できない仕様上の未決定事項 ―― 例えば業務ルールの優先度、画面上の表示方針、特定条件での挙動など ―― を協議して意思決定するための定例の打ち合わせです。

Step 3. チームメンバーの作成した機能要件のレビュー【人】

　担当者が作成した機能仕様書について、PMOやリーダー陣がレビューを行います。モックにある項目やボタンが抜けていないか、決定済みの仕様が正しく反映されているかといった観点で確認します。問題がなければ、次の Plan 作成に進みます。

Step 4. Plan ― 技術設計を生成する【AI + 人】

　確定した仕様をもとに、AIがAPI入出力（DTO）、DBマッピング、認可ルール、エラー設計、サービス層構造などの技術設計を出力します。この際、技術標準や制約を具体的な値で記載し、抽象的な言葉ではなく具体的に伝えることがポイントです。

Step 5. Clarify ― 設計の内容を補完する【AI → 人】

　Step 2 と同様に、今度は設計に対してAIが検証の質問を投げかけます。APIの詳細、DBの整合性、認可の抜け漏れなどを確認し、回答できるところは回答して詳細設計を詰めていきます。

Step 6. チームメンバーの作成した実装プランのレビュー【人】

　担当者が作成した実装プラン（設計）について、各リーダー陣がレビューを行います。問題がなければ、実装工程に進みます。

Step 7. Tasks ― 実装タスクに分解する【AI + 人】

　設計が固まったら、AIがレイヤーごと（Controller、Service、Repository など）に実装タスクを分解してくれます。チームではこの分解結果をベースに、誰がどのタスクを担当するかを決めていきます。

Step 8. Implement ― 実装のたたき台を生成する【AI + 人】

　タスクに基づいてAIが実装コードを生成します。ただし、ここで生成されるコードはあくまで「たたき台」です。Spec Kitの出力結果を盲信せず、担当者が仕様に沿っているか、無駄なコードがないか、コーディング規約に沿っているかといった観点でレビューを行います。修正点があれば、自身で直すか Spec Kitに修正を指示します。

　このように、Spec Kitを使った開発では 「人が考え、AIが整理し、人が判断する」 というサイクルが各フェーズで繰り返されます。AIに丸投げするのではなく、あくまで人間の意思決定を支援するツールとして活用している、というのがSpec Kit開発のスタンスです。

現時点の所感

　まだ導入して間もないですが、使い始めてみた段階での率直な感想をいくつか。

良いと感じた点：

　何より、仕様策定の段階で考慮漏れに気づけるのが大きいです。Clarify のステップでAIから「この場合の挙動はどうなりますか？」と聞かれると、「あ、ここ決めてなかった」と気づくことが結構あります。今まで実装に入ってから発覚していたような問題を、上流工程で拾えるのは非常にありがたいです。

　また、フェーズが明確に分かれていることで、今自分がどの段階にいるのかがわかりやすく、チーム内での進捗共有もスムーズになりました。「今 Plan フェーズまで終わったので、次は Tasks に入ります」といった会話が自然にできるようになったのは嬉しい変化です。

　従来のAI生成コーディングでは把握できなかったインプット内容がspec(仕様)として残るため、顧客からの要望もコードから変更点を探すのではなく、固まっている仕様からどう変わるのかを判断すれば良くなり、属人化の回避につながりそうだと感じています。

課題と感じた点：

　チーム開発での導入事例がまだ少なく、ベストプラクティスが確立されていないというのが正直なところです。Spec Kit自体は非常によくできたツールですが、「チームで使うときにどう運用するのが正解か」という知見はまだ手探りの段階です。

　具体的に悩んでいる点は、同じ画面に対して複数の機能を並行開発する場合の競合問題です。例えば、ある画面の「検索機能」と「一覧表示機能」を別々のPBIとして別のメンバーが同時に Spec Kitで進めた場合、それぞれの Implement フェーズで生成されるコードが同じファイルに手を入れることになり、マージ時に競合が発生します。この問題に対する回避策やについては、まだチーム内で試行錯誤しているところです。

　また、従来の開発とは人が手を動かす箇所が異なるため、タスク管理ツールの使い方も見直しが必要となっています。