.NET Coreのシステム開発の発注/外注/依頼/委託方法について

.NET Coreのシステム開発を発注・外注するなら、技術名だけで依頼先を決めず、業務要件、データ移行、連携、運用、サポート期限まで含めて委託範囲を設計することが重要です。発注前にRFPと受け入れ条件を整え、要件の確定度に応じて請負・準委任・段階発注を使い分けると、予算と品質を管理しやすくなります。

本記事では、「.NET Coreのシステム」を外部会社へ発注・外注・委託する進め方を、発注形態の選び方、RFP・要件整理、契約形態、費用相場、委託先の選定、見積比較のポイントまで順番に解説します。既存の.NET FrameworkやVB.NET資産を活用する場合、AzureやAWSへ移行する場合、開発後の保守まで任せる場合にも使える判断軸を整理します。

▼全体ガイドの記事
・.NET Coreのシステム開発の完全ガイド

.NET Coreのシステムを発注・外注する全体像

.NET Coreは現在の.NETにつながる呼称であり、業務WebシステムではASP.NET Coreを使って画面、Web API、バッチ、認証・認可、外部サービス連携などを構築します。発注対象は画面制作だけではなく、業務ルール、データベース、権限、ログ、インフラ、テスト、移行、保守まで含む一つの業務基盤です。

「.NET Coreで業務システムを作る」という依頼だけでは、会社ごとに想定する範囲が変わります。顧客・商品・案件などのマスタ管理、受発注や在庫の業務処理、帳票、CSV入出力、承認、通知、会計やERPとの連携、監査ログを機能単位で洗い出します。利用者数、同時アクセス数、月間処理件数、保存期間も添えると、必要な性能とインフラを比較しやすくなります。

委託範囲は、現状調査、要件定義、UI設計、アプリ開発、データ移行、クラウド構築、テスト、教育、リリース、保守に分けて記載します。特にデータ移行と外部連携は、後から追加費用になりやすい領域です。移行対象の件数、文字コード、欠損や重複の扱い、連携先の仕様確認までRFPに含めることが安全です。

標準的な販売管理や勤怠管理で業務を合わせられる場合は、パッケージやSaaSを導入し、独自性の高い部分だけを.NETで補う方法があります。既存のSQL Server、VB.NET、ASP.NET資産や社内認証を活かしたい場合は、ASP.NET Coreで段階的に刷新する方法が候補です。すべてを新規開発するのではなく、標準領域はパッケージ、独自業務はスクラッチ、連携はAPIという分担も検討できます。

構成を決めるときは、最初からマイクロサービスにする必要があるかを慎重に確認します。Microsoft Learnのアーキテクチャ指針でも、規模やチーム体制によっては一つのモノリスをコンテナなどで運用する方が、分散構成よりコストと複雑性を抑えられると説明されています（出典: Microsoft Learn「Common web application architectures」、2026年8月確認）。業務境界が明確になった部分だけをAPIやサービスへ切り出す方が、発注後の運用を現実的にできます。

発注形態はどれを選ぶとよいですか？

結論として、要件と完成条件が固まっている部分は請負、検証しながら決める部分は準委任、両方が混在する案件は段階発注が適しています。契約形態を価格だけで選ばず、変更が起きる可能性、社内で意思決定できる人員、納品後の保守責任まで踏まえて決めます。

画面一覧、API仕様、連携先、納期、受け入れ条件を合意できる場合は、請負契約で機能単位の開発を委託しやすくなります。発注者は総額と納品物を管理しやすくなりますが、契約後に業務ルールや画面数を大きく変えると、追加開発として再見積もりになる可能性があります。

請負では、完成の定義を「画面が表示されること」に限定しません。正常系・異常系・権限別のテスト、性能条件、バックアップと復旧、移行後の照合、操作マニュアル、ソースコード、設計書、環境構築手順を納品物に含めます。受け入れテストで不合格になる条件も、契約書や仕様書に先に記載します。

