Figmaに「送る」だけで、実装がレイヤーになる

お疲れ様です。みんみんです。

今回は、この半年で出てきた「デザインと実装をつなぐ」系の新機能を3つ触ってみたので、その記録を書きます。
社内の技術共有で発表した内容をそのまま記事にしたものです。

先に書いておくと、3つのうち1つは会社アカウントで使えず、結果が一番良かったのは一番地味な機能でした。できたこととできなかったことを分けて書きます。

はじめに：毎回発生していた往復

UIを作るとき、これまではだいたいこの流れでした。

Figmaでモックを作る → デザインをエンジニアに渡す → デザイン意図を読み取りながら実装 → 差分を目視で確認 → 修正依頼 → またFigmaへ

この往復が毎回そこそこのコストになっていました。
デザインシステムとのズレは目で確認するしかないし、実装が進んだ後の修正はFigmaにも反映しないと資料が古くなります。

で、この半年で出た3つの機能が、どれもこの往復を短くする方向のものでした。

順番に見ていきます。

1. /design：まず自分のアカウントで使えなかった

Claude Code の /design は、2026年8月に出た機能です。
ターミナルで作りたい画面を一言伝えると、Claude が複数のデザイン案を artboard として描いて、ブラウザで見られるページとして公開してくれます。そこから案を選んで「これで実装して」と言うと、コードになります。

で、実際に打ってみたらこうなりました。

Unknown command: /design

対象プランが Pro / Max / Team / Enterprise なので、使えるかどうかは契約プランに依存します。
自分の個人アカウントでは動いたので、今回は個人アカウントで確認した内容を発表しました。業務環境でそのまま使える前提では話せていません。

個人アカウントで動かした流れはこうです。

• 作りたいUIを一言で指示する（自分）
• コードベースを読んだうえで、複数案が artboard として描かれる（Claude）
• リンクを開いて案を1つ選ぶ（自分）
• 選んだ案が、既存の規約に沿った実装になる（Claude）

題材は既存の申込みフォーム案件にしました。ここでポイントにしたのは、色コードもフォント名もあえて指定しなかったことです。

> /design access-gmobbforms-web の DESIGN.md と
  access-gmobb-ui の tokens/ を読んで、
  そのデザインシステムに従った申込みフォームの画面を作って。

  参考にする既存実装:
  Forms/frontend/src/features/entry-hikari/pages/
  （Step01 アンケート → Step02 入力 → Step03 確認 → Step04 完了）

  スマホでの入力しやすさを優先して、
  項目のグルーピングと進捗の見せ方を改善したい。

ブランドカラーを直接書く代わりに、DESIGN.md と tokens/ を参照させています。人間が色コードを転記するとそこで間違えるので、定義ファイルから読ませたほうが確実だと考えました。

ただ、出てきた案が実務で通るかどうかは、まだ判断していません。
「デザインシステムから色を拾えている」ことは確認しましたが、実案件のレビューに出したわけではないので、品質面の評価はできていません。

• ※/design は research preview です。正式版ではないので仕様が変わる可能性があります
• ※Claude Code v2.1.234 以降が必要です

2. Claude Code to Figma：送れたが、そのままでは送れなかった

2つ目は Claude Code to Figma。2026年2月17日リリースで、/design とは別の機能です。
こちらは方向が逆で、すでに実装してあるコードを、編集可能なFigmaレイヤーとしてキャンバスに送るものです。

手順自体はこれだけです。

• Figma の MCP サーバーを Claude Code に追加する
• 実装した画面をブラウザで開く（localhost でも staging でも本番でもOK）
• Claude に「Send this to Figma」と打つ
• 画面全体か、特定の要素だけを選んでキャプチャする

MCP を追加したあとに反映されない場合は、Claude Code を完全に再起動します。MCP接続は起動時に初期化されるので、追加しただけでは繋がりません。

今回は、自分が触っている申込みフローのページを実際に送ってみました。
結果としてはレイヤーになったのですが、最初は一部のパーツが丸ごと落ちました。

擬似要素は落ちる

落ちたのは、矢印、吹き出しのしっぽ、STEPを繋ぐ縦線、三角のマーカーでした。
どれも ::before / ::after で作られていたものです。

擬似要素はDOMに実体がありません。キャプチャはDOMを読むので、実体がないものは持っていけません。結果、Figma側では矢印や吹き出しのしっぽが抜けた状態になります。

対策としてやったのは、キャプチャ前に擬似要素を実際のSVG要素としてDOMに書き出すことでした。三角形なら M 0 0 H 20 L 10 10 Z のようなパスを持つ <svg> を実DOMとして生成して、擬似要素の位置に置きます。

// キャプチャ専用の前処理として、擬似要素を実 SVG に置き換える
prepareFigmaDom()
//  replaceTriangleArrows     三角矢印
//  replaceBubbleTails        吹き出しのしっぽ
//  replaceStepConnectors     STEP 間の接続線
//  replaceVerticalDotLines   縦の点線
//  applyFigmaLayerNames      レイヤー名の付与

これをやったあと再度送ったら、矢印も吹き出しのしっぽも VECTOR ノードとして入り、fill も実装通りの色になりました。

ただ、これは「送るために実装側に手を入れた」ということです。
既存のページをそのままボタン1つで送れたわけではありません。装飾に擬似要素を使っているページは、送る前に変換処理を書く必要があります。

