Adobe XD → Figma、日本語テキストはどこまで正確に変換できるか

「XD で作ったデザインを Figma に移したら、日本語テキストの位置がちょっとズレて見える」「同じ fontSize なのに、Figma だと文字が細く / 小さく見える」— XD から Figma への移行を進めているデザイナーから、よく聞く声です。

この「ちょっとしたズレ」は、ピクセル単位のレイアウトを大切にする日本語デザインでは無視できないノイズになります。だからといって、コンバーター系の宣伝文句にあるような 「完璧に変換」「flawless migration」を実現するのは、技術的にかなり難しいというのが現実です。

この記事では、Pixel Fine Converter で 5 フォント × 42 セルを実測した結果をもとに、日本語テキストの「揃う部分」と「揃わない部分」を誠実に切り分け、それぞれの背景と実用的な対応策をまとめます。

この記事で得られること

ベースライン位置は補正できる（プラグインが何をしているのか）
グリフ描画は揃わない（なぜ揃わないのか、技術背景）
MS Gothic の特殊事情（ビットマップフォントの話）
ツール側で補正しない理由（「信頼されるデータ」を保つという哲学）
実用的な推奨（モダンフォントへの段階移行、サイズの工夫）

📝 はじめに — なぜ日本語テキストがズレて見えるのか

XD と Figma は、同じ「デザインツール」のカテゴリにありますが、内部のテキスト描画エンジンは別物です。同じフォントファイルを読み込んでいても、

ベースライン位置（文字の縦位置の基準点）
行の高さ（lineHeight）の解釈
グリフのアンチエイリアス処理

これらが微妙に違うため、XD で作ったデザインをそのまま Figma で開くと、日本語テキストの見え方がわずかに変わります。

英数字フォントでも差は出るのですが、日本語フォントでは特に目立ちます。理由は 2 つです。

CJK（中国語・日本語・韓国語）フォントは、フォント内部の baseline メトリクスが英数字フォントと異なる構造を持つこと
MS Gothic のような古いフォントは、Windows 時代のビットマップ描画を前提に設計されており、現代のアウトライン描画と相性が悪い場合があること

これらの差を、プラグイン側でどこまで補正できるのか — その境界線を明らかにするのが、この記事のテーマです。

✅ 揃うもの — ベースライン位置

まずは正確に補正できるものから紹介します。ベースライン位置（テキストの縦位置）は、プラグインで補正できます。

Pixel Fine Converter では、主要な日本語フォントについて XD と Figma のベースライン差を実測し、フォント別に補正値を持っています。

実測データのサマリ（42 セル × 5 フォント検証）

検証対象フォント:

Noto Sans CJK JP — Adobe / Google 製、CJK 統合フォント
Noto Sans JP（非 CJK 版）— Google Fonts 経由の日本語版
ヒラギノ角ゴ ProN — macOS 標準
游ゴシック — macOS / Windows 共通の現代和文フォント
MS Gothic — Windows 標準（古典的）

各フォントについて、Regular / Bold × 7 サイズ × 3 lineHeight の計 42 セルを実測。補正後の平均ズレは 1px 未満 に収束しています。

具体的にプラグインがやっていることは、

フォント名を識別して、対応する補正係数を引く
補正係数を baselineOffset として座標補正に反映
Noto Sans CJK JP は補正方向が他のフォントと逆 → 専用フラグで補正をスキップ
MS Gothic は補正未発動の閾値下に該当 → 専用 baselineOffset を新設

つまり、フォントごとの個体差を「レジストリパターン」で持つことで、新しいフォントが必要になったら測定して追加する、という拡張可能な設計にしています。

→ プラグインの補正対応フォント一覧は Features: 日本語フォント対応で確認できます

⚠️ 揃わないもの — グリフの見かけの大きさ

ベースライン位置は揃いました。しかし、グリフ（文字の形）の見かけの大きさについては、プラグインで補正することはできません。

具体的には、こんな現象が起きます。

同じ fontSize: 14 でも、XD のほうが文字が太く見える / Figma のほうが細く見える
特に MS Gothic の小サイズ（12〜16px） で顕著
フォント全体の「重心」がわずかに違って見えることがある
アンチエイリアスのかかり方が違うため、輪郭の柔らかさが変わる

この差は fontSize を変えても解決しない

「Figma で細く見えるなら、fontSize を少し大きくすればいい」と思うかもしれませんが、それをツール側で自動的にやると、「XD のオリジナルデータと違う値」が Figma に書き込まれることになります。これは後述する「ツール側で補正しない理由」につながります。

このグリフ描画の差は、ベースライン補正のように数値計算で揃えられる種類のものではなく、レンダリングエンジンの設計思想そのものの違いから生まれています。

