---

---

デザインシステムとは、プロダクト開発を進める上でのルールや利用できるツールがまとまった仕組みのことです。
特にデザイナー・エンジニアが実務の際に参考にすることで、一貫性があり安定したプロダクト開発を進めるのに役立ちます。

この記事では、デザインシステムの基礎知識からメリット、作り方や便利なツールまでを解説します。

デザインシステムとは？

デザインシステムとは、プロダクトをより良いものとするためのルールやツールが連携した形でまとめられたものです。

皆さんが今読んでいる『NIJIBOX BLOG』にも、文体やサイトデザインを定めるためのルール、見出しやリンクをページ内に実装するためのツールがあります。
これらは、「このブログを通してより多くの人にUI UXの情報を発信する」ために考え、ルール化やツール化をしたものです。

デザインシステムのポイントは、ルールやツールが「連携した形で」まとめられている点です。

色やテキストに関するルールと、ボタンを実装するソースコードといったツールを別々に用意するだけでは、「ルールとツールの整備」に過ぎません。
ルールを定義し、それにのっとった形でツールを作ることではじめて、「連携した形」となります。

良いプロダクトを実現するために定めるものが「ルール」で、その実現をサポートするものが「ツール」、これらをセットで考えられたものが「デザインシステム」です。

デザインシステムと関連用語の違い

混同されやすい関連用語との違いを一覧にまとめました。呼び方や含める範囲は組織によって異なるため、以下は本記事での整理です。

概念	役割・特徴	含まれる主な構成要素
デザインシステム	プロダクト開発全体を効率化・統合する仕組み	デザインの基本方針、色・文字・余白のルール、共通のUI部品、更新・共有の仕組み
デザインガイドライン	デザインをする上での方針やルール全般	デザインの基本方針や、見た目・使い方のルールを説明した文書
スタイルガイド	主に視覚的な表現のルールをまとめたドキュメント	色、タイポグラフィ、余白などの視覚ルール
パターンライブラリ	よく使うUIの型や使い方をまとめたもの	よく使うUIの組み合わせ、用途、使い方。実装例を含む場合もある

デザインシステムの定義

ここまでの解説で大まかにデザインシステムの概念を捉えられたところで、より理解を深めるために改めてその定義を見ていきましょう。

デザインシステムとは、プロダクトをより効率的でまとまりのあるものとして進めるため、個人、チーム、または組織によってビジュアルスタイル・コンポーネント・およびその他の懸念事項のライブラリをコードおよびツールとしてドキュメント化したもの。

－Nathan Curtis（Defining Design Systems / EightShapes）

これは、アメリカのUXコンサルティング会社を経営するNathan Curtis氏が「Defining Design Systems（デザインシステムの定義）」と題した記事内で定義したものです。

同記事では、さらに次のように続きます。

システムとは、統合された全体を形作る相互連携されたパーツのセットを意味します。デザインシステムもこの定義にのっとり、次の3つの要素を包含しています。

1. 再利用可能な相互連携されたパーツ一式
2. 相互連携されたまとまりのあるプロダクト
3. 協調的で相互連携された組織

－Nathan Curtis（Defining Design Systems / EightShapes）

Nathan Curtis氏による定義を整理すると、デザインシステムは次のように理解ができます。

• 目的は？：効率的でまとまりのあるプロダクト開発・運用
• 誰によって？：チームまたは組織（デザイナーもエンジニアも）
• 何を用意する？：ビジュアルスタイルやコンポーネント、その他懸念事項がツールとしてまとめられた一式

デザインシステムと混同されやすい概念と、その違い

前述の表で触れた通り、デザインガイドライン、スタイルガイド、パターンライブラリといった概念は、デザインシステムとよく混同されがちです。
それぞれの意味と、デザインシステムとの違いを押さえておきましょう。

デザインガイドラインとデザインシステムの違い

デザインガイドラインは、その名の通りデザインをする上でのガイドライン全般のことです。
ブランドアイデンティティやデザイン指針などの原則から、色やタイポグラフィといった具体的なルールまでを要素として含みます。

