Entity Frameworkのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

Entity Frameworkのシステム開発は、業務整理から始めて、技術選定、設計・開発の順に進めると手戻りを抑えられます。テスト、移行、定着も、同じ流れのなかで順に進めます。

EFの役割や費用相場を含む全体像は、Entity Frameworkのシステム開発の完全ガイドもあわせてご覧ください。

▼全体ガイドの記事
・Entity Frameworkのシステム開発の完全ガイド

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

Entity Frameworkのシステム開発の全体像

Entity Frameworkは、C#のエンティティとリレーショナルデータベースを対応付けるORMです。EF自体は、販売管理や顧客管理のような完成したパッケージではありません。

EFを使うと、SQL Server、Azure SQL、PostgreSQLなどに対する検索・登録・更新・削除を実装しやすくなります。EFが主に担当するのは、データアクセス層です。

一方で、画面やAPI、帳票は、ASP.NET Coreなどを使って別に設計します。認証や業務ルール、外部連携についても、EFとは切り分けて考えます。

EFが担う範囲とシステム全体の構成

EFが担う範囲と業務側で設計する内容は、システム全体のどの部分に当たるかで分けて整理できます。

• システム構成：Web画面、サービス層、EFのデータアクセス層、データベース
• データ処理：サービス層で入力を検証し、DbContextへエンティティを渡してLINQで検索・保存
• 業務ルール：在庫引当、承認経路、締め処理を、利用部門と合意したうえでコードへ反映

APIやバッチも同じモデルと業務ルールを使えるため、処理の重複を減らせます。ただし、業務フローそのものは、EFを導入しても決まりません。取消可能な期間と操作ログの保存期間も、実装の前に現場と決めておく必要があります。

発注時には、要件定義、DB設計、性能試験が見積もりに含まれているかを確かめます。さらに、移行、教育、保守も含まれるかを確認します。

EF6とEF Coreを選ぶ判断基準

選ぶ基準は、既存環境との互換性と、新規開発で必要な実行基盤です。

• 既存.NET Framework：アプリケーションを維持する場合はEF6が候補
• 新規のWeb・コンテナ・Linux・クラウド：EF Coreを検討
• 既存コードの移行：API、プロバイダー、実行基盤の差を確認

EF Core 10は2025年11月にリリースされたLTSで、2028年11月10日までサポートされます。出典はMicrosoft Learn「What’s New in EF Core 10」（2025年）です。

EF Core 10には.NET 10 SDKとランタイムが必要で、旧.NET Frameworkでは動作しません。新規案件では、長期運用を見据えた候補になります。

一方で、既存案件では.NETとDBプロバイダーの組み合わせを検証します。認証ライブラリとクエリ結果も、動作を確かめておく必要があります。

Code FirstとDatabase Firstの使い分け

新規モデルを先に作るか、既存DBを維持するかで、方式を選びます。

• Code First：新規システムで業務モデルを先に設計する場合に向く
• Database First・Scaffold：既存DBのテーブルや制約を維持する場合に安全
• 共通の確認：データ所有者、キー、NULL、監査列、削除方針、インデックスを合意

Code FirstではC#のモデルと設定をソースコードで管理し、レビュー済みの変更を段階的にDBへ反映できます。

Migrationsを本番へ無検証で適用すると、列変更や大量データ変換で停止する可能性があります。適用前には生成SQLを確認し、バックアップと切り戻し方法を用意します。所要時間も見ておきます。

Entity Frameworkのシステム開発の進め方

業務とデータを整理したうえで、要件整理から技術選定、設計・開発へと進みます。全体は6段階で、テスト、稼働、定着まで続きます。各段階の完了条件を先に決めておくと、現場で使えない、移行後の数値が合わないといった事態を減らせます。

フェーズ1：要件整理で決める業務とデータの境界

要件整理では、業務の流れと数値化した要件を、現場担当者と一緒にまとめます。

誰がいつ情報を使い、何を判断するかを、業務フローに落とし込みます。販売管理では、たとえば見積、受注、出荷の状態遷移を記録します。売上、請求、入金の遷移も、同じ流れのなかで記録します。

画面一覧に頼ると漏れやすいため、例外処理や締め後の修正は、現場担当者と一日の作業を見て確かめます。

性能や運用、完了の判断に関わる条件は、業務の流れだけでは決まりません。そこで、要件として決めておく項目を次の4つの観点で整理します。

