【2026年版】受託開発とSESの違い｜契約・指揮命令・費用の比較と使い分け

開発会社から「受託開発で一式」「SESでエンジニアを常駐」と提案を受けた担当者なら、 「受託開発とSESは何に対してお金を払うのか、責任は誰が負うのか」 「SESのエンジニアに直接指示をしてはいけないのか」 「費用はどちらが安いのか、月額と総額をどう比べればいいのか」 ——このような疑問をお持ちではないでしょうか。

受託開発とSESの違いは「成果物に払うか、稼働時間に払うか」に集約され、受託開発(請負)は開発会社が完成責任を負って総額が契約時に決まり、SES(準委任)は仕様が流動的でも人手を確保できる代わりに完成の責任と日々の管理が発注側に乗ります。

責任と管理を誰が持つかで整理できれば、2社の提案を同じ土台で比べ、仕様の固まり具合・社内の管理者・期間の3問で、自社の案件に合う頼み方を根拠を持って選べるようになります。

この記事では、受託開発とSESのどちらで頼むか決めたい方に向けて、

• 契約・目的・指揮命令・報酬・責任の5つの観点の比較
• SESのエンジニアに直接指示してはいけない理由と偽装請負を避ける運用
• 費用の構造の違い——受託の総額とSESの月額、マージンの実態
• 発注側のメリット・デメリットと、使い分けの3問・併用パターン
• 第3の選択肢——ラボ型開発とオフショア

上記について、ベトナムのIT企業でERPのプライム案件を請負で担当し、現在は請負型とラボ型(準委任)の両方を提供する当社が、発注者と開発会社の両方の視点から解説しています。

提案書の契約形態を読み解く材料が揃いますので、ぜひ参考にしてください。

受託開発とSESの違い——契約・目的・指揮命令・報酬・責任の5つの観点

「同じ外注なのに、何が違うのか」——受託開発とSESは、どちらも外部の力を借りる点では同じですが、契約の性質も責任の所在も発注側がやるべきことも異なります。

結論から言えば、受託開発は「完成した成果物」に、SESは「エンジニアの稼働時間」に対価を払う頼み方です。

比較表で見る5つの違い

発注側の視点で言い換えると、受託開発は「完成物を買う」感覚、SESは「専門人材の時間を借りる」感覚です。

同じ「外注」でも、自社が担う仕事の量がまったく違います。

契約形態と責任——請負の契約不適合責任と準委任の善管注意義務

請負契約は「仕事の完成」を約束する契約です(民法632条)。

開発会社は成果物を完成させる義務を負い、納品後に契約内容と違う不具合が見つかれば、契約不適合責任として修正・減額・損害賠償の対象になります。

準委任契約は「業務の誠実な遂行」を約束する契約です(民法656条・643条)。

エンジニアは専門家として注意を払って業務にあたる善管注意義務を負いますが、成果物が未完成でも、誠実に稼働していれば報酬は発生します。

契約類型の詳細(成果完成型の準委任、解除、印紙税など)は準委任と請負の違いで解説しています。

報酬の対象——成果物か、稼働時間か

受託開発の報酬は、契約時に合意した総額を、成果物の納品に対して支払います。

開発会社の工数が想定より増えても、追加要件がなければ発注側の支払額は原則変わりません。

SESの報酬は、人月単価×稼働時間で毎月発生します。

成果物が完成したかどうかにかかわらず、稼働した分の費用は発生し、期間が延びれば総額は増え続けます。

私自身、ベトナムのIT企業でERPのプライム案件を請負で担当しましたが、契約形態の選び間違いから始まる失敗を見てきました。

どちらが優れているかではなく、責任と管理を誰が持つかで整理する、というのが出発点です。

指揮命令権と偽装請負——SESのエンジニアに直接指示してはいけない理由

「直接言ったほうが早いのに」——SESのエンジニアが自社のオフィスに常駐していると、そう感じるのが自然です。

しかし、発注側がエンジニア個人に直接指示を出す運用は、偽装請負として法的な問題になり得ます。

指揮命令権はどちらも受託側にある

