【2026年版】準委任契約とSESの違い｜請負・派遣との比較と偽装請負の防ぎ方

「SES契約と準委任契約は何が違うのか」。この質問には、少し意外な答えがあります。SESは法律用語ではありません。エンジニアの技術力を役務として提供する取引の呼び名であり、契約の形としては準委任が使われることが多い、という関係です。

この関係を理解していないと、実務で判断を誤ります。特に危ういのが偽装請負のリスクです。契約書にSESと書いてあるかどうかは、適法性の判断には関係ありません。判断されるのは書面ではなく現場の実態です。

この記事では、準委任契約とSESの関係、2020年の民法改正で明文化された2つの型、請負・派遣との違い、厚生労働省の基準にもとづく偽装請負の線引き、そして発注側が契約と運用で決めておく項目までを整理します。

確認したいポイント	結論	詳細
SESと準委任契約は違うもの？	SESは通称、法的には準委任	SESは法律用語ではありません。契約の形として準委任が使われる、という関係です。
準委任は時間精算だけ？	成果完成型という型もある	2020年施行の改正民法で明文化されました。成果に対して報酬を定めることも可能です。
請負とは何が違う？	完成義務と契約不適合責任の有無	準委任は善管注意義務を負いますが、仕事を完成させる義務までは負いません。
偽装請負を避けるには？	発注側が直接指示を出さない	厚生労働省の37号告示が判断基準です。指示は受託側の責任者を通して行います。

この記事でわかること

• SESと準委任契約の正確な関係と、なぜ混同が起きるのか
• 履行割合型と成果完成型という2つの型の違いと使い分け
• 請負契約・労働者派遣契約との違いを、責任と指揮命令の観点で整理
• 厚生労働省の37号告示にもとづく偽装請負の判断基準とグレーになる場面
• 発注側が契約書と現場運用で決めておくべき項目

契約形態と体制の設計、無料で相談できます どの契約形態が合うか、現場運用をどう組むか。体制の設計からご一緒します。初回のご相談は無料です。

準委任契約とSESの関係

最初に、言葉の関係を整理します。この2つは並列で比較するものではありません。片方は法律上の契約類型、もう片方は業界の通称です。

なお本記事は一般的な情報の整理であり、個別の契約についての法的な助言ではありません。実際の契約締結や運用の判断にあたっては、弁護士や社会保険労務士へのご相談をおすすめします。

SESは法律用語ではない

SES（システムエンジニアリングサービス）は、IT業界における取引の呼び名です。エンジニアの技術力を役務として提供する取引を指しますが、民法や労働者派遣法にこの言葉は登場しません。

契約の形としては、準委任契約が使われることが多くなります。つまり「SES契約」と呼ばれているものの法的な実体は準委任契約である、というのが両者の関係です。

ここで押さえておくべき点があります。SESという名称を使っているかどうかは、適法性の判断には関係ありません。後述する偽装請負の判断は、契約書の記載ではなく現場の実態にもとづいて行われます。

準委任契約とは｜民法上の位置づけ

準委任契約は、法律行為ではない事務の処理を委託する契約です（民法656条）。システム開発の文脈では、要件定義の支援、技術調査、設計レビュー、保守運用、開発支援といった場面で使われます。

受託側が負うのは、善良な管理者の注意をもって業務を処理する義務（善管注意義務、民法644条）です。「完成させること」ではなく「専門家として適切に業務を行うこと」自体が契約の目的になります。

この点が、後述する請負契約との決定的な違いになります。成果物が期待どおりに完成しなかったとしても、適切に業務を遂行していれば債務は履行されているという構造です。

なぜ混同が起きるのか

混同の原因は2つあります。1つは、SESという言葉が契約類型のように使われていること。「SES契約」という独立した契約形態が存在するかのように語られる場面が多くあります。

もう1つは、現場の見え方が派遣とほぼ同じであることです。エンジニアが客先に常駐し、客先の環境で働く。この光景だけを見れば、派遣との区別はつきません。区別されるのは、指揮命令が誰から出ているかという一点です。

多重下請けという構造的な論点

もう1点、実務で押さえておきたいのが取引の階層です。IT業界では、元請けから二次、三次へと再委託が重なる構造が広く見られます。階層が深くなるほど、指揮命令の経路が曖昧になりやすいという問題があります。

発注側として確認すべきは、再委託の有無と範囲です。契約書で再委託の可否を定め、実際に誰が業務に従事するのかを把握できる状態にしておいてください。再委託先の管理責任がどこにあるかも、あわせて明確にしておく必要があります。

