TL;DR
- 受入条件はレビュー後付けでは遅い。 実装前に「何をもって完了か」を定義することで、AIの出力精度が上がる。
- Exampleベースで条件を書くと、AIが生成すべきコードの方向性が明確になり、手戻りが激減する。
- Red → Green → Refactorの短サイクルがAI実装と相性が良く、1回のプロンプトで検証可能な単位に分割できる。
はじめに
AI開発で最も多い手戻りパターンは「レビューで初めて期待動作のズレが発覚する」ことです。原因はシンプルで、受入条件（Acceptance Criteria）が実装後に書かれているケースがほとんどだからです。
本記事では、受入条件を先に定義する「Acceptance First」アプローチを、AI開発のワークフローに組み込む具体的な方法を解説します。
本記事は Spec-Driven Development（SDD）シリーズ の1本です。シリーズ全体像は親記事で扱っています。 👉 AI時代の仕様品質マネジメント
受入条件を先に定義する理由
AIの「探索空間」を制約する
AIコーディングエージェントは与えられた指示から「ありえる実装パターン」を広く探索します。受入条件がないと、探索空間が広すぎて意図しない実装を返すリスクが高まります。
先に判定基準を置くことで、AIの探索空間を狭められます。具体的には、次の3つの効果があります。
- 出力の方向性が定まる -- 「何が正解か」が明確なので、AIが迷走しない
- レビューコストが下がる -- レビュアーは受入条件との照合だけで済む
- 手戻りループが短縮する -- 不合格なら条件を見せて再生成するだけ
後付けレビューとの比較
受入条件を「先に書く」場合と「後から書く」場合で、開発フローがどう変わるかを比較します。
| 観点 | 受入条件を先に定義 | レビュー時に後付け |
|---|---|---|
| AIへの指示精度 | 高い（条件が明示される） | 低い（暗黙の期待に依存） |
| レビュー所要時間 | 短い（照合のみ） | 長い（期待動作を都度確認） |
| 手戻り回数 | 平均1〜2回 | 平均3〜5回 |
| ナレッジ蓄積 | 条件がそのままテスト資産に | 散逸しやすい |
この「後付けレビュー」の問題は、コンテキスト負債の一形態でもあります。暗黙知に頼った開発は、チームの「当てる力」を低下させます。
Exampleベースの受入条件の書き方
なぜExampleベースが有効か
受入条件を「〜であること」という抽象文で書くと、解釈の余地が残ります。一方、具体的な入出力ペア（Example）で書くと、AIは「このインプットに対してこのアウトプットを返せばいい」とパターンマッチできます。
これはSDD（Spec Driven Development）の思想とも一致します。仕様を「テスト可能な形式」で定義することで、AIエージェントが仕様を無視するリスクを減らせます。
3層Example構成
受入条件は以下の3層で構成するのが実用的です。
- 正常系 -- 1〜2例。最も基本的な動作パターン
- 境界条件 -- 1〜2例。上限値・下限値・空入力など
- エラー条件 -- 1例。異常入力時の期待動作
具体例: ユーザー登録APIの受入条件
## 受入条件
### 正常系
- 入力: { name: "田中太郎", email: "[email protected]" }
- 期待: 201 Created, レスポンスに id が含まれる
### 境界条件
- 入力: { name: "a"（1文字）, email: "[email protected]" }
- 期待: 201 Created（最小長でも登録可能）
- 入力: { name: ""（空文字）, email: "[email protected]" }
- 期待: 400 Bad Request, エラーメッセージに "name" が含まれる
### エラー条件
- 入力: { name: "田中太郎", email: "invalid-email" }
- 期待: 422 Unprocessable Entity, バリデーションエラー
この形式は、Issueテンプレートで要件解像度を上げる手法と組み合わせると、Issueの中に受入条件を直接埋め込めるため、AIへのコンテキスト伝達が自然になります。
Red → Green → Refactorのサイクル
TDDの基本サイクルをAI開発に適用する手順は次のとおりです。
- Red: 受入条件をテストコードとして書く（当然失敗する）
- Green: AIにテストを渡し、「このテストを通す実装を書いて」と指示する
- Refactor: 生成されたコードを人間がレビューし、可読性・保守性を改善する
ポイントは、1回のプロンプトで検証可能なサイズに分割することです。受入条件が10個あるなら、2〜3個ずつに分けてサイクルを回す方が、一括で渡すより精度が高くなります。
運用の落とし穴と対策
条件過多による実装停止
受入条件が多すぎると、AIが「すべてを同時に満たそう」として複雑なコードを生成し、結果的に何も通らない状態になります。
対策: 1つのIssueあたり受入条件は5〜7個を上限とする。それを超える場合はIssueを分割するサインです。
抽象的な条件による解釈ブレ
「パフォーマンスが良いこと」「ユーザーにわかりやすいこと」といった条件は、AIには解釈できません。
対策: 必ず数値または具体的な入出力ペアで定義する。「レスポンスタイムが200ms以下」「エラーメッセージに原因フィールド名が含まれる」のように書く。
条件と実装判断の混同
受入条件に「Reactを使うこと」「PostgreSQLに保存すること」といった技術選定を混ぜると、AIの自由度を不必要に制約してしまいます。
対策: 受入条件は「何を満たすか（What）」に絞り、「どう実装するか（How）」は実装仕様に分離する。技術的な意思決定の記録については、意思決定ログと証拠管理の型を参照してください。
まとめ: 次のアクション
受入条件先行は、AI時代の品質担保における最短のフィードバックループです。
明日から試せるステップは次の3つです。
- 次のIssueで、実装依頼の前に受入条件を3つ書く（正常系1・境界1・エラー1）
- 条件をテストコードに変換し、AIに渡す（Red → Greenサイクル）
- 手戻り回数を記録し、Before/Afterを比較する
全体像に戻る: AI時代の仕様品質マネジメント
シリーズ全体に戻る: 親記事
