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

Dynamics 365 Salesのシステムは、顧客情報・営業案件・活動履歴をDataverseに集約し、営業プロセスの標準化と売上予測を支えるクラウド型CRM/SFAです。

ただし、ライセンスを契約して画面を用意するだけでは、営業現場で使われるシステムにはなりません。Excelや既存CRMからのデータ移行、基幹システムとの連携、権限設計、Power Platformによる拡張、Copilotの利用ルール、稼働後の定着までを一つの業務システムとして設計することが重要です。本記事では、Dynamics 365 Salesの全体像、機能、種類、導入・開発の進め方、費用相場、開発会社やサービスの選び方、失敗しやすい点、FAQまでをまとめて解説します。

▼関連記事一覧
・Dynamics 365 Salesのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・Dynamics 365 Salesのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・Dynamics 365 Salesのシステム開発の見積相場や費用/コスト/値段について
・Dynamics 365 Salesのシステム開発の発注/外注/依頼/委託方法について

Dynamics 365 Salesのシステムとは何ですか？

結論として、Dynamics 365 Salesは営業部門だけの入力ツールではなく、顧客データを中心に営業活動と周辺システムをつなぐ業務基盤です。製品の標準機能を使いながら、組織の営業プロセスに合わせて設定し、不足する部分をPower PlatformやAPIで補います。

CRMは取引先企業や担当者との関係を管理し、SFAはリード、商談、営業活動、受注見込みなどの営業プロセスを管理する仕組みです。Dynamics 365 Salesでは、取引先企業、取引先担当者、リード、営業案件、活動、見積、受注などを関連付けて管理できます。たとえば、ある営業案件に紐づくメール、会議、タスク、提案状況を時系列で確認できるため、担当者が変わっても経緯を追いやすくなります。

営業担当者にとっては、訪問前に顧客情報と過去の活動を確認でき、管理者にとっては案件ステージ、滞留日数、受注予定、失注理由を横断的に把握できます。経営層が知りたい売上予測と、営業企画が必要とするプロセス別の実績を同じデータから作れることが、Excelを個別管理する場合との大きな違いです。

Dynamics 365 Salesは、専用のデータベースを個別に構築して運用する製品ではありません。公式ドキュメントでは、Microsoft Dataverse上で動作し、Power Appsのモデル駆動型アプリ設計を使う製品と説明されています（出典: Dynamics 365 Sales概要、2026年）。そのため、画面の項目追加だけでなく、データモデル、環境、セキュリティロール、監査、ワークフローまで含めて設計する必要があります。

基本構成は、営業担当者や営業管理者がSales Hubを利用し、顧客・案件・活動をDataverseに保存し、Power Automateで通知や承認を自動化し、Power BIでKPIを分析する流れです。商品マスター、在庫、請求、売上実績などを持つERPや基幹システムとは、APIや連携基盤を通して必要な情報だけを同期します。Sales側に何を持ち、基幹側に何を残すかを決めないまま開発を始めると、二重入力とデータ不整合が発生しやすくなります。

Dynamics 365 Salesの主な機能と種類を整理します

Dynamics 365 Salesには、基本的な営業管理からAIを使った予測・提案まで段階的な機能があります。最初からすべてを有効化するのではなく、営業プロセスの標準化、データ品質、利用者の習熟度に合わせて導入範囲を決めることが大切です。

基本機能は、取引先企業と担当者の管理、リードの登録・評価、営業案件の作成、営業ステージの更新、電話・メール・会議・タスクなどの活動記録です。案件ごとに見込み金額、受注予定日、競合、失注理由、次回アクションを管理すれば、営業会議を担当者の感覚だけに依存しにくくなります。商品・価格表、見積、受注、請求への引き渡しまで扱えるため、販売管理との境界も定義しやすくなります。

