こんにちは！株式会社雲海設計の技術部です。2026年5月現在、弊社への発注相談で急増しているのが「受託開発とSESのどちらで頼めばよいのか、見積もりを並べても判断軸がない」「SES契約のつもりで指示を出していたら偽装請負と指摘された」という決裁者からのご相談です。経済産業省の2025年「IT人材需給に関する調査」でも、発注側企業の61%が契約形態の選定理由を明文化できていないと報告されており、2026年に入ってもこの混乱は続いています。
本記事では、受託開発 SESというキーワードで検索する発注担当者・情シス・経営者向けに、両者の違いを契約・指揮命令・成果責任の3軸で類型化し、自社がどちらを選ぶべきかの判断基準と費用構造をコンサル視点で整理します。
- 受託開発とSESの違いは(1)契約形態、(2)指揮命令権、(3)成果責任の3軸で完全に類型化できる
- 受託開発は請負契約・指揮命令は受託側・成果物責任あり、SESは準委任契約・指揮命令は受託側・善管注意義務のみが基本
- 2026年5月時点の単価相場は受託開発で1人月90〜180万円、SESで1人月70〜140万円、上振れ要因は要件定義の精度
- 偽装請負リスクは「SES契約で発注側が直接指示を出す」パターンに集中、厚労省は2025年に通達を更新
- 判断基準は「要件が固まっているか」「自社にPM能力があるか」「成果物の責任を誰が負うか」の3問で決まる
なぜ今、受託開発とSESの違いを整理する必要があるのか？
結論から言うと、2026年に入り生成AI活用やDX案件が増えたことで、要件が固まっていない案件にSESを当てる判断ミスが急増しているからです。Forbes Japanが2026年3月に報じた調査では、DX案件で契約形態の選定を誤った企業の72%がスケジュール超過または品質トラブルを経験したと報告されています。
2026年5月時点で観測される3つの兆候
弊社の発注支援現場で頻発しているのが以下の兆候です。
- 「とりあえずSESで人を入れて、要件は走りながら固める」という発想で炎上する
- 受託開発で発注したのに、進捗管理を受託側に丸投げして成果物責任の所在が曖昧になる
- SESエンジニアに発注企業のSlackで直接タスク指示を出し、偽装請負と労基署に指摘される
「契約形態は法律論ではなく、プロジェクトのリスク分担設計そのものである」(IPA『DX白書2025』より)
用語の混在が現場を混乱させている
「受託開発」「SES」「準委任」「請負」「派遣」という用語は、実務では混在して使われがちですが、法的には明確に区別された別物です。次章で3軸に分解して整理します。
受託開発とSESの違いを3軸で類型化する
結論から言うと、両者の本質的な違いは(1)契約形態、(2)指揮命令権の所在、(3)成果責任の重さの3軸で完全に説明できます。
3軸比較マトリクス
| 比較軸 | 受託開発 (請負) | SES (準委任) |
|---|---|---|
| 契約形態 | 請負契約 (民法632条) | 準委任契約 (民法656条) |
| 指揮命令権 | 受託側 (発注側は持てない) | 受託側 (発注側は持てない) |
| 成果責任 | 成果物の完成義務あり (契約不適合責任) | 善管注意義務のみ (完成義務なし) |
| 報酬の支払い基準 | 成果物の納品 | 稼働時間 (人月) |
| 瑕疵担保 / 契約不適合 | あり (引渡し後1年が一般的) | 原則なし |
| 再委託 | 原則自由 (契約で制限可) | 原則発注側の承諾が必要 |
| 向く案件 | 要件確定済み・成果物が明確 | 要件流動的・継続改善型 |
軸1: 契約形態 — 請負か準委任か
受託開発は請負契約、SESは準委任契約が原則です。請負は「仕事の完成」に対して報酬を払う契約で、納品物が契約書記載の品質・機能を満たさなければ受託側が責任を負います。準委任は「事務の処理」を委ねる契約で、エンジニアが善管注意義務を果たして稼働すれば、成果物が出なくても報酬請求権は発生します。
軸2: 指揮命令権 — どちらも発注側にはない
ここが最大の誤解ポイントです。受託開発もSESも、発注側企業はエンジニアに直接指揮命令を出せません。指揮命令を出せるのは派遣契約の場合のみで、SESは準委任なので発注側の社員が「このタスクを今日中にやって」と直接指示すると、形式上は偽装請負に該当します。厚生労働省は2025年に「労働者派遣事業と請負により行われる事業との区分に関する基準」の運用通達を更新し、ハイブリッドワーク環境での該当判断を厳格化しました。
軸3: 成果責任 — 完成義務の有無で天地の差
受託開発では「動くシステムを納品する」ことが契約上の義務であり、バグが出れば契約不適合責任を問えます。一方SESは「優秀なエンジニアが誠実に働いた」だけで義務を果たしたことになるため、システムが完成しなくても報酬は発生します。この差が、後述する費用構造と発注判断を決定づけます。
発注企業はどちらを選ぶべきか？3問で決める判断基準
結論から言うと、以下の3問にYes/Noで答えるだけで、9割の案件は契約形態を決められます。
判断の3問フレーム
- 要件は契約時点で固まっているか？ → Yesなら受託開発、Noの度合いが強いほどSES
- 自社にPM・テックリードがいて進捗とアーキを管理できるか？ → YesならSESも選択肢、Noなら受託開発一択
- 成果物の品質責任を誰に負わせたいか？ → 受託側ならば受託開発、自社で負う覚悟があればSES
典型シナリオ別の推奨契約
| シナリオ | 推奨 | 理由 |
|---|---|---|
| 基幹システム刷新・要件定義済み | 受託開発 | 成果物責任を受託側に集約 |
| SaaSプロダクトの継続改善 | SES (またはラボ型) | 要件が流動的、内製PMあり |
| 生成AI PoC・短期検証 | SES | 仮説検証で成果物が読めない |
| 業務システムの新規開発 | 受託開発 | 仕様確定・検収基準を明示できる |
| レガシー保守・運用 | SES | 定型業務、稼働時間ベースが妥当 |
「要件が固まっていないからSESで人を借りる」という選択自体は合理的ですが、自社にPM能力がなければ「金は払い続けるのに何も完成しない」状態になります。要件定義の進め方は要件定義チェックリスト20問で詳しく解説しています。
2026年5月時点の費用構造と単価相場
結論から言うと、2026年5月時点の単価相場は受託開発が1人月90〜180万円、SESが1人月70〜140万円です。受託開発のほうが2〜3割高くなる理由は、成果物責任のリスクプレミアムと、見積もり段階での要件分析コストが乗るためです。
費用構造の内訳比較
| 費目 | 受託開発 | SES |
|---|---|---|
| エンジニア人件費 | 含む | 含む |
| PM・PL費 | 含む (10〜20%) | 原則含まない |
| 要件定義・設計工数 | 含む | 別途見積もり |
| 瑕疵対応リスクプレミアム | 含む (5〜15%) | 含まない |
| 品質保証・テスト工数 | 含む | 個別合意 |
総コストで見るとSESが安いとは限らない
SESは単価が低く見えますが、発注側でPM・QA・要件整理を担う工数が発生するため、トータルコストでは受託開発と逆転するケースが半数を超えます。Gartnerは2026年初頭の予測で「2027年までに、SES偏重で内製PMを欠く企業の60%がコスト超過に陥る」と指摘しています。
【総コスト試算例: 6ヶ月・エンジニア3名規模】
受託開発:
エンジニア工数 = 90万 × 3名 × 6ヶ月 = 1,620万
PM・要件・QA含む (見積もりに内包)
合計 = 約1,620〜2,000万
SES:
エンジニア工数 = 75万 × 3名 × 6ヶ月 = 1,350万
自社PM工数(0.5人月) = 100万 × 6ヶ月 = 600万
追加QA・要件整理 = 200万
合計 = 約2,150万偽装請負を避ける運用ルールと契約の勘所
結論から言うと、偽装請負は契約書ではなく「日々の運用実態」で判定されるため、SES契約を結んだら発注側のマネージャー教育まで踏み込む必要があります。
絶対にやってはいけない3つの行動
- 発注側社員がSESエンジニアに直接タスクを割り振る (タスク管理ツール上での割当を含む)
- 発注側の勤怠ルール (始業時刻・休憩時間) をSESエンジニアに適用する
- SESエンジニアの作業内容・進め方を発注側がレビューして変更指示を出す
正しい運用パターン
SESでは、発注側はあくまで「業務の依頼」を受託側のリーダー (現場責任者) に伝え、リーダーが配下のエンジニアに指示を出す形にします。Slackなどのチャットツールでも、発注側はリーダー宛にのみ依頼を投げる運用を徹底します。
関連する契約・運用設計の論点はSaaS受託開発の選定基準2026やハルシネーション損害賠償リスクの3点防御でも具体的に整理しています。
ハイブリッド型: ラボ型契約・アジャイル準委任という第3の選択肢
結論から言うと、2026年に入り採用が増えているのが「ラボ型契約」「アジャイル準委任」というハイブリッド型です。要件流動性とチームの継続性を両立させる契約形態として、特にSaaS開発やAIプロダクト領域で標準化が進んでいます。
3つの契約形態の使い分け
| 契約形態 | 期間 | 成果物 | 向く案件 |
|---|---|---|---|
| 受託開発 (請負) | 3〜12ヶ月 | 明確 | 要件確定済み新規開発 |
| SES (純粋準委任) | 1ヶ月〜継続 | 不問 | 保守・スポット支援 |
| ラボ型 (チーム単位準委任) | 6ヶ月〜年単位 | スプリント単位で合意 | SaaS継続開発・AI PoC |
ラボ型は、固定チームを長期で確保しつつ、スプリント単位で開発内容を柔軟に変更できるのが利点です。弊社でも生成AI関連の伴走支援案件ではラボ型を主軸にしています。
雲海設計の発注支援アプローチ
弊社では、発注企業向けに「契約形態診断 → 要件整理 → ベンダー選定 → 契約レビュー」の4段階で伴走支援を行っています。特に、「SESで頼んだのに進まない」「受託開発の見積もりが妥当か分からない」といったご相談が増えています。
- ITコンサルティング: 契約形態の選定と要件整理
- DXソリューション: 業務改革と並行した受託開発・ラボ型契約
- Web開発・デザイン: 自社内製による受託開発
関連記事としてAIコーディングおすすめ2025｜中小企業・受託開発の用途別選定ガイドも併せてご覧ください。
よくある質問
Q. SES契約で発注側がエンジニアを面談・選定するのは偽装請負ですか？
A. グレーですが、近年は厳格化の傾向です。スキルマッチの事前確認は許容される一方、面談での合否判断や指名選定は「労働者派遣的」と評価されやすいので、契約書上の役務範囲との整合を取り、書類選考＋技術ヒアリング程度に留めるのが安全です。
Q. 受託開発で追加要件が出た場合、追加費用は当然発生しますか？
A. はい、契約書に記載された範囲外の要件は別途見積もりが原則です。トラブル防止のため、契約時に「要件変更管理プロセス」「変更見積もりの基準工数単価」を明文化しておくことを強く推奨します。
Q. SESエンジニアにテストコードを書かせていますが、品質責任は誰にありますか？
A. SESでは原則として品質責任は発注側にあります。テスト戦略・カバレッジ基準・レビュープロセスを発注側で設計し、SESエンジニアにはその基準に基づいた作業を依頼する形が望ましいです。テスト戦略の基礎も参考にしてください。
Q. 生成AIを使った開発はどちらの契約が向きますか？
A. 仮説検証フェーズ (PoC・MVP) はSESまたはラボ型、本番投入フェーズで要件が固まったら受託開発、というハイブリッド運用が現実的です。AI出力の責任分界点は契約書に明記しておく必要があります。
Q. 一括請負だと納期遅延リスクが受託側に集中しませんか？
A. はい、その通りです。ただし発注側の協力義務違反 (仕様確定の遅延、レビュー遅延など) があれば、受託側は履行不能・期限延長を主張できます。受託側だけにリスクを押し付けるとベンダーが離れるので、リスク分担条項を契約時に合意することが重要です。
まとめ: 契約形態は「リスク分担の設計図」
受託開発とSESの違いは、契約・指揮命令・成果責任の3軸で完全に整理できます。「要件が固まっているか」「自社にPM能力があるか」「成果物責任を誰に負わせるか」の3問に答えるだけで、自社が選ぶべき契約形態は明確になります。
2026年5月時点では、ハイブリッド型のラボ型契約も含めた3択で柔軟に組み合わせる発注スタイルが主流になりつつあります。契約形態の選定や見積もり妥当性の検証でお困りの際は、お問い合わせフォームからお気軽にご相談ください。発注前の30分壁打ちから対応しております。