準委任契約とは？請負・派遣との違いとシステム開発での使い分けを解説

準委任契約とは、法律行為ではない事務の処理を委託し、その遂行そのものに報酬を払う契約類型で、民法656条が委任の規定を準用すると定めています。システム開発では要件定義やラボ型開発、保守運用の現場で広く使われますが、「成果物の完成義務がない」「契約不適合責任を原則負わない」という性質を誤解したまま結ぶと、発注者と開発会社の期待がずれ、トラブルの火種になりかねません。この記事では、2020年4月1日施行の改正民法で明文化された履行割合型（648条2項）と成果完成型（648条の2）の違い、請負契約・派遣契約・SES・業務委託との線引き、そしてシステム開発の工程ごとにどちらを選ぶべきかを、発注者の判断基準として整理します。

まとめ：準委任契約の要点と発注者が押さえる判断基準

準委任契約は「決められた業務を善良な管理者の注意をもって遂行する」契約で、請負のように仕事の完成を約束するものではありません。だからこそ、仕様が固まりきらない工程や、専門人材の稼働そのものを買いたい場面に向きます。報酬は稼働に対して払う履行割合型が基本で、特定の成果に対して払う成果完成型を選ぶこともできます。

発注者が最初に判断すべきは、買いたいものが「完成した成果物」か「専門家の稼働」かの一点です。完成責任を負ってほしいなら請負、要件を一緒に固めながら進めたいなら準委任、と切り分けます。システム開発では、要件定義は準委任、設計・実装は請負、保守運用やアジャイル型は準委任、という組み合わせが実務の定石です。契約書には報酬の型・中途解約・再委託・作業報告の方法を明記し、指揮命令を発注者が直接出さない体制にしておくと、後述する偽装請負のリスクを避けられます。

準委任契約の民法上の位置づけと履行割合型・成果完成型の全体像

準委任契約の性質は民法の条文で決まっています。まず言葉の定義から押さえ、そのうえで2020年改正で整理された2つの報酬類型を見ていきます。

準委任契約の定義と委任契約との違い（民法643条・656条）

委任契約は、当事者の一方が法律行為をすることを相手方に委託する契約です（民法643条）。これに対し、法律行為でない事務、たとえばプログラムの実装やサーバの運用監視のような事実行為を委託するものを準委任契約と呼び、民法656条が委任の規定を準用します。両者は報酬や責任のルールが同じで、実務上は「委任」「準委任」を厳密に区別せず業務委託契約として一本化して扱うことも珍しくありません。開発現場で「委任契約」と言うとき、その中身はほぼ準委任だと考えて差し支えありません。

善管注意義務が求める作業水準と成果を保証しない理由（民法644条）

受任者は、委任の本旨に従い善良な管理者の注意をもって事務を処理する義務を負います（民法644条）。これが善管注意義務です。求められるのは「その分野の専門家として通常期待される水準で作業を尽くすこと」であって、特定の成果を出すことではありません。たとえば運用監視の準委任なら、監視体制を適切に敷いて障害に対応する義務は負いますが、「障害ゼロ」を保証するわけではない、という理解になります。裏を返せば、善管注意義務を怠って生じた損害には債務不履行責任を問える、という点は発注者が押さえておく実務上の要になります。

履行割合型と成果完成型という2つの報酬類型（民法648条2項・648条の2）

2020年4月1日施行の改正民法は、準委任の報酬の払い方を2つの型として明文化しました。履行割合型は、稼働時間や工数など履行の割合に応じて報酬を払う型で、委任事務を履行した後に請求できます（648条2項）。成果完成型は、事務処理によって得られる成果に対して報酬を払う型で、成果の引渡しと同時に報酬を請求します（648条の2第1項）。次の表で違いを整理します。

成果完成型は成果に報酬を紐づけるため請負に似て見えますが、あくまで準委任です。完成義務を負わない点は履行割合型と変わりません。契約書のタイトルが「業務委託契約書」でも、どちらの型かを条項で特定しておかないと、途中解約時の報酬計算で揉めます。