受託開発(請負)でもSES(準委任)でも、エンジニアに業務の指示を出す権限は、エンジニアが所属する開発会社・SES企業にあります。

発注側が「この作業を先にやって」「今日は残業して」とエンジニアに直接指示すると、実態が労働者派遣と変わらないため、職業安定法や労働者派遣法に違反する偽装請負と判断されるおそれがあります。

厚生労働省は「労働者派遣・請負を適正に行うためのガイド」で、請負と派遣の区分の判断基準を示しています。

SESは発注側の職場で作業するケースが多く、距離が近い分だけ直接指示に流れやすいため、より注意が必要です。

受託・SES・労働者派遣の違い

「人手を確保して直接指示したい」なら、SESではなく労働者派遣契約が正しい選択です。

偽装請負を避ける運用ルール——NG例とOK例

• NG:エンジニア個人にタスクを直接割り当てる、残業や休日出勤を指示する、勤怠を管理する、業務内容を発注側の判断で変更する
• OK:開発会社の窓口(PM・リーダー)を通して依頼する、受入基準と優先順位を文書で示す、定例で要望と課題を共有する、成果物のレビューで指摘する

たとえば当社のラボ型開発では、日本人PMまたはブリッジSEが窓口に立ち、発注側の要望は窓口を通してチームに伝わる体制にしています。

窓口を通す運用は、法令遵守のためだけでなく、要望の整理と優先順位づけが1か所に集まる点でも機能します。

契約書の形式が準委任でも、運用が派遣なら偽装請負です。

「誰が指示を出す契約なのか」を理解せずに運用するのは要注意です。

費用の構造の違い——受託の総額とSESの月額、マージンの実態

「SESのほうが安く見える」——月額60万円と総額500万円を並べれば、そう見えるのは当然です。

しかし費用の構造が違うため、同じ土台に乗せないと比べられません。

受託開発の費用——見積もり内訳と総額固定

受託開発の見積もりは、工程別の工数を積み上げた総額です。

契約時に総額が固まるため予算が読みやすい反面、追加要件はその都度別見積もりになります。

規模別の相場はシステム開発の外注で整理しています。

SESの費用——人月単価×稼働と、単価に含まれるマージン

SESの費用は、人月単価×稼働時間(月)で毎月発生します。

国内SESの人月単価には公開された一次統計がないため、本記事では金額を示しません。比較の物差しには、金額を公開している当社の単価(実務3年目安 1,500USD・約22.5万円、5年 2,000USD、ブリッジSE 3,000USD。1USD=150円換算の目安)をお使いください。

単価には本人の給与だけでなく、社会保険・管理費・SES企業のマージンが含まれます。

マージンの比率には公開された一次統計がないため、本記事では割合を示しません。単価のうちどれだけが本人に渡るかはSES企業ごとに異なります。

さらに商流が1段階深くなるごとに、中間コストが上乗せされます(詳しくはエンジニア単価の相場)。

たとえば当社のラボ型開発の単価は、実務3年目安で月額約22.5万円(1,500USD)です。

国内SESの単価と比べて構造的に低い理由は、ベトナムの人件費の水準に加え、グループの人財データベースから直接アサインして中間マージンが乗らないためです。

見えないコスト——自社の管理時間まで含めた総コスト

SESは月額で費用が見えやすい反面、エンジニアの稼働を活かすための指示出し・進捗管理に、自社の担当者の時間が継続的に取られます。

受託開発はその管理を開発会社が担うため、社内の負担は要件定義と検収に集中します。

表に出る金額だけでなく、自社の人が割く時間と完成しなかった場合のリスクまで含めた総コストで比べる、というのが実務の考え方です。

月額と総額を同じ土台に乗せずに「安いほう」を選ぶのは失敗のもとです。

発注側のメリット・デメリット——受託開発とSESを並べて比較

責任・指揮命令・費用の構造が分かると、メリットとデメリットは裏表の関係だと見えてきます。

発注側の視点で並べて比較します。

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

メリットは、完成責任を開発会社に持たせられること、契約時に総額が固まり予算計画を立てやすいこと、社内に専門人材がいなくても進められることです。

