UI/UXデザインの見積もりの作り方｜あとで足せない項目

2026年6月28日

丸山桃子

この記事のポイント

✓UI/UXデザインの見積もりの出し方を
✓工程の分解から前提条件の書き方まで解説
✓デザインシステム整備など

UI/UXデザインの見積もりの出し方で本当に難しいのは、金額をいくらにするかではありません。見積書に「書き忘れた作業」が、着手後にほぼ確実に発生し、しかもその時点では追加請求を切り出しにくくなる、という構造のほうです。デザインは形が見えるまで発注者と受注者の頭のなかがズレたままになりやすく、ズレが表面化するのはたいてい中盤以降です。この記事では、見積書を作る前に確定させる前提、工程ごとに立てるべき項目、そして「あとで足せない項目」の具体例を、受注後の実務の順番どおりに整理します。

デザイン費の相場情報を集めるより先に、自分の見積書が何を含み何を含まないかを言語化できているか。ここが曖昧なままだと、どんな金額を提示しても不利になります。

見積もりが「あとで足せない」構造になる理由

制作物の見積もりには、ソフトウェア開発と同じ厄介さがあります。作り始めてからでないと本当の作業量が分からないのに、作り始める前に金額を確定させなければならない。この非対称を、発注側と受注側のどちらが引き受けるかを決めるのが見積書です。

途中で気づく作業は「当然含まれている」と読まれる

たとえば画面デザインを進めていて、エラー時の表示や、データが1件もないときの表示が定義されていないことに気づいたとします。これは追加作業ですが、発注者から見れば「その画面をデザインすると言ったのだから、エラーの見た目も含まれているはず」という認識になります。受注者が後から「エラー画面は別途です」と言い出すと、値段の話ではなく誠実さの話にすり替わってしまう。金額の妥当性ではなく、信頼の問題として処理されるところが厄介です。

だから追加請求できるかどうかは、作業量の大小ではなく、見積書の時点でその項目が「見えていたか」で決まります。書いてあれば交渉になり、書いていなければサービスになる。この非対称を前提に項目を立てるのが、UI/UXデザインの見積もりの出し方の芯です。

費用は「範囲」と「発注先」で動く

デザイン費の水準そのものは、作業の難易度よりも、どこまでを任せるかで動きます。調査から任せるのか、要件が固まった状態から画面だけ作るのか。その線引きが違うと、同じ「UI/UXデザイン」という言葉でも中身がまったく変わります。

UI/UXデザインの費用は、依頼する業務の範囲・規模・発注先の種類によって大きく変動します。まずは全体的な相場感とコスト構造を把握することが、予算計画の第一歩となります。出典: ripla.co.jp

発注者側もここで迷っています。だから見積書が「範囲の定義書」として読めるようになっていると、それだけで比較検討の土俵に乗りやすくなります。金額の欄より、前提条件の欄を先に読む発注担当者は珍しくありません。

発注側は「読み解けない」と感じている

発注担当者が見積書を前にして何に困っているかを知っておくと、書き方が変わります。

UI/UXデザインへの投資を検討しているものの、「一体いくらかかるのか」「見積もりをどう読み解けばよいのか」と悩んでいる方は多いはずです。費用感を把握せずに発注してしまうと、予算オーバーや品質不足といったトラブルに直結します。出典: ripla.co.jp

つまり相手は、値段の高い安いを判断したいのではなく、この金額で何が手に入るのかを知りたい。ここに答える見積書は、それだけで比較優位に立ちます。

見積書を作る前に確定させる4つの前提

見積もりの精度は、書式ではなくヒアリングで決まります。次の4つが埋まっていない状態で金額を出すと、ほぼ確実に後から揉めます。

対象範囲と成果物の形式

何を納品したら完了なのかを、モノの名前で確定させます。画面デザインのFigmaファイルなのか、実装可能なコンポーネント一式なのか、画面遷移をつないだ操作可能なプロトタイプなのか。同じ「デザイン一式」でも、この3つは工数が段違いです。

成果物の形式には、編集権限の扱いも含みます。Figmaのファイルそのものを渡すのか、閲覧権限だけ渡すのか。ファイルを渡すなら、レイヤー名やコンポーネント名の整理も納品物の品質に含まれるため、そのぶんの作業を見込む必要があります。この整理は地味に時間を食う作業で、見積もりから抜け落ちやすい代表格です。

