Looker StudioのGA4レポートに(other)が表示される原因と消し方｜行数上限の回避設計

この記事のポイント

• Looker StudioのGA4レポートに出る(other)行はバグではなく、GA4 Data APIの行数上限（カーディナリティ超過）による仕様である
• 高カーディナリティディメンション（ページパス・ID系）と長期間指定の組み合わせが(other)を誘発する主因
• 即効性が高い順に、期間短縮・フィルタ・ディメンション削減・計算フィールドでの丸め・データ抽出・BigQuery移行の7手を試すのが定石
• 月次の定型レポートならレポート設計の見直しで足りるが、全量分析が必要ならBigQuery移行を検討すべき

月次レポートの締切前日、Looker StudioでGA4のページパス別アクセスをグラフ化しようとしたら、上位数件の下に「(other)」という謎の行が大量のセッションを抱えたまま鎮座している——このパターンでつまずく運用者は少なくありません。フィルタをかけ直しても、コネクタを再接続しても消えないので、「Looker Studioの表示バグでは」と疑いたくなる気持ちはよくわかります。

結論から言うと、これはLooker Studio側の不具合ではありません。GA4（Googleアナリティクス4）が裏側で持つデータの行数上限を超えたときに起きる、仕様としての挙動です。原因が分かればやることは明確で、期間を絞る、ディメンションを減らす、計算フィールドで値を丸める、データ抽出（Extract Data）を使う、最終的にBigQueryに逃がす、という順番で対処すれば当日中に報告資料は作れます。

この記事では、なぜLooker StudioでGA4の(other)が出るのかを構造的に説明したうえで、即効性の高い順に7つの対処法を並べ、月次レポート運用と全量分析のどちらを目指すかで選ぶべき手が変わることまで判断フローとして示します。読み終える頃には、自分のレポートにどの対処が合うか判断できる状態になっているはずです。

Looker StudioのGA4レポートに(other)が表示されるのはなぜ？

Looker StudioのGA4レポートに(other)が出るのは、GA4のカーディナリティ（ディメンション値の種類数）が内部処理テーブルの行数上限を超え、少数派の値がまとめられるためです。Looker Studio自体は集計結果を表示しているだけで、集計処理そのものはGA4側で先に完了しています。

(other)行の正体はGA4 Data APIの行数上限

カーディナリティとは、あるディメンションが取りうるユニークな値の種類数を指す言葉です。ページパスであれば「/」「/about」「/contact」といったURLの種類数がそのままカーディナリティになります。Looker StudioはGA4のネイティブコネクタを通じてGoogle Analytics Data APIというインターフェースにリクエストを送り、集計済みのレポートデータを取得しますが、このAPIが参照する内部テーブルには行数の上限があります。

Online Metricsのブログ記事では、高カーディナリティの目安として1日あたり500を超えるユニーク値を挙げ、Data APIが参照する日次テーブルの行上限は多くの場合5万行程度だと説明されています。日本市場でも考え方はそのまま当てはまり、ページパスにIDやクエリパラメータが混ざるサイトほど、この上限に早く到達しやすいと捉えておくとよいでしょう。上限を超えた分の行は個別に返せなくなり、「その他大勢」として(other)に集約されます。

GA4のデータは3層構造：UI表示・内部処理テーブル・生データ

GA4のデータ構造は、UIに見える表示テーブル、その手前にある内部処理テーブル、そして元になる生イベントデータという3層で捉えると挙動が理解しやすくなります。Optimize Smartのブログでは、GA4のデータが「UI表示テーブル→内部処理テーブル→生イベントデータ」という3層構造になっており、(other)は中間層である内部処理テーブルの行数上限で発生すると整理されています。

この整理が優れているのは、「なぜGA4の標準レポートだけでなくLooker Studioでも(other)が出るのか」を一言で説明できる点です。Looker Studioが接続するData APIは中間層を参照するため、GA4標準レポートと同じ制約を受けます。一方、探索レポートやBigQueryは生データに近い層を直接参照するため、(other)という概念自体が存在しません。この違いを押さえておくと、後述する対処法の優先順位も理解しやすくなります。

Looker Studio側の設定ミスではないと判断できる理由

コネクタの再接続や表の再作成をしても(other)が消えないなら、それはLooker Studio側の設定ではなく、GA4からLooker Studioに渡されるデータそのものに(other)が含まれている証拠です。Looker Studioはあくまで受け取った集計結果を表やグラフに変換しているだけで、集計のロジックには関与していません。したがって、キャッシュのクリアやフィルタの調整だけで直そうとするのは的外れな対応になりがちです。実務でつまずきやすいのはまさにこの点で、「Looker Studio側の不具合」という前提で調査時間を浪費してしまうケースです。原因はGA4側の行数上限にあると早めに見切りをつけることが、次の対処に進む近道になります。

