おはようございます。室長こと吉島良平（Microsoft MVP for Business Applications | Microsoft Regional Director）です。

茂木外相がアメリカのルビオ国務長官および国際刑事裁判所（ICC）の赤根所長とそれぞれ電話会談を行い、米国のICC制裁措置や沖縄での強盗殺人事件などについて協議・遺憾の意を伝えたようです。最近、日本への移民や、外国人観光客に対する不平・不満が大きく論じられるようになりました。自分も空港の混雑やホテル代の高騰には正直頭を抱える事があります。ただ、一生懸命真面目に日本で頑張っている外国籍の方々へのレスペクトは忘れないようにしたいと思っています。良き日本を後世へ引き継ぎたい。これは今をこの日本で生きている我々日本人にとって大切な事だと思います。

本日はCRM×AIシリーズの最終稿です。準備に1か月、投稿は連続10日間。CRM、Data、AI、Agent、ERP—これだけの範囲を、一つの問いとして書き続けるのは、正直、簡単ではありませんでした。それでも最終回を迎えて感じるのは、書き始めた時よりも問いが深くなった、ということです。顧客への約束が、これほど多くの判断と責任と設計にまたがっているとは、第1回の時点ではここまで見えていませんでした。

Dynamics 365に関わり25年、CRM10年。ERPを15年やり、そこからCRMにも向き合うようになって10年になる自分が、CRMについてここまで書けるとは思っていませんでした。Dynamics 365について、恥ずかしくないレベルでCRM/ERPを語れるようになった。そんな気がしています。お客様からいただくご要望がCRMとERPを跨ぐものが多く、楽しい時も、辛い時もDynamics 365に日々向き合ってきた結果だと思っています。そういう機会をくださったお客様、CRM/ERPが内包されたDynamics 365に長く関われたおかげだと感謝しています。

前回のDynamics 365 Field Service × AIでは、顧客との会話から生まれた問題を、正しいCustomerとAsset（機器・資産）へ結び付け、Work Order（作業指示） Context（作業指示コンテキスト）を整え、Skill（スキル）、Parts（必要部品）、Location（現場所在地）、Time、Safetyを使って実行可能なPlanへ変え、現場でEvidence（証跡）を残し、その結果をCustomer 360とKnowledge（ナレッジ）へ戻す「Field Resolution Loop（現場解決ループ）」まで進みました。

そこで見えてきたのは、CRMの仕事が「顧客を知ること」で終わらないという事実です。顧客の期待を理解し、商談を進め、問い合わせを受け、現場へ引き継いでも、約束を実現するためには在庫、能力、調達、原価、信用、税、請求、入金、プロジェクトというERPの現実を通らなければなりません。

逆に、ERPが正しい伝票と会計だけを守っても、なぜその取引が必要なのか、顧客が何を期待し、どの問題を解決しようとしているのかが失われれば、企業は正しく処理しながら顧客を失うことがあります。今回の総集編では、CRMとERPを別々の製品群としてではなく、「顧客への約束を作り、守り、証明し、学ぶ一つの企業能力」として読み直します。

第1回では、CRMが顧客台帳から顧客変革基盤へ進む全体像とAI Native CRM 6層モデルを整理しました。第2回では、Customer Identityが崩れると、AIは優秀でも顧客を間違えることを考えました。第3回では、FabricのMedallionアーキテクチャでGolden Dataを育てる方法を整理しました。第4回から第8回まで、Customer 360、Journey（ジャーニー）、Sales（営業）、Customer Service、Contact Centerの設計を順に積み上げ、第9回では現場で解決を証明し結果をCustomer 360へ戻す設計まで進みました。今回はそのすべてをつなぎ直し、CRMとERPの接点を設計します。

10回を振り返ったとき、テーマは製品ごとに変わっていましたが、問いは一貫していました。企業が顧客に何を約束し、誰が確定し、どう実行し、何を学ぶか。以下の表は、そのレンズで全9回を読み直したものです。

表1：CRM×AIシーズン1を「約束を作り、実行し、学ぶ設計論」として読む

