クライアントとの契約書に「検収」の文字を見つけても、具体的に何を確かめれば責任の話が落ち着くのか、輪郭がつかみにくいものです。案件の契約書には、成果物を受け取ってもらう場面と、あとから不具合が見つかった場面の両方に条文が置かれています。責任の重さは条文の文言だけでなく、検収の基準がどこに書かれているかと、期間をどう数えるかで変わってきます。この記事では、IPAが公表した資料をもとに、契約不適合責任の輪郭を検収の基準と期間の数え方から順に整理します。

1. 責任の話は役割分担から始まる

契約不適合責任という言葉だけを見ると、どちらか一方が重い負担を背負う話に聞こえます。ですが実際の契約書は、責任を一点に集めるのではなく、役割を分けて置くところから設計されています。誰が何を確認し、いつまでに何を伝えるかという役割分担が、そのまま責任の輪郭になります。

IPAの資料は、責任関係や作業分担が明確になっていないと、損害賠償請求の訴訟などのトラブルに発展するケースもあると述べています¹。裏を返せば、役割分担が条文の形で書かれていれば、責任の範囲は先に見通せるということです。

役割分担が曖昧な契約書ほど、あとから揉めやすい

設計や実装を進めるなかで、誰が何を決めたのかがあいまいなまま進んでしまう場面は少なくありません。仕様の変更点をメールだけでやり取りして、契約書には反映しないまま進めるケースもあります。

あいまいさは進行中は問題に見えなくても、成果物を受け取ってもらう段階になって表面化します。検収の基準が条文にないと、双方が思い描く「完了」の像がずれたまま話し合いに入ることになります。

条文の細かさよりも、誰がどの範囲を確認するかという役割の線引きのほうが、実務では効いてきます。線引きが先に書かれていれば、あとの話し合いは事実の確認だけで済みます。

検収の基準を起点に、責任の輪郭をたどる

この記事では、責任の話を条文の一点からではなく、検収の基準・途中資料の承認・第三者ソフトの扱い・期間の数え方という4つの場面から順に見ていきます。それぞれの場面に、どんな考え方が置かれているかを一つずつ確認します。

抽象的な心構えよりも、契約書のどこにどんな条があるかを知っておくことのほうが、実際の話し合いでは役に立ちます。次の章から、検収の基準がどう決められているかを見ていきます。

図の作成：Remogu編集部。契約不適合責任が具体的な論点になりやすい場面を整理したもので、統計データではありません

2. 検収の基準が決まっていること

成果物を受け取ってもらう場面で、いちばん揉めやすいのが「何をもって完了とするか」という一点です。動作を一通り確認しただけで完了とするのか、決められたテスト項目をすべて満たして完了とするのか、条文に書かれていないと双方の理解がずれます。

IPAの資料は、契約書のひな型を見直すポイントの一つとして、検収基準の明確化を挙げています²。条文の見直しが進んでいるということは、この一点が実務でくり返し課題になってきたことの裏返しでもあります。

「何をもって完了とするか」が争いの入口になる

検収の基準があいまいなまま進むと、成果物を渡した側は「終わった」と考え、受け取る側は「まだ確認できていない」と考える、という食い違いが起きます。この食い違いは、感情の行き違いではなく、条文に基準が書かれていないことから生まれます。

基準がテスト項目の一覧のような具体的な形で示されていれば、確認する側も進める側も、同じものさしで話ができます。ものさしを共有できているかどうかが、あとの話し合いの長さを左右します。

基準を条文の言葉だけで終わらせない

条文に「検収基準」と一言書いてあるだけでは、実務での運用には届かない場面もあります。何を、どの手順で、誰が確認するのかという具体を、契約の付属資料に残しておく進め方が実務では取られています。

条文の言葉よりも、実際に残る記録のほうが、あとの説明を助けます。検収に関するやり取りは、口頭ではなく書面や記録が残る形で進めておくと、あとから振り返るときの手がかりになります。

次の章では、検収そのものより手前にある、途中の資料の承認について見ていきます。設計書や仕様書の承認も、責任の話に関わってくる場面です。

