リリース後の不具合、無償対応と有償対応の境界線

「リリースしたばかりのシステムで不具合が出た。開発会社に連絡したら『それは仕様変更にあたるので、別途お見積りになります』と言われた」——ひとり情シスや総務兼任のシステム担当者から、この種の相談を受けることは珍しくありません。無償で直してもらえると思っていたものに費用を請求されると、開発会社への不信感につながりますし、逆に本来は追加費用が発生して当然の依頼を「不具合だから無償で」と主張してしまうと、今度は開発会社との関係がこじれます。

この記事では、リリース後に見つかった不具合が「無償対応の範囲」なのか「有償対応（追加費用が発生する範囲）」なのかを見分けるための考え方を、民法の契約不適合責任の条文に基づいて整理します。あわせて、境界線上のグレーゾーンに入ったときの交渉の進め方、開発会社との認識のズレを防ぐための事前準備についても解説します。

結論を先に言うと、境界線を分けるのは「仕様書・要件定義書に書かれていた内容と違うかどうか」です。書かれていた内容と実際の動作が食い違っていれば、原則として無償修正を求められる不具合です。一方、仕様書に記載がなく、後から「こうであってほしかった」と気づいた内容は、たとえ業務上は不具合のように感じられても、契約上は追加の作業（＝有償）として扱われるのが基本の考え方です。

よくあるすれ違いの具体例

境界線の話に入る前に、実際にどのようなやり取りでトラブルが起きるのか、具体的な場面をイメージしておきましょう。

• 発注者「注文一覧の合計金額が実際の請求額と1円ずれている。直してほしい」→ 開発会社「消費税の端数処理の仕様について、仕様書に明記がなかったため、今回の実装が正しいという認識でした。仕様変更として対応します」
• 発注者「スマートフォンで見ると一部のボタンが押しにくい。使いにくいので直してほしい」→ 開発会社「レスポンシブ対応の詳細な基準は要件定義に含まれていなかったため、追加の調整は別見積もりになります」
• 発注者「エクスポートしたCSVの文字化けを直してほしい」→ 開発会社「文字コードの指定がなかったため、標準のUTF-8で出力しています。Shift-JISへの変更は仕様変更として承ります」

これらの例に共通するのは、いずれも「仕様書に明記されていなかった」という開発会社側の説明です。発注者からすれば「そんな細かいことまで書く発想がなかった」というのが正直なところでしょうが、開発会社側の立場に立つと、明記されていない事項について独自の判断で実装せざるを得ない場面は実際に多く存在します。どちらか一方が悪いというより、要件定義・仕様策定の段階での「書かれていない領域」が、リリース後にそのままトラブルとして表面化する構図です。

無償対応と有償対応、何が境界線になるか

まず押さえておきたいのは、この境界線が担当者の感覚や開発会社の善意で決まるものではなく、契約の内容によって決まるという点です。感情的な「直してほしい」という気持ちと、契約上「直してもらえる」かどうかは、残念ながら別の話になります。

境界線を作る基準は大きく2つあります。

• 契約内容との適合性：仕様書・要件定義書・画面設計書などの合意文書に記載された内容と、実際の動作が異なっているかどうか
• 原因の所在：不具合の原因が開発会社側の実装ミスにあるのか、発注者側が提供した情報（データ、指示内容）にあるのか

このうち特に重要なのが1つ目です。中小企業のシステム開発では、要件定義書や仕様書が簡素なことも多く、「書かれていないこと」が実は非常に多いという実態があります。書かれていないグレーゾーンにこそ、無償・有償のトラブルが集中します。

「動かない」「エラーが出る」といった明確な不具合は判断に迷いませんが、「使いにくい」「もっとこうだったら」という要望に近い不具合ほど、無償か有償かの判断が難しくなります。

以降では、この境界線の法的な根拠と、実務での判断の進め方を順番に見ていきます。

法的な根拠：民法が定める「契約不適合責任」

「無償で直してもらえる不具合」の法的な裏付けとなるのが、民法が定める契約不適合責任です。2020年の民法改正で、それまでの「瑕疵担保責任」という呼び方から「契約不適合責任」に変わり、考え方も整理されました。

システム開発の請負契約（成果物の完成を約束する契約）に関しては、民法第636条・第637条が担保責任の基本ルールを定めています。

民法第636条（請負人の担保責任の制限）

