AI時代のデザインシステム実践 第2回 DESIGN.md という新しいフォーマットの衝撃

追補ノート（2026年4月18日）
本連載は2026年4月16日に執筆を完了したのですが、公開準備を進めていた翌17日、Anthropic Labs から Claude Design が発表されました。連載で論じてきた「AIがデザインシステムを読む時代」が、製品として具体化した瞬間です。
この発表を受けて、連載に 第6回「追補 — 予測が実装になった一週間」 を書き下ろしました。第1〜5回の本文は執筆時のまま残し、「予測が実装に追い抜かれた瞬間」の記録として公開します。

たった一枚の Markdown が変えるもの

前回は、AI が出力する凡庸さを見抜き、言葉で正す力がデザイナーの武器になるという話をしました。今回は、その武器を収める鞘——つまり DESIGN.md というフォーマットそのものに踏み込みます。

DESIGN.md は、Google Labs の Stitch が 2026年初頭に打ち出し、2026年3月18日の Stitch "vibe design" アップデートでデザインシステム機能の中核として正式に位置づけられた概念です。その正体は、拍子抜けするほどシンプルです。プロジェクトのビジュアル・デザインシステムを、Markdown 1枚で書いたファイル。それだけです。

特別なツールは不要。JSON スキーマも、Figma プラグインも、専用の SaaS も要りません。テキストエディタで開けて、Git で差分管理できて、誰でも読めて、AI にもそのまま渡せる。

この「それだけ」が、なぜ衝撃なのか。それを理解するために、まずデザインシステムの情報が今までどこに住んでいたのかを振り返ってみましょう。

デザインの言葉が住んでいた場所

デザインシステムの情報は、歴史的に複数の場所に散らばって保管されてきました。

Figma や Sketch のファイルには、色やコンポーネントの視覚的な定義が入っています。人間のデザイナーには直感的に分かりやすいものの、AI コーディングエージェントにとっては解析が困難です。MCP（Model Context Protocol）サーバー経由で接続すれば読めなくもないのですが、「この画面のこの緑は #10b981 です」くらいの情報がようやく取れる程度で、なぜその緑なのかは伝わりません。

Brand PDF は、代理店やデザインチームが作る美しいガイドラインブックです。人間にとっては素晴らしい読み物ですが、AI にとっては画像埋め込みの PDF はほぼブラックボックスです。差分レビューもバージョン管理もできません。

Design Tokens JSON（Style Dictionary など）は、色やサイズの数値を構造化して管理する形式です。AI にも読めますし、バージョン管理もできます。しかしここには数値しか入りません。「なぜ weight-300 なのか」「なぜ Inter なのか」という設計意図は、JSON には書けないのです。

Storybook / MDX は、コンポーネントのドキュメントとしては優秀ですが、デザインシステム全体の哲学や空気感を伝えるためのフォーマットではありません。個々のボタンの使い方は分かるけれど、ブランド全体がどういう"表情"を持つべきかは分からない。

デザインシステムの情報がどこに住んでいたかの概念図。Figma に色、JSON にトークン、PDF に哲学、Storybook にコンポーネント——それぞれバラバラに存在していたものが、DESIGN.md に統合される。

ここに DESIGN.md が登場します。

DESIGN.md は、これらすべてを1枚のテキストファイルに統合するためのフォーマットです。色の HEX コード（JSON の領域）も、ブランドの哲学（PDF の領域）も、コンポーネントの振る舞い（Storybook の領域）も、すべてが一枚の Markdown に共存できる。しかもその Markdown は、人間がそのまま読めて、AI がネイティブに解釈できて、Git で差分レビューできて、PR でレビュー対象にできる。

これが「それだけ」の正体です。今まで散らばっていたものを、全員が読める1枚に集約する。言ってしまえばそれだけのことなのですが、だからこそ衝撃的です。

なぜ Markdown なのか

ここでひとつ、素朴な疑問が浮かぶかもしれません。「なぜ Markdown なんだ」と。YAML でも TOML でも XML でも良いじゃないか、と。

答えは明快です。Markdown は、LLM（大規模言語モデル）が最もよく訓練されているテキスト形式だからです。

GitHub の README、技術ブログ、ドキュメントサイト、Wiki——インターネット上の膨大なテキストの中で、Markdown は圧倒的な量が LLM の訓練データに含まれています。見出し階層（##）、パイプテーブル（| column |）、コードブロック（```）。これらの構造は、LLM のアテンション機構にそのままマップされるため、パースの工程なしに「どこに何が書いてあるか」を AI が即座に理解できます。

