クライアントとの契約書に「検収」の文字を見つけても、具体的に何を確かめれば責任の話が落ち着くのか、輪郭がつかみにくいものです。案件の契約書には、成果物を受け取ってもらう場面と、あとから不具合が見つかった場面の両方に条文が置かれています。責任の重さは条文の文言だけでなく、検収の基準がどこに書かれているかと、期間をどう数えるかで変わってきます。この記事では、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%以上がフルリモート可能です。場所に縛られずに働きたいという理想と、契約を自分の目で確かめる力は、両立できます。

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

8. よくある質問

責任関係や作業分担が曖昧だと、どうなりますか

IPAの資料は、責任関係や作業分担等が明確になっていないと、損害賠償請求の訴訟などのトラブルに発展するケースもあると述べています¹。

重過失は契約書の条文に入れられますか

IPAの資料は、システム開発の局面で重過失が認められた例がほとんどないため、契約書の条文の形に落とし込むのは難しいと述べています¹。

紛争の予防について、モデル契約では何が論点に挙げられましたか

ベンダのプロジェクトマネジメント義務とユーザの協力義務について、モデル契約上の手当てで紛争の予防に資することはできないかが、論点として挙げられました¹。

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

出典・参考情報

＊1 IPA「システム開発の健全化に向けて（情報システム・モデル取引・契約書 講演資料）」起点の問題（2025年4月・2026年10月確認）