問い①　Agentは「何を根拠に」その操作を行ったか
Agentが仕入先への発注書を送信した。その判断の根拠は何か。どのデータを参照し、どのルールを適用し、どの条件が満たされたと判定したのか。人間の操作と異なり、Agentの「理由」はシステムが明示的に記録しない限り証跡に残らない。

問い②　Human-in-the-Loop はどこにあったか
承認ステップは存在したか。それは形式的なものではなく、実質的な確認を伴うものだったか。承認者はAgentが提示した情報の何を確認し、何を承認したのか。Agentが単独で完結した処理と、人間が関与した処理の区別が証跡に残っているか。

Layer 1 / 1+　D365標準ログ＋標準テレメトリ
FO: Database Log / Security Change Log / User Log V2 / Form Run Telemetry / DMF Telemetry（PU69+）
BC: Change Log / Application Insights Telemetry / Sensitive Field Monitoring / Page View Telemetry / RT0006
CRM: Dataverse Auditing / Activity Logging（Purview転送）/ Power BIアクティビティログ
役割: 個別システムのデータ変更・権限変更・フォーム閲覧・レポート実行を記録する一次証跡。

Layer 2　Microsoft Purview—コンプライアンスと保護の中枢
Purview Audit（Standard / Premium）/ Compliance Manager / Information Protection / DLP
役割: M365・Dataverse等の操作ログを統合保管（FO・BCのログは別途連携が必要）。コンプライアンス評価・スコア算出。データ分類とラベル付け。保持ポリシーと監査ログ保全機能。

Layer 3a　Microsoft Sentinel—横断分析・脅威検知・UEBA
D365コネクタ / Microsoft Entra IDコネクタ / M365コネクタ / UEBA / KQLアラートルール
役割: 複数システムのログを集約・相関分析。異常行動の検出。セキュリティ監視とコンプライアンス監視の融合。

Layer 3b　Microsoft Fabric—長期保管・分析・AI活用
OneLake / Fabric Lakehouse / Power BI / Real-Time Intelligence
役割: 長期保管設計・コスト最適化（保持期間・不変性ポリシーは別途構成が必要）。大量ログのバッチ分析。監査レポートの自動生成。

取得できる情報
Azure Application Insightsを環境に設定すると、FOはフォームへのアクセスを自動的にテレメトリとして記録します。「どのユーザーが・いつ・どのフォームを開いたか」「フォームの読み込み時間」等を追加コードなしに取得できます（クローズイベントは別途）。例えば、仕入先マスター（VendTable）フォームを誰がいつ開いたかをKQLで確認できます。

設定方法
FO環境では System administration → Monitoring and Telemetry parameters からApplication Insights接続文字列を設定します（旧LCS方式から移行済み）。FastTrack on GitHubに標準ダッシュボードが公開されており、接続後すぐに可視化できます。

⚠️ フォームレベル（Form Run）は記録できますが、特定レコードを見たかどうか（レコード単位の閲覧ログ）は標準では取得できません。仕入先マスターフォームを開いたことは分かっても、どの仕入先レコードを見たかは別の話です。レコード単位の閲覧ログには、後述のX++カスタム拡張が必要です。

取得できる情報
Platform Update 69/70前後（アプリバージョン10.0.45/10.0.46以降—有効化バージョンはMicrosoft Learnで確認推奨）から、DMFジョブ（Data Management Framework—エンティティのエクスポートジョブ）の実行がApplication Insightsに自動記録されます。シグナルは3種類: DMFJob Start（ジョブ開始: エンティティ名・ジョブID・実行ユーザー）、DMFJob End（ジョブ終了: 処理件数・実行時間）、DMFJob Status（成功/失敗の状態）。

監査での使いどころ
「誰が・いつ・どのエンティティを・何件エクスポートしたか」をDMFジョブ単位で追跡できます。大量エクスポートの異常検知（例: 深夜に全顧客データをエクスポート）のSentinelアラートに活用できます。

