ECサイト・システム開発の外注で『検収』のリスクとは？支払いと契約不適合責任を防ぐ契約のポイント

◆監修・編集責任者　小園 将隆　2026年10月1日

B2B EC-COLUMN

ECサイト・システム開発の外注で『検収』がリスクになる理由

納品されたECサイトを触ってみたら、カートまわりの挙動が仕様書の読み方次第でどちらにも取れる。
検収書に署名してよいのか決めきれないまま、月末の支払処理だけが近づいてくる。
こうした場面で発注者が実際に動かせるのは、納品後の判断よりも、契約書に検収の基準と期限をどう書いておくかという手前の部分です。
検収は完成を確認する作業であると同時に、代金の支払期日が走り出し、不具合の責任を追及できる期間が始まる起点でもあります。
2026年に施行された取適法では、検収の有無にかかわらず受領後60日以内に代金を支払う義務があり、受託者に責任のない受領拒否や返品も禁じられています。
検収を保留すれば支払いも止められる、という前提は成り立ちません。

検収とは何を確認する手続きか

検収は、開発会社から納品されたECサイトやシステムが契約で定めた内容を満たしているかを発注者が確認し、受け取りを確定させる手続きです。
検証環境で主要な画面を触り、仕様書や要件定義書と突き合わせ、問題がなければ検収書に署名する。
作業の見た目としては、それだけのものに見えます。

ところが、検収が完了した瞬間に動き出すのは、完成の確認だけではありません。
納品物を受け取ったという事実が確定し、代金の支払期日の計算が進み、あとから不具合が見つかったときに責任を追及できる期間が始まります。
検収は、品質の判定と、お金と責任の時計を同時に扱う手続きなのです。

この三つが同時に動くことを意識しないまま進むと、社内の段取りもあいまいになります。
誰が検収の責任者なのか、どの環境で確認するのか、合格と判断した記録をどこに残すのか。
担当者が「一応見ました」と口頭で伝えただけの状態は、開発会社から見れば検収が終わったのかどうか分からない状態です。

だからこそ、検収の基準や期限が決まっていない取引では、二つの方向からもめ事が起きます。
一つは支払いをめぐるもので、発注者は「まだ検収が終わっていない」と考え、開発会社は「納品は済んでいるのだから支払期日は来ている」と考える。
もう一つは責任をめぐるもので、公開後に出た不具合について、発注者は無償での修正を求め、開発会社は追加の見積りを出す。
どちらも、検収という一点の認識がずれていることから生まれます。

情報成果物作成委託（ソフトウェア・サイト制作）も規律の対象になる

もう一つ見落としやすいのが、自分たちの発注がそもそも法律上の規律の対象かどうかという点です。
取適法の対象となる取引には、物品の製造委託・修理委託や特定運送委託に加えて、情報成果物作成委託と役務提供委託が含まれます³。
ECサイトの構築、カート機能の改修、受注管理システムの開発、サイトのデザインやコーディングの委託は、この情報成果物の作成にあたります。

「うちは製造業ではないから関係ない」という受け止めは、ここで外れます。
ソフトウェアやウェブサイトを外部に作ってもらう取引も、発注の仕方から受け取り、支払いの時期まで規律が及ぶ場面として扱われます。
自社の制作物だから社内のルールで自由に扱える、という前提で検収を運用していると、そこがリスクの入口になります。

ただし、すべての外注が対象になるわけではありません。
対象になるかどうかは発注する側と受注する側の資本金や従業員数などの基準によって決まり、相手が一定の基準に該当する中小受託事業者である場合に規律がかかります。
本記事で参照した資料からは具体的な基準の数値までは確認できていないため、自社の取引が該当するかどうかは、発注先の規模とあわせて条文や公表資料で確かめてください。
以降の説明は、この条件に当てはまる取引を前提にしています。

実務では、同じ社内でも発注先によって扱いが変わり得る点が厄介です。
大手の開発会社に出している基幹システムの改修と、小規模な制作会社に出しているLPやバナーの制作とでは、適用の有無が異なることがあります。
契約書のひな形を一本に揃えていても、どの取引が規律の対象になるのかは発注管理の側で把握しておく必要があります。

検収を先延ばしにすれば支払いを遅らせられるか

2026年1月施行『取適法』とは

