構造は合っているのに見た目が違う?Adobe XDとFigmaの「最後の数ピクセル」を埋めるためのひと工夫をご紹介!
XDからFigmaへの移行作業で、最後まで残るのが**「構造は合っているのに、なぜか見た目が違う」**という違和感です 🤔(オートレイアウトやコンポーネントといった「構造」の変換については、それぞれ『XDのスタックを組み直す手間はもう不要!Figmaのオートレイアウトへ忠実に変換します!』『XDで作成したコンポーネントを忠実に再現!Figmaでもそのまま使えます!』で詳しく解説しています!)
グラデーションの角度がわずかにずれる。テキストがフレームの端で見切れる。オートレイアウト内のテキストが数ピクセル下にずれる — これらはXDとFigmaのレンダリングエンジンの根本的な違いに起因しており、構造を正しくコピーするだけでは対処できません。
多くの変換ツールはここで手を止めます。「構造が移ればOK」と。しかし実際に移行作業をする方にとっては、変換後の手直しこそが最も時間のかかる工程ですよね 😇
Pixel Fine Converter は、この「最後の数ピクセル」の問題に一つひとつ向き合っています! 完璧な再現を約束するものではありませんが、XDとFigmaのレンダリング差異を理解した上で、変換後の手直し工数をできるだけ減らすための4つの微調整を徹底的に行っています 🔧
ご注意: 微調整機能は Pro プラン(買い切り $29) の機能です。プラグイン本体は無料でインストールでき、Freeプランでも構造・スタイル・グループなどの基本変換はご利用いただけます。
🧩 なぜ微調整が必要なのか
XDとFigmaはどちらもベクターベースのデザインツールですが、内部のレンダリングロジックは大きく異なります。
| 領域 | XD | Figma |
|---|---|---|
| グラデーション座標 | 正規化座標系(0〜1)、要素サイズに非依存 | バウンディングボックス座標系、アスペクト比が角度に影響 |
| フォントメトリクス | 独自のテキストレイアウトエンジン | 同じフォントでも約1.15〜1.45倍のスペースを占有する場合がある |
| 単一行テキストの行高さ | lineHeight を無視して描画(表示に影響しない) | lineHeight を常に適用(小さすぎるとクリッピング発生) |
| ハーフレディング | 単一行テキストのY座標に直接反映 | (lineHeight - 自然高) / 2 をグリフの上下に均等配分 |
これらの違いは構造変換では対処できません。Pixel Fine Converterが行う微調整は、こうした差異に一つずつ対策を適用して、変換後の手直しを減らすための大事な工程です! すべてを完璧に補正できるわけではありませんが、「なぜずれるのか」を理解した上で、できる限りの対応をしています。
以下、4つの機能それぞれについて「何が問題で、なぜ起こり、どう解決するのか」を詳しく解説していきます!
🎨 グラデーション角度の補正
問題
XDのグラデーションは正規化された座標系(0〜1)で定義されるため、要素のサイズに関係なく同じ角度で描画されます。一方、Figmaはバウンディングボックス座標系を使用するため、正方形でない要素では斜めのグラデーション角度がずれます。
この問題は、アスペクト比が極端な要素ほど顕著です。たとえば 960×50px のヘッダーバーに45°のグラデーションをかけた場合、XDでは意図通りの斜め方向になりますが、Figmaではほぼ水平に近い角度で描画されてしまい、見た目が大きく変わります。
なぜこのずれが起こるのか
XDはピクセル空間でグラデーション方向を計算します。「左上から右下へ」という指定は、要素が正方形でも横長でも同じ角度です。一方、Figmaは正規化された [0,1]² 空間でサンプリングを行います。横長の要素では水平方向が「圧縮」されるため、45°の指定が実際にはもっと水平に近い角度で描画されます。
つまり、同じ (0,0) → (1,1) という指定でも、XDでは「ピクセル上の対角線」、Figmaでは「正規化空間の対角線」を意味するため、正方形でない要素で角度が食い違ってしまうのです。
解決
Pixel Fine Converter は、要素のアスペクト比(W/H)を考慮したアフィン変換行列を再計算します。XDの正規化座標をFigmaのピクセル座標に射影し直すことで、角度のずれを補正します!
具体的には、グラデーションの始点・終点をピクセル空間に展開し、W² と H² で重み付けした変換行列を生成します。この計算により、Figmaのサンプリング空間上で見たときにXDと同じ角度に見えるよう調整されます。地味ですが効きます 💪
なお、この補正は線形グラデーションのみに適用されます。放射グラデーションは別の変換処理(変換行列の合成→逆算)で対応しています。
自動スキップ
以下のケースでは補正が不要なため、自動的にスキップされます。
- ✅ 正方形の要素 — 幅と高さの差が 0.01px 以下の場合、両座標系は実質同じ
- ✅ 水平・垂直方向のグラデーション — アスペクト比の影響を受けない角度
トレードオフ
この補正はデフォルトONですが、ごくまれに補正が逆効果になるケースがあります。変換後のグラデーションに違和感がある場合は、オプションからOFFに切り替えることで元の挙動に戻せます。
✂️ テキストの見切れを防止
問題
XDとFigmaではフォントメトリクスが異なり、同じフォント・同じサイズのテキストでも、Figmaの方が約1.15〜1.45倍のスペースを占有する場合があります。XDではフレーム内にきれいに収まっていたテキストが、Figmaでは右端や下端で見切れる現象が起こります。
特にクリッピングが有効なフレーム(clipsContent=true)の中のテキストで顕著です。テキストのはみ出しはたった1〜3px程度ですが、クリッピングフレーム内ではその数ピクセルが「見切れ」として目に見える問題になります。たかが数ピクセル、されど数ピクセルです 😅
なぜフォントの描画サイズが違うのか
フォントファイル(TTF/OTF)には、行の高さを決めるメトリクス情報が複数格納されています。代表的なものが sTypo(OS/2テーブル)と hhea(hheaテーブル)の2系統です。
XDとFigmaは異なるメトリクス系統を参照しており、同じフォントファイルでも算出される行高さが異なります。この差はフォントごとに違いますが、特にCJKフォント(Yu Gothic、Noto Sans JPなど)では差が大きく、Latin フォントの約1.15〜1.25倍に対して、CJKフォントでは約1.45倍のスペースを占有することがあります。日本語デザインで特に問題が表面化しやすいのはこのためです!
解決
この機能をONにすると、クリップフレーム内の全テキストノードの実寸を計算し、はみ出しが検出された場合に必要最小限のピクセル数だけフレームを拡張します。
- 🔍 検出: テキストノードの右端・下端がフレームサイズを超えているかチェック
- 📐 計算: すべての子テキストの最大はみ出し量を算出し、小数点以下を繰り上げ
- 📦 拡張: フレームとマスク形状を同期して拡張。マスクが矩形・楕円・ベクターのいずれでも対応
固定値ではなく、子ノードごとのオーバーフロー量を算出して適用するため、無駄な余白が生じません 🎯
対象と除外
この機能は、textAutoResize が WIDTH_AND_HEIGHT(ポイントテキスト)のテキストノードを対象としています。テキストボックス型(固定幅)のテキストは、フレーム幅に合わせて折り返すため対象外です。また、回転されたクリップフレームはオーバーフロー検出の精度が保証できないため、スキップされます。
トレードオフ
フレームサイズがXDの元サイズよりわずかに大きくなります。ピクセルパーフェクトなレイアウトが必要な場合は、手動での微調整が必要になることがあります。
📏 行高さの正規化
問題
XDでは lineHeight が fontSize より小さくても、単一行テキストは見切れずに表示されます。XDはこの値を単一行テキストの描画には使わないからです。
しかしFigmaでは lineHeight が常にテキストボックスの高さに反映されます。lineHeight < fontSize の場合、テキストボックスの高さがグリフより小さくなり、上下がクリッピングされます。72pxの見出しテキストに24pxの lineHeight が設定されていた場合、Figmaでは文字の大部分が見切れてしまいます 💦
なぜ lineHeight < fontSize が起こるのか
「なぜそんな設定がXDに存在するのか?」と思われるかもしれません。XDでは、デザイナーが複数行テキスト用にlineHeightを設定したあと、テキストを1行に変更することがよくあります。このとき、XDではlineHeightの値が見た目に影響しないため、古い値がそのまま残ります。見た目では問題なく動作するため、デザイナー本人も気づかないのです。XDあるある、ですね!
解決
この機能をONにすると、lineHeight を Figma が実測した自然な行高さ(naturalLineHeight)以上にクランプ(引き上げ)します。単純に fontSize と比較するのではなく、Figma上でフォントを読み込んだ後に実際の描画高さを測定し、その値を最小値として使用します。
これにより、フォントごとに異なるメトリクス(CJKフォントの場合は fontSize × 1.45 程度、Latinフォントの場合は fontSize × 1.2 程度)を正確に反映した補正が行われます。
⚡ ハーフレディング問題の解消
問題
これはPixel Fine Converterが行う微調整の中でも最も厄介な問題です!
XDでは単一行テキストの lineHeight は表示位置に影響しません。しかしFigmaでは、テキストの上下に**(lineHeight - 自然な行高さ) / 2** の余白(ハーフレディング)が均等に配分されます。
この差異はオートレイアウトフレーム内で顕著になります。たとえば、24pxの見出しと14pxの補足テキストが横並びになっているボタンを想像してください。XDでは両方のテキストが上端揃えで自然に配置されていますが、Figmaではそれぞれのテキストに異なるハーフレディングが加算され、ベースラインが数ピクセル下にずれてしまいます。
座標汚染 — 問題をさらに複雑にする要素
さらに厄介なのが、XDの座標データ自体が lineHeight の影響を受けている場合があることです。XDの textAutoResize=WIDTH_AND_HEIGHT モードでは、テキストのY座標に lineHeight のオフセットが織り込まれていることがあります。
XDでは lineHeight が表示に影響しないため、デザイナーはこの「汚染」に気づきません。しかし変換時にこの座標をそのまま使い、さらにFigma側でハーフレディングが加算されると、二重にずれが発生します。つまり「XD座標のずれ + Figmaハーフレディングのずれ」が重なるのです。複雑さの極みですね 😵💫
解決
Pixel Fine Converter は、オートレイアウトの方向に応じて異なる正規化戦略を適用します。
| 方向 | 処理 | 理由 |
|---|---|---|
| 水平オートレイアウト | lineHeightをAUTO(自動)にリセット | 横並びのテキストはグリフの中央揃えが重要。AUTOで自然な揃いになる |
| 垂直オートレイアウト | XDの子要素間の座標差から適切な高さを逆算して適用 | 座標データが信頼できる範囲であれば、XDの意図したスペーシングを復元できる |
垂直オートレイアウト: 座標汚染の検出
垂直方向の場合、Pixel Fine Converter はXDの子要素間のY座標差から「XDが意図していた高さ」を逆算します。計算されたXD高さと、Figma上での実際のテキスト高さの比率をとり、この比率で座標の信頼性を判定します。
- 📊 比率 1.5 以下 → 座標データは信頼できる。XDの座標から算出した高さを
lineHeightとして採用 - 📊 比率 1.5 超 → 座標が lineHeight に汚染されている可能性が高い。
lineHeightを AUTO にフォールバック
なぜ 1.5 なのか? XDとFigmaのフォントメトリクス差は通常 1.0〜1.3 倍の範囲に収まります。1.5倍を超える差は、メトリクス差だけでは説明できないため、座標データ自体が lineHeight の影響を受けていると判断できる、というロジックです。
すべてのケースで完璧に機能するわけではありませんが、多くの一般的なレイアウトでハーフレディングによるずれを軽減できます 🛡️
適用範囲の制御
ハーフレディング正規化には3つのモードがあり、用途に応じて選べます。
- 🔴 OFF — 正規化を行わない(デフォルト)
- 🟡 Auto-layout children only — オートレイアウトフレーム内のテキストのみ正規化(推奨)
- 🟢 All — 条件を満たすすべてのテキストを正規化(積極的に修正したい場合)
デフォルトが「Auto-layout children only」である理由は、通常のフレーム内ではlineHeightが意図的な垂直センタリングに使われているケースがあるためです。たとえばボタン内のテキストは、lineHeightでフレーム内の上下中央に配置されていることがあり、この場合に正規化すると配置が崩れてしまいます。
トレードオフ
正規化されたテキストは元の lineHeight 値を失います。後からテキストを複数行に変更した場合、行間はXDの値ではなくFigmaのデフォルトが使われます。
⚠️ 限界とスコープ(正直にお伝えします)
ここまでPixel Fine Converterが行う4つの微調整に関する詳細をお伝えしてきましたが、これらはXDとFigmaのレンダリング差異という根本的な問題に対する「対症療法」です。すべてのケースで完璧に機能するわけではないため、トレードオフをきちんとお伝えしておきます!
- グラデーション角度の補正はごくまれに逆効果になります。変換後に違和感がある場合はOFFにして再変換してください
- テキストの見切れ防止はフレームサイズを変更するため、ピクセルパーフェクトなレイアウトとはトレードオフになります
- 行高さの正規化は元の
lineHeight値を上書きします。複数行テキストに後から変更する場合は行間の再調整が必要です - ハーフレディング正規化はオートレイアウトフレーム内のテキストにのみデフォルト適用されます。通常フレーム内のテキストにも適用したい場合は「Auto-layout children only」をOFFにできますが、意図しない変更が増える可能性があります
- 回転されたクリップフレームのオーバーフロー検出はスキップされます
- 全オプションの挙動は Guide: Fine-tuning オプションリファレンス で確認できます
レンダリングエンジンの違いに完全に対処することは原理的に不可能ですが、「気になる差異の8〜9割をプラグイン側で吸収できれば、残った1〜2割の手直しはずっと楽になる」 — そんな思想で開発を続けています。今後も、お使いいただくユーザーの皆様にご満足いただけるプラグインを目指してまいります。
🚀 まずは無料プランで、変換精度を確かめてください
Pixel Fine Converter はFigma Communityから無料でインストールできます! Freeプランでは、shape / text / style / group / mask / image / transform の基本変換がすべてご利用いただけるので、まずは手元の.xdファイルで変換品質を確認してみてください。
微調整機能をはじめとする、細部まで配慮した変換機能を必要とされる場合は、Pro プラン(買い切り $29、サブスクリプション無し) へのアップグレードでご利用いただけます 🎁
Figma Communityから1クリックで追加できます
関連ページ
- Guide: Fine-tuning オプションリファレンス — 各オプションのデフォルト値と詳細
- Features: Auto Layout 変換 — XDのスタックをFigmaオートレイアウトへ変換
- Features: Components 変換 — コンポーネントとインスタンスの構造復元
- Features: Prototype & States — プロトタイプ接続とステート変換
- Blog: XD→Figma 移行 実践ガイド — 移行の背景・手順・失敗パターン・ツール選び