本稿は、Microsoft公式の製品ドキュメント、Microsoft Learn、Dynamics 365／Power Platform／Microsoft Fabricの公式公開情報、およびDX365Life「CRM×AI」シリーズ第1〜9回を基に構成しています。公開前には対象テナント、地域、言語、ライセンス、容量、Preview／GA、管理者設定の最新状態を確認してください。

---

9回を通して見えたものは「顧客データ」ではなく「顧客への約束」

シリーズの入口は顧客データでした。しかし、第1回から第9回までをつなぎ直すと、本当に扱っていたのはデータそのものではありません。企業が顧客の期待を受け取り、何を約束し、誰が実行し、何をもって完了と説明するかという設計でした。

ここでいうPromiseはQuoteやOrderという一枚の伝票ではありません。価格、納期、品質、提供範囲、サービスレベル、顧客への説明、問題発生時の対応、継続提供までを含みます。顧客は製品名やアプリ境界ではなく、一つの会社から受けた約束として体験します。

表2：DataからFeedback（フィードバック）まで、企業が引き受ける責任

つまり、Customer 360は顧客の全情報を集めることではなく、約束を作るために必要な顧客文脈を維持する能力です。Sales（営業）はOpportunityを増やすだけでなく、顧客と企業の双方が引き受けられる約束を形成する場所です。ServiceはCase（ケース）を閉じる場所ではなく、約束が実現されたかをEvidence（証跡）で確かめる場所です。

---

攻めのCRM、守りのERP — ただし、その二分法だけでは足りない

CRMを「攻め」、ERPを「守り」と表現すると、入口としては分かりやすくなります。CRMは顧客理解、需要創出、商談、エンゲージメント、継続を担い、ERPは実行可能性、在庫・能力、原価・利益、信用・回収、会計・コンプライアンスを担います。

ただし、AI時代にはこの二分法だけでは足りません。CRMにも守りがあります。誤ったIdentityで顧客へ連絡しないこと、Consentを守ること、Brand Promiseを逸脱しないこと、顧客の安全を優先することです。ERPにも攻めがあります。例外を予兆し、代替案を提示し、在庫と運転資本を再配置し、Marginを改善し、機会損失を減らすことです。

したがって最終的な整理は「攻め対守り」ではなく、Promise CreationとPromise Assuranceです。CRMは期待を価値ある約束へ変える能力を持ち、ERPはその約束が実行可能かを検証し、現実の取引・供給・キャッシュへ変える能力を持ちます。ERPから返るConstraintやOutcome（成果）がCRMへ戻ることで、次の提案はより正確になります。

---

CRMとERPの間で壊れるもの

企業変革の難所は、各アプリケーションの標準機能の中だけにあるのではありません。OpportunityからQuote、QuoteからOrder、OrderからSupply／Project、ServiceからWarranty／Invoice、ResolutionからRetentionへ渡るHandoff（引継ぎ）にあります。

CRMとERPの境界では、部門KPI、データの正本、時間軸、責任者、承認、例外、会計確定、顧客説明が異なります。営業は顧客の決定を前へ進めたい。供給部門は能力と在庫を守りたい。財務は利益、信用、税、キャッシュを確定したい。サービスは顧客問題を早く解消したい。どれも正しいのですが、局所的な正しさ同士がつながらないと、会社全体では約束が壊れます。

APIがつながっていても、価格の意味が違う、在庫の時点が違う、納期回答の責任者が不明、税区分が後から確定する、Warranty判断の根拠が残らないという状態は起こります。技術統合の成功は、業務継続や顧客約束の成功と同義ではありません。

---

Promise-to-Outcome（成果） Loopという編集モデル

Promise-to-Outcome（成果） Loopは、Lead-to-CashやQuote-to-Cashを置き換えるMicrosoftの正式プロセス名ではありません。CRM、ERP、Service、Customer 360を一つの経営ループとして読むための筆者の編集モデルです。

