AI開発委託契約書のチェックポイント｜通常のシステム開発委託と何が違うか

AI開発を外部に委託するとき、多くの会社が「いつものシステム開発委託契約書のひな型」に社名と金額を入れ替えて使っています。しかしAI開発は、何が完成すれば契約を果たしたことになるのかを契約時点で書き切れないという性質を構造的に抱えています。従来型のひな型はこの「完成」を書けることを前提に組み立てられているため、前提が崩れたまま使えば肝心なところが空白のまま契約が成立します。

経済産業省は2018年6月に「AI・データの利用に関する契約ガイドライン（AI編）」を公表し、AI開発には従来型のソフトウェア開発と異なる4つの特徴があると整理しました。その後、2025年2月に「AIの利用・開発に関する契約チェックリスト」、2026年4月には「AI利活用における民事責任の解釈適用に関する手引き」（第1.0版）が公表されています。

この記事では、これらの公的資料の原文をもとに、「自社の契約書だとこの論点はどうなっているか」を確認するための視点を整理します。発注する側・受託する側のどちらの立場でも使える構成にしました。

AI開発の委託契約が「いつものひな型」で危ない理由

違いは成果物を事前に確定できるかどうかにあります。従来型の契約は、要件定義を固めれば何が納品されるかが決まるという前提に立っています。AI開発ではこの前提が成立しないことが多く、そこに契約書の穴が生まれます。

経済産業省が整理した4つの特徴

ガイドライン（AI編）は、学習済みモデルの生成について、従来型のソフトウェア開発と比較した特徴を次の4つに整理しています。

1. 学習済みモデルの内容・性能等が契約締結時に不明瞭な場合が多いこと
2. 学習済みモデルの内容・性能等が学習用データセットによって左右されること
3. ノウハウの重要性が特に高いこと
4. 生成物について更なる再利用の需要が存在すること

この4つは、そのまま契約書の4つのチェックポイントに対応します。①は性能保証・検収条項、②はデータの利用範囲、③はノウハウの取扱い、④は成果物の再利用条件です。この4つが手当てされていない契約書は、AI開発の契約書としては未完成だということになります。

「演繹」と「帰納」——作り方そのものが違う

ガイドラインは違いを推論の方向で説明します。従来型は処理手順をルールとして記述しコード化する演繹的な作業で、開発対象物があらかじめ特定されています。学習済みモデルの生成は、限られたデータのみから未知の状況における法則を推測する帰納的な作業です。ここから次の違いが生じます。

ただしこれを「AIだから責任を負わなくていい」と読み替えないことが重要です。ガイドライン自身が、AI技術の特性は契約によるリスク分配を直ちに決するものではなく、あくまでもリスクの評価の一要素にすぎないと述べています。特性は交渉の出発点であって、免責の根拠ではないという整理です。

なお、AIを「作る」のではなく契約書のチェックにAIを「使う」場面の注意点は、AI契約書レビューの落とし穴で別途整理しています。

4段階モデル（アセスメント→PoC→開発→追加学習）を実務に翻訳する

成果物が事前に確定できない開発をどう契約に落とすのか。ガイドラインが提唱したのが「探索的段階型」の開発方式です。開発を次の4段階に分け、段階ごとに目的を実現できるか・次に進むかを検証しながら進めます。

1. アセスメント段階：学習済みモデルの実現可能性を検討する
2. PoC段階：PoC（Proof of Concept＝概念実証）。実現可能性を示すために部分的に実現する（この段階に特有の論点はAIのPoC契約（技術検証）の落とし穴で詳しく扱っています）
3. 開発段階：実際に学習済みモデルを開発する
4. 追加学習段階：運用しながら学習を重ねる

ガイドラインはこれを、最初に要件定義を固めるウォーターフォール形式と異なり、試行錯誤型の開発を許容する開発方式だと説明しています。

本質は「進まない選択」を契約に残すこと

4段階に分ける最大の意味は工程管理ではありません。ガイドラインが明記しているのは、このプロセスでは必要な性能を有する成果物ができないと判明した場合に、次の段階に進まないという選択ができるという点です。これにより、認識の違いから生じるトラブルや開発失敗のリスクを限定できるとされています。

