SketchをFigmaにインポートした後に崩れるなら、すぐに全ページを作り直さず、原ファイル・読み込み後の副本・原稿画像を保存してから原因を切り分けてください。単純な文字や色の差はFigmaで直し、フォント、元ライブラリ、複雑な効果、読み込み失敗が関係する場合はSketchの原生環境で再確認します。

この手順は、Sketchの過去案件をFigmaへ移すUIデザイナー、Windowsで.sketchファイルを受け取って修正するフリーランス、デザインシステム移行の工数を判断する製品チーム責任者向けです。見た目だけでなく、後から再利用できる構造まで確認したい場合に役立ちます。

最初に崩れ方を分類する

SketchをFigmaにインポートした後に崩れる状態は、同じ「変換ミス」に見えても対処が異なります。まず代表画面を選び、原稿画像と読み込み後の画面を並べてください。

見えている症状 先に確認する項目 初期対応
画面全体が大きく見える、または小さく見える 表示倍率、フレーム、アートボードの範囲 基準画面を固定して局所差分を確認
文字だけが改行する フォント名、ウェイト、フォントの版、利用許可 フォントを揃えて影響レイヤーを記録
ボタンやカードの状態が違う メインコンポーネント、インスタンス、上書き 関係を確認し、必要なものだけ再接続
画像や効果が欠ける 埋め込み素材、マスク、影、描画モード 原ファイルと素材の存在を再確認
古い画面だけが一致しない 原稿の更新時点、参照ライブラリ 移行前の最新版を特定

Figmaは.sketchファイルを読み込めますが、読み込み結果は独立したFigmaファイルです。Sketch側の元ファイルが自動的に更新されるわけではありません。Symbolsがコンポーネントへ変換される点を含め、まずはFigma公式のSketchファイル読み込み仕様を確認してください。

注意：元ファイルを開いて上書き保存する前に、ファイル名へ「原本」「移行用副本」「検収用」などの役割を付けて分けてください。問題の原因が元データなのか、読み込み結果なのか追跡できなくなります。

第二段階：文字のずれをフォントから直す

フォント名が一致していても、見た目が一致するとは限りません。ウェイトの定義、字幅、フォントファイルの版が異なると、見出しの改行、本文の行高、ボタンの幅が変わります。

Figmaではローカルフォントを利用できる状態にする必要があります。デスクトップアプリの設定だけでなく、Figma公式のフォント追加手順と、ブラウザーからローカルフォントへアクセスするためのローカルネットワーク権限の説明を確認してください。

確認順序は次の通りです。

  • 原稿で使われているフォント名を確認する。
  • Regular、Medium、Boldなどのウェイトを照合する。
  • Figmaで代替フォントが自動適用されていないか確認する。
  • 見出し、入力欄、ボタンのテキストを代表画面で比較する。
  • 影響を受けたテキストレイヤーを一覧化する。
  • 最後に、Figmaのテキストとフォントの確認方法で設定を再確認する。

一括置換は最後に行います。先に置換すると、どの画面の改行が変わったのか分からなくなります。静止画納品なら視覚差を優先できますが、開発へ渡すデザインなら行高やボタン寸法の再確認も必要です。

第三段階：Symbolsとコンポーネントを再接続する

Sketch Symbolsの読み込み後は、見た目が似た部品でも、元のライブラリとの関係が切れていることがあります。Figmaのコンポーネントへ変換されたことと、Figmaのチームライブラリとして運用できることは別です。

確認対象 保持できている状態 作り直しを検討する状態
メインコンポーネント 変更元が特定できる どの部品が元か分からない
インスタンス 変更が親へ反映される 個別の独立オブジェクトになっている
上書き内容 文字や画像の差し替えが保たれる 状態や上書きが消えている
入れ子構造 親子関係を追跡できる 部品が平坦化されている
ライブラリ 公開と更新の流れを設計できる 名前だけで対応先を判断している

Figmaのコンポーネントとライブラリの公式説明にある通り、チームで再利用するには公開や更新の仕組みが必要です。外部Sketch Libraryを使っていた案件では、名称が同じだからといって対応する部品を決めないでください。原生Sketch環境でライブラリの出所と最新版を確認する方が安全です。

シーン別の判断

小規模な画面修正で、コンポーネントの親子関係が明確ならFigma内で修正できます。一方、入力フォーム、ナビゲーション、状態違いが多いデザインシステムでは、見た目の修正だけでは後工程の再利用性を失います。

その場合は、全コンポーネントを一度に再構築するのではなく、利用頻度の高い部品から代表画面で検証します。再接続できないもの、上書きが欠落したもの、入れ子関係が崩れたものを分けて工数を見積もります。

第四段階：色、効果、画像を見た目と構造で分ける

色やテキストの共有スタイル、影、グラデーション、マスク、描画モードは、視覚的には近くても編集構造が変わることがあります。Figmaのスタイルに関する公式仕様を基準に、次の三つへ記録してください。

  • 保持：色、効果、スタイル、素材が原稿と一致している。
  • 変化：見た目または編集方法が変わっている。
  • 要確認：原稿側の情報不足で判断できない。

静止画として納品するだけなら、見た目の一致を優先して局所修正できます。デザインシステムとして維持するなら、共有スタイルの再作成、効果の編集可能性、部品への再適用まで確認します。

画像が表示されない場合は、Figma側だけを疑わないでください。Sketchで元ファイルを開き、画像が埋め込まれているか、リンク先が存在するかを確認します。Sketchのファイルを開く・確認する公式手順では、原稿を開いて内容を確認する流れが示されています。

読み込みに失敗したときの分岐