デザインシステムとデザインガイドラインの違いは、コンポーネントライブラリが含まれない点です。
つまり、デザインガイドラインは「実装前段階」までのガイドラインと言えます。

デザインガイドラインについては以下の記事で解説しています。ぜひ参考にしてみてください！

スタイルガイドとデザインシステムの違い

スタイルガイドは、見た目や表現のルールを指します。
デザインシステムに含まれる原則やコンポーネントライブラリは含まれず、視覚的なルールのみをまとめたドキュメントです。

パターンライブラリとデザインシステムの違い

パターンライブラリは、特定のプロダクト（または、企業やブランド）内で使うデザインパターンをまとめたものです。また、そのデザインを実装するコードも含まれるため、コンポーネントライブラリと似た概念と言えます。

デザインシステムとパターンライブラリの違いは、前者が原則まで含むのに対して、後者は含まない点です。「制作背景や途中経過は抜きにして、既に出来上がったデザインパターンを一覧化したもの」がパターンライブラリです。

デザインシステムの構成要素の3つの分類

先ほど解説した定義に、「ビジュアルスタイルやコンポーネント、その他懸念事項」と記載がありました。
これらがデザインシステムの構成要素ですが、やや分かりにくい単語が並んでいると思いますので、もう少し詳しく解説します。

本記事では、基本となる構成要素を「上位概念である原則」「スタイルガイド」「コンポーネントライブラリ」の3つに分けて説明します。3つはそれぞれが独立したものではなく、相互連携していることを理解しておきましょう 。

スタイルガイドは、原則に基づいて作られ、コンポーネントライブラリはスタイルガイドに基づいて作られます。場合によっては、スタイルガイドやコンポーネントライブラリに対するフィードバックを受けて、原則が見直されることもあります。このように、お互いが影響を与え合い、一つの大きなデザインシステムが形作られていくのです。

紹介する要素を、初めから全てそろえる必要はありません。チームや組織にとって必要な要素を適宜取り入れ、擦り合わせながら育てていく意識で良いと思います。

具体的な導入について以下の当ブログ記事でも詳しく解説しています。

• 導入を検討するときに押さえたいポイント［1/3］
• 導入の段階と、プロダクト・チームの課題の考え方［2/3］
• 導入コスト・費用対効果と運用計画の考え方［3/3］
• 支援事例から学ぶデザインシステム構築の成功ポイント
• 国内外のデザインシステム事例
• AIを活用したデザインシステム運用の実践例

1.デザインの原則

まず、その組織やプロダクトで共有するデザインの原則を定めます。この方針をもとに、見た目のルールや共通のUI部品を整えていきますが、原則に沿ってスタイルガイドやコンポーネントライブラリに取り掛かる必要があります。

上位概念である原則

• ブランドアイデンティティ（ブランドの方針、大事にしたいこと）
• デザインプリンシプル（デザインの指針）
• 情報設計
• コンテンツプリンシプル（コンテンツの指針）
• トーン&マナー（表現の指針）
• 用語集

などが挙げられます。

デザインの原則は、ブランドアイデンティティなど企業理念・ブランド理念も関連します。つまり、単にデザイナー達だけで作るのではなく、企業やブランド全体でデザインの原則を作るべきとも言えるでしょう。

2.スタイルガイド

デザインの原則に沿った、具体的なデザイン上のルールがスタイルガイドです。

原則に基づいたデザインルール＝スタイルガイド

• 色
• タイポグラフィ（テキストのルール）
• アイコン
• ページ内の余白
• アニメーション

などが挙げられます。

テキストやページ内の余白などは、ページごとにバラバラになってしまっては、UIに優れているとは言えないデザインになってしまいます。デザインの原則に沿って、ユーザーの使いやすさを考慮しながらスタイルガイドを作成していきましょう。

3.コンポーネントライブラリ

コンポーネントライブラリはUI開発で使われる再利用可能なパーツ群を指します。

ルールに基づいたパーツ群＝コンポーネントライブラリ

• ボタン
• ナビゲーション
• リスト
• アコーディオン

具体的なデザインを形作っていくためのビジュアルパーツや、UIとして実装するためのコードがセットになっている状態が一般的です。

