～正を分けず、渡す単位を小さく保つ～
筆者
こんにちは、ゼンリンデータコムの亀井です。開発部門の経歴が長く、現在は品質部門に在籍しています。本業以外にKiroを使ったSPEC駆動開発の社内推進メンバーとして、各案件の相談対応にあたっています。
■はじめに
SPEC駆動開発を実験的に導入する方が増えてきていると思います。現場でも、新規案件への導入が進んでいます。要件定義書から検証設計書までを生成AIの力を借りて進められ、うまくいけば工数圧縮も期待できます。
SPECが正として整備が漏れなく進むことで、検証漏れの防止にもつながると感じています。工数削減と品質のいいとこどりができるなら、案件としても魅力は大きいです。私もそこに大きな期待を持っています。
ただ、試し始めると現場では別のしんどさも見えてきます。同じ要件を渡しているはずなのに、再生成のたびに画面の見え方や実装の抜けが変わり、レビューのたびに「前回と何が違うのか」を追う負荷が増える。文書が肥大化すると、その先の設計・実装の出力も一段と不安定になります。
こうしたブレは、再現性の低さとして品質にも直結します。同じSPECから同じ振る舞いを安定して生成できなければ、手戻りや説明コストが増え、せっかくの工数圧縮効果も打ち消されてしまいます。本稿では、再現性を担保したSPEC駆動開発にするにはどうすればよいかを整理します。
※生成AIを利用してイラストを作成
扱う問題は次の3つです。
- 正の分裂（二重管理と再現性）
- 長文の要件定義書による有効仕様のズレ
- 巨大な design.md による有効仕様のズレ
先に、本稿で使う用語だけ示します。
- 有効仕様 原本のSPECそのものではなく、生成AIが要約・解釈・取捨選択したうえで生成するために実際に使う仕様のことです。
- EARS 要件を「いつ／どの状態で／何をするか」の型に載せて書く記法で、曖昧さを減らしやすい特徴があります。KiroではEARSが採用・推奨されやすいです。
- SPEC 本稿では次の位置づけとします。要件定義書には書き方の違いとして、顧客確認用（従来版）と内部用（EARS版）があり得ます。
SPEC
├ 要件定義書
│ ├ 顧客確認用（従来版）
│ └ 内部用（EARS版）
├ API仕様
├ DB仕様
└ 画面仕様
■問題１：正の分裂（二重管理と再現性）
問題１で扱うのは、再現すべき仕様の「正」が途中で分かれてしまうことです。この問題には次の2面があります。一見別物に見えますが、根は同じです。
- 文書管理側：顧客確認用（従来版）と内部用（EARS版）の二重管理による認識ズレ
- 生成AI側：原本の要件定義書から有効仕様へ変換される過程での再現性の崩れ
文書管理側：二重管理による認識ズレ（顧客確認との分岐）
内部用（EARS版）は、解釈ブレを抑える目的では有効でも、顧客確認用（従来版）の代わりにはほぼ使えません。その結果、内部用（EARS版）と顧客確認用（従来版）の二重管理になり、更新タイミングや表現の差から認識ズレが生まれます。
生成AI側：再現性の崩れ（生成AIへの変換）
もう一方の面の中心は「再現性」です。同じSPECから同じ振る舞いを安定して生成することです。その前提が、原本の要件定義書と有効仕様がずれないこと、すなわち有効仕様の安定です。
本稿では再現性のうち、この有効仕様の安定に絞って扱います。内部用（EARS版）は、条件や例外を型に載せて要件の曖昧さを減らす点で、有効仕様のブレの一因を抑えることに寄与し得ます。ただし、長い文書の要約や取捨選択までは解けず、認識ズレがゼロになるわけでもありません。
■対策１：顧客確認用（従来版）を唯一の正にする
対策は単純です。内部用（EARS版）へ変換せず、顧客確認用（従来版）を唯一の正として、そのまま生成AIへ渡してコード化することです。
顧客確認用（従来版） → 生成AI → コード
これにより、顧客確認用（従来版）と内部用（EARS版）の二重管理をなくし、文書管理側で「正」が増えることを防ぎます。不足する厳密さは内部用（EARS版）へ逃がすのではなく、顧客確認用（従来版）の側で埋めます。
経路を比べると、ズレは成果物そのものではなく、確認・変換の切れ目で起きます。
顧客確認用（従来版）
└ (A) 顧客合意とのズレ（確認不足・別資料化）
→ 生成AI
└ (B) 有効仕様のズレ
→ コード
顧客確認用（従来版）
└ (A) 顧客合意とのズレ（確認不足・別資料化）
→ 生成AI
└ (B) 有効仕様のズレ
→ 内部用（EARS版）へ変換
└ (C) レビュー漏れ・整合漏れ・推論による誤仕様の固定
→ 生成AI
└ (D) 有効仕様のズレ
→ コード
内部用（EARS版）を挟む後者は (C)(D) が増え、正が分かれやすくなります。だから後者は採りません。一方、前者を選んでも (A)(B) は残ります。残るズレ、とくに長文の要件定義書に起因する有効仕様のズレへの抑え方は、次の問題２以降で整理します。
■問題２：長文の要件定義書による有効仕様のズレ
対策１で内部用（EARS版）への変換をやめても、(B) の有効仕様のズレは残ります。SPEC駆動ではAIの補完余地を減らすために要件を緻密化するため、顧客確認用（従来版）の文字量は増えがちです。
生成AIは長い入力を要約・解釈・取捨選択してから実装に使うことが多く、原本の要件定義書と有効仕様の間にズレが生まれやすくなります。つまり、顧客確認用（従来版）を唯一の正にしても、一度に渡す量が多すぎると正が薄まるのが問題２です。
分割前の例：
SPEC
└ requirements.md … 4000行
■対策２：ファイル分割と目次で参照範囲を限定する
対策は、顧客確認用（従来版）を巨大な1ファイルのまま渡さないことです。
- 機能単位・画面単位でファイル分割する … 1回の生成で参照する範囲を小さくする
- 目次（または要件ID一覧）で全体構造を保つ … 分割しても生成時に抜け漏れや関連を追えるようにする
- 生成指示で参照ファイルを明示する … 「今回はどの分割した要件定義書だけを正とするか」を固定する
分割の単位は、顧客確認の単位と揃えると、(A) の文書管理側とも衝突しにくいです。目次は地図、各ファイルは詳細、という役割分担にします。
分割後の例：
SPEC
├ requirements.md … 目次
├ requirements_1.md … 800行程度まで 画面A_1
├ requirements_2.md … 800行程度まで 画面A_2
├ requirements_3.md … 800行程度まで 画面B
├ requirements_4.md … 800行程度まで 画面C
├ requirements_5.md … 800行程度まで 画面D
※4000行 → 800行を5ファイルに分割＋目次
■問題３：巨大な design.md による有効仕様のズレ
顧客確認用（従来版）を分割しても、設計段階で design.md が巨大化すると、同じ問題が再発します。複数機能の設計・制約・例外が1文書に積まれると、生成AIは再び要約と取捨選択を行い、有効仕様がぶれやすくなります。
問題２が「要件定義書の渡し方」の話だとすれば、問題３は設計成果物の肥大化が、次の実装生成でも有効仕様のズレを起こすという話です。
■対策３：機能ごとに小さい design.md を生成する
対策は、大きな design.md を育て続けないことです。
-
小さい機能単位で
design.mdを分ける … 1生成・1改修の対象を狭く保つ - 要件定義書側の分割単位と対応づける … どの要件定義書に対する設計かを明確にする
- 実装生成時も、その機能の design.md だけを参照させる … 無関係な設計を有効仕様に混ぜない
顧客確認用（従来版）の分割（対策２）と設計の分割（対策３）をセットで回すことで、内部用（EARS版）を使わずとも、渡す正を小さく保ち、有効仕様の安定に近づけます。
design
├ 画面A_1
│ ├ frontend
│ │ └ design.md ※小単位で作成する
│ └ backend
│ └ design.md
├ 画面A_2 ※以下も同様に分割する
├ 画面B
├ 画面C
└ 画面D
■まとめ
本稿の結論は次の3点です。
- 内部用（EARS版）を別の正にしない … 顧客確認用（従来版）との二重管理を避け、要件定義書レベルでの認識ズレを増やさない
- 顧客確認用（従来版）を唯一の正にする … 変換を挟まず、確認済みの要件定義書をそのまま生成AIへ渡す
-
渡す単位を小さく保つ … 要件定義書も
design.mdも分割し、参照範囲を限定して有効仕様のズレを抑える
再現性を担保したSPEC駆動開発では、記法を増やすことより、正を分けず、小さく渡すことが先です。分割しても、確認不足やモデル更新によるブレは残ります。変更のたびに、同じ正・同じ参照範囲で生成と確認を回し続けることが必要です。