AI開発委託・PoC契約の注意点｜業務委託契約との違いを整理する

1. AI開発委託・PoC契約が通常の業務委託契約と違う理由

通常の業務委託契約（システム開発・役務提供）は、「仕様→開発→検収→引渡し」という直線的なモデルを前提に作られています。発注者は仕様を確定でき、ベンダーはそれに従って成果物を完成させ、検収で合否が決まります。

これに対しAI開発、特に機械学習モデルや生成AIの個別開発・PoCは、次の点で前提が崩れます。

1-1. 「やってみないと挙動が分からない」前提

AIモデルの精度や挙動は、データの質・量、タスクの難易度、モデル選定によって大きく変動します。事前に「正解率○％を保証する」と確約することは技術的に困難であり、これを通常の請負契約のように「完成義務」として書き込むと、ベンダー側が事実上引き受けられない契約になります。生成AIを用いる場合は、そもそも「正解率」という指標がなじまず、ハルシネーションの許容範囲やフィルタリング方針として整理する必要があります。

1-2. 成果物の輪郭が曖昧

「AIモデル」と一口に言っても、対象は学習済みパラメータ、推論用スクリプト、前処理コード、教師データ、評価データ、評価レポート、業務組み込み用のAPI、UI、プロンプトテンプレート——と幅広く、契約書で「成果物」とだけ書くと、後で範囲争いが起きます。

1-3. データの権利処理が成果物と別軸で発生

通常の業務委託では、発注者が出した資料はそのまま使えるのが普通です。しかしAI開発では、学習データ・教師データ・評価データの取扱い、第三者著作物の混入、個人情報の処理、生成物の権利、海外再委託先での処理など、成果物とは別軸でデータの権利処理を整理する必要があります。

1-4. ベンダー側にノウハウ・基盤モデル・派生モデルが残る

AI開発では、当該案件用に作ったモデルとは別に、ベンダーが汎用的に持つ既存モデル・基盤モデル、学習・チューニングのノウハウ、派生して得られた改善知見が必ず生まれます。これを発注者の成果物と一括して「全部発注者に帰属する」と書くと、ベンダー側が事業として継続できず、契約自体が成立しにくくなります。

1-5. PoCと本開発で目的が違う

PoCは「やる価値があるかを検証する」段階、本開発は「業務に組み込む」段階です。両者を同じ契約フォーマットに乗せると、PoCに過度な完成義務を押し付けたり、逆に本開発で精度や運用性を曖昧にしたまま走らせる、という両極の事故が起きます。

1-6. 比較表：通常の業務委託契約とAI開発委託契約の違い

2. PoC段階で先に決めておくべき事項

PoCは「とりあえずやってみる」と言われがちですが、契約上は「目的・終了条件・成果物・費用・データ・権利の落としどころ」を最低限明文化していないと、後の本開発交渉やトラブル時に紛糾します。

2-1. PoCの目的と終了条件を分ける

まず、PoCが 「技術的な実現可能性の検証」なのか、「本開発の前提として精度・運用性を見極める段階」なのか、それとも実質的に既に実装着手段階なのかを切り分けます。これにより、求められる水準、評価方法、契約上の責任の重さが変わります。

2-2. 評価条件は契約段階で確定させる

「PoC終了時に評価する」ではなく、評価データの選定方法・評価指標（判別系であれば Accuracy・Precision・Recall・F1 等、生成AIであればハルシネーション率・タスク成功率・人手評価基準等）・許容水準・評価実施者を契約段階で合意しておきます。事後に発注者と受託者が異なる評価データで主張をぶつけ合うのが最悪のパターンです。

2-3. PoCの成果物を「何を引き渡すか」で定義する

PoCの成果物は、本開発で使う前提の「学習済みモデル」を含むのか、評価レポートのみか、検証用スクリプトを含むのか、によって権利関係も再利用可否も変わります。

2-4. 本開発移行の有無と条件

PoCの結果が良好な場合に本開発契約へ移行するのか、移行しない場合の費用・成果物の扱いはどうするのか。「PoC成功時に独占交渉権を発注者に与える」「本開発を別ベンダーに移す場合の中間成果物の取扱い」などは、PoC開始前に整理します。

2-5. PoC契約で曖昧にしやすい論点一覧

3. 本開発契約で詰めるべき事項（契約骨格）

本開発契約では、PoCで残った曖昧さを 業務に組み込める水準まで詰めます。本章では契約類型・成果物定義・ライセンス・出口戦略といった契約骨格を扱い、検収・責任・損害賠償の設計は次章で扱います。

3-1. 契約類型の選択は「要件確定度」で判断する

AI開発の契約類型は一律ではありません。基本構造は次のように整理できます。

