システム開発・DX

システム開発の契約形態|請負と準委任の違い

最終更新日:2026年8月13日 ZenWeb Japan 編集部
結論:請負は「完成させる義務」がある契約、準委任は「決めた作業を誠実に進める義務」がある契約です。仕様がまだ固まっていない工程は準委任、確定した工程は請負が基本になります。全工程をまとめて一括請負にするより、工程ごとに分けて契約したほうが、あとから追加費用が出にくくなります。

01はじめに|この記事でわかること

要点:この記事は、システム開発をこれから発注する方に向けた契約形態の読み方です。請負と準委任の違い、工程ごとの使い分け、契約書で決めておく項目を、発注する側の判断軸で整理します。

見積書の表紙に「一括請負」とだけ書かれていて、その意味を確かめないまま押印してしまう。よくあるご相談のはじまりです。開発が進んで「この画面も足したい」と伝えたところ、別料金だと言われて驚く。あるいは逆に、毎月請求は来るのに何ができあがったのかがわからない。どちらも契約形態の話です。

請負か準委任かは、法律の用語である前に「どこまでを相手の責任にするか」の線引きです。ここを決めずに金額だけ比べても、あとで必ず食い違います。この記事では、2000年創業のWeb制作・システム開発会社ZenWeb Japanが、Webシステム開発のご相談でお伝えしている考え方をご紹介します。

この章のポイント:契約形態は法律用語の暗記ではなく、責任の線引きです。線引きが決まっていない見積りは、金額を比べても意味がありません。

まずは請負と準委任の違いを短くつかめる解説動画をご紹介します。

システム開発のポイント1【準委任契約と請負契約の違い】

出典動画:システム開発のポイント1【準委任契約と請負契約の違い】(YouTube)


02請負と準委任の違いは「完成させる義務」があるかどうか

要点:請負は仕事を完成させて初めて報酬が発生する契約です。準委任は完成そのものではなく、専門家として作業を誠実に進めることに対して報酬が発生します。この一点から、責任も費用の増え方も分かれていきます。

どちらも民法(e-Gov法令検索)に定めのある契約です。請負は「仕事を完成すること」を約束し、準委任は「事務の処理」を任せる契約と整理されています。ここでいう事務とは、設計や調査、技術支援といった作業のことです。

違いを一言でいえば、ゴールの置き場所です。請負のゴールは動くシステムそのもの。準委任のゴールは、約束した作業をきちんと進めることです。ですから、まだ何を作るかが決まっていない段階で請負にすると、完成の定義があいまいなまま「完成義務」だけが走り出します。要件定義の進め方を先に押さえておくと、この違和感がはっきり見えてきます。

  • 請負は成果物に責任を持ちます。納めたものが約束と違えば、直す義務が生じます。発注側は完成を待って検収します。
  • 準委任は進め方に責任を持ちます。専門家として当然払うべき注意を尽くしていれば、思うような結果にならなくても債務は果たしたことになります。
  • 費用の動き方が違います。請負は原則として金額が固定、準委任は稼働した分が積み上がります。
この章のポイント:完成義務があるのが請負、作業を誠実に進める義務があるのが準委任です。何を作るかが決まっていない段階では、そもそも完成義務を負わせられません。

034つの見方で比べる|責任・報酬・指示・中途解約

要点:比べるときは、成果物の責任、報酬の決まり方、開発者への指示の出し方、途中でやめたときの扱いという4点で並べてください。この4点がそろえば、どちらの契約が今の状況に合うかは自然に決まります。

見る点 請負契約 準委任契約
成果物の責任 完成させる義務あり。契約不適合なら修補や減額の対象 完成義務なし。専門家として注意を尽くす義務
報酬の決まり方 仕事の完成に対して固定額 稼働時間や工数に応じて。成果に紐づける型もあり
開発者への指示 受注側の責任者が出す。発注側は直接出せない 同じく受注側が出す。作業の依頼は窓口経由
途中でやめたとき できた部分が役に立つなら、その割合で報酬が発生 それまでの履行分について報酬が発生
向いている工程 仕様が固まった設計以降、実装、テスト 企画、要件定義、技術調査、メンテナンス・運用

注意したいのは「指示の出し方」です。どちらの契約でも、発注側が相手の担当者へ直接こまかく指示を出すことはできません。金額の妥当性を確かめる手順はシステム開発の見積もりの見方をご覧ください。

この章のポイント:責任・報酬・指示・中途解約の4点で並べると、契約形態の違いは表1枚に収まります。迷ったらこの表に当てはめてください。

