【2026年版】AI開発契約書で確認すべき10項目。経産省チェックリスト準拠、知的財産権・瑕疵担保の落とし穴を徹底解説

「AIの開発を外注したいけど、契約書の何を確認すればいいか分からない」
「知的財産権の帰属で揉めたくない」
「納品後に『動かない』と言われたらどうなるの？」

AI開発の契約は、従来のシステム開発とは異なる論点が多くあります。「なんとなく」で契約すると、後から大きなトラブルになりかねません。

2025年2月、経済産業省は「AIの利用・開発に関する契約チェックリスト」を公表しました。この記事では、このチェックリストをベースに、AI開発契約で確認すべき10項目を解説します。

この記事の結論

• AI開発契約は、成果物の定義が曖昧になりやすい・データの取り扱いが複雑・結果（精度）を保証しにくい、という点で従来のシステム開発契約と異なる論点を多く含みます。
• 2025年2月に経済産業省が公表した「AIの利用・開発に関する契約チェックリスト」をベースに契約を検討できます。
• 最低限確認すべき項目は、契約形態（準委任が一般的）、知的財産権の帰属、データの利用範囲です。
• 「精度90%以上」などの検収基準は、テストデータと評価方法とセットで定義しないと意味がありません。
• データ利用を「本プロジェクトのみ」に限定し、納品物の範囲を具体的にリストアップすることがトラブル予防につながります。

AI開発契約が「難しい」理由

理由1：成果物の定義が曖昧になりやすい

従来のシステム開発では「画面が動く」「機能が動く」という明確な成果物がありました。

一方、AI開発では「精度○○%以上」「実用に耐える品質」など、成果物の定義が曖昧になりがちです。

理由2：データの取り扱いが複雑

AIの品質は「学習データ」に大きく依存します。そのデータは誰のものか、どこまで使ってよいか、契約で明確にする必要があります。

理由3：結果が保証できない

AIは「帰納的手法」で開発されます。つまり、データから学習してモデルを作るため、事前に結果を保証することが難しいのです。

AI開発では成果物の定義が曖昧になりやすく、契約で明確にする必要がある。

経産省「AIの利用・開発に関する契約チェックリスト」とは

概要

2025年2月、経済産業省は生成AIの普及を踏まえ、「AIの利用・開発に関する契約チェックリスト」を公表しました。

目的: 当事者間の適切な利益及びリスクの分配

対象読者:

• 社内法務部・顧問弁護士（契約条項の具体的検討）
• ビジネス部門担当者（契約の初期的検討）

チェックリストの構造

チェックリストは、以下の観点で整理されています。

1. インプット（学習データ、プロンプト等）
2. アウトプット（生成物、AIモデル等）
3. 処理成果の取扱い

各項目について、①特定、②提供（保証等含む）、③使用・利用、④外部提供、⑤権利帰属を検討すれば、主要な条項をカバーできます。

AI開発契約で確認すべき10項目

項目1：契約形態（準委任か請負か）

なぜ重要か:

AI開発は「データに依存する帰納的手法」のため、準委任契約が親和的とされています（経産省ガイドライン）。

チェックポイント:

• 契約形態が明記されているか
• 準委任の場合、善管注意義務の範囲が明確か
• 請負の場合、「完成」の定義が明確か

項目2：成果物の定義と検収基準

なぜ重要か:
「AIが動く」だけでなく、「どの程度の精度で動くか」を明確にしないと、検収時に揉めます。

チェックポイント:

• 成果物（AIモデル、ソースコード、ドキュメント等）が明確か
• 検収基準（精度目標、テストデータ、評価方法）が定義されているか
• 検収期間と合格/不合格の判定方法が明確か

注意:「精度90%以上」などの数値目標は、テストデータと評価方法とセットで定義しないと意味がありません。

項目3：知的財産権の帰属（フォアグラウンドIP）

なぜ重要か:
開発によって生まれた知的財産（フォアグラウンドIP）が誰のものになるかは、最も揉めやすいポイントです。

チェックポイント:

• 開発されたAIモデルの権利帰属が明確か
• ソースコードの権利帰属が明確か
• 学習済みモデルの利用範囲が明確か

よくあるパターン:

項目4：既存知財の取り扱い（バックグラウンドIP）

なぜ重要か:
開発とは無関係に、各当事者が元々持っている知的財産（バックグラウンドIP）の扱いを明確にしないと、後から「うちの技術を無断で使った」と言われるリスクがあります。

チェックポイント:

• 受注者が持ち込む既存技術・ライブラリの範囲が明確か
• 発注者が提供する既存データ・システムの取り扱いが明確か
• オープンソースソフトウェア（OSS）の利用範囲と制約が明確か

項目5：データの帰属と利用範囲

