CRMとERPをまたぐエージェント—統合設計の全体像

こんばんは。室長こと、吉島良平（Microsoft MVP for Business Applications | Microsoft Regional Director）です。

皆さん、いかがお過ごしでしょうか？　このシリーズも第6回になりました。今日は少し違う入り方をさせてください。

このシリーズを書きながら、ひとつ面白いことに気づきました。スポーツの例えで整理するとこうなります。

野球では、ピッチャーがいてキャッチャーがいる。ラグビーではスクラムハーフとスタンドオフ（フライハーフ）のコンビ。サッカーではパサーとトップ下。アメフトではQBとレシーバー。

どのスポーツでも、「球を出す役割」と「それを受け取って判断・実行する役割」がある。そしてどちらが欠けても機能しない。

これは単なる例え話ではありません。ビジネスアプリケーションの世界でも、まったく同じことが起きています。AIが自律的に動くためには、正確な球（データ）が必要です。在庫はいくつあるか・与信残高はいくらか・この顧客は誰か・この商談はどの段階にあるか——これらの球を、正確に・リアルタイムに・適切な文脈で出せるシステムがなければ、AIエージェントはノールックパスを出せません。Dynamics 365のCRMとERPは、まさにこの「球出し」の基盤です。

さて、もうひとつ正直に書かせてください。私はMicrosoft MVP for Business ApplicationsとMicrosoft Regional Directorというタイトルをいただいています。ありがたいことです。しかし実は「自分はこれにふさわしいのだろうか」と、いつも自問自答しています。

MVPやRDは、コミュニティへの貢献・技術的な深さ・情報発信の継続が評価されるものです。毎年MicrosoftのWave Releaseを追いかけ、新しい機能や変化をキャッチアップし続けることが求められます。正直なところ「自分がこのタイトルにふさわしいかどうか」は、常に問い続けることが大事だと思っています。ふさわしいと思った瞬間に成長が止まる気がするからです。このシリーズを書き続けることも、その問いへの答えのひとつなのかもしれません。

では今日も、その問いを胸に第6回をお届けします。テーマはいよいよ「CRMとERPをまたぐエージェント——統合設計の全体像」です。これまでのシリーズで積み上げてきたすべてが、ここで統合されます。

Series #06 — Agentic Engineering × Dynamics 365

CRMとERPをまたぐエージェント

統合設計の全体像——Dynamics 365 デザインパターンとエージェントアーキテクチャ

2026年5月
第6回
Dynamics 365
設計パターン
Power Apps
MCP / APIM

ここで前提を一つはっきりさせる必要があります。

単一のシステムに閉じたエージェントは、本質的な価値を持ちません。

CRMの中だけで動くエージェント、ERPの中だけで動くエージェントは、それぞれの業務を部分的に最適化することはできても、業務全体を最適化することはできません。

顧客、契約、在庫、サービス、請求。本来は分断されているこれらの情報を横断して判断しているのは、これまで人間でした。

エージェントが価値を持つのは、この「分断された判断」を横断できるようになったときです。

第1回でエージェントの定義と自律性の段階を、第2回でHuman-in-the-Loopの設計原則を、第3回でデータモデルを、第4回でCopilot Studioの実装パターンを、第5回で監査・コンプライアンスの設計を整理してきました。それぞれの回で「部分」を見てきましたが、今回はそれらを統合して「全体」として俯瞰します。Dynamics 365にはCRM・ERP・Field Service・Project Operations・Commerce・Human Resources・Customer Insightsと多数のアプリケーションが存在します。今回はまず「Dynamics 365 デザインパターン」として全体の組み合わせパターンを整理し、その上でエージェントが統合的に動く全体像を見ていきます。そしてPower Apps・MCP・APIMといった周辺技術が加わることで、どんな面白いシナリオが生まれるかも考えます。

Design patterns

Dynamics 365 デザインパターン——全体マップ

