デザイントークンの設計：CSSカスタムプロパティとビルド時トークンの使い分け
デザイントークンは設計判断を一元管理する仕組みだが、実行時のCSSカスタムプロパティとビルド時に静的展開する方式では性質が異なる。選択は、テーマ切り替えが実行時の要件かどうかで決まることが多い。
デザイントークンは、色や余白といった設計判断を名前付きの値として一元管理する仕組みだ。実現方法は大きく、実行時に解決するCSSカスタムプロパティと、ビルド時に静的な値へ展開する方式に分かれる。両者は目的が近いようで性質が異なる。ここでは使い分けの判断基準を整理する。W3CのDesign Tokens Community Groupも、トークンを特定の実装から独立した抽象として定義している。
トークンが解く問題
トークンが本質的に解くのは、「設計判断の重複」だ。同じ色コードや余白値がコードの各所に散らばると、変更のたびに全箇所を追う必要が生じる。トークンは値に名前を与え、参照を一点に集約する。この一元化そのものは、どの実現方式でも共通する価値だ。
実行時トークン：CSSカスタムプロパティ
CSSカスタムプロパティは、ブラウザが実行時に値を解決する。最大の利点は、テーマの切り替えやダークモードを、CSSの変数を差し替えるだけで実現できる点だ。カスケードに乗るため、特定の範囲だけ値を上書きすることもできる。一方で、各プロパティの解決に一段の間接参照が挟まる。多くの場合は無視できるが、極端に多用すれば描画コストに影響しうる。
ビルド時トークン：静的な生成
ビルド時トークンは、定義から各プラットフォーム向けの静的な値を生成する。CSSだけでなく、iOSやAndroidのコードも同じ定義から出力できるため、プラットフォーム非依存という強みがある。値は静的に展開されるので、実行時の間接参照はない。ただし、静的である以上、実行時のテーマ切り替えには向かない。切り替えが要るなら、生成物の側でCSSカスタムプロパティを併用することになる。
使い分けの判断
判断の分かれ目は明快だ。テーマの実行時切り替えが要件なら、CSSカスタムプロパティが第一の選択肢になる。複数プラットフォームへ同じ定義を展開したいなら、ビルド時トークンが適する。もっとも、両者は排他ではない。ビルド時に基盤トークンを生成し、テーマに関わる部分だけ実行時のカスタムプロパティに載せる構成は、実務でよく取られる。フォントの読み込みを静的に最適化する発想はWebフォントのサブセット化と通じ、フォーカスのように実行時にしか検証できない要素はフォーカス管理で扱ったとおり別の扱いが要る。
実行時か、ビルド時か
デザイントークンの価値は一元化にあり、その点は方式を問わない。分かれるのは、実行時の柔軟性を取るか、静的な最適化とプラットフォーム非依存を取るかだ。テーマ切り替えという要件の有無を先に確かめれば、選択は自ずと定まる。多くの現場では、両者の併用が現実的な落としどころになる。
