AI 駆動開発ほど「仕様」が効く理由

AI にコードを書かせる開発で最初にぶつかる壁は、コードの書けなさではなく「何を作るかが曖昧なまま実装が進む」ことです。Claude Code や Cursor は指示された範囲を高速で形にしますが、指示が曖昧なら曖昧なまま、それらしい実装を作り上げてしまいます。レビューの段階で「そもそも作るものが違った」と気づき、作り直しになる。これが AI 駆動開発で最も多い手戻りの原因です。

先に結論を述べると、AI 駆動開発で品質と速度を両立させる鍵は、仕様 (spec) を一次情報として固定し、その仕様から実装・テスト・レビューを駆動すること にあります。これが本記事で扱う仕様駆動開発です。人間がコードを書いていた時代は、仕様が多少曖昧でも実装者が文脈を補って帳尻を合わせていました。ところが AI は文脈の暗黙の補完をしないか、しても勝手な前提で補ってしまう。だからこそ、人間時代より厳密に「何を作るか」を言語化しておく価値が跳ね上がります。

AI 駆動開発そのものの全体像は AI 駆動開発とは？従来開発との違い・進め方 で解説しているので、本記事では「仕様を起点に AI へ実装を委ねる」具体的な進め方に絞って掘り下げます。

仕様駆動開発とは — vibe coding・AI 駆動 TDD との違い

仕様駆動開発 (spec driven development) は、仕様を人間と AI が共有する一次情報として扱い、その仕様から実装とテストを導く開発スタイルです。仕様は「あとで読む資料」ではなく「実装を駆動する入力」であり、変更が起きるたびに仕様を更新し、仕様・テスト・実装を常に同期させます。

近い言葉と並べると位置づけがはっきりします。

アプローチ起点になるもの向く場面弱点
vibe coding思いつき・対話探索・プロトタイプ後から何を作ったか分からなくなる
AI 駆動 TDD失敗するテスト機能単位の堅実な実装テストの上位にある「何を作るか」は曖昧なまま
仕様駆動開発仕様 (spec)中〜大規模・長期運用仕様を書く初期コストがかかる

これらは排他的ではなく層になっています。仕様駆動開発が「何を作るか」を固め、AI 駆動 TDD がその仕様を「失敗するテスト」へ翻訳し、実装で Green にする。vibe coding は要件が固まる前の探索で動くものを作る局面で使い、確定したら仕様へ昇格させます。AI 駆動 TDD の具体的なループは AI 駆動 TDD — テストを AI に先に書かせる開発フロー で詳述しているので、本記事はその一段上の「仕様」を扱います。

vibe coding をそのまま本番投入したときに何が起きるかは vibe coding を本番投入する前のレビュー観点 で整理しました。探索で作ったものを仕様へ昇格させずに本番へ流すと、まさにこの記事で挙げた事故が起きます。仕様駆動はその対極で、最初に「何を作るか」を確定させてから AI に手綱を渡します。

spec を一次情報にするドキュメント設計

仕様駆動開発の成否は、仕様の書き方でほぼ決まります。重要なのは、AI が読んで実装でき、人間がレビューで参照でき、変更履歴を Git で追える形にすることです。FIXIT では仕様をリポジトリ内の Markdown としてコードと同じ場所に置き、機能単位のディレクトリに spec.md を配置しています。チャットや会議の口頭合意に仕様を閉じ込めないことが、最初にして最大の原則です。

仕様に書くべき要素は大きく 3 つに分かれます。

ひとつ目は要件です。この機能が解決する課題、対象ユーザー、想定する利用シーンを書きます。ここが抜けると、AI は技術的には正しいが目的に合わない実装を作りがちです。「ログイン機能を作る」ではなく「既存会員がメールアドレスとパスワードでログインでき、5 回連続で失敗したらアカウントを 15 分ロックする」まで具体化します。

ふたつ目は受け入れ条件です。仕様駆動開発で最も重要な部分で、「この条件を満たせば完成」と言える観測可能な振る舞いを箇条書きで列挙します。受け入れ条件は後でそのままテストになるため、曖昧語を避けて「〜のとき、〜になる」の形で書きます。たとえば「パスワードが 8 文字未満のとき、登録は失敗し、エラーメッセージを表示する」のように、入力・条件・期待結果が揃った文にします。

