AI開発の契約 注意点｜発注側が揉める3点と危ない兆候

AI開発を外部に発注する直前で「この契約書、何を見ればいいのか」と手が止まる担当者は多いはずです。従来のシステム開発と同じ感覚で読むと、いちばん危ない条項を素通りしてしまいます。

結論：AI開発の契約で揉めるのは金額ではなく3点

AI開発の契約でいちばん揉めるのは、金額ではありません。成果物の定義（精度は保証されるのか）、提供データと学習済みモデルの権利、追加学習・再学習の扱い——この3点です。見積もりの総額は交渉のテーブルに載りやすい一方、この3点は契約書の中で静かに決まり、揉めたときには手遅れになりやすいからです。

この3点が揉めどころになる理由は、AIソフトウェアが従来型のソフトウェアと技術的性質から違うためです。経済産業省の「AI・データの利用に関する契約ガイドライン」は、両者の違いを整理したうえで、AIソフトウェアは「未知の入力データに対する性能保証が技術的に困難」であり、「内容・性能等は学習用データセットに左右される」と説明しています（同ガイドラインの概要資料・2021年1月／経済産業省 情報経済課）。つまり「発注時点では完成物を確定できない」ことが前提の取引なのです。

したがって発注側がやるべきことは、ベンダーに精度を約束させることではなく、「どこまでできたら次に進むのか」「そこで生まれたものを誰がどう使えるのか」を段階ごとに書き分けることです。以下、生成AI開発委託契約の注意点として、発注側が契約書のどこを見るのかを条項ごとに整理し、そのまま使える契約チェックリストと、一括で発注するか段階に分けるかの判断線までつなげます。なお本記事は一般的な情報の整理であり、個別案件の法的判断については必ず弁護士にご確認ください。

生成AI開発委託契約の注意点──発注側が条項ごとに見る7点

生成AIを組み込んだ開発を外部に委託するとき、発注側が契約書で見る箇所は7つに整理できます。経済産業省が2025年2月18日に公表した「AIの利用・開発に関する契約チェックリスト」は、AI関連サービスの契約を利用型契約（汎用的なAIサービスをそのまま使う契約）と開発型契約（カスタマイズ・新規開発を伴う契約）に分け、ユーザ（＝発注側）が条項ごとに確認すべき点を列挙しています（経済産業省「AIの利用・開発に関する契約チェックリスト」を取りまとめました／2025年2月18日）。生成AI開発委託契約は、この利用型と開発型の性質が重なるのが特徴で、従来のシステム開発の契約書だけを見ていると論点が落ちます。

以下は同チェックリストと経済産業省「AI・データの利用に関する契約ガイドライン」に書かれていることを土台に、発注側の順番で並べ直したものです。一般的な整理であり、個別の契約の評価は文言と事実関係で変わります。最終的な判断は弁護士にご確認ください。

① 成果物の権利──モデル・コード・プロンプト・データを分けて書く

最初の注意点は、「成果物」をひとかたまりの言葉で扱わないことです。生成AI開発では、学習済みモデル／ソースコード／プロンプト（指示文・システムプロンプト）／学習用データセット／生成物（アウトプット）の5つが別々に存在し、それぞれ帰属と利用条件を決める必要があります。

チェックリストは、アウトプットの権利帰属と利用条件を「ユーザとベンダの利害が先鋭的に対立しやすい事項」と位置づけ、開発型契約では開発により創出された成果をフォアグラウンドIP、開発と関係なく各当事者が有する知的財産をバックグラウンドIPと位置づけたうえで、前者の権利帰属や利用条件が議論されることが少なくないと整理しています。発注側としては、「どこからがこの案件で生まれたものか」の線を契約書上で引けているかを確認します。

プロンプトも忘れないでください。チェックリストは、ユーザからベンダに提供する情報が「秘密情報」「インプット」「技術情報」「ノウハウ」「フィードバック」「プロンプト」等と呼ばれることがあると注記しています。自社の業務知識を凝縮したシステムプロンプトは資産ですから、インプットの定義に含まれるか、含まれた場合に誰が使えるのかを見ます。

