総勘定元帳の売掛金科目残高と、売掛金元帳（Accounts Receivable Subledger）から出力したAging / Open Transactions レポートの合計が一致しない場合、監査官は即座に手動調整仕訳の有無を確認します。

差異が発生する典型原因：元帳を経由せず直接転記された仕訳、外部連携で二重計上が発生した、特定ユーザーが期末に調整仕訳を入力したケース等が挙げられます。Database Logを事前に有効化していれば「誰がいつどのテーブル・フィールドを変更したか」を追跡できますが、ログ設定前の変更は遡及的に取得することができません。

在庫残高の勘定科目と、在庫評価レポート（Inventory Valuation Report）の評価額が一致しない状態。棚卸資産の評価方法（FIFO・移動平均・標準原価）の設定ミス、または在庫調整仕訳による人為的な操作が疑われます。

「いつ、誰が、どのデータ項目を変更したか」は、対象テーブル・フィールドを事前にDatabase Logへ設定していれば追跡できます。ただし評価ロジックの設定変更履歴（原価計算グループの変更など）は別途確認が必要です。

請求書や仕訳の計上日（Posting Date）が、納品書・受領書などの帳票に記載された日付と一致しない場合、または期末をまたいで遡及変更されている場合、収益・費用の期間帰属の操作が疑われます。

特に決算月末日をまたぐ計上日の変更はリスクシグナルとして監査で重点的に確認されます。Database Logでは「変更前の計上日」と「変更後の計上日」「変更者」「変更日時」の4つを記録できます。

Purchase Price Variance（仕入差額）は、標準原価と実際購買価格の差分です。在庫に品目が残っているにもかかわらず、PPVが大きくコストとして認識されている場合、標準原価の設定ミスまたは意図的なコスト操作が疑われます。

「誰が標準原価を変更したか」はDatabase Logで追えますが、変更のタイミングと在庫評価への影響の連鎖を分析するには、原価計算グループ・品目グループの設定変更ログとの照合が必要です。

Aging分析で90日以上滞留する未消込の売掛・買掛明細は、回収条件・顧客との合意内容・消込プロセスの問題など正当な理由がある場合も多いですが、架空債権・循環取引のリスク指標の一つとして確認対象になり得ます。特に同一金額の借方・貸方が繰り返されているパターンは監査の重点対象になります。

未消込の残高はレポートで確認できますが、「なぜ消込されなかったか」「誰が消込を保留にしたか」の証跡にはDatabase Logが必要です。

棚卸調整（在庫調整仕訳）が特定のユーザーによって定期的・高頻度に行われている場合、または1回あたりの金額が業務上説明しにくい水準である場合、監査官は「正当な業務上の理由があるか」を問います。

Database Logを対象テーブル・フィールドに事前設定していれば、記録された変更について変更者・変更日時・変更前後の値を追跡できます。ただし、在庫調整という取引そのものをDatabase Logだけで包括的に追える設計ではなく、「なぜその調整が必要だったか」の証跡（承認記録・根拠文書）は別途業務プロセスの設計が必要です。

不正送金リスクの観点では、トランザクション操作だけでなくマスターデータの変更も重要な確認対象になります。仕入先の銀行口座番号・支払先・支払条件の変更、顧客の請求先住所・与信枠の変更—これらは取引処理の変更より発見が遅れやすく、監査で優先的に確認されるリスク領域の一つです。

FOではVendor Bank Accountテーブル・Customer テーブルを、BCではVendor/Customer テーブルを Database Log / Change Logの監視対象に明示的に設定しておくことが不正防止設計の基本です。「誰が・いつ・どの仕入先の・どの口座番号を・何に変更したか」が証跡として残っていない場合、支払後に変更が行われたと主張することができなくなります。

Sales Pipelineの商談（Opportunity）が「受注」に近い状態（Proposal / Negotiation）から理由なく「失注（Lost）」に変更されるパターン。特に期末に集中して発生している場合、KPI調整や売上操作の疑いが持たれます。

Dataverse Auditingを商談エンティティに設定していれば、「誰がいつステージを変更したか」「変更前の状態は何だったか」をPre-Post Valueで確認できます。

