Looker Studio（現 Data Studio）のエラーで困っていませんか？原因を突き止めて修正します

Looker Studio（Data Studio）のレポートでエラーが出る理由

グラフの下にある何かが変わったのに、Data Studio はコネクタが壊れても警告してくれないからです。グラフはただエラーや空白を表示するか、数値が静かにずれていきます。誰かが気づく頃には、レポートが何週間も間違っていたということがよくあります。

私が最もよく目にする原因を、おおよそ頻度の高い順に挙げます。

• 認証情報：データソースが、退職した、あるいはアクセス権を失ったアカウントのオーナーの認証情報を使っている。
• 割り当て上限：多くのグラフと閲覧者が 1 時間あたりのトークン枠を共有すると、GA4 のグラフが割り当て上限エラーで失敗する。
• ブレンド：命名の変更後に結合キーが一致しなくなり、行が黙って落ちている。
• 廃止されたフィールド：2026年5月4日に廃止された Google Ads の住所表示オプション関連のフィールドのように、コネクタがフィールドを削除した。
• スキーマの変更：Sheet やテーブルの列名が変更され、それを使っていたすべての計算フィールドが壊れた。
• サイズ：大きなクエリが「行数が多すぎます」エラーになるか、タイムアウトする。

Data Studio のデータソースの認証情報エラーをどう直すか

各データソースが誰の認証情報を使っているかを確認し、今後も残るアカウントに移します。オーナーの認証情報では、閲覧者はデータソースのオーナーのアクセス権を通じてデータを見ます。閲覧者の認証情報では、各閲覧者が元のデータへの自分自身のアクセス権を必要とします。どちらも正しい設定ですが、意図せず設定されるとどちらもエラーの原因になります。

典型的な失敗は、フリーランスや元社員が作ったレポートで、すべてのデータソースがその人の認証情報で動いているケースです。その人のアクセス権がなくなると、レポート全体が空白になります。私は所有権を共有アカウントやサービス用のアカウントに移し、各データソースを再認証し、一般的な閲覧者としてレポートをテストします。

レポートに構成エラーや壊れたブレンドが表示されるのはなぜか

構成エラーは通常、グラフが参照しているフィールド、指標、ディメンションがもう存在しないか、互換性がなくなったことを意味します。コネクタの更新後、誰かが Sheet の列名を変えた後、あるいは計算フィールドが削除された別のフィールドに依存しているときに現れます。

ブレンドはもっとわかりにくい壊れ方をします。ブレンドは等価結合で最大 5 つのデータソースを結合するため、末尾の空白、キャンペーンの命名規則の変更、形式の異なる日付があると、行が一致しなくなります。グラフは読み込まれますが、合計が小さくなるだけです。私はブレンドした合計を各データソース単体と比較して行が失われている場所を見つけ、キーを修正するか、結合を確認しやすい Google Sheets や BigQuery に移します。

Data Studio のレポートが遅いのはなぜか

遅いレポートは、たいてい重いクエリを一度に送りすぎています。何十ものグラフが並ぶ長いページ、幅の広い表、多数のブレンド、長い期間にわたる GA4 のライブクエリが積み重なります。

修理は実践的です。ページを分割し、使われていないグラフを削除し、大きな表のディメンションを減らし、遅い過去データを抽出データに置き換え、最も重いデータソースは BigQuery で事前集計します。GA4 や Google Ads のような固定スキーマのデータソースでは表がディメンション 10 個・指標 20 個までなので、それを超えて設計した表はまともに動きません。

レポートの数字が元データと合わない場合は

そうでないと判明するまでは、定義の問題として扱います。レポートと GA4、Google Ads、CRM の差は、たいてい期間、タイムゾーン、データソースのフィルタ、異なるコンバージョンの列、あるいは比率を再計算せずに合計している計算フィールドから生じます。

私は指標を 1 つずつ元データと照合し、それぞれの差を文書化し、誤りであるものを修正します。GA4 のキーイベントと CRM のリードのように正当な差もあり、それらは修正するのではなく、ページ上にラベルを付けます。

私が Greenwolf Tech Labs で主導した製造ダッシュボードは、これがなぜ重要かを示すよい例です。生産数とロス数、機械ごとのロス数、機械ごとの生産性、オペレーターの稼働状況、ロスの要因、保守コストを追跡しています。こうした数字が保全の判断に使われるとき、定義の誤りは見た目の問題では済みません。

レポートを修理すべきか、作り直すべきか

構造が健全で、問題が特定の箇所にあるなら修理します。修理なら既存の URL、ブックマーク、スケジュール配信が残り、チームがレイアウトを覚え直す必要もありません。

ロジックがドキュメントなしに何十ものレポートレベルの計算フィールドにコピーされているとき、すべてのページが割り当て上限と格闘しているとき、あるいはもう誰も尋ねない問いに答えているレポートのときは、作り直します。どちらに当てはまるかは、監査の後、どちらの費用もお支払いいただく前にお伝えします。MySQL 5.6 と 5.7 のサポートが 2027年2月26日までに終了するなど、今後の廃止予定も、レポートがそれらのデータベースを使っているなら今のうちに確認する価値があります。