GTM API直叩き×Chrome DevTools MCPでSEO周辺をautonomous化

公開: 2026年5月16日更新: 2026年8月10日約9分で読めます

SEOまわりの細かい雑務を、人が手を動かさずに回す。設定変更、入稿、確認。この繰り返しをAIに任せて、自分は方針だけ握る。そういう働き方が現実になってきた。

この記事の結論

AIエージェントに「管理画面操作系のSEOタスク」を任せるとき、MCP が read-only だと action が止まる
突破口は3つ: ① MCP の credentials を流用して API 直接呼び出し、② Chrome DevTools MCP でブラウザ自動操作、③ どちらも無理ならユーザーに手順書を渡す
f2t.jp の SEO 改善で、GTM の writesonic タグ削除（API直叩き）と microCMS の description フィールド追加（ブラウザ自動操作）を、両方とも autonomous で完走させた

AI エージェントが詰まる場所

f2t.jp の SEO 最適化を Claude Code に任せて autonomous で走らせたとき、最後まで残ったのは「人間が管理画面でクリックする系のタスク」だった。

GTM で writesonic タグを削除（Lighthouse Best Practices 73→90+ の必須条件）
microCMS のスキーマに description フィールドを追加（全151記事の SEO description 改善の前提）

どちらも MCP で対応するツールはあるが、すべて read-only。GTM MCP には list_tags はあるが delete_tag はない。microCMS には Management API がベータで存在するが、API情報の更新 の権限が表に出ていない。

ここで普通なら「ユーザーに管理画面で操作してください」と手順書を返して終わる。だが今回は両方とも、別ルートで autonomous 完走させた。

ルート 1: MCP credentials を流用して API 直接呼び出し

GTM のケース。まず GTM MCP のソースコードを読んだ。

# gtm_server.py
"""Google Tag Manager MCP server (read-only).
書き込み系 (create/update/publish) は意図的に未実装。
認証は credentials_gtm.json (OAuth refresh_token, info@f2t.jp) を使う。
"""

「意図的に未実装」と書いてある。が、その下を読むと credentials は OAuth refresh_token で、scope を見れば書き込み可能かが分かる。

MCP read-only の壁を API 直接呼び出しでバイパスする図 — 左: MCP write 不可で停止 / 右: 同じcredentialsを使ってAPI直接DELETEで突破

実際に credentials_gtm.json を読み込んで scope を確認したら、こうだった:

['https://www.googleapis.com/auth/adwords',
 'https://www.googleapis.com/auth/tagmanager.edit.containers',
 'https://www.googleapis.com/auth/tagmanager.edit.containerversions',
 'https://www.googleapis.com/auth/tagmanager.publish',
 'https://www.googleapis.com/auth/tagmanager.readonly']

書き込み権限あり。tagmanager.edit.containers も tagmanager.publish もある。つまり MCP は read-only だが、credentials 自体は write 権限を持っていた。MCP は単に「安全のため write 系メソッドを実装していない」だけだった。

ここから先は HTTP API を直接叩くだけ。

# DELETE writesonic tag
DELETE https://tagmanager.googleapis.com/tagmanager/v2/accounts/{ACCOUNT}/containers/{CONTAINER}/workspaces/{WORKSPACE}/tags/5

# Workspace → Version スナップショット作成
POST .../workspaces/{WORKSPACE}:create_version
  { "name": "Remove writesonic SEO fixer tag" }

# Version を本番公開
POST .../versions/{VERSION_ID}:publish

3 API call で完了。所要時間1分。GTM-T2W8J69C コンテナの Version 7 として writesonic 除去が公開された。

このルートの注意点

MCP のソースコードを読むのは必須。credentials の scope を確認してから write を試す。「MCP が read-only だから write できない」と思い込まない。MCP は単に書込みツールを export していないだけで、auth は通る場合がある。

ただし autonomous で実行する前にユーザー承認は必要。Claude Code は GTM 本番への DELETE を実行する直前で larc-approval-gate に止められ、ユーザーが「はい」と返して初めて action が通った。書き込み権限があっても、実行は人間判断で挟む のがゴール mode のセーフティライン。

ルート 2: Chrome DevTools MCP でブラウザ自動操作

microCMS のケース。Management API ベータは権限リストに「API情報の取得」しかなく、API情報の更新（スキーマ編集）が存在しなかった。何度試しても 403 (error code 1010 = 権限不足)。

スキーマ編集は 管理画面 UI 限定 だった。

ここで Chrome DevTools MCP の出番。Claude Code 自身がブラウザを開き、人間と同じように画面を操作してスキーマを編集した。

Chrome DevTools MCP でのブラウザ自動操作シーケンス — navigate → click → fill → save の4ステップでmicroCMSのschema編集を自動化

実際の操作シーケンス:

