はじめに

2025年2月、経済産業省は「AIの利用・開発に関する契約チェックリスト 」（ 以下、「チェックリスト」という）を公表した。近年、ChatGPTなどの生成AIの普及により、AIの利活用に関する契約の重要性が高まっていることを受け、実務で使いやすい形の指針として策定されたものである。

チェックリストは、AI利活用の実務経験は問わず、幅広い読者を念頭に置いており、以下の利用場面を想定している。

・　社内法務部・顧問弁護士等が契約条項を具体的に検討する場面

・　ビジネス部門担当者等が契約についての初期的な検討を行う場面

図表1　チェックリストの主な想定読者と利用場面

出典：チェックリスト3頁。

本稿では、筆者自身が生成AIを用いたツール開発・検証事業に携わった実務経験も踏まえ、近年、急速に普及している大規模言語モデル（LLM）を用いた生成AI（テキスト生成、要約、翻訳、議事録作成、チャットボット等に活用される）も念頭に置きつつ、チェックリストの要点を解説する。
なお、チェックリスト自体は生成AIのみならず、いわゆる識別系AI（与えられた情報から予測・分類を行うAI）も含むAI全般を対象としている。

チェックリストの前提部分（AIのシステム、当事者、ユースケース、契約の類型）

チェックリストでは、契約の具体的な検討の前提として、①対象となるAIシステムの構成や、②関係当事者、③想定されるユースケース・契約類型について整理がなされている。

以下、大規模言語モデル（LLM）を用いた生成AIを念頭に置きつつ、具体例を示す。

AIシステム

チェックリストでは、識別系・生成系を問わず共通するAIシステムの構成として、

①　インプットとアウトプット

②　導入プロセス

③　技術的調整

の三段階からなる全体像が以下のとおり示されている。

図表2　AIシステム概要

出典：チェックリスト4頁（赤字部分は筆者による）。

筆者の経験上、生成AIを用いた開発において重要なのは、このAIシステムの仕組みの理解に加え、どのモデルを使っているか、どのような手法で処理しているか、プロンプト設計はどうなっているかなど、技術的構成に関する一定の理解が発注者側にも求められるということである。こうした理解が欠けていると、ベンダが採用している手法の妥当性や成果物の性質を把握できず、レビューや判断が形骸化してしまうリスクがある。その結果、開発の方向性を誤ったまま検討が進行したり、成果物の評価が困難になったりするなどの問題に発展しかねない。しかし、現実的な問題として、AIの技術的事項は極めて専門性が高いため、たとえば発注者側で、AIの技術面に詳しいアドバイザーを確保しておくといった手法も重要となる。

当事者

チェックリストでは、契約上の立場として、以下のとおり「AI開発者」「AI提供者」「AI利用者」の三つの当事者が登場する。

図表3 　各当事者の定義

出典：チェックリスト5頁。

図表3でそれぞれの定義が示されているが、実務において、具体的にどのような企業が該当するのかはチェックリストに明記されていない。各当事者の具体例を補足すると以下の通りとなる。

AI開発者：大規模言語モデル（LLM）そのものを自ら設計・学習して構築している企業が該当し、GPT-4などの基盤モデルを開発しているOpenAIが典型例。

AI提供者：AIモデル自体を開発していないが、モデルをサービスとして組み込み、企業に実装・運用可能な形で提供する事業者。たとえば、カスタマーサポート業務に生成AIチャットボットを導入できるよう、企業にAPI連携型のサービス^※を提供するAI事業者。

AI利用者：提供された生成AIを業務などに利用する企業や個人。

ユースケースと契約類型

チェックリストでは、AIを活用する契約類型として、以下の三つのパターンが示されている。
それぞれの類型で契約リスクの所在や交渉のポイントが異なるため、自社のケースがどの類型に該当するかを正しく把握することが重要となる。

類型1：汎用的AIサービス利用型

出典：チェックリスト7頁。

