Figma×Anthropic「Code to Canvas」解説実行UIを編集可能なデザインへ戻す新しい往復路

1. 何が発表されたのか：Figma×Anthropicの「Code to Canvas」

2026年2月17日、FigmaはAnthropicと連携し、Claude Codeで作られたUIをFigmaのキャンバスへ取り込み、編集可能なレイヤーとして扱える「Code to Canvas（Claude Code to Figma）」を公開した。ここで重要なのは、単にコード断片を貼り付ける機能ではなく、ブラウザで実行されている画面状態を起点に、Figma上で再編集できる「構造化されたデザイン成果物」に変換する点である。Figmaの共同創業者・CEOであるDylan Fieldは同日の声明で、コードとキャンバスは二者択一ではなく、両方の力を往復できることが今後の制作に必要だという立場を明確にした。

Figma側の説明では、Claude Codeのワークフローから、プロダクション環境・ステージング環境・ローカルホストで動作する実画面を取り込み、Figma上ではフレームとして整理・複製・注釈・比較が可能になる。従来の「スクリーンショット共有」「画面録画の貼り付け」と異なり、取り込まれた要素がレイヤーとして存在するため、余白やタイポグラフィ、コンポーネント粒度の調整を、デザイン編集と同じ操作体系で行える。加えて、複数画面を連続してキャプチャし、フローとしての順序や文脈を保持したままキャンバスに展開できることが強調されている。

この発表は、生成AIが「設計→実装」の直線工程を崩し、試作がコード側から始まる局面が増えたことへの回答でもある。Claude Codeのようなエージェント型コーディング環境では、自然言語の指示で動くUIが早期に立ち上がる一方、その試作物は端末やブラウザの中に閉じがちで、チームが合流して比較検討する段階に移すには、手作業の再構成が必要だった。Code to Canvasは、この移送の摩擦を下げ、試作の“動く現物”をキャンバスへ持ち込み、合意形成と磨き込みの場に載せ直すことを狙っている。

2. 「コードのインポート」ではなく「実行UIのキャプチャ」：仕組みを分解する

Code to Canvasの核心は、コードを静的に解析して設計図へ落とすよりも、実行されたUIの状態をブラウザから取得し、Figmaのレイヤー構造へ写像する点にある。Dylan Fieldの説明でも「ブラウザのレンダリング状態が、編集可能なFigmaレイヤーへ自動変換される」と表現されており、入口はソースコードというより表示結果である。

実装上はFigmaのModel Context Protocol（MCP）サーバーを介し、Claude CodeからFigma側のツールを呼び出す形で提供される。開発者向け資料では、Claude Code専用かつリモートMCPサーバー専用のツールとしてgenerate_figma_designが定義されている。つまり、同じMCPクライアントでも、現時点で「コード→キャンバス」の生成ができるのはClaude Codeに限られ、他のIDE統合は主に「デザイン→コード」側の文脈取得や変数・コンポーネント参照が中心になる。

手順の骨格は次の通りである。まずClaude CodeにFigmaのリモートMCPサーバーを登録し、OAuthでFigmaアカウントを認証する。次に「ローカルサーバーを起動してUIをキャプチャし、新規のFigmaデザインファイルへ送る」「既存ファイルURLへ送る」「クリップボードへ送る」といった指示をClaudeに与える。Claudeは必要に応じて開発サーバーを立ち上げ、キャプチャ用のスクリプトを注入し、ブラウザを開く。ブラウザが開いた段階で初回キャプチャが行われ、以後は専用ツールバーから画面全体、または特定要素の選択キャプチャを繰り返せる。キャプチャ先がファイルの場合は「Open file」で結果に遷移し、クリップボードの場合は任意のFigmaファイルへ貼り付けて運用する。

この設計は、「Claudeが生成したコード」を直接Figmaに渡すというより、「Claudeが起動した（あるいは既存の）Web UIを、ブラウザのDOMと描画情報からFigma表現へ変換する」ことに近い。実運用では、Claude Codeが生成したUIだけでなく、既存のプロダクションサイトやステージング環境の画面も対象になり得る。開発者向け資料は、ライブなWebアプリやサイトから取り込む場合、Playwrightなどの自動化ツールでキャプチャ用スクリプトを注入する運用も想定している。単なる“出力物の保存”ではなく、実行環境と結びついたキャプチャ体験として設計されている点が、従来のプラグイン的変換と異なる。

3. MCPが支える「往復可能性」：Code to CanvasはMCP戦略の延長線上にある