コンポーネントライブラリは、スタイルガイドに沿って作成していきましょう。「デザインの原則」→「原則に従ったスタイルガイド」→「スタイルガイドに沿ったコンポーネントライブラリ」と連携させるからこそ、一貫性を持ち、UIに優れているデザインを完成させることができるのです。

デザインシステムの作り方3STEP

それでは、デザインシステムはどのようにして作るのでしょうか。具体的には、構成要素の章で分類した「上位概念である原則」「原則に基づいたルール＝スタイルガイド」「ルールに基づいたツール＝コンポーネントライブラリ」の順に作っていきます。

【STEP1】原則を決める

デザインシステム作成は、ブランドアイデンティティやデザイン・コンテンツ・表現の指針といった「原則」を定義してドキュメント化するところからスタートします。

場合によってはこれらの要素の多くが既に決まっていることもあるでしょう。プロダクト開発の初期段階における戦略策定や要件定義でのアウトプットを流用またはアレンジするだけでも構いません。
原則に関わる要素が曖昧だと、そもそもプロダクト開発自体がスムーズに進まないため、しっかりと定義しておきましょう。

【STEP2】スタイルガイドを作る

2つ目のステップは、色やタイポグラフィ、余白などを一つひとつ定めていき、スタイルガイドを作成することです。例えば色であれば、メインカラーとサブカラーはどれにするか、個別のパーツのカラー採用における方針を明確にし、ドキュメント化します。
前述の通り、全てを完璧に作る必要はありません。プロダクトの規模を考慮して、今時点で必要最低限の要素だけを用意することを意識しましょう。

【STEP3】コンポーネントライブラリを作る

デザインシステム作成の3つ目のステップでは、ボタン、ナビゲーションといったパーツのビジュアルとそれを実装するためのコードをセットで用意し、コンポーネントライブラリを作成します。

特にコンポーネントライブラリはデザインだけではなく実装にも大きな影響を与えます。原則やスタイルガイドに基づいた見た目になっているかのデザイナー的視点と、実現可能であるかのエンジニア的視点双方を考慮して作ることを意識しましょう。

デザインシステムの3つのメリット

ここからは、プロダクトの開発や運用にデザインシステムを用いるとどんな良いことがあるのかを見ていきましょう。

1. UIデザインに一貫性が生まれ、品質が向上する

デザインシステムを導入する1つ目のメリットは、UIデザインに一貫性が生まれることです。

良いプロダクトの条件の1つである「一貫したユーザー体験」を提供するには、UIの統一が欠かせません。例えば、同じECサイト内でページごとにボタンのデザインや操作性が異なると、ユーザーに無駄なストレスを与えてしまいます。

デザインシステムによってUIのルールを標準化すれば、プロダクト全体のデザインと操作性が統一されます。結果として、ユーザーが迷わず直感的に使えるようになり、プロダクト全体の品質向上が期待できます。

2. チーム内外のコミュニケーションがスムーズになり、連携が高まる

2つ目のメリットは、プロダクト開発に関わるメンバー間のコミュニケーションが円滑になることです。

デザイナーやエンジニア、ディレクター、さらには外部パートナーなど、立場の異なるメンバーが同じ方向を向いて進むには「共通のルール」が必要です。

例えば色のルールが曖昧なままでは、各自の主観で意見がぶつかり、議論がまとまらない事態を招きかねません。あらかじめデザインシステムで「主要ボタンはメインカラーのオレンジを使用する」と基準を設けておけば、こうした認識のズレを防げます。主観による不要な議論が減るため、より建設的で連携の取れたチーム開発が可能になります。

3.生産性が向上し、コスト削減につながる

デザインシステムを活用する3つ目のメリットは、各メンバーの生産性が向上することです。

例えば、ルール化されていることでデザイナーはデザインの判断スピードが速くなる、再利用可能なパーツがコードも含めてツール化されていることでエンジニアの実装が速くなる、などです。

また、先述のようにコミュニケーションがスムーズになるため、デザイナーからエンジニアへの情報伝達に関わる工数も少なくなります。

デザインシステムの導入時に押さえたいポイント

