Dynamics 365 Salesのシステム開発の完全ガイド

Dynamics 365 Salesのシステム開発では、CRM/SFAを基礎に、Power Platformによる拡張と基幹連携を段階的に組み合わせます。こうして組み立てることで、営業情報を一か所に集約できます。

各テーマの詳細は、本文の下にある関連記事でご覧いただけます。

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

Dynamics 365 Salesのシステムの概要

営業データの保存先から周辺機能と基幹連携へ広がる構成です。

Dynamics 365 Salesは、顧客データを中心に、営業活動と周辺システムをつなぐ業務基盤です。営業部門だけで使う入力ツールとは、役割の範囲が違います。

導入では、まず標準機能を組織の営業プロセスに合わせて設定します。そのうえで、足りない部分をPower PlatformやAPIで補います。

CRMとSFAによる営業情報の集約

CRMは取引先企業や担当者との関係を管理し、SFAは営業プロセスを管理します。両方の情報を同じ基盤に集めることで、部門の状況を一か所で確認できます。

情報の関連付け：取引先、担当者、リード、案件、活動、見積、受注を結び付け、案件のメール、会議、タスク、提案状況を時系列で追えます。
営業担当者：訪問前に顧客情報と活動履歴を確認できます。
管理者：案件ステージ、滞留日数、受注予定、失注理由を横断して把握できます。
経営・営業企画：売上予測とプロセス別実績を、同じデータから作成できます。

取引先から見積や受注までを一続きにしておけば、担当者が替わっても案件の経緯をたどれます。Excelで個別に管理する場合との違いは、この点にあります。

DataverseとPower Platformを含む構成

Dynamics 365 Salesは、Microsoft Dataverse上で動作し、Power Appsのモデル駆動型アプリ設計を使います（出典: Dynamics 365 Sales概要、2026年）。専用データベースを個別に構築する方式とは異なります。

設計対象：画面項目のほか、データモデル、環境、セキュリティロール、監査、ワークフローが対象です。
標準構成：Sales HubとDataverseを中心に、Power Platformを組み合わせた構成です。
基幹連携：商品マスター、在庫、請求、売上実績を、必要な範囲に限ってAPIなどで同期する形です。

たとえば、Sales Hubで顧客・案件・活動を扱い、Dataverseに保存します。そのうえで、Power Automateで通知や承認を自動化し、Power BIでKPIを分析します。Salesと基幹側でデータの分担を決めておかないと、二重入力や不整合が起きやすくなります。

Dynamics 365 Salesの主な機能と種類

機能は、基本的な営業管理からAIによる予測・提案まで段階的に用意されています。どこまでを使うかは、営業プロセスの標準化、データ品質、利用者の習熟度に応じて決めます。

顧客・案件・活動・予測の一連の管理

基本機能と分析機能を組み合わせることで、営業活動から売上予測まで把握できます。

顧客・案件：取引先・担当者の管理、リードの登録と評価、案件の作成、営業ステージの更新に対応します。
活動と案件情報：電話、メール、会議、タスクを記録し、見込み金額、受注予定日、競合、失注理由、次回アクションを管理します。
販売管理との接点：商品・価格表、見積、受注、請求への引き渡しも扱えます。
予測・分析：営業プロセス、テリトリー、目標、売上予測、ダッシュボードが対象です。Power BIで案件化率、滞留、ステージ別受注率、予実差を追えます。

公式の説明では、主要な領域として、リード獲得から営業のクローズまで、売上予測、Power BI連携、TeamsやOutlookとの統合が挙げられています（出典: Dynamics 365 Sales概要、2026年）。

Professional・Enterprise・Premiumの違いと選び方

ライセンスは、利用者数だけでなく、営業プロセスの複雑さ、予測・AIの必要性、カスタマイズの範囲をもとに選びます。

Professional：基本的な営業自動化やMicrosoft 365連携から始める場合に適します。
Enterprise：高度な営業自動化、分析、カスタマイズ、Copilotを検討する場合の候補です。
Premium：Enterpriseの機能に加えて、営業インテリジェンス、予測、推奨アクションを重視する場合の選択肢です。

2026年8月に確認できる米国公式価格では、年契約のSales Professionalは1ユーザー月額65米ドルです。また、Sales Enterpriseは105米ドル、Sales Premiumは150米ドルです（出典: Dynamics 365 Sales価格ページ、2026年）。

ただし、日本の請求額は地域、為替、税、契約形態、販売条件によって変わります。そのため、円換算の額を正式な見積もりとして扱わず、契約前に確認します。

