DESIGN.mdは「判断の説明」にとどめ、値は本物のトークンから読ませる。トークンを1つ変えて新画面が追従するか試す
手書きのDESIGN.mdに値を写すと、見た目は合っていても「2つ目のデザインシステム」ができてしまう。
どんな問題を解決するか / いつ使うか
DESIGN.mdにトークンの値をコピーしてエージェントに渡していると、本物のデザインシステムが更新されても生成画面は古い値のまま、というずれ（ドリフト）が起きる。例として、Supernova が Skyscanner の Backpack 向けに手書きしたDESIGN.mdには、434個のトークンのうち32個しか入っておらず、ダークモードやボタンのAPIも抜けていた。
関連: DESIGN.mdだけでは部品の選び方がぶれる。種類一覧と使い分けの索引を1階層上に置く、AI向けデザインシステムはコードを正にし、FigmaはMCPで作る「鏡」にする
手順
- DESIGN.mdには「なぜこの見た目か」（トーン、優先順位、やらないこと）を書く。具体的な色・余白の値は書き写さない。
- 値と部品は、製品の実際のコンポーネントとトークンの正本（トークンファイル、パッケージ、MCP）から読むようエージェントに指示する。
- ドリフト検査：本物のデザインシステムでトークンを1つ変更し、エージェントに新しい画面を1枚作らせる。
- 新しい値が反映されれば正しくつながっている。古い値が出たら、どこか（DESIGN.md、過去の画面のコピーなど）に値が写されている。
- 画面を何十枚も量産する前に、この検査を一度やっておく。
注意点
- DESIGN.mdを使うなとは言っていない。役割を「説明」と「正本への道案内」に分けるのがポイント。
- 検査用に変えたトークンは元に戻す。