Outlookのプロファイルカードに、組織独自のカスタムプロパティを表示できるようになる見込みです。これにより、メールや予定表で相手を確認するときに、部署・役職だけでなく、HRシステムなどにある社内固有の情報も確認しやすくなります。ポイントは、単に項目が増えることではありません。管理者が「何を表示するか」「どのシステムを正とするか」「誰に見えてよい情報か」を事前に決めておく必要があります。
Microsoft 365 Roadmap ID 529851では、対象サービスはOutlook、対象プラットフォームはWeb、提供リングはGeneral Availability、提供時期は2026年7月予定とされています。情報は2026年6月2日23:00 UTCに更新されており、日本時間では2026年6月3日の更新情報として扱えます。なお、Microsoft 365 Roadmapの提供時期や内容は変更される可能性があります。(Microsoft) (Microsoft)
Outlookのプロファイルカードで何が変わるのか
今回の「Outlook: Enriching profile cards with custom, organization-specific properties」は、Microsoft 365のプロファイルカードに、組織固有のカスタムプロパティを追加できるようにする変更です。
従来のプロファイルカードは、氏名、メールアドレス、役職、部署、会社名、勤務先電話番号など、Microsoft 365やMicrosoft Entra IDにある標準的なユーザー情報を中心に表示していました。今回の変更では、HRプラットフォームなど外部システムから取得した組織固有の情報を、Outlookのプロファイルカードに表示できるようになります。
Microsoftの説明では、テナント管理者が表示名とアイコンを設定でき、追加したプロパティはプロファイルカードのContact Informationセクションに表示されるとされています。(Microsoft)
たとえば、次のような情報を表示する用途が考えられます。
| 表示項目の例 | 使える場面 | 注意点 |
|---|---|---|
| コストセンター | 承認依頼や部門横断プロジェクトで所属管理単位を確認する | 経理・人事上の扱いを確認する |
| 従業員区分 | 正社員、契約社員、派遣、外部パートナーなどの把握 | 差別的な扱いにつながらない表示名にする |
| 担当製品・担当領域 | 問い合わせ先やレビュー依頼先を探す | 最新性が重要。異動後に古い情報が残ると逆効果 |
| 拠点コード・リージョン | グローバル組織で拠点を判別する | 住所や詳細所在地を出しすぎない |
| 資格・認定・スキル | セキュリティ、法務、技術レビューの相談先を探す | 本人申告情報か公式認定情報かを明確にする |
重要なのは、「表示できる情報が増える」こと自体よりも、Outlook上で相手の文脈を素早く理解できるようになる点です。メールを送る前、会議に招待する前、問い合わせ先を探すときに、プロフィール情報が判断材料になります。
対象範囲はOutlook on the webが中心
Roadmap ID 529851では、対象製品はOutlook、プラットフォームはWeb、クラウド環境はWorldwide Standard Multi-Tenantとされています。(Microsoft)
現時点で注意したいのは、「Outlook」と書かれていても、すべてのOutlookクライアントで同じタイミング・同じ見え方になるとは限らないことです。クラシックOutlook for Windows、新しいOutlook for Windows、Outlook on the web、Outlook for Mac、モバイル版Outlookでは、機能の展開時期や表示仕様が異なる場合があります。
管理者は、まずOutlook on the webで検証し、社内でよく使われているクライアントごとに表示確認するのが安全です。
| 確認対象 | 見るべきポイント |
|---|---|
| Outlook on the web | カスタムプロパティがContact Informationに表示されるか |
| 新しいOutlook for Windows | Web版と同じ表示になるか |
| クラシックOutlook for Windows | 表示されない、または差異が出る前提で確認する |
| Teams、SharePoint、OneDriveなど | 同じプロファイル情報が別サービスにも影響するか |
| モバイル版Outlook | 画面幅が狭い場合の見え方、項目の折り返し、表示優先度 |
プロファイルカードはOutlookだけで完結する情報ではありません。Microsoft 365のユーザープロファイルやPeople関連の体験とつながるため、Outlookでの表示確認だけでなく、Microsoft 365全体での見え方を確認する必要があります。
既存のプロファイルカード設定との違い
Microsoft 365のプロファイルカードには、すでに標準プロパティと任意表示のプロパティがあります。Microsoft Learnでは、プロファイルカードのプロパティはMicrosoft 365プロファイルリソースの属性にマップされ、Microsoft Entra ID、Microsoft 365の組織データ、Microsoft 365 Copilot connectors for people data、ユーザー入力情報などから設定されると説明されています。(Microsoft Learn)
既定で表示される代表的なプロパティには、氏名、メール、チャット、勤務先電話番号、会社名、役職、部署、勤務先住所などがあります。これらはデータがある場合に表示され、管理者が非表示にできないものもあります。(Microsoft Learn)
一方、任意表示のプロパティとしては、Division、Role、Employee number、Employee type、Cost center、User principal name、Alias、Fax、Street address、State、Postal codeなどが挙げられています。これらは既定では非表示で、Microsoft 365管理センターの「Settings > Org settings > People settings > Profile card > Contact info」から表示・非表示を構成できます。変更の反映には最大24時間かかる場合があります。(Microsoft Learn)
今回の変更で注目すべきなのは、組織固有の情報を外部システムから取り込み、表示名やアイコンを設定してプロファイルカードに出せる点です。標準項目をオンにするだけでなく、自社の業務に合わせた「見せるべき人物情報」を設計する段階に入ると考えると分かりやすいでしょう。
管理者がまず確認すべきこと
管理者が最初にやるべきことは、設定画面を開くことではありません。まず「何を表示すべきか」「なぜ表示するのか」「誰がそのデータの責任者か」を決めることです。
表示する項目を業務シーンから逆算する
プロファイルカードは、ユーザー名簿ではなく、日常業務の中で相手を理解するための補助情報です。そのため、表示項目は「あると便利そう」ではなく、実際の業務判断に使うものに絞るべきです。
判断基準は次の3つです。
| 判断基準 | 採用してよい例 | 採用を慎重にすべき例 |
|---|---|---|
| 業務上の必要性 | 承認ルート、担当領域、拠点、役割 | 興味本位で見るだけの属性 |
| 最新性を維持できるか | HRシステムで定期更新される項目 | 手作業で更新されず古くなりやすい項目 |
| 全社に見えて問題ないか | 公開前提の部署コード、担当領域 | 評価情報、給与等級、個人事情に関わる情報 |
特に避けたいのは、HRシステムにある項目をそのまま表示候補にすることです。人事データには、プロファイルカードで全社に見せるべきではない情報が含まれることがあります。
管理者ロールを確認する
Microsoft Learnでは、プロファイルカードの構成にはグローバル管理者またはPeople管理者の権限が必要とされています。(Microsoft Learn)
一方、People data connectorsの構成には、グローバル管理者またはCopilot管理者ロールが必要とされています。(Microsoft Learn)
実務では、次のように役割分担すると進めやすくなります。
| 担当 | 主な役割 |
|---|---|
| Microsoft 365管理者 | プロファイルカード表示設定、Microsoft 365管理センターでの確認 |
| Entra ID管理者 | ユーザー属性、ID、同期状態の確認 |
| HRシステム管理者 | 人事データの正確性、更新タイミング、項目定義の確認 |
| セキュリティ・法務・人事 | 表示してよい情報、プライバシー、社内規程との整合性確認 |
| 開発者・連携担当 | Microsoft Graph、People data connector、データマッピングの実装 |
小規模テナントでは1人が複数の役割を兼ねることもありますが、表示項目の決定だけはIT部門だけで完結させないほうが安全です。
外部システム連携で確認すべきポイント
今回の機能は、HRプラットフォームなど外部システムの情報を活用できる点が大きな特徴です。Microsoft Learnでは、people data connectorsを使うことで、HR、採用、タレント管理、その他の人物情報システムからMicrosoft 365に権威ある人物情報を取り込み、Microsoft 365 Copilot、Microsoft Search、プロファイルカード、Org Explorerなどでより有用な人物コンテキストを表示できると説明されています。(Microsoft Learn)
ソースシステムを「正」として扱う
People data connectorsは、外部システムをMicrosoft 365に置き換えるものではありません。Microsoft Learnでは、外部ソースはそのデータの権威あるシステムとして残り、Microsoft 365はよりよい人物コンテキストを表示するために利用すると説明されています。(Microsoft Learn)
つまり、Outlook側で情報を直すのではなく、元データを持つHRシステムや人材管理システムを正しく保つ運用が必要です。
たとえば、従業員の担当領域が変わったのにHRシステム側が更新されていなければ、Outlookのプロファイルカードにも古い情報が表示される可能性があります。問い合わせ先の誤認や承認依頼の遅延につながるため、更新頻度と責任者を決めておきましょう。
複数ソースの優先順位を決める
Microsoft 365では、Microsoft Entra ID、Microsoft 365の組織データ、People data connectors、ユーザー入力情報など、複数のソースが同じプロフィール項目を持つ可能性があります。この場合、どのソースを優先するかを決める必要があります。
Microsoft Learnでは、複数ソースが同じプロファイル情報を提供する場合、管理者はソースの優先順位を設定して、Microsoft 365が期待どおりに最終プロファイルを構成できると説明されています。(Microsoft Learn)
たとえば、役職情報がEntra IDでは「Manager」、HRシステムでは「Senior Manager」となっている場合、どちらを表示するかを決めておかなければ、ユーザーから「表示が違う」という問い合わせが発生します。
開発者が確認すべきMicrosoft Graph関連の注意点
開発者や連携担当者は、Microsoft Graphの既存APIと今回のPeople data connectorの考え方を混同しないようにする必要があります。
People data connectorではスキーマ設計が重要
Microsoft Learnでは、people data connectorを構築する場合、Microsoft Graph external connections APIを使用し、接続が人物データを含むことをMicrosoft 365に認識させるために、接続構成・スキーマ要件・プロファイルデータソースとしての登録が必要とされています。(Microsoft Learn)
スキーマでは、対象ユーザーにマッピングするためにpersonAccountラベルを持つプロパティが必要です。また、ラベルが付いていないプロパティはカスタムプロパティとして扱われます。(Microsoft Learn)
実装時は、次の点を確認してください。
| 確認項目 | 実務上のポイント |
|---|---|
| ユーザー識別子 | UPNや外部ディレクトリIDで正しく対象ユーザーに紐づくか |
| スキーマ名 | reqIdのような社内略称ではなく、意味が分かる名前にする |
| 説明文 | 管理者・将来の保守担当者が理解できる説明を付ける |
| データ型 | 文字列、文字列コレクション、JSONシリアライズ形式などの要件を確認する |
| 同期頻度 | HRシステムの更新タイミングとMicrosoft 365側への反映タイミングを合わせる |
| 登録と優先順位 | コネクタ作成後、プロファイルソースとして登録し、優先順位に追加する |
Microsoft Learnでは、カスタムプロパティ名はユーザーやエージェントが理解できる名前にし、複雑なカスタムプロパティではJSONよりも自由記述、Markdown、YAMLの利用を推奨しています。(Microsoft Learn)
既存のprofileCardProperty APIとの違いを理解する
Microsoft Graphには、プロファイルカードにMicrosoft Entra IDの属性やカスタム拡張属性を追加するための既存APIもあります。Microsoft Learnでは、Microsoft Entra IDの15個のカスタム拡張属性をプロファイルカードに追加でき、変更の反映には最大24時間かかるとされています。また、この方法で追加したカスタムプロパティは検索には使えないと説明されています。(Microsoft Learn)
今回のRoadmap項目は、外部システム由来の組織固有プロパティをプロファイルカードに表示する流れと関係します。すでにEntra IDのextensionAttributeを使ってプロファイルカードを拡張している組織は、次のように整理するとよいでしょう。
| 現在の方式 | 向いている用途 | 注意点 |
|---|---|---|
| Entra IDの標準属性 | 役職、部署、電話番号など基本情報 | 既存のID同期設計に影響する |
| Entra IDの拡張属性 | 少数の社内属性を簡易的に表示 | 属性数や検索利用に制約がある |
| Organizational Data in Microsoft 365 | 組織データをMicrosoft 365体験に広く活用 | データ優先順位と更新運用が重要 |
| People data connector | HR・タレント管理など外部システムの情報を取り込む | スキーマ、権限、可視性、同期設計が必要 |
既存の仕組みをすぐ置き換えるのではなく、どの情報をどの経路で持つべきかを棚卸しすることが重要です。
セキュリティとプライバシーの注意点
プロファイルカードは、ユーザーが日常的に見る情報です。便利になる一方で、過剰な個人情報や内部情報を表示してしまうリスクがあります。
Microsoft Learnでは、Copilot connector経由で提供される人物データは既定でテナント内のすべてのユーザーに表示され、ユーザーのMicrosoft 365プロファイルに保存されると説明されています。(Microsoft Learn)
そのため、次のような項目は特に慎重に扱うべきです。
- 人事評価、等級、給与レンジに関係する情報
- 健康状態、配慮事項、家族情報などのセンシティブ情報
- 契約条件や雇用上の詳細が推測される情報
- セキュリティ権限や内部統制上の役割が過度に分かる情報
- 外部パートナーに見せるべきではない内部コード
また、プロパティを非表示にしても、基になるデータがMicrosoft 365プロファイルから削除されるわけではありません。データを完全に削除するには、管理者がソースシステム側から削除する必要があるとされています。(Microsoft Learn)
「表示しないから安全」と考えるのではなく、そもそもMicrosoft 365に取り込むべきデータかどうかを判断してください。
展開前のチェックリスト
本番展開前には、設定作業よりも先にデータと運用を確認します。特に大企業やグループ会社を含むテナントでは、部門ごとに項目定義が異なることがあるため、パイロット展開を強くおすすめします。
| フェーズ | 確認すること | 失敗しやすいポイント |
|---|---|---|
| 企画 | 表示する項目と目的を決める | 「あれば便利」で項目が増えすぎる |
| データ棚卸し | どのシステムが正しい値を持つか確認する | Entra IDとHRシステムで値が食い違う |
| リスク確認 | 全社表示してよい情報か確認する | 人事・法務レビューを省略する |
| 技術設計 | コネクタ、スキーマ、ユーザー紐づけを設計する | UPN変更やゲストユーザーを考慮しない |
| 表示設計 | 表示名、アイコン、日本語表記を決める | 社内略語が多く、一般ユーザーに伝わらない |
| パイロット | 一部部門で表示と問い合わせを確認する | 管理者アカウントだけで確認してしまう |
| 展開 | ヘルプデスク向けFAQを用意する | 「間違っている情報をどこに連絡するか」が不明 |
| 運用 | 同期頻度、変更申請、削除手順を定める | 異動・退職・兼務の更新漏れが起きる |
展開時は、社内アナウンスで「プロファイルカードに表示される情報の修正依頼先」を明確にしてください。ユーザーがOutlook上で見つけた誤情報を、IT部門、人事部門、所属長のどこに連絡すべきか分からないと、問い合わせが分散します。
表示名とアイコンはユーザー目線で設計する
今回のRoadmap説明では、テナント管理者が表示名とアイコンを構成できるとされています。(Microsoft)
表示名は、社内システムの項目名をそのまま使わないほうがよい場合があります。たとえば、HRシステム上のempTypeCdやcostCtrのような名前をそのまま出すと、一般ユーザーには意味が伝わりません。
おすすめは、次のような変換です。
| システム上の項目名 | 表示名の例 | 理由 |
|---|---|---|
costCtr | コストセンター | 一般的な業務用語として理解しやすい |
empTypeCd | 従業員区分 | コード名ではなく意味を表示できる |
bizUnit | 事業部門 | 部門・部署との違いが分かりやすい |
productOwnerArea | 担当製品領域 | 問い合わせ先判断に使いやすい |
workRegion | 勤務リージョン | グローバル組織でも意味が伝わる |
日本語環境では、英語表示名だけでなく、日本語表示名が必要かも検討してください。グローバル企業では、英語名を標準にしつつ、日本国内向けに日本語の説明を社内ポータルやFAQに用意する方法もあります。
よくある疑問
Outlookのプロファイルカードに表示すると、ユーザーが自由に編集できるのか
外部システム由来の情報は、基本的に元システムで管理する前提です。Microsoft Learnでは、プロファイルカードの情報が誤っている場合、ユーザーはプロファイルカードデータをエクスポートしてソースIDを確認し、管理者に連絡し、管理者がソースシステム側を更新すると説明されています。(Microsoft Learn)
ユーザーがOutlook上で直接編集できる項目と、管理者または外部システムで管理する項目を分けて説明しておく必要があります。
変更はすぐ反映されるのか
既存のプロファイルカード設定では、表示変更が反映されるまで最大24時間かかる場合があります。(Microsoft Learn)
また、People data connectorで取り込む情報については、コネクタのクロールや同期スケジュールにも影響されます。Microsoft Learnでは、正確で最新のプロファイルを維持するため、管理者が定期的なクロールや同期を設定することを推奨しています。(Microsoft Learn)
そのため、検証時には「設定直後に見えない＝失敗」と判断せず、反映時間と同期タイミングを確認してください。
すべての情報をプロファイルカードに出すべきか
出すべきではありません。プロファイルカードは、相手を理解し、仕事を進めるための最小限の情報に絞るべきです。
特に、評価、給与、個別事情、内部統制上の機密ロールなどは、表示による利便性よりもリスクが上回る可能性があります。表示項目は、人事・法務・セキュリティの確認を経て決めるのが安全です。
既存のEntra ID拡張属性は不要になるのか
すぐ不要になるとは限りません。Entra ID拡張属性で十分な項目もあります。一方、HRシステムやタレント管理システムの情報を継続的に取り込みたい場合は、People data connectorのほうが適しているケースがあります。
判断基準は、「その情報の正本がどこにあるか」です。Entra IDが正本なら既存属性を活用し、HRシステムが正本なら外部システム連携を検討する、という考え方が実務的です。
管理者・開発者が取るべき次の行動
今回のOutlookプロファイルカード拡張は、ユーザーにとっては「相手の情報が見やすくなる」変更ですが、管理者や開発者にとっては、人物データのガバナンスを見直すきっかけになります。
まずは、次の順番で準備してください。
| 優先度 | やること |
|---|---|
| 高 | Microsoft 365 Roadmap ID 529851と自社テナントのMessage Center通知を確認する |
| 高 | 表示候補の項目を洗い出し、全社表示してよいか確認する |
| 高 | Entra ID、HRシステム、組織データ、People data connectorのどれを正本にするか決める |
| 中 | Microsoft 365管理センターのPeople settingsとProfile card設定を確認する |
| 中 | パイロット部門を決め、Outlook on the webで表示を検証する |
| 中 | 表示名、アイコン、日本語表記、社内FAQを整備する |
| 低 | 既存のEntra ID拡張属性やGraph API設定との整理・統合方針を決める |
最初から全社展開するよりも、情報の価値が分かりやすい部門で小さく試すほうが安全です。たとえば、サポート部門、営業部門、プロジェクト管理部門など、相手の担当領域や役割を素早く知るメリットが大きい部署から検証すると、効果と課題が見えやすくなります。
Outlookのプロファイルカードは、ただの連絡先表示ではなく、Microsoft 365上の人物情報を活用する入口です。今回の変更を機に、表示する情報、更新する仕組み、削除する手順、問い合わせ対応まで含めて整備しておきましょう。
コメント