変換したファイルを code 生成に使えますか？

はい。まず Figma の構造を整えてください。適切にコンポーネント化され、命名され、Auto Layout が整った Figma ファイルのほうが、design-to-code の出力はずっと良くなります。AI エージェントのワークフローなら、Cursor や Claude Code で Figma MCP サーバーと組み合わせてください。

← すべての記事に戻る

Screenshot to Figma: 編集可能なUIデザインを作る2026年完全ガイド

チュートリアル2026-04-25

Screenshot-to-Figma とは何か

Screenshot-to-Figma（別名 image to Figma）は、フラットな PNG、JPG、WebP を編集可能な Figma レイヤーに変換するAI機能です。編集できるテキストレイヤー、図形、写真やアイコンの個別の画像レイヤー、グループ化されたレイヤー階層が得られ、検出された一部の行やスタックには Auto Layout も付きます。つまり、単にスクリーンショットをFrameの中に貼るのではなく、実際に編集できる構造化されたFigmaファイルを作ることが目的です。

Codia Screenshot to Figma を使うと、スクリーンショットや UI 画像を編集可能な Figma レイヤーに変換し、再設計、比較、引き継ぎに進めます。

Codia AI はこの変換を行い、ほとんどの画面は数分で編集できる状態になります。出力は Figma フレームで、編集可能なテキストレイヤー（フォント、サイズ、色を画像から検出）、図形、独立した画像レイヤーとしての写真やアイコン、入れ子になったレイヤー階層で構成されます。そのため、デザイナーは手作業でトレースする代わりに、タイポグラフィ、余白、色、構造を確認できます。なお、Codia がコンポーネント、Variables、デザイントークンを自動で作るわけではありません。繰り返し要素のコンポーネント化は、変換後に数分で済む仕上げ作業です。

このガイドでは、用途別のコツ、4ツール比較、無料版とPro版の違い、最もよくある品質上の不満とその回避策、完全なレビュー用チェックリスト、そして screenshot-to-Figma を Cursor + Figma MCP のワークフローに組み込む方法まで扱います。

何を変換できるか

同じワークフローは、さまざまな画面に適用できます。

再構築のステップでは、Codia Screenshot to Figma で参照画像を編集可能なレイヤーに変換してからデザインを調整できます。

モバイルアプリ画面 - iOS と Android、ライトモード / ダークモード
iPhone のスクリーンショット - 実機やシミュレータから取得した画像
SaaS ダッシュボード - サイドバー、グラフ、テーブルを含む情報密度の高いページ
ランディングページ - ヒーロー、特徴、料金、口コミを含むマーケティングセクション
Eコマースの商品ページ - PDP、カート、チェックアウト
ワイヤーフレームとスケッチ - ラフな白黒のワイヤーフレーム画像
レガシーUI - 元のデザインファイルがない画面
クライアントから共有された参考画像 - PNG、JPG、WebP

最適なのは、切り抜かれておらず、鮮明で、フル解像度かつテキストが読みやすい画像です。対応形式は PNG、JPG、WebP です。圧縮されたサムネイル、ノートPC画面の写真、動画やアニメーションから切り出したフレームは、タイポグラフィやアイコンの復元を難しくします。

ステップごとのワークフロー

きれいな PNG、JPG、WebP 画像を取得またはアップロード する。Figma プラグインからでも、ブラウザの Codia Studio からでも構いません。
対象UIだけが残るようにトリミング する。ブラウザのUI、チャットウィジェット、OSバー、オーバーレイは取り除く。
変換を実行 する。AIがレイアウト、テキスト、色、アイコン、レイヤー階層を解析する。
結果を Figma で開く。 プラグインならフレームがそのままキャンバスに配置されます。Codia Studio で変換した場合は Copy to Figma を使い、Figma ファイルに貼り付けます。
レイヤーツリー、テキスト、色、アイコン、余白をレビュー する（下のチェックリスト参照）。
重要なフレームはリネームし、必要ならコンポーネント化 してから引き渡す。

