GA4 データを読み込む際にエラーが発生しました｜API クオータとしきい値の対処

はじめに

GA4 のレポート画面や Looker Studio のダッシュボードを開いた際、「このコンポーネントのデータを読み込む際にエラーが発生しました」というメッセージが表示され、グラフや表が描画されないことがあります。昨日まで正常に動作していたダッシュボードが突然表示されなくなるため、設定ミスや障害を疑いがちですが、多くの場合、原因は GA4 側の仕様（API クオータとデータしきい値）にあります。

本記事では、このエラーの 2 大原因である「GA4 Data API のクオータ制限」と「データしきい値」について、公式ドキュメントの上限値をもとに切り分けと対処の手順を解説します。

結論を先に述べると、このエラーの原因は「Data API のクオータ超過」と「データしきい値によるマスキング」のいずれかに大別されます。クオータは GA4 プロパティ単位で共有されるため、ダッシュボードのグラフ数や閲覧者数が増えるほど超過しやすくなります。恒久的な対処としては、Looker Studio から GA4 Data API を直接参照する構成をやめ、BigQuery を中間層に挟むアーキテクチャへの変更が有力な選択肢となります。

エラーの正体: GA4 Data API のクオータ制限とは

Looker Studio で GA4 のデータを可視化する場合、バックグラウンドでは GA4 Data API が使用されています。ダッシュボード上のグラフ・表・スコアカードなどのコンポーネント 1 つひとつが個別の API リクエストとして処理されるため、コンポーネント数の多いレポートや複数人での同時閲覧は、それだけ多くの API リソースを消費します。Google はこの API に対してプロパティ単位の利用上限（クオータ）を設けており、上限に達するとデータが返却されず、コンポーネントにエラーが表示されます。

エラーが発生する 2 大原因（クオータとしきい値）

このエラーメッセージに遭遇した場合、まず以下の 2 つのどちらに該当するかを切り分けることを推奨します。

 原因 1: Data API のクオータ超過

Looker Studio などの外部ツールから GA4 Data API へのリクエストが上限を超えたケースです。クオータには「トークン数（時間あたり・日あたり）」と「同時リクエスト数」の 2 系統があり、どちらを超過してもコンポーネントの読み込みに失敗します。クオータがリセットされるまで待つと一時的に復旧するため、「時間帯によって表示されたりされなかったりする」という症状はこのケースの典型です。

 原因 2: データしきい値によるマスキング

ユーザーのプライバシー保護のため、GA4 が意図的に一部のデータをレポートから除外しているケースです。ユーザー数が少ない期間・セグメントで集計した場合に発生しやすく、エラーというよりも「データの一部が欠落して見える」「BigQuery の生データと数値が合わない」という形で現れます。こちらは API の問題ではなく GA4 のレポート仕様であるため、対処のアプローチが異なります。

原因 1 の詳細な切り分けと対処は次章、原因 2 はその次の章でそれぞれ解説します。

標準プロパティのクオータ上限値（公式数値）

GA4 Data API のクオータは、Google の開発者向けドキュメントで公開されています。標準プロパティ（無償版）と Analytics 360 プロパティ（有償版）の主な上限値は以下のとおりです。

参考: Data API limits and quotas（Google for Developers）
“The number of tokens charged depends on the request’s complexity.”
（消費されるトークン数は、リクエストの複雑さに依存します）
https://developers.google.com/analytics/devguides/reporting/data/v1/quotas

トークンは API リクエストごとに消費され、大半のリクエストは 10 トークン以下ですが、集計期間の長さ、ディメンションのカーディナリティ（pagePath やカスタムディメンションなど一意な値が多いもの）、プロパティのイベント量によって消費量が増加します。目安として、グラフ 20 個とフィルタを配置したダッシュボードでは 1 回の表示セッションで 200 トークン前後を消費するため、1 時間あたり 40,000 トークンという上限は、複数人が頻繁に参照する社内ダッシュボードでは決して余裕のある数値ではありません。

ここで押さえておきたい重要な仕様が 2 点あります。

1 点目は、クオータが GA4 プロパティ単位で共有されることです。Looker Studio のダッシュボードだけでなく、Google スプレッドシートのコネクタ、自作スクリプト、サードパーティ製 BI ツールなど、同じプロパティに対するすべての API リクエストが同一のクオータを消費します。そのため、1 つの過剰なダッシュボードがプロパティ全体のクオータを使い切り、他のツールのデータ取得まで巻き添えで失敗させることがあります。

