GA4 APIの使い分け|Data・Admin・Realtime・BigQueryと取得手順

2026年8月7日

著者: 与謝秀作
GA4 APIとは?できることとBigQuery/レポート連携への活用例

GA4の定例レポートを自動取得したいときは、まず集計レポート、設定情報、直近の状況、エクスポートされたイベントのどれが必要かを決めます。Data API、Admin API、Realtimeメソッド、BigQueryは役割が異なります。認証から取得条件、割り当て、数値照合までを、実装前に使える表と架空例で整理します。

Data・Admin・RealtimeとBigQueryの役割を分ける

Google Analytics Data APIは、ディメンションと指標を指定して集計レポートを取得する仕組みです。保存済みのレポートデータを任意に書き換える機能ではありません。runReportなどの通常レポートと、直近の状況を取得するrunRealtimeReportを目的で使い分けます。

Admin APIはアカウント、プロパティ、ストリームなどの設定・管理を扱い、設定変更を行うメソッドもあります。BigQueryエクスポートはイベントをデータウェアハウスへ出力する別の方式です。Data APIから生イベント全件を取得することと同一ではありません。

目的に合わせて取得方式を選ぶ比較表

方式

向く問い

注意点

Data APIの通常レポート

週次の入口・チャネル・指標を集計したい

互換性、期間、割り当て、レポートの集約条件

Data APIのRealtime

直近のアクティブ状況を把握したい

標準は過去30分、360は最大60分。通常期間のレポートと別

Admin API

プロパティやストリームの管理情報を確認したい

読み取りと変更の権限を分ける

BigQueryエクスポート

エクスポートされたイベントをSQLで分析したい

出力開始日、SQL設計、欠落、保存・処理費用

週次の集計表だけが必要なら、まずData APIで必要列を少なくした構成を検討します。CRMとの結合が必要なら、許可された結合キーとデータ範囲を決めてからBigQuery等を検討します。データ量が多いという理由だけで、最初から全方式を組み合わせる必要はありません。

API有効化・認証・プロパティ権限を確認する

公式クイックスタートに沿ってCloudプロジェクトとAPI有効化、認証する主体、対象GA4プロパティへのアクセスを確認します。ユーザー認証とサービスアカウントでは主体が異なり、サービスアカウントにも対象プロパティの権限が必要です。APIを有効にしただけではアクセスできません。

  • 対象の数値プロパティIDを確認する。G-で始まる測定IDは代用しない。
  • レポート取得には必要な読み取り権限とOAuthスコープを確認し、不要な管理変更権限を渡さない。
  • APIキーだけで非公開レポートへのアクセス権が得られると考えない。
  • 鍵・トークンを記事、共有URL、共有シートへ貼らず、管理担当と失効・交代の方法を決める。

指標・期間・フィルターを決めてレポートを取得する

runReportの仕様を基に、指標、ディメンション、開始日・終了日、フィルター、並び順を取得仕様書へ残します。getMetadataやcheckCompatibilityで利用可能な名前と組合せを確認し、少量のレポートから試してください。

入口の自然検索を知りたい場合は、入口ディメンションとSession default channel groupなどセッションの条件をそろえます。First user・Session・イベントのスコープは異なるため、初回獲得元をセッション流入元の代わりにしません。本番ホストと言語も記録し、同じパスが別ホストに存在する場合の混合を防ぎます。欠落行の有無と、ゼロが記録された行も区別します。

割り当て・ページ分割・再試行を設計する

2026年10月12日に確認した標準プロパティのCore割り当ての主な上限は次のとおりです。これはトークン数や同時実行の上限であり、同数のリクエストを実行できるという意味ではありません。

Coreの制限

標準プロパティ

プロパティあたり1日

200,000トークン

プロパティあたり1時間

40,000トークン

プロジェクト×プロパティあたり1時間

14,000トークン

プロパティあたり同時リクエスト

10

行・列の数、フィルターの複雑さ、期間などで消費が変わります。returnPropertyQuotaで状態を確認し、429等は制限の種類を調べて頻度・複雑さ・同時実行を調整します。待ち時間を設けた再試行にも上限を決め、無制限に再送しません。Core以外のメソッドは最新の区分と表を別確認します。

runReportは既定10,000行、1要求の最大250,000行です。架空の32,000行をlimit 10,000で取得するならoffset 0、10,000、20,000、30,000の4回で、最後は2,000行です。期間・フィルター・安定した並び順を固定し、rowCountと取得行数を照合します。分割中のデータ更新まで同じスナップショットになる保証はないため、取得日時と再確認を残します。

UIとAPIとBigQueryの数値差を照合する

差を見つけたら、先に同じ問いを比べているか確かめます。指標の分母、期間・タイムゾーン、フィルター、Reporting identity、データ鮮度を順に照合します。ページ別のアクティブユーザーを足して全体人数にするなど、集計側の誤りも候補です。

BigQueryのエクスポートはUIで加えられる処理やモデル済み指標と同じものではありません。しかし、rawだから全利用者の完全な実態になるわけでもありません。同意、未送信、識別、重複、遅延、クエリの定義を確認します。Streamingはbest effortで欠落し得るため、日次表の利用も含めて照合します。差をすべて仕様、あるいはすべて不具合と決めつけないでください。

架空の週次レポートを設計する

以下は架空の設計票です。対象は日本語の記事入口、直前の完了した7日間と対応する前期間、Organic Searchと全経路を別に取得する週次レポートです。

設計項目

架空の記入例

目的と対象

特定記事を入口にしたセッションの変化を確認

条件

本番ホスト、言語パス、同じ日数、セッションチャネル

列

入口パス、セッション、正式な平均時間、キーイベント件数

照合

同じ条件のUI、取得行数、割り当て残量、取得時刻

別系列

GSCクリックは別に取得して並記し、セッションと同一化しない

成果

成功条件・重複・認証遷移が未検証なら登録人数は未測定

一度取得できたことと、比較や成果の意味まで確認できたことは別です。自動更新の前に人が一回照合し、再取得条件と担当を決めると、定例の差を追いやすくなります。

運用担当・費用・未測定項目を記録する

BigQueryは出力開始日と利用できる履歴を確認し、連携前の全履歴を自動的に遡及取得できる前提で設計しません。標準の日次エクスポートは1日100万イベントまでで、保存・処理やStreamingの費用は公式のエクスポート案内から現在の料金条件を確認します。無料・無制限・必ず安定という表現は避けてください。

BIツールがBigQueryを参照する構成でも、Cloud側の費用、割り当て、更新遅延は残ります。認証管理、取得エラー、欠落、費用、指標の定義変更を誰が確認するかを台帳へ残しましょう。まず必要な一つのレポートを再現可能にし、追加データや成果検証は目的が固まってから広げます。

次に確認する内容に合わせて、DMPとは?CDP・CRMとの違いとデータ活用の選び方、アクセス解析レポートの作り方|GA4指標の定義と改善提案の型、GA4の平均エンゲージメント時間|分母・計算例・改善判断、検索キーワードの調べ方|候補収集・検索数・GSCを使い分けるも参照してください。

関連記事