発注側は見込みの薄い開発に全額を投じ切る前に降りられ、受託側は事前に約束できない性能を一括で保証させられる事態を避けられます。全工程を1本の請負契約にまとめた瞬間に、この安全弁を自分で外していることになります。自社の契約書がどちらの形か、まず確認してみてください。

段階ごとに、契約で決めるべきことが変わる

とくに抜けやすいのが追加学習段階です。運用が続くほど成果物の中身は変わるため、ここを空欄にすると数年後に「今動いているモデルは誰のものか」を誰も答えられなくなります。

チェックポイント①成果を保証できない——性能保証と検収条項

契約書の書き方に最も直接響くのが「性能を事前に保証しにくい」という点です。ここで避けて通れないのが契約の性質です。

請負か準委任か——ただし抽象的に争わない

2025年2月の契約チェックリストは、開発型契約の交渉で契約の性質を準委任契約（民法656条・643条）とするか請負契約（民法632条）とするかが重要な交渉事項とされることがある、と整理しています。

• 準委任契約と理解される場合：ベンダは善管注意義務（民法644条）を負うにとどまる
• 請負契約と理解される場合：仕事の完成義務（民法632条）および契約不適合責任（民法559条・562条から564条）を負う

ただしチェックリストは、これらの区分は当事者間で合意がない場合の補充的なルールにすぎず、抽象的にどちらに分類されるかを議論する妥当性は検討が必要だと注意を促します。さらに、準委任契約でもベンダは善管注意義務を負い、一定の水準に達しない開発なら債務不履行責任を問われ得る点は変わらないとも述べています。つまり「準委任だから結果責任はない」という整理は成り立ちません。

重要なのは契約類型のラベルではなく、ユーザがベンダに対して成果の内容や水準をどの程度求めるかが契約書で言語化されているかです。

「精度○%」と書けばよいわけではない

ガイドラインは、未知の入力への性能保証は困難だとしつつ、脚注で重要な補足をしています。既知の入力に対する性能については、評価用データを含む評価条件を適切に設定・限定することにより、契約上、性能保証を行うことに合理性が認められる場合もあるという指摘です。

ここから設計が導けます。数字だけでなく「どの評価用データで、どういう条件で測った数字か」をセットで定めること。評価条件のない「精度○%以上」は、後から双方が別の測り方を主張し合う余地を残します。

またチェックリストは、AIモデルそのものではなくAIモデルを含むAIシステムを開発する場合には、ベンダが一定の担保責任を負うことが合理的な場面も考えられるとしています。「AIだから一律に保証できない」ではなく何を開発対象とするかで結論が変わるという整理です。

自社の契約書で確認してほしいこと

• 検収の合格基準が評価用データと評価条件を伴った基準になっているか
• 基準に達しなかったときに何が起きるか（再実施の回数・期限、費用負担、解除、精算）
• 検収期間の経過で自動的に合格とみなす条項の有無と、その期間の妥当性

実際に検収をめぐって支払いが止まる局面の対応はシステム開発の検収拒否、開発が頓挫した場合の責任の所在はシステム開発の頓挫とPM義務・協力義務、紛争類型の全体像はシステム開発トラブルの全体像で扱っています。

2026年4月の手引きが示した「説明義務」

経済産業省は2026年4月、「AI利活用における民事責任の解釈適用に関する手引き」（第1.0版）を公表しました。契約書の書き方そのものではありませんが、担保させる範囲を考えるうえで直結します。手引きは、最終的に人の判断を介在させる補助／支援型AI（現状では多くのAIがこれに該当すると考えられるとされています）と、人の判断を代替する依拠／代替型AIに分けて整理し、前者では従来の過失の判断枠組みを適用できるとしています。そしてAIの出力を援用したことは、原則として、AI利用者が求められる注意義務の水準を引き上げることも引き下げることもないと述べています。

契約実務への示唆は、開発者・提供者の説明義務です。手引きは、AIの機能や性能の限界、使用方法、重要なリスク等について、当該時点の科学技術の水準に照らし合理的に予見可能な範囲で明確な説明を行うことが重要だとしています。受託側にとっては性能限界・前提条件を文書で明示して引き渡すことが、そのまま自社の防御になるということです。なお2025年5月には人工知能関連技術の研究開発及び活用の推進に関する法律（令和7年法律第53号）が成立しており、長期の契約では法令改定に対応する見直し条項が実務的です。