2 点目は、同時リクエスト数の上限（標準プロパティで 10 件）は Analytics 360 でも 50 件までしか拡張されず、コンポーネント数の多いレポートでは容易に到達することです。1 ページに 15 個のグラフを配置したダッシュボードは、開いた瞬間に 10 件を超えるリクエストを発生させ得るため、トークン残量に余裕があっても同時リクエスト超過のエラーが発生します。

なお、日次クオータは太平洋標準時（PST）の深夜 0 時、日本時間では夏時間で 16 時・冬時間で 17 時にリセットされます。「毎日夕方になると復旧する」という症状は、日次トークンを使い切っているサインとして切り分けに利用できます。

原因 1: Looker Studio 連携時の API クオータ超過

本章では、エラーの原因がクオータ超過であるかを切り分け、どのリクエストがトークンを消費しているかを特定する手順を解説します。クオータ超過は「どの上限に達したか」によって表示されるメッセージが異なるため、まずエラー文言から原因を絞り込むアプローチが有効です。

エラーメッセージ別の切り分け表

Looker Studio や API のレスポンスに表示される代表的なエラー文言と、その原因・対処の対応関係は以下のとおりです。

切り分けの観点として、「特定の時間帯だけ失敗し、翌日や 1 時間後に復旧する」場合はトークン枯渇、「ページを開いた瞬間に複数のグラフが同時に失敗する」場合は同時リクエスト超過の可能性が高いと判断できます。前章で述べたとおり、日次トークンのリセットは太平洋標準時の深夜 0 時（日本時間の夕方）であるため、復旧する時刻もヒントになります。

トークン消費の仕組みと 1 グラフあたりの目安

GA4 Data API はトークンバケット方式でクオータを管理しており、リクエストごとに複雑さに応じたトークンが消費されます。公式ドキュメントによると、大半のリクエストの消費は 10 トークン以下ですが、以下の要因で消費量が増加します。

• 集計期間の長さ: 期間が長いほど処理対象のデータが増え、消費トークンが増加します。
• ディメンションのカーディナリティ: pagePath やカスタムディメンションなど、一意な値が多いディメンションは消費量を大きく押し上げます。
• プロパティのイベント量: 同じクエリでも、イベント数の多いプロパティでは消費が増える傾向があります。

Looker Studio ではグラフ・表・スコアカード 1 つが 1 リクエストに対応するため、単純なグラフ 1 個で約 10 トークンが目安となります。グラフ 20 個とフィルタを配置したダッシュボードであれば、1 回の表示で 200 トークン前後を消費する計算です。さらに、閲覧者がフィルタや期間を変更するたびに再リクエストが発生するため、「複数人が営業時間中に頻繁に操作する共有ダッシュボード」は、時間あたり 40,000 トークンの上限に対して想定以上の速度でクオータを消費します。

returnPropertyQuota でトークン残量を確認する手順

API を直接利用している場合や、消費状況を定量的に確認したい場合は、リクエストボディに returnPropertyQuota を指定する方法が有効です。true を指定すると、レスポンスの propertyQuota オブジェクトに「そのリクエストで消費したトークン数」と「残量」が含まれます。

以下は runReport メソッドでの確認例です。（123456789 は対象の GA4 プロパティ ID に読み替えてください）

curl -X POST \
  -H "Authorization: Bearer $(gcloud auth print-access-token)" \
  -H "Content-Type: application/json" \
  "https://analyticsdata.googleapis.com/v1beta/properties/123456789:runReport" \
  -d '{
    "dateRanges": [{ "startDate": "7daysAgo", "endDate": "today" }],
    "dimensions": [{ "name": "pagePath" }],
    "metrics": [{ "name": "screenPageViews" }],
    "returnPropertyQuota": true
  }'

レスポンスには以下のような propertyQuota が付与され、日次・時間・同時リクエストの各バケットの消費量（consumed）と残量（remaining）を確認できます。

"propertyQuota": {
  "tokensPerDay": { "consumed": 14, "remaining": 199986 },
  "tokensPerHour": { "consumed": 14, "remaining": 39986 },
  "concurrentRequests": { "consumed": 0, "remaining": 10 },
  "tokensPerProjectPerHour": { "consumed": 14, "remaining": 13986 }
}

高カーディナリティのディメンションや長期間のクエリを本番投入する前に、この方法で 1 リクエストあたりの実測トークンコストを把握しておくと、ダッシュボード設計段階でクオータ超過を予防できます。なお、消費トークン数はリクエスト実行時に確定する仕様のため、事前の正確な見積もりはできず、実測での確認が基本となります。

データの API 割り当て履歴で消費元を特定する

