デザインの引き渡し：デザインを損なうことなくFigmaを開発者に引き渡す方法

ほとんどのデザイン引き継ぎは同じように失敗に終わります。デザイナーはFigmaファイルを納品します。開発者はそれを開き、3つの質問をし、2つの回答を得て、近似的なデザインに取り掛かります。2週間後、デプロイされた製品はコンセプトの80%程度しか再現できず、デザイナーは苛立ち、開発者は防御的になり、プロジェクトマネージャーはギャップを「イテレーション」と言い訳します。このワークフローは10年間、何の改善も見られません。

このガイドは、このワークフローを置き換えるものです。2026年の真の引き継ぎは、会議ではなくシステムです。曖昧さを排除するFigmaファイル構造、デザインを機械可読にするトークン規律、コーディング担当者がデザインを直接読み取れるFigmaMCP配線、そして出荷前に逸脱を検出するレビューループ。

設計ハンドオフとは何か

設計ハンドオフとは、設計が実装可能なコードになる瞬間です。 その瞬間まではすべて設計であり、それ以降はすべて開発です。ハンドオフは2つのシステム間のインターフェースであり、設計の機械可読性によって成否が決まります。

従来の定義（設計者が開発者にファイルの説明を行う会議）は失敗パターンです。説明は拡張性に欠け、人員変更に対応できず、コーディング担当者が実際に必要とするものと一致しません。2026年の定義は異なります。ハンドオフとは、開発者（またはClaude Code担当者）が、意図を誰にも尋ねることなく設計を構築できる構造化された成果物です。

その成果物はFigmaファイルに格納されます。ファイルの品質がハンドオフの品質を決定します。別途ハンドオフ文書、注釈付きPDF、不足部分を補うNotionブリーフは存在しません。ファイル自体がブリーフです。

引き継ぎに耐える4層構造のFigmaファイル

引き継ぎ準備が整ったFigmaファイルは、4つの層で構成されています。いずれかの層を省略すると、開発者は推測するしかありません。4つの層すべてを構築すれば、開発者（またはAIエージェント）は何も質問する必要がなくなります。

層1：トークン

トークンは、デザインにおけるすべての値の真の情報源です。 色、間隔、タイポグラフィ、半径、影、モーション。すべてのコンポジションにおけるすべての表示値は、トークンに帰着します。

トークンはFigma変数（チームが旧ワークフローを使用している場合はトークンスタジオ）に格納されます。トークン名は、視覚的なものではなく、意味に基づいて命名されます。color/background/primaryであってgray-50ではありません。spacing/lgであって24pxではありません。意味に基づいた名前は、デザイン変更後も維持されます。文字名がそのまま使われていると、誰かが値を変更した途端に機能しなくなります。

トークンのないハンドオフファイルは、開発者一人ひとりが色、間隔、半径、配置場所などについて何百もの細かい決定を下すファイルです。これらの何百もの決定が十数個のコンポーネントに及ぶと、デプロイされた製品はコンプと一致しなくなります。解決策は「もっと注意を払う」ことではありません。解決策は、最初からトークンを強制的に適用することです。デザインシステムガイドの解説では、トークンの完全な分類体系を説明しています。

レイヤー2：コンポーネント

コンポーネントは、デザインシステムが提供する再利用可能な単位です。すべてのボタン、入力フィールド、カード、モーダル、ナビゲーション、プリミティブは、すべてのバリエーション、すべての状態、すべてのレスポンシブ動作が組み込まれたFigmaコンポーネントとして存在します。

ルール：コンポーネントでないものはページレイヤーに到達しません。「独立した」要素（ヒーローの中に手動でスタイル設定された単発のボタンなど）は、将来バグの原因となります。ブランドカラーが初めて変更されたとき、その独立した要素は更新されません。 2回目も、次の回も、同じ結果にはなりません。6か月後には、デザインシステムはグリュイエールチーズのように古びてしまいます。

