AI導入の契約では、料金や機能だけを確認しても十分ではありません。

入力した社内データがAIの学習に利用されるのか、生成された文章や画像を商用利用できるのか、利用ログや設定情報を自社で取得できるのかなど、運用開始後に関係する条件も確認する必要があります。

さらに重要なのが、契約終了時の取扱いです。

現在のベンダーとの契約を終了した場合、入力データ、プロンプト、システム設定、ログ、運用マニュアルなどは自社に残るのでしょうか。別のベンダーへ変更するとき、業務を止めずに引き継げる状態になっているでしょうか。

これらを契約前に確認していないと、特定のベンダーから切り替えたくても切り替えられない「ベンダーロックイン」が発生する可能性があります。

経済産業省は、AIサービスの利用・開発における契約実務を支援するため、「AIの利用・開発に関する契約チェックリスト」を公表しています。同チェックリストでは、入力情報の利用範囲、第三者提供、生成物の利用条件、セキュリティ、ログ保存など、AI契約で確認すべき項目が整理されています。

ただし、実際の導入現場では、契約条項を読むだけでは判断できません。

「自社としてどのデータを入力してよいのか」「生成物をどの業務に使うのか」「契約終了後も継続すべき業務は何か」といった業務上の方針を先に決め、その方針を契約条件へ反映する必要があります。

本記事では、AI導入契約の確認項目を、事業責任者が判断できる実務的な形に置き換えて解説します。

※本記事は一般的な情報提供を目的としています。個別契約の法的判断については、弁護士などの専門家へご相談ください。

AI導入契約では何を確認すべきか

AI導入契約で確認すべき内容は、契約の種類によって異なります。

まず、自社が導入しようとしているものが、既製のAIサービスなのか、自社向けにカスタマイズされたシステムなのか、新規開発を伴うものなのかを整理しましょう。

経済産業省の契約チェックリストでは、主なAIサービスの利用形態を、次の3類型に整理しています。

汎用的なAIサービスでは、ベンダーが定めた利用規約を受け入れて利用するケースが中心です。そのため、利用企業側が個別に条件を変更できない場合があります。

一方、カスタマイズや新規開発を伴う場合は、成果物、データ、ソースコード、仕様書、保守、引き継ぎなどについて、個別に契約条件を決められる可能性があります。

AI契約は契約書だけを確認しても足りない

AI導入では、契約書以外にも複数の文書が関係します。最低限、次の資料を集めて確認しましょう。

• 契約書
• 利用規約
• プライバシーポリシー
• データ処理に関する条件
• サービス仕様書
• SLA
• セキュリティ資料
• 見積書
• 提案書
• 運用マニュアル
• 外部サービスや基盤モデルの利用条件

特に注意したいのが、ベンダーが別会社の生成AIやクラウドサービスを組み込んでいるケースです。

自社が直接契約するベンダーの条件だけでなく、その先にある基盤モデル提供者やクラウド事業者の条件にも影響を受けることがあります。

例えば、自社向けAIチャットボットを提供するベンダーが、外部の大規模言語モデルを利用している場合、入力データがどこまで送信されるかは、ベンダーだけでなく基盤モデル側の仕様にも左右されます。

契約確認の前に自社で決めるべき5つの方針

1. AIをどの業務に使うのか
2. どのようなデータを入力するのか
3. 生成物を何に利用するのか
4. どこまでベンダーへ任せるのか
5. 契約終了後も継続すべき業務は何か

例えば、「社内文書を検索するAIを導入したい」という要望だけでは、契約条件を判断できません。

対象文書に顧客情報や従業員情報が含まれるのか、生成された回答を顧客へそのまま提示するのか、回答履歴を何年間保存するのかによって、必要な条件は変わります。

契約条件を先に見るのではなく、自社の業務要件を先に明確にすることが重要です。

AI契約チェックリストを業務上の判断に置き換える

経済産業省の「AIの利用・開発に関する契約チェックリスト」では、ユーザーが提供するプロンプトや学習用データなどを「インプット」、AIから提供される生成結果などを「アウトプット」として整理しています。

しかし、事業責任者が契約を確認する際は、法律用語だけでなく、具体的な業務判断へ置き換える必要があります。ここでは、主要な確認項目を実務上の質問に変換して解説します。