誰が決めるのか（意思決定者と承認の回数）

デザインの作業量を最も左右するのは、実は難易度ではなく承認プロセスです。担当者が単独で決められる案件と、担当者の上に部長がいて、その上に役員がいて、さらに現場部門のレビューが入る案件では、同じ画面数でも修正の往復が何倍にもなります。

最初の打ち合わせで「今回、最終的に決めるのはどなたですか」「途中で見ていただく方は他にいますか」を聞いておきます。ここで挙がった人数が多いほど、修正回数の上限を明示する必要が高まります。関係者が多い案件で修正無制限の見積もりを出すのは、赤字への最短ルートです。

素材は誰が用意するのか

写真、イラスト、アイコン、そして文章。UIの見た目を決めるのはレイアウトだけではなく、そこに入る中身です。ダミーテキストのまま進めたデザインが、実際の文章を流し込んだ瞬間に崩れるのは日常茶飯事です。

素材の担当を決めるときは、次の3つを分けて確認します。用意する人、選ぶ人、そして権利を確認する人。ストックフォトの購入費用を誰が負担するのか、有料フォントのライセンスをどちらの名義で取るのか。この確認を飛ばすと、納品直前に「このフォントは商用利用の契約が要る」と発覚して、費用と時間の両方を持ち出しで払うことになります。

開発チームとの接続点

デザインが実装されるまでが1つの流れである以上、開発側との接続をどこまで担当するかを決めておきます。デザインデータを渡して終わりなのか、実装後の画面を見て差分を指摘するところまでやるのか、開発の定例に参加して質問に答え続けるのか。

とくに最後の「質問に答え続ける」は、時間が読めないわりに見積書に立てにくい項目です。開発期間が3ヶ月あれば、その間ずっと断続的に問い合わせが来ます。時間単位の対応枠として別立てにするか、月額の伴走枠として切り出すのが実務的です。UI/UXの仕事の広がりを整理したい場合は、UI/UX・アプリデザインのお仕事で、どの工程までが依頼対象になりやすいかを俯瞰しておくと、見積書の項目立てを考えるときの土台になります。

工程ごとに立てる見積もり項目

ここからは、見積書に実際に並べる項目です。工程で分けると、発注者が「どこを削れば予算に収まるか」を自分で判断できるようになり、値引き交渉が「範囲の調整」に変わります。これは受注側にとっても有利です。

調査と現状分析

競合サービスの調査、既存画面の課題洗い出し、アクセスデータの確認、ユーザーインタビュー。ここは削られやすい工程ですが、削ると後工程で「なぜこのデザインなのか」を説明できなくなり、結果として修正が増えます。

見積書には、調査の手法と回数を数えられる形で書きます。競合何社を見るのか、インタビューを何人にするのか、既存画面を何本分析するのか。数えられる形にしておくと、追加が発生したときに単純な足し算で説明できます。

要件整理と情報設計

調査の結果を、画面一覧と遷移図に落とす工程です。ここで作る画面一覧が、以降のすべての見積もりの土台になります。逆に言えば、画面一覧が固まる前に画面単価で見積もると、必ず外します。

実務では、この工程だけを先に小さく受注し、画面一覧を確定させてから本体の見積もりを出す進め方があります。発注者にとっても、金額の根拠がはっきりした状態で予算を通せるので通りやすい。いきなり全体の金額を出すのが難しい案件では、この二段構えが有効です。

UIデザインとコンポーネント整備

画面を実際に作る工程です。ここで見積もりを外す最大の原因は、画面の数え方にあります。詳しくは次の章で扱いますが、少なくとも「1画面」の定義を見積書に書いておく必要があります。

コンポーネント整備は、ボタンやフォームなどの部品を再利用可能な形にそろえる作業です。画面を作るついでに終わる規模ではなく、独立した工程として見込みます。部品を整えておくと後半の画面制作が速くなるため、総量では得になることが多いのですが、前半に負荷が寄る形になります。

プロトタイプと検証

画面をつないで操作できる状態にし、想定ユーザーに触ってもらう工程です。プロトタイプは「作る」だけでなく「直す」までがセットで、検証の結果を反映する時間を見ておかないと、検証したのに直せないという最悪の形になります。

