Power Platform管理・監視 調査まとめ

本レポートでは、Microsoft公式資料を基に、Power Platformの管理・監視機能とログ分析の選択肢を整理します。主な対象はPower Apps、Power Automate、Dataverseで、Copilot StudioとPower Pagesについても補足します。

Power Platformの監視情報は、標準の管理画面、監査、テレメトリなど複数の場所に分かれており、目的に合わない仕組みを選ぶと必要な記録が取れなかったり、導入・運用の負担が増えたりすることがあります。本レポートは、何を確認したいかに応じて使う機能とログの経路を見分け、ライセンスや保持期間、配信遅延などの前提を踏まえて導入判断を進めるための道しるべです。標準機能で足りる範囲と追加連携が必要な場面を整理しているため、監視設計の検討や小規模なPoCの計画にも活用できます。

なお、Power BI/Fabricの詳細な監視設計は対象外です。実テナントの設定、ライセンス、ログ到着状況は検証していません。本文中の「推奨」は調査に基づく設計提案であり、製品の標準動作を示すものではありません。

1. 結論とサービスの役割

Log Analyticsを使ってPower Platformのログを分析できます。ただし、目的に応じて収集経路を選ぶ必要があります。 性能・障害を調べる実行テレメトリにはApplication Insights連携、管理操作・共有変更などの監査にはPurview Audit、その監査ログを使ったセキュリティ分析にはMicrosoft Sentinelが主な選択肢です。1, 9, 12, 15

選択肢主な目的答えられる問い導入上の位置づけ
Power Platform標準機能日常管理、利用状況、稼働確認どのアプリ・フローが使われ、どこで失敗が増えたか最初に活用する管理画面・診断機能
Dataverse監査業務データの変更を追跡します誰がどのレコードのどの列を変更し、変更前の値は何だったか対象環境、テーブル、列の監査を設定します
Microsoft Purview Audit管理・利用操作を監査します誰が環境、アプリ、フロー、共有権限などを変更したか監査の検索と保持ポリシーを管理します
Application Insights＋Log Analytics性能を分析し、エラーを調査しますどの処理や依存先が遅い、または失敗しているかテレメトリを収集し、KQLで分析します
Microsoft Sentinel脅威を検知し、SOCで調査・対応します不審な変更やアクセスが、他のセキュリティイベントと関連するかLog Analytics上のログをSIEMとして利用します
API＋独自収集標準連携で不足するログを収集します独自の管理台帳や業務イベントを分析できるか収集処理を開発・運用します

Log AnalyticsはAzure Monitor Logsを検索する機能で、ワークスペースがログの保存先になります。Application Insightsはアプリケーション監視機能です。ワークスペースベースのリソースを利用すると、テレメトリは関連付けたLog Analyticsワークスペースに保存されます。Sentinelはセキュリティ分析のためのサービスであり、一般的な性能分析だけであれば必須ではありません。19, 20, 24

2. 標準的な機能で実施できること

「標準搭載」と「追加ライセンス条件なし」は同じではありません。特にManaged Environmentsの推奨事項やカスタムアラートなどは、利用条件を確認してください。