入力情報の範囲｜何をAIへ入力してよいか

最初に決めるべきことは、AIへ入力する情報の範囲です。

AIサービスの契約条件が整っていたとしても、自社が入力してよい情報と、入力してはいけない情報を決めていなければ、安全な運用はできません。

事業部だけで判断せず、情報の種類に応じて法務や情シスと相談しましょう。自社で決めるべきなのは、次のような事項です。

• AIを利用する対象業務
• 入力する情報の種類
• 入力禁止情報
• 匿名化やマスキングの方法
• 例外利用の承認手順
• 違反があった場合の報告先

契約書に「安全に管理する」と書かれていても、従業員が自由に機密情報を入力してよいわけではありません。

入力情報の利用範囲｜AIの学習に使われるのか

AI導入の相談で特に多いのが、「入力したデータをベンダーがAIの学習に使うのか」という質問です。

この質問は、単純に「学習するか、しないか」だけでは判断できません。少なくとも、次の利用目的を分けて確認する必要があります。

• 契約したサービスを提供するための処理
• 入力履歴を保存するための利用
• 不正利用やセキュリティ監視
• 障害調査
• 人による品質確認
• サービス改善
• AIモデルの学習
• 匿名化・統計化した情報の利用

「学習には使わない」と説明されていても、障害調査や品質評価のために一定期間保存される場合があります。反対に、サービス改善への利用が認められていても、自社が個別設定で拒否できる場合があります。

ベンダーへは、次のように具体的に質問しましょう。

• 入力情報はAIモデルの追加学習に使われますか
• サービス改善や品質評価に使われますか
• 人が入力内容を確認する可能性はありますか
• 学習や改善への利用を拒否できますか
• 入力情報はどのくらいの期間保存されますか
• 契約終了後も利用されますか
• 匿名化後のデータは継続利用されますか

自社で判断するのは、どの種類のデータまで学習・改善利用を許容するかです。法務や情シス、ベンダーと相談すべきなのは、「学習しない」という説明の対象範囲や、保存期間、匿名化の方法、再委託先での取扱いです。

第三者提供｜誰までデータへアクセスするのか

AIサービスでは、自社と契約先ベンダーだけで処理が完結しないケースがあります。次のような第三者が関係している可能性があります。

• 基盤モデルの提供者
• クラウド事業者
• データセンター事業者
• システムの再委託先
• 保守事業者
• 人手による評価担当者
• 海外拠点

そのため、「当社は第三者提供しません」という説明だけでなく、業務委託や再委託として誰がデータを扱うかも確認する必要があります。

• 再委託先は存在するか
• 再委託先を事前に確認できるか
• 再委託先が変更された場合に通知されるか
• データはどの国や地域で処理されるか
• 海外の担当者がアクセスする可能性はあるか
• 基盤モデル提供者へ送信される情報は何か
• 人による内容確認が行われるか

個人情報を含む場合は、個人情報保護法や自社のプライバシーポリシーとの整合性も確認してください。

生成物の利用｜商用利用できるのか

AIが生成した文章、画像、プログラム、分析結果などを、業務でどこまで利用できるかも重要な確認事項です。

• Webサイトや広告への掲載
• 商品パッケージへの利用
• 顧客への提案書
• 納品物
• 有料コンテンツ
• ソフトウェアへの組み込み
• 社内意思決定の資料
• 顧客向けチャットボットの回答

確認すべきなのは、単に「商用利用可能か」だけではありません。

• 顧客へ納品できるか
• 再販売できるか
• 加工して利用できるか
• ベンダー側も同じ生成物を利用できるか
• 第三者の権利を侵害した場合の責任はどうなるか
• 生成物の正確性について保証があるか
• 人による確認が求められているか

サービス規約上、生成物の利用が認められていても、第三者の著作権、商標権、肖像権などを侵害しないことまで保証されているとは限りません。

そのため、自社で次の運用方針を決めましょう。

• 生成物を利用してよい業務
• 人による確認が必要な業務
• そのまま公開してはいけない用途
• 法務確認が必要な用途
• 出典確認が必要な用途

特に、広告、商品、顧客への納品物など、社外へ公開する用途では慎重な確認が必要です。

セキュリティ｜自社の機密水準に合っているか