要件がまだ固まっていない場合や、業務部門と開発会社がワークショップを重ねて設計する場合は、準委任で専門人材の稼働を確保する方法が合います。現状調査、PoC、MVP、既存コードの解析、移行計画、アーキテクチャ検討など、不確実性が高い作業を短いサイクルで進められます。

一方で、準委任は稼働時間を確保する契約であり、機能の完成や固定納期が自動的に保証されるわけではありません。月次の稼働報告だけでなく、スプリントごとの成果物、決定事項、未解決課題、次月の優先順位を確認します。成果物を自社に残したい場合は、設計書、コード、テスト記録をいつ渡すかも決めます。

実務では、最初に準委任で現状調査と要件定義を行い、仕様が固まった段階でアプリ本体を請負に切り替える方法が使いやすくなります。データ移行、外部API連携、負荷試験のように難易度を初期に読みづらい作業は、PoCや技術検証として別契約に分けることもできます。

段階発注では、前工程の成果物が後工程の入力になるようにします。要件定義書、画面一覧、データ項目定義、API仕様、権限マトリクス、移行対象一覧が未完成のまま開発へ進まないよう、各工程の完了条件を明確にします。契約を分けても、責任の押し付け合いが起きないよう、全体のプロジェクト責任者を定めます。

.NET Coreのシステム発注・外注はどのように進めますか？

発注は、会社を探すところから始めるのではなく、自社の業務と制約を整理するところから始めます。現状調査、RFP作成、提案比較、要件定義、設計・開発、テスト・移行、運用引き継ぎの順に進め、各工程で発注者が判断する項目を残します。

最初に、対象業務の担当部署、利用者、処理件数、繁忙期、承認経路、例外処理を整理します。現行の.NET Framework、VB.NET、ASP.NET、SQL Server、Excel、CSV、Active DirectoryやMicrosoft Entra IDなどの認証基盤も一覧化します。画面数だけでなく、業務ルールとデータの正しさを把握しないと、旧システムを新しい画面へ置き換えただけになりやすくなります。

課題は「入力が面倒」のような感想だけで終わらせず、入力に何分かかるか、承認が何日滞留するか、二重入力が月何件起きるかまで確認します。短縮したい時間、削減したいミス、必要な可視化をKPIにすると、提案会社の比較とリリース後の効果測定がしやすくなります。

RFPには、プロジェクトの背景、解決したい課題、対象業務、利用者、機能一覧、対象外の範囲、既存システム、データ、外部連携、希望時期、予算の考え方、提案に求める納品物を記載します。機能は「顧客を登録する」だけでなく、必須項目、重複判定、編集権限、履歴、検索条件、CSV出力、エラー時の扱いまで分けて書きます。

非機能要件には、同時利用者数、応答時間、稼働時間、バックアップ、復旧目標、監視、ログ保存、個人情報、アクセス元制限、脆弱性対応を含めます。たとえば「通常操作は3秒以内」「障害時は何時間以内に一次回答」「操作履歴を何年間保存」のように、検証できる表現へ変換します。要件が未確定な項目は、提案会社に確認方法と追加費用の条件を提示してもらいます。

設計では、フロントエンド、ASP.NET CoreのWeb/API層、業務ロジック、Entity Framework Coreなどのデータアクセス、SQL ServerやPostgreSQLなどのデータベースを分けて考えます。画面とAPIをどの範囲で分離するか、バッチやキューを使うか、クラウドかオンプレミスかは、利用者数、連携数、運用体制を基準に決めます。

バージョン選定は、開発会社の得意技術だけで決めません。2026年8月時点で、.NET 10はLTSとして2028年11月14日まで、.NET 8は2026年11月10日までサポートされます。新規開発では.NET 10を候補にしつつ、利用ライブラリの対応状況や既存資産との互換性を確認し、アップデート時期、検証環境、費用負担をRFPと保守契約に含めます（出典: Microsoft「.NET and .NET Core official support policy」、2026年8月確認）。

テストは、画面が開くかだけでなく、業務が最後まで完了するかを確認します。単体・結合・総合・受け入れの各テストに加え、権限別、異常系、大量データ、外部連携先の停止、タイムアウト、二重登録、通信切断、バックアップからの復旧を対象にします。業務部門が本番利用を想定して受け入れ、未解決の不具合と回避策を記録します。