価格表（Price List）から大幅に逸脱した割引が、承認ワークフローを経由せずに特定の商談・受注に適用されている場合。割引上限を超えた操作は内部統制の観点から問題とされます。

Dataverse AuditingでQuote / Order エンティティの価格・割引フィールドを監視対象に設定することで、価格変更の証跡が残ります。承認ワークフローのバイパスはPower Automateのフロー実行ログとの照合で確認できます。

Customer Serviceのケース（Case）が顧客の承認なく「解決済み」に変更されている、または月末・四半期末に特定のユーザーが多数のケースを一括クローズしているパターン。ファーストコンタクト解決率やAHT（平均処理時間）などKPIを意図的に操作している疑いです。

Dataverse AuditingでCase エンティティの「ステータス」「解決日時」フィールドの変更履歴を記録することで、「誰が・いつ・どのケースを解決済みにしたか」が追跡できます。

退職予定の営業担当者が離職直前に顧客・コンタクト・リードのレコードを別ユーザーに一括移管する、またはExcelに大量エクスポートするパターン。競合他社への転職に伴う情報持ち出しの典型的なリスクシナリオです。

レコードの担当者変更はDataverse Auditingで追えます。しかしExcelエクスポートの詳細（何件・どのフィールドを出力したか）は標準では記録されません。このシナリオへの対応にはMicrosoft Sentinel（Dataverse Connectorによる異常なエクスポート量の検知）またはMicrosoft Purviewのインサイダーリスク管理との組み合わせが現実的な選択肢です。

FO / ERPで問われるSoD
同一ユーザーが「仕入先登録」「発注書作成」「請求書計上」「支払承認」をすべて実行できる状態。これは支払不正の典型的な温床です。FO / BCでは役割（Security Role）の設計でこの分掌を制御しますが、プロジェクト納期優先・人手不足等の理由で一人に過剰な権限が集中しているケースが監査で頻繁に指摘されます。

CRM / Dataverseで問われるSoD
同一ユーザーが「商談作成」「割引承認」「受注確定」「顧客データエクスポート」をすべて単独で実行できる状態。特に大型商談での割引承認を自分で行い自分で確定できる権限設計は内部統制上の重大なリスクです。

FO（Finance & Operations apps）
FOでは、データエンティティのData Management（Import/Export）・OData・Microsoft Office integrationなど、利用シナリオごとに異なるセキュリティモデルでエクスポート権限を設計できます。特に顧客・仕入先などの機密データについては、必要なエンティティやアクセス経路を最小権限で設計することが重要です。設定粒度や制御範囲はシナリオによって異なるため、環境の権限構成を確認した上で設計します。

BC（Business Central）
BCでは、機能や操作に応じてPermission SetsでExcel出力関連の権限を制御できます。特定のレポートデータセットのExcel出力などには専用権限もあります。ただしBCのExport制御はFO・CRMほど粒度が細かくないケースもあるため、環境の権限構成を確認した上で設計することが推奨されます。

CRM / Dataverse
DataverseではExport to Excelが独立したSecurity Role privilege（Miscellaneous Privileges内の「prvExportToExcel」）として提供されており、この権限をロールから除外することでグリッドからのExcel出力・CSVダウンロードを禁止できます。Power Platform DLPポリシーと組み合わせることでさらに強固な設計が可能ですが、これは後編で扱います。

① ロールマトリクス（Role Matrix）
To-Be業務フローから導出した、職責×操作権限×データ範囲の対応表。「誰が・何の業務を・どの操作まで・どのデータ範囲で実行できるか」を製品ごとに定義します。

② SoD制約一覧
分離すべき職務の組み合わせと、技術的強制（システム制御）または運用統制（承認プロセス・監査）のどちらで担保するかを明示した一覧。どちらで担保するかの判断自体が、設計の重要な成果物です。

③ カスタマイズ機能の権限設計
独自実装した画面・ワークフロー・APIへのアクセス制御設計。カスタマイズと権限設計は同時に行います。後から追加した機能に権限が設定されていないことは、典型的な漏れパターンです。