🔧 なぜ揃わないのか — レンダリングエンジンの違い

XD と Figma で日本語テキストの見え方が変わる根本原因は、テキスト描画を担当するエンジンが違うことにあります。

項目	Adobe XD	Figma
描画基盤	Adobe 独自エンジン（ネイティブアプリ）	ブラウザベースの独自エンジン（WebGL + Canvas）
ヒンティング	OS のフォントレンダリングに依存	独自実装（OS をまたいで一貫させるため）
アンチエイリアス	OS 標準（macOS は subpixel、Windows は ClearType 等）	ブラウザ標準（一般的に grayscale）
埋め込みビットマップ	フォント側の埋め込みを使用する場合あり	アウトラインから生成

整理すると、

XD は OS のフォント描画機能をそのまま使うので、macOS と Windows で見え方が違う（けれど、それぞれの OS では「自然」な見え方）
Figma はブラウザベースで OS をまたいで一貫させるため、独自の描画ルールを持つ（その代わり、特定 OS の「自然な見え方」とはズレる）

どちらも合理的な設計判断ですが、移行時には「同じデザインなのに違って見える」という結果につながります。

これは XD ⇔ Figma 固有の問題ではない

実は、Sketch、Penpot、Adobe Illustrator など、異なるレンダリングエンジンを持つツールの間では同様の差が常に起きています。XD → Figma で目立つのは、移行する人が多いからこそ報告される、という側面が大きいのです。

🔤 MS Gothic の特殊事情 — ビットマップフォント

日本語フォントの中でも、特に MS Gothic は「揃わない」が目立ちやすいフォントです。これには技術的な理由があります。

MS Gothic は Windows 95 世代のビットマップフォント

MS Gothic は 1990 年代の Windows 向けに設計された日本語ゴシックフォントで、フォントファイル内部に「埋め込みビットマップ」を持っています。

12px、14px、16px など、よく使われる小サイズ用の見た目を、画像として直接埋め込んでいる
これにより、低解像度ディスプレイでも文字がカクカクせず、シャープに表示できた
Windows のメイリオ（Meiryo）登場前の時代の標準的な手法

XD と Figma での扱いの違い

XD（とくに Windows 版）: 埋め込みビットマップを優先的に使う場合がある → シャープな見た目
Figma: アウトライン（ベクター形状）から各サイズを生成する → ビットマップとは異なる見た目

この差が、MS Gothic の小サイズで「Figma のほうが細く / 小さく見える」現象として現れます。

MS Gothic は本質的に「過去の遺産」

MS Gothic はビットマップ前提の設計のため、現代の高解像度ディスプレイ（Retina / 4K）では本来の良さが活きにくく、Web フォントとしての配信もできません。新規デザインで MS Gothic を選ぶ理由は、現代ではほぼありません。

つまり、MS Gothic で起きるズレは、Figma 側の問題ではなく、フォント自体が現代の使われ方にマッチしていないことが根本原因です。

🛠 なぜツール側で補正しないか

「グリフが細く見えるなら、プラグイン側で fontSize を 1.05 倍くらいに自動補正してくれないの？」— よく出る発想ですが、Pixel Fine Converter では意図的にやらない選択をしています。理由は 3 つあります。

理由 1: それは「変換」ではなく「改変」になる

XD ファイルに fontSize: 14 と書かれているテキストを、勝手に fontSize: 14.7 に変えて Figma に書き出すと、それは「データの正確な変換」ではなくなります。後から「あれ、なんで Figma 側だけ 14.7 なの？」と混乱の種になります。

理由 2: 補正の度合いはフォント / OS / Figma バージョンで変動する

フォント A では 1.05 倍が良くても、フォント B では 1.03 倍が適切
同じフォントでも OS によって「正解」が違う
Figma がアップデートで描画エンジンを変えたら、補正値はすべて見直しが必要

つまり、自動補正は「今この瞬間の見た目」を揃えても、長期的にはトラブル源になります。

理由 3: ベースライン補正は安全、グリフ補正は危険

ベースライン位置は「数値で計測できる、変換時点で確定する物理量」です。一方、グリフの見かけの大きさは「視覚的な印象」が混じる主観的な指標です。前者を補正するのは正確性の向上、後者を補正するのは推測になります。

この線引きが「信頼できる変換」の定義

Pixel Fine Converter は「揃えられる部分には徹底的にこだわり、揃えられない部分には余計な手を加えない」という方針をとっています。これは、変換結果を信頼して使ってもらうための土台だと考えています。

💡 実用的な推奨 — モダンフォントへの段階移行