長く下請法という名前で知られてきた法律は、中小受託取引適正化法（取適法）へと改められました。
この改正法は2026年から施行されています²。
名称が変わったことで、社内の発注マニュアルやチェックリストの表現だけが古いまま残っている、という状態が起きやすい時期でもあります。

発注者の実務に引き寄せると、見るべきなのは呼び名よりも、受領・検収・支払いという一連の流れにどの義務がかかっているかです。
とくに支払いの期日は、社内の検収フローの設計をそのまま左右します。
なお、施行日より前に締結した契約の取扱いについては、本記事で参照した資料からは確認できていません。

検収の有無にかかわらない60日以内の支払い義務

情報成果物作成委託では、検収の有無にかかわらず、受領後60日以内に定めた支払期日までに代金を支払う必要があります¹。
つまり「検収が終わっていないから支払いは保留する」という運用は、この規律のもとでは通りません。
検収の進み具合と支払期日は、別々に走る時計だと考えたほうが実態に近いものです。

この一点は、社内の検収体制の作り方に直結します。
納品を受けてから検証担当者を割り当て、関係部署に確認を回し、稟議を上げる——という段取りを納品後にゼロから始めると、検証が終わらないうちに支払期日が近づきます。
ECサイトの改修はセールや商戦期の前に納品が集中しがちで、検証に人を割けない時期と重なりやすい。
検収にかけられる日数を先に見積もり、そこから逆算して納品日を決めるほうが現実に合います。

規模の大きい開発であれば、納品そのものを分けるという手もあります。
画面単位や機能単位で区切って納品を受ければ、一度に検証する量が減り、検収の遅れがそのまま支払いの期限と衝突する場面を減らせます。
ただし分割すれば、それぞれの受領日から期日が動き出すことになるため、何をもって一つの納品とするかは契約の段階で決めておく必要があります。

逆の言い方をすれば、検収を遅らせることは発注者の防御手段になりません。
支払いを止めるための保留は規律に反する可能性があり、同時に、次に説明する受領拒否の問題にもつながります。
防御になるのは、合否を判断できる基準をあらかじめ用意しておくことのほうです。

例外となる『みなし受領』の事前合意

起算日の決め方には例外にあたる扱いもあります。
委託事業者と中小受託事業者が事前に合意している場合、納期前に一定の水準を満たしていることを確認した時点を受領とみなすことができ、この確認した時点が支払期日の起算日になります¹。

ここを「支払いを後ろ倒しにできる仕組み」と読むと意味が逆になります。
みなし受領は、受け取った日がいつなのかを当事者の間で特定しておくための取り決めであり、起算日を曖昧にしないための方法です。
条件は二つあり、事前の合意があること、そして満たすべき水準が決まっていることです。
どの画面がどう動けば水準を満たすのかを契約書や個別の仕様書に書いておかなければ、合意として機能しません。

水準を書くときに迷いやすいのは、どこまで細かくするかです。
すべてのテスト項目を列挙しようとすると契約書が膨らみ、改修のたびに作り直すことになります。
契約書には判定の枠組み（誰が、どの環境で、何を根拠に確認するか）を置き、個別の項目は発注ごとの仕様書や試験項目表に委ねて、契約書からそれを参照する形にしておくと、運用に乗りやすくなります。

検収で『不合格』にできる場合・できない場合

受領拒否が禁止されるケース（第5条第1項第1号）

支払期日が検収の進み具合で動かないとすれば、次に気になるのは、そもそも受け取りを断れるのはどんなときかという点です。
中小受託事業者に責任がないにもかかわらず納入物の受領を拒むことは、受領拒否として禁止されています（第5条第1項第1号）⁴。

実務で問題になりやすいのは、品質そのもの以外の理由です。
社内から別の意見が出たので公開を見送りたい、繁忙期に入って検証に手が回らない、方針が変わって機能自体が不要になった——いずれも開発会社の側に責任がある事情ではありません。
こうした理由で納品物を受け取らない運用は、受領拒否として問題になり得ます。

では「受託者に責任がある」とはどういう状態か。
判断の軸になるのは、契約書や発注書で合意した内容を満たしているかどうかです。
合意した内容が「使いやすいカート画面」といった抽象的な言葉しかないと、満たしているかどうかを誰も判定できません。
検収リスクの本体は、拒否してよい場面が狭いことそのものよりも、拒否の当否を判断する物差しが契約に用意されていないことにあります。

