検収後のバグ・ミスを
請負人に追完させる条項

次の重要ポイントは、このページ全体で扱う検収後バグ追完条項の設計軸を三つに整理したものです。読者にとって重要なのは、検収後の救済だけを強めるのではなく、検収の確定性、潜在的不適合の救済、保守との境界を同時に読み取ることです。

このページは、企業間取引、特にシステム開発、業務委託、制作物納入、設計・構築業務などにおいて問題となる「検収後に発覚したバグやミスを請負人に追完させる条項」を、契約法務・IT法務・紛争予防の観点から整理した専門的解説である。個別案件における法的助言ではなく、実際の契約書作成・交渉・紛争対応では、契約類型、成果物、当事者の専門性、仕様書、検収手続、保守契約、損害賠償制限、下請・再委託構造、準拠法、裁判管轄等を踏まえて弁護士等に確認する必要がある。

このページでは、民法上の請負、契約不適合責任、履行の追完、検収、通知期間、システム開発紛争の裁判実務、IPAの情報システム・モデル契約に関する公表資料等を基礎として論じる。なお、以下では、注文者を「甲」、請負人・ベンダ・開発会社・制作会社等を「乙」と表記する。

結論の要点

「検収後に発覚したバグやミスを請負人に追完させる条項」を設計する際の核心は、単に「検収後でも乙は無償で直す」と書くことではない。むしろ、次の二つの価値を両立させることである。

第一に、検収は、成果物の納入、検査、報酬支払、プロジェクト完了、危険・管理責任の移転、次工程への移行を区切る重要な手続である。検収後に、甲が無限定に「これはバグである」「これはミスである」と主張できるなら、乙はいつまでも成果物の完成と報酬確定を得られない。これは請負契約の安定性を損なう。

第二に、ソフトウェア、システム、データ移行、設定、設計書、業務手順構築などでは、通常の検収テストだけでは発見困難な不具合があり得る。検収後に本番環境、実データ、長期運用、外部システム連携、同時アクセス、月次・年次処理等で初めて顕在化する問題もある。検収済みであるという一事をもって、こうした契約内容に適合しない不具合の追完請求を全面的に否定すれば、甲に過度な不利益が生じる。

したがって、実務上適切な条項は、次のような設計をとるべきである。

次の比較表は、検収後バグ追完条項は確定と救済の両立が核心で確認すべき項目を設計項目、実務上の要点の列で整理したものです。契約レビューで重要なのは、各列の違いから責任範囲、手続、期限、費用負担のどこを条文に落とすべきかを読み取ることです。

このような構造をとることで、甲にとっては「検収後に発覚した重大なバグやミスへの救済」が確保され、乙にとっては「無限定・無期限の無償対応義務」を避けることができる。

次の判断の流れは、検収後に見つかった不具合を契約不適合として扱うかを検討する順番を示しています。読者にとって重要なのは、検収済みかどうかだけで結論を急がず、契約内容、原因、通知、期間、追完可能性を順に確認することです。

3.1 改正民法後の基本構造

現行民法では、従来の「瑕疵担保責任」という整理から、契約内容に適合しない履行に対する「契約不適合責任」という整理へ移行している。請負においても、成果物が契約内容に適合しない場合には、追完請求、報酬減額請求、損害賠償請求、解除といった救済が問題となる。

企業法務上、ここで重要なのは、「契約不適合」とは、抽象的な完全性を意味しないという点である。契約不適合かどうかは、当該契約において合意された内容、仕様書、要件定義書、設計書、提案書、議事録、テスト仕様書、受入基準、変更合意、当事者の専門性、取引通念等を総合して判断される。

したがって、契約書レビューでは、単に「乙は検収後も不具合を修補する」と書くだけでは不十分である。何が契約内容なのか、どの文書が優先するのか、受入基準は何か、未確定事項はどう変更管理するのか、検収時に残課題をどう扱うのかを定めておく必要がある。

3.2 検収後でも追完請求が問題となる理由

請負契約では、検収は完成・納入・支払と強く結びつく。しかし、検収は万能ではない。特にソフトウェアやデータ処理のような成果物では、次の理由により、検収時点ですべての不具合を発見することは困難である。

• 全入力パターンを検証することが現実的に不可能である
• 大量データ、長期データ、月次・年次処理は検収時に再現しにくい
• 外部システム連携は本番接続後に初めて問題が出る場合がある
• 同時アクセス、ピーク時処理、ネットワーク遅延等は本番で顕在化しやすい
• 実ユーザーの操作により、想定外の状態遷移が発見されることがある
• セキュリティ要件やログ要件の不備は、運用開始後に明らかになることがある

