Employee Self-Service agentの2026年4月更新で注目すべき点は、従業員がMicrosoft 365 Copilot上の会話から来訪者を事前登録できる「ゲスト招待」の拡張パターンがMicrosoft公式ドキュメントで具体化されたことです。これは完成済みの来訪者管理アプリが追加されたというより、Copilot Studioのトピック、Adaptive Cards、バックエンドAPIを組み合わせて、自社の受付・施設管理システムへつなぐための実装例と考えると分かりやすいです。Microsoft Learnの該当ページは2026年4月23日に更新されています。(Microsoft Learn)
Microsoft 365管理者、ワークプレイスIT、総務・施設管理チームにとっての実務上のポイントは、「Employee Self-Service agentをHR/IT問い合わせ窓口にとどめず、受付・ロビー・施設運用のセルフサービス基盤として拡張できる」ことです。特にグローバル拠点を持つ企業では、来訪者登録、建物選択、訪問目的の入力、受付通知、エラー時の案内を標準化しやすくなります。
Employee Self-Service agentの最新動向：ゲスト招待拡張パターンで何が変わったか
今回の更新では、Employee Self-Service agentを「Invite a Guest」、つまり来訪者招待の業務フローに拡張する具体例が示されました。Microsoftの説明では、Employee Self-Service Copilot agentは、管理者が構成したナレッジソース、HCM、ITシステムなどから従業員の問い合わせに回答できるエージェントとして位置付けられています。さらに、組み込みトピックと並行して独自トピックを作成・発行できる拡張可能な設計であることも明記されています。(Microsoft Learn)
今回のゲスト招待パターンは、その拡張性を施設・ロビー業務に応用するものです。従業員は、たとえば「取引先を来週火曜に東京オフィスへ招待したい」といった自然文から手続きを始め、必要情報をフォームで補完し、バックエンドのゲスト管理APIへ登録できます。
重要なのは、Employee Self-Service agentが単なるFAQチャットボットではなく、会話、フォーム、API実行、結果通知をつなぐ業務実行インターフェイスとして使われる点です。
| 観点 | 従来のよくある運用 | 今回の拡張パターンで狙える運用 |
|---|---|---|
| 来訪者登録 | 社内ポータル、メール、受付システムを別々に操作 | Copilot上の会話から登録を開始 |
| 入力フォーム | 固定フォームにすべて手入力 | 自然言語から訪問目的や場所を事前入力 |
| 建物選択 | ユーザーが拠点名や建物名を覚える必要がある | バックエンドAPIから建物一覧を取得して表示 |
| 確認・通知 | 登録後の確認が別画面やメールに分散 | 成功・失敗を会話内で返す |
| 管理者側の拡張 | 専用アプリ開発が中心 | Copilot StudioのトピックとHTTP APIで構成 |
今回の更新は「新機能」よりも「実装パターンの提示」と捉える
今回の内容を読むうえで、最も誤解しやすいのは「Employee Self-Service agentにゲスト招待機能が標準搭載された」と受け取ってしまうことです。
Microsoftのドキュメントでは、Copilot StudioにEmployee Self-Service agentをインストールしていること、Copilot Samplesへのアクセス、サンドボックスまたは運用前環境へのMakerアクセス、そして建物一覧取得とゲスト招待作成に使うゲスト管理APIへのアクセスが前提条件として示されています。また、例ではゲスト管理システムをAzure上に構築されたカスタムソリューションと仮定しています。(Microsoft Learn)
つまり、今回の更新は次のように理解するのが実務的です。
| 誤解しやすい理解 | 実務での正しい理解 |
|---|---|
| Microsoftが来訪者管理システムを提供した | 自社のゲスト管理APIへ接続する拡張例が公開された |
| すぐ全社展開できる | サンドボックスや運用前環境での検証が前提 |
| Copilotだけで完結する | 建物情報、招待作成、通知処理はバックエンド連携が必要 |
| ノーコードだけで済む | YAML、HTTP API、状態変数、エラー処理の理解が必要 |
| 受付業務だけの話 | 施設、総務、セキュリティ、ID管理、監査にも関係する |
Microsoft 365管理者は、これを「Copilot StudioでEmployee Self-Service agentを業務システムへ接続するための参考アーキテクチャ」として評価するべきです。
ゲスト招待パターンの仕組み
このパターンは、大きく分けて「トピック」「Adaptive Cards」「コネクタ／HTTP API」の3要素で構成されます。Microsoftのドキュメントでも、RE&F、つまりReal Estate & Facilities領域のEmployee Self-Service拡張には、トピック、Adaptive Cards、コネクタの理解が必要だと説明されています。(Microsoft Learn)
トピックで会話の流れを定義する
Copilot Studioのトピックは、会話がどのように進むかを定義するワークフローです。ゲスト招待では、ユーザーの自然言語入力をトリガーにして、招待シナリオを起動します。たとえば、次のような入力が想定できます。
「来週の水曜日にベンダーの佐藤さんを大阪オフィスに招待したい」
この一文から、エージェントは「ゲスト招待の意図」を判断し、必要に応じて訪問日、訪問目的、建物、ゲスト情報などを確認します。Microsoftのドキュメントでは、トピックがトリガープロンプトの定義、必要情報の取得、ゲスト登録フォームの提示、バックエンドAPI呼び出し、API応答の解釈に使われると説明されています。(Microsoft Learn)
ここで重要なのは、トピックを「会話の台本」としてだけでなく、業務プロセスの制御ポイントとして設計することです。
たとえば、会社のポリシーとして「個人ゲストは勤務時間内のみ」「海外拠点では受付承認が必要」「一度に登録できるゲストは1名まで」といった条件がある場合、トピック内の条件分岐や状態変数で制御する必要があります。
Adaptive Cardsで入力の抜け漏れを防ぐ
ゲスト招待では、会話だけで全項目を正確に入力させるよりも、フォーム形式で確認させるほうがミスを減らせます。そこで使われるのがAdaptive Cardsです。
Microsoftは、Adaptive CardsをJSONで作成されるプラットフォーム非依存のUIスニペットとして説明しています。Copilot Studioのエージェントでは、テキスト、グラフィック、ボタンなどを含むリッチな会話体験を作るために利用できます。(Microsoft Learn)
ゲスト招待フォームでは、少なくとも次のような項目が必要になります。
| 入力項目 | 実務上の確認ポイント |
|---|---|
| ゲストの姓・名 | ローマ字表記が必要な拠点では入力ルールを明示する |
| メールアドレス | 招待メール送信に使う場合は形式チェックが必要 |
| 訪問目的 | 面接、商談、納品、個人訪問など分類を決めておく |
| 訪問先の建物 | APIで取得した建物一覧から選択させると誤入力を防げる |
| 訪問日時 | タイムゾーン、営業時間、休日ルールを考慮する |
| 受け入れ担当者 | 監査や受付確認に必要な場合が多い |
自然言語から一部の値を事前入力できる点も、今回のパターンの実用的なポイントです。Microsoftのドキュメントでは、ユーザーのクエリから訪問目的と場所を判断し、ゲスト招待フォームへ自動入力するための「応答のカスタマイズ」ノードが紹介されています。ただし、このノードはユーザー体験を高めるための任意要素として扱われています。(Microsoft Learn)
実務では、自動入力された値をそのまま登録するのではなく、フォーム上でユーザーに確認させる設計が安全です。特に建物名、日付、ゲストメールアドレスは誤登録の影響が大きいため、確認ステップを省略しないほうがよいでしょう。
HTTP APIでゲスト管理システムへ登録する
会話とフォームで集めた情報は、最終的にバックエンドのゲスト管理APIへ送信されます。Microsoftの例では、HttpRequestActionコンポーネントを使って、建物一覧の取得や招待作成APIへのHTTP呼び出しを行う流れが説明されています。(Microsoft Learn)
この部分は、Microsoft 365管理者だけで完結しないことが多い領域です。ワークプレイスIT、施設管理システムの担当者、ID管理チーム、セキュリティ担当者との連携が必要になります。
実装前に、最低限次のAPI仕様を確認しておきましょう。
| 確認項目 | 確認すべき内容 |
|---|---|
| エンドポイント | 建物一覧取得、招待作成、キャンセル、更新の有無 |
| 認証方式 | OAuth、APIキー、証明書、Microsoft Entra ID連携など |
| 必須パラメーター | 氏名、メール、日時、建物ID、訪問目的、ホスト情報 |
| レスポンス形式 | Record、Table、Stringなど、Copilot Studio側の受け取り型 |
| エラーコード | 入力不備、権限不足、重複登録、営業時間外、API障害 |
| 監査ログ | 誰が、誰を、いつ、どの拠点に招待したかを追跡できるか |
APIの接続先URLだけを置き換えて動かそうとすると、レスポンス型や必須ヘッダーの不一致で失敗しやすくなります。MicrosoftのFAQでも、API URL、HTTPメソッド、ヘッダー、本文、レスポンスデータ型、状態変数、エラー処理ロジックの確認がトラブルシューティング項目として示されています。(Microsoft Learn)
Microsoft 365管理者が見るべき更新ポイント
今回の更新は、Copilot Studioの作成者だけでなく、Microsoft 365管理者にも関係します。なぜなら、Employee Self-Service agentの公開、認証、利用範囲、チャネル制御が全社のガバナンスに直結するからです。
Microsoftの公開手順では、Employee Self-Service agentはTeamsチャネルとMicrosoft 365 Copilotチャネルで動作するように設計されている一方、現在はMicrosoft 365 Copilot内で動作するように設計されていると説明されています。また、Teams単体のエクスペリエンスとして利用すると、エラーや機能破損が起きる可能性があるため、TeamsからCopilotへのリダイレクトやTeams側でのブロックが選択肢として示されています。(Microsoft Learn)
管理者が最初に確認するべきこと
導入検討時は、いきなりサンプルYAMLを取り込むのではなく、次の順番で確認すると失敗しにくくなります。
| 優先度 | 確認項目 | 理由 |
|---|---|---|
| 高 | Employee Self-Service agentが対象環境に導入済みか | 前提条件を満たさないと拡張作業に進めない |
| 高 | Copilot StudioのMaker権限が適切か | 誰でも業務APIを追加できる状態はリスクになる |
| 高 | ゲスト管理APIが利用可能か | このパターンの中核はバックエンド連携 |
| 高 | 認証方式と権限スコープ | 来訪者情報は個人情報を含む可能性がある |
| 中 | 対象拠点と建物マスター | グローバル展開では建物名・タイムゾーンが課題になる |
| 中 | 受付・セキュリティ部門の運用 | 登録後の確認、入館証、通知の流れを合わせる必要がある |
| 中 | 公開範囲 | まずパイロットユーザーに限定するのが現実的 |
特に注意したいのは、Employee Self-Service agentの拡張を「便利機能の追加」として扱わないことです。来訪者登録は、物理セキュリティ、個人情報、社外秘エリアへのアクセス、受付オペレーションに関係します。Microsoft 365側のアプリ公開だけでなく、施設管理側の業務責任者を巻き込む必要があります。
ビジネスユーザーにとって何が便利になるのか
ビジネスユーザーにとっての価値は、来訪者登録のために別のポータルや受付システムを探さなくてよくなることです。
たとえば、従来は次のような手間がありました。
| シーン | 従来の負担 | Employee Self-Service agentで改善できる点 |
|---|---|---|
| 商談前の来訪者登録 | 受付システムのURLを探す | Copilotに自然文で依頼できる |
| 建物名の選択 | 正式な拠点名が分からない | 候補一覧から選べる |
| 訪問目的の入力 | 毎回同じ内容を入力 | 会話文から事前入力できる |
| 登録完了の確認 | メールや別画面で確認 | 会話内で完了メッセージを確認できる |
| 入力ミス | 日付や場所を間違える | フォームで最終確認できる |
ただし、ユーザー体験を良くするには、エージェントの応答文を業務に合わせて調整することが重要です。
たとえば、単に「ゲスト招待が作成されました」と返すだけでは不十分な場合があります。実務では、次のような情報を含めると使いやすくなります。
| 完了メッセージに含めたい情報 | 目的 |
|---|---|
| ゲスト名 | 登録対象の確認 |
| 訪問日時 | 日時の誤り確認 |
| 訪問先建物 | 拠点・建物の誤り確認 |
| 招待メール送信状況 | ゲストに案内が届くかの確認 |
| 受付への通知状況 | 当日の受付対応の確認 |
| 変更・キャンセル方法 | 予定変更時の導線確保 |
このあたりはMicrosoftのサンプルをそのまま使うのではなく、自社の受付フローに合わせてSendActivityコンポーネントや条件分岐を調整するべきです。Microsoftのドキュメントでも、成功時・失敗時のメッセージは該当するSendActivityコンポーネントを変更してカスタマイズできると説明されています。(Microsoft Learn)
実装前に決めておくべき業務ルール
ゲスト招待パターンは、技術的にはトピックとAPI連携で構成できます。しかし、実装の成否を左右するのは業務ルールです。ルールが曖昧なまま作り始めると、後から例外対応が増え、エージェントの会話が複雑になります。
まず決めるべきルール
| ルール | 決めるべき内容 |
|---|---|
| 招待できるゲスト種別 | 取引先、候補者、個人ゲスト、配送業者など |
| 招待できる人数 | 1回につき1名か、複数名を許可するか |
| 対応する操作 | 新規登録のみか、変更・キャンセルも対象にするか |
| 承認の要否 | 特定拠点・特定ゲスト種別で上長承認が必要か |
| 利用可能時間 | 休日・営業時間外・深夜訪問を許可するか |
| 通知先 | ゲスト本人、ホスト、受付、警備、施設管理 |
| 保持期間 | 来訪者情報をどのくらい保持するか |
| 多言語対応 | 英語、日本語、現地語で案内を出すか |
Microsoftのサンプルでは、1回のゲスト訪問のみをサポートし、新しい訪問のみを対象とし、既存訪問の編集やキャンセルはサポートしない制限を適用するノードが紹介されています。ただし、これらの制限は任意であり、不要であれば対応する変数や条件ノードを削除できると説明されています。(Microsoft Learn)
ここは実務上かなり重要です。最初から複数ゲスト、変更、キャンセル、承認、代理登録まで詰め込むと、テスト項目が急増します。初期導入では「新規の単一ゲスト招待」に絞り、利用状況を見て拡張するほうが現実的です。
導入手順の実務イメージ
Microsoftのドキュメントでは、Copilot Studioで空白からトピックを追加し、コードエディターにCopilot SamplesリポジトリのInvite a Guest topic YAMLを貼り付け、HttpRequestActionのURLプロパティを自社バックエンドに合わせて更新する流れが示されています。(Microsoft Learn)
実務では、次のような段階に分けて進めると安全です。
| フェーズ | 作業内容 | 成果物 |
|---|---|---|
| 要件整理 | 対象拠点、ゲスト種別、登録項目、通知先を整理 | 業務要件メモ |
| API確認 | 建物一覧取得API、招待作成API、認証方式を確認 | API仕様書、テスト用認証情報 |
| サンドボックス実装 | サンプルYAMLを取り込み、URLやヘッダーを調整 | 検証用トピック |
| フォーム調整 | Adaptive Cardの入力項目、ラベル、必須項目を調整 | 自社向けゲスト登録フォーム |
| エラー処理 | API失敗、必須項目不足、建物一覧取得失敗を分岐 | エラーメッセージ設計 |
| ユーザーテスト | 管理者、受付、一般ユーザーでテスト | 修正リスト |
| パイロット公開 | 特定部門・特定拠点に限定公開 | 初期運用フィードバック |
| 本番展開 | 利用範囲を段階的に拡大 | 運用手順、問い合わせ導線 |
この手順で特に重視したいのは、サンドボックスまたは運用前環境での検証です。Microsoftの前提条件にも、Copilot Studioのサンドボックスまたは運用前環境へのアクセスが含まれています。(Microsoft Learn)
ゲスト招待は、成功時だけでなく失敗時の体験が重要です。建物一覧が表示されない、APIが空のレスポンスを返す、認証エラーになる、といったケースを本番前に確認しましょう。
失敗しやすいポイントと対策
Employee Self-Service agentの拡張は、見た目以上に複数の領域が絡みます。特に以下のポイントでつまずきやすくなります。
| 失敗しやすいポイント | 起きる問題 | 対策 |
|---|---|---|
| API URLだけ変更してテストする | ヘッダー、本文、レスポンス型が合わず失敗する | API仕様に合わせてHttpRequestAction全体を見直す |
| 建物名を自由入力にする | 表記揺れで登録先が不明確になる | 建物一覧APIから候補を取得して選択式にする |
| 自然言語の事前入力を過信する | 訪問目的や場所を誤認識する | 登録前にAdaptive Cardで確認させる |
| エラー文が技術者向けになる | 一般ユーザーが次に何をすべきか分からない | 「再試行」「受付へ連絡」など行動を示す |
| 受付部門を後から巻き込む | 当日の運用とシステム登録が合わない | 設計段階から受付・警備・施設管理を参加させる |
| 全社一斉公開する | 拠点差分や例外で問い合わせが急増する | 1拠点・1部門からパイロット展開する |
| Teams利用を前提にする | 想定外の動作や混乱が起きる可能性がある | Microsoft 365 Copilot側での利用導線を明確にする |
MicrosoftのFAQでも、建物一覧が表示されない場合は建物取得APIの構成や応答変数、バックエンドAPIのコントラクト変更を確認するよう示されています。また、空白または想定外のレスポンスが返る場合は、要求ヘッダー、本文パラメーター、レスポンスデータ型、バックエンドAPIログを確認する必要があります。(Microsoft Learn)
グローバル企業で使う場合の追加注意点
今回の要点には「グローバル読者向けに扱える」とありますが、グローバル展開では日本国内だけの受付運用よりも考慮点が増えます。
タイムゾーンと日付表現
「来週月曜の10時」と入力された場合、ユーザーの所在地、訪問先拠点、ゲストの所在地が異なる可能性があります。登録APIへ渡す日時は、訪問先拠点のタイムゾーンで統一するのか、UTCで保持するのかを決めておく必要があります。
建物マスターの管理
グローバル拠点では、建物名、キャンパス名、受付名、フロア名が複雑になりがちです。Adaptive Cardに表示する選択肢は、人間に分かりやすい表示名と、APIに渡す建物IDを分けて管理すると安定します。
多言語の案内
ゲスト本人に送る招待メールや到着案内は、ホストの言語ではなくゲストの言語に合わせる必要がある場合があります。最初の実装では日本語・英語の2言語に絞り、将来的に拠点別テンプレートへ広げるのが現実的です。
個人情報と監査
ゲスト名、メールアドレス、訪問日時、訪問先は個人情報やセキュリティ情報に該当する可能性があります。保存先、保持期間、閲覧権限、監査ログ、削除依頼への対応を事前に確認してください。特に複数国で展開する場合は、地域ごとのプライバシー要件を法務・コンプライアンス部門と確認する必要があります。
今回の更新を活用すべき企業
このゲスト招待拡張パターンは、すべての企業がすぐ導入すべきものではありません。既存の受付システムや施設管理システムが成熟していない場合、まずバックエンド側の整備が必要です。
導入効果が出やすいのは、次のような企業です。
| 向いている企業 | 理由 |
|---|---|
| Microsoft 365 Copilotを社内展開している | 従業員がCopilot上で手続きを始めやすい |
| Copilot StudioでEmployee Self-Service agentを運用している | 既存のエージェント体験に追加しやすい |
| 複数拠点・複数ビルを持つ | 建物一覧取得や標準化の効果が大きい |
| 受付業務がメール・Excel・ポータルに分散している | 会話起点で手続きを集約しやすい |
| 施設管理APIや来訪者管理APIを持っている | 実装までのハードルが下がる |
| グローバル拠点で受付ルールを統一したい | 入力項目や通知フローを標準化できる |
一方、来訪者管理システムがAPIを提供していない場合や、受付フローが拠点ごとに大きく異なる場合は、Copilot側の実装より先に業務プロセスとAPI連携方針を整理するべきです。
まず実施すべきアクション
2026年4月更新の「Employee Self-Service gains a guest invitation extension pattern」は、Employee Self-Service agentを実務プロセスへ拡張するための分かりやすいサンプルです。特に、自然言語で依頼を開始し、Adaptive Cardsで情報を確認し、HTTP APIでゲスト管理システムへ登録する流れは、他の施設・総務・IT申請にも応用できます。
まずは次の3つを確認してください。
| 次のアクション | 確認すること |
|---|---|
| 現状把握 | Employee Self-Service agentとCopilot Studioの利用状況を確認する |
| API確認 | 建物一覧取得とゲスト招待作成のAPIが使えるか確認する |
| 小さく検証 | 1拠点・単一ゲスト・新規登録のみでサンドボックス検証する |
今回の更新を「ゲスト招待機能が増えた」と見るのではなく、「Employee Self-Service agentを社内業務APIへ安全につなぐ設計例が公開された」と捉えると、活用範囲が広がります。来訪者登録で検証した会話設計、フォーム入力、API連携、エラー処理の考え方は、施設チケット、備品申請、駐車場登録、社内手続きの自動化にも展開できます。
コメント