Stape の GTM MCP サーバーで、Google タグマネージャーを Claude から操作する

Stape が公開している Google Tag Manager の MCP サーバーを Claude Code に繋ぐと、コンテナ・タグ・トリガー・変数・バージョンの読み書きが自然言語でできる。実際に自分の管理コンテナを読ませてみて分かった便利さと、書き込み時に気をつけるべき点をまとめる。

·
  • Google Tag Manager
  • MCP
  • Claude Code
  • Stape
  • 計測
  • Web開発
左のチャット吹き出しから伸びた線がコネクタ型のモジュールを経由して、右側の Tag・Trigger・Variable・Version の 4 枚のカードにつながっているミニマルなイラスト

Google タグマネージャー（GTM）の管理画面は、正直あまり好きではない。クライアントごとにアカウントを切り替えて、コンテナを開いて、ワークスペースを選んで、タグの一覧から目当てのものを探して、設定を開いて……という操作を、案件の数だけ繰り返すことになる。「このサイトの GA4 タグ、どのトリガーで発火してたっけ」を確認するだけで数クリックかかる。

最近は Claude Code から Stape の GTM MCP サーバー 経由で GTM を触ることが増えた。これが思った以上に便利だったので、仕組みと使い方、実際に自分の管理コンテナを読ませてみた結果をまとめておく。

Stape の GTM MCP サーバーとは

stape-io/google-tag-manager-mcp-server は、サーバーサイド GTM のホスティングで知られる Stape が公開している Model Context Protocol（MCP）サーバー だ。Apache 2.0 ライセンスで、2026 年 9 月時点で GitHub スター 215、直近のリリースは 9 月 2 日の v5.1.1 とメンテナンスも活発に続いている。

MCP は AI アプリケーションが外部のツールやデータに接続するための共通規格で、Claude Desktop / Claude Code / Cursor などが対応している。GTM MCP サーバーを繋ぐと、Claude が GTM API を直接叩けるようになり、「このコンテナのタグ一覧を出して」「このトリガーを使う GA4 イベントタグを作って」といった指示で GTM を操作できる。

提供形態は 2 つある。

形態認証データの経路
ホスト版 https://gtm-mcp.stape.ai/mcpブラウザで Google OAuthStape の Cloudflare Worker を経由する
ローカル CLI npx google-tag-manager-mcp-serverサービスアカウント鍵 / リフレッシュトークン / アクセストークンを環境変数で渡す自分のマシンから Google API へ直接

ツールセットは両方同じ。手軽さならホスト版、クライアントのデータを第三者のサーバーに通したくない場合はローカル CLI、という使い分けになる。ちなみにローカル CLI は v2〜v3 の間、公開されていた npm パッケージのエントリポイントが Cloudflare Worker 用のもので npx しても何も起きない状態だった。v4.0.0（2026 年 8 月）で stdio 対応の本物の MCP サーバーとして復活しているので、古い記事の「動かない」情報は気にしなくていい。

セットアップは 1 コマンド

Claude Code でホスト版を使うなら、これだけだ。

claude mcp add --transport http gtm-mcp-server https://gtm-mcp.stape.ai/mcp

最初にツールを呼んだタイミングでブラウザが開き、Google アカウントでの OAuth 認可が走る。GTM のアカウントに紐づく Google アカウントで承認すれば、以後はそのアカウントで見えるものがすべて Claude からも見える。

Claude Desktop なら Settings → Connectors → Add custom connector に同じ URL を入れる。ネイティブに OAuth をサポートしない MCP クライアントの場合は mcp-remote を挟む。

{
  "mcpServers": {
    "gtm-mcp-server": {
      "command": "npx",
      "args": ["-y", "mcp-remote", "https://gtm-mcp.stape.ai/mcp"]
    }
  }
}

ローカル CLI 版は、GOOGLE_SERVICE_ACCOUNT_KEY にサービスアカウントの JSON をそのまま入れるのが一番素直だ。サービスアカウントのメールアドレスを GTM 側でユーザーとして追加しておく必要がある。