さらに、営業プロセス、テリトリー、目標、売上予測、ダッシュボード、Power BIによる分析を組み合わせると、個人の活動量だけでなく、案件化率、案件の滞留、ステージ別の受注率、予実差を追跡できます。公式の機能説明でも、リード獲得から営業のクローズまでのプロセス、売上予測、Power BI連携、TeamsやOutlookとの統合が主要な利用領域として整理されています（出典: Dynamics 365 Sales概要、2026年）。

ライセンスは、利用者数だけでなく、営業プロセスの複雑さ、予測・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クレジットが含まれる表示もありますが、エージェントや追加利用の条件は契約前に確認が必要です。

拡張方法は、標準機能、設定変更、Power AppsやPower Automateによるローコード拡張、Dataverseのカスタムテーブル、Web APIやAzure Functionsを使う連携開発に分けて考えます。標準の営業プロセスで解決できる要件を独自画面に作り直すと、アップデート対応、テスト、保守の負担が増えます。まずFit to Standardで標準機能に合わせられる業務を整理し、競争優位や法令対応に直結する要件だけを拡張対象にする方針が安全です。

一方で、基幹システムの商品マスターや売上実績をSalesに取り込む、見積承認を自動化する、営業案件の条件に応じてTeamsへ通知する、といった要件はPower PlatformやAPIと相性が良いです。Salesだけで会計・在庫・製造まで再構築するのではなく、Salesは顧客・案件・活動のフロント基盤、ERPや基幹システムは受注後の正データというように、システムごとの責任範囲を決めます。

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

導入は、企画、現状分析、要件定義、設計・設定、開発、移行、テスト、教育、リリース、定着化という順で進めます。順番を飛ばして画面作成から始めると、入力項目が増えすぎたり、データの正となるシステムが曖昧になったりします。小さく検証してから対象部門を広げる進め方が、品質とスピードのバランスを取りやすい方法です。

最初に、何を導入するかではなく、営業上のどの問題を解決するかを明確にします。たとえば「案件情報が担当者のExcelに分散している」「営業会議の集計に毎週半日かかる」「受注見込みの根拠が人によって違う」「商品マスターを何度も入力している」といった課題を、現場・営業企画・情報システム・経営の視点で整理します。

そのうえで、案件登録率、必須項目の入力率、ステージごとの滞留日数、重複顧客の割合、受注予測と実績の差、営業会議にかかる時間などをKPIにします。入力率だけを目標にすると、形式的な登録が増える可能性があります。最終的に意思決定が速くなったか、案件の抜け漏れが減ったか、予測の精度が改善したかまで測れる指標を用意します。

次に、現行の営業プロセス、顧客・案件の項目、組織・拠点・役割、既存のExcelやCRM、基幹システムとの連携を棚卸しします。要件は「必須」「できれば必要」「今回は対象外」に分け、標準機能で実現できるか、設定で対応できるか、拡張が必要かを一つずつ判定します。ここで業務を見直さず、現行の例外をすべて再現しようとすると、導入効果が薄れます。

最初のMVPでは、対象を10〜30人程度の営業部門に限定し、取引先、担当者、リード、営業案件、活動履歴、営業ステージ、最低限のダッシュボードを構築します。3か月程度で検証する場合は、複雑な全社連携や高度なAIを後回しにし、日々の入力が続くか、営業会議でデータが使えるかを優先します。検証結果をもとに項目、権限、プロセス、教育内容を修正してから全社展開へ進みます。

設計では、データ項目、選択肢、営業ステージ、必須条件、重複判定、組織階層、所有者、閲覧範囲、承認経路を決めます。たとえば「商談化」の定義が部署によって違うと、案件化率を比較できません。ステージを増やす場合は、営業担当者が次に取る行動と、ステージを進める条件までセットで定義します。

連携設計では、システムごとにデータの正を決め、同期方向、頻度、キー項目、エラー時の再送、ログの保管、担当部署を文書化します。商品・価格・在庫は基幹側、顧客・案件・活動はSales側というように分ける方法が一般的です。API連携は本番稼働前だけでなく、通信失敗、重複登録、項目欠落、タイムアウト、障害復旧まで含めてテストします。

