Google Labsがdesign.md仕様をOSSで公開―AIエージェントのデザイン制御が標準化へ
Google Labsがdesign.md仕様をOSSで公開
2026年4月21日、Google Labsはdesign.mdリポジトリをGitHub上で公開した。スター数はすでに2,800件を超えており、公開から2日で急速な注目を集めている。
- リポジトリ名:
google-labs-code/design.md（Apache License 2.0） - npmパッケージ:
@google/design.md（v0.1.0・2026年4月21日リリース） - Google Stitch（AIデザインツール）と統合される公式仕様
- TypeScript実装、Bun + Turborepoのモノレポ構成
- 公開2日でスター2,860件・フォーク203件
このリポジトリは、AIエージェントに対してビジュアルアイデンティティ（デザインシステム）を説明するためのフォーマット仕様書と、そのCLIツール群を提供する。一言でいえば「AIがUIを生成するときに読む設計書の標準フォーマット」をGoogleが公式に定義したものだ。
Google Labs公式ブログ「Stitch & DESIGN.md: From design to code with AI」では、DESIGN.mdがデザインルールのポータビリティを実現し、AIがWCAGアクセシビリティ規則に対する選択を自動検証できるようになると説明されている。
当サイトではこれまで、コミュニティ主導のdesign.mdフォーマットをawesome-design-mdやDESIGN.md入門として紹介してきた。今回の発表は、そのフォーマットをGoogleが公式に採用・標準化したことを意味する重要なマイルストーンだ。
DESIGN.mdの2層構造：トークンと散文の融合
DESIGN.mdファイルは、以下の2層で構成される。
┌─────────────────────────────────────┐
│ YAML front matter │
│ （機械可読デザイントークン） │
│ --- で区切られたYAMLブロック │
├─────────────────────────────────────┤
│ Markdown本文 │
│ （人間向けデザイン根拠・ガイドライン） │
│ ## セクション見出しで構造化 │
└─────────────────────────────────────┘
上層のYAMLが「何を」定義し、下層のMarkdownが「なぜ」そうするかを説明する。この設計思想により、AIエージェントは正確なカラーコードや寸法を読み取りながら、デザインの文脈や意図も同時に理解できる。
以下は公式READMEにある最小構成例だ。
---
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
---
## Overview
Architectural Minimalism meets Journalistic Gravitas. The UI evokes a
premium matte finish — a high-end broadsheet or contemporary gallery.
## Colors
- **Primary (#1A1C1E):** Deep ink for headlines and core text.
- **Secondary (#6C7278):** Sophisticated slate for borders, captions, metadata.
- **Tertiary (#B8422E):** "Boston Clay" — the sole driver for interaction.
- **Neutral (#F7F5F2):** Warm limestone foundation, softer than pure white.
このファイルを読んだAIエージェントは、「深いインクカラー（#1A1C1E）でPublic Sansのヘッドライン、暖かいライムストーンの背景（#F7F5F2）、ボタンはBoston Clay（#B8422E）」という一貫したUIを生成できる。
トークンスキーマの仕様
公式仕様書（docs/spec.md）が定義するYAMLスキーマは、name・colors・typography・rounded・spacing・componentsの6つのトップレベルキーで構成される。バージョンは現在alphaで、積極的に開発中だ。
4種類のトークン型
| 型 | フォーマット | 例 |
|---|---|---|
| Color | # + 16進数（sRGB） |
"#1A1C1E" |
| Dimension | 数値 + 単位（px/em/rem） | 48px, -0.02em |
| Token Reference | {path.to.token} |
{colors.primary} |
| Typography | fontFamily/fontSize/fontWeight等のオブジェクト | — |
コンポーネントはToken Referenceを使って定義する。たとえばbutton-primaryの背景色を{colors.tertiary}と書くと、colors.tertiaryの値が実際の色として解決される。ホバー・プレスのバリアントはbutton-primary-hoverのように名前付きエントリとして表現する。
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 | — |
省略は可能だが、順序が違う場合はlintで警告が出る。
CLIツール：lint / diff / export / spec
@google/design.mdパッケージは4つのコマンドを提供する。npx @google/design.md [コマンド] DESIGN.mdの形式で実行でき、インストール不要で使い始められる。
| コマンド | 役割 | 主な用途 |
|---|---|---|
lint |
7つのルールで仕様を検証 | CI組み込み・品質チェック |
diff |
2つのDESIGN.mdのトークン差分を検出 | デザイン変更レビュー |
export |
TailwindやW3C DTCG形式に変換 | 既存ツールとの連携 |
spec |
フォーマット仕様書を出力 | AIエージェントのシステムプロンプト注入 |
lintコマンドは7つのルールを実行し、エラー・警告・情報をJSON形式で出力する。終了コードはエラーがあれば1、なければ0のため、CIパイプラインに直接組み込める。Windowsでは.md拡張子がファイル関連付けと衝突するため、designmdエイリアスが用意されている。
diffコマンドは2ファイルを比較し、追加・削除・変更されたトークンをJSON形式で出力する。「after」ファイルのエラー・警告が増加した場合はリグレッションと判定し、終了コード1を返す。
specコマンドはDESIGN.mdフォーマット仕様書そのものを出力する。AIエージェントのシステムプロンプトに注入し、エージェントがDESIGN.mdを正確に解釈できるようにするユースケースを想定している。
7つのlintルール
linterは7種類のルールを実行する。
| ルール | 重大度 | 検証内容 |
|---|---|---|
broken-ref |
error | {colors.primary}等のトークン参照が解決できない |
missing-primary |
warning | colorsは定義されているがprimaryカラーがない |
contrast-ratio |
warning | コンポーネントのbg/textペアがWCAG AA（4.5:1）未満 |
orphaned-tokens |
warning | 定義されているがどのコンポーネントからも参照されないカラートークン |
token-summary |
info | 各セクションのトークン定義数の集計 |
missing-sections |
info | 他トークンが存在するのにspacingやroundedセクションがない |
missing-typography |
warning | colorsは定義されているがtypographyトークンがない |
contrast-ratioルールがWCAGアクセシビリティを自動チェックする点は特に重要だ。デザイン仕様を書いた時点でアクセシビリティ問題を検出でき、実装後の修正コストを削減できる。
WCAG AA基準（コントラスト比4.5:1）を満たさない色の組み合わせをlint時に自動検出する。これはデザインシステムレベルでのアクセシビリティ保証を意味する。Google Labsのアプローチが「後から修正」ではなく「仕様書段階で予防」を重視していることがわかる。
実際のDESIGN.mdの例：3つのサンプル
リポジトリにはexamples/ディレクトリに3つのサンプルデザインが収録されており、それぞれのビジュアルコンセプトと配色方針が異なる。
| サンプル名 | コンセプト | カラーパレットの特徴 |
|---|---|---|
| atmospheric-glass | ダーク系・宇宙的な配色・Glass UI | ダークネイビー背景、ソフトブルーのアクセント |
| paws-and-paths | ペット向けサービス・温かみのある配色 | アースカラー、暖色系プライマリ |
| totality-festival | イベント・フェスティバル向けの大胆な配色 | 高彩度・コントラスト重視 |
各サンプルにはDESIGN.md（仕様書）、design_tokens.json（トークンデータ）、tailwind.config.js（Tailwind設定）の3ファイルが含まれており、exportコマンドの出力との互換性を示している。awesome-design-mdの58ブランドサンプルと合わせて参照すると、様々なデザインスタイルの表現方法が把握できる。
Google Stitchとの統合
このリポジトリの背景にあるのが、Google Labsが開発するStitch（AIを使ったデザインツール）だ。公式ホームページはhttps://stitch.withgoogle.com/docs/design-md/specificationに設置されており、DESIGN.mdはStitchのコア仕様として位置づけられている。
Google公式ブログによれば：
- DESIGN.mdを使うとデザインルールをプロジェクト間でエクスポート・インポートでき、「デザインシステムの基礎を毎回一から作り直す必要がなくなる」
- AIエージェントが色の用途を正確に把握し、WCAGアクセシビリティ規則に対する選択を自動検証できる
- ユーザーはStitchで独自ファイルを生成し、GitHubでプロジェクトに貢献できる
Stitchは従来のFigmaやCanvaのような手動デザインツールとは異なり、AIが設計の意思決定を支援する方向性を持つ。DESIGN.mdはその「AIとデザイナーの共通言語」として機能する。
同様の発想をAnthropicも持っており、Claude Designはコードベースからデザインシステムを自動抽出してプロトタイプを生成するAIデザインツールだ。Google StitchとClaude Designはアプローチが異なるが、どちらもDESIGN.mdを起点にした「デザイン仕様→AI生成」のワークフローと相性がよい。デザインツール側でDESIGN.mdを出力し、コーディングエージェント側でそれを読む、という分業が自然に成立する。
（Stitch）"] B["DESIGN.md"] C["@google/design.md
CLI"] D["AIエージェント
（Claude Code/Cursor等）"] E["生成UI
（コード）"] A -->|"仕様書を作成"| B B -->|"lint/diff/export"| C C -->|"検証済みトークン"| D D -->|"デザイン仕様通りに生成"| E B -->|"直接参照"| D
awesome-design-mdとの位置関係
当サイトで以前紹介したawesome-design-md（VoltAgent/awesome-design-md）は、コミュニティが作成した58種類（＋日本語24種類）のDESIGN.mdサンプル集だ。npx getdesign@latest add [ブランド名]で素早く導入できるリソース集として人気を集めている。
今回の@google/design.mdはフォーマット仕様とlintツールを提供するものであり、両者は以下のように役割が異なる。
| awesome-design-md | @google/design.md | |
|---|---|---|
| 提供元 | VoltAgent（コミュニティ） | Google Labs（公式） |
| 内容 | サンプルDESIGN.mdの集合体 | フォーマット仕様 + CLIツール |
| 用途 | スターター・参照・コピー元 | 検証・変換・仕様確認 |
| インストール | npx getdesign@latest |
npx @google/design.md |
awesome-design-mdで作成したファイルを@google/design.md lintで検証するというワークフローが自然に成立する。DESIGN.md入門記事でフォーマットの基本を押さえたうえで、awesome-design-mdのサンプルをlintにかけてみるのが最初の一歩としておすすめだ。
W3Cデザイントークンとの互換性
DESIGN.mdのトークン設計はW3C Design Token Format（DTCG）にインスパイアされており、特に「型付きトークングループ」の概念と{path.to.token}参照構文を採用している。
exportコマンドは以下の2形式に対応する。
- Tailwind theme config：
--format tailwindオプションで出力。Tailwind CSSプロジェクトに直接取り込める形式 - W3C DTCG tokens.json：
--format dtcgオプションで出力。Figma変数、Style Dictionary等との互換形式
これにより、DESIGN.mdはAIエージェント用のフォーマットにとどまらず、デザインシステムのエコシステム全体の接続点としても機能する。FigmaのデザインデータをDTCG形式でエクスポートし、DESIGN.mdに組み込んで再利用するといった双方向の連携も視野に入る。
AI MDファイル群の標準化の流れ
現在、AIコーディングツールはそれぞれ独自のMDファイルを定義している。AI時代におけるMDファイル整理ガイドで紹介したように、CLAUDE.md・AGENTS.md・.cursorrules・GEMINI.mdといったファイルが乱立している状況だ。
DESIGN.mdはその中でもデザインシステム専用のMDファイルとして、今回Googleが公式に仕様を制定した。
（Claude Code用）"] C["AGENTS.md
（OpenAI Codex用）"] D["DESIGN.md
（UIデザイン仕様）"] E[".cursorrules
（Cursor用）"] A --> B A --> C A --> D A --> E style D fill:#4285f4,color:#fff
デザインシステム入門ガイドで解説したように、デザインシステムは「色・フォント・コンポーネントの共通言語」だ。DESIGN.mdはそれをAIエージェントが理解できる機械可読な形式に落とし込んだものと考えればよい。
v0.1.0の詳細：リリースノートから読む
2026年4月21日に公開されたv0.1.0では、以下の4つの主要機能が実装されている。
- Design System Linter：仕様検証、未解決参照、循環依存、無効なトークン値の検出
- Spec Generator：コアスキーマから人間可読な仕様書を生成
- Agent-First Design：決定論的JSON出力、サイレント実行モード（AIエージェント向け最適化）
- Clean JSON Output：デバッグログを排除し、パイプ処理やAIエージェントに安全な純粋JSON出力
「Agent-First Design」という表現が示すように、このCLIはAIエージェントがDESIGN.mdを処理するパイプラインに組み込まれることを前提に設計されている。決定論的なJSON出力と、stdoutを汚染しないサイレント実行がその証拠だ。また、Windows環境でのシェル互換性問題と、モジュール読み込みクラッシュの修正も同バージョンで対応されている。
開発体制と技術スタック
google-labs-code/design.mdリポジトリは、TypeScript製のCLIパッケージ（packages/cli/）と自動生成の仕様書（docs/spec.md）、3つのサンプルデザイン（examples/）から構成されるモノレポだ。
| 項目 | 内容 |
|---|---|
| 言語 | TypeScript |
| ランタイム | Node.js 18以上 / Bun対応 |
| ビルドシステム | Turborepo（モノレポ管理） |
| ライセンス | Apache License 2.0 |
| コントリビューション | CONTRIBUTING.mdあり |
特筆すべきは.agents/ディレクトリの存在だ。リポジトリ自体がAIエージェントとの協働を前提として設計されていることを示しており、DESIGN.mdがAIツールのエコシステムに深く組み込まれる意図が見える。
今後の展望：alphaからの進化
現状、DESIGN.mdフォーマットはバージョンalphaとして位置づけられており、公式READMEにも「スペック、トークンスキーマ、CLIは積極的に開発中。フォーマットが成熟するにつれ変更が予想される」と明記されている。
今後の注目点は以下の通りだ。
- Stitch本番統合：Google Stitchとの深い統合が進めば、デザインからコードへの自動変換が標準ワークフローになる可能性がある
- W3C標準化：DTCGとの互換性を持つことで、W3Cデザイントークン標準との整合が進むかもしれない
- IDE拡張：VS CodeやJetBrainsからDESIGN.mdをリアルタイムlintする拡張が登場する可能性
- AIデザインツール連携：Claude DesignやFigma AIがデフォルトでDESIGN.mdを出力・読み込む対応を加えれば、デザインと開発のハンドオフが標準化される
AIコーディングの現場でvibe codingが広まる中、デザインの一貫性を担保する仕組みとしてDESIGN.mdの位置づけはますます重要になる。AIにUIを作らせれば作らせるほど、仕様書なしでは「毎回違うデザイン」の問題が顕在化するからだ。
Google Labsがフォーマット仕様をOSSとして公開したことは、DESIGN.mdをGoogleのツール（Stitch）だけでなく、Claude Code・Cursorなど競合を含むあらゆるAIコーディングツールでの利用を想定した「オープンスタンダード戦略」と読める。Anthropicのmodel cardやOpenAIのSWE-benchと同様に、業界標準を握ることで生態系の中心に立とうとする動きだ。
まとめ
Google Labsが@google/design.md v0.1.0をリリースしたことで、これまでコミュニティ主導で育ってきたDESIGN.mdフォーマットが、Googleが公式に定義する仕様書へと格上げされた。
- 既存プロジェクトに
DESIGN.mdを作成する（DESIGN.md入門記事を参照） npx @google/design.md lint DESIGN.mdで品質検証を実施する- awesome-design-mdから好みのスタイルをコピーして、自分のプロジェクトに合わせてカスタマイズする
- CIパイプラインに
lintコマンドを追加してデザイン品質を自動チェックする - Claude Designや Google Stitchと組み合わせて、AIデザイン→コード生成のワークフローを試す
AI UIが「毎回同じデザイン」で出力される世界への一歩として、DESIGN.mdは今後のAIコーディングワークフローにとって欠かせない標準となっていく可能性が高い。
参照ソース
