【2026年版】受託開発とは？請負開発との違い・流れ・費用相場を解説

システム開発を外部に頼もうと考えている企業の担当者なら、 「受託開発と請負開発は何が違うのか。準委任という言葉も出てきて混乱する」 「頼んだ後、自分たちは何をすればよいのか」 「見積もりの金額が会社によって2倍違う。どれが妥当なのか」 ——このような疑問をお持ちではないでしょうか。

受託開発とは、発注者の依頼に基づいて外部の開発会社がシステムを設計・実装し、成果物を納める頼み方の総称であり、契約は請負が多いものの準委任で頼むこともあります。

契約の形と発注側の役割を押さえれば、仕様変更のたびに費用が膨らむ失敗を避け、ベトナムのような海外の開発会社を使って国内の半分以下の水準で同等品質の開発を進める道筋も見えてきます。

この記事では、受託開発を検討している方に向けて、

• 受託開発の定義と請負開発・SES・ラボ型との違い
• 請負契約と準委任契約の責任範囲
• 依頼から検収までの6ステップと発注側の役割
• 国内とベトナムの人月単価と見積もりの読み方
• 失敗しない開発会社の選び方

上記について、ベトナムのIT企業で受託側としてERPのプライム案件3件を担当し、現在はマッチングアプリやAIチャットボットなどの請負型開発を提供する当社の実務経験を交えながら解説しています。

自社の案件をどの契約で誰に頼むべきかを判断する材料が揃いますので、ぜひ参考にしてください。

受託開発とは——請負開発との違いと他の開発形態との関係

「受託開発と請負開発は、同じことではないのか」——外注を検討し始めた担当者の方から、当社がよく受ける質問です。

結論から言えば、受託開発は「外部の開発会社に頼む」という頼み方の総称で、請負開発は「請負契約で頼む」という契約の形を指します。

この章では定義と対象範囲を押さえたうえで、請負開発、そして自社開発・SES・ラボ型開発との関係を整理します。

受託開発の定義と対象範囲

受託開発とは、発注者の依頼内容に基づいて外部の開発会社がシステムやソフトウェアを設計・実装・テストし、成果物を納める開発の形態です。

パッケージ製品では対応できない要件に合わせて作る、いわゆるオーダーメイドの開発が中心です。

対象は業務システム、Webサービス、モバイルアプリ、ECサイト、AIを使ったツールまで幅広く、たとえば当社ではマッチングアプリ・決済アプリ・AIチャットボット・求人プラットフォームなどを請負型で開発してきました。

開発会社側から見ると「受託」、発注者側から見ると「委託」であり、同じ取引を指す言葉です。

請負開発との違いは「頼み方」と「契約の形」

受託開発の多くは請負契約で結ばれます。

請負契約は成果物の完成に対して対価を払う契約で、開発会社が完成責任を負います。

ただし、受託開発=請負契約ではありません。

要件が固まりきらない案件では、業務の遂行に対価を払う準委任契約で頼むこともあり、これも受託開発の一種です。

整理すると次の通りです。

• 受託開発:外部の開発会社に開発を頼む形態の総称(頼み方)
• 請負開発:請負契約で成果物の完成を頼む形(契約の形)。受託開発の中で最も多い
• 準委任での受託:業務の遂行を頼む形。成果物の完成責任はない

「請負で頼むのか、準委任で頼むのか」は、受託開発を選んだ後に決める話です。

この順番を押さえると、開発会社の提案書に並ぶ用語で迷わなくなります。

自社開発・SES・ラボ型開発との違い

受託開発と比較される開発形態は、主に次の3つです。

私自身、ベトナムのIT企業でERPのプライム案件3件を受託側として上流から下流まで担当しましたが、失敗する案件は形態の選び間違いから始まります。

仕様が動く案件を請負で受けると変更のたびに見積もりが必要になり、確定した案件をラボ型で進めると体制の固定費が無駄になる、というのが実態です。

受託開発の契約形態——請負と準委任の責任範囲

受託開発で最初に決めるのが、請負契約か準委任契約かです。

両者は責任の種類・指揮命令・支払い方法が異なり、ここを曖昧にしたまま契約すると、検収や追加費用で揉めます。

