AIサービスの契約書を前にして、どこを見ればいいのか分からない——これは法務がいる会社でも起きます。通常のシステム開発契約とは論点が違うからです。
経済産業省が「AIの利用・開発に関する契約チェックリスト」(令和7年2月)を公開しています。あまり知られていませんが、確認すべき条項が体系的に整理された資料です。実際に読んで、実務で効く部分を抜き出しました。
まず、契約の型を2つに分ける
チェックリストは、AI関連の契約を大きく2種類に分けています。
| 型 | 中身 | 交渉の余地 |
|---|---|---|
| 利用型 | 汎用的なAIサービスを利用する契約 | 小さい |
| 開発型 | カスタマイズ型/新規開発型 | 大きい |
この区別が実務では重要です。資料には、利用型の契約は多数のユーザーと画一的に締結されるものであり、そのぶん料金や条件が合理的な範囲に設定されているという趣旨の記述があります。
つまりSaaSの利用規約を相手に条項交渉を挑むのは、多くの場合は筋が悪いということです。法令違反や著しく不利益な例外的な場面を除けば、条件を所与の前提として運用側で対応するほうが合理的、という整理になっています。
ここを理解しておかないと、変えられない契約書を前に時間を溶かします。交渉すべきは開発型のほうです。
インプット(自社が入力するデータ)の確認項目
チェックリストはインプット側の条項に多くの項目を割いています。実務で確認すべきものを整理すると、こうなります。
管理・セキュリティ
- ベンダーが入力データを管理する義務を負うか
- 負う場合、どの水準の管理が求められるか
- その管理体制について、こちらから監査や情報提供を求められるか
3番目が抜けやすい項目です。「適切に管理します」と書いてあっても、それを確認する手段が契約に無ければ、確認できません。資料には、契約で明示されていない管理水準であっても業界標準に照らして体制構築義務が認められる可能性がある、という趣旨の補足もあります。
保存期間と削除
- ベンダーが入力データを保存できる期間はどの程度か
- 保存期間が終わったとき、ベンダーは何をするか
- こちらが求めたとき、また契約終了時に、削除する義務を負うか
- 削除したことを証明する書面の発行義務を負うか
最後の項目は、ほとんどの会社が意識していないはずです。「削除した」と口頭で言われるのと、書面で証明されるのはまったく違います。特に機密情報を扱う場合、監査対応で効いてきます。
返却・提供
- ベンダーが入力データをこちらに提供する義務があるか
資料には、返却されない場合に備えて自社側でバックアップを取ることを検討するという趣旨の記述があります。契約で解決できないなら運用で対応する、という考え方です。
アウトプット(AIの出力)の確認項目
- ベンダーがアウトプットを完成させる義務を負うか(請負契約で特に問題になる)
- 提供する義務の有無と条件(時期・頻度・態様)
- 内容について満たすべき条件(質・量・粒度)があるか
- ベンダーによる保証や情報提供義務があるか
保証があっても、確認は必要
資料の記述で重要なのがここです。ベンダーの保証がある場合でも、学習の性質上、アウトプットには不正確な情報や偽情報、他者の権利利益を侵害する情報が含まれる可能性がある——という趣旨が明記されています。
したがって利用目的に応じて、正確性や適法性を評価し、人による確認を行うことが必要とされています。
「ベンダーが保証しているから大丈夫」は成立しません。人による確認プロセスを社内に持つことが前提になっています。これは契約の話ではなく運用の話ですが、契約チェックリストにわざわざ書かれているのが実態を表しています。
最も実務的なのは、この但し書き
チェックリストは「全部満たすべき条件表」ではない
資料には、使い方について重要な注意が書かれています。指摘されている=契約すべきでない、ではありません。要旨はこうです。
- チェックリストで指摘されているからといって、ただちに条項の是正を求めたり、契約締結を見送ることを推奨するものではない
- 契約の主な機能はリスク分配だが、リスクはAI利活用それ自体に内在するもので、契約文言だけで完全にコントロールできるものではない
- 自社が不利な条項を受け入れる場合でも、リスクが事実上許容できる範囲なら、契約して進めることが合理的な場合もある
これは相当に実務的です。チェックリストを持って「全部クリアしないと契約できない」と言い出すと、どのベンダーとも契約できなくなります。
判断のときに考慮する要素
資料は、判断にあたって総合的に考慮すべき要素を列挙しています。
- 提供されるAI関連サービスの内容
- 契約の形態(利用契約か個別契約か)
- その条項を受け入れることによるリスク
- 契約上の各義務の履行可能性
- 利用目的に照らした代替サービス・代替手段の有無
- 契約交渉に必要な労力
- 契約外(運用等)の方法によるリスク低減の可否
5〜7が現実的です。代替がなく、交渉の労力が大きく、運用で減らせるリスクなら、契約は飲んで運用でカバーする。これが実務での正解であることは多い。
使い方
- まず利用型か開発型かを判別する——利用型なら条項交渉に時間をかけない
- 開発型なら、インプットの管理水準・監査可否・削除証明を確認する
- アウトプットの完成義務と品質条件を確認する
- 飲めない条項があったら、運用で低減できるかを先に検討する
- それでも無理なものだけ、交渉のテーブルに乗せる
1と4を飛ばすと、契約検討が止まる
全項目を潰そうとしないことが、このチェックリストの正しい使い方です。利用型なのに開発型の条項交渉を始めると終わりませんし、運用で低減できるものを全部交渉のテーブルに乗せると相手も引きます。
飲めない条項が出たときの順番
| 判定 | 対処 | 例 |
|---|---|---|
| 1 | 運用で低減できないか考える | 入力してよい情報を規程で絞る |
| 2 | 設定で低減できないか考える | 保持期間を管理者設定で短縮する |
| 3 | 範囲を限定して受け入れる | 対象業務を限る/対象部署を限る |
| 4 | ここではじめて交渉する | 権利帰属・削除証明など譲れないもの |
4から入ると、交渉が長引くわりに得るものが少なくなります。1と2で消せる項目がかなりあります。
この記事について:経済産業省「AIの利用・開発に関する契約チェックリスト」(令和7年2月)のPDFを取得し、自作の抽出ツールで本文を読みました。抽出の過程で一部の文字が欠落したため、原文の逐語引用は避け、内容を確認したうえで平易に言い換えています。正確な条文・記述は原典をご確認ください。本記事は判断の材料であって法的助言ではありません。実際の契約は法務・弁護士にご確認ください。
この記事の確認項目に、実際の答えを入れた表があります
インプット・アウトプットの扱い、保存期間、保存先、人によるレビュー。主要4サービスについて、公式ドキュメントを一次で当たって埋めています。確認すべき項目ではなく、確認した結果です。出典と確認日つき。
利用型か開発型か、迷ったらご相談ください
どこまでを自社で持つかによって、契約の型も確認項目も変わります。かんたんな設問に答えるだけで、自社に合う進め方を診断します。費用はかかりません。