Figma 素材管理術: チームで散らかさないライブラリ運用 7 ルール

Figma は便利な反面、 案件が増えるほど「コンポーネントが二重に存在する」「カラースタイルが 30 種類ある」「目的のファイルが探せない」 といった散らかりが必ず発生します。 1 人で使っているうちは気にならなくても、 チームで 100 ファイルを超えた頃には、 デザインの一貫性も検索性も崩壊しかねません。

この記事では、 個人 / チームのどちらでも破綻しないライブラリ運用 7 ルール、 コンポーネント設計の原則、 カラー・テキスト・バリアブルの管理方法、 チームライブラリの公開フロー、 月次棚卸しの手順、 そして書き出しアセットを Digift などの外部 DAM に集約する実務的な連携方法までを、 競合上位記事の論点を踏まえつつ独自視点で解説します。

なぜ Figma はすぐに散らかるのか

Figma のデフォルト状態は「自由に作れる白紙のキャンバス」 です。 だからこそクリエイティブが捗る一方、 整理ルールを決めずに使い続けると、 次のような散らかりが急速に進みます。

• 類似コンポーネントの乱立: Button / Button2 / Button-Final / BTN-OK のように同じ機能の派生が増殖する
• カラースタイル名の表記揺れ: Primary / primary / 青 / #0078b6 が同じ色を指す
• ページ階層の崩壊: Page 1 / Page 1 (Copy) / Untitled が並ぶ
• ファイル所有者の不明化: 退職メンバーが作ったファイルが孤児になる
• ライブラリの未更新: 古いコンポーネントを使い続けて修正が反映されない

散らかりは「個人の怠慢」 ではなく、 ガバナンスの不在によって発生します。 1 人の意識でなく仕組みで防ぐのが鉄則です。

管理対象は「ファイル」「ページ」「アセット」 の 3 層

Figma の整理を考えるとき、 一気に全部を扱おうとすると挫折します。 まず階層を 3 つに分け、 それぞれに別のルールを適用するのが効果的です。

多くの人が「コンポーネントを綺麗にしよう」 と考えがちですが、 ファイル層が散らかっていれば、 そもそもアセットが見つかりません。 上から順に整えるのが原則です。

ライブラリ運用 7 ルール

実務で破綻しないライブラリ運用には、 次の 7 ルールを最低ラインとして設定するのがおすすめです。

1. 1 プロダクト = 1 デザインシステムファイル: 全プロダクト共通の DS を持つ場合、 マスターを 1 ファイルにまとめてチームライブラリとして公開
2. 命名はプレフィックス + カテゴリ + 役割: 例 Btn / Primary / Default。 単独で見ても何のコンポーネントか分かる粒度
3. セクションで階層を視覚化: Section 機能を活用して「Buttons / Forms / Cards」 のグループを作る
4. カラーは Primitive と Semantic を分ける: color/blue/500 (Primitive) → color/text/link (Semantic)
5. バリアブルでブランド / ダークモードを 1 セットで管理: スタイルを増やさず、 モード切替で対応
6. ライブラリ更新は週次バッチ: 個別差分でなく週 1 でまとめて更新通知 → 採用者の負荷を下げる
7. 使われないコンポーネントは Archive ページへ: 削除でなく退避。 6 ヶ月使われなければ正式削除

この 7 ルールを書面化して、 新メンバーオンボーディングの最初の 15 分で説明するだけでも、 散らかり速度は劇的に減ります。

コンポーネント設計 4 原則

コンポーネントを「とにかく作って共有」 だけでは意味がありません。 設計の段階で次の 4 原則を意識すると、 後から修正が楽になります。

原則 1: バリアントは props として設計

色違い・サイズ違いは別コンポーネントにせず、 Variants の Properties として管理します。 後から CSS の prop 構造にもそのままマッピングしやすく、 エンジニアの実装コストも下がります。

原則 2: Auto Layout を最初から組み込む

手作業で配置したコンポーネントは、 文言が変わるたびにレイアウトが崩れます。 ボタン・カード・リスト系はすべて Auto Layout で組み、 Padding / Gap を Token 化しておけば、 後の修正が「数値を 1 か所変える」 だけで済みます。

原則 3: Boolean props で表示・非表示を切り替える

「アイコンあり / なし」 のような表示制御は Boolean Property で実装。 Show / Hide 切替で 2 種類を 1 つにまとめれば、 バリアント爆発を防げます。

原則 4: Description を必ず書く

コンポーネントの Description には「使う場面」 と「使ってはいけない場面」 を明記。 ライブラリパネルから検索した人が、 説明だけで採否を判断できる状態にするのが理想です。

カラー / テキストスタイル / バリアブルの管理

Figma のスタイル管理は「2 層構造」 で考えるのが定石です。

1. Primitive (原色 / 原フォント): blue/500 / font-size/16 のように数値ベースで定義
2. Semantic (意味): color/text/link / typography/body/m のように用途で定義

Semantic だけで運用すると、 ブランド色変更時に「全画面チェック」 が必要に。 一方 Primitive だけだと、 似たような色を毎回探す手間が増えます。 両方を持ち、 Semantic から Primitive を参照する構造にすると、 ブランド変更も意味の再設計も両方しやすくなります。

Figma のバリアブル (Variables) 機能を使えば、 ライト / ダークモード、 ブランド A / B などの切替を 1 セットの設計で実現できます。 スタイルを 2 倍に増やす必要がなくなり、 保守コストが激減します。

チームライブラリの公開と更新フロー

個人プランからチームプランに上げた瞬間に解放されるチームライブラリ機能。 ただし「公開すれば自動で皆が使う」 わけではなく、 運用フローが必要です。

推奨フロー

