デザインシステム入門：部品・利用ルール・変更手順をそろえる

同じ「保存」なのに、画面によって色、押せる条件、エラーの出方が違う。部品をコピーして直すたびに、どれが正しいか分からなくなる。デザインシステムは、こうした判断を共有し、使いながら更新するための仕組みです。

30秒で要点

• 色や余白だけでなく、部品の状態、使う場面、変更の責任まで共有します。
• 共通化する基準は見た目の似方より、利用者が同じ目的を同じ操作で達成できるかです。
• 実際の画面を一つ選び、よく使う部品から導入します。部品数や採用率だけで成果を判断しません。

スタイルガイドやUIキットとの違い

UIは画面の表示と操作、UXは目的を達成するまでの体験です。画面の色が統一されても、入力ミスから戻れなければ、使いやすさはそろいません。

表が収まらない場合は、横にスクロールできます

名称の境界は組織によって違います。見るべきなのは成果物の名前より、判断に必要な内容がつながっているかです。たとえばIBMのCarbonは、動くコード、デザイン資源、ガイド、パターンなどを含む仕組みとして公開されています。他社の体系をそのまま移すより、自社の利用者と運用に合う部分を選びます。

値、意味、部品、画面の使い方をつなぐ

デザイントークンは、色や余白などの設計判断に名前を付けて共有するものです。たとえば青の値をblue-700と呼び、それを「主要な操作の背景」という用途へ結び付けます。用途に名前があると、画面ごとに「青を直接指定する」変更を減らせます。

その値を使うボタンがコンポーネント、ボタンと入力欄を組み合わせた検索や申請の流れがパターンです。パターンには、表示だけでなく、入力中、送信中、失敗、完了時の扱いも含めます。

設計原則も、判断に使える言葉にします。「分かりやすくする」だけでなく、「失敗した入力は消さず、直す場所と理由を示す」なら、フォームの仕様を選ぶ基準になります。トークンや部品は、その原則を繰り返し実現するために使います。

トークンを複数の道具で共有する方法として、Design Tokens Format Module 2025.10があります。これはDesign Tokens Community Groupの仕様で、W3C勧告ではありません。対応する道具の形式を確かめて採用します。以下のCSS変数の例は、Web上で考え方を試すための小さな実装です。

ボタン一つでも、状態と意味をそろえる

次は、通常・ホバー・キーボードフォーカス・無効状態を持つボタンの例です。CSSの三つの段階は、基礎の値、用途、部品への割り当てです。既存のサイト全体の設定を置き換えず、独立した検証ページで確かめます。

:root {
  --sample-blue-700: #1d4ed8;
  --sample-blue-800: #1e40af;
  --sample-white: #ffffff;
  --sample-ink: #0f172a;
  --sample-muted-text: #475569;
  --sample-muted-surface: #e2e8f0;

  --sample-action-bg: var(--sample-blue-700);
  --sample-action-hover: var(--sample-blue-800);
  --sample-action-text: var(--sample-white);
}

.sample-button {
  background: var(--sample-action-bg);
  color: var(--sample-action-text);
  border: 1px solid transparent;
  border-radius: 0.375rem;
  padding: 0.75rem 1rem;
  min-block-size: 2.75rem;
  font: inherit;
  line-height: 1.5;
  cursor: pointer;
}

.sample-button:hover:not(:disabled) {
  background: var(--sample-action-hover);
}

.sample-button:focus-visible {
  outline: 3px solid var(--sample-ink);
  outline-offset: 3px;
}

.sample-button:disabled {
  background: var(--sample-muted-surface);
  color: var(--sample-muted-text);
  cursor: not-allowed;
}

同じページに次のHTMLを置きます。これは見た目と状態を確かめる例で、条件を適用する業務処理は含めていません。

<button class="sample-button" type="button">条件を適用</button>
<p id="condition-note">地域を選ぶと、この操作を利用できます。</p>
<button class="sample-button" type="button" disabled aria-describedby="condition-note">
  地域の条件を適用
</button>

type="button"は、フォーム内でも意図せず送信しないための指定です。送信する部品にはtype="submit"を使います。HTMLのbutton要素の動作に合わせて、リンクによる移動とボタンによる操作も分けます。

