受託開発とSESの違い｜契約・責任・費用を比較、発注側の使い分けと注意点

開発を外に頼みたいが、「受託開発」と「SES」の見積もりが並んで出てきて、どちらを選べばいいのか分からない。片方は総額、もう片方は月額の人数分。そもそも同じ土俵で比べていいのか。発注の初期に必ず出てくる疑問です。

結論から言えば、対価が「成果物」に対して支払われるのか、「業務の遂行」に対して支払われるのかという一点が両者を分けています。ここから契約形態も、責任の範囲も、指示の出し方も派生します。

本記事では、受託開発とSESの違いを契約と責任の観点で整理し、それぞれのメリットとデメリット、使い分けの判断軸、費用構造の違い、そして発注側が最も注意すべき偽装請負の論点までをまとめます。自社の案件がどちらに向くかを判断できる状態を目指しています。

確認したいポイント	結論	詳細
受託開発とSESの最大の違いは？	対価が成果物か、業務の遂行かの違い	受託開発は完成責任を負う請負契約、SESは業務の遂行に対価が発生する準委任契約です。他の違いはここから派生します。
責任範囲はどう違う？	契約不適合責任か、善管注意義務か	受託開発は納品物の不具合に責任を負います。SESは完成責任こそ負いませんが、注意義務違反があれば責任を問われます。
どちらを選ぶべき？	仕様が固まっているなら受託、未確定ならSES	社内に進行を管理できる人がいるかも判断材料になります。実務では工程ごとに使い分けるのが一般的です。
発注側が最も注意すべき点は？	エンジニアへ直接指示を出さないこと	SESでは指揮命令権は受託企業側にあります。発注側が直接指示すると、偽装請負と判断されるおそれがあります。

この記事でわかること

• 受託開発とSESを分ける「対価の対象」という一点と、そこから派生する違い
• 請負契約と準委任契約の責任範囲、契約不適合責任と善管注意義務の差
• それぞれのメリット・デメリットと、工程別の使い分け
• 偽装請負と判断されないために発注側が守るべき運用
• 総額と人月単価という費用構造の違いと、比較のしかた

自社の案件は受託開発とSESのどちらが向くか。事業相談の初回は無料で対応しています。

受託開発とSESの違いを一言でいうと

両者は同じ「開発を外部に頼む」手段ですが、契約の目的がそもそも違います。ここを混同したまま見積もりを比較すると、判断を誤ります。

対価の対象が「成果物」か「業務の遂行」か

受託開発は、納品物の完成に対して報酬が発生します。クライアントから依頼を受け、システム開発という仕事そのものを請け負う形です。何を作るかが決まっていて、それを完成させることが契約の目的になります。

SESは、エンジニアの業務遂行そのものに対価が支払われます。技術者の労働力を提供する契約であり、成果物の完成責任は負いません。報酬の対象が労働時間である点が、受託開発との決定的な差です。

この違いから、他のすべての差が派生します。契約形態、責任範囲、指示の出し方、費用の計算方法。まず「何に対してお金を払っているのか」を押さえてください。

契約形態は請負と準委任

受託開発は請負契約が基本です。請負人は仕事の完成を約束し、その履行について法的責任を負います。完成しなければ、原則として報酬を請求できません。

SESは準委任契約にあたります。合意された業務を、善良な管理者の注意をもって遂行することに対して対価と責任が発生します。受任者は仕事の完成に対して法的責任を負いません。

責任の違いは契約不適合責任と善管注意義務

受託開発には契約不適合責任があります。納品したプログラムに不具合があった場合、修補や損害賠償などの責任を負う必要があります。発注側から見れば、品質のリスクを相手が引き受けている状態です。

一方SESでは、納品物に対する責任を理由に損害賠償を請求されることはありません。ただし、善管注意義務に違反があった場合は責任を問われる可能性があります。責任がゼロなのではなく、責任の性質が違うと理解してください。

指揮命令権の所在

実務で最も重要な違いがここです。SESでも受託開発でも、エンジニアへの指揮命令権は受託企業側にあります。発注側が直接、業務の進め方や労働時間を指示すると、法的な問題が生じます。

「常駐しているのだから自社の社員のように指示できる」という誤解は、後の章で扱う偽装請負に直結します。ここは契約書の書き方ではなく、日々のやり取りの実態で判断されます。

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

受託開発のメリットとデメリット

