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

ASP.NETのシステム開発は、まず新規か既存改修かを分け、Web Forms・MVC 5・ASP.NET Coreのどれを使うかを整理するところから始まります。そのうえで発注形態と契約形態を決め、RFPをもとに複数社を比べ、開発、受入、運用移管へ進みます。

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

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

ASP.NETの発注前に整理する全体像

ASP.NETは、Microsoftの.NET上でWebアプリケーションを開発するための基盤です。

ASP.NETでは、顧客管理や受発注、在庫などの業務システムのほか、請求やワークフロー、帳票、外部サービス連携も構築できます。

同じASP.NETでも、システムの状態や難易度は案件ごとに大きく違います。そのため、ASP.NETという名称だけで判断せず、発注前に現状を確かめておきます。

新規開発と既存改修の区分

見積もりの前提をそろえるには、発注側がまず新規開発と既存改修のどちらなのかを分けて、委託先に伝えます。

• 新規開発：業務に合わせた画面、DB、認証、権限、連携の設計が中心です。
• 既存改修：ソースに加え、古いOS、DB、帳票、ActiveX、Windows認証、外部部品まで調べる必要があります。
• 仕様書がない場合：現行画面とデータを調べるだけでも、見積もりの対象になります。

対象技術（Web Forms・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月確認）。

社内向けか顧客向けかによる要求水準の違い

利用者の範囲によって必要な性能、セキュリティ、障害対応が変わるため、RFPには運用条件も示しておきます。

• 社内向け：社内ネットワークや既存アカウントを活用できる場合があります。
• 顧客向け：ピーク負荷、決済、個人情報、障害対応を考慮します。

利用者数に加えて、同時利用者数、1日の登録件数、データ保持年数、停止可能時間をRFPに記載しておくと、各社が同じ前提で見積もれます。

発注形態の選択肢（スクラッチ・パッケージ・クラウド）

発注形態は、技術選定より先に、業務を標準化できるかで考えます。

標準機能で足りるなら、初期構築を抑えやすく早く導入できるパッケージやSaaSが候補です。一方で、独自の承認・料金計算・外部連携が競争力に直結するなら、スクラッチ開発が適しています。

既存ASP.NET資産を生かし、差別化の部分だけをASP.NET Coreで作る方法もあります。

スクラッチ・パッケージ・SaaSの業務適合性による比較

必須業務への適合と将来の運用を並べて見ると、方式を絞り込めます。

• パッケージ・SaaS：標準的な顧客管理や申請管理を早く導入できます。
• スクラッチ：独自業務に合わせやすい一方、要件定義と保守人材の確保が欠かせません。

標準外の業務を無理に合わせると、追加開発が増え、現場がExcelに戻ってしまうこともあります。そのため、候補ごとに必須機能、追加開発の範囲、データの取り出し可否を確かめます。

クラウドとオンプレミスの運用責任による選び方

まず、環境の運用をどちらが担うかを確かめ、構築費だけでなく継続作業も含めて見積もります。

• クラウド：環境構築、監視、バックアップ、拡張を設計しやすい一方、月額費用や権限管理が続きます。
• オンプレミス：既存LANや特殊機器と接続しやすく、自社で更新を担います。

Azure App ServiceやAzure SQLはクラウドの選択肢です。クラウドでは通信経路、リージョン障害、ログ保管、権限を管理し、オンプレミスではサーバー更新、バックアップ、脆弱性対応を自社で担います。見積書には、毎月の作業を誰が担当するかも書いてもらいます。

案件の不確実性で選ぶ一括請負・準委任・ラボ型

仕様の確定度と開発の継続性によって、契約形態を使い分けます。

• 一括請負：仕様と納期が固まり、成果物を定義できる案件向けです。
• 準委任：調査や要件定義など、不確実性の高い工程に向きます。
• ラボ型：継続的な機能追加が続く案件向けで、人数、対応時間、交代ルールを決めます。

既存コードの解析では、まず準委任で調査を発注し、その結果をもとに開発契約へ分けて進める方法があります。

ラボ型を選ぶ場合は、成果物と最低契約期間も決めておきます。

