Power Platformの監視情報をアプリ担当者へ開示する：戦略パターンとログ分析基盤の設計
2026年10月14日の「Power Platform管理・監視 調査まとめ」では、基盤を運営する担当者の視点から、管理画面、監査、テレメトリの役割を整理しました。企業では、その基盤の上に複数の業務アプリがあり、開発者も運用責任者も異なります。基盤担当がログを集められるだけでは、個々のアプリの改善や障害対応は進みません。
次に必要なのは、アプリ開発者とアプリ管理者が、自分たちの担当するアプリの状況を、自分たちで調べられる環境です。日々の状況はダッシュボードで確認し、問題があれば個別のクエリで掘り下げる。そのために、何をアプリ側で記録し、何を中央で収集し、どの範囲まで開示するかを設計します。
この記事は、Power Appsのキャンバス／モデル駆動型アプリ、Power Automateクラウドフロー、Dataverse、および連携するAPIを主な対象とします。Microsoft公式資料を2026年10月14日に確認しています。推奨構成、共通スキーマ、コード例、受け入れ条件は設計提案です。実テナントでの構築・動作検証は行っていません。
1. 結論：中央が分析環境を用意し、アプリ側が業務の意味を記録する
企業向けの出発点としては、中央が収集先・権限・ダッシュボードのひな型を提供し、アプリチームが業務イベントと対応手順を整備する方式を推奨します。
基盤担当だけでは、「申請が完了した」「承認をやり直した」「検索結果がなく業務を中断した」といった業務の意味を判断できません。一方、すべてのチームに保存先、権限、費用管理を一から構築させると、品質と統制がばらつきます。中央とアプリ側の得意な役割を組み合わせます。
最初に決めるべき事項は、次の三つです。
- 収集の責任：標準テレメトリは中央が有効化し、独自の業務イベントはアプリ側が実装する。
- 開示の単位：アプリ、開発チーム、業務システム、環境のどれを閲覧範囲にするかを決める。
- 分析の自由度：決められた指標だけを見る利用者と、詳細ログにクエリを実行する利用者を分ける。
ダッシュボード上でアプリを選択できることと、担当外アプリのデータを読めないことは別の要件です。表示の絞り込みは使いやすさの設計、アクセス制御は保存先・クエリ基盤の権限設計として扱います。
2. アプリ担当者に渡す情報を整理する
2.1 「ログ」を四つに分ける
| 情報の種類 | 答えたい問い | 主な収集方法 | アプリ担当者への提供 |
|---|---|---|---|
| 利用・体験 | どの画面が使われ、どこで待たされているか | 標準指標、画面・セッションのテレメトリ | 日次の利用傾向、画面別の性能 |
| 技術的な実行 | どのフロー、アクション、API、プラグインで失敗したか | 実行履歴、Application Insights、API側の計装 | 障害一覧、処理時間、相関IDを用いた調査 |
| 業務イベント | 申請が成功したか、業務を途中で断念したか | Trace、独自の計装、業務データ | 業務KPI、機能別の完了率、リリース前後比較 |
| 監査・証跡 | 誰がアプリや権限、業務データを変更したか | Purview Audit、Dataverse監査 | 必要な対象・期間に限った開示、監査部門への調査依頼 |
利用テレメトリは業務の完了を保証しません。ボタンが押されたことと、データの保存や承認が完了したことを別々に記録します。Power Automateの管理操作の監査も、各実行の性能ログの代わりにはなりません。監査と実行テレメトリの区別は前の記事を参照してください。
2.2 開発者とアプリ管理者で入口を変える
| 利用者 | 普段の入口 | 必要な掘り下げ | 原則として渡さない権限 |
|---|---|---|---|
| アプリ開発者 | 技術ダッシュボード、保存済みクエリ | 担当アプリの詳細ログ、リリース別分析、依存先との突合 | 全テナントの管理権限、担当外の生ログ |
| アプリ管理者・業務責任者 | 業務KPIと障害サマリー | 発生時間、影響、対応状況、必要に応じた明細 | ログ収集設定の変更、利用者の行動履歴の無制限閲覧 |
| 基盤運営担当 | 全体の健全性、収集状況、費用 | 複数システムの共通障害、収集欠落、容量 | 業務判断をアプリ側に代わって行うこと |
| セキュリティ・監査担当 | 監査・セキュリティの専用基盤 | 特権操作、変更、アクセスの証跡 | アプリの運用ダッシュボードへの不要な証跡配布 |
「アプリ管理者」はここでは業務アプリの運用責任者を指します。Power Platform管理者、環境管理者、Azure管理者と同一の製品ロールではありません。閲覧のためだけに強い管理ロールを付ける設計を避けます。
3. 情報提供の五つの戦略パターン
収集・保存の主体と開示方法を組み合わせると、次のパターンに整理できます。組織全体で一つに統一する必要はありません。
| パターン | 収集・保存の主体 | 開示と分析 | 向く場面 | 主な負担 |
|---|---|---|---|---|
| A. 標準機能の利用 | 製品標準、中央が設定を管理 | 作成者向けMonitor、Live monitor、フロー実行履歴 | 短期調査、少数アプリ、まず始めたい場合 | 長期保存や独自分析の限界 |
| B. アプリチーム別の分析環境 | チームごとのApplication Insights／Log Analytics | チームがWorkbooksとKQLを管理 | 自立した開発組織、責任や保存条件が異なる場合 | 設定・クエリ・費用のばらつき |
| C. 中央集約して直接開示 | 中央のLog Analytics、必要に応じて複数のApplication Insights | リソース単位または行単位の権限でKQLを許可 | 共通の運用基盤と深い分析を両立したい場合 | 権限・帰属情報の設計と検証 |
| D. 中央で加工して提供 | 中央が生ログと提供用データを分けて保存 | 提供用テーブルのKQL、Power BI、必要に応じてSQL | 個人情報・共有処理を含み、生ログの開示が難しい場合 | 加工パイプライン、複製、遅延 |
| E. 共通基盤＋アプリ側の計装 | 中央が標準を提供し、アプリ側が業務イベントを追加 | CまたはDに技術・業務情報を統合 | 多数の開発チーム、企業の継続運用 | 共通仕様とアプリ実装の両方を維持 |
以下では、各パターンの構成と構築方法を具体化します。
4. パターンA：標準機能で担当アプリの状況を見てもらう
4.1 作成者向けの監視情報を有効にする
Power Appsには、作成者が編集権限を持つアプリの指標・ログを閲覧できる監視エクスペリエンスがあります。テナントレベル分析に加え、環境単位の作成者向け分析設定を確認します。利用者の仮名識別子であるEUPIの開示は別設定で、セッションIDやユーザーオブジェクトIDの可視化を管理します。公式資料：Power Appsの指標・推奨事項と作成者向け監視
構築の流れは次のとおりです。
- 中央でテナントレベル分析を有効化し、対象環境の設定を確認する。
- 担当アプリに編集権限を持つ開発者で監視画面を開き、見えるアプリと指標を確認する。
- EUPIは利用目的と開示対象を決めたうえで、必要な環境にだけ有効化する。
- 閲覧専用の業務責任者には、編集権限を与える方式で足りるかを検討し、適さなければDのレポート提供に進む。
管理用PowerShellでの設定確認・変更例です。実行者には対応する管理権限が必要です。
Get-AdminPowerAppEnvironmentMakerAnalyticsSettings -EnvironmentName '<environment-id>'
Set-AdminPowerAppEnvironmentMakerAnalyticsSettings -EnvironmentName '<environment-id>' -EnableAnalyticsForMakers $true
EUPIの開示を有効にする設定は別途-EnableEUPIForMakerAnalytics $trueです。上の設定だけで利用者識別情報も開示されると解釈しないでください。
4.2 個別の障害はLive monitorと実行履歴で調べる
Power AppsのLive monitorは、操作を再現しながら通信やイベントを確認する入口です。継続的な全アプリの長期保管先としてではなく、特定セッションを診断するために利用します。公式資料：Live monitor
Power Automateでは、フローの所有者・共同所有者が実行履歴を確認できます。共同所有者には編集などの権限も含まれるため、「履歴だけ見せたい」要件と照合します。実行専用ユーザーへの共有を、すべての履歴への閲覧専用権限と同じものとして扱わないでください。履歴の入出力には業務データが含まれるため、セキュアな入力・出力設定も確認します。公式資料：クラウドフローの共有
ソリューション対応クラウドフローなら、DataverseのFlowRunとAutomation centerも利用候補です。FlowRunはDataverseのRBACで管理でき、既定の保存は28日ですが、容量や取り込みの制約があります。FlowRunを使う場合にも、対象担当者に必要な行が見え、担当外の行が見えないことを実ユーザーで確認します。公式資料：Dataverseのクラウドフロー実行履歴
このパターンで不足するのは、長期間の履歴、独自の業務指標、任意の結合・クエリ、AzureのAPIとの横断分析です。それらが必要になったアプリから、次のパターンへ移します。
費用の見方：既存ライセンスで利用できる標準の画面・履歴だけを使うなら、外部ログ基盤の料金は発生しません。ただしFlowRunはDataverse容量を消費し、追加の有料機能を使う場合はライセンス条件を確認します。権限設定、問い合わせ対応、短い保持期間内に行う調査の工数は必要です。詳細は第13章で比較します。
5. パターンB：アプリチームごとに分析環境を持たせる
5.1 保存先と運用責任をチーム単位にする
構成は「アプリ・API → チーム用Application Insights → チーム用Log Analytics → Workbooks／KQL」です。中央は命名、権限、保持、費用の最低基準を定め、チームが自身のダッシュボードやアラートを運用します。
ワークスペースまで分けると、閲覧範囲や保存条件を説明しやすくなります。Application Insightsだけを分けて共通ワークスペースに接続する方式もありますが、ワークスペース全体の閲覧権限を付けると他チームのデータも見える可能性があります。保存先の集約と閲覧範囲は別々に決めます。公式資料：ワークスペースベースApplication Insightsの作成、Log Analyticsのアクセス管理
5.2 キャンバスアプリの構築手順
- 中央またはチームがLog Analyticsワークスペースと、接続するApplication Insightsを作成する。
- 管理者がテナント設定のCanvas app insightsを確認する。
- 開発者がPower Apps StudioでAppオブジェクトにApplication Insightsの接続文字列を設定する。
- アプリを保存・公開し、公開済みアプリを実行して画面を遷移する。
- Application Insightsで利用情報とTraceイベントの到着を確認する。Studio内のプレビューは送信確認に使わない。
- チームの閲覧グループ、ダッシュボード、保持設定、費用通知を整える。
接続文字列の宛先によって別テナントにも送信できるため、アプリの移送・インポート後は宛先を確認します。接続文字列はログを読む権限ではありませんが、クライアントからの送信先設定として保護・点検が必要です。公式資料：キャンバスアプリのApplication Insights連携
5.3 モデル駆動型アプリとフローは環境の境界に注意する
管理センター経由のDataverse／モデル駆動型アプリ／Power Automateのエクスポートは、キャンバスアプリごとの接続設定とは異なります。Managed Environments、Dataverseデータベース、設定者の管理権限、Azure側の権限などが前提です。複数環境を一つのApplication Insightsに混在させると標準レポートが正しく動作しないと案内されているため、原則として環境ごとに分けます。公式資料：Application Insightsへのデータエクスポート
チームごとにPower Platform環境が分かれている場合は、この方式を適用しやすくなります。同じ環境に複数チームのアプリがある場合は、環境のログをそのまま一つのチームへ渡す設計にはできません。CまたはDで、アプリへの帰属と開示を設計します。監視権限を分けるためだけに環境を分割する場合も、ALM、接続、ライセンス、共有データへの影響まで評価します。
費用の見方：主な継続費用はログ取り込み、無料期間を超える保持、アラートです。ワークスペースベースのApplication Insightsと接続先Log Analyticsに、同じログの取り込み費用を二重計上しません。チーム別に分けること自体より、総ログ量、複製の有無、各チームが維持する設定・ダッシュボードの工数が効きます。
6. パターンC：中央に集め、開発者へ直接クエリ環境を開示する
このパターンには、二つの異なる権限モデルがあります。
6.1 C1：Application Insightsリソース単位で分ける
Log Analyticsのアクセス制御モードをUse resource or workspace permissionsとし、アプリ担当者には対象Application Insightsリソースの必要な読み取り権限を付け、リソースを対象とするLogsやWorkbooksを入口にします。中央はワークスペース全体への権限を持ちます。公式資料：アクセスモードとリソース権限
構築時には、Application Insightsごとの_ResourceIdと開示範囲が一致すること、ワークスペースや上位のリソースグループ・サブスクリプションから広い閲覧権限が継承されていないことを確認します。
この方式の境界はApplication InsightsというAzureリソースです。Power AppsのアプリIDではありません。 同じInsightsにAとBのログが入っていれば、Aの担当者にそのInsightsの閲覧権限を付けてもBだけを隠すことはできません。環境単位のDataverseエクスポートを、これだけでアプリ単位に分離できると考えないことが重要です。
6.2 C2：共通テーブルに行単位のアクセス条件を付ける
Log AnalyticsにはGranular RBACがあり、ロール割り当ての条件によってテーブル・行単位の閲覧を制御できます。アプリ担当者に中央の共通ワークスペースで自由なKQLを実行させながら、認可された行だけを返す方式です。公式資料：Granular RBAC
構築の手順は次のとおりです。
- 提供対象のテーブルと、行の開示先を示す列を決める。例として文字列の
AccessScopeIdを用意する。 - 中央が管理する台帳と収集処理で、この列を確実に設定する。アプリから送られた自己申告だけで開示先を決めない。
- ワークスペースのアクセス制御モードを
Require workspace permissionsにする。 - Entra IDの閲覧グループに、条件付きのLog Analytics Data Readerなどを割り当てる。許可テーブルと許可する
AccessScopeIdを明示する。 - 無条件で全データを読める既存・継承ロールを調べ、開示対象ユーザーから取り除く。Azure RBACは権限が加算されるため、条件付きロールを追加するだけでは既存の広い権限を狭められない。
- ダッシュボードと直接クエリの両方で、担当外・帰属不明の行が返らないことを確認する。
この方式はC1と同じ設定のまま追加するものではありません。公式資料では、Granular RBACをリソースを対象とするクエリでも適用するには、関連するワークスペースをRequire workspace permissionsにする必要があります。Use resource or workspace permissionsでは、リソースの読み取り権限がログ全体への経路になり、ワークスペースのABAC条件が使われない場合があります。公式資料：Granular RBACのFAQ
標準ログではアプリID等がPropertiesというdynamic型の中に入ることがあります。設計例のAccessScopeIdが既定で存在するわけではありません。行単位の条件に使える列・型と、対象テーブルの変換対応を確認し、不足する場合はDで文字列列を持つ提供用テーブルを作ります。保存済みKQL関数でextendした列を、永続列に対する権限条件の代わりにしないでください。
Granular RBACはクエリ時の制御です。データエクスポート先に同じ条件が自動的に引き継がれるわけではありません。また、対応するApplication Insightsはワークスペースベースで、条件付きアクセスを使うログアラートはマネージドID方式に対応範囲が限定されます。利用クラウド、アラート、複製先まで含めて適用条件を確認します。公式資料：Granular RBACの留意事項
費用の見方：Bと同じログ量・プラン・保持条件なら、中央集約だけで取り込み料金が大きく下がるわけではありません。C1はリソースと権限の管理、C2は行の帰属付与と条件の検証に工数がかかります。Analyticsプランの通常の対話型KQLにはスキャン量に応じた追加料金がないため、開発者が深く調べる用途に適しています。大量収集時のコミットメント価格は、実際の日量を確認して判断します。
7. パターンD：中央で生ログを加工して、提供専用データを作る
生ログを直接開示しにくい場合や、標準ログだけでは権限条件に必要な帰属情報を付けられない場合は、提供用データを別に作ります。
生ログと提供用データを同じワークスペースに置くなら、テーブル・行の権限を確実に分けます。設定を単純化したい場合は、提供専用ワークスペースを開示先のチームごとに分けます。ワークスペースを分けても、複製の費用と保管責任は増えます。
7.1 加工パイプラインを構築する
- 中央が対象ログ、必要な列、開示先、遅延の許容値を決める。
- Azure Functions等の収集処理を用意し、認可されたIDで生ログを取得する。
- アプリ台帳と照合して
ApplicationKey、AccessScopeId、サービスの担当者を付ける。機密情報を除去し、コード体系を正規化する。 - 提供用Log Analyticsなら、カスタムテーブル、Data Collection Rule（DCR）、Logs Ingestion APIの送信経路を作る。取り込みIDにはDCRに対する必要な送信権限を付け、閲覧者の権限とは分ける。
- 提供先の閲覧権限、保持期間、監査、ダッシュボードを設定する。
- 収集の遅れ・失敗・未分類データを中央の監視対象にする。
Logs Ingestion APIはDCRに従ってデータを取り込みます。公式の構成例ではDCRにMonitoring Metrics Publisherを付与します。エンドポイントはDCRまたはDCEを用い、Private Link等の要件によってDCEが必要になります。公式資料：Logs Ingestion API
中央の全件を読む収集IDの資格情報を、開発者の端末やアプリ内に配布してはいけません。収集処理は中央のサービスとして運用し、閲覧者は加工後のデータだけにアクセスさせます。
7.2 データ取得経路を混同しない
| 経路 | 適する用途 | 構築時に確認すること |
|---|---|---|
| Azure MonitorのログをAPIで定期取得して加工 | アプリ帰属を付けた明細・集計の提供 | クエリの時間範囲、上限、分割、遅着、再実行 |
| Log Analyticsのデータエクスポート | 対応テーブルの新規データをStorage／Event Hubsへ継続転送 | 対応テーブル、転送費用、転送先の権限 |
| Power Platformのセルフサービス分析エクスポート | Power Appsのインベントリ・利用データをData Lakeで長期分析 | プレビューの前提、ADLS Gen2、対象データ、初期設定 |
| FlowRunをDataverse API等で取得 | ソリューション対応フローの実行メタデータ分析 | 権限、TTL、容量、取り込み制約 |
Log Analyticsのデータエクスポートは、アプリごとのwhere条件を指定して配る機能ではありません。標準の転送はテーブルの新規データが対象で、過去データの一括移送でもありません。必要な分類・除去は対応する変換や後段の処理として設計します。転送先には元の行単位の閲覧条件も引き継がれません。公式資料：Log Analyticsデータエクスポート
Power Platformのセルフサービス分析エクスポートは、Power Appsの台帳・利用データを扱う経路です。Application Insightsの詳細な実行・エラーログをすべて取得できる経路と解釈しないでください。公式資料：セルフサービス分析エクスポート（プレビュー）
定期取得する場合は、最後に取得したイベント時刻だけを記録する方式では遅着データを取りこぼします。再取得する時間幅とチェックポイントを設け、元イベントID等で重複を管理します。Log Analyticsへの再送は自動の上書き・重複排除を前提にできないため、集計側で重複排除するか、提供処理に冪等性を持たせます。
7.3 Power BIと自由なクエリは別の入口にする
アプリ管理者には、業務KPIと障害の傾向をPower BI等で提供できます。セマンティックモデルにアプリと閲覧者の対応を持たせ、RLSを設定します。ただしPower BIのRLSは、ワークスペースのAdmin、Member、Contributorには適用されません。閲覧者のロールと共有方法を合わせて設計します。公式資料：Power BIのRLS
レポートの利用者に、自由なKQLやSQLを実行する機能まで自動的に付くわけではありません。開発者には提供用Log Analytics等を別途開示し、分析基盤側で閲覧範囲を制限します。生ログのStorage、分析用テーブル、セマンティックモデルそれぞれの権限を確認し、Power BIのRLSを迂回して元データを読む経路を残さないようにします。
費用の見方：生ログに加え、加工処理、提供用データの取り込み・保持、採用する転送経路、Power BI等のライセンスが増えます。明細を複製するか、集計結果だけを提供するかで差が出ます。Power BIは既存のPro権利や適格な容量を使える場合と、新たに全閲覧者へライセンスを用意する場合を分けて見積もります。
8. パターンE：共通の監視基盤に、アプリ固有のログを載せる
Eは、中央集約や加工済みデータ提供に、アプリ側の計装を組み合わせる運用方式です。「アプリ側で準備してもらう」とは、保存基盤をすべて任せることではなく、業務の意味と調査に必要な情報を、共通ルールで記録してもらうことです。
8.1 中央からアプリチームへ渡すもの
- 利用可能な収集経路と、開発・検証・本番の送信先。
- 共通イベント仕様、個人情報を含めない実装例、ログの重要度の基準。
- アプリ別Workbooks、保存済みKQL、問い合わせ時に提示する相関IDのひな型。
- 閲覧グループ、保持・費用の基準、収集障害時の連絡先。
- リリース前の確認項目と、ログに関する変更管理の手順。
アプリ側は、業務イベントの定義、計装、業務成功の判定、エラー対応、リリース情報を受け持ちます。中央は、保存先、収集、認可、共通ダッシュボード、基盤の健全性を受け持ちます。
8.2 共通ログスキーマの設計例
以下はこの記事の独自仕様です。製品標準の列名ではありません。
| 項目 | 記録する内容 | 設計上の理由 |
|---|---|---|
SchemaVersion |
共通仕様の版 | 新旧ログを解析する |
EnvironmentId |
実環境のID | 同じアプリの検証・本番を区別する |
ApplicationKey |
台帳で管理する業務アプリの識別子 | UI、フロー、APIを業務アプリとしてまとめる |
SourceResourceId |
アプリID、フローID、AzureリソースID等 | 元の技術リソースへ戻れるようにする |
AccessScopeId |
中央が認可に使う閲覧範囲 | 分析用のアプリ名と認可の根拠を分ける |
EventName |
RequestSubmitted等の安定した名称 |
自由文に依存せず集計する |
Outcome / ErrorCode |
成功、失敗、中断と分類コード | 技術エラーと業務上の不成立を区別する |
CorrelationId / RunId |
一連の業務操作と実行のID | UIからフロー・APIまでたどる |
ReleaseVersion / DurationMs |
アプリの版と処理時間 | リリースの影響を比較する |
EventTime / ReceivedTime |
発生時刻と受信時刻 | 遅着・収集停止を識別する |
アプリ側でApplicationKeyを送っても、中央は登録済みの送信元との整合を確認します。クライアントが送った値だけで別のアプリのAccessScopeIdを名乗れる設計にしないことが重要です。
8.3 キャンバスアプリのTrace実装例
キャンバスアプリではPower FxのTraceを用いて、独自の診断情報を記録できます。Application Insightsに接続している場合は、その宛先で分析できます。公式資料：Trace関数
Trace(
"RequestSubmitted",
TraceSeverity.Information,
{
SchemaVersion: "1",
ApplicationKey: "expense-request",
CorrelationId: varCorrelationId,
ReleaseVersion: "2026.10.1",
Outcome: "Succeeded"
}
)
varCorrelationIdは、例えば申請操作の開始時にSet(varCorrelationId, Text(GUID()))で作り、呼び出すフローやAPIへ引き渡す設計とします。上のTraceは、クリック直後ではなく、定義した保存処理の成功を確認した箇所に置きます。入力チェックで止まった場合、保存に失敗した場合、送信後の承認が完了した場合は、異なるイベントとして記録します。
この例には氏名、メール、申請本文を含めていません。ただし標準のテレメトリにも識別情報等が含まれ得るため、独自項目だけでなく、実際に到着した標準ログも確認します。Traceは診断用の記録であり、業務データの保存や監査証跡の保証には使いません。
8.4 モデル駆動型アプリ、プラグイン、フローの追加計装
モデル駆動型アプリの標準連携は、フォームやグリッド等の性能調査に使えますが、保存イベントとリボンコマンドは標準収集の対象外と明記されています。独自ボタンの業務成功や中断は、必要な箇所に追加計装します。公式資料：モデル駆動型アプリとDataverseのテレメトリ
Dataverseのプラグインでは、Application Insights連携を有効にしたうえでMicrosoft.Xrm.Sdk.PluginTelemetry.ILoggerを使う方法があります。ITracingServiceによるプラグイントレースとは用途が異なり、補完して利用します。プラグイン内部の業務判定を記録する箇所と、同期処理への負荷を確認します。公式資料：ILoggerによるテレメトリ
Power Automateの標準エクスポートは、実行がRequests、トリガーとアクションがDependenciesに入ります。業務固有の分岐理由まで必要なら、共通のログ受付APIやログ用子フローを追加する設計を検討します。認証、DLP、コネクタのライセンス、要求数、ログ送信失敗時の扱いまで決めます。公式資料：Power AutomateとApplication Insights
フローでは本処理のScopeと、失敗・タイムアウト等に応じて実行する記録処理を設ける方法があります。ただし、トリガー前の失敗、フローが開始しない場合、キャンセルなどはフロー内の記録だけで捕捉できるとは限りません。標準テレメトリや外部の監視と併用します。診断ログの送信に失敗したときに業務まで失敗させるかも、事前に決めておきます。
費用の見方：EはCまたはDに追加する方式なので、それらの基盤費用に、業務イベントの増加分とアプリ側の実装・維持工数を足します。ログ受付APIや子フローを使う場合は、その実行・要求数・コネクタのライセンスも対象です。中央で共通部品を用意すれば各アプリの重複開発を減らせますが、共通部品の保守責任は残ります。
9. アプリとログの対応を管理する
9.1 業務アプリは単一リソースではない
一つの申請アプリが、複数フロー、共通のDataverseテーブル、Azure Functions、外部APIを使うことがあります。逆に、一つの共通フローやAPIが複数アプリから呼ばれる場合もあります。
そのため、中央に「業務アプリ → 技術リソース → 開示範囲」の台帳を持ちます。最低限、業務アプリの識別子、環境ID、アプリID、フローID、API、担当グループ、閲覧グループ、共有処理の扱いを登録します。表示名だけで結合すると、改名・移行・同名アプリで誤分類します。
9.2 共有する処理のログをどう見せるか
共通APIの全件を、そのAPIを呼ぶすべてのアプリチームに渡すと、別業務の情報も見えます。共有処理は次のように扱います。
- 呼び出し元を確実に識別できるログは、呼び出し元の開示範囲に割り当てる。
- 複数業務にまたがる障害情報は、機密項目を除いた共通の障害サマリーとして提供する。
- 帰属を確定できない行は、中央だけが調査できる領域に保留する。
Dataverseのサーバー処理を、テーブル名やプラグイン名だけで特定のアプリへ割り当てないようにします。同じテーブルを複数アプリや自動処理が使う場合、アプリIDがないログの帰属は一意に決まりません。
相関IDは調査をつなぐための情報です。ログを読む権限や利用者本人であることの証明にはなりません。Power Apps、フロー、APIをまたぐ相関も自動的に成立すると仮定せず、引き渡す項目と実際のログを確認します。
10. ダッシュボードと個別クエリを提供する
10.1 共通ダッシュボードの構成
Azure Monitor Workbooksを技術的な分析の入口にし、アプリ・環境・期間・リリースで絞り込めるひな型を配布します。共有にはWorkbook自体と参照先データへの権限が必要です。URLを渡すだけでは読めるようになりません。公式資料：Workbooksの共有と管理
| ページ | 表示する内容 | 次の行動 |
|---|---|---|
| 概要 | 利用、観測された失敗、処理時間、業務完了、最終受信時刻 | 影響のあるアプリ・期間を選ぶ |
| 障害 | エラーコード、フロー・アクション、版、相関ID | 失敗の明細や実行履歴へ進む |
| 性能 | 画面・依存先の処理時間、p50／p95、タイムアウト | 遅い処理とリリース差を調べる |
| 利用・業務 | 利用機能、完了・中断、必要に応じた仮名の利用者集計 | 改善箇所を決める |
| ログ品質 | 到着遅延、未分類率、重複、収集停止、量・費用 | 収集の問題を業務障害と切り分ける |
すべてのアプリで同じ指標が取れるわけではありません。欠けている指標をゼロとして表示せず、「未計装」「未対応」「未到着」を区別します。各指標に、定義、対象ログ、集計の時間帯、サンプリング・欠落の扱い、更新時刻を添えます。
10.2 KQL例：アプリの独自イベントを調べる
以下はLog Analyticsワークスペースのテーブル名を使った例です。Application Insights画面のtraces／requestsと、ワークスペースのAppTraces／AppRequestsでは名前と列が異なります。例は実データで未検証のため、まず数行を取得し、列とプロパティ名を確認して調整してください。公式資料：Application Insightsのデータモデル
// 前章の独自Traceを送信した場合の例
AppTraces
| where TimeGenerated > ago(7d)
| where tostring(Properties["ApplicationKey"]) == "expense-request"
| where Message == "RequestSubmitted"
| extend Outcome = tostring(Properties["Outcome"]),
ReleaseVersion = tostring(Properties["ReleaseVersion"])
| summarize ObservedEvents = count()
by bin(TimeGenerated, 1d), Outcome, ReleaseVersion
| order by TimeGenerated asc
ApplicationKeyは独自項目です。自動収集されるPower AppsのアプリIDにはms-appId等の製品固有項目があるため、独自ログと標準ログを台帳で正規化します。このwhereは分析の条件であり、担当外データを保護する権限設定ではありません。
10.3 KQL例：担当フローの失敗傾向を調べる
let targetEnvironment = "<environment-id>";
let targetFlow = "<flow-id>";
AppRequests
| where TimeGenerated > ago(7d)
| where tostring(Properties["resourceProvider"]) == "Cloud Flow"
| where tostring(Properties["signalCategory"]) == "Cloud flow runs"
| where tostring(Properties["environmentId"]) == targetEnvironment
| where tostring(Properties["resourceId"]) == targetFlow
| summarize ObservedRuns = count(),
ObservedFailures = countif(Success == false),
P95DurationMs = percentile(DurationMs, 95)
by bin(TimeGenerated, 1h)
| extend ObservedFailureRatePct =
100.0 * ObservedFailures / ObservedRuns
フローの識別には環境IDとフローIDを組み合わせます。標準のOperation Nameを利用する分析では、これがフロー識別子に対応することも確認します。アクション／トリガーはAppDependenciesを調べ、同じ環境・フローに絞り込んでから分析します。公式資料：Power Automateテレメトリの項目とクエリ
この例の件数・失敗率・p95は保存された観測ログに基づく値です。サンプリングがある場合はItemCount等の重みを考慮する集計と、処理時間の統計方法を再設計します。欠落したデータまで復元できるわけではありません。業務の全実行件数や正確な成功率は、実行履歴・業務データと照合します。
10.4 KQL例：加工済みログを業務単位でたどる
以下はDで作成した独自テーブルAppTelemetry_CLの例です。標準で存在するテーブルではありません。TimeGenerated、ApplicationKey、CorrelationId等の列を持つ設計を前提にします。
AppTelemetry_CL
| where TimeGenerated > ago(2d)
| where ApplicationKey == "expense-request"
| where CorrelationId == "<correlation-id>"
| project TimeGenerated, SourceResourceId, EventName,
Outcome, ErrorCode, ReleaseVersion
| order by TimeGenerated asc
開発者には、入門用の保存済みクエリと、自分で変更できるクエリ環境を両方提供します。時間範囲と対象を最初に絞り、必要な列だけを取得する例を示すと、費用・応答時間・不要な情報取得を抑えられます。
11. 中央基盤を構築する実務手順
11.1 収集先を用意する
- 開発・検証・本番の扱い、データ分類、開示先を決め、Log Analyticsの分割単位を選ぶ。
- キャンバスアプリのアプリ別収集先と、環境エクスポート用の収集先を区別してApplication Insightsを作る。
- 閲覧グループと、収集設定を変更できる管理グループを分ける。
- テーブルごとの保持、利用するテーブルプラン、量・費用の監視を設定する。
長期の自由な結合・分析とリソースを対象とするクエリが要件なら、必要なテーブルに適したプランを選びます。Basic／Auxiliaryプランは、Analyticsプランと同じクエリ機能・アクセス方式を前提にできません。公式資料：Log Analyticsのアクセス方式とテーブルプランの制約
11.2 標準エクスポートを有効にする
管理センターのManage → Data export → App Insightsでパッケージを作成し、データ種別、環境、Azureサブスクリプション、リソースグループ、Application Insightsを選びます。Power Automateでは実行・トリガー・アクションを選択します。Managed Environmentsと対象ユーザー・フローのライセンス条件、Dataverseデータベース、設定者の権限を事前に確認します。公式資料：エクスポート設定、Managed Environmentsのライセンス
この連携はApplication Insightsのローカル認証を必要とします。Azure側でローカル認証を禁止している場合、方針との適合を確認する必要があります。独自APIをEntra ID認証にしても、標準エクスポートの前提が置き換わるわけではありません。
公式資料では、この管理センター経由のテレメトリ配信SLAは24時間で、初期設定後の送信開始も24時間以内とされています。またPower Automateのエクスポートはパブリックプレビューです。数分以内の障害通知が必要な場合は、この経路のログアラートだけで要件を満たすと判断せず、アプリ／API側の通知・計装を追加します。この24時間の説明を、キャンバスアプリの直接送信等に一律に適用しないでください。公式資料：提供条件と配信SLA
11.3 開示方式を設定し、受け入れ確認を行う
C1ならリソースごとの権限、C2なら条件付きのテーブル・行の権限、Dなら提供用データと保存先を構築します。その後、アプリ別Workbooksとクエリ例を渡し、次の条件を確認します。
| 確認 | 合格の目安 |
|---|---|
| 基本収集 | 代表的な画面遷移、成功、意図した失敗、フロー実行のログが確認できる |
| 担当範囲 | A担当者はAを読める。条件を外した直接クエリや別テーブルの検索でもBを読めない |
| 共有処理 | 共通API等のログから、担当外の業務データが漏れない |
| 不明データ | アプリ帰属が不明・空の行は、一般の担当者に開示されない |
| 遅延・欠落 | 発生時刻と到着時刻を測り、遅着時の表示・アラートを説明できる |
| 複製と再実行 | 収集を再実行しても二重計上せず、失敗から再開できる |
| 変更・異動 | 担当変更、アプリ移送、フロー複製、退職に合わせて台帳・権限・送信先を更新できる |
権限の確認は、中央管理者のアカウントだけで行ってはいけません。実際に開示する権限だけを持つユーザーで、Logs、Workbooks、API、レポートの各経路を確認します。
12. 全体を通しての留意事項
12.1 利用者の行動ログを必要な範囲に限定する
氏名、メール、入力本文、顧客情報、トークン、HTTPヘッダーなどを無条件にログへ入れないようにします。ログの自由文とエラーメッセージにも機密情報が混入します。利用者単位の分析が必要なら、目的、閲覧者、保持期間、仮名化を決めます。仮名のIDでも長期の行動を結び付けられることを踏まえ、集計だけで目的を満たせるかを検討します。
ダッシュボード、ダウンロードしたCSV、通知メール、Teamsの通知、問い合わせ票への転記も情報開示です。生ログを制限していても、通知本文や複製先に同じ情報を載せれば別の経路で開示されます。
12.2 テレメトリの欠落と「ゼロ件」を区別する
Power AutomateのApplication Insightsテレメトリは非トランザクションデータで、欠落がないことを保証しません。厳密な実行確認はPower Automateの実行履歴等を参照します。Dataverse／モデル駆動型アプリのテレメトリにも、サンプリングやパイプライン由来の欠落があり得ます。公式資料：Power Automateの欠落に関する注意、Dataverseテレメトリの注意
「失敗がゼロ」と「ログが届いていない」を区別するため、最終受信時刻、対象リソースの数、未分類率を表示します。利用頻度が低いアプリでは、無通信だけで障害と判断しないよう、予定実行やテストイベントと組み合わせます。
12.3 共通の時刻・ID・版を維持する
保存時刻はUTCを基準にし、日本時間の日次集計では日付境界を明示します。イベント時刻と到着時刻を分け、遅着によって翌日に集計が変わることを説明します。アプリやフローを本番へ移送したら、環境ID・リソースIDと台帳の対応、接続文字列、閲覧グループを更新します。
リリース番号を記録すると、不具合の増加が変更と一致するかを確認できます。アプリ名、フロー名、自由文のエラーメッセージだけに依存した集計は、改名や言語によって壊れやすくなります。
12.4 費用をログのライフサイクル全体で管理する
費用は、取り込み、保持、テーブルプランによるクエリ、エクスポート、加工処理、複製先、レポートのライセンスまで含めて見積もります。日量に加え、調査時の詳細ログ、開発時の大量Trace、複製した提供用データを考慮します。
通常時と障害調査時で記録レベルを変える設計や、必要な業務イベントを絞る設計を検討します。ただしコスト制御でログが減った場合、ダッシュボードの件数や成功率の解釈も変わります。上限やサンプリングの設定を、分析担当者にも共有します。
12.5 ログを読む操作と権限変更を監査する
Log Analyticsではクエリの監査を有効にでき、ワークスペースに送る場合はLAQueryLogsに保存されます。クエリ本文に機密値が書かれる場合もあるため、監査ログの開示範囲も別に設定します。公式資料：ログクエリの監査
アプリの閲覧グループ、上位スコープからの権限継承、サービスID、エクスポート先の権限を定期的に点検します。担当者の異動・委託終了時は、Power Platform側だけでなくAzure・Power BI・複製先の権限も見直します。
13. 各パターンの費用と見積もり方法
13.1 既存費用と、今回増える費用を分ける
費用は「初期構築」「毎月のサービス・ライセンス」「毎月の運用工数」に分けて比較します。既に支払っているアプリの利用ライセンスを、監視導入による追加費用として全額計上しないようにします。一方、監視機能を使うためにManaged Environmentsを導入し、対象ユーザーのライセンスを追加する場合は、その差額を含めます。
Managed Environmentsは対象ライセンスの権利に含まれますが、管理者一人のライセンスだけで環境内の全利用者をカバーできるとは限りません。アプリ・フローを利用するユーザーや、割り当てる容量ベースのプランの条件を確認します。公式資料：Managed Environmentsのライセンス条件
| パターン | 初期構築で必要な作業 | 毎月増える主な費用 | 費用が増えやすい条件 |
|---|---|---|---|
| A. 標準機能 | 分析設定、権限確認、調査手順の整備 | 既存権利内なら外部ログ基盤は0円。FlowRunの容量、条件に応じた追加ライセンス、調査工数 | 履歴の手動回収、担当者ごとの調査、Dataverse容量不足 |
| B. チーム別 | チームごとのInsights／ワークスペース、ダッシュボード、通知 | 各チームの取り込み・保持・アラート料金と維持工数の合計 | 設定の重複、同じログの複製、環境別の過剰な収集 |
| C1. リソース単位で中央集約 | アプリ別Insights、中央保存、リソース権限、共通Workbook | 取り込み・保持・アラート、中央の共通運用工数 | アプリ別アラートの大量作成、共有APIの追加開示処理 |
| C2. 行単位で中央集約 | 帰属列、条件付きロール、権限の受け入れ確認 | C1と同種のログ費用、帰属・権限の維持工数。正規化のために複製すればその追加費用 | 複雑な共有処理、台帳変更、広い権限の継承、提供テーブルの追加 |
| D. 加工して提供 | 取得・加工・再送、提供用保存先、レポート、再実行対策 | 生ログ＋提供データ、加工処理、必要な転送、Power BI／分析基盤、運用工数 | 全明細の複製、長期保持、頻繁な更新、多数のレポート閲覧者 |
| E. 共通基盤＋計装 | C／Dの構築に加え、共通部品と各アプリの計装 | C／Dの費用＋業務イベント増加、受付API／子フロー、計装の維持 | 全操作の詳細記録、巨大なログ本文、アプリごとの独自実装 |
この表の初期作業・工数の比較は、この記事の設計評価です。製品の定価や、導入作業の市場価格を示すものではありません。
13.2 Azureのログ料金で押さえること
ワークスペースベースのApplication Insightsでは、取り込み・保持は接続先Log Analyticsで課金されます。「Insightsで保存し、さらにLog Analyticsで同じデータを保存する二段階の料金」とは扱いません。別テーブルや別ワークスペースへ加工結果を再取り込みする場合は、追加の取り込み対象になります。公式資料：Application Insightsの課金
| 費目 | 見積もりの単位 | このレポートの構成での注意 |
|---|---|---|
| 取り込み | 課金対象GB × テーブルプランの単価 | アプリ数よりログ量が効く。元のファイルサイズではなく課金対象量を測る |
| 保持 | 無料期間を超えて保持するGB × GB・月単価 | 取り込み量と、保管中の残量を区別する |
| クエリ | プランに応じたスキャンGB、長期保持の検索等 | Analyticsの通常の対話型検索はスキャン課金なし。Basic／Auxiliaryはスキャン課金あり |
| アラート・通知 | ルール、評価頻度、時系列、通知方式 | ダッシュボードを見る料金と、定期評価・通知の料金を分ける |
| データエクスポート | 転送したJSONのGB | 採用した場合のみ。加工処理のAPI取得と同じ費目ではない |
| 加工・提供 | 実行、計算時間、Storage、Event Hubs、SQL等 | Dの処理方式によって変わる。最低稼働のあるプランも確認する |
自由なクエリを多用する開発者向けの明細では、取り込みが安いという理由だけでBasic／Auxiliaryを選ばず、検索頻度と機能の制約まで含めます。保持の無料期間は、一般のAnalytics Logsでは31日、Application Insightsのデータでは90日が料金表上の対象です。独自の提供用テーブルにも90日の扱いが自動的に付くとは考えないでください。実際の保持設定と対象テーブルを確認します。公式資料：Azure Monitor料金、課金モデルとアラート
2026年10月14日にAzure Retail Prices APIで確認した、Japan East・USD・従量課金の参考単価は、Analytics Logsの有料取り込みが3.34 USD/GB、対話型の追加保持が0.15 USD/GB・月、Log Analyticsデータエクスポートが0.145 USD/GBでした。以下の試算はこの値を使います。実請求は契約、通貨、割引、課金対象量で変わります。公式資料：Retail Prices API
料金表には従量課金の最初の5GB/月の無料枠がありますが、課金アカウント単位です。アプリやワークスペースを増やして5GBずつ積み上げる計算にはしません。また、コミットメント価格は100GB/日からで、実際の使用量が少なくてもコミットした量の費用が発生します。小規模導入では従量課金を基準にし、継続して大きな日量になったときに比較します。公式資料：無料枠、コミットメント価格
13.3 ライセンスの参考価格
日本向け公式料金ページで確認した参考価格です。いずれも年払いの月額相当・税別で、実契約の割引や既存の利用権は含めていません。すべてのプランを購入するという意味ではありません。
| 製品 | 参考価格 | 監視設計で確認する場面 |
|---|---|---|
| Power Apps Premium | 2,998円／ユーザー・月相当 | アプリの利用権、Managed Environmentsの条件、プレミアムな接続を追加する場合 |
| Power Automate Premium | 2,248円／ユーザー・月相当 | 独自のログ送信フロー等で対象の利用権が必要な場合 |
| Power Automate Process | 22,488円／ボット・月相当 | フローへのライセンス割り当て方式を採る場合。クラウドフローの適用条件を別途確認 |
| Power BI Pro | 2,098円／ユーザー・月相当 | Dでレポートを公開・共有し、作成者・閲覧者の権利を追加する場合 |
| Power BI Premium Per User | 3,598円／ユーザー・月相当 | PPUの機能・ワークスペースを利用する場合 |
価格の出典：Power Apps、Power Automate、Power BI。
例えば、既存の権利では足りない100人にPower Apps Premiumを新規に用意するなら、参考価格では299,800円／月相当です。ログ量が少ない構成では、Azureの取り込みよりライセンスの追加が大きくなる場合があります。ただし、既存Premiumや対象のDynamics 365権利等で条件を満たす人まで再購入する計算にはしません。
Power BIも、20人全員に新たにProを用意するなら41,960円／月相当です。Microsoft 365 E5等に含まれるProの権利や、無料ユーザーへの配布が可能な適格な容量を使える場合は追加額が変わります。PPUのレポートをProだけのユーザーへ同じ条件で配布できるとは考えず、ワークスペースと閲覧者の条件を確認します。公式資料：Power BIのライセンス別機能
AzureのLogs／Workbooksで閲覧・分析させる構成では、Power BIのレポート配布を採用しない限り、Power BIの閲覧ライセンスを一律に追加する必要はありません。Azureのデータ権限と各サービスの従量料金を見積もります。
13.4 同じログ量で比較する試算
以下は構成差を理解するための計算例です。生ログ合計10GB/日、30日/月、Analyticsプラン、無料枠・割引は使わず、為替は計算用に1USD＝150円と仮定します。150円は実勢レートではありません。元のログの取り込みだけなら、300GB × 3.34USD ＝ 1,002USD、150,300円／月です。
| パターン・条件 | 計算に含めた月額相当 | さらに必要な費目 |
|---|---|---|
| A：外部へ収集せず、既存権利の標準機能だけ | Azureの外部ログ基盤は0円 | 調査工数、FlowRun容量、条件に応じた追加ライセンス。B以降と同じ分析機能は提供しない |
| B：各チーム合計で生ログ300GB、複製なし | 150,300円 | 各チームの運用、アラート、保持延長、必要なライセンス |
| C1／C2：中央で生ログ300GB、追加の複製なし | 150,300円 | 中央の運用、権限・帰属の維持、アラート、保持延長 |
| D：生ログ300GB＋20%の提供用明細60GBを再取り込み | 180,360円 | 加工処理、提供用保持、採用する転送・分析基盤、レポートの権利 |
| D：上記に、新規Pro利用者20人を追加 | 222,320円 | 上記と同じ。20人は作成者・閲覧者を合わせた新規購入対象の想定 |
| E：Cを基盤とし、業務イベントが10%増えて330GB | 165,330円 | 計装工数、受付API／子フロー、アラート、保持延長、必要なライセンス |
この金額は総額見積もりではありません。 ログの取り込みと表で明示したProだけを比較した部分試算です。C2で行の帰属を付けるためにDと同様のテーブルを複製するなら、その分を追加します。EをDに組み合わせる場合は、Dの加工・提供費用も足します。
10GB/日は説明用で、アプリの数や利用人数から自動的に決まる値ではありません。同じ取り込み単価なら、30GB/月は約15,030円、300GB/月は約150,300円、3,000GB/月は約1,503,000円となります。PoCで課金対象の実測量を取得し、通常時・繁忙期・障害調査時を分けて置き換えます。
13.5 保持・加工・人件費を追加して総額を出す
毎月の総額は、次の項目を足して求めます。
追加月額 ＝ 必要なライセンス差額
＋ 生ログと提供データの取り込み
＋ 無料期間を超える保持
＋ 課金対象クエリ・アラート・通知
＋ 加工・転送・複製先・分析容量
＋ 月次運用時間 × 社内の時間単価
例えばApplication Insightsのデータを10GB/日で180日間、対話型に保持し、料金表上の無料90日が適用される場合、定常状態では追加90日分が概算900GBです。0.15USD/GB・月なら追加保持は約135USD、計算用為替で約20,250円／月となります。立ち上がり直後は保管残量が小さく、実際には日単位で計算されます。独自の提供用テーブル、長期保持プラン、異なる日量では再計算します。
Dで提供用明細を保持する場合は、その取り込み料金だけでなく、そのテーブルの無料保持期間を超える残量も別に見積もります。レポートの集計に必要な項目だけを提供すれば、複製量を減らせます。逆に、全件の明細を同じプランで複製すれば、取り込みの対象量は概ね二倍になります。データエクスポートを採用した場合は、転送したJSON量の料金と転送先の費用も追加します。
構築・運用の人件費には製品の定価がないため、実作業で積み上げます。初期作業には、収集・計装、権限検証、ダッシュボード、再実行対策、引き継ぎを含めます。月次には、権限変更、台帳更新、収集失敗、費用点検、スキーマ変更対応を含めます。例えば社内単価を仮に5,000円/時間、月次運用を10時間と置けば50,000円/月です。この値も導入サービスの市場相場を示すものではありません。
予算管理では、生ログ基盤の共通費、アプリごとの追加ログ、提供データの複製、レポートライセンスを分けると、どのチームの何を改善すべきかが分かります。収集先を分ける／集めるという選択だけでなく、既存権利の活用、記録するイベントの選別、複製するデータの量、維持する仕組みの数で費用を調整する設計にします。
14. 企業向けの導入案
まず、重要なキャンバスアプリ一つ、モデル駆動型アプリ一つ、フロー数本を対象に小規模な導入を行います。目標は、全ログを集めることではなく、アプリ担当者が状況把握から原因調査まで自分で進められることです。
- 標準機能で入口を作る：作成者向け監視、Live monitor、実行履歴を整理し、閲覧のために編集・管理権限を増やす必要がある箇所を洗い出す。
- 中央の分析環境を用意する：キャンバスアプリはアプリ別Insights、環境テレメトリは環境別Insightsを基本とし、LogsとWorkbooksを提供する。
- 開示境界を実装する：Insights単位で足りるならC1、共通ログを直接開示するならC2、生ログが開示しにくければDを選ぶ。
- 業務イベントを追加する：申請・承認・検索等の重要な完了と失敗を、共通仕様でアプリ側に記録してもらう。
- 運用に組み込む：リリース前のログ確認、台帳更新、担当者変更、費用点検、障害対応を通常の開発・運用手順にする。
小規模なアプリはAだけでも運用できます。独立した開発チームにはBが適する場合もあります。多くの企業では、Eを運用方針として、CとDをアプリのデータ分類や環境構成に応じて併用する形が現実的です。
基盤担当は、ログの置き場所と安全に読む仕組みを提供する。アプリ担当は、業務を理解できる記録を追加し、その情報を使って改善と障害対応を行う。この役割分担ができると、監視は基盤担当への問い合わせで終わらず、各アプリの運用品質を継続して高める仕組みになります。