デザインシステムを導入するときは、解決したい課題を明確にし、整備の範囲と運用の進め方を決めておくことが大切です。例えば、UIの不統一や手戻りを減らす目的なら、修正回数や設計・実装にかかる時間を導入前後で比較すると、効果を検証しやすくなります。

スムーズな導入のポイントは？

• 初期構築の負担を抑える： 初めから全てをそろえず、よく使う色やUI部品から整備し、利用状況を確認しながら対象を広げます。
• 現場で使える状態にする： デザイナーとエンジニアで使い方を共有し、設計・レビュー・実装のどこで参照するか、誰が更新するかを決めます。
• 変更に対応できるようにする： 新しい機能に必要な部品や例外を検討できるよう、改善提案の窓口と確認・反映の進め方を決め、継続的に見直します。

自社に合う導入範囲をどう判断する？

導入の範囲は、人数や事業フェーズだけでなく、UIの不統一や手戻り、更新負担といった課題に応じて判断します。PMF前や少人数のチームでも、色や頻出する部品を最小限そろえる取り組みは選択肢になります。

整備を検討しやすい状況	まず小さく始めたい状況
・複数のプロダクトやサービスを展開している ・開発組織が急拡大し、メンバー間の認識ズレが増えてきた ・UIの不具合や一貫性の欠如がユーザー体験を損ねている	・PMF（プロダクトマーケットフィット）前のプロトタイプ段階 ・少人数（1〜2名）のデザイナー・エンジニアで完結している ・事業方針が頻繁にピボット（方向転換）する時期

【ニジボックスの支援事例】現場の利用実態を踏まえたデザインシステム刷新

ニジボックスは、株式会社エアークローゼットのファッションレンタルサービス『airCloset』で、デザインシステムの刷新を支援しました。
既存のFigmaデータと実装コードを調査し、コンポーネントの利用状況を整理。その結果をもとに再設計の優先順位を定め、デザイナーとエンジニアの合意形成を進めました。さらに、既存画面への段階的な適用と、設計・レビュー・開発連携までの運用フローを整備しています。

株式会社エアークローゼット｜デザインシステム刷新の支援実績を見る

---

💡 自社のフェーズに合った設計・運用でお悩みですか？
自社に必要な整備の範囲や、現場で使い続けるための進め方を検討している方へ。ニジボックスの支援事例と導入・運用のアプローチを資料で紹介しています。
デザインシステム支援の資料をダウンロード

デザインシステムについて学べる本

ここではデザインシステムについて体系的に学べる本を紹介します。

『Design Systems ―デジタルプロダクトのためのデザインシステム実践ガイド』

本書はインタラクションおよびビジュアルデザイナーとしてさまざま様々なプロダクトに携わった著者が、デザインシステムの導入、設計、運用に関して体系的に解説している本です。
基礎編と応用編で構成されているため、初心者からデザインシステム運用中の人まで幅広く役に立つ内容となっています。
Alla Kholmatova 著（2018）『Design Systems ―デジタルプロダクトのためのデザインシステム実践ガイド』ボーンデジタル

『ちいさくはじめるデザインシステム』

本書は人事・労務領域の業務アプリケーションSaaSを提供しているSmartHR社のデザインシステムの立ち上げから運用までの取り組みについて述べられている本です。

公開されているSmartHR社のデザインシステムと併せて読めば、よりデザインシステムについての理解が深まると思います。
ビー・エヌ・エヌ、大塚亜周・稲葉志奈 編著、金森悠・samemaru・圓山伊吹・植田将基・関口裕 著（2023）『ちいさくはじめるデザインシステム』

---

【自社書籍のご案内】ニジボックス独自の現場ノウハウを詰め込んだ書籍も発売中！

ニジボックスが実際の支援現場で培ったノウハウを体系化した書籍が、技術評論社より発売中です。デザインシステムの具体的な要素や運用方法・作り方など、現場目線での知見をさらに深く知りたい方はぜひ事実ベースの知見としてお役立てください。
技術評論社、株式会社ニジボックス 著（2024）『つくって、みなおす、デザインシステム——現場での合意形成から設計、運用まで』

