---
title: "ローカルMCPをリモート化する｜移行の焦点は機能ではなく認証にある"
excerpt: "「作った人のPCでしか動かない」ローカルMCPを、誰でもどこからでも使えるリモート構成へ移行しました。踏み台MCPサーバを経由してGAS MCPサーバへ接続する設計です。リモート化の最大の焦点はキーの取り回しとOAuth認証の永続化であり、ホスティング先も認証情報のメンテナンス性で選ぶ必要があるという記録です。"
author: "AI活編集部"
author_username: ai-katsu-editorial
published_at: 2025-11-08T00:00:00+00:00
verified_at: 2025-11-08T00:00:00+00:00
tools: ["MCP", "Google Apps Script", "Vercel"]
tasks: ["開発・エンジニアリング", "業務プロジェクト"]
domain: "マーケティング"
canonical_url: https://ai-katsu.jp/articles/marketing-remote-mcp-server
---
# ローカルMCPをリモート化する｜移行の焦点は機能ではなく認証にある

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

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

## この検証の概要

| 項目 | 内容 |
| --- | --- |
| 検証時期 | 2025年11月（11/8〜11/21） |
| 使用ツール | MCP / GAS / Render / Vercel |
| やりたかったこと | ローカル環境に依存せず、誰でもどこからでもマーケティングデータ（GA4/Clarity）にアクセス・分析できる環境を作る |
| 構成 | **踏み台MCPサーバを経由してGAS MCPサーバへ接続するリモートMCP構成** |
| 達成できたこと | 1時間で切れるアクセストークンのリフレッシュ処理の実装成功／ローカルMCP環境の共有完了 |
| 焦点 | **「キーの取り回し」と「OAuth認証の永続化」** |
| 状況 | アーキテクチャ設計および移行中 |

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

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

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

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

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

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

## 構成：踏み台を挟む

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

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

### ホスティング先の検討

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

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

## 達成できたこと

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

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

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

|  | ローカルMCP | リモートMCP |
| --- | --- | --- |
| 始めやすさ | 手軽 | 設計が必要 |
| 利用できる人 | 構築した本人のみ | 誰でも |
| 認証情報の管理 | 手元にあるだけ | **設計対象になる** |
| 組織の仕組みとして | 成立しにくい | 成立する |

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

## よくある質問

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

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

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

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

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

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

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

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

## まとめ

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

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

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