AI開発の契約形態の選び方｜準委任・請負・ラボ型の違いと段階別の検収条件

AI開発を外部に委託するとき、最初につまずきやすいのが契約形態の選択です。「準委任と請負のどちらがよいのか」「ラボ型と提案されたが何が違うのか」「PoCで期待した結果が出なかったら費用はどうなるのか」。こうした疑問を残したまま、ベンダーから提示された契約書に署名してしまうと、後から検収や追加費用をめぐって認識のずれが表面化しやすくなります。

この記事では、BtoB企業でマーケティングやDX推進を担当している方に向けて、AI開発の契約形態である準委任・請負・ラボ型の違いを整理し、PoC（概念実証）から本番開発、運用までの段階ごとにどの契約を選ぶか、検収条件をどう決めるかを解説します。法律の細部よりも、発注側の担当者が社内調整やベンダーとの打ち合わせで使える判断基準に重点を置いています。

なお、契約書の最終的な確認は、自社の法務部門や弁護士に依頼してください。ここで扱うのは、契約形態を考えるための一般的な整理です。

なぜAI開発は契約形態の選び方が難しいのか

従来の業務システム開発では、要件定義で画面や機能、処理の流れを決め、その仕様どおりに動くものを作れば完成とみなせました。一方、機械学習や生成AIを使った開発では、「仕様どおりに作ったが、期待した精度が出ない」という事態が起こり得ます。この違いが、契約形態の選び方を難しくしています。

結果がデータに左右され、事前に完成形を約束しにくい

AIの出力の品質は、学習や評価に使うデータの量・質・偏り、業務の例外パターンの多さなどに大きく左右されます。データを実際に分析してみるまで、どの程度の精度が見込めるかは発注側にもベンダーにも分かりません。そのため、開発の初期段階で「この精度を達成したら完成」と約束すること自体が難しく、完成を前提にした契約とは相性がよくない場面があります。

開発の途中で目標や進め方が変わりやすい

検証を進めるうちに、「この業務はAIより既存のルール処理のほうが向いている」「対象範囲を絞れば実用に足る」といった発見が出てきます。AI開発は、試しながら目標そのものを調整していく性質を持っています。最初に決めた仕様を固定して進める契約だと、こうした方針転換のたびに変更契約が必要になり、発注側・受注側の双方に負担がかかります。

こうした事情から、AI開発では一つの契約で最後まで発注するのではなく、段階を分けて契約し、段階ごとに次へ進むかどうかを判断する考え方が広く取られています。公的な情報としては、特許庁 IP BASE「AI開発を受託する際の契約方式の選び方 請負型と準委任型」でも、AI開発の受託における請負型と準委任型の選び方が取り上げられています。また、経済産業省の「AI・データの利用に関する契約ガイドライン」では、段階を区切って探索的に進める開発方式の考え方が示されています。

準委任・請負・ラボ型の違い

AI開発の委託でよく使われる契約形態は、準委任、請負、ラボ型の三つです。ラボ型は法律上の独立した契約類型というより、準委任契約をベースにした運用の形として結ばれることが一般的です。それぞれの特徴を見ていきます。

準委任契約：作業の遂行に対して報酬を払う

準委任契約は、ベンダーが専門家として注意を尽くして作業を行うことを約束する契約です。成果物の完成そのものは約束しないため、期待した精度が出なかったとしても、契約どおりに作業を行っていればベンダーの債務不履行にはなりません。報酬は作業時間や期間に応じて支払う「履行割合型」が基本ですが、2020年施行の改正民法では、成果物の引渡しに対して報酬を支払う「成果完成型」の準委任も明文化されました。成果完成型であっても、完成義務まで負うわけではない点が請負との違いです。

準委任は、何ができるか分からない段階の検証や、要件が動き続ける開発に向いています。発注側から見ると、柔軟に方向転換できる反面、期間や作業範囲を管理しないと費用が膨らみやすいという特徴があります。

請負契約：成果物の完成に対して報酬を払う

請負契約は、ベンダーが仕事を完成させることを約束し、発注側が完成した成果物に対して報酬を払う契約です。成果物が契約内容に適合しない場合、発注側は修補や代金減額などを求められる契約不適合責任の仕組みがあります。予算と納期を固定しやすく、社内の稟議や予算管理と相性がよい形態です。

