Figma MCPで実装の工程を変えたら、見積もりはどう直すか──コーディングを半額にせず、データの整備とレビューを行に足す計算例
この記事は、Figma MCPなどでデザインから実装への工程を変えたときに、見積もりの行と工数をどう直すかを扱います。
「Figmaからコードが出るなら、コーディング代は要らないですよね」
デザインのデータをAIのコーディングツールに読ませ、実装の下書きを作る。そうした使い方が、制作の現場に入ってきました。
けれど、工程を変えてみると、減る作業と、新しく増える作業があります。
見積もりは、その両方を行に出してから直す必要があります。
Figma MCPを使った見積もりの直し方とは、実装の行を減らす前に、「デザインデータの整備」と「生成コードのレビュー」を独立した行として足し、差し引きで工数を出し直すことである
黒字化の外科医です。デザインから実装への工程が変わったときの見積もりを解剖します。
差し引きで直すべき理由は、三つあります。
第一に、生成の精度は、デザインデータの作り方に左右されるから。
部品と変数（色や余白の値）が整理されたデータと、ばらばらに描かれたデータでは、手直しの量が違います。
第二に、生成されたコードは、そのまま納品できるとは限らないから。
既存のコードの規約、共通部品、表示の崩れ。人が確かめる時間は残ります。
第三に、ツールの席と、使える回数に条件があるから。
席の種類で、使える機能と回数が変わります。
Figma MCPで何ができるか：公式で確かめた範囲
ここに書く機能は、2026年10月25日に、Figmaと各ツールの公式のヘルプ・開発者向けドキュメントで確かめたものです。機能や条件は変わることがあるため、使う前に必ず公式で確かめてください。
【Figma MCPサーバー】（確認日：2026年10月25日、Figma公式ヘルプ・開発者向けドキュメント）
・AIエージェントに、デザインの情報（変数、コンポーネント、レイアウト）を渡し、
選択したフレームからコードを作る使い方が案内されている
・リモート版とデスクトップ版があり、公式はリモート版を勧めている
・デスクトップ版は、Professional以上の対象プランで、DevまたはFullの席が必要とされている
・読み取りの道具として、get_design_context（デザインの情報とコード）、
get_variable_defs（変数とスタイル）、get_screenshot（画面写真）などがある
・利用回数には、プランと席ごとの上限がある（View・Collabの席は月20回まで）。
上限は変わることがあると明記されている
【Code Connect】（確認日：2026年10月25日、Figma公式ヘルプ）
・Figmaのコンポーネントと、コードの部品を結びつける機能
・Professional・Organization・Government・Enterpriseのプランで、FullまたはDevの席が必要とされている
【Claude CodeでのMCPの追加】（確認日：2026年10月25日、Claude Code公式ドキュメント）
・claude mcp add --transport http 〔名前〕〔URL〕 の形で、リモートのMCPサーバーを追加できる
・接続する前に、そのサーバーを信頼できるか確かめるよう警告があり、
外部の内容を読むサーバーにはプロンプトインジェクションの危険があると書かれている対応しているツール（Claude Code、Cursor、VS Codeなど）と、それぞれで使える機能は、Figmaの公式の一覧で確かめてください。
見積もりの行の直し方
従来の見積もりの「コーディング」の1行を、次の4行に分けます。
従来
・コーディング 〔 〕画面
直したあと
・デザインデータの整備（コンポーネントと変数の整理、実装に渡す範囲の決定）
・実装（生成と手直し）
・生成コードのレビュー（既存のコードの規約、共通部品、アクセシビリティ）
・表示と動作の確認（〔端末と画面幅を記載〕）顧客には金額の理由が見え、社内では、どの行が減り、どの行が増えたかを記録できます。
UIデザインの見積もり自体の積み方は、こちらで扱いました。
▶ UIデザイン受託の見積もりは「画面数×単価」では足りない──状態の数・共通部品・実装への引き渡しまで工数で積み、使いやすさと実装の責任の線を引く型
例：10画面の案件で、工数を出し直す（数字はすべて例）
【従来】
デザイン 80時間
コーディング 100時間
表示と動作の確認 20時間
修正対応 20時間
合計 220時間
【自社でデザインしたデータを使う場合】
デザイン 80時間
デザインデータの整備 16時間
実装（生成と手直し） 50時間
生成コードのレビュー 16時間
表示と動作の確認 20時間
修正対応 20時間
合計 202時間
【顧客から支給された、整理されていないデータを使う場合】
デザイン 80時間
デザインデータの整備 40時間
実装（生成と手直し） 50時間
生成コードのレビュー 16時間
表示と動作の確認 20時間
修正対応 20時間
合計 226時間検算：80 ＋ 100 ＋ 20 ＋ 20 ＝ 220時間。80 ＋ 16 ＋ 50 ＋ 16 ＋ 20 ＋ 20 ＝ 202時間。80 ＋ 40 ＋ 50 ＋ 16 ＋ 20 ＋ 20 ＝ 226時間。
コーディングの行は半減しても、全体では18時間（約8.2%）しか減らず、支給データが整理されていなければ、従来より6時間増えます。
検算：220 − 202 ＝ 18時間、18 ÷ 220 ≒ 8.2%。226 − 220 ＝ 6時間。
支給データの状態を、見積もりの前提に書く
【前提条件の文例】
・本見積もりは、ご支給のデザインデータが、共通部品（コンポーネント）と
色・文字・余白の値（変数）で整理されていることを前提としています。
・整理されていない場合は、データの整備を〔 〕時間（〔 〕円）で別途お見積りします。
・生成したコードは、当社の確認を経たうえで納品します。今すぐ試せる：デザインデータの状態から見積もりを直すプロンプト
私はWeb制作会社の経営者です。Figmaのデザインデータを使い、AIのコーディングツールで実装の下書きを作る前提で、見積もりを直したいです。
【前提】
・案件の画面数と、従来の見積もりの工程ごとの工数：〔記載〕
・デザインデータを作るのは自社か、顧客の支給か：〔記載〕
・データの状態（共通部品の使い方、変数の有無、画面ごとのばらつき）：〔記載〕
・使うツールと、関わる人の席の種類：〔記載〕
1. 「コーディング」の行を、デザインデータの整備・実装（生成と手直し）・生成コードのレビュー・表示と動作の確認に分ける。
2. 工程ごとの工数を、従来と新しい工程で比べる表を作る。
3. 支給データが整理されていない場合の工数を、別の案として出す。
4. 見積書の前提条件の文を作る。
ツールの機能や料金は推測で書かず、「公式で確認が必要」と書くこと。構造的なリスク
逆説を指摘しておきます。
工程を変えた最初の数件は、整備とレビューの時間が読めず、従来より時間がかかることがあります。
その数件で判断するのも、最初から見積もりを下げるのも、早すぎます。
もう一つ、顧客のFigmaファイルを外部のツールにつなぐことは、顧客の情報を扱うことです。どのツールに、どのファイルを読ませるかは、契約と顧客の同意の範囲で決めてください。
よくあるQ&A
Q. 席の費用は、見積もりに入れるべきか？
入れてください。デザインと開発に使う席の年額を、年間の案件数か工数で配り、案件の原価に足します。料金は、各社の公式の料金ページで確かめてください。
Q. 工程を変えたあとの粗利は、どう確かめるか？
整備・レビューの時間と席の費用を、役割別の時間単価で積んで計算します。計算の型は、こちらのシートにまとめました。
▶ AI駆動開発の粗利シミュレーションシート──工数・単価・ツール費・レビュー費を役割別に積み、値下げの上限、手戻りと従量課金の感度、請負と準委任の差まで計算する型
最後に
デザインから実装への工程が変わっても、減るのは実装の一部で、整備と確認の仕事は残ります。
コーディングの1行を分解し、デザインデータの整備とレビューを見積もりの行に出した会社だけが、新しい工程の速さを、値引きではなく利益として残せるのです。
これまでの記事は、メンバーシップ「黒字化オペ室」でまとめて読めます。月額1,980円、記事2本分の金額です。詳しくはプロフィールから。
#Web制作会社 #FigmaMCP #Figma #MCP #見積もり #AI駆動開発 #制作会社経営 #中小企業 #デザイン実装 #ClaudeCode
