DESIGN.mdは、AIコーディング時代の「見た目の仕様書」になれるのか

Google Stitch と awesome-design-md が示した、UI開発の新しい中間層

AIでUIを作ること自体は、もう珍しくありません。
テキストから画面を出す。画像から叩き台を起こす。コードまで吐かせる。そこまでは、すでに多くの人が体験しています。

でも、現場で本当に困るのはその先です。
1枚の画面は出せても、2枚目、3枚目、設定画面、モーダル、テーブル、空状態、エラー状態まで含めて、同じ人格のUIを保てない。
ここで急に「AIっぽい雑さ」が出ます。
レイアウトの癖が変わる。
余白のリズムが崩れる。
ボタンの圧が画面ごとに違う。
色の使い方に節度がなくなる。
つまり、AIは画面を作れても、デザインシステムを守るのが苦手でした。
そこに対して、Google Stitch が DESIGN.md を前面に出してきた意味はかなり大きいです。
Google は 2025年5月に Stitch を、自然言語や画像から UI デザインとフロントエンドコードを生成し、Figma へ貼り付けたりコードを書き出したりできる Google Labs の実験として公開し、2026年3月の更新では DESIGN.md を「agent-friendly markdown file」として位置づけ、URL から design system を抽出したり、design rules を他の design / coding tools に export / import したりできる流れを打ち出しました。

ここで重要なのは、DESIGN.md が単なる「雰囲気メモ」ではないことです。
これは、AIに対して「こういう見た目が好き」と伝えるメモではなく、そのプロダクトがどう見えるべきかを拘束する視覚契約に近い。
Google の説明でも、DESIGN.md は design rules を持ち運ぶためのファイルとして語られています。
つまり論点は、AIが画面を作れるかどうかではありません。見た目の一貫性を、AIが読める形でどこまで持ち運べるかです。

なぜこれが効くのか。
理由は、従来のデザイン資産がそれぞれ半端にしかAIへ渡らなかったからです。Figma は人間に強い。一方で、AIにとっては「なぜこの余白なのか」「どこが絶対に崩してはいけない核なのか」を安定して理解しにくい。スクリーンショットは見た目の参照にはなるが、状態変化や禁止事項までは渡しにくい。design token の JSON は厳密だが、思想や雰囲気、Do / Don’t、どのコンポーネントをどの場面で優先するかのような叙述的な情報を持ちにくい。
その中間にあるのが DESIGN.md です。数値も書ける。原則も書ける。禁止事項も書ける。しかも Markdown なので、LLM がそのまま読みやすい。ここが本質です。

この流れを一気に分かりやすくしたのが、VoltAgent の awesome-design-md です。README では、これは developer focused websites に触発された DESIGN.md の curated collection であり、現時点で DESIGN.md count 55 を掲げています。さらに README は、AGENTS.md を「How to build the project」、DESIGN.md を「How the project should look and feel」と対比させています。
この整理はかなり良い。
つまり、実装の仕様書と見た目の仕様書を分けるということです。しかもこの repo には、DESIGN.md だけでなく preview.html と preview-dark.html も用意され、Color Palette、Typography、Component Stylings、Layout Principles、Depth、Do’s and Don’ts、Responsive Behavior、Agent Prompt Guide まで含む構成が示されています。 (GitHub)

この AGENTS.md と DESIGN.md の分離は、AIネイティブ開発の文脈ではかなり筋が良いです。
「何をどう作るか」と「どう見えるべきか」は、本来は別の制約です。にもかかわらず、これまでは一つの prompt の中で雑に混ぜていました。
Next.js で作って、shadcn/ui を使って、アクセシブルで、でも Linear っぽくして、余白は広めで、でも遊びすぎず、CTA は目立たせて……と全部を一つの会話に押し込む。これでは、会話のたびに制約が揺れます。
だから、AGENTS.md 系には実装契約を書き、DESIGN.md には視覚契約を書く。その分離が効くわけです。

実際、この発想は各AIコーディングツールの現状とも噛み合っています。Claude Code は CLAUDE.md や設定、skills などをプロジェクトや ~/.claude から読み込む仕組みを持っています。
Gemini CLI は GEMINI.md をデフォルトの context file として階層的に読み込み、見つかった context files を結合して毎回モデルに送ります。
GitHub Copilot は .github/copilot-instructions.md に加えて、AGENTS.md、ルートの CLAUDE.md、GEMINI.md を agent instructions として扱えます。
Cursor も Rules と AGENTS.md を通じて永続的な指示を与える設計です。
つまり各ツールは、すでに instruction file を読む文化を持っている。そこへ DESIGN.md を置くのは自然な流れです。

