相談する

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

.NET Coreのシステム開発は、業務整理、RFPの作成、契約、開発・移行の順に進めると、予算と品質を管理しやすくなります。

発注の対象は画面だけでなく、業務ルール、データ、権限、移行、保守まで含みます。Azure・AWS移行や既存資産、保守委託も、同じ流れで整理できます。

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

AI駆動開発の基本や工程ごとの活用方法、費用・期間への影響については、無料ホワイトペーパー「【2026年最新版】AI駆動開発の完全ガイドブック」で詳しく解説しています。

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

.NET Coreは、現在の.NETにつながる呼称です。業務WebシステムではASP.NET Coreを使い、画面、Web API、バッチ、認証・認可、外部サービス連携などを構築します。

発注対象は画面だけではないため、業務ルール、データベース、権限を中心に、一つの業務基盤として考えます。ログ、インフラ、テスト、移行、保守までを同じ基盤の一部として扱い、その内訳は次の節で業務単位に分けて整理します。

発注対象の業務単位での定義

「.NET Coreで業務システムを作る」だけでは、会社ごとに想定する範囲が変わります。そこで、RFPでは業務単位で委託対象を特定します。

  • 業務機能：顧客・商品・案件のマスタ、受発注・在庫処理
  • 周辺機能：帳票、CSV、承認、通知、会計・ERP連携、監査ログ
  • 規模と工程：利用者数、同時アクセス、月間件数、保存期間、委託工程
  • 移行・連携条件：件数、文字コード、欠損・重複、接続先仕様

委託工程は、現状調査、要件定義、UI設計に分けて決めます。開発、移行、クラウド構築も、作業ごとに区切ります。テスト、教育、リリース、保守まで含め、工程ごとに整理します。

データ移行と外部連携は追加費用になりやすいため、必要な性能やインフラと合わせて、範囲をはっきり書いておきます。

パッケージ・クラウド・スクラッチの比較

方式を選ぶ際は、標準業務への適合、既存資産の活用、運用の複雑さを比べます。構成については、最初からマイクロサービスにする必要があるかを慎重に確認します。

  • パッケージ・SaaS：標準的な販売管理や勤怠管理に業務を合わせられる場合に導入する
  • .NETで補完：独自性の高い機能だけを個別開発する
  • 段階刷新：既存SQL Server、VB.NET、ASP.NET、社内認証を活用したい場合に検討する
  • 役割分担：標準領域はパッケージ、独自業務はスクラッチ、連携はAPI
  • 構成方式：業務境界やチーム体制を踏まえて選ぶ

規模やチーム体制によっては、モノリスをコンテナなどで運用するほうが、分散構成よりコストと複雑性を抑えられます。Microsoft Learnもこの点を説明しています（出典: Microsoft Learn「Common web application architectures」、2026年8月確認）。また、業務境界が明確な部分だけをAPIやサービスに切り出せば、発注後の運用も現実的になります。

発注形態の選び方

請負、準委任、段階発注を、それぞれ完成した機能の納品、不確かな要件の作業、仕様確定後の請負への切り替えとして並べた図。
要件の確かさと完成条件が、契約形態を選ぶ分かれ目になります。

要件と完成条件が固まった部分は請負、検証しながら決める部分は準委任が適しています。両方が混在する案件は段階発注にし、変更の可能性、社内の意思決定を担う人員、納品後の保守責任を踏まえて選びます。

請負契約による完成機能の納品

請負では、納品物の完成条件と、変更が起きたときの扱いを、契約書や仕様書に具体的に書き込みます。

  • 合意事項：画面・API・連携先・納期・受入条件を合意できる場合は、機能単位で委託しやすい
  • 変更条件：業務ルールや画面数の大幅変更は、再見積もりになる場合がある
  • 完成条件：正常系と異常系、権限別テスト、性能、バックアップ・復旧、移行照合、不合格となる条件を契約に記載
  • 納品物：マニュアル、ソースコード、設計書、環境構築手順

準委任契約による専門人材の伴走

