Google Analytics Data APIとは？ GA4レポートをUbuntuから自動取得する

この記事について

この記事について
この記事は、生成AIを活用した自動生成フローで作成しています。
Google Analytics Data APIの公式ドキュメントとQuickstartを確認し、GA4のレポートを「画面で見る」だけでなく、PythonやRESTから安全に取得して業務へつなぐ流れを整理します。

情報確認基準日：2026-09-19
GoogleのAPI、認証方式、料金・クォータ、画面名称は変更される可能性があります。利用時は末尾のGoogle公式情報も確認してください。

まず一言でいうと

Google Analytics Data APIは、GA4のレポートをプログラムから取り出すための公式な窓口です。

GA4（Google Analytics 4）はWebサイトやアプリで「何人が来たか」「どのページを見たか」「どんなイベントが発生したか」などを分析するサービスです。Data APIを使うと、そのレポートを毎回ブラウザで開いて転記する代わりに、PythonやRESTから取得できます。 次の4点が分かります。

• Data APIがGoogle全体のどこにいるのか

• GA4画面・Property・API・認証がどうつながるのか

• 自動レポートを作るとき、どこまでがData APIの仕事なのか

• Microsoft系の分析APIを知っている人がどう捉えればよいのか

Google全体では何のパーツ？

Data API自体がアクセスを計測するわけではありません。計測するのはGA4、Data APIは計測済みデータを取り出すパーツです。

flowchart LR
  U[サイト利用者] --> SITE[Webサイト / アプリ]
  SITE --> GA[GA4 Property<br/>計測・集計]
  GA --> API[Google Analytics Data API<br/>レポート取得口]
  API --> PY[Python / REST / SDK]
  PY --> OUT[CSV・社内レポート・ダッシュボード]
  OUT --> DEC[改善判断]

用語を先に整理する

何ができる？

代表的なレポート操作は次のとおりです。

最初は runReport が分かりやすいです。たとえば「過去7日の日付別activeUsers」を毎朝取得できます。

GA4画面との関係

Data APIは「別のAnalytics」ではありません。GA4 Propertyのレポートを、プログラムから扱うための入口です。

sequenceDiagram
  participant Job as Ubuntu / Python
  participant Auth as Google認証
  participant API as Analytics Data API
  participant GA as GA4 Property
  Job->>Auth: 認証情報を使って認証
  Auth-->>Job: 利用可能な資格情報
  Job->>API: runReport(Property ID, Dimension, Metric)
  API->>GA: レポートデータを参照
  GA-->>API: 集計結果
  API-->>Job: レポート応答
  Job->>Job: 必要列だけ保存・加工

ここで大切なのは、認証できたことと、対象Propertyを読めることは別という点です。利用主体には対象GA4 Property側で必要なアクセス権が必要です。

認証はどう考える？

2026-09-19時点の公式Quickstartでは、ユーザーアカウントとService Accountの双方が案内されています。ローカル開発ではユーザー資格情報を使い、自動処理では実行環境に合ったService Account等を選ぶ構成があります。

ADC（Application Default Credentials）は、コードへ秘密情報を直接書かず、実行環境から利用可能な資格情報を探す仕組みです。Google Cloud上の本番環境では、可能ならリソースへService Accountをアタッチして短期資格情報を使う方式を優先し、長期のService Account keyを安易に配布しません。

Pythonで安全な読み取りを試す

次は公式Quickstartに近い読み取り例です。Property IDはダミーです。

from google.analytics.data_v1beta import BetaAnalyticsDataClient
from google.analytics.data_v1beta.types import DateRange, Dimension, Metric, RunReportRequest

PROPERTY_ID = "000000000"  # ダミー。実値を公開リポジトリへ固定しない

client = BetaAnalyticsDataClient()
request = RunReportRequest(
    property=f"properties/{PROPERTY_ID}",
    dimensions=[Dimension(name="date")],
    metrics=[Metric(name="activeUsers")],
    date_ranges=[DateRange(start_date="7daysAgo", end_date="yesterday")],
)

response = client.run_report(request)
for row in response.rows:
    print(row.dimension_values[0].value, row.metric_values[0].value)

何を見る？

日付とactiveUsersの値が行単位で返ることを確認します。

成功条件

認証エラーや権限エラーにならず、対象期間のレポート行が返れば最小確認は成功です。0行の場合は「API失敗」と即断せず、期間、Dimension / Metric、Property、実データの有無を確認します。