請負人が種類又は品質に関して契約の内容に適合しない仕事の目的物を注文者に引き渡したとき（その引渡しを要しない場合にあっては、仕事が終了した時に仕事の目的物が種類又は品質に関して契約の内容に適合しないとき）は、注文者は、注文者の供した材料の性質又は注文者の与えた指図によって生じた不適合を理由として、履行の追完の請求、報酬の減額の請求、損害賠償の請求及び契約の解除をすることができない。ただし、請負人がその材料又は指図が不適当であることを知りながら告げなかったときは、この限りでない。

条文を読み解くと、次の2点が分かります。

1. 「契約の内容に適合しない」場合に、注文者（発注者）は修正（履行の追完）を請求できる
2. ただし、発注者が提供した材料や指示が原因で不具合が起きた場合は、原則としてこの請求権が制限される

つまり、「契約の内容に適合しない」＝仕様と違う、という状態が無償修正を求められる不具合の出発点であり、逆に発注者側が渡したデータや指示に原因がある不具合は、開発会社の責任とは言えないということです。

システム開発契約では、成果物完成後に一定期間動作させて確認する「準委任契約」ではなく「請負契約」が使われることが多く、この請負契約に民法第636条・第637条が適用されます。準委任契約の場合はやや考え方が異なりますが、この点は後述します。

契約不適合責任には「通知期限」がある

無償修正を求められる不具合であっても、いつまでも権利を主張できるわけではありません。民法第637条には期間の制限が定められています。

民法第637条（目的物の種類又は品質に関する担保責任の期間の制限）

前条本文に規定する場合において、注文者がその不適合を知った時から一年以内にその旨を請負人に通知しないときは、注文者は、その不適合を理由として、履行の追完の請求、報酬の減額の請求、損害賠償の請求及び契約の解除をすることができない。

2 前項の規定は、仕事の目的物を注文者に引き渡した時（その引渡しを要しない場合にあっては、仕事が終了した時）において、請負人が同項の不適合を知り、又は重大な過失によって知らなかったときは、適用しない。

要点は次の通りです。

この条文で注意したいのは、起算点が「不具合を知った時」であり、「リリースした時」や「検収した時」ではないという点です。リリースから半年後に初めて気づいた不具合であれば、そこから1年間は通知が可能ということになります。

ただし、この1年という期間は民法上のデフォルトルールに過ぎません。実際の契約書では、この期間を短縮する特約（たとえば「検収完了後3ヶ月以内」など）が定められているケースが多くあります。SOW（作業範囲記述書）や契約書に、契約不適合責任に関する独自の期間の定めがないかを、まず確認することをおすすめします。

• 契約書に契約不適合責任の期間について記載があるか確認する
• 記載があれば、そちらが民法の規定に優先する（民法は任意規定のため）
• 記載がなければ、民法第637条の「知った時から1年」が適用される

不明な点があれば、契約書の解釈は弁護士等の専門家に確認することをおすすめします。特に、記載された期間が極端に短い、あるいは発注者に一方的に不利な内容になっている場合は、専門家の判断を仰ぐべき領域です。

無償対応になるケース：3つの典型パターン

ここからは、実務でよく遭遇する「無償対応になりやすいケース」を具体的に見ていきます。

パターン1：仕様書通りに動作しない

もっとも分かりやすい無償対応のケースです。仕様書や要件定義書に「入力フォームで必須項目が未入力の場合はエラーメッセージを表示する」と明記されているにもかかわらず、実際にはエラーが出ずに保存できてしまう、といった状態です。

書かれた仕様と実際の動作の間に明確な差異があるため、これは契約内容に適合しない状態＝不具合であり、開発会社に無償修正を求めやすいケースです。

パターン2：一般的に期待される品質水準に達していない

仕様書に明記されていなくても、「そのシステムとして通常備えているべき機能・品質」に達していない場合も、契約不適合と評価される余地があります。たとえば、大量データを登録すると画面が固まって操作不能になる、特定のブラウザで致命的な表示崩れが起きる、といったケースです。

ただし、この「通常期待される水準」の判断には幅があり、開発会社との見解が分かれやすい領域でもあります。次章で扱うグレーゾーンの典型例です。

パターン3：発注者側に原因がないバグ・エラー

システムの内部処理のロジックミス、想定していた入力パターンでの異常終了など、発注者側が提供したデータや指示に起因しない不具合は、開発会社側の実装上の問題として無償対応の対象になりやすいものです。

