公開2023.09.15更新2026.10.11 Webサイト

デザインシステムとは？構成要素と作り方、ガイドライン・スタイルガイドとの違い

デザインシステムとは、デザインの原則、色や余白の値を変数にしたデザイントークン、ボタンなどのUIコンポーネント、その使い方のドキュメント、そしてそれらを更新し続ける運用体制をひとまとめにした、製品づくりの共通基盤です。配色や書体のルール集であるデザインガイドラインより範囲が広く、デザインツールとコードが同じ部品を参照する状態までを含みます。この記事では、定義の出自、似た用語との違い、構成要素、W3Cのコミュニティグループが2025年10月に安定版を出したトークン形式、作り方の5ステップ、導入を見送るべき条件までを整理します。

まとめ：デザインシステムの要点

定義：原則・トークン・コンポーネント・ドキュメントに、それを運用する組織までを含めた製品づくりの基盤。部品集（UIキット）だけを指す言葉ではない。
ガイドラインとの違い：ガイドラインは見た目のルールを書いた文書で、デザインシステムの一部。デザインシステムはそのルールを、実装と連動する部品と運用手順まで落とし込んだもの。
トークンの標準形式：Design Tokens Community Group（DTCG）が2025年10月28日に Format Module 2025.10 を公開。色の値は16進文字列でなく colorSpace と components を持つオブジェクトで書く。
作り方：現状の棚卸し→原則→トークン→頻出コンポーネント→ドキュメントと運用ルール、の順で小さく始める。
見送る条件：画面数が少なく、更新担当を置けないうちはフルセットを作らない。更新されない部品集を正しい仕様として使い続けると、実装と文書の不一致が広がる。

デザインシステムの定義と3つの層

部品集・製品群・組織の3層

デザインシステムに標準の定義はありませんが、定義の出発点としてよく参照されるのが、EightShapesのNathan Curtisが2017年10月に公開した「Defining Design Systems」です。Curtisは、デザインシステムという言葉は1つではなく、相互に関わる3つのシステムを指すと書いています。再利用できる部品のキット（a kit of reusable, interconnected parts）、まとまりのある製品群（a set of cohesive, interconnected products）、協働する人々のコミュニティ（a community of collaborative, interconnected people）の3つです。

この定義から読み取るべきなのは、デザインシステムの対象が部品だけではないことです。ボタンやフォームの部品集はその一部にすぎず、部品を使って作られる複数の製品と、部品を更新・承認する人の体制までがそろって初めて機能します。国内の解説では「デザイン言語」「ツールボックス」「組織」の3つの柱として説明されることもあります。部品と組織を含む点は共通ですが、Curtisの整理では、部品を使って作られる「製品群」も独立した対象になっています。

製品数・チーム数から考える導入時期

デザインシステムの価値は、同じ部品を参照する画面・製品・人が多いほど大きくなります。Web・iOS・Androidで同じサービスを出している、複数チームが並行して画面を作っている、外部の制作会社と社内で実装を分けている、といった状況では、部品を共有しない限りボタンの色や余白が画面ごとに少しずつずれていきます。逆に、1チームが1つのWebサイトを作っているだけなら、後述するガイドラインと数個の共通部品で足りることが多いです。

ガイドライン・スタイルガイド・パターンライブラリとの違い

ガイドライン、スタイルガイド、パターンライブラリ、UIキットは、単独でも使われます。下の表は、これらをデザインシステムに組み込む場合に、それぞれが何を対象にし、実装とどこまでつながるかを整理したものです。呼称や連動の範囲は提供元によって異なります。

用語	主な中身	実装との連動	デザインシステムとの関係
デザインガイドライン	原則・使い方・禁止例	なし（文書）	ドキュメント部分
スタイルガイド	色・書体・ロゴ・余白の規定	なし〜値の共有	トークンの元になる部分
パターンライブラリ	UIの型とコード部品	あり	コンポーネント部分
UIキット	デザインツール上の部品	なし	デザイン側の部品
デザインシステム	上記すべて＋運用体制	あり（同期を前提）	全体