Premiumには、月あたり1ユーザー1,000のCopilotクレジットが含まれるという表示もあります。なお、エージェントや追加利用の条件は、契約前に確認します。

標準機能・ローコード・APIの使い分け

機能を拡張する方法は、要件によって変わります。

標準・設定：標準機能や設定変更で、営業プロセスに対応します。
ローコード：Power Apps、Power Automate、Dataverseのカスタムテーブルを使う形です。
連携開発：Web APIやAzure Functionsで、商品マスターや売上実績を取り込みます。
活用例：Power PlatformやAPIで見積承認を自動化し、営業案件の条件に応じてTeamsへ通知します。

標準の要件を独自画面で作り込むと、更新、テスト、保守の負担が増えます。そのため、まずFit to Standardで業務を整理し、競争優位や法令対応に直結する部分だけを拡張します。

Salesは顧客・案件・活動の基盤、ERPや基幹は受注後の正データと位置づけ、役割を分けます。会計、在庫、製造までSalesで再構築せず、責任範囲は明確にします。

Dynamics 365 Salesのシステム開発・導入の進め方

小規模な検証を経て、移行と現場定着へ段階的に進みます。

導入は、企画、現状分析、要件定義、設計・設定、開発の順に進めます。そのあと、移行、テスト、教育、リリース、定着化へと続きます。

最初に画面作成から始めると、入力項目が増えたり、どのシステムをデータの正とするかが曖昧になったりします。そこで、小さく検証してから対象部門を広げると、品質と速度のバランスを取りやすくなります。

▶ 詳細はこちら：Dynamics 365 Salesのシステム開発の進め方/やり方/流れや方法/手法/工程/手順

企画・現状分析での目的とKPIの設定

課題の把握とKPIの設定では、何を解決し、何で成果を測るかを最初にそろえます。

課題の特定：製品を選ぶ前に、解決すべき営業上の問題を明らかにします。
関係者の視点：現場、営業企画、情報システム、経営のそれぞれの立場から、課題を見ます。
KPI：案件登録率、必須項目入力率、ステージ滞留日数、重複顧客率、予測差、会議時間を測定対象にします。
成果の確認：入力率だけを見ると形式的な登録が増える可能性があるため、意思決定の速さ、案件の抜け漏れ、予測精度も測ります。

課題の例には、案件情報のExcelへの分散、営業会議の集計に毎週半日かかること、受注見込みの根拠のばらつき、商品マスターの重複入力があります。

Fit to StandardとMVPによる対象範囲の絞り込み

Fit to StandardとMVPでは、範囲を順に決めてから検証します。

営業プロセス、顧客・案件の項目、組織・拠点・役割、Excel・CRM、基幹連携を洗い出します。
要件を「必須」「できれば必要」「今回は対象外」に分けたうえで、標準機能、設定、拡張のどれで対応するかを判定します。
現行の例外はすべて再現せず、10〜30人程度の営業部門からMVPを始めます。
取引先、担当者、リード、案件、活動履歴を構築し、営業ステージと最低限のダッシュボードも加えます。
3か月程度で入力の継続と会議での利用を検証します。複雑な全社連携や高度なAIは後回しにし、項目、権限、プロセス、教育を直してから全社展開します。

業務を見直さずに現行の例外を再現すると、導入効果が薄れます。そのため、検証結果を展開前の計画に反映します。

設計・開発でのデータと連携の責任範囲

設計と連携では、業務ルールと、システム間の分担を明確にしておきます。

営業データ：項目、選択肢、ステージ、必須条件、重複判定を定義します。組織階層、所有者、閲覧範囲、承認経路も決めます。
ステージ条件：ステージを増やす場合は、「商談化」の定義をそろえ、次の行動や移行条件も合わせておきます。
連携仕様：正データ、同期方向・頻度、キー、再送、ログ、担当部署を文書にまとめます。商品・価格・在庫は基幹側、顧客・案件・活動はSales側に置く方法もあります。
連携テスト：通信失敗、重複登録、項目欠落、タイムアウト、障害復旧の場面で動作を確かめます。

移行・テスト・教育による現場利用の定着

移行から稼働後まで、現場に定着しているかを確かめながら進めます。

データ移行：移行条件を決めたうえで、表記や重複を整え、不要データを取り除きます。
リハーサル・テスト：移行リハーサルを複数回行い、業務シナリオ、権限、監査、連携の動きを確かめます。
教育・改善：役割別マニュアル、入力ルール、問い合わせ窓口、相談会を用意します。