途中で仕様変更が入った取引は、この物差しがとくにずれやすいところです。
打ち合わせの口頭合意やチャットのやり取りだけで変更を進めると、納品物が「最初の仕様」と「変更後の了解」のどちらを基準に判定されるのかが分からなくなります。
変更を受け入れた時点で検収の判定基準も更新し、どの資料が最新かを双方で確認しておくほうが、納品時の判断が速くなります。

受領後の返品が禁止されるケース（第5条第1項第4号）

受け取ったあとの扱いにも規律があります。
受領後の返品が認められるのは、納入物に明らかな不良・不備があるなど中小受託事業者に責任がある場合に限られ、それ以外の受領後の返品は禁止されています（第5条第1項第4号）⁴。

物品であれば返品の姿は分かりやすいのですが、システムやサイトの場合は形が違います。
検収を済ませた後になって「やはりこの仕様では使えない」として作り直しを求め、その分の代金を払わない、といった扱いが実質的な返品にあたります。
受領後に気が変わったという理由では、この扱いはとれません。

ここから導かれる実務上の帰結は、検収の前にどこまで検証するかを決めておくことです。
受け取ってしまえば、後から差し戻せる範囲は狭くなる。
一方で、検収に無期限の時間をかけられるわけでもなく、支払期日の上限は受領日から進みます。
検収期間を契約書で定める意味は、この二つの制約の間に現実的な線を引くことにあります。

現場では、致命的ではない不具合がいくつか残った状態で検収日を迎えることがよくあります。
全部直るまで受け取らないという構えは支払期日と衝突しやすく、かといって無条件に合格とすれば修正の約束が残りません。
一つの考え方として、合否の判定とは別に、合格後に残課題として対応する項目とその期限を一覧にして合意しておく運用があります。
これは確認した規律から導いた契約・運用設計の提案であり、残課題の扱い方自体は当事者の取り決めによって変わります。

検収完了後に不具合が見つかったらどうなるか

モデル契約書における検収完了時点の位置づけ

受け取りの可否が整理できたところで、受け取った後に問題が見つかった場合に移ります。
経済産業省とIPAが示す「情報システム・モデル取引・契約書」では、検収完了時という客観的な時点を契約不適合責任の期間制限の起算点とする規律が維持されています（ベンダに故意・重過失がある場合を除く）⁵。

起算点が検収完了時であることの意味は、数え始めの日が記録に残る一点に固定されるところにあります。
不具合に気づいた日や、運用が安定したと感じた日といった、人によってずれる時点ではありません。
裏を返すと、検収がいつ完了したのか自体が曖昧な取引では、期間の計算も曖昧になります。

そのため、検収完了をどう記録するかが思いのほか効いてきます。
検収書の日付なのか、合格を通知したメールの日付なのか、再検査を経た場合はどちらを完了日とするのか。
合否の通知方法まで契約書に書いておけば、後から「いつ終わったか」を遡って探す必要がなくなります。

この説明が当てはまるのは、モデル契約書に準じた検収・契約不適合責任の条項を置いた請負型の受託開発契約です⁵。
独自の条項を使っている契約や、成果物の完成を約束しない準委任型の契約では前提が変わります。
手元の契約書がどちらの型なのかを先に見てください。

契約不適合責任の期間を契約書で定める意味

期間の長さそのものは、契約当事者が定める事柄です。
本記事で参照した資料からは具体の月数を示せないため、何か月とするかは交渉と、適用される法令の確認によって決まります。

発注者の立場で考えておきたいのは、ECサイトの不具合が出る時期の偏りです。
平常時のアクセスでは問題なく動いていた在庫の引き当てやクーポンの判定が、セールや商戦期の注文量で初めて崩れることがあります。
検収完了から数えた期間が短いと、実運用でしか現れない種類の不具合が期間の外に出てしまう。
期間を決めるときは、カレンダー上で運用の山を一度またぐかどうかを一つの目安に置くと、現場の感覚と合わせやすくなります。
これは確認した規律を前提にした契約設計の考え方であり、何か月なら安全と決まっているわけではありません。

期間と合わせて決めておきたいのが、対象となる不適合の範囲です。
契約で合意した仕様を満たしていない状態を指すのか、運用して分かった使いにくさまで含めるのか。
後者を無制限に含める書き方は開発会社側が受けにくく、交渉が長引きます。
仕様との不一致を対象の中心に置き、使い勝手の改善は別の保守・改修の枠組みで扱うと分けておくほうが、双方の了解を得やすい形になります。

