Microsoft 365 CopilotのCopilot People Connectorsを使う企業にとって、今回の更新のポイントは「外部の人事・採用・タレント管理システムにあるPeopleデータを、アクセス制御付きでMicrosoft 365に取り込めるようになる」ことです。単に社員プロフィールを充実させるだけでなく、ソースシステム側で定義された権限をCopilotが尊重しながら、人に関する情報を推論・検索に使えるようになる点が重要です。Microsoft 365 Roadmap ID 561326では、一般提供予定は2026年8月、ステータスはIn development、対象クラウドはWorldwide、プラットフォームはDeveloperとされています。作成・更新時刻はUTCで2026年5月15日22時台のため、日本時間では2026年5月16日の更新として確認できます。(Microsoft)
この機能を検討する管理者は、まず「どのPeopleデータを取り込むか」ではなく、「誰がその情報を見てよいのか」を先に決めるべきです。スキル、職務経歴、所属、担当領域、採用関連情報などはCopilotの回答精度を高めますが、権限設計を誤ると、組織図では見えてよい情報と、人事システム上だけで扱うべき情報の境界が崩れます。公開前に確認すべきことは、既存コネクタの可視性、ACLの設計、Microsoft Entra IDとのIDマッピング、プロファイルソースの優先順位、プロファイルカードへの表示範囲、そしてテスト用ユーザーでの権限検証です。
Microsoft 365 CopilotのCopilot People Connectorsで何が変わるのか
今回の更新では、Copilot People Connectorが外部システムからPeopleデータをMicrosoft 365へ取り込む際に、関連するアクセス制御リスト、つまりACLもあわせて扱えるようになります。ロードマップの説明では、外部システムに定義された既存のアクセス権をCopilotが尊重し、取り込まれたデータを特定の個人やグループにスコープできるとされています。(Microsoft)
従来のPeopleデータ連携では、公式ドキュメント上、Copilotコネクタ経由で提供されたPeopleデータは既定でテナント内の全ユーザーに表示されると説明されており、開発者向けドキュメントでもPeopleデータを取り込む項目には全ユーザーへのアクセス許可を与えるACLが必要とされていました。(Microsoft Learn) (Microsoft Learn)
今回のロードマップ項目は、この既存仕様に対する実務上大きな拡張と考えられます。特に、人事・タレント・採用・スキル管理などの外部システムをMicrosoft 365 Copilotに接続したい企業にとって、「取り込むか、取り込まないか」だけでなく、「誰に見せるか」を細かく制御できる可能性が出てきます。
| 観点 | これまで注意が必要だった点 | 今回の更新で期待できること | 実務上の確認ポイント |
|---|---|---|---|
| Peopleデータの可視性 | 既定で広く見える前提の設計が必要だった | 個人・グループ単位でスコープできる | 「全社員に見せてよい属性」と「限定公開の属性」を分ける |
| Copilotの回答 | 取り込まれたPeopleデータをCopilotが利用できる | 権限を尊重した回答に近づく | 許可ユーザーと非許可ユーザーで同じプロンプトを試す |
| 外部システム連携 | Microsoft 365側のプロフィール情報として扱う設計が中心 | ソース側ACLをMicrosoft 365側へ反映できる | ソース権限とEntra IDユーザー・グループの対応表を作る |
| 移行・展開 | 過共有を避けるため属性選定が重要だった | ACL付き取り込みを前提に再設計できる | 既存コネクタの削除・再作成が必要になる可能性を確認する |
Peopleデータ連携がCopilotの精度に効く理由
Copilot People Connectorsは、人事、採用、タレント管理、その他のPeopleプラットフォームにある信頼できるユーザー情報をMicrosoft 365に取り込み、Microsoft 365 Copilot、Microsoft Search、プロファイルカード、組織エクスプローラーなどで、より豊かな人物コンテキストを使えるようにするための仕組みです。(Microsoft Learn)
たとえば、次のような質問に対して、Copilotがより実務に近い回答を返しやすくなります。
- 「関西エリアで製造業のERP導入経験がある人を探して」
- 「この案件に詳しいセキュリティ担当者は誰？」
- 「次の顧客提案に参加すべきメンバー候補を挙げて」
- 「この部署でPower Platformに詳しい人を確認して」
ただし、Peopleデータは便利な一方で、扱いを誤るとリスクが高いデータでもあります。役職、担当業務、スキル程度なら共有しやすい一方で、評価、報酬、異動予定、採用選考、休職情報、健康情報、懲戒・労務情報などは、Copilotの参照対象にすべきではありません。今回のACL対応は、こうした境界を設計するための重要な材料になります。
影響範囲：利用者、管理者、開発者で見るべきポイントが違う
今回の変更は、エンドユーザーの画面に新しいボタンが出るような単純なUI変更ではありません。むしろ、Microsoft 365 Copilotが回答を生成する際の「人物情報の根拠データ」をどう安全に広げるかという、管理・開発寄りの更新です。
| 対象者 | 主な影響 | すぐ確認すべきこと |
|---|---|---|
| 一般利用者 | 人探し、スキル検索、組織理解、担当者特定の回答が改善される可能性 | Copilotに聞いてよい範囲、回答の根拠確認方法 |
| Microsoft 365管理者 | コネクタの可視性、権限、プロフィール表示、同期設定の見直しが必要 | Copilot > Connectorsの接続状況、権限設定、対象データ |
| セキュリティ・コンプライアンス担当 | 過共有、個人情報、情報バリア、監査観点の確認が必要 | 取り込み禁止属性、限定公開属性、DSR対応 |
| 開発者 | Peopleデータ用スキーマ、ACL、外部グループ、同期処理の実装が必要 | contentCategory=people、personAccount、ACL設計 |
| 人事・業務部門 | どの外部データをMicrosoft 365に反映するかの判断が必要 | ソースシステム上の権限とMicrosoft 365上の見え方 |
管理者が最初に確認すべき設定
既存のCopilotコネクタが「全員に表示」前提になっていないか確認する
Microsoft 365 Copilotコネクタのアクセス権は、Microsoft 365管理センターの「Copilot > Connectors > Your Connections」から確認できます。公式ドキュメントでは、コネクタの権限として「Only people with access to this data source」と「Visible to everyone」が示されており、誤ってEveryone相当の設定にすると、機密性の高いコンテンツの過共有につながる可能性があると説明されています。(Microsoft Learn)
既存のPeopleデータ連携がある場合は、次の3点を確認してください。
| 確認項目 | 見るべきポイント |
|---|---|
| 接続名 | どの外部システムからPeopleデータを取り込んでいるか |
| 権限設定 | 全員表示なのか、ソース権限を尊重する設計なのか |
| 取り込み属性 | 役職、部署、スキル、資格、プロジェクト、採用情報など何が入っているか |
特に注意したいのは、以前は問題にならなかった属性が、Copilotの自然言語回答によって見つけやすくなるケースです。検索画面では見落とされていた情報でも、Copilotが「候補者を要約して」と聞かれたときに回答へ含める可能性があります。
アクセス権は作成後に簡単に変えられない前提で設計する
一般的なMicrosoft 365 Copilotコネクタのドキュメントでは、接続作成後のアクセス権限更新は現在サポートされておらず、意図した可視性モデルと合わない場合は既存接続を削除し、Custom setupで明示的にアクセス権を設定して再作成する流れが示されています。(Microsoft Learn)
今回のPeople ConnectorのACL対応が展開された後も、既存接続の扱いは仕様更新や対象コネクタによって変わる可能性があります。そのため、展開前の設計段階で次の判断を済ませておくことが重要です。
- 既存のPeople Connectorを継続利用するのか
- 新しいACL対応を前提に再作成するのか
- 一部属性だけを取り込む縮小構成にするのか
- 本番テナントではなく検証環境で先に確認するのか
- ソースシステム側の権限変更をどの頻度でMicrosoft 365へ反映するのか
プロファイルソースの優先順位を確認する
Peopleデータを複数のシステムから取り込む場合、同じプロフィール項目に複数の値が存在することがあります。たとえば、役職はMicrosoft Entra IDにもあり、人事システムにもあり、タレント管理システムにもあるかもしれません。
Microsoftのドキュメントでは、複数ソースが同じプロファイルプロパティを提供する場合、管理者がプロファイルソースの優先順位を設定し、どの値をMicrosoft 365上で表示するか制御できると説明されています。既定ではEntra IDが優先ソースとされています。(Microsoft Learn)
実務では、次のように決めると整理しやすくなります。
| プロファイル項目 | 推奨される権威ソースの例 | 理由 |
|---|---|---|
| 氏名、メール、アカウント | Microsoft Entra ID | ID管理と一致させるため |
| 所属、役職、雇用区分 | 人事システム | 組織情報の正本になりやすいため |
| スキル、資格、プロジェクト経験 | タレント管理システム | 業務検索・人材活用に使いやすいため |
| 担当顧客、案件履歴 | CRMや案件管理システム | 営業・CSの文脈に依存するため |
ここを決めずに接続すると、「Copilotが出した役職とプロフィールカードの役職が違う」「人事システムでは更新済みなのにMicrosoft 365では古い」といった問い合わせが増えます。
プロファイルカードに表示する情報を見直す
PeopleデータはCopilotの回答だけでなく、プロフィールカードなどのMicrosoft 365体験にも関係します。管理者はMicrosoft 365管理センターのPeople settingsで、プロフィールカードに表示する一部のプロパティを制御できます。なお、プロパティを非表示にしても、Microsoft 365プロフィール内の元データが削除されるわけではないと説明されています。(Microsoft Learn)
つまり、「プロフィールカードに出さないから安全」とは言い切れません。CopilotやSearchなど、他の体験で参照される可能性も含めて、取り込み自体を制御する必要があります。
開発者が押さえるべき実装ポイント
Peopleデータ用コネクタとして認識される構成にする
Peopleデータ用のMicrosoft 365 Copilotコネクタを構築する場合、Microsoft Graph外部接続APIを使い、接続にPeopleデータが含まれることをMicrosoft 365に認識させる必要があります。公式ドキュメントでは、externalConnections APIのcontentCategoryプロパティにpeopleを設定すること、さらにスキーマ要件に従って接続をプロファイルデータのソースとして登録することが説明されています。(Microsoft Learn)
特に重要なのは、personAccountラベルです。外部データの1レコードをMicrosoft Entra IDのどのユーザーに対応させるかを示すため、スキーマにはpersonAccountラベルを持つプロパティが必要です。userPrincipalNameやexternalDirectoryObjectIdが一致しないユーザーアカウントは無視されるため、IDマッピングの精度が実装品質を左右します。(Microsoft Learn)
ACLは「誰に見せるか」を表す中心設計にする
Microsoft Graph接続に追加するexternalItemには、ACL、properties、contentという主要な構成要素があります。ACLは、Microsoftの各体験でアイテムを表示してよいかどうかを、Microsoft Entraユーザーやグループなどに対してgrantまたはdenyで表す仕組みです。denyはgrantより優先されるため、除外条件を使う場合はテストが必須です。(Microsoft Learn)
ACLの型としては、Microsoft GraphのACLリソースでuser、group、everyone、everyoneExceptGuests、externalGroupなどが示されています。Microsoft Entra IDのユーザーやグループを使う場合、valueには対象IDを指定します。(Microsoft Learn)
PeopleデータでACLを設計する際は、次の順序で考えると実装ミスを減らせます。
| 設計項目 | 判断基準 |
|---|---|
| ユーザー単位で許可するか | 個別の役職者、直属上長、人事担当者など少人数に限定する場合 |
| グループ単位で許可するか | 部門、職種、地域、プロジェクト単位で権限が決まる場合 |
| 外部グループを使うか | ソースシステム側に独自のロール、チーム、権限グループがある場合 |
| denyを使うか | 全体許可から特定ユーザー・グループだけ除外する必要がある場合 |
| Everyoneを使うか | 本当に全社員に公開してよい属性だけに限定する場合 |
外部システム固有の権限はexternalGroupで表現する
Salesforceのプロファイルやロール、ServiceNowのローカルグループ、Confluenceのローカルグループのように、Microsoft Entra IDに存在しないグループ構造をソースシステムが持っている場合があります。このような場合、Microsoftは外部グループを使うことを推奨しています。外部グループを作成し、ACL定義で利用し、メンバーシップを最新状態に同期する流れです。(Microsoft Learn)
開発で避けたいのは、ソースシステムのグループメンバーを毎回展開して、個別ユーザーのACLとして大量に書き込むことです。グループメンバーの変更が大量のアイテム更新につながり、同期遅延やAPI負荷、運用ミスの原因になります。Microsoftのドキュメントでも、外部グループのメンバーシップを個別アイテムのACLに直接展開することは避けるよう説明されています。(Microsoft Learn)
移行・展開前のチェックリスト
今回の更新は「機能が利用可能になったらすぐ有効化する」よりも、「現在のPeopleデータ管理を棚卸ししてから段階的に展開する」ほうが安全です。特に既にPeople ConnectorやGraph Connectorを使っている環境では、以下の順序で確認してください。
| 手順 | 作業内容 | 完了条件 |
|---|---|---|
| 1 | 接続済みコネクタを棚卸しする | 接続名、データソース、取り込み属性、権限設定が一覧化されている |
| 2 | Peopleデータを分類する | 全社公開、部門限定、人事限定、取り込み禁止に分けられている |
| 3 | ソースシステムのACLを確認する | ユーザー、グループ、ロール、例外設定が把握できている |
| 4 | Entra IDとの対応を確認する | UPN、メール、オブジェクトID、外部グループの対応方針が決まっている |
| 5 | プロファイルソース優先順位を設計する | Entra ID、人事、タレント管理などの優先順が決まっている |
| 6 | 検証用データでテストする | 許可ユーザーだけが該当情報をCopilotで取得できる |
| 7 | 本番展開の戻し方を決める | コネクタ削除、再作成、属性削減、同期停止の手順が文書化されている |
| 8 | 利用者へ周知する | Copilotで扱える人物情報、誤りの申告先、禁止プロンプトが共有されている |
なお、Peopleデータ用コネクタのドキュメントでは、接続作成後に検索、People体験、Copilotで利用可能になるまで最大6時間かかる場合があるとされています。また、Peopleデータ接続ではステージングされた接続はサポートされないと説明されています。(Microsoft Learn)
そのため、本番テナントで「少しだけ試す」運用には注意が必要です。限定公開したいデータをいきなり本番投入するのではなく、検証用の属性、検証用ユーザー、検証用グループを先に用意するほうが安全です。
展開時に失敗しやすいポイント
「ソース側で見えないからCopilotでも見えない」と思い込む
今回の機能は、ソース側のACLをCopilotに尊重させるための更新です。しかし、ACLを正しく取り込まなければ、ソース側の権限が自動的に完全再現されるとは限りません。
特に、ソースシステム側に独自ロールやネストされた権限、例外的なdeny設定がある場合は要注意です。単純な部署グループだけで再現すると、本来見えない人に見える、または本来見える人に見えないという問題が起きます。
センシティブな人事属性を「検索精度向上」の名目で入れすぎる
Copilotの回答精度を上げるには、人物に関する文脈が多いほど有利です。しかし、すべての人事データを取り込むべきではありません。
取り込みを避けるべき典型例は次のとおりです。
| 取り込みを避けたい属性 | 理由 |
|---|---|
| 給与、賞与、等級の詳細 | 閲覧権限が極めて限定されるため |
| 人事評価、パフォーマンス評価 | 本人・上長・人事以外への露出リスクが高いため |
| 休職、健康、障がい、配慮事項 | 個人情報・プライバシー上のリスクが高いため |
| 異動予定、退職予定 | 公開タイミングの管理が難しいため |
| 採用候補者情報 | 社員プロフィールとは扱いが異なるため |
| 懲戒、労務トラブル | Copilotの検索・要約対象にすべきではないため |
取り込む候補は、まず「業務上の人探しに必要な属性」に限定するのが現実的です。たとえば、部署、勤務地、担当領域、保有資格、公開可能なスキル、参加プロジェクト、社内コミュニティ、言語などです。
プロファイルカード非表示だけで対策したつもりになる
プロフィールカードで表示しない設定にしても、元データがMicrosoft 365プロフィールから削除されるわけではなく、他のMicrosoft 365体験に現れる可能性があります。(Microsoft Learn)
そのため、表示制御はあくまで補助的な対策です。根本的には、取り込むデータ自体を絞る、ACLで可視範囲を限定する、ソースシステムで不要な属性を出力しない、という3段階で考える必要があります。
同期頻度を決めずに運用を始める
Peopleデータは、組織変更、異動、兼務、退職、資格更新、プロジェクト終了などで頻繁に変わります。Microsoftのドキュメントでも、正確で最新のプロフィールを維持するには、ソースシステムとの整合性を保つために定期的なクロールまたは同期を設定する必要があるとされています。(Microsoft Learn)
実務では、属性ごとに同期要件を分けると運用しやすくなります。
| 属性の種類 | 推奨される同期の考え方 |
|---|---|
| 氏名、所属、役職 | 人事マスタ更新に合わせて高頻度で同期 |
| スキル、資格 | 日次または週次で十分な場合が多い |
| プロジェクト参加情報 | 案件管理システムの更新頻度に合わせる |
| 採用・候補者関連 | 原則として社員プロフィールとは分離 |
| 限定公開属性 | 変更時の反映遅延を短く設計する |
管理者向け：権限検証で使えるテスト観点
ACL対応の検証では、単に「Copilotが回答するか」ではなく、「回答してはいけないユーザーに回答しないか」を確認する必要があります。
| テストケース | 確認する内容 |
|---|---|
| 許可されたユーザーで質問する | 対象のPeopleデータが回答に使われるか |
| 許可されていないユーザーで同じ質問をする | 対象者名、属性、根拠が回答に含まれないか |
| グループメンバーを追加する | 追加後、同期タイミングに応じて見えるようになるか |
| グループメンバーを削除する | 削除後、見えていた情報が見えなくなるか |
| deny対象ユーザーで確認する | grantよりdenyが優先されるか |
| プロファイルカードを見る | Copilot回答とプロフィール表示に不整合がないか |
| Microsoft Searchで検索する | Copilotだけでなく検索結果にも過共有がないか |
テスト用プロンプトは、実際の業務に近いものを使うのが効果的です。
例として、許可ユーザーと非許可ユーザーの両方で次のように試します。
関西エリアでAzureセキュリティに詳しい人を探して製造業向けERP案件の経験があるメンバーを候補として挙げて〇〇プロジェクトに参加したことがある人を教えて非許可ユーザーで、対象者の名前や限定属性が出てくる場合は、ACL、外部グループ、プロファイルソース、取り込み属性のいずれかを見直す必要があります。
利用者へ周知すべき内容
Copilot People ConnectorsのACL対応は管理者・開発者向けの機能に見えますが、利用者への説明も欠かせません。特に、Copilotの回答を人事情報の正本として扱わないこと、誤ったプロフィール情報を見つけた場合の申告先、限定情報を引き出そうとするプロンプトの禁止を明確にしておく必要があります。
利用者向けには、次のように伝えると分かりやすくなります。
| 利用者に伝えること | 伝え方の例 |
|---|---|
| Copilotは人物情報を探しやすくする | 「スキルや担当領域から相談相手を探せます」 |
| 回答は権限に基づく | 「自分に閲覧権限のない情報は表示されません」 |
| 情報が古い可能性がある | 「正確性が必要な場合は元システムも確認してください」 |
| 誤りは管理者へ申告する | 「プロフィール情報の修正はソースシステム側で行います」 |
| 機密情報を聞かない | 「評価、給与、健康、労務情報などを尋ねる用途は禁止です」 |
今回の更新で取るべき次のアクション
Microsoft 365 CopilotのCopilot People ConnectorsにおけるPeopleデータのACL対応は、Copilot活用を「文書検索」から「人・スキル・組織知の活用」へ広げる重要な更新です。一方で、Peopleデータは個人情報や人事情報に近いため、展開前の設計が不十分だと過共有リスクが高まります。
まず管理者は、既存のCopilotコネクタとPeopleデータの棚卸しを行い、全社公開できる属性、限定公開すべき属性、取り込まない属性を分類してください。次に開発者は、contentCategory=people、personAccount、プロファイルソース登録、ACL、外部グループ同期の設計を確認します。最後に、許可ユーザーと非許可ユーザーで同じプロンプトを実行し、CopilotとMicrosoft Searchの両方で過共有が起きていないことを検証します。
ロードマップ情報は予定であり、一般提供時期や仕様は変更される可能性があります。Microsoft 365 Roadmap自体も、リリース予定日や説明は変更される可能性があると明記しています。(Microsoft) そのため、2026年8月の一般提供に向けて、今の段階では「すぐ有効化」ではなく「データ分類・権限設計・検証計画」を先に固めるのが最も安全です。
コメント