移行では、対象期間、データ件数、欠損や重複、文字コード、添付ファイル、旧コードと新コードの対応、移行後の照合方法を決めます。いきなり本番データを移さず、テスト移行とリハーサルを行い、切り戻し条件を明確にします。リリース後の問い合わせ窓口、初期不具合の対応期間、操作教育も、開発完了とは別に計画します。

契約形態と委託範囲で決めておくべきこと

契約書は、開発会社へ作業を任せるためだけの文書ではありません。何をもって完了とするか、仕様変更をどう扱うか、成果物を誰が保有するか、障害や脆弱性に誰が対応するかを明確にし、プロジェクトの判断基準をそろえる文書です。

請負では、成果物、納期、検収方法、契約不適合への対応、変更時の再見積もり条件を確認します。準委任では、稼働時間、担当者のスキル、作業報告、指示系統、成果物の共有方法、契約期間、終了時の引き継ぎを決めます。要件定義は準委任、確定した機能開発は請負というように、工程ごとに異なる契約を組み合わせることもできます。

変更管理では、追加要望をその場の口頭合意で進めないことが重要です。変更内容、業務上の理由、影響範囲、追加工数、納期、テスト範囲、承認者をチケットや変更依頼書に残します。月額の準委任でも、優先順位を変えた結果として何が後ろ倒しになったかを記録します。

納品物は、実行ファイルだけでは不十分です。ソースコード、リポジトリ、設計書、データベース定義、API仕様、テスト仕様書と結果、インフラ構築手順、CI/CD設定、監視設定、バックアップ手順、管理者マニュアルを一覧化します。Gitリポジトリやクラウド契約を誰が保有するかも決め、特定の担当者の個人アカウントに依存しない運用にします。

著作権の譲渡範囲、既存部品やOSSの扱い、第三者ライブラリのライセンス、翻案や改修の可否、著作者人格権の扱いを契約で確認します。開発会社が再利用する共通部品と、自社専用に作った成果物を分けて記載すると、将来の別会社への保守移管や内製化を進めやすくなります。

保守契約では、問い合わせの受付時間、障害の重要度、一次回答と復旧の目標時間、軽微改修の月間枠、バックアップ確認、監視、ログ調査、定期報告を分けて記載します。Microsoftの.NET更新やNuGetパッケージの脆弱性情報を誰が確認し、自己完結アプリを再ビルドして本番へ再デプロイするかも、保守範囲に含めます。

認証と認可を分け、ロールだけでなくポリシーやリソース単位でアクセスを制御します。HTTPS、CSRF・XSS・SQLインジェクション対策、CORS、MFA、秘密情報の安全な保管、最小権限、監査ログ、依存パッケージのスキャンを受け入れ条件に含めます。Microsoft LearnのASP.NET Coreセキュリティ指針では、認証・認可、データ保護、秘密情報管理などを個別の論点として扱っています（出典: Microsoft Learn「ASP.NET Core security topics」、2026年8月確認）。

.NET Coreのシステム発注費用相場とコストの内訳

.NET Coreだけを対象にした日本の開発費の公的な平均統計は確認できないため、以下は2025〜2026年に公開された業務システムの相場とC#.NET人材単価を組み合わせた、発注判断用の推定レンジです。画面数、データ移行、帳票、外部連携、権限、性能、可用性、保守範囲によって大きく変わるため、予算確定前に同じRFPで複数社へ見積を依頼します。

小規模で、1部門向けの5〜15画面、基本的な登録・一覧・検索、ログイン、CSV入出力を想定する場合は、初期開発費を150万〜500万円程度の検討レンジとします。要件定義、テスト、簡単なデータ移行を含むかで変わりますが、帳票や複雑な承認、複数システム連携を加えると小規模の下限には収まりにくくなります。

