Webデザイン＆開発 AI統合・活用支援 SEO＆アクセス解析 アプリ開発 ブランディング View All → 🔍 AI互換性を一括診断
Works
Philosophy Company Team
Blog Recruit Contact 無料でAI診断する
DESIGN.md
calendar_today
[AI時代のデザインシステム実践 Vol.4] 山下 太郎 山下 太郎

AI時代のデザインシステム実践 第4回 世界のデザインシステムはどう再構築されているか

Spotify Encoreの三層分離、Indeedの4,300プロトタイプ、Anthropicの反凡庸マニュアル、Katherine Yehの実践。世界のデザインチームがデザインシステムを再構築し始めている現場レポート。

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

地図を手にしたら、次は旅に出る

ここまでの3回で、DESIGN.md というフォーマットの性格と、一流ブランドの書き起こしの読み方を見てきました。地図は手に入った。では、その地図を使って実際に何が起きているのか。

今回は、世界のデザインチームや個人のデザイナーが、DESIGN.md やデザインシステムの仕組みをどう再構築し始めているかを見ていきます。うまくいっている事例だけでなく、うまくいかなかった事例から始めましょう。失敗の中にこそ、最も実践的な教訓があります。

Spotify が直面した「迂回問題」

音楽ストリーミングの巨人 Spotify は、Encore という自社デザインシステムを長年運用してきました。コンポーネント、トークン、ガイドライン——大規模プロダクトにふさわしい、精密に構築されたシステムです。

ところが、AI コーディングエージェントが普及し始めた頃、Encore チームは予想外の事態に直面しました。開発者たちが Encore を迂回し始めたのです。

何が起きたか。開発者たちは Cursor（AI コーディングエージェント）に直接指示を出し、Encore を経由せずに UI を組み立てていました。結果として、Encore のコンポーネントを使わない、ブランドガイドラインに沿わない UI が生まれ始めた。

なぜ迂回されたのか。理由はシンプルです。Encore が複雑すぎて、AI が効率よく読み取れなかった。プロップス、バリアント、スタイル、振る舞い、アクセシビリティ情報、使用ガイドライン——すべてが一つの巨大なドキュメントブロックに詰め込まれていた。人間にとっては一箇所にまとまっている方が便利ですが、AI にとっては「何もかもが詰まった巨大なコンテキスト」を解析するのは非効率です。開発者が Cursor に「このボタンを作って」と指示すると、Cursor は Encore の膨大なドキュメントを前にして、Encore を使わずに自前でボタンを生成する方が"早い"と判断してしまう。

Spotify の Web Engineer Victoria Tholerus 氏と Senior Product Designer Aleksander Djordjevic 氏は、Into Design Systems Meetup（Spotify HQ ストックホルム）でこの問題と解決策を発表しています。

Spotify の解法と、コンテキストを分離する設計思想

Encore チームが取った解決策は、大きく二つの方向からなっています。一つはコンポーネントそのものの再設計、もう一つはコンテキストの届け方の再設計です。

まずコンポーネントの再設計について。Spotify は、従来モノリシックに束ねていたコンポーネント定義を三つの独立した層に分離しました。一次情報（Sil Bormüller 氏の解説記事「Your Design System Is Not Ready for AI Agents」）では、この三層は以下のように呼ばれています。

  • Foundation layer：トークンとプリミティブ
  • Style layer：見た目の定義
  • Behavior layer：インタラクションの論理

こう分離することで、AI エージェントは「ボタンの塊」を理解するのではなく、Foundation / Style / Behavior を独立に扱えるようになります。ボタンのスタイルだけ取ってきて振る舞いは自前で書く、といった組み合わせも可能になる。結果として Encore 採用率は上がり、Bormüller 氏の記事によれば共有スタイルの使用数は220,000件以上（前年比50%増）、開発者満足度93%に達したとされます。

