準委任契約と請負契約の違い｜AI開発で選ぶ基準

AI開発の契約設計は、請負契約と準委任契約の違いを押さえるところから始まります。
請負は仕事の完成に報酬を払う契約で、完成責任と契約不適合責任が発生するのに対し、準委任は業務の遂行に報酬を払う契約で、受注者は善管注意義務を負うものの完成責任は負いません。
IT人材のマッチングやSESの実務を見ていると、この成果責任の有無を曖昧にしたまま進めた案件ほど、発注後の認識違いが大きくなりやすいものです。
さらにAIは学習データの量と質に精度が左右され、生成AIや深層学習の性質上、完成や性能を事前に約束しづらいため、実務では準委任を起点に考えるのが自然だといえます。

結論：工程別おすすめ早見表と1分でわかる選び方

AI開発の契約は、最初から一つに固定しないほうが設計しやすいです。
PoC・検証段階は準委任、本開発は請負または成果完成型準委任、運用保守は再び準委任へ切り替える流れが、実務ではいちばん整理しやすい組み立てになります。
請負は仕事の完成に対して報酬を払う契約、準委任は業務の遂行に対して報酬を払う契約で、完成責任を負うか、過程の遂行に責任を負うかが分岐点です。
年間多数のエンジニアマッチングを手がけた現場でも、ここを曖昧にしたまま着手すると、完成しないのに報酬を請求されたり、仕様変更のたびに揉めたりしやすくなります。

目的別おすすめ早見表：こんな企業はこの契約

PoC・検証段階を始めたい企業は、まず準委任（履行割合型）を選ぶのが自然です。
まだ要件が揺れている段階で完成責任まで背負わせると、ベンダー側が守りに入りやすく、試行錯誤の速度が落ちます。
仕様が固まった本開発を発注したい企業は、請負か成果完成型準委任を検討するとよく、完成物の線引きを明確にしたいなら請負が向いています。
運用しながら継続改善したい企業は、業務の遂行に対して報酬を払う準委任が適しています。

現場では、発注者から相談を受けたときにまず工程分解から入ります。
AI開発は、学習データの整備、モデル選定、評価、実装、運用改善が一続きに見えても、契約上の性質は同じではありません。
工程を分けて考えるだけで、どこまでが探索で、どこからが完成責任なのかが見えます。
おすすめです。

準委任 vs 請負 5項目比較表

準委任と請負の違いは、同じ「業務委託」に見えても、報酬が何に対して発生するかで決まります。
請負は仕事の完成に対価を払う契約で、完成しなければ原則として報酬は発生しません。
準委任は業務の遂行に対価を払う契約で、民法644条の善管注意義務を尽くしていれば、完成まで到達しなくても報酬設計がしやすい構造です。
2020年4月の民法改正で準委任は履行割合型と成果完成型に整理され、AI開発のように途中経過の価値が大きい案件では、この切り分けが効いてきます。

この表で見たいのは、どちらが優れているかではなく、どこに責任を置くかです。
AI開発では、学習データの質や未知データへの推論精度が先に読めないため、完成保証を強く置きすぎると、受注側に過重な義務が乗ります。
折衷案として成果完成型準委任を置く発想もありますが、それでも本質は「完成に責任を負うのか、過程に責任を負うのか」にあります。
そこを外さないようにしましょう。

迷ったらまず工程を分けて考える

AI開発では、1つの契約で全工程をまとめ切るより、PoC、本開発、運用保守の3区分で切り替えるのが定石です。
探索的段階型の考え方に沿えば、アセスメント・PoCは準委任、本開発は請負または成果完成型準委任、運用保守や追加学習は準委任という並べ方が最も整合的です。
経産省モデルでもこの分け方が推奨されており、工程ごとに契約の性格を変えるほうが、責任と報酬の対応関係を崩しにくくなります。

実務上は、この切り分けがトラブル予防に直結します。
契約形態を曖昧にしたまま走り出すと、仕様変更のたびに「それは追加なのか、最初から含むのか」で止まりやすく、発注者も受注者も消耗します。
まず工程を分解し、その工程に合う契約を当てる。
これが契約選びの第一歩であり、AI開発を無理なく前に進めるための基本線です。
おすすめします。