データ移行では、既存データをそのまま取り込むのではなく、項目の対応付け、表記ゆれの統一、重複統合、不要データの除外、保持期間、移行後の責任者を決めます。顧客名の全角・半角、法人格の有無、担当者の異動、商品コードの変更などを放置すると、検索や集計の精度が下がります。本番移行前に件数照合とサンプル確認を行い、移行リハーサルを複数回実施します。

テストは、画面単位の動作確認だけでなく、業務シナリオ、権限、監査、連携、性能、障害復旧、スマートフォン利用まで確認します。教育は一度の操作説明会で終わらせず、役割別のマニュアル、入力ルール、問い合わせ窓口、利用開始後の相談会を用意します。稼働後30日、60日、90日でKPIを確認し、入力しにくい項目や使われない機能を改善する運用が必要です。

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

費用は、ライセンス、導入支援、要件定義、設定・追加開発、データ移行、外部連携、テスト、教育、保守運用に分けて見積もります。月額ライセンスだけを見て判断すると、既存データの整理や連携、定着化に必要な費用を見落とします。以下は一般的な導入規模をもとにした推定であり、正式な金額はユーザー数と要件を明確にしたうえで確認します。

ライセンス費用は、利用者が営業担当者だけなのか、営業管理者、営業企画、参照専用の利用者も含むのかで変わります。全員に同じ上位ライセンスを割り当てるのではなく、必要な機能と操作範囲を整理して構成します。ただし、参照専用にしたつもりでも、レコード作成やレポート閲覧で別の権利が必要になる場合があるため、契約条件は最新のライセンスガイドで確認します。

参考として、米国公式価格を1米ドル150円で機械的に換算すると、Professionalは1ユーザー月約9,750円、Enterpriseは約15,750円、Premiumは約22,500円です。10人がProfessionalを利用する場合は年約117万円、50人がEnterpriseを利用する場合は年約945万円、50人がPremiumを利用する場合は年約1,350万円という試算になります。これは為替を固定した参考値であり、税、国内価格、割引、契約条件、追加ライセンスは含みません（出典: Dynamics 365 Sales価格ページ、2026年）。正式な料金は、契約時点の国内価格と条件で確認します。

小規模導入は、10〜30ユーザー、標準機能中心、OutlookやTeamsとの基本連携、初期データ移行を対象にすると、300万〜800万円程度が一つの目安です。期間は2〜4か月程度です。対象業務を限定したPoCやスターターパックであれば100万〜300万円台になる可能性もありますが、全社展開や複雑な移行を含む金額ではありません。

中規模では、30〜150ユーザー、複数部門の営業プロセス、基幹・商品マスター連携、権限設計、Power BI、教育まで含めて800万〜2,500万円程度、4〜9か月程度を見込みます。大規模では、150ユーザー超、複数拠点、旧CRM移行、ERPやAPI連携、複雑な承認・監査を含めて2,000万〜5,000万円超、6〜12か月以上になる場合があります。全社CRM刷新や複数システムの同時再構築では、さらに大きな予算を想定します。

初期費用のほかに、データ移行の追加作業、外部APIの利用、Power PlatformやPower BIの追加ライセンス、Copilotやエージェントのクレジット、Dataverseのデータ・ファイル・ログ容量、Azureサブスクリプション、教育の追加開催などが発生することがあります。公式の価格ページでも、エージェント利用にはAzureサブスクリプションが必要とされ、Copilotクレジットの購入方式が複数示されています（出典: Dynamics 365 Sales価格ページ、2026年）。必要な追加費用を契約前の見積書で確認します。

保守運用は、初期開発費の年15〜25％程度を仮置きするケースがありますが、対象範囲で大きく変わります。問い合わせ対応だけか、月次の改善、リリース検証、連携監視、権限変更、データクレンジング、ユーザー教育まで含むかを分けてください。Dataverseの容量も、レコードだけでなくファイルやログの利用状況を確認し、容量超過時の追加費用と監視担当を決めておくと安心です。

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

