Microsoft 365 CopilotのCopilot Searchで、ユーザーの「部署（department）」を検索条件として見つけやすくなります。今回の変更により、Copilot SearchでPeopleソースを直接検索したとき、特定の部署に所属する人物を探したり、部署名に一致する人物を一覧しやすくなります。
管理者が最初に確認すべきポイントは、Copilot側の複雑な設定ではなく、Microsoft Entra IDやMicrosoft 365のユーザープロファイルに入っている「department」情報の正確性です。部署名が空欄、表記ゆれ、旧組織名のままになっていると、便利になるどころか「検索結果が信用できない」という状態になりやすい更新です。
Microsoft 365 Roadmap ID 508527の公式情報では、対象製品はMicrosoft Copilot（Microsoft 365）、リリースフェーズはGeneral Availability、GA時期は2026年2月、プラットフォームはWeb、クラウドはWorldwide（Standard Multi-Tenant）、ステータスはLaunchedとされています。公式API上の更新日時は2026-05-15 22:00:42 UTCで、日本時間では2026-05-16の更新に相当します。なお、Microsoft 365ロードマップの情報は変更される可能性があるため、展開状況はテナントごとに確認するのが安全です。(Microsoft)
Microsoft 365 CopilotのCopilot Searchで何が変わるのか
今回の更新は、Microsoft 365 Copilotそのものに新しいチャット回答パターンが追加されるというより、Copilot SearchのPeople検索で「部署」という人物属性を使いやすくする変更です。
従来の人物検索では、名前、メールアドレス、役職、関係性などを手がかりに人を探す場面が中心でした。今回の変更により、「営業企画部の人を探したい」「人事部の担当者を確認したい」といった、部署名を起点にした検索がより実用的になります。
公式説明では、Copilot Searchが人物のdepartmentに一致できるようになり、Peopleソースを直接検索した場合に、特定部署のすべての人物を検索・参照できるとされています。(Microsoft)
| 項目 | 内容 |
|---|---|
| ロードマップID | 508527 |
| 機能名 | Microsoft Copilot (Microsoft 365): Copilot Search Matches on People’s Department |
| 対象サービス | Microsoft 365 Copilot / Copilot Search |
| 変更内容 | People検索で人物のdepartmentに一致できるようになる |
| 主な利用場面 | 部署名から担当者や関係者を探す |
| リリースフェーズ | General Availability |
| GA時期 | 2026年2月 |
| 対象プラットフォーム | Web |
| 対象クラウド | Worldwide（Standard Multi-Tenant） |
| ステータス | Launched |
利用者にとっての影響
利用者にとって分かりやすい変化は、「人の名前を知らなくても、部署名から人を探しやすくなる」ことです。
たとえば、次のような場面で役立ちます。
| 利用シーン | 検索例 | 期待できる効果 |
|---|---|---|
| 部署の担当者を探す | 「法務部」 | 法務部に所属する人物を探しやすい |
| 横断プロジェクトの関係者を確認する | 「マーケティング部」 | 部署単位で関係者候補を把握しやすい |
| 新入社員が問い合わせ先を探す | 「情報システム部」 | 名前を知らなくても連絡先を見つけやすい |
| 他部門との連携先を探す | 「営業企画」 | 部署名を手がかりに候補者を絞り込める |
Microsoft 365 Copilot Searchは、Microsoft 365 Copilotアプリに統合された検索モジュールで、Microsoft 365やサードパーティデータソースを横断して探すためのユニバーサル検索として説明されています。対象ライセンスを持つユーザーはMicrosoft 365 Copilotアプリから利用でき、管理者やユーザーがCopilot Search自体を個別設定する必要はないとされています。(Microsoft Learn)
ただし、利用者に案内する際は「部署名で何でも正確に探せる」と言い切らないほうが安全です。検索結果はユーザープロファイルの登録内容に依存します。部署名が「営業部」「営業本部」「Sales」「Sales Dept.」のように分かれていると、期待した一覧にならない可能性があります。
管理者が最優先で確認すべき設定
今回の変更で最も重要なのは、Copilotの管理画面を探し回ることではありません。確認すべき中心は、ユーザー属性のdepartmentが正しく管理されているかです。
Microsoft Graphのuserリソースでは、departmentは「ユーザーが働いている部署の名前」と説明され、最大64文字の文字列として定義されています。また、取得には$selectが必要で、$filterによる条件指定にも対応しています。(Microsoft Learn)
部署名の表記ゆれを洗い出す
まず、同じ部署を複数の表記で登録していないか確認します。Copilot Searchがdepartmentに一致できるようになっても、元データに表記ゆれがあれば検索体験は不安定になります。
| 悪い例 | 問題点 | 改善例 |
|---|---|---|
| 営業部 / 営業本部 / Sales | 同じ組織なのか別組織なのか判断しにくい | 国内営業部、法人営業部など正式名称に統一 |
| 情シス / 情報システム / IT | 利用者がどの名称で検索すべきか分からない | 情報システム部に統一し、略称は社内説明で補う |
| HR / 人事 / 人事総務 | グローバル表記と日本語表記が混在する | 人事部、HR Japanなど運用ルールを決める |
| 旧部署名のまま | 異動後も古い検索結果に出る | 人事マスターやEntra ID同期を見直す |
特に大企業では、正式な組織名と現場で使われる略称が違うことがあります。検索しやすさだけを考えると略称を入れたくなりますが、departmentは他のシステムでも参照される可能性があるため、まずは正式名称を基準にするのが無難です。
空欄や古い部署名のユーザーを確認する
次に、departmentが空欄のユーザーや、退職者・異動者・兼務者の扱いを確認します。空欄のままでは部署検索に出にくくなります。古い部署名のまま残っていると、利用者が誤った連絡先にたどり着く可能性があります。
確認対象は、少なくとも次のユーザーです。
- 正社員
- 契約社員や業務委託など、社内ディレクトリに表示されるユーザー
- 共有アカウントに近い運用をしているユーザー
- 退職予定者、休職者、異動直後のユーザー
- ゲストユーザーや外部ユーザー
ゲストユーザーや外部協力会社のアカウントに部署名を入れる場合は、社内の部署名と混同されないルールが必要です。たとえば、外部ユーザーに「営業部」とだけ入れると、社内の営業部メンバーと同じように見えてしまう可能性があります。
Microsoft 365管理センター、Entra ID、同期元のどこで管理しているか確認する
クラウドIDを使っている組織では、Microsoft Entra IDにユーザーアカウントが格納され、Microsoft 365管理センターの多くのユーザープロファイル情報を管理できます。一方、SharePointのカスタムユーザープロファイルプロパティはMicrosoft Entra IDに同期されないと説明されています。(Microsoft Learn)
つまり、SharePointの独自プロパティや社内ポータルだけに部署情報を持たせている場合、今回のCopilot Searchのdepartment一致にそのまま使われるとは限りません。部署情報の正本がどこにあるかを確認し、Microsoft 365側の標準的なユーザー属性と整合させることが重要です。
管理者向けの確認手順
展開前後に、次の順序で確認すると失敗しにくくなります。
| 手順 | 確認内容 | 判断基準 |
|---|---|---|
| 1 | 対象ユーザーのライセンス | Microsoft 365 Copilotの対象ライセンスを持っているか |
| 2 | 対象環境 | Worldwide（Standard Multi-Tenant）か |
| 3 | departmentの入力状況 | 空欄、旧部署名、表記ゆれが多くないか |
| 4 | 検索テスト | Peopleソースで部署名検索したとき、期待する人物が出るか |
| 5 | 利用者案内 | 部署名検索の使い方と限界を周知できているか |
| 6 | 運用ルール | 異動、組織改編、退職時にdepartmentが更新されるか |
PowerShellでdepartmentを棚卸しする例
Microsoft Graph PowerShellを使うと、ユーザーのdepartmentを一覧化して確認できます。実行には組織の権限設計に応じた適切なMicrosoft Graph権限が必要です。
Connect-MgGraph -Scopes "User.Read.All"
Get-MgUser -All -Property Id,DisplayName,UserPrincipalName,Department,JobTitle,AccountEnabled |
Select-Object DisplayName,UserPrincipalName,Department,JobTitle,AccountEnabled |
Sort-Object Department,DisplayName |
Export-Csv ".\users-department-audit.csv" -NoTypeInformation -Encoding UTF8出力したCSVでは、次の観点で確認します。
Departmentが空欄のユーザーがいないか- 同じ部署なのに表記が複数に分かれていないか
- 退職者や無効化済みアカウントが検索対象として残っていないか
- 役職や勤務地と矛盾する部署名になっていないか
- 外部ユーザーに社内部署と同じ名称を付けていないか
一括修正する場合は、いきなり全社に適用せず、少数ユーザーでテストしてから実施してください。部署名は検索だけでなく、アドレス帳、組織図、ワークフロー、権限設計、レポートにも影響する可能性があります。
開発者が確認すべきポイント
開発者にとって今回の更新は、Copilot Searchの画面上の改善に見えますが、実務上はユーザープロファイル連携の設計見直しにつながります。
社内アプリ、社員検索、ワークフロー、CRM、問い合わせ管理などで部署情報を扱っている場合、Microsoft 365側のdepartmentとアプリ側の部署名が一致しているか確認してください。
Microsoft Graphで部署別ユーザーを取得する例
Microsoft Graphのuserリソースでは、departmentは$selectと$filterで扱える属性です。部署別の人物一覧を自社アプリで取得している場合、次のような考え方で確認できます。(Microsoft Learn)
GET https://graph.microsoft.com/v1.0/users?$select=id,displayName,userPrincipalName,department&$filter=department eq '営業部'開発者が注意すべき点は、Copilot Searchの検索体験と、Microsoft Graph APIの検索・フィルター結果を同一視しすぎないことです。Graph APIはアプリのデータ取得に使えますが、Copilot Searchのランキング、表示順、PeopleソースのUI挙動は別の検索体験として扱うべきです。
カスタム属性だけに部署情報を持たせている場合は要注意
社内システムによっては、部署コードや組織階層をextensionAttribute、カスタムセキュリティ属性、SharePointのカスタムユーザープロファイルプロパティ、独自データベースで管理していることがあります。
今回の更新で対象になるのは、公式説明上「person’s department」です。独自の「部門コード」「本部名」「兼務部署」「原価センター」がすべてCopilot SearchのPeople検索で同じように使えると考えるのは危険です。
実務では、次のように役割を分けると運用しやすくなります。
| データ | 主な用途 | 運用の考え方 |
|---|---|---|
| department | ユーザーが所属する部署名 | 人が見て分かる正式名称を入れる |
| 部署コード | 基幹システム、ワークフロー、会計連携 | コード体系として別管理する |
| 兼務情報 | 組織図、人事管理 | departmentだけで表現しきれない場合は別属性で管理する |
| 表示用の略称 | 社内ポータル、案内ページ | 検索補助として使い、標準属性と混同しない |
| SharePointカスタムプロパティ | 独自プロフィール情報 | Entra IDと同期されない点に注意する |
セキュリティとプライバシー面の注意点
Copilot SearchはMicrosoft 365 Copilotと同じデータ保護、プライバシー標準、セキュリティ構成に準拠すると説明されています。また、Microsoft 365 Copilotはユーザーがアクセス許可を持っているデータのみを表示するとされています。(Microsoft Learn)
ただし、部署名は多くの組織で「誰でも見られる基本プロフィール」として扱われがちです。検索しやすくなるということは、裏を返せば、機微な部署名やプロジェクト名が見つかりやすくなる可能性もあります。
たとえば、次のようなdepartment名は慎重に扱うべきです。
- M&A準備室
- 組織再編プロジェクト
- 内部監査特命チーム
- 懲戒調査担当
- 早期退職プログラム事務局
- 未発表の新規事業名
こうした名称をdepartmentに直接入れると、部署検索によって意図せず存在が推測される可能性があります。機密性の高い組織や一時的なプロジェクトは、正式な公開可否、表示名、グループ管理、権限設計を分けて検討してください。
移行・展開時に失敗しやすいポイント
今回の変更は、アプリの大規模移行が必要なタイプの更新ではありません。しかし、ユーザープロファイルが未整備のまま展開されると、利用者の信頼を落としやすい更新です。
組織改編直後に検索結果が混乱する
組織改編の直後は、部署名が旧名称と新名称で混在しがちです。この状態でCopilot Searchの部署検索を使うと、「新しい部署名で検索しても一部の人が出ない」「旧部署名の人が残っている」という問い合わせが増えます。
対策として、組織改編の作業リストにdepartment更新を含めてください。人事マスター、Entra ID、Microsoft 365、社内ポータル、ワークフローの更新タイミングをそろえることが重要です。
部署階層をdepartmentだけで表現しようとする
departmentは部署名の文字列です。部、本部、課、チーム、拠点、兼務をすべて1つの項目に詰め込むと、検索しにくくなります。
悪い例は次のような値です。
営業本部/東日本営業部/第一営業課/兼務:新規開拓チームこのような文字列は一見詳しく見えますが、検索、表示、メンテナンスのすべてで扱いにくくなります。departmentには利用者が人を探すときに使う主要な所属名を入れ、階層や兼務は別の属性や人事システムで管理するほうが実務的です。
日本語名と英語名のルールが決まっていない
グローバル企業では、日本語の部署名と英語の部署名が混在しやすくなります。日本のユーザーは「人事部」で探し、海外のユーザーは「HR」で探すかもしれません。
この場合、どちらをdepartmentの正とするかを決める必要があります。日本法人だけで使うなら日本語正式名称、グローバル共通ディレクトリなら英語正式名称、または「HR Japan」のようなルールを採用するなど、利用者の検索行動に合わせて設計します。
検索結果の反映に時間差があることを説明していない
ユーザープロファイルを修正しても、検索体験に即時反映されるとは限りません。Microsoft 365の検索やインデックスは、サービス側の処理タイミングに影響されます。
管理者は「変更したのに出ない」という問い合わせに備え、反映確認のタイミングを決めておくとよいでしょう。たとえば、変更直後、数時間後、翌営業日など、段階的に確認する運用にすると切り分けしやすくなります。
利用者への案内文の例
全社展開時は、難しい技術説明よりも「何ができるようになったか」を短く伝えるほうが効果的です。
Microsoft 365 CopilotのCopilot Searchで、部署名から社員を探しやすくなりました。
Copilot SearchのPeople検索で「人事部」「営業企画部」などの部署名を入力すると、その部署に所属する人物を探せます。
検索結果はMicrosoft 365に登録されている部署情報をもとに表示されます。
部署名が古い、該当者が見つからない、異動後の情報が反映されていない場合は、情報システム部または人事部まで連絡してください。案内時は、次の一言を加えると問い合わせを減らせます。
部署名の表記は正式名称で検索してください。略称では期待した結果にならない場合があります。管理者・開発者向けチェックリスト
公開前後に確認すべき項目を整理すると、次のようになります。
| 対象 | チェック項目 | 優先度 |
|---|---|---|
| Microsoft 365管理者 | Microsoft 365 Copilotライセンスの対象ユーザーを確認する | 高 |
| Microsoft 365管理者 | Copilot Searchが利用できるユーザー範囲を確認する | 高 |
| Entra ID管理者 | departmentの空欄、旧名称、表記ゆれを棚卸しする | 高 |
| 人事・総務 | 正式な部署名ルールを決める | 高 |
| セキュリティ担当 | 機微な部署名を公開プロフィールに入れていないか確認する | 高 |
| 開発者 | 社内アプリの部署名とMicrosoft 365側のdepartmentを照合する | 中 |
| 開発者 | Graph APIで部署別ユーザーを取得している処理を確認する | 中 |
| ヘルプデスク | 「部署検索で見つからない」問い合わせの一次切り分けを用意する | 中 |
| 利用部門 | 正式部署名で検索する運用を周知する | 中 |
この更新で「できること」と「できないこと」
最後に、誤解しやすい点を整理します。
| 区分 | 内容 |
|---|---|
| できること | Peopleソースを直接検索したとき、部署名を手がかりに人物を探しやすくなる |
| できること | 名前を知らない相手でも、部署名から候補者を見つけやすくなる |
| できること | 新入社員や他部門連携の問い合わせ先探しを効率化できる |
| できないこと | departmentが未設定のユーザーを正しく部署検索に出すこと |
| できないこと | 表記ゆれや旧部署名を自動的に完全解消すること |
| できないこと | 組織階層、兼務、プロジェクト所属をdepartmentだけで正確に表現すること |
| できないこと | 独自属性や社内DBの部署情報が自動的にPeople検索のdepartment一致として扱われると断定すること |
まず実施すべきこと
今回の「Copilot Search Matches on People’s Department」は、利用者から見ると小さな検索改善に見えるかもしれません。しかし、管理者にとっては、Microsoft 365 Copilot時代にユーザープロファイルの品質がそのまま検索体験に影響することを示す重要な更新です。
最初に行うべきことは、対象テナントでCopilot SearchのPeople検索を確認し、代表的な部署名で検索テストを行うことです。そのうえで、departmentの空欄、表記ゆれ、旧組織名、機微な部署名を洗い出してください。
Copilotの検索精度を上げる近道は、プロンプトの工夫だけではありません。人、部署、役職、組織情報を正しく整えることが、Microsoft 365 Copilotを実務で使える状態にする土台になります。
コメント