このモデルで重要なのは、各段階を画面や伝票ではなく「入力データ」「判断」「責任」「Evidence（証跡）」「次工程へのHandoff（引継ぎ）」で読むことです。顧客Signal（シグナル）からOpportunityを作るだけでは足りません。何を約束するのか、約束は実行可能か、実行結果は収益とキャッシュになったか、顧客問題は解消したか、何を学びとして戻すかまで閉じる必要があります。

表3：Promise-to-Outcome（成果） Loopの経営設計

Cashは重要な中間成果です。しかし、入金だけでLoopを終えると、顧客が問題を抱えたままでも成功に見えてしまいます。Outcome（成果）はMargin、Cash、Resolution、Retention、Learningまで広げて捉える必要があります。利益を残せたか、資金へ変わったか、問題を解決したか、関係が続いたか、次の判断が改善したか。これらを一つの因果として見ることで、部門KPIを企業成果へ接続できます。

---

Agentはアプリの境界を越える。だから責任境界が必要になる

従来の連携では、人が画面を開き、内容を確認し、次のシステムへ登録する途中で違和感に気づくことがありました。Agentはその摩擦を減らし、アプリ境界を速く越えます。これは大きな価値ですが、誤ったIdentity、価格、在庫、納期、信用、税、契約、権限も同じ速度で伝播します。

そのため評価すべきはAI精度だけではありません。どのSystem of Recordを参照したか、情報はいつの時点か、誰の権限で何を読んだか、どの金額・Risk（リスク）・顧客影響で承認へ戻すか、誰が何を実行したかを観測できるか、異常時に停止・例外処理・Rollbackできるか、結果をEvidence（証跡）として説明できるかが必要です。

AIが賢くなるほどGovernanceが軽くなるわけではありません。実行速度が上がるほど、Governanceを人の記憶や善意ではなく、構成可能なルール、権限、閾値、ログ、停止条件として設計する必要があります。Governanceは自動化を遅くするブレーキではなく、安全に速く進むための道路設計です。

---

Dynamics 365を一つの企業実行基盤として見る

Dynamics 365の価値を「CRMとERPが同じデータベースで動くこと」と説明するのは正確ではありません。Sales（営業）、Customer Service、Field Service、Customer Insights等の顧客エンゲージメント系アプリはDataverseを中核とします。一方、Dynamics 365 Finance、Supply Chain Management、Project Operations（複数のデプロイモデルを持ち、CRMとERPの双方にまたがる構造を持つ。最新動向は別稿参照）、Business Centralには、それぞれの業務と統制に適したアプリケーション構造とデータストアがあります。

したがって設計では、どのシステムが正本か、どこへ同期するか、どこは参照に留めるか、誰が更新できるか、更新の順序と時点をどう合わせるかを明確にしなければなりません。同じブランドだから自動的に一つの意味になるわけではありません。

それでもDynamics 365を一つの視野で見る意味があります。Microsoft 365は会話と成果物が生まれる仕事の場、Power Platformは業務の拡張とオーケストレーション、Dataverseは顧客・業務文脈、Dynamics 365の各アプリは実行と記録、Microsoft Fabricは横断的な履歴・分析・経験、Copilot StudioはAgentの目的・知識・Actionを構成する接点、AzureとSecurityは実行・統合・保護の基盤になります。価値は製品数ではなく、同じ経営文脈の中で正本、判断、権限、実行、Evidence（証跡）を設計できることです。

---

FabricはCRMとERPの「経験」をAIへ渡す

Operational Systemは現在の業務事実を確定します。顧客、商談、Case（ケース）、Work Order（作業指示）、受注、在庫、請求、入金、会計は、それぞれの業務責任の下で更新されます。一方、Microsoft FabricとOneLakeは、CRMとERPをまたぐ履歴、Evidence（証跡）、結果、意味を蓄積し、次の分析とAI／Agent判断へ経験を渡す層として捉えられます。

ここでいう経験は、AIが勝手に記憶することではありません。いつ、どの顧客・製品・契約に、どの約束をし、何が制約となり、どのActionを選び、どの結果になったかを、AIが必要なときに根拠として参照できるようにすることです。

