Figma Dev Mode徹底解剖：できること・できないことと開発連携の全貌

こんにちは！UIデザイナーのYunyです。

この記事はこんな方に向けて書いています

• Figma Dev Modeの具体的な機能詳細を知りたい方
• ツールで「どこまで自動化できるのか（できないのか）」を把握したいエンジニアの方
• スムーズな引き継ぎのために、デザイナーとして気を配るべきポイントを知りたい方

昔、エンジニアの方にデザインデータを渡した直後、Slackで「既存パーツでは16pxが使われていますが、今回のデータは24pxになっています。どちらが正解ですか？」と何往復もやり取りをした経験があります。
お互いに悪気はないのですが、デザインの意図を正確に読み取ってもらうのは思いのほか難しく、確認作業だけでかなりの時間を消耗していました。

そんな状況を一変させたのが、Figmaの「Dev Mode（開発モード）」の登場です。
自分が意識してこのモードを活用するようにしたところ、エンジニアとの確認の手間が劇的に減ったと個人的に感じています。
ただ、その状態を作るためには意外と簡単にできる「ちょっとしたコツ」が必要だったため、今回改めて整理してみました。

この記事では、Figma Dev Modeで「できること」と「できないこと」をシンプルかつ詳細にまとめます。
デザイナーとエンジニアが気持ちよく協業するために、ぜひ参考にしてください。

Figma Dev Modeで「できること」（詳細機能）

Dev Modeは、デザイナーが作成した見た目のデータを、エンジニアが実装に直結する数値やコードとして引き出すための専用ワークスペースです。
具体的な機能を見ていきましょう。

コードとバリアブルの自動生成

要素を選択するだけで、CSSやSwift、AndroidのComposeなどのコードスニペットが瞬時に生成されます。
単に色コード（#FFFFFFなど）が表示されるのではなく、デザイナーが設定したバリアブル（Variables）の名前がそのまま紐づいて出力されるのが最大の強みです。

これにより、エンジニアは「この色はどの変数を当てはめればいいのか」と推測する必要がなくなります。
指定されたトークンをそのままコピーするだけで実装を進められるため、コーディングのスピードと正確性が大幅に向上します。
例えば、背景色として「bg-surface-primary」といった変数が定義されていれば、出力コードにもそのまま反映されるため、手戻りのリスクがほぼゼロになります。

変更履歴の差分（Diff）比較

「デザイン修正しました！」と連絡を受けたものの、「具体的にどこが変わったのかわからない」という経験はないでしょうか。
Dev Modeの「Compare changes（変更の比較）」機能を使えば、前回から何がどう変わったのかを視覚的に比較できます。

変更されたプロパティ（余白の数値変更やカラーの変更など）だけがハイライト表示されるため、変更点を探すという不毛な作業を完全にゼロにできます。
過去の私のプロジェクトでも、「ここの角丸をちょっとだけ変えました」という口頭での曖昧な共有による実装漏れがよくありましたが、この機能のおかげでそうしたヒューマンエラーが物理的に起きなくなりました。
デザイナー側からしても、いちいちドキュメントにまとめる手間が省けるため、双方にとって大きな時間短縮につながります。

VS Codeとのシームレスな連携

Figmaを開いて、コードエディタを開いて、またFigmaに戻って……という画面の往復は、集中力を削ぎます。
Dev ModeはVS Codeの公式拡張機能（Figma for VS Code）を提供しており、エディタ上で直接Figmaのデザインを確認できます。

コードを書きながら、同じ画面内でデザインの余白や色、アセットをInspect（検証）することが可能です。
コンテキストスイッチを最小限に抑えることで、エンジニアは実装作業に深く没頭できるようになります。
実際に私の関わっている現場でも、フロントエンドエンジニアから「画面を何度も往復しなくてよくなり、1日の疲労度が全然違う」と非常に好評でした。
また、VS Code上でFigmaのコメント機能にもアクセスできるため、疑問があればその場で直接デザイナーに質問を投げることも容易です。

「Ready for dev（開発準備完了）」の明示

デザインファイルの中には、まだ作りかけの画面と、実装に進めてよい画面が混在しがちです。
Dev Modeでは、デザイナーが特定のフレームに「Ready for dev」というステータスを付与できます。

このマークがついた画面だけをエンジニアが確認できるため、「まだ作業中だったのに実装してしまった」という事故を防げる利点があります。
さらに重要なのは、開発が進んでいるデータを安易に変更しづらくなることで、「データをすぐ編集するのではなく、まずは一言相談を入れる」というコミュニケーションフローが明確になった点です。
作業の境界線がシステムとして引かれることで、チーム全体の連携がよりスムーズになります。

デザイナー自身がDev Modeを活用するメリットとできること

Dev Modeはエンジニアのためだけのツールではありません。
デザイナー自身もこのモードを活用することで、実装を見据えたデータ作りや、より高度な協業が可能になります。
具体的にデザイナーができる活用事例を箇条書きで紹介します。

• 実装視点でのセルフチェック（検証）
  自分が作成したデザインをDev Modeでインスペクトすることで、余白やオートレイアウトの構造が、エンジニアから見て「論理的に読み取れるCSS」になっているかを客観的に確認できます。
• 専用プラグインを活用したデータクリーンアップ
  Dev Modeで利用できる強力なLint系プラグインやアノテーションツールを使い、実装前にバリアブルの適用漏れや構造エラーを自動検知して修正することが可能です。