デメリットは、要件が固まっていないと契約しにくく、仕様変更のたびに追加費用と再見積もりが要ること、開発会社によって品質に差があること、社内にノウハウが残りにくいことです。

たとえば当社の請負型では、品質の差を抑えるため、日本人PMの設計レビュー・Gitのプルリクエストによるコードレビュー・リリース前のダブルチェックを全案件で標準化しています。

SESのメリット・デメリット

メリットは、仕様が固まっていなくても人手を確保できること、状況に応じて増減しやすいこと、採用・育成のコストを省いて即戦力を得られることです。

デメリットは、完成の責任と管理が発注側に乗ること、管理を怠ると成果が出ないまま費用だけがかさむこと、帰属意識を持ってもらいにくいこと、直接指示による偽装請負とセキュリティのリスクがあることです。

人材紹介の仕事で日系企業約100社と付き合ってきましたが、SESで失敗する企業様の多くは、デメリットの「管理が自社に乗る」を軽く見ていました。

メリットだけを見て選ぶと、裏表のデメリットが後から効いてくる、というのが実態です。

使い分けの判断軸——仕様・社内の管理者・期間の3問と併用パターン

「仕様が固まっていないからSESにしよう、でよいのか」——消極的な選び方は、「何を作るか決まらないまま時間だけが過ぎる」状態を招きます。

使い分けは、次の3問に答えれば方向性が決まります。

問1: 完成の期日と範囲を、いま約束できるか

作る範囲と機能が決まっていて、「これを完成させて納めてほしい」と言える段階なら、完成責任を持ってもらえる受託開発が向きます。

やりたいことは決まっているが仕様が流動的で、進めながら調整したい段階なら、準委任(SESまたはラボ型)で人手を確保するほうが柔軟に動けます。

判断に迷うときは、「完成の期日と範囲を、この場で開発会社と約束できるか」を自問してください。

約束できる材料がそろっているなら受託開発、まだ探りながら固める段階なら準委任、という切り分けが実務的です。

問2: 社内に開発を仕切れる人がいるか

SESは、開発の方向性を示し、優先順位を決め、進捗を管理する役割が発注側に残ります。

この舵取りができる人が社内にいないと、SESは力を発揮しません。

受託開発は完成物を納めてもらう頼み方なので、要件定義さえ丁寧に行えば、社内に専門人材がいなくても進められます。

「仕切れる人がいない」なら受託開発、「仕切れる人がいて、手を動かす人手が足りないだけ」ならSES、「仕切る人はいないが仕様は動く」ならPM・ブリッジSEが窓口に立つラボ型が候補です。

問3: 期間は読めるか——併用とフェーズごとの切り替え

短期間で完成させたい開発は受託開発、期間が読みにくい継続的な開発は準委任が費用面でも合います。

受託開発とSESは二者択一ではなく、フェーズごとに組み合わせるのが一般的です。

仕様の解像度が上がったタイミングで準委任から受託へ、リリース後に受託から準委任へ、と切り替える進め方が現実的です。

仕様が動く案件を請負で受けると変更のたびに見積もりが要り、確定した案件を準委任で進めると体制の固定費が無駄になる、というのが私の見てきた失敗の型です。

まず3問への答えを書き出し、フェーズで分けて考えてください。

第3の選択肢——ラボ型開発(準委任+チーム+窓口)とオフショア

「準委任で柔軟に進めたいが、管理は任せたい」——受託開発とSESの間にあるこの要望に応えるのが、ラボ型開発です。

ラボ型開発はSESと何が違うか

ラボ型開発は、開発会社が専属のチームを月額固定で組み、一定期間、発注側の開発を継続的に担う形態です。

契約は準委任である点はSESと同じですが、体制と窓口が違います。

発注側は優先順位の決定に集中でき、日々の指示と進捗管理は開発会社のPM・ブリッジSEが担うため、「準委任だが管理を任せたい」という要望に合います。

当社の請負型とラボ型の使い分け

