デザインシステムとは何か。スタイルガイドと何が違うのか

「デザインシステムを作ったが使われていない」という相談と、「そもそもどこまでを含む言葉なのか社内で揃っていない」という相談は、たいてい同時に来ます。後者が片付いていないと、前者の原因も特定できません。

説明が割れているのには理由があります。デザインシステムという語は、作る対象の名前としても、続ける仕組みの名前としても使われています。公開されているデザインシステムを並べても、何を構成要素に数えるかは揃いません。どれかが誤りというわけではありません。

共通している部分と、割れている部分は分けて見た方が早い。2026年8月時点の状況です。

デザインシステムとは何か

デザインシステムは、プロダクトのデザインを大規模に扱うための基準を、参照先1つにまとめたものです。NN/g は「再利用可能な要素を使ってデザインを大規模に管理するための基準の完全なセット」と定義しています。UXPin は「原則・ガイドライン・コンポーネント・トークン・ドキュメントを統合した包括的で単一の情報源」という言い方をします。

日本語で読める公的な定義には、デジタル庁のデザインシステム（DADS）があります。ブランドやコミュニケーションの価値観を指針化したデザインプリンシプル、情報アーキテクチャとインタラクションデザインに基づくコンポーネント定義、アクセシビリティを含む規範となるデザインガイドライン。この3つから成るデザインアセットの集合体とされ、単なる規約ではなくアクセシビリティと組み合わさった仕組みだと書かれています。

ここまではおおむね揃っています。原則、ガイドライン、トークン、コンポーネントを束ねて、参照先を1つにする。割れるのはこの先です。

スタイルガイドとは何が違うのか

スタイルガイドはデザインシステムより狭く、その内側に置かれます。NN/g は両者を親子関係として整理し、スタイルガイドを「特定の実装ガイドラインを含む1つのドキュメント」と位置づけています。デザインシステムが基準の集合で、スタイルガイドはそのうちの1冊、という関係です。

ただし、そのスタイルガイドがどこまでを含むかで説明が分かれます。NN/g はスタイルガイドを「コンテンツ」「ブランド」「フロントエンド」の3種に分け、コピーのトーンもその範囲に入れています。日本語の解説記事では、色・フォント・余白といった視覚要素に限定して説明するものが目立ちます。「スタイルガイドはあります」という言葉が、見た目のルールだけを指すのか、文言の書き方まで含むのかは、聞き返さないと分かりません。

逆向きの用法もあります。デジタル庁 DADS は、スタイルガイドを「個々のウェブサイト向けのデザイン仕様書」とし、デザインシステムのコンポーネント定義を複製して、ロゴやブランドカラー、デザイン原則をそのサービス固有のトーンに合わせて追加・編集したものと説明しています。この使い方では、スタイルガイドはデザインシステムの部分集合ではなく、そこから派生した各サービスの実装仕様になります。

UIキットとコンポーネントライブラリ

UIキットは、Figma などのデザインツール上で作られたパーツの素材集を指し、実装コードを持つコンポーネントライブラリとは別物だと明確に分ける説明があります。一方で、Goodpatch はデザインシステムの構成要素の1つとして「ユーザーインタフェースキット」を挙げますが、実装物との違いには踏み込みません。UXPin は、スタイルガイド、パターンライブラリ、コンポーネントライブラリのいずれもデザインシステムの部分集合として並べています。

区別しておきたいのは、デザインファイルの中だけに存在するのか、実装から呼び出せる形で配られているのかです。同じ「UIキット」という言葉で、この2つが混ざります。

構成要素の数え方は出典ごとに違う

公開されているデザインシステムと、提唱者の定義を並べると、要素の数も内訳も一致しません。

出典	構成要素の区分
Atlassian Design System	基盤（デザイントークン、ガイドライン、ビジュアルスタイル）、コンポーネント、パターン、ツールの4区分
GOV.UK Design System	スタイル、コンポーネント、パターンの3区分。政府のデザイン原則は構成要素として並べず、従う考え方として別に置いている
デジタル庁 DADS	デザインプリンシプル、コンポーネント定義、デザインガイドライン
Goodpatch	原則、ブランドガイドライン、ユーザーインタフェースガイドライン、ユーザーインタフェースキットの4要素
Nathan Curtis（2017年）	再利用可能なパーツのキット、まとまりのある複数プロダクト、協働するコミュニティの3層

