偽装請負とは：4類型と37号告示の判断基準、SES・準委任で発注側が守る線引き

偽装請負は、契約書では請負や準委任なのに、発注者が受注者の技術者へ直接指示を出している状態を指します。判断の材料は契約の名前ではありません。厚生労働省の37号告示が定める「誰が業務の指示と労働時間を管理しているか」という実態です。この記事では、東京労働局が示す4つの類型、37号告示の要件を発注側の行為に置き換えた一覧、職業安定法と労働者派遣法の罰則、疑義応答集第3集が扱うアジャイル開発やチャットツールでの線引きを、SES・準委任で技術者を受け入れる発注側の立場から整理します。

まとめ：偽装請負の判断軸と発注側が契約前に決めておく指揮命令の線引き

偽装請負かどうかは、発注者が受注者の技術者に業務の進め方・労働時間・配置を直接指示しているかで決まります。請負でも準委任でもSESでも同じ基準が当たり、アジャイル開発だから例外になることもありません。

発注側が実務で押さえるのは次の3点です。1つ目は、日々の作業指示を自社で出したいなら最初から労働者派遣で契約すること。2つ目は、準委任やSESで受け入れるなら、指示は受注者側の管理責任者を通す窓口を契約書に書くこと。3つ目は、勤怠の承認・残業の指示・個人の指名を発注側がしないことです。

違反すると、受注者は無許可派遣として、発注者も職業安定法44条違反として、いずれも1年以下の拘禁刑または100万円以下の罰金の対象になり得ます。加えて発注者には、技術者へ直接雇用を申し込んだとみなされる制度が適用される場合があります。

偽装請負の定義と、請負・準委任・派遣を分ける指揮命令の有無という一点

偽装請負の中身は、契約形態の比較を1つの表にすると見通しがよくなります。先に定義、次に3形態の違いの順で確認します。

実態は労働者派遣なのに請負や準委任の名目をとる契約という労働局の定義

東京労働局の「偽装請負について」は、偽装請負を「書類上、形式的には請負（委任（準委任）、委託等を含む）契約ですが、実態としては労働者派遣であるもの」と定義し、違法だと明記しています。かっこ書きに準委任と委託が入っている点が実務では効きます。SESの多くは準委任契約なので、「請負ではないから関係ない」という整理は通りません。

疑義応答集第3集のQ1も同じ立場です。請負とは仕事の完成を目的とする契約（民法632条）で、派遣との違いは「発注者と受注者側の労働者との間に指揮命令関係を生じない」点にあり、委任（民法643条）・準委任（民法656条）も同様だと書かれています。契約の形式を問わず、実態に指揮命令関係があれば労働者派遣事業に該当します。

請負・準委任・労働者派遣の3形態を指揮命令と完成責任で並べた比較表

3つの契約形態の違いを、偽装請負の判断に関わる項目に絞って並べます。

表のとおり、発注者が技術者へ直接指示できるのは労働者派遣だけです。請負と準委任の違いは完成責任の有無で、指揮命令の面では同じ扱いになります。準委任の契約実務そのものは準委任契約とは？請負・派遣との違いとシステム開発での使い分けで、受託開発としての請負は受託とは？受託開発の意味と委託・請負・SESとの違いで詳しく扱っています。

東京労働局が示す偽装請負の4類型と、システム開発の現場で起きる形

東京労働局は偽装請負を4つの類型に分けています。システム開発で起きやすいのは前の2つで、後の2つは多重下請けやフリーランスへの業務委託で表面化します。

代表型と形式だけ責任者型＝発注者の直接指示が日常化している状態

代表型は、発注者が業務の細かい指示を労働者に出したり、出退勤や勤務時間を管理したりしている形です。開発現場に置き換えると、発注側のリーダーが常駐エンジニアに毎朝タスクを割り振り、勤怠表に発注側の課長が承認印を押している状態がこれに当たります。

形式だけ責任者型は、受注者が現場に責任者を置いているものの、その責任者が発注者の指示を個々の労働者に伝えるだけになっている形です。受注者側のリーダーが「お客様からこう言われたので、このチケットを今日中に」と転送しているだけなら、実態は発注者の直接指示と変わりません。責任者を置いたことだけでは適法になりません。

使用者不明型と一人請負型＝多重下請けとフリーランス再委託で起きる形

使用者不明型は、業者Aが業者Bに仕事を発注し、Bがそれを業者Cにそのまま出し、Cの労働者がAの現場でAやBの指示を受けて働く形です。SESで二次請け・三次請けが重なり、エンジニア本人が自分の雇用主以外から指示を受けている構図がこれに当たります。商流の深さが偽装請負の温床になる構造はプライム案件とは？元請け・一次請けとの違いで整理しています。

