AIエージェント開発の業務委託契約｜精度保証・モデル更新に備える条項と発注判断

「AIエージェントで問い合わせ対応を自動化せよ」「社内業務をAIで効率化せよ」。経営層からこうした指示を受けて開発会社を探し始めると、多くの発注担当者がある段階で手が止まります。開発会社から届いた契約書ドラフトに「精度保証なし」「モデル変更時は別途協議」「再委託あり」といった見慣れない条項が並んでいて、何にサインしようとしているのか判断できなくなるのです。

無理もありません。従来のスクラッチ開発であれば、要件を固めて請負契約を結び、仕様どおりに完成したものを検収すれば話は済みました。ところがAIエージェント開発では、出力が確率的で「100点の完成」を定義しづらく、しかも土台となる基盤モデル（その時点で最先端＝SoTA）が数ヶ月単位で入れ替わります。従来の発注経験がそのまま通用しないため、何から契約に落とし込めばよいか分からなくなります。

この迷いの正体は、契約の知識不足ではなく「AIエージェント開発という対象が、従来のシステム開発と何が違うのか」が整理できていないことにあります。違いさえ押さえれば、請負と準委任のどちらを選ぶか、精度をどう握るか、モデルが変わったときどうするかは、論理的に決められます。

本記事では、AIエージェント開発を業務委託で発注する際の契約設計を、発注者の判断基準という観点から整理します。請負と準委任の選び方、精度保証ができない前提での握り方、基盤モデルの更新やLLM API費用の改定に備える条項、知的財産・データの守り方、そして社内稟議と交渉でそのまま使える発注前チェックリストまでを順に解説します。読み終えたときには、自社のケースで「どのタイプの契約を、どんな条項で結ぶか」を言語化できる状態を目指します。

AIエージェント開発の業務委託契約が「従来のシステム開発」と違う理由

最初に押さえておきたいのは、AIエージェント開発を従来の請負契約の感覚でそのまま発注すると危険だ、という点です。なぜ危険なのかを理解するには、そもそも何を委託しているのか、そしてそれが契約のどこに効いてくるのかを分けて考える必要があります。

そもそもAIエージェント開発とは何を委託することなのか

AIエージェントとは、大まかにいえば「LLM（大規模言語モデル）を頭脳として、与えられた目的を達成するために自分で判断し、外部のツールやデータベースを使いながらタスクを進めるソフトウェア」です。問い合わせ対応エージェントであれば、ユーザーの質問を理解し、社内ナレッジを検索し、必要なら基幹システムを参照して、回答を生成する、といった一連の流れを担います。

ここで委託する作業を分解すると、従来のシステム開発との違いが見えてきます。AIエージェント開発で発注会社が手がけるのは、おおむね次のような要素の組み合わせです。

• LLMの選定と接続: どの基盤モデル（OpenAI、Anthropic、Googleなど）を、どのAPIで使うか
• プロンプト設計: エージェントに役割や手順を指示する文章の設計・調整
• ツール連携・ワークフロー定義: 検索・社内システム呼び出し・データ取得などの組み込み
• 評価と改善: 出力の良し悪しを測る評価データセットの整備と、継続的なチューニング

従来のシステム開発が「仕様書どおりに動く機能を実装する」作業中心だったのに対し、AIエージェント開発では、確率的に振る舞うLLMをいかに目的どおりに動かすかという調整・評価の比重が大きくなります。完成形を最初に固めきれず、作りながら精度を上げていく性質が強いのが特徴です。

契約設計に効く3つの特殊性

この性質の違いは、契約設計に具体的な形で効いてきます。発注者が押さえるべき特殊性は、次の3つに整理できます。

1. 精度を「完成」として保証できない

LLMの出力は確率的で、同じ入力でも揺らぎが生じます。「問い合わせの95%に正答する」と契約で完成義務として保証することは、技術的に困難です。従来の請負契約は「仕事の完成」を前提にしますが、AIエージェントの精度はこの完成の枠に収まりにくいのです。ここを理解せず「正答率100%を保証してほしい」と求めても、まともな開発会社は引き受けられません。

2. 基盤モデル（SoTA）の変化で成果物が陳腐化する

AIエージェントの土台となる基盤モデルは、数ヶ月単位で新世代が登場します。半年前に最適だったモデルやプロンプト設計が、新モデルの登場で見劣りしたり、旧モデルの提供終了で作り直しが必要になったりします。一度作って終わりではなく、変化に追従し続ける前提で契約を考える必要があります。

3. LLM APIという外部依存があり、費用も仕様も当事者がコントロールできない

多くのAIエージェントは、外部企業が提供するLLM APIを利用料を払って使います。この利用料（処理量に応じた従量課金）は基盤モデル提供者が価格を改定でき、発注者も開発会社もコントロールできません。さらにAPIの仕様変更やモデルの提供終了も外部の都合で起こります。「自社と開発会社の二者だけでは閉じない契約」になる点が、従来のオンプレミス開発と大きく異なります。

