今日の問い
同じボタンを直したら、全画面で同じように直りますか。
30秒でつかむ
コンポーネントは、役割と振る舞いを持つ再利用部品です。 デザイントークンは、色、余白、文字などの判断に、 名前を付けて共有する最小単位です。
部品、状態、トークンを結ぶと、 見た目の一貫性が実装上の契約になります。
30秒図解 · LESSON 23
階層図
部品、状態、値を分離して再利用する
トークンから状態、コンポーネント、画面へ一方向につなぎます。
- 01Token
- 02State
- 03Component
- 04Pattern
- 05Screen
CLUE · 見抜く手掛かり
変更理由を一箇所へ戻せるか
TRAP · ありがちな罠
似た部品を画面ごとに複製する
原則
まず、似ているだけの要素をまとめないようにします。 役割、内容の構造、操作、状態が同じなら、 同じコンポーネントの候補です。 見た目が似ていても責任が違えば分けます。
ボタンなら、ラベルとクリックだけでは足りません。 通常、hover、focus、pressed、disabled、loading、 error時の振る舞いまで部品の契約に含めます。 状態が定義されて初めて、再利用できます。
次に、値を部品へ直接書かず、トークンへ置きます。
たとえば color.action.primary、
space.component.inline、type.bodyです。
名前は値ではなく、判断の用途を表します。
Design Tokens Community Groupの仕様は、 トークンを名前、値、型などで表し、 ツール間で交換する形式を定めています。 2025.10版は安定版ですが、 W3C標準ではなくCommunity Group Reportです。 この位置付けも、採用判断では明記します。
トークンを増やしすぎると、選択が難しくなります。 最初は前の三回で実際に使った値だけを登録します。 例外が出たら、新しい意味なのか、 既存規則の誤用なのかを先に確認します。
デザイントークンの名前、値、型、グループ、参照を交換する安定仕様と、その標準上の位置付けを確認する。
良い例と惜しい例
ボタンを再利用する条件
トークンを選び、値ではなく用途名から使用場所を判断してください。
トークンを選び、値ではなく用途名から使用場所を判断してください。
視覚プレビューの対象外です。
Literal value
#2457A7Usage
主要操作の背景に使い、前景との比率を確認します。
AIへの指示例
目的: 予約変更フローで繰り返す部品とデザイントークンを実装する
制約: 値を各画面へ直書きしない。未定義の状態を省略しない。トークン名へ色名や画面名を埋め込まない
参照: visual-system.md、wireframes/、ui-states.md
受入条件: Button、Field、StatusMessageの責任と全状態を記し、使用する色、余白、文字をtokens.jsonから参照する
確認問題
セルフチェック
1. 青いボタンが二画面にあります。共通コンポーネントにする前に、何を確認しますか。
最終制作へ反映する
visual-system.mdとtokens.jsonの部品契約
これまでの視覚規則をtokens.jsonへ対応させ、主要コンポーネントの役割、構造、操作、状態、参照トークンをvisual-system.mdへ追記する。
Acceptance criteria
- 主要コンポーネントに通常、hover、focus、pressed、disabled、loading、errorの扱いがある
- 色、余白、文字の値が用途名のトークンで管理され、部品から参照されている
今日のまとめ
- コンポーネントは、見た目ではなく役割と状態でまとめる
- トークンは、値へ用途名を付けて判断を共有する
- 次は、状態変化へ適切な動きとフィードバックを加える