LASSIC Media らしくメディア
システム開発の準委任契約と請負契約の違い｜責任・費用・向くケースを解説
LASSIC IT事業部｜元請（プライムベンダー）としてシステム開発・保守・運用を受託
この記事のポイント
- 準委任契約は「作業プロセスへの報酬」、請負契約は「成果物の完成に対する報酬」という根本的な違いがあります
- 契約不適合責任は請負にのみ適用され、準委任では発注側が仕様リスクを持ちます
- 要件定義・基本設計には準委任、詳細設計・開発・受入テストには請負が多く選ばれますが、工程特性と自社のリスク許容度で選択することが大切です
目次
準委任契約と請負契約の定義
準委任契約と請負契約の違いとは、ひと言でいえば「何に対して報酬を支払うか」という義務の性質の違いです。請負は成果物の完成を約束する契約であり、準委任は専門的な作業の遂行を約束する契約です。システム開発で契約類型を誤ると、責任の所在や費用の追加発生について認識のずれが生じ、紛争につながるケースがあります。
請負契約とは（民法第632条）
請負契約は、民法第632条に「当事者の一方がある仕事を完成することを約し、相手方がその仕事の結果に対してその報酬を支払うことを約することによって、その効力を生ずる」と定義されています。
システム開発に置き換えると、ベンダーが「このシステムを完成させる」と約束し、発注側が「完成したら代金を払う」という構造です。成果物（完成したシステム）が存在することが報酬発生の前提となります。
完成の義務を負うことから、ベンダーは仕様に対して責任を持ちます。後述する契約不適合責任（民法第562条〜）が適用され、納品物が仕様を満たさない場合には修補・代替・代金減額・損害賠償を求められます。
委任・準委任契約とは（民法第643条・第656条）
委任契約は民法第643条に「当事者の一方が法律行為をすることを相手方に委託し、相手方がこれを承諾することによって、その効力を生ずる」と定めています。弁護士への法律事務の委託が典型例です。
これに対して準委任契約は民法第656条に「この節の規定は、法律行為でない事務の委託について準用する」と定められています。システム開発における要件定義・設計作業・コンサルティングなど、法律行為ではない専門的業務の委託がこれにあたります。
準委任では「成果物を完成させる」義務は負いません。受任者（ベンダー）は善良な管理者の注意義務（善管注意義務）をもって作業を遂行する義務を負います。作業の遂行自体が契約の中身であり、成果物の完成が保証されているわけではありません。
責任・リスクの違い — 契約不適合責任と仕様変更
契約類型を選ぶ上で最も重要な論点の一つが、責任の所在です。請負と準委任では、納品物に問題が生じたときに誰が責任を負うかが根本的に異なります。
請負の契約不適合責任（民法第562条〜）
請負契約では、民法第562条（買主の追完請求権）が準用される形で、「引き渡された目的物が種類、品質又は数量に関して契約の内容に適合しないものであるとき」に発注側は修補・代替物引渡しなどを請求できます。この責任を契約不適合責任といいます（2020年の民法改正前は「瑕疵担保責任」と呼ばれていました）。
システム開発における請負では、仕様書どおりに動作しない場合や、約束した機能が実装されていない場合に、ベンダーは無償での修補に応じる義務を負います。発注側にとっては成果物に対して一定の保証を得られるメリットがあります。
ただし、この責任が機能するためには仕様が明確に合意されていることが前提です。仕様書が曖昧な場合や、開発途中に頻繁に仕様変更が入る場合は、「契約の内容に適合しない」かどうかの判断が難しくなり、紛争になることがあります。
準委任に契約不適合責任は適用されない
準委任契約では、ベンダーは「成果物の完成」を約束していないため、契約不適合責任は適用されません。ベンダーが善管注意義務を果たした上で作業を遂行した場合、期待していた成果物が得られなくても責任を問いにくい場面があります。
これは発注側にとってリスクです。要件が固まっていない段階で準委任を選ぶことは合理的ですが、成果物の品質基準・完了条件をあらかじめ契約書に明記しておかないと、「期待どおりの成果が得られなかった」という認識のずれが生じやすくなります。
IPAが公表している「情報システム・モデル取引・契約書」第二版（2020年公表・2025年4月更新）でも、準委任契約における成果物・完了条件の定義方法が整理されており、実務の参考になります。
| 比較項目 | 請負契約 | 準委任契約 |
|---|---|---|
| 根拠条文 | 民法第632条 | 民法第656条（643条準用） |
| 義務の中心 | 成果物の完成（仕事完成義務） | 作業の遂行（善管注意義務） |
| 契約不適合責任 | あり（民法562条〜） | なし |
| 報酬の発生 | 原則として完成時払い | 履行割合型または成果報酬型（民法648条・648条の2） |
| 仕様変更の影響 | 変更に対して追加費用・工期交渉が必要 | 変更に柔軟に対応しやすいが、作業量増加は費用増につながる |
| 典型的な場面 | 仕様確定後の開発・テスト工程 | 要件定義・基本設計・技術コンサルティング |
報酬の発生条件 — 完成払いか月次払いか
契約形態の違いは、費用の発生タイミングにも直結します。発注側の予算計画と資金繰りにも影響するため、契約締結前に理解しておく必要があります。
請負の完成払い原則
請負契約では成果物の完成が報酬発生の条件です。民法第632条の「仕事の結果に対して報酬を支払う」という定義がその根拠です。原則として、システムが完成して納品されるまで報酬を支払う必要はありません。
ただし実務では、長期プロジェクトに備えて「基本設計完了時に30%、詳細設計完了時に30%、納品時に40%」のようにマイルストーン払いを契約書で定めることが一般的です。この場合でも、各マイルストーンの成果物が合意の要件を満たすことが支払条件になります。
準委任の履行割合型・成果報酬型（民法第648条・第648条の2）
準委任契約の報酬は、民法第648条に「委任事務を履行した後でなければ、これを請求することができない」と定められています。ここでの「履行」とは作業の遂行自体であり、毎月の作業工数に応じた月次払い（履行割合型）が最も多く使われます。
2020年の民法改正（令和2年4月1日施行）では、民法第648条の2として成果報酬型の準委任が明文化されました。「委任事務の履行により得られる成果に対して報酬を支払うことを約した場合」に、成果物引渡しと同時に報酬を支払う形態です。これにより、準委任であっても成果物に応じた報酬設計が法文上も認められています。
発注側の視点では、成果報酬型の準委任は請負に近い形で成果物の担保が得られる一方、完了条件の定義が甘いとベンダーとの解釈の違いが生じます。契約書での完了定義の明確化が実務上の重要課題です。
工程別の使い分け — 上流は準委任、開発・テストは請負が多い理由
どちらの契約が適切かは、作業の性質・仕様の確定度・リスクの許容範囲の3点で判断します。実務では工程ごとに契約形態を切り替えるのが一般的です。
要件定義・基本設計で準委任が向く理由
要件定義フェーズは、「何を作るか」をまだ明確化している最中です。この段階では成果物の仕様が確定していないため、請負契約を締結すると「完成の基準が何か」を巡る紛争が起きやすくなります。
準委任であれば、「〇週間・〇人月分の要件定義作業を実施する」という作業内容を合意することで契約が成立します。作業の途中で顧客要望が変わっても、追加工数分を合意の上で費用計上できます。発注側も「要件が変わるかもしれない」という現実に沿った進め方が可能です。
基本設計（外部設計）も同様の理由で準委任が選ばれることが多くあります。画面・機能の概要を決める工程は、業務要件の整理と並行して進むため、完成物の定義が難しい場面があります。
詳細設計・開発・受入テストで請負が向く理由
詳細設計（内部設計）以降は、画面仕様・API仕様・データ定義が確定している段階です。「この仕様書どおりのシステムを構築する」という合意が成立するため、請負契約が機能しやすくなります。
受入テスト（UAT）では、発注側が設定したテストケースを全てパスすることを完成条件として明記できます。契約不適合責任も働くため、発注側はテスト不合格の修補を請求できます。
ただし、開発フェーズでの請負を成功させるには、仕様変更管理プロセス（変更管理票・承認フロー）を契約書または別紙で定めておくことが重要です。仕様変更が追加費用の交渉なしに行われ続けると、ベンダー側の負担が増大し、品質低下や納期遅延につながるリスクがあります。
IPAモデル取引・契約書の考え方
IPA「情報システム・モデル取引・契約書」第二版（2020年12月公表・2025年4月更新）では、システム開発の各工程に応じた契約形態の選択と、成果物・完了条件の定め方の雛形が示されています。
同書では、要件定義工程を発注側が主体的に関与する形で準委任として位置づけ、開発・テスト工程は請負を基本としながら、仕様変更管理の条項を整備することを推奨しています。また、成果報酬型準委任（民法648条の2）の適用場面についても整理されており、契約書作成時の実務的な参考資料となっています。
発注側が陥りやすい3つの落とし穴
契約類型の知識があっても、実務で運用を誤ると想定外のリスクが顕在化します。過去のシステム開発トラブル事例の類型から、発注側が特に注意すべき3点を整理します。
準委任での仕様変更コストの増大
準委任は仕様変更に柔軟に対応できる半面、変更のたびに追加工数が発生します。「変更しやすいから」という理由で全工程を準委任にすると、最終的な費用が当初見積もりを大幅に超えるケースがあります。
対策として、各月・各スプリントの作業内容と工数を記録し、進捗確認と費用消化の透明性を保つことが重要です。ベンダーとの間で月次の報告体制（作業報告書・工数実績の共有）を契約書に明記しておくと、費用のコントロールがしやすくなります。
請負での契約不適合責任を巡るトラブル
請負で契約不適合責任が適用されるためには、「仕様書どおりに動作しない」ことが証明できる必要があります。しかし仕様書が曖昧だったり、開発途中で口頭の変更が重なったりすると、「契約不適合かどうか」の判断が困難になります。
こうした場合、ベンダーは「仕様変更に対応したため、元の仕様書は既に変更されている」と主張し、発注側は「口頭でのやり取りは変更合意ではない」と主張する、という認識の対立が生じます。仕様変更は書面（変更管理票・合意議事録）で双方が合意した上で進めることが、請負契約を適切に運用するための前提です。
偽装請負リスクと指揮命令系統
準委任契約を締結しているにもかかわらず、発注側がベンダーのエンジニアに対して直接作業指示を出す状況は、偽装請負に該当するリスクがあります。準委任（および請負）では、業務の指揮命令権はベンダー側にあります。発注側が常駐エンジニアに「今日はこの作業を優先してほしい」と直接指示することは、労働者派遣法の観点から問題になる場合があります。
準委任・請負と人材派遣の違いについては別途確認をお勧めします。
まとめ — 契約選択の3つの判断軸
本稿では、システム開発における準委任契約と請負契約の違いについて、民法条文・IPA資料を踏まえて整理しました。要点を3点に集約します。
第一に、義務の性質が異なります。請負は成果物の完成を約束し（民法第632条）、準委任は専門的な作業の遂行を約束します（民法第656条）。どちらが「良い」という話ではなく、工程の性質に合わせて選ぶものです。
第二に、責任とリスクの分担が変わります。請負では契約不適合責任（民法第562条〜）によりベンダーが成果物品質を保証しますが、そのぶん仕様の確定と変更管理が重要になります。準委任では発注側が成果の方向性を握りますが、完了条件・作業報告の仕組みを自ら設計する必要があります。
第三に、工程別に使い分けることが実務的な解です。要件定義・基本設計は準委任、詳細設計・開発・受入テストは請負という組み合わせが多く、IPAモデル契約書もこの考え方に沿っています。ただし、自社の体制・リスク許容度・ベンダーとの関係性によって最適解は異なります。
よくある質問
準委任契約と請負契約は、どちらが発注側にとって有利ですか？
一概にどちらが有利とは言えません。成果物の品質保証（契約不適合責任）を重視するなら請負が有利ですが、仕様が固まっていない段階では請負の「完成義務」が逆にトラブルの元になります。準委任は柔軟に進められますが、作業量に応じた費用が積み上がるリスクがあります。工程の特性と自社の管理体制に応じて選択することが大切です。
準委任契約でも成果物の品質を担保できますか？
あります。契約書または別紙に「作業完了の定義（受入基準・納品物一覧）」を明記することが有効です。また、2020年の民法改正で成果報酬型準委任（民法第648条の2）が法文化されており、成果物の引き渡しを報酬発生の条件とすることもできます。IPAの「情報システム・モデル取引・契約書」第二版では、準委任での完了条件の定め方の雛形が参考になります。
システム開発で「準委任＋請負」のように工程によって契約を分けることはできますか？
できます。むしろ実務では工程ごとに契約形態を変えるのが一般的です。要件定義・基本設計は準委任で進め、仕様が確定した詳細設計以降を請負で締結する方法が広く採用されています。各フェーズの開始時に別契約（または契約書の追補）を締結することで、それぞれの工程に適した責任構造を設定できます。
準委任契約で途中解約した場合、費用はどうなりますか？
民法第648条第3項の規定により、受任者（ベンダー）は既に遂行した作業部分の報酬を請求できます。月次払いの準委任であれば、解約月の作業実績に応じた費用の支払いが発生します。契約書に解約予告期間（例：1か月前通知）や精算方法を明記しておくと、解約時のトラブルを予防できます。
請負契約で仕様変更が発生した場合、追加費用はどう扱いますか？
請負契約では、当初合意した仕様の範囲外の作業が発生した場合、原則として追加費用の交渉が必要です。変更管理票（変更要求書）をベンダーと発注側の双方が合意した上で、費用・工期への影響を確認してから作業を進めることが大切です。口頭だけで仕様変更を重ねると、契約不適合責任の判断が難しくなり、完成時のトラブルにつながることがあります。
著者：テレリモ総研編集部 鈴木 亮佑
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：民法第632条（請負の定義）「Wikibooks 民法第632条」（e-Gov法令検索と同一条文）
- *2 出典：民法第643条（委任の定義）「Wikibooks 民法第643条」
- *3 出典：民法第656条（準委任の定義）「Wikibooks 民法第656条」
- *4 出典：民法第562条（買主の追完請求権）「Wikibooks 民法第562条」（2017年民法改正により新設）
- *5 出典：民法第648条（受任者の報酬）・第648条の2（成果等に対する報酬）「Wikibooks 民法第648条」（648条の2は2020年施行民法改正で新設）
- *6 出典：IPA「情報システム・モデル取引・契約書 第二版」（2020年12月公表・2025年4月更新）
