---
title: "GA4・Google広告・Clarityの指標を自動通知する｜API制限と認証の壁で方針転換した記録"
excerpt: "マーケティング指標をDiscordへ定期自動通知する仕組みを検証しました。Clarityは1日10回というAPI制限があり設計を左右する一方、最大の障壁はGoogle Ads APIの複雑さとOAuth認証の永続化。Makeでの認証維持を諦め、認証基盤の自前構築へ舵を切った判断と、全自動を急がない段階的アプローチをまとめています。"
author: "AI活編集部"
author_username: ai-katsu-editorial
published_at: 2025-09-01T00:00:00+00:00
verified_at: 2025-09-01T00:00:00+00:00
tools: ["Google Analytics 4", "Google Ads", "Microsoft Clarity", "Make"]
tasks: ["業務自動化・ワークフロー", "業務プロジェクト"]
domain: "マーケティング"
canonical_url: https://ai-katsu.jp/articles/ga4-gads-clarity-report
---
# GA4・Google広告・Clarityの指標を自動通知する｜API制限と認証の壁で方針転換した記録

GA4、Google広告、Microsoft Clarity。マーケティングの数字は複数のダッシュボードに散らばっていて、確認するだけで毎日それなりの時間を使います。「重要指標だけDiscordに毎日流してほしい」——営業サイドからのこの要望が出発点でした。

結果として、**全自動化は一旦保留し、認証基盤の構築に舵を切りました。**技術的に何が壁になったのか、そしてどこから段階的に進めることにしたのかを共有します。

## この検証の概要

| 項目 | 内容 |
| --- | --- |
| 検証時期 | 2025年9月（9/1〜9/12） |
| 対象API | Google Analytics API / Google Ads API / Clarity Data Export API |
| やりたかったこと | GA4・Google広告・Clarityの重要指標を、Discordへ日次／週次／月次で自動通知する |
| 最大の障壁 | **Google Ads APIの複雑さ。OAuth認証の永続化（リフレッシュトークン管理）** |
| 重要な制限 | **Clarityは1日10回というAPI制限**があり、取得タイミングの最適化が必須 |
| 判定 | 一部保留（認証基盤の構築へシフト） |

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

## 調査結果：APIの利用制限に大きな差がある

まず着手したのが、各ツールのAPI利用制限（Quotas）の調査です。ここで重要な差が見つかりました。

| API | 利用制限 | 評価 |
| --- | --- | --- |
| GA4 | 制限に余裕がある | 頻繁な取得も可能 |
| **Clarity Data Export** | **1日10回** | 取得タイミングの最適化が必須 |

**Clarityの1日10回という制限は、設計に直接影響します。**「必要なときに叩けばいい」という前提が成り立たないため、いつ取得して、どこにキャッシュするかを先に決める必要があります。

複数APIを束ねる仕組みでは、**最も制限の厳しいAPIが全体の設計を決めます。**ここを先に調べておくと、後戻りが減ります。

## 最大の壁：Google Ads APIの複雑さと認証の永続化

技術的に最も重かったのがこれです。

**Google Ads APIの複雑さが最大の障壁でした。**加えて、実用化の鍵になるのが**OAuth認証の永続化（リフレッシュトークンの管理）**です。

定期実行の仕組みでは、誰も見ていない時間帯に認証が切れて止まる、という事態を避けなければなりません。トークンをどこに保持し、どう更新し続けるか。ここが設計の中心になります。

準備としてGoogle Ads MCC（マルチクライアントセンター）のアカウントを作成し、テスト環境を構築。Makeでデータ取得のプロトタイプも作りました。

## 方針転換：Makeでの認証維持をやめる

プロトタイプを作る中で見えたのは、**リモート環境（Make等）でのOAuth認証維持が煩雑だということ**でした。

そこで構成を変える判断をしています。

-   **ローカルMCP接続**にする、または
-   **認証基盤を自前で持つ**（Vercel / Cloud Run などに構築する）

ノーコードツールは組むのが速い反面、**認証の永続化のような「見えない部分の作り込み」が必要になると、かえって扱いにくくなります。**ここが分岐点でした。

## 全自動を急がない、という判断

営業上の優先度変更と、認証の技術障壁。この2つが重なったため、**無理に全自動化を急がない方針に切り替えました。**

段階的な進め方はこうです。

1.  **まずローカル環境で動くMCPとしてデータを取得する**
2.  **レポート化は人間が行う**
3.  安定してきた工程から順に自動化していく

**「データを取ってくる」ところと「定期実行で無人化する」ところは、難易度がまったく違います。**前者だけでも日々の巡回は減らせるので、そこから始めるという整理です。

## よくある質問

### なぜMakeでの自動化をやめたのですか？

**リモート環境でのOAuth認証の維持が煩雑だったためです。**定期実行では認証が切れると止まってしまうため、リフレッシュトークンの管理を含めた認証基盤を自前で持つか、ローカル接続にする方向へ切り替えました。

### Clarityの1日10回制限は回避できますか？

回避はできないため、**取得タイミングの最適化が必須です。**必要なときに都度叩く設計ではなく、決まった時刻に取得してキャッシュする前提で組む必要があります。

### どのAPIが一番大変でしたか？

**Google Ads APIです。**API自体の複雑さに加え、OAuth認証の永続化が実用化の鍵になります。GA4は制限にも余裕があり、比較的扱いやすい部類でした。

### 結局レポートは自動化できたのですか？

**全自動化は保留しています。**現時点では、ローカル環境で動くMCPとしてデータを取得し、レポート化は人間が行う段階です。認証基盤が整ってから、順次自動化を進める計画です。

## まとめ

-   複数の解析APIを束ねる際は、**最も制限の厳しいAPIが全体設計を決める**。Clarityは1日10回
-   GA4は制限に余裕があり扱いやすいが、**Google Ads APIの複雑さが最大の障壁**
-   実用化の鍵は**OAuth認証の永続化（リフレッシュトークン管理）**
-   リモート環境（Make等）での認証維持が煩雑なため、**ローカルMCPまたは自前の認証基盤**へ方針転換
-   全自動化を急がず、**まずデータ取得だけ自動化し、レポート化は人間が行う**段階から始める

定期実行の自動化は、作るところより「止まらずに動き続けること」が難しい領域です。認証まわりの設計を後回しにすると、あとで作り直すことになります。

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