XD のコンポーネント / シンボルを Figma Components に移行する完全ガイド

「XD のコンポーネントを Figma に持って行ったら、ステートが Variants にうまく変換されない」「マスターとインスタンスの関係が崩れた」「インスタンスのオーバーライドが反映されない」— XD → Figma 移行で最後まで残りやすいのが、コンポーネント周りの再現性です。

XD と Figma は コンポーネントの設計思想が部分的に異なる ため、自動変換だけで完璧に再現できないケースが残ります。重要なのは、何が自動で再現でき、何が手動補正必要か を最初に把握することです。

この記事では、XD のコンポーネントが Figma Components にどう変換されるか、Pixel Fine Converter の自動変換の挙動、手動補正が必要なケース、ベストプラクティス を整理します。

この記事で得られること

XD と Figma のコンポーネント概念の決定的な違い
マスター / インスタンス / ステート / オーバーライドのマッピング
Pixel Fine Converter の自動変換が対応する範囲と、手動補正が必要なケース
移行を成功させるベストプラクティス（XD 側で何を整えてから変換すべきか）

📝 はじめに — XD のコンポーネント移行が壁になりやすい理由

XD と Figma の双方を触ったことがあるデザイナーが共通して感じるのが、コンポーネント周りの「ノリの違い」 です。両ツールとも「マスター + インスタンス」というモデルは持っていますが、

構造変更の許容度（XD はインスタンス側でのノード追加・削除を許容、Figma は許容しない）
ステートの扱い（XD はマスター内に複数ステート、Figma は Variants で別コンポーネントを束ねる）
オーバーライドの粒度（テキスト / 画像 / カラー / 入れ子の扱い）

の 3 点で挙動に差があります。これらの違いが「自動変換だけでは越えられない壁」を生み、移行作業の最後の調整コストとして残ります。

この記事の前提として一つ押さえておきたいのが、コンポーネント変換は Pixel Fine Converter の Pro プラン（買い切り $29）の機能 です。プラグイン本体は無料でインストールできますが、Free プランでは構造・スタイル・グループの基本変換までで、コンポーネント / Variants 変換は対象外になります。

🔬 XD のコンポーネントと Figma Components の概念差

XD と Figma で「コンポーネント」と呼ばれているものは、似て非なるモデルです。3 つの観点から差を整理します。

マスターとインスタンス（基本構造）

両ツールとも「マスター（定義）+ インスタンス（複製）」という構造ですが、インスタンス側で何ができるか が大きく違います。

項目	XD	Figma
マスター（定義側）	シンボル定義	メインコンポーネント（`COMPONENT`）
インスタンス（複製側）	シンボルインスタンス	インスタンス（`INSTANCE`）
構造変更の許容	許容（ノード追加 / 削除 / 型変更が可能）	不許容（構造はマスターと完全一致が必須）
許可されるのは	プロパティ + 構造の自由な変更	プロパティのオーバーライドのみ

→ この 「XD の柔軟性 vs Figma の厳密性」 が、コンポーネント変換で最大の障害になります。XD のインスタンスでノードを追加・削除する慣習があるチームほど、Figma 側で構造的に持ち込めない要素が多くなる傾向があります。

ステート vs Variants（多状態管理）

XD のステート（hover / pressed / disabled など）と Figma の Variants は、どちらも複数の状態を管理する仕組み ですが、構造が違います。

項目	XD	Figma
表現	1 マスター内に複数ステートが入れ子で存在	複数の `COMPONENT` を `COMPONENT_SET` で束ね、Variants プロパティで切り替え
命名	ステート名（Default / Hover 等）	プロパティ軸（例: `State=Hover`、`Size=Large` 等）
多軸管理	できない（ステートは 1 軸の列挙）	複数プロパティ軸（State / Size / Theme などの組み合わせ）
表現力	状態列挙としてシンプル	軸の組み合わせで指数的に状態を持てる

Figma の方が表現力が高い分、変換時には 「XD のステートをどう Variants プロパティ軸に整理するか」 という設計が必要になります。Pixel Fine Converter は、XD のステート名をそのまま State=<ステート名> のプロパティ値として使う形で自動変換するため、多軸化したい場合は変換後に手動で Variants プロパティを再編成 する流れになります。

オーバーライド（テキスト / 画像 / カラー）

両ツールとも、インスタンス側で個別のテキスト / 画像 / カラーを変更できる「オーバーライド」を持ちます。ただし対応範囲が違います。

種類	XD	Figma
テキスト内容	✅	✅
画像	✅	✅
カラー	✅	✅
表示 / 非表示	✅	✅
Auto Layout プロパティ	—	✅
構造変更（ノード追加 / 削除 / 型変更）	✅ 許容	❌ 不許容

→ 「Figma のほうがオーバーライドできる項目が広い」一方、「XD でオーバーライドが構造変更を伴っているケース」は Figma に持ち込めない という非対称性があります。これが自動変換が効かないケースと手動補正のケース 2 で扱う中核問題です。

🗺️ XD → Figma の変換マッピング（PFC の挙動）

