システム開発は請負と準委任どちらを選ぶべき？違いと区別の判断基準を裁判例で解説

システム開発の契約書には、委託契約書、業務委託契約書、システム開発契約書などさまざまな表題がありますが、法律上は主に「請負契約」か「準委任契約」のどちらかに当たり、次のような違いがあります。

• 請負契約：約束したものを完成させて引き渡せば、報酬を受け取ることができる契約
• 準委任契約：結果までは約束せず、専門家として求められる注意を尽くして（いわばベストを尽くして）業務を行う契約

どちらに当たるかは契約書の表題ではなく契約の実態で判断され、開発が未完成で終わったときや途中で解約したときの結論も変わります。本記事では、両者の違いと区別の判断基準を、裁判例とあわせて解説します。

システム開発の契約類型が争いになりやすい理由

システムは、開発の過程で段階的に具体化していきます。そのため、特に初期工程の契約が請負と準委任のどちらに当たるかをめぐって、争いになりやすいといえます。

システム開発は、システムという「約束されたもの」を作り上げることを目的としています。上記の区別に従えば請負契約にも思えますが、そう単純ではありません。法律が想定する典型的な請負契約とは、実態が少し異なるからです。

典型的な請負契約の例として、オーダーメイドのスーツが挙げられます。スーツであれば、寸法などが決まれば当事者間で完成物のイメージを共有しやすく、仕上がりが注文どおりかどうかも判断しやすいでしょう。これに対しシステム開発では、システムの全体像がひと目でわかる資料は通常存在せず、発注者にとって全体像を把握しにくいといえます。また、要件定義、設計、実装、テストといった性質の異なる工程を経て、徐々に具体化していくという特殊性もあります。

そのため、システム開発のある工程、特に初期段階の契約が、仕事の完成を約束する「請負契約」なのか、ベストを尽くす「準委任契約」なのかが問題になることが多くあります。この区別次第で、仕事が完成しなかった場合に開発会社（ベンダー）が原則として報酬を請求できなくなるなど、当事者の一方に大きな金銭負担が生じることがあるため、どちらの契約に当たるかの区別は重要です。

以下では、請負契約と準委任契約の違い、両者を区別する判断基準、区別によって結論が分かれるトラブルの場面、どちらの契約を締結すべきかを順に説明します。

請負契約と準委任契約の違い【比較表】

請負契約は「仕事の完成」を約束する契約、準委任契約は「善良な管理者の注意をもって事務を処理すること」を約束する契約です。この違いから、報酬、解除、不具合の責任などに次のような差が生じます。

請負契約は仕事の完成に対して報酬が支払われる

請負契約とは、当事者の一方（請負人／ベンダー）がある仕事を完成することを約束し、相手方（注文者／ユーザー）がその仕事の結果に対して報酬を支払うことを約束する契約です（民法632条）。

「仕事の完成」の例としては、両当事者の認識が一致した「計画書」「要件定義書」「基本設計書」「プログラム」「システム」などの成果物の作成が挙げられます。

報酬は、仕事の目的物の引渡しと同時に支払うのが原則です（民法633条）。仕事が完成する前に報酬の支払を受けるには、前払いの特約が必要です。請負型のシステム開発では、この「仕事の完成」が極めて重要な概念となります。

また、システム開発の契約では、「検収」を仕事の完成や報酬支払の条件と定めることが多くあります。

準委任契約は善管注意義務を尽くして事務を処理する（履行割合型・成果完成型）

準委任契約とは、ある者（受任者/ベンダー）が他の者（委任者/ユーザー）から委託されて、法律行為でない事務の処理を行うことを目的とする契約で、委任の規定が準用されます（民法656条）。

受任者は、委任の本旨に従い、善良な管理者の注意をもって事務を処理する義務（善管注意義務）を負います（民法644条）。持っている能力を発揮して合理的に業務を遂行する義務であり、要は「ベストを尽くす」ということです。