この3点が、後述する「請負か準委任か」「精度をどう握るか」「モデル更新・API費用の条項」といった具体的な論点すべての出発点になります。逆にいえば、この3つの前提を契約に織り込めるかどうかが、発注者が自社を守れるかの分かれ目です。

請負契約と準委任契約、AIエージェント開発ではどちらを選ぶか

業務委託契約は法律上の単一の契約類型ではなく、主に「請負契約」と「準委任契約」に分かれます。AIエージェント開発でどちらを選ぶかは、契約設計の最初の分岐点です。

請負と準委任の違いを発注者目線で整理する

両者の違いを、発注者が気にすべき観点で比較すると次のようになります。

経済産業省が2025年2月に公表した「AIの利用・開発に関する契約チェックリスト」でも、開発を伴う契約について「準委任契約か請負契約かを明確にする必要がある」とし、準委任は委任事務の遂行が目的でベンダは善管注意義務を負うのみであるのに対し、請負は仕事の完成を目的とし完成しない限り義務を履行したことにならない、と整理しています（経済産業省「AIの利用・開発に関する契約チェックリスト」令和7年2月）。請負と準委任の選び方については、特許庁IP BASEも公的な解説を提供しています（特許庁 IP BASE「AI開発を受託する際の契約方式の選び方」）。

ここで発注者が誤解しやすいのが「完成義務を負わせる請負のほうが発注者に有利だ」という思い込みです。たしかに成果物がはっきり定義できる開発なら請負が安心です。しかし、前章で見たとおりAIエージェントの精度は完成として定義しづらいため、無理に請負で「精度の完成」を約束させようとすると、開発会社が受注を断るか、リスク分を上乗せした高い見積もりになるか、形式的に契約だけ結んで実態が伴わないか、のいずれかになりがちです。

AIエージェント開発でのフェーズ別契約タイプ選択

現実的な解は「全部を請負か準委任のどちらかに寄せる」のではなく、開発のフェーズと成果物の確実性に応じて使い分けることです。AIエージェント開発を次の3フェーズに分けて考えると整理しやすくなります。

フェーズ1: PoC（実証実験）→ 準委任が向く

「そもそも自社の業務でAIエージェントが使いものになるか」を検証する段階です。この時点では精度も実現可能性も未知数で、成果を完成として約束できません。準委任契約で「一定期間・一定工数で検証を行い、結果をレポートする」と握るのが現実的です。ここで請負にしてしまうと、検証の結果「期待した精度に届かない」と分かったときに「完成していないので報酬を払わない」といった不毛な争いになりかねません。

フェーズ2: 要件が固まった機能開発 → 請負＋成果物定義が向く

PoCで方向性が見え、「この入力にはこう応答する」「この画面・APIを作る」といった、AIの精度に依存しない明確な成果物が定義できる部分です。エージェントを動かすための管理画面、ログ基盤、外部システム連携の実装などがこれにあたります。こうした定義可能な部分は請負で完成義務を負わせ、成果物を具体的に列挙して検収基準を決めておくと、発注者の安心につながります。

フェーズ3: 継続的な精度改善・運用 → 準委任（ラボ型）が向く

リリース後も評価データを見ながらプロンプトを調整し、モデル更新に追従し続ける段階です。終わりが定義できない継続業務なので、月額・工数ベースの準委任（ラボ型・準委任の継続契約）が適します。

つまり「PoCは準委任、定義できる機能は請負、継続改善は準委任」という混合設計が、多くのAIエージェント開発で現実的な落としどころになります。一本の契約にまとめるのではなく、フェーズごとに契約タイプと範囲を切り分けることが、発注者がリスクをコントロールする第一歩です。請負・準委任の基本的な選び方や、発注前に合意しておくべき成果物・検収の考え方は、業務委託エンジニアの契約形態の選び方もあわせて押さえておくと、AIエージェントに限らない発注全般に応用できます。

SoTA変化に備える契約条項の設計

ここからが本記事の核心です。基盤モデルの更新、API価格の改定、精度のゆらぎといった「変化する前提」に、どの条項で備えるかを具体的に見ていきます。冒頭で不安に感じた「精度保証なし」「モデル変更時は別途協議」といった文言の意味と、発注者として自社に有利な握り方を整理します。

精度は「保証」でなく「評価指標と受入基準」で握る

開発会社の契約書に「精度・性能を保証しない」と書かれていると、発注者は「では何の保証もなく払うのか」と不安になります。しかし、精度を完成義務として保証できないのは、開発会社の怠慢ではなく、確率的に振る舞うLLMの本質的な性質によるものです。経済産業省のチェックリストでも、AI生成物の性質上、提供者が一定の品質や正確性を保証することが難しい点が前提として整理されています。