(other)が出やすいレポートの条件は？原因を切り分ける

(other)が出やすいレポートには共通の傾向があり、高カーディナリティディメンションの有無、期間の長さ、データブレンドやピボットの使用状況を確認すれば、自分のレポートのどこが上限を圧迫しているか診断できます。

高カーディナリティディメンション（ページパス・ID系）が入っていないか

ページパス、ランディングページ、検索キーワード、トランザクションIDのようなディメンションは値の種類数が多く、真っ先に(other)を誘発します。特にECサイトの商品詳細ページのように末尾にIDが付くURL構造や、パラメータ付きURLをそのままページパスとして扱っているサイトは、同じページでも表記ゆれで別カウントされ、実質的なカーディナリティが跳ね上がりがちです。

チェックの目安として、次のような組み合わせが入っていないか確認してください。

ディメンション例	カーディナリティの傾向	(other)への影響
ページパス＋クエリ文字列	非常に高い	大きい
ページパスのみ（クエリ除外）	中程度	中程度
ページタイトル	中程度	中程度
デバイスカテゴリ	低い	ほぼなし
参照元/メディア	低〜中程度	小さい

期間の長さ×ディメンション数の掛け算で行数は膨らむ

行数は単純にディメンションの種類数だけで決まるわけではなく、期間の長さとの掛け算で膨らんでいきます。1日単位では上限内に収まっていても、90日分をまとめて集計すると、日ごとに現れる細かなページパスの組み合わせが積み上がり、あっという間に上限を超えてしまいます。

さらに、ディメンションを2つ以上組み合わせたレポート（ページパス×デバイスカテゴリ、など）では、それぞれのユニーク値の掛け合わせ分だけ行が増えるため、単一ディメンションのときより上限に達するスピードが速くなります。月次レポートで直近1年分を1つの表にまとめようとすると、この掛け算の効果で(other)が出やすくなるのは典型的なパターンです。

データブレンド・ピボットテーブルが上限を圧迫するケース

データブレンドやピボットテーブルを使うと、複数のディメンションを組み合わせた集計をLooker Studio側で行うことになり、単純な表よりも内部的に扱う行数が増えます。特にピボットテーブルで行・列の両方にディメンションを配置すると、組み合わせの数だけ集計対象が広がるため、単一のディメンションだけの表では出なかった(other)が急に現れることがあります。データブレンドで複数のGA4データソースを結合している場合も同様で、結合キーの種類数がそのままカーディナリティに直結します。レポートを作り込むほど(other)が出やすくなるという逆説的な現象は、この仕組みを知らないと原因不明のトラブルとして扱われがちです。

Looker Studioの(other)を消す方法7つ【即効性順】

(other)への対処は、期間短縮のような設定変更だけで済むものから、BigQuery移行のようなインフラ変更を伴うものまで工数の幅が広く、即効性が高い順に試すのが効率的です。ここでは7つの対処法を、手を付けやすい順に並べます。

期間を絞る・フィルタで対象を限定する

最も即効性が高いのは、レポートの期間を短くすることです。90日を30日に、1年分を四半期ごとに分割するだけで、集計対象の行数は大きく減ります。あわせて、除外したいディレクトリやパラメータをフィルタで先に除外しておけば、そもそも上限に達する前に不要な行を減らせます。手順としては、対象のグラフや表を選択し、右側パネルの「フィルタ」から日付範囲コントロールを追加するか、既存のフィルタ条件にパスのプレフィックス指定を加える形になります。工数はほぼゼロに近く、まず試すべき一手です。

ディメンション数を減らしレポートを分割する

1枚の表に複数の高カーディナリティディメンションを詰め込んでいる場合は、ディメンションを1つに絞り、代わりにレポートページを分割するアプローチが有効です。「ページパス×デバイスカテゴリ×参照元」のような3軸構成の表を、「ページパス別」「デバイス別」「参照元別」の3つの表に分けるだけで、それぞれの表が扱うカーディナリティは大幅に下がります。見た目の情報量は変わらず、上限だけを回避できるため、月次の定型レポートでは特に採用しやすい手です。

計算フィールドでページパスを丸めてカーディナリティを下げる

Semetisの記事では、(other)への対処を「スコープを狭める（期間・フィルタ）」「計算フィールドでディメンション値を粗いカテゴリに丸める」「BigQueryに移行する」の3系統に整理しており、特に計算フィールドでページパスを丸める発想は日本語の解説記事ではあまり見かけません。

