Google Workspace には会議室の自動解放機能が標準搭載されているが、「出席者全員が辞退した場合のみ」という条件付きで、承諾済みなのに誰も来ないノーショーには対応していない。この記事では、Google Workspace 会議室のノーショーを GAS（Google Apps Script）と Calendar API で補完する設計判断を整理する。
この記事を読んだほうが良い人
- Google Workspace のカレンダーリソース（会議室）を管理している情シス担当者
- ノーショーが常態化していて、自動化による解決を検討している人
- 組み込みの自動解放機能に限界を感じていて、独自の対策を検討している人
組み込み機能の限界：標準の会議室解放では届かない範囲
Google Workspace には「Release unused Calendar meeting rooms（未使用の会議室を自動解放）」という機能がある。Google Workspace Updates ブログによると、2023年3月6日からサポート対象エディションでデフォルト有効になった。
対象エディションは Enterprise Standard / Enterprise Plus / Education Fundamentals / Education Standard / Education Plus / Teaching and Learning Upgrade と旧 G Suite Business に限られる。Business Starter / Business Standard / Business Plus / Enterprise Essentials / Nonprofits / Frontline は対象外だ。
この機能がリリースするのは「主催者以外の出席者全員が辞退した場合」のみ。次のケースには対応していない。
- 出席承諾（RSVP ステータスが accepted）済みなのに誰も会議室に来なかった
- そもそも RSVP を返さないまま（needsAction のまま）会議が始まった
- 辞退はしていないが全員リモートで参加していて、物理的な入室がなかった
また、会議時間が4時間超 / 収容人数20名以上の部屋 / 開始30分以内のイベント / 外部ゲストが1人でも含まれる会議 / セカンダリカレンダーの予約なども対象外となる。
100名規模の会社では Business エディション帯を使っているケースも多く、組み込み機能が使えないまま「承諾したのに来なかった」ノーショーが積み重なる状況が起きやすい。
ノーショー検知の3アプローチを比較する
A: 経過時間トリガー + RSVP 状態確認
GAS のタイム駆動トリガーを使い、会議開始から N 分後にスクリプトを実行する方式だ。CalendarApp の getEventsForDay() で進行中のイベントを取得し、getGuestList() の各参加者の getGuestStatus() が GuestStatus.YES（承諾済み）かどうかを確認する。承諾済みの参加者が1人もいなければ「幽霊予約」と判定する。
長所: 実装が比較的シンプル。追加の認証設定（後述の DWD）が不要。
短所: 「承諾したけど来なかった」ノーショーは検知できない。RSVP ベースの判定に留まる。
B: Google Meet 参加者確認
Google Meet の会議が紐付いているイベントであれば、Meet REST API の participants リソースを参照して、実際に会議に参加したユーザーを確認できる。開始から N 分後に参加者がゼロであれば、ノーショーと判定する。
長所: 「承諾したが Meet にも現れなかった」というハイブリッド会議のノーショーを高精度で検知できる。
短所: Meet REST API へのアクセスにはドメイン全委任（DWD: Domain-Wide Delegation）を持つサービスアカウントの設定が必要で、GAS 単体の実装よりも構成が複雑になる。対面オンリーの会議には機能しない。
C: 手動チェックイン（QRコード方式）
会議室の扉付近に QR コードを設置し、入室時にスキャンすると GAS の Web アプリ（doPost エンドポイント）へ記録が送られる仕組み。カレンダーイベントと突き合わせることで、物理的な入室を確認できる。
長所: RSVP や Meet とは無関係に実際の入室を検知できる。
短所: QR コードの設置・運用ルールの周知・スキャン忘れの例外処理が必要で、3つの中で運用コストが最も高い。
選択の目安
| アプローチ | 検知精度 | 実装コスト | 対面専用会議に有効か |
|---|---|---|---|
| 経過時間 + RSVP 確認 | 低〜中 | 低 | 限定的 |
| Meet 参加者確認 | 高（ハイブリッド限定） | 中（DWD 設定が必要） | △ |
| QR コード入室確認 | 高 | 高 | ○ |
最初の導入としては「経過時間 + RSVP 確認で通知のみ」構成から始め、運用が安定したら Meet 参加確認を段階的に追加するのが現実的だ。
自動キャンセルか通知のみかの判断基準
通知のみにすべき場面
- 導入初期で誤検知率がまだわかっていない段階（最初の 2〜4 週間は通知のみで運用する）
- キャンセルが他の社内システム（受付管理・来訪者対応など）と連動している
- 会議室数が少なく、人手で最終確認できる規模（目安として6室以下）
自動キャンセルに踏み切れる場面
- 通知のみ運用で 2〜4 週間、誤検知率が許容範囲に収まったと確認できた後
- 会議室が多く、手動フォローが現実的でない規模
- 繰り返し予約のノーショーが多く、手動対処の件数が毎週多数発生している
どちらのモードでも、処理後は予約オーナーへの通知メールを必ず送る。予約が突然消えた事実が当人に伝わらないと、運用トラブルの原因になる。
GAS と Calendar API による自動化スケルトン
design_judgment 記事のため全 API 引数の列挙は省くが、処理フローと使うサービスの概念を示す。以下は「開始 N 分後に全会議室をチェックし、幽霊予約を検知する」スクリプトのスケルトンだ。
// タイム駆動トリガーで 10〜15 分おきに実行する
function checkNoShows() {
const ROOMS = [
'room-a@resource.calendar.google.com',
// 管理対象の会議室リソースアドレスを追記
];
const GRACE_MINUTES = 15; // 開始から何分後に判定するか
const now = new Date();
ROOMS.forEach(roomEmail => {
// CalendarApp で対象リソースカレンダーを取得
const cal = CalendarApp.getCalendarById(roomEmail);
if (!cal) return;
// 今日のイベント一覧を取得
const events = cal.getEventsForDay(now);
events.forEach(event => {
const start = event.getStartTime();
const elapsedMin = (now - start) / 60000;
// GRACE_MINUTES 以上経過 & まだ終わっていないイベントのみ対象
if (elapsedMin < GRACE_MINUTES || now > event.getEndTime()) return;
// 参加者の中に「承諾済み（YES）」がいるかチェック
const anyAccepted = event.getGuestList().some(
g => g.getGuestStatus() === CalendarApp.GuestStatus.YES
);
if (!anyAccepted) {
// 幽霊予約と判定 → 通知 or キャンセル処理を実行
handleNoShow(event, roomEmail);
}
});
});
}
上記はあくまで概念スケルトンだ。実際の実装では、繰り返しイベントへの対応・スプレッドシートへのログ記録・エラーハンドリングが別途必要になる。
運用開始前のポリシー設計チェックリスト
自動化を動かす前に、以下の点を事前に決めておく。
- 対象リソースの洗い出し: どの会議室を自動化対象にするか。経営会議室など例外扱いにする部屋はないか
- 猶予時間: 開始から何分後に判定するか（標準は 10〜15 分。重要会議は 30 分の例外設定を検討）
- 通知先: キャンセル・アラートの通知は予約オーナーのみか、情シスにも CC するか
- キャンセル後の再予約: Calendar API でキャンセルしたイベントは即時空き状態になる。再予約の連絡方法を通知メールに含めるか
- 例外イベントの識別方法: 4時間超の長時間予約・全社会議など、誤検知リスクが高い予約を除外するロジック
- スクリプトの実行権限: 管理者アカウントで GAS を実行するか、サービスアカウント + DWD で動かすか
- ログ保存: 何を根拠にキャンセルしたかの記録をスプレッドシートか Cloud Logging に残す
- 段階導入の計画: 最初の 2〜4 週間は通知のみモードで試験運用し、誤検知率を確認してから自動キャンセルへ切り替える
できないこと・制限事項
設計の誠実さとして、現時点の技術的な限界を整理する。
物理的な在室確認は Calendar API だけではできない
RSVP ステータスや Meet 参加ログはあくまで代替指標だ。「承諾したが物理的に来なかった」ケースの自動検知は、在室センサーや NFC / QR コードによるチェックイン仕組みとの組み合わせが必要になる。
Meet 参加確認には追加の認証設定が必要
Meet REST API を GAS スクリプトから参照するには、ドメイン全委任（DWD）を持つサービスアカウントの設定が別途必要だ。Workspace のエディションによって DWD の利用条件が異なるため、事前にエディション仕様を確認する。
リソースカレンダーの管理権限が必要
スクリプトを実行するアカウントは、対象リソースカレンダーに対して「変更と予約の管理」権限を持っている必要がある。一般ユーザーアカウントで実行しても、会議室イベントの変更・削除はできない。
Business Starter / Standard / Plus は組み込み機能の対象外
前述の通り、標準の「Release unused Calendar meeting rooms」機能は Business エディション帯では利用できない。GAS による補完が最初の選択肢になる。
まとめ：段階的に設計を積み上げる
ノーショー対策の設計は、検知精度と実装コストのトレードオフだ。
最初の一歩として最も現実的なのは「経過時間トリガー + RSVP 確認で通知のみ」構成だ。スクリプトの実装量が少なく、誤検知があっても自動削除が起きないため、安心して試せる。
設計の進め方をまとめると、次の順序で進むのが安全だ。
- 対象会議室と猶予時間を決め、例外パターンを洗い出す
- 通知のみモードでスクリプトを本番稼働させる
- 2〜4 週間ログを確認し、誤検知率を測る
- 許容範囲内であれば自動キャンセルモードへ切り替える
- 必要に応じて Meet 参加確認を追加し、検知精度を上げる
小さく始めて検証しながら範囲を広げる。会議室運用の自動化設計では、このリズムが一番長続きする。
コーポレートITのご相談はお気軽に
この記事で書いたような業務改善・自動化の設計から実装まで、DRASENASではコーポレートITの現場に寄り添った支援を行っています。
「まず相談だけ」でも大歓迎です。DRASENAS 公式サイトからお気軽にどうぞ。
※ この記事は DRASENAS Blog の転載です。オリジナルではコードや設定手順が随時アップデートされています。