「見積書には『SES』と書いてあるが、これまでの受託開発と何が違うのかわからない」「契約書上は準委任だが、現場では毎日直接指示を出している」——このような相談は、AIプロダクト開発の発注担当者から特に多く寄せられます。契約形態の違いを理解しないまま進めると、指揮命令権の所在が曖昧になり偽装請負のリスクを抱えたり、想定外の費用増加やスケジュール遅延の責任の押し付け合いが起きたりします。この記事では、受託開発とSESの違いを「指揮命令権」「責任の所在」「費用の決まり方」の3軸で整理し、AIプロダクト開発でどちらを選ぶべきかを解説します。
受託開発とSESの違いとは？指揮命令権・責任・費用の3軸で整理する
受託開発は、請負契約または準委任契約によって「成果物」または「業務の遂行」に対する責任を開発会社が負う契約形態です。一方SESは、準委任契約（実務上は特定派遣的に運用されることも多い）で、エンジニアの稼働時間・スキル提供そのものが契約の目的になります。両者は契約書の文言だけでは区別できず、①指揮命令権を誰が持つか、②責任の所在がどこにあるか、③費用がどう決まるか、という3つの軸で実態を見る必要があります。とくに指揮命令権は、発注者が現場で直接指示を出せるかどうかを左右する重要な論点で、混同すると法的リスクに直結します。契約形態そのものの法的な位置づけ（請負・準委任の違い）については、受託開発と請負は何が違う？契約形態（請負・準委任）の意味とAI・DX開発で失敗しない選び方で詳しく解説しています。
Structure
なぜ日本ではSES・多重下請け構造が広がったのか
総務省の情報通信白書がIPA「IT人材白書2017」のデータをもとに紹介している数字によると、日本の情報処理・通信に携わるICT人材は約105万人で、そのうち72％がベンダー企業側に所属しています。一方、米国のICT人材は約420万人で、65％がユーザー企業側に所属しており、日米で人材の偏在構造が逆転していることがわかります。日本ではシステム開発の担い手がユーザー企業内部ではなくベンダー側に集中しているため、必要な人員を外部から調達するSESや、開発工程を丸ごと委託する受託開発といった契約形態が発達し、結果として多重下請け構造が広がってきた背景があります。この構造を理解しておくと、なぜ発注担当者が指揮命令や責任の所在で混乱しやすいのかが見えてきます。
契約形態の選び方に迷ったら、要件が固まる前でもご相談いただけます。
無料で相談するMisconceptions
発注担当者が誤解しやすい3つのポイント
誤解1：SESでも現場で直接指示してよい。実際には、労働者派遣か請負（SESを含む業務委託）のいずれに該当するかは契約書の名称ではなく、厚生労働省が示す「労働者派遣事業と請負により行われる事業との区分に関する基準（37号告示）」に基づいて実態で判断されます。SES契約のエンジニアに発注者が日常的に業務指示を出している場合、契約形態にかかわらず偽装請負とみなされるリスクがあります。
誤解2：受託開発なら丸投げできる。実際には、請負型の受託開発であっても要件定義を発注者側が主体的に進める責任は残ります。要件が曖昧なまま開発会社に任せきりにすると、成果物が期待とずれても「仕様通り」として片付けられてしまうことがあります。契約形態と丸投げできるかどうかは別問題です。
誤解3：人月単価が安い方が得。実際には、SESは稼働時間ベースの費用、受託開発は要件定義に基づく総額見積りという、そもそも算出方式が異なります。単価だけを比較すると、稼働期間が延びた場合の総額や、遅延時の追加費用負担の有無を見落としがちです。
Process
契約形態を選ぶための判断ステップ
- 要件の確定度を確認する：作りたいものの仕様が固まっているか、それともPoCのように探索段階かで、適した契約形態は変わります。
- 指揮命令の実態を整理する：日々の作業指示を誰が出すのか、開発会社側のリーダーが管理するのかを事前に決めておきます。
- 責任分界点を契約書で明文化する：バグ対応やスケジュール遅延が発生した際に誰が責任を負うのかを、契約段階で具体的に取り決めます。
- 費用の算出方式を確認する：人月単価×稼働時間なのか、要件定義に基づく総額見積りなのかを確認し、想定外の増額リスクを事前に把握します。
私たちオプティソースでは、探索段階から要件確定後のMVP開発まで一貫して伴走することを心がけており、たとえば製造業向けAI受発注システム「newji」も、調達・購買業務の属人化解消という課題を整理しながら開発を進めてきました。フェーズによって契約の性質を柔軟に切り替えることが、無理のない進め方につながります。
Comparison
受託開発とSES、AIプロダクト開発ではどちらを選ぶべきか
| 契約形態 | 特徴 |
|---|---|
| SES（準委任・稼働提供） | 要件が固まっていないPoCや探索フェーズに向く。稼働時間に対して費用が発生し、指揮命令はSES側の管理者を通す必要がある。 |
| 受託開発（準委任型） | 業務の遂行自体が目的で、成果物への完成責任は限定的。仕様変更が多い開発初期の柔軟な進め方に適する。 |
| 受託開発（請負型） | 成果物への完成責任を開発会社が負う。要件が確定したMVP・本開発フェーズに適するが、要件があいまいだと見積りが膨らみやすい。 |
| オプティソースのAIプロダクト開発支援 | 探索フェーズから要件確定後の開発まで伴走し、フェーズごとに適した契約形態を提案する。小規模な体制のため大手のような大量動員は苦手だが、要件定義から一貫して関われる点が強み。 |
FAQ
よくある質問
SESと業務委託は同じ契約ですか？
SESは業務委託契約の一種で、多くの場合準委任契約として結ばれます。ただし実務上の運用によっては特定派遣に近い形になっていることもあり、契約書の名称だけでは判断できません。
準委任・請負・SESはどう違いますか？
準委任は業務の遂行自体を目的とし、請負は成果物の完成を目的とします。SESは準委任契約の枠組みで稼働・スキルを提供する契約形態を指すことが一般的で、契約の型としては準委任に含まれますが、稼働ベースで費用が決まる点が特徴です。
偽装請負にならないために発注者が注意すべきことは何ですか？
SESや準委任契約のエンジニアに対して、発注者が直接業務指示・勤怠管理を行わないようにすることが重要です。指示系統は先方の管理者を通す運用にし、37号告示に照らした実態を定期的に確認することをおすすめします。
AI開発で要件が固まらない場合はどちらの契約形態を選ぶべきですか？
要件が固まっていない探索段階では、準委任型の契約で柔軟に進め、方向性が固まった段階で請負型の受託開発に切り替える進め方が現実的です。当社でもこうした段階的な進め方でAIプロダクトのMVP開発をご支援しています。
受託開発とSESの違いは、指揮命令権・責任の所在・費用の決まり方という3つの軸で見ると整理しやすくなります。特にAIプロダクト開発では、要件が固まっていない探索フェーズと、要件確定後のMVP・本開発フェーズとで適した契約形態が異なるため、フェーズに応じて契約の性質を切り替える視点が欠かせません。契約形態の選び方に迷った際は、要件が固まる前の段階からご相談いただくことも可能です。
