SaaS・開発委託契約の知財補償条項はどこまで必要？第三者IP侵害が起きたときの責任分担

株式会社IPリッチのライセンス担当です。SaaSを導入したり、外部ベンダーへシステム開発を委託したりするとき、契約書に「第三者の知的財産権を侵害しないことを保証する」「侵害請求があればベンダーが補償する」といった条項を求めることがあります。しかし、どこまで広く保証させれば安全なのか、逆に提供側としてどこまで引き受けるべきなのかは簡単ではありません。

知財を収益化するうえでも、第三者権利との衝突は事業価値に直結します。自社技術をライセンスしたり売却したりする場面では、権利侵害の有無や既存契約上の責任がデューデリジェンスで確認されます。株式会社IPリッチが運営するPatentRevenueは、日本国内の特許を無料登録し、売却・ライセンス募集につなげるサービスです。知財を事業資産として扱うなら、取得する側だけでなく、技術を提供する側も「第三者IP侵害が起きた場合に誰が何を負担するか」を契約段階で明確にしておく必要があります。

知財補償条項は、単に「ベンダーが全部責任を負う」と書けばよいものではありません。対象となる権利の範囲、侵害請求を受けたときの通知、訴訟防御の主導権、和解への同意、修正・代替・利用停止・返金などの救済、責任上限との関係、発注者が指定した仕様や素材による侵害の扱いまで設計しなければ、いざというときに機能しません。

中小企業庁の知的財産取引に関するガイドラインでは、第三者の知的財産権を侵害しないことに係る保証責任や、その調査費用の負担について、目的物の仕様決定で発注者と受託側が果たした役割等に応じて適切に分担し、一方へ例外なく転嫁しない考え方が示されています。2026年6月に経済産業省・公正取引委員会等が公表した知財取引指針も、知的財産権・ノウハウ・データの取引全般について適切な取引環境を整える考え方を示しています。契約の強さは「保証文言を広くすること」だけではなく、誰がリスクをコントロールできるかに合わせて責任を配分することにあります。

この記事では、SaaS・開発委託契約で知財補償条項を設計するときの論点を、発注者側・提供者側の双方から整理します。

「第三者IP侵害」をひとまとめにしない

最初に確認すべきなのは、何の権利を対象にするかです。

SaaSやシステム開発では、特許、著作権、商標、営業秘密、場合によっては第三者ライセンス契約違反など、異なるリスクが混在します。これらをすべて「知的財産権」とだけ書き、同じ責任を課すと、想定外の範囲まで補償義務が広がる可能性があります。

たとえば、ベンダーが独自に開発したソフトウェアが第三者の著作権を侵害しているケースと、発注者が指定した画像素材やライブラリを組み込んだ結果、ライセンス条件に違反したケースでは、責任の原因が異なります。

また、特許侵害は、著作権侵害のように他人の成果をコピーしたかだけで判断するものではありません。独自開発であっても、第三者特許のクレームを実施すれば侵害問題が生じ得ます。そのため「自社で独自に作ったので第三者権利を侵害しません」という説明だけでは、特許リスクへの回答にはなりません。

契約では、対象権利を列挙するのか、一定の権利を除外するのか、利用地域や用途を限定するのかを、サービスや成果物の性質に合わせて決めます。

「非侵害保証」と「第三者請求への補償」は分けて考える

知財条項では、保証と補償を混同しないことが重要です。

保証条項は、成果物やサービスが第三者権利を侵害していないことなどを契約上の約束として定めます。一方、補償条項は、第三者から請求を受けた場合に、誰が防御し、どの費用や損害を負担するかを定めます。

無制限の非侵害保証を置くと、提供者は自分が知り得なかった第三者権利まで広く責任を負う可能性があります。特に特許は膨大で、すべての国・すべての利用態様について完全な非侵害を保証することは現実的でない場合があります。

そのため実務では、利用地域・用途を限定したり、第三者請求が実際に発生した場合の防御・代替措置を中心に設計したりします。発注者側は「保証が弱い」と感じることがありますが、重要なのは、問題が起きたときに事業を止めずに済む仕組みです。単に広い保証文言を獲得するより、侵害請求があったときの対応手順と救済を明確にする方が実効性のある場合があります。

