「AIっぽい見た目」を卒業する──デザイントークンをAIに渡す方法

3行まとめ

1. AIに曖昧に頼むと暗い紺×シアンのテック調に収束しがち
2. デザイントークン（CSS変数）で具体値を渡すと再現性が上がる
3. 世界観の一文＋変数セットで量産的な見た目から脱却しやすい

AIに「いい感じのサイトを作って」と頼むと、似たような暗い紺×シアンのテック調に収束しがちだ。原因は指示の曖昧さにある。

解決策：トークンで渡す

曖昧な言葉ではなく、デザイントークン（CSS変数） で具体値を渡すと再現性が上がる。

:root {
  --bg: #faf6ef;      /* 背景 */
  --surface: #fffdf8; /* カード面 */
  --text: #2b2722;    /* 文字 */
  --accent: #c75f3e;  /* アクセント */
  --radius: 14px;     /* 角丸 */
}

「クリーム×テラコッタの雑誌風で、明朝見出し、余白広め」のような世界観の一文と、この変数セットをAIに渡すだけで、量産的な見た目から脱却しやすくなる。

試せます

当サイトのツール一覧で、配色×フォントの組み合わせを選んでトークンを書き出せる「Design Vault」を公開しています。

デザイントークンとは、正確には何を指すのか

「デザイントークン」という言葉には統一された唯一の定義があるわけではないが、業界標準を定めようとしている団体がW3Cの「Design Tokens Community Group」だ。2026年8月14日時点でW3Cの公式サイト（designtokens.org）を確認すると、このグループが策定中の仕様は「Design Tokens Format Module」（2026年7月30日付のDraft Community Group Report）で、ページ自身に「これは進行中の変更のプレビュードラフトであり、直接参照・実装しないでほしい」と明記されている。つまり2026年8月時点では、まだ確定版のW3C標準ではなく、業界が合意形成を進めている途中の仕様だ。

この仕様が定めているのは、ツール間でデザイントークンをやり取りするためのJSON形式のファイルフォーマットで、推奨拡張子は.tokensまたは.tokens.json。トークン1つは最低限、値を表す$valueと種類を表す$typeという2つのプロパティを持つ。任意で$description（説明文）や$deprecated（廃止予定フラグ）も付けられる。

定義済みのトークン種類（W3C仕様より）は以下の通り。

記事冒頭のサンプルコードにある--bgや--radiusはCSS変数としての書き方であり、上記のJSON形式そのものではない。両者は別物だが、目的は同じで「色や余白を、コード側から差し替え可能な変数として管理する」という考え方の実装が違うだけだ。個人開発でAIに渡す分には、CSS変数のままで十分機能する。JSON形式のトークンファイルが要るのは、同じトークンをWeb・iOS・Android・Figmaなど複数のプラットフォームで使い回したい場合だ。

AIコーディングツールごとの渡し方

AIコーディングツールによって、トークンの受け取り方に癖がある。2026年8月14日時点で各公式ドキュメントを確認した範囲では、次のような違いがある。

共通しているのは、どのツールも「変数名の集合」という形でトークンを受け取る点だ。AIに投げるプロンプトに直接この変数定義を貼り付けるだけでも、多くの場合は機能する。Tailwindプロジェクトなら@themeブロックごと、shadcn/uiベースのプロジェクトならglobals.cssの:rootと.darkブロックごと渡すのが手っ取り早い。

なお、Vercelが提供するAIコーディングツールv0の公式ドキュメント（v0.app/docs）を2026年8月14日時点で確認したが、デザインシステムの読み込みについては、v0公式に「Design Systems 2.0」という専用ドキュメントがあり、インストール可能なパッケージ・ソースリポジトリ・実際に動いているアプリ・Storybookやドキュメント・Figmaのフレームといった複数の入口からv0にデザインシステムを教えられると説明されている。ツールによって公開ドキュメントの充実度に差があるため、個別に試して確認する必要がある。

つまずきやすいポイント

• 変数名だけ渡して値の意図を渡さない。 「--radius: 14px」だけでは、AIは「なぜ14pxなのか」「ボタンとカードで同じ半径を使うべきか」までは判断できない。「カードは大きめの角丸、ボタンは小さめ」のように、どのコンポーネントにどのトークンを当てるかの方針も一言添えると再現性が上がる。
• コントラスト比を指定し忘れる。 背景色とテキスト色をトークンで渡しても、AIが自動でアクセシビリティ基準を満たす組み合わせを選んでくれるとは限らない。文字色と背景色のペアは自分で確認するか、既存のUIキットの配色をそのまま流用するのが安全。
• ダークモードを後付けで頼む。 shadcn/uiの設計思想のように、最初から「同じトークン名を.darkで上書きする」前提で変数を作っておかないと、あとからダークモード対応を頼んだときにAIが変数体系を作り直してしまい、既存のライトモードのスタイルまで崩れることがある。
• フォントのライセンスを確認しない。 「明朝体で」「セリフ体で」と指定してAIが選んだフォントが、商用利用不可のライセンスだったケースがある。Google FontsやAdobe Fontsなど、ライセンスが明示されているフォントを自分で指定する方が確実。

トークンを用意する3つの方法（判断の目安）

個人や小規模チームがAIコーディングでまず試すなら、CSS変数の手書きで十分なことが多い。複数プラットフォームへの展開や、デザイナーとエンジニアの間でトークンを一元管理したくなった段階で、Style Dictionaryのようなビルドツールの導入を検討すればよい。

AIコーディングツール自体の選び方については、AIコーディングアシスタント比較──Copilot/Cursor/Claude Code【2026年】も参照。

正直に書いておくと

• 「デザイントークンを渡せば必ず量産的な見た目から脱却できる」とは言えない。AIの出力は依然としてプロンプト全体・学習データの傾向に左右され、トークンは再現性を上げる一つの手段にすぎない
• 本記事で紹介したツールの対応状況（Tailwind、shadcn/ui、Style Dictionary）は2026年8月14日時点で各公式ドキュメントを確認した内容であり、AIコーディングツール側（Claude Code、Cursor、v0、bolt.newなど）が「デザイントークンJSON」を直接読み込む専用機能を持っているかどうかは、ツールごとに個別の検証が必要で、本記事では全ツールを検証できていない
• W3Cの仕様自体がまだDraft（草案）段階であり、将来的にプロパティ名や構造が変わる可能性がある。今この仕様に厳密に沿ってファイルを作り込んでも、そのまま将来も使える保証はない
• コントラスト比などのアクセシビリティ基準は、トークンを渡すだけでは担保されない。別途チェックが必要