背景
「仕様さえ渡せばAIが実装できる」という期待が開発現場で高まっている。こうした文脈で注目されるアプローチを、本稿では仕様駆動開発（SDD）と呼ぶ。仕様を先に定義し、それを基準に実装・検証を進める開発スタイルである。
SDDでは仕様の品質が成果物の品質を直接左右する。AI活用開発ではプロンプトが事実上の仕様となるため、この性質がより先鋭になる。人間同士で暗黙に共有される前提は、AIとの間では同等には共有されない。
仕様駆動開発（SDD）とフロントエンドの相性
フロントエンドでは仕様の完全化が構造的に難しい
SDDの前提は「正確な仕様」だが、フロントエンドではこの前提を満たすことが難しい。
仕様が言語化しにくい
フロントエンドの要件の中心はUI・インタラクション・UXであり、言語だけで仕様化しにくい。ステークホルダーから挙がる要件は、しばしば次のようになる。
- 「使いやすくして」
- 「自然な動きで」
- 「直感的に」
こうした要件は仕様に落とし込みにくい。実際に動くものを見てはじめて「意図と違う」と判断されることも多く、事前の言語化だけでは仕様が完結しない。
デザインへの依存が強く変更も多い
フロントエンドの仕様はデザインに強く依存する。デザイン自体が繰り返し更新されるため、仕様の確定がデザインの確定を前提とする構造になりやすく、仕様が安定しない。
仕様で網羅しきれない変数が多い
UIの状態遷移は組み合わせが多く、全パターンを仕様で網羅することは現実的でない。「ドラッグ中にホバーした要素」「フォーカス遷移中にモーダルが開いた状態」のように、仕様に記述されていない組み合わせが実装段階で頻繁に現れる。ブラウザやデバイスなど実行環境の差異もあり、仕様の完全性だけでは吸収しきれない。
デザインシステムは一部を仕様化しやすくする
デザインシステムが整備されていれば、仕様化できる範囲は広がる。AIへの指示でも「Buttonコンポーネントのprimary variant」のように、構造化された語彙で仕様を伝えられる。
| 観点 | デザインシステムなし | デザインシステムあり |
|---|---|---|
| コンポーネントの仕様 | 都度定義が必要 | 既定のものを参照できる |
| デザイントークン（色・余白等） | 曖昧になりやすい | 数値で仕様化できる |
| インタラクションパターン | 言語化が難しい | 共通定義として参照できる |
| UXの文脈判断 | 仕様化しにくい | 依然として仕様化しにくい |
ただし解決できるのは構成要素レベルの仕様化に限られる。コンポーネントの組み合わせや文脈に応じたパターン選択は、デザインシステムがあっても仕様化しにくい。
詳細化による補完にも上限がある
仕様の曖昧さを詳細化で埋める方向の対処もあるが、AIが処理できるコンテキスト量には上限がある。長大な仕様では中間部分の情報が抜け落ちる「Lost in the Middle」、入力の長さに応じて応答品質が劣化する「Context Rot」といった現象が報告されている。状態遷移やバリエーションが多いフロントエンドでは、詳細化と処理性能が両立しにくい。
ウォーターフォールと組み合わせると不整合が伝播する
SDDの仕様は、生きたドキュメントとして更新し続ける運用もあれば、最初に確定させて固定する運用もある。ウォーターフォールと組み合わせると後者になり、仕様の誤りは実動作を経るまで発覚しにくい。SDDはその固定された仕様を忠実に実装する。加えて、フロントエンドでは前述の通り仕様の完全化自体が難しい。
この3つの条件が重なると、次の因果関係が生じる。
曖昧な要件
↓（言語化ロス）
不完全な仕様
↓（ウォーターフォールで固定）
検証・修正なく実装へ
↓（SDDで忠実に実行）
「仕様通り」だが「意図と異なるもの」が完成たとえば次のような問題が起きる。
- 「仕様書に書いてあった」と「ユーザーが期待していた」が乖離したままリリースに至る
- 状態遷移の考慮漏れが仕様・実装・テストの各工程に伝播する
- デザイン変更による仕様修正が実装完了後に発生する
アジャイルであればイテレーションで仕様を修正できるため、この問題は軽減される。ただし、フロントエンド固有の仕様化の難しさが消えるわけではない。
SDDが機能するのはフロントエンドの周辺領域に限られる
SDDが適用しやすい領域はフロントエンドにも存在するが、その範囲は狭い。
| 領域 | SDDとの相性 | 理由 |
|---|---|---|
| APIとのインターフェース定義 | ◯ | 仕様化しやすく、変更が少ない |
| コンポーネントのProps仕様 | ◯ | 入出力を明確に定義できる |
| バリデーションルール | ◯ | ロジックが言語化しやすい |
| デザインシステムに基づくUI実装 | △ | 構成要素は仕様化できるが、組み合わせの判断は残る |
| UIの見た目・インタラクション（デザインシステムなし） | ✗ | 言語化・網羅が困難 |
| UX・使いやすさ | ✗ | 主観・文脈依存が強い |
◯がついた領域はいずれもフロントエンド作業の周辺部分であり、レイアウト・インタラクション・状態管理・UXといった中心的な作業には適用しにくい。
問うべきは「仕様への責任を誰が負うか」
問題の中心は手法ではなく、仕様に対して誰がどのように責任を持つかにある。仕様を書いたかどうかより、その内容を検証し承認したかどうかが重要である。フロントエンドでは仕様の言語化が難しいため、承認があっても妥当性の検証が不十分になりやすい。SDDとの相性の悪さの根本はここにある。
結論
SDDは仕様の品質に成果物が直結する手法であり、フロントエンドは仕様の完全化が構造的に難しい領域である。ウォーターフォールと組み合わせると、仕様の誤りが修正されないまま後続工程に伝播しやすくなる。
フロントエンドへSDDを持ち込む際は、「仕様を書いたか」ではなく「仕様に責任を持てるか」が重要である。仕様の完全化に依存せず、型システム・テスト・Visual Regression Testing・CI/CDといった決定論的な検証と組み合わせることで、仕様で網羅できない部分の品質を担保できる。ただしこれらの検証基盤の構築には相応の投資が必要であり、基盤が未整備のままSDDを先行させると、検証は結局人間の目視に依存する。