請負契約と準委任契約の選び方：システム開発の契約形態で変わる責任

システム開発の契約形態は、大きく「請負契約」と「準委任契約」の二つです。結論から言うと、作るものと完成の基準を契約時点で書き切れるなら請負、作りながら仕様を決めていく必要があるなら準委任が向いています。どちらが得かではなく、「仕様がどこまで決まっているか」と「発注側がどれだけ判断に関われるか」で選ぶものです。

請負は開発会社が完成に責任を持つ代わりに、仕様変更のたびに見積もりと合意がやり直しになります。準委任は柔軟に方向転換できる代わりに、成果の出来不出来に対する責任の多くを発注側が引き受けることになります。この違いを理解しないまま契約すると、「完成していないのに費用だけかかった」「変更を頼んだら別料金と言われた」といった食い違いが起きます。

この記事は、初めてシステム開発を外注する事業責任者や、新規事業でMVPを作ろうとしている担当者に向けて書いています。二つの契約形態の違い、仕様変更・検収・費用精算への影響、工程ごとの使い分け、契約書で確認すべき項目までを、発注者の目線で整理します。なお、契約の法的な解釈は個別の条項や事情によって変わるため、実際の契約書は弁護士など専門家の確認を受けてください。

請負契約と準委任契約の違いを一言で整理する

請負契約は「仕事の完成」を約束する契約です。開発会社は、合意した仕様どおりに動くシステムを納品する義務を負い、発注側は完成したものに対して報酬を支払います。完成しなければ原則として報酬は発生せず、納品後に仕様と違う点が見つかれば、開発会社は修正などの責任を負います。民法上は、この責任を「契約不適合責任」と呼びます。

準委任契約は「業務の遂行」を約束する契約です。開発会社は、専門家として求められる注意を払って作業を行う義務（善管注意義務）を負いますが、システムの完成そのものは約束しません。報酬は、稼働した時間や期間に対して支払うのが基本です。2020年施行の改正民法では、成果物の引き渡しに対して報酬を払う「成果完成型」の準委任も明文化されましたが、それでも請負のような完成義務とは性質が異なります。

両者の違いを表にまとめると、次のようになります。

「請負は安全、準委任はリスクが高い」と単純に捉えるのは誤りです。請負でも仕様が曖昧なら、何をもって完成とするかで揉めます。準委任でも、目的と優先順位を発注側がきちんと握っていれば、無駄なく開発を進められます。

仕様変更の扱いはどう変わるか

契約形態の違いが最も表に出るのは、開発途中の仕様変更です。

請負契約では、契約時に合意した仕様が「完成」の基準になります。途中で画面を追加したい、業務の流れが変わったので処理を変えたい、といった要望は、基準そのものを変えることになるため、追加見積もりと変更契約が必要になるのが一般的です。開発会社から見れば、固定の金額で完成を約束している以上、範囲が広がればその分の対価を求めるのは自然なことです。

準委任契約では、決まった期間・体制で稼働する契約なので、その範囲内であれば「この機能を後回しにして、代わりにこちらを先に作る」という入れ替えがしやすくなります。ただし、稼働量が変わらないということは、何かを足せば何かが後ろにずれるということです。追加の要望が積み重なれば、期間延長や体制増強という形で費用が増えます。

変更が多くなりそうなら最初から前提に置く

新規事業やMVPのように、顧客の反応を見ながら機能を決めていく開発では、仕様変更が起きるのが前提です。この場合に請負で契約すると、変更のたびに見積もりと合意のやり取りが発生し、スピードが落ちます。逆に、既存の業務をそのままシステム化する場合のように、業務フローが固まっていて変更の余地が小さいなら、請負で範囲と金額を確定させた方が予算管理はしやすくなります。

請負で変更を受け付けるときの手順

請負契約のまま仕様変更を受け付ける場合は、次の流れを契約書か運用ルールに定めておくと、言った言わないを防げます。