⚠️ DMFジョブ（定型エクスポート）は記録されますが、フォーム上の「Excelで開く」ボタン（ad-hocエクスポート）はDMFを通らないため別途X++拡張が必要です。フライト設定（DMFTelemetryConfigurationFlight / DMFEnableAppInsightsLogsAndErrors）はデフォルト有効ですが、対象バージョン未満の環境ではアップデートが必要です（バージョンはMicrosoft Learnで確認推奨）。

SSRSのExecutionLog3とは
SQL Server Reporting Services（SSRS）は標準でExecutionLog3ビューを持ち、「レポートパス・実行ユーザー・開始/終了時刻・行数・バイト数」を最大60日間保持します。オンプレミスのSSRS環境では直接クエリ可能で強力な監査ツールです。

クラウドFOでの制約
クラウドFO（Dynamics 365 Finance / SCM）のSSRSは「Microsoft Azure Compute Service上でホスト」されており、ReportServerデータベースへの直接アクセスは顧客には付与されません。ERによるレポート実行はER実行ログ（標準）で追跡でき、SSRS帳票はApplication Insightsにエラーが記録されますが、正常実行ログの詳細取得は制約があります。

⚠️ 現実的なアプローチ: ER（電子申告）フレームワークで管理されているレポートはER実行ログを使う。SSRSベースのカスタムレポートはApp Insights経由でエラー検知、詳細な実行ログが必要な場合はSentinelのApp Insightsコネクタを活用するか、カスタムX++実装を検討する。

フックポイント: FormDataSource.active() 等
対象フォームのデータソース上でレコード選択・アクティブ化を検知できる拡張ポイント（例: FormDataSource.active()）を実装します。ここで「ユーザー・日時・テーブル名・レコードID（RecId）・主キー値」を取得してApplication Insightsのカスタムイベントとして送信します。なお、Table.initValue()は新規レコード初期化用のため、既存レコード閲覧ログのフックとして混同しないよう注意してください。

注意点
閲覧ログは変更ログと異なり「読むだけ」の操作のためトリガーが多くなりがちです。ハイリスクなマスターテーブル（仕入先・顧客・銀行口座等）に対象を絞り込むことで、Application Insightsのインジェストコストとクエリ負荷を抑えます。

⚠️ 全テーブル・全フォームに適用するとパフォーマンスへの影響が大きくなり得ます。監査要件で明示されたハイリスクエンティティのみに絞ることを推奨します。

フックポイント: SysExcelExport 系クラス（バージョン確認必須）
フォーム上の「Excelで開く」機能はSysExcelExport系クラスを経由して処理されますが、実際の呼び出し経路は対象バージョン・フォームによって異なります。Chain of Command / Event Handler等の公開・拡張可能なポイントを対象バージョンで確認した上で実装し、「実行ユーザー・フォーム名・エクスポートエンティティ・出力行数・フィルター条件」を取得してApplication Insightsに記録します（具体的なクラス名はバージョンアップで変わる可能性があります）。

OData経由のad-hocエクスポート
Power BIやカスタムアプリがODataエンドポイントを直接叩くケースでは、Azure API ManagementでHTTPリクエストを受け、$filter パラメーターと呼び出し元のサービスプリンシパルをAzure Monitor Logsに記録するアプローチが有効です。

⚠️ エクスポートの出力先（ローカル保存・OneDrive・メール添付等）までは標準では追跡できません。Microsoftエンドポイント保護（MDE）やEntra ID Conditional Accessと組み合わせた多層防御が必要です。

フックポイント: X++ Pre/Post Handler
FO のエクスポート処理クラス（Excel出力を担う SysExcelExport 系やData Management Frameworkのジョブ実行）に対して、X++のイベントハンドラ（Pre/Post Handler）を実装します。実際の呼び出し経路はバージョン・フォームによって異なるため、対象バージョンで拡張可能なポイントを確認した上で実装してください。エクスポート実行時に「実行ユーザー・日時・対象エンティティ・適用フィルター・出力形式」を取得して記録します。

記録先: Azure Application Insights / Azure Monitor Logs
カスタムハンドラで取得したデータをAzure Application InsightsのカスタムイベントまたはAzure Monitor Logsのカスタムテーブルに送信します。KQLで分析でき、Sentinelへの転送・FabricへのOneLake集約とも自然につながります。