実務で問題になるのは、ガイドラインやUIキットだけを作って「デザインシステムを導入した」と扱うケースです。PDFやFigma上の部品は、コード側に自動では反映されません。改訂内容をコードへ反映する手順がなければ、ドキュメントと実際の画面に差が生じます。本記事では、デザインとコードの食い違いを減らす実装方針として、トークンとコンポーネントの値を共有する構成を勧めます。

デザインガイドラインに載せる項目と作り方

デザインガイドライン単体を作る場合、載せる項目は「判断の拠り所」と「再現に必要な値」に分かれます。前者はデザイン原則、トーン＆マナー、文言の書き方、アクセシビリティ方針です。後者はロゴの最小サイズと余白、カラーパレット、書体とサイズの段階、余白の単位、グリッド、アイコンの線幅です。作るときは、新しく決めるより先に現行の画面から実際に使われている値を拾い出し、似た値を統合するところから始めると、現場の実装と食い違いません。ロゴや企業カラーなどブランド側の規定はビジュアルアイデンティティ（VI）とは？意味と構成要素・公開ガイドライン4本で見る作り方、企業全体の視覚規定をマニュアルにまとめる手順はCIデザインとは？コーポレートアイデンティティの3要素とVIマニュアルの作り方で扱っています。

デザインシステムの構成要素

デザイン原則の役割と書き方

デザイン原則は、個々の判断で迷ったときに立ち返る短い言葉です。たとえば「装飾より情報の明快さを優先する」「アクセシビリティは後付けせず既定にする」のように、二つの選択肢のどちらを取るかが決まる書き方にします。「使いやすく」「美しく」のような、誰も反対しない言葉は判断に使えないので原則になりません。原則があいまいなままトークンや部品を増やすと、担当者ごとに解釈が分かれて部品の形がぶれていきます。

デザイントークンの役割とDTCG形式

デザイントークンは、色・余白・角丸・書体・影などの値に名前を付けた、デザインシステムの最小単位です。#0066ccを直接書く代わりにcolor.primaryを参照し、値を1か所変えれば全画面に反映されるようにします。トークンの持ち方は、W3CのコミュニティグループであるDesign Tokens Community Group（DTCG）が標準化しており、2025年10月28日にDesign Tokens Format Module 2025.10を、色の形式を定めるColor Module、ライトモードとダークモードのような文脈の切り替えを定めるResolver Moduleとともに公開しました。位置づけはFinal Community Group Reportで、仕様自体に「W3C標準ではなく、標準化トラックにも載っていない」と明記されています。

2025.10の形式で押さえるべき点は3つあります。まず、トークンは$valueを持つオブジェクトです。次に、$typeはトークンごとに書かなくてもよく、親グループの$typeを継承します。継承元も無く型が決まらないトークンは無効として扱われます。最後に、色の$valueは"#0066cc"のような文字列ではなく、colorSpaceとcomponentsを必須とするオブジェクトで、16進表記は任意のhexに入れます。草案段階の解説記事には文字列で書く例が今も多いので、ツールに読ませる前に確認してください。推奨される拡張子は.tokensまたは.tokens.jsonです。

{
  "color": {
    "$type": "color",
    "primary": {
      "$value": { "colorSpace": "srgb", "components": [0, 0.4, 0.8], "hex": "#0066cc" }
    },
    "danger": {
      "$value": { "colorSpace": "srgb", "components": [0.851, 0.188, 0.145], "hex": "#d93025" }
    }
  },
  "space": {
    "$type": "dimension",
    "md": { "$value": { "value": 16, "unit": "px" } }
  }
}

この例では$typeをグループ側に1回だけ書き、配下のトークンに継承させています。余白などの寸法もvalueとunitに分けたオブジェクトで書きます。色のトークンを決める段階で、文字色と背景色の組み合わせがWCAGのコントラスト比を満たすかも確かめておくと、部品を作った後の手戻りが減ります。比の基準と検証方法はWebアクセシビリティのコントラスト比：4.5対1と3対1の適用範囲・CSS実装・自動検証の落とし穴にまとめています。

