Microsoft Viva: Viva Glint – Self service for historical importsは、Viva Glintへ過去の従業員サーベイデータを取り込む作業を、管理者がより少ないファイル数と簡素化された操作で実行できるようにする機能です。2026年5月13日公開・更新の公式ロードマップ情報では、対象はMicrosoft Viva、プラットフォームはWeb、クラウドはWorldwide（Standard Multi-Tenant）、リリース段階はGeneral Availability、提供開始予定は2026年12月、ステータスはIn developmentです。(Microsoft)
結論から言うと、今すぐ本番手順を置き換える機能ではなく、Viva Glintの履歴インポート作業を簡素化するための新しい選択肢と捉えるべきです。管理者は、既存のAdvanced Configurationを使った履歴インポート手順、過去サーベイの質問マッピング、メールアドレス・従業員ID・属性値の整合性を先に棚卸ししておくと、一般提供後の移行がスムーズになります。
Microsoft Viva: Viva Glint – Self service for historical importsで何が変わるのか
今回の変更は、Viva Glintに過去のサーベイ結果を取り込む「historical imports」を、管理者がより扱いやすくするためのものです。
公式ロードマップでは、この機能は既存のAdvanced Configurations機能に対する代替ソリューションとして説明されています。従来は、管理者がViva Glintプラットフォームへ履歴データをインポートする際に複数のファイルや高度な設定操作を扱う必要がありました。新機能では、必要なファイル数を減らし、履歴データをViva Glintへ取り込むユーザー体験を簡素化するとされています。(Microsoft)
ただし、「Advanced Configurationsが即時廃止される」とは読み取れません。公式情報では“alternative solution”と表現されているため、少なくとも現時点では、既存手順を補完または代替する新しいセルフサービス手段として準備するのが安全です。
| 観点 | 従来の運用 | 新機能で期待される変化 | 管理者が確認すべきこと |
|---|---|---|---|
| 操作場所 | Advanced Configuration中心 | よりセルフサービス化された操作 | 既存の手順書と権限設計を見直す |
| ファイル準備 | 複数ファイルを準備する必要がある | 必要ファイル数の削減が見込まれる | どのファイル・列が不要になるかはGA後に確認 |
| 利用者 | 高度な設定に慣れた管理者向け | 管理者が扱いやすくなる可能性 | HR担当者だけで実行させず、IT・データ管理者も関与 |
| リスク | 属性・ID・質問マッピングのミスが影響しやすい | 操作は簡素化されてもデータ品質の重要性は変わらない | 事前検証、プレビュー、復旧手順を残す |
対象となる組織と利用シーン
この機能の主な対象は、Viva Glintを導入済み、または導入予定で、過去の従業員サーベイ結果をViva Glint上で比較・分析したい組織です。
具体的には、次のようなケースで関係します。
- 以前のサーベイベンダーからViva Glintへ移行する
- 過去のエンゲージメント調査結果をViva Glintのレポートに取り込みたい
- 年次・半期・四半期などの過去サイクルと現在のサーベイ結果を比較したい
- 部署、拠点、職種、マネージャー階層などの属性別に履歴トレンドを確認したい
- HR部門が持つ過去データをMicrosoft Viva上の分析基盤に集約したい
Viva GlintのAdvanced Configurationには、外部の過去サーベイデータを取り込み、Viva Glintで継続して質問している項目のトレンドを確認する用途があります。(Microsoft Learn) そのため、新機能も単なるCSVアップロード機能ではなく、過去データを現在のViva Glint運用に接続するための管理機能として理解するとよいでしょう。
影響範囲：一般ユーザーよりも管理者・HR・データ担当者への影響が大きい
この変更で直接影響を受けるのは、従業員サーベイに回答する一般ユーザーではなく、主にViva Glintの管理・データ連携・レポート運用を担当する人です。
| 対象者 | 影響 | 具体的な確認ポイント |
|---|---|---|
| Viva Glint管理者 | 履歴インポートの実行手順が変わる可能性 | Advanced Configurationでの既存手順、権限、承認フロー |
| HR・People Analytics担当 | 過去データの比較分析がしやすくなる可能性 | 質問文、回答スケール、属性値、対象期間の整合性 |
| Microsoft 365管理者 | 権限・ユーザーデータ連携の確認が必要 | 管理者ロール、ユーザー情報、メールアドレス、従業員ID |
| データ連携・開発担当 | CSV生成やデータ整形ロジックの見直しが必要 | HRIS、DWH、ETL、Power Query、スクリプトの出力形式 |
| 現場マネージャー | レポート上で過去比較を閲覧する可能性 | 比較可能なデータかどうかの説明、読み解き方の周知 |
開発者やデータ担当者にとって重要なのは、「画面操作が簡単になる＝データ準備が不要になる」ではない点です。過去データの品質、質問IDの対応、メールアドレスや従業員IDの整合性が崩れていれば、どれだけインポートUIが簡素化されても、正しいトレンド分析にはつながりません。
リリース時期と展開計画で押さえるべき点
公式ロードマップ上の提供開始予定は2026年12月です。状態はIn developmentであり、リリースフェーズはGeneral Availability、対象クラウドはWorldwide（Standard Multi-Tenant）、プラットフォームはWebとされています。(Microsoft)
Microsoft 365ロードマップのリリース日は商用機能の推定予定であり、内容や時期は変更される可能性があります。(Microsoft) そのため、社内展開計画では「2026年12月に必ず本番移行する」と固定せず、次のように段階を分けると安全です。
| 時期 | やること | 目的 |
|---|---|---|
| GA前 | 現行の履歴インポート手順とファイル構成を棚卸し | 新機能との差分をすぐ判断できるようにする |
| GA直後 | テスト用データで操作手順・エラー・権限を確認 | 本番データ投入前に失敗パターンを把握する |
| 本番前 | HR、IT、法務・セキュリティ、データ担当で承認 | 個人情報・属性データの取り扱いリスクを抑える |
| 本番後 | ダッシュボード、階層、スコア、回答者数、コメントを確認 | インポート結果が分析に使える状態か検証する |
現行の履歴インポート手順を理解しておく
新機能の一般提供前に、現行の履歴インポートで何が必要かを把握しておくと、変更点を正しく評価できます。
Microsoft Learnの現行ドキュメントでは、外部の履歴データをインポートする際に、主に次の3種類のデータファイルが必要とされています。(Microsoft Learn)
| ファイル | 役割 | 実務での注意点 |
|---|---|---|
| ユーザーファイル | 履歴データに含まれる従業員と属性をViva Glint側に登録する | 現在の従業員情報と混同しない。履歴時点の属性を扱う |
| Raw Score File | 回答者のメールアドレスと質問ごとの数値回答を含める | 質問ID、回答値、コメント列の形式を正確に合わせる |
| 回答者ユーザーファイル | 履歴サーベイの回答者情報を含める | メールアドレス、名、姓、従業員ID、状態などの必須項目を整える |
ロードマップでは、新機能によって必要なファイル数を減らすと説明されています。(Microsoft) ただし、どのファイルが不要になるか、どの入力項目が画面側に統合されるかは、一般提供後のドキュメントや管理画面で確認する必要があります。
インポート前に判断すべき「過去データを入れる価値」
履歴データは、入れれば必ず役に立つわけではありません。過去データの文脈が現在の組織と大きく違う場合、レポート上のトレンドがかえって誤解を生むことがあります。
Viva Glintの公式ドキュメントでも、過去サーベイの時期、組織再編や大規模な人員増減の有無、回答スケール、Viva Glint項目とのマッピング可否などを確認する重要性が示されています。特に、データが古い場合や組織に大きな変化があった場合、履歴データを比較対象として使う意味が薄れる可能性があります。(Microsoft Learn)
判断基準は次のとおりです。
| 判断項目 | インポートに向いている状態 | 注意が必要な状態 |
|---|---|---|
| 調査時期 | 直近1年程度で組織構造が大きく変わっていない | 数年前のデータ、M&A・分社化・大規模再編後 |
| 回答スケール | Viva Glintと同じ5段階のLikertスケールに近い | 4段階、10段階、独自スコア、逆転尺度が混在 |
| 質問文 | 現在のViva Glint項目と意図が近い | 似た言葉でも測っている概念が違う |
| 属性値 | 部署・拠点・職種などが現在の設計と対応する | 「人事部」と「HR」など表記ゆれが多い |
| 利用目的 | 経年比較や移行時の基準値として使う | 過去データだけで現在の施策判断を行う |
たとえば、過去に「上司との関係に満足しているか」という質問を使い、現在のViva Glintでは「マネージャーは成長を支援してくれる」といった項目を使っている場合、どちらもマネージャー関連に見えても、測っている内容は同じとは限りません。この場合、無理にトレンド比較するより、注釈付きで参考値として扱うほうが安全です。
管理者が確認すべき設定・権限
現行のAdvanced Configurationを使った外部インポートでは、Viva Glintの詳細設定ページへのアクセスが必要です。アクセスできない場合は、サービス管理ユーザーロールに属しているか、Advanced Configuration機能がユーザーに対して有効化されているかを確認する必要があります。(Microsoft Learn)
また、Advanced Configurationは高度な設定変更や複雑なデータ更新を扱う機能であり、一部の設定変更は元に戻せない可能性があるため、訓練されたViva Glintユーザーが変更すべきとされています。(Microsoft Learn) 新しいセルフサービス機能でも、少なくとも初期展開時は同じ考え方で権限を絞るべきです。
権限設計の実務ポイント
権限は「実行できる人」ではなく、「責任を持って検証できる人」を基準に付与します。
おすすめの分担は次のとおりです。
| 役割 | 担当内容 |
|---|---|
| Viva Glint管理者 | インポート操作、プレビュー確認、完了確認 |
| HR責任者 | 質問マッピング、組織属性、分析目的の承認 |
| Microsoft 365管理者 | 管理者ロール、ユーザー情報、アクセス制御の確認 |
| データ担当者 | CSV・属性・ID・メールアドレス・重複チェック |
| セキュリティ/法務担当 | 個人情報、機微属性、保存期間、利用目的の確認 |
少人数のHR担当者だけで完結させると、メールアドレスの不一致や属性値の表記ゆれ、過去組織階層の扱いで失敗しやすくなります。特にグローバル企業や組織再編が多い企業では、IT側のデータ確認を必ず入れてください。
データ移行で失敗しやすいポイント
履歴インポートの成否は、画面操作よりもデータ準備で決まります。新機能でUIが簡素化されても、以下のチェックは省略しないほうが安全です。
メールアドレスと従業員IDの整合性
Viva Glintの履歴インポートでは、回答者データとViva Glint側のユーザープロファイルでメールアドレスが一致していないと、「ユーザーがクライアントにいない」というエラーが発生する場合があります。(Microsoft Learn)
退職者、メールドメイン変更、姓名変更、グループ会社統合がある組織では、過去サーベイ時点のメールアドレスと現在のメールアドレスが異なることがあります。事前に次のような対応表を作ると、エラーを減らせます。
| 旧メールアドレス | 現メールアドレス | 従業員ID | 状態 | 備考 |
|---|---|---|---|---|
| [email protected] | [email protected] | E00123 | Active | ドメイン変更 |
| [email protected] | [email protected] | E00456 | Active | 姓変更 |
| [email protected] | なし | E00789 | Inactive | 退職者 |
属性値の表記ゆれ
属性値の表記ゆれは、レポートの分断につながります。Microsoft Learnでも、現在のViva Glintと履歴ユーザーの間で属性と値を揃える必要があると説明されており、例として「部署 = 人事部」と「部署 = 人事」は同じトレンドとして扱われないことが示されています。(Microsoft Learn)
実務では、次のような正規化ルールを先に決めます。
| 表記ゆれ | 統一後の値 |
|---|---|
| 人事、人事部、HR、Human Resources | HR |
| 東京本社、Tokyo HQ、TOKYO | Tokyo |
| 営業、Sales、セールス部 | Sales |
| 正社員、Full-time、FT | Full-time |
この作業を後回しにすると、インポート自体は成功しても、ダッシュボード上で属性別の傾向が正しく見えません。
質問IDと回答値の整合性
Raw Score Fileでは、各ユーザーの回答データを横方向のレイアウトで持ち、質問列にはViva Glint側の質問IDを使う必要があります。複数選択の回答値はコロン区切りで指定するなど、質問タイプごとに形式の違いがあります。(Microsoft Learn)
過去サーベイの質問文とViva Glintの質問IDを対応させるときは、単純な文字列一致ではなく、質問の意図まで確認します。
悪い例：
- 過去質問：「会社に満足している」
- Viva Glint項目：「友人にこの会社を勧めたい」
- 判定：どちらも満足度に見えるが、同一トレンドとして扱うには慎重な判断が必要
良い例：
- 過去質問：「この会社を働く場所として友人に勧めたい」
- Viva Glint項目：「I would recommend this company as a great place to work」
- 判定：意図が近く、スケールも一致するならマッピング候補になる
展開時に注意すべき運用ポイント
履歴インポートは、一度きりのデータ投入に見えて、実際には既存の従業員データ、アンケートプログラム、配布リスト、レポート階層に影響します。新機能を展開する際も、次の点を必ず確認してください。
ライブ中のサーベイと重ねない
現行ドキュメントでは、Viva Glintアンケートがライブ中の場合、外部の履歴インポートを避けるよう注意されています。(Microsoft Learn) 本番サーベイの配信中に履歴インポートを行うと、ユーザー情報や配布リスト、レポート処理の切り分けが難しくなります。
おすすめは、次のようにサーベイ運用カレンダーに履歴インポート用の作業枠を明示することです。
| タイミング | 実施可否 | 理由 |
|---|---|---|
| サーベイ配信中 | 避ける | 回答・通知・データ更新の影響を切り分けにくい |
| サーベイ終了直後 | 慎重に実施 | レポート処理や関係者レビューと重なる可能性 |
| 次回サーベイ設計前 | 実施しやすい | 質問マッピングや過去比較の設計に反映できる |
| 大規模組織変更直後 | 慎重に実施 | 階層・属性・IDの整合性確認が必要 |
例外日を適切に設定する
現行手順では、例外日はレポートに表示される開始日を決める項目で、現在日より少なくとも1週間前、かつスケジュール済みアンケートと重複しない日付にする必要があります。また、現在日から3日以内の日付を選ぶと、不要なメール招待が従業員に送信される可能性があるとされています。(Microsoft Learn)
例外日が既存または予定済みのアンケート開始日と重複すると、例外日付の重複エラーが発生します。(Microsoft Learn) 事前に完了済み・予定済みのサーベイ開始日を一覧化してから作業してください。
定期的な従業員データ連携を一時停止する
現行ドキュメントでは、履歴インポート中に従業員データを定期インポートしている他チームと連携し、アップロードを一時停止できるようにすることが推奨されています。(Microsoft Learn)
HRISやSFTP連携、定期CSVアップロードが動いたままだと、履歴時点の属性を読み込んだ直後に現在の従業員情報で上書きされる可能性があります。作業前に、次の項目を確認しましょう。
- 定期インポートの実行時刻
- 手動アップロードの担当者
- SFTPや自動連携の有無
- インポート後に現在の従業員データへ戻す手順
- 失敗時に復元するためのバックアップファイル
よくあるエラーと事前対策
履歴インポートでは、ファイル形式やデータの不整合によるエラーが起きやすくなります。新しいセルフサービス機能で操作が簡単になっても、以下の確認は必要です。
| エラー・症状 | 主な原因 | 事前対策 |
|---|---|---|
| 必須フィールドがありません | Raw Score Fileに必要なフィールドが不足している | 必須列、列ヘッダー、UTF-8 CSV形式を確認する |
| ユーザーがクライアントにいません | 回答者ユーザーファイルとViva Glintプロファイルのメールアドレスが一致しない | 旧メール・現メール・従業員IDの対応表を作る |
| エントリの重複 | Raw Score File内に重複するユーザーレコードがある | 各回答者が1行だけになるよう重複排除する |
| 例外日付の重複 | 例外日が既存または予定済みサーベイの開始日と重なる | サーベイ開始日の一覧を確認し、重複しない過去日を選ぶ |
必須フィールド不足のエラーでは、CSVをExcelに取り込む際に元の形式を保持し、必要な列と列ヘッダーを確認したうえで、UTF-8エンコードのCSVとして保存し直す手順が示されています。(Microsoft Learn) また、Raw Score Fileに重複ユーザーレコードがある場合、各回答者は1つの応答行だけを持つ必要があるため、重複を削除してから再インポートする必要があります。(Microsoft Learn)
開発者・データ担当者が見直すべき処理
Viva Glintの履歴インポートは管理画面の機能ですが、実務ではデータ加工を担当する開発者やBI担当者の関与が欠かせません。特に、HRIS、DWH、CSV生成スクリプト、Power Query、ETLツールで過去データを整形している場合は、新機能のGA前に以下を確認してください。
CSV生成ロジック
現行手順では、Raw Score Fileと回答者ユーザーファイルは、コンマ区切りのCSV形式で、UTF-8またはBOM付きUTF-8である必要があります。値にコンマが含まれる場合は二重引用符で囲む必要があります。(Microsoft Learn)
チェックすべきポイントは次のとおりです。
- 文字コードがUTF-8になっているか
- カンマを含む部署名・役職名が正しく引用符で囲まれているか
- 改行を含むコメントが列ずれを起こしていないか
- 質問IDがViva Glint側のIDと一致しているか
- 数値回答とテキスト回答が混在していないか
- 1回答者につき1行になっているか
コメントデータの扱い
コメントを含める場合は、文字列のクレンジングも必要です。現行ドキュメントでは、コメントに含まれるバックスラッシュの置換、二重引用符で囲まれた語句の扱い、UTF-8 CSVとして保存する場合の引用符処理などが説明されています。また、1,024文字を超えるコメントは切り捨てられるとされています。(Microsoft Learn)
実務上は、コメントの長さ、個人情報、機微情報、禁止語、不要な改行を事前に確認してください。サーベイコメントには、氏名、部署内の個人が特定できる情報、健康・労務・ハラスメント関連の記述が含まれることがあります。単にインポートできるかではなく、誰が閲覧できるか、レポート上で匿名性が保たれるかを確認することが重要です。
テストデータの作成
本番データを使って初回検証するのは避けるべきです。次のような最小データセットを作り、処理を確認します。
| テスト観点 | 用意するデータ |
|---|---|
| 正常系 | 5〜10名程度、質問数を絞った履歴データ |
| メール不一致 | 旧メール・現メールが異なるユーザー |
| 重複 | 同じ回答者が2行存在するデータ |
| 属性ゆれ | 「HR」「人事」など表記が異なる属性 |
| コメント | 短文、長文、カンマ、引用符、改行を含むコメント |
| 未回答者 | ユーザーファイルにはいるがRaw Score Fileにいないユーザー |
このテストでエラー内容、プレビュー表示、レポート反映、修正手順を確認しておくと、本番移行時の手戻りを減らせます。
インポート後に必ず確認すること
インポートが完了したら、ファイル処理が成功したかだけで判断してはいけません。レポート上で期待どおりに表示されるかを確認する必要があります。
Microsoft Learnでは、外部インポートの処理後に、ダッシュボードとレポートで、レポート階層、質問スコア、回答者数、履歴データとViva Glintデータのトレンド、属性値の表示、コメント数などを確認することが示されています。コメントレポートについては、データが完全に設定されていない場合、24時間後に再確認する案内もあります。(Microsoft Learn)
確認項目は次のように整理できます。
| 確認項目 | 見るべきポイント |
|---|---|
| 回答者数 | 過去サーベイの実績値と一致しているか |
| スコア | 質問ごとの平均値や分布が元データと大きくずれていないか |
| 組織階層 | マネージャー配下、部署、拠点が期待どおりに表示されるか |
| トレンド | 現在のViva Glint項目と過去項目が正しくつながっているか |
| 属性別分析 | 表記ゆれでグループが分裂していないか |
| コメント | 件数、表示範囲、匿名性、切り捨ての有無を確認する |
特に、回答者数と質問別スコアは、元データと照合しやすい指標です。最初にここが一致していない場合、ダッシュボード上の高度な分析を見る前に、ファイルやマッピングを見直してください。
新機能への移行準備チェックリスト
Microsoft Viva: Viva Glint – Self service for historical importsの一般提供に備えるなら、今から次のチェックリストを進めておくと効果的です。
| チェック項目 | 完了の目安 |
|---|---|
| 現行の履歴インポート手順を文書化した | 誰が、いつ、どのファイルで、どの画面から実行するか分かる |
| 過去サーベイ一覧を作成した | 実施日、対象者、質問数、回答スケール、ベンダーが分かる |
| 質問マッピング表を作成した | 過去質問とViva Glint項目の対応理由が説明できる |
| 属性値の正規化ルールを決めた | 部署名、拠点名、職種名などの表記ゆれを統一できる |
| メールアドレス・従業員IDを照合した | 旧メール、現メール、退職者、ID変更を確認済み |
| テスト用データを用意した | 正常系と代表的なエラー系を検証できる |
| 権限設計を見直した | 実行者、承認者、レビュー担当が分かる |
| 失敗時の戻し方を決めた | バックアップ、再インポート、関係者連絡手順がある |
新機能がGAになったら、最初に見るべきポイントは「画面が簡単か」ではありません。重要なのは、既存手順と比べて、必要ファイル、必須項目、プレビュー内容、エラー表示、完了後のレポート反映がどう変わったかです。
まとめ：GA前にデータ品質と運用ルールを整えておく
Microsoft Viva: Viva Glint – Self service for historical importsは、Viva Glintに過去のサーベイデータを取り込む作業を簡素化する機能です。2026年12月の一般提供が予定されており、既存のAdvanced Configurationsを使った履歴インポートに対する代替手段として位置付けられています。(Microsoft)
管理者が今やるべきことは、新機能を待つことではなく、過去データを安全に取り込める状態に整えることです。具体的には、質問マッピング、メールアドレス・従業員IDの照合、属性値の正規化、定期インポートとの調整、テストデータの準備を進めてください。
履歴インポートは、過去と現在をつなげる便利な機能です。一方で、古いデータや不整合な属性をそのまま取り込むと、意思決定を誤らせる原因にもなります。Viva Glintの新しいセルフサービス機能を活用するには、操作手順だけでなく、「比較してよいデータか」を判断する運用ルールまで整備しておくことが重要です。
コメント