「どのダッシュボードやツールがトークンを消費しているのか分からない」という場合は、GA4 管理画面の監査機能で消費元を特定できます。管理画面の「管理」＞「プロパティ」列にある「プロパティ単位のデータの API 割り当て履歴」を開くと、API 経由のデータアクセスが 1 件ずつ記録されており、以下の項目を確認できます。（閲覧には管理者ロールが必要です）

• アクセス日時
• アクセサーのアプリ名（Looker Studio、スプレッドシートのアドオン、外部連携サービス等）
• ユーザーのメールアドレス
• Data API 割り当てカテゴリ（コア・リアルタイム・ファネル）
• 消費した Data API 割り当てプロパティトークン数

参考: Google アナリティクスのアカウントまたはプロパティ単位のデータの API 割り当て履歴を表示する（アナリティクス ヘルプ）
“ユーザーまたはアプリが Google Analytics API を介してプロパティ データにアクセスしたタイミングを確認できます”
https://support.google.com/analytics/answer/15560170

期間は過去 2 年以内で指定でき、フィルタでアプリ名やユーザー単位に絞り込めます。エラーが頻発する時間帯で消費トークン数の多い行を抽出すれば、「どのユーザーが開いた、どのツールのリクエストがクオータを圧迫しているか」を客観的なデータで特定できます。特定の Looker Studio レポートが突出している場合は、そのレポートのコンポーネント削減や後述の BigQuery 連携への移行を優先的に検討する判断材料になります。

原因 2: データしきい値によるマスキング

クオータに余裕があるにもかかわらずデータが表示されない場合、データしきい値が適用されている可能性があります。しきい値はエラーではなく GA4 のプライバシー保護仕様であるため、「不具合として調査しても原因が見つからない」という状況に陥りやすいのが特徴です。本章では適用条件と回避策を解説します。

しきい値が適用される条件（2024 年以降の最新仕様）

データしきい値とは、レポートの閲覧者がユーザー属性（年齢・性別）やインタレストなどのシグナルから個別ユーザーを推測できないよう、ユーザー数が少ない集計単位のデータを意図的に除外する仕組みです。しきい値が適用されると、レポート右上のデータ品質インジケーターにオレンジ色の「！」アイコンが表示されます。

参考: データのしきい値について（アナリティクス ヘルプ）
“データのしきい値はシステムによって定義されるため、ご自身で調整することはできません”
https://support.google.com/analytics/answer/9383630

しきい値が適用されやすい条件は以下のとおりです。

• Google シグナルによるユーザー属性・インタレストデータの収集が有効になっている。
• 集計期間が短い、またはセグメントが細かく、対象ユーザー数が少ない。
• レポートにユーザー属性やユーザーベースのディメンション・指標が含まれている。
• レポートに検索語句（Search Console 連携のクエリ等）が含まれている。

なお、2024 年 2 月に「Google シグナルがレポート用識別子から削除される」という仕様変更がありました。この変更後、Google シグナルはユーザー識別（クロスデバイスの名寄せ）には使用されなくなりましたが、ユーザー属性・インタレストデータの収集機能としては存続しており、この属性データこそがしきい値の主要因である点は変わっていません。「2024 年の変更でしきい値はなくなった」という誤解が一部で見られますが、現在もしきい値は適用されます。

レポート用識別子「デバイスベース」への切り替え手順

しきい値の適用を減らす代表的な方法が、レポート用識別子の切り替えです。手順は以下のとおりです。

1. GA4 の「管理」を開き、「プロパティ」列の「レポート用識別子」をクリックします。
2. 選択肢が「ハイブリッド」「計測データ」の 2 つしか表示されない場合は、「すべて表示」をクリックします。
3. 「デバイスベース」を選択し、保存します。

デバイスベースではデバイス ID（Web の場合はクライアント ID）のみでユーザーを識別し、User-ID や属性由来のシグナルを無視するため、しきい値が適用されにくくなります。運用上、以下の 2 点を把握しておくと安心です。

 この設定はデータの収集・処理には影響せず、レポートの集計方法だけを切り替えるものです。公式ヘルプにも、いつでも切り替え可能でデータに永続的な影響はない旨が明記されており、「しきい値で見えない数値を確認するときだけデバイスベースに切り替え、確認後に元へ戻す」という一時的な運用が可能です。

 切り替えはプロパティ全体に反映されるため、同じプロパティを参照している他のメンバーのレポート数値（特にユーザー数・アクティブユーザー数）も変動します。チームで運用している場合は、事前に周知した上での切り替えを推奨します。

期間延長・ディメンション見直しによる回避