検証を見積書に入れるときは、実施回数と、その結果を反映する修正の範囲をセットで書きます。検証で大きな方針変更が出た場合は別途協議とする一文も添えておきます。

開発への引き渡しと実装確認

デザインデータの整理、寸法や余白の仕様の明示、状態変化の説明。そして実装された画面とデザインの差分確認です。この工程は成果物が目に見えにくいため、見積書に書かないと存在しないものとして扱われます。

差分確認は回数で区切ります。実装後に2回まで確認して指摘する、3回目以降は別途、といった形です。開発側の完成度によって作業量が大きく変わるため、無制限にすると際限がありません。

あとで足せない項目の具体例

ここが本題です。着手後に発生するのに、着手後には請求しにくい項目を並べます。見積書の時点で行を立てるか、少なくとも前提条件として書いておくべきものです。

画面数の数え方

「1画面」が何を指すかを定義しないまま画面単価で見積もると、実作業は見積もりの何倍にもなります。1つの画面には、通常の表示だけでなく、読み込み中、データが空、入力エラー、通信失敗、権限なし、といった状態があります。さらにスマートフォンとパソコンで別のレイアウトが要るなら、その分だけ増えます。

見積書には「1画面とは、基本表示1パターンを指す。状態違い、画面幅違いは別カウントとする」と書きます。そのうえで、主要画面については状態違いを最初から見積もりに含めておくと、発注者にとっても実態に近い金額が見えて誠実です。この定義を書いておくだけで、後半の「これも入っていますよね」という会話がなくなります。

修正の回数と、修正の定義

修正回数の上限を書くのは、もはや標準です。ただし回数だけ書いても効きません。何を1回と数えるかを書かないと、細かい指摘が何度も送られてきて、そのたびに「これは1回に含まれますか」というやり取りが発生します。

実務的な書き方は、修正を「1回のフィードバックとしてまとめて受け取ったもの」と定義し、フィードバックの受け取り回数で数える形です。あわせて、方向性そのものを変える指示は修正ではなく再制作として扱う旨を書きます。色や文言の調整と、レイアウトを白紙に戻す指示では、作業量が桁違いだからです。

デザインシステムの整備

「今後も使えるように、ルールをまとめておいてほしい」という依頼は、たいてい後から来ます。色、余白、文字サイズ、部品の使い分け、命名規則。これを他人が使える形にドキュメント化する作業は、画面を作るのとは別のスキルと時間が必要です。

見積もりの段階で、デザインシステムの整備を含むか含まないかを明示します。含まないなら、除外事項の欄に「デザインガイドラインの文書化は含まない」と一行入れておく。この一行があるかどうかで、後から相談されたときに別見積もりを出せるかが変わります。

素材の調達と加工

写真の選定、切り抜き、色調整、アイコンの作成。素材を発注者が用意する前提の見積もりでも、実際には「いい写真がないので探してもらえませんか」という相談が来ます。

ここは「素材の選定は貴社にてお願いします。当方で選定・加工が必要な場合は別途お見積もりします」と書いておくのが穏当です。断るためではなく、相談されたときに気持ちよく引き受けて対価を得るために書きます。

実装立ち会いとQA

実装が始まってからの質問対応、実機での見え方の確認、リリース前のチェック。この期間は自分の作業がなくても拘束されます。

拘束される時間は、時間単位や月単位の枠として見積もるのが実務的です。「開発期間中の質問対応は、月4時間まで含む」といった書き方であれば、発注者にも予算が読めます。

中断と再開のコスト

発注者側の都合でプロジェクトが止まることは、珍しくありません。担当者の異動、予算の再検討、優先順位の変更。止まった期間が長いと、再開時に文脈を思い出す時間が必要になり、その間こちらのスケジュールも埋められません。

見積書に「1ヶ月を超える中断が発生した場合、再開時の条件を再協議する」と書いておきます。実際に請求するかどうかは別として、この一文があると、発注者側も止めないよう社内を動かしてくれます。

権利の扱い

著作権の譲渡、二次利用の範囲、制作物の実績公開の可否。これらは金額に直結します。著作権をすべて譲渡し、実績としての公開も不可とするなら、その条件込みの金額になります。