そのため、検収後の追完条項は、甲の救済手段として重要である。同時に、検収後のすべての不具合を乙の無償責任にすると、乙は検収の意味を失う。条項の設計は、この緊張関係を調整する作業である。

3.3 「検収後だから請求できない」は正しくない

実務上、ときどき「検収後に発覚したバグは、検収済みだから乙に請求できない」と理解されていることがある。しかし、この理解は単純化しすぎである。

検収後に発覚した不具合であっても、それが契約内容に適合しないものであり、かつ契約上または民法上の期間・通知要件を満たすなら、甲は追完等を請求し得る。逆に、検収前から存在していた問題であっても、それが契約内容に照らして不適合とはいえない場合、または甲の指図・資料・環境に起因する場合、乙に無償追完を求めることはできない。

要するに、検収後の争点は「検収したか否か」だけではなく、次の順序で検討すべきである。

1. 当該不具合は何か
2. 契約内容・仕様・受入基準との不一致は何か
3. 原因は検収前に存在したか、乙の作業に由来するか
4. 甲の指図、資料、環境、改変、誤使用に起因しないか
5. 甲は不具合を知った後、合理的期間内に具体的に通知したか
6. 契約上の責任期間内か
7. 追完が可能か、過分な費用を要しないか
8. 追完方法、費用負担、期限はどう定められているか

3.4 報酬減額・損害賠償・解除との関係

追完条項を作る際には、追完だけでなく、その後の救済も設計しなければならない。乙が追完に応じない場合、追完しても契約目的を達成できない場合、重大な障害が継続する場合、追完に過大な時間を要する場合には、甲は報酬減額、損害賠償、解除を検討することになる。

ただし、損害賠償については、契約不適合があることと乙が当然に損害賠償責任を負うことは同じではない。債務不履行による損害賠償では、契約その他の債務発生原因および取引上の社会通念に照らして、乙に帰責事由があるかが問題となる。また、企業間契約では、損害賠償の範囲、特別損害の扱い、逸失利益、間接損害、データ消失、第三者請求、損害賠償上限、故意・重過失時の例外などを別途定めることが多い。

5.1 条項名は「検収後の契約不適合に係る履行の追完」とするのが望ましい

SEOや社内説明では「検収後に発覚したバグやミスを請負人に追完させる条項」という表現が分かりやすい。しかし、契約書の条項名としては、より法的に精密な表現が望ましい。

推奨される条項名は、たとえば次のようなものである。

• 検収後の契約不適合に係る履行の追完
• 検収後に発見された不適合の修補
• 成果物の契約不適合責任
• 納入物の不具合対応および追完
• 検収後不具合の通知および是正

「バグ」や「ミス」は日常語として有用だが、法的には曖昧である。条項本文では、「契約内容に適合しない不具合」「契約不適合」「本契約、仕様書、設計書、受入基準その他甲乙が合意した文書に適合しない状態」などと表現するのがよい。

5.2 検収を無意味にしない

検収後条項を強くしすぎると、乙にとって検収の意味がなくなる。たとえば、次のような条項は避けるべきである。

このような条項は、一見すると甲に有利である。しかし、実務上は次の問題を生む。

• 乙が過大なリスクを見込み、見積額を上げる
• 乙が契約締結を拒む
• 「バグ」「ミス」「不満事項」の範囲をめぐり紛争化する
• 仕様変更や追加開発まで無償対応に含まれるか争われる
• 保守契約との境界が崩れる
• 検収手続の緊張感が失われる
• 甲側の受入テスト・資料提供・協力義務が軽視される

条項は、甲に救済を与えつつ、乙にも予測可能性を与える必要がある。

5.3 追完義務の範囲を「契約内容への不適合」に限定する

条項の出発点は、「乙が追完すべき対象は、契約内容に適合しない状態である」と定めることである。

契約内容には、契約書本文だけでなく、仕様書、要件定義書、基本設計書、詳細設計書、テスト仕様書、議事録、変更合意書、提案書、見積書、SLA、セキュリティ要件、データ移行仕様、運用設計書などが含まれ得る。ただし、これらが矛盾する場合の優先順位を定めていなければ、紛争時に「どの文書が契約内容なのか」が争われる。

したがって、追完条項とあわせて、次のような文書優先順位条項を置くことが望ましい。

5.4 「検収時に合理的に発見できなかった不適合」をどう扱うか

検収後に発覚した不具合には、次の二種類がある。

1. 検収時に通常の注意を払えば発見できた不具合
2. 検収時に合理的なテストを行っても発見困難だった不具合