管理業務標準機能確認できる内容・使い方制約・確認事項
Microsoft側の障害確認管理センターのService healthサービス障害、影響、復旧状況サービス全体の障害情報として確認し、個別アプリのエラー調査とは分けて扱います。7
アプリ・フローの健全性管理センターのMonitor健全性指標、関連イベントログ、改善推奨Tenant-level analyticsを有効にします。ログは最大7日、指標は最大28日確認でき、日次集計が基本です。1
定着・利用状況Power Apps分析、テナント分析利用傾向、利用者、アプリのエラー・サービス性能Power Appsの該当環境分析はキャンバスアプリが対象です。最大28日分を確認でき、約24時間ごとに更新されます。3
フローの利用・失敗傾向Power Automate分析実行数、エラー、作成・共有、コネクタ利用約24時間ごとに更新されます。現行の分析レポートでは、ソリューション対応フローは対象外と明記されています。4
個別のフロー障害調査Power Automate実行履歴実行ごとの状態、失敗したアクション、入出力通常の履歴は28日間です。閲覧権限やセキュアな入力・出力設定の影響も確認してください。6, 28
自動化全体の状況確認Automation center、DataverseのFlowRunソリューション対応クラウドフローの状態、所要時間、エラー、親子実行関係FlowRunの既定TTLは28日で、APIから独自TTLを設定できます。容量・権限・高負荷によって取り込みが欠落する場合があります。6
アプリの再現調査Power Apps Live monitor操作中のイベントを追い、性能・通信・式などを調査キャンバス／モデル駆動型アプリのセッション診断に使います。継続的に全社ログを保管するには、別の仕組みが必要です。8
Dataverseの稼働・負荷確認Dataverse分析利用者、API、失敗したワークフロー、プラグイン、ストレージなどMonitorにおけるDataverse専用リソースの表示とは別の機能です。5
容量・ライセンス管理Licensing／Capacity／Actionsライセンス消費、ストレージ、容量の不足と推奨対応項目によって更新頻度やManaged Environmentsの条件が異なります。25, 26
データ変更履歴Dataverse監査作成・更新・削除、変更列、以前の値、共有権限等環境、テーブル、列ごとに監査を設定します。ログ容量を消費します。9

2.1 管理センターMonitorの対象とアラート

公式のMonitor概要によると、キャンバスアプリ、モデル駆動型アプリ、クラウドフロー、デスクトップフローは一般提供されています。ワークキューとCopilot Studioエージェントはパブリックプレビューです。また、Dataverse単体とDynamics 365アプリは、Monitorの専用表示に対応していません。製品ごとの分析画面とMonitorの対応状況は、分けて確認してください。1

カスタムアラートでは、環境または個別リソースについて、指標のしきい値、重大度、メール通知を指定できます。対象はManaged Environmentsです。Microsoftが定義した事前アラートもあり、利用率の高いリソースの健全性低下を通知します。通常の評価は24時間ごとです。1時間のデータ評価期間は、現時点の資料ではコードアプリ向けプレビューに限られています。そのため、これをすべてのフローに対する即時検知と解釈しないでください。2

2.2 標準機能から始める場合の判断

日々の健全性チェック、短期的な失敗傾向の把握、容量・ライセンスの確認、個別障害の再現調査であれば、標準機能で幅広く対応できます。一方、数か月にわたる傾向分析、独自KPI、Azureバックエンドとの突合、独自の通知・自動対応が必要な場合は、外部連携を検討してください。

注意：Power Automate分析の公式ページでは、冒頭のデスクトップフロー除外と後段の対象説明に差があります。レポート名・画面ごとに対象を確認し、クラウド／デスクトップ／ソリューション対応のすべてを一括して「全件取得できる」と判断しないでください。4

3. Purviewなどを使った監査と組み合わせる

3.1 Purview Auditで確認できること

対象主な監査イベント管理業務での利用例
Power Platform管理操作環境作成・削除・コピー・復元、設定変更、環境グループ、データポリシー、Lockbox本番環境の変更主体、変更申請との整合を調査。10
Power Apps作成、起動、編集、公開、削除、アプリ権限・所有者変更等公開や共有変更を追跡し、問い合わせ・内部監査に利用。11
Power Automateクラウドフロー作成・編集・削除、権限変更等誰がフローを変更／削除したかを調査。12
Dataverse／モデル駆動型アプリ設定した活動・読み取り監査誰が対象データにアクセスしたかを調査。更新前後の値の確認はDataverse監査を併用。9, 15
Power Pagesサイト関連管理・設定変更等WAF有効化などの設定履歴を確認。29