技術的な背景を理解したうえで、実務的にどうすればよいか。3 つの推奨があります。

1. 新規デザインではモダンフォントを使う

以下のフォントは、補正対応が成熟しており、Figma との相性も良好です。

フォント	特徴
Noto Sans JP	Google Fonts で配信、ウェブで広く使われる現代和文フォント
ヒラギノ角ゴ ProN	macOS 標準、商用案件でよく選ばれる
游ゴシック / Yu Gothic	macOS / Windows 共通、本文向きのバランス型
Noto Sans CJK JP	CJK 統合版、多言語混在デザインに最適

これらは Pixel Fine Converter でも実測ベースの補正係数を持っており、ベースライン位置が 1px 未満に揃います。

2. MS Gothic は段階的に移行

既存の MS Gothic 使用箇所を一気に置き換えると、レイアウト崩れの原因になります。

新規案件では使わない（Yu Gothic / Noto Sans JP に置き換え）
既存案件は許容（差は出るが、データの正確性は保たれる）
大規模リニューアル時にまとめて置換（Find & Replace で一括処理）

3. 本文サイズは 14px 以上にすると差が目立ちにくい

レンダリング差はサイズが小さいほど目立ちます。

12px 以下: ピクセルレベルの差が比較的目立つ
14px 以上: 差はあるが、視覚的にほぼ気にならない
18px 以上: 違いはほぼ判別不能

ウェブのアクセシビリティ観点でも、本文 14〜16px は推奨される範囲です。サイズを少し上げるだけでレンダリング差の体感は大きく改善します。

🚀 自分のファイルで日本語テキストの再現精度を試してみる

Free プランで 3 アートボードまで変換可能。ウォーターマークなし、登録不要です

💬 よくある質問

Q: ベースラインの差は具体的に何 px くらいですか？

A: フォントとサイズによりますが、補正前は 2〜5px ズレることがあり、補正後は 1px 未満に収束します。Pixel Fine Converter は 5 フォント × 42 セルの実測データに基づいてフォント別の補正係数を持っています。

Q: なぜグリフ補正をしないのですか？技術的に難しいのですか？

A: 技術的には可能です。ただし、補正値はフォント / OS / Figma バージョンで変動するため、自動補正を入れると「現時点の見た目」は揃いますが、Figma が描画エンジンをアップデートした際に全部見直しが必要になります。XD のオリジナルデータをそのまま Figma に持っていくほうが、長期的には安全だと考えています。

Q: MS Gothic を使ったデザインを移行する場合、どうすればいいですか？

A: 3 つの選択肢があります。(1) 既存資産は MS Gothic のまま維持（差は出るが数値データは正確）、(2) 大規模リニューアルのタイミングで Yu Gothic / Noto Sans JP へ置換、(3) Figma 側で別フォントに統一しつつ XD のオリジナル指定を保持（後で戻せる）。チームの方針に合わせて選んでください。

Q: Figma 側でフォントレンダリングを XD に近づける設定はありますか？

A: ありません。Figma のレンダリングエンジンは OS をまたいで一貫した見た目を提供することを優先しているため、特定の OS / アプリの見た目を再現するオプションは公式には存在しません。

Q: 他の変換プラグインと比べて、日本語テキストの再現精度は違いますか？

A: 補正対応の有無によって差が出ます。ベースライン補正をフォント別に持つかどうかは、プラグインによってまちまちです。具体的な比較は変換プラグイン徹底比較を参照してください。

🎯 まとめ

XD → Figma の日本語テキスト変換について、「揃う部分」と「揃わない部分」を切り分けて整理しました。

記事の要点

#	ポイント	詳細
1	ベースライン位置は揃う	Pixel Fine Converter は 5 フォント × 42 セル実測ベースの補正で、平均 1px 未満に収束
2	グリフ描画は揃わない	レンダリングエンジン（XD = OS 依存 / Figma = ブラウザベース独自）の違いが根本原因
3	MS Gothic は特殊	Windows 95 世代のビットマップフォント、現代の使い方にマッチしない
4	ツール側で自動補正しない理由	データの正確性 > 見た目の一致、長期的な安全性を優先
5	実用的な推奨	モダンフォント（Noto Sans JP / ヒラギノ / 游ゴシック）への段階移行と、本文サイズ 14px 以上

「完璧に揃える」を目指すと、どこかで矛盾が生じ、データの整合性を保つことができなくなります。「揃えられる部分には徹底的にこだわり、揃えられない部分には余計な手を加えない」— これが Pixel Fine Converter の設計思想であり、長期的にデータを信頼して使うための前提だと考えています。

🚀 Pixel Fine Converter を Figma Community からインストール

Figma Communityから1クリックで追加できます