ASP.NETのシステムを発注・外注するなら、新規開発か既存システムの改修かを分け、Web Forms・ASP.NET MVC 5・ASP.NET Coreのどれを対象にするかを先に確定することが重要です。技術名だけで委託先を探すと、移行できない古い部品や、要件に含まれていないデータ移行・帳票・運用費が後から発覚し、予算と納期が崩れやすくなります。
この記事では、ASP.NETのシステム開発を発注する際の発注形態の選び方、RFPと要件の整理、契約形態、費用相場、委託先の選定、見積書の比較方法を順に解説します。既存のWeb Formsを延命する場合から、ASP.NET Coreで新しい業務システムを構築する場合まで、社内で発注条件を固めるための判断材料をまとめています。
▼全体ガイドの記事
・ASP.NETのシステム開発の完全ガイド
ASP.NETのシステム発注で最初に整理すべき全体像

ASP.NETは、Microsoftの.NET上でWebアプリケーションを開発する基盤です。顧客管理、受発注、在庫、請求、ワークフロー、帳票、外部サービス連携など、企業ごとの業務に合わせたシステムを構築できます。発注前に押さえるべきなのは、ASP.NETという名称だけではシステムの状態や難易度が決まらないことです。
新規開発か既存改修かを最初に分けます
新規開発では、業務の理想像に合わせて画面、データベース、認証、権限、連携方法を設計できます。一方、既存システムの改修では、ソースコードだけでなく、古いOS、データベース、帳票製品、ActiveX、Windows認証、サードパーティー部品まで調査が必要です。仕様書が残っていない場合は、現行画面とデータを確認する調査工程だけで見積もりが発生します。
Web Forms・MVC 5・ASP.NET Coreを確認します
既存のWeb FormsやASP.NET MVC 5を保守する案件と、ASP.NET Coreで新規開発する案件では、必要な知識とリスクが異なります。新規案件は原則としてサポート期間を確認したASP.NET Coreを候補にし、既存案件は継続保守、部分移行、全面再構築を比較します。Microsoftのライフサイクル情報では、.NET 10は2025年11月にリリースされ、2028年11月までサポートされる長期サポート版です。.NET 8のサポート期限は2026年11月です(出典: Microsoft Learn「Microsoft .NET and .NET Core – Lifecycle」、2026年8月確認)。
社内向けか顧客向けかで要求水準が変わります
社内の限られた利用者が使う業務システムでは、社内ネットワークや既存のアカウント基盤を活用できる場合があります。顧客向けサービスでは、不特定多数のアクセス、ピーク負荷、決済や個人情報、障害時の告知と復旧まで求められます。利用者数だけでなく、ピーク時の同時利用者数、1日の登録件数、データ保持年数、停止できる時間をRFPに書くと、委託先が同じ前提で見積もりやすくなります。
発注形態はスクラッチ・パッケージ・クラウドから選びます

発注形態の選択は、技術選定より先に業務の標準化度合いを見ます。標準機能で足りるならパッケージやSaaSが早く、独自の承認・料金計算・外部連携が競争力に直結するならスクラッチ開発が適しています。既存ASP.NET資産を生かしながら、差別化部分だけをASP.NET Coreで作るハイブリッドも現実的な選択肢です。
スクラッチ・パッケージ・SaaSを業務適合性で比べます
パッケージやSaaSは、初期構築を抑えやすく、標準的な顧客管理や申請管理を短期間で導入しやすい点が利点です。ただし、標準外の業務を無理に合わせると、現場がExcelへ戻ったり、追加開発が増えたりします。スクラッチでは業務に合わせて設計できますが、要件定義の質と保守人材への依存が大きくなります。候補ごとに、必須業務を標準機能で満たせるか、追加開発の範囲はどこか、データを取り出せるかを確認します。
クラウドとオンプレミスは運用責任で選びます
Azure App ServiceやAzure SQLなどのクラウドは、環境構築、監視、バックアップ、負荷に応じた拡張を設計しやすい選択肢です。一方で、月額費用、通信経路、リージョン障害、ログの保管、アカウント権限を継続管理する必要があります。オンプレミスは既存LANや特殊機器と接続しやすい反面、サーバー更新、バックアップ、脆弱性対応を自社で担います。見積書では「構築費」だけでなく、誰が毎月どの作業を担当するかを明記します。
一括請負・準委任・ラボ型を案件の不確実性で選びます
仕様と納期が固まっており、成果物を明確に定義できる場合は、一括請負契約が候補になります。要件を調査しながら段階的に作る場合や、既存コードの解析で不確実性が高い場合は、準委任契約で調査・要件定義を先に発注し、その後に開発契約へ分ける方法が安全です。継続的に機能追加するラボ型では、稼働人数、対応時間、成果物、交代ルール、最低契約期間を確認します。
ASP.NETのシステム開発を発注する進め方