まず全体を俯瞰する前に、Customer Insights – Dataの位置づけを明確にしておきます。Customer Insights – DataはすべてのパターンからデータをCDPに集約できる横断的なプラットフォームです。どのパターンを選択しても、CRM・ERP・Commerce・Field Serviceのすべてのトランザクションデータ・行動データを統合して顧客の統一プロファイルを生成できます。以下のパターン表では省略していますが、すべてのパターンに横断的に追加できます。

#	パターン名	主要アプリ構成
P1	ERP単体（BC）	Business Central（従業員・勤怠含む）
P2	ERP単体（F&O）	Finance + SCM（F&O内HRモジュール含む）
P3	ERP + D365 HR	Finance + SCM + Dynamics 365 HR（単体）
P4	CRM + BC	Sales/CS + Business Central
P5	CRM + F&O	Sales/CS + Finance + SCM（+ HR）
P6	CS + Contact Center	Customer Service + Contact Center（+ CI-Journeys）
P7	ERP + Field Service	F&O/BC + Field Service + Project Operations（※Wave 1からセット運用が前提）+ HR
P8	ERP + Project Operations	F&O + Project Operations（+ HR）
P9	Commerce + CRM + ERP	Commerce + Sales + BC/F&O + Customer Insights
P10	Full Suite	CRM + F&O + Field Service + Project Operations + Customer Insights + D365 HR

Field ServiceとProject Operationsの依存関係

Wave 1からField ServiceのTime EntriesがProject Operationsに直接流れる設計になりました。フィールド技術者が記録した時間エントリがProject Operationsに反映され、プロジェクト原価・請求に即時反映されます。Field Serviceを導入する場合はProject Operationsとセットで設計することが現実的です。

P1：ERP単体（BC）——中堅・中小企業のシンプルな統合ERP

Business Central単体で財務・在庫・販売・購買・プロジェクト管理を完結させるパターンです。典型的な企業像は社員数50〜300名程度の製造業・卸売業・サービス業で、「まず基幹業務をひとつのシステムに統合したい」という段階の企業です。

エージェントの具体例：

→Sales Order Agentが受注から出荷指示まで自律実行

→Payable Agentが仕入先請求書の照合・承認・支払いを自動処理

→Expense Agentが経費精算のポリシーチェック・承認・仕訳処理を自律実行

→月次クローズ支援として未計上トランザクションの検知・担当者への確認タスク自動生成

P2：ERP単体（F&O）——大企業の基幹ERP

Finance + SCMを中心としたF&O系ERPで大企業の基幹業務を完結させるパターンです。グローバル展開している製造業・商社・大手小売で、複雑なサプライチェーン・多通貨・連結会計・規制対応が必要な企業向けです。

エージェントの具体例：

→需要予測連動の自動発注（SCM）

→銀行口座照合（Bank Reconciliation）の自律化（Finance）

→製造委託の無償支給・有償支給の管理と在庫自動補充

→製造ラインの品質異常検知と製造伝票への自動フラグ登録

P3：ERP + D365 HR——人事機能を本格強化した大企業向けパターン

Finance + SCMにDynamics 365 Human Resources（単体製品）を追加するパターンです。F&O内のHRモジュールでは対応できない本格的な採用管理・ベネフィット管理・人事評価・組織管理が必要な企業向けです。

エージェントの具体例：

→採用プロセスの自動化（応募者スクリーニング・面接スケジュール調整）

→従業員のスキルデータとField Serviceのリソーススケジューリングの連携

→勤怠データとFinanceの人件費配賦の自動処理

P4：CRM + BC——中堅・中小企業の営業からバックオフィスまで統合

Dynamics 365 Sales・Customer ServiceとBusiness Centralを組み合わせるパターンです。「フロントの営業・顧客管理」と「バックのERP処理」を統合します。BC 28.0で大幅に拡張されたIntegration Table Mappingにより、DataverseとBCのテーブル間のフィールドマッピングをUIから直接設定できるようになり、CRMとBCのデータ双方向同期がノーコードで実現できます。