AIサービスのセキュリティは、「安全です」という説明だけでは判断できません。自社が入力する情報の機密度に対して、必要な水準を満たしているかを確認します。

• 通信時・保存時の暗号化
• データの保存場所
• 管理者権限
• ユーザーごとのアクセス制御
• 多要素認証
• シングルサインオン
• 退職者アカウントの停止
• 脆弱性対応
• バックアップ
• インシデント発生時の通知
• 再委託先の管理
• 第三者認証の取得状況

また、カスタマイズ型のAIシステムでは、アプリケーション部分だけでなく、基盤モデル、クラウド、データベース、外部APIなど、システム全体の構成を確認することが重要です。

一部のサービスだけが高いセキュリティ水準を満たしていても、別の連携先から情報が漏れる可能性があります。

監査と情報提供｜問題発生時に確認できるか

事故やトラブルが発生したとき、ベンダーからどのような情報を受け取れるかも確認します。

• インシデントの発生日時
• 影響を受けたデータ
• 影響を受けた利用者
• 原因
• 応急対応
• 再発防止策
• 再委託先での発生有無
• ログの提供可否
• 第三者調査への協力

必ずしも利用企業がベンダーの環境を直接監査できるとは限りません。その場合は、第三者認証、監査報告書、セキュリティチェックシート、事故報告義務など、代替手段を確認します。

ログ保存｜何をどの期間残すか

AIの利用ログは、事故調査だけでなく、業務改善、利用状況の把握、不正利用の確認にも使われます。一方で、ログそのものに機密情報や個人情報が含まれる可能性もあります。

• ユーザーの利用履歴
• 入力内容
• 出力内容
• 管理者の操作ログ
• 認証ログ
• アクセスログ
• 設定変更履歴
• プロンプトの変更履歴
• モデルの変更履歴
• エラー履歴
• インシデント記録

経済産業省の契約チェックリストでも、利用者のログだけでなく、管理者や開発者権限に関する認証ログ、アクセスログ、操作ログなどの保存が検討対象とされています。

自社では、次の点を決めます。

• 何のためにログを保存するのか
• どのログが必要か
• どのくらいの期間保存するか
• 誰が閲覧できるか
• 契約終了時に受け取る必要があるか
• 保存期間終了後にどう削除するか

ログを保存しすぎると情報管理リスクが高まります。反対に、保存期間が短すぎると、問題が発覚したときに原因を確認できません。

規約変更｜誰が確認し、何を再判断するか

クラウド型AIサービスの利用規約や仕様は、契約期間中に変更される可能性があります。

• 入力データの利用条件
• AI学習への利用
• 保存期間
• 料金
• 利用上限
• 利用可能なモデル
• 生成物の利用条件
• セキュリティ機能
• サービス終了条件
• 責任制限

問題は、規約が変更されること自体ではありません。変更通知を受け取る担当者が決まっておらず、誰も確認しない状態になることです。

• 規約変更通知の受信先
• 確認担当部署
• 確認頻度
• 重大変更の判断基準
• 事業責任者への報告方法
• 利用継続の承認者
• 社内ルールの更新担当者

規約変更によって、自社が入力してよい情報や、生成物の利用方法が変わる可能性があります。「契約時に確認したから終わり」ではなく、運用中も定期的に確認する体制が必要です。

AI導入契約の確認項目を誰が判断するか

AI契約は、法務部門だけで完結するものではありません。法務は契約上の権利義務を確認できますが、どのデータを入力するか、何日分のログが必要か、契約終了後にどの業務を継続するかは、事業部や情シスが判断する事項です。

事業部・事業責任者が決めること

事業部は、AIを利用する目的と業務要件を決めます。

• AIを使う業務
• AIを使わない業務
• 入力するデータ
• 生成物の利用先
• 人による確認工程
• 求める精度
• 必要な稼働時間
• 業務停止が許容される時間
• 契約終了後も続ける業務
• 引き継ぎに必要な情報

特に重要なのが、「AIが停止した場合に業務がどうなるか」です。代替手段がなく、AIサービスの停止によって顧客対応や受発注が止まる場合は、より厳しいサービス水準や引き継ぎ条件が必要です。

法務と確認すること