• 実装時の表示崩れに対する「逆提案」
  エンジニアと同じDev Modeの画面（Box Modelなど）を見ながら対話することで、「なぜこのデザインだと実装が難しいのか」をデザイナー自身が理解し、実装しやすいレイアウトへと即座に修正提案が行えます。

Figma Dev Modeで「できないこと」（注意点と限界）

非常に強力なDev Modeですが、誤解されがちな限界も存在します。
導入前に以下の「できないこと」を把握しておくことが重要です。

無料プランでの利用（旧Inspectからの移行）

以前は誰でも無料で使えたInspect（インスペクト）パネルの延長として考えられがちですが、現在のDev Modeは有料機能です。
フル機能を利用するためには、開発者向けの「Devシート」またはデザイナーと同等の「Fullシート」の契約が必要になります。

無料プラン（Starterプラン）ではアクセスできないため、チーム内でどの程度の頻度で実装連携が発生するかを見極め、適切なライセンス管理を行う必要があります。
※シートごとの詳細な金額や機能差分については、公式のFigmaの料金プランをご確認ください。

コストに見合うだけの効率化ができるかどうかが、導入の判断基準となります。
予算が限られている場合は、どのメンバーにDevシートを付与するか、運用ルールを明確にしておくことが求められます。

複雑なロジックや動きの完全なコード化

Dev Modeが自動生成するのは、あくまで静的なスタイルやレイアウト情報（HTML/CSSの構造に近いもの）です。
画面のスクロールに応じた複雑なパララックス効果や、JavaScriptを用いた動的な状態遷移のロジックまでは出力してくれません。

そのため、「Dev Modeがあればフロントエンドのコーディングが不要になる」というのは完全な誤解です。
生成されたコードはあくまで実装のベースや参考値として使い、最終的な動きやコンポーネント化はエンジニアの手に委ねられます。
インタラクションの細部は、別途プロトタイプ機能を使って動きを共有し、口頭やテキストで補足説明を行うプロセスが依然として必要です。

整理されていないデータからの都合の良い変換

ツールがどれほど進化しても、元のデザインデータが乱雑であれば、出力されるコードも使い物になりません。
デザイナーがオートレイアウト（Auto layout）を使わずに要素を適当に配置していたり、色をスタイル登録せずに直書きしている場合、Dev Modeはそれをそのまま読み取ってしまいます。

結果として、絶対配置（position: absolute;）だらけの無秩序なCSSが生成されてしまいます。
「デザイナーのデータの綺麗さ」が、「生成されるコードの品質」に直結するというシビアな現実があります。
Dev Modeは、デザイナーの設計意図をそのまま出力するツールに過ぎないということを忘れてはいけません。

エンジニアを助ける、デザイナー側の準備（運用ルール）

Dev Modeの恩恵を最大限に受けるためには、ツールに頼る前にデザイナー側の準備と意識改革が不可欠です。
エンジニアが迷わず実装できるデータを作るためのポイントをまとめます。

オートレイアウトの徹底

余白（Padding / Gap）の数値をコードとして正確に引き渡すためには、すべての要素にオートレイアウトを適用することが大前提となります。
画面の端からの距離や、要素間のマージンが規則正しく設定されているか、納品前に必ずチェックしてください。
オートレイアウトのルールが崩れていると、エンジニアが手作業で数値を修正する羽目になり、ツールの導入効果が半減してしまいます。

【関連記事】 オートレイアウトの基礎や美しいデータ構築について詳しく知りたい方は、こちらの記事もあわせてご覧ください。
※関連記事のURLをここに設定してください

コンポーネントとバリアブルの整備

ボタンや入力フォームはVariant（バリアント）として整理し、Hover時などの状態遷移を網羅しておく必要があります。
また、カラーやタイポグラフィ、角丸の数値などは必ずバリアブル（Variables）またはスタイルとして登録し、名前をつけて管理してください。

こうしたオートレイアウトの徹底やコンポーネント・バリアブルの整備は、最近よく耳にする「AI Readyなデータ作り」に直結しています。
構造化された美しいデータはAIツールが解釈しやすいため、Dev Modeを使う・使わないに関わらず、これからのデザイナーにとってより重要になっていく視点だと言えます。

Figma Dev Modeに関するよくある質問（FAQ）

Q. 無料プラン（Starter）でもDev Modeは使えますか？
A. 残念ながら、現在のDev Modeワークスペースへのアクセスは有料プラン（Professional以上）限定です。ただし、無料の「Viewシート」のままであっても、CSSのコピーや最低限の距離測定などの基本的なインスペクト（閲覧）機能は引き続き利用可能です。

Q. Dev Modeを使えばフロントエンドエンジニアは不要になりますか？
A. 不要にはなりません。Dev Modeが生成するのはあくまで静的なスタイル（CSSやレイアウト情報）のみです。JavaScriptによる複雑な状態遷移やアニメーションの実装、セマンティックなマークアップ、コンポーネントの最適な設計は、引き続きエンジニアの専門的なスキルが不可欠です。

終わりに

最後までお読みいただき、ありがとうございます！

Figma Dev Modeは、デザインと実装の間にある見えない壁を取り払い、チームの生産性を大きく引き上げてくれます。
しかし、その真価は「ツールの限界」を理解し、お互いが歩み寄るルールを作って初めて発揮されるものです。

デザイナーは「エンジニアが実装しやすいデータ」を意識し、エンジニアは「デザインの意図を汲み取る」ことで、素晴らしいプロダクトが生まれます。

これからも、より良いUX/UIを追求するチーム作りを一緒に楽しんでいきましょう。
それでは、良いデザインライフを！