いまの見積書、どちらの契約か書かれていますか。

工程ごとの区切り方と契約形態の組み合わせを、案件の状況にあわせて整理してお伝えします。 Webシステム開発の進め方を見る →


04工程ごとに契約形態はどう使い分けられているか

要点:実務では工程で契約を切り替えます。企画と要件定義は準委任が中心、詳細設計から実装は請負が中心です。仕様が固まっているかどうかが、そのまま境目になっています。

工程別に見た契約形態の採用割合
受託したシステム開発案件を工程別に分け、請負・履行割合型準委任・成果完成型準委任の採用割合をまとめた集計表
工程 請負 準委任(履行割合型) 準委任(成果完成型) 請負の比率
企画・構想 5% 80% 15%
要件定義 8% 72% 20%
基本設計 34% 44% 22%
詳細設計・実装 78% 12% 10%
結合・総合テスト 62% 28% 10%
メンテナンス・運用 12% 76% 12%

出典:ZenWeb Japanが受託したシステム開発案件(日本国内、2022〜2026年)の集計。

数字を並べると、境目がはっきり見えます。要件定義まではほとんどが準委任、詳細設計から先はほとんどが請負です。基本設計だけ割れているのは、この工程で仕様が固まる案件と固まりきらない案件が混ざるからです。工程の中身は基本設計と詳細設計の違いで整理しています。

この章のポイント:契約形態は案件単位ではなく工程単位で選ぶものです。仕様が固まった時点が、準委任から請負へ切り替える目安になります。

05要件定義を準委任にする理由

要点:要件定義は、発注側と開発側が話し合いながら「何を作るか」を決めていく工程です。決めるべき中身がまだない段階では、完成の基準を書けません。だから請負ではなく準委任にします。

請負契約は、完成の姿が先に決まっていて初めて成り立ちます。ところが要件定義は、その完成の姿を作る作業そのものです。ここを請負にすると、何をもって完成とするかを契約時に書けません。書けないまま押印すると、検収の場で「これは要件定義書として不十分だ」「いや、合意した範囲は満たしている」という水掛け論になります。

もうひとつの理由は、途中で方針が変わることです。業務の実態を聞き取るうちに、想定していなかった課題が出てきます。準委任なら、その場で話し合って進め方を変えられます。画面のイメージを早い段階で固める方法はワイヤーフレームの作り方が参考になります。

  • 完成の基準を先に書けないからです。成果物である要件定義書の中身が、作業を進めながら決まっていきます。
  • 話し合いの回数が読めないからです。関係部署が多いほど、合意までの打ち合わせは増えます。
  • やめる判断がしやすいからです。要件定義の結果、いまは作らないという結論も選べます。
この章のポイント:完成の姿を作る工程を、完成義務つきの契約で縛ることはできません。要件定義が準委任なのは、慣習ではなく理屈です。

06請負契約で気をつける3点|契約不適合責任と検収

要点:請負で確かめるのは、契約不適合責任の期間、検収の基準、変更手続きの3つです。2020年施行の改正民法で、発注側は修補だけでなく報酬の減額も請求できるようになりました。

改正民法にあわせて、IPA(情報処理推進機構)は情報システム・モデル取引・契約書(第二版)を公開しています。見直しの論点として、請負契約の契約不適合責任に報酬減額請求権が加わったこと、権利行使の期間制限が変わったことが挙げられています。契約書を読むときの手がかりになります。

  1. 契約不適合責任の期間を確かめてください。不具合を見つけてから、いつまでに伝えれば直してもらえるのか。「引渡しから◯か月」と書かれているのが一般的です。
  2. 検収の基準を数字にしてください。「正常に動作すること」だけでは、判断が分かれます。テスト項目に合格すること、と紐づけておくと争いになりません。テスト工程の種類と流れもあわせてご確認ください。
  3. 変更手続きを決めておいてください。誰が、どの書式で申し出て、いつまでに金額を回答するか。ここが空欄だと、変更のたびに交渉から始めることになります。
この章のポイント:請負の守りは検収と契約不適合責任です。期間と基準を数字で決めておけば、あとから直してもらえる範囲がはっきりします。

07準委任契約で気をつける3点|履行割合型と成果完成型

要点:準委任には、稼働した分だけ払う履行割合型と、成果物ができたときに払う成果完成型があります。上限工数、報告の頻度、成果物の定義。この3つが決まっていない準委任は、費用が読めなくなります。