国内外で公開されているデザインシステムの代表例

自社での設計を考える際は、企業や行政機関が公開するデザインシステムの構成や運用方法も参考になります。部品やコードを利用する場合は、公開されている範囲と利用条件を確認しましょう。
ここでは、代表的な公開デザインシステムの特徴と、内容を参考にするときの着眼点を紹介します。

デザインシステム名 (提供元)	公開内容・特徴	参考にできる点（本記事での独自解釈）	利用規約
デジタル庁デザインシステム | デジタル庁 (デジタル庁)	「誰一人取り残されない、人に優しいデジタル化を。」の実現に寄与することを目指し、行政機関や公共性の高い組織での利用を目的に開発。アクセシビリティを重視したUI部品、設計・実装ガイド、Figmaデータを公開しています。	行政手続きや幅広い人が使う申込みフォームを設計するときに。入力欄、エラー表示、キーボード操作の仕様を具体的に確認できます。	FigmaデータはCC BY 4.0。含まれる素材や編集・加工の有無によって個別の条件があります。文書・Figma・コードそれぞれの利用条件を公式ページで確認してください。 利用規約・ライセンス – デジタル庁デザインシステム
SmartHR Design System (株式会社SmartHR)	すべての人によりよい体験を届けるためのデザインシステムを目的に開発。UI部品に加え、アクセシビリティ、情報設計、画面の文章の指針も公開しています。	入力や確認作業が多い業務SaaSの画面を統一したいときに。フォームやテーブルの部品、画面パターン、分かりやすい文言の設計を参考にできます。	公開サイトの文章・画像・ブランド資産は公式の利用規約に従ってください。実装コードを利用する場合は、対象ライブラリのライセンスを個別に確認してください。 利用規約 | SmartHR Design System
Ubie Vitals (Ubie株式会社)	Ubieのプロダクトをすべてのユーザーに届けるためのデザインシステムとして開発。「気軽・かんたん・誠実・スッキリ」の原則を、色や余白、UI部品へ展開しています。	質問に答えて進むサービスや、入力の負担を減らしたいフォームに。Formのレイアウト、選択肢をカードで示す部品、案内文の書き方を参考にできます。	React向けのUbie UIはApache License 2.0で公開されています。サイト上の文章・画像やブランド資産まで同じ条件で使えるとは限りません。 ubie-oss/ubie-ui/LICENSE (GitHub)
Material Design (Google)	美しく使いやすいプロダクトをつくるための、オープンソース・デザインシステムとして開発。Material 3では、色・文字・形のテーマ設定と、共通のUI部品を提供しています。	Androidアプリの基本UIを整え、ブランドカラーやダークモードにも対応したいときに。配色の役割分け、テーマ設定、ボタンやナビゲーションの仕様が参考になります。	デザイン資料、実装ライブラリ、アイコンは配布元と条件を分けて確認してください。導入案内のみで全資産の利用条件を判断しないようにしましょう。 Get started – Material Design 3
Carbon Design System (IBM)	企業利用に対応するIBMのオープンソース・デザインシステム。チームが一貫したデジタル体験を、より速く構築できるようにすることを目的に開発。UI部品、画面パターン、データ可視化を、設計指針と実装コードで提供しています。	大量の情報を扱う業務画面や分析ダッシュボードを設計するときに。データテーブルの操作、グラフの表現、アクセシビリティを含めた実装例を参考にできます。	コードを利用する場合は対象リポジトリのLICENSE、ブランド資産を利用する場合は提供元の条件を確認してください。 carbon-design-system/carbon/LICENSE (GitHub)
Cloudscape Design System (AWS)	AWSの製品・サービス向けのデザインシステム。AWSのWebアプリケーションのユーザー体験を改善し、チームがより速く実装できるようにすることを目的に開発。React部品に加え、リソース管理の画面パターンや動くデモを公開しています。	クラウドサービスの管理コンソールや運用画面を作るときに。一覧の検索・絞り込み・選択、リソースの作成・編集など、一連の操作フローをデモで確認できます。	コードを利用する場合は対象リポジトリのLICENSEを確認してください。文書や画像、ブランド資産は個別の利用条件も確認が必要です。 cloudscape-design/components/LICENSE (GitHub)

