DEV Community: miho

DESIGN.mdとは？AIと進めるUIデザインの共有ガイド

miho — Sun, 06 Sep 2026 11:15:00 +0000

要点

DESIGN.mdは、UIの見た目と判断理由を人とAIで共有する文書です
数値だけでなく、目指す印象や避けたい表現まで言葉にします
さまざまなDESIGN.mdギャラリーサイトや生成方法があります

生成AIでUIのたたき台を作ることは以前より速くなりました。一方で、指示するたびに意図しない方向へ雰囲気が変わり、デザインプロセスが安定しない場面も増えています。そこで役立つのが、デザインの値と意図を一つのMarkdownファイルにまとめるDESIGN.mdです。

DESIGN.mdとは

Google LabsではDESIGN.mdを「デザインシステムをAIエージェントへ永続的・構造的に伝える形式」と位置づけています。任意のYAML Front Matterに機械が扱いやすいデザイントークンを置き、Markdown本文に人が理解しやすい設計意図や適用方法を書く構成が示されています。

たとえば「角丸は8px」と値だけを渡しても、どの部品に適用するのか、例外を認めるのかまでは伝わりません。反対に「親しみやすくする」と文章だけで伝えても、生成される形は毎回変わります。値と理由を組み合わせることで、AIは迷いにくくなり、人は出力をレビューしやすくなります。

なお、公式リポジトリでは、この形式のステータスがalphaとされています。現時点では完成した業界標準として扱うのではなく、チームの実践に合わせて試し、更新していく共有形式と捉えるのがよさそうです。

デザインシステムやプロンプトとの違い

DESIGN.mdは、既存のデザインシステムを置き換えるものではありません。Figmaのライブラリや実装済みコンポーネントが「再利用できる部品」を提供するのに対し、DESIGN.mdはAIが作業を始める前に参照できる、軽量な案内図に近い存在です。既存のトークンやガイドラインから必要な情報を抜き出し、リポジトリ内で読みやすく整理できます。

また、一度きりのプロンプトとも役割が異なります。プロンプトに毎回「青を使う」「カードの角丸は小さく」と書くと、更新漏れや表現の揺れが起こります。判断をDESIGN.mdへ寄せれば、依頼文は「DESIGN.mdに従って設定画面を作る」のように短くでき、複数画面や別の作業セッションでも同じ前提を使えます。

大切なのは、ファイルを置くだけで自動的に参照されるとは限らないことです。利用するツールの指示ファイルやプロンプトに「UI作業の前にDESIGN.mdを読む」と明記し、実際の出力にルールが反映されているか確認する必要があります。

何を書くと役立つのか

公式仕様には、Overview、Colors、Typography、Layout、Elevation & Depth、Shapes、Components、Do's and Don'tsという順序が示されています。すべてを最初から埋める必要はありません。まずは次の三つから始めると、短い文書でも判断基準として機能します。

目指す印象：誰に向けた画面で、どのような感情を持ってほしいか
よく使う値：色、文字、余白、角丸など、繰り返し現れるトークン
境界線：採用する表現と、ブランドに合わないため避ける表現

簡略化すると、次のように記述できます。

---
name: Example Product
colors:
  primary: "#2457D6"
  surface: "#FFFFFF"
  text: "#172033"
spacing:
  sm: 8px
  md: 16px
rounded:
  sm: 4px
  md: 8px
---

## Overview

業務中に長時間使う管理画面です。装飾よりも一覧性を優先し、
落ち着きがあり、次の操作に迷わない見た目を目指します。

## Components

- Primary Buttonは画面内の主要操作にだけ使います
- Cardを入れ子にせず、余白と区切り線で階層を示します

## Do's and Don'ts

- 状態は色だけでなく、ラベルやアイコンでも伝えます
- 背景のグラデーションを主要な情報領域に使いません

