Figmaライブラリ構造とは？大規模デザインシステムを支える設計・命名・運用方法

Figmaでデザインシステムを構築するとき、コンポーネントを作成するだけでは、長期的に利用できるライブラリにはなりません。ファイル、ページ、コンポーネント、変数、スタイル、ドキュメントをどのような階層で配置するかによって、検索性、更新速度、再利用性、権限管理が大きく変わります。小規模な段階では問題が見えなくても、コンポーネント数や利用チームが増えると、ライブラリ構造の違いが作業効率に直接影響します。

適切に設計されたFigmaライブラリでは、利用者が必要な部品を短時間で発見でき、設計者は変更の影響範囲を予測できます。一方、ファイルやページの役割が曖昧なライブラリでは、似たコンポーネントが複数作られ、古い部品が残り、どれを使うべきか判断できなくなります。ライブラリ構造は、見た目を保存する箱ではなく、チームの設計判断を共有する仕組みとして考える必要があります。

本記事では、Figmaライブラリ構造とは何かという定義から、ファイル分割、ページ設計、コンポーネント階層、バリアント、変数、公開設定、更新管理、品質確認まで詳しく解説します。単にきれいに並べることではなく、利用者が迷わず、管理者が安全に変更できる状態を作ることが目的です。

1. Figmaライブラリ構造とは

Figmaライブラリ構造とは、再利用可能なコンポーネント、スタイル、変数、アイコン、説明資料を、一定の規則に基づいて配置する設計全体を指します。どのファイルに何を置くか、どの単位で公開するか、どの名前で検索できるようにするかまで含まれます。

1.1 ライブラリ構造が担う役割

Figmaライブラリ構造の第一の役割は、デザイン資産の所在を明確にすることです。ボタン、入力欄、カード、ナビゲーションなどが決められた場所に配置されていれば、利用者は新しい部品を作る前に既存の選択肢を確認できます。結果として、同じ目的のコンポーネントが重複して作られる状況を減らせます。

第二の役割は、変更の責任範囲を明確にすることです。基礎色、共通部品、製品固有の部品を分離しておけば、変更がどの範囲へ影響するか判断しやすくなります。すべてを一つのファイルへ集約すると、便利に見える一方で、小さな変更でも多くの利用画面に影響する可能性があります。

1.2 ファイルを並べることとの違い

単にファイルをカテゴリ別に並べるだけでは、ライブラリ構造とはいえません。ファイル名が分かりやすくても、公開対象、更新担当者、依存関係、利用対象が定義されていなければ、運用中に判断がばらつきます。構造には配置だけでなく、管理規則が必要です。

たとえば「UI Components」という一つのファイルへすべてを追加すると、初期段階では検索しやすく見えます。しかし、基礎コンポーネントと製品固有コンポーネントが混在すると、他の製品で再利用してよい部品か判断できません。分類名だけでなく、再利用範囲と責任を設計することが重要です。

1.3 小規模ライブラリと大規模ライブラリ

小規模なプロジェクトでは、一つのファイルに変数、スタイル、コンポーネントをまとめても運用できます。利用者が少なく、部品数も限定されているため、複雑な分割を行うと管理コストの方が大きくなる場合があります。

大規模な組織では、複数製品、複数ブランド、複数テーマを扱う可能性があります。そのため、基礎値、共通コンポーネント、ブランド別設定、製品固有部品を分離しなければなりません。規模に合わない構造を選ぶと、過剰な複雑さか、過剰な集中のどちらかが起こります。

1.4 ライブラリ利用者と管理者の視点

利用者にとって重要なのは、目的の部品を素早く見つけ、正しい設定で配置できることです。検索結果に似た名前のコンポーネントが多数表示されると、どれを選ぶべきか分かりません。そのため、名前、カテゴリ、説明、プロパティの分かりやすさが重要になります。

管理者にとって重要なのは、変更の影響範囲と公開状態を把握できることです。どのコンポーネントが公開され、どの部品が他の部品から参照されているかを理解できなければ、安全に修正できません。優れた構造は、利用しやすさと管理しやすさの両方を満たします。

1.5 良いライブラリ構造の判断基準

良いライブラリ構造は、ファイル数が少ないことや、ページがきれいに並んでいることだけでは判断できません。利用者が必要な部品を発見できるか、誤った部品を選びにくいか、更新内容を理解できるかという実際の利用結果が重要です。

また、構造は固定された完成形ではありません。製品、チーム、ブランド、コンポーネントが増えたときに、既存のルールを壊さず拡張できる必要があります。現在の見た目だけでなく、将来追加される要素の置き場所まで想定します。

2. Figmaライブラリのファイル構成

Figmaライブラリのファイル構成では、すべてを一つへ集約する方法と、役割ごとに複数ファイルへ分割する方法があります。適切な構成は、製品数、利用者数、公開頻度、権限、依存関係によって変わります。

2.1 単一ファイル構成