リハーサルでは、性能、障害復旧、スマートフォン利用も確認します。稼働後は、30日、60日、90日にKPIを確かめ、使いにくい項目や未利用機能を改めます。

さらに、項目の対応関係、保持期間、移行後の責任者も決めておきます。

顧客名の全角・半角や法人格の有無、担当者の異動、商品コードの変更を放置すると、検索や集計の精度が下がります。そのため、本番前に件数を照合し、サンプルも確認します。

ポイント

導入の進め方に迷ったら、まず対象部門を絞り、標準機能に業務を寄せる範囲と、データや連携の責任を先に決められているかで判断します。

Dynamics 365 Salesの費用相場とコストの内訳

規模が上がるにつれて想定される費用帯も広がります。

費用は、ライセンス、導入支援、要件定義、設定・追加開発、移行の順に分けて見積もります。外部連携、テスト、教育、保守運用も、見積もりの項目に加えます。

月額ライセンスだけを見ると、データ整理、連携、定着化の費用を見落としやすくなります。規模別の金額は一般的な推定で、正式な金額はユーザー数と要件を明確にして確認します。

▶ 詳細はこちら：Dynamics 365 Salesのシステム開発の見積相場や費用/コスト/値段について

ユーザー数とエディションによるライセンス費用

ライセンス費用は、利用者の役割、必要な機能、操作範囲をもとに見積もります。

利用者の範囲：営業担当者だけか、管理者、営業企画、参照専用の利用者も含めるかを確かめます。
権利の確認：参照専用でも、レコード作成やレポート閲覧には別の権利が必要になる場合があります。最新のライセンスガイドで見極めます。
換算額：米国価格を円に換算した月額の参考値で比べます。
人数別試算：利用人数とエディションごとに、年額を計算します。
参考値の条件：換算額は、為替を固定して計算した額です。

ライセンス構成は利用者の役割に合わせて組み、全員へ同じ上位プランを割り当てないようにします。

1米ドル150円で換算すると、Sales Professionalは1ユーザー月約9,750円です。同じ換算で、Sales Enterpriseは月約15,750円、Sales Premiumは約22,500円です。

この換算で計算すると、10人のProfessionalは年約117万円です。さらに、50人のEnterpriseは約945万円、50人のPremiumは約1,350万円です。

ただし、この試算は税、国内価格、割引、契約条件、追加ライセンスを含みません（出典: Dynamics 365 Sales価格ページ、2026年）。正式な金額は、契約時点の国内価格で確認します。

導入・開発費用の幅（300万〜5,000万円超）

導入の費用と期間は、利用者数に加えて、連携や移行の範囲によっても変わります。

小規模：10〜30ユーザーで、標準機能中心、Outlook・Teams基本連携、初期移行を含みます。費用は300万〜800万円程度、期間は2〜4か月程度です。
PoC・スターターパック：対象を絞れば100万〜300万円台になる可能性があります。全社展開や複雑な移行は含みません。
中規模：30〜150ユーザーで、費用は800万〜2,500万円程度、期間は4〜9か月程度です。
大規模：150ユーザー超、複数拠点を含む場合は、2,000万〜5,000万円超、6〜12か月以上となることがあります。

中規模では、部門の営業プロセス、基幹・商品連携、権限、Power BI、教育を含みます。大規模の目安には、旧CRM移行、ERP・API連携、複雑な承認・監査も含まれます。

全社のCRM刷新や複数システムの同時再構築では、さらに大きな予算を想定します。

移行・連携・保守・容量を含むランニングコスト

初期費用のほかに、利用状況に応じて運用費用が発生します。

追加利用料：移行、外部API、追加ライセンス、AIクレジットに伴って発生する場合があります。
容量・教育：Dataverseのデータ量、Azureの利用、追加研修にかかる費用も考慮します。
保守運用：初期開発費の年15〜25％程度を仮置きする場合があります。範囲は、問い合わせ、月次改善、更新検証、連携監視で変わります。
容量超過：レコードだけでなく、ファイルとログも確かめ、追加費用と監視担当を決めます。

保守運用の範囲には、権限変更、データ整備、教育も含まれます。

なお、追加ライセンスにはPower PlatformやPower BIも含まれます。エージェントを使うには、Azureサブスクリプションが必要です（出典: Dynamics 365 Sales価格ページ、2026年）。Copilotクレジットには、複数の購入方式があります。