▶ 関連記事：ITソリューションサービスの詳細はこちら

準委任には2つの型がある

実務でよく見かける誤解が、「準委任は時間精算しかできない」というものです。これは2020年4月に施行された改正民法以降、正確ではなくなりました。

報酬の定め方によって、2つの型に分かれます。

履行割合型｜労務の提供に対して支払う

業務の遂行そのものに対して報酬を支払う型です（民法648条3項）。業務時間や工数といった業務量に応じて報酬が決まります。SESで一般的に使われているのはこちらです。

契約が途中で終了した場合も、既に履行した部分の割合に応じて報酬を請求できます。改正民法によって、この点が明確になりました。

向いているのは、業務の範囲が事前に確定しにくい案件です。要件定義の支援、技術調査、保守運用のように、やってみないと必要な工数が読めない業務と相性がよくなります。

成果完成型｜成果の引渡しに対して支払う

事務処理の成果に対して報酬を支払う型です（民法648条の2）。成果の引渡しを要する場合、報酬の支払いと引渡しは同時履行とされています。

改正前の民法には、準委任契約で成果に対して報酬を支払う合意がある場合の規定がありませんでした。改正によって明文化され、準委任でも成果ベースの報酬設計ができるようになっています。

なお、委託者の責めに帰することができない事由で履行できなくなった場合や、引渡し前に解除された場合でも、委託者が受ける利益の割合に応じて報酬を請求できます。

成果完成型と請負は何が違うのか

報酬が成果に紐づく点は同じですが、決定的な違いがあります。成果完成型の準委任は、成果物を完成させる義務を負いません。また、原則として契約不適合責任も負いません。

請負契約では、仕事の完成が目的であり義務です（民法632条）。完成しなければ債務不履行となり、成果物に不備があれば契約不適合責任を問われます。

したがって、受託側から見れば請負より成果完成型のほうが責任は軽くなります。ただし善管注意義務は負うため、成果について全く無責任でよいわけではない、という点は押さえておいてください。

自社の案件にどの契約形態が合うか、整理しませんか 業務の性質と体制を踏まえ、契約形態と運用ルールを一緒に設計します。初回のご相談は無料です。

請負・労働者派遣との違い

実務で判断が必要になるのは、準委任・請負・労働者派遣の3つの使い分けです。ここでは責任と指揮命令という2つの軸で整理します。

この2軸を押さえておけば、どの契約形態を選ぶべきかの大半は判断できます。

軸1｜完成責任があるか

請負契約は、仕事の完成が目的です。成果物が完成しなければ報酬は発生せず、不備があれば契約不適合責任を負います。発注側にとっては、成果に対する保証が得られる形です。

準委任契約は、業務の遂行が目的です。善管注意義務は負いますが、完成義務までは負いません。労働者派遣も同様に、完成責任はありません。

したがって、成果物を明確に定義できるなら請負、定義しきれないなら準委任というのが基本の判断軸になります。

軸2｜指揮命令権がどこにあるか

ここが最も重要です。準委任契約と請負契約では、指揮命令権は受託側にあります。発注側は、作業に従事する個人へ直接指示を出せません。

一方、労働者派遣契約では、指揮命令権は派遣先にあります。派遣先の担当者が派遣労働者へ直接指示を出すことが、契約上の前提です。ただし労働者派遣事業を行うには許可が必要です。

この違いを理解しないまま運用すると、契約書上は準委任なのに実態は派遣、という状態が生まれます。これが偽装請負です。

3形態の使い分け

整理すると、次のようになります。成果物が明確で完成保証がほしいなら請負。専門性を柔軟に活用したく、指示は受託側の責任者を通すなら準委任。自社が直接指示を出す必要があるなら労働者派遣。

「直接指示を出したいが派遣の手続きは避けたい」という理由で準委任を選ぶのは、最も危険な判断です。運用の実態が契約形態を決めます。手続きを避けるために形式を選ぶという発想自体を、まず外してください。

契約形態を途中で変えるという選択

案件の進行に応じて契約形態を切り替える、という選択肢もあります。要件が固まっていない調査・設計の段階は準委任、仕様が確定した実装の段階は請負という組み合わせです。

この進め方には利点があります。不確実性の高い段階で無理に完成義務を負わせないため、受託側が現実的な見積もりを出しやすくなります。発注側にとっても、段階ごとに続けるかどうかを判断できます。