請負契約とは：成果物の完成に責任を負う契約

請負契約は、仕事の完成そのものに報酬が結びつく契約です。
民法632条が定める通り、受注者は成果物を完成させる義務を負い、発注者はその結果に対して代金を支払います。
つまり、作業をしたことではなく、合意した成果を出したことが報酬発生の条件になるのです。

そのため、請負では完成責任が強く働きます。
納品前に終わっていないなら原則として報酬は発生しにくく、完成後には品質や数量の不備まで問われます。
発注者にとっては成果物の納品を法的に確保しやすい契約形態ですが、要件が曖昧な案件では負担の重さが目立ちます。

請負の定義と『完成』が報酬の条件になる仕組み

請負は民法632条で『当事者の一方が仕事の完成を約し、相手方がその結果に対して報酬を支払う』と定義されます。
ここでの核心は、労働時間や作業量ではなく、最終的に約束した仕事が完成しているかどうかに報酬が紐づく点です。
受注者は「途中まで進めた」だけでは足りず、完成という結果まで到達して初めて対価を請求できる構造になります。

この仕組みは、発注者にとってはわかりやすい安心材料です。
仕様どおりの成果物を受け取る前提が置かれるため、どこまでやったかの管理よりも、何が納品されるのかが重視されます。
標準的な成功パターンとしては、仕様書が詳細に固まった案件で請負を選び、品質基準や検収条件を契約段階で明文化しておく進め方が挙げられます。
そこまで詰めておけば、検収時の認識ずれが起きにくく、発注者も受注者も判断しやすくなるでしょう。

契約不適合責任とは何か

請負で完成した成果物に品質や数量の不備があれば、契約不適合責任が問題になります。
旧・瑕疵担保責任にあたる考え方で、納品物が契約内容に適合していない場合、受注者は修補、代金減額、損害賠償、契約解除といった責任を負います。
完成しただけでは足りず、契約で約束した水準に達しているかまで追及される点が、発注者側の保護につながっています。

発注者にとってこの制度が重要なのは、納品後の品質を法的に問えるからです。
たとえば数量不足や仕様違反が見つかった場合でも、単なる道義的なやり直し依頼にとどまらず、契約上の手当てとして修補や減額を求められます。
完成責任と契約不適合責任が組み合わさることで、請負は「作って終わり」ではなく「約束した成果を満たして終わる」契約になるわけです。

発注者から見たメリットとデメリット

発注者視点で見ると、請負のメリットは成果物を確実に受け取りやすいことです。
完成が報酬条件なので、受注者は納品まで責任を持って進める必要があり、仕様が固まっている案件では管理しやすくなります。
ウォーターフォール型開発と相性が良いのもこのためで、工程と成果物の区切りが明確なほど請負の強みが生きます。
実務ではおすすめの選び方です。

ただし、デメリットもはっきりしています。
開発途中で仕様変更が頻発すると、当初合意した完成物の前提が崩れ、見積もりと実態が乖離しやすくなります。
要件が曖昧なまま請負契約を結んだ案件では、途中で修正が積み重なって契約変更の調整に追われる失敗が起きがちです。
発注者から見れば柔軟に変えたい場面ほど硬直的で、契約の修正そのものが追加コストになります。

要件が固まっているなら請負はおすすめです。
品質基準を先に詰め、検収条件まで決めておけば、発注者にとっても受注者にとっても進め方が明快になります。
反対に、まだ仕様が動きそうなら、途中で契約を見直す前提を持って進めましょう。
そこを外すと、完成責任の重さだけが前面に出てしまうのです。

準委任契約とは：業務の遂行に責任を負う契約

準委任契約は、民法656条にもとづいて、法律行為ではない事務の処理を委ねる契約です。
受注者が負うのは成果物を完成させる責任ではなく、民法644条の善管注意義務に従って、専門家として期待される注意を尽くしながら業務を進める責任になります。
だからこそ、AI開発のように見通しが揺れやすい案件でも使いやすく、発注者側も「完成」より「適切な遂行」を前提に設計しやすい形です。
もっとも、成果未達でも報酬が発生しうるため、契約の切り分けは丁寧に考える必要があります。

