エージェントを信頼できるか—ログ・監査・コンプライアンスの設計｜第5回
こんにちは。室長こと、吉島良平（Microsoft MVP for Business Applications | Microsoft Regional Director）です。
皆さん、いかがお過ごしでしょうか？ 実はこのシリーズ、夜中にブログを書き上げて、朝6時に仮眠をとり、9時半には着席して業務をしているという、なかなかのペースで進んでいます。「室長、寝なくて大丈夫なの？」とよく心配していただくのですが、学生時代から研究室にこもって夜通し作業するのが当たり前だったので、すっかり慣れっこです。週末はもう少しゆっくり寝ていますので、ご心配なく（笑）。読んでくださっている皆さんへの感謝を胸に、今日も元気に第5回をお届けします。
さて、ここまでのシリーズで「何をするエージェントを作るか」「どこに人間を置くか」「どのデータを使うか」「どうやって組み立てるか」を整理してきました。
実はこのシリーズを書くモチベーションのひとつになったのが、Directions ASIA 2026の2日目キーノートで紹介された「Building IT Compliance Agent」です。マイクロソフトの製品開発チームが紹介したこのコンセプトは、エージェントが自律的に動く世界において「コンプライアンスをどう担保するか」という問いを正面から扱っています。目の前でそれを見せられたとき、「これはDynamics 365の実装者・意思決定者が今すぐ理解しなければならないテーマだ」と確信しました。パッケージビジネスも、スクラッチ開発も、サービスに関わる収益確保は大きな課題になっていく事を再認識しました。同時に、そのために我々はどのような働き方をすべきか、そしてAgentic Engineeringのあるべき姿について、大きなヒントを得る機会になりました。
さて、本題に戻ります。大事な問いがまだ残っています。「そのエージェント、信頼できますか？」——今日はこの問いに向き合います。
Series #05 — Agentic Engineering × Dynamics 365
エージェントを信頼できるか
ログ・監査・コンプライアンスの設計——説明責任に耐えるエージェントアーキテクチャ
第5回
Dynamics 365
Compliance
Microsoft Purview
Sentinel
ここで考えるべきは、「ログを残すべきかどうか」ではありません。
エージェントが誤った判断をした場合、何が起きるかです。
例えば、誤った発注を行う、誤った価格で見積を出す、誤った顧客対応を実行する。これらは単なるシステムエラーではなく、業務そのものの失敗になります。
エージェントは「実行主体」です。だからこそ、その判断の過程と結果が追跡できなければ、責任の所在も説明できません。
ログや監査は付加機能ではなく、「運用するための前提条件」になります。
エージェントが自律的に動くということは、「誰が何を判断したか」が見えにくくなるということでもあります。人間が判断していれば「池山さんがこの発注を承認した」「河内さんがこの見積を送った」という明確な責任の所在があります。しかしエージェントが自律実行した場合、「なぜそうなったのか」「誰が責任を持つのか」を説明できる仕組みがなければ、組織として信頼できるシステムとは言えません。これはコンプライアンスの問題であり、ガバナンスの問題であり、そして組織の信頼の問題です。エージェントを「信頼できる存在」にするためには、動いた記録を残すこと・異常を検知すること・説明責任を果たせる設計にすること——この3つが必要です。Microsoft Purview・Microsoft Sentinel・Agent 365のガバナンス機能が、このテーマの中心に出てきます。
Why audit design matters
なぜエージェントの監査設計が重要なのか
従来のシステムでは、「人間が操作した」という事実がそのまま監査証跡になっていました。ERP・CRMへのログインはEntra IDで管理され、レコードの変更は変更ログに残り、承認は承認フローの記録として残ります。「誰が・いつ・何をしたか」は比較的追いやすい設計になっていました。
エージェントが自律実行する世界では、この構造が変わります。エージェントは24時間・365日・人間の操作なしに動きます。発注を自動実行し、見積を自動送付し、仕訳の下書きを自動生成します。このとき「なぜエージェントはこの判断をしたのか」「どのデータを参照して・どのルールに従って・どのアクションを実行したのか」について、説明できなければ、内部監査・外部監査・コンプライアンス対応のいずれにも耐えられません。
内部監査への対応
「このエージェントが実行した発注は、購買ポリシーに従っていたか」「承認フローを正しくトリガーしたか」「閾値の設定は適切だったか」——これらを内部監査担当者が確認できる証跡が必要です。
外部監査・規制対応
会計処理を担うエージェント（Bank Reconciliation・Payable Agent等）が実行した操作は、会計監査人が「このシステムは信頼できるか」を判断する材料になります。J-SOX・IFRS・各国の会計規制に対応した監査証跡の設計が求められます。
インシデント発生時の原因調査
エージェントが誤った判断をした場合——誤発注・誤送付・誤った与信判断——「なぜそうなったか」を迅速に特定して修正するためのログ設計が必要です。原因がわからなければ再発防止もできません。
Dynamics 365 — Full landscape
Dynamics 365の全体像を改めて整理する——技術基盤の視点から
このシリーズでは「CRMとERP」という表現を使ってきましたが、Dynamics 365 2026 wave 1の全体を見渡すと、実際にはより多くのアプリケーションが存在します。監査・コンプライアンスの設計を正確に行うためにも、技術基盤の視点から整理しておきましょう。
| 製品 | コア基盤 | Dataverseとの関係 |
|---|---|---|
| Finance / SCM / Commerce | F&O独自基盤（旧Dynamics AX） | バーチャルテーブル・Dual-writeで連携 |
| Human Resources | F&O→Dataverseへ移行中 | F&Oを起点としつつ、Dataverseへの移行が進行中の構成 |
| Business Central | NAV独自基盤（AL） | Integration Table Mappingで双方向同期（BC28で大幅強化） |
| Project Operations | ハイブリッド（移行中） | UIや業務アプリケーションはDataverse上で動作し、コアな業務処理はF&Oが担うハイブリッド構成（Dual-writeによる同期） |
| Sales / CS / Contact Center / Field Service | Dataverse | ネイティブ |
| Customer Insights – Data / Journeys | Dataverse | ネイティブ |
まず、ここで重要になるのが、Entra IDを中心としたセキュリティ基盤と、それを支えるMicrosoft 365のライセンス体系です。
E3が基本的な認証・アクセス制御の土台を提供する一方で、E5ではデータ保護、監査、コンプライアンス、リスク検知といった機能が強化され、分散したデータとエージェントの動きを統制するための前提が整います。
実際には、このレベルの統制を前提とする場合、E5相当のセキュリティが事実上の前提となります。
さらにE7では、エージェントを前提としたセキュリティとガバナンスが拡張されます。
そして、その上位に位置するのがAgent 365です。Agent 365は、個々のエージェントを個別に管理するのではなく、組織内で動作する全エージェントの状態、権限、振る舞いを統合的に可視化・統制するための基盤として機能します。
つまり、各アプリケーションは独立したシステムではなく、Dataverseを中心とした構造の中で役割分担される存在へと変わり始めています。
Microsoft security landscape
Microsoftセキュリティ＆コンプライアンス製品の全体像
エージェントが自律的に動く環境のセキュリティ・コンプライアンスを設計するとき、Microsoftは複数の製品を組み合わせた多層防御の仕組みを提供しています。まず各製品の役割を整理しておきましょう。
| 製品 | 役割 | エージェント文脈での使い方 |
|---|---|---|
| Microsoft Entra ID | ID・認証・認可の基盤 | エージェントのID管理・条件付きアクセス・SSO・PIM |
| Microsoft Defender | 脅威検知・エンドポイント保護 | エージェントが呼び出す外部API・エンドポイントへの攻撃検知 |
| Microsoft Purview | データガバナンス・コンプライアンス・情報保護 | 監査ログの長期保存・コンプライアンスレポート・データ分類 |
| Microsoft Sentinel | SIEM・SOARによるセキュリティ監視 | エージェントの異常動作検知・インシデント対応の自動化 |
| Microsoft Intune | デバイス管理・モバイル管理 | 承認フローで人間が介在する際のデバイスコンプライアンス |
| Azure Policy | リソースのガバナンス・コンプライアンス強制 | Azureリソース（Functions・Logic Apps等）への設定強制 |
| Microsoft Compliance Manager | コンプライアンス評価・リスク管理 | J-SOX・GDPR・ISO27001等への準拠状況の可視化 |
ラグビーで例えると
Entra IDがチームのルールブック（誰がどこに立てるか）、Defenderが最前線のタックル、Purviewが試合の記録係、Sentinelが監督のビデオ分析、Intuneが選手の体調管理、そしてCompliance Managerがリーグの審判——それぞれが役割を分担して全体を守ります。
Microsoft Entra ID——すべての認証・認可の起点
Copilot Studioで作成したエージェントはEntra IDのサービスプリンシパルまたはマネージドIDとして登録されます。「このエージェントはDynamics 365 CRMのOpportunityテーブルを読めるが書けない」という細かい権限設計がRBACで実現できます。Privileged Identity Management（PIM）を使うことで、エージェントの設定変更・閾値の修正といった高権限操作を「必要なときだけ・一時的に・承認を経て」付与する設計ができます。
Microsoft Defender——脅威からエージェントを守る
Defender for Cloud Appsは「エージェントが通常とは異なる時間帯に大量のレコードにアクセスしている」「エージェントが想定外の外部APIを呼び出そうとしている」といった異常をリアルタイムで検知します。Defender for Identityはエージェントのサービスプリンシパルに対する不正アクセス試行・権限昇格の試みを検知します。Defender for CloudはAzure Functions・Logic Appsといったエージェントが依存するAzureリソースへの脅威を検知・防御します。
Microsoft Purview——データガバナンスとコンプライアンスの中枢
Microsoft Sentinel——エージェントの異常を検知するSIEM
Sentinelは機械学習を使って「通常とは異なるパターン」を検知します。エージェントに関してはこういった異常を検知できます。
SentinelのSOAR機能により、異常を検知したとき「エージェントのアクセスを一時停止する」「担当者にTeamsでアラートを送る」「Dynamics 365の関連レコードにフラグを立てる」といった対応を自動実行できます。
Audit design by platform
各系統の監査・コンプライアンス設計
技術基盤の整理ができたところで、各系統の監査・コンプライアンス設計を見ていきます。エージェントが自律実行した操作が「説明責任に耐えられるか」という観点で整理します。
CRM系（Dataverse基盤）の監査設計
Dataverse基盤のCRM系アプリ（Sales・Customer Service・Contact Center・Field Service）は、Dataverseの監査ログ機能を共通で使います。エンティティ・フィールド単位で監査を有効化でき、エージェントが操作した場合はエージェントのサービスプリンシパルIDが操作者として記録されます。「池山さんが変更した」ではなく「Sales Agentが変更した」という形で証跡が残ります。監査ログはMicrosoft Purview Auditと連携することで長期保存・高度な検索・コンプライアンスレポートが実現できます。
ERP（F&O系）の監査設計
F&O系（Finance・SCM・Commerce）は会計系システムとして監査機能が最も充実しています。
ERP（Business Central系）の監査設計
Business Centralの監査機能は変更ログ（Change Log）とFinancial Auditingの2本柱です。
CDP・マーケティング系の監査設計
Customer Insights – Data（CDP）とCustomer Insights – Journeys（デジタルマーケティング）はDataverse基盤であるため、CRM系と同様の監査ログ機能を使います。ただしCDPが処理する個人データにはGDPRの観点から特別な注意が必要です。「誰の個人データを・いつ・どのように処理したか」の記録が求められます。Microsoft Purview Information Protectionと連携して、個人データに機密ラベルを自動付与し、データ保持ポリシー・アクセス制御を自動適用する設計が推奨されます。
Application Insights & Power BI
追跡できないオペレーションとAzure Application Insightsによる補完
Dynamics 365の標準監査ログは「何が変わったか」を記録します。しかし実装の現場では、標準監査ログでは追跡できないオペレーションが必ず存在します。
標準監査ログでは見えにくいもの
・Copilot Studioのエージェントが「なぜその判断をしたか」という推論プロセス
・Azure Functionsの呼び出し回数・処理時間・エラー率
・Logic Appsのフロー実行の成功・失敗・リトライの詳細
・バーチャルテーブル経由のERPデータ参照の頻度とパターン
・エージェントが承認フローをトリガーしてから承認者が応答するまでの時間
・マルチエージェントアーキテクチャの全体的な処理フロー
・エージェントが閾値の判定を行った際の入力値と判定結果の詳細
これらへの対策は、Azure Application InsightsはAzureのアプリケーション監視サービスです。Azure Functions・Logic Apps・Azure Web Appsからテレメトリデータをリアルタイムで収集し、エージェントが呼び出す各処理の詳細を記録します。
トレース（Trace）
エージェントの処理フローの各ステップの実行記録。「バーチャルテーブルで在庫データを取得した」「原価が閾値を超えたため承認フローをトリガーした」という一連の流れをトレースとして記録します
カスタムイベント（Custom Event）
実装者が独自に定義したビジネスイベント。「発注金額が100万円を超えたため承認フローに移行した」「与信超過を検知した」といったビジネス上の重要な判断ポイントをカスタムイベントとして記録できます
依存関係（Dependency）
エージェントが呼び出した外部サービス（Dynamics 365 API・外部与信API・Azure AI Foundryのモデル等）の呼び出し時間・成功・失敗が記録されます
メトリクス（Metrics）
エージェントの処理時間・呼び出し回数・エラー率を時系列で記録します。第2回で設計した閾値の継続的チューニングの判断材料になります
Power BIによる可視化——エージェント稼働状況ダッシュボード
Application Insightsが収集したテレメトリデータをPower BIで可視化することで、実装者・運用者・経営者それぞれに合わせたエージェント稼働状況ダッシュボードが実現できます。
2つの仕組みの使い分け
Dynamics 365の標準監査ログは「何が変わったか」の記録——コンプライアンス・内部統制・外部監査への対応に使います。Azure Application Insightsは「なぜそうなったか・どう動いたか」の記録——運用監視・パフォーマンス改善・インシデント対応に使います。この2つは補完関係にあります。
Building IT Compliance Agent
Building IT Compliance Agent——エージェントがコンプライアンスを担う
Directions ASIA 2026の2日目キーノートで紹介された「Building IT Compliance Agent」は、このシリーズを書くモチベーションのひとつになったコンセプトです。エージェントが自律的に動く世界において、「コンプライアンスの監視・検知・対応」そのものをエージェントが担うという考え方です。
従来のコンプライアンス管理はこういう流れでした。システムが操作を実行する→監査ログに記録される→定期的に監査担当者がログをレビューする→問題を発見する→対応する。このサイクルは週次・月次で回っており、問題の発見から対応までにタイムラグが生じていました。Building IT Compliance Agentはこのサイクルをリアルタイムに変えます。
リアルタイムモニタリング
Compliance AgentはDynamics 365の監査ログ・Application Insightsのテレメトリ・Microsoft Sentinelのセキュリティイベントをリアルタイムで監視します。「購買ポリシーに違反する発注が実行された」「与信限度額を超えた受注が承認フローをスキップして登録された」「短時間に大量のマージ操作が実行された」といった異常をリアルタイムで検知します。
自動調査と根本原因分析
異常を検知したCompliance Agentは、Application InsightsのトレースデータとDynamics 365の監査ログを横断的に調査し、「なぜこの異常が発生したか」を自動で分析します。「閾値の設定が誤っていた」「エージェントのロジックに設計ミスがある」「不正アクセスの可能性がある」といった根本原因を特定し、担当者にレポートします。
自動対応とエスカレーション
根本原因が特定されたら、Compliance AgentはMicrosoft SentinelのSOAR機能と連携して自動対応を実行します。「問題のあるエージェントのアクセスを一時停止する」「影響を受けたレコードにフラグを立てる」「関係者にTeamsでアラートを送る」「コンプライアンス担当者に詳細レポートを送付する」といった対応をエージェントが自律実行します。
Compliance AgentにもHuman-in-the-Loopを設計する
Compliance Agent自身も第2回で整理したHuman-in-the-Loopの原則に従って設計する必要があります。「コンプライアンス違反の検知」と「軽微な異常への自動対応」はCompliance Agentが自律実行し、「エージェントの停止」「大規模なデータ修正」「外部への報告」は必ず人間の判断を経る設計が重要です。コンプライアンスを監視するエージェント自身が暴走しないよう、Compliance AgentにもガードレールとHuman-in-the-Loopを設計する——これがAgentic Engineeringの設計原則が再帰的に適用される面白いポイントです。
Summary
まとめ
今回はエージェントを「信頼できる存在」にするための監査・コンプライアンス設計を、Dynamics 365の全アプリ横断で見てきました。改めて整理するとこうなります。
このような構造を前提とする場合、E5相当のセキュリティを基盤とすることが実務上の前提となり、さらにエージェント活用を見据えたE7の導入を検討することが重要になります。
このシリーズの構成
Agentic Engineeringとは何か——「作る対象」から「統率する存在」へ
どこに人間を置くか——Human-in-the-Loopの設計原則
エージェントはデータをどう使うか——CRMとERPのデータモデル
エージェントを組み立てる——Copilot Studioで何ができて何ができないか
エージェントを信頼できるか——ログ・監査・コンプライアンスの設計 ← 本記事
CRMとERPをまたぐエージェント——統合設計の全体像
これからのDynamics 365エンジニアに何が求められるか
次回は「CRMとERPをまたぐエージェント」をテーマに、これまでのシリーズで積み上げてきた設計原則・データ設計・実装パターン・監査設計を統合し、エンドツーエンドのエージェントアーキテクチャとして俯瞰します。
以上、室長でした。
- dx365jp
24年ほど、Microsoft Dynamics ERP（NAV/AX)＋CRMの導入コンサルティングに従事し、日本を含む34か国において導入コンサルティングを経験してきました。グローバル環境における“プロジェクト”と“マーケティング”を生業としております。
最近は、【CRM/MKTG（攻めのDX）⇔ ERP（守りのDX）】＋【ローコード】というDX365な活動に奮闘中です。Microsoft Dynamics 365 ビジネスで地球を90周中です。＃DX365 #DynamicsIoT
Microsoftの運営する外部技術者グローバル組織「Microsoft MVP（*日本165名/世界3023名）・ Microsoftのトラスティッドアドバイザーである「Microsoft Regional Director （*日本4名/世界189名）」として、複数のITコミュニティーにて活動中。（*2022/07/06時点）
プロフィールはこちら→bit.ly/Dynamics365JP
- 監査対応はなくなる？｜取引と責任を繋ぐAIエージェントの世界 2026年6月14日
- 請求も、発注も、提案も消えない、それでも“仕事をするのは人ではなくなる？” ｜ Dynamics 365が変える企業間取引の新しい当たり前 2026年6月13日
- AIはどこまで任せ、どこで止めるのか？｜Business Centralに実装された“境界設計”の正体 2026年6月10日
- Microsoft自社開発MAI、7モデル一挙発表—「D365（CRM/ERP）× Frontier Tuning」が描く、ちょっと面白い未来 2026年6月8日
- Microsoft Build 2026｜Dynamics 365 実装者・アーキテクトが押さえるべき変化 2026年6月6日