知識（Knowledge）——エージェントは何を知っているか

エージェントが参照する情報源を定義します。SharePointのドキュメント・Webサイト・ナレッジベース・Dataverseのデータ・カスタムデータソースを「知識」として設定することで、エージェントはこれらを参照しながら回答・判断を行います。第3回で整理したFabricやDataverseのデータモデルの知識が、ここで活きてきます。

アクション（Actions）——エージェントは何ができるか

エージェントが実行できる操作を定義します。Power Automateフローの呼び出し・Dynamics 365のエンティティの読み書き・Azure Functionsの呼び出し・外部APIへのHTTPリクエストがこれにあたります。「知識」を参照して判断し、「アクション」を実行する。この組み合わせがエージェントの自律実行の核心です。

トピック（Topics）——エージェントはどう動くか

会話の流れ・分岐条件・エスカレーションのルールを定義します。「この条件が満たされたらこのアクションを実行する」「この状況になったら人間にエスカレーションする」という第2回で設計したHuman-in-the-Loopの介在ポイントが、ここで実装されます。

新規にDynamics 365を導入する際、既存システムからデータを移行するタイミングが名寄せの最大のチャンスです。ここで名寄せを徹底しておかないと、汚いデータがそのままDynamics 365に持ち込まれます。

CRM（Sales）：データインポート前にAzure Data FactoryやPower Queryで重複候補を洗い出し、マージルールを定義してからインポートします。会社名・電話番号・メールアドレス・住所の組み合わせでファジーマッチングを行い、一致度スコアが閾値を超えたレコードを重複候補としてリストアップします。

Business Central：顧客・仕入先マスタの名寄せをインポート前に行います。BCの標準機能として「重複する顧客の検索」機能があり、類似名称・同一住所・同一登録番号を検出できます。RapidStartサービスを使ったデータマイグレーション前に、Excelでの名寄せ作業を必ず挟む設計が推奨されます。

F&O（SCM・Finance）：特に重要なのがGlobal Address Book（GAB：グローバルアドレス帳）です。GABはF&Oのすべての関係者を一元管理する住所録であり、名寄せの中心となります。導入前にGABの統合ルール——どの項目を名寄せのキーとするか（法人登録番号・VAT番号・DUNS番号等）——を明確に定義しておくことが必須です。

導入後も日常的な業務の中で重複レコードは発生します。営業担当者が既存顧客を新規として登録してしまう・ECサイトからの新規登録と既存CRMレコードが重複するといったケースです。

CRM（Sales）：重複検出ルール（Duplicate Detection Rules）を設定することで、レコード作成・更新・インポート時にリアルタイムで重複を検知・警告できます。マージ後はサブレコードが非アクティブ化され、関連する活動・商談・ケースはすべてマスターレコードに統合されます。

Business Central：「重複する顧客の統合」機能でレコードをマージできます。マージ時にすべての関連トランザクション（請求書・支払い・仕訳）がマスターレコードに紐付けられます。

F&O（SCM・Finance）：GABの「Party統合」機能を使って重複するPartyレコードをマージできます。ただしF&Oのマージは影響範囲が広く——仕訳・発注・請求書・与信情報すべてに波及——するため、マージ実行前に必ず影響範囲を確認するプロセスを設けることが重要です。

CRMとERPを連携させる場合、名寄せの問題は「単一システム内の重複」から「システム間の不一致」へと複雑化します。CRMのAccountレコードとERPのCustomerレコードが同一の取引先を指しているにもかかわらず、別々のIDで管理されていると、エージェントが不整合を引き起こします。

CRMとF&O連携（Dual-write）：Dual-writeを使う場合、CRMのAccountとF&OのCustomer・VendorをリアルタイムでマッピングするDual-writeマップが設定されます。このマッピングを正しく設定するためには、まず両システムで名寄せが完了していることが前提です。

CRMとBusiness Central連携：標準のBC-CRM統合コネクタ（Integration Table Mapping）はCRMのAccountとBCのCustomerを1対1でマッピングする設計です。両システムの名寄せが完了していないと連携時にレコードが二重に作成されるという問題が発生します。

どれだけ慎重に名寄せを行っても、誤ったマージが発生することがあります。「本来別々の顧客だったのに、名前が似ていたため誤ってマージしてしまった」というケースへの切り戻し方法は製品によって異なります。

