AIチャットからGA4やClarityのデータを直接扱えるようにする。この体験は便利ですが、ローカルMCPで組むと構築した本人しか使えません。
誰でも簡単に使える環境にするため、踏み台MCPサーバを経由する構成を設計しました。実装を進める中で、実用化の鍵は機能ではなく秘匿情報の管理とセッション維持にあることがはっきりしました。
この検証の概要
検証時期 | 2025年11月〜12月（11/22〜12/19） |
|---|---|
使用ツール | MCP / GAS |
やりたかったこと | 個々のローカル環境に依存せず、誰でも簡単にGA4やClarityのデータをAIチャット上で扱えるようにする |
構成案 | 踏み台MCPサーバ → GAS MCPサーバ（アクセストークン管理） |
達成できたこと | リフレッシュトークンを用いたアクセストークンの自動発行（プロンプトベース）が安定稼働 |
実用化の鍵 | リモートホスティング時の秘匿情報（キー）の管理とセッション維持の設計 |
状況 | アーキテクチャ構築フェーズ |
本記事は自社での検証記録です。工数削減などの定量測定は行っていないため、数値は掲載していません。
結論：ホスティングは簡単、秘匿情報の管理が難しい
この構築で明確になった論点です。
リモートホスティング（Vercel / Render等）を行う際、秘匿情報（キー）の管理とセッション維持の設計が実用化の鍵となります。
MCPサーバをクラウドに載せること自体は、それほど難しくありません。詰まるのはその先です。
- キーをどこに置くか — 環境変数に入れるとして、誰が更新するのか
- セッションをどう維持するか — 複数の利用者が同時に使う場合の扱い
- トークンをどう更新し続けるか — 期限切れで止まらないようにする
ローカルで動いていたときには存在しなかった問題が、共有した瞬間にまとめて現れます。
構成：踏み台を挟んでトークン管理を集約する
クライアント（AIチャット）
↓
踏み台 MCP サーバ
↓
GAS MCP サーバ（アクセストークンを管理）
↓
GA4 / Clarityアクセストークンの管理をGAS MCPサーバ側に寄せる設計です。認証情報の置き場所を1箇所に固定することで、管理対象が分散するのを防ぎます。
達成できたこと：プロンプトベースでのトークン自動発行
リフレッシュトークンを用いたアクセストークンの自動発行が、プロンプトベースで安定稼働しています。
Google系APIのアクセストークンは1時間で切れます。利用者がその都度認証をやり直す必要があると、「誰でも簡単に使える」という当初の目的が崩れます。
プロンプトを投げれば、裏側で必要なトークンが自動的に取得される。この状態になって初めて、利用者が認証の存在を意識せずに済みます。
「誰でも使える」ために必要だったこと
目指した状態 | そのために必要なこと |
|---|---|
ローカル環境の整備が不要 | リモートホスティング |
認証を意識しなくてよい | トークンの自動発行・更新 |
安全に共有できる | 秘匿情報の管理設計 |
使いやすさは、裏側の設計をどれだけ引き受けるかで決まります。利用者から見えない部分に手間をかけるほど、表側が簡単になります。
よくある質問
なぜ踏み台サーバを挟むのですか？
アクセストークンの管理を1箇所に集約するためです。認証情報の置き場所が分散すると、更新や管理が難しくなります。
リモート化で一番難しいのは何ですか？
秘匿情報（キー）の管理とセッション維持の設計です。ホスティング自体は難しくありませんが、ローカルでは存在しなかった問題が共有した瞬間に現れます。
利用者は認証操作が必要ですか？
不要にすることを目指しています。リフレッシュトークンによるアクセストークンの自動発行がプロンプトベースで安定稼働しており、利用者が認証を意識せずに済む状態を作っています。
まとめ
- ローカルMCPを誰でも使える形にするため、踏み台MCPサーバ → GAS MCPサーバという構成を設計
- リフレッシュトークンによるアクセストークンの自動発行がプロンプトベースで安定稼働
- 実用化の鍵は秘匿情報の管理とセッション維持の設計。ホスティング自体は難しくない
- 使いやすさは裏側の設計をどれだけ引き受けるかで決まる
「誰でも使える」を実現するコストは、たいてい認証まわりに集中します。ここを設計に含めておくと、共有の段階で立ち止まらずに済みます。
株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のデータ活用基盤づくりを支援しています。ご相談はお問い合わせフォームから、継続的な伴走支援についてはAI参謀をご覧ください。