【2026年最新】AI時代のデザインシステム「DESIGN.md」入門

2026-04-24

CursorやClaude CodeなどのAIコーディングエージェントを使っていて、「生成されるUIのトーン＆マナーが毎回ブレる」「コンポーネントのデザインがバラバラになる」と悩んだことはありませんか？
この課題に対する新しいアプローチとして、フロントエンド開発の現場で注目を集めはじめているのが 「DESIGN.md」 です。
この記事では、Googleの「Stitch」が導入し、コミュニティで実践が広がりつつある「DESIGN.md」の基本から、関連するGitHubリポジトリ、そして実際の書き方までを、初めての方にもわかりやすく解説します。

目次

DESIGN.mdとは？なぜフロントエンド界隈で注目されているのか

DESIGN.md とは、一言で言えば 「AI（LLM）にプロジェクトのデザインシステムを理解させるための、プレーンテキスト（Markdown）の仕様書」 です。

これまで、デザインシステムといえば専用ツール上で視覚的に管理するか、Storybookなどでコンポーネント化するのが主流でした。しかし、AIエージェントにコードを書かせる際、画像や視覚的なデザインカンプを渡しただけでは、AIが「余白の意図」や「ホバー時の細かな挙動」といった文脈までを汲み取ってくれるわけではありません。

そこで、プロジェクトのルートディレクトリに DESIGN.md を配置し、カラースキーム、タイポグラフィ、UIの基本ルールを テキストとして言語化しておく ことで、AIエージェントがブランドの世界観に沿ったUIを安定して出力しやすくなります。特定のデザインツールに依存しない、汎用性の高いアプローチです。

DESIGN.md という形式は、Googleが提供するAI UIデザインツール Google Stitch が導入した概念で、Stitch公式ドキュメント（stitch.withgoogle.com/docs/design-md/overview/）でフォーマットが公開されています。Stitch以外のAIコーディングエージェント（Claude Code、Cursorなど）でも、ルートディレクトリに置いておくだけで参照させることができます。

主要ブランドのデザインを再現する「awesome-design-md」

DESIGN.mdのポテンシャルを実感しやすいのが、GitHubで公開されているリポジトリ awesome-design-md（VoltAgent提供）です。

このリポジトリには、2026年4月時点で約30のサービス・ブランドのデザインシステムを DESIGN.md フォーマットに変換したコレクションが収録されています。具体的には次のようなサービスが含まれています（一部抜粋）。

  • AI / 機械学習：Claude、Cursor、Mistral AI、xAI、Replicate
  • 開発者向けプラットフォーム：Vercel、Linear、Supabase、Sentry、Figma
  • インフラ・SaaS：Stripe、HashiCorp、Sanity、ClickHouse
  • コンシューマー・エンタープライズ：Apple、Notion、IBM、NVIDIA、Uber

使い方:

  1. 自分が作りたいテイストに近いブランドの DESIGN.md をダウンロード
  2. 自分のプロジェクトのルートディレクトリに配置
  3. Cursorなどで「ログイン画面を作って」とプロンプトを投げる

たったこれだけで、AIが指定したブランドの世界観（余白の取り方、ボタンのホバーエフェクト、タイポグラフィなど）に近いコードを出力してくれます。ゼロからデザインルールを作るのが大変な方にとって、有力なスタート地点となります。

なお、これらの DESIGN.md ファイルは公開されているCSSや視覚的特徴をもとに第三者が抽出したものであり、各社の公式デザインシステムそのものではない点には留意してください（リポジトリのライセンスはMITです）。

日本語サービス向けの「awesome-design-md-jp」

グローバルブランドだけでなく、「日本のWebサービスに特化したデザインシステムを使いたい」「日本語タイポグラフィ（Noto Sans JPなど）の最適な設定が知りたい」というニーズに応える形で、日本のコミュニティから派生プロジェクトとして awesome-design-md-jp が公開されています。

作者はクズケン氏（@kuzzken）、リポジトリは github.com/kzhrknt/awesome-design-md-jp で公開されています。

この派生版は、本家の awesome-design-md が日本語タイポグラフィをカバーしていない点を補うことを目的としており、以下のような日本語UI特有の仕様を含んでいます。

  • 和文フォントのフォールバックチェーン（和文 → 欧文 → generic）
  • 日本語に適した行間（line-height 1.5〜2.0）
  • 日本語の字間設定（本文に0.04〜0.1em程度）
  • 禁則処理（句読点や括弧の行頭・行末ルール）
  • OpenType機能（palt、kern によるプロポーショナル組版）
  • 和文・欧文の混植ルール

freee、Apple Japan、クックパッドなど、20以上の日本語サービスがすでに収録されています。