色名はblueではなくprimaryやsurfaceのように役割で命名すると、その役割を保ったまま値を差し替えられます。本文には「どこで使うか」「なぜ必要か」を書き、単なる数値一覧にしないことがポイントです。

参考にできるギャラリーとツール

DESIGN.mdのギャラリーサイトは数多くあります。

プラットフォーム名	用途
DESIGNmd	コミュニティのデザインを探す
designmd.app	500件以上のデザインを比較する
Free Design MD	無料・登録不要のデザインを探す
designmd.sh	GitHubで公開されたデザインを探す
DesignMD	実在ブランドのデザインを探す・生成する
Refero Styles	実在プロダクトのデザインシステムを研究する

また、既存のWebページからスクリーンショットやデザイン情報を取得するDesign MD Generator（GitHub）というツールもあります。取得した情報をお使いのAIエージェントに読み込ませ、DESIGN.mdを生成してもらう方法もあります。

おわりに

可能性を広げる方法が多様になり、何から始めればよいのかわからないことも多いと思います。こうしたギャラリーサイトを参考に、ほかの人がどのように作っているのかを見ることは、新しい概念を理解するための第一歩になるのではないでしょうか。

AIを使う目的は、これまでのデザインの仕事を単に合理化することだけではありません。今まで自分では思いつかなかった可能性を広げ、眠っていた課題を解決する創造的なアイデアを生み出せるよう、これからも学習と開発を進めていきたいと思います。

情報整理について考える—シソーラス・タクソノミー・オントロジー

miho — Wed, 26 Aug 2026 09:34:51 +0000

要点

シソーラスは言葉をつなぎ、タクソノミーは情報を分け、オントロジーは意味を結びます
AIが身近になるほど、情報の構造を理解する力が重要になると考えています

これまでこうした情報を扱うためのノウハウは情報アーキテクチャに携わる人やライブラリアンといった一部の人たちに必要なものだと考えられてきました。
しかし、すでに私たちは感覚や経験だけでは扱いきれない情報量を日常に抱えており、さまざまのところで似たような課題を抱えているのではないのでしょうか。
情報の管理がさまざま人の立場や解釈によって混乱を生み、業務が停滞したり、重大な情報の漏洩につながったりするのも、こうした情報に対する私たちの考えがまだ成熟していないからかもしれません。
今回は、「シソーラス」「タクソノミー」「オントロジー」について取り上げ考えてみたいと思います。

情報整理の観点について

以下、ChatGPTにそれぞれの役割の違いについてまとめてもらいました。

シソーラス：言葉を揃える
タクソノミー：置き場所を決める
オントロジー：意味のつながりを記述する

整理術	できること	主な使い所
シソーラス	呼び方の迷いを減らす	用語集、サイト内検索、タグ整理
タクソノミー	探す場所の迷いを減らす	フォルダ整理、商品カテゴリ、FAQ分類
オントロジー	情報のつながりをたどれるようにする	人物・組織・出来事の関係整理、関連情報の検索

シソーラス：言葉をつなぐ

『情報アーキテクチャ第4版―見つけやすく理解しやすい情報設計』によると、シソーラスとは以下のように定義できるそうです。

検索向上のために同義性、階層性、関連性を明らかにした制限語彙のこと。シソーラスはこれら3つの語義関係を基本にしながら、単純な制限語彙の構造物の上に成り立っています。

つまりシソーラスは、その言葉自体が持つ性質を語彙によって整理することで、検索をする際に、その時必要な情報を取り出しやすくすることに目的がありそうです。

たとえば、「ワイン」を探している人が「ぶどう酒」や「葡萄酒」と入力することがあります。これらを同義語として結び付けておけば、使う言葉が違っても同じ情報へ案内できます。さらに「果実酒」を上位語、「スパークリングワイン」を下位語、「葡萄」を関連語として結ぶことで、検索の範囲を広げたり絞ったりしやすくなります。

最初から完璧に作る必要はなく、身近な言葉について、よく使う表記・別の呼び方・関連する言葉を一覧にするだけでも、小さなシソーラスになります。