{
  "mcpServers": {
    "gtm-mcp-server": {
      "command": "npx",
      "args": ["-y", "google-tag-manager-mcp-server"],
      "env": {
        "GOOGLE_SERVICE_ACCOUNT_KEY": "{\"type\":\"service_account\", ... }"
      }
    }
  }
}

一つ注意点として、ホスト版とローカル版を切り替えるときは ~/.mcp-auth にキャッシュされた認証情報を消さないと混乱することがある、と README にある。

ツールの構成

GTM API のリソースごとに 1 ツール、という設計になっている。Claude Code から見えるツール名はこうだ。

  • gtm_account / gtm_container / gtm_workspace
  • gtm_tag / gtm_trigger / gtm_variable / gtm_built_in_variable / gtm_folder
  • gtm_template / gtm_client / gtm_transformation / gtm_zone / gtm_gtag_config
  • gtm_environment / gtm_version / gtm_version_header / gtm_user_permission
  • gtag_destination（Google タグのリンク先の一覧）
  • gtm_remove_session（ホスト版のセッション破棄）

各ツールは action パラメータで操作を選ぶ。たとえば gtm_tag なら create / get / list / update / remove / revert、gtm_workspace なら create / get / list / update / remove / createVersion / getStatus / sync / quickPreview / resolveConflict、gtm_version なら get / live / publish / remove / setLatest / undelete / update といった具合で、GTM の管理画面でできることはほぼ全部ある。ワークスペースからバージョンを切って公開するところまで含めてだ。

地味に良いのが、レスポンスが LLM 向けに整えられている点。list 系はページネーション（タグ・トリガー・変数は 20 件、それ以外は 50 件ずつ）が入っていて、gtm_version の get / live は resourceType を指定すると特定リソースだけをページ単位で取れる。大きなコンテナを一気に読み込んでコンテキストを溢れさせない配慮がされている。

実際に自分のコンテナを読ませてみた

ここからは、自分が管理している複数のクライアントアカウントに対して、Claude Code から実際に読み取り操作をしてみた結果だ（クライアント名や ID は伏せる）。

「どのアカウントに何があるか」が一発で出る

「GTM のアカウント一覧を出して」と言うと、gtm_account の list が呼ばれて、OAuth した Google アカウントに紐づく 5 アカウントが名前と ID つきで返ってきた。続けて「それぞれのコンテナを見せて」で gtm_container の list が回り、公開 ID（GTM-XXXXXXX）や usageContext（web / server など）、有効な機能フラグが分かる。

管理画面ではアカウントごとにページを切り替えて確認するところが、会話の中で表になって出てくる。これだけでも管理案件が多い人には価値がある。

公開中バージョンのサマリーが読める

あるサイトのコンテナで「今 live になってるバージョンの中身を要約して」と頼むと、gtm_version の live が呼ばれて、こういう情報が返ってきた。

  • バージョン名: 「GA4イベント追加・測定ID変更・ヘルスチェック対応」
  • タグ 10、トリガー 5、変数 8、組み込み変数 5
  • 各リソースのサンプル数件（タグなら種類・発火トリガー・例外トリガー・パラメータの中身まで）

カスタム HTML タグの中身のスクリプトも parameter にそのまま入ってくるので、「この Meta Pixel タグ、CAPI にイベント ID を渡してる？」のような質問にそのまま答えられる。実際、Pixel と CAPI の重複排除用に eventID を生成して両方に渡している実装であることをタグの本文から確認できた。

gtm_version_header の list でバージョン履歴も取れる。バージョン名にタグ数・トリガー数・変数数がついて 14 件並んだので、「いつ GA4 を入れたか」「いつ本番以外のホスト名をブロックする例外トリガーを足したか」が会話の中で追える。

読み取り結果は「裏取り」してから信じる

これは想定していなかった経験だった。同じコンテナで「Default Workspace のタグ一覧を出して」と頼むと、gtm_tag の list が返したのは タグ 2 本とトリガー 1 本だけ。公開中のバージョンには 10 本あるのに、だ。gtm_workspace の getStatus を見ると「added」状態の変更が 3 つ残っていて、中身は初期に作った Meta Pixel タグの古い版だった。「Default Workspace が公開版と乖離したまま放置されている」と一度は結論づけた。