Figmaへの読み込みが完了しない場合、まずSketchで原ファイルが正常に開くかを確認します。Sketchでも開けないなら、ファイル破損、欠落素材、保存状態を疑います。Sketchで開けるなら、移行用副本をページや機能単位に分けて、どの範囲で失敗するかを調べます。

Sketchのインポートと書き出しに関する公式資料も参照し、読み込み前のファイル形式や素材の扱いを確認してください。大容量の案件や、古い版から長期間更新されてきた案件では、全体を何度も読み込むより、複製した小さな範囲で試す方が原因を限定しやすいです。

Macがないため原ファイルの検査ができない場合は、Windows上で無理に修正を続けない選択もあります。短期間だけMACCOMEの日本語サービス案内から遠隔Macの利用条件を確認し、Sketchで原稿、ライブラリ、素材を確認してからFigmaへ戻す流れです。

FAQ：移行時に詰まりやすいポイント

SketchをFigmaにインポートした後、どこから検収すべきですか？

最初から全ページを見るのではなく、文字量が多い画面、コンポーネントの状態が多い画面、複雑な画像効果を使う画面を基準にします。原稿画像、Figmaの読み込み結果、必要ならSketchで開いた原稿を横並びにし、フォント、部品、効果、素材の順で確認すると、見落としを抑えられます。

Symbolsの対応関係が分からないとき、名前だけで判断してよいですか？

名前だけでの判断は避けてください。同名の部品でも、状態、上書き項目、入れ子構造、外部ライブラリの版が異なる可能性があります。元のSketchライブラリを確認できるなら、メイン側と利用側の関係を確認します。確認できない場合は、再利用性が必要な部品を「要再構築」として記録します。

Figma上で見た目が一致していれば、そのまま納品できますか？

静止画だけの納品なら、視覚的な一致を主基準にできる場合があります。ただし、開発用のFigmaファイルやデザインシステムで使う場合は、コンポーネント、共有スタイル、テキスト設定が編集可能な形で残っているか確認が必要です。見た目が同じでも、構造が失われていれば後の更新作業で問題になります。

Sketchの原稿が古いかどうかは、どのように判定しますか？

ファイルの更新日時だけで決めず、依頼元が示した画面一覧、仕様書、書き出し画像、ライブラリの更新履歴を照合します。Figmaへ移した後に差が出た場合も、変換による差なのか、元原稿が古いことによる差なのかを分けて記録してください。判断できない項目は、納品前に依頼元へ確認します。

遠隔Macは、どの段階で使うと無駄がありませんか？

文字の置換や単純な色修正だけなら、まずFigma内で対応できます。原ファイルが開けない、外部ライブラリの出所を確認できない、複雑な効果やSymbolsの関係を調べる必要がある場合に、遠隔Macを短期利用する意味が出ます。確認、整理、再読み込み、検収を同じ作業期間にまとめると、利用目的が明確になります。

納品前に使う検収チェック

次の項目を、基準画面ごとに記録してください。チェックが付かない項目を残したまま、移行完了とは判断しません。

  • [ ] 原始Sketchファイルを変更せず保存した
  • [ ] 移行用のFigmaファイルを原本と分離した
  • [ ] 原稿画像または静的参考稿を保存した
  • [ ] フォント名、ウェイト、版、利用許可を照合した
  • [ ] 主要画面の改行、行高、ボタン寸法を比較した
  • [ ] メインコンポーネントとインスタンスの関係を確認した
  • [ ] 上書き内容と入れ子構造を確認した
  • [ ] 共有カラー、テキストスタイル、効果を記録した
  • [ ] 影、グラデーション、マスク、描画モードを確認した
  • [ ] 画像や書き出し素材の欠落がない
  • [ ] 未解決項目に担当者と確認内容を記録した
  • [ ] 原本、移行ファイル、問題記録、参考稿を同じ案件単位で保管した

判定は三つに分けます。Figma内で直せる軽微な差、Sketchへ戻って確認する差、デザインシステムとして再構築する差です。これにより、「全部作り直す」か「問題なし」と決めつけず、修正範囲を現実的に管理できます。

既存環境と遠隔Macを比較して決める

WindowsだけでFigmaの修正を進める方法は、軽微な文字・色・画像差には向いています。しかし、原生Sketchでのファイル確認、外部ライブラリの調査、複雑なSymbolsの整理は進めにくいことがあります。自分でMacを購入する方法は継続案件には合いますが、移行作業のためだけなら初期費用、保管、更新、利用しない期間の負担が残ります。

選択肢 向いている作業 注意点
Windows＋Figma 軽微な見た目修正、共同確認 原ファイルやSketchライブラリを確認しにくい
手元のMac＋Sketch 継続的な制作、原稿の管理 移行だけでは設備負担が大きくなりやすい
遠隔Mac＋Figma 短期の原稿確認、整理、再移行 通信品質と作業時間を先に確認する
Figmaで構造を再構築 長期運用する新しい設計システム 部品の優先順位と工数管理が必要

移行案件だけのために環境を増やすなら、Mac miniの利用プランを確認し、必要な期間と作業内容を先に整理してください。遠隔操作は通信状態に左右されるため、細かな描画作業を常時行う用途より、原ファイルの確認、整理、書き出し、検収のように目的を区切った作業に適しています。

Windows環境だけで進める現在の方法には、原稿を開けない、ライブラリの関係を推測するしかない、移行失敗の原因を切り分けにくいという弱点があります。Macを購入して常設する方法にも、移行後に利用頻度が下がれば費用と管理負担が残るという弱点があります。原生Sketchでの確認が一時的に必要な案件なら、MACCOMEの遠隔Macを短期の作業環境として使い、整理・再移行・検収が終わった時点で継続利用が必要か判断するのが現実的です。