典型的な例として、医療行為が挙げられます。医師は、治癒という結果までは責任を負いませんが、治療のプロセスでは医療水準に沿った診療を提供することを約束しています。請負契約と大きく異なるのは、仕事の結果までは責任を負わない点です。

準委任の報酬には、次の2つの型があります。

• 履行割合型：事務処理の労務そのものに対して報酬を支払う型です。報酬は、原則として事務を履行した後に請求できます（民法648条2項）。仕事が完成しなくても、事務処理が適切に行われていれば、受任者/ベンダーは報酬を得ることができます。
• 成果完成型：事務処理によって得られる成果に対して報酬を支払う型です。成果の引渡しを要する場合は、成果の引渡しと同時に報酬を支払います（民法648条の2第1項）。

いずれの型でも、受任者は仕事の完成を約束するわけではありません。

一度決めた報酬を、システム開発の経緯などを踏まえて増額できるかについては、下記記事で詳しく解説しています。

契約の性質を決める判断基準｜名称より実態が重視される

請負か準委任かは、契約書の題名や「請負」「準委任」の文言だけでは決まらず、成果物がどこまで確定していたか、報酬をどう定めていたかなどを総合的に考慮して判断されます。

請負か準委任かの性質決定が問題になる場面

「契約の性質決定」とは、当事者が請負か準委任かを明確に合意せず、契約書にも定めていなかった場合に、その契約がどちらに当たり、民法のどちらの規定が適用されるかを事後的に判断することをいいます。

もっとも、この問題の前提として、そもそもシステム開発に関する契約が成立しているのか、という問題があります。この点については、下記記事で詳しく解説しています。

契約が成立していることを前提に、それが請負と準委任のどちらに当たるかは、当事者のどちらが多額の金銭を負担するかに直結する大きな問題です。実務では、契約書に「請負」や「準委任」と明記していない場合や、明記していても実態が異なる場合、当事者間で認識が食い違っている場合も少なくありません。

裁判所が総合考慮する7つの要素

契約の性質は、契約全体をみて、その目的が「完成させた成果物を給付する」ことにあるのか、ベンダーが「合理的に業務を遂行する」ことにあるのか、という点から判断されます。完成すべき目的物の内容がある程度具体的に確定し、それに向けてプロジェクトが進んでいたかがポイントです。具体的には、次の要素が総合的に考慮されます。

開発会社の実績

同程度以上のシステムを開発した実績があれば、「完成させることが当然予定されており、完成をもって報酬を支払う合意があった」と判断されやすく、請負寄りの要素になります。

工程表上のゴールが「完成」になっているか

工程表のゴールが「完成」であれば、「完成させることが義務だった」と判断されやすく、請負寄りの要素になります。

契約内容・契約書上の記載における、成果物の内容の明確性

成果物の内容が明確なほど、「要件が明確なものを完成させることが予定されていた」と判断されやすく、請負寄りの要素になります。

報酬が成果物単位の固定額か、単価×稼働期間か

報酬が成果物に対する固定額で定められていれば、「完成をもって報酬が発生する建付けであり、完成させることが義務だった」と判断されやすく、請負寄りの要素になります。反対に、技術者ごとの単価に稼働期間を掛けて報酬を算定している場合は、労務の提供そのものに対する報酬とみられやすく、準委任寄りの要素になります（後述の東京地裁平成27年11月24日判決）。

報酬が完成後払いか

報酬が完成後払いであれば、「完成させることが義務だった」と判断されやすく、請負寄りの要素になります。

検収・契約不適合責任（旧瑕疵担保責任）・保証の条項の有無

これらの条項があれば、「完成させることが義務であり、それを前提に検収や契約不適合責任（旧瑕疵担保責任）、保証の条項が置かれていた」と判断されやすく、請負寄りの要素になります。

請負や準委任の文言の有無

