請負契約と準委任契約の違いは？システム開発の契約形態を発注者が選ぶときの比較表と工程別の考え方

開発会社から契約書の雛形が届き、「請負」と「準委任」のどちらかを選ぶよう求められた。システム開発の契約形態の違いがよく分からず、手が止まってしまう発注者は少なくありません。名前が似ているうえ、どちらを選ぶと自社が得なのかも見えにくいからです。

先に結論をお伝えします。「どちらが得か」ではなく、「作るものを契約の時点で具体的に決めきれているか」で選ぶのが基本です。完成させるべきものがはっきりしている工程は請負、作るもの自体を一緒に考える工程や、進めながら中身を変えていく開発は準委任が向いています。1つのプロジェクトを工程ごとに分けて、請負と準委任を組み合わせることもよくあります。

この記事では、2つの契約の違いを比較表で整理し、工程ごとの考え方、契約書で確認したいポイント、チェックリストと開発会社への質問例をまとめます。なお、契約は個別の事情で判断が変わるため、ここでの内容は一般的な考え方です。実際の契約書は弁護士などの専門家に確認してください。

請負契約と準委任契約の違いをひとことで言うと

まずは、法律上の定義をやさしく言い換えておきます。どちらも民法に定めがあります。

請負契約：「完成させること」を約束する契約

請負は、開発会社（請負人）が仕事を完成させることを約束し、発注者（注文者）がその完成した結果に対して報酬を支払う契約です。

📰 出典：e-Gov法令検索「民法」第632条（請負）

民法第632条では、請負は「当事者の一方がある仕事を完成することを約し、相手方がその仕事の結果に対してその報酬を支払うことを約する」ことで成立すると定めています。システム開発に置きかえると、「この仕様書どおりのシステムを完成させて納品する」ことが開発会社の義務になります。

準委任契約：「専門家として注意深く作業すること」を約束する契約

準委任は、法律行為ではない事務（作業）を任せる契約で、委任の規定が準用されます（民法第656条）。委任の規定のうち大事なのが第644条で、受任者（開発会社）は「善良な管理者の注意」をもって事務を処理する義務を負うとされています。

この「善良な管理者の注意」（＝善管注意義務）とは、その道の専門家として通常求められるレベルの注意を払って、誠実に作業する義務のことです。準委任では、開発会社は完成そのものを約束するのではなく、専門家としてきちんと作業することを約束します。

📰 出典：e-Gov法令検索「民法」第643条・第644条・第656条（委任・準委任）

準委任には「履行割合型」と「成果完成型」がある

準委任の報酬の決め方には、大きく2つの型があります。

• 履行割合型：作業した時間や期間に応じて報酬を支払う（例：月◯人分の作業に対して月額で支払う）
• 成果完成型：作業によって得られた成果に対して報酬を支払う（民法第648条の2）

成果完成型は、成果物の引渡しが必要な場合は引渡しと同時に報酬を支払う、と定められています。ただし成果完成型であっても準委任であることは変わらず、開発会社が完成を約束する請負とは別物です。「成果に払う＝請負と同じ」と思い込まないよう注意しましょう。

請負と準委任の比較表

違いを6つの観点で整理しました。あくまで民法の原則に沿った一般的な整理で、実際の内容は契約書の条文で変えられる点に注意してください。

比べる観点	請負契約	準委任契約
支払いの基準	完成した仕事の結果（納品物）に対して支払う	作業した時間・期間に対して支払う（履行割合型）。成果に対して支払う型（成果完成型）もある
完成責任	完成させる義務がある	完成の義務はない。専門家として注意深く作業する義務（善管注意義務）を負う
契約不適合責任（＝納品物が約束と違うときの責任）	ある。修補（直してもらう）・報酬の減額・損害賠償・解除を求められる	請負のような契約不適合責任はない。ただし注意義務違反があれば債務不履行責任を問える
変更への柔軟さ	低め。仕様を変えると、費用・納期の見直し（変更契約）が必要になりやすい	高め。作業の範囲内であれば優先順位や中身を変えながら進めやすい
発注者の関与度	仕様を決めた後は任せる部分が多い（ただし確認・検収は必要）	高い。何を作るか・何を優先するかを発注者が継続的に判断する
向く工程	作るものが具体的に決まっている工程（内部設計〜製造〜テストなど）	作るものを決める工程（企画・要件定義）、アジャイル開発、運用支援など

📰 出典：IPA「情報システム・モデル取引・契約書（第二版）」

IPA（情報処理推進機構）が公開しているモデル契約書の解説でも、請負は仕事の完成義務を負い、準委任は善管注意義務を負うものの完成の義務は負わないこと、請負では契約不適合責任を負うが準委任では負わないこと（注意義務違反があれば通常の債務不履行責任を負うこと）が、主な違いとして整理されています。あわせて、契約書に規定を設けることで民法の規定を修正することは原則として可能な場合が多いとも書かれています。つまり「請負だから必ずこうなる」ではなく、最終的には契約書の中身が重要です。