エージェントの具体例：

→CRMで受注確定した商談がBC側の受注伝票に自動連携

→BCの与信残高をバーチャルテーブル経由でCRMエージェントがリアルタイム参照

→見積生成時にBCの在庫・原価をリアルタイム参照して正確な見積を自動生成

P5：CRM + F&O——大企業の営業からサプライチェーンまで統合

Dynamics 365 Sales・Customer ServiceとFinance + SCMを組み合わせる、大企業向けの標準的なフルCRM+ERPパターンです。大規模な営業組織を持ち、サプライチェーンが複雑な製造業・商社・大手サービス業向けです。

エージェントの具体例：

→CRMの見積エージェントがSCMの実原価・在庫可用性をDual-write経由でリアルタイム参照

→与信管理はF&OをマスターとしてCRMがバーチャルテーブル経由で参照

→受注からF&Oの出荷・請求・会計処理までエンドツーエンドで自律実行

P6：CS + Contact Center——コールセンター・カスタマーサポート重視のパターン

Customer ServiceとContact Centerを組み合わせ、CI-Journeysも加えたカスタマーサポート特化パターンです。大規模なコールセンターを運営する通信・金融・保険・流通・EC企業向けです。

エージェントの具体例：

→Contact Centerのエージェントが一次対応を自律実行し感情スコアが閾値を超えたケースだけ人間にルーティング

→Customer Serviceエージェントがナレッジベースを参照して回答案を自動生成

→CI-Journeysのエージェントがケースクローズとともに満足度アンケートを自動送付

P7：ERP + Field Service + Project Operations——保守・修理・現場作業サービスのパターン

F&OまたはBCにField ServiceとProject Operationsをセットで組み合わせるパターンです。製造設備の保守サービス・現場作業員を多数抱えるサービス業・エレベーター・空調設備の保守業者・ITインフラのフィールドサポート向けです。

エージェントの具体例：

→IoTセンサーの異常検知をトリガーにField Serviceの作業指示を自動生成

→修理伝票の完了をトリガーにCRMエージェントが顧客への完了通知・次回点検案内を自動送付

→技術者のスキル・資格・稼働状況をHRから参照して最適な作業員を自動アサイン

→Field Serviceの工数がProject Operationsに自動反映されてプロジェクト原価・請求に即時反映

P8：ERP + Project Operations——プロジェクト型ビジネスのパターン

F&OとProject Operationsを組み合わせ、プロジェクトの販売・リソース管理・原価・請求・会計を統合するパターンです。コンサルティング会社・システムインテグレーター・建設会社・エンジニアリング会社・受注製造業向けです。

エージェントの具体例：

→プロジェクトの予算消化率が閾値を超えた時点でPMにアラートを自動送信

→リソース計画エージェントがHRの人員データを参照して最適なプロジェクトアサインを提案

→タイムシートのデータをProject Operationsに自動反映

→プロジェクト完了後の請求書生成をエージェントが自律実行

P9：Commerce + CRM + ERP——小売・EC・D2Cのパターン

CommerceとSalesとBC/F&O、さらにCustomer Insightsを組み合わせる小売・EC特化パターンです。実店舗とECサイトを両方持つアパレル・食品・家電量販・D2Cブランド向けです。

エージェントの具体例：

→ECサイトでの購買行動データがCustomer Insights – Dataに集約されてリアルタイムで統一プロファイルが更新

→在庫エージェントがオンライン・オフラインの在庫を横断的に監視してオムニチャネル対応の発注を自動実行

→CI-JourneysのエージェントがECサイトでのカート放棄を検知してパーソナライズされたフォローメールを自動送付

P10：Full Suite——大企業・複合業態の統合パターン

