Figma to HTML – Anima Appを使ってHTMLコーディングしてみた

Figma to HTML – Anima Appを使ってHTMLコーディングしてみた

2025年3月24日
TAKUJI OGAWA

導入: FigmaからHTMLコーディングへ

近年、デザインツールのFigmaで作成したデザインを自動でHTML/CSSに変換する「Figma to HTML」ツールが注目されています。デザイナーが作成したUIをそのままコード化できれば、開発者が一からHTML/CSSを書く手間を省け、プロジェクトの効率化につながります。そこで登場したのがAnima App(アニマ)です。AnimaはFigma(他にもAdobe XDやSketch)用のプラグインおよびサービスで、デザインから「実用的なHTML/CSSコード」を生成してくれるツールです。直接FigmaからHTMLを生成することで、デザインをブラウザ上で動くプロトタイプにしたり、LP(ランディングページ)など簡易なWebサイトを即座にデプロイしたり、開発者にとってはコーディング済みのUIパッケージを受け取って作業を加速したりできるとされています。本記事では、Anima Appを使ったFigmaからHTMLコーディングへの具体的な手順を初心者〜中級エンジニア向けに解説し、そのメリット・デメリットや実際の使用感について紹介します。

Animaを使ったHTMLコーディングの手順

*1. Figmaでデザインを準備する まずはFigma上でコーディングしたいWebページのデザインを完成させます。デスクトップやモバイルなど各画面サイズごとのフレームを用意し、必要に応じてコンポーネント化やAuto Layout(自動レイアウト)機能を使ってレイアウトを構築しましょう。Animaでの変換精度を高めるため、Figma上でのレイヤー名をわかりやすく整理し、隠れた不要要素は削除しておくと、後で生成されるコードがクリーンになります。例えばナビゲーションバーやフッターなど繰り返し使うUIはFigma上でコンポーネント化し、テキストはAuto Width/Heightに設定しておくと良いでしょう。これにより、Animaが不要なスタイルを出力するのを防ぎ、クリーンなHTML/CSSになる準備が整います。 ![](/assets/n04b60180427b_1742267612-YOWAobieN5dnpUcftRhG3PZX.png) 2. FigmaでAnimaプラグインを起動する デザインができたら、FigmaのプラグインからAnimaを起動します。Animaプラグインは通常の編集モード(Edit Mode)でも、FigmaのDev Mode(開発モード)上でも動作します。プラグインを立ち上げると、Animaにログインするよう求められるので、事前に無料アカウントを作成しておきましょう。ログイン後、AnimaプラグインのパネルがFigma内に表示され、ここからコード変換の設定を行います。 3. ブレークポイントの設定(レスポンシブ対応) 複数のデバイス向けにデザインしている場合は、AnimaのBreakpoints(ブレークポイント)機能を使ってレスポンシブなページとして設定します。例えば「ホームページ」のデスクトップ版とモバイル版のフレームを用意しているなら、それらをShiftキーなどで同時選択し、プラグイン内の「Responsive pages」機能から一つのページにまとめます。具体的には、Animaプラグイン内で「Responsive pages」→「+」ボタンをクリックし、新規レスポンシブページを作成します。選択した複数のフレームが一覧に表示されるので、それぞれに対応するブレークポイント(例えば「1280px以上をデスクトップ」「780px〜1279pxをタブレット」「〜779pxをモバイル」など)を指定して保存します。こうすることで、後述のエクスポート時にメディアクエリ付きのCSSが生成され、画面幅に応じて指定したレイアウトが自動で適用されるコードになるのです。 Animaプラグインのブレークポイント設定画面の例。Figma上でモバイル・タブレット・デスクトップ版の3つのフレームを用意し、Animaの「Responsive pages」でそれぞれ380px・810px・1500pxのブレークポイントとして登録している。 ![](/assets/n04b60180427b_1742267656-DkL4jeWvpYQEISCuxZ81RB20.png) 4. プレビューとインタラクションの設定 Animaプラグインには、コードをエクスポートする前にプレビュー(Preview)機能で出来栄えを確認する方法もあります。プラグイン内で「Preview in Browser」や「Open in Anima」などのオプションを使うと、AnimaのWebアプリ上で現在のデザインを実際にブラウザ表示して確認できます。ここではレスポンシブの効き方(ウィンドウ幅を変えたときのレイアウト変化)や、Figmaで設定したインタラクション(画面遷移やホバー効果など)が再現されているかをチェックできます。AnimaはFigmaのプロトタイプ設定もある程度引き継ぎ、リンク設定されたボタンのページ遷移や基本的なホバーアニメーションなど高忠実度なプロトタイプを実現します。例えば、Figma上で「ボタンをクリックしたら別のフレームへ遷移」というプロトタイプアクションを設定しておけば、プレビュー時にそのボタンが実際にクリック可能になり、対応するページに切り替わります。ただし高度なアニメーションや複雑な状態管理(例えばハンバーガーメニューの開閉など)はプレビュー上でも簡易的なものになるため、必要に応じて後述するように手動でコードを追加する必要があります。 ![](/assets/n04b60180427b_1742267734-KfQNE1CgLMukB0Xqjyhn9p8G.png) ![](/assets/n04b60180427b_1742267713-E7lJaQ3FGxbTZBqKifoU20yk.png)

 5. 出力されたコードの内容