ほとんどの画面は数分で編集できる状態になります。デザイナーの時間は、再構築ではなく判断に移ります。階層の整理、レイアウトの調整、プロダクトに合わせた仕上げが主な作業になります。

無料版とPro版: どちらが必要か

多くの screenshot-to-Figma ツール（Codia も含む）は、無料版と有料版を提供しています。率直に言うと次のような違いです。

必要なこと	無料版で十分	Pro版が有効
月1〜3画面を個人学習や軽い用途で変換	✅
画質や精度が自分の業務に合うか試したい	✅
毎日のデザイン業務、月10画面以上		✅
高解像度 / モバイルRetina ソース		✅
一括処理 / API での移行		✅ 一括アップロード（Pro は一度に最大 20 枚）、大規模な作業には Visual Struct API
優先キュー / 高速処理		✅

Codia の無料プランでは、毎月 5 AI クレジットが付与され、1440×1440 px・5 MB までの画像を変換できます。クレジットカードは不要で、学習してたまに使うには十分です。毎週スクリーンを変換するチームや移行プロジェクトを走らせる場合は、Pro版を前提に考えるべきです。

「ボタンが平坦な画像になる」問題と対策

AI の screenshot-to-Figma で最もよくある不満は、見た目は合っているのに、ボタンが編集可能なレイヤーではなく平坦な画像になってしまう ことです。主な原因は3つあります。

1. 元画像がスクリーンショットのスクリーンショットだった。 再エンコードされた JPG は、AI がインタラクティブ要素を検出するためのシャープなエッジを失います。新しく取得した、劣化のない PNG を使ってください。

2. ボタンのスタイルが複雑で、AI が分解できなかった。 強いグラデーション、特殊なシャドウ、標準外のサイズは、ボタンを認識閾値の下に落とします。対策としては、ボタンだけを小さめの余白付きで切り出して変換し、編集可能になった結果をメインファイルに貼り戻してから、自分でコンポーネント化します。

3. ボタンがテキストや画像と重なっていた。 重なりは分離が最も難しいです。CTA がきれいな背景の上に来る状態までスクロールして、重なりのないスクリーンショットを取り直してください。

それでもアイコンやボタンが平坦な画像のまま残る場合は、その部分を切り出して Codia の Image to SVG に通すと、編集可能なベクター図形になります。常に100%ではありませんが、ボタンやアイコンなら十分なことが多いです。

用途別のコツ

モバイルアプリ画面（iOS / Android ネイティブ）

ステータスバーやホームインジケーターが必要ないなら、含めずにアップロードする。
iOS と Android では既定のフォントスタックが異なるため、フォント置換はある程度想定し、レビュー時に近いブランドフォントへ寄せる。
タブバー、セグメントコントロール、ボトムシートは、たいていグループとして変換される。再利用のために自分でコンポーネント化するとよい。
ダークモード参照では、レビュー前にフレームの塗りを暗いサーフェス色にしてコントラストを確認する。

iPhone のスクリーンショットを Figma にする場合

iPhone のスクリーンショットは特に人気のある入力です。すぐ使えるポイントは次のとおりです。

実機（サイドボタン + 音量上）またはシミュレータから取得する。どちらも適切なピクセル密度のきれいな PNG を出せます。
角丸マスクが不要なら切り落とす。Figma 側のフレームがすっきりします。
SwiftUI ベースのデザインなら、後で Figma to Code を使うときに SwiftUI の View と整合しやすいよう、変換結果から作るコンポーネントの名前を PascalCase にする。

SaaS ダッシュボード