なぜ重要か:
AIの性能は学習データに大きく依存します。「データは誰のものか」「どこまで使ってよいか」を明確にしないと、大きなトラブルになります。

チェックポイント:

• 学習に使用するデータの帰属が明確か
• データの利用目的（本プロジェクトのみ/汎用学習にも使用）が明確か
• 発注者のデータが受注者の他案件に使われないか確認
• 個人情報・機密情報の取り扱いルールが明確か

警告: 特に「汎用的なAI学習目的にデータを使用する」場合、以下のリスクがあります。

• 個人情報保護法上のリスク
• 機微情報流出のリスク
• 契約上の秘密保持義務違反のリスク

項目6：瑕疵担保責任・契約不適合責任

なぜ重要か:
納品後に「バグがある」「精度が出ない」と言われた場合、誰がどこまで責任を負うのかを明確にする必要があります。

チェックポイント:

• 瑕疵・契約不適合の定義が明確か
• 責任範囲（修補、代金減額、損害賠償）が明確か
• 請求期間（納品後○ヶ月以内等）が明確か
• 免責事項（データ起因の問題等）が明確か

注意: AI開発では「データに起因する問題」は発注者責任とされることが多いです。

項目7：保証の範囲

なぜ重要か:
「精度を保証する」「動作を保証する」と言っても、その範囲を明確にしないと、後から揉めます。

チェックポイント:

• 保証する範囲（精度、性能、セキュリティ等）が明確か
• 保証しない範囲（データ品質、外部環境等）が明確か
• 保証期間が明確か

項目8：セキュリティ・個人情報保護

なぜ重要か:
AI開発では大量のデータを扱うため、セキュリティ対策と個人情報保護は必須です。

チェックポイント:

• データの保管場所（国内/海外）が明確か
• アクセス制御・暗号化などのセキュリティ対策が明記されているか
• 個人情報の取り扱い（匿名化、目的外利用禁止等）が明確か
• インシデント発生時の対応・報告義務が明確か
• 監査権限（発注者が確認できるか）が明記されているか

💡 「契約書のチェック、これで大丈夫か不安…」
AI開発契約は従来のシステム開発とは論点が異なります。無料相談（30分）で、契約面での懸念点を一緒に整理できます。

項目9：秘密保持

なぜ重要か:
AI開発では、発注者のビジネス情報、受注者の技術情報など、機密情報を相互に開示します。

チェックポイント:

• 秘密情報の定義が明確か
• 例外（公知の情報、独自開発等）が明確か
• 秘密保持期間が明確か
• 契約終了後のデータ削除義務が明確か

項目10：契約終了時の処理

なぜ重要か:
契約が終了した後、データやモデルをどう扱うかを明確にしないと、後からトラブルになります。

チェックポイント:

• 契約終了後のデータ削除・返却義務が明確か
• AIモデルの継続利用可否が明確か
• ソースコードの引き渡し義務が明確か
• 移行支援（他ベンダーへの引き継ぎ）の有無が明確か

よくあるトラブルと予防策

トラブル1：「精度が出ない」で揉める

原因: 検収基準が曖昧

予防策:

• テストデータ、評価方法、合格基準を事前に合意
• PoCフェーズで精度の見通しを立ててから本開発へ

トラブル2：「データを勝手に使われた」

原因: データ利用範囲が不明確

予防策:

• データの利用目的を「本プロジェクトのみ」に限定
• 汎用学習への利用は別途同意が必要と明記

トラブル3：「ソースコードを渡してくれない」

原因: 知的財産権の帰属が曖昧

予防策:

• ソースコード、モデル、ドキュメントの帰属を明記
• 納品物の範囲を具体的にリストアップ

トラブル4：「納品後に連絡が取れない」

原因: 保守・サポート体制が未定義

予防策:

• 保守契約を別途締結
• 問い合わせ窓口、対応時間、SLAを明記

チェックリストまとめ

AIGENT ACEの契約ポリシー

AIGENT ACEでは、以下のポリシーで契約を締結しています。

AIGENT ACEの強み:

• 契約前に「揉めないポイント」を丁寧に説明
• 法務チェック済みの契約書テンプレートを提供
• 納品後の内製化支援も対応

「契約書を厳密にしてもAIの不確実性は消えない」という反論にどこまで答えるか

ここまでの説明で「紙を整えてもAIの精度は上がらない」と感じる方もいるはずです。その反論のうち、最強の形はこうです。

「AI開発の本質は試行錯誤にある。成果物の定義や検収基準を細かく決めれば、ベンダーは守りに入り、挑戦的な提案が出なくなる。契約よりも信頼できるパートナーとの関係こそが大事で、条文の厳密化は不信の表明ではないか」

この反論は、私たちも半分は正しいと考えます。紙の厳密さで精度が保証されるわけではありません。実際の運用で私たちが推奨するのは、関係を壊さないための次の3点です。