要件が不確かな作業では、進め方と成果の共有方法を先にそろえておきます。

  • 向く状況：要件が未確定で、業務部門と開発会社が協議しながら設計する場面
  • 対象作業：現状調査、PoC、MVP（Minimum Viable Product）、コード解析
  • 計画作業：移行計画やアーキテクチャ検討を、短いサイクルで進める
  • 契約上の確認：月次稼働報告に加え、スプリントごとの成果物、決定事項、未解決課題、次月の優先順位を確認する

準委任は稼働時間を確保する契約で、機能完成や固定納期が自動で保証されるものではありません。そのため、設計書、コード、テスト記録を自社に残す場合は、受け渡しの時期も決めておきます。

段階発注による不確実な部分の小規模な検証

最初に準委任で現状調査と要件定義を行い、仕様が確定したあとでアプリ本体を請負へ切り替える方法があります。難易度を読みにくいデータ移行、外部API連携、負荷試験は、PoCや技術検証として切り分けることもできます。

後工程へ渡す成果物は、要件定義書、画面一覧、データ項目定義などです。API仕様、権限マトリクス、移行対象一覧も、後工程で使える状態にそろえます。未完成の成果物を残したまま開発に進まないよう、工程ごとに完了条件を決めておきます。

契約を工程ごとに分けると、工程の境目で責任を押し付け合う恐れがあります。そのため、全体を見るプロジェクト責任者を決めておきます。

ポイント

迷ったときは、要件と完成条件がどこまで固まっているかを基準にします。固まっていない部分をどう扱うかで、請負・準委任・段階発注のどれが合うかが変わります。

.NET Coreのシステム発注・外注の進め方

システム発注を現状調査、RFP作成と提案比較、要件定義・設計・開発、テスト・移行・リリース・運用引き継ぎの順で示した図。
初期の業務整理から稼働後の保守まで、発注者の判断が続きます。

発注は、会社を探す前に自社の業務と制約を整理するところから始めます。各工程で発注側が判断する項目も、記録として残しておきます。

  1. 現状調査で業務、既存資産、課題を把握する
  2. RFPを作成し、提案と見積を比較する
  3. 要件を定義し、設計・開発を進める
  4. テストとデータ移行を行い、リリースする
  5. 運用を引き継ぎ、保守を開始する

現状調査での業務・資産・課題の洗い出し

対象業務の担当部署と利用者、処理件数を整理します。承認経路や繁忙期、例外処理も、現場に確認しておきます。業務ルールとデータの正しさを把握しないと、旧システムを新しい画面に置き換えるだけになりがちです。

現行の資産は、.NET FrameworkやVB.NET、ASP.NETを一覧にします。SQL ServerやExcel、CSVも同じ一覧に加えます。また、Active DirectoryやMicrosoft Entra IDなどの認証基盤も確認します。

入力の手間は、入力時間、承認の滞留日数、月間の二重入力件数として数字で押さえます。短縮したい時間、削減したいミス、必要な可視化をKPIとして決めておくと、提案の比較や効果測定に役立ちます。

RFPでの目的・範囲・非機能要件の明示

複数社の提案条件をそろえるため、RFPには案件の背景から求める性能まで記載します。

  • 案件情報：背景、課題、対象業務・利用者、対象外範囲、希望時期、予算
  • システム情報：機能、既存環境、データ、外部連携、求める納品物
  • 機能の詳細：必須項目、重複判定、権限、履歴、検索、CSV、エラー処理
  • 非機能要件：利用者数、応答・稼働時間、バックアップ・復旧、監視、ログ、アクセス元制限、個人情報、脆弱性

「通常操作は3秒以内」「障害時は何時間以内に一次回答」「履歴を何年間保存」のように、後から検証できる書き方にします。未確定の項目については、確認の方法と追加費用の条件を、提案会社に示してもらいます。

設計・開発での業務境界と更新方針の確認

発注時には、システム構成と更新方針を一緒に決め、運用時の互換性も見通しておきます。

  • 構成要素：画面、ASP.NET CoreのWeb/API、業務ロジック、データアクセス、DB
  • 構成判断：画面/APIの分離、バッチ・キュー、クラウド・オンプレミス
  • バージョン：.NET 10はLTSで2028年11月14日まで、.NET 8は2026年11月10日までサポート（2026年8月時点）
  • 更新準備：対応ライブラリ、既存資産との互換性、更新時期、検証環境、費用