• 入力情報の利用許諾
• 秘密保持
• 個人情報
• 第三者提供
• 再委託
• 生成物の利用条件
• 知的財産権
• 保証
• 補償
• 損害賠償
• 責任制限
• 契約解除
• 規約変更
• 準拠法・裁判管轄

ただし、法務へ契約書だけを渡すのではなく、自社の利用目的やデータの種類も伝える必要があります。利用実態が分からなければ、契約条件が業務に適しているかを判断できません。

情シス・セキュリティ担当と確認すること

• システム構成
• データの流れ
• 保存場所
• 認証方式
• アクセス権限
• ログ
• API連携
• バックアップ
• 障害対応
• アカウント管理
• データのエクスポート
• 他システムへの移行可能性

情シスがいない中小企業では、外部のIT専門家やセキュリティ事業者へ相談する方法もあります。

ベンダーへ確認・交渉すること

• 入力情報はどこへ送信されるか
• AIの学習に使われるか
• 再委託先はどこか
• データはいつ削除されるか
• どのログを取得できるか
• 設定情報を引き渡せるか
• 契約終了時に何を返却するか
• 返却形式は何か
• 移行支援の費用はいくらか
• 引き継ぎ期間はどの程度か
• 担当者変更時にどう対応するか

役割分担の目安は次のとおりです。

ベンダーロックインとは

ベンダーロックインとは、特定のベンダー、製品、サービスへの依存度が高まり、他社への切り替えが困難になる状態です。

単に同じベンダーを長期間利用しているだけでは、ベンダーロックインとは限りません。問題になるのは、切り替えたい事情が発生しても、技術的・契約的・費用的な理由によって切り替えられない状態です。

AI導入でベンダーロックインが起きる理由

• データが独自形式で保存されている
• データを一括出力できない
• プロンプトや設定をベンダーしか管理していない
• RAGの構成が公開されていない
• API連携が独自仕様である
• ソースコードを受け取っていない
• 設計書が更新されていない
• ベンダー担当者しか運用方法を知らない
• クラウド環境がベンダー名義になっている
• 契約終了時の移行支援が定められていない

例えば、AIチャットボットの回答精度を高めるため、数年間にわたってプロンプトや参照データを調整したとします。その設定がベンダー側にしかなく、自社が取得できない場合、別ベンダーへ変更すると、これまでの調整を最初からやり直さなければなりません。

ベンダーロックイン自体が必ず悪いわけではない

ベンダーへの依存をすべてなくす必要はありません。専門性の高いベンダーへ任せることで、次のメリットがあります。

• 導入期間を短縮できる
• 自社で専門人材を採用せずに済む
• 障害対応を一元化できる
• 継続的な改善を任せられる
• 最新技術を取り入れやすい

問題は、依存していることを把握していない状態です。依存度、切り替え費用、移行期間、業務停止リスクを把握したうえで利用するのであれば、合理的な経営判断になる場合があります。

ロックインの危険度を判断する5つの質問

1. データを標準的な形式で一括出力できますか
2. プロンプトや設定を自社で確認できますか
3. 別のベンダーが理解できる設計書がありますか
4. 自社に運用方法を理解している担当者がいますか
5. 契約終了時の移行支援条件が決まっていますか

「いいえ」が多い場合、ベンダーロックインのリスクが高いと考えられます。

ベンダーロックインを防ぐ契約上の確認ポイント

ベンダーロックイン対策は、ベンダー変更を決めてから始めるものではありません。契約締結前、遅くとも本番運用へ移行する前に、終了・移行条件を確認する必要があります。

データの返却形式を決める

「契約終了時にデータを返却する」という条件だけでは不十分です。返却されたデータを、別システムで利用できるかを確認します。

• CSV
• JSON
• XML
• PDF
• Excel
• データベースダンプ
• API経由
• 添付ファイル一式

例えば、顧客情報をPDFで返却してもらっても、次のシステムへ一括登録できない可能性があります。そのため、次の事項まで決めておくことが重要です。

• ファイル形式
• 項目名
• データ型
• 文字コード
• 添付ファイルとの関連
• 履歴情報の有無
• 出力回数
• 出力費用
• 契約終了後の出力期限

設定情報とプロンプトを成果物に含める

AIシステムの価値は、元データやプログラムだけではありません。運用を通じて調整した次の情報も重要な資産です。