単一ファイル構成では、色、文字、アイコン、コンポーネント、説明を一つのファイルで管理します。小規模な製品や、管理者が限定されているチームでは、移動や検索が少なく、全体を把握しやすいという利点があります。

一方、内容が増えると読み込みが重くなり、公開変更の確認範囲も広がります。アイコンだけを更新した場合でも、同じファイルに含まれる多数のコンポーネント変更と一緒に確認しなければならない可能性があります。

2.2 複数ファイル構成

複数ファイル構成では、基礎値、アイコン、共通コンポーネント、製品固有コンポーネントなどを別々のファイルへ分けます。変更担当者や公開頻度が異なる領域を分離できるため、大規模チームに適しています。

ただし、ファイル間の依存関係が増えるため、下位ファイルから上位ファイルを一方向に参照する規則が必要です。相互参照が発生すると、更新順序や公開タイミングが複雑になり、変更の影響を把握しにくくなります。

2.3 基礎ファイルとコンポーネントファイル

基礎ファイルには、色、余白、角丸、文字サイズなどの変数やスタイルを配置します。画面上で直接利用する完成部品ではなく、他のコンポーネントが参照する値を中心に管理します。

コンポーネントファイルには、ボタンや入力欄など、デザイナーが画面へ配置する部品を置きます。基礎ファイルと分けることで、値の変更と部品構造の変更を別々に管理できます。

ファイル依存関係の例

01 Foundations   ├─ Color variables   ├─ Spacing variables   ├─ Typography styles   └─ Radius variables 02 Icons   └─ Icon components 03 Components   ├─ Actions   ├─ Inputs   ├─ Navigation   └─ Feedback 04 Product Components   ├─ Commerce   ├─ Account   └─ Administration

2.4 製品別ファイルを分ける判断

製品固有コンポーネントは、共通ライブラリとは別ファイルに置くことで、他の製品から誤って利用されることを防げます。特定の業務フローやデータ構造に依存する部品は、共通部品として公開しても再利用できない場合があります。

ただし、製品別ファイルが増えすぎると、同じ目的の部品が各製品で作られる可能性があります。新しい部品を追加する前に、共通化できる基礎部分と製品固有部分を分けられないか検討します。

2.5 ファイル名の付け方

ファイル名には、内容、階層、公開対象が判断できる情報を含めます。単に「Components」だけでは、共通部品なのか製品固有部品なのか分かりません。「Design System / Components / Core」のように、体系と役割を示す方法があります。

順序を固定したい場合は番号を付けることもできます。ただし、番号だけで意味を表すのではなく、名称と組み合わせます。組織名や製品名を付ける場合も、長くなりすぎないようにします。

3. ページ階層の作り方

Figmaファイル内のページは、コンポーネントを配置する場所だけではありません。公開対象、説明、作業中、非推奨など、目的の異なる内容を分ける単位として利用できます。

3.1 公開ページと作業ページを分ける

公開対象のコンポーネントと、検討中の案を同じページに置くと、どれが正式な部品か判断しにくくなります。公開ページには、利用可能な状態まで確認されたコンポーネントだけを配置します。

作業ページには、試作、比較案、検証中の部品を置きます。ページ名に「作業中」「検証中」などを付けることで、利用者が誤って参照する可能性を減らせます。

3.2 カテゴリ別ページを作る

コンポーネント数が増えた場合、操作、入力、ナビゲーション、通知などのカテゴリでページを分ける方法があります。各ページの内容が限定されるため、管理者が該当領域を確認しやすくなります。

一方、ページを細かく分けすぎると、関連するコンポーネントを行き来して確認しなければなりません。カテゴリごとの部品数と更新頻度を見ながら、ページ単位を決めます。

3.3 ページ名に状態を含める

ページ名の先頭へ記号や状態を付けると、現在の用途を一覧から判断できます。たとえば、公開中、作業中、非推奨を示す一定の接頭辞を使う方法があります。

ただし、記号だけに依存すると意味が共有されていない利用者には伝わりません。記号と文字を組み合わせ、チーム内の命名規則として文書化します。

ページ名の例

✅ Published / Actions ✅ Published / Inputs 🟡 Work in Progress 📘 Documentation ⚠ Deprecated 🧪 Experiments

3.4 説明ページを設ける

説明ページには、ライブラリの利用対象、ファイル依存関係、命名規則、更新手順、問い合わせ先を記載します。初めてファイルを開いた利用者が、どこから確認すべきか分かる状態を作ります。

説明を外部文書だけに置くと、Figmaファイルを利用している途中で参照されにくくなります。重要なルールはファイル内にも短く記載し、詳細文書へのリンクを用意します。

3.5 非推奨ページの扱い

古いコンポーネントをすぐに削除すると、既存画面の参照が切れたり、移行前の利用者が困ったりする可能性があります。そのため、一定期間は非推奨ページへ移し、新しい部品への置き換え方法を記載します。

非推奨ページへ移しただけでは、利用停止は進みません。コンポーネント名、説明、公開設定で非推奨であることを明示し、削除予定日と移行先を示します。