バリエーションはコンポーネントと同じくらい重要です。ボタンは単一のコンポーネントではなく、サイズバリエーション、タイプバリエーション（プライマリ、セカンダリ、ゴースト、破壊）、状態バリエーション（デフォルト、ホバー、アクティブ、無効、ローディング）を持つボタンファミリーです。開発者が作成する必要のあるすべてのバリエーションは、ファイル内に存在していなければなりません。存在しない場合、開発者はそれを考案することになりますが、考案されたバージョンは、次のデザイナーが思い描くデザインから乖離してしまいます。

レイヤー3：パターン

パターンとは、コンポーネントを再利用可能なレイアウトブロックにまとめたものです。ヒーローセクション、機能グリッド、ナビゲーションバー、フッター、価格表などがこれに該当します。これらは完全なページではなく、ページを構成するマクロです。

パターンはコンポーネントとページの間に位置します。パターンは、コンポーネントが何であるかだけでなく、それらがどのように関連しているかを決定するため、ほとんどの「デザイン意図」が宿るレベルです。ヒーローパターンは、見出し、小見出し、CTA、そして補助的なビジュアルを、この順序で、この間隔で、各ブレークポイントでこのサイズ関係で配置するというものです。

パターンはレスポンシブデザインの動作も記述します。パターンは、少なくとも3つのブレークポイントバリアント（モバイル、タブレット、デスクトップ）が定義されて初めて、真に文書化されたと言えます。ブレークポイントのないパターンは、システムコンポーネントを装った装飾的なワイヤーフレームに過ぎません。

レイヤー4：ページ

ページは最終的な構成要素です。ページはパターンを使用し、パターンはコンポーネントを使用し、コンポーネントはトークンを使用します。ページが存在する時点で、すべての値、すべてのプリミティブ、すべてのブロックは既に決定されています。

引き渡し準備が整ったページはパターンから構成され、新しい要素は何も追加されません。ページにシステムに存在しない新しい色、新しい間隔の値、または新しいボタンのスタイルが導入された瞬間、4層モデルは崩壊し、開発者はページを決定論的に再現できなくなります。

ページには、その目的も明記する必要があります。ヒーロー、見出し、主要なCTA、コンバージョンパスなどです。ここでの注釈は「開発者に何を作るべきかを指示する」のではなく、「実装が現実世界の制約に直面した際に、適切なトレードオフ判断ができるように、エージェント（人間またはAI）にページの目的を伝える」ものです。

トークン規律は耐荷重壁

4つのレイヤーのうち、トークンは多くのチームが見落としがちなレイヤーであり、その欠如がハンドオフを最も早く阻害するレイヤーです。トークン規律が守られたファイルであっても、コンポーネントが不完全であれば、コンプにほぼ適合します。一方、トークン規律がずさんなファイルであっても、コンポーネントが完璧であれば、近似値の近似値しか適合しません。

トークン規律を維持するための3つのルールがあります。

すべての可視値はトークンに解決されます。 ほとんどではなく、すべてです。色、間隔、半径、タイポグラフィの値がトークンでない場合、それは将来のバグとなります。

トークンは意味的に命名されます。 surface/raised、text/muted、border/strong。 gray-100、gray-400、gray-700ではありません。セマンティック名は意図に対応します。リテラル名は特定のグレーの濃淡に対応し、ブランドが更新された瞬間に機能しなくなります。

**トークンは単一の情報源を持ちます。**トークンは1つのFigmaライブラリに格納され、一度エクスポートされ、あらゆる場所で使用されます。3箇所で定義されたトークンは、どのバージョンが最新か分からないため、実質的には0箇所で定義されたトークンと同じです。

デザイナーのための色彩理論では、トークン対応のパレットをゼロから構築する方法について解説しています。タイポグラフィシステムデザインでは、タイプトークンについて同様の解説を行っています。

Figma MCPによるハンドオフの変更

2026年にハンドオフワークフローに最も大きな影響を与える変更は、Figma MCPです。 Figma が公開するモデルコンテキストプロトコルサーバーにより、コーディングエージェント（Claude Code、カーソル、Claude デスクトップ）は、トークン、コンポーネント、変数、Code Connect マッピングを含む Figma ファイルを直接読み込むことができます。

