受託とは？受託開発の意味と委託・請負・SESとの違いを発注者視点で解説

受託とは、業務を受けて託される側の立場を指す言葉で、システム開発では受託開発として、仕様を渡された会社が成果物を仕上げて納品する形を意味します。ビジネスの契約文脈で検索したとき、上位に並ぶのは「受託と委託は何が違うのか」「請負や準委任とはどう区別するのか」という用語の切り分けです。この記事では受託の意味と読み方から入り、委託・請負・準委任（SES）・客先常駐との違いを、誰が指示を出せて誰が完成の責任を負うかで整理します。そのうえで、発注する側が受託開発に任せるべき条件、自社開発やSESとの切り分け、受託開発会社を選ぶときに見るべき契約形態と見積もりの妥当性までを判断軸で示します。

まとめ：受託と受託開発の意味、委託・請負・SESとの違いと発注判断

受託は「託される」側、委託は「託す」側を表す対の言葉で、同じ取引を受注側から見るか発注側から見るかの違いにすぎません。システム開発でいう受託開発は、この受託を請負契約で行う形が中心で、開発会社が仕事の完成を約束し、納品物に問題があれば契約不適合責任を追及できるのが特徴です。工数だけを借りる準委任（SES）や客先常駐とは、成果物ごと任せて完成の責任を負ってもらえる点で決定的に異なります。

発注する立場で受託開発を選ぶ基準は明確です。仕様がある程度固まり、要件定義から設計・テストまで成果物として任せたいなら受託開発が向きます。逆に要件が動き続け、自社のリーダーが日々指示しながら進めたいなら、工数を借りるSESや内製のほうが合います。「受託開発はやめとけ」という声の多くは、下請け構造やキャリアに関する働く側の話であり、発注側が受け取る価値とは論点が別です。成果物ごと任せたい段階に来たら、費用の内訳まで提示するWebシステム開発の受託相談を起点にすると、受託・SES・内製のどれが自社に合うかを整理しやすくなります。

受託とは｜業務を受けて託される契約の意味と受託開発の位置づけ

まず言葉の意味を押さえます。受託の定義がはっきりすると、後半の「委託・請負との違い」も「発注側の使い分け」も、すべて同じ軸で読み解けるようになります。

受託の意味と読み方、業務受託・受託開発それぞれで使われる文脈の違い

受託は「じゅたく」と読み、他者から業務や権限を任され、それを引き受けることを指します。日常のビジネスでは「業務受託」「受託製造」「受託販売」のように、自社の代わりに何かを担う契約全般で使われる言葉です。IT分野では、この受託がシステムやアプリの開発に向くと「受託開発」となり、発注企業から仕様を受け取った開発会社が、成果物を作って納める取引を指します。読み方や意味を調べる検索は多いものの、実務で問題になるのは「受託が具体的にどの契約形態を指すのか」という点で、そこは請負か準委任かで中身が大きく変わります。

受託開発とは｜システムやアプリを外部に委ねて成果物を受け取る形態

受託開発とは、発注企業が自社で作らず、開発会社に仕様を渡してシステム・アプリを作ってもらう開発スタイルです。要件定義から設計、実装、テスト、納品までを一貫して任せられるため、社内にエンジニアを抱えない事業会社でも、必要なときに必要なシステムを手に入れられます。自社サービスを継続的に育てる自社開発と対比されるのが、顧客の課題を契約した範囲で仕上げて納めるという受託開発の性格です。多くは請負契約で結ばれ、開発会社は完成の責任を負う代わりに、発注側は作り方の細部まで指示せず成果物を受け取る、という役割分担になります。依頼形態そのものの全体像はシステム開発の種類と依頼方法の解説で整理しており、受託開発がどこに位置づくかを対応づけられます。

受託と委託・請負・準委任（SES）の違いを指揮命令権と成果責任で整理

受託という言葉は契約の種類そのものではありません。受託の裏にある契約が請負か準委任かで、誰が指示を出せて誰が完成を約束するかが変わります。ここが発注側の判断の土台です。

受託と委託の違い｜「受ける」側と「託す」側という立場の裏返し

受託と委託は、同じ取引を反対の立場から呼んだ言葉です。仕事を任せる発注側が「委託する」、任される受注側が「受託する」と表現します。つまり「A社がB社に開発を委託した」と「B社がA社から開発を受託した」は、同じ関係を指しています。混乱しやすいのは、委託という言葉が請負と準委任の両方をゆるく含んで使われる点です。契約書のタイトルが「業務委託契約書」でも、中身が請負か準委任かは条文を読まないと判別できません。発注側は「委託」という言葉の見た目に安心せず、完成義務が書かれているかで実質を見極める必要があります。

