AI コーディングエージェント（Cursor、Claude Code、Windsurf、Codex）を使ってデザインから UI を作っているなら、誰もがぶつかる壁に心当たりがあるはずです。チャットにスクリーンショットを貼るやり方は、単純なコンポーネントには通じても、実際の UI ではすぐに破綻します。エージェントは推測し、その推測は外れ、修正し、トークンが消え、結局は手作業で作り直すことになります。
より良いパイプラインがあります。まず Codia AI でスクリーンショットを構造化された Figma ファイルに変換する。次に、その Figma ファイルをエージェントに接続した MCP サーバーで読む。こうすると、エージェントが扱うのはフラットな画像ではなく、構造化されたレイアウト情報、Variables、コンポーネント、デザイントークンです。出力の質は上がり、反復回数は減り、作業は道具との格闘ではなくなります。
Codia Screenshot to Figma を使うと、スクリーンショットや UI 画像を編集可能な Figma レイヤーに変換し、再設計、比較、引き継ぎに進めます。
Figma MCP サーバーとは？
Figma MCP サーバーは、Figma ファイルと、Model Context Protocol に対応した AI エージェントをつなぐ公式ブリッジです。Figma ファイル、コンポーネント、Variables、デザイントークンを、エージェントが直接読める構造化データとして公開し、画像から逆解析させる必要をなくします。
再構築のステップでは、Codia Screenshot to Figma で参照画像を編集可能なレイヤーに変換してからデザインを調整できます。
現在 MCP に対応しているエディタ: VS Code、Cursor、Windsurf、Claude Code、Codex。
MCP が解決する問題
スクリーンショットを Cursor や Claude Code に貼って「これを作って」と言うと、エージェントはこう動きます。
- 画像をビジョンで見る
- レイアウト構造を推測する
- 余白を推測する
- 色を推測する
- コンポーネントを推測する
- その推測に基づいてコードを書く
この「推測」が、トークンコストが積み上がり、品質が落ちるポイントです。実際のデザインファイルには、その情報がピクセルではなくデータとして入っています。MCP はそのデータを公開します。
このワークフローで Codia が解決する問題
MCP を役立てるには、Figma ファイルが必要です。もし手元にあるのが、作りたい参照 UI のスクリーンショットだけなら、MCP だけでは足りません。結局、画像を貼るところに戻ってしまいます。
Codia はそのギャップを埋めます。スクリーンショット → Codia → 構造化された Figma ファイル（Variables、Auto Layout、名前付きコンポーネント付き）→ MCP 対応、という流れです。
3 ステップのパイプライン
ステップ 1: Codia でスクリーンショットを変換する
参照用スクリーンショット、競合ページ、インスピレーション画像、既存の本番画面を Codia AI に取り込んで Figma へ変換します。
- Codia の Figma プラグインまたは Web アプリにアップロードする
- 変換を実行する（きれいなフルスクリーンなら約 10 秒）
- 結果を Figma で開く
出力は本物のフレーム、本物のテキストレイヤー、対応する箇所には Auto Layout、繰り返し要素のコンポーネントです。重要なのは、MCP が読むのに必要な 構造 があることです。
変換そのものの詳細は、Screenshot to Figma: 完全ガイド を参照してください。
ステップ 2: MCP 向けに Figma ファイルを整える
MCP は、きれいな Figma ファイルほど効果が大きいです。5 分で次を確認してください。
- Variables を色に適用する。 生の HEX 値はエージェントに文字列しか渡しません。Variables はトークンを渡します。すると、エージェントの出力が独自のデザインシステムではなく、あなたのデザインシステムに従います。
- レスポンシブにしたいコンテナに Auto Layout があるか確認する。 MCP はこれを通じて、そのレイアウトがどう振る舞うべきかをエージェントに伝えます。
- コンポーネント名を意味のあるものにする。
Group 47ではなくPrimaryButton、NavItem、PricingCardのようにする。生成コードにその名前が使われます。 - 繰り返し要素はアドホックなインスタンスではなくコンポーネントにまとめる。 MCP はコンポーネントを第一級の概念として公開します。
Codia で変換したファイルなら、この作業の大半はすでに済んでいます。変換時点で Auto Layout、要素名、繰り返しパターンのグループ化が作られるからです。5 分の整備は仕上げに近いものです。
ステップ 3: エディタに MCP を接続して生成する
使うエディタで Figma MCP サーバーをインストールして設定します。公式セットアップガイド: Figma MCP server guide。
そのうえで、プロンプトでは Figma ファイルや選択範囲を参照します。
"Use the Figma file [link or selection ID] to build a React component matching this design exactly. Use the design system Variables. Match the spacing tokens."
これでエージェントは次を受け取れます。
- 実際のレイヤー階層
- Auto Layout から得られる実際の余白値
- Variables から得られる実際のカラートークン
- 実際のコンポーネント定義
- 必要に応じた選択部分のスクリーンショット（視覚確認用）
出力は、スクリーンショットを貼るだけのやり方より、はるかにデザインに近づきます。
このパイプラインが「スクリーンショットを貼る」より優れている理由
| アプローチ | エージェントが得るもの | 出力品質 | トークンコスト |
|---|---|---|---|
| スクリーンショットをチャットに貼る | ピクセル + あなたのプロンプト | 低〜中、推測が多い | 高い。修正が多い |
| Codia → MCP → エージェント | 構造化レイアウト + Variables + コンポーネント + スクリーンショット | 中〜高、推測が少ない | 低い。修正が少ない |
| Codia → MCP → エージェント + きれいな Figma ファイル | 上記に加えてデザインシステム情報 | 高い | 最低 |
実務での効果として、このフルパイプラインを使うチームは、スクリーンショットだけのプロンプトに比べて UI 生成タスクの「ここを直して」が約 50〜70% 減ると報告しています。トークン消費もそれに応じて下がります。
Cursor での手順
Cursor を使った具体例です。
- Figma で、Codia が生成したファイルを開き、作りたいフレームを選択する。
- Cursor で、Figma MCP サーバーをインストールする（Settings → MCP → Add Server）。
- Cursor のチャットで、こう書く: "Using the Figma MCP server, fetch the selected frame from my Figma file and generate a React + Tailwind component matching the design exactly. Use Variables as Tailwind theme tokens."
- エージェントが MCP ツールを呼び出し、構造化データと選択部分のスクリーンショットを取得する。
- コンポーネントを生成する。 1 回目の出力は、スクリーンショットを直接渡したときよりずっとデザインに近い。
- 同じ Figma ソースを参照しながら、具体的な修正を依頼して反復する。
Claude Code と組み合わせる場合
流れは同じで、ツールが少し違うだけです。Claude Code は MCP をネイティブにサポートしています。Figma MCP サーバーのインストール方法も同じです。プロンプトのスタイルも同じです。
すでに Claude Code をバックエンド作業で使っているなら、Figma MCP サーバーを追加することで、同じエージェントが Codia 変換済み Figma ファイルから UI を作れます。
Windsurf と組み合わせる場合
こちらも同様です。Windsurf の MCP サポートにより、Figma MCP サーバーは Cursor や Claude Code と同じように接続できます。
よくある落とし穴
Variables を飛ばすこと。 Figma ファイルが生の HEX 値だらけだと、MCP はそのままの文字列をエージェントに返します。デザインシステムの Variables を適用してください。それが「ブランドカラーに近い色」ではなく「正しいブランドカラー」の違いです。
Auto Layout を忘れること。 Auto Layout がなければ、MCP は位置は説明できてもレスポンシブ意図までは伝えられません。Auto Layout にすると「これは 16px gap の flex row です」といった、エージェントにとって使える情報になります。
1 回のプロンプトでやりすぎること。 「ダッシュボード全体を作って」は大きすぎます。「Figma の選択範囲に一致するサイドバーコンポーネントを作って」の方がはるかにうまくいきます。コンポーネント単位で構成し、あとで組み立ててください。
Figma で選択を曖昧にすること。 MCP は選択したものを取得します。曖昧な選択は曖昧な文脈につながります。欲しいフレームを正確に選んでください。
スクリーンショットのプロンプトと MCP を混ぜること。 MCP をセットアップしたなら、それを使ってください。MCP の参照に加えてスクリーンショットも貼ると、エージェントは 2 つの正解候補を受け取り、都合のいい方を選んでしまいます。
1 回限りの画面を超えて: コンポーネントライブラリを作る
このパイプラインはスケールします。
- Codia で代表的なスクリーンショットをまとめて変換する
- Figma 内で結果をコンポーネント化する
- Variables とデザインシステムを適用する
- MCP を使って、対応するコードのコンポーネントライブラリを生成する
バッチ変換には、Visual Struct API を使います。1 バッチあたり最大 1,000 画像まで対応します。
このパイプラインを使わない方がいい場合
- 単純なボタンやアイコン。 ときには、スクリーンショットをそのままエージェントに渡す方が速い。
- すでに Figma にネイティブであるデザイン。 Codia を飛ばして、そのまま MCP へ進む。
- デザイン忠実度を必要としないコード生成。 「だいたい合っていればいい」なら、スクリーンショット経由で十分な場合がある。
FAQ
Figma MCP サーバーは有料ですか？
公式 Figma MCP サーバーは Figma プラットフォームの一部です。利用可否は Figma のプランを確認してください。
エージェントは実際の Figma ファイルを見るのですか、それとも API だけですか？
MCP サーバーは、Figma ファイルから構造化データ（レイヤー、名前、位置、Variables、コンポーネント）をエージェントに渡し、選択部分のスクリーンショットを返すこともできます。
Codia 由来ではない自分の Figma ファイルでも使えますか？
はい。MCP は、構造が整った Figma ファイルなら何でも使えます。Codia は、スクリーンショットしかなく、既存の Figma ソースがない場合の橋渡しです。
変換した Figma ファイルが散らかっていたら？
5 分だけ整えてください。コンポーネント名を付け、Variables を適用し、Auto Layout を確認する。エージェントの出力品質はファイル品質に比例します。
Cursor の Auto / Claude / GPT モデルでも動きますか？
はい。MCP はモデル非依存です。サーバーは、エディタが使っているどのモデルにも構造化データを渡します。
Figma Make と比べるとどうですか？
Figma Make は Figma 内でプロンプトから UI を生成します。Codia + MCP のパイプラインは、Figma ファイルをデザインソース オブ トゥルースとして使いながら、Figma の外で コード を生成します。ツールも出力も違います。