3階層モデルとState Layerで「トークンの増殖」を止める

前回のおさらい

前回は、OKLCHを使って知覚的に均一なプリミティブカラー（素材）を作る方法を解説しました。

今回はいよいよその素材に「役割」を与えるフェーズ——セマンティックトークンの設計です。

ここが、カラーシステムの設計で最も多くの人が詰まる場所です。

---

なぜトークンは増殖するのか

セマンティックトークンの設計を始めると、多くの人が最初にこういう命名をします。

button/primary/bg、badge/success/bg、modal/header/bg…

直感的でわかりやすい。でも、コンポーネントが増えるたびにトークンも増え続け、最終的には誰も管理できない状態になります。

問題の本質は「コンポーネント名で色を管理しようとしている」ことです。コンポーネントは無限に増えますが、色の「役割」は有限です。ここを切り替えるのが、3階層モデルの核心です。

---

3階層モデルの構造

モダンなデザインシステムでは、トークン名を次の3階層で構成します。

カテゴリ / サブカテゴリ / モディファイア（例: surface / brand / normal）

第1階層：カテゴリ（どこに使うか）

要素が画面上の「どの場所」に使われるかを4つに分類します。

• Background — ページ全体やセクションの最も広い背景
• Surface — カード・ボタン・ダイアログなど、Backgroundの上に乗るUIパーツの塗り
• Border — 境界線・区切り線・枠線
• Content — テキストとアイコン（情報を伝えるもの）

第2階層：サブカテゴリ（どんな意味か）

その色が持つ「意味」を定義します。

• Neutral — UIの骨格となる中立的な基本色
• Brand — プロダクトのアイデンティティ・主要なCTA
• Positive / Warning / Negative / Informative — 成功・警告・エラー・情報
• Interaction — ホバーやアクティブなど、操作状態を表す透過レイヤー専用

第3階層：モディファイア（どんな状態・強さか）

状態（Normal / Hover / Disabled…）や強調度（Subtle / Strong…）を付与します。

この構造があれば、ボタンもバッジもカードも、同じ surface/brand/normal という1つのトークンでカバーできます。コンポーネントが100種類になっても、トークンの数はほとんど変わりません。

---

On-Color——見落としがちなアクセシビリティの要

3階層モデルで忘れてはいけないのが On-Color（反転色） の定義です。

ブランドカラーの青いボタンに白い文字を乗せるとき、その文字色は「ブランド背景の上専用の色」として別途定義する必要があります。これを content/brand/onBrand のように、背景色とセットで定義します。

On-Colorを省略して「とりあえず白」で済ませると、ダークモード対応や特殊な背景色への展開で必ず破綻します。面倒でも、背景色とセットで定義することがシステムを守ります。

---

State Layerで「ホバー色問題」を解決する

3階層モデルを理解したところで、もう一つの大きな問題に直面します。

ホバー色をどう管理するかです。

surface/brand/hover、surface/negative/hover…と色ごとにホバー専用トークンを作り始めると、またしてもトークンが増殖します。

モダンなデザインシステムが採用している解決策が State Layer（状態レイヤー） です。

考え方はシンプルです。「色ごとにホバー色を作るのではなく、共通の透過レイヤーを重ねる」。

具体的には、STEP 2で定義した透過色（Black 8%）を surface/interaction/hover として登録し、ボタンコンポーネントの内部に絶対配置で仕込んでおきます。

ベースが青（Brand）だろうと、赤（Negative）だろうと、白（Neutral）だろうと、ホバー時にはこの共通の透過レイヤーを重ねるだけ。たった1つのトークンで、すべての色のホバー表現が完成します。

---

テキストリンクのホバーはどうするのか

「文字や枠線のホバー色は？」と思った方もいるかもしれません。

シンプルなモダンシステムでは、テキストや枠線専用のホバー色トークンはあえて作りません。

アウトラインボタンやテキストボタンの場合、文字・枠線の色は変えずに、空の背景に surface/interaction/hover をそっと敷くだけで「押せる感」のフィードバックが成立します。テキストリンクであれば、ホバー時に下線を表示するという表現でも十分です。

「ホバーしたら必ず色を変えなければいけない」という固定観念を手放すことで、システムは驚くほどシンプルになります。

---

まとめ

• トークン増殖の原因は「コンポーネント名で色を管理しようとすること」
• カテゴリ / サブカテゴリ / モディファイアの3階層で命名することで、最小限のトークンで最大限のUIをカバーできる
• On-Colorは背景色とセットで定義する。省略するとシステムが破綻する
• State Layerを使えば、ホバー色はたった1つのトークンで全色に対応できる

---

3階層モデルに基づいた実際のトークン一覧（セマンティック・リファレンス）は、Figmaテンプレート内にまとめています。Variables登録作業やUIデザイン時の「カンペ」としてそのまま使えます。

👉 MODERN COLOR SYSTEM | Logical Variables Template for Figma

日英対応・CC BY 4.0で公開中です。

---

次回は「Figma Variablesに実装して、チームの共通言語を作る」——シリーズ最終回です。