「すべてのコンポーネントは提供しない」─ AIと変数が支える、余白のあるデザインシステム構想
はじめに
BtoC、BtoB、社内ツールなど、多岐にわたるプロダクトのデザインを下にフロントエンド実装をしてきました。
その時々の状況・環境や経験を通じて、自分自身のデザインシステムの考え方はアップデートされていきました。
最初のころは、コード目線でのデザインシステムのあり方が目線でした。共通化されたコンポーネントをデリバリーして適用することが正しいと思っていました。
しかし、プロダクト単位や複数のプロダクトとコンテキストが変わるにつれ、考え方も変わっていきました。
職種や利用シーンや業務ドメインが違えば、プロダクトに求められる最適なUX/UIは全く異なる
プロダクトごとに求めるUX/UIは異なります。
業種や業務フローに応じて共通化されたコンポーネントを適用することは、ターゲットが変わればノイズになります。
それなのに、多くのデザインシステムは「一貫性」という名のもとに、すべてのUIパーツを共通化しようとします。
その結果、「この機能には合わないからOverride（上書き）しよう」が常態化し、システムは現場の課題解決能力を奪う道具と化します。
エンジニア目線では、共通化されたコンポーネントであれば画面を早く作れるという利点や、再利用性の高いコンポーネントを作ることで一貫性が保てて横展開も容易になると考えます。この考え方自体は間違いではありません。
しかし、いざ現場に落とし込まれると、一貫性が崩れたり、システムとの乖離が生まれたりします。
ドメイン駆動設計の考え方に基づくと、職種・利用シーンによってプロダクトに求められる要件は変わるからです。
コンポーネントを拡張したり、拡張が難しければ似たようなコンポーネントを作成するというサイクルが繰り返され、結果としてそれが制約になったり形骸化したりします。
この課題は、ずっとつきまとっていました。
この課題に対する私の結論（2025年11月時点）は、「共通して使うものは、最小限であればあるほどいい」 というものです。
本記事では、経験則から 「縛るためではなく、解き放つための最小構成デザインシステム」 の思想と構造について解説します。
1. 哲学：形は「課題」によって変わる。変わらないのは「DNA」だけ
なぜ、すべてのコンポーネントを用意するアプローチが失敗するのでしょうか？
それは、UIの 「形状（Shape）」や「レイアウト」は、ユーザーの課題を解決するために柔軟に変わるべきもの だからです。この可変領域にシステムが固い制約を設けてはいけません。
最小限の要素を定義しDNAをプロダクトごとに提供していかなければなりません。
-
提供するもの（不変のDNA）：
ブランドの核となるVariables（変数）やDesign Tokens（色、タイポグラフィ、余白、ラディアス）。 -
提供しないもの（可変の形状）：
特定の文脈に依存する複雑なコンポーネントやレイアウトパターン。
最小構成にすることは手抜きではありません。
現場のデザイナーが最高のUXを導き出せるよう、あえて「余白」を残す戦略 と考えます。
2. 組織戦略：最小限にすることは、現場への「配慮」である
「最小構成」は、技術論であると同時に、極めて重要な組織論でもあります。
システムを組織全体、全プロダクトに広げよう（一般化しよう）とするほど、ルールは減らさなければなりません。
ルールがガチガチであるほど、個別の事情を持つ現場との 「摩擦」 を生み、システムは使われなくなります。
組織が大きくなればなるほど、プロダクトの数が増えれば増えるほど、現場の課題は多様になっていきます。
また、ルールが多ければ多いほど、人によって解釈が異なってくることから、ルール自体も薄いほうが定着しやすくなります。
- 摩擦の回避: 最小限のガードレールにするのは、現場の専門性、そして各事業の固有性を尊重するという 「配慮」 が必要
- 集中力の確保: 摩擦をなくすことで、全社が内向きの議論ではなく、外向き（事業・顧客）の課題解決に集中できる
「最低限のガードレールさえ守ってくれれば、あとは事業の最適化を優先していい」。この信頼関係が、システムの利用促進への第一歩だと考えます。
3. 実践論：最小構成デザインシステムを支える4つの原理
デザインシステムは、エンジニアだけでもできないしデザイナーだけでは完結しません。
それぞれの得意な領域をチームとして協働して作り上げなければならない。
それぞれの領域が噛み合わなければ、前に進むことも完成に至らない。
よくあるデザインシステムは、プロダクトに対して 1:1（デザインシステム1つ 対 プロダクト1つ）の関係であり、Figma のデザイン : プロダクトコード であれば、APIを通じて自動的に同期し、仕組み化はできるでしょう。（Figma MCP / Figma Makeなど）
以下の記事のように、AIやMCPを駆使することでフローを組み合わせることで自動化は可能です。
Figma MCPを使った開発やワークフロー（仕組み化）を取ること自体は否定しているわけではなく、自分はもっとコンテキストは広く組織的に横展開するにはプロダクトの持ってる課題が変わってくると感じています。
事業会社であれば複数のプロダクト を持っており、その一貫性をプロダクトに適用して効率化を図ろうとして、1:N（デザインシステム1つ 対 プロダクトN個）で考えてしまうと失敗します。
1:1 の関係では、プロダクト自体に課題ベースでコンポーネントをつくれるのに対して、1:N は組織的・プロダクトを横断的な部分にコンテキストが広がっていきます。
そのため、横断的な仕組みはより広く一般的なものになってしまうため、ここをガチガチなルールにするとうまく組織やプロダクトへ適用できなくなります。
組織や各プロダクトへの横展開には、より最小構成になっていることと3つの原理がベースにある必要があります。
① ガードレール（守るべき最小限のルール）
守るべきルールは、最小限に絞り込むことが重要です。
事業会社や受託開発でも、この最低限のルール適用がポイントになると考えます。
エンジニアであれば、コードの書き方のルールを手動でチェックするのではなく、ESLintでルールを自動適用することで、ルールの適用を仕組み化しています。
デザインシステムでも同様に、最低限のガードレールで認識を揃えておくことが重要です。
- 定義: トークンと合わせて、グリッドシステムやスペーシングのルールを 「安全柵」 として定義
- 役割: この柵の内側であれば、どれだけ自由にデザインしても 「プロダクトとしての最低限の品質とリズム」 は担保される
② コンポーネントの「サンプリング」と「拡張」
Headless UIやshadcn/uiといった、一般的に提供されているオープンソースのコンポーネントライブラリは、広く多くの人が利用できるように設計されています。事業規模によっては扱いやすく、素早くプロダクトをデリバリーできるため、実現可能性の検証には最適です。
しかし、事業固有のプロダクトデザインにおいては、そのまま適用できない部分も多くあります。そのため、先ほど述べたガードレールをベースに拡張していく必要があります。
コンポーネントの「サンプリング」と「拡張」では、最低限のサンプルコードを提供しつつ、それらを拡張できるようにすることが重要です。コンポーネントをルールとして固定するのではなく、良質な素材として活用することで、ビジネスやプロダクト、ドメインに合ったコンポーネントへと拡張していくことが望ましいです。
提供するのは、ガードレールを適用したサンプルコンポーネントです。これらを具体例として、どのように使えば良いかを示すべきだと考えます。
-
定義: コンポーネントは
npmパッケージなどで提供しますが、これは「変更不可の完成品」ではなく、「良質な素材（Reference Implementation）」 です。 - 役割: エンジニアはそれをそのまま利用するだけでなく、現場の要件に合わせてコードレベルで 自由に拡張（Extend） を行える。形を変えることは、事業課題解決のための正規のフロー
③ AIによるレビューの仕組み化とガードレールの自動強化
従来の人の目による目視レビューは、コストが高い上に、技術の進化（AI）によって代替可能になりました。
この「人の手による検品作業」を、テクノロジーに置き換えることで、レビューの仕組み化自体も進化しています。
システムが定義したコンテキスト（最小限のルールセット）をAI/Linterに適用することで、デザインのガードレールに対するチェックが自動で、かつ即時に行われます。
- AI/Linterの役割: トークン定義外の色や、ルールに反した余白の使用など、機械的な違反を検知し、自動でエラーを出します。
- 結果: 人間が「間違い探し」に時間を割く必要がなくなり、「UXの本質的な価値」 の探求に集中できるのです。
4. 結論：デザインシステムは「部品屋」ではない
デザインシステムは、コンポーネントをデリバリーするためのシステムではありません。
コンポーネントを提供すること自体が目的ではなく、プロダクトの課題によって変化するものです。
そのため、デザイナーとエンジニア、そしてPO・PdMといったプロダクトに関わるメンバーと対話しながら進めていかなければなりません。
コンポーネントの「配給」は、本質ではない
デザインシステムの目的は、モノを詰めた箱を納品する「部品屋」 になることではありません。
便利なUIキットを配り続けるだけのチームは、いずれ現場の下請けになります。
プロダクトごとにクリエイティブが必要であることを前提に、デザインシステムのあり方そのものも変化が必要ではないだろうか。
組織論で考えるデザインシステムのあり方は、「余白」ではないだろうかと結論に至りました。
ガチガチにしたルールやコンポーネントルールではなく、薄い規則やルールをベースにプロダクトに応じて拡張していける形が、各プロダクトのクリエイティブを解き放つデザインシステムのあり方ではないだろうか。
真の目的は「Why」と「How」の対話である
デザインシステムが提供すべきは、「なぜ（Why）を語るデザイナー」と「どのように（How）を実現するエンジニア」 が対話し、協働するための共通言語（ハブ）です。
- デザイナーの役割： Whyの探索（課題と変数の定義）
- エンジニアの役割： Howの探索（最小構成からの拡張と実現）
職種間が互いの領域を尊重し、WhyとHowが噛み合うことで、初めてシステムは生きたツールとして機能します。
デザインシステムは、部品をデリバリーする繰り返しではなく、ルールの定義を最小限にしてそれぞれのプロダクトの課題や環境に応じて変化させます。
テンプレートを機械的に量産するのではなく、プロダクトごとに異なる課題に対してクリエイティブな解を導き出すため、仮説検証を繰り返し、プロダクトの価値を高めていくために同期的に対話する必要があります。
プロダクトごとにクリエイティブが必要であることを前提に、デザインシステムは「縛るためではなく、解き放つための」最小構成であるべきなのです。
まとめ
「すべてのコンポーネントは提供しない」という逆説的なアプローチに基づき、組織の創造性を最大化する最小構成デザインシステムの思想を解説しました。
職種や利用シーンによって最適なUX/UIは異なり、ガチガチな共通コンポーネントは現場の 「摩擦」 を生み、システムを形骸化させる最大の原因となります。
形（Shape） は課題に応じて柔軟に変化させるべきであり、システムが提供すべきは、ブランドの核となる DNA（Variables / Design Tokens） という不変の要素のみに絞るべきです。
最小限のガードレールにすることは、現場の専門性に対する 「配慮（リスペクト）」 であり、組織内の摩擦を最小化し、全社が顧客課題に集中するための戦略でもあります。
言い換えれば、デザインシステムは クローン人間を量産するのではなく、状況や環境に応じた人間を育てる ようなものであるべきです。同じDNA（Design Tokens）を持ちながらも、それぞれのプロダクトが独自の課題に応じてクリエイティブに進化していく。
そのような柔軟性と多様性を許容するシステムこそが、組織の創造性を最大化できるのではないでしょうか。
Figma Makeや他のAIツールの進歩は早く、ツールの進化に伴ってやり方も変化していきます。しかし、本質的な 「最小限」 という部分は、時代が変わっても変わらない基本の考え方として持ち続けていきたいと考えています。
Discussion