⚠️ X++カスタマイズはMicrosoftのアップデートサイクル（One Versionポリシー）に対する追従テストが必要です。アップデート前後での動作確認を自動化テストに組み込む運用設計を推奨します。

Page View Telemetry（閲覧ログ）
Azure Application InsightsをBCに設定すると、ページビューイベントが標準で記録されます。FOのForm Run Telemetryに対応するもので、「どのユーザーがいつどのページを開いたか」をKQLで分析できます。BCはSaaSモデルなので、Application Insights接続文字列を管理センターで設定するだけです。

RT0006: Report Rendering Telemetry（レポート実行ログ）
トレースID RT0006 はBCの標準レポートテレメトリシグナルです。レポートが実行されると自動的にApplication Insightsに記録されます。取得できる情報: reportId・reportName・serverExecutionTime（サーバー処理時間）・totalTime（総処理時間）・result（Success / Failure / Cancellation）・renderedRows（処理行数テレメトリ）。

KQLクエリ例（RT0006はtracesテーブル / Page ViewはpageViewsテーブルを参照）: traces | where customDimensions.eventId == "RT0006" | project timestamp, user_Id, customDimensions.reportName, customDimensions.result, customDimensions.renderedRows

⚠️ これだけで「誰がいつどのレポートを実行したか・処理行数のテレメトリ」を追跡できます（renderedRowsはBCテレメトリにおけるレポート処理行数の指標であり、ユーザーが最終的に取得したデータ件数とは必ずしも一致しません。正確な意味はMicrosoft Learnの最新ドキュメントで確認してください）。

取得できる情報
BCには、監視対象として指定した重要フィールドの値が変更された操作を記録するField Monitoring機能があります。たとえばVendor（仕入先）の銀行口座番号（IBAN）・Payment Method、Customer（顧客）のCredit Limit等を監視対象に設定することで、「誰が・いつ・どの機密フィールドを変更したか」を標準機能で追跡できます。Change Logより性能影響が小さく、監視対象フィールドを絞った運用が推奨されています（Microsoft Learn）。

設定方法
Setup → Sensitive Field setup から対象フィールドをSensitiveとして登録します。Change Log Setupで対象テーブルのChange Logが有効になっている必要があります。変更ログはChange Log Entriesで確認でき、フィルタリングで機密フィールドの変更操作のみを抽出できます。

⚠️ この機能が記録するのはフィールド値の変更操作です。「誰がそのフィールドを閲覧したか（参照ログ）」を取得する機能ではありません。閲覧ログが必要な場合は、AL Extensionによるカスタム実装（後述）を検討してください。

対象テーブル・フィールドの選定
Change Log Setupでどのテーブルのどのフィールドを記録するかを設定します。全フィールドを有効化するとChange Log Entriesが急増してDBが膨張するため、J-SOX対象の重要フィールドに絞ることが現実的です。優先対象の例: Vendor（仕入先）のBank Account・Payment Terms・Address、Customer（顧客）のCredit Limit・Payment Method、Item（品目）のUnit Price・Costing Methodなど財務計算に直結するフィールドです。

保持期間とエクスポート設計
Administration → Data Administration → Change Log ManagementからChange Log Entriesのクリーンアップ間隔を設定します。デフォルトは短期間のため、J-SOX（7年保管）を念頭にFabric / Azure Blob等へ定期エクスポートするパイプラインを設計します。BCはSaaSのため直接DBアクセスは不可であり、Export機能またはAPIで取得する必要があります。

⚠️ Application Insightsテレメトリ（Page View / RT0006 / カスタムテレメトリ）はAzure側で保持期間を設定します。Change LogとAIテレメトリは記録先・アクセス方法・改ざん防止の設計が異なるため、用途に応じて組み合わせてください。

フックポイント: Page.OnAfterGetRecord
AL Extensionで対象ページ（例: Vendor Card・Customer Card）の OnAfterGetRecord トリガーをフックします。「ユーザー・日時・ページ名・レコードNo.・主キー値」を Telemetry.LogMessage() でApplication Insightsに送信します。

KQLクエリ例
traces | where customDimensions.eventId == "CUSTOM_RECORD_VIEW" | project timestamp, user_Id, customDimensions.pageName, customDimensions.recordNo | where user_Id == "対象ユーザー"