一人請負型は、受注者と労働者の関係まで個人事業主との請負契約で偽装し、実態は発注者の指示で働かせる形です。フリーランスのエンジニアを業務委託で受け入れ、社員と同じ勤務時間で発注側が直接指示している場合は、偽装請負に加えて労働基準法上の労働者性も問題になります。

37号告示の判断基準を発注側の行為に置き換えた6項目と独立処理の3要件

適法な請負・準委任と認められるには、労働者派遣事業と請負により行われる事業との区分に関する基準（昭和61年労働省告示第37号）の第2条が定める2つの要件を両方満たす必要があります。自ら労働者を管理すること（1号）と、業務を独立して処理すること（2号）です。

業務遂行・労働時間・秩序維持の3管理を受注者が自ら行う要件とNG行為

1号は、イ（業務の遂行）・ロ（労働時間）・ハ（企業秩序）の3つの管理を、それぞれ2項目ずつ受注者が自ら行うことを求めています。条文の各項目を、発注側がやってしまいがちな行為に置き換えると次のとおりです。

ロ(1)(2)には「単なる把握を除く」というかっこ書きがあります。入館記録で在館時間を把握すること自体は管理に当たりません。問題になるのは、発注側が始業時刻を決めたり休暇を承認したりする行為です。

資金・事業主責任・専門性で判断する独立処理の要件と人月精算の落とし穴

2号は、イ「業務の処理に要する資金につき、すべて自らの責任の下に調達し、かつ、支弁すること」、ロ「事業主としてのすべての責任を負うこと」、ハ「単に肉体的な労働力を提供するものでないこと」の3つを求めます。システム開発ではハの(2)「自己の有する専門的な技術若しくは経験に基づいて、業務を処理すること」で満たすのが一般的です。

見落としやすいのが料金の決め方です。疑義応答集（第1集）のQ8は、出来高精算は問題ないとしたうえで、業務に投入した労働者の人数を単価として請負料金を精算している場合は「単なる労働力の提供」として偽装請負と判断されると答えています。準委任で人月単価の契約にすること自体は直ちに違法ではありませんが、発注側が人数と時間だけを買い、中身の指示を自分で出している構図になると、この回答に近づきます。

第3条にも注意が要ります。形式的に2条の要件を整えていても、派遣法の規制を免れるために故意に偽装したものなら、労働者派遣事業と扱われると定めています。

偽装請負と判断されたときの罰則と発注者が負う労働契約申込みみなし制度

偽装請負の責任は受注者だけにとどまりません。発注者が刑事罰と民事上の効果の両方を負う可能性がある点を、条文で確認します。

職業安定法44条と労働者派遣法59条の罰則＝1年以下の拘禁刑か100万円以下の罰金

受注者側は、許可を受けずに労働者派遣事業を行ったものとして、労働者派遣法59条2号により「一年以下の拘禁刑又は百万円以下の罰金」の対象になります。刑法改正の施行により、2025年6月から懲役は拘禁刑に切り替わっています。

発注者側に効くのは職業安定法44条です。同条は労働者供給事業を行うことに加えて、供給される労働者を「自らの指揮命令の下に労働させ」ることも禁じており、64条10号で受注者と同じ1年以下の拘禁刑または100万円以下の罰金が定められています。派遣法24条の2も、許可のない事業主から派遣を受け入れることを禁じています。

労働者派遣法40条の6による直接雇用の申込みみなしと1年間撤回できない効果

発注者にとって実害が大きいのは、派遣法40条の6の労働契約申込みみなし制度です。1項5号は、派遣法の適用を免れる目的で請負その他労働者派遣以外の名目で契約を結び、労働者派遣の役務の提供を受けた場合、その時点で発注者が技術者に対して、同一の労働条件で労働契約を申し込んだものとみなすと定めています。

2項により、このみなし申込みは違法行為が終わった日から1年間撤回できません。技術者が承諾すれば、発注者との間に雇用関係が成立します。ただし、該当することを知らず、知らなかったことに過失がなかった場合は適用されません。「免れる目的」という主観の要件もあるため、すべての偽装請負に自動で当たるわけではありませんが、指揮命令の実態を知りながら放置していた場合には、過失なしと言える余地は小さくなります。

アジャイル開発・チャット・スキルシート：疑義応答集第3集が示す境界線

37号告示の疑義応答集のうち第3集は、アジャイル型開発を題材にした8問で構成されています。Q8で、Q1〜7の考え方は「アジャイル型開発以外のシステム開発を請負業務とする場合についても当てはまります」と答えており、ウォーターフォールの準委任やSESにもそのまま使えます。

対等な協働と自律的な判断があれば偽装請負にならないというQ2の基本線

疑義応答集（第3集）のQ2は、発注者側と受注者側が密に連携し、情報共有や技術的な助言・提案をしていても、両者が対等な関係で協働し、受注者側の開発担当者が自律的に判断して開発業務を行っているなら偽装請負とは判断されないとしています。