Animaで「Get Code」を実行すると、Figmaで作成した3種類のレイアウト(mobile screen / tablet screen / desktop-all-breakpoints screen)のコードが、各約100行程度のブロックとしてそのまま出力されます。 - 出力形式: それぞれのレイアウトがひとつのHTMLファイル内にまとめられ、CSSはメディアクエリ(@media screen)を使って画面幅に応じて表示を切り替える仕組みになっています。 - これにより、各レイアウトは単にHTML内に挿入された状態となり、細かな最適化は後工程で行う必要があります。 ![](/assets/n04b60180427b_1742268061-T0CdyfOZAsIS5mirtxq4nUpo.png) ![](/assets/n04b60180427b_1742268074-8lvuQG0PjKEThJrfwCReacYo.png)

6. UIパーツの再現度について

- ハンバーガーメニューなどの動的要素: Figmaで設計したハンバーガーメニューやその他のインタラクティブなパーツは、エクスポートされたコードには含まれますが、その再現度は低いケースが多いです。 ![](/assets/n04b60180427b_1742268131-nDjO42tMCTa08JVqsPgd9XzB.png)

7. AI Coding Editor Cursorによる自動修正

- 自動修正の試み: 出力されたコードを元に、AI Coding Editor Cursorに「このコードを整形・修正せよ」と指示することで、自動でコードの調整を試みます。 - 基本的な文法の修正や、不要な入れ子の削除など、機械的な部分の改善はCursorが行います。 ![](/assets/n04b60180427b_1742268184-luqvXSsNUx67DmwaBV8KbEJ1.png)

8. AI Coding Editor Cursorの課題と手動調整

- Cursorの限界: しかし、Cursorは常に完璧な修正を実施するわけではありません。特定の複雑なレイアウトや、Figma特有の配置の再現については「沼」にハマることがあり、指示しても修正が完了しない場合があります。 - このような場合、エンジニア自身が手動でコードを確認し、微修正を加える必要があります。 ![](/assets/n04b60180427b_1742268209-DJMYtHCRX9x7sA4b6KWuVS5r.png)

9. デバッグと最終調整の実際

- 調整にかかる時間: 実際の作業では、AI Coding Editor Cursorに嫌味を言いつつ修正を試みた結果、最終的な調整に約1時間ほど費やすケースも見受けられました。 - デバッグや微修正工程は思った以上に時間がかかるため、全体の作業スケジュールには余裕を持たせる必要があります。 - 注意点: 自動生成されたコードをそのまま利用するのではなく、出力内容をよく確認し、特にメディアクエリの設定やUIの動作に不備がないか、手動での調整工程を必ず設けることが重要です。 - また、ハンバーガーメニューなど動的な部分は、必要に応じてJavaScriptで自前実装を行うなど、別途対応が求められる点にも留意しましょう。
HTML/CSSコードのエクスポート 準備が整ったら、いよいよコードを出力します。Animaプラグインでは2通りのエクスポートが可能です。 ![](/assets/n04b60180427b_1742268339-yqZ7OB1gpGNAwPeWRhJ0t4YM.png)

Anima導入のメリット・デメリット

メリット(効率化できる部分)

1. コーディング時間の短縮:  最大のメリットはやはりスピードです。そこまで制度が良くなくても デザインからHTML/CSSへの変換が少しの手間でとりあえず使えそうな(?)物が出てくるのはやはり心強い。
*

デメリット(自動化でカバーしきれない部分)

1. 生成コードの調整は避けられない: 生成されたコードをそのまま製品リリースできるケースはほぼ無理で、調整やリファクタリングが必要です。またFigma上の表現をそのまま再現する都合上、HTMLの構造がややディープ(入れ子が深い)になることもあります。 2. インタラクションや動的機能の不足: Animaが自動生成するのは主に静的なHTML/CSSと簡易的なスクリプトであり、本格的なJavaScriptロジックまではカバーしません。したがって、複雑なUIの動作再現は難しいです。例えばハンバーガーメニューの開閉動作や、モーダルダイアログの表示、カルーセルスライダーの自動送りなど、ユーザー操作に応じた動的振る舞いは生成コードに組み込まれません。同様に、フォームの送信動作や高度なアニメーションなども、コード上の土台は出力されてもロジックは自動化されないため、最終的にはエンジニアリングの出番となります。 3. 学習コストとツール依存: 新しいツールを導入する際には学習コストが付きものです。Animaも例外ではなく、Figmaプラグインの操作方法や、期待通りのコードを得るためのデザイン上のコツ(前述したレイヤー名の整理やAuto Layoutの活用など)を習得する必要があります。また定期的にFigmaやAnima側の仕様変更に追随しなければならず、アップデート情報のチェックも必要です。場合によっては「Animaのためのデザイン調整」を強いられることもあり、本末転倒にならないよう注意が必要です。 4. コスト面のハードル: Anima自体は基本利用無料プランがありますが、本格的に使おうとすると有料プランへの加入が実質必須になります。無料プランでは月に数回程度のコードエクスポートなど機能制限があるため、継続的なプロジェクト利用には向きません。Proプランは月額約$49(2025年時点)から提供されており、チームで使う場合は1ユーザーあたりこのコストが発生します。小規模プロジェクトや個人利用なら投資対効果は見合いやすいですが、予算の限られた現場では慎重に判断すべきでしょう。