無効状態は色だけで表さず、実際のdisabled属性と理由の説明をそろえています。無効なボタンは通常のTab移動の対象から外れるため、説明をボタンの中やホバー表示だけに閉じ込めません。aria-disabledだけを使う別の設計では、属性を付けるだけで操作が止まるわけではなく、振る舞いも実装する必要があります。

色をそろえた後にも確認が残る

WCAGの文字コントラスト基準は、通常の文字に4.5:1以上、大きな文字に3:1以上を求め、無効な部品などには適用除外があります。トークン名が「primary」であることは、白文字を重ねられる根拠にはなりません。実際の前景色と背景色の組み合わせで計算します。

また、フォーカスは今操作できる場所を示す表示です。周囲の背景に埋もれたり、枠から切れたりしないかを確かめます。W3Cのボタンパターンでは、Enter・Spaceによる操作や名前・状態を扱っています。キーボード、拡大表示、支援技術で、実際の利用場面を確認します。

処理中なら重複実行をどう防ぎ、完了や失敗をどう伝えるかも必要です。たとえばボタンだけを無効にしても、要求が二度届く可能性への対策にはなりません。部品の表示とサーバーの処理には、それぞれ責任があります。

最初の導入範囲は、実際の一つの画面で決める

最初から全画面を書き換えると、作る量が増え、どの改善が役立ったかも見えにくくなります。申請フォームや一覧の検索など、繰り返し使う一つの画面を選びます。

1. 今の使われ方を集める。 同じ役割のボタン、入力、エラーを並べます。見た目の違いだけでなく、文言と操作の違いも記録します。
2. 利用者の困りごとを一つ選ぶ。 「入力を直す場所が分からない」など、確かめられる問題に絞ります。
3. 必要な部品と使い方を作る。 正常時だけでなく、空欄、エラー、処理中、長い日本語などを用意します。
4. 画面へ組み込み、使って確かめる。 部品単体では見えない並び順、説明、画面幅、操作後の移動も確認します。
5. 採用範囲と担当を記録する。 確認した環境と残る条件を残して、次の画面へ広げます。

GOV.UKの追加基準は、必要性と既存要素との差を確認し、公開前に利用者や複数の環境で確かめる考え方を示しています。自社でも「部品を増やしたい」から始めず、利用上の問題と既存部品では足りない理由を先に置きます。

共通部分を変えるときの手順を用意する

同じ部品を多くの画面で使うほど、一つの変更が広く影響します。コード上の引数を変えなくても、ボタンの幅や文章の折り返しが変われば画面が崩れることがあります。「互換性がある」は型だけで判断できません。

表が収まらない場合は、横にスクロールできます

部品ごとの説明には、使う場面、使わない場面、状態、アクセシビリティ上の条件、コード例、変更履歴、問い合わせ先を残します。FigmaやStorybookなどを使う場合も、道具の導入だけでこの内容が自動的にそろうわけではありません。

更新時は、利用者からの報告を受け取る担当、採用を判断する担当、配布と移行を進める担当を明確にします。一人が兼ねる場合でも、何を確認してから共通部分へ入れるかを決めておくと、場当たり的な例外が増えにくくなります。

部品の数より、利用上の問題が減ったかを見る

採用率を出すなら「共通部品を使った箇所数／対象範囲でその部品を使える箇所数」と定義し、対象外の画面を分母に混ぜないようにします。ただし、この数字は利用の広がりを示すもので、使いやすさそのものではありません。

同じ種類の画面で、実装からレビュー完了までの時間、手戻りの理由、操作テストで目的を達成できた件数を確認します。導入前後で画面の難しさや担当者が違うなら、その条件も記録します。効率が上がったように見えても、利用者の問題が残るなら使い方を見直します。

次に一つのボタンを選び、「使う場面」「押せないときの理由」「変更したら影響を受ける画面」を書いてみてください。この三つを共有できると、見た目の統一から、維持できる仕組みへ進めます。画面幅の違いへの対応は、レスポンシブデザインの設計につなげて確認できます。