UIコンポーネントと操作パターンの役割分担

UIコンポーネントは、ボタン・入力欄・カード・ダイアログなどの再利用できる部品です。各部品はトークンを参照し、通常・ホバー・フォーカス・無効・エラーといった状態まで定義します。部品を粒度で分ける考え方にはアトミックデザインとは？5階層の分類基準とReactコンポーネント設計・3階層縮退が使えます。パターンは部品より一段上の「操作の型」で、検索結果の絞り込み、入力エラーの出し方、空の状態の見せ方などを揃えます。部品がそろっていても、エラー表示の位置が画面ごとに違えば利用者は迷います。

ドキュメントの記載事項と更新の責任分担

ドキュメントには、部品ごとの使いどころ、使ってはいけない例、状態のバリエーション、アクセシビリティ上の注意を書きます。コンポーネントをブラウザ上のカタログとして見せるにはStorybookが広く使われており、2026年10月11日時点の最新安定版は、2026年9月29日公開の10.6.1です。ここに、変更を提案・承認する担当者、リリースの周期、廃止の手順という運用体制を加えたものが、Curtisの言う「組織」の層にあたります。更新・承認の担当が決まっていないと、ドキュメントや部品の修正が止まり、実装との食い違いが残ります。

導入するメリットと、見送るべき条件

デザインシステムの効果は、一貫性と速度に集約されます。全画面が同じ部品を使うので、利用者はボタンやエラー表示の意味を画面ごとに学び直さずに済みます。開発側では、新しい画面を既存の部品の組み合わせで作れるため、デザインレビューで余白や色を指摘し合う時間が減ります。ブランドカラーの変更のように全画面に及ぶ修正も、トークンの値を1か所直してビルドし直せば反映できます。

一方で、次の条件に当てはまるうちは、フルセットのデザインシステムを作るべきではありません。

製品が1つ・担当が1チームで、画面数も少ない
デザインシステムの更新に工数を割ける担当者がいない
製品の方向性がまだ固まっておらず、画面の構成が月単位で作り直されている

この段階でコンポーネントを数十個作っても、製品の変化に部品の更新が追いつかず、誰も使わないFigmaファイルが残ります。代わりに、トークンとボタン・入力欄など数個の共通部品だけを決め、2つ目の製品や2つ目のチームが出てきた時点で範囲を広げるほうが、作り直しの費用を抑えられます。

デザインシステムの作り方5ステップ

全部を一度に作ろうとすると、完成前に製品のほうが先へ進みます。使われる頻度の高いものから作り、運用しながら育てます。

1. 現行画面の棚卸しと重複部品の把握

主要な画面をすべてスクリーンショットに並べ、ボタン・見出し・入力欄・色・余白の種類を数えます。たとえば同じ役割のボタンが5種類、グレーが12色見つかれば、どこから統一するかの優先順位と、関係者を説得する材料が同時に手に入ります。

2. デザイン原則の言語化と判断例の明示

棚卸しで見えたばらつきのうち、どちらに寄せるかを決める基準を原則として書きます。本記事では、原則を3〜5個に絞るところから始めることを勧めます。Spindleの「Amebaらしさ3原則」などを参考に、それぞれに「だからこの場面ではこうする」という判断例を添えます。

3. デザイントークンの命名とFigma Variablesへの登録

棚卸しで拾った値を統合し、名前を付けます。名前はblue-500のような見た目の名前（基本トークン）と、color.text.linkのような用途の名前（意味トークン）の2段に分けると、ダークモードやブランド変更で用途側の参照先だけを差し替えられます。FigmaではVariablesに登録し、部品の色や余白をVariablesに結びつけます。Figmaは2025年11月からVariablesの画面でDTCG形式のJSONをモード単位でインポート・エクスポートできるようになり、トークンファイルとVariablesの受け渡しにプラグインが必須ではなくなりました。モード機能を使えるのはEducation・Professional・Organization・Enterpriseの各プランです。なお、Figmaの変数をAPIで読み書きするVariables APIはEnterpriseプランが条件で、詳細はFigma APIの使い方｜レート制限・トークン・Variables APIのEnterprise条件で扱っています。

