AI導入時の責任分界はどう決めるか|誤答・事故・第三者クレームへの備え
AIツールを業務に入れるとき、契約書のレビュー段階で真っ先に聞かれるのが「何か問題が起きたら、誰がどこまで責任を負うのか」という論点です。通常のSaaS契約以上に厄介なのは、AIの場合、出力そのものが不確実で、誰が何を間違えたのかを切り分けにくいという点にあります。
この記事では、AIの誤答・第三者権利侵害・情報漏えい・サービス停止・アルゴリズムバイアスといった代表的なAI事故の類型ごとに、ベンダー責任・利用企業責任・共同管理のどこに落ちるかを整理し、契約でどこを交渉すべきかまで踏み込んで解説します。2026年4月に経済産業省が公表した「AI利活用における民事責任の解釈適用に関する手引き」が示す「補助/支援型AI」と「依拠/代替型AI」の2類型、AIエージェントの権限設計、EU AI Actの2026年8月2日以降の適用状況までを踏まえた、BtoBのAI導入契約を主戦場とする法務担当者向けの実務整理です。
本記事の読み方(3つのレイヤーを混ぜないでください)
AIをめぐる「やるべきこと」は、性質の異なる3層が混在しています。本記事では、以下を区別して記載しています。
- 【法的義務】法律・規則で義務づけられているもの(例:個人情報保護法上の安全管理措置、漏えい等報告)
- 【推奨(ガイドライン)】経済産業省の手引き・AI事業者ガイドライン等が示す考え方。これら自体は法律ではなく、違反しても直ちに罰則の対象にはなりません。ただし調達基準や事後の過失判断で実質的に参照されます。
- 【推奨(契約実務)】交渉で取りにいくべき水準。案件のリスク・交渉力・保険・対価によって落としどころは変わります。
ガイドライン上望ましいことを「法律上必須」と読み替えないでください。
1. AI導入で責任分界が問題になりやすい理由
AI導入時の契約で、責任分界の議論が通常のシステム導入より揉めやすい理由は、大きく次の5点に整理できます。
1-1. 出力の正確性が保証されない
生成AIも予測AIも、アウトプットの正確性は統計的なものであって、100%の保証はありません。多くのベンダー契約では、出力の正確性・完全性・適法性を明示的に否認する保証否認条項が置かれています。これは技術的には合理的ですが、利用企業から見ると「間違っていても文句が言えない契約」に見えやすく、レビュー時の最大の摩擦点になります。
1-2. 原因の切り分けが難しい
AIで事故が起きたとき、原因が「モデルの品質」「学習データ」「RAG(検索拡張生成)の構成」「ナレッジベースの更新運用」「ユーザの入力(プロンプト)」「業務フローへの組み込み方」「レビュー体制」のいずれにあるのか、事後的に切り分けるのが極めて難しいケースが多くあります。そのため契約段階で「どちらの責任領域か」を明示的に定義しておかないと、事故後に水掛け論になります。本記事では第4章で、レイヤーごとに責任原因を分解する実務フローを示します。
1-3. インフラが多重構造になっている
現在の企業向けAIサービスの多くは、国内ベンダーが自社でモデルを開発しているわけではなく、海外プラットフォーマー(OpenAI、Anthropic、Googleなど)のAPIを経由して提供されています。このため、日本のベンダーと契約しても、背後にある海外プラットフォーマーの免責範囲が壁になるという構造があります。
この構造への対応として、国内ベンダーが「プラットフォーマーが免責している範囲は当社も免責される」と定める、いわゆるBack-to-Back条項を求めてくるケースが目立ちます。この節は後述(7-6)で改めて扱いますが、導入時点で「実質的な責任主体は誰か」を見極める必要があるという点は、AI契約特有の論点です。
1-4. 第三者に対する責任が発生しうる(ここは正確に理解する必要があります)
AIの出力をそのまま外部提供したり、顧客対応に使ったりすると、第三者(顧客・取引先・権利者)との関係で損害賠償請求や権利侵害クレームが起きえます。契約は当事者間にしか及ばないため、契約外の第三者との関係では、不法行為法(民法709条以下)が基本的なルールになります。
ここで、旧来よく見られる「AI事故なら第三者は利用企業とベンダーの双方に当然に不法行為責任を問える」という説明は正確ではありません。民法709条の責任は、請求を受ける主体ごとに、
- 故意または過失(予見可能性と結果回避義務違反)
- 他人の権利または法律上保護される利益の侵害
- 損害の発生
- 行為と損害との間の因果関係
をそれぞれ個別に判断する必要があります。AIが介在したという事実だけで、開発者・提供者・利用者が自動的に横並びで責任を負うわけではありません。
経済産業省の「AI利活用における民事責任の解釈適用に関する手引き〔第1.0版〕」も、不法行為法と製造物責任法の観点から、AI開発者・AI提供者・AI利用者それぞれについて要件該当性を検討する構成をとっています。とくに、人が最終判断を行う前提の「補助/支援型AI」では、AI開発者・提供者については因果関係が否定される場面が多く、責任が認められる場面は限定的である方向で整理されています(詳細は第3章)。
複数主体が関与する場合には、民法719条1項前段の共同不法行為や同条2項の教唆・幇助の成否が論点になります。これらの要件が満たされれば、各当事者が連帯して損害賠償責任を負います。
共同不法行為者間の求償について
共同不法行為者の一人が被害者に賠償した場合の内部的な求償について、条文上の直接の根拠として「民法442条以下」を単純に引用するのは正確ではありません。共同不法行為の規定は民法719条であり、判例は719条に基づく損害賠償債務をいわゆる不真正連帯債務と位置づけたうえで、判例法理として、各自の過失割合に応じて定まる負担部分を超えて賠償した者は、他の共同不法行為者に対して求償できるとしてきました(最判昭和41年11月18日、最判昭和63年7月1日、最判平成3年10月25日など)。
なお、2017年(平成29年)民法改正により連帯債務における絶対的効力事由が縮減されたため、不真正連帯債務という概念の位置づけ自体には議論があります。契約審査の実務では、条文の引用に踏み込むよりも、契約上の補償条項(indemnity)や責任分担条項で求償の経路を明示的に確保しておくことのほうが実効性が高い、と理解しておくのが安全です。
1-5. 法令上の責任は「合意」で免脱できない
個人情報保護法上の安全管理措置(法23条)、委託先の監督(法25条)、漏えい等の報告・本人通知(法26条)、著作権法上の権利侵害責任、各業法上の責任などは、契約で「ベンダー責任」と書いても、行政上・司法上の責任まで当然に免れるわけではありません。誰が法令上の義務主体になるかは、あくまで法令の適用関係で決まります。
もっとも、後述のとおり(6-3)、「AIベンダーへの個人データの提供がどの法的構成に当たるか」によって、義務主体の整理は変わります。「利用企業が常に一次的責任主体」と一律に述べるのは不正確です。
なお、消費者契約法8条は、事業者の損害賠償責任を全部免除する条項等を無効とし(1項)、さらに令和4年改正(2023年6月1日施行)で新設された同条3項により、責任の一部を免除する条項のうち「軽過失による行為にのみ適用されることを明らかにしていないもの」(いわゆるサルベージ条項)も無効とされています。これは事業者と消費者の契約に適用される規律であり、BtoBのAI導入契約そのものには直接適用されません。もっとも、自社がBtoCサービスの中にAIを組み込んで提供する場合は、エンドユーザ向け利用規約の免責条項が同条の射程に入るため、仕入れ側(AIベンダー契約)の責任配分と整合させておく必要があります。
実務上のポイント
AIの責任分界は、①契約上の賠償責任の配分、②対外的な法令上の責任、③第三者からの直接請求と求償の経路、の3つを分けて考える必要があります。契約で責任を全部ベンダーに寄せても、法令上の義務主体は法令の適用関係で決まりますし、第三者からの請求に対しては各主体について不法行為の要件が個別に判断されます。
2. 経産省「AI民事責任手引き」の位置づけ
2026年4月9日、経済産業省は「AI利活用における民事責任の解釈適用に関する手引き〔第1.0版〕」を公表しました(同年6月9日にページ更新)。有識者研究会(座長:大塚直・早稲田大学教授、全4回)とパブリックコメントを経て取りまとめられたものです。
2-1. 何を扱う文書か
- 【推奨(ガイドライン)】新しい法制度を作る文書ではありません。現行の民法(不法行為)および製造物責任法を前提に、解釈適用の方向性を示すものです。法的拘束力はありません。
- 中心的な検討対象は不法行為責任であり、契約関係を踏まえた当事者間の厳密な責任分界を確定するものではありません。契約上の留意事項は「AI・データの利用に関する契約ガイドライン1.1版」および「AIの利用・開発に関する契約チェックリスト」が扱う、という役割分担になっています。
- そのうえで、契約当事者間でも不法行為責任を加重・制限・放棄する合意が可能であることから、契約に基づく責任・損失の分配を設計する際の参考になると位置づけられています。
2-2. 想定事例
手引きは、AIを用いたサービス・システムが事故に寄与した以下の想定事例を題材に検討しています。契約審査でのアナロジーを探す際に有用です。
- 配送ルート最適化AI
- 弁護士業務支援AI
- 画像生成AI
- 取引審査AI
- 外観検査AI
- 自律走行ロボット(AMR)
- (補論)AIエージェント(カスタマーサポートの事例)
2-3. 「補助/支援型AI」と「依拠/代替型AI」
手引きの中核は、AIの利用形態に応じた2類型の整理です。まず自社の使い方がどちらに該当する(または近い)かを検討することが出発点になります。
| 比較軸 | 補助/支援型AI | 依拠/代替型AI |
|---|---|---|
| 定義 | AI利用者の判断の補助・支援としてのみ用いられ、最終的に人の判断や行動を介在させることが予定されている類型 | 人の判断や行動の全部または一部を代替する前提で提供され、AIの判断に依拠しながら用いることが予定される類型 |
| 典型例 | 調査・ドラフト支援、社内ナレッジ検索、画像生成の下書き、外観検査の一次スクリーニング(人が最終確認) | 自律走行ロボット、人手を介さない一次審査・自動応答(品質・精度が一定水準を満たす場合) |
| 補助/支援型とすべき場面 | ①機能・利用場面から人の判断を代替しているといえない場合、②規制法上、人の最終判断が要求される場合、③出力が潜在的に第三者の権利を侵害するリスクを内包し、人の評価・検証が必要な場合 | — |
| AI利用者の注意義務 | AIを使ったかどうかにかかわらず、自身の職業・地位に応じた本来の注意義務のもとで適切に判断・行動することが求められる(「AIが間違えた」は抗弁になりにくい) | 注意義務の対象が、個別判断の適否から「AIシステムを適正に用いるための体制の構築および運用」へと移る |
| AI開発者・提供者の責任 | 最終的に利用者が出力の適切性を検証・是正する前提のため、原則として因果関係が否定されやすく、責任を負う場面は限定的。中心は性能限界・重要リスク等に関する説明義務 | 人の検証が予定されない分、設計・性能・説明に関する責任の比重が相対的に高まる。組み込み型では製造物責任も検討対象 |
2-4. 実務へのインパクト:ガバナンスが過失判断に効く
手引きは、AI利用者について、AI事業者ガイドラインの考え方も踏まえてリスクの調査・分析や体制構築を行っていた場合、それでもなお予見が困難であった特異なリスクが顕在化したケースでは予見可能性を否定する方向の事情として斟酌され得ること、また見込まれたリスクの程度に応じて実務上合理的な対応策を講じていた場合には結果回避義務違反と評価される可能性を低くする事情として斟酌され得ることを示しています。
これは法務にとって重要な示唆です。AIガバナンス文書・レビュー運用・ログ・承認工程の整備は、単なる「望ましい取組」ではなく、事後の過失判断で自社を守る材料になり得るということです。ただし、これは解釈の方向性を示すものであって、体制を整えれば免責されるという意味ではありません。
2-5. 製造物責任法との関係
製造物責任法(平成6年法律第85号)は、「製造又は加工された動産」の欠陥により生命・身体・財産に損害が生じた場合に、過失の有無を問わず製造業者等に賠償責任を認める不法行為法の特則です(同法2条1項、3条)。
- 日本法では、AIソフトウェア単体は「製造物」に当たらないと一般に解されています。
- 他方、ソフトウェアがハードウェアに組み込まれている場合には、当該製造物の欠陥として製造物責任が問題となり得ます。自律走行ロボット、AI搭載機器、フィジカルAIを扱う場合は、この観点の検討が必要です。
- EUでは2024年12月に発効した改正製造物責任指令により、ソフトウェア等の無体物が「製造物」に含まれることとされています。日本法とEU法で射程が異なる点は、越境取引では見落とせません。
3. AI事故の主な類型
契約審査で整理すべきAI事故は、おおむね以下の6類型に分かれます。類型ごとに責任の落としどころが違うため、ひとまとめに議論せず、類型別に論点を整理するのが実務的です。
- 誤答・幻覚・出力不正確性:生成AIが事実と異なる回答を出した、予測AIが誤った判定をした、といった事故。
- 第三者権利侵害:出力物が第三者の著作権・意匠権・肖像権・商標権・パブリシティ権等を侵害した事故。
- 個人情報漏えい・秘密情報流出:入力データがベンダー側に保持・学習され、外部に流出する事故。
- サービス停止・障害:AIサービスが長時間停止し、業務に影響が出る事故。
- アルゴリズム・バイアス:学習データやモデルの偏りにより、不当な差別的出力や公平性を欠く判定が行われる事故。
- 不適切利用・社内ルール違反:従業員がガイドラインに反する使い方をし、情報漏えいや不適切な出力につながる事故。
4. レイヤー別・責任原因分析フロー
AI事故の原因究明は、「ベンダーか自社か」という二択で考えると必ず行き詰まります。実務上は、AIシステムを次の6レイヤーに分解し、どのレイヤーで何が起きたかを先に特定してから、責任主体の議論に進むのが有効です。
入力 → モデル → RAG・外部データ → システム実装 → 人のレビュー → 外部行為
| レイヤー | 典型的な不具合 | 主に問題となり得る主体 | 保全・確認すべき証跡 |
|---|---|---|---|
| ①入力(プロンプト・添付データ) | 誤った前提の入力、指示の欠落、禁止データの入力、プロンプトインジェクション | 利用企業(利用部門)/入力制御を担うベンダー | 入力ログ、添付ファイル、入力ルールの周知記録、入力フィルタの設定 |
| ②モデル | 確率的な不正確性(いわゆる幻覚)、能力限界、モデル差替え・バージョン更新による挙動変化 | AI開発者・提供者(説明義務・仕様適合性)/上位プラットフォーマー | モデル名・バージョン、リリースノート、性能に関する説明資料・SLA、評価結果 |
| ③RAG・外部データ | ナレッジベースの更新漏れ、検索対象の誤設定、権限のないデータの混入、外部APIの応答異常 | RAGを構築・運用する側(ベンダー独自実装か、利用企業の運用か) | インデックス更新履歴、参照ドキュメントID、検索クエリと取得スニペット、権限設定 |
| ④システム実装 | プロンプトテンプレートの欠陥、後処理・整形の不具合、権限制御の不備、UIが誤解を招く設計 | 国内ベンダー・SIer(独自実装部分)/内製の場合は利用企業 | 設計書、テンプレート、リリース履歴、テスト記録、権限マトリクス |
| ⑤人のレビュー | レビュー未実施、形式的チェックのみ、レビュー担当者の権限・力量不足、承認工程のスキップ | 利用企業(原則) | 承認ログ、レビュー担当者・日時、チェックリスト、差戻し記録 |
| ⑥外部行為 | 誤った出力の外部送信・公表、誤発注、誤った顧客回答、外部システムへの誤反映 | 利用企業(原則)/自律実行の設計を担った側 | 送信・実行ログ、公開記録、取引記録、停止操作の記録 |
【推奨(契約実務)】このレイヤー分解は、契約条項にも落とし込めます。責任分担条項で「上位プラットフォームに起因する事象」「ベンダー独自実装に起因する事象」「RAG・カスタマイズに起因する事象」「利用企業の運用に起因する事象」を切り分けて定義しておくと、事故後の交渉が格段に進めやすくなります。あわせて、②〜④の証跡についてはベンダー側にしか存在しないため、事故時のログ提供義務を必ず取りにいってください。
5. 事故類型ごとの責任分界の考え方
各類型について、責任判断の出発点をまとめたのが次の表です。ここに書いてあるのは交渉前のたたき台であり、法的な結論ではありません。実際の帰結は、AIの利用形態(補助/支援型か依拠/代替型か)、ベンダーの性質(汎用AIか、カスタマイズAIか、オンプレAIか)、用途、契約形態によって変わり、最終的には各主体について不法行為・債務不履行の要件を個別に検討することになります。
AI事故類型別の責任分界表
| 事故類型 | 想定される原因レイヤー | 責任判断の出発点(個別判断が必要) | 契約で明確化すべき点 |
|---|---|---|---|
| 誤答・幻覚 | ①入力/②モデル/③RAG/④実装/⑤レビュー | 補助/支援型では、出力を検証して用いる利用企業側の注意義務が中心。ただしモデル性能に関する説明・保証との乖離、RAG・実装の不具合はベンダー側の債務不履行・過失の問題となり得る | 出力の正確性に関する保証範囲、人のレビューを前提とする旨、性能に関する説明資料の契約への取込み |
| 第三者権利侵害 | ②モデル(学習データ)/①入力(模倣指示)/⑥外部行為(公表) | 出力の権利侵害性を評価・検証すべき立場は利用企業にあることが多い一方、権利侵害の高度の危険性が見込まれるのに防止措置を欠く提供は開発者・提供者の設計上の注意義務の問題となり得る | 知財補償条項、フィルタリング・確認運用の分担、公表前チェックの責任者 |
| 個人情報漏えい | ①入力/②モデル(学習利用)/④実装(アクセス制御) | 個人データの提供が委託・第三者提供・共同利用・ベンダー独自利用のいずれに当たるかで法的整理が変わる(6-3参照)。当然に利用企業のみが責任主体となるわけではない | 入力データの学習利用可否、委託/第三者提供の別、越境移転の根拠、再委託先の管理、報告・通知の役割分担 |
| 秘密情報流出 | ①入力/④実装/⑥外部行為 | 共同管理(両側に義務)。ベンダーのセキュリティ体制と、利用企業の入力管理・アクセス管理の双方が問題になる | 守秘義務・情報管理措置、ログ閲覧権、漏えい時連絡義務、事故時の調査協力 |
| サービス停止 | ②モデル/④実装/上位プラットフォームの障害 | ベンダー側の債務の問題となるのが基本だが、契約上の免責が広く設定されているのが実情 | SLA、稼働率、代替手段、長期停止時の解除権、上位障害時の取扱い |
| アルゴリズム・バイアス | ②モデル(学習データ)/④実装/用途設定 | 共同管理。モデル側(学習データ・モデル構造)はベンダー、用途適合性(業務への使い方)は利用企業という切り分けが出発点 | 評価・テスト結果の開示、モニタリング、用途拡張時の再評価、是正手続 |
| 不適切利用 | ①入力/⑤レビュー/⑥外部行為 | 契約上は利用企業側の管理責任が中心 | 利用規約違反時の措置、アカウント停止の前置手続、ベンダーの通知義務 |
6. 類型別の実務対応
6-1. 誤答・幻覚:「原則利用企業責任」と単純化しない
生成AIの誤答は、多くの契約で「出力の正確性は保証しない」と明記され、利用企業側がレビューすることが前提になっています。手引きの整理でも、補助/支援型AIでは利用者の本来の注意義務が維持されるため、「AIが間違えた」という抗弁は通りにくい方向です。
もっとも、誤答をすべて「利用企業責任」と分類するのは不正確です。原因ごとに責任判断の材料が異なります。
| 誤答の原因 | 典型例 | 責任判断で効いてくる要素 |
|---|---|---|
| モデル自体の確率的不正確性 | 存在しない判例・条文・製品仕様を生成する | 技術的に不可避な範囲か。性能限界・重要リスクについてベンダーが明確に説明していたか。利用企業が検証工程を置いていたか |
| RAG・検索実装の不具合 | 参照すべき最新規程を索引していない、権限外文書を参照する、取得スニペットが欠落する | RAGの構築・運用を誰が担っていたか。仕様との適合性。更新運用の分担合意。ベンダーの債務不履行として構成できる余地が大きい領域 |
| 保証した性能との乖離 | 提案書・デモ・SLAで示した精度水準を明らかに下回る | 説明資料・提案書が契約内容に取り込まれているか。仕様適合性・契約不適合の問題として構成できるか |
| 利用者側の入力ミス | 前提条件を誤って入力、旧版の資料を添付、指示が不明確 | 入力ルールの整備・周知。入力ログ。過失相殺的な評価 |
| 人のレビューの欠如 | レビュー工程を省略して外部提供、形式的な確認のみ | 補助/支援型として運用する前提が崩れる。利用企業側の結果回避義務違反と評価されやすい |
【推奨(契約実務)】交渉ポイントは、保証の有無そのものではなく、(1)利用目的に関する説明資料と実態が乖離していないか、(2)ベンダー側の「通常の技術水準を下回るミス」まで免責しているか、の2点です。特にRAG型サービスや業務特化型AIの場合、ナレッジベースの更新不備やRAG構成の欠陥を保証否認条項の例外として切り出す交渉の余地があります。
6-2. 第三者権利侵害への対応
AI出力が第三者の著作権・意匠権・肖像権・パブリシティ権等を侵害した場合、知財補償条項(IP indemnity)を設けているベンダーもあります。ただし、主要ベンダーが一律に同じ補償を提供しているわけではありません。補償の内容は契約・プラン・提供形態(コンシューマ/エンタープライズ/API)によって大きく異なり、また改定も頻繁です。「大手だから補償がある」という前提を置かず、その案件の契約条件を都度確認してください。
確認すべきは次の項目です。
- 補償の対象(著作権のみか、意匠・商標・特許・肖像権まで含むか)
- 補償の対象者(自社のみか、自社の顧客まで及ぶか)
- 補償の前提条件(指定フィルタ・安全機能の利用、指示違反がないこと、出力の改変がないこと等)
- 除外事由(入力データ起因、模倣を意図した指示、ファインチューニング、第三者データの混入等)
- 補償の上限(年間支払額か、利用料の一定倍数か、上限なしか)
- 通知・協力義務と、訴訟防御の主導権(ベンダーが防御を引き取るのか、和解に自社の同意が必要か)
- 第三者から直接請求された場合に、一旦自社で賠償してから求償できる構造になっているか
「補償条項がある」と書いてあるだけでは不十分で、条件が厳しく実際には発動しないケースもあります。条項を具体的に読み込んでください。
6-3. 個人情報漏えい:まず「どの法的構成か」を決める
ここが本記事でもっとも誤解の多い論点です。「AIベンダーに入力したら常に利用企業が一次的責任主体」と一律に整理するのは正確ではありません。個人データをAIベンダーに提供する場合、法的構成は少なくとも次の4パターンに分かれ、それぞれ適用される規律が異なります。
| 法的構成 | 典型的な場面 | 主に適用される規律 | 実務上の要点 |
|---|---|---|---|
| ①個人データ取扱いの委託 | ベンダーが利用企業の指示の範囲でのみ処理し、自社目的で利用しない(学習利用なし) | 本人同意は不要(法27条5項1号)。委託元に委託先の監督義務(法25条)と安全管理措置(法23条) | 委託の範囲、再委託、学習利用の禁止、監督の具体的方法(契約・報告・監査)を書き込む |
| ②第三者提供 | ベンダーが自社目的(モデル学習等)でも利用する場合など、委託の枠に収まらない提供 | 原則として本人の同意が必要(法27条1項)。記録義務(法29条) | 同意取得が現実的かを事前に判断。取得できないなら学習利用オプトアウトを契約で確定させる |
| ③共同利用 | グループ会社・提携先とAI基盤を共同で利用する場合 | 法27条5項3号の要件(利用目的、項目、範囲、管理責任者等の通知・公表) | 要件を満たさないまま「共同利用」と称している例が多い。公表内容の実在を確認 |
| ④ベンダー自身による独自利用 | ベンダーが自らの判断で取得・利用(サービス改善、モデル学習、統計利用等) | ベンダー自身が個人情報取扱事業者としての義務を負う(利用目的の特定・通知公表、取得の適正性等) | ベンダー側の責任領域。利用企業としては、提供の適法性と説明可能性を確保する必要がある |
さらに、ベンダーが海外事業者である場合や、データが海外サーバで処理される場合は、外国にある第三者への提供の制限(法28条)の適用を検討する必要があります(委託構成であっても、外国にある委託先への提供は法28条の規律を受け得ます)。
【推奨(ガイドライン)】個人情報保護委員会は2023年6月2日に「生成AIサービスの利用に関する注意喚起等」を公表しており、個人情報を含むプロンプトを入力する場合には特定した利用目的の達成に必要な範囲内であることを十分に確認すること、応答結果の出力以外の目的(機械学習等)で取り扱われる場合には法違反となる可能性があるため、当該サービス提供事業者が個人データを機械学習に利用しないこと等を十分に確認すべきことなどを示しています。AI導入時の入力ルール設計では、この文書が実務上の出発点になります。
6-4. 漏えい発生時の報告期限(正確な整理)
【法的義務】報告対象事態(施行規則7条各号の4類型)が生じた場合、個人情報取扱事業者は個人情報保護委員会(権限委任がある場合は事業所管大臣)に報告し、本人に通知する義務を負います(法26条)。期限の整理は次のとおりです。
| 区分 | 法令上の規律 | 実務上の目安・注意点 |
|---|---|---|
| 速報 | 報告対象事態を知った後、「速やかに」報告(施行規則8条1項)。日数は法令に明記されていない | 通則編ガイドラインは、事態を知った時点からおおむね3〜5日以内を目安としています。これは法定の日数ではなくガイドライン上の目安です。その時点で把握している事項を報告すれば足ります |
| 確報 | 報告対象事態を知った日から30日以内(施行規則8条2項) | 起算点は「知った日」。法人の場合、いずれかの部署が知った時点が基準になります |
| 確報(不正目的のおそれ) | 不正の目的をもって行われたおそれがある行為による漏えい等(規則7条3号事案)は60日以内 | ランサムウェア、不正アクセス等が典型。調査が長期化する事案でも期限は動きません |
| 本人通知 | 事態の状況に応じて速やかに通知(法26条2項)。困難な場合は代替措置 | 報告と通知は別の義務です。公表は代替措置の一態様であって、通知の代替が常に認められるわけではありません |
| 委託先事故 | 委託先が、報告義務を負う委託元に対し、把握している事項を速やかに通知した場合、委託先の報告義務・本人通知義務は免除される(法26条1項ただし書、施行規則9条) | 「委託先が事故を起こしても委託元だけが報告する」という単純な構造ではありません。原則として双方が義務主体であり、通知によって委託先が免除される建付けです |
「72時間以内の通知」は日本法上の法定期限ではありません
AI契約のレビューで「ベンダーからの通知は発見後72時間以内とすべき」と一律に書かれた解説を見かけますが、72時間は日本法上、AIベンダーに一律に課される法定期限ではありません(GDPR33条の監督機関への通知期限に由来する数字です)。
【推奨(契約実務)】契約上の通知期限は、①自社が負う法定報告期限(速報の目安3〜5日、確報30日/60日)から逆算し、②社内のインシデント対応体制(検知・エスカレーション・意思決定に要する時間)、③ベンダーの役割(委託先か、第三者提供先か、独自利用者か)を踏まえて具体化してください。実務的には、「ベンダーが事態を認識した後○時間以内に一次通知(既知の事項のみで可)、以後△時間ごとに続報、確報作成に必要な情報は□日以内に提供」といった段階的な通知義務として設計するほうが機能します。
なお、2026年7月10日に成立し同月17日に公布された改正個人情報保護法(令和8年法律第56号)では、課徴金制度の導入、子どもの個人情報・特定生体個人情報の規律、委託を受けた事業者の規律、漏えい等発生時の本人通知に関する見直し等が盛り込まれています。主要部分は未施行(原則として公布から2年を超えない範囲内で政令で定める日、罰則の一部は2027年1月17日先行施行)であり、政令・規則・ガイドラインの整備が進行中です。現行制度と混同しないよう注意してください。
6-5. サービス停止・障害への対応
サービス停止については、ほとんどのベンダー契約で免責が広く設定されています。稼働率保証(例:月間99.9%)があっても、超過分の返金上限が月額料金の一部に限定され、実損害の回復にはならないケースが大半です。さらに、上位のプラットフォーム側の障害が起きた場合、国内ベンダーが「当社の責めに帰すべき事由ではない」として免責を主張する構造もあります(Back-to-Back構造の帰結です)。
法務の役割は、事故を防ぐことよりも、長期停止が起きたときに解除できるか、代替手段があるかを確認することに移ります。SLA違反が一定回数・一定期間を超えた場合の中途解約権の確保は、交渉の最後に必ず入れておきたい条項です。
6-6. アルゴリズム・バイアスへの対応
学習データの偏りや用途への不適合により、採用・与信・人事評価等で不当な差別的出力や公平性を欠く判定が行われるケースは、AI事業者ガイドライン第1.2版でも公平性・透明性・アカウンタビリティの観点から扱われています(同ガイドラインは法律ではなく、違反に罰則があるわけではありません)。責任分界の考え方は共同管理が基本で、モデル側(学習データとモデル構造)はベンダー、用途適合性(業務への使い方)は利用企業という切り分けが出発点です。
【推奨(契約実務)】ベンダーに対してモデルの評価・テスト結果の開示を求めつつ、利用企業側も用途拡張時に再評価を行うという運用責務を明記するのが現実的です。社内的には、モニタリング体制と、是正の必要が生じたときの利用停止・運用見直しのフローを定めておくべき論点になります。
なお、EUでは採用・与信・教育等の用途は高リスクAIとして規律されますが、その適用時期は後述のとおり延期されています(第9章)。国内法上、これらの用途を直接規律する横断的なAI規制法は現時点で存在しません。
6-7. 不適切利用への対応
従業員が利用規約違反の使い方をした場合、契約上の責任は原則として利用企業にあります。ここでベンダーに求めるべきは「事故を防ぐ義務」ではなく、違反が検知された場合の通知義務と、合理的な利用停止の前置手続です。いきなりアカウント停止されて業務が止まる事態を避けるためです。
7. AIエージェントの責任分界
2026年時点で実務上もっとも論点が集中しているのがAIエージェントです。AI事業者ガイドライン第1.2版では、第1.1版からの更新点としてAIエージェント・フィジカルAIに関する記述が追加され、特定の目標を達成するために環境を感知し自律的に行動するAIシステムとして整理されています(【推奨(ガイドライン)】であり法規制ではありません)。
経産省の民事責任手引きは、AIエージェントを補助/支援型にも依拠/代替型にもなり得るものと位置づけ、個別技術やユースケースへの依存が強いため当事者の責任を個別具体的に整理することは現時点では困難としつつ、手引きの基本的な考え方が高度なシステムを検討する際の基礎になると指摘しています。カスタマーサポートの想定事例では、品質・精度が同種業務の通常人と同等以上の水準を発揮している場合には依拠/代替型に、回答精度が十分でない場合には補助/支援型に該当し得ると整理されています。
実務的な含意は明確です。「どちらの型として使うかを自社が選択し、選択した型に見合った体制を構築していたか」が問われます。依拠/代替型として運用するなら、AIに判断を委ねることの合理性を裏付ける検証と、誤出力を防ぐ体制の構築が必要になります。
アクション類型別の権限設計
| 自律アクション | 主なリスク | 権限境界の設計 | 承認・停止の設計 |
|---|---|---|---|
| メール送信 | 誤送信、機密情報の外部流出、誤った意思表示と受け取られる文面 | 宛先ドメインのホワイトリスト、社外送信の禁止/制限、添付可否 | 社外宛は人の承認を必須化。下書き生成までに留める運用を既定値に |
| 発注・支払 | 誤発注、二重発注、金額誤り、取引先誤り | 金額上限、取引先マスタの範囲内に限定、カテゴリ制限 | 一定金額以上は人の承認。取消・返品フローの事前整備 |
| データ更新 | 基幹データの破壊、権限外データへの書込み、不可逆な更新 | 読み取り専用を既定値とし、書込みは対象テーブル・項目を限定 | ロールバック手順、更新前スナップショット、夜間バッチの停止条件 |
| 契約処理 | 権限のない契約締結・承諾と評価されるリスク、条件の誤り | 締結権限は与えない設計を原則に。ドラフト・比較・要約に限定 | 締結行為は必ず人の決裁を経由。社内規程の職務権限表との整合を確認 |
| 顧客対応 | 誤案内、不適切表現、個人情報の取扱い、確約と受け取られる回答 | 回答可能な範囲・トピックの限定、エスカレーション条件の定義 | クレーム・返金・法的請求はただちに人へ引き継ぐ。AI対応であることの明示(EU向けは第50条の対象) |
| 外部API実行 | 第三者システムへの影響、レート超過、外部サービス規約違反 | 呼び出し可能なAPI・スコープ・回数の制限、認証情報の分離 | 実行ログの完全保存、異常検知時の自動停止(サーキットブレーカ) |
AIエージェント導入時に責任分界の観点から詰めるべき5点
- 権限境界:エージェントが実行できるアクションを列挙し、それ以外を実行できない構成になっているか(できることを制限するのではなく、できることだけを許可する設計か)
- Human-in-the-Loop:どの判断・どの金額・どの相手方で人の介在を必須とするかを、業務単位で定義しているか。介在させないと判断した場合、その合理性を裏付ける検証記録があるか
- 停止権限:誰が、どの手段で、どれくらいの時間で全停止できるか。停止権限者が不在の時間帯の運用はどうするか
- ログ:入力・モデル応答・ツール呼び出し・外部実行・承認の各段階が、事後に再構成できる粒度で保存されているか。保存期間と、ベンダー側ログの提供義務は契約に書かれているか
- 承認工程:承認が形式的な「押すだけ」になっていないか。承認者に判断材料(根拠データ、参照ドキュメント、信頼度)が提示される設計か
契約上の含意
エージェント型では、「誰が権限設計をしたか」が責任分界の起点になります。ベンダーが標準機能として権限制御を提供しているのか、利用企業が設定したのか、SIerが個別実装したのかで、事故時の評価は変わります。設定作業の担当と、設定内容の妥当性確認の責任者を、契約書または個別合意書で明示してください。
8. 契約で見ておきたい条項
責任分界の観点で優先的に見るべき条項を、「契約条項でどこに落とすか」の視点で整理します。
共同管理で整理しておくべき典型項目
| 項目 | 共同管理で定めるべき内容 |
|---|---|
| 出力の利用目的適合性 | ベンダー説明資料と実用途の整合、用途拡張時の再確認義務、補助/支援型か依拠/代替型かの前提合意 |
| 補償条項の発動条件 | フィルタ利用・指示遵守等の条件設定と、通知・協力義務・訴訟防御の手続 |
| 漏えい時の対応 | 自社の法定報告期限から逆算した段階的通知、調査協力、ログ提供、本人通知の役割分担、再発防止の共同検討 |
| 稼働・障害対応 | 障害時の報告・復旧協力、代替運用とBCPの分担、上位プラットフォーム障害時の取扱い |
| エージェントの権限設定 | 権限設計の担当、設定変更の承認手続、停止権限、ログの保存・提供 |
| 契約終了時の過渡期 | 移行期間の運用責任分担、データ返却・消去の具体手続と完了証明 |
8-1. 保証否認条項
「現状有姿(AS IS)」「一切の保証を行わない」といった広範な保証否認は、AI契約でほぼ必ず登場します。全面削除は現実的ではないものの、少なくともベンダーの故意・重過失、秘密保持義務違反、個人情報取扱違反、知財侵害を免責から外す(carve-out)ことは、交渉で持ち出すべき論点です。
ただし、これらを一律にcarve-outすべきと断定するのは適切ではありません。carve-outの範囲は、案件のリスクの大きさ、当事者の交渉力、ベンダーの保険付保状況、サービス対価の水準によって変わります。少額のツール導入で無制限の責任を求めれば、ベンダーは対価を上げるか、取引自体を断ることになります。「何をcarve-outするか」ではなく「このリスクに、この対価で、どこまでの責任を求めるのが合理的か」という交渉事項として整理してください。
8-2. 損害賠償上限条項
AIベンダー契約では、賠償上限が「過去12か月に支払った利用料」や「事故発生月の利用料」に限定されているケースが多く見られます。少額利用の段階では問題になりにくいのですが、本格導入後に一度事故が起きると、上限金額が実損害と大きく乖離するのが実務上の問題です。
交渉で検討する選択肢は次のとおりです。いずれも「必ず取るべき水準」ではなく、リスクに応じて選ぶカードです。
- 上限金額を契約総額や年間料金の複数倍に引き上げる
- 特定の事由(個人情報漏えい・秘密保持違反・知財侵害・故意重過失)について、通常上限より高いスーパーキャップを設定する(上限の完全撤廃だけが選択肢ではありません)
- ベンダーが加入するサイバー保険・E&O保険の付保内容と支払限度額を確認し、実際に回収可能な水準を見極める
- 逸失利益・間接損害の扱い(除外するのか、上限の内側に取り込むのか)を明確にする
上限を無制限にしても、ベンダーに支払能力がなければ意味がありません。「条項上の上限」と「現実の回収可能性」を分けて評価するのが実務です。
8-3. 免責条項
免責が広すぎる条項は、重大過失・故意・守秘違反・個人情報事故がcarve-outされているかを確認します。carve-outがない場合、ベンダーに明らかな過失があっても責任追及しにくくなります。前記のとおり、どこまでを外すかは案件ごとの判断です。
8-4. 補償条項(知財補償・個人情報漏えい補償)
補償条項は「あるかないか」ではなく、発動条件・手続・上限・除外で実効性が決まります。発動条件が「ベンダーが指定したフィルタを利用したこと」「ユーザが明示的な指示違反をしていないこと」となっている場合、カスタム利用や独自のプロンプト設計を行うとすぐに外れる構造になりがちです。6-2の確認項目に沿って、条項単位で読み込んでください。
8-5. 解除条項
解除条項は、SLA違反・セキュリティ事故・法令違反・業務不適合時に解除できるかが核です。解除後のデータ消去義務と、過渡期の運用責任も合わせて確認します。AI契約では移行コストが大きい(プロンプト資産・運用ノウハウ・RAGインデックスの再構築)ため、解除権を取りにいく実益は通常のSaaSより大きくなります。
8-6. Back-to-Back条項(上位プラットフォーマー免責との連動)
国内SIerや国内AIベンダー経由で海外プラットフォーマーのAPIを利用する場合、契約書に「上位プロバイダが免責されている範囲については当社も責任を負わない」趣旨のBack-to-Back条項が入っていることがあります。
この条項は、国内ベンダーの側から見れば事業継続上やむを得ない面がありますが、そのまま受け入れると上位プロバイダの利用規約が実質的な天井になります。ただし、上位プラットフォーマーの免責が当然に国内ベンダーへ転嫁されるわけではありません。事故原因を切り分けたうえで、連動の範囲を限定するのが実務です。
| 事故原因の区分 | 典型例 | Back-to-Back連動の妥当性 |
|---|---|---|
| 上位サービス起因 | 基盤モデル側の障害、モデル差替えによる挙動変化、上位側の仕様変更 | 連動に一定の合理性がある。ただし、変更の事前通知義務・代替手段の提供義務は別途求める |
| 国内ベンダー独自実装起因 | プロンプトテンプレート、後処理、権限制御、UI、連携基盤の欠陥 | 連動させるべきでない。ベンダー自身の債務として責任を負ってもらう領域 |
| RAG・カスタマイズ起因 | ナレッジ構築、索引設定、ファインチューニング、業務辞書の整備 | 誰が構築・運用しているかで切り分ける。ベンダー主導なら連動対象外 |
| 運用起因 | 利用企業の入力・設定・レビュー体制、社内ルール違反 | 利用企業側の領域。ただしベンダーの通知義務・注意喚起義務は残る |
あわせて、レビュー時には次の3点を確認してください。
- Back-to-Back条項の射程(免責・賠償上限・解除・知財補償のどこまで連動するか)
- 上位プロバイダの利用規約変更時に、自動的に国内ベンダー契約の条件も変わる構造になっていないか。変更時の事前通知と、受け入れられない場合の解除権があるか
- ベンダー独自の付加価値部分については、上位プロバイダ免責の外で独自の責任を負う設計になっているか
9. 実務で交渉対象にしやすいポイント
ベンダーが汎用大手の場合、標準利用規約のままで交渉余地がない条項は多いのですが、エンタープライズ契約や、国内SIer経由の契約、日本のAIスタートアップとの契約では、以下の項目は比較的交渉しやすい領域です。
契約交渉で修正したい典型条項一覧
| 条項 | ベンダー案に多いパターン | 交渉で検討する水準 |
|---|---|---|
| 入力データの学習利用 | 学習利用にオプトアウトが必要/記載が曖昧 | 学習利用の不使用を契約で確定。個人データを含む場合は委託・第三者提供・共同利用のいずれの構成かを明記 |
| 賠償上限 | 過去12か月の利用料を上限 | リスクに応じた引上げ、重要事由へのスーパーキャップ、保険付保内容の確認 |
| 免責条項 | 一切の結果責任を否認 | 故意・重過失・守秘違反・個人情報事故の扱いを個別に交渉 |
| 知財補償 | 補償条件が厳しい/対象が限定 | 対象・除外・上限・訴訟防御の主導権・求償経路を条項単位で確認し、必要な範囲を拡張 |
| 通知義務 | 「速やかに」等の曖昧表現 | 自社の法定報告期限(速報の目安3〜5日、確報30日/60日)から逆算した段階的通知期限を明記 |
| ログ提供 | ログ閲覧権なし | 事故時に、モデル・バージョン・RAG参照先・ツール呼び出し履歴を含む合理的範囲でのログ提供 |
| 仕様・性能の説明 | 提案書・デモは契約外 | 性能・利用目的に関する説明資料を契約の一部に取り込む(保証否認条項との優先関係も明記) |
| 準拠法・管轄 | ベンダー所在国・国際仲裁 | 第一希望は日本法・東京地裁。難しい場合は国際仲裁のコスト・時間・執行リスクを評価し受容可否を判断 |
| 解除後のデータ | 合理的期間内に削除 | 期間を具体的に明記、削除完了証明の提供、バックアップ・学習済みモデルからの扱いも確認 |
| Back-to-Back条項 | 上位プロバイダ免責と全面連動 | 原因区分による切り分け、ベンダー独自レイヤーの除外、条項変更時の事前通知と解除権 |
国際仲裁をやむなく受ける場合の注意点
準拠法・管轄を日本に寄せられず、シンガポール等での国際仲裁となる場合、(1)仲裁費用の高額化、(2)審理に要する時間、(3)執行可能性、の3点を事前に評価してから受諾するのが実務上のスタンダードです。特に中小規模の利用企業にとっては、仲裁費用が実損害を上回るリスクがあり、結果的に「紛争解決できない契約」になっていないかを確認する必要があります。AI事故は複数法域にまたがりやすく、手続法上の論点が増える点にも留意してください。
10. EU AI Actの現在地(2026年9月8日時点)
EU向けにサービスを提供する場合、または出力がEUで利用される場合は、EU AI Act(Regulation (EU) 2024/1689)の適用を検討する必要があります。2026年に大きな動きがあったため、タイムラインを正確に把握してください。
10-1. Digital Omnibus on AIによる改正
2026年7月8日に採択されたRegulation (EU) 2026/1744(Digital Omnibus on AI)がEU官報に2026年7月24日に掲載され、同月27日に発効しました。これはAI Act採択後初の実質的改正であり、高リスクAI規律の適用時期を延期する一方、第50条の透明性義務は原則として当初のスケジュールどおり維持しています。
10-2. 適用時期のタイムライン
| 時期 | 適用される規律 |
|---|---|
| 2024年8月1日 | AI Act発効 |
| 2025年2月2日 | 禁止されるAI慣行(第5条)、AIリテラシー義務(第4条) |
| 2025年8月2日 | 汎用AI(GPAI)モデル提供者の義務、ガバナンス・罰則関連規定 |
| 2026年8月2日 | 一般適用日。第50条の透明性義務が適用開始(延期されていません) |
| 2026年12月2日 | ①2026年8月2日より前に上市されたシステムについて、第50条2項の機械可読マーキング義務の猶予期間が終了。②Digital Omnibusで追加された新たな禁止行為(同意なき性的画像の生成等、児童性的虐待素材の生成)が適用開始 |
| 2027年12月2日 | 附属書III掲載のスタンドアロン型高リスクAI(採用・与信・教育・重要インフラ等)の義務。2026年8月2日から延期 |
| 2028年8月2日 | 附属書I(EU製品安全法制)対象製品に安全部品として組み込まれる高リスクAIの義務 |
10-3. 第50条の透明性義務
欧州委員会は2026年7月20日に第50条の実施ガイドラインを最終版として採択し、あわせて「AI生成コンテンツの透明性に関する実践規範(Code of Practice)」が委員会およびAI Boardにより適合的(adequate)と評価されました。委員会FAQによる主な内容は次のとおりです。
- 第50条1項(提供者):人と直接やり取りするAIシステム(チャットボット、AIエージェント、アバター等)は、AIとやり取りしていることが分かるように設計する。明白な場合の例外は限定的に解釈される。
- 第50条2項(提供者):合成音声・画像・動画・テキストを生成するAIシステムの出力に、機械可読なマーキングを施し検出可能にする。短い記号列、ソースコード、機械間通信のみに用いられる出力等は対象外。B2B・産業用途については限定的な適用除外がガイドラインで想定されています。
- 第50条3項(デプロイヤー):感情認識システム・生体分類システムにさらされる者への情報提供。
- 第50条4項(デプロイヤー):ディープフェイクの表示、および人のレビュー・編集責任を経ずに公共の関心事項について公衆に情報提供する目的で公表されるAI生成テキストの表示。実質的な人のレビューまたは編集上の管理を経た場合は対象外(スペルチェック等の形式的確認では足りません)。
- 執行:主として加盟国の市場監視当局が執行します。AI Officeの役割は限定的です。第50条違反の制裁金は最大1,500万ユーロまたは全世界年間売上高の3%のいずれか高い額に達し得ます。
- 遡及適用:2026年8月2日より前に生成されたコンテンツを遡って表示する義務はありません。
「EU向けサービスならすべて同じ義務」ではありません
AI Actの義務は役割(provider/deployer/importer/distributor等)ごとに異なります。自社が「AIシステムを自己の名称・商標で市場に出す提供者」なのか、「自己の権限の下でAIシステムを業務利用するデプロイヤー」なのかで、負う義務は変わります。
また、域外適用の判断も一律ではありません。委員会FAQは、EU域外に所在する提供者であっても、そのAIシステムの出力がEU内で用いられる場合にはAI Actの規定に服し得ること、デプロイヤーについては、グローバルにアクセス可能なインターネット上にディープフェイクを掲載する行為がEU向けの特定のターゲティングを要することなく第50条4項の義務を生じさせ得る、との解釈を示しています。
「EUに拠点がないから関係ない」「EU向け販売がないから関係ない」という単純な結論は避け、役割・出力の到達範囲・提供形態を個別に確認してください。
11. 国内のソフトローと基本法
11-1. AI事業者ガイドライン(第1.2版)
総務省・経済産業省は2026年3月31日に「AI事業者ガイドライン(第1.2版)」を公表しました。2024年4月の第1.0版、2025年3月の第1.1版に続く改訂で、主な更新点は、①AIエージェント・フィジカルAIに関する事項の追記、②AIによるリスクの記載の見直し、③各主体に関する記載や別添事例の拡充、AI推進法・適正性確保指針への参照の追加です。AI開発者・AI提供者・AI利用者という3主体の区分、10の共通の指針、リスクベースアプローチという骨格は維持されています。
【重要】本ガイドラインは法律ではなく、法的拘束力を持ちません。違反しても罰則の対象にはなりません。もっとも、関係省庁・大企業の調達基準やセキュリティ評価で参照されるため、実務上は事実上の要求仕様として機能します。また、前述のとおり民事責任手引きは、AI事業者ガイドラインの考え方も踏まえた体制構築が、事後の過失判断において斟酌され得ることを示しています。
契約設計に落とし込む際は、安全性・公平性・プライバシー保護・セキュリティ確保・透明性・アカウンタビリティといった共通の指針を、「誰が、どの工程で、どう担保するか」という分担の言語に翻訳するのが実務的です。たとえば透明性であれば、ベンダー側の「性能・限界の説明義務」と、利用企業側の「エンドユーザへのAI利用の明示」に分解できます。
11-2. AI推進法(人工知能関連技術の研究開発及び活用の推進に関する法律)
正式名称は「人工知能関連技術の研究開発及び活用の推進に関する法律」(令和7年法律第53号)です。施行状況を正確に押さえておきます。
- 2025年6月4日:公布、および一部施行
- 2025年9月1日:人工知能戦略本部の設置に係る規定等を含め全面施行(内閣府公表)
- 本則28条・附則2条。第1章 総則、第2章 基本的施策、第3章 人工知能基本計画、第4章 人工知能戦略本部という構成
- 同法に基づき、2025年12月19日に「人工知能関連技術の研究開発及び活用の適正性確保に関する指針」が決定され、2025年12月23日に人工知能基本計画が閣議決定されています
したがって、「2025年9月1日全面施行」という表現自体は正確です。ただし、同法は基本法的な性格の法律であり、AIの利用に個別の禁止行為や制裁を課す規制法ではありません。
「活用事業者の責務」を契約上の損害賠償責任と混同しないでください
同法7条は、活用事業者について「基本理念にのっとり、自ら積極的な人工知能関連技術の活用により事業活動の効率化及び高度化並びに新産業の創出に努めるとともに、第四条の規定に基づき国が実施する施策及び第五条の規定に基づき地方公共団体が実施する施策に協力しなければならない」と定めています。
これは国・地方公共団体の施策への協力等に関する責務規定であり、AI事故が起きたときの民事上の損害賠償責任の根拠となる規定ではありません。「AI推進法に責務があるからベンダーに責任がある」といった論理は成り立ちません。民事責任はあくまで契約または不法行為法(民法709条以下)等によって判断されます。
12. 社内運用で吸収すべき部分
契約で全てを取りにいくのは現実的ではないため、契約の外側──つまり社内ルールとレビュー運用で吸収すべき部分を整理しておくことも、法務の重要な仕事です。前述のとおり、これらの整備は事後の過失判断でも意味を持ち得ます。
- AI出力は人がレビューしてから外部提供するという原則を、社内規程・ガイドラインに落とし込む(=補助/支援型として運用することを明確化する)
- 依拠/代替型として運用する業務を限定し、その選択の合理性を裏付ける検証記録を残す
- 機密情報・個人情報の入力禁止ラインを明確化する(具体例付きで)
- 重要な判断(契約条件の決定、与信判断、人事判断など)は、AI出力のみで決めない
- ログ保存期間とインシデント発生時の対応フローを事前に決めておく(レイヤー別に何を保存するかを決める)
- 利用範囲・用途を限定し、用途拡張は法務レビューを経由する
- AIエージェントを業務に組み込む場合は、権限境界・Human-in-the-Loop・停止権限・ログ・承認工程を設計文書として残す
- ISO/IEC 42001等のAIマネジメントシステム規格を参考に、自社のAIガバナンス体制を文書化する
- EU域内の顧客・ユーザにAIが直接応対する構成、または合成コンテンツを公開する構成の場合は、第50条の適用有無を役割ベースで確認する
契約上の責任分界は、社内ルールで補完されて初めて実効性を持ちます。「契約で勝ちにいく」発想と同じくらい、「運用で吸収する」発想が必要です。
13. 事故発生後の法務対応フロー
AI事故が起きたときに、法務が着手すべき順序をチェックリスト化しました。順序が重要です。証跡の保全に失敗すると、その後の責任分析も交渉も成立しません。
AI事故発生後の10ステップ
- 入力・利用状況の保全:誰が、いつ、どの業務で、どのようなプロンプト・添付データを入力したかを確定させる。ヒアリングだけでなく、画面・ファイル・チャット履歴を確保する
- モデル・システム・RAGの特定:使用されたモデル名とバージョン、システムの版数、RAGの索引状態と参照先ドキュメントを特定する。ベンダーに照会が必要な場合はこの段階で正式に発出する
- ログ保全:入力・出力・ツール呼び出し・外部実行・承認の各ログについて、上書き・自動削除を停止する。ベンダー側ログの保全と提供も同時に要請する(保存期間が短いことが多く、初動が遅れると失われます)
- 人のレビュー状況の確認:レビュー工程が設計どおり機能していたか、承認記録が残っているか、形式的確認にとどまっていなかったかを確認する
- 外部影響の確認:誤答・生成物が外部に到達したか、誰に、どの範囲で。取引・支払・契約行為が実行されていないか。回収・訂正が可能か
- 法令対応の要否判断:個人情報(法26条の報告対象事態該当性、報告・本人通知の期限)、知的財産(権利者からの通知の有無)、業法・広告規制・下請関係法令等について、それぞれ独立に判断する
- ベンダー通知:契約上の通知義務の履行。通知期限、通知先、通知方法を契約で確認したうえで、記録が残る方法で行う。補償条項の発動には期限内通知が条件になっていることが多い点に注意
- 契約上の責任分析:レイヤー別の原因特定を踏まえ、保証否認・免責・賠償上限・補償・Back-to-Back条項の適用関係を整理する。求償の経路(契約上の補償か、不法行為に基づく求償か)を確定する
- 再発防止:原因レイヤーに対応した措置を設計する(入力ルール、RAG更新運用、権限設計、承認工程、モニタリング)。措置の決定過程を記録として残す
- 利用再開判断:誰が、どの条件が満たされたら再開を決定するのかを事前に定めておく。暫定運用(機能限定・人の承認必須化)を挟む選択肢も検討する
14. チェックリスト
AI契約の責任分界チェックリスト
- 自社の使い方は「補助/支援型」か「依拠/代替型」か。前提を社内とベンダーで共有できているか
- AI出力を人がレビューする前提の契約設計になっているか
- 出力をそのまま外部提供・公表する運用を前提にしているか(していれば責任配分を見直す)
- ベンダーが精度や正確性についてどこまで説明・保証しているか。説明資料が契約に取り込まれているか
- 誤答の原因レイヤー(モデル/RAG/実装/入力/レビュー)ごとに責任領域が定義されているか
- 第三者権利侵害時の補償(IP indemnity)の有無と、対象・発動条件・上限・除外・訴訟防御・求償経路を確認したか
- 個人データの提供が委託・第三者提供・共同利用・ベンダー独自利用のどれに当たるかを確定させたか
- 委託構成の場合、委託先の監督(法25条)を実施できる契約条項・報告手続になっているか
- 越境移転が発生する場合、法28条の対応(同意または基準適合体制等)が取れているか
- 漏えい時の通知期限が、自社の法定報告期限(速報の目安3〜5日、確報30日/60日)から逆算されているか
- 事故時のログ提供義務(モデル・バージョン・RAG参照先・実行履歴)が契約にあるか
- 損害賠償上限が実損害と乖離していないか。重要事由へのスーパーキャップや保険付保状況を確認したか
- 免責条項が広すぎて、ベンダーの明白な過失まで免責していないか
- SLA違反・セキュリティ事故時の解除権があるか。解除後のデータ返却・消去義務と期限が明確か
- 準拠法・裁判管轄が日本になっているか。国際仲裁の場合はコスト・時間・執行を評価したか
- Back-to-Back条項の射程を確認し、上位起因・独自実装起因・RAG起因・運用起因を切り分けたか
- ベンダーの監督責任(再委託先・外部API提供元)の範囲が定義されているか
- AIエージェント構成の場合、権限境界・停止権限・承認工程・ログの分担が合意されているか
- 自社がBtoCサービスでAIを組み込む場合、エンドユーザ向け利用規約と消費者契約法8条(1項・3項)の整合が取れているか
- EU域内のユーザにAIが直接応対する、または合成コンテンツを公開する構成の場合、AI Act第50条の適用有無を役割ベースで確認したか
事業部へ確認すべき事故想定質問リスト
- AIの出力をそのまま外部に出すのか、社内で加工・確認してから使うのか
- 人のレビューを外す予定はあるか。ある場合、どの業務で、どの根拠で外すのか
- 顧客対応・契約交渉・与信判断・人事評価など、重要な業務判断に使う予定があるか
- 個人情報・機密情報・営業秘密を入力する想定があるか。入力データの提供先はどこまで及ぶか
- 競合他社や関連会社が同じベンダーを使っていないか
- 誤答・バイアスのある出力が出たときに誰がレビューするのか、レビュー担当者は指定済みか
- 事故発生時に即時にサービスを止めて業務を切り替える手段はあるか。誰が停止権限を持つか
- AI利用が年間でいくら規模になり、どの業務にクリティカルに入るのか
- 既存の業務委託契約・個人情報の取扱いに関する契約との整合性は取れているか
- 海外拠点・グループ会社の従業員も使うか(越境データ移転の論点発生)
- EU域内の顧客・ユーザが直接AIとやり取りする構成になるか。生成物を対外的に公開するか
- 利用開始後、想定外の用途に拡張する可能性があるか
- AIエージェント型で自律的に外部システムへアクションする構成か。実行できるアクションを列挙できるか
- ログはどこに、どの粒度で、どれだけの期間保存されるか(自社側・ベンダー側の双方)
事業部へのヒアリングの目的
上記の質問は、単に情報を集めるためではなく、事業部と法務の間で「どこまで踏み込んで使うつもりか」の認識を揃えるためのものです。事業部が「試験利用だけのつもり」と答えた案件が、数か月後に本格運用になっているケースは珍しくありません。とくに、当初は人のレビューを前提にしていた業務が、いつの間にか自動化されているケースは、責任分界の前提そのものを崩します。導入時点で運用範囲を確認し、拡張時の再レビューを条件にしておいてください。
15. まとめ
AI導入時の責任分界は、通常のSaaS契約以上に「契約だけでは吸収しきれない」構造を持ちます。重要なのは、次の3つのレイヤーを区別して考えることです。
- 契約で取りにいく部分:賠償上限とcarve-outの設計、知財補償、通知義務、ログ提供、解除権、準拠法、Back-to-Back条項の射程整理
- 社内運用で吸収する部分:人のレビュー、入力データの制限、エージェントの権限設計、用途拡張時の再レビュー、AIガバナンス体制の文書化
- 法令上避けられない部分:個人情報保護法上の安全管理措置・委託先監督・漏えい時の報告と本人通知、著作権法その他各業法上の責任、EU向けサービスにおけるAI Actの該当義務
「AIだから全部ベンダー責任」でも「使った側が全部悪い」でもありません。第三者との関係では、各主体について不法行為の要件を個別に判断する必要があり、当事者間では契約条項が優先します。経済産業省の民事責任手引きが示した「補助/支援型」と「依拠/代替型」の切り分けは、この個別判断を進めるうえでの共通言語になります。
AI推進法の全面施行(2025年9月1日)、AI事業者ガイドライン第1.2版の公表(2026年3月31日)、民事責任手引きの公表(2026年4月9日)、そしてEUにおける第50条透明性義務の適用開始(2026年8月2日)と、企業側には説明責任と統制設計の水準を高めることが求められています。契約審査の段階で「なぜこの条項をこう設計したか」を記録として残しておくことが、今後の紛争対応・行政対応の両面で効いてきます。
参照した主な一次資料・公的資料
- 民法(e-Gov法令検索)(709条、719条ほか)
- 製造物責任法(e-Gov法令検索)
- 個人情報の保護に関する法律(e-Gov法令検索)(23条、25条、26条、27条、28条ほか)
- 消費者契約法(e-Gov法令検索)(8条)
- 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン(通則編)」
- 個人情報保護委員会「同ガイドライン(外国にある第三者への提供編)」
- 個人情報保護委員会「生成AIサービスの利用に関する注意喚起等」(2023年6月2日・PDF)
- 経済産業省「『AI利活用における民事責任の解釈適用に関する手引き』を公表しました」(2026年4月9日公表/同年6月9日更新)/手引き〔第1.0版〕本文(PDF)
- 経済産業省「AIの利用・開発に関する契約チェックリスト」(2025年2月18日公表、同月20日差替え)
- 総務省・経済産業省「AI事業者ガイドライン(第1.2版)」(2026年3月31日)/本編(PDF)
- 内閣府「人工知能関連技術の研究開発及び活用の推進に関する法律(AI法)」/条文(e-Gov法令検索)
- Regulation (EU) 2024/1689(EU AI Act)
- Regulation (EU) 2026/1744(Digital Omnibus on AI、2026年7月24日官報掲載・同月27日発効)
- European Commission「Guidelines on transparency obligations for providers and deployers of certain AI systems」(Article 50ガイドライン)
- European Commission「Transparency obligations under Article 50 of the AI Act(FAQ)」
※本記事は一般的な情報提供を目的としたものであり、個別案件についての法的助言ではありません。実際の判断にあたっては、最新の条文・ガイドラインを確認のうえ、必要に応じて専門家にご相談ください。
契約書AIレビュー プロンプト
AI契約における責任分界や免責・補償の危険箇所を、実務目線で素早く洗い出したい方向け。
ベンダー契約の落とし穴を10ステップで点検できるプロンプト集です。
🔍 関連ガイドへ進む
この記事と関連度の高い実務ガイドをまとめています。次に読むならこちら。
