Power Automate for desktopを社内展開している場合、今回まず確認すべき結論は「Power Platform管理センターだけでなく、各Windows端末のレジストリ設定まで含めて統制する必要がある」という点です。Microsoft Learnの「Governance in Power Automate for desktop」では、更新、サインイン、プロキシ、証明書、ログ、外部実行、Copilot、UI AccessなどをWindowsレジストリキーで制御する方法が整理されています。なお、Microsoft Learn上では最終更新日が2026年5月20日と表示されており、本記事では日本時間の2026年5月21日時点で管理者・開発者が確認すべきポイントとして整理します。(Microsoft Learn)
Power Platformの「Governance in Power Automate for desktop – Power Automate」は何が変わるのか
今回の公式情報で重要なのは、Power Automate for desktopのガバナンスが「フロー作成者の運用ルール」だけでは完結しない点です。端末側のWindowsレジストリを使い、誰がサインインできるか、どのテナントに接続できるか、ログをどこまで残すか、外部ショートカットからフローを起動できるかといった挙動を制御できます。(Microsoft Learn)
特に企業利用では、以下のような場面で影響が出ます。
| 確認領域 | 影響を受ける人 | 実務上の確認ポイント |
|---|---|---|
| サインイン制御 | 情シス、Power Platform管理者、利用部門 | 個人Microsoftアカウントやライセンスなしアカウントでの利用を許可していないか |
| テナント・リージョン制御 | 管理者、運用担当 | 想定外のテナント登録や別リージョン接続を防げているか |
| プロキシ・証明書 | ネットワーク管理者 | 社内プロキシ、証明書失効チェック、認証方式と矛盾していないか |
| ログ・診断 | セキュリティ担当、開発者 | トラブルシュートに必要なログと、機密情報保護のバランスを取れているか |
| 外部実行・共有フロー | 開発者、利用部門 | URLやショートカット経由の実行、信頼していない作成者の共有フローを許可するか |
| Copilot・AI関連 | Power Platform管理者 | 組織ポリシーに合わせてCopilot機能やフィードバック送信を制御するか |
| UI Access | RPA開発者、端末管理者 | 管理者権限が必要なアプリを自動化する端末に限定して有効化するか |
つまり、Power Automate for desktopを本番業務で使っている企業は、フローそのものだけでなく、実行端末の設定を棚卸しする必要があります。
最初に押さえるべき注意点
Windowsレジストリは強力ですが、誤った変更をするとOSやアプリの動作に影響する可能性があります。Microsoft Learnでも、レジストリ変更前にバックアップを取ること、存在しないキーは作成してから値を追加することが案内されています。(Microsoft Learn)
運用では、いきなり全社端末に展開するのではなく、次の順序で進めるのが安全です。
| 手順 | やること | 失敗しやすいポイント |
|---|---|---|
| 現状把握 | Power Automate for desktopのバージョン、MSI版かどうか、利用テナントを確認 | バージョン依存の設定を古い端末に適用して効かない |
| 方針決定 | サインイン、ログ、外部実行、Copilotなどの許可範囲を決める | セキュリティ部門と開発部門の認識がずれる |
| 検証 | 代表端末でレジストリ設定後の動作を確認 | プロキシや証明書設定でクラウド接続が失敗する |
| 段階展開 | Intune、グループポリシー、PowerShellなどで配布 | HKLMとHKCUの違いを見落とす |
| 監査 | 設定値、フロー実行結果、ユーザー問い合わせを確認 | ログ抑止により障害解析に必要な情報まで失う |
HKLM配下の設定は端末全体に影響しやすく、HKCU配下の設定はユーザー単位で効くものがあります。共有端末やVDI環境では、どのユーザーコンテキストで設定するかを事前に確認してください。
管理者が優先して確認すべきレジストリ設定
Power Automate for desktopのガバナンス設定は数が多いため、すべてを一度に変更するよりも、リスクの高い領域から確認するのが現実的です。
更新と自動起動の制御
Power Automate for desktopを社内標準バージョンで運用している場合、利用者が手動で更新してしまうと、検証前のバージョンが混在する可能性があります。公式情報では、DisableOptionalUpdatesを使うことで、ユーザーによる手動更新と更新通知を防ぐ設定が示されています。(Microsoft Learn)
| 目的 | レジストリパス | 値名 | 型 | 設定値 |
|---|---|---|---|---|
| 手動更新を防ぐ | HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Power Automate Desktop | DisableOptionalUpdates | DWORD | 1 |
| 自動起動の手動設定を防ぐ | HKEY_CURRENT_USER\SOFTWARE\Microsoft\Power Automate Desktop | DisableAutoStartConfiguration | DWORD | 1 |
注意したいのは、DisableAutoStartConfigurationはMSI版に適用される設定である点です。Microsoft Store版や別配布形態を混在させている場合は、インストール方式も合わせて確認してください。
サインインできるアカウントを制限する
個人Microsoftアカウントや、ライセンス条件を満たさない職場・学校アカウントでPower Automate for desktopを利用できる状態は、企業ガバナンス上のリスクになります。公式情報では、Microsoftアカウント、ライセンスなしの組織アカウント、組織アカウント全般を制限するキーが整理されています。(Microsoft Learn)
| 制御内容 | 値名 | 実務での使いどころ |
|---|---|---|
| Microsoftアカウントでのサインインを防ぐ | RestrictMSAAccountsSignIns | 個人アカウント利用を禁止したい場合 |
| attended RPAライセンスなしの職場・学校アカウントを防ぐ | RestrictNoLicenseOrgIDAccountsSignIns | ライセンス管理を徹底したい場合 |
| 職場・学校アカウントまたは組織プレミアムアカウントでのサインインを防ぐ | RestrictOrgIDAccountsSignIns | 特定端末でPower Automate for desktop利用自体を強く制限したい場合 |
ここで重要なのは、すべてのアカウント種別を制限すると、当然ながらPower Automate for desktopへサインインできなくなる点です。端末の利用禁止が目的なら有効な選択肢ですが、通常の社内利用を残したい場合は、個人アカウント禁止やライセンスなしアカウント禁止から検討するのが現実的です。
テナント・組織・リージョン接続を制御する
複数テナントを扱う企業や、開発・検証・本番環境を分けている企業では、ユーザーが意図しない組織へ接続するリスクがあります。EnableOrganizationPickerでは、Power Automate for desktopコンソールの組織切り替えや、サインイン時に接続を試みる組織リストを制御できます。Cloudでは、接続先リージョンの既定値を設定できます。(Microsoft Learn)
| 目的 | 値名 | 型 | 補足 |
|---|---|---|---|
| 組織選択を許可または無効化する | EnableOrganizationPicker | String | isEnabled、organizationList、selectOrganizationFromListIsEnabledを組み合わせる |
| 接続先リージョンを指定する | Cloud | DWORD | 2はグローバルパブリック、3以降は米国政府系や中国リージョン向け |
日本国内の一般的な企業利用では、Cloudを不用意に変更する機会は多くありません。ただし、グローバル企業、政府系クラウド、21Vianet運営の中国リージョンを扱う場合は、端末単位で接続先の設計が必要です。
証明書失効チェックとプロキシ設定を見直す
社内プロキシやSSLインスペクションを使っている環境では、Power Automate for desktopのクラウド接続がネットワーク設定に強く影響されます。証明書失効チェックはCertificateRevocationCheckで、チェックなし、Basic、Comprehensiveを選べます。既定ではBasic checkとされています。(Microsoft Learn)
| 値 | 動作 | 向いているケース |
|---|---|---|
0 | 失効情報を確認しない | 原則として本番環境では慎重に扱う |
1 | Basic check。失効済み証明書のみ拒否 | 社内プロキシで失効情報が取得しづらい環境 |
2 | Comprehensive check。失効済み、または失効情報なしの証明書を拒否 | 厳格な証明書検証が必要な環境 |
プロキシ関連ではProxyServer、DisableWindowsProxy、UseDefaultProxyCredentials、ProxyNetworkCredentialsKey、ProxyBypassListなどのキーが用意されています。一方で、Power Automate for desktop 2.45以降は、プロキシ設定ファイルでもすべてのプロキシ設定を構成できるとされています。既存のレジストリ運用を続けるか、設定ファイル中心に移行するかは、端末管理の方針に合わせて判断してください。(Microsoft Learn)
実務では、まず検証端末で次の3点を確認します。
- Power Automate for desktopのサインインが成功するか
- クラウドフロー連携やDataverse接続に失敗しないか
- 証明書失効チェックを厳格化しても社内プロキシ配下で通信できるか
証明書チェックを強めると安全性は高まりますが、プロキシ側の証明書運用によっては接続障害の原因になります。セキュリティ要件だけでなく、実際のネットワーク経路で検証することが重要です。
ログ、診断、スクリーンショットの扱いは慎重に決める
Power Automate for desktopのログ設定は、障害解析と情報保護のバランスが最も難しい領域です。エラー時のスクリーンショット、アクションログ、Designer実行ログ、ローカルの実行詳細、動画ログなどは、トラブルシュートには有用ですが、画面や入力値に機密情報が含まれる可能性があります。(Microsoft Learn)
| 目的 | 値名 | 設定の考え方 |
|---|---|---|
| 任意の診断使用状況データ収集を制御 | AllowOptionalDataCollection | プライバシーポリシーに合わせて0または1を決める |
| エラー時のスクリーンショット取得を止める | DisableScreenshotCaptureOnError | 個人情報や顧客情報が画面に出る業務では優先度が高い |
| 実行後の詳細アクションログのアップロードを止める | DisableFlowExecutionActionLogging | クラウド側に詳細ログを残したくない場合に検討 |
| Designer実行ログをローカルに残す | EnableDesignerExecutionLogs | 開発・検証端末のデバッグ向け |
RunDefinition.jsonのコピーを残す | KeepRunDefinitionFilesCopy | 再現調査を重視する場合に限定して使う |
Actions.logのクリーンアップを止める | DisableRunFilesCleanup | ディスク容量と保存期間の管理が必要 |
| 動画ログを制御する | VideoLoggerModeOverrideなど | 2.66以降の端末で、保存先と保存時間を明確にする |
特にEnableDesignerExecutionLogsは、Designerからの実行ログをローカルファイルシステムに保存するため、古いログを自動的に削除しない点に注意が必要です。検証端末では便利ですが、本番利用者の端末に広く有効化すると、ディスク使用量や情報管理の問題が起きやすくなります。(Microsoft Learn)
動画ログについては、2.66以降でVideoLoggerModeOverride、VideoLoggerDisableSubtitles、VideoLogDurationInSeconds、VideoLogOutputPathが示されています。VideoLoggerDisableSubtitlesは値名だけを見ると分かりにくいですが、公式情報では0が字幕無効、1が字幕有効とされています。設定名から推測せず、値の意味を確認してから展開してください。(Microsoft Learn)
外部実行、共有フロー、クラウドコネクタはセキュリティ観点で確認する
Power Automate for desktopでは、URLやデスクトップショートカットからフローを起動する運用ができます。便利な一方、利用者が意図せず実行したり、管理外の起動経路が増えたりするリスクがあります。
公式情報では、ユーザー単位の確認ダイアログ設定としてEnableAskBeforeRunningAFlowExternally、端末単位で外部実行を強制制御する設定としてConfigureExternalRunsが示されています。ConfigureExternalRunsを1にすると確認ダイアログを常に表示し、2にするとURLやショートカットからのフロー起動を禁止します。(Microsoft Learn)
| シナリオ | 推奨される考え方 |
|---|---|
| 業務端末で利用者が手動確認してから実行する | 確認ダイアログを強制する |
| キオスク端末や共有端末で誤実行を避けたい | 外部実行の禁止を検討する |
| 開発端末でショートカット起動を検証したい | 検証範囲を限定し、本番端末とは設定を分ける |
共有フローについても注意が必要です。DisableAskBeforeRunningASharedFlowを1にすると、信頼していない作成者の共有フローを実行する際の確認ダイアログを表示しない設定になります。利便性は上がりますが、セキュリティチェックを弱める方向の設定です。組織として明確な理由がない限り、本番端末に広く適用する設定ではありません。(Microsoft Learn)
また、クラウドコネクタを含むデスクトップフローの実行を無効化するDisableCloudConnectors、UNCパスを含むアクション入力を無効化するDisableUNCPaths、DLPルールで管理されない例を非表示にするDisableExamplesも確認対象です。UNCパス無効化はPower Automate for desktop 2.55以降に適用され、UNCパスを含むアクションは実行時エラーになります。既存フローでファイルサーバーの\\server\share形式を使っている場合は、事前に影響調査が必要です。(Microsoft Learn)
Copilot関連のガバナンスは管理センター設定も含めて見る
Power Automate for desktopのガバナンスはレジストリだけではありません。公式情報では、Copilotの生成回答機能を防ぐには、Power Platform管理センターで「Copilot help assistance in Power Automate via Bing」設定をオフにすることが示されています。Copilot関連のフィードバック送信は、disableSurveyFeedbackテナント設定で制御できます。また、すべてのCopilot機能を無効化したい場合はMicrosoft Customer Supportへの連絡が案内されています。(Microsoft Learn)
ここでの判断基準は、単に「AIを使うか使わないか」ではありません。社内規程、扱うデータの種類、開発者の利用範囲、監査要件に合わせて決める必要があります。
| 方針 | 向いているケース | 確認ポイント |
|---|---|---|
| Copilotを限定的に許可 | 開発効率を重視し、扱うデータを制限できる | 利用部門、対象環境、入力してよい情報を明文化する |
| 生成回答を無効化 | AI利用に関する社内ルールが未整備 | 管理センター設定とテナント設定を確認する |
| 全Copilot機能を無効化 | 規制業種や監査要件が厳しい | Microsoftサポート対応を含めて計画する |
Power Platform管理者は、Power Automate for desktopの端末設定と、Power Platform管理センター側のAI設定を別々に管理しないようにしてください。現場から見るとどちらも「Power Automateの設定」ですが、実際には設定場所が分かれます。
UI Accessは必要な端末だけに限定する
Power Automate for desktop 2.68以降では、昇格された権限を必要とするアプリケーションを自動化する端末向けに、UI Accessを有効化するレジストリ設定が示されています。設定値はUseUIAccessAutomationServerで、1が有効、0が無効です。(Microsoft Learn)
| 目的 | レジストリパス | 値名 | 型 |
|---|---|---|---|
| UI Accessを有効化する | HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Power Automate Desktop\Global | UseUIAccessAutomationServer | DWORD |
UI Accessは、すべての端末で一律に有効化する設定ではありません。管理者権限で動く業務アプリをRPA対象にしている端末、または明確な検証目的がある端末に絞って適用するのが安全です。
開発者側では、「UI Accessを有効にすれば何でも自動化できる」と考えないことが大切です。対象アプリの権限、起動方法、ユーザー権限、セキュリティソフトの制御などによって、実際の動作は変わります。端末単位で再現テストを行い、本番展開前に失敗時の代替手順も用意してください。
管理者向け：レジストリ展開前のチェックリスト
Power Automate for desktopのガバナンス設定は、セキュリティ強化と業務影響が表裏一体です。展開前に、以下を最低限確認してください。
| チェック項目 | 確認内容 |
|---|---|
| バージョン | 2.24、2.41、2.45、2.55、2.66、2.68など、設定ごとのバージョン条件を満たすか |
| インストール方式 | MSI版限定の設定が対象端末に効くか |
| テナント | 登録許可テナント、組織切り替え、外部テナント登録の方針が決まっているか |
| ネットワーク | プロキシ、証明書失効チェック、認証方式を検証したか |
| ログ | どのログを残し、どのログを抑止し、保存期間をどう管理するか |
| セキュリティ | 外部実行、共有フロー、UNCパス、クラウドコネクタの許可範囲を決めたか |
| Copilot | 管理センター設定、テナント設定、社内AI利用ルールが一致しているか |
| ロールバック | 設定変更後に業務影響が出た場合、元に戻す手順を用意しているか |
レジストリ設定をPowerShellで展開する場合は、設定対象を明確にしてから実行します。例えば、手動更新を禁止する設定は次のように記述できます。
$path = "HKLM:\SOFTWARE\Microsoft\Power Automate Desktop"
if (-not (Test-Path $path)) {
New-Item -Path $path -Force | Out-Null
}
New-ItemProperty `
-Path $path `
-Name "DisableOptionalUpdates" `
-PropertyType DWord `
-Value 1 `
-Force | Out-Nullこの例はあくまで1つの設定例です。実際の展開では、変更前の値を記録し、検証グループで動作確認してから本番端末へ広げてください。
開発者が確認すべきポイント
開発者は「フローが動くか」だけでなく、「管理者が設定した制約の中で安定して動くか」を確認する必要があります。
特に、以下のようなフローは事前テストが重要です。
| フローの種類 | 確認すべき設定 |
|---|---|
| ファイルサーバー上のファイルを扱う | DisableUNCPathsが有効化されていないか |
| URLやショートカットから起動する | ConfigureExternalRunsで禁止されていないか |
| クラウドコネクタを含む | DisableCloudConnectorsの影響を受けないか |
| 社内プロキシ配下で通信する | ProxyServer、UseDefaultProxyCredentials、証明書失効チェックの影響を確認 |
| 障害解析にログが必要 | DisableFlowExecutionActionLoggingやローカルログ設定を確認 |
| 管理者権限アプリを操作する | UI Access設定と端末権限を確認 |
開発段階では動いていたのに本番端末で失敗する場合、原因はフローのロジックではなく、端末側のガバナンス設定にあることがあります。フロー設計書や運用手順書には、必要なレジストリ設定、接続先テナント、プロキシ条件、ログ取得方針も記載しておくと、障害対応が速くなります。
移行・展開時に起きやすい失敗
Power Automate for desktopのガバナンス設定では、次のような失敗が起きやすくなります。
| 失敗例 | 原因 | 対策 |
|---|---|---|
| 一部端末だけ設定が効かない | HKLMとHKCUを取り違えている | 端末単位かユーザー単位かを整理する |
| プロキシ経由でサインインできない | 証明書失効チェックやプロキシ認証方式が合わない | ネットワーク担当と検証端末で確認する |
| 既存フローが突然エラーになる | UNCパスやクラウドコネクタが制限された | 既存フローの利用アクションを棚卸しする |
| 障害解析に必要なログが残らない | ログ抑止設定を強くしすぎた | 本番、開発、検証でログ方針を分ける |
| ユーザーが想定外のテナントへ登録する | 登録テナント制御をしていない | AllowedRegistrationTenantsなどの設定を検討する |
| Copilot利用ルールと実設定がずれる | 管理センターと端末設定を別々に管理している | AI利用ポリシーとPower Platform設定を同時に見直す |
特に注意すべきなのは、セキュリティを強化する設定ほど、現場の自動化に影響しやすいことです。たとえばUNCパスを禁止すればファイルサーバー利用のリスクは下げられますが、共有フォルダーを前提にした既存フローは実行時エラーになります。変更前に「どのフローが影響を受けるか」を確認してください。
まず取るべき次のアクション
Power Automate for desktopを社内で使っている場合、最初にやるべきことは、すべてのキーを設定することではありません。まず、現在の運用でリスクが高い領域を洗い出すことです。
優先順位は次の順で考えると進めやすくなります。
- 個人アカウントや想定外テナントでサインインできないか確認する
- 社内プロキシ、証明書、リージョン接続で通信要件を満たしているか確認する
- エラー時スクリーンショット、アクションログ、動画ログの扱いを決める
- URL・ショートカット実行、共有フロー、UNCパス、クラウドコネクタの許可範囲を決める
- Copilotやフィードバック送信の方針をPower Platform管理センター側の設定と合わせる
- 検証端末で動作確認し、段階的に本番端末へ展開する
Power Automate for desktopのガバナンスは、Power Platform管理者だけで完結するものではありません。端末管理、ネットワーク、セキュリティ、RPA開発の各担当者が同じ設定一覧を見ながら、許可する機能と禁止する機能を明文化することが重要です。今回の公式情報を機に、レジストリ設定を単なる技術メモではなく、社内RPA運用ルールの一部として見直してください。
コメント