• システムプロンプト
• プロンプトテンプレート
• ワークフロー
• AIエージェントの設定
• RAGの設定
• 検索条件
• データ分割方法
• 評価基準
• テストデータ
• モデルの選択条件
• 外部APIの連携設定
• 権限設定

これらが契約上の成果物に含まれるかを確認します。ただし、ベンダーが以前から保有している汎用的なノウハウや共通テンプレートまで、すべて自社へ移転されるとは限りません。自社専用に作成・調整した部分と、ベンダーの既存資産を切り分けることが必要です。

設計書と運用マニュアルを更新対象にする

契約時に設計書を受け取っても、その後の変更が反映されなければ、引き継ぎには利用できません。次の資料を定期的に更新する条件を入れましょう。

• システム構成図
• データフロー図
• API仕様書
• データ項目定義
• アカウント一覧
• 権限一覧
• 障害対応手順
• バックアップ手順
• 復旧手順
• 運用マニュアル
• プロンプト一覧
• モデル変更履歴
• 設定変更履歴

「納品時に一度作成する」ではなく、運用中の変更を誰が、いつ反映するかまで決めます。

自社名義のアカウントと環境を増やす

事業継続に不可欠なアカウントがベンダー名義になっていると、契約終了時に利用できなくなる可能性があります。特に次の環境は、名義と管理権限を確認しましょう。

• クラウドアカウント
• AIサービスの法人契約
• ドメイン
• サーバー
• データベース
• ソースコードリポジトリ
• APIアカウント
• 監視サービス
• ドキュメント管理ツール
• バックアップ環境

すべてを自社名義にすると管理負担が増えるため、事業継続上重要なものから優先します。少なくとも、自社が管理者権限を持っているか、契約終了時に権限移管できる状態にしておきましょう。

移行支援の範囲と費用を決める

「必要に応じて引き継ぎに協力する」という表現では、対応範囲が曖昧です。次の内容を具体化します。

• 引き継ぎ先への説明会
• データ出力
• データ項目の説明
• 新環境への移行作業
• 移行テスト
• 並行稼働
• 問い合わせ対応
• 障害対応
• 引き継ぎ期間
• 作業費用
• 契約終了後の対応期限

特に確認したいのが、移行支援が月額費用に含まれるのか、別料金なのかです。契約終了後に高額な移行費用が発生すると、実質的にベンダーを変更しにくくなります。

基盤AIの変更・終了時の対応を決める

• 利用モデルの提供終了
• APIの廃止
• 料金の大幅な改定
• 利用上限の変更
• モデル更新による精度低下
• 規約変更
• データ保存条件の変更
• セキュリティ機能の変更

代替モデルへ切り替える場合、追加費用が発生するのか、再検証を誰が担当するのかも決めておきましょう。

契約終了時に何を残すべきか

契約終了時に残すべきものは、元データだけではありません。次のベンダーや自社担当者が運用を継続できる状態を作る必要があります。

契約終了時に受け取るべきもの

データ

• 入力した元データ
• 加工後のデータ
• 顧客・ユーザーデータ
• 入出力履歴
• 評価データ
• 学習・検証用データ
• 添付ファイル
• データ項目定義

設定

• プロンプト
• ワークフロー
• AIエージェント設定
• RAG設定
• 検索条件
• 権限設定
• API設定
• モデル設定
• パラメーター

ログ

• 利用ログ
• 管理者ログ
• 認証ログ
• アクセスログ
• 変更履歴
• エラー履歴
• 障害記録

技術資料

• ソースコード
• システム構成図
• データフロー図
• API仕様書
• データベース設計書
• 環境構築手順
• テスト仕様書

運用資料

• 運用マニュアル
• 障害対応手順
• バックアップ・復旧手順
• 問い合わせ履歴
• 課題管理表
• 変更管理表
• ライセンス一覧

返却後にベンダー側のデータをどう扱うか

• いつ削除されるか
• バックアップからも削除されるか
• 再委託先からも削除されるか
• 削除完了の報告を受けられるか
• 法令上保存が必要な情報は何か
• 匿名化データは残るか
• サービス改善に利用し続けるか

「契約終了時に削除する」という条件でも、バックアップ内のデータは一定期間残る場合があります。削除時期と削除範囲を確認しましょう。