• 非機能要件：ピーク時同時利用者数、1日・1か月の登録件数、検索時間
• 運用条件：保存期間、RTO・RPO、利用者の役割、個人情報の範囲、連携頻度
• 完了条件：業務・画面・データ・権限・連携・非機能・対象外範囲の承認
• 移行と将来：移行データの件数と品質、拠点や取引先の追加

検索性能は、通常時3秒以内、月末の同時利用時も5秒以内のように数値で定めます。「速く」という表現では、完了の判断ができません。

完了条件に例外・取消・再処理の扱いを含め、現場責任者の承認を得ておきます。

フェーズ2：EF・.NET・データベースの選定

候補は、既存資産、運用体制、業務の独自性を基準に比べます。

• 新規Webシステム：ASP.NET Core、EF Core、SQL Server、Azure SQL、PostgreSQLを候補にする
• 既存資産：.NET 10移行、ライブラリ互換性、クエリ性能を確認する
• 業務要件：パッケージ、ハイブリッド、スクラッチを比較する

Azureでは、App ServiceやContainer Appsを組み合わせられます。加えて、Key VaultやApplication Insightsも使えます。

権限設計や監視、バックアップも必要です。利用料金の管理も、欠かせません。

オンプレミスや他のクラウドも、選択肢になります。DBプロバイダーの機能差と保守担当者の経験も確かめます。

EF Core 10では、.NET 10への移行可否、ライブラリ互換性、EF Core 9や8とのクエリ性能差を検証します。

既存の.NET Frameworkでは、EF6を続ける範囲とEF Coreへ移す範囲を、ロードマップにまとめます。短期の作りやすさだけで選ぶと、数年後の更新費用が膨らみます。

標準的な申請、マスタ、通知はパッケージを使います。競争力に直結する業務や既存DB連携だけをEFで作る構成は、独自開発の範囲を抑えられます。

複雑な業務ルールや高い拡張性が必要な場合は、スクラッチを検討します。その際は、採用理由、見送った案、将来の変更条件を記録に残しておきます。

フェーズ3：データモデルの設計と開発

画面の見た目より先にデータを設計し、代表的な業務を早い段階で検証しながら進めます。

• モデル設計：エンティティ、関係、制約、状態、監査項目を整理する
• 業務検証：代表的な処理を小さく実装し、画面から帳票までつなぐ
• 性能確認：SQLの問題を早期に見つけ、必要な処理だけ別手段も検討する

顧客と受注などの関係を図に起こし、1対多か多対多かを確かめます。

DbContextの責務やトランザクション境界は、設計書に明記します。同時更新や論理削除と物理削除の扱いについても、同じ設計書に書いておきます。

顧客登録から受注、在庫引当、請求までを小さく実装します。そのうえで、画面と帳票を早い段階でつなぎ、サービス層やEF、DBの動きを確かめます。

Code Firstの場合は、Migrationsをリポジトリで管理します。Database Firstでは、生成モデルと業務ロジックを分けて、再生成で手書きの変更が消えないようにします。

EFの性能は、実装者が自動生成されるSQLを確認するかどうかで大きく変わります。

Includeの多用や全列・全件の取得、ループ内のN+1は、早期に検出します。検索列のインデックス不足も、見逃さないようにします。

複雑な集計や性能を重視する処理では、LINQだけに頼らず、別の手段も取り入れます。ビューやストアドプロシージャ、検証済みSQLを、必要な範囲で併用します。Dapperも、限定的に使います。

フェーズ4：業務・SQL・性能のテスト

画面の表示だけでなく、業務、性能、セキュリティの観点から動作を確かめます。

• 業務テスト：単体・結合・受入の各段階で正常系と例外系を確認
• 性能試験：想定件数とピーク時間を本番に近いデータ量で再現
• セキュリティ：SQL、認証・認可、DB権限、暗号化、ログを点検

単体テストでは、サービスやモデルのルールを確かめます。結合テストでは、EFを含む画面からDBまでの流れと外部連携を、通しで確かめます。受入テストでは、業務担当者が実際の業務を再現します。

受注取消、在庫不足、重複送信といった例外を試します。通信断や権限のない操作も、対象に入れます。

性能では、平均値と95パーセンタイルを見ます。DB CPUやメモリの使用状況も確かめます。