以下は2026年度時点の一般的な整理です。私は法律の専門家ではありませんので、個別の契約は弁護士に確認してください。

請負契約——完成責任と契約不適合責任

請負契約では、開発会社が成果物を完成させる義務(完成責任)を負います。

納品後に成果物が契約内容に適合しない場合は、契約不適合責任(2020年4月施行の改正民法で、瑕疵担保責任から改められた責任)を負います。

発注者は修補・代金減額・損害賠償・解除を求めることができます。法定では不適合を知った時から1年以内の通知が原則ですが、実務では責任の期間を契約で定めるのが一般的です。

逆に言えば、「何が完成か」「何が契約内容か」を要件定義書と検収基準で明文化しておかないと、契約不適合かどうかの判断ができません。

請負で頼むなら、要件定義の精度が発注者側の最大の仕事です。

準委任契約——善管注意義務と成果完成型

準委任契約では、開発会社は業務を適切に遂行する義務(善管注意義務)を負いますが、成果物の完成責任は負いません。

改正民法では、業務の遂行に対価を払う「履行割合型」に加え、成果の引き渡しに対価を払う「成果完成型」の準委任が明文化されました。

ラボ型開発やSESは履行割合型の準委任が一般的で、月額や人月で費用が決まります。

要件が動く案件や、まず動くものを作って検証したい案件では、準委任のほうが発注者の総費用が小さく収まることも多いのが実情です。

指揮命令と支払い方法の違い

どちらの契約でも、発注者がエンジニア個人に直接指示する運用は、偽装請負と判断されるリスクがあります。

指示は開発会社のPMや窓口を通すのが原則です。2つの契約の責任と報酬の違いをさらに細かく見たい場合は、「準委任 請負 違い」の記事で整理しています。

受託開発のメリット・デメリット——発注側の視点

「外注すれば楽になる」とは限りません。

受託開発には明確なメリットがある一方で、発注側の準備が足りないと費用も品質も崩れます。発注前の準備から検収までの実務は、「システム開発 外注」の記事で7ステップに分けて解説しています。

ここでは発注側の視点でメリット・デメリットを整理し、デメリットを抑える原則を3つ示します。

発注側のメリット

• 開発工数の負担を抑えられる:設計・実装・テストを開発会社が担い、自社は要件と検収に集中できる
• 予算計画を立てやすい:請負では契約時に費用と納期が確定し、稟議や予算管理がしやすい
• 専門性を短期間で調達できる:自社にない技術(モバイル・決済・AI)を、採用せずに使える
• 固定費を増やさない:エンジニアを雇用せず、案件単位で費用を変動費にできる

たとえば当社の請負型では、要件定義から設計・実装・テスト・保守運用サポートまでをワンストップで対応するため、発注側に専任のエンジニアがいなくても進められます。

発注側のデメリット

• 仕様変更に弱い:請負では契約後の変更が追加見積もりになり、費用と納期が膨らむ
• ノウハウが社内に残りにくい:開発の中身が開発会社側に蓄積される
• 要件が曖昧だと手戻りが増える:認識のずれが検収まで気づかれないことがある
• 開発会社への依存:ドキュメントやソースコードの権利を確認しないと、他社へ引き継げない

このうち最も多い失敗は、要件の曖昧さから生じる手戻りと追加費用です。

デメリットを抑える原則

1. 要件の解像度を最初にそろえる:画面・機能・データの一覧と優先順位を、発注前に言語化する
2. 変更は別管理にする:変更依頼(CR)の手順と費用の扱いを契約で決め、口頭の追加を作らない
3. レビューの体制を持つ:設計段階でのレビューと、リリース前のダブルチェックを工程に組み込む

当社が設計段階から日本人PMのレビューを入れているのも、仕様の認識ずれを上流で潰すほうが、検収で見つけるより安く済むためです。

削るべきは工数であって、レビューではありません。

受託開発の流れ——依頼から検収までの6ステップ

「頼んだ後、自分たちは何をすればよいのか」——初めて外注する方が最も不安に感じる点です。

受託開発は大きく6つのステップで進み、発注者の仕事は前半(要件)と後半(検収)に集中します。

依頼から検収までの6ステップ