とくに実績公開の可否は、受注後に「言い出しにくくなる」項目の筆頭です。契約書を交わす前に確認し、公開できない場合は代わりに何ができるかも決めておきます。実績の見せ方は次の仕事の獲得に直結するため、金額と同じ重みで扱う価値があります。フリーランスとして継続的に案件を得る前提条件については、UI/UXデザインのフリーランスになるには？必要スキルと案件相場で、必要なスキルと案件の獲得経路が整理されています。

見積書そのものの書き方

項目が決まったら、次は書式です。読み手は多くの場合、デザインの専門家ではありません。

前提条件を先頭に置く

金額の表より前に、前提条件を置きます。想定画面数、修正回数、素材の担当、期間、意思決定者の人数。この5つが冒頭にあると、読み手は金額を「条件つきの数字」として理解します。条件が変われば金額も変わることが自然に伝わるため、後の交渉が楽になります。

除外事項を明記する

含まないものを書くのは、けちに見えるのではないかと躊躇する人がいますが、逆です。除外事項が具体的に書かれた見積書は、書いた側が実務を分かっている証拠として読まれます。曖昧な見積書のほうが不安を与えます。

除外事項には、前章で挙げた項目を並べます。デザインシステムの文書化、素材の調達、実装、テキストのライティング、多言語対応、既存デザインの修正。案件ごとに要らない行は消します。

有効期限と支払い条件

見積書には有効期限を入れます。発注者側の検討が長引いた結果、半年後に「あの見積もりでお願いします」と言われても、こちらの状況は変わっています。

支払い条件は、着手時と納品時に分けるのが一般的です。期間が長い案件では、月ごとの精算にする方法もあります。契約と支払いをめぐる基本的なルールは、人間中心設計(HCD)専門家資格でUXデザインのフリーランス案件を獲得でも、専門性の裏づけを持って条件交渉に臨む観点から触れられています。

相見積もりで比較されるときの見え方

発注者は複数社から見積もりを取ります。そのとき、金額だけが並べられた表に落とし込まれることを想定しておきます。

比較される前提なら、総額の隣に「この金額に含まれるもの」を短く書いた行を用意しておくと有利です。単純な安さで負けても、範囲の違いで説明できる形になっていれば、担当者は社内でその差を説明できます。逆に、範囲が書かれていない見積書は、安いほうに流れます。

見積もりでよくある失敗と、その手当て

現場で繰り返し見かける失敗を、原因と手当てのセットで挙げます。

相手の予算を聞かずに出す

予算を聞くのは失礼だという感覚を持つ人がいますが、実務では逆です。予算が分かれば、その範囲で何ができるかを提案でき、双方の時間が節約できます。聞き方は「概算で構いませんので、今回はどのくらいの規模でお考えですか」で十分です。

答えが返ってこない場合は、範囲の異なる2案を出します。最小限の範囲の案と、調査と検証を含む案。金額の幅を見せることで、発注者は自分の予算感を口に出しやすくなります。

工数を積み上げただけで出す

自分の作業時間に単価を掛けただけの見積もりは、削られたときに何を削ればいいか分からなくなります。工程ごとに分解し、削れる工程と削れない工程を自分の中で決めておきます。

削れないのは、要件整理と画面一覧の確定です。ここを削ると、あとの全部が不安定になります。削れるのは、調査の深さ、検証の回数、対応する画面幅の種類です。

速さを売りにしてしまう

短納期を売りにすると、その納期が次回以降の基準になります。しかも短納期で通した案件は、修正の時間も圧縮されるため品質が落ちやすい。結果として、安くて速いが雑という評価がつきます。

納期は、確認と修正の時間を含めて提示します。発注者にとっても、確認の時間が確保された進行のほうが安心です。

保守と運用の話をしない

デザインは納品して終わりではありません。運用が始まれば、画面の追加、季節ごとの差し替え、機能追加に伴う修正が発生します。この話を見積もりの段階でしておくと、単発が継続に変わります。

見積書の末尾に「納品後の運用支援について」という項目を、金額なしで一行入れておくだけでも効果があります。発注者側が予算を組むときに、その行が思い出されます。

発注先の種類によって見積書の形が変わる

発注者は、制作会社、個人のデザイナー、エージェント経由の3つを比較検討していることが多いです。自分がどの立ち位置で見られているかを知っておくと、見積書に書くべきことが変わります。

制作会社と比べられるとき

