Google Workspace MCPのOAuthを確認する。11月11日以降に止めない準備
公開日 ・更新日
Google Workspace MCPをAI agentから使っている場合、OAuthクライアントの設定を11月11日までに確認する必要があります。Googleの開発者向け更新では、agenticとして指定されていないクライアントからのWorkspace MCPリクエストを11月11日から拒否し、11月12日時点でも指定がなければMCPを呼べない状態が続くと案内されています。AI agent用と通常のREST API用を分ける考え方から、切り替え前の確認手順まで整理します。
11月11日から拒否条件が変わる
対象となるのは、Google Workspace MCPサーバーへOAuthで接続するアプリや連携です。Google Auth Platformのクライアント設定で、Use this client for an AI-powered agentを選んだagenticクライアントが必要になります。AI agentではなく、Google WorkspaceのREST APIだけを呼ぶアプリは、この変更の影響を受けません。MCPを使っているか分からないまま設定だけを変えると、別の連携まで止める可能性があるため、最初に接続先を棚卸しします。
まずOAuthクライアントを棚卸しする
管理画面とアプリの設定を照合し、クライアントID、利用している環境、接続するWorkspaceサービス、MCPかREST APIかを一覧にします。開発、検証、本番で同じクライアントを共有している場合は、どの環境が11月11日の変更に影響するかを分けて記録します。秘密情報そのものを一覧へ写す必要はありません。識別子と保管場所、担当者だけを確認できれば、作業の範囲を決められます。
AI agentとREST APIを分ける
一つのOAuthクライアントをAI agent機能と通常のREST API機能で共有している場合、GoogleはAI agent用に別のクライアントを作り、既存の非agent機能用クライアントはそのまま保つ方法を示しています。分離すると、MCPの権限や変更が通常の業務連携へ波及しにくくなります。新しいクライアントへ切り替える前に、どのサービスを読めるか、書き込めるか、人の確認が必要な操作は何かを一覧にします。
切り替え前に小さく試す
本番の全ユーザーを一度に切り替えず、検証用のアカウントと限定したデータで接続を試します。読み取りだけの操作、作成や更新を伴う操作、権限不足時のエラーを分けて確認し、実行ログにクライアント識別子と実行者を残します。MCPサーバーはDeveloper Previewとして案内されているため、利用できる機能や管理方法が変わる前提で、切り替え前の状態へ戻す手順も用意します。
権限と停止手順を残す
切り替えが終わったら、agentic指定を行った日、承認した人、接続確認の結果、問題が起きた場合に古いクライアントへ戻す方法を記録します。11月11日を過ぎて接続できない場合は、同じリクエストを繰り返すのではなく、クライアントの指定、環境変数、リダイレクト設定、権限の順に確認します。Google Workspace MCPの導入範囲とOAuthの分離を一緒に整理したい場合は、COZITOへご相談ください。
関連記事
著者: 松井 勇樹