BCはSaaSのため、OnAfterGetRecordは高頻度で発火します。ページ単位ではなく「リスト画面からカード画面へ遷移した場合のみ」等の条件でフィルタリングする実装が現実的です。

⚠️ OnAfterGetRecordは「ユーザーによる明示的な閲覧」を意味するイベントではありません。監査証跡として採用する場合は、対象ページ・遷移条件・セッション状況を組み合わせて「閲覧」の定義を明確化し、監査法人等と合意した上で採用してください。

「Edit in Excel」の仕組みとログ取得
BCの「Edit in Excel」はExcel Add-inがOData APIを呼び出して動作します。ALレイヤーで直接フックする標準的なトリガーはないため、Azure API Managementをゲートウェイとして $filter パラメーターとユーザーIDをAzure Monitor Logsに記録するアプローチが現実的です。

「Send to Excel」（静的エクスポート）
AL ExtensionのReport OnPreReport トリガーで出力形式（Excel / PDF / Print）を判定し、Excel出力時のみTelemetry.LogMessage()で記録します。出力行数は renderedRows（RT0006）との組み合わせで補完します。

⚠️ FO・BCともに「エクスポート後のデータの行方」を追うには、Power Platform DLPポリシーやMicrosoft Purview Information Protectionによる「持ち出し制御」レイヤーとの組み合わせが必要です（次節参照）。

フックポイント: Report.OnPreReport トリガー / ページイベント
AL Extensionで対象レポートの OnPreReport トリガーをフックし、Rec.GetFilters() でRequest Filterを取得します。「実行ユーザー・日時・レポート名・フィルター条件・出力形式（Print/PDF/Excel）」を構造化データとして送信できます。

記録先: Telemetry.LogMessage() → Azure Application Insights
BCはAL Extensionから Telemetry.LogMessage() でAzure Application Insightsにカスタムテレメトリを送信する仕組みを標準で持っています。FO より実装コストが低い場合が多く、BCのApplication Insights基盤（前編で触れた標準テレメトリ）と同じログ先に統合できるため、レポート実行ログと標準テレメトリを同一のKQLクエリで分析できます。

⚠️ BCはSaaSモデルのため、AL Extensionはアップデートごとの互換性確認が必要ですが、Microsoftが提供するAL Extension開発ガイドラインに沿って実装することで追従コストを抑えられます。

有効化と対象エンティティの絞り込み
Power Platform管理センター → 環境 → 監査ログ → Audit設定 からActivity Loggingを有効化します。「すべてのエンティティ」を有効にするとPurview Auditへの転送量・保管コストが急増します。ハイリスクエンティティ（Account / Contact / Opportunity / Order / Invoice等）に絞って有効化することを推奨します。

記録される操作の種類
Read（レコード閲覧）・Create / Update / Delete・ExportToExcel（Excel出力）・Share / Assign（共有・割り当て）等が対象です。このうちReadとExportToExcelは「データ参照・持ち出し」の監査において特に重要で、Dataverse Auditingでは記録されない操作です。

Purview Auditへの自動転送
Activity LoggingのイベントはMicrosoft Purview Auditに自動転送されます（CRMのネイティブ統合）。Purview管理センターのAudit Searchで検索・エクスポートでき、Sentinelの「Microsoft 365」コネクタ経由でSentinelに取り込むことも可能です。FO・BCにはこのPurview Native統合がないため、CRM固有の強みです。

⚠️ 保持期間: Activity LoggingはPurview Audit上で管理されます。Standard（180日）/ Premium（主要Workloadは1年・その他は180日が既定。保持ポリシーと長期保持add-onで延長可）の保持設定を確認してください。Dataverse Auditingのデフォルト30日とは別の保持設定です。

取得できる情報
Power BIアクティビティログはM365の標準機能として、Power BIレポートの操作イベントを記録します。「ViewReport（閲覧）・ExportArtifact（エクスポート）・ShareReport・CreateDashboard」等のイベントと、「ユーザー・タイムスタンプ・ワークスペース名・レポート名・アーティファクトID」を取得できます。