OpenAIのChatGPTやGoogleのGeminiなど、既に提供されている生成AIを、そのまま業務で利用するケース。たとえば、小売業の企業が、OpenAIの「ChatGPT」に購買履歴（年齢、購入商品、時期など）をプロンプトとして入力し、消費者の嗜好傾向を分析させるケースが該当する。

ユーザはウェブ画面等を通じてサービスを利用するが、契約は提供事業者が定めた「利用規約（約款）」に同意する形で成立することが想定され、個別に契約交渉を行う余地は少ないと考えられる。

類型2：カスタマイズ型

出典：チェックリスト7頁。

自社の業務に合わせてチャット画面やデータ連携機能を加えたツールを、外部ベンダに構築してもらうケース。この場合、ベンダが外部のLLMを利用しつつ、自社のニーズに応じた機能や画面を追加する。たとえば、小売業の企業が、チャットボットサービスを構築するにあたり、商品説明データや在庫情報、販売実績などと連携させたシステムを開発ベンダに依頼し、当該ベンダがOpenAIのLLMを利用して、チャットボットを開発するケースが該当する。

契約内容の交渉や設計が可能であり、実務で多く見られる類型であると考えられる。

類型3：AI開発委託型

出典：チェックリスト8頁。

企業が外部のAI開発者と提携し、自社専用のAIモデルやアルゴリズムをゼロから設計・開発するケース。たとえば、製造業の企業が、設備の稼働データを基に、異常を早期に検知するAIモデルを開発会社に委託し、異常検知アルゴリズムそのものを一から構築してもらうケースが該当する（生成AIではなく、識別系AI）。

チェックリスト

チェックリストの構成

チェックリストは、具体的な契約条文のひな型を示すものではなく、契約書を確認する際に、現行条項が十分か、また必要な条項が漏れていないかを確認するための整理指針として活用されるものである。

全体構成は以下の図表4のとおり、AIの利用にあたって中心となる「インプット（A）」と「アウトプット（B）」、それぞれに関する論点を軸に設計されている。

図表4　チェックリストの対象となる条項

出典：チェックリスト11頁。

そして、インプットとアウトプットは、以下の六つの観点に分類して整理されている。

①　特定（定義・対象の明確化）

②　ベンダへの提供（提供義務・条件など）

③　使用・利用（誰がどのように使うか）

④　外部提供（第三者への開示・共有）

⑤　権利帰属（知的財産権の所在）

⑥　処理成果（中間・派生成果物の取扱い）

チェックリスト本文

体系的な理解のため、チェックポイントを整理した表は以下の通りである。

図表5　インプット（プロンプト、学習用の生データ等）

※　チェックポイントは多数あるため、筆者において、要点のみを記載している。実際に契約をチェックする際は、チェックリストを直接参照されたい。
※　「対応ポイント」は、チェックリスト上の事実上とりうる対応・備考欄から筆者が要点を追記したものである。

図表6　アウトプット（分析結果・コンテンツ等のAI生成物、AIシステム等の成果物等）

※　チェックポイントは多数あるため、筆者において、要点のみを記載している。実際に契約をチェックする際は、チェックリストを直接参照されたい。
※　「対応ポイント」は、チェックリスト上の事実上とりうる対応・備考欄から筆者が要点を追記したものである。

留意点（実務上のポイント、リスク）

契約上のチェック項目については以上であるが、本チェックリストには、実務上、特に留意すべき点やリスクが解説されている。そのうち、いくつかポイントを絞って以下記載する。

インプットの提供に関する留意点

（1） インプットとアウトプットの取扱い

AIサービスでは、ユーザが提供するインプット（例：社内データや業務情報）に基づいて、アウトプット（例：生成文章や分析結果）が提供されるため、インプットとアウトプットの取扱いは、契約上の核心である。チェックリストでは、以下のようなリスクが指摘されている。

図表7　インプットの提供に関する主なリスク

（2） インプットについてより注意を要する点