文言も重要な考慮要素の一つです。ただし、「請負」や「準委任」という文言だけで判断されるわけではありません。見積書や注文書に「納期」「納品物」と書かれていても、それだけでは請負と判断されなかった裁判例もあります（後述）。契約書の書き方は慎重に検討する必要があります。

また、こうした判断は、契約書だけでなく、システム開発の過程で作成された議事録なども証拠として行われます。議事録の残し方については、下記記事で詳しく解説しています。

契約の性質が争われた裁判例

裁判所は、契約書の名称にとらわれず、実態をみて契約の性質を判断しています。代表的な裁判例を2つ紹介します。

東京地裁平成22年9月21日判決（判例タイムズ1349号136頁）

学習塾を運営するユーザーが、基幹業務システムの刷新をベンダーに委託した事案です。業務分析、要件定義、開発管理を内容とする「コンサルティング契約」について、裁判所は、準委任であるとしても、システム構築に係る請負の要素を含むと判断しました。そのうえで、新システムが旧システムの業務上重要な機能を踏襲していないとして、ユーザーによる解除を有効とし、既に支払った報酬の返還を認めました。

「コンサルティング」「準委任」という名称の契約でも、一応の作業をしただけで報酬を返さなくてよいとは限らないことを示す例です。

東京地裁平成27年11月24日判決（平成25年(ワ)第15414号）

ソーシャルゲームの開発を受託したベンダーが、未払いの報酬を請求した事案です。裁判所は、技術者ごとの1か月当たりの単価に稼働期間を掛けて報酬を算定し、作業内容が契約後のユーザーの指示で確定していった第1契約を、準委任と判断しました。見積書などに「納期」「納品物」の記載があっても、それだけで契約の性質が決まるわけではないとしています。

一方、報酬を総額で定め、契約時に企画書や画面遷移図などがユーザーから提供されていた第2契約は、請負と判断しました。第2契約のゲームは未完成でしたが、ユーザーが必要な指示や調整をしなかったことによるもので、ユーザーの責めに帰すべき事由によるとして、報酬の請求を認めています。

請負と準委任で結論が分かれる3つのトラブル

開発が未完成で終わったとき、途中で解約したとき、不具合が見つかったときの3つの場面では、請負と準委任のどちらに当たるかによって、請求できる内容が変わります。

開発が未完成で終わったときの報酬（割合的な報酬）

請負では、仕事が完成しなければ、請負人/ベンダーは原則として報酬を請求できません。前払いの特約に基づいて報酬を受け取っていても、プロジェクトの中止などで仕事が完成しなかった場合には、その返還を求められることがあります。

ただし、注文者の責めに帰することができない事由によって仕事を完成できなくなったときや、仕事の完成前に契約が解除されたときでも、既にした仕事のうち可分な部分の給付によって注文者が利益を受けるときは、その部分を仕事の完成とみなし、注文者が受ける利益の割合に応じて報酬を請求できます。

第634条　次に掲げる場合において、請負人が既にした仕事の結果のうち可分な部分の給付によって注文者が利益を受けるときは、その部分を仕事の完成とみなす。この場合において、請負人は、注文者が受ける利益の割合に応じて報酬を請求することができる。
1　注文者の責めに帰することができない事由によって仕事を完成することができなくなったとき。
2　請負が仕事の完成前に解除されたとき。

出典：e-Gov法令検索「民法」第634条

また、注文者の責めに帰すべき事由によって仕事を完成できなくなった場合には、注文者は報酬の支払を拒むことができません（民法536条2項）。前述の東京地裁平成27年11月24日判決も、ユーザー側の事情で未完成となった開発について、報酬の請求を認めています。

準委任では、仕事が完成しなくても、事務処理自体が適切に行われていれば、受任者/ベンダーは報酬を得ることができます。委任者の責めに帰することができない事由によって委任事務を履行できなくなったときや、委任が履行の中途で終了したときも、既にした履行の割合に応じて報酬を請求できます（民法648条3項）。成果完成型の準委任では、請負と同じく民法634条が準用されます（民法648条の2第2項）。

報酬が未払いとなった場合の法律問題については、下記記事で詳しく解説しています。

途中解約したときの損害賠償

請負では、当事者に債務不履行（約束違反）がない場合でも、注文者/ユーザーは、仕事が完成するまでの間、いつでも損害を賠償して契約を解除できます（民法641条）。この場合の「損害」は、請負人/ベンダーが支出した費用と、得られたであろう報酬から、仕事を完成させる義務を免れたことで節約できた費用を差し引いた額になります。一方、請負人/ベンダーには、このように理由を問わずに解除できる権利はありません（相手方の債務不履行を理由とする解除は別です）。

準委任では、相手方に債務不履行がない場合でも、委任者/ユーザーだけでなく受任者/ベンダーからも、いつでも契約を解除できます（民法651条1項）。ただし、次の場合には、やむを得ない事由があったときを除き、解除した側が相手方の損害を賠償しなければなりません（同条2項）。

• 相手方に不利な時期に解除したとき
• 委任者が、受任者の利益（専ら報酬を得ることによるものを除く）をも目的とする委任を解除したとき

いずれの契約でも、相手方に債務不履行がない限り解除できないとする特約を結べば、理由なく解除されるリスクを抑えられます。ただし、こうした特約の効力は、条項の文言や事情によって争われることがあるため、契約書の作成時に慎重に検討する必要があります。

ユーザー都合でシステム開発が中断された場合の法律問題については、下記記事で詳しく解説しています。

不具合が見つかったときの責任（契約不適合責任と善管注意義務）

請負では、引き渡されたシステムが種類や品質に関して契約の内容に適合しない場合、注文者は、履行の追完（修補など）、報酬の減額、損害賠償、契約の解除を求めることができます（民法559条により民法562条〜564条を準用）。契約で予定されていた最後の工程まで終えて仕事が完成した後に、システムが約束した仕様・性能を満たしていない場合が典型です。ただし、注文者が提供した材料の性質や注文者の指図によって生じた不適合については、原則として責任を追及できません（民法636条）。

注文者は、不適合を知った時から1年以内にその旨を請負人/ベンダーに通知しなければ、これらの権利を失います（民法637条1項）。ただし、引渡しの時に請負人/ベンダーが不適合を知っていた場合や、重大な過失によって知らなかった場合は、この期間の制限は適用されません（同条2項）。

裁判例では、大学の事務システムの開発について、多数の学生などが同時に利用することが想定されるのに、データの同時更新を制御する排他制御の機能がなかったことが、システムの不具合と評価されたものがあります（東京地裁平成22年1月22日判決〔平成18年(ワ)第6445号ほか〕）。システムの利用目的に照らして、基本的な機能が備わっているかが判断の目安になります。

責任を負わないとする特約や、責任を追及できる期間を短縮する特約を結ぶこともできます。ただし、請負人/ベンダーが知りながら告げなかった事実については、責任を免れることはできません（民法559条により民法572条を準用）。

契約不適合責任については、下記記事で詳しく解説しています。

準委任では、不具合があった場合の責任は、主に受任者が善管注意義務を尽くしたかどうかという債務不履行の問題として扱われます。受任者は「ベストを尽くす」という善管注意義務を負っているため、合理的な業務遂行を怠れば、債務不履行に基づいて損害賠償を請求されたり、契約を解除されたりするおそれがあります（民法415条・541条・542条）。成果完成型の準委任であっても、仕事の完成を約束するものではない点に注意が必要です。

不具合の通知には期限があり、契約が請負と準委任のどちらに当たるかで追及できる責任も変わります。相手方から責任を問われた場合も、こちらから請求する場合も、回答や通知の前に、契約書と開発の経緯の記録を弁護士に確認してもらうことをおすすめします。

再委託の制限と偽装請負のリスク

準委任では、再委託に委任者の許諾が必要です。また、契約の名称が請負や準委任であっても、発注者が受注者側の担当者に直接指示を出せば、偽装請負と判断されるおそれがあります。

準委任契約で再委託するには委任者の許諾が必要

請負では、請負人/ベンダーは原則として自由に再委託できます。ただし、再委託を禁止する旨の特約を結ぶと、再委託はできなくなります。

これに対して準委任では、受任者/ベンダーは、委任者の許諾を得たとき、またはやむを得ない事由があるときでなければ、再委託（復受任者の選任）ができません（民法644条の2第1項）。再委託をしたい場合は、契約書に再委託を認める条項を設けるなどして、あらかじめ委任者の許諾を得ておく必要があります。

この点は実務上も問題になることが多く、注意が必要です。「システム開発である以上、特に明記がなくても再委託できるはずだ」と考えて、再委託を認める条項のないまま準委任型の契約を結んでしまうと、再委託を行ったこと自体を契約違反と指摘されかねません。

なお、再委託先が中小企業やフリーランスの場合は、当事者の資本金や従業員数などによって、中小受託取引適正化法（取適法）やフリーランス法が適用され、取引条件の明示や支払期日の設定などの義務が生じることがあります。

再委託の可否については、下記記事で詳しく解説しています。

システム開発への取適法の適用については、下記記事で詳しく解説しています。

準委任でも発注者が直接指示すれば偽装請負になる

システム開発の現場では、ベンダーの技術者がユーザーの事業所に常駐して作業することも多くあります。このとき、ユーザーがベンダー側の技術者に直接、業務の進め方や労働時間を指示すると、実態は労働者派遣であるとして、偽装請負と判断されるおそれがあります。

厚生労働省の「労働者派遣事業と請負により行われる事業との区分に関する基準」（昭和61年労働省告示第37号）に関する疑義応答集（第3集）は、準委任契約であっても、契約の形式を問わず実態に即して判断するとしています。一方で、発注者と受注者の開発関係者が密に連携していても、対等な協働のもとで受注者側の担当者が自律的に判断して開発を進めていれば、偽装請負には当たらないとも示しています。

この疑義応答集はもともとアジャイル型開発を想定したものですが、令和8年5月25日に追加されたQ8では、同じ考え方がアジャイル型以外のシステム開発を請負で行う場合にも当てはまるとされています。

偽装請負の判断基準と対処法については、下記記事で詳しく解説しています。

常駐型の開発で使われることの多いSES契約の注意点については、下記記事で詳しく解説しています。

システム開発で問われるベンダーのプロジェクトマネジメント義務とユーザーの協力義務

請負と準委任のどちらであっても、ベンダーにはプロジェクトの進行を管理する義務が、ユーザーには開発に協力する義務が認められることがあります。

システム開発では、ベンダーは専門家として、開発の進捗を管理し、開発を妨げる要因があれば対処し、必要に応じてユーザーに対応を求める義務（プロジェクトマネジメント義務）を負うとされています。準委任契約であっても、この義務を怠れば、債務不履行として損害賠償などの責任を問われるおそれがあります。

プロジェクトマネジメント義務については、下記記事で詳しく解説しています。

一方で、多数の人手や工数が必要なシステム開発では、発注者であるユーザー側にも、必要な情報の提供や仕様の決定など、一定の協力義務が課されます。開発が頓挫した場合には、双方の義務の履行状況が責任の分担を左右します。

ユーザー側が負う協力義務については、下記記事で詳しく解説しています。

請負と準委任のどちらを選ぶべきか

どちらを選ぶべきかは、開発の難易度や、成果物の完成形を契約書で具体的に定められるかによって判断することになり、工程ごとに契約類型を使い分けることも少なくありません。まずは、ベンダーとユーザーそれぞれから見たメリット・デメリットを整理します。