1. 発注側が変更の内容と理由を書面（チャットやチケットでも可）で申し出る
2. 開発会社が、追加の工数・費用・納期への影響を見積もって回答する
3. 発注側が、実施するか・別の機能を削るか・見送るかを判断する
4. 実施する場合は、変更の内容と金額・納期を記録に残し、双方が合意したことを明確にする

この手順を踏むと、小さな変更が口頭で積み重なり、検収の段階で「どこまでが元の仕様だったか」が分からなくなる事態を避けられます。

仕様変更の進め方そのものについては、開発途中の仕様変更にどう対応するかで、変更要求の記録と影響見積もりのルールを詳しく扱っています。

検収と「完成」の基準の違い

請負契約では、納品物を発注側が確認し、合格と判断する「検収」が報酬支払いの条件になるのが一般的です。検収で何を確認するかが曖昧だと、「この不具合が直るまでは検収できない」「それは仕様に書いていないので追加対応だ」という対立が起きます。そのため請負では、検収の基準と期間、不合格の場合の再検収の流れを契約時に決めておくことが重要です。

準委任契約では、成果物の完成ではなく業務の遂行に報酬を払うため、検収という手続きは必須ではありません。月ごとの作業報告を確認して支払う形が多くなります。ただ、検収がないからといって品質確認が不要になるわけではありません。むしろ準委任では、出来上がったものが目的に合っているかを判断する責任が発注側に寄るため、スプリントごとのレビューや受入確認を自分たちで設計する必要があります。

成果完成型の準委任を選ぶ場合は、「何が引き渡されたら報酬を払うのか」を具体的に書く必要があります。たとえば「要件定義書一式」「画面設計書と画面遷移図」のように成果物を列挙し、それぞれの完了条件を決めておきます。

検収で何を確認するかの作り方は、受入テストの進め方で、業務シナリオに沿ったテストケースの作り方として説明しています。

費用の決まり方と精算のしかた

請負契約の費用は、作業範囲を見積もったうえでの固定金額が基本です。開発会社は見積もりの段階で、仕様の不確かさや手戻りの可能性を織り込んだ「リスク分」を上乗せすることが多く、仕様が曖昧なほどこの上乗せは大きくなりがちです。その代わり、見積もりを超えて工数がかかっても、仕様の範囲内であれば発注側の負担は増えません。

準委任契約の費用は、「投入する人数 × 期間 × 単価」で決まるのが一般的です。上振れのリスクを開発会社が抱えないので見積もり時の上乗せは小さくなりやすい一方、稼働が延びればその分だけ費用が増えます。予算の上限を守るためには、期間と体制をあらかじめ区切り、その範囲で何を優先するかを発注側が決める運用が欠かせません。

準委任で予算の上限を守る運用

準委任で進めながら予算を守るには、契約前に次のような運用を決めておくと効果的です。

• 契約期間を1〜2か月程度の短い単位で区切り、更新のたびに続けるかを判断する
• 稼働の上限時間を決め、上限に近づいたら事前に連絡をもらう
• 毎週、完了した作業と次週の予定を一覧で共有してもらう
• 「必ず作るもの」と「余裕があれば作るもの」を分け、後者は予算の残りを見て判断する
• 期間の終わりに、目標に対してどこまで到達したかを振り返る場を設ける

この運用があれば、準委任でも「いつの間にか費用が膨らんでいた」という事態を避けられます。逆に、こうした管理を発注側で担う余力がない場合は、範囲を絞ったうえで請負にした方が安心できることもあります。

見積もりの金額差がどこから生まれるかを読み解く方法は、システム開発の見積もり比較のコツにまとめています。

工程ごとに契約形態を使い分ける

実務では、一つのプロジェクトを一つの契約形態で通す必要はありません。工程の性質に合わせて契約を分けるのが、発注側にとってもリスクを抑えやすい方法です。