④ データ範囲・列レベルの設計
BU / Company / Column Security Profileの設計。CRM / DataverseではRecord-level SecurityとColumn-level Security（Column Security Profile）は独立した仕組みであり、ロール設計とは別の成果物として管理します。

⑤ Integration / API Security Matrix
ERP間連携・Power Platform・外部API・帳票出力・BI連携など、同じデータへの複数のアクセス経路について「どのIdentityが・何のデータに・どの操作を・どの認証で行うか」を整理します。画面のロール設計だけでは防ぎきれないデータアクセスは、ここで設計します。

⑥ ユーザー・ロールライフサイクル設計
誰にいつ権限を付与し、異動・兼務・退職時にどう剥奪するかを定義します。入社（Joiner）・異動（Mover）・退職（Leaver）の各タイミングで権限を正しく管理するプロセスがなければ、過剰権限が蓄積します。本番移行後の定期棚卸しの方針も含めます。

標準のアプローチ
FOのセキュリティはPermission → Privilege → Duty → Roleの4層構造で設計します。Permissionは個々のセキュリティ保護対象（メニュー項目・フォーム・テーブルなど）へのアクセス、Privilegeは個別のタスク、Dutyは業務プロセスの一部、Roleはユーザーの職責を表します。通常はPermissionをPrivilegeにまとめ、PrivilegeをDutyにまとめ、DutyまたはPrivilegeをRoleへ割り当てます。SoD Conflictチェックは「セキュリティ > 職務の分離 > ルールの設定」から設定・検証できます。また、Task RecordingとSecurity Diagnosticsを組み合わせることで、業務シナリオに必要なセキュリティオブジェクトを分析し、特定ユーザーに不足している権限を特定できます。To-Beフローをそのままタスクとして記録し、必要な権限を診断するアプローチは、権限漏れを体系的に発見する実用的な方法です。

カスタマイズ機能への権限割り当て
X++拡張で追加したメニュー項目・フォーム・レポート・サービス操作（Entry Point）に対するアクセス権は、Privilegeとして定義し、既存または新規のDuty・Roleに組み込みます。Visual StudioのSecurity Projectで設計・管理します。カスタム機能を追加した際の権限設計の漏れは後から発見しにくいため、実装と同時に設計します。

ロール自体のカスタマイズ
標準ロールを参考に独自ロールを作成または複製し、業務責任と最小権限の原則に基づいてDuty・Privilegeを調整します。標準ロールの複製は有効な方法の一つですが、不要な権限を残さないことに加え、ライセンス要件との整合も確認する必要があります。

標準のアプローチ
BCの権限はPermission Sets（権限セット）の組み合わせで設計します。ユーザーは複数のPermission Setを持ち、それらの権限の和集合がアクセス可能な範囲になります。ライセンス／Entitlementによる利用可能範囲とPermission Setによる権限付与は別の概念であり、両方を確認してはじめて「この操作ができる」状態になります。なお、同一ユーザーに割り当てられた複数のPermission Setが同じTableDataを対象とする場合、Security Filterは制限の弱い側が有効になるため、Permission Setの組み合わせによる意図しないアクセス拡大にも注意が必要です。

カスタマイズ機能への権限割り当て
AL拡張で追加したTable・Page・Report・Codeunitには、拡張専用のPermission Setオブジェクト（.alファイル）を定義し、必要な権限を付与します。TableDataに対してはRead・Insert・Modify・Delete権限、Page・Report・Codeunitに対してはExecute権限を設定します。ALのAccessプロパティはPublic / Internalなど、オブジェクトを別モジュールから参照できる範囲を制御するものであり、ユーザーのデータ操作権限を設定するものではありません。対応するPermission Setや権限付与を設計しないままカスタム機能を追加すると、一般ユーザーが当該機能を実行できず、過剰な権限を一時的に付与して回避する事態になりかねません。

ロール自体のカスタマイズ
MicrosoftやISVが提供するSystem Permission Setは直接編集できないため、コピーしてユーザー定義のPermission Setを作成するか、ALで新しいPermission Setを定義します。既存のAL定義Permission Setに権限を追加する場合は、PermissionSetExtensionオブジェクトを使用します。PermissionSetExtensionでは権限の追加のみが可能で、既存権限の削除はできないため、過剰権限を生じさせないよう注意が必要です。ユーザー管理には、Microsoft Entra IDのセキュリティグループをBusiness CentralのSecurity Groupに関連付け、そのSecurity GroupにPermission Setを割り当てる方法が現在の推奨アーキテクチャです。従来のUser Groupを使用している環境では、Security Groupへの移行方針も確認します。