Pixel Fine Converter は次のマッピングルールで XD のコンポーネント系要素を Figma に変換します。

基本マッピング: マスター → COMPONENT、インスタンス → INSTANCE

XD 側	Figma 側	補足
シンボル定義（マスター）	メインコンポーネント（`COMPONENT`）	レイヤー階層・スタイル・子ノード構造を保持
シンボルインスタンス	インスタンス（`INSTANCE`）	メインコンポーネントとの参照関係（master link）を維持

最もシンプルな変換ルートで、構造一致が取れているマスター + インスタンス群はこのまま自動変換されます。

ステート → Variants の変換

XD のステートを持つマスターは、Figma の Component Set（COMPONENT_SET） として変換され、各ステートが State=<ステート名> の Variants プロパティ値になります。

XD 側	Figma 側
マスターの Default 状態	`State=Default` の Variant
ステート「Hover」	`State=Hover` の Variant
ステート「Pressed」	`State=Pressed` の Variant

→ ステートを多用するインタラクティブコンポーネント（ボタン / トグル / チップ等）も、構造一致が取れていれば自動で Variants 化されます。プロトタイプのステート遷移トリガー も、可能な範囲で Variants 切替に変換されます。

オーバーライドの保持

Pixel Fine Converter は、XD のインスタンスに含まれるテキスト / カラー / 画像 / 表示状態のオーバーライドを 選択的 deep merge で Figma 側に持ち込みます。

プリミティブ値（色・不透明度・テキスト内容）は インスタンスの値を採用
構造メタデータ（ノード型・制約・レイアウト情報）は マスターの値を採用

これは「XD で 角丸の矩形 がインスタンスで マスクグループ に変わっている」のような構造変更ケースを、そのまま上書きすると Figma の INSTANCE 制約に抵触する ため、構造系メタデータだけマスター側を保持する設計です。詳細は Features: Components を参照してください。

インスタンスリサイズ

XD のインスタンスがマスターと異なるサイズを持つ場合、Figma のインスタンスもソースサイズに合わせてリサイズされます。許容誤差は Strict（5px） / Standard（10px、デフォルト） / Tolerant（30px） の 3 段階で設定可能で、デフォルトの Standard で多くのケースが正確に動作します。

変換は完全にローカル処理

Pixel Fine Converter のコンポーネント変換は、XD のドキュメント構造を解析して 変換するユーザーのパソコン上で完結 します。ファイルのデータを外部サーバーに送信することはありません。デザインシステムの中核を扱う移行で、機密性が問題にならない設計です。

🛠️ 自動変換が効かないケースと手動補正

Pixel Fine Converter の自動変換でカバーしきれないケースと、それぞれの対処方針を整理します。

ケース 1: ネストされたコンポーネント

コンポーネント内にさらにコンポーネントが入っている多階層構造です。

症状: 内側のインスタンスが認識精度落ち、または個別フレームに展開される
背景: ネスト深度が増すと、構造一致検証の許容誤差が累積する + 親変更の影響範囲が広がる
対処:
- 浅い階層なら そのまま変換 → Figma 側で目視確認 で問題ないケースが多い
- 深い階層は XD 側で事前にネストを浅くする、または 変換後に Figma で Component → Variant 構造に整理 する

ケース 2: オーバーライドで構造変更を伴うケース

XD ではインスタンス側でノードを追加 / 削除できますが、Figma の INSTANCE は基本的に構造変更を許可しません。

症状: 該当インスタンスが INSTANCE ではなく プレーンフレーム（通常の Frame） として変換され、master link が失われる
背景: Figma の INSTANCE モデルが構造変更を許容しない設計のため
対処:
- 見た目は再現されているので、構造変更不要なら Frame のままで運用 も実用的
- コンポーネント参照を維持したい場合は、XD 側で「派生したインスタンス」を別マスターとして切り出す のが現実解

ケース 3: ステートの境界が曖昧なケース

XD のステートが「明示的なプロパティ軸として定義されていない」場合、Figma の Variants にどう振り分けるかが自明でないことがあります。

症状: ステートが単純な列挙（State=A / State=B / State=C）として変換され、後から軸再編成が必要
背景: Figma の Variants は 複数プロパティ軸（State + Size + Theme 等）を持てるが、XD のステートは 1 軸の列挙
対処: 変換後に Figma 側で Variants プロパティ軸を手動で再編成（State 軸 + Size 軸の二軸化、等）

ケース 4: 大規模コンポーネント（500 ノード超）

500 ノードを超えるコンポーネントでは、Pixel Fine Converter は Figma プラグインのメモリ予算内に収めるためのフォールバックを適用します。具体的には authoritative default state の抽出をスキップ することで OOM を回避します。

症状: Variants 自体は生成されますが、Default state に 特定 state からの上書き残留（例: opacity 0.7 のような state-based override の混入） が残ったまま使われる場合があります
対処: ノード数を減らして 500 ノード以下に収める（不要レイヤーの削除、ベクター統合）か、コンポーネントを分割する

⭐ 移行を成功させるベストプラクティス