ところが、いざ sync で同期しようとすると GTM API が「Workspace is already submitted」で拒否した。改めて gtm_workspace の list を呼び直すと、返ってきた Default Workspace は 別の ID で、そちらは getStatus が空、タグも公開版と完全に一致していた。最初の list が返してきたのは、とっくにバージョン作成で提出済みになった古いワークスペースだったのだ。提出済みワークスペースは管理画面には出ないが、API では ID を指定すれば読めてしまうし、今回のように一覧に混ざって返ってくることもある。

教訓は単純で、MCP 経由の読み取り結果を根拠に何かを直す前に、別の角度からもう一度読むこと。今回は sync が安全側に倒れて止めてくれたが、もし「残骸を消して」と頼んでいたら、存在しない問題を直そうとして無駄な操作をしていた。逆に言えば、公開バージョンとワークスペースの差分を getStatus で聞けるのは本当に便利で、こういう整合性の確認そのものは会話の中で数秒で終わる。

書き込みで気をつけること

読み取りは気軽にやっていいが、書き込みは GTM API の癖を理解しておく必要がある。ツールの説明文にも明記されている重要な点が 2 つある。

update は全置換。GTM API の update は PATCH ではなく PUT の意味で、送らなかったフィールドは消える。ツールの説明にも「必ず get してから、完全なオブジェクトに変更を加えて送り返せ」と書いてある。Claude はこの説明を読んで動くので、普通に「このタグの発火トリガーを X に変えて」と頼めば get → update の順で動くが、レビューするときは差分が意図した箇所だけかを見ておきたい。

fingerprint による楽観ロック。update / remove / revert / publish には、直前に取得したときの fingerprint を渡す必要がある。他の人が同じリソースを触っていれば失敗する。これは安全側の挙動なので歓迎したい。

それから運用面。Stape 自身がセットアップガイドで「アクセスは与えても、コントロールは渡すな」と書いている通り、本番コンテナへの publish を AI に任せきりにしない 方がいい。自分の運用はこうしている。

  1. Claude には新しいワークスペースを切らせて、そこにタグ・トリガー・変数を作らせる
  2. quickPreview か管理画面のプレビューで動作確認する
  3. createVersion までは Claude にやらせてもいいが、publish は自分で押す

GTM の権限モデルは OAuth したアカウントの権限がそのまま使われるので、閲覧だけさせたいクライアントのアカウントなら、そのアカウントでの権限を「読み取り」に落としておくのが一番確実だ。

MCP で GTM を扱う意味

「管理画面でできることを自然言語でやる」だけなら、慣れた人には管理画面の方が速い場面も多い。それでも MCP 経由の価値があると思うのは、GTM の設定をコードや他のコンテキストと突き合わせられる からだ。

たとえば、サイト側のコードで dataLayer.push({ event: 'contact_form_submit', ... }) を書いたあと、同じ Claude Code のセッションで「この event を受けるトリガーと GA4 イベントタグを GTM 側に作って」と頼める。イベント名も、渡しているパラメータも、Claude は直前に書いたコードから知っている。GTM 側の変数名（DLV - contact_email など）と dataLayer のキーがずれる、というよくあるミスがなくなる。

逆方向も同じで、「このコンテナのタグが参照している dataLayer のキーを全部リストして、サイト側のコードで push している箇所と照合して」といった監査が、1 つの会話で完結する。GTM とアプリケーションコードの間にある「人間が両方を見比べる」工程が消えるのが、この MCP サーバーの本当のメリットだと思う。

まとめ

  • Stape の GTM MCP サーバーは、GTM API のほぼ全リソースを Claude から読み書きできるようにする。ホスト版なら Claude Code に 1 コマンドで繋がる
  • 読み取りは即戦力。複数アカウントの棚卸し、公開バージョンの要約、ワークスペースの整合性チェックが会話でできる。ただし古い提出済みワークスペースが混ざるなど、読み取り結果は裏取りしてから信じる
  • 書き込みは update が全置換であること、fingerprint が要ることを理解した上で、publish は人間が押す運用にする
  • 一番効くのは、サイト側のコードと GTM 設定を同じセッションで扱えること

参考リンク