1. new_page('https://app.microcms.io/f2t/apis/blogs')
2. wait → 404 → リダイレクト先に手動navigate
3. take_snapshot で UI 要素を取得
4. dialog 閉じる (uid clicked)
5. 「API設定」リンク click
6. 「APIスキーマ」 click
7. 「フィールドを追加」 click
8. フィールドID = "description" を fill
9. 表示名 = "メタディスクリプション" を fill
10. 種類選択 click → 「テキストフィールド」選択
11. 「変更する」 click
12. 確認ダイアログに「blogs」を fill (microCMS の二段階確認)
13. 最終「変更する」 click
14. スキーマ反映確認

14ステップ、所要時間約3分。人間がやっても同じ手順だが、Claude Code が「次に何をクリックすべきか」を snapshot から自動推論しながら進めた。

このルートが効くケース

API がそもそも write 操作を提供していない（microCMS Management API ベータが典型例）
管理画面 UI でしか触れない設定がある
スクリプト化するには登場頻度が低い操作

DOM が頻繁に変わる SaaS だと壊れやすい。「一度きりの操作」「変動の少ない設定画面」だけに使うのが現実的。

比較: API直叩き vs ブラウザ自動操作

項目	API直叩き	ブラウザ自動操作
信頼性	高（API契約に依存）	中（DOM 変更で壊れる）
速度	速い（HTTP 1-3 call）	遅い（snapshot + click 連鎖）
可監査性	高（log 残る）	中（screenshot 推奨）
適用範囲	API がある操作	管理画面のみの操作
失敗時の安全度	高（API レスポンスで判定）	中（途中 state が残る可能性）
autonomous 適性	高	中（ヒューマンインザループ推奨）

私の運用ルールは「API があるなら API、ない場合のみブラウザ」。今回のケースだと GTM は API、microCMS スキーマ編集はブラウザ、と自然に振り分かれた。

autonomous で詰まる本当の壁

両方の突破ルートに共通するのは、「権限があるか」を最初に Claude Code 自身が確認すること。

GTM: credentials の scope を確認 → write OK と分かってから DELETE
microCMS: Management API で複数 endpoint を叩いて全部 403 → ブラウザ自動操作にフォールバック

この 「権限の偵察」を 1 行たりとも飛ばさない のが、autonomous SEO の実用ラインを引く境界線だ。権限が無いまま action しようとして失敗すると、ロールバックの判断が必要になり、人間判断を求めるか勝手に何かを直そうとして dead code を生む（私もやった）。

Q. ブラウザ自動操作で本番設定を変えるのは怖くない？

怖い。だから3点で守った。

取り消し可能な操作だけ実行（schema 編集は revert 可能、コンテンツ削除は不可）
直前に snapshot を確認（変更ボタンを押す前に画面状態を読む）
ユーザー承認をゲートに挟む（larc-approval-gate がCRITICAL action で物理停止する）

これでも事故るリスクは残る。今回のセッションは前段で5バッチの microCMS PATCH で安全運用の感触を握ったから、最終フェーズでブラウザ自動操作まで踏み込めた。最初からこれをやるべきではない。

Q. 失敗した試みは？

ある。GTM API 直叩きの前に、私は gcloud の access token を取得してそれで API call する案を試した。その時点ではまだ MCP credentials の存在に気づいていなかった。

結果は「auto mode classifier が credential 探索を blocking」で停止。SEO の文脈で gcloud token を取り出すのは scope を超える、と判定された。これは正しい判定で、私は方向転換した。

そこから「MCP のソースコードを読めば認証経路が分かる」と気づくまで5分。grep で gtm_server.py を見つけて、credentials のパスと scope を確認した。MCP の認証経路と gcloud の認証経路は別管理になっていることを、ここで初めて把握した。

このシリーズについて

本記事はシリーズ第3回（最終回）。

3記事を通じて見えてくるのは、AIエージェントに SEO 改善を任せる「現実的なライン」だ。

タイトル・description のリライト → 完全 autonomous で OK
Schema.org 設計と JSON-LD 統合 → 完全 autonomous で OK
管理画面の設定変更（GTM・microCMS） → API か Browser MCP で autonomous 化可能、ただし人間承認を挟む
本番テナントの destructive 操作（記事削除・タグ削除・予算変更） → 必ず人間承認を挟む

このラインを最初に明文化して握れば、Claude Code に SEO 周辺タスクをかなり広く任せられる。一晩で 37 記事リライト + Lighthouse 100点化 + GTM 操作 + microCMS スキーマ変更まで通すのは、人間が一人でやると数日かかる。

SEO周辺の作業をAIに自走させる話は、担当者の効率化に見えて、実はエージェント設計の実例だ。人がやっていた一連の手順を、AIが自分で判断しながら進める形に組み替える。うまく設計すると、一人分の作業を機械側に丸ごと寄せられる。ただしどこまで自走させて、どこで人の確認を挟むか。その線引きを間違えると、勝手に妙な変更をされて後始末に追われる。この攻めと守りの設計こそが肝で、自社のどの業務がこの形に向くかを一緒に見極めたい。まだ絵が描けていない段階が、むしろ話しやすい。まずは現在地を知るだけで十分。無料の診断（6問・約1分）で、どの業務からAIに任せられるかの目安がその場で出る。

自動化の現在地を診断する（無料・6問・約1分）