AIにデザインを「伝える」時代の新標準
Google LabsがApache 2.0で公開 / Claude Code・Cursor・Copilotに対応 / 導入は30秒
2026年4月21日にGoogle Labsがオープンソースとして公開した「DESIGN.md」は、AIコーディングエージェントにデザインシステムを正しく伝えるための新しいファイル規格です。1つのMarkdownファイルをプロジェクトに置くだけで、Claude CodeやCursor、GitHub CopilotといったAIツールが、ブランドに沿った一貫性のあるUIを生成できるようになります。
DESIGN.mdとは何か
DESIGN.mdは、Google Labsが2026年4月21日にオープンソース(Apache 2.0ライセンス)で公開した、デザインシステムをAIコーディングエージェントに伝えるためのファイル規格です。
プロジェクトのルートディレクトリにDESIGN.mdという1つのMarkdownファイルを置くだけで、Claude Code、Cursor、GitHub CopilotなどのAIツールがそのファイルを読み取り、ブランドカラー・フォント・間隔・コンポーネントのルールに沿ったUIコードを生成するようになります。
DESIGN.mdは「AIのためのデザインガイドライン」です。人間のデザイナー向けのスタイルガイドをAIが読める形式に変換したものと考えてください。README.mdがプロジェクトの概要をAIに伝えるように、DESIGN.mdはプロジェクトのビジュアルルールをAIに伝えます。
なぜ必要なのか — AIが「デフォルトの青」を生成してしまう問題
Claude CodeやCursorにUIの生成を依頼したことがある方なら、こんな経験があるのではないでしょうか。
- 「ブランドカラーでダッシュボードを作って」と依頼したのに、Tailwindのデフォルトの青で生成される
- 毎回プロンプトにカラーコードやフォント指定を書き直す必要がある
- 複数のファイルを生成すると、ファイルごとにスタイルがバラバラになる
- チームメンバーごとにプロンプトが異なり、生成結果が統一されない
この問題の根本原因は、AIエージェントがプロジェクト固有のデザインルールを永続的に把握する手段がなかったことにあります。毎回のプロンプトに詳細なスタイル指定を含めるか、AIが推測に頼るかの二択でした。
DESIGN.mdはこの課題を解決します。一度ファイルを配置すれば、AIはそのデザインシステムを毎回参照し、プロンプトにスタイル情報を含めなくても正しいデザインを生成するようになります。
ファイル構造 — YAMLトークンとMarkdown解説の二層構造
DESIGN.mdの最大の特徴は、機械可読なデザイントークンと人間向けの設計意図の解説を1つのファイルに統合している点です。
第1層 — YAMLフロントマター(デザイントークン)
ファイル冒頭の—で囲まれた部分に、カラー・フォント・余白などの具体的な値を構造化データとして記述します。
---
version: "alpha"
name: "My Brand Design System"
colors:
primary: "#1A73E8"
on-primary: "#FFFFFF"
background: "#FFFFFF"
surface: "#F8F9FA"
text-primary: "#202124"
text-secondary: "#5F6368"
typography:
heading-1:
fontFamily: "Inter"
fontSize: "32px"
fontWeight: 700
lineHeight: 1.3
body:
fontFamily: "Inter"
fontSize: "16px"
fontWeight: 400
lineHeight: 1.6
spacing:
xs: "4px"
sm: "8px"
md: "16px"
lg: "24px"
xl: "32px"
rounded:
sm: "4px"
md: "8px"
lg: "16px"
---
第2層 — Markdownセクション(設計意図の解説)
YAMLブロックの下に、##見出しで区切られたセクションが続きます。ここに「なぜその値を選んだのか」という設計の意図や使い方のルールを自然言語で記述します。
## Colors
Primary blue (#1A73E8) はブランドの信頼感を表現する色です。
CTAボタンやリンクに使い、背景色には使いません。
テキストは常に #202124 を使い、薄いグレー (#5F6368) は
補足的なラベルやキャプションにのみ使います。
## Typography
見出しは Inter Bold を使い、本文は Inter Regular を使います。
見出しと本文のコントラストで情報の階層を明確にします。
## Do's and Don'ts
- Do: ボタンにはprimaryカラーを使う
- Don't: 背景にprimaryカラーを使わない
- Do: 余白はspacingスケールの値のみ使う
- Don't: 任意のピクセル値で余白を指定しない
AIエージェントはカラーコードの値だけでなく、「このピンクはエラー表示専用」「この余白は常にmd以上」といった文脈を理解することで、単なる値の適用ではなくデザインの判断ができるようになります。DESIGN.mdが他のトークン管理ツールと異なるのは、この「意図」の層を持っている点です。
セクションの推奨順序
DESIGN.mdの仕様では、セクションの順序が以下のように定められています(省略可)。
| 順序 | セクション名 | 内容 |
|---|---|---|
| 1 | Overview | デザインシステムの全体方針 |
| 2 | Colors | カラーパレットと用途 |
| 3 | Typography | フォント・サイズ・ウェイト |
| 4 | Layout | グリッド・余白・配置ルール |
| 5 | Elevation & Depth | シャドウ・奥行き表現 |
| 6 | Shapes | 角丸・枠線のルール |
| 7 | Components | ボタン・カード等のスタイル |
| 8 | Do’s and Don’ts | やるべきこと・やってはいけないこと |
対応するデザイントークンの種類
YAMLフロントマターに記述できるトークンの種類は以下の通りです。
| トークン種別 | 形式 | 例 |
|---|---|---|
| Color(色) | Hex値(sRGB) | “#1A73E8” |
| Dimension(サイズ) | 数値 + 単位 | 48px / 1rem |
| Typography(文字) | fontFamily, fontSize等のオブジェクト | 上記の例を参照 |
| Token Reference(参照) | 中括弧でパス指定 | {colors.primary} |
Token Referenceは特に強力な機能です。たとえばボタンの背景色を{colors.primary}と指定しておけば、primaryカラーを変更した時にボタンの色も自動的に追従します。AIエージェントはこの参照関係を理解し、一貫性のあるコードを生成します。
CLIツールの機能
GoogleはDESIGN.mdの仕様と合わせて、検証・比較・エクスポートが可能なCLIツールも公開しています。
| コマンド | 機能 | 用途 |
|---|---|---|
| lint | 構造の正しさを検証 | 壊れたトークン参照、必須カラーの欠落、WCAGコントラスト比のチェック。結果はJSON形式で出力 |
| diff | 2つのバージョンを比較 | デザインシステム変更時のトークンレベルの差分検出 |
| export | 他形式への変換 | TailwindやW3C DTCGフォーマットへの書き出し |
| spec | 仕様の出力 | AIエージェントのプロンプトに仕様を渡す際に使用 |
- 壊れたトークン参照(存在しないトークンを参照していないか)
- 必須カラー(primary等)の欠落
- WCAGのAA基準を満たさないコントラスト比
- 使われていない孤立トークン
- セクション順序の違反
- 構文エラー
- 値のフォーマット不正
対応AIツールと使い方
DESIGN.mdは特定のツールに依存しない汎用フォーマットです。Markdownファイルを読めるAIエージェントであれば、原理上すべて対応します。
対応が確認されているツール
| ツール | 対応方法 |
|---|---|
| Claude Code | プロジェクトルートに配置すれば自動認識 |
| Cursor | プロジェクトルートに配置すれば自動認識 |
| GitHub Copilot | プロジェクトルートに配置すれば参照可能 |
| Google Stitch | ネイティブ対応(生成・インポート・エクスポート) |
| Lovable | プロンプトで参照を指示 |
導入手順(30秒で完了)
- DESIGN.mdファイルを用意する — 自分で書くか、100種類以上のテンプレートから選ぶ(designmd.aiで入手可能)
- プロジェクトルートに配置する — README.mdと同じ階層に置く
- AIツールに「DESIGN.mdに従って」と指示する — 以降、そのセッション内ではデザインルールが適用される
特別な設定やプラグインのインストールは不要です。DESIGN.mdはただのMarkdownファイルなので、Git管理の対象にもなり、チーム全体でデザインルールを共有できます。
Google Stitchとの関係
DESIGN.mdはもともとGoogle Stitchから生まれたフォーマットです。Stitchは2026年3月中旬にGoogle LabsからリリースされたAIデザインプラットフォームで、自然言語の指示からUIデザインを生成するツールです。
4月21日の発表で、GoogleはDESIGN.mdの仕様をStitchから切り離し、独立したオープンソースプロジェクトとしてGitHubに公開しました。これにより、Stitch以外のどのプラットフォームでもDESIGN.mdを利用できるようになりました。
- Stitchを使う場合 — GUIでDESIGN.mdを自動生成・編集できる。デザイナー向け
- Stitchを使わない場合 — テキストエディタで直接書く、またはテンプレートを利用する。開発者向け
どちらの方法でも同じDESIGN.mdファイルが生成され、同じAIツールで利用できます。
Before/After — DESIGN.mdがあるとAIの出力はどう変わるか
「具体的に何が変わるのか」がもっともイメージしやすいのは、Before/Afterの比較です。クラスメソッド社の実践レポートや複数のブログ記事から、DESIGN.mdの有無で何が変わるかをまとめます。
DESIGN.mdなし — 毎回「ガチャ」状態
- AIに「ダッシュボードを作って」と依頼すると、Tailwindのデフォルトカラー(blue-500等)で生成される
- ボタンのborder-radiusが12pxだったり8pxだったりと、コンポーネントごとにバラバラ
- シャドウの強さやパディングも毎回変わり、ページ全体の統一感がない
- チームメンバーがそれぞれ異なるプロンプトを使うため、同じプロジェクト内でもUI品質にバラつきが出る
DESIGN.mdあり — 一貫性と効率が劇的に改善
- AIが自動的にDESIGN.mdを参照し、指定されたカラー・フォント・余白で生成する
- クラスメソッド社の実験では、プロンプトの文字数が約11,500文字から約3,500文字へ — 約70%削減
- フッターの著作権表記やロゴの配置位置まで自動で反映される
- Claude Codeは「DESIGN.mdに沿って作成します」と明示的に宣言してから生成を開始する
| 項目 | DESIGN.mdなし | DESIGN.mdあり |
|---|---|---|
| プロンプト文字数 | 毎回 約11,500文字 | 約3,500文字(70%削減) |
| カラー一貫性 | 毎回指定が必要 | 自動適用 |
| コンポーネント統一 | border-radius / shadow がバラバラ | DESIGN.mdの値を毎回使用 |
| チーム間のブレ | 人によって出力が異なる | 誰が使っても同じデザイン |
| ツール間の互換性 | ツールごとに設定が必要 | 1ファイルで全ツール対応 |
DESIGN.mdの本質的な価値
DESIGN.mdの真の価値は「一度書けば、毎回読んでくれる」点にあります。プロンプトの冒頭にカラーコードを毎回コピペする作業がなくなるだけでなく、AIが設計の意図を理解した上で判断できるようになります。たとえば「このピンクはエラー表示専用」「背景にはプライマリカラーを使わない」といったルールを文脈として把握し、新しいコンポーネントを生成する際にもそのルールを守ります。
すぐに使えるテンプレート集 — awesome-design-md
DESIGN.mdを自分でゼロから書く必要はありません。コミュニティが公開しているテンプレート集を活用すれば、有名サービスのデザインシステムをそのまま参考にできます。
awesome-design-md — 69種類のブランドテンプレート
GitHubの「awesome-design-md」リポジトリには、Stripe・Notion・Linear・Vercelなど69種類以上の有名ブランドのデザインシステムをDESIGN.md形式に変換したテンプレートが収録されています。
| カテゴリ | 収録ブランド例 | 数 |
|---|---|---|
| AI・LLMプラットフォーム | Claude, Ollama, Replicate, xAI | 12 |
| 開発ツール・IDE | Cursor, Vercel, Expo, Raycast | 7 |
| バックエンド・DB | Supabase, MongoDB, Sentry, PostHog | 8 |
| SaaS・生産性 | Notion, Linear, Zapier, Resend | 7 |
| デザイン・クリエイティブ | Figma, Framer, Miro, Webflow | 6 |
| フィンテック | Stripe, Coinbase, Revolut, Wise | 7 |
| コンシューマー | Apple, Nike, Spotify, Uber, Airbnb | 11 |
| 自動車 | BMW, Tesla, Ferrari, Lamborghini | 5 |
「Notionみたいなデザインにして」が実現する
たとえば社内ツールのUIを「Notionっぽい雰囲気にしたい」と思ったとき、これまではプロンプトに「白背景で、角丸は小さめで、フォントはInter系で…」と細かく指定する必要がありました。
awesome-design-mdのNotionテンプレートを使えば、ファイルを配置するだけでAIがNotionの配色・タイポグラフィ・余白感・コンポーネントスタイルを自動的に再現します。「Stripe風のきれいな決済画面」「Linear風のシンプルなタスク管理画面」なども同様です。
- そのまま使う — 好みのブランドテンプレートをダウンロードして配置。プロトタイプやMVPに最適
- ベースとしてカスタマイズ — テンプレートのカラー値だけ自社のブランドカラーに差し替える
- 構造だけ参考にする — テンプレートのセクション構成やDo’s/Don’tsの書き方を参考に、自社オリジナルのDESIGN.mdを作成する
日本語UIに特化したテンプレートも
GitHub上には「awesome-design-md-jp」という日本語UIに特化したリポジトリも公開されています。CJKフォント(Noto Sans JP、Inter等)の指定や、日本語の行間・字間設定が含まれたテンプレートが24ブランド分用意されており、日本語のWeb制作でそのまま使えます。
また、designmd.aiやdesignmd.appでは423種類以上のデザインシステムがライブラリとして公開されており、タグ(clean, modern, SaaS, dashboardなど)で検索して目的のデザインテイストに合ったテンプレートを見つけることができます。
既存のデザインシステム管理との違い
デザインシステムの管理には既存のツールやフォーマットがあります。DESIGN.mdはこれらとどう違うのでしょうか。
| 項目 | DESIGN.md | FigmaのDesign Tokens | Style Dictionary |
|---|---|---|---|
| 形式 | Markdown + YAML | JSON(プラグイン経由) | JSON / YAML |
| AI最適化 | 設計意図の自然言語解説付き | 値のみ | 値のみ |
| 導入の手軽さ | ファイル1つ配置するだけ | Figma + プラグイン必要 | Node.js環境 + 設定ファイル |
| エクスポート | Tailwind / W3C DTCG | プラグイン依存 | 多数のフォーマットに対応 |
| バージョン管理 | Git対応(テキストファイル) | Figmaの履歴機能 | Git対応 |
| コスト | 無料(Apache 2.0) | Figma有料プラン推奨 | 無料 |
DESIGN.mdの最大の差別化ポイントは「設計意図を自然言語で伝えられる」点です。他のフォーマットが「何の値か」を定義するのに対し、DESIGN.mdは「なぜその値なのか」まで伝えることで、AIの判断精度を高めます。
導入時の注意点と現在のステータス
- アルファ版 — 仕様・トークンスキーマ・CLIはすべて開発中。フォーマットが変更される可能性がある
- AIツール側の対応はまちまち — Claude CodeやCursorは自動認識するが、一部ツールではプロンプトで明示的に参照を指示する必要がある
- 複雑なインタラクションは対象外 — アニメーション、マイクロインタラクション、レスポンシブのブレークポイント等は現時点では扱えない
- デザイナーとの協業フローは未確立 — FigmaやAdobe XDとの双方向同期はまだ実現していない
導入が向いているケース
- AIコーディングエージェント(Claude Code, Cursor等)を日常的に使っている開発チーム
- プロトタイプやMVPを素早く作りたいスタートアップ
- デザインの一貫性に課題を感じているプロジェクト
- Tailwind CSSベースのプロジェクト(エクスポートで直接使える)
まだ時期尚早なケース
- 大規模な既存デザインシステムをすでに運用している企業(移行コストが高い)
- フォーマットの安定性が求められるプロダクション環境(アルファ版のため)
- デザインの自由度よりも厳密なピクセルパーフェクトが求められる受託案件
まとめ
DESIGN.mdは「AIにデザインの意図を伝える」という、これまでありそうでなかったニーズを解決するシンプルなフォーマットです。1つのMarkdownファイルをプロジェクトに置くだけで、AIが生成するUIの品質が格段に向上します。
アルファ版ではあるものの、Apache 2.0で公開されており、100種類以上のテンプレートがコミュニティから提供されています。Googleが業界標準を目指して仕様策定を進めている点も、今後の普及を期待させます。
AIコーディングエージェントを使ってUIを生成する機会がある方は、まずは既存のテンプレートをプロジェクトに配置してみることをおすすめします。30秒の作業で、AIの出力品質の違いを体感できるはずです。
はてなベースでは、DESIGN.mdの導入支援を含め、最新AIツールを業務に組み込むための支援を行っています。
-
AIエージェント組み込みサポート
既存業務フローへのAIエージェント導入を設計から実装まで支援します -
データ基盤の整備
AIエージェント活用の前提となるデータ統合・整理を支援。散在するデータを一元化し、AI活用の土台をつくります -
オンプレミスAI導入支援
「全社でAIを使いたいがセキュリティが心配」という企業向けに、オンプレミス環境での生成AI導入を支援します
DESIGN.mdとは?GoogleがオープンソースにしたAI時代のデザインシステム規格を解説
最終更新 2026.04.24
関連記事

いつの間にかやってしまっていない?AI時代の著作権問題|2026年最新の訴訟事例と企業の5つの対策
いつの間にかやってしまっていない?AI時代の著作権問題 2026年最新の訴訟事例と文化庁の2段階整理をもとに、生成AI利用で企業が直面する著作権リスクと実践的な対策を解説 2026.04.25 はてなベース株式会社 この

ClaudeがSpotify・Uber・Booking.comと連携開始|200以上の外部サービスをAIから直接操作する時代へ
Claudeが「なんでも頼めるアシスタント」に進化した Spotify・Uber・Booking.comなど200以上のサービスと直接連携。その仕組みは、企業のDXにも直結する この記事のポイント 2026年4月23日、

【GitHub非エンジニア入門 5/5】組織導入と運用|権限・セキュリティ・社内浸透のコツ
GitHub 非エンジニア入門シリーズ(全5回) Part 1/5 GitHubとは何か Part 2/5 アカウント作成と最初のリポジトリ Part 3/5 編集・履歴・チーム共有 Part 4/5 AI用コンテキスト

【GitHub非エンジニア入門 4/5】AI用コンテキストをGitHubで管理する実践|CLAUDE.md・Skills・社内ナレッジを集約
GitHub 非エンジニア入門シリーズ(全5回) Part 1/5 GitHubとは何か Part 2/5 アカウント作成と最初のリポジトリ Part 3/5 編集・履歴・チーム共有 ▶ Part 4/5

【GitHub非エンジニア入門 3/5】編集・履歴・チーム共有|ブラウザだけで使うGitHubコラボレーション
GitHub 非エンジニア入門シリーズ(全5回) Part 1/5 GitHubとは何か Part 2/5 アカウント作成と最初のリポジトリ ▶ Part 3/5 編集・履歴・チーム共有(本記事) Part

【GitHub非エンジニア入門 2/5】アカウント作成と最初のリポジトリ|ブラウザだけで始めるGitHub
GitHub 非エンジニア入門シリーズ(全5回) Part 1/5 GitHubとは何か ▶ Part 2/5 アカウント作成と最初のリポジトリ(本記事) Part 3/5 編集・履歴・チーム共有 Part