お問い合わせ
AUTOMATION NOTE — 120

Google Workspace 会議室ノーショーを自動キャンセルする設計

PUBLISHED2026.06.04
READ7 分
CATEGORYAUTOMATION

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 確認で通知のみ」構成だ。スクリプトの実装量が少なく、誤検知があっても自動削除が起きないため、安心して試せる。

設計の進め方をまとめると、次の順序で進むのが安全だ。

  1. 対象会議室と猶予時間を決め、例外パターンを洗い出す
  2. 通知のみモードでスクリプトを本番稼働させる
  3. 2〜4 週間ログを確認し、誤検知率を測る
  4. 許容範囲内であれば自動キャンセルモードへ切り替える
  5. 必要に応じて Meet 参加確認を追加し、検知精度を上げる

小さく始めて検証しながら範囲を広げる。会議室運用の自動化設計では、このリズムが一番長続きする。

コーポレートITのご相談はお気軽に

この記事で書いたような業務改善・自動化の設計から実装まで、DRASENASではコーポレートITの現場に寄り添った支援を行っています。 「まず相談だけ」でも大歓迎です。DRASENAS 公式サイトからお気軽にどうぞ。

CONTACT

御社の IT 部門、ここにあります。

「ITのことはあまりわからない」── そのような状態からで、まったく問題ございません。まずはお気軽にご相談ください。

無料相談を予約する → サービス詳細を見る
一社ずつ、一から。