Workspace版Geminiの無料連携に限界を感じて、API契約をしようかなと思った話

はじめに

社内データをAIに連携させて業務を自動化したい。そう考えたとき、Google Workspace Enterprise環境のユーザーなら、誰もが一度はこう考えるのではないでしょうか。

「Workspace版Geminiから、Cloud Run上に作ったMCPサーバーを呼び出せばいいのでは？」
「Cloud Run側でGoogleアカウント認証（Cloud IAP）をかませれば、追加のアカウント設定なしでセキュアな環境が構築できるはずだ！」

私もこの仮説を思いつき、意気揚々と検証を始めました。しかし結論から言うと、見事に様々な仕様の壁にぶつかり、苦肉の策（スプレッドシート定時更新）を経由した結果、大人しくAPIの契約を検討することになりました。

本記事では、その試行錯誤のプロセスと見えてきた「AIシステムの限界」を共有します。

1. 完璧に思えたアーキテクチャ（仮説）

当初思い描いていたシステム構成は以下の通りです。

• AIUI: 普段使っているブラウザ版のGemini（Enterpriseプランなら追加料金ゼロ・学習されないから安全）
• サーバー: Cloud Run上に社内データ取得用のMCPサーバーを構築（無料枠に収まる）
• セキュリティ: アクセス制限としてGoogleアカウント認証（OAuth / IAP）を設定

これなら、社員は普段のGeminiの画面から話しかけるだけで、安全に社内データを使った回答を得られる最強の環境ができると考えました。

2. 検証して絶望した「2つの巨大な壁」

しかし、実際に構築を検討していくと、システムの根本的な仕様という厚い壁に阻まれました。

壁1：ブラウザ版Geminiには「MCP接続UI」がない

そもそも、現状の gemini.google.com のチャット画面には、自作のMCPサーバーのURLを拡張機能として追加・登録する機能が解放されていませんでした。（※Claudeのデスクトップアプリにはある機能ですが、Geminiは未対応）。

壁2：プロンプトでの「URL指定」は認証を突破できない

「UIがないなら、プロンプトで『このURL（API）にアクセスして情報を取ってきて』と指示すればいいのでは？」というハッカー思考も試しました。
しかし、ここに最大の罠がありました。Geminiが裏側でWebサイトにアクセスする際、「ブラウザで操作している私自身のGoogleアカウント情報（Cookieやトークン）」はロボットには渡されません。
丸腰の状態でアクセスしに行くため、Cloud Run側のGoogle認証で「誰だかわからない不審なアクセス」として無慈悲に弾かれてしまいます。

3. 苦肉の策：スプレッドシート・ハブ構想（と、更なるGASの罠）

どうしても現在のWorkspace契約の範囲内でやりたい場合の、唯一の突破口がこれでした。
システム間のリアルタイムな通信を諦め、矢印の向きを逆にします。

「GASを使って、データ取得APIの実行結果をスプレッドシートに蓄積し、それをGeminiの拡張機能（@Google ドライブ）で読ませる」という力技です。

しかし、ここでも GAS（Google Apps Script）の仕様とAIの挙動による「2つの罠」 にブチ当たりました。

罠：スプレッドシートの「OPENイベント」が上がらない

最初は「Geminiに読ませる直前にデータを最新にしたいから、スプレッドシートを開いたタイミングでAPIを叩いて自動更新させよう」と考えました。しかし、これは動きません。

• 理由1（シンプルトリガーの制限）：
  単にコードへ function onOpen() と記述するだけの「シンプルトリガー」の仕組みでは、セキュリティ上の制限から、外部への通信命令（UrlFetchApp）の実行が禁止されており、権限エラーになります。
  (※メニューから手動で設定する「インストール型トリガー」を使えば、認証をパスして外部APIを叩くコード自体は実行可能です。ただし、次の理由2によって結局破綻します。)
• 理由2（AIは人間ではない）：
  これが致命的でした。ブラウザ版Geminiが @Google ドライブ 経由でファイルを覗きに行く行為は、「人間が画面を開く」という挙動ではないため、シンプルトリガーであれインストール型トリガーであれ、そもそもOPENイベント（起動トリガー）自体が一切発火しません。

回避策：「時間主導型トリガー」への移行

結局、「開いた時に更新」は技術的に諦めざるを得ず、GASのトリガーを 「1時間おき」や「毎日朝7時」といった時間主導型（タイマー） に設定し、人間もAIも関係ない裏側で勝手にデータを定時更新・ストックしておく運用に落ち着きました。

これなら認証の壁も越えられ、追加費用をかけずにセキュアに社内データを分析させることができます。

4. 結論：大人しくAPIの契約を検討します

スプレッドシートを使った定時更新の連携はコスパ最強ですが、やはり 「リアルタイムな情報検索」や「膨大なデータ量（数万件以上のログなど）」には耐えられません。
データ量が増えると、Geminiが膨大な表データを読み込む際にタイムアウトするリスクも跳ね上がります。

今回、システムの仕様とAIの限界を整理したことで、1つの真理に辿り着きました。

「AIに自社システムを操作・検索させる（Function Calling / MCP）なら、ケチらずに開発者向けのGemini API（AI Studio）を使うしかない」

Gemini APIのクレジットカードを登録する「有料枠（Pay-as-you-go）」に切り替えれば、送信したデータはAIの学習に使われないため、エンタープライズのセキュリティ要件を完全に満たしたまま、リアルタイムで強固なシステム連携が可能になります。

変に抜け道を探して時間を消費したり、GASの制限やスプレッドシートの容量限界に怯えたりするより、王道のAPI契約を進めて、真っ当なRAGやMCP連携を構築していこうと思います。

同じような「無料アーキテクチャ」を夢見ている方の参考になれば幸いです！