② 学習データ・入力データの利用範囲と二次利用の可否

チェックリストは、入力データ（インプット）の扱いを3つの場合に分けて留意点を整理しています。（1）不特定多数のユーザのために汎用的なAI学習目的で利用される場合、（2）そのユーザへのサービス提供に必要な範囲でのみAI学習目的に利用される場合、（3）AI学習目的には利用されない場合です。発注側がまずやるのは、自分の案件がどれに当たるかを契約書の文言で特定することです。

チェック項目としては、インプットの利用目的が定められているか、ベンダによるサービス提供目的以外の利用が認められているか、認められる場合に自社技術開発や学習目的といったサービス提供目的以外の目的での利用が許容されているか、が挙げられています。「その他乙の業務のために利用できる」のような広い書き方は、ここで引っかけます。

見落としやすいのは定義のほうです。チェックリストは、インプットの定義に合致しない情報は、適用法令による制限がない限りベンダが自由に利用できる可能性があると指摘し、提供情報が定義に合致するかを情報提供の前に確認する、定義に該当しない不必要な情報は提供しない、という対応を挙げています。条項を直せないときでも「渡す情報を絞る」という手は残っているわけです。

なお同チェックリストは、ベンダが自社技術の開発目的でデータを使うこと自体を不適切と評価するものではない、と明記しています。重要なのは、適用法令を守ったうえで、発注側が条件とリスクを認識し、得られるベネフィットとデータ提供のデメリットを比べて受け入れるかを決めることだ、という立て方です。禁止するか否かではなく、比べて決めた記録が社内に残っているかが実務上の分かれ目になります。

③ 精度・性能の保証──保証させる代わりに受入基準で縛る

経済産業省の契約ガイドラインAI編は、AIモデルが学習用データセットに基づく帰納的な手法で開発されるという技術的背景を踏まえ、AIモデルに関する完成義務の設定や性能保証が必ずしも容易でない点を指摘しています。生成AIを使う場合はこの不確実性がさらに大きくなります。

したがって発注側の打ち手は、保証の文言を強くさせることではありません。保証できないものを無理に保証させると、達成できなければ紛争、達成できても測り方で揉めます。代わりに受入基準（合格ライン）で縛るのが実務上の安全側です。具体的には、評価に使うデータ（本番データからどう切り出すか）、指標（正答率・再現率・人による5段階評価など何で測るか）、測定の実施者、合格ラインの4点を契約書か別紙に書きます。

チェックリストも、ベンダがアウトプットを完成する義務を負うか、負う場合にどのような完成条件が課せられるのか（完成時期、検収条件等）を確認項目に挙げています。あわせて、完成義務を負わない場合でもベンダは善管注意義務を負い、一定の水準に達しない開発が行われる場合には債務不履行責任を問われ得る点に変わりはない、とも整理しています。「準委任だから何も言えない」わけではありません。

④ 検収の基準と検収期間

受入基準を決めたら、次はいつ・誰が判定するかです。生成AIの検収は、合否が一発で出るものではなく、評価用データを用意して測り、外れた出力を見て、指示や後処理を直して再提出する、という往復が入ります。この往復を見込まない期間設定にすると、期間切れで自動合格になるか、逆に延々と終わらないかのどちらかに振れます。

契約書で埋めるのは、検収の開始条件（何が納品されたら検収を始めるのか）、判定する人、判定に使うデータと指標、不合格だった場合の再提出の回数と期限、そして検収期間が過ぎたときの扱い（みなし合格とするかどうか）です。チェックリストも、利用を希望する時期までに十分なアウトプットが提供されない場合の対応は、事前に検討することが望ましいとしています。

正直に書いておくと、検収期間を「何日が妥当」と示した公的資料は、今回の調査では見つけられませんでした。日数そのものは案件ごとに決めるしかないので、ここでは「再提出の1往復が物理的に入る長さにする」という考え方だけをお伝えします。

⑤ ハルシネーション・誤出力が起きたときの責任分界