後者については、甲に救済を認める必要性が高い。たとえば、年次処理、長期データ蓄積による性能劣化、特定条件下の同時処理、特定外部システム連携、潜在的な権限設定不備などである。

IPAのモデル契約関連資料でも、検査時に容易に発見できない契約不適合への対応や、検収時を起算点とする責任期間の設計、ベンダの故意・重過失時の例外、保守との役割分担等が論点として整理されている。

条項設計上は、通常の不適合については「検収完了日から○か月／○年」とし、検収時に合理的に発見困難だった不適合については、別枠で「甲が知った時から○か月以内に通知した場合」とするなど、段階的な設計が考えられる。

5.5 期間制限を明確にする

期間制限は、検収後条項の中心である。民法上、請負の契約不適合に関しては、注文者が不適合を知った時から一定期間内に通知しなければ、追完、報酬減額、損害賠償、解除を主張できないという規律がある。請負人が引渡し時または仕事終了時にその不適合を知り、または重大な過失によって知らなかった場合には、その期間制限が適用されないとされる。

もっとも、企業間契約では、民法のデフォルトルールを前提にしつつ、検収完了日から一定期間を責任期間として定めることが多い。これは、乙の保守体制、開発環境の維持、担当者確保、価格設定、検収インセンティブを考えると合理性がある。一方で、検収時に合理的に発見できない重大な不適合について、検収日から短期間で完全に遮断する条項は、甲にとってリスクが大きい。

実務上は、次のような選択肢がある。

次の比較表は、検収後バグ追完条項の基本設計で確認すべき項目を期間設計、甲のメリット、乙のメリット、注意点の列で整理したものです。契約レビューで重要なのは、各列の違いから責任範囲、手続、期限、費用負担のどこを条文に落とすべきかを読み取ることです。

7.1 第1項 ― 対象を「契約不適合」に接続する

第1項は、検収後に発見された不具合を「契約不適合」として位置づける規定である。ここでは、単に「バグ」「ミス」とせず、契約書、個別契約、仕様書、要件定義書、設計書、テスト仕様書、受入基準、変更合意書等に適合しない状態と定義している。

実務上は、契約文書が多層化しやすい。たとえば、提案書には「AIによる自動分類」と記載されているが、要件定義書では「候補提示」に弱められ、基本設計書では対象データが限定され、議事録では初期リリース対象外とされていることがある。このような場合、どの文書を基準に契約不適合を判断するかを定めていなければ、検収後の追完請求は争いになりやすい。

したがって、第1項とあわせて、文書の優先順位、変更合意の方式、議事録の効力、口頭指示の扱いを整備することが望ましい。

7.2 第2項 ― 原因を「検収前または乙作業由来」に限定する

第2項は、乙の無償追完義務の範囲を限定する規定である。検収後に発見された不具合であっても、原因が検収後の甲の改変や外部環境変更にある場合、乙が無償で対応する義務を負うとは限らない。

ここで重要なのは、「発見時期」と「原因発生時期」を区別することである。検収後に発見されたからといって、原因が検収後に発生したとは限らない。逆に、検収後に発見されたからといって、原因が検収前に存在したとも限らない。

たとえば、検収後3か月で在庫計算に誤差が出た場合、原因は、乙の実装ミスかもしれないし、甲が本番後にマスタを誤登録したことかもしれないし、外部システムの連携仕様変更かもしれない。この原因調査を経ずに費用負担を決めると、紛争化しやすい。

7.3 第3項 ― 通知は「具体的」にする

第3項は、甲の通知義務を定める。民法上も、契約不適合を知った注文者が一定期間内に通知することが重要であり、実務上も、通知が抽象的では乙が調査できない。

不十分な通知の例は、次のようなものである。

望ましい通知は、少なくとも次の情報を含む。

次の比較表は、検収後バグ追完条項の逐条ポイントで確認すべき項目を項目、内容の列で整理したものです。契約レビューで重要なのは、各列の違いから責任範囲、手続、期限、費用負担のどこを条文に落とすべきかを読み取ることです。

このように通知要件を具体化すると、甲は証拠化しやすく、乙は調査しやすい。紛争時にも、甲がいつ何を通知したかが明確になる。

7.4 第4項 ― 期間制限は案件に応じて設計する

第4項は、責任期間を定める。ここでは、通常の契約不適合について「検収完了日から12か月／24か月／36か月」という選択肢を示し、検収時に合理的な検査を行っても発見困難だった不適合について、別枠の通知期間と上限期間を設けている。