4. コンポーネント階層の設計

コンポーネント階層では、小さな部品をどの範囲で組み合わせ、どこまでを一つの再利用単位として公開するかを決めます。階層が深すぎても浅すぎても、変更しにくいライブラリになります。

4.1 基礎部品を定義する

基礎部品には、ボタン、入力欄、アイコン、ラベルなど、複数の画面や複合コンポーネントから利用される要素を置きます。用途が広いため、製品固有の情報や配置条件を含めすぎないことが重要です。

基礎部品を細かく分けすぎると、利用者が毎回多数の部品を組み合わせなければなりません。再利用性だけでなく、実際の配置作業に必要な操作量も考慮します。

4.2 複合コンポーネントを作る

検索欄、フォーム項目、カードヘッダーなど、複数の基礎部品が一定の規則で組み合わされる場合は、複合コンポーネントとして提供できます。これにより、余白や配置のばらつきを減らせます。

ただし、複合コンポーネントへ多くの条件を追加すると、すべての画面要件を一つで処理しようとして複雑になります。共通する構造が十分に安定しているか確認してから作成します。

4.3 入れ子を深くしすぎない

多数の入れ子コンポーネントを使用すると、上位インスタンスから変更できる項目が分かりにくくなります。内部の一部を変更するために、複数階層を開かなければならない構造は、利用者の作業を遅くします。

入れ子にする前に、再利用される単位か、独立した責任を持つかを確認します。単なる装飾用フレームまでコンポーネント化すると、管理対象が増えるだけになる場合があります。

4.4 部品と画面パターンを分ける

ボタンや入力欄は、画面を越えて再利用される部品です。一方、商品検索ヘッダーや注文確認欄は、特定の画面構成を再現するためのパターンです。両者を同じカテゴリへ置くと、再利用範囲が分かりにくくなります。

画面パターンは、設計開始時のひな型として有効ですが、すべての内部要素を固定するべきではありません。基礎コンポーネントを入れ子にし、利用場面に応じて内容を変更できる状態を作ります。

4.5 内部部品の公開範囲

複合コンポーネントの内部でのみ使う小部品を、一般利用者へ公開すると、検索結果に不要な部品が増えます。内部部品が単独で使われる可能性がない場合は、公開対象から外すことを検討します。

ただし、内部部品を完全に閉じると、他のコンポーネントで同じ構造が必要になったときに重複が起こる場合があります。単独利用の可能性と、利用者が誤用する可能性の両方を考えます。

5. バリアントとコンポーネントプロパティ

Figmaのバリアントとコンポーネントプロパティは、同じ部品の状態、種類、内容を切り替えるために利用します。設計軸を適切に分けなければ、組み合わせ数が急増します。

5.1 バリアント軸を決める

バリアント軸には、役割、寸法、表示形式、状態など、互いに排他的な選択肢を設定します。ボタンであれば、主要、補助、危険という役割と、小、中、大という寸法を別軸にできます。

役割と寸法を一つの値へまとめると、Primary SmallやDanger Largeのような組み合わせを個別に作らなければなりません。異なる意味を持つ条件は別の軸として定義します。

5.2 真偽値プロパティを使う

アイコン表示、区切り線、補助文など、存在するかどうかを切り替える条件には真偽値プロパティが適しています。バリアントとして「アイコンあり」「アイコンなし」を作るより、利用側で一つの切り替えとして扱えます。

ただし、複数の真偽値が互いに排他的な場合は注意が必要です。「左配置」と「右配置」を別々の真偽値にすると、両方が有効になる可能性があります。この場合は、一つの選択プロパティにします。

5.3 テキストプロパティを使う

ラベル、補助文、件数など、利用側が文字内容を変更する要素にはテキストプロパティを使用します。内部レイヤーを直接選択せずに内容を変更できるため、操作が簡単になります。

テキストプロパティ名は、表示内容の役割を表す名前にします。「Text 1」「Text 2」ではなく、「ラベル」「補助文」「件数」のように、どの情報を変更するか分かる名前を付けます。

5.4 インスタンス交換を使う

アイコンや小さな付属部品を変更する場合は、インスタンス交換を利用できます。利用者は内部構造を分解せず、許可されたコンポーネントから選択できます。

交換対象を広く設定しすぎると、意図しない部品が挿入される可能性があります。交換候補となるコンポーネントのカテゴリ、寸法、用途を揃えます。

プロパティ構成例

Button ├─ Role: Primary | Secondary | Danger ├─ Size: Small | Medium | Large ├─ State: Default | Disabled | Loading ├─ Show leading icon: True | False ├─ Show trailing icon: True | False ├─ Label: Text property ├─ Leading icon: Instance swap └─ Trailing icon: Instance swap

5.5 バリアント数を抑える

バリアント数は、各軸の選択肢を掛け合わせた数だけ増えます。役割4種類、寸法3種類、状態4種類、アイコン配置3種類なら、理論上144種類の組み合わせになります。