これら3つのパターンに共通するのは、「仕様書に書かれた内容、または通常期待される品質」と「実際の動作」のギャップが、発注者側の行為に起因していないという点です。

無償対応になりやすいケースかどうかを自己判断するための簡易チェックリストとして、以下を確認してみてください。

• 仕様書・要件定義書・設計書のいずれかに、該当する動作についての記載があるか
• その記載と、実際にシステムが動いている内容が異なっているか
• 不具合の原因が、発注者側から渡したデータ・指示・設定に起因していないか
• 開発会社が納品時点で気づいていた、あるいは通常の注意を払えば気づけたはずの不具合か

上記の項目に多く当てはまるほど、無償対応を求められる可能性は高くなります。ただし、これはあくまで実務上の目安であり、最終的な法的判断ではありません。金額の大きい交渉になりそうな場合は、契約書の写しを持って弁護士等の専門家に相談することをおすすめします。

有償対応になるケース：3つの典型パターン

一方で、以下のようなケースは「不具合」ではなく「追加の作業依頼」として扱われ、有償対応になりやすいものです。

パターン1：仕様書に記載のない機能追加の依頼

「検索機能はあるが、絞り込み条件をもっと増やしてほしい」「一覧画面に新しい列を追加してほしい」といった依頼は、たとえ業務上あると便利であっても、契約時点の仕様書に含まれていなければ、追加開発（＝有償）として扱われるのが一般的です。

パターン2：運用開始後の業務要件変更に伴う修正

システムをリリースしてから半年後に部署の業務フローが変わり、それに合わせてシステムの動作を変更したい、といったケースです。これはシステム側の欠陥ではなく、外部環境（業務要件）の変化への対応にあたるため、有償の仕様変更として扱われます。

パターン3：発注者側が提供したデータ・環境に起因する不具合

発注者が渡したマスターデータに誤りがあり、それが原因で計算結果がおかしくなっていた、発注者側のネットワーク環境の設定変更によって連携先のシステムと通信できなくなった、といったケースです。民法第636条が定める通り、発注者が供した材料や指示に起因する不具合は、開発会社の担保責任の対象外となるのが原則です。

無償・有償を分ける2つの表を、あわせて整理しておきます。

判断に迷うグレーゾーン：よくある3つの論点

無償・有償のどちらとも言い切れない、判断の分かれやすいケースを3つ紹介します。

論点1：「常識的に考えて」という主張のすれ違い

発注者側は「システムなら当然こう動くはず」と考えていても、仕様書には明記されておらず、開発会社側は「仕様書通りに作った」と主張する、というすれ違いです。

この場合、まず確認すべきは仕様書・要件定義書・議事録などの合意文書に、該当する動作についての記載や言及がないかです。打ち合わせの議事録に「〇〇のような動作を希望する」という発言記録が残っているだけでも、交渉材料になります。記載や記録が一切ない場合は、残念ながら「発注者の期待」にとどまり、契約上の請求は難しくなります。

論点2：非機能要件（性能・セキュリティなど）の不足

「表示速度が遅い」「同時アクセスに弱い」といった、機能そのものではなく品質に関わる不満は、仕様書に具体的な数値目標（たとえば「1画面の表示は3秒以内」など）が記載されていない限り、契約不適合と主張するのが難しい領域です。

非機能要件は要件定義の段階で数値化されにくく、後からトラブルになりやすいポイントです。今回のリリースで数値目標が定められていなかった場合は、次回以降の発注時に、性能・セキュリティ・可用性などの非機能要件をできる限り具体的な数値で仕様書に落とし込んでおくことをおすすめします。

論点3：検収を終えた後に見つかった不具合

すでに検収が完了し、検収書に押印済みであっても、契約不適合責任の主張自体は可能です（民法第637条の「知った時から1年」はこの検収完了後も適用されます）。ただし、検収前に「まだ完成していない」と主張するのに比べ、検収後は「契約内容とどう違うのか」を発注者側が具体的に示す必要があり、立証のハードルはやや上がります。検収の進め方そのものについては、この記事の後半で紹介する関連記事で詳しく扱っています。

開発会社から「有償です」と言われたときの交渉の進め方

境界線がグレーな状態で開発会社から有償対応を提案された場合、感情的に反発するのではなく、次のステップで冷静に進めることをおすすめします。