• 請負契約（民法632条）：仕事の完成を目的とする契約。成果物の完成までを目的（義務）とし、契約不適合責任（民法562条以下）を負う。
• 準委任契約（民法656条）：法律行為以外の事務処理の委託。成果物の完成までは目的としないが、善管注意義務（民法644条）を負う。改正民法（2020年4月施行）以降は、報酬の支払い方によって 「履行割合型」（民法648条3項）と「成果完成型」（民法648条の2）が明文上区別される。

この整理を踏まえると、AI開発では次の使い分けがなじみやすいです。

• PoC・探索的開発フェーズ：要件・評価条件が固まりきらないため、準委任ベースがなじみやすい。報酬を「評価レポート提出」に紐づける場合は成果完成型準委任として整理する。
• 本開発フェーズ：要件・評価条件が相応に固まれば、成果物の引渡しを目的とする請負的整理もあり得る。ただし、契約不適合責任の対象・範囲は AI 案件向けに限定する設計が必要。
• 運用・保守・再学習フェーズ：継続的な事務処理が中心となるため、履行割合型準委任がなじむ。

「AI案件は準委任一択」と決め打つのではなく、当該フェーズの要件確定度に応じて類型を選ぶのが正攻法です。

3-2. 成果物を細目で定義する

「AIシステム一式」ではなく、学習済みモデル（重み・構造）／推論コード／前処理・後処理スクリプト／API／UI／プロンプトテンプレート／評価レポート／ドキュメント等に分解し、それぞれの成果物について、引渡し物・形式・媒体・依存環境を明記します。

3-3. 基盤モデル・OSSのライセンス条件を契約に取り込む

ベンダーが既存の基盤モデル（Foundation Model）やOSSライブラリをベースに開発する場合、成果物の権利を発注者に帰属させる旨を契約に書いても、上流のライセンス条件が優先します。たとえば次のような論点が生じます。

• ベース基盤モデルのライセンスが、商用利用・再配布・派生物の公開を制限していないか。
• OSSライセンス（Apache 2.0、MIT、BSD、GPL/LGPL、AGPL等）の条件（表示義務、ソース公開義務、コピーレフト効果）が、発注者の利用方法と整合するか。
• ライセンスバージョンの変更・終了時に発注者の利用が継続できるか。

本開発契約では、使用する基盤モデル・主要OSSの一覧、各ライセンス条件、商用利用上の制限の有無、契約終了後の継続利用条件をベンダーに開示させ、別紙として契約に取り込んでおくのが安全です。

3-4. 出口戦略（Exit Strategy）とベンダーロックイン対策

AI案件は、特定のベンダー環境・推論基盤・MLOpsプラットフォームに強く依存しがちで、契約終了時に他環境へ移行できない「ベンダーロックイン」が発生します。本開発契約には、次のような条項を入れておきます。

• モデルのポータビリティ：学習済みパラメータ・重み・構造定義・必要な前処理ロジックを、標準的な形式（ONNX 等）または合意した形式で引き渡す義務。
• 移行支援義務：契約終了時に、後続ベンダー・自社環境への引継ぎ作業を一定期間・一定費用で受託する義務。
• 運用ドキュメントの整備：再現に必要な手順・依存関係・運用ノウハウを引継ぎ可能な水準でドキュメント化する義務。
• データ消去・証明：契約終了後、ベンダー側で発注者のデータ・派生データを消去し、消去証明を提出する義務。

3-5. 運用・保守フェーズの分離

AIシステムは納品して終わりにならず、再学習・モデル差替え・精度モニタリング・基盤モデルのバージョン更新対応が続きます。本開発契約とは別に運用・保守契約を結ぶか、本契約内で運用フェーズを別章として切り出すのが安全です。

4. 成果物・データ・モデル改善の整理（権利関係）

AI開発委託の権利関係で最も誤解されやすいのが、「成果物の権利を発注者に帰属させれば全部安全」という発想です。実際には、成果物・提供データ・派生データ・モデル改善分・ベンダーの汎用ノウハウ・基盤モデル・OSSを別軸で整理する必要があります。

4-1. 「全部発注者に帰属」がうまくいかない理由

ベンダーは複数案件を通じてモデルやノウハウを蓄積しており、特定案件の成果物として全部譲渡してしまうと、他案件の継続利用ができなくなります。逆に発注者からみると、自社データで精度向上した部分まで他社に流用されるのは避けたい。「層ごとに切り分ける」発想が鍵です。

4-2. 整理表：成果物・データ・モデル改善・ノウハウの整理

4-3. データの権利処理は提供前に行う

「学習データの提供」は契約上の義務ですが、そのデータの権利処理（第三者著作物の利用許諾、個人情報の取得経路と利用目的、営業秘密性、開示禁止対象の有無）は発注者側の責任で事前に終わらせておく必要があります。これを契約後にベンダーに丸投げすると、開発が止まり、責任所在も曖昧になります。著作権との関係では、AI学習段階での著作物利用は著作権法30条の4（非享受目的の利用）の範囲で適法とされる余地がありますが、文化庁「AIと著作権に関する考え方について」（2024年3月）も踏まえ、享受目的が併存しないか・追加学習の態様が問題ないかを案件ごとに確認します。

