【テクニカル・上級編】Figmaの「Library Analytics」を徹底活用！デザインシステムの利用率とコンポーネントのデッドコードを可視化する方法 – UI/UX・デザインツール活用バイブル

デザインシステムを「聖域」から「兵器」へ：Library Analyticsで倒すゾンビコンポーネントの全技術

デザインシステムは、作った瞬間から腐敗が始まる。
これは残酷な真実だが、多くの組織が「コンポーネントライブラリを公開したこと」で満足し、その後のメンテナンスを放置している。結果、デザインファイルには数千の使われないレイヤーが蓄積し、メモリを食らい、デザイナーの認知負荷を増大させ、エンジニアとのコミュニケーションコストを肥大化させる「ゾンビコンポーネント」が蔓延する。

本稿では、FigmaのLibrary Analyticsを単なる「利用状況モニタ」としてではなく、デザインシステムの健全性を担保し、ROIを可視化するための「計測・排除パイプライン」の核として活用する方法を伝授する。

—

1. Library Analyticsの解像度を一段引き上げる

Figmaの標準ダッシュボードは便利だが、本質は「どのコンポーネントが使われているか」の粒度にある。我々が注目すべきは、単なる「Insert数」ではなく、「Detached（デタッチ）率」と「更新頻度」だ。

Detached率が高いコンポーネント:

これはライブラリのAPI設計が、現場のユースケースに追いついていないことを示すシグナルだ。ユーザー（デザイナー）は「使いたい形にできないから」破壊している。これを放置するのは、設計の敗北である。

更新頻度 vs 利用数:

更新頻度が高いのに利用数が少ないコンポーネントは、過剰設計か、あるいはドキュメントが不親切である証拠だ。

—

2. ゾンビコンポーネントを殲滅するAPI自動化術

UI上でポチポチと確認する時代は終わった。Figma REST APIを叩き、全ファイルの利用状況をスプレッドシートやデータベースに吸い上げ、デッドコードを自動検知するスクリプトを構築する。

以下のNode.jsスクリプトは、Figma APIを介して特定ライブラリの利用状況を取得し、利用数がしきい値を下回るコンポーネントをリストアップする雛形だ。

Figma Library Audit Script
特定のLibraryにおける利用数に基づき、ゾンビコンポーネントを特定する

/
const axios = require(‘axios’);

const FIGMA_TOKEN = process.env.FIGMA_ACCESS_TOKEN;
const FILE_KEY = ‘YOUR_LIBRARY_FILE_KEY’; // デザインシステムのFile Key

async function fetchComponentUsage() {
// Library Analytics APIを叩く（Enterpriseプランの権限が必要）
const url = `https://api.figma.com/v1/files/${FILE_KEY}/analytics/components`;

try {
const response = await axios.get(url, {
headers: { ‘X-Figma-Token’: FIGMA_TOKEN }
});

const components = response.data.components;

// 利用数が極端に少ない（ゾンビ）コンポーネントを抽出
const zombies = components.filter(c => c.usageCount < 5); console.table(zombies.map(z => ({
name: z.name,
usage: z.usageCount,
lastUsed: z.lastUsedAt
})));
} catch (err) {
console.error(‘API Error: 権限またはトークンを確認せよ。’, err);
}
}

fetchComponentUsage();

運用ハック：CI/CDとの統合

このスクリプトをGitHub Actionsで定期実行（Cron）し、利用率が極端に低いコンポーネントをSlackの #design-system-admin チャンネルに通知せよ。「今週の削除候補」としてIssueを自動発行するまでがワンセットだ。

—

3. デザイン効率をROIに変換する「メトリクス・ダッシュボード」

経営層に対して「デザインシステムのおかげで綺麗になりました」と報告しても予算は取れない。「これだけの工数を削減した」という数値が必要だ。

私は以下の計算式でROIを算出している。

1. 削減工数 (Hours): `(全コンポーネント数 – 削除したゾンビ数) 修正にかかる平均工数(通常15分) 利用回数`
2. コスト換算: `削減工数平均時給(エンジニア換算)`

これをLookerやGrafanaに流し込み、「デザインシステムのメンテナンスによって、今月は〇〇時間の開発工数を創出した」というグラフを生成する。これが、デザインシステムを組織のインフラとして認めさせる唯一の言語だ。

—

4. エキスパートとしての最適化：パフォーマンスの深淵

Figmaのファイルパフォーマンスを最適化する最後の砦は、「巨大なメインコンポーネントの分割」にある。

メモリ消費の削減: 1つのファイルに全コンポーネントを押し込むと、Figmaのメモリ消費は指数関数的に増大し、スクリプトの実行速度も低下する。
ライブラリの分割: Atomic Designに基づいて、Foundation（Token系）、Molecules（パーツ系）、Organisms（複合系）でファイルを物理的に分割せよ。
不要なVariantの圧縮: バリアントセットが肥大化しすぎていないか？ `Component Property` を活用し、隠れたバリアントを整理することで、ファイルを開く速度が劇的に向上する。

—

結びに：伝説のアーキテクトからの一言

デザインシステムは「納品物」ではなく「生き物」だ。
放置すれば腐敗し、手入れを怠れば肥大化する。Library Analyticsは、その腐敗を早期に発見するための「聴診器」だ。

APIを使い倒せ。自動化を恐れるな。デザイナーがツールの中で迷う時間を極限まで削り、エンジニアがコードを書く前にデザインが解決されている状態こそが、我々が目指すべき聖域なのだ。

さあ、そのゾンビコンポーネントを削除して、組織の「正気」を取り戻そう。