お問い合わせ
AUTOMATION NOTE — 132

Google Workspace 会議室を AI エージェントで最適化する

PUBLISHED2026.06.08
READ10 分
CATEGORYAUTOMATION

Anthropic の Claude Agent SDK は Python と TypeScript から利用できる自律型エージェント構築フレームワークとして、2026 年に本番利用が可能な状態になっています。Google Calendar API と組み合わせることで、GAS による単純なノーショー（会議室の予約無断欠席）キャンセルを超えた、予約パターン分析と自律的なリソース最適化フローを設計できます。

この記事を読んだほうが良い人

  • GAS による会議室ノーショー自動キャンセルをすでに運用しており、次のステップを探している情シス担当者
  • 会議室の予約率が低い時間帯・部門に偏りがあるが、人手をかけずに整理したい方
  • Claude Agent SDK を GWS 管理自動化に活用できるか、設計の判断軸が知りたい方

GAS と Claude Agent SDK：何が違うのか

会議室自動化の文脈でよく比較されるのが GAS (Google Apps Script) と Claude Agent SDK です。どちらも Calendar と接続できますが、設計思想が根本的に異なります。

次の表は、両者の特徴を会議室最適化の観点で整理したものです。

観点 GAS Claude Agent SDK
判断の性質 ルールベース（事前に定義した条件のみ） コンテキスト理解（状況を解釈して動的に判断）
利用パターン分析 集計は可能、判断は人間が担う 過去データを自律的に解釈して傾向を抽出できる
振替提案の生成 不可 可能（代替時間帯・会議室の提案文を自動生成）
実行環境 Google インフラ内（認証コストが低い） 外部サーバーまたはクラウド関数（Calendar API 経由）
Calendar 接続方法 Apps Script の Calendar サービス（スコープ設定が簡易） Google Calendar API + OAuth 認証（スコープ設計が必要）
セットアップコスト 低（GAS エディタで完結） 中〜高（API 認証・実行環境の整備が必要）
適した用途 開始 N 分後に参加者ゼロなら削除、などの単純ロジック 利用率の偏り検知・自律的なリソース解放・振替提案

GAS が「決めたルールを確実に実行する機械」なら、Claude Agent SDK は「状況を読んで判断する自律エージェント」という位置づけです。

具体例を挙げると、月曜の午前中に 5 室すべての会議室がブロック予約されているが、実際に参加者のチェックインが確認できているのは 2 室だけという状況が週次で繰り返されているとします。GAS のノーショーキャンセルは「開始 15 分後に参加者ゼロならキャンセル」という条件でしか動きません。ブロック予約者が念のため参加ボタンを押しながら実際には無人という場合、キャンセルはかかりません。Claude Agent SDK なら「会議室 A は月曜午前の過去 4 週間で参加者チェックイン確認率が 18%」という分析を自律的に出力し、解放候補として提示できます。GAS で検知できない構造的な空室問題を、会議室自動化 Google Workspace の次のステップとして解決する設計がここにあります。

「GAS で十分か、Agent SDK が必要か」の判断フロー

すべての情シス担当者が Agent SDK へ移行すべきかというと、そうではありません。以下の観点で判断するのが実務的です。

GAS で十分な条件

  • ノーショー判定の基準が固定で変わらない（例：開始 15 分後に参加者ゼロ）
  • 対象の会議室数が少なく、適用ルールが単純
  • 外部 API 接続の運用コストを増やしたくない
  • エージェントの誤判断に対するリスク許容度が低い

Claude Agent SDK が有効な条件

  • 部門別・曜日別・時間帯別など多変数の利用傾向を分析したい
  • ノーショーかどうかの判定を「状況に応じて柔軟に調整」したい
  • 予約者への振替提案メッセージを自動生成したい
  • 複数の会議室リソースをまたいで需要バランスを最適化したい

100 名規模の企業では、目安として会議室数が 5〜15 室程度で、予約数が 1 日あたり 20〜60 件程度になるケースが多い。このボリュームになると「月・水の午後が予約で埋まっているのに実際には空室が多い」「特定部門が会議室を複数ブロック予約している」といった偏りが発生しやすくなります。GAS の時間ベースキャンセルでは検知できないこうした問題に、Claude Agent SDK は対応できます。

なお、どちらか一方を選ぶ必要はなく、「GAS で単純キャンセルを動かしながら、Claude Agent SDK で週次の分析レポートを生成する」という併用構成も現実的です。特に最初の段階では、エージェントに書き込み権限を与えずに分析専用で使い、人間が判断するフローから始めると導入リスクが低くなります。

Claude Agent SDK で設計する自律最適化フロー

Claude Agent SDK は、エージェントに対して「何をするか」をプロンプトで指示し、エージェントが自律的にツールを呼びながら処理を進める仕組みです。

会議室最適化の設計では、次の 3 フェーズをひとつのエージェントにまとめるか、サブエージェントとして分けるかを最初に決めます。