チェックポイント②データ依存——インプットの利用範囲を切り分ける

第2の特徴は、モデルの性能が学習用データセットの品質に依存する点です。ガイドラインは、学習用プログラムの仕様に問題がなくても満足のいく性能のモデルが生成できない事態が十分に想定されるとし、未知データへの適用には本質的に誤差が含まれると述べています。

データに「所有権」はない——だから契約で書く必要がある

交渉で最もよく空転するのがデータの「帰属」です。ガイドラインは、データは無体物（情報）であるため所有権の対象とはなり得ない（民法206条、同法85条参照）と整理します。そのうえでデータは著作物や営業秘密、個人情報に該当する場合があり、著作権法・不正競争防止法・個人情報保護法により保護を受け得るとしています（学習用データセットがデータベースの著作物に該当する場合もあります。著作権法12条の2）。

決定的なのが次の指摘です。これらの法制による保護を受ける場合を除き、データの利用について法令上の明確な定めはなく、契約による定めがない限り、データに現実にアクセスできる者が自由に利用できる。したがって制限を希望するなら契約で明示的に禁止する必要がある——。つまり契約書に何も書かなければ、既定値は「渡した相手が自由に使える」側に振れます。

ベンダの「自社技術の開発目的」での利用を認めるか

チェックリストは、開発型契約ではインプットやその処理成果の利用条件が重要な検討事項になることが少なくないとし、典型例としてベンダがサービス提供目的を超えて自社技術の開発目的にインプットを利用することを希望する場合を挙げ、認めるか、認める場合の利用可能範囲および利用禁止範囲を検討する必要があるとしています。

ここが発注側の最も損をしやすい箇所です。長年蓄積した業務データを渡し、それが同業他社向けサービスの改良に使われる契約になっていないか。「利用可能範囲」と「利用禁止範囲」の両方が書かれているかを確認してください。チェックリストは、インプットを提供する立場からは「提供」「使用・利用（管理や消去等も対象）」「外部提供」の条項を見れば取扱いをおおむね確認できるとしています。

提供データに個人情報が混ざる場合

インプットに個人データが含まれる場合、第三者提供規制（個情法27条）の遵守が必要です。ベンダが外国に所在するときはさらに越境移転規制（個情法28条）が必要で、海外のAIサービスを組み込む構成では見落とされがちです。

一方、個人データの提供が利用目的の達成に必要な範囲内での取扱いの「委託」（個情法27条5項1号）に伴う場合は、あらかじめ本人の同意を得る必要はありません。ただし委託先は委託された業務以外に当該個人データを取り扱えず、委託元には委託先の監督義務（個情法25条）が課されます。「委託だから同意は不要」で終わらせない設計が必要です。

なお、令和8年7月17日に「個人情報の保護に関する法律等の一部を改正する法律」が公布され、ここで前提としている27条1項に例外が新設されましたが、施行期日は公布の日から起算して2年を超えない範囲内とされており、本記事の執筆時点では未施行です。新設される30条の2（個人情報に係る統計作成等の特例）は、統計情報等の作成にのみ利用されることが担保されていること等を条件に本人の同意のない個人データの第三者提供を可能とするもので、個人情報保護委員会の改正概要は「統計作成等」に統計作成等であると整理できるAI開発等を含むと明記しています。ただし書面による提供元・提供先間の合意、公表、提供先での目的外利用・再提供の禁止といった要件が置かれており、「AI開発なら同意が不要になる」わけではありません。具体的な対象範囲は委員会規則に委ねられているため、現時点の契約審査は現行法を前提に組み、施行時期と規則の内容が定まった段階で見直すのが実務的です。改正の内容はプロンプトに顧客情報を入れてよいか｜生成AIと個人情報保護法で詳しく整理しています。

チェックポイント③④ノウハウと再利用需要——「権利の帰属」より「利用条件」

ノウハウの重要性と再利用需要は、契約書では同じ場所で交わります。成果物と中間生成物を誰がどこまで使えるのかという条項です。成果物を構成する要素ごとに帰属の初期設定がどう変わるかは学習済みモデル・学習用データの権利帰属で切り分けています。

