AI開発の契約形態は請負か準委任か。発注側が押さえる三つ

AIを使うシステム開発を外部に発注するとき、請負契約と準委任契約のどちらが合うかで迷うことがあります。答えは、仕様と合格条件が契約時点で書き切れるかどうかです。書き切れるなら請負、探索が多く成果物が途中で動くなら準委任が合います。工程ごとに契約を分けることもできます。

請負と準委任、そもそもの違い

請負契約は、仕事を完成させることを約束し、その結果に対して報酬を受け取る契約です。成果物が仕様どおりに完成していなければ、契約を果たしたことにはなりません。準委任契約は、業務を遂行することを約束する契約で、成果物の完成そのものは約束しません。受託者は決められた注意を払って業務を進める義務を負いますが、結果が仕様どおりであることまでは保証しません。

この違いが、AIを使う開発では通常の開発よりも大きな意味を持ちます。仕様が固まっていない段階で請負にしてしまうと、完成の基準が曖昧なまま契約を結ぶことになります。

請負か準委任か。押さえる三つ

請負が合う場合

成果物と合格条件が、契約時点で書き切れる場合です。仕様どおり動くかどうかで検収できるため、要件が固まった本開発の段階に向いています。

準委任が合う場合

探索が多く、成果物が途中で動く場合です。作業量や工程の完了で確認するため、PoC（試作）や方針を探る段階に向いています。

先に決めること

どちらで発注するかは、仕様の固さから選びます。要件定義は準委任、開発は請負というように、工程ごとに契約を分ける進め方も一般的です。

AI開発で請負が難しくなる場面

AIは、同じ入力に対して必ずしも同じ結果を返すとは限りません。「精度○%を保証してください」という条件を契約に書くのは現実的ではないことがあります。仕様どおり動くかで検収する請負契約は、この不確実性と噛み合わないことがあります。

合格条件を、精度の数値保証ではなく、評価データ・指標・許容水準の事前合意という形で書けば、請負でも検収の基準を持てます。何を確かめれば合格かで書いた考え方が、この合意の作り方に当たります。

契約不適合責任との関係

請負契約では、完成した仕事が契約の内容と合っていない場合、受託者が修正や損害の賠償を負う責任があります。この責任の範囲を明確にするには、そもそも「契約の内容」が仕様として書き切れていることが前提になります。仕様が曖昧なまま請負契約を結ぶと、責任の範囲を判断する基準そのものが曖昧になります。

探索が多い段階は、準委任から始める

PoCの段階は、何が実現できるかを確かめる作業です。成果物を確定させる前に、準委任で作業量に応じた契約から始め、実現の見通しが立ってから請負に切り替える進め方があります。最初から請負で始めると、探索の途中で仕様変更が繰り返され、契約と実態がずれます。

切り替えのタイミング

準委任から請負に切り替える判断は、成果物の形と合格条件の両方が文書にできる状態になったかどうかで見ます。片方だけが決まっている状態で切り替えると、検収の段階で解釈の違いが出ます。要件定義の粒度をどこまで割るかはAIシステム開発の要件定義で、通常の外注と変わる三つで書いています。

工程を分けて検収する進め方

大きな開発を一つの請負契約にまとめると、完成の判断が最後の一回に集中し、途中で意図とのずれに気づいても直しにくくなります。工程や機能の単位で契約と検収を分け、それぞれの単位で合格条件を確認しながら進める方法もあります。この分け方は、仕様をAIに渡せる粒度まで割る考え方と同じ根を持っています。分割の単位が細かいほど、契約と検収も細かく分けやすくなります。仕様を割る考え方は人向けの要件定義を、AIに渡せる粒度まで割る方法で書いています。

工程ごとに検収する場合、それぞれの工程の合格条件を、次の工程が始まる前に文書にしておく必要があります。合格条件があいまいなまま次の工程に進むと、後になって前の工程のやり直しが必要になったときに、どちらの契約の範囲かが分からなくなります。

工程を分けるほど、契約書や検収の書類を作る手間は増えます。仕様が最初から固く、探索の要素がほとんどない案件では、工程を分けずに一つの請負契約で進めたほうが、手間と検収の確実性のバランスが取れることもあります。工程を分けるかどうかも、仕様の固さから判断します。

開発を頼まなくても、ここだけ相談できる

契約形態の選び方、合格条件の書き方だけでも相談できます。実装を当社が担当しない案件でも同じです。すでに契約を結んでいる案件でも、次の工程の契約形態を選ぶところから相談できます。考え方はAboutに、相談はお問い合わせに相談の窓口を置いています。

よくある質問

AI開発の契約は、請負と準委任のどちらを選ぶべきですか

仕様と合格条件が契約時点で書き切れるなら請負、探索が多く成果物が途中で動くなら準委任が合います。

工程ごとに契約を分けることはできますか

できます。要件定義やPoCの段階は準委任、成果物が固まった本開発は請負というように分けることが一般的です。

精度を契約でどう保証すればよいですか

「精度○%を保証」という数値の約束ではなく、評価データ・指標・許容水準を事前に合意する形にします。

最初から請負で発注してはいけないのですか

仕様が固まっていない段階で請負にすると、探索の途中で仕様変更が繰り返され、契約と実態がずれます。探索が多い段階は準委任から始めることを勧めます。

PoCと本開発で契約を分ける理由は何ですか

PoCは実現可能性を確かめる作業で、成果物を確定できません。本開発は成果物と合格条件を確定させた段階です。段階が変わると、合う契約形態も変わります。

この判断は、AIを使わない開発でも同じですか

基本的な考え方は同じですが、AI開発では精度の不確実性という要素が加わる点が異なります。

開発を頼まなくても相談できますか

できます。契約形態の選び方、合格条件の書き方だけをお受けしています。

知財の帰属はどちらの契約でも決めておくべきですか

はい。請負・準委任のどちらでも、AIが生成したコードの著作権・利用条件は契約に明記します。

準委任から請負に切り替えるタイミングは、どう見ればよいですか

成果物の形と合格条件の両方が文書にできる状態になったかどうかで見ます。片方だけでは、検収の段階で解釈の違いが出ます。

請負契約での契約不適合責任は、仕様が曖昧でも問えますか

問いにくくなります。責任の範囲を判断する基準は契約の内容、つまり仕様です。仕様が曖昧なまま契約を結ぶと、責任の範囲を判断する基準そのものが曖昧になります。

大きな開発を、工程ごとに契約と検収を分けるメリットは何ですか

完成の判断が最後の一回に集中せず、工程ごとに意図とのずれを確認できます。分割の単位が細かいほど、途中でのやり直しの範囲も小さくできます。

工程ごとに検収する場合、次の工程に進む前に何を決めておく必要がありますか

その工程の合格条件を、文書として先に決めておきます。合格条件があいまいなまま次の工程に進むと、あとでやり直しが必要になったときに契約上の範囲が分からなくなります。