開発会社や導入サービスを選ぶときは、製品知識だけでなく、営業業務、データ移行、既存システム連携、セキュリティ、稼働後の運用まで確認します。知名度や認定だけで決めるのではなく、自社の規模・業界・利用者・既存環境に近い経験があるかを、提案内容と体制で見極めます。

営業案件の進み方は、商材、販売チャネル、契約期間、拠点、受注承認の有無によって変わります。提案時に「標準機能で対応できます」と言われたら、どの標準テーブル、ステージ、権限、画面を使うのか、業務側に変更を求めるのかを確認します。逆に、現行業務を無条件に再現する提案は、不要なカスタマイズを増やす可能性があります。

ヒアリングでは、営業担当者だけでなく、営業管理者、営業企画、情報システム、データ管理者も参加させます。商談化の条件、失注理由、見込み金額の決め方、売上予測の締め日、担当者変更時の所有権、他部門への引き継ぎを具体的に説明できる提案者は、システム画面だけでなく業務の定着まで考えている可能性が高いです。

データ移行では、何件を、どの項目から、どの品質基準で移すかを確認します。「データ移行一式」と書かれているだけでは、重複除去、表記統一、旧データの保管、移行リハーサル、移行後の照合が含まれるか分かりません。連携についても、設計・開発・テスト・障害時の一次切り分けを誰が担当するかを明記してもらいます。

Dataverseはロールベースのセキュリティモデルを使い、アクセスレベルと権限の組み合わせでユーザーが閲覧・操作できる範囲を制御します（出典: Dataverseのロールに基づくセキュリティ、2026年）。提案時には、営業部門・拠点・役職ごとの閲覧範囲、退職・異動時の権限変更、監査ログ、エクスポート制御、開発・検証・本番環境の分離を確認します。Copilotを使う場合は、データ移動の同意、DLPポリシー、利用可能な地域、対象ユーザー、監査履歴を含めて設計する必要があります。

相見積もりを取る際は、同じRFPを複数の候補に渡します。対象ユーザー数、部門・拠点、移行元データの件数、連携対象、必要なダッシュボード、教育対象、リリース希望時期、保守範囲をそろえないと、価格だけで比較できません。見積は、ライセンス、要件定義、環境構築、設定、追加開発、移行、連携、テスト、教育、保守に分け、前提条件と対象外を記載してもらいます。

また、担当者の経験年数、設計・開発・テストの役割分担、問い合わせの受付時間、障害時の対応、アップデート検証、月次改善、内製化支援の有無も重要です。要件定義とテストが極端に少ない提案、一式金額ばかりで作業範囲が見えない提案、稼働後の教育が別料金なのに説明がない提案には注意します。

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

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

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

導入の成否は、稼働日に画面が動いたかだけでは判断できません。営業担当者が必要な情報を入力し、管理者が同じ定義で案件を見て、経営がデータに基づいて判断できる状態になったかを、稼働後も継続して確かめます。

よくある失敗は、Excelの列をそのままSalesの項目にすることです。現場で使われていない列や重複した項目まで移すと、入力負荷が上がり、重要な情報が埋もれます。次に多いのが、部署ごとの例外をすべてカスタマイズで再現することです。標準プロセスへ業務を寄せられる部分を先に決め、不足する部分だけを拡張します。

また、基幹連携を本番直前まで後回しにすると、商品コードや顧客コードの不一致が発覚したときに稼働日を守れません。Copilotを権限やDLPの設計なしに有効化することも避けます。Copilotの公式設定手順では、地域間のデータ移動への同意、DLPで必要なコネクタが許可されていること、利用者の制御、監査履歴などが前提として示されています（出典: Dynamics 365 Sales Copilotの有効化と設定、2026年）。