ここで発注者が取るべきは「保証を求める」のではなく「測れる形で握る」アプローチです。具体的には、契約書または仕様書に次の要素を盛り込みます。

• 評価データセット: どんな入力サンプルで精度を測るかをあらかじめ定義する（例: 過去の問い合わせ100件）
• 合格ライン（受入基準）: そのデータセットに対し「正答率○%以上」「重大な誤回答ゼロ」といった検収の判断基準を決める
• 測定方法と判定者: 誰が・どの手順で評価するか（発注者側の業務担当が確認する等）を明記する
• 運用後の改善義務: リリース後に基準を下回った場合、どの範囲で改善対応を行うかを準委任の運用契約に書く

このように「保証」ではなく「合意した評価データセットに対する受入基準のクリア」という形にすれば、開発会社も引き受けられ、発注者も「何をもって支払うか」が明確になります。精度を100%約束させることはできなくても、「自社が困らない最低ラインをどう確認するか」は契約で握れるのです。

モデル更新・切替に対応する条項

基盤モデルが新世代に切り替わったり、利用中のモデルが提供終了になったりするのは、AIエージェント運用では「いつか必ず起きること」です。契約書の「モデル変更時は別途協議」という一文を、発注者に不利な空白のまま放置すると、いざ変更が必要になったときに追加費用や対応範囲で揉めます。発注前に次の点を取り決めておくと、変化に振り回されにくくなります。

• 再評価のトリガー: モデルを変更・更新する際に、前述の評価データセットで再評価することを義務づける（変更後に精度が落ちていないかを確認する仕組み）
• 追加費用の分担ルール: モデル切替に伴う調整作業を、運用契約の工数内で行うのか、別途見積もりとするのかをあらかじめ決める。「別途協議」のままにせず、判断基準（軽微な調整は工数内、大規模な作り直しは別途等）を言語化する
• 協議の枠組みと期限: どちらが・いつまでに・何を提示して協議するかの手順を定める

ポイントは、変化そのものを契約で止めることはできないので、「変化が起きたときの対応手順とコスト負担をあらかじめ決めておく」という発想に切り替えることです。

LLM API費用の条項設計

外部のLLM APIを使う以上、その利用料は基盤モデル提供者の価格改定や利用量の増減で変動します。この費用をめぐる不安が「青天井のコスト」への懸念です。次の論点を契約で押さえておきます。

• 費用負担の主体: LLM API利用料を発注者が直接負担するのか、開発会社が立て替えて請求するのかを明確にする。発注者が自社のAPIアカウントを用意し直接契約すれば、利用量も価格も自社で把握できます
• 月次上限と通知義務: 想定利用量から月額の上限目安を設定し、それに近づいた・超えそうな場合は開発会社が通知する義務を課す。利用が急増したときに「気づいたら高額請求」を防ぎます
• 価格改定時の取扱い: 基盤モデル提供者が価格を改定した場合、誰がそのコスト変動を負担するか、また再見積もりの手順を定める
• マルチモデル前提でベンダーロックを避ける: 特定の1モデルにエージェントを密結合させず、モデルを差し替えられる設計（モデルの抽象化）を成果物の要件に含める。これにより、あるモデルが大幅値上げや提供終了になっても、より安価・高性能な別モデルへ乗り換えられます

特に4点目のマルチモデル前提の設計は、コスト面だけでなく、SoTAの変化に強い構成を作る上でも重要です。「今いちばん良いモデル」に固定するのではなく「いつでも乗り換えられる」状態を契約段階で要件化しておくと、将来の価格改定やモデル交代に振り回されにくくなります。

知的財産・成果物・セキュリティで発注者が押さえる条項

精度やコストと並んで、発注者が見落としやすいのが知的財産・成果物の引き渡し・データの取扱いです。ここを曖昧にすると、開発会社を乗り換えたいときに成果物が手元に残らない、あるいは自社の機密情報が外部に流出する、といった問題が後から表面化します。

プロンプト・ワークフローの権利帰属と成果物の引き渡し範囲

AIエージェント開発では、ソースコードに加えて「プロンプト設計」「ワークフロー定義」「評価データセット」といった、従来のシステム開発にはなかった成果物が生まれます。これらの権利帰属と引き渡し範囲を契約で決めておく必要があります。

• プロンプト・ワークフローの権利帰属: エージェントの中核となるプロンプトやワークフローの定義を、発注者が利用・改変できる権利を確保する。開発会社が汎用的に使うノウハウ部分との線引きは交渉ポイントになりますが、少なくとも自社業務に固有の設計は自社で使い続けられる形にしておきます
• 学習データ・チューニング成果物の取扱い: ファインチューニングや独自データの整備を行った場合、その成果物（学習済みの設定や整備済みデータ）が誰のものかを明記する
• ソースコード・設定の引き渡しと可搬性: ソースコード、設定ファイル、構成情報を発注者に引き渡し、別のベンダーでも動かせる状態にしておく。これがないと、開発会社を変えたくても変えられない「ベンダーロック」に陥ります