この二層構造は、実務上有用である。検収日を起算点とすることで乙の予測可能性を確保しつつ、潜在的不適合について甲の救済を残すからである。

ただし、「検収時に合理的な検査を行っても発見困難」という文言は、濫用されないように注意すべきである。単に甲が十分な検収テストをしなかった場合、担当者の確認漏れがあった場合、テストシナリオが粗かった場合まで「発見困難」とすると、検収制度が形骸化する。

実務上は、検収計画、受入テスト仕様書、テストデータ、検査結果、残課題一覧、未確認項目を記録し、「何を検収で確認し、何が合理的に未確認だったのか」を明確にしておく必要がある。

7.5 第5項 ― 故意・重過失の例外を置く

第5項は、乙が不適合を知っていた場合、または重大な過失により知らなかった場合の例外である。民法上も、請負人が不適合を知り、または重大な過失により知らなかった場合には、注文者の通知期間制限が適用されないという規律がある。

企業間契約でも、乙が重大な不具合を把握していたにもかかわらず検収を通していた場合、または専門家として通常あり得ない重大な見落としがあった場合に、短い責任期間で完全免責することは公平性を欠く。

ただし、「重過失」の範囲が広がりすぎると、期間制限の意味が失われる。条項交渉では、次のような補助的定義を置くことも考えられる。

7.6 第6項 ― 調査報告義務を明記する

第6項は、乙の調査・報告義務を定める。検収後不具合の実務では、最初から「乙が直すべきか」「甲が費用負担すべきか」が明確でないことが多い。そのため、まず調査フェーズを置くことが重要である。

調査報告には、次の事項を含めるとよい。

• 不具合の有無
• 再現性
• 影響範囲
• 暫定対応の要否
• 原因の仮説
• 追加調査の必要性
• 契約不適合に該当するかの暫定見解
• 追完方法案
• 追完予定時期
• 甲に必要な協力
• データ保全・ログ保全の必要性

特に重大障害では、原因確定前に暫定対応が必要となる。条項上、「原因確定まで乙は何もしない」とならないよう、緊急対応と費用精算の仕組みを設けておくとよい。

7.7 第7項 ― 追完方法は柔軟に定める

第7項は、追完方法を定める。ソフトウェアやシステムの追完は、建物の修補とは異なり、単一の方法に限られない。パッチ、設定変更、データ補正、回避策、再処理、再納入、文書修正など、技術的に合理的な方法が複数あり得る。

民法上も、追完方法について、注文者が一定の方法を請求した場合でも、請負人側が注文者に不相当な負担を課さないときは、異なる方法で追完できるという考え方が問題となる。IPAの整理でも、システム開発では、実際の修正方法はベンダが最も効率的な対応を知っていることがあり、甲乙協議により決めることが実務的であると整理されている。

条項では、甲の業務継続を重視しつつ、乙に技術的裁量を残すことが重要である。たとえば、甲が「全面再構築」を求めても、軽微な設定変更で同等の効果が得られるなら、乙に全面再構築を義務づけるのは過大である。他方、乙が単なるマニュアル回避策だけを提示し、根本的なデータ誤計算を放置することも許されない。

7.8 第8項 ― 重大障害には暫定対応を義務づける

第8項は、重大障害への緊急対応を定める。基幹システム停止、決済不能、顧客データ漏えいのおそれ、権限管理の重大不備、法定帳票の誤出力、在庫・会計・給与計算の重大誤りなどでは、原因の法的帰属を議論している間にも被害が拡大する。

そのため、契約書には、恒久対応と暫定対応を分けて規定することが望ましい。

次の比較表は、検収後バグ追完条項の逐条ポイントで確認すべき項目を対応、目的、例の列で整理したものです。契約レビューで重要なのは、各列の違いから責任範囲、手続、期限、費用負担のどこを条文に落とすべきかを読み取ることです。

費用負担は原因確定後に精算する方式もあり得る。緊急時に「費用負担が決まるまで対応しない」という状態を避けることが、企業法務・リスク管理上重要である。

7.9 第9項 ― 除外事由を明確化する

第9項は、乙が無償追完義務を負わない場合を列挙する。検収後の不具合では、甲側環境、外部サービス、第三者ソフト、法令改正、業務変更、運用ミスなどが原因となることが多い。これらまで乙の無償責任に含めると、乙は見積不能なリスクを負う。

一方で、除外事由を広くしすぎると、乙が本来警告すべきリスクを放置できることになる。たとえば、甲の指図が明らかに不適切で、専門業者である乙がそれを認識していたにもかかわらず黙って実装した場合には、乙が完全に免責されるべきではない。民法上も、注文者の供した材料または指図によって不適合が生じた場合の請負人免責には、請負人がその不適当を知りながら告げなかった場合の例外がある。