稼働後30日は、ログイン率、案件登録率、必須項目の入力率、エラーや問い合わせの内容を確認します。入力できない理由が項目の多さなのか、営業プロセスの定義不足なのか、権限や画面の問題なのかを切り分け、短いサイクルで改善します。60日では、営業会議でダッシュボードが使われているか、案件の滞留や次回アクションの抜けが減ったかを見ます。

90日では、商談化率、受注率、案件ステージ別の滞留日数、予測と実績の差、重複データ率、営業会議の準備時間などを導入前と比較します。数字が改善しない場合は、ツールの問題と決めつけず、ステージ定義、入力ルール、マネージャーの活用方法、評価制度との整合性を見直します。導入後に運用責任者が定例会を持ち、改善要望の優先順位を決めることが定着につながります。

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

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

Dynamics 365 Salesは、CRMとSFAの両方の役割を持つ営業支援アプリケーションです。顧客・担当者との関係や履歴を管理するCRM機能と、リード・案件・活動・売上予測を管理するSFA機能を同じデータ基盤で利用できます。

人数だけで導入可否は決まりませんが、10〜30人程度の営業部門を対象にMVPから始める方法は現実的です。Microsoft 365を利用している、営業情報がExcelに分散している、案件管理の共通ルールを作りたい、といった課題があれば、規模が小さくても導入効果を検証できます。

Copilotは、契約プラン、利用地域、管理者設定、データ移動への同意、DLPポリシー、ユーザー権限などを確認してから有効化します。社外秘情報を扱う場合は、どのデータを参照させるか、アクセス権をどう適用するか、監査ログをどこまで残すか、生成結果を誰が確認するかを決め、個人情報や機密情報の取り扱いルールと整合させてください。

移行できますが、列をコピーするだけでは不十分です。移行前に顧客・担当者・案件の対応関係、重複、表記ゆれ、不要データ、保持期間、担当者コードを整理し、テスト移行と件数照合を行います。移行対象を絞り、過去データは参照用に別保管する方法も含めて、検索性と費用のバランスを決めます。

営業の基本機能を標準化したい場合は、パッケージの標準機能を軸に導入し、不足部分だけを拡張する方法が向いています。独自業務が多い場合でも、最初からすべてをスクラッチ開発するのではなく、標準機能で残す領域と、別アプリやAPIで補う領域を分ける方が、アップデートや運用の負担を抑えやすくなります。

まとめ

Dynamics 365 Salesのシステムは、顧客・営業案件・活動を集約するCRM/SFAであり、Dataverse、Power Platform、Microsoft 365、基幹システムをつなぐ営業業務の基盤です。導入のポイントは、標準機能を優先しながら、業務上の重要な差分だけを拡張し、データ移行、権限、連携、Copilot、定着化を初期計画に含めることです。

導入前には、対象ユーザーと営業プロセス、解決したい課題、目標KPI、Salesと基幹システムの責任範囲、移行対象データ、連携方式、権限・監査、AI利用ルール、初期費用とライセンス費用、稼働後の運用担当を確認します。特に「何を標準機能で行い、何を拡張するか」「どのデータが正か」「稼働90日後に何を改善とみなすか」を決めると、提案内容と成果を比較しやすくなります。

いきなり全社導入を決めるのではなく、現行のExcel・CRM・基幹システムから、顧客、担当者、案件、商品、売上、活動履歴の項目と件数を洗い出します。次に、営業プロセスを一枚に整理し、10〜30人程度の部門でMVPを検証します。共通のRFPで費用、作業範囲、体制、移行、連携、教育、保守を比較すれば、自社に合う導入方法を判断しやすくなります。

▼関連記事一覧
・Dynamics 365 Salesのシステム開発の進め方/やり方/流れや方法/手法/工程/手順
・Dynamics 365 Salesのシステム開発でおすすめの開発会社/ベンダー6選と選び方
・Dynamics 365 Salesのシステム開発の見積相場や費用/コスト/値段について
・Dynamics 365 Salesのシステム開発の発注/外注/依頼/委託方法について