ロック待ちやタイムアウトは、調べておきます。生成SQLとインデックスの利用状況も、確かめます。EF Core 10更新時は、実行計画と処理時間を前後で比べます。

パラメーター化コレクションのSQL変換などに変更があります（出典: Microsoft Learn「Breaking changes in EF Core 10」、2025年）。

Microsoftは、FromSqlやFromSqlInterpolatedのパラメーター化を安全な方法として説明しています。一方で、FromSqlRawは使い方によってSQLインジェクションの危険があるとしています。

IPAは、プレースホルダーと必要最小限のDB権限を推奨しています。コードレビューと脆弱性診断は、工程に含めます。

出典はMicrosoft Learn「SQL Queries – EF Core」とIPA「安全なウェブサイトの作り方」です（2025〜2026年確認）。

フェーズ5：移行計画と稼働

データ移行、切り替え、稼働判定は、分けて計画し、完了条件をそろえます。

• 移行準備：旧データを調べ、変換・対象期間・除外・照合方法を決める
• 切り替え：停止許容時間と更新頻度から方式を選び、復旧策を用意する
• 稼働判定：データ、権限、監視、連絡先、旧システム停止時期を確認する

旧システムの顧客コードと商品コードを調べ、重複や欠損、表記の揺れを確認します。

テスト移行は複数回行い、件数と金額を旧システムと照合します。在庫残高と未処理伝票も、照合の対象です。

移行方式は、一斉移行、段階移行、並行稼働から選びます。業務停止の許容時間とデータ更新頻度で判断します。

一斉移行なら停止時間、バックアップ、切り戻し条件を具体化します。段階移行なら、拠点や部門ごとのデータ整合性とサポート窓口を決めます。

Migrationsを適用する際は、バックアップ、適用ログ、失敗時の復旧手順をリリース手順書に含めます。

稼働判定では、移行後の件数や数値、権限別の操作を確かめます。月末締めや大量取込を安全に終えた時点を、稼働完了とします。

フェーズ6：定着と継続改善

稼働後も、教育や保守、利用状況の確認を続け、改善につなげます。

• 教育と窓口：業務シナリオで研修し、一次切り分け役を決める
• 保守：更新、脆弱性、容量、復元テスト、監視、法改正を扱う
• 定着と引き継ぎ：利用状況を測り、運用に必要な納品物を渡す

研修の題材は、受注登録や承認、月次締め、エラー時の再処理といった実際の業務シナリオです。

キーユーザーを決め、現場の問い合わせと開発会社への連絡を別の役として分けておくと、混乱を抑えられます。

保守契約では、障害対応に加えて、.NETやEF Coreの更新も確認対象にします。帳票変更への扱いも、契約で確かめます。

個人情報を扱う場合は、運用手順と契約へ落とし込みます。対象は、アクセス制御や利用状況の記録、委託先管理です。暗号化と漏えい時の対応も含みます。

出典は個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」です（2025〜2026年確認）。

ログイン人数のほか、処理時間や紙・Excelへの戻りを月次で見ます。入力エラーや問い合わせ、月末締めの時間も、あわせて追います。復旧時間も、月次の確認項目に入れます。

引き継ぐ納品物には、ソースコード、DBスキーマ、Migrationsがあります。テストコードや監視設定、障害対応手順も、引き継ぎの対象です。CI/CDやIaCも含みます。

担当会社を変えるときにも、選択肢を残しやすくなります。

Entity Frameworkのシステム開発の費用相場

EFはオープンソースのため、通常はライセンス料が費用の中心にはなりません。予算を左右するのは、業務要件や画面・API数、DB設計です。外部連携や移行も、費用に関わる要素です。

性能・セキュリティ試験、クラウド、保守も費用に関わります。EFを採用したからといって、一般的な業務システムより大幅に安くなるとは限りません。

規模別の初期費用と期間の目安

2026年の一般的な開発相場は、小規模100万〜300万円、中規模500万〜1,000万円、大規模1,000万円〜数千万円以上です。

人月単価は60万〜200万円程度とされています（出典: SIA株式会社「システム開発の費用・相場 2026年版」、2026年）。

EF Coreをデータアクセス層に採用する業務システムでは、規模によって費用と期間の目安が大きく変わります。区分ごとの目安は、4つに分けて示します。