生成AI特有の注意点がここです。チェックリストは、アウトプットについてベンダによる保証がない場合のみならず、保証がある場合であっても、機械学習の特性上、アウトプットには不正確な情報や虚偽の情報、あるいは他者の著作権等の権利利益を侵害する情報が含まれる可能性があるとし、したがって利用目的に応じてアウトプットの正確性や適法性を適切に評価し、人による確認を行うことが必要であると述べています。

つまり「誤出力をゼロにする」という前提の条項は、技術的に成り立ちません。契約で書けるのは、誤出力が起きることを前提にした分界です。

• 出力をそのまま外部（顧客・取引先）に出す経路があるのか、人の確認を必ず挟むのか。挟む場合、誰のどの工程に入れるのか。
• 誤出力が原因で損害が出たときの責任の上限と、上限が外れる場合（故意・重過失、秘密保持義務違反、第三者の知的財産権侵害など）。
• 出力の正確性チェックが発注側の役割になるなら、そのための時間と人をどちらの費用で見るのか。

「人による確認が必要」と公的資料が言っている以上、確認を入れない運用設計のまま契約を結ぶのは、条項の問題ではなく業務設計の問題として残ります。

⑥ 再委託と、裏で使う外部AIサービスの利用規約との整合

生成AI開発の多くは、ベンダが自前でモデルを作るのではなく、他社の汎用的なAIサービス（基盤モデルのAPI等）を組み込んで作ります。チェックリストはこの構造を【類型2：カスタマイズ型】として整理し、カスタマイズサービスを提供する事業者は、発注側との関係ではサービスの提供者（ベンダ）だが、汎用的AIサービスの提供者との関係ではその利用者（ユーザ）になる——立場が入れ替わる、と説明しています。

ここから出てくる注意点は2つです。1つは、発注側が結ぶ契約の裏側に、ベンダ自身が縛られている外部サービスの利用規約があること。ベンダが約束できる範囲は、その規約より広くはなりません。もう1つは、その規約が動くことです。チェックリストは、ベンダが利用規約に基づいてサービスを提供しているケースでは利用規約が定期的に変更され得るため、変更状況を随時確認すべきとし、利用規約が民法上の定型約款（民法548条の2）に該当する場合には、変更する旨・変更後の内容・効力発生時期を効力発生時期の到来前に周知すれば、その変更が合理的なものである限り個別の同意なく契約内容を変更できる（民法548条の4）と整理しています。さらに、カスタマイズサービスの利用規約は、基となる汎用的AIサービスの利用規約の変更に連動して変わる、とも述べています。

したがって契約書に入れておきたいのは、再委託の可否と事前承諾の要否に加えて、使用する外部AIサービスの名称・リージョン（データの保存先）の開示と、それらの規約や仕様が変わったときに発注側へ通知する義務です。再委託先にも同じ秘密保持・データ利用制限が課される建付けかも、あわせて確認します。

⑦ 秘密保持と、生成AIサービス側の「学習に使わない」設定

最後は秘密保持です。チェックリストは、AI関連サービスに用いられる技術次第では第三者からのアクセスやプロンプト等を通じてインプットの内容が漏洩する可能性があるとし、特に不正競争防止法上の営業秘密に該当する情報は、公知となる場合に以後の要保護性が失われる可能性があると注意しています。また、第三者との契約で秘密保持義務等を負う情報をインプットとして提供する場合、契約内容次第ではその行為自体が契約違反となるおそれがあるとも指摘しています。社内の情報だから自由に渡せる、とは限らないわけです。

「学習に使わない設定にしてあります」という説明を受けることも多いと思います。これについてチェックリストは、インプットがAIサービスの改良のために使用されず、第三者に漏えい・提供されることがない環境が確保されているかはベンダ側の運用やセキュリティ水準に依拠するため、特に自社の機微情報をインプットに含める場合には、システムの構造やセキュリティ水準等に関して慎重な検討が必要だとしています。設定の有無だけで安心せず、運用まで見るという立て方です。

その検討手段としてチェックリストが挙げているのが、セキュリティ水準の明示、監査条項、ログ保存義務です。監査については、第三者である委託事業者の内部監査部門による監査等の条項や、ISO/IEC 27001等の国際的なセキュリティの第三者認証を用いる形が示されています。

