LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

デザインシステム構築とは何か — UIの一貫性を保つ共通言語

デザインシステムとは、プロダクト全体で一貫したユーザーインターフェース（UI）を保つために、デザイン原則・デザイントークン・UIコンポーネント・利用ガイドラインを体系的にまとめたものを指します。単なる配色ルールやロゴ規定ではなく、デザイナーとエンジニアが同じ基準で画面を作れるようにする共通言語です。

W3C（World Wide Web Consortium、Webの技術標準を策定する国際団体）のDesign Tokens Community Group（デザイントークンの標準化を進める公開コミュニティ）は、その目的を「プロダクトやデザインツールがデザインシステムのスタイル要素を大規模に共有するための標準を提供すること」と説明しています^*1。デザインシステムが単一のツールや会社の内製物ではなく、業界横断で標準化が進められている概念であることが分かります。

日本国内では、デジタル庁が行政サービス向けに「デジタル庁デザインシステム」を公開しています。同庁はスタイル・コンポーネント・ガイドライン・デザインデータ・素材集を体系化し、官民を問わず参照できる形で提供しています^*2。公的機関が一貫したUIの基盤を公開・運用している事例として参考になります。

画面ごとにUIがばらつく3つの原因

デザインシステムが整備されていないプロダクトでは、画面ごとにボタンの色や余白、文字サイズが微妙に異なる状態が発生しやすくなります。この状態が生まれる背景には、主に3つの原因があります。

原因1：画面単位でデザインを作成し基準を共有していない

複数のデザイナーやエンジニアが並行して画面を作る場合、各自が個別にボタンの色や角丸の数値を決めてしまうと、プロダクト全体で見たときに統一感が失われます。デザインカンプ（画面の設計図）を都度ゼロから作る体制では、この乖離が蓄積しやすくなります。

原因2：デザインと実装が別々のファイルで管理されている

Figmaなどのデザインツールとフロントエンドのコードベースがつながっていないと、デザイン変更がコードに反映されなかったり、逆にコード側で調整した値がデザインファイルに反映されなかったりする状態が生まれます。どちらが正しい状態かを示す基準がないため、修正のたびに認識をすり合わせる工数が発生します。

この状態を放置すると、画面追加のたびにゼロから配色や余白を決め直すことになり、開発期間の後半でUI調整の手戻りが増える傾向があります。デザインとコードのどちらを正とするかという「Single Source of Truth（正となる情報源を一本化する考え方）」を導入していないプロダクトほど、この傾向が強く出ます。

原因3：命名やルールがドキュメント化されていない

色や余白の値を各デザイナー・エンジニアが感覚で決めている場合、新しく参加したメンバーは既存の基準を推測するしかありません。結果として、既存の値に近いが微妙に異なる新しい値が追加され続け、バリエーションが増加します。

デザインシステムを構成する4つの要素

デザインシステムは単一の成果物ではなく、複数の要素の組み合わせで構成されます。外注を検討する際は、どの要素をどこまで委託するかを事前に切り分けておくことが重要です。

デザイントークン — 色・タイポグラフィ・余白を変数化する

デザイントークンとは、色・タイポグラフィ（文字の書体やサイズの設計）・余白などのデザイン上の決定事項を、名前の付いた変数として管理する仕組みです。W3C Design Tokens Community Groupは、デザイントークンをデザインシステムの基礎となるスタイル要素と位置づけ、2025年10月に最初の安定版仕様（バージョン2025.10）を公開しました^*1。この仕様には、ライトモード・ダークモードやブランドバリエーションを扱うテーマ機能、Display P3・OKLCHといった色空間への対応が含まれています^*1。

この標準化には、Adobe・Google・Figma・Sketchなど主要なデザイン・開発ツール事業者が参加しています^*1。特定企業の独自仕様ではなく、業界横断で共通フォーマットを作る動きが進んでいることが分かります。トークンを整備すると、色の変更を1箇所で行うだけで、その値を参照するすべての画面・コンポーネントに反映できるようになります。

UIコンポーネントライブラリ — 再利用可能な部品の集合

UIコンポーネントライブラリは、ボタン・フォーム入力・カード・ナビゲーションなど、繰り返し使う画面部品をあらかじめ設計・実装しておいたものです。デジタル庁デザインシステムでも、リンクテキストやテキスト入力・テキストエリアといった再利用可能なコンポーネントが主要な構成要素として明示されています^*2。

コンポーネントを都度作成するのではなく、ライブラリから呼び出す体制にすることで、新規画面の実装スピードと見た目の一貫性を両立できます。ただし、すべての画面パターンを最初から網羅する必要はありません。使用頻度の高い部品から着手し、段階的に拡充する進め方が実務では現実的です。

利用ガイドライン — いつ・どう使うかを言語化する

ガイドラインは、各コンポーネントやトークンを「どのような場面で」「どう使うべきか」を言語化したドキュメントです。デジタル庁デザインシステムでも、各要素の使用方法に関する指針としてガイドラインが独立した構成要素に位置づけられています^*2。

ガイドラインがないと、コンポーネントが存在していても使い方が担当者ごとに異なってしまい、結局は画面ごとの独自判断に戻ってしまいます。「主要なアクションには塗りボタン、補助的なアクションには枠線ボタンを使う」のような使用条件を明文化することが、一貫性の維持に直結します。

FigmaとコードのSingle Source of Truth — デザインと実装をつなぐ

デザインシステムを機能させるには、デザインファイル（Figma等）とフロントエンドのコードのどちらか一方を正として同期させる仕組みが必要です。UIコンポーネント開発環境であるStorybook（各コンポーネントの見た目や状態をブラウザ上で個別に確認・管理できるオープンソースツール）の公式ドキュメントでは、コンポーネントの描画状態を「ストーリー」として記録し、コードを編集するとブラウザ上に即座に反映される仕組みが説明されています^*3。