標準のアプローチ
DataverseのSecurity Roleは、テーブル権限のアクセスレベルをOrganization / Parent:Child Business Units / Business Unit / User / Noneの5段階で設計します（画面上ではGlobal・Deep・Local・Basicなどと表現される場合があります）。「どのレコードが見えるか」はロール名ではなく、アクセスレベルとBusiness Unit（BU）の階層構造で決まります。なお、Teamはアクセスレベルではなく、ユーザーをグループ化してセキュリティロールやレコード所有権を共有するための仕組みです。列レベルセキュリティ（Column-level Security。画面上のフィールドに対する制御）はロールとは独立した仕組みとして、Column Security Profileで列単位のRead / Create / Update可否を制御します。Record-level SecurityとColumn-level Securityは別の仕組みであり、ロール設計と同時にColumn Security Profileを設計しないと、ロール設計だけでは情報漏洩を防げない場面が生まれます。

カスタマイズ機能への権限割り当て
カスタムテーブルを作成しても、既存のセキュリティロールにそのテーブルの権限は自動的に追加されません。Power Appsの管理センターからセキュリティロールを開き、カスタムテーブルのCreate・Read・Write・Delete・Append・Append To・Assign・Share権限と、それぞれのアクセスレベルを設計します。特にテーブル間の参照関係では、AppendとAppend Toは関連付けの両側で必要になるため、設定漏れが起きやすい点に注意が必要です。

ロール自体のカスタマイズ
Microsoftまたはアプリケーションが提供する標準セキュリティロールを直接変更するのではなく、原則として標準ロールをコピーして独自ロールを設計します。複数ロールの権限は和集合になるため、組み合わせによる意図しないアクセス拡大が起きないよう、定期的な権限棚卸しが必要です。

① 変更ログ（Change Log / Audit Trail）
データが「何から何に変わったか」を記録する。Who / What / When / Pre-Post Value が軸。「昨日まで100万円だった請求額が今日90万円になっている—誰が変えたか？」に答える。

② 操作ログ（Activity Log / Access Log）
ユーザーが「何をしたか・何を見たか」を記録する。「そのユーザーはどのレポートをいつ実行し、どんな条件でExcelにエクスポートしたか？」に答える。データは変えていなくても、閲覧・エクスポートしたことを証跡として残す。

監査ログの文脈で頻繁に出てくるCRUDは、データ操作を整理するときによく使われる4分類です。Create（作成）・Read（閲覧・取得）・Update（更新）・Delete（削除）の頭文字を取ったものです。

変更ログは主にデータの作成・更新・削除など「データが変わった操作」を対象とします。一方で操作ログ・活動ログでは、Read（データを変更しない閲覧・取得）やExport操作も対象になります。「誰が見たか」のRが最も記録しにくく、かつ情報漏えい・不正アクセスの文脈で最も問われやすい領域です。

Dataverse AuditingはCreate / Update / Deleteに加え、Assign・Share・セキュリティロール変更などの変更イベントを対象とします。Retrieve / ExportはDataverse Auditing単体では対象外であり、Read/Exportの追跡にはActivity Loggingが必要になる—という構造は、このCRUDの分類を理解すると自然に腑に落ちます。

最も重要な変更ログ機能。テーブル・フィールドを指定して、Insert / Update / Delete / Rename の操作を記録します。

設定場所：システム管理 > 設定 > データベースログの設定

記録内容：変更日時 / ユーザー / テーブル・フィールド名 / 変更前の値（Pre Value）/ 変更後の値（Post Value）。取引先・銀行口座・与信枠など、監査上重要なテーブル・フィールドを選択して有効化します（例：VendBankAccountテーブル、CustTableのCredit Limitフィールドなど）。ユーザー権限の変更については、Security Governance等のセキュリティ監査機能とあわせて確認します。広範囲に有効化するとパフォーマンスやデータ量への影響が大きくなり得るため、対象テーブル・フィールドの絞り込みが前提です。