国内向けのプロジェクトを立ち上げる際は、まずこちらの jp 版リポジトリから自分のイメージに近い DESIGN.md を探してみるのが、効率的なショートカットになるでしょう。

README.md / CLAUDE.md / AGENTS.md との違いは？

開発ディレクトリにはすでにさまざまなMarkdownファイルが存在しますが、それぞれ役割が明確に異なります。

ファイル名メインの読者役割と記載する内容
README.md人間（開発者）プロジェクトの概要、環境構築手順、ライセンスなど
CLAUDE.md / AGENTS.mdAIエージェント使用するフレームワーク、テスト方針、独自のCLIコマンド、コーディング規約など「ロジック・開発フロー」に関わる指示
DESIGN.mdAIエージェント（特にデザイン担当）カラーパレット、フォント、余白のルール、コンポーネントの振る舞いなど「視覚・UI」に特化した指示

なお、CLAUDE.md は Anthropic の Claude Code 向け、AGENTS.md は OpenAI 系を含む汎用フォーマットとして広まったもので、出自はやや異なりますが、いずれも「AIエージェントへの開発指示書」という共通の役割を持っています。

役割を分割することで、AIのコンテキスト（プロンプト）が整理され、より精度の高いコード生成が可能になります。

DESIGN.md の書き方・基本構造

DESIGN.md には決まったフォーマットはありませんが、Google Stitch が公開している構成が事実上のリファレンスになりつつあります。awesome-design-md でも、おおむね次のようなセクション構成が共通して採用されています。

  1. Visual Theme & Atmosphere：ブランドの全体的なトーン・雰囲気
  2. Color Palette：カラーパレットの定義
  3. Typography：フォントとテキストスタイル
  4. Components：ボタン・カード・フォームなどのスタイル
  5. Layout & Spacing：余白・グリッドのルール
  6. Do’s and Don’ts：やること・やってはいけないこと

AIに意図を正確に伝えるためには、人間向けのふんわりとした説明ではなく、「ルール・理由・実装方法」をセットにするのがコツです。

  1. Rule（ルール）：守るべきデザインの制約
  2. Why（理由）：なぜそのルールがあるのか（AIが応用を効かせるため）
  3. How（実装）：具体的にどのTailwindクラスやCSS変数を使うか

実践的な DESIGN.md のサンプルコード

すぐに自分のプロジェクトで使えるテンプレートです。これをベースにカスタマイズしてみてください。

# Design System (DESIGN.md)

## 1. Core Principles (基本原則)
- シンプルでクリーンなUIを目指す。
- 余白（Spacing）をたっぷりと取り、要素を詰め込みすぎないこと。

## 2. Color Palette (カラーパレット)
Tailwind CSSの変数を使用すること。ハードコードされたカラーコード（#FFFFFFなど）は使用禁止。

- **Primary**: `bg-blue-600` / Text: `text-white`
  - 用途: 主要なCTAボタン、重要なリンク
- **Background**: `bg-gray-50` (ライトモード) / `bg-gray-900` (ダークモード)
- **Text**: `text-gray-800` (基本) / `text-gray-500` (サブテキスト)

## 3. Typography (タイポグラフィ)
- フォントファミリー: `Inter`, sans-serif
- 見出し (H1): `text-3xl font-bold tracking-tight`
- 本文: `text-base leading-relaxed`

## 4. Components Rules (コンポーネントのルール)

### Buttons (ボタン)
- **Rule**: すべてのボタンは角丸にし、ホバー時のトランジションを含めること。
- **Why**: ユーザーにクリック可能な要素であることを直感的に伝えるため。
- **How**: `rounded-md transition-colors duration-200` を必ず付与すること。

### Spacing (余白)
- コンポーネント間の余白は `gap-4` または `gap-6` を基本とする。

サンプルコードの各項目の解説：AIに何を伝えるべきか？

ただ漫然とデザインの希望を書くのではなく、上記の4つの項目を軸に「制約」を明文化することが、AIに高品質なUIを作らせる鍵になります。

1. Core Principles（基本原則）：「プロジェクトの性格」を決める

AIに対する 「大枠の方向付け（コンパス）」 の役割を果たします。「フラットデザインなのか」「マテリアルデザイン風なのか」「ポップでリッチな装飾が欲しいのか」を定義します。

ここを明確にすることで、AIが意図しないドロップシャドウ（影）やグラデーションを追加して、デザインが冗長になるのを防ぎやすくなります。

2. Color Palette（カラーパレット）：AIの「カラーゆらぎ」を防ぐ

AIにUIを生成させると、指示がない限りAIは良かれと思ってさまざまなカラーコード（例：#e5e7eb や #ff5733）を生成してしまいがちです。