切り替えの前提は、各段階の終了条件を事前に合意しておくことです。「この成果物が出た時点で次の契約に移る」という基準がなければ、切り替えのタイミングで揉めます。

▶ 関連記事：そのAI、何ヶ月で元が取れますか。投資回収を3分で見える化する計算式

▶ 関連記事：受託開発サービスの詳細はこちら

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

ここからが実務の中心です。偽装請負とは、書類上は請負や準委任でありながら、実態は労働者派遣である状態を指します。違法であり、罰則の対象となり得ます。

判断の基準は、厚生労働省が公表しています。

厚生労働省の37号告示

正式名称を「労働者派遣事業と請負により行われる事業との区分に関する基準」といい、昭和61年労働省告示第37号として定められています。労働者派遣に該当するかどうかを判断するための基準です。

この基準では、労働者派遣に該当せず請負に該当すると判断されるために、2つの要件のいずれにも該当する必要があるとされています。1つは自己の雇用する労働者の労働力を自ら直接利用すること、もう1つは請け負った業務を自己の業務として相手方から独立して処理することです。

重要なのは、労働者派遣と請負のどちらに該当するかは契約形式ではなく実態に即して判断されるという点です。契約書にどう書いてあっても、現場の運用が基準を満たしていなければ労働者派遣とみなされます。

厚生労働省は、判断に迷う場面について疑義応答集も公開しています。第1集から第3集まであり、具体的な事例に即した考え方が示されています。あわせて、労働局が公開している自主点検表も、社内確認のツールとして活用できます。

発注側がしてはいけないこと

実務上の要点は明確です。発注側の担当者が、常駐しているエンジニア個人へ直接指示を出さないこと。業務の割り振り、進め方の指示、作業順序の変更は、受託側の責任者を通します。

勤怠に関する管理も同様です。始業・終業時刻の指示、残業の指示、休暇の承認は、雇用主である受託側が行います。発注側がこれらを行えば、実態は労働者派遣と判断される可能性が高くなります。

配置や要員の交代についても、発注側が個人を指名して交代を求める形は避けてください。業務に必要な要件を伝え、誰を充てるかは受託側が決めるという分担にします。

実務でグレーになりやすい場面

1つ目は朝会や定例会議です。発注側の会議に常駐エンジニアが直接参加し、その場で作業指示が飛ぶ運用は危険です。参加させる場合は、情報共有にとどめ、指示は責任者経由にしてください。

2つ目はチャットでの直接やり取りです。発注側の担当者が個別に業務を依頼する形が常態化すると、実態として指揮命令が成立します。受託側の責任者を必ずチャンネルに含める運用が現実的です。

3つ目は備品や機材の提供です。発注側が業務に必要な設備をすべて提供している場合、独立して処理していると言えるかが問われます。セキュリティ上の理由で貸与する場合は、その必要性を説明できるようにしておいてください。

4つ目は急な仕様変更や割り込み対応です。「今すぐこれをやってほしい」という依頼を現場で直接伝える運用は、最も陥りやすい形です。緊急時の連絡経路も、あらかじめ責任者経由で設計しておく必要があります。

5つ目は評価やフィードバックです。発注側が常駐エンジニア個人の勤務態度や能力を評価し、本人へ直接伝える運用は避けてください。業務品質に関する要望は、受託側の責任者へ伝えるのが原則です。

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

契約形態と運用ルールの整理、ご相談ください 案件の性質に応じた形態の選定から、現場運用の設計まで支援します。導入以外のご相談もお問い合わせフォームから承ります。

発注側の契約形態の選び方

ここまでを踏まえて、発注側がどう選ぶべきかを整理します。判断の起点は、成果物を定義できるかどうかです。

3つの問いに順に答えれば、大半の案件は分類できます。

問1｜成果物を明確に定義できるか

「何ができあがれば完了とするか」を文書で書けるなら、請負が候補になります。画面数、機能、性能要件が固まっている開発案件が該当します。

定義しきれないなら準委任です。要件定義の支援、技術調査、既存システムの調査、そして保守運用。やってみないと必要な作業量が読めない業務は、無理に請負にすると双方が苦しみます。

経済産業省の「AI・データの利用に関する契約ガイドライン」でも、不確実性の高い段階では準委任、成果が定義できる段階では請負という使い分けが示されています。段階によって契約形態を変えるという発想が実務的です。

問2｜期間と柔軟性のどちらを優先するか

仕様変更が頻繁に発生する見込みなら、請負より準委任のほうが柔軟に対応できます。請負では変更のたびに契約変更の協議が必要になり、進行が止まりがちです。