JSON は構造化に優れていますが、散文（自然言語の説明文）との相性が悪い。YAML は設定ファイルとしては優秀ですが、長文の哲学的記述を入れるには不自然です。Markdown だけが、数値と散文と構造を、ひとつのファイルで自然に共存させられるフォーマットなのです。

そしてもうひとつ。Markdown は人間が書きやすく、読みやすい。これは見落とされがちですが、非常に重要な性質です。DESIGN.md は、デザイナーが書くファイルです。JSON を書きたいデザイナーは（おそらく）あまりいませんが、Markdown なら、ほぼ普通の文章を書く感覚で取り組めます。

三層構造：README / AGENTS / DESIGN

DESIGN.md は、単独で存在する概念ではありません。ソフトウェアプロジェクトの「ドキュメント新秩序」の一部として理解する必要があります。

2025年8月、OpenAI が AGENTS.md というオープンフォーマットを発表しました。これは「AI コーディングエージェントのための README」と位置づけられるファイルで、ビルドコマンド、テストの走らせ方、コーディング規約、ディレクトリ構造、やってはいけないことなどを、エージェントが読みやすい形で記述するフォーマットです。

AGENTS.md は急速に業界標準化が進み、2025年12月には Linux Foundation 傘下の Agentic AI Foundation（AAIF）に寄贈され、ベンダーニュートラルな標準として管理されることになりました。AAIF には OpenAI、Anthropic、Block、Google、Microsoft、AWS、Bloomberg、Cloudflare が創設メンバーとして参画しています。Anthropic の Model Context Protocol（MCP）、Block の goose、そして OpenAI の AGENTS.md の三つが、AAIF の創設プロジェクトです。

2026年4月時点で、AGENTS.md は 60,000 を超えるオープンソースプロジェクトで採用されています。対応するエージェントとツールも、Cursor、GitHub Copilot、VS Code、Gemini CLI、Devin、Amp、Windsurf、OpenAI Codex、Jules（Google）など、ほぼ主要プレイヤーを網羅しています。

Claude Code を使っている方には CLAUDE.md の方が馴染みがあるかもしれません。中身は AGENTS.md とほぼ同じ思想で、シンボリックリンクで相互参照させる使い方も一般的です。

この流れの中で、Google Stitch が打ち出したのが DESIGN.md です。三つのファイルの役割を、横並びで比較してみましょう。

README.md は人間が読む。AGENTS.md は AI に「どう作るか」を伝える。DESIGN.md は AI に「どう見えるべきか」を伝える。

この三つが揃うと、AI エージェントは「何を作ればいいか」「どう作ればいいか」「どう見えればいいか」のすべてを、プロンプトに書かなくても、ファイルから読み取れるようになります。毎回「Inter フォントで、色は #5e6ad2 で、余白は 8px グリッドで……」と指示する必要がなくなる。一度 DESIGN.md に書いておけば、それが永続的な前提条件になるのです。

9つのセクション

DESIGN.md の内部構造に目を向けましょう。

Google Stitch が 公式ドキュメント で提示したフォーマットを基に、VoltAgent の awesome-design-md プロジェクトが採用している拡張版が、事実上の標準となっています。その構成は9つのセクションからなります。

補足：Stitch 公式ドキュメントのサンプルコードブロックでは、Overview / Colors / Typography / Components / Do's and Don'ts という5セクションの最小構成が例示されています。以下で紹介する9セクション構成は、これに awesome-design-md 側で Layout Principles / Depth & Elevation / Responsive Behavior / Agent Prompt Guide を加えた拡張版です。実運用では、この拡張版のほうが AI エージェントに対して情報密度が圧倒的に高いため、本稿ではこちらを取り上げます。

① Visual Theme & Atmosphere（視覚テーマと空気感）

ここは、デザインシステム全体の「気分」を散文で書くセクションです。ムード、情報密度、デザイン哲学。数値ではなく、言葉で。

例えば、awesome-design-md の Linear 分析ではこう書かれています（第1回で触れた通り、これは第三者の観察です）：

「近黒（#08090a）のキャンバスの上にコンテンツが星明かりのように浮かび上がる。極度の精密工学という印象：すべての要素が、輝度の緻密なヒエラルキーの中に配置されている」

これは JSON トークンでは絶対に表現できない領域です。そしてこのセクションこそ、前回述べた「書き手が普段何を摂取しているかの鏡」が最も露わになる場所です。

② Color Palette & Roles（カラーパレットと役割）

色の HEX コードに加えて、各色のセマンティックな役割を明記するセクションです。