• 単機能の社内CRUDやPoC：150万〜500万円、1〜3か月程度
• 部門向け販売・在庫・申請システム：500万〜1,500万円、3〜8か月程度
• 複数拠点や既存.NET刷新を含む全社システム：1,500万〜5,000万円、6〜15か月程度
• 大量データ等を扱う基幹系：5,000万円〜1億円超、12〜24か月以上

基幹系の対象は、大量データや複雑な連携を扱う案件です。さらに、24時間運用や高可用性、段階移行まで求められる案件が含まれます。

部門向けには、認証や権限、既存DB連携が含まれます。複数画面も含みます。全社向けには、移行や監査ログ、性能対策を含む可能性があります。

これらは、一般的な開発相場とEFを使う典型的な構成要素から整理した推定レンジで、EF専用の公的統計ではありません。

会社や契約方式、要件の確定度で変わります。そのため、予算申請では前提と除外範囲を併記します。

費用を構成する項目と保守費

初期開発と継続費用の内訳は次のとおりです。項目ごとに確認して、見積もりの前提をそろえます。

• 初期費用：要件整理、設計・環境構築、実装、テスト、移行、教育、リリース
• 仮置きの配分：要件定義10〜15%、設計等20〜25%、実装45〜50%、テスト15〜20%
• 別費用の候補：旧データのクレンジング、外部API仕様の調査、帳票製品、クラウド・DBの利用料、監視、脆弱性診断、研修、現地支援
• 保守・運用：初期開発費の年15〜25%程度が目安となる場合がある

移行や性能試験を別項目にできる案件では、作業量と納品物を見て判断します。比率だけで決めないことが大切です。

バックアップの扱いも、見積もりの前提に含めて確かめます。保守費は、月間の対応時間やSLAで変わります。更新や法改正、追加開発の範囲も、保守費に影響します。

EF Core更新では、互換性、SQL性能、Migrationsの検証も必要です。これらを無償の作業と決めつけないようにします。

Entity Frameworkのシステム開発で見積もりを取るポイント

見積もりの精度を上げるには、技術名だけでなく、業務範囲と完了条件を伝えることが大切です。同じ前提で比べられるRFPを用意します。

候補会社には、画面・帳票・API一覧やデータ項目表を示します。連携先や利用者数、ピーク件数も具体的に伝えます。希望時期と保守条件も伝えます。

要件が未確定の段階では、本開発の固定額をすぐに求めるより、調査と要件整理を小さな契約で先に進める方法もあります。

RFPと要件整理による前提の統一

各社の回答条件をそろえるには、RFPに業務の前提から引き渡し条件までを具体的に書いておきます。盛り込む内容は、4つの分野に分けて整理できます。

• 業務前提：課題、部門、役割、データ、画面・帳票・API、移行、運用時間
• 技術確認：EF Coreの版と理由、SQLレビュー、性能試験、Migrations管理
• 納品物：業務フロー図、画面・帳票一覧、ER図とデータ辞書、権限マトリクス、API仕様、非機能要件、移行設計、テスト計画、運用設計
• 引き渡し条件：ソースや設定の所有権と納品時期を契約に記載

業務課題や移行方式を伝えたうえで、技術条件は「EF Coreを使うこと」の一言で済ませないようにします。そうすれば、各社が共通条件で回答でき、単価以外の品質差も比べられます。

引き渡しの対象には、ソースコードやDBスキーマ、Migrationsが含まれます。テストコードと監視設定も対象に入れます。CI/CDとIaCも含めます。担当者が変わっても保守できる状態で納品することを、条件として定めておきます。

開発会社の技術と業務の両面での比較

技術実績と、業務理解や管理体制の両方を、具体的な回答で比べます。

• 技術力：EF・.NET・DBの経験、SQL性能、既存環境からの移行
• 業務・管理力：要件整理、工程ごとの役割、変更・リスクの報告体制
• 継続性：担当者の稼働率、再委託の範囲、障害時のSLA、ソースの保管場所、内製化支援

「C#対応」かどうかだけでなく、新規案件のEF Core・.NETの版を質問します。SQL Server、Azure SQL、PostgreSQLの経験も聞きます。

N+1や遅いクエリを見つけられるか、.NETやAccessからの移行経験があるかを聞きます。MigrationsとDB変更の承認者も確認します。設計書やテスト例があると、比べやすくなります。

利用部門との要件整理担当、PMとテックリードの参加工程、課題・変更・リスクの報告頻度も聞きます。