1. 相談・依頼:目的・予算・時期を伝え、開発会社を2〜3社に絞る
2. 要件定義:画面・機能・データ・非機能要件(性能・セキュリティ)を開発会社と一緒に固める
3. 見積もり・契約:工数と単価の内訳、納期、検収基準、変更管理のルールを確認して契約する
4. 設計・実装・テスト:開発会社が設計書を作り、実装と単体・結合テストを進める。発注者は定例で進捗と設計を確認する
5. 受け入れテスト・検収:発注者が検収基準に沿って動作を確認し、合格で納品完了
6. 運用・保守:リリース後の不具合対応と改善を、保守契約または準委任で継続する

期間は規模と要件の固まり具合で大きく変わるため、一律の相場は示せません。見積もりを受け取るときは、この6ステップのどの工程にどれだけの期間を見込んでいるかを、工程ごとに確認してください。

各工程で発注側が決めること

発注側の判断が結果を左右する工程は、要件定義・契約・検収の3つです。

• 要件定義:「誰が・いつ・何のために使うか」と、機能の優先順位(必須/あれば良い)を決める
• 契約:検収基準、変更管理(CR)の手順、成果物とソースコードの権利、契約不適合責任の期間を決める
• 検収:テストの観点(正常系・異常系・性能)と合格条件を、開発前に決めておく

2018年からベトナムで開発と採用の現場に立ってきましたが、揉める案件は例外なく「検収基準を後から決めている」ケースです。

検収の実務

検収は「動いた」ではなく「契約どおりに動いた」を確認する工程です。

要件定義書と設計書を横に置き、画面ごと・機能ごとにチェックリストで確認し、不具合は再現手順を添えて開発会社に戻します。

検収期間(たとえば納品後2週間など)を契約で決めておくと、双方の負担が減ります。

当社ではリリース前にエンジニアと日本人PMがダブルチェックを行い、発注者の検収に入る前に実装品質の問題を潰す運用にしています。

受託開発の費用相場——人月単価と見積もりの読み方

「結局、いくらかかるのか」——受託開発の費用は「人月単価×工数(人月)」で決まります。

多くの開発会社は単価を非公開にしており、相見積もりを取って初めて相場感がつかめる、というのが実情です。

この章では国内の相場、ベトナムでの単価、見積もりで確認すべき点を順に示します。

国内の人月単価と見積もりの膨らみ方

国内の受託開発の人月単価には、公的統計として公表されている一次データがありません。開発会社ごとに単価表が異なるため、同じ要件でも提示額の幅は大きくなります。

総額は「人月単価×工数」で決まります。画面数・機能数・外部連携が増えるほど工数が積み上がり、総額もそれに比例して大きくなります。

運用保守費は、新規開発費に対する年額の比率で見積もるのが一般的です。比率は保守範囲(障害対応のみか、小改修まで含むか)で変わるため、契約書で範囲を確認します。

短納期の案件や仕様変更の多い案件では、体制を厚くしたり手戻りが生じたりするぶん、同じ機能でも見積もりは膨らみます。

オフショア(ベトナム)の受託開発の単価

オフショア開発白書2025年版(オフショア開発.com、2026年9月21日確認)では、ベトナムのプログラマーの人月単価は40.1万円、シニアエンジニアは50.0万円で、中国(58.3万円/71.7万円)より低く、インド・フィリピンとは同水準です。

当社の公開単価は、さらに下の水準です。

※市場相場は当社調べ。円表記は1USD=150円での換算目安で、体制やスキルスタックにより変動します。

請負型でも、費用の基礎は人月単価です。

当社が相場の約1/2で提示できるのは、グループの人材紹介事業が持つ2,000名以上のIT人財データベースから直接アサインし、中間マージンが乗らないためです。

同じ仕様で見積もりが2倍違うとき、主な理由は技術力の差ではなく中間マージンの構造にあります。

見積もりで確認する3点

• 工数の内訳:要件定義・設計・実装・テスト・PM(管理)の人月が分かれているか。管理工数が実装の3割を超える場合は理由を確認する
• 単価の根拠:役割別の単価が示されているか。開示を渋る会社は中間マージンが厚い可能性があります
• 含まれる範囲:テスト・ドキュメント・保守初期対応・契約不適合責任の期間が含まれているか。安い見積もりは範囲が狭いことが多い

金額だけで比較するのは失敗のもとです。