準委任でいちばん多いご不安は「いつまでも請求が続くのでは」というものです。これは契約の書き方で防げます。月あたりの上限工数を決め、超えるときは事前に合意する。この一行があるだけで、青天井にはなりません。

  • 上限工数と超過時の扱いを決めてください。「月120時間まで、超過分は事前合意のうえ時間単価で精算」といった形が扱いやすいです。
  • 報告の頻度と形式を決めてください。週次で作業実績と残タスクを出してもらえば、進み具合が見えます。見えない準委任がいちばん不安になります。
  • 成果完成型なら成果物を具体的に書いてください。「設計書一式」ではなく、画面設計書・テーブル定義書というところまで並べます。

成果完成型準委任は、完成義務までは負わないものの、成果物の引渡しに報酬を紐づける型です。ラボ型開発のように、体制を一定期間確保して進める形とも相性がよく、ラボ型開発と請負・準委任の違いで詳しく取り上げています。在庫や受発注のように業務ルールが複雑な領域では、在庫管理システムの開発のように、前半を準委任で固めてから請負に移す進め方が向いています。

この章のポイント:準委任が青天井になるのは、上限工数と報告の取り決めがないときだけです。この2つを入れれば、費用は十分に読めます。

08契約の組み方と追加費用の関係

要点:全工程をまとめて一括請負にした案件は、追加費用が出る割合がもっとも高くなります。要件定義を準委任で切り出し、そこから請負に移した案件では、その割合が半分以下に下がります。

契約の組み方別の追加費用の発生状況
契約の組み方を4分類し、当初見積りからの追加費用が発生した案件の割合と平均増加率をまとめた集計表
契約の組み方 追加費用が出た割合 発生率の比較 平均増加率
全工程を一括請負 46% 当初比 +18%
全工程を準委任 29% 当初比 +11%
要件定義のみ準委任+以降を請負 21% 当初比 +7%
工程ごとに分割して契約 17% 当初比 +6%

出典:ZenWeb Japanが受託したシステム開発案件(日本国内、2022〜2026年)の集計。

全工程を一括請負にした案件のうち、およそ半数で追加費用が発生しています。金額を先に固めたはずが、いちばん動いています。

理由は単純です。要件が固まる前に金額を固めると、開発側は見えない部分を見込みで積むしかありません。その見込みが外れたとき、差額は追加費用として表に出てきます。分割して契約すれば、次の工程の見積りは前の工程の成果物を見て出せます。だから精度が上がります。

この章のポイント:一括請負は金額が固まるように見えて、実際にはもっとも動きます。前工程の成果物を見てから次を見積もる形が、いちばんぶれません。

09仕様変更が3件起きたときの試算

要点:同じ仕様変更でも、契約形態によって追加費用と合意までの日数が変わります。請負は交渉の手間が大きく、準委任は工数の積み増しで済みます。金額だけでなく、待ち時間も比べてください。

仕様変更3件が発生した場合の影響(試算)
開発費1,000万円・期間6か月の業務システムに仕様変更が3件発生した場合の、契約形態別の追加費用・追加期間・合意日数の試算表
契約の組み方 追加費用 追加期間 合意までの日数
全工程を一括請負 約180万円 約1.5か月 1件あたり10〜15日
要件定義のみ準委任+以降を請負 約70万円 約0.5か月 1件あたり5〜8日
準委任(履行割合型) 約110万円 約0.7か月 1件あたり2〜3日
準委任(成果完成型) 約90万円 約0.6か月 1件あたり3〜5日

試算例:開発費1,000万円・期間6か月の業務システムに、画面追加1件・帳票変更1件・権限設計変更1件が発生した想定。ZenWeb Japanの案件傾向をもとにした試算であり、実績値ではありません。

注目していただきたいのは、いちばん右の列です。一括請負では、変更のたびに範囲を切り分けて再見積りを出し、社内で承認を取る必要があります。1件あたり2週間近く止まることもあります。準委任なら、その週の作業計画を組み替えるだけで動けます。

ただし準委任は、変更を止める仕組みが契約側にありません。歯止めは発注側が持ちます。変更を受け入れる基準を先に決めておくと、必要な変更だけが通るようになります。

この章のポイント:比べるのは金額だけではありません。変更が決まるまでの日数も、納期に効いてきます。

10成果完成型準委任はこの5年で増えている

要点:一括請負は年々減り、成果完成型準委任とアジャイル型の契約が増えています。改正民法で成果完成型の位置づけが整理され、モデル契約が公開されたことが、選びやすさにつながっています。

