記事一覧に戻る

準委任契約と請負契約の違いとは?システム開発の契約形態を発注者目線で解説

準委任契約と請負契約は「成果物の完成責任を負うかどうか」が決定的に異なります。システム開発でどちらを選ぶべきか、責任・報酬・変更対応の違い、向くケースと注意点を発注者目線で実務的に解説します。

2026/6/24
10分

準委任契約と請負契約の最大の違いは、「成果物の完成責任を負うかどうか」です。請負は「完成したものを納める」ことを約束する契約、準委任は「専門性をもって業務を遂行する」ことを約束する契約で、この違いがシステム開発の進め方・リスク・費用すべてに影響します。

「開発を外注したいが、どの契約形態が自社に合うのか分からない」——契約形態の選択は、プロジェクトの柔軟性とリスク配分を左右する重要な意思決定です。本記事では、準委任契約と請負契約の違いを発注者の目線で整理し、どちらを選ぶべきかの判断基準までを解説します。

準委任契約とは

準委任契約とは、特定の業務(事務処理)を遂行することを約束する契約です。法律上は民法の「委任」に準じる契約で、受託者は「善良な管理者の注意義務(善管注意義務)」をもって業務にあたりますが、成果物の完成そのものは約束しません

システム開発では、要件が固まりきっていない段階での開発、継続的な改修・運用、PoC(概念実証)などで多く用いられます。月額の専属チームで進めるラボ型開発も、契約上は準委任に該当するのが一般的です。

なお2020年の民法改正で「成果完成型の準委任」も明文化されましたが、本記事では実務で主流の「履行割合型(稼働に対して報酬を支払う形)」を前提に解説します。

請負契約とは

請負契約とは、仕事を完成させることを約束し、その完成に対して報酬を支払う契約です。受託者は成果物を完成させる義務を負い、納品物に不具合があれば「契約不適合責任(旧・瑕疵担保責任)」を負います。

「作るものが明確に決まっている」「仕様が固まっている」単発のシステム開発に向きます。一方、完成責任を負う以上、受託側はリスクを見積りに織り込むため、仕様変更には再見積りが必要になりやすいのが特徴です。

準委任契約と請負契約の違い(比較表)

両者の違いを、発注者が押さえるべき観点で整理します。

比較軸準委任契約請負契約
契約の対象業務の遂行(専門性・稼働の提供)仕事の完成(成果物の納品)
成果物の完成責任負わない(善管注意義務)負う
契約不適合責任原則なしあり
仕様の固まり具合未確定でも着手できる事前に確定が必要
仕様変更への対応柔軟(優先度の組み替えが容易)再見積りが必要になりやすい
報酬の考え方稼働・期間に対して(月額など)成果物単位の総額
コスト変動リスク発注側が負いやすい受注側が負いやすい
向くケース要件が動く開発・継続的な改善仕様が固い単発開発

ポイントは、リスクを誰が負うかです。請負は受注側が完成リスクを負う代わりに費用にバッファが乗りがちで、変更に弱い。準委任は柔軟だが、発注側が進め方をコントロールする関与が求められます。

それぞれのメリット・デメリット

準委任のメリットは、仕様が固まっていなくても始められ、状況に応じて優先順位を変えられること。デメリットは、完成を契約で縛れないため、進捗管理を発注側も意識する必要がある点です。対策として、月次でゴールとアウトプットを定義し、デモベースで進捗を確認する運用が有効です。

請負のメリットは、完成責任が受注側にあり、発注側の管理負担が比較的軽いこと。デメリットは、仕様確定が前提のため、要件が動くプロジェクトでは変更のたびにコストと時間がかさむことです。

どちらを選ぶべきか

判断の軸はシンプルで、「作るものが、今どれだけ固まっているか」です。

  • 請負が向くケース:仕様書レベルで要件が確定しており、変更が想定されない単発開発(例:既存仕様の置き換え、定型的な機能追加)。
  • 準委任が向くケース:要件がこれから固まる、AI・DXのように実現性を試しながら進める、リリース後も継続的に改善したい——こうした「変化が前提」のプロジェクト。