なお、個々の生成AIサービスにおける「学習に利用しない」設定の名称や初期値はサービスごとに異なり、規約改定で変わり得ます。確認できなかったので本記事ではサービス名を挙げた断定はしません。契約書に設定画面の名前を書き込むのではなく、「インプットをAIの学習に利用しないこと」を義務として書き、仕様や規約が変わった場合の通知を求めるほうが、長く効きます。

私たちMihataも独自AI開発のお手伝いをしております。契約の話の途中で恐縮ですが、受入基準の置き方や外部AIサービスの選び方は、実際に作っている側に聞いたほうが早い部分だと思っています。よろしければ合わせてご覧いただけたら嬉しいです。

契約チェックリスト──発注前にこのまま確認に使う

上の7点を、契約書を開いたまま上から潰せる形にしたものです。印刷するか社内の確認表に写して使ってください。「書いていない」ことが分かった時点で成功です（書いていない項目は、交渉するか、渡す情報を絞るかの判断に回します）。

• ☐ 納品物が列挙されている（学習済みモデル／ソースコード／プロンプト／学習用データセット／生成物を別々に書いている）
• ☐ この案件で生まれたもの（フォアグラウンドIP）と、もともと各社が持っていたもの（バックグラウンドIP）の線が引けている
• ☐ 生成物について、権利の帰属だけでなく利用条件（誰が・どの範囲で使えるか／第三者に使わせないか）が書いてある
• ☐ 自社が渡したシステムプロンプトを、ベンダが他案件で使えないことが書いてある
• ☐ インプット（提供データ）の定義があり、自社が渡す予定の情報がその定義に入る
• ☐ 入力データが「汎用的なAI学習に使われる／自社向けサービス提供の範囲でのみ使われる／学習には使われない」のどれなのか特定できる
• ☐ ベンダの目的外利用（自社技術開発・学習目的・横展開）が禁止されている、または許容範囲が限定されている
• ☐ 精度・品質の数値が「保証」か「目標値」か明示されている
• ☐ 受入基準が、評価データ・指標・測定の実施者・合格ラインの4点セットで書いてある
• ☐ 検収の開始条件・判定者・再提出の回数と期限・期間満了時の扱い（みなし合格の有無）が書いてある
• ☐ 誤出力・ハルシネーションを前提に、人による確認をどの工程で誰が行うかが決まっている
• ☐ 損害賠償の上限と、上限が外れる場合（故意・重過失／秘密保持違反／知的財産権侵害）が書いてある
• ☐ 再委託の可否と事前承諾の要否、再委託先にも同じ義務が及ぶ建付けになっている
• ☐ 使用する外部AIサービスとデータの保存先（リージョン）が開示されている
• ☐ 外部サービスの利用規約・仕様が変更された場合に通知される
• ☐ 秘密情報の定義に、口頭共有やシステム連携で渡したデータも入る（「書面で秘密と明示したもの」に限定されていない）
• ☐ 契約終了後のデータの返還・消去義務と、モデルに取り込まれた分の扱いが書いてある
• ☐ セキュリティ水準・ログ保存・監査（内部監査条項やISO/IEC 27001等の第三者認証）のいずれかで、運用を確認する手段がある
• ☐ 第三者に対して秘密保持義務を負っている情報を、インプットに混ぜていない

この19項目のうち、どれが埋まっていないかを数えると、次の判断（一括で発注するか、段階に分けるか）がそのまま決まります。

請負と準委任の違い──AI開発が準委任になりやすい理由

まず契約類型です。日本の民法では、開発の委託は大きく請負と準委任に分かれます。両者の違いは「完成」を約束するかどうかにあります。

• 請負：仕事の完成を目的とする契約。受注者は完成義務を負い、成果物が契約の内容に適合しない場合には契約不適合責任を負う。
• 準委任：事務の処理を委託する契約。受注者は善管注意義務（善良な管理者の注意をもって事務を処理する義務）を負うが、完成そのものは約束しない。

なぜAI開発は準委任が採られやすいのか

