【Power Platform】アプリやフロー、Copilotの共有の条件・制約

こんにちは。DXソリューション営業本部の吾妻です。

Power Platformにおいて、自分が実装したアプリやフローを周りのユーザーにも使ってもらいたいときのために用意されている機能として、「共有」があります。今回は、Power Appsのキャンバスアプリとモデル駆動型アプリ、Power Automateのクラウドフローとデスクトップフロー、Copilot Studioのエージェントのそれぞれについて、共有できるもの、共有できる相手、制約事項などを各種条件で実際に検証して解説していきたいと思います。

以前にご紹介した「Dataverseレコードの共有」とは異なり、「ソリューションコンポーネントの共有」に関する内容となります。Dataverseレコードの共有については、以下の記事をご覧ください。

モデル駆動型アプリ概説　⑨レコードの共有と割り当て | QES ブログ
株式会社QUICK E-Solutionsから、皆さまへお役立ち情報を発信するブログです。ぜひご覧ください。
 

検証の前提条件

次の画像のように、動的配布リスト以外の各種グループはMicrosoft 365管理センターから、動的配布リストはExchange管理センターから、それぞれ作成したうえで、本記事でご紹介する検証を行いました。検証内容は、2025年7月現在の情報で、環境によって差異が生じる場合があります。

グループの機能比較

今回検証に利用するグループの種類ごとの特徴をまとめておきます。

①Microsoft 365グループ

Teams、SharePoint、Planner、Outlook などのMicrosoft 365製品で使用する、コラボレーションに特化したグループです。Teamsチームの裏側に自動的に作成されるのもMicrosoft 365グループで、Microsoft Entra管理センター以外にも、Microsoft 365 管理センター、Teams、SharePointなどのアプリケーションの中からでも作成できます（が、Entra管理センター以外から作成すると、securityEnabled属性がFalseに初期設定され、後ほどご紹介する共有手順において、挙動が異なることがあります）。

②配布グループ

メールの宛先に指定して送信することによって、メンバーにメールを一斉送信するためのグループで、ファイル共有や予定表の機能はありません。公式ドキュメントやアプリケーションのUIでは、配布グループと記載されている場合と配布リストと記載されている場合がありますが、どちらも同じものを指します。

③動的配布グループ

部門、場所といった条件に基づいて、メンバーが自動的に決定される配布グループです。

④セキュリティグループ

アクセス制御用で、メール送信機能がないグループです。

⑤メールが有効なセキュリティグループ

メール送信機能を追加したセキュリティグループです。

⑥共有メールボックス

複数人で共有してメールを送受信できるようにするための、実体のあるメールボックスで、予定表も共有できます。

共有できるもの、共有できる相手

Power Platformの主要な製品に関して、他者に共有できるコンポーネントと、それらを誰宛てに共有できるかをまとめた表を示します。

ここからは、それぞれの製品について、共有手順や注意事項を解説していきます。

【Power Apps】キャンバスアプリ

キャンバスアプリを他ユーザーに共有するときには、メーカーポータルでアプリを選択して、「共有」メニューを実行します。

このとき、共有相手に対して招待メールが自動的に送信されます。招待メールにはアプリへのリンクが記載されているので、そこから直接アプリを起動できます。「クラシック」なUIの頃は、共有相手にメールを自動的に送信するか否かを指定するチェックボックスがありましたが、現行のUIでは、設定を切り替えることができず、常にメールが送信されるようになっています。なお、アプリの共有を受けたユーザーがこの招待メールを見逃していたとしても、メーカーポータルのアプリ一覧から選択することによって、アプリを再生することができます。

また、共有相手にキャンバスアプリの中身（アプリスタジオ）を見せたい場合は、単に共有するだけでなく、共同所有者に設定する必要があります。さらに、アプリのデータソースとしてDataverseを利用している場合には、併せてセキュリティロールを選択する必要があります。適切なセキュリティロールをユーザーに割り当て忘れると、アプリは起動できてもデータの表示や保存ができず、思った通りに動作しません。

【Power Apps】モデル駆動型アプリ

モデル駆動型アプリを共有するときも、キャンバスアプリと同様に、メーカーポータルから「共有」メニューを実行します。モデル駆動型アプリの共有は、キャンバスアプリとは考え方が異なり、「アプリ自体を共有する」というよりは、アプリで参照するテーブルへのアクセス許可を付与する（＝セキュリティロールを割り当てる）ことによって共有します。つまり、アクセス権がセキュリティロールに紐づいているため、管理者は複数のモデル駆動型アプリやその他のソリューションコンポーネントの権限を一元的に管理できます。これは、エンタープライズ規模のソリューションを運用する上で非常に効率的です。

また、アプリを共有した際の通知動作も異なり、メールによる通知は行われず、アプリを共有するユーザーがWebリンクを取得して、任意の手段で共有相手に知らせる必要があります。

【Power Automate】クラウドフロー

クラウドフローを共有する場合には、Power Automateポータルからクラウドフローを選択して、共同所有者を追加します。