サイドバーとヘッダーは複数ページで繰り返されるので、まず1画面を変換し、次にそのクローム部分をコンポーネント化する。
行数の多いテーブルは、密集した表全体を渡すより、代表行を1つはっきり見せたほうがうまく変換される。
グラフはスタイル付きの図形やグループとして再構築される。編集可能なチャート仕様が必要なら、後でデザインシステムのコンポーネントで作り直す前提で考える。
情報密度の高いグリッドは、列の整列を丁寧に確認する。

ランディングページ

長いページでは、ヒーロー、特徴、料金、FAQ、フッターなどをセクションごとに分けて変換する。セクション単位のほうがレイヤー構造がきれいになります。
料金表は、比較表だけを中央に寄せて狭く切り出すと精度が上がる。
ヒーローイラストや抽象的なグラデーション背景はラスター画像のまま入ることがある。チームが後から調整したいなら、編集可能なベクターやデザインシステム資産に置き換える。

Eコマースの商品ページ

商品写真はそれぞれ独立した画像レイヤーとして入る。変換後に高解像度の元画像へ差し替える。
バリアント選択、サイズ選択、数量ステッパーは、すぐにコンポーネント化する候補として適している。
信頼バッジ、決済手段の帯、レビュー抜粋は OCR 精度の確認が必要。小さい文字やブランド固有の記号に注意する。

ワイヤーフレームとスケッチ

ワイヤーフレームは、編集可能なテキストを持つ黒白のきれいなFigmaフレームになる。見た目のデザイン前にUI反復を素早く回すのに便利です。
平らな場所で撮影された手描きスケッチ（十分な照明、影が少ないもの）も変換できる。デジタルワイヤーフレームよりは多めの調整が必要です。

レガシーUI移行

すべての画面を変換しない。まず代表的な画面を選ぶ。たとえばダッシュボード、設定、空状態、オンボーディング、チェックアウト、主要導線などです。
そこからタイポグラフィスケール、ブランドカラー、コンポーネントライブラリを作り、残りを一括変換する。
レガシーライブラリに数百画面あるなら、バッチ処理には Visual Struct API を使う。

ツール比較: Codia vs Image.to.design vs Banani vs Refore

スクリーンショットを Figma に変換するときに多くの人が検討する4ツールを、実用面で比較するとこうなります。

	Codia AI	image.to.design	Banani	Refore
強み	UIを理解した変換、HTML/CSS/PSD/PDF/screenshot 対応、バッチAPI	Auto Layout 出力が強い、幅広い形式に対応	Auto Layout 優先の出力、洗練されたUX	ピクセル忠実度重視のベクタライゼーション
向いている用途	UIスクリーンショット、バッチ移行、下流のコード連携	Figma 内だけで完結したいデザイナー	軽量な日常変換	ベクターの忠実性を最優先する作業
API / バッチ	✅ Visual Struct API のバッチエンドポイント + webhook	限定的	限定的	なし
Figma以外への出力	Figma + PSD + Sketch + JSON + code	Figma のみ	Figma のみ	Figma のみ
MCP / エージェント連携	Visual Struct API を AI エージェントに利用可能	なし	なし	なし
無料版	あり	あり（クレジット制）	あり	あり

どれを選ぶかの目安は次のとおりです。Codia は、成果物がコード、バッチ処理、または Figma 以外の出力へ流れる場合に向いています。image.to.design や Banani は、Figma 内だけで完結するデザイン作業向きです。Refore は、編集可能性よりもベクターの忠実性が重要なときに向いています。

スクリーンショットから Figma への詳細比較は、Codia vs image.to.design: Detailed Comparison for Screenshot-to-Figma を参照してください。

Cursor + Figma MCP と組み合わせる

AI コーディングエージェント（Cursor、Claude Code、Windsurf、Codex）でデザインからUIを作るなら、screenshot-to-Figma は最初の欠けている一歩です。流れは次のとおりです。

