連携ガイド
ZoomをAIエージェントに安全に連携する|権限・承認・監査の設計
ZoomをAIエージェントにつなぐと、会議の棚卸し、録画・文字起こしの要約、参加状況の分析を自動化できます。便利な一方で、録画には機微な会話が含まれ、会議の作成は招待につながる操作です。連携の前に権限設計を決めておくべきです。
Zoom連携でまず起きる問題
ZoomをそのままAIエージェントに渡すと、典型的に次の問題が起きます。
- OAuthトークンの散在:プロンプトやローカルのMCP設定に置いた認証情報は、漏れたときにZoomの操作が丸ごと露出します。
- 読み取りと書き込みが同じ扱い:参照も更新も、エージェントから見れば同じ「ツール呼び出し」です。区別がなければ、AIは同じ気軽さで実行します。
- 録画・会話の露出:録画や文字起こしには機微な会話が含まれ、必要以上に広く参照させるべきではありません。
読み取りは自由に、書き込みは承認制に
実務的な原則はシンプルです。参照系は自由に、更新系は人間の承認を経てから。Zoomの操作をこの2種類に仕分けます。
- 自由に実行してよい(読み取り):会議・録画・参加者・ユーザーの参照、会議一覧、録画一覧。要約や分析はここで完結します。
- 承認を挟む(書き込み):会議の作成(招待につながる)。参照対象の録画もロールで絞り、アクセスを監査に残します。
こうしておけば、AIエージェントは分析や下書きまで一人で走り切り、外部や本番に効く操作の直前だけ担当者が確認する、という運用になります。
生のOAuthトークンをエージェントに渡さない
もう一つの要点は認証情報の置き場所です。ZoomのOAuthトークンをエージェントのランタイムやプロンプトに置くのは避けます。 認証情報はサーバー側に暗号化して保管し、エージェントにはスコープ付きの権限トークンを1つだけ渡す。 こうすれば、あるワーカーのトークンが漏れても、失効はそのワーカーの範囲に限定でき、Zoom本体の認証情報を作り直す必要はありません。
すべての操作を監査ログに残す
会議・録画を扱う以上、「どのワーカーが・どの録画を・いつ参照したか」を後から追えることが重要です。 承認された操作もブロックされた操作も、ワーカー・ロール・ツール・接続・リクエスト・結果まで記録しておけば、 後からの調査や説明責任にそのまま使えます。
Grantryでの実現方法
Grantryは、AIエージェントと業務ツールの間に入る権限レイヤーです。 Zoomを含むMCP対応のサービスに対して、ワーカーごとにスコープ付きトークンを1つ発行し、 読み取りは自由に、会議作成などの書き込みは承認ゲート越しに、そして全コールを監査ログに残します。 Claude CodeやCodexなどのMCPクライアントを、ワーカートークン付きでGrantryのエンドポイントに向けるだけで、 エージェント側のコード変更なしに始められます。
よくある質問
AIエージェントにZoomのOAuthトークンを直接渡しても大丈夫ですか?
推奨しません。プロンプトやローカルのMCP設定に置いたOAuthトークンは、Zoomでできる操作すべて(例:会議の作成)を許す常時オファーになります。OAuthトークンはサーバー側に暗号化して保管し、エージェントにはスコープ付きの権限トークンを1つだけ渡す設計が安全です。
Zoomの会議の作成をAIに自動実行させても問題ないですか?
会議の作成は影響が大きい、または戻せない書き込みです。会議の参照などの読み取り・分析は自由に実行させ、会議の作成は人間の承認を経てから実行する承認ゲートを挟むのが実務的です。
録画の要約はさせたいが、範囲は絞れますか?
絞れます。ロールとスコープで参照できる会議・録画を限定し、要約や分析だけをAIに任せられます。会議の作成は承認制にでき、誰がどの録画を参照したかは監査ログに残ります。