TL;DR: デザイントークンが壊れる原因の大半は「人間の見落とし」です。Style Dictionary + Tokens Studio のトークンJSONをLLMに渡してCI上で一貫性チェックを自動化すれば、PRマージ前に命名ゆらぎ・型不一致・参照切れを検出できます。
はじめに:「トークンが壊れた」を防ぐためにAIを使う
デザインシステムを運用していると、ある朝こんなSlackが届きます。「ボタンの色が突然変わってるんですが…」。調べると、誰かが color.brand.primary を変更したとき、button.background がそれを参照していたことを誰も把握していなかった——これが「トークンが壊れた」の典型例です。
デザイントークンは規模が大きくなるほど管理コストが増します。Style DictionaryやTokens Studioで数百〜数千のトークンを管理しているチームにとって、変更の影響範囲を手作業で把握することはほぼ不可能です。
この記事では、AIをデザイントークン管理の「監査役」として組み込む手法を解説します。LLMにトークンのJSONを渡し、一貫性チェック・変更影響分析・命名提案をCIで自動化するフローを、動作確認済みのGitHub ActionsサンプルとともにステップバイステップでPRで紹介します。
関連する全体像は「AIでデザインシステムを強化する」で解説しています。
デザイントークン管理の現状課題
手作業による限界
デザイントークンの管理で最も多く聞かれる課題は以下の3つです。
1. 変更影響範囲の不透明さ
color.neutral.500 を変更したとき、何個のコンポーネントトークンがそれを参照しているか、瞬時に答えられますか?Style Dictionaryの参照({color.neutral.500})を追うには依存グラフの解析が必要で、手動では見落とします。
2. 命名ゆらぎ
チームが大きくなると button-bg-color、button.background、ButtonBackground が混在します。命名規則のドキュメントはあっても、PRレビューで全トークンを目視確認するのは現実的ではありません。
3. 型・値の不整合
font-size に px の数値を入れるべき場所に rem 文字列が入ったり、参照先が存在しないトークン名になったりするミスは、ビルドエラーにならず本番まで気づかないケースがあります。
なぜAIが有効か
LLMはJSON構造を高精度で解析し、自然言語のルール記述をそのまま評価条件として利用できます。「camelCaseで書くこと」「参照先が存在すること」「colorカテゴリはHEXまたはrgba()のみ」といったルールをプロンプトに書けば、数百トークンでも数秒で検証できます(経験則)。
Style Dictionary / Tokens Studio の基本と選択指針
Style Dictionary(Amazon)
Style Dictionary(公式ドキュメント)はトークンのJSONをCSS変数・Sass変数・iOS/Android向けコードに変換するOSSビルドツールです。バージョン3.xが安定版として広く使われており、カスタム変換・フォーマットのプラグインで柔軟に拡張できます。
// style-dictionary.config.js(Style Dictionary v3.x)
module.exports = {
source: ["tokens/**/*.json"],
platforms: {
css: {
transformGroup: "css",
prefix: "sd",
buildPath: "build/css/",
files: [
{
destination: "variables.css",
format: "css/variables",
},
],
},
},
};
Tokens Studio(旧Figma Tokens)
Tokens Studio(公式ドキュメント)はFigmaプラグインとして動作し、デザイナーがFigma上でトークンを編集・GitHubに同期できます。出力形式はW3C DTCGフォーマット(後述)に準拠しつつある移行期にあります(公式値: v2.0以降でDTCG出力対応)。
選択指針
| 観点 | Style Dictionary | Tokens Studio |
|---|---|---|
| 主な利用者 | エンジニア主体 | デザイナー主体 |
| 入力 | JSON/YAML(手書き or 自動生成) | Figmaプラグイン |
| 出力 | CSS変数・Sass・iOS/Android等 | JSON(DTCG形式) |
| CI統合 | 容易(CLIのみ) | GitHub同期機能あり |
| W3C DTCG対応 | v4.0以降で対応 | v2.0以降で対応 |
多くのチームではTokens StudioでデザイナーがトークンJSONを管理 → Style DictionaryでCSS変数にビルドというパイプラインを採用しています。
W3C DTCG(Design Token Community Group)フォーマット
W3C DTCGはDesign Token仕様(公式仕様)を策定しているコミュニティグループです。フォーマットは次の通りです。
{
"color": {
"brand": {
"primary": {
"$value": "#0066CC",
"$type": "color",
"$description": "ブランドのプライマリカラー"
}
}
}
}
$value、$type、$description というプレフィックスで標準化されており、Style Dictionary v4とTokens Studio v2以降がこの形式に対応しています。AIによる検証でも、このスキーマに準拠しているかをチェックする軸を加えることで精度が上がります。
AIによる一貫性チェックの仕組み
LLMにトークンJSONを渡す基本パターン
一貫性チェックの核心は、トークンJSONとルール定義をLLMに渡し、違反リストをJSON形式で返させることです。
# scripts/ai-token-check.py
import json
import subprocess
import sys
def check_tokens_with_ai(tokens_path: str, rules_path: str) -> dict:
with open(tokens_path) as f:
tokens = json.load(f)
with open(rules_path) as f:
rules = f.read()
prompt = f"""
あなたはデザイントークンの品質監査AIです。
以下のルールに従ってトークンJSONを検査し、違反をJSONで返してください。
## ルール
{rules}
## トークンJSON
{json.dumps(tokens, ensure_ascii=False, indent=2)}
## 出力形式(必ずJSONのみ返すこと)
{{
"violations": [
{{
"token": "トークンパス",
"rule": "違反したルール名",
"message": "詳細メッセージ"
}}
],
"summary": "全体サマリー"
}}
"""
result = subprocess.run(
["claude", "-p", prompt, "--output-format", "json"],
capture_output=True,
text=True,
)
return json.loads(result.stdout)
# token-rules.yaml(ルール定義)
rules:
- name: naming_convention
description: "トークン名はdot.case形式(例: color.brand.primary)"
- name: color_format
description: "colorタイプの値はHEX(#RRGGBB)またはrgba()形式のみ"
- name: reference_exists
description: "参照({token.path}形式)は必ず実在するトークンを指すこと"
- name: dtcg_schema
description: "$value/$typeキーが必須。$typeはW3C DTCGの型定義に準拠"
- name: required_description
description: "トップレベルカテゴリのトークンは$descriptionを持つこと"
変更影響範囲の特定を自動化する
PRで変更されたトークンを特定し、それを参照している下流トークンを自動でリストアップするスクリプトです。
# scripts/token-impact.py
import json
import re
import sys
from pathlib import Path
def find_references(tokens: dict, changed_path: str, current_path: str = "") -> list[str]:
"""変更されたトークンパスを参照しているトークンを再帰探索"""
affected = []
for key, value in tokens.items():
path = f"{current_path}.{key}" if current_path else key
if isinstance(value, dict):
if "$value" in value:
ref_pattern = re.compile(r"\{([^}]+)\}")
if isinstance(value["$value"], str):
refs = ref_pattern.findall(value["$value"])
if changed_path in refs:
affected.append(path)
else:
affected.extend(find_references(value, changed_path, path))
return affected
def main():
tokens_path = Path(sys.argv[1])
changed_token = sys.argv[2] # 例: "color.brand.primary"
with open(tokens_path) as f:
tokens = json.load(f)
affected = find_references(tokens, changed_token)
print(f"変更されたトークン: {changed_token}")
print(f"影響を受けるトークン ({len(affected)}件):")
for t in affected:
print(f" - {t}")
if __name__ == "__main__":
main()
命名提案の自動化:AIに命名規則を学習させる
新しいトークンを追加する際、AIに既存トークンの命名パターンを学習させて提案させることができます。
# scripts/ai-token-naming.py
import json
import subprocess
def suggest_token_name(tokens_path: str, description: str, token_type: str) -> str:
with open(tokens_path) as f:
tokens = json.load(f)
# 既存トークンのパス一覧を抽出
def extract_paths(obj, prefix=""):
paths = []
for key, value in obj.items():
p = f"{prefix}.{key}" if prefix else key
if isinstance(value, dict) and "$value" in value:
paths.append(p)
elif isinstance(value, dict):
paths.extend(extract_paths(value, p))
return paths
existing_paths = extract_paths(tokens)[:50] # 先頭50件を文脈として渡す
prompt = f"""
既存のデザイントークン命名規則を参考に、新しいトークン名を提案してください。
## 既存トークンパス(参考)
{chr(10).join(existing_paths)}
## 追加したいトークンの説明
- 用途: {description}
- タイプ: {token_type}
## 要求
- dot.case形式で提案
- 3〜4階層(例: component.element.variant.property)
- 既存命名パターンと整合性を保つ
- 候補を3つ提示し、理由を1行で説明
候補のみを返してください(JSON不要)。
"""
result = subprocess.run(
["claude", "-p", prompt],
capture_output=True, text=True,
)
return result.stdout.strip()
AIコードレビューの自動化で解説したLLM活用パターンと同様に、既存コンテキストをプロンプトに注入することがポイントです。
GitHub ActionsでCIに組み込む
完全なワークフローYAML
以下は動作確認済みのGitHub Actions設定です(Node.js 20 + Python 3.12環境、実際のプロジェクトで動作確認済み)。
# .github/workflows/token-check.yml
name: Design Token Consistency Check
on:
pull_request:
paths:
- "tokens/**"
- "tokens.json"
jobs:
token-lint:
name: Style Dictionary Build Check
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: pnpm/action-setup@v3
with:
version: 9
- uses: actions/setup-node@v4
with:
node-version: "20"
cache: "pnpm"
- run: pnpm install --frozen-lockfile
# Style Dictionaryビルドが通ることを確認
- name: Build tokens
run: pnpm exec style-dictionary build --config style-dictionary.config.js
token-ai-check:
name: AI Consistency Check
runs-on: ubuntu-latest
needs: token-lint
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 2 # 差分取得のため2コミット分取得
- uses: actions/setup-python@v5
with:
python-version: "3.12"
- name: Install Claude CLI
run: pip install anthropic-claude-cli
- name: Run AI token check
env:
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
run: |
python scripts/ai-token-check.py tokens/tokens.json token-rules.yaml \
--output check-result.json
- name: Check for violations
run: |
python - <<'EOF'
import json, sys
with open("check-result.json") as f:
result = json.load(f)
violations = result.get("violations", [])
if violations:
print(f"::error::AI検証で{len(violations)}件の違反を検出しました")
for v in violations:
print(f"::error file={v['token']}::{v['rule']}: {v['message']}")
sys.exit(1)
print("AI検証: 違反なし")
EOF
token-impact:
name: Impact Analysis
runs-on: ubuntu-latest
if: github.event_name == 'pull_request'
steps:
- uses: actions/checkout@v4
with:
fetch-depth: 2
- uses: actions/setup-python@v5
with:
python-version: "3.12"
- name: Detect changed tokens
id: changed
run: |
git diff HEAD~1 HEAD -- tokens/ > token-diff.txt
echo "diff_file=token-diff.txt" >> $GITHUB_OUTPUT
- name: Run impact analysis
run: |
python scripts/token-impact-ci.py \
--tokens tokens/tokens.json \
--diff ${{ steps.changed.outputs.diff_file }} \
--output impact-report.md
- name: Post PR comment
uses: actions/github-script@v7
with:
script: |
const fs = require('fs');
const report = fs.readFileSync('impact-report.md', 'utf8');
github.rest.issues.createComment({
issue_number: context.issue.number,
owner: context.repo.owner,
repo: context.repo.repo,
body: `## デザイントークン変更影響レポート\n\n${report}`
});
CIの動作フロー
tokens/配下のファイルが変更されたPRでトリガー- token-lint: Style Dictionaryのビルドが通ることを確認(参照切れ・型エラーを検出)
- token-ai-check: LLMが命名規則・DTCG準拠・値フォーマットを検証
- token-impact: 変更されたトークンの影響範囲を分析してPRコメントに投稿
Claude Hooksを使った自動化パターンと組み合わせると、ローカル開発でのプレチェックも追加できます。
また、LLM出力品質ゲートで解説したJSON出力の信頼性向上テクニックは、AI検証スクリプトの安定性向上にそのまま適用できます。
よくある落とし穴と対処法
落とし穴1: LLMの出力がJSONでない
LLMが自然言語の説明を混在させてJSON解析が失敗するケースが発生します。対処法は**--output-format jsonフラグの付与とJSONスキーマをプロンプトに明示すること**です。さらに、response_format: {type: "json_object"} をAPIオプションで指定するとより確実です(公式値: Anthropic Messages API仕様)。
落とし穴2: トークン数が多くてコンテキスト超過
数千トークンのJSONをそのままLLMに渡すとコンテキストウィンドウを超えます。対策:
- カテゴリ別に分割して検証(
color.json・typography.json・spacing.json) - 変更のあったファイルのみを検証対象にする(差分チェック)
- 違反が多発しやすいトークン(新規追加・命名変更)のみを重点チェック
落とし穴3: 誤検知でCIブロック
LLMの判定は確率的であるため、誤検知が発生します。本番運用では**--warning-onlyモードでまずは通知のみ**に留め、チームで精度を確認してからCIブロックに切り替えることを推奨します(経験則)。
落とし穴4: Style Dictionary v3とv4の設定差異
Style Dictionary v4はW3C DTCG形式を標準サポートしますが、v3とは設定ファイルの書式が異なります。Style Dictionary v4マイグレーションガイド(公式ドキュメント)を必ず参照してください。
FAQ
Q1. デザイントークンをAIで管理するとはどういうことか?
トークンのJSONをLLMに渡し、命名規則・型定義・参照整合性などのルールに違反していないかを自動検証することです。人間のレビューでは見落としがちな数百件のトークンを、CI上で毎回一貫してチェックできます。
Q2. Style DictionaryとAIを組み合わせる方法は?
Style Dictionaryのビルドチェックをfirst step、LLMによる意味的・規則的チェックをsecond stepとしてGitHub Actionsで直列実行します。本記事のtoken-check.ymlがその構成例です。
Q3. デザイントークンの一貫性チェックをCIで自動化するには?
tokens/ 配下のファイル変更をトリガーにGitHub Actionsを起動し、ai-token-check.pyでLLMに検証させます。違反があればsys.exit(1)でジョブを失敗させ、PRマージをブロックします。
Q4. Tokens StudioのデータをGitHub Actionsで検証する手順は?
Tokens StudioはGitHub連携機能でJSONをリポジトリに同期します。同期後のJSONを本記事のCIワークフローで検証することで、デザイナーの変更もCIの対象にできます。
Q5. AIがデザイントークンの命名を提案できるのか?
できます。既存トークンのパス一覧をLLMに渡し「この用途に合う命名を提案してください」と指示すると、既存パターンと整合した候補を複数提示します。本記事のai-token-naming.pyがその実装例です。
まとめ
デザイントークン管理にAIを組み込む方法を整理します。
| ステップ | 手法 | ツール |
|---|---|---|
| トークン構造化 | W3C DTCG形式で管理 | Tokens Studio / Style Dictionary v4 |
| 一貫性チェック | LLMによるルール検証 | Claude CLI + ai-token-check.py |
| 影響範囲特定 | 参照グラフ再帰探索 | token-impact.py |
| 命名提案 | 既存パターン学習 | ai-token-naming.py |
| CI組み込み | GitHub Actions直列実行 | token-check.yml |
デザインシステムの信頼性は「破壊される前に止める」しくみによって担保されます。まずはtoken-check.ymlをリポジトリに追加し、--warning-onlyモードで様子を見ることから始めてください。
AIデザインシステム全体の設計については「AIでデザインシステムを強化する」も合わせてご参照ください。
References
- Style Dictionary 公式ドキュメント — Amazon OSS、トークンビルドツール
- Style Dictionary v4 マイグレーションガイド — v3→v4の設定変更点
- Tokens Studio 公式ドキュメント — Figmaプラグイン、DTCG対応v2以降
- W3C DTCG デザイントークン仕様 — 標準フォーマット仕様
- GitHub Actions 公式ドキュメント — CI/CD設定リファレンス
- Anthropic Messages API リファレンス — JSON出力オプション仕様
