記事公開日
【Power Platform】Copilot Studio の「共有」は1つじゃない - 権限と裏で動くDataverseロールを最小権限で整理 -
この記事のポイント
Microsoft Copilot Studioの「エージェントを共有する」という操作は、ひとつではありません。
チャットだけを許可する共有と、一緒に作り込む共同編集（共同で作成するための共有）では、付与される権限も、裏で動くMicrosoft Dataverseのセキュリティロールも変わってきます。
本記事では、公式ドキュメントの記述に沿って、この違いと共有設計の勘所を整理します。
- 共有には2系統ある：
「チャットのための共有」と「共同で作成するための共有（共同編集）」は別物で、付与される権限が異なります。 - 共同編集はEnvironment Makerが前提：
共同編集者にはDataverseの「Environment Maker（環境作成者）」ロールが必要で、共有者がシステム管理者であれば共有時に自動で割り当てられる仕組みがあります。 - 分析の閲覧は二段構え：
Analytics Viewer（分析ビューアー）は分析ページの読み取り専用、会話トランスクリプト（会話の書き起こし）まで見るにはBot Transcript Viewerが別途必要です。
こんにちは！DXソリューション営業本部の大和矢です。
「このエージェント、〇〇さんにも共有しておいて」——そう言われたとき、あなたは何を共有しますか？
チャットできるようにするだけでしょうか。それとも、一緒に編集できるようにするのでしょうか。
実はMicrosoft Copilot Studioでは、この「共有」という言葉の中身が一段深くなっていて、選び方を間違えると意図しない権限まで渡してしまうことがあります。
やっかいなのは、画面上の「共有」操作の裏で、Microsoft Dataverse（Power Platformのデータ基盤）のセキュリティロールが動いている点です。
共同編集を許可した瞬間に環境側のロールが付与されたり、分析を見せたつもりが会話の中身までは見えなかったり——「見える／見えない」の境界が、UIだけ見ていると掴みづらいのですね。
この記事では、公式ドキュメントに書かれている範囲で、共有の種類とそれぞれが付与する権限、そして裏で動くDataverseロールの関係を整理します。
読み終えるころには、「誰に・何を・どこまで」共有すべきかを、最小権限（必要最小限の権限だけを渡す考え方）の視点で判断できるようになるはずです。
「共有」は1つじゃない：チャット用と共同編集用
結論から言うと、Copilot Studioの共有には大きく2つの系統があります。
ひとつは「チャットのための共有」、もうひとつは「共同で作成するための共有（共同編集）」です。
この2つは付与される権限が違うので、最初にここを押さえておくと後がぐっと楽になります。
はじめに2つの前提：
共有できる相手は、Copilot Studioを利用できるライセンスを持つユーザーに限られます。これは単体のCopilot Studioユーザーライセンスのほか、Microsoft 365 Copilotライセンスでも満たせます。いずれのライセンスもない相手には、共有しても使えません（「共有したのに使えない」の典型的な原因です）。
ライセンス体系（Copilotクレジットや購入プランの違い）の詳細は、別記事「Microsoft Copilot Studio のライセンス体系を紹介」で解説していますので、あわせてご覧ください。
また本記事は、Web版（Copilot Studioの作成画面）での共有を前提に整理しています。Teams版では共有の単位（セキュリティグループやチームへの追加）や反映までの時間が異なる場合があるため、Teamsで運用する際は別途ご確認ください。
チャットのための共有は、ユーザーに作成権限を与えずに、エージェントとチャットする権限だけを与えるものです。
共有先は、個々のユーザー、セキュリティグループ、あるいは組織内のすべての人から選べます。
一方の共同編集のための共有は、エージェントを「表示・編集・構成・共有・発行」できる権限を付与します。
ただし、削除はできません。
また、共同編集の共有は組織内の個々のユーザーに対してのみ可能で、これらのユーザーは組織に属している限り、異なるPower Platform環境にいても共有できる、と記載されています。
| 共有の種類 | 付与される主な権限 | 共有先 |
|---|---|---|
| チャットのための共有 | エージェントとチャットする権限（作成権限は付与しない） | 個々のユーザー／セキュリティグループ／組織内のすべての人 |
| 共同で作成するための共有（共同編集） | 表示・編集・構成・共有・発行（削除は不可） | 組織内の個々のユーザーのみ（異なる環境にいても可） |
なお、実際の共有画面では、この2つは「閲覧者」（＝チャットのための共有：このエージェントとチャットできる）と「エディター」（＝共同編集のための共有：表示・編集・構成・共有・発行ができる）という2つのアクセス許可として表示されます。
画面上の呼び名と公式ドキュメントの言い回しが違うだけで、指している中身は同じです。「画面にはエディターと閲覧者しかない」と感じても、それがそのまま本記事で言う2系統だと考えてください。
なぜ区別が大事か：
「共有」とひとことで言っても、相手にチャットだけ許すのか、設計や発行まで委ねるのかで、組織に与える影響はまったく違います。
公式ドキュメントでも「共同編集のための共有は単純な共有操作ではありません」と明記されており、後述するDataverseのセキュリティロールが絡んでくるのがその理由です。
つまり、最初の分岐は「チャットさせたいだけ」か「作る側に引き込みたい」か。
ここを意識するだけで、次に説明するロールの話がすっと入ってきます。
共同編集で自動付与されるEnvironment Makerロール
共同編集の共有でいちばん見落とされがちなのが、裏でDataverseのセキュリティロールが動く点です。
公式ドキュメントには、共同編集者には「Environment Maker（環境作成者）」のDataverseセキュリティロールが必要、と書かれています。
では、相手がまだこのロールを持っていなかったらどうなるのでしょうか。
このとき、共有する側（あなた）が「システム管理者」のDataverseセキュリティロールを持っていれば、Copilot Studioが必要なロールを代理で割り当ててくれる、とされています。
言い換えると、あなたがシステム管理者なら、共有操作の中で相手に環境作成者ロールが付与される、ということです。
自分も相手も必要なロールを持っていない場合は、システム管理者に依頼してくださいと案内されています。
反映には時間差がある点に注意：
ユーザーがまだ共有エージェントの環境のメンバーでない場合、そのユーザーのCopilot Studioでエージェントが使えるようになるまで最大10分かかることがある、と記載されています。
共有直後に「見えない」と言われても、少し待つ必要があるケースがあるわけですね。
ここで一歩引いて考えてみてください。
エージェント1つを共同編集で渡すという操作が、実は環境（テナント内の区画）レベルの権限付与につながっている——これは設計上、無視できないポイントです。
「とりあえず編集できるように共有」を繰り返すと、環境作成者ロールを持つ人が静かに増えていきます。
このあたりは、誰に環境レベルの権限を渡すのかという組織のガバナンス方針と直結するため、本番運用では「共有のルール」を先に決めておくほど後で揉めにくくなります。
逆に言えば、共有設計は単なる操作手順ではなく、権限設計そのものです。
自社の環境構成やロール運用と噛み合わせて考える必要があります。
（出典: 他のユーザーとエージェントを共有する｜Microsoft Learn）
分析を見せる：Analytics ViewerとBot Transcript Viewerの違い
「編集はさせたくないけれど、分析だけは見てほしい」——アナリストや関係者に対して、よくある要望です。
これに応えるのが、Copilot Studioの「Analytics Viewer（分析ビューアー）」という共有ロールです。
エージェントに変更を加えることなく、分析への読み取り専用アクセスを提供できます。
Analytics Viewerロールが割り当てられたユーザーにできること・できないことは、ドキュメントに明記されています。
分析ページとそのメトリック（指標）を表示でき、分析ページからエージェントを直接開けます。
一方で、エージェントの編集や共有はできず、トピック・アクション・設定・テストツール・発行にもアクセスできません。
なお、このロールはエージェントの所有者だけが割り当てられ、しかも共有先は個人に限られます。セキュリティグループのようなグループ単位では指定できず、対象者を一人ずつ指定する必要がある、とされています。
ここからが少しややこしいところです。
分析ページの「ドリルダウン」、つまり各メトリックの裏にある会話トランスクリプト（会話の書き起こし）まで掘り下げて見るには、追加の権限が必要になります。
ドキュメントによれば、ドリルダウンにアクセスするにはユーザーに次の両方が必要です。
| ロール | アクセスできる範囲 | 付与される場所 |
|---|---|---|
| Analytics Viewer（分析ビューアー） | エージェントの分析ページとそのメトリック | Copilot Studioの共有ロール（所有者が個人に付与） |
| Bot Transcript Viewer | セッションレベルのデータとトランスクリプト | Dataverseのセキュリティロール（環境レベルで割り当て） |
つまり、Analytics Viewerは「分析ページ」までの入場券、Bot Transcript Viewerは「会話の中身」まで踏み込む鍵、という役割分担です。
Bot Transcript Viewerのセキュリティロールは、Power Platform管理センターの環境レベルで割り当てられます。
しかも既定では、管理者のみがBot Transcript Viewerロールを持つ、と記載されています。
ここで見落としてはいけないのが、このロールの「効く範囲」です。
2つのロールは、権限の効く単位が異なります。Analytics Viewerはエージェント1つに対して付与する共有ロールですが、Bot Transcript Viewerは特定のエージェントではなく、環境（テナント内の区画）に対して割り当てるDataverseのセキュリティロールです。
そのためドキュメントには、このロールを持つユーザーは「自分が作成した、あるいはその環境内で共有されているすべてのエージェントの会話トランスクリプトにアクセスできる」と明記されています。
これは実務上、無視できない違いです。
たとえば同じ環境にFAQ用・人事相談用・経営ダッシュボード用のエージェントが同居している場合、FAQ用エージェントの会話を見せたいだけのつもりでBot Transcript Viewerを付与すると、その人には人事相談用や経営用エージェントの会話の中身まで見えてしまう、ということです。
「会話を見せる鍵」は1本でも、その鍵が開けるのは1部屋ではなく環境というフロア全体——この感覚を持っておくと、付与の判断を誤りにくくなります。
だからこそ、誰に会話を見せるかを厳密に絞りたい場合は、対象のエージェント専用に新しい環境を用意することが、制御策としてドキュメントでも案内されています。
プライバシーへの配慮が前提：
ドキュメントには、エージェントの内容や対象ユーザーによっては、適切なプライバシートレーニングを受けたユーザーのみにトランスクリプトアクセスを許可することを検討するよう、注意喚起があります。
会話の書き起こしには利用者の生の発話が含まれ得るため、誰に見せるかは慎重に設計したい部分です。
「分析を共有して」と言われたとき、相手が見たいのはサマリーの数字なのか、個々の会話なのか。
ここを確認するだけで、付与すべきロールが変わってきます。
最小権限で共有を設計する
ここまでの話を踏まえると、共有設計の軸ははっきりしてきます。
「相手に必要なことだけをさせる」、いわゆる最小権限の考え方です。
Copilot Studioのロールは、まさにこの考え方に沿って使い分けられるように用意されています。
たとえば、エージェントを使ってほしいだけならチャットのための共有で十分です。
分析の数字を見せたいならAnalytics Viewer、会話の中身まで見せる必要があるときに初めてBot Transcript Viewerを足す。
設計や発行まで任せたい相手にだけ、共同編集の共有（Environment Makerが前提）を使う——こう段階を分けると、渡しすぎを防げます。
| やりたいこと | 選ぶ共有・ロール |
|---|---|
| エージェントを使ってほしいだけ | チャットのための共有 |
| 分析の数字を見せたい | Analytics Viewer（分析ビューアー） |
| 会話トランスクリプトまで見せたい | Analytics Viewer ＋ Bot Transcript Viewer |
| 一緒に編集・発行してほしい | 共同で作成するための共有（Environment Makerが前提） |
運用面で覚えておきたいのが、共有時の制約です。
ドキュメントには、エージェントを共有する際にはセキュリティロールを「割り当てる」ことしかできず、共有時に削除はできない、と書かれています。
ロールの削除を含む完全な管理を行うには、Power Platform管理センターを使う必要があります。
つまり「共有画面で足す」ことはできても「共有画面で剥がす」ことはできない、という非対称性があるわけですね。
設計の最終解は要件次第：
ここで紹介したのは、あくまで標準的なロールの使い分けの考え方です。
実際には、どの環境にどのエージェントを置くか、誰にどのロールをどの範囲で渡すか、トランスクリプト閲覧をどこまで絞るか——この具体的な設計は組織の体制やデータの機微度（取り扱いの慎重さ）によって変わります。
「とりあえず共有」を積み重ねた結果、誰が何を見られるのか分からなくなる、ということも起こり得るでしょう。
自社の運用に落とし込む段階で詰まりそうだと感じたら、設計の整理から一緒に考えるのが良いと思います。
最小権限は、一度ルールを決めてしまえば運用がぐっと軽くなる考え方です。
共有のたびに迷わなくなりますし、棚卸しもしやすくなります。
まとめ：共有の裏側を理解して設計する
今回は、Microsoft Copilot Studioのエージェント共有について、公式ドキュメントの記述に沿って整理しました。
最後に、3つの学びを振り返っておきましょう。
- 「共有」には2系統ある：チャットのための共有と、共同で作成するための共有（共同編集）は別物で、付与される権限がまったく異なります。
- 裏でDataverseロールが動く：共同編集にはEnvironment Maker（環境作成者）が必要で、共有者がシステム管理者なら共有時に代理付与され、分析の深掘りにはBot Transcript Viewerが別途必要です。しかもBot Transcript Viewerは環境単位で効くため、付与した相手には同じ環境にある全エージェントの会話が見えます。
- 最小権限で段階的に：使わせたいだけ／分析を見せたい／会話まで見せたい／一緒に作りたい、を切り分け、必要な分だけ渡すのが運用を楽にするコツです。
なお、本文で触れた数値や仕様は2026年時点の公式ドキュメントの記述に基づくもので、今後変わる可能性があります。最新の挙動は必ず公式ドキュメントでご確認ください。
（出典: 他のユーザーとエージェントを共有する｜Microsoft Learn）
まずは自社のエージェントについて「誰に・何を・どこまで」共有しているかを棚卸しすることから始めてみてはいかがでしょうか。
また、QESでは、Power Platform導入時の支援から、アプリケーション開発、導入後の保守サポートまで対応しています。
以下のリンクからご提供しているサービスの詳細をご確認いただけます。
※このブログで参照されている、Microsoft、Microsoft Copilot Studio、Microsoft Dataverse、Power Platform は、米国およびその他の国における Microsoft Corporation の商標または登録商標です。
