ソフトウェア開発契約での
契約不適合責任の特殊性

ソフトウェア開発契約では、契約締結時点でシステムの細部が完全に決まっていないことが少なくありません。ユーザの業務要件、既存システムの制約、データ構造、外部システム連携、現場業務の例外処理が、開発工程を通じて具体化されます。

契約不適合の判断では、契約書本文だけでなく、プロジェクト全体の文書群が契約内容を補う資料になります。次の比較表は、どの資料がどの判断に関係するかを示すものです。資料ごとの役割を押さえることで、契約内容の根拠が単一文書に閉じないことを読み取れます。

ソフトウェアには一定程度の不具合が発生し得ます。重要なのは、技術的な意味でのバグと法律上の契約不適合を分けることです。軽微な表示崩れ、テスト工程で当然に修補される不具合、指摘後に遅滞なく修補された不具合は、直ちに重大な契約不適合を基礎づけるとは限りません。

一方で、合意された主要機能の未実装、仕様書上必須の処理誤り、業務中核機能の重大な誤処理、性能要件の大幅な未達、セキュリティ仕様違反、重大なデータ移行不備、修補不能または長期化する不具合は、契約不適合と評価されるリスクが高くなります。

工程ごとの契約類型も責任判断を変えます。次の比較表は、工程・業務ごとに典型的な契約類型と責任の焦点を整理したものです。請負か準委任かで何を約束した契約なのかが変わるため、工程ごとの違いを読み取ることが重要です。

ユーザの協力義務も品質を左右します。業務要件、既存システム情報、データ、承認、受入テストをユーザが適時に提供しなければ、遅延や品質低下が起きやすくなります。他方で、ベンダが要件不備やリスクを認識しながら警告しなかった場合は、説明義務、助言義務、プロジェクトマネジメント義務が問題になります。

次の一覧は、責任帰属を検討するときに見落としやすい要素を示します。左右の当事者を単純に非難するのではなく、情報提供、警告、承認、記録のどこに問題があったかを読み取ることが重要です。

検収とは、ユーザが成果物を確認し、契約上の納入物として受け入れる手続です。ソフトウェア開発では、検収は単なる事務処理ではなく、報酬支払、納入完了、契約不適合責任期間の起算、保守フェーズ移行の基準になります。

検収条項では、納入物の範囲、検査期間、検査方法、合格基準、不合格時の通知方法、不合格理由の具体化、再納入、再検査、みなし検収、検収後の契約不適合責任、保守契約への移行を定めます。

次の判断の流れは、納入から保守移行までに何を確認するかを表します。順番どおりに記録を残すことで、検収済みの効果、残課題の扱い、後日発見された不具合の位置づけを読み取りやすくなります。

検収済みでも、検収時に発見困難な重大不具合、特定条件下で発生する障害、セキュリティ脆弱性、データ移行の欠落などが後から問題になることがあります。他方で、合理的に発見できた不具合を検収時に指摘せず後日広範に主張する場合は、信義則、検収合意、責任期間条項、過失相殺、協力義務違反が問題になります。

みなし検収は、ユーザの検査遅延により報酬支払が不当に遅れることを防ぐために有効です。ただし、重大な契約不適合をベンダが知りながら黙っていた場合や、納入物が契約目的を達成できないほど不完全な場合まで機械的に免責するとは限りません。

情報成果物作成委託では、取適法上、検査の有無にかかわらず受領後60日以内に定めた支払期日までの支払が問題になります。契約不適合責任と検収・支払を設計する際は、民事契約上の合意だけでなく、受領、検査、支払期日の規制も確認する必要があります。

契約不適合の最も実務的な救済は追完です。ソフトウェアでは、代替物の引渡しよりも、バグ修補、パッチ提供、設定変更、データ修正、設計修正、追加テスト、代替運用の提供が中心になります。

次の一覧は、契約不適合責任で検討される四つの救済手段を、ソフトウェア開発の場面に置き換えて整理したものです。救済手段ごとに効果と難点が異なるため、どの段階でどの手段が現実的かを読み取ることが重要です。

追完では、ある不具合を修正すると別機能に影響が出ることがあります。契約書では、修補後の再テスト、影響範囲確認、リグレッションテスト、修補期限、暫定回避策、ユーザ協力、緊急対応を定める必要があります。

損害賠償では、直接かつ通常の損害に限定するか、逸失利益・間接損害・特別損害を除外するか、上限を委託料相当額や個別契約額にするか、故意・重過失、秘密保持違反、個人情報漏えい、知財侵害、セキュリティ違反を上限除外にするかが中心論点になります。

解除は影響が大きいため、次の手順で事実と証拠を整理することが望ましいです。この判断の流れは、解除を感情的な決裂ではなく法的効果を伴う手続として扱うために重要です。各段階で契約条項との対応と証拠を残すべきことを読み取ってください。

近年のソフトウェア開発契約では、セキュリティ、データ移行、クラウド基盤、OSS、外部APIが契約不適合責任の中心論点になりやすくなっています。脆弱性、認証不備、権限管理不備、暗号化不備、ログ不足、クラウド設定ミス、秘密情報・個人情報漏えいは、技術問題にとどまらず債務不履行や第三者請求にもつながります。

次の一覧は、セキュリティ・データ・クラウド領域で契約不適合責任に発展しやすい要素を示します。リスクの種類ごとに契約で決めるべき責任分界点が異なるため、どの要素を仕様書・別紙・保守契約に落とすべきかを読み取ってください。

