Google Labsが「DESIGN.md」というCLIツールをオープンソースで公開しました。
プロジェクトルートに DESIGN.md を1つ置くだけで、AIがデザインルールを理解してコードに自動反映します。GitHubスター数は公開直後から急増し、現在5,900超。
私はメリットがピンとこなかったので、改めてメリット・デメリットを調査しました。
DESIGN.mdがないと何が困るのか・あると何が変わるのか
❌ ない場合のデメリット
1. AIへの説明を毎回書き直す セッションをまたぐたびに「ボタンは青 #3B82F6、フォントは16px…」と再説明が必要。同じ指示を何十回も書くことになる。
2. 人・AIによってUIがバラバラになる チームメンバーが変わるたびに口頭でルールを伝え直す。AIへの指示の書き方次第で、実装がプロジェクトごとに微妙にズレる。
3. デザインとコードが乖離していく Figmaのデータ・CSSの実装・ドキュメントが別々のファイルで管理される。時間が経つとどれが最新の正解かわからなくなる。「Figmaは青だけどCSSは水色になってる」という状態が起きる。
4. アクセシビリティを誰も確認しない コントラスト比（WCAG基準）は手動で計算しないと分からない。実装後に指摘されて修正、というループが起きる。
✅ ある場合のメリット
1. AIへの指示が1行になる 「DESIGN.mdに従って実装して」——これだけ。カラーコード・フォント・余白の説明が不要になる。
2. 誰が頼んでも同じ結果になる チームの誰がAIに依頼しても、DESIGN.mdのトークンが基準になるので実装がブレない。
3. デザインの正解が1ファイルに集約される DESIGN.mdが「唯一の正解」になる。FigmaでもCSS変数でも、すべてここから派生する。
4. WCAGコントラスト比を自動チェック
design lint を実行するだけで、テキストと背景の組み合わせが基準を満たしているか自動計算してくれる。手動作業ゼロ。
5. Tailwind設定に自動変換できる
design export --format tailwind でそのまま tailwind.config.js に使える形式に変換。FigmaのデータをCSSに手動で書き写す作業がなくなる。
なぜ今これが必要なのか
AIを使ったUI実装には長年の課題があります。AIはコードは書けても、デザインの「正解」を知らないという問題です。
指示するたびに「ボタンは青 (#3B82F6) で」「フォントは16px で」と毎回伝える必要があり、複数人が使えばプロジェクトのスタイルがバラバラになります。またFigmaのデータ・CSSの実装・ドキュメントが別ファイルで管理されるため、どれが最新の正解か誰にもわからなくなります。
DESIGN.mdはデザイン仕様をAIが直接読める構造化フォーマットで1ファイルに集約することで、これを解決します。
ファイルの構造
DESIGN.mdは2層構造です。
---
# 上部：機械が読むYAML（デザイントークン）
colors:
primary: "#1A73E8"
surface: "#FFFFFF"
on-primary: "#FFFFFF"
typography:
body:
fontFamily: "Google Sans"
fontSize: "16px"
lineHeight: 1.5
spacing:
base: "8px"
md: "16px"
lg: "24px"
---
# 下部：人間が読むMarkdown（設計の意図）
## Overview
Googleのマテリアルデザインに準拠したデザインシステム。
一貫性と視認性を最優先とする。
## Colors
プライマリカラー（#1A73E8）はCTAボタンとリンクにのみ使用すること。
背景色としては使用しない。コントラスト比4.5:1以上を維持すること。
## Typography
本文フォントは最小16px。モバイルでの可読性を確保する。
YAMLはAIが読む用、Markdownは人間が読む用——両方を1ファイルで管理します。
実際に何が変わるのか
Before：DESIGN.mdがない場合
AIにUIの実装を頼むとき、毎回こう書く必要があります。
ボタンコンポーネントを作ってください。
色は #1A73E8、ホバーは #1557B0。
フォントは Google Sans 14px、パディングは上下12px 左右24px。
角丸は 4px。アクセシビリティのコントラスト比は 4.5:1 以上で。
セッションをまたぐたびに同じ説明が必要です。チームに別の人が加わったら、また同じ説明を書きます。半年後に自分が書いたCSSとFigmaのデータがどちらが正しいか分からなくなります。
After：DESIGN.mdがある場合
DESIGN.mdをプロジェクトに置いておけば、指示は1行になります。
DESIGN.mdのトークンに従って、ボタンコンポーネントを実装してください。
AIがDESIGN.mdを読んで、カラー・フォント・余白・コントラスト比を自動で正しく適用します。チームの誰がAIに頼んでも同じ結果になります。
After：DESIGN.mdを使った場合
# 1. インストール
npm install @google/design.md
# 2. DESIGN.mdをプロジェクトルートに作成（デザイナーが書く）
# 3. lintでミスを自動検出
npx @google/design.md lint DESIGN.md
lintの出力例：
{
"findings": [
{
"rule": "contrast-ratio",
"severity": "warning",
"message": "text '#757575' on '#FFFFFF' has contrast ratio 4.48 (WCAG AA requires 4.5)"
},
{
"rule": "broken-ref",
"severity": "error",
"message": "Token reference '{colors.accent}' is not defined"
}
]
}
# 4. Tailwind設定に自動変換
npx @google/design.md export --format tailwind DESIGN.md > tailwind.theme.json
# 5. AIに実装を依頼
# 「DESIGN.mdのトークンに従ってボタンコンポーネントを実装して」
# → AIがDESIGN.mdを読んで、正しいカラー・サイズで実装する
CLIコマンド一覧
| コマンド | 役割 |
|---|---|
lint |
構造検証 + WCAGコントラスト比チェック |
diff |
2バージョン間のトークン変更を検出 |
export --format tailwind |
Tailwind CSS設定に変換 |
export --format dtcg |
W3C標準形式（tokens.json）に変換 |
spec |
AIエージェント向けに仕様を出力 |
lintが検出できる問題（7種類）
| ルール | 深刻度 | 内容 |
|---|---|---|
broken-ref |
error | 存在しないトークンを参照している |
contrast-ratio |
warning | WCAG AA基準（4.5:1）未満のコントラスト |
missing-primary |
warning | プライマリカラーが未定義 |
orphaned-tokens |
warning | 定義されているが使われていないトークン |
missing-typography |
warning | タイポグラフィトークンが未定義 |
section-order |
warning | セクションの並び順が仕様と違う |
token-summary |
info | トークン数のサマリー |
コントラスト比は自動計算されます。デザイナーが目視で確認する必要がなくなります。
Claude Codeとの組み合わせ
DESIGN.mdとCLAUDE.mdを両方置くと、AIへの指示が完全に構造化されます。
プロジェクト/
├── DESIGN.md ← デザインのルール（カラー・フォント・間隔）
├── .claude/
│ └── CLAUDE.md ← 開発のルール（コマンド・アーキテクチャ）
└── src/
Claude Codeへの指示：
DESIGN.mdのトークンに従って、ヘッダーコンポーネントを実装してください。
プライマリカラー・タイポグラフィ・スペーシングはすべてDESIGN.mdから参照すること。
AIはDESIGN.mdを読んで、カラーコード・フォントサイズ・余白を自動で正しく適用します。
現状と注意点
- アルファ版（仕様は今後変わる可能性あり）
- IDE/エディタ拡張は現時点で未公開
- Figmaとの直接連携は非対応（手動でDESIGN.mdに書く）
- Apache-2.0ライセンス（商用利用可）
まとめ
DESIGN.mdが解決するのは「AIはコードは書けるが、デザインの正解を知らない」という根本的な問題です。
デザイントークンをAIが読める形式で書いておけば、実装のたびにカラーコードを伝える必要がなくなります。さらにlintがWCAGコントラスト比を自動チェックするため、アクセシビリティの見落としも防げます。
まだアルファ版ですが、CLAUDE.mdと組み合わせることで、AIへの設計指示を完全に構造化できる最初のツールとして注目に値します。