Storybookはコンポーネント駆動のUI開発（Component driven UI、小さな部品単位で開発を進める考え方）を推進するツールと位置づけられており^*3、実装済みのコンポーネントをデザイナー・エンジニア双方が確認できる状態を作れます。デザインファイルの見た目と実装コードの挙動を突き合わせる基盤として、Storybookのようなツールを併用する構成が実務で採用されています。

棚卸しから運用まで — 構築を進める5ステップ

デザインシステムの構築は、最初から全画面・全パターンを網羅しようとすると工数が膨らみ、途中で頓挫しやすくなります。小さく始めて段階的に拡張する進め方が現実的です。

ステップ1：既存画面の棚卸しと重複要素の洗い出し

まず既存のプロダクト画面をすべて確認し、使われている色・フォントサイズ・ボタンの種類を一覧化します。この段階で、意図せず増えてしまった類似色や似たようなボタンスタイルの重複が可視化されます。棚卸しを省略していきなりトークンを定義すると、実態に合わない基準ができあがるリスクがあります。

ステップ2：デザイントークンの定義

棚卸しの結果をもとに、色・余白・タイポグラフィなどの値を整理し、名前付きのトークンとして定義します。命名規則（例：主要な操作色を示す変数名を統一する等）をこの段階で決めておくと、後続のコンポーネント設計がスムーズになります。

ステップ3：コアコンポーネントの整備

ボタン・入力フォーム・カードなど、使用頻度の高いコンポーネントから着手します。すべてのUIパターンを一度に用意するのではなく、実際の画面で頻出する部品を優先することで、初期投資を抑えながら効果を出しやすくなります。

ステップ4：ドキュメント化

整備したトークンとコンポーネントの使い方をドキュメントにまとめます。Storybookのようなツールを使えば、コンポーネントの見た目とコードをセットで管理でき、デザイナー・エンジニア双方が同じ基準を参照できる状態を作れます^*3。

ステップ5：運用ルールの策定と定着

デザインシステムは一度作って終わりではなく、プロダクトの成長に合わせて更新が発生します。誰がトークンやコンポーネントの追加・変更を承認するか、変更をどう周知するかという運用ルールを決めておかないと、せっかく整備した基準が再び形骸化します。デジタル庁デザインシステムも公開後に継続的な拡充・更新が行われており^*2、構築後の運用体制が重要であることがうかがえます。

外注する場合の委託範囲と発注準備

デザインシステムの構築を外部パートナーに委託する場合、委託範囲を事前に明確にしておくことが、期待とのズレを防ぐうえで重要です。

委託範囲を決める前に必要なスキル・工数を把握する

デザインシステムの構築を内製で行うには、デザイントークンの設計知識・UIコンポーネントの実装スキル・既存画面の棚卸しを担当する人員が必要です。加えて、FigmaとコードをつなぐStorybookなどのツール運用の知見も求められます。これらを社内で完結させるには、デザイナーとフロントエンドエンジニアが連携して棚卸しから運用ルール策定まで並走する体制が必要になり、他の開発タスクと並行して進める場合は着手から定着までに相応の期間を要します。

棚卸しを不十分なまま進めると、実態と合わないトークン設計になり、後工程でコンポーネントを作り直す事態が生じます。作り直しが発生すると、当初の構築期間に加えて再設計の工数が上乗せされるため、着手前の棚卸しに十分な時間を確保することが結果的に総コストを抑えます。

委託範囲のパターン

外注の委託範囲は、大きく分けて「デザイントークンの設計のみ」「コアコンポーネントの実装まで」「ドキュメント化・運用ルール策定まで」の3段階があります。すべてを外部に一括委託する方法と、設計は外部、実装は内製というように分担する方法のいずれも選択できます。

どちらの体制でも、デザインファイルとコードのどちらを正として管理するかという合意を発注前に取り決めておく必要があります。この合意がないまま進めると、外注先が納品したコンポーネントと社内の実装方針が食い違い、追加の調整作業が発生します。

発注準備として確認すべき事項

発注前には、既存プロダクトの画面数・使用しているフロントエンドフレームワーク（React、Vueなど）・デザインツールの利用状況を整理しておくことが必要です。外注先にこれらの情報を正確に伝えられないと、見積もりの前提が曖昧になり、着手後に想定外の追加作業が発生しやすくなります。

また、納品後にトークン定義やコンポーネントのソースコードの所有権が発注者側に帰属するかどうかを契約書で確認してください。外注先固有のツール環境に依存した納品物になっていると、契約終了後の運用移管が難しくなります。

まとめ：デザインシステム構築を進める3つの判断軸

本稿では、デザインシステムの構成要素・構築の進め方・外注の委託範囲を整理しました。要点を3つにまとめると次の通りです。

第一に、デザインシステムはデザイントークン・コンポーネント・ガイドライン・Single Source of Truthという4つの要素の組み合わせであり、色やボタンの見た目を整えるだけでは完成しません。第二に、構築は棚卸しからトークン定義、コアコンポーネント整備、文書化、運用定着まで段階を踏んで進めることで、初期投資を抑えながら効果を積み上げられます。

第三に、外注を検討する場合は委託範囲の切り分けと、納品物の所有権・デザインとコードの同期方法を発注前に確認することが、費用対効果を左右する判断軸になります。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：W3C Design Tokens Community Group「Design Tokens Community Group」（2025年10月・安定版仕様2025.10公開時点）
2. *2　出典：デジタル庁「デジタル庁デザインシステム」（2024年5月版移行・本稿執筆時点での確認内容）
3. *3　出典：Storybook公式ドキュメント「What’s a story?」（本稿執筆時点での確認内容）

Tweet