Figmaから本番公開まで：必要な工程と見積もりが増えるポイント

「Figmaが完成した」という状態は、デザインが整ったということだ。本番公開できるということではない。この違いを正確に把握していないと、開発の見積もりで想定外のコストが発生する。

家の間取り図が完成しても、実際に住める状態にするには電気・水道・壁の工事が必要だ。Figmaはその「見取り図」でしかない。外観はわかる。動線もわかる。しかし実際に動くソフトウェアにするには、Figmaに描かれていない大量の工程が残っている。

Figma公式のDev Modeは、デザインの検査・CSSスニペットの取得・アセットのエクスポートを効率化する。しかしこれは「見た目のスタイル層」に留まる。海外の開発者コミュニティでも明言されている通り、「Dev Mode is a great assistant, but not a complete solution（Dev Modeは優秀なアシスタントだが、完全なソリューションではない）」。本番稼働するコードを書く作業のうち、Figmaが代替できる部分はごく一部だ。

Figmaから本番公開まで「実際に何が発生するか」

エンジニアがFigmaを受け取ってから本番公開までに実行する工程は以下の6段階だ。それぞれの内容を理解しておくと、見積もりの内訳が腑に落ちる。

1. コードのレビューとクリーニング

Figma Dev Modeが出力するCSSや構造コードは、そのまま本番環境に使えない。命名規則が統一されていない、不要なネストが深い、再利用性を考慮していないなど、品質上の問題が多く残る。エンジニアはこれを一から整理し、保守・拡張できる構造に書き直す。

2. インタラクティブ機能の実装

フォームバリデーション（メールアドレス形式チェック、必須項目判定）、ボタンの活性/非活性制御、ローディング状態の表示、エラーメッセージの出し分けといった動的な挙動はすべてJavaScriptで実装する。Figmaに「送信ボタン」が描かれていても、押したときに何が起きるかはコードで書く必要がある。ショッピングカートのような状態管理が複雑な機能は、特に工数が膨らみやすい。

3. バックエンドとの連携

ユーザー認証（ログイン・ログアウト・セッション管理）、データの保存と取得（API接続）、権限に応じた表示制御など、バックエンドとのやり取りはFigmaには一切描かれていない。Figmaが「フロント」とすれば、バックエンドはまったく別の設計と実装が必要な領域だ。多くのプロジェクトでは、このバックエンド部分が開発コストの中心を占める。

4. レスポンシブ対応

Figmaでデスクトップ版を作っても、モバイル対応のコードはFigmaが書いてくれない。「Figmaはデザインの複数画面サイズへの適応コードを生成しない」という制約は、業界標準の認識だ。スマートフォン・タブレット・デスクトップの各ブレークポイントに対応するCSSとレイアウトロジックを、エンジニアが手で実装する。

5. パフォーマンス最適化

画像の圧縮とWebP変換、遅延読み込み（Lazy Load）の実装、不要なJavaScriptバンドルの削減、Core Web Vitalsの改善といった作業は、Figmaには存在しない工程だ。本番環境でユーザーが実際に使う速度を担保するために必要で、特にモバイル回線での動作に直結する。

6. アクセシビリティ・ブラウザ互換性のテスト

スクリーンリーダー対応、キーボード操作の担保、コントラスト比の確認、Chrome・Safari・Firefox・Edge間での表示差異の解消。これらは本番公開前に必ず必要なQA工程だ。Figmaのデザインがどれだけ美しくても、この工程を省いたコードは本番に出せない。

詳細は本番公開の最後の30%で解説している。

見積もりが増える3つの要因

同じFigmaデザインを受け取っても、見積もりが2倍・3倍になることがある。原因は主に以下の3つだ。

要因1：権限の種類数

「管理者」「一般ユーザー」「閲覧のみ」の3種類があれば、画面の表示ロジックは実質3倍になる。管理者には削除ボタンが表示され、一般ユーザーには表示されず、閲覧ユーザーには編集系のUIがすべて非表示になる。この分岐をフロントエンド・バックエンド両方で実装するコストは、権限の種類が増えるほど線形ではなく指数的に膨らむ。

要因2：画面の状態数

Figmaには「正常に表示された状態」が描かれることが多い。しかし実装では以下の状態をすべてカバーしなければならない。

• データが0件のとき（空の状態）
• データ取得中のとき（ローディング）
• エラーが発生したとき（エラー状態）
• 権限がないとき（403エラー画面）
• セッションが切れたとき（再ログイン誘導）

Figmaに1画面しか描かれていなくても、実装では5〜6パターンのUIを書く必要がある。この「Figmaに描かれていない状態」が見積もりの盲点になる。

要因3：外部API連携

Stripe（決済）・LINE（メッセージ）・Slack（通知）・Google Analytics（計測）など、外部サービスとの連携は1件あたり+2〜4週間の工数が発生する目安だ。サンドボックス環境でのテスト、本番APIキーの取得と設定、エラーハンドリング、Webhookの受け口実装など、連携1件あたりの作業量は想定より大きい。