確認する場面	何を確かめるか	関係する条
成果物を受け取る場面	決められた基準をすべて満たしているか	検収の条
途中の資料を受け取る場面	設計書や仕様書の内容に相違がないか	承認に関する条
第三者の部品を組み込む場面	部品側の不具合の責任がどちらにあるか	責任分担に関する条
不具合があとから見つかった場面	いつを起点に期間を数えるか	契約不適合責任の条

3. 途中の資料の承認にも効果がある

責任の話は、成果物を渡す最後の場面だけで決まるわけではありません。開発の途中で作られる設計書や仕様書を、クライアントが承認する場面にも、あとの話し合いを左右する効果があります。

IPAの資料は、ひな型を見直すポイントとして、中間資料の承認の効果を明確化することも挙げています³。途中で承認された内容を、あとになって覆せるのかどうかが、実務でくり返し論点になってきたことが読み取れます。

設計書や仕様書の承認は、後戻りを防ぐ節目になる

設計書をクライアントが承認したあとに、前提が変わったからと大きな作り直しを求められると、進める側の負担は重くなります。承認という手続きには、そこから先を後戻りさせないための節目という意味があります。

逆に言えば、承認の効果が条文で明確になっていないと、節目としての意味も弱くなります。何が承認されると、どこまでの手戻りが起きなくなるのかを、契約の段階で確かめておく進め方が実務的です。

承認の記録を残す習慣が、責任の所在を明確にする

承認そのものより、承認したという記録が残っているかどうかのほうが、あとの話し合いでは重みを持ちます。議事録やメールの文面に、承認した日付と対象を残しておくと、あとから振り返る材料になります。

口頭でのやり取りよりも、書面に残ったやり取りのほうが、責任の所在を確かめるときの根拠になります。案件を進めるなかで、承認の場面が来たら、その記録を残す習慣をつけておくと安心です。

途中の資料の扱いを押さえたところで、次に見ておきたいのが、自分が作った部分ではなく、外部から組み込む第三者ソフトの扱いです。

4. 第三者の部品の扱いは分けて置かれている

開発する成果物のすべてを、自分だけで一から作ることは多くありません。外部で作られたライブラリや部品を組み込んで進める場面は日常的にあります。この部分の責任は、自分が書いた部分と同じ扱いにはなりません。

IPAの資料は、ひな型を見直すポイントとして、第三者ソフトの瑕疵等に関する責任分担も挙げています⁴。自分の作業の話と、外部の部品の話を、契約の段階から分けて考える必要があるということです。

自分が作った部分と、外部の部品は別の話

自分が実装したコードに不具合があった場合と、組み込んだライブラリ自体に不具合があった場合とでは、確かめるべき事実がまったく違います。前者は自分の作業を振り返る話であり、後者は部品の出どころを確かめる話です。

この二つを同じ責任として扱おうとすると、話がかみ合いません。契約書の段階で、外部の部品に起因する不具合をどう扱うかが分けて書かれているかどうかを、まず確かめておきたいところです。

組み込む部品の出どころを、契約の段階で確かめる

ライブラリの選定を自分の判断で行う場合と、クライアントから指定された部品を使う場合とでも、責任の重さは変わってきます。どちらの立場で部品を選んだのかを、あとから説明できる形にしておくと安心です。

個別の部品の細かな仕様よりも、責任分担の条がどう書かれているかという契約全体の設計のほうが、実務では優先して確かめたい点です。次の章では、この責任分担が契約書のひな型のなかでどう並んでいるかを見ていきます。

5. ひな型では検収と責任が続けて置かれている

検収の基準、途中資料の承認、第三者ソフトの扱いという3つの場面を見てきましたが、これらは契約書のひな型のなかで、ばらばらに置かれているわけではありません。検収の条と契約不適合責任の条は、隣り合わせに設計されています。

IPAの資料によれば、契約書のひな型には、検収の条と契約不適合責任の条が続けて置かれています⁵。検収が終わった直後の話として、不適合が見つかったときの扱いが書かれているという並びです。

検収の条と契約不適合責任の条は、隣り合わせに設計されている

検収を終えた成果物であっても、あとから不適合が見つかることはあります。ひな型がこの二つの条を続けて置いているのは、検収の合格が「今後いっさい問題を扱わない」という意味ではないことを示しています。