取得方法
Power BI REST API（GET /v1.0/myorg/admin/activityevents）またはPowerShell（Get-PowerBIActivityEvent）で最大30日間のログを取得できます。Sentinelの「Microsoft Power BI」コネクタを使うと自動的にLog Analyticsに取り込み、KQLで分析できます。

⚠️ CRM（Dataverse）のデータをPower BIで閲覧している場合、Power BIアクティビティログでレポート閲覧の監査が可能です。FetchXMLベースのカスタムレポート（Dataverseクエリを直接発行する帳票）の詳細については、後述のPurviewセクションを参照してください。

①prvExportToExcel — Excelエクスポート権限の制御
Dataverseのセキュリティロールには prvExportToExcel 権限が存在します。この権限をロールから削除することで、特定のユーザーグループに対して「Excelへのエクスポートそのものを禁止」できます。閲覧はできるがエクスポートはできない、というロール設計が可能です。顧客情報を扱うすべてのロールでデフォルト付与されていないか確認を推奨します。

②列レベルセキュリティ（Column-Level Security）
口座番号・個人情報等の機密フィールドに列レベルセキュリティを設定することで、参照権限のないユーザーはそのフィールド自体が見えません。参照権限がない列はExcelエクスポートにも含まれないため、「特定フィールドだけ出力されない」設計になります（エクスポート時だけ除外する機能ではなく、参照権限の有無が起点です）。

③行レベルセキュリティ（Row-Level Security）
Dataverseの所有権モデル・Business Unit・チーム共有を組み合わせ、「自分の担当顧客以外のレコードはそもそも見えない」設計にすることで、エクスポートできるデータ範囲を構造的に限定します。「1,000件見える → 1,000件出力可能」から「自担当の50件しか見えない → 50件しか出力できない」への転換です。

⚠️ FO・BCのエクスポート権限制御はセキュリティロール（Privilege / Duty / Role）の設計で行います。Dataverseのロール設計とは独立しているため、同一の設計思想を直接適用することはできません。

UIを経由しないデータ持ち出しの監査課題
Power BI / カスタムアプリ / Power AutomateなどがDataverse Web API（OData）を直接呼び出してデータを取得する場合、UIのActivity Loggingには記録されますが、「どのクエリで何件取得したか」の詳細は標準では残りません。自動化フローや外部連携によるバルクな顧客データ取得は、UI操作と区別しにくいリスクです。

Azure API Management によるOData監査
DataverseへのODataアクセスをAzure API Managementでプロキシし、呼び出し元のサービスプリンシパル / ユーザー・リクエストURL・クエリパラメーター（$filter / $select / $top）をAzure Monitor Logsに記録するアプローチが有効です。特に「どのサービスプリンシパルが何件まとめて取得したか」の追跡に有用です。

Power Platform DLPとの組み合わせ
Power Automateフローによる「DataverseからSharePoint / メール / 外部サービスへのデータ転送」はPower Platform DLPポリシーで遮断できます。DLPはUI操作には適用されませんが、Power Platformコネクタ間のデータフロー制御として有効な補完手段です。

⚠️ すべてのDataverse Web APIアクセスをAPI Managementで仲介する設計は既存の統合・接続に影響を与えます。対象を「外部連携・バッチ系のサービスプリンシパル」に絞った段階的な監査設計が現実的です。

対象: FetchXMLベースのカスタムレポート・高度な検索
Dataverseの「高度な検索（Advanced Find）」やカスタムモデル駆動型アプリのカスタムレポートは、FetchXMLを直接発行してDataverseにアクセスします。まず標準のPurview Auditで取得できる操作の範囲（RetrieveMultipleイベントの記録）を確認し、業務要件上どうしてもクエリ内容の記録が必要な限定シナリオについてのみ、補完的にPlugin実装を検討します。 RetrieveMultiple Pluginは「包括的なDataverseアクセス監査基盤」として使うものではありません。