たとえば当社は、ベトナム・ホーチミンで請負型とラボ型の両方を提供しています。

• 請負型:要件が固まっている案件。要件定義から設計・開発・テスト・リリースまでワンストップで完成責任を持つ。マッチングアプリ・決済システム・AIチャットボット・求人プラットフォームなどの実績
• ラボ型:要件が動く継続開発。日本人PMまたはブリッジSEが窓口に立つ専属チーム(パターンA)、または発注側に管理機能がある場合のエンジニアのみ(パターンB)。最短2週間・1名から、増員は最短1週間、ミスマッチ時は1か月単位のリプレイスメント保証

単価は実務3年目安で月額約22.5万円(1,500USD)と、国内SESの単価と比べて構造的に低く、理由はグループの人財データベースから直接アサインして中間マージンが乗らないためです。

2018年からホーチミンで日系企業約100社と付き合ってきましたが、「SESで管理に疲れた」企業様がラボ型に切り替える相談は年々増えています。

一方で、現地常駐が必須の案件や、数週間の超短期案件にはオフショアのラボ型は向きません。

オフショアが全員に最適なわけではない、というのが正直なところです。

【FAQ】受託開発とSESの違いに関するよくある質問

受託開発とSESの違いについて、当社がよくいただく質問に結論から回答します。

個別の状況により異なる点は、無料相談で具体的にお答えしています。

受託開発とSESは併用できますか?

併用できます。

初期開発は受託開発で完成させ、その後の改修・運用は準委任で人手を確保する組み合わせが一般的です。

SESのエンジニアに直接指示を出してはいけないのですか?

発注側がエンジニア個人に直接指示すると、偽装請負とみなされるおそれがあります。

指示は開発会社の窓口を通し、直接指示したいなら労働者派遣契約を選んでください。

費用が安いのはどちらですか?

一概には言えません。

仕様が固まった短期開発は受託開発のほうが総額を抑えやすく、長く続く開発は準委任のほうが柔軟です。

準委任は成果に責任がないのですか?

完成責任は負いませんが、専門家として誠実に業務を遂行する善管注意義務を負います。

成果物の完成を条件に報酬を払う「成果完成型」の準委任もあります。

ラボ型開発とSESはどちらが管理が楽ですか?

ラボ型は開発会社のPM・ブリッジSEが窓口に立つため、発注側は優先順位の決定に集中できます。

SESは指示と進捗管理が発注側に残るため、社内に仕切れる人がいるかが前提。

まとめ: 受託開発とSESは「成果物か稼働時間か」——責任と管理を誰が持つかで選ぶ

受託開発とSESの違いは、「成果物に払うか、稼働時間に払うか」に集約されます。

この記事の要点は次の5つです。

• 受託開発(請負)は開発会社が完成責任(契約不適合責任)を負い総額が契約時に決まる。SES(準委任)は完成責任を負わず(善管注意義務)、稼働に応じた月額が続く
• 指揮命令権はどちらも受託側にあり、発注側がエンジニア個人に直接指示すると偽装請負のおそれがある。直接指示したいなら労働者派遣契約
• SESの単価には社会保険・管理費・SES企業のマージンが含まれ、期間が延びれば総額は増える。自社の管理時間まで含めた総コストで比べる
• 使い分けは「完成の期日と範囲を約束できるか」「社内に仕切れる人がいるか」「期間は読めるか」の3問。初期開発は受託、改修・運用は準委任の併用が一般的
• 「準委任で柔軟に進めたいが管理は任せたい」なら、PM・ブリッジSEが窓口に立つラボ型開発が第3の選択肢

まず、3問への答えと、開発のフェーズ(探索・初期開発・改修運用)を書き出してください。

その2つがあれば、提案書の「受託で」「SESで」を同じ土台で比べ、契約後の「思っていた頼み方と違う」を避けられます。

どちらが優れているかではなく、責任と管理を誰が持つかで決めるのが、失敗しない順番です。

現在の体制と要件をお聞かせください。請負型とラボ型の使い分けを含めて、同等品質でどこまで下げられるか、概算見積もりでお答えします。