発注は、会社を先に決めてから要件を考えるのではなく、現状整理、RFP作成、提案比較、契約、設計・開発、受入、運用移管の順で進めます。特に既存ASP.NETでは、提案前に現行環境を見せる調査期間を置くと、根拠のない一律価格を避けやすくなります。
現行業務とシステムを棚卸しします
まず、誰が、いつ、何を入力し、どの承認を経て、どの帳票や連携データを出すのかを業務単位で整理します。画面一覧だけでは、例外処理、Excelでの補正、紙の承認、締め処理、手作業の照合が抜けます。現場担当者へのヒアリングでは、通常フローだけでなく「急ぎの受注」「返品」「担当者不在」「データ訂正」「障害時の代替手順」も確認します。
要件定義とPoCで難所を先に確かめます
要件はMust、Should、Couldに分け、最初のリリースに必要な範囲を絞ります。外部API連携、大量帳票、既存データの変換、古い認証、複雑な権限など、失敗すると手戻りが大きい部分は、小さな画面やデータでPoCを行います。新規システムでも、実装を始めてから「この帳票は印刷位置が1ミリ単位で必要だった」「この外部サービスは夜間しか連携できない」と分かると、費用と納期が大きく変わるためです。
受入テストと切替リハーサルを行います
開発会社のテストだけでなく、利用部門が実際の業務シナリオで受入テストを行います。権限のない人が見られないか、締め処理後に訂正できるか、帳票の合計が既存資料と一致するか、連携失敗時に再送できるかを確認します。データ移行は本番直前の一度だけにせず、移行リハーサル、件数照合、欠損と重複の確認、切戻し手順まで行い、研修と切替日程を確定します。
RFPと要件整理で見積もりの前提をそろえます

RFPは、開発会社に「何を作るか」だけでなく、「どの条件で成功と判断するか」を伝える資料です。完璧な仕様書を作る必要はありませんが、会社ごとに前提が違う状態で価格だけを比べないために、対象範囲、現状、希望時期、制約、評価基準をそろえます。
RFPには利用者・機能・データ・連携を記載します
最低限、利用部門、利用者数、拠点数、同時利用者数、対象業務、画面数の概算、帳票数、CSV入出力、外部API、既存データ件数、移行対象期間、希望納期を記載します。既存案件では、Web FormsかMVC 5か、.NET Frameworkのバージョン、SQL Serverなどのデータベース、ソースコードと設計書の有無、現行サーバーの構成も伝えます。秘密情報が含まれる場合は、NDA締結後にソースやデータのサンプルを共有します。
非機能要件を数字で書きます
非機能要件には、応答時間、同時利用者数、稼働時間、バックアップ頻度、復旧目標、データ保持期間、監査ログ、アクセス制御、端末とブラウザー、障害通知を含めます。「快適に動く」「安全に使える」だけでは会社ごとに解釈が変わります。たとえばピーク時の同時利用者数を100人、重要処理の目標応答時間を3秒以内といったように、測定条件と例外を含めて定義します。数値がまだ決められない場合は、要件定義で決める項目として見積もりに分けて記載します。
納品物と発注者側の責任範囲を決めます
設計書、画面仕様書、API仕様、データベース定義、ソースコード、テスト仕様書と結果、移行手順書、運用手順書、教育資料のどこまで納品するかをRFPと契約書に書きます。発注者側も、業務ルールの決定、マスタデータの整理、現場の受入担当者の確保、テストデータの準備を担当します。ここを曖昧にすると、開発会社の遅延に見えて実は発注者の確認待ちだったという事態が起きます。
契約形態と見積条件を先に決めます