反対に、発注者側の開発責任者や開発担当者が、受注者側の開発担当者に業務の遂行方法や労働時間を直接指示すれば偽装請負です。予防策としてQ2は、双方の役割・権限・チーム内の進め方を事前に明確にして合意すること、アジャイル型開発の特徴について事前研修などで認識を揃えることを挙げています。プロダクトオーナーがバックログの優先順位を決め、スプリント内の順序は開発担当者が決めるという分担が、そのまま線引きになります。

会議・チャット・管理ツールで直接指示を出す場面がNGになる条件

Q6は、会議や打ち合わせ、電子メール、チャットツール、プロジェクト管理ツールに双方の関係者が全員参加していても、それだけで偽装請負にはならないと答えています。すべての会議に受注者側の管理責任者が同席する必要もありません。

線を越えるのは、そうした場で発注側から受注者側の担当者へ直接「この順で作業して」「今夜中に終わらせて」と指示した場合です。Q3は、進捗が遅れて仕事の割り付けや順序、緩急の調整が必要になったときは、受注者が管理責任者などを通じて自ら指示する必要があるとしています。Slackのチャンネルで発注側の担当者が受注者のエンジニアを名指しでタスクにアサインしている状態は、ツールの使い方そのものが代表型に近づくサインです。

スキルシートの提出要求と、個人の指名・就業拒否を分ける配置決定の線引き

Q7は、受注者側の技術力を判断するためにスキルシートの提出を求めることは、それが個人を特定できるものではなく、発注者が個々の労働者を指名したり就業を拒否したりできるものでなければ、直ちに偽装請負とはならないとしています。

一方で、発注者が特定の人を指名して業務に就かせたり、特定の人の就業を拒否したりすれば、37号告示1号ハ(2)の配置の決定に関与したことになり、適正な請負等とは認められません。SESでよく行われる「面談で人を選ぶ」運用は、氏名入りのスキルシートで個人を選ぶ形になっていないかを確認する必要があります。SES特有の商慣行についてはSESとは？契約形態と派遣・SIerの違いもあわせて参照してください。

発注側が契約前と稼働中に確認する偽装請負防止のチェックリスト

ここまでの条文と疑義応答集を、発注側が実際に確認する項目へ落とします。契約前に決めることと、稼働中に起きやすい行為に分けて並べました。

契約書と業務指示書に書くべき役割・権限・連絡窓口と成果の定義

契約前に、次の順で書面を整えます。

1. 業務の範囲と成果の定義（準委任なら作業内容と報告の形式、請負なら成果物と検収条件）
2. 受注者側の管理責任者の氏名と、不在時の代理者
3. 発注側から受注者側への依頼・変更・クレームはすべて管理責任者を通すという連絡経路
4. 勤怠管理・休暇承認・残業指示は受注者が行うという分担
5. 担当者の選任と交代は受注者が決めること、スキルシートは個人を特定しない形で受け取ること

特に3は、疑義応答集第1集のQ2が根拠になります。発注者が受注者に作業工程の見直しや作り直しを求めることは契約当事者間の注文なので問題ありませんが、発注者が請負労働者へ直接変更を指示すれば偽装請負です。同じ内容でも「誰に言うか」で結論が分かれます。

稼働中に起きやすいNG行為：勤怠承認・残業指示・タスクの直接割り振り

契約書が整っていても、稼働して数か月たつと現場の運用が崩れがちです。次の行為が1つでもあれば、運用を見直すべき状態です。

• 発注側の社員が受注者のエンジニアの勤怠表や休暇申請を承認している
• 発注側から受注者のエンジニアへ、残業や休日出勤を直接頼んでいる
• チケットやタスクを発注側が受注者の担当者個人へ直接アサインしている
• 発注側の上長が受注者のエンジニアの評価面談をしている
• 「あの人は外してほしい」と個人を名指しで交代させている

業務に関係のない日常会話は、第1集Q1のとおり指揮命令に当たりません。気にすべきは会話の量ではなく、指示の中身と宛先です。常駐体制での運用の線引きは客先常駐とは？派遣・SES・受託開発との違いと発注側の使い分けで、委託取引で守る代金・発注書面の義務は下請法とは？システム開発の委託で押さえる4義務・11禁止行為で扱っています。

派遣・準委任・請負のどれで発注するか：偽装請負を避ける契約形態の選び方

偽装請負の多くは、本当は派遣で受けるべき働き方を準委任の契約で回そうとして起きます。チェックリストで運用を正すより、最初に契約形態を正しく選ぶほうが確実です。判断は次の2通りに言い切れます。

日々の作業指示を自社で出したいなら最初から労働者派遣で契約する判断

