---
title: "1時間で切れるトークンをどう扱うか｜マーケ指標の自動通知で越えたOAuthの壁"
excerpt: "GA4・Clarity・Google広告の指標を自動集計しDiscordへ通知する環境を構築しました。最大の障壁はGoogle認証のアクセストークンが1時間で期限切れになること。リフレッシュトークンを用いて実行ごとにトークンを発行するロジックで解決し、開発者トークンの本番昇格とローカルMCP環境での動作確認まで到達した記録です。"
author: "AI活編集部"
author_username: ai-katsu-editorial
published_at: 2025-10-11T00:00:00+00:00
verified_at: 2025-10-11T00:00:00+00:00
tools: ["Google Apps Script", "MCP", "Vercel", "Google Analytics 4", "Microsoft Clarity"]
tasks: ["開発・エンジニアリング", "業務プロジェクト"]
domain: "マーケティング"
canonical_url: https://ai-katsu.jp/articles/marketing-kpi-ga4-clarity-ads
---
# 1時間で切れるトークンをどう扱うか｜マーケ指標の自動通知で越えたOAuthの壁

GA4、Clarity、Google広告。それぞれを個別に開いて確認する時間は、積み重なると無視できません。指標の見落としも起きます。

これらを自動集計し、AIによる改善提案までワンストップで受け取る環境を構築しました。特に苦労したのが**Google認証の有効期限**です。アクセストークンは1時間で切れます。この自動更新処理を確立できたことが、今回の実質的な成果でした。

## この検証の概要

| 項目 | 内容 |
| --- | --- |
| 検証時期 | 2025年10月（10/11〜10/24） |
| 使用ツール | GAS / ローカルMCP / Vercel / GA4 / Clarity / Google Ads |
| やりたかったこと | 複数の分析ツールを個別確認する工数を削減し、AIによる自動集計と改善提案をワンストップで受け取る |
| 達成できたこと | GA4・ClarityのDiscord自動通知の成功／開発者トークンの本番昇格／ローカルMCP環境での動作確認完了 |
| 技術的な成果 | **1時間で期限が切れるアクセストークンの自動更新処理を確立** |
| 状況 | 進行中（環境整備完了、パラメータ選定フェーズ） |

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

## 結論：1時間で切れるトークンをどう扱うか

この構築で最大の技術的課題がこれでした。

**Google認証（OAuth）のアクセストークンは1時間で期限が切れます。**定期実行の仕組みでは、これが致命的になります。夜間に走らせた処理が認証切れで止まっていた、という事態が起きるからです。

解決策として採用したのが、**リフレッシュトークンを用いて、実行のたびにアクセストークンを発行するロジック**です。トークンを保存して使い回すのではなく、必要になった時点で取り直します。

**この自動更新処理を確立できたことが、環境整備における実質的な到達点でした。**

## 構成

```
GAS / ローカルMCP / Vercel
    ↓  リフレッシュトークンでアクセストークンを都度発行
GA4 / Clarity / Google Ads API
    ↓
Discord へ自動通知
```

実行環境をGAS・ローカルMCP・Vercelに分けているのは、**処理の性質に応じて置き場所を変えるため**です。すべてを1つに寄せず、認証まわりの安定性が要る部分を切り出しています。

## 達成できたこと

-   **GA4・ClarityのDiscord自動通知が成功** — 指標の巡回作業が減る
-   **開発者トークンの本番昇格** — 実データを扱うための前提をクリア
-   **ローカルMCP環境での動作確認完了** — 手元でデータを取れる状態に

以前の検証では、リモート環境での認証維持が煩雑だという課題が出ていました。**ローカルMCPという選択肢を含めた構成に切り替えたことで、この部分が前進しています。**

## 現在のフェーズ：何を通知するかを選ぶ

環境整備が完了し、現在は**パラメータ選定フェーズ**にあります。

データを取れるようになったあとに残るのは、**「どの指標を、どの頻度で通知するか」という設計の問題**です。全部を毎日流すと、通知そのものが読まれなくなります。

自動通知の仕組みは、作った時点では完成しません。**受け取る側が反応できる量に絞り込むところまでが設計に含まれます。**

## よくある質問

### アクセストークンが1時間で切れる問題はどう解決しましたか？

**リフレッシュトークンを用いて、実行のたびにアクセストークンを発行するロジックを採用しました。**トークンを保存して使い回すのではなく、必要な時点で取り直す方式です。

### なぜ実行環境を複数使っているのですか？

**処理の性質に応じて置き場所を変えるためです。**GAS・ローカルMCP・Vercelを組み合わせ、認証まわりの安定性が求められる部分を切り出しています。

### すでに運用に乗っていますか？

**環境整備は完了し、GA4・ClarityのDiscord自動通知は成功しています。**現在は「どの指標をどの頻度で通知するか」を決めるパラメータ選定のフェーズです。

### どのくらい工数が減りましたか？

**この検証では定量測定を行っていないため、数値はお答えできません。**

## まとめ

-   **Google認証のアクセストークンは1時間で切れる。**定期実行の仕組みではここが最大の障壁になる
-   解決策は**リフレッシュトークンによる、実行ごとのアクセストークン発行**
-   GA4・ClarityのDiscord自動通知に成功。開発者トークンの本番昇格も完了
-   環境整備の完了後に残るのは**「何を、どの頻度で通知するか」の設計**。全部流すと読まれなくなる

定期実行の自動化は、作るところより「止まらずに動き続けること」が難しい領域です。認証の期限をどう扱うかは、最初に設計しておくべき項目になります。

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