前述のとおり、AIソフトウェアは「契約初期は開発対象の確定が困難」「未知の入力データに対する性能保証が技術的に困難」という性質を持つと整理されています。完成物の水準を契約時に確定できない以上、完成義務を負う請負を初期段階から結ぶと、ベンダー側は達成できないかもしれない約束を背負うことになります。そのためAI開発では、探索的な段階を準委任で進め、見通しが立った段階で改めて開発契約を結ぶ進め方が実務上とられています。

ただし「準委任なら安心」ではありません。経済産業省が2025年2月に公表した「AIの利用・開発に関する契約チェックリスト」をめぐる解説では、重要なのは請負か準委任かを抽象的に議論することではなく、成果の内容や水準をどの程度求めるのかを明確にすることだと指摘されています。類型のラベルより、「何ができたら合格なのか」を検収基準として書けているかのほうが実質的に効きます。

危ない書き方の対照表──条項ごとの「よくある一文」

チェックリストで「書いてある／書いていない」を確認したら、次は書いてある中身を見ます。以下は条項ごとに、発注側が見るポイントと、実際に契約書で見かける危ない一文を並べた対照表です。「危ない書き方の例」は法的に無効という意味ではなく、発注側の想定と食い違いやすく、後から揉めやすい書き方という意味です。

この表のうち発注側が最も見落とすのは、2行目と3行目のセットです。データの利用範囲を絞っていても、そのデータで学習した派生モデルの権利がベンダー単独帰属になっていれば、自社の資産が形を変えて外へ出ます。逆にモデルの権利を取っても、動かすための環境やノウハウが手元になければ使えません。この2つは必ず並べて読んでください。

金額の妥当性を同時に確認したい場合は、AI開発の見積もりの内訳をどう読むかもあわせてご覧ください。契約条項と見積書は、実は同じ「どこまでやるか」を別の言葉で書いたものです。

一括請負か段階型か──段階型に切る判断線

発注側のいちばん大きな分岐は、一括で請負契約を1本結ぶか、段階に分けるかです。公的な基準があるわけではないので、以下はMihataが実務で使っている目安です（公的資料に書かれたしきい値ではありません）。次の5つのうち1つでも当てはまったら、一括の請負ではなく段階型（アセスメント／PoC → 本開発）に分けるほうが安全側だと考えています。

• 決まっていない要件が3つ以上ある：やりたいことを文章で書き出したとき、「ここは走りながら決める」となる項目が3つ以上。
• 合格ラインを数値と測定方法のセットで書けない：「業務で使えるレベル」しか書けない状態。③で述べた4点セット（評価データ・指標・実施者・合格ライン）のどれかが埋まらない。
• データが揃っていない：学習・評価に使うデータの件数・形式・保管場所・社外への持ち出し可否のどれかが未確定。
• 人の確認を挟まずに出力を外部へ出す想定がある：顧客や取引先に直接届く経路があるのに、確認工程の担当が決まっていない。
• 投資回収の試算を作っていない：何時間・何人分の手間が減るのかを自社で試算していない（＝PoCの合格ラインも置けない）。

逆に、どれにも当たらない——要件が文章で確定でき、合格ラインが数値で置け、データが手元にあり、出力は社内でしか使わない——のであれば、最初から開発契約1本で進めても事故は起きにくいと考えています。段階に分けること自体にも、契約を2回結ぶ手間と期間の分だけコストがかかるためです。

この考え方は公的資料の整理とも噛み合います。チェックリストは、開発型契約が締結される時点において、AIシステムに生じ得るリスク分析が技術その他の制約により十分に実施できない場合には、開発型契約単体でリスク調整を行うのではなく、その後当事者間で締結される契約で段階的に調整をすることで、より実態に即したリスク分配が可能となる場合も想定されると述べています。「分からないことが多いなら、契約を分ける」という発想です。

しきい値の数字は会社ごとに変えて構いません。大事なのは、決まっていないことの数を実際に数えて、数が多ければ契約を分けるという形にしておくことです。感覚ではなく個数で判断できるようにしておくと、社内の説明も通りやすくなります。この進め方を上に通す段階であれば、AI導入の稟議書に書くべき6項目が、そのまま「やめる条件」「損失の上限」の書き方の参考になります。

