Looker StudioでGA4のグラフが出ない｜Data APIでトークンを数えた

データポータル（英語名 Data Studio、旧 Looker Studio）に GA4 をつないだレポートで、グラフの代わりに「This property has issued too many requests in the last hour.」のような英語のエラーが出て、それが公式のトラブルシューティングに載っている7つの割り当てのエラーのどれかなら、GA4 Data API の割り当てに当たっています。GA4 に接続するデータポータルのレポートには Data API の割り当てが適用され、標準のプロパティでは1日 200,000 トークン、1時間 40,000 トークンなどの上限があります。典型的なグラフと同じ形のリクエスト1本が使うトークンは、当社サイトの GA4 プロパティで、2026年10月15日に Data API で測った値では1トークン、重くした形で8トークンでした。

測る前は、同じリクエストを続けて投げれば2回目はキャッシュから返ってほぼ0になると考えていました。実際には0にはならず、約4分（3.7分と4.4分）あけた2回では元の値に戻り、重くした形は4回投げて4回とも8でした。トークンを減らすには、Data API に同じ問い合わせを繰り返すことに期待するのではなく、データポータル側で問い合わせ自体を減らす必要がある、というのがこの記事の結論です。当社は、GA4 と Google タグ マネージャーでの計測の設計・実装から、BigQuery を使ったデータ基盤やデータポータルのダッシュボードづくりまでを支援している会社で、今回は自社のコーポレートサイトの GA4 で測りました。

測ったのは Data API に直接投げたリクエストで、データポータルの画面では測っていません。データポータルが1つのグラフを表示するのに Data API へ何本のリクエストを出すかも、確かめていません。そのため、この記事の「グラフ1つ」は「典型的なグラフと同じ形のリクエスト1本」の意味です。接続や認証のエラー、BigQuery につないだときの料金（データポータルの BigQuery 料金）は扱いません。Looker Studio は2026年4月に元の名前の Data Studio に戻り、日本語の公式ドキュメントでは「データポータル」です（Google Cloud「データポータルへようこそ」）。

エラーの文言で、どの割り当てが尽きたかを分ける

公式のトラブルシューティングには、GA4 の割り当てを超えたレポートに出るエラーとして、次の7つが英語のまま載っています。日本語のヘルプでも英語です。どのエラーがどの割り当てに当たるかの対応表は公式の資料には見当たりませんが、文言と Data API の割り当ての表の項目名を突き合わせると、次のように読めます。

トークンの割り当ては3つあり、1回のリクエストで使ったトークンは、1日・1時間・プロジェクトとプロパティの組ごとの1時間の3つから同時に引かれます。どれかの残りが0になると、そのプロパティへのその後のリクエストは Data API では 429 RESOURCE_EXHAUSTED のエラーになります。1日の割り当てはすべて太平洋標準時の午前0時に戻り、1時間の割り当ては1時間以内に戻りますが、ちょうど1時間の区切りで戻るとは限りません。また公式は、1時間の2つの割り当てはどちらも消費されるので、プロパティあたりの 40,000 がプロジェクトとプロパティの組ごとの 14,000 より先に上限に達するには、1つのプロパティに3つ以上のプロジェクトからアクセスする必要がある、としています。1つのプロジェクトから読む限り、先に尽きるのは 14,000 のほうです。

しきい値が設定される可能性のあるリクエストは、userAgeBracket・userGender・brandingInterest・audienceId・audienceName（年齢・性別・インタレスト・オーディエンスの系統）のディメンションを含むリクエストのことで、1時間に 120 件までです。これらのディメンションを使ったグラフでだけ出るエラーなら、トークンの量ではなくこの件数を疑います。

当社の GA4 で、リクエスト1本ずつのトークンを数えた

Data API には、リクエストに "returnPropertyQuota": true を付けると、そのリクエストで使ったトークンと残りを応答に返す仕組みがあります。公式も、リクエストのトークンの費用を知る最も効果的な方法としてこれを挙げています。2026年10月15日の9時56分から10時03分（日本時間）に、当社のコーポレートサイトの GA4 プロパティ（標準）に、データポータルの典型的なグラフと同じ形のリクエストを、サービス アカウントの読み取り権限で1本ずつ、計42本投げました。データポータルを通さず REST で直接投げたので、データポータルのメモリは間に入っていません。

たとえば日別セッションの折れ線と同じ形のリクエストの主な部分は、次のとおりです（並べ替えの指定は省き、プロパティ ID は伏せています）。

POST https://analyticsdata.googleapis.com/v1beta/properties/PROPERTY_ID:runReport
{
  "dateRanges": [{ "startDate": "2026-09-17", "endDate": "2026-10-14" }],
  "dimensions": [{ "name": "date" }],
  "metrics": [{ "name": "sessions" }],
  "limit": "10000",
  "returnPropertyQuota": true
}

