Looker Studio初心者に贈る「これだけは絶対するな」

Looker Studioは触ればすぐグラフが出ます。そこが良いところで、そこが落とし穴でもあります。とりあえず作ったダッシュボードは、半年後に誰も直せなくなります。

作り始める前に避けておくべきことを並べます。どれも、後から直すのに何倍も手間がかかるものです。

1. 生のテーブルを直接つながない

もっとも多い失敗です。BigQueryのテーブルをそのままデータソースにすると、次の問題が起きます。

• 元のテーブルの列名が変わると、全部のグラフが壊れます
• 表示するたびに全期間をスキャンし、課金額が膨らみます
• 同じ集計ロジックを、グラフごとに何度も書くことになります

代わりにやること

集計済みのビューかテーブルを1つ作り、それをつなぎます。

[生データ]
   ↓  日次で集計
[レポート用のテーブル/ビュー]   ← Looker Studio はここだけを見る
   ↓
[ダッシュボード]

この1枚を挟むだけで、元のテーブル構成が変わってもダッシュボードは無事で済みます。ロジックの修正もSQL側の1箇所になります。

2. カスタムクエリをグラフに直接書かない

Looker Studioには「カスタムクエリ」でSQLを書き込める機能があります。便利ですが、ダッシュボードの中にSQLが埋まります。

• 誰が何を書いたか分からなくなります
• 同じようなSQLがダッシュボードの数だけ増えます
• バージョン管理ができません

代わりにやること

SQLはデータベース側にビューとして置きます。Looker Studioからはビューを参照します。SQLの履歴はデータベース側で管理できます。

暫定的にカスタムクエリを使う場合は、先頭にコメントで目的と作成日を書きます。

3. 計算フィールドに全角文字を混ぜない

これは実際によく踏みます。計算フィールドやSQLのエイリアスに全角の英数字・記号・スペースが混ざると、原因が分かりにくい構文エラーになります。

見た目では全角と半角の区別がつかないため、探すのに時間がかかります。

代わりにやること

日本語を使いたいのは「表示名」の側です。内部の名前は半角で統一します。

4. 日付を文字列のまま扱わない

20250716 や 2025/07/16 のような文字列を日付として使うと、期間フィルタも日付の比較も効きません。

代わりにやること

データソース側でDATE型に変換しておきます。Looker Studio側の変換でもできますが、元のデータで直したほうが後が楽です。

-- 例: 文字列を日付に直して持っておく
SELECT
  PARSE_DATE('%Y%m%d', order_date_str) AS order_date,
  ...

期間フィルタを付けるグラフは、参照している日付フィールドを1つに揃えます。グラフごとに違う日付を見ていると、数字が合わない原因になります。

5. 全期間を既定の表示期間にしない

既定の期間を「全期間」にすると、開くたびに全データを読みます。BigQueryは読んだ量で課金されるため、人が見るだけで費用が増えます。

代わりにやること

• 既定の期間は直近28日など短く設定します
• 長期の推移は、月次に集計したテーブルを別に用意してそこから見ます
• BigQuery側でパーティションを設定し、日付で絞れるようにします
• データソースの設定でキャッシュを有効にします

費用は最初は気になりません。テーブルが育ってから効いてきます。

6. グラフを先に作らない

空のキャンバスを前にすると、グラフから作り始めてしまいます。結果、見られない数字が並んだダッシュボードができます。

代わりにやること

紙かテキストで先に1枚書きます。

誰が見るか  : 営業部の週次会議
何を決めるか: 今週どの商材に人を寄せるか
見る数字    : 商材別の商談数（前週比）、受注率
判断の基準  : 前週比80%を下回ったら要因を確認する
更新頻度    : 毎週月曜の朝

「何を決めるためか」が書けない数字は載せません。 これだけでグラフの数が半分になります。

7. 1ページに詰め込まない

スクロールが必要なほど詰め込むと、結局誰も下まで見ません。

代わりにやること

1ページ目は画面1枚に収めます。会議で開いた瞬間に状況が分かる状態にします。

8. 前提を書かずに配らない

数字の問い合わせの大半は、前提が書かれていないことから来ます。

代わりにやること

ダッシュボードの片隅にテキストで注記を置きます。

集計基準: 注文日ベース
対象    : キャンセル・返品を除く
更新    : 毎日 6:00（前日分まで）
除外    : 社内IPからのアクセス
問い合わせ先: （担当部署）

これがあるだけで「この数字は何を含んでいるのか」という質問が減ります。作った本人は自明だと思っていますが、見る人には分かりません。

9. 共有範囲を確認せずにリンクを渡さない

Looker Studioの共有は、レポートの共有設定とデータソースの認証方法の2つで決まります。ここを理解せずに配ると、事故になります。

「所有者の認証情報」のままリンクを広く配ると、本来アクセス権のない人が中身を見られる状態になります。

代わりにやること

• 配る前に、データソースの認証方法を確認します
• リンクを知っている全員に公開する設定は避け、個別またはグループ単位で付与します
• 社外に見せる場合は、必要な列だけに絞った専用のビューを作ってつなぎます
• 個人情報を含む列は、ダッシュボード用のビューに入れません

見えないようにグラフから外すだけでは不十分です。データソースに含まれていれば、操作で取り出せます。

やりがちな失敗のまとめ

最初にやること

1. 目的と見る人を1枚書きます
2. 集計済みのビューを1つ作る（内部名は半角で統一）
3. 日付をDATE型にし、パーティションを設定します
4. 既定の期間を直近28日にします
5. 1ページ目に主要指標だけを置きます
6. 注記を書きます
7. 共有前に認証方法と共有範囲を確認します

この順でやると、あとから直す作業がほとんど発生しません。 逆の順でやると、半年後に作り直しになります。

まとめ

• Looker Studioの失敗は、作り方ではなく作り始め方にあります
• 生データに直接つながず、集計ビューを1枚挟みます
• 内部の名前は半角のみにします。全角は表示名だけ
• 既定の期間とパーティションで費用を抑えます
• グラフより先に目的を書きます
• 配る前に共有範囲とデータソースの認証方法を確認します

グラフはあとから何度でも足せます。土台の作り方だけは、最初に決めておきます。