請負契約と準委任契約の違い:システム開発の契約形態はどちらを選ぶべきか

開発会社から提示された契約書に「準委任契約」と書かれているのを見て、手が止まったことはないでしょうか。見積もりの話をしていたはずなのに、急に聞き慣れない契約用語が出てきて、これまで何となく使っていた「請負契約」という言葉との違いが分からない。上司に契約形態を説明しなければならないのに、「なぜこの契約なのか」を自分の言葉で言えない。ひとりで情シスや総務のIT担当を兼任している方であれば、こうした場面に一度は直面したことがあるのではないでしょうか。

結論から言うと、請負契約と準委任契約の違いは、開発会社が何を約束するかの違いです。請負契約は「決められた成果物を完成させること」を約束する契約で、準委任契約は「専門知識をもって業務を遂行すること」を約束する契約です。この違いは単なる言葉の違いではなく、支払いのタイミング、途中で契約をやめられるかどうか、成果物に不具合があったときにどこまで責任を追及できるかという、発注者にとって実務上重要な違いに直結します。

この記事では、民法の条文にさかのぼりながら、請負契約と準委任契約の法的な違いを整理したうえで、「自社の発注ではどちらが適切か」を判断するための考え方を解説します。読み終える頃には、開発会社から提示された契約形態が自社の発注内容に合っているかどうかを、自分の言葉で確認できるようになるはずです。

この記事で分かること

契約形態の違いに迷っている担当者が抱える疑問に、順番に答えていきます。

• 請負契約と準委任契約は、法律上どう定義されているか
• 報酬の支払いタイミング、契約の途中解除、成果物の不具合対応で、両者はどう違うか
• システム開発の現場で、それぞれの契約形態がどんな場面に向いているか
• 一つのプロジェクトの中で契約形態が工程ごとに変わることがある理由
• 契約書のどこを見れば、実際にどちらの契約なのかを確認できるか
• 契約形態を巡って発注者側が注意すべき落とし穴

一つずつ、順を追って見ていきます。

請負契約とは:「仕事の完成」を約束する契約

請負契約とは、民法第632条で定義されている契約形態です。条文には次のように書かれています。

請負は、当事者の一方がある仕事を完成することを約し、相手方がその仕事の結果に対してその報酬を支払うことを約することによって、その効力を生ずる。（民法第632条）

ここでのポイントは、請負人（開発会社側）が約束しているのは「仕事を完成すること」であり、注文者（発注者側）が支払う報酬は「仕事の結果」に対する対価だという点です。つまり請負契約は、完成した成果物そのものに価値を認め、その完成をゴールとする契約だといえます。

システム開発でいえば、「この仕様書通りのシステムを完成させ、納品する」という約束が請負契約の骨格になります。仕様が事前に固まっており、何を作れば完成といえるかが明確な開発案件では、請負契約が選ばれやすくなります。

• 完成の基準が契約時点で明確にできる（仕様書・要件定義書などで合意できる）
• 発注者は「動くもの」を受け取ることを目的にしている
• 開発途中の作業プロセスよりも、最終的な成果物の品質・機能を重視している

請負契約のもとでは、たとえ開発会社が多くの工数をかけて作業したとしても、仕事が完成しなければ原則として報酬を請求できません。これは請負契約の最も大きな特徴であり、次の見出しで説明する報酬の支払時期にも直結しています。

準委任契約とは:「業務の遂行」を約束する契約

一方の準委任契約は、民法上「委任」の規定を準用する形で定義されています。まず委任について、民法第643条は次のように定めています。

委任は、当事者の一方が法律行為をすることを相手方に委託し、相手方がこれを承諾することによって、その効力を生ずる。（民法第643条）

委任は本来、契約の締結や法律行為の代理など「法律行為」を委託する契約です。これに対してシステム開発の作業（プログラミングやテストなど）は法律行為には当たらないため、民法第656条の準用規定によって「準委任契約」として整理されます。

この節の規定は、法律行為でない事務の委託について準用する。（民法第656条）

つまり準委任契約は、法律行為以外の事務（システム開発の作業を含む）について、委任契約と同じルールを当てはめる契約形態だということです。ここで受任者（開発会社側）が約束しているのは、仕事の完成ではなく「委任事務を、専門家として誠実に遂行すること」です。成果物の完成そのものは契約上の約束の対象になっていません。

システム開発でいえば、「要件がまだ固まりきっていない中で、専門家として設計・開発の作業を進める」「保守・運用として日々の対応にあたる」といった、完成の基準を事前に一義的に定めにくい業務で準委任契約が選ばれやすくなります。

• 仕様が流動的で、開発を進めながら要件を固めていく必要がある
• アジャイル開発のように、短いサイクルで見直しながら進める開発スタイルを取っている
• 保守・運用のように、そもそも「完成」という概念がなじまない継続的な業務である

準委任契約でも「成果完成型」という類型があり、この場合は成果に対して報酬を支払う特約を結ぶことができます（民法第648条の2）。ただし、この特約があっても契約の性質自体は準委任のままで、後述する中途解除のルールなどは請負契約とは異なります。この点は次の見出しで詳しく見ていきます。

決定的な違い1:報酬はいつ、何に対して支払われるか

請負契約と準委任契約の最初の決定的な違いは、報酬の性質と支払いタイミングです。

請負契約では、報酬は「仕事の完成」に対して支払われます。民法第633条は次のように定めています。

報酬は、仕事の目的物の引渡しと同時に、支払わなければならない。ただし、物の引渡しを要しないときは、第六百二十四条第一項の規定を準用する。（民法第633条）

つまり原則として、成果物が完成し引き渡されるまで、開発会社は報酬を請求できません。これが請負契約における「後払い」の原則です。実務上は着手金・中間金といった形で契約時に分割払いを取り決めることが一般的ですが、それはあくまで契約当事者間の特約であり、民法の原則としては完成・引渡しが報酬発生の起点になります。

これに対して準委任契約では、報酬は「委任事務を履行したこと」に対して支払われます。民法第648条は次のように定めています。

受任者は、特約がなければ、委任者に対して報酬を請求することができない。受任者は、報酬を受けるべき場合には、委任事務を履行した後でなければ、これを請求することができない。（民法第648条第1項・第2項）

無報酬が原則である点は請負契約と異なりますが、実務上のシステム開発の準委任契約では、月額の稼働に対して報酬を支払う特約を結ぶのが一般的です。この場合、成果物が完成しているかどうかに関わらず、稼働した分の報酬が発生します。

この違いは、発注者にとって「予算の見通しやすさ」にも関わります。請負契約は完成までの総額が契約時点で確定しやすい一方、準委任契約は稼働に応じた精算になるため、想定より作業が長引けば総額も膨らみやすいという性質があります。この見積もりの読み方については、SOW（作業範囲記述書）の作業範囲の明確さとあわせて確認しておくと判断がしやすくなります。

決定的な違い2:途中で契約をやめられるか

二つ目の決定的な違いは、プロジェクトを中断・解除したいときの扱いです。

請負契約では、注文者（発注者側）はいつでも契約を解除できますが、その場合は請負人に生じた損害を賠償する必要があります。民法第641条は次のように定めています。

請負人が仕事を完成しない間は、注文者は、いつでも損害を賠償して契約の解除をすることができる。（民法第641条）

ここでの「損害」には、それまでに開発会社が投じた工数の対価や、契約が完遂していれば得られたはずの利益（逸失利益）が含まれ得ると解されています。つまり請負契約を発注者都合で途中解除する場合、開発会社側の逸失利益まで賠償の対象になり得るため、金銭的な負担が大きくなりやすいという特徴があります。

一方、準委任契約は当事者双方がいつでも解除できるのが原則です。民法第651条は次のように定めています。

委任は、各当事者がいつでもその解除をすることができる。前項の規定により委任の解除をした者は、次に掲げる場合には、相手方の損害を賠償しなければならない。ただし、やむを得ない事由があったときは、この限りでない。一 相手方に不利な時期に委任を解除したとき。二 委任者が受任者の利益（専ら報酬を得ることによるものを除く。）をも目的とする委任を解除したとき。（民法第651条第1項・第2項）

準委任契約の解除でも損害賠償が発生する場合はありますが、原則は「いつでも解除できる」ことがベースにあり、賠償が発生するのは「相手に不利な時期に解除した」などの限定的な場合です。

• 請負契約:途中解除は可能だが、開発会社の逸失利益を含めた損害賠償リスクが大きくなりやすい
• 準委任契約:途中解除のハードルは低いが、実務上は月額契約の解約予告期間（1ヶ月前通知など）を契約書で定めているケースが多い

この違いは、プロジェクトの先行きが不透明なときにどちらの契約形態を選ぶべきかの判断材料になります。仕様がまだ固まっていない段階から請負契約で発注してしまうと、後から要件を大きく変更したくなった場合の解除コストが重くなりがちです。小さく試してから本発注を判断したい場合は、PoC（概念実証）発注の考え方もあわせて検討する価値があります。

決定的な違い3:成果物に不具合があったときの責任

三つ目の違いは、納品されたものに問題があったときに、発注者がどこまで責任を追及できるかです。

請負契約では、完成した仕事の目的物が契約内容に適合しない場合(いわゆる契約不適合責任)、注文者は履行の追完請求・報酬減額請求・損害賠償請求・契約解除を行うことができます。ただし、民法第637条によって期間の制限があります。

前条本文に規定する場合において、注文者がその不適合を知った時から一年以内にその旨を請負人に通知しないときは、注文者は、その不適合を理由として、履行の追完の請求、報酬の減額の請求、損害賠償の請求及び契約の解除をすることができない。（民法第637条第1項）

つまり、不具合に気づいてから1年以内に開発会社へ通知しなければ、これらの請求ができなくなります。検収の場面で見つかった不具合はもちろん、納品後しばらく経ってから発覚した不具合についても、この通知期限を意識しておく必要があります。

準委任契約には、この「仕事の目的物」を前提にした担保責任の規定がそもそも存在しません。準委任契約における受任者の義務は、専門家として通常期待される注意を払って業務を遂行すること(善管注意義務と呼ばれます)であり、成果物の完成・品質そのものを保証する契約ではないためです。準委任契約のもとで納品物に不具合があった場合、発注者が追及できるのは「業務の遂行に注意義務違反があったかどうか」という、請負契約とは異なる筋道の主張になります。

実務上の視点: 「準委任契約だから何を作っても責任を問われない」という理解は正確ではありません。専門家として通常払うべき注意を欠いていたと言える場合は、民法第415条の債務不履行による損害賠償の対象になり得ます。ただし、請負契約の契約不適合責任のように「完成品が仕様と違う」という単純な比較で主張できるわけではなく、何が善管注意義務違反にあたるかの評価が必要になる点で、発注者側の立証のハードルは上がります。この評価が絡む場面では、自己判断で結論を出さず、弁護士等の専門家に確認することをおすすめします。

なぜ一つのプロジェクトで契約形態が工程ごとに変わるのか

ここまで請負契約と準委任契約を対比してきましたが、実際のシステム開発の現場では、一つのプロジェクトの中で契約形態が工程ごとに切り替わることが珍しくありません。典型的なパターンを整理すると、次のようになります。

1. 要件定義フェーズ: 何を作るべきかがまだ固まっていないため、準委任契約で進めることが多い
2. 設計・実装フェーズ: 要件定義の結果を受けて仕様が確定していれば、請負契約に切り替えて「この仕様通りに完成させる」契約を結ぶことが多い
3. 保守・運用フェーズ: 納品後の日々の問い合わせ対応や軽微な改修は、完成という概念になじまないため準委任契約(または保守契約という名称の契約)で進めることが多い

なぜこのような使い分けが起きるかというと、請負契約を結ぶには「何をもって完成とするか」を契約当事者双方が合意できていることが前提になるからです。要件が固まっていない段階で無理に請負契約を結んでしまうと、後から「これは仕様に含まれているか、いないか」を巡るトラブルの火種になります。逆に、仕様が確定している工程まで準委任契約のままにしてしまうと、発注者側は「完成品を受け取る権利」を契約上明確に持てないまま、稼働に応じた支払いを続けることになります。

• 要件定義フェーズを準委任契約で進める場合、成果物として何が納品されるか(要件定義書の完成度・粒度)を契約書やSOWで具体的に定めておくと、次工程への引き継ぎがスムーズになります
• 設計・実装フェーズを請負契約に切り替える場合、要件定義の成果物が仕様の合意文書として機能するかどうかを事前に確認しておく必要があります
• 保守フェーズの保守契約は、対応範囲・対応時間・SLAなど準委任契約特有の取り決めが必要になります

この工程ごとの切り替えは、システム開発の契約実務ではむしろ標準的なパターンです。「最初から最後まで同じ契約形態でなければならない」という思い込みを持たず、工程の性質に応じて契約形態が変わり得るという前提で契約書を確認すると、違和感なく読み進められるはずです。

混同しやすい概念:準委任契約と労働者派遣の違い

契約形態を調べていく過程で、もう一つよく出てくる混同が「準委任契約と労働者派遣は何が違うのか」という点です。どちらも「特定の作業をしてもらう」という点では似て見えますが、法律上の位置づけは大きく異なります。

