Power Platform inventoryは、Power Platform上で作成されたエージェント、アプリ、フローをテナント横断で把握するための管理者向け機能です。2026年4月24日の公式GitHub履歴では、本文機能の大幅変更ではなく、ドキュメントのメタデータに「AI利用」に関する記述を追加した更新が確認できます。一方で、IT管理者やPower Platformのプロダクトオーナーにとって重要なのは、Power Platform inventoryが「シャドーIT化しやすいローコード資産を、環境・所有者・種類・地域の観点で棚卸しできる基盤」になっている点です。(GitHub)
この記事では、Power Platform inventoryの2026年4月時点の更新ポイント、確認すべき機能、管理現場での使い方、注意すべき制限を整理します。結論から言うと、すでにPower Apps、Power Automate、Copilot Studio、Microsoft 365 Copilot関連の作成物が増えている組織では、まずPower Platform admin centerのInventory画面で「誰が、どの環境に、何を作っているか」を確認し、所有者不在・非承認リージョン・既定環境への集中を優先的にチェックすべきです。
Power Platformの最新動向: Power Platform inventory – Power Platformで何が変わったか
今回取り上げる「Power Platform inventory – Power Platform」は、Microsoft Learnで公開されているPower Platform管理者向けドキュメントです。公式ページ本文の最終更新日は2026年3月27日と表示されていますが、GitHub上の履歴では2026年4月24日に「Add AI usage note to inventory documentation」というコミットがあり、ai-usage: ai-assistedというメタデータが追加されています。つまり、2026年4月24日の更新は、少なくとも公開履歴上では本文の機能説明を大きく変えるものではなく、ドキュメント管理上の注記追加と見るのが妥当です。(GitHub)
ただし、本文で説明されているPower Platform inventoryの内容自体は、管理者にとってかなり重要です。特に、Power AppsやPower Automateだけでなく、Copilot StudioのエージェントやMicrosoft 365 Copilot Agent Builder由来のエージェント、App Builderアプリ、Workflows agentのワークフローまで視野に入っている点は見逃せません。Microsoft Learnでは、Power Platform inventoryが、組織内のPower Platform上で作成されたエージェント、アプリ、フローを統合的に表示し、検索、フィルター、並べ替えによって管理タスクを効率化できる機能として説明されています。(Microsoft Learn)
Power Platform inventoryとは
Power Platform inventoryは、テナント管理者がPower Platform上のリソースを一元的に確認するためのインベントリ機能です。従来、Power Apps、Power Automate、Copilot Studioなどは、それぞれの管理画面で確認する場面が多く、組織全体の「作成物の全体像」をつかみにくい課題がありました。
Power Platform inventoryを使うと、次のような管理作業を1つの観点で進めやすくなります。
| 管理したいこと | Power Platform inventoryで確認する観点 | 実務での使い方 |
|---|---|---|
| 作成物の全体像 | アプリ、フロー、エージェント、環境、環境グループ | 棚卸し、監査準備、運用設計 |
| 所有者の偏り | Owner、Created by | 退職者・異動者の資産引き継ぎ |
| 環境ごとの集中度 | Environment、Environment type、Environment group | 既定環境への作成集中を発見 |
| リージョン管理 | Location | 非承認リージョンの利用確認 |
| サポート対応 | リソース名、ID、種類 | 問い合わせ対象のアプリやフローを特定 |
| ガバナンス強化 | 種類別・環境別の件数 | 管理対象の優先順位付け |
重要なのは、Power Platform inventoryを単なる一覧画面として見るのではなく、「Power Platform運用の初動調査ツール」として使うことです。特に、Power Platformの導入初期から数年経った組織では、誰が作ったか分からないアプリ、使われているか判断しにくいフロー、環境の分散、Copilot Studioエージェントの増加が起きやすくなります。Power Platform inventoryは、そうした状態を可視化する入口になります。
対象となるリソース
Microsoft Learnによると、Power Platform inventoryの対象には、Agents、Apps、Flows、Environments、Environment groupsが含まれます。AppsにはPower Appsのキャンバスアプリ、モデル駆動型アプリ、コードアプリ、vibeアプリ、Microsoft 365 CopilotのApp Builder agentで作成されたアプリが含まれます。FlowsにはCopilot Studioのagent flows、Power Automateのcloud flows、Microsoft 365 CopilotのWorkflows agentで作成されたワークフローが含まれます。(Microsoft Learn)
| 分類 | 含まれる主なリソース | 管理上の注目点 |
|---|---|---|
| Agents | Copilot Studioで作成されたエージェント、Microsoft 365 Copilot Agent Builderのエージェント | 公開前のドラフトも含めた把握が重要 |
| Apps | Canvas apps、Model-driven apps、Code apps、Vibe apps、App Builder apps | 業務利用アプリと試作アプリの切り分け |
| Flows | Cloud flows、Agent flows、Workflows agentのワークフロー | 所有者、接続、業務影響度の確認 |
| Environments | テナント内の環境 | 既定環境、開発環境、本番環境の使い分け確認 |
| Environment groups | 環境グループ | 部門別・用途別の統制設計に活用 |
この対象範囲から分かるように、Power Platform inventoryは従来型の「Power AppsとPower Automateの棚卸し」だけを目的にした機能ではありません。Copilot StudioやMicrosoft 365 Copilot関連の作成物が増えるほど、より重要性が増します。
2026年4月更新で押さえるべきポイント
2026年4月24日のGitHub履歴では、Power Platform inventoryドキュメントにAI利用に関するメタデータが1行追加されたことが確認できます。本文機能の追加・削除が大きく示された更新ではありません。(GitHub)
ただし、管理者が実務上チェックすべき更新ポイントは、ドキュメント本文に示されている次の内容です。
統合インベントリとしての役割が明確になっている
Power Platform inventoryは、Power Platform上のリソースを一元表示する機能です。Microsoft Learnでは、管理者が組織全体のエージェント、アプリ、フローを発見、検索、フィルター、並べ替えできると説明されています。(Microsoft Learn)
これは、Power Platformの利用が部門単位で広がっている企業にとって大きな意味があります。たとえば、経理部門がPower Appsで申請アプリを作り、営業部門がPower Automateで通知フローを作り、カスタマーサポート部門がCopilot StudioでFAQエージェントを作っている場合、管理者はそれぞれを個別に探すだけでは全体像をつかめません。
Power Platform inventoryを使えば、まず全体の件数を把握し、次に環境、所有者、種類、作成日などで絞り込めます。これにより、「どの部門の活動が活発か」「どの環境に作成物が集中しているか」「退職者が所有するリソースが残っていないか」を確認しやすくなります。
作成・更新・削除が比較的短時間で反映される
Power Platform inventoryの主な機能として、作成、更新、削除されたリソースが15分以内に表示されることが説明されています。(Microsoft Learn)
これは監査や障害対応で重要です。たとえば、サポートチケットで「昨日作成したフローが動かない」と報告された場合、管理者はPower Platform inventoryで対象フローを検索し、所有者、環境、作成日時、リソース種別を確認できます。
ただし、「15分以内」はリアルタイム監視と同じ意味ではありません。緊急の障害対応やセキュリティ調査では、Power Platform inventoryだけで完結させず、各サービスの管理画面、監査ログ、Dataverse、Entra ID、DLPポリシーの確認も組み合わせるべきです。
環境グループを含むフィルターと並べ替えに対応している
Power Platform inventoryでは、任意の列や属性を使ってフィルターと並べ替えができます。Microsoft Learnでは、Environment type、Owner、Created onを組み合わせて、既定環境内で特定ユーザーが特定期間に作成したリソースを絞り込む例が示されています。(Microsoft Learn)
実務では、次のような条件で絞り込むと効果的です。
| 調査シーン | 推奨フィルター | 見つけたいもの |
|---|---|---|
| 既定環境の整理 | Environment type = Default | 本来は部門環境や本番環境に移すべきアプリ・フロー |
| 退職者対応 | OwnerまたはCreated by | 所有者変更が必要なリソース |
| コンプライアンス確認 | Location | 利用が認められていないリージョンのリソース |
| Copilot活用状況の確認 | Type = agents | Copilot StudioやAgent Builderで作成されたエージェント |
| 部門別ガバナンス | Environment group | 部門・用途ごとの管理対象 |
特に既定環境は、Power Platformを使い始めたユーザーが最初にアプリやフローを作る場所になりやすいため、管理の優先度が高い領域です。毎月1回、既定環境に新しく作成されたリソースを確認するだけでも、野放しの拡大を防ぎやすくなります。
Power Platform inventoryとMicrosoft 365管理センターの違い
Power Platform inventoryを使う際に混乱しやすいのが、Microsoft 365管理センターに表示されるエージェント数との違いです。
Microsoft Learnでは、Microsoft 365管理センターはユーザーが利用可能なエージェントを表示し、Microsoftのファーストパーティエージェント、サードパーティISVエージェント、組織が公開・共有したエージェントなどを含むと説明されています。一方、Power Platform inventoryはPower Platform上で作成されたエージェントに対象が絞られ、Copilot StudioやMicrosoft 365 Copilot Agent Builderで作成された公開済み・ドラフトのエージェントを含みます。(Microsoft Learn)
| 比較項目 | Power Platform inventory | Microsoft 365管理センター |
|---|---|---|
| 主な利用者 | Power Platform管理者 | Microsoft 365管理者 |
| 表示対象 | Power Platform上で作成されたエージェント | テナント内で利用可能なエージェント |
| ドラフトの扱い | 含まれる | 基本的に公開・共有済みが中心 |
| Microsoft製・ISV製エージェント | 含まれない | 含まれる |
| スコープ | 環境単位をテナントに集約 | テナント単位 |
この違いは、経営層や監査部門へ「エージェント数」を報告するときに重要です。たとえば「社内に存在するAIエージェントはいくつか」と聞かれた場合、Power Platform inventoryの数だけを答えると、Microsoft 365管理センターに表示されるMicrosoft製やISV製のエージェントを含めない集計になります。
報告時は、次のように定義を明確にするのが安全です。
「Power Platform inventoryで確認した数は、Copilot StudioおよびMicrosoft 365 Copilot Agent Builderなど、Power Platform上で組織が作成したエージェントの数です。Microsoft 365管理センターの数は、ユーザーが利用可能なMicrosoft製・サードパーティ製・組織作成エージェントを含むため、件数が異なる場合があります。」
管理者が最初に確認すべき画面と権限
Power Platform inventoryを見るには、Power Platform administratorまたはDynamics 365 administratorのテナント全体管理ロールが必要です。該当ロールがない場合、Inventoryにはアクセスできません。(Microsoft Learn)
Power Platform admin centerでは、主に次の場所から確認できます。
| 入口 | 確認できる内容 |
|---|---|
| Manage > Inventory | テナント横断のメインインベントリ |
| Manage > Copilot Studio | Copilot Studio、Microsoft 365 Copilot Agent Builderのエージェント、agent flows、workflows |
| Manage > Power Apps > App Inventory tab | Canvas、Model-driven、Code、Vibe、App Builderアプリ |
| Manage > Power Automate > Flow Inventory tab | Cloud flows |
最初に見るべきなのは、Manage > Inventoryです。ここで全体像を確認してから、必要に応じてPower Apps、Power Automate、Copilot Studioの各領域に移動すると、調査が散らかりにくくなります。
実務で使えるPower Platform inventoryの確認手順
Power Platform inventoryを導入後に活用するなら、まずは次の順番で確認すると効率的です。
| 手順 | 作業 | 判断基準 |
|---|---|---|
| 1 | 全リソース件数を確認 | 想定より多い場合は棚卸し優先度を上げる |
| 2 | リソース種別で分類 | アプリ、フロー、エージェントのどれが増えているかを見る |
| 3 | 環境別に並べ替え | 既定環境や特定環境への集中を確認 |
| 4 | 所有者で絞り込み | 退職者、異動者、外部ユーザー由来のリソースを確認 |
| 5 | 作成日で絞り込み | 直近で急増している作成物を把握 |
| 6 | リージョンを確認 | 組織のデータ配置ポリシーと合っているか確認 |
| 7 | Excelへエクスポート | 関係者レビューや台帳化に利用 |
たとえば、月次レビューでは次のような流れが現実的です。
まず、前月に作成されたアプリ、フロー、エージェントをCreated onで絞り込みます。次に、Environment typeでDefaultを指定し、既定環境に作成されたものを抽出します。その中から、業務利用されている可能性が高い名称のリソースを確認し、必要に応じて所有者へ用途、利用者、データ接続、移行要否を確認します。
この運用を続けると、「問題が起きてから探す」状態から、「毎月増えたものを軽く確認する」状態へ移れます。Power Platformのガバナンスでは、この差が大きくなります。
よくある活用シーン
退職者・異動者が所有するアプリやフローを探す
Power Platform管理でよくある失敗は、重要なフローの所有者が退職・異動した後に、接続や所有権の問題で業務が止まることです。Power Platform inventoryでは、OwnerやCreated byを手掛かりに対象リソースを探せます。
ただし、Microsoft Learnでは、cloud flowsとagent flowsのOwner列は現在、フローを作成したユーザーを表示し、所有者が変更されても更新されないと説明されています。(Microsoft Learn)
そのため、フローの所有者確認ではInventoryの表示だけで判断せず、Power Automate側の詳細画面や共有設定も確認してください。退職者対応では、次のようなチェックリストを使うと抜け漏れを防げます。
| 確認項目 | 見る場所 | 注意点 |
|---|---|---|
| フローの作成者 | Power Platform inventory | Owner列が現在の所有者と一致しない可能性がある |
| 現在の所有者 | Power Automateの詳細 | 共同所有者の有無を確認 |
| 接続参照 | ソリューション、接続設定 | 個人アカウント依存を避ける |
| 実行状況 | Power Automateの実行履歴 | 業務影響度を判断 |
| 引き継ぎ先 | 部門管理者、システム所有者 | 個人所有からチーム所有へ移す |
非承認リージョンのリソースを確認する
グローバル企業や規制業種では、Power Platformリソースのリージョン管理が重要です。Power Platform inventoryでは、Locationを使ってリソースの地域分布を確認できます。
たとえば、日本法人の業務アプリは原則として日本リージョンまたは会社が承認したリージョンに限定する、といったルールがある場合、Locationでリソースを集計し、想定外の地域に作成されたアプリやフローを調査できます。
ここで重要なのは、単に「海外リージョンだから削除」と判断しないことです。グローバル共通基盤、M&A後の統合環境、部門横断プロジェクトなど、正当な理由がある場合もあります。まずは所有者と用途を確認し、ポリシー違反か、例外承認が必要なケースかを分けるべきです。
既定環境に作られた業務アプリを見つける
既定環境は、ユーザーが気軽にアプリやフローを作り始める場所になりやすい一方、本番業務の運用場所としては管理しづらい場合があります。
Power Platform inventoryでEnvironment typeをDefaultにして絞り込むと、既定環境に存在するアプリ、フロー、エージェントを確認できます。さらにCreated onで直近作成分を絞り込めば、早い段階で作成者に声をかけられます。
声のかけ方も重要です。いきなり「既定環境で作らないでください」と止めるのではなく、次のように確認すると協力を得やすくなります。
「このアプリは業務で継続利用する予定ですか。部門内だけの試作であればそのまま整理対象にできますが、複数名で使う場合は、適切な環境への移行や所有者設定を一緒に確認します。」
Power Platformのガバナンスは、作成を止めることではなく、継続利用するものを安全に運用へ載せることが目的です。
サポートチケットの対象リソースを素早く特定する
Power Platformの問い合わせでは、利用者がアプリ名やフロー名を正確に伝えられないことがあります。Power Platform inventoryの検索機能を使うと、現在UIに読み込まれているリソースをキーワード検索できます。
ただし、検索はUIに表示されているリソースに対して適用され、最大1,000件ずつが対象です。インベントリがこの上限を超える場合は、先にフィルターで対象範囲を絞る必要があります。(Microsoft Learn)
大規模テナントでは、検索ボックスだけに頼らず、次の順番で絞り込むと見つけやすくなります。
| 絞り込み順 | 使う条件 | 理由 |
|---|---|---|
| 1 | リソース種別 | アプリかフローかエージェントかを分ける |
| 2 | 環境 | 部門・用途から候補を減らす |
| 3 | 所有者 | 問い合わせ者や部門担当者で絞る |
| 4 | 作成日・更新日 | 最近作成されたものを特定する |
| 5 | 名前・ID | 最後にキーワード検索する |
プログラムから取得する方法
Power Platform inventoryは、UIだけでなく、プログラムからも利用できます。Microsoft Learnでは、Power Platform for Admins V2 connector、Power Platform API、Azure Resource Graphによる取得方法が紹介されています。(Microsoft Learn)
特に、定期的なレポートや自動監視をしたい場合は、Azure Resource GraphやPower Platform APIの利用を検討する価値があります。
Azure Resource Graphで集計する
Power Platform inventoryのサンプルクエリでは、PowerPlatformResourcesテーブルを使って、全リソース数、種類別件数、環境別件数、リージョン別件数、所有者別件数などを取得できます。(Microsoft Learn)
たとえば、リソース種別ごとの件数を確認する基本クエリは次のような形です。
PowerPlatformResources
| summarize resourceCount = count() by type
| order by resourceCount環境別にリソース数を把握したい場合は、次のように集計できます。
PowerPlatformResources
| extend properties = parse_json(properties)
| extend environmentId = tostring(properties.environmentId)
| summarize resourceCount = count() by environmentId
| order by resourceCount descリージョン別の分布を確認する場合は、次のクエリが使えます。
PowerPlatformResources
| summarize resourceCount = count() by location
| order by resourceCount descこれらのクエリは、Power Platformの管理ダッシュボードを作るときの出発点になります。たとえば、月次で「環境別リソース数」「新規作成リソース数」「所有者別上位」「非承認リージョンの件数」を自動集計すれば、手作業の棚卸しを減らせます。
Power Platform inventory APIを使う
Power Platform inventory APIでは、POSTリクエストの本文にクエリ仕様を渡し、Azure Resource Graphに対する構造化クエリを実行できます。エンドポイントは、POST {PowerPlatformAPI url}/resourcequery/resources/query?api-version=2024-10-01として説明されています。(Microsoft Learn)
APIでは、Where、Project、Take、Order by、Distinct、Count、Summarizeなどの句がサポートされ、KQLの演算子に変換されます。たとえば、特定のリソース種別だけを取得したり、必要なフィールドだけを投影したり、件数を集計したりできます。(Microsoft Learn)
UIで確認するだけならAPIは不要です。しかし、次のような要件がある場合はAPIやAzure Resource Graphを検討してください。
| 要件 | 推奨手段 |
|---|---|
| 管理者が月1回だけ棚卸しする | Power Platform admin center |
| 部門別にExcelでレビューしたい | Inventoryのダウンロード |
| 毎週自動で件数を集計したい | Azure Resource Graph |
| 独自ダッシュボードに組み込みたい | Power Platform API |
| Power Automateで通知や承認に回したい | Power Platform for Admins V2 connector |
スキーマで見るべきフィールド
Power Platform inventory schema referenceでは、PowerPlatformResourcesテーブルに含まれるリソース種別とフィールドが説明されています。リソース種別には、Canvas apps、Model-driven apps、Code apps、App Builder apps、Cloud flows、Agent flows、Workflow agent flows、Copilot Studio agents、Environments、Environment groupsなどが含まれます。(Microsoft Learn)
共通フィールドとしては、表示名、リソース種別、アイテムID、Location、Created on、Created byなどが示されています。環境については、environmentType、isManaged、environmentGroup、environmentGroupId、lastModifiedAtなどが利用できます。(Microsoft Learn)
管理レポートでは、最初からすべてのフィールドを使おうとしない方がうまくいきます。まずは次の項目に絞ると、関係者が読みやすい台帳になります。
| フィールドの観点 | 使い道 |
|---|---|
| displayName | 人が読めるリソース名 |
| type | アプリ、フロー、エージェントなどの分類 |
| name | 一意のIDとして問い合わせや調査に利用 |
| location | リージョン確認 |
| createdAt | 新規作成の追跡 |
| createdBy | 作成者確認 |
| ownerId | 所有者確認 |
| environmentId | 環境別集計 |
| environmentGroup | 部門・用途別の管理 |
なお、スキーマは将来変更される可能性があります。Microsoft Learnでも、利用可能なフィールドを確認するためのクエリ例が示されています。定期レポートを作る場合は、固定の列だけを前提にしすぎず、スキーマ変更時に確認できる手順を残しておくと安全です。(Microsoft Learn)
既知の制限と注意点
Power Platform inventoryは便利ですが、万能ではありません。特に次の制限は、運用設計に直接影響します。
| 制限 | 内容 | 実務上の対策 |
|---|---|---|
| Classic chatbots | 新しいInventoryページには含まれない | Manage > Copilot Studio > Classic chatbotsで別途確認 |
| Environment name検索 | 環境名は完全一致が必要 | 環境名の一覧を先に確認し、正式名称で検索 |
| MFAとAzure Resource Manager | 条件付きアクセスによりInventoryが読み込めない場合がある | Entra ID管理者とポリシーを確認 |
| Modified on / Last modified by | Agentsではダッシュ表示になる | エージェント詳細側で補完 |
| Owner列 | Cloud flowsとagent flowsでは作成者を表示し、所有者変更後に更新されない | Power Automate側で現在の所有者を確認 |
| 未公開のモデル駆動型アプリ | publishedなモデル駆動型アプリのみ捕捉 | 公開状態を確認 |
| 既定環境のプリインストールアプリ | 編集・再公開まで表示されない場合がある | 初期表示されないアプリを過大に問題視しない |
| Sovereign cloud | GCC、GCC-High、DoD、21Vianet、中国、Air Gapped環境では現在利用不可 | 対象クラウドの可用性を事前確認 |
Microsoft Learnでは、Azure Resource ManagerへのMFA条件付きアクセスポリシーによりPower Platform inventoryが読み込めない場合があると説明されています。その場合、Power Platform admin centerアプリケーションのクライアントID 00b46ad5-e4ae-43ac-a878-281fc03d0839 とMicrosoft Azure Management resourceをMFA条件付きアクセスポリシーに含める対応が示されています。(Microsoft Learn)
この点は、セキュリティ部門との調整が必要です。Inventoryが表示されないからといって、すぐに管理者権限の問題と判断せず、条件付きアクセス、MFA、Azure Resource Managerへのアクセス制御を確認してください。
導入・運用時に失敗しやすいポイント
件数だけを見て判断する
Power Platform inventoryでは、条件に合うリソース件数を確認できます。しかし、件数が多いこと自体が問題とは限りません。部門でPower Platform活用が進んでいる場合、件数が多いのは自然です。
見るべきなのは、件数の多さではなく、管理されていない状態です。たとえば、次のような状態は優先的に確認すべきです。
- 所有者が退職者や異動者のままになっている
- 既定環境に本番業務アプリがある
- 非承認リージョンにリソースがある
- 作成者が1人に偏り、属人化している
- Copilot Studioエージェントの用途や公開範囲が不明
- フローの接続が個人アカウントに依存している
Microsoft 365管理センターの数字と混同する
エージェント数を報告するときは、Power Platform inventoryとMicrosoft 365管理センターの違いを必ず説明してください。Power Platform inventoryはPower Platform上で作成されたエージェントに絞られます。一方、Microsoft 365管理センターはユーザーが利用可能なエージェントのカタログに近い位置づけです。(Microsoft Learn)
両方の数字が異なっていても、必ずしも不整合ではありません。報告書には「集計対象」と「除外対象」を明記しましょう。
UI検索だけで大規模テナントを調べようとする
Inventoryの検索は便利ですが、UI上で見えている最大1,000件の範囲に対して働きます。大規模テナントでは、検索の前にフィルターで範囲を絞る必要があります。(Microsoft Learn)
数千件以上のリソースがある組織では、UIだけで棚卸しするより、Azure Resource GraphやAPIで定期集計した方が安定します。管理者が毎回手作業で検索する運用は、いずれ限界が来ます。
Inventoryを監査ログの代わりに使う
Power Platform inventoryは、リソースの存在や属性を確認するための機能です。誰がいつ何を操作したかを細かく追う監査ログそのものではありません。
セキュリティ調査では、Inventoryで対象リソースを特定し、その後に監査ログ、Power Platform admin center、各サービスの詳細画面、Entra ID、DLPポリシー、Dataverse監査などを確認する流れが現実的です。
管理者向けチェックリスト
Power Platform inventoryを初めて確認する場合は、次のチェックリストから始めてください。
| 優先度 | チェック項目 | 判断基準 |
|---|---|---|
| 高 | 既定環境のアプリ・フロー・エージェント | 本番利用されているものは適切な環境へ移行検討 |
| 高 | 退職者・異動者が作成または所有するリソース | 所有者変更、接続見直し、削除判断 |
| 高 | 非承認リージョンのリソース | 例外承認または移行・削除を検討 |
| 中 | リソース数が多い環境 | ガバナンス、DLP、管理者体制を確認 |
| 中 | Copilot Studioエージェント | 用途、公開状態、所有者、データ参照先を確認 |
| 中 | 作成者が偏っている部門 | 属人化対策、共同所有者設定、運用ドキュメント整備 |
| 低 | 長期間更新されていないリソース | 廃止候補として所有者に確認 |
最初から完璧な台帳を作ろうとすると、作業が重くなります。まずは「リスクが高いものを見つける」ことに絞るのがおすすめです。
Power Platform inventoryを運用に組み込む進め方
Power Platform inventoryは、単発の棚卸しで終わらせるより、定期運用に組み込むことで効果が出ます。おすすめは、次の3段階です。
初回: 現状把握
最初の1回は、全体像を把握することを目的にします。アプリ、フロー、エージェント、環境別の件数を確認し、既定環境と所有者不明に近いリソースを重点的に見ます。
この段階では、すべてのリソースを分類しようとせず、リスクの高いものだけを抽出します。
2回目以降: 差分確認
次回からは、前回以降に作成されたリソースをCreated onで絞り込みます。新規作成分だけを見ると、管理者の負担が大きく下がります。
月次レビューでは、次の4項目だけでも十分に効果があります。
- 前月に作成されたアプリ数
- 前月に作成されたフロー数
- 前月に作成されたエージェント数
- 既定環境に作成されたリソース数
定着後: 自動化とレポート化
運用が定着したら、Azure Resource GraphやPower Platform APIで定期集計し、Power BIやExcelに連携する方法を検討します。
たとえば、次のようなレポートを作ると、IT部門だけでなく部門責任者にも共有しやすくなります。
| レポート | 目的 |
|---|---|
| 環境別リソース数 | 管理対象が集中している環境を特定 |
| リソース種別別の増加傾向 | Power Apps、Power Automate、Copilot Studioの利用傾向を把握 |
| 所有者別上位 | 属人化やチャンピオンユーザーを発見 |
| リージョン別分布 | データ配置ポリシーとの整合性を確認 |
| 既定環境の新規作成 | 早期是正と利用者支援 |
IT admins、product ownersが取るべき次のアクション
IT管理者は、まずPower Platform inventoryへのアクセス権を確認し、Manage > Inventoryで全体件数を見てください。その後、既定環境、所有者、リージョン、エージェントの4つを優先して確認します。
Power Platformのプロダクトオーナーは、Inventoryを「統制のための監視」だけでなく、「活用状況の把握」にも使うべきです。作成数が多いユーザーや部門は、問題の原因ではなく、社内のPower Platform活用を広げるチャンピオン候補です。Microsoft Learnでも、Power Platform inventoryの用途として、リソースを多く作成しているユーザーを見つけ、トップイノベーターを認識・育成することが挙げられています。(Microsoft Learn)
Microsoftエコシステムに関心のある読者にとっては、Power Platform inventoryがCopilot StudioやMicrosoft 365 Copilot Agent Builderまで含む点が重要です。Power Platformの管理対象は、従来のアプリとフローから、AIエージェントやワークフローへ広がっています。今後の管理では、「誰がアプリを作ったか」だけでなく、「誰がどのエージェントを作り、どの環境で、どのデータに接続しているか」を把握する視点が必要になります。
Power Platform inventoryの2026年4月更新は、GitHub履歴上ではドキュメントメタデータの追加が中心です。しかし、機能本文で示されている内容は、Power Platformのガバナンスに直結します。まずはPower Platform admin centerのInventoryで全体像を確認し、既定環境、所有者、リージョン、エージェントを優先的に棚卸ししてください。大規模テナントでは、Azure Resource GraphやPower Platform APIを使った定期集計まで進めると、Power Platformの利用拡大と統制を両立しやすくなります。
コメント