「Tailwindのクラスや定義済みの変数しか使ってはいけない」「プライマリーカラーはこれだけ」 と明確に定義することで、サイト全体の色使いに統一感が生まれます。ダークモード時の反転ルールなどもここに記載します。

3. Typography（タイポグラフィ）：統一感のある文字組みルール

文字の大きさや太さ、行間（line-height）のルールです。AIは「見出し」を作るとき、毎回サイズが揺れてしまうことがあります。

H1、H2、本文にそれぞれどのCSSクラス（例：text-3xl font-bold）をあてるかを明記しておくことで、ページ遷移しても見出しのサイズがブレない、整った「縦のリズム」を持ったUIが生成されやすくなります。

4. Components Rules（コンポーネントのルール）：細部の振る舞いを定義

ボタンやカード、入力フォームなど、頻出するパーツ固有のルールです。

特に重要なのが 「インタラクション（ホバー時やクリック時の動き）」 と 「余白（Padding/Margin）」 の指定です。AIは動きのない静的なUIを出力しがちなので、「ボタンには必ず hover: のスタイルをつけること」と Rule/Why/How の形式で指示しておくことで、UXが向上しやすくなります。

現場で役立つ実運用とベストプラクティス

実際の開発現場で DESIGN.md を運用する際の重要なポイントは、「命名規則（デザイントークン）の統一」 です。

プロジェクト内で使う色やコンポーネントの名前（例：Brand-Blue や Primary-Button）を DESIGN.md 内で明確に定義し、AIには「この名称を使ってコードを生成すること」と指示します。これにより、AIが新しいクラス名を勝手に作り出すのを抑制でき、人間がコードを読んだときの理解度も上がります。

DESIGN.mdを「軽量なインデックス」として運用するアプローチ

大規模なプロジェクトでは、DESIGN.md にすべてを書き込むとファイルが肥大化し、AIのコンテキスト制限に影響する可能性があります。

この点について、Zennで公開されている mine_take 氏の記事「DESIGN.md 導入ガイド: AI実装のための入口・契約・検証をどう整えるか」（2026年4月公開）では、興味深いアプローチが提案されています。

それは、DESIGN.md を 「軽量な入口（index）」として位置づけ、詳細はデザインシステム関連の別ドキュメント群に委譲する という運用方法です。具体的には、デザイントークンの正本（Source of Truth）はJSONファイルに置き、コンポーネント対応表は別ファイルで管理し、DESIGN.md には「読む順番」「正本の場所」「最小チェック手順」だけを書く、という構成です。

この考え方は、小さなプロジェクトでは過剰かもしれませんが、AI実装と人間のレビューが並走する規模の現場では、ドキュメントの陳腐化を防ぐ実践的な手法として参考になります。

DESIGN.md に関するFAQ

Q. DESIGN.md は誰が考案したものですか？

GoogleのAI UIデザインツール「Google Stitch」が導入した概念です。Stitch公式ドキュメントでフォーマットが公開されており、Stitch以外のAIコーディングエージェントでも利用できる汎用的な仕様になっています。

Q. README.md と何が違うのですか？

README.md は人間の開発者向けに書かれた、プロジェクトの概要や環境構築手順をまとめたドキュメントです。一方、DESIGN.md はAIエージェントが視覚的なUIを生成する際に参照するための、デザインシステムの仕様書です。読者と用途が明確に異なります。

Q. 無料で使えますか？

DESIGN.md という形式自体に費用はかかりません。awesome-design-md および awesome-design-md-jp はいずれもMITライセンスで無料公開されています。

Q. Cursor や Claude Code でも使えますか？

はい。DESIGN.md はプレーンなMarkdownファイルなので、プロジェクトのルートディレクトリに配置するだけで、Cursor、Claude Code、GitHub Copilot などの主要なAIコーディングエージェントから参照させることができます。

Q. 既存のデザインシステムがあるプロジェクトでも導入できますか？

導入できます。既存のデザインルールをDESIGN.md形式で言語化することで、AI実装時の参照ドキュメントとして活用できます。すべてを一度に書く必要はなく、まずはカラーパレットとタイポグラフィの基本ルールから始める方法が現実的です。

まとめ

DESIGN.md は、特定のデザインツールに依存しない、AIコーディング時代における「人間とAIをつなぐ視覚の共通言語」と言える存在です。

まずは awesome-design-md や awesome-design-md-jp のようなリポジトリからテンプレートを借りてきて、日頃使っているAIエージェントに読み込ませてみてください。これまで手作業で調整していたUIのトーンが揃いやすくなることを実感できるはずです。

参考リンク

最終更新日: 2026-04-24

こちらもどうぞ