もう一つの方向が、コンテキストの届け方です。ここで私なりに整理すると、Spotify の取り組みは次の三つの"層"として読み替えられます（これは一次情報を横断した私の再構成で、Spotify 公式の呼称ではありません）。

著者によるコンテキスト配送の三層整理。Foundations（常時読み込み）、Component MCP（必要時に問い合わせ）、AGENTS.md（オーケストレーション）。Spotify 公式の呼称ではなく、Bormüller 氏の「Your Design System Is Not Ready for AI Agents」と Spotify 発表を突き合わせた再構成。

Layer 1：Foundations（土台） ——DESIGN.md に相当する層です。色、タイポグラフィ、間隔スケール、基本原則。常時 AI のコンテキストに読み込まれる、小さくて軽いファイル。HumanLayer の "Writing a good CLAUDE.md"が示す「instruction budget（フロンティア LLM が一貫して従える命令数は概ね 150〜200 程度という経験則）」の範囲内に収まるよう、意図的にコンパクトに保たれています。この「150〜200」という数値の初出は、Heavybit による HumanLayer 共同創業者 Dexter Horthy 氏のインタビューです。

Layer 2：Component MCP（コンポーネントのオンデマンド提供） ——個々のコンポーネントの API、プロップス、バリアント情報は、MCP（Model Context Protocol）サーバーとして独立させました。AI エージェントは「ボタンのバリアントを知りたい」と思ったときにだけ MCP サーバーに問い合わせ、必要な情報だけを取得します。全部を最初から読み込む必要がない。

Layer 3：AGENTS.md（オーケストレーション） ——Layer 1 と Layer 2 をどう組み合わせるか、どのルールが常時適用で、どの情報をオンデマンドで取得するか、という指揮系統を定義する層です。Bormüller 氏の記事では、AGENTS.md が「常時有効なルールがどれで、MCP サーバーの所在はどこで、信頼度はどう配分するか」を定義するオーケストレーション層として位置づけられています。

この設計を Spotify は "way smaller context bubbles（はるかに小さなコンテキストの泡）" と呼んでいます。AI エージェントのコンテキストウィンドウを、一つの巨大な泡ではなく、必要に応じて膨らむ小さな泡の集まりとして管理するという考え方です。

ここには DESIGN.md を導入する上で、最も実践的な教訓が含まれています。DESIGN.md に全部を書こうとしてはいけない。Foundations だけを書き、コンポーネントの詳細は別の仕組みで提供する。この分離の思想は、規模の大小を問わず適用できます。

Indeed の高速パイプライン

求人プラットフォーム Indeed は、別のアプローチで AI 時代のデザインシステムに取り組んでいます。

Indeed の Senior Design System Designer である Diana Wolosin 氏は、自社のデザインシステムの MDX ドキュメント（77 コンポーネント分）を JSON メタデータに変換し、8つの異なる MCP 構成を 1,056 のプロンプトでベンチマークしました。結果は明快で、JSON 形式は Markdown 形式に比べてトークン数で 80% 減、年間コストで 5倍の削減（$1,500 → $300）を達成しました。そして、MDX が更新されるたびに自動的に JSON メタデータに変換されるパイプラインを構築した結果、4ヶ月間で 4,300 の AI プロトタイプが生成されたと報告しています。

この数字が示すのは、デザインシステムを「AI が読める形」に変換するだけで、プロトタイピングの速度が桁違いに上がるということです。4,300 という数は、人間のデザイナーが手作業で4ヶ月に作れる量を遥かに超えています。

Diana 氏の実践的なルールが印象的です——「JSON for MCP, Markdown for LLM」。コンポーネント API・プロップス・サイズ・バリアントといった構造化された契約は JSON で（曖昧さを排除できるから）、一方で LLM への指示や原則といった自然言語のルールは Markdown で。形式を目的に合わせる、という当たり前のようで見過ごされがちな原則です。