みっつ目は非機能要件と制約です。性能の目安、扱うデータの上限、使用してよいライブラリやアーキテクチャの制約、既存システムとの境界を書きます。AI は明示しなければ平気で新しい依存を増やしたり、既存の規約を無視した書き方をします。制約を仕様に書いておくと、その範囲内で実装を組み立てさせられます。

仕様は最初から完璧を目指さず、要件と受け入れ条件を骨組みとして先に置き、実装しながら判明した前提を追記していく運用が現実的です。ただし「実装が先に進んで仕様が後追いで陳腐化する」状態だけは避けます。仕様の更新を実装と同じ Pull Request に含めるルールにすると、この陳腐化を構造的に防げます。

Claude Code / Cursor に spec を読み込ませる実装フロー

仕様が整ったら、AI に実装を委ねます。FIXIT で回している基本フローは次のとおりです。

flowchart LR
  SPEC["仕様 (spec)<br/>要件・受け入れ条件・制約<br/>(人間が確定)"]
  TEST["受け入れ条件をテスト化<br/>(AI 生成 → 人間レビュー)"]
  IMPL["実装<br/>(AI 生成 → 人間レビュー)"]
  REV["仕様との差分レビュー<br/>(人間)"]
  CI["CI: 仕様由来テスト全通過"]
  SPEC --> TEST --> IMPL --> REV --> CI
  CI -- 仕様変更あり --> SPEC

実務での進め方を順に説明します。

まず仕様をリポジトリに置き、CLAUDE.md やルールファイルから参照できるようにします。Claude Code なら CLAUDE.md に「機能の仕様は各ディレクトリの spec.md を一次情報とすること」と書いておき、Cursor なら Project Rules に同様の方針を記述します。CLAUDE.md の整え方そのものは CLAUDE.md のベストプラクティス にまとめています。

次に、実装を依頼するときの指示が肝心です。「ログイン機能を作って」ではなく「spec.md の受け入れ条件をすべて満たす実装とテストを書き、各実装が仕様のどの条件に対応するか説明して」と依頼します。仕様のどのセクションを根拠にしたかを言語化させることで、AI が仕様を読み飛ばしていないかを確認でき、仕様にない機能を勝手に足す動きも抑えられます。

仕様が長い場合は、機能単位に分割して該当ファイルだけをコンテキストに渡します。AI に「仕様全体」を一度に渡すと、関係ない箇所に引っ張られて精度が落ちます。今から実装する機能の仕様セクションに絞ると、受け入れ条件への追従が安定します。

実装と同時にテストを書かせる点も重要です。受け入れ条件は観測可能な振る舞いとして書いてあるので、それぞれをテストケースへ一対一で対応させられます。「受け入れ条件 3 に対応するテストがどれか」を AI に明示させると、条件の取りこぼしが見つけやすくなります。ここで AI 駆動 TDD のループに接続し、失敗するテストを先に書いてから実装を Green にする流れに乗せると、仕様 → テスト → 実装の鎖が一本に繋がります。

仕様と実装の差分をレビューで検知する品質ゲート

AI が高速で実装するほど、人間のレビューはコードの細部を追うより「仕様どおりか」を見る方向へ寄せた方が効きます。仕様駆動開発のレビューは、次の 3 つの問いに集約できます。

第一に、受け入れ条件をすべて満たしているか。仕様の受け入れ条件を 1 つずつ、対応するテストと実装が存在するかを確認します。条件をそのままチェックリストにして、漏れがないかを見ます。

第二に、仕様にない挙動が混入していないか。AI は親切心や推測で、仕様に書いていない機能やエラーハンドリングを付け足すことがあります。それ自体は悪くないこともありますが、仕様に書かれていない以上は誰もレビューで意図を保証できません。発見したら、仕様へ昇格させるか実装から削るかを判断します。

第三に、仕様が更新されているか。実装の過程で仕様の前提が変わったなら、同じ Pull Request で仕様も更新されているべきです。コードだけ変わって仕様が古いままなら、それは次の手戻りの種です。

