Data quality

エージェントの判断はデータの品質で決まる

エージェントの自律性がどれだけ高くても、判断の根拠となるデータが間違っていれば、エージェントは自信を持って間違えます。これはラグビーで言えば、フィールドの状況認識が間違ったままノールックパスを出すようなものです。受け取る側がいない場所にパスが飛んでいきます。

エージェントが使うデータには、大きく3つの品質要件があります。

CRM — Data model

CRMのデータモデルを読み解く

Dynamics 365 CRMのデータモデルは、「顧客との関係性」を中心に設計されています。エージェントがCRMのデータを使って判断するとき、主に次の3つのレイヤーのデータを参照します。

ERP — Data model

ERPのデータモデルを読み解く

Dynamics 365 ERPのデータモデルは、「モノと金の動き」を中心に設計されています。CRMが「顧客との関係性」を扱うのに対し、ERPは「実際に何が・いくらで・どこに・いつ動いたか」という事実を記録します。

製造委託と支給材のデータモデル

製造業でエージェントを設計するとき、見落とされがちだが実装上非常に重要なのが「製造委託」と「支給材」のデータモデルです。

外部の協力工場に製造を委託するケースでは、Dynamics 365で外注発注（Subcontracting Purchase Order）として管理されます。エージェントはこの外注発注のステータス——委託先への指示が出たか、進捗はどうか、入荷予定はいつか——をリアルタイムで監視し、遅延を検知した場合は担当者にアラートを送るという自律実行が可能です。

支給材には大きく2種類があります。

監査証跡データ——変更ログと監査ログ

エージェントが自律的に動く世界では、「誰が・いつ・何を・なぜ変えたか」を追跡できる監査証跡データが、データモデルの中で新たに重要な位置を占めます。

Dynamics 365 CRMには監査ログ機能が標準搭載されており、エンティティ・フィールド単位で変更履歴を記録できます。エージェントが商談のステータスを変更した・見積を自動生成した・承認フローをトリガーした——これらすべての操作がログとして残ります。Dynamics 365 ERP（Finance・SCM・Business Central）でも同様に、トランザクションの変更履歴・承認フローの記録・仕訳の修正履歴が監査ログとして保持されます。特にFinanceでは内部統制の観点から、誰が仕訳を入力し・誰が承認し・誰が修正したかの完全な証跡が監査要件として求められます。エージェントが自動生成した仕訳の証跡も同様に記録される設計が必須です。

さらに細粒度のテレメトリデータ——エージェントがどのくらいの頻度で動いているか・処理時間はどれくらいか・どこでエラーが起きているか——はAzure Application Insightsで収集します。Azure FunctionsやAzure Web AppsからApplication Insightsにテレメトリを送信することで、エージェントが呼び出す各処理のレイテンシ・エラー率・スループットをリアルタイムで監視できます。このデータをPower BIで可視化することで、「エージェントの稼働状況ダッシュボード」を実装者・運用者・経営者それぞれに合わせた粒度で提供できます。第2回で触れた「エージェントの閾値を継続的にチューニングする」という運用の、具体的な実装手段がここにあります。

Customer Insights

Customer Insightsが加わると何が変わるか

CRMのデータモデルとERPのデータモデルを整理してきました。しかしここまでの話には、まだ重要なピースが欠けています。「顧客が何をしたか」というデータです。CRMは「顧客との関係性」を、ERPは「モノと金の動き」を記録します。しかしどちらも、「顧客がWebサイトで何を見たか」「どのメールを開封したか」「どのキャンペーンに反応したか」というデジタル行動データは持っていません。これを補うのがDynamics 365 Customer Insightsです。

たとえばこういうシナリオが実現します。顧客がWebサイトで特定製品のページを複数回閲覧する（行動データ）→ Customer Insights – DataのCDPがこの顧客のプロファイルを更新する → Customer Insights – JourneysのエージェントがこのシグナルをトリガーにCRMの担当営業にアラートを送る → SalesエージェントがCRMの商談データと組み合わせてフォロー提案を自動生成する → 担当者が確認・承認して送付する。この流れはCRM・ERP・Customer Insightsの3つがデータとして連携して初めて動きます。

