このページの結論
IP補償は、範囲、除外、手続、救済、上限の五つを決めて組み立てます。
補償を通常の賠償の上限の内側に置くか別枠にするかで、顧客の自己負担は大きく変わります。
OSSは、使っているものの台帳と、利用者に渡す形によって義務が変わります。
あなたが決めるのはどれ？
よくある誤り
- 否認だけを書いて、請求は利用者が解決すると定める。法人の顧客の法務が最初に修正を求める条項です。標準の型を先に用意しておきます。
- 補償を「一切の損害」と書く。範囲も上限も決まらず、保険にも上流にも回せない約束になります。
- 手続と救済の順序を書かない。顧客の独断の示談の求償や、停止か継続かの判断の遅れにつながります。
まず確かめる3点
御社の事業に合わせて書類を作成します。
ご相談とお見積りは無料です。内容に合わせた詳しいご提案書をお送りします。
無料チェックは毎日5組限定です。1書類につき24時間以内に問題点を回答します。修正案は付きません。
結論：IP補償は「範囲・除外・手続・救済・上限」の五つを決め、OSSは「台帳」と「配る形かどうか」で義務が変わる
SaaSの提供者が法人の顧客と契約するとき、顧客の法務担当者が早い段階で確認する条項の一つが、知的財産権の侵害に関する扱いです。知的財産権とは、著作権・特許権・商標権・営業秘密などの総称です。顧客が「このサービスを使っていたら、第三者から権利侵害だと言われた」という請求を受けたとき、提供者が顧客に代わって対応し、費用を持つのか。この約束を補償（英語でindemnificationといい、本稿では「IP補償」と書きます）といいます。規約に「第三者の知的財産権を侵害しないことを保証しません」と否認だけを書いている例は多く、それで足りると考えられがちですが、法人の顧客が相手になると、そのままでは通らないことが少なくありません。
もう一つの論点がOSS（オープンソースソフトウェア）です。OSSとは、ソースコードが公開され、定められたライセンス条件のもとで誰でも利用・改変・再配布できるソフトウェアのことです。SaaSの内部には多くの場合OSSが使われていますが、ライセンスの種類と、そのソフトウェアを利用者に渡す形によって、提供者が負う義務は大きく変わります。条件を守らなければ、ライセンスの許諾の範囲を外れた利用となり、著作権の侵害を主張される原因になります。IP補償とOSSは、別々の話に見えて、同じ請求の入口になります。
整理する点は五つです。
- 補償の範囲：どの権利、どの地域の請求を対象にし、何を負担するか（確定した賠償額、和解金、防御の費用）を書きます。
- 除外：顧客が入れたデータ、改変、他の製品との組合せ、指定した仕様、無償版などを外します。広すぎると補償が空になり、書かなければ無限定になります。
- 手続：通知、防御の主導、和解の同意を決めます。ないと、顧客が独断で示談した金額を請求される争いが起きます。
- 救済：権利を取得する、侵害しない形に差し替える、できなければ機能を止めて前払金を返す、という順序を書いておきます。
- 上限との関係：補償を通常の賠償の上限の内側に置くのか、別枠にするのか、上限なしにするのかを決めます。ここが書かれていないと、補償と責任制限の条項が互いに打ち消し合います。
OSSについては、(1)使っているOSSの名称・版・ライセンスの台帳を持つこと、(2)利用者に渡す形（サーバの中だけか、ブラウザやアプリやコンテナで渡すか）を把握すること、(3)その結果を規約と顧客への説明に反映することが基本です。このページは提供者側の立場で書いています。顧客の資料に起因する請求を顧客に補償させる側の書き方は責任制限と補償の条項、生成AIの出力に固有の問題は生成AI機能付きSaaSの契約条項で扱っています。
なぜ契約に書くのか：権利者の請求は、顧客にも提供者にも届く
SaaSの機能が第三者の権利を侵害していると権利者が考えたとき、請求の宛先は提供者だけとは限りません。まず提供者に対しては、著作権であれば、侵害の停止や予防を請求できます（著作権法112条1項）。侵害の行為によって作られた物の廃棄など、必要な措置も求められます（同条2項）。損害賠償は、故意又は過失があれば民法709条で請求でき、著作権については損害額を推定する規定があります（著作権法114条）。
顧客に対してはどうでしょうか。ブラウザ越しに使うだけの顧客が、直接の侵害者とされる場面は多くありません。他方、アプリ、エージェント（顧客の環境に置いて動かす小さなプログラム）、SDK（顧客が自分のシステムに組み込む部品）、オンプレミスやコンテナでの提供のように、顧客の端末やサーバに複製物が置かれる形では、顧客自身が使用者になります。プログラムの著作物の著作権を侵害して作られた複製物を業務上コンピュータで使う行為は、使用する権原を取得した時に情を知っていた場合に限り、侵害とみなされます（同法113条5項）。つまり、知らずに導入した顧客がみなし侵害に当たりにくい一方で、提供者が差止めを受ければ、顧客の業務は止まります。顧客が補償を求める実質的な理由は、賠償額より、業務が止まる危険にあることが多いのです。
特許権にも触れておきます。プログラムの著作物の保護は、プログラム言語、規約及び解法には及びません（同法10条3項）。機能の仕組みそのものを守っているのは、主に特許権や契約による制限です。特許権の侵害は、差止めの請求に侵害者の故意や過失を要しないのが原則で、警告が顧客に直接届くこともあります。
権利者の請求と補償の流れ（導入型のSaaSの例）
下流への約束は、上流から受けられる補償の範囲と合わせないと、提供者が差額を負担します。
契約に何も書かないと、顧客と提供者の間の負担は、債務不履行（民法415条）や不法行為（同法709条）を前提とした争いになります。双方が共同の不法行為を行ったとされれば、各自が連帯して賠償する責任を負います（同法719条1項）。権利者に対して連帯して責任を負うことと、二者の間で最終的に誰がどれだけ負担するかは別の問題で、後者を事前に決めておく条項がIP補償です。否認だけの規約では、提供者が「負担しない」と言い切れるわけでもなく、争いの入口だけが残ります。
補償条項の部品：何を、誰が、どの手順で持つのか
IP補償の条項は、六つの部品で組み立てます。部品が欠けていないかが重要です。
IP補償の部品と、欠けたときに起きること
| 部品 | 書くこと | 欠けたときに起きること |
|---|---|---|
| 対象の請求 | 権利の種類（著作権・特許権・商標権・営業秘密）、地域（日本国内か）、提供者が提供する部分に限ること | 「一切の知的財産権」「世界中」と書くと、提供者が把握できない権利まで引き受ける |
| 負担する内容 | 確定した賠償額、提供者が同意した和解金、合理的な弁護士費用 | 「一切の損害」と書くと、逸失利益や顧客の社内対応の人件費まで対象と読まれる |
| 除外 | 顧客の入力データ、顧客の改変、他の製品との組合せ、顧客が指定した仕様、無償版・試用版、侵害を知った後の継続利用 | 除外がないと無限定の補償。除外が「OSS全般」「第三者のサービス全般」だと、提供者が選んだ部品まで除かれ、顧客が受け入れない |
| 手続 | 遅滞のない通知、提供者による防御の主導、顧客の協力、提供者の同意のない和解の禁止 | 顧客の独断の示談の求償、提供者が防御に参加できない状態 |
| 救済 | 権利の取得、侵害しない形への差替え、停止と前払金の返金の順序 | 差止めを受けたとき、提供者に停止か継続かの判断基準がなく、顧客との協議が長引く |
| 上限と存続 | 通常の賠償の上限との関係、補償専用の上限、契約終了後も終了前の利用に基づく請求に対応すること | 補償が上限に吸収される、又は契約の終了と同時に消える |
設計の型は三つに分かれます。どれを選ぶかは、顧客の層、料金の水準、上流から補償が受けられるかで決まります。
IP補償の三つの設計
否認＋顧客の自己解決
補償しない型
- 「侵害しないことを保証しない。請求は利用者が解決する」とする。
- 低価格で個人や小規模事業者が中心のサービスに多い。
限定補償
範囲と上限を絞って補償する型
- 提供者が提供する中核部分に限り、除外と手続を置いて補償する。
- 引き受ける量を計算できる形にでき、法人向けSaaSで最も現実的な型。
全面補償
請求を広く引き受ける型
- 範囲や上限を広く設ける。大企業向けの個別契約で求められる。
- 上流から同水準の補償を受けられない限り、差額が提供者に残る。
手続の部品は、短くても省かないことが重要です。権利者が顧客に訴えを起こしたとき、提供者が防御に関与できる仕組みがなければ、顧客の側が選んだ主張で進み、その費用が提供者に請求されます。民事訴訟法には、訴訟の結果に利害関係を持つ第三者が当事者の一方を補助するために参加する補助参加（同法42条）や、参加できる第三者に訴訟を知らせる訴訟告知（同法53条）がありますが、契約では、通知・防御の委任・協力の義務を先に書いておきます。次は、法人向けSaaSを想定して新しく書き起こした条文例です。
条文例知的財産権の侵害の請求への対応（法人向けの例）
- 当社は、利用者が本規約に従って本サービスを利用したことについて、第三者から、本サービスが当該第三者の日本国内の著作権、特許権、商標権又は営業秘密を侵害するとの請求（以下「侵害請求」といいます。）を受けたときは、次の各号の金額を負担します。(1)裁判所が確定した損害賠償の額 (2)当社が書面で同意した和解の額 (3)当社の同意を得て支出した合理的な弁護士費用
- 前項は、侵害請求が、次のいずれかに起因する場合には適用しません。(1)利用者が本サービスに入力し又は提供した情報や資料 (2)利用者による改変、又は当社が定める方法以外の方法での利用 (3)当社が提供しない製品、サービス又はデータとの組合せ (4)利用者が指定した仕様 (5)無償で提供する機能又は試用期間中の機能 (6)利用者が侵害のおそれを知り、又は当社から中止の連絡を受けた後の利用の継続
- 利用者は、侵害請求を受けたときは、遅滞なく当社に通知し、防御及び和解の交渉を当社に委ね、当社の求めに応じて必要な協力をします。通知の遅れにより当社の防御に不利益が生じたときは、当社の負担は、その不利益の限度で減額されます。利用者は、当社の書面による事前の同意なく、当社に義務を負わせる和解をしません。
- 侵害請求があった場合又はそのおそれがある場合には、当社は、自己の費用で、次のいずれかの措置を、この順序で検討します。(1)利用者が本サービスの利用を継続できるよう権利を取得すること (2)権利を侵害しないよう本サービスの全部又は一部を変更し、又は代替すること (3)前二号が合理的に不可能なときは、影響を受ける機能の提供を停止し、その機能に対応する未経過期間の前払の利用料金を日割りで返金すること
- 第1項の負担の総額は、当社、その代表者又はその使用する者の故意又は重大な過失による場合を除き、侵害請求を受けた時点から遡って12か月の間に利用者が当社に支払った利用料金の総額の◯倍を上限とします。第◯条（責任の制限）の上限は、第1項の負担には適用しません。
法人向けの例です。個人が契約者に含まれる場合は、上限や唯一の救済とする書き方が、消費者契約法8条（事業者の損害賠償の責任を免除する条項等の無効）の対象にならないかを個別に点検します。◯の部分は、料金の水準と保険の補償限度から決めます。
補償は責任の上限の内側か、外側か：数字で確かめる
IP補償の条項を置いた後に確認しておきたいのが、通常の損害賠償の上限（月額料金の何か月分、というもの）との関係です。実務で見られる失敗は二つあります。一つは、責任制限の条項で「第三者からの請求に基づく損害」について責任を負わないと列挙しながら、別の条で「第三者の知的財産権を侵害しないことを保証する」と書き、両者が衝突している契約です。保証違反の請求を免責が打ち消すのか、保証が優先するのかが文言から決まりません。もう一つは、委託料を上限とする条項が、知的財産権の侵害を含む請求原因のいかんにかかわらず適用され、故意・重過失がある場合にも上限を及ぼす書き方になっている契約です。
後者は、有効性が争われやすい形です。ホテルの宿泊約款の賠償額の限度が、ホテル側に故意又は重大な過失がある場合には適用されないとされた最高裁判決（最判平成15年2月28日）があり、考え方は責任制限のページで整理しています。上限の条項は、故意・重過失を除く旨を上限を定める一文の中に書くのが基本です。
数字で比べます。月額5万円（仮）のサービスで、権利者の請求を受けた顧客の防御費用と和解金の合計が400万円（仮）になったとします。上限の決め方によって、顧客の自己負担は次のように変わります。
補償の置き場所による顧客の負担額（仮の数字）
| 設計 | 補償の上限 | 提供者が負担する額 | 顧客の自己負担 |
|---|---|---|---|
| 通常の賠償の上限の内側 | 月額の12か月分＝5万円×12＝60万円 | 60万円 | 400万円－60万円＝340万円 |
| 補償専用の上限（別枠） | 支払総額の3倍＝60万円×3＝180万円 | 180万円 | 400万円－180万円＝220万円 |
| 上限なし（範囲を限定） | 定めない | 400万円（範囲内の費用） | 0円 |
計算の前提は、年額の利用料金が60万円で、400万円の全額が補償の範囲に入るという仮定です。実際には、除外の事由に当たる部分は顧客の負担に残ります。上限の内側に置くと、最初の一件で上限を使い切り、他の事故に使える余地がなくなる点も見落とされがちです。
上限の基準を「直前12か月の支払総額」にすると、無料プラン、課金前のβ期間、解約から12か月を過ぎた元利用者では上限が0円になります。補償専用の上限を支払総額の倍数にしたときも同じなので、「月額の◯か月分又は固定額のいずれか高い額」のように下限を置きます。
個人が顧客に混じる契約では、補償を絞る条項が、責任の一部を免除する条項として消費者契約法8条の対象になり得ます。軽い過失の場合の一部免除でも、重大な過失を除く過失による行為にのみ適用されることを明らかにしていなければ無効とされます（同条3項）。法人向けと個人向けを同じ規約で扱うなら、補償の条項は法人向けの別紙に切り出すと、点検の対象を分けられます。
OSSは「入れてよいか」より「どの形で渡すか」で義務が変わる
OSSのライセンスは多数ありますが、提供者が最初に把握すべきなのは、義務の重さに応じた大きな分類です。個々のライセンスの条文は原文で確認します。
OSSライセンスの型と、主な義務
| 型 | 主な義務 | SaaSで問題になる場面 |
|---|---|---|
| 許容的（MIT、BSD、Apache-2.0など） | 著作権表示とライセンス文を残す。Apache-2.0では、変更した旨の表示や、NOTICEファイルがあればその表示も求められる | 利用者に渡すコードやアプリに表示が漏れる。Apache-2.0では、特許の訴訟を起こすと、そのOSSに付いた特許のライセンスが終了する条件がある |
| 弱いコピーレフト（LGPL、MPLなど） | 対象のライブラリやファイルを改変したときは、その部分のソースを提供する。それ以外の自社部分は対象外にできる設計がある | 改変したライブラリをアプリやコンテナに入れて渡すとき。静的に結合するかどうかで扱いが変わることがある |
| 強いコピーレフト（GPLなど） | プログラムを配布するとき、全体を同じライセンスにし、ソースを提供する | 利用者の端末に渡るアプリ、エージェント、オンプレミス提供、コンテナ納品。サーバの中だけで動かし、利用者に渡さない形では、配布の義務は通常生じないと考えられている |
| ネットワーク型（AGPLなど） | 改変したプログラムにネットワーク越しに触れる利用者がいるとき、その利用者にソースを入手する手段を示す | サーバの中だけで動かしていても、改変したものを利用者がネット越しに使えば義務が生じ得る |
AGPLバージョン3では、プログラムを改変したときに、ネットワーク経由で対話する利用者にソースを入手する手段を示すことが定められています（13条）。ライセンス条件に違反するとライセンスは終了しますが、権利者から最初の通知を受けて30日以内に違反を是正すれば、その権利者との関係でライセンスが復活する定めもあります（8条）。
表の結論は、提供者の義務は「OSSの種類」と「渡す形」の掛け算で決まる、ということです。次の三つの形に分けると、判断の材料を整理できます。
利用者に渡す形と、OSSの義務
サーバの中だけで動かす
プログラムを利用者に渡さない
- GPLなどの配布を要件とする義務は、通常は生じない。
- ただし、AGPLのように、ネット越しの利用で義務が生じる型は別に確認する。
- ライセンスの表示や、変更の記録のような義務は、ライセンスごとに確認する。
ブラウザ・アプリ・SDKで渡す
コードが利用者の端末や環境に届く
- ブラウザに送られるJavaScriptは、利用者の端末に届くので、配布に当たるかを確認する。
- モバイルアプリ、デスクトップのクライアント、エージェント、SDKは、配布に当たる場面が多い。
- ライセンス文の表示、ソースの提供の手段を用意する。
オンプレミス・コンテナで納品する
環境ごと顧客に渡す
- コンテナイメージには、多数のOSSが含まれる。
- 含まれるOSSの一覧と、ライセンス文の同梱を納品物に入れる。
- 顧客が再配布する場合の条件も、契約で整理する。
ライセンス条件に反して複製や公衆送信をすると、著作権者の許諾の範囲を外れた利用と評価され、著作権の侵害を主張される可能性があります。複製（著作権法21条）や翻案（同法27条）は著作者が専有する権利で、侵害には差止め（同法112条）の請求が伴います。その請求が顧客に届けば、先に述べた補償の条項が働きます。
OSSの管理の核になるのが台帳です。経済産業省は、OSSの管理手法の事例集や、ソフトウェアの部品表であるSBOM（Software Bill of Materials）の導入の手引を公表しています。台帳には、名称、版、ライセンス、用途、改変の有無、利用者に渡す形、脆弱性情報の担当者を記録します。顧客から一覧を求められたときに、短時間で答えられます。
規約に反映するときは、二つの点が見落とされがちです。第一に、禁止事項で「リバースエンジニアリングの禁止」を一律に書くと、OSSのライセンスが許している行為まで禁止することになるため、OSS部分にはOSSのライセンスが優先すると書きます。第二に、OSSを理由にIP補償を全面的に外すと、提供者が自分で選んだ部品まで補償から外れ、顧客に受け入れられません。OSSの品質や適合は保証しないが、提供者がライセンス条件を守らなかったことによる請求は補償する、と線を引く方法があります。
条文例オープンソースソフトウェア（OSSの条文例）
- 本サービスには、第三者が提供するオープンソースソフトウェア（以下「OSS」といいます。）が含まれることがあります。OSSには、本規約に優先して、それぞれのライセンス条件が適用されます。
- 当社は、本サービスに含まれるOSSについて、そのライセンス条件を遵守します。当社は、OSSそのものの品質、特定の目的への適合性及び第三者の権利を侵害しないことを保証しません。ただし、当社がライセンス条件に違反したことに起因する侵害請求には、第◯条（知的財産権の侵害の請求への対応）を適用します。
- 第◯条（禁止事項）に定めるリバースエンジニアリング、改変その他の行為の禁止は、OSSに適用されるライセンスがこれを許す範囲では、当該OSSには及びません。
上流とつなぐ：開発委託先・外部サービス・再販元との背中合わせ
SaaSの提供者が顧客に約束する補償は、自社で書いたコードの部分だけでは済みません。開発を外部に委託している、商用のライブラリを組み込んでいる、決済・認証・生成AIなどの外部サービスを呼び出している、他社のサービスを再販している、という構成のどこかに、提供者が直接コントロールできない部分があります。顧客への約束が、上流から受けられる補償より広いと、その差額は提供者が負担します。次の表は、上流の関係ごとの傾向と下流への書き方です。受けられる内容は契約ごとに異なります。
上流の関係ごとの補償の傾向と、下流への書き方
| 上流の関係 | 受けられる補償の傾向 | 下流（顧客）への書き方 |
|---|---|---|
| 開発委託先（受託開発） | 成果物が第三者の権利を侵害しないことの保証と、請求時の解決の義務を定める例が多い。保証の期間を納品から一定期間とする例もある | 顧客への補償は契約期間の全体に及ぶので、保証の期間が短い場合は、期間の差が提供者の負担になる |
| 商用ライブラリ・ライセンサー | 提供元の標準約款に、補償が含まれることも、含まれないこともある。交渉の余地は小さい | 補償の対象を「当社が提供する部分」に限り、ライセンサーのコードの請求は上流の範囲で対応する、と書く |
| 外部のクラウド・API | 標準の規約のまま利用するのが通常で、個別の補償は期待しにくい | 外部サービスの部分は補償の対象から外し、外部サービスの規約が顧客に適用されることを示す |
| 再販元（他社のサービスを再販する） | 再販元が、製品そのものの非侵害を保証する例はあるが、出力や連携部分は含まれないことがある | 再販先の顧客への約束を、再販元の保証の範囲に合わせる |
開発の委託契約では、OSSの扱いにも工夫が必要です。実務で見られる書き方には、受託者がOSSを使う場合に、名称・版・ライセンスを事前に通知して発注者の書面による承諾を得なければならず、承諾なく成果物に組み込んではならない、という型があります。反対に、受託者側が、OSSの権利侵害や瑕疵がないことを保証せず、OSSの利用を提案した時点で問題を知っていたか重過失で告げなかった場合に限って責任を負う、という型もあります。成果物にOSSが含まれるときは、その利用、改変及び配布がライセンス条件に適合し、発注者の利用に制限や不利益を生じさせないことを表明保証させる例もあります。
SaaSの提供者は、この関係の両側に立ちます。開発を委託するときは上のような条項を求める発注者であり、顧客と契約するときは補償を約束する側です。顧客への補償は上限を支払総額の倍数にしているのに、開発委託先の保証は委託料の範囲に限られる、という食い違いがあれば、その差が提供者の負担になります。
他社のシステムを自社のブランドで販売する再販では、再販元の非侵害の保証が製品そのものに限られ、出力や外部のAPIに起因する侵害を含まないとき、再販する側が最終的な負担者になります。再販の設計は販売代理店・再販の契約を参照してください。
受託開発では保証の期間を納品から一定期間に区切る例がありますが、SaaSは提供を続ける契約なので、終了前の利用に基づく請求について終了後も補償を存続させるのかを、存続条項で決めておきます（期間・自動更新・中途解約のページ）。
よくある失敗と直し方
規約や契約書の見直しで、IP補償とOSSの周りに繰り返し現れる書き方があります。誤りやすい書き方と、直した書き方を並べます。
書き方の例（一般的な例） IP補償・OSSの条項
保証の否認だけを置く
理由法人の顧客の法務が最初に修正を求める条項。個別の修正に追われる前に、標準の型を用意しておく。
補償と責任制限が衝突する
理由優先関係が書かれていないと、保証違反の請求が免責に吸収されるのかが解釈に委ねられる。
「一切の損害」を負担する
理由範囲が見通せない約束は、保険にも乗らず、上流にも転嫁できない。
手続を書かない
理由顧客の独断の示談の金額や、提供者が関与できないまま進んだ訴訟の費用を負担せずに済ませる。
救済の順序がない
理由差止めを受けたとき、提供者が機能を止める根拠と、顧客への返金の基準になる。
ヒヤリングで確認すること
条文を整える前に、提供者の事実を確認します。確認する事項と、その理由は次のとおりです。
ヒヤリングの問いと理由提供者に確認する事項
サービスの提供の形は何か。ブラウザだけか、モバイルアプリ、デスクトップのクライアント、エージェント、SDK、ブラウザ拡張、オンプレミスやコンテナはあるか。
OSSの配布に当たるかと、顧客の環境に複製物が置かれるかが、この答えで決まるためです。
使っているOSSの名称・版・ライセンス・改変の有無の一覧を、すぐに出せるか。誰が更新するか。
一覧がなければ、顧客から求められたときに答えられず、違反の有無も判断できません。
開発は自社か、委託か。委託の場合、成果物の保証、請求時の解決、OSSの事前承諾の条項はあるか。
顧客への補償を上流に回せる範囲を知るためです。
商用ライブラリ、外部のクラウド、API、生成AIなどの規約に、提供者向けの補償があるか。
外部サービスの部分を補償の対象から外すか、引き受けるかの判断材料になります。
顧客は大企業か、中小企業か、個人も含むか。契約は規約のみか、個別の契約書も交わすか。
標準の型を限定補償にするか、個別契約用に全面補償の雛形を別に持つかが変わります。個人が含まれる場合は消費者契約法の確認も要ります。
料金の水準と、賠償責任保険の補償限度はいくらか。顧客が持ち込むデータやカスタマイズは何か。
補償の上限を保険の範囲と合わせ、除外の事由を実態に合わせて具体化するためです。
IP補償とOSSで起きがちなこと
- 規約に否認だけを書き、法人の顧客から個別に修正を求められるたびに、書き方がばらばらになる。
- 補償の条項と責任制限の条項の優先関係を書かず、保証違反の請求が免責に吸収されるのかが決まらない。
- 補償を「一切の損害」と書き、範囲も上限も決まらないため、上流からも保険からも回収できない。
- 顧客への補償が契約期間の全体に及ぶのに、開発委託先の保証が納品から一定期間で終わり、差額を自社で負担する。
- 「サーバの中だけだから」と配布に当たらないと思い込んでいるが、ブラウザに送るコードやエージェントが利用者に渡っている。
- OSSの台帳がなく、顧客に一覧を求められても出せない。一律のリバースエンジニアリング禁止がライセンスと食い違う（顧客データ条項の整理と合わせて点検する）。
このページの要点（まとめ）
- IP補償は、対象の請求、負担する内容、除外、手続、救済、上限の六つの部品で組み立て、否認だけの規約は法人の顧客に修正されやすい。
- 補償を通常の賠償の上限の内側に置くか、別枠にするかで、顧客の自己負担額は大きく変わる。責任制限の条項との優先関係を文言で決める。
- OSSの義務は、ライセンスの型（許容的・弱いコピーレフト・強いコピーレフト・ネットワーク型）と、利用者に渡す形で決まる。台帳を持つ。
- 顧客への補償は、開発委託先・ライセンサー・外部サービス・再販元から受けられる補償の範囲と合わせ、差額が提供者に残らないようにする。
よくあるご質問
SaaSの規約に、知的財産権の侵害の補償まで書く必要がありますか？
個人や小規模事業者が中心の低価格なサービスでは、否認と顧客の自己解決を書く型もあります。法人の顧客が相手になると、顧客の法務から補償を求められることが多く、範囲・除外・手続・上限を決めた限定補償を標準の型として持っておくと、個別の修正が減ります。
補償は、通常の損害賠償の上限の内側に置くべきですか？
内側に置くと最初の一件で上限を使い切るおそれがあり、別枠にすると提供者の負担が増えます。どちらでも、責任制限の条項との優先関係を「第◯条の定めにかかわらず」と文言で決め、上限の下限（無料期間や初月に0円にならない仕組み）も置きます。故意又は重大な過失を除く旨は、上限を定める一文の中に書きます。
SaaSでGPLのOSSを使うと、ソースコードの公開義務が生じますか？
サーバの中だけで動かし、プログラムを利用者に渡さない形では、GPLの配布を要件とする義務は通常は生じないと考えられています。ただし、ブラウザに送るコード、アプリ、エージェント、SDK、オンプレミスやコンテナでの納品は配布に当たり得ます。AGPLのように、ネット越しの利用で義務が生じる型もあるので、ライセンスの原文で確認します。
OSSを使っている場合、IP補償の対象から外してもよいですか？
OSS全般を外すと、提供者が選んで組み込んだ部品まで補償から外れ、顧客に受け入れられにくくなります。OSSそのものの品質や適合性、第三者の権利を侵害しないことは保証しないが、提供者がライセンス条件を守らなかったことによる請求は補償する、という線の引き方があります。
開発を外部に委託しているとき、顧客への補償を委託先に回せますか？
委託先の保証や補償の範囲と期間を確認する必要があります。顧客への補償が契約期間の全体や広い損害に及ぶのに、委託先の保証が納品から一定期間、委託料の範囲に限られていれば、差額は提供者の負担です。OSSの事前承諾と、ライセンス条件への適合の表明保証を委託契約に入れておくと、下流への約束とそろえやすくなります。
あわせて読みたいページ
本ページは一般的な情報提供です。個別の取引への当てはめは、サービスの仕組みや契約の経緯によって異なることがあります。書き方の例として紹介している内容は、一般に見られる書き方を整理した例で、特定の事業者や案件を示すものではありません。条文は e-Gov法令検索（法令API）で確認しています（最終確認日：2026年10月22日）。参考: e-Gov法令検索 / 個人情報保護委員会 / 経済産業省 / 国税庁