仕様を誰が決めたかで責任分担は変わる

知財補償を考えるとき、最も重要な事実の一つが仕様決定です。

発注者が詳細な仕様、アルゴリズム、画面、部品、素材、OSS、連携先サービスなどを指定し、ベンダーはその指示どおり実装しただけという場合、第三者権利との衝突をすべてベンダーへ負わせるのは合理的でないことがあります。

逆に、ベンダーが技術選定から設計まで一貫して担当し、自社の標準SaaSとして多数の顧客へ提供しているなら、ベンダー側の方が侵害回避をコントロールしやすい領域が広くなります。

中小企業庁のガイドラインでも、第三者知財を侵害しないことの保証や調査費用について、目的物の仕様決定で当事者が果たした役割等に応じて適切に分担する考え方が示されています。契約交渉では、「どちらが強い立場か」だけでなく、「誰がそのリスクを避けられるか」を確認することが重要です。

補償対象から除外する場面を具体化する

提供者が知財補償を引き受ける場合でも、すべての侵害請求を対象にするのではなく、一定の除外を設けることがあります。

代表的なのは、発注者が提供した素材や仕様に起因する場合です。発注者が第三者の画像、データ、ソースコード、設計情報を提供し、それが原因で侵害が生じたなら、提供者だけに責任を負わせるのは不合理です。

また、契約で想定していない改変、指定外の製品との組合せ、提供者が認めていない用途、修正版を提供した後も古いバージョンを使い続けたことによる問題などを除外対象とすることもあります。

ただし、除外条項を広く書きすぎると、補償条項自体が実質的に機能しなくなります。「他製品と組み合わせた場合はすべて除外」とすると、SaaSの通常利用自体が他サービスとの連携を前提としているケースでは、発注者にとって意味がありません。除外は、実際の利用方法と照らし合わせて決める必要があります。

侵害通知を受けたら誰が主導するかを先に決める

補償条項で見落とされやすいのが、第三者から警告状や訴状を受け取った後の手続です。

まず、発注者が提供者へどの時点で通知するのかを決めます。通知が遅れた場合に補償が直ちに消滅するのか、それとも遅延によって実際に不利益が生じた範囲で調整するのかも設計の余地があります。

次に、防御の主導権を誰が持つかを決めます。提供者が費用を負担するなら、弁護士選任や訴訟戦略を一定程度コントロールしたいと考えるのが自然です。一方、発注者にとっては、自社ブランド、主要顧客、事業継続に影響するため、すべてを提供者へ任せることは難しい場合があります。

そこで、提供者が防御を主導しつつ、発注者へ合理的な情報提供を行う、重要な和解には発注者の同意を必要とする、といった設計を検討します。

和解条項では「金銭」だけでなく事業制約を見る

第三者IP紛争の和解は、単に賠償金を払って終わるとは限りません。

相手方から、特定機能の停止、顧客への通知、製品回収、ライセンス条件への同意、将来の販売制限などを求められることがあります。そのため、「提供者は自由に和解できる」とだけ定めると、発注者の事業に重大な制約が生じる可能性があります。

発注者側では、自社に金銭以外の義務を課す和解、責任を認める和解、サービス継続に重大な影響を与える和解について、事前同意を求めることを検討します。提供者側では、発注者が合理的理由なく和解を拒否し続け、訴訟費用だけが増える状態を避けるため、同意を不合理に留保しないといった調整も考えられます。

最も重要なのは「使い続けられるか」という救済

SaaSや基幹システムでは、第三者権利侵害が認定されたとき、損害賠償より「明日から使えなくなる」ことの方があ深刻な場合があります。

そこで知財補償条項では、提供者が一定の選択肢をとれるようにします。典型的には、第三者から必要なライセンスを取得して利用継続を可能にする、非侵害となるようサービスや成果物を修正する、同等機能の代替物へ置き換える、といった対応です。

それでも合理的に継続できない場合に、契約解除、未利用期間分の返金、移行支援などを定めます。