CRM（Sales）：マージ後のサブレコードは「非アクティブ」状態で保持されています。管理者が非アクティブレコードを再アクティブ化し、マージ前の状態に手動で戻す操作が必要です。CRMには「アンマージ」機能はなく、変更されたフィールドの値を手動で元に戻す作業が必要になります。エージェントが自動マージを実行する場合は、「マージ実行前に担当者の確認を必須とする」Human-in-the-Loopの設計を強く推奨します。

Business Central：マージ後の切り戻しはCRM以上に難しくなります。BCのマージはトランザクションデータにも影響するため、誤マージを検知した場合は手動でレコードを再作成し、関連トランザクションを新レコードに紐付け直す作業が必要です。

F&O（SCM・Finance）：GABのParty統合は最も慎重な運用が必要です。標準の「アンマージ」機能はなく、誤マージの影響を受けたトランザクションを特定して修正する作業は専門知識が必要です。マージ前にデータベースのバックアップを取得し、最悪の場合はバックアップからのリストアを検討できる状態にしておくことも重要です。

CRM（Sales）：監査ログ（Audit Log）を有効化することでマージ操作を含むすべてのレコード変更を記録できます。エージェントがマージを実行した場合も、エージェントのサービスプリンシパルIDが操作者として記録されます。

Business Central：変更ログ（Change Log）を設定することでレコードの変更履歴を記録できます。マージ操作・フィールド値の変更・レコードの削除がChange Log Entryテーブルに保存され、エージェントによる操作もユーザーIDとともに記録されます。

F&O（SCM・Finance）：データベースログ（Database Log）とAudit Workbenchの2つの仕組みがあります。エージェントがF&OのAPIを通じてマージ操作を実行した場合、そのAPI呼び出しのユーザーコンテキスト（サービスプリンシパル）が操作者として記録されます。

さらにどの製品においても、Azure Application InsightsとMicrosoft Sentinelを組み合わせることで、エージェントによる名寄せ・マージ操作の異常検知——「短時間に大量のマージが実行された」——をリアルタイムで監視する設計が可能です。

複雑なビジネスロジックの実装

Copilot Studioはローコード/ノーコードが設計思想であるため、複雑な条件分岐・計算ロジック・データ変換を直接実装するのには向いていません。複雑なビジネスロジックはAzure FunctionsやPower Automateに切り出し、Copilot Studioはその呼び出しだけを担当する設計が正解です。

大量データのバッチ処理

Copilot Studioはリアルタイムの会話・アクション実行には向いていますが、大量データの一括処理には向いていません。「1万件の在庫レコードを一括チェックして発注候補リストを生成する」といったバッチ処理は、Azure Data FactoryのパイプラインやAzure Logic Appsのスケジュール実行に任せるのが適切です。Power Automateはイベント駆動の軽量フローには向いていますが、エンタープライズ規模の大量データのバッチ処理にはAzureのデータ基盤側で設計することが正解です。

長時間の非同期処理

Copilot Studioからアクションを呼び出す際にはタイムアウトの制約があります。長時間かかる処理はAzure Functionsの非同期実行パターンに切り出し、処理完了後にCopilot Studioのエージェントに結果を返す設計が必要です。

複雑なUI・帳票の生成

Copilot Studioが生成できるアウトプットは基本的にテキスト・カード・ボタンといった会話UIの範囲に限られます。PDFの見積書・Excelの発注リスト・複雑なレポートの生成はCopilot Studioの守備範囲外です。Power Automateと連携してWord・Excelテンプレートを使った帳票生成を行うか、Azure FunctionsでPDF生成ロジックを実装する設計が必要です。

精緻なエラーハンドリングと冪等性の保証

エージェントが自律実行する際、途中で失敗した場合の冪等性の保証はCopilot Studio単体で行うのは難しいです。Azure Functionsのリトライポリシー・Azure Service Busのメッセージキュー・Dataverseのトランザクション管理を組み合わせて設計する必要があります。

Dynamics 365のカスタマイズとの相性

Dynamics 365に深くカスタマイズが入っている環境では、Copilot Studioのエージェントがそのカスタマイズを認識できないケースがあります。特にプラグインがトリガーされる条件とエージェントのアクションが競合する場合、想定外の動作が起きることがあります。Dynamics 365の実装者としての深い理解がここで活きてきます。

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

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

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

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

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

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

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