さらに注意すべきは、インプットが汎用的なAI学習目的（例：ChatGPT等への入力）に利用される場合である。この場合、以下のリスクが高まる。

図表8　インプットが汎用的AI学習目的に利用される場合の主なリスク

開発型契約の留意点

生成AIを用いたサービスの開発をベンダに委託する場合、その多くは開発型契約に該当し、特にアウトプットの取扱いや成果物の水準に関して注意が必要となる。

（1） 契約の性質決定（準委任か請負かの判断）

開発型の契約に関しては、その契約の性質が、民法上の準委任契約であるか、請負契約であるかが一つの交渉事項とされることがある。

委託者としては、一定のクオリティを求め、当該基準に達しない場合にはベンダに責任を問うべく、一般的には請負契約を希望することが多いと考えられる。他方、受託者としては、AIを用いた開発は、やってみないと結果が分からないことが多いという性質上、準委任契約を希望することが多いと考えられる。しかし、いずれにせよ、契約の性質の区分は、あくまでも当事者間で合意がない場合の補充的なルールを定めるにすぎないため、重要なのは、開発型契約が準委任契約か請負契約のどちらに分類されるかを抽象的に議論することではなく、むしろユーザがベンダに対して、成果の内容や水準をどの程度求めるのかを明確にし、その点を交渉、契約の中で明らかにしておくことである。

（2） 生成AIを用いた成果物等に関する実務上のポイント（筆者の経験に基づく）

筆者の経験上、生成AIを活用した開発は、従来のロジックベースの開発に比べ、「やってみないとどんな出力が得られるかわからない」という不確実性が大きい。このため、成果物のイメージや合意内容をあらかじめすり合わせておくことが重要である。
また、生成AIは、端的にいえば入力に対して「もっともらしい語」を確率的に出力する仕組みであり、質問内容を理解して回答を返すわけではない。そのため、見た目には自然でも誤った内容（いわゆるハルシネーション）が避けられず、100％正しい出力を期待することはできない。このような特性を踏まえ、例えば正解データ100件に対し何件正答できるかを基準とするなど、評価方法を事前に定めておくことがトラブル防止につながる。なお、評価にあたっては単なる正解率だけでなく、誤りの重大性や出力がどこまで網羅できているか（カバレッジ）など、複数の観点から総合的に判断することが望ましい。
また、完全自動での運用を前提とするのではなく、人による確認や補正を前提とする「人間中心の運用設計（Human-in-the-loop）」を採用することが、実務上も安全かつ現実的である。もし人による確認なしで100％の正答率を求めるのであれば、ハルシネーションが不可避である以上、生成AIの導入自体を再検討すべきである。

その他留意点

チェックリストには、その他、知的財産の観点からの権利帰属や、個人データの国内外提供に関する個人情報保護法上の留意点（第三者提供や越境移転規制の観点）、クラウド利用を含むAIサービスの安全確保の観点からのセキュリティ対策（例えばSBOM^注1の取得、監査権限の確保、ログ保存義務など）についても整理されている。必要に応じてチェックリストの該当箇所を参照されたい。

おわりに

AIの契約に限った話ではないが、チェックリストにも記載されている重要な観点として、望ましくない条件であっても、そのリスクの発生可能性や影響度を冷静に見極め、事業上許容できる範囲内にあると判断できる場合には、リスクを受容して契約を進めるという選択も合理的であることは理解しておく必要がある。重要なのは、担当者がAIの仕組みを一定程度理解したうえで、どのようなリスクがあり、それがどの程度の蓋然性で発生しうるか、また発生した場合にどの程度の影響があるかを正しく把握することである。

※　なお、本記事は、筆者個人の見解を記載したものであり、デジタル庁の見解ではない。

→この連載を「まとめて読む」

1. SBOM（Software Bill of Materials）とは、ソフトウェアを構成するすべての部品（ライブラリやモジュールなど）を一覧にしたリストであり、ソフトウェアの安全性や脆弱性の管理を行ううえで重要とされている。[↩]