チームがよく直面するのは、元のデザインソースが見つからない、古い、あるいは最初から存在しない Web サイトをリデザインする場面です。実際のページこそが UI の唯一の正確な情報源であることが多く、それを Figma に手作業で写すと 1 画面あたり数日かかることもあります。
Website-to-Figma 変換はこの課題を解決します。Codia AI にライブ URL を指定するか HTML/CSS を貼り付けると、編集可能な Figma ファイルとして出力されます。フレーム、テキストレイヤー、コンポーネント、デザイン トークンまで揃うため、デザイナーはゼロから作り直すのではなく、実際の公開ページをもとに監査、リデザイン、ドキュメント化、あるいはデザインシステムの抽出ができます。
関連する Codia 製品：Codia HTML to Figma。
このガイドでは、Website-to-Figma と Screenshot-to-Figma、HTML-to-Figma の使い分け、ランディングページ / SaaS アプリ / EC / マーケティングサイトごとの実践ポイント、キャプチャ前の準備、変換後のクリーンアップまでを網羅します。
Website-to-Figma を使う場面
次のようなケースでは、このワークフローが向いています。
- 元の Figma ファイルがなくなった、または古くなっている。
- リデザインを始めたいが、まずは現在のページを編集可能なベースにしたい。
- Figma と本番環境の差分を把握したい。
- 競合調査をしたいが、静的なスクリーンショットではなく編集可能な参照がほしい。
- 実際のプロダクト UI をデザインシステム作業のために Figma に戻したい。
- 既存ページからデザインシステムを抽出したい。
- 引き継いだマーケティングサイトをデザイン運用の対象にしたい。
Website-to-Figma / Screenshot-to-Figma / HTML-to-Figma の違い
3 つのワークフローは目的が似ていますが、入力とトレードオフが異なります。
| ワークフロー | 入力 | 最適な用途 |
|---|---|---|
| Website to Figma | ライブ URL | ブラウザで開けるページ。計算済み CSS や実際のフォント名など、ソースに近いレイアウト情報がほしい場合。 |
| Screenshot to Figma | PNG/JPG | ライブページにアクセスできない場合。課金壁の内側、社内限定、削除済み、画像しかないケース。 |
| HTML to Figma | 生の HTML/CSS | ソースコードを持っていて、最も高い忠実度がほしい開発主導のワークフロー。 |
実際には、ライブ URL は現在のサイトや競合サイト、スクリーンショットはインスピレーションボードやアクセスできない参照、HTML はエンジニア主導の変換、というように組み合わせて使うのが一般的です。
ワークフロー
- URL とビューポートを決める。デスクトップ、タブレット、モバイルのどれを取るかを決め、必要なら各ブレークポイントを別々にキャプチャする。
- ページを準備する。Cookie バナー、ポップアップ、チャットウィジェットを閉じ、必要に応じてログイン / ログアウトし、フォントや遅延読み込み画像を待つ。
- 重要な状態を個別にキャプチャする。変換されるのは、その時点で見えていたものだけです。ナビゲーション展開、モーダル表示、空状態、価格切り替え、ホバーカード、モバイルメニュー、ログイン後状態は、それぞれ別ジョブで取る。
- 変換を実行する。Codia AI がレイアウト、タイポグラフィ、カラー、アイコン、画像、コンポーネント構造を解析する。
- 結果を Figma で開く。キャプチャした各ビューポートは独立したフレームになる。
- レビューする。下のチェックリストを使う。
- 繰り返し使うセクションをコンポーネント化する。ナビ、ヒーロー、機能カード、フッター、CTA ブロックなど。
シナリオ別のコツ
マーケティング ランディングページ
- 長いページは 1 セクションずつ変換する。ヒーロー、機能、実績、価格、FAQ、フッターに分けると、1 回の巨大キャプチャよりも Auto Layout 構造がきれいになる。
- ヒーローのイラストや装飾グラデーションはラスタライズされやすい。必要ならデザインシステムのベクター資産に置き換える。
- 価格表はそのセクションだけに絞ってキャプチャすると扱いやすい。
- A/B テストのバリアントは別々に変換し、Figma 上で並べて比較する。
SaaS アプリ画面
- 実プロダクト画面には個人情報や機微情報が含まれやすいので、キャプチャにはデモアカウントや空状態を使う。
- サイドバー、トップナビ、モーダルは画面間で繰り返し使われる。1 画面を変換したら、まずクローム部分をコンポーネント化し、次の画面に進む。
- 空状態、エラー状態、読み込み状態は Figma ソースに欠けがちなので、意識的にキャプチャする価値がある。
- データグリッドやテーブルのような密度の高い UI は、Screenshot to Figma のダッシュボード向けヒントも参考になる。
EC サイト
- 商品ギャラリーは画像プレースホルダーとして出ることがあるので、実際の商品写真に差し替える。
- バリアント選択、サイズ選択、数量ステッパーはコンポーネント化しやすい。
- PDP、カート、チェックアウトをまとめて変換すると、購入導線全体に沿ったデザインシステムになる。
競合調査
- 競合のランディングページを編集可能な Figma 参照に変換し、静的なスクリーンショットではなく、構造、コピー、レイアウト、視覚的ヒエラルキーを分析できるようにする。
- 複数の競合キャプチャを 1 つの Figma ファイルにまとめ、横並びでレビューする。
- キャプチャは 参考と分析 として使い、1:1 の複製にはしない。公開前には必ず自社ブランドに合わせて作り直す。
本番 UI を Figma に戻して記録する
- 実際のプロダクトでトラフィックの多いページを、1 ページずつ変換する。
- 復元された色やテキストスタイルは、インポート時に Figma ライブラリへマッピングする。レポートでは、システムと一致しない色やスタイルが指摘される。
- これが「Figma ソースと本番のズレ」を解消するための土台になる。
変換後に直すべきこと
インポート結果は、よくできた編集可能ドラフトとして扱うのが正解です。次を確認してください。
- フォント。Web フォントは Figma で最初に開いたときに代替される。デザインシステムのフォントへマッピングする。
- テキストスタイル。アドホックなタイポグラフィをデザイントークンに置き換える。
- アイコン。ラスターアイコンはライブラリの適切な SVG アセットに差し替える。
- 背景画像。正しくトリミングし、必要なら装飾背景はデザインシステムのアセットへ置き換える。
- 繰り返しセクション。カード、ナビ項目、ボタン、フッターを Figma コンポーネントにまとめる。
- レスポンシブ制約。ブレークポイント間で伸縮する必要があるフレームは Auto Layout を組み直す。
- サードパーティ ウィジェット。チャット吹き出し、Cookie バナー、分析オーバーレイはデザインシステムに含めない。削除する。
- カラートークン。復元された色をデザインシステムのカラートークンにマッピングする。
よくある落とし穴
間違ったビューポートを取ること。 1440px のキャプチャだけでは、375px でどう見えるかは分かりません。必要なブレークポイントごとに取ってください。
オーバーレイを閉じ忘れること。 Cookie バナー、チャットウィジェット、Hotjar のアンケートはすべて一緒にキャプチャされ、後処理が増えます。先に閉じましょう。
個人化された状態を取ること。 実ユーザーのデータ、名前、社内ツールなどは、必ずログアウトするかデモアカウントを使ってください。
1 回の巨大スクロールキャプチャ。 長いページはセクション単位で変換した方がうまくいきます。
インタラクティブ状態を省くこと。 メニュー、モーダル、ホバーカード、空状態は通常のキャプチャには含まれません。別ジョブとして取ってください。
変換をデザインだと思い込むこと。 出力はベースラインです。本当のデザイン作業は、その後のクリーンアップ、コンポーネント化、リデザインの判断です。
API とバッチ変換
単発のデザイン作業なら、プラグインと Web アプリの流れで十分です。代理店が 200 件のクライアントサイトを再構築する場合や、社内チームがプロダクト全体を文書化する場合、デザイン運用チームが市場横断でブランド監査を行う場合のように、大量のページを変換するなら、Visual Struct API が URL を受け取り、ページをキャプチャし、構造化 JSON を返します。これを使って Figma に変換したり、下流のデザインパイプラインに流し込めます。
バッチエンドポイントは、処理完了時に webhook コールバック付きで大量の URL 取り込みを処理します。
FAQ
どんな Web サイトでも Figma に変換できますか？
多くの可視 Web ページは、十分に使える編集可能なドラフトになります。高度に動的なアプリ、キャンバス中心のページ（3D、WebGL）、個人化された画面は追加のクリーンアップが必要なことがあります。自動キャプチャをブロックするサイトは、代わりにスクリーンショットベースのワークフローが必要です。
レスポンシブ レイアウトもキャプチャされますか？
指定したビューポートがキャプチャされます。レスポンシブ対応が必要なら、デスクトップ、タブレット、モバイルを別々にキャプチャしてください。
インタラクティブ状態もキャプチャされますか？
可視状態のみです。メニュー、モーダル、ホバーカード、空状態は別ジョブとしてキャプチャしてください。
変換後のファイルには実コードも含まれますか？
いいえ。Figma はデザインツールであり、コードソースではありません。Web サイトから コードへ 行きたい場合は、website → Figma → Figma to Code という流れにするか、スクリーンショットを直接使って Screenshot to Code を使えます。
競合調査に役立ちますか？
はい。編集可能な Figma 参照は、フラットなスクリーンショットよりも、分析やリデザイン計画にずっと役立ちます。ただし、あくまでインスピレーションとして扱い、1:1 のコピーにはしないでください。
認証が必要なページはどう扱いますか？
ログイン済みブラウザセッションか一時的なデモアカウントを使ってください。機微な顧客データは、キャプチャ入力に含めるべきではありません。
サイト全体を一度に変換できますか？
個人のデザイン作業では、ページごとにキャプチャしてください。数十から数百ページあるサイト全体の変換には、Visual Struct API のバッチエンドポイントを使います。