ローカルMCPをリモート化する｜移行の焦点は機能ではなく認証にある【AI活用検証vol.44】

ローカルMCPは手軽に始められますが、「作った人のPCでしか動かない」という弱点があります。組織の仕組みにするには、この依存を外す必要があります。

誰でもどこからでもマーケティングデータにアクセスできるよう、踏み台MCPサーバを経由してGAS MCPサーバへ接続する「リモートMCP構成」の設計・構築を進めました。リモート化にあたって焦点になるのは、認証まわりです。

この検証の概要

本記事は自社での検証記録です。工数削減などの定量測定は行っていないため、数値は掲載していません。

結論：リモート化の焦点は認証にある

この移行で最も重要な論点がこれです。

リモートMCP化にあたっては「キーの取り回し」と「OAuth認証の永続化」が最大の焦点となります。

ローカルで動かしている間は、認証情報は自分のPCにあります。誰と共有するかを考える必要もありません。ところがリモート化すると、「誰の認証情報で、どこに置いて、どう更新し続けるか」を設計しなければなりません。

MCPサーバをホスティングに載せること自体は難しくありません。難しいのは、そこに認証情報を安全に持たせ、切れないように保つことです。

構成：踏み台を挟む

クライアント（誰のPCからでも）
    ↓
踏み台 MCP サーバ（Render / Vercel）
    ↓
GAS MCP サーバ
    ↓
GA4 / Clarity のデータ

直接繋ぐのではなく踏み台を経由する構成にしています。認証情報を集約する場所を1箇所に固定できるため、管理の対象が分散しません。

ホスティング先の検討

ホスティング先としてRenderやVercelを検討しました。判断軸は認証情報のメンテナンス性です。

環境変数の管理方法、更新のしやすさ、アクセス制御。「どこで動かすか」を性能やコストだけで決めると、あとで認証まわりの運用が苦しくなります。

達成できたこと

• 1時間で切れるアクセストークンのリフレッシュ処理の実装成功 — 定期実行の前提条件
• ローカルMCP環境の共有完了 — 個人の手元だけで動く状態からの一歩

Google系APIのアクセストークンは1時間で期限切れになります。これを自動更新できないと、リモートで動かしても止まります。ここをクリアできたことが、移行の土台になりました。

ローカルからリモートへ移行する意味

ローカルで価値を確認してから、リモートに移して全員が使える形にする。この順序自体は正しい進め方です。ただし移行時に認証の設計が必要になることは、最初から見込んでおくべきでした。

よくある質問

なぜ踏み台サーバを挟むのですか？

認証情報を集約する場所を1箇所に固定するためです。直接繋ぐ構成にすると、管理対象が分散して運用が難しくなります。

ホスティング先はどう選びましたか？

認証情報のメンテナンス性を判断軸に、RenderやVercelを検討しました。性能やコストだけで決めると、後から認証まわりの運用が苦しくなります。

アクセストークンの1時間制限は？

リフレッシュ処理の実装に成功しています。これができないとリモートで動かしても止まってしまうため、移行の前提条件になります。

すでに誰でも使える状態ですか？

現在はアーキテクチャ設計および移行中です。ローカルMCP環境の共有までは完了しています。

まとめ

• ローカルMCPは手軽だが「作った人のPCでしか動かない」。組織の仕組みにはリモート化が必要
• 構成は踏み台MCPサーバを経由してGAS MCPサーバへ接続。認証情報を1箇所に集約できる
• リモート化の最大の焦点は「キーの取り回し」と「OAuth認証の永続化」
• ホスティング先は認証情報のメンテナンス性を軸に選ぶ
• 1時間で切れるアクセストークンのリフレッシュ処理が移行の前提条件

ローカルで動くものを組織の仕組みに変える工程では、機能ではなく認証と権限が主な課題になります。ここを見込んでおくと、移行の見積もりが現実的になります。

株式会社AI棒では、こうしたAI活用の検証を日々行い、企業のデータ活用基盤づくりを支援しています。ご相談はお問い合わせフォームから、継続的な伴走支援についてはAI参謀をご覧ください。