Microsoft 365で組織データを取り込んでいる管理者にとって、「処理が終わったのか」「失敗していないか」を見落とさないことは重要です。今回の「Microsoft 365 admin center: Notifications for organizational data processing status」は、設定済みコネクタによる組織データ処理が完了した場合、または対応が必要な場合に、組織データソース管理者へメール通知する機能です。通知は既定で有効になり、不要な場合は配信停止できる予定です。プレビューは2026年6月、一般提供は2026年7月が予定されています。(Microsoft)
この変更は、Microsoft 365の利用者全員に見える新機能というより、Microsoft 365 admin centerでOrganizational Data in Microsoft 365を運用している管理者向けの監視・運用改善です。特に、Workday、SAP SuccessFactors、API連携、CSV取り込みなどで人事・組織データをMicrosoft 365やViva、Copilot関連機能に連携している組織では、通知の受信者、対応フロー、データ品質確認の手順を事前に整理しておく必要があります。
Microsoft 365 admin centerの組織データ処理ステータス通知で変わること
今回の変更点は、組織データの処理状況を管理者が能動的に確認するだけでなく、処理完了や要対応の状態をメール通知で把握できるようになる点です。
公式ロードマップでは、対象サービスは「Microsoft 365 admin center」、プラットフォームは「Web」、クラウドは「Worldwide Standard Multi-Tenant」、状態は「In development」とされています。リリースフェーズはPreviewとGeneral Availabilityの両方が設定されており、Preview dateはJune CY2026、GA dateはJuly CY2026です。(Microsoft)
| 項目 | 内容 |
|---|---|
| 機能名 | Microsoft 365 admin center: Notifications for organizational data processing status |
| Roadmap ID | 564971 |
| 対象 | Organizational Data in Microsoft 365のデータソース管理者 |
| 通知内容 | 設定済みコネクタのデータ処理が成功した場合、または対応が必要な場合 |
| 既定設定 | 通知は既定で有効 |
| 配信停止 | unsubscribeの選択肢あり |
| プレビュー予定 | 2026年6月 |
| 一般提供予定 | 2026年7月 |
| 対象クラウド | Worldwide Standard Multi-Tenant |
| 対象画面 | Microsoft 365 admin center、Web |
重要なのは、この機能が「データ処理そのものを変える機能」ではなく、「データ処理の状態を見落としにくくする通知機能」だという点です。既存のコネクタ設定、属性マッピング、データソース、アプリ共有設定を自動的に最適化するものではありません。
また、Microsoft 365 Roadmapの情報は商用機能の見込みリリース日と説明を示すもので、内容や時期は変更される可能性があるとMicrosoftは説明しています。展開計画では、2026年6月時点の情報を前提にしつつ、実際のテナント反映状況をMicrosoft 365 admin centerやMessage centerで確認してください。(Microsoft)
対象になる組織と管理者
対象になる可能性が高いのは、Organizational Data in Microsoft 365を使い、外部の人事・組織データをMicrosoft 365に取り込んでいる組織です。
Microsoft Learnでは、Organizational Data in Microsoft 365について、従業員の氏名、所在地、職務などを表す組織データをMicrosoft 365やMicrosoft Vivaにインポートできる機能と説明しています。また、複数のHRISシステムからコネクタを通じて組織・人事データを取り込めること、Microsoft 365 CopilotやMicrosoft 365アプリで利用されること、データ品質の問題を検出・通知するフレームワークを備えることが示されています。(Microsoft Learn)
影響を受けやすい利用シーン
次のような運用をしている場合は、今回の通知機能を確認対象に入れてください。
- HRシステムからMicrosoft 365へ組織データを定期連携している
- WorkdayやSAP SuccessFactorsなどのHCM／HRISデータをMicrosoft 365に取り込んでいる
- APIベースのインポートを使って組織データを送信している
- CSVやAzure Blob Storage Connectorなどで組織データを取り込んでいる
- Copilot Dashboard、Viva Insights、Workforce Insights、People Skillsなどで組織データを活用している
- 管理者がMicrosoft 365 admin centerのData Connections画面を定期的に確認している
組織データは、Copilot DashboardやViva Insightsで部門別の傾向を可視化したり、組織関係を正確にマッピングしたりするために使われます。Workforce InsightsやPeople Skillsでも、組織データやカスタム属性が分析・スキル関連機能の基盤になります。(Microsoft Learn)
そのため、データ処理の失敗や遅延を放置すると、単なる管理画面上のエラーにとどまりません。部門、役職、所在地、マネージャー情報などを前提にした分析やレポートの精度に影響する可能性があります。
通知を受け取る「Organizational Data Source Administrator」とは
今回の通知対象として示されているのは、organizational data source adminsです。Microsoft Learnでは、Organizational Data Source Administratorは、Organizational Data in Microsoft 365の取り込みや管理に関連する設定を管理できるロールと説明されています。データのアップロード、更新、削除、エクスポートに加え、WorkdayやSAP SuccessFactorsなどのHCMシステム接続、セキュアなファイルアップロード、アプリによるデータアクセス管理も行えます。(Microsoft Learn)
| ロール | 主な役割 | 今回確認すべきこと |
|---|---|---|
| Microsoft 365 Global Administrator | 組織データ機能や管理者ロールを含む広範な管理 | データソース管理者の割り当て、管理体制、サポート窓口 |
| Organizational Data Source Administrator | 組織データの取り込み・管理・エクスポート・接続設定 | 通知メールの受信、エラー対応、データ品質確認 |
| HRIS／HCM担当者 | 元データの出力、定期エクスポート、項目変更管理 | 元データの列名変更、出力遅延、資格情報期限切れへの対応 |
| 開発者／連携担当者 | API連携、認証情報、ジョブ監視、リトライ設計 | メール通知に頼り切らない監視とログ突合 |
よくある失敗は、「グローバル管理者だけが把握していて、実際のデータ連携担当者に通知が届かない」状態です。今回の機能はデータソース管理者への通知が中心になるため、実運用で誰が通知を受け、誰が調査し、誰がHR側へ確認するのかを決めておくことが重要です。
通知メールで分かることと分からないこと
公式ロードマップで明記されているのは、設定済みコネクタによるデータ処理が「正常に完了した場合」または「対応が必要な場合」にメール通知されることです。通知は既定で有効で、unsubscribeできるとされています。(Microsoft)
一方で、2026年6月時点のロードマップ情報だけでは、次の詳細は明確ではありません。
| 未確定または要確認の項目 | 管理者が取るべき対応 |
|---|---|
| メールの送信元アドレス | メールセキュリティ製品で誤検知しないか、プレビュー開始後に確認する |
| 件名や本文フォーマット | 受信ルールや自動振り分けを作る場合は、実際の通知を確認してから設定する |
| 通知の頻度 | 定期連携の実行回数に応じてメール量が増えないか確認する |
| 「requires attention」の具体的な分類 | 管理画面の状態、ログ、データ品質レポートと合わせて判断する |
| 管理者単位のunsubscribeか、通知種別単位のunsubscribeか | 不要な配信停止で運用担当者が通知を失わないようにする |
特に、通知が既定で有効になる点は見落としやすいポイントです。新機能が有効化された後に突然メールが届き始める可能性があるため、管理者向けメールボックスやチケット管理への転送ルールを整えておくと混乱を防げます。
管理者が今すぐ確認すべき設定
Data Connectionsで対象コネクタを棚卸しする
まず確認すべき場所は、Microsoft 365 admin centerのOrganizational Data in Microsoft 365にあるData Connectionsです。APIベースのインポートでは、Microsoft 365 admin centerの「Home > Setup > Migration and imports > Organizational Data in Microsoft 365 > Data Connections」から取り込み設定を開始する手順が案内されています。(Microsoft Learn)
確認する項目は次の通りです。
| 確認項目 | 見るポイント |
|---|---|
| コネクタ名 | 何のデータソースと連携しているか分かる名前になっているか |
| 接続種別 | API、CSV、HRISコネクタなど、運用担当者が識別できるか |
| 最終処理日時 | 定期連携の想定スケジュールとずれていないか |
| 状態 | Awaiting connection、処理中、エラーなどが放置されていないか |
| 管理者 | 通知を受けるべき担当者にロールが割り当てられているか |
| 下流アプリ | どのMicrosoft 365／Vivaアプリにデータを共有しているか |
コネクタが複数ある組織では、通知メールだけを見ても影響範囲を判断しづらい場合があります。コネクタ名には「HR-Workday-Weekly」「PeopleSkills-SkillsAPI」「VivaInsights-OrgData」など、用途と更新頻度が分かる名前を付けると運用しやすくなります。
通知を受ける管理者を見直す
通知が届いても、受信者が退職者、異動者、個人管理者のままでは意味がありません。Global Administratorは、Organizational Data Source Administratorの割り当てを見直し、少なくとも次の条件を満たす体制にしておくべきです。
- 通知を読む担当者が明確である
- 休暇や異動時の代替担当者がいる
- HRIS担当、Microsoft 365管理者、セキュリティ担当の連絡経路がある
- 通知を受けた後の一次対応手順が決まっている
- unsubscribeを個人判断で行わないルールがある
おすすめは、個人の経験に依存した運用ではなく、「通知受信」「一次確認」「原因切り分け」「HR側確認」「再実行またはMicrosoftサポート問い合わせ」までを短いランブックにすることです。
データ品質と必須属性を確認する
Organizational Data in Microsoft 365では、Microsoft_PersonEmailが必須属性として示されています。これは、組織データを特定の人物に関連付けるための属性です。(Microsoft Learn)
また、APIベースのインポート手順では、ヘッダーCSVとデータCSVの列数や列名が一致しない場合、インポート処理が失敗すると説明されています。予約済み属性名を使う場合は、Microsoft_PersonEmailのように「Microsoft_」プレフィックス付きの列名を使うことで自動マッピングできる場合があります。(Microsoft Learn)
通知機能の導入前に、次のようなデータ品質チェックを用意しておくと、requires attentionの通知が来たときに素早く原因を絞り込めます。
| チェック対象 | 失敗例 | 対応例 |
|---|---|---|
| 必須属性 | Microsoft_PersonEmailが空欄 | 元データの抽出条件を修正する |
| 列名 | ヘッダーCSVとデータCSVの列が一致しない | テンプレートを固定し、変更時は事前レビューする |
| メール形式 | 個人に紐づかないメールアドレスが混在 | HRIS側の従業員IDとメールアドレスを照合する |
| マネージャー情報 | Microsoft_ManagerEmailが退職者を指している | 退職・異動データの反映タイミングを確認する |
| カスタム属性 | 想定外の値や空欄が多い | 下流アプリで使う属性だけを共有する |
| レコード件数 | 前回より大幅に少ない | 抽出対象部署、雇用区分、退職者除外条件を確認する |
通知メールはあくまで「気づくための入口」です。根本対応には、元データ、属性マッピング、コネクタ設定、下流アプリへの共有設定を確認する必要があります。
通知を受け取った後の対応フロー
通知が届いたら、内容に応じて次のように対応します。
| 通知の種類 | まず確認すること | 実務上の判断 |
|---|---|---|
| 処理完了 | 対象コネクタ、処理日時、前回との差分 | 通常の定期処理であれば記録のみ。大きな件数差があれば確認 |
| 対応が必要 | 管理画面上の状態、エラー内容、直近の元データ変更 | 認証、ファイル形式、属性マッピング、データ品質を切り分け |
| 通知が来ない | 対象管理者、メール配送、unsubscribe、コネクタ実行状況 | そもそも処理が走っていない可能性も確認 |
| 通知が多すぎる | コネクタ数、実行頻度、重複通知 | メール振り分けや担当分担を見直し、安易に全停止しない |
成功通知で見るべきポイント
成功通知が届いた場合でも、何も確認しなくてよいわけではありません。特に月次・週次の組織データ更新では、件数や主要属性の変化を簡単に確認しておくと、後から分析結果の異常に気づくリスクを減らせます。
例えば、従業員数が2,000人の組織で、ある週だけ取り込み件数が1,200件に減っていた場合、処理自体は成功していても、HRIS側のエクスポート条件が変わった可能性があります。メールが「成功」を示していても、データの妥当性までは別途確認する運用が必要です。
requires attention通知で見るべきポイント
対応が必要という通知を受けた場合は、まずMicrosoft 365 admin centerで該当コネクタの状態を確認します。APIベースのインポートでは、データがVivaやMicrosoft 365サービスの要件に対して検証され、検証には数時間かかることがあり、完全なアップロードがプロファイルストアで利用可能になるまで最大3日かかる場合があると説明されています。(Microsoft Learn)
すぐに再実行する前に、次の順序で確認すると原因を切り分けやすくなります。
| 順序 | 確認内容 | 例 |
|---|---|---|
| 1 | 対象コネクタ | どのHRIS、どのAPI、どのCSVか |
| 2 | 処理タイミング | 定期実行か、手動実行か |
| 3 | 直近変更 | HRISの列追加、列名変更、抽出条件変更 |
| 4 | 認証情報 | シークレット、証明書、フェデレーション資格情報の期限 |
| 5 | データ形式 | 文字コード、区切り文字、ヘッダー、必須属性 |
| 6 | 下流影響 | Viva Insights、Copilot Dashboard、People Skillsなどへの影響 |
| 7 | 対応記録 | 再実行、修正内容、確認者、発生日 |
「とりあえず再実行」は避けた方が安全です。元データの列構造が変わっている場合、再実行しても同じ失敗を繰り返すだけでなく、原因の特定が遅れます。
開発者・連携担当者が確認すべきポイント
APIベースで組織データを連携している場合、メール通知だけに頼らず、連携基盤側でも実行結果を確認できるようにしておくべきです。
Microsoft LearnのAPIベースインポート手順では、Global AdministratorがMicrosoft Entra admin centerでアプリ登録を作成し、データソース管理者が証明書やシークレットを渡して登録を支援する流れが示されています。Workday RaaSのような外部ソースとの直接接続では、証明書やフェデレーション資格情報ではなくクライアントシークレットを使う必要があると説明されています。(Microsoft Learn)
開発者や連携担当者は、次の観点で点検してください。
| 観点 | 確認内容 |
|---|---|
| 認証 | クライアントシークレット、証明書、フェデレーション資格情報の期限管理 |
| 実行ログ | 送信日時、件数、ジョブID、HTTPステータス、エラー内容の保存 |
| リトライ | 一時的な失敗とデータ不備を区別して再実行する設計 |
| データ検証 | Microsoft 365へ送る前に必須属性、列数、値形式を検証 |
| 変更管理 | HRIS側の項目追加・削除・名称変更を事前レビュー |
| 通知連携 | メール通知、監視ツール、チケット管理の役割分担 |
メール通知は管理者にとって便利ですが、システム連携の監視としては粒度が粗い場合があります。API連携では、ジョブごとの実行ログとMicrosoft 365 admin center側の処理結果を突合できるようにしておくと、障害調査が大幅に早くなります。
移行・展開時の注意点
Preview中は仕様変更を前提にする
Preview dateは2026年6月、GA dateは2026年7月とされていますが、ロードマップの時期や内容は変更される可能性があります。運用ルールを固める場合も、Preview中に受信したメールの件名、本文、通知頻度、対象者を確認してから本番ルールに反映するのが安全です。(Microsoft)
特にメールセキュリティ製品、SIEM、チケット管理ツールと連携する場合、Preview時点のフォーマットに依存しすぎると、GA後の変更で自動処理が動かなくなる可能性があります。
通知の既定有効化によるメール増加に注意する
通知は既定で有効になる予定です。複数のコネクタを短い間隔で実行している組織では、想定以上に通知が増える可能性があります。
ただし、メールが多いからといって安易にunsubscribeするのはおすすめしません。通知を止める前に、次の順序で整理してください。
- どのコネクタの通知が多いのか確認する
- 成功通知と要対応通知を分けて扱えるか確認する
- メールルールでフォルダー分けできるか確認する
- チケット化する条件を「requires attention」のみに絞れるか検討する
- 配信停止する場合は、代替の監視方法を用意する
通知を止めた結果、データ処理の失敗に気づけなくなる運用は避けるべきです。
組織データの共有範囲を見直す
Organizational Data in Microsoft 365では、公開属性、機密属性、カスタム属性を扱えます。公開属性には勤務先メール、氏名、役職、部署などが含まれ、機密属性やカスタム属性は、どのアプリに共有するかを管理できます。(Microsoft Learn)
また、Microsoft 365 admin centerから組織データをアップロードすると、そのデータはMicrosoft 365やVivaのアプリ・サービスでアクセス・利用されると説明されています。(Microsoft Learn)
通知機能の導入をきっかけに、次の点も見直すとよいでしょう。
| 見直し項目 | 理由 |
|---|---|
| 共有対象アプリ | 不要なアプリに機密属性やカスタム属性を共有しないため |
| カスタム属性 | 業務上の意味が不明な属性を増やしすぎないため |
| データ保持・削除 | 退職者や異動者の情報が古いまま残らないようにするため |
| HRとの変更管理 | 組織改編や職位名称変更が分析結果に影響するため |
| センシティブデータ | 不要な個人情報をMicrosoft 365に取り込まないため |
通知はデータ処理の状態を教えてくれますが、共有してよいデータかどうかまでは判断してくれません。管理者側でデータ最小化とアクセス制御を確認する必要があります。
データ優先順位の設定にも注意する
複数のデータソースが同じ属性を提供する場合、どのデータをMicrosoft 365 User Profileで優先するかが重要です。Microsoft Learnでは、Microsoft Entra ID、Organizational Data in Microsoft 365、ユーザープロファイル同期など複数ソースのデータが重なる場合、テナント管理者が信頼するデータソースを構成できると説明されています。(Microsoft Learn)
例えば、Microsoft Entra IDのjobTitleが「Software Engineer」、組織データ側のMicrosoft_JobTitleが「Senior Software Engineer」の場合、組織データを優先するとMicrosoft 365のプロファイルカードなどで後者が返されます。(Microsoft Learn)
さらに、Microsoft Learnでは、Microsoft 365 User Profileの情報を最新かつ正確に保つため、組織データを定期的に更新することが推奨されています。例として週次更新が示されています。(Microsoft Learn)
通知機能の導入後は、「処理が成功したか」だけでなく、「正しいソースが優先されているか」「古いデータが優先されていないか」も確認してください。
よくある疑問
すべてのMicrosoft 365管理者に通知が届くのか
公式ロードマップでは、通知対象はorganizational data source adminsとされています。すべてのMicrosoft 365管理者や一般ユーザーに届く機能ではなく、組織データソース管理者向けの通知と考えるのが自然です。(Microsoft)
ただし、実際の受信対象やメール配送の詳細は、テナントでの展開後に確認してください。
既定で有効なら何もしなくてよいのか
何もしなくても通知は届く可能性がありますが、運用としては不十分です。通知を誰が見るのか、対応が必要な場合に誰へエスカレーションするのか、成功通知を記録するのかを決めておかないと、メールが届いても対応が属人化します。
unsubscribeしても問題ないのか
不要な通知を止める選択肢はありますが、代替の監視方法がないまま配信停止するのは避けるべきです。特にHRIS連携やCopilot Dashboard、Viva Insightsで組織データを活用している場合、処理失敗の見落としが分析品質に影響する可能性があります。
組織データを使っていないテナントにも影響するのか
Organizational Data in Microsoft 365のコネクタを設定していない場合、実務上の影響は限定的と考えられます。ただし、将来的にCopilot、Viva、People Skills、Workforce Insightsなどの活用を予定している組織は、組織データの取り込み設計とあわせて通知運用も検討しておくとよいでしょう。
展開前に準備しておきたいチェックリスト
GA前に、少なくとも次の項目を確認しておきましょう。
| チェック項目 | 完了の目安 |
|---|---|
| 対象コネクタの一覧化 | Data Connectionsにある全コネクタの用途、所有者、実行頻度が分かる |
| 管理者ロールの確認 | Organizational Data Source Administratorが現行担当者に割り当てられている |
| 通知受信ルール | 通知メールを見落とさないメールボックス、フォルダー、チケット化ルールがある |
| エラー対応手順 | requires attention時の一次確認項目が決まっている |
| HRIS変更管理 | 元データの列名、抽出条件、スケジュール変更の連絡経路がある |
| 認証情報管理 | 証明書やシークレットの期限を把握している |
| データ品質確認 | 必須属性、列数、件数差分、主要属性のチェックがある |
| 下流影響の整理 | Copilot Dashboard、Viva Insights、People Skillsなど利用先が分かる |
| unsubscribeルール | 個人判断で通知停止しない運用になっている |
| Preview確認 | 実際のメール件名、本文、頻度、対象者を確認する予定がある |
まず行うべきこと
今回の「Notifications for organizational data processing status」は、組織データ連携を運用する管理者にとって、障害や処理完了を早く把握するための実用的な改善です。特に、Microsoft 365 Copilot、Viva Insights、Workforce Insights、People Skillsなどで組織データの品質が重要になる環境では、通知を単なるメールとして扱わず、運用監視の入口として位置付けるべきです。
最初に行うべきことは、Microsoft 365 admin centerでOrganizational Data in Microsoft 365のData Connectionsを確認し、対象コネクタ、管理者ロール、通知受信者、エラー対応手順を棚卸しすることです。そのうえで、Preview期間中に実際の通知内容を確認し、GA前にメール振り分け、チケット化、HRIS担当者との連絡フローを整えておきましょう。
コメント