応答の最後に、次のような propertyQuota が付きます。consumed がこのリクエストで使ったトークン、remaining が残りです。

"propertyQuota": {
  "tokensPerDay": { "consumed": 1, "remaining": 199859 },
  "tokensPerHour": { "consumed": 1, "remaining": 39859 },
  "tokensPerProjectPerHour": { "consumed": 1, "remaining": 13859 },
  …
}

最初の1本の consumed と remaining を足すと、1日 199,996、1時間 39,996、プロジェクトとプロパティの組ごとの1時間 13,996 で、公式の表の 200,000・40,000・14,000 から、測り始める前に使われていた数トークンを引いた値でした。同時リクエスト 10、サーバーエラー 10、しきい値のリクエスト 120 も、表のとおりです。

1つ気をつけたいのは、remaining の差から1本の消費を計算しないことです。続けて投げた2本の間で、1日の残りが自分の消費より多く減った組がありました。理由は確かめていません。残りが前の回より増えた組もあり、残りの表示は単調に減るとは限りませんでした。1本ずつのトークンは、応答の consumed で読みます。

以下の数字は、すべてこの日のこのプロパティで1回ずつ測った値です。公式は、トークンの正確な費用は実行時に決まるので事前の計算は難しいとし、イベント数の多いプロパティでは、データ量の少ないプロパティより同じクエリで多くのトークンを使うことがあると書いています。データ量やイベント数の多いプロパティでは、同じ形でも数字が大きくなりえます。読んでほしいのは、何を変えると増え、何を変えても減らなかったかの向きです。

出典：Google Analytics「Data API の制限と割り当て」（トークンの消費に影響する要因、トークンの使用状況のモニタリング）

典型的な1ページを1回表示する相当で、4トークン

例として、28日のダッシュボードを1ページ考えます。セッションのスコアカード（前の28日と比較）、日別セッションの折れ線、チャネル（セッションのデフォルト チャネル グループ）別のセッションの棒、ページ別の表（ページパスとページのタイトル、表示回数（screenPageViews）・合計ユーザー数・エンゲージメント率）の4つです。それぞれと同じ形のリクエストは、どれも 1 トークンで、4本で 4 トークンでした。続けてもう一度同じ4本を投げた（ページを表示し直した相当）ときも、4本とも 1 で、合わせて 4 でした。

公式は、ほとんどのリクエストは10トークン以下だとしています。今回の42本も、いちばん多くて8でした。1日 200,000 トークンに対して、この1ページ1回分の4はごく一部です。上限に当たるのは、グラフの数・表示の回数・見る人の数を掛け合わせた量が大きいときか、データ量の多いプロパティで1本あたりが大きくなるとき、と考えられます。ただし、これは計算からの推論で、今回は上限に当てていません。

何を変えると増えたか：条件を1つずつ変えた

公式は、トークンが増える要因として、行数（より多くの行を求める）、ディメンションと指標の数、フィルタの複雑さ、期間の長さ、ディメンションのカーディナリティ（固有の値の多さ）、プロパティのイベント数の6つを挙げています。このうちリクエストの側で変えられるものを、1つずつ変えて投げました。

ディメンションは、数より中身で増えた

90日・指標はセッション1つのまま、ディメンションを日付から1つずつ足しました。日付だけ、チャネルを足す、参照元（セッション参照元）を足す、までは 2・2・2 で変わらず、ランディング ページを足したところで 3 になり、デバイス（デバイス カテゴリ）を足しても 3 のままでした。

公式は、ページパスやカスタム ディメンションのように固有の値が多いディメンションは、トークンを大きく増やすことがあるとしています。今回も、値の種類が少ないチャネルやデバイスでは変わらず、セッションの最初のページのページパスが値になるランディング ページを重ねたところで増えました。ただ、値の多いディメンションでも1つだけなら軽く、ページパスだけの表（90日）は 1、ページパスとページのタイトルの表（28日）も 1 でした。増えたのは、日付・チャネル・参照元にランディング ページを重ねた形（3）と、ページパスにチャネルを重ねた表（3）です。今回の範囲で言えるのは、値の多いディメンションをほかのディメンションと重ねると増えた、までです。公式も、頻繁に投げる問い合わせでは値の多いディメンションを組み合わせないよう勧めています。

期間は、延ばすと増えた

日付×チャネルの形で期間だけを変えると、7日 1、28日 1、90日 2、14か月相当 3 でした。14か月相当（2025年8月15日から）を指定した期間には、当社のプロパティにデータが無い期間も含まれます。データの無い期間を指定したぶん増えたのか、データのある期間の分で増えたのかは、この測り方では分けられません。