ポイント

費用は、ライセンス代だけでなく、データ整理、連携、教育、保守まで含めて比べます。正式な金額は、ユーザー数と要件をそろえたうえで個別に見積もって確認します。

Dynamics 365 Salesの開発会社・ベンダーの選び方

開発会社は、製品知識に加えて、営業業務、移行、既存システムとの連携、セキュリティ、稼働後の運用を見ておく必要があります。知名度や認定よりも、自社に近い規模、業界、環境での経験を、提案内容と体制から見極めます。

業界理解と営業プロセスの設計力

営業案件の流れは、商材、販売チャネル、契約期間、拠点、受注承認の有無によって変わります。そのため、「標準機能で対応」と聞いたときには、使うテーブル、ステージ、権限、画面、業務変更の要否を確かめます。

現行業務をそのまま再現する提案は、不要なカスタマイズを増やす可能性があります。そこで、ヒアリングには営業担当者だけでなく、管理者、営業企画、情報システム、データ管理者も参加させます。

商談化の条件、失注理由、見込み金額、予測の締め日、担当変更時の所有権、他部門への引き継ぎを、具体的に説明できるかを確かめます。ここで答えられるかどうかは、業務の定着まで考えた提案かを判断する材料になります。

提案書で確かめる移行・権限・AIの責任範囲

提案書では、移行、連携、権限、AIそれぞれの作業範囲と責任者を確かめます。

データ移行：件数、項目、品質基準を確かめます。加えて、重複除去、表記統一、旧データ保管、リハーサル、移行後照合も見ます。
システム連携：設計、開発、テストと障害時の一次切り分けを、誰が担うかを明記してもらいます。
権限管理：閲覧範囲、アクセス権の変更、監査、出力制御、環境分離の条件を確かめます。
Copilot：データ移動の同意、DLP、利用地域、対象者、監査履歴を設計に含めます。

Dataverseは、ロールに基づいて閲覧と操作の範囲を制御します（出典: Dataverseのロールに基づくセキュリティ、2026年）。そのうえで、部門、拠点、役職ごとに閲覧範囲を決めます。

権限は、異動や退職のタイミングで変わるため、その際の変更方法を提案書で確かめておきます。監査ログ、エクスポート制御、環境分離についても、同じ確認の中で条件を見ます。

見積の透明性と稼働後の支援体制

相見積もりをとる場合は、同じRFPを複数の候補に渡して依頼します。

比較条件：ユーザー数、部門・拠点、移行件数、連携対象をそろえます。ダッシュボード、教育対象、希望時期、保守範囲も条件に含めます。
見積内訳：ライセンス、要件定義、環境構築、設定、追加開発を分けてもらいます。移行、連携、テスト、教育、保守も別々に示し、前提と対象外を記載してもらいます。
支援体制：経験年数、設計・開発・テストの分担、受付時間を確かめます。加えて、障害対応、更新検証、月次改善、内製化支援も見ます。
注意する提案：要件定義やテストが極端に少ない場合、一式金額で範囲が見えない場合、稼働後教育の別料金を説明しない場合には注意します。

▶ 詳細はこちら：Dynamics 365 Salesのシステム開発でおすすめの開発会社/ベンダー6選と選び方

▶ 詳細はこちら：Dynamics 365 Salesのシステム開発の発注/外注/依頼/委託方法について

ポイント

開発会社は、製品知識だけでなく、自社に近い規模や業界での経験と、移行・権限・稼働後の支援体制を提案書で示せるかどうかで比べます。

導入で失敗しやすいポイントと成功を測るKPI

導入の成否は、担当者が情報を入力し、管理者が共通の定義で案件を見て、経営がデータで判断できる状態が続いているかで確かめます。稼働日に画面が動くことは、その状態に入る前の段階です。

Excelの再現、過剰なカスタマイズ、連携の後回しという失敗

導入時には、失敗につながる進め方を避けます。

Excelの再現：Salesに移す列を選び、標準プロセスに沿って項目を整えます。
例外の再現：部署ごとの例外をすべてカスタマイズで対応すると、次に多い失敗になります。
連携の先送り：本番直前の基幹連携では、商品・顧客コードの不一致が見つかることがあり、稼働日に影響する可能性があります。
Copilotの準備不足：権限とDLPを設計したうえで有効化します。

現場で使われない列や重複項目まで移すと、入力負荷が上がり、重要情報が埋もれます。そのため、標準プロセスに業務を寄せる範囲を決め、不足する部分だけを拡張します。