CRM + F&O + Field Service + Project Operations + Customer Insights + D365 HRをすべて組み合わせるフルスイートパターンです。複数の事業を持つ大企業・製造から販売・アフターサービスまで一気通貫で管理したいグローバル企業向けです。

エージェントの具体例：

→営業エージェントがCRMで商談を管理し、受注確定後にF&OのSCMエージェントが製造・調達を自律実行

→Field Serviceエージェントが設置・保守を管理し、Project Operationsエージェントがプロジェクト原価・請求を処理

→HR AgentがD365 HRのデータを参照してリソースアサインを最適化

→Customer Insights – DataがすべてのトランザクションデータをCDPに集約して次の商談につながる顧客インサイトをSalesエージェントに提供

Customer Insights – Dataはすべてのパターンに横断的に追加できます

P10に限らず、どのパターンであっても「CDPでデータを統合し、次のアクションにつなげる」という設計は、エージェントの判断品質を高める上で最も効果的な投資のひとつです。

Power Apps — Simplifying data entry

Power Appsによる入力画面の簡素化——複雑なデータ登録を現場に使いやすく

Dynamics 365の標準画面は機能が豊富ですが、その分「現場の担当者が使うには複雑すぎる」という問題が実装の現場で必ず出てきます。Power Appsはこの問題を解決します。「この業務でこの人が使う画面」だけを、シンプルに・モバイル対応で・必要な情報だけに絞って設計できます。バックエンドはDynamics 365のデータモデルをそのまま使い、入力画面だけを最適化する——これがPower Appsの最も効果的な使い方のひとつです。

さらに重要なのは、入力画面が簡単になれば現場担当者がリアルタイムにデータを入力するようになるという点です。第3回で「月末まとめ入力ではエージェントは機能しない」と書きました。Power Appsによる簡素化は、エージェントへの「球出し精度」を上げる最も現実的なアプローチのひとつです。

見積入力画面

Dynamics 365 SalesのQuoteエンティティは非常に多機能ですが、営業担当者が必要なのは「顧客・品目・数量・価格・納期」だけというケースが多いです。Power Appsで「見積クイック入力アプリ」を作り、5項目を入力すればDynamics 365 CRMに見積レコードが自動生成される設計にすると、入力時間が劇的に短縮されます。エージェントはその見積データを受け取って原価チェック・承認フロートリガーを自律実行します。

タイムシート入力画面

Project OperationsまたはField Serviceの工数入力は、現場の技術者にとって最も負荷が高い作業のひとつです。「今日・どのプロジェクト・何時間・作業内容」の4項目だけをスマートフォンから入力できるPower Appsを作り、Project Operationsに自動連携する設計が現実的です。Wave 1からField ServiceのTime EntriesがProject Operationsに直接流れる設計になっているため、このPower AppsはField Service・Project Operations両方への入口として機能できます。

製造実績入力画面——ロット番号・シリアル番号・MES連携

SCMの製造オーダーに対して、ラインオペレーターが製造完了数・不良数・作業時間を入力する画面をPower Appsで作ります。ここで特に重要なのがロット番号とシリアル番号の選択です。Dynamics 365 SCMの標準画面では、ロット番号・シリアル番号を選択・入力するオペレーションが複数の画面を行き来する必要があり、製造ラインの現場では「画面が複雑すぎて入力が後回しになる」という問題が頻発します。

Power Appsで専用の入力画面を作ることで、バーコードスキャナーまたはカメラでロット番号・シリアル番号を読み取り、ワンタップでSCMの製造伝票に紐付けられるシンプルなUXが実現できます。

MES（製造実行システム）との連携

製造業の現場ではすでにMESが稼働しているケースが少なくありません。MESは製造ラインの機械・センサー・PLCから直接データを収集し、リアルタイムで製造実績・品質データ・設備稼働状況を管理します。

