デザインからコードへの受け渡しとは

デザインからコードへとは、Figma などのツールで下した決定を動作するフロントエンドのコードに変える工程を指します。長く使える方法はキャンバスからマークアップを生成することではなくデザイントークンを受け渡すことです。画面が変わってもトークンは有効なままですが、生成されたマークアップはそうではありません。

混同されがちな二つのやり方

キャンバスからコードを生成する。 ツールを Figma のフレームに向けると JSX や HTML が返ってきます。デモでは非常に映えますが、本番では期待外れになります。出力はあなたのコンポーネントライブラリと何の関係もなく、入れ子はデザイナーがレイヤーをどうまとめたかを反映しており、デザインが変わればまた生成し直して手を入れた分は失われます。

決定を移す。 代わりにトークン、つまり色・余白・タイポグラフィ・角丸を移し、それを参照するコンポーネントをエンジニアが作ります。デモでは地味です。しかしこちらが生き残ります。レイアウトが変わってもトークンは有効なままですし、コードは人が書き、人が保守できるコードのままだからです。

最初のやり方を試したチームは、ほぼ例外なく二つ目に落ち着きます。

受け渡しが失敗し続ける理由

失敗するのは受け渡しの瞬間ではありません。その後のすべてです。

デザイナーが Figma で色を更新します。その変更はスタイルシートに届かなければなりません。自動の経路はないので、チャンネルのメッセージ経由で届き、誰かが読むか、読まないかになります。それを一年分の変更すべてに掛けてください。

どちらの側も正しく仕事をしています。両者をつないでいるのは、覚えている人間です。

Figma API の制約

この分野のツールを評価する前に知っておく価値があります。Figma の REST API のうちバリアブルを読むエンドポイントは、Enterprise プランでのみ利用できます。

つまり、Figma のバリアブルを REST API 経由で同期するツールは、Enterprise アカウント上のデモでは動き、多くのチームが使っている Professional プランでは何もしません。プラグインはこの制約を受けません。プラグイン API を使ってファイルの内側からバリアブルを読むからです。同期ツールを比べるなら、それぞれどちらを使っているか尋ねてください。

うまく回るループの形

デザインの決定はトークンとして、両者が参照する一か所に置かれる。
デザイン側の変更は差分として届く。上書きではない。
編集権限を持つ人がレビューして適用する。
リポジトリにプルリクエストが開き、通常のコードレビューを通る。
AI エージェントは同じトークンをその場で読むので、生成されたコードはシステムの外ではなく中に着地する。

途中のレビュー段階は、削るべき摩擦ではありません。チームのトークンを黙って書き換えるツールは、自動化が生む価値より多くの信頼を失わせます。

Flash DSM との関係

Flash DSM は Figma プラグインを伝送路として使うため、どの Figma プランでも動きます。公開はレビュー可能なトークン差分になり、承認された差分はプルリクエストとして開けます。