したがって、除外事由には「ただし、乙が不適切性を知りながら告げなかった場合を除く」という但書を置くことが重要である。

7.10 第10項 ― 甲の協力義務を置く

システム不具合の調査には、ログ、データ、環境、権限、担当者ヒアリングが不可欠である。甲が必要な協力をしなければ、乙は原因調査も追完もできない。

そのため、検収後条項には、甲の協力義務を必ず置くべきである。具体的には、次のような協力が考えられる。

• 再現環境の提供
• ログ、エラー情報、画面キャプチャの提供
• 本番データのマスキング提供
• テストアカウントの発行
• ネットワーク・クラウド設定情報の提供
• 業務担当者へのヒアリング機会
• バックアップデータの保全
• 障害発生時刻と操作内容の記録
• 外部ベンダ・クラウド事業者との連携

甲の協力義務は、乙の免責のためだけでなく、早期解決のためにも重要である。

7.11 第11項 ― 原因不明・対象外の場合の費用精算を定める

検収後の不具合では、調査の結果、乙の契約不適合ではないと判明することがある。この場合、乙の調査工数を誰が負担するかを定めていないと、紛争になる。

実務上は、次のいずれかの設計が考えられる。

次の比較表は、検収後バグ追完条項の逐条ポイントで確認すべき項目を設計、内容、向いている場面の列で整理したものです。契約レビューで重要なのは、各列の違いから責任範囲、手続、期限、費用負担のどこを条文に落とすべきかを読み取ることです。

費用精算条項がない場合、乙は調査着手をためらい、甲は対応遅延に不満を抱きやすい。契約書で処理手順を定めることが望ましい。

7.12 第12項 ― 追完後の再確認手続を置く

追完した後に、甲が確認しなければ、追完が完了したか不明確になる。そこで、追完後の再確認期間と異議通知手続を置く。

ただし、追完確認をもって、甲が他の不具合について権利を放棄したと解釈されないように注意する。修正した不具合Aの確認完了と、まだ発見されていない不具合Bの権利放棄は別問題だからである。

7.13 第13項 ― 追完不履行時の救済を接続する

追完条項は、乙が追完することを前提にしている。しかし、乙が追完しない、追完できない、追完しても契約目的を達成できないという事態もある。その場合に、報酬減額、損害賠償、解除、第三者修補費用請求などへ接続する規定が必要である。

特に甲としては、乙が対応しない場合に第三者へ修補を依頼できるか、その費用を乙に請求できるかを定めておくとよい。ただし、第三者修補を行うと原因解析が困難になり、証拠が失われることがある。条項上は、原則として乙に相当期間を与え、緊急時または乙の不対応時に第三者修補を可能にする構造が望ましい。

7.14 第14項 ― 保守契約との関係を明確にする

第14項は、極めて重要である。検収後のバグ修正と、通常の保守・改修・機能追加は混同されやすい。

たとえば、次のような作業は、契約不適合の追完ではなく、保守または追加開発に分類される可能性がある。

• 検収後に甲の業務手順が変わったため画面を変更する
• 法令改正に合わせて帳票を変更する
• 新ブラウザ対応を追加する
• 外部SaaSのAPI仕様変更に対応する
• 当初対象外だったデータ項目を追加する
• 性能要件を超えるアクセス増に対応する
• UIをより使いやすく改善する
• 甲の運用ミスで壊れたデータを復旧する

一方で、契約時に合意した動作環境・処理量・機能・セキュリティ要件を満たしていない場合は、保守契約ではなく契約不適合の追完として扱うべきである。

この境界を明確にしないと、甲は「保守費を払っているのに追加費用を請求された」と感じ、乙は「契約不適合ではない改修を無償要求された」と感じる。保守契約には、一次受付、障害切分け、SLA、問い合わせ対応、運用支援、法令改正対応、外部環境変更対応、軽微改修、追加開発の見積手続を明確に定めるべきである。

9.1 契約不適合の追完と保守は目的が異なる

契約不適合の追完は、納入時点で契約内容に適合していなかった成果物を、契約内容に適合させるための救済である。これに対し、保守は、検収後の運用を継続するためのサービスであり、問い合わせ対応、障害受付、監視、軽微修正、環境変更対応、法令改正対応、セキュリティパッチ、SLA対応などを含む。

両者は重なることもあるが、法的性質と費用負担が異なる。契約不適合の追完は、原則として乙の責任範囲であれば無償である。他方、保守は通常、月額費用または作業費用により提供される。

