目次
Google WorkspaceのUniversal Search Serverを使うと、からGmail、Google Drive、Google Calendar、Google Chatを一つの検索ツールで横断できます。会議予定はCalendar、議事録はDrive、直前の相談はChat、決定事項はGmailというように情報が分かれていても、製品ごとの検索ツールを順番に呼び分けずに探せる点が特徴です。
ただし、2026年11月2日時点ではGoogle Workspace Developer Preview Programの機能です。一般提供済みの完成機能として本番へ直結するのではなく、検索対象、応答時間、結果の網羅性、利用者が許可した範囲を検証する段階と捉える必要があります。本記事はGoogleの公式資料を基にした導入・評価の解説であり、実環境での性能測定結果ではありません。
スポンサーリンク
Universal Searchで変わる検索ツールの構成
Google WorkspaceにはGmail、Drive、Calendar、Chatなど製品別のリモートMCPサーバーがあります。製品別サーバーはメールの下書き作成、ファイル内容の取得、予定の作成といった個別操作を備えます。これに対しUniversal Search MCP Serverが提供するツールはsearch_corpus一つです。対象はGmailメッセージ、Driveファイル、Calendarイベント、Chatのスペースとメッセージで、同じ問い合わせを複数の情報源へまたがって探します。
例えば「次回の販売会議はいつで、最新の企画書と直近の相談内容は何か」という質問では、Calendarだけを検索しても会議日時しか得られません。DriveとChatを別々に呼ぶ設計では、モデルが適切なツールを選び、検索語を調整し、複数結果をまとめる必要があります。Universal Searchは最初の横断検索を一つのツールへ集約できるため、エージェント側の分岐と往復を減らせる可能性があります。
一方、Universal Searchは製品別操作の代替ではありません。見つかったDriveファイルの本文を詳しく読む、Gmailで下書きを作る、Calendarへ予定を登録するといった後続処理には、対応する製品別MCPサーバーやが必要です。「探す入口」と「内容を読む・状態を変える処理」を分けて構成すると、使い分けが明確になります。
利用前に満たす三つの前提
- Google Workspace Developer Preview Programへ参加していること
- Google Cloudプロジェクトを用意できること
- リモートMCPと 2.0に対応したクライアントを使えること
Googleの公式手順はAntigravityとClaudeの設定例を掲載しています。Preview Programは今後の機能を事前に試す制度で、Googleは通常3〜6カ月程度プログラム内に置かれることが多いと説明していますが、例外もあります。採用判断では、機能名や接続先、設定形式が変わる可能性を考慮し、設定をアプリ本体から分離して戻せるようにします。
まずGoogle CloudプロジェクトでGoogle Workspace MCP APIを有効にします。公式資料の例は次の形です。実行前に、対象のプロジェクトIDと実行者の権限を確認してください。
gcloud services enable workspacemcp.googleapis.com \
--project=PROJECT_ID
次にGoogle Auth PlatformでOAuth同意画面とWebアプリケーション用のOAuthクライアントを用意します。クライアントでは「Use this client for an AI-powered agent」を選択します。接続先はhttps://workspacemcp.googleapis.com/mcp/v1です。Antigravityの例ではmcp_config.jsonにサーバーURL、クライアントID、クライアントを設定します。
{
"mcpServers": {
"workspace-universal": {
"serverUrl": "https://workspacemcp.googleapis.com/mcp/v1",
"oauth": {
"clientId": "OAUTH_CLIENT_ID",
"clientSecret": "OAUTH_CLIENT_SECRET"
}
}
}
}
この例は設定項目の対応を示すもので、秘密情報をソース管理へ入れることを勧めるものではありません。利用するMCPクライアントの秘密情報保管方法を確認し、開発・検証・本番でOAuthクライアントを分けます。URIもクライアントごとに公式手順の値を使い、別製品のURIを流用しないでください。
スポンサーリンク
検索対象は承認したスコープで決まる
Universal Searchは、利用者が承認した製品だけを検索します。公式資料が示す読み取りスコープは、Gmailのgmail.readonly、Driveのdrive.readonly、Calendarのcalendar.readonly、Chatのchat.messages.readonlyです。すべてを要求する必要はありません。
例えばGmailを含めず、Drive、Calendar、Chatだけを承認した場合、検索結果にメールは入りません。これは失敗ではなく、許可された範囲に従った動作です。検索結果が少ないときにだけを調整するのではなく、利用者がどのスコープを承認したか、対象情報がどの製品にあるかを先に確認します。
導入時は用途ごとに必要な情報源を決めます。会議準備ならCalendarとDriveから始め、メールやChatが本当に必要かを評価できます。全製品を最初から要求すると、同意画面が重くなり、利用者が許可しない理由も分かりにくくなります。検索対象を段階的に増やせば、追加した製品が回答品質と待ち時間へ与えた影響も比較できます。
約1時間ごとの再ログインを避ける条件
長時間利用するMCPクライアントでは、の期限後も接続を続けるためリフレッシュトークンが必要です。Googleの資料は、認可リクエストにaccess_type=offlineを含めないとリフレッシュトークンが発行されず、OpenID Connectのoffline_accessスコープだけでは代用できないと説明しています。
すでに同意済みの利用者へ新しいリフレッシュトークンを発行させる場合は、prompt=consentも追加します。クライアントが独自のパラメータに対応していなければ、トークン失効のたびに再ログインが必要になります。評価時に短時間の接続だけを成功条件にせず、少なくともアクセストークン更新をまたいだ継続利用を確認してください。
スポンサーリンク
検索品質は製品別に分けて評価する
横断検索の評価では、最終回答だけを見ると原因を特定できません。本サイトでは、質問、承認スコープ、期待する情報源、実際に返った情報源、採用した結果、最終回答を分けて記録することを提案します。Driveの資料は見つかったがChatの直近メッセージが出なかった場合と、両方見つかったのに回答へ反映されなかった場合では、直す場所が異なります。
検証用の質問には、単一製品で答えられるものと、複数製品が必要なものを混ぜます。「次の定例会議はいつか」はCalendar中心、「企画書の最新版はどれか」はDrive中心です。「次の会議日時、最新版の資料、未解決の相談をまとめる」はCalendar、Drive、Chatをまたぎます。メールだけにある決定事項も用意し、各製品の結果が必要な質問を区別します。
結果の正しさに加え、更新反映、同名ファイル、古い会議、似たプロジェクト名も確認します。検索語を具体化したときに対象が絞れるか、権限のない情報を前提に回答しないか、見つからないときに古い資料で補って断定しないかを見ます。の検索品質を詳しく切り分ける方法は、関連記事「RAGの回答がずれるのはなぜ?文書分割と検索品質から改善する」でも整理しています。
Universal Searchと製品別MCPを段階的につなぐ
実装は、最初に横断検索だけを許可し、結果を利用者へ表示するところから始めると比較しやすくなります。次に、選ばれたファイルやメッセージを製品別ツールで詳しく読みます。最後に、下書き作成や予定登録など状態を変える処理が必要なら、検索とは別の確認段階へ進めます。
この分離により、検索結果が不十分なのか、後続ツールの引数が不適切なのかを切り分けられます。また、横断検索の結果を受けてモデルがどの製品別ツールを選んだかも記録できます。構造化出力とツール実行の責務については「構造化出力とツール呼び出しはどう違う?AIをWeb機能へ組み込む設計」も参考になります。
Universal Searchを採用する価値は、ツール数を一つ減らすことだけではありません。情報源をまたぐ質問で、エージェントが個別検索の順序や検索語を毎回組み立てる負担を減らせる点にあります。ただし、検索結果の内容、順位、応答時間、費用に関する具体的な保証は今回確認した公式資料には示されていません。自社の質問とアカウントで比較し、製品別検索より有利な範囲を決める必要があります。
導入判断で確認する項目
- Preview Programへ参加でき、仕様変更を追えるか
- 対象業務がGmail、Drive、Calendar、Chatの横断検索を必要としているか
- 必要な製品だけをOAuthスコープへ追加しているか
access_type=offlineを使い、トークン更新後も接続できるか- 単一製品と複数製品の質問を分けて検索品質を記録できるか
- 検索、詳細取得、状態変更を別段階として検証できるか
- Preview終了や接続先変更時に製品別MCPへ戻せるか
Google Workspaceの情報が複数製品へ分散している組織では、Universal SearchはAIエージェントの最初の探索を簡潔にする候補です。まず読み取り専用の少数スコープと代表的な質問集で比較し、見つけられる範囲と見つけられない条件を明らかにします。その結果から、製品別MCPを追加する場所と、人が確認する場所を決めるのが現実的です。
参考資料
- Google for Developers:Let AI agents search across workspace with the Universal Search MCP Server for Workspace(最終更新:2026年10月23日、確認:2026年11月2日)
- Google for Developers:Configure the Google Workspace MCP servers(確認:2026年11月2日)
- Google for Developers:Google Workspace Developer Preview Program(確認:2026年11月2日)








![[入門]LLMアプリ開発 --基本・LLMのしくみ・MCP・AIセキュリティ](https://thumbnail.image.rakuten.co.jp/@0_mall/book/cabinet/4707/9784297154707_1_29.jpg?_ex=240x240)
