AIエージェント開発を外注するときの契約で決めること｜責任の分担・成果物の権利・データの扱い・終わり方

AIエージェントの開発を外部へ委託するとき、見積の金額と期間は熱心に詰めても、契約書は相手から出てきたひな形をそのまま回してしまうことがあります。ところがAIを使った仕組みは、誤った出力が出る前提で運用するものなので、従来のシステム開発の契約では決めきれない項目がいくつか残ります。この記事では、法務へ回す前に自社で決めておく6項目と、確認する順番を扱います。条文の書き方や法令の解釈には踏み込まず、社内で結論を出しておく内容に絞ります。

契約書は法務へ回す前に、自社の希望を決めておく

契約書のやり取りが長引く場面の多くは、法務の作業が遅いのではなく、発注部門が何を望むかを決めていないことが原因です。「責任の範囲をどうしますか」と法務から聞かれても、業務を知らなければ答えようがありません。逆に、誤った出力が出たときに誰がどこまで持つかを発注部門が決めていれば、法務の作業は条文の形に落とすところから始まります。

決めるのは次の6項目です。どれも金額や期間と違って、後から変えるには相手の同意が要ります。

決める項目	決めないまま進むと起きること	契約書に落とす形
誤った出力が出たときの責任	事故のたびに、どちらの落ち度かを個別に交渉することになる	人が確認する工程を明記し、その工程を経た出力の扱いを書く
成果物の権利の所在	同じ仕組みを他社へ転用されても止められない	コード・設定・プロンプトそれぞれの権利者と、使ってよい範囲
自社データの二次利用と保管	渡したデータが学習や改善の材料として残る	利用目的の限定、保管場所、契約終了後の削除と報告
検収の基準	「動いている」の解釈が分かれ、支払いが止まる	判定に使うデータ、合格ライン、判定の期間と回数
保守の範囲	月額に含む作業が食い違い、追加請求が出る	含む作業と時間、超過分の単価、対応時間帯
契約を終えるときの引き渡し	移行のたびに追加の費用と期間を積まれる	引き渡す物の一覧と、引き渡しの期限・形式

6項目を先に決めておくと、法務のやり取りは条文の形を整える作業から始められる。

準委任で結ぶか請負で結ぶかで、検収と直しの扱いが変わる

6項目の中身へ入る前に、契約の型を決めます。実務では準委任と請負のどちらかで結ぶことが多く、どちらを選ぶかで検収と、納品後に不具合が見つかったときの直しの扱いが変わります。

見るところ	準委任で結んだ場合	請負で結んだ場合
約束するもの	決めた体制と期間で作業を進めること	合意した状態の成果物を仕上げて引き渡すこと
検収	作業報告の確認が中心になり、合否の判定は置きにくい	合格ラインに照らして合否を判定する
納品後に見つかった不具合	追加の作業として都度合意する	契約で定めた期間内は委託先の負担で直す取り決めを置ける
向いている工程	要件が動く要件定義・検証、精度を詰める工程	範囲と合格ラインが固まった実装・接続

AIエージェントの開発は、工程ごとに向く型が違います。どの程度の精度が出るかを確かめる段階で完成を約束させると、相手は安全側に倒した金額を出すか、達成しやすい低い基準を置きます。一方、範囲と合格ラインが決まったあとの実装まで準委任のままにすると、動かないものを受け取っても直しの根拠がありません。工程で型を分け、要件定義と検証は準委任、実装と接続は請負とする組み方が扱いやすくなります。どの工程をどちらに置くかは、発注先に希望として伝える段階で決めておきます。提案と見積から発注先を見極める観点は「AIエージェント開発会社の選び方」にまとめています。

なお、条文の書き方や個別の解釈は法務や顧問弁護士の領域です。ここで決めるのは、どの工程をどちらの型で結びたいかという希望までで十分です。

誤った出力が出たときに、どこまでを誰が持つか

AIを使った仕組みは、正しく作っても誤った出力が出ます。この前提を契約書に書かないまま進むと、事故が起きるたびに、仕組みの欠陥なのか運用の問題なのかを個別に交渉することになります。

分担を決めるには、人が確認する工程を先に定めます。処理の結果を人が見て確定させる工程が業務の中にあるなら、その工程を通った出力について、内容の責任は発注側が持つのが自然な形です。逆に、人の確認を挟まずに社外へ出る出力があるなら、そこは設計の妥当性を含めて委託先と条件を詰める箇所になります。どの工程に人の承認を残すかは「AIエージェントにどこまで任せるか」で扱っています。

そのうえで、委託先が持つ範囲を分けて考えます。合意した仕様どおりに動かない場合は委託先の範囲です。仕様どおりに動いたうえで、AIの出力が想定と違った場合は、合格ラインを満たしているかどうかで判断が分かれます。だからこそ、次に挙げる検収の基準を数値で決めておく必要があります。基準が無いと、責任の分担も決まりません。

