システム開発を外部へ依頼するとき、

「請負契約と準委任契約は何が違うのか」

「システムが完成しなかった場合、どちらが責任を負うのか」

「要件定義・開発・保守はそれぞれどの契約形態が適しているのか」

と迷うことがあります。

システム開発では、契約形態によって、

何に対して報酬を支払うのか

ベンダーが何を約束するのか

仕様変更をどう扱うのか

成果物の完成責任を誰が負うのか

が大きく変わります。

結論から整理すると、

請負契約
=
仕事の完成を約束する契約

準委任契約
=
一定の業務を適切に遂行する契約

という違いがあります。

民法632条では、請負について、一方が仕事を完成することを約し、相手方がその仕事の結果に対して報酬を支払う契約と定めています。国税庁も、請負の特徴を「完成された仕事の結果を目的とする」点にあると説明しています。

一方、準委任は民法656条に基づき、法律行為ではない事務の委託について委任の規定を準用する契約です。システム開発の実務では、要件定義支援・アジャイル開発・保守など、成果物の完成だけでは評価しにくい業務で利用されます。IPAのモデルでも、準委任型ではベンダーが成果物の完成義務を負うのではなく、専門家として善良な管理者の注意をもって業務を遂行する考え方が示されています。

この記事では、請負と準委任の違いを、システム開発の具体例を使いながら解説します。

請負と準委任の違いを一覧で比較

まず全体像を整理します。

項目	請負	準委任
契約の中心	仕事の完成	業務の遂行
完成義務	原則あり	原則なし
報酬	仕事の結果に対して	業務遂行・契約内容に応じて
仕様の確定	比較的重要	変更を織り込みやすい
発注者の関与	比較的少なくできる	継続的な関与が重要
変更への対応	契約変更・追加見積になりやすい	比較的柔軟
向くケース	仕様が明確な開発	要件が変化する業務
例	確定仕様のシステム開発	要件定義・アジャイル・保守

ただし実際の契約では、単純に名称だけで判断できるとは限りません。

契約書のタイトルが、

業務委託契約書

でも、中身が仕事の完成を目的としていれば、実質的に請負として扱われる場合があります。国税庁も、請負は仕事の完成を目的とする契約であると説明しています。

そのため重要なのは、

契約書の名前

より、

実際に何を約束している契約なのか

です。

請負契約とは

請負契約では、受注者が、

決められた仕事を完成させる

ことを約束します。

例えば、

顧客管理システムを
2027年3月31日までに完成させる

という契約です。

完成条件として、

顧客登録

顧客検索

案件管理

対応履歴

CSV出力

などの要件を合意します。

受注者は、その条件を満たすシステムを完成させることが契約の中心になります。

民法上も、請負は「仕事の完成」と「その結果に対する報酬」を基本とする契約です。

請負契約のイメージ

例えば、

発注者：

顧客管理システムを
500万円で開発してください


開発会社：

合意した仕様のシステムを
完成させます

という関係です。

そのため、

予定していたより
開発に時間がかかった

としても、直ちに追加料金を請求できるという話にはなりません。

一方、発注者が途中で、

請求書機能も追加したい

スマホアプリも追加したい

と要求すれば、当初の請負範囲を超えるため、

仕様変更

↓

影響調査

↓

追加見積

↓

契約変更

となる可能性があります。

準委任契約とは

準委任契約では、

成果物を完成させること

そのものではなく、

契約で定めた業務を
適切に遂行すること

が中心になります。

例えば、

月80時間

要件定義・設計・開発支援を行う

という契約です。

IPAの準委任型モデルでは、ベンダーは完成義務を負わない一方、専門知識・ノウハウに基づき、善良な管理者の注意をもって業務を行う義務を負う考え方が示されています。

つまり、

完成義務がない
=
何をしてもよい

という意味ではありません。

契約内容に基づき、専門家として適切に業務を遂行する必要があります。

「準委任なら成果物はない」は正確ではない

準委任について、

成果物が存在しない契約

と理解されることがありますが、これは単純化しすぎです。

例えば準委任で要件定義を行い、

要件定義書

業務フロー

機能一覧

などを作成することはあります。

重要なのは、

成果物があるかどうか

ではなく、

契約上、
特定の仕事を完成させること自体を
義務としているか

です。

また、改正民法を踏まえたIPAのモデル契約では「成果報酬型準委任契約」についても整理されています。したがって、「報酬が成果に連動したら必ず請負」という単純な区別でもありません。

請負契約のメリット

1．発注金額を決めやすい

