Power Platform Center of Excellence（CoE）Starter Kit overviewを確認している管理者が最初に押さえるべき結論は、CoE Starter Kitは今後の主役ではなく、Power Platform管理センターを中心に運用を組み直す必要があるという点です。Microsoftの公式情報では、Power Platform CoE Starter Kitはアクティブに保守されなくなり、コア機能はPower Platform管理センターに含まれると説明されています。問題のレビューや修正対応も原則行われず、セキュリティ上の懸念はMicrosoft Security Response Centerへ報告する扱いです。(Microsoft Learn)
この記事では、2026年5月時点の公式情報をもとに、Power Platform Center of Excellence（CoE）Starter Kit overviewで何が変わるのか、既存利用者への影響、管理者・開発者が確認すべき設定、移行や展開時の注意点を実務目線で整理します。すでにCoE Starter Kitを使っている場合も、これから導入を検討している場合も、まずは「何をPower Platform管理センターへ寄せるか」「何を残すか」「何を廃止するか」を切り分けることが重要です。
Power Platform CoE Starter Kit overviewで最も重要な変更点
今回の公式情報で最も重要なのは、CoE Starter Kitが「Power Platform管理の推奨中核」ではなくなったことです。
CoE Starter Kitは、これまでPower Platformの導入状況の可視化、ガバナンス、監視、ベストプラクティスの実装例として多くの組織で使われてきました。しかし現在は、Inventory、Usage、Monitor、ActionsといったPower Platform管理センター内の機能を中心に、ガバナンスや監視を行う方針へ移っています。(Microsoft Learn)
| 変更点 | 実務上の意味 | まず確認すべきこと |
|---|---|---|
| CoE Starter Kitはアクティブに保守されない | 新機能追加や通常の不具合対応を前提にできない | 既存のCoE依存機能を棚卸しする |
| コア機能はPower Platform管理センターへ移行 | 標準UI・管理機能を優先して使う | Inventory、Usage、Monitor、Actionsを確認する |
| 既存・新規デプロイは利用可能 | すぐに強制停止されるわけではない | 継続利用のリスクと目的を明確にする |
| 問題のレビューや対処は行われない | 運用トラブルを自社で切り分ける必要がある | サポート対象と非対象を運用手順に明記する |
| セキュリティ問題はMSRCへ報告 | 通常のGitHub issue対応とは異なる | セキュリティ報告ルートを社内に共有する |
重要なのは、「CoE Starter Kitを今すぐ削除する」という判断ではありません。既存環境で使っているPower BIレポート、Dataverseテーブル、クラウドフロー、通知プロセス、独自カスタマイズがある場合は、業務影響を確認せずに停止すると、可視化や棚卸しの運用が途切れる可能性があります。
一方で、新規導入を検討している組織は、最初からPower Platform管理センターの標準機能を起点に設計する方が安全です。CoE Starter Kitは参考実装や補完ツールとして扱い、標準機能で不足する部分だけを慎重に検討するのが現実的です。
そもそもPower Platform CoE Starter Kitとは
Power Platform CoE Starter Kitは、Power Platformの導入・運用・ガバナンスを支援するためのリファレンス実装です。公式情報では、Power Apps、Power Automate、Power BI、Dataverse、Copilot Studioなど、Power Platformの標準的なローコード機能を使って、ガバナンス、監視、導入促進の仕組みを構築する例として説明されています。(Microsoft Learn)
キットには、主に次のような要素が含まれていました。
- テナント内のアプリ、フロー、メーカーなどを把握するためのDataverseデータモデル
- 収集データを確認するPower BIレポート
- 管理者向けのPower Apps
- リソース情報を収集するクラウドフロー
- ガバナンス、監査、通知、導入促進に関するテンプレート
- メーカー向けの案内やコミュニティ運用を支援する仕組み
ただし、CoE Starter Kitは「CoEそのもの」ではありません。CoE、つまりCenter of Excellenceを運営するには、ツールだけでなく、責任者、運用ルール、教育、相談窓口、セキュリティ基準、例外処理のルールが必要です。公式情報でも、CoEの管理には人、コミュニケーション、定義された要件とプロセスが必要であり、ツールは目的を達成するための手段だと説明されています。(Microsoft Learn)
実務では、CoE Starter Kitを入れただけでガバナンスが完成するわけではありません。たとえば、以下のような運用判断を社内で決めておく必要があります。
- どの環境で業務アプリを作ってよいか
- 共有範囲が広いアプリを誰が確認するか
- 退職者が所有しているアプリやフローをどう引き継ぐか
- 未使用アプリを削除する前に誰へ通知するか
- プレミアムコネクタ利用をどの部門予算に紐づけるか
- Copilot Studioエージェントを誰がレビューするか
今回の変更は、こうしたCoE運用が不要になったという意味ではありません。むしろ、ツールの中心をCoE Starter KitからPower Platform管理センターへ移し、CoEの運用設計を改めて整理するタイミングだと捉えるべきです。
何がPower Platform管理センターへ移るのか
公式情報では、CoE Starter Kitの中心的なシナリオはPower Platform管理センターの機能に対応すると整理されています。具体的には、Inventory、Usage、Monitor、Actionsが重要です。(Microsoft Learn)
| CoE Starter Kitで見ていたこと | Power Platform管理センター側の主な機能 | 確認ポイント |
|---|---|---|
| アプリ、フロー、エージェントの棚卸し | Inventory | テナント全体のリソースを検索・絞り込みできるか |
| 利用状況や導入状況の把握 | Usage | 利用が多いアプリ、フロー、エージェントを追えるか |
| 重要リソースの正常性確認 | Monitor | 障害傾向や改善推奨を確認できるか |
| リスク検出と対処 | Actions | 推奨事項、影響リソース、対応履歴を運用に組み込めるか |
| メーカーへの案内 | Managed EnvironmentsのMaker welcome contentなど | 新規作成者に事前案内を出せるか |
| 共有制限やDLP管理 | Managed Environments、データポリシー | 予防的なガバナンスを標準機能で実施できるか |
Inventoryは、Power Platform上で作成されたエージェント、アプリ、フロー、環境などを統合的に把握するための機能です。公式情報では、リソースの検索、フィルター、並べ替え、詳細確認、Excelへのエクスポートなどが説明されています。また、Inventoryの閲覧にはPower Platform管理者またはDynamics 365管理者などのテナント全体の管理者ロールが必要です。(Microsoft Learn)
Usageは、Power Apps、Power Automate、Copilot Studioエージェントの利用状況や導入状況を把握するためのページです。ただし公式情報ではプレビュー機能として扱われ、リージョンによってはまだ利用できない可能性があるとされています。本番運用のKPIとして使う場合は、表示有無やデータの扱いを事前に確認してください。(Microsoft Learn)
Monitorは、アプリ、フロー、エージェントなどの運用正常性を確認するための領域です。管理者はテナント全体または特定環境の正常性を把握でき、メーカーは自身が編集権限を持つリソースの改善に使えます。ただし、メトリックはランタイム活動のログを日次集計して算出されるため、リアルタイム監視ではありません。(Microsoft Learn)
Actionsは、Power Platformテナントを最適化するための推奨事項を表示し、インライン操作、Power Automate、PowerShellなどで対応できる管理機能です。推奨事項はセキュリティ、運用効率、ライセンスと容量、パフォーマンスなどのカテゴリに整理されます。Managed Environmentsでは、影響リソースの詳細や操作をより活用しやすくなります。(Microsoft Learn)
影響を受ける対象者
今回の変更は、Power Platform管理者だけでなく、開発者、CoE運営担当、セキュリティ担当、Power BIレポート管理者にも影響します。
Power Platform管理者
Power Platform管理者は、最も影響を受けます。これまでCoE Starter KitのPower BIダッシュボードや管理アプリを見ていた場合、今後はPower Platform管理センターのInventory、Usage、Monitor、Actionsを標準の確認場所として位置づける必要があります。
確認すべきことは、次の3つです。
- 既存のCoE Starter Kitでどの機能を使っているか
- 同じ目的をPower Platform管理センターで満たせるか
- 満たせない部分を残すのか、別の自動化に置き換えるのか
たとえば、単に「どのアプリが誰に所有されているか」を見るだけなら、Inventoryへ移せる可能性があります。一方、部門マスタと連携した独自のPower BI分析や、社内申請プロセスと連動した通知フローを作り込んでいる場合は、移行に設計が必要です。
CoE運営チーム
CoE運営チームは、ツールの変更よりも運用モデルの見直しが重要です。CoE Starter Kitを前提にしていた月次棚卸し、メーカー向けメール、未使用リソースの確認、ガバナンスレビューの会議体を、Power Platform管理センターの機能に合わせて再設計する必要があります。
特に見直すべきなのは、次のような業務です。
- アプリやフローの棚卸しレポート作成
- 共有範囲が広いアプリの確認
- 退職者・異動者が所有するリソースの引き継ぎ
- メーカーへのオンボーディング
- 未使用リソースの削除確認
- DLPポリシー違反やリスクの検出
公式情報では、CoE Starter Kitには一括権限更新、放棄されたリソースのクリーンアップ、メーカー調査、アイデアのROI計算など、Managed Environmentsだけではまだ満たされていない機能もあると説明されています。つまり、すべてを一気に標準機能へ置き換えられるとは限りません。(Microsoft Learn)
開発者・メーカー
開発者やメーカーへの直接影響は、管理ルールや通知方法の変更として現れます。たとえば、これまでCoE Starter Kitのウェルカムメールで案内していたルールを、Managed EnvironmentsのMaker welcome contentへ移す場合、メーカーはPower Appsへサインインした時点でガイダンスを受け取る形になります。
開発者側で注意すべきなのは、管理者がリソースの利用状況、所有者、共有範囲、正常性、推奨事項をより標準機能で確認できるようになる点です。独自に作ったアプリやフローも、環境・所有者・利用状況・正常性の観点で管理対象になります。
セキュリティ・コンプライアンス担当
セキュリティ担当者は、CoE Starter Kitの独自運用に頼っていた統制を、標準の管理センター、Managed Environments、データポリシー、Actionsへ寄せることを検討する必要があります。
特に重要なのは、予防的なガバナンスです。公式情報では、CoE Starter Kitはリソース共有を制限しないため、プロアクティブな共有制御はManaged Environmentsで行うと説明されています。CoE Starter Kitのコンプライアンスプロセスは、広く共有されたリソースを後から特定し、追加情報を求めるようなリアクティブな運用に向いています。(Microsoft Learn)
つまり、「作られた後に検知する」だけでなく、「作られる前・共有される前に制御する」設計へ移すことが重要です。
管理者が最初に確認すべき設定
移行や見直しを始める前に、Power Platform管理センター側の機能が使える状態か確認します。機能が無効なままCoE Starter Kitを止めると、棚卸しや監視の空白期間が生まれます。
管理者ロールを確認する
Inventoryを利用するには、Power Platform管理者またはDynamics 365管理者など、テナント全体を管理できるロールが必要です。環境管理者だけでは、テナント全体の棚卸しに必要な情報へアクセスできない場合があります。(Microsoft Learn)
確認する項目は次の通りです。
| 確認項目 | 推奨アクション |
|---|---|
| Power Platform管理者が誰か | 少なくとも主担当・副担当を明確にする |
| グローバル管理者に依存していないか | 日常運用はPower Platform管理者へ委任する |
| 環境管理者の範囲 | 本番・開発・検証環境ごとに責任者を決める |
| 退職者・異動者の棚卸し | 所有リソースの引き継ぎ手順を用意する |
テナントレベル分析を有効化する
Monitorや分析系の機能を使うには、テナントレベル分析の設定が重要です。公式情報では、テナントレベル分析を有効にすると、複数環境のテレメトリデータを集約し、Power Platform管理センターから分析できると説明されています。有効化後、レポート表示まで通常24〜48時間かかる場合があります。(Microsoft Learn)
設定確認の流れは、次の通りです。
| 手順 | 操作 |
|---|---|
| 1 | Power Platform管理センターへサインイン |
| 2 | Manageを開く |
| 3 | Tenant settingsを選択 |
| 4 | Analyticsを開く |
| 5 | Tenant-level analyticsをEnableにする |
| 6 | 保存後、表示反映を待つ |
注意点として、テナントレベル分析を無効化すると、集約済みのメトリック、ユーザーオブジェクトID、アプリ名やフロー名などのリソース名が削除されると公式情報に記載されています。運用中に無効化する場合は、影響範囲を確認してください。(Microsoft Learn)
Managed Environmentsを確認する
Managed Environmentsは、Power Platformを大規模に管理するためのプレミアム機能群です。環境グループ、共有制限、週次利用状況、データポリシー、パイプライン、Maker welcome content、Solution checker、IP Firewallなど、多数の管理機能に関係します。(Microsoft Learn)
特にCoE Starter Kitからの移行で重要なのは、次の機能です。
| Managed Environmentsの機能 | CoE運用での使いどころ |
|---|---|
| Maker welcome content | メーカーへのルール、申請手順、学習リンクの案内 |
| Limit sharing | アプリの過剰共有を予防する |
| Data policies | コネクタ利用やデータ接続を統制する |
| Weekly usage insights | 利用状況の定期把握 |
| Solution checker | ソリューション品質の確認 |
| Pipelines | ALMと展開プロセスの標準化 |
| Environment groups | 環境単位の管理ポリシー適用 |
ただし、Managed Environmentsにはライセンス上の考慮が必要です。公式情報では、スタンドアロンのPower Apps、Power Automate、Microsoft Copilot Studio、Power Pages、Dynamics 365ライセンスの権利として含まれる一方、Developer Planでユーザーが資産を実行する場合は権利に含まれないと説明されています。(Microsoft Learn)
Inventoryの制限を確認する
InventoryはCoE Starter Kitからの移行で中心になる機能ですが、制限もあります。たとえば、UI上の検索は現在読み込まれている最大1,000件に対して適用されるため、リソース数が多いテナントではフィルターで対象を絞り込む必要があります。また、ソブリンクラウドや一部クラウドでは利用可否に制限があります。(Microsoft Learn)
実務では、次のように使い分けると管理しやすくなります。
| 目的 | 推奨手段 |
|---|---|
| すばやく所有者や環境を確認する | InventoryのUI |
| 大量データを定期レポート化する | Excelエクスポート、API、コネクタ |
| 独自のPower BI分析を作る | Power Platform inventory APIやAdmin V2 connector |
| 部門・地域・コストセンター別に分析する | 組織マスタと連携したカスタムレポート |
移行・展開で失敗しやすいポイント
CoE Starter KitからPower Platform管理センター中心の運用へ移すときは、「機能名が似ているから置き換えられる」と単純に考えないことが大切です。実際には、データの粒度、更新頻度、対象リソース、権限、通知方法、レポート形式が異なる場合があります。
既存のCoEカスタマイズを把握しないまま止める
最も危険なのは、CoE Starter KitのクラウドフローやPower BIレポートを、利用状況を確認せずに停止することです。
たとえば、次のようなカスタマイズが入っている場合があります。
- 特定部門向けの独自Power BIレポート
- アプリ作成時のTeams通知
- 未使用フローの所有者確認メール
- 退職者所有アプリの検出処理
- 社内申請システムとの連携
- セキュリティレビュー用のDataverse列追加
- DLPポリシー変更時の影響確認レポート
これらは標準機能だけでは完全に再現できない場合があります。移行前に、CoE環境内のソリューン、フロー、アプリ、Dataverseテーブル、Power BIデータセット、接続参照、サービスアカウントを一覧化してください。
標準機能のプレビューやリージョン差を見落とす
Usageのように、公式情報でプレビューとされている機能や、リージョンによって利用できない可能性がある機能があります。本番運用の主要KPIに組み込む場合は、自社テナントで実際に表示されるか、必要なデータが揃うかを検証してください。(Microsoft Learn)
「公式にあるから使えるはず」と考えるのではなく、次の観点で確認します。
| 確認観点 | 例 |
|---|---|
| 利用可否 | 自社リージョンで表示されるか |
| データ範囲 | Power Apps、Power Automate、Copilot Studioのどこまで対象か |
| 更新頻度 | 日次集計か、リアルタイムか |
| 権限 | 誰が閲覧できるか |
| 本番利用可否 | プレビュー機能かどうか |
| エクスポート | Excel、API、コネクタで取り出せるか |
Monitorをリアルタイム監視と誤解する
Monitorは重要な正常性確認機能ですが、公式情報ではメトリックは日次イベントログの集計から算出され、リアルタイムではないと説明されています。また、イベントログは最大7日、メトリックは最大28日という考慮点も示されています。(Microsoft Learn)
障害検知や即時アラートが必要な業務では、Monitorだけに依存しない方が安全です。重要な業務アプリでは、必要に応じてApplication Insights、Power Automateの実行履歴、業務側の監視、サービス正常性確認を組み合わせてください。
CoE Starter Kitを「Microsoftサポート対象の製品」と誤解する
CoE Starter Kitの基盤となるDataverse、管理API、コネクタなどはサポート対象のPower Platform機能ですが、キット自体はサンプル実装です。公式情報でも、キットの機能は組織の管理・ガバナンス目標に合わせてカスタマイズする必要があると説明されています。(Microsoft Learn)
今回の更新では、さらに通常の問題レビューや対処が行われないことが明確になっています。したがって、CoE Starter Kitに依存した運用を続ける場合は、次の前提を文書化しておくべきです。
- 不具合対応をMicrosoftに期待しない
- 自社またはパートナーで調査・修正できる体制を持つ
- Power Platform側の仕様変更により動作影響が出る可能性を考慮する
- 重要な管理業務は標準機能または自社管理の仕組みに移す
- セキュリティ問題の報告ルートをMSRCに切り替える
実務で使える移行ステップ
CoE Starter KitからPower Platform管理センター中心の運用へ移す場合は、段階的に進めるのが安全です。以下の流れで進めると、影響範囲を抑えながら移行できます。
| ステップ | 作業内容 | 成果物 |
|---|---|---|
| 1 | 現在のCoE利用状況を棚卸し | 利用機能一覧、所有者一覧 |
| 2 | 標準機能との対応表を作る | 移行・継続・廃止の分類表 |
| 3 | 管理センター側の設定を確認 | ロール、分析、Managed Environments設定 |
| 4 | 検証環境で運用を再現 | テスト結果、差分一覧 |
| 5 | 通知・レポートを移行 | 新しい確認手順、レポートURL |
| 6 | CoE依存フローを段階停止 | 停止計画、ロールバック手順 |
| 7 | 運用ルールを更新 | 管理手順書、社内アナウンス |
現在のCoE利用状況を棚卸しする
最初に、CoE環境で何が動いているかを確認します。
具体的には、次の情報を集めます。
- インストール済みのCoE Starter Kitソリューション
- 有効化されているクラウドフロー
- 定期実行のスケジュール
- 利用中のPower BIレポート
- Dataverseテーブルの追加列や独自テーブル
- カスタムアプリやカスタムページ
- 接続参照と所有者
- 通知先のメール、Teamsチャネル
- サービスアカウントや管理者アカウント
- 業務部門が参照しているレポート
この棚卸しで「誰も見ていないレポート」「動いているが効果が不明なフロー」「所有者が不明な接続」が見つかることがあります。移行は、単なる機能置換ではなく、管理負債を整理する機会にもなります。
機能ごとに移行・継続・廃止を分類する
棚卸しが終わったら、各機能を次の3つに分類します。
| 分類 | 判断基準 | 例 |
|---|---|---|
| 移行 | 管理センター標準機能で目的を満たせる | アプリ・フローの一覧確認をInventoryへ移す |
| 継続 | 標準機能では代替が難しく、業務価値が高い | 部門別Power BI分析、独自承認フロー |
| 廃止 | 利用者がいない、重複している、保守リスクが高い | 古い通知フロー、未使用ダッシュボード |
判断に迷う場合は、「この機能が1か月止まったら誰が困るか」を確認してください。困る人が明確で、代替手段がないものは継続または移行対象です。困る人がいないものは、廃止候補です。
Power Platform管理センターで運用を再設計する
次に、管理センター側で日常運用を組み直します。
たとえば、月次のCoEレビュー会議では、次のような確認項目に変えられます。
| 旧運用 | 新運用の例 |
|---|---|
| CoE Power BIでアプリ数を確認 | Inventoryでアプリ、フロー、エージェントを確認 |
| CoEレポートで利用上位アプリを確認 | Usageで利用傾向を確認 |
| CoE通知で未使用リソースを確認 | ActionsやInventoryを使い、必要に応じてPower Automateで通知 |
| CoEメールでメーカーに案内 | Managed EnvironmentsのMaker welcome contentで案内 |
| CoEのDLP Editorで影響確認 | 管理センターのデータポリシーと標準分析を確認 |
ただし、標準機能の画面だけで会議資料が足りない場合は、Inventory API、Power Platform API、Power Platform for Admins V2 connectorなどを使った独自レポート化を検討できます。公式情報でも、管理センターUIだけでなくCLI、API、コネクタを使う選択肢が示されています。(Microsoft Learn)
段階的にCoE依存を減らす
移行後すぐにCoE Starter Kitを削除するのではなく、段階的に依存を減らします。
おすすめの進め方は次の通りです。
| 期間 | 作業 |
|---|---|
| 第1段階 | 管理センター側で同等情報を確認できるか検証 |
| 第2段階 | CoEレポートと管理センターの差分を比較 |
| 第3段階 | 業務利用者へ新しい確認場所を案内 |
| 第4段階 | 重複する通知やレポートを停止 |
| 第5段階 | CoE環境の残存機能を継続・廃止に再分類 |
| 第6段階 | 不要なフロー、アプリ、接続、レポートを整理 |
特に通知系のフローは、停止前に必ず通知先と頻度を確認してください。管理者だけでなく、業務部門、セキュリティ部門、内部監査部門が参照している場合があります。
開発者が確認すべき実装・ALM上の注意点
開発者や内製支援チームは、CoE Starter Kitの移行を「管理者だけの作業」と考えない方がよいです。Power Platform管理センター中心の運用になると、アプリやフローの作り方、環境の使い方、ソリューション管理、共有方法がより見られるようになります。
管理対象リソースを意識して作る
Inventoryでは、Power Appsのキャンバスアプリ、モデル駆動型アプリ、コードアプリ、Power Automateのクラウドフロー、Copilot Studioのエージェントなどが対象に含まれます。エージェントやフローも管理対象として見えるため、個人作成の小さな自動化でも、所有者や環境を適切に管理する必要があります。(Microsoft Learn)
開発時は、次のルールを徹底してください。
- 個人の既定環境に業務重要アプリを作らない
- 本番利用するアプリは専用環境で管理する
- 所有者を1人に固定せず、共同所有や引き継ぎを考慮する
- ソリューション化してALMに乗せる
- 接続参照と環境変数を使い、環境差分を管理する
- アプリ名、フロー名、説明欄に用途と責任者が分かる情報を入れる
独自ガバナンスは別ソリューションで管理する
CoE Starter Kitをカスタマイズしている場合、管理対象ソリューションのコンポーネントを直接編集しているケースがあります。公式の更新手順では、フローやアプリを変更するとアンマネージドレイヤーが作成され、更新を受け取れない場合があると説明されています。(Microsoft Learn)
今後CoE Starter Kitの積極的な更新は期待できないとしても、管理対象コンポーネントを直接変更する運用は避けるべきです。独自の通知、承認、レポート、Dataverse拡張は、可能な限り別ソリューションとして管理してください。
API・コネクタ活用を検討する
標準UIでは足りない分析や自動化が必要な場合は、Power Platform inventory API、Power Platform API、Power Platform for Admins V2 connectorを検討します。たとえば、Actionsの推奨事項を取得し、対象リソースの所有者へ通知し、一定期間応答がなければ管理者へエスカレーションする、といった運用をPower Automateで組むことができます。Actionsは、Admin V2 connectorを使った自動対応にも対応しています。(Microsoft Learn)
ただし、APIやコネクタで独自実装を作る場合は、次の点に注意してください。
- 権限を最小化する
- サービスアカウントの棚卸しを行う
- 実行履歴と監査ログを残す
- 削除や権限変更などの破壊的操作は承認ステップを入れる
- 仕様変更に備えて定期的にテストする
- 取得データを保存する場合は個人情報・機密情報の扱いを確認する
既存のCoE Starter Kitを使い続ける場合の判断基準
CoE Starter Kitを使い続けるべきかどうかは、次の基準で判断します。
| 判断項目 | 継続してよいケース | 移行・廃止を優先すべきケース |
|---|---|---|
| 業務価値 | 独自レポートや通知が実際に使われている | 誰も参照していない |
| 代替可能性 | 標準機能で代替できない | InventoryやActionsで十分 |
| 保守体制 | 自社またはパートナーが保守できる | 不具合時に調査できる人がいない |
| セキュリティ | 権限・接続・データ保管が管理されている | 所有者不明の接続が多い |
| 将来性 | 段階的な縮小計画がある | 目的なく使い続けている |
おすすめは、CoE Starter Kitを「全部残す」か「全部消す」ではなく、機能単位で判断することです。
たとえば、以下のような判断が現実的です。
- アプリ・フロー一覧の確認はInventoryへ移行
- 利用状況の大まかな把握はUsageへ移行
- 重要リソースの正常性確認はMonitorへ移行
- セキュリティ推奨事項や対応履歴はActionsへ移行
- 部門別の詳細Power BI分析は一時的にCoE側を継続
- 未使用リソースの独自通知はPower Automateで再実装
- 使われていないウェルカムメールはMaker welcome contentへ置き換え
よくある疑問
これからCoE Starter Kitを新規導入してもよいのか
新規導入は可能ですが、最初の選択肢にするべきではありません。公式情報では、CoE Starter Kitは既存および新規デプロイで引き続き利用できるものの、新機能では強化されず、問題のレビューや対処も行われないと説明されています。(Microsoft Learn)
これからPower Platform管理を始めるなら、まずPower Platform管理センター、Managed Environments、データポリシー、Inventory、Usage、Monitor、Actionsを確認してください。そのうえで、標準機能では満たせない明確な要件がある場合に限り、CoE Starter Kitや独自実装を検討する流れが安全です。
既存のCoE Starter Kitはすぐ削除すべきか
すぐ削除する必要はありません。むしろ、利用状況を確認せずに削除するのは危険です。
既存環境では、CoE Starter Kitが棚卸し、通知、Power BIレポート、監査、社内ルール確認に使われている可能性があります。まずは利用機能を棚卸しし、Power Platform管理センターで代替できるものから段階的に移行してください。
CoEチームは不要になるのか
不要にはなりません。変わるのはツールの中心であり、CoEの役割そのものではありません。
Power PlatformのCoEには、環境戦略、セキュリティ、DLP、教育、メーカー支援、ALM、ライセンス、利用状況分析、業務部門との調整が必要です。管理センターの機能が強化されても、それをどう運用に落とし込むかは組織側の責任です。
Microsoftサポートには何を問い合わせられるのか
Power Platformのコア機能に関する問題は、通常のサポートチャネルを使います。一方、CoE Starter Kit自体の利用に関する通常の問題はレビューや対処が行われず、潜在的なセキュリティ問題はMicrosoft Security Response Centerへ報告する扱いです。(Microsoft Learn)
社内手順では、問い合わせ先を次のように分けておくと混乱を防げます。
| 問題の種類 | 問い合わせ・対応先 |
|---|---|
| Power Platform管理センターの標準機能 | Microsoftの標準サポート |
| Power Apps、Power Automate、Dataverseなどの基盤機能 | Microsoftの標準サポート |
| CoE Starter Kitの通常不具合 | 自社または導入パートナーで調査 |
| CoE Starter Kitに関する潜在的なセキュリティ問題 | Microsoft Security Response Center |
| 独自カスタマイズ部分 | 自社開発チームまたは保守ベンダー |
管理者が今すぐ取るべきアクション
Power Platform Center of Excellence（CoE）Starter Kit overviewの更新を受けて、管理者が最初にやるべきことは明確です。CoE Starter Kitの継続利用を前提にするのではなく、Power Platform管理センターを中心に管理設計を見直してください。
まずは、次のチェックリストから始めるのがおすすめです。
| 優先度 | アクション |
|---|---|
| 高 | CoE Starter Kitがアクティブに保守されないことを管理者間で共有する |
| 高 | 既存のCoE環境で使っている機能、フロー、レポートを棚卸しする |
| 高 | Inventory、Usage、Monitor、Actionsが自社テナントで使えるか確認する |
| 高 | Power Platform管理者、環境管理者、CoE担当者の責任範囲を整理する |
| 中 | Tenant-level analyticsとManaged Environmentsの設定を確認する |
| 中 | CoE Starter Kitの機能を移行・継続・廃止に分類する |
| 中 | 独自レポートや通知をAPI・コネクタで再設計できるか検討する |
| 低 | 不要になったCoEフローやレポートを段階的に停止する |
今回の変更は、Power Platform管理を弱めるものではありません。むしろ、標準機能を中心に、より保守しやすいガバナンスへ移行する機会です。
CoE Starter Kitを使ってきた組織は、これまで蓄積した運用ノウハウを捨てる必要はありません。ただし、ツールの中心はPower Platform管理センターへ移し、CoE Starter Kitは必要な部分だけを補完的に扱うべきです。次に行うべきことは、自社のCoE運用を棚卸しし、標準機能で置き換えられる範囲を1つずつ確認することです。
コメント