実務・技術解説
Figmaのデザインをコード化する最適解は?「Locofy vs v0 vs エンジニア依頼」徹底比較
Figmaのデザインはあるけれど、どうやって動くコードにするか?自動変換ツールのLocofy、生成AIのv0、そしてプロのエンジニアへの依頼。それぞれのメリット・デメリットを比較します。
Figmaで丁寧に作ったデザインがある。コンポーネントも整理されている。でもこれをどうやって動くWebアプリにするか、という段階で詰まる人は多い。
「Figma to Code」を実現する主要な手段は3つ——Locofy/Builder.ioなどの自動変換プラグイン、v0などの生成AI、そしてエンジニアへの実装依頼だ。それぞれに向いているケースがあり、「どれが最強か」という問いに一律の答えはない。ただ、どれを選ぶかの判断軸は明確にできる。
3つのアプローチを比較する
| 項目 | Locofy / Builder.io | v0 | エンジニア依頼 |
|---|---|---|---|
| 向いているケース | Figmaが完璧に整備されている | スケッチからコンポーネント生成 | 本番運用する実装 |
| デザイン再現度 | 高い(条件付き) | 中程度 | 高い |
| ロジック実装 | 不可 | 部分的に可能 | 完全対応 |
| コスト | 月$49〜$149 | 月$20〜 | 1画面3〜8万円 |
| 速度 | 即時(Figma整備済みなら) | 数分〜数時間 | 数日〜数週間 |
| 保守性 | 低い(崩れやすい) | 低〜中 | 高い |
| 制約 | Figmaの品質に依存する | ピクセルパーフェクトは困難 | なし |
Locofy / Builder.ioの実態
Locofyは「FigmaのデザインをそのままReactコードに変換する」という触れ込みのプラグインだ。仕組みとしては、Figmaのレイヤー構造とAuto Layoutの設定を読み取り、対応するHTMLとCSSを生成する。
うまくいく条件が厳しい。 Auto Layoutが完璧に適用されており、コンポーネントが再利用可能な形で整理されており、レイヤー名が意味のある命名になっている——これらが揃っていれば、再現度の高いコードが出る。
問題は、ほとんどのFigmaファイルがこの条件を満たしていないことだ。 デザイナーが見た目を優先して作ったFigmaは、Auto Layoutが部分的だったり、絶対配置が混在していたりする。そういったFigmaをLocofyに通すと、崩れたコードが大量に出力される。修正にかかる時間が、一から書くより長くなることもある。
また、Locofyが生成するのはあくまでUI構造だ。ボタンを押したら何が起きるか、フォームのデータをどこに送るか、といったロジックは一切生成されない。静的なHTMLとしては使えても、動くアプリにはならない。
向いているのは: 静的なランディングページ、デザインシステムのHTMLプロトタイプ生成、Figmaが完璧に整備されたプロジェクト。
v0の実態
Vercelが提供するv0は、スクリーンショットやテキスト説明からReactコンポーネントを生成するAIツールだ。Locofyとは根本的に発想が違う。Locofyがデザインの「変換」なら、v0はデザインの「解釈と再生成」だ。
v0の強みはラフなインプットから動くコードを作れることだ。Figmaのスクリーンショットを貼り付けて「これと同じ感じでReactコンポーネントを作って」と指示すれば、数分でShadcn/UIを使ったコンポーネントが出てくる。ピクセルパーフェクトではないが、構造は合っている。Tailwind CSSで書かれており、カスタマイズもしやすい。
弱点はピクセル精度とコード品質だ。 v0が生成するコードにはTypeScriptの型定義が甘い箇所がある。アクセシビリティ属性(aria-labelなど)が欠落しがちだ。エラー状態やローディング状態のUIが未実装のままのことが多い。本番コードとしてそのまま使うのは避けた方が良い。
また、v0は対話形式で洗練させていく前提のツールだ。一発で完成品を期待するのではなく、「もう少しシンプルに」「このボタンをもっと目立たせて」と数回やり取りしながら調整する使い方が合っている。
向いているのは: コンポーネントのベースコード生成、デザインを見ながらのスケッチ実装、エンジニアが手直し前提で使う素材生成。
エンジニア依頼の実態
エンジニアへの実装依頼は、コストと時間がかかる代わりに品質と保守性が担保される。1画面3〜8万円というのは、シンプルなUIであれば3万円台、インタラクションが複雑だったりDB連携が必要だったりすると8万円以上になるという感覚だ。
本番運用を考えるなら、最終的にエンジニアが触る工程は避けられない。 v0やLocofyで生成したコードも、本番環境に乗せる前にエンジニアが型を付け、エラー処理を加え、テストを書く作業が必要になる。この作業を省略したコードは、後から必ず問題になる。
現実的なハイブリッドワークフロー
「どれか一つを選ぶ」より、組み合わせる方が合理的だ。実務で効果的なフローを具体的に説明する。
Step 1:Figmaのセクションごとにスクリーンショットを撮り、v0に投げてReactコンポーネントを生成する。
ヘッダー、サイドバー、メインコンテンツ、フォームといったセクション単位で作業する。1画面を一気に変換しようとするより、コンポーネント単位の方がv0の精度が高い。
Step 2:生成されたコードをエンジニアが整形し、TypeScript型を付け、エラー状態を追加する。
v0の出力をそのまま使うのではなく、素材として扱う。エンジニアが手直しする前提で使えば、一から書くより30〜50%の時間短縮になる。
Step 3:DB連携とビジネスロジックをエンジニアが実装する。
Supabaseのクエリ、フォームのバリデーション、APIコールの処理はエンジニアが担当する。v0は「見た目」まで、ロジックは人間が書く、という分業が機能する。
このフローだと、全部エンジニアに依頼するより30〜40%のコスト削減になりつつ、自動変換ツールだけに頼るより品質が高い成果物が得られる。
どれを選ぶかの判断
| 状況 | 推奨するアプローチ |
|---|---|
| ランディングページ・静的サイト | Locofy(Figmaが整備済みなら) |
| コンポーネントのたたき台が欲しい | v0 |
| 本番運用するWebアプリ | エンジニア依頼(v0を素材として活用) |
| Figmaが完璧でない | v0 > Locofy |
| 予算が限られている・スピード優先 | v0でベース生成 → エンジニアが整形 |
コストだけで判断すると後悔する。Locofyで自動変換したコードの修正に3日かけるなら、最初からエンジニアに頼んだ方が速かった、という事例は珍しくない。「どのツールを使うか」より「どの工程に人間を入れるか」を先に決めることが、Figma to Codeの現実的な最適解だ。