すべての組み合わせが必要とは限りません。アイコンの表示は真偽値や交換プロパティで処理し、状態によって変化する装飾は変数やプロパティで制御することで、バリアント数を抑えられます。

6. 変数とスタイルの構造

Figmaの変数とスタイルは、色、寸法、文字、効果などの一貫性を保つために使います。値の階層と用途を決めることで、テーマ変更やブランド変更へ対応しやすくなります。

6.1 基礎変数を作る

基礎変数には、青500、灰100、間隔16、角丸8など、具体的な値を定義します。これらはUI上の意味ではなく、デザインで利用できる値の集合として扱います。

基礎変数を直接すべてのコンポーネントへ適用すると、用途変更時に多くの参照先を修正する必要があります。そのため、基礎変数の上に用途を表す変数を設ける方法が有効です。

6.2 意味変数を作る

意味変数には、背景、本文文字、主要操作、危険表示など、UI上の用途を示す名前を付けます。実際の値は基礎変数を参照します。

主要操作の色が青から別の色へ変わっても、コンポーネントは「主要操作背景」という変数を参照し続けられます。具体値と利用目的を分けることで、変更範囲を限定できます。

6.3 コレクションを分ける

変数コレクションは、色、寸法、角丸、文字値などの責任ごとに分ける方法があります。すべてを一つのコレクションへ入れると、モードや公開対象を管理しにくくなります。

一方、細かく分けすぎると、参照場所が増えます。値の更新担当者、モードの有無、利用範囲が同じものを一つのコレクションとして扱います。

6.4 モードでテーマを管理する

ライトテーマ、ダークテーマ、ブランド別テーマなどは、変数モードによって管理できます。同じ意味変数に対してモードごとの値を設定するため、コンポーネントの構造を複製する必要がありません。

モード名には、利用場面を明確に表す名前を付けます。「Mode 1」「Mode 2」のような名称では、どの画面で使うか判断できません。

トークンJSONの例

{  "color": {    "surface": {      "default": {        "light": "#FFFFFF",        "dark": "#111827"      },      "subtle": {        "light": "#F3F4F6",        "dark": "#1F2937"      }    },    "text": {      "default": {        "light": "#111827",        "dark": "#F9FAFB"      }    }  } }

6.5 文字スタイルと変数の役割

文字スタイルは、フォント、太さ、サイズ、行間などを一つの組み合わせとして適用する場合に便利です。見出し、本文、注釈など、文章上の役割に基づいて定義します。

変数は、文字サイズや行間などの個別値を管理する場合に利用できます。スタイルと変数のどちらかへ無理に統一せず、利用者の操作と実装連携に合う形を選びます。

7. 命名規則の作り方

命名規則は、ライブラリの検索性と理解速度を左右します。名前から用途、階層、状態が判断できる構造を作ることで、利用者の選択ミスを減らせます。

7.1 スラッシュでカテゴリを表す

Figmaでは、コンポーネント名にスラッシュを含めることで、アセットパネル上のカテゴリを作れます。「Actions/Button」「Inputs/Text Field」のように、上位カテゴリから具体的な部品へ進む構造にします。

階層を深くしすぎると、目的の部品へ到達するまでの操作が増えます。通常は二階層から三階層程度で理解できる名前を目指します。

命名例

Actions/Button Actions/Icon Button Actions/Menu Item Inputs/Text Field Inputs/Select Inputs/Checkbox Feedback/Alert Feedback/Toast Feedback/Progress

7.2 部品名と状態名を分ける

コンポーネント名に状態を含めて別部品として作ると、「Button Default」「Button Disabled」「Button Loading」が検索結果に並びます。これらは同じ部品の状態であるため、バリアントとしてまとめる方が適しています。

名前には部品の種類を表し、状態や寸法はプロパティで選択できるようにします。検索結果を減らし、利用者が一つのコンポーネントから必要な状態を選べる構造にします。

7.3 略語を制限する

チーム内で意味が統一されていない略語を使うと、新しい利用者が名前を理解できません。「Btn」「Cmp」「Nav」などは短くできますが、検索語と一致しない場合があります。

一般的に認識されている略語だけを許可し、業務固有の略語は一覧を用意します。ファイル名とコンポーネント名で異なる略語を使わないことも重要です。

7.4 日本語名と英語名を選ぶ

利用チームが日本語中心であれば、日本語名は理解しやすい選択肢です。一方、実装コード、外部資料、複数国のチームと連携する場合は、英語名の方が対応関係を作りやすい場合があります。

重要なのは、同じ階層で日本語と英語を無計画に混在させないことです。部品名は英語、説明文は日本語など、利用目的ごとに規則を決めます。

7.5 命名を自動確認する

コンポーネント数が増えると、手作業の確認だけでは命名のばらつきを防げません。FigmaのプラグインAPIや外部スクリプトを利用し、命名規則に合わない項目を検出する方法があります。