データアクセスには Entity Framework Core、DBには SQL ServerやPostgreSQLなどの選択肢があります。構成は利用者数、連携数、運用体制をもとに決め、バージョンも開発会社の得意技術だけで選ばないようにします。新規開発では、.NET 10を候補にします。

更新条件は、RFPと保守契約に含めておきます（出典: Microsoft「.NET and .NET Core official support policy」、2026年8月確認）。

テスト・移行・リリースの工程別管理

本番移行でのやり直しを減らすため、検証、データ移行、稼働後の対応を分けて計画します。

  • テスト：単体・結合・総合・受け入れ、権限別、異常系、業務完了を確認
  • 障害検証：大量データ、連携停止、タイムアウト、二重登録、通信切断、復旧
  • データ移行：期間・件数、欠損・重複、文字コード、添付、コード対応、照合
  • リリース後：問い合わせ窓口、初期不具合対応期間、操作教育を計画する

業務部門は、本番での利用を想定して受け入れを行い、未解決の不具合と回避策を記録します。移行では、テストとリハーサルを重ねたうえで、切り戻しの条件を定めておきます。

ポイント

迷ったら、発注の前に業務と制約を整理できているかを基準にします。工程ごとに誰が判断するかが決まっていないと、途中で判断が止まる原因になります。

契約形態と委託範囲の取り決め

契約書では、完了条件と仕様変更の扱いを明確にします。成果物の保有者や、障害・脆弱性への対応者も、あわせて決めておきます。

請負と準委任の責任境界の契約への反映

契約方式によって、責任や記録の対象が変わります。そのため、それぞれの取り決めを契約に明文化します。

  • 請負：成果物、納期、検収、契約不適合、変更時の再見積もり
  • 準委任：稼働、スキル、報告、指示系統、成果物共有、期間、引き継ぎ
  • 工程別契約：要件定義は準委任、確定機能の開発は請負などで組み合わせる
  • 変更記録：要望の理由、影響、工数、納期、テスト範囲、承認者を残す
  • 優先順位変更：月額準委任でも後ろ倒しになった作業を記録する

ソースコード・設計書・権利の帰属の明記

納品後も保守や改修を続けられるように、成果物、運用資料、権利の扱いを決めておきます。

  • 開発成果：ソース、リポジトリ、設計書、DB定義、API仕様、テスト資料
  • 運用資料：構築、CI/CD、監視、バックアップの手順、管理者マニュアル
  • 保有と権利：リポジトリ・クラウド契約の保有者、著作権譲渡範囲、既存部品・OSS・第三者ライセンス
  • 利用範囲：翻案・改修、著作者人格権、共通部品と自社専用成果物を整理

Gitリポジトリやクラウド契約は、個人のアカウントに頼らず、保有者を決めておきます。そうすれば、将来の保守移管や内製化に備えられます。

保守・脆弱性対応・バージョン更新の範囲

保守契約には、日常の対応に加えて、更新やセキュリティ上の責任分担も含めておきます。

  • 保守サービス：受付時間、障害重要度、回答・復旧目標、月間改修枠、バックアップ確認、監視、ログ調査、定期報告
  • 更新対応：.NET更新とNuGet脆弱性情報の確認、自己完結アプリの再ビルド、本番再デプロイの担当
  • アクセス対策：認証・認可、権限、HTTPS、CSRF・XSS・SQLインジェクション、CORS、MFA
  • 情報保護：秘密情報、最小権限、監査ログ、依存パッケージのスキャン

認証と認可は分けて考え、ロールだけでなくポリシーやリソース単位で制御します。Microsoft Learnでも、認証・認可、データ保護、秘密情報の管理を個別に扱っています（出典: 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、開発者、テスター、インフラ担当の工数
  • 比較単位：要件定義、設計、開発、テスト、移行、PMの人月をそろえる
  • 対象範囲：権限、帳票、API、データ整備、受け入れ支援を含めた範囲

参考までに、2025年7月のC#.NETフリーランス案件の月額平均単価は69.2万円です（出典: エン・ジャパン「フリーランススタート 開発言語別の月額平均単価」、2025年7月）。