単に「#5e6ad2」と書くのではなく、「Brand Indigo（#5e6ad2）：プライマリCTAのみに使用。装飾的には使わない」のように、使っていい場所と使ってはいけない場所まで言葉で指定します。これが AI にとっては決定的に重要で、色コードだけを渡すと AI はその色をあちこちに散らしてしまいます。

③ Typography Rules（タイポグラフィ規約）

フォントファミリ、サイズ、ウェイト、行間、字間を、用途ごとに一覧表で示すセクションです。

ここでは Markdown のパイプテーブルが威力を発揮します。Display XL / Heading 1 / Body / Caption / Mono のように、役割ごとの行が並び、各行にフォント名・サイズ・ウェイト・行間・字間が入る。AI エージェントは、「ここに Heading 2 を置いて」と指示されたとき、この表から正確なスタイルを引いてきます。

④ Component Stylings（コンポーネントスタイル）

ボタン、カード、入力フォーム、ナビゲーションなど、主要コンポーネントのスタイル定義です。ここでは状態ごとのスタイル（通常、ホバー、フォーカス、無効化）も書きます。

⑤ Layout Principles（レイアウト原則）

間隔のスケール（8px, 16px, 24px, 32px…）、グリッドシステム、最大幅、余白の哲学などを記述します。

⑥ Depth & Elevation（深度と高さ）

影の体系、サーフェスの階層を定義するセクションです。「Level 0 は影なし、Level 2 は rgba(0,0,0,0.2) 0px 0px 12px のインセットシャドウ」のように、具体的な値とともにいつどのレベルを使うかを明記します。

⑦ Do's and Don'ts（やること・やらないこと）

ここが DESIGN.md の隠れた主役です。

「純白（#ffffff）をメインテキストに使わないこと。#f7f8f8 が正しい——目の負担を防ぐため」のような禁則事項が並びます。AI エージェントは指示がなければ安易にデフォルト値を使いがちですが、Don't に明記されていれば踏みとどまれます。

JSON トークンファイルには書けない。Figma のコメントには書けなくはないが見落とされがち。DESIGN.md の Do's and Don'ts は、ブランドの「ここだけは譲れない」を、AI に対して最も効果的に伝える場所です。

⑧ Responsive Behavior（レスポンシブ挙動）

ブレイクポイント、タッチ領域のサイズ、コンテンツの折り返し戦略を定義します。「ヒーローのテキストは 72px → 48px → 32px に段階的に縮小し、字間もそれに応じて調整する」のように、具体的な段階変化を記述します。

⑨ Agent Prompt Guide（エージェント向けプロンプトガイド）

最後のセクションは、そのまま AI に渡せるプロンプトのテンプレート集です。

「#08090a の背景に、48px Inter Variable weight 510 のヘッドライン、色 #f7f8f8、字間 -1.056px のヒーローセクションを作って」——のような、DESIGN.md のトークンを使って書かれた具体的な指示文が、ここに並びます。

これによって DESIGN.md は、「読んで参考にする文書」から「コピーして貼り付ければ即座に動く指示書」に昇格します。デザインシステムがそのままプロンプトライブラリになるわけです。

awesome-design-md：68ブランドのコレクション

ここまでの話を聞いて、「面白いけど、自分でゼロから書くのは大変そうだ」と思った方もいるかもしれません。

そこで紹介したいのが、前回も触れた VoltAgent の awesome-design-md プロジェクトです。2026年4月時点で GitHub スター数は 57,000 を超え、デザインシステム関連リポジトリのなかでも屈指の勢いを見せています。

awesome-design-md に収録されたブランドの一部。AI & LLM Platforms、Developer Tools & IDEs、Backend/Database & DevOps、Productivity & SaaS、Design & Creative Tools、Fintech & Crypto、E-commerce & Retail、Media & Consumer Tech、Automotive と、カテゴリは9つに及ぶ。

このリポジトリには、68ブランドぶんのサイトを観察して書き起こした DESIGN.md が、MIT ライセンスで公開されています。重ねて強調しますが、これらは各社公式のファイルではなく、第三者がCSS値を読み取り、ブランドの視覚言語を言葉に翻訳した観察記録です。

ファイルの実体は、2026年春のリポジトリ刷新以降、GitHub から専用ホスティングサイト getdesign.md に移されました。現在の構成はこうなっています。