契約終了後も自社に残らない可能性があるもの

• ベンダーが以前から保有しているプログラム
• 他社にも利用している共通部品
• 汎用プロンプト
• ベンダー独自の開発手法
• 基盤モデル
• 第三者の有料ライブラリ
• 外部API
• 再販売が認められていないライセンス

自社に必要なものをすべて取得できるとは限らないため、契約前に「終了後も自社で必要になるもの」を特定することが重要です。

契約終了チェックリスト

• データを受領した
• データの件数と内容を確認した
• 別環境でデータを読み込めた
• プロンプトと設定を受領した
• 設計書とマニュアルを受領した
• 管理者権限を移管した
• 自社名義のアカウントへ変更した
• APIキーを変更・無効化した
• ベンダー側のデータ削除を確認した
• 再委託先の削除状況を確認した
• ライセンスを解約した
• 並行稼働を終了した
• 問い合わせ窓口の終了日を確認した

AIシステムを円滑に引き継ぐ方法

AIシステムの引き継ぎは、契約終了が決まってから準備するのでは遅い場合があります。運用中から、第三者が理解できる状態を作りましょう。

運用中から引き継ぎ資料を更新する

• モデルを変更したとき
• プロンプトを変更したとき
• 連携システムを追加したとき
• 権限を変更したとき
• 重大な障害が発生したとき
• 業務フローを変更したとき

更新頻度を月次または四半期と決める方法もあります。資料が更新されているかを定例会議で確認すると、ベンダーだけが知っている情報を減らせます。

自社側にシステムオーナーを置く

• 利用目的を管理する
• 対象業務を決める
• 契約更新を判断する
• 規約変更を確認する
• ベンダーとの窓口になる
• 成果物を保管する
• 引き継ぎ計画を管理する
• 社内ルールを更新する
• 利用部門へ周知する

ベンダーとの連絡担当者ではなく、事業継続と投資判断に責任を持つ担当者を置くことが重要です。

担当者の退職にも耐えられる状態を作る

• 個人メールアドレスで契約しない
• 共有メールアドレスを利用する
• 管理者を複数名設定する
• パスワード管理ツールを利用する
• APIキーの保管場所を決める
• 月次の運用内容を記録する
• 定期的に引き継ぎ訓練を行う

新しいベンダーが再現できる資料を残す

• 何の業務に使っているか
• どのシステムと連携しているか
• どのデータを利用しているか
• どのような設定になっているか
• 何を変更してはいけないか
• 障害時に何を確認するか
• どのアカウントが必要か
• 現在の課題は何か

AI導入契約を確認するタイミング

AI導入契約は、締結時だけでなく、プロジェクトの節目ごとに確認する必要があります。

契約締結直前

• 入力データの範囲
• AI学習への利用
• 第三者提供
• 生成物の利用条件
• セキュリティ
• ログ
• 成果物
• 費用
• 契約期間
• 解約条件
• データ返却
• 移行支援

この段階で終了・移行条件を確認しておくことが、ロックイン対策になります。

PoC終了時

• 本番データを安全に扱えるか
• ログを取得できるか
• 障害対応が可能か
• 継続的な費用を負担できるか
• 運用担当者を確保できるか
• 設定やプロンプトを引き継げるか
• 別のモデルへ変更できるか
• 契約終了時にデータを取得できるか

PoC環境がベンダーの検証用アカウントで作られている場合、そのまま本番利用できないこともあります。本番移行前に、環境の名義、データ移行、成果物の帰属を確認しましょう。

本番運用移行時

• システムオーナー
• 管理者
• 利用者
• 障害時の連絡先
• 規約変更の確認担当
• ログの確認担当
• セキュリティ事故の報告先
• ベンダーとの定例会議
• マニュアルの更新担当
• バックアップ担当

PoCで動作したことと、継続的に運用できることは別です。本番移行の承認条件に、体制と引き継ぎの整備を含めましょう。

契約更新時

• 利用部門が増えていないか
• 入力データが増えていないか
• 個人情報を扱うようになっていないか
• 規約が変更されていないか
• 料金が変わっていないか
• 利用モデルが変更されていないか
• ベンダーへの依存度が高まっていないか
• 資料が更新されているか
• データを出力できるか