完全な自動修正よりも、違反箇所を一覧化して担当者が確認できる仕組みが安全です。既存の参照や公開名へ影響するため、名前変更は慎重に行います。

名前を確認するコード例

const allowedPrefixes = [  "Actions/",  "Inputs/",  "Navigation/",  "Feedback/",  "Data Display/", ]; function hasAllowedPrefix(name: string): boolean {  return allowedPrefixes.some((prefix) =>    name.startsWith(prefix),  ); } const invalidComponents = figma.root  .findAllWithCriteria({    types: ["COMPONENT", "COMPONENT_SET"],  })  .filter((node) => !hasAllowedPrefix(node.name)); console.log(  invalidComponents.map((node) => node.name), );

8. ローカルコンポーネントと共有ライブラリの違い

ローカルコンポーネントと共有ライブラリは、作成場所だけでなく、変更責任、公開範囲、更新方法が異なります。どちらを利用するかは、再利用範囲と安定性によって判断します。

8.1 利用範囲の違い

ローカルコンポーネントは、現在のファイル内で利用する部品です。特定の画面だけで使う構造や、検証中の案に適しています。

共有ライブラリのコンポーネントは、複数のファイルやチームから利用されます。公開後の変更が多数の画面へ影響するため、安定性と説明が必要です。

8.2 更新方法の違い

ローカルコンポーネントは、元コンポーネントの変更が同じファイル内のインスタンスへ反映されます。更新の承認操作が少なく、素早く変更できます。

共有ライブラリでは、管理者が変更を公開し、利用側が更新を受け取ります。変更内容を確認してから適用できる一方、利用側に古いバージョンが残る可能性があります。

8.3 安定性の違い

ローカルコンポーネントは、検討中の構造や画面固有の変更を含めても、影響範囲が限定されています。そのため、試行錯誤を行いやすい環境です。

共有コンポーネントは、名前、プロパティ、レイヤー構造を変更すると、多数の利用画面に影響する場合があります。公開前に利用例、例外、既存画面との互換性を確認します。

8.4 共有へ移す判断

同じ部品が複数ファイルで繰り返し作られている場合、共有ライブラリへの移行を検討できます。ただし、見た目が似ているだけで、利用目的や内部情報が異なる場合は共通化できないことがあります。

少なくとも複数の実際の利用例を確認し、共通部分と変更可能部分を判断します。一つの画面だけを基準に共有部品を作ると、後から多数の例外が追加されます。

8.5 共通化しすぎる問題

すべての部品を共有ライブラリへ移すと、検索結果が増え、利用者が選びにくくなります。さらに、小さな製品固有変更まで中央チームの確認が必要になり、開発速度が落ちる可能性があります。

共通ライブラリには、複数の利用者が同じ判断を繰り返さずに済む部品を置きます。画面固有の配置や一時的な試作は、ローカルに残す方が管理しやすい場合があります。

9. ライブラリ公開の設計

ライブラリ公開では、どのコンポーネント、スタイル、変数を利用者へ提供するかを管理します。作成したすべての要素を公開する必要はありません。

9.1 公開対象を選ぶ

利用者が直接配置する部品や、複数ファイルから参照する値を公開対象にします。内部構造を構成するだけの部品や、作業中の要素は公開しない方が検索性を保てます。

公開対象を増やすほど、互換性を維持する責任も増えます。一度公開した要素は、既存画面から参照される可能性があるため、削除や名前変更が難しくなります。

9.2 公開前の確認項目

公開前には、名前、説明、プロパティ、変数参照、オートレイアウト、制約、アクセシビリティ上の表現を確認します。見た目だけでなく、利用者が内容を変更したときに崩れないかも確認します。

長い文字列、アイコンなし、補助文あり、狭い幅など、標準例以外の条件でも確認します。公開後の修正回数を減らすには、利用場面に近い条件での検証が必要です。

9.3 変更内容を書く

公開時の変更説明には、何が変わったか、なぜ変わったか、利用側で何を確認すべきかを記載します。「ボタンを更新」のような説明では、影響を判断できません。

プロパティ名の変更、既定値の変更、寸法変更など、利用画面へ影響する内容は具体的に書きます。移行操作が必要な場合は、手順も示します。

9.4 小さな変更と大きな変更を分ける

色値の微調整と、コンポーネント構造の変更では、利用側への影響が異なります。変更の大きさに応じて、確認者、告知方法、公開タイミングを変えます。

大きな変更を多数の小さな公開へ分割すると、利用者が何度も更新を受け取ることになります。関連する変更は一つの更新としてまとめる一方、影響範囲が大きすぎる場合は段階的に移行します。

9.5 公開後の反映を確認する

公開が完了しても、利用ファイルが自動的に最新状態になるとは限りません。利用者が更新を確認し、適用する必要があります。

重要な変更では、主要な製品ファイルで更新が反映されたか確認します。古いバージョンが残る場合は、対象チームへ案内し、期限を設けます。

10. 更新履歴と版管理