逆に、予算を確定させたい、成果に対する保証がほしいという要請が強いなら請負を選びます。柔軟性と確実性はトレードオフであり、どちらを優先するかは経営判断になります。

問3｜自社が直接指示を出す必要があるか

日々の細かい指示を自社の担当者が出さなければ回らない業務であれば、準委任ではなく労働者派遣を検討してください。準委任のまま運用すれば、偽装請負のリスクを抱え続けることになります。

逆に、受託側にチームとして裁量を持って進めてもらう形が可能なら、準委任が適します。受託側に責任者を置き、その責任者と発注側の窓口がやり取りする体制を組めるかどうかが分岐点です。

▶ 関連記事：採用を諦めた中小企業社長が、AIで人手不足を埋めるまで

契約書と現場運用で決めておく項目

最後に、トラブルを未然に防ぐために決めておく項目を整理します。契約書に書く事項と、現場の運用ルールの両方が必要です。

片方だけでは機能しません。書面と実態の両方を揃えてください。

契約書に明記する項目

業務の範囲を具体的に書きます。「システム開発支援」のような抽象的な記載では、後から範囲を巡って争いになります。対象システム、担当する工程、想定する作業内容まで落としてください。

報酬の型も明記します。履行割合型なのか成果完成型なのか、精算の基準時間はどうするか、超過や不足が出た場合の扱いはどうするか。ここが曖昧だと毎月の請求で揉めます。

指揮命令の所在と連絡経路を書いておくことも重要です。受託側の責任者を明記し、指示や依頼はその責任者を通す旨を条文に含めます。書面と実態の両方が揃って初めて意味を持ちます。

加えて、秘密保持、成果物や知的財産の帰属、再委託の可否、契約終了時の引き継ぎも定めてください。特に引き継ぎは、後回しにされがちですが実務では最も効いてきます。

近年はもう1つ、AIツールの利用ルールも論点になっています。常駐するエンジニアが生成AIを使う場合、入力してよい情報の範囲、利用してよいサービス、生成物の取り扱いを、双方で合意しておく必要があります。この点が抜けたまま運用すると、情報管理の責任範囲が不明確になります。

▶ 関連記事：Claude Code企業導入｜セキュリティ・運用・ROI設計

現場運用で決めるルール

責任者を双方に置き、窓口を一本化する。これが最も基本的なルールです。発注側の担当者が個別にエンジニアへ依頼する経路を、構造的に作らないようにします。

チャットツールを使う場合は、受託側の責任者を必ずチャンネルに含める設定にしてください。個別のダイレクトメッセージで業務依頼が飛ぶ状態は、実態として指揮命令が成立します。

定例の場も設計します。週次で発注側の窓口と受託側の責任者が進捗と課題を確認し、そこで作業内容の調整を行う。この場があれば、日々の直接指示が不要になります。

そして、これらのルールを双方の現場メンバーに周知してください。契約書を交わした担当者は理解していても、実際に日々やり取りする現場が知らなければ意味がありません。

▶ 関連記事：外注ゼロでAIを回す会社がやっている、内製化5段階のステップ

体制と運用ルールの設計を、現場から支援します 契約形態の選定、責任者体制の設計、連絡経路の整備まで。安心して進められる形をご一緒につくります。初回相談は無料です。

まとめ

準委任契約とSESの関係、2つの報酬類型、請負・派遣との違い、偽装請負の線引き、契約形態の選び方、そして契約と運用で決める項目を整理しました。出発点は、SESが法律用語ではないという理解です。

契約書にどう書いてあっても、判断されるのは現場の実態です。発注側の担当者が常駐エンジニアへ直接指示を出さない。この一点を守れるかどうかが、適法性の分岐点になります。

また、準委任は時間精算しかできない契約ではありません。2020年施行の改正民法で成果完成型が明文化されており、業務の性質に応じて報酬設計を選べます。契約形態は、業務の不確実性に合わせて選ぶという発想を持ってください。

株式会社LiftBaseは、AI駆動開発と受託開発に加え、即戦力のITエンジニアをプロジェクト単位でご提供しています。必要な役割で開発体制を補強したい、という段階のご相談も承っています。

▶ 関連記事：AI導入支援・コンサルティングのサービス詳細はこちら

開発体制の補強、ご相談ください 必要な役割とスキルを整理したうえで、契約形態と運用体制まで含めてご提案します。まずはお気軽にご相談ください。初回相談は無料です。