AIエージェントが本番GTMをAPIで変更・公開するまで。OAuthの壁3連発とMCPという抜け道

以前、Claude Codeにブラウザを操作させてGTMの設定変更を自動化した話を書きました。あれはあれで動くのですが、ブラウザ操作は遅く、画面変更で壊れます。本命はAPI経由です。

ところが今回、AIエージェントにGTM（Google Tag Manager＝サイトの計測タグを一元管理するツール）の本番コンテナを触らせようとしたら、認証で3回連続ブロックされました。最終的にMCP（Model Context Protocol＝AIにツールを接続する規格）経由で突破し、タグ変更からバージョン公開、実機検証までAIが一気通貫でやり切った。その顛末と、再現可能な構成を書きます。

結論：Google直のOAuthは諦めて、検証済みクライアントを持つMCPサーバーを経由する

先に最終形を示します。

Claude Code
  └─ mcp-remote（ローカルのプロキシ）
       └─ GTM MCPサーバー（stape-io製、ホスティング型）
            └─ Google Tag Manager API

ポイントは、Googleに対するOAuth認証（＝アプリにアカウント権限を渡す手続き）を自分のスクリプトでやろうとせず、審査を通過した公開MCPサーバーに任せることです。なぜそうなったのかは、ブロックされた順に見るのが早いと思います。

実話：認証の壁、3連発

壁その1：gcloudのスコープ付きログインがWorkspaceにブロックされる

最初に試したのは王道です。gcloudで tagmanager.edit.containers スコープを付けてログインし、そのトークンでGTM APIを叩く。コマンドを実行するとブラウザが開き、承認画面の手前で「このアプリはブロックされます」。Google Workspaceのセキュリティポリシーが、センシティブなスコープを要求する未許可クライアントを弾いた形です。組織管理下のアカウントでは珍しくない挙動でした。

壁その2：サービスアカウントのキー発行が組織ポリシーで禁止

次の手はサービスアカウント（＝プログラム用のGoogleアカウント）です。作成は通ったものの、キーを発行しようとしたら iam.disableServiceAccountKeyCreation という組織ポリシーに当たりました。キーファイルの漏洩事故を防ぐため、最近のGCP環境ではキー発行自体を禁止する設定が推奨されており、これも正しい壁です。

壁その3：インパソネーションは通るが、GTM側に権限がない

キーなしでサービスアカウントとして振る舞うインパソネーション（権限の借用）はトークン発行まで成功しました。ただしGTM APIは「そのサービスアカウントがGTMコンテナのユーザーとして登録されているか」を見るので、結果は404。登録には管理画面でのユーザー追加という人手作業が必要で、自動化の入口としては片手落ちです。

突破口：stape製GTM MCPサーバー

ここで方針を変えました。GTM MCPサーバー（stape-io製、GitHubで公開されています)は、Googleの審査を通過したOAuthクライアントを持つホスティング型のMCPサーバーです。接続時にブラウザでワンクリック承認するだけで、壁その1で弾かれた認証が通ります。ユーザー本人の権限で動くので、GTM側のユーザー追加も不要でした。

接続は mcp-remote というプロキシを介します。

npx -y mcp-remote https://gtm-mcp.stape.ai/mcp

初回起動でブラウザが開き、承認するとトークンがローカルにキャッシュされます。以降はAIエージェントからGTMのタグ・トリガー・変数・バージョン操作が一通り叩けます。

ひとつ実務的なコツを足すと、Claude CodeのMCP設定はセッション起動時に接続されるため、作業中にMCPを追加しても使えません。今回はmcp-remoteをサブプロセスとして起動し、標準入出力のJSON-RPC（＝MCPの素の通信形式)を直接話す小さなヘルパーを書いて、セッションを再起動せずに操作しました。トークンを取り出してHTTPを直接叩く方法も試しましたが、トークンがプロキシのセッションに紐づいていて2回目から弾かれます。プロキシごと起動するのが正解でした。

AIが実際にやったこと：変更→公開→実機検証

環境がつながってからの流れです。人間がやったのは最後の公開承認だけでした。

1. 既存のタグ・トリガー・変数を一覧で読み、変更対象と影響範囲を特定
2. ワークスペース上でタグを編集（この時点では本番に影響なし）
3. 変更内容を人間に提示して、公開の承認を取る
4. バージョン作成、公開
5. 配信中のコンテナJS（gtm.js）をcurlで取得して変更が載ったことを確認
6. ヘッドレスブラウザで実サイトを開き、計測ビーコンに新しいパラメータが載っていることを確認

5と6が地味に効きます。GTMは「公開した」と「実際に動いている」の間に、キャッシュ・タグ実行順・変数の評価タイミングといった落とし穴がいくつもあります。実際このときも、公開後の検証で値が空のまま送信されている不具合をAI自身が発見し、変数の方式を変えた修正バージョンを重ねて公開しました（この話は別記事で書きます）。

アンチパターン：承認なしでAIに公開までさせる

技術的には、AIはバージョン公開まで全自動でできます。やらないほうがいい。GTMコンテナは複数サイトで共有されていることが多く、公開は全サイトに即時反映されます。今回も「ワークスペース編集まではAIが自由に、公開だけは変更差分を人間が見てから」というゲートを置きました。自動化の価値は「人間の判断回数を減らす」ことであって、ゼロにすることではないと思っています。

まとめ

• 組織管理下のGoogleアカウントでは、GTM APIの自前OAuthは高確率で詰む（Workspaceポリシー・SAキー禁止・GTM側権限の3連壁）
• 検証済みOAuthクライアントを持つ公開MCPサーバー（stape製）経由なら、ワンクリック承認で通る
• ブラウザ自動化より速く、壊れにくい。ただし公開だけは人間の承認ゲートを残す
• 公開後はgtm.jsのgrepと実機の計測ビーコン確認までやって初めて「動いた」と言える

計測タグの運用をAIエージェントに任せる構成づくり、GTM・GA4まわりの計測設計を支援しています。お問い合わせはこちら。