学習済みパラメータは知的財産権の対象にならない可能性が高い

ガイドラインは、成果物等の中には知的財産権の対象にならない可能性があるものも存在するとし、例として学習済みパラメータは大量の数値データであって創作性等が認められず、通常は知的財産権（著作権等）の対象にはならない可能性が高いと述べています。

知的財産権の対象とならない成果物等には、利用に関する法律上の明確なデフォルトルールが存在しません。したがって原則として現実にアクセス可能な当事者が自由に利用でき、制限するには当事者の合意によって直接「利用条件」を設定する必要があるとされます。利用態様が法令上定められていない以上、具体的な利用態様の合意が重要だという指摘です。

つまり「著作権はすべて甲に帰属する」という一文だけでは、成果物の相当部分をカバーできていない可能性があります。プログラム部分は著作権法の保護を受け得ますが（ソースコードはプログラムの著作物、著作権法10条1項9号）、学習済みパラメータはそこから漏れ得るのです。

「とりあえず全部の権利を取る」という発想の落とし穴

ガイドラインは実務の発想を名指しで指摘しています。実務的な知見の蓄積が十分でないこともあり、「何か問題があると困るため、とりあえず権利を全て取得しておけば安全である」との発想に陥るケースも散見される——。発注側には対価を払いデータ取得にも投資したのだから権利は自社にという意識が生じやすく、受託側には権利をすべて渡すと事業の自由度が制約されるという危惧がある。どちらも自然な言い分です。ガイドラインは、権利帰属の議論に多大なコストを費やすことが常に必要とは限らずAI開発の遅れを招きかねないとし、それぞれ何を求めているかを相互に理解して利用条件をきめ細やかに設定することで適切な合意に至れることもあるとしています。

実務的にはこれが最も現実的な解き方です。「所有」を争うのをやめ、用途・期間・分野・地域・独占非独占・第三者提供の可否で切り分ける。「同業種向けには使わせない」といった業種・競合単位の限定は、権利の全部取得よりも合意しやすく、守りたい実益にも直結します。なおガイドラインは、権利帰属や利用条件を決める基準として寄与度・労力・専門知識の重要性・当事者が受けるリスク等を挙げています。交渉はこの物差しに沿って組み立てるのが筋道です。

再利用需要とフォアグラウンドIP／バックグラウンドIP

ガイドラインは、学習用データセットや学習済みモデルは多大なコストと時間をかけて生成され、パラメータを変更すれば精度向上や他目的での利用も可能なため、従来のプログラムより多くの場面で再利用が可能だとし、方法として追加学習等による再利用モデルの生成・蒸留モデルの生成・アンサンブル学習を挙げています。ベンダには再利用の要望があり、ユーザには制限したいインセンティブがあるため利害調整の必要が生じるとまとめています。

チェックリストはより新しい整理を示します。開発により創出された成果に関する知的財産をフォアグラウンドIP、開発と関係なく各当事者が有する知的財産をバックグラウンドIPと位置づけたうえで、アウトプットの範囲が十分に認識されないまま開発が進み、決定段階に至ってフォアグラウンドIPかベンダのバックグラウンドIPかが争点になることも想定されると警告し、開発初期の段階で当事者の認識を擦り合わせることが重要としています。「開発が終わってから権利を決めよう」が最も揉める進め方だということです。

この論点はAI開発に限らず、制作物の受発注全般で起きます。実務上よくあるのは、Webサイトや広告の制作物について著作権を自社に残すのか発注者に譲渡するのかという整理で、近年はそこに「生成AIで作った素材が混じっている場合にどう扱うか」という論点が重なってきています。素材の出所と利用条件を切り分けて記録しておくことが、後の権利処理を軽くします。業務委託契約における知財帰属条項の設計は業務委託契約の知財帰属条項設計でも整理しています。

生成AI時代の追加論点——2025年2月チェックリストの3類型

チェックリストは、総務省・経済産業省「AI事業者ガイドライン」（2024年4月に第1.0版公表、2026年3月に第1.2版へ改訂）が整理するAI開発者・AI提供者・AI利用者の役割分担におおむね依拠しつつ、3類型を示しています。

受託側は「同時にユーザでもある」——立場の入れ替わり