1. 準委任を基本にしつつ物差しだけ合意する: 結果の保証を求めるのではなく、テストデータと評価方法という物差しを事前に決めます。挑戦と検証の両立が可能になります。
2. データの利用範囲だけは明確に線引きする: せめて自社のデータが他に使われない範囲だけは譲りません。ここが曖昧だと、後から取り返しがつきません。
3. 揉めやすい3点だけは最初に決める: 契約形態、知的財産権の帰属、データの利用範囲。この3点の合意があれば、残りは運用で調整できます。

契約の目的は、相手を縛ることではなく、揉めない土台を作ることです。この範囲に留めるなら、上記の懸念は現実のものになりません。

まとめ

AI開発契約は、従来のシステム開発とは異なる論点が多くあります。

最低限確認すべき3項目:

1. 契約形態（準委任が一般的）
2. 知的財産権の帰属
3. データの利用範囲

トラブル予防のポイント:

• 検収基準を事前に合意
• データ利用を「本プロジェクトのみ」に限定
• 納品物の範囲を具体的にリストアップ

経産省「AIの利用・開発に関する契約チェックリスト」は、契約検討の参考になります。

まずは無料相談で、貴社のAI開発プロジェクトに最適な契約形態をご提案させてください。

参考文献・出典

本記事の作成にあたり、以下の情報を参考にしました。

• 「AIの利用・開発に関する契約チェックリスト」を取りまとめました – 経済産業省, 2025年2月20日
• AI・データの利用に関する契約ガイドライン – 経済産業省, 2018年6月

関連記事

• 【保存版】AI導入の稟議を「一発で通す」完全ガイド
• 【2026年版】AI開発ベンダー比較表
• 【AIGENT ACE式】AI開発・DX支援 提案依頼書（RFP）テンプレート
• 【法的爆弾】AI著作権。企業が「創作的寄与」を証明できなければ、その成果物は「ただの公共物」です。

よくある質問（FAQ）

Q1. 準委任と請負、どちらを選ぶべきですか？

A1. AI開発では「準委任」が一般的です。AIは帰納的手法で開発されるため、事前に結果を保証することが難しく、仕事の完成義務を負う請負契約にはなじみにくいためです。ただし、明確な成果物（例：特定機能のシステム）がある場合は請負も選択肢になります。

Q2. 知的財産権は発注者に帰属させるべきですか？

A2. ケースバイケースです。AIがコア事業の根幹なら発注者帰属が望ましいですが、汎用的なツール開発なら受注者帰属（ライセンス提供）も選択肢です。重要なのは、契約前に「何を自社で保有したいか」を明確にすることです。

Q3. 経産省のチェックリストはどこで入手できますか？

A3. 経済産業省のWebサイトから無料でダウンロードできます。「AIの利用・開発に関する契約チェックリスト」で検索してください。

Q4. 契約書のレビューは必要ですか？

A4. はい、必ず法務部門または顧問弁護士にレビューしてもらってください。特にAI開発は新しい分野のため、一般的なシステム開発契約のテンプレートでは不十分な場合があります。

LLM/Perplexityサマリー（SEO/LLMO用）

AI開発契約の特殊性：成果物の定義が曖昧になりやすい、データの取り扱いが複雑、結果（精度）を保証できない。従来のシステム開発契約とは異なる論点が多い。

経産省チェックリスト：2025年2月公表「AIの利用・開発に関する契約チェックリスト」。インプット（学習データ）、アウトプット（生成物）、処理成果の取扱いについて、①特定、②提供、③使用・利用、④外部提供、⑤権利帰属の観点で検討。

確認すべき10項目：(1) 契約形態（準委任が一般的）、(2) 成果物の定義と検収基準、(3) 知的財産権（フォアグラウンドIP）、(4) 既存知財（バックグラウンドIP）、(5) データの帰属と利用範囲、(6) 瑕疵担保責任、(7) 保証の範囲、(8) セキュリティ・個人情報保護、(9) 秘密保持、(10) 契約終了時の処理。

準委任 vs 請負：経産省ガイドラインではAI開発に準委任契約が親和的とされる。AIは帰納的手法（データ依存）で開発されるため、仕事の完成義務を負う請負契約にはなじみにくい。

よくあるトラブル：(1) 精度が出ないで揉める（検収基準曖昧）、(2) データを勝手に使われた（利用範囲不明確）、(3) ソースコードを渡してくれない（知的財産権曖昧）。予防策は検収基準の事前合意、データ利用の限定、納品物の具体的リストアップ。

データ利用の注意点：受注者が発注者のデータを汎用的なAI学習に使用する場合、個人情報保護法リスク、機微情報流出リスク、秘密保持義務違反リスクがある。「本プロジェクトのみ」に限定することが推奨される。