Power Platform の公式ページ「Important changes (deprecations) coming in Power Platform」は、機能停止や仕様変更に備えるための重要な情報源です。結論から言うと、2026年5月時点で優先して確認すべきなのは、Dataverse監査イベントの仕様変更、モデル駆動型アプリのグリッド／外観変更、Power Automate関連のアドイン・コネクタ移行、Test Engineの廃止、BYOKからCMKへの移行状況です。
「非推奨」は、発表された瞬間に必ず停止するという意味ではありません。ただし、正式に削除されると機能しなくなるため、管理者は環境と設定の棚卸し、開発者はアプリ・フロー・カスタムコードの影響確認、現場部門は操作手順の見直しを早めに進める必要があります。Microsoftは「非推奨」を、将来のリリースで機能や能力を削除する予定がある状態と説明しており、正式削除まではサポートされるものの、削除後はその機能が動作しなくなるとしています。(Microsoft Learn)
Power Platformの非推奨情報でまず押さえるべきこと
Power Platform の非推奨情報を見るときは、「まだ使えるか」ではなく、業務停止・監査不備・セキュリティリスクにつながるかで優先順位を付けるのが実務的です。
特に Power Apps、Power Automate、Dataverse、モデル駆動型アプリを業務システムとして使っている組織では、次の3つに分けて確認すると漏れを減らせます。
| 確認対象 | 主な見るべきポイント | 放置した場合のリスク |
|---|---|---|
| 管理者・IT部門 | Dataverse監査、暗号化キー、認証方式、環境設定、コネクタ利用状況 | 監査レポートの欠落、API失敗、セキュリティ統制の低下 |
| アプリ作成者 | モデル駆動型アプリのグリッド、クラシック外観、Copilot、Figma／画像からのアプリ作成 | 画面表示や操作性の変化、作成手順の変更、ユーザー問い合わせ増加 |
| 開発者 | Power Automateコネクタ、カスタムJavaScript、テスト自動化、Dataverse API連携 | フロー停止、テスト資産の陳腐化、カスタム機能のエラー |
Power Platform の変更予告は、単なる「機能一覧」ではなく、運用・監査・開発プロセスに影響します。たとえば、UIの変更だけなら利用者教育で済む場合がありますが、監査イベントの出力項目変更や認証方式の変更は、ログ分析、アラート、コンプライアンス報告まで影響します。
2026年5月時点で優先確認すべき主な廃止・変更
以下は、Microsoft Learnの公式情報をもとに、管理者や開発者が優先して確認すべき項目を実務目線で整理したものです。(Microsoft Learn)
| 変更項目 | 時期・状態 | 影響を受けやすい対象 | 確認すべきこと |
|---|---|---|---|
| Dataverse監査イベントの変更 | 2026年5月以降、Microsoft Purviewに送信される監査イベントから前後のフィールド変更値が除外 | Purview、監査レポート、異常検知、コンプライアンス確認 | Purview側で旧値・新値を参照しているルールやレポートを洗い出す |
| Test Engineの廃止 | 2026年4月から非推奨。ドキュメントとGitHubリポジトリはMicrosoftによる保守対象外 | Power Platformの自動テストをTest Engineで組んでいる開発チーム | Playwrightベースのテストへ移行する計画を立てる |
| Editable Grid／Power Apps Read-Only Gridの廃止 | 2026年3月からモデル駆動型アプリで非推奨 | モデル駆動型アプリのビュー、サブグリッド、編集可能グリッド | Power Apps grid controlへ移行し、編集・並べ替え・フィルター動作を検証する |
| Power Automate for Excelアドインの廃止 | AppSource版アドインは非推奨 | Excelからフローを作成・実行しているユーザー | Excelの「Automate」タブへ移行し、利用端末ごとの差を確認する |
| モデル駆動型アプリのCopilotチャット廃止 | 2026年1月以降、Dynamics 365アプリで有効化されていない環境では非推奨 | モデル駆動型アプリでCopilotチャットを使う環境 | Microsoft 365 Copilotへの移行可否、ユーザー導線、ライセンスを確認する |
| モデル駆動型アプリのクラシック外観廃止 | 2026年4月以降、クラシック外観への切り替え不可 | クラシックUI前提の操作マニュアル、研修資料、利用者サポート | 最新の外観で画面確認し、マニュアルやスクリーンショットを更新する |
| 画像またはFigmaファイルからのアプリ作成廃止 | 2025年10月21日以降、新規作成で利用不可 | Power AppsでFigmaや画像からアプリを作っていた作成者 | Plansや生成ページなど、別の作成方法に切り替える |
| Format data by examplesの廃止 | 2025年8月第1週時点でPower Automateクラシックデザイナーの機能が非推奨 | 例から日付・数値・文字列の式を作っていたユーザー | 式アシスタントやCopilotによる式作成に移行する |
| Viva EngageコネクタのOAuth 2.0接続廃止 | 新規接続は2025年9月1日からEntra ID認証へ。既存OAuth2接続は2025年11月15日まで | Viva Engage連携フロー | 接続をEntra ID認証へ切り替える |
| Power Automateの個人用Microsoftアカウント対応廃止 | 2025年5月27日から非推奨、2025年7月26日に廃止期間終了 | 個人メールアカウントでクラウドフローを使うユーザー | 職場または学校アカウント、開発者環境などへの移行状況を確認する |
| SQL ServerコネクタV1アクションの廃止 | 2025年6月30日以降、V1アクションはサポート終了・無効化 | SQL Server連携フロー、Power Apps連携 | V2アクションへ置き換え、入出力スキーマの差分をテストする |
| Cards for Power Appsの廃止 | 2025年8月29日から非推奨・サポート終了 | Teamsで共有しているCards for Power Apps | Copilot StudioやTeams向けAdaptive Cardsへの移行を検討する |
| BYOK Dataverseサービスの廃止 | 2026年1月6日以降、BYOKサポート終了 | Dataverse環境でBYOKを使っていた組織 | Customer-managed keys（CMK）への移行状況を確認する |
Dataverse監査イベントの変更は、監査・分析基盤への影響が大きい
今回の変更で特に注意したいのが、DataverseからMicrosoft Purviewへ送信される監査イベントです。2026年5月以降、Purviewに送られる監査イベントには、フィールド変更前後の値が含まれなくなります。監査イベント自体は引き続き流れますが、フィールドレベルの詳細な値変更は除外されます。(Microsoft Learn)
影響を受けるのは、次のような仕組みです。
| 仕組み | 影響例 | 対応方針 |
|---|---|---|
| 異常検知ルール | 「金額が旧値から新値へ急増した」などの比較ができなくなる | 旧値・新値の取得元をDataverse監査へ変更する |
| Power BIや独自レポート | Purview由来のフィールド差分分析が欠落する | レポートのデータソースとクエリを見直す |
| コンプライアンスチェック | 変更者・変更日時は追えても、値の変化内容が不足する可能性 | 必要な粒度を再定義し、Dataverse側の監査情報を使う |
| SIEM連携 | ルールは動いていても検知条件が空振りする | テストデータでアラート条件を再検証する |
Microsoftは、詳細なフィールドレベルの監査情報が必要な場合、PurviewではなくDataverseから直接取得するよう案内しています。また、Purviewには変更者、変更日時、影響を受けたテーブルなどのメタデータは引き続き送信されると説明されています。(Microsoft Learn)
ここで失敗しやすいのは、「ログが流れているから問題ない」と判断してしまうことです。イベント件数だけを見る監視では異常に気づけません。旧値・新値を使っているルール、レポート、データパイプラインを個別に確認してください。
モデル駆動型アプリはグリッドと外観の確認が必須
モデル駆動型アプリでは、画面部品と見た目に関する変更が続いています。特に業務アプリとして使っている場合、ユーザーが毎日操作する一覧画面、サブグリッド、編集可能グリッドの影響確認が重要です。
Microsoftは、Editable Grid controlとPower Apps Read-Only Grid controlを2026年3月から非推奨としています。既存実装は当面動作しますが、重要なセキュリティ修正のみが提供され、新機能は追加されません。推奨される移行先はPower Apps grid controlです。(Microsoft Learn)
グリッド移行で確認すべき項目
Power Apps grid controlへ切り替えるときは、単に表示できるかだけでなく、実際の業務操作で検証する必要があります。
| 確認項目 | 具体的なチェック内容 |
|---|---|
| インライン編集 | 編集可能列、保存タイミング、入力制御、業務ルールの動作 |
| ビューとサブグリッド | 一覧画面、フォーム内サブグリッド、関連レコード表示 |
| 並べ替え・フィルター | 既存ユーザーが使っている検索条件や並べ替えが維持されるか |
| コマンドバー | ボタン、カスタムコマンド、選択行に対する処理 |
| セキュリティロール | 表示・編集権限が意図通り反映されるか |
| モバイル利用 | スマートフォンやタブレットでの表示崩れ、操作性 |
モデル駆動型アプリのクラシック外観についても、2026年4月以降は切り替えできなくなり、すべてのアプリが既定でモダンな外観を使用します。Microsoftは、アプリのロジック、データ、アクセス許可には影響しないと説明していますが、管理者設定は削除されます。(Microsoft Learn)
この変更で実務上問題になりやすいのは、アプリそのものよりも、操作マニュアル、社内研修、問い合わせ対応です。画面の位置や名称が変わると、利用者は「機能が消えた」と感じることがあります。公開前に主要画面のスクリーンショットを更新し、問い合わせ窓口には変更点を共有しておくと混乱を抑えられます。
Power Automateはコネクタ・アカウント・Excel連携をまとめて確認する
Power Automateでは、複数の廃止・変更が重なっています。特に注意すべきなのは、Excel連携、SQL Serverコネクタ、Viva Engageコネクタ、個人用Microsoftアカウント、クラシックデザイナー関連の機能です。
AppSourceで提供されていたMicrosoft Power Automate for Excelアドインは非推奨となり、Excelの「Automate」タブによるネイティブ統合への切り替えが案内されています。ネイティブ統合はWeb版ExcelとWindowsデスクトップ版Excelでサポートされ、macOSデスクトップ版Officeを使う場合はブラウザーでExcelを開いてAutomateタブにアクセスする必要があります。(Microsoft Learn)
Power Automateで確認すべき実務ポイント
| 確認対象 | 確認内容 | 注意点 |
|---|---|---|
| Excel連携 | AppSource版アドインを使っていないか | ユーザー端末によってAutomateタブの見え方が異なる |
| SQL Serverコネクタ | V1アクションが残っていないか | V2へ置き換えるだけでなく、出力値や動的コンテンツの差分を確認 |
| Viva Engage連携 | OAuth 2.0接続を使っていないか | Entra ID認証への切り替え後、実行ユーザー権限も確認 |
| 個人用Microsoftアカウント | 個人メールアカウントでクラウドフローを所有していないか | 廃止後はクラウドフローへのアクセス削除やフロー削除の影響がある |
| クラシックデザイナーの式作成 | Format data by examplesに依存していないか | 式アシスタントやCopilotでの式作成に移行 |
SQL ServerコネクタのV1アクションは、2025年6月30日以降サポートされず無効化されると案内されています。V2アクションへの移行では、同じように見えるアクションでも、戻り値、エラー時の挙動、動的コンテンツの参照名が変わる可能性があります。置き換え後は、保存して終わりにせず、成功パターンと失敗パターンの両方でテストしてください。(Microsoft Learn)
個人用Microsoftアカウントについては、Power Automateポータルやモバイルアプリへのログイン、クラウドフローの作成・編集・管理、関連フローへのアクセスに影響があります。なお、Power Automate for desktopは個人メールアカウントでも引き続き動作すると説明されています。(Microsoft Learn)
Test Engine利用中のチームはPlaywright移行を前提にする
Power PlatformのTest Engineは、2026年4月から非推奨となりました。Microsoftは、ドキュメントとGitHubリポジトリを今後保守しないと説明しており、代替としてPower Platform向けのPlaywrightサンプルを案内しています。(Microsoft Learn)
テスト自動化でTest Engineを使っている場合は、次の順番で移行を進めると現実的です。
| 手順 | 作業内容 |
|---|---|
| 既存テストの棚卸し | どのアプリ、画面、シナリオをTest Engineで検証しているか一覧化する |
| 重要シナリオの分類 | ログイン、一覧表示、登録、更新、承認、エラー処理などに分ける |
| Playwright化の優先順位付け | 本番障害時の影響が大きい業務から移行する |
| テストデータ設計 | 毎回同じ条件で実行できるデータ作成・後片付けを決める |
| CI/CDへの組み込み | 手動実行ではなく、リリース前に自動で失敗を検知できるようにする |
移行で避けたいのは、画面上の文字列や待機時間に強く依存した不安定なテストです。Power PlatformはUIやコントロールの更新が継続的に行われるため、テストでは業務上重要な結果を検証し、細かな見た目だけに依存しない設計にしておくと保守しやすくなります。
Copilot関連は「機能の有無」だけでなく利用者導線を確認する
モデル駆動型アプリのCopilotチャットは、Dynamics 365アプリで有効化されていない環境では2026年1月以降に非推奨となります。Microsoftは、モデル駆動型アプリにおける自然言語操作の推奨ソリューションとしてMicrosoft 365 Copilotを示しています。移行期間中は、環境によってCopilotのドロップダウンに複数の選択肢が表示される場合があります。(Microsoft Learn)
管理者が確認すべきなのは、単に「Copilotが使えるか」ではありません。次の点まで確認してください。
| 確認項目 | 見るべきポイント |
|---|---|
| 環境 | Dynamics 365アプリで有効化されている環境か |
| ライセンス | Microsoft 365 Copilotの利用条件を満たしているか |
| ユーザー導線 | 旧CopilotチャットとMicrosoft 365 Copilotの使い分けを説明できるか |
| 業務アプリ側の期待値 | アプリ固有の質問、検索、操作支援がどこまで可能か |
| サポート体制 | 問い合わせ時に「どのCopilotを使っているか」を切り分けられるか |
Copilotは利用者の期待値が高くなりやすい機能です。移行時は「何ができるか」だけでなく、「以前と同じ質問で同じ回答が得られるとは限らない」ことも説明しておくと、現場の混乱を抑えられます。
BYOK利用環境はCMK移行状況を必ず確認する
DataverseのBring Your Own Key（BYOK）は、2026年1月6日以降にサポート終了となります。Microsoftは、強化されたソリューションとしてCustomer-managed keys（CMK）への移行を推奨しています。また、2025年6月1日以降は本番環境にBYOKを適用できず、2026年1月6日までにCMK移行が完了していない場合、環境はMicrosoft管理キーへ自動的に戻ると説明されています。(Microsoft Learn)
BYOKからCMKへの移行は、単なる設定変更ではなく、セキュリティ運用の変更です。次の観点で確認してください。
| 確認項目 | 実務上のポイント |
|---|---|
| 対象環境 | 本番、サンドボックス、開発環境でBYOK利用有無を確認 |
| キー管理 | キーの所有者、更新手順、緊急時対応を明確化 |
| 権限 | キー管理に必要な管理者権限を最小限にする |
| テスト | 非本番環境で移行手順と影響を確認 |
| 監査 | 移行前後で暗号化・アクセス監査の証跡を残す |
暗号化キー関連は、問題が起きたときの影響が大きいため、アプリ担当者だけでなく、セキュリティ部門、監査部門、Microsoft 365またはAzureの管理者も含めて確認するのが安全です。
認証・外部連携ではサービスプリンシパルの有無を確認する
Dataverseでは、Microsoft Entra IDテナントにサービスプリンシパルが存在しないマルチテナントアプリについて、アプリ専用トークンのサポートが削除されています。対象テナントにサービスプリンシパルがない場合、トークン生成が失敗し、Dataverse API連携に影響します。(Microsoft Learn)
開発者は、次のような連携を確認してください。
| 確認対象 | チェック内容 |
|---|---|
| Dataverse API連携 | アプリ登録、サービスプリンシパル、アプリケーションユーザーの対応関係 |
| 外部システム連携 | トークン取得エンドポイント、テナントID、権限付与 |
| バッチ処理 | 夜間処理や定期同期で認証エラーが出ていないか |
| 古い実装 | organizations エンドポイントや曖昧なテナント指定が残っていないか |
認証まわりの変更は、利用者画面ではなくバックエンド処理で発生するため、気づいたときには連携データが止まっていることがあります。監視では「フローの成功・失敗」だけでなく、APIの応答コード、トークン取得失敗、同期件数の急減も見るようにしてください。
管理者と開発者が進めるべき棚卸し手順
Power Platformの廃止・変更予告に対応するには、個別項目を読むだけでは不十分です。環境、アプリ、フロー、コネクタ、監査基盤を横断して棚卸しする必要があります。
| 手順 | 作業内容 | 担当の目安 |
|---|---|---|
| 環境一覧を作る | 本番、サンドボックス、開発者環境、所有者、用途を整理 | Power Platform管理者 |
| 影響機能を洗い出す | グリッド、Copilot、BYOK、Purview監査、コネクタ、個人アカウント利用を確認 | 管理者、アプリ所有者 |
| 重要度を付ける | 業務停止、監査不備、セキュリティ影響、利用者数で分類 | 情シス、業務部門 |
| 移行先を決める | Power Apps grid control、CMK、Entra ID認証、V2アクションなどを選定 | 開発者、管理者 |
| 非本番で検証する | UI、権限、フロー実行、ログ出力、レポート更新を確認 | 開発者、テスター |
| 本番展開を計画する | 展開日、ロールバック可否、利用者通知、問い合わせ対応を決める | 管理者、業務責任者 |
| 展開後に監視する | フロー実行履歴、監査ログ、問い合わせ件数、APIエラーを確認 | 運用担当 |
この棚卸しで重要なのは、Power Platform管理者だけで完結させないことです。Power AppsやPower Automateは現場部門が作成・管理しているケースが多く、管理センター上の情報だけでは実際の利用状況を把握しきれない場合があります。アプリ所有者、フロー所有者、業務責任者に確認し、「誰が使っているか」「止まると何が困るか」を明確にしてください。
優先順位は「期限」だけでなく「業務影響」で決める
廃止・変更対応では、期限が近いものから順に処理したくなります。しかし、実務では期限よりも影響度が大きい項目を先に確認すべきです。
優先順位は次のように考えると判断しやすくなります。
| 優先度 | 対象例 | 理由 |
|---|---|---|
| 最優先 | Dataverse監査、BYOK／CMK、認証、SQL Server V1、個人アカウントのクラウドフロー | 監査不備、セキュリティリスク、業務停止につながりやすい |
| 高 | モデル駆動型アプリのグリッド、クラシック外観、Copilot | 利用者影響が大きく、問い合わせや教育コストが発生しやすい |
| 中 | Test Engine、Figma／画像からのアプリ作成、Format data by examples | 開発・作成プロセスへの影響が中心で、計画的に移行しやすい |
| 要確認 | 過去に廃止済みのコネクタや古いクライアントAPI | 既に障害原因になっている可能性がある |
特に、既に期限を過ぎている項目は「今から期限前対応する」のではなく、障害が起きていないか、代替手段へ移行済みかを確認する対象として扱います。たとえば、SQL ServerコネクタV1アクション、Cards for Power Apps、個人用Microsoftアカウントのクラウドフローは、残存していれば既に不具合や利用不可の原因になっている可能性があります。(Microsoft Learn)
展開時に失敗しやすいポイント
Power Platformの非推奨対応では、移行先の機能を有効にするだけでは不十分です。以下の失敗は実務で起こりやすいため、事前に対策しておきましょう。
| 失敗しやすいポイント | 回避策 |
|---|---|
| グリッドを切り替えたが、現場の編集手順が変わった | 主要シナリオを利用者と一緒に検証し、操作マニュアルを更新する |
| フローのアクションを置き換えたが、動的コンテンツの参照が壊れた | 置き換え後に実行履歴と出力JSONを確認する |
| Purviewの監査イベント件数だけを見て問題なしと判断した | 旧値・新値を使うレポートやアラートを個別に検証する |
| Copilotの名称だけで利用者が混乱した | どの画面でどのCopilotを使うか、問い合わせ窓口向けに整理する |
| 非本番環境だけで成功し、本番の権限差で失敗した | 本番相当のセキュリティロール、接続、データ量で確認する |
| 変更内容をIT部門だけで決めた | アプリ所有者、業務部門、監査担当を含めて影響を確認する |
Power Platformはローコードで変更しやすい一方、現場部門が独自に作成したアプリやフローが業務の中核になっていることがあります。廃止・変更予告への対応では、「管理者が知っている環境」だけでなく、「現場が実際に使っているアプリ」を見つけることが重要です。
次に取るべき行動
まずは、Power Platform管理センターや社内のアプリ台帳を使って、Power Apps、Power Automate、Dataverse環境の棚卸しを始めてください。最初に確認するべきなのは、Dataverse監査とPurview連携、BYOK／CMK、SQL ServerやViva Engageなどのコネクタ、モデル駆動型アプリのグリッドと外観です。
そのうえで、影響がある項目ごとに「移行先」「検証環境」「本番展開日」「利用者通知」「展開後の監視」を決めます。Power Platformの非推奨情報は今後も更新されるため、一度確認して終わりではなく、四半期ごとの運用チェック項目に入れておくと、突然の機能停止や監査不備を防ぎやすくなります。
Microsoft Learnの公式ページでは、キャンバスアプリやPower Pagesなど、関連領域の非推奨情報は別ページも参照するよう案内されています。Power Platform全体を運用している場合は、Power Apps、Power Automate、Dataverseだけでなく、Power PagesやDynamics 365関連の変更情報もあわせて確認しておくと安全です。(Microsoft Learn)
コメント