ライブラリは継続的に変更されるため、現在の状態だけでなく、どのような変更が行われたかを追跡できる必要があります。更新履歴は利用者の判断と問題調査を支えます。

10.1 更新単位を決める

関連する複数の変更を一つの更新として公開するか、部品ごとに分けるかを決めます。細かすぎる更新は利用者の確認負荷を増やし、大きすぎる更新は影響範囲を分かりにくくします。

同じ目的を持つ変更や、同時に適用する必要がある変更はまとめます。独立して安全に公開できる修正は、別の更新として扱えます。

10.2 変更履歴ページを作る

Figmaファイル内に変更履歴ページを設けると、利用者が過去の更新を確認できます。日付、対象、変更内容、移行の必要性、担当者を記載します。

履歴が長くなった場合は、最新の重要変更だけをファイル内に残し、詳細は外部文書へ移す方法があります。利用者が確認すべき情報を先頭に置きます。

変更履歴の例

2026-07-24 対象: Actions/Button 変更: Sizeプロパティの既定値をMediumへ統一 影響: 既存インスタンスの表示変更なし 対応: 新規配置時の既定寸法を確認 2026-07-10 対象: Inputs/Text Field 変更: Error Messageをテキストプロパティ化 影響: 内部レイヤー名を変更 対応: 切り離したインスタンスは手動確認

10.3 破壊的変更を扱う

プロパティの削除、名前変更、内部部品の置き換えなどは、既存インスタンスへ大きな影響を与える可能性があります。破壊的変更は、通常の装飾修正とは別に扱います。

新しいコンポーネントを追加し、旧版を一定期間残す方法が安全です。利用状況を確認しながら移行を進め、旧版の削除日を事前に告知します。

10.4 分岐を利用する

大きな変更や複数人での作業では、元ファイルへ直接変更せず、分岐上で作業する方法があります。公開中のライブラリを安定させたまま検証できます。

分岐を長期間残すと、元ファイルとの差分が大きくなり、統合が難しくなります。変更範囲と確認期限を決め、必要な作業だけを分岐で行います。

10.5 復元できる状態を保つ

公開後に重大な問題が見つかった場合、以前の状態へ戻せる必要があります。変更内容、公開日時、担当者が記録されていれば、問題の原因を確認しやすくなります。

復元だけに頼らず、公開前に主要コンポーネントの複製や検証用画面を用意する方法もあります。変更前後を比較できる状態を作ることで、差分を発見しやすくなります。

11. 権限と管理責任

Figmaライブラリでは、誰が編集し、誰が公開し、誰が利用するかを決める必要があります。権限が広すぎると意図しない変更が起こり、狭すぎると更新が停滞します。

11.1 編集者を限定する

ライブラリファイルの編集権限は、構造と公開ルールを理解している担当者へ限定します。すべての利用者が編集できる状態では、命名や変数参照が意図せず変更される可能性があります。

利用者からの改善提案は、コメント、依頼フォーム、専用チャンネルなどで受け付けます。編集権限を限定しても、提案経路がなければライブラリが実際の要件から離れてしまいます。

11.2 公開責任者を決める

編集できる人と公開できる人を同じにするか、別にするかを決めます。小規模チームでは同じ担当者でも運用できますが、大規模な共通ライブラリでは公開前の確認者を設ける方法があります。

公開責任者は、見た目だけでなく、命名、プロパティ、利用影響、移行案内まで確認します。単なる承認操作ではなく、公開品質を守る役割として定義します。

11.3 領域ごとの担当者を置く

一人の管理者がすべての領域を担当すると、確認待ちが増えます。入力、ナビゲーション、データ表示など、カテゴリごとに担当者を置く方法があります。

領域担当者が独自の規則を作らないように、全体の命名、変数、公開規則は共通化します。専門性と一貫性の両方を維持する必要があります。

11.4 変更依頼の形式を決める

変更依頼には、問題、利用場面、現在の代替方法、希望する変更、影響画面を含めます。「新しいカードが欲しい」だけでは、既存部品で対応できるか判断できません。

実際の画面例や利用件数があると、優先度を決めやすくなります。依頼者が解決方法まで決めるのではなく、解決したい問題を中心に記載します。

11.5 緊急変更の手順を作る

重大な表示問題やブランド上の問題が見つかった場合、通常の確認工程を待てないことがあります。そのため、緊急変更を誰が判断し、どの範囲まで省略できるかを決めます。

緊急変更後は、通常の確認を後から実施し、変更履歴を残します。緊急対応を理由に説明や検証を省略したままにすると、同じ問題が再発します。

12. ドキュメントの構造

コンポーネントを正しく作っても、利用条件が伝わらなければ誤用されます。ドキュメントは、部品の説明だけでなく、判断基準を共有するために必要です。

12.1 コンポーネント説明を書く

コンポーネント説明には、何のために使うか、どの場面で使わないか、主要なプロパティ、関連部品を記載します。見た目を説明するだけでは、利用者が選択できません。