準委任の定義と善管注意義務

準委任は、法律行為でない事務を任せるときに使う契約類型で、民法656条が委任の規定を準用しています。
ここで押さえるべきなのは、受任者が約束するのは「完成」ではなく、業務を専門家として適切に処理することだという点です。
民法644条の善管注意義務は、単なる作業者ではなく、知識と経験を前提に注意深く動くことを求めるルールであり、発注者にとっては品質の最低ラインを支える基準になります。

実務では、この違いが契約の考え方を大きく変えます。
請負なら成果物の完成が中心ですが、準委任では発注者が期待するのは、要件整理、調査、PoC、保守運用のような「進め方そのもの」です。
要件が固まりきらないPoC案件で履行割合型の準委任を選ぶと、稼働工数ベースで仮説検証を回しやすくなります。
AI開発では特に、最初から完成物を固定しにくいため、この柔軟さが使いやすい一方、曖昧なまま進めると「どこまでやれば十分か」がぶれやすいので、業務範囲の整理が欠かせません。

履行割合型：工数に対して報酬を払う

2020年4月の民法改正で、準委任の報酬設計は「履行割合型」と「成果完成型」の2類型に整理されました。
履行割合型は、稼働時間や作業量といった工数に応じて報酬を支払う考え方です。
データ入力や調査のように、やった仕事の量を比較的追いやすい業務と相性がよく、AI開発でも要件定義前の検証やデータ整備、モデル比較のような工程に向いています。

この形の利点は、成果がまだ読めない段階でも前進を止めにくいことです。
実際、検証対象が変わるPoCでは、月ごとの稼働を見ながら方向修正できるため、発注側は無理に完成像を先に固定しなくて済みます。
ただし、報酬が工数連動である以上、発注者は「何時間働いたか」だけでなく、「その稼働が何の目的に使われたか」まで見ておかないと、費用対効果が見えにくくなります。
中途終了時の報酬請求もここで問題になりやすく、履行した割合に応じて支払う整理を契約で明確にしておくと、終了時の精算がぶれにくくなります。

成果完成型：成果の引き渡しを条件にする

成果完成型は、成果の引き渡しを報酬支払の条件にする類型です。
もっとも、ここでいう成果は「完成責任を負う」という意味ではありません。
請負のように完成そのものを法的に保証するわけではなく、あくまで引き渡しを区切りに報酬を定める点が特徴です。
そのため、準委任の柔軟さを残しながら、発注者側には一定の区切りを作れる折衷案として使われやすい類型だといえます。

AI開発では、プロトタイプ、分析レポート、学習済みモデルの納品など、成果物の形を置きつつも完成責任は強く求めたくない場面で選ばれがちです。
このとき注意したいのは、「どこまでが成果の引き渡しか」を契約で具体化しておかないと、完成責任を負わないはずなのに事実上の完成を求められて揉めやすいことです。
受領基準、検収方法、修正回数、引き渡し物の定義を先に言語化しておくほど、後からの解釈差は小さくなります。
中途で契約が終わる場合も、どの引き渡し段階まで到達したかを基準に、報酬の扱いを整理しておくと混乱しにくいでしょう。

両者の決定的な違い：成果責任・報酬・契約不適合責任の3軸

請負と準委任の違いは、単なる契約名の違いではなく、完成責任・報酬発生の条件・不備があったときの責任という3軸で見分けるのが基本です。
発注者側から見ると、成果が出なかったときに報酬を払うのか、どこまでやり直しを求められるのかが変わるため、実務上のリスクはこの3軸でほぼ決まります。
さらに、中途終了時の精算方法と仕様変更への追随しやすさまで含めて整理すると、契約の使い分けが一気に見えやすくなるでしょう。

軸①成果物の完成に責任を負うか