ただし、請負が機能するのは「何をもって完成とするか」を仕様書で明確に定義できる場合に限られます。完成条件があいまいなまま請負で発注すると、ベンダーはリスクを見込んで見積もりを高めにしたり、完成の定義を狭く解釈したりしやすくなり、結果として発注側の期待とずれることがあります。

ラボ型契約：一定期間、専任チームを確保する

ラボ型は、一定期間、ベンダーのエンジニアやデータサイエンティストなどで構成するチームを確保し、その期間内で優先度の高い開発や改善を進めていく形態です。毎回の発注ごとに見積もりや契約を結び直す必要がなく、メンバーに業務知識が蓄積されていく点が利点です。

一方で、発注側にも「次に何を作るか」「どれを優先するか」を判断し続ける体制が求められます。発注する開発内容が少ない期間も、確保したチームの費用は発生するのが一般的です。また、準委任をベースにしているため、発注側がベンダーのメンバーに直接、細かな作業指示を出すと、偽装請負とみなされるおそれがある点にも注意が必要です。

表から分かるとおり、三つの形態に優劣があるわけではありません。違いは「どこまで決まっているか」と「発注側がどれだけ関与できるか」にあります。完成形を定義できるなら請負、できないなら準委任、長期で改善を続けるならラボ型、というのが大まかな目安です。

契約形態を選ぶための判断基準

実際に契約形態を選ぶときは、ベンダーの提案をそのまま受け入れるのではなく、自社の状況に照らして確認することが大切です。次の問いに順番に答えていくと、どの形態が合っているかが見えてきます。

特に重要なのは、最初の二つの問いです。完成形を定義できず、データの状態も分からないうちに請負で発注するのは、発注側・ベンダー双方にとってリスクが高い選択です。逆に、仕様もデータも固まっているのに準委任で漫然と続けると、費用と期間の管理が難しくなります。

PoCから本番開発までの段階別の契約の選び方

AI開発は、一般に構想・アセスメント、PoC、本番開発、運用・改善という段階を経て進みます。段階ごとに分からないことの量が減っていくため、それに合わせて契約形態を切り替えていくのが合理的です。各段階の終わりに「次の段階へ進むか、方針を変えるか、中止するか」を判断する場を設けることで、見込みのない開発に費用をかけ続けるリスクを抑えられます。

構想・アセスメント段階

解決したい業務課題を整理し、AIで取り組む価値があるか、どのデータが使えそうかを確認する段階です。手元のデータを一部ベンダーに渡して簡易的な分析を依頼することもあります。成果物は課題の整理や実現可能性の見立てなので、準委任が適しています。期間を短く区切り、何を判断するための調査なのかを契約前に明確にしておきます。

PoC（概念実証）段階

実際のデータを使って小さなモデルや試作品を作り、業務で使える水準に届きそうかを検証する段階です。結果が事前に読めないため、準委任が基本になります。重要なのは、PoCの目的を「AIを作ること」ではなく「本番開発に進むかどうかを判断する材料を得ること」と位置づけることです。そのうえで、期間、作業範囲、報告の頻度、中止を検討する条件を契約に盛り込みます。

本番開発段階

PoCで確認した方式をもとに、業務システムとして使える形に作り込む段階です。PoCを経て仕様やデータの前提が固まっていれば、請負で発注できる範囲が広がります。ただし、モデルの精度向上の部分は準委任、システムへの組み込みや画面開発の部分は請負、というように、性質の違う作業を分けて契約する方法もあります。費用の内訳の考え方はAI駆動開発の費用の内訳と見積もりの読み方も参考になります。

運用・改善段階

本番稼働後は、データの変化に合わせた再学習やプロンプトの調整、機能追加などが継続的に発生します。障害対応や監視などの定型的な作業は保守契約で、改善や機能追加は準委任やラボ型で、というように分けて考えると整理しやすくなります。運用段階の費用については生成AIの運用保守費用の内訳と見積もりの読み方で詳しく解説しています。

段階を分けることには、ベンダーを途中で見直せるという利点もあります。PoCを依頼したベンダーと本番開発のベンダーを別にすることも可能です。その場合は、PoCの成果物やデータ、知見を次のベンダーに引き継げるよう、権利や資料の扱いを最初の契約で決めておく必要があります。

検収条件の決め方

検収とは、受け取った成果物や作業結果が契約どおりかを発注側が確認し、受け入れる手続きです。AI開発では、段階によって「何を検収するのか」が大きく変わります。ここをあいまいにしたまま進めると、もっとも揉めやすいポイントになります。

