AI開発委託契約書のチェックリスト｜知っておくべき条項
AI開発の契約書は、通常のシステム開発委託契約と共通する部分が多い一方で、学習データの扱いや生成物の権利関係など、AI特有の論点も含まれます。契約締結後に「思っていたのと違った」とならないよう、発注前に確認しておきたい条項を整理しました。
請負契約と準委任契約、どちらで結ぶべきか
AI開発の契約形態には、成果物の完成を約束する「請負契約」と、一定の業務遂行を約束する「準委任契約」があります。要件が明確なシステム開発部分は請負、精度がやってみないと分からないPoCやモデル調整のフェーズは準委任、という形で段階ごとに契約形態を分ける進め方が一般的です。
契約の冒頭でこの前提が曖昧なまま進んでしまうと、「完成」の定義を巡って発注者と開発会社の認識がずれ、検収の段階でトラブルになりやすくなります。どのフェーズをどちらの契約で進めるのか、契約書に明記してもらうことが最初の確認ポイントです。
フェーズごとに契約形態を分けるメリット
PoCの段階から本開発まで単一の請負契約で進めようとすると、精度がどの水準に達すれば「完成」なのかを事前に確定しづらく、発注者・開発会社の双方にとってリスクの高い契約になりがちです。フェーズごとに契約を分割すれば、各段階の終了時点で成果を確認し、次フェーズに進むかどうかを都度判断できます。
分割契約は事務手続きが増える一方、途中で方向転換や中止をしやすいという利点もあります。特に初めてAI開発を発注する企業にとっては、小さく検証しながら進められる分割契約のほうが結果的にリスクを抑えられるケースが多く見られます。
成果物の範囲と検収基準を具体的にする
AI開発では「動くモデル」がどのレベルであれば納品完了とみなすのか、検収基準を数値や具体的な条件で定義しておく必要があります。「精度が十分に高いこと」のような曖昧な表現では、双方の解釈がずれたときに解決が難しくなります。
検収基準に加えて、検収期間（納品後何日以内に検収を行うか）と、不合格だった場合の再修正の回数・範囲についても契約書に明記されているか確認しましょう。
- 成果物（モデル・ソースコード・ドキュメント等）の具体的な範囲
- 検収基準（評価指標・合格ライン）の数値化
- 検収期間と再修正の回数・範囲
- 納品形式（実行環境・ソースコード・API仕様書 等）
評価指標の数値化で認識ズレを防ぐ
画像分類の正解率、問い合わせ対応の一次解決率など、AIモデルの評価指標は用途によって様々です。契約書には「精度90%以上」のような単純な数値だけでなく、その数値をどのデータセットで、どのような条件下で測定するのかまで明記してもらうと、検収時の解釈のズレを防げます。
テスト用データセットを発注者・開発会社のどちらが用意するのかも、事前に取り決めておきたいポイントです。開発会社が用意したデータだけで高い精度が出ても、実運用データでは精度が下がるということが起こり得るため、可能であれば実データに近いテストセットでの評価を条件に含めるとよいでしょう。
再修正の範囲を「無制限」にしない工夫
検収不合格時の再修正について、「合格するまで無制限に対応する」という条項は一見発注者に有利に見えますが、実際には開発会社側がリスクを見込んで見積もりに上乗せすることが多く、結果的に費用が割高になる傾向があります。
再修正の回数や工数の上限を現実的な範囲で設定し、それを超える手戻りが発生した場合は、原因（要件定義の不備か、開発側の技術的な問題か）を踏まえて追加費用の負担者を協議する、という形にしておくと双方にとって納得感のある契約になりやすくなります。
著作権・知的財産権の帰属条項
生成されたモデルやソースコードの著作権が発注者・開発会社のどちらに帰属するかは、契約書で最も注意深く確認すべき条項の一つです。開発会社側の既存ライブラリやフレームワーク部分は開発会社に権利が残り、案件固有に開発した部分のみ発注者に譲渡される、という切り分けが一般的です。
権利の帰属だけでなく、他社への転用・再利用が可能かどうかも合わせて確認しておくと、将来的に別の開発会社へ乗り換える際にも困りません。
追加開発・仕様変更時の費用ルール
プロジェクトが進むにつれて、当初想定していなかった機能追加や仕様変更が発生することは珍しくありません。契約書には、こうした追加開発・仕様変更が発生した場合の見積もり・承認フローと、費用が発生するかどうかの基準をあらかじめ定めておくと、後になって「言った・言わない」の水戻りを避けられます。
特に、要件定義書に明記されていない細かい仕様（エラー時の挙動、想定外の入力への対応など）は、開発が進む中で「これは当然含まれるはず」という認識のズレが生じやすい部分です。軽微な調整と有償の追加開発の線引きについても、契約書または付随する覚書で共有しておくと安心です。
オープンソース活用部分の扱いを明文化する
開発会社が独自に構築した共通基盤（社内フレームワーク）を用いる場合、その基盤部分は複数の案件で再利用されることを前提に設計されていることが多く、成果物の権利をすべて発注者に譲渡するという建て付け自体が実務上難しいことがあります。契約書上は「案件固有の開発部分」と「既存基盤部分」を明確に区分し、それぞれの権利関係と利用条件を別々に定義しておくと、後々の認識齟齬を防げます。
学習データとモデルの取り扱い
社内データを学習に用いる場合、そのデータの利用範囲・保管期間・削除義務が契約書に定められているかを確認します。特に、開発会社が他社案件でも流用できる汎用モデルとして育てていくのか、案件専用のモデルとして扱うのかは、費用感にも影響する重要な論点です。
生成AIのAPIを組み込む構成の場合は、外部API提供元の利用規約とも矛盾がないか、契約書と合わせて確認しておくと安心です。
モデルの再利用・転用に関する取り決め
開発会社によっては、ある企業向けに開発したモデルの構造やノウハウを、匿名化した形で他社案件にも活かすビジネスモデルを採っている場合があります。これ自体は開発費用を抑えられる合理的な仕組みですが、自社のデータや業務ノウハウが競合他社の類似システムに間接的に活用されることに抵抗がある場合は、契約段階で転用の可否や範囲を明確にしておく必要があります。
逆に、独自性をそこまで求めず費用を抑えたい場合は、汎用モデルをベースにした開発を許容することで、見積もり金額を下げられる可能性もあります。自社の優先順位に応じて交渉するとよいでしょう。
データ提供時の匿名加工・マスキング範囲
学習データに個人情報や取引先の機微な情報が含まれる場合、開発会社に渡す前にどこまで匿名化・マスキング処理を行うかを事前に取り決めておく必要があります。加工の責任が発注者・開発会社のどちらにあるかが曖昧なまま進むと、個人情報保護の観点で思わぬリスクを抱えたままプロジェクトが進んでしまうことがあります。
特に、氏名や連絡先だけでなく、組み合わせによって個人が特定されうる項目（勤務先・役職・地域等）についても、匿名加工の対象に含めるかどうかを具体的にすり合わせておくと安心です。
保守・運用フェーズの責任分界点
納品後の保守・運用フェーズについて、どこまでが契約に含まれるのかを明確にしておきましょう。AIモデルは環境の変化（データの傾向変化等）により性能が徐々に劣化することがあるため、保守契約に「再学習」や「精度モニタリング」が含まれるかどうかで、運用コストが大きく変わってきます。
保守契約が別途必要な場合は、契約期間・費用・対応時間帯（平日日中のみか、休日も含むか）についても事前に確認しておくとよいでしょう。
精度劣化時の対応義務をどう定めるか
AIモデルは「一度作れば完成」ではなく、実運用データの傾向が変化するにつれて徐々に精度が落ちていく性質があります。保守契約の中に、精度が一定の水準を下回った場合の対応（再学習の実施、原因調査の範囲、追加費用の有無）が定められているかを確認しましょう。
モニタリング体制についても、開発会社側が定期的にレポートを提出する仕組みなのか、発注者側から異常を申告した場合のみ対応する受け身の体制なのかで、実際の運用負荷が大きく変わります。契約前にどちらの体制を求めるか整理しておくことをおすすめします。
損害賠償・免責条項の確認
AIの出力には一定の誤り（誤答・偏り等）が発生しうるため、その結果生じた損害についてどこまでが開発会社の責任範囲となるのか、上限額とあわせて確認しておくことが重要です。過度に開発会社側が免責される内容になっていないか、逆に現実的でない範囲まで責任を負わせる内容になっていないか、双方にとって妥当な水準かを見極めましょう。
契約書の細部は専門的な内容を含むため、金額の大きい契約や継続的な取引になる場合は、詳細を弁護士等の専門家にも確認いただくことをおすすめします。
保険加入の有無を確認する
開発会社によっては、業務上の過失によって発注者に損害が生じた場合に備え、賠償責任保険に加入していることがあります。特に、AIの誤判定が業務や顧客対応に直接影響するようなシステム（与信判断、医療関連の補助など）を発注する場合は、開発会社の保険加入状況を確認しておくと、万一の際の実効性のある補償につながります。
保険の有無だけでなく、損害賠償の上限額が契約金額の何倍程度に設定されているかも、契約交渉の際の確認ポイントとして押さえておきましょう。
契約解除条項も併せて確認する
プロジェクトが計画通りに進まない場合に備え、どのような条件で契約を解除できるのか、解除時に既払いの費用や制作途中の成果物がどう扱われるのかも確認しておきたい条項です。「重大な契約違反があった場合」のような抽象的な解除事由だけでなく、具体的にどのような状況を想定しているのかを事前にすり合わせておくと、いざという時の対応がスムーズになります。
