「請負か、準委任か?」
AIやシステム開発をめぐる契約実務において、成果物の定義や責任範囲を誤ると、プロジェクトの進行に深刻な支障が生じかねません。
本記事では、民法上の整理をふまえつつ、開発フェーズや実務慣行に応じた最適な契約類型の選び方と、よくある誤解・落とし穴の回避ポイントを弁護士の視点で解説します。
目次
1.準委任と請負の区別・選択基準
システム開発取引における「準委任契約」と「請負契約」の使い分けは、成果物の完成を重視するか、作業の遂行自体を重視するかという視点が基本になります。
(1)法的性質の違い
準委任と請負の法律上の相違点をまとめると次の通りとなります。
|
|
準委任 |
請負 |
|
契約の目的 |
受託者は、委託者より依頼を受けた事務を処理すること |
受託者は、委託者より依頼を受けた仕事を完成させること |
|
受託者の義務 |
善管注意義務 |
仕事を完成させる義務 |
|
報酬請求権 |
事務を履行した後でなければ報酬請求できない |
仕事を完成させた後でなければ報酬請求できない |
|
契約解除 |
委託者と受託者は、いつでも契約解除可能 |
委託者は、仕事完成前であれば契約解除可能(受託者からは不可) |
|
再委託 |
原則不可 |
可 |
|
報告義務 |
あり |
なし |
(2)実務上の使い分け視点
■成果物の有無・定義の明確さ
・準委任契約を選択する場面…仕様が流動的で、変更が頻繁に発生する可能性がある取引(例えば、アジャイル開発、保守運用、技術者常駐などの取引)。
・請負契約を選択する場面…要件定義や仕様が明確で確定しており、完成品が想定できる取引(例えば、基幹業務システム、Webアプリケーションなど仕様書に基づき完成物を納品する取引)。
■成果責任の所在
・準委任契約を選択する場面…受託者が作業の結果に対する責任までは負えない取引(もっとも善管注意義務を負担するので、全くの無責ではないことに注意)。
・請負契約を選択する場面…受託者が成果責任を果たすことができる取引(成果物に瑕疵があれば修補責任が発生する)。
■報酬の支払基準
・準委任契約を選択する場面…原則として、作業時間や期間に応じて定期的に報酬を発生させる取引(なお、成果報酬型準委任契約などの例外あり)。
・請負契約を選択する場面…成果物の完成と引換えに報酬を発生させる取引(なお、現場実務的には進捗に応じた中間金などの特約を定めることが多い)。
(3)システム開発取引におけるフェーズと準委任・請負の区分
■要件定義
通常は準委任契約(要件を委託者と受託者が一緒に協議することで、完成品を特定していく段階であるため)。
■基本設計~実装
請負契約とすることが多い(仕様が確定し、完成品がイメージできる状態となっているため)。
■テスト・導入支援
どちらも有り得る(受託者が実施するテストは請負契約に馴染みやすい、委託者主導のテストは準委任契約に馴染みやすい)。
■保守運用
通常は準委任契約(障害対応作業などが中心となるため)。
(4)当事者の立場に応じた準委任・請負の選択基準
■発注者の立場
・成果責任を求めたいなら請負。
・柔軟な変更や運用指示をしたいなら準委任。
■受託者の立場
・成果に対して過度な責任を負いたくないなら準委任。
・単価ベースで安定的に業務提供したいなら準委任。
・自社のテンプレートや既存資産で納品物が早期に完成できるなら請負。
2.準委任契約が馴染みやすいシステム開発の事例
上記1.では、一般論として準委任と請負の相違点や区別の仕方を解説しましたが、実際の現場実務では、準委任契約が用いられるシステム開発取引の事例はある程度固定化されています。
例えば、次のような取引です。
①要件定義フェーズ
業務内容:ユーザ部門の業務分析、システム化要件の整理、Fit & Gap分析など
理由:作業のプロセスと専門的知見提供が中心となるため。
なお、大型のシステム開発といった事例でない限り、要件定義作業のみを抽出して準委任契約を締結することは極めて稀だと考えられます。
これは一般的に、「要件定義、設計、納入」をまとめて受託し、システム開発を行うことが多いからです(この場合、成果物の完成が中心業務となる以上、請負契約として処理されます)。
いわゆる一括契約と、各フェーズに応じた契約(多段階契約)の使い分け等については、次の記事をご参照ください。
システム開発契約における多段階契約・一括契約の選択ポイント等を解説
②調査・検証(PoC)フェーズ
業務内容:新技術(AI、RPA、ブロックチェーン等)の導入可能性調査、モデル評価、API接続テストなど
理由:成果としての「成功」を保証できないため。また、仮説検証的な意味合いが強く、業務遂行に報酬を支払うという当事者認識があるため。
これは近時増えつつある、AI技術を組み込んだシステム開発を念頭に置いています。
例えば、AIが顧客からの問い合わせに対して自動で回答するAIチャットボットシステムの場合、チャットボットシステムを開発する前に、組み込むAIが果たして役に立つのか(委託者の期待通りに動作するのか)検証テストを行います。この検証テストは独立の契約として取り扱われることが一般的であり、ここで記載しているのは、その独立した検証テストに関する契約のことを指しています。
③保守・運用業務
業務内容:障害対応(バグ解析、回避策提示)、バージョンアップ対応、サーバー監視・死活確認・バックアップ作業など
理由:恒常的かつ継続的な業務で、作業ごとの成果物が通常は想定されていないため。
保守・運用業務の中には、修正プログラムの作成など成果物の完成を目的とする取引があることも事実ですが、主たる業務内容は「作業遂行」であり、準委任契約として取り扱われることが通常です。
なお、法律上は準委任契約であっても、上記のような修正プログラムの納品を契約書に記載していた場合、印紙税法上は2号文書(請負)として印紙を納める必要があることに注意を要します。
④エンジニアの常駐型業務支援
業務内容:クライアント企業の社内プロジェクトへの参画(PMO、SE補助)、ユーザ問い合わせ対応、テスト支援など
理由:発注者が日々の作業内容を指図し、これに応じて受託者が作業することが契約目的となるため。
SES取引などが代表例です。
なお、この種の取引の場合、偽装請負に該当しないか注意する必要があります。偽装請負問題については、次の記事をご参照ください。
偽装請負に該当するとどうなる? 契約形態・運用・制裁・是正策を弁護士が徹底解説
⑤アジャイル開発
業務内容:スプリント単位の開発、検証、フィードバック反映
理由:成果物の完成が前提ではなく、反復的な改善作業が重視されるため。また、ユーザとの協働が前提のため、仕様が常に変化するため。
アジャイル開発とは、小単位で実装とテストを繰り返して開発を進めていく手法のことをいいます。この小単位とは、例えばシステムの機能ごとといった意味です。
アジャイル開発は、もともと開発途中でのユーザのニーズ変化に対応できる手法として用いられていることから、成果物は途中で変化するという前提に立っています。このため、請負契約は馴染まないことになります。
⑥運用支援・ヘルプデスク対応
業務内容:エンドユーザからの問合せ対応、操作説明、マニュアル作成など
理由:サービスレベルの維持が目的で、特定の成果物を納める性質ではない。
これは理由欄に記載した通りです。
3.AI技術を組み込んだシステム開発との関係
(1)AIを用いたシステム開発につき準委任契約が望ましいとされる理由
前記2.②でも少し触れましたが、AI技術を組み込んだシステム開発については、準委任契約が望ましいとされています。
このような指摘がされているのは、次のような事情があるためです。
①「成果物の完成保証」が困難であるため(請負契約に馴染まない)
AIが生成する結果は確率的であり、同じ入力でも常に同じ出力が得られるとは限りません(特に生成AIや深層学習)。
このため、モデルの精度や有効性は、提供されるデータの質、量、偏り等に大きく依存し、「完成」や「目標性能(例:正答率90%)」の達成が、受託者の努力だけで保証できないという実情があるためです。
仮に、請負契約とした場合、「成果物の完成」が報酬支払、責任追及の基準になるところ、受託者はリスクコントロールができない事態に陥ってしまいかねません。
②「プロセス(遂行行為)」に価値がある契約であるため
例えば、モデル選定、前処理、プロンプト調整、評価指標の設計などの業務は、成果物の完成ではなく、ノウハウ・判断の積み重ねが主たる業務といえます。特に、PoC(概念実証)段階では、その目的が「導入可否の判断」である以上、成果物の完成とは異なるものとなります。
このような実情を踏まえると、受託者に対して、誠実に業務遂行する義務(善管注意義務)を負担させることが合理的であり、準委任契約に馴染むといえます。
③請負契約とした場合のリスクが高すぎるため
上記①でも少し触れましたが、例えば、精度不足や学習失敗が「債務不履行」扱いになるリスクを受託者のみが負担するのは、不合理と言わざるを得ません。
ちなみに、経済産業省が公表している「AI・データの利用に関する契約ガイドライン」には、次のような記述があります。
|
・アセスメント段階は学習済みモデルの生成可能性を検証するための段階であり、PoC段階は学習済みモデルの生成をさらに進めることの可否および妥当性を検証するための段階であって、そもそも学習済みモデルの完成を目的とする段階ではない。 ・開発段階は学習用データセットを用いて学習済みモデルを生成することを目的とする段階であるが、…(省略)…契約締結時までに仕様や検収基準を確定することは難しいことが多く、また、未知の入力(データ)に対しては、学習済みモデルがユーザ・ベンダのいずれもが想定しない挙動をしないことの保証をすることも困難である。そのため、具体的な仕事の完成を目的とし、一定の瑕疵担保責任(※現行法では契約不適合責任)を伴う請負型の契約にはなじみにくい。 ・追加学習段階は、ベンダが納品した学習済みモデルを基礎に、追加の学習用データセットを使って学習を行うことを目的とする段階であって、一定の学習済みモデルの完成を目的とする段階ではない。 以上のとおり、学習済みモデル生成の各段階には、具体的な学習済みモデルの完成を約束する請負型の契約ではなく、一定の検証や開発といった役務の提供を目的とする準委任型の契約がその実態になじみやすい。 |
④アジャイル・反復型開発と相性がよいため
AI開発は、一度作って終わりではなく、継続的な調整・改善が前提となるため、スプリント単位での成果レビューやパラメータ変更が頻繁に発生することが通常です。
このため、作業ベースで報酬を支払う準委任契約と親和性があるといえます。
⑤技術的・倫理的リスクの分散(責任限定)の観点
誤回答、偏見、不適切応答など、「受託者(開発者)が完全に制御不能な問題」が発生しうることが想定されること、これによる社会的影響や損害の予測が困難であることを踏まえると、受託者の責任を合理的範囲に限定する必要があります。
この点を考慮した場合、成果責任ではなく注意義務ベースの責任となる準委任契約が馴染みやすいと言えます。
(2)請負契約とした場合の問題点
上記(1)でも少し触れていますが、AIを組み込んだシステム開発につき請負契約とした場合の問題点をここで解説しておきます。
①成果物の「完成」の定義が曖昧になりやすい
請負契約は、「完成した成果物の引渡し」が契約の中心的義務です。
しかしAI開発では、成果物(例:モデル、アルゴリズム)の完成基準が客観的に定義しづらく、「完成したか否か」を巡って紛争になる可能性が高いと言わざるを得ません。
具体的には、納品後に委託者から「期待した精度に達していない」として検収拒否、契約不適合責任を追及されるリスクが生じます。
②精度や性能の「保証」を求められるリスク
AIの性能(例:正答率90%など)は、学習データや利用環境に左右されるため、保証が非常に困難であるにもかかわらず、請負となった場合、一定の性能保証を要求される可能性が高くなります。
もし、性能について委託者に不満が生じた場合、受託者は、契約違反を理由とする契約解除や損害賠償請求を受けるリスクが生じます(結果として、受託者が「予測不可能なリスク」を背負う構造になります)。
③改善・チューニングなどの「継続対応」と契約構造が合わない
一般的にAI開発は「納品して終わり」ではなく、運用中のフィードバックに応じた継続的改善が前提となっています。もっとも、請負契約では、別途保守運用契約を締結しない限り、納品完了後の受託者による関与がなくなります。
この結果、せっかくのAIシステムを委託者が活用できず、これに起因して受託者がクレームを受けるリスクが生じます(法的な根拠が成立するか否かを問わず)。
(3)AI技術を組み込んだシステム開発契約書を作成する場合の注意点
上記(1)及び(2)で解説した通り、AI技術を組み込んだシステム開発取引の場合、準委任契約とすることが望ましいと言えます。
このように書くと、巷にある準委任契約書(業務委託契約書)を転用すれば、AI技術を組み込んだシステム開発契約書を作成することが可能と考える方もいるかもしれません。
たしかに、一般的な準委任契約書(業務委託契約書)をベースにすること、それ自体は問題ありません。しかし、AIには特有の注意事項(例:性能が保証できない等)があるため、この点を意識して加除修正しないことには必要十分な契約書にはなりません。
一般的な準委任契約書(業務委託契約書)については、次の別コンテンツをご参照いただくとして、ここではAI特有の注意事項につき解説します。
準委任契約(業務委託契約)とは何か? 契約書作成時の注意点と共に解説
①契約類型の誤解
準委任契約は「業務遂行」義務にすぎず、成果物の完成は約束されません。
しかし、委託者が「AI技術を組み込んだ『システム』を完成させてくれるはず」と誤解している可能性は十分にあり得ます。そして、この誤解を解かないまま作業を進めたことで、最後の最後で「満足のいくものではない」として、委託者が支払を拒否する等のトラブルが勃発するといったことが起こりえます。
したがって、受託者の立場からすれば、契約書には成果保証しない旨を明示することが重要です。
②成果の見えづらさ
準委任契約に基づく報酬は、作業遂行に対する対価である点を頭では分かっていても、委託者からすれば、業務に対する対価性が見えづらいのは事実です。
この点を考慮するのであれば、定期的な業務報告書の提出義務、作業成果(例:設計書、テスト結果、学習ログなど)を契約書に明記し、委託者の納得を得やすいものとするのが得策です。
③成果物の知的財産権帰属を見落としがち
準委任契約の場合、成果物の完成が契約目的とはなりませんが、成果物の作成自体は行われる以上、その成果物に対する権利の取扱い等は生じ得ます。特にAI技術を用いた開発の場合、プロンプト、テンプレート、設計資料、学習済モデルなど、作業遂行に伴い知的財産が断続的に発生しますが、契約書でこれらに対する権利帰属を定めていない場合、トラブルに発展しかねません(これらのものは、果たして著作物に該当するのか怪しい場合もあり、明確な権利ではなく、一定の法律上の利益を享受する地位に過ぎないこともあります)。
この観点からすると、権利帰属の明確化と共に使用許諾範囲を契約書に明記することがポイントになります。
④学習データの取扱い
提供データや対話ログに個人情報(例:顧客情報など)が含まれる可能性があるところ、AIはその情報を用いて学習するため、取り扱いの明確化が不可欠となります。
したがって、利用目的の限定、再利用禁止、削除義務等を契約書に整備することが重要となります。
⑤精度・結果への責任限定
AIの性質上、誤った回答や不適切な出力は避けて通ることができません。
したがって、受託者の立場からすれば、契約上又はSLA等で、「精度・応答結果は保証しない」、「故意・重過失以外は免責」といった責任限定条項を設けるのが必須となります。
⑥契約終了時の処理
契約終了後もモデルやデータが残ると、秘密保持や知的財産権侵害のリスクが残ることになります。
このため、「業務用データ・ログ・モデル等の返還、削除義務」、「第三者への再利用禁止」等の契約終了後の措置につき、手厚く契約書に定めておく必要があります。
4.システム開発取引(準委任・請負)を弁護士に相談・依頼するメリット
AIを含むシステム開発取引は、技術革新のスピードと同様に、法的リスクや契約責任も高度化・複雑化しています。
「準委任にするか請負にするか」という一見シンプルな問題も、実際には次のような複雑な判断を要する場面が少なくありません。
・要件定義が不確定な段階で、どこまで業務範囲を契約化すべきか
・成果物と知的財産の帰属をどこまで明示すべきか
・精度や性能が発注者の期待に届かなかった場合の責任の限定方法
・継続的な改善・保守対応の法的整理
・偽装請負と判断されないための業務体制と契約設計 …など
これらのリスクを契約段階で予防することが、トラブルを未然に防ぎ、貴社の信用・利益を守る最大の方策です。
■弁護士に相談・依頼するメリットとは
弁護士に相談することで、次のような実務的なメリットが得られます。
|
①貴社の開発プロセスや事業モデルに即した最適な契約類型の選定 単に「準委任が安全」「請負は危険」といった一般論ではなく、貴社が抱える開発スキームに応じて、最適な契約形態や条項設計を行います。
②想定されるリスクを洗い出した実践的な契約ドラフト・レビュー 契約条文の一語一句を点検し、責任の限定、成果定義、知的財産権の帰属、業務報告義務など、発注側・受託側それぞれの立場で重要な論点を適切に整理します。
③万一の紛争や契約交渉への備えも可能に 紛争が発生した場合でも、事前に法的観点から備えておくことで、有利な交渉材料を確保し、解決の主導権を握ることができます。 |
5.リーガルブレスD法律事務所のサポート
リーガルブレスD法律事務所は、複数のシステム開発事業者の顧問弁護士として活動すると共に、スポットでの法律相談等も多数お受けしています。
そして、近時注目を集めている生成AIと連携したシステム開発取引に関する交渉支援、契約書の作成、トラブル対応など、システム開発にまつわる様々なサポートを行ってきました。
クライアントの皆様には、現場実務対応で得られた知見とノウハウを活用し、できる限り有利な形での解決を図ることができるよう日々尽力しています。
【リーガルブレスD法律事務所が提供するサポート内容】
当事務所では、システム開発・AI導入に関わる契約支援を多数取り扱っています。
契約類型の選定から契約書ドラフト、交渉サポート、継続的な法務相談まで、貴社の業務実態に応じた対応が可能です。
ご関心のあるサービスがございましたら、ぜひお気軽にご相談ください。
■契約書レビュー・チェックプラン
|
ご依頼内容(例) |
・準委任契約で取引することになったが、成果責任や知財の取扱いが不安 ・請負契約として渡された契約書に精度保証が書いてあるが、削除してもいいのか? |
|
サポート内容 |
・契約書(受注・発注いずれも)の法的チェック ・不利条項、見落としリスクの指摘 ・修正文案の提案(成果定義、責任限定、知財など) |
|
主な利用者 |
・中小~中堅SIer、ITベンダ、発注者(IT導入企業) ・自社契約雛形をお持ちでない方 ・初めて準委任契約を結ぶ方など |
|
弁護士費用 |
8万円(税別)~ (契約書のボリューム、難易度等により変動します) |
|
実施方法 |
・契約書データを事前送付 ・Web面談でご意向確認 ・レビュー結果を記載したWordデータを納品 |
■契約書作成・カスタマイズプラン
|
ご依頼内容(例) |
・準委任契約を使うと言われたが、自社に合った雛形がない ・AI開発に特化した契約書をゼロから作りたい |
|
サポート内容 |
・業務内容、開発スキームに応じた契約書の新規作成 ・業務範囲、報酬、知財、データ、成果物定義等の明文化 ・検収プロセスがない場合の補完方法の設計 |
|
主な利用者 |
・AIシステム開発企業(委託者側・受託者側問わず) ・法務部がないスタートアップ、新興IT事業者など |
|
弁護士費用 |
10万円(税別)~ (難易度、作業工数などによって変動します) |
|
実施方法 |
・30分~1時間程度のヒアリング ・初案(たたき台)の提示 ・ご指摘に応じた加除修正 ・Wordデータにて納品 |
■継続顧問プラン
|
ご依頼内容(例) |
・契約の相談や利用規約の整備など、毎月発生するが都度依頼が面倒 ・エンジニアからの質問にも応えてくれる弁護士を探している |
|
サポート内容 |
・契約書(開発契約、業務体系、NDAなど)レビュー・ドラフト ・技術寄りの法務質問にも随時対応 |
|
主な利用者 |
スタートアップ、中堅IT企業(社内に法務部がない企業)など |
|
弁護士費用 |
月額5万円(税別)~ (※1ヶ月当たりの対応件数、業務範囲に応じて設定します) |
|
実施方法 |
Chatwork・メール・定期Zoom対応など柔軟に対応可能 |
■スポット(単発)法律相談プラン
|
ご依頼内容(例) |
・AIを活用したシステム開発を予定しているが、請負と準委任のどちらが適切か判断できない ・PoC段階なので成果は出せないが、費用請求できるようにしたい。条項案を相談したい ・学習データの知的財産権帰属や秘密保持の条項に不安がある ・精度保証や検収をどう整理すべきか、他社の事例に即したアドバイスがほしい |
|
サポート内容 |
・ご相談内容に応じた契約上のリスクの洗い出しと対策のアドバイス ・既存契約書やドラフト文案への口頭コメント ・類似事例や実務慣行に基づいた契約構造や条項設計の方向性提示 ・必要に応じて、準委任/請負のハイブリッド型や成果定義の設計案の提示 |
|
主な利用者 |
・システム開発やAI導入に関する契約締結を控えた事業会社(発注者) ・契約書案を提示されたが、どこを修正すべきかわからない受託者 ・法務部を持たないスタートアップ、中小企業 ・顧問契約を検討する前に、まずは単発で相談してみたい企業担当者など |
|
弁護士費用 |
1回90分当たり15,000円(税別) |
|
実施方法 |
・事前に関係資料の送付、事前検証 ・オンライン面談 or 来所での対面面談 |
<2025年7月執筆、2026年1月加筆>
※上記記載事項は弁護士湯原伸一の個人的見解をまとめたものです。今後の社会事情の変動や裁判所の判断などにより適宜見解を変更する場合がありますのでご注意下さい。