AI Supplier Warranty／Indemnity／Liability Allocation

AIを外部調達する場合、モデルの性能評価とは別に、契約上の保証（warranty）、補償（indemnity）、責任制限（limitation of liability）、第三者請求、顧客データ・入力・出力の権利と利用条件を版管理して確認する必要がある。契約に「enterprise」「commercial」「indemnity」等の語があることだけで、顧客の全損失、規制違反、誤出力、第三者知的財産請求、データ侵害まで供給者が負担すると解釈してはならない。

AIサービスの法的配分は、公開規約一枚で決まらない。master agreement、order form、service-specific terms、DPA、SLA、acceptable-use policy、product-specific addendum、個別交渉条項が重なる。優先順位条項により、service-specific termsやorder formが一般条項に優先する場合もある。調達台帳では少なくとも provider、contracting entity、jurisdiction、agreement title/version/effective date、order form、service/product、indemnity scope、exclusions、liability cap、uncapped carve-outs、warranty disclaimer、data-use terms、termination/suspension、notice/claim procedure を同一snapshotとして保持する。

OpenAIの2026年1月1日発効Services Agreementは法人・開発者向けサービスに適用され、2026年10月16日更新のService TermsはAgreementと競合する場合にService Termsが優先するとしている。APIについては、一定の第三者知的財産権侵害請求をOutputに関する補償対象へ含める一方、侵害を知るべき場合、安全・引用機能等を無効化・無視した場合、他製品との組合せや変形、Input/fine-tuning filesの権利不足、商標関連、Third Party Offering由来など複数の除外がある。したがって「出力IP補償あり」を無条件保証として記録しない。

Google Cloudの現行Service Specific TermsもGenerative AIについて、Generated OutputをCustomer Dataとして扱う一方、出力が不正確・不快になり得て、顧客の規制・法的義務を満たすために設計されたものではない旨を明示する。追加の生成AI補償は「Generative AI Indemnified Service」として列挙された有償サービス・機能等に限定され、training data由来のIP請求とGenerated Output由来の請求でも条件が分かれる。対象サービス一覧は別ページで更新されるため、契約締結時点と事故時点の対象版を保存する。

MicrosoftのProduct TermsにあるCustomer Copyright Commitmentも、Covered ProductのOutput Contentに関する一定の第三者IP請求を対象とするが、安全機能を無効化しないこと、侵害のおそれを知りながら利用しないこと、Inputに十分な権利を持つこと、商標請求ではないこと、必要なmitigationを実装すること等の条件がある。Anthropicも商用条件について、authorized use of services/outputsに関するcopyright infringement claimへの防御・一定のsettlement/judgment負担を公表しているが、実際の適用はその時点のCommercial Termsと個別契約を確認する。

Warrantyは契約当事者間でサービスや権限等について約束される表明・保証であり、indemnityは典型的には特定の第三者請求等について防御・補償責任を配分する。SLA service creditも損害賠償や第三者請求補償とは別である。調達審査では「可用性SLAがある」「IP indemnityがある」「サービスを仕様通り提供する条項がある」を別フィールドにする。

生成AIでは、accuracy、non-infringement、fitness for a particular purpose、regulatory compliance等について広いdisclaimerが置かれることがある。業務部門が「ベンダーがAIの正確性を保証している」と誤認しないよう、契約上の明示保証と、製品資料・マーケティング表現を分離する。

補償義務が存在しても、その金額が無制限とは限らない。一般責任上限、特別上限（super-cap）、除外損害（indirect/consequential等）、cap除外、IP indemnity、confidentiality、data protection、gross negligence/willful misconduct等のcarve-outを契約本文で照合する。さらに、claim procedure、通知期限、防御主導権、和解同意、協力義務を満たさなければ補償を失う可能性があるため、事故対応runbookへ契約通知手順を接続する。

「年間利用料が小さいAPI」でも、顧客側の下流損害や規制リスクは大きくなり得る。契約capと実運用exposureが不釣り合いな場合、保険、用途制限、human review、取引上限、二重承認、別ベンダー、内部留保などで残余リスクを扱う。

