「見積もりをもらったら請負契約だったが、AIの精度は事前に確約できないと言われた」——生成AI開発の契約でよく起きるすれ違いです。結論から言うと、生成AI開発は仕様が確定しにくい前提を踏まえ、多くの場合「準委任」で始め、仕様が固まった工程だけを「請負」に切り替えるのが実務的です。 一般的なシステム開発と同じ感覚で「成果物を決めて請負契約」を結ぼうとすると、AI特有の不確実性とかみ合わず、PoC止まりや検収トラブルの原因になります。
この記事では、準委任と請負の違い、生成AI開発が請負と相性の悪いことがある理由、検収基準の考え方、契約形態を選ぶ判断軸までを、AI導入を現場で実装・運用まで伴走する FDE（Forward Deployed Engineer／フォワードデプロイドエンジニア） サービスの DeploAI が解説します。依頼先の選び方は生成AI導入支援の選び方、要件定義の進め方は生成AIの要件定義はどう進める？もあわせてご覧ください。
準委任と請負、そもそも何が違う？
請負は「仕事の完成」を目的とする契約、準委任は「業務の遂行」を目的とする契約という違いがあります。 どちらも外部に業務を委託する契約ですが、何を約束しているかが異なります。
| 請負 | 準委任 | |
|---|---|---|
| 契約の目的 | 仕事の完成（成果物の納品） | 業務の遂行（プロセスの実施） |
| 受託者の義務 | 定めた成果物を完成させる義務 | 善良な管理者として業務にあたる義務（成果物の完成そのものは義務ではない） |
| 検収 | 成果物を検収し、合否を判定する | 明確な検収という概念は原則なし |
| 契約不適合が判明した場合 | 修補などの契約不適合責任を負うのが原則 | 原則として契約不適合責任の対象にならない |
| 向いている工程 | 仕様が確定している開発 | 仕様が流動的な構想・PoC・要件定義、運用・改善 |
システム開発の分野では、IPA（情報処理推進機構）が公開する「情報システム・モデル取引・契約書」などでも、要件定義・企画のように仕様が固まっていない上流工程は準委任、仕様が確定した設計・開発工程は請負になじむ、という整理が広く参照されています。生成AI開発でもこの基本の考え方は変わりませんが、AI特有の事情でその線引きがより重要になります。
なぜ生成AI開発は「請負」と相性が悪いことがあるのか？
生成AIは、着手前に「この精度を必ず達成する」と成果物の仕様として確定しにくい性質があるため、請負契約と相性が悪いことがあります。 従来型のシステム開発であれば、機能要件を固めて「この画面・この処理を作る」と成果物を定義できますが、生成AIは同じプロンプト・同じデータでも出力の精度や挙動が実装しながら変わっていくことが珍しくありません。
（準委任）仕様が未確定。検証しながら方向性を決める
（準委任 or 請負）仕様が固まった範囲は請負も選択可。データ・要件が変わりやすい部分は準委任が実務的
（準委任）精度の継続的な評価・改善は「完成」がない業務
AIプロジェクトの進行に合わせて、契約形態も段階ごとに変わる。仕様が固まっていない段階を請負で縛ると、変更のたびに契約の巻き直しが発生しやすい。
仕様が固まっていない段階から請負で契約すると、生成AIの要件定義で扱ったような要件の揺れが起きるたびに、契約変更の手続きが発生します。逆に、仕様がすでに確定している範囲（決まったデータ連携の実装など）は、請負で成果物と検収基準を明確にする方が双方にとって分かりやすいこともあります。「AI開発は準委任一択」ではなく、工程ごとに向き・不向きがある、というのが実務的な整理です。
具体例：仕様確定前に請負で契約してしまうと何が起きるか（仮の例）
架空の例で考えます。ある企業が「問い合わせ対応AIを開発し、正答率90%を達成する」という成果物を仕様として固定し、請負契約を結んだとします。開発を進める中で、想定していなかった問い合わせパターンが多数見つかり、当初のデータ設計では正答率90%に届かないことが分かりました。
この場合、成果物と精度をあらかじめ固定してしまっているため、仕様変更のたびに追加の契約交渉が必要になり、開発が止まりやすくなります。 一方、同じプロジェクトを準委任で始めていれば、「業務の遂行」が契約の目的であるため、精度目標の見直しやデータ設計の変更を、契約を都度巻き直すことなく、当初の業務範囲の中で柔軟に進めやすくなります（もちろん、業務範囲そのものを大きく超える場合は、準委任であっても契約の見直しが必要です）。
AI開発の検収基準はどう設計する？
請負で契約する場合、生成AIの検収基準は「バグがないこと」ではなく、事前に合意できる定量的な評価基準として設計することが重要です。 一般的なソフトウェアの検収は「仕様どおりに動くか」で判定できますが、生成AIの出力は確率的であるため、同じ基準をそのまま当てはめると判定が難しくなります。
- 評価用データセットを事前に固定する：本番運用で想定される入力パターンを代表するテストデータセットを、契約前に双方で合意しておく。
- 精度・応答基準を数値で定義する：「正答率◯%以上」「応答時間◯秒以内」など、判定できる基準を個別契約に明記する。
- 合否の判定方法と期限を定める：検収の実施方法（誰が、どのデータで、いつまでに判定するか）を曖昧にしない。
これらを曖昧にしたまま請負契約を結ぶと、検収の合否をめぐって双方の認識がずれ、AI導入がPoC止まりになる理由で扱ったような停滞につながります。逆に、これらを最初から明確にできるのは、多くの場合すでにPoCなどを通じて仕様が固まっている段階です。
契約形態を選ぶときの判断軸
契約形態で迷ったときは、次の項目を確認すると整理しやすくなります。
- 実現したい機能・精度の仕様は、すでに確定していますか？（確定していない → 準委任が実務的）
- 評価用データセットと、判定できる検収基準を用意できますか？（用意できない → 請負での検収は難しい）
- プロジェクトの目的は「特定の成果物を完成させること」ですか、「継続的に業務を遂行すること」ですか？
- 要件が今後も変わる可能性がありますか？（変わりやすい → 準委任で柔軟性を確保）
FDEはどのように契約を設計しているか
DeploAI の FDE（Forward Deployed Engineer）では、個別契約に定めがない場合は準委任を基本とし、仕様が確定した開発業務については、契約でその旨・成果物・検収基準を定めたうえで請負とすることも可能です。加えて、DeploAI の開発フレームなど既存資産を提供する場合は、利用許諾（ライセンス）という形態も別途用意しています。お申し込み時には、この3つ（ライセンス／準委任／請負）から契約形態を選んでいただき、契約形態が未定の場合は、まず準委任として開始し、内容確認のうえで調整します。
請負とする場合の検収は、成果物の納入後10営業日以内に検査・合否を通知いただく流れとし、契約不適合が判明した場合は検収合格後3か月以内のご通知で修補対応します（この契約不適合責任は、性質上、準委任には適用しません）。仕様が固まっていない構想・PoCの段階から、仕様確定後の実装、そして運用・改善まで、段階的に投資を広げる進め方と合わせて、工程ごとに適した契約形態で伴走できる設計にしています。詳しい契約条件は利用規約、料金体系は料金ページをご覧ください。
まとめ
- 請負は「仕事の完成」を目的とする契約、準委任は「業務の遂行」を目的とする契約という違いがある。
- 生成AI開発は仕様・精度を事前に確定しにくいため、多くの場合は準委任で始め、仕様が固まった工程だけを請負に切り替えるのが実務的。
- 請負で契約する場合、検収基準は評価用データセットと数値基準を事前に合意しておくことが欠かせない。
- 契約形態は「仕様が確定しているか」「検収基準を用意できるか」「業務の目的は完成か継続か」で判断する。
生成AI開発の契約形態の選び方、検収基準の設計に不安がある場合は、無料相談からお気軽にご相談ください。関連記事：生成AI導入支援の選び方／生成AIの要件定義はどう進める？／生成AI導入の費用はどう考える？。