ASP.NETのシステム開発を発注する進め方

まず要件と前提を整理してから委託先を比べます。全体の流れは、現状整理とRFPから始まり、提案比較と契約を経て、開発、受入、運用移管へ進みます。

既存ASP.NETでは、提案の前に現行環境を調べる期間を設けておくと、調査なしの一律の見積もり価格になるのを避けられます。

現行業務とシステムの洗い出し

業務の流れと例外を整理すると、画面一覧だけでは見えない作業が分かります。

• 通常業務：入力、承認、帳票、連携データの流れです。
• 例外業務：返品、訂正、担当者不在、急ぎの受注を調べます。
• 代替手順：障害時の対応やExcel補正も把握します。

現場の担当者には、締め処理や紙の承認、照合作業も聞き取ります。そのうえで、業務ごとに誰がいつ何を処理しているかを確かめます。

要件定義とPoCによる難所の事前確認

まず初回リリースの範囲を決め、手戻りが大きくなりやすい機能は小さく検証します。

• 要件の優先度：Must、Should、Couldに分類します。
• PoCの対象：API、帳票、データ変換、古い認証を試します。

帳票の印刷位置や外部サービスの連携時間は、実装後に分かると費用と納期が変わってしまいます。だからこそ、小さな画面やデータで先に確かめておきます。

受入テストと切替リハーサルの実施

利用部門が業務シナリオに沿って受入テストを行い、本番移行の手順も事前に確かめます。

• 業務確認：権限、締め後の訂正、帳票合計の確認です。
• 連携確認：失敗時にデータを再送できるかを試します。
• 移行確認：件数、欠損、重複と切戻し手順を確かめます。

移行リハーサルは本番直前の一回で済ませず、複数回行う前提で計画します。

研修と切替日程も、あわせて確定させます。

RFPと要件整理による見積もりの前提のそろえ方

RFPは、作るものと成功の判断条件を開発会社へ伝えるための資料です。

完璧な仕様書でなくても、対象範囲、現状、希望時期、制約、評価基準をそろえれば足ります。

RFPに記載する利用者・機能・データ・連携

同じ条件で見積もってもらうため、業務量、システムの範囲、既存資産を記載します。

• 規模：部門、利用者、拠点、同時利用者、画面、帳票を示します。
• 機能・データ：CSV入出力、API、既存データ件数、移行期間を書きます。
• 既存環境：Web FormsやMVC 5、.NET Frameworkの版を伝えます。

SQL ServerなどのDBや、ソースと設計書の有無、現行サーバーの構成、希望納期も示します。

ただし、秘密情報を含むソースやデータ例は、NDA締結後に共有します。

数字で書く非機能要件

測定条件と例外を決めておくと、「快適」「安全」といった言葉の解釈のずれを減らせます。

• 性能・稼働：応答時間、同時利用者数、稼働時間を示します。
• データ・復旧：バックアップ頻度、復旧目標、保持期間を決めます。
• 管理・環境：監査ログ、権限、端末、ブラウザー、障害通知を含めます。

たとえば、ピーク時の同時利用者を100人、重要処理の応答時間を3秒以内と定義できます。まだ決まっていない数値は、要件定義で決める項目として見積もります。

納品物と発注者側の責任範囲

成果物と発注者の担当を明確にしておくと、確認待ちによる遅延を減らせます。

• 納品物：画面仕様、API・DB定義、ソース、テスト仕様と結果を定めます。
• 移行・運用資料：手順書や教育資料の範囲を決めます。
• 発注者の役割：ルール決定、マスタ整理、受入担当を用意します。

テストデータの準備も、発注者側が担当します。その範囲は、RFPと契約書に記載します。

契約形態と見積条件の事前決定

契約形態は、責任の押し付け合いを防ぐための仕組みです。そこで、決定済みの範囲と調査が必要な範囲を分け、要件定義、設計・開発、移行・教育、保守を同じ書類に混ぜないようにします。

請負契約の成果物・検収・変更手続きの定義

完成条件は業務シナリオまで定義し、検収の方法と変更の扱いを合意しておきます。

