フロントエンドの開発現場では、人手不足の中で単純なHTMLマークアップ作業を自動化し、人間はより創造的な作業に集中したいというニーズが高まっています。近年の生成AI（Generative AI）の進化により、コーディングの反復的な部分を自動化し、開発者がクリエイティブな作業に専念できる環境が整いつつあります。本記事では、デザインからのマークアップ生成にAIを活用する試行錯誤の過程を振り返り、最終的に導入したLocofy.AIに焦点を当てて、その導入効果と課題について紹介します。

tl;dr

スクリーンショットからHTML/CSSを生成するLLM（ChatGPTやClaudeなど）ではデザインの細部再現が難しく実用度は低かったです。一方、Figma連携のAIコーディングツールではLocofy.AIが頭1つ抜けて高精度でした。ほぼデザインどおりのコードを自動生成し差分同期まで可能でした。ただし前提としてFigmaデザインの整備（コンポーネント化、Auto Layout対応、命名ルールなど）が不可欠で、準備が不十分だと恩恵を十分に得られません。AIを活かせる企業とそうでない企業の格差が生まれつつあるのを実感しました。

AI画像解析を用いたマークアップ生成の試み

まず取り組んだのは、完成デザインのスクリーンショットをそのままLLMに入力し、HTML/CSSのマークアップを生成させる方法です。ChatGPT、Google Gemini、Anthropic Claude、V0などを試しました。手順としてはデザイン画像をアップロードし「このデザインを再現するHTML/CSSを書いてください」といったプロンプトを投げるだけです。生成結果は一見それらしく、テキストやレイアウトの大枠は拾えていました。しかし細部のスタイル再現性に課題があり、特にカラーや余白（paddingなど）がデザインと一致しません。例えば、ChatGPT（GPT-4V）にMaterial DesignのスライダーUIの画像からコード生成させたケースでは「色合いやデザインは少し異なる」が「スライダーとしては動作する」程度で、デザインを忠実に再現するには追加の指示や調整が必要だったと報告されています。実際、私たちの試行でも同様にスタイルの詰めが甘く、「ほぼ完成」から最後の仕上げに想像以上の手間がかかりました。生成AIはコーディングの下支えにはなるものの、このアプローチだけでピクセルパーフェクトなマークアップを得るのはまだ難しく、プロダクション利用には至りませんでした。

Figmaプラグインを活用したコーディング自動化ツールの模索

画像解析の精度に限界を感じ、次にデザインデータそのものからコードを起こす手段を検討しました。具体的にはFigmaのプラグイン経由でデザイン情報を取得し、自動コーディングするツールです。いくつか試した中で、以下のようなツールを検証しました。

• Figma to Cursor（CursorのAIエディタ連携）およびBuilder.ioのVisual Copilotプラグイン

  Figma上のレイアウトをAIで解析し、直接コードを生成できるプラグインです。操作自体はワンクリックで簡単でしたが、生成コードを確認すると細かなスタイル調整が必要でした。特にフォントサイズやマージンの微調整、コンポーネント間の一貫性など、デザインとの乖離がいくつか見られます。業界的にも、これらのFigma-to-codeツールはデザインデータの準備状況に出力品質が大きく左右され、現状では「100%完璧なコードにはまだ至らない」「生成後の微修正は避けられない」と指摘されています。実際、私たちの環境でもデザインどおりに動くコードに仕上げるには追加修正が必要で、この段階では導入の決め手には欠けました。

• Figma Context MCP（Model Context Protocol）

  これはプラグインというよりFigmaの設計情報をAPI経由でLLMに流し込む仕組みです。Cursorなどのエージェント型AIにレイアウト情報を与えてコード生成させるオープンソースの試みで、先述のプラグインよりは改善が見られ、今まで試してみたやり方の中には一番でした。Paddingやカラーなど、デザインの細部まで認識され、複数コンポーネント間の整合性も高まります。しかし、依然として手直し箇所は出てくるため、「自動化のための準備作業と手直し作業のバランス」を考えると決定打には欠けました。

このように各種ツールを比較検討した結果、最も有望だったのがLocofy.AIのFigmaプラグインでした。

Locofy.AIを採用した理由

いくつかの選択肢を試した中で、最終的にLocofy.AIを導入する決め手となったのはコード生成精度の高さです。LocofyのFigmaプラグイン「Locofy Lightning」を使うと、デザインからほぼピクセルパーフェクトなコード変換が可能でした。実際に社内のデザインを変換したところ、見た目・レイアウトともにほぼ100%デザインを再現したHTML/CSS（およびReactコンポーネント）を得ることができ驚きました。

