統一デザインシステムの資産化：2 層 CSS variables で足りる（enterprise 構造は過剰）

B 方向·OPC 最佳实践（维度：見た目の資産運用）。デザイン 索引にシステム課題なし（japan-senior-ui-guidelines は原则、本課題は実装資産）。xmm 本轮不可用。

背景と問題

モジュール寄生構造（opc-module-component-map）で家族图谱上に機能が積み上がる——見た目が製品ごとにバラけると「同じ家族の道具」感が壊れる。デザインの一貫性を保つ仕組みを、solo の実装コストの範囲で作る。

发现（访问 2026-09-15）

• 2 層構造が solo の最適解：primitive token（--color-blue-500）→semantic token（--color-primary）の 2 段の CSS variables で 9 割の効果——Style Dictionary/Figma 同期 pipeline など enterprise 構成は不要というのが実務者の共通見解（Contentful 解説、Reddit の過剰設計議論，访问 2026-09-15）。
• 3 層目（component token）は製品線が育ってから：primitive/semantic/component の 3 段構成に成長させる判断は「複数製品で同じ部品を使い回す」段になってからでよい。
• token の本質は「デザイン決定に名前を付けて再利用する」こと——solo でも「決定の記録」としての価値がある（ EightShapes の整理）。

推测

• 我々の token の中核は文字サイズとコントラスト【推测】：銀髪 UI ガイド（japan-senior-ui-guidelines·16pt 準拠等）の数字をそのまま semantic token（--text-body-large 等）に写す——原则課題の数字が実装に落ちる最初の場所。
• 色は低彩度·高コントラストの 2 軸で家族端（老人端）と子女端の 2 テーマに分ける（同一 semantic token で値だけ差し替え）——japan-bilingual-family-ui（双語 UI）と同じ「同一構造·異なる値」の設計思想。

结论

可行动启发：

1. tokens.css 1 ファイルを最初の資産に：色 12 個前後+文字 3 サイズ+間隔 3 種の 2 層 token——全製品（PWA/LINE リッチメニューの色指定含む）がこの 1 ファイルを参照する単一の真実。
2. senior-ui ガイドの数字を semantic token に写す作業を実装週に：16pt·コントラスト比等の原则を --text-*, --contrast-* として固定——原则が守られない事故を構造で防ぐ。
3. リッチメニュー画像の色も token から生成：LINE リッチメニュー（opc-line-richmenu-design）の画像内色指定も同じ色値を使う（画像生成時のテンプレに token 値をハードコードしない）。
4. component token は「家族カード」が出たら：家族メンバーの表示部品が複数モジュールで使い回される段階で 3 層目に昇格——現段階では導入しない（過剰設計回避）。

待办 / 下次继续

• tokens.css v1（色/文字/間隔の 2 層、senior-ui 数字反映）。
  
• 家族端/子女端 2 テーマの色ペア表 v1。
  

关联

• japan-senior-ui-guidelines（原则→token への写像元）、opc-module-component-map（機能の統合·見た目側）、opc-line-richmenu-design（画像内色の統合先）、japan-bilingual-family-ui（同一構造·異なる値の思想）。