制作会社の見積書には、ディレクター、デザイナー、必要に応じてリサーチャーといった役割ごとの行が並びます。人数分の管理コストが乗るぶん総額は上がりますが、担当者が抜けても案件が止まらない体制が値段に含まれています。

個人で受ける場合、この「止まらない安心」を金額以外で埋める必要があります。進捗の共有方法、連絡が取れないときの代替手段、体調不良時の対応方針。こうした運用の約束を見積書の前提条件に書いておくと、体制面の不安が減ります。安さで勝負するより、この一手のほうが効きます。

個人に直接依頼されるとき

発注者が個人に直接頼む理由は、金額だけではありません。担当者と作り手のあいだに人が入らないため、意図が薄まらずに伝わることを期待しています。この期待に応えるなら、見積書にも中間の言い換えがない形で書きます。専門用語を並べず、何をして何を渡すかを日本語で書く。それだけで期待に沿った印象になります。

一方で、個人への直接依頼には発注者側の不安もあります。契約書の有無、請求書の形式、源泉徴収の扱い、そして情報の取り扱いです。見積書と一緒に、契約の型と秘密保持の考え方を短く添えておくと、社内の稟議が通りやすくなります。書類の不備で発注が止まるのは、双方にとって損です。

エージェント経由で紹介されるとき

エージェントを介する場合、見積書の宛先はエージェントになり、条件の一部は先に決まっています。稼働の形態が時間単位で決まっていることも多く、成果物単位の見積もりを出す余地が小さい。

このとき注意するのは、時間単位の契約に「時間で測れない作業」が紛れ込むことです。資料の読み込み、関係者との調整、実装後の確認。これらを稼働時間に含めるかどうかを最初に確認しておかないと、実質的な作業量が契約上の時間を超え続けます。

納品後に続くコストを先に書いておく

見積書は着手から納品までを対象に書かれますが、発注者が本当に知りたいのは、その後にいくらかかり続けるかです。ここに触れた見積書は、それだけで検討の土俵で有利になります。

ツールとライセンスの費用

デザインツールの利用料、有料フォント、購入した写真素材、プロトタイプの共有環境。これらは制作が終わっても、運用が続く限り関係し続けます。とくにフォントとストックフォトのライセンスは、契約の名義と有効期間を確認しておかないと、あとで使えなくなる形の事故が起きます。

見積書には、こちらが負担するものと、発注者名義で契約してもらうものを分けて書きます。ここを分けておくと、納品後に発注者が自分で更新できるようになり、余計な問い合わせが減ります。

更新と差し替えの発生頻度

サービスが動き出せば、画面は必ず変わります。文言の差し替え、キャンペーンのバナー、新機能の画面追加。これらを誰がやるのかを決めておかないと、納品直後から無償の小作業が連続する状態になります。

見積書の末尾に、運用時の作業を想定した枠を一行入れておきます。金額を書かなくても構いません。運用時にも作業が発生するという事実を、着手前に共有しておくことに意味があります。

引き継ぎができる状態にしておくこと

将来、別の担当者やチームがデザインを引き継ぐ場面は必ず来ます。そのとき参照される形にデータを整えておくかどうかで、発注者にとっての資産価値が変わります。

引き継ぎ可能な状態にするには、ファイルの構造、命名、ルールの記述が要ります。これは前述のデザインシステム整備と重なる作業で、含むか含まないかを明示すべき項目です。含む場合は堂々と行を立てて金額をつけ、含まない場合は除外事項に書く。どちらでもよいので、書かないという選択だけは避けます。

見積もりの型を作って使い回す

案件ごとに一から見積書を書いていると、時間がかかるうえに項目の抜けが起きます。型を持っておくと、精度と速度が同時に上がります。

過去案件の実績を数字で残す

見積もりの精度を上げる唯一の方法は、実際にかかった時間を記録することです。工程ごとに、予定と実績を並べて残します。何度か記録すると、自分がどの工程を過小に見積もる癖があるかが見えてきます。多くの人は、要件整理と修正対応を軽く見積もります。

記録は複雑にしません。工程名、予定時間、実績時間、ずれた理由。この4項目を案件ごとに残すだけで、次の見積もりの根拠になります。

説明の言い回しを用意しておく