契約形態の構成比の推移(2021〜2026年)
2021年から2026年までの受託システム開発案件について、一括請負・履行割合型準委任・成果完成型準委任・アジャイル型契約の構成比の推移をまとめた時系列表
一括請負 履行割合型準委任 成果完成型準委任 アジャイル型契約
2021年 54% 31% 11% 4%
2022年 50% 32% 13% 5%
2023年 46% 33% 15% 6%
2024年 42% 33% 17% 8%
2025年 39% 33% 19% 9%
2026年 36% 33% 21% 10%

出典:ZenWeb Japanが受託したシステム開発案件(日本国内、2021〜2026年)の集計。2026年は上半期時点。

背景には制度の整備があります。2020年4月に施行された改正民法で、成果完成型準委任の位置づけと中途解除時の報酬の扱いが整理されました。あわせてIPAはアジャイル開発版のモデル契約書を公開しています。以前は「前例がないから請負で」となりがちだった場面で、選択肢が示されたことは大きい変化です。

開発の進め方そのものの違いはアジャイル開発とウォーターフォールの違いにまとめています。契約形態は、進め方とセットで考えると迷いません。

この章のポイント:一括請負一択の時代は終わりました。成果完成型やアジャイル型を含めて、進め方に合う契約を選べるようになっています。

海外拠点を使う場合の契約形態も整理できます。

ラボ型のように体制を確保して進める形は、準委任との相性がよく、費用の見通しも立てやすくなります。 オフショア開発の体制を見る →


11偽装請負にならないための線引き

要点:請負でも準委任でも、発注側が相手の担当者へ直接こまかい指示を出すと、実態は労働者派遣とみなされることがあります。判断されるのは契約書の名前ではなく、日々のやり取りの実態です。

厚生労働省は、労働者派遣と請負を区分する基準(37号告示)について、疑義応答集を公開しています。第3集ではアジャイル型開発と契約方式に関する考え方(厚生労働省)が示されており、開発チームで一緒に働く形をとる場合の注意点がまとめられています。

  • 指示は必ず窓口を通してください。受注側の責任者へ依頼し、担当者への割り振りは相手に任せます。
  • 勤務時間や休憩を管理しないでください。出退勤の指定や残業の指示は、指揮命令とみなされる典型例です。
  • 役割を分けて記録に残してください。打ち合わせは議事録で、依頼は課題管理表で。口頭の細かい指示が積み重なると、実態が変わります。

同じ場所で一緒に働くこと自体が問題になるわけではありません。誰が何を決めているか、その線がはっきりしているかどうかです。

この章のポイント:判断されるのは実態です。指示は窓口経由、勤怠は相手の管理。この2つを守っていれば、契約形態にかかわらず問題になりません。

12契約書で決めておく6項目

要点:契約形態を決めたら、成果物、検収、変更手続き、知的財産権、再委託、秘密保持の6項目を確かめてください。この6つが空欄のまま進むと、トラブルの原因がそのまま残ります。

項目 確かめること
成果物 納品物の一覧と形式。ソースコードや設計書が含まれるか
検収 合格基準、確認期間、期限を過ぎたときの扱い
変更手続き 申し出の方法、見積回答までの日数、金額の決め方
知的財産権 著作権が誰に移るか。汎用部品の扱いをどうするか
再委託 外部への委託が可能か。事前承諾が要るか
秘密保持 対象データの範囲、契約終了後の返却と削除

知的財産権は、あとから効いてくる項目です。著作権が制作会社に残ったままだと、別の会社に改修を頼めません。本番データの扱いはWebシステムのセキュリティ対策、納品後の費用はシステム保守・運用費用の相場もあわせてご覧ください。

この章のポイント:契約形態を決めただけでは足りません。成果物と検収、そして知的財産権。この3つは必ず自分の目で読んでください。

13契約形態を決める5つの手順

要点:工程を書き出し、仕様の固まり具合を確かめ、区切りを決め、工程ごとに契約形態を当てはめ、変更手続きを決める。この5つの順番で進めれば、契約形態はほぼ自動的に決まります。

迷ったときは、次の順番で手を動かしてみてください。会議で議論するより早く結論が出ます。

  1. 工程を書き出します。企画、要件定義、基本設計、詳細設計・実装、テスト、移行、メンテナンス。抜けがないか並べます。
  2. 工程ごとに仕様の固まり具合を確かめます。「作るものが文章で書けるか」を基準にしてください。書けない工程は、まだ請負にできません。
  3. 区切りを決めます。どこまでを1本目の契約にするか。要件定義までで区切るのが、いちばん扱いやすい形です。
  4. 工程ごとに契約形態を当てはめます。書ける工程は請負、書けない工程は準委任。成果物を先に決められるなら成果完成型も選べます。
  5. 変更手続きを決めます。途中で要望が出たときに、誰がどう判断するか。ここまで決めて、はじめて契約の形が完成します。
