HTML と CSS のソースコード、つまり自社の本番コード、オープンソースのUIライブラリ、フロントエンドのプロトタイプ、静的エクスポートなどにアクセスできるなら、それを直接編集可能なFigmaファイルへ変換できます。これは、Website-to-Figma の開発主導・ソース先行版です。
ライブURLではなくソースコードを使う理由は3つあります。まず、忠実度が最も高いこと。計算済みスタイルが、ピクセルから推測されるのではなくCSSからそのまま来るためです。次に、キャプチャしづらいページ（ビルド時生成、認証後、開発中）でも使えること。最後に、エンジニア主導のワークフローでコードとデザインを往復させるのに向いていることです。
関連する Codia 製品：Codia HTML to Figma。
HTML-to-Figma を使う場面
次のようなときに向いています。
- ページが開発環境にあり、まだデプロイされていない。
- デザインソースはないが、静的な HTML/CSS エクスポートはある。
- コードで書かれたオープンソースのデザインシステムやコンポーネントライブラリを扱っている。
- エンジニアがページを所有していて、本番CSSからFigmaソースを逆生成したい。
- コンポーネントライブラリをFigmaへドキュメント化して、デザイン整合を取りたい。
- デザインシステムチームが、本番CSSとデザイントークンの差分を監査したい。
ページにアクセスできるURLがあるなら、通常は Website-to-Figma のほうが簡単です。HTML-to-Figma は、ソースコードそのもの しか手元にないときのためのものです。
HTML to Figma vs Website to Figma vs Screenshot to Figma
| Input | Workflow | Best for |
|---|---|---|
| Raw HTML/CSS source | HTML to Figma | Dev-led conversion, max fidelity, unpublished pages. |
| Live URL | Website to Figma | Reachable pages, including competitor and production. |
| PNG/JPG | Screenshot to Figma | When all you have is an image. |
3つのワークフローは、どれも同じ出力先、つまり編集可能なFigmaファイルへ向かいます。違うのは、入力するものです。
ワークフロー
- ソースを準備 する。HTML が単独で正しくレンダリングされることを確認します。CSS が足りない、フォントが壊れている、ビルドサーバーが起動していない、という状態は避ける。
- 変換する。 Codia AI がマークアップを解析し、計算済み CSS スタイルを適用し、画像とフォントを解決し、見た目を Figma レイヤーに再構築します。
- 結果を Figma で開く。 各変換ジョブは、構造化レイヤー、テキストスタイル、画像塗りを持つフレームとして着地します。
- レビュー する。下の整理セクションを参照してください。
- 繰り返しコンポーネントをコンポーネント化 して、Figma ファイルがソースコードと同じ構造になるようにします。
変換後に何が残るか
たいていきれい
- セマンティックな HTML 構造 -
<section>、<article>、<header>、<footer>とその入れ子レイアウトは、グループ化された Figma フレームとして変換される - テキスト内容とタイポグラフィ -
font-family、font-size、font-weight、line-heightを保持した実テキストレイヤー - 色の値 - 単色の背景とテキスト色は Figma の塗りへ直接変換される
- Flexbox と Grid レイアウト - 比喩がきれいに成り立つ範囲では Figma Auto Layout に変換される
- 境界線、角丸、シャドウ - Figma の効果として適用
- 画像 - 元のアセットURLを参照する image fill として配置
要レビュー
- CSSのみの複雑な効果 -
backdrop-filter、複雑なmask-image、多段グラデーションのブレンド。Figma に近い表現へ近似される - 疑似要素 -
::before/::afterの内容は別フレームとして取り込まれる。疑似クラス状態（:hover）は各状態ごとにキャプチャが必要 - カスタムフォントのホスティング - 独自 CDN で読み込むフォントは、ローカル Figma フォントへの手動マッピングが必要な場合がある
- CSS変数とデザイントークン - 生の値として保持される。Figma のデザインシステムへ戻すのは手作業
- JS駆動のレイアウト - JavaScript でサイズや位置が決まるものは、変換前に最終状態まで実行されている必要がある
- Webアニメーション - Figma は CSS keyframes や transition をネイティブには表現しない。停止状態を変換する
役割別のユースケース
コードベースを引き継ぐデザイナー
入社したら本番フロントエンドはあるのに Figma がない、という状況で使えます。HTML-to-Figma は、すべての画面を手作業で再構築せずにデザイン作業を始めるための出発点になります。
デザインシステムチーム
本番CSSに実際何があるのかを、Figma ライブラリと比較します。コードベースから代表的なコンポーネントを変換し、Figma の対応物と並べると、ずれが見えます。
コンポーネントを文書化するエンジニアリングチーム
コンポーネントライブラリはコードにあり、デザインチームはFigmaでのドキュメントを求めているなら、HTML-to-Figma が橋渡しになります。各コンポーネントの Storybook やデモを Figma フレームへ変換します。
代理店とフリーランス
クライアントから静的 HTML モックアップを受け取ったとき（以前の制作会社の成果物など）、手作業で作り直すより HTML-to-Figma のほうが速く、再設計用の編集可能な土台を得られます。
何を整理すべきか
変換後は、次を重点的に確認します。
- テキストスタイル - インラインスタイルを Figma のタイポグラフィトークンに置き換える
- カラートークン - 復元された hex 値をデザインシステムのカラーにマップする
- アイコン - ラスターアイコンをライブラリの SVG コンポーネントに置き換える
- Auto Layout - レスポンシブセクションで正しく変換されたか確認し、必要に応じて再構築する
- コンポーネント構造 - 繰り返しパターン（カード、ボタン、リスト項目）を Figma コンポーネントにする
- 命名 - コードのクラス名はデザイン名にそのままは対応しない。デザイン用にリネームする
- サードパーティウィジェット - 分析、チャット、同意オーバーレイをデザイン面から取り除く
よくある落とし穴
ソースが半壊している。 HTML がブラウザで正しく表示されないなら、変換は壊れているものを復元できません。まずソースがきれいに表示されるか確認してください。
CSSやフォントが欠けている。 同じ話です。外部CSSやフォントの読み込みに失敗すると、変換結果はフォールバックを拾います。変換用には全部まとめてください。
JSで描画されるコンテンツを忘れる。 重要なレイアウトや内容がページロード後に JavaScript で描画されるなら、変換前に JS を実行して、ページが完全に hydrate された状態にしてください。
CSSアニメーションをそのまま期待する。 Figma は静的です。停止状態を変換し、必要なら後からインタラクティブなバリアントを Figma で設計します。
コード品質チェックとして扱う。 HTML-to-Figma はコードをリファクタリングしません。あるものをそのまま変換するだけです。コード品質の作業はコードレビューでやるべきです。
Figma-to-Code と組み合わせる
エンジニアリングチームにとって役立つ往復パターンは、HTML → Figma（このワークフロー） → Figma で整理 → Figma to Code → きれいにリファクタされたフロントエンド、という流れです。ばらついた本番CSSを、デザインシステムに揃った実装へまとめ直したいときに有効です。
API アクセス
コンポーネントライブラリやデザインシステム全体をまとめて変換するなら、Visual Struct API が HTML 入力を受け取り、下流ツールが Figma に変換したり、デザイン運用パイプラインへ流せる構造化 JSON を返します。
FAQ
生の HTML/CSS を本当に編集可能な Figma に変換できますか？
はい。変換は HTML を解析し、計算済み CSS を適用し、見た目を Figma レイヤーとして再構築します。テキストは実テキスト、色は実際の塗り、レイアウトは比喩が成り立つ範囲で実際の Auto Layout になります。
ページをスクリーンショットするのと何が違いますか？
スクリーンショットでは、計算済み CSS の文脈が失われます。フォントや正確な色、レイアウトの理由付けを、ピクセルから再推定しなければなりません。HTML-to-Figma はソース値から始めるので、忠実度が高く、確認の負担が低くなります。
React や Vue のようなフレームワークでも動きますか？
変換対象は、フレームワークのソースではなく レンダリング済み HTML です。コンポーネントを HTML/CSS としてレンダリングし（Storybook、静的エクスポート、ブラウザDevToolsの "Copy outerHTML" など）、それを入力してください。
Tailwind CSS クラスはどうなりますか？
Tailwind は実行時に通常の CSS へコンパイルされるので、変換側からは普通の CSS ルールとして見えます。復元される Figma スタイルは、クラス名ではなく見た目に一致します。
デザイントークンは保持されますか？
CSS カスタムプロパティ（--brand-primary など）は生の値として保持されます。Figma のデザインシステムトークンへ戻すのは手作業ですが、レポートが各トークン値を拾ってくれるので、体系的にマッピングできます。
フルサイトが必要ですか？ 1コンポーネントでも使えますか？
どちらでも構いません。フルページでも、単一コンポーネントのスニペットでも入力できます。小さく焦点の定まった入力のほうが、たいていきれいな出力になります。
API はコンポーネントライブラリ全体を処理できますか？
はい。Visual Struct API のバッチエンドポイントを使えます。