今回は28日までなら最小の1でした。期間を長くとるグラフは、今回の範囲では1本あたりが増えました。前の期間と比べるスコアカードは28日と28日の組で試しただけで、1でした。

指標の数は、この1組では言い切れない

日付×90日で、指標を1つから5つにすると 1 から 2 になりました。ただ、比べた指標1つの形は、limit だけを変えた同じ形を2回測ったところ 2 と 1 に分かれたので、この1組だけでは指標の数がどれだけ効くかは言えません。公式は指標の数も要因に挙げています。

行数の上限（limit）は、1回目では差が出なかった

ページ別の表（90日）で、返す行数の上限 limit を 10、100、10,000 と変えても、1・1・1 で同じでした。重くした形（ディメンション5・指標5・14か月相当）でも、limit 100 と 100,000 はどちらも1回目が 8 と 8 でした。公式は「より多くの行をリクエストする」ことを費用が高くなる要因に挙げていますが、1回目の値では差が出ませんでした。ただし、同じリクエストを繰り返したときは、limit 100 の重くした形が2回目から 1 になった一方、limit 100,000 の形は毎回 8 のままでした（次の節）。limit が効かないとまでは言えず、言えるのは1回目では差が出なかったことまでです。

単純なフィルタは、増やさず減らした

ページ×チャネル（90日）の表に、フィルタを1つだけ付けました。フィルタ無しが 3、チャネルが Organic Search に完全一致で 2、ページパスに /blog/ を含むで 2 です。期待していたのは「変わらないか増える」でしたが、結果の行が減る方向の単純なフィルタでは、減りました。

公式が費用を上げる要因に挙げているのは「複雑なフィルタ式」で、今回の1条件のフィルタとは別のものです。AND・OR を重ねたフィルタや正規表現は試していません。ブログの記事だけ、自然検索だけのように見る範囲が決まっているページなら、グラフかページにフィルタを付けておくと、1本あたりが下がる場合があります。

同じリクエストを繰り返しても、0にはならなかった

いちばん期待と違ったのが、まったく同じリクエストを繰り返したときです。日付・チャネル・参照元・ランディング ページの4つ（90日）の形は、1回目が 3、0.7分後の2回目が 1、続けて 0.1分後の3回目も 1 と、安くはなりましたが0にはなりませんでした。ところが、3.7分あけた4回目は 3 に戻り、その 0.4分後の5回目はまた 1 でした。ページ×チャネルの形も、4.4分後の2回目は 3 のまま安くならず、直後の3回目が 1 でした。

短い間隔の回だけ安くなったように見えますが、何分までなら安くなるのか、そもそもこれが Data API 側のキャッシュによるものなのかは、今回の回数では決められません。Data API の割り当てのページにも、同じリクエストを繰り返したときの扱いの説明は見当たりませんでした。

重くした形は、さらに違う動きでした。ディメンション5・指標5・14か月相当・limit 100,000 の形は、0.2分後・1.6分後・2.2分後に同じ本文を投げても、毎回 8 でした。同じ形で limit だけを 100 にしたものは、1回目が 8、直後の2回目と3回目は 1 です。2つはリクエストの limit が違い、limit 100,000 の形は条件に合う行をすべて、limit 100 の形は100行を返していました。ただ、原因は公式では確かめられず、言えるのは「返す行が多いと、繰り返しても安くならないことがあった」までです。

本文が少しでも違うと、安くなりませんでした。4つのディメンションの形で、ディメンションの順番だけを入れ替えたものも、limit を 10,000 から 9,999 に変えただけのものも、直前に同じ形を投げていたのに 3 と 3 でした。一方で、日付だけの形を limit 9,998 にしたものは、1分後に 1 でした（同じ形の1回目は 2）。これは上の動きと合わず、1回ごとの値の揺れなのかは、同じ条件を繰り返し測っていないので分かりません。

ここから言えるのは、Data API に同じ問い合わせを繰り返しても、トークンが0になることを当てにはできない、ということです。GA4 に直接つないだグラフで、トークンを使わずに出せるのは、データポータルが自分のメモリから返したときです。データポータルのヘルプは、トークンの使用状況のダイアログで、緑色のチェックマークは「トークンを消費せずに」メモリからグラフを読み込んだこと、赤い X は GA4 に直接問い合わせたことを示す、と説明しています。対処の手順も、このメモリを効かせる方法が先に並んでいます。

出典：データポータル ヘルプ「データポータルのエラーのトラブルシューティング」（トークンの使用状況を表示する）、Google Analytics「Data API の制限と割り当て」

減らす手順：公式の解決手順は8つ