共同所有者に追加されたユーザーは、クラウドフローに接続されたサービスを使うことはできますが、他の所有者が作成した接続の資格情報（認証情報）を編集することはできません。そのため、所有者の退職などに伴って元の所有者ではなく別のユーザーとして認証をやり直したい場合には、クラウドフローを編集して接続を切り替える必要があります。これにより、意図せず他人の権限で連携先サービスが利用されてしまうようなセキュリティリスクを抑えることができます。

一方で、担当者の退職や異動が発生した際には、接続情報の管理が煩雑になりがちです。あるユーザーの個人アカウントで作成された接続に依存しているフローは、そのユーザーがアクセスできなくなるとエラーとなります。この場合、フローを編集モードで開き、接続を新しいユーザーのものに一つ一つ手動で切り替えて再認証する作業が必要となり、手間と時間がかかります。このため、業務において重要な役割を持つクラウドフローにおいては、個人のアカウントに紐づく接続情報の利用は避けるべきです。例えば、フローを作成（もしくは他の環境からのインポート）する時点で、特定の個人に依存しないサービスプリンシパルまたは、そのシステム専用のサービスアカウントとして利用する（ライセンスが付与された）ユーザーを用意しておき、フローの所有者を設定するとともに、認証もサービスアカウントで済ませておくような運用を強く推奨します。

【Power Automate Desktop】デスクトップフロー

Power Automate Premiumライセンスをもつユーザーであれば、Power Automateポータルから「共有」メニューを実行することで、他のユーザーにデスクトップフローを共有することができます。有償版ライセンスがない場合は、フローデザイナーを開いて、アクションをコピーして得られるテキストを共有するような原始的な方法をとることになります。表に記載している通り、デスクトップフローをグループに共有することはできませんが、Dataverseチームに対して共有することは可能なので、間接的にMicrosoft 365グループやセキュリティグループに共有することができます。

【Power Apps / Power Automate】カスタムコネクタ

カスタムコネクタは、組織内のユーザーやゲストユーザー、配布リスト以外のグループに対して共有することができます。カスタムコネクタのみを明示的に共有することもできますが、キャンバスアプリやクラウドフローを共有したときに自動的にカスタムコネクタも共有されるので、通常あまり意識する必要はありません。組織外のユーザーに対して共有するためには、マイクロソフトのレビュー・認定を受けて、標準コネクタとして公開されている必要があります。

【Copilot Studio】エージェント

他のユーザーがエージェントとチャットできるようにするためには、セキュリティグループ、または組織全体に閲覧者としての許可を付与します。また、他のユーザーが単にチャットするだけでなく、エージェントの中身を共同作業で編集できるようにするためには、編集者としての許可を付与します。

キャンバスアプリの共有と同様に、クラシックなUIとモダンなUIが用意されており、メール送信の有無を指定するためには、クラシックなUIに切り替える必要があります。

また、表中で△とした部分に関しては、公式ドキュメントを読む限り、「個々のユーザーと直接」共有することはできず、セキュリティグループに共有して、セキュリティグループのメンバーを追加・削除することで管理する仕組みとなっています。しかし、実際の製品UIでは、個々のユーザーに対する共有機能について公式ドキュメントと実際のUIの間に食い違いが見られ、個々のユーザーを選択して共有相手として登録できてしまうようで、どちらが正式な仕様なのかが曖昧になっています（今後正式にアナウンスされるかもしれません）。

さらに、クラシックなUIで「新しいユーザーに招待メールを送信する」を有効化して単一ユーザーに共有した場合、メールが届くときと届かないときがありました。公式ドキュメントの記載としては、メールが有効なセキュリティグループ宛てに共有した場合のみ、ユーザーは招待メールを受信できることになっていて、個々のユーザー宛てに共有した場合の仕様については明記されていません。個々のユーザー宛てに共有する機能がGAになるまで（なるのか不透明ですが）当面の間は、きちんとメールが有効なセキュリティグループを用意して共有相手に指定するか、クラシックなUIでメール送信をオフにして共有してから、別途URLをTeamsなどの手段で連携するような運用とするのが望ましいでしょう。

【Power BI】レポート・ダッシュボード・データセット

Power BIで作成したレポートやダッシュボード、データセットを組織内外のユーザーと共有するためには、用途に応じて複数の方法が提供されています。ここでは、代表的な7つの共有方法について、メリット・デメリットと使い分け方を解説します。

①pbixファイルの共有

最も簡単な共有方法は、Power BI Desktopのレポートファイル（拡張子が.pbixのファイル）そのものを、他のユーザーに直接渡すことです。Power BIの有償版ライセンスを持っていないユーザー同士でもレポートを共有できる一方で、Power BIサービスを介さないため、誰が最新版のファイルを持っているのかを管理するバージョン管理が難しく、レポートやデータに対してきめ細やかなアクセス制御を行うこともできません。この方法は、ごく少人数のチーム内で、一時的にレポートの内容を確認しあうような限定的な用途に適しています。

②OneDrive や SharePoint 経由の共有

