フリーランスエンジニアに業務委託した機能にバグが見つかり、修正を依頼したところ「準委任契約なので完成保証の義務はない」「修正には追加費用がかかる」と返されて、対応に行き詰まっていませんか。手元の契約書を見ても、どちらの言い分が正しいのか判断がつかず、このまま受注者の言葉を信じて泣き寝入りするしかないのかと不安を抱えている発注担当者は少なくありません。
業務委託のバグ責任は、法律の条文を読んでも一筋縄ではいきません。「請負か準委任か」という契約の種類で結論が真逆になり、さらに2024年11月に施行されたフリーランス新法が、バグ発生時に発注者が取れる行動に新しい制約を加えています。社内に法務担当がいない中で、これらを正確に切り分けるのは簡単ではありません。
そのうえ、調べても出てくるのは「契約書を整備しましょう」「弁護士に相談しましょう」という抽象的なアドバイスばかりで、今まさにバグを抱えた発注者が「今日、受注者に何をどう要求すればよいか」という肝心な部分にはなかなかたどり着けません。
本記事は、フリーランスエンジニアに業務委託している発注企業の担当者の視点で、成果物にバグが出たときに発注者が責任をどこまで問えるのか、そして泣き寝入りしないために今すぐ取れる具体的な行動を解説します。請負と準委任での責任の違い、準委任でも発注者に認められる権利、見落としがちな発注者側の「逆責任」リスク、フリーランス新法の影響、そしてバグ発見当日から使えるアクションチェックリストまで、順を追って整理していきます。
業務委託エンジニアのバグ責任は「契約の種類」で真逆になる
業務委託の成果物にバグや欠陥が出たとき、誰がどこまで責任を負うかは、まず契約が「請負契約」なのか「準委任契約」なのかで根本的に変わります。受注者が口にする「準委任だから責任を負わない」という説明が部分的にしか正しくないことを理解するために、両者の違いから押さえていきましょう。
請負契約は成果物の完成義務があり契約不適合責任が発生する
請負契約は、受注者が「仕事の完成」を約束し、発注者がその完成に対して報酬を支払う契約です。完成した成果物が契約の内容に適合していなければ、受注者は契約不適合責任を負います。
契約不適合責任とは、引き渡された成果物の種類・品質・数量が契約内容に適合していない場合に、発注者が受注者に対して、修正（追完）・報酬減額・損害賠償・契約解除を請求できる責任のことです。2020年4月施行の改正民法で、それまでの「瑕疵担保責任」という名称が「契約不適合責任」に改められました（マネーフォワード クラウド契約 / 契約不適合責任の解説）。つまり請負契約であれば、納品されたシステムにバグがあった場合、発注者は契約不適合を理由に修正などを正面から要求できます。
準委任契約は完成保証はないが善管注意義務を負う
一方の準委任契約は、受注者が「一定の業務を遂行すること」を約束する契約で、成果物の完成そのものを約束するものではありません。報酬の対象が「成果物」ではなく「業務の遂行」であるため、原則として契約不適合責任は適用されません（Workship ENTERPRISE / 準委任契約と契約不適合責任）。
ただし、ここで重要なのは「準委任だから責任ゼロ」ではないという点です。準委任契約の受注者は、業務を遂行するにあたって「善管注意義務」（善良な管理者としての注意義務）を負います。専門家として通常期待される注意を払って業務を遂行する義務であり、これを怠ってバグを作り込んだ場合には、債務不履行を理由とした損害賠償の対象になり得ます。つまり「完成は保証しないが、プロとして当然払うべき注意を怠ってよい」わけではありません。
フリーランスエンジニアへの委託は準委任が多い
フリーランスエンジニアへの業務委託は、実務上「準委任契約」の形を取っているケースが大半です。月額固定で稼働してもらう、スプリント単位で開発を進めるといった働き方は、成果物の完成を一括で請け負う請負契約よりも準委任契約になじむためです。
自社の契約がどちらかを見分けるには、契約書の表題ではなく中身を確認してください。「成果物の完成」「検収」「納品物の引渡し」を報酬の条件としていれば請負の性質が強く、「業務の遂行」「稼働時間」「役務の提供」を中心に据えていれば準委任の性質が強いと判断できます。表題が「業務委託契約書」となっていても、実態がどちらかで責任の所在は変わります。受注者の「準委任だから」という主張をうのみにせず、まず自社の契約書の中身を確認することが、対処の出発点になります。
準委任契約でバグが出たとき、発注者に認められること
「準委任契約には契約不適合責任が適用されない」と聞くと、発注者は何も要求できないように感じてしまいます。しかし、準委任契約であっても発注者が行使できる権利は存在します。「準委任だから何もできない」という諦めは正確ではありません。
「善管注意義務違反」を根拠に修正・損害賠償を求められる
準委任契約の受注者が善管注意義務を怠った結果としてバグが生じた場合、発注者は債務不履行に基づく損害賠償を請求できます。たとえば、一般的なエンジニアであれば当然行うべきテストを怠った、明らかに既知の不具合を見逃した、合意した仕様を無視した実装をしたといったケースでは、善管注意義務違反が問われる余地があります。
ポイントは「結果として完成しなかったこと」ではなく「プロとして払うべき注意を払ったか」が判断基準になる点です。受注者が「準委任だから完成義務はない」と主張しても、業務の進め方そのものに専門家としての注意の欠如があれば、その責任は別に問えます。受注者と交渉する際は、「完成しなかった責任」ではなく「善管注意義務を尽くしたと言えるのか」という観点で論点を立てると、準委任契約でも法的根拠を持って向き合えます。
「成果完成型準委任」で変わること・変わらないこと
2020年4月施行の改正民法では、準委任契約が「履行割合型」と「成果完成型」の2種類に整理されました（パーソル / 成果完成型準委任の解説）。成果完成型は、業務の成果に対して報酬を支払う形態で、アジャイル開発やスプリント単位の納品ではこの形が使われることがあります。
注意したいのは、成果完成型であっても受注者が負う義務はあくまで善管注意義務であり、成果物の「完成義務」や契約不適合責任が発生するわけではない、という点です（前掲・Workship ENTERPRISE）。成果完成型は「成果が出なければ報酬が発生しにくい（成果と報酬が結びつく）」という点で発注者に有利な側面はありますが、「成果完成型だから請負と同じようにバグの修正を当然要求できる」と考えるのは誤りです。自社の契約がアジャイル前提の成果完成型であっても、責任追及の土台は善管注意義務であることを押さえておきましょう。
バグ修正費用は誰が負担するか
業務委託のバグ修正費用を誰が負担するかは、最終的には「契約書の記載」と「バグの原因がどちらにあるか」で決まります。
請負契約で受注者の作り込んだバグであれば、契約不適合責任に基づき受注者負担での修正（追完）を求められます。準委任契約であっても、善管注意義務違反が認められるバグであれば、受注者の負担で対応を求める根拠になります。一方で、後述するように発注者側の仕様変更や指示が原因のバグは、発注者負担となる可能性が高くなります。
つまり「準委任だから一律に発注者負担」でも「請負だから一律に受注者負担」でもなく、契約の種類と原因の所在を組み合わせて判断します。だからこそ、後述するように原因を切り分ける証拠（仕様書・検収記録・指示のやり取り）を残しておくことが、費用負担の交渉で決定的に効いてきます。システム開発全般の修正費用負担の考え方については、システム開発のバグ修正費用は誰が負担？もあわせてご確認ください。
見落としがちな落とし穴 — 発注者側に過失が認定される「逆責任」リスク
ここまでは受注者に責任を問う視点で解説してきましたが、業務委託のバグトラブルには、発注者自身が見落としがちな落とし穴があります。発注者の行動が原因で、逆に発注者側に過失が認定されるケースです。「自分たちの発注の仕方に問題があったのでは」という不安を抱えている方は、ここを冷静に点検しておく必要があります。
仕様変更・承認遅延が「発注者の帰責事由」になる
開発の途中で発注者が仕様を変更したり、確認・承認を遅らせたりした結果として不具合が生じた場合、その原因は発注者側にあると判断される可能性があります。受注者が指定された仕様どおりに実装したにもかかわらず、その仕様自体が誤っていた、あるいは発注者の指示変更が混乱を招いたというケースでは、バグの責任を受注者に転嫁することは難しくなります。
請負契約においても、民法は注文者の指図によって生じた不適合について、原則として請負人は契約不適合責任を負わないと定めています。発注者の指示や仕様が原因のバグについては、受注者を一方的に責められないという前提を理解しておきましょう。
テスト環境の未整備・受領遅滞が修正請求を難しくする
発注者がテスト環境やテストデータを提供しなかった、検収を長期間放置した、納品物の受領を正当な理由なく遅らせたといった事情があると、修正請求や責任追及の場面で発注者側が不利になることがあります。
特に検収を放置したまま時間が経過すると、「いつ・どの状態で・どんな不具合があったか」を立証することが難しくなります。また、契約不適合責任には期間の制限があり、不適合を知った時から1年以内に通知しないと、追完・減額・損害賠償・解除の請求ができなくなるのが原則です（マネーフォワード クラウド契約 / 民法566条の解説）。バグに気づきながら通知を先延ばしにすることは、自ら権利を手放すことにつながりかねません。
逆責任を避けるための記録・指示の残し方
逆責任を避けるには、発注者側のやり取りを記録として残しておくことが最も有効です。仕様の合意内容、変更の指示とその理由、承認・検収のタイミング、テスト環境の提供状況などを、口頭ではなくメールやチケット、チャットのログなど後から確認できる形で残してください。
これらの記録は「発注者側に落ち度がなかったこと」を示す証拠になると同時に、バグの原因が受注者側にあることを切り分ける材料にもなります。なお、本記事の内容は一般的な法的枠組みの整理であり、個別のケースで責任の所在がどう判断されるかは事実関係によって変わります。具体的な判断が必要な場合は、契約書を持参して弁護士に相談することをおすすめします。
2024年施行・フリーランス新法がバグ対応に与える影響
フリーランスエンジニアへの業務委託でバグが出たとき、発注者の行動には2024年に施行された新しい法律が影響します。「特定受託事業者に係る取引の適正化等に関する法律」、いわゆるフリーランス新法です。2024年11月1日に施行され（政府広報オンライン / フリーランス新法）、フリーランスに業務を委託する発注者に新たな義務を課しています。競合する解説記事の多くは民法の話で止まっていますが、バグ対応の現場ではこの新法を無視できません。
発注者が負う義務のうち「バグ対応」に関わるもの
フリーランス新法は、フリーランスに業務委託する発注者に対して、取引条件の明示、報酬の支払期日の設定と遵守などを義務付けています。なかでもバグ対応に直結するのが報酬の支払期日に関するルールです。発注者は、成果物を受け取った日から数えて60日以内のできる限り短い期間内で報酬の支払期日を設定し、その期日内に報酬を支払わなければならないとされています（前掲・政府広報オンライン）。
「バグがあるから支払いを止める」という対応は、この支払期日のルールとの関係で慎重に検討する必要があります。また、契約条件は書面（電磁的方法を含む）で明示する義務があるため、バグ対応の前提として、そもそも委託時の条件が書面化されているかも確認しておきましょう。
成果物の受領拒否禁止と、修正要求の適法な期限設定の両立
フリーランス新法は、発注者がフリーランスに責任がないにもかかわらず成果物の受領を拒否することや、報酬を減額することを禁止しています（前掲・政府広報オンライン）。バグを理由に「受け取らない」「報酬を払わない」と一方的に対応することは、受注者に帰責事由がない場合、新法違反となるおそれがあります。
一方で、受注者の善管注意義務違反によるバグについて、合理的な修正期限を設けて追完を求めること自体は、正当な権利の行使です。重要なのは「受注者に責任があるバグについて、根拠を示して期限を区切って修正を求める」のと「責任の所在を確かめないまま一方的に受領や支払いを拒む」のとを切り分けることです。前者は適法な要求、後者は新法違反のリスクがあると整理して動いてください。
違反時のリスク
フリーランス新法に違反した場合、公正取引委員会・中小企業庁・厚生労働省による行政措置の対象となります。違反が確認されると、助言・指導から始まり、報告徴収・立入検査、是正の勧告、そして勧告に正当な理由なく従わない場合には命令、その事実の公表へと段階的に進みます。命令に違反した場合や検査を拒否した場合には、50万円以下の罰金が科される可能性があります（マネーフォワード クラウド契約 / フリーランス新法の罰則）。
バグへの対応に追われるあまり、感情的に受領拒否や支払い停止に踏み切ると、自社が新法違反として社名公表のリスクを負う事態にもなりかねません。発注者責任全般の論点については業務委託で発注者が負う責任とリスクもあわせてご確認ください。
バグ発見翌日にやること — 発注者のアクションチェックリスト
ここからが本記事の核心です。バグを発見した発注者が、法律用語に振り回されず今すぐ実行できる手順を、ステップ形式で整理します。難しい法的判断を後回しにしてでも、まず証拠を固めて冷静に通知することが、その後の交渉を有利に進める出発点になります。
Step1 — 不具合を再現手順つきで書面記録・通知する
最初にやるべきは、口頭やチャットの一言で済ませず、不具合を客観的な記録として残すことです。次の項目をそろえて文書化してください。
- 発生している不具合の内容（どの機能が、どう動かないか）
- 再現手順（どの操作をすると、どの環境で発生するか）
- 発生日時と、それを確認した担当者
- 期待される動作と、実際の動作の差分
- スクリーンショットやエラーログなどの客観的な証拠
これらをまとめて、メールなど日時が残る形で受注者に通知します。前述のとおり契約不適合責任には「知った時から1年以内」という通知期間の制限があるため、発見したら速やかに通知することが、権利を保全するうえで重要です。バグ・不具合・エラーの深刻度の切り分けについてはバグ・不具合・エラーの違いとは？が参考になります。
Step2 — 合理的な修正期限を設定して追完を請求する
不具合を通知したら、いつまでに修正してほしいかという合理的な期限を設定して、追完（修正）を請求します。「合理的な」とは、不具合の規模や難易度に照らして受注者が現実的に対応できる範囲という意味で、過度に短い期限を一方的に押し付けるのは避けます。
このとき、修正が契約上の義務として求められるものなのか、それとも善意の対応をお願いするものなのかを、自社の契約の種類（請負か準委任か）と原因の所在を踏まえて整理しておくと、受注者との認識のズレを防げます。期限と請求内容は必ず書面で残してください。
Step3 — 修正されない場合に報酬減額か契約解除を選択する
設定した期限を過ぎても修正されない、あるいは修正が不十分な場合は、次の選択肢を検討します。
- 報酬の減額: 成果物の不適合の程度に応じて報酬の減額を求める
- 契約の解除: 不適合が重大で契約の目的を達成できない場合に契約を解除する
- 損害賠償: 不具合によって発注者に損害が生じた場合に賠償を求める
請負契約であればこれらは契約不適合責任に基づく権利として行使でき、準委任契約であっても善管注意義務違反を根拠に損害賠償や解除を検討できます。ただし、フリーランス新法の観点から、受注者に責任がないバグについて一方的に減額・受領拒否をすることは避け、根拠を明確にしたうえで選択してください。
Step4 — 損害賠償請求の進め方と限界
バグによって自社に具体的な損害（システム停止による逸失利益、復旧費用など）が生じた場合は、損害賠償を請求できます。ただし、フリーランス個人への損害賠償請求には現実的な限界があることも理解しておく必要があります。
法人の開発会社と異なり、フリーランス個人は損害賠償の支払い能力が限られていることが多く、高額な賠償を求めても実際の回収が難しいケースがあります。また、契約書に損害賠償の上限額が定められている場合は、その範囲に制限されます。損害賠償は最後の手段と位置づけ、まずは現実的に回収可能な範囲での修正・減額交渉を優先し、それでも解決しない場合に弁護士へ相談する流れが実務的です。
同じトラブルを繰り返さない — 契約書に盛り込むべき条項
バグトラブルへの最善の対処は、起きる前に防いでおくことです。次回以降の業務委託契約で、ここまで見てきたリスクを事前に抑えるために盛り込んでおきたい条項を整理します。すでにトラブルを経験した発注者にとっても、再発防止の指針になります。
バグ修正範囲と無償対応期間の明示
どこまでをバグとして扱い、どの範囲を無償で修正対応するのかを契約書に明記します。納品（検収）後の一定期間（保証期間）を設け、その期間内に発見された不具合は無償で修正する、といった取り決めを入れておくと、修正費用をめぐる「誰が負担するのか」という争いを未然に防げます。
損害賠償の上限額と直接損害限定条項
損害賠償の範囲を、賠償額の上限や「直接損害に限る」といった形であらかじめ定めておきます。これは受注者保護の条項に見えますが、フリーランス個人に過大な賠償を求めても回収が難しい現実を踏まえると、双方にとって現実的な落としどころを先に決めておく意味があります。
フリーランス新法に準拠した受領・支払い・修正期限の設定
成果物の受領、報酬の支払期日（受領から60日以内）、修正要求の期限について、フリーランス新法に準拠した形で契約書に落とし込みます。これにより、バグ対応の局面で発注者が新法違反のリスクを負わずに権利を行使できる土台を整えられます。
検収基準・仕様書の合意
何をもって「完成」「合格」とするかの検収基準と、実装すべき内容を定めた仕様書を、契約の一部として明確に合意しておきます。検収基準と仕様書は、バグが発生したときに「契約内容に適合しているか」を判断する基準そのものであり、責任の所在を切り分ける最大の証拠になります。
発注者の指示・仕様起因の免責範囲を限定列挙する
発注者の指示や仕様が原因の不具合について受注者を免責する条項は一般的ですが、その範囲を限定列挙しておくことをおすすめします。免責範囲が曖昧だと、受注者側のミスまで「発注者の指示が原因」と主張される余地を残してしまいます。
契約書に盛り込むべき項目の全体像は業務委託契約書に必要な13項目、エンジニア委託に特有の条項はエンジニアの業務委託契約書で押さえる条項で詳しく解説しています。
まとめ — フリーランスエンジニアへの委託でバグリスクを最小化する
業務委託エンジニアのバグ責任を発注者がどこまで問えるかは、抽象的な不安のままにせず、順を追って切り分ければ判断できます。本記事の要点を整理します。
- バグ責任は「請負か準委任か」で真逆になる。請負は契約不適合責任、準委任は善管注意義務が土台
- 準委任でも「責任ゼロ」ではない。善管注意義務違反を根拠に修正・損害賠償・解除を求められる
- 修正費用の負担は「契約の種類」と「バグの原因の所在」の組み合わせで決まる
- 発注者の仕様変更・承認遅延・受領遅滞は「逆責任」につながる。記録を残して原因を切り分ける
- フリーランス新法により、受注者に責任のないバグでの一方的な受領拒否・報酬減額は違反リスクがある
- バグ発見時は「書面記録・通知 → 修正期限の設定 → 減額・解除の選択 → 損害賠償」の順に動く
- 再発防止には、保証期間・賠償上限・検収基準・免責範囲を契約書に明記しておく
そして、バグリスクを根本的に下げる最も確実な方法は、トラブルが起きにくいエンジニアを最初に選ぶことです。技術力だけでなく、不具合発生時のコミュニケーションや責任範囲への理解がしっかりしたエンジニアと契約できれば、ここまで解説した対処手順を発動する場面そのものを減らせます。委託前のリスク低減から契約後の品質保証まで、業務委託の品質をどう担保するかを体系的に整理した資料を用意しています。バグ責任の不安を抱えたまま次の発注に進む前に、あわせてご活用ください。