準委任契約と労働者派遣の最大の違いは、指揮命令権がどちらにあるかです。

• 準委任契約: 発注者(委任者)は、受任者(開発会社)の従業員に対して直接の指揮命令を行いません。作業の進め方や誰がどの作業を担当するかは、受任者側が自らの裁量で決定します。発注者ができるのは、業務の内容や納期について受任者と協議することであり、現場の担当者に「今日はこの作業を先にやってください」と直接指示することはできません
• 労働者派遣: 派遣先(発注者)が、派遣元から派遣されてきた労働者に対して直接の指揮命令を行います。これは労働者派遣法で認められた特別な形態であり、労働者派遣事業の許可を受けた事業者でなければ行うことができません

この違いが実務上重要なのは、準委任契約であるにもかかわらず、発注者側の担当者が開発会社のエンジニアに日々の細かい指示を直接出してしまうケースがあるためです。これは「偽装請負」と呼ばれる状態に該当するおそれがあり、労働者派遣法・職業安定法に抵触するリスクがあります。

実務上の視点: 準委任契約で常駐型の開発を依頼する場合、発注者側の担当者が「今日はこの画面を先に直してください」「明日は出社時間を早めてください」といった形で開発会社の担当者に直接指示を出す運用は、偽装請負に該当するリスクがあります。実務上は、発注者が要望や優先順位を開発会社の責任者(プロジェクトマネージャーなど)に伝え、実際の作業指示は開発会社側の責任者が自社の担当者に行うという指揮命令系統を保つ必要があります。この線引きに不安がある場合は、労働局や社会保険労務士、弁護士等の専門家に確認することをおすすめします。

請負契約についても、同様に偽装請負のリスクは存在します。契約上は請負・準委任であっても、実態として発注者が現場の労働者に直接指揮命令を行っていれば、契約書の文言に関わらず労働者派遣とみなされる可能性がある点は覚えておいてください。

契約書のどこを見れば分かるか:確認すべき3つのポイント

自社が結ぼうとしている契約が請負契約なのか準委任契約なのかを確認するために、契約書のどこを見ればよいかを整理します。契約書のタイトルに「業務委託契約書」と書かれているだけでは、どちらの類型かは判断できません。「業務委託」は法律上の正式な契約類型ではなく、請負・準委任いずれの実質を持つ契約にも使われる慣用的な名称だからです。

契約書本文の、次の3点を確認してください。

• 契約の目的条項: 「甲は乙に対し、別紙仕様書記載のシステムの完成を委託し」のように「完成」「納品」という言葉が使われていれば請負契約的、「甲は乙に対し、別紙業務内容記載の業務の遂行を委託し」のように「遂行」「実施」という言葉が使われていれば準委任契約的な内容だと読み取れます
• 報酬条項: 「検収完了をもって報酬を支払う」であれば請負契約的、「毎月の稼働工数に応じて報酬を支払う」であれば準委任契約的な内容です
• 検収条項の有無: 請負契約には成果物を確認・受け入れる検収の手続きが定められているのが一般的ですが、純粋な準委任契約には検収という概念自体がなじみません。検収条項の有無は、契約類型を見分ける分かりやすい手がかりになります

実務上の視点: 契約書のタイトルや冒頭の一文だけで判断せず、報酬条項・解除条項・検収条項の3か所を実際に読み比べることをおすすめします。特に、タイトルは「業務委託契約書」なのに報酬条項は「稼働時間に応じて」となっている契約は珍しくなく、この場合は実質的に準委任契約として扱われます。契約類型の判断に迷う場合、あるいは契約書の記載が請負・準委任どちらとも取れる曖昧な内容になっている場合は、弁護士等の専門家に確認したうえで契約を締結することをおすすめします。

発注者側が注意すべき落とし穴

契約形態の違いを理解したうえで、発注者側が実務でつまずきやすいポイントを3つ挙げます。

落とし穴1: 準委任契約なのに「完成」を期待してしまう

準委任契約は業務の遂行を約束する契約であり、成果物の完成を法的に保証するものではありません。にもかかわらず、発注者側が「お金を払っているのだから当然完成するはずだ」という感覚のまま契約を結んでしまうと、想定通りの成果物が得られなかったときに「話が違う」というトラブルに発展しやすくなります。準委任契約を選ぶ場合は、完成を保証されない契約であることを理解したうえで、進捗確認の頻度や中間成果物の共有方法を契約書やSOWに具体的に盛り込んでおくことが重要です。