見積もりがブレる理由の詳細は見積もりがブレる理由を参照。

費用の目安（Figmaあり前提）

Figmaデザインが完成している前提での開発費の相場は以下の通りだ。Figmaがない場合と比較して20〜30%削減できるケースが多いが、バックエンドの複雑さによって変動幅が大きい。

Bolt.new・LovableなどのVibe codingツールで動くプロトタイプがすでにある場合は、さらに削減できる可能性がある。プロトのコードをベースにリファクタリングと本番化を進める形が取れるため、ゼロからの実装より工数を圧縮しやすい。

なお、上記の金額はフロントエンド・バックエンド・インフラ設定を含んだ概算だ。非機能要件（セキュリティ、ログ基盤、監視設定）の範囲によって上下する。詳細は非機能要件の最小セットで確認できる。

また、2週間で本番公開できる条件も合わせて読むと、スコープの絞り方が具体的にわかる。

Figmaの段階で決めると安くなること

開発を発注する前にFigmaの中で決めておくと、見積もりの精度が上がり、結果として工数削減につながる項目がある。

例外時の画面をFigmaに追加する

「データが0件のとき」「エラーが発生したとき」「ローディング中」の3パターンを最低限Figmaに描いておく。エンジニアが独自判断で実装するより、デザイナーが意図した見た目に揃えられるため、手戻りが減る。

ロールごとの画面差分を明示する

「管理者には削除ボタンあり、一般ユーザーにはなし」といった差分をFigmaのコメントまたは別フレームで明示する。口頭の説明だけでは漏れが生じやすく、実装後に「この画面も権限分岐が必要でした」という追加対応が発生する。

バリデーションのルールをコメントで書く

メールアドレス形式必須、パスワードは8文字以上、電話番号はハイフンなしなど、入力規則をFigmaのコメント機能で記載する。エンジニアが仕様を推測する時間がなくなり、実装の精度も上がる。

外部API連携の仕様書を先に準備する

Stripe・LINEなど外部サービスを使う場合、サンドボックス環境へのアクセス権・APIキー・連携仕様書を発注前に準備する。これがないと、エンジニアが仕様確認・アカウント取得待ちで止まる。

よくある誤解と現実

誤解：「Figmaが完成していれば費用が固定される」

実際は権限の種類数・外部API連携数・非機能要件の範囲で費用は大きく変動する。Figmaはフロントの見た目だけを表現するものであり、バックエンドの複雑さはFigmaに描かれない。Figmaが完成していることは「見積もりの上限が下がる」ことを意味しても、「費用が固定される」ことを意味しない。

誤解：「Vibe codingツールでFigmaを再現できれば本番化できる」

Bolt.new・LovableはFigmaに近いUIを短時間で生成できる。しかしUIの見た目が再現できることと、本番に出せるコードであることは別の話だ。認証・権限管理・エラーハンドリング・セキュリティ対策・パフォーマンス最適化など、本番品質に必要な要素の多くはVibe codingツールのデフォルト出力には含まれていない。

誤解：「デザイナーにFigmaを作ってもらえばエンジニアへの発注が楽になる」

これはある程度正しい。フロントエンドの実装起点が明確になり、デザインと実装の認識齟齬が減る。しかしバックエンドの複雑さはFigmaに反映されない。権限設計・データモデル・外部連携の仕様はFigmaとは別に詰める必要がある。Figmaがあることでフロントの工数は削減できるが、全体の費用がそれに比例して下がるわけではない。

よくある質問

Figmaがない場合と比べてどのくらい安くなりますか？

フロントエンドの実装工数が20〜30%削減できるケースが多い。ただしバックエンド・インフラ・テストの工数はFigmaの有無に関わらず発生するため、プロジェクト全体では10〜20%削減が現実的な目安だ。バックエンドが複雑なSaaSでは削減効果が相対的に小さくなる。

Vibe codingツールで作ったプロトはFigmaと同じ扱いですか？

むしろFigmaより有利なケースが多い。Bolt.new・Lovableで作った動くプロトタイプがあれば、UIの実装起点だけでなく、画面遷移・インタラクションの意図も具体的に伝わる。コードをベースに本番化を進めることもできるため、ゼロスタートよりも工数を圧縮しやすい。

Figmaのデザインが古い（1年前）でも使えますか？

使えるが、現状との差分確認が必要だ。1年前のデザインは、その後の要件変更・追加機能・UIの方向性変更が反映されていないことがある。発注前にデザインと現在の要件を突き合わせ、差分を整理してから渡す方が手戻りを防げる。古いFigmaをそのまま渡して「あとはよろしく」とすると、仕様の確認コストがかえって増える。

費用の見積もりはどう出しますか？

まず費用見積もりツールで概算を出し、その後に詳細な要件ヒアリングを経て確定見積もりを提示する流れが標準だ。ツールで出た数字は目安であり、権限の種類・外部API連携数・非機能要件の範囲によって上下する。概算と確定見積もりの差が大きい場合は、スコープの絞り方を一緒に検討する。