契約不適合責任の期間にも注意

請負の場合、納品物が契約の内容に合っていないことを見つけたら、民法では「不適合を知った時から1年以内」に開発会社へ通知しないと、修補や減額などを求められなくなるのが原則です（民法第637条）。ただし契約書で別の期間を定めていることも多いため、雛形の該当条文を必ず確認しましょう。

工程ごとに見る「請負か準委任か」の考え方

「どちらか1つを選ぶ」と考えると迷いますが、実務ではプロジェクトを工程で区切り、工程ごとに契約形態を選ぶ方法がよく使われます。IPAのモデル契約書も、この「多段階契約」を基本にしています。

📰 出典：IPA「情報システム・モデル取引・契約書（第二版）」解説付きモデル契約書

IPAのモデル契約書（第二版）では、工程と契約形態の関係が次のように示されています。

工程	モデル契約書での扱い	理由の考え方
企画・要件定義（＝何を作るかを決める工程）	準委任	発注者自身も始める時点で成果物を具体的に描けないため、完成を約束する請負になじみにくい
外部設計（＝画面や帳票など、使う人から見える部分の設計）	準委任または請負（選択）	発注者の業務要件に関わる部分が多く準委任になじむが、実務では請負も多い
内部設計〜製造〜結合テスト（＝システム内部の設計と組み立て）	請負	着手前に成果物を具体的に決められるため、請負で行うことができる
システムテスト	準委任または請負（選択）	外部設計の妥当性を確かめる工程で、発注者の業務要件と関わりが深い
導入・受入支援、運用テスト、移行支援	準委任	発注者が行う作業を開発会社が専門家として支援する

小規模なシステムでは、ここまで細かく契約を分けないこともあります。その場合でも、「要件定義までは準委任で進め、要件が固まった段階で設計〜開発を請負で見積もり直す」という2段階に分けるだけで、見積もりの精度が上がり、後からの食い違いを減らしやすくなります。工程ごとの用語は、打ち合わせで確認しながら進めれば十分です。

アジャイル開発は準委任が前提

アジャイル開発（＝短い期間で「作る→確かめる→直す」を繰り返しながら作っていく進め方）の場合、IPAが公開しているアジャイル開発版のモデル契約書は準委任契約を前提としています。開発の途中で機能の追加・変更や優先順位の入れ替えを行うため、あらかじめ決めた成果物の完成に対して支払う請負とは相性がよくないからです。

📰 出典：IPA「情報システム・モデル取引・契約書（アジャイル開発版）」

同じページでは、発注者がプロダクトの方向性や内容を決めるために主体的かつ積極的に関与する必要があり、相応の負担を伴うことも強調されています。「準委任＝お任せ」ではない点は押さえておきましょう。

状況別の選び方と判断フロー

請負が向きやすいケース

• 作りたいものの機能・画面・データが仕様書として具体的に決まっている
• 既存システムの置き換えなど、完成形のイメージを発注者と開発会社で共有できている
• 予算を固定したい、完成したら検収して支払うという形にしたい

準委任が向きやすいケース

• まだ「何を作るか」を検討している段階（企画・要件定義）
• 使いながら改善したい新規サービスで、仕様を固めきれない
• 社内に判断できる担当者を置き、開発会社と一緒に優先順位を決めていける
• 運用開始後の改善や問い合わせ対応など、作業そのものを継続的に頼みたい

判断フロー（文章版）

[画像：請負と準委任を選ぶ判断フローチャート]

1. 契約の時点で「何を完成させるか」を仕様書などで具体的に書けるか？ → 書けない場合は準委任（まず要件定義を準委任で行い、固まってから次の契約を検討）
2. 書ける場合、開発の途中で仕様を大きく変える可能性が高いか？ → 高い場合は準委任、またはアジャイル開発を検討
3. 変える可能性が低く、完成したものを検収して支払いたいか？ → 請負が向きやすい
4. どの場合も、工程を分けて契約できないかを開発会社と相談する

請負・準委任それぞれの「やりがちな失敗」

請負にしたから丸投げでよい、と考えてしまう

IPAのモデル契約書の解説では、請負型をとると発注者側に「丸投げ」「ベンダにすべてお任せ」という意識が強くなりやすいことが指摘されています。請負であっても、要件を決めるのは発注者の役割ですし、仕様の確認や検収も発注者が行います。仕様があいまいなまま請負にすると、「どこまでが契約の範囲か」で揉める原因になります。

途中で仕様を変えたくなったときの考え方は、システム開発の途中で仕様変更したい！どこまで変えていい？判断の物差しと進め方も参考にしてください。

