こんにちは！エンジニアの大戸です

最近、「仕様駆動開発（Spec-Driven Development、以下SDD）」というキーワードを耳にする機会が増えました。これは、仕様を中心として設計・実装計画にブレークダウンし、さらに仕様＝テストとなるようテストを作ることで、実装前後に適切なガードレールを敷く手法です。たとえばAmazonのKiroというIDEでは、構造化された仕様を起点に、AIが設計・実装・テストを段階的に進められるようになっています。他にもGitHubのSpec Kitなど、近い方向性のツールや実践例が増えており、SDDへの注目度の高さがうかがえます。私自身も「AIの活用を形式化できる」「AIへ渡すコンテキストを適切にコントロールしやすくなる」という点から、この手法に関心を持っています。

ただ、実務で導入しようとすると、話はそう単純ではありません。既存のサポートツールは優れたものが多いですが、ツールや方法論にプロジェクト側を合わせることが、かえってコストになる場合もあります。

そこで重要になるのは、SDDを闇雲に取り入れることではなく、まず「自分たちのプロジェクトでAIにどう働いてもらいたいか」を考え、それに合った形を柔軟に整えていくことだと考えています。本記事では、私が実際のプロジェクトで整備した"AI実装ワークフロー"を例に、SDDを実務に取り入れるうえでの考え方と工夫を紹介します。

対象のプロジェクトでは、仕様は既にある程度整備されている状態でした。課題は「仕様をどう用意するか」ではなく、「仕様からどう実装を進めるか」にありました。また、ほぼゼロからのシステム構築だったため、処理すべき仕様の量も、それに伴う実装量も大きくなることが見込まれていました。

こうした状況で効率良くAI活用を行うため、SDDの導入を検討しました。既存のサポートツールにはよくできたものが多く、多段階での進行や検証の仕組みも備わっています。ただ、今回はそれをそのまま使うのは難しそうだと感じました。

理由はいくつかあります。まず、既存ツールは仕様作成のサポートが充実しているものが多いですが、今回はその部分は不要でした。また、仕様の記述量が大きいため、そのままAIに渡すとコンテキストの制御が難しくなります。さらに、実装量が多いため、既存ツールの粒度よりも細かくフェーズを区切ってコントロールしたいと考えました。

既存ツールの部分的な活用も検討しましたが、仕様からのズレがないかの確認や、優先すべき実装項目の棚卸しなど、より細かいコントロールが求められました。

そこで、既存ツールの仕組みを参考にしつつ、プロジェクトの状況に合わせた粒度でAI実装ワークフローを整備することにしました。次章では、その具体的な内容を紹介します。

本章では、最終的に形になったワークフローの全体像を紹介します。本記事ではどのような考え方で作ったかに重点を置きたいため、ここでは「そういうの作ったんだ」とイメージをざっと掴んでいただける程度の説明に留めたいと思います。

ワークフローは以下の流れで進みます。

仕様 → 実装タスク化 + テスト項目作成 → 実装(簡易テスト・レビュー・バグ修正) → E2E確認

SDDの基本的な考え方——仕様を中心として設計・実装計画にブレークダウンし、さらに仕様＝テストとなるようテストを作ることで、実装前後に適切なガードレールを敷く——をベースにしています。

既存のSDDサポートツールには汎用性が高く使いやすいものが多く、こうした仕組みを簡単に導入できるようになっています。ただ、今回のプロジェクトでは仕様の規模が大きく、実装量も多いという事情がありました。既存ツールの仕組みをそのまま使うより、プロジェクトの状況に合わせてより細かい粒度でコントロールできる形にしたいと考えました。

たとえば、仕様からタスクへの分解では、段階を踏んで丁寧に分解し、途中で仕様との整合性を検証するフェーズを挟んでいます。また、実装スコープに必要なものだけに絞ることで、AIが扱うコンテキスト量を減らすようにしました。

実装フェーズでは、「実装 → テストやレビュー → 修正」のサイクルで扱う範囲をかなり小さく区切り、サブエージェントごとにコンテキストを分離しています。E2Eテストの実行や細かいバグ修正など、コンテキストが膨らみやすい作業は専用のサブエージェントに切り出します。

こうした構成を、Claude Codeのカスタムコマンドとサブエージェントを使って実現しています。カスタムコマンドで繰り返し行う作業フローを共通化し、サブエージェントで役割ごとにコンテキストを分離する形です。

