※記事に出てくる専門用語は、こちらの【用語集ページ】でも解説しています。必要に応じてご参照ください。
１．契約書の隅に潜む「1,500万ユーロの時限爆弾」
欧州市場やグローバル案件に潜む巨額賠償責任の転嫁
欧州市場への展開やグローバル案件を手掛ける日本のIT企業、受託制作会社、SaaS事業者に、巨額の賠償責任を転嫁するための契約書が届きつつあります。
表向きは「EU AI法への適切なコンプライアンス対応」を謳った合意書や業務委託契約の覚書です。「第50条に基づく透明性義務を遵守すること」という文言が並んでいます。
損害賠償・補償条項の後半に忍び込む過酷な文言
問題は、契約書の後半にある「損害賠償」や「補償」の条項です。「一般的な定型条項が並んでいるのだろう」と油断しがちなこの箇所に、極めて過酷な文言が忍び込んでいることがあるのです。
「受託者は、本件成果物の瑕疵または法令違反に関連して委託者が被った一切の損害、費用、および第三者からの請求（行政上の制裁金を含む）について、委託者を防御し、補償（Indemnify）する。」
この条文に合意すると、受託企業は、欧州の巨大企業が規制当局から科される天文学的な制裁金リスクを、転嫁されてしまうことになります。
自社の受注規模とは桁違いの賠償義務を課される盲点
その制裁金とは、「最大1,500万ユーロ（約24億円）」あるいは 「（欧州巨大企業グループ全体の）全世界年間売上高の3%」 のいずれか高い方です。
ここで注意すべきなのは、制裁金の算定基準が「自社の売上」ではなく、「商流の頂点にいる欧州巨大企業の売上」 である点です。
受託金額がわずか数百万円の開発案件や、月額数十万円のAPI提供契約であっても関係ありません。契約書上で適切な防衛線を引いていなければ、自社の受注規模とは桁違いの巨額な賠償義務が一方的に課されます。
現場の営業担当者は「大手との取引継続のために必要だから」と安易に合意を急ぎがちです。
しかしそれは、取引の対価とは全く不釣り合いなリスクを自社だけが背負い込む、極めて片務的な契約です。他社の巨大な法的リスクを無償で引き受ける危険な行為に他なりません。
２．背中合わせ（バック・トゥ・バック）の責任転嫁メカニズム
日本のIT業界が抱える多層下請け構造と強力な法的圧力
なぜ、自社の規模とはかけ離れた巨額リスクを押し付けられる事態が起きるのか。その背景には、日本のIT業界が長年抱えてきた「多層下請け構造」があります。
欧州の規制当局から発せられた強力な法的圧力が、受託ピラミッドの上流から下流へ向かって、そのまま流れ落ちてくる仕組みになっているためです。
EU市場で自社ブランドを展開する欧州の大企業は、EU AI法に違反した際に科される最大1,500万ユーロ（約24億円）、あるいはグループ全世界年間売上高の3%という制裁金を極度に恐れています。
欧州委員会が策定したAI調達モデル契約条項（MCC-AI）の大義名分
そこで活用されているのが、欧州委員会が策定・公表した「MCC-AI（AI調達モデル契約条項：Model Contractual Clauses for AI）」 です。
これは、企業や官公庁が外部からAIシステムを調達する際に用いる「公式の標準契約ひな形」であり、透明性義務の遵守やバイアス監査などの要件が、あらかじめ盛り込まれています。
欧州の顧客は、このMCC-AIをベースに「欧州の公式標準だから」という大義名分を掲げ、システム開発やコンテンツ企画を請け負う大手元請けSIerやグローバル広告代理店に対し、「法令違反で生じた制裁金や損害はすべて貴社が補償せよ」という過酷な契約条件を突きつけます。
ここで窮地に立たされるのが、発注を受けた大手元請け企業です。
実際のシステム開発や画像・テキストの生成モジュール構築、あるいはAPI連携の実務は、外部の中小IT企業や受託制作会社、SaaSベンダーが担っています。
元請け企業自身が直接コードを書いていない以上、下請けが納品した成果物にC2PA電子刻印の欠落などの不備があった場合、欧州の巨大顧客から請求される数十億円もの賠償金を自社だけで支払うわけにはいきません。
元請け企業が自社の賠償リスクを回避する契約の鏡写し構造
そこで元請け企業が自社の賠償リスクを回避するために使うのが、「背中合わせ（バック・トゥ・バック）条項」です。
元請け企業は、欧州の顧客から課された過酷な補償義務をコピペして、契約当事者の名義は自社と下請け企業の名前に書き換えます。そして、その過酷な補償義務を下請けベンダーとの個別契約書や発注覚書へ流し込むのです。
発注元に対する自社の義務と、下請けに対する自社の権利を鏡のように一致させることで、元請け企業は、上から降ってきた賠償請求をそのまま下流へ受け流すことができます。
仮に欧州市場で配信されたコンテンツに不備があり、現地の巨大企業に行政制裁金が科されたとします。その損害賠償請求は元請けを素通りし、最終的に末端の下請けベンダーを直撃します。
その結果、受け取った開発費や制作費がわずか数百万円にすぎない受託企業が、自社の受注額とは桁違いの 「巨額の賠償金」 を請求される事態に陥ります。
立場の弱い下請けが、実質的に欧州巨大企業のリスクを肩代わりさせられてしまうのです。
３．Indemnificationを全額補償へすり替える契約のからくり
法務部門や事業責任者が最も見落としやすいのが、契約書に書かれた言葉の定義と、その運用実態のズレです。
実は、欧州委員会が公開している純正の「MCC-AI（AI調達モデル契約条項）」の標準ひな形を精読すると、第12条（責任規定）において、受託者の契約対価を基準とした「責任上限（Liability Cap）」を明示的に設定することが推奨されています。
本来の公的標準は、受託企業を一方的に破産させるような過酷な設計にはなっていません。
そもそも英米法において「Indemnification（補償条項）」という概念そのものは、本来「一方の当事者が、特定の事由によって生じた損害や費用から相手方を守る（填補・防御する）」という中立的なリスク分担の仕組みにすぎません。
日本の民法でいう「損害賠償」とは異なり、本来はトラブル発生時に「相手方を無傷に保つ」ための実務的な取り決めであり、これ自体が悪質な契約というわけではないのです。
問題は、商流の頂点にいる欧州巨大企業や、その発注を受けた大手元請け企業（SIer）の法務部が、この「公的標準」や「中立的な契約用語」という看板を隠れ蓑にしながら、自社の法的リスクを完全に消し去るために条文を独自に魔改造・肉付けしている点にあります。
彼らは、純正のMCC-AIから「責任上限の空欄」を意図的に削除し、一般的な補償条項の枠組み（Indemnification）の中に、以下の3つの条件を周到に抱き合わせることで、実質的に下請け企業へすべての損失の身代わりを強制する「全額補償の罠」へと姿を変えさせているのです。
からくり①：責任上限（Liability Cap）規定からの意図的な除外
通常の受託開発やシステム保守の契約では、受託者を守るための防壁として「責任上限」が設定されます。「損害賠償の総額は、本契約に基づき過去12ヶ月間に支払われた受託対価を上限とする」といった条文がその代表例です。
しかし、危険な契約書では、補償条項の末尾に目立たない一行が差し込まれます。
「ただし、第○条（法令遵守およびAI法コンプライアンス）に関する補償義務については、本上限規定を適用しない。」
この例外規定を承諾すると、受託金額が数百万円の案件であっても、責任の上限枠が消滅します。青天井の無限責任を背負わされることになります。
からくり②：間接損害や行政上の制裁金まで網羅する損害範囲の無制限な拡張
通常、日本の損害賠償実務で対象となるのは、民法第416条に基づく「直接かつ通常の損害」に厳格に限られます。
ところが、独自にカスタマイズされた過酷な補償条項では、受託者が補償すべき「損失（Losses）」の定義が、契約書上で極限まで肉付けされています。直接損害だけでなく、間接損害、特別損害、将来の逸失利益、さらには元請け企業が雇った高額な弁護士費用までが、あらかじめ条文内に網羅されているのです。
そして最悪の場合、欧州当局から欧州巨大企業や元請け企業に科された「行政上の制裁金」までもが、この損失の定義リストへ合法的に紛れ込まされます。
からくり③：過失責任から「客観的事実」のみで発動する結果責任への変質
日本の民法に基づく一般的な国内取引であれば、受託者側に「故意または過失（落ち度）」、すなわち「受託者の責めに帰すべき事由」がなければ、損害賠償責任を問われないのが原則です。
しかし、あらかじめカスタマイズされた過酷な補償条項では、この「過失」という概念そのものが最初から排除されています。
条文内には日本の取引で一般的な免責文言は存在せず、「成果物に起因して第三者から請求や調査が生じた場合」という客観的な事実（結果）だけで、直ちに受託者の補償義務が全自動で発動するよう最初から設計されているのです。
このように、大企業の法務部は「Indemnification」という一般的な契約用語の枠組みを使いながら、「責任上限の撤廃」「損害範囲の拡大」「無過失責任化」の3つを最初からセットで組み込んでいます。
これにより、事実上の全額補償を下請け企業に約束させるのです。
４．自社P/Lを守り抜く「3つの契約防衛ライン
相手方から過酷な契約条件を突きつけられた際、あるいはすでにサインしてしまった後だと気づいた際、下請け企業やSaaS事業者はどのように対処すべきでしょうか。
「サインしなければ案件を失注する」という営業的な力関係に屈して白紙委任する必要はありません。
また、すでに合意してしまった場合であっても、打つ手が完全に消滅したわけではありません。自社の資本とP/Lを防衛するための現実的な対処法は存在します。
契約締結前の段階であれば、以下の3つの論理的対案を提示し、条文の修正を求めてください。
防衛ライン①：受託対価を上限とするキャップ規定の例外なき適用
どのような補償条項（Indemnification）であっても、責任上限の例外にしてはなりません。
「欧州の公的標準（MCC-AI）だから変更できない」という元請け側の要求は明確なブラフです。なぜなら、純正のMCC-AIの標準雛形自体が、受託者の契約対価に応じた責任上限（Liability Cap）を設定することを明示的に推奨しているからです。
交渉の席では、下記のような経済合理性を突いた対案を毅然と提示してください。
「数百万円の受注対価に対して何十億円もの無限責任を負うことは保険数理上も不可能です。純正のMCC-AIの精神に則り、過去12ヶ月の対価を上限とする規定にして頂きたい。上限を外すことは、万一の際に当社が破綻し、貴社に対する履行不能を引き起こすリスク（共倒れ）を高めるだけです」
これは相手方の法務部にも通用する極めて強力な交渉カードになります。
防衛ライン②：サーバー側の自動処理や配信インフラ起因過失の完全免責を明記
C2PA電子刻印の消滅が、自社の開発ミスではなく「元請け側や配信インフラの自動処理」によって引き起こされるリスクを、あらかじめ条文で切り離してください。
「成果物の納品後に、委託者または第三者のサーバー、CDN、もしくは配信プラットフォームにおける画像圧縮、フォーマット再エンコード、メタデータ削除（Exifスクラブ等）の処理によってC2PA等の識別情報が破壊・消去されたことに起因する損害について、受託者は一切の補償義務および損害賠償責任を負わない」
という免責条項を設けることで、配信出口での「技術的自爆」の責任転嫁を遮断できます。
防衛ライン③：通知義務と「防御の主導権（Control of Defense）」を確保する
欧州当局からの公的調査やクレームが入った際、元請け企業が自社の都合だけで勝手に巨額の和解を結び、その請求書だけを下請けに回してくる事態を防ぎます。
「委託者は、補償の対象となる事態が生じた場合、遅滞なく受託者へ書面で通知しなければならない。また、受託者の事前の書面による承諾なしにいかなる和解も行ってはならず、受託者は自らの費用負担において当該請求に対する防御を主導する権利を有する」
と定めてください。
５．すでに契約書にサインしてしまった場合の緊急処方箋
問題は、「すでに元請け企業の提示した補償条項にサインしてしまっている場合」です。締結済みの契約書を今すぐ一方的に巻き戻すことは現実的ではありません。
技術的なエビデンス（客観的ログ）の確保とアーカイブの即座導入
この場合に取るべき実務的な初動は、契約書の改定を急いで相手を刺激することではなく、「技術的なエビデンス（客観的ログ）の確保」 です。
具体的には、「納品時点におけるデータのハッシュ値とC2PAマニフェスト完全性のログ」を自社サーバー側に自動保存・アーカイブする仕組みを至急、導入してください。
欧州市場で配信された画像からC2PAが消えて当局から問題視された際、契約書上は全額補償義務を負わされていても、議論の焦点は「誰がその刻印を消したのか（自社の納品ミスか、納品後の元請け側のインフラ処理か）」になります。
手元に「自社は正常なC2PAヘッダーを付与して納品した」という電子ログがあれば、納品後に元請け側のサーバー処理で破壊された事実を客観的に証明できます。
この記録によって相手方の過失や因果関係の断絶を立証でき、不当な責任転嫁を現場協議の段階で退ける有力な根拠になります。
次回のSLA改定タイミングを捉えた段階的な改定
その上で、半期ごとの契約更新や、次回のSLA（Service Level Agreement：サービス品質保証契約） の改定タイミングを捉え、前述の責任上限や免責条項を盛り込んだ覚書へと段階的に改定していくという手順を踏んでください。
６．猶予期限に向けた「署名前の3ステップ選別法」
EU AI法 第50条の既存システム向け適合猶予期限は、2026年12月2日に迫っています。
大手元請け企業からの改定要請に対する毅然とした拒絶
この期限が近づくにつれ、IT受託やコンテンツ制作の現場では、コンプライアンス確認を名目とした契約書の改定要請が急増します。大手元請け企業から「欧州案件を継続するために、大至急この覚書に押印してほしい」というプレッシャーが舞い込んでくるはずです。
しかし、営業的な力関係に押されて焦ってサインをしてはなりません。
技術的なC2PAの実装をどれほど完璧に仕上げていても、契約書に「責任上限のない全額補償条項」が潜んでいれば、配信インフラ側の些細なトラブル一つで自社が致命傷を負います。
自社が負うべき責任範囲の明確な定義と理不尽な転嫁の遮断
真のコンプライアンスとは、言われるがままに他社の法的リスクを背負い込むことではありません。自社が負うべき責任の範囲を明確に定義し、理不尽な責任転嫁を毅然と拒絶することです。
今後、契約書に「Indemnify（補償する）」という文字を見つけた際は、以下の3段階のチェック手順を実行してください。
【ステップ1：責任上限（キャップ）の確認】
補償義務に対して、自社の受託対価（または過去12ヶ月分）を上限とするキャップが例外なく適用されているかを確認する。
除外規定がある場合は即座に修正を求めてください。元請け側が「公的標準」を盾に拒む場合は、「純正のMCC-AI第12条でも責任上限の設定枠が確保されているはずです。御社が提示している無限責任は、欧州委員会の本来の趣旨を超えた過剰な転嫁です」と論理的に切り返してください。
【ステップ2：インフラ免責条項の挿入】
納品後に発生するExif削除やWebP変換など、元請け・第三者の配信インフラ起因によるC2PA消滅について、自社が完全免責される条文を追加する。
【ステップ3：客観的エビデンスの確保】
すでに契約書へサイン済みの場合、あるいは相手方が修正に一切応じない場合は、納品時におけるC2PA完全性のハッシュ値・電子ログを自社で自動保存し、責任転嫁を現場レベルで退ける体制を直ちに整える。
会社全体の存続を危険に晒さないための勇気ある撤退判断
もし、相手方が責任上限の設定を拒否し、無限責任の受け入れを取引継続の絶対条件として突きつけてくるのであれば、その案件からは勇気を持って撤退する判断も必要です。
数百万円の売上のために、会社全体の存続を危険に晒す合理的な理由はありません。
契約書の条文を精査することは、後ろ向きな作業ではありません。自社の粗利益と技術者を守り、国際的な規制の荒波の中で事業を存続させるための、極めて前向きな経営防衛です。
References
European Commission Institutional AI Procurement Framework
EU AI Act Regulatory Compliance Portal
EUR-Lex Access to European Union Law
※記事に出てくる専門用語は、こちらの【用語集ページ】でも解説しています。必要に応じてご参照ください。
