SES契約における
多重下請構造の注意点

SESは、一般にSystem Engineering Serviceの略称として用いられ、ITエンジニアがシステム開発、インフラ構築、運用保守、テスト、PMO、ヘルプデスク、セキュリティ対応などに関与する役務提供型の取引を指します。ただし、SESは法律上の独立した契約類型ではありません。

重要なのは、契約書のタイトルではなく実態です。誰がエンジニアに指示を出すのか、誰が勤怠・休暇・残業・配置を管理するのか、成果物の完成を約束しているのか、専門的な注意義務をもって役務を提供するのかで法的評価が変わります。

次の比較表は、SES契約で混同されやすい契約類型を整理したものです。読者にとって重要なのは、名称ではなく、報酬条件、検査の有無、指揮命令、勤怠管理、成果物の扱いを照合することです。列ごとに契約の中心とリスクを比較し、自社の運用がどの列に近いかを読み取ってください。

多重下請構造とは、エンドユーザー、元請ITベンダー、一次下請SES会社、二次下請SES会社、三次下請SES会社、個人事業主エンジニア又は最終下請会社の従業員が縦に連なる状態をいいます。公正取引委員会のソフトウェア業調査でも、SESでは商流上五社程度が中間に入る例があるとされています。

次の時系列は、典型的な多重下請の連なりを上流から実作業者まで表しています。順番に意味があり、上流に近いほど発注・価格・契約条件を決めやすく、下流に近いほど実作業と情報アクセスを担いやすくなります。この距離が広がるほど、責任と情報のずれを読み取る必要があります。

偽装請負とは、契約書上は請負や準委任の形を取りながら、実態として発注者が受託会社の労働者に直接指揮命令を行い、労働者派遣に近い状態になることをいいます。厚生労働省の資料でも、契約形式ではなく実態に即して判断されると説明されています。

発注者とエンジニアが一切会話できないわけではありません。仕様確認、障害状況の共有、レビュー、技術的説明は実務上必要です。問題は、情報共有を超えて、作業方法、作業順序、勤務時間、休暇、残業、評価、配置を発注者が個人へ直接命じることです。

次の比較表は、適正な準委任・請負に近い運用と、偽装請負リスクが高い運用を並べています。列の左右に意味があり、左は受託者の管理責任が残る状態、右は発注者の労務指揮に寄る状態です。自社の会議、チャット、チケット、勤怠承認がどちらに近いかを読み取ってください。

次の判断の流れは、二重派遣・労働者供給リスクを見つけるための確認順序を表しています。上から順番に事実を確認することが重要で、途中で発注者や上位会社の直接指揮命令が見つかるほど、契約スキームの見直しが必要になります。

アジャイル開発や緊急障害対応では、発注者と受託者側の技術者が密接に協働します。この場合でも、発注者がプロダクト価値、優先順位、受入条件を示すことと、受託者が自社メンバーの作業方法、役割分担、勤務管理を行うことを分ける必要があります。

多重下請構造では、上流から下流へ価格が順に下がり、中間会社が複数入るほど、最終受託者やエンジニアに十分な対価が届かないことがあります。価格が低すぎると、品質低下、過重労働、虚偽経歴、無理な再委託、契約外作業の押し付けにつながります。

2026年1月1日から、下請法は中小受託取引適正化法、通称取適法として施行されています。SES契約やソフトウェア開発委託では、取引内容と当事者規模により適用可能性を確認する必要があります。労働者派遣法に基づく派遣を受ける取引は、一般に取適法上の製造委託等には該当しないとされるため、SESと派遣の区別も重要です。

次の比較表は、取引適正化で問題になりやすい運用を整理しています。読者にとって重要なのは、単価交渉だけでなく、発注時点、作業開始後、支払時点の各場面にリスクがあることです。左の場面と右の問題を照合し、自社の注文書・請求処理に記録が残っているかを読み取ってください。

次の時系列は、価格協議を記録する実務の順番を表しています。順番に意味があり、申入れ、根拠、回答、協議、結論が欠けると、後から一方的な単価決定と見られるリスクがあります。どの段階の証跡が不足しているかを読み取ってください。

SES契約は役務提供型であっても、ソースコード、設計書、テスト仕様書、運用手順書、構成図、スクリプト、設定ファイル、議事録、調査レポート、障害分析資料などが発生します。これらの権利帰属を定めていないと、発注者の利用権、受託者の再利用、再委託先からの権利移転、OSSや第三者コードの扱いが不明確になります。