例えば、

顧客管理システム一式
500万円

と決められます。

要件・仕様が確定していれば、発注者は予算を管理しやすくなります。

2．完成するものが明確

例えば、

F01 顧客登録

F02 顧客検索

F03 案件管理

F04 対応履歴

F05 CSV出力

と定義して契約します。

発注者としては、

契約したシステムが
完成すること

を前提にできます。

3．仕様が明確な開発と相性がよい

例えば、

既存システムと
ほぼ同じ機能で作り直す

仕様書が完成している

画面・帳票がすべて確定

などの場合です。

何を完成させるのか明確であれば、請負契約を利用しやすくなります。

請負契約のデメリット・注意点

1．仕様変更に弱い

例えば開発途中で、

当初：
顧客管理だけ

↓

途中：
案件管理も追加したい

となれば、契約範囲が変わります。

そのため、

追加見積

契約変更

スケジュール変更

が必要になる可能性があります。

2．要件が曖昧だとトラブルになりやすい

請負では、

何を完成させればよいのか

が重要です。

例えば、

使いやすい管理画面を作る

だけでは完成条件が曖昧です。

誰が

何を登録できるか

何を検索できるか

何を出力できるか

をできるだけ明確にします。

3．変更が多い開発とは相性が悪い場合がある

IPAも、開発内容が決まっていない段階でプロジェクト全体を一つの請負契約にすることは適切ではないとし、仕様が確定した部分を請負にするなどの考え方を示しています。

特にアジャイル開発では、

ユーザーの反応を見る

↓

優先順位を変える

↓

仕様を変更する

↓

追加開発

という流れが前提になるため、最初にすべてを固定する請負とは相性が悪くなる場合があります。

準委任契約のメリット

1．仕様変更へ対応しやすい

例えば、

今月：

顧客管理を優先


来月：

顧客管理を減らして
案件管理を優先

という調整がしやすくなります。

契約している、

期間

稼働量

業務範囲

の中で優先順位を変更できる契約設計であれば、請負より柔軟に進められます。

2．要件が未確定でも開始しやすい

例えば、

業務システムを作りたい

↓

しかし現在の業務自体が
整理できていない

という場合です。

この段階で、

完成するシステム：
500万円

と決めるのは難しいでしょう。

そこでまず準委任で、

業務ヒアリング

課題整理

業務フロー

要件定義

を行い、仕様を確定させる方法があります。

IPAの資料でも、BPRなどを行いながらシステム化範囲を検討する段階では、最終成果物を早期に確定しにくいため、多段階で契約する考え方が紹介されています。

3．アジャイル開発と相性がよい

IPAのアジャイル開発向けモデル契約は、アジャイルでは機能追加・変更・優先順位変更が発生する特徴から、準委任契約を前提としています。

例えば、

2週間

↓

機能開発

↓

ユーザーテスト

↓

フィードバック

↓

次の機能を決定

という進め方です。

最初に最終成果物を固定するより、

一定期間ごとに
優先順位を見直す

方が適しています。

準委任契約のデメリット・注意点

1．完成が保証される契約ではない

最も重要です。

例えば、

6か月準委任契約

を結んだからといって、

6か月後に
必ずシステムが完成する

という契約とは限りません。

IPAも、準委任ではベンダーが完成義務を負わない点を明確にしています。

そのため発注者は、

何を優先するか

何を作るか

進捗はどうか

残予算はいくらか

を継続的に管理する必要があります。

2．総額が読みにくい場合がある

例えば、

月80時間
×
6か月

で開始しても、

追加開発

仕様変更

検証

によって期間が延びれば費用も増えます。

請負に比べ、最終費用が固定されにくい契約になる場合があります。

3．発注者側にもプロジェクト管理能力が必要

準委任、特にアジャイルでは、

発注して待つ

だけでは進みにくくなります。

発注者側も、

要件判断

優先順位

レビュー

受入確認

フィードバック

へ継続的に参加する必要があります。

システム開発ではどちらを選べばよい？

判断基準は、

成果物・仕様が
どの程度確定しているか

です。

請負が向いているケース

要件が明確

仕様が明確

画面・機能が確定

納期が明確

成果物を明確に定義できる

場合です。

例えば、

既存Excelを
決められた仕様でWeb化

既存システムの
特定機能だけ改修

仕様確定済みの
予約システム開発

などです。

準委任が向いているケース

業務要件がまだ曖昧

仕様変更が多い

ユーザーの反応を見ながら開発

技術検証が必要

継続的に改善する

場合です。