⚠️ 重要：Database Logは「事前に設定したテーブル・フィールドの変更」のみを記録します。すべての取引・自動バッチ処理を包括的に追跡する設計ではありません。また、ログを有効化した時点以降の変更しか記録されず、設定前の過去データを遡及的に取得することはできません。監査対応は監査が来てからログをONにする仕事ではない—この前提が導入・運用設計の出発点です。

ユーザーのサインイン・アクセス活動の記録。Finance and Operationsでは、ユーザー活動情報をUser Log・Security Governanceレポート・テレメトリ等の組み合わせで確認します。製品バージョンや有効化機能により確認場所が異なるため、現行環境の構成を確認する必要があります。なお旧来の「システム管理 > 照会 > ユーザーログ」画面はレガシー機能として位置づけられており、2026年時点ではUser Log V2（Preview）が提供されています。User Log V2は有効化後のサインイン情報を記録するため、過去のデータが自動的に移行されるわけではありません。

確認場所：Microsoft Entra サインインログ、Security Governance関連レポート、または現行版のUser Log V2（Preview）

セキュリティロール・権限の変更履歴を記録します。「このユーザーにいつ管理者権限が付与されたか」を追うための機能です。

確認場所：システム管理 > セキュリティ > 監査証跡

⚠️ レポートの実行ログ—ERレポートはER実行ログ（標準）で追跡可能。SSRSはApplication Insights連携が必要。どちらもフィルター条件の詳細は要X++拡張
❌ レポート実行時のフィルター条件（抽出期間・会社コード・勘定科目の指定内容）—ER・SSRS問わず要X++拡張
⚠️ エクスポート操作の詳細—DMFエクスポート（PU69+）はApplication Insights Telemetryで対応可能。ad-hocグリッドエクスポートは要X++拡張
❌ エクスポートした行数・フィールド一覧—ad-hocは要X++拡張
⚠️ 画面の閲覧ログ—フォームレベルはForm Run Telemetry → Application Insightsで取得可能。レコード単位の閲覧証跡は要X++拡張
❌ データグリッド上のフィルター・並び替え操作

BCの中核的な変更追跡機能。テーブル・フィールド単位で Insert / Modify / Delete を記録します。

設定場所：管理 > Change Log Setup。テーブルごとに「All Fields」または「Some Fields」を選択して監視対象を絞り込みます。

記録内容：変更日時 / ユーザーID / テーブル名 / フィールド名 / 変更前の値 / 変更後の値。Change Log Entriesページで確認できます。取引先・品目・単価・ユーザー権限など、業務上の重要データを対象テーブルとして選択することが基本設計です。

⚠️ 重要：Change Logは「Change Log Setupで事前に設定したテーブル・フィールドの変更」のみを記録します。有効化した時点以降の変更のみが対象となり、設定前の過去データを遡及的に取得することはできません。監査対応は監査が来てからログをONにする仕事ではない—この前提が導入設計の出発点です。

📝 名称メモ：Microsoft Learn のドキュメントページタイトルは “Auditing changes”（2026年6月更新）に変わっていますが、機能名は引き続き「Change Log」のままです（Change Log Entries / Change Log Setup）。「Audit Log」への正式な名称変更は行われていません。

BCはAzure Application InsightsへのTelemetry送信機能を標準で持ち、操作系テレメトリを取得・分析しやすい製品です。レポート実行・ページビュー・セッション・ユーザー・AL Extension呼び出し・連携・権限エラー等のテレメトリを取得・分析できます。

設定場所：Business Central admin centerでApplication Insights接続文字列を設定。Microsoft公式ドキュメントでは、レポート実行のTelemetryからユーザー・会社・レポート定義等を分析する例も提供されています（Analyze financial report usage telemetry）。

KQLでの分析・Power BIへの接続・Microsoft Sentinelとの連携も可能。Change Logが「何が変わったか」を記録するのに対し、Application Insightsは「誰が何を使ったか」を分析する補完的な基盤として位置づけられます。

