2025 年 6 月以降、環境メンバーではないユーザーと共有されたフローには、そのユーザーはアクセスできなくなります。 Power Automate へのこの重要な変更により、ユーザーは、その環境内のフローにアクセスするには、その環境のメンバーである必要があります。 この変更により、環境の境界が適用されることでセキュリティが強化されます。 ただし、異なる環境間でフローを共有している組織には影響します (たとえば、フロー所有者が環境外のユーザーを共同所有者または実行専用ユーザーとして追加するなど)。
新しいポリシーに準拠するには、Power Platform 管理者は、環境外のユーザーと共有されているフローを特定し、それらのフローの共有設定を調整する必要があります。 この記事では、そのための構造化されたアプローチについて説明します。
この記事は、次のことに役立ちます。
- 外部ユーザー (フローの環境に存在しないユーザー) と共有されているフローを特定します。
- 継続性を確保するため、これらのフローの共有とアクセスを調整します (環境に適切なユーザーを追加し、実行のみのアクセスを使用するなあど)。
この記事では、2025 年 6 月の施行に先立ち、Power Platform 管理者が共有に関する問題を事前に解決する方法をご案内しています。 また、今後フロー共有を安全に管理するためのガバナンスを確立するのにも役立ちます。 この記事では、重要なポイントを説明するために、実際の例と手順を段階的に紹介しています。
共有フローを管理するためのベストプラクティスについてはクラウドフローの共有を参照してください。
環境外のユーザーと共有されているフローを特定する
まず、各環境におけるすべてのクラウド フローとその共有ユーザーのインベントリを作成し、その環境のメンバーではない外部ユーザーと共有されているフローを特定します。 Power Automate フローは、通常の (非ソリューションの) フロー、ソリューション対応フロー (Dataverse ソリューションの一部として) で作成できます。 どちらも環境内に存在し、どちらも確認が必要です。 次のセクションでは、外部共有フローを識別する方法について説明します。
Power Platform 管理センター — GUI メソッド
環境管理者は、Power Platform 管理センターを使用して、視覚的な監査を行うことができます。
Power Platform 管理センターで、管理>環境 > (ご利用の環境) >リソース>フローを選択します。
A は、環境内のすべてのフローを、所有者 列とともに一覧表示します。
フローごとに、所有者を検査します。 フローに複数の所有者 (作成者と共同所有者) がいる場合、フローは共有されます。 これらの所有者を環境の既知のメンバーと比較します。 たとえば、その環境のセキュリティ グループまたはユーザー リストを比較します。
所有者または共同所有者が想定される環境メンバーではないフローにフラグを立てます。 たとえば、部門 A の環境には部門 A のユーザーのみを含める必要があるが、部門 B の共同所有者がいる場合、そのフローは部外者と共有されます。 詳細を表示するには、所有者の名前を選択したり、環境のユーザー ディレクトリと相互参照したりする必要がある場合があります。
Power Platform 管理センター — GUI メソッドの利点
Power Platform 管理センターは、ユーザー フレンドリーなインターフェースを備えており、名前や所有者によるフィルタリングやフローの並べ替えが可能です。 環境内のどのチームとユーザーが属しているかがわかれば、明らかな不一致をすばやく見つけることができます。
Power Platform 管理センター — GUI メソッドの欠点
この方法は手動であり、多くのフローでは適切にスケーリングできません。 所有者を個別に確認する必要がありますが、大規模な環境では時間がかかることがあります。 ユーザー インターフェイスから直接環境のメンバーシップをクロスチェックするのは難しい場合があります。
PowerShell スクリプト - 自動化された方法
体系的で再現性のある監査を行うため、Power Automate ではフローとその所有者を一覧表示するための管理用 PowerShell cmdlet を提供しています。 このアプローチは、大規模な環境全体またはテナント全体の一括分析に有効です。 すべてのフローを出力し、外部共有を強調表示するようにプロセスをスクリプト化できます。
たとえば、このスクリプトでは、Get-AdminFlow を使用してすべてのフローを取得し、Get-AdminFlowOwnerRole を使用して各フローの所有者とその役割を一覧表示しています。 出力には、各フロー名と Owner: [User]、Role: [Owner/Co-owner] の項目が箇条書きで表示されます。 この出力をファイルにリダイレクトしたり、さらに処理したりできます。
次に、外部共有を決定します。各所有者のユーザー プリンシパル名 (UPN) を、環境のメンバーであるユーザーのセットと比較します。 外部 共有は、UPN が環境のユーザー リストまたはセキュリティ グループに含まれていない所有者によって示されます。 実際には、次のことができます。
- 前のスクリプトのフロー所有者リストと環境ユーザーリストをエクスポートし、Excel またはスクリプトを使用して相違点を見つけるか、
- PowerShell スクリプトを強化して、
Get-AdminEnvironmentUserを通じて環境ユーザーと相互チェックを行うようにします。
PowerShellスクリプトの長所 - 自動化された方法
この方法は自動化され、包括的です。 数百または数千のフローをすばやく列挙でき、レポート用にスクリプト化できます。 毎月などのスケジュールで実行して、新しい外部共有を見つけることができます。
PowerShellスクリプトの短所 - 自動化された方法
PowerShell と管理者権限に関する知識が必要です。 また、生の出力には UPN とオブジェクト ID が表示されます。 どれが環境外にあり、分析が必要なのかを解釈する必要があります。 ただし、環境のユーザー ドメインがわかっている場合や、環境メンバーの一覧がある場合は、これは簡単です。
センター オブ エクセレンス (CoE) ツールキット - ダッシュボード方式
組織が Power Platform センター オブ エクセレンス スターターキットを使用している場合、共有指標を含む Power BI ダッシュボードとレポートが提供されます。 CoE のフローのインベントリでは、ゲスト所有者または環境の通常のセキュリティ グループ外の所有者がいるフローを強調表示できます。 たとえば、CoE ダッシュボードには、複数の所有者がいるフローやゲストユーザーと共有されているフローのレポートが表示されます。 これらの分析情報を活用して、共有が異常であるフローを見つけることができます。
センター オブ エクセレンス (CoE) ツールキットの長所 - ダッシュボード方式
一元化された視覚的なレポート (既に環境データを集約している可能性がある)。 CoE が配置されている場合、追加のスクリプトは必要ありません。 非準拠のパターンに自動的にフラグを立てることができます。
センター オブ エクセレンス (CoE) ツールキット - ダッシュボード方式の短所
CoE スタート キットを展開し、最新の状態に保つ必要があります。 データはリアルタイムではない可能性があります (通常はスケジュールに従って更新されます)。 また、外部ドメイン ユーザーの識別など、カスタム フィルターを設定するには、CoE コンポーネントの調整が必要になる場合があります。
識別方法の比較
| メソッド | ツール/アプローチ | 長所 | デメリット |
|---|---|---|---|
| 管理センター (GUI) | Power Platform 管理センターの Web インターフェイスは、フローと所有者を視覚的に確認します。 | ユーザーフレンドリなインターフェイスを備えています。 少数のフローを即座に把握できます。 | 手動検証、大規模な環境ではスケーラブルではありません。 所有者と環境のメンバーシップの相互参照は組み込まれていません。 |
| PowerShell スクリプト | 管理者 PowerShell コマンドレット (Get-AdminFlow, Get-AdminFlowOwnerRole)。 |
フローと所有者の自動一括出力。 スケジュールを設定し、結果をCSVまたはその他の形式にエクスポートできます。 環境のユーザー リストがわかっている場合は、高い精度。 | PowerShell知識が必要です。 どの所有者が外部であるかを個別に識別する必要があります。 スクリプトまたは後処理が必要です。 |
| CoE ツールキット (ダッシュボード) | Power BI ダッシュボードと CoE フロー。 | CoE がインストールされている場合は既に使用可能です。 一元化されたレポートで、外部所有者やゲスト所有者など、通常とは異なる共有を強調表示できます。 | CoE の展開とメンテナンスが必要です。 データ更新の遅延があります (リアルタイムではありません)。 特定の外部ユーザーを特定するためにカスタマイズが必要な場合があります。 |
前の表の方法の 1 つまたは組み合わせを使用して、外部共有ユーザーを持つフローの一覧をコンパイルします。 これらは、ポリシー変更の前に注意が必要な影響を受けるフローです。 多くの組織では、これは管理可能なフローのサブセットである可能性があります (たとえば、少数の部門間フローや、パートナーのゲスト アカウントと共有されるフローなど)。 他のテナント、特にオープン共有プラクティスを採用しているテナントでは、処理するフローの数がかなり多い可能性があるため、早期に特定する方が良いでしょう。
影響を受けるフローの共有とアクセスを調整する
環境外のユーザーと共有されているフローを特定したら、次の手順は、各フローの共有構成を修正することです。 目標は、フローへのアクセスが必要なすべてのユーザーが環境に適切に追加されるようにすること (または、フローのアクセス権が変更されるようにすること) です。 これは、新しい強制が開始されたときに、機能が失われないようにするためです。 以下のセクションでは、調整の方法について説明します。
各外部共有の必要性の評価
フラグが立てられたフローごとに、フローの所有者または関連するビジネス チームと、なぜ外部で共有されたのかについて話し合います。 このコンテキストは、修正を決定するために重要です。 次の一覧では、一般的なシナリオとアクションについて説明します。
- シナリオ 1: ユーザーが、フローの実行や、出力を表示するためだけに共同所有者として追加された: 多くの場合、所有者が外部ユーザーを所有者として追加した場合、そのユーザーがフローをトリガーまたは使用するだけで済みます (フローの編集は不要)。 たとえば、所有者はヘルプデスク エージェントをフローの共同所有者として追加して、手動でトリガーできます。 このような場合、ユーザーは完全な所有者権限を必要としない可能性があります。
- アクション: 所有者 リストからそれらを削除し、代わりに、環境へのアクセス権があることを確認した上で、実行のみ可能なユーザーとしてフローを共有します (該当する場合)。 これにより、所有者にならずにフローを実行するために必要な機能が提供されます。 詳細については、この記事の 必要なユーザーを環境に追加する セクションを参照してください。
- シナリオ 2: ユーザーがフローの構築または保守において真のコラボレーションを行う: たとえば、2 つの部門が共同でフローを開発した場合、部門 B のユーザーは部門 A の環境で共同所有者に設定されたとします。
- アクション: そのユーザーを、適切な役割でオーナーとして環境に正しく登録します。複数の組織ユニットが共同所有者となる場合は、フローを中立的な環境に移すことを検討してください。 短期的には、環境の許可されたユーザー リストにユーザーを追加し、適切なロール (編集権限が必要な場合は環境作成者) を付与すると、アクセスの問題が解決されます。
- シナリオ 3: 共有が不要となった: ユーザーが一時的に追加されたり、プロジェクトから離れたりする場合があります。
- アクション: フローの共有から外部ユーザーを削除します。 これは、該当する場合の最も簡単な修正です。 環境外のユーザーがフローを必要としていない場合は、共有を解除します。 その後、フローは準拠し、内部所有者のみが残ります。
- シナリオ 4: テナント間またはゲスト ユーザー共有: たとえば、フローがゲスト (外部テナント) アカウントと共有されたとします。 これは強制後にブロックされます。
- アクション: そのゲストがどうしてもアクセスが必要かどうかを判断してください。 「はい」の場合、そのゲストをテナントの Azure AD ゲストとして正式に登録し、環境のセキュリティグループに追加するという方法があります。 これにより、環境メンバーになります。 しかし、あまりないケースと言えるでしょう。 あるいは、ゲストに代わって行動できる社内のユーザーに所有権を移すよう手配するか、直接共有ではなく、安全な HTTP トリガーを介してフローを公開するなどの別の仕組みを利用します。 環境メンバーとして追加された場合でも、テナント間の問題が発生する可能性があるため、直接ゲスト共有を削除することをお勧めします。
環境に必要なユーザーを追加します
フローに引き続きアクセスする必要があるユーザーごとに、そのユーザーが今後環境のメンバーであることを確認してください。 これは通常、次のことを意味します。
環境でセキュリティ グループを使用している場合: その Azure AD セキュリティ グループにユーザーのアカウントを追加します。 これにより、特に設定されていない限り、環境内のデフォルトの Basic ユーザー ロール が付与されます。 基本ユーザー ロール は、通常、フローの実行のみが必要で、作成や編集は必要ないユーザーには十分です。 追加後、Power Platform 管理センターの環境のユーザー リストにユーザーが表示されることを確認します。
すべてのユーザーに公開されているテナントの既定の環境の場合: ほとんどのライセンス ユーザーは既にその環境にいます。 ユーザーには、Power Automate ライセンスが必要です。 この強制は、主に、メンバーシップが制限されている既定以外の環境に影響します。
環境作成者と基本ユーザーの比較: その環境でフローを構築および編集する必要が本当にある場合を除いて環境作成者を付与しないでください。 この修正では、共有フローの実行を許可する「基本ユーザー」またはカスタム最小ロールのみを付与することを推奨しています。 実行専用アクセスの場合は、Basic ユーザーで十分です。ユーザーは作成者である必要はありません。 作成者ロールの制限はガバナンスのベスト プラクティスであり、次のセクションで詳しく説明します。
フローの共有設定を調整する
ユーザーが環境メンバーになったので、フローを共有する方法を調整します。
ユーザーがフローの実行のみを行う場合: 実行のみ共有を使用します。 Power Automate で、フローの共有設定を開きます。 所有者リストからユーザーを削除し、実行専用ユーザー セクションに名前を追加します。 ボタン フローやインスタント フローなど、手動でトリガーされるフロー、または共有可能なリンクでトリガーされるフローの場合、これにより、所有者でなくてもフローをトリガーできます。 フローの内部を編集または表示することはできず、実行することしかできません。 その結果、ユーザーは所有者リストの外部にとどまるため、環境の競合は発生しませんが、意図したとおりにフローの機能を使用できます。
例: マーケティングの Bob は、営業のリードプロセッサ フローの共同所有者であり、定期的に開始していました。 Bob を共同所有者から削除し、Bob を実行専用ユーザーとして追加します。 Bob は 営業 環境にも Basic ユーザーとして追加されます。 これで、ボブはフローのボタンを選択したり、フローを実行するためのリンクを受け取ったりできますが、外部の所有者ではなく、その環境の承認された Basic ユーザーです。
ユーザーが完全な所有者アクセス許可 (共同編集) を必要とする場合: これらを環境に追加した後、フローに所有者として引き続き表示されていることを確認します。 技術的には、アクセス許可を更新するために、それらを削除して再度追加することができます。 しかし、いったん環境に入ってしまえば、そのシェアは正当なものです。 また、異なる領域の 2 人の所有者が長期的に管理する場合は、フローをソリューションに移行することもご検討ください。 ソリューション フローは、必要に応じて専用環境に簡単に転送できます。 いずれの場合も、フローの詳細で、所有者に表示され、その役割が編集可能 (所有者) になっていることを再確認してください。
冗長な共有や承認されていない共有を削除する: このプロセス中に、クリーンアップの機会を利用してください。 万が一のために追加されたが、フローを使用しない場合は、そのユーザーを削除します。 最小権限の原則は、監視の負担を軽減する際に役立ちます。 各フローの所有者リストは、設計と編集アクセス権が実際に必要なユーザーのみに制限してください。
影響を受けるユーザーに変更を伝えます
他のユーザーのアクセス権を削除する場合や、フローを呼び出す方法を変更する場合は、その旨を通知します。 ユーザーの観点から見ると、実行専用アクセスによるフローの実行は少し異なる場合があります。 共有リンクを取得したり、マイ フローではなくチーム フローでフローを表示したりする場合があります。 混乱を防ぐため、「新しい Power Automate ポリシーに準拠するため、Flow X の共有方法を更新しました。メソッド Y で引き続き実行できますが、直接の所有権には表示されなくなります」と説明してください。
調整後の状態を確認する
変更を行った後、PowerShell または Power Platform 管理センターを使用して、外部所有者が残っているフローがないことを再確認してください。 たとえば、識別スクリプトを再度実行し、それらのフローにフラグが立てられなくなったことを確認します。 フラグが立てられた各インスタンスは、削除するか、適切な環境メンバーシップによって解決します。
これらの調整を実行することで、Microsoft がスイッチを切り替えたときに、これらのフローが目的のユーザーに対して引き続き実行されるようになります。
you do not have access to this flow というエラーは表示されず、ユーザーは適切な権限を持つ環境メンバーとなったため、認証されたままになります。 基本的には、共有のプラクティスをプラットフォームのガバナンス モデルに合わせることです。