開発リソースを社内に持たない、あるいは確保できない場合に、仕事そのものを外に出すのが受託開発です。発注側から見た利点と弱点を整理します。

メリット：予算計画が立てやすく、品質責任を任せられる

報酬と支払い期限が決まっているため、予算計画を立てやすいのが利点です。相談、見積もり、正式発注、開発開始という流れがある程度決まっており、計画的に進められます。

加えて、完成責任と契約不適合責任を相手が負うため、品質面のリスクを移転できます。社内に管理できる人が少ない場合、この点は大きな安心材料になります。

デメリット1：仕様変更に弱い

請負契約は「決まったものを作る」前提です。開発途中の仕様変更には追加見積もりが必要になり、そのたびに費用と時間が発生します。作りながら決めたい案件とは相性がよくありません。

回避策は、要件定義を独立した工程として先に切り出し、そこで作るものを確定させてから開発を発注することです。変更管理の手続きを契約時に定めておくことも欠かせません。

デメリット2：社内にノウハウが残らない

開発を完全に外部へ委託すると、社内のエンジニアが開発に関わる機会がなくなります。エンジニアがスキルアップせず、社内にノウハウが蓄積されない環境が定着するという指摘があります。

社内にエンジニアがいる企業なら、一部の工程は自社で担当し、経験を積める形にする工夫が必要です。運用フェーズだけでも社内に移す設計にしておくと、依存を抑えられます。

デメリット3：進捗が見えにくい

開発の実務が社外で進むため、意識して情報を取りにいかないと状況が把握できません。「順調です」という報告だけが続き、終盤で問題が判明するというのはよくあるパターンです。マイルストーンと中間成果物の確認を契約に含めてください。

SESのメリットとデメリット

自社のリソースだけでは不足する専門スキルを補う目的で使われるのがSESです。受託開発とは向く場面が異なります。

メリット1：即戦力を、育成コストなしで確保できる

自社で人材を育成する手間を省きながら、不足している開発技術をピンポイントで確保できます。採用に半年から1年かかることを考えると、時間を買っているという見方が正確です。

メリット2：体制を柔軟に変更できる

プロジェクトの状況に応じて、増員も縮小も比較的しやすい形態です。フェーズによって必要なスキルが変わる場合にも対応できます。長期の固定費を抱えずに済むのが利点です。

メリット3：要件が固まっていなくても進められる

業務の実施そのものが契約の対象であるため、要件が定まりきっていない段階や、途中の仕様変更にも柔軟に対応できます。探索的に進める案件、運用しながら改善していく案件と相性がよい形態です。

デメリット1：完成責任がない

期日までに動くものができる保証はありません。進行管理と品質管理は発注側が担う前提になります。社内にプロジェクトを見られる人がいないと、時間だけが過ぎることになります。

デメリット2：成果にばらつきが出る

同じ単価でも、参画するエンジニアのスキルによって成果は変わります。事前に経歴を確認し、可能であれば面談の機会を設けてください。合わない場合の交代について、契約時に取り決めておくことも有効です。

デメリット3：長期になると総額が膨らむ

月額の積み上げであるため、期間が延びればそのまま費用が増えます。受託開発なら総額が確定していた案件が、SESでは青天井になり得るという点は認識しておいてください。期間の目安と、継続判断のタイミングを決めておきます。

受託開発とSESのどちらが自社の案件に向くか。要件の固まり具合と社内体制から整理します。事業相談の初回は無料です。

使い分けの判断軸と、工程別の考え方

どちらが優れているという話ではありません。案件の性質と社内の体制で決まります。判断の順序を示します。

軸1：仕様がどこまで固まっているか

最も強い判断軸です。作るものが明確なら受託開発、まだ探りながら決める段階ならSES。分からないものを請負契約で発注すると、追加見積もりの連続になり、双方が疲弊します。

軸2：社内に進行を管理できる人がいるか

SESは進行管理を発注側が担う前提です。仕様を伝え、優先順位を決め、成果を確認する役割が社内に必要になります。この役割を置けないなら、完成責任を持つ受託開発を選ぶほうが安全です。

軸3：期間と体制の変動性

短期集中で作り切る案件なら受託開発、継続的に開発量があり体制を伸縮させたい案件ならSESが向きます。プロダクトを長期で育てていく形なら、SESまたはラボ型のほうが噛み合います。

工程ごとに使い分けるのが実務的

