Copilot の導入状況を見たいのに、全社平均しか出せない。これでは、必要な打ち手が「全社研修を増やす」くらいにしかならず、現場では役に立ちにくいです。2026年4月7日に Microsoft が公開したロードマップ項目 559995 は、Viva の Copilot 分析で使う Power BI レポートに対し、Global 管理者と Insights 管理者が reserved attributes と custom attributes を追加フィルターとして有効化できるようにするものです。Power BI レポートにアクセスできる利用者は、その新しいフィルターでレポートを自社の業務要件に合わせて絞り込めるようになる、と案内されています。(Microsoft)
この更新が重要なのは、Copilot 導入を「全社で何％使われているか」ではなく、「どの部門・職種・階層・拠点・独自セグメントで定着しているか」で見られるようになるからです。ロードマップ上では 2026年4月7日時点で In development、時期の目安は 2026年5月 とされており、Microsoft 365 Roadmap の情報は変更される可能性があります。(Microsoft)
Viva の Copilot の洞察がさらに深くなる Power BI フィルタリングで何が変わるか
まず、今回の発表内容を整理すると次の通りです。(Microsoft)
| 項目 | 内容 |
|---|---|
| ロードマップ ID | 559995 |
| 発表日 | 2026年4月7日 |
| 発表内容 | Global / Insights 管理者が、reserved attributes と custom attributes を Power BI レポートの追加フィルターとして有効化できるようにする |
| 想定利用者 | Power BI レポートにアクセスできるユーザー |
| 状態 | In development |
| ロードマップ上の時期 | 2026年5月 |
| 対象 | Worldwide（標準マルチテナント）/ Web / Microsoft Viva / Microsoft Copilot (Microsoft 365) |
※上表は Microsoft のリリースコミュニケーションと Microsoft 365 Roadmap の公開情報を整理したものです。(Microsoft)
直接影響するのは、組織データを管理する管理者だけではありません。Copilot Analytics では、組織データのアップロード、Advanced Reporting の実行、Power BI レポートのカスタマイズ、レポート配布がそれぞれ別の役割にまたがります。つまり今回の更新は、Global 管理者や Viva Insights 管理者、Insights Analyst、導入推進担当が一緒に設計すべきテーマです。(Microsoft Learn)
なぜ組織属性ごとのセグメント化に効くのか
既定の組織データだけでは、分析の粒度に限界があります。Copilot Dashboard と Agent Dashboard は、既定では Microsoft Entra ID とユーザー設定、SMTP アドレスから取り込まれる PersonId、ManagerId、Organization、Domain、TimeZone を使います。さらに Organization フィルターは Entra ID の Department に対応し、Job function は FunctionType または Microsoft_JobDiscipline をアップロードしたときに表示されます。標準ダッシュボードで扱える属性が限られるからこそ、Power BI 側の深いフィルター設計に価値があります。(Microsoft Learn)
| 見方 | 浅いフィルター | 深いフィルター |
|---|---|---|
| 何が見えるか | 全社平均、部門平均 | 職種・階層・拠点・独自セグメントごとの差 |
| 起こしやすい誤解 | 「全社で使われていない」 | 「特定層では定着し、別の層では止まっている」 |
| 打ち手 | 全社向け一律研修 | 役割別シナリオ、管理職向け展開、拠点別支援、パイロット再設計 |
しかも Copilot Analytics の Power BI テンプレートは、もともと組織属性と時間軸でレポートを絞り込みながら導入やインパクトを深掘りできる設計です。2026年3月18日更新の Microsoft 365 Copilot adoption report では、クエリに最大20個の組織属性を追加でき、実行後はそれらでレポートを group / filter できます。さらに out-of-the-box の Power BI レポートは Filters pane に field を追加したり、レポートを保存し直したりできます。今回の 4月7日の告知は、こうした仕組みに対して、管理者が追加属性をフィルターとして有効化しやすくする方向のアップデートと読むと、実務上の意味がつかみやすいです。(Microsoft Learn)
どの属性で切ると打ち手が変わるのか
Viva Insights の組織データでは、required attributes に加えて reserved optional attributes と custom attributes を扱えます。reserved optional には LevelDesignation、FunctionType、HireDate、Layer、WeeklyBadgeOnsiteDays、Location などがあり、custom attributes は自社で定義した任意の属性です。さらに Microsoft 365 の Organizational Data では、JobTitle、Company、CompanyCode など、Viva Insights / Copilot Dashboard 向けの reserved attributes も案内されています。(Microsoft Learn)
| 優先したい属性軸 | 代表例 | 見えること | 打ち手 |
|---|---|---|---|
| 組織軸 | Organization、Company、Cost center | 事業部ごとの定着差 | 予算配分、部門別の展開計画見直し |
| 職務軸 | FunctionType / JobDiscipline、JobTitle | 役割ごとのユースケース差 | ロール別プロンプト、業務別トレーニング |
| 階層軸 | LevelDesignation、Layer、SupervisorIndicator | 管理職と現場の習慣化の差 | 管理職向け伴走、IC向け基本活用の再設計 |
| 地理軸 | Location、Country / Region、Office | 拠点ごとの導入速度の差 | 拠点別支援、言語・時差を踏まえた展開 |
| 独自軸 | pilot cohort、employment type、frontline / knowledge worker | 自社特有の定着パターン | パイロット再設計、対象ライセンスの最適化 |
たとえば職務軸で見ると、「営業部門は使っている」という大きな結論よりも、「営業企画は定着しているがフィールド営業は習慣化していない」といった実務に直結する差が見つかります。導入レポートは、group ごとの active Copilot users や actions per active user、power user concentration を見られるので、研修対象を部門単位ではなく職務単位で決めやすくなります。(Microsoft Learn)
階層軸も有効です。導入レポートでは Power user、Habitual user、Novice user、Non-user の区分があり、Power user は「平均で週15回以上の Copilot actions を行い、過去12週間のうち9週間以上利用した人」と定義されています。利用者数だけでなく、習慣化の深さを LevelDesignation や Layer で見ると、「役職者だけが活用し、現場 IC に広がっていない」といった失速ポイントが見えます。(Microsoft Learn)
拠点や独自 cohort で切るのも実用的です。Location や pilot cohort 属性で見ると、「全社展開は伸びているが、成果が出ているのは最初のパイロット群だけ」という状態を早い段階で見抜けます。custom attributes は Organizational Data in Microsoft 365 で downstream app への共有先や属性アクセスを管理できるため、単に属性を作るだけでなく、Viva / Copilot に渡す設定まで確認することが大切です。(Microsoft Learn)
深いフィルターを活かす前に整えるべき前提
属性品質
フィルターを深くしても、属性の品質が低ければ結論は歪みます。Data Quality Dashboard は attribute health、manager hierarchy consistency、data freshness を可視化し、coverage が 30% 未満の属性を low-quality と扱います。Power BI template queries では low-quality / missing attributes に警告が出るため、空欄だらけの属性を増やすより、まず使える属性を整えるほうが先です。(Microsoft Learn)
実務では、30% 未満を避けるのは当然として、まずは 80% 以上そろう属性 からフィルター候補にすると運用が安定します。特に manager 系の分析をしたいなら、ManagerId の不整合やループがないかも先に確認しておくべきです。(Microsoft Learn)
属性設計
属性は多ければよいわけではありません。Viva Insights では optional attributes を最大100個、全体で 105 属性まで扱えますが、Copilot adoption report などの Power BI クエリに追加できる組織属性は最大20個です。数を増やすより、「施策が変わる軸」だけを厳選したほうが、レポートは読まれ、打ち手にもつながります。(Microsoft Learn)
おすすめは、最初から 20 個埋めることではなく、3〜5 個の高シグナル属性 で始めることです。たとえば「FunctionType」「Layer」「Location」「pilot cohort」のように、見るだけで次の施策が変わる属性を優先すると、分析がレポート鑑賞で終わりません。
共有と権限
Power BI レポートを広く見せるほど、共有設計は重要になります。Viva Insights の Power BI レポート公開には unfiltered original report と manager hierarchy で絞る公開 があり、custom report publish 機能そのものは viewer ごとにデータを自動フィルターしません。Power BI レポートを広く配布するなら、row-level security や受信者設計を先に決めるべきです。(Microsoft Learn)
また、Copilot Dashboard と Agent Dashboard の group-level metrics には minimum group size があり、既定値は 10、設定可能な下限は 5 です。細かい属性で切りすぎると、見たいのに表示されない group が増えます。分析では「切れること」よりも、「表示可能な母数が残ること」を優先したほうが失敗しません。(Microsoft Learn)
失敗しやすいポイント
Organizationをそのまま実組織だと思い込むこと。Entra ID 既定では Organization フィルターは Department に対応するため、自社の BU や職制とずれることがあります。(Microsoft Learn)- カスタム属性を取り込んだだけで使えると思うこと。Organizational Data in Microsoft 365 では、アプリ共有先の選択や attribute access の設定が必要です。(Microsoft Learn)
- 低品質属性をそのままフィルターに並べること。coverage 30% 未満は low-quality とされ、warnings や missing insights の原因になります。(Microsoft Learn)
- レポート共有とデータ制御を同じものだと思うこと。custom report publish は viewer ごとのデータ絞り込みを自動では行いません。(Microsoft Learn)
- 属性更新を止めること。Microsoft は少なくとも月1回の組織データ更新を推奨しており、freshness が落ちると分析の信頼性も下がります。(Microsoft Learn)
今やるべきこと
実務では、次の順で進めると失敗しにくいです。
- Data Quality Dashboard で、使いたい属性の coverage と freshness を確認する
- 「施策が変わる属性」を 3〜5 個に絞る
- Global 管理者、Viva Insights 管理者、分析担当で、どの属性を Viva / Copilot に共有するか決める
- Copilot adoption report で一度レポートを作り、属性ごとに本当に打ち手が変わるか検証する
- 公開前に、受信者、minimum group size、row-level security の方針を決める
組織データは少なくとも月1回の更新が推奨で、新規インポートが Data Quality metrics に見えるまで最大2日かかることがあります。機能の展開を待つ間にこの運用を整えておけば、Power BI フィルタリングが深くなったタイミングで、すぐに意味のある Copilot 分析を回せます。(Microsoft Learn)
今回の Viva の Copilot の洞察がさらに深くなる Power BI フィルタリングの本質は、Copilot 導入を「平均」ではなく「属性ごとの定着差」で見られるようにすることです。機能そのものはまだロードマップ段階ですが、勝負はリリース後ではなく前準備で決まります。最初の一歩は、Data Quality Dashboard で low-quality な属性を洗い出し、そのうえで FunctionType、Layer、Location、独自 cohort のうち、施策を変えられる 3 つ前後から優先して整備することです。そうすれば、Copilot 導入の議論が「使われているか」から「どこに何を打つべきか」へ変わります。(Microsoft Learn)
コメント