受託の見積には、管理費や品質管理の工数も含みます。さらに、請負リスクや設計・テスト、営業・調整の工数も、見積の中に入っています。そのため、フリーランスの単価をそのまま発注単価と見なさず、画面単価だけでは判断しないようにします。

クラウド・ライセンス・保守費の別枠での試算

稼働後のクラウド利用料と保守費も、初期開発費と並べて見積もります。

AzureやAWSのような基盤を使う場合は、利用料が毎月かかる点を押さえておきます。

  • クラウド利用料：計算資源、DB、ストレージ、ログ、監視、バックアップ、通信
  • 検証環境：小規模は月2万〜10万円程度、中規模は月10万〜50万円程度を仮置き
  • 保守範囲：問い合わせ、障害、軽微改修、監視、バックアップ、セキュリティ、.NET更新、報告
  • 保守費の目安：一般的な業務システムで初期費用の年10〜25％程度という考え方

クラウド費は、可用性、データ量、通信量によって変わる推定です。環境数も関係するため、開発・検証・本番それぞれの月額と、利用量が増えたときの変動要因を、発注先に試算してもらいます。

保守費の割合は、.NET Coreの公的な平均ではありません。対応時間や月間改修枠に応じて予算を調整し、SLAや休日対応、更新検証の範囲も踏まえます。

ポイント

費用は規模や前提条件で変わるため、目安はレンジで持ちます。初期開発費に加えて、クラウド利用料と保守費も並べて、稼働後の負担を含めて判断します。

委託先の選定と見積比較の観点

ASP.NET Coreの委託先選定で確認する本番運用実績、対象業務の経験、クラウドとオンプレミス双方の運用力、担当体制を示した図。
技術経験に加えて、業務理解と運用を担う体制も選定に関わります。

委託先は「C#対応」だけでなく、ASP.NET Coreの本番運用実績、対象業務に近い経験、クラウドとオンプレミス双方の運用力で選びます。

同時利用者数やデータ量、障害対応などは、提案会社に直接質問しておきます。バージョン更新と保守体制も確認し、そのうえで、同じ条件で提案と見積を比べます。

ASP.NET Coreの本番実績と担当体制

実績を確認する際は、技術経験に加えて、提案時の担当者と実際の担当者が同じかを見ます。担当体制や引き継ぎの実態も、あわせて比べます。

  • 技術実績：ASP.NET Coreの版、業務、運用人数・年数、障害・更新対応を質問する
  • 業務経験：販売、在庫、受発注、金融、医療、学校などの類似実績
  • 担当体制：提案・設計・開発・保守の担当、PMなど各役割
  • 引き継ぎと実演：再委託、交代時の引き継ぎ、ログ・復旧・権限エラーへの対応

近い業務の経験は、業務ルールの理解やテスト設計に役立ちます。可能であれば、画面やデモも見せてもらいます。

提案書の方式選定とリスクへの回答

提案書は、技術構成だけでなく、選定理由、想定リスク、その対応策をあわせて比べます。

  • 技術構成：ASP.NET Core、Blazor・React、API、DB、認証、クラウド等
  • 選定理由：利用者増加、外部連携、運用担当の管理範囲への対応
  • 想定リスク：既存コード、データ不備、仕様変更、旧版終了、担当者不足、定着
  • 対応策：PoC、移行リハーサル、段階リリース、教育、保守条件

方式そのものに加えて、選定理由と運用担当者が管理する範囲を説明できているかを確かめます。

見積書の作業単位での分解と比較

見積は総額だけでなく、作業単位と費用条件をそろえて比べます。

  • 作業単位：要件定義、基本・詳細設計、開発、テスト、移行、教育、リリース、保守、クラウド構築を横並びにする
  • 費用条件：「含む・含まない・条件付き」で確認する。A社は移行を初期費用に含み、B社は別項目の場合もある
  • 安い見積：担当者の経験、テスト・PM工数、連携の対象範囲、移行費、時間外保守の有無
  • 高い見積：過剰なマイクロサービス、不要なカスタマイズ、将来構想の初期開発への混入を確認し、機能・品質・納期・保守の優先順位を社内で合意する

ベンダーロックインと撤退条件

ソースコードやデータ、設計書を、自社が取得できるかを確認します。クラウドアカウントやCI/CD、監視設定の取得可否も確かめます。専用ツールや独自フレームワークを使う場合は、移管の費用と期間も聞きます。