中規模で、複数部門、20〜80画面、権限、帳票、バッチ、API連携、既存データ移行を含む場合は、500万〜3,000万円程度が一つの検討レンジです。基幹刷新、多拠点、大量データ、冗長化、厳格な監査、複数の外部連携まで含む大規模案件は、3,000万円〜1億円超となる可能性があります。これらは業務システム全般の公開相場を.NET Coreの要件へ置き換えた推定であり、特定金額の断定ではありません（出典: 株式会社FrameScript「2026年版 業務システム開発の費用相場」およびリサーチノート、2026年確認）。

見積書では、PM、業務コンサルタント、アーキテクト、上級SE、開発者、テスター、インフラ担当の役割と工数を確認します。2025年7月の調査では、C#.NETのフリーランス案件の月額平均単価が69.2万円とされています（出典: エン・ジャパン「フリーランススタート 開発言語別の月額平均単価」、2025年7月）。受託開発の見積には、会社の管理費、品質管理、請負リスク、設計・テスト、営業や調整の工数も含まれるため、この単価をそのまま発注単価に置き換えません。

各社の見積を比べるときは、総額だけでなく、要件定義何人月、設計何人月、開発何人月、テスト何人月、移行何人月、PM何人月かをそろえます。画面1枚あたりの単価だけで判断すると、裏側の権限、帳票、API、データ整備、受け入れ支援が抜けた提案を安く見誤る可能性があります。

初期開発費とは別に、AzureやAWSのコンピューティング、データベース、ストレージ、ログ、監視、バックアップ、通信の利用料がかかります。小規模な検証環境では月2万〜10万円程度、中規模の業務システムでは月10万〜50万円程度を仮置きする考え方がありますが、可用性、データ量、通信量、環境数で変動する推定です。発注先には、開発・検証・本番の環境ごとの月額試算と、利用量が増えた場合の変動要因を出してもらいます。

保守費は、問い合わせ、障害対応、軽微改修、監視、バックアップ確認、セキュリティ更新、.NETのバージョンアップ、運用報告を分けて見積もります。一般的な業務システムでは初期費用の年10〜25％程度を保守の検討目安とする考え方がありますが、.NET Coreの公的平均ではありません。対応時間、SLA、月間改修枠、休日対応、バージョンアップ検証を含める範囲によって、必要な予算を調整します。

委託先の選定と見積比較で確認すべきポイント

委託先は、単に「C#対応」と書かれている会社ではなく、ASP.NET Coreを本番運用した経験、対象業務に近い実績、クラウド・オンプレミスの両方を含む運用力で選びます。公開実績だけで判断せず、同時利用者数、データ量、障害対応、バージョン更新、保守体制を質問し、提案と見積の中身を同じ条件で比較します。

実績確認では、「.NETに対応できますか」ではなく、「ASP.NET Coreのどのバージョンで、どの業務を、何人が何年運用し、どのような障害や更新に対応したか」と質問します。販売、在庫、受発注、金融、医療、学校など自社に近い業務の経験があれば、業務ルールの理解やテスト設計に生かしやすくなります。

提案時の担当者と、実際に設計・開発・保守する担当者が同じかも確認します。PM、業務担当、アーキテクト、開発者、インフラ担当、テスターの役割、再委託の有無、担当者の交代時の引き継ぎ方法を聞きます。可能であれば、類似案件の画面やデモだけでなく、エラー時のログ確認、復旧手順、権限エラーの扱いも見せてもらいます。

提案書では、ASP.NET Core、BlazorやReactなどの画面方式、API、データベース、認証基盤、Azure・AWS・オンプレミスの構成を確認します。方式そのものよりも、なぜその方式を選んだか、将来の利用者増加や外部連携にどう対応するか、運用担当者が何を管理するかを説明できているかが重要です。

リスク欄には、既存コードのブラックボックス化、データの欠損や重複、連携先の仕様変更、旧バージョンのサポート終了、担当者不足、現場の利用定着を記載します。リスクを隠す提案より、PoC、移行リハーサル、段階リリース、教育、保守の条件まで示す提案の方が、実行可能性を評価しやすくなります。