毎年一度、実際にデータを出力して確認する方法も有効です。「契約上は出力できるが、実際には時間がかかる」という問題を早期に発見できます。

ベンダー変更を検討するとき

• 現行契約の解約期限
• 自動更新の有無
• データ返却条件
• 返却形式
• 設計書の不足
• アカウント名義
• 新旧ベンダーの役割
• 並行稼働期間
• 移行テスト
• 業務停止リスク
• 追加費用
• ベンダー側のデータ削除

新しいベンダーの選定だけでなく、現在のベンダーから何を受け取れるかを先に確認しましょう。

ベンダーへ確認する質問リスト

以下は、ベンダーとの商談や契約確認で利用できる質問例です。

入力データについて

• 入力データをAIモデルの学習に使用しますか
• サービス改善や品質評価に使用しますか
• 人が入力内容を確認する可能性はありますか
• 学習や改善への利用を拒否できますか
• 入力データはどの国・地域に保存されますか
• データの保存期間はどの程度ですか
• 基盤モデル提供者へ何の情報が送信されますか
• 再委託先はありますか
• 契約終了後もデータを保持しますか

生成物について

• 生成物を商用利用できますか
• 顧客への納品物に利用できますか
• 生成物を再販売できますか
• 生成物の権利は誰に帰属しますか
• 類似する生成物が他社へ提供される可能性はありますか
• 第三者の権利を侵害した場合、どのような支援がありますか
• 人による確認が必要な用途はありますか

ログとセキュリティについて

• どのようなログを保存していますか
• ログの保存期間はどの程度ですか
• 自社でログを取得できますか
• 管理者や開発者の操作ログは残りますか
• インシデント発生時は何時間以内に通知されますか
• 再委託先で事故が発生した場合も通知されますか
• 第三者認証や監査報告書を確認できますか
• データは通信時・保存時に暗号化されていますか

終了・移行について

• 契約終了時に返却されるデータを教えてください
• データの返却形式を教えてください
• プロンプトや設定情報は引き渡されますか
• ソースコードや設計書は受領できますか
• アカウントの管理権限を移管できますか
• 新しいベンダーへの説明に協力してもらえますか
• 移行支援は月額費用に含まれますか
• 別料金の場合、料金体系を教えてください
• 契約終了後、データはいつ削除されますか
• 削除完了の報告を受けられますか

AI導入契約でよくある失敗

PoCの成果物を本番環境へ移せなかった

PoC環境がベンダーの検証アカウントで構築され、本番環境への移行費用が別途必要になるケースです。PoC開始前に、本番化した場合の環境、名義、移行費用を確認しましょう。

データは返却されたが再利用できなかった

PDFや画面印刷の形式でしかデータを受け取れず、新しいシステムへ移行できないケースです。返却の有無だけでなく、形式と項目定義を確認する必要があります。

プロンプトや設定が担当者の個人管理だった

ベンダー担当者や自社担当者の個人端末にしか設定が残っておらず、退職後に内容が分からなくなるケースです。共有管理と変更履歴の保存を徹底しましょう。

基盤AIの規約変更を誰も確認していなかった

直接契約しているベンダーの規約だけを確認し、組み込まれている基盤モデルの変更を把握していないケースです。ベンダーに、上位サービスの変更をどのように把握し、利用企業へ通知するかを確認しましょう。

引き継ぎ作業が高額な別料金だった

契約終了時に初めて、データ出力、資料作成、説明会などが別料金だと分かるケースです。契約前に移行支援の範囲と料金体系を確認します。

ソースコードだけ受領し、再構築できなかった

ソースコードはあるものの、環境構築手順、ライブラリ情報、API設定、認証情報がなく、動作させられないケースです。「何を受け取るか」ではなく、「第三者が再構築できるか」で判断しましょう。

AI導入契約を確認する7つの手順

手順1．利用する業務とデータを整理する

AIの利用目的、入力情報、生成物の利用先を明確にします。

手順2．関係する契約書と規約を集める

契約書だけでなく、利用規約、仕様書、セキュリティ資料、外部サービスの条件も集めます。

手順3．自社判断と専門判断を分ける

事業部が決める項目、法務へ相談する項目、情シスが確認する項目を整理します。