参照をスクリーンショット化 する。競合ページ、インスピレーション、既存の本番画面など。
Codia で Figma に変換 する。参照が編集可能なフレームになる。テキストレイヤー、図形、画像レイヤー、グループ化された階層を持ち、検出された一部の行やスタックには Auto Layout も付く。数分かけて繰り返し要素をコンポーネント化し、チームで使っているなら色を Variables に紐づける。
Figma MCP サーバーをエディタに接続 する（Cursor / Claude Code / Windsurf）。
Codia で生成した Figma ファイルをプロンプトで参照 する。「このダッシュボードをデザインシステムに合わせてそのまま作って」と伝える。MCP サーバーは、平坦なスクリーンショットではなく、構造化されたレイアウトデータ、テキストとスタイルの値、レイヤー階層、そして自分で追加したコンポーネントや Variables をエージェントに渡す。
コード側で反復 する。

この方法が機能する理由は、Figma MCP が最もクリーンなコードを出すのは 構造化された意味的デザインデータ（命名されたレイヤー、コンポーネント、Variables、Auto Layout）があるときだからです。チャットに単なるスクリーンショットを放り込んでも、エージェントにとっては情報がほとんどありません。Codia で生成した Figma ファイルなら、出発点として実際のレイヤーと階層があり、仕上げで追加したコンポーネントや Variables がその先を補います。

この流れを段階的に追いたい場合は、Screenshot to Figma with Cursor and the Figma MCP Server を参照してください。

ローカルホスト、認証必須、非公開ソース

すべてのUIが公開URLにあるとは限りません。以下のようなものにも使えます。

localhost の開発ページ: スクリーンショットを撮って Codia に通す。スクリーンショットは万能なソースです。
認証配下の画面: ログインしてキャプチャし、変換する。HTML/CSS の忠実度が必要なら、HTML to Figma も非公開ビルドで使えます。
社内ツール: 同じ流れです。スクリーンショットできるものは変換できます。

変換後に確認すること - 完全品質チェックリスト

出力は、完成品ではなく「よくできた編集可能な下書き」として扱ってください。引き渡し前に次のチェックを通します。

テキスト

重要なテキストレイヤーはすべて編集可能か
改行は正しいか
句読点、大小文字、数字は正しいか
OCR が似た文字を取り違えていないか（O と 0、l と I、rn と m など）
フォント置換はプロダクトに合っているか

レイアウト

主要なコンテナは正しくグループ化されているか
カード、リスト、行の整列は揃っているか
繰り返し要素の間隔は一貫しているか
グリッドと列は維持されているか
オーバーレイ、ブラウザUI、OSバー、無関係な領域は削除されているか

アセット

アイコンは独立したレイヤーになっていて、自分のアイコンセットに差し替えやすいか
画像は正しく切り取られているか
シャドウとマスクは妥当か
ブランドカラーはデザインシステムに十分近いか。ずれているならデザイントークンに置き換える
装飾要素は機能UIと別にグループ化されているか

コンポーネント

繰り返し要素は Figma コンポーネントに変換する。これが長期的に使えるファイルにする鍵です。

ボタン（デフォルト、ホバー、無効など全状態）
フォームフィールド（input、textarea、select）
カード
ナビゲーション項目
テーブル行
リスト項目
バッジとタグ
アバターとアイコンボタン

レスポンシブ

ブレークポイントをまたいで拡張が必要なフレームは、Auto Layout を再構築する
テキストと画像のレイヤーが Auto Layout コンテナ内で正しく制約されているか確認する
レスポンシブ前提なら、1つのブレークポイントを変換して Auto Layout を整え、複製して調整する。毎回別々に変換し直すより効率的です

よくある落とし穴

ピクセル完全一致を期待しすぎる。 AI 変換は、きれいな入力なら大部分まで到達します。最後の詰めは、追加の変換ではなくデザイン判断です。

OCR レビューを飛ばす。 数字、日付、ラベルは最も間違いやすい部分です。必ず見直してください。

巨大なスクリーンショットを1枚で変換する。 長いランディングページや縦に長いダッシュボードは、論理的なセクションに分けてからアップロードしたほうがよいです。

