「AIでUIを作ってもらったら、毎回デザインがバラバラで結局デザイナーが全部直すことになった」
心当たりはないだろうか。Claude CodeやCursorに「かっこいいLPを作って」と頼むと、確かに動くコードは出てくる。でも色がページごとに違う、フォントに統一感がない、ボタンの大きさがなんとなく合っていない。そういう経験を繰り返してきたエンジニアは多いはずだ。
この問題の本質は「AIにデザインの文脈が渡っていない」ことにある。いくら優秀なコーディングエージェントでも、プロジェクトのブランドや設計思想を知らなければ、毎回ゼロから想像するしかない。
2026年4月21日、Googleがその課題に対する答えを出した。DESIGN.mdという仕様フォーマットのオープンソース化だ。
- DESIGN.mdとは何か？3行で理解する
- DESIGN.mdの仕組みと構造
- CLIツールで何ができるか
- 実際にどう使うか：エンジニア向け実践ガイド
- ビジネスパーソン・非エンジニアにとっての意味
- 従来のデザインシステム管理との比較
- 注意点・現時点での限界
- まとめ：「デザインの世界にも仕様の時代が来た」
- 参考リンク
DESIGN.mdとは何か？3行で理解する
まず一言でいうと、「AIコーディングエージェントのためのデザインシステム仕様書」だ。
プロジェクトのルートディレクトリにDESIGN.mdという1枚のMarkdownファイルを置く。するとClaude CodeやCursorなどのAIエージェントがそれを自動的に読み込み、色・フォント・余白・コンポーネントの仕様に従ったUIを生成するようになる。
README.mdのデザイン版、という理解が一番わかりやすい
コードを書く人ならREADME.mdは当然知っている。プロジェクトの概要、セットアップ方法、使い方を書いておくファイルだ。
DESIGN.mdはそれのデザイン版。READMEがコーディングエージェントに「このプロジェクトは何か」を伝えるように、DESIGN.mdは「このプロジェクトのUIはどう見えるべきか」を伝える。
同じ仕組みが、CLAUDE.md（Anthropicのコーディング指示ファイル）やAGENTS.md（汎用エージェント指示ファイル）として既に活用されているのを知っている人には、すぐにピンとくるはずだ。
なぜMarkdownなのか
FigmaやStorybookは使えないのか、という疑問が出るかもしれない。
答えは「AIエージェントはFigmaファイルを直接読めない」から。JSONのデザイントークンファイルも、それ単体ではAIにとって「なぜこの色なのか」という意図が伝わらない。
MarkdownはLLMが学習データとして大量に処理してきたフォーマットだ。AIにとって最も自然に「読める」形式であり、人間が書いても、AIが読んでも、両方に意味が通じる。ここにDESIGN.mdの設計上の核心がある。
DESIGN.mdの仕組みと構造
ファイルの中身は2層構造になっている。
層1：YAMLフロントマター（機械可読なデザイントークン）
ファイルの冒頭、---で囲まれた部分に書く。色のHEX値、フォントサイズ、余白、角丸などを定義する。
--- name: Heritage colors: primary: "#1A1C1E" secondary: "#6C7278" tertiary: "#B8422E" neutral: "#F7F5F2" typography: h1: fontFamily: Public Sans fontSize: 3rem body-md: fontFamily: Public Sans fontSize: 1rem rounded: sm: 4px md: 8px spacing: sm: 8px md: 16px components: button-primary: backgroundColor: "{colors.tertiary}" textColor: "#ffffff" rounded: "{rounded.sm}" padding: 12px ---
{colors.tertiary}のようなトークン参照記法（token reference）も使える。コンポーネントのbackgroundColorが「colors.tertiaryを参照する」と書いておけば、後でカラーを変更したときにコンポーネント全体に反映される。
層2：Markdownの本文（人間可読な設計の意図）
YAMLブロックの後に、なぜそのデザイントークンなのかを自然言語で書く。
## Overview Architectural Minimalism meets Journalistic Gravitas. The UI evokes a premium matte finish — a high-end broadsheet or contemporary gallery. ## Colors The palette is rooted in high-contrast neutrals and a single accent color. - **Primary (#1A1C1E):** Deep ink for headlines and core text. - **Tertiary (#B8422E):** "Boston Clay" — the sole driver for interaction. - **Neutral (#F7F5F2):** Warm limestone foundation, softer than pure white.
AIはこの2層を組み合わせて読む。「#B8422Eというのは単なる色コードではなく、インタラクションを唯一ドライブするアクセントカラーである」という意味まで理解した上でUIを生成する。これが従来のデザイントークンファイルとの決定的な違いだ。
セクション構成
仕様では以下の順序でMarkdownのセクションを書くことが推奨されている（省略も可）。
| セクション番号 | 見出し | 別称 |
|---|---|---|
| 1 | Overview | Brand & Style |
| 2 | Colors | - |
| 3 | Typography | - |
| 4 | Layout | Layout & Spacing |
| 5 | Elevation & Depth | Elevation |
| 6 | Shapes | - |
| 7 | Components | - |
| 8 | Do's and Don'ts | - |
CLIツールで何ができるか
DESIGN.mdの仕様公開と同時に、CLIツールも提供されている。npx @google/design.mdで使える（npmインストール不要でそのまま実行できる）。
lint：ファイルの検証
npx @google/design.md lint DESIGN.md
WCAGのコントラスト比チェックを含む7つのルールでファイルを検証し、構造化されたJSONで結果を返す。
| ルール名 | 深刻度 | チェック内容 |
|---|---|---|
| broken-ref | エラー | {colors.primary}のようなトークン参照が未定義 |
| missing-primary | 警告 | カラーが定義されているがprimaryがない |
| contrast-ratio | 警告 | コンポーネントの背景色とテキスト色がWCAG AA基準（4.5:1）未満 |
| orphaned-tokens | 警告 | 定義されているカラーをどのコンポーネントも参照していない |
| missing-typography | 警告 | カラーはあるがタイポグラフィが未定義 |
| token-summary | 情報 | 各セクションのトークン数サマリー |
| section-order | 警告 | セクションの順序が仕様と異なる |
アクセシビリティチェックが自動化されるのは、実務での恩恵が大きい。デザインレビューの度に手動でコントラスト比を計算していた手間がゼロになる。
diff：バージョン比較
npx @google/design.md diff DESIGN.md DESIGN-v2.md
2つのバージョンを比較し、追加・削除・変更されたトークンを検出する。デザインシステムのリグレッション（品質後退）がないかを自動判定できる。
export：他フォーマットへの書き出し
npx @google/design.md export --format tailwind DESIGN.md > tailwind.theme.json npx @google/design.md export --format dtcg DESIGN.md > tokens.json
TailwindのテーマConfigやW3C標準のDTCG（Design Token Community Group）フォーマットへの変換に対応している。既存のTailwindプロジェクトに組み込むハードルが低い。
実際にどう使うか：エンジニア向け実践ガイド
Claude Codeでの使い方（最速5分）
- プロジェクトのルートディレクトリに
DESIGN.mdを作成する CLAUDE.mdに以下の1行を追加する
UIを生成する際はプロジェクトルートのDESIGN.mdを参照すること。
これだけ。Claude Codeはプロジェクト起動時にCLAUDE.mdを自動で読むので、以降のUI生成は全てDESIGN.mdの仕様に従うようになる。
Cursorでの使い方
.cursor/rules/design-system.mdc
上記のパスに、DESIGN.mdを参照する指示を書いたルールファイルを配置する。Cursor v1.0以降は.cursor/rules/ディレクトリ配下の.mdc形式が推奨されている。
DESIGN.mdをゼロから書くのが面倒な場合
3つの方法がある。
方法1：Google Stitchで自動生成する
Googleが2026年3月に公開したAIデザインツール「Stitch」では、自社サイトのURLを入力するだけでDESIGN.mdを自動生成できる。
方法2：awesome-design-mdを使う
GitHubのVoltAgent/awesome-design-mdリポジトリには、Stripe・Vercel・Linear・Notion・Figma・Apple・Teslaなど主要企業のデザインシステムをDESIGN.md形式で書き起こしたファイルが69社分以上（2026年4月時点で63,500スター超）公開されている。プロジェクトにドロップして、Claude Codeに「Stripe風のUIを作って」と指示すれば、Stripeのデザイントークンに準拠したUIが生成される。
方法3：Chrome拡張でサイトから抽出する
「DESIGN.md Generator」というChrome拡張（2026年4月17日公開）を使えば、任意のWebサイトを表示した状態で拡張ボタンを押すだけで、そのサイトのデザインシステムをDESIGN.md形式で抽出できる。
ビジネスパーソン・非エンジニアにとっての意味
エンジニア向けの話が続いたが、プロダクトマネージャーやデザイナーにとってもDESIGN.mdは無視できない変化だ。
「AIへの指示をうまく書く」時代の終わり
これまで「AIでいい感じのUIを作ってもらう」には、プロンプトエンジニアリングの知識が必要だった。色の表現方法、トーン&マナーの言語化、過去の指示との整合性確保…。
DESIGN.mdが普及すると、この構造が変わる。一度仕様書を書いてしまえば、毎回のプロンプトで「Stripeみたいに」「プロっぽく」という曖昧な表現をしなくて済む。ブランドの意図がファイルに込められ、AIが自動で読む。
「良いプロンプトを書く」から「良い仕様書を書く」へという転換は、プロダクト開発の現場での役割分担にも影響する。デザイン仕様の言語化はデザイナーの仕事になり、その仕様を土台にエンジニアとAIが実装する、という分業が自然に生まれる。
デザイン品質の底上げ
実際にClaude CodeとDESIGN.mdを組み合わせて自社ホームページを実装したエンジニアが、次のような経験を報告している（Qiita、2026年4月）。
「Claude Codeだけでホームページを作ると、パッと見でAIが作ったとわかることがある。レイアウトがバラバラ、フォントサイズが統一されていない。DESIGN.mdがあると、この『AI感』が一切なくなった。Claude Codeが毎回同じデザイントークンを参照するので、ページをまたいでもデザインが揺れない」
複数のDESIGN.mdを使い分けることも可能で、管理画面用と顧客向けページ用でそれぞれ別のデザインシステムを定義するといった運用もできる。
従来のデザインシステム管理との比較
DESIGN.mdが「従来手法の何を置き換えるか」を整理しておく。
| 管理方法 | AIが直接読める | 人間も読める | バージョン管理 | セットアップコスト |
|---|---|---|---|---|
| Figmaファイル | ✗ | ○ | △（履歴機能あり） | 中 |
| StorybookのCSF | △（要変換） | ○ | ○（Gitで可） | 高 |
| JSON デザイントークン | ○ | △（意図が伝わりにくい） | ○（Gitで可） | 低〜中 |
| Tailwind設定ファイル | ○ | △ | ○（Gitで可） | 低 |
| DESIGN.md | ○ | ○ | ○（Gitで可） | 低 |
完全に「Figmaが不要になる」という話ではない。ビジュアルデザインの作業はFigmaで続けるケースがほとんどだろう。ただ、「FigmaにはあるけどAIには伝わらない」状態を解消するブリッジとして、DESIGN.mdが機能する。
注意点・現時点での限界
良いことばかり書いたが、現時点での課題も正直に書いておく。
まだアルファ版
DESIGN.mdの仕様は2026年4月時点でalphaバージョンだ。仕様・トークンスキーマ・CLIは活発に開発中であり、今後の変更が前提になっている。本番プロダクトのデザインシステムをフル移行するにはまだ早い。小規模プロジェクトやプロトタイプで試すところから始めるのが現実的だ。
書く人の質に依存する
DESIGN.mdはあくまで「仕様書」なので、書いた人の理解と言語化能力が品質に直結する。「プロっぽく」という曖昧な言葉を排除しよう、という思想のツールではあるが、DESIGN.md自体を曖昧に書いてしまえば出力も曖昧になる。
Googleの標準化戦略という側面
第3のツイートで指摘されていたが、これはGoogleの明確な戦略でもある。v0（Vercel）・Bolt・Lovable・Claude Codeなど各社が独自フォーマットで分断している状況を、DESIGN.mdというオープン標準で統一しにきている。ChromeがWeb標準を握ったのと同じ構図だ。
OSSとしてApache 2.0ライセンスで公開されているため、コミュニティからの貢献も受け付けている。ただ、標準化の主導権はGoogleが握る形になる。特定のベンダーに依存することへの警戒感を持つ組織は、仕様の動向を観察しながら採用を判断するのが良いだろう。
セキュリティ・免責事項
GitHubリポジトリには「このプロジェクトはGoogle Open Source Software Vulnerability Rewards Programの対象外」という記載がある。まだ実験的なプロジェクトとして扱われているという認識でいた方が良い。
まとめ：「デザインの世界にも仕様の時代が来た」
DESIGN.mdが解決しようとしている問題は、実はシンプルだ。
コードはGitで管理できる。テストも自動化できる。でもデザインの意図だけは、ずっとFigmaのコメントや口頭説明、デザイナーの頭の中にしかなかった。AIがUIを生成するようになった今、その「伝えられなかったもの」がボトルネックになり始めている。
1枚のMarkdownファイルで、ブランドの意図をAIに渡せるようになる。これは小さな仕組みの変化のようでいて、「誰がデザインを管理するか」「エンジニアとデザイナーの協働をどう設計するか」という問いに対する答えを変えていく可能性がある。
個人的には、まずはサイドプロジェクトや社内ツールのリニューアルで試してほしいと思っている。awesome-design-mdでNotionやLinearのDESIGN.mdをダウンロードして、Claude Codeに投げてみる。30分もあれば体感できる。仕様書を書く習慣がある組織ほど、このツールの恩恵は大きい。