データポータルのトラブルシューティングは、GA4 の割り当てを超えたときの解決手順を、GA4 に問い合わせるデータを減らし、データポータルのキャッシュをもっと使う方法として、次の並びで挙げています。順に行うようにとは書かれていません。

1と2は、どちらもデータポータルのメモリを効かせて、GA4 への問い合わせそのものを減らす方法で、並びの最初にあるのはそのためと読めます。データの認証情報は、データソースのフィールド パネルの上部で変えられます。オーナーの認証情報にすると、データセットへのアクセス権がない人もレポートを見られ、閲覧者の認証情報にすると、見る人ごとに各自の認証情報が要ります。見る人が多いレポートで閲覧者の認証情報になっていたら、まずここを確かめます。

4を今回の測定に当てはめると、メモリから返せない表示は、グラフと同じ形のリクエスト1本ごとに少なくとも1トークンかかりました。繰り返しても0にはならなかったので、グラフを減らすかページを分けるのが、そのまま問い合わせの回数を減らすことになります。6で BigQuery を経由したときにどの操作で料金がかかるかはデータポータルの BigQuery 料金で、GA4・BigQuery・データポータルの組み合わせ方はGA4 と BigQuery と Looker Studio の構成の比較で書いています。

なお、データポータルの GA4 のデータの更新頻度の既定は12時間です。同じヘルプは、データが更新頻度の設定より古くなることはない一方で、その間隔の間にメモリからデータが配信される保証はない、とも書いています。メモリを効かせる手順を取っても、すべての表示がトークン0になるわけではありません。

出典：データポータル ヘルプ「Google アナリティクスに接続する」、データポータル ヘルプ「データの更新速度を管理する」

直しても当たるとき：自分のレポートで数えてから決める

自分のレポートで何がトークンを使っているかは、データポータルのダイアログで見られます。レポートを編集モードで開き、キャンバスを右クリックして［Google アナリティクス トークンの使用状況］を選ぶと、そのセッションでレポート全体または今のページが使ったトークン、上限までの残り、グラフごとの量（多い順）が出ます。グラフを右クリックすると、そのグラフの問い合わせごとのトークン、完了の時刻、GA4 から直接読んだかメモリから読んだかが出ます。当社はこのダイアログでは測っていませんが、今回の数字と同じトークンの単位で、自分のレポートのどのグラフが重いかを並べられます。

見積もりは、ダイアログで見た「1ページ1回分のトークン」に、1時間あたりの表示回数を掛けて、1時間 14,000（プロジェクトとプロパティの組ごと）と比べます。上の割り当ての節のとおり、3つ以上のプロジェクトから読まない限り、40,000 より先にこちらが尽きるためです。計算の例として、当社のプロパティで測った1ページ4トークンをそのまま使うと、1時間に 3,500 回の表示で 14,000 になります。重くした形のグラフ（8トークン）が4つ並ぶページなら 32 トークンで、1時間に 437.5 回、つまり 438 回目の表示で超える計算です。データポータルが1つのグラフを1本のリクエストで取るかどうか、データポータルの問い合わせがどのプロジェクトとして数えられるかは確かめていないので、これは仮定を置いた計算です。閲覧者の認証情報でキャッシュが共有されない場合は、同じ表示でも見る人の数だけ問い合わせが増えると考えられます。

今回の測定で確かめていないことも挙げておきます。トークンの数はデータポータルの画面ではなく Data API で測った値で（42本、合計 100 トークン）、データ量やイベント数の多いプロパティでは同じ形でも増えることがあります。割り当ての上限・エラーの文言・解決手順は、2026年10月15日に公式のドキュメントで確かめたものです。割り当てを使い切ってエラーを出すことはしておらず、エラーの文言は公式の原文だけです。同時リクエストの上限（10）に当てる試しもしていません（1本ずつ、間をあけて投げました）。複数の Google Cloud プロジェクトから同じプロパティを読む場合の分け方、データポータルの GA4 のリクエストがどのプロジェクトとして数えられるか、カスタム ディメンションや、年齢・性別などしきい値の対象になるディメンションを使った場合、アナリティクス 360 のプロパティでの値も、今回の範囲の外です。

まず、エラーが出たページをデータポータルの編集モードで開き、キャンバスを右クリックして［Google アナリティクス トークンの使用状況］でトークンの多い順に上の3つのグラフを書き出し、それぞれのグラフを右クリックして、赤い X（GA4 に直接）か緑のチェック（メモリ）かも見てください。そのうえで、データソースの認証情報を確かめ、重いグラフのディメンションと期間を見直すのが、公式の解決手順にも今回の測定にも沿った始め方です。

当社は、GA4 の計測の設計から、データポータルのレポートを割り当てや料金の見通しが立つ形で組むところまでをマーケティングデータの支援で手伝っています。