AI時代における品質重視型プロジェクト運用モデルの提案（1/3）

SDD×ATDD×TDDで「仕様を守らないAI」をCIで止める

本トピックは3部構成の初回となっています。

• AI時代における品質重視型プロジェクト運用モデルの提案（1/3）（本記事）
• AI時代における品質重視型プロジェクト運用モデルの提案（2/3）
• AI時代における品質重視型プロジェクト運用モデルの提案（3/3）

今回は以下の開発手法を現実的な内容で取り入れたプロジェクト運用モデルを提案します。

• 仕様書駆動開発 (Spec Driven Development / SDD)
• 受け入れテスト駆動開発 (Acceptance Test Driven Development / ATDD)
• テスト駆動開発 (Test Driven Development / TDD)

この記事は連載の第1回です。
第2回以降で、成果物設計（Spec/Scenario/契約）と、CIでドリフトを弾くための具体的な運用指針に踏み込みます。
※SDDは深掘りしますが、ATDD/TDDは現場の技術選定に依存するため「接続点」として扱います。

伝えたいこと

• AIコーディングエージェントは開発を加速する一方、仕様充足を保証しません。
• “バイブコーディング（壁打ち）”だけで品質を担保しようとすると、手戻りが不確実になり疲弊します。
• 本モデルは、仕様（SDD）× テスト（ATDD/TDD）× ゲート（CI/レビュー/QA） を統合し、AIの逸脱が混入しない構造をつくります。
  • 特にATDD/TDDは「品質ゲート」だけでなく、AIに**仮説の余地がない“実行可能なゴール”**を与えるための加速器です。
• ポイントは「人が頑張る」ではなく、CIでドリフトを検知して弾く ことです。

想定読者とスコープ

• 対象読者：エンジニア / PdM / QA / テックリード
  （AIコーディングエージェントを日常的に使う現場）
• 目的：AIの開発速度を活かしつつ、精密なビジネスロジックの品質を落とさずにデリバリーする
• 前提：アジャイル（短い反復）で回す
• 本連載の立ち位置：
  • AIプロンプト術やツール比較が主題ではありません
  • 「運用で頑張る」ではなく 仕組み（成果物＋ゲート＋CI） で品質を守ります

背景：AI導入後に起きがちな落胆

AIコーディングエージェントが一般化して、導入から半年以上経った現場も増えました。
導入時には「自然言語で指示すれば高速に実装できる」「いわゆるバイブコーディングで爆速開発できる」と期待されがちです。

しかし、現実のAIの振る舞いはこうなりがちです。

• 仕様を守らない（都合よく解釈する／暗黙の前提を捏造する）
• それっぽい実装で穴埋めする（一見動くが境界条件や例外が抜ける）
• 壁打ち（往復）の回数が読めない（手戻りが不確実＝疲弊）
• 最後はエンジニアが手で直して「AIを使うほど疲れる」状態になる

ここで辛いのは、品質が落ちること自体というよりも、手戻りの確率と規模が読めなくなることです。
見積もりや計画、レビューの負荷も、すべてが不確実になります。

このモデルが解くこと

AIは高速に成果物を作れますが、仕様充足の保証はありません。
そこで、品質を「個人の頑張り」ではなく「仕組み」で守るために、役割分担と、AIに渡す実行可能なゴール（テスト）と、逸脱を止めるゲートを固定します。

• Spec（SDD）：AIが迷わない道しるべ（意図・境界・用語・業務ルール・決定事項）
• 受入（ATDD）：外側から見た期待（Given/When/Then）を固定（外側ゲート）
• 単体（TDD）：境界・例外・不変条件を高速に検証（内側ゲート）
• CI / レビュー / 最終QA：AIの逸脱を多層で止める（通らないものは統合しない）

このモデルの思想はシンプルです。

「AIが勘違いすることを前提に、誤った変更がマージされない構造をつくる。」

提案：品質重視型AI駆動運用モデル（全体像）

プロジェクト全体をウォーターフォール化するのではなく、スプリントの中で「チケット単位の作業」をゲート付きで標準化します。

多層ゲートで“どこで止めるか”を明確にする

• Spec（SDD）で 意図と境界を固定する
• 受入（ATDD）で 外側の期待を固定する
• 単体（TDD）で 境界/例外/不変条件を固定する
• CIで 機械的に検知できるドリフトを弾く
• レビューと最終QAは「読むべきポイント」に集中する（全部は見ない）

なぜ「SDD」が中核になるのか

AIに実装を任せるほど、仕様が曖昧だとAIは“補完”します。
補完はたいてい「最もありがちな一般解」なので、精密なビジネスルールほどズレます。

SDDの狙いは、要件を長文化することではありません。

• AIに渡す「最小の道しるべ」を作る
• 仕様の“意図・境界・用語・決定事項”を固定し、曖昧さの余地を減らす
• 後工程（受入・単体・実装）が参照できる形にする

第2回では、Specテンプレ（最小セット）と、レビューしやすい書き方を具体化します。

ATDD/TDDは「品質ゲート」以上の価値を持つ

SDDが「道しるべ」だとすると、ATDD/TDDは AIが迷わず到達できる“ゴール” です。
ここが整うと、AIは“壁打ち相手”ではなく テストを通過するまで自走する実行エンジンとして機能し始めます。

