「受託開発を依頼する＝請負契約になる」と思い込んでいる発注担当者は少なくありません。しかし実際には、受託開発は自社開発（内製）と対になる「発注のビジネスモデル」の呼び方であり、請負・準委任は民法上の「契約類型」です。この2つは別の次元の言葉であるため、混同したまま契約書を読むと、思わぬトラブルにつながります。特にAI・DX開発では要件が事前に固まりにくく、契約類型の選び方が案件の成否を左右します。この記事では、請負・準委任の基本と、AI・DX開発で失敗しない契約の選び方を整理します。
受託開発と請負は何が違うのか？「発注形態」と「契約類型」の整理と請負・準委任の基本
「受託開発」とは、自社にエンジニアを抱えずに外部のベンダーへ開発業務を委ねる発注形態全般を指す言葉です。これに対して「請負」「準委任」は、民法で定められた契約の種類（契約類型）であり、受託開発をどちらの契約で結ぶかは案件ごとに選択されます。つまり「受託開発＝請負契約」ではなく、受託開発の中に請負と準委任という2つの選択肢がある、という関係です。
経済産業省が公表している「情報システム・モデル取引・契約書（受託開発・保守運用）」では、請負契約は成果物の完成そのものに責任を負い、完成後は契約不適合責任（旧・瑕疵担保責任）を負う契約類型として整理されています。一方の準委任契約は、決められた成果物の完成ではなく、ベンダーが業務を遂行すること自体に対価が発生する契約類型で、成果物の完成責任は原則負いません。この基本構造を理解しておくことが、契約選びの第一歩になります。
「うちの案件は請負？準委任？」という段階からでもご相談いただけます。
無料で相談するMisconceptions
「受託開発＝請負契約」など、契約選びでよくある誤解3点
誤解1：受託開発は必ず請負契約である。実際には、要件が固まっているウォーターフォール型の開発では請負が選ばれやすい一方、要件が流動的なアジャイル型の開発では準委任が選ばれることが多く、案件の進め方によって最適な契約類型は変わります。
誤解2：準委任は成果物責任を負わないので発注者に不利である。実際には、準委任契約でも善管注意義務（善良な管理者としての注意を尽くす義務）は発生し、業務の進め方や報告義務を契約書に明記することで発注者側のリスクは十分にコントロールできます。責任の性質が異なるだけで、一方的に不利という単純な話ではありません。
誤解3：契約書の雛形は業界共通で毎回同じでよい。実際には、成果物の定義や知的財産権の帰属、変更管理の条件は案件ごとに異なるため、雛形をそのまま使い回すと、後になって「誰が何をどこまで負うのか」が曖昧なまま進んでしまうリスクがあります。
Why AI/DX
なぜAI・DX開発では準委任契約が使われやすいのか？アジャイル開発と偽装請負リスク
AI・DX開発は、市場やユーザーの反応を見ながら要件を固めていくアジャイル的な進め方が向いており、開発前に成果物を完全に確定させることが難しいケースが多くあります。IPA（独立行政法人情報処理推進機構）が公表するアジャイル開発版モデル契約書でも、あらかじめ成果物を確定させるウォーターフォール型の請負契約ではなく、ベンダーの業務遂行そのものに対価を払う準委任契約を前提とすることが明記されています。実際に当社のコーポレートサイトも、Claude CodeのようなAIコーディングツールを使い、デザイン調整から記事投稿の仕組みまで、短いサイクルで検証と改善を繰り返しながら構築しています。こうした開発スタイルには準委任契約がなじみやすいと感じています。
ただし、常駐型で準委任契約を結ぶ場合には「偽装請負」のリスクにも注意が必要です。発注者側がベンダーの担当者に直接指揮命令を行ってしまうと、労働者派遣法上の問題に発展する可能性があります。IPAのモデル契約書でも、厚生労働省の疑義応答集（37号告示関連）を参考に、指揮命令系統を明確にしておくことの重要性が示されています。
準委任契約の「成果完成型」と「履行割合型」
2020年4月に施行された改正民法で、準委任契約の報酬の決め方は2つに整理されました。
| 履行割合型 | 成果完成型 | |
|---|---|---|
| 報酬の基準 | 働いた時間や工数 | できあがった成果物の引き渡し |
| よく使う場面 | 要件が固まっていない開発・PoC | 調査レポートや検証結果など、形のあるものを納める場合 |
| 完成させる義務 | なし | なし（請負とはここが違う） |
成果完成型は請負契約に似ていますが、受ける側に「完成させる義務」はありません。途中で契約が終わった場合も、それまでの作業で発注側が得た利益の割合に応じて報酬を払います（民法648条の2）。成果物に欠陥があったときに修補などを求められる「契約不適合責任」も、請負と違って当然には付きません。必要なら契約書に書き込みます。
発注側の判断の目安：何を作るかがまだ決まっていない段階は履行割合型、納めるものがはっきり決まっている段階は成果完成型か請負、と使い分けます。
Process
契約書チェック時に見るべき必須項目【チェックリスト】
- 成果物の定義：請負契約では、何をもって「完成」とするかを具体的に定義する。準委任契約では成果物ではなく、実施すべき業務内容とその範囲を明記する。
- 検収基準：請負契約では検収の合否判定基準・期間を明記する。準委任契約では業務報告の頻度・方法を代わりに定める。
- 知的財産権（IP）の帰属：開発した成果物やソースコードの著作権・利用権がどちらに帰属するかを、契約類型にかかわらず必ず確認する。
- 変更管理プロセス：仕様変更が生じた際の追加費用・スケジュール調整のルールを事前に定めておく。特に準委任契約では変更が発生しやすいため、変更管理のプロセスをより丁寧に記載する必要がある。
Comparison
請負・準委任・自社サービスを比較する
| 契約形態・発注パターン | 特徴 |
|---|---|
| 請負契約（一般的な受託開発） | 成果物の完成責任・契約不適合責任がある。要件が固まった開発に向くが、途中の仕様変更には追加契約が必要になりやすい。 |
| 準委任契約（一般的な受託開発） | 業務遂行そのものに対価が発生し、成果物の完成責任は原則負わない。要件が流動的なアジャイル開発に向くが、発注者側にも進行管理への一定の関与が求められる。 |
| オプティソースのAIプロダクト開発（フェーズ別契約設計） | PoC・MVP段階は準委任契約で仮説検証を柔軟に進め、要件が固まった本開発フェーズでは請負契約に切り替えるなど、フェーズに応じた契約設計を行う。契約の切り替えには双方の合意形成が必要になる分、初回の契約設計に相応の対話時間がかかる。 |
Checklist
システム開発の契約でもめる3つの場面｜発注側が契約前に決めておくこと
契約書の項目を押さえても、実際のシステム開発では同じ場所でもめます。契約類型を選ぶ話とは別に、システム開発の契約を結ぶ前に決めておくと後で揉めにくい点が3つあります。
- 途中で出てきた要望を、誰がいつ判断するか：システム開発では、作り始めてから「この項目も足したい」が必ず出ます。請負契約なら追加は原則として変更契約と再見積の対象、準委任契約なら決められた時間の中で優先順位を入れ替える形になります。どちらにしても、その場で判断できる担当者を発注側に1人決めておかないと、開発が止まったまま日程だけが延びます。
- 何をもって「終わり」とするか：請負契約は完成したものを引き渡す約束なので検収の基準が要ります。一方、準委任契約は完成そのものを約束しないため、検収ではなく作業の報告で確認します。ここを取り違えたまま進むと、発注側は「まだ終わっていない」、受注側は「契約どおり働いた」と、双方が正しいことを言い合う状態になります。
- 作った後に誰が直せるか：システム開発の契約は、たいてい開発までで終わります。保守が別契約であること自体は普通ですが、ソースコードや動かしている環境の引き渡し範囲を決めていないと、他社に乗り換えられないまま毎年の保守費を払い続けることになります。契約前に「この開発が終わった時点で、自社の手元に何が残るか」を一度書き出して確認してください。
いずれも、契約書の文面より先に発注側で決めておく話です。ここが決まっていれば、請負と準委任のどちらを選んでも大きな事故にはなりにくくなります。
FAQ
受託開発の契約形態に関するよくある質問
請負と準委任、どちらが安いですか？
契約類型自体が価格の高低を決めるわけではありません。準委任契約は稼働時間に応じた課金になりやすく、請負契約は成果物の規模・難易度に応じた見積りになりやすいという違いはありますが、最終的な費用は開発範囲やベンダーの体制によって変わります。
開発の途中で契約形態を変更できますか？
可能です。特にPoC・MVP段階を準委任で進め、要件が固まった段階で請負契約に切り替えるケースはよくあります。ただし契約の切り替えには双方の合意と契約書の再締結が必要になるため、事前にどのタイミングで切り替えるかを話し合っておくとスムーズです。
見積書の段階で請負か準委任かは分かりますか？
見積書に契約類型が明記されていない場合もあるため、見積り依頼の際に「この見積りは請負契約を前提としているか、準委任契約を前提としているか」を確認することをおすすめします。前提が異なると、金額の比較自体が難しくなります。
社内にエンジニアがいなくても、契約類型を判断して発注できますか？
問題ありません。案件の要件がどの程度固まっているか、開発の進め方がウォーターフォール型かアジャイル型かをヒアリングした上で、適した契約類型をご提案することが可能です。契約書の項目チェックも含めてご相談いただけます。
受託開発は発注のビジネスモデル、請負・準委任はその中で選ぶ契約類型という整理をしておくと、契約書の内容を読み解く際の混乱が減ります。特にAI・DX開発では要件が事前に固まりにくいため、開発フェーズに応じて契約類型を切り替える設計が有効です。契約形態の選び方に迷う場合は、案件の進め方を整理する段階からご相談ください。なお、受託開発全体の費用相場や発注プロセスについては「AI受託開発とは？費用相場・発注プロセス・失敗しないベンダー選びを内製化と比較して解説」もあわせてご覧ください。
