オリジナル特集オリジナル特集

デザインシステムをAIが読める設計図に――『DESIGN.md』の役割と始め方

デザインシステムをAIに伝える「DESIGN.md」

デザインシステムを整備していても、AIコーディングエージェントが意図を正しく読み取れるとは限りません。色や余白の値がコードやデザインツールに分散していたり、「この青はリンク用で、ボタンには使わない」といった判断の理由が記録されていなかったりするためです。そこで注目されているのが、デザインのルールをAIにも扱いやすい形でまとめる「DESIGN.md」です。

このファイルは、単なるスタイルガイドではありません。機械が処理しやすい構造化データと、人間にも読める説明文を組み合わせ、AIが画面を実装するときの判断材料にします。特定のツールだけに閉じず、プロジェクト内に置いたMarkdownを通じて、デザインの方針をチームとエージェントの双方に共有できるのが特徴です。仕様は発展途上のため、導入時には利用するツールや形式との互換性も確認しておきましょう。

数値と「なぜ」をひとつにまとめる

DESIGN.mdの要点は、色・文字・角丸・余白などのデザイントークンと、それらの使い方を説明する文章を同じファイルに収めることです。たとえば、色を「青」とだけ記すのではなく、意味に応じて「primary」「accent」「surface」のような名前で定義します。コンポーネント側では、色の値を直接繰り返す代わりに、対応するトークンを参照します。こうすれば、変更箇所を特定しやすく、画面ごとのばらつきも抑えられます。

一方、数値だけでは表現できない判断もあります。「アクセントカラーはリンクや強調に使い、主要ボタンには使わない」「本文は読みやすさを優先し、見出しだけに強い個性を持たせる」といった説明がそれです。AIが定義済みの値だけでは対応できない場面で、こうした背景や避けるべき表現があれば、意図に沿った選択をしやすくなります。トークンが「何を使うか」を示すなら、文章は「どう考えるか」を伝える役割を担います。

最初は一画面分のルールから

導入時に、完成度の高い全社共通システムをいきなり作る必要はありません。まず対象をひとつの画面や機能に絞り、実際に使っている色、文字サイズ、余白、角丸を洗い出します。次に、それぞれへ意味のある名前を付け、同じ用途の値が複数存在する場合は、どれを標準にするか決めます。ボタンや入力欄など主要コンポーネントについては、役割、基本状態、必要なバリエーションも整理します。

本文には、製品の雰囲気や利用者像に加え、レイアウトの密度、色の使い分け、文字の階層、コンポーネントの状態変化を記します。さらに「してよいこと」だけでなく、「避けること」も具体化しましょう。たとえば「一画面に主要ボタンを複数並べない」「意味のない装飾色を追加しない」といったルールです。抽象的な形容詞だけで終わらせず、実装者が確認できる行動に落とし込むことが大切です。

生成物を確認し、継続的に育てる

ファイルを置いただけで、AIの出力が自動的に正しくなるわけではありません。DESIGN.mdを読み込ませて画面を生成し、色や余白がルールに沿っているか、状態やアクセシビリティへの配慮があるかを人が確認します。意図と違う出力があれば、プロンプトだけで補うのではなく、ルールの曖昧さや不足を見直します。トークン名と説明の食い違い、コンポーネントごとに異なる例外なども、早めに解消しましょう。

デザインが変わったときは、実際のコードやデザイントークンとDESIGN.mdを一緒に更新し、古いルールを残さないようにします。必要に応じて、ファイルを人間向けのスタイルガイドとして表示する仕組みを用意すると、AIとチームの双方が同じ内容を確認しやすくなります。DESIGN.mdの価値は、AIにデザインを任せきることではなく、判断の基準を共有し、生成結果を検証できる状態にすることにあります。まず小さく書き、使いながら直すことが、実践的な始め方です。