web会議の会議室予約が二重予約になる理由｜決めるのは部屋側の設定
2026年9月29日
web会議の予約と会議室の予約は、同じカレンダーに並んで見えても、確定の仕組みが違います。web会議のURLは作った時点で確定します。会議室は依頼を出して、部屋の側が受けるか断るかを返す仕組みです。この記事では、その返事が3種類あること、受けるか断るかを決めているのが部屋ごとの設定であること、押さえた部屋が当日に外れる条件を、Microsoft と Google の公式ヘルプの記述から整理します。予約システムを増やす話は出てきません。
上位に並ぶのは「会議室予約システムの比較」
この言葉で検索すると、上位は会議室予約システムの比較記事で埋まっています。予約を1か所に集めれば重複は防げる、という筋立てです。それは正しくて、紙の予約表と口頭の押さえとカレンダーが並走している状態なら、まず1か所に集めるのが先です。
上位に無いのは、1か所に集めたあとでも重複が起きることと、その可否を決めているものが何かです。カレンダーで空きを見て、空いていたから取った。それでも重なる。この段の話を書いたページは見つかりませんでした。
「予約できた」の返事には3種類ある
会議室に依頼を出したときの返事は、承諾・仮・無視の3つに分かれます。厄介なのは、カレンダーの見た目では仮と承諾の区別が付きにくいことです。
承認待ちの予定を「仮」で置くか「空き」で置くかは、部屋ごとに切り替わります。Microsoft の Set-CalendarProcessing のリファレンスにある TentativePendingApproval の既定値は $true（仮として表示）で、$false にすると「承認を待っている会議出席依頼が予定表に空き時間として表示されます」。この場合、あなたが依頼を出した部屋は、ほかの人のカレンダーからは空いて見えます。
もう1つは、承認する人に依頼が届かない場合です。同じリファレンスの AutomateProcessing を AutoUpdate にすると「会議出席依頼は、代理人による承認まで予定表内で仮定されます」。そのすぐ下に注記があります。「会議室メールボックスでこの値を設定すると、代理人は要求を受け取りません」。承認待ちのまま、誰も承認できません。
そして、この既定値は部屋がいつ・どうやって作られたかで違います。 Exchange Online では、管理センターで作った部屋と2018年11月15日以降に PowerShell で作った部屋は AutoAccept、それより前に PowerShell で作った部屋は AutoUpdate が既定です。同じ社内でも、古い部屋と新しい部屋で挙動が違うことになります。
重複を断るかどうかは、部屋ごとの設定が決めている
重複を許すかどうかの設定は AllowConflicts で、既定は $false（競合は許可されない）です。$true にすると「定期的な会議シリーズは、予定が既存の予約と競合するかどうかに関係なく受け入れられます」。ここまでは設定名から想像がつきます。
想像がつかないのはこの先です。Microsoft は「会議室が予約されている場合でも、会議室を予約できます」というサポート記事（KB 3066068）を出しています。症状は「既に別の会議用に予約されている会議室で会議をスケジュールしようとすると、予定表アテンダントは競合する会議出席依頼を自動的に拒否しません」。そして原因として名前が挙がっているのは AllowConflicts ではありません。
> この問題は、会議室メールボックスの AllRequestOutOfPolicy プロパティが True に設定されている場合に発生します。 これにより、会議室メールボックスは競合する会議出席依頼を無視します。
AllRequestOutOfPolicy は本来「ポリシー外の依頼を出すことを全員に許可するか」の設定です（既定は $false）。重複を許可したつもりがないのに、重複が通る状態になっていることがある、という話です。管理者に「二重予約を許可する設定を切ってほしい」と頼むとき、探す場所が1つではありません。
定期の商談は、1回ずつではなくシリーズで判定される
週1回の定例商談のように繰り返す予定は、回ごとではなくシリーズ単位で判定されます。ここは Microsoft と Google で向きが逆でした。
Exchange 側は厳しい方向です。ConflictPercentageAllowed（重複許容率）と MaximumConflictInstances（最大重複許容数）の既定値はどちらも 0 で、「値が 0 の場合、新しい定期的な会議の出席依頼に重複は許可されません」と書かれています。AllowConflicts が $false のときは「競合の数または割合が ConflictPercentageAllowed または MaximumConflictInstances パラメータ値よりも大きい場合、シリーズは拒否されます」。既定のままなら、20回のうち1回重なっただけでシリーズ全体が断られる側に入ります。
Google 側は通す方向です。Google カレンダーのヘルプには「定期的な予定の場合は、予定の半分以上で会議室を利用可能であり、8 回以上利用不可にならないようにしてください」とあります。半分以上空いていれば通るので、一部の回だけ部屋が無い状態のまま予定が立ちます。 20回の定例で7回ぶん部屋が無くても、シリーズは成立します。
同じページには、見た目と判定がずれる例も挙がっています。終日の予定に会議室を足すと「予定は協定世界時（UTC）の午前 0 時から翌日の午前 0 時として扱われるため、カレンダー上で空きがあるように見えても、予約が拒否されることがあります」。
押さえた部屋が、当日に外れることも入れ替わることもある
取れた部屋が、そのまま当日まで残るとは限りません。
Microsoft Places の自動リリースは、公式の手順ページで「設定可能な時間枠内にチェックインする人がいない場合、スペースは自動的に解放され、他の人が予約できるようになります」と説明されています。既定のポリシーは10分です。 チェックインの手段は Teams パネル・Teams Rooms のコンソール・Teams チャットで、パネルはアプリのバージョンが 1449/1.0.97.2024061108 以降である必要があります。オンラインの商談を自席から繋ぐつもりで部屋を取っただけだと、チェックインされないまま解放されます。
Google 側にも、参加者が辞退したときに部屋の予約を取り消す管理設定があります。ただしこのページで挙げられている取り消されない条件が細かいです。開始まで10分未満の辞退、開始まで30分以内に設定された会議、部屋のカレンダーで直接取った予約、4時間を超える会議、20人以上が参加する会議、外部のゲストだけの会議、サブカレンダー上の予約。この一覧は「効く／効かないを予定の中身で判定している」ということで、同じ運用でも会議によって結果が変わります。
入れ替わる場合もあります。Google には使用できない会議室を自動的に置き換える機能があり、すでに予約されている部屋や施設から削除された部屋の代わりを探します。条件は同じ建物・同じ設備・参加者数に見合う大きさで、対象は収容人数70人までの会議室です。予定は通りますが、入っている部屋が最初に選んだ部屋とは違います。
そもそも受け付けない条件が、依頼を出す前に決まっている
重複とは別に、依頼そのものが通らない線が引かれています。商談で当たりやすいのは次の3つです。
1つ目。相手が作った招待に自社の会議室を足す形は、既定では通りません。ProcessExternalMeetingMessages の既定は $false で、「外部差出人からの会議出席依頼は拒否されます」。日程調整を相手に任せた商談で、部屋だけ自分で足したいときは、自社側でも予定を立てることになります。
2つ目。先の日付が取れません。BookingWindowInDays は「最大何日前からリソースを予約できるようにするか」で、既定は180日です。半年以上先の商談は、部屋だけ後から取る形になります。
3つ目。長さの上限があります。MaximumDurationInMinutes の既定は1440分（24時間）で、定期的な会議では「このパラメーターの値は会議の各回の長さに適用されます」。1日を超える枠で押さえておく使い方はできません。
ここまでの設定はすべて部屋の側に付いていて、依頼を出す画面からは見えません。通らなかった理由を自分の操作から推測するのは難しいので、断られた返信メールの文面をそのまま管理者に渡すのが早いです。 断る理由を返信に含めるかどうかも EnableResponseDetails で切り替わり、既定は含める（$true）側です。
Meetnectの話
Meetnect はブラウザだけで動くオンライン商談ツールです。Meetnect がカレンダーに作る予定には、会議室も出席者も付いていません。 入るのは商談のURLと開始時刻、それに開始から1時間の枠だけです。会議室を使うなら、その予定にカレンダー側で部屋を足すことになり、通るかどうかはこの記事に書いた部屋側の設定が決めます。日程が動いたときにカレンダー側から追従する範囲はリスケの記事に書いたとおりで、追うのは開始時刻だけです。部屋の予約まで一緒に動かすことはしていません。