請負は、成果物を完成させる責任を負う契約です。
完成しなければ原則として報酬も発生せず、発注者にとっては「成果が出なかったのに支払うのか」という判断を避けやすい構造になります。
実際、発注者から「成果が出なかったのに報酬を請求された」と相談を受けた場面では、契約が準委任だったため完成責任を問えず、契約類型の違いがそのまま請求可否を分ける典型例になりました。

準委任は、適切に業務を遂行すれば報酬が発生し、完成そのものは約束しません。
だからこそ、調査、助言、運用支援、開発の一部工程のように、結果だけではなくプロセスの遂行自体に価値がある業務で使われやすいのです。
発注者にとっては、完成保証を求めるなら請負、一定の作業遂行を重視するなら準委任、という切り分けを外さないことが肝心です。

軸②報酬はいつ・何に対して発生するか

報酬の発生条件も、両者で考え方が異なります。
請負は成果物の完成が基準になり、納品して初めて対価を請求する発想です。
これに対して、準委任の履行割合型は工数や稼働時間に応じて報酬が発生し、成果完成型は成果の引き渡しを条件にするため、同じ準委任でも報酬のタイミングが揃いません。
ここを混同すると、発注側は「まだ成果がないから払えない」と考え、受託側は「作業は終えているから請求できる」と考える食い違いが起きます。

準委任の履行割合型では、途中で契約が終わっても既履行分に応じて報酬請求が可能です。
これが、長期の運用支援や仕様が動きやすい案件で選ばれやすい理由でもあります。
仕様変更にも柔軟に対応しやすく、追加作業が発生したときも契約を組み替えやすいからです。
もっとも、請負は変更のたびに契約変更が必要になりやすく、工程と責任範囲を厳密に固めたい案件では、その硬さがむしろ管理しやすさにつながります。

軸③不備があったとき誰がどう責任を負うか

不備が出たときの責任追及は、請負のほうが明確です。
請負では契約不適合責任を問えるため、修補、代金減額、損害賠償といった手段で不備への対応を求めやすくなります。
準委任には契約不適合責任がなく、代わりに善管注意義務違反を問う形になるため、単に結果が悪かっただけでは足りず、どの注意義務に反したのかを立証する必要があります。
実務ではここが重く、請負案件で納品物の不備を契約不適合責任にもとづいて修補請求できたのに、準委任案件では善管注意義務違反の立証に苦労した、という差がそのまま表れます。

この違いは、責任の重さだけでなく、証拠の残し方にも影響します。
請負では成果物を基準に検査しやすいのに対し、準委任では作業過程、指示内容、報告の粒度まで見ていく必要があるため、発注者側も管理の設計を変えなければなりません。
つまり、同じ「外部に仕事を出す」でも、完成責任を取りたいのか、遂行状況を重視したいのかで、責任追及のしやすさは大きく変わるのです。

なぜAI開発は準委任が基本なのか：精度を保証できない構造

AI開発では、学習データから規則を見つけて答えを導く以上、未知の入力に対してどこまで当たるかを契約前に言い切るのが難しいです。
とくに生成AIや深層学習は確率的に出力するため、同じ入力でも結果がぶれることがあり、完成形や性能値を硬く約束する設計と相性がよくありません。
この性質が、請負ではなく準委任を基本に考える出発点になります。

AIの精度は学習データ依存で事前保証が難しい

AIソフトウェアは、あらかじめ書かれたルールをそのまま実行するのではなく、学習用データから帰納的にパターンを獲得して振る舞います。
だからこそ、精度は学習データの量と質に強く左右されます。
十分なデータがそろっていても、将来遭遇する未知の事象まで同じ水準で推論できるとは限りません。
契約の現場でこの点が効いてくるのは、ベンダーが「何を作るか」だけでなく「どこまで当たるか」まで背負えるのか、という論点に直結するからです。

生成AIや深層学習では、同じ入力でも毎回まったく同じ出力になるとは限りません。
これは欠陥というより、確率的に出力を選ぶ仕組みそのものに由来します。
したがって、通常のシステム開発のように完成物の形を先に固定し、納品時点で性能を断定するやり方をそのまま当てはめると、現実と契約がずれやすいのです。
実務では、発注者が当初は請負を希望しても、ベンダーが精度保証の難しさを説明し、準委任に落ち着く流れが珍しくありません。