PurviewのPower Automate監査には、フローの個別実行、各アクションの実行、実行時のコネクタ呼び出しは含まれません。 実行失敗や所要時間を調査する場合は、実行履歴、FlowRun、Application Insightsを使います。12

3.2 Dataverse監査との違い

Dataverse監査では、レコードや列の変更履歴を管理します。列の更新は値が変わった場合に記録されるため、誰がいつどの列を更新したか、更新前の値は何かを調査できます。環境だけでなく対象のテーブルや列でも監査を有効にし、ログ容量と保持期間を設計してください。9

DataverseのRead logsは、Purviewに送信する活動ログの設定です。レコードを開く、または一覧を表示する操作の監査も別途設定してください。データ変更監査だけを有効にしても、すべての閲覧履歴が記録されるわけではありません。監査テーブルの分析にはAzure Synapse Link＋Power BIを使う方法も公式に案内されていますが、これはLog Analyticsへの自動送信とは別の経路です。9

3.3 有効化・権限・保持

  • Power Platform管理操作の収集は、公式資料では全テナントで既定で有効です。ログを閲覧するには、PurviewのAudit LogsまたはView-Only Audit Logsなどの権限を確認してください。10
  • 環境のユーザー活動監査については、製品ごとの前提条件を確認してください。公式概要では本番環境を対象とし、監査設定、ライセンス、Purview側での監査有効化を求めています。SAS利用の監査には、Enable SAS Logging in Purviewという専用設定も案内されています。これをすべての監査イベントに共通するスイッチとして扱わず、対象ログごとの設定と実際のデータ到着を確認してください。13
  • Audit Standardの既定保持期間は180日です。E5にするだけでPower Platformのログがすべて自動的に1年間保持されるとは限りません。対象レコード種別の保持ポリシーと、操作を行うユーザーに適用されるライセンスを確認してください。14
  • 180日を超えて1年間、または10年間保持する場合は、それぞれ追加のライセンス条件があります。監査閲覧者だけでなく、イベントを生成するユーザーのライセンス条件も重要です。14

Purviewで監査検索や証跡保持の目的を満たせる場合は、Log Analyticsへの複製は必須ではありません。自動検知、他サービスとの相関分析、SOC運用が必要な場合は、Sentinelなどを追加してください。

4. Azureのログ分析系サービスと組み合わせる

4.1 性能・障害分析：Application Insights経由

対象収集方法できる分析制約・導入条件
Dataverse／モデル駆動型アプリ管理センターのData export→App Insightsサーバー側診断、フォーム・グリッド等の性能、操作の相関管理センターのエクスポートにはManaged EnvironmentsやDataverse DBなどの前提があります。モデル駆動型アプリの保存イベント／リボンコマンドは対象外と明記されています。16, 17
Power Automateクラウドフロー同上で実行・トリガー・アクションを選択フロー失敗率、処理時間、失敗したアクション、コネクタ処理の問題パブリックプレビューです。Requestsには実行、Dependenciesにはトリガーとアクションが記録されます。データが欠落する可能性があります。16, 18
キャンバスアプリアプリにApplication Insightsの接続文字列を設定利用者・セッション・画面利用、Traceによる独自イベント・エラーアプリごとに設定して公開する必要があります。Studio内のプレビューでは送信されません。管理センターの一括エクスポートとは別の経路です。21
Copilot Studioエージェント単位、または環境単位の連携エージェントの診断、環境単位ではエージェント呼び出し・ツール実行等のspan分析環境単位の連携はプレビューで、Managed Environmentsなどの前提があります。2つの方式では対象とスキーマが異なります。22, 23
Power PagesTracking Code等にテレメトリ用HTML/JSを設定クライアント側のアクセス・利用・性能等データモデルによって設定場所が異なります。ブラウザー計測だけで全サーバー処理が自動収集されるとは考えないでください。30
Azure Functions／API等対象サービスのApplication Insights等Power Platformから呼ばれるAPI・依存先の性能・エラーPower Platform側とは別に設定します。相関IDが引き継がれない場合、同じトレースには自動的にまとまりません。設計と実測が必要です。