さらにLocofyは「差分同期（Smart Regenerate）」の機能を備えています。Figmaデザインを更新した際、再度プラグインを実行すると変更差分だけを検出してコードに反映できるため、最初からコードを書き直す必要がありません。これはGitHub連携によるスマートマージ機能で実現されており、デザインとコードを常に同期して単一のソースに保つことができます。私たちの検証でも、小さなデザイン修正であればLocofyがコード側に自動反映してくれたため、人手による微修正が大幅に減りました。

以上の高い再現性と効率的なワークフローにより、「デザインからコーディング」の単純作業をAIに任せ、人間はロジックや体験の部分に注力するという当初の目的に近づけると判断し、Locofy.AIを採用しました。

Locofy導入で期待した効果

Locofy.AIを導入することで、単純なマークアップ作業からの解放を実現し、以下の効果を強く期待しました。

• デザイン再現度の飛躍的向上: Locofyが“Pixel perfect”を謳うとおり、Figma上の色・タイポグラフィ・余白などスタイルの細部まで忠実にコード化してくれるはずです。
• 開発スピードの加速: デザインのアップロードからコード生成までをワンストップで行えるため、フロントエンド初期実装のリードタイムが大幅に短くなると見込んでいました。特にプロトタイピング段階では、デザイン確定後すぐに動作確認可能な画面が手に入ることで、チーム内のフィードバックサイクルが格段に速くなるはずです。
• 差分のみの反映による効率化: Figma上での部分的なデザイン変更を、Locofyの差分同期機能が自動で検知・コードに反映してくれると期待しました。たとえば、ボタンの色や文言を変えただけで、その差分だけを適用したコードが生成され、人手による微修正やコンポーネント差し替えの手間がほとんど不要になるはずです。結果として、リファクタリングや微調整に費やす工数を大幅に削減できると考えていました。

以上のようにLocofy導入で「デザインどおりのコーディング」がほぼ実現すると期待していました。しかし、実際に使ってみるといくつか期待と異なる点があり、注意すべき前提条件も明らかになりました。次のセクションでは、Locofyを最大限に活用するためにデザイン面で整備すべきポイントについて解説します。

Locofy導入後に分かった注意点

Locofyの精度は高いものの、そのアウトプットをメンテナブルな形で得るにはデザインデータ側の準備が重要だと痛感しました。雑なデザインをそのまま流し込むと、コードも同様に雑になるためです。Locofy導入後に判明した注意点として、以下のポイントを整理します。

• Figma上でのコンポーネント化: 同じUIパーツはFigmaでコンポーネント化しておかないと、Locofy側ではそれぞれ別個のコンポーネントとしてコード生成されてしまい冗長になります。Figma上でレイヤー構造がバラバラだと、Locofyは同じパーツと認識できず「似たようなコードの重複」を生みがちです。デザイン段階で使い回し部分をしっかり部品化し、一貫した構造に整えることが必要です。
• Auto Layoutの徹底活用（レスポンシブ対応）: レスポンシブなデザインを実現するにはFigmaのAuto Layoutを正しく利用することが不可欠です。要素を手動配置していると、Locofyは固定サイズや絶対位置のスタイルを吐き出すことがあり、画面サイズの変化に対応できません。反面、Auto Layoutで余白や揃え方を適切に設定しておけば、Locofyも各要素の伸縮ルールを理解してレスポンシブなコードを生成してくれます。デザインカンプとは別にブレークポイントごとに個別デザインを用意するような手法は、Locofy経由では統合が大変になるため避け、単一のAuto Layout設計で調整する方が効率的です。
• フレーム（レイヤー）命名の明確化: Figma上のフレームやレイヤー名はわかりやすく付けておくべきです。例えばFrame 123のようなデフォルト名だと、Locofyはその意図を汲めず意味不明なクラス名やコンポーネント名を生成してしまうことがあります。逆に「Header」「MainButton」のように明確な名前を付与しておけば、生成コード上の命名も自ずと分かりやすくなります。
• 既存のReactコンポーネントを共有する: 既にプロジェクトに共通コンポーネントが存在する場合、それをLocofyに認識させないと重複したコンポーネントが別名で生成される恐れがあります。同じボタンUIなのにButton.jsxとButton2.jsxができる…といった事態を避けるため、Storybookなどを介して既存コンポーネントをLocofyにインポートし、Figmaの該当パーツにマッピングすることが望ましいです（LocofyはStorybook連携によるコンポーネントマッピング機能を提供しています）。このひと手間でコードの一貫性とコンポーネントのDRY原則を維持できます。
• プロジェクト固有の命名規則やCSS設計の反映不可: Locofyは汎用的なコードを生成してくれますが、チーム独自のコーディング規約（クラス命名やBEM記法、CSS設計手法など）までは考慮してくれません。そのため、生成後のコードに対しては必要に応じてリファクタリングが必要です。私たちの場合、Cursorエディタを併用しつつ生成CSSをプロジェクトの命名規則に合わせて修正しました。コーディング規約のすり合わせはAI任せにせず人間がフォローする必要があります。
• グローバルCSSやテーマの影響: プロジェクトによっては全体に適用されるCSSやデザインテーマがありますが、Locofyが生成するスタイルと衝突するケースがありました。たとえば既存のグローバルCSSでbuttonタグにデフォルトスタイルが当たっていると、Locofy生成物の見た目が崩れたり、毎回別クラスが生成される原因になりました。対策として、Locofyに流し込むデザインは可能な限りプロジェクト固有のスタイル影響を排除し、ニュートラルな状態でコード生成させることが重要です。必要に応じて、生成後にプロジェクトのテーマ変数に置き換えるなどの調整も発生します。