フックポイント: RetrieveMultiple メッセージ（Pre-Operation / Post-Operation）
DataverseのPlugin StepをRetrieveMultipleメッセージにPost-Operationで登録します。Plugin内でInputParameters[“Query”]を取得できます。クエリの型はFetchExpression / QueryExpression等、呼び出し経路によって異なるため、型判定の実装が必要です。取得した情報（ユーザー・日時・エンティティ名・クエリ内容・結果件数）をカスタムEntityに記録するか、Azure Functionを経由してApplication Insightsに転送します。

実装例（概念コード—実装時はバージョン・型・経路を要確認）
// Post-Operation Plugin: RetrieveMultiple（概念コード）
// InputParameters["Query"]の型はFetchExpression / QueryExpression等、経路により異なる
if (context.InputParameters["Query"] is QueryExpression qe) {
var fetchXml = ConvertToFetchXml(qe); // 要変換実装
LogToAppInsights(userId, entityName, fetchXml, resultCount, timestamp);
} else if (context.InputParameters["Query"] is FetchExpression fe) {
LogToAppInsights(userId, entityName, fe.Query, resultCount, timestamp);
}

⚠️ 高負荷リスク注意: RetrieveMultipleはDataverseの内部処理でも非常に頻繁に実行される最重要メッセージです。これを包括的なアクセス監査フックとして利用する設計は推奨しません。全エンティティに適用すると深刻な性能劣化・コスト超過を招きます。必ず対象エンティティ・ユーザー・アプリケーションを限定し、標準Auditで補えない限定シナリオへの補完として位置づけることが前提です。無限ループ防止のDepth確認（context.Depth == 1）も必ず実装してください。

Step 1: Purview Audit → Search でExportToExcelイベントを絞り込む
Microsoft Purview管理センター → Audit → Search から、対象ユーザー・期間を指定して ExportToExcel イベントを検索します。

Step 2: 検索結果を「エクスポート」する（ポータルで見るだけでは不十分）
ポータルのUI上でレコードをクリックしても、すべてのフィールドが表示されるわけではありません。検索結果を CSVにエクスポートすると、各イベントの全JSON情報を含む AuditData 列が得られます。

Step 3: AuditData（JSON）を展開して Query プロパティを確認する
ExcelのPower Queryで「JSONの変換」を使うか、プログラムで解析します。Query プロパティに値が含まれている場合、それがエクスポート時に使用されたクエリ情報です（FetchXML形式が含まれる場合があります。プロパティが存在しない・空の場合もあります）。

Step 4: クエリ情報をデコードして内容を読む
FetchXMLはエンティティ名・条件・ソート等を含む構造化クエリです。クエリ情報が含まれる場合、デコードすることで「どのビューから・どの条件でエクスポートしたか」等の情報を確認できる場合があります。

前提条件: Microsoft Purview Audit（Standard以上）+ CRMのActivity Loggingが有効化されていること。Queryプロパティの有無・内容はエクスポート方法・環境・バージョンによって異なります。本手順を監査要件に使用する前に実環境で記録内容を確認し、監査法人等との合意を得ることを推奨します。

この手順はDataverse（CRM）に固有のものです。FO・BCのExportにはこの手法は使えません。FO・BCでのエクスポートフィルター条件の取得はカスタム実装が必要です。

Power Platform DLP（データ損失防止）ポリシーは、Power Apps・Power Automate・Copilot Studioで使用できるコネクタを「Business / Non-Business / Blocked」の3層に分類し、異なるグループのコネクタを同一フローで併用することを制限します。

D365監査設計での活用例：

Dataverse（CRMデータ）コネクタと外部ストレージ（Google Drive・Dropbox等）コネクタを同一フローで使うことをBlockedに設定—Agentや自動化フローによるCRMデータの外部コネクタへの意図しない転送を制限する（Power Platformのコネクタ間データフロー制御であり、D365フォームからの直接操作には適用されない）。

承認なしのメール送信コネクタ（Outlook等）とDataverseの組み合わせをNon-Businessに分離—自動化による大量データのメール送信を抑止する。

⚠️ DLPポリシーはPower Platform上のフロー・アプリに適用されます。D365フォームからの直接エクスポート（「Excelで開く」等）はPower Platformを経由しないため、DLPポリシーの対象外です。なお2026年時点では従来のClassic Data Policyに加え、Certified ConnectorをAllowlistで管理するAdvanced Connector Policies（ACP）も提供されており、より厳格なコネクタ制御の選択肢となっています。