フェーズ 1: 分析

過去 2 週間の会議室リソースカレンダーの予約データを取得し、実使用率・キャンセル率・部門別傾向を算出します。このフェーズは読み取り専用なので、Calendar API の読み取りスコープだけで完結します。エージェントの出力イメージは「会議室 B（10 名収容）は月曜・木曜 10〜12 時の予約率が 87% だが、参加者チェックイン確認率は 22%。過去 2 週間で 7 回の予約のうち入室確認ができたのは 2 回。」のような定量サマリーです。なお、「チェックイン確認」の具体的な定義は組織環境によって異なります。Calendar のイベント承諾ステータスをシンプルに使う場合もあれば、入退室センサーのログや会議システムの接続記録と組み合わせる場合もあります。自組織で追えるデータに合わせて指標を定義しておく必要があります。

フェーズ 2: 解放判断

使用率が低い会議室・時間帯の予約を「解放候補」として抽出します。判断基準はプロンプトで自然言語指示できるため、「祝前日は例外にする」「役員会議は除外する」「外部ゲストが参加しているイベントは対象外」といったルール追加も、プロンプトの変更だけで対応できます。コードを修正せずに判断ロジックを変えられる点が、GAS との最大の差です。閾値（使用率 30% 以下など）を設定ファイルから読み込んでプロンプトに注入する設計にしておくと、非エンジニアの情シス担当者でも変更しやすくなります。

フェーズ 3: 振替提案

解放候補の予約者に対して、代替の時間帯や会議室を含む通知ドラフトを生成します。たとえば「ご予約いただいている 10/14（月）10:00〜12:00 の会議室 B について、同時間帯に会議室 D（6 名収容・同フロア）が空いています。人数に問題なければ移動をご検討ください。」のような文章を自動生成します。最終送信は人間がレビューするフローにすることで、完全自動化と人間の判断を組み合わせた設計が可能です。

以下は、3 フェーズを束ねるエージェントのプロンプト設計イメージです。fetch_room_reservations などのカスタムツールは MCP (Model Context Protocol) サーバーとして実装し、mcp_servers オプションで Claude Agent SDK に登録します。ツール名は mcp__<サーバー名>__<ツール名> の形式で allowed_tools に指定します。

import asyncio
from claude_agent_sdk import query, ClaudeAgentOptions

SYSTEM_PROMPT = """
あなたは Google Workspace の会議室リソース最適化エージェントです。
以下の手順で分析・提案を行ってください。

1. 直近 2 週間の会議室予約データを取得する
2. 会議室ごとの実使用率（参加者チェックインが確認できた割合）を算出する
3. 実使用率が 30% 以下の会議室について、翌週以降の予約を解放候補として抽出する
4. 解放候補の予約者に送る振替提案のドラフトを作成する
"""

async def run_room_optimizer():
    async for message in query(
        prompt=SYSTEM_PROMPT,
        options=ClaudeAgentOptions(
            # カスタムツールは MCP サーバーとして実装し、mcp_servers で登録する
            # ツール名は mcp__<サーバー名>__<ツール名> 形式になる
            mcp_servers={
                "calendar": {
                    "command": "python",
                    "args": ["calendar_mcp_server.py"],
                }
            },
            allowed_tools=[
                "mcp__calendar__fetch_room_reservations",   # Calendar API ラッパー（要実装）
                "mcp__calendar__calculate_usage_rate",       # 使用率集計ツール（要実装）
                "mcp__calendar__draft_reschedule_message",   # 提案メッセージ生成（要実装）
            ],
        ),
    ):
        if hasattr(message, "result"):
            print(message.result)

asyncio.run(run_room_optimizer())

ポイントは、fetch_room_reservations の中身（Calendar API の具体的な呼び出し）を MCP サーバー側に集約し、エージェントから隠蔽している点です。エージェントは「どのツールをいつ呼ぶか」を自律的に判断するため、判断ロジックの変更はプロンプトを書き換えるだけで対応できます。Calendar API のコード側を触らずに挙動を変えられるのが Agent SDK の設計上の強みです。

カスタムツールの実装は、calendar_mcp_server.py として Google Calendar リソース管理 API の呼び出しを薄くラップする Python の MCP サーバーを作るのが出発点になります。ツール 1 本の責務を「1 種類のデータを取ってくる」に絞ることで、エージェントがどのツールをいつ組み合わせるかを自律的に決めやすくなります。

Calendar API 権限設計：最小スコープの考え方

Calendar API を使うエージェントを設計する際、OAuth スコープの範囲は慎重に設計します。Google Calendar API の公式ドキュメントによると、スコープには「読み取りのみ」「イベントの編集」「カレンダー全体の管理」など複数の段階があります。

分析フェーズだけなら読み取りスコープで十分