以上の注意点を踏まえると、Locofy導入前にはデザインシステムやコンポーネント設計の見直しが欠かせません。

なぜ事前のデザイン整備が必要か

上記の注意点は裏を返せば、「Locofyなどのコード生成AIを最大限活かすにはデザイン側に一定の秩序やルールが必要」ということです。大企業であればデザインシステム（UIキットやスタイルガイド）が整備されている場合もありますが、中小企業やスタートアップではFigma上のデザインが個人の裁量に委ねられ、Auto Layout未使用・命名ゆるめ・コンポーネント未整理といった状態も珍しくありません。

そうした無秩序なデザインデータをそのままLocofyに投入すると、案の定冗長なコードや重複コンポーネントが生成されてしまいます。実際、Figmaのレイヤー構造が画面ごとにバラバラだと、Locofyは共通パターンを見出せず別々のコンポーネントとしてコード化してしまいます。またレイヤー名がそのままクラス名になるため、適当な名前だとコード上でも意図が伝わらない変数名が出てきます。

要するに、コード生成AIは「与えられた設計図どおりに組み立てる職人」のようなものです。設計図（=デザインデータ）が曖昧だったり散らかっていたりすれば、それがそのまま出力物（=コード）の品質に跳ね返ります。Locofyは優秀な「大工」ではありますが、木材の材質や図面の精度までは補完できません。だからこそ、事前にデザインシステムやレイアウトルールを整備し、AIが理解しやすい形にしておく必要があるのです。

この点、中長期的には「デザインと開発の共通言語を整えること」が組織の課題になってくるでしょう。Locofyのようなツールを使うか否かに関わらず、デザインの一貫性やコンポーネント化は最終的に開発効率につながるためです。Locofy導入はその課題を炙り出す良い機会にもなりました。

Locofyの活用が向いているケース

以上を踏まえ、Locofyのようなデザインtoコード自動化が特にフィットしやすいケース・企業を考えてみます。

• プロトタイプ重視のスタートアップ: プロダクト開発のスピードを最優先するようなチームでは、Locofyによる即時コーディングが強力な武器になります。デザインさえできれば即座に画面が動くため、アイデア検証やピボットが素早く行えます。多少コードが荒くてもまず形にするフェーズでは大いに役立つでしょう。
• デザインシステムが確立している企業: デザインのコンポーネント化やスタイル統一が徹底されている環境では、Locofyの出力も綺麗にまとまりやすいです。前述したような事前準備がすでに整っているため、生成コードをそのままプロダクション品質で使える可能性が高まります。言い換えればデザインのルール化に投資してきた企業ほどLocofyの恩恵を受けやすいと言えます。
• これからデザインシステム導入を進めたい企業: 稀なケースかもしれませんが、「今まさにデザインシステムを整備しようとしている」段階の企業にもLocofyは刺激になります。Locofyを試すことで、逆に既存デザインのどこが非効率か（コンポーネント未統一など）見えてくるため、そのフィードバックを元にデザイン体制を強化できます。もっとも、整備途上での導入は相応に混乱もあるため、実験的な位置づけになるでしょう。

まとめ

Locofy.AIを中心としたデザインからのコード自動生成について、その効果と課題を紹介しました。結論として、Locofy自体の技術精度は非常に高く、適切な環境で使えばフロントエンド開発の生産性と品質を大きく向上させるツールだと感じています。しかし同時に、受け入れ側の準備（デザインシステムやコーディング規約の整備）ができていないと真価を発揮しづらい点も浮き彫りになりました。

生成AIは万能の“銀の弾丸”ではなく、日頃から技術負債の解消や基盤整備に投資している企業ほど大きな恩恵を受けやすく、その結果、AI活用による効果の差が企業間でさらに拡大する可能性があります。しかし、この格差を縮める鍵は「継続的な設計・整備の積み重ね」にあると考えています。私たちもLocofy導入を機に、デザインと開発のプロセスを見直し、人手を創造的な作業に集中させ、機械に単純作業を任せる体制を整備しなければならないことを痛感しました。

今後もツールの進化を注視しながら、デザインとコードの連携をさらに最適化していきたいと思います。