4-4. 海外再委託・越境データ移転（個情法28条）

開発ベンダーが海外（アジア圏のオフショア拠点等）のエンジニアやアノテーターを起用する場合、個人データを含む学習データの提供は、個人情報保護法28条の「外国にある第三者への提供」に該当する場合があります。委託に伴う提供であっても同条の適用は外れません。実務上は、次のいずれかで対応することになります。

1. 提供先国がEU・英国等、施行規則15条で定める「同等水準国」に該当する場合は、本人同意なく提供可。
2. 提供先が施行規則16条の「基準適合体制」を整備している場合は、本人同意なく提供可。ただしこの場合、提供元は定期的な確認義務・本人への情報提供義務を負う。
3. 上記いずれにも該当しない場合は、本人同意を取得する。

さらに、同等水準国・基準適合体制で対応する場合や、海外サーバ・海外従業者経由で個人データを取り扱う場合は、「外的環境の把握」として、当該外国の個人情報保護制度を把握した上で安全管理措置を講じ、プライバシーポリシー等で明示する義務（個情法23条、32条1項4号、政令10条1号）も別途生じます。AI開発委託契約では、再委託先の所在国・取扱う者の所在国・利用するクラウド／サーバ所在国の開示と該当する場合の対応スキームの合意を契約段階で固めておく必要があります。

5. 精度評価・検収・責任の考え方（責任設計）

本章では、契約骨格（前章）を踏まえた上で、精度評価・検収・契約不適合・損害賠償・第三者侵害といった責任設計を扱います。

5-1. 「精度保証」は原則として書かせない・書かない

AIモデルの精度は、データ・タスク・運用環境に強く依存するため、「正解率○％を保証する」という形式の保証条項は、ベンダーにとって過度な負担となり、発注者にとっても実効性が乏しい条項になりがちです。実務では「合意した評価条件において一定水準を上回るよう善管注意義務をもって対応する」という整理が一般的です。

5-2. 検収は「評価条件」で行う

検収は、合意した評価データ・評価指標・許容水準に照らして合否を判定します。事前合意が無いと、検収段階で評価方法から争いになります。生成AIの場合は、自動指標だけでは合否判定が困難なため、人手評価のサンプリング基準・評価者要件・許容ハルシネーション率等まで設計しておく必要があります。

5-3. 契約類型ごとの責任構造

契約類型の選択（前章3-1）と連動して、責任の構造が変わります。

• 準委任ベースで組む場合：そもそも成果完成義務を負わせない構造にするのが基本。善管注意義務違反の有無で責任を判断する。検収は「評価条件下で水準を満たしたかどうか」のチェックポイントとして設計する。
• 請負ベースで組む場合：完成義務と契約不適合責任（民法562条以下）が当然に伴うため、契約不適合責任の対象を「合意した評価条件における水準未達」に限定し、責任の通知期間・救済手段（追完・代金減額・損害賠償・解除）の範囲を AI 案件に合わせて調整する必要がある。

請負と準委任の違いの基礎は 請負契約と準委任契約の違いとは？を、検収条項の設計の基本は 検収条項とは？を参照してください。

5-4. 損害賠償条項は責任範囲・上限・除外を整理する

AIシステムの誤判定によって発注者の業務に発生した間接損害・逸失利益までベンダーに負わせるのは、現実的ではありません。責任範囲・上限額（多くは契約金額相当）・除外損害（間接損害・逸失利益・第三者損害）を必ず整理します。詳細は 業務委託契約の損害賠償条項を参照してください。

5-5. 第三者の権利侵害（特に著作権）への備え

AIの生成物が第三者の著作物・商標等を侵害するリスクへの責任分担も重要です。基本的な考え方としては、学習データに混入した第三者権利物については提供主体側、生成物の利用方法に起因するリスクについては利用者側に整理することが多いものの、実際には、提供データ側の権利処理不備、ベンダー側のモデル設計・フィルタリング不備、利用者側の利用態様が重なって生じることが多く、補償条項や責任分担は個別事情に応じて修正されます。一律の線引きで済む論点ではない点に留意が必要です。

5-6. セキュリティ責任の分担

生成AIを業務に組み込む場合、プロンプトインジェクション、機密情報の漏えい、データ汚染（Poisoning）、モデル抽出攻撃といったAI固有のセキュリティ論点が生じます。本開発契約では、ベンダーが講ずべき対策（入出力フィルタ、権限制御、ログ取得、定期的な脆弱性評価等）の水準と、発注者側で講ずべき対策（利用ルール、ユーザー教育、業務フロー上の人手確認）を分けて整理しておきます。

6. チェックリスト

7. まとめ