• GitHub リポジトリ（VoltAgent/awesome-design-md）：ブランドのインデックス、CONTRIBUTING.md、README.md を保持。各ブランドのサブディレクトリには README.md が置かれ、そこから getdesign.md の該当ページへ誘導される。
• getdesign.md：各ブランドに固有の URL（例：https://getdesign.md/stripe/design-md）が割り当てられ、以下の3つのビューが閲覧できる。
  • DESIGN.md タブ：9セクション構成の本体テキスト
  • Live Preview タブ：実際のスタイルで描画されたライト/ダーク切り替え可能なビジュアルカタログ
  • Preview タブ：色・タイポ・コンポーネントの俯瞰スナップショット

使い方は驚くほどシンプルです。getdesign.md が公式に用意している npx コマンドを、プロジェクトのルートディレクトリで叩くだけ。

# 例：Stripe 風の UI を作りたい場合
npx getdesign@latest add stripe

これでプロジェクトルートに DESIGN.md が書き込まれます。あとは Claude Code や Cursor に「DESIGN.md を参照して UI を生成して」と一言添えるだけです。

もちろん、他社のデザインシステムをそのまま使うことが目的ではありません。awesome-design-md は、「自分のブランドの DESIGN.md を書くときの、構造と粒度のリファレンス」として使うのが本来の活用法です。Linear がどのレベルの粒度で色を定義しているか。Stripe がどう余白の哲学を言語化しているか。Notion がどんな言葉でミニマリズムを表現しているか。これらを読むことで、自分のブランドを同じ精度で言語化するときの基準が手に入ります。

Google Stitch：デザインシステムを「書き出す」ツール

DESIGN.md というフォーマットを世に送り出したのは、Google Labs の Stitch です。

Stitch のキャンバス画面。自然言語からUIモックアップを生成し、DESIGN.md として書き出す機能を持つ。

Stitch は 2025年の Google I/O で発表され、2026年3月18日の "vibe design" アップデートで「AI-native software design canvas」へと大きく進化しました。このアップデートでは、AI-native の無限キャンバス、デザイン専用エージェント（Agent manager 含む）、音声インタラクション、そしてデザインシステムツールキットの拡張（URLからの抽出、DESIGN.md のインポート/エクスポート）が、まとめて発表されました。

Stitch の面白さは、モックアップを生成するだけでなく、そのモックアップの背後にあるデザインシステムを DESIGN.md として書き出せることにあります。あるいは、既存の URL を渡すと、そのサイトのデザインシステムを自動的に抽出して DESIGN.md にしてくれることもできます。

さらに、Stitch は MCP サーバーと SDK を提供しており、Claude Code や Google Antigravity などの外部ツールから直接接続して、デザイン情報を取得することもできます。

ただし、ここで大事な注意を。Stitch を使わなくても DESIGN.md は書けます。Stitch はあくまで「DESIGN.md を効率よく生成するツール」のひとつであって、DESIGN.md というフォーマット自体はツール非依存です。テキストエディタだけで完結できます。

この点は、デザイナーにとって重要な安心材料になるはずです。特定のツールに依存するフォーマットは、ツールが終了すれば一緒に死にます。DESIGN.md は Markdown なので、Stitch が明日消えても、ファイルは永遠に使えます。

CLAUDE.md / AGENTS.md との連携

実際にプロジェクトに DESIGN.md を導入する際の、最も軽い始め方を紹介します。

DESIGN.md をプロジェクトのルートに置いたら、Claude Code を使っている場合は CLAUDE.md に1行追加するだけです。

## Design System

UIを生成する場合は ./DESIGN.md を必ず参照し、定義されていないトークンを使わないこと。

Claude Code は毎セッションの開始時に CLAUDE.md を自動で読み込むので、この1行が書かれていれば、以降のすべての UI 生成で DESIGN.md が暗黙の前提条件になります。

Cursor の場合は .cursorrules や AGENTS.md から同様に参照させます。最近のトレンドでは、ツール固有のファイル（.cursorrules 等）よりも AGENTS.md に一本化する方向に動いています。これは AAIF（Linux Foundation）が推進する流れで、どのツールに乗り換えても設定が引き継がれる利点があります。

ファイルの配置は、シンプルに保つのが鉄則です。

my-project/
├── README.md          # 人間の開発者向け
├── AGENTS.md          # AI エージェント向け（ビルド・テスト・規約）
├── CLAUDE.md          # Claude Code 固有の設定（AGENTS.md を参照可）
├── DESIGN.md          # ← デザインシステム
└── src/
    └── ...

この4枚の Markdown が揃えば、AI エージェントは「何を」「どう」「どういう見た目で」作ればよいかを、すべてファイルから知ることができます。プロンプトに毎回長い指示文を書く時代は、これで終わりです。