自社の社員と同じチームに入れ、朝会でタスクを割り振り、優先度の変更も自社のリーダーが直接伝えたい。この運用を望むなら、準委任やSESで契約してはいけません。許可を持つ派遣元と労働者派遣契約を結ぶのが正解です。派遣なら発注者は派遣先として直接指示でき、偽装請負の問題は生じません。

代わりに、派遣先として同一組織での受け入れ期間の上限（いわゆる3年ルール）や派遣先責任者の選任といった義務を負います。派遣の仕組みとマージン・期間制限は派遣社員とは？仕組み・正社員との違い・給与とマージン率・3年ルールで、派遣先側の勤怠管理は派遣の勤怠管理システムとは？派遣元・派遣先の勤怠と二重派遣防止で解説しています。

準委任・SESで発注するなら窓口一本化と管理責任者の実働を条件にする判断

準委任やSESが向くのは、発注側が「何を作るか・何を優先するか」までを決め、「どう作るか・誰がいつやるか」を受注者に任せられる場合です。条件は2つあります。発注側からの依頼が必ず受注者の管理責任者を通ること、そして管理責任者が名前だけでなく実際に作業の割り振りと勤怠管理をしていることです。

この2条件を満たせない案件、たとえば受注者側が1名だけで管理責任者を置けない、発注側のリーダーが細かく作業順を指示しないと進まない、といった場合は準委任を見送り、派遣に切り替えるか、成果物を定義して請負で出すほうが安全です。一創の開発リソース提供（SES・準委任・技術者派遣）では、こうした運用の想定から、準委任と技術者派遣のどちらで受けるかを含めて相談を受け付けています。

偽装請負の相談先・客先常駐での判断基準・発注者の罰則についてよくある質問

発注側の担当者から寄せられやすい疑問を5つ取り上げます。

偽装請負かどうか迷ったときはどこに相談すればよいですか？

所在地を管轄する都道府県労働局が窓口です。厚生労働省の疑義応答集のページでも、疑義応答集に載っていない事例は各都道府県労働局が実態に即して個別に判断するとされ、問い合わせ先として労働局が案内されています。相談の前に、契約書、業務指示の経路（誰が誰にどのツールで依頼しているか）、勤怠の承認者を整理しておくと、判断に必要な事実を短時間で伝えられます。社内では法務部門か顧問の社会保険労務士・弁護士に確認する流れが一般的です。

客先常駐のSESは、それだけで偽装請負になりますか？

なりません。37号告示の第2条は、勤務場所が発注者の事務所かどうかを要件に挙げていません。判断されるのは、業務の遂行方法・労働時間・配置を誰が管理しているかです。常駐していても、受注者の管理責任者が作業を割り振り、勤怠を管理しているなら適法な準委任です。逆に、受注者の事務所で作業していても、発注側がチャットで直接作業順を指示していれば偽装請負になり得ます。

発注者が受注者のエンジニアと直接話すだけで偽装請負になりますか？

直接話すこと自体は問題ありません。疑義応答集第1集のQ1は業務に関係のない日常会話を指揮命令に当たらないとし、第3集のQ4・Q5は、プロダクトバックログの詳細説明や開発に必要な情報提供、対等な立場での技術的な議論や助言・提案も、それだけで偽装請負にはならないとしています。線を越えるのは、会話の中身が作業の進め方や労働時間についての指示になった場合です。

偽装請負で罰則を受けるのは発注者と受注者のどちらですか？

両方が対象になり得ます。受注者は無許可の労働者派遣事業として派遣法59条2号、発注者は供給された労働者を自らの指揮命令下で働かせたとして職業安定法44条・64条10号の対象で、いずれも1年以下の拘禁刑または100万円以下の罰金です。発注者には派遣法40条の6の労働契約申込みみなしも加わり、技術者が承諾すれば直接雇用が成立する点が、受注者側にはない固有の負担になります。

二重派遣と偽装請負はどう違いますか？

二重派遣は、派遣先が受け入れた派遣労働者をさらに別の会社へ派遣し、その会社の指揮命令下で働かせる形です。職業安定法44条が禁じる労働者供給に当たります。偽装請負は、請負や準委任の名目で実態は派遣をしている状態です。SESの多重下請けで、エンジニアが二次請け先や元請けから指示を受ける使用者不明型は、両方の性質を併せ持つことがあります。どちらも指示を出す主体が雇用主以外になっている点が共通しています。

関連記事

• 準委任契約とは？請負・派遣との違いとシステム開発での使い分けを解説：偽装請負を避ける前提となる準委任契約の基本
• SESとは？契約形態と派遣・SIerの違いを発注者視点で解説：SESの商流と発注側の注意点
• 客先常駐とは？派遣・SES・受託開発との違いと発注側の使い分け【2026年版】：常駐体制での指揮命令の線引き
• プライム案件とは？元請け・一次請けとの違いと発注者が直接発注すべきか解説：多重下請けの構造と使用者不明型の背景