契約形態は、責任の押し付け合いを防ぐための仕組みです。発注時点で決まっている範囲と、調査しなければ決まらない範囲を分け、要件定義、設計・開発、移行・教育、保守の契約を同じ書類で混ぜないようにします。
請負契約は成果物・検収・変更手続きを定義します
請負契約を選ぶ場合は、完成の条件、検収期間、瑕疵対応の範囲、納期、遅延時の扱い、仕様変更の手続き、知的財産権、再委託、秘密保持、個人情報の取扱いを確認します。特に「画面ができた」だけでなく、指定した業務シナリオを通過し、必要な性能・権限・帳票・移行結果を満たすことを検収条件に含めると、評価が明確になります。
準委任契約は作業範囲・体制・報告を明確にします
準委任契約では、特定の完成物を約束するより、合意した作業を専門家が行う形になります。既存コードの調査、要件定義、技術検証、アジャイル開発など、不確実性が高い工程と相性があります。月の稼働時間、担当者の経験、会議と報告の頻度、成果物の扱い、追加稼働の承認方法、担当者交代時の引継ぎを契約前に決めます。
保守契約は障害・更新・改善を分けて確認します
保守費用には、問い合わせ対応、障害復旧、OSや.NETの更新、脆弱性対応、バックアップ確認、法改正対応、軽微な改善などが含まれることがあります。これらを一つの「保守費」として比べず、受付時間、一次回答と復旧の目標、対象外作業、月間の対応時間、追加開発の単価を分けます。初期開発費の15〜20%を年間保守の検討目安とする考え方がありますが、クラウド料金やライセンス費を含むかで大きく変わるため、あくまで企画時の目安として扱います。
ASP.NETのシステム発注費用相場とコストの内訳

