LASSIC Media らしくメディア

LASSIC IT事業部｜元請（プライムベンダー）としてシステム保守・運用を受託

偽装請負とは何か——37号告示が定める2つの要件

システム開発における偽装請負とは、契約書に「業務委託」「準委任」「請負」と記載されていながら、現場の実態が労働者派遣に該当する状態を指します。厚生労働省は昭和61年労働省告示第37号（以下、37号告示）で「労働者派遣事業と請負により行われる事業との区分に関する基準」を定めており^*1、偽装請負の判断はこの告示に基づく2つの要件の充足で行われます。

37号告示が定める要件1：指揮命令の独立性

37号告示の第1の要件は、受託者が自社の従業員に対して指揮命令を自ら行うことです^*1。具体的には次の3点を受託者が独立して実施していなければなりません。

• 業務の遂行方法（作業の順序・手順・優先度）について自ら指示していること
• 労働時間・休暇・残業の管理を自ら行っていること
• 服務規律（遅刻・欠勤・守秘義務等の企業秩序）の維持を自ら行っていること

発注者が受託者の個々のエンジニアに直接日次タスクを指示したり、勤怠承認を発注者システム上で行ったりしている場合は、この要件を満たしていないと判断される可能性があります。

37号告示が定める要件2：事業処理の独立性

第2の要件は、受託者が事業主として独立して業務を処理していることです^*1。次の3点が問われます。

• 業務遂行に必要な資金を自ら調達・支弁していること
• 単なる労働力の提供ではなく、専門技術・ノウハウ・機器等を提供して業務を処理していること
• 事業主として法的責任（瑕疵・損害・労働安全衛生）を自ら負っていること

受託者が発注者から機材を無償提供されていたり、成果物に固有の専門性がなく人員を提供するだけの実態になっていたりする場合は、独立性が否定される要因となります。

IT・SES・客先常駐で偽装請負と判定される4パターン

厚生労働省の37号告示関係疑義応答集^*2では、アジャイル型開発を含むITプロジェクト特有のシナリオが取り上げられています。実務上、偽装請負リスクが高まる典型的な4つのパターンを整理します。

パターン①：発注者が個々のエンジニアに直接タスク指示

チャットツール（Slack・Teams等）や日次スタンドアップミーティングで、発注者側の社員が受託者のエンジニアに個別に作業指示を出すケースです。管理責任者を経由せず「今日はこの機能を実装してください」と直接指示する運用は、指揮命令権が発注者側に帰属しているとみなされます。

アジャイル開発でのプロダクトオーナーによるタスク割り当ても、受託者の管理責任者の了解なく行われる場合はリスクとなります。発注者とエンジニアのチャット履歴・議事録が証拠として残ることも念頭に置く必要があります。

パターン②：管理責任者が形式上のみで実質指揮が発注者側

受託者側に名目上の「現場リーダー」を置いていても、実際の業務指示・評価・配置決定のすべてが発注者側に集約されているケースです。リーダーが情報を伝達するだけで自らの判断を介在させていない場合、「管理責任者が業務遂行に関する指示・管理・交渉等の権限を有する」という要件を満たさないと判断されます^*3。

このパターンは長期常駐案件で発生しやすく、発注者・受託者双方の担当者が「これが当たり前」と感じていても違法状態が継続することがあります。

パターン③：「顔合わせ」名目の事前選考・個人指名

発注者が受託者の特定エンジニアを業務委託前に面談し、スキル・適性を評価したうえで「この人で」と指名するケースです。労働者派遣では派遣先が特定個人を選考することは原則として禁止されており（労働者派遣法第26条第6項）、業務委託・請負の形式をとっていても個人選考の実態があると偽装請負の一因となります。

「顔合わせ」の位置づけを事前に取り決めず、スキルシートの詳細評価・コーディングテストを発注者が実施している場合は特に注意が必要です。

パターン④：発注者側システムで勤怠・評価を一元管理

受託者のエンジニアが発注者の勤怠管理システムに打刻し、発注者の上長が残業申請を承認する運用は、労働時間管理の主体が発注者側にある状態です。同様に、人事評価・業務成績の査定を発注者が直接行っている場合も独立性を欠くと判断されます。