説明文は長すぎると読まれないため、Figma上には重要点を短く記載し、詳細文書へつなげます。最初の一文で目的が分かる内容にします。

12.2 利用例を載せる

正しい利用例を画面に近い状態で示すと、部品単体だけを見るより理解しやすくなります。主要ボタンと補助ボタンの配置関係など、複数部品の関係も示せます。

利用例をそのまま複製して使えるようにする場合は、古くならないよう管理が必要です。例が旧コンポーネントを参照したままだと、誤った使い方を広めます。

12.3 禁止例を載せる

禁止例は、利用者が起こしやすい誤りを具体的に示します。主要ボタンを同じ画面に多数配置する、エラー表示を色だけで伝えるなど、判断が分かれやすい場面に有効です。

単に禁止マークを付けるのではなく、なぜ問題なのか、代わりに何を使うかを記載します。理由が理解されれば、別の場面でも正しく判断できます。

12.4 判断の流れを示す

似た部品が複数ある場合、どれを選ぶか判断する流れを示します。通知とトースト、モーダルとドロワーなど、用途が近い部品では特に重要です。

判断の流れは、利用者が持っている情報から選べる形にします。「重要ならモーダル」のような曖昧な基準ではなく、操作を止める必要があるか、確認が必要かなど、具体的な条件を使います。

12.5 問い合わせ先を明示する

利用者が判断できない場合や、新しい要件がある場合の問い合わせ先を記載します。担当者名だけでは異動や休暇で連絡できなくなるため、チームや専用チャンネルを案内します。

問い合わせ内容が蓄積されたら、頻繁に質問される内容をドキュメントへ反映します。質問数は、説明不足や構造上の分かりにくさを示す情報として利用できます。

13. 品質を確認する方法

ライブラリ品質は、コンポーネントが見た目どおり表示されることだけでは判断できません。内容変更、寸法変更、テーマ変更、更新適用など、実際の利用条件で確認します。

13.1 検証用ページを作る

検証用ページには、各コンポーネントのバリアント、寸法、状態を一覧表示します。変更前後の差を確認しやすくなり、公開前の見落としを減らせます。

検証用ページは公開部品を参照する形にし、複製した見本だけを置かないようにします。元コンポーネントと見本が別々に更新される状況を防ぎます。

13.2 長い文字列を確認する

英語、日本語、数値、長い名称など、文字内容によってコンポーネントの幅や高さは変化します。短い見本だけで確認すると、実際の画面で崩れる可能性があります。

ボタン、タブ、入力補助文、通知などに長い文字を入れ、折り返し、切り捨て、最小幅を確認します。多言語対応する製品では、文字量の増加も考慮します。

13.3 可変幅を確認する

コンポーネントが固定幅だけで作られていると、異なる画面幅で利用しにくくなります。最小幅、最大幅、内容に合わせる幅、親に合わせる幅を確認します。

オートレイアウトの設定だけでなく、入れ子コンポーネントの伸縮設定も確認します。内部の一要素が固定幅になっていると、上位を広げても追従しないことがあります。

13.4 テーマごとに確認する

変数モードを利用している場合は、すべての主要テーマでコンポーネントを確認します。背景と文字の組み合わせ、境界線、無効状態、フォーカス表示などが対象です。

一つのテーマで見える装飾が、別のテーマでは背景へ埋もれることがあります。単に変数が切り替わるかではなく、情報の区別が維持されているか確認します。

13.5 自動検査を導入する

プラグインやスクリプトを利用し、未接続の色、命名違反、説明不足、不要な公開要素を検出できます。人による確認の前に機械的な問題を減らせます。

自動検査は、設計の正しさを完全に判断できるものではありません。利用目的、文章の分かりやすさ、操作上の自然さは、人が実際の画面で確認する必要があります。

未接続色を検出する考え方

const paintNodes = figma.root.findAll(  (node): node is SceneNode & GeometryMixin =>    "fills" in node, ); const nodesWithRawSolidColor = paintNodes.filter((node) => {  if (node.fills === figma.mixed) {    return false;  }  return node.fills.some(    (paint) =>      paint.type === "SOLID" &&      !paint.boundVariables?.color,  ); }); console.log(  nodesWithRawSolidColor.map((node) => node.name), );

14. チーム運用の流れ

Figmaライブラリを維持するには、設計者だけでなく、利用者、開発者、製品担当者が共通の流れで変更へ参加する必要があります。

14.1 要望を収集する

ライブラリへの要望は、個別の会話だけで受け取らず、記録できる場所へ集約します。利用場面、困っていること、対象画面、必要時期を記載します。

同じ要望が複数チームから出ている場合は、共通化の優先度が高い可能性があります。一方、一つの画面だけの例外は、製品側で対応した方が早い場合があります。

14.2 設計案を検証する

新しいコンポーネントを正式に追加する前に、実際の画面で試します。単体の見本だけでは、周辺部品との関係や情報量への対応を確認できません。

