はじめに
Google Labsが2026年4月21日、AIエージェント向けのデザインシステム記述フォーマット「DESIGN.md」のドラフト仕様をオープンソースで公開しました。本稿では、DESIGN.mdの仕組みとCLIツールの機能、そしてAIが主導するUI開発への影響について解説します。
参考記事
- タイトル: Stitch’s DESIGN.md format is now open-source so you can use it across platforms.
- 著者: Cassia Xu
- 発行元: Google Labs Blog
- 発行日: 2026年4月21日
- URL: https://blog.google/innovation-and-ai/models-and-research/google-labs/stitch-design-md/
参考（GitHub リポジトリ）:
関連記事
要点
- DESIGN.mdはYAMLフロントマターとMarkdownボディの2層構造で、AIエージェントにデザイントークンの「値」と「意図」を同時に伝えるフォーマットである
- 今回の仕様オープンソース化により、Stitch以外のあらゆるツール・プラットフォームで利用できるようになった
- @google/design.md CLIパッケージが公開されており、lint（構造検証）・diff（差分検出）・export（他フォーマット変換）・spec（仕様出力）の4コマンドが使える
- lintコマンドはWCAGアクセシビリティ基準のコントラスト比チェックやトークン参照の欠損検出など、7つのルールに対応している
- 仕様はalpha版であり、GitHubでコントリビュートを受け付けている
詳細解説
DESIGN.mdとは何か
DESIGN.mdは、視覚的なデザインシステムをAIエージェントに伝えるための構造化フォーマットです。ファイルは2層で構成されています。1つ目はYAML フロントマター（ファイル先頭の — 区切り部分）で、カラーコード・タイポグラフィ・スペーシング・角丸などのデザイントークンを機械可読な形式で記述します。2つ目は Markdown ボディで、「なぜそのデザインにしたのか」という意図や適用方針を人間可読な散文で記述します。
例えば、あるデザインシステムでは #B8422E というカラーを定義し、「このカラーは唯一のインタラクション要素として機能するアクセントカラーである」と散文で説明します。AIエージェントはトークンの値だけでなく、その意図を参照することで、ブランドに沿ったUIをより正確に生成できると考えられます。従来のCSSトークンやFigmaファイルの共有では、値は渡せても「なぜその値なのか」まではエージェントに伝えにくい側面がありました。DESIGN.mdはその橋渡しを担う設計だと言えます。
オープンソース化の背景と意義
DESIGN.mdはもともと、Google Labsのビジュアルデザインツール「Stitch」の機能として2026年3月に導入されました（https://jobirun.com/google-stitch-vibe-design-ai-canvas/）。Stitch内では、デザインルールをプロジェクト間でエクスポート・インポートする仕組みとして機能していました。
今回の仕様オープンソース化によって、特定ツールに依存せずどのコーディングエージェントやデザインプラットフォームでも同フォーマットを共有できるようになります。Google Labsによれば、AIエージェントはカラーの目的を正確に把握し、WCAG（ウェブコンテンツアクセシビリティガイドライン）のルールに照らして選択を検証できるようになるとのことです。仕様はApache 2.0ライセンスで公開されており、GitHubでのコントリビュートも歓迎されています。
CLIツールの4つのコマンド
@google/design.md NPMパッケージには4つのコマンドが含まれています。
lint は、DESIGN.mdファイルの構造的な正確性を検証します。7つのルールが実行され、結果はJSON形式で返されます。主なルールには、トークン参照の欠損（broken-ref）、コンポーネントのWCAGコントラスト比チェック（AA基準: 4.5:1以上）、定義済みだが未参照のトークン（orphaned-tokens）などが含まれます。アクセシビリティ検証をコマンド一発で実行できる点は、開発フローへの組み込みがしやすいと思います。
diff は、2つのバージョンのDESIGN.mdを比較し、トークンレベルの変更（追加・削除・変更）を検出します。「以前のバージョンからどのカラーが変わったか」を構造化されたJSONで把握できるため、デザインシステムのバージョン管理に活用できると考えられます。
export は、トークンをTailwind設定形式またはW3C Design Tokens Format（DTCG）形式に変換します。既存の開発環境へDESIGN.mdのトークンを持ち込む際の移行コストを抑える仕組みだと言えます。
spec は、DESIGN.md仕様自体をMarkdownまたはJSON形式で出力します。エージェントのシステムプロンプトに仕様を注入する際に利用できます。
ファイル構造とトークンスキーマ
DESIGN.mdのトークンスキーマは、name（必須）・colors・typography・rounded・spacing・components の各セクションで構成されます。各セクションは省略可能ですが、存在する場合は「Overview → Colors → Typography → Layout → Elevation → Shapes → Components → Do’s and Don’ts」の順序で記述する必要があります（順序違反はlintの警告対象）。
コンポーネントトークンは button-primary のようなキー名でグループ化し、backgroundColor・textColor・rounded・padding などのプロパティを指定します。ホバーやアクティブ状態は button-primary-hover のように別エントリーで表現します。また、{colors.primary} のようなトークン参照構文を使うことで、値の変更が関連コンポーネント全体に伝播する仕組みになっています。
未知のセクション見出しや未知のトークン名はエラーにならず保持・受け入れられる設計になっており、仕様の拡張性への配慮が感じられます。
まとめ
Google LabsがDESIGN.mdをオープンソース化したことで、AIエージェントとデザインシステムの連携が特定ツールに依存せず実現できる基盤が整いつつあります。仕様はまだalpha段階であり、今後フォーマットに変更が加わる可能性がある点には注意が必要だと思います。Anthropicの「Claude Design」など、AIデザインツールが各社から相次いで登場している流れのなかで（https://jobirun.com/anthropic-claude-design-launch-visual-creation/）、設計意図の標準的な記述方法がどこまで広がるか、注目していきたいところです。