公式の手順では、地域間の移動への同意と、必要なコネクタの許可が前提になっています（出典: Dynamics 365 Sales Copilotの有効化と設定、2026年）。あわせて、利用者制御と監査履歴も確かめます。

30日・60日・90日の利用率と業務成果

稼働後の30日、60日、90日に、利用状況と業務成果を確かめます。

30日：ログイン率、案件登録率、必須項目入力率、エラーや問い合わせを見ます。入力しにくい理由は、項目数、業務定義、権限、画面に分けて改善します。
60日：営業会議でのダッシュボード利用、案件の滞留、次回アクションの漏れを見ます。
90日：商談化率、受注率、ステージ別滞留日数、予測差、重複率、会議準備時間を、導入前と比べます。

改善が進まない場合は、ツールの問題と決めつける前に、ステージ定義、入力ルール、管理者の活用、評価制度との整合性を見直します。そのうえで、運用責任者が定例会で改善要望の優先順位を決めます。

ポイント

導入の成否は、稼働後30日・60日・90日の利用率と業務成果を導入前と比べて判断します。担当者が入力を続け、管理者が共通の定義で案件を見ている状態かどうかが、その目安になります。

Dynamics 365 Salesのシステムに関するよくある質問

導入前によく寄せられる質問に答えます。価格や機能は契約、地域、更新時期によって変わるため、最終的な判断では最新の公式資料と個別の見積もりを確認します。

Dynamics 365 SalesはCRMですか？SFAですか？

Dynamics 365 SalesはCRMとSFAの両方の役割を持つ営業支援アプリです。顧客との関係や履歴に加えて、リード、案件、活動、売上予測も同じデータ基盤で扱えます。

何人くらいの会社から導入できますか？

何人くらいから導入できるかは、人数だけでは決まりません。そのうえで、10〜30人程度の営業部門からMVPを始める方法は現実的です。

Microsoft 365を利用し、営業情報がExcelに分散している、または案件管理の共通ルールを作りたい場合は、小規模でも効果を検証できます。

Copilotはすぐに使えますか？社外秘情報は安全ですか？

有効化の前に、契約プラン、利用地域、管理者設定、データ移動への同意、DLP、ユーザー権限を確かめます。

社外秘の情報を扱う場合は、参照させるデータ、アクセス権、監査ログ、生成結果の確認者を決めておきます。そのうえで、個人情報や機密情報のルールとも整合させます。

Excelや既存CRMのデータを移行できますか？

移行は可能ですが、列を写すだけでは不十分です。顧客、担当者、案件の対応関係を整理します。さらに、重複、表記ゆれ、不要データ、保持期間、担当者コードも整えます。

テスト移行を行い、件数を照合します。過去データを参照用に別に保管する方法も含めて、検索性と費用のバランスを決めます。

パッケージ導入とスクラッチ開発はどちらがよいですか？

営業の基本機能を標準化する場合は、パッケージを中心に導入し、不足する部分だけを拡張します。

独自の業務が多い場合でも、標準機能で残す領域と、別アプリやAPIで補う領域を分けると、更新や運用の負担を抑えやすくなります。

まとめ

Dynamics 365 Salesは、顧客・案件・活動を集約するCRM/SFAです。Dataverse、Power Platform、Microsoft 365、基幹システムをつなぐ営業基盤として使います。

標準機能を優先し、業務上重要な差分だけを拡張します。あわせて、移行、権限、連携、Copilot、定着化も初期計画に含めます。

導入判断で確認するポイント

導入前には、対象者、営業プロセス、課題、KPIを確かめます。Salesと基幹の責任範囲、移行データ、連携も確認します。そのうえで、権限・監査、AI利用ルール、費用、運用担当を見ます。

標準機能と拡張の境界、正とするデータ、稼働90日後の評価基準を決めておくと、提案と成果を比べやすくなります。

最初の一歩は営業データと業務定義の棚卸し

全社導入を決める前に、Excel・CRM・基幹から、顧客、担当者、案件の項目と件数を洗い出します。

基幹側に置く方法もあるため、同じ棚卸しで、それぞれのデータがどこに保存されているかも確かめます。

商品
売上
活動履歴

営業プロセスを整理し、10〜30人程度の部門でMVPを検証します。共通のRFPを使い、費用、範囲、体制、移行、連携を比べます。教育や保守も含めて、自社に合う方法を判断します。

▼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を創業。