BCにはChange Logとは別に、Sensitive Field Monitoringの概念があります。仕入先・顧客の銀行口座番号、支払条件、与信枠など、特に監査・不正防止上の重要フィールドを重点的に監視し、変更時にアラート・通知を発するよう設計できます。

Microsoftはこのアプローチを「全フィールドに対して重いChange Logを取る」のではなく「重要フィールドを高精度で監視し、それ以外はTelemetryで広く見る」という設計思想として説明しています。パフォーマンスへの影響を最小化しながら不正防止上のリスクをカバーできる点で、Change Log単独より実用的な構成になります。

⚠️ レポートの実行（どのレポートが実行されたかはRT0006 Telemetryで追跡できる）
❌ Request Pageで指定された具体的なフィルター条件は標準Telemetryでは残らない
❌ ExcelへのエクスポートのフィールドリストとExport行数
❌ レコード単位の閲覧証跡（どの顧客・どの仕入先レコードを開いたか）
❌ APIコール経由のデータ取得ログ（Application Insightsで一部補完可能）

DataverseはFO・BCと比べて最も細かい粒度での監査設定が可能です。環境レベル・テーブル（エンティティ）レベル・フィールドレベルの3段階で有効化します。

設定場所：Power Platform管理センター > 環境 > 監査設定、またはソリューションエクスプローラー内のテーブル設定。

記録内容：Create / Update / Delete、Assign（担当者変更）、Share（共有権限変更）、セキュリティロール変更等をカバー。Who / What / When / Pre-Post Valueが記録されます。なお、Dataverse Auditing自体はRetrieve（Read）やExport操作を対象としていません。一部のアクセス関連イベントは監査対象にできますが、一般的な意味での「全閲覧ログ」を標準で網羅的に取得する設計ではありません。Read / Export等の活動については、別途Dataverse / model-driven apps activity loggingを有効化し、Microsoft Purviewで確認します。

確認場所：各レコードの「監査履歴」タブ、または監査の概要ビュー（Audit Summary View）で横断確認。Microsoft Purviewの監査ログ検索とも連携します。

⚠️ 重要：Dataverse Auditingは「環境・テーブル・フィールド単位で事前に有効化した対象」のみを記録します。有効化した時点以降の変更のみが対象となり、設定前の過去データを遡及的に取得することはできません。監査対応は監査が来てからログをONにする仕事ではない—この前提が導入設計の出発点です。

Microsoft 365コンプライアンスポータル（Microsoft Purview）の統合監査ログには、Power Appsのアクティビティ（アプリの起動・共有・コネクタへのアクセス）や、Power Automateのフロー実行ログが記録されます。

検索場所：Microsoft Purview > 監査 > 監査ログの検索。「Dataverse」「Power Apps」「Power Automate」のアクティビティカテゴリでフィルタリングできます。ライセンス要件は監査機能・保持期間・ユーザーのライセンス構成によって異なります。Microsoft Purviewでの長期保持には追加のライセンス要件があります。

❌ Retrieve / Read（閲覧）操作：Dataverse Auditing単体では対象外。Activity Loggingを別途有効化することで対応可能
❌ Export操作：Dataverse Auditing単体では対象外。Activity Logging / Microsoft PurviewでExportToExcelイベントを記録可能（ただし「何件を・どのフィールドで」という詳細粒度には制約がある）
⚠️ エクスポート時のフィルター条件：継続的な監視・証跡管理にはPurview＋カスタマイズが必要。なお事後の一回性調査に限り、CSVエクスポート後にAuditData列のJSONを解析→Queryプロパティ（FetchXML）を取得することでフィルター条件を読み取れる場合がある（詳細は後編参照）
❌ キャンバスアプリ上のフィルター操作・ボタン操作等の詳細
❌ Power Apps キャンバスアプリ上のすべての操作詳細（フォーム遷移・ボタン操作等）

標準機能で応答できる範囲
・データ変更監査（誰が・何を・いつ・変更前後の値）
・管理者アクティビティ監査（権限変更・設定変更）
・ユーザーサインイン（Microsoft Entra ID経由）
・CRMのRead / Export操作（Activity Logging / Purview）
・FOの閲覧ログ（フォームレベル）—Form Run Telemetry → Application Insights連携で対応可能
・BCの閲覧ログ（ページレベル）—Page View Telemetry → Application Insights連携で対応可能