発注者側では「補償額はいくらか」だけでなく、「代替措置が事業要件を満たすか」「データ移行できるか」「業務停止期間をどうするか」を確認することが重要です。重要度の低いツールなら利用料相当の返金で十分な場合もありますが、基幹システムでは返金だけでは損失を補えません。

責任上限との関係を曖昧にしない

多くのSaaS契約・開発契約には、損害賠償責任の上限があります。たとえば、一定期間に支払った利用料や委託料を上限とする設計です。

そこで問題になるのが、知財補償も一般の責任上限に含めるかです。

発注者側は、第三者訴訟の費用が契約金額を大きく上回る可能性があるため、知財侵害については責任上限の対象外にしたいと考えます。提供者側は、無制限責任を引き受ければ一件の紛争で事業継続が危うくなるため、一定の上限を求めます。

解決策は一つではありません。一般損害より高い別上限を設ける、特定の知財侵害だけ上限対象外にする、故意・重過失の場合のみ別扱いにするなど、事業規模とリスクに応じて設計します。

特許調査費用まで当然に提供者負担としない

発注者が「第三者特許を侵害しないことを保証してほしい」と求めると、提供者は特許調査をどこまで行うべきかという問題が生じます。

特許調査は、対象国、技術分野、製品機能、検索範囲によって費用が大きく変わります。すべての国のすべての第三者権利について完全な調査を行うのは現実的ではありません。

そのため、契約前に、どの国を対象にするか、どの機能を重点的に調べるか、調査費用を価格に含めるか、発注者側の既存FTO結果を共有するかなどを決めます。発注者が特定仕様を指定した場合は、その仕様に関する調査を共同で行う選択肢もあります。

OSS・第三者コンポーネントは別枠で確認する

SaaSや開発成果物には、オープンソースソフトウェアや第三者ライブラリが含まれることが一般的です。

ここでは「第三者IP侵害」だけでなく、ライセンス条件の遵守が重要になります。表示義務、ソースコード提供義務、再配布条件などが問題になるため、単純な非侵害保証とは別に、利用している第三者コンポーネントの管理方法を確認します。

発注者側では、OSS一覧やSBOMの提供をどこまで求めるか、重大なライセンス条件がある場合の通知、脆弱性対応と知財対応をどう分けるかを検討します。提供者側では、発注者が指定したライブラリや、発注者自身が追加したコンポーネントまで自社補償の対象にしないよう整理します。

契約締結前は「第三者から警告状が来た翌日」を想像する

知財補償条項を確認するときは、まず対象権利を確認します。次に、対象地域と利用態様、仕様決定の主体、通知と防御、和解同意、救済、責任上限、除外を順に確認します。

調達側では、そのSaaSやシステムが止まったら何が起きるかを整理します。代替サービスへ移行できるのか、顧客データを取り出せるのか、切替えにどの程度の時間がかかるのかを確認します。そのうえで、知財侵害請求が起きた場合に必要なのが、訴訟費用の補償なのか、利用継続ライセンスなのか、迅速な代替提供なのかを決めます。

提供側では、引き受ける責任と価格をセットで考えます。広い知財保証を求められれば、そのためのFTO、外部弁護士レビュー、第三者ライセンス取得、保険などのコストが発生します。低価格のSaaSに無制限の知財補償を付ければ、契約採算が崩れる可能性があります。

SaaS・開発委託契約の知財補償では、「強い発注者が広い保証を取れば安全」「提供者はできるだけ免責すればよい」という発想では、長期的に安定した契約になりません。誰が仕様を決め、誰が第三者部品を選び、誰が侵害回避をコントロールできるのか、問題が起きたとき誰が最も効率的に防御・修正できるのかを見て責任を割り振ることが重要です。

契約締結前に確認すべき最も具体的な問いは、「第三者から警告状が来た翌日、誰が何をするのか」です。その答えが契約書から読み取れないなら、保証文言が広くても実務上は不十分です。通知、防御、和解、修正、代替、返金、責任上限を一つの流れとして設計することが、機能する知財補償条項につながります。

（この記事はAIを用いて作成しています。）