検収の基準を先に確かめておくことは、そのまま契約不適合責任の話にもつながります。二つの条を切り離して考えるよりも、続きの話として読んでおくほうが、契約書全体の理解が早くなります。

紛争を防ぐための手当てという論点

ひな型の見直しでは、条文の並びだけでなく、進め方そのものも論点になっています。IPAの資料は、ベンダのプロジェクトマネジメント義務とユーザの協力義務について、モデル契約上の手当てで紛争の予防に資することはできないかが論点として挙げられたと述べています⁶。

責任を一方に寄せる話よりも、双方の義務を条文にどう落とし込むかという話のほうが、ひな型の見直しでは中心になっています。契約は一方だけが確かめるものではなく、双方が確かめ合う仕組みとして設計されています。

ひな型の並びを押さえたところで、次はもう一つの重要な論点である、期間の数え方について見ていきます。いつからいつまでが対象になるのかは、責任の輪郭を決める大きな要素です。

図の作成：Remogu編集部。契約書のひな型における条文の並びと論点を整理したもので、統計データではありません

順序	条の呼び名	扱う内容
1つ目	検収の条	何をもって完了とするかの基準
2つ目	契約不適合責任の条	検収後に不適合が見つかったときの扱い
横断する論点	紛争予防に関する手当て	ベンダとユーザ双方の義務の明確化

6. 期間の数え方と「重大な過失」

契約不適合責任には、いつまでに指摘できるかという期間の考え方があります。この期間をどこから数えるかは、民法改正に対応した見直しのなかで整理が進んだ論点の一つです。

IPAの資料は、起算点についても、検収完了時から知った時へ整理する考え方が示されていると述べています¹⁰。感覚的な期間よりも、起算点がいつなのかという具体のほうが、実際の行動を左右します。

起算点が「検収完了時」から「知った時」へ整理された

検収が完了した日を起点に数えるという考え方と、不適合があると知った日を起点に数えるという考え方とでは、実際に指摘できる期間の長さが変わってきます。どちらの考え方が採られているかは、契約書の条文を確かめないと分かりません。

成果物を受け取った直後に問題が見つかるとは限りません。しばらく使い続けたあとに不具合が判明する場面もあるため、起算点の考え方が変わったことは、実務上の影響が小さくありません。

重大な過失の有無が、期間の分かれ目になる

IPAの資料は、民法改正に対応した見直しにより、請負型の業務における契約不適合責任でも「重大な過失」の有無が客観的起算点による期間制限の適用の分水嶺になったと述べています⁷。過失の重さによって、適用される期間の考え方そのものが変わるということです。

この分かれ目は、契約書の文言だけを読んでも見えにくい部分です。作業を進めるなかで、確認や記録をどれだけ残しているかが、あとになって過失の重さを説明する材料になります。

期間の数え方を押さえたところで、次はさらに実務で起きやすい、多段階契約の場面と、条文にしにくい理由について見ていきます。

図の作成：Remogu編集部。契約不適合責任の起算点の整理を図式化したもので、統計データではありません

起算点の考え方	数え始める時点	位置づけ
従来の起算点	検収が完了した時点	客観的に定まりやすい
整理された起算点	不適合を知った時点	民法改正への対応として示された
両者の分かれ目	重大な過失の有無	期間制限の適用を左右する

7. 遡られる場面と、条文にしにくい理由

ここまで、検収の基準・途中資料の承認・第三者ソフトの扱い・期間の数え方という4つの場面を見てきました。最後に、これらが積み重なって起きる、多段階契約特有の場面を見ておきます。

IPAの資料は、多段階契約では、下流工程でのトラブルをきっかけに、ユーザが上流工程まで遡って解除に基づく代金返還請求や損害賠償責任を追及する紛争が頻発していると述べています⁸。下流の問題が、上流の契約にまで及ぶという構図です。

多段階契約では、上流工程まで遡って争いになることがある

要件定義、設計、実装、テストというように工程が分かれている契約では、それぞれの工程が別の契約として結ばれることがあります。下流工程で不具合が見つかったとき、その原因が上流工程の要件定義にあったと主張されることがあります。

工程が分かれているからといって、責任の話も工程ごとに独立するとは限りません。上流工程での取り決めが、下流工程の成果物の評価に影響することを、契約を結ぶ段階で意識しておきたいところです。