• 完成・検収：性能、権限、帳票、移行結果を条件に含めます。
• 契約条件：納期、遅延、瑕疵対応、知財、再委託の取り決めです。
• 情報管理：秘密保持と個人情報の取扱いを定めます。

仕様変更の手続きと検収期間も、契約前に確かめておきます。

準委任契約の作業範囲・体制・報告の明確化

準委任は完成物よりも、合意した作業の実施を重視します。そのため、不確実性の高い工程と合いやすい契約です。

• 対象工程：既存コード調査、要件定義、技術検証に使えます。
• 稼働条件：月の稼働時間、担当経験、追加稼働の承認方法を決めます。
• 連携体制：会議、報告、成果物、交代時の引継ぎを定めます。

アジャイル開発のように仕様を段階的に決める場合も、候補に入ります。

保守契約の障害対応・更新対応・改善対応の区分

保守費には、問い合わせ、障害復旧、OSや.NET更新、脆弱性対応、バックアップ確認、法改正対応、軽微な改善などが含まれることがあります。項目ごとに分けて、対応範囲を確認します。

• 障害対応：受付時間、一次回答、復旧目標を決めます。
• 更新対応：OSや.NET、脆弱性、バックアップの扱いです。
• 改善対応：対象外作業、月間時間、追加単価を分けます。

年間保守を初期開発費の15〜20％とする考え方もあります。ただし、クラウドやライセンスを含むかで変わるため、企画時の目安として扱います。

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

ASP.NET固有の全国一律の開発費統計はありません。下記の金額は、一般的な業務システムの公開相場と、ASP.NET案件で増減しやすい工程をもとにした企画用の推定です。

費用には、要件定義、開発、既存資産の解析から、移行、テスト、インフラ、帳票、保守までが含まれます。そのため、ASP.NET Coreのライセンス費だけで見積もりを比べないようにします。

規模別の費用レンジ（企画の目安）

企画の段階では、既存改修から基幹連携まで、機能と移行範囲を見て概算の幅をつかみます。

• 既存調査・小改修：50万〜200万円程度です。
• 小規模な社内業務：300万〜800万円程度です。
• 中規模案件：800万〜2,000万円程度です。
• 大規模・基幹連携：2,000万〜1億円以上の場合があります。

既存改修の目安は、現状調査、脆弱性・ライブラリ更新、画面追加、帳票修正を含む範囲です。小規模には、ログイン、権限、マスタ、検索、CSV、簡易帳票を想定します。

中規模は、ワークフロー、複数拠点、外部API、移行、監査ログを含む想定です。さらに、大規模ではERP・会計連携、大量データ、高可用性、段階移行が費用を押し上げます。

上記は2025年版の公開相場などによる推定で、公的なASP.NET専用の価格ではありません（出典: Harmonic Society「2025年版 業務システム開発費の相場と料金まとめ」、2025年）。実際の金額は、個別見積もりで確かめる必要があります。

工程別の比率による見積もりの抜けの確認

工程別の割合と見比べると、見積もりに含まれていない作業を見つけやすくなります。

• 要件定義：10〜15％程度です。
• 設計：15〜20％程度です。
• 開発：30〜40％程度です。
• テスト：15〜20％程度です。
• 移行：5〜10％程度です。

この比率は業務システム全般の整理ですが、ASP.NET案件で要件定義や移行を削ると、後から業務ルールの追加やデータ不整合が生じることがあります。

見積書には、工程ごとの工数、担当、成果物、前提を記載してもらいます。そのうえで、テストと移行が極端に少なくないかを確かめます。

公開事例の工数と範囲の読み分け

公開事例は、機能や工程の規模を比べる材料として使います。価格を決める根拠にはなりません。

• 分析結果通知：ASP.NET Core（C#）とSQL Serverで約2人月です。
• 宴会情報管理：ASP.NET（C#）とPostgreSQLで約6人月です。

上記はBSSの公式実績ページにある総工数です（出典: 株式会社BSS「実績」、2026年8月確認）。人月単価や、要件定義、管理費、移行、教育、保守が含まれているかは分かりません。