発注者提供のPCや業務ツールを受託者が使用すること自体は直ちに違法とはなりませんが、これらが重なると偽装請負の総合判断に影響します。

発注者が直面する3つのリスク——行政・刑事・直接雇用

偽装請負が発覚した場合、発注者（注文者）は3つの次元でリスクを負います。特に直接雇用リスクは経営に直結するため、発注担当者だけでなく人事・法務部門が把握すべき内容です。

リスク①：行政指導・勧告・企業名公表

都道府県労働局や労働基準監督署の調査で偽装請負と認定された場合、まず行政指導（是正指導）が行われます。指導に従わない場合は勧告、さらに改善されない場合は企業名が公表されることがあります。

企業名公表はブランドイメージや採用活動への影響が大きく、取引先との契約見直しに発展する可能性もあります。監督署への申告は受託者側の従業員からも行われるため、現場の実態管理が対策の出発点となります。

リスク②：労働者派遣法・職業安定法・労基法の刑事罰

偽装請負に関連する法令違反には複数の罰則が設けられています^*4。

• 労働者派遣法違反（無許可の派遣供給）：1年以下の拘禁刑または100万円以下の罰金
• 職業安定法違反（労働者供給事業の違法実施）：供給元・供給先の双方に1年以下の拘禁刑または100万円以下の罰金
• 労働基準法違反（中間搾取の禁止）：1年以下の拘禁刑または50万円以下の罰金

受注者が労働者派遣事業の許可を取得していない場合、許可なく派遣事業を行ったとして受注者側にも罰則が科される可能性があります（労働者派遣法第59条2号・第62条）。発注者・受注者の双方が当事者となる点に留意が必要です。

リスク③：労働契約申込みみなし制度による直接雇用義務

3つのリスクの中で経営インパクトが特に大きいのが、労働者派遣法第40条の6に基づく「労働契約申込みみなし制度」です。偽装請負など一定の違法行為があった場合、発注者（受け入れ側）は受託者のエンジニアに対して直接雇用の労働契約を申し込んだとみなされます^*3。

当該エンジニアが承諾すれば、その時点で発注者との直接雇用契約が成立します。長期間にわたる偽装請負では「発注者が偽装請負を目的として行為した」と推認されるとした裁判例も存在します^*3。長期常駐の外注エンジニアが突然直接雇用の対象となるリスクは、人員計画・コスト構造に大きな影響を与えます。

準委任・請負・派遣——契約形態ごとの指揮命令の線引き

システム開発では案件・フェーズによって複数の契約形態が混在します。それぞれの指揮命令権・成果責任・法的許可の違いを整理します。

IT開発では要件定義・設計フェーズを準委任契約、実装・テストフェーズを請負契約とするなど、フェーズで契約形態を使い分けることがあります。その場合も各フェーズで上記の要件が満たされているかを都度確認することが重要です。

なお、発注者が特定のエンジニアに直接業務指示を出したいのであれば、派遣法に基づく許可を得た派遣会社からの派遣契約に切り替えることが適法な選択肢となります。

発注側が取るべき偽装請負回避の4ステップ

偽装請負リスクを回避するには、契約書の整備だけでなく現場運用レベルの体制設計が欠かせません。発注側が実施すべき4つのステップを整理します。

ステップ1：管理責任者の設置と権限の文書化

37号告示では、受託者が「業務遂行に関する指示・労働者の管理・発注者との交渉等の権限を有する管理責任者」を置く場合、発注者はその責任者を通じて指示を伝えることができると定めています^*1。この要件を満たすには、管理責任者の氏名・権限範囲・連絡窓口を契約書または業務委託仕様書に明記することが出発点となります。

名目だけの責任者では要件を満たしません。責任者が実際に受託者側の判断として業務を采配できる権限と実態が伴っている必要があります。

ステップ2：指示・連絡ルートの一本化と記録

発注者担当者が受託者のエンジニアに直接連絡できるチャット環境は、偽装請負の温床となります。運用ルールとして「発注者からの業務依頼は管理責任者宛にのみ送る」「エンジニア個人への直接タスク指示は行わない」を明文化し、チャットルールとして周知します。