重要な運用上の制約

管理センターのApplication Insightsエクスポートでは、テレメトリ配信のSLAは24時間と明記されています。初期設定後の送信開始も、24時間以内が目安です。実際には早く届くこともありますが、数分以内の障害検知をこの経路だけに依存すると、要件を満たせない可能性があります。16

Power Automateのテレメトリは非トランザクションデータであり、欠落がまったくないとは限りません。欠落が疑われる場合は、Power Automateポータルの実行履歴を参照してください。FlowRunにも取り込み欠落に関する注意があるため、証跡や全実行件数をテレメトリだけで厳密に照合しないでください。18, 6

環境ごとにApplication Insightsリソースを分ける設計を推奨します。公式資料では、複数環境を同じApplication Insightsに混在させると、標準レポートが正しく動作しないと注意されています。同じLog Analyticsワークスペースに集約するか、ワークスペースを分けて横断検索するかは、閲覧範囲、保管、運用責任に応じて決めてください。また、このPower Platform連携ではApplication Insightsのローカル認証が必要です。Azure Policyなどで禁止している場合は、要件への適合を確認してください。16

連携後にできること

  • KQLを使って、環境別・フロー別の失敗率、所要時間の分布、日次傾向を集計できます。
  • エラーを分類し、頻発するアクション、遅い依存先、影響するリソースを絞り込めます。
  • Workbooksなどで複数の分析をまとめ、Azure Monitorのログ検索アラートで通知できます。24, 31
  • Action Groupsからメール、Webhook、Functions、Logic Appsなどを使って、通知や対応処理につなげられます。32
  • 運用に必要な保持期間を設定できます。長期保持と通常の対話的検索では、条件と費用が異なります。33

アラートの評価頻度を短くしても、元ログの配信遅延は短くなりません。業務停止の即時検知が必要な場合は、重要フローの失敗処理や外部通知、独自業務イベント、予定実行の未実施チェックなどを補助経路として設計し、その経路自体の障害も考慮してください。

4.2 監査・セキュリティ分析：Microsoft Sentinel経由

公式のMicrosoft Business Applicationsソリューションを使うと、監査・活動ログをSentinelに接続し、脅威や不審な操作の検知に活用できます。導入には、Sentinelを有効化したLog Analyticsワークスペース、必要な権限、監査の有効化などが必要です。15

公式導入ページで明記されたコネクタLog Analyticsテーブル収集対象
Microsoft Power Platform Admin ActivityPowerPlatformAdminActivityPower Platform管理操作
Microsoft Power AutomatePowerAutomateActivityPower Automate活動監査
Microsoft DataverseDataverseActivityDataverse／モデル駆動型アプリ活動ログ

※この一覧はPower Platformの全ログを含むものではありません。Power Appsの起動ログなどを、上記のテーブル名だけから収集できると推測しないでください。目的のイベントが該当コネクタで収集されるか、サンプル操作で確認してください。15

活用例として、環境の削除、共有権限やデータポリシーの変更、対象データへの不審なアクセスを検知し、Entraなどの別ログと時刻・ユーザー・環境で相関させる設計が考えられます。具体的な検知条件は、ログ項目と業務上の正常なパターンに合わせて作成してください。Purviewは監査の検索・保持、Sentinelは検知・調査・対応を担います。

導入資料では、試験操作の後に60分待ってから取り込みを確認するよう案内しています。ただし、これはすべての監査イベントが必ず60分以内に到着するという保証ではありません。15

4.3 Sentinelを使わない独自収集