1. 根拠を確認する：開発会社が「有償」と判断した根拠（仕様書のどの記載に基づくものか）を、具体的に示してもらう
2. 自社の記録を確認する：仕様書・要件定義書・打ち合わせ議事録・メールのやり取りを見返し、該当する記載や発言がないか確認する
3. 記載がある場合：その記載を根拠に、無償対応を改めて依頼する
4. 記載がない場合：契約上は有償の可能性が高いことを踏まえたうえで、業務への影響度に応じて、有償でも対応してもらうか、次回のリニューアル時まで見送るかを判断する
5. 金額・工数を確認する：有償対応で合意する場合は、見積もり（工数・単価）を書面で提示してもらう

以下のように、感情的な表現を避け、事実ベースで確認するメールや文面を心がけると、開発会社側とのやり取りがスムーズに進みます。

「ご提示いただいた見解について確認させてください。今回の事象は、要件定義書のP.〇〇に記載の『〇〇』という内容と異なる動作になっているという理解なのですが、こちらは契約内容に適合しない不具合という扱いにはならないでしょうか。もし該当する記載が見当たらないということであれば、その旨も教えていただけますと幸いです。」

このように、「なぜ有償だと考えているのか」「自社としてはどの記載を根拠に無償だと考えているのか」を、双方が明示しながら会話すると、感情的な対立に発展しにくくなります。

有償対応の見積もりが妥当かを確認する視点

交渉の結果、有償対応で合意する場合でも、提示された見積もりをそのまま鵜呑みにする必要はありません。以下の視点で内容を確認することをおすすめします。

• 工数の内訳が示されているか：「一式10万円」のような丸めた金額だけでなく、調査・設計・実装・テストといった作業ごとの工数（人時・人日）が示されているか
• 影響範囲の説明があるか：今回の修正が、システムの他の機能にどう影響するのか（テスト対象範囲）についての説明があるか
• 既存の保守契約の範囲外である理由：すでに保守契約を締結している場合、なぜ今回の対応が保守契約の範囲に含まれないのかの説明を求める

金額の妥当性そのものを厳密に判断するのは難しいものですが、内訳が不透明なまま高額な見積もりが提示された場合は、遠慮なく詳細を尋ねる、あるいは他の開発会社にセカンドオピニオンとして相談することも選択肢に入ります。保守契約自体の費用感を把握しておきたい場合は、システム保守費用の相場も参考になります。ただし、セカンドオピニオンを求める際は、既存の契約書に守秘義務や競業に関する制約がないかを確認したうえで進めてください。

社内での意思決定：有償対応を進めるかどうかの判断材料

開発会社との交渉と並行して、社内でも「この有償対応にお金をかけるべきか」の判断が必要になります。ひとり情シスや総務兼任の担当者は、この判断を一人で抱え込みがちですが、以下の観点を整理しておくと、経営層への説明や稟議がスムーズになります。

1. 業務への影響度：放置した場合、業務が止まる・数字が誤るなど、実害がどの程度あるか
2. 発生頻度：毎日発生する不具合か、年に数回程度の限定的な事象か
3. 代替手段の有無：システムを直さなくても、手作業や別の方法で回避できるか
4. 金額と社内予算：見積もり金額が、緊急対応として承認を得やすい金額か、稟議が必要な金額か

実害が大きく、代替手段もない不具合であれば、有償であっても速やかに対応を依頼すべき場面です。逆に、発生頻度が低く、手作業で回避できる程度の不具合であれば、次のシステム更新のタイミングにまとめて対応する、という判断も現実的な選択肢です。すべての不具合に即座にお金をかけるのではなく、優先順位をつけて判断する視点を持つことが、限られた予算の中で情シス業務を回すうえで重要になります。

開発会社とのやり取りがこじれたときのエスカレーション

根拠を示しても開発会社側が納得せず、話が平行線をたどる場合は、担当者同士のやり取りだけで解決しようとせず、双方の上位者を交えた話し合いに切り替えることも検討してください。開発会社の窓口担当者だけでは判断できない金額や、契約解釈に関わる内容であれば、開発会社側の営業責任者やプロジェクトマネージャーに相談を上げてもらうよう依頼するとよいでしょう。自社側も、情シス担当者だけで抱え込まず、上長や法務担当（いる場合）に状況を共有し、組織として対応する体制を整えることをおすすめします。

準委任契約の場合は考え方が異なる