契約は供給者から顧客への補償だけではない。顧客がInput、Customer Content、End User利用、違法利用、契約違反等に起因する請求について供給者を補償する条項を持つ場合がある。自社が投入するデータ・fine-tuning files・RAG corpus・画像・コードに必要な権利を持つかを確認し、第三者ライセンスや個人情報を「AIに入れられる権利」と「生成物を利用できる権利」に分けて追跡する。

安全機能、citation、filter、metaprompt、policy restrictionを無効化した場合に供給者補償が外れる契約では、技術設定変更が法的risk allocationを直接変える。したがってsecurity/MLチームのconfiguration drift監視とprocurement/legal台帳を接続し、補償条件に関係する設定を変更管理対象にする。

「Customer Dataを学習に使わない」というデータ利用条件と、「出力の正確性・合法性を保証する」ことは別である。データ保持、abuse monitoring、subprocessor、region、fine-tuning ownership、feedback利用、ログ、削除、法執行対応等をDPA/サービス条件と照合する。契約上のデータ利用制限が技術設定や特定プランに依存する場合、実際のtenant/configurationをreadbackする。

第三者モデル、plugin、connector、grounding source、marketplace offeringを組み合わせると、provider本体のindemnityが適用されない、または別契約が支配することがある。AIシステム全体を一社の契約で覆われていると仮定せず、componentごとにcontract ownerを割り当てる。

• Contract snapshot: 発効日・更新日・取得日・URL/PDF/hash・契約当事者・order formを保存する。
• Clause matrix: warranty / disclaimer / supplier indemnity / customer indemnity / liability cap / carve-out / excluded damages / claim procedure / data use / IP ownership / suspension / terminationを構造化する。
• Product binding: 実際に使うmodel/API/feature/planが補償対象リストに含まれるか確認する。
• Configuration binding: safety filter等の補償条件に関係する設定をchange managementへ接続する。
• Use-case exposure: 医療、雇用、金融、重要インフラ等は契約capだけでなく用途固有の法規制・professional dutyを別評価する。
• Incident notice: 第三者請求・侵害通知を受けた際の通知先、期限、証拠保全、防御主導権をincident runbookへ入れる。
• Renewal diff: 自動更新・規約更新時に旧版との差分を取り、補償対象、除外、cap、データ利用条件の変更を再承認する。
• Exit control: 契約終了時のdata export/deletion、fine-tune artifacts、logs、model dependency、代替供給者への移行可能性を確認する。

公開規約は個別交渉契約を反映しない。企業顧客のorder formやenterprise agreementが公開条件を修正している可能性があるため、公開ページだけから自社の権利義務を確定しない。

「著作権補償」も、すべてのIP権、すべての生成物、すべての利用方法、すべての第三者サービスを覆うとは限らない。商標、顧客Inputの権利不足、安全機能無効化、第三者Offering、改変・組合せ等が除外され得る。

責任上限や免責の有効性は法域・強行法規・事実関係で変わり得る。本記事は契約構造を運用管理するための辞典項目であり、特定契約の法的助言・訴訟見通しを示すものではない。

供給者の契約が強くても、顧客自身の法令遵守義務、professional duty、対エンドユーザー責任、内部統制責任が移転するとは限らない。契約によるrisk transferと、業務上のrisk eliminationを混同しない。

「ベンダーがAI出力を保証する」「著作権侵害はすべてベンダー負担」「enterprise契約なので責任はベンダーへ移転済み」と一般化しない。

「対象サービス・契約版・法域・利用条件・安全機能・Input権利・第三者Offering等の条件を満たす範囲で、特定種類の第三者請求について供給者補償が定められる場合がある。実際の適用範囲、責任上限、除外、通知手続は自社の締結済み契約一式で確認する」と記述する。

• 自社の個別order form/MSAが公開規約をどこまで修正しているか。
• 各providerでIP indemnityが一般責任cap内か、別capか、uncappedか。
• marketplace/third-party model/connectorを含む場合の契約境界。
• safety filter等の技術設定変更が補償条件へ与える影響。
• 各法域でdisclaimer、excluded damages、liability capがどこまで有効か。
• AI Actその他の規制義務と契約上の責任移転の関係。
• 保険契約が生成AI由来のIP、privacy、professional liabilityをどこまでカバーするか。