PoCの検収：判断材料がそろっているかを確認する

PoCの検収対象は、精度の数値そのものではなく、本番開発に進むかどうかを判断するための材料です。具体的には、使ったデータの範囲と前処理の内容、評価の方法と結果、うまくいかなかったケースの分析、本番化に向けた課題と必要な作業の見立てなどが報告書にまとまっているかを確認します。契約時に「報告書に含める項目」を合意しておけば、精度が目標に届かなかった場合でも、検収の基準ははっきりします。

本番開発の検収：受入テストの基準を事前に合意する

本番開発を請負で発注する場合は、受入テストの項目と合格基準を契約時点で決めておきます。画面や機能、他システムとの連携、処理時間、エラー時の動作など、従来のシステム開発と同じ観点はそのまま使えます。AI部分については、次に述べる精度の扱いを別途決めておく必要があります。

精度の数値目標をどう扱うか

精度を検収条件に入れること自体は可能ですが、その場合は、評価に使うデータセット、指標の定義（何を正解とし、どう数えるか）、測定の手順を事前に合意しておくことが前提です。評価用データは、学習に使っていないもので、実際の業務を代表する内容にする必要があります。また、本番稼働後はデータの傾向が変わり、精度が変動し得ることも踏まえておきます。精度を完成条件にするのが難しい場合は、「合意した評価手順で測定し、結果を報告すること」までを請負の範囲とし、精度の向上は準委任で別に扱う方法もあります。

検収の手続き：期間・不合格時の扱い・記録

検収条件と並んで、手続きも決めておきます。成果物の納品から検収結果を通知するまでの期間、期間内に通知しなかった場合の扱い、不合格だった場合の修正と再検収の流れ、仕様変更をどう記録して合意するかといった点です。打ち合わせでの口頭の合意は、議事録や変更管理の文書に残し、双方で確認しておくと、検収時の認識のずれを防げます。

このように、PoCでは「判断できる状態になったか」、本番開発では「合意した基準を満たしたか」を検収します。同じAI開発でも、段階によって検収の意味が異なることを社内の関係者とも共有しておくと、稟議や報告の場で説明しやすくなります。

契約前に確認したいチェックリスト

契約書に署名する前に、次の項目が契約書や仕様書、提案書で明確になっているかを確認します。ベンダーへの依頼内容を整理する段階で、AI開発のRFPの書き方と評価基準もあわせて確認しておくと、各社の提案を比較しやすくなります。

• 契約の対象となる段階と、その段階の目的が書かれているか
• 成果物の種類と、成果物に含める内容（報告書の項目、文書、プログラムなど）が具体的か
• 準委任の場合、期間、作業範囲、工数の上限、報告の頻度が決まっているか
• PoCの場合、中止を検討する条件と、中止したときの費用の扱いが書かれているか
• 検収の対象、合格基準、検収期間、不合格時の修正と再検収の流れが決まっているか
• 仕様変更の申し入れ方、見積もりの出し方、合意の記録方法が決まっているか
• 学習済みモデル、プログラム、学習用データセットなどの権利の帰属と、利用できる範囲が書かれているか
• 発注側が提供したデータを、ベンダーが他の案件や自社の改善に使えるかどうかが明確か
• 秘密保持と個人情報の取り扱い、データの返却・削除の方法が決まっているか
• 損害が生じた場合の責任の範囲と上限が書かれているか
• 準委任やラボ型の場合、作業の指示を誰が誰に出すかという体制が明確か
• 本番稼働後の保守・改善を、どの契約で誰が担うかの見通しがあるか

データやシステムを外部に預ける場合は、委託先のセキュリティ体制の確認も欠かせません。確認の観点は委託先のセキュリティ対策チェック項目にまとめています。

つまずきやすい点と対処

AI開発の契約では、契約形態の選び方そのものより、運用の段階で問題が表面化することが多くあります。代表的なつまずきと対処を整理します。

PoCが終わらず、準委任が延々と続く

「もう少し調整すれば精度が上がるかもしれない」と検証を延長し続け、本番開発にも中止にも進めない状態です。原因の多くは、PoCの終了条件と判断の場が決まっていないことにあります。対処としては、PoCの期間を区切り、終了時に何をもって判断するかを契約前に決め、延長する場合も目的と期間を改めて合意することが有効です。

請負で発注したのに精度が出ず、検収で揉める