指示ログ・議事録・勤怠承認記録は、適法性の証拠としても機能します。特に長期常駐案件では四半期ごとに指示ルートの記録を点検し、逸脱がないかを確認することを推奨します。

ステップ3：定期的な現場実態監査（四半期点検）

契約書と現場運用の乖離は時間の経過とともに生じやすいため、定期的な現場実態監査が必要です。確認すべき項目は次のとおりです。

• 誰が日次・週次のタスク割り当てを行っているか
• 勤怠申請の承認者は受託者側か発注者側か
• 業務評価・面談を発注者側が直接行っていないか
• 受託者の管理責任者が実質的な判断権限を行使しているか

問題が見つかった場合は速やかに是正し、その経緯を記録に残すことで、万一の調査においても適法性を示す根拠となります。

ステップ4：アジャイル開発での合意形成議事録の保全

アジャイル型開発ではスプリント計画・デイリースクラム等で発注者・受託者が頻繁にやり取りします。厚生労働省の疑義応答集（第3集）^*2では、アジャイル開発における受発注の適正な運用方法についてQ&Aが収録されており、合意形成の透明性と議事録保全が適法性の根拠となることが示されています。

スプリントレビューで発注者が成果物への意見を述べることは、直接の業務指示とは区別されます。ただし、その意見が管理責任者を経由せずにエンジニアへの指示として機能している場合は法的解釈が難しい領域となるため、受託者の管理責任者が意思決定の主体であることを議事録に明示することが大切です。

LASSICが元請（プライムベンダー）として担う偽装請負リスク管理

多重下請け構造が慣行となっているIT業界では、元請企業の体制設計が偽装請負リスクを左右します。発注者が1社の元請（プライムベンダー）と契約し、二次・三次請けの管理を元請に委ねる体制は、指揮命令の経路を整理する観点からも有効です。

LASSICは元請（プライムベンダー）として、発注者と直接契約を結び、案件に応じた管理責任者の設置・体制図の提示・現場指示ルートの整備を行います。発注者が二次・三次のエンジニアと直接やり取りする状況を避け、法的責任の所在を明確化することが、偽装請負リスクの遮断につながります。

発注担当者が「どこまで指示してよいか」を迷う場面では、管理責任者への事前確認フローを設けることで、日常業務レベルでの逸脱を防ぐことができます。

まとめ——偽装請負リスク回避の3つの判断軸

本稿では、システム開発における偽装請負リスクを37号告示の2要件から解説し、IT・SES現場での4パターン、発注者が直面する3種類のリスク、そして回避のための4ステップを整理しました。要点を3つの判断軸に集約します。

第一に、指揮命令の実態で判断されるという原則です。契約書の名称ではなく、誰が誰に業務指示を出しているかという現場の実態が法的判断の基準となります。管理責任者を経由しない直接指示は、どれほど軽微であっても偽装請負リスクを積み上げます。

第二に、直接雇用リスクを最重大リスクとして位置づけることです。罰則よりも経営インパクトが大きい労働契約申込みみなし制度は、長期常駐案件ほど顕在化しやすい性質があります。現場担当者任せにせず、法務・人事が定期的に関与する体制が求められます。

第三に、体制設計と記録保全がリスク回避の実務であるという認識です。管理責任者の設置・指示ルートの文書化・四半期監査・議事録保全という4ステップは、偽装請負の予防と万一の調査対応の両方に機能します。

よくある質問

著者：テレリモ総研編集部　鈴木 亮佑

ご不明な点はお問い合わせフォームからもご連絡いただけます。

1. *1　出典：厚生労働省「労働者派遣・請負を適正に行うためのガイド（昭和61年労働省告示第37号）」
2. *2　出典：厚生労働省「37号告示に関する疑義応答集（第3集・令和8年5月更新）」
3. *3　出典：TMI総合法律事務所「偽装請負の判断基準と違反のリスク」（2024年）
4. *4　出典：keiyaku-watch「偽装請負とは？違法性の判断基準・問題点・罰則・事業者の注意点などを解説」

Tweet