Power Platform管理センターの「Get support」は、Power PlatformのトラブルをAI搭載のサポートエージェントで切り分け、自己解決できない場合に同じ流れでMicrosoftサポートへ問い合わせるための入口です。2026年5月16日に更新された公式情報では、サポートエージェントを中心とした問い合わせ手順、バックアップ用のWebフォーム、サポートプランの紐づけ、診断同意、サービス正常性や既知の問題の確認方法が整理されています。(Microsoft Learn)
管理者がまず確認すべき結論は、「問い合わせフォームの場所が分かればよい」ではありません。適切な権限、アクティブなサポートプラン、正しい製品分類、重大度の判断、環境情報、診断同意の扱いまでを事前に決めておくことが重要です。準備が不足していると、サポートリクエストを作成できない、誤った担当にルーティングされる、調査開始が遅れるといった問題につながります。
Power Platform管理センターのGet supportで押さえるべき要点
Power Platform管理センターのGet supportは、Power Apps、Power Automate、Dataverse、Power Platform管理センターなどに関する問題を、管理者がPower Platform admin centerから扱うためのサポート導線です。公式情報では、管理者はサポートエクスペリエンス上で自己解決策を確認し、それでも解決しない場合はサポートプランを使ってMicrosoftサポート担当者へ問い合わせられると説明されています。(Microsoft Learn)
今回の情報で特に重要なのは、サポートの入口がAI搭載のSupport agentを中心に説明されている点です。ただし、すべてのテナントや状況で同じ画面になるとは限りません。多くのユーザーはSupport agentを利用しますが、エージェントが利用できない場合やパフォーマンス上の問題がある場合は、バックアップのサポートエクスペリエンスが表示されます。(Microsoft Learn)
| 確認ポイント | 実務上の意味 | 管理者がやるべきこと |
|---|---|---|
| AI搭載Support agent | 問題説明をもとに解決策提示と問い合わせ作成を支援する | AIの回答を鵜呑みにせず、公式ドキュメントや実環境で確認する |
| バックアップWebフォーム | エージェントが使えない場合も問い合わせ導線を維持する | 運用手順書に「Webフォームへ切り替わる場合がある」と明記する |
| サポートプラン | 自己解決策の閲覧と問い合わせ作成の条件が異なる | 契約状態、アクセスID、パスワードを事前に確認する |
| 製品分類 | 誤った分類は担当ルーティングの遅延につながる | 管理センターの問題はPower Platform Administrationを選ぶ |
| 診断同意 | Microsoftが調査に必要な情報へアクセスできるかに関わる | どの同意レベルを許可するか、社内ルールを決めておく |
| サービス正常性・既知の問題 | 問い合わせ前に障害や既知不具合を確認できる | インシデント対応フローに確認手順を組み込む |
何が変わるのか：問い合わせ前の「自己解決」と「正しいルーティング」がより重要に
Get supportの流れでは、最初に問題内容を説明し、Support agentが追加質問を行い、既知の問題、ドキュメント、コミュニティ情報などをもとに解決策を提示します。そのうえで解決しない場合に、アクティブなサポートプランを使ってサポートリクエストを作成します。(Microsoft Learn)
これは、管理者や開発者にとって「問い合わせ前の情報整理」が以前より重要になることを意味します。AIサポートエージェントは入力された説明をもとに分類や回答生成を行うため、曖昧な説明では適切な解決策にたどり着きにくくなります。
たとえば、次のような説明では切り分けが進みにくいです。
「Power Appsが動きません」
一方、次のように書くと、原因の候補や担当領域を絞り込みやすくなります。
「本番環境のモデル駆動型アプリで、2026年5月17日 10:20頃から営業部ユーザーのみ取引先テーブルのビュー表示に失敗します。管理者では再現せず、対象ユーザーではEdgeとChromeの両方で再現します。直前にセキュリティロールを変更しました」
問い合わせの質は、サポート対応の速度に直結します。特に、発生日時、対象環境、影響範囲、再現手順、期待される動作、実際の動作、直前の変更内容は、最初の説明に入れておくべきです。
対象者と影響範囲
Get supportの更新内容は、Power Platformを利用するすべてのエンドユーザーに直接影響するというより、問い合わせや障害対応を担う管理者、運用担当者、開発者に影響します。Power Platform admin centerのSupport requestsページへアクセスするには、Billing Admin、Company Admin、Environment Admin、Power Platform Admin、Power Apps Full Admin、Helpdesk Admin、Security Admin、Teams Adminなど、公式情報に列挙された対象ロールのいずれかが必要です。(Microsoft Learn)
| 対象者 | 影響する作業 | 確認すべきこと |
|---|---|---|
| Power Platform管理者 | サポートリクエスト作成、重大度判断、サポートプラン管理 | 権限、契約、環境URL、診断同意の社内基準 |
| 環境管理者 | 環境単位の障害調査、Dataverseやアプリの切り分け | 対象環境、直前の変更、ユーザー影響範囲 |
| 開発者 | Power AppsやPower Automateの不具合再現、ログ取得 | 最小再現手順、コード、コネクタ、ネットワークトレース |
| ヘルプデスク | 初期受付、既知障害確認、管理者へのエスカレーション | サービス正常性、既知の問題、問い合わせテンプレート |
| セキュリティ・法務担当 | Microsoftによる診断アクセスや環境コピーの扱い | 顧客データを含む調査同意の可否と承認フロー |
エンドユーザーが直接Microsoftへサポートリクエストを作成する運用ではなく、社内の管理者やヘルプデスクが一次切り分けを行い、必要に応じてPower Platform admin centerから問い合わせる設計にしておくと混乱を防げます。
サポートリクエストを作成する前に確認すべき設定
Get supportを使う前に、最低限以下の項目を確認してください。特に本番障害時は、ここが未整理だと問い合わせ作成そのものに時間を取られます。
| 項目 | 確認内容 | 不備がある場合のリスク |
|---|---|---|
| 管理者ロール | 問い合わせ担当者がSupport requestsにアクセスできるか | 障害発生時にリクエストを作成できない |
| サポートプラン | Subscription support、Professional Direct support、Unified supportなどの有効な契約があるか | 自己解決策は見られても、サポートリクエストを作成できない |
| サポートプランの紐づけ | Access IDとPasswordで対象製品に紐づいているか | 問い合わせ画面で契約が見つからない |
| 対象製品 | Power Platform Administration、Dataverse、Power Appsなどを正しく選ぶ | 誤ルーティングで対応が遅れる |
| 対象環境 | 環境名、環境URL、リージョン、種類が分かるか | Microsoft側の調査開始が遅れる |
| 重大度 | 業務停止、回避策の有無、影響ユーザー数を整理しているか | Severity Aの自動ダウングレードや対応遅延につながる |
| 診断同意 | Microsoftによる診断情報アクセスやサポート環境作成を許可できるか | 追加確認が必要になり、調査が止まる |
| サービス正常性 | 現在発生中または解決済みの障害がないか | 既知障害なのに不要な個別調査を始めてしまう |
| 既知の問題 | 回避策や修正予定が公開されていないか | 既に案内されている対応を見落とす |
公式情報では、サポートプランがなくても自己解決リソースにはアクセスできますが、サポートリクエストの作成にはアクティブなサポートプランが必要とされています。また、サポートプランを追加した場合、利用可能になるまで最大1時間かかる場合があります。(Microsoft Learn)
AI-powered support agentで問い合わせる手順
Support agentを使う場合の基本的な流れは、Power Platform admin centerにサインインし、ナビゲーションからSupport、Support requests、Get supportの順に進むことです。表示されたSupport agentペインでチャット形式の案内に従い、問題内容の説明、製品の確認、追加質問への回答、解決策の確認、サポートリクエスト作成へ進みます。(Microsoft Learn)
問題説明は「分類されやすい形」で書く
Support agentは、入力された説明をもとに問題を理解し、製品やカテゴリの候補を判断します。そのため、最初の説明では以下を入れると実務上役立ちます。
| 入れるべき情報 | 具体例 |
|---|---|
| いつから発生したか | 2026年5月17日 9:30頃から |
| どこで発生したか | 本番環境、Dataverse環境URL、対象アプリ名 |
| 誰に影響しているか | 営業部ユーザー約80名、管理者は再現しない |
| 何が起きているか | フロー実行が失敗し、承認メールが送信されない |
| 期待される動作 | 申請登録後、承認者へTeams通知が送信される |
| 実際の動作 | フロー履歴でコネクタ認証エラーが出る |
| 直前の変更 | DLPポリシー変更、ソリューション展開、接続参照の更新 |
| 試したこと | 再認証、別ブラウザ確認、別ユーザー確認、サービス正常性確認 |
管理センター自体の問題や管理操作に関する問題では、製品としてPower Platform Administrationを選択するよう公式情報で案内されています。一方、Dynamics 365 Customer Serviceを誤って選ぶと、リクエストが誤った場所へ送られて遅延する可能性があるため注意が必要です。(Microsoft Learn)
AI生成の回答は検証してから使う
Support agentは、既知の問題、Microsoftドキュメント、コミュニティコンテンツなどを参照して回答を生成します。ただし、公式情報でもAI生成コンテンツは誤っている可能性があると明記されています。(Microsoft Learn)
そのため、AIが提示した手順を本番環境でそのまま実行するのは避けてください。設定変更、DLPポリシー変更、コネクタ再認証、環境コピー、ソリューション再展開などは、影響範囲を確認し、必要に応じて検証環境で試してから実行するのが安全です。
バックアップサポートエクスペリエンスが表示される場合
Support agentが利用できない、クラッシュする、応答性能に問題がある、または特定の業務シナリオや技術的制約、ポリシー上の理由がある場合は、バックアップのサポートエクスペリエンスが使われます。エージェントがクラッシュした場合は、Webフォームへ切り替えるボタンが表示され、8時間のクールダウン期間中はバックアップ体験が既定で読み込まれると説明されています。(Microsoft Learn)
ここで重要なのは、社内手順書を「Support agentが必ず表示される」前提で作らないことです。障害対応マニュアルには、チャット型の画面とWebフォーム型の画面のどちらでも、同じ情報を入力できるようにテンプレートを用意しておくべきです。
サービス正常性と既知の問題を先に確認する
Power Platformのトラブルでは、個別環境の設定ミスではなく、Microsoft側のサービス障害や既知の製品問題が原因である場合があります。Power Platform admin centerでは、SupportのService healthタブからDynamics 365やPower Platform製品のサービス正常性を確認でき、製品カテゴリ、問題種別、ステータスで絞り込みできます。(Microsoft Learn)
既知の問題については、SupportのKnown issuesタブから確認できます。公式情報では、既知の問題には説明、回避策、修正見込みが利用可能な場合に表示されるとされており、該当する既知の問題がある場合は、基本的に新しいサポートリクエストを作成せず、詳細ページの更新を確認する流れが示されています。(Microsoft Learn)
障害対応では、次の順序で確認すると無駄な問い合わせを減らせます。
| 順序 | 確認先 | 判断ポイント |
|---|---|---|
| 1 | Service health | テナントや製品に影響するアクティブな障害がないか |
| 2 | Known issues | 同じ症状の既知問題や回避策がないか |
| 3 | 変更履歴 | 直前にソリューション、権限、DLP、接続、環境設定を変えていないか |
| 4 | 再現範囲 | 特定ユーザー、特定アプリ、特定環境、全体障害のどれか |
| 5 | Get support | 自己解決できない場合にサポートリクエストを作成する |
重大度は業務影響と対応体制で決める
サポートリクエストでは重大度の選択が重要です。Microsoftのサポート概要では、Severity Aは重大な業務影響があり即時対応が必要なケース、Severity Bは中程度の業務影響があるが回避策により業務継続が可能なケース、Severity Cは影響が小さいケースとして整理されています。Severity AやBでは、対応体制や連絡可能性も求められます。(Microsoft Learn)
| 重大度 | 適した状況 | 避けるべき使い方 |
|---|---|---|
| Severity A | 本番業務が広範囲に停止し、即時対応が必要 | 担当者が24時間対応できないのに選択する |
| Severity B | 業務影響は大きいが、暫定回避策で継続できる | 実質的には軽微な不具合なのに緊急扱いにする |
| Severity C | 一部機能の不具合、調査依頼、軽微な影響 | 本番停止に近い状況なのに低く設定する |
公式情報では、Severity Aを送信する場合はMicrosoftと継続的に対応できる必要があり、それができない場合は低い重大度で申請すべきとされています。また、低優先度の問題にSeverity Aを選ぶと適切な重大度へ自動的に下げられる可能性があります。(Microsoft Learn)
管理者は、単に「早く見てほしい」ではなく、業務停止の範囲、回避策の有無、売上や顧客影響、社内の対応可能時間をもとに重大度を決めるべきです。
診断同意とサポート環境は事前に社内ルールを決める
Power Platformのサポートでは、Microsoftが問題調査のためにテナントや環境内の診断情報へアクセスしたり、サポート環境を作成したりする場合があります。Microsoftは同意なしに顧客データへアクセスしたり環境を複製したりしないと説明しており、同意は一時的で、いつでも取り消せます。(Microsoft Learn)
同意の選択肢には、診断情報への読み取りアクセス、顧客データを含まない最小コピー、顧客データを含むフルコピー、診断情報へのアクセスを許可しない選択肢があります。診断情報へのアクセス許可は既定では選択されず、明示的に選択する必要があります。(Microsoft Learn)
| 同意の観点 | 管理者が決めておくこと |
|---|---|
| 診断情報アクセス | どの種類の障害なら許可するか |
| 最小コピー | 顧客データを含まない環境複製を許可できるか |
| フルコピー | 顧客データを含む複製を誰が承認するか |
| 同意の取り消し | ケース対応中に誰が判断し、誰が操作するか |
| 監査対応 | サポート環境の作成・アクセスをどのように記録するか |
サポート環境は本番環境に影響を与えずに再現や解決策の評価を行うための複製環境です。サポート環境はPower Platform admin centerで管理者に表示され、アクセスや使用は監査されます。サポート環境は7日で期限切れになるか、チケット解決時に終了し、システム管理者はいつでも削除できます。(Microsoft Learn)
開発者が準備すべきサポートリクエストの書き方
Power AppsやDataverse、モデル駆動型アプリ、カスタムコードに関する問題では、開発者側の切り分けが重要です。Microsoftの「効果的なサポートリクエスト」の案内では、Power Appsのバグと個別アプリのバグを区別し、誰でも再現できる情報を提供することが重要だと説明されています。(Microsoft Learn)
開発者が準備すべき情報は次のとおりです。
| 情報 | 具体例 |
|---|---|
| 再現手順 | どの画面で、どのボタンを押し、どの条件で失敗するか |
| 期待される動作 | 本来表示されるレコード、送信される通知、成功する処理 |
| 実際の動作 | エラーメッセージ、空白表示、タイムアウト、失敗コード |
| 最小再現構成 | 本番アプリ全体ではなく、問題を再現する最小アプリやソリューション |
| ネットワーク情報 | Monitorやブラウザー開発者ツールで取得したトレース |
| 画面証跡 | スクリーンショット、動画、エラー画面 |
| システム情報 | セッションID、ブラウザー、環境、対象ユーザー |
| 直前の変更 | ソリューション展開、Power Fx変更、JavaScript変更、接続参照変更 |
特に、カスタムJavaScript、Power Fx、Webリソース、コネクタ、Dataverse権限が絡む場合は、「本番アプリで起きています」だけでは不十分です。問題を切り出した最小コードや検証環境での再現結果を用意すると、Microsoftサポート側が製品不具合か個別実装の問題かを判断しやすくなります。
移行・展開時に注意すべきポイント
Power Platformの移行や展開作業では、Get supportの使い方を事前に運用設計へ組み込んでおくべきです。特に、本番展開直後の不具合では、環境、ソリューション、接続参照、DLPポリシー、セキュリティロール、Dataverseテーブル権限、カスタムコネクタなど、複数の要素が絡みます。
展開前に次の情報を記録しておくと、サポートリクエスト作成時に役立ちます。
| 展開前に残す情報 | 理由 |
|---|---|
| 展開日時と作業者 | 問題発生時刻と変更の関連を確認するため |
| ソリューション名とバージョン | どの変更が影響したかを特定するため |
| 対象環境URL | サポートリクエストで環境指定が必要になるため |
| 変更した接続参照 | Power Automateやコネクタ認証の問題を切り分けるため |
| 変更したDLPポリシー | コネクタ利用制限による失敗を確認するため |
| 変更したセキュリティロール | 特定ユーザーだけの不具合を調査するため |
| ロールバック手順 | サポート回答を待つ前に業務継続策を判断するため |
また、公式情報では、一部のサポートリクエストでサポート環境のリクエストが求められる場合がある一方、Power AppsやPower Automateを製品として選んだ場合、現在はサポート環境を作成できないとされています。Power Platformの問題でサポート環境を含むリクエストを作成する場合は、製品としてMicrosoft Dataverseを選択するよう案内されています。(Microsoft Learn)
この点は、移行・展開時のトラブル対応で見落としやすいポイントです。Power AppsやPower Automateの画面で発生した問題でも、Dataverse環境やサポート環境が調査に必要な場合は、製品分類の選び方が対応速度に影響します。
Report outageは表示されるテナントでのみ利用できる
Power Platform admin centerでは、テナントによっては直接「Report outage」機能を利用できる場合があります。公式情報では、この機能が有効な場合、サポートページ上のGet supportボタンの横にReport outageボタンが表示され、高優先度のサポートリクエストを起票できると説明されています。表示されない場合は、アクティブなサポートプランがあればSupport agentまたはサポートエクスペリエンスの流れから高優先度のリクエストを作成します。(Microsoft Learn)
ただし、Report outageは「問い合わせを早めるボタン」ではなく、サービス停止や重大な影響が疑われる場合に使う機能です。個別アプリの軽微な表示崩れ、開発環境だけのエラー、社内設定変更が原因と思われる問題では、まずサービス正常性、既知の問題、変更履歴を確認してから通常のサポートリクエストを検討してください。
よくある失敗と回避策
| 失敗例 | 起きる問題 | 回避策 |
|---|---|---|
| サポートプランを確認していない | リクエスト作成直前で契約が見つからない | 平時にSupport plansで契約の表示を確認する |
| 製品分類を誤る | 担当チームへのルーティングが遅れる | 管理センター問題はPower Platform Administrationを選ぶ |
| Severity Aを安易に選ぶ | 対応体制がない場合にダウングレードされる | 業務影響と24時間対応可否で判断する |
| Advisory案件をTechnicalで出す | リクエストがクローズされる可能性がある | 技術的障害か助言依頼かを事前に分ける |
| AI回答をそのまま本番適用する | 不要な設定変更や二次障害につながる | 検証環境、公式ドキュメント、変更承認を通す |
| 環境が一覧に出ずに止まる | 問い合わせを完了できない | My environment is not listedを選び、環境URLを入力する |
| 診断同意を社内で決めていない | Microsoft側の調査が開始できない | 同意レベルごとの承認者を決める |
| 再現手順が曖昧 | サポート側で問題を再現できない | 期待結果、実際の結果、最小再現構成を添える |
管理者が今すぐやるべきこと
Power PlatformのGet support対応で最初にやるべきことは、障害が起きてから画面を探すことではありません。平時に、問い合わせ可能な管理者、サポートプラン、診断同意、重大度判断、開発者から受け取る情報テンプレートを決めておくことです。
まず、Power Platform admin centerにアクセスできる管理者ロールを確認します。次に、対象製品にサポートプランが正しく紐づいているかを確認します。そのうえで、ヘルプデスクや開発チーム向けに、発生日時、環境URL、対象アプリ、影響ユーザー、再現手順、期待結果、実際の結果、直前の変更、取得済みログを記入するテンプレートを用意してください。
Power Platformのサポート対応は、AIサポートエージェントによって入口が便利になる一方、入力する情報の質がより重要になります。管理者は、Get supportを「最後に押すボタン」ではなく、サービス正常性、既知の問題、社内変更履歴、再現情報、診断同意をつなぐ運用プロセスとして整備することが、迅速な復旧への近道です。
コメント