なお、モデル契約書の規律では、ベンダに故意・重過失がある場合は起算点の扱いが別になるとされています⁵。
通常の不具合対応とは切り分けて考える部分です。

トラブルを防ぐために契約書に明記しておくべきこと

検収基準・検収期間を明記する

ここまでの規律を踏まえて、発注前の契約書に何を書いておくかを整理します。
最初は検収基準です。
何をもって合格とするのかを、判定できる形にしておきます。

具体的には、合否を判定するテスト項目と期待する結果、検証を行う環境が本番と同等かどうか、判定を行う担当者、不合格だった場合の再納品と再検査の進め方です。
「表示が崩れないこと」ではなく、どの環境のどの画面で、どの操作をしたときに何が起きれば合格なのか。
この粒度まで落ちていれば、受領を拒否してよい場面かどうかも、両者が同じ材料で判断できます。

次に検収期間です。
納品から何営業日以内に合否を通知するのか、通知がなかった場合にどう扱うのか、再検査にはどれだけの期間を置くのか。
通知の期限がないと、検収がいつまでも終わらない状態と、開発会社が「もう合格したはずだ」と考える状態が同時に生まれます。
期間を決めるときは、受領日から支払期日までの上限が60日以内である点¹を前提に、社内の検証と稟議が収まる日数を置いてください。

書く場所も決めておくと運用が崩れません。
判定の枠組みと期間は基本契約書に、個別のテスト項目は発注ごとの仕様書や試験項目表に置き、契約書からそれを参照する。
この形にしておけば、案件ごとに契約書を作り直さずに、検収の基準だけを案件の中身に合わせて差し替えられます。

みなし受領の条件を合意しておく

みなし受領の条件を合意しておくと、支払期日の起算日を当事者の間で特定できます¹。
どの水準を満たした確認をもって受領とみなすのかを、検収基準と同じ粒度で書いておくことが前提になります。

この合意は、検収作業をやめてよいという意味ではありません。
水準を満たしているかを確認する行為自体は残ります。
変わるのは、受け取った日がいつなのかで食い違う余地が小さくなることと、支払処理の予定を早い段階で立てられることです。

契約不適合責任の期間を明記する

三つ目が契約不適合責任の期間です。
起算点を検収完了時とすること⁵、期間の長さ、対象となる不適合の範囲、発見した場合の通知方法を書きます。
通知方法を決めておけば、期間内に申し出たかどうかを後から確認できます。

いま挙げた三点は、いずれも揉めてから決めることができない種類の取り決めです。
検収の場面で意見が割れたときには、すでに双方に立場があり、基準を後から合意するのは難しくなります。
契約書に書いておくことで、支払いと責任をめぐる主張の食い違いが起きにくくなる、というのが本記事で確認した規律から導ける範囲の結論です。
どんな契約文言でも不具合やすれ違いがなくなるわけではありませんが、少なくとも「何を根拠に判断するのか」という問い自体は残らなくなります。

最後に前提の確認です。
ここまで述べた支払期日や受領拒否・返品の規律は、相手が一定の基準に該当する中小受託事業者である取引にかかるものです。
規律の対象かどうかは発注者と受注者の規模の関係で決まるため、発注先が変われば、同じひな形を使っていても適用の有無が変わり得ます。
契約書の整備と並行して、どの取引が対象になるのかを発注管理の側で把握しておくと、運用が揃います。

検収の場面で禁止されている行為そのものは、次の二点に整理できます。

検収基準をどこまで書けばよいか、検収期間を何営業日に置けば社内の検証と稟議が収まるかは、サイトの構成や繁忙期の山によって変わるため、法令の条文を読むだけでは決まりません。

現在のサイト構成と運用の繁忙期を前提に、検収で確認すべき項目の範囲と、納品日から逆算した検収スケジュールの組み方を具体的に詰められます。無料相談で要件を整理する

検収に関わる主な禁止行為の整理

検収の前（受け取る場面）と後（受け取った後の場面）という、起きる時点の違いで並べています。

• 受領拒否（第5条第1項第1号）——中小受託事業者に責任がないにもかかわらず納入物の受領を拒むこと。社内の方針変更や検証に手が回らないといった発注者側の事情は、拒否の理由にならない