受託開発の請負契約と準委任契約の違い｜完成責任と契約不適合責任の有無

受託開発の契約は、大きく請負と準委任に分かれ、両者は完成の責任で対照的です。請負は民法632条にもとづき仕事の完成を約束する契約で、納品物が契約内容に適合しなければ、2020年4月施行の改正民法でいう契約不適合責任（改正前の瑕疵担保責任に相当）を追及でき、修補や代金減額を求められます。準委任は民法656条にもとづき事務の遂行そのものを引き受ける契約で、善良な管理者の注意をもって作業すれば、狙った機能が完成しなくても契約違反にはなりません。SES（システムエンジニアリングサービス）はこの準委任で運用される代表例です。

発注側にとっての要点は一つです。動くものが必ず仕上がる保証を契約で担保できるのは請負だけで、準委任やSESで人を借りている限り、完成そのものは契約上の約束に含まれません。成果物に責任を持ってほしいなら請負（受託開発）を選ぶ、というのが基本の線引きになります。

受託開発とSES・客先常駐の違い｜成果物を買うか工数を借りるか

実務でもっとも取り違えやすいのが、受託開発とSES・客先常駐の区別です。受託開発（請負）は「成果物を買う」契約で、完成した動くシステムに対して総額で対価を払います。SESや客先常駐は「工数を借りる」契約で、エンジニアの稼働時間に対して人月単位で払い、完成の保証はありません。発注側が自社の担当者から常駐エンジニアへ直接、日々の作業を指示し始めると、準委任のはずが実態は派遣に近づき、偽装請負のリスクが生じます。この工数を借りる側の使い分けは客先常駐とSES・受託開発の違いと発注側の使い分けで詳しく整理しており、成果物ごと任せる受託開発との対比で読むと、自社にどちらが必要かが見えてきます。

受託開発と自社開発の違い｜発注側から見たメリットと任せられない場面

受託開発を検討する人がまず比べるのが、自社で作る内製（自社開発）との違いです。ここは求人・キャリアの文脈で語られがちですが、発注側の損得に絞って整理します。

発注側から見た受託開発のメリットと、外部に任せてはいけない場面

発注側にとって受託開発の利点は、社内にエンジニアを常時抱えなくても、必要なシステムを完成品として手に入れられる点です。採用や教育のコストをかけずに専門技術を調達でき、要件定義から納品までの責任を受注側に持たせられます。予算も、成果物に対する総額で握るため読みやすくなります。一方で任せてはいけないのは、仕様がまったく固まっておらず、作りながら仕様を毎週変えたい段階です。請負は完成基準を先に決めて総額を握る契約なので、頻繁な仕様変更は追加費用と交渉の火種になります。要件が流動的なうちは、工数を借りるSESや内製で走り、固まってから受託開発に切り出すほうが無理がありません。費用の見え方の違いはシステム開発費用の内訳と相場の考え方で確認しておくと、内製の人件費と受託の総額を同じ土俵で比べられます。

「受託開発はやめとけ」と言われる理由と、発注側の損得とは別軸である理由

「受託開発 やめとけ」「つらい」という検索は、そのほとんどが働くエンジニア側の視点です。多重下請け構造の下層に入ると単価を抜かれる、案件ごとに技術がバラつき専門性が積み上がらない、上流の企画に関われない、という不満が背景にあります。これはエンジニアのキャリア設計上の論点であり、開発を発注する企業が受け取る価値やコストの話とは軸が異なります。発注側が見るべきは、依頼先が下請けに丸投げせず自社で完成責任を果たせる体制か、要件定義から関与できるかどうかです。求職者向けの評判をそのまま調達判断に持ち込むと、本来見るべき「完成責任を負える相手か」という論点を見失います。

【発注者視点】受託開発に任せるべき条件と受託開発会社選びの判断軸

ここからが用語解説に留まる競合記事には無い、発注する側の意思決定です。自社の状況で受託開発・SES・内製のどれが合理的かを、条件付きで言い切ります。

受託開発を選ぶべき条件と、内製・SESにすべき場面の切り分け