例えば、

要件定義支援

PoC

アジャイル開発

既存システム改善

保守

技術コンサル

などです。

開発工程ごとに契約を分ける方法もある

システム開発全体を、

請負

または、

準委任

のどちらか一つにする必要はありません。

例えば、

企画・要件整理
↓
準委任

要件定義
↓
準委任

仕様確定

↓

開発
↓
請負

リリース

↓

保守・改善
↓
準委任

という方法があります。

IPAでも、プロジェクトのフェーズや状況に応じて請負・準委任を使い分ける多段階契約モデルを紹介しています。

これはシステム開発では非常に合理的な考え方です。

要件定義は準委任が向いているケースが多い

要件定義では、

最初から答えが決まっている

とは限りません。

例えば、

現状業務ヒアリング

↓

課題発見

↓

新業務フロー検討

↓

必要機能整理

↓

優先順位決定

という作業です。

ヒアリングを進める中で、

当初必要だと思った機能が不要

別の機能が必要

と分かることもあります。

そのため、

この要件定義書を
必ずこの内容で完成させる

という請負より、

専門家として
要件整理を支援する

準委任の方が適する場合があります。

IPAが2025年に公開したシステム開発の契約に関する資料でも、要件定義を準委任として整理する契約モデルが示されています。

仕様が確定した開発は請負にしやすい

要件定義が終わり、

機能一覧

画面

データ

権限

非機能要件

外部連携

が明確になれば、

この仕様を
500万円で完成させる

という請負契約を結びやすくなります。

つまり、

準委任
↓
仕様を決める

請負
↓
決まったものを作る

という組み合わせです。

アジャイル開発は準委任と相性がよい

アジャイルでは、

設計

↓

開発

↓

リリース

↓

ユーザーの反応

↓

改善

↓

次の開発

を短いサイクルで繰り返します。

そのため、

最初に全仕様を確定

するのではなく、

優先順位を変えながら
価値の高い機能を開発

します。

IPAのアジャイル開発版モデル契約も、こうした性質から準委任を前提としています。

PoCは準委任が適する場合がある

AI・新技術の検証では特に重要です。

例えば、

画像AIで
90％以上の精度が出るか

を検証するとします。

検証前に、

必ず90％の精度を出す

と約束することが難しい場合があります。

そこで、

データ分析

モデル検証

評価

改善案整理

という検証プロセス自体を委託する方法があります。

つまり、

成功結果を保証

するのではなく、

専門家として
適切な検証を行う

形です。

R&D、AI PoC、新技術調査などでは、こうした準委任の考え方が適する場合があります。

保守・運用も準委任を利用しやすい

保守では、

毎月必ず障害を3件修正する

とは決められません。

実際には、

障害調査

問い合わせ対応

アップデート

監視

軽微な修正

など、発生した業務に対応します。

そのため、

月○時間まで

月額○万円

という準委任型の保守契約が使われる場合があります。

一方、

毎月決められたレポートを
必ず完成させる

など、成果物を明確に定義できる業務では別の設計も考えられます。

請負と準委任を選ぶチェックリスト

次の質問で考えると整理しやすくなります。

請負向き

□ 完成する成果物を明確に定義できる

□ 必要機能が確定している

□ 画面・仕様がある程度決まっている

□ 納期を固定したい

□ 予算を固定したい

□ 開発途中の仕様変更は少ない

該当項目が多いなら、請負を検討しやすいでしょう。

準委任向き

□ 何を作るべきかまだ整理中

□ 要件定義から支援してほしい

□ 開発途中で優先順位を変えたい

□ PoC・技術検証を行いたい

□ アジャイルで進めたい

□ 継続的に改善したい

□ 保守・運用を依頼したい

こちらが多ければ、準委任が候補になります。

請負契約で確認したい項目

システム開発を請負で契約する場合は、少なくとも次を明確にします。

□ 開発対象

□ 成果物

□ 機能要件

□ 非機能要件

□ 納期

□ 検収方法

□ 検収期間

□ 報酬

□ 支払条件

□ 仕様変更方法

□ 契約不適合への対応

□ 著作権・知的財産

□ ソースコードの扱い

□ 再委託

□ 秘密保持

特に、

何をもって完成とするか

が重要です。

検収条件を曖昧にしない

例えば、

正常に動作すること

だけでは曖昧です。

できれば、

要件定義書記載の
受入テスト項目をすべて満たすこと

など、判断方法を決めます。