4. 頻出コンポーネントの実装とStorybookでの文書化

登場回数の多いボタン・入力欄・見出し・リンクから作ります。デザイン側の部品とコード側の部品を同じ名前・同じプロパティにそろえ、Storybookでカタログ化します。見た目の意図しない変化を検知するには、Storybookの各ストーリーを画像で比較するビジュアルリグレッションテストを組み合わせます。その代表的なサービスはChromaticとは？Storybook連携のビジュアルテスト自動化と料金・TurboSnapを解説で紹介しています。

5. トークンからのCSS生成と更新ルールの策定

FigmaからエクスポートしたDTCG形式のJSONをGitで管理し、変換ツールのStyle DictionaryでCSSカスタムプロパティなどを生成します。2025.10形式の色オブジェクトには5.3.0、寸法のオブジェクトには5.4.0で対応したため、それより古い版では前述のトークンを読めません。最新の5.6.1（2026年10月10日公開）はNode.js 22以上が必要です。npm install --save-dev [email protected]で導入し、前述のトークンをtokens/base.tokens.json、次のスクリプトをbuild.mjsとして保存してnode build.mjsを実行すると、下のCSSが生成されることを確認しました（出力先頭の自動生成コメントは省略）。

import StyleDictionary from 'style-dictionary';

const sd = new StyleDictionary({
  source: ['tokens/**/*.tokens.json'],
  platforms: {
    css: {
      transformGroup: 'css',
      buildPath: 'build/',
      files: [{ destination: 'variables.css', format: 'css/variables' }]
    }
  }
});
await sd.buildAllPlatforms();

:root {
  --color-primary: #0066cc;
  --color-danger: #d93025;
  --space-md: 16px;
}

トークンの変更をプルリクエストでレビューする運用にし、マージ後のCIでこのビルドを実行します。生成したCSSを製品へ反映するには、成果物の配布と製品側の更新処理も設定します。同じ段階で、誰が変更を承認し、どの周期でリリースするかを決めます。

形骸化させない運用ガバナンス

デザインシステムは、技術面を整えても、更新の担当と手順がなければ維持できません。担当が決まっていないと、立ち上げ時にどれだけ整備しても製品のほうが先に進み、部品は古いまま取り残されます。避けるには、最初に次の3点を決めます。

オーナー：変更の提案を受け付け、採否を決める担当者またはチーム
昇格の基準：個別画面の部品を共通部品にする条件（例：2つ以上の製品で使われたら共通化を検討する）
差分の点検：コード変更前後の表示差分をビジュアルリグレッションテストで検知し、デザインファイルとの一致は別途レビューする仕組み

何でも共通化すると、製品ごとの事情に合わない部品を無理に使わせることになり、かえって現場が回避策を作り始めます。業務システムのように画面の性質が製品で大きく違う場合の線引きは業務システムの画面デザイン｜実装者向けUI設計パターンとライブラリ選定を参考にしてください。社内でUI設計とデザインシステムの整備を進める余力が無い場合は、UI/UXデザインの支援のように外部の手を借りて、トークンと主要部品の初期整備だけを委ねる方法もあります。

公開されているデザインシステムの事例

公開されているデザインシステムは、自社で作る範囲と粒度を決める教材になります。丸ごと真似るものではなく、どの単位で部品化し、ドキュメントに何を書いているかを見ます。

名称	提供元	見るべき点
デジタル庁デザインシステム	デジタル庁	行政向けのアクセシビリティ基準
SmartHR Design System	SmartHR	ライティング・多言語化の指針
Spindle	サイバーエージェント（Ameba）	「Amebaらしさ」を原則に書く方法
Material Design 3	Google	トークンとテーマの体系
Primer	GitHub	製品UIとブランドUIの分離
Carbon	IBM	White・Gray系の4テーマ