TL;DR
- AI導入で実装速度は上がる一方、仕様の曖昧さが引き起こすコストは従来以上に拡大する。
- 仕様品質は「文章量」ではなく「判断可能性」で測る――合否を機械的に判定できるかが基準。
- 要件テンプレ・受入条件・意思決定ログの3本柱を揃えると、手戻りが構造的に減る。
- 本記事はシリーズ親記事として全体像を整理し、各柱の実践は子記事で深掘りする。
はじめに――なぜ今「仕様品質」なのか
本記事は Spec-Driven Development（SDD）シリーズ の1本です。シリーズ全体の構成は親記事を参照してください。
AIコーディングアシスタントやエージェントの登場で、実装フェーズのスループットは劇的に向上しました。一方で、多くのチームが「AI に書かせたコードの手戻りが多い」という課題に直面しています。
原因の大半は 実装ではなく上流の仕様にある というのが本記事の主張です。曖昧な要求でも AI は何らかの出力を返すため、誤った前提のまま開発が進行し、結果として修正コストが膨らみます。
本テーマでは「仕様品質」を親記事として俯瞰し、以下の3つの柱で実務テンプレを深掘りするシリーズ構成を取ります。
| # | 柱 | 解決する課題 | 子記事 |
|---|---|---|---|
| 1 | 要件テンプレート | 要求の解像度不足 | Issueテンプレで要件解像度を上げる |
| 2 | 受入条件 | レビュー摩擦・合否不明確 | 受入条件を先に書くTDD実践 |
| 3 | 意思決定ログ | 合意の再燃・属人化 | 意思決定ログと証拠管理の型 |
仕様の曖昧さがAI開発で増幅される理由
「出力が出る」ことが問題を隠す
従来の開発では、仕様が曖昧だと実装者が手を止めて質問していました。AI は手を止めず、もっともらしいコードを生成します。このフィードバックループの遅延が手戻りの元凶です。
具体例を挙げます。
- 「ユーザー管理画面を作って」という指示 → AI はログイン・CRUD・権限管理まで一気に生成する
- しかし「管理者ロールは2段階か3段階か」「削除は論理削除か物理削除か」といった判断基準が仕様に書かれていなければ、AIの推測が正解である保証はない
- レビューで初めてズレに気付き、大幅な作り直しが発生する
この問題は、AI が優秀になるほど深刻化します。生成速度が上がるほど「間違った方向への進行速度」も上がるからです。
仕様品質の判定基準
仕様品質は以下の3つの観点で評価できます。
| 観点 | 質問 | 低品質の兆候 |
|---|---|---|
| 判断可能性 | この仕様で合否判定できるか？ | 「適切に」「必要に応じて」等の曖昧表現 |
| 境界明確性 | スコープの内と外が明確か？ | 「非目的（Non-Goals）」の記載がない |
| 検証可能性 | 完了条件を第三者が確認できるか？ | テストケースに落とせない受入条件 |
深掘り記事: Issueテンプレで要件解像度を上げる方法
受入条件不在がレビュー摩擦を生む
レビューが「好みの議論」になる構造
受入条件が定義されていないと、コードレビューは属人的な判断に依存します。「動いているからOK」「もっとこうした方が良い」という議論は終わりがなく、チームの意思決定速度を著しく低下させます。
AI 生成コードではこの問題がさらに顕著です。人間が書いたコードには「なぜそう書いたか」の文脈が暗黙的に共有されますが、AI の出力にはその文脈がありません。レビュアーはコードの意図を推測するところから始めなければならず、摩擦が増大します。
受入条件ファースト開発の効果
受入条件を実装前に書くことで、以下の変化が起きます。
- AI への指示精度が上がる ― 受入条件をプロンプトに含めることで、AI の出力が仕様に沿いやすくなる
- レビュー基準が明確になる ― 「受入条件を満たしているか」というYes/No判定に集約される
- テスト設計が自動化しやすくなる ― 受入条件からテストケースを機械的に導出できる
この考え方は TDD（テスト駆動開発）の発想と同じですが、テストコードではなく自然言語の受入条件をファーストクラスの成果物として扱う点が異なります。
深掘り記事: 受入条件を先に書くTDD実践
証拠のない合意は再燃する
意思決定の揮発性
プロジェクトでは日々多くの判断が行われますが、その理由が記録されないと、同じ論点が繰り返し蒸し返されます。特に AI 開発では判断の頻度が高く、「なぜこの設計にしたのか」が追跡できないケースが増えています。
AIエージェントとの対話は基本的に揮発的です。チャット履歴は残っても、構造化された意思決定記録にはなりません。この問題については なぜAIエージェントは仕様書を無視するのか でも詳しく取り上げています。
証拠基準を固定する3つの要素
意思決定の再燃を防ぐには、以下の3要素をセットで記録します。
- 判断内容 ― 何を決めたか（結論）
- 選択肢と却下理由 ― 他にどんな案があり、なぜ採用しなかったか
- 根拠となるデータ ― 判断の裏付け（ベンチマーク結果、ユーザーテスト、技術制約など）
これらを 仕様ファイルとして構造化して管理 することで、チームメンバーの入れ替わりや時間経過による文脈喪失を防げます。
深掘り記事: 意思決定ログと証拠管理の型
従来型とAI時代の仕様運用モデルの比較
仕様品質マネジメントの考え方自体は新しくありませんが、AI 開発ではその重要度と運用方法が変わります。
| 観点 | 従来型の運用 | AI時代の運用 |
|---|---|---|
| 仕様の粒度 | 概要レベルで口頭補足 | 判断可能な粒度まで明文化が必須 |
| 受入条件 | テスト工程で後付け | 実装前にファーストクラス成果物として作成 |
| レビュー基準 | レビュアーの経験に依存 | 受入条件との合否で判定 |
| 意思決定記録 | 議事録に埋もれる | 構造化されたログとして検索可能に管理 |
| フィードバック速度 | 実装者が質問して補正 | AI は質問せず進むため仕様で事前に補正 |
この比較から分かるように、AI 時代の仕様運用は「事後的な補正」から「事前的な設計」へとシフトします。
まとめ――仕様品質はAI時代のスループットの基盤
仕様品質の向上は、AI 開発の生産性を最大化するための土台です。3つの柱を段階的に導入することで、手戻りを構造的に減らせます。
次のアクション:
- まず自チームの直近の手戻り事例を1つ選び、原因が仕様側にあったか確認する
- 最も課題感が大きい柱から子記事を読んで実践に移す
シリーズ子記事:
- Issueテンプレで要件解像度を上げる方法 ― 要件の書き方を型化したい方向け
- 受入条件を先に書くTDD実践 ― レビュー摩擦を減らしたい方向け
- 意思決定ログと証拠管理の型 ― 合意の再燃を防ぎたい方向け
関連記事:
- なぜAIエージェントは「仕様書」を無視するのか？ ― SDD の全体像
- 仕様ファイルの管理術 ― Requirements/Design/Tasks の3層管理
シリーズ全体に戻る: 親記事