Log Analyticsで監査ログを集計するだけであれば、Sentinelを有効にする必要はありません。たとえば、次の構成を実装できます。

  1. Office 365 Management Activity APIなど、対象監査ログを取得できるAPIを使用します。
  2. Azure Functionsなどで、取得、ページング、再試行、重複排除を実装します。
  3. Azure Monitor Logs Ingestion APIとDCRを使って、独自のLog Analyticsテーブルに送信します。

監査APIを使うには、Audit.Generalなどの購読と、ActivityFeed.Readを含む認可が必要です。コンテンツ一覧の取得範囲は最大24時間で、開始時刻は過去7日以内などの制限があります。Purviewの180日保持とAPIから取り出せる期間は同じではありません。 収集停止、取りこぼし、順序の入れ替わりも考慮してください。27

Logs Ingestion APIでは、事前にテーブルとDCRを用意し、DCRへの送信権限を付与します。独自テーブルには_CL接尾辞を使います。DCEはすべての構成で必須ではなく、Private Linkを利用する場合やDCRに取り込みエンドポイントがない場合などに必要です。34

この方式は設計案であり、Power Platformの全製品の監査ログを自動かつ完全に取得できる標準機能ではありません。Power Appsなどの目的イベントが実際にAPIから返ることを検証してから採用してください。収集基盤の保守負担も比較してください。

5. 目的別ディシジョンツリー

各図では、目的に応じた監視方法の選び方を示しています。複数の目的がある場合は、それぞれに適した経路を併用してください。

5.1 最初に監視目的を選ぶ

図1：監視目的別の選択フロー

Image description

5.2 性能・障害の判断フロー

図2：性能・障害監視の意思決定フロー

Image description

Managed Environmentsやライセンスの条件を満たせない場合は、管理センターからのエクスポートを前提にせず、標準機能、対象API、個別計測を利用できるか再検討してください。数分以内の通知が必要な場合は、配信遅延が許容範囲内かどうかも含めて、構成を評価してください。

5.3 監査・セキュリティの判断フロー

図3：監査・セキュリティ監視の意思決定フロー

Image description

5.4 目的と最初の選択肢

目的・要件最初の選択肢追加する条件
毎朝、利用状況・失敗傾向を確認管理センターMonitor／分析標準対象に入らないリソースを補完
フローが昨日失敗した原因を調査フロー実行履歴多数フローを横断するならApp Insightsを追加
特定ユーザーのアプリが遅いLive monitor継続的な傾向ならアプリ種別に応じApp Insights
3か月分の失敗率とp95を比較App Insights＋Log Analyticsログ粒度、配信遅延、欠落を許容できるか確認
重要フローの障害を数分で通知フロー内失敗処理・独自通知等を設計標準エクスポートの実測と配信SLAを確認
誰がアプリ共有・フロー権限を変更したかPurview Audit自動検知・SOC運用が必要ならSentinel
誰が顧客データの金額を変更したかDataverse監査対象列の監査、保持、アクセス権を設計
不審な参照・変更とサインインを突合Purview等の監査＋Sentinel必要な参照イベントとEntraログの取得を検証
容量・ライセンスの不足を把握Licensing／Capacity／Actions独自の時系列が必要ならAPI対応範囲を調査
監査ログを1年以上保持Purview保持ポリシー／別途保管を設計操作者のライセンス・原本保管要件を確認

6. Log Analyticsを使う場合の導入案

6.1 推奨する構成の分け方

図4：Power Platformのログ収集・分析に推奨する構成

Image description

※監査経路は概念図です。各監査イベントの生成・収集経路は、コネクタの仕様に従います。図では運用責任を分けて示していますが、ワークスペースを物理的に分けることを必須とするものではありません。