これにより、計算方法が変わります。開発者はもはや目視で設計を書き写す必要はありません。エージェントがファイルを読み込み、コンポーネントを生成し、開発者がレビューします。近似精度は低下し、処理速度は飛躍的に向上します。ハンドオフはもはや変換ステップではなく、コンパイルステップとなります。

ただし、注意点があります。MCP は、その下にあるファイルの質に依存します。クリーンなトークン、実際のコンポーネント、Code Connect バインディングを含む 4 層構造のファイルは、クリーンなコードを生成します。トークンのない緩いファイルは、以前と同じ近似精度ですが、処理速度が速くなります。MCP はファイルを拡張するだけで、元のファイルを復元するわけではありません。

セットアップの詳細については、figma mcp ガイドでClaude Code、カーソル、Claudeデスクトップ間の配線全体を解説しています。デザイナーのためのクロード・コードでは、エージェントがデザイナーの作業にどのように組み込まれるかを説明しています。

コードコネクトレイヤー

コードコネクトは、Figmaコンポーネントと、それを実装する本番コードコンポーネントとの間の明示的なリンクです。これがないと、MCP駆動の生成は、コンポーネント名、プロパティAPI、インポートパスを推測する必要があります。コードコネクトを使用すると、生成は決定論的になります。

実際の製品UIをリリースするチームは、コードコネクトを必須と考えるべきです。セットアップコストはわずか（コンポーネントごとに1つのマッピング）で、その効果は将来の生成ごとに累積されます。コーディングエージェント、Storybook統合、デザインQAツール、ビジュアル差分システムなど、すべてが恩恵を受けます。

マッピングはコンポーネントごとに小さな.figma.tsxファイルに格納され、Reactコンポーネント、そのプロパティ、そしてFigmaバリアントがそれらのプロパティにどのようにマッピングされるかを宣言します。その後、エージェントまたは開発者はFigmaからコンポーネントインスタンスを取得し、完全に型付けされたReactを受け取ります。

ハンドオフレビューループ

ハンドオフはファイルが出荷された時点で完了するのではなく、デプロイされた製品がコンポーネントと一致した時点で完了します。出荷前に3つのレビューチェックポイントでずれを検出します。

チェックポイント1：ハンドオフ前の設計自己監査

開発にファイルを送信する前に、デザイナーは5つのチェックを実行します。

すべての表示可能な値がトークンに解決されていること。すべてのページレベルの要素がコンポーネントインスタンスであり、独立したプリミティブがないこと。すべてのコンポーネントがページで使用されるすべてのバリアントを持っていること。ページ上のすべてのパターンについて、すべてのレスポンシブブレークポイントが文書化されていること。すべてのページには、その主要な目的とコンバージョンパスが注釈として付けられています。

5つのチェックポイントのいずれかに該当するページは、開発ではなくデザイン段階に戻されます。まだ何も構築されていない段階で、最もコスト効率よく問題点を発見できるからです。

チェックポイント2：初回コンポーネントレビュー

開発者（またはエージェント）は、ページを作成する前にコンポーネントを構築します。デザイナーは、ページ作業を開始する前に、Figmaライブラリと照らし合わせてコンポーネントをレビューします。

この段階で、トークンのずれ、バリアントの欠落、プロパティAPIの不一致などを発見できます。コンポーネントレベルで修正すれば、すべての箇所で修正されます。ページレベルで修正すると、一度修正されただけで、次のページで再び問題が発生する可能性があります。

このチェックポイントで30分間のコンポーネントレビューを行うことで、後々のページレベルの修正作業を30時間削減できます。チームにとって圧倒的に有利な計算です。

チェックポイント 3: コンポーネントに対するビジュアル QA

ページがステージング環境にデプロイされた後、デザイナーはコンポーネントに対してビジュアル QA を実行します。「見た目が問題ないか」ではなく、「ピクセル単位で意図どおりにコンポーネントと一致しているか」を確認します。トークン、スペーシング、ウェイト、ブレークポイント、状態、モーションなど、すべてをチェックします。