3〜5年のTCOによる比較

初期開発費が安くても、運用費が高ければ総額は大きくなります。そこで、3〜5年間の利用を想定し、総所有コスト（TCO）で比べます。

• 導入費：開発、移行、教育を含めます。
• 継続費：インフラ、ライセンス、年間保守を足します。
• 将来費：追加開発と契約終了時の引継ぎも考慮します。

月額のインフラやDB、帳票は、費用として見ておきます。さらに、監視やバックアップ、脆弱性診断も費用に含めます。問い合わせや法改正への対応も、見積もりに入れておきます。

予算を抑えるなら、認証・マスタ・主要業務を第1期にし、分析や周辺帳票を第2期に分けます。

ASP.NETの委託先を選ぶポイント

委託先は、C#に対応しているかだけでなく、似た業務をASP.NETでどこまで担当したかで見ます。あわせて、要件定義から保守までの責任範囲と担当者も確かめます。

ASP.NET FrameworkからCoreへの移行経験

既存案件と新規案件では必要な経験が違うため、委託先には具体的な実績を質問します。

• 既存環境：Web Forms、MVC 5、SQL Serverなどの経験です。
• 移行経験：制約を調べ、部分移行か再構築か判断した事例を聞きます。
• 新規技術：Coreの版やMVC、Web APIなどの選択力を見ます。

「対応可能」という回答に加えて、制約を調べて移行方式を判断した事例を確かめます。

帳票やWindows認証、.NET Frameworkも確認対象です。新規開発では、Razor Pages、Blazor、Entity Framework Core、認証基盤を選べるかも確かめます。

業務理解とコミュニケーション体制の確認

現場の例外を仕様に落とし込める人が、要件定義を担当するかを確かめます。

• 会議・課題管理：定例の頻度と管理方法です。
• 意思疎通：質問への回答期限や決定者を定めます。
• 代替体制：海外・地方拠点との連携や担当者不在時の対応を聞きます。

業務ルールを理解していなければ、技術者が優秀でも、使われるシステムにはなりません。

セキュリティと運用まで含めた提案力

安全を保つには、機能に加えて、設定と運用の体制が必要です。

• アプリ対策：認証・認可、HTTPS、CSRF、CORS、XSSへの対応です。
• 運用管理：ログ、秘密情報、バックアップ、パッチ担当を決めます。
• 診断・法令：脆弱性診断や保存要件への対応を確認します。

ASP.NET Coreには、認証・認可、データ保護、HTTPS、秘密情報の安全な保管、CSRF、CORS、XSSへの対策が用意されています。ただし、機能があるだけで安全が自動的に完成するわけではありません（出典: Microsoft Learn「ASP.NET Core security topics」、最終更新2026年5月）。

個人情報は安全管理措置、会計・請求データは電子帳簿保存法の保存要件も、あわせて確認します。

見積書を比較するときのポイント

金額だけでは、適切な発注先を判断できません。そのため、発注先は要件定義、移行、テストまで含めて比べます。さらに、教育、保守、ライセンス、管理費も比べる対象です。これらは別料金になっている可能性があるため、見積書で確かめておきます。

3社程度に同じRFPを渡し、工程、前提、除外項目、追加単価をそろえておくと、価格差を説明しやすくなります。

同じ条件で工程と成果物を比べる方法

同じ比較表に工程と納品物を並べて比べます。

• 開発工程：要件定義、基本・詳細設計、開発を比べます。
• テスト：単体・結合・総合テストを比べます。
• 移行・運用：移行、受入支援、教育、リリース、保守を含めます。

各工程の金額、工数、担当、納品物、期間を記載してもらいます。空欄が対象外か未確定かも、あわせて確かめます。

画面数が少なくても、承認経路、外部連携、帳票、移行が複雑であれば、費用は上がります。そのため、画面単価だけで比べないようにします。

提案説明での担当者とリスクへの回答

提案会には、実際に要件定義と開発を担当する人に参加してもらいます。そのうえで、移行、データ、障害、契約終了時の対応を質問します。