6.2 最初のPoCで行うこと

  1. 監視要件を整理します。 対象環境・リソース、ログ種別、保持期間、検知時間、監査証跡の要否を一覧にします。
  2. 標準画面でベースラインを確認します。 Tenant-level analytics、Monitor、分析、実行履歴、Dataverse監査、Service healthを確認します。
  3. 重要なフロー1本とアプリ1本で収集します。 可能であれば検証用Managed Environmentを利用し、環境ごとのApplication Insightsと関連ワークスペースを用意します。
  4. 正常・失敗・遅延の各ケースを試します。 Power Automateでは、実行・トリガー・アクションの到着、件数、環境ID、フローIDを確認します。
  5. 監査イベントも別に確認します。 アプリ権限の変更、フローの編集、データポリシーの変更などを発生させ、Purviewと必要な収集先で確認します。
  6. KQLと通知を試します。 対象リソースに絞った失敗集計、処理時間、収集停止の検知を作成し、通知先に届くことを確認します。
  7. 1～2週間、件数・遅延・費用を測定します。 元の実行履歴と照合し、p50／p95の配信遅延、欠落・重複、日次取り込みGB、利用者別の閲覧範囲を評価します。

本番採用の条件として、対象リソースを収集できること、許容できるプレビュー条件であること、通知遅延が要件内であること、必要な項目を取得できること、月額費用と保持条件について合意できていることなどが挙げられます。無活動のフローは「ログがない」だけでは障害と判定できません。そのため、実行予定や収集処理のheartbeatを使って確認してください。

7. KQLの出発点

以下は、資料にあるテーブル対応に基づいて作成したサンプルです。実環境では実行していません。環境ID、実際のProperties、送信対象を確認して調整してください。集計件数は取り込まれた行数です。欠落やサンプリングがある場合、業務実行の総数を保証するものではありません。

Application Insights画面のrequestsとLog AnalyticsワークスペースのAppRequestsは、同じテレメトリに対する異なるスキーマ名です。timestampとTimeGenerated、customDimensionsとPropertiesなどの対応を区別してください。19, 20

7.1 クラウドフロー別の失敗率とp95所要時間

Log Analyticsワークスペース側で実行してください。

let targetEnvironment = "<environment-id>";
AppRequests
| where TimeGenerated >= ago(7d)
| where tostring(Properties["resourceProvider"]) == "Cloud Flow"
| where tostring(Properties["environmentId"]) == targetEnvironment
| summarize
    ReceivedRuns = count(),
    FailedRuns = countif(Success == false),
    P95DurationMs = percentile(DurationMs, 95)
    by FlowId = OperationName, bin(TimeGenerated, 1d)
| extend FailureRatePct = 100.0 * FailedRuns / ReceivedRuns
| order by TimeGenerated desc, FailureRatePct desc

OperationNameとフローIDの対応、およびresourceProvider、environmentIdなどは、Power Automate連携資料に基づいています。項目が空の場合は、まず生ログを確認してください。18

7.2 失敗したクラウドフローのアクション

let targetEnvironment = "<environment-id>";
AppDependencies
| where TimeGenerated >= ago(7d)
| where tostring(Properties["resourceProvider"]) == "Cloud Flow"
| where tostring(Properties["environmentId"]) == targetEnvironment
| where tostring(Properties["signalCategory"]) == "Cloud flow actions"
| where Success == false
| project TimeGenerated, Name, OperationId, ResultCode, DurationMs, Properties
| order by TimeGenerated desc

フロー単位に絞る場合は、Properties内の実際のフロー識別項目を確認して追加してください。OperationIdが他システムのIDと自動的に一致するとは限りません。

7.3 Sentinel側の管理監査ログ取り込み確認

PowerPlatformAdminActivity
| where TimeGenerated >= ago(7d)
| take 50

まず生ログのスキーマを確認し、DLP、環境、共有などの判定条件を作成してください。現行資料では、Power PlatformのデータポリシーイベントはGovernanceApiPolicyOperationにまとめられ、旧DLP活動名は非推奨とされています。過去のイベント名だけで検知条件を固定しないでください。10, 15

8. 本番設計で決める事項