過去の予約データを取得して使用率を計算する処理は、イベントの読み取り権限だけで実現できます。書き込みスコープを付与しなければ、エージェントが誤って予約を削除するリスクが構造的に存在しなくなります。

書き込みスコープはリソースカレンダー専用のサービスアカウントに限定する

フェーズ 2 以降でイベントを更新・削除する場合は書き込みスコープが必要になります。このスコープは「すべてのカレンダーを編集できる」権限まで及ぶ可能性があるため、リソースカレンダー専用のサービスアカウントを作成し、そこに絞って付与する設計が安全です。

リソースカレンダーと個人カレンダーのスコープを分ける

会議室リソースカレンダーは組織固有の共有リソースです。一般ユーザーの個人カレンダーへのアクセス権と混在させると、意図しないデータアクセスが発生します。エージェントが触れるカレンダーをリソースカレンダーのみに限定することで、影響範囲を最小化できます。

管理コンソールの API アクセス制御を事前確認する

Google Workspace の管理コンソールでは、サードパーティアプリや内製ツールによる API アクセスを組織ポリシーで制限できます。エージェントのサービスアカウントが Calendar API へのアクセスを試みる前に、組織の API アクセス制御設定でブロックされないかを確認しておく必要があります。設定はセキュリティ関連の管理コンソールから参照できます。既存の GAS が動いている環境であれば基本的に通過できますが、サービスアカウント経由のアクセスは別ポリシーが適用される場合があるため、事前確認が必要です。

なお、Google Workspace のカレンダーリソース管理機能は、個人アカウントでは利用できません。Workspace アカウントの組織内リソースとして設定されている会議室のみが対象になります。

よくある設計ミスと対策

導入を進める中で、以下の 3 パターンで問題が起きやすい。

書き込みスコープを付けたまま本番移行する

プロトタイプ段階で「分析も削除も全部試したい」という理由でフル権限を付与し、そのまま本番に移行してしまうパターンです。エージェントがプロンプトの解釈を誤ると、対象外の予約を削除するリスクがあります。フェーズ 1（分析）は読み取り専用で本番稼働させ、フェーズ 2 以降に移行するタイミングで権限を別のサービスアカウントに分離するのが安全な順序です。

GAS トリガーとエージェントのスケジュールが重複する

既存の GAS が週次でノーショーキャンセルを実行している状態でエージェントも同じ会議室を対象に動かすと、重複削除や競合が発生します。エージェントを導入するタイミングで GAS のトリガーを一時停止するか、対象リソース ID を明示的に分けた上でそれぞれを起動する設計にします。どちらが何をやっているかを一覧化したドキュメントを先に作っておくと、切り替え判断が楽になります。

閾値をプロンプトに直書きする

「使用率 30% 以下を解放候補とする」をプロンプト文字列に埋め込んでしまうと、閾値変更のたびにプロンプト全体を書き直す必要が生じます。閾値・除外リスト・例外条件は設定ファイルから読み込んでプロンプトに注入する設計にしておくと、情シス担当者がコードを触らずにチューニングできるようになります。

導入前チェックリスト

エージェントを本番稼働させる前に、以下を確認します。

  • [ ] 現行の GAS による自動化処理をすべてドキュメント化したか（エージェントとの重複・競合を防ぐ）
  • [ ] Calendar API 接続用のサービスアカウントを作成し、リソースカレンダーのみに権限を限定したか
  • [ ] エージェントが読み取るカレンダーの対象範囲（リソース ID リスト）を明示的に定義したか
  • [ ] フェーズ 3（振替提案）を人間レビュー込みのフローにするか、完全自動にするかを決定したか
  • [ ] エージェントの判断ログを保存し、後から監査できる仕組みを確保したか
  • [ ] 閾値（使用率 30% 以下など）をプロンプト直書きではなく設定ファイルで管理しているか
  • [ ] GAS の既存トリガーとエージェントのスケジュールが重複していないか

まとめ：判断軸は「ロジックが固定かどうか」

GAS は変わらず有効なツールです。単純なノーショーキャンセルだけが目的なら、GAS の方が導入コストも運用コストも低い選択肢です。

Claude Agent SDK を選ぶ理由は、「判断を自動化したい」ときです。予約率・部門別傾向・曜日パターンを読んで「この予約は解放してよいか」を動的に判断し、振替提案まで自動生成するフローは、ルールベースの GAS では構造的に難しい。

設計判断の分岐点を 1 つに絞るなら、「判断ロジックが固定かどうか」です。固定なら GAS で十分、状況に応じて変化する判断が必要になったとき初めて Claude Agent SDK への移行を検討するのが現実的な順序です。

小さく始めるなら、まず分析フェーズ（読み取り専用）だけ Agent SDK でプロトタイプを作り、出力レポートを人間が確認する構成から試すことを勧めます。解放・提案の自動化は、分析精度に満足できてから段階的に追加する方が安全です。

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

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

CONTACT

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

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

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