1か所変えてみる

Dimension(name="date") を、利用可能な別Dimensionへ変更すると「何別に集計するか」が変わります。変更前にMetadataや公式Dimension / Metric一覧を確認すると安全です。

Ubuntuで定期実行するなら

systemd timer
    ↓
Python
    ↓
ADC / 実行環境の認証
    ↓
Analytics Data API
    ↓
必要な列だけ抽出
    ↓
CSV / レポート

Service Account keyファイルを使わざるを得ない構成でも、本文、GitHub、systemd unitへ秘密鍵そのものを書きません。環境変数でファイル位置を渡す場合も、そのファイル自体をGit管理から除外します。

仕事ではどう使う？

一般利用者・事務職 / Web担当者

毎週のアクセス報告を手作業で転記する代わりに、決まった指標をCSV化できます。まずは「日付・activeUsers」程度の小さなレポートから始めると、数字の意味を確認しやすくなります。

IT管理者

誰の資格情報で動くか、対象Propertyへの権限、Cloud Project、API有効化、クォータ、秘密情報の保管方法、失敗時ログを管理します。自動化スクリプトより認証・権限設計の方が重要になることがあります。

開発者

runReport、Realtime、Pivot等をアプリやバッチへ組み込みます。APIレスポンスをそのまま公開せず、用途に必要なデータだけを保存する設計にします。

Search Console・AdSense・BigQueryとの役割分担

flowchart LR
  SC[Search Console API<br/>検索前] --> SAFE[必要項目だけの分析データ]
  GA[Analytics Data API<br/>サイト内] --> SAFE
  AD[AdSense API<br/>収益] --> SAFE
  SAFE --> REPORT[改善レポート]

3つを組み合わせても、個人情報や不要な識別子まで保存する必要はありません。分析目的に必要な最小限の項目へ絞ります。

Microsoftを知っている人はどう理解する？

完全な1対1対応製品はありませんが、「管理画面のデータをAPIで取得して自動レポートへつなぐ」という考え方はMicrosoft Graphや各MicrosoftサービスのレポートAPIに近いです。

「Google版Microsoft Graph」と丸ごと置き換えて考えるのは不正確です。Data APIはGA4という特定サービスの分析レポートAPIです。

料金・クォータは固定値で覚えない

APIの利用条件やクォータは変更される可能性があります。実装時はGoogle公式のData APIドキュメントとクォータページを基準日時点で確認してください。Google Cloud Projectの課金設定が必要になる他サービスと同じ感覚で、固定料金を推測しないことが重要です。

セキュリティで最低限守ること

• Service Account JSON、private key、access token、refresh tokenをGitHubへ保存しない

• 対象GA4 Propertyへの権限を必要最小限にする

• 公開用データにはメールアドレスや不要な識別子を含めない

• 本番では長期Service Account keyより、利用可能ならアタッチされたService Account等の短期資格情報を優先する

• ログにもTokenや秘密情報を出力しない

よくある勘違い

Property IDはMeasurement IDと同じ？

違います。Data APIでは数値のGA4 Property IDを指定します。Web計測で見る G-... のMeasurement IDとは役割が異なります。

Service Accountを作ればすぐ読める？

いいえ。認証主体を作るだけでなく、対象GA4 Property側で必要なアクセス権が必要です。

Data APIがWebサイトを計測してくれる？

いいえ。Data APIは計測済みのGA4レポートを取得するパーツです。

結局どういうサービス？

Google Analytics Data APIは、GA4の分析結果と自分のプログラムをつなぐ公式の出口です。Webサイトの計測そのものをするサービスではなく、GA4 Propertyに蓄積・集計されたレポートをPythonやRESTへ渡します。

そのため実務では「APIコードを書く」だけでなく、GA4 Property → 権限 → 認証 → Data API → 必要項目だけ保存 → 改善判断という一連の流れで考えると理解しやすくなります。

Papandaで触ってわかる：GA4レポートを「表→グラフ」へ

見える成果物：dimension/metricの小さなレポートをCSVにし、ブラウザまたはExcelでグラフ表示。 Daily Codeは実API取得部と可視化部を分け、公開版ではダミーanalyticsデータを使います。日付範囲を1か所変えて結果件数が変わることを成功条件にします。

Google公式情報

• Google Analytics Data API overview

• Google Analytics API quickstart

• Create a report

• Application Default Credentials

• Set up Application Default Credentials