AI・業務システム開発の多くは後者に当てはまります。要件もコストも見えない段階から相談したい場合は、準委任での進め方が現実的です。発注前の費用感は業務システム・AI開発の外注費用、会社選びの観点はAI・システム開発会社の選び方も参考にしてください。

SnapBuildが準委任型を採用している理由

SnapBuildは、月単位の業務委託(準委任型)を基本としています。これは、お客様の多くが「何を作るべきか」が固まっていない段階からのご相談で、一括請負では相性が悪いためです。

準委任なら、要件整理そのものをチームと一緒に進められ、毎月の優先順位を事業状況に合わせて柔軟に組み替えられます。PoC(概念実証)から本開発、運用改善までを同じチームで一気通貫に伴走できるのも、この契約形態だからこそです。実現性を小さく試したい段階の進め方はAI PoCの進め方と費用にまとめています。

契約時に確認すべきポイント

契約形態を選んだら、契約書で次の点を必ず確認しておきましょう。後のトラブルの多くは、ここの取り決めの曖昧さから生まれます。

  • 業務範囲と善管注意義務の範囲:準委任は「何を遂行するか」を具体的に定める。曖昧だと「やる・やらない」で揉めます。
  • 報告・検収の取り決め:進捗報告の頻度・方法、月次成果物の確認方法を明記する。
  • 知的財産権の帰属:開発した成果物(ソースコード等)の権利が発注側に帰属するかを明確にする。
  • 再委託の可否:受託側が外部に再委託する場合の条件・範囲を確認する。
  • 契約期間と中途解約:更新条件、解約時の通知期間・精算方法を定めておく。

これらは準委任・請負どちらでも重要ですが、特に完成責任を負わない準委任では、報告・検収・成果物の権利の取り決めが実務上の安心材料になります。

まとめ

準委任と請負は「完成責任を負うか」が決定的な違いで、それがリスク配分・費用・変更対応のすべてに表れます。仕様が固いなら請負、変化が前提なら準委任——この軸で選ぶのが基本です。

SnapBuildは、要件が固まっていない段階からのご相談を最も得意としています。「自社のこの開発は、どの契約形態・進め方が合うか」を整理したい方は、お気軽に無料相談(30分)をご利用ください。

関連記事:ラボ型開発とはAI PoCの進め方と費用業務システム・AI開発の外注費用

この記事が参考になりましたか?

AI・システム開発でお困りでしたら、お気軽にご相談ください。専門チームがあなたの課題解決をサポートします。

関連記事

AI PoC(概念実証)とは?進め方の4ステップと費用相場を実務目線で解説
ノウハウ

AI PoC(概念実証)とは?進め方の4ステップと費用相場を実務目線で解説

AI PoC(概念実証)とは、本格開発の前に「効果が出るか・実現できるか」を小さく検証する工程です。進め方の4ステップ、費用相場、失敗しないコツ、月額で小さく始める方法までを、生成AI開発の現場目線で解説します。

2026/6/24
10分
要件定義の進め方|失敗しない手順とRFP(提案依頼書)の書き方を解説
ノウハウ

要件定義の進め方|失敗しない手順とRFP(提案依頼書)の書き方を解説

システム開発の成否は要件定義で決まります。現状業務の整理から要求の引き出し、優先順位づけ、RFP(提案依頼書)の書き方まで、失敗しない要件定義の進め方を発注者目線で実務的に解説します。

2026/6/24
11分
システム開発のサブスク(月額制)とは?仕組み・料金・従来モデルとの違い
経営・戦略

システム開発のサブスク(月額制)とは?仕組み・料金・従来モデルとの違い

システム開発のサブスク(月額制)は、開発リソースを月額で継続利用する購買モデルです。仕組み、料金体系、一括発注(請負)との違い、向いているケースを、発注側の視点で分かりやすく解説します。

2026/6/15
9分