こんにちは、コアシス開発グループのfjtです！
今回は、最近注目されている開発手法である「仕様駆動開発（Spec-Driven Development）」を実際のプロジェクトで導入してみたのでその所感をお伝えします。
1. はじめに
仕様駆動開発（SDD）とは
仕様駆動開発（Spec-Driven Development）とは、AIが実行可能なレベルまで構造化された仕様書を先に作成し、それに基づいてAIに実装を任せる開発手法です。
AIを利用した開発手法であるVibe Codingの課題を解決できる可能性があるとして注目されています。
なぜ仕様駆動開発を導入しようと思ったか
弊チームもVibe Codingを取り入れてきましたが下記の課題に直面していました。
課題1: 要件や仕様を正確に実装に移せない
AIに仕様を伝えて実装してもらっても、意図した通りの実装にならないことが多々ありました。細かいニュアンスが伝わらなかったり、暗黙の前提が共有されていなかったり。
課題2: 要件定義のフォーマットが不統一
RDRA、SUDOモデリング、クラス図など、案件ごとに異なるフォーマットで要件を整理していました。AIに渡す情報の形式がバラバラだと、結果の品質もバラつきます。
課題3: AIへの細切れ指示で抜け漏れ・手戻りが発生
「まずこの機能を作って」「次はこれ」と細切れに指示を出していくと、全体を見通した設計ができず、後から「あ、ここ考慮漏れてた」となることが頻発しました。
# よくあるパターン User: ユーザー登録機能を作って AI: (実装) User: あ、メール認証も必要だった AI: (修正) User: バリデーションも追加して AI: (修正) User: やっぱり設計から見直したい...
課題4: 外部資料の要件をAIにうまく伝えられない
要件や仕様が社内Wiki、Figmaなどの外部資料にある場合、それをAIに正確に伝えるのが難しい。コピペしても文脈が抜け落ちたり、関連情報が不足したり。
課題5: 仕様書と実装の乖離
実装後に修正が入ると、仕様書や設計書を更新し忘れて、ドキュメントと実装が乖離していく問題も発生しました。
課題6: AIの実装の振れ幅が大きい
同じ機能でも、伝え方によってAIの出力が大きく変わります。再現性がなく、品質が安定しませんでした。
仕様駆動開発導入の前に試したこと
実は仕様駆動開発を導入する前に、似たようなアプローチを手動で試していました。
TDDの発想で自然言語テストケースを書く
「まず自然言語でテストケースを書いて、それに従ってAIに実装してもらう」というやり方です。
# テストケース（自然言語） - ユーザーがメールアドレスを入力して登録ボタンを押すと、仮登録される - 仮登録後、認証メールが送信される - 認証リンクをクリックすると本登録が完了する - パスワードが8文字未満だとエラーになる ... → これをAIに渡して実装してもらう
しかし、このやり方には限界がありました。
- 想定した実装にならない: テストケースだけでは設計意図が伝わらず、AIが独自解釈で実装してしまう
- 手戻りが多発: 「そうじゃないんだよな...」と修正指示を出す→また違う→結局自分で書く
- PRが巨大になる: 一度に実装すると変更が大きすぎてレビューが困難
そこで、タスクに分けて実装・PRにする仕組みも手動で導入しました。
# タスク分割（手動） - [ ] Task 1: Userエンティティの作成 - [ ] Task 2: 登録UseCaseの作成 - [ ] Task 3: メール送信機能の作成 ...
これで多少マシになりましたが、要件定義や設計のフォーマットが自己流で、毎回ゼロから考える必要がありました。
仕様駆動開発は、このような試行錯誤を体系化・標準化したものだと言えます。
2. 仕様駆動開発の導入
使用ツール
今回使用したのは cc-sdd というツールです。
セットアップは非常に簡単で、以下のコマンド1発でプロジェクトに導入できます
npx cc-sdd@latest --lang ja
これにより、.kiro/ディレクトリ配下に必要なテンプレートやルールファイルが生成されます。
基本的な考え方
- 仕様を先に書く: 実装の前に、要件・設計・タスクを構造化されたドキュメントとして作成
- 段階的にレビュー: 各フェーズでレビューを挟み、認識齟齬を早期に発見
- AIはドキュメントに従う: AIエージェントは仕様ドキュメントを読み込み、それに忠実に実装
開発フローの全体像
私たちのチームでは、JIRAと組み合わせて以下のフローで運用しています
1. 要求定義・要件定義（エンジニア＋事業部）
↓
2. ユーザーストーリー作成（JIRA）
↓
3. 要件定義資料作成（esa、必要に応じて）
↓
4. 設計タスク（JIRA）→ cc-sddで仕様策定 → PR → レビュー → マージ
↓
5. 実装タスク（JIRA）→ cc-sddで実装 → 動作確認 → PR → レビュー → マージ
↓
6. 受入試験（事業部、必要に応じて）
↓
7. リリース
ポイント: 設計PRと実装PRを分けることで、設計段階でのレビューが可能になります。実装に入る前に設計の妥当性を確認できるため、手戻りを大幅に削減できます。
cc-sddのワークフロー
Phase 1: Specification（仕様策定） ├── /kiro:spec-init → 仕様の初期化 ├── /kiro:spec-requirements → 要件定義 ├── /kiro:spec-design → 技術設計 └── /kiro:spec-tasks → 実装タスク分割 Phase 2: Implementation（実装） └── /kiro:spec-impl → タスクに従って実装 Progress Check: └── /kiro:spec-status → 進捗確認
処理フロー
┌─────────────────────────────────────────────────────────────────┐
│ Spec-Driven Development Flow │
└─────────────────────────────────────────────────────────────────┘
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ 要件定義 │ → │ 技術設計 │ → │ タスク分割 │ → │ 実装 │
│requirements│ │ design │ │ tasks │ │ impl │
└──────────┘ └──────────┘ └──────────┘ └──────────┘
↓ ↓ ↓ ↓
レビュー レビュー レビュー レビュー
(人間) (人間) (人間) (人間)
各フェーズで人間のレビューを挟むことで、認識齟齬を早期に発見できます。
3. 導入してみた感想
良かった点
要件→実装の精度が向上
仕様ドキュメントを唯一の情報源としてAIに渡すことで、意図した通りの実装が得られるようになりました。AIの実装の振れ幅が大幅に減少しました。
前述の「TDDの発想で自然言語テストケースを書く」アプローチと比較すると、手戻りが明らかに少なく、実装が想定通りでないと感じることがほとんどありません。
これは、要件だけでなく技術設計（design.md）で「どう実装するか」まで明示的に指定していることが大きいと感じています。AIに「何を作るか」だけでなく「どう作るか」も伝えることで、解釈の余地を減らしています。
フォーマットの統一
要件定義、コンポーネント設計、タスク分割という一貫したフォーマットにより、誰が書いても同じ構造の仕様書ができるようになりました。
段階的レビューで手戻り削減
要件→設計→タスクの各フェーズでレビューを挟むことで、「実装してから気づく」手戻りが減りました。
仕様と実装の一体管理
仕様ドキュメントがリポジトリ内にあるため、PRで一緒にレビューでき、実装との乖離が起きにくくなりました。
要件定義・設計段階での検討促進
実装に入る前に要件や設計を明文化するプロセスが強制されるため、「とりあえず作ってみる」ではなく、事前に十分な検討を行う習慣がつきました。曖昧な部分や考慮漏れが、実装前に発見されるようになります。
チームへの知識共有
仕様ドキュメントがPRレビューを通すフローになるため、チームメンバーが必ず確認するようになりました。これにより
- 新機能の設計意図がチーム全体に共有される
- 「この機能、誰も仕様を知らない」という属人化が防げる
- レビューを通じて設計の改善提案も得られる
AIとの壁打ちによる仕様の深掘り
仕様策定フェーズでAIと対話することによるメリットがありました。
既存コードのリバースエンジニアリング
AIが既存コードを読み解いて要件や設計を整理してくれるため、ドキュメントが不足しているレガシーコードの仕様把握が進みました。「このコード、何やってるんだっけ？」という部分が、仕様ドキュメントとして言語化されます。
仕様の抜け漏れ発見
AIと要件定義や設計を詰めていく過程で、「このケースはどうなりますか？」「この条件の場合は？」といった確認が入ります。人間だけで検討していると見落としがちなエッジケースや境界条件に気づけることが多々ありました。
難しかった点
エンジニア外との認識合わせ
仕様駆動開発の「仕様」には要件定義（requirements.md）も含まれます。つまり、要件を決める段階から事業部との認識合わせが必要になります。
しかし実際には、事業部とエンジニアで要件を固め、エンジニアがそれを仕様に落とし込む、という流れになります。
事業部 エンジニア
[要求・要件資料] [仕様駆動開発の仕様]
- PRD - requirements.md
- 企画書 - design.md
- Jiraチケット - tasks.md
↓
「これ作って」 → 「仕様に落とします」
この時点で二重管理は構造的に発生します。理想は仕様ドキュメントを唯一の情報源とすることですが、実際には
- リポジトリの内容をそのまま事業部に見せるのが難しい
- PRのレビュアーにエンジニア以外を加えるのも現実的ではない
- 事業部は慣れたツールで管理したい
といった事情があります。現状、「事業部の資料はインプット、仕様駆動開発の仕様はエンジニアの実装仕様」として役割を分けています。
変更時のフロー強制ができない
仕様駆動開発の理想は、修正や変更が必要になった時も、要件→設計→タスクの順でbreakdownしてから実装に入ることです。
理想のフロー: 仕様変更が必要 → requirements.md修正 → design.md修正 → tasks.md修正 → 実装 現実: 仕様変更が必要 → (直接実装を修正してしまう) → 仕様書との乖離発生
現状は特に技術的な縛りがないため、仕様ドキュメントを経由せずに実装から直接修正できてしまいます。急ぎの修正や小さな変更の場合、つい「後で仕様書も直そう」となり、結局更新されないケースもあり得そうです。
4. 今後の展望
Steeringの充実
プロジェクト全体の指針（Steering）をより充実させることで、AIの出力品質をさらに向上させたいと考えています。コーディング規約、アーキテクチャパターン、ドメイン知識などを蓄積していく予定です。
事業部との連携強化
前述の通り、現状は事業部の要求資料とエンジニアの仕様ドキュメントが二重管理になっています。理想は「一つの仕様書をエンジニア・非エンジニアで共有する」こと。そのための環境整備を進めていきたいと考えています。
仕様変更フローの仕組み化
変更時に仕様ドキュメントを経由せず直接実装を修正してしまう問題への対策として、PRテンプレートに「仕様変更の有無」を確認項目として追加したり、CIで仕様ドキュメントの更新有無をチェックする仕組みを検討しています。
5. まとめ
現時点で、仕様駆動開発は非常に有効なアプローチだと感じています。
- 仕様を先に書くことで、AIへの指示が明確になる
- 段階的レビューで、手戻りを早期に防止
- 仕様と実装の一体管理で、ドキュメントの陳腐化を防ぐ
一方で、非エンジニアとの連携という課題も見えてきました。これは技術的な解決だけでなく、組織的な取り組みも必要な領域だと考えています。
さいごに
ホワイトプラスでは、ビジョンやバリューに共感していただけるエンジニアを募集しています！ ネットクリーニングの「リネット」など「生活領域×テクノロジー」で事業を展開している会社です。
どんな会社か気になった方は、オウンドメディア「ホワプラSTYLE」をぜひご覧ください。 エンジニアの方向けのエントランスブック「WHITEPLUS Entrance Book for Engineer」もございます。
オンラインでカジュアル面談もできますので、ぜひお気軽にお問い合わせください！