1. 構想・要件定義の段階は準委任にする：何を作るかを一緒に決める工程なので、成果物の内容を事前に確定できません。期間と体制を決めた準委任で進め、成果として要件定義書や画面設計書を受け取ります。
2. 要件が固まった開発の段階は請負も選択肢にする：要件定義書をもとに範囲と金額を確定できるなら、請負で完成責任を持ってもらいます。仕様がまだ動きそうなら、ここも準委任のまま進めます。
3. 受入テストと本番移行は契約上の扱いを明確にする：請負なら検収の一部として、準委任なら作業範囲として、誰が何をするかを決めます。
4. 運用・保守・改善の段階は準委任や保守契約にする：障害対応や小さな改修が継続的に発生するため、月ごとの稼働や対応範囲を決めた契約が向いています。

このように工程を分けると、要件定義の段階で「この内容なら請負でいくらになるか」を判断する材料がそろい、開発会社を比較しやすくなります。また、要件定義の段階で相性が合わないと分かれば、次の工程で別の会社を選ぶこともできます。

MVP開発で準委任が選ばれやすい理由

新規事業のMVPは、作ってみて顧客の反応を見てから次を決める開発です。仕様が途中で変わることが前提なので、多くの場合は準委任が向いています。その際に「成果がはっきりしない」という不安を減らす方法は、MVP開発の契約形態で詳しく扱っています。

架空の例で考える：二つのケース

ここでは架空の例で、契約形態の選び方を考えてみます。

一つ目は、ある卸売の会社が、紙とExcelで管理している受注業務をシステム化するケースです。業務の流れは長年変わっておらず、必要な画面や帳票も現場担当者がはっきり説明できます。この場合、最初に短い準委任で要件定義を行い、画面と帳票の仕様を確定させてから、開発を請負で発注する流れが合っています。請負で範囲と金額が決まるため、社内の予算承認も通しやすくなります。

二つ目は、ある会社が新規事業として、個人向けのマッチングサービスを立ち上げるケースです。どの機能が利用者に響くかは、出してみないと分かりません。この場合、開発は準委任で期間を区切り、毎週の定例会で優先順位を見直しながら進めます。たとえば「最初の6週間で、登録・検索・問い合わせの三つの流れが動く状態にする」と目標を置き、残りの要望はその後に判断します。契約上は完成を約束しませんが、目標とレビューの場を決めておくことで、成果が見えない不安を抑えられます。

契約書で確認すべき項目チェックリスト

契約形態を決めたら、契約書の中身を確認します。どちらの形態でも、次の項目は発注側が目を通しておくべきです。

• 契約形態が請負か準委任か、契約書の表題だけでなく条文の中身で確認したか
• 作業範囲（何をする・何をしない）が具体的に書かれているか
• 成果物の一覧と、それぞれの完了条件が書かれているか
• 請負の場合、検収の期間・基準・不合格時の扱いが決まっているか
• 準委任の場合、稼働の上限・報告の頻度と形式・単価が決まっているか
• 仕様変更の申し出方と、追加費用の決め方の手順が書かれているか
• 納品後の不具合対応の期間と範囲が書かれているか
• ソースコードや設計書の著作権・利用権の帰属が決まっているか
• 再委託（下請けへの発注）の可否と条件が書かれているか
• 秘密保持と個人情報の取り扱いが決まっているか
• 途中解約の条件と、その時点までの成果物・費用の扱いが決まっているか

権利の帰属については、ソースコードの著作権は誰のものかで、将来の保守移管で困らない決め方を説明しています。

よくある失敗と避け方

準委任なのに請負のつもりで任せきりにする

準委任契約を結んだのに、発注側が「お金を払ったのだから完成させてくれるはず」と考えて関与しないケースです。準委任では、何を優先して作るかの判断は発注側に求められます。判断が遅れると稼働だけが進み、期待したものができないまま費用が膨らみます。準委任を選ぶなら、週次の定例会で優先順位を決める担当者を必ず置きます。

仕様が曖昧なまま請負で契約する

金額を確定させたい一心で、要件が固まっていない段階で請負契約を結ぶケースです。開発会社は曖昧さを上乗せして見積もるか、自分たちの解釈で範囲を狭く定義します。結果として、納品物が期待と違っても「仕様どおり」と言われる、あるいは追加費用が繰り返し発生する、という事態になります。要件定義を先に準委任で進め、その成果をもとに請負の見積もりを取る方が、結局は安く済むことが多い進め方です。

