Dynamics 365 Salesの導入は、6つのフェーズで進めます。要件整理と選定を経て設計・開発に入り、テスト、稼働、定着化と続きます。標準機能を軸に設計し、稼働後90日間の改善を通じて、営業データを業務改善につなげます。
▼全体ガイドの記事
・Dynamics 365 Salesのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
Dynamics 365 Salesのシステム開発の全体像
Dynamics 365 Salesは、取引先企業、担当者、リード、営業案件、活動履歴などをDataverseに集約するCRM・SFAです。リード獲得から受注までの営業プロセスを管理します。
Microsoft Learnでは、Microsoft Dataverse上で動作し、Power Appsのモデル駆動型アプリ設計を使う製品と説明されています。また、データモデル、権限、Power Platform、Microsoft 365や基幹システムとの連携も設計対象です。
一元管理する情報の範囲
取引先企業と担当者の情報を起点に、リードの獲得経路と評価、営業案件、活動履歴を一つの流れで管理します。営業案件には金額・確度・予定日があり、見積・受注への引き渡しまで扱います。
営業担当者は案件の状況を入力し、営業管理者はパイプラインや売上予測を確認します。営業企画は部門別のKPIを分析できます。さらに、案件表をExcelで個別に管理するのとは違い、ステージの滞留日数や失注理由を共通の定義で確認できる点に価値があります。
標準機能と追加開発の境界
Dynamics 365 Salesは営業活動のフロント基盤として使い、商品マスター、在庫、会計、請求などの正データは既存ERPや基幹システムに残しておきます。
営業案件と受注情報をSales側で作り直すと、同じ情報を二重に管理することになり、連携も複雑になります。そのため、標準テーブルと標準プロセスを優先し、不足する分だけを拡張します。
- 通知・承認：Power Automateで自動化する部分。
- 入力・分析：Power Apps、Power BIでの画面と集計。
- 個別連携：Web APIやAzure Functionsで補う部分。
標準機能を中心に、連携や拡張を疎結合の形で補っておくと、将来のアップデートや担当者の交代にも対応しやすくなります。
2026年時点では、Copilotや営業エージェントを使い、リード調査、案件要約、次のアクション提案を行う方向が強まっています。
Microsoftの2026 release wave 1は、2026年4月から9月に提供予定の機能を対象にしています。Copilot、AI、エージェント、売上予測、データ品質向上を投資領域として示しています（出典：Microsoft Learn「Dynamics 365 Sales 2026 release wave 1」、2026年）。
特にAIは後付けせず、入力項目、権限、顧客情報の利用範囲を、初期設計の段階で開発会社と確認しておきます。
Dynamics 365 Salesのシステム開発の進め方
開発は要件整理から定着化までを一続きの業務改善として進めます。現場のユーザーに早い段階で画面を試してもらい、移行データとKPIが使えるかを確かめます。
期間の目安は、小規模で2〜4か月、中規模で4〜9か月、大規模で6〜12か月以上です。ただし、既存CRMのデータ品質と連携数によって変わります。
1. 要件整理：目的・KPI・対象範囲
Dynamics 365 Salesの導入を目的にするより先に、解決したい業務課題を言葉にします。たとえば、案件状況が担当者の頭の中にある、受注見込みの集計に毎週半日かかる、といった課題が挙がります。
既存CRMとExcelへの二重入力も、課題の例になります。稼働後に測る指標は、案件入力率、ステージ別滞留日数、受注確度と実績の差などから、3〜5個に絞ります。
営業会議の集計時間や重複顧客の割合も、指標の候補になります。指標を選ぶ前に、まず対象ユーザーと営業プロセスの範囲をそろえます。要件整理では、業務・システム・データの3つの観点から要件を洗い出します。
- 業務要件：営業ステージ、必須項目、承認ルール、見積・受注との境界。
- システム要件：連携対象、保持期間、権限、モバイル利用、監査要件。
- データ確認：項目名、コード体系、件数、重複、欠損、更新頻度。
「案件金額」「受注予定日」「確度」の定義が部門ごとに違う場合は、画面を作る前に業務定義を統一しておきます。違ったままだと、後で作り直す手戻りが生じやすくなります。
2. 選定：ライセンスと導入パートナーの比較
利用者数に加えて、必要な機能と運用体制を比べます。米国の年間契約価格では、Sales Professionalは1ユーザー月額65米ドルです。同条件でSales Enterpriseは105米ドル、Sales Premiumは150米ドルです（出典：Microsoft公式「Dynamics 365 Sales pricing」、2026年8月確認）。
日本の実際の請求額は、為替や税、地域によって変わります。契約形態や販売パートナー、割引によっても変わるため、見積の時点で確認しておきます。
プランを選ぶときは、必要な機能と追加費用の可能性を照らし合わせます。
- Professional：基本営業支援、Microsoft 365連携、レポートを重視する場合。
- Enterprise：高度なカスタマイズ、売上予測、営業プロセス拡張を重視する場合。
- Premium：Sales Enterpriseの機能に加え、営業インテリジェンスや予測モデルを使いたい場合。
Power Automate、Power Apps、Power BI、Copilot Studioは、別費用になる可能性があります。加えて、LinkedIn Sales Navigator、Dataverse容量、Azureも、別に費用がかかることがあります。
機能名だけでなく、必要なライセンスの組み合わせを一覧にして比べます。パートナーには、標準機能を優先する提案か、カスタム開発を前提とする提案かを尋ねます。
データ移行と連携テストの担当者、稼働後の問い合わせ窓口も確認します。Microsoftのパートナー制度や受賞歴は、判断材料の一つとして扱います。
自社に近い業界での実績や、ユーザー規模に合った体制を説明できるかを確認します。あわせて、旧CRM移行、ERP連携の進め方、Copilotの権限設計も確かめます。
3. 設計・開発：標準機能を軸にした構成
設計では、業務フローとデータモデルを先に決めます。続いて、画面と権限、連携方式、エラー時の処理を固めます。標準テーブルを中心に据え、追加する項目やカスタムテーブルは必要最小限にとどめます。
対象となる標準テーブルは、取引先と担当者、リードに、営業案件や活動などを加えたものです。商品や価格を基幹システムで管理する場合、Salesでは参照や選択に必要な情報を連携します。
商品や価格の正データをどちらに置くかは、設計書に明記しておきます。実装方法は、標準機能で足りるかを起点に、要件に応じて選びます。
- 設定：標準機能で対応する部分。
- ローコード：Power Platformで拡張する部分。
- 個別開発：不足する処理を、APIやAzureで実装する部分。
たとえば、単純な通知や承認はPower Automate、部門専用の入力画面はPower Appsで対応します。経営ダッシュボードには、Power BIを使います。
開発会社には、各要件を「標準」「設定」「ローコード」「個別開発」「対象外」のいずれかに分けた一覧を出してもらいます。
4. テスト：データ・権限・連携の業務シナリオ検証
画面が開くかを見るだけでなく、営業担当者がリードを登録し、案件化して活動を記録するまでの流れを通して確かめます。さらに、見積を依頼し、受注情報を基幹システムへ渡して、管理者が予測を確認する一連のシナリオも検証します。
テストは、単体テスト、連携テスト、移行リハーサル、ユーザー受入テストに分けて行い、誰が合否を判断するかも先に決めておきます。営業の一連の業務が滞りなく進むかは、画面の動きとデータの流れの両面から確かめます。
- 入力と表示：必須入力、エラーメッセージ、重複判定、スマートフォン表示。
- 連携と権限：日付・金額・通貨、二重送信、再実行、閲覧制御。
- 運用確認：監査ログ、レポート集計値、移行データの件数・欠損・関連付け。
移行元と移行後で、件数や主要項目を照合します。差分があれば、本番移行の前にデータをクレンジングします。
5. 稼働：段階展開と切り戻し条件
全社一斉に展開するより、1部門または10〜30人程度のパイロットから始めるほうが安全です。入力率や案件ステージの滞留、営業会議でのレポート利用を見るほか、問い合わせ件数も確認します。
確認結果に応じて、業務ルールや画面を調整します。問題が起きたときは、旧システムへ戻すか、入力を止めて復旧するかを決め、判断者とともにカットオーバー計画に記載します。本番移行の前には、準備がそろっているかを項目ごとに確認します。
- 利用環境：利用者アカウント、ライセンス、セキュリティロール。
- 運用体制：連携用アカウント、バックアップ、問い合わせ窓口。
- 利用者支援：操作マニュアルと周知。
Dataverseはロールベースで、データとアプリへのアクセスを制御します。なお、Microsoft 365管理者でも、Dataverseのデータ操作ロールが自動で付くとは限りません（出典：Microsoft Learn「Dataverseのロールに基づくセキュリティロール」、2026年）。そのため、管理者、営業責任者、一般営業、外部協力者などのロールは、実データに近い条件で検証します。
6. 定着化：稼働後90日の使い方とKPI改善
操作研修は、稼働後も継続して支える前提で計画します。稼働初週は問い合わせを集中して受け、30日後に入力項目と画面を見直します。
60日後はレポートと承認ルール、90日後はKPIと追加開発の優先順位を確認します。入力の負担が大きい項目は減らしつつ、案件金額や予定日のように判断に必要な項目は、理由と利用場面を利用者に説明します。
90日後は、定着状況と業務成果を指標で測ります。
- 入力状況：必須項目入力率、活動履歴登録率、重複顧客率。
- 案件状況：ステージ滞留日数、予測と実績の差。
- 運用状況：営業会議の集計時間、問い合わせ解決時間。
入力率だけを見ると、形だけの登録が増えるおそれがあります。そのため、営業会議での意思決定や受注率、案件の見通しも合わせて評価します。
また、運用担当者が項目、ビュー、簡単なフローを自社で変えられるように、管理者への引き継ぎと変更申請のルールを整えます。
Dynamics 365 Salesのシステム開発にかかる費用相場
費用は、ライセンス、導入支援、追加開発の3つに分けて考えます。さらに、データ移行と外部連携、教育、保守の費用も見ておきます。なお、Dynamics 365 Salesに限定した一律の公開相場は多くありません。
この費用の目安は、リサーチノートの業務システム人月単価と規模別相場、一般的な工程から算出した推定です。ここで示す導入費の目安には、ライセンス費、税、データクレンジングの追加作業、外部システム改修費は含みません。
規模別の導入・開発費用の目安
規模別の費用と期間は、対象ユーザー数、連携、移行範囲によって変わります。小規模導入は10〜30ユーザーを対象に、標準機能を中心として、Outlook・Teams連携と初期データ移行を想定します。
- 小規模：300万〜800万円程度、期間は2〜4か月程度。
- 中規模：800万〜2,500万円程度、期間は4〜9か月程度。
- 大規模：2,000万〜5,000万円超が目安。
小規模でも、対象を絞ったPoCやスターターパックは、100万〜300万円台になることがあります。ただし、本番運用や全社教育まで含む価格とは限りません。
中規模は30〜150ユーザーを対象とし、複数部門の営業プロセス、基幹の商品マスター連携、Power BI、細かな権限設計を含む想定です。
大規模は150ユーザーを超える規模で、旧CRMの移行や国内外の拠点を含みます。さらに、ERPや複数API、複雑な承認・監査、定着化支援の対応も入ります。全社CRMの刷新や複数システムの同時再構築では、1億円規模になることもあります。
ライセンス費用とランニングコスト
ライセンスの円換算は為替と契約条件で変わるため、参考値として読んでください。1米ドル=150円と仮定すると、Professionalは1ユーザー月額約9,750円です。
同じ仮定では、Enterpriseは約15,750円、Premiumは約22,500円です。10人がProfessionalを年間で利用する場合は、約117万円になります。
50人の場合は、Enterpriseなら約945万円、Premiumなら約1,350万円の試算になります。いずれも、実際の請求額ではありません。
年間費用を見積もるときは、ライセンス以外の運用項目も含めて確認します。
- サービス費：更新料、追加Copilot Credits、Dataverse容量、Azure、Power PlatformやPower BI、外部サービス。
- 運用費：監視、問い合わせ対応、定期的な改善。
- 保守費：初期開発費の年15〜25％程度が一般的な業務システムの目安。
Microsoft公式価格ページでは、Sales Premiumに1ユーザー月1,000のCopilot Creditsが含まれています。一方で、エージェント利用にはクレジットやAzureサブスクリプションの確認が必要です（出典：Microsoft公式「Dynamics 365 Sales pricing」、2026年8月確認）。
見積では導入費だけでなく、1年目と2年目以降の総保有コストを並べて見ます。保守の範囲は会社ごとに異なるため、含まれる内容を確かめておきます。
保守の中身としては、問い合わせ時間や月次のデータ品質確認、アップデート影響調査、追加改修枠、障害対応時間を見ます。保守の率だけでなく、月の作業時間と体制も比べます。
Dynamics 365 Salesの見積もりを取る際のポイント
見積の精度は、依頼前に現状と対象範囲をどこまで整理できるかで決まります。「導入したい」という依頼からは、標準設定、CRM移行、ERP連携、Copilotのどれを含むのか読み取れません。
候補会社には同じRFPを渡し、前提条件と除外事項をそろえて比べます。
RFPに含めるべき情報
RFPには、目的とKPI、対象部門とユーザー数、現行の営業フロー、導入対象外の業務を書きます。加えて、必要なライセンス候補、移行元と件数、連携先の基幹システムも入れます。
認証方式と権限区分、希望スケジュールを示します。あわせて、教育対象と保守の期待範囲も記載します。
移行データは、顧客や担当者、リード、案件、活動の件数で示します。
さらに、重複や欠損、保持期間、関連付けの有無も伝えます。要件の優先度を分けておくと、提案の違いが見えてきます。
- Must：初回稼働に必須の案件管理と権限。
- Should：次回改善でもよい分析機能や自動化。
- Could：将来検討するAIや高度な予測。
Mustだけの場合、Shouldを加えた場合、全要件を含む場合の3パターンで見積もると、予算と効果の関係を判断しやすくなります。
複数社の見積の同条件比較
比較表では、費目と作業範囲を分けて並べます。「導入一式」とだけ書かれた見積では、移行や教育が別途になる可能性があります。
- 費目：ライセンス、要件整理、環境、設定・カスタマイズ、連携。
- 導入作業：移行、テスト、教育、稼働支援。
- 運用：保守。
各項目では、作業内容や成果物、担当者、工数を確認します。そのうえで、前提と除外事項、追加料金の条件も確かめます。
価格以外では、営業現場の参加体制や移行リハーサルの回数も比べます。
テスト仕様書を用意するか、障害時にどこまでを誰が受け持つか、アップデート対応や内製化支援の範囲も確かめます。担当者には、対象機能、ユーザー規模、連携先、移行元、稼働後の支援期間を尋ねます。
追加費用と納期遅延のリスク
追加費用は、データの重複・欠損が想定より多い場合に生じることがあります。基幹システム側の改修や、異なる営業プロセスの統合が必要になると、費用が増えることもあります。
さらに、権限や監査要件が後から増えると、費用に影響します。契約前に決めきれない要素は、調査フェーズを設けて切り分けられます。
調査後に本開発へ進む条件と、進まない場合の費用や成果物を、発注側と開発会社で合意しておきます。AI機能を使う場合は、利用条件と確認手順も決めておきます。
- データと権限：対象データ、参照文書、利用者の権限。
- 利用と監査：学習・保持の扱い、プロンプト・出力の監査。
- 誤回答への対応：確認手順と報告方法。
Copilotの有効化を成果とするより、使う業務、出力の確認者、誤りの報告方法まで運用設計に含めます。
よくある質問（FAQ）
費用や期間は対象範囲によって変わるため、ここに挙げる数字は要件整理の目安として見てください。
Dynamics 365 Salesの導入には何か月かかりますか？
標準機能を中心にした場合の期間の目安は、小規模で2〜4か月、中規模で4〜9か月、大規模で6〜12か月以上です。ただし、データ移行の難易度や部門数によって変わります。
基幹システムとの連携や、ユーザー受入テスト、教育の範囲も期間に影響します。正式な納期は、要件整理と移行調査の後に決めます。
Excelや既存CRMのデータを移行できますか？
移行はできます。その際は、重複の排除やコードの統一、必須項目の補完、保持期間の整理を行ったうえで取り込みます。
顧客、担当者、案件、活動の関連付けと、過去データの移行範囲を決めます。テスト移行と件数照合も行います。
過去の履歴は、日常利用するデータと監査上必要なデータに分けて扱うと、費用と定着のバランスを取りやすくなります。
カスタマイズしすぎると何が問題になりますか？
独自画面や個別処理が増えると、アップデートの影響調査、障害対応、担当交代時の理解、追加ライセンスの確認が難しくなります。
まず、標準機能で業務を変えられないかを検討し、競争優位に直結する要件だけを拡張します。そのうえで、Power PlatformやAPIで責任範囲を分け、設計書とテストを残します。
Copilotは導入時から使うべきですか？
全機能を初日から使う必要はありません。まず、データ品質、権限、参照範囲、利用目的を整え、会議準備や案件要約など確認しやすい業務から試します。
試したあとは、効果と誤りを評価します。2026年の公式価格情報では、プランによってCopilot機能やCreditsの扱いが異なります。そのため、利用人数や利用量、Azureや追加クレジットの条件も見積もります。
まとめ
進め方と費用の要点
Dynamics 365 Salesの開発は、6つのフェーズで進みます。要件整理と選定を経て設計・開発に入り、テスト、稼働、定着化と続きます。営業KPIと正データを先に決め、標準機能を軸に、移行・連携・権限・教育の計画も立てます。
標準中心の場合、小規模導入は300万〜800万円程度、中規模は800万〜2,500万円程度、大規模は2,000万〜5,000万円超が推定の目安です。ライセンス、開発、移行、教育、保守を分けて見積もります。
最初に整理する情報
現行のExcel、CRM、基幹システムを一覧にして、対象ユーザー、営業プロセス、KPI、移行データ、連携先を整理してください。
その情報をもとに、標準構成、段階導入、将来拡張の3段階で計画を比べると、過剰なカスタマイズや予算のぶれを抑えやすくなります。
▼全体ガイドの記事
・Dynamics 365 Salesのシステム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。