データ移行では、旧システムのデータ欠損・重複・不整合が新システムに移ってしまうことがあります。次の比較表は、移行工程で確認すべき責任分担を示します。旧データ、移行ツール、仕様定義、ユーザ確認、ベンダ実装のどこに問題があるかを分けて読み取ることが重要です。

第三者ソフトウェアやクラウド基盤については、ベンダがすべての外部要因を保証できるとは限りません。第三者ソフトウェアの一覧、ライセンス、費用負担、OSSライセンス遵守、脆弱性情報の監視範囲、クラウド障害時の責任分担、API仕様変更時の対応費用、サポート終了・バージョンアップ対応を定める必要があります。

条項例は、考え方を示すための素材であり、そのまま利用するものではありません。実際の契約では、取引規模、システム重要度、契約類型、交渉力、業法、取適法、個人情報、知財、セキュリティ要件に応じて調整します。

次の一覧は、契約不適合責任を扱う主要条項と、その条項で何を決めるべきかを整理したものです。条項名だけを置くのではなく、参照文書、例外、協議手続、証拠化の範囲を読み取ってください。

契約不適合の定義では、ユーザの指示、提供資料、提供データ、利用環境、第三者サービス、承認済み変更に起因する不適合をどこまで除外するかが重要です。ただし、ベンダが不適当性を知りながら告げなかった場合は別扱いにすることで、ユーザ起因と警告義務のバランスを取ります。

検収条項では、不合格通知を具体化させることが重要です。使えない、期待と違うという抽象的な通知では、修補範囲が不明確になります。追完条項では、必ずしもユーザが求める方法だけが唯一の追完方法ではなく、代替措置もあり得ることを明記します。

納品物にバグがあれば、必ず契約不適合ですか。

一般的には、ソフトウェア開発では一定の不具合発生が技術的に想定されるため、バグの存在だけで直ちに契約不適合と評価されるとは限らないとされています。ただし、合意された仕様・品質からの逸脱、業務影響、修補可能性、修補対応の適切性、不具合の重大性によって結論が変わる可能性があります。具体的な評価は、契約書、仕様書、テスト結果、障害記録を整理したうえで弁護士等の専門家へ相談する必要があります。

検収したら、後から不具合を主張できませんか。

一般的には、検収済みでも、検収時に発見困難な重大不具合や、ベンダが知りながら告げなかった不具合については、契約不適合責任が問題となる余地があります。ただし、契約上の保証期間、通知期間、みなし検収、保守条項、ユーザの検査義務によって結論が変わる可能性があります。具体的な対応は、検収記録と障害記録を整理したうえで弁護士等の専門家へ相談する必要があります。

契約書に検収後6か月とある場合、民法の知った時から1年は使えませんか。

一般的には、商取引では契約上の特約が重視されるとされています。ただし、特約の文言、故意・重過失の有無、潜在不具合、一般の債務不履行、消滅時効、信義則、個別事情によって解釈が変わる可能性があります。具体的な見通しは、契約条項と発見・通知の時期を整理したうえで弁護士等の専門家へ相談する必要があります。

ユーザが要件を決めきれなかった場合でも、ベンダは責任を負いますか。

一般的には、ユーザの資料・指示・承認に起因する不適合については、ユーザ側の責任や過失相殺が問題となる可能性があります。他方で、ベンダが専門家として要件不備やリスクを認識しながら警告しなかった場合は、説明義務、助言義務、プロジェクトマネジメント義務が問題となる可能性があります。具体的な判断は、議事録、課題管理表、承認履歴を整理したうえで弁護士等の専門家へ相談する必要があります。

アジャイル開発でも契約不適合責任はありますか。

一般的には、アジャイル開発でも不適切な成果物、重大な実装ミス、セキュリティ不備、説明義務違反、善管注意義務違反が問題となる可能性があります。ただし、固定仕様への一致ではなく、合意されたプロセス、バックログ、スプリント成果、レビュー、品質基準、プロダクトオーナーの役割、技術的助言義務が中心となることがあります。具体的な整理は、契約類型とスプリント記録を確認したうえで弁護士等の専門家へ相談する必要があります。

セキュリティ脆弱性は契約不適合ですか。

一般的には、契約で定めたセキュリティ仕様、適用基準、脆弱性診断条件、業務上必要な安全性を満たしていない場合、契約不適合または債務不履行が問題となる可能性があります。ただし、リスク水準、コスト、運用責任、クラウド設定、パッチ適用、OSS脆弱性管理の分担によって結論が変わります。具体的な対応は、仕様書、診断結果、運用記録を整理したうえで弁護士等の専門家へ相談する必要があります。

法令・公的資料

• e-Gov 法令検索「民法」
• 法務省「民法（債権関係）の改正に関する説明資料－主な改正事項－」
• 経済産業省「情報システム・ソフトウェア取引トラブル事例集」
• 公正取引委員会「取適法」
• 公正取引委員会「よくある質問コーナー（取適法）」

モデル契約・研究資料

• IPA「情報システム・モデル取引・契約書（第二版）」
• IPA「情報システム・モデル取引・契約書からの見直しのポイント」
• IPA「情報システム・モデル取引・契約書（アジャイル開発版）」
• 一般財団法人ソフトウェア情報センター システム開発紛争判例研究会「判例で読み解くシステム開発紛争」