ただし、ここは少し冷静に見た方がいい点もあります。
SNSで流れてくる紹介文だと、「Claude Code、Cursor、Gemini CLI、GitHub Copilot が全部ネイティブで DESIGN.md を読む」と聞こえがちです。
でも厳密には、各ツールが正式に予約しているファイル名は別です。
Claude Code は CLAUDE.md、Gemini CLI は GEMINI.md、Copilot は .github/copilot-instructions.md や AGENTS.md などを正式に扱います。
Cursor も Rules や AGENTS.md です。
なので今の DESIGN.md は、全ベンダー共通の正式標準というより、どのエージェントにも運びやすいプレーンな Markdown 慣習と見る方が正確です。ここを誤解すると、「置くだけで全部が完全準拠する」と期待しすぎます。
実務では、CLAUDE.md や AGENTS.md 側から DESIGN.md を参照させる設計の方が堅いです。

もう一つ大事なのは、awesome-design-md が「公式 design system 集」ではないことです。
README には、各 DESIGN.md は public websites から抽出した design system documents であり、公開されている CSS 値を元にしている、visual identity の所有権を主張しない、と明記されています。
つまり、Stripe や Vercel や Notion の内部で運用されている正式な brand rule をそのまま配っているわけではない。あくまで公開面から再構成した、AI が真似しやすい視覚仕様書です。
これは長所でもあり、限界でもあります。
長所は、すぐ触れること。限界は、静的な見た目からは interaction の哲学や内部の rationale までは取り切れないことです。hover、focus、loading、error、responsive の崩れ方まで含めて本番品質にするには、やはり自分のプロダクト用に再編集が必要です。

それでも、この repo が持つ意味は小さくありません。
なぜなら、ここで配られているのは「似た配色」ではなく、再現のルールだからです。
Visual Theme、Color Roles、Typography、Components、Layout、Depth、Do / Don’t、Responsive Behavior まで文章化されていると、AIは単なる模写ではなく、判断の枠を持てるようになります。
たとえば「アクセント色はCTAと focus ring に限定する」「影は存在感の演出ではなく境界補助として使う」「section 間のリズムは decorative separator より whitespace で作る」といった指示があると、AIは“盛る方向”への暴走をかなり起こしにくくなります。
逆に言えば、今までのAI UI生成が崩れやすかった理由は、色コードを知らなかったからではなく、節度の規則を持っていなかったからです。

では、実務ではどう使うべきか。
私なら、DESIGN.md を repo root に置くだけでは終わらせません。
まず CLAUDE.md や AGENTS.md に「UI作業前に DESIGN.md を読む」「未定義 color / spacing / radius を勝手に増やさない」「既存 component を優先する」と書く。
次に DESIGN.md に書いた色・余白・radius・shadow を token に落とし、CSS variables か Tailwind theme に固定する。
最後に visual regression や screenshot 比較でズレを監査する。
つまり、文章契約 → 実装契約 → token enforcement → 画面検査の四段で閉じるわけです。DESIGN.md だけでは雰囲気は揃えやすくなりますが、最後の歩留まりまでは保証できません。
そこをコード側と評価側で受け止める必要があります。

この観点から見ると、DESIGN.md の本質はかなり明確です。
これは Figma を消すものではありません。
Google 自身、Stitch で生成したものを Figma に貼り付けたり、フロントエンドコードを書き出したりする流れを最初から用意しています。
つまり構図は、「Figma か Markdown か」の二択ではない。
Figma は人間の編集面、DESIGN.md はAIの可読面です。
両方がある方が強い。人間が編集しやすい面と、AIが守りやすい面を分ける。その中間層として DESIGN.md を置くと、ようやく UI 生成が「1枚絵の奇跡」から「継続的に崩れにくい設計」へ近づきます。

私は、この流れをかなり本命だと思っています。
理由は単純で、AIコーディングが強くなるほど、差が出るのはコード生成能力そのものではなく、何を守らせるかをどう構造化するかだからです。
機能の仕様だけ整っていても、見た目の仕様が曖昧なら、出てくるUIは毎回ぶれます。逆に視覚契約まで文章化できれば、複数のエージェント、複数のツール、複数の画面に跨って、人格を維持しやすくなる。DESIGN.md が面白いのは、まさにその中間層を作ろうとしているからです。

言い切るなら、こうです。
README.md は人間にプロジェクトを説明する。
AGENTS.md はAIに実装の進め方を教える。
そして DESIGN.md は、AIに「どう見えるべきか」を教える。

AIコーディングの次の勝負は、コードを書けるかどうかではありません。
見た目の一貫性まで、契約として持ち運べるかどうかです。
DESIGN.md は、その入口としてかなり筋がいい。
今後これが正式な共通標準へ進むのか、各ベンダー独自の instruction file に吸収されるのかはまだ分かりません。ですが少なくとも、デザインシステムが「人が読む資料」から「AIが守る仕様書」へ変わり始めたことだけは、もうかなりはっきりしています。

#AI #生成AI #AIコーディング #AIエージェント #UIデザイン #デザインシステム #フロントエンド #GoogleStitch #ClaudeCode #Cursor #GitHubCopilot #プロンプト設計