QA は細かい指摘のリストではありません。4 層構造のファイルに対する構造化された比較です。違いがあれば、バグ、開発者が制約の中で下した設計上の決定、またはより良い実環境での実装に合わせて更新する必要のあるコンポーネントのいずれかです。これら 3 つの結果はすべて妥当です。重要なのは、違いを可視化して決定することであり、見過ごされたままリリースしてしまうことではありません。

このループを 2 つの独立したチームではなく、 1 つのワークフローとして実行するチームを希望する場合は、Brainy を雇用する を参照してください。ブランド、Web、および製品 UI は、ハンドオフのずれなくリリースされます。

ハンドオフ チートシート

これを保存し、デザインオペレーション ドキュメントにピン留めしてください。

| レイヤー | 保存場所 |同梱物 | 障害モード |

|-------|----------|---------------|--------------|

| トークン | Figma 変数 | 色、間隔、タイプ、半径、影、モーション | トークンに解決されない独立した値 |

| コンポーネント | Figma ライブラリ | ボタン、入力フィールド、カード、すべてのバリエーションを持つプリミティブ | ページ内で手動でスタイル設定された独立した要素 |

| パターン | Figma ライブラリ | ブレークポイント付きのヒーロー、ナビゲーション、フィーチャー、フッターアセンブリ | レスポンシブ動作のない1ブレークポイントパターン |

| ページ | Figma ファイル | パターンとコンポーネントで構成された最終構成 | システムに存在しない新しい値を導入するページ |

| ツール | 役割 | メリットが得られる場面 |

|---------|------|------------------|

| Figma 変数 | トークンの信頼できる情報源 | すべてのプロジェクト、例外なし |

| コードコネクト | Figma コンポーネントを React コンポーネントにマッピング | MCP が初めてコンポーネントを生成するとき |

| Figma MCP | コーディングエージェントにファイルを読み込ませる | Claude Code が初めて画面を構築するとき |

| ストーリーブック | 開発者向けのライブコンポーネントリファレンス | 複数の開発者によるチーム間の引き継ぎ |

| ビジュアル差分 (Chromatic、Percy) | デプロイ後のドリフトを検出 | 複数のデザイナーの作品をリリースするすべてのチーム |

2026年の変更点

過去18か月で、3つの変更により引き継ぎ方法が変更されました。

AIエージェントはファイルを直接読み込みます。 Claude Code、Cursor、Claude Desktop、およびv0はすべてFigmaからMCPまでを利用します。引き継ぎはもはや「デザイナーが説明し、開発者が実装する」ではなく、「デザイナーが構造化ファイルを納品し、エージェントがコードを生成し、開発者がレビューして統合する」という流れになりました。ボトルネックは翻訳からファイル品質へと移行しました。

Code Connectはprop APIのギャップを解消しました。 2026年までは、MCPによる生成ではprop名を推測する必要がありました。Code Connectのマッピングによってリンクが確定的になり、AI生成コンポーネントはデモレベルではなく、実際に統合可能なものになりました。

トークンは必須要件となりました。 3年前、トークン管理はトップレベルのデザインチームの成熟度を示す指標でした。今日では、AIツールを使用するあらゆるものを出荷するための前提条件となっています。トークンのないデザインシステムは、MCPにも、Code Connectにも、そしてファイルを読み取るすべてのコーディングエージェントにも見えません。

2026年に最もクリーンな製品を出荷するチームは、最も美しいモックアップを持つチームではありません。最も緊密な4層構造のファイル、最も厳格なトークン管理、そして最もクリーンなCode Connectバインディングを持つチームです。美しさは依然として重要です。それは構造に取って代わるものではなく、構造の上に積み重ねられるものです。

---

FAQ

デザインハンドオフとは？