見積比較では、要件定義、基本設計、詳細設計、開発、テスト、移行、教育、リリース、保守、クラウド構築を横並びにします。A社が初期費用に含めているデータ移行をB社が別項目にしている場合があるため、総額だけでなく、含む・含まない・条件付きの三つに分けて確認します。

安い見積が出たときは、担当者の経験が浅い、テストやPM工数が少ない、外部連携が対象外、データ移行が別料金、保守が時間外対応なしという可能性を確認します。高い見積では、過剰なマイクロサービス、不要なカスタマイズ、将来構想を初期開発へ含めていないかを確認します。機能・品質・納期・保守のどれを優先するかを社内で合意してから、価格を評価します。

発注前に、ソースコード、データ、クラウドアカウント、CI/CD、監視設定、設計書を自社が取得できるか確認します。専用の運用ツールや独自フレームワークを使う場合は、別会社へ移管する費用と期間、開発会社が事業を停止した場合の引き継ぎ手順、契約終了後の保守可否も確認します。

また、再委託先の範囲、個人情報へのアクセス、海外拠点の利用、障害時の連絡経路、バックアップの保管場所を契約に反映します。自社の情報システム部門が運用を担うのか、外部会社へ継続委託するのかを先に決めると、納品物や教育内容、保守費用の妥当性を判断しやすくなります。

よくある質問（FAQ）

.NET Coreのシステムを発注する前に、多くの企業が技術選定、既存資産の移行、予算、開発会社の選び方で迷います。ここでは、見積依頼前に確認しやすい代表的な質問へ、発注者の判断に直結する形で回答します。

厳密には同じものではありません。.NET Coreは実行基盤や開発プラットフォームの旧称で、ASP.NET Coreはその上でWeb画面やWeb APIを作るフレームワークです。発注時は「.NET Core対応」だけでなく、ASP.NET Coreのバージョン、C#、データアクセス、認証、クラウド、保守の実績まで確認します。

新規開発では、サポート期間が長い.NET 10を第一候補にし、利用ライブラリ、既存資産、開発会社の対応状況を確認します。.NET 8を選ぶ場合は、2026年11月10日のサポート終了までに更新できる計画と費用を契約へ含めます。バージョンだけでなく、更新時の回帰テストと本番再デプロイの担当者を決めることが重要です。

活用できる可能性はありますが、コードをそのまま移すだけで済むとは限りません。依存ライブラリ、認証、IIS設定、データベース、帳票、文字コード、外部連携を調査し、再利用、ラッピング、段階的な再開発のどれが適切かを判断します。発注前に、代表的な画面とデータを使った移行PoCを依頼すると、見積の精度を高められます。

要件をそろえたうえで、2〜3社を基本に比較すると、提案の違いと価格の幅を把握しやすくなります。大規模案件や専門性の高い移行では、候補を3〜5社に広げてもよいですが、会社数を増やしすぎると提案準備と質疑対応に時間がかかります。RFPで同じ質問をし、技術力、業務理解、体制、保守、費用の順に評価します。

まとめ

.NET Coreのシステムを発注・外注するときは、開発会社を先に決めるのではなく、対象業務、既存資産、データ、連携、権限、性能、運用、サポート期限を整理します。そのうえで、確定した機能は請負、検証が必要な部分は準委任、複雑な案件は段階発注として、契約と成果物を設計します。

最低限、RFPには目的とKPI、業務範囲、画面・帳票・API・バッチ、利用者と権限、データ移行、非機能要件、希望時期、納品物、保守条件を記載します。見積書は人月と工程、含む・含まない範囲、クラウドやライセンス、追加変更、更新対応を分解して比較します。価格の安さだけではなく、何が抜けているかを確認することが重要です。

既存.NET資産の移行、複雑な権限、外部API、性能要件がある場合は、代表的な業務とデータを使ったPoCや移行リハーサルを先に実施します。成功条件と失敗時の切り戻しを確認してから本開発へ進めば、見積の不確実性と本番障害のリスクを小さくできます。開発後も、.NETの更新、NuGetの脆弱性、監視、バックアップ、引き継ぎを保守計画に残します。

▼全体ガイドの記事
・.NET Coreのシステム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。