連携パターンA（リアルタイム）：MESのデータをAzure IoT Hub経由でSCMの製造伝票に自動反映。ロット番号・シリアル番号もMESから自動連携されるため手入力が完全になくなります。

連携パターンB（バッチ）：Azure Data FactoryでETL処理を行い定期的にSCMに取り込む設計。既存MESへの影響を最小限に抑えながら連携できます。

修理実績入力画面——パーツのシリアル番号・ロット番号管理

Field Serviceの修理伝票（Service Order）に対して、技術者がスマートフォンから「作業内容・使用パーツ・作業時間・完了写真」を入力できるPower Appsを作ります。修理現場では「どの在庫からどのパーツを使ったか」をシリアル番号レベルで記録することが、保証管理・トレーサビリティ・在庫精度の観点から非常に重要です。

→サービスカー内のパーツをバーコードスキャンしてシリアル番号を自動入力

→使用可能な在庫ロット・シリアル番号を絞り込んで表示・パーツ使用と同時にSCMの在庫から自動引当

→完了写真をAzure AI Foundryのコンピュータビジョンモデルに送信して損傷状況を自動記録

→修理完了と同時にCRMエージェントが顧客への完了通知・次回点検案内を自動送付

MCP & APIM

MCP・APIM——外部連携が広げるエージェントのシナリオ

Power Appsで入力画面を簡素化し、Dynamics 365にデータが正確にリアルタイムで蓄積される環境が整ったとき、次の問いが生まれます。「そのデータを外部のシステムやAIとどうつなぐか」——ここでMCP（Model Context Protocol）とAzure API Management（APIM）が登場します。

MCP（Model Context Protocol）——エージェントと外部システムをつなぐ標準プロトコル

MCPはAnthropicが提唱し業界標準になりつつあるプロトコルで、AIエージェントが外部のツール・データソース・APIを安全に呼び出すための標準インターフェースです。Copilot StudioのエージェントもMCPサーバーに接続することで、Dynamics 365の外にあるシステムのデータをリアルタイムで参照・操作できるようになります。

外部与信照会との連携：CRMエージェントが見積を生成する際、MCPを通じて外部の与信照会サービスをリアルタイムで呼び出し、与信スコアを取得してDynamics 365 Financeの与信データと組み合わせて判断する

物流・配送システムとの連携：SCMエージェントが発注を実行した後、MCPを通じて物流会社のAPIを呼び出し、リアルタイムの配送状況・納期回答を取得してDynamics 365の受注伝票に自動反映する

CAD・PLMシステムとの連携：製造業での設計変更をPLMシステムから検知し、MCPを通じてDynamics 365 SCMの部品表（BOM）に変更内容をエージェントが自動反映する

気象データ・市場データとの連携：需要予測エージェントがMCPを通じて気象データAPIや市場トレンドデータを取得し、季節変動・市場変化を加味した高精度な発注量を算出する

マーケットプライス情報からの価格算出：新車販売時、CRMエージェントがMCPを通じて外部の中古車市場データAPI（オークション相場・市場流通価格・走行距離・年式・グレード別の価格データ等）をリアルタイムで呼び出し、顧客の下取り車両の市場価値を自動査定します。その結果をDynamics 365 CRMの商談レコードに反映し、市場データに裏付けられた下取り価格を営業担当者に提示します。この下取り価格データはERPの在庫・原価管理にも連携され、受け払い元帳への反映まで自動処理できます

会計事務所・税務システムとの連携：Financeエージェントが決算処理を実行した後、MCPを通じて外部の税務申告システムにデータを連携し、申告書の下書きを自動生成する

MCPの重要な特徴は「標準プロトコル」であることです。個々のシステムとの連携ごとにカスタムAPIを開発するのではなく、MCPサーバーを一度実装すれば、Copilot StudioをはじめとするMCP対応のあらゆるAIエージェントから呼び出せるようになります。

Azure API Management（APIM）——すべてのAPIを一元管理するゲートウェイ

