Claude CodeやCursorでUIを生成するたび、色もフォントも毎回バラバラになる——その原因は、AIがプロジェクトのデザインシステムを会話をまたいで保持できないことにある。
2026年4月21日、Google Labsはこの問題を正面から解決するオープンソースのファイルフォーマット「DESIGN.md」を公開した。
この記事でわかること:
- DESIGN.mdがどんな問題を解決するか
- ファイルの構造と記述のしかた
- Claude CodeやCursorへの組み込み方
- CLIツールの活用方法
- DESIGN.mdファイルを今すぐ入手する3つの方法
AIがUIを生成するたびにデザインが崩れる理由
Claude CodeやCursorでUIコンポーネントを書いてもらうとき、よくある問題がある。最初のボタンは正しいブランドカラーで生成される。次のカードは違う色になる。3つ目のフォームはまた別のフォントになる。
原因はシンプルで、AIコーディングエージェントは会話をまたいでデザインシステムを記憶しない。毎回の指示から推測するしかなく、結果として画面ごとに見た目がバラける。
人間のデザイナーにはFigmaファイルや仕様書を渡せる。AIエージェントには、何を渡せばいいのか。
DESIGN.mdはその問いへの答えだ。
DESIGN.mdとは何か
DESIGN.mdは、プロジェクトのルートディレクトリに置くMarkdownファイルで、視覚的なデザインシステム全体をAIエージェントが読める形式で記述する。
README.mdがコードの概要を人間の開発者向けに書いたものなら、DESIGN.mdはデザインシステムの概要をAIエージェント向けに書いたものと考えるとわかりやすい。配置場所も命名規則も同じ——読む相手が違うだけだ。
GitHubのリポジトリ(google-labs-code/design.md)は公開から約2週間で11,600スターを超えており、開発者コミュニティの関心の高さが伝わってくる。ライセンスはApache 2.0。
ファイルの構造
DESIGN.mdはYAMLフロントマターとMarkdown本文の2層構造になっている。
YAMLブロックには機械可読なデザイントークンを書く。MarkdownにはなぜそのトークンがそういW値になっているかの理由を書く。この「値と意味をセットで渡す」設計が従来のスタイルガイドとの大きな違いだ。
---
name: Heritage
colors:
primary: "#1A1C1E"
secondary: "#6C7278"
tertiary: "#B8422E"
typography:
h1:
fontFamily: Public Sans
fontSize: 3rem
body-md:
fontFamily: Public Sans
fontSize: 1rem
spacing:
sm: 8px
md: 16px
---
このYAMLブロックの下にMarkdown形式で各トークンの解説を書く。たとえば #B8422E というカラーコードだけ渡しても、エージェントはそれがボタンのアクセントカラーなのかエラー表示なのか判断できない。「Boston Clay — インタラクションの唯一のドライバー」と書いてあれば、エージェントはこの色をインタラクティブな要素にのみ使うと理解する。
仕様として定義されているセクションは、Overview(ブランドの方向性)、Colors(カラーパレット)、Typography(タイプシステム)、Components(ボタン・カード・入力欄などのトークン)、Agent Prompt(エージェント向け固有指示)の5つだ。すべてを埋める必要はなく、プロジェクトに関係するセクションだけ記述する。
Claude CodeとCursorへの組み込み方
Claude Codeの場合
プロジェクトルートに CLAUDE.md があれば、以下の一文を追加するだけで機能する。
Always read DESIGN.md at project root before generating any UI.
Use the design tokens and rationale to make all styling decisions.
CLAUDE.mdがない場合でも、Claude Codeに指示を出すときに「Check DESIGN.md before writing any CSS or component styles.」と冒頭に添えるだけで読み込む。
Cursorの場合
.cursorrules ファイルに同様の参照指示を追加する。Cursorはルールファイルを毎回のチャットに自動で差し込むため、プロンプトで毎回指示しなくていい。
Bolt、Lovable、v0、Gemini CLIも対応しており、同じ1ファイルをどのエージェントでも使い回せる。
CLIツールで品質を保つ
Google Labsは同時に @google/design.md というCLIツールも公開している。Node.jsが入っていればインストール不要で使える。
lint — ファイルの構造チェックとWCAGコントラスト比の自動検証を行う。アクセシビリティ上の問題も同時に洗い出せる。
npx @google/design.md lint DESIGN.md
diff — 2つのDESIGN.mdを比較し、トークンレベルの変更を一覧表示する。CIに組み込めばデザインシステムの意図しない変更を検知できる。
npx @google/design.md diff DESIGN.md DESIGN.next.md
export — TailwindのテーマJSONやW3C DTCGのtokens.jsonに変換する。Figma VariablesやStorybookとの連携にはDTCG形式が使われる。
npx @google/design.md export --format tailwind DESIGN.md > tailwind.theme.json
DESIGN.mdを入手する3つの方法
1. Google Stitchで生成する
stitch.withgoogle.com でUIデザインを作ると、DESIGN.mdが自動的に出力される。既存のデザインのスクリーンショットを読み込ませて生成することもできる。
2. テンプレートをそのまま使う
github.com/VoltAgent/awesome-design-md にはAnthropicやCohereなど実在するプロダクトから抽出したDESIGN.mdが68件収録されている。近いスタイルのものをベースにして値を書き換えるのが最速だ。
3. 無料ライブラリから選ぶ
freedesignmd.com では121件のデザインシステムをカテゴリ別に閲覧できる。minimal、dark、editorial、glassなどのスタイルタグで絞り込み、コピーしてそのままプロジェクトに置ける。
DESIGN.mdが解決するのは、エージェントへの指示の問題ではなく、エージェントへの記憶の問題だ。プロンプトを書くたびに「青いボタン、Interフォント、角丸8px」と繰り返す必要はなくなる。ファイル1つで、どのエージェントも、どの画面でも、同じデザイン言語を使い続ける。