「契約書のどこを見れば、AIベンダーに患者データを渡しても大丈夫か判断できるのか」——生成AIの導入検討を進めている情報システム部門や事務長から、この半年で急に増えてきた相談です。汎用の利用約款だけを見ても、医療機関側でどこまで責任を負い、どこからがベンダー側の管轄なのか、線引きが明確に読み取れないというのが実際のところだと思います。
経済産業省が2025年2月18日に公表した「AIの利用・開発に関する契約チェックリスト」は、こうした判断の指針として実務担当者が使える形にまとめられた資料です。全66項目でデータ・知財・責任の論点を分解しているため、法務専門家でなくても契約条項を1つずつ確認できます。本記事では、このチェックリストを医療機関の視点でどう読み解き、ベンダー契約に落とすかを、ヘルスインタビューの導入現場で日常的にやり取りしている観点から整理します。
経産省チェックリストが求めているのは何か
公表の背景と法的な位置づけ
経済産業省は2025年2月18日、生成AIの急速な普及で「ユーザ企業が契約条項を十分に理解しないままAIサービスを導入し、データ流出や知財紛争のリスクを抱える」状況が広がっていることを受け、本チェックリストを公表しました（出典：経済産業省プレスリリース 2025年2月18日、取得日: 2026-04-26）。
法的拘束力自体はありません。ただし、医療機関の場合は個人情報保護法や3省2ガイドラインといった強制法規と重なる項目が多く、実質的にチェックリストの主要項目を外すと法令違反のリスクが同時に高くなります。ガイドラインの立て付けとしては任意ですが、医療領域では事実上の遵守事項に近い扱いになる、と受け止めておくのが安全です。
66項目の内訳
チェックリストは、AIサービスに投入するデータ（インプット）と、AIが生成する成果物（アウトプット）の2側面で構成されています。
| 区分 | 項目数 | 主な論点 |
|---|---|---|
| インプット（ユーザがベンダに提供するデータ） | 37項目 | サービス目的外利用の可否、ベンダの管理義務、知財権の帰属、第三者提供の範囲 |
| アウトプット（AIが生成した成果物） | 29項目 | 完成義務の有無、ユーザの第三者提供権、知財権の帰属、品質保証 |
医療機関の場合、インプット側に患者情報が含まれるため、37項目のインプット側検討が実務上の中心になります。アウトプット側は、診療支援AIのように誤生成が診療判断に直結する用途で29項目の重みが増す構造です。
利用型と開発型で論点が変わる
本チェックリストは、AI関連契約を利用型と開発型の2類型に整理しています。医療機関で生成AIを活用する場合、両方が混在するのが実情です。
| 契約類型 | 概要 | 医療機関での該当例 |
|---|---|---|
| 利用型契約（汎用サービス利用型） | ベンダーが提供するAIサービスをユーザがそのまま利用 | ChatGPT API、汎用文書生成AI、汎用画像認識API |
| 開発型契約（カスタマイズ・新規開発型） | ユーザのデータや要件を踏まえてAIモデルを開発・カスタマイズ | 院内マニュアルRAG、独自診療補助AI、専用問診AIの構築 |
たとえば「汎用LLM（利用型）＋院内独自RAG（開発型）」の組み合わせは、契約構造としては別物です。同じテンプレートで両方をカバーしようとすると、リスク移転の設計に穴が空きます。
医療機関で見落とされがちな5つの論点
66項目のうち、医療機関の事情で重点になるのは以下の5点です。汎用のAI契約レビューではあまり議論されない領域ほど、後から問題が浮上しがちです。
学習データへの転用を契約で禁じる
インプットを「サービス提供以外の目的、たとえば自社のAIモデル学習」に使えるかどうかは、汎用AIサービスの契約で最初に確認したい項目です。
医療機関が患者データを生成AIに入力する場合、学習データへの転用は個人情報保護法上の第三者提供に該当する可能性があります。ベンダー側の口頭説明や約款の同意ではなく、契約条項として明文化しておくことが推奨されます。UIで「学習に使わない」を選択するタイプのオプトアウトは、設定が変更されたときの検知が難しいため、書面での合意を残しておくのが安全策です。
ベンダーの管理義務と再委託先の把握
ベンダーがインプットの管理義務（暗号化・アクセス制御・削除義務）を負うかどうかは、3省2ガイドラインの委託先監督義務と直結します。
見落とされやすいのは再委託先（サブプロセッサー）の存在です。生成AI事業者が裏側で別のクラウド事業者やファインチューニング専門会社に処理を委託しているケースは珍しくありません。再委託が発生した場合の通知義務、および再委託先までの監督義務を契約で明示することが求められます。
知的財産権の帰属を最初に整理する
インプットや学習中間生成物の知財権が、ベンダー側に自動的に移らない構造にしておく必要があります。
医療機関固有の臨床知見・院内マニュアル・問診ノウハウは、開発型契約の用語でいえばバックグラウンドIPにあたり、ユーザ側保持を原則とすべき情報です。一方、開発成果物であるフォアグラウンドIPは、用途別に帰属を切り分ける設計が現実的です（例：問診生成モデル本体はベンダー保持、当該医療機関向けチューニング済み派生モデルはユーザ側利用権あり、といった二段構え）。
アウトプットの品質保証と責任分界
医療現場では、最終的な医療判断は医師の責任という原則は動きません。一方で、AIベンダー側の過失に起因する誤生成（ハルシネーション）については損害賠償の対象になり得ます。
免責条項が広すぎるとベンダー側の責任が事実上ゼロになる契約もあるため、免責範囲と責任上限額の設定は論点として外さないでください。「AIの生成物は参考情報であり、いかなる責任も負わない」という文言だけで免責を成立させようとする契約書は、医療用途では実効性を欠きます。
国外サーバ経由と越境移転規制
多くの汎用AIサービスは、米国等のサーバを経由して処理されます。改正個人情報保護法第28条の越境移転規制と、3省2ガイドラインの委託先監督が二重に効いてくる領域です。
データの物理的所在地、およびデータ管理主体の国籍・法人所在地を契約書で確認し、必要に応じて患者同意の取得フローに越境移転同意を組み込むことが推奨されます。「日本語UIで提供されているから国内サービス」と思い込んでいたら、実処理は海外リージョンだった、という運用は珍しくありません。
利用型と開発型で重点が変わる
同じチェックリストを使っても、契約類型によって重点の置き方は変わります。院内RAGや問診AIのカスタマイズは開発型、LLM APIの直接利用は利用型に分類できますが、両者を混同したまま同じ契約テンプレートを流用すると責任分界が不明確になりやすい領域です。
| 論点 | 利用型契約での重点 | 開発型契約での重点 |
|---|---|---|
| インプット目的外利用 | 学習禁止条項が焦点。オプトアウト設定を契約書化 | 開発目的の範囲を明文化。二次利用の可否をプロジェクトごとに判断 |
| 管理義務・SLA | 既製サービスの標準設定を確認し、不足分を追加覚書で補う | 個別SLAを設計。監査ログ・障害対応時間・データ削除フローを個別に定義 |
| 知財権帰属 | 標準約款の確認と、必要に応じて特約による修正 | フォアグラウンド／バックグラウンドの整理を最初に合意 |
| アウトプット品質 | 免責条項の範囲を精査 | 受入検査・瑕疵担保の期間と範囲を設計 |
| 監査・ログ | 既存ログの開示請求権を確認 | 監査条項・第三者検証権を条項として盛り込む |
利用型は既製サービスの範囲内でどこまで追加合意を取り付けられるかが勝負であり、開発型はプロジェクト立ち上げ時点でどれだけ論点を先出しできるかが勝負、という違いです。
契約レビューをどう進めるか
医療機関の実務で本チェックリストを回すには、以下の順序で進めるのが現実的です。
既存契約の棚卸し
まず院内で利用中・PoC中の生成AIツールを一覧化し、契約書を全件再点検します。クラウドサービスの約款は更新されているケースがあるため、最新版を取得し直してください。所要期間の目安は2週間程度です。「無償枠だから」「PoCだから」と対象から外していた分にも患者データが流れていないか、この段階で確認しておくと後戻りが減ります。
チェックリストでの条項レビュー
66項目のうち、医療機関で必ず押さえたい前述の5論点を中心に、既存契約の抜けを洗い出します。法務機能が薄い医療機関は、外部弁護士や医療AI領域のコンサルとの共同レビューを検討する価値があります。単発の契約1本だけを見るのではなく、包括契約・個別発注書・付随SLAをまとめて突き合わせるのが漏れを防ぐコツです。
ベンダー交渉と条項追記
学習禁止・国外移転・監査権・ログ保全等で不足が確認された条項について、覚書または追記契約でベンダーと合意します。ベンダー側が「約款で対応済み」と主張する場合でも、書面での個別合意を残しておくと後日の解釈の揺れを防げます。
院内規程・運用フローへの反映
患者同意取得フロー・委託先管理台帳・インシデント対応手順を、契約改定と並行して更新します。ダイナミックコンセントの導入は、AI利用ごとの都度同意取得を運用可能にする手段として現実的です。
定期監査
AI事業者側の規約やモデルは頻繁に更新されます。年1〜2回の定期点検を運用に組み込むことで、契約条項と実態の乖離を防ぎます。契約締結時に「変更通知はメール1本」で済まされる条項が入っていると、通知の見落としで実質的な同意を後追いで取ってしまうリスクがあります。
ヘルスインタビューでの対応設計
ヘルスインタビューは、本チェックリストの主要観点をプロダクト設計レベルで満たすように作られています。契約レビューの負荷を、プロダクト選定の段階で吸収するアプローチです。
| チェックリスト観点 | ヘルスインタビューの対応 |
|---|---|
| インプット目的外利用の禁止 | 学習データへの転用を技術・契約の両面で遮断 |
| ベンダー管理義務 | 国内データセンター運用、3省2ガイドライン準拠のセキュリティ設計 |
| 知財権の帰属 | 院内ナレッジ（マニュアル・テンプレート等）のユーザ側保持を契約書で明文化 |
| 同意取得 | ダイナミックコンセントによる、AI利用ごとの患者同意取得 |
| 監査ログ・履歴保全 | 独自特許のブロックチェーン技術による改ざん不能な履歴保全 |
| 責任分界 | 医療判断責任は医師、技術起因の不具合はベンダー責任という分界を契約書で定義 |
導入医療機関の契約担当者が66項目を逐一審査するのではなく、標準機能側でクリアできる観点を増やすことで、契約交渉のコストを構造的に下げる設計にしています。より詳細な機能や導入事例は、ヘルスインタビューのサービスページ をご参照ください。
現場で聞かれることの多い質問
Q. 経産省チェックリストには法的拘束力がありますか？
法的拘束力はありません。あくまでベンダ・ユーザ間の契約交渉を支援するガイドラインです。ただし、医療機関の場合は3省2ガイドライン・個人情報保護法等の強制法規と重なる項目が多いため、実質的にはチェックリストの主要項目を満たさないと法令違反のリスクが高まります。
Q. 既存のクラウド利用約款だけで対応できないのですか？
多くの汎用AIサービスの約款はベンダ有利の標準条項であり、医療機関側の責任が過大になっているケースがあります。医療データを扱う場合は、追加覚書・SLA合意・データ処理契約（DPA）を別途締結することを推奨します。
Q. 医療AIの契約レビューで最も見落とされやすい条項は何ですか？
サブプロセッサー（再委託先）の通知義務です。生成AI事業者が裏側で別のクラウド・ファインチューニング会社に委託しているケースは多く、再委託先までの委託先監督義務を契約で明示する必要があります。
Q. 開発型契約での知財権はどう整理すればよいですか？
フォアグラウンドIP（開発で生まれた成果物）とバックグラウンドIP（既存知見）を区別し、前者は用途別の共有・後者は各当事者保持を原則とする設計が一般的です。医療機関側の臨床知見はバックグラウンドIPとして保護してください。
Q. ヘルスインタビュー導入後も契約レビューは必要ですか？
はい。ヘルスインタビュー本体の契約は本チェックリストに準拠していますが、他のAIサービスとの併用がある場合は、それぞれ別途レビューが必要です。AIBTRUSTでは契約レビューの観点出しもご支援しています。
まとめ
経産省のAI契約チェックリストは、生成AI時代のベンダー契約における論点をインプット37・アウトプット29の計66項目で分解した実務指針です。医療機関では、インプット側の学習禁止・国外移転・監査権・再委託先通知の4点が特に重要で、これらを個人情報保護法と3省2ガイドラインの要求と重ねて設計する必要があります。
ベンダー任せにするのではなく、覚書・SLA・DPAで追加合意を残す姿勢と、そもそも契約観点を標準で満たすプロダクトを選ぶ姿勢の両輪で進めるのが、結果的に導入工数を最小化するルートです。自院での契約レビューや観点出しの具体的な相談は、医療機関向けのお問い合わせからご連絡ください。
出典・参考資料
- 経済産業省「『AIの利用・開発に関する契約チェックリスト』を取りまとめました」2025年2月18日（取得日: 2026-04-26）
https://www.meti.go.jp/press/2024/02/20250218003/20250218003.html - 経済産業省「AIの利用・開発に関する契約チェックリスト 令和7年2月」（PDF）
https://www.meti.go.jp/policy/mono_info_service/connected_industries/sharing_and_utilization/20250218003-ar.pdf