標準では応答できない領域（ギャップ）

・レポート名—どのレポートが実行されたか
・エクスポートフォーマット—Excel・CSV・PDF等のどの形式でダウンロードされたか
・フィルター条件—どのデータ範囲を指定してエクスポートしたか
・行数—何件のレコードがエクスポートされたか（大量持ち出しの検知）

これらのギャップに対してカスタム実装でカバーするアプローチは存在します。FO ではX++イベントハンドラ、BC ではAL Extensionのカスタムテレメトリ、CRM ではPurview＋カスタマイズを組み合わせることで、フィルター条件を含むエクスポート操作の証跡を記録できます。後編でそれぞれの実装アプローチを整理します。

FO：X++による拡張でレポート実行イベントをフックしてカスタムログテーブルに書き込む。BCではAL Extensionでページ・レポートのトリガーポイントにカスタムテレメトリを実装する。CRM/DataverseではPluginやCustom APIでデータアクセスイベントを捕捉する。

メリット：ログ内容を自由に設計できる、システム内で完結する。デメリット：開発・テスト・保守コストが発生する。製品アップデートへの追従が必要。ログの保存先（DB肥大化）設計も別途必要。

Microsoft SentinelはD365・Microsoft 365・Microsoft Entra IDの各ログコネクタを持っています。Dynamics 365 Connector・Microsoft Purview Connectorを使ってログをSentinelのLog Analytics Workspaceに集約し、KQLクエリによる高度な分析・アラートが可能になります。

重要な前提：SentinelはD365が「出力したログ」を集約・分析するプラットフォームです。D365が出力していないログ（レポートフィルター条件など）をSentinelが独自に生成することはできません。Sentinelの価値は、D365・Entra ID・M365の複数ログを横断して相関分析できる点にあります。「このユーザーが大量エクスポートを行った翌日にEntra IDでの異常なサインインがあった」といったシナリオの検出が得意領域です。

メリット：複数システムのログを一元管理・横断分析できる、UEBAによるアノマリ検出。デメリット：Sentinelライセンス費用（データインジェスト量に比例）、運用するSOC体制が前提。「ログを見る人」と「アラートに対応する人」の体制整備が必要。

BCはApplication Insightsへのテレメトリ送信をadmin centerで標準設定できる系統です。AL Extensionでカスタムテレメトリを追加することで、レポート実行・フォームアクセス等の操作ログをApplication Insightsに記録できます。FOもForm Run Telemetry等でApplication Insightsへの接続は可能ですが、BCのようにadmin centerで完結する統合設定はなく、X++による拡張実装が主体になります。FOでは複数システムのログを横断分析したい場合はSentinel（アプローチ②）との組み合わせが主流です。

KQLでの分析、Power BIへの接続、Microsoft Sentinelとの連携も可能。カスタム開発とクラウドログ基盤の組み合わせとして、BCでは最も実用的なアプローチの一つです。

CRM / Dataverse 固有のアプローチです。Activity Loggingを有効化することで、Read（閲覧）・Export（エクスポート）・Assign・Share等の操作ログをMicrosoft Purviewに送信できます。Production環境ではPurviewの監査ログとして集約・保持され、コンプライアンスセンターから検索・エクスポートが可能です。

カバー範囲と制約：エンティティ単位の閲覧・エクスポートは記録できますが、レコード単位の詳細（どのレコードIDを参照したか）やフィルター条件（どの条件で絞り込んだか）の記録には粒度の制約があります。これらの詳細はPlugin拡張と組み合わせることで補完できます（→ アプローチ①との併用）。

メリット：カスタム開発不要でCRMの操作ログを取得できる唯一の標準アプローチ。Purviewのコンプライアンス機能（保持ポリシー・eDiscovery）と統合できる。デメリット：Microsoft Purview / Power Platformのライセンス要件・保持期間要件を事前に確認。大量ログ生成によるストレージ・検索性能への影響を考慮した設計が必要。

D365 3系統 監査ログ現状地図（2026年9月時点）