準委任契約と請負契約の違いと完成義務および契約不適合責任の所在

発注者が最も間違えやすいのが、準委任と請負の線引きです。両者は「完成義務」と「契約不適合責任」の有無で決定的に分かれます。

仕事の完成義務がどちらにあるかという根本の違い（民法632条）

請負契約は、請負人が仕事を完成させ、注文者がその結果に報酬を払う契約です（民法632条）。完成しなければ原則として報酬は発生しません。準委任は事務の遂行そのものが目的なので、成果物が想定どおりに仕上がらなくても、善管注意義務を尽くしていれば報酬は発生します。「動くシステムが必ず納品される」ことを前提に発注したいなら請負、「要件を詰めながら専門家に手を動かしてもらう」なら準委任、という切り分けになります。

契約不適合責任を負うのは請負だけという整理（民法562条以下）

請負では、引き渡した成果物が契約の内容に適合しない場合、注文者は修補・代金減額・損害賠償・解除を請求できます。これが契約不適合責任で、2020年改正前は瑕疵担保責任と呼ばれていた枠組みです（民法562条以下を559条経由で準用）。準委任は仕事の完成を目的としないため、この契約不適合責任を原則として負いません。成果完成型であっても、648条の2第2項が準用するのは割合的報酬の規定（634条）であって、契約不適合責任そのものではない、という点は誤記の多い箇所なので契約書レビュー時に確認してください。ただし責任がゼロになるわけではなく、善管注意義務違反があれば債務不履行として損害賠償の対象になります。

発注者が準委任と請負のどちらを選ぶかを分ける契約設計の判断軸

下の表は、発注者が契約類型を選ぶときに見るべき軸をまとめたものです。

受託開発の全体像や、委託・請負・SESの呼び分けを発注側の目線で整理した内容は受託開発の意味と委託・請負・SESとの違いで詳しく扱っています。契約類型と発注方式をセットで理解しておくと、見積書のどこにリスクが乗っているか読み解けます。

準委任契約と派遣契約・SES・業務委託の違いと指揮命令権の所在

準委任・派遣・SESは、現場に人が常駐する点が似ているため混同されがちです。決定的な違いは、作業者に指揮命令を出せるのが誰か、という一点にあります。

指揮命令権が発注者側にあるのが派遣という区別（労働者派遣法）

労働者派遣では、派遣先である発注者が派遣スタッフに直接指揮命令を出せます。労働時間の管理や作業指示を発注者が行うのが前提で、派遣元は労働者派遣事業の許可を持っている必要があります。準委任は逆で、指揮命令権は受任者側（開発会社）にあり、発注者は成果や進め方の要望は伝えられても、個々の作業者へ直接の業務命令は出せません。「常駐しているエンジニアに毎日タスクを直接割り振っている」なら、契約書が準委任でも実態は派遣に近づき、違法な労働者供給とみなされる危険が出てきます。

SES・業務委託という業界呼称と準委任契約の法的な性質の違い

SES（システムエンジニアリングサービス）は、開発会社がエンジニアの技術力を提供する契約形態を指す業界用語で、その法的な中身の多くは準委任契約です。業務委託契約も法律上の固有名詞ではなく、請負か準委任のいずれか（または両方の混合）を指す実務上の総称にすぎません。つまり「SES」「業務委託」という言葉だけでは責任分界がわからず、契約書の条項で完成義務と指揮命令の所在を確認しなければなりません。次の表で常駐系3類型の違いを整理します。

この区別を曖昧にしたまま常駐させると、次章で述べる偽装請負の問題に直結します。

システム開発の工程別に見た準委任契約と請負契約の使い分け方針

ここからは競合記事があまり踏み込まない、発注実務の話をします。準委任と請負は「どちらが正しい」ではなく、開発工程ごとに向き不向きが分かれる関係です。1つのプロジェクトで工程ごとに契約を分ける、いわゆる多段階契約が現実的な解になります。

要件定義工程に準委任が向く理由と発注者が丸投げすると起きる問題