データの状態を確かめないまま請負で発注し、納品物の精度が期待に届かないケースです。発注側は「完成していない」、ベンダーは「仕様どおりに作った」と主張し、話が平行線になりがちです。PoCを経てから請負に切り替える、精度の扱いを請負の範囲から切り離す、評価手順を事前に合意するといった方法で予防します。

ラボ型で発注側が直接指示を出してしまう

ラボ型のチームと日常的にやり取りするうちに、発注側の担当者がベンダーの個々のメンバーに作業の進め方や時間の使い方まで指示してしまうことがあります。準委任ベースの契約でこうした指揮命令を行うと、偽装請負とみなされるおそれがあります。要望はベンダー側の責任者を通して伝え、優先度の調整は定例の場で行うなど、やり取りの窓口とルールを決めておきます。

権利やデータの扱いを後回しにする

開発が始まってから学習済みモデルの権利やデータの利用範囲を話し合うと、すでに作業が進んでいるため交渉が難しくなります。将来、別のベンダーへ切り替えたい、内製化したいといった可能性があるなら、成果物の引き継ぎや利用の条件を最初の契約で決めておくことが大切です。内製化を視野に入れる場合は生成AIの内製化の判断基準と進め方も参考にしてください。

よくある質問

準委任だと、成果が出なくても費用を払い続けることになりますか？

準委任は完成を約束しない契約のため、作業を行った分の報酬は発生するのが基本です。ただし、期間や工数の上限、報告の頻度、中止を検討する条件を契約に書いておけば、見込みが立たない段階で止める判断ができます。

PoCは準委任、本番開発は請負に切り替えてもよいですか？

問題ありません。PoCで仕様やデータの前提を固め、本番開発で請負に切り替えるのは、段階を分けて契約する考え方に沿った進め方です。切り替える際は、PoCの成果物や知見を本番開発でどう扱うかも決めておきます。

AIの精度を検収条件にしてもよいですか？

可能ですが、評価に使うデータ、指標の定義、測定の手順を事前に合意しておくことが前提です。本番稼働後に精度が変動し得ることも踏まえ、基準を満たさなかった場合の扱いも契約に書いておきます。

ラボ型と準委任はどう違いますか？

ラボ型は法律上、準委任契約として結ばれることが多く、違いは一定期間、専任のチームを確保して優先度の高い開発を進めるという運用の形にあります。発注内容が流動的で、長期の改善を前提にする場合に向いています。

契約形態はいつ決めればよいですか？

ベンダーに提案を依頼する前に、どの段階をどの形態で発注したいかという方針を持っておくと、各社の提案を比較しやすくなります。最終的には、各段階を始める前に、その時点で確定している情報をもとに決めます。

まとめ

AI開発の契約形態は、準委任・請負・ラボ型のどれが優れているかではなく、「どこまで決まっているか」と「発注側がどれだけ関与できるか」で選びます。要点を整理すると次のとおりです。

• 結果が事前に読めない構想・アセスメントやPoCは、準委任で期間と範囲を区切って進める
• PoCで仕様とデータの前提が固まった本番開発は、請負、または請負と準委任の組み合わせを検討する
• 本番稼働後の継続的な改善は、保守契約に加えて準委任やラボ型で進める
• PoCでは判断材料がそろっているか、本番開発では合意した受入基準を満たすかを検収する
• 精度を検収条件にするなら、評価データ・指標・測定手順を事前に合意する
• 権利、データの利用範囲、変更手続き、指示の窓口は、開発が始まる前に決めておく

契約形態を決める前に、そもそも何の課題をAIで解決したいのか、どの業務や顧客接点に効果を期待するのかを整理しておくことが、段階ごとの目的や検収条件を決める土台になります。

HVLでの進め方

ハイ・ヴァーチュ・ラボは、AI駆動開発・システムインテグレーション・マーケティングを一気通貫で提供するテクノロジーパートナーです。プロジェクトの立ち上げから収益化まで、すべての工程を網羅しています。AIを使った開発の相談では、開発の技術面だけでなく、その開発がマーケティングや事業の成果にどうつながるかという目的の整理から一緒に進めます。

「AIで何から取り組むべきか分からない」「開発の前に、自社のマーケティングの課題を整理したい」という段階であれば、まずは無料マーケティング診断をご活用ください。現状の課題を整理したうえで、AI開発に進むべきか、どの段階から始めるかを検討する材料になります。開発や保守の具体的な相談はシステムインテグレーション（開発・保守）のページもご覧ください。