1. 変更提案: PR 的に「変更ブランチファイル」 を作り、 元ライブラリにコメントで提案
2. レビュー: ライブラリ管理担当者がレビュー (週 1 回まとめてが現実的)
3. マージ: 元ライブラリにマージ → 公開ボタンを押す
4. 通知: Slack / Chatwork に「今週の DS 変更まとめ」 を投稿
5. 適用: 利用者は消費ファイル側で「Updates」 を受け取り、 影響範囲を確認してから適用

利用者が「いきなり崩れた」 と困らないよう、 破壊的変更は非推奨マークを 2 週間置いてから削除する運用が現実的です。

ファイル命名規則とプロジェクト分割

Figma のファイル名は、 探すときの第一手段。 検索ボックスに何を入れたら 1 発で見つかるかを意識して設計します。

プロジェクトは「クライアント別 / 案件別」 で分割。 横断する DS / コンポーネント類は「Foundations」 などの専用プロジェクトに集約し、 他プロジェクトはそれを参照するだけにします。 これにより案件プロジェクトを退役させても DS は残せます。

月 1 回の棚卸しルーチン 6 ステップ

ライブラリは「作って終わり」 ではなく、 育てるものです。 月 1 回 1 時間の棚卸しを習慣化すると、 散らかりを防げます。

1. 使用率レポート: 主要コンポーネントの利用ファイル数を Figma の Library Analytics で確認
2. 利用ゼロのコンポーネント抽出: 3 ヶ月利用ゼロは Archive ページへ
3. 命名揺れチェック: 検索でヒットすべきだが出てこないものを修正
4. 色 / フォントの重複: スタイルパネルで近似値を統合
5. ドキュメント追記: 新規追加コンポーネントに Description を追加
6. レビュー会議 30 分: チームに「先月の変更」 を報告 + 提案を募集

Notion / Confluence など外部ドキュメントに「DS 議事録」 を残すと、 オンボーディングの説明素材としても再利用できます。

書き出しアセットを Digift で一元管理する

Figma 上の整理が完了したら、 次に課題になるのが書き出しアセットの管理です。 SVG / PNG / WebP / PDF などの最終ファイルが Slack や Google Drive に散らばってしまうと、 結局「ファイル探し」 が再発します。

ここで Digift のような DAM を使うと、 Figma → 書き出し → Digift にアップロード → タグとコレクションで分類、 という統一フローが組めます。 制作者が変わっても、 検索ですぐ過去案件のアセットを引っ張り出せる状態を維持できます。

推奨ワークフロー

1. Figma で「Export」 グループを必ず Auto Layout で配置 (再書き出しを楽に)
2. 命名規則 (例 [案件コード]_[画面]_[要素]_[サイズ].svg) を Figma 上で予約
3. 書き出し後、 Digift に D&D で一括アップロード。 案件コードを Collection として作成し、 タグで色 / 用途を補足
4. クライアント納品時はその Collection からまとめてダウンロード or 共有リンクを発行

Figma の中身を綺麗にすることと、 書き出した結果のアセットを綺麗にすることは別問題です。 両方を仕組み化して初めて、 制作スピードと検索性が継続的に維持できます。

よくある失敗 5 パターン

• 1. デザインシステムを作るが、 案件が反映しない: 採用率を上げる工夫 (週次変更通知 / オンボーディング講座) が必要
• 2. 命名規則を作るが、 守られない: チェックリストを PR レビュー的に運用、 自動ツール (Figma Plugin の Naming Lint) も併用
• 3. ライブラリ公開後に頻繁に破壊的変更: 「非推奨マーク → 2 週間 → 削除」 の段階を作る
• 4. アーカイブせずに削除: 過去案件で再利用する可能性があるため、 削除より退避を優先
• 5. 個人プランで使い続け、 チームライブラリが共有できない: メンバーが 3 名超えたらチームプランに上げる

よくある質問

Q1. デザインシステムは何人から作るべき?

A. 1 人でも作る価値があります。 ただし規模により粒度を調整。 1 人 → Primitive + Semantic スタイル + 5 コンポーネント。 3〜5 人 → 上記 + ライブラリ公開。 10 人超 → 専任の DS チーム設置を検討。

Q2. Figma の有料プランは必要?

A. 個人プランでも基本機能は使えますが、 チームライブラリ・バリアブル・無制限ファイル等はプロ / 有料以上。 3 名以上のチームでは費用対効果が高いです。

Q3. 書き出し時に WebP / SVG どちらを優先すべき?

A. 写真系は WebP (圧縮率と画質のバランス)、 ロゴ / アイコン系は SVG (拡大縮小に強い)。 詳細は「WebP 変換完全ガイド」 を参照。

Q4. Figma と Sketch・Adobe XD の併用は?

A. 同一プロジェクトで併用すると同期コストが高く、 推奨しません。 移行を決めたら一斉に切替が現実的。

Q5. ファイル数が 1000 を超えたら?

A. Figma 単体の管理では限界。 案件プロジェクトと DS プロジェクトを分け、 退役プロジェクトは Read-only に。 書き出しアセットは外部 DAM (Digift など) に集約することで、 Figma 自体の負荷も減ります。

まとめ

Figma の素材管理は、 個人スキルでなく仕組みで支えるものです。 7 ルール・4 原則・棚卸しルーチン・命名規則の 4 本柱を導入し、 月 1 時間の棚卸しを継続できれば、 100 ファイル超のチームでも散らかりません。

そして Figma の中身を整理した上で、 書き出した最終アセットは Digift のような DAM に集約することで、 「過去案件のアセットを探す時間」 がほぼゼロになります。 デザインシステムの構築と並行して、 アセット管理の仕組みも整えることをおすすめします。

無料で Digift を試す ことができます。 Figma の書き出しアセットを集約したい方は、 まず無料プランで使い心地を確認してみてください。