• 返品（第5条第1項第4号）——受領後に納入物を返すこと。認められるのは明らかな不良・不備など中小受託事業者に責任がある場合に限られ、受領後に判断が変わったという理由では扱えない

いずれも、相手が規律の対象となる中小受託事業者に当たるかどうかで適用の有無が変わります。

要点の整理

確認する軸	判断の基準
支払期日の起点	納品物を受領した日。検収が終わっていないことを理由に後ろ倒しにはならない
支払期日の上限	情報成果物作成委託では受領後60日以内に定めた支払期日まで
起算日を特定したい場合	事前合意によるみなし受領。満たすべき水準を契約・仕様書に書いておく
受け取りを断れる場面	受託者側に責任がある場合に限られる。受領後の返品も同じ
検収後の責任の起算点	モデル契約書に準じた請負型契約では検収完了時。完了日の記録方法まで決める
契約書に書く項目	検収基準、検収期間と通知方法、みなし受領の条件、契約不適合責任の期間と範囲

すでに走っている委託契約については、どの条項が曖昧で、どの発注先との取引から優先して直すべきかを、取引の実態と突き合わせて見ないと判断できません。 既存の契約書と直近の発注内容を見ながら、検収と支払いで食い違いが起きやすい箇所の洗い出しと、次回の発注で先に決めておく項目の整理ができます。

よくある質問

検収基準や検収期間を契約書で決めていない場合、支払いの起点はどうなりますか

検収についての取り決めがないことを理由に、支払いの起点が後ろへずれるわけではありません。
情報成果物作成委託では、検収の有無にかかわらず受領後60日以内に定めた支払期日までに代金を支払う必要があります¹。
基準や期間を決めていない取引で起きるのは、支払いが待ってもらえる状態ではなく、合否の判断材料がないまま期日だけが近づく状態です。
まずは次の発注分から、合否の判定方法と通知の期限を発注書や仕様書の側で揃えるところから始めるのが現実的です。

『みなし受領』の合意をしておけば、検収の手続きは省略してよいのでしょうか

省略してよいという意味ではありません。
みなし受領は、事前に合意した水準を満たしていることを確認した時点を受領とみなし、そこを支払期日の起算日とする扱いです¹。
水準を満たしているかどうかを確認する行為自体は残りますし、その水準が契約や仕様書に書かれていなければ、確認のしようもありません。
変わるのは作業の有無ではなく、受領日がいつなのかで食い違う余地が小さくなる点です。

ECサイトのデザインやコーディングの外注も、情報成果物作成委託として対象になりますか

取適法の対象となる取引には情報成果物作成委託が含まれており³、サイトのデザインやコーディング、システムの開発はここに当たります。
ただし対象になるかどうかは、発注する側と受注する側の資本金や従業員数などの基準によって決まり、相手が一定の基準に該当する中小受託事業者である場合に規律がかかります。
具体的な基準の数値は本記事で参照した資料からは確認できていないため、発注先ごとに条文や公表資料で確かめてください。

受領拒否や返品が認められる『受託者に責任がある場合』とは、具体的にどんなケースですか

返品について示されているのは、納入物に明らかな不良・不備があるなど中小受託事業者に責任がある場合に限られるという点です⁴。
システムやサイトであれば、契約や仕様書で合意した動作を満たしていない状態がこれに当たります。
逆に、社内で別の意見が出た、方針が変わって機能が不要になった、検証の時間が取れないといった発注者側の事情は、受託者の責任ではありません。
判断が割れるのは多くの場合「合意した内容」が曖昧なときなので、何をもって合格とするかを契約の段階で書いておくことが、そのまま拒否や返品の当否を判断できる状態をつくることになります。

1. 1　出典：公正取引委員会「中小受託取引適正化法(取適法)よくある質問コーナー」（2026年）
2. 2　出典：公正取引委員会「2026年1月施行！～下請法は取適法へ～改正ポイント説明会の実施について」（2026年）
3. 3　出典：公正取引委員会「取適法の概要」（2026年）
4. 4　出典：公正取引委員会「委託事業者の禁止行為」（2026年）
5. 5　出典：独立行政法人情報処理推進機構(IPA)「「情報システム・モデル取引・契約書」からの見直しのポイント」（2026年）