Design Tokens 2025.10は、色、余白、文字サイズなどの設計判断を、デザインツールや実装環境の違いを越えて共有するための安定した土台です。
ただし、ファイル形式を採用しただけでは、デザインシステムは定着しません。
既存の画面やコードへ生かすには、トークンの役割、変更する人、検証方法、廃止手順までを一つの運用として設計する必要があります。
Design Tokens 2025.10で安定したもの
デザイントークンとは、人が読める名前と値を中心に、色や寸法などの設計判断を表すデータです。
Design Tokens Community Group（DTCG）は、2025年10月28日付の2025.10を安定版のTechnical Reportとして公開し、公式FAQでは最初の安定版と説明しています。
2025.10のTechnical ReportsはFormat、Color、Resolverの各モジュールで構成されていますが、W3C勧告やW3C標準化トラック上の文書ではありません。
「安定版」は実装の共通基盤として扱えるという意味であり、すべてのデザインツールや変換ライブラリが同じ時期に完全対応することを保証する表現ではありません。
Format Moduleは、設計判断をプラットフォームに依存しない形で表し、組織内の共通語彙とツール間の相互運用を支えることを目的に掲げています。
JSON形式の共通仕様ができたことで、独自フォーマットからの変換規則や受け渡し方法を検討しやすくなりました。
仕様とデザインシステムは同じではない
DTCG仕様が定めるのは、主にトークンを記述し、参照し、解決するための形式です。
どの名前を採用するか、誰が変更を承認するか、既存部品をいつ廃止するかという組織の判断までは決めません。
したがって、デザイントークンはデザインシステムのデータ層になり得ますが、コンポーネント、文章表現、利用者調査、実装ガイド、変更管理を含む仕組み全体の代わりにはなりません。
既存の設計全体を確認したい場合は、アクセシブルなデザインシステム実践ガイドも参考になります。
役割で分ける三層のトークン
実務では、値の再利用範囲を三層に分けると、変更の意図と影響を追いやすくなります。
これはDTCG仕様が必須とする階層ではなく、移行時の判断を整理するための設計例です。
| 層 | 役割 | 名前の例 | 変更時に確認すること |
|---|---|---|---|
| 基礎値 | 色や寸法そのものを保持する | palette.blue.600 |
同じ値を参照する意味トークンの範囲 |
| 意味 | 文章色や境界線などの用途を表す | color.text.link |
通常、ホバー、無効など各状態の整合 |
| 部品 | 特定コンポーネントの役割へ割り当てる | button.primary.background |
画面、テーマ、ブランド別の差分 |
基礎値だけを直接参照すると、「青を変えたい」という依頼が、リンク、情報表示、装飾のどこへ影響するのか分かりません。
意味の層を挟めば、色コードではなく「何のための色か」を基準に変更できます。
一方、部品ごとのトークンを無制限に増やすと、同じ意味の値が別名で増えます。
新しい名前を追加するときは、既存トークンで表せない理由と利用範囲を記録しておくと、重複を抑えられます。
導入前に決めたい四つの運用
正本と責任者を一つにする
デザインファイル、コード、表計算、ドキュメントがそれぞれ正しい状態では、更新のたびに差分が生まれます。
どのリポジトリやデータを正本とするかを決め、追加、変更、廃止を承認する責任者を明記します。
責任者は一人で全作業を抱える役ではなく、変更の理由と影響範囲を確認し、判断を記録する役です。
名前と説明に設計意図を残す
blue500のような見た目の名前は作りやすいものの、用途を示しません。
color.text.linkのような役割名と説明を組み合わせると、値が変わっても利用目的を保てます。
命名規則には、単数形と複数形、状態名、テーマ名、略語、廃止済みトークンの扱いまで含めます。
コンポーネントの受け入れ基準を持つ
色と余白がそろっていても、キーボード操作、読み上げ名、エラー状態が未定義なら、部品の品質はそろいません。
たとえば、WCAG 2.2の達成基準2.5.8はレベルAAとして、ポインター入力のターゲットを原則24×24 CSSピクセル以上にするか、例外条件に沿って十分な間隔を確保するよう求めています。
詳しい条件と例外は、W3Cのターゲットサイズ（最小）の解説で確認できます。
フォーカス表示も、単に色を一つ登録して終わりではありません。
レベルAAAの達成基準2.4.13は、フォーカスの外観について大きさとコントラストの具体的な基準を示しており、より見つけやすい表示を設計する際の参考になります。
適合レベルを混同せず、採用する基準と確認方法をコンポーネントごとに記録します。
変更と廃止をリリースとして扱う
トークン名の変更は、デザインだけでなくCSS、アプリ、ドキュメント、テストへ波及します。
破壊的変更を突然反映せず、旧名の非推奨化、移行先、期限、影響する部品をリリースノートへ残します。
GOV.UK Design Systemのコントリビューション基準は、部品を公開する前に、利用者調査、障害のある利用者を含む検証、一貫性、複数のブラウザーや支援技術への対応を確認しています。
同じ審査制度をそのまま移す必要はありませんが、提案、検証、承認、公開の各段階を分ける考え方は、小規模なチームにも応用できます。
既存環境からの移行手順
- 対象を一つに絞る：ボタンや入力欄など、利用頻度が高く状態の多い部品を試行対象にします。
- 現在値を棚卸しする：デザインとコードから色、寸法、状態、例外を集め、同じ意味の値と偶然同じ値を分けます。
- 役割名へ対応づける：基礎値、意味、部品のどの層で管理するかを決め、説明と所有者を付けます。
- 変換経路を作る：正本から各ツールやコードへ出力し、手修正が必要な箇所を記録します。
- 差分を検証する：通常状態だけでなく、ホバー、フォーカス、無効、エラー、拡大表示、狭い画面を確認します。
- 採用範囲を測る：移行済み部品、独自値、非推奨トークンの残数を追い、次の対象を決めます。
最初から全製品を置き換えると、命名や変換規則の誤りが広範囲へ伝わります。
一つの部品で設計、出力、検証、廃止までを通し、運用上の詰まりを直してから範囲を広げる方が安全です。
導入判断のチェックリスト
- 共通化によって減らしたい手戻りを説明できるか。
- 正本、責任者、承認者が決まっているか。
- 名前が値ではなく役割を表しているか。
- デザインとコードの変換方法を再現できるか。
- フォーカス、エラー、無効、拡大時の状態を検証できるか。
- 破壊的変更と非推奨化の手順があるか。
- 試行対象と移行完了の判定方法が決まっているか。
よくある質問
デザイントークンを導入すればデザインシステムになりますか
なりません。
デザイントークンは設計判断を共有するデータですが、利用者調査、コンポーネントの振る舞い、文章、実装ガイド、変更管理は別に必要です。
独自形式からすぐに全面移行すべきですか
一斉移行を前提にする必要はありません。
利用中のツールが2025.10の必要な機能へ対応しているかを確認し、変換アダプターと一つの部品で往復テストをしてから範囲を広げます。
小規模なサイトにも必要ですか
部品数が少なければ、大規模な基盤は不要です。
ブランド色、文章色、余白、フォーカス表示など、変更時の影響が大きい値だけを役割名で管理すると、更新の意図を保ちやすくなります。
参考資料
- Design Tokens Community Group「Technical Reports」
- Design Tokens Community Group「FAQ」
- Design Tokens Technical Reports 2025.10
- Design Tokens Format Module 2025.10
- GOV.UK Design System「Contribution criteria」
- W3C WAI「Understanding Target Size (Minimum)」
- W3C WAI「Understanding Focus Appearance」
- 株式会社greeden公式サイト
この記事に関連する株式会社greedenの取り組み
デザインシステムは、部品を増やすより、誰もが迷いにくい基準を継続運用することが成果を左右します。株式会社greedenは、Webアクセシビリティのチェックサービスを提供し、サイトの課題把握と改善の第一歩を支えます。