レポート用識別子を変更せずにしきい値を回避したい場合は、レポート側の工夫でも対処できます。

 集計期間を延長する: しきい値はユーザー数の少なさに起因するため、期間を広げて対象ユーザーの総数を増やすことで、除外されていたデータが表示されることがあります。公式ヘルプでも案内されている、最も副作用の少ない方法です。

 ユーザー属性系のディメンションを外す: 年齢・性別・インタレストなどのディメンションや、ユーザーベースの指標を使わない形にレポートを再構成すると、しきい値の適用条件から外れやすくなります。

 BigQuery エクスポートで生データを参照する: しきい値はレポート表示層の仕組みであるため、BigQuery にエクスポートされたイベントデータには適用されません。恒久的にしきい値の影響を受けない分析基盤が必要な場合は、次章で述べる BigQuery 連携が選択肢になります。

対処法の比較と選定ガイド

ここまで見てきたエラー・マスキングへの対処は、暫定対処から恒久対策まで複数の選択肢があります。本章では代表的な 4 つの対処法を比較し、状況別の選定基準を整理します。

4 つの対処法の比較表

選定の目安は以下のとおりです。

 まず試すべきは構成見直しと Extract Data です。1 ページあたりのコンポーネントを 10 個未満に抑える、更新頻度の低いレポートは Extract Data のスナップショット（自動更新スケジュール設定可）に置き換える、といった対処で多くのケースは解消します。

 複数チームがダッシュボードを常用しており、エラーが業務影響を及ぼしている場合は、BigQuery を中間層とするアーキテクチャへの移行が費用対効果の高い恒久対策です。Looker Studio のデータソースを GA4 コネクタから BigQuery に切り替えることで、GA4 Data API のクオータの制約から外れます。

 GA4 360 は、クオータ以外の要件（サンプリング回避・データ保持期間・SLA 等）も含めて必要性がある場合の選択肢です。クオータ対策のみを目的とした導入は、コストに見合わないケースが多いと考えられます。

BigQuery 連携時の注意点（ユーザー数の乖離・無料枠）

BigQuery 連携は根本対策として有力ですが、移行前に把握しておくべき制約が 3 点あります。

1 点目は、日次エクスポートの上限です。

参考: BigQuery Export（アナリティクス ヘルプ）
“標準プロパティでは、BigQuery Export の 1 日の上限は 100 万イベントです”
https://support.google.com/analytics/answer/9358801

標準プロパティの日次（バッチ）エクスポートは 1 日 100 万イベントが上限で、継続的に超過すると日次エクスポートが一時停止され、停止期間分のデータは再処理されません。トラフィックの多いサイトでは、エクスポート対象のデータストリームやイベントを絞り込む設定（page_view 以外の高頻度イベントの除外等）を事前に検討することを推奨します。なお、ストリーミングエクスポートにはイベント数の上限がありませんが、1 GB あたり 0.05 ドル（イベント約 60 万件相当）の追加費用が発生します。

2 点目は、レポートと BigQuery でユーザー数が一致しない点です。BigQuery へのエクスポートには Google シグナル由来のデータが含まれないため、GA4 のレポート画面（特にハイブリッド識別子使用時）とはユーザーの名寄せ精度が異なり、ユーザー数・アクティブユーザー数に乖離が生じます。「BigQuery の数値がレポートと合わない」のは多くの場合この仕様によるもので、異常ではありません。

3 点目は、費用です。エクスポート自体は無料で、エクスポート先として BigQuery サンドボックス（無料インスタンス）も利用できますが、サンドボックスにはストレージ上限やテーブル有効期限などの制限があります。本格運用ではストレージとクエリ処理に対する従量課金が発生するため、小規模サイトであれば実質無料枠に収まる一方、データ量の多いサイトではクエリ設計（スキャン量の削減）がコスト管理のポイントになります。

まとめ

「このコンポーネントのデータを読み込む際にエラーが発生しました」は、GA4 の障害や設定ミスではなく、Data API のクオータ制限とデータしきい値という 2 つの仕様に起因することがほとんどです。まずエラーがどちらに該当するかを切り分け、暫定対処から BigQuery 連携などの恒久対策まで、状況に応じて選択することが解決への近道となります。

• エラーの原因は API クオータ超過とデータしきい値の 2 つに大別される。
• クオータは GA4 プロパティ単位で共有され、超過すると全ユーザーが影響を受ける。
• 標準プロパティの上限は 1 日 20 万・1 時間 4 万トークン、同時リクエスト 10 件。
• 時間帯で復旧するならトークン枯渇、同時失敗なら同時リクエスト超過を疑う。
• returnPropertyQuota と API 割り当て履歴で消費元を特定できる。
• データしきい値は Google シグナルの属性データが主因で無効化はできない。
• 恒久対策は BigQuery を中間層に挟みクオータの制約から外す構成。

以上、最後までお読みいただきありがとうございました。