撤退や乗り換えのときに「成果物が手元に残るか」は、発注者にとって最後の防御線です。順調なうちは意識しにくい論点ですが、契約段階で引き渡し範囲を具体的に列挙しておくことが大切です。

入力データ・秘密情報の取扱いと第三者LLMへの送信ルール

AIエージェントは、業務で扱うデータ（顧客情報・社内文書など）を入力としてLLMに渡します。このデータが外部のLLM提供者にどう扱われるかは、発注者が必ず確認すべき点です。

• 第三者LLMへの送信と学習利用の禁止: 入力データが外部のLLM APIに送信される範囲を把握し、そのデータを基盤モデル提供者の学習に使わせない設定・契約になっているかを確認する。多くの法人向けLLM APIは入力データを学習に使わないオプションを提供していますが、契約・設定で明示的に担保しておく必要があります
• 秘密保持と再委託時の取扱い: 秘密保持義務の範囲を定め、開発会社が業務を再委託する場合でも同等の守秘義務が及ぶようにする。再委託先の特定・承諾・責任分担を契約でどう定めるかは、業務委託の再委託条項を正しく設計する方法も参考になります
• データの保存・削除: 入力データやログがどこに・どれだけの期間保存され、契約終了時に削除されるかを取り決める

自社のデータがどこを通り、どう扱われるかを発注前に確認しておくことは、情報漏えいリスクから自社を守る基本です。外部に業務を委託する際の情報漏洩の典型パターンと対策は業務委託の情報漏洩リスクと対策で整理しているので、あわせて確認しておくとよいでしょう。開発会社に「データはどのLLMに、どんな設定で送られるのか」を具体的に質問し、回答を契約・仕様に落とし込みましょう。

発注前チェックリストと契約設計の進め方

ここまでの論点を、社内稟議と開発会社との交渉でそのまま使える形に落とし込みます。最後に、発注前のチェックリスト、開発会社に確認すべき質問、そして進め方を整理します。

発注前チェックリスト

AIエージェント開発を業務委託する前に、次の項目を自社で確認・決定しておきます。社内稟議の資料にも転用できます。

開発会社に確認すべき質問と発注の進め方

チェックリストを埋めるために、開発会社へは次のような質問を投げかけると、各社の実力と姿勢が見えてきます。

• 精度はどの評価データセット・どの基準で確認し、どこまで改善対応してもらえるのか
• 使用する基盤モデルは何か、別モデルへ差し替えられる設計になっているか
• LLM API利用料はどちらが負担し、想定月額と上限通知の仕組みはあるか
• ソースコード・プロンプト・設定は引き渡してもらえるか、他社でも運用できるか
• 入力データは外部LLMにどう送られ、学習に使われない設定になっているか
• 見積もりの根拠（工数・API費用・運用費の内訳）を提示してもらえるか

進め方としては、最初から大きな本番契約を一本で結ぶのではなく、PoCを準委任で小さく握り、検証結果を見てから本番開発・運用の契約を分けて結ぶ段階的な進め方が安全です。PoCで「自社の業務で本当に使えるか」「どの精度なら業務に乗るか」を確かめてから本番に進めば、完成しないリスクも、想定外のコストも、早い段階で見極められます。

最後に、業務委託である以上の基本的な注意点として、運用フェーズで開発会社の担当者に直接細かい指示を出し続けると「偽装請負」と判断されるおそれがあります。偽装請負とは、契約形式は業務委託でも実態が労働者派遣に近い状態を指し、発注者が直接の指揮命令や勤怠管理を行うことが典型例とされています（厚生労働省 東京労働局「偽装請負について」）。AIエージェントの継続改善のように発注者と開発会社が密に連携する場面では、指示の出し方が業務の依頼の範囲にとどまっているかに注意が必要です。具体的にどこからが偽装請負にあたるか、指揮命令の線引きは偽装請負を防ぐ指揮命令ルールで詳しく整理しているので、運用契約を結ぶ前に確認しておくと安心です。誰がどう作業を進めるかの判断は受託者側に委ねる運用を心がけましょう。

ここまでの論点を自社のケースに当てはめれば、「PoCは準委任で検証し、精度は評価データセットの受入基準で握る」「モデル更新とAPI費用の条項を入れ、マルチモデル前提でロックインを避ける」「成果物の引き渡しとデータの取扱いを明記する」といった発注方針を、自分の言葉で言語化できるはずです。その方針を社内稟議と開発会社との交渉の土台にすれば、変化の速いAIエージェント開発でも、自社を守りながら着実に発注を進められます。