Code to Canvasを理解するには、Figmaが2025年から進めてきたMCPサーバー戦略を踏まえる必要がある。Figmaは2025年6月、MCPサーバーのベータ公開を通じて、Copilot（VS Code）やCursor、Windsurf、Claude Codeといったエージェント型開発環境に、Figmaの設計情報を直接供給する枠組みを提示した。画像を貼って推測させるのではなく、コンポーネント名、変数、スタイル、レイアウトといった「設計意図に近いデータ」を必要な粒度で渡すことが狙いだった。ここで強調されたのは、正しいコードはピクセル一致ではなく設計意図との整合であり、スクリーンショットは補助情報として扱うべきだという立場である。

2026年2月時点のヘルプ資料では、MCPサーバーはリモート型とデスクトップ型の2経路で提供される。リモート型はホストされたエンドポイントへ接続する方式で、デスクトップアプリの常駐を不要にする。一方デスクトップ型はFigmaデスクトップアプリ内でDev Modeを用いて起動し、ローカルアドレスへ接続する。利用条件も分岐しており、リモート型は全プラン・全シートで利用可能とされるが、日次・月次のツール呼び出し上限が設定される。開発者向け資料では、Enterpriseで1日600回、OrganizationまたはProのFull/Devシートで1日200回、StarterプランやView/Collabシートでは月6回という上限が明示されている。生成AIの導入は「無制限の自動化」ではなく、権限とリソース管理を伴うサービスとして設計されていることが数字からも読み取れる。

Code to Canvasは、このMCPの「外部ツールとFigmaを往復させる」発想を、設計→実装だけでなく、実装→設計にも拡張したものと言える。Figma側の記事でも、キャンバスで合意形成した結果を、MCP経由で再びコーディング環境へ戻す“Roundtrip back to code”が明示されている。重要なのは、往復が「同一形式の完全変換」を意味しない点である。コードは実行系、キャンバスは比較検討と編集の場であり、双方が得意な局面を切り替えるための搬送路としてMCPが使われる。

4. 既存の「HTML→Figma」系と何が違うのか：技術の連続性と統合の意味

Code to Canvasは突然現れた発想ではない。Figma自身が2025年9月、「Figma Make」の生成結果をキャンバスへコピーして編集可能にする“Copy design”を導入し、さらにコミュニティで普及していた<div>RIOTSのプラグインhtml.to.design（ライブHTMLを編集可能なフレームへ変換）について、技術の取得を公表している。同社の記事では、html.to.designが約200万人に利用され、開発に3年を要したことも触れられた。ここから見えるのは、Figmaが「生成結果や実行結果を、キャンバス編集可能な構造へ戻す」領域に継続投資してきたという流れである。

差分は大きく2つある。第一に、入口が「HTMLページの変換」から「Claude Codeのワークフローに埋め込まれたキャプチャ」へ移り、生成AIの試作プロセスと直結した点である。Claude Codeは単なるコード補完ではなく、ファイル読込やコマンド実行を伴うエージェント型環境として設計されており、ローカルサーバー起動やブラウザ操作も含めて一連のタスクとして扱える。Code to Canvasは、AIが“作ったもの”を、AI自身が“運んで整形する”工程まで含めて自動化し、共同編集空間へ引き渡す。

第二に、変換が「単発の輸出入」から、MCPという標準インターフェースに乗った「組み合わせ可能なツール群」へ位置づけ直された点である。MCPでは、UIの生成（generate_figma_design）に加えて、選択フレームからのコード生成、変数定義取得、Code Connectによるコンポーネント対応表の参照といった複数のツールが提供され、エージェント側が必要に応じて呼び分ける。これにより、組織がデザインシステムへ投資しているほど、AI生成コードが既存パターンへ寄る確率が高まる。つまり「AIで速く作る」だけでなく、「既存の規律に沿って速く作る」方向へ進む。

5. 仕事の流れはどう変わるか：意思決定の“場”が移る

Code to Canvasが狙うのは、デザインと実装の分業を単に近づけることではなく、意思決定の場を“画面の外”へ引き戻すことである。コードは一度に一状態へ収束しやすい。対してキャンバスは、複数案を並べ、関係を俯瞰し、議論の痕跡を残しやすい。Figmaはこの違いを「コードはconverging、キャンバスはdiverging」と表現し、行き来の価値を整理している。

この点は認知科学の観点でも説明できる。1956年に発表されたGeorge A. Miller（ハーバード大学）の研究によると、短期記憶の容量は7±2程度の「チャンク」として説明される。2001年に発表されたNelson Cowan（ミズーリ大学）の研究では、注意下で同時に保持できる単位は4±1程度に収束するという見解が整理された。複数画面の分岐や状態遷移を、1人の頭の中だけで保持しながら議論するのは構造的に難しい。1995年のEdwin Hutchins（カリフォルニア大学サンディエゴ校）が提示した分散認知の枠組みでは、認知は個人の脳内に閉じず、外部表象や共同作業の配置に分散する。キャンバス上でフローを並べ、注釈を置き、比較する行為は、まさに外部表象へ認知負荷を逃がす設計である。