成果物とプロンプト、学習データの権利を分けて書く

「成果物の権利は発注側に帰属する」の一文で済ませると、AIの開発では抜けが出ます。成果物と呼ばれるものが一つではないためです。

開発されたコードと設定ファイル
AIへ渡す指示文（プロンプト）と、その調整の履歴
判定基準や分類の定義を書いたファイル
委託先が元から持っていた部品やひな形
精度を測るために作った評価用のデータと正解付けの結果

このうち、委託先が元から持っていた部品は、他の案件でも使うものなので発注側へ移らないのが通常です。ここを一律に「すべて発注側へ帰属」と書こうとすると交渉が止まります。分けたうえで、自社が譲れない範囲だけを指定します。

実務で効いてくるのはプロンプトと判定基準の扱いです。AIエージェントの動きは、コードよりも指示文と基準の書き方で決まる部分が大きく、これが手元に残らないと、別の会社へ移るときに動きを再現できません。少なくとも、自社の業務に合わせて調整した指示文と判定基準は、自社で保有するか、自由に使える形にしておきます。評価用のデータは自社の業務データから作ることが多いため、こちらも自社に残す前提で書きます。

自社データの二次利用と保管場所

渡すデータについては、三つを書きます。何に使ってよいか、どこに置くか、いつ消すかです。

利用目的は、今回の業務の範囲に限ると書くのが基本形です。そのうえで、委託先のサービス改善や、モデルの学習の材料として使うことを認めるかどうかを明示します。認めないなら、その旨を書かない限り歯止めになりません。委託先が外部のAIサービスを利用する場合は、そのサービス側の条件も確認の対象になります。

保管場所は、国内か国外か、どのクラウドの契約かまで特定します。情報システム部門の審査で必ず聞かれる項目なので、審査の資料と契約書の記載が食い違わないようにします。確認される項目は「生成AIのセキュリティ審査チェックリスト12項目」に整理しています。

消す条件は、契約が終わったときだけでなく、途中で中止した場合も書きます。削除したことをどう確認するか、報告書を出してもらうのか、期限は何日以内かまで決めておくと、終了時のやり取りが短くなります。

検収の基準は、判定に使うデータまで含めて決める

検収でもめるのは、合否の判定方法が決まっていないためです。「正しく動作すること」という条件では、何件試してどれだけ合えば合格なのかが決まりません。契約書または別紙に、次を書きます。

何を1件と数えるか（書類1通なのか、抽出する項目ごとなのか）
対象にする項目と、項目ごとの合格ライン
判定に使うデータの出どころ、件数、誰が正解を付けるか
判定を行う期間と、不合格だった場合の再判定の回数
合格ラインに届かないまま期間が過ぎた場合の扱い

判定に使うデータを誰が用意するかは、特に決めておきます。業務を知っている人でなければ正解を付けられないため、発注側の作業になることが多く、日程と人の手当てが要ります。合格ラインの置き方そのものは「AIエージェントの精度をどう評価するか」を参照してください。

再判定の回数を決めておく理由は、期限の無い直しの往復を避けるためです。回数の上限に達しても届かない場合に、範囲を狭めて合格とするのか、契約を解除するのかを先に書いておくと、その局面で交渉から始めずに済みます。

保守の範囲と、運用が始まってからの費用

運用が始まったあとの条件は、開発の条件とは別に書きます。月額の金額だけが決まっていて中身が書かれていないと、どこまでが含まれる作業かで食い違います。

書くのは、対応する時間帯、障害が起きたときの連絡の順路と目安の返答時間、月額に含む作業時間、含まれない作業の単価です。AIを使った仕組みでは、これに加えて基準の調整を誰が行うかを決めます。業務の書式が変わったり、判定の傾向を直したりする作業が定期的に発生するためで、月に何時間分を含むかを数値で置きます。

自社側でどこまで直せるようにするかも、ここで決まります。基準の調整を自社の担当者が行える形にしておくと、軽微な変更のたびに見積と承認を挟まずに済みます。運用を引き取る体制の作り方は「内製したAIエージェントの運用・保守」にまとめています。

終わり方を、始める前に書いておく

契約を終えるときの条件は、締結の時点でしか決められません。移行の話が出てから交渉すると、相手には引き延ばす余地があり、こちらには時間がないためです。

引き渡しの対象として、少なくとも次を一覧に書きます。

引き渡す物	無いと起きること	書く形
ソースコードと設定ファイル	別の会社が引き継げず、作り直しになる	保管場所と形式、引き渡しの期限
指示文と判定基準	同じコードでも動きを再現できない	調整の履歴を含めて引き渡す旨
接続先の情報と認証の設定	基幹システムやSaaSとの接続が切れる	接続先の一覧と、権限の移管手順
運用手順書と障害時の対応記録	何が起きてきたかが分からないまま運用を引き取る	更新の頻度と、引き渡し時点の版
移行の支援	引き渡し後に質問できる相手がいない	支援する期間と、その間の費用