要件定義は、発注者もまだ完成形を描けていない段階です。成果物を確定できない工程に完成義務を課す請負を当てると、開発会社は防衛的に見積もりを膨らませ、要件変更のたびに追加費用が発生します。だからこの工程に合うのは、稼働に報酬を払う準委任です。ただし準委任だからと発注者が要件検討を丸投げすると、後工程の手戻りが跳ね上がります。要件定義で発注者が担う役割や成果物は要件定義の目的・進め方・成果物で整理しています。

設計・実装工程は請負、保守運用は準委任とする契約の割り付け方

要件が固まった後の設計・実装は、仕様書という完成の基準がある工程です。ここは完成義務と契約不適合責任のある請負を当て、納品物の品質責任を開発会社に持たせるのが基本になります。一方、リリース後の保守運用は、障害対応や小改修のように「何が起きるか事前に確定できない」稼働です。完成の定義ができないため準委任が向きます。開発全体をどの工程に区切るかはシステム開発の流れと各工程を押さえたうえで契約を割り付けると設計しやすくなります。

アジャイル開発やラボ型の開発で準委任契約が選ばれる背景と理由

スプリントごとに要件が変わっていくアジャイル開発や、一定人数のチームを一定期間確保するラボ型開発では、完成の範囲を契約時に固定できません。仕様の変化を前提にする以上、請負の完成義務とは相性が悪く、稼働に報酬を払う準委任（履行割合型）が選ばれます。この場合、発注者は「何人月をいくらで確保するか」で費用を見積もることになり、人月単価の妥当性を判断する目線が要ります。相場観はシステム開発の費用相場と人月単価を参照してください。

発注者が準委任契約で失敗する典型場面と偽装請負を避ける実務対応

準委任の性質を理解しないまま結ぶと、発注者が損をする場面がはっきりしています。ここは立場を明確にして書きます。次の3つに当てはまるなら、その契約は結ぶべきではありません。

成果物の完成を期待しながら準委任契約を結んでしまう発注の失敗

「動くシステムが納品されるはず」と考えているのに契約が準委任なら、それは選択を誤っています。準委任に完成義務はなく、成果物が未完成でも善管注意義務を尽くした稼働分の報酬は支払わなければなりません。完成責任を開発会社に負わせたいなら、その工程は請負にすべきです。準委任を選ぶのは、完成の範囲を事前に確定できない、あるいは確定させたくない工程に限る、と割り切ってください。

常駐エンジニアへ発注者が直接指示を出して偽装請負とされる失敗

契約は準委任なのに、発注者が常駐エンジニアへ直接タスクを割り振り、勤怠まで管理していると、実態は労働者派遣とみなされます。派遣の許可なくこれを行えば偽装請負にあたり、労働者派遣法や職業安定法に触れます。回避策は明快で、業務の依頼は開発会社の責任者を通す、作業者への直接指示や勤怠管理をしない、という体制を契約と運用の両面で徹底することです。指揮命令の窓口を一本化するだけで、リスクの大半は消えます。

作業報告書の様式と善管注意義務の履行基準を定めないまま結ぶ失敗

準委任は稼働に報酬を払うため、「何をどこまでやれば義務を果たしたことになるか」が曖昧だと、成果への不満が報酬トラブルに変わります。作業報告書の様式と提出頻度、報告に含める項目（着手したタスク・稼働時間・課題）を契約時に決めておけば、善管注意義務を果たしたことを客観的に示せるでしょう。要件が固まらない段階で外部の開発体制に伴走してほしい場合は、準委任を前提に工程設計から相談できるWebシステム開発の依頼先を選ぶと、契約と工程のミスマッチを最初から避けられます。

準委任契約の締結前に確認する報酬・中途解約・印紙税の実務条項

最後に、契約書のどこを見るべきかを実務の順で挙げます。ここを詰めておくと、後日の解釈違いを防げます。

報酬の型と支払いのタイミングを契約書の条項で特定する実務要点

