「AgentにMake、MCPにCode to canvas。結局、どれを使えばいいんだろう」
FigmaとClaudeの新しい連携機能を試すたびに、そう思っていませんか?
私も同じで機能を試すたびに決めかねていました。
2026年は2月から6月まで新機能の発表が続き、「figma claude 連携」と検索してはひととおりつないでみて、気づいたらAIを入れる前より制作フローが散らかっていました。
それでも今は、迷わなくなりました。
効いたのは新機能の知識より、置き場所の決め方でした。
- Agent・Make・MCP・Code to canvasって、結局何がどう違う？
- 自分の制作フローのどの工程に、何を置けばいい？
- 逆に、何を「使わなくていい」？
FigmaとClaudeをつないだら、制作フローが散らかった
期待がいちばん大きかったのは、つないだ直後でした。
MCPのローカルとリモートの違い、参照ノードの選び方、画像やSVGの扱い。
私は一気に全部を検証して、大量の時間を溶かしました。
「Figmaファイル全体を渡せば、あとは全部うまく実装してくれる」と期待していたからです。
結果はどうだったか。
AIに任せる作業は増えたのに、楽になった感じがしない。
手を動かす時間は減ったのに、デザインと実装のあいだの往復はむしろ増える。
正直、AIを入れる前のほうがフローはシンプルだった時期すらあります。
ただ、いま振り返ると、散らかった原因は機能の側にありませんでした。
なぜ散らかったのか——Agent・Make・MCPを「機能名」で覚えていたから
ここ、私もしばらく気づけませんでした。
4つとも、並べてみると「似たようなAIデザイン機能」に見えます。
でも実際は、どれかが上位版でどれかが旧版、という関係にありません。
違うのは、置く工程です。
機能名でなく、工程で選ぶ。
私のフローが片付いたのは、結局この切り替えひとつでした。
あなたの検索履歴にも、「figma claude 連携」「figma エージェント」と機能名が並んでいませんか。
機能名で覚えると、「全部つなぐか、絞るか」を機能の数だけ迷い続けます。
工程に置き直すと、関係のない機能のほうが先に消えていきます。
一気に全部つないだ「設定沼」の中身
象徴的だったのがトークン超過です。
Figmaのデザイン情報をまるごとClaude Codeへ渡そうとしたとき、「351,378トークンが上限25,000を超過」というエラーで止まりました。
私はしばらく、自分の設定が悪いのだと疑って直し続けました。
「わかります……。エラーが出ると、まず自分のセットアップミスを疑いますよね」
私も疑い続けました。でもこれ、Figma公式が既知の問題として文書化しています。対処も『選択範囲を絞る・分割して渡す』が公式の推奨。個人の設定ミスというより、全体を一度に渡す発想のほうに無理があったんです
フレーム単位・コンポーネント単位に絞ってから、挙動は一気に安定しました。
沼の正体は、「一気に全部」という渡し方だった。気づくまでが長かったです。
そしてもう一つ。私の場合は「起点」も古くなっていました。
「Claude Code→Figmaはもう古い」の正確なところ
この連携を追いかけていると、「あれはもう古いらしい」という情報だけが断片で残っていきませんか。
時系列を並べると、少し違う構造が見えます。
- 2026年2月: Code to canvas（当初の名前はClaude Code to Figma）発表。
実装済みUIをFigmaフレームに変換 - 2026年3月: Write to canvas。AIがFigmaネイティブ構造（Auto Layout等）を直接作れるように
- 2026年5月: Figma Design Agentがベータ開始
- 2026年6月: AgentとMake向けのカスタムSkillsが発表（こちらは試し始めたばかりなので、事実の紹介だけに留めます）
以前の私は、Claude Codeで見た目を先に作ってFigmaへ持ち込む流れでした（当時の検証は別記事に残しています）。
この方法、後からAuto Layoutの組み直しとVariablesの当て直しがまとめて戻ってきます。
いまは最初からFigmaネイティブ構造で作れるので、古くなったのは連携そのものというより、「Code起点を、すべてのデザインの起点に置くこと」のほうでした。
Code to canvasという機能自体は現役です。
変わったのは、置く工程だけ。
では、4つをどの工程に置くのか。
Figma×Claude連携の4工程マップ——どの工程に何を置くか
「figma claude」で検索して出てくる機能の一覧表は、たぶんもう見飽きていますよね。
ここで主役になるのは、あなたの制作フローのほうです。
Agent・Make・MCP・Code to canvasの違いを一言でいうと、置く工程の違いです。
Agentはキャンバス上で一緒に編集するアシスタント、Makeは動く試作で検証する道具、MCPはデザイン構造を実装側へ渡す橋、Code to canvasは実装済みの画面をFigmaへ戻してずれを回収する選択肢です。
| 機能 | 置く工程 | 役割 | 使わなくていい条件 |
|---|---|---|---|
| Figma Agent（Figmaエージェント） | ①発想・たたき台 / ②デザインを詰める | キャンバス上で一緒に編集するアシスタント | Starter（無料）プランの人（Full seat対象・ベータ中） |
| Figma Make | ①発想・たたき台（動く検証） | プロンプトから動く試作を作る | 静的なデザインだけで検証が足りる人 |
| Figma MCP | ③実装へ渡す | レイアウト・Variablesごと構造をClaude Codeへ渡す橋 | コーディングエージェントを使っていない人 |
| Code to canvas | ④コードから戻す | 実装とデザインのずれを回収する | 実装画面をFigmaへ戻す往復がない人 |
工程① 発想・たたき台
私はまずClaude Codeとの対話で、目的・要素・優先順位を文章に整理してから、Agentでたたき台を作ります。
動く感触まで確かめたいときだけMake。
コツは、AIより先に自分の頭を整理しておくことです。ここが曖昧だと、何案出ても選べません。
工程② デザインを詰める
Agentが効くのは、複数画面へのコンポーネント反映やタイポグラフィの一括更新のような「広く浅い変更」。余白・文字の強弱・視線の流れの最終判断は、私はいまも手でやっています。
あなたなら、どこまで任せたいでしょうか。
工程③ 実装へ渡す——いちばん往復が減った場所
Figma MCPで、選択したフレームの構造（Auto Layout・コンポーネント・Variables）をClaude Codeへ渡します。
コツはここでも、画面まるごと渡さないこと。
「このフレームを実装する」と作業単位を絞るほど安定します。
私のフローで往復がいちばん減ったのは、この工程でした。
セットアップと実装相談の具体的な手順は、Figma MCPの記事で細かく書いています。
工程④ コードから戻す
Code to canvasで、実装済みの画面をFigmaへ戻します。
ただし毎回は使いません。
実装とデザインがずれてきたときの回収の選択肢です。
残すもの・使わなくていいもの
で、結局ぜんぶ入れるべきなんでしょうか。
ぶっちゃけ、全部使う必要はありません。
この地図の実用価値は「何を入れるか」より、「何を使わなくていいかが決まる」ほうにあります。
- 完全分業でデザイン→実装を一人で往復しない人: MCPもCode to canvasも急ぎません。
担当工程で受け渡しコストが高い一点だけで十分 - Starter（無料）プランの人: Agentは対象外（ベータ中・2026年7月時点）。
ただしCode to canvasのドラフト出力はシート不問、Makeには月500クレジットの試用枠あり - コーディングエージェント未使用の人: MCPは後回しで問題ありません
AIが入っても、デザインの判断時間はむしろ増える
「AIに任せたのに、楽にならない」という違和感、ありませんか。
私の場合、正体は判断時間の増加でした。
案や変更が短時間で出てくるぶん、なぜこの画面が必要か・何をいちばん目立たせるか・どこまで直せば完成か、を決める回数が増える。
手は空くのに、頭は空きません。
これは使い方の巧拙でもなさそうです。
公式自身がWrite to canvasを「ベータ品質。出力には手動レビューと修正が必要な場合がある」と明記しています。確認と判断は構造的に残る。
だから、任せる工程を絞るほうがフロー全体は速くなります。
で、結局どの構成が正解なんですか？ 先に答えがほしいです……
正解の構成は決めません。工程は人によって違うし、どれもベータでプラン条件が動きます。代わりに、自分の工程に当てはめる手順を渡しますね
あなたの工程では、どこに一つ入れるか
Figma×Claude連携は、機能名でなく工程で選ぶ。
そうすると「使わなくていいもの」が決まるので、フローは散らかりません。
全部つなぐ巨大な自動化より、詰まっている工程に一つ入れるほうが実際は速い、が私の現在地です。
やることは3つ。
10分あれば、紙の上で終わります。
- 自分の制作フローを4つに分ける（発想・たたき台 → デザインを詰める → 実装へ渡す → コードから戻す）
- いちばん往復（やり直し・受け渡し）が多い工程を一つ選ぶ
- そこにだけ、対応する機能を一つ入れる
私の場合は、工程③のMCPでした。
あなたの詰まりが工程②なら、入口はAgentになります。
完全分業のチームや、プランの制限で入れられない機能がある場合も、「往復の多い一点に絞る」という軸は同じです。
今回のテーマはFigmaとClaudeの連携でした。
ただ、振り返っていちばん効いたのは、新機能を覚えることより、自分の制作フローのどこで往復が多いかを観測することでした。
機能の観測は公式ブログがやってくれます。
あなたにしかできないのは、自分の工程の観測のほうです。
私は毎週、自分の制作フローと数字を見ながら「次に入れる一点・外す一点」を決めて、その記録をメルマガに書いています。同じように、道具に振り回されず自分の工程から決めたい人へ。