Microsoft 365のサービス（SharePoint・Exchange・Teams・Dataverse等）の操作ログを一元管理するサービスです。前編で触れたDataverse Activity LoggingのPurview転送先がここです。なお、FO・BCのログはPurview Auditの直接対象外です（下記補足参照）。

Standard（E3ライセンス含む）: 操作ログの180日保管（2023年10月17日以降に生成されたログに適用）。基本的な検索・エクスポート機能。

Premium（E5またはCompliance Add-on）: Exchange・SharePoint・OneDriveなど主要Workloadは既定1年保管。それ以外の活動は既定180日。保持ポリシーにより対象ユーザー・Workloadで期間を延長可。10-Year Audit Log Retention add-onで最長10年まで保管できます（対象ユーザー・エンティティ要件あり）。なお「Premiumならすべてのログが自動的に1年保管される」ではなく、Workload・ユーザーライセンス・保持ポリシーの組み合わせで決まります。その他の機能: 詳細なメタデータの記録、Intelligent Insightsによる異常操作の検出、監査ログのエクスポートAPIによる自動化。

⚠️ CRMのActivity Logging（閲覧・エクスポートログ）はPurview Auditに転送されますが、FO・BCの操作ログはPurview Auditに直接統合されるわけではありません。FO・BCのログはそれぞれのAzure SQL環境に残り、Sentinelやカスタム連携でPurviewの外部から補完する設計が現実的です。

J-SOX・ISO 27001・GDPR・SOC 2等のコンプライアンスフレームワークに対して、現在の設定状況がどの程度準拠しているかを評価・スコア化するツールです。

設定改善のアクション（Actions）を提示し、実施した改善を記録できます。監査法人へのエビデンス提出にも活用できます。

⚠️ Compliance Managerが評価するのはMicrosoftクラウドサービスの設定状況です。D365のカスタマイズや組織内プロセスのコンプライアンスは、組織側のアセスメントを別途行う必要があります。

機密データにラベルを付与し（Sensitivity Label）、そのラベルに基づいてアクセス制御・暗号化・DLP（データ損失防止）ポリシーを適用します。

Dataverseとの統合では、DataverseデータをもとにするPower BIレポートやMicrosoft 365コンテンツに感度ラベルを適用できます（Dataverseレコード自体への直接のラベル付与とは異なります）。前編で触れた「持ち出し制御」の延長として、Power BI・M365レイヤーでの情報保護を加える設計です。

⚠️ FO・BCのデータへのSensitivity Label適用はDataverseのように直接統合されているわけではなく、Power BI等を経由したレポート・エクスポートへの適用が現実的な範囲です。

Microsoft Entra IDコネクタ: サインインログ・監査ログ（権限変更・MFA状況・条件付きアクセスの評価結果）をSentinelに転送。D365ユーザーのサインイン異常検知の基盤。

Microsoft 365コネクタ: Purview Auditのログ（SharePoint・Exchange・Teams・Dataverse Activity Logging）をSentinelに転送。CRMの閲覧・エクスポートログを横断分析に組み込める。

Dynamics 365コネクタ: Dataverse Auditingのログ（C/U/D・Assign・Share）をSentinelに転送。CRMの変更操作を他システムのログと相関分析できる。

⚠️ FO・BCのDatabase Log / Change LogはSentinelのネイティブコネクタでは対応していません。Azure Monitor / Azure Blob経由のカスタム連携またはSyslogコネクタ等を用いた個別構成が必要です。

UEBAは「ユーザーとエンティティの行動分析」です。複数のログソースからユーザー・エンティティ単位の行動情報を集約・分析し、通常パターンから外れた異常性を検知します。監査ログを「事後に読む」のではなく「リアルタイムに監視する」機能です。

D365の監査での活用例：

普段は月50件程度の取引を処理するユーザーが、特定の週に突然500件を処理した。

退職手続き開始後のユーザーが、退職予定日の前日に大量のレコードをエクスポートした。

通常は日本からのみログインしているユーザーが、海外IPから深夜にログインした直後にマスター変更を実行した。