実際には、どちらか一方に決める必要はありません。要件が定まっていない要件定義は準委任、作るものが決まった設計・製造は請負、継続業務である運用保守は準委任という使い分けが、実務では標準的です。

SES契約は「完成品の存在しない業務」に適しています。テスト、運用保守、既存システムの改善といった領域は、成果物で区切りにくいためSESが機能します。逆に、設計やプログラミングのように成果物が明確な製造工程は請負が向きます。

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

混同されやすい他の形態との違い

受託開発とSESの周辺には、似て非なる形態がいくつかあります。並べて整理しておくと、提案を受けたときに位置づけが分かります。

労働者派遣との違い

SESと最も混同されやすいのが労働者派遣です。決定的な違いは指揮命令権の所在にあります。派遣では、派遣先が労働者に直接指揮命令を行い、それが法的に認められています。

SES（準委任）では、指揮命令権は受託企業側にあります。つまり、派遣なら適法な直接指示が、SESでは違法になり得るということです。同じ常駐でも、扱いがまったく違います。派遣を利用するには許可を受けた事業者である必要もあります。

自社開発（内製）との違い

自社の社員が開発する形です。ノウハウが完全に社内に残り、意思決定も速くなります。一方で、採用と育成のコスト、そして人材を維持し続ける負担が固定費として乗ります。

先が読めない段階では、固定費を抱える内製より変動費で区切れる外部活用のほうが経営判断として安全です。長く大量に開発し続ける前提が立ってから、内製に寄せるのが順序になります。

ラボ型・オフショア開発との違い

一定期間、専任チームを確保する形です。契約としては準委任に近く、SESの発展形と捉えると分かりやすくなります。継続的に開発量がある企業に向き、人月単価を抑えられる場合があります。

注意点は、仕様が固まらない上流工程ではコミュニケーションのコストが単価差を上回ることです。要件定義と受け入れは国内で持ち、実装の一部を切り出す形が現実的です。

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

偽装請負にしないために。発注側が守るべきこと

SESを使う発注側にとって、最も重要かつ見落とされやすいのが指揮命令の問題です。契約書の名称ではなく、実態で判断されます。

判断は契約の名称ではなく実態で行われる

厚生労働省は「労働者派遣事業と請負により行われる事業との区分に関する基準」（いわゆる37号告示）を定めており、これについて具体的な判断基準やQ&Aを示す「労働者派遣・請負を適正に行うためのガイド」を公表しています。

同ガイドでは、これに反する場合はいわゆる偽装請負となり、労働者派遣法違反となると位置づけられています。請負の形式による契約に基づいていても、実態として労働者派遣事業と判断される場合があるということです。

出典：厚生労働省「『労働者派遣・請負を適正に行うためのガイド』について」

発注側がやってはいけないこと

エンジニアに直接、業務の進め方や段取りを指示する。始業・終業時刻を管理する。残業を指示する。作業の割り振りを発注側が決める。これらはいずれも、指揮命令を行っていると判断される要素になります。

契約書の書き方はいくらでも整えられますが、指揮命令の実態は日々のやり取りに現れるため隠せません。チャットでの直接指示、朝会での作業割り当てといった日常の運用こそが判断材料になります。

適正に運用するための実務

指示は受託企業の責任者を通して行います。伝えるのは「何を達成してほしいか」であり、「どうやるか」ではありません。要望は要件として伝え、進め方の判断は受託側に委ねるという線引きです。

勤怠管理、評価、教育も受託企業側が行います。発注側は成果物と進捗を確認する立場に立ちます。窮屈に感じるかもしれませんが、この距離感を保つことが双方を守ります。

契約形態の選び方、体制の組み方、日々の運用ルールの設計など、発注前段階のご相談も承っています。事業相談以外のご用件もこちらから。

費用構造の違いと、見積もりの比べ方

両者の見積もりは、そもそも書式も比較の軸も違います。並べて安いほうを選ぶ、という判断はできません。

受託開発は総額、SESは人月単価×人数×期間

受託開発は、開発範囲に対する総額として提示されます。何を作るかが確定しているため、金額も確定します。予算管理はしやすい反面、範囲の外に出た瞬間に追加費用が発生します。

SESは、参画するエンジニアの人月単価に人数と期間を掛けた金額になります。期間が延びればそのまま増える構造です。単価はスキルと役割で変わり、上流を担える人材ほど高くなります。