Microsoft Fabric & Copilot IQ

構造化データと非構造化データ——Microsoft FabricとCopilot IQが開く世界

ここまで話してきたCRM・ERP・Customer Insightsのデータは、すべて「構造化データ」です。しかし実際のビジネスの現場には、構造化されていないデータが大量に存在しています。

Microsoft Fabricは、構造化・非構造化を問わず、あらゆるデータを一元的に収集・統合・分析するデータ基盤プラットフォームです。SharePointに保存されたドキュメント・Teams上の会話・Azure Blob Storageの画像・動画・音声データまでを、ひとつのデータレイク（OneLake）に統合できます。Microsoft Copilot IQは、このFabricに統合されたデータを、エージェントが自然言語で検索・参照・活用できるようにする仕組みです。

非構造化データの活用シナリオ

Azure — Integration architecture

Azureサービスが支えるデータ統合アーキテクチャ

FabricとCopilot IQでデータを統合する話をしましたが、実際の実装現場では「どうやってデータをFabricに持ってくるか」「エージェントとシステムをどうつなぐか」というインフラ設計が重要になります。

2分のタイムアウト問題とAzure Functions

Dynamics 365 CRMのプラグイン開発をしたことがある方なら必ずぶつかる壁があります。プラグインの実行タイムアウトが2分に制限されているという問題です。重い処理・外部API呼び出し・大量データの処理をプラグイン内に書いてしまうと、タイムアウトエラーで落ちます。この問題の解決策がAzure Functionsです。重い処理・外部システムとの連携・バッチ処理をAzure Functionsに切り出すことで、タイムアウトの制約を回避できます。エージェントが長時間かかる処理をトリガーする場合も同様で、Copilot StudioからAzure Functionsを呼び出す設計が現実的です。

データ連携のAzureサービス群

Microsoft Entra ID——すべての認証・認可の基盤

どれだけ優れたエージェントを設計しても、「誰がそのエージェントを動かせるか」「エージェントはどのシステムにアクセスできるか」を正しく管理しなければ、セキュリティリスクになります。これを担うのがMicrosoft Entra ID（旧Azure Active Directory）です。

Agent 365——すべてが統合されたエージェントの世界

ここまで見てきたデータ基盤・Azureサービス群・Entra IDによるセキュリティ——これらが揃った上で動くのが、MicrosoftがAgent 365と呼ぶエージェント群です。

Agent 365とは、Dynamics 365のCRM・ERP・Customer Insightsに組み込まれた業務エージェントの総称です。Wave 1で登場したSales Agent・Customer Service Agent・Finance Agent・Supply Chain Agent・Business Central（Sales Order Agent・Payable Agent・Expense Agent）などが含まれます。これらはCopilot Studioを「指揮台」として複数のエージェントが協調して動くマルチエージェントアーキテクチャとして設計されています。

CRM・ERP・E-Commerceをまたぐ統合アーキテクチャの具体的な姿——顧客がECサイトで注文する → Logic AppsがDynamics 365の受注伝票を自動生成 → ERPのエージェントが在庫確認・与信チェックを実行 → 出荷完了後、CRMエージェントが顧客にフォロー連絡を自動送付 → 顧客の購買行動データがADLS経由でFabricに蓄積され、Customer Insightsのプロファイルが更新される → 次回の購買タイミングをエージェントが予測し、パーソナライズされたアプローチを営業担当者に提案する。インフラ側のエンジニアにとっては、「Dynamics 365のプロジェクト」が「Azureフル活用のアーキテクチャ設計」と不可分になる時代が来ているということです。

Summary

まとめ

今回はエージェントがデータをどう使うかをテーマに、CRM・ERPのデータモデル、Customer Insightsによるデータ統合、FabricとCopilot IQが開く非構造化データの世界、監査証跡・Application Insights・Entra ID、そしてAzureサービス群が支えるインフラアーキテクチャまで見てきました。改めて整理するとこうなります。

このシリーズの構成