GA4 APIの使い分け|Data・Admin・Realtime・BigQueryと取得手順
2026年8月7日
著者: 与謝秀作
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を使い分けるも参照してください。


