Microsoft 365 admin centerの「Organizational Data – Granular access policy controls for custom attributes」は、組織データのカスタム属性を、全社員や全マネージャーへ一律公開するのではなく、特定のユーザーやグループに限定して公開できるようにする更新です。人事データ、職種、勤務地、評価区分、スキル、バッジイン回数のような社内固有の属性をMicrosoft 365やWorkforce Insightsで活用している組織では、公開範囲の見直しが必要になります。
今回のポイントは、便利になるというよりも「初期公開を慎重にできる」点です。カスタム属性をいきなり広範囲へ展開せず、対象部門・検証グループ・一部マネージャーから段階的にリリースできます。特に、Microsoft 365 Copilot、Viva、Workforce Insights、組織データ連携を管理している管理者は、カスタム属性の棚卸し、アクセス対象グループ、委任時の非公開データ共有ルールを早めに確認しておくべきです。Microsoftの公式ロードマップAPIでは、この項目はID 564805として登録され、Public Previewは2026年6月、一般提供は2026年7月予定、対象はMicrosoft 365 admin center、Web、Worldwide標準マルチテナントとされています。(Microsoft)
Microsoft 365 admin centerのOrganizational Dataで何が変わるのか
今回の変更は、Microsoft 365のOrganizational Dataに取り込んだカスタム属性のアクセス制御を細かく管理できるようにする機能強化です。
これまでのように「全社員に見せる」「全マネージャーに見せる」といった広い単位だけではなく、管理者が特定のユーザーやグループに対してカスタム属性を公開できるようになります。Microsoftは、この変更により、機密性の高い組織データをより保守的な既定アプローチで扱えるようになり、新しい属性を段階的に展開しやすくなると説明しています。(Microsoft)
変更前と変更後の違い
| 観点 | これまでの運用で起きやすい状態 | 今回の更新後に期待できる運用 |
|---|---|---|
| カスタム属性の公開範囲 | 全社員、全マネージャーなど広い単位になりやすい | 特定ユーザーや特定グループに絞って公開しやすい |
| 新しい属性の展開 | 本番反映時に影響範囲が広がりやすい | パイロットグループから段階展開できる |
| 機密性の高い属性 | 「使いたいが公開が怖い」ため活用が進みにくい | 最小限の対象者から利用開始しやすい |
| Workforce Insightsの委任 | マネージャーやリーダーが委任者へどこまで非公開データを共有できるかが重要になる | 管理者が共有可否をより明確に制御できる |
この機能は、単なる表示設定ではありません。人事データや組織分析データを、誰が、誰の情報として、どの粒度で利用できるかに関わるため、Microsoft 365のデータガバナンス設計そのものに影響します。
そもそもOrganizational Dataとは
Organizational Data in Microsoft 365は、従業員の名前、勤務地、職務、組織階層など、ユーザーを説明する組織・人事系データをMicrosoft 365やMicrosoft Vivaで利用するための仕組みです。Microsoftの説明では、複数のHRISシステムから組織・人事データを取り込み、Microsoft 365 CopilotやMicrosoft 365アプリの各種機能で使えるようにするサービスです。(Microsoft Learn)
Organizational Dataでは、属性は大きく次のように整理できます。
| 属性の種類 | 例 | 実務上の注意点 |
|---|---|---|
| Public attributes | 勤務先メール、名前、役職、部署など | テナント内のユーザーやMicrosoft 365アプリで広く使われる前提で扱う |
| Confidential attributes | 時給、スーパーバイザー区分など | アプリに共有するかどうかを慎重に判断する |
| Custom attributes | バッジイン回数、独自の職種区分、地域ブロック、評価区分など | 組織固有の意味を持つため、命名・説明・公開範囲の設計が重要 |
Microsoft Learnでは、カスタム属性は組織ごとに特別な意味を持つ属性であり、どのアプリがアクセスできるかについてConfidential attributesに近い制御を利用できると説明されています。(Microsoft Learn)
対象になるサービスと影響範囲
公式ロードマップ上の対象製品はMicrosoft 365 admin centerです。対象プラットフォームはWeb、クラウドインスタンスはWorldwide標準マルチテナント、状態はIn development、リリースフェーズはPreviewおよびGeneral Availabilityです。(Microsoft)
実務上、特に影響を受けるのは次の担当者です。
| 対象者 | 影響 |
|---|---|
| Microsoft 365グローバル管理者 | Organizational Dataの設定、アクセス方針、公開範囲の承認が必要になる |
| Organizational Data Source Administrator | データ取り込み、属性管理、アプリへの共有設定、アクセスポリシーの確認が必要になる |
| Viva Insights / Workforce Insights管理者 | 分析に使う属性、委任、マネージャー向け表示範囲の確認が必要になる |
| セキュリティ・コンプライアンス担当 | 個人情報、評価情報、勤務実態データなどの過剰共有リスクを確認する必要がある |
| 開発者・データ連携担当 | HRIS、CSV、API、Azure Blob、Workday、SAP SuccessFactorsなどの連携データ定義を見直す必要がある |
なお、現行のMicrosoft Learnでは、Organizational Data in Microsoft 365のアクセスポリシーを使用するアプリはWorkforce Insightsであり、設定したアクセスポリシーはWorkforce Insightsの体験に影響すると説明されています。(Microsoft Learn) そのため、現時点でまず確認すべき中心はWorkforce Insightsですが、Microsoft 365やViva周辺の組織データ活用全体を前提に棚卸ししておくと安全です。
管理者が最初に確認すべき設定
今回の更新に備えて、管理者は「機能が来たら設定する」ではなく、先にデータと権限の設計を終えておくことが重要です。
カスタム属性の一覧を作る
まず、Organizational Dataに取り込んでいる、または取り込む予定のカスタム属性を一覧化します。
最低限、次の項目を表にしてください。
| 確認項目 | 記入例 |
|---|---|
| 属性名 | WorkLocationType |
| 意味 | 勤務形態を表す社内区分 |
| 値の例 | Remote、Hybrid、Office |
| データ元 | HRシステム、勤怠システム、CSV |
| 利用目的 | Workforce Insightsで部門別の勤務傾向を分析 |
| 機密度 | 社内限定、マネージャー限定、特定部門限定 |
| 公開対象 | 人事部、経営企画、対象部門のマネージャー |
| 委任可否 | マネージャーが委任者へ共有可能か要確認 |
よくある失敗は、カスタム属性名だけを見て判断することです。たとえばBand、Class、Statusのような列名は、開発者や管理者には分かっても、マネージャーや分析担当者には意味が曖昧です。Workforce Insightsでは、カスタム列の名前、説明、データ型、データ品質が重要であり、列名は簡潔で説明的にし、略語や曖昧な用語を避けることが推奨されています。(Microsoft Learn)
公開対象を「役職」ではなく「利用シナリオ」で決める
アクセス制御を設計するときは、「マネージャーだから見せる」「人事だから見せる」と単純化しないほうが安全です。
実務では、次のように利用シナリオから逆算します。
| 利用シナリオ | 公開すべき対象 | 注意点 |
|---|---|---|
| 部門長が自部門の人員構成を把握する | 対象部門のリーダー、必要に応じて委任者 | 他部門の個人レベル情報が見えないようにする |
| 人事企画が職種別の分布を見る | 人事企画グループ | 評価・報酬に近い属性は最小人数に限定する |
| Copilot導入チームが利用傾向を分析する | Copilot推進チーム、IT管理者 | 個人を特定できる粒度での利用目的を明確にする |
| パイロット部門で新しい属性を検証する | パイロット対象グループ | 本番全体公開と混同しないよう命名・記録を残す |
今回の更新で特定ユーザーやグループへの公開が可能になるため、Microsoft 365グループやセキュリティグループの設計も重要になります。属性ごとに個別ユーザーを直接指定し続けると、異動・退職・兼務のたびに運用が破綻しやすくなります。原則として、職務やプロジェクト単位のグループで管理するのが現実的です。
委任時に非公開データを共有してよいか確認する
今回のロードマップでは、管理者が「リーダーやマネージャーが、非公開データをWorkforce Insightsの委任者に共有できるか」を構成できるようになる点も示されています。(Microsoft)
これは見落としやすいポイントです。
たとえば、マネージャーが自分のチーム分析を秘書、部門スタッフ、HRビジネスパートナーに委任するケースがあります。このとき、委任者が単なる代理操作だけでなく、給与帯、勤務区分、離職リスクに近い内部属性まで見られると、想定外の情報共有になる可能性があります。
Workforce Insightsでは、マネージャーやリーダーが委任者を割り当て、チームに関する利用可能な組織データへアクセスさせるシナリオが説明されています。例として、マネージャーが給与のような機密属性にアクセスできる場合、委任者もその列を照会できる可能性があるため、委任の管理は慎重に扱うべきです。(Microsoft Learn)
移行・展開時にやるべきこと
今回の変更は、既存のデータ連携をすぐ壊すタイプの更新ではありません。ただし、放置すると「本来は限定すべき属性が広く使われ続ける」「新しい制御を使わないまま旧来の公開範囲で運用する」といった問題が残ります。
推奨する展開手順
| 手順 | 作業内容 | 判断基準 |
|---|---|---|
| 1 | 取り込み済み属性を棚卸しする | カスタム属性、機密属性、公開属性を分ける |
| 2 | 各属性のデータオーナーを決める | 人事、IT、経営企画など承認者を明確にする |
| 3 | 公開対象グループを設計する | 個人指定ではなく、セキュリティグループやMicrosoft 365グループを使う |
| 4 | パイロット対象を決める | 人事部内、Copilot推進チーム、一部部門長などから始める |
| 5 | 委任時の共有可否を決める | マネージャー本人だけか、委任者にも許可するかを属性ごとに確認する |
| 6 | 本番前に表示・検索・分析結果を確認する | 意図しないユーザーから属性が見えないか検証する |
| 7 | 設定変更履歴を残す | 誰が、いつ、どの属性を、どの対象に公開したか記録する |
特に重要なのは、属性ごとの「使わせたい相手」と「見えてはいけない相手」を両方書き出すことです。アクセス制御は許可リストだけで設計すると抜け漏れが出ます。
CSVやHRIS連携を使っている場合の注意点
Organizational Dataは、CSV、Azure Blob Storage Connector、SAP SuccessFactors、Workday、APIベースのインポートなど複数の取り込み方法に対応しています。(Microsoft Learn)
CSVやHRIS連携を使っている場合は、次の点を確認してください。
| 確認項目 | 理由 |
|---|---|
| カスタム属性の列名が安定しているか | 列名変更でアクセス設定や分析設定が崩れる可能性がある |
| 値の表記ゆれがないか | Sales、sales、SALESのような違いが分析精度を下げる |
| 不要な属性を取り込んでいないか | 使わない機密データを取り込むほど管理リスクが増える |
| データ型が正しいか | 数値・日付・文字列の誤りは集計ミスにつながる |
| 更新頻度が妥当か | 古い組織情報のままでは、異動後のアクセスや分析が不正確になる |
Viva Insightsの組織データ準備では、組織データファイルに含める属性を分析目的に合わせて選び、正しく構造化してアップロードすることが説明されています。また、オプション属性やカスタム属性を使ってフィルターやグループ化を行う場合、必要な人と属性を含めることが重要です。(Microsoft Learn)
開発者・データ連携担当が見るべきポイント
開発者やデータ連携担当にとって、今回の更新はUI上の管理機能だけではありません。HRシステム、ID基盤、Microsoft 365側の属性名、分析アプリの期待値をそろえる必要があります。
属性設計で避けたい失敗
意味が重複する列を増やす
JobRole、RoleName、PositionTypeのように似た列を複数作ると、利用者はどれを使えばよいか分からなくなります。Workforce Insightsのカスタム列ベストプラクティスでも、似た概念を表す複数列は不整合や予測しにくい結果につながるため、統合を検討すべきとされています。(Microsoft Learn)
社内略語をそのまま属性名にする
BU、GEO、WFO、L3Mgrのような略語は、データを作った部署以外には伝わりません。AIや分析エージェントが使う場合も、列の意味が曖昧だと回答品質に影響します。
人事データの粒度を細かくしすぎる
分析には便利でも、個人が特定されやすい小さなグループや希少な属性値は注意が必要です。たとえば「勤務地」「職種」「等級」「雇用形態」を組み合わせると、少人数組織では個人が推測できる場合があります。公開範囲を絞れるようになっても、データ最小化の考え方は必要です。
テストで確認すべき観点
開発者・運用担当は、少なくとも次のテストを行うべきです。
| テスト観点 | 確認内容 |
|---|---|
| 権限テスト | 対象グループのユーザーだけがカスタム属性を使えるか |
| 非対象ユーザーテスト | 権限のないユーザーから属性が見えない、または結果に出ないか |
| 委任テスト | マネージャーが委任した場合、委任者に見える範囲が想定通りか |
| データ更新テスト | 異動・退職・グループ変更後にアクセス範囲が正しく変わるか |
| 属性説明テスト | AIや分析画面で属性の意味が誤解されないか |
| ロールバックテスト | 誤って公開した属性を停止・範囲縮小できるか |
特に、アクセス対象グループのメンバー更新タイミングは要注意です。Microsoft 365グループやセキュリティグループの反映に時間差がある環境では、テスト直後の結果だけで判断しないほうが安全です。
セキュリティとガバナンス上の注意点
今回の更新は、データの活用範囲を広げるための機能であると同時に、過剰共有を防ぐための機能でもあります。便利になったからといって、すべてのカスタム属性を分析対象に加えるべきではありません。
機密度の高いカスタム属性の例
次のような属性は、特に慎重に扱う必要があります。
| 属性例 | リスク |
|---|---|
| 評価ランク、パフォーマンス区分 | 人事評価情報に近く、本人や管理職以外への共有に注意が必要 |
| 給与帯、報酬グレード、時給 | 報酬情報として機密性が高い |
| 退職予定、休職、雇用ステータス | 個人情報・労務情報として扱いに注意が必要 |
| バッジイン回数、出社日数 | 勤務実態の推測につながる |
| スキル、資格、後継者候補 | 人材配置や評価に影響する可能性がある |
| 契約社員、派遣、ベンダー区分 | 利用目的によっては不必要な属性公開になりやすい |
「分析に便利」という理由だけで公開対象を広げると、後から説明が難しくなります。属性ごとに、利用目的、公開対象、保存・更新元、問い合わせ先を明確にしておくことが重要です。
最小権限で始める
今回の機能強化は、まさに最小権限での展開に向いています。
おすすめは、次の順番です。
- 管理者とデータオーナーだけで属性を確認する
- 人事・IT・分析担当の小さなグループに限定公開する
- 一部の部門長やマネージャーでパイロットする
- 利用ログ、問い合わせ、誤解されやすい属性を確認する
- 問題がなければ対象部門を広げる
最初から全社展開すると、属性の意味が誤解されたり、意図しない比較に使われたりする可能性があります。段階展開できるようになること自体が、今回の更新の大きな価値です。
よくある疑問
一般ユーザーにも影響するのか
直接影響するのは、主にWorkforce Insightsなどで組織データを利用するユーザーです。通常のOfficeアプリ利用者全員に、突然新しい画面が表示されるような更新ではありません。
ただし、マネージャー、リーダー、分析担当、委任者としてWorkforce Insightsを使うユーザーには、利用できる属性や見えるデータ範囲が変わる可能性があります。
既存のカスタム属性はすぐに見えなくなるのか
公式ロードマップの説明だけでは、既存属性が自動的に非公開化されるとは読み取れません。今回の趣旨は、管理者がより細かく公開範囲を制御できるようにすることです。
ただし、機能提供後に既定値や管理画面の選択肢が変わる可能性はあります。既存のアクセス設定をそのまま放置せず、公開対象と委任可否を確認してください。
Microsoft 365グループとセキュリティグループのどちらを使うべきか
アクセス制御の目的であれば、一般的にはセキュリティグループのほうが管理しやすいケースが多いです。Microsoft Learnのアクセスポリシー設定でも、オーディエンスをTeams、Microsoft 365グループ、セキュリティグループでフィルターできる旨が説明されています。(Microsoft Learn)
ただし、組織の運用ルールによって最適解は変わります。重要なのは、属性公開のためのグループを一時的・属人的に作らないことです。所有者、命名規則、棚卸し周期を決めておくべきです。
Copilotの回答にも影響するのか
Organizational Dataは、Microsoft 365 CopilotやMicrosoft 365アプリの機能を支えるデータとして使われることがあります。Microsoft Learnでも、Organizational DataはMicrosoft 365 CopilotやMicrosoft 365アプリで各種機能を動かすために使われると説明されています。(Microsoft Learn)
ただし、今回のロードマップ項目で直接説明されているのは、Organizational Dataのカスタム属性に対するアクセス制御と、Workforce Insights delegatesへの非公開データ共有制御です。Copilot全体への影響を断定せず、まずはWorkforce Insightsや組織データを使う機能から確認するのが現実的です。
今すぐやるべき対応まとめ
Microsoft 365 admin centerの「Organizational Data – Granular access policy controls for custom attributes」は、組織データをより安全に活用するための重要な更新です。特にカスタム属性を使っている組織では、公開範囲を細かく制御できるようになる一方、属性設計や委任ルールの曖昧さがそのままリスクになります。
まずは次の4点から着手してください。
- Organizational Dataに取り込んでいるカスタム属性を一覧化する
- 各属性の機密度、利用目的、公開対象、データオーナーを決める
- 特定ユーザー・グループへの段階展開を前提に、検証用グループを用意する
- Workforce Insightsの委任時に、非公開データを共有してよいかルール化する
この更新は、カスタム属性を「より多くの人に見せる」ためではなく、必要な人にだけ、必要な属性を、段階的に使わせるための機能です。公開プレビューの段階から小さく検証し、一般提供前後に本番ポリシーへ反映できるよう準備しておくと、Microsoft 365の組織データ活用を安全に進めやすくなります。
コメント