ベンダーから見たメリット・デメリット

開発会社/ベンダーにとって、「請負契約」にするメリットは、投入する人を少なくして効率よく進めれば、準委任よりも利益を上げやすいことです。請負は「完成させること」が義務なので、人を減らしたり業務を効率化したりしてコストを抑えても、完成させれば義務を果たしたことになるからです。

一方、デメリットは次のとおりです。

• 仕事が完成するまでは、報酬を確実に得られるとは限らない
• 要件を満たすものを完成させるために当初想定していなかった工数が発生しても、その費用を負担することになり、赤字になるおそれがある
• 完成した成果物が契約の内容に適合しない場合に、契約不適合責任を負う

「準委任契約」にするメリットは、次のとおりです。

• 仕事が完成していなくても、履行の割合に応じて報酬を受け取れる
• 稼働に応じて報酬を請求できるため、増加した工数の費用を負担してもらいやすい
• 仕事を完成させ、契約の内容に適合した成果物を引き渡すという重い責任を負わずに済む
• 善管注意義務を尽くして業務を行うことが義務の内容なので、義務を果たすためのコストを事前に予測しやすい

ユーザーから見たメリット・デメリット

発注者/ユーザーにとって、「請負契約」にするメリットは、次のとおりです。

• 仕事が完成するまでは、原則として報酬を支払わなくてよい（ただし、未完成で終わった場合でも、既にされた仕事のうちユーザーが利益を受けた部分については、報酬の支払が必要になることがあります）
• 報酬が固定されるので、当初合意した範囲の作業であれば、工数が増えてもその費用を負担せずに済む

デメリットは、ベンダーが損失発生のリスクを見込むため、高額な見積りを提示されるおそれがあることです。

「準委任契約」にするメリットは、請負よりも低額な見積りを期待できることです。一方、仕事を完成させる責任までは受任者/ベンダーに負わせられず、当初想定していなかった工数が発生した場合には、その費用を負担することになる点がデメリットです。

工程ごとに契約類型を使い分ける多段階契約（IPAモデル契約）

システム開発では、工程ごとに個別契約を結び、工程の性質に応じて請負と準委任を使い分ける方法があります（多段階契約）。IPA（独立行政法人情報処理推進機構）と経済産業省が公表している「情報システム・モデル取引・契約書」（第二版）も、この考え方を前提にしています。要件定義は準委任、内部設計からシステム結合までのソフトウェア開発は請負とし、外部設計は準委任と請負のいずれかを選べるという整理です。アジャイル開発については、準委任を前提とした「情報システム・モデル取引・契約書」（アジャイル開発版）も公表されています。

もっとも、どちらの契約を締結すべきかは、開発対象の難易度や内容、受領したい／用意できる金額、相手方の意向や両者の力関係、そもそも成果物の完成像をイメージして契約書に記載できるかなど、経営面・法的側面の両方から各社の個別の事情に応じて判断し、交渉して決めることになります。

準委任型で契約する場合の契約書のチェックポイントについては、下記記事で詳しく解説しています。

まとめ：システム開発の契約類型は締結前と紛争の初期に確認を

「請負」と「準委任」は似ているようで、法的な効果はまったく異なります。どちらに当たるかは契約書の名称ではなく、議事録やメールなど開発の過程で残った記録も含めた実態で判断されます。

トラブルが表面化した後の不用意なやり取りが不利な証拠になることもあり、請負で不具合の責任を追及するには、不適合を知った時から1年以内の通知も必要です。契約書の締結前でも、トラブルが起きた直後でも、早い段階で専門家に相談すれば、取り得る選択肢を多く残せます。

当事務所は、システム開発の契約書の作成・レビューや紛争対応について、高度なノウハウを有しています。ベンダー側・ユーザー側のいずれの立場の方も、お気軽にご相談ください。