⚠️ UEBAはSentinelへのログインジェスト量に応じたコストが発生します。全ログを流すのではなく、高リスク操作のログを選択してインジェストするコスト設計が重要です。

OneLake への集約: D365の各ログ（Database Log / Change Log / Dataverse Auditing等）とPurview AuditのログをパイプラインでOneLakeに取り込みます。Delta Lake形式での保管により、長期保管のコストを抑えながら分析可能な状態を維持できます。

Fabric Lakehouse での監査分析: SparkやT-SQLを使って、数年分の監査ログを横断的に分析できます。「過去3年分のうち、仕入先マスターを変更したすべての操作を時系列で出せ」という監査要求に、バッチ分析で応えられます。

Power BI での監査ダッシュボード: 監査部門・コンプライアンス担当者向けに、ログの可視化ダッシュボードを構築できます。「今月の異常件数」「権限変更の推移」「エクスポート操作の集計」等を継続的にモニタリングする体制が作れます。

⚠️ FabricはF SKU等のFabric Capacityライセンスが必要です（既存のM365・Power BIライセンスとは別途確認が必要）。導入前にコスト試算と既存ライセンス構成の確認を推奨します。

J-SOX（会社法・金融商品取引法）対応における保持期間の考え方: 内部統制の評価・監査に必要な文書・証跡については、法令・会社の文書管理規程・監査人との合意に基づく保存要件を確認する必要があります。一般的に7年保管が必要となる証跡が生じますが、「すべてのD365監査ログを一律7年間保存する」設計ではなく、内部統制の評価・証明に直接使う記録の範囲を監査法人と合意した上で保持期間を決定します。

D365標準ログのデフォルト保持期間:

FO Database Log: 管理者が設定したクリーンアップ期間（デフォルト90日。要変更）

BC Change Log: 管理者がRetention Policyを設定（デフォルト設定要確認）

Dataverse Auditing: デフォルト30日（Purview Premium保持ポリシー＋長期保持オプションで拡張可。条件はMicrosoft Learnで確認）

⚠️ D365の標準ログは「デフォルト設定では7年保管できない」ケースが多数あります。本番稼働前にRetention Policyを必ず確認・変更するか、Fabric / Azure Blob等への長期エクスポートパイプラインを設計してください。

監査で最も見落とされやすい論点の一つが、ログの改ざん防止設計です。「管理者が自分のログを削除できる」構造では、監査証跡として機能しません。

Purview Audit Premium の保護機能: Purview Audit Premiumの保持ポリシーを活用することで、管理者による削除を防ぐ形での長期保持を設計できます。外部監査・法的訴追に備えた証拠保全には、eDiscovery機能との連携も別途検討が必要です。

Azure Blob Storage の Immutability Policy: D365のログをAzure Blob Storageにエクスポートし、WORM（Write Once Read Many）ポリシーを設定することで、一定期間の書き換え・削除を防止できます。J-SOX対応でFO・BCのログを長期保管する現実的な方法の一つです。

⚠️ ログの存在と改ざん不可能性の証明は別の設計です。単に「保管している」だけでは不十分で、「誰も削除・変更できなかった」ことを証明できる設計が必要です。

① ログの網羅性: 監査対象として定義したフィールド・テーブル・操作すべてにログが設定されているか。「設定したつもりだったが、特定のフィールドが漏れていた」は高リスク。

② ログとビジネスプロセスの対応: 重要な業務プロセス（仕入先マスター変更・銀行口座変更・与信枠変更等）に対して、対応するログが存在するか。業務フローとログ設定のマトリクスが文書化されているか。

③ SoD違反の定期的なレビュー: SoD（職務分掌）違反が発生していないかを定期的にレビューしているか。レビューした記録が残っているか（「やっている」だけではなく「記録がある」こと）。

④ 特権アカウントの管理: システム管理者権限・スーパーユーザーの操作ログが別途管理されているか。特権アカウントの操作は通常ユーザーとは異なるレベルの監視が求められる。

⑤ 異常検知と対応の記録: 異常なログを検知した場合に、誰が・いつ・どう対応したかの記録があるか。検知だけで対応がないのは、内部統制として機能していない。