見積書を送ったあとには、必ず質問が来ます。この項目は何ですか、ここはもう少し下げられませんか、この作業は本当に必要ですか。そのたびに考えて答えていると、返信が遅れ、相手の検討も止まります。

よく聞かれる項目については、あらかじめ2、3文の説明を用意しておきます。とくに、削ると後で高くつく工程については、削った場合に何が起きるかまで書けるようにしておく。これは値引きを断るためではなく、相手が社内で説明できる材料を渡すためです。

現場を長く見てきた立場からの観察

フリーランスと発注者の取引を20年見てきた立場から言えば、見積もりで揉める案件と揉めない案件を分けているのは、金額の高低ではありません。着手前にどれだけ言葉にしたか、その一点です。

揉めない人の見積書には、一見すると余計に見える文が並んでいます。何を1画面と数えるか、修正を何回と数えるか、素材は誰が用意するか。この余計に見える文が、着手後に相手を責めずに条件を再交渉するための足場になります。逆に、きれいで短い見積書ほど、後半で苦しくなる傾向があります。

もう一つ、長く続いている人ほど、見積書を「値段を伝える紙」ではなく「仕事の進め方を合意する紙」として使っています。金額の話しかしていない関係は、次に安いところが現れたら終わります。進め方まで合意している関係は、次の案件も同じ紙を土台に話が始まるので、二回目以降の見積もりが速くなり、双方の手間が減ります。

そしてもう一点。中間に手数料が乗らない直接の取引では、同じ予算で発注者はより多くを頼めて、受け手は手取りが厚くなります。手数料0%の意味は、額面が上がることではなく、同じ額面でも双方の余白が増えることです。余白があるぶん、検証や状態違いの画面といった「あとで足せない項目」を最初から見積もりに入れやすくなる。長く同じ相手と仕事をしている人ほど、この余白を品質に回しています。

職種としてのデザイナーが、どの領域でどのくらいの収入水準に位置づけられるかを把握しておくと、自分の見積もりが市場のどこにあるかを判断しやすくなります。分野ごとの整理はデザイナーの年収データ｜Web・UI/UX・グラフィック分野別【2026年版】にまとまっています。開発側の職種と比べたい場合はソフトウェア作成者の年収・単価相場も参考になります。UIデザインは開発と隣接する仕事であり、開発側の水準を知っておくと、実装確認や仕様調整といった越境作業の価値を説明しやすくなります。

見積もりの出し方に唯一の正解はありません。ただ、あとで足せない項目を先に書き出しておくという原則は、案件の規模を問わず効きます。次の見積書を書くときは、金額を決める前に、この記事の除外事項リストを一度なぞってみてください。

よくある質問

Q. UI/UXデザインの見積もりは、画面単価と工数単価のどちらで出すべきですか？

画面一覧が確定しているなら画面単価、確定していないなら工数単価が実務的です。画面一覧が固まる前に画面単価で出すと、状態違いや画面幅違いが後から増えて必ず外します。要件整理までを小さく受注して画面一覧を確定させ、そのうえで本体の見積もりを画面単価で出す二段構えなら、双方が納得しやすくなります。

Q. 修正回数の上限は見積書に書いても失礼になりませんか？

失礼にはなりません。むしろ回数が書かれていない見積書のほうが、発注者にとっては予算が読めず不安です。書くときは回数だけでなく、何を1回と数えるかを添えます。まとめて受け取ったフィードバックを1回と数える、方向性を変える指示は再制作として扱う、といった定義まで書くと、後のやり取りが減ります。

Q. 見積もりを出す前に、必ず聞いておくべきことは何ですか？

成果物の形式、最終的な意思決定者と関係者の人数、素材を用意する担当、開発チームとの接続点の4つです。とくに関係者の人数は作業量を最も左右します。承認する人が増えるほど修正の往復が増えるため、人数が多い案件では修正回数の上限を明示する必要が高まります。予算の概算も、聞ける場面なら早めに確認します。

Q. 着手後に追加作業が発生したとき、どう切り出せばよいですか？

見積書の前提条件と除外事項を根拠に、事実として伝えます。当初は基本表示のみを対象としていたが、エラー時と空データ時の表示が必要になった、という形です。相手を責める言い方ではなく、範囲が変わったので条件を再確認したい、という組み立てにします。この会話ができるかどうかは、見積書に定義が書いてあるかで決まります。