Looker Studioでデータが表示されない原因と対処6つ

結論：Looker Studioでデータが出ないのは「キャッシュ」「期間・フィルタ」「スキーマ」「認証」の4系統

Looker Studioでグラフが空になる、表が「データがありません（No data）」になる、赤い「データセットの設定エラー」が出る——症状は違って見えますが、原因はほぼ①キャッシュ（更新頻度）②期間設定とフィルタ ③データソース側の列名・スキーマ変更 ④認証情報と共有権限の4系統に収まります。

この4つは対処がまったく違います。キャッシュが原因なら「データを更新」を1回押すだけで直りますが、列名が変わっているときに何度更新しても直りません。まず切り分け、それから直す。順番を守るのが最短です。

まず30秒で切り分ける3つの質問

手を動かす前に、次の3つに答えてください。ここで原因の系統がほぼ決まります。

• 「データがありません」か、赤いエラーバナーか：前者は期間・フィルタ・キャッシュ側、後者はスキーマ・認証側の疑いが濃くなります。
• レポート全体か、特定のグラフ1つだけか：1つだけならそのコンポーネントのフィルタ・ディメンション設定、全体ならデータソースか認証です。
• 自分では見えるが、他の人だけ見えないか：これは100%データではなく権限側の話です（後述の手順5へ）。

原因別の対処6手順

1. 「データを更新」でキャッシュを手動リフレッシュする

Looker Studioはクエリと結果を一時的にメモリへ保存して表示を速くしています。つまり、元データを直した直後にレポートを開いても、設定された更新頻度に達するまでは古い結果が返ります。

Google公式ドキュメントによると、デフォルトの更新頻度はコネクタごとに異なります（データの更新頻度を管理する｜Looker Studio 公式ドキュメント）。

編集者は「その他」アイコンから「データを更新」を実行できます。ただし最後の更新から1分のクールダウンがあるため、連打しても意味はありません。1回押して直るならキャッシュが犯人で、それ以上の調査は不要です。

実務で多いのは、スプレッドシート連携なのに「12時間」に落としていたケースです。読み込みを軽くしようとして伸ばした設定が、そのまま「反映されない」というクレームの原因になります。日次で見るダッシュボードなら15分〜1時間に戻してください。

2. 期間設定とフィルタを疑う

「データがありません」の最頻出は、期間にデータが1行も無いだけです。次の順で確認します。

• レポート全体の期間：「過去7日間」で見ているのに、元データの更新が止まっていないか。
• コンポーネント個別の期間：グラフごとに期間を上書きしていると、レポート期間を変えても動きません。
• フィルタの掛け違い：完全一致（Equal to）で指定した値が、元データで表記ゆれしていると0件になります。全角スペース・末尾の空白が典型です。
• 日付ディメンションの型：スプレッドシートの日付列が文字列として読まれていると、期間フィルタが一切効きません。データソースの編集画面で型を「日付」に直します。

3. データソース側の列名・スキーマ変更を確認する

赤い「データセットの設定エラー」「基になるデータセットからデータを取得できませんでした」が出るときの筆頭容疑は、元のスプレッドシートで列名を変えた・列を消したことです。Looker Studioはスキーマの変更を自動では追随しないため、参照先を見失って落ちます。

直し方は2つです。（a）元データの列名を元に戻すか、（b）データソースの編集画面で「フィールドを更新（再接続）」して、新しい列にマッピングし直す。実務では(a)で一旦復旧させ、落ち着いてから(b)で正式に直すのが安全です。

再発防止としては、ダッシュボードが参照するシートを「生データ」と分け、見出し行を固定した中間シートを1枚挟むのが効きます。現場が生データの列名を触っても、中間シートの列名さえ守ればダッシュボードは壊れません。

4. 認証情報が「オーナー」か「閲覧者」かを確認する

データソースには、誰の資格情報でデータを取りに行くかの設定があります。オーナーの認証情報なら閲覧者はデータソースへのアクセス権が無くても数字を見られ、閲覧者の認証情報なら見る人それぞれが元データの権限を持っている必要があります。

「作った本人だけ見える」「共有した相手だけ空になる」という症状は、ほぼここです。社内共有のダッシュボードはオーナー認証、権限を厳密に分けたい場合は閲覧者認証、と用途で選び分けます。

5. 共有権限と組織のポリシーを確認する

レポートを共有していても、元データ（スプレッドシートやBigQuery）側の権限が無いと閲覧者認証では空になります。またGoogle公式ヘルプが説明しているとおり、職場や学校のアカウントでは組織外のユーザーとファイルを共有できない場合があり、公開ファイルにアクセスできるユーザーを管理者が制限できます（Google ドライブのファイルを共有する｜Google公式ヘルプ）。社外に共有したダッシュボードが相手側でだけ開かない場合は、まずここを疑ってください。

6. 行数・ブレンド・計算フィールドの限界を疑う

最後に、データ量そのものが原因のことがあります。数十万行のスプレッドシートを直結していると、タイムアウトして「データがありません」に見えることがあります。対処は元データを集計済みのサマリーシートに落としてから接続することです。ブレンド（結合）を何段も重ねている場合も同じで、結合は1段までに抑え、前処理はスプレッドシート側かBigQuery側で済ませます。

症状別の早見表

毎月ここで詰まるなら、直すべきは設定ではなく設計かもしれません

実務で本当に多いのは、「Looker Studioが悪い」のではなく、ダッシュボードが生の業務シートを直接見ていることです。現場が列を足す・並べ替える・行を挿入するたびに壊れるので、毎月同じ復旧作業が発生します。

この構造から抜けるには、入力（現場が触る場所）と集計（ダッシュボードが見る場所）を分けるしかありません。入力側を画面のあるアプリにして、集計側は触らせない形にすると、壊れる余地そのものが消えます。

私たちはスプレッドシートをそのまま社内アプリにするお仕事もしております。記事の途中で恐縮ですが、同じ復旧作業を毎月繰り返している方には役に立つと思いますので、よろしければ合わせてご覧いただけたら嬉しいです。

ダッシュボードの作り方そのものを見直したい場合はスプレッドシートでダッシュボードを作る方法を、元データ側のピボットが更新されない場合はピボットテーブルが更新されない原因を、保存自体が通らない場合は「変更内容を同期できません」を直す手順を先に確認してください。

まとめ：更新を1回押して直らなければ、キャッシュではない

Looker Studioの表示トラブルは、「データを更新」を1回押すだけで切り分けの半分が終わります。直ればキャッシュ、直らなければ期間・フィルタ・スキーマ・権限のどれかです。エラーバナーの色（赤か、ただの空か）で系統を分けてから動けば、原因探しの往復がぐっと減ります。