複数の調査では、知的作業の中断と再開に相当のコストがあることも示されている。たとえばGloria Markらの職場研究を整理した2015年のCSCW論文では、作業が中断された後、元のタスクに戻るまで平均23分前後を要するという先行研究が引用されている。別の研究では、職場の中断の64%が受け手にとって有益だと報告される一方、40%では中断後に元の作業へ戻らないともされ、中断は単純な「集中の妨げ」だけでは説明できない。端末上の試作物を、会議資料やデザイン案として共有するためにスクリーンショットへ変換する行為は、それ自体が追加の中断になり得る。Code to Canvasが搬送を一手に引き受けることで、移送のための細かな手作業を減らし、議論の時間を増やす設計意図が読み取れる。

また、1987年にJill LarkinとHerbert A. Simon（カーネギーメロン大学）が論じた「図は時に一万語に匹敵する」という主張は、表象形式が推論コストを左右する点を示した。コードの差分は行単位で比較するが、UIの差分は空間配置で比較したほうが早い局面がある。Code to Canvasが提供するのは、こうした表象の切替を、スクリーンショットや口頭説明ではなく、編集可能な成果物として行うルートである。

さらに、1988年にJohn Sweller（ニューサウスウェールズ大学）が提唱した認知負荷理論の研究によると、初期試作で速度を上げても、探索不足のまま進むと“誤った方向への勢い”が生じる。Figmaが「スピードは重要だが、探索のないスピードは危険」と述べたのは、まさにこの罠を指している。コードで素早く作り、キャンバスで探索し、再びコードへ戻すという往復は、速度と探索を分離するための工程設計として読むことができる。

6. 技術的な争点：何が“編集可能”として残り、何が落ちるのか

「編集可能なデザイン」と言っても、すべてが完全に保存されるわけではない。一般にWeb UIはHTML/CSSだけでなく、CanvasやWebGL、動画、外部ウィジェット、シャドウDOM、ランタイムで生成される要素など多様な技術要素で構成される。キャプチャがブラウザのレンダリング状態を起点とする以上、Figma側へ写像できるのは、主にテキスト、矩形、画像、ベクター、レイアウト制約に落とし込める部分になる。ここで課題になるのが、CSSのレイアウトモデルとFigmaのAuto Layoutや制約の対応関係である。FlexboxやGridの振る舞い、レスポンシブのブレークポイント、疑似要素やフィルタ、フォントレンダリング差などは、デザインツール側の表現に写す際に近似が発生しやすい。

一方で、実務上の価値は「完全再現」より「編集可能な議論素材」の生成にある。Figma側の説明でも、取り込んだ画面を並べて比較し、注釈を付け、構造変更を試すことが強調され、ピクセル単位の一致を目標としていない。これは、MCPサーバーの思想とも整合する。MCPは、変数名やコンポーネント参照といった“意図”の手がかりを渡し、生成側が既存の設計規範に寄せることを重視する。Code to Canvasで持ち込まれたフレームが、後段の「デザイン→コード」生成に接続されるなら、キャンバス上の編集も再度コードへ反映しやすい。完全一致でなくても、意思決定に必要な要素がレイヤーとして残っていれば十分な局面が多い。

この点で重要になるのが設計資産の整備である。Code Connectのように、Figmaコンポーネントとコード側コンポーネントを対応付ける仕組みは、生成コードの再利用率を高め、差分を小さくする。逆に、デザイン側がコンポーネント化されていない、変数が統一されていない、命名規則が曖昧である、といった状態では、往復のたびに表現が揺れやすい。Code to Canvasは単体で魔法をかける機能というより、デザインシステム運用の成熟度を前提に、AIが往復工程を担えるようにする土台として理解したほうが現実的である。

7. セキュリティと統制：MCPは便利だが“接続”は攻撃面を増やす

生成AIと業務ツールを接続する際、最大の論点の一つが権限とデータ流出である。MCPは標準化された接続方式であり、Claude Codeの公式ドキュメントでも、外部MCPサーバーの導入は信頼できるものに限定し、特に不正なコンテンツを取得するサーバーはプロンプトインジェクションのリスクを高めると注意喚起している。FigmaのMCPサーバーもOAuthで認証し、既存の閲覧・編集権限の範囲内でしかリソースへアクセスできない設計だが、連携が進むほど「どのAIが、どの権限で、どのファイルに触れたか」を監査する必要性が増す。

