Microsoft 365 Copilot TechCommunityで「Spent hours trying to build an employee feedback workflow with Power Automate」という投稿を見つけ、「新機能が追加されたのか」「Power Automateの設定変更が必要なのか」と気になった人もいるでしょう。
結論からいうと、この投稿はMicrosoft 365 CopilotやPower Automateの製品アップデートではありません。Power Automate、Microsoft Forms、SharePointを使った従業員フィードバックの仕組みに苦戦している利用者が、より適切な構成を質問したフォーラム投稿です。
そのため、この情報だけを理由に、管理者が設定変更、更新、移行、追加ライセンスの購入を行う必要はありません。元ページでは「Forum Discussion」として掲載されており、投稿者は継続的なフィードバックを社員情報へ正しく紐付けられないことや、個人別に集計しにくいことを課題として挙げています。確認時点では返信も掲載されていません。(TECHCOMMUNITY.MICROSOFT.COM)
なお、指定情報では2026年6月12日公開・更新とされていますが、Tech Communityのページ上は「Jun 11, 2026」と表示されています。本記事では、日本時間を含む取得タイミングによる日付差を考慮し、2026年6月12日時点の情報として整理します。(TECHCOMMUNITY.MICROSOFT.COM)
結論：今回の変更点は製品変更ではなく、ワークフロー設計上の課題
今回の情報を、設定や料金への影響も含めて整理すると次のとおりです。
| 確認項目 | 結果 |
|---|---|
| 新機能・仕様変更 | 発表されていない |
| Microsoft 365 Copilotへの変更 | 確認できない |
| Power Automateへの変更 | 確認できない |
| 管理者による設定変更 | 不要 |
| 既存フローの更新 | 不要 |
| データやフローの移行 | 不要 |
| 料金変更 | 記載なし |
| 対応期限 | 記載なし |
| 主な対象者 | 従業員フィードバックの仕組みを構築する担当者 |
| 投稿の種類 | Microsoft Tech Community上のフォーラム相談 |
Microsoft Tech CommunityはMicrosoftが運営する情報共有サイトですが、掲載されている内容がすべてMicrosoft製品チームによる公式発表とは限りません。
今回のページには、展開時期、対象テナント、管理センターでの設定、ロードマップID、メッセージセンターIDなど、通常の製品変更で示される情報がありません。したがって、「Microsoft 365 Copilot TechCommunityに掲載された新機能」ではなく、「利用者が投稿した実装相談」として読む必要があります。
「Spent hours trying to build an employee feedback workflow with Power Automate」の内容
投稿者は、経営層から次のような仕組みを求められたと説明しています。
- 従業員同士が継続的にフィードバックを送れる
- Microsoft Teamsから利用できる
- フィードバックを従業員ごとに蓄積できる
- 過去のフィードバックを時系列で確認できる
投稿者はPower Automate、Microsoft Forms、SharePointを組み合わせて構築を試みました。しかし、Formsの回答を社員プロファイルへきれいに紐付けられず、対象者ごとの長期的な集計も難しいという問題に直面しています。(TECHCOMMUNITY.MICROSOFT.COM)
ここで重要なのは、問題の中心がPower Automateの機能不足ではなく、社員を識別するキーとデータ構造が決まっていないことです。
回答者とフィードバック対象者は別の人物
従業員フィードバックでは、少なくとも次の2人を区別する必要があります。
- フィードバックを入力した人
- フィードバックを受ける人
Microsoft Formsの「名前を記録する」設定で取得できるのは、基本的に回答者の情報です。フィードバック対象者は、別の設問や入力画面で選択させなければなりません。
対象者を自由入力の氏名で保存すると、表記揺れや同姓同名によって集計が崩れます。
たとえば、次の入力は人間には同じ人物に見えても、システム上は別の値です。
- 山田 太郎
- 山田太郎
- Taro Yamada
- 山田さん
表示名ではなく、Microsoft Entra IDのオブジェクトIDやUPNなど、社員ごとに識別できる値を保存する設計が必要です。
フィードバックと社員情報を同じ表で管理しない
社員名、部署、役職、コメント、評価、回答日時をすべて1つのSharePointリストへ詰め込むと、社員情報が変更されたときに過去データとの整合性を取りにくくなります。
実務では、次のように役割を分けると管理しやすくなります。
| データ | 主な項目 | 役割 |
|---|---|---|
| 社員マスター | オブジェクトID、UPN、表示名、部署、在籍状態 | 社員を一意に識別する |
| フィードバック履歴 | 対象者ID、回答者ID、回答日時、分類、コメント | 1回ごとのフィードバックを記録する |
| 集計データ | 対象者ID、期間、件数、分類別集計 | レポート表示を高速化する |
小規模な運用なら、社員マスターを別途作らず、フィードバック履歴へ対象者のオブジェクトIDと表示名の両方を保存する方法でも対応できます。
ただし、集計にはIDを使い、画面表示には氏名を使うという役割分担が重要です。
誰に影響する情報なのか
今回の投稿による直接的なサービス変更はありませんが、同じ仕組みを作ろうとしている担当者には参考になる内容です。
| 対象者 | 影響 |
|---|---|
| Microsoft 365の一般ユーザー | 画面や操作方法の変更はない |
| Microsoft 365管理者 | 必須の設定変更はない |
| Power Automate作成者 | 社員情報との紐付け方法を見直す必要がある |
| Power Platform管理者 | DLPポリシー、接続、所有者を確認する必要がある |
| 人事・マネージャー | 匿名性、閲覧範囲、利用目的を決める必要がある |
| 既存フローの運用担当者 | 今回の投稿だけを理由に更新する必要はない |
特に影響を受けるのは、Microsoft Formsの回答結果をそのままSharePointへ保存し、あとから社員別に集計しようとしている担当者です。
フォームを作り始める前に、誰をどの値で識別するかを決めておく必要があります。
設定・更新・移行・料金・期限で確認すべきこと
設定変更は不要だが、フォームの本人確認設定は重要
今回の投稿に伴う必須設定はありません。ただし、実際に従業員フィードバックを作る場合は、Microsoft Formsの回答者設定を先に決めます。
記名式にする場合は、回答対象を「組織内のユーザー」に限定し、「名前を記録する」を有効にします。匿名式にする場合は、名前を記録しない設定にします。Microsoft Formsでは、組織内ユーザーに限定したうえで、回答者名を記録するかどうかを選択できます。(マイクロソフトサポート)
ただし、名前を記録しない設定にしても、完全な匿名性が自動的に保証されるわけではありません。
回答者が少ない、自由記述に本人を特定できる内容が含まれる、回答時刻から推測できるといった場合は、回答者が判別される可能性があります。Microsoftの案内でも、質問内容や回答時刻などから個人を推測できるケースが示されています。(マイクロソフトサポート)
そのため、次の点を事前に決めておきましょう。
- 記名式か匿名式か
- 回答者情報を誰が閲覧できるか
- フィードバック対象者へ原文を公開するか
- 人事評価に利用するか
- データをいつまで保存するか
- 削除依頼へどう対応するか
Power Automateでは社員情報を取得してから保存する
Microsoftの公式手順では、FormsとPower Automateを連携する場合、次の流れが案内されています。
- 「新しい応答が送信されるとき」でフローを開始する
- 「応答の詳細を取得する」で回答内容を取得する
- 回答者のメールアドレスをOffice 365 Usersコネクタへ渡す
- 「ユーザープロファイルの取得（V2）」で社員情報を取得する
- 取得した情報を保存先へ登録する
公式ドキュメントでも、Formsの「Responders’ Email」をOffice 365 Usersの「Get user profile（V2）」へ渡す構成が紹介されています。(Microsoft Learn)
従業員フィードバックに応用する場合は、回答者だけでなく、フィードバック対象者についても同様に社員情報を解決します。
推奨するフローは次のとおりです。
| 順番 | Power Automateの処理 |
|---|---|
| 1 | Formsの新規回答を検知する |
| 2 | 回答の詳細を取得する |
| 3 | 回答者のプロファイルを取得する |
| 4 | フィードバック対象者のプロファイルを取得する |
| 5 | 対象者のオブジェクトIDまたはUPNを確定する |
| 6 | SharePointリストへ1件の履歴として保存する |
| 7 | 必要に応じてTeamsやメールで通知する |
| 8 | 失敗時の管理者通知とログを残す |
Teamsにはコメント全文を投稿せず、「新しいフィードバックが登録されました」といった通知だけを送り、閲覧権限を制御した画面へ誘導する方が安全です。
更新や移行は発生しない
今回の投稿には、既存フローの更新、コネクタの廃止、データ移行に関する記載はありません。
すでにForms、Power Automate、SharePointでフローを運用している場合も、今回の情報だけを理由に作り直す必要はありません。
Microsoft 365の正式な機能変更や対応期限は、Microsoft 365管理センターの「正常性」から「メッセージセンター」を開いて確認します。メッセージセンターは、新機能、変更予定、必要な管理者対応などを確認するための公式な情報源です。(Microsoft Learn)
Tech Communityで気になる投稿を見つけた場合は、次の情報があるかを確認すると、製品変更かユーザー投稿かを判断しやすくなります。
- メッセージセンターID
- Microsoft 365 Roadmap ID
- ロールアウト開始日
- 対象テナント
- 管理者が行う操作
- 廃止日や移行期限
これらがなく、ページ種別が「Forum Discussion」であれば、まずはコミュニティ上の相談や意見として扱うのが適切です。
料金変更は発表されていない
元投稿には、料金やライセンス変更に関する説明はありません。
Microsoft Forms、SharePoint、Office 365 Usersは、Power Automateのコネクタ分類ではStandardとして案内されています。(Microsoft Learn)
ただし、Standardコネクタであることは、すべての契約で無条件に追加費用なく使えることを意味しません。次の条件によって必要なライセンスが変わる可能性があります。
- 契約しているMicrosoft 365プラン
- Power Automateの実行方法
- PremiumコネクタやDataverseを追加するか
- Power Appsを入力画面として利用するか
- 組織外ユーザーを対象にするか
- 専用の従業員フィードバック製品を利用するか
料金を確認するときは、コネクタ名だけで判断せず、実際のフローで使用するすべてのサービスを一覧化してください。
対応期限はない
今回の投稿には、ロールアウト日、移行期限、廃止期限は設定されていません。
管理者が期限付きで対応する項目はありません。実際の製品変更を確認したい場合は、メッセージセンターでPower Automate、Microsoft Forms、SharePoint、Microsoft Teams、Microsoft 365 Copilotに関する通知を検索します。
従業員フィードバックを作る場合の推奨構成
小規模から中規模の社内運用であれば、次の構成から始めると設計しやすくなります。
Microsoft Forms
↓
Power Automate
↓
Office 365 Usersで社員情報を取得
↓
SharePointリストへ履歴を保存
↓
Teamsまたはメールで通知SharePointリストには、最低限次の列を用意します。
| 列名の例 | 用途 |
|---|---|
| FeedbackID | フィードバックの一意なID |
| TargetObjectID | フィードバック対象者のID |
| TargetUPN | 対象者のUPN |
| TargetDisplayName | 対象者の表示名 |
| SubmitterObjectID | 回答者のID |
| SubmittedAt | 回答日時 |
| Category | 称賛、改善提案、支援依頼などの分類 |
| Comment | フィードバック本文 |
| Visibility | 本人、人事、上司などの公開範囲 |
| Status | 未確認、確認済み、対応中などの状態 |
匿名運用にする場合は、SubmitterObjectIDを保存しない設計にします。ただし、Power Automateの実行履歴や接続先に回答者情報が残らないかも確認が必要です。
フィードバック対象者の選択方法を使い分ける
対象者の人数によって、入力方法を変えると運用しやすくなります。
| 対象規模 | 選択方法 |
|---|---|
| 数人から数十人 | Formsの選択肢として登録 |
| 対象者が固定 | 対象者ごとに専用フォームを作成 |
| 数百人以上 | Power Appsなどで社員検索画面を作る |
| 組織変更が多い | Entra IDやOffice 365 Usersから動的に取得 |
| 完全匿名の簡易アンケート | 対象部署やチームだけを選択させる |
社員数が多い環境で、氏名やメールアドレスを自由入力させる方法は避けましょう。入力ミスが発生すると、同じ社員のフィードバックが複数の値に分かれてしまいます。
Power Automateで失敗しやすいポイント
表示名を集計キーにする
同姓同名や氏名変更に対応できません。表示名は画面表示に限定し、集計にはオブジェクトIDやUPNを使います。
Formsの「名前を記録する」だけで設計を終える
取得できるのは回答者情報です。フィードバック対象者を別途識別する仕組みが必要です。
Teamsをデータ保存先として扱う
Teamsのチャネル投稿は通知や会話には向いていますが、人別・期間別の履歴管理には適していません。元データはSharePointやDataverseなどへ保存し、Teamsは入口または通知先として使います。
フィードバック本文を広い範囲へ通知する
フィードバックには、個人情報や人事上のセンシティブな内容が含まれる可能性があります。Teamsのチャネルへ原文を投稿せず、権限を設定した保存先へ誘導してください。
フローの所有者を1人だけにする
個人アカウントだけで運用すると、異動、退職、パスワード変更、アカウント無効化などによってフローが停止する可能性があります。
Microsoftのガイダンスでは、重要または長期間運用するフローについて、特定ユーザーへの依存を避けるため、サービスプリンシパルの利用が推奨されています。少なくとも共同所有者、接続の管理方法、障害時の担当者を決めておきましょう。(Microsoft Learn)
DLPポリシーを確認せずに作り始める
Power PlatformのDLPポリシーでは、どのコネクタ同士でデータを共有できるかを管理できます。管理者のポリシーによっては、作成したフローが保存できても実行時にブロックされる可能性があります。(Microsoft Learn)
本番開発の前に、Forms、Office 365 Users、SharePoint、Teamsなど、使用予定のコネクタが同じ環境で利用できるかを確認してください。
FormsとPower Automate以外の選択肢
継続的な従業員フィードバックは、目的によって適切なサービスが異なります。
| 選択肢 | 向いているケース | 注意点 |
|---|---|---|
| Forms＋Power Automate＋SharePoint | 独自項目を持つ小規模な社内フロー | データ設計、権限、集計を自作する必要がある |
| Power Apps＋Power Automate＋SharePoint | 社員検索や入力チェックが必要 | 開発工数とライセンス条件を確認する |
| Viva Pulse | マネージャーがチームの状態を定期的に把握する | 任意の社員間フィードバックとは目的が異なる |
| Viva Glint | 全社規模の従業員サーベイやエンゲージメント分析 | 導入範囲やライセンスを含めた検討が必要 |
Viva Pulseは、マネージャーやリーダーが調査ベースの質問を送り、チームの状態を継続的に把握するための軽量なサーベイツールとして案内されています。Viva Glintは、全社規模の従業員サーベイやエンゲージメント改善を支援するサービスです。(Microsoft Learn)
ただし、Viva Pulseは、社員が任意の同僚へ随時コメントを送る「ピアフィードバック台帳」とは目的が異なります。
次のように判断すると選びやすくなります。
- 社員同士の個別フィードバックを記録したい場合は、カスタムワークフロー
- チームの状態を定期的に把握したい場合は、Viva Pulse
- 全社の従業員意識を分析したい場合は、Viva Glint
- 社員検索や入力制御を重視する場合は、Power Apps
Viva Pulseを利用する場合は、有効なライセンスを持つユーザーへの割り当てが必要な機能があります。Microsoft 365管理センターで対象ユーザーと契約プランを確認してください。(Microsoft Learn)
管理者と作成担当者が確認する手順
今回の投稿を見て対応が必要か迷った場合は、次の順番で確認します。
- ページが「Blog」「Announcement」「Forum Discussion」のどれか確認する
- 投稿者がMicrosoft製品チームか一般のコミュニティ参加者か確認する
- メッセージセンターIDやロードマップIDがあるか確認する
- 展開日、対象テナント、期限、管理者アクションを確認する
- 同じ内容をMicrosoft 365メッセージセンターで検索する
- 既存フローへの影響がなければ、変更作業は行わない
- 新規構築する場合は、社員識別キーと閲覧権限から設計する
今回の情報については、設定変更や移行作業ではなく、従業員フィードバックを自作するときの設計上の注意事例として活用するのが適切です。
まとめ：必須対応はなく、作る場合は社員IDと権限設計を優先する
Microsoft 365 Copilot TechCommunityの「Spent hours trying to build an employee feedback workflow with Power Automate」は、Microsoft 365 CopilotやPower Automateの新機能を発表する情報ではありません。
設定変更、更新、移行、料金変更、対応期限はいずれも示されておらず、一般ユーザーや管理者に必須の作業はありません。
実際に従業員フィードバックの仕組みを作る場合は、フォーム作成より先に次の3点を決めてください。
- フィードバック対象者をどのIDで識別するか
- 記名式と匿名式のどちらにするか
- 誰がどの範囲まで閲覧できるか
小規模な独自運用ならForms、Power Automate、Office 365 Users、SharePointを組み合わせられます。チーム状況の定期調査や全社サーベイが目的なら、Viva PulseやViva Glintも比較対象に含めるとよいでしょう。
コメント