9.2 保守契約に含めるべき事項

検収後のバグ・ミス対応を実効化するには、保守契約に次の事項を定めるとよい。

次の比較表は、検収後バグ追完条項と保守契約の切り分けで確認すべき項目を項目、内容の列で整理したものです。契約レビューで重要なのは、各列の違いから責任範囲、手続、期限、費用負担のどこを条文に落とすべきかを読み取ることです。

保守契約がない場合、検収後の不具合対応は、契約不適合か有償改修かの二択になりやすく、現場対応が硬直化する。中長期運用を前提とするシステムでは、検収後条項と保守契約をセットで設計すべきである。

9.3 「無償保証期間」という言葉の危険性

実務では、「検収後1年間は無償保証」といった表現が使われることがある。しかし、「保証」という言葉は曖昧である。保証期間中であれば、どのような障害でも無償対応なのか、契約不適合に限るのか、甲の操作ミスや環境変更も含むのかが不明確になりやすい。

そのため、契約書では「無償保証期間」ではなく、次のように分解して定めるのが望ましい。

• 契約不適合に係る無償追完期間
• 保守サービスの提供期間
• 一次調査の無償範囲
• 甲起因・外部起因の場合の有償対応
• 緊急対応の費用精算
• 法令改正・環境変更対応の扱い

11.1 「バグ修正」と「仕様変更」は紛争になりやすい

検収後の不具合対応で最も多い紛争の一つが、「これはバグ修正か、仕様変更か」である。

甲は、現場が期待どおり使えないため「バグ」と主張する。乙は、仕様書どおり実装しており「追加要望」と主張する。この対立を防ぐには、契約内容、仕様確定手続、変更管理、議事録、検収基準を整備するほかない。

11.2 判断基準

バグ修正か仕様変更かは、次の観点から判断する。

次の比較表は、検収後バグ追完条項と仕様変更・追加開発で確認すべき項目を観点、バグ・契約不適合に傾く事情、仕様変更・追加開発に傾く事情の列で整理したものです。契約レビューで重要なのは、各列の違いから責任範囲、手続、期限、費用負担のどこを条文に落とすべきかを読み取ることです。

11.3 変更管理条項を置く

仕様変更・追加開発との境界を明確にするためには、変更管理条項が不可欠である。

変更管理が機能していないプロジェクトでは、検収後に「言った・言わない」「期待していた・聞いていない」という紛争が生じやすい。

データ移行は、検収後に問題が発覚しやすい領域である。特に、会計、人事、在庫、顧客管理、医療、金融、EC、サブスクリプション課金などでは、データ移行ミスが重大な損害につながる。

13.1 データ移行ミスの典型例

• 旧システムから新システムへの項目マッピング誤り
• 文字コード変換ミス
• 金額、税率、数量、日付、端数処理の誤り
• 顧客ID、契約ID、商品IDの紐づけ誤り
• 履歴データ、添付ファイル、ログの移行漏れ
• 重複データ、欠落データ、NULL処理の不備
• 甲が提供した元データ自体の誤り
• 本番移行直前の差分データ反映漏れ

13.2 条項上の注意点

データ移行では、甲と乙の責任分担が重要である。旧データの正確性は甲が保証し、移行仕様、変換ロジック、移行作業、検証支援は乙が負う、という分担が一般的に考えられる。

契約書では、次の事項を定めるべきである。

• 甲が提供するデータの範囲、形式、提供時期
• 乙が実施するデータクレンジングの有無
• 移行対象外データ
• 変換ルール
• サンプル検証と全件検証の範囲
• 移行リハーサル
• 本番移行時の差分反映
• 移行後の照合基準
• データ誤り発見時の補正手続
• バックアップとロールバック
• データ毀損時の責任制限

検収後のデータ移行ミスを追完対象にする場合、「乙の移行仕様違反または移行作業ミスに起因するもの」に限定し、甲提供データの誤りや甲の確認漏れについては別途扱うのが合理的である。

甲、すなわち注文者側から見ると、検収後条項の目的は、検収時に発見できなかった重大な不具合について、乙に実効的な追完を求めることである。甲側の交渉ポイントは次のとおりである。

15.1 潜在的不適合を救済対象に入れる

検収完了日から短期間で一切の責任を遮断する条項は、甲にとって危険である。特に、年次処理、決算処理、法定帳票、長期データ蓄積、セキュリティ、外部連携、ピーク処理などは、通常の受入テストで完全に検証できない。

甲側では、次のような文言を入れるべきである。