具体的には、Looker Studioの計算フィールド機能でREGEXP_REPLACE関数を使い、/products/12345のようなIDつきパスを/products/*という共通カテゴリに丸めてしまう方法です。手順は次のとおりです。

1. データソースの編集画面を開き、「フィールドを追加」から計算フィールドを新規作成する
2. REGEXP_REPLACE(ページパス, "/products/[0-9]+", "/products/*")のような式で、末尾のID部分を固定文字列に置換する
3. 元のページパスの代わりに、この計算フィールドをディメンションとしてグラフや表に設定する

この方法のメリットは、BigQueryのような追加インフラを用意しなくても、レポート側の工夫だけでカーディナリティ自体を下げられる点です。商品詳細ページが多いECサイトや、予約番号つきの完了ページを持つサイトとは特に相性がよく、URL構造をカテゴリレベルで丸めるだけで(other)がほぼ解消するケースは珍しくないと言われています。

データ抽出（Extract Data）で事前集計する

Looker Studioのデータ抽出（Extract Data）は、必要なディメンションと指標だけを事前に集計してLooker Studio内にキャッシュとして保持する機能です。ライブ接続では毎回GA4 Data APIにフルクエリを投げるのに対し、データ抽出は一度事前集計を済ませておくため、同じ上限に達しにくくなるうえ表示速度も向上します。手順は、データソース一覧から「データを抽出」を選び、必要なディメンション・指標・期間を指定して抽出テーブルを作成し、既存のグラフのデータソースをこの抽出済みテーブルに差し替える流れです。ただし抽出データは手動または設定した頻度でしか更新されないため、リアルタイム性が求められるレポートには向きません。

BigQueryコネクタに切り替える

根本的に(other)をなくしたいなら、GA4のBigQueryエクスポート機能を使い、Looker StudioのデータソースをGA4ネイティブコネクタからBigQueryコネクタに切り替える方法が最も確実です。Analytics Canvasのブログでは、(other)の根本解はBigQueryエクスポート一択であり、BigQueryにはそもそも(other)行という概念が存在しないと述べられています。BigQueryは生のイベントデータをそのままテーブルとして持つため、Data APIの中間層を経由しないからです。

この方法の詳細な導入判断については、GA4×BigQuery連携の導入判断ガイドで個別に解説しているので、コスト感やSQLの学習コストを含めて検討したい場合はあわせて確認してください。

どの対処法を選ぶべきか？運用レベル別の判断フロー

(other)への対処は、月次の定型レポートを回したいだけなのか、全量・明細レベルの分析が必要なのかで、どこまで投資すべきかが変わります。

月次の定型レポートなら：レポート設計の見直しで足りる

決まったKPIを月次で報告する運用であれば、前章で紹介した期間短縮・フィルタ・ディメンション削減・計算フィールドでの丸めの4つで、多くの場合は十分に対応できます。これらはすべてLooker Studio内の設定変更で完結し、追加のインフラ費用や学習コストが発生しません。判断の目安としては、「知りたい粒度がカテゴリレベルで足りるか」を自問することです。個別ページのアクセス数まで追う必要がなく、カテゴリ単位の傾向が分かれば報告として成立するなら、BigQueryまで踏み込む必要はないと考えてよいでしょう。

全量・明細分析が必要なら：BigQuery移行を検討する基準

一方で、個別の商品ページやユーザー単位の行動を1件も欠かさず追いたい、あるいはSQLで柔軟に集計し直したいというニーズがあるなら、BigQuery移行を検討すべきタイミングです。判断基準としては、「(other)に含まれる行を個別に見たいか」「複数のディメンションを自由に掛け合わせて分析したいか」の2点が挙げられます。どちらかにイエスと答えるなら、レポート設計の工夫だけでは限界があり、生データにアクセスできるBigQueryへの移行が現実的な選択肢になります。ただし、SQLの学習コストやBigQueryの利用料金が発生する点は考慮material事項として押さえておく必要があります。

API経由の回避策は割り当て超過という別の壁に注意

(other)を避けようとしてAPI経由の呼び出し頻度を増やしたり、データ抽出の更新を細かくしすぎたりすると、今度はGA4 Data APIのクォータ（割り当て）を使い切ってしまうという別の問題に当たることがあります。Analytics Canvasの記事でも、API経由でダッシュボードにデータを流す回避策はGA4 APIのクォータに阻まれる可能性があると指摘されており、(other)対策とクォータ管理はセットで考える必要があります。

この2つは原因の構造がよく似ており、どちらも「GA4側のリソース上限に引っかかる」という点で共通しています。Looker Studioの「割り当て超過」エラーの原因と対処で詳しく扱っているので、対処を進める中でエラーが出た場合は参照してください。

そもそもGA4側で(other)を発生させない予防設計

(other)を都度対処するのではなく、GA4の設計段階でカーディナリティが上がらないようにしておけば、Looker Studio側での作業自体が減ります。

ID系・タイムスタンプ系をカスタムディメンション登録しない

Online Metricsのブログでは、イベントID・タイムスタンプ・ユーザーID系のパラメータをカスタムディメンションとして登録すると、プロパティ全体のレポートに(other)が波及すると警告されています。これは、1つのカスタムディメンションが極端に高いカーディナリティを持つと、そのプロパティ内の他のレポートまで巻き込んで上限を圧迫しうるという因果です。日本の実務でも同様の設計ミスは起こりやすく、トラブルシューティング用に一時的に登録したIDパラメータを、そのまま本番のカスタムディメンションとして残してしまうケースは典型的な失敗パターンと言えます。カスタムディメンションを追加する際は、そのパラメータが1日あたりどれくらいのユニーク値を持ちうるかを事前に見積もっておくことをおすすめします。

カスタムディメインション設計そのものの詳しい対処は、GA4管理画面側で(other)が表示される原因と対処で扱っているので、GA4の管理画面上で(other)を見かけている場合はそちらもあわせて確認してください。

URLパラメータの整理でページ系ディメンションの基数を抑える

ページパスのカーディナリティを抑えるもう一つの有効な手は、GA4側でURLパラメータを整理し、トラッキングに不要なクエリパラメータを除外する設定を行うことです。GA4の管理画面には、特定のクエリパラメータをページパスから除外する設定があり、これを使えば?utm_source=や?sessionid=のようなパラメータがページパスに混入するのを防げます。この設定を先に済ませておくと、Looker Studio側で計算フィールドによる丸め処理をしなくても、そもそものカーディナリティが低く保たれます。URL設計の段階でパラメータの整理ルールを決めておくことは、(other)対策であると同時に、レポート全体の見やすさにも寄与する予防投資だと言えるでしょう。

よくある質問

Q：GA4の(other)行とは何ですか？なぜ表示されるのですか？ GA4の(other)行とは、レポートの行数が内部処理テーブルの上限を超えた際に、上限からあふれた少数派の値がまとめて表示される仕様上の行を指します。原因はディメンションのカーディナリティ（ユニーク値の種類数）が上限を超えたことにあり、Looker Studioやレポート表示側の不具合ではありません。

Q：GA4の探索レポートなら(other)は表示されませんか？ 探索レポートは生データに近い層を参照するため、(other)という行自体は出ません。ただし、代わりにサンプリングが発生することがあり、精度とのトレードオフになる点には注意が必要です。標準レポートと探索レポートで数値が食い違って見える場合は、GA4の標準レポートと探索レポートで数値が合わない原因で仕組みを解説しています。

Q：BigQueryを使えば(other)は完全になくなりますか？ BigQueryのエクスポートデータには(other)という行は存在せず、生のイベントデータをそのまま集計できます。ただし、SQLの記述やBigQueryコネクタの設定を学ぶコストが発生するほか、データ量に応じた利用料金がかかる点は事前に考慮しておく必要があります。

Q：Looker Studioの「割り当て超過」エラーと(other)は関係ありますか？ 直接の原因は異なり、割り当て超過はGA4 Data APIのクォータ（呼び出し回数や処理量の上限）に起因し、(other)は行数上限に起因します。ただし、どちらも「GA4側のリソース上限を超える」という構造は共通しているため、(other)対策でAPI呼び出しを増やすと割り当て超過に触れやすくなる点は覚えておくとよいでしょう。

Q：GA4 360（有料版）にすれば(other)は解決しますか？ GA4 360では行の上限が最大200万行まで拡張されるため、無料版に比べて(other)が出にくくなるのは事実です。ただし、中小規模のアカウントであれば、有料版への切り替えよりも先に、本記事で紹介したレポート設計の見直しで解決できるケースの方が多いと考えられます。

---

Looker StudioのGA4レポートに(other)が出る仕組みと対処の考え方は以上です。どの対処法を選ぶべきかは、レポートの目的や運用体制によって変わってきます。真策堂では、広告運用やアクセス解析のレポーティング設計についてこうした観点からのご相談を受けています。GA4とLooker Studioの連携そのものについてはLooker StudioとGA4連携で出来ること・出来ないことでも整理していますので、あわせてご参照ください。