まず、履行割合型と成果完成型のどちらかを条項で明記します。履行割合型なら「単価×稼働時間」の計算式と締め日、成果完成型なら成果の定義と引渡し条件を書きます。中途で契約が終了したときに、既にした履行の割合で報酬を請求できること（648条3項）や、可分な成果の扱いも定めておくと、清算で揉めません。

中途解約の予告期間と再委託できる範囲を契約書に明記する確認点

準委任は各当事者がいつでも解除できます（民法651条1項）。ただし相手に不利な時期の解除や、受任者の利益も目的とする委任を解除した場合は、損害賠償が必要になることがあります（651条2項）。長期の運用委託では、解約予告期間を条項で定めておくのが実務的です。あわせて、受任者が第三者へ業務を再委託（復委任）できる範囲も確認します。改正民法は本人の許諾または やむを得ない事由がある場合に復受任者の選任を認めており（644条の2）、再委託の可否と責任分界を契約書で線引きしておきます。

印紙税の要否と契約書名に潜む落とし穴を契約の実質で確認する視点

準委任契約書は課税文書にあたらないため、収入印紙は不要です。請負契約書が第2号文書として印紙を要するのと対照的で、契約書名を「業務委託契約書」としていても、中身が準委任なら印紙は不要と判断されます。逆に、名称が準委任でも実質が請負なら印紙が必要になるため、印紙の要否は名称ではなく契約の実質で判断する、という点を押さえておいてください。判断に迷う契約が多いなら、システム開発の依頼方法全体をシステム開発とは（種類・工程・依頼方法）で俯瞰してから個別条項に入ると整理しやすくなります。

よくある質問

準委任契約について、発注者から実際に多い質問をまとめました。

準委任契約書に収入印紙は必要ですか？

不要です。準委任契約書は印紙税法上の課税文書にあたりません。印紙が必要になるのは請負契約書（第2号文書）などで、契約書の名称が「業務委託契約書」でも中身が準委任なら印紙は不要と判断されます。ただし実質が請負であれば印紙が必要になるため、名称ではなく契約の実質で判断してください。

準委任契約でも成果物を求められることはありますか？

成果完成型の準委任（民法648条の2）なら、合意した成果の引渡しが報酬の条件になります。ただしこれは請負の完成義務とは異なり、成果が未達でも善管注意義務を尽くしていれば債務不履行にはなりません。確実に完成した成果物がほしい工程は、準委任ではなく請負を選ぶのが適切です。

SESと準委任契約は同じものですか？

SESは開発会社がエンジニアの技術力を提供する契約形態を指す業界用語で、その法的な中身の多くは準委任契約です。指揮命令権が開発会社側にある点が派遣との違いで、発注者が常駐者へ直接指示すると偽装請負になる恐れがあります。契約書では完成義務の有無と指揮命令の所在を必ず確認してください。

準委任契約は途中で解約できますか？

各当事者がいつでも解約できます（民法651条1項）。ただし相手にとって不利な時期の解約や、受任者の利益も目的とする契約を解約した場合は、損害賠償が必要になることがあります（651条2項）。長期の運用委託では、解約予告期間を契約書で定めておくと運用が安定します。

準委任契約では契約不適合責任を負いますか？

原則として負いません。契約不適合責任は仕事の完成を目的とする請負に生じる責任で（民法562条以下）、事務の遂行を目的とする準委任には当てはまらないのが基本です。成果完成型でも同じで、648条の2第2項が準用するのは割合的報酬の規定です。ただし善管注意義務に違反した場合は、債務不履行として損害賠償の対象になります。

関連記事

• 受託とは？受託開発の意味と委託・請負・SESとの違い：契約類型と発注方式をセットで理解したいときに読むと、見積書のリスクの所在がわかります。
• システム開発の流れと各工程：工程ごとに準委任と請負を割り付ける前提となる、開発全体の流れを押さえられます。
• システム開発の費用相場と人月単価：ラボ型・準委任で費用を見積もるときの人月単価の妥当性を判断できます。