このうち、デザイントークンの名前の階層と、定義をデザインツールと実装のどこに置くかはデザイントークンとは何かで整理しています。

性格がいちばん違うのは Nathan Curtis の3層です。2017年10月10日の記事で、デザインシステムを「再利用可能で相互接続されたパーツのキット」「まとまりのある相互接続された複数プロダクト」「協働する相互接続されたコミュニティ」の3つの相互関連するシステムとして定義しました。他の説明では構成要素に入ってこない人と組織が、ここでは要素そのものに含まれています。

正解を1つ選ぶ話ではありません。粒度の切り方が違います。ただ、社内で「デザインシステムを作る」と言うとき、誰の区分で数えているかが揃っていないと、どこで完成なのかもずれます。

成果物として見るか、運用として見るか

定義は、作る対象として見る立場と、続ける仕組みとして見る立場に分かれます。説明が割れる根っこはここです。

議論が噛み合わないときは、片方が納品物の話をしていて、もう片方が運用の話をしていることがあります。

言葉の出どころ

「デザインシステム」という語がいつ生まれたかを明言した一次資料は、2026年8月時点で見つけられませんでした。複数の実践者の仕事が積み重なって2016年前後に業界用語として定着した、という整理をする二次資料はあります。年号を一次で確認したわけではないので、由来としては断定できません。

日付まで確認できるものもあります。2011年8月19日、Twitter の Mark Otto と Jacob Thornton が、社内のツール開発で1年以上使っていたスタイルガイドをもとに Bootstrap をオープンソースとして公開しました。再利用可能なUIパーツをコードで配るという発想が広まったのはここからです。定義の側では、2017年の Nathan Curtis の記事が繰り返し引用されています。

機能しているかをどう見分けるか

作ったデザインシステムが運用として動いているかは、そこからの逸脱を機械的に判定できる状態になっているかで見分けられます。

Nue はプロダクトを週次でクロールして、UX、UI品質、デザインシステムからの逸脱、アクセシビリティ、コピー、コンバージョンの阻害要因の6観点でレビューします。コントラスト比、代替テキストの有無、デザイントークンからの逸脱のように機械で判定できる項目は自動化し、UXの妥当性は人が見ます。

この設計上、見積りはデザインシステムの有無で変わります。定義されたルールがあれば、そこからの逸脱を機械にかけられる。無ければ基準づくりから始めることになります。

「デザインシステムがあります」という自己申告と、逸脱を検知できる状態は別ものです。機械が拾えるのは、形式が決まっている項目に限られます。判定できないルールは、誰かが毎回目で見て気づくしかない。

AIエージェントにデザインを作らせる場面でも、見分け方の軸は同じです。制約と検証をエージェント向けに体系立てたものはデザインハーネスと呼ばれ、検証層を運用し続けたときに何が起きるかは別記事にまとめています。

週次で見ている6観点の内訳は プロダクト開発支援 のページに書いています。

守られなくなるのはどこからか

形骸化の理由として挙げられるのは、作った後の扱いです。Goodpatch は、他組織の完成度の高いデザインシステムをそのまま流用すると組織との乖離が生まれること、厳格なルールとして定めておきながら運用を怠ることを、失敗の要因として説明しています。

実務で厄介なのは、運用を怠っているのか、そもそも逸脱を検知する手段が無いのかが、外からは同じに見えることです。ドキュメントはあるのに実装から外れを判定できない状態と、判定できるのに直していない状態では、次の一手が違います。前者は基準を実装に落とすところから、後者は直す順番を決めるところから始まります。

作ったものが使われないという形は、デザインシステムに限りません。生成AIのPoCが本番に行かないで書いたのも、精度ではなく置き場所が無いまま作られている、という話でした。

作らない方がいい場合

1つは、他社の完成度の高いデザインシステムを持ってきて自社に当てる場合です。この進め方は失敗の要因に挙げられています。参照するのと、そのまま使うのは別です。

規模の面では、Nathan Curtis の定義が「まとまりのある複数プロダクト」を構成要素に含んでいることが手がかりになります。複数のプロダクトや画面をまたいで同じ判断を繰り返している状態が、この定義の前提として置かれていると読めます。

何画面から必要になるか、という線引きを数字で置くのは難しい。プロダクトの複雑さと、同じ判断を繰り返している回数で変わります。

代わりに置ける判断材料は、定義した後にそれを見張る担当と頻度を用意できるかどうかです。用意できないまま作れば、Goodpatch が挙げる失敗の形をなぞることになります。