内訳と範囲を同じ物差しでそろえて初めて、見積もりの妥当性が判断できます。

受託開発会社の選び方——失敗しないチェックリスト

「どこに頼めば失敗しないのか」——見積もりが出そろった後に残る問いです。

受託開発会社は、価格ではなく体制・実績・契約の透明性で選びます。

ここでは問い合わせの前後に確認する項目と、請負とラボ型の使い分けをまとめます。

確認すべき項目

• 同種の開発実績:自社と近い業種・規模の案件を作った実績があるか
• 体制と品質担保:PMが誰か。設計レビュー・コードレビュー・リリース前チェックの仕組みが標準化されているか
• 見積もりの透明性:工数と単価の内訳が開示されるか
• 契約の明確さ:検収基準・変更管理・権利・契約不適合責任の期間が契約書にあるか
• コミュニケーション:日本語での窓口、定例の頻度、ドキュメントの言語

人材紹介の仕事で日系企業約100社と付き合ってきましたが、良い会社ほど「できないこと」を先に言います。

すべてを「できます」と言う会社は要注意です。

請負とラボ型の使い分け

• 請負型が向く:仕様と納期が明確/プロジェクト単位で予算を確定したい/完成物の検収で管理したい
• ラボ型が向く:要件が固まりきらない/継続的な開発体制が必要/優先順位を柔軟に変えたい

当社では両方を提供しており、「固める部分は請負、変える部分はラボ型」という組み合わせも可能です。ラボ型の仕組みと費用相場は「ラボ型開発」の記事にまとめています。

まずは現在の要件と予算をお聞かせください。

請負とラボ型のどちらが合うか、概算でお答えします。

【FAQ】受託開発に関するよくある質問

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

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

受託開発と請負開発は同じ意味ですか?

同義ではありません。

受託開発は外部に頼む形態の総称で、請負開発は請負契約で頼む形です。

受託開発の多くは請負ですが、準委任で頼む受託開発もあります。

受託開発の費用はいくらかかりますか?

人月単価×工数で決まります。

国内の人月単価には公的な一次統計がなく、会社ごとに提示額の幅があります。当社(ベトナム)の公開単価は実務3年目安で月額1,500USD(1USD=150円換算で約22.5万円)〜で、相場の約1/2(当社調べ)の水準です。

開発の途中で仕様を変更できますか?

請負契約では、変更管理(CR)の手続きを経て追加見積もりになるのが一般的です。

仕様が動く前提なら、準委任(ラボ型開発)で頼むほうが総費用を抑えやすくなります。

納品後に見つかった不具合は直してもらえますか?

請負契約では契約不適合責任の範囲で対応されます。

責任の期間と範囲は契約で決まるため、契約前に確認してください。

オフショアの受託開発は品質が心配です

品質は国ではなく体制で決まります。

当社は日本人PMの設計レビュー・Gitのプルリクエストによるコードレビュー・リリース前のダブルチェックを全案件で標準化し、日本品質×低価格を両立する体制です。

まとめ: 受託開発は「どの契約で頼み、発注側が何を決めるか」で結果が決まる

受託開発とは、発注者の依頼に基づいて外部の開発会社がシステムを設計・実装し、成果物を納める頼み方の総称です。

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

• 定義と契約:受託開発の多くは請負契約(完成責任・契約不適合責任あり)だが、準委任(善管注意義務)で頼む受託開発もある。「受託開発=請負」ではない
• 発注側の役割:要件定義・契約(検収基準・変更管理・権利)・検収の3つは発注者が握る。ここを曖昧にすると追加費用と手戻りが膨らむ
• 費用と選び方:費用は人月単価×工数。国内の人月単価に公的な一次統計はなく会社ごとに幅がある。ベトナムの当社なら実務3年目安で月額1,500USD(1USD=150円換算で約22.5万円)〜。会社は価格ではなく体制・実績・契約の透明性で選ぶ

仕様と納期が明確なら請負型、要件が動くならラボ型という使い分けを押さえれば、失敗の多くは防げます。

自社の案件がどちらに向くか、いくらになるかは、要件を仮置きして概算するのが最も早く正確です。

現在の要件と予算をお聞かせください。同等品質でどこまで下げられるか、概算見積もりでお答えします。