コンポーネント化を忘れる。 変換しただけでコンポーネント化しないファイルは、1画面では便利でも、2画面目からチームの速度を落とします。

ソース選びを間違える。 画面写真、強く圧縮されたスクリーンショット、動画やアニメーションから切り出したフレームは、きれいな PNG エクスポートより精度が落ちます。

プラグインとAPI: どちらを使うべきか

Codia の Figma プラグインを使うべきケース は、日常的なデザイン作業で、数画面ずつ変換し、そのまま Figma 内で編集を続けたいときです。Figma Community から Codia AI Design: Screenshot to Editable Figma Design をインストールします。

Visual Struct API を使うべきケース は、バッチ処理です。たとえば競合UIのカタログ化、レガシー移行、自動 QA、あるいはスクリーンショットを下流の design-to-code ワークフローへ流す場合です。API は、ツール側で扱える構造化 JSON を返します。バッチエンドポイントは多数の画像をまとめて処理でき、完了時には webhook コールバックで通知されます。

多くのチームにとっての答えは、「デザイン作業はプラグイン、移行プロジェクトは API」です。

FAQ

どんなスクリーンショットでも Figma に変換できますか？

多くの鮮明な UI スクリーンショットは、十分に使える編集可能なFigma下書きになります。ぼやけた画像、低解像度のサムネイル、実物の画面写真、激しくアニメーションするUIは、変換後に手作業の調整が多くなります。

"image to Figma" は "screenshot to Figma" と同じですか？

はい、ほぼ同じ意味で使われます。image to Figma はより広い表現で、あらゆる画像入力を含みます。screenshot to Figma は UI のキャプチャを特に指します。Codia はどちらも同じワークフローで扱い、アプリ画面、Webページ、ダッシュボード、モックアップといった PNG、JPG、WebP の UI 画像向けに作られています。

screenshot to Figma でテキストは保持されますか？

はい。テキストは編集可能なテキストレイヤーとして復元され、フォント、サイズ、色は画像から検出されます。多くの言語のテキストを認識できます。結果を使う前に、綴り、改行、フォント置換を必ず確認してください。

ボタンが平坦な画像になったのはなぜですか？

たいていは、元画像が再エンコードされていた、ボタンのスタイルが特殊だった、あるいはボタンが他の要素と重なっていたことが原因です。上の専用セクションで対策を確認してください。どうしても平坦なまま残るアイコンやボタンは、切り出して Codia Image to SVG で変換できます。

出力はピクセル完全一致ですか？

いいえ。それが目的ではありません。目的は、グループ化された構造、実テキスト、独立した画像レイヤーを持つ、実用的な編集ベースを作って、手作業の再構築を省くことです。そこから再利用可能なコンポーネントを作るかどうかはあなた次第です。

screenshot to Figma は無料ですか？

Codia は、毎月 5 AI クレジットが付きクレジットカード不要の無料プランを提供しており、たまに使う用途をカバーできます。毎日の重い利用やチーム運用には有料プランがあります。上の無料版とPro版のセクションを参照してください。

Figma プラグインはありますか？

はい。 Codia AI Design: Screenshot to Editable Figma Design を Figma に直接インストールできます。

変換したファイルをコード生成に使えますか？

はい。まず Figma の構造を整えてください。適切にコンポーネント化され、命名され、Auto Layout が整った Figma ファイルのほうが、design-to-code の出力はずっと良くなります。 Figma to Code を参照してください。AI エージェントのワークフローなら、Screenshot to Figma with Cursor and the Figma MCP Server も見てください。

screenshot から直接 code に行くのはどうですか？

最終目標が Figma ではなく code なら、Screenshot to Code を参照してください。

Codia は image.to.design、Banani、Refore と比べてどうですか？

上の比較表と、専用の Codia vs image.to.design の詳細解説を参照してください。