開発会社が事業を停止した場合の引き継ぎや、契約終了後の保守可否も確認します。再委託先や海外拠点、個人情報へのアクセスは、契約に反映しておきます。障害時の連絡経路とバックアップ保管場所も、同じ契約に書き込みます。

運用を自社の情報システム部門で担うか、外部へ継続して委託するかを先に決めておくと、納品物や教育、保守費用が妥当かを判断できます。

ポイント

委託先は、C#の経験だけでなく、本番運用の実績と対象業務への近さで比べます。見積は作業単位をそろえ、含む範囲と含まない範囲を並べてから判断します。

よくある質問（FAQ）

発注では、技術選定や既存資産の移行、予算で迷うことが少なくありません。開発会社の選び方も、判断に悩みやすい点です。そこで、見積依頼の前に確認しておきたい質問に、順に答えます。

.NET CoreとASP.NET Coreは同じものですか？

厳密には異なります。.NET Coreは実行基盤や開発プラットフォームの旧称で、ASP.NET Coreはその上でWeb画面やWeb APIを作るフレームワークです。

発注時は「.NET Core対応」だけでなく、ASP.NET Coreのバージョン、C#、データアクセス、認証の実績も確認します。クラウドや保守の実績も、あわせて聞いておきます。

.NET 8と.NET 10のどちらで開発を発注すべきですか？

新規開発では、サポート期間が長い.NET 10を第一候補にします。そのうえで、ライブラリや既存資産、開発会社の対応状況を確認します。.NET 8を選ぶ場合は、更新計画と費用を契約に含めておきます。

.NET 8は2026年11月10日にサポート終了予定です。そのため、更新時の回帰テストと本番再デプロイの担当も、あらかじめ決めておきます。

既存のVB.NETやASP.NETの資産は活用できますか？

活用できる可能性はありますが、そのまま移行できるとは限りません。依存ライブラリ、認証、IIS設定を調べます。DBや帳票、文字コード、外部連携も、あわせて確かめます。

再利用、ラッピング、段階的な再開発のなかから、適切な方法を選びます。そのうえで、代表的な画面とデータで移行PoCを行うと、見積の精度を高められます。

何社くらいに相見積もりを依頼するとよいですか？

要件をそろえたうえで2〜3社を基本として依頼すると、提案の違いと価格幅が見えてきます。大規模案件や専門性の高い移行では、3〜5社に広げてもよいでしょう。

会社数を増やしすぎると、提案準備と質疑対応に時間がかかります。そのため、同じRFPで質問し、技術力と業務理解を中心に評価します。体制や保守、費用も、同じ基準で比べます。

まとめ

.NET Coreの発注では、開発会社を先に決めず、対象業務と既存資産、データを整理します。連携や権限、性能に加えて、運用とサポート期限も、発注前に押さえておきます。

確定した機能は請負、検証が必要な部分は準委任とし、複雑な案件では段階発注を選びます。そのうえで、契約と成果物を設計します。

発注前に確認する項目

RFPには、目的とKPI、業務範囲、利用者と権限を記載します。加えて、画面・帳票・API・バッチ、データ移行、非機能要件を書き込みます。さらに、希望時期、納品物、保守条件も含めます。

見積は、人月と工程ごとに分けてもらいます。含む範囲と含まない範囲を明記してもらい、そのうえで、クラウドやライセンス、追加変更、更新対応を確かめます。金額の大小だけで決めず、抜けている項目も見ます。

小規模な検証と本番発注

本開発に進む前に、検証の範囲と判断の条件を決め、稼働後まで見越した計画を立てます。

  • 事前検証：既存.NET資産、複雑な権限、外部API、性能要件を試す
  • 本開発の判断：代表業務・データでのPoCと移行リハーサル
  • 保守計画：.NET更新、NuGet脆弱性、監視、バックアップ、引き継ぎを含める

成功条件と、失敗時の切り戻しを確認してから本開発に進めば、見積の不確実さと本番障害のリスクを抑えられます。

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

▼開発を相談する前に読みたい無料ホワイトペーパー
・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

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

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

執筆者プロフィール
張田谷凌央
張田谷凌央

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