ただし重要なのは、Indeed がこのパイプラインを「デザイナー不要にする仕組み」ではなく、「デザイナーが探索できる選択肢を爆発的に増やす仕組み」として位置づけていることです。4,300 のプロトタイプは、すべてがそのまま採用されるわけではない。デザイナーがその中から可能性を見極め、方向性を選択し、磨き上げる。探索の量を AI が担い、判断の質を人間が担う。この分業が、Indeed のアプローチの核心です。

Anthropic：凡庸との戦いを宣言する

AI を作る側の Anthropic 自身も、この問題に正面から取り組んでいます。

Claude Code 用に公開されている frontend-design スキルは、第1回で触れた "distributional convergence"（分散収束）への明確な対抗宣言です。このスキルは、公式ブログが「約400トークンのコアプロンプト」と表現するほどコンパクトな指示でありながら、"AI slop（AI のつくる凡庸）" と呼ばれる美意識を避けるよう明示的に指示しています。

具体的には：

  • タイポグラフィ：「Arial や Inter のような汎用フォントを避け、個性的な選択を」
  • カラー：「支配的な色と鋭いアクセントの組み合わせが、均等に分散された臆病なパレットを上回る」
  • 背景：「単色に逃げず、空気感と深みを持たせる」

Anthropic の公式ブログは、このスキルが生まれた背景を "distributional convergence" という言葉で説明しています。LLM は訓練データの統計的中心に収束する傾向があるため、誰も不快にさせない「安全な」選択——白背景、紫グラデーション、Inter フォント、予測可能なレイアウト——を出力しがちになる。それを意識的に押し戻すために、Anthropic は自社の AI に向けた「反凡庸マニュアル」をあえて外部公開した、ということです。

ここには、AI を作っている企業自身が「AI の凡庸さ」を最も深刻に受け止めているという事実が表れています。Anthropic は、自社の AI が生成するデフォルトの美意識に満足していない。だからこそ、それを矯正するスキルを公式に提供している。

このスキルは2026年4月時点で277,000 回以上インストールされており、Claude Code プラグインとして AI 時代のデザイン品質基準の事実上の標準になりつつあります。

個人の実践：Figma を開く前に言葉を置く

企業の事例だけでなく、個人のデザイナーの実践も見ておきましょう。

プロダクトデザイナーの Katherine Yeh 氏は、Claude Code を使ったデザインワークフローについての記事を Medium の Bootcamp で公開しています。彼女の実践で最も注目すべきは、最初の一歩が Figma を開くことではなく、「デザイン原則を言葉で書く（スキル化する）」ことだったという点です。

彼女は Claude Code のワークフローを三層で整理しています。Reference Skills（デザイン原則・コンポーネント仕様・コンテンツガイドラインなどの「知識」）、Capability Skills（design-review、generate-design、identify-ux-problems などの「能力」としてのワークフロー）、そして Tools & Connectors（MCPs）（Figma・Jira・Wiki などの外部接続）。この整理が示唆的なのは、まず「知識」を明文化し、それを「能力」が参照し、最後に「道具」につなぐという順序です。Figma を開くのは最後。

そしてスキルファイルを書くこと自体も、ゼロから身構える必要はありません。彼女は「自分のガイドラインのドキュメントを貼り付け、何が大事かを口頭で Claude に説明すれば、Claude がドラフトしてくれる。あとはレビューして調整するだけ」という趣旨のことを書いています。デザイン原則を Claude と一緒に「対話で書き起こす」——これが、2026年のデザイナーの新しい一日目の作業です。

もう一人、デザイナーの Felix Lee 氏の実践も示唆的です。彼は Creator Economy のインタビューで、数千人規模のデザイナーに Claude Code と Figma MCP を使ったデザインワークフローを教えていることを明らかにしています（原文は "1000s of designers"）。彼の発言を私なりに要約すれば、デザインと実装の間に存在してきた「翻訳レイヤー」が消えつつある、という話です。Felix 氏自身の言葉では「デザインとコードの間の gap は translation problem だった」「Figma MCP で design-to-dev の translation loss がなくなった」と表現されています。デザイナーがデザイナーの語彙で「こうしたい」を伝えると、Claude Code がそれをコードに翻訳する。かつてエンジニアに「このパディングは16px にしてください」と伝えていたコミュニケーションコストが、AI との対話に吸収されていく。

