受託開発の費用は、開発方式、システム規模、要件や連携の範囲によって、300万円程度から5,000万円超まで幅があります。
初期開発のあとにも運用費がかかるため、金額を比べる前に内訳を押さえておくと、見積もりの差の理由が見えてきます。
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
受託開発の概要と費用の前提
受託開発は、発注者の業務課題や要望をもとに、外部の開発会社がシステムを設計して開発する方式です。
社内に足りないエンジニアやプロジェクトマネージャーを確保しやすい点が利点です。一方で、要件や優先順位が曖昧なままだと、追加費用や納期遅延につながります。
フルスクラッチ、SaaS、ローコードの違い
受託開発では、業務に合わせて独自に作るか、既製サービスを使うかによって、費用や柔軟性が変わります。
- フルスクラッチ：独自の業務フローや複雑な権限管理を、そのまま形にできる方式です。
- SaaS・パッケージ：標準機能に業務を合わせられるなら、初期費用を抑えやすい方式です。
- ローコード：画面や簡易なワークフローを、短い期間で作りやすい方式です。
フルスクラッチでは、要件定義や画面設計、データモデル、テストの範囲が広がるため、費用も大きくなります。なお、ローコードでも、複雑な外部連携や性能要件がある場合には、追加の開発が発生します。
ハイブリッド構成による費用と柔軟性のバランス
基幹業務はフルスクラッチで作り、申請や通知などの周辺機能はSaaSやローコードで、データ連携はAPIで行う構成も選べます。
すべてを自社専用に作らないことで、初期費用を抑えつつ、差別化に直結する部分へ投資できます。ただし、製品ごとの利用料やAPI連携費、データの所有権、障害時にどこまでを誰が受け持つかは、事前に確認が必要です。
受託開発の費用相場とコストの内訳
受託開発の費用は、機能数や利用者数、連携先などによって変わります。さらに、セキュリティ要件や納期、運用体制も金額に関わります。
システムの規模ごとに、2026年時点で比較検討の起点にしやすい費用の水準を並べると、次のようになります。
- 小規模な業務アプリやMVP：300万〜1,000万円程度です。
- 複数部門が使う中規模システム：1,000万〜5,000万円程度です。
- 基幹連携や高い可用性を求める大規模システム：5,000万円を超えることがあります。
金額の大小だけで決めると、含まれる工程や成果物の違いを見落とす原因になります。そのため、各社の工程と成果物をそろえてから比べます。
人件費と工程別の配分
開発費の大部分を占めるのは人件費で、プロジェクトマネージャーや業務担当、エンジニアなど、各工程に関わる人の費用が積み上がります。
- 人月配分：単価と工程ごとの人月の内訳です。
- 工程の不足：要件定義やテストが配分目安より極端に少ない場合、手戻りや品質確認を発注側へ転嫁していないかを見ます。
- 工程配分の目安：要件定義10〜12％、設計・環境構築22〜24％、開発48〜50％、テスト15〜17％です。
- 試算例：人日単価5万円で100人日なら、開発費の基準は500万円です。
- 配分例：要件定義10人日、設計・環境構築23人日、開発50人日、テスト17人日です。
実際の単価や配分は技術領域や会社によって異なります。それでも、この目安は見積もりのなかで抜けている工程を見つける物差しになります。
初期費用以外のランニングコスト
初期開発のあとには、クラウド利用料やライセンス料が継続してかかります。加えて、監視や障害対応、OSやミドルウェアの更新などの作業が発生し、軽微な改修も必要になります。
保守費用は、開発費の年間15〜25％程度を見込むケースがあります。ただし、対象時間や対応速度、含まれる作業は会社ごとに異なります。
月額の料金だけでなく、障害の一次受付や復旧目標、追加改修の単価も確認してください。
受託開発の進め方と順番
費用を抑えるには、後から高額な手戻りが起きない順番で進めることが大切です。
たとえば、発注先に任せきりですぐ開発へ入ると、完成後に画面や業務の認識違いが見つかり、追加費用が発生します。そこで、企画から保守までを一続きの計画として扱います。
- 企画と要件定義
- 設計
- 開発とテスト
- リリースと保守
要件定義での業務課題と優先順位の整理
最初に、誰がどの業務で何に困っているのかを書き出します。
「在庫管理を効率化する」だけでは目標が伝わりにくいため、「毎日2時間かかる転記を30分以内にする」「二重入力をなくす」のように、現状と目標を数字で表します。
- 機能の優先度：必須の機能と、できれば欲しい機能、今回は作らない機能に分けます。
機能一覧には、目的と利用者を添えます。さらに、優先度と受け入れ条件も書き加えると、見積もりの前提がそろいます。
設計と開発での変更管理
設計では、画面と権限、データ項目を決めます。外部連携やエラー時の動きも、ここで決めておきます。
- 変更の判断：目的や追加工数を記録し、承認者が納期や将来の保守への影響を見て決めます。
変更を無料で受け続けると、スコープクリープによって予算も納期も崩れます。また、準委任契約でアジャイルに進める場合は、スプリントごとに優先順位と消化工数を確かめて、変更を管理します。
テストとリリースでの本番運用の想定
テストでは正常系だけでなく、異常時の動きも確かめます。権限不足や通信失敗、重複登録の場面に加えて、データ移行ミスや負荷集中、バックアップからの復旧も対象になります。
リリース前には、受け入れ基準と切り戻し手順を決めておきます。あわせて、未解決の不具合を残したまま公開してよいかを判断する担当者も決めます。
納品物に操作マニュアルや設計書、テスト結果が含まれるかも確かめます。また、ソースコードやアカウント情報が含まれるかも確認します。
受託開発の会社の選び方
会社選びでは、自社と近い業種や規模の実績、説明の透明性、プロジェクト管理力を見ます。知名度や最安値だけで決めないことが大切です。
候補企業は、取引先の紹介や同業者のリファラル、マッチングサービスや一括見積もりサイトなどから集めます。紹介は信頼性を確かめやすい一方、マッチングサービスは比較しやすい方法です。
掲載情報だけでは保守体制まで分からないため、面談と実績の確認も組み合わせます。
コンペでの想定外の場面と対応力
提案時のデモでは、用意された成功画面だけでなく、あえて想定外の場面を起こして対応力を見ることが大切です。
- 外部API：タイムアウトが起きたときの復旧方法をたずねます。
- 権限：途中で担当者のアクセス権を外したときの動きを見ます。
- 重複データ：起きたときに誰が調べられるかを聞き、可能であれば操作も試します。
遅延や権限不足が起きたときに、ログや通知の扱い、切り戻し、責任者を説明できる会社は、運用を任せても安心できる可能性が高いといえます。
安すぎる見積もりの工程と前提
相見積もりで金額差が大きいときは、単価の差よりも範囲の違いを確かめます。
- 見積もり範囲：各社が含む工程や作業をそろえて比べます。
- 「一式」の内訳：成果物や工数を確認し、担当者や前提条件も見ます。
対象工程には、要件定義やテストに加え、UI・UXやセキュリティ設計、移行などがあります。さらに、教育やリリース後の保守も含まれます。
極端に安い見積もりには、要件定義やテストを圧縮して後から追加請求されるリスクがあります。また、セキュリティ対策を省くことや、経験の浅い担当者へ過度に任せることも考えられます。
発注前の準備とRFP作成によるコストの安定
発注前に情報を整理しておくと、会社ごとの前提がそろい、比べやすい見積もりになります。
完璧な仕様書は不要です。現状の業務と課題、対象部署を書き出し、そのうえで利用者数やデータ量、連携先などを添えます。希望時期と予算上限、必須条件も、あわせて伝えます。
RFPに入れる目的・範囲・評価基準
RFPは提案依頼書で、背景と目的、業務フロー、対象範囲を記載します。そのうえで、機能・非機能要件や連携、データ移行を書き、納期や予算、体制などの条件も記します。
成果物と保守条件、提案書の提出形式も含めます。評価項目には、価格に加えて、実績や提案の具体性、リスクの説明を入れます。さらに、コミュニケーション方法も評価対象にします。評価基準を先に渡しておけば、会社は同じ観点で提案を組み立てられます。
発注側の意思決定工数の確保
受託開発を発注しても、社内の仕事がなくなるわけではありません。
- 社内の確認業務：業務ヒアリングや画面確認、受け入れテストに加え、優先順位の決定にも時間が必要です。
この時間は、小規模な案件でも必要になります。数か月の案件であれば、責任者は週3〜8時間程度、現場代表者は週1〜4時間程度を確保する想定で計画します。
時間は案件の規模によって上下します。社内PMや決裁者、現場代表、情報セキュリティ担当を先に明確にしておけば、判断待ちによる遅延を防ぎやすくなります。
契約と進行中のリスクの管理
契約では、完成責任や変更の扱い、成果物、検収の条件を明確にします。さらに、途中解約の条件も含め、知的財産や再委託、保守について取り決めます。
契約形態と費用の見え方は、不確実性を発注者と受託者のどちらが負うかによって変わります。
請負契約と準委任契約の工程別の使い分け
請負と準委任では、責任の範囲や向いている工程、費用の見え方が異なります。
- 請負契約：合意した成果物の完成責任を負い、要件や検収条件が固まった工程で使われます。
- 準委任契約：一定の業務の遂行を依頼する形で、要件が変わりやすい企画や要件整理、アジャイル開発に適しています。
- 費用の目安：請負は準委任の人月計算より1.3〜1.5倍程度になる場合がありますが、これは法律上の係数ではありません。
準委任でも、成果を確認する会議体や報告の方法を決めておかなければ、稼働しているのに成果が見えない状態になりかねません。そこで、契約方式だけで高い・安いを決めず、責任範囲や成果物、変更手続きと合わせて確かめます。
契約で決めるソースコードと知的財産の扱い
開発費を支払っても、ソースコードや翻案権が当然に自社へ移るとは限りません。
- 対象の区分：新規開発部分、既存汎用部品、オープンソース、デザイン、データ、ドキュメントを分けます。
- 契約への記載：利用許諾や引渡しの範囲を、契約書に明記します。
中小企業庁は、開発成果の帰属と既存技術の扱いを分けて考え、適正な対価も含めて合意するよう案内しています。
AI開発の速さと本番品質の区別
生成AIを使うと、画面の試作や定型コードの作成を短時間で進められます。
ただし、AIが出力したコードをVibe Codingのまま本番に投入すると、設計の一部が欠けてしまう可能性があります。なかでも、認証や権限、個人情報、決済に関わる設計は要注意です。
- 見積もりに含める体制：レビュー担当者やテスト記録、脆弱性診断、運用責任者を確保します。
IPAは2026年に公開した製品開発者向けガイドで、脆弱性への対処と、開発者・利用者双方の対策を示しています。
受託開発のコスト最適化のポイント
コスト最適化とは、価値の低い作業を減らし、失敗によるやり直しを防ぐことです。単価を下げることだけを目指すわけではありません。
品質に直結する要件定義やテストを削ると、リリース後の障害対応や追加開発で、かえって費用がかさみます。
MVPから始める効果の確認
最初から全部署や全機能を対象にせず、最も大きな課題を解くMVPから始めます。
- 初期実装の範囲：1部署の申請・承認と、最低限の権限、必要な帳票に絞ります。
これは、全社基盤を一度に作る方法に代わる進め方です。利用状況と効果を確かめてから機能を追加すれば、要件の思い込みを減らせます。また、稟議も「初期投資」と「検証後の追加投資」に分けて説明できます。
ベンダーを乗り換える際の引き継ぎの確保
品質やコミュニケーションに問題が出ても、感情的に解約を決める前に、手元の状態を整理することが大切です。
- 契約書や未払い、成果物などを一覧にし、クラウドアカウントや設計書、テスト記録も確認します。
- 次の会社へ渡せるものと、現ベンダーにしかないものを分けて、引き継ぎ期間と費用を合意します。
- コード、管理者権限、データのエクスポート、未解決の不具合一覧を確保し、移行計画を立てます。
この順序で準備すると、ベンダーロックインを解く手がかりがそろいます。
リリース後の保守と内製化
開発会社を選ぶときは、納品日だけでなく、運用の引き継ぎ方も確かめます。IPAの「DX動向2025」では、日本企業のDX推進人材が不足している割合が8割を超えると紹介されています。
外部委託は有効な手段です。ただし、社内に判断できる人がいない状態が続くと、保守費用や変更費用を自社で評価できなくなります。
保守契約のSLAと費用の境界
保守契約には、問い合わせ対応や障害の一次切り分け・復旧、脆弱性対応が含まれることがあります。定期更新やバックアップ確認、軽微な改修も対象になる場合があります。
SLAには、重大度ごとの受付時間や初動時間、復旧目標を書き込みます。対応可能な曜日や連絡手段も、あわせて明記します。
新機能や大規模な仕様変更については、保守費用に含めるか、別の見積もりにするかも決めておきます。
発注前に確認する内製化支援の有無
将来、内製化したい場合は、「納品後に引き継ぎます」という説明だけでは足りません。
- 共同作業：設計レビューへの参加や、ペア開発を提案してもらいます。
- 運用・育成：運用手順や社内研修、コードレビュー、段階的な権限移管を依頼します。
IPAの調査でも、外部で開発したシステムの内製化は課題として挙げられています。だからこそ、選定の段階から、どの知識をいつ社内へ移すかを計画に含めることが大切です。
よくある質問（FAQ）
費用と会社選びで寄せられやすい質問をまとめました。対象ユーザー、連携、セキュリティ、運用の前提を加えて判断してください。
受託開発は最低いくらから依頼できますか？
小規模な業務アプリや検証用MVPは、実務上300万円前後から検討されることがあります。画面数や外部連携、データ移行などを含めると、金額は上がります。認証やテスト、保守まで含めると、さらに上がります。
予算だけを先に伝えるのではなく、必須機能と見送る機能を分けて相談すると、現実的な提案につながります。
安い受託開発会社を選んでも問題ありませんか？
安いこと自体は問題ではありません。SaaSやローコードを使い、対象範囲を絞った結果として安くなる場合もあります。
一方で、要件定義やテスト、セキュリティなどの工程が見積もりから抜けていると、後から追加費用が発生しやすくなります。そこで、工程別の工数と、含まれない作業を確認してください。
AIを使えば受託開発の費用を大幅に下げられますか？
AIで試作や定型作業の時間を短縮できる可能性はあります。ただし、完成品質を自動で保証できるわけではありません。認証や権限、個人情報のレビュー費用は残ります。監査ログや脆弱性、運用設計の確認にも、費用がかかります。
AIの利用範囲や入力データの扱いは、見積もりと契約に含めておきます。さらに、生成物のレビュー責任とテスト記録も、契約書に明記します。
まとめ
受託開発では、価格の安さよりも、費用の内訳とリスクを説明できるかどうかを見極めることが大切です。
小規模なMVPは300万〜1,000万円程度、中規模システムは1,000万〜5,000万円程度が検討の起点です。実際の金額は、要件や連携、セキュリティなどによって変わります。
要件定義10〜12％、設計・環境構築22〜24％、開発48〜50％、テスト15〜17％を目安に、工程の抜けを確認してください。
3社への同じ条件での相談
現状の業務フローと必須機能を1枚にまとめ、同じRFPを3社程度に渡します。
工程別の工数や含まれない作業、担当体制などを比べれば、自社に合う受託開発パートナーを見極められます。
記事で参照した情報源
参照した資料は、内製化や人材不足、AI開発に関するものと、契約や知的財産に関するものです。
- 内製化・人材不足：IPA「DX動向2025」です。
- AI開発・脆弱性対策：IPA「製品開発者向け・製品利用者向けガイド」およびIPA「AIセーフティに関する評価観点ガイド」を参照しています。
- 契約書：経済産業省「契約書フォーマット」です。
- 知的財産・開発委託契約：中小企業庁「知的財産取引に関するガイドライン」です。
- 掲載費用：公定価格ではなく、案件の規模や要件で変動する実務上の目安です。
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。