どちらが安いかは、期間と変更の量で決まる

短期で仕様が固まっている案件なら、受託開発のほうが総額を抑えやすくなります。逆に、仕様変更が頻繁に発生する案件では、そのたびに追加見積もりが積み上がり、結果的にSESより高くつくことがあります。

判断の目安は、変更がどれくらい発生しそうかです。要件が読み切れないなら、最初から準委任で回すほうが総額もリードタイムも抑えられます。

比較するなら前提を揃える

受託開発の見積もりは、工程ごとに金額と工数が分かれているか、前提条件と除外事項が明記されているかを確認します。SESの場合は、参画する人の役割、稼働時間の範囲、超過時の扱い、交代の条件を確認してください。

どちらも、保守運用の範囲が含まれているかは必ず見てください。安く見える見積もりは、後で効いてくる費用が抜けているだけということがあります。

エンジニアから見た受託開発とSESの違い

発注側だけでなく、働く側から見た違いも押さえておくと、体制を組むときの理解が深まります。人材確保の観点でも役に立ちます。

働く環境の違い

SESはプロジェクトごとに就業先が変わるのが特徴です。幅広い現場を経験できる一方、帰属意識が育ちにくいという面があります。労働時間は契約で定められた範囲に収まりやすい傾向があります。

受託開発は自社での勤務が中心で、環境の変化は少なくなります。納期の責任を負うため、繁忙期の負荷は上がりやすい構造です。

スキルの積み方の違い

SESでは、参画する現場によって扱う技術も工程も変わります。上流工程に関われるかは案件次第という側面があります。受託開発では、要件定義から運用まで一連の流れを経験しやすくなります。

発注側として体制を組むときは、この違いが人材の定着に影響することも知っておいてください。長期で同じメンバーに関わってほしいなら、そのための条件設計が必要になります。

関連記事：AIエンジニア年収の現実｜職種別・年代別の手取り

体制の設計、人材要件の整理、契約形態の切り分けまで伴走します。初回の事業相談は無料です。

第三の選択肢と、これからの体制の組み方

実務では、二択で割り切らない形も増えています。目的に応じて組み合わせるのが現実的です。

受託とSESを組み合わせる

新規開発は受託で作り切り、その後の改善と運用はSESで体制を維持する。あるいは、要件定義だけ準委任で伴走してもらい、確定した範囲を請負で発注する。工程で契約を分ける多段階の考え方が、そのまま使えます。

内製化を前提にした伴走

外部主導で立ち上げ、運用フェーズで社内に移していく形です。SESの体制で社内メンバーと並走しながら、ノウハウを残すことを契約の目的に含めます。受託開発の弱点であるノウハウ非蓄積を補えます。

この形を選ぶなら、移管を前提とすることを契約時点で合意してください。後から言い出しても、対応してもらえないことがあります。

AIで変わりつつある工数の前提

どちらの形態でも、費用は人月で決まります。AIコーディングツールを開発工程に組み込めば、同じ機能をより少ない人月で作れるようになりました。過去の相場をそのまま当てはめると、実態より高い金額を受け入れることになりかねません。

見積もりを受け取ったら、どういう開発体制で、どの工程にAIを使っているかを聞いてみてください。ここに答えられる会社かどうかは、これからの差になります。

関連記事：Claude Codeチーム導入｜社内展開90日ロードマップ

まとめ

受託開発とSESを分けているのは、対価が成果物に対して支払われるのか、業務の遂行に対して支払われるのかという一点です。ここから契約形態も責任範囲も費用構造も派生します。

選び方は明快です。仕様が固まっていて完成責任を求めるなら受託開発。要件が探索的で体制を柔軟に変えたいなら、そして社内に管理できる人がいるならSES。実務では、要件定義は準委任、製造は請負、運用保守は準委任という工程別の使い分けが標準です。

そして発注側が最も注意すべきは指揮命令です。エンジニアへ直接、進め方や勤務を指示しないこと。判断は契約の名称ではなく日々の実態で行われます。要望は要件として伝え、進め方の判断は受託側に委ねてください。

LiftBaseは、要件定義から運用まで一気通貫の受託開発と、プロジェクト単位で開発体制を補強するITソリューションの両方を提供しています。どちらの形が合うか判断したい段階からのご相談でも構いません。

案件の性質と社内体制から、最適な契約形態と体制を整理します。初回の事業相談は無料です。