Microsoft Teamsの「Shared & Delegate Mailbox Scheduling for Events」は、秘書、Chief of Staff、部門アシスタントなどが、リーダー本人やチーム代表のメールボックスを使ってTeamsイベントを予約しやすくする更新です。結論から言うと、招待メールの送信元を個人アカウントではなく、選択した共有メールボックスまたは代理対象メールボックスにそろえられるため、参加者から見た信頼性と運用の一貫性が高まります。公式ロードマップ上では、対象はMicrosoft Teams、ステータスは開発中、一般提供は2026年6月予定、プラットフォームはDesktopとMacです。(Microsoft)
一方で、この機能は「公開されたら全社でそのまま使えばよい」という単純な更新ではありません。Teamsのイベントポリシー、Exchange Onlineの共有メールボックス権限、Send As／Send on behalf権限、表示名、運用ルールを整理しておかないと、招待元の混乱や送信権限エラーにつながります。Microsoft 365ロードマップのリリース時期や説明は予定情報であり、変更される可能性がある点も押さえておきましょう。(Microsoft)
Microsoft TeamsのShared & Delegate Mailbox Scheduling for Eventsで何が変わるのか
この更新のポイントは、Teamsイベントを「実際に操作しているユーザー」だけでなく、「組織として見せたい送信元」から予約・招待しやすくなることです。
たとえば、社長秘書が全社会議を予約する場合、従来は秘書個人の名前が目立ち、参加者が「誰のイベントなのか」を迷うことがありました。Shared & Delegate Mailbox Scheduling for Eventsでは、リーダー本人の委任メールボックスや、[email protected] のような共有メールボックスを選び、より自然な送信元で招待を送れるようになる予定です。
| 項目 | 公式情報上の内容 | 実務での意味 |
|---|---|---|
| 機能名 | Microsoft Teams: Shared & Delegate Mailbox Scheduling for Events | Teamsイベント予約時の送信元・代理運用に関する更新 |
| 対象サービス | Microsoft Teams | Teamsの会議・イベント運用担当者が主な対象 |
| 主な用途 | 共有または委任メールボックスを使い、リーダーやチームの代理でイベントを整理 | 秘書、Chief of Staff、部門アシスタント、イベント事務局向け |
| 対象クラウド | Worldwide（Standard Multi-Tenant） | 一般的な商用Microsoft 365テナント向け |
| 対象プラットフォーム | Desktop、Mac | 現時点のロードマップではWeb、モバイルは明記されていない |
| 提供状態 | In development | まだ開発中。展開前の準備が必要 |
| GA予定 | 2026年6月 | 2026年6月に一般提供予定。ただし予定変更の可能性あり |
| 公開・更新日 | UTCでは2026年5月15日22時台、日本時間では2026年5月16日 | 2026年5月16日公開・更新情報として扱える |
共有メールボックスと代理メールボックスの違いを整理する
今回の更新を理解するには、「共有メールボックス」と「代理メールボックス」を分けて考える必要があります。
共有メールボックスは、複数人で利用する代表メールボックスです。例として、[email protected]、[email protected]、[email protected] などがあります。参加者から見ると、個人ではなくチームや窓口から招待されたように見えるため、社内外イベントの案内に向いています。
代理メールボックスは、特定のユーザーの代わりに別のユーザーが操作する形です。たとえば、役員本人の予定表やメールボックスに対して秘書が適切な権限を持ち、役員の代理でイベントを設定するケースです。
| 利用パターン | 向いている場面 | 招待元の考え方 | 注意点 |
|---|---|---|---|
| 共有メールボックス | 全社イベント、部門説明会、採用イベント、顧客向けウェビナー | チームや事務局名で一貫して見せる | 表示名、所有者、送信権限を事前に整理する |
| 代理メールボックス | 役員会議、リーダー主催イベント、顧客との重要会議 | リーダー本人または代理関係を明確に見せる | Send AsとSend on behalfの違いを理解しておく |
| 個人アカウントのまま予約 | 小規模な通常会議、担当者個人の会議 | 操作した本人が主催者として見える | 異動・退職・担当変更時に継続性が弱い |
この機能で重要なのは、「誰が操作したか」よりも「参加者にどの送信元として信頼してもらうか」を設計できる点です。社外向けイベントでは、個人名よりも正式な部署名やイベント事務局名の方が、招待メールを見落とされにくくなります。
利用者にとってのメリット
利用者側の最大のメリットは、Teamsイベントの案内が分かりやすくなることです。
たとえば、部門横断の説明会を人事担当者Aさんが予約した場合でも、招待元が「人事部イベント事務局」と表示されれば、参加者はイベントの主体をすぐ理解できます。役員主催のタウンホールでも、秘書個人ではなく役員室やリーダー本人に紐づいた招待として扱えるため、メールの信頼性が上がります。
特に効果が出やすいのは、次のような場面です。
- 全社会議やタウンホールを、役員室や社内広報が代理で予約する
- ウェビナーを、営業企画やマーケティング部門の共有メールボックスから案内する
- 採用説明会を、採用チームの代表メールボックスで統一する
- 顧客向けイベントを、担当者個人ではなくカスタマーサクセス部門名で送る
- リーダーの予定調整を、Chief of Staffや秘書が代理で行う
受信者にとって、招待元の表示は小さな要素ではありません。特に外部参加者がいるイベントでは、「知らない個人名」よりも「正式な組織名」から届いた招待の方が、フィッシングや誤送信への不安を減らしやすくなります。
管理者が確認すべきTeams側の設定
この更新はTeamsのイベント予約に関わるため、まずTeams管理センターの会議・イベントポリシーを確認します。Microsoft Teamsには、会議、ウェビナー、タウンホールといった複数の開催形式があり、管理者は誰が作成できるかを会議ポリシーやイベントポリシーで制御できます。(Microsoft Learn)
特に確認すべきなのは、次の3点です。
| 確認項目 | 見るべき場所 | 確認の観点 |
|---|---|---|
| 誰がイベントを作成できるか | Teams管理センターのMeeting policies／Event policies | 秘書、イベント事務局、部門担当者に必要な権限があるか |
| ウェビナー作成の許可 | Events policies | 公開ウェビナーを誰でも作れる状態になっていないか |
| タウンホール作成の許可 | Events policies | 役員・広報など必要なユーザーに限定できているか |
| ポリシーの割り当て | ユーザー単位またはグループ単位 | 対象者に正しいポリシーが割り当たっているか |
| クライアント環境 | Teams Desktop／Mac | ロードマップ上の対象プラットフォームと一致しているか |
Teamsのイベントポリシーは、Teams管理センターの「Meetings」配下から作成・編集できます。また、ユーザーには会議ポリシーとイベントポリシーがそれぞれ1つずつ割り当てられる仕様です。(Microsoft Learn)
ウェビナーについては、Teams管理センターのEvents policiesでWebinars設定をオン／オフできます。さらに、参加可能範囲を「Everyone」または「EveryoneInCompanyExcludingGuests」から選ぶ設定もあります。社外向けウェビナーを扱う部門では、この設定を公開範囲の管理とセットで確認してください。(Microsoft Learn)
タウンホールについても、Teams管理センターまたはPowerShellで、誰が作成・実行できるかを管理できます。既に予定されたタウンホールがあるユーザーに対して設定をオフにすると、そのユーザーがタウンホールを実行・開始できなくなる可能性があるため、変更前に既存イベントを棚卸しすることが重要です。(Microsoft Learn)
Exchange Online側で確認すべき権限
Shared & Delegate Mailbox Scheduling for Eventsの実務上の成否は、Exchange Onlineのメールボックス権限に大きく左右されます。Teamsで送信元を選べるようになっても、対象メールボックスに対する権限設計が不十分だと、招待の作成や送信でエラーになる可能性があります。
Microsoftの説明では、共有メールボックスは適切な権限を持つユーザーが「Send as」または「Send on behalf」で送信できます。また、共有メールボックスにアクセスするユーザーはライセンス付きのExchange Onlineメールボックスを持つ必要がありますが、共有メールボックス自体は条件を満たす範囲では個別ライセンスなしで利用できます。共有メールボックス用アカウントで直接サインインする用途ではなく、サインインはブロックしておくべきです。(Microsoft Learn)
特に間違いやすいのが、Full Accessと送信権限の違いです。Full Accessはメールボックスを開いて内容を管理するための権限であり、それだけではSend AsやSend on behalfの権限にはなりません。(Microsoft Learn)
| 権限 | できること | Teamsイベント運用での注意点 |
|---|---|---|
| Full Access | メールボックスを開き、内容を閲覧・管理できる | 送信権限ではない。招待送信には別途Send AsまたはSend on behalfが必要になる場合がある |
| Send As | 対象メールボックスそのものから送信されたように見える | 代表メールボックス名で統一したいイベントに向く |
| Send on behalf | 「代理で送信」したことが分かる形で送信される | 役員やリーダーの代理運用で透明性を出したい場合に向く |
| メールボックスの予定表権限 | 予定表の閲覧・編集に関係する | イベント予約や変更の実運用に影響する可能性がある |
Exchange Onlineでは、Full Access、Send As、Send on behalfの各権限をEACまたはPowerShellで管理できます。Send AsとSend on behalfの両方を持つ場合、Send Asが使用される点も運用ルールとして把握しておきましょう。(Microsoft Learn)
展開前に作るべき運用ルール
この機能は便利ですが、自由に使わせると「どのメールボックスから招待すべきか」が属人化します。GA前に、少なくとも次のルールを決めておくと混乱を防げます。
| 決めること | 推奨される判断基準 | 例 |
|---|---|---|
| どのイベントで共有メールボックスを使うか | 参加者が多い、社外参加者がいる、組織名で案内すべきイベント | 全社説明会、顧客向けウェビナー、採用説明会 |
| どのイベントで代理メールボックスを使うか | リーダー本人の主催性を明確にしたいイベント | 役員タウンホール、部門長主催会議 |
| 誰に権限を付与するか | 実際に予約・変更・再送する担当者に限定 | 秘書、Chief of Staff、イベント事務局 |
| Send AsとSend on behalfのどちらを使うか | 完全に代表名で送るか、代理関係を明示するか | 事務局名ならSend As、役員代理ならSend on behalf |
| 表示名をどうするか | 受信者が一目で正式な送信元と分かる名前にする | 「株式会社〇〇 採用イベント事務局」 |
| 退職・異動時の権限削除 | 人事異動フローに組み込む | 月次で権限棚卸し |
実務では、共有メールボックスを増やしすぎないことも大切です。イベントごとに代表メールボックスを作ると、管理が煩雑になり、権限削除漏れや表示名の不統一が起きやすくなります。まずは「役員室」「社内広報」「採用」「マーケティングイベント」など、継続的に使う単位に絞るのが現実的です。
GA前後の展開手順
2026年6月の一般提供予定に向けて、管理者は段階的に準備するのがおすすめです。ロードマップ情報は変更される可能性があるため、公式ロードマップとMicrosoft 365管理センターのメッセージセンターを併せて確認しながら進めてください。
| タイミング | 作業 | 目的 |
|---|---|---|
| GA前 | 対象イベントの棚卸し | どの会議・イベントで共有／代理メールボックスを使うべきか決める |
| GA前 | 共有メールボックスと表示名の確認 | 参加者から見て信頼できる送信元に整える |
| GA前 | Teamsイベントポリシーの確認 | ウェビナーやタウンホールを作成できるユーザーを整理する |
| GA前 | Exchange Online権限の確認 | Full Access、Send As、Send on behalfを必要最小限で付与する |
| GA直後 | 少人数でテスト | Desktop／Mac環境で招待元、予定表、更新通知の挙動を確認する |
| GA後 | 本番展開 | 対象部門へ手順書を共有し、利用ルールを固定する |
| GA後 | 権限棚卸し | 異動者、退職者、不要な代理権限を削除する |
テストでは、単にイベントを作成できるかだけでなく、次の観点まで確認してください。
- 参加者に届く招待メールの送信元が想定どおりか
- 返信やキャンセル通知がどのメールボックスに届くか
- イベント更新時の通知が正しく送られるか
- 代理担当者が変更・キャンセルできる範囲はどこまでか
- 外部参加者に表示される送信元名が分かりやすいか
- モバイルやWeb版Teamsで同じ操作ができると誤解されていないか
ロードマップ上の対象プラットフォームはDesktopとMacです。Web版やモバイルでの利用可否は、展開時点の公式情報と実機検証で確認してください。(Microsoft)
開発者・自動化担当者が注意すべき点
Power Automate、Microsoft Graph、独自のイベント管理システムなどでTeamsイベントやOutlook予定表を扱っている場合、この更新は「主催者」「作成者」「送信元」の扱いを見直すきっかけになります。
特に注意したいのは、次のような実装です。
| 既存の前提 | 起きやすい問題 | 見直しポイント |
|---|---|---|
| イベント作成者＝送信元と決め打ちしている | 共有メールボックスからの招待を正しく扱えない | 作成者、主催者、送信元を別項目として扱う |
| 個人メールアドレスを通知テンプレートに埋め込んでいる | 代表メールボックス運用と表示が食い違う | 送信元表示名を設定値として管理する |
| 退職者のアカウントを起点にイベントを作っている | 後から変更・キャンセルが困難になる | 共有メールボックスやサービス運用アカウントの設計を見直す |
| 代理権限を手作業で付与している | 権限漏れや削除漏れが起きる | 棚卸し手順や申請フローを整備する |
| Teamsクライアント差を考慮していない | Desktopでは動くが他環境では使えない可能性がある | 対象クライアントを明記して利用者に案内する |
現時点のロードマップ項目には、API仕様変更や既存イベントの自動移行についての記載はありません。そのため、開発者は「新しい予約方法が追加される可能性がある」と捉え、既存の自動化が送信元メールボックスの違いに耐えられるかを確認するのが安全です。
失敗しやすいポイント
Shared & Delegate Mailbox Scheduling for Eventsは、組織のイベント運用をきれいにする機能ですが、設定ミスがあると逆に混乱します。よくある失敗を先に潰しておきましょう。
| 失敗例 | 何が起きるか | 対策 |
|---|---|---|
| Full Accessだけ付与して送信できると思い込む | 招待送信や送信元選択で権限エラーになる可能性がある | Send AsまたはSend on behalfも必要に応じて設定する |
| 共有メールボックスに直接サインインさせる | セキュリティ上望ましくない運用になる | 共有メールボックスのサインインはブロックし、代理ユーザー経由で使う |
| 表示名が曖昧なまま使う | 参加者が正式な招待か判断しづらい | 「部門名＋用途」が分かる表示名にする |
| 退職者や異動者の権限が残る | 元担当者がイベントやメールボックスにアクセスできる状態が続く | 月次棚卸しと人事異動時の削除をルール化する |
| 全員にイベント作成を許可する | 公開ウェビナーやタウンホールが乱立する | Teamsイベントポリシーで作成者を制御する |
| Web版・モバイルでも使えると案内する | 利用者から問い合わせが増える | 公式情報上の対象プラットフォームを確認して案内する |
特に、Send AsとSend on behalfの違いは利用者にも説明しておくべきです。Send Asは代表メールボックスそのものから送信されたように見える一方、Send on behalfは代理送信であることが分かります。社外イベントではSend As、役員の透明な代理運用ではSend on behalfなど、組織の信頼性と説明責任のバランスで選ぶとよいでしょう。
よくある疑問
GA予定の2026年6月になれば全テナントで同時に使えるのか
必ずしも同時とは限りません。Microsoft 365ロードマップは商用機能の予定時期と説明を示すものですが、情報は変更される可能性があります。展開開始後も、テナントやリリースリングによって利用可能になるタイミングがずれることがあります。(Microsoft)
既存のTeamsイベントは自動的に共有メールボックス運用へ変わるのか
公式ロードマップの該当項目には、既存イベントを自動移行するという説明はありません。現時点では、新しくイベントを作成・整理する際の選択肢が増える更新として捉えるのが妥当です。既存イベントの主催者や送信元を変更する必要がある場合は、展開後の仕様を確認してから個別に判断してください。(Microsoft)
Microsoft 365グループや配布リストでも同じように使えるのか
今回のロードマップ項目で明記されているのは、共有メールボックスと委任メールボックスです。Microsoft 365グループや配布リストが同じ対象になるとは読み取れないため、展開時点の公式ドキュメントや実機検証で確認する必要があります。
外部ユーザーに共有メールボックスの代理権限を付与できるのか
共有メールボックスを利用できるのは組織内のユーザーです。Microsoftの説明でも、Gmailアカウントのような組織外のユーザーに共有メールボックスへのアクセス権を付与することはできないとされています。外部パートナーと共同運営するイベントでは、社内担当者を正式な代理操作担当にする運用が必要です。(Microsoft Learn)
まず管理者が取るべき行動
Shared & Delegate Mailbox Scheduling for Eventsは、単なるTeamsの予約画面の改善ではなく、イベント招待の「信頼できる送信元」を整えるための更新です。特に役員イベント、全社説明会、採用イベント、顧客向けウェビナーを多く扱う組織では、2026年6月の一般提供予定を待つだけでなく、今のうちに権限と運用を整理しておく価値があります。
最初にやるべきことは、対象イベントの棚卸しです。次に、使うべき共有メールボックスを絞り、表示名を整え、TeamsイベントポリシーとExchange Onlineの送信権限を確認します。最後に、Desktop／MacのTeamsクライアントで少人数テストを行い、招待元、返信先、更新通知、キャンセル通知の挙動を確認してください。
この準備をしておけば、機能が展開されたときに「誰の名前で招待すべきか」「なぜ送信できないのか」で迷わず、信頼性の高いTeamsイベント運用へスムーズに移行できます。
コメント