この章のポイント:「作るものが文章で書けるか」。この1つの問いで、請負にできる工程かどうかが判定できます。

14よくある失敗|要件が固まる前に一括請負にする

要点:予算を確定させたい事情から、要件が固まる前に一括請負を選ぶ。これがいちばん多い失敗です。金額は決まりますが、範囲が決まっていないため、結局あとから交渉が始まります。

社内稟議のために総額を先に固めたい。よくわかるご事情です。ただ、そこで無理に一括請負にすると、開発側は不確実な部分にリスク分を上乗せします。結果として、割高な金額で契約したうえに、それでも追加費用が出ます。

現実的な進め方は2段階です。まず要件定義を準委任で行い、予算枠だけ「◯◯万円程度」として社内に共有しておく。要件定義が終わった時点で、精度の高い見積りを取って本予算を確定させる。稟議の回数は増えますが、着地のずれは小さくなります。

相見積りでも同じことが起きます。1社は一括請負、もう1社は要件定義から分割という形では、総額を比べても意味がありません。声をかける段階で、契約の区切り方をそろえておいてください。

この章のポイント:予算を早く固めたい気持ちが、かえって金額を動かします。要件定義を挟む2段階の進め方が、結果的にいちばん読めます。

15まとめ|発注側が押さえる3点

要点:完成義務の有無で見分ける。工程ごとに契約形態を切り替える。検収と変更手続きを数字で決める。この3点を押さえれば、契約形態の選択で大きく外すことはありません。

  1. 違いは完成義務の有無です。請負は完成させる義務があり、準委任は作業を誠実に進める義務があります。まずここで見分けてください。
  2. 契約は工程ごとに選びます。作るものが文章で書ける工程は請負、書けない工程は準委任。案件をひとまとめにしないことが、追加費用を減らします。
  3. 検収と変更手続きを数字にします。合格基準、確認期間、見積回答までの日数。ここが決まっていれば、途中で要望が出ても止まりません。

契約形態の選択は、事務手続きではなく設計の一部です。Webシステム開発のご相談では、見積りと一緒に工程の区切り方と契約の組み方までお話ししています。


16よくある質問

1. 請負と準委任のどちらが発注側に有利ですか?

工程によって変わります。仕様が固まっている工程では、完成義務のある請負が発注側に有利です。一方、仕様がこれから決まる工程では、請負にしても完成の基準を書けないため、守りになりません。有利かどうかは契約の名前ではなく、工程との組み合わせで決まります。

2. 要件定義を準委任にすると費用が読めなくなりませんか?

上限工数を決めれば読めます。「◯人月まで、超過分は事前合意のうえ精算」と書いておけば、上限は明確です。あわせて週次の作業報告を求めてください。進み具合が見えていれば、上限に近づく前に判断できます。

3. 成果完成型準委任と請負は何が違いますか?

どちらも成果物の引渡しに報酬が紐づきますが、完成義務の有無が違います。請負は仕事を完成させる義務を負い、成果物が契約に適合しなければ修補などの責任を負います。成果完成型準委任は完成義務までは負わず、専門家として注意を尽くす義務にとどまります。

4. 契約書は制作会社の雛形をそのまま使っても大丈夫ですか?

読んだうえで使うなら問題ありません。確認すべきは、成果物の一覧、検収の基準と期間、知的財産権の帰属、変更手続きの4点です。判断に迷う場合は、IPAが公開しているモデル契約書と読み比べると、抜けている条項が見えてきます。

5. 偽装請負と言われないために発注側が気をつけることは?

指示を窓口に一本化し、勤怠を管理しないことです。作業の依頼は受注側の責任者へ伝え、誰がいつ作業するかは相手に任せます。出退勤の指定や残業の指示は行いません。判断されるのは契約書の文言ではなく、日々のやり取りの実態です。

契約形態の選び方を一緒に整理しませんか。

作りたいシステムと社内の状況をうかがい、工程の区切り方、工程ごとの契約形態、契約書で決めておく項目を整理してお伝えします。2000年創業のZenWeb Japanが、日本品質を適正価格でご提供します。

無料で相談する →

まずは、いまお困りのことを聞かせてください

ご相談は無料です。要件が固まっていない段階でも構いません。内容をうかがったうえで、進め方とお見積りをご提案します。