請負だとベンダーが過重な義務を負うリスク

請負契約は、完成責任と契約不適合責任を前提に組み立てられます。
ところがAI案件では、学習後のデータ追加や運用条件の変化で性能が動くため、「完成」を一義的に定めにくい場面が多いです。
ここで請負を強く求めると、ベンダーは自分で制御しきれない要素まで負担することになりかねません。
性能保証を明記すればするほど、評価不能な失敗まで責任化されるおそれがあるため、ベンダーが難色を示すのは自然だと言えるでしょう。

実際の交渉でも、発注者が「精度◯%以上」を先に置こうとしても、その数字をどう測るか、どのデータで測るか、どの期間で測るかが決まらなければ合意は空回りします。
そこで、硬い保証を並べる代わりに、検証方法と評価指標を先に合意するやり方が有効です。
たとえば、どのテストデータを使い、どの誤判定を許容し、どの条件を満たしたら合格とみなすかを詰める。
こうした進め方なら、発注者は期待値を管理でき、ベンダーも過重な義務を避けやすくなります。

折衷案：成果完成型の準委任という落としどころ

折衷案として現実的なのが、法的な完成責任は負わないが、一定の成果到達を目指す成果完成型の準委任です。
これは、請負のように完成責任を全面的に背負わせるのではなく、一定の成果に向けて善管注意義務を尽くす形に近い発想です。
発注者にとっては、完成責任を最後まで切り離さずに済みますし、ベンダーにとっては、AI特有の不確実性を抱えたまま過大な保証を求められずに済みます。
AI案件の契約設計では、このバランスが出発点になるのです。

この考え方は、単なる妥協ではありません。
AI開発は、性能がデータと運用で育つため、最初から最終成果を一枚岩で固定するより、段階的に評価しながら詰める方が合理的です。
発注者が望むのは「動くもの」ではなく、業務で使える水準の再現性でしょう。
その意味で、成果完成型の準委任は、技術的不確実性と商取引上の責任配分を両立させる実務上のおすすめの設計だといえます。

工程別の使い分け：PoC・本開発・運用保守で契約を切り替える

工程ごとに契約を切り替える考え方は、AI開発では実務上かなり有効です。
探索の段階で仕様を固定しきらず、PoCで開発可能性を見極め、本開発で契約形態を確定し、運用保守で継続改善へつなげる流れにすると、見積もりのぶれや手戻りを抑えやすくなります。
最初から一つの契約にまとめるより、各工程の完了時点で次の契約を判断するほうが、発注者にとっても無理のない進め方です。

PoC・アセスメント段階：準委任で探索する

アセスメントとPoCは、AIが本当に業務に使えるかを確かめる探索の段階です。
この時点では成果物の完成を約束するより、仮説検証を積み重ねることに価値があります。
だからこそ、作業の遂行を目的にした準委任が適しており、完成責任や瑕疵担保責任を前提にしないほうが整合的です。
発注者の相談でも、まずPoCを準委任で小さく始めてから次の契約を決める形にすると、投資判断を急ぎすぎずに済みます。

工程を分けず、最初から本開発を請負で走らせようとすると、要件が固まっていないまま見積もりだけが先に膨らみがちです。
実際、この進め方では期待値と実装範囲のズレが大きくなり、途中で契約変更を迫られることが少なくありません。
まずは検証で不確実性を減らし、どこまで作れるかを確かめる。
その順番が、結果として最も手戻りを防ぎます。

本開発段階：仕様が固まれば請負も検討

本開発では、要件定義が進み、何を作るかが相当程度定まっているかどうかが判断基準になります。
仕様や評価方法がはっきりしていれば請負も選択肢になりますが、AIは精度保証が難しく、期待した成果を一度で固定しにくいため、成果完成型準委任が選ばれやすいのが実務です。
発注者は「どこまで仕様が確定したか」を見て、契約形態を切り分けると判断しやすくなります。