複数の異なる画面で利用できるかを確認すると、必要なプロパティと不要な自由度が見えてきます。一つの事例だけで設計を固定しないことが重要です。

14.3 開発者と対応関係を確認する

Figmaのコンポーネント名、プロパティ、変数名を実装側と近づけると、設計から開発への受け渡しが分かりやすくなります。ただし、Figmaとコードの構造を完全に同一にする必要はありません。

開発側で実現できないプロパティや、実装上は別コンポーネントとして扱う必要がある要素を事前に確認します。公開後に構造を大きく変えるより、設計段階で差を把握する方が安全です。

対応表の例

type ButtonProps = {  role?: "primary" | "secondary" | "danger";  size?: "small" | "medium" | "large";  loading?: boolean;  disabled?: boolean;  leadingIcon?: React.ReactNode;  trailingIcon?: React.ReactNode; };

14.4 利用者へ告知する

新しい部品や重要な変更を公開した場合は、対象者へ変更内容を伝えます。更新が存在することだけでなく、どの場面で利用するか、既存部品から移行が必要かを説明します。

告知先を増やしすぎると、重要な変更が埋もれます。専用チャンネル、定例会、更新履歴など、情報の種類ごとに役割を決めます。

14.5 利用状況を確認する

公開後は、コンポーネントが実際に使われているか、誤った方法で使われていないか確認します。利用されない場合は、発見しにくい、用途が分からない、要件に合わないなどの原因が考えられます。

利用者への短い聞き取りや、主要ファイルの確認から問題を見つけられます。公開数を増やすことではなく、正しく再利用されることを成果として評価します。

15. 既存ライブラリを再構築する方法

既存ライブラリの再構築では、現在の部品をすべて作り直すのではなく、利用状況と問題を確認しながら段階的に移行します。

15.1 現在の資産を調査する

最初に、ファイル、ページ、コンポーネント、スタイル、変数の一覧を確認します。同じ目的の部品、利用されていない部品、名前が不明確な部品を見つけます。

見た目だけで重複と判断せず、実際の利用場面を確認します。似ていても異なる役割を持つ場合があり、統合すると利用者が困る可能性があります。

15.2 目標構造を決める

現在の問題を基に、ファイル、ページ、カテゴリ、変数階層の目標を決めます。理想だけでなく、管理者数、移行期間、製品の開発予定を考慮します。

最終構造を一度に実現できない場合は、優先順位を決めます。検索性を先に改善し、その後で変数やファイル分割を行うなど、段階的な計画を作ります。

15.3 新旧を並行運用する

新しいライブラリへ一度に切り替えると、多数の画面で問題が起こる可能性があります。旧版を残しながら、新規画面は新版を利用する期間を設けます。

並行運用期間中は、旧版へ新機能を追加しないなどの規則が必要です。両方を同じように更新すると、移行が完了しません。

15.4 移行手順を提供する

利用者には、どの旧部品をどの新部品へ置き換えるかを示します。単に「新版を使ってください」と案内しても、プロパティや寸法の違いを判断できません。

主要な部品については、置き換え前後の例、変更される見た目、確認すべき箇所を記載します。自動置き換えが難しい場合は、優先画面から順番に手動で進めます。

移行対応表の例

{
 "Button/Primary": {
   "replaceWith": "Actions/Button",
   "properties": {
     "Role": "Primary",
     "Size": "Medium"
   }
 },
 "Input/Default": {
   "replaceWith": "Inputs/Text Field",
   "properties": {
     "State": "Default"
   }
 }
}
 

15.5 旧ライブラリを終了する

移行状況を確認し、主要ファイルで旧部品の利用がなくなった段階で公開を停止します。停止前に、利用者へ期限と影響を案内します。

旧ライブラリを削除する前に、過去画面の参照や記録として残す必要があるか確認します。編集不可の保管ファイルへ移す方法もあります。終了後は、新しいライブラリの問い合わせ先と更新方法を改めて共有します。

おわりに

Figmaライブラリ構造は、コンポーネントをきれいに並べるためだけのものではありません。ファイル、ページ、コンポーネント、変数、スタイル、公開設定、権限、ドキュメントを一つの体系として設計し、利用者と管理者の判断を支える仕組みです。構造が明確であれば、必要な部品を見つけやすくなり、重複や誤用を減らせます。

特に重要なのは、共通領域と製品固有領域を分け、基礎値から完成部品までの依存関係を一方向に保つことです。また、バリアントを増やしすぎず、真偽値、テキスト、インスタンス交換などのプロパティを適切に使い分ける必要があります。変数についても、具体値と用途を表す値を分けることで、テーマ変更やブランド変更へ対応しやすくなります。

ライブラリは公開した時点で完成するものではありません。利用状況、質問、重複、更新の停滞を確認しながら、構造と説明を継続的に改善する必要があります。利用者が迷わず部品を選び、管理者が安全に変更できる状態を維持することが、長期的に機能するFigmaライブラリの条件です。