ASP.NET固有の全国一律の開発費統計はないため、以下は一般的な業務システムの公開相場と、ASP.NET案件で増減しやすい工程をもとにした企画用の推定です。ASP.NET Core自体のライセンス代だけで決まる金額ではなく、要件定義、開発工数、既存資産の解析、データ移行、テスト、インフラ、帳票、保守を含めて個別に見積もります。
規模別の費用レンジを企画の目安にします
既存Web FormsやMVCの調査・小改修は、現状調査、脆弱性やライブラリの更新、画面追加、帳票修正を含めて50万〜200万円程度が目安です。ログイン、権限、マスタ、検索、CSV、簡易帳票を備えた小規模な社内業務システムは300万〜800万円程度、ワークフロー、複数拠点、外部API、データ移行、監査ログを含む中規模案件は800万〜2,000万円程度が企画時のレンジです。ERPや会計との基幹連携、大量データ、高可用性、段階移行を含む案件では2,000万〜1億円以上になる場合があります。これらは2025年版の業務システム公開相場と関連工程から作った推定であり、ASP.NET専用の公的価格ではありません(出典: Harmonic Society「2025年版 業務システム開発費の相場と料金まとめ」、2025年。ASP.NET案件は個別見積もりが必要です)。
工程別の比率で見積もりの抜けを確認します
業務システム全般の工程を見ると、要件定義は10〜15%、設計は15〜20%、開発は30〜40%、テストは15〜20%、移行は5〜10%程度という整理ができます。ASP.NET案件では、開発費だけを見て要件定義や移行を削ると、後で業務ルールの追加とデータ不整合が発生しやすくなります。見積書に工程ごとの工数、担当、成果物、前提条件を記載してもらい、テストと移行が極端に少なくないかを確認します。
公開事例は工数と範囲を分けて読みます
BSSの公式実績ページでは、ASP.NET Core(C#)とSQL Serverによる分析結果通知サービスを約2人月、ASP.NET(C#)とPostgreSQLによるホテル内宴会情報管理システムを約6人月と掲載しています(出典: 株式会社BSS「実績」、2026年8月確認)。この数字は各案件の総工数であり、他社の価格表ではありません。人月単価、要件定義の範囲、管理費、本番移行、教育、保守の有無が分からないため、公開事例は「同じ技術なら同じ価格」と読むのではなく、機能と工程の規模を比較する材料として使います。
3〜5年のTCOで判断します
初期開発費が安くても、クラウド、データベース、帳票製品、監視、バックアップ、脆弱性診断、問い合わせ、法改正、追加開発が高ければ、総額は大きくなります。3〜5年間の利用を想定し、初期費用、移行・教育費、月額インフラ、ライセンス、年間保守、機能追加、契約終了時の引継ぎ費用を足して比較します。予算を抑える場合は、認証・マスタ・主要業務を第1期にし、高度な分析や周辺帳票を第2期に分ける方法が有効です。
ASP.NETの委託先を選ぶポイント

委託先は「C#に対応できる会社」ではなく、自社と似た業務をASP.NETでどこまで担当した会社かで見ます。技術名の一致だけでなく、要件定義、既存コードの解析、移行、インフラ、受入、保守までの責任範囲を確認し、提案担当者と実装担当者が誰かを確かめます。
ASP.NET FrameworkからCoreへの移行経験を確認します
既存システムを扱う場合は、Web Forms、ASP.NET MVC 5、.NET Framework、SQL Server、帳票、Windows認証の実績を具体的に質問します。単に「対応可能」と答える会社ではなく、どのような制約を調査し、部分移行か全面再構築かを判断した事例を示せる会社が候補です。新規開発では、ASP.NET Coreのバージョン、MVC、Razor Pages、Web API、Blazor、Entity Framework Core、認証基盤を案件に応じて選べるかを確認します。
業務理解とコミュニケーション体制を確認します
技術者が優秀でも、業務ルールを理解できなければ、使われるシステムになりません。要件定義を担当する人が業務部門の言葉を理解し、現場の例外を仕様へ落とせるかを確認します。定例会議の頻度、課題管理の方法、質問への回答期限、意思決定者、海外・地方拠点との連携、担当者が休んだときの代替体制も選定項目に含めます。
セキュリティと運用まで提案できるか見ます
ASP.NET Coreには認証・認可、データ保護、HTTPS、秘密情報の安全な保管、CSRF対策、CORS、XSS対策などのセキュリティ領域がありますが、機能が用意されているだけで安全が自動的に完成するわけではありません(出典: Microsoft Learn「ASP.NET Core security topics」、最終更新2026年5月)。権限設計、ログ監視、脆弱性診断、秘密情報の管理、バックアップ復元、パッチ適用の担当を見積もりに含めてもらいます。個人情報を扱う場合は、個人情報保護委員会の安全管理措置、会計・請求データを扱う場合は電子帳簿保存法の保存要件も確認します。
見積書を比較するときのポイント

見積金額の大小だけでは、適切な発注先を判断できません。安い見積もりは、要件定義、移行、テスト、教育、保守、ライセンス、管理費が別途になっている可能性があります。3社程度に同じRFPを渡し、工程、前提、除外項目、追加単価をそろえて比較すると、価格差の理由を説明しやすくなります。
同じ条件で工程と成果物を比べます
比較表を作るなら、要件定義、基本設計、詳細設計、開発、単体・結合・総合テスト、データ移行、受入支援、教育、リリース、保守を行にします。各工程の金額、工数、担当、納品物、期間を並べ、空欄は「含まれない」のか「未確定」なのかを確認します。画面数が少なくても、複雑な承認経路や外部連携、帳票、データ移行があれば高くなるため、画面単価だけの比較は避けます。
提案説明では担当者とリスクへの答えを聞きます
提案会では、実際に要件定義と開発を担当する人に参加してもらいます。「Web FormsからCoreへ移行する場合の第一歩は何か」「データ移行のリハーサルを何回行うか」「帳票製品のライセンスは誰が持つか」「障害時に何分以内に連絡するか」「契約終了時にソースコードと手順書をどの形式で受け取るか」と質問します。答えが抽象的な場合は、同種案件の成果物例や体制表を確認します。
安さよりも将来の変更と引継ぎを評価します
ASP.NETのシステムは、リリース後に制度変更、組織変更、連携先の仕様変更、OSや.NETの更新が発生します。短期の開発費だけでなく、ソースコードの可読性、テスト自動化、設計書の品質、開発環境の再現性、他社へ引き継げる契約かを評価します。特に一社しか保守できない状態を避けるなら、ソース、データベース定義、CI/CD設定、インフラ構成、運用手順、アカウントの所有者を契約で明確にします。
よくある質問(FAQ)

ASP.NETの発注では、技術の新旧、費用、既存資産の扱い、契約後の保守について質問が集中します。ここでは、発注前に社内で回答をそろえておきたい代表的な疑問に答えます。
ASP.NETのシステムは無料で作れますか?
ASP.NET Coreはオープンソースの基盤として利用できますが、システムを無料で発注できるという意味ではありません。要件定義、設計、開発、テスト、データ移行、Azureなどのインフラ、SQL Serverや帳票製品のライセンス、監視、保守に費用が発生します。見積もりでは基盤のライセンスと開発・運用の費用を分けて確認します。
古いWeb Formsはすぐに作り直すべきですか?
すぐに全面再構築する必要があるとは限りません。業務が安定し、セキュリティと保守を確保できるなら継続利用も選択肢ですが、サポート切れのOS・.NET・部品、仕様書不足、採用難、変更のしにくさを調査します。現状診断の後、脆弱性と依存部品を更新し、API化や画面単位の段階移行を行う方法もあります。
ASP.NET Coreはどのバージョンを選べばよいですか?
新規開発では、サポート期間、必要なライブラリ、開発会社の保守体制を確認して、長期的に更新できるバージョンを選びます。2026年8月時点では.NET 10が2028年11月まで、.NET 8が2026年11月までサポートされる情報が公開されていますが、リリース時期と契約期間によって最適解は変わります。バージョン番号だけで決めず、更新計画と互換性テストを見積もりに含めます。
開発後に保守会社を変更できますか?
変更できるようにするには、契約時点でソースコード、設計書、テスト仕様書、データベース定義、インフラ構成、運用手順を納品物に含め、アカウントとライセンスの名義を発注者側で管理します。引継ぎ期間、質問対応の単価、環境再構築に必要な情報、第三者部品の契約条件も確認します。保守会社を変える予定がなくても、将来の事業継続と担当者交代に備えて、引継ぎ可能な状態を作ります。
まとめ

ASP.NETのシステムを発注する際は、まず新規開発か既存改修かを分け、Web Forms・MVC 5・ASP.NET Coreの対象を確定します。そのうえで、スクラッチ、パッケージ、クラウド、オンプレミス、一括請負、準委任などを業務の不確実性と運用責任に合わせて選びます。
同じRFPを複数社へ渡して比較します
RFPには、利用者数、ピーク負荷、機能、帳票、外部連携、既存ソース、移行対象、非機能要件、希望時期、保守条件を記載します。見積書は工程別の金額、工数、成果物、除外項目、追加単価、ライセンス、クラウド、保守を同じ条件で比べます。価格だけでなく、ASP.NETの世代を見極める力、業務理解、セキュリティ、移行、運用、将来の引継ぎまで評価することが、発注後の手戻りを抑えるポイントです。
最初は現状調査と小さな検証から始めます
既存システムならソース、サーバー、データ、帳票、認証を調査し、新規開発なら業務フローと非機能要件を整理します。外部連携や移行などの難所をPoCで確かめ、必要であれば要件定義だけを先に委託します。発注者と委託先が同じ前提を共有し、完成条件と運用責任を契約に落とし込むことが、ASP.NETのシステム開発を成功させる近道です。
▼全体ガイドの記事
・ASP.NETのシステム開発の完全ガイド
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

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

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>


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