段階契約の進め方──アセスメント／PoC／開発／追加学習

経済産業省のガイドラインは、従来のウォーターフォール型ではなく、「探索的段階型」の開発方式を提唱しています。試行錯誤を繰り返しながら納得できるモデルを生成するアプローチで、4つの段階に分けて契約を結び直していきます。

各段階で決めておくこと

段階を分ける意味は、「まだ分からないこと」を契約書に書かずに済ませる点にあります。逆にいえば、各段階で次に進む条件だけは必ず決めておく必要があります。

• ①アセスメント：渡すデータの範囲と、秘密保持の範囲。ここで渡したデータをベンダーが他案件に使えないことを先に固める。判定結果がネガティブだった場合に打ち切れることも明記する。
• ②PoC：「何をもって次の開発に進むか」の合格条件。評価に使うデータ、指標、測定の実施者を決める。PoCで作ったパイロット版モデルの権利と、PoC不成立で終わったときの費用精算も先に決める。
• ③開発：成果物の一覧、検収基準、権利帰属と利用条件、責任の上限。ここで初めて完成物に近い言葉が使えるようになる。
• ④追加学習：運用開始後に自社データで育てたモデル（派生モデル）の権利と、ベンダー側が他社へ横展開できるかどうか。ここを空白のまま運用に入る例が非常に多い。

実務では、①と②をまとめて短期の準委任で走らせ、③から本格的な開発契約に切り替える形がよく見られます。AI開発会社の選び方を検討している段階なら、この段階分けを提案してくるかどうかがそのまま見極めの材料になります。いきなり一括の請負を提示してくる相手は、AIの不確実性を織り込んでいないか、リスクを発注側に寄せているかのどちらかです。

危ない兆候──この書き方が出てきたら立ち止まる

契約書を細かく読み込む時間がないときでも、次の4つだけは探してください。いずれも「その場では通るが、後で必ず効いてくる」タイプの兆候です。

1. 精度を数値で言い切っている

「正答率95%を保証します」と提案書や契約書に書かれている場合、まず測定条件を確認してください。未知の入力データに対する性能保証は技術的に困難とされる領域です。条件のない数値保証は、達成できなければ紛争、達成できても検収でもめる火種になります。逆に、評価用データと指標を特定したうえで「この条件下でこの数値を目標とする」と書いてある提案は信頼できます。

2. 学習済みモデルの権利がベンダー単独帰属で、交渉に応じない

ベンダー側にも「自社の研究・開発に関する事業自由度を確保したい」「横展開したい」という正当な事情があり、単独帰属の主張自体が不当なわけではありません。問題は交渉のテーブルにすら載せない場合です。ガイドラインは権利帰属だけでなく利用条件（利用目的・期間・態様・第三者への提供の可否・利益配分）をきめ細かく設定する枠組みを提案しています。帰属で折り合わないなら、利用条件で調整できるはずです。それも拒むなら、自社データが自社の手を離れる契約だと理解して判断してください。

3. PoCを挟まず、いきなり一括請負を提示してくる

「まとめて発注いただいたほうが安く済みます」という提案は、発注側から見ると総額が読めて安心に見えます。しかし成果が不明瞭な段階で完成義務を負わせると、ベンダーはリスク分を見積もりに載せるか、検収を曖昧にして逃げ道を作るかのどちらかになりがちです。結果として、高いのに何が納品されるか分からない契約になります。社内AIツールがうまくいかない典型パターンの多くは、この入口の設計に原因があります。

4. 提供データの利用範囲が無制限になっている

「乙は本件データを本件業務その他乙が必要と認める目的で利用できる」といった書き方は、目的外利用を実質的に許すものです。データは知的財産権の対象とならず法律上のデフォルトルールがない場合が多いため、契約で書いていないことは守られないと考えるのが安全です。利用目的・期間・第三者提供・契約終了後の消去まで、一つずつ書き切ってください。