実際の使用感: 作業時間短縮とコード品質

作業時間の短縮効果

実際にAnimaを使ってみると、その作業時間短縮効果は確かにあります。例えば、従来デザイナーから渡されたFigmaデザインをフロントエンドエンジニアがコーディングする場合、シンプルなLP1ページでも数時間かかることがあります。それがAnima経由ではデザイン完成後すぐにコードを書き出せるため、Figma側で設定さえ終わっていればものの数分で基本的なHTML/CSS一式が揃います。特に繰り返しの多いパターン(カードUIが何十枚も並ぶ等)では、人手で書くよりも自動生成の方がミス無く一括生成できる利点があります。結果として、デザイン修正→コーディング修正の反復も素早く行えるため、筆者の体感では、ある程度きちんと設計されたFigmaファイルであれば、コーディング工数は従来の半分以下になるケースもあります。もちろん後工程の調整時間は別途必要ですが、それでもトータルでは十分な効率化が感じられました。

生成コードの品質とレスポンシブ対応

Animaから出力されたコードを確認すると、思った以上に整然としている印象を受けます。HTMLの構造は見通しが良く、適切にやといった要素が割り振られ、テキストも見出しタグと段落タグに分類されています(多少大雑把な割り当ての場合もあります)。ただしFigma側のレイアウト名をそのまま適用するので、ある程度Figma側で名前をしっかり入れ込む必要があります。CSSもBEM記法風のクラス名が付与されており、全体としてルールに沿ったスタイル定義になっています。FigmaでAuto Layoutを使っていた部分はCSSでもdisplay: flex;やgapで再現され、手動コーディングと遜色ないレイアウト実現方法でした。もちろん完璧というわけではなく、細かい部分で全然うまく言っていない部分が多いです。しかし「ゼロから自分でコーディングした場合」と比べれば十分許容範囲であり、むしろ土台ができている分修正も楽に感じます。

ハンバーガーメニュー等複雑UIの再現度

Animaの弱点として挙げられるのが、複雑なユーザーインターフェースの再現です。例えばハンバーガーメニューを例にとってみましょう。デザイン上では「PCでは水平ナビゲーション、モバイルではハンバーガーメニューに変化する」というレスポンシブ対応は、Animaでもブレークポイント機能で実現できます。実際、エクスポートされたHTMLにはPC用メニューとモバイル用メニューの両方の要素が含まれ、CSSで画面幅に応じて表示・非表示が切り替わるようになっていました。ただしAnima側もまったく対処していないわけではなく、簡単なホバーエフェクトやスクロールアニメーション程度ならCSSや簡易スクリプトで表現されています。例えばボタンのホバーで色が変わる、フェードインアニメーションがつく、といった装飾的な動きは生成コードにも含まれていました。とはいえ総じて、Animaはあくまで静的な部分(マークアップとスタイル)までを担当するツールであり、アプリケーション的な振る舞いはエンジニアの実装領域だと考えておくのが適切です。

結論: Animaは初・中級エンジニアにとって導入する価値があるか?

その最大の強みは、コーディングの初歩的な部分を自動化することで、エンジニアが本来注力すべき機能開発や高度なUI実装に時間を割けるようになる点にあります。しかし、エンジニアにとっては「あと一歩惜しい」部分も散見されるため、Animaを完全自動コーディングツールというよりは「コーディング補助ツール」として位置付けるのが現実的でしょう。ベースがあるのと無いのとでは生産性が大きく違うため、導入価値はあります。 もっとも、Anima導入の判断にはコスト要因も絡みます。個人や小規模チームであれば月額利用料も比較的安価に感じられるかもしれませんが、予算が厳しい場合や既に確立した手作業フローがある場合は無理に導入する必要はありません。Animaをうまく取り入れるには「機械に任せる部分」と「人間がやる部分」を切り分け、ワークフローを上手く組み上げてチーム全体の生産性を上げられるかが鍵と言えます。