← ガイド一覧

UI/UXデザインのみ委託— 検収の切り分け

公開: 2026年9月2日

Web サービスやアプリの UI/UX デザインだけを外部に委託する場合、ワイヤーフレーム・ビジュアルデザイン・デザインシステムのどこまでを納品範囲とするかで、検収と支払のタイミングが大きく変わります。

開発実装は別ベンダー、デザインだけフリーランスという構成は中小企業でも珍しくありません。
一方で「デザインが好みじゃない」という主観と、契約上の検収拒否は別問題として整理しないと、支払遅延や減額トラブルにつながります。

本記事では、ワイヤーと完成デザインの検収切り分け、修正回数の上限、著作権・納品形式まで、発注側が押さえる実務ポイントを整理します。

トリカク(torikaku) は発注書面・受領日・支払期日を台帳で一元管理し、段階検収ごとの超過リスクを可視化します。

1. 成果物の段階と検収マイルストーン

1-1. ワイヤーフレーム段階の完了定義

情報設計・画面遷移・主要 UI 要素の配置が要件を満たしているかで検収するのが一般的です。
ビジュアルの完成度ではなく、機能要件との整合を基準にすると、後続のデザイン工程との境界が明確になります。
この段階で検収承認すると、ビジュアルデザインは次のマイルストーンとして別扱いになります。

1-2. モックアップとプロトタイプ

クリッカブルプロトタイプは、社内レビュー用かユーザーテスト用か、実装引き渡し用かで納品物の定義が変わります。
Figma プロジェクトの権限移譲日を受領日とする運用が多いですが、エクスポートデータの納品を求める場合は契約に明記します。
プロトタイプ段階で検収すると、実装向けの詳細仕様は別フェーズになります。

1-3. 完成デザインとスタイルガイド

実装に必要なコンポーネント一覧・デザイントークン・レスポンシブ各ブレークポイントまで含めるかを契約で固定します。
検収基準は検収基準の決め方の考え方で、チェックリスト形式にすると行き違いが減ります。
「見た目が整っている」だけではなく、実装者が迷わない粒度まで書面化しておきます。

2. 修正回数と方向性変更

2-1. 含まれる修正ラウンドの上限

デザイン委託は修正が続きやすいため、見積もりに含まれる修正回数を契約に明記します。
上限超過分は追加発注として扱う旨を事前に合意しておき、口頭で無制限に依頼しない運用にします。
修正回数と不当なやり直しの境界は契約条項と検収基準で先に決めておきます。

2-2. 方向性変更と微修正の違い

当初合意したコンセプトからの大幅変更は、修正ではなく新規発注に近い扱いです。
例えば BtoC 向けトーンから BtoB 向けに切り替える場合、見積もりと納期への影響を都度書面で合意します。
社内ステークホルダーの意見が割れるままデザイナーに渡すと、修正ラウンドが膨らみやすくなります。

2-3. 実装フィードバックの範囲

実装時の微調整がデザイン委託の範囲に含まれるかは境界が曖昧になりがちです。
実装支援を別契約に分けるか、月あたりの対応時間枠を設けるかを発注前に決めます。
実装ベンダーからの差し戻し対応までデザイナー負担にしないよう、責任分界を書面に残します。

3. 著作権・納品形式・素材利用

3-1. 帰属と利用許諾

納品デザインの著作権が発注者に移転するか、利用許諾にとどまるかを契約に明記します。
ストックフォト・アイコン素材のライセンス条件も納品物一覧に含め、商用利用可否を確認します。

3-2. ソースファイルの納品範囲

PNG 書き出しのみか、Figma や Sketch の編集可能データまで含むかで価格と検収が変わります。
フォントライセンスの扱いも、発注者名義で購入するか受託者持ち込みかを合意します。

3-3. ポートフォリオ掲載

受託者の実績掲載可否・匿名化の要否・公開タイミングも、書面で触れておくと後からの齟齬が減ります。
未公開サービスのデザインを掲載されるリスクがある場合は、リリース後まで禁止する条項も検討します。

4. 発注書面・段階払い・台帳

4-1. デザインのみ委託の記載事項

業務内容・報酬・支払期日・検収条件は発注書面の3条書面の型で整えます。
発注前の全体確認は発注コンプライアンスのチェックリストも参照してください。

4-2. 段階払いと受領日