共通するパターン：まず言葉を置く

ここまでの事例を振り返ると、ある共通パターンが浮かび上がります。

Spotify は、Encore のドキュメントを「AI が読める形」に再構築しました。Indeed は、MDX を JSON に変換する自動パイプラインを組みました。Anthropic は、AI の美意識を矯正するスキルを「テキスト」で定義しました。Katherine Yeh 氏は、Figma を開く前に「デザイン原則を言葉で書く」ことから始めました。Felix Lee 氏は、デザイナーの語彙がそのまま実装指示になる体験をしました。

すべての起点が、言葉です。

コンポーネントを Figma で組むことでもなければ、ピクセルを調整することでもない。まず言葉でデザインの意図を定着させ、それを AI が読み取り、実装に翻訳する。この流れが、2026年のデザインワークフローの主流になりつつあります。

これはデザイナーにとって、決して脅威ではありません。むしろ逆です。

考えてみてください。デザイナーの仕事が「ピクセルを動かすこと」だけだった時代、その仕事は AI に代替されやすいものでした。しかし「言葉でデザインの意図を定義する」仕事は、ブランドの本質を理解し、顧客の心理を読み解き、ビジュアルとビジネスの接点を言語化できる人間にしかできない。前回見た Linear / Stripe / Notion の例が、まさにそれを証明しています。

AI が実装を担うほど、「何を作るべきか」を定義する人間の役割が重くなる。 その定義を最も美しく、最も精密に行えるのは、長年ビジュアルの世界で審美眼を鍛えてきたデザイナーです。

小さな実験

今回の実験は、実際に手を動かしてみるものです。

Claude Code でも ChatGPT でも構いません。好きな AI に、こう話しかけてみてください。

「私のプロダクト（あるいは好きなブランド）のデザイン原則を、DESIGN.md の第一セクション『Visual Theme & Atmosphere』の形式で書いてみて。ブランド名は〇〇、顧客層は△△、目指す印象は□□」

AI が生成した文章を読んでみてください。おそらく、悪くはないけれど「何かが足りない」と感じるはずです。その「足りない何か」を、あなたの言葉で修正してみる。その修正こそが、あなたのデザイナーとしての価値です。

Katherine Yeh 氏が実践しているように、ゼロから書く必要はない。AI にドラフトを任せて、自分はレビューと微調整に集中する。この分業が、これからのデザイナーの最も自然なワークフローになっていきます。

次回は最終回です。ここまで見てきた DESIGN.md の可能性と限界、そして世界の実践を踏まえて、実際に運用するときに直面する現実——陳腐化のリスク、AI に任せる範囲の線引き、チームでの運用ルール——を整理します。

美しい言葉で書かれた DESIGN.md も、運用されなければただのテキストファイルです。最終回では、その言葉を「生きた文書」として維持し続けるための、地味だけれど決定的に重要な話をします。

参考文献

この記事をシェアする

X (Twitter) LinkedIn Facebook Bluesky Threads
山下 太郎

山下 太郎

代表取締役 / CEO

2000年、Webデザイナーとしてこの世界に飛び込み、フリーランスを経て2007年に株式会社アンタイプを創業。AI時代の到来とともに、効率だけを追うAI活用に違和感を覚えながら、それでも最前線でツールを使い続ける。企業のWebとコミュニケーションを設計する仕事を通じて、「人間らしさとは何か」を問い直す視点を発信し続けている。

View Profile arrow_outward

Categories

DESIGN.md デザイン AI AIエージェント

Related

あわせて読みたい

すべての記事を見る arrow_forward