Dynamics 365のエージェントアーキテクチャが複雑になればなるほど、エージェントが呼び出すAPIの数も増えます。Azure API ManagementはこれらすべてのAPIを一元管理するゲートウェイです。

セキュリティの一元管理

認証・認可・レート制限・IPフィルタリングを一か所で管理できます。APIキーや認証情報の管理が集中化され、セキュリティリスクが大幅に下がります。

APIのバージョン管理

Dynamics 365のAPIはWave Releaseごとに更新されます。APIMでバージョン管理を行うことで、エージェント側のコードを変更せずにAPIのバージョンアップに対応できます。

使用量の監視とコスト管理

エージェントがどのAPIをどの頻度で呼び出しているかをAPIMで一元的に把握できます。有償APIの使用量をリアルタイムで監視し、コスト最適化と予算超過のアラートを設定できます。

MCPとの組み合わせ

MCPサーバーへのアクセスをAPIMを経由させることで、外部システムへの連携もすべて一元的なセキュリティポリシー・監視・コスト管理の下に置くことができます。

Summary

まとめ

今回はCRMとERPをまたぐエージェントの統合設計の全体像を、Dynamics 365 デザインパターン・Power Apps・MCP・APIMという切り口から見てきました。改めて整理するとこうなります。

→ビジネスアプリケーションの役割はAIへの「球出し」です。正確な球が来なければ機能しません。Dynamics 365のCRMとERPが正確なデータをリアルタイムに提供できて初めて、エージェントは自律的に動けます

この「球出し」のイメージをより具体的に感じていただきたい方は、以前書いた【ある製造業の物語】という架空のストーリーを読み直してみてください。

→Dynamics 365のデザインパターンはP1〜P10の10パターンに整理できます。Customer Insights – DataはすべてのパターンからデータをCDPに集約できる横断的なプラットフォームであり、どのパターンにも追加できます

→Field ServiceはWave 1からProject Operationsとのセット運用が前提になりました。Time EntriesがProject Operationsに直接流れ、プロジェクト原価・請求に即時反映される設計です

→見積・タイムシート・製造実績・修理実績などの入力画面をPower Appsで簡素化することで、ロット番号・シリアル番号のバーコードスキャン入力・MESとのリアルタイム連携が実現し、エージェントへの「球出し精度」が上がります

→MCPはエージェントと外部システムをつなぐ標準プロトコルです。外部与信照会・物流API・気象データ・マーケットプライス情報・CAD/PLMシステムとの連携が標準化された形で実現できます。APIMはすべてのAPIを一元管理するゲートウェイとして、セキュリティ・バージョン管理・コスト管理を担います

このシリーズの構成

プロローグ：企業ソフトウェアが「考えて動く」時代へ

Agentic Engineeringとは何か——「作る」から「統率する」へ

CRM：商談フォローERP：自動発注

どこに人間を置くか——Human-in-the-Loopの設計原則

CRM：見積承認ERP：発注閾値

エージェントはデータをどう使うか——CRMとERPのデータモデル

CRM：顧客データERP：仮想テーブル

エージェントを組み立てる——Copilot Studioで何ができて何ができないか

CRM連携ERP連携

エージェントを信頼できるか——ログ・監査・コンプライアンスの設計

CRM：通信ログERP：会計監査

CRMとERPをまたぐエージェント——統合設計の全体像 ← 本記事

CRM + ERP 統合

これからのDynamics 365エンジニアに何が求められるか

CRMエンジニアERPエンジニア

次回は「これからのDynamics 365エンジニアに何が求められるか」をテーマに、このシリーズの締めくくりをお届けします。Agentic Engineeringの波の中で、実装者・意思決定者・エンジニアそれぞれに何が求められるのか——技術スキルだけでなく、業務設計力・AI統率力・組織変革への関わり方まで、正面から考えていきます。

以上、室長でした。