なお、そもそも外注すべきか自社で作るべきかを迷っている段階であれば、社内でAIを内製するか外注するかの判断軸を先に整理しておくと、契約交渉の力点も定まります。予算感の目安は中小企業の独自AI開発にかかる費用にまとめています。

生成AIを使う場合に増える論点

ChatGPTのような生成AIやその基盤モデルを組み込む開発では、上記に加えて入力データの取り扱いと生成物の著作権という2つの論点が乗ってきます。ここは特に解釈が固まりきっていない領域なので、一次資料に書いてあることと、そこから先の判断を分けて扱ってください。

入力データの取り扱い

経済産業省のガイドラインは、AI技術の利用契約においてユーザが入力したデータの扱いを契約で定めるべきとし、とくに営業秘密やノウハウが含まれる場合、ベンダが入力データをユーザへのサービス提供以外の目的で利用することを望む場合を挙げています。また入力データを用いて追加学習を行う場合には、再利用モデルの権利帰属や利用条件についても契約で定めるべきとされています。

著作権の面では、文化庁の文化審議会著作権分科会法制度小委員会「AIと著作権に関する考え方について」（令和6年3月15日）が、生成AIへのプロンプト入力に伴う著作物の複製等について、情報解析にあたるものとして著作権法第30条の4の適用が考えられるとしています。ただし、入力に用いた既存の著作物と類似する生成物を生成させる目的で当該著作物を入力する行為には、享受目的が併存すると考えられるため同条は適用されないと整理されています。

生成物の著作権

生成物に著作権が発生するかは、一律には決まりません。同文書は、生成AIに対する指示が表現に至らないアイデアにとどまるような場合には、当該AI生成物に著作物性は認められないと考えられるとしたうえで、著作物性は個別具体的な事例に応じて判断されるとし、判断要素として次の3つを挙げています。

• 指示・入力（プロンプト等）の分量・内容：創作的表現といえるものを具体的に示す詳細な指示は、創作的寄与があると評価される可能性を高める。一方、長大な指示であっても、創作的表現に至らないアイデアを示すにとどまる指示は判断に影響しない
• 生成の試行回数：試行回数が多いこと自体は判断に影響しない。ただし生成物を確認し指示・入力を修正しつつ試行を繰り返す場合には、著作物性が認められることも考えられる
• 複数の生成物からの選択：単なる選択行為自体は判断に影響しない

実務上の含意はシンプルです。生成AIの出力そのものに著作権があることを前提にした契約条項は、前提から崩れる可能性があるということです。「生成物の著作権は甲に帰属する」と書いても、そもそも著作物性がなければ帰属させる権利が存在しません。したがって、生成物については著作権の帰属だけでなく利用条件（誰がどの範囲で使えるか、第三者に使わせないか）を契約で定めておくほうが実効性があります。

なお、この文書自体が「公表時点における小委員会としての一定の考え方を示すもの」であり、それ自体が法的な拘束力を有するものではない、と冒頭で明示しています。本記事の記述も同様に一般的な整理にすぎません。実際の契約書のレビューや個別の法的判断は、必ず弁護士にご確認ください。

まとめ──契約書で見るのは「金額」より「境界」

AI開発の契約で発注側がやることは、突き詰めると境界を引くことです。どこまでできたら次の段階に進むのか（成果物と検収基準）、生まれたものは誰がどこまで使えるのか（権利帰属と利用条件）、渡したデータはどこで止まるのか（利用範囲と再委託）。この3つの境界が書けていれば、多少の想定外は運用で吸収できます。

逆に境界が曖昧なまま総額だけ合意した契約は、うまくいっているうちは問題になりませんが、精度が伸びなかったとき・担当者が変わったとき・別のベンダーに移りたくなったときに、必ず表面化します。契約書を読む時間は、そのときのための保険だと考えてください。

Mihataでは中小企業向けにAI導入のご相談を承っております。契約書そのもののレビューは弁護士の領分ですが、「この見積もりと条項の組み合わせで何が起きるか」「PoCの合格条件をどう置くか」といった技術寄りの部分であれば、お手伝いできることがあるかもしれません。判断に迷っている段階でも、よろしければお声がけください。