レイヤー名は aria-label から取られる

もう1つ分かったのが、レイヤー名の話です。

最初は class 名がレイヤー名になると思っていました。でも実際に送ってみると名前が付いていません。
調べたところ、読まれているのは aria-label でした。class や data 属性は見ていません。

なので、キャプチャ前にclass名を aria-label に流し込む処理を入れました。

// Figma 側はレイヤー名に aria-label を使うため、クラス名を流し込む。
// スクリーンリーダーが読み上げてしまうので、キャプチャ専用ページに限定する。
useEffect(() => startFigmaLayerNameSync(), [])

ここが一番引っかかったところで、aria-label はスクリーンリーダーが読み上げる属性です。本番のページに入れるとアクセシビリティを壊します。

つまり、この処理は本番コードには入れられません。キャプチャ専用のページを別に用意して、そこでだけ有効化する形にしました。
「実装をそのままFigmaに送る」と聞いたときに想像していたものとは、少し違います。送るための専用の入り口を作っている状態です。

逆に、流し込む先がクラス名でよかった点もあります。Figma上のレイヤー名が実装のクラス名と一致するので、レイヤーを見ればコードのどの要素か分かります。ここは後述します。

コードに戻す方向は試していない

この機能は逆方向もできることになっています。Figma側で修正した要素を右クリックして「Copy link to selection」でノードリンクをコピーし、Claude に渡すと、変更された部分だけをコードに反映してくれる、という説明です。

ただ、今回この往復は試していません。
コード → Figma の片方向だけを確認した状態です。往復が実際にどれくらい使えるかは、まだ分かりません。「往復できるのが強み」と紹介はしましたが、自分で確認した事実ではありません。

3. Figma 公式 Chrome 拡張：こちらのほうが結果が良かった

3つ目は、Figma が公式に出している Chrome 拡張です。2026年6月11日リリース。
Claude Code も MCP も不要で、ブラウザで見ているページを拡張機能のボタン1つでFigmaレイヤーとして取り込めます。

• Chrome ウェブストアからインストールして、Figma アカウントでログイン
• 取り込みたいページを開いて拡張のアイコンをクリック
• Capture page でページ全体、Select element で特定要素だけ
• スクリーンショットではなく、構造を持ったレイヤーとして貼り付けられる

同じ自社ページに対して、Capture page と Select element の両方を試しました。

結果として、Claude Code 経由よりこちらのほうが素直に入りました。
擬似要素も、先に書いた prepareFigmaDom() でDOM化してあるので問題なく入っています。レイヤー名も aria-label から取られるので、こちらも同じ前処理がそのまま効きます。

つまり、前処理をしてあるページなら、Claude Code を経由する必要はありませんでした。
MCP の設定もなく、再起動もなく、ボタンを押すだけです。Claude Code 経由と比べて手数が少ないぶん、こちらのほうが速いです。

ここは事前の想定と逆でした。「AIを経由したほうが賢く整えてくれるだろう」と思っていたのですが、実際にはDOMを素直に読む拡張のほうが結果が安定していました。
整えていたのは前処理のほうで、送る側の機能ではなかった、ということです。

レイヤー名がクラス名で入るのが良い

レイヤー名の元は aria-label に流し込んだクラス名なので、Figma上のレイヤー名が実装のクラス名と一致します。

これが想像以上に便利でした。
Figmaのレイヤーを見れば、それがコードのどの要素なのかが分かります。デザイナーから「ここを直したい」と言われたときに、レイヤー名でそのままコードを検索できます。名前で実装とデザインが繋がっている状態です。

制約はこのあたりです。

• ※現時点ではベータ版で、有料プランのみ対応です
• ※コードに戻す機能はありません（Code to Figma と違って一方通行です）
• ※他社サイトを取り込む場合は著作権の扱いに注意が必要で、リサーチや内部検討用に留めるのが安全とされています

今回わかったことの整理

まとめ

この3つは、Figmaを置き換えるものではありません。デザインと実装の受け渡しを滑らかにするためのものです。

実装した画面をそのままFigmaに持っていけるので、「実装後の状態をデザイナーに共有する」ためにモックを作り直す必要がなくなります。レイヤー名が実装のクラス名で入るので、Figma上の指摘をそのままコードに辿れます。
Figmaで作る工程が消えるわけではなく、Figmaとコードの間の段差が減る、という変化でした。

ただ、そのために前処理を書き、キャプチャ専用ページを用意する必要はありました。何もしなくても滑らかになるわけではありません。

/design は research preview、Chrome 拡張はベータ版。どちらもまだ研究段階の機能で、/design は契約プランの都合で業務環境ではそもそも動きませんでした。

そして今回一番わかったのは「送れるかどうかは、実装の書き方に左右される」ということでした。

擬似要素で作った装飾はDOMに存在しないので持っていけない。レイヤー名は aria-label から取られる。
これはツールの性能の話ではなく、実装側の構造の話です。実際、同じ前処理をしたページなら、AIを経由しない Chrome 拡張のほうが素直に入りました。結果を決めていたのは送る機能ではなく、送られる側のDOMでした。

次は、今回できていないコードへ戻す往復のほうを試す予定です。
参考になれば嬉しいです。