項目決めること
ログの用途性能診断、業務実行の確認、内部監査、脅威検知を区別します
対象範囲環境の種類、アプリの種類、クラウド／デスクトップ、ソリューション対応の有無を定めます
ライセンスManaged Environmentsの利用者・容量条件、Purviewの保持条件、Azure／Sentinelの費用を確認します
権限Power Platformの設定権限、Purviewの閲覧権限、Azureの取り込み・閲覧権限を分離します
保持標準画面、Dataverse、Purview、Log Analyticsそれぞれの保持期間を定めます
配信品質遅延、欠落、重複、再取得可能期間を確認し、元データと照合します
相関テナントID、環境ID、アプリ／フローID、実行ID、操作IDを使い、時刻をUTCに統一します
データ内容入出力、ユーザー情報、会話内容などの必要性を確認し、収集・閲覧範囲を最小限にします
通知閾値、最低実行件数、評価期間、通知先、一次対応者、重複抑制を定めます
費用日次取り込み量、アクション単位のログ量、保持、アラート、Sentinel、収集処理の費用を見積もります

Managed Environmentsを有効にする場合は、利用するユーザーやリソースに応じた適格ライセンス、容量、従量課金の条件を満たす必要があります。監視を有効にする管理者のライセンスだけで判断しないでください。35

Log Analyticsでは、テーブルごとに保持期間とプランを検討できます。長期保持は最大12年まで設定できると案内されています。ただし、低頻度で検索する長期保持と通常の対話的検索では条件が異なり、費用も異なります。AppRequestsはBasicプランに対応していないため、すべてのテーブルを安価なプランに変更できるとは考えないでください。20, 33

未確認・実環境で確認すべき事項

  • 利用中テナントでの新UI、Monitor、プレビュー機能の提供状況。
  • 保有するライセンスでのManaged Environments・Purview利用／保持可否。
  • 実際のログ配信遅延、項目、件数一致、収集設定の影響。
  • Power Appsなど、Sentinelの上記3つのコネクタに明示されていない対象の具体的な取得経路。
  • Power Pagesの全サーバー診断ログやデスクトップフローの全アクション詳細を、標準のApp Insightsエクスポートで取得できるか。今回の資料からは、一括対応を確認できていません。
  • Power Platformと外部API間の相関ID伝播、横断トレースの成立。
  • 料金見積もり。地域、契約、取り込み量、保持期間、通知数が不明なため、算定していません。

9. 公式参照資料

  1. Power Platform Monitor概要
  2. 標準のアラート設定
  3. Power Apps管理者分析
  4. Power Automateクラウドフロー分析
  5. Dataverse分析
  6. Dataverseのクラウドフロー実行履歴
  7. サービス正常性
  8. Live monitor概要
  9. Dataverse監査の管理
  10. PurviewのPower Platform管理操作ログ
  11. PurviewのPower Appsログ
  12. PurviewのPower Automateログ
  13. Power Platform活動ログ・Purview監査概要
  14. Purview監査ログ保持ポリシー
  15. Power PlatformとSentinelの接続
  16. Application Insightsへのエクスポート設定
  17. モデル駆動型アプリ・Dataverseテレメトリ
  18. Power AutomateのApplication Insights連携
  19. Application Insightsデータモデル
  20. AppRequestsテーブル
  21. キャンバスアプリのApplication Insights連携
  22. Copilot Studioテレメトリ概要
  23. Copilot Studio環境単位のテレメトリ：プレビュー
  24. Azure Monitorログクエリ
  25. 容量・ライセンスの監視
  26. 容量・ライセンスの推奨事項
  27. Office 365 Management Activity API
  28. フロー実行履歴の保持と欠落
  29. Power PagesのPurview活動ログ
  30. Power Pagesのテレメトリ設定
  31. Azure Monitorログ検索アラート
  32. Action Groups
  33. Log Analyticsの保持期間設定
  34. Logs Ingestion API
  35. Managed Environmentsライセンス条件