FigmaToCodeは何を変換し、何を推測しないのか

FigmaToCodeの役割を正しく区切る

bernaferrari/FigmaToCodeは、Figmaで選択したフレーム、コンポーネント、グループ、個別レイヤーから、編集可能なコードの骨格を生成するプラグインです。READMEが想定する場面は、ビジュアルデザインと実装の間で、コピーして修正できる読みやすい出力を得ることです。プロジェクトの説明には、レスポンシブなページとアプリをHTML、Tailwind、Flutter、SwiftUIで生成するとあります。

変換はFigmaのプラグインサンドボックス内で決定的に動き、AIモデルを呼び出さず、リポジトリを調べず、選択内容を別サービスへ送らないとREADMEは説明します。したがって、画像から意味を推測する生成AIではなく、Figmaノードのレイアウトとスタイル情報を別の表現へ写す小さなコンパイラーとして見るのが適切です。メタデータでは、言語はTypeScript、ライセンスはGPL-3.0、既定ブランチはmain、アーカイブ状態はfalseです。

同じ選択から四つの出力系列

HTML系列では、素のHTML、React JSX、Svelte、styled-componentsを選べます。Tailwind CSS系列はHTML、React JSX、Twigを出力し、Tailwind 3とTailwind 4の両方に対応するとREADMEに記載されています。Flutter系列は完全なアプリ、stateless widget、スニペットを選び、SwiftUI系列はプレビュー、`View`構造体、スニペットを選べます。

生成コードとローカル画像を小さなスターターへまとめる機能もあります。WebではVite、Next.js、静的HTML、Flutterではソース、`pubspec.yaml`、アセット、セットアップ手順、SwiftUIではソース、アセットカタログ、セットアップ手順が対象です。出力は依存を少なくした開始点であり、完成した本番アプリケーションではないとREADME自身が線を引いています。プロジェクトへ取り込むときは、生成ディレクトリをそのまま本体にせず、既存の命名、ルーティング、ビルド設定、コンポーネント規約へ合わせて差分として扱います。

レイヤー情報から生成設定へ

設定項目は選択したターゲットに適用できる場合だけ表示されます。Figmaのレイヤー名をクラスへ含めるか、値をそのまま保持するか、間隔と色を近いTailwindトークンへ丸めるかを選べます。Tailwind 4の構文やカスタムクラスプレフィックス、対応するFigmaのカラーバリアブル、HTML内のBase64画像、Web向けSVG埋め込みも選択肢です。フレームワークごとにファイル、コンポーネント、スニペットのモードを切り替えられます。

画面には変換結果のプレビュー、明るい背景と暗い背景、警告、抽出された色とグラデーション、コードコピー、プロジェクトのダウンロードが用意されています。ここで見るべきなのは、見た目が近いかだけではありません。トークンへ丸めた結果がデザインシステムと合うか、画像埋め込みが配布サイズを膨らませないか、レイヤー名が保守しやすい命名になるかを確認します。設定の初期値や各効果の対応範囲はターゲット別に異なるため、同じFigma選択を複数ターゲットへ出して比較する場合も、人間のレビューを残します。

プラグイン内で完結するデータ経路

リポジトリの`manifest.json`は、公開プラグインがFigmaへ示す設定です。READMEに示された境界では、`permissions`は空配列、`networkAccess.allowedDomains`は`none`です。選択したノードはFigma Plugin APIで読み取られ、メモリ上で正規化され、TypeScriptのターゲット別ジェネレーターで変換され、プラグインの画面へ戻ります。READMEはテレメトリ、デザインのアップロード、外部モデル、専用ユーザーアカウントがないと説明します。

このプライバシー説明はプラグインが追加する通信先についてのものです。Figma自体は接続された製品で、ファイルの処理は利用者のFigmaプランとポリシーに従います。ここを混同して、Figmaファイル全体が常にローカルにとどまると宣伝するのは不正確です。組織で使う場合は、Figma側の共有権限、プラグイン実行を許可するポリシー、生成したアセットの保存先を別に確認します。manifestを読めることは、組織の情報管理審査を済ませたことを意味しません。

得意なレイアウトとターゲット差

READMEが対応範囲として挙げるのは、Auto Layout、ネストしたフレーム、グループ、整列、サイズ、積み重ね、通常フローと絶対配置の混在です。文字組み、塗り、境界線、角丸、多くのエフェクト、色変数、複数種類のグラデーション、画像とローカルアセット、Webとネイティブのレスポンシブな骨格も対象です。変換不能な細部は、結果を黙って近似するのではなく、警告として返す方針が説明されています。

ただし、Figmaの視覚構造とアプリの意味構造は同じではありません。星、ポリゴン、線、グラデーション、効果はターゲットのAPIに同等の表現がないことがあり、Webでは任意扱いのベクターがネイティブでは限定されます。大きな選択範囲や複雑なレイヤー木はメモリを多く使うため、ページ全体を一度に変換するより、再利用するカード、ナビゲーション、入力部品を個別に変換する方が境界を修正しやすい設計です。

自動化しない領域が品質を決める

FigmaToCodeはAI推論を行わず、セマンティクス、インタラクション、プロンプトによる再設計を発明しません。リポジトリの既存コンポーネントを調べたり、Figmaへアプリを逆輸入したり、生成ファイルを継続同期したり、後のデザイン変更をコードへ押し戻したりもできません。状態管理、データ読み込み、ナビゲーション、バックエンド動作、業務ルールは出力に含まれません。

アクセシビリティも自動的に完成しません。意味のある要素、ラベル、キーボード操作、動的文字サイズ、レスポンシブのブレークポイントは、実装側で決めます。見た目のスクリーンショットが一致しても、読み上げ順、フォーカス移動、エラー表示、タッチ領域、空状態を満たすとは限りません。チームの受け入れ条件には、コンパイルだけでなく、意味付け、操作性、実データ、狭い画面と広い画面での振る舞いを含めます。

変換パイプラインと開発者が見る場所

変換の流れは、選択したFigmaノードとレイアウト、スタイルのメタデータを読む、内部ツリーへ正規化する、親子関係やAuto Layout、整列、サイズ、位置を整理する、選んだHTML、Tailwind、Flutter、SwiftUIのバックエンドで生成する、コード、プレビュー、アセット、警告を画面へ返す、という段階で説明されています。ルールが公開TypeScriptで書かれているため、変換結果の理由をコードから追える構成です。

ローカル開発のREADMEはNode.js 24以上とpnpm 11を要件に挙げ、リポジトリを`packages/backend`、`packages/plugin-ui`、`packages/types`、`packages/tsconfig`、`apps/plugin`、`apps/web`へ分けています。`packages/backend`には中間表現、コードジェネレーター、スターター出力があり、`apps/plugin`にはFigmaのコントローラーとUI入口があります。公開された変換規則を改修するときは、サポート対象のFigmaノード、ターゲット別の差、警告文、アセットの扱いを同じ変更単位で確認します。

編集部の結論

FigmaToCodeは、Figmaの選択範囲から読みやすい見た目の骨格を作り、開発者が既存コードへ組み込むための出発点として使う道具です。AIモデル、外部アップロード、リポジトリ接続、状態管理、バックエンド処理を提供する製品ではありません。導入するなら小さな再利用部品から変換し、警告、生成画像、レスポンシブ境界、意味構造、キーボード操作を人間が確認してから採用します。

公式情報源

1. Official documentation
2. Official README
3. Project repository