pbixファイルをOneDriveやSharePointといったクラウドストレージに格納し、そのファイルへのリンクを他のユーザーに連携する方法です。この手法のメリットは、ファイルを更新するたびに都度相手に送付し直す手間がなくなることです。ただし、この方法でもバージョン管理は難しく、意図しない変更が加わってデグレを起こすリスクがあります。

③Power BI サービスでの共有

Power BI有償版ライセンスの真価を発揮する共有方法が、Power BIサービス上での共有機能です。この機能は、個別のレポートやダッシュボード単位で共有するもので、マイワークスペースまたはカスタムのワークスペースから設定します。

アクセス許可を設定する際には、大きく分けて2つの選択肢があります。1つ目は「直接アクセス」で、共有したいユーザーやグループを個別に指定し、それぞれにロール（役割）を割り当てる方法です。この直接アクセス方式に限り、ゲストユーザーとして登録されていない組織外のユーザーに対しても共有することが可能です。2つ目は「共有リンクの発行」で、これは直接アクセスを許可していないユーザーでもレポートにアクセスできる特別なリンクを生成する機能です。このリンクを使えば、より広範囲の相手に簡単に閲覧権限を付与できます。

④ワークスペースでの共有

レポート単体ではなく、関連するレポートやダッシュボード、データセット一式をまとめて管理する「ワークスペース」そのものを共有することもできます。特定のプロジェクトや部門のメンバーが共同で作業を行う場合にこの方法を選択すると良いでしょう。ワークスペースへのアクセス権限は、「管理者」「メンバー」「共同作成者」「ビューアー」という4種類のロール（役割）から選択します。これらのロールは、個々のユーザーだけでなく、セキュリティグループ、Microsoft 365グループ、配布リストといったグループ単位でも割り当てることができるため、大規模な組織でも効率的に権限管理を行えます。

Power BI アプリとして配布

Power BIアプリを作成して、組織内外のユーザーに配布することもできます。Power BIアプリは、複数のダッシュボードやスプレッドシート、セマンティックモデル、レポートなどの関連しているコンテンツをまとめてパッケージ化したものです。利用者は、元のワークスペースを意識することなく、ワークスペースとは異なるアクセス許可設定に基づいて、レポートを閲覧・操作できます。

Power BI Embedded（埋め込み）

Power BIで作成した視覚的なレポートやインタラクティブなダッシュボードを、既存のWebサイトやモバイルアプリに直接埋め込むための機能がPower BI Embeddedです。この機能を利用することで、自社のアプリケーションの利用者に、シームレスなデータ分析機能を提供できます。ユースケースは大きく分けて2つあり、一つは組織内のポータルサイトなどに埋め込んで組織内のユーザーに利用させるケース、もう一つは自社が提供する公開Webサイトなどに組み込み、組織外の（Power BIのライセンスを持たない）ユーザーに対して分析機能を提供するケースです。これにより、Power BIを単なる分析ツールとしてではなく、自社サービスの一部として活用できます。

データセットの再利用（データセット共有）

レポート作成の元となるデータセットをPower BIサービス上で公開し、組織内の他のユーザーがそのデータセットを再利用できるようにすることもできます。組織内の多数のユーザーが共通して利用するような、人事やカレンダーなどのマスタデータ、業務情報などのトランザクションデータは、個々のユーザーが管理するのではなく、信頼できる単一のデータソース（Single Source of Truth）で管理することによって、誰もが同じデータに基づいてレポートを作成できるようになります（本来SSOTは、Azureのサービスを用いてDWHを構築すべきです）。公開されたデータセットが更新されると、そのデータセットを読み込んでいるすべてのレポートに変更内容が自動的に反映されるため、データの一貫性を保つ上で有用です。

ただし、この機能を活用するには、データセットを共有する側と、共有される側の双方に、Power BIの有償版ライセンスが必要となります。データセットを共有する際には、共有相手がセマンティックモデル（データセットの定義）を編集できるか、さらには別の人に再共有できるかといった、詳細な権限設定を行うこともできます。

まとめ

本記事では、Power Platformに含まれる各製品について、共有できるもの、共有できる相手、制約事項などをご紹介しました。構築フェーズだけでなく、ガバナンス設計においても理解しておく必要がある項目なので、理解しておく必要があります。


QES技術ブログでは、参考事例やサンプルもご紹介していますので、以下のリンクからご覧ください。

QESでは Power Platform の開発支援、QAサポート、開発者教育、ガバナンス整備など、組織で Power Platform を活用するためのサポートを包括的にご提供しています。Power Platform 活用についてご興味がある／利用中だが課題を感じていらっしゃるお客様はまずはお気軽にお問い合わせください。

Power Platform（ローコード開発） ｜ QES
ローコード開発ツール「Microsoft Power Platform」で現場からアプリ開発・DXを推進！QESはマイクロソフト認定パートナー、「パートナー・オブ・ザ・イヤー」受賞パートナーとしてお客様の Power Platform 活用を包括的に支援しています。
 

---

このブログで参照されている、Microsoft、Windows、その他のマイクロソフト製品およびサービスは、米国およびその他の国におけるマイクロソフトの商標または登録商標です。