国立国会図書館のWeb NDL Authoritiesでも、同様の整理方法でまとめられることを確認できます（Web NDL Authorities「ワイン」）。

タクソノミー：情報を分ける

タクソノミーは、情報を一定の基準で分類し、主に階層として整理する仕組みです。たとえばネット通販なら、「食品」の下に「飲料」、「飲料」の下に「コーヒー」や「お茶」を置く、といった構造が考えられます。

上位の分類から下位へたどれるため、情報の全体像を見渡しやすくなりますが、複数の軸を一つの階層へ押し込むと、迷いが生まれることもあります。「旅行先で撮った家族写真」は、「旅行」と「家族」のどちらにも置けそうです。この場合は主となる分類軸を一つ選び、ほかの軸をタグで補う方法もあります。

オントロジー：意味を結ぶ

オントロジーは、言葉を揃えたり情報を分類したりするだけでなく、ものごとの関係に意味を与える仕組みです。

たとえば、映画の情報には「作品」「監督」などが登場しますが、ここで「監督が作品を撮る」と関係の意味まで記録します。すると、「この監督の作品に出演した俳優」のように、複数のつながりをたどりやすくなります。

Wikipediaなどを支えるWikidataでは、人物や作品などを一つひとつの「項目」として扱い、「監督」「出演者」といったプロパティで関係を記録します。普段目にする百科事典の裏側にも、ものごとの種類と関係を明示する考え方が使われています（Wikidata「プロパティ」）。

AI時代に情報を整理するということ

AIの普及によって、私たちは膨大な情報へ簡単にアクセスできるようになりました。しかし、手に入る情報が増えるほど、それらをどのような言葉で捉
え、どのように分類し、何と結び付けて理解するかが重要になります。

同じデータを見ても、置かれた状況や価値観によって、人が読み取る意味は異なります。AIが提示する回答についても同じです。答えを受け取るだけで
はなく、その中で使われている言葉や分類、情報同士の関係を捉えなければ、内容を適切に評価することはできません。

ここまで見てきたシソーラス、タクソノミー、オントロジーは、単なる情報整理の専門技術ではありません。それぞれ「言葉」「分類」「関係」という
観点から、私たちが情報を理解するための土台を与えてくれます。

AIを使える人と使えない人の差以上に、AIが示した情報を整理し、自分なりに判断できる人と、そうでない人の差が広がっていくのかもしれません。情
報アーキテクチャの考え方は、これから一部の専門家だけでなく、誰もが身に付けるべき基礎教養になっていくと考えています。

Figma用にフラットイラストを生成するSkillを作成しました

miho — Sun, 16 Aug 2026 14:28:01 +0000

要点

Skillsを使うことでワークフローの標準化を実現できます
段階的な質問でフラットイラストを生成するSkillを作りました
Codexで観点を広げ、最後は自分で調整することで完成度を上げました

2026年5月、Figmaはキャンバス上で直接使えるFigmaエージェントを発表しました。

最近では、FigmaでSkillsを活用したコンテンツも投稿されています。そこで、せっかくなら私も作ってみようと思い、Codexと相談しながらフラットイラストを生成するSkillを作りました。

そもそもFigma Skillsとは

Figma Skillsは、繰り返し行うワークフローを、AIエージェントが実行できる指示としてまとめる仕組みです。

たとえば、毎回長いプロンプトを書かなくても、Skillに手順やルールを持たせておけば、スラッシュコマンドから呼び出せます。複数のスキルを呼び出すことも可能で、柔軟に活用することができます。

Figmaの公式ヘルプによると、Custom Skillの実体はAgent Skills仕様に沿ったMarkdownファイルです。Figma上で直接記述する方法と、既存のMarkdownファイルをアップロードする方法があります。

