Webシステムの納品から3週間後、クライアントから「ログイン機能が特定の環境でエラーになる」という報告が届いた。フリーランスエンジニアのA氏は検収完了済みと認識していたが、クライアントは「これは欠陥であり無償で修正すべきだ」と主張している。
一方、制作会社B社のプロジェクトマネージャーは、ECサイトの納品後にカート機能の動作不具合を発見した。仕様書には記載のなかったブラウザでのみ再現するが、エンドユーザーへの影響が出始めている。受託先の開発会社は「仕様書に定義のない環境での動作は保証外」と主張している。
成果物の不具合をめぐるこうしたトラブルは、フリーランス・業務委託の現場で日常的に発生する。「バグ 修正 義務」「納品後 不具合」の問題は、受発注双方の法的権利義務を正確に理解していなければ、不当な無償労働の強制あるいは正当な権利行使の放棄という二つの失敗につながる。
納品後に発覚する不具合の実態
このセクションでは、制作現場で実際に起きる不具合トラブルのパターンと、それが受発注双方にもたらす損失を整理する。
典型的な不具合トラブルのパターン
パターン1: 検収後に発覚する隠れた不具合
Webアプリケーションの検収時には正常動作を確認したが、本番環境への移行後にデータ量が増えるにつれてパフォーマンスが著しく低下するケース。検収環境と本番環境のデータ規模の差異が原因であり、受託者は「検収時には問題なかった」、発注者は「本番で使えないなら欠陥だ」と主張が対立する。
パターン2: 仕様解釈の齟齬によるバグ
「ユーザーが自由に並べ替えられる商品リスト」という仕様に対して、受託者はドラッグ&ドロップ機能のみを実装した。しかし発注者は「番号入力での並べ替えも含む」と解釈しており、納品後に「仕様を満たしていない」として修正を要求。仕様書の記載が曖昧だったため、双方の主張に根拠がある状態となった。
パターン3: 第三者環境での再現不具合
納品したスマートフォン向けUIが、発注者の顧客の特定端末モデルで表示崩れを起こすことが判明。契約書の対応環境一覧に当該モデルは含まれていないが、「サポート対象の機種で動かないのは欠陥では」と発注者は主張する。
パターン4: 運用後に顕在化する設計上の問題
リリースから6ヶ月後、セキュリティ診断の結果としてSQLインジェクション脆弱性が発見された。受託者は「開発当時のセキュリティ基準には準拠していた」と主張するが、個人情報保護の観点から発注者は損害賠償を求めている。
不具合トラブルがもたらす損失
受託者側への影響
未払い報酬の不発生リスクが最も深刻だ。「不具合が解消されるまで残金は払わない」という発注者の主張が認められた場合、完成に近い成果物に対して報酬が宙に浮いたままになる。また、無償修正対応に要する工数は直接的な機会損失を生む。修正作業に1週間費やせば、その分の売上が消える。
心理的コストも無視できない。「自分が作ったものに欠陥がある」という認識は、制作者のモチベーションに打撃を与える。不当な無償修正要求であっても、対応しなければ関係悪化や評判損失のリスクがある。
発注者側への影響
本番環境での不具合は、エンドユーザーへの直接的な影響につながる。ECサイトであれば売上機会の損失、業務システムであれば業務停止のリスクがある。修正が完了するまでの間、代替手段を用意する必要が生じ、追加コストが発生する。
受託者との交渉・訴訟には時間と費用がかかる。期待していた品質を得られなかったことへの精神的消耗も大きい。
責任の法的構造を理解する
このセクションでは、不具合責任の根本となる法的な仕組みを整理する。契約形態と瑕疵の性質が、修正義務の有無を決定する。
請負契約と準委任契約の違い
請負契約（民法632条）
請負は「仕事の完成」を目的とする契約である。Webサイト制作・システム開発・動画制作など、特定の成果物の納品を約束する場合、通常は請負契約として扱われる。
請負契約では、受託者は「契約に適合した仕事の完成」という結果を約束している。完成した仕事が契約の内容に適合しない場合（契約不適合）、発注者は追完請求・代金減額・損害賠償・契約解除の各権利を持つ（民法559条・562条以下）。
この「契約不適合責任」が、いわゆる瑕疵担保責任の現代的表現である。
準委任契約（民法656条）
準委任は「業務の遂行」を目的とする契約である。コンサルティング・継続的な運用管理・特定の結果を約束しない保守作業などが該当する。
準委任では、受託者は「善管注意義務を尽くして業務を行うこと」を約束しているにすぎず、特定の結果の保証はしていない。したがって、成果物に不具合があっても直ちに修正義務が生じるわけではなく、「相当な注意を払って作業したか」という観点から責任が評価される。
実務上の注意点
「業務委託契約書」という名称だけでは請負か準委任かは判断できない。契約書の条項、報酬の決め方（成果物完成時一括払いか月次払いか）、業務内容の実態を総合的に判断する必要がある。曖昧な場合、裁判所は実態に基づいて判断するため、後から「準委任だったから結果責任はない」と主張しても認められないリスクがある。
「仕様バグ」と「実装バグ」の区分
不具合責任を考えるうえで重要なのが、「何が原因で不具合が生じたか」という問いである。
実装バグ（受託者の責任）
仕様書に明確に定義された機能が、その定義どおりに動作しない場合を「実装バグ」と呼ぶ。「ログイン後はマイページに遷移する」と仕様書に書かれているのにエラーページが表示される、という類のものだ。これは受託者の実装上の誤りであり、原則として無償修正義務がある。
仕様バグ（発注者・双方の責任）
仕様書の定義自体が不完全・矛盾している場合を「仕様バグ」と呼ぶ。受託者は仕様書どおりに実装したものの、その仕様自体が現実の業務要件を満たしていなかった、というケースだ。
仕様バグの責任は、基本的には要件定義を担った側（多くの場合発注者、または発注者の指示で要件定義を行った受託者）にある。ただし、受託者が「この仕様では要件を満たせない」と気づきながら指摘しなかった場合、善管注意義務違反として受託者にも一定の責任が生じる可能性がある。
対応環境・前提条件の外側で起きる問題
契約書や仕様書に明記された対応ブラウザ・OS・バージョン以外の環境での不具合は、原則として受託者の修正義務の範囲外となる。ただし、「業界標準として当然対応すべき環境」について明記がない場合、争いになりやすい。
契約不適合責任の通知期間
民法566条により、発注者が契約不適合を知った時から1年以内に受託者に通知しなければ、追完請求・代金減額・損害賠償・契約解除の権利を行使できなくなる（権利失効）。
なお、「知った時から1年」であって「納品から1年」ではない点に注意が必要だ。後から発覚した不具合については、発覚後1年以内に通知することで権利を保全できる。
ただし、この1年という期間は当事者間で自由に変更できる。契約書に「検収完了後6ヶ月」「納品から1年」などと定めることが多い。受託者としては期間を短く定め、発注者としては長く定める利益がある。
受託者側の責任範囲と対処法
このセクションでは、不具合が発生した際に受託者が取るべき具体的な行動手順と、不当な無償修正要求への対処法を示す。
無償修正義務の射程を確認する
不具合の報告を受けたら、まず以下の点を確認する。
- 契約形態の確認: 請負か準委任か。請負であれば契約不適合責任が問われる可能性がある
- 不具合の性質の確認: 実装バグ（仕様どおりに動かない）か、仕様バグか、対応環境外の問題か
- 検収の有無と完了時期: 検収が完了しているか。完了しているなら、その後何ヶ月が経過しているか
- 契約書の瑕疵担保条項: 無償修正の対象・期間・除外事項が定められているか
実装バグであれば、検収後であっても原則として修正義務がある。ただし、契約書に瑕疵担保期間（例：「検収後3ヶ月」）が定められていれば、その期間が経過した後の修正は有償とする根拠となる。
不具合対応の段階的手順
Step 1: 事実確認と記録
不具合報告を受けたら、まず発生状況を詳細に確認する。再現手順、発生環境、影響範囲を書面（メール・チャット）で記録する。口頭報告は必ずメールで復唱確認を取る。
Step 2: 不具合の性質分類
実装バグか仕様バグかを技術的に分析する。仕様書・設計書・コミュニケーション記録を証拠として整理する。「仕様書のどの記述に基づいて実装したか」を明確にしておく。
Step 3: 修正義務の判断
実装バグかつ契約不適合責任の期間内であれば、無償修正義務がある。仕様バグまたは対応環境外の問題であれば、修正は有償対応として提案できる。期間外であれば、有償対応を原則としながら関係維持のための部分無償も検討する。
Step 4: クライアントへの説明と合意取得
修正義務の有無・範囲について、根拠を示した書面で説明する。有償修正の場合は見積もりを提示し、発注者の承認を得てから作業を開始する。「とりあえず見てみます」という形で始めると、後から有償と言いにくくなる。
不当な無償修正要求への対処
発注者が「すべて欠陥だ、すべて無償で直せ」という主張をしてくる場合、以下の対応を取る。
証拠の活用
仕様書、設計書、検収時のやりとり、承認メールを整理し、「受託者の義務の範囲内で完成していた」ことを証明できる書類を揃える。
代替案の提示
「無償では対応できないが、追加費用で対応できる」という提案を書面で行う。関係維持を優先する場合、「今回は特例として一部無償で対応するが、今後同様の対応は有償となる」と明示したうえで対応することもある。
内容証明・法的手段の準備
交渉が進まない場合、弁護士への相談を検討する。費用対効果が見合わない場合は、少額訴訟（60万円以下）や支払督促の活用も選択肢となる。
発注者側の権利と行使手順
このセクションでは、不具合が発生した際に発注者が持つ法的権利と、それを適切に行使するための実務手順を整理する。
発注者が持つ4つの権利
民法が定める契約不適合責任として、発注者には以下の権利がある。
1. 追完請求権（民法562条）
不具合のある部分を修正・補完するよう求める権利。「バグを直せ」という要求がこれに当たる。受託者は原則としてこれに応じる義務があるが、修正が過分な費用を要する場合は拒否できる。
2. 代金減額請求権（民法563条）
追完が不可能または受託者が追完を拒否した場合、不具合の程度に応じて代金を減額するよう求める権利。追完請求と選択的に使用する。
3. 損害賠償請求権（民法564条・415条）
不具合により損害が生じた場合、その賠償を求める権利。本番環境での障害により売上損失が生じた場合などが該当する。受託者の帰責事由が必要となる。
4. 契約解除権（民法564条・541条以下）
重大な不具合により契約目的を達せない場合、契約を解除する権利。解除には催告が必要な場合が多く、解除が認められると受領済みの報酬を返還する義務が発生しうる。
権利行使の実務手順
Step 1: 通知の早期発出
不具合を発見したら、遅滞なく受託者に書面で通知する。民法566条の「知った時から1年」のカウントが始まるため、記録に残る形での通知が重要だ。通知内容には不具合の内容・発生状況・影響範囲を具体的に記載する。
Step 2: 追完の催告
追完請求をする場合、「○月○日までに修正してほしい」と相当期間を設けて催告する。期間の長さは不具合の複雑さに応じて設定するが、一般的には1〜2週間が目安となる。
Step 3: 追完拒否・不履行の確認
催告期間が経過しても修正がなされない場合、または受託者が修正を拒否した場合、代金減額・損害賠償・契約解除への移行を検討する。この段階では法的な対応として内容証明郵便の送付が有効だ。
Step 4: 費用の保全
代金の残金がある場合、「不具合が修正されるまで残金の支払いを保留する」という対応が現実的だ。ただし、保留の根拠が明確でない場合は受託者から報酬請求を受けるリスクがあるため、弁護士に相談のうえで判断することを推奨する。
発注者が陥りやすい対応ミス
「とにかく直してくれ」という曖昧な要求
不具合の内容・影響範囲を整理せずに「全部欠陥だから全部直せ」という要求を出すと、受託者との議論が長引く。権利行使を効果的に行うには、不具合を具体的に特定し、優先度をつけて伝えることが重要だ。
通知の遅延
「後でまとめて伝えよう」という判断が、民法566条の通知期間を損なうリスクを生む。不具合を発見したら、その時点で書面で通知しておくことが権利保全の基本である。
無償修正を当然視する態度
検収完了後に発覚した不具合すべてが無償修正の対象となるわけではない。受託者の無償修正義務の範囲を超えた要求は、交渉の長期化と関係悪化を招く。発注者としても法的義務の範囲を理解したうえで、合理的な要求を行うことが最終的に得策となる。
不具合リスクを減らす契約設計
このセクションでは、不具合トラブルを未然に防ぎ、発生した場合の処理を円滑にするための契約条項設計を示す。
受託者向け契約設計のポイント
瑕疵担保期間の明確化
民法の原則（知った時から1年）に代えて、「検収完了後○ヶ月」という形で期間を明示する。フリーランスであれば「検収後3ヶ月」程度が業界標準的な設定である。ただし、フリーランス保護法の適用対象となる場合は、著しく短い期間の設定が問題となる可能性があるため注意が必要だ。
免責事項の列挙
以下の場合は受託者の修正義務が生じない旨を明記する：
- 対応環境一覧に記載のない環境での動作不具合
- 発注者または第三者による納品後の改変に起因する不具合
- 仕様書に明記のない機能・動作に関する問題
- 納品後の外部サービス・ライブラリのアップデートに起因する問題
対応環境の具体的明示
「主要ブラウザ最新版」という記述は曖昧である。「Chrome 128以上 / Firefox 130以上 / Safari 17以上 / Edge 128以上（各macOS・Windows最新版）」のように具体的なバージョンまで明記する。
有償保守契約の提案
瑕疵担保期間終了後の継続的なサポートを有償保守契約として別途締結することを提案する。「納品して終わり」ではなく継続的な関係を構築することで、収益の安定化とトラブルリスクの低減を同時に実現できる。
発注者向け契約チェックのポイント
検収プロセスの明文化
「誰が」「何を基準に」「何営業日以内に」検収を行うかを契約書に明記する。検収手順が曖昧なまま「検収完了」の証跡がないと、後で「本当に検収が完了していたか」が争点になる。
不具合発見時の手続き
不具合発見時の通知方法（書面・メール等）と、受託者の応答期限（3営業日以内等）を定める。手続きの明確化により、修正対応の遅延リスクを減らせる。
本番環境固有リスクの取り扱い
テスト環境と本番環境の差異（データ量・負荷・連携サービスの違い等）に起因して発生しうる問題について、検収環境での確認範囲と本番環境での追加確認の責任分担を明確にしておく。
双方に共通する実務慣行
仕様書の版管理
仕様の変更がある場合、版番号をつけて管理する。「最終版仕様書v2.3」が存在し、双方が同一のファイルを確認していることを記録しておくことで、「仕様書どおりに作った」という主張の根拠が明確になる。
検収チェックリストの活用
納品物の確認項目を事前にリスト化し、検収時に双方で確認する。確認済みの項目は書面上で明示することで、後から「この部分は確認しなかった」という主張を防ぐ。
コミュニケーション記録の保全
すべての指示・承認・変更依頼をメールやチャットで記録する。口頭での合意は必ずメールで確認の返信を送る習慣をつける。不具合トラブルは「言った言わない」の水掛け論になりやすく、書面による記録が最強の防御となる。
成果物の不具合をめぐるトラブルは、契約前の設計と記録管理の習慣によって大幅に予防できる。受託者は「仕様どおりに作った」と言える証拠を積み重ね、発注者は「何が問題か」を具体的に特定したうえで権利を行使する。双方が法的な根拠を理解することで、感情論でなく事実と法律に基づいた建設的な解決が可能になる。