エンドユーザーが元請から著作権譲渡を受ける契約を締結していても、元請が一次下請から権利譲渡を受けていなければ、上流へ有効に権利を移せない可能性があります。個人事業主エンジニアが成果物を作る場合は、本人との契約で著作権、利用許諾、著作者人格権不行使、OSS利用ルールを定める必要があります。

次の表は、成果物・知財・事故責任で確認すべき論点を整理しています。読者にとって重要なのは、権利と責任を別々に見ないことです。各行の「確認すること」を見て、上流契約と下流契約で同じ義務がつながっているかを読み取ってください。

次の重要ポイントは、損害賠償条項で特に交渉になりやすい事項をまとめています。金額だけを見るのではなく、秘密保持、個人情報、知財侵害、故意・重過失、再委託先行為、保険加入を分けることが重要です。通常の上限と例外の切り分けを読み取ってください。

SES契約における多重下請構造では、契約書よりも現場の実態が問題を示すことがあります。発注者社員が下請エンジニアの出退勤を直接管理している、体制図にない人物がリポジトリへアクセスしている、注文書が作業開始後に出ている、といった兆候は早めに確認すべきです。

赤信号は、指揮命令、商流、価格・支払、情報管理、知的財産に分かれます。どれか一つでも見つかった場合、同じ案件の他の項目にも問題がないかを横断的に確認する必要があります。

次のリスク一覧は、現場で見つけやすい赤信号を領域別に整理したものです。読者にとって重要なのは、各項目が証拠に残りやすい点です。チケット、チャット、勤怠、請求、アクセスログ、体制図のどこに痕跡があるかを読み取ってください。

次の比較一覧は、典型的なケースを実務判断に使いやすい形で整理したものです。ケースごとに、適正要素、問題要素、必要対応を比べることが重要です。自社案件がどの例に近いかを読み取ってください。

Q1. SES契約の多重下請は違法ですか。

一般的には、多重下請構造そのものが直ちに違法とされるわけではありません。ただし、商流の深さ、再委託承諾、指揮命令、取引条件、情報管理、個人情報の取扱いによって結論が変わる可能性があります。具体的な契約設計や是正方針は、契約書と運用資料を整理したうえで弁護士等の専門家へ相談する必要があります。

Q2. 発注者は下請エンジニアと直接話してはいけませんか。

一般的には、仕様確認、障害状況の共有、技術的な事実確認などのコミュニケーション自体が直ちに問題になるとは限りません。ただし、作業方法、作業順序、勤怠、残業、休暇、評価、配置を直接決めると、指揮命令性が強まる可能性があります。具体的な運用は、会議体やチャットの実態を確認したうえで専門家に相談する必要があります。

Q3. 再委託を許可する場合、何を確認すればよいですか。

一般的には、再委託先の名称、所在地、業務範囲、担当者、個人情報取扱い、国外アクセス、セキュリティ体制、再々委託の有無、同等義務の流し込みを確認することが重要とされています。ただし、システム重要度や扱う情報の性質によって必要な管理水準は変わります。具体的には専門家やセキュリティ担当者と確認する必要があります。

Q4. 個人事業主エンジニアが含まれる場合の注意点は何ですか。

一般的には、取引条件の明示、報酬支払期日、不当な減額や無償やり直しの回避、ハラスメント対応、秘密保持、個人情報、知的財産、労働者性の確認が重要とされています。ただし、契約形態、勤務実態、指揮命令、報酬設計によって判断は変わります。具体的な対応は資料を整理したうえで専門家に相談する必要があります。

Q5. 情報漏えいが起きた場合、誰が責任を負いますか。

一般的には、契約上の責任分担、再委託先管理、アクセス権限、事故原因、故意又は過失、個人情報の取扱い状況によって判断されます。上流契約だけでなく下流契約、ログ、体制図、再委託承諾の有無も重要です。具体的な責任範囲や対応方針は、事実関係を確認したうえで弁護士等の専門家へ相談する必要があります。

Q6. 実態が派遣に近い場合はどうすればよいですか。

一般的には、実態が発注者による直接指揮命令を前提としている場合、準委任や請負のまま形式だけ整えるのではなく、適法な労働者派遣、直接雇用、請負型の業務切分けなどを検討する必要があります。ただし、具体的な切替え方法は契約関係や現場運用で変わるため、専門家の確認が必要です。