落とし穴2: 請負契約なのに仕様が固まっていない

逆に、要件がまだ流動的な段階で「金額を確定させたいから」という理由だけで請負契約を結んでしまうと、後から仕様変更のたびに追加見積もり・追加契約が発生し、結果として当初の想定より総額が膨らむことがあります。仕様が固まっていない段階では、無理に請負契約にこだわらず、準委任契約で要件を固めるフェーズを設けることも検討に値します。

落とし穴3: 契約形態の違いを理解しないまま相見積もりを比較してしまう

複数の開発会社から見積もりを取る際、A社は請負契約、B社は準委任契約を前提に見積もりを出してきた場合、金額の単純比較には意味がありません。請負契約の見積もりには完成責任のリスク分が織り込まれている一方、準委任契約の見積もりは稼働ベースの実費に近い性質を持つため、同じ金額でもリスクの所在が異なります。作業範囲を定めた文書の記載とあわせて、契約形態も比較の軸に加えることをおすすめします。相見積もりの取り方全般については、比較の観点を整理した記事もあわせてご覧ください。

発注者側にも義務がある:下請法の視点

ここまで開発会社側の義務を中心に説明してきましたが、契約形態を理解するうえで、発注者側にも法律上の義務が生じる場合があることに触れておきます。

自社の資本金規模が一定以上で、委託先の開発会社が中小企業に該当する場合、下請代金支払遅延等防止法(下請法)の適用対象になることがあります。下請法は、委託する側(発注者)が優越的な立場を利用して不当な扱いをすることを防ぐための法律で、システム開発の外部委託(情報成果物作成委託)もこの対象に含まれます。

下請法が適用される場合、発注者側には主に次のような義務が課されます。

• 発注内容(委託内容・報酬額・支払期日など)を記載した書面を交付する義務
• 給付を受領した日から起算して60日以内のできるだけ短い期間内に報酬を支払う義務
• 発注者の都合による受領拒否・返品・報酬の減額・支払遅延などを行わない義務

これは契約形態が請負契約か準委任契約かに関わらず、資本金規模と委託内容によって適用の有無が決まります。「準委任契約だから下請法は関係ない」という理解は誤りで、業務委託(準委任)であっても情報成果物作成委託に該当すれば適用対象になり得ます。

実務上の視点: 下請法の適用要件(資本金区分・委託内容の該当性)は個別の取引ごとに判断が必要で、自己判断で「うちは対象外」と決めつけると、意図せず違反状態になっているリスクがあります。委託先の規模や取引内容によっては公正取引委員会・中小企業庁の相談窓口、または弁護士等の専門家に確認することをおすすめします。

この視点は、外注のはじめかたを扱う本メディアにとっても重要です。発注者側は「お金を払う側だから強い立場にある」と考えがちですが、法律上は発注者側にも順守すべき義務があり、開発会社を不当に扱えば違反になり得るという点は、契約形態の選択とあわせて理解しておくべき前提です。

まとめ:自社の発注ではどちらを選ぶべきか

ここまでの内容を整理すると、契約形態を選ぶ際の判断軸は次のようになります。

• 仕様が事前に固まっており、「何を完成とするか」を契約時点で合意できる場合は、請負契約が適している
• 仕様がまだ流動的で、専門家として業務を進めながら要件を固めていく必要がある場合は、準委任契約が適している
• 保守・運用のように、そもそも完成という概念がなじまない継続的な業務は、準委任契約(または保守契約)が適している
• 一つのプロジェクトの中で、工程ごとに契約形態が変わることは珍しくない

契約形態の選択は、開発会社が一方的に決めるものではなく、発注者側も「なぜこの契約形態なのか」を理解したうえで合意すべき事項です。提示された契約書がどちらの類型なのか判断がつかないとき、あるいは自社の発注内容にその契約形態が本当に合っているか迷うときは、この記事で紹介した3つの確認ポイント(目的条項・報酬条項・検収条項)を手がかりに契約書を読み返してみてください。それでも判断が難しい場合は、自己判断で契約を締結せず、弁護士等の専門家に確認することを強くおすすめします。

契約形態を理解したら、次は実際の発注プロセスに落とし込む段階です。要件をどう開発会社に伝えるか、見積書のどの項目を確認すべきか、小さく試してから本発注を判断する方法など、外注のはじめかたに関する他の記事もあわせてご覧ください。