ただし、この構成は最初から設計したものではありません。次章では、どのような考え方でこのワークフローを作っていったかを紹介します。

3章で紹介したワークフローは、最初から設計して作ったものではありません。まずは普通のプロンプトで1機能を実装するところから始め、繰り返しの中で少しずつ形にしていきました。

この進め方を選んだ背景には、ひとつの前提があります。それは、どれだけ仕組みを整えても、AIが完璧に動いてくれるわけではない、ということです。

仕様の読み落とし、意図しない実装方針、細かい挙動のズレ。こうしたことは、どうしても起こります。テストコードを書かせても、Playwrightで画面確認させても、すべてを検知できるわけではありません。だからこそ、実装に対する最終的な責任は人間にある、という前提を持っておくことが大事だと考えています。

これは「AIを信用しない」という意味ではありません。最近のAIの性能は高く、過剰に疑う必要はないと思います。ただ、間違う可能性がある前提で使う方が、結果的にうまくいきます。AIを「自律的に完璧にこなしてくれる存在」ではなく、「優秀だが確認が必要なメンバー」として扱うイメージです。

この前提に立つと、目指すものも変わってきます。「AIが自動で全部やってくれる完璧なワークフロー」ではなく、「人間が確認しやすく、必要に応じて介入しやすい仕組み」。そして、その仕組みを最初から作り込むのではなく、動かしながら育てていく。これが基本的なスタンスでした。

この考え方をもとに、いくつかの方針を持って進めました。

AIに100%を求めない。 期待値は体感70〜80%程度の完成度に設定し、残りは別セッションでアドリブ的に対話しながら仕上げるようにしています。最初から完璧を求めると、確認フェーズが膨らみすぎて逆に時間がかかります。

確認しやすさを優先する。 AIによる自動確認（テスト実行など）やレビューは有効ですが、やりすぎると実装完了までの時間が伸びます。それよりは、ある程度早く実装を進めて、人間が確認できる状態にしてしまう方が効率的でした。「動作確認まで時間がかかりそうだな」と思ったら、確認フェーズを省略させることもあります。

フローは最初から作り込まない。 カスタムコマンドやサブエージェントを最初に全部設計するのではなく、まずは普通のプロンプトで1機能を実装するところから始めました。うまく回る保証がない段階で時間をかけてフローを構築しても、無駄になる可能性があります。「同じ指示を繰り返しているな」と感じたらコマンド化する。「この作業とこの作業には共通点がある」と気づいたら共通コマンドにまとめてみる。「この作業は独立して進められそう」と思ったらサブエージェントでコンテキストを分離する。こうした判断を、開発を進めながら少しずつ行っていきました。コマンド化やワークフロー化は過剰になることもあるので、状況に合わせて調整することが大事です。

実際にフロー化していく場面・フローを動かしていく場面では、以下のようなことを意識しました。

タスクを細かく分割し、確認ポイントを組み込む  大きな仕様をそのままAIに渡すと、どこで何が起きているか把握しづらくなります。タスクを小さく分け、各段階で確認できるようにすることで、問題があっても早期に気づけます。

設計の基本に立ち返る  AIを活用する場合でも、基本的なUIコンポーネントやアーキテクチャ、ルーティングといった大枠は事前に固めておくべきです。当たり前のことですが、これが曖昧なままAIに渡すと、実装のたびに判断がブレてしまいます。AIに任せる範囲を明確にするためにも、まず人間が決めるべきことを決めておく。

AIの動きを監視し、柔軟に介入する。 サブエージェントへ送られるプロンプトを適宜確認し、重要な指示が落ちていないか注視します。サブエージェントの実装が遅すぎる場合は、何かに詰まっている可能性が高いので、作業を止めて自分で確認することもあります。

本記事では、SDDの考え方をベースに、プロジェクトの状況に合わせてAI実装ワークフローを整備した事例を紹介しました。

SDDというと、しっかりした仕組みを構築するイメージがあるかもしれません。ただ、実務で取り入れるうえでは、まず1つのプロンプトから始めてみること、そして少しずつ形式化していくことが、現実的な一歩になると思います。

 また、生成AIは汎用性の高いものなので、ワークフローやツールの導入に囚われるのではなく、あくまでも解決したい課題を見極め、そのためにどうAIをカスタマイズしていくかという柔軟な考え方を持つことも重要だと思います。

この記事が、SDDの導入を検討している方の参考になれば幸いです。