Power Platform CoE Starter Kitのセットアップ情報でまず押さえるべき点は、単なるインストール手順ではなく、CoE Starter Kitを今後の中核として使い続けるべきか、Power Platform管理センターへ運用を寄せるべきかを判断する必要があるという点です。2026年5月時点の公式情報では、CoE Starter Kitはアクティブに保守されておらず、主要機能はPower Platform管理センターに組み込まれています。既存環境で利用している場合は、すぐに停止する話ではありませんが、新規機能追加や通常の課題対応を前提にした運用は見直すべきです。(Microsoft Learn)
この記事では、Power Platform CoE Starter Kitの「Set up the CoE Starter Kit: Prerequisites and instructions」で確認すべき変更点、影響範囲、管理者・開発者が見るべき設定、移行・展開時の注意点を実務目線で整理します。
Power Platform CoE Starter Kitの位置づけは「導入ツール」から「移行・整理対象」へ変わっている
CoE Starter Kitは、Power Apps、Power Automate、Copilot Studioなどの利用状況を可視化し、ガバナンスや運用ルール整備を支援するために使われてきたPower Platform向けの管理支援キットです。
ただし、現在の重要な変更点は、MicrosoftがCoE Starter Kitの継続的な機能投資を行わず、Inventory、Usage、Monitor、Actionsなどの中核的な管理機能をPower Platform管理センター側で提供する方向へ進んでいることです。既存・新規の展開自体は可能ですが、新機能追加や通常のIssue対応は期待できません。(Microsoft Learn)
つまり、これから確認すべきポイントは次の3つです。
| 確認ポイント | 実務での意味 |
|---|---|
| 新規導入する必要があるか | 管理センターの標準機能で代替できるなら、CoE Starter Kitの新規展開は慎重に判断する |
| 既存環境をどう扱うか | すぐ撤去ではなく、機能ごとに管理センターへ置き換えられるかを棚卸しする |
| どの機能が業務に依存しているか | Power BIレポート、通知、承認、独自カスタマイズがある場合は移行計画が必要 |
特に、CoE Starter Kitを「Power Platform管理の標準基盤」として社内ルールに組み込んでいる組織では、ドキュメントや運用手順書も更新が必要です。
何が変わったのか：最大の変更点は保守方針
今回の公式情報で最も重要なのは、CoE Starter Kitが「アクティブに保守されなくなった」と明記されている点です。あわせて、問題のレビューや対応も行われず、セキュリティ上の問題を見つけた場合はMicrosoft Security Response Centerへ報告する流れになっています。(Microsoft Learn)
これは、利用者側から見ると次のような影響があります。
| 項目 | 以前の見方 | 今後の見方 |
|---|---|---|
| 機能追加 | 月次更新で改善を期待しやすい | 新機能追加は前提にしない |
| 不具合対応 | Issueや更新で解消される可能性があった | 通常のIssue対応は期待しない |
| 管理機能の中心 | CoE Starter Kitを中心に設計 | Power Platform管理センターを中心に設計 |
| 長期運用 | 継続利用前提で設計しやすい | 依存範囲を減らす計画が必要 |
ここで誤解しやすいのは、「保守されない＝すぐ使えなくなる」ではない点です。公式情報では、既存・新規の展開は引き続き可能とされています。ただし、将来のPower Platformの仕様変更に追随する前提で設計するのは危険です。(Microsoft Learn)
影響を受ける対象者
Power Platform管理者
最も影響を受けるのは、Power Platform管理者です。環境、アプリ、フロー、メーカー、利用状況、所有者情報などをCoE Starter Kitで監視している場合、同等の確認をPower Platform管理センターでどこまで代替できるかを確認する必要があります。
公式情報では、管理センターのInventoryでアプリ・フロー・エージェントを確認し、Usageで利用状況や所有者を把握し、Monitorで重要リソースの稼働状態を確認し、Actionsでリスクやガバナンス上の対応を行う流れが示されています。(Microsoft Learn)
Power Apps・Power Automate開発者
開発者にとっての影響は、直接的な開発機能よりも「通知・棚卸し・承認・所有者確認」の運用に出ます。
たとえば、これまでCoE Starter Kit経由で以下のような運用をしていた場合は、変更の影響を受けやすくなります。
- アプリやフローの所有者確認
- 使われていないアプリの棚卸し
- メーカー向け通知
- Teamsのアダプティブカード通知
- Power Automate承認を使ったガバナンス運用
- Power BIダッシュボードによる利用状況の可視化
特に、通知や承認を自動化している場合は、単に管理センターを見るだけでは代替できないことがあります。どの通知が業務上必須なのか、どの通知は廃止できるのかを分けて確認することが重要です。
情シス・セキュリティ担当者
セキュリティ担当者は、CoE Starter Kit自体の権限、使用コネクタ、データポリシー、Microsoft Graphへの接続を確認する必要があります。
CoE Starter Kitはテナント全体のPower Platformリソース情報を扱うため、セットアップ用アカウントには強い権限が必要です。公式手順では、Power Platformサービス管理者またはグローバルテナント管理者、Power Apps・Power Automate関連ライセンス、必要に応じたPower BIライセンスやAzureアプリ登録などが挙げられています。(Microsoft Learn)
新規導入する前に判断すべきこと
これからPower Platform CoE Starter Kitを新規導入する場合、最初に考えるべきことは「セットアップできるか」ではなく「本当にセットアップすべきか」です。
判断基準は次のように整理できます。
| 判断基準 | CoE Starter Kitを検討するケース | 管理センター中心でよいケース |
|---|---|---|
| 既存の運用資産 | CoE Starter Kit前提のレポートや通知がある | まだ運用設計が固まっていない |
| カスタム要件 | 独自のPower BI分析や承認フローが必要 | 標準の可視化・監視で足りる |
| 管理対象規模 | 複数部門・多数環境を横断管理している | 小規模な環境管理が中心 |
| 将来性 | 短中期のつなぎとして使う | 長期の標準基盤を作りたい |
| 保守体制 | 自社で検証・修正・運用できる | Microsoftの標準機能に寄せたい |
新規導入のおすすめ方針は、まずPower Platform管理センターのInventory、Usage、Monitor、Actionsで要件を満たせるかを確認し、不足する部分だけCoE Starter Kitや独自実装で補うことです。
逆に、最初からCoE Starter Kitをフル展開し、その上に社内運用を組み上げる設計は慎重に避けるべきです。保守が止まっているツールに業務ルールを強く依存させると、将来の移行コストが大きくなります。
既存利用中の組織が確認すべき設定
既にCoE Starter Kitを利用している場合は、すぐに撤去するのではなく、現状の依存関係を洗い出します。特に以下の設定は優先して確認してください。
セットアップ用アカウントとライセンス
CoE Starter Kitをインストール・実行するIDには、Power Platform環境へのアクセス権が必要です。公式手順では、Power Platformサービス管理者またはグローバルテナント管理者が必要で、Dynamics 365サービス管理者はすべての環境タイプを収集できないなどの理由でサポート対象外とされています。(Microsoft Learn)
確認すべき項目は次の通りです。
| 項目 | 確認内容 |
|---|---|
| 管理ロール | Power Platformサービス管理者またはグローバル管理者か |
| Power Appsライセンス | 試用版ではなく、継続利用できるライセンスか |
| Power Automateライセンス | ユーザー単位またはフロー単位のライセンスがあるか |
| Power BIライセンス | レポート共有に必要なライセンスがあるか |
| メールボックス | Office 365 Outlookコネクタで使えるメールボックスがあるか |
| 多要素認証 | 条件付きアクセスやMFAの設計と矛盾していないか |
よくある失敗は、個人管理者アカウントでセットアップしてしまい、異動・退職・権限変更でフローや通知が止まるケースです。業務継続性を考えるなら、所有者、ライセンス、MFA、メールボックスの扱いを明確にしておく必要があります。
管理者・メーカー・ユーザー向けのMicrosoft 365グループ
公式手順では、管理者、メーカー、ユーザーという3つのペルソナごとにMicrosoft 365グループを用意することが推奨されています。これらはメール対応のセキュリティグループとして扱え、Teamsと関連付けて共同作業にも使えます。(Microsoft Learn)
実務では、次のように使い分けると整理しやすくなります。
| グループ | 主な用途 | 注意点 |
|---|---|---|
| 管理者グループ | 管理者間の連絡、問い合わせ窓口 | 権限を持つメンバーを定期的に棚卸しする |
| メーカーグループ | アプリ作成者への通知、教育案内 | インベントリ処理でメーカーが追加される可能性を考慮する |
| ユーザーグループ | 利用者向け連絡、影響通知 | 全社配信にならないよう対象範囲を確認する |
また、CoE Starter Kitの一部プロセスではPower Automate承認やTeamsのアダプティブカードが使われます。これらはグループではなく個人に割り当てる必要があるため、承認やチャットボット通知を受け取る個人管理者の指定も確認しておきましょう。(Microsoft Learn)
インベントリ収集はData ExportとCloud flowsの違いを理解する
CoE Starter Kitで重要なのが、Power Platformリソースのインベントリ収集です。公式手順では、データ収集の仕組みとしてData ExportとCloud flowsの2つが示されています。(Microsoft Learn)
| 方式 | 特徴 | 向いているケース | 注意点 |
|---|---|---|---|
| Data Export | Power Platform管理センターのデータエクスポート機能を使い、Azure Data Lake Storageへ出力する | 管理センター側のデータを効率的に使いたい場合 | CoE Starter Kitでの利用は実験的プレビューとして扱われる |
| Cloud flows | 管理コネクタでテナントをクロールし、Dataverseに保存する | 小〜中規模テナント | 環境・アプリ・フローなどの合計が10,000オブジェクトを超えると性能問題が出る可能性がある |
大規模テナントでは、Cloud flowsで全体を巡回する設計が重くなりやすい点に注意が必要です。公式手順でも、10,000オブジェクトを超える場合はパフォーマンス問題が発生する可能性があるとされています。(Microsoft Learn)
Data Exportを試す場合は、ストレージアカウントにインベントリデータファイルが表示されてからCoE Starter Kitの構成へ進む必要があります。初回エクスポートには最大5日かかる場合があるため、検証スケジュールには余裕を持たせましょう。(Microsoft Learn)
環境構成で失敗しやすいポイント
CoE Starter Kitのセットアップでは、テスト環境と本番環境の2つを用意することが推奨されています。公式手順では、データベース付き環境を作成し、既定言語は英語、サンプルアプリやデータセットは追加しないこと、セキュリティグループはNoneにすることなどが示されています。(Microsoft Learn)
特に重要なのは、テスト環境のProductionEnvironment環境変数です。テスト環境ではこの値をnoに設定することで、メーカーやエンドユーザーにメールが送信されない状態で検証できます。(Microsoft Learn)
実務での失敗例は次の通りです。
| 失敗例 | 起きる問題 | 対策 |
|---|---|---|
| テスト環境で本番扱いの設定にする | メーカーや利用者へ不要な通知が送られる | ProductionEnvironmentを必ず確認する |
| サンプルデータを追加する | 不要なデータやアプリが混ざり検証が複雑になる | 環境作成時にサンプルを追加しない |
| 日本語環境で作成する | 一部手順やコンポーネントで想定差異が出る可能性がある | 公式手順に合わせて英語を選ぶ |
| セキュリティグループで制限しすぎる | 承認やメーカー操作が正常に動かない | 必要な操作範囲を確認して設計する |
既存環境で運用している場合も、テスト環境が形だけになっていないかを確認してください。アップグレード検証や管理センターへの移行検証を行う場所として、テスト環境の重要性はむしろ高まっています。
データポリシーとコネクタの確認は必須
CoE Starter Kit環境に適用されるデータポリシーでは、複数のコネクタを同じビジネスグループで利用できるようにする必要があります。公式手順では、Approvals、Azure Resource Manager、HTTP、HTTP with Microsoft Entra ID、Microsoft Dataverse、Microsoft Teams、Office 365 Groups、Office 365 Outlook、Office 365 Users、Power Apps for Admins、Power Automate for Admins、Power Platform for Admins V2、Power Query Dataflows、RSSなどが挙げられています。(Microsoft Learn)
ここで注意したいのは、単に「コネクタを許可する」だけでは不十分な点です。CoE Starter Kitはアプリやフローの所有者情報を収集するため、通常ユーザーが所有するリソースではOffice 365 Usersコネクタを使い、サービスプリンシパルが所有するリソースではHTTP with Microsoft Entra IDを使ってMicrosoft Graphからアプリユーザー名を取得します。(Microsoft Learn)
そのため、次の観点で確認しましょう。
- DLPポリシーで必要なコネクタが分断されていないか
- 複数のデータポリシーが重なって予期せぬ制限が発生していないか
- HTTP系コネクタの利用を社内ポリシーで禁止していないか
- Microsoft Graphへの接続がセキュリティ要件と矛盾しないか
- GCC、GCC High、DoDなど特殊なクラウド環境でエンドポイント確認が必要か
特にHTTP系コネクタは、セキュリティ部門の審査で止まりやすいポイントです。導入担当者だけで進めず、DLPポリシー管理者と事前に確認してください。
アップグレード方針は「延命」ではなく「移行準備」として考える
公式手順では、CoE Starter Kitの更新について、少なくとも3か月ごとのアップグレードと、本番適用前の専用テスト環境での検証が推奨されています。(Microsoft Learn)
ただし、現在はCoE Starter Kit自体がアクティブに保守されていないため、アップグレード方針は単なる最新版追随ではなく、次のように考えるべきです。
| やること | 目的 |
|---|---|
| 現在使っているコンポーネントを一覧化する | 移行対象を明確にする |
| Power Platform管理センターで代替できる機能を確認する | CoE Starter Kitへの依存を減らす |
| Power BIレポートの利用状況を確認する | 必要な分析だけ残す |
| 通知・承認フローを棚卸しする | 業務上必要な自動化だけ再設計する |
| テスト環境で動作確認する | 本番ユーザーへの誤通知や停止を防ぐ |
特に、CoE Starter KitのPower BIダッシュボードを経営報告や部門別KPIに使っている場合は注意が必要です。レポートの見た目だけを移行するのではなく、「誰が、何を判断するために使っているか」を確認し、管理センターの標準機能、Power BIの独自レポート、APIやコネクタの利用に分けて再設計しましょう。
管理者・開発者向けチェックリスト
CoE Starter Kitを利用中、または導入を検討している組織は、次の順番で確認すると無駄が少なくなります。
| 優先度 | 確認項目 | 実施者 |
|---|---|---|
| 高 | CoE Starter Kitを今後も使う理由があるか確認する | Power Platform管理者 |
| 高 | Power Platform管理センターのInventory、Usage、Monitor、Actionsで代替できる範囲を確認する | 管理者・情シス |
| 高 | セットアップ用アカウント、ライセンス、MFA、メールボックスを確認する | 管理者 |
| 高 | DLPポリシーと必要コネクタを確認する | セキュリティ担当 |
| 中 | Power BIレポート、通知、承認フローの利用状況を棚卸しする | 管理者・開発者 |
| 中 | Data ExportとCloud flowsのどちらでインベントリを収集しているか確認する | 管理者 |
| 中 | テスト環境のProductionEnvironmentがnoになっているか確認する | 管理者 |
| 低 | 独自カスタマイズを管理センター標準機能へ置き換えられるか検討する | 開発者 |
これからの推奨対応
Power Platform CoE Starter Kitは、今でも既存環境や特定の用途では役立つ可能性があります。しかし、今後の標準的な管理基盤としては、Power Platform管理センターを中心に考えるべきです。
まずは、現在の運用を次の3分類に分けてください。
| 分類 | 例 | 対応方針 |
|---|---|---|
| 管理センターで代替できるもの | インベントリ確認、利用状況確認、リスク確認 | 管理センターへ移行 |
| 代替に工夫が必要なもの | 独自Power BIレポート、部門別通知 | 要件を整理して再設計 |
| CoE Starter Kitに残すもの | 短期的に移行困難な承認・通知・分析 | 期限を決めて暫定運用 |
重要なのは、「CoE Starter Kitを使うか、使わないか」を一度に決めることではありません。機能ごとに依存度を見える化し、管理センターへ移せるものから順に移行することです。
Power Platform管理の次の一手としては、まず管理センターで現在のアプリ、フロー、エージェント、所有者、利用状況を確認し、CoE Starter Kitでしか見ていない項目を洗い出してください。そのうえで、通知、承認、Power BIレポート、DLPポリシーの順に見直すと、影響を抑えながら現実的に移行できます。
コメント