15.2 乙の調査・回答期限を定める

乙が不具合通知を受けても、対応期限がなければ、調査が後回しになることがある。甲側では、重大度に応じた初動時間、暫定対応、恒久対応計画の提出期限を定めるとよい。

例 ―

次の比較表は、甲側から見る検収後バグ追完条項の交渉ポイントで確認すべき項目を重大度、内容、初動、対応計画の列で整理したものです。契約レビューで重要なのは、各列の違いから責任範囲、手続、期限、費用負担のどこを条文に落とすべきかを読み取ることです。

15.3 保守契約に逃げ込ませない

乙が「検収後なので保守契約の有償対応です」と主張することを防ぐため、甲側では、契約不適合の追完は保守費にかかわらず無償であることを明記する必要がある。

ただし、甲側も、仕様変更や機能追加まで無償化しようとすると交渉が難航する。契約不適合と追加要望を区別する姿勢が重要である。

15.4 第三者修補権を確保する

乙が対応しない場合、甲が第三者に修補を依頼できないと、業務停止が長期化する。甲側では、相当期間を定めて催告しても乙が対応しない場合、または緊急やむを得ない場合には、第三者修補を認め、その合理的費用を乙に請求できる条項を検討する。

ただし、第三者修補前には、証拠保全、ログ保存、現状記録、乙への通知を行うべきである。第三者がコードやデータを変更すると、原因立証が難しくなるからである。

検収後の不具合紛争では、技術的な正しさだけでなく、証拠化が重要である。企業法務、内部監査、情報システム、経理、経営層は、次の資料を保全すべきである。

17.1 保全すべき資料

次の比較表は、検収後バグ追完条項を支える証拠化と内部統制で確認すべき項目を資料、意味の列で整理したものです。契約レビューで重要なのは、各列の違いから責任範囲、手続、期限、費用負担のどこを条文に落とすべきかを読み取ることです。

17.2 証拠を壊さない

障害対応では、急いで修正した結果、原因を示すログやデータが消えることがある。重大な契約不適合が疑われる場合、次の措置を検討すべきである。

• ログの退避
• データベースのスナップショット
• 画面・帳票の保存
• 操作動画の取得
• エラー発生時刻の記録
• ソースコードの該当バージョン保存
• 設定ファイルの退避
• 第三者修補前の現状記録
• 関係者ヒアリングメモ
• 外部専門家によるデジタルフォレンジック

特に、個人情報漏えい、会計誤処理、決済障害、行政報告を伴う不具合では、証拠保全と初動対応を並行して進める必要がある。

Q1. 検収後にバグが見つかった場合、必ず乙に無償修正を請求できますか。

一般的には、無償追完の対象になり得るのは、その不具合が契約内容に適合せず、乙の作業または検収前に存在した原因に由来し、契約上または民法上の通知・期間要件を満たす場合とされています。ただし、甲の指図、甲提供データ、甲の改変、外部環境変更、仕様変更要望などによって結論が変わる可能性があります。具体的な対応は、契約書、仕様書、ログ、通知経過を整理したうえで弁護士等の専門家へ相談する必要があります。

Q2. 検収した以上、甲は後から何も言えないのですか。

一般的には、検収は完成・納入・支払に関する重要な手続であり、紛争時の証拠にもなります。ただし、検収後に発見された契約不適合について、契約上または民法上の要件を満たす限り、追完等が問題となる場合があります。原因、通知時期、検収時の発見可能性によって判断が変わるため、具体的には弁護士等の専門家に確認する必要があります。

Q3. ソフトウェアにバグはつきものだから、乙は責任を負わないのですか。

一般的には、軽微な不具合があることだけで直ちに重大な契約不適合と評価されるとは限りません。ただし、合意された重要機能が動作しない、業務目的を達成できない、重大な誤処理が継続する、修補対応がされないといった事情があれば、契約不適合、損害賠償、解除が問題となる可能性があります。具体的な評価は、契約内容と技術的事実を整理して専門家へ相談する必要があります。

Q4. 追完方法は甲が指定できますか。

一般的には、甲は契約内容に適合させるための追完を求め得るとされています。ただし、システム開発では、技術的に合理的な修正方法を乙が把握していることも多く、甲乙協議により合理的な方法を定める構造が望ましいとされます。具体的な指定の可否は、条項文言、成果物の性質、費用負担、緊急性によって変わります。

Q5. 検収後の不具合対応は保守契約で処理すれば足りますか。