XD 側で事前に整えておくと、Figma 側での再現性が向上するポイントです。

1. マスターの命名を統一する

XD で雑然とした命名（Component 1 / New symbol 等）になっていると、Figma 側で「どのマスターが何の役割か」が分からなくなります。Button/Primary / Card/Article のようなスラッシュ区切り で意味のある命名にしておくと、Figma の Variants にも自然に対応します。

2. ステートの命名規則を整える

ステートの順序と命名（Default / Hover / Pressed / Disabled のような英語名 + 標準的な順序）を XD 側で揃えておくと、Figma の State=Hover 等のプロパティ値も意味のある命名で揃います。

3. ネスト深度を最小化する

経験則として、コンポーネント内コンポーネントの入れ子を浅め（2-3 階層程度）に抑えると、変換後の認識精度が上がる傾向があります。深いネストは、XD 側で シンプルなコンポーネントに分解 するか、Atomic Design のような階層設計 を意識して再整理するのが移行前の準備として有効です。

4. 構造変更を伴うインスタンスは事前に分解する

「マスターと構造が大きく異なるインスタンス」は、Figma に持ち込めません（→ ケース 2）。移行前に XD 側でそのインスタンスを別マスターとして切り出す ことで、Figma でも参照関係を保てます。

5. XD の Document Assets を整理する

未使用のアセット / 重複したマスター / リネーム履歴で整理されないまま残った要素は、変換時のノイズになります。移行前に Document Assets を整理 することで、Figma 側に持ち込まれるコンポーネント数が減り、後続の作業がシンプルになります。

💬 よくある質問

Q: XD のステートは Figma の Variants にそのまま変換されますか？

A: 基本的には変換されます。XD のステートは State=<ステート名> のプロパティ値として Figma の Component Set（Variants）に持ち込まれます。ただし、プロパティ軸を多軸化したい場合（State + Size + Theme の 3 軸など）は、変換後に Figma 側で手動での再編成が必要です。

Q: マスターを XD で編集したら、Figma 側のインスタンスにも反映されますか？

A: いいえ、変換した後は両者の同期は切れます。Figma 側に持ち込まれた後は、XD と Figma は完全に独立したファイルとして扱われるため、再変換しないと反映されません。継続的に XD で編集して Figma に反映したいユースケースには、Pixel Fine Converter は適していません（移行ツールとしての位置づけ）。

Q: ネストされたコンポーネントは正しく変換されますか？

A: 多くのケースは変換できますが、ネストが深いほど手動補正コストが上がります。経験則として、浅め（2-3 階層程度）なら高い精度で変換できる傾向にあり、深いネストでは変換後の Figma 側で目視確認 + 手動再構成が現実的です。

Q: XD のリピートグリッドはどう変換されますか？

A: リピートグリッドはコンポーネントとは別軸の機能です。Auto Layout + Component + Instances の構成として変換されます。詳細は Adobe XD のスタックとリピートグリッドを Figma Auto Layout に変換するを参照してください。

Q: コンポーネント変換は Free プランで使えますか？

A: いいえ、コンポーネント変換は Pro プラン（買い切り $29、サブスクリプション無し） の機能です。Free プランでは shape / text / style / group / mask / image / transform の基本変換までご利用いただけます。Pro 機能の動作確認は、Free プランで構造を変換 → 必要に応じて Pro にアップグレードという二段構えがおすすめです。

Q: インスタンスの色や文字を変えていた箇所は保持されますか？

A: はい、テキスト内容 / カラー / 画像 / 表示状態のオーバーライドは 選択的 deep merge で Figma 側に保持 されます。ただし、構造変更を伴うオーバーライド（ノードの追加・削除・型変更）は Figma の INSTANCE 制約により持ち込めず、プレーンフレーム化されます。

✅ まとめ

XD のコンポーネントを Figma Components に移行する際のポイントを整理しました。

記事のポイント

XD と Figma の コンポーネント概念差（構造変更の許容度 / ステートの扱い / オーバーライド粒度）
マスター → COMPONENT、ステート → Variants（State=<名前>）、オーバーライドは選択的マージ という自動変換マッピング
手動補正が必要な 4 ケース（ネスト / 構造変更オーバーライド / ステート軸曖昧 / 大規模コンポーネント）
移行を成功させる 5 つのベストプラクティス（命名統一 / ステート命名 / ネスト最小化 / 事前分解 / Document Assets 整理）

XD のシンボルを Figma の Variants として活かすには、XD 側で事前に整理する作業 + 変換時の自動マッピング + Figma 側での手動補正 の 3 段階で取り組むのが現実的です。デザインシステムの中核を運用しているチームほど、移行コストの大半はこのコンポーネント周りに集約されるため、「自動変換でどこまで再現できるか」を最初に把握する ことが移行プロジェクトの工数見積もりの鍵になります。

🚀 XD のコンポーネントを Figma Components へ自動変換 — Pixel Fine Converter

Free プランで基本変換を確認 → Pro プラン（買い切り $29）でコンポーネント / Variants / インスタンスリサイズを有効化