準委任にしたのに、完成まで保証されると思っていた

準委任では、開発会社は完成を約束していません。予定した期間が終わっても思った機能がそろっていない、ということも起こり得ます。準委任を選ぶなら、定例会で進み具合と残りの作業を確認し、優先順位を発注者が判断していく体制が欠かせません。

開発会社のメンバーに直接細かく指示を出してしまう（偽装請負への注意）

請負や準委任（いわゆる業務委託）で働く開発会社のメンバーに対して、発注者が直接作業の指示を出したり、勤務時間を管理したりすると、実態として労働者派遣にあたると判断されるおそれがあります。これがいわゆる「偽装請負」の問題です。

📰 出典：厚生労働省「労働者派遣事業と請負により行われる事業との区分に関する基準（37号告示）関係疑義応答集」

厚生労働省は、労働者派遣か請負かは契約の形式ではなく、実態に即して判断されるとしています。同じページには、アジャイル開発のようなシステム開発を想定した疑義応答集（第3集）も掲載されています。一般的には、要望や仕様の相談は開発会社側の責任者を通す、メンバーの勤務管理は開発会社が行う、といった線引きを意識しておくと安心です。具体的な運用が問題ないかは、弁護士や都道府県労働局などの専門窓口に確認してください。

契約書で確認したい7つのポイント

雛形で契約形態を選ぶときは、「請負」「準委任」の文字だけでなく、次の条文も読み合わせましょう。

確認ポイント	請負で見るところ	準委任で見るところ
1. 業務の範囲	何を完成させるか（仕様書・納品物の一覧）	どんな作業を、どの期間・どの体制で行うか
2. 報酬と支払時期	検収後の一括か、分割か	月額か、成果完成型か。作業報告の方法
3. 検収・確認の方法	検収の期間、合格の基準、期間内に返事がない場合の扱い	作業完了の確認方法（報告書など）
4. 不具合への対応	契約不適合責任の期間・範囲・方法	注意義務違反があった場合の扱い
5. 変更の手続き	仕様変更時の見積もり・変更契約の流れ	作業範囲や体制を変える場合の手続き
6. 途中終了	途中で解約した場合の報酬の扱い	解約の予告期間、それまでの作業分の報酬
7. 役割分担	発注者が提供する資料・判断・期限	発注者側の担当者、定例会、指示の窓口

このほか、成果物の著作権をどちらに帰属させるか、再委託（＝開発会社がさらに別の会社に作業を任せること）を認めるかも、契約形態にかかわらず確認しておきたい項目です。

発注者がやることチェックリスト

• ☐ 作るもの（機能・画面・データ）を契約時点でどこまで具体的に書けるか整理した
• ☐ プロジェクトを「要件定義」「設計〜開発」「テスト・移行」などに分けて契約できないか検討した
• ☐ 選んだ契約形態で、発注者側が担う役割（判断・資料提供・検収）を書き出した
• ☐ 準委任の場合、優先順位を判断する社内担当者と定例会の時間を確保した
• ☐ 請負の場合、仕様書・納品物一覧・検収の基準が契約書に紐づいているか確認した
• ☐ 契約不適合責任の期間、途中解約時の報酬、変更手続きの条文を読んだ
• ☐ 開発会社のメンバーへの指示は、先方の責任者を通すルールにした
• ☐ 契約書の最終確認を弁護士などの専門家に依頼するか決めた

開発会社への質問例

• 「今回の工程ごとに、請負と準委任のどちらを想定していますか？その理由も教えてください」
• 「要件定義までを準委任で行い、その後の開発を改めて請負で見積もる進め方は可能ですか？」
• 「準委任の場合、作業報告はどのような形で、どのくらいの頻度でいただけますか？」
• 「請負の場合、検収の基準と、納品後に不具合が見つかったときの対応期間はどうなっていますか？」
• 「仕様を変更したくなったとき、見積もりと契約変更はどのような手順になりますか？」

まとめ：契約形態は「作るものが決まっているか」で選び、中身は条文で確認する

請負と準委任の違いと選び方のポイントをおさらいします。

• 請負は「完成させること」、準委任は「専門家として注意深く作業すること」を約束する契約
• 請負には契約不適合責任があり、準委任は変更への柔軟さがある代わりに発注者の関与が大きい
• 作るものが具体的に決まっている工程は請負、決める工程やアジャイル開発は準委任が向きやすい
• 工程ごとに契約を分ける方法もある（IPAのモデル契約書が参考になる）
• 契約形態にかかわらず、発注者の役割はなくならない。メンバーへの直接の指示には注意する

どちらの契約でも、民法の原則は契約書の条文で修正されていることが多いため、最後は条文の中身で判断することが大切です。迷ったら開発会社に理由を聞き、重要な契約は弁護士などの専門家に確認してから締結しましょう。

あわせて読みたい関連記事