請負では契約不適合責任も重要な論点であり、IPAの最新のモデル契約関連資料でも、報酬減額請求、損害賠償、解除、権利行使期間などが論点として整理されています。

準委任契約で確認したい項目

準委任では、

完成物

より、

どのような業務を
どの条件で行うか

を明確にします。

例えば、

□ 業務範囲

□ 契約期間

□ 月間稼働時間

□ 時間単価・月額

□ 作業場所

□ 役割分担

□ 報告方法

□ 定例会

□ 成果物がある場合の扱い

□ 知的財産

□ 契約終了条件

□ 超過時間の料金

などです。

例えば、

月80時間

だけではなく、

要件定義

基本設計

コードレビュー

開発支援

など、担当業務を記載します。

「準委任＝時間単価契約」とも限らない

準委任というと、

1時間5,000円
×
作業時間

をイメージしやすいですが、必ずしも時間単価だけではありません。

改正民法では委任について成果に対する報酬の規定も設けられ、IPAのモデル契約でも「成果報酬型準委任契約」が論点として整理されています。

そのため、

請負
=
固定額

準委任
=
時間単価

だけで判断するのは適切ではありません。

契約内容全体を確認します。

準委任で発注者が直接指示してよい？

ここは契約だけでなく、労働者派遣との区分にも関係するため注意が必要です。

例えば外部ベンダーのエンジニアへ発注者が、

今日はこのコードを書いてください

この順番で作業してください

9時から18時までここで働いてください

など、実質的に直接指揮命令する運用になると、契約書の名称だけでは整理できない問題が生じる可能性があります。

IPAのアジャイル開発モデルでも、受発注契約の下でアジャイル開発を行う場合の偽装請負リスクに触れ、厚生労働省の区分基準等を参考にするよう案内しています。

契約形態だけでなく、実際の業務指示・プロジェクト運営方法も確認する必要があります。

契約書のタイトルだけで判断しない

例えば、

業務委託契約

と書いてあっても、

中身が、

○月○日までに
システムを完成させる

完成後に500万円を支払う

なら、実質的には請負に近い契約内容です。

逆に、

システム開発契約

という名称でも、

月80時間の開発支援

なら準委任的な内容かもしれません。

したがって、

契約名称

ではなく、

義務の内容

報酬

成果物

責任範囲

を確認します。

請負・準委任を組み合わせる具体例

中小企業向けの業務システム開発を例にします。

フェーズ1｜要件定義

契約：
準委任

期間：
1か月

内容：

・業務ヒアリング
・業務フロー整理
・要件整理
・画面整理
・機能一覧

この段階では何を作るか確定していないため、準委任で進めます。

フェーズ2｜本開発

要件定義が終わり、

必要機能

画面

データ

権限

非機能要件

が決まったら、

契約：
請負

開発費：
400万円

納期：
4か月

とします。

フェーズ3｜運用・保守

リリース後は、

契約：
準委任

月額：
5万円

内容：

障害調査

問い合わせ

軽微な修正

アップデート

とします。

このように契約を分けることで、

曖昧な段階
↓
準委任

確定した段階
↓
請負

継続改善
↓
準委任

と、それぞれの特徴を活かせます。

請負と準委任でよくある誤解

誤解1｜準委任なら責任を負わない

違います。

完成義務を負わないことと、業務遂行上の責任がないことは別です。

IPAの準委任モデルでも、ベンダーには善管注意義務があることが示されています。

誤解2｜請負ならどんな追加要望も無料

違います。

契約後に新しい機能を追加すれば、追加費用が発生する可能性があります。

誤解3｜準委任なら仕様を決めなくてよい

違います。

柔軟に変更できるとしても、

目的

優先順位

業務範囲

は必要です。

誤解4｜請負なら発注者は何もしなくてよい

システム開発では発注者側の協力も重要です。

例えば、

業務ルール回答

仕様確認

レビュー

受入テスト

などが遅れれば、プロジェクトへ影響します。

IPAのモデル契約でも、プロジェクトマネジメント義務とユーザー企業側の協力義務が重要な論点として扱われています。

誤解5｜どちらか一方を全工程で使わなければならない

違います。

工程ごとに契約を分ける方法があります。

契約形態を決める5ステップ

STEP1｜成果物を明確にできるか確認する

完成状態を
明確に説明できるか？

を確認します。

STEP2｜仕様変更の可能性を確認する

開発途中で
要件が変わりそうか？

を考えます。

STEP3｜発注者がどの程度参加できるか確認する

準委任・アジャイルでは発注者の参加が重要です。

STEP4｜予算と納期の固定度を確認する