また、Code to Canvasは“実行UI”をキャプチャするため、画面に表示された個人情報や機密情報がそのままデザイン成果物として残り得る。プロダクション環境を対象にする場合、テスト用のダミーデータに切り替える、権限制御されたステージングで行う、キャプチャ範囲を要素単位に絞る、といった運用設計が必要になる。これは従来のスクリーンショット共有でも同じ課題があったが、編集可能なレイヤーとして残るぶん、コピーや再利用が容易になり、漏洩時の拡散速度は上がり得る。技術機能の導入と同時に、取り込み対象・保管場所・共有範囲・削除ポリシーを組織として定義することが不可欠になる。

加えて、Claude Code側のMCP設定はプロジェクト単位やユーザー単位で管理され、環境変数や出力制限（例えばMCPツール出力が1万トークンを超えると警告が出る、上限を環境変数で調整できる、といった仕組み）も存在する。生成AIが“何をどこまで”持ち出したかを把握するには、エージェントのログ、ツール呼び出し履歴、Figma側のアクセスログを突合する運用が求められる。Code to Canvasはデザインと実装の距離を縮める一方で、セキュリティ境界を横断する経路を増やす機能でもある。

8. 意味合い：デザインツールは「描く場」から「往復の交通整理」へ

歴史的に、インターフェース制作は何度も表象形式の転換を経験してきた。1968年のDouglas Engelbartのデモは、マウス操作やハイパーテキストだけでなく、共同編集という概念を可視化した。1970年代のAlan KayやSmalltalk系の思想は、実行可能な表象を使って学び、作り、再利用する流れを強めた。1980〜90年代のWYSIWYGやGUIビルダーは、コードを隠蔽して制作の裾野を広げたが、同時に“実装の真実”が別の層に移る問題も生んだ。2000年代以降のWebでは、デザインと実装の分離が進み、デザインシステムがその橋渡しとして発達した。

2020年代の生成AIは、この分離を別の形で揺らしている。自然言語から動く試作が立ち上がり、実装が「最初から存在する」状態が増えると、デザインツールの価値は静的モックを描くことだけでは説明しづらい。Figmaが提示する「コードとキャンバスの往復」は、デザインツールを、表象の切替と合意形成のインフラへ再定義する試みと言える。実装はコードで収束させ、探索と意思決定はキャンバスで広げる。その交通整理を担うのが、MCPを軸にした接続機構であり、Code to Canvasはその象徴的な機能である。

ぽちょ研究所の観点では、このニュースは「生成AIが生産性を上げる」一般論ではなく、制作工程の“どこで何を決めるか”という意思決定設計の再配置として読むのが有益である。コード生成が高速化したとき、差別化要因は再びデザインの判断へ戻る。その判断を支える材料を、実行系からキャンバスへ引き戻し、編集可能な形で共有する。Code to Canvasは、AI時代のUI制作における「議論できる現物」を増やすための、新しい搬送路として位置づけられる。

9. これから観測すべきポイント：機能の広がり方と品質指標

Code to Canvasは、ヘルプ資料で「継続的に改善中」と明記されており、現段階では“完成された自動変換”というより、実運用でのフィードバックを前提にした能力拡張フェーズにある。今後の評価軸としては、少なくとも三つの観測点がある。

第一に、対象クライアントの拡大である。開発者向け資料ではgenerate_figma_designが「Claude Codeのみ」とされているが、MCP自体は標準インターフェースであり、理論上は他のMCPクライアントにも同等のツールが提供できる。仮に対象が広がれば、特定ベンダーのIDEやエージェントに依存しない“コード→キャンバス”が実現し、企業内の標準ツール選定にも影響し得る。

第二に、変換品質の定量化である。たとえば、Figma側のAuto Layoutへ落ちる比率、テキストスタイル・カラー変数の保持率、レイヤー命名の一貫性、コンポーネント化の推定精度といった指標は、単なる見た目ではなく「後から編集できるか」を左右する。設計意図を扱う以上、ピクセル誤差よりも、構造誤差（本来同じコンポーネントが別物として生成される、変数がハードコード化されるなど）が重要になる。

第三に、往復後の“差分処理”である。キャンバス側での修正がコードに戻るとき、全面生成で置き換えるのか、既存コードへパッチとして当てるのかで、実務の採用可否が変わる。FigmaはMCPを通じてデザインコンテキストやCode Connectの対応表を提供するが、実際のマージ戦略はエージェントの能力とプロジェクトの規律に依存する。Gitの履歴と同様に、差分の透明性とレビュー可能性が担保されなければ、速度は出ても品質保証が難しくなる。

この三点は、単に機能が増えるかどうかではなく、組織が安心して工程に組み込めるかを左右する。導入初期は、限定した画面・限定したデータ・限定した共有範囲で試し、変換品質と権限設計の両方を検証するのが現実的になる。