• 移行：Web FormsからCoreへ移す際の第一歩を聞きます。
• 運用：移行リハーサルの回数や障害時の連絡時間です。
• 引継ぎ：ソースや手順書を受け取る形式を決めます。

帳票ライセンスの保有者も確かめます。回答が抽象的な場合は、類似案件の成果物例や体制表を見せてもらいます。

価格より将来の変更と引継ぎを重視した評価

制度や組織、連携先、OS、.NETは、リリース後も変わるため、変更しやすさを評価します。

• 開発品質：コード、テスト自動化、設計書を確認します。
• 再現性：開発環境やCI/CD設定の引継ぎを確認します。
• 所有権：ソース、データ定義、アカウントの名義を定めます。

特定の一社しか保守できない状態を避けるには、インフラ構成や運用手順も契約で明確にしておきます。

よくある質問（FAQ）

発注では、技術の新旧、費用、既存資産、契約後の保守について質問が寄せられます。

ASP.NETのシステムは無料で作れますか？

ASP.NET Coreはオープンソースですが、システムを無料で発注できるという意味ではありません。

• 開発作業：要件定義、設計、開発、テストに費用がかかります。
• 導入・運用：移行、Azureなどのインフラ、監視、保守が必要です。
• 製品費：SQL Serverや帳票製品のライセンスです。

見積もりでは、基盤のライセンスと開発・運用費を分けて確認します。

古いWeb Formsはすぐに作り直すべきですか？

すぐに全面再構築する必要があるとは限りません。現状を診断したうえで選びます。

• 継続利用：業務が安定し、セキュリティと保守を確保できる場合は候補です。
• 再構築検討：サポート切れや仕様書不足、採用難を調べます。
• 段階移行：脆弱性対応後、API化や画面単位の移行も選べます。

OS、.NET、部品のサポート状況や、変更のしにくさも確かめます。

ASP.NET Coreはどのバージョンを選べばよいですか？

サポート期間、必要なライブラリ、開発会社の保守体制を踏まえ、更新できる版を選びます。

2026年8月時点では、.NET 10は2028年11月まで、.NET 8は2026年11月までサポートされるという情報が公開されています。ただし、最適な版はリリースや契約期間によって変わります。

バージョン番号だけで決めず、更新計画と互換性テストも見積もりに含めます。

開発後に保守会社を変更できますか？

契約時に成果物とアカウントの所有者を決めておくと、保守会社を変更しやすくなります。

• 引継ぎ資料：ソース、設計書、テスト、DB定義を納品対象にします。
• 運用情報：環境再構築の情報を残し、アカウントとライセンスは発注者が管理します。
• 移行条件：引継ぎ期間、質問単価、部品の契約の確認です。

保守会社を変える予定がなくても、事業継続や担当者の交代に備えて、引継ぎ可能な状態を作ります。

まとめ

ASP.NETの発注では、まず新規か既存改修かを分け、Web Forms・MVC 5・ASP.NET Coreのどれを使うかを確定します。

スクラッチ、パッケージ、クラウド、オンプレミス、一括請負、準委任などを、業務の不確実性と運用責任に合わせて選びます。

同じRFPを複数社に渡して比べる進め方

RFPには、利用者や負荷、機能、帳票、連携を記載します。さらに、既存ソースや移行、非機能要件、希望時期、保守条件も含めます。

まず、工程別の金額、工数、成果物、除外項目を同じ条件で比べます。そのうえで、追加単価、ライセンス、クラウド、保守も比べます。また、技術や業務理解、セキュリティも評価します。さらに、移行、運用、引継ぎも見ます。

現状調査と小さな検証から始める最初の一歩

発注前に確認しておく事項を、対象ごとに整理します。

• 既存システム：ソース、サーバー、データ、帳票、認証を調べます。
• 新規開発：業務フローと非機能要件を整理します。
• 難所の検証：外部連携や移行をPoCで確かめ、必要なら要件定義だけを先に委託します。

完成条件と運用責任を契約に明記することが、開発を成功させる近道です。

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

▼開発を相談する前に読みたい無料ホワイトペーパー
・【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を創業。