デザインシステムとは？制作担当者が変わっても最適なUI/UXを届ける仕組み
前の担当者がどう作っていたか、誰も分からなくて困った…
リニューアル直後はきれいだったのに、2年経ったらページごとのデザインが違ってる…
Webサイトを長く運用している情報システム部門やWeb担当の方から、こうした声をよく伺います。
原因は担当者のスキル不足ではありません。判断の基準が個人の頭の中にしかない状態＝属人化が、構造的な原因です。
この記事では、担当者が変わってもUI/UXが崩れない仕組みとしてのデザインシステムを、基本から運用方法まで解説します。
目次
デザインシステムとは？
デザインシステムとは、UIの「ルール」と「部品」をセットで管理する仕組みです。
単に見た目のガイドラインだけを指すものではありません。
考え方から実装コードまでが一本につながっていることが特徴で、誰が作業しても同じ品質になる状態をつくるためのものです。
共通認識・共通言語であり、コミュニケーション課題を解消し、一貫したサービスを届けることができるようになります。
デザインシステムの4つの構成要素
| 構成要素 | 中身 | 具体例 |
|---|---|---|
| デザイン原則 | 判断のよりどころとなる考え方 | 「ユーザーを迷わせない」「装飾より可読性を優先」 |
| デザイントークン | 色・文字・余白などを変数化したもの | color-primary、spacing-16、font-size-body |
| コンポーネント | 再利用するUI部品と、その状態の定義 | ボタン（primary／secondary／disabled）、フォーム、カード |
| コード | 実装された部品とコーディング規約 | React／SCSSの実装、命名規則、アクセシビリティ要件 |
上から下へ、抽象から具体へと段階的につながっているのがポイントです。
たとえば「可読性を優先する」という原則があり、それを実現する文字サイズと行間がトークンとして定義され、そのトークンを使った見出しコンポーネントがあり、それがコードとして実装されている——この連鎖があることで、担当者は「なぜこのルールなのか」を毎回考えずに済みます。
逆に、原則のないトークンは形骸化し、コードにつながらないコンポーネントは飾りになります。4つが揃っていて初めて仕組みとして機能します。
代表的なツール構成
実際の構築では、次のようなツールの組み合わせが一般的です。
| 役割 | 主なツール | できること |
|---|---|---|
| デザイン | Figma | Variables（変数）でトークンを定義し、Componentsで部品化。ライブラリとして全プロジェクトに配信できる |
| 実装カタログ | Storybook | 実装済みコンポーネントを状態ごとに一覧表示。「実装の正解」をブラウザで確認できる |
| ドキュメント | zeroheight、Notion など | デザイン原則や使い方ガイドを明文化する |
| バージョン管理 | Git（GitHub／Bitbucket） | 更新履歴を残し、変更をレビューしてから反映する |
最小構成で始めるなら、Figma＋Storybookの2つで十分です。
- Figmaが「デザインの正解」を持つ
- Storybookが「実装の正解」を持つ
- 両者のトークン名・コンポーネント名を一致させる
この3点を守るだけで、デザインと実装のズレという最も頻発する問題が構造的に起こりにくくなります。
LYZONも自社のデザインシステムをFigma上で公開しています（詳細はデザインシステムとは？LYZONが自社初のデザインシステムを公開をご覧ください）。
なぜ担当者が変わるとUIが崩れるのか
デザインシステムがない現場では、次の3つが同時に起こりがちです。
引き継ぎ資料との違いは明確です。資料は読んで理解するものなので、理解の精度が人に依存します。
デザインシステムは使って再現するものなので、部品を使えばルールが自動的に守られます。
デザインシステムを作ると何が解消されるか
「担当者が判断しなくても済む範囲」を増やすこと。これが引き継ぎに強い状態の中身です。
AI生成で構築のハードルを下げる
作るべきなのは分かるが、リソースがない
最も多い声です。ここでAIが有効に使えます。
コツは、AIに「作らせる」のではなく「たたき台を出させる」ことです。
- 既存UIの棚卸し……既存のHTML/CSSを読み込ませ、実際に使われている色・文字サイズ・余白・ボタンのパターンを抽出する。「同じ意味のボタンが十数種類に分かれていた」といった実態が短時間で可視化される
- 統合案の作成……「この7種類は3種類に集約できる」といった案を提示させ、人は採用可否を判断する
- ドキュメントの下書き……用途説明や使用可否の例など、文章化の負担を大きく下げられる
一方で、次の判断は人に残します。
- ブランドとして何を大切にするかの意思決定
- 事業上の優先順位に基づく取捨選択
- アクセシビリティ要件の最終確認（WCAG 2.2 AA準拠など）
AIは選択肢を並べるのは得意ですが、組織の意思を決めることはできません。ここを委ねると、もっともらしいが自社に合わない体系ができあがります。
ハーネスを構築しデザインシステムを遵守できる環境をつくる
作った後に守られなければ意味がありません。そこで重要になるのがハーネス設計です。
ハーネス（harness）とは、AIに作業させるための足場を指します。AIの性能そのものではなく、何を参照させ、どの順序で作業させ、どこで人が確認するかという周辺の作り込みです。そして同じ考え方が、人の運用にもそのまま使えます。
- ① ルールファイル……コーディング規約、命名規則、トークン定義を、AIが常に参照できる形（
CLAUDE.mdなどのルールファイル）で置く - ② スキル・テンプレート……「ページを追加する」「コンポーネントを追加する」といった定型作業の手順を再利用可能な形にまとめる
- ③ チェック工程……トークン以外の色が使われていないか、コンポーネント外のマークアップが増えていないかを検証する工程をフローに組み込む。この確認もAIに任せられる
この3点が揃うと、運用は次のように変わります。
- 新しい担当者がルールを暗記する必要がない（ルールはファイル側にある）
- 制作会社を変更しても、渡すのはルールファイルとテンプレート
- 逸脱がその場で検知される（数年後に発覚しない）
属人化していた品質担保の役割を、仕組み側に移す。 これが「担当者が変わっても崩れない」状態の実質です。
運用に定着させる4つのルール
作って終わりにしないために、次の4点は最初に決めておきます。
- オーナーを決める……更新責任者が不在のまま運用すると、早い段階で形骸化します。兼任でも明示的に置く
- 例外の出し方を決める……禁止するとシステム外で作られ二重管理になります。「誰に相談し、誰が承認するか」を決めておく
- 追加フローを決める……新しい部品が必要になったときの申請から反映までの流れを一本化する
- 更新サイクルを決める……四半期ごとなど、実態との差分を棚卸しするタイミングを固定する
「例外を認めない」ではなく「例外の出し方を決めておく」のが、現場で回るルール設計のコツです。
導入ステップ
一度に全部を揃える必要はありません。運用中のサイトなら次の順序が現実的です。
まずPhase 0とPhase 1です。トークンを整えるだけでも、色やフォントの無秩序な増加は止まります。網羅性を求めて着手が遅れるより、狭い範囲で運用に乗せることを優先してください。
よくある失敗パターン
- 完璧を目指して公開が遅れる……使われないまま古くなる
- デザイナーだけで作る……実装側が使えない部品ができる。開発と運用担当を必ず巻き込む
- AIの出力をそのまま採用する……自社の実態と合わない体系になる
- Figmaだけで終わる……コードにつながらないと現場では守られない
まとめ
担当者の交代でUI/UXが崩れるのは、個人の力量ではなく判断が仕組み側に残っていないという構造の問題です。
- デザインシステムは「デザイン原則・トークン・コンポーネント・コード」の4要素で構成する
- 最小構成はFigma（デザインの正解）＋Storybook（実装の正解）
- AI生成で棚卸しとたたき台づくりを短縮し、意思決定は人が担う
- ハーネス設計で、品質担保の役割を属人性から仕組みへ移す
引き継ぎのたびに説明し直す運用から、部品とルールを渡すだけで済む運用へ。その転換点にあるのがデザインシステムです。
LYZONでは、既存サイトの棚卸しから、AI活用を前提としたデザインシステムの構築・運用定着までをご支援しています。運用の引き継ぎやUIのばらつきにお悩みの際は、お問い合わせよりお気軽にご相談ください。
LYZONのクリエイティブ・UI/UX
デザインひとつでCVRが変わります
見た目だけでなく成果につながるUI/UX設計を提供。UI/UXデザインの詳細はこちらからどうぞ。
デザインシステムに関するよくある質問
Q1. 小規模なサイトでもデザインシステムは必要ですか？
ページ数より「担当者・制作会社が変わる可能性」が判断基準です。数十ページでも運用が続くなら、トークン定義だけでも効果があります。
Q2. 構築にはどれくらいの期間がかかりますか？
範囲によって変わりますが、Phase 0〜1（棚卸しとトークン定義）だけであれば短期間で着手できます。全体を一度に揃える必要はありません。
Q3. Figmaだけで運用してはいけませんか？
デザインの正解は決まりますが、実装側に反映される保証がありません。Storybook等で「実装の正解」を持つことで、デザインと実装のズレを防げます。
Q4. 既存の運用中サイトにも後から導入できますか？
できます。既存UIの棚卸しから始め、狭い範囲で運用に乗せる進め方が現実的です。
2017年にWebデザイナーとしてLYZONに入社。
現在はアートディレクターとしても活動中。