受託開発を選ぶべきなのは、次の三つが揃うときです。作りたいものの仕様がおおよそ固まっている、社内に開発を専任で回せる技術者がいない、完成の責任を外部に負ってほしい。この条件なら、成果物を総額で握れる受託開発が最も予算を読みやすく、管理負担も軽くなります。逆に内製やSESにすべきなのは、要件が動き続け、自社主導で日々指示しながら進めたい場面です。既存システムの改修や運用保守のように優先順位が週単位で変わる作業は、工数を柔軟に足し引きできるSESや内製が向きます。判断を誤りやすいのは、実態は自社が細かく指示したいのに受託（請負）で契約し、仕様変更のたびに追加費用でもめるケースです。開発の進め方まで含めて任せたいなら、反復して仕様を固めるアジャイル開発の進め方を受託開発の枠組みで採るという選択肢もあります。

受託開発会社を選ぶときに確認する契約形態と見積もりの妥当性の見極め

受託開発会社を選ぶ段階では、看板の「業務委託」という言葉ではなく、契約が請負か準委任かを必ず確認します。完成責任を負ってほしいのに準委任で契約すれば、動かないときの責任追及ができません。あわせて見積もりでは、要件定義・設計・実装・テストの工程ごとに内訳が示され、人月単価と想定工数の根拠が説明できるかを見ます。総額だけが提示され内訳がない見積もりは、追加費用の温床になりやすい。発注側は、完成基準と検収条件を契約書に明記させ、変更が生じたときの費用ルールも先に握っておくべきです。要件整理の段階から相談したい場合は、費用の内訳まで示すWebシステム開発の受託を窓口にすると、契約形態と見積もりの妥当性を並べて検討できます。

よくある質問

受託と委託・請負・SESの違い、発注側が受託開発の判断でつまずきやすい点を、実際の検索質問に沿って答えます。

受託とはどういう意味ですか？

他者から業務や権限を任され、それを引き受けることを指します。読み方は「じゅたく」です。任せる側の「委託」と対になる言葉で、同じ取引を受注側から見た表現にあたります。システム開発では、発注企業から仕様を受け取って成果物を作る「受託開発」の形で使われます。

受託と委託の違いは何ですか？

立場の違いです。仕事を任せる発注側が「委託する」、任される受注側が「受託する」と表現し、同じ関係を反対から呼んでいます。注意点として、委託という言葉は請負と準委任の両方を含んで使われるため、契約書が「業務委託契約」でも、完成義務があるか（請負）ないか（準委任）は条文で確認する必要があります。

受託開発とSESの違いは何ですか？

受託開発（請負）は成果物を仕上げて納める契約で、開発会社が完成の責任を負います。SESは準委任契約でエンジニアの工数を提供する形で、完成義務はなく、指揮命令も開発会社側に残る契約です。発注側にとっては、動くものが仕上がる保証を契約で担保できるのが受託開発、工数を柔軟に借りられるのがSES、という違いになります。

受託開発はやめとけと言われるのはなぜですか？

多くは働くエンジニア側の視点です。多重下請けで単価を抜かれる、案件ごとに技術が偏り専門性が積み上がりにくい、上流工程に関われない、といった不満が背景にあります。これはキャリア設計上の論点であり、開発を発注する企業が受け取る価値やコストとは別軸です。発注側は完成責任を果たせる体制かどうかで判断します。

発注側は受託開発と自社開発のどちらを選ぶべきですか？

仕様がある程度固まり、社内に専任の技術者を置かずに完成品として受け取りたいなら受託開発が向きます。自社サービスを継続的に育て、仕様を日々変えながら内製で改善したいなら自社開発（内製）が合います。要件が流動的なうちはSESや内製で走り、固まった範囲を受託開発に切り出す併用も現実的な選択肢です。

関連記事

• 客先常駐とは？派遣・SES・受託開発との違いと発注側の使い分けを解説：工数を借りるSES・常駐と、成果物を任せる受託開発を対比したいとき
• システム開発の費用相場は？内訳・人月単価と見積もりの妥当性を発注者視点で解説：受託開発の見積もりが妥当かを内訳から確認する費用ハブ
• システム開発とは？種類・工程・依頼方法までの全体像をわかりやすく解説：受託・依頼形態の全体像から受託開発の位置づけを確認できる
• アジャイル開発とは？スクラムの進め方・ウォーターフォールとの違いをわかりやすく解説：受託開発の枠組みで仕様を反復して固める進め方の補完
• アプリ開発の費用相場は？規模・OS・開発手法別の内訳と抑え方を発注者視点で解説：同じ発注者視点でアプリの受託開発費用を検討する場合の関連記事