テストはAIへの指示として、最も誤解が少ない

自然言語の指示やSpecだけだと、どうしても「解釈の余地（仮説）」が残ります。
一方テストは、最終的に Pass/Failで判定されるため、AIにとって次のような性質を持ちます。

• ATDD（受入）：外側から観測できる期待（Given/When/Then）を固定し、「何ができればOKか」を明確にする
• TDD（単体）：境界・例外・不変条件を固定し、「内部の正しさ」を最小粒度で保証する

つまり「仕様を読んで推測して実装する」ではなく、「テストに通るように実装する」 という、曖昧さの少ない目標に変換できます。

“壁打ち疲れ”の正体は、フィードバックループが不確実なこと

AIとの壁打ちが辛いのは、誤りそのものというよりも、

• 何回の往復で収束するか読めない
• どの指示が効いたか再現しづらい
• 最後は人間がコードを読む/直す羽目になる

という「不確実なフィードバック」にあります。

ATDD/TDDがあると、フィードバックは会話ではなく 実行結果になります。
AIは「実装 → テスト実行 → 修正」を高速に回し、ゴール到達まで自走しやすくなります。結果として、人間が行う壁打ち（往復）は大きく減ります。

ただし「テストに通れば良い」だけでは危険

ATDD/TDDだけをゴールにすると、AIは テストを通すための最短経路に寄りやすく、意図や業務ルールが弱いと“抜け道実装”が混入します。
さらに極端な例では、AIがテスト自体を都合よく変更して「通しただけ」になるリスクもあります。

だからこそ、本モデルは次の形で統合します。

• Spec（SDD） で意図・境界・用語・業務ルールを固定する（推測の余地を減らす）
• ATDD/TDDで実行可能なゴールを置く（AIが自走できる）
• CI/レビュー/QAで“ゴールの改竄”や逸脱が混入しないように多層で止める

この「道しるべ＋ゴール＋ゲート」の組み合わせが、AI時代の“壁打ち疲れ”に対する実務的な回答になります。

役割分担（人間が見る場所を減らす設計）

AI時代に、レビューを「全部読む」で回すのは破綻しやすいです。
そこで、責務を固定して“見るべきポイント”を分けます。

• PdM：Spec（意図・境界・業務ルール）の妥当性
• QA：受入シナリオ（期待値・観測可能性・テスト観点）
• エンジニア：単体（境界/例外/不変条件）と実装の整合
• CI：参照/命名/リンク切れ/契約整合など、機械的に検査できるもの
• 最終QA：統合観点と回帰の最後の砦

これにより、AIが作った大量の差分を“人力で全部確認する”負荷を削減できます。

「ウォーターフォール回帰では？」への答え

このモデルは、工程を増やして前倒しする話ではありません。
アジャイル（スプリント／反復）をそのまま維持した上で、「1チケットの中の進め方」だけを標準化します。

• スプリント計画・デイリー・レビュー・レトロなど、反復の枠組みは変えない
• 変えるのは、着手したチケットを 「品質ゲートを通過して完了させる」ための最小フローだけ
• つまり、ウォーターフォールのように「フェーズをまたいで長期固定する」のではなく、チケット内に“ミニSDLC”を埋め込むイメージです

このため、アジャイルの利点（学習速度・短いフィードバックループ）を落とさずに、AI時代に崩れやすい品質を運用で支えられます。

• 反復は短いまま（学習速度は落とさない）
• ただしチケットは「品質ゲートを通過する」単位として扱う
• 仕様・受入・単体・実装の同期を、属人化させない

最小導入のすすめ（まず何から始めるか）

第1回では全体像に留めますが、導入順はだいたいこれが安全です。

1. Spec（SDD）の最小テンプレを決める（意図・境界・用語・業務ルール・決定事項）
2. 「受入（ATDD）」「単体（TDD）」は、いったん“接続点”だけ決めて小さく始める（AIに渡す“実行可能なゴール”を置く）
3. CIで弾くルールを最小から入れる（例：成果物間リンク切れ、命名規約、必須項目など）
4. 役割分担（PdM/QA/Eng）を固定し、レビュー観点をテンプレ化する

第3回で、CIで“ドリフト検知して弾く”ための具体例（最小セット）を出します。

まとめ

AI時代の課題は「AIが速い」ことではなく、AIの逸脱が統合されやすい構造にあります。
だからこそ、品質を「人の頑張り」ではなく、

• SDDで道しるべを固定し
• 受入・単体・CI・レビュー・最終QAの多層ゲートで止める

という、運用モデルとして解くのが有効です。

次回予告（2/3）

次回は、SDDを中心に「成果物設計」を具体化します。

• Spec（SDD）は何を書けば“道しるべ”になるのか（最小テンプレ）
• 受入シナリオ（ATDD）や契約（UI/API/DATA）とどう接続するのか
• レビュー待ち（キュー詰まり）を起こさない現実的ルール

付録：本連載での用語

• SDD：仕様（Spec）を道しるべにしてAIと人の作業を揃える考え方
• ATDD：受入基準をシナリオとして固定する
• TDD：境界・例外・不変条件を中心に単体で守る
• ドリフト：Specや契約から、実装・テストがズレていく現象