DESIGN.mdが示すAI時代の設計書 — 機械と人間が同時に読める仕様の書き方
# DESIGN.mdが示すAI時代の設計書 — 機械と人間が同時に読める仕様の書き方
「AIに設計意図を正確に伝えるにはどうすればいいか」——この問いに対して、Googleがひとつの回答を出した。
先週、`google-labs-code` からリリースされた `DESIGN.md` がコミュニティで話題になった。デザインシステムをAIエージェントに伝えるための新しいフォーマットで、既にlintツールや差分比較コマンドまで揃っている。
今すぐUI開発に使う予定がなくても、このフォーマットの設計思想は読んでおく価値がある。なぜなら、同じ問題がUI設計に限らず、要件定義・機能仕様・システム設計のあらゆる場面で起きているからだ。
DESIGN.mdとは何か
DESIGN.mdは、ビジュアルデザインシステムをAIエージェントに伝えるための構造化フォーマットだ。ファイルの構造はシンプルで、2つの層から成る。
YAML前文（トークン層）: 色コード・フォントサイズ・余白値といった「機械が直接使える値」を記述する。曖昧さゼロの数値と識別子だけが並ぶ。
Markdownボディ（意図層）: なぜその色を選んだのか、どういう文脈で使うべきか、禁止事項は何かを人間の言葉で記述する。
この二層構造が、DESIGN.mdの核心だ。
「何」と「なぜ」を分離することの価値
従来の設計書には2つの問題があった。
問題1: 数値が散在している。デザインガイドラインのPDFやFigmaのコメントに色コードが書いてあっても、AIが「この色はここで使え」というルールを自動で抽出するのは難しい。自然言語に埋め込まれた数値は、機械にとって解析コストが高い。
問題2: 意図が失われる。逆にFigmaのVariablesやtokens.jsonだけでは、「なぜこのトークンを選んだのか」「この色をどういう感情を込めて使うのか」という設計意図が伝わらない。AIは値を知っていても、適切な使い方を判断できない。
DESIGN.mdはこの両方を解決する。YAMLで「何」を定義し、Markdownで「なぜ」を説明する。AIエージェントはYAMLを直接パースして値を取得しながら、Markdownで意図を理解してコンテキストに応じた判断ができる。
さらに、バージョン間の差分比較コマンドまで用意されている。設計変更の追跡も機械的に行えるようになった。
これはUIに限った話ではない
DESIGN.mdの革新性は、UIデザインを超えた示唆を持っている。
「機械が直接使える値 + 人間が書いた意図の文章」という構造は、ソフトウェア開発のあらゆる仕様書に応用できる。
要件定義書であれば、セッションタイムアウト時間や最大失敗試行回数といった制約値をYAMLで定義し、「なぜ30分なのか」「なぜ5回なのか」という法的・セキュリティ上の根拠をMarkdownで記述する。APIの仕様書であれば、エンドポイント・レート制限・タイムアウト値をYAMLに、「この100msが1%コンバージョンに影響する」というビジネスコンテキストをMarkdownに書く。
構造化された「値」と文脈化された「意図」を分離して記述することで、AIエージェントはコードを書 くときに正しい選択ができるようになる。
「AIに伝わる仕様書」の3つの原則
DESIGN.mdの設計から学べる原則を、要件定義・機能仕様に適用するなら次の3つになる。
原則1: 機械が使う値はYAML/JSONで分離する
「3秒以内にレスポンスを返すこと」という自然言語より、`timeout_ms: 3000` という形式の方がAIは直接コードに使える。制約値・閾値・識別子は構造化して書く。
原則2: 「なぜ」を散文で書く
数値の根拠、ビジネス上の制約、過去の意思決定の経緯はMarkdownで書く。これはAIのためだけでなく、数年後の自分たちのためでもある。多くの技術的負債は、「なぜそうなっているか」が失われることで生まれる。
原則3: AIがlintできる構造にする
DESIGN.mdのようにバリデーションツールが走れる形式にする。スキーマを定義することで、仕様書の品質チェックを自動化できる。「必須フィールドが埋まっているか」「参照先のIDが存在するか」といった機械的な確認をAIに任せられる。
設計書の未来形
GoogleがDESIGN.mdをリリースした背景には、AIエージェントが日常的にコードを書くようになった現実がある。エージェントが毎日ファイルを読み、コンテキストとして持ち続ける以上、設計書の書き方を変えなければいけない。
これはUI設計だけでなく、システム設計・要件定義・API設計・データモデリングのすべてに当てはまる。
「AIが読める仕様書」は、もはや先進的な取り組みではない。AIエージェントを開発プロセスに組み込むなら、仕様書の構造化は必須のインフラになりつつある。
アツメルでは、要件定義から仕様書作成にかけてのプロセスをAIネイティブに再構築する取り組みを支援しています。「仕様書がAIに伝わらない」「要件定義の品質がブラックボックス」という課題をお持ちの方は、お問い合わせからお気軽にご相談ください。
