2026年4月30日にGitHub上のMicrosoftDocsリポジトリで更新された「Update configure-copilot-features.md」は、見た目は小さな文言修正ですが、Dynamics 365 Customer ServiceのCopilot機能を運用している組織では確認しておきたい変更です。
結論からいうと、今回のポイントは「Copilot case summary」だけに見えていた権限説明が、より広く「Copilot」へのアクセス説明に修正されたことです。標準ロールだけで運用している場合の影響は限定的ですが、カスタムセキュリティロール、Customer Service Hub、Copilot Service workspace、カスタムアプリを使っている環境では、権限設定と運用手順を見直す価値があります。
GitHubの公式ドキュメント更新「Update configure-copilot-features.md」で何が変わったか
今回の更新は、GitHub上の MicrosoftDocs/dynamics-365-customer-engagement リポジトリにある ce/customer-service/administer/configure-copilot-features.md に対するコミットです。コミットの件名は「Update configure-copilot-features.md」で、対象ファイルは1つ、差分は2行追加・3行削除という小規模な更新でした。(GitHub)
重要なのは、変更量ではなく権限説明の対象範囲です。差分では、カスタムセキュリティロールに Miscellaneous privileges > prvIntelligenceUsage を割り当てる目的が、以前の「Copilot case summaryにアクセスするため」から「Copilotにアクセスするため」へ変更されています。(GitHub)
| 確認項目 | 変更前の意味合い | 変更後に読むべき意味合い |
|---|---|---|
prvIntelligenceUsage の説明 | Copilotのケース要約機能に関係する権限に見える | Copilot機能全体へのアクセスに関わる権限として確認すべき |
| 影響範囲 | ケース要約だけを使う部署に限定して考えがち | Copilotを使う代表者、カスタムロール、カスタムアプリ利用者まで確認対象になる |
| 運用上の判断 | 「要約を使わなければ関係ない」と判断しやすい | Copilotを有効化している環境では、ロール設計の再確認が必要 |
この更新は、新機能の追加やUI変更を示すものではありません。ただし、権限設計の読み違いを防ぐための修正と考えると、developers、cloud admins、solution architects、technical decision makersにとって実務上の意味があります。
今回の更新はGitHub Copilotの変更ではなく、Dynamics 365 Customer ServiceのCopilot設定に関する更新
記事タイトルやコミット名だけを見ると、GitHub Copilotの機能変更のように見えるかもしれません。しかし、対象はGitHub Copilotそのものではなく、MicrosoftDocsのDynamics 365 Customer Service向けドキュメントです。
Microsoft Learn上の該当ページは、Dynamics 365 Customer ServiceでCopilot機能を有効化・管理する方法を説明しています。Copilot Service workspaceなどで、担当者が質問への回答、メール作成、チャット応答の下書き、ケースや会話の要約を利用できることが説明されています。(Microsoft Learn)
つまり、今回確認すべきなのは次のような環境です。
| 環境・利用形態 | 確認すべき理由 |
|---|---|
| Dynamics 365 Customer ServiceでCopilotを使っている | Copilotアクセス権の説明が広い表現に変わったため |
| Customer Service Representative以外のカスタムロールを使っている | 権限不足でCopilotが使えない可能性があるため |
| Customer Service HubやカスタムアプリでCopilotを使う | 追加設定やアプリ側の有効化が必要になる場合があるため |
| セキュリティロールを細かく分けている | 最小権限設計と利用可否のバランスを確認する必要があるため |
| グローバル展開している | リージョン、データ移動、プレビュー提供範囲の確認が必要になるため |
管理者が最初に確認すべきポイント
今回の更新を受けて、最初に見るべき場所は「Copilotの画面」ではなくセキュリティロールです。特に、標準のCustomer Service Representativeロールをそのまま使わず、独自のCSRロールやマネージャーロールを作っている環境では確認優先度が高くなります。
Microsoft Learnの現行説明では、標準のCustomer Service Representativeロールを持つユーザーはCopilot機能を利用できる一方、カスタムロールのユーザーには必要な権限を付与する必要があるとされています。(Microsoft Learn)
prvIntelligenceUsage を確認する
今回の差分で最も重要なのは、prvIntelligenceUsage です。Microsoft Learnでは、必要なカスタムセキュリティロールに Miscellaneous privileges > prvIntelligenceUsage を割り当てるよう記載されています。(Microsoft Learn)
実務では、次のように確認します。
| 確認対象 | 見るべきポイント |
|---|---|
| 標準CSRロール | 標準ロールをそのまま使っているか |
| カスタムCSRロール | prvIntelligenceUsage が含まれているか |
| CSR Manager相当のロール | 必要なCopilot関連権限が適切なアクセスレベルになっているか |
| 一時的に作った検証用ロール | 本番展開前に権限が不足していないか |
| 部門別・地域別ロール | 一部ユーザーだけCopilotが使えない状態になっていないか |
ありがちな失敗は、「Copilotの設定は有効なのに、特定のユーザーだけ使えない」というケースです。この場合、ライセンスやリージョンだけでなく、カスタムロールに必要な権限が入っているかを確認する必要があります。
カスタムロールで確認すべきCopilot関連テーブル権限
Microsoft Learnでは、カスタムロールに必要なCopilot関連のテーブル権限も示されています。対象には msdyn_copilotevent、msdyn_copilotinteraction、msdyn_copilotinteractiondata、msdyn_copilotagentpreference、msdyn_copilottranscriptdata などが含まれます。(Microsoft Learn)
すべてを丸暗記する必要はありません。実務では、次のように用途別に整理すると確認しやすくなります。
| 権限グループ | 関連する用途 | 確認の観点 |
|---|---|---|
| Copilot利用イベント | Copilot利用時のイベント記録 | 読み取り・作成・書き込み権限が不足していないか |
| Copilotインタラクション | 担当者とCopilotのやり取り | 利用ログや対話データの扱いと整合しているか |
| Copilot transcript data | Copilotとのやり取りの記録・分析 | 録画・記録・分析の運用ポリシーに合っているか |
| AI Model / AI Template | AI関連設定の参照 | 必要なユーザーに読み取り権限があるか |
| App profile / Pane configuration | アプリやペインの表示設定 | Copilotペインやカスタムアプリ利用時に不足がないか |
特に注意したいのは、Copilot機能を「画面に出す設定」と「実際に使える権限」は別物だという点です。UI上でCopilotを有効化していても、ユーザーのロールに必要な権限がなければ、利用できない、または一部機能だけ動かない状態になる可能性があります。
仕様確認で見るべき範囲
今回の更新は小さいため、「文言修正だけ」として見逃しやすい内容です。しかし、Copilotのように権限、データ、リージョン、ライセンスが関係する機能では、ドキュメントの表現変更が運用判断に影響することがあります。
Copilotの利用場所を確認する
Dynamics 365 Customer ServiceのCopilot機能は、Copilot Service workspaceなどのアプリで使われます。公式ドキュメントでは、Customer Service Hubやカスタムアプリで利用する場合には、追加の有効化手順が必要であることも説明されています。(Microsoft Learn)
確認すべき項目は次の通りです。
| 確認項目 | 判断基準 |
|---|---|
| Copilot Service workspaceのみで使う | 標準設定とロール確認を優先 |
| Customer Service Hubでも使う | 機能有効化の範囲を確認 |
| カスタムアプリで使う | アプリ側の設定、フォーム、ロール、表示条件を確認 |
| 一部部門だけに展開する | エクスペリエンスプロファイルやカスタムロールで制御できているか確認 |
| グローバル拠点に展開する | リージョンごとの利用可否とデータ移動設定を確認 |
リージョンとデータ移動を確認する
Copilot機能では、リージョンやAzure OpenAI Serviceの提供状況によって、データ移動の設定が関係する場合があります。Microsoft Learnでは、米国、オーストラリア、インド、英国、政府クラウドなど一部地域では「in region」で利用できる説明があり、その他の地域ではPower Platform管理センターでリージョン間データ移動を有効化する必要がある場合があります。(Microsoft Learn)
日本語圏の組織で特に注意したいのは、国内利用者向けの展開であっても、テナントや環境の地域、データ処理の地理的条件、組織のコンプライアンス要件が一致しているとは限らないことです。
導入前には、次の観点で確認しましょう。
| 確認項目 | なぜ重要か |
|---|---|
| Power Platform環境の地域 | Copilot利用可否やデータ処理条件に関係するため |
| データ移動の許可状態 | 利用できない、または性能に影響する可能性があるため |
| 社内のデータ保護ポリシー | 顧客情報や会話データを扱うため |
| グローバル拠点の利用範囲 | 国・地域ごとに許容条件が異なる場合があるため |
| 監査証跡の保存方針 | 後から利用状況を説明できるようにするため |
運用影響は「カスタムロールの有無」で大きく変わる
今回の更新で最も影響を受けやすいのは、セキュリティロールを独自設計している組織です。
たとえば、次のような環境では確認を後回しにしないほうがよいでしょう。
| ケース | 起こりやすい問題 |
|---|---|
| 標準CSRロールをコピーして一部権限を削った | Copilot利用に必要な権限まで削除している可能性がある |
| 部門ごとにCSRロールを分けている | 一部部門だけCopilotが使えない可能性がある |
| マネージャー向けロールを独自作成している | CSR Manager相当の権限レベルとずれている可能性がある |
| 最小権限を厳格に運用している | Copilot関連テーブルの権限不足が起きやすい |
| 検証環境と本番環境でロールが異なる | 検証では動いたが本番で動かない可能性がある |
重要なのは、「Copilotを有効化するかどうか」だけでなく、「誰に、どのアプリで、どの機能を、どのデータ条件で使わせるか」まで整理することです。
実務で使える確認手順
更新内容を受けて、管理者は次の順番で確認すると効率的です。
| 手順 | 作業内容 | 成果物 |
|---|---|---|
| 1 | Copilotを利用するアプリを洗い出す | Copilot Service workspace、Customer Service Hub、カスタムアプリの一覧 |
| 2 | 対象ユーザーのロールを確認する | 標準ロール・カスタムロールの一覧 |
| 3 | prvIntelligenceUsage の有無を確認する | 不足しているロールのリスト |
| 4 | Copilot関連テーブル権限を確認する | Create、Read、Write、Appendなどの確認結果 |
| 5 | 検証ユーザーで実際に動作確認する | 利用可否、エラー、表示状態の記録 |
| 6 | 社内手順書を更新する | 「case summary」ではなく「Copilot」全体として記載 |
| 7 | 本番反映前に承認を取る | 変更理由、対象範囲、戻し方の記録 |
この手順で進めると、単なるドキュメント更新の確認で終わらず、本番運用に必要な権限・データ・アプリ設定まで一度に点検できます。
移行準備で注意すべきポイント
Copilot機能をこれから展開する場合や、一部ユーザーから全社利用へ拡大する場合は、今回の更新を移行準備のチェックリストに含めるべきです。
社内ドキュメントの表現を修正する
社内手順書に「Copilot case summaryを使う場合は prvIntelligenceUsage を付与する」と書いてある場合、読者はケース要約以外では不要だと誤解する可能性があります。
今回の更新に合わせて、次のように表現を変えると安全です。
| 修正前 | 修正後 |
|---|---|
Copilot case summaryを使う場合は prvIntelligenceUsage が必要 | Copilotを利用するカスタムロールには prvIntelligenceUsage の確認が必要 |
| ケース要約利用者だけ権限を確認する | Copilot利用者全体のロールを確認する |
| 要約機能の展開手順として管理する | Copilot機能のアクセス制御手順として管理する |
この修正は小さく見えますが、問い合わせ対応や権限申請フローの混乱を防ぐ効果があります。
権限を広げすぎない
Copilotが使えない問題を解決するために、安易に管理者ロールを付与するのは避けるべきです。短期的には動作確認が楽になりますが、長期的には監査、情報保護、職務分掌の観点で問題になります。
おすすめは、次のような段階的な対応です。
| 対応 | 推奨度 | 理由 |
|---|---|---|
| 必要なカスタムロールに不足権限を追加する | 高 | 最小権限を保ちやすい |
| 標準CSRロールとの差分を比較する | 高 | 不足権限を見つけやすい |
| 検証ユーザーで権限を再現する | 高 | 本番影響を抑えられる |
| 一時的に管理者権限を付与する | 低 | 原因切り分け以外ではリスクが大きい |
| すべてのCSRに同じ広い権限を付与する | 低 | 部門別制御や監査要件に合わない場合がある |
developersが確認すべき点
developersにとって重要なのは、Copilotの利用可否がアプリ側の実装だけで決まらないことです。
Customer Service HubやカスタムアプリでCopilotを利用する場合、アプリの表示、フォーム、プロファイル、ロール、関連テーブル権限が組み合わさります。画面上のコンポーネントが正しく表示されても、ユーザーの権限が不足していれば期待通りに動作しない可能性があります。
開発チームは、次のような観点でテストケースを作るとよいでしょう。
| テスト観点 | 具体例 |
|---|---|
| 標準ロールとカスタムロールの差 | 標準CSRでは使えるが、カスタムCSRでは使えない状態を確認 |
| アプリ別の挙動 | Copilot Service workspace、Customer Service Hub、カスタムアプリで比較 |
| 機能別の挙動 | 回答生成、メール作成、要約、翻訳、トランスクリプト記録を分けて確認 |
| エラー表示 | 権限不足時にユーザーへどう見えるか確認 |
| ロール変更後の反映 | 反映タイミングや再ログインの必要性を確認 |
cloud adminsが確認すべき点
cloud adminsは、Power Platform管理センター、Dynamics 365環境、セキュリティロール、データ移動設定をまとめて確認する必要があります。
Copilot機能では、リージョン間データ移動やデータ共有の設定が関係する場合があります。公式ドキュメントでは、Copilot機能のデータ共有をPower Platform管理センターで有効化できること、ユーザーの自然言語入力、出力、関連テレメトリなどが機能改善や検証に使われる場合があること、Azure OpenAI Serviceの基盤モデルのトレーニングには顧客データを使わないことが説明されています。(Microsoft Learn)
確認すべきポイントは次の通りです。
| 項目 | 確認内容 |
|---|---|
| 環境の地域 | 利用対象のDynamics 365 / Power Platform環境がどの地域にあるか |
| データ移動 | リージョン間データ移動が必要か、許可されているか |
| データ共有 | 任意のデータ共有設定が組織ポリシーに合っているか |
| セキュリティロール | カスタムロールに必要な権限があるか |
| 監査 | 誰が、いつ、どの機能を使えるようにしたか記録できるか |
solution architectsが確認すべき点
solution architectsは、今回の更新を「権限の細部」だけでなく、Copilot導入設計全体の確認材料として扱うべきです。
特に、次の設計判断が重要です。
| 設計テーマ | 判断すべき内容 |
|---|---|
| 利用範囲 | 全CSRに展開するか、特定部門から始めるか |
| ロール設計 | 標準ロール中心か、カスタムロール中心か |
| データ境界 | 地域、テナント、環境ごとのデータ制約をどう扱うか |
| 監査設計 | Copilot利用履歴やトランスクリプトをどう扱うか |
| 変更管理 | ドキュメント更新をどのタイミングで社内標準に反映するか |
Copilotは単体機能ではなく、アプリ、データ、権限、運用プロセスがつながった機能です。文言修正であっても、設計書や運用ルールに反映しなければ、現場では「なぜ使えないのか分からない」という問い合わせにつながります。
technical decision makersが判断すべき点
technical decision makersにとって今回の更新は、投資判断や導入方針を変えるほど大きな変更ではありません。ただし、Copilot導入の前提条件を再確認するきっかけになります。
判断すべき点は次の3つです。
| 判断項目 | 確認すべきこと |
|---|---|
| 導入準備 | ライセンス、リージョン、権限、データ条件がそろっているか |
| 運用負荷 | カスタムロール管理、問い合わせ対応、監査記録を誰が担うか |
| 展開方針 | 一括展開か、部門別・段階的展開か |
特に、Copilotの効果だけを見て急いで展開すると、権限不足やデータポリシーの確認漏れで現場の信頼を失う可能性があります。まずは代表的なロールで検証し、問い合わせが出やすいポイントを事前に潰しておくのが現実的です。
よくある誤解と正しい見方
「2行追加・3行削除なら確認不要」ではない
差分は小さくても、権限に関する文言変更は運用に影響します。特にCopilotのようなAI機能では、アクセス制御の説明が広がることで、確認対象も広がります。
「ケース要約を使っていないから関係ない」とは限らない
今回の修正では、「Copilot case summary」ではなく「Copilot」にアクセスするための権限として表現されています。ケース要約を使っていなくても、Copilot機能を有効化している環境では確認対象になります。
「Copilotを有効化すれば全員使える」とは限らない
Customer Service Hubでは機能を有効化すると代表者に利用可能になる説明がありますが、カスタムロールやカスタムアプリでは権限や追加設定の確認が必要です。(Microsoft Learn)
「管理者権限なら動くから問題ない」は危険
管理者権限で動作確認すると、一般ユーザーやカスタムCSRロールの権限不足を見落とします。必ず実際の業務ロールに近いユーザーで検証しましょう。
すぐに使えるチェックリスト
今回のGitHub公式ドキュメント更新を受けて、次の項目を確認しておくと安全です。
| チェック項目 | 完了の目安 |
|---|---|
| 対象コミットの内容を確認した | configure-copilot-features.md の差分を把握している |
| GitHub CopilotではなくDynamics 365 Customer ServiceのCopilot設定だと理解した | 対象サービスの誤解がない |
| カスタムセキュリティロールの有無を確認した | CSR、CSR Manager、部門別ロールを洗い出した |
prvIntelligenceUsage を確認した | 必要なカスタムロールに含まれている |
| Copilot関連テーブル権限を確認した | 標準ロールとの差分を把握している |
| Copilotを使うアプリを確認した | workspace、Hub、カスタムアプリを分けている |
| リージョンとデータ移動を確認した | Power Platform環境の条件を把握している |
| データ共有とトランスクリプト記録を確認した | 社内ポリシーと矛盾していない |
| 検証ユーザーで動作確認した | 本番ロールに近い条件で確認済み |
| 社内手順書を更新した | 「case summary」限定の表現を避けている |
まとめ：小さな文言修正でも、Copilot運用では権限設計を見直すきっかけになる
今回の「Update configure-copilot-features.md」は、機能追加ではなくドキュメント上の表現修正です。ただし、prvIntelligenceUsage の説明が「Copilot case summary」から「Copilot」へ広がったことで、カスタムロールを使う組織では確認すべき範囲が明確になりました。
まず実施すべきことは、Copilotを使うユーザーとアプリを洗い出し、カスタムセキュリティロールに prvIntelligenceUsage と必要なCopilot関連テーブル権限が含まれているか確認することです。そのうえで、リージョン、データ移動、データ共有、トランスクリプト記録、社内手順書の表現を見直しましょう。
差分が小さい更新ほど、現場では見落とされがちです。Copilotを安定して展開するには、公式ドキュメントの更新を「読む」だけでなく、ロール設計と運用手順に落とし込むことが重要です。
コメント