継続性の項目は、金額と合わせて比べます。金額だけでは見えにくい体制の差が、ここで分かれます。

安さだけで選ばないための追加費用の条件

追加費用につながる作業とリスクを洗い出し、契約前に条件を決めます。

• 見積条件：工数、単価、成果物、前提、除外事項、変更単価、納期影響
• 主なリスク：DB品質、外部仕様変更、レビュー遅れ、移行欠損、要件追加
• 契約前の対策：発注者・受注者の担当、発生条件、回避策、予備費をリスク表に記録

要件定義や移行、性能試験が別料金なら、安い見積もりでも最終費用は増えます。セキュリティや教育も、別料金の項目として見ておきます。

「一式」と書かれた項目には、人日と完了内容を質問します。短納期の請負契約や複数ベンダーでは、調整工数が増えることがあります。そのため、見積もりの前提に明記します。

Entity Frameworkのシステム開発でよくある質問（FAQ）

発注や技術選定でよく聞かれる質問に答えます。EFや既存資産に関する判断は、性能、費用、保守の観点とあわせて行います。

Entity Frameworkは無料なので開発費も安くなりますか？

EFはオープンソースのため、通常はEF自体のライセンス料が大きな負担にはなりません。EFで削減しやすいのは、データアクセス実装の一部です。そのため、システム全体の費用が自動的に安くなるわけではありません。

一方で、業務要件やDB設計、画面・APIには費用がかかります。移行や性能試験、クラウドも費用の対象です。保守の費用も、見込んでおく必要があります。

新規開発ならEF6とEF Coreのどちらを選ぶべきですか？

新規Webシステムでは、原則としてEF Coreを中心に検討します。EF Core 10はLTSですが、.NET 10が必要です。

既存の.NET Framework資産と利用ライブラリを確認します。DBプロバイダーと保守体制も見たうえで、決めます。

既存アプリの短期保守ではEF6を続け、.NETとEF Coreへの移行計画を別に作る場合もあります。

EFを使うと大量データの処理が遅くなりませんか？

EFを使うこと自体は、処理の遅さに直結しません。遅さは、生成されるSQLや取得の仕方から生じやすいため、対策は4つの面に分けて考えます。

• 問い合わせの確認：LINQから生成されるSQLと取得件数、インデックス、トラッキング、トランザクション
• 避ける取得：全件取得、N+1、過剰なInclude、不要な列の取得
• 読み込みの工夫：必要に応じたAsNoTrackingやページング、ビューやストアドプロシージャ
• 切り出しの判断：本番に近いデータ量で試験し、許容時間を満たさない処理だけをSQLやDapperへ切り出す

開発会社には何を質問すると失敗を防げますか？

EF Coreと.NETのバージョン、類似業務とDBの実績を質問します。SQL性能の検証と移行担当も、聞いておきます。セキュリティ、Migrations管理、テスト範囲も確かめます。

公開実績に加えて、ソースコードや文書の引き渡し、保守SLAも確かめます。提案担当者が要件整理から保守まで、どの程度関わるかも聞きます。

回答をRFPの評価表に並べると、価格と継続運用のしやすさを比べられます。

まとめ

成功させるには、EFを部品として扱い、業務・データ・運用を設計したうえで、データアクセス層へ組み込むことが大切です。

新規ならEF Core、既存の.NETならEF6を、互換性を基準に選びます。DB、クラウド、保守体制まで含めて検討します。

着手前に確認する5つのポイント

着手前には、業務フローと例外処理の承認を確かめます。EF・.NET・DBの選定理由と更新計画も、同じ時期に確認します。

移行や性能、セキュリティの見積もりを確かめます。数値化したテストと稼働判定、引き継ぐ納品物も、確認します。

納品物には、ソースコードやMigrationsが含まれます。DBや運用手順も、納品物に入ります。これらが曖昧だと、追加費用や手戻りが発生しやすくなります。

要件整理と小さな検証からの着手

全社機能を一度に発注する前に、代表的な業務を選びます。そのうえで、データモデルと権限を小さく検証し、検索性能と移行方法も確かめます。

要件整理の結果と検証結果をもとに、複数社から同じ条件で見積もりを取ります。その後、費用と品質を比べ、体制と引き継ぎやすさも見ます。

▼全体ガイドの記事
・Entity Frameworkのシステム開発の完全ガイド

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【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を創業。