期限と形式まで書くのが要点です。「協力する」とだけ書かれた条項は、いつまでに何を渡すかが決まっていないため、実際の移行では機能しません。外注から内製へ切り替えるときに引き継ぐものの詳細は「外注していたAI開発を内製へ切り替える」で扱っています。

確認の順番

6項目は同時には決まりません。前の項目が決まらないと次が決められない関係にあるため、順番に進めます。

人が確認する工程を決める（誰がどの出力を確定させるか）
検収の基準を決める（判定の単位、合格ライン、判定に使うデータ）
誤った出力が出たときの分担を決める（1と2が前提になる）
権利とデータの条件を決める（自社に残す物を指定する）
保守の範囲と、終了時の引き渡しを決める
発注先へ希望として伝え、条文は法務へ渡す

1から5までは発注部門で決められます。ここまで決めてから法務へ渡すと、確認は条文の形と、抜けている条件の指摘に絞られます。発注の前に自社で固めておく内容は「AIエージェント導入前の確認項目」、依頼書の段階で伝える条件は「AIエージェント開発を外注するときの依頼書の書き方」にまとめています。依頼書に書いた範囲やデータの条件は、そのまま契約書の前提になるため、両者で数値が食い違わないようにします。

まとめ：AI開発の委託契約で、法務へ回す前に決める6項目

契約書のやり取りが長引くのは、発注部門が何を望むかを決めていないことが多い。条文の形は法務が整えられるが、業務の条件は発注部門しか決められない
決めるのは、誤った出力が出たときの責任の分担、成果物とプロンプトの権利、自社データの二次利用と保管、検収の基準、保守の範囲、終了時の引き渡しの6項目
準委任と請負では検収と納品後の直しの扱いが変わる。要件定義と検証は準委任、範囲と合格ラインが固まった実装は請負とする分け方が扱いやすい
責任の分担は、人が確認する工程を決めてから考える。その工程を通った出力の内容は発注側が持ち、仕様どおりに動かない部分は委託先が持つ形が起点になる
権利は成果物をひとまとめにせず分ける。自社の業務に合わせた指示文と判定基準、評価用のデータは自社に残す
データは、利用目的の限定、保管場所の特定、終了時と中止時の削除と報告までを書く
検収は、判定の単位、合格ライン、判定に使うデータの出どころと正解付けの担当、再判定の回数まで決める
終わり方は締結の時点でしか決められない。引き渡す物の一覧に、期限と形式、移行支援の期間を添える

Augueでは、対象業務の切り出しから要件の整理、発注先とのすり合わせ、その後の構築と運用の内製化までを支援しております。契約の前に自社で決めておく条件を洗い出す段階からご一緒できますので、ご興味がある方は是非ご相談ください。

まずは現状をお聞かせください

弊社では具体的な要件が固まっていない段階でも、無料相談で現状をお聞きしていますので、お困りの際はご相談ください。

無料相談を予約する →

よくある質問

発注先から提示されたひな形をそのまま使ってもよいですか？

提示されたひな形は、作る側が引き受けやすい配分で書かれているのが普通です。そのまま押し返す必要はありませんが、自社が譲れないと決めた項目だけは、ひな形のどの条項に当たるかを照らして過不足を確認します。該当する条項が見当たらない項目は、書かれていないだけで合意もされていないため、覚書や別紙として足してもらう形が現実的です。

検証（PoC）と本開発で契約を分けるべきですか？

分ける例が多く、理由は目的が違うためです。検証は成り立つかどうかを確かめる段階なので完成を約束しにくく、本開発は動くものを引き渡す段階です。一本にまとめると、検証で作った試作の扱いと本番の品質基準が同じ条項で語られ、検収でもめる原因になります。分ける場合でも、検証で作った成果物を本開発へ持ち込めるかは先に書いておきます。

損害賠償の上限はどれくらいが相場ですか？

一律の相場は示せません。業務が止まったときに自社で発生する損失の見積もりと、委託金額との関係で決める話だからです。判断の材料になるのは、その業務が止まったときに何日まで手作業で回せるか、回せなくなった場合に一日あたりいくら失うか、代わりの手段へ切り替えるのに何日かかるかの3点です。この数値を先に出すと、上限の妥当性を社内で説明できます。

再委託（下請け）はどこまで認めるべきですか？

全面的に禁じると進まないことが多いため、届け出を条件に認める形が扱いやすくなります。確認するのは、再委託先の範囲、自社データがそこまで渡るかどうか、渡る場合に同じ条件の秘密保持が掛かるか、障害が起きたときの窓口が元の委託先のままかです。情報システム部門の審査でも同じ点が聞かれるので、審査の資料をそのまま使えます。