一般的には、保守契約は検収後の運用支援を定めるものであり、契約不適合の無償追完とは性質が異なると整理されます。ただし、初期調査、通常保守、追加開発、無償追完の境界は契約内容によって変わります。具体的には、保守範囲、SLA、原因調査、費用精算の規定を確認する必要があります。

Q6. 検収後に法令改正があった場合、乙は無償対応すべきですか。

一般的には、検収後の法令改正対応は契約不適合の追完ではなく、保守契約または追加開発の対象となることが多いとされています。ただし、契約締結時に特定の法令対応を成果物要件として合意していたのに満たしていなかった場合は、契約不適合となる可能性があります。具体的な整理は、合意時点、仕様書、変更管理の記録を確認して判断する必要があります。

Q7. 甲が検収時に十分テストしなかった場合でも、後から追完請求できますか。

一般的には、検収時に容易に発見できた不具合を合理的な検査なく見落とした場合、後から広範な無償追完を求めることは争点になり得ます。一方で、合理的な検査を行っても発見困難だった潜在的不適合は、検収後条項で救済対象とする必要性があります。具体的には、検収基準、テスト結果、発見可能性、通知時期を整理して専門家へ相談する必要があります。

Q8. 乙が原因は甲側と主張して対応しない場合、どう整理すべきですか。

一般的には、甲側は仕様書、テスト結果、ログ、再現手順、業務影響、乙の作業履歴との関係を整理し、原因調査と根拠説明を求めることが重要とされています。ただし、第三者修補や損害賠償の見通しは、証拠関係と契約条項で結論が変わります。重大障害では、証拠保全を行ったうえで弁護士等の専門家に相談する必要があります。

Q9. 乙は、原因不明の段階で調査費用を請求できますか。

一般的には、原因不明時の初期調査を保守契約内または一定時間無償とし、甲起因・外部起因・対象外と判明した場合に費用精算する方式が見られます。ただし、費用請求の可否は契約書の調査条項、保守契約、変更管理条項によって変わります。具体的には、調査範囲と費用負担の規定を確認する必要があります。

Q10. 準委任契約にも同じ条項を入れられますか。

一般的には、準委任では成果物の完成責任ではなく、善管注意義務に基づく事務処理が中心となるため、請負型の契約不適合条項をそのまま入れることには注意が必要です。ただし、納入物、報告書、設定ファイル、成果資料などの誤りの是正義務を個別に定めることは考えられます。具体的には、契約類型と成果物の位置づけを確認して専門家へ相談する必要があります。

21.1 法務担当・企業内弁護士

法務担当・企業内弁護士は、検収後条項を、契約不適合責任、損害賠償、解除、保守、仕様変更、証拠化の全体設計として見る必要がある。条項単体ではなく、契約書全体のリスク配分として整合性を確認すべきである。

21.2 外部弁護士

外部弁護士は、裁判になった場合の主張立証を意識して、契約内容、検収基準、通知、原因調査、証拠保全、損害算定を設計する。条項文言が抽象的な場合には、紛争時の解釈リスクを指摘し、具体化を支援する。

21.3 情報システム部門・IT法務担当

情報システム部門は、技術的な不具合管理と契約上の契約不適合管理を接続する役割を持つ。Jira、Backlog、GitHub Issues、Redmine等のチケット管理を、契約上の通知・対応履歴として使えるよう整備することが重要である。

21.4 内部監査・内部統制担当

内部監査・内部統制担当は、検収手続が形骸化していないか、検収権限者が明確か、証跡が残っているか、重大不具合が経営に報告されているか、支払承認と検収が適切に連動しているかを確認する。

21.5 公認会計士・税理士

公認会計士・税理士は、システム開発費、資産計上、保守費、追加開発費、障害対応費、引当、損害賠償金、税務処理に関心を持つ。検収後の不具合が重大である場合、会計上・税務上の処理にも影響し得る。

21.6 経営者・事業責任者

経営者・事業責任者は、検収後の不具合を単なる法務問題ではなく、事業継続、顧客対応、ブランド、内部統制、IT投資回収の問題として把握すべきである。契約書の一条項が、障害時の交渉力と初動速度を左右する。

• 民法（明治二十九年法律第八十九号）｜e-Gov法令検索
• 国税庁「請負の意義」
• IPA「情報システム・モデル取引・契約書（第二版）」
• IPA「情報システム・モデル取引・契約書の見直しのポイント」
• IPA「民法改正を踏まえた整理にあたって」PDF
• 経済産業省「情報システム・ソフトウェア取引トラブル事例集」PDF
• SOFTIC「判例で読み解くシステム開発紛争～事案概要と研究会検討を踏まえた解説～」PDF