類型2で注意が必要なのが立場の入れ替わりです。カスタマイズサービスを提供する事業者は、①その利用者との関係では提供者（ベンダ）だが、②汎用的AIサービスを提供する事業者との関係ではその汎用的AIサービスの利用者（ユーザ）になるとされています。つまり受託側が発注元に約束できる内容は、上流の汎用AIサービスの利用規約で自社が許されている範囲を超えられません。上流の規約が改定されれば、下流で約束した条件が履行できなくなることもあります。チェックリストが「規約改定に関する留意点」を独立項目に立てているのはこの構造への対応です。

受託側は上流の利用範囲・出力物の取扱い・改定手続と自社の約束に齟齬がないかを、発注側は成果物が第三者のAIサービスに依存する場合の依存関係と規約変更リスクが契約書に反映されているかを確認してください。成果物に生成AIの出力が混ざる場合の権利処理と非侵害保証は生成AIを組み込んだ受託開発と著作権で扱っています。関連論点はSaaS・IT企業の法務でも整理しています。

大阪の中小企業でよくある「うちの契約書だとどうなる？」の分かれ目

弁護士法人ブライトは大阪の中小企業の外部法務部として、契約書のレビューや知的財産の帰属をめぐるご相談を日常的にお受けしています。近年は、生成AIで作成した画像や文章を広告・制作物に用いる際の権利処理や表示上の注意点といったご相談も出てきています。以下では、AI開発の委託契約で実務上よく問題になる分かれ目を、一般的な論点として整理します。AI開発から社内でのAI利用までを含めた全体像はAI開発・AI活用の法律問題 総合ガイドで俯瞰できます。

発注側でよくある論点

• 期待した精度が出ないので支払いを止めたい——評価条件を伴った合格基準があるかで主張の組み立てが変わります。基準が曖昧なまま「使えないから払わない」と主張すると、逆に履行遅滞を主張されかねません
• 渡したデータで作られたモデルを他社に売られないか——契約で明示的に制限していなければ既定値は「使える」側です。競合・同業種単位での利用禁止範囲を書けているかが分かれ目です
• 委託先が倒産したらシステムが使えなくなる——成果物や中間生成物へのアクセスを相手方の信用リスクから切り離せているか。ソースコードや学習済みパラメータの預託など、契約段階で打てる手があります

受託側でよくある論点

• 汎用的な部分を他の案件でも使いたい——バックグラウンドIPや汎用的な技術・ノウハウを案件固有の成果物とどう切り分けているか。曖昧なまま「成果物の権利はすべて発注者に帰属」と署名すると、自社の既存資産まで巻き込まれかねません
• 将来の外販や事業展開の余地を残したい——開発の入口でどの範囲を自社が自由に使えるかを握る必要があります。事業譲渡やM&Aの局面で過去の受託契約の条項が制約になることは珍しくありません

いずれの立場でも、契約書の一般的な危険条項の見方は業務委託契約書のひな型と8つの危険条項が土台になります。AI開発では、そこに本記事の4つのチェックポイントを重ねる順序で考えるのが実務的です。

弁護士に相談すべきケース

• 自社の中核的な業務データ・ノウハウを学習用に提供する場合
• 提供データに個人情報が含まれる、または海外のAIサービスが構成に入る場合
• 相手方のひな型がそのまま提示され、権利帰属条項が一方に全部寄っている場合
• すでに精度や検収をめぐって認識の相違が生じている場合（この段階では、やり取りの記録の残し方が結果を左右します）

よくある質問

この記事の監修者

和氣 良浩（わけ よしひろ）

弁護士法人ブライト｜代表弁護士／パートナー弁護士

弁護士歴20年（2006年登録）／大阪弁護士会／大阪大学法学部卒

専門：顧問弁護士・企業法務・M&A・経営権紛争・事業再生

AI開発の委託契約書のチェック、権利帰属・利用条件条項の設計、PoC段階からの契約設計など、大阪でAI関連の法務課題を継続的に相談できる体制をお探しの方は、弁護士法人ブライトにお問い合わせください。顧問先130社以上の実名を公開しており、法務部がない会社の「外部法務部」として伴走します。企業法務窓口：0120-929-739／顧問サービス（みんなの法務部プラン）／企業法務トップ