デザインハンドオフとは、デザインツール（通常はFigma）から本番コードにデザインを転送するプロセスです。2026年、ハンドオフは4層構造のFigmaファイル（トークン、コンポーネント、パターン、ページ）を中心に構築され、開発者とAIコーディングエージェントが近似ではなく決定論的にデザインを実装できるようになります。

Figma を開発者に引き渡す最適な方法は？

4層構造のファイルを作成します。すべての表示値に対応するトークン、すべてのバリエーションを持つコンポーネント、すべてのブレークポイントを持つパターン、既存のパターンとコンポーネントのみで構成されるページを作成します。チームがMCP 駆動型コーディングエージェントを使用している場合は、Code Connect マッピングをレイヤーに追加します。3段階のチェックポイントレビューループ（引き渡し前の監査、コンポーネントファーストのビルドレビュー、コンポーネントに対するビジュアルQA）を実行します。

Figma 開発者モードとは？

Figma 開発者モードは有料プランで、デザイン仕様（CSS、iOS、Android）、コードスニペット、Code Connect マッピングパネルを、ファイルを閲覧する開発者に公開します。ネイティブコードをリリースするチームや、Figma 内で優れた開発者環境を求めるチームに役立ちます。トークン管理とコンポーネントバリアントを組み合わせることで、ほとんどの価値が相乗的に高まります。

デザインの引き渡しにFigma MCPは必要ですか？

厳密には必要ではありませんが、計算方法が変わります。MCPを使用すると、コーディングエージェントはFigmaファイルを直接読み込み、実際のトークンとコンポーネントバリアントに基づいてコンポーネントを生成します。MCPがない場合、開発者はデザインを目視で書き写すため、時間がかかり、デザインがずれやすくなります。Claude CodeまたはCursorを本番環境で使用しているチームは、MCPを組み込むことで大幅な効率向上を実現できます。

引き渡し後のデザインのずれを防ぐにはどうすればよいですか？

3つのルールがあります。ソースでのトークン管理（すべての可視値はトークンに解決される）。コンポーネントファーストビルド（開発者はページを作成する前にコンポーネントを作成し、デザイナーはページを作成する前にコンポーネントをレビューする）。デプロイ後の構造化されたビジュアルQA（雰囲気ではなく、4層構造のファイルとの比較）。ドリフトは人格の問題ではなく、プロセスの問題です。

最新のデザインハンドオフに必要なツールは？

最低限必要なのは、変数とコンポーネントを備えたFigmaです。次のステップは、Figma開発者モードと、型付きReactマッピング用のCode Connectです。さらに高度なステップは、FigmaMCPをチームが使用するコーディングエージェント（Claude Code、Cursor、Claudeデスクトップ）に統合することです。大規模チームの場合は、Storybookとビジュアル差分ツール（Chromatic、Percy）がスタックを完成させます。

ハンドオフは会議ではなくシステムです

デザインハンドオフはかつては一瞬の出来事でした。会議、Loom、Notionドキュメント、「質問があれば教えてください」Slackメッセージ。このモデルは拡張性に欠け、今や人間のウォークスルーではなく構造化された入力を必要とするAIエージェントに取って代わられつつあります。

2026年のモデルは異なります。ハンドオフはファイルです。ファイルはシステムです。システムは4つのレイヤーで構成されています。トークン、コンポーネント、パターン、ページ。これらのレイヤーを正しく構成すれば、開発者はデザインをそのまま出荷でき、エージェントはコンパイル可能なコードを生成し、QAプロセスは短時間で済みます。レイヤーを誤ると、コンプ単体でどれほど見栄えが良くても、下流のすべてのサーフェスが劣化します。

プロジェクトを1つ選び、4つのレイヤーに対してファイルを監査してください。最も大きなギャップを見つけ、まずそれを修正します。そして、新しい構造でハンドオフを再度実行し、実装がどれほど速く、よりクリーンに、より正確になるかを確認してください。

デザインと開発を一体化したチーム、契約書としてのファイル、そして引き継ぎのずれのないチームをお望みなら、Brainy を雇用する。同じチーム、同じシステム、同じ出荷製品。