デザインシステムの作成・運用を支えるツールの選び方

デザインシステムの運用では、デザインデータ、実装コード、そして使い方のガイドラインを紐付けて管理することが重要です。

無理に1つのツールで完結させようとせず、チームの制作・開発環境に合わせて最適なツールを使い分けましょう。「見た目を管理できるか」だけでなく、「デザインの変更をスムーズに実装へ反映できるか」「チーム全体へ簡単に共有できるか」といった視点も欠かせません。

ここからは、デザイン側と実装側それぞれの管理アプローチと、ツール選定時に確認すべきポイントをご紹介します。

Figmaでデザインデータを管理する

Figmaは、デザインシステムや具体的なデザインを作成していくためのツールです。実際に、数々の企業でデザインシステムをFigma上で公開しています。

Figmaの優れている点は、共同編集に優れていることと、実際のデザインやプロダクト開発まで一括のツールで作成できることです。

Figma上で、デザインシステムを確認しながら実際のプロダクトの進行ができるため、デザイナーはもちろん、チェックや議論をするメンバーにとってもスムーズに進めやすいツールと言えるでしょう。

Figmaはこちら

Figmaについて、より詳しく知りたい方はこちらの記事も参照してください。

実装側の管理とドキュメント

デザインの部品と実装コードを対応させ、どの部品をどの場面で使うかを共有できる環境を整えます。部品の状態や使用例を確認できるドキュメントと、変更履歴を追えるコードの管理を組み合わせると、デザインと実装の食い違いを見つけやすくなります。

ツール選定時に確認したいこと

ツールを選ぶ際は、現在の提供状況、利用プラン、デザインとコードの連携方法、データの書き出しや移行のしやすさを確認しましょう。

デザインシステムは浸透させなければ意味がない

最後に、「デザインシステムは誰のためのものか？」という問いで締めくくりたいと思います。

答えは、「プロダクト開発に携わる全ての人のためのもの」です。 実務で直接触れるのは主にデザイナーやエンジニアですが、ディレクターや他職種、さらにはクライアントにも共有し、浸透させることが重要です。チーム全体で共通言語を持つことで合意形成がスムーズになり、結果として高品質なプロダクトの効率的な開発へとつながります。デザインシステムは作って終わりではなく、現場に浸透してはじめてその真価を発揮するのです。

本記事が、デザインシステム導入の参考になれば幸いです。

一方で、ここまで作り方や運用ポイントを解説してきましたが、「自社だけでゼロから進めるのはハードルが高い」と感じる方もいらっしゃるでしょう。

せっかく作ったデザインシステムを形骸化させず、現場の実務でしっかりと機能させるため、ニジボックスでは導入から運用までの伴走支援を行っています。 以下の資料では、実際の支援事例や、スムーズな導入・運用に向けた弊社のアプローチをご紹介しています。自社へどう取り入れていくかを検討する際の参考として、ぜひご活用ください。

また、「まずは自社の現状や課題について直接相談してみたい」といった場合には、個別のご相談も承っております。こちらもお気軽にご活用ください。

デザインシステムに関するよくある質問

Q. デザインシステムとUIキットの違いは何ですか？

A. 本記事では、UIキットをボタンやフォームといった部品のセット、デザインシステムを部品とデザインの基本方針・使い方・更新の仕組みを結び付けたものとして整理しています。UIキットに含まれる説明の範囲は、提供元によって異なります。

Q. エンジニアとデザイナー、どちらが主導して作るべきですか？

A. デザイナーとエンジニアが初期段階から連携し、ユーザー体験、実装の実現性、保守・更新のしやすさを一緒に確認する進め方が有効です。必要に応じて、プロダクトの責任者や利用するチームも検討に加わります。

Q. 既存のプロダクトに後からデザインシステムを導入することは可能ですか？

A. 十分に可能です。その場合は、既存の画面を精査し、バラバラになっているUI要素を洗い出した上で、よく使われるコンポーネントから少しずつ共通化していく「スモールスタート」のアプローチが有効です。