手順4．ベンダーへ質問する

不明点を質問票にまとめ、口頭回答だけでなく文書で残します。

手順5．終了・移行条件を確認する

データ、設定、ログ、資料、アカウントの返却条件を確認します。

手順6．社内の責任者を決める

システムオーナー、規約確認担当、ログ管理担当、インシデント対応責任者を決めます。

手順7．契約後も定期的に再確認する

規約、利用範囲、データ、料金、依存度を定期的に見直します。

よくある質問

AIへ入力したデータは必ず学習に使われますか

必ず学習に使われるとは限りません。AIサービス、料金プラン、契約条件、管理設定によって異なります。ただし、「学習に使わない」とされていても、サービス提供、障害調査、不正利用監視、品質確認などの目的で一定期間保存・処理される場合があります。学習利用だけでなく、保存、閲覧、サービス改善、第三者への送信を分けて確認しましょう。

AIが生成した文章や画像は商用利用できますか

サービスの利用規約によって異なります。商用利用が認められていても、第三者の著作権、商標権、肖像権などを侵害しないことまで保証されるとは限りません。広告、商品、顧客への納品物などに利用する場合は、人による確認工程を設け、必要に応じて法務へ相談してください。

ベンダーロックインは完全に避けるべきですか

完全に避ける必要はありません。専門性の高いベンダーへ任せることで、導入期間の短縮や運用負担の軽減につながるためです。重要なのは、依存度、移行費用、移行期間、データ返却条件を把握したうえで判断することです。

契約終了時にデータは必ず返してもらえますか

契約書や利用規約に定めがなければ、希望する範囲・形式で返却されない可能性があります。元データだけでなく、加工データ、ログ、プロンプト、設定、設計書、マニュアルまで、何を受け取れるかを契約前に確認しましょう。

AI契約は法務だけに確認してもらえば十分ですか

法務だけでは十分でない場合があります。法務は権利義務や法的リスクを確認できますが、どのデータを入力するか、どのログを保存するか、契約終了後に何を引き継ぐかは、事業部や情シスが決める内容です。事業部、法務、情シス、ベンダーで役割を分担して確認しましょう。

まとめ｜AI導入契約は終了後の状態から逆算する

AI導入契約では、利用中の料金や機能だけでなく、入力データ、生成物、セキュリティ、ログ、規約変更、契約終了時の取扱いまで確認する必要があります。

特に重要なのは、契約終了後も業務を継続できる状態を作ることです。

確認すべきポイントを整理すると、次のとおりです。

• 入力データの利用範囲を確認する
• AI学習やサービス改善への利用を分けて確認する
• 第三者・再委託先へのデータ提供を確認する
• 生成物の商用利用条件を確認する
• セキュリティとログの要件を決める
• 規約変更の確認担当者を決める
• データ、設定、プロンプト、資料の返却条件を決める
• 移行支援の範囲と費用を確認する
• 自社名義のアカウントと管理権限を確保する
• 運用中から引き継ぎ資料を更新する

ベンダーロックインは、契約終了時に突然発生するものではありません。データや設定がベンダー側に蓄積され、自社に資料や知識が残らない状態が続くことで、少しずつ切り替えが難しくなります。

契約前、PoC終了時、本番移行時、契約更新時に、現在のベンダーが優れているかだけでなく、「将来、必要になったときに変更できるか」も確認しましょう。

AI導入契約とベンダーロックイン対策のご相談

AI導入契約は、契約書だけを確認しても十分とは限りません。 入力するデータ、生成物の利用方法、ログの保存、社内の責任者、契約終了時の引き継ぎまで、実際の業務に合わせて整理する必要があります。 自社の契約内容で何を確認すべきか、現在のベンダー依存度に問題がないか、PoCから本番運用へ進んでよいか迷っている場合は、契約書、提案書、システム構成、運用体制を整理したうえで専門家へ相談するとスムーズです。

• AI導入契約について相談する
• ベンダーロックインの状態を確認する
• PoCから本番移行できるか相談する
• AIシステムの引き継ぎ条件を整理する

参考資料

経済産業省「AIの利用・開発に関する契約チェックリスト」：https://www.meti.go.jp/policy/mono_info_service/connected_industries/sharing_and_utilization/20250218003-ar.pdf