.NET MAUIのシステム開発は、6つのフェーズで進みます。最初の要件整理と技術・サービスの選定で業務と構成を決めたあと、設計・開発から定着までを順に進めます。各段階で実機を使って確かめながら進めると、現場への定着につながります。
▼全体ガイドの記事
・.NET MAUIのシステム開発の完全ガイド
AI駆動開発の基本や工程ごとの活用方法、費用・期間への影響については、無料ホワイトペーパー「【2026年最新版】AI駆動開発の完全ガイドブック」で詳しく解説しています。
.NET MAUIのシステム開発の全体像
.NET MAUIは、複数のプラットフォーム向けに業務アプリを構築するフレームワークで、CRMや営業支援の完成済みパッケージではありません。
基本構成では、モバイル画面を.NET MAUIで作り、ASP.NET CoreなどのAPIやデータベース、既存CRMやERPと組み合わせます。
共通化できる部分と個別対応が必要な部分
顧客検索、案件一覧、日報入力、認証、API呼び出しは、共通コードにしやすい領域です。一方で、端末の機能はOSごとに権限や挙動が異なるため、個別の実装が残ります。
- 端末機能：カメラ、GPS、バーコード、プッシュ通知が対象です。
- OS依存の処理：ファイル保存やバックグラウンド処理など、OSごとの個別の確認が必要な処理
すべてのOSで完全に同じ動作になるとは限りません。そのため、共通化率も事前に断定しないほうが安全です。
Microsoft Learnの企業向けアーキテクチャは、UIと業務ロジックを分離するMVVMを示しています。さらに、依存性注入、サービス層、APIクライアントも組み合わせる構成です（出典: Microsoft Learn「Enterprise Application Patterns Using .NET MAUI」）。
この分離を先に決めておくと、営業画面を変えたときに、データ連携や認証のコードへ影響が及びにくくなります。
システムの範囲と連携先の確定
システムの範囲は、画面の作り方を決めた段階ではまだ定まりません。そこで、管理対象と連携先を具体的に決めます。
連携先には、Salesforce、HubSpot、Dynamics 365、販売管理、基幹システムなどがあります。連携先ごとに、既存CRMと新しい業務APIのどちらをデータの正とするかを決めます。
- 管理範囲：顧客、会社、担当者、リード、案件、活動履歴のうち、扱う対象
- 連携仕様：API項目、更新権限、レート制限、エラー時の再送方法
- オフライン：電波の弱い場所で入力するかの判断、保存データの範囲と暗号化
- 同期と利用基準：同期の順序、更新競合の解決方法、訪問先で30秒以内の登録などの利用基準
.NET MAUIのシステム開発の進め方と6フェーズ
開発は6つのフェーズを順に進めます。最初の要件整理と選定で業務と構成を決め、そのあとは設計・開発から定着までへ移ります。各フェーズの終了条件を先に決めておくと、後半で大きな作り直しが起きにくくなります。
営業・CRM用途では、利用者が画面を使うタイミングを要件に含めることが成功の分かれ目になります。
フェーズ1：要件整理で業務と利用場面を具体化
要件整理では、誰が、いつ、どの端末で何を入力し、入力後に誰が使うかを整理します。たとえば営業日報なら、訪問前の顧客確認から訪問後の活動履歴登録までの流れを描きます。
訪問中の写真や位置情報の記録、次回アクションの登録も、一連の業務に含めます。さらに、画面一覧に加えて業務フローと権限、必須項目を洗い出します。
承認の流れも、通知や帳票、検索条件とあわせて、この段階で書き出します。そのうえで、入力されない項目や重複顧客を特定します。確認するのは次の3項目です。
- 利用環境：利用者と人数、対象OSと端末、オンライン・オフラインの前提
- データと管理：連携先、データの正、個人情報、監査ログ
- 運用体制：ストア配信の有無、導入後の問い合わせ窓口
マスタデータの整備を発注者と開発会社のどちらが担うかは、要件定義書に明記します。また、既存Excelの内容を移すだけで要件を終えず、業務の流れ全体を書きます。
フェーズ2：PoCによる技術とサービスの選定
選定では、業務に合う構成を比べます。標準業務が中心ならパッケージが有利ですが、独自の要件が多い場合は、4つの構成から選びます。
- 標準CRM：CRMに備わるモバイル機能の利用
- SaaSと現場アプリ：SaaSに.NET MAUIアプリを組み合わせる形
- 既存.NET基盤：既存バックエンドとMAUIクライアントの組み合わせ
- フルスクラッチ：独自要件に合わせて一から作るシステム
現場独自の入力や複雑な承認が競争力に直結するなら、専用アプリを検討しやすくなります。また、オフラインやカメラ、バーコードの利用も、競争力に直結する場合は専用アプリの候補になります。
PoCでは、全機能を一度に作らず、代表画面を1〜3本に絞ります。そのうえで、ログインや顧客検索、写真添付を実機で確認し、API接続と復旧後の同期も確かめます。
評価するのは、画面表示時間や入力操作数、同期エラーです。iOSとAndroidの差、権限の説明、開発会社の固有コードへの理解も見ておきます。
PoCの終了条件を満たさないまま本開発へ進まないことが、安全な進め方です。
フェーズ3：設計・開発でのAPIと端末固有処理の分離
MAUIクライアント、認証、業務APIの3つを、それぞれ別々に設計します。データベースや外部連携にも同じ考え方を当てはめ、通知やログ監視も切り分けます。
UIはView、画面状態や表示処理はViewModelに分けます。
- 業務処理：業務ルールとデータアクセスのサービス層への分離
- オフライン：端末データの有効期限と暗号化、同期キュー、重複登録、削除、競合時の表示
- 開発体制：画面担当に加え、データ移行、API、インフラ、実機QA、業務部門の責任者が定例に参加する形
- 実機デモ：2週間単位などで行い、押しにくいボタンや検索結果、通信状態の問題を見つけて修正する
トークンなど少量の秘密情報には、.NET MAUIのSecureStorageを候補にできます。ただし、大量のテキスト保存には向かないとMicrosoft Learnは説明しています（出典: Microsoft Learn「Secure storage – .NET MAUI」）。
顧客一覧や案件履歴は、SecureStorageには置かず、適切な暗号化領域に保存します。
端末側だけで権限を守ると、API直呼びで情報が漏えいするため、API側でも認可します。
フェーズ4：テストでのOS・端末・通信の差の洗い出し
単体テストやAPI結合テストに加えて、OS、端末、通信条件を組み合わせた検証が必要です。
- 端末条件：iOS・Android・Windowsの対象バージョン、画面サイズ、メモリやカメラ性能
- 通信条件：低速回線、通信断、復旧後の同期
- 障害条件：強制終了、端末の時刻ずれ、別担当者による同じ顧客の更新
営業現場で写真を10枚添付した場合や、通信が途中で切れた場合も試します。そのうえで、実際の失敗シナリオに沿って動作を確かめます。
ストア公開時は、審査、署名、証明書を確認します。プライバシー表示やロールバックも、テスト計画の段階で扱います。
Google Playでは、Android 15を対象とする新規アプリや更新に、2025年11月1日から16KBページサイズ対応が求められています（出典: Google Android Developers「Support 16 KB page sizes」）。
ネイティブライブラリや外部SDKがある場合は、判断をMAUI側に限らず、その依存部分も含めて行います。ビルドしたアプリは、実機で確かめます。
フェーズ5：稼働時の段階リリースと切り戻しの準備
全社一斉の切り替えより、1部署や数名の営業担当者によるパイロットのほうが安全です。初週と初月には、次の指標を確認します。
- 利用状況：顧客検索の成功率、日報入力完了率、案件更新率
- 運用状況：同期エラー件数、問い合わせ件数
既存Excelや旧アプリをいつ止めるか、二重入力をどの期間まで認めるか、障害時に誰が判断するかも、事前に決めておきます。
稼働判定では、機能だけでなくデータ移行件数や権限テスト、バックアップ復旧も確認します。監査ログや通知、紛失端末のアカウント失効も、判定の対象に含めます。
納品物として、設計書やテスト結果、ソースコードを受け取ります。CI/CD設定や環境変数の管理方法、移行仕様書、操作マニュアルも含めます。
特に、納品物が曖昧だと、将来の保守会社の変更や内製化が難しくなります。
フェーズ6：定着での利用率と改善サイクルの向上
リリース後は、現場が使わない理由を確認します。操作の難しさや入力項目、通信環境を中心に調べ、業務ルールや管理者のフォローも原因の候補に入れます。
利用開始後の1か月は、短い操作説明や現場同行を行い、問い合わせを分類します。改善版は小刻みにリリースします。そのため、Excelへ戻る兆候も早く見つけられます。
定着のKPIは、ログイン人数だけでなく、活動登録や案件更新などの業務指標で設定します。
- 活動と案件：訪問後24時間以内の活動登録率、案件ステージ更新率
- 入力と検索：必須項目の未入力率、検索から登録完了までの時間
- 同期：失敗率
AIによるリードスコアや予測分析を加える場合も、まずは顧客名の重複や住所の表記揺れを整理します。元データが整わないままでは、営業判断の信頼性は上がりにくいです。
.NET MAUIのシステム開発費用の相場と内訳
画面やロジックを.NET MAUIで共通化できても、費用が自動的に半額になるとは限りません。APIや管理画面、外部連携は、画面の共通化とは別に必要です。
さらに、データ移行や実機テストが必要になります。ストア対応や保守設計も、見積もりに含めます。
ここで示す金額は、調査ノートの営業・CRM相場と、一般的な業務モバイル開発の工数をもとにした編集上の推定です。特定の会社の定価や確定見積ではありません。
規模別の初期開発費の目安：300万円から5,000万円以上
費用は画面数や連携範囲で変わるため、規模ごとの推定レンジで考えます。
- 小規模PoC：300万〜800万円程度。10〜20画面で、ログイン、日報、写真、簡易API、iOS・Android対応を含みます。
- 中規模：800万〜2,000万円程度。顧客・案件・活動履歴、権限、通知、オフライン同期、管理画面、CRM連携が対象です。
期間の目安は、小規模PoCで2〜4か月程度、中規模で4〜8か月程度です。
複数拠点や複数OS、ERP・SFA・MA連携を含む大規模案件は、2,000万〜5,000万円以上です。厳格な監査ログやデータ移行、BI、全社展開も、大規模案件に含まれる要素です。期間は8〜18か月程度が推定レンジです。
SaaSの標準機能を使い、初期設定と少数の連携だけを行う場合は、初期設定費50万〜300万円程度に月額ライセンスが加わる形もあります。ただし、要件を減らしたからといって、必ずこの範囲に収まるとは限りません。
工程・連携・運用の3方向から見る費用の内訳
予算配分のたたき台は、工程ごとの割合で考えます。なお、比率は画面数や既存APIの状態で変わります。
- 要件定義：10〜15%。
- 基本設計：15〜20%。
- 詳細設計：10〜15%。
- 開発：30〜40%。
- 結合・総合テスト：15〜20%。
移行・教育は5〜10%程度です。この比率を固定の価格として扱わず、見積書の工程と成果物を照合します。
クラウドや監視、通知の費用は、追加の費目になります。地図や電子署名の外部サービス、ストア登録、端末購入も、追加費目として扱います。UI部品や脆弱性診断、データクレンジングの費用も確かめます。教育や保守も、見積もりの確認項目です。
業務UI部品の例として、メシウスのComponentOne 2024J v2のEnterprise開発ライセンスが公表されています。初回22万円、更新11万円です（出典: メシウス株式会社の製品資料、1人・1年・税込）。これはアプリ開発費ではなく、追加ライセンス費の一例です。
リリース後の保守と更新費用
保守費用は、障害対応に加えて、OSや開発基盤の更新確認にも使われます。更新確認の対象には、iOS・Android・Windowsのほか、XcodeやAndroid SDKが含まれます。.NET MAUIやNuGetパッケージも、対象に入ります。
- 費用目安：調査ノートでは、スクラッチ開発の保守・OS対応・脆弱性修正を初期開発費の年10〜20%程度としています。
- 契約範囲：SLA、対応時間、対象端末、改修時間を含むかで費用が変わります。
年額は一つの数字で断定せず、保守契約の範囲ごとに確認します。
2026年8月時点で、Microsoftの公式ポリシーでは.NET MAUI 10は2025年11月11日にリリース済みです。サポート終了日は2027年5月11日です（出典: Microsoft「.NET MAUI support policy」、2026年7月23日更新）。
.NET本体と.NET MAUIのサポート期間は同じとは限りません。そのため、採用時にアップグレード計画と予算を契約に含めておきます。
.NET MAUIの見積もりを取る際のポイント
金額だけで比べると、安く見えた提案が後から高くなることがあります。そのため、OS固有の処理やAPI、データ移行まで含めて比べます。実機検証やストア公開、運用も、比較の対象に入れます。
発注前には、「何を作るか」と「何を作らないか」を明確にしておきます。
RFPに記載する画面・データ・端末・非機能要件
見積もり前には、機能要件と利用環境をまとめます。オフライン条件や非機能要件も、同じ資料に書きます。
- 機能要件：画面、入力、検索、通知、帳票、外部連携、データ移行の範囲
- 利用環境：利用者ロール、端末、OS、同時利用者数、通信環境
- オフライン：許容時間、同期の優先順位、競合時の最終決定者の指定
機能要件が同じでも、端末を3種類で検証するか20種類で検証するかによって、工数は変わります。
ログインにMicrosoft Entra IDやOAuth 2.0を使うか、MFAを必須にするかも決めておきます。端末紛失時のトークン失効や監査ログの保管年数、障害通知までの時間も、あらかじめ定めます。
個人情報を扱う場合は、アクセス権限や暗号化、バックアップの扱いを確認します。委託先や海外クラウド、脆弱性修正については、どこまでを誰が受け持つかも決めます。
個人情報保護委員会の安全管理措置ガイドラインやOWASP MASVSを参照し、その内容を受入テストに反映します。
複数社の見積もりの比較（前提と納品範囲の統一）
2〜3社には、同じRFPと画面一覧を渡します。対象OSや連携条件も、すべての会社で共通にします。比較表では、工程と費用の範囲をそろえます。
- 開発範囲：要件定義、UI、MAUI、API、管理画面、データ移行
- リリース範囲：テスト、ストア、教育、保守
- 契約上の範囲：含む、含まない、別途の区分
工数に加えて、プロジェクト責任者と実機QAの担当者を確認します。データ移行の担当や問い合わせ窓口も、見積もりの確認事項に入れます。
会社には、MAUI 10への更新とXamarin資産の調査について質問します。OS固有の処理やオフライン同期、納品形式も確かめます。ストア審査やOS更新の対応時間も、あわせて聞いておきます。
公開実績だけで判断せず、構成、リスク、代替案を具体的に説明できる会社を選びます。
契約前に確認する追加費用のリスク
追加費用につながる要因は、契約前に洗い出しておきます。そのうえで、前提や変更時の扱いを明確にします。
- 仕様やデータ：既存APIの仕様不足、顧客マスタの重複
- 追加作業：端末追加、オフライン要件の後付け、OS更新
- 公開と運用：ストア審査の差し戻し、外部SDKライセンス、診断、現場教育
前提条件や除外範囲は、契約か見積条件に書いておきます。変更管理や追加単価、承認者も、同じ書面に残します。「必要になったら相談」という書き方で済ませず、前提と追加費用の扱いを具体的に書きます。
納品後は、どこまでを誰が受け持つかを決めておきます。アプリの問題とAPIやクラウドの問題を、同じ保守範囲にしないことが大切です。外部サービスや端末、利用者操作の問題も、担当を分けておきます。
重大障害の一次受付と復旧目標、報告期限を定めておくと、稼働後の判断が早まります。データ復旧やMAUI・SDKの更新時期も、決めておきます。
.NET MAUIのシステム開発でよくある質問
進め方は、既存システムや端末、現場の通信環境によって変わります。発注前によくある疑問に、ここで答えます。
.NET MAUIならiOSとAndroidの開発費は必ず半額になりますか？
必ず半額になるとは限りません。画面や業務ロジックは、共通化できる可能性があります。
一方で、APIや認証、データ移行は共通化しても費用が残ります。端末固有機能や実機テスト、ストア対応も費用になり、運用費用も加わります。PoCで共通化範囲と固有実装を確かめ、OS別の工数を見積書に分けてもらいます。
.NET MAUIでオフラインの営業アプリを作れますか？
作れますが、端末に保存するデータと同期ルールの設計が必要です。たとえば、通信が切れている間の日報はキューに保存し、復旧後に送信します。
複数人による顧客更新の競合や削除も、定義が必要です。失敗時の再送や期限切れデータの扱いも、決めておきます。
顧客情報を端末に持つ場合は、暗号化や端末ロック、リモート失効を含むセキュリティ要件を設定します。ログの扱いも、要件に含めます。
Xamarinで作った既存アプリを.NET MAUIへ移行できますか？
移行できる可能性はありますが、事前調査が必要です。調べる対象は、プロジェクト設定やNuGet、外部コントロールで、プラットフォーム固有コードも含みます。
証明書やストア設定も調べます。ただし、画面や業務ロジックを、そのまま移せるとは限りません。
まずは、ビルドの可否と依存関係を調べ、代表画面で小規模な検証を行います。移行後のMAUIバージョンとサポート期間も、計画に含めます。
既存CRMと.NET MAUIのアプリを連携する場合に注意することは何ですか？
連携先のデータ項目と更新権限は先に決め、そのうえでAPI呼び出し回数やレート制限、エラー時の再送を定めます。データの正も、あわせて決めます。
顧客名や担当者名の重複を整理しなければ、検索結果が不正確になります。そこで、CRMの標準モバイル機能で足りる範囲と、MAUIで作る範囲を分けます。また、連携本数と移行件数を見積もりに反映します。
.NET MAUIのシステム開発の小さな検証と現場への定着
採用の可否は、フレームワーク名だけで決めません。現場の画面や既存データ、端末、更新体制を一つの計画にまとめてから判断します。
6フェーズの進め方による判断漏れの防止
要件整理から定着までを一つの工程として扱い、各フェーズの終了条件と担当者を決めます。PoCの実機評価やデータ移行を先に計画へ置き、OS更新と利用率KPIも、早い段階で計画に入れます。
最初の相談で整理する現場・端末・連携先
相談の前には、利用者、対象OS、端末台数を整理しておきます。代表画面や既存CRM、基幹システムもあわせてまとめ、オフラインの要否や個人情報の扱い、希望時期を確認します。
- 未確定の項目を明示したうえで、調査やPoCを含む提案を受ける
- 要件整理で、現場の利用場面とデータの正を決める
- PoCで実機を確かめ、APIと端末処理を分けた設計
- 低速回線、同期エラー、ストア要件を含むテスト
- 段階リリース後のKPI確認と、現場への定着
費用は小規模PoCで300万〜800万円程度、中規模CRMモバイルシステムで800万〜2,000万円程度です。大規模な営業・MA基盤は、2,000万〜5,000万円以上という推定レンジを出発点にできます。
ここで示した数字は、調査ノートと一般的な開発工数を組み合わせた目安です。複数社に依頼する際は、画面や連携、移行、端末、セキュリティ、保守の前提をそろえ、納品物と、どこまでを誰が受け持つかも比べます。
営業日報や顧客検索など、利用頻度が高く効果を測りやすい業務を1つ選びます。
利用者や端末、連携先を整理してPoCの範囲を決めると、自社との適合性を判断しやすくなります。必須画面やオフライン、セキュリティ条件も、そのなかに含めます。
▼全体ガイドの記事
・.NET MAUIのシステム開発の完全ガイド
▼開発を相談する前に読みたい無料ホワイトペーパー
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。