ここまでは請負契約を前提に説明してきましたが、準委任契約（成果物の完成を約束せず、一定水準の業務遂行を約束する契約）の場合、民法上の請負の担保責任（第636条・第637条）はそのままは適用されません。

準委任契約では、開発会社は「善良な管理者の注意をもって業務を行う義務（善管注意義務）」を負っており、この義務に違反した場合に債務不履行として損害賠償等の責任を問う、という構成になります。「納品物が仕様通りでない」という請負的な発想よりも、「業務の遂行過程に落ち度があったかどうか」が問題になる点が異なります。

準委任契約で開発を進めているプロジェクトでリリース後の不具合が見つかった場合、「無償修正の義務」という形での主張はしづらく、実務上は当事者間の協議（追加の業務委託として対応してもらう、あるいは元々の業務範囲に含まれていたと交渉する）で解決するケースが多くなります。契約形態がどちらなのかは、契約書の名称だけでなく、実際の契約条項の内容（成果物の完成義務が明記されているか）で判断する必要があるため、迷う場合は契約書を確認するか、弁護士等の専門家に相談することをおすすめします。

トラブルを未然に防ぐための3つの事前準備

境界線をめぐるトラブルは、リリース後に対処するよりも、契約前・開発中に予防線を張っておくほうがはるかにコストがかかりません。

• 仕様書・要件定義書の記載を厚くする：「当然分かるだろう」と思う動作こそ、明文化しておく。特に異常系の挙動（不正な入力があったときの動作など）は漏れやすい
• 契約不適合責任の期間を契約書で確認する：民法のデフォルト（知った時から1年）が短縮されていないか、契約締結前に確認する
• 保守契約の対応範囲を確認する：リリース後の保守フェーズに入る場合、保守契約の中で「不具合修正」と「追加開発」がどう線引きされているかを、事前に確認しておく

特に3つ目は見落とされがちです。開発契約が完了し、保守契約に移行した後で不具合が見つかると、「これは保守契約の範囲内か、別途見積もりが必要な追加開発か」という新たな境界線の問題が発生します。保守契約書に「軽微な不具合修正は月額料金に含む」「仕様変更を伴う修正は別途見積もり」といった線引きが明記されているかを、契約前に確認しておくことをおすすめします。

さらに、保守契約の中には「不具合修正は無償、ただし月あたりの対応工数に上限を設ける」という形態も存在します。この場合、上限を超えた分は有償になるため、無償・有償の境界線が「不具合かどうか」だけでなく「その月の対応工数がどれだけ残っているか」という運用上の要素にも左右されます。保守契約を結ぶ際は、対応工数の上限の有無と、上限を超えた場合の扱いについても確認しておくとよいでしょう。

開発会社を選ぶ段階から、この境界線トラブルを見据えておくことも有効です。初回の打ち合わせや契約交渉の際に、「リリース後に不具合が見つかった場合、無償修正の対象範囲と期間はどう定義されますか」と直接質問し、その回答を契約書に反映してもらうよう依頼することで、後々の認識のズレを大きく減らせます。この質問に対して曖昧な返答しかできない、あるいは「その都度判断します」としか答えない開発会社である場合、今後のプロジェクト運営でも同様の曖昧さが続く可能性があるという、開発会社選定の判断材料としても活用できます。

まとめ：境界線は「仕様書との差異」で判断する

リリース後の不具合が無償対応か有償対応かを判断する際の軸は、以下の通りです。

• 仕様書・要件定義書に記載された内容と実際の動作が異なる → 無償対応（契約不適合）の可能性が高い
• 記載がなく、後から気づいた要望や機能追加 → 有償対応（追加開発）になりやすい
• 発注者側が提供したデータ・指示に原因がある → 開発会社の責任とは言えない
• 契約不適合の通知は「知った時から1年以内」が民法上のデフォルトだが、契約書の特約で短縮されている場合がある

判断に迷うグレーゾーンでは、感情的な主張ではなく、仕様書・議事録・メールなどの記録を根拠に、開発会社と事実ベースで対話することが解決への近道です。契約書の解釈や、金額の大きい交渉が必要な場面では、早めに弁護士等の専門家へ相談することも検討してください。

次回は、検収の段階で不具合をどう見つけ、どう報告すればスムーズに対応してもらえるかについて、具体的なチェックポイントと報告文の書き方を扱います。すでに検収を控えている方は、あわせてご覧ください。