ただしFabricを新たな万能正本にしてはいけません。Operational Data、Golden Data、Customer Intelligence、Engagement、ERP Executionには異なる責任があります。Fabricが統合・履歴・意味付けを担っても、取引の確定や顧客同意の訂正、在庫引当、会計仕訳などの業務責任まで奪うわけではありません。

表4：Operational Systemと経験の層の責任分界

---

CxOが見るべきものはRevenueかCostかではなく、約束の質

CxOの視点では、Revenue最大化とCost最小化を別々に追うだけでは不十分です。売上を増やすために実行不能な納期を約束すれば、Expedite Cost、返品、再訪問、補償、回収遅延が増えます。コストを削るために在庫やサービス能力を過度に削れば、機会損失、停止時間、顧客離反が増えます。

見るべきなのはPromise Accuracy、Margin、Cash Conversion、Working Capital、Service Resolution、Retention、Learning Speedの因果連鎖です。正確な約束は、無理な例外と再作業を減らし、利益を守ります。正しい実行と請求はCashへ変わります。問題解決のEvidence（証跡）はRetentionを支えます。Outcome（成果）が学習へ戻れば、次の約束はさらに正確になります。

表5：部門KPIを約束の質へ接続する

---

Human-in-the-Loopは、人を残す設計ではなく責任を配置する設計

Human-in-the-Loopを「AIの出力を人が一度見ること」と理解すると、全件承認によって速度を失うか、形式的なクリックによって責任だけが残るかのどちらかになります。本質は、判断の影響と不確実性に応じて責任を配置することです。

Agentへ任せる領域、Human Reviewを置く領域、Human Decisionを必要とする領域を分けるだけでなく、誰がAccountableか、どのEvidence（証跡）で承認するか、どの条件で停止・Escalation（エスカレーション）するか、事後監査で判断を再現できるかまで決めます。

表6：Human-in-the-Loopを責任配置として設計する

高影響判断では、AIが提案を作れることと、AIへ決定を委ねてよいことを分けなければなりません。会計・税務の確定、信用供与、契約例外、安全や診断、重要な価格・納期・補償などは、企業として誰が責任を持つかを明示します。人が残るのはAIが未熟だからだけではなく、会社が説明し、承認し、責任を引き受ける主体だからです。

---

AI Native CRMからAI Native ERPへ

AI Native CRMは、顧客Signal（シグナル）をCustomer 360の文脈で理解し、AI／Agentと人が行動へ変え、結果から学ぶCRMの再定義でした。次に問うのは、その約束を受け取るERPです。

AI Native ERPは、既存ERPへチャット画面を追加することではありません。正しい取引を記録し、ルールに従って処理し、締め、報告する強みを残しながら、業務の途中で例外を捉え、影響を理解し、選択肢を提示し、許された範囲で実行し、統制し、結果から学ぶ基盤へ広がることです。

次の連載では、ERPは記録する場所から、例外を捉え、判断し、実行し、統制し、学ぶ場所へどう変わるのかを追います。Finance、Supply Chain Management、Project Operations、Business CentralでAgentはどこまで動けるのか。攻めのCRMが作ったPromiseを守りながら、ERPはどこまで攻められるのか。これが次の半年の問いです。

---

まとめ：CRMとERPの間に、企業変革がある

CRMは顧客の期待を理解し、価値ある約束を作ります。ERPはその約束を能力、在庫、原価、信用、税、供給、会計、キャッシュの現実へ変えます。Serviceは約束が実現されたかを顧客の問題解決とEvidence（証跡）で確かめます。Customer 360とFabric／OneLakeは、結果を次の理解と判断へ戻します。

この循環のどこかが切れると、部門ごとのシステムは動いていても、会社としては学べません。CRMが作ったPromiseがERPへ届かない。ERPのConstraintがSales（営業）へ戻らない。ServiceのResolution Evidence（解決証跡）がJourney（ジャーニー）や製品改善へ戻らない。これが「CRMとERPの間」に企業変革がある理由です。

---

---

Let’s Enjoy our DX365LIFE!

---