システム開発の請負契約と準委任契約の違いと選び方｜発注者のためのリスク判断ガイド
システム開発を外注しようとすると、必ずといっていいほど「請負か準委任か」という選択を迫られます。ベンダーから「今回のプロジェクトは準委任で進めましょう」と提案されたとき、その意味やリスクをすぐに判断できる発注者はどれほどいるでしょうか。
「請負のほうが成果物が保証されて安心では？」「準委任だとコストが膨らむのでは？」と感じながらも、ベンダーの提案をそのまま受け入れてしまうケースは少なくありません。しかしこの判断が、プロジェクトの費用・品質・納期に直結するリスクの所在を左右します。
法律サイトや弁護士監修の解説記事を読むと、「請負は成果物を完成させる義務がある」「準委任は業務の遂行自体が目的」という制度の違いは分かります。ところが「それを踏まえて自社はどちらを選ぶべきか」という判断フレームワークはなかなか見つかりません。
本記事では、契約形態の制度解説にとどまらず、発注者の視点から「プロジェクトの特性に合った契約形態をどう選ぶか」を解説します。リスク分担の整理・選定フロー・フェーズ別の使い分け・契約書のチェックポイントまで網羅しているので、ぜひ次の発注判断の材料にしてください。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
こんな方におすすめです
請負契約・準委任契約とは？法的な基本の違い
まず、両者の法的な定義を簡単に確認しておきます。
請負契約は、民法第632条に定められた「ある仕事を完成させることを約束し、その結果に対して報酬を支払う」契約です。成果物の完成が報酬発生の前提となります。
準委任契約は、民法第656条・第643条に基づく「一定の業務の遂行を委託する」契約です。業務の遂行プロセス自体が目的であり、成果物の完成は必須ではありません。
比較項目 |
請負契約 |
準委任契約 |
|---|---|---|
目的 |
成果物の完成 |
業務の遂行 |
報酬の発生条件 |
成果物の完成・納品後 |
業務の遂行（時間・工数ベース） |
成果物の完成義務 |
あり |
なし |
契約不適合責任（旧: 瑕疵担保責任） |
あり |
なし |
中途解除 |
原則として発注者都合の解除は損害賠償が生じる |
双方が比較的柔軟に解除可能 |
なお、「ラボ型開発」「SES（システムエンジニアリングサービス）」は別の開発体制モデルであり、契約形態の分類とは異なります。開発体制モデルの比較についてはシステム開発の外注形態（ラボ型・SES・請負）の違いを参照してください。
発注者にとってのリスク分担マトリクス
制度の違いよりも重要なのは、「どちらの契約を選ぶとリスクが誰に帰属するか」という視点です。費用・品質・納期の3観点でリスクの所在を整理します。
費用リスク（予算超過の可能性）
請負契約の場合: 契約時に合意した金額が原則として固定されます。開発途中での仕様変更がなければ、追加費用は発生しません。ただし、仕様変更が発生した場合は変更管理手続きを経て費用が増加します。
準委任契約の場合: 月間工数×単価のような時間単価モデルが多く、開発が長引けばそのまま費用が増加します。要件変更・試行錯誤が多いプロジェクトほど、費用超過リスクが発注者側に集中します。
判断のポイント: 要件が確定していて仕様変更が少ないなら請負が費用リスクを抑制できます。逆に探索が必要なフェーズでは、請負にすると変更管理コストが膨らみかねないため、準委任のほうが実態に合っていることが多いです。
品質リスク（成果物が使えない場合）
請負契約の場合: 2020年の民法改正により「瑕疵担保責任」が「契約不適合責任」へと変更されました（民法改正の詳細はIPAの公式資料を参照）。契約で合意した仕様を満たさない場合、発注者は修補請求・代金減額請求・損害賠償請求が可能です。権利行使期間は「不適合を知ったときから1年以内」が原則です。
準委任契約の場合: 成果物の完成義務がないため、原則として品質保証は適用されません。ただし「善管注意義務（善良な管理者の注意義務）」により、専門家として相当の注意を払って業務を遂行する責任はあります。
判断のポイント: 納品物の品質を明確に定義でき、検収基準を事前に合意できる案件は請負が向いています。成果物の品質を事前定義できない探索フェーズでは、準委任での進行が現実的です。
納期リスク（開発が終わらない場合）
請負契約の場合: 納期は契約の重要な条件となるため、未達の場合は受託者の責任となります。遅延損害金の設定や契約解除も可能です。
準委任契約の場合: 納期の概念が薄く、進捗管理は実質的に発注者の責任になります。「エンジニアに対してこの順番で作業してほしい」「今週中にこの機能を仕上げてほしい」という直接指示は、労働者性が問われる「偽装請負」のリスクにつながりかねないため注意が必要です。
判断のポイント: 期限が厳しく、納期を契約で縛りたい場合は請負が適切です。準委任を選ぶ場合は、報告義務・マイルストーン設定・予算上限を契約書に明記することが重要です。
プロジェクト特性別・契約形態選定フロー
リスクの所在を理解した上で、自社プロジェクトの特性から契約形態を選定します。
要件が確定している → 請負が基本
以下の条件が揃っていれば、請負契約が適切です。
- 開発前に仕様書・画面設計書を渡せる状態になっている
- 参考にできる既存システムや事例がある
- 「何を作るか」についてベンダーと合意できている
- 開発中の仕様変更はほぼないと言い切れる
- 成果物の検収基準（機能一覧・テスト仕様書）を事前に定義できる
具体的な例としては、既存業務フローの一部システム化・外部APIとの連携開発・既存システムのリプレース（要件が明確な場合）などが該当します。
要件が不明確・探索が必要 → 準委任が基本
以下の条件に当てはまれば、準委任契約が適切です。
- 「何を作るか」を決めるところから一緒にやってほしい
- 要件定義・PoC・プロトタイプ制作の段階にある
- アジャイル開発を採用し、仕様を柔軟に変更しながら進めたい
- 新規サービス・AIシステムなど、要件が技術検証と並走して変わる
新規SaaS立ち上げ・DXプロジェクトの初期フェーズ・社内業務のデジタル化（業務フロー自体を整理しながら進める）などが典型例です。
迷ったときの5項目チェックリスト
判断に迷う場合は、以下の5項目で自己診断してください。「YES」が3つ以上なら請負、2つ以下なら準委任が適切である可能性が高いです。
- 仕様書・要件定義書を渡せばすぐ開発着手できる状態か
- 成果物の品質基準（検収条件）を事前に文書化できるか
- 開発中の仕様変更はほぼないと言い切れるか
- 納期を事前に確定できるか
- 社内に準委任の場合の進捗管理を担える担当者がいるか（準委任選択時の必須条件）
フェーズ別の使い分け実践例
実際のプロジェクトでは、「全工程を一つの契約形態で通す」よりも、フェーズごとに契約形態を切り替えることが最善解になるケースが多くあります。
要件定義・PoC → 準委任
要件が固まっていないフェーズでは準委任契約が適切です。「この段階で何を完成させるか」が不確定なため、請負では成果物・検収条件を定義しづらいためです。
注意点: 準委任で進める際は、以下を契約書に明記することが重要です。
- 期間・工数・予算の上限
- 終了基準（何をもって要件定義完了とするか）
- 成果物の定義（設計書・議事録など中間成果物も含める）
基本設計〜詳細設計 → 準委任または請負
設計書を成果物として定義できれば、請負契約も可能なフェーズです。
判断基準: 「設計書の品質基準と検収条件を事前に合意できるか」が分かれ目です。例えば「画面設計書・ER図・API仕様書を成果物として、所定のレビューで承認されれば検収」という合意ができれば請負で進めることができます。
実装・テスト → 請負
仕様が確定した後の実装フェーズでは、請負契約が適切です。動作するシステムという成果物を明確化でき、テスト仕様書に基づく検収が可能になります。
注意点: 検収条件を詳細に定義することが重要です。機能一覧・テスト仕様書・受入基準（パフォーマンス要件・セキュリティ要件など）を事前に合意しておくことで、「完成の基準」を巡るトラブルを防ぐことができます。
保守・運用 → 準委任（SLA付き）
リリース後の保守・運用フェーズでは、障害対応や機能改善が継続的に発生するため、準委任契約が一般的です。ただし、品質水準を担保するためにSLA（サービスレベルアグリーメント）の設定が重要です。
SLAに明記すべき項目の例:
- 障害発生時の応答時間（例: 重大障害は1時間以内に初動対応）
- 復旧目標時間（RTO）・復旧目標時点（RPO）
- 定期メンテナンスの実施条件と事前通知期間
契約締結時の重要チェックポイント
どちらの契約形態を選んでも、契約書の内容が不明確だとトラブルの原因になります。締結前に必ず確認すべきポイントをまとめます。
請負契約のチェックポイント
1. 検収条件の明確化 最も重要な項目です。「何をもって完成とするか」を、機能一覧・テスト仕様書・受入基準のレベルで具体的に定義してください。「発注者が承認したとき」のような曖昧な表現は、後々の紛争の原因になります。
2. 契約不適合責任の範囲と期間 2020年の民法改正後は、「契約で合意した仕様を満たさない」ことが責任の発生要件です（BUSINESS LAWYERS: システム開発における契約不適合責任）。責任を問える期間・対象となるバグの種類・免責事項を契約書で確認してください。
3. 中途解除条件 ベンダー都合・発注者都合それぞれの解除条件と、解除時の清算ルール（既払い額の返還・完成部分の費用按分など）を明確にしておくことで、途中でトラブルが発生したときの出口戦略を持てます。
4. 仕様変更手続き 請負契約中に仕様変更が発生した場合の、変更指示書の書式・追加費用の算定方法・承認フローを定めておいてください。口頭での変更指示は後で「合意していない」と言われるリスクがあります。
準委任契約のチェックポイント
1. 報告義務の設定 進捗が見えにくくなりがちな準委任契約では、報告義務を契約に明記することが重要です。「週1回のオンライン報告 + 週次議事録の提出」のように、頻度・形式・手段を具体的に定めてください。
2. 工数上限・予算上限 「最大○人月まで」「月額上限○○万円まで」という上限を設定し、超過見込みが出た時点で事前報告を義務付けることで、青天井の費用増加を防ぐことができます。
3. 成果物の定義 準委任契約でも「業務の遂行」に加えて、中間成果物（設計書・議事録・レポート）を契約書に定義しておくことを強くお勧めします。成果物を定義しておくことで、進捗の可視化と品質確認が可能になります。
4. 解除条件 品質不満・著しい進捗遅延が続いた場合の解除手順と精算方法を明記してください。準委任は発注者側から比較的柔軟に解除できますが、精算方法を事前合意しておかないと費用トラブルに発展することがあります。
まとめ
請負契約と準委任契約の選択は、「どちらが安全か」という二項対立ではなく、プロジェクトの特性に合った契約形態を選ぶという視点が重要です。
選択の際は、以下の3点を意識してください。
- 要件が固まっているかどうかで基本方針を決める: 仕様確定済みなら請負、探索・試行錯誤が必要なフェーズは準委任が基本です
- フェーズ別に切り替えることも選択肢に入れる: 要件定義は準委任、実装は請負というように、工程ごとに最適な契約形態を選ぶことが実務の最善解になるケースも多くあります
- どちらを選んでも契約書のチェックポイントを押さえる: 検収条件・責任範囲・報告義務・解除条件を明確にすることが、トラブルを防ぐ最大の対策です
秋霜堂株式会社では、要件が固まっていない構想段階からシステム開発の伴走支援を行っています。「請負か準委任か迷っている」「プロジェクトの進め方から相談したい」という方は、まずはお気軽にご相談ください。
システム開発 完全チェックリスト――発注前・発注中・完了後の3フェーズで使えるチェック集
この資料でわかること
こんな方におすすめです
作業時間削減
システム化を通して時間を生み出し、ビジネスの加速をサポートします。
システム開発が可能に
