Google Labsは2026年4月22日、AIデザインツール「Stitch」で用いているDESIGN.mdのドラフト仕様をApache 2.0ライセンスで公開した。色、書体、余白、角丸、コンポーネントの値をYAMLで書き、なぜその値を使うのかをMarkdown本文で説明するファイル形式だ。Stitch内のプロジェクト引き継ぎ機能にとどめず、GitHub上の仕様とCLIとして切り出した点が今回新しい。AIエージェントに「ブランドらしく作って」と毎回説明する代わりに、リポジトリ内の設計ルールを読ませ、検証可能な制約として扱わせる狙いだ。
Stitch内の記憶から、ツール横断の設計ファイルへ
Googleは2026年3月18日、Stitchを自然言語から高忠実度のUIを作るAIネイティブなデザインキャンバスへ拡張したと発表していた。この時点でStitchには、任意のURLからデザインシステムを抽出したり、DESIGN.mdを使って別プロジェクトや外部のデザイン・コーディングツールへ設計ルールを渡したりする機能が含まれていた。今回の公開は、そのDESIGN.mdをStitch専用の入出力形式から、単独で読める仕様と実装へ近づける動きである。
Googleの公式ブログは、DESIGN.mdを使うことで、Stitchがデザインシステムの背後にある理由を理解し、ブランドに合ったユーザーインターフェースを生成できると説明している。2026年4月22日の発表では、AIエージェントが色の意図を推測するのではなく、何のための色かを知り、WCAGのアクセシビリティルールに照らして選択を検証できるとした。THE DECODERは、このファイル形式がプロジェクトやプラットフォームをまたいで動く、AIエージェント向けの「prompt-ready」な設計図だと位置付けている。
公開先はGoogle Labs CodeのGitHubリポジトリで、ライセンスはApache 2.0である。リポジトリの説明文は、DESIGN.mdを「visual identityをcoding agentsに説明するためのformat specification」としている。GitHub上ではREADME、仕様書、CLI、例、ワークフローが確認でき、現時点のステータスはalphaで、仕様とトークンスキーマ、CLIは今後変わり得ると明記されている。
YAMLの正確な値と、Markdownの理由を一つの文書に置く
DESIGN.mdの中核は、YAML front matterとMarkdown本文の二層構造である。YAML側には、colors、typography、rounded、spacing、componentsといったデザイントークンを置く。色はsRGBの16進表記、寸法はpx、em、remなどの単位付き値、参照は{colors.primary}のようなパス表記で書く。コンポーネントにはbackgroundColor、textColor、typography、rounded、padding、height、widthなどのプロパティを持たせられる。
Markdown本文は、数値だけでは伝わらない設計意図を補う。仕様書は、Overview、Colors、Typography、Layout、Elevation & Depth、Shapes、Components、Do's and Don'tsという順序を示している。例えば「Primaryは見出しと主要テキストのための深いインク色」「Tertiaryは主要アクションだけに使うアクセント色」といった説明を添えることで、AIエージェントは単なるカラーパレットではなく、使いどころの制約まで読める。
この構造は、従来のデザイントークンJSONとも、単なるプロンプト文書とも少し違う。トークンは規範的な値として扱われ、本文は適用の文脈を与える。仕様書はW3C Design Tokens Formatの考え方に触発されていると説明し、tokens.json、Figma variables、Tailwind theme configsとの変換可能性にも触れている。ただし、DESIGN.md自体がW3C標準になったわけではなく、Googleが公開したドラフト仕様として見るのが正確である。
GitHub READMEの例では、DESIGN.mdを読んだエージェントが、Public Sansの見出し、温かい石灰色の背景、Boston ClayのCTAボタンを持つUIを作ると説明されている。デザインの説明は会話履歴や一回限りのプロンプトに閉じない。リポジトリに置けるプレーンテキストであれば、複数のAIコーディングエージェント、デザインツール、レビュー手順が同じ設計情報を参照できる。
CLIはlint、diff、exportで設計ルールを機械的に扱う
GoogleはDESIGN.mdと同時に、@google/design.mdというCLIも用意している。READMEでは、npx @google/design.md lint DESIGN.mdで構造を検証し、壊れたトークン参照、WCAG AAのコントラスト比、構造上の問題をJSONで返す例が示されている。diffは2つのDESIGN.mdを比較し、色や書体などのトークン変更と回帰の有無を報告する。exportはTailwind theme configやW3C DTCG形式のtokens.jsonへ出力する。
lintルールは7種類に整理されている。broken-refは未定義トークンへの参照をエラーにし、contrast-ratioはコンポーネントの背景色と文字色がWCAG AAの4.5:1を下回る場合に警告する。missing-primary、orphaned-tokens、missing-typography、section-orderなどもあり、エージェントが生成後に人間へ曖昧な感想を返すのではなく、構造化された指摘として修正に回せる。
AIによるUI生成では、自然言語だけで「自社らしいSaaS管理画面」や「既存ブランドに合うモバイルアプリ」を頼むと、最初の画面はそれらしくても、次の画面で余白、角丸、色の役割、ボタン状態が崩れやすい。DESIGN.mdは、完成品を保証する魔法ではないが、ブランドの設計情報をファイル化し、AIが読み、検証し、差分を追える形へ落とす。最初に試すなら、既存のブランドガイドから主要色、本文フォント、ボタン、カード、フォームだけを抜き出し、lintで参照切れとコントラストを確認する使い方が現実的である。
仕様の柔軟さは運用時の注意点にもなる。未知のセクション見出しは保持され、未知の色名や書体名も値が妥当なら受け入れられる。未知のコンポーネントプロパティは警告で済み、重複したセクション見出しはエラーになる。厳密なデザインシステムを期待する企業ほど、DESIGN.mdだけで統制できる範囲と、既存のFigmaライブラリ、Storybook、アクセシビリティレビュー、ブランドガイドラインで見る範囲を分ける必要がある。
alpha仕様の価値は、AIデザインの共通語を先に置いた点にある
2026年4月時点のAIデザイン領域では、GoogleのStitchだけでなく、AnthropicのClaude Designもプロトタイプやプレゼン資料を会話から作る方向へ広がっている。THE DECODERは、Claude Designがコードベースやデザインファイルを読んで、色、書体、コンポーネントを含むデザインシステムを新しいプロジェクトへ適用できると報じている。各社のツールが「デザインを生成する」だけでなく、「デザインシステムを読んで再利用する」方向へ寄っている。
DESIGN.mdの差分は、そこで特定ツールの内部メモリではなく、外へ持ち出せるテキスト仕様を先に置いた点にある。GitHubに置けるMarkdownファイルなら、AIエージェントのコンテキスト、コードレビュー、CI、デザインハンドオフの間を移動しやすい。CLIのspecコマンドは仕様自体をエージェントのプロンプトに注入する用途も想定しており、DESIGN.mdは「作例」よりも「作る前に読む制約」として設計されている。
alpha段階の仕様をそのまま企業の標準基盤にするには早い。READMEは、仕様、スキーマ、CLIが活発に開発中で、成熟まで変更を想定すべきだと書いている。日本の開発現場で使う場合も、日本語のブランドガイド、和文フォント、禁則処理、アクセシビリティ表現、既存コンポーネント命名規則をどう書くかは各社で詰める必要がある。Figma variablesやtokens.jsonを正本として持つ組織では、DESIGN.mdを置き換え先ではなく、AIエージェントに意図と制約を渡す派生ファイルとして扱う方が導入しやすい。
GoogleがDESIGN.mdを公開した意味は、AIによるUI生成を「毎回プロンプトで雰囲気を説明する作業」から、「リポジトリに置いた設計契約を読ませる作業」へ寄せたことにある。ブランド一貫性、アクセシビリティ、差分管理をAI生成後の手直しだけで抱えるのではなく、生成前の入力として構造化する。alpha仕様である以上、採用には検証が要るが、AIエージェント時代のデザインシステムをファイルとして持ち運ぶ発想は、フロントエンド開発の前処理として試す価値がある。
Sources