デザインシステムは「テキスト」になった

ここまで読んで、ある種の不思議な感慨を覚える方もいるかもしれません。

デザインシステムは、Figma のファイルでもなく、PDF のブランドブックでもなく、JSON のトークンでもなく、テキストになったのです。

テキストになったことで、デザインシステムは初めて、コードと同じ市民権を手に入れました。PR でレビューできる。Git で差分を追える。ブランチを切って実験できる。マージの前に承認を求められる。そしてなにより、AI がそのまま読める。

これは、デザイナーとエンジニアの関係性にも変化をもたらすはずです。今まで「Figma を見てください」「この PDF の23ページにあります」と伝えていたものが、「この DESIGN.md の Typography Rules を見てください」と伝えるだけで済むようになる。そして同じファイルを、AI エージェントも読んでいる。三者が同じ文書を読んでいるという状態が、初めて実現するのです。

ただし——テキストになったということは、言葉の精度がそのまま設計の精度になるということでもあります。曖昧な DESIGN.md は、曖昧な UI を量産します。美しい DESIGN.md は、一貫した UI を生み出します。

前回の結論を、もう一度繰り返します。DESIGN.md は鏡です。そこに置ける言葉の解像度は、書き手が普段何を見て、何に触れ、何を読んできたかに、比例します。

小さな実験

今回も、ひとつ試してみてほしいことがあります。

awesome-design-md の GitHub リポジトリか、あるいは本体が置かれている getdesign.md を開いて、好きなブランドのページに入ってください。そして DESIGN.md を一本、最初から最後まで通して読んでみてください。

おすすめは、自分が普段よく使っているプロダクトのものです。Linear を使っているなら Linear、Notion を使っているなら Notion。自分がすでに体感で知っている UI を、言葉で書くとどうなるのか。その体験は、きっと想像以上に新鮮なはずです。

読み終わったら、こう自問してみてください。「自分が関わっているプロダクトの DESIGN.md を、この粒度で書けるだろうか」と。

もし「書けそうだ」と思えたなら、あなたはすでにそのプロダクトのデザインシステムを深く理解しています。もし「まだ書けない」と思ったなら、それは能力の問題ではなく、言語化の訓練をまだしていないだけです。DESIGN.md を読むこと自体が、その訓練の第一歩になります。

そして68ブランドが収録されている awesome-design-md は、あくまで出発点にすぎません。そこに載っていない、あなた自身のプロダクトの美学を言葉にできるのは、あなたしかいません。

次回は、awesome-design-md のコレクションの中でも特に完成度の高い Linear、Stripe、Notion の書き起こしを、1本ずつ精読していきます。一流ブランドのビジュアルを言語化するとはどういうことなのか。そして書き手の解釈をどう読み解くべきなのか。

読むことは、書くことの最良の準備です。

参考文献

• Google Stitch — DESIGN.md を打ち出した Google Labs の AI-native デザインキャンバス

• Google Stitch DESIGN.md 公式ドキュメント — DESIGN.md フォーマットの公式仕様（"What is DESIGN.md?"）

• Introducing "vibe design" with Stitch — Google Keyword Blog — Stitch "vibe design" アップデート（2026年3月18日）の公式アナウンス

• AGENTS.md 公式サイト — OpenAI が主導し、60,000+ プロジェクトで採用されているフォーマット

• Linux Foundation Announces the Formation of the Agentic AI Foundation — AAIF 設立（2025年12月9日）のプレスリリース

• OpenAI: Agentic AI Foundation — OpenAI 側からの AAIF 共同設立アナウンス

• VoltAgent / awesome-design-md — 68ブランドの DESIGN.md 書き起こしコレクション（MIT ライセンス、インデックス兼 CONTRIBUTING の場）

• getdesign.md — awesome-design-md 本体ファイルのホスティング・ブラウジング先。npx getdesign@latest add <brand> でプロジェクトに直接取り込める

• Model Context Protocol（MCP） — Anthropic が提唱し、AAIF で管理されるエージェント接続プロトコル

• Stitch MCP Server / Stitch SDK — Stitch を外部ツールと連携させるための公式接続口

• Claude Code — Anthropic の AI コーディングエージェント（CLAUDE.md 対応）

• Cursor — AGENTS.md に対応した AI ネイティブ IDE

• Google Antigravity — Google の AI 開発環境。Stitch と連携可能

• Style Dictionary — Design Tokens を構造化管理する代表的ツール

• Storybook — コンポーネントドキュメントの標準プラットフォーム

• Linear / Stripe / Apple / Notion