契約書の表題と実態がずれている

表題は「業務委託契約」でも、中身が請負なのか準委任なのかが不明確な契約書は珍しくありません。報酬が何に対して払われるのか、完成義務があるのかを条文で確認しましょう。また、準委任で発注側の担当者が開発会社のエンジニアに直接細かく作業を指示し続けると、実態が労働者派遣に近いとみなされるおそれがあります。指示は開発会社側の責任者を通す運用にしておくと安全です。

運用・保守の契約を後回しにする

開発契約だけを結び、リリース後の保守を決めていないケースです。納品後に不具合が見つかったとき、契約不適合として無償で直してもらえる範囲なのか、新たな保守契約が必要なのかで揉めます。開発契約と同時に、保守の範囲と費用の考え方を確認しておきます。

よくある質問

Q. 請負と準委任、どちらの方が費用は安くなりますか？

一概には言えません。請負は不確実性の分を上乗せするため割高に見えやすく、準委任は総額が期間次第で変わります。仕様が固まっていれば請負、変更が多ければ準委任の方が、結果的に無駄が少なくなる傾向があります。金額だけでなく、変更の起きやすさと発注側の関与の余力で判断してください。

Q. 準委任で納品物に不具合があった場合、直してもらえますか？

準委任では完成義務がないため、請負のような契約不適合責任をそのまま求めることはできません。ただし、専門家として必要な注意を怠った結果であれば責任を問える場合があります。実務上は、不具合修正を作業範囲に含めておく、稼働の中で優先して直す、といった取り決めを契約や運用で決めておくのが現実的です。

Q. 途中で契約形態を変えることはできますか？

できます。要件定義を準委任で行い、開発を請負に切り替える、あるいはリリース後に準委任や保守契約に移るのは一般的な進め方です。切り替えるときは、それまでの成果物の扱いと、新しい契約の範囲・完了条件を改めて書面で合意します。

Q. 契約書のひな形は開発会社のものを使ってよいですか？

使うこと自体は問題ありませんが、開発会社に有利な条項が含まれている可能性はあります。本記事のチェックリストの項目を確認し、気になる点は修正を相談しましょう。金額や影響が大きい契約は、弁護士に確認してもらうことをおすすめします。

Otsumuに相談できること

仕様がはっきりしていて、要件定義書も社内で作れる場合は、複数の開発会社から請負で見積もりを取り、比較して選ぶ進め方で十分です。社内に開発の発注経験がある方がいれば、本記事のチェックリストを使って契約書を確認するだけでも、多くのトラブルは防げます。

一方で、新規事業のように何を作るべきかがまだ定まっていない場合や、契約形態を決める前に要件を整理したい場合は、外部の力を借りた方が早く進みます。特に、準委任で進めたいが優先順位を決める社内の体制に不安がある、という状況は、契約の選び方よりも進め方の設計が鍵になります。

Otsumuは、構想から開発・運用・改善まで一気通貫で支援し、目的から逆算して必要な機能に絞ったうえで、工程に合った進め方を一緒に設計します。開発の進め方全般はシステム開発、検証のための小さな開発から始めたい場合は新規事業の爆速MVPシステム開発のページで紹介しています。たとえば、範囲を区切って6週間を目安に設計する PoC / MVP Sprint（300万円〜、税別・参考価格）のように、期間と成果を決めて進める形もご用意しています。それ以外の範囲は個別見積もりです。

「この案件は請負と準委任のどちらが合うか」という段階のご相談でも構いません。まずは30分の無料相談で、現在の状況をお聞かせください。秘密保持や契約条件は、相談時に確認のうえ合意して進めます。

この記事について

Otsumu株式会社が執筆しました。統計値や他社の事例には依拠せず、進め方と判断の枠組みを中心にまとめています。法務・税務・会計などの制度は、専門家や公的窓口で最新の情報をご確認ください。

執筆：Otsumu株式会社 ／ 編集日 2026.10.01