仕様が新しいデザイン成果物になる日 — 仕様駆動開発についてデザイナーが知っておくべきこと

仕様駆動開発（Spec-Driven Development）が再興している。これはAIがコードを書く時代に、人間の意図をどう正確に伝えるかへの実践的な答えだ。従来、仕様書は人間が読むための参考資料であり、実装が始まれば現実とズレていくのが常だった。仕様駆動開発では、仕様書がAIへの入力そのものになる。仕様を書き換えれば、コードが変わる。仕様が真実であり、コードはその射影に近づいていく。進め方の骨格は「何を、誰のために、なぜ作るか」という要件の記述、次に「それをどう実現するか」という設計の記述、そこでAIが実装し、人間が各段階でレビューして次へ進む、という流れである。AWSのKiroやGitHub Spec Kitはこの流れを製品として組み込み、Claude Codeのようなコーディングエージェントでも、先に仕様を書かせてから実装に入る進め方が定着しつつある。

ここで痛い指摘がある。デザイナーが「デザインを渡す」と言うとき、渡しているのは理想状態のスナップショットだ。テキストが3行に折り返したら、APIが失敗したら、リストが0件だったら、権限のないユーザーが来たら――こうした行間の大半はモックアップのどこにも描かれていない。これまで優秀なエンジニアが「たぶんこうだろう」と補い、デザイナーが後出しレビューで「そこはこうしてほしかった」と修正してきた。AIが実装するようになると、この曖昧さが通用しない。書かれていないことは、ランダムに埋められる。つまり「デザインの未定義領域」がそのまま品質のばらつきとして表面化する。これまで暗黙知として許されてきたハンドオフの曖昧さは、AI時代には致命傷になるのだ。

仕様駆動開発は、この未定義領域を書き起こすことを中心に置く。エラーをどう伝えるか、境界値でレイアウトをどう崩さないか、空状態をどう見せるか。これらの意思決定は本来デザインの領域であり、仕様駆動開発はその置き場所を用意する。求められるコアスキルは新しいツール操作ではなく、構造化された文章力だ。曖昧さのない文を書く。前提を明示する。例外を先回りして列挙する。これは「機械と人間の両方が誤読しない文章」という新しいジャンルである。受け入れ条件（acceptance criteria）とは「この機能ができたと言ってよい条件」を検証可能な文で列挙したもので、仕様書の要となる。「見た目が良いこと」は検証できないが、「テキストが最大文字数でも2行に収まり、超過分は省略記号で切られること」は検証できる。全てが仕様になるわけではない。イージングの気持ちよさ、余白の詰まりが生む緊張感、ホバー反応速度の「ちょうどよさ」といった質感は、プロトタイプを触って最後に調整する領域として残る。仕様駆動開発は、下層の機械化を進めるほど、デザイナーの最終審美眼の希少価値を高める構造なのだ。