重過失の例が少ないから、条文に落としにくい

IPAの資料は、システム開発の局面で重過失が認められた例はほとんどなく、契約書の条文の形に落とし込むのは難しいと述べています⁹。基準を明文化したくても、参考にできる実例が少ないという実務上の事情がうかがえます。

条文にしにくい部分があるからこそ、日々の作業のなかで確認や記録を残しておくことの意味が大きくなります。あいまいな線を条文が引いてくれない場面ほど、自分の側の記録が説明の支えになります。

図の作成：Remogu編集部。契約を結ぶ段階で確かめておきたい項目を整理したもので、統計データではありません

4つの場面を条文の段階から確かめておく力は、案件を離れて働く場面でいっそう意味を持ちます。近くに相談できる担当者がいない分、契約の内容を自分で読み解く力が問われるからです。Remoguが取り扱う案件は、90%以上がフルリモート可能です。場所に縛られずに働きたいという理想と、契約を自分の目で確かめる力は、両立させることができます。

初めて受ける案件でも、契約不適合責任の考え方は変わりますか

考え方そのものは、経験の長さによって変わるものではありません。検収の基準・承認の効力・第三者部品の扱い・期間の数え方という4つの項目は、初めて受ける案件でも同じように契約書に置かれています。経験がまだ少ない段階では、これらの項目が条文のどこにあるかを、まず一つずつ確認する進め方が着実です。

副業として受ける案件でも、確認する内容は同じですか

稼働の形が主とする案件か副業かによって、確認する項目そのものが変わるわけではありません。検収の基準や期間の数え方は、契約書に書かれている内容として同じように確かめておきたい点です。稼働の時間配分は案件によって異なるため、そちらは個別に条件を協議しておくと安心です。

週3日程度の稼働でも、検収の基準は変わりますか

検収の基準は、稼働日数によって変わるものではなく、成果物に対して定められるものです。週3日程度の稼働であっても、決められた基準を満たしているかどうかが確認の対象になります。稼働日数が少ない分、進捗の報告と記録を細かく残しておくと、検収の場面で説明がしやすくなります。

契約不適合責任の輪郭は、検収の基準がどこに書かれているかを確かめるところから見えてきます。まずは今の契約書、あるいはこれから結ぶ契約書のなかで、検収の条と契約不適合責任の条がどう置かれているかを確かめてみましょう。自分の経験に合う条件を、登録して確かめてみることも、次の一歩になります。

※公開中の案件数は時期によって変わります。記事中の案件の傾向は執筆時点のものです。

出典・参考情報

＊1 IPA「システム開発の健全化に向けて（情報システム・モデル取引・契約書 講演資料）」起点の問題（2025年4月・2026年9月確認）
＊2 IPA「システム開発の健全化に向けて（情報システム・モデル取引・契約書 講演資料）」検収の基準（2025年4月・2026年9月確認）
＊3 IPA「システム開発の健全化に向けて（情報システム・モデル取引・契約書 講演資料）」途中の承認（2025年4月・2026年9月確認）
＊4 IPA「システム開発の健全化に向けて（情報システム・モデル取引・契約書 講演資料）」第三者の部品（2025年4月・2026年9月確認）
＊5 IPA「システム開発の健全化に向けて（情報システム・モデル取引・契約書 講演資料）」条の置かれ方（2025年4月・2026年9月確認）
＊6 IPA「システム開発の健全化に向けて（情報システム・モデル取引・契約書 講演資料）」双方の義務（2025年4月・2026年9月確認）
＊7 IPA「システム開発の健全化に向けて（情報システム・モデル取引・契約書 講演資料）」期間の分かれ目（2025年4月・2026年9月確認）
＊8 IPA「システム開発の健全化に向けて（情報システム・モデル取引・契約書 講演資料）」遡られる場面（2025年4月・2026年9月確認）
＊9 IPA「システム開発の健全化に向けて（情報システム・モデル取引・契約書 講演資料）」条文にしにくい（2025年4月・2026年9月確認）
＊10 IPA「システム開発の健全化に向けて（情報システム・モデル取引・契約書 講演資料）」起算点の整理（2025年4月・2026年9月確認）