ここで重要なのは、請負か準委任かを形式で決めないことです。
モデルの性能、データの質、評価指標の合意状況が十分なら請負に近づきますが、学習データの整備や精度改善が残るなら、準委任の柔軟さを残したほうが安全です。
仕様が固まる前に完成責任だけを先に置くと、現場は守りに入り、開発も遅れやすくなります。

運用保守・追加学習段階：継続改善は準委任で

運用保守と追加学習は、一度納品して終わる工程ではありません。
実運用では入力データの偏りや業務フローの変化が起きるため、改善のたびに見直しが必要になります。
こうした継続的なフィードバックを前提にするなら、準委任が基本になります。
作業を回しながら精度を高めていくAIの性質に、準委任の柔軟性が最も合っています。

この段階で請負に寄せすぎると、改善のたびに契約を作り直す負担が増えます。
むしろ、運用しながら学習データを整え、評価を更新し、次の改善を積み上げるほうが現実的です。
工程を区切り、完了ごとに次の契約を判断する流れにしておけば、PoCで得た知見を本開発へ、本開発の運用実績を保守・追加学習へと自然につなげられます。
おすすめです。

契約時の注意点：偽装請負リスクと知的財産権の取り決め

契約名を整えても、現場の指示系統が崩れていれば発注者側にリスクが残ります。
特に常駐エンジニアへ直接細かな指示を出す運用は、偽装請負の火種になりやすく、知的財産権も契約の書き方を誤ると後で権利関係が曖昧になります。
契約段階では、業務の進め方と成果物の扱いを切り分け、現場運用まで含めて設計しておくことが求められます。

偽装請負：契約名ではなく指揮命令の実態で判断される

偽装請負は、請負や準委任という契約名そのものではなく、実際に誰が誰へ指示しているかで見られます。
発注者がベンダー常駐エンジニアに直接指揮命令を出し、作業の順番まで細かく決めていれば、形式上は準委任でも、実態として違法な労働者派遣に近づきます。
区分の基準は指揮命令の有無だと理解しておくと、判断を誤りにくいでしょう。
現場で見落とされやすいのは、日々のちょっとした声かけです。
技術指導、作業工程の調整、勤務評価まで発注者側が担うと、ベンダー側の管理責任が薄れ、偽装請負と判断される構図が生まれます。
準委任で常駐させたエンジニアに発注者が直接細かい指示を出していたために指摘を受ける、というのは珍しくない落とし穴です。
発注はベンダー側の責任者経由に寄せ、誰が業務を割り振るのかを先に決めておきましょう。

知的財産権は誰のものか

学習済みモデルの知的財産権の帰属は、法律で明確に一本化されていません。
だからこそ、契約で誰に帰属させるのか、あるいはどこまで使えるのかを先に定める必要があります。
権利の名義を奪い合うより、利用範囲・利用目的を明確にする「利用条件」で実をとる設計のほうが、実務ではまとまりやすいはずです。
交渉の現場でも、帰属をベンダーに残しつつ発注者が広い利用権を得る形で落ち着くことがあります。
これは、所有の線引きを厳密に争うより、事業で使える範囲を明文化したほうが双方の納得を得やすいからです。
成果をどう使えるかが明確なら、将来の拡張や再利用の判断もしやすくなります。

検収基準・派生モデルの取り決めを明文化する

契約で見落としがちなのが、検収基準と性能評価の方法です。
どの水準を満たせば合格なのかが曖昧だと、完成後に「できている」「できていない」の水掛け論になります。
数値だけでなく、評価データの条件や確認手順まで先に固めておくと、納品後の摩擦を減らせます。
さらに注意したいのが、派生モデルや蒸留モデルです。
別データを学習させた派生モデルには、元契約の効力が及ばない可能性があるため、利用範囲を本体だけでなく派生物まで広げて書いておく必要があります。
どこまで再利用できるのか、どこから別契約になるのかを曖昧にしないことが、後日の紛争を防ぐ近道です。
ここは事前に明文化しておきましょう。