ECサイト構築委託— 請負と役務の区分

1. 請負と役務委託の区分

1-1. 一式請負としての契約

デザイン・実装・初期商品登録・決済連携までを固定報酬で請け負う形態です。
完成・引渡しを検収条件とし、受領日は公開可能状態になった日と定義することが多いです。

1-2. 工程別の役務委託

デザイン・フロント実装・バックエンド・商品撮影を別ベンダーに分ける場合、各工程で発注書面・台帳を分けます。
一括で「EC 構築費」として処理すると、どの給付の受領日か追えなくなります。

1-3. 適用判定と書面

資本金・従業員数・取引形態により取適法の適用有無が変わります。
発注前に発注コンプライアンスのチェックリストで判定し、発注書面の3条書面を整えます。

2. 段階検収とマイルストーン

2-1. 設計・実装・公開の切り分け

ワイヤー承認・テーマ実装完了・テスト環境公開・本番公開など、マイルストーンごとに検収・支払を分ける設計が一般的です。
各段階の完了定義をチェックリスト形式で別紙に添付します。

2-2. 受領日と60日起算

段階ごとの受領日を台帳に記録し、支払60日ルールの起算点から支払期日を計算します。
本番公開前のテスト環境受領を起算に含めるかは契約で明確にします。

2-3. 検収基準の具体化

「動けば OK」ではなく、決済テスト・配送設定・特定商取引法表記・プライバシーポリシー設置等を検収項目に含めます。
検収基準の設計は検収基準の決め方も参照してください。

3. 追加機能・仕様変更・保守

3-1. スコープ外の追加要望

会員機能・サブスク・多言語対応など、当初見積もり外の機能は追加発注として書面化します。
口頭で「ついでに入れて」と依頼した機能は、検収時に争点になりやすいです。
Shopify アプリの追加インストールも、機能追加の一種として見積もり・承認の対象に含めます。

3-2. SaaS プラン・プラグイン費用

Shopify アプリ月額・テーマ購入費等は、構築報酬と別勘定で処理します。
発注者名義で契約するか受託者経由かを決め、台帳上も分けます。

3-3. 公開後の保守委託

構築完了後の更新・障害対応は、別契約の継続委託として切り出すのが一般的です。
構築契約に無償保守期間を含める場合、その期間と範囲を明記します。

4. データ・権限・引き渡し

4-1. 管理画面権限

ストア管理権限は発注者名義を原則とし、構築完了時にオーナー権限を移譲します。
受託者のテスト用アカウントは公開前に削除または権限降格します。

4-2. ソース・カスタマイズの帰属

カスタムテーマ・独自アプリの著作権帰属、Shopify 標準機能との境界を契約に書きます。
引き渡し物一覧に、ドキュメント・設定値エクスポートを含めます。

4-3. 商品データ・画像素材

商品登録代行を含む場合、登録件数上限・画像加工の範囲を契約に明記します。
素材の著作権・肖像権は発注者提供か受託者制作かを区別して記録します。

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

5-1. 公開直前に決済連携を追加したとき

例えば本番公開2週間前に、当初見積もりに無かった Amazon Pay 連携を依頼したとします。
追加見積もり・納期への影響・検収条件を変更依頼書で合意し、台帳に別発注として紐づけます。
承認なしに実装が進んでいる場合、公開延期の責任分界で争点になります。
決済テストの完了条件と、本番切替のロールバック手順も変更依頼書に含めておきます。

5-2. デザインと実装を別ベンダーにしたとき

デザイン納品日と実装開始日のずれが遅延を生む場合、両契約で納期の関係を明記します。
デザイン変更が実装工数に与える影響は、追加発注として記録します。
実装側の受入テストでデザイン差異が見つかった場合、修正がデザイン契約の範囲か実装契約の範囲かを事前に決めておきます。

5-3. 発注前チェック（EC 構築向け）

納品範囲・マイルストーン・検収項目・追加機能の扱い・SaaS 費用・権限移譲・保守の切り出しを書面に含めるか確認します。
段階ごとの受領日を台帳に記録する担当を決め、経理への引き渡し期限も統一します。
特定商取引法・プライバシーポリシー・返品規定など、公開に必要なページ設置も検収チェックリストに含めます。

よくある質問

Q. Shopify 構築は請負と役務どちらですか

契約の書き方と給付の性質によります。完成引渡し型なら請負に近く、工程別発注なら役務委託として整理されます。
取引実態に合わせて書面を設計してください。

Q. テスト環境だけ先に検収できますか

契約でマイルストーンを分けていれば可能です。テスト環境受領日を起算に含めるかも明記します。

Q. 商品登録500件は構築費に含まれますか

見積もり段階で登録件数上限を固定し、超過分は追加発注とします。
件数・画像加工の有無を別紙に書いておきます。

Q. 公開後のバグ修正は無償ですか

契約上の瑕疵対応期間と、仕様変更・新機能は別物として扱います。
無償期間・回数上限を契約に書いておきます。
決済・在庫連携など外部 API 起因の不具合は、委託範囲とベンダーサポートの境界も合意文書に残します。

Q. 受託者名義の Shopify ストアは問題ですか

名義・解約時のデータ移管・支払条件でリスクが生じます。発注者名義を原則とすることを推奨します。

まとめ

• 一式請負か工程別役務かを発注前に決め、台帳・検収をそれに合わせる
• マイルストーンごとに検収・受領日を切り、60日起算で支払期日を管理する
• 追加機能・SaaS 費用は構築報酬と分け、書面で都度合意する
• 管理権限・ソース帰属・商品登録範囲を引き渡し時まで明確にする

6. ECサイト構築委託の発注前チェックリスト

• 納品範囲とマイルストーン・検収項目を書面に書いたか
• 追加機能・商品登録件数上限を見積もりに含めたか
• SaaS・アプリ費用を構築報酬と台帳で分けたか
• 管理権限移譲と引き渡し物一覧を合意したか
• 公開後保守を別契約に切り出すか決めたか
• 段階ごとの受領日記録担当を決めたか

公開直前の「ついでに」追加は争点になりやすいです。変更は着手前に書面合意してください。
デザインと実装を分けた場合、両契約の納期関係を明記しておきます。
本番公開日を社内の統合受領日とするか、決済テスト完了日とするかを事前に決め、台帳の検収メモに残します。
公開後1週間の軽微な修正が無償保守に含まれるかどうかも、契約の瑕疵条項とセットで確認します。
ストア審査リジェクト対応が構築スコープに含まれるかも、見積もり段階で明記しておきます。

注意

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