web会議の変更通知が相手に届かない｜予定表と受信トレイは別
2026年10月3日
商談の時間を1時間ずらして更新を送ったのに、当日になって「変更、聞いていませんでした」と言われる。送信履歴には残っている。相手は迷惑メールを探したが無い。
調べると「迷惑メールフォルダを見てもらう」と「変更をお知らせするメールの例文」が並びます。この記事では、そこから一段手前にある話を書きます。変更は「相手の予定表」と「相手の受信トレイ」の2本の経路に分かれて進んでいて、片方だけ届くことが仕様としてあること。そして送った側からは、どちらが起きたのか見えないことです。出典はすべて本文に置きました。
上位に並ぶのは「迷惑メールを見てもらう」と「お知らせの例文」
「web会議 変更 通知 相手に届かない 迷惑メール」で上位に出てくるのは、大きく3つに分かれます。ひとつはサービス側のヘルプで、Webex の招待メールが届かない件と、Microsoft Q&A の「Outlook 予定表で発信された開催案内がメールで届かない」。ふたつめは個人のブログと解説記事で、Outlook で会議招集を変更しても参加者に通知されない、という話。みっつめは「会議場所の変更をメールで伝える例文」と、返信が来ないときの催促メールの書き方です。
どれも間違っていません。ただ、迷惑メールフォルダを探してもらう案と、文面を整える案は、どちらも「メールは相手に届いているはず」という前提に立っています。 その前提が崩れる型が、各社の公式ドキュメントに書かれていました。
Microsoft：変更の通知が受信トレイに出ないのは、仕様としてある
Exchange Online には VisibleMeetingUpdateProperties という組織全体の設定があります。Set-OrganizationConfig のリファレンスに、設定例とその結果がそのまま書かれています。
Set-OrganizationConfig -VisibleMeetingUpdateProperties "Location,Subject,Body,AllProperties:15"> In Exchange Online, this example results in meeting updates being auto-processed (meeting update messages aren't visible in attendee Inbox folders) except any changes to meeting location, subject and body as well as any property changes within 15 minutes of the meeting start time.
訳すと、この設定では会議の更新が自動処理され、更新のメッセージは出席者の受信トレイには見えなくなります。 例外は、場所・件名・本文の変更と、開始15分前以降の変更です。
ここで起きているのは「届かなかった」ではありません。メールは相手のメールボックスに届いていて、システムが中身を相手の予定表に適用したあと、メッセージのほうを受信トレイから外している。 相手の予定表は正しく書き換わっているのに、相手本人は何も見ていない、という状態です。
この設定は組織の管理者が PowerShell で変える値です。商談相手の会社がどの値で動いているかを、こちらから見る方法はありません。
既定値がどれなのかは、このページの該当箇所まで辿れませんでした。 既定でどの範囲まで自動処理されるかは書きません。分かるのは、こういう動きが設定として存在するということだけです。
同じ「受信トレイに出ない」に、別の原因もある
Microsoft には、もう1つ別の型のトラブルシュート記事があります。会議出席依頼や返信が受信トレイに表示されない（元の KB 番号 2966790）の症状は、こう書かれています。
> 会議出席依頼がユーザーに送信されると、会議はユーザーの予定表に仮の状態で正しく表示されますが、Outlook は要求を受信トレイにルーティングしません。 たとえば、要求は削除済みアイテム フォルダーに表示されます。
原因として挙げられているのは、受信メッセージの振り分け先を持つ内部のテーブル（MAPI 受信フォルダー）の設定が受信トレイになっていない、というものです。前の節の自動処理とは別で、メールボックス側の設定が壊れている型です。
目を引くのは、確かめ方のほうです。この記事が案内している調べ方は Exchange Online PowerShell で、Get-MailboxFolderStatistics で削除済みアイテムに入った会議アイテムの数を数え、Get-MessageTrace で特定のメッセージがどのフォルダに配信されたかを見る、という手順です。直す手順も MFCMAPI というツールでメールボックスの内部を触るもので、記事自身が「誤って使用すると、メールボックスが永続的に破損する可能性があります」と注意を付けています。
つまりこの型は、受け取る側の管理者だけが確かめられます。 送った側にできることは1つもありません。なおこの記事はクラシック版の Outlook for Windows 向けで、新しい Outlook や Teams で同じかは確かめていません。
Google：メールを送らなくても、相手の予定表は書き換わる
Google 側は、逆向きの食い違いが起きます。カレンダーの予定にゲストを招待するには、予定を更新するときの挙動がこう書かれています。
> メール通知を送信しないように選択することもできます。以下の場合を除き、ゲストのカレンダーは引き続き更新されます。
除外として並んでいるのは2つです。
> Google カレンダーのユーザーの設定が [知っているユーザーから届いた場合のみ追加] になっており、そのユーザーとやり取りが行われたことがなく、メールアドレスがそのユーザーの連絡先に登録されておらず、同じドメインに属していない。
> ユーザーがカレンダーに予定を自動的に追加しない設定を選択している。
予定を動かすと「変更内容をメールで送信しますか？」と聞かれます。ここで送らないほうを選んでも、相手の予定表の枠は動きます。 急いでいるときや、何度も直しているときに送信をスキップすると、相手の予定表だけが静かに書き換わります。
そして除外の2つに当たる相手では、逆のことが起きます。メールも行かず、予定表も動かない。初回の商談相手は「やり取りが行われたことがなく」「連絡先に登録されておらず」「同じドメインに属していない」の3つに当てはまる側から始まります。招待そのものが相手の予定表に入るかどうかは、web会議の招待を相手のカレンダーに入れるに分けて書きました。手で .ics を取り込んだ予定が後の変更を追いかけない話も、そちらにあります。
迷惑メールの側は、受け取る側だけの問題ではない
「迷惑メールを確認してください」とお願いする前に、送る側のドメインの話があります。Gmail のメール送信者のガイドラインは、要件を「すべての送信者」と「1 日に 5,000 件以上送信する送信者」で分けています。すべての送信者に求めているのは「SPF または DKIM」の設定で、そのうえでこう書かれています。
> 認証されていないメールは、迷惑メールに分類されたり、5.7.26 エラーで拒否されたりすることがあります。
5,000 件以上の側には、SPF と DKIM の両方と DMARC が求められ、さらに次の条件が付きます。
> ダイレクト メールの場合、送信者の From: ヘッダー内のドメインは、SPF ドメインまたは DKIM ドメインと一致している必要があります。
会議の招待や変更の通知は、差出人が主催者の名前で、実際に送っているのはカレンダーやツールのサーバーです。この「名前と送り出した場所が別」という形が、認証の論点に触れます。
Cisco はこの点を自分のヘルプに書いています。一部の出席者は出席者の招待メールを受信していませんには、「迷惑メールをブロックするスパムフィルターは、多くの場合、企業のメールサーバーにメール管理者によって導入されます。」とあり、続けてこう書かれています。
> Webex メールは自動メールサーバーから送信されます。これにより、招待状に特定のヘッダーが残ってしまい、参加者が招待状を受け取れない可能性があります。
ホスト側にできる案として招待の再送が挙がっていますが、実質的な解決は参加者の IT 部門が自社のメールサーバーのフィルタを調整することだ、という立て方になっています。
Zoom のZoom Scheduler の通知のトラブルシュートも同じ向きで、対処として並ぶのは「受信者に迷惑メールフォルダを確認してもらう」「Zoom のドメインを安全な送信者リストに追加してもらう」です。そのうえで、受け取る側のドメインまで名指しされています。
> For Yahoo email addresses, be aware that DMARC policy may block emails.
3社とも、最後の一手は相手側に渡っています。 送る側で持てるのは自分のドメインの認証までで、そこから先は相手の会社のフィルタです。
公式に書かれていなかったこと
当たった範囲で、分からなかったことを残します。
VisibleMeetingUpdatePropertiesの既定値。前述のとおり、当たったページでは設定例の説明までしか辿れませんでした。既定でどこまで自動処理されるかは示せません。- Zoom で予約済みの会議を変更したときに、参加者へ通知が行くのか。Making changes to a scheduled Zoom meeting を当てましたが、日時の変更や出席者の削除について、通知の有無が書かれていません。無いという意味ではなく、このページには書かれていないという意味です。
- ここに挙げた型を、自分で再現したわけではありません。他社のテナントを用意して試していないので、各社の公式の記述を並べただけです。
「届かない」は2種類ある
ここまでを、相手側で起きていることで分けると2つです。
1つめ、予定表は書き換わっていて、本人が知らない。 Microsoft の自動処理と、Google で送信をスキップした場合がこれです。当日の時間は合っているので、相手は正しい時刻に入ってきます。ただし「聞いていない」という状態のまま入ってくるので、直前の確認がすべて噛み合いません。
2つめ、予定表も元のままになる。 迷惑メールで止まった場合と、Google の除外2条件に当たる場合、相手が .ics を手で取り込んでいた場合がこれです。相手は前の時刻で待っています。
送った側の画面では、この2つが同じに見えます。送信は成功している。エラーも返っていない。どちらが起きたのかを区別する手がかりは、製品の中にありません。だからできることは、変更を伝える経路を、カレンダーの更新だけに依存させないことに寄ります。以下は公式の記述から導いた進め方で、効果は測っていません。
- 日時を動かしたら、カレンダーの更新とは別に、普通のメールを1本送る。 件名に新しい日時を入れます。カレンダーの更新メッセージは、ここまでに見たとおり受信トレイに出ないことがあります。
- 返信をもらうまで、変更は伝わっていないものとして扱う。 「予定表に入っているはず」を当てにしないという意味です。
- 変更の回数を減らす。 何度も直すほど、どの経路でどこまで届いたかが分からなくなります。定例の変更がどこまで遡って効くかは定期的な会議の変更は今回だけか以降すべてかに書きました。
- 予定を消すときも同じに考える。 消した側の操作がどこまで相手に届くかはweb会議の予定を削除に分けて書いています。表示されている時刻そのものがずれる型はweb会議の招待の時間がずれるです。
Meetnectの話
Meetnect は、商談相手に通知メールを一通も送りません。予約を作ると主催者の Google カレンダーに予定ができますが、src/worker.js のカレンダー連携には出席者を渡す部分（attendees）も、通知を送る指定（sendUpdates）もありません。入るのは主催者の予定表だけで、参加URLは予定の「場所」と「説明」に置かれます。だから相手に日時やURLを伝えるのは、この記事に書いた「普通のメール」の側です。カレンダー側で時刻を動かしたときに予約がどう追従するかは、商談のリスケで日程変更したとき、URLと予約はどう追従させるかに書きました。