ワイヤー承認時・ビジュアル承認時に分割払いする場合、各段階の受領日を台帳に個別記録します。
60 日起算の起点は支払60日ルールの起算点を参照し、段階ごとに期日を計算します。

4-3. 実装委託との連携

別ベンダーが実装する場合、デザイン引き渡し日と実装開始日の関係を両契約で明記します。
デザイン変更が実装遅延を招くときの責任分界も合意し、変更は追加発注として台帳に紐づけます。

5. 実務シナリオとチェックリスト

5-1. ワイヤー承認後に要件が変わったとき

例えばワイヤー検収後に、会員機能の画面数が倍増する依頼が口頭で入ったとします。
情報設計の変更は方向性変更として、追加見積もりと承認を取ってからデザイナーに再着手してもらいます。
承認なしに進んだ作業は、検収時に「当初スコープ外」と争点になるため、早めに書面化します。

5-2. 複数画面を別デザイナーに分けたとき

LP と管理画面を別契約にする場合、取引先・発注番号・受領日を台帳で分けて管理します。
一括で「デザイン費」として処理すると、どの給付の受領日か追えなくなり、支払期日の計算が止まります。

5-3. 発注前チェック(UI/UX 向け)

ワイヤー・モック・完成デザインの検収マイルストーン、修正回数上限、納品形式、著作権、実装連携を書面に含めるか確認します。
キックオフ議事録だけで終わらせず、合意内容が発注書面・別紙に反映されているか経理・法務でクロスチェックします。

よくある質問

Q. 気に入らないデザインを検収拒否できますか

契約上の検収基準を満たしているかで判断します。
主観的な好みだけでは拒否理由にならない場面があり、基準を事前に具体化しておくことが重要です。

Q. 1画面だけ別デザイナーに頼む場合

画面単位で発注書面・台帳を分け、受領日を個別管理します。
共通デザインシステムの適用範囲も、どちらの契約に含めるか書面で決めます。

Q. アクセシビリティ監査は含めますか

WCAG 準拠のレベル(AA 等)を契約に書き、監査結果や修正対応を検収資料に含めます。
監査のみ別委託にする場合も、デザイン側の修正責任範囲を切り分けます。

Q. ブランドガイドライン既存ありの場合

遵守すべきガイドを添付し、逸脱時の修正責任と追加費用の扱いを定めます。
ガイド未整備の状態で「雰囲気で」と依頼すると、修正が増えやすくなります。

Q. UX リサーチ・ペルソナ作成は別料金ですか

ユーザーリサーチがスコープに含まれるかは見積もり段階で切り分けます。
リサーチ成果物の検収基準も、デザイン成果物とは別マイルストーンとして定義します。

まとめ

  • ワイヤー・モック・完成デザインで検収マイルストーンを分け、受領日を段階ごとに記録する
  • 修正回数と方向性変更の扱いを契約に明記し、上限超過は追加発注とする
  • 著作権・納品形式・素材利用を書面で固定し、実装委託との責任分界を決める
  • 段階払いは各受領日から60日起算で支払期日を台帳管理する

6. UI/UXデザイン委託の発注前チェックリスト

  • ワイヤー・モック・完成デザインの検収マイルストーンを分けたか
  • 修正回数の上限と方向性変更の扱いを契約に書いたか
  • 納品形式(書き出しのみか編集可能データか)を固定したか
  • 著作権・利用範囲・ポートフォリオ掲載可否を合意したか
  • 実装委託との引き渡し日と責任分界を決めたか
  • 段階払いの各受領日を台帳に記録する運用があるか

「気に入らない」は検収拒否の理由にならない場面があります。契約上の検収基準を先に言語化してください。
社内レビューは合意した1本のフィードバックにまとめてから渡すと、修正ラウンドの超過を防げます。

注意

本記事は取適法・フリーランス新法に関する一般的な情報の整理であり、トリカク(torikaku) の機能説明を含みますが、法的助言ではありません。
個別の契約内容・取引実態については専門家にご確認ください。

トリカク(torikaku) で試す

適用判定・取引先台帳・明示事項チェック・60日ルールの期日管理・メール通知を一箇所にまとめられます。無料プランは稼働中の取引先1社・発注記録 月3件までです。停止中の取引先は枠を消費しません。形式チェック・記録管理・期日管理のみを行います。メール通知の遅延・未達は保証しません。法令・ガイドライン改正時は判定ロジックを更新し、公開ページに案内します。

適用の形式判定だけ試す場合(ログイン不要): /check

← ガイド一覧