予算を固定したい

納期を固定したい

なら請負との相性を確認します。

一方、

予算内で
優先度の高いものから作りたい

なら準委任・アジャイルも候補になります。

STEP5｜工程ごとの契約を検討する

最後に、

要件定義：
準委任

開発：
請負

保守：
準委任

など、分割できないか検討します。

請負・準委任に関するよくある質問

請負と準委任の最大の違いは何ですか？

最も大きな違いは、

請負
=
仕事の完成

準委任
=
業務の遂行

に契約の重点があることです。

請負については民法632条で仕事の完成が契約の中心として定められています。

システム開発は請負と準委任のどちらが一般的ですか？

どちらも利用されます。

仕様が確定した開発では請負、要件定義・アジャイル・保守などでは準委任が利用されることがあります。

重要なのは案件・工程に合わせることです。

要件定義は請負にできますか？

契約上は案件ごとに検討が必要ですが、要件定義段階では最終成果物を事前に完全に確定しにくいため、準委任とするモデルがあります。IPAの資料でも要件定義を準委任として整理する例が示されています。

アジャイル開発は請負にできませんか？

請負で絶対にできないということではありません。

ただしIPAは、アジャイルでは要件・仕様・優先順位が変化する特徴から、準委任を前提としたモデル契約を公開しています。請負を利用する場合は、仕様確定部分に限定するなどの工夫が必要になります。

準委任ならシステムが完成しなくても報酬が必要ですか？

契約内容によりますが、準委任は原則として仕事の完成そのものを義務とする契約ではありません。

したがって、請負と同じ「完成しなければ一切報酬なし」と単純には考えられません。

具体的な報酬条件は契約書で確認する必要があります。

業務委託契約と準委任契約は同じですか？

「業務委託契約」という言葉は実務上広く使われますが、民法上の典型契約名として一律に一つの性質を示すものではありません。

契約内容によって、

請負

準委任

などの性質を持つ場合があります。

契約前に確認したいチェックリスト

□ 請負か準委任か

□ 何を委託する契約なのか

□ 成果物は何か

□ 完成義務はあるか

□ 契約期間はいつまでか

□ 報酬はいくらか

□ 支払条件は何か

□ 検収はあるか

□ 仕様変更はどう扱うか

□ 追加費用の条件は何か

□ 契約終了条件は何か

□ ソースコードは誰に帰属するか

□ 著作権はどうするか

□ クラウドアカウントは誰が所有するか

□ 再委託は可能か

□ 秘密保持はどうするか

□ 保守は契約に含まれるか

契約金額が大きい場合や重要なシステムでは、実際の契約書について弁護士など専門家へ確認することも検討してください。

hiro-dev-labの要件定義・業務システム開発支援

hiro-dev-labでは、Webシステム・業務システムについて、実装だけではなく要件整理から対応しています。

例えば、

• 現状業務のヒアリング
• 業務フロー整理
• 業務要件・機能要件整理
• 非機能要件整理
• システム化範囲整理
• 要件定義
• Webシステム設計・開発
• 外部API連携
• データ移行
• リリース
• 継続的な機能追加・保守

などを検討できます。

システム開発では、

最初から仕様が完全に決まっている案件

だけではありません。

例えば、

現在Excelで管理しているが、
どのようなシステムにすればよいか
まだ分からない

という場合は、

業務ヒアリング

↓

要件整理

↓

開発範囲確定

↓

設計・開発

と段階的に進めます。

請負と準委任は「どちらが優れているか」ではなく「どの工程に合うか」で選ぶ

請負と準委任には、それぞれ役割があります。

請負
=
仕事の完成を約束

準委任
=
専門家として業務を遂行

という違いを理解した上で、

要件が明確か

仕様変更が多いか

成果物を明確に定義できるか

発注者が継続的に参加できるか

予算・納期を固定したいか

から判断します。

システム開発では、

企画・要件定義
↓
準委任

仕様確定後の開発
↓
請負

継続的な改善・保守
↓
準委任

というように、工程ごとに契約形態を使い分ける方法もあります。

重要なのは、

とりあえず全部請負

とりあえず全部準委任

と決めるのではなく、

そのフェーズで誰が何を約束するべきなのか

を明確にすることです。

「要件がまだ固まっていない」

「請負で見積を取る前に要件整理したい」

「現在の業務をどのようにシステム化すればよいか分からない」

「要件定義から設計・開発まで相談したい」

といった段階からでも、システム化の検討を進めることができます。

要件定義・業務システム開発について相談する