AIでデザインシステム運用を週10時間短縮
「需要はあるのに手が足りない」—これはデザインシステムチームの永遠の課題だ。コンポーネントを作り、ドキュメントを書き、一貫性を保ち、採用を促進し、さらに「AIも活用しろ」と言われる。
Design System Guide の Romina Kavcic が、この課題に対する 20の具体的なAIワークフロー をまとめた記事を公開した。本記事では、その内容を紹介しつつ、ソロビルダーが即実践できる形 に落とし込む。
参考記事: 20 AI workflows that save design system teams 10+ hours a week
🏷️ 関連プロダクト
5つのカテゴリ、20のワークフロー
元記事では以下の5カテゴリに整理されている：
- コンポーネントと実装 — AIによるコード生成・自動監査
- ドキュメントと支援 — ドキュメント自動同期、オンボーディング
- 戦略と優先順位付け — バックログ整理、意思決定支援
- トークンと一貫性 — 命名規約生成、トークン監査
- 採用・メトリクス・ROI — 採用ダッシュボード、バイパスパターン分析
以下、各カテゴリから特に重要なワークフローを紹介する。
カテゴリ1: コンポーネントと実装
1. Figma → コンポーネント自動生成
問題: AIが生成するコンポーネントは、単体では良く見えても、実際のシステムに組み込むと破綻する。独自のスペーシング、間違ったトークン、無視されたコンポジションパターン。
解決策: AIを自分のシステムに接続する。
セットアップ:
1. Figma Make がデザインフレームからコード生成
→ 汎用コードではなく、既存コンポーネントを参照
2. MCP コネクタ（Notion, GitHub）でコンポーネントドキュメントとトークンファイルにアクセス
3. .ai/ ディレクトリにコンポーネント生成ルールを配置
→ どのトークンを使うか、どの基本コンポーネントを組み合わせるか、アクセシビリティ要件
ソロビルダーの実践ポイント: Figma MakeだけでなくCursor、Claude Codeも同様の設定が可能。
.ai/ディレクトリのルールファイルがあれば、どのツールでも一貫したコード生成が実現できる。
2. Playwright MCPで継続的監査
問題: アクセシビリティ監査、ビジュアルリグレッションテスト、トークン使用チェックは、誰も時間がないが、スキップすると必ず問題になる。
解決策: PlaywrightのMCP統合で、3つのAIエージェントが協調動作する。
- Planner: StorybookやドキュメントサイトからテストシナリオをE
- Generator: コンポーネントと対話しながらテストコードを書く
- Healer: コンポーネント変更時にテストを自動修正
今日から自動化できる5つの監査:
| 監査種別 | 内容 |
|---|---|
| トークン一貫性監査 | レンダリングされたコンポーネントからハードコードされた値を検出 |
| コンポーネント動作テスト | キーボードナビゲーション、フォーカス管理 |
| アクセシビリティチェック | ARIAロール、コントラスト、スクリーンリーダーラベル |
| ドキュメント正確性 | ドキュメントと実際のコンポーネント動作の一致 |
| ビジュアルリグレッション | テーマ・ビューポート間のスクリーンショット比較 |
3. Plugmaでカスタムトークンバリデーター
問題: デザイナーが間違ったトークンを使う、セマンティックレイヤーをスキップする、ステータスカラーを誤ったコンテキストで使う。同じレビューコメントを毎週繰り返す。
解決策: Plugma でFigmaプラグインを開発。
npx create-plugma@latest my-token-validator
cd my-token-validator
npm run dev # Figma内でホットリロード
プラグインでフラグできる内容:
- トークンの代わりに使われた生のHEXカラー
- コンポーネント内で直接使われたプリミティブトークン（
blue.500） - 間違ったコンテキストで使われたステータスカラー（danger/success）
- 静的要素に適用されたインタラクティブトークン
カテゴリ2: ドキュメントと支援
4. マイグレーションガイド自動生成
問題: 破壊的変更をリリースすると、3チームが壊れる。誰もchangelogを読まない。
解決策: AIに差分と変更理由を渡し、構造化されたガイドを生成させる。
プロンプト:
この破壊的変更のマイグレーションガイドを書いてください。
入力:
- 旧API: [貼り付け]
- 新API: [貼り付け]
- 変更理由: [貼り付け]
出力:
1) 影響を受けるのは誰か
2) before/afterの例
3) ステップバイステップのマイグレーションチェックリスト
4) よくある間違い
migration-guides/[component]-[version].mdとして保存。チームから「どう更新すればいい？」と聞かれたら、返答を打つ代わりにリンクを送る。
5. ドキュメント自動同期パイプライン
問題: コードから数週間遅れたドキュメントは、ドキュメントがないより悪い。積極的に誤解を招く。
パイプライン構成:
1. Figma MCP がデザインからprops、バリアント、ステートを抽出
2. Claude Code がソースコード + Figmaデータからドキュメントマークダウンを生成
3. Mintlify（またはStorybook）がマージ時に自動公開
4. Cronジョブ（オプション）が週次でスクリーンショットを再同期、ドリフトを検出
6. Claude Code Skillsでプロンプトを標準化
問題: チームメンバーごとにAIへのプロンプトが異なる。結果は一貫性がなく、同じ指示を何度も書く羽目になる。
解決策: Claude Code Skills。Skillsはコンテキストに基づいて自動ロードされる再利用可能な指示セット。
デザインシステムに最適なSkills:
| Skill名 | 機能 |
|---|---|
token-migration-assistant |
Style Dictionary、W3C DTCG、Figma Variables、CSS、Tailwind間の変換を検出・実行 |
component-audit |
アクセシビリティ、テーマ対応、レスポンシブ、コード品質の包括監査 |
documentation-standards |
フォーマットに合わせた一貫したコンポーネントドキュメントを生成 |
brand-guidelines |
ブランドの色、タイポグラフィ、スペーシング、モーションルールを適用 |
figma-variables-generator |
デザイントークンからFigma Variables JSONを直接生成 |
プロンプトライブラリとの違い: プロンプトライブラリは「存在を忘れられるドキュメント」。Skillは「関連性を検出したら自動ロード」。この違いがすべて。
カテゴリ3: 戦略と優先順位付け
7. リクエスト統合とバックログ整理
問題: リクエストがSlackスレッド、Jiraチケット、会議の余談、3週間前のワークショップのポストイットから来る。手動で重複排除に何時間もかかる。
プロンプト:
あなたはデザインシステムリードがリクエストを統合するのを支援しています。
入力: リクエストのリスト（Slackスニペット、Jiraチケット、会議メモ）
出力:
1) テーマ別にグループ化されたクリーンなリクエストリスト（重複はマージ）
2) 各テーマの頻度、影響を受けるチーム、根本的なjob-to-be-done
3) 短い「やらないことリスト」（スコープコントロール）
フォーマット: markdown
スプリントあたり2〜3時間節約。記憶ではなくソース・オブ・トゥルースを持てる。
8. コンポーネント構築判断の事前検証
問題: 影響力のある人がリクエストし、構築すると、6ヶ月後に2箇所でしか使われていない。一方で3チームが本当に必要としているコンポーネントはバックログに埋もれている。
プロンプト:
新しいコンポーネントを構築すべきか判断を支援してください。
コンポーネントリクエスト: [貼り付け]
コンテキスト:
- リクエストしているチーム: [リスト]
- 既知の画面/フロー: [リスト]
- 現在のシステム内の代替: [リスト]
出力:
1) 再利用可能性（高/中/低）と理由
2) リスク（メンテナンス、バリアント、アクセシビリティの複雑さ）
3) MVPスコープ（最小実行可能バージョン）
4) 構築前に検証すべきこと
カテゴリ4: トークンと一貫性
9. AIでトークン命名規約を生成
問題: 命名の不整合があらゆる場所に。あるファイルではcolor-primary、別のファイルではprimaryColor、さらに別ではbrand.primary。
プロンプト:
トークンセットを分析し、一貫した命名規約を提案してください。
目標:
- 予測可能
- 複数ブランドにスケール可能
- セマンティックとプリミティブの明確な分離
出力:
1) 命名ルール
2) 10個の「before → after」リネーム例
3) 短いマイグレーション戦略
開発者がドキュメントを確認せずにトークン名を推測できる — これが目標。
10. MCPでリアルタイムトークン接続
問題: AIプロンプトにトークン値を貼り付けるたびに、それはすでに古くなっている。Figma変数が更新される。トークンJSONに新リリースが出る。AIは先週の火曜日にコピペしたものを使っている。
解決策: MCPサーバーでデザイントークンをClaude直接接続。
1. Figma MCPサーバー（または独自のMCP Design Tokens Serverテンプレート）をインストール
2. FigmaファイルまたはトークンJSONを指定
3. これで、実行するすべてのAIプロンプトが実際のトークン値にリアルタイムアクセス
11. トークンドリフト監査Skill
問題: チームがトークンをバイパスする。数週間後にUIがおかしくなって気づく。すべてのPRでハードコードされた色やスペーシング値を手動チェックするのはスケールしない。
Skill例:
---
name: token-drift-audit
description: デザイントークンシステムをバイパスするハードコード値をコードベースからスキャン
autoload: PRレビュー時またはトークン使用チェック時
---
# Token Drift Audit
## フラグする内容
- コンポーネントファイル内のハードコードされたhex/rgb/hslカラー
- 生のピクセルスペーシング値（4px, 8px, 16px等）
- タイポグラフィトークンの代わりのインラインフォントサイズ
- トークンとして存在するが生の値で書かれた色
- コンポーネント内で直接使われたプリミティブトークン（例: blue.500）
## 出力フォーマット
- 発見内容を重大度別にグループ化: critical, warning, info
- 各発見についてファイルパスと行番号を表示
- ハードコード値に対する正しいトークンを提案
- 最後にサマリーカウント
保存場所: .claude/skills/token-drift-audit/SKILL.md
カテゴリ5: 採用・メトリクス・ROI
12. ビルドタイム採用メトリクス
問題: リーダーシップがメトリクスを求める。しかしランタイムトラッキング（どの開発者がどのコンポーネントを使っているかリアルタイム監視）は侵襲的で、データもノイズが多い。
解決策: ビルドタイムシグナルから始める。
| メトリクス | 内容 |
|---|---|
| コンポーネントインポート/使用カウント | どのコンポーネントがどれだけ使われているか |
| トークンドリフトカウント | ハードコード値の数 |
| バイパスシグナル | 生の<button>要素、インラインスタイル |
| PRドリフトデルタ | PR間でのドリフト増減 |
ビルドタイムメトリクスは「監視されている」感覚なしに、コードベースで何が起きているかを教えてくれる。
13. バイパスパターン分析
問題: チームがデザインシステムをバイパスすると、本能的にチームを責める。しかし一貫してバイパスされるなら、システムがチームを失望させている。コンポーネントがない、トークンがない、ドキュメントが不明確、APIが硬すぎる。
プロンプト:
このドリフトレポートから、上位のバイパスパターンを特定してください。
各バイパスについて:
- なぜチームがそうするのか
- デザインシステムは何を変えるべきか（コンポーネント、トークン、ドキュメント）
- 今スプリントで出荷できる最小の修正
修正するバイパスごとに、システムは使いやすくなり、次のバイパスは起こりにくくなる。採用の複利効果。
24/7デザインシステムアシスタント: OpenClaw
元記事で紹介されている OpenClaw（旧称clawdbot）は、自分のハードウェアで24時間動作するオープンソースAIアシスタントだ。
セットアップ例:
- 朝のcronジョブでトークンドリフトスキャンを実行、結果をSlackに投稿
- チームメンバーがTelegramでボットにメッセージ:「現在のスペーシングスケールは？」
→ 実際のトークンを読み取って回答
- 週次自動競合チェック:「Polaris、Carbon、Primerが今週何を出荷した？」
セキュリティ上の注意: 本番インフラとは別のサーバーで動かす。トークンファイルとドキュメントのクローンへの読み取り専用アクセスのみを与える。
ツール一覧と始め方
| ツール | 用途 | リンク |
|---|---|---|
| Claude Code | ファイルアクセス、Web検索、Skills対応のAIコーディングアシスタント | claude.ai |
| Figma MCP | 変数、デザインフレーム、コンポーネントメタデータを読み取り | MCP公式 |
| Figma Make | Figmaデザインからコンポーネントライブラリを使ったコード生成 | figma.com/make |
| Playwright | Planner/Generator/HealerエージェントでE自動ブラウザテスト | playwright.dev |
| Context7 | AI toolsに最新ライブラリドキュメントを供給 | context7.com |
| Plugma | モダンFigmaプラグイン開発ツールチェーン | plugma.dev |
| OpenClaw | 自分のサーバーで動くセルフホストAIアシスタント | docs.openclaw.ai |
ソロビルダーへの提案: まず試すべき3つ
大規模チーム向けの内容だが、ソロビルダーが明日から試せる ものを3つ選ぶなら：
1. .ai/ ディレクトリを作る
プロジェクトルートに .ai/ を作り、コンポーネント生成ルールを書く。どのトークンを使うか、どのパターンに従うか。Cursor、Claude Code、どのツールでも一貫した出力が得られる。
2. Claude Code Skillを1つ作る
自分のプロジェクトの命名規約やコーディングスタイルを .claude/skills/ にMarkdownで書く。Skillは使う必要があるときに自動でロードされる。
3. MCPでFigmaまたはトークンを接続
コピペでトークン値を渡す代わりに、MCPサーバーでリアルタイム接続。「常に最新のトークンを見ている」状態でAIが動く。
まとめ
デザインシステムの運用は「やることが多すぎて手が回らない」状態になりがちだ。この記事で紹介した20のワークフローは、AIに任せられる部分を明確化 し、人間は「難しい判断」に集中できるようにする。
ソロビルダーにとっても、.ai/ ディレクトリ、Claude Code Skills、MCPの3つから始めれば、すぐに恩恵を受けられる。
参考リンク
- 原文記事: 20 AI workflows that save design system teams 10+ hours a week — Romina Kavcic
- Claude Code Skills: Claude Code公式ドキュメント
- MCP公式: modelcontextprotocol.io
- OpenClaw: docs.openclaw.ai