プロンプトは、一度の出力を得るための依頼になりがちですが、Skillには質問の順序、選択肢、ルール、確認方法まで含められます。つまり、成果物だけでなく、そこへ至る進め方も共有できます。Markdownファイルとして残すことで、業務プロセスの標準化にもつなげられます。

なお、生成AIの性質上、同じSkillを使っても出力が完全に同じになるわけではなく、ここで目指す「標準化」とは、毎回確認すべき観点や方向性をそろえることだと考えています。

generate-flat-illustrationsの概要

今回公開したgenerate-flat-illustrationsは、Figma上でフラットなイラストを作るSkillです。

想定したのは、次のような場面です。

ブログのサムネイルがほしい
プレゼン資料のイメージがほしい

利用者にシーン、イメージキーワード、サイズを順に確認し、条件が決まったら完成候補を3案生成するワークフローにしました。

工夫したのは「選択式＋任意入力」

フローを考える上で最も意識したのは、自由入力だけにしないことでした。

何でも入力できる状態は一見便利ですが、利用者は「何を書けばよいか」から考えなくてはいけません。反対に、すべてを固定すると、用途に合わないイラストになってしまいます。

そこで、基本的な方向性は選択肢から選び、必要な場合だけ追加の要望を書ける形にしました。また、一度にすべてを尋ねるのではなく、シーン、イメージキーワード、サイズの順に質問を少しずつ提示する「段階的開示」を取り入れています。前の回答を踏まえて次の選択肢を示せるため、利用者が考える範囲をその都度絞れます。

また、カラーパレットを追加してトンマナを安定させたことも工夫した点の1つです。
OKLCHなら知覚的な明るさを基準に調整でき、トンマナを保ちながら色相ごとのパレットを展開しやすいと考え、採用しました。

安定してフラットイラストを生成できるよう、表現に適度な制約を設け、何度か試行を重ねた結果、現在のSkillの内容に至りました。

Codexとの壁打ちで、完成形の解像度が上がった

最初から詳細な仕様があったわけではありません。「フラットイラストを生成するSkillを作りたい」という大まかな考えから始め、まずは何から着手すべきかを一緒に整理しました。

Codexが検討すべき観点をあらかじめ候補として挙げてくれたことで、私はそれらを確認しながら、要件の整理と意思決定に集中できました。
また、Codexとのやり取りでは、要件だけでなく実際のメッセージ例も提示してもらいました。そのため、具体的なイメージをつかみやすくなり、事前に細かな調整を進められました。
一方で、Codexが作成した内容をそのまま使うと、文章や構造がやや冗長になる部分もあったため、最終的には私のほうで整理・調整を加えています。

自分でもCustom Skillを作るには

FigmaのCustom Skillは、チャットの入力欄から「Skills」→「Add skill」と進み、次のどちらかで作成できます。

Markdownファイルをアップロードする
Figma上で名前、説明、指示を直接記述する

公式の詳しい手順は、Custom skills for the Figma agent and Figma Makeで確認できます。また、Figma MCP ServerとCodexを使って作る場合は、Create skills for the Figma MCP serverで、Codexから$skill-creatorを呼び出す手順が紹介されています。

初めて作るなら、いきなり長い指示を書くより、普段何度も書いているプロンプトを一つ選ぶと始めやすいかもしれません。

最初の版は小さく作り、実際に何度か呼び出してみてください。期待と異なる出力になった場合は、指示を追加する前に、「質問が曖昧ではないか」「二つのルールが競合していないか」を確認すると整理しやすいと思います。

おわりに

今回はフラットイラスト生成に限った試みであり、複雑な制作フローやチームでの運用までは扱えていません。

それでも、Codexとの壁打ちを通じて判断材料を広げ、最後は自分で取捨選択しながら調整することで、完成度を高めることができました。今回のようなSkillを作成するプロセス自体は、ほかの場面でも活かせそうだと感じています。

これからも試行錯誤を重ねながら、AIやチームと一緒にプロダクトづくりを楽しんでいきたいと思います。