これらを人手の善意に頼らず、機械的なゲートに落とすのが品質ゲートの考え方です。CI では仕様の受け入れ条件から導いたテストが全て通ることをマージ条件にします。Pull Request のテンプレートに「対応する仕様セクション」「受け入れ条件のチェックリスト」「仕様の変更有無」の記入欄を設け、書かれていなければレビューを始めない運用にすると、仕様駆動が形骸化しません。

よくある失敗と対策

仕様駆動開発を導入したチームがつまずく典型を、対策とともに挙げます。

仕様が実装に追い越されて陳腐化する。 最も多い失敗です。実装が先行し、仕様が「初版のまま」放置される。対策は単純で、仕様の更新を実装と同じ Pull Request に含めることをルール化し、仕様変更のない機能変更を原則認めないことです。仕様・テスト・実装を 1 つの変更単位として動かせば、三者は構造的にずれません。

受け入れ条件の粒度が荒い。 「ユーザーが快適にログインできる」のような曖昧な条件は、テストにできず、AI も人間も解釈が割れます。対策は「入力・条件・期待結果」の三点が揃った観測可能な文に書き直すこと。テストに落とせない受け入れ条件は、まだ受け入れ条件になっていないと考えます。

仕様を会話に閉じ込める。 Claude Code や Cursor のチャットの中だけで合意し、ファイルに残さないと、次のセッションで AI はその合意を知りません。対策は、合意した仕様を必ずリポジトリの Markdown に書き戻すこと。AI との対話は仕様を作る手段であって、仕様の保管場所ではありません。

仕様を厚く書きすぎて初期が重くなる。 探索段階の機能にまで網羅的な仕様を求めると、書くだけで疲れて形骸化します。対策は、探索フェーズは vibe coding で動くものを作り、確定した機能から仕様へ昇格させる段階運用にすること。すべてを仕様駆動にする必要はありません。

FIXIT の実案件での運用と効果

FIXIT では、複数人と複数の AI エージェントが並行して実装する案件ほど、仕様駆動の効果が大きいと実感しています。ある業務システムのリプレイス案件 (BtoB・中規模) では、既存システムの複雑なドメインルールを機能単位の仕様へ書き起こし、それを一次情報として Claude Code と Cursor に実装を委ねました。

効果は二方向に現れました。ひとつは手戻りの減少です。「作ってからレビューで方向性のずれが発覚する」事故が、仕様レビューを実装前に挟むことで前倒しで潰せるようになりました。もうひとつは並行作業のしやすさです。仕様が一次情報として固定されているため、複数のメンバーや AI エージェントが別々の機能を同時に進めても、互いの前提がぶつかりにくくなりました。

数値の保証はしませんが、傾向として、仕様を厚めに固めたフェーズほど後工程の手戻りが減り、結果としてプロジェクト全体の所要期間を短く抑えられています。仕様を書く初期コストは確かにかかりますが、AI が高速に実装する以上、ボトルネックは実装速度ではなく「何を作るかの確定速度」へ移ります。仕様駆動はそのボトルネックを正面から扱う方法だと考えています。

こうした仕様駆動を含む AI 駆動開発の進め方は、案件ごとに最適な型が変わります。FIXIT が提供する AI 駆動開発サービス では、仕様設計から品質ゲートの整備まで含めて伴走しています。

まとめ

AI が実装を肩代わりする時代に、開発の主導権を握り続ける手段が仕様です。仕様を一次情報として固定し、受け入れ条件をテストへ落とし、仕様と実装の差分をレビューと CI で機械的に検知する。この流れを作れば、Claude Code や Cursor に安心して実装を委ねながら、品質も速度も落とさずに進められます。仕様駆動は AI 駆動開発を堅実に回すための土台です。仕様策定を含む要件定義から運用までの工程・体制・成果物の全体像は AI 駆動開発の進め方が一目でわかる|工程・体制・成果物の全体像 で一望できます。

AI 駆動開発の進め方を相談する

仕様設計から品質ゲートの整備、Claude Code・Cursor を実プロジェクトへ組み込む進め方まで、AI 駆動開発のクリエイティブスタジオである FIXIT が伴走します。自社のプロジェクトでどう仕様駆動を始めればよいか、まずは 無料で相談 してください。