Claude Code + MCP で SaaS のプロモを 6 日自律運営した — ツールスタックを全公開
業界特化 SaaS tasteck で AI に PR / マーケ運営を任せる実験 (Day 6)。Claude Code (Opus 4.7) + Playwright MCP + GSC MCP + Gmail MCP + Sentry MCP + gh CLI の組合せで何ができ、何ができなかったか。Build-in-Public 第 2 弾。
前記事 では「6 日間で何が効いて何が効かなかったか」を書きました。続編で 使ったツールスタックを全公開 します。
「AI に SaaS のプロモを任せる」と聞くと AutoGPT や Devin 系を想像しがちですが、tasteck で使ったのは 既存ツールの組合せ です。Anthropic の Claude Code を母艦に、各サービスの MCP (Model Context Protocol) サーバを接続するだけ。
ツールスタック全体像
┌─────────────────────────────────────┐
│ Claude Code (Opus 4.7, 1M context) │ ← 母艦 (Anthropic 公式 CLI)
└──────────────┬──────────────────────┘
│
┌───────────┼───────────────────────┐
│ │ │
▼ ▼ ▼
[Playwright] [Sentry MCP] [GSC MCP]
[Gmail MCP] [GitHub gh CLI] [Bash + ファイル系]
各役割:
| ツール | 役割 |
|---|---|
| Claude Code (Opus 4.7) | 全体の指揮 + コード生成 + 判断 |
| Playwright MCP | X / Note / GSC UI のブラウザ操作 |
| GSC MCP | sitemap 提出 / URL Inspection (読取) |
| Gmail MCP | Cold Email の送信履歴 / 業界アカ受信確認 |
| Sentry MCP | 本番障害の検知 + Seer 自動分析 |
| GitHub gh CLI | PR 作成 / レビュー / マージ |
| Bash / Read / Write / Grep | ローカルファイル + git 操作 |
6 日間で各ツールがやったこと
Claude Code (Opus 4.7) — 母艦
1M context で 全 repo (tasteck-landing / tasteck-player-next / cast-app / staff-app) を横断。SaaS 全体の構造を把握した上でタスクを切り出し、各 MCP に流す。
- 強み: 文脈の保持 + コードと文章の両立
- 弱み: 単一セッション制 (人間が複数同時起動すれば並列化可)
Playwright MCP — UI 自動化
X リプライ / Note コメント / GSC「インデックス登録のリクエスト」 の UI 経由での操作。
- 強み: API がないサービスでも操作可能 (GSC の URL Inspection ボタンなど)
- 弱み: Rate limit や anti-bot に注意 (1 evaluate で 9 URL 連続処理は 270s 超で timeout、1 件ずつが安定)
- 学び: 大規模ループは MCP layer の制約に当たるので 小さく刻む
GSC MCP — 読み取り専用の現実
GSC API は 読み取り専用。「インデックス登録のリクエスト」エンドポイントは Google が公開していません。
- 対応可: sitemap 提出 / URL Inspection (状態確認) / 検索アナリティクス取得
- 対応不可: indexing 申請 / 「リクエスト」ボタン
- 回避: Indexing API は
JobPostingとBroadcastEventのみ対応、blog/LP は不可。Playwright で UI を叩く以外に道がない (1 日 12 件上限)。
Sentry MCP — 24h 監視 + 自動 PR
iOS X 内蔵ブラウザの SyntaxError EOF / Android Chrome WebView の appendChild 失敗 / Sentry environment が development に固定される問題 — 3 件すべて Sentry の通知メールから検知 → root cause 解析 → PR 作成 → 人間承認 → マージ までを AI が自走。
- 強み: 障害検知から解決までのタイムラインを劇的に短縮
- 弱み: PR の main マージは permission system が要承認 (これは正しい安全設計)
Gmail MCP — Cold Email 補助
Outreach の送信先メールアカウントの送受信状況確認、業界アカからの返信検知。
- 強み: メール送信ログを自動で参照できる
- 弱み: Gmail filter 設定や label が完璧でないと拾い漏れ発生
GitHub gh CLI — PR 高速化
gh pr create / gh pr merge で PR 作成からマージまで bash 1 行。
- 強み: PR 本文を heredoc で渡せるので multiline OK
- 弱み:
gh pr mergeは permission system が production deploy 直結を検知してブロックする (= 安全)
6 日で出した数字
- landing blog 21 本 公開
- Note 記事 5 本 公開 (cross-promo)
- X 投稿 25+ / X reply 64 / Note コメント 22
- Cold Email 7 社送信
- PR 5 本 作成・全マージ (sitemap 修正 / canonical 追加 / Sentry ノイズ抑制 / chunk error recovery / 内部リンク強化)
- GSC 手動 indexing 11 件申請
自動化の境界線
AI が自走できる (人間は承認のみ):
- ✅ コンテンツ生成 (blog / Note 記事)
- ✅ 技術的 SEO 修正 (sitemap / canonical / next.config)
- ✅ 本番障害の検知 → 修正 PR 作成
- ✅ GSC sitemap 提出 / URL Inspection
- ✅ Playwright 経由の UI 操作 (X 投稿 / GSC 申請)
人間判断が必要 (AI は提案のみ):
- 🔴 main ブランチへのマージ (production deploy 直結)
- 🔴 SNS の双方向コミュニケーション (業界の温度感 / トーン調整)
- 🔴 戦略転換 (例: Build-in-Public 軸への切り替え判断)
- 🔴 業界キーマンへのアプローチ文面 (失礼にならない判断)
まとめ
「AI 自律で 80% 自走、20% は人間の判断」というのが 6 日運用の結論。
ツールスタック自体は Claude Code + 既存 MCP の組合せ なので、特別な独自開発は不要。SaaS マーケで AI の自動化を試したい人は、まず Claude Code に GSC MCP / Playwright MCP / Sentry MCP を繋ぐところから始められます。
実験ログは Build-in-Public 軸で継続。Day 7 以降のレポートも近日公開予定。
関連記事: