2026.06.09 コラム
【Looker入門】最初につまずかないためのLooker設計のポイント
初心者が見落としがちな「設計」の重要性とは？
Lookerは、データ分析やダッシュボード作成を効率化できる便利なツールです。
近年では、データ活用の文脈でLookerに触れる機会も増えてきました。
一方で、実際に運用してみると、「正しい数値を反映できない」、「ダッシュボード間でデータに不一致がある」などの壁にあたり、「思ったより難しいな…」と感じるケースも少なくありません。
実際、Lookerは画面操作自体は比較的シンプルな一方で、その前段階である設計や考え方の部分でつまずくケースが多いツールです。
特に初心者のうちは、「どう作るべきか」が分からないまま進めてしまいがちです。
しかも、多少ズレた作り方をしていても、一見それっぽいダッシュボードは作れてしまいます。
その結果、
- ダッシュボード上の数値や分析結果を信頼できない
- 分析したい内容を十分に実現できない
- 利用者に活用されず、誰にも使われなくなる
といった問題が発生し、期待した成果を得られないケースも少なくありません。
この記事では、Looker初心者がハマりやすい落とし穴と、その回避ポイントを整理します。
よくある躓きと対処法
① 定義があいまいなまま、とりあえずグラフを作ってしまう
Looker初心者が最初にやってしまいがちなのが、「まずはグラフを作ってみよう」と進めてしまうことです。ただし、「売上」や「ユーザー数」といった指標の定義が曖昧なまま進めると、人によって解釈が異なる状態になりやすくなります。
たとえば「売上」だけでも、
- キャンセルを含むのか
- 税込 / 税抜どちらか
- 注文ベースか出荷ベースか
など、認識がズレるケースがあります。
しかも、多少ズレた状態でも一見それっぽいグラフは作れてしまうため、運用後に
「数字が合わない」、 「部署ごとに見ている値が違う」といった問題につながることもあります。
【対処法】
最初に、「この指標は何を意味するのか」を言語化しておくことが大切です。
たとえば、
- 売上の定義
- 除外条件
- 集計単位
などを事前に整理しておくだけでも、その後の認識ズレを防ぎやすくなります。
② 必要になったタイミングで都度指標を作ってしまう
Looker初心者が陥りがちなのが、Excelのように「必要になったらその場で計算を作る」という使い方です。
【起こりがちな実務上のフロー】
- 必要な指標（例: 粗利）がExplore上に存在しない
- 画面上の「表計算機能」で、その場限りのローカルな計算式を組み込む
- 別のダッシュボードでも同じ指標が必要になり、同様の計算式を個別に再作成する
- 指標の定義変更時（例: 原価に配送料を含める）、全ダッシュボードの手修正が必要に。
→ 修正漏れにより、レポート間で「数字の不一致」が発生する可能性
対処法
Lookerでは、指標を都度作るのではなく、「共通ルールとして定義し、全員で使い回す」という前提で設計することが重要です。
最初に定義を揃えておくだけでも、
- 数字のブレを防ぎやすい
- ダッシュボードを再利用しやすい
- 属人化しにくい
といったメリットがあります。
③ データ構造（テーブル）の設計を意識せずに進めてしまう
Lookerでよくある失敗が、元データの形を意識せず、「使えそうなデータを画面（Explore）で適当に結合してしまう」ことです。
データの「1行が何を表しているか」を無視して繋げてしまうと、Lookerの裏側でデータが掛け算されて増殖し、売上などの数字が2倍・3倍に膨れ上がるという現象が起きます。
具体例：「注文テーブル」と「注文詳細テーブル」の結合
- 注文テーブル（主）: 1つの注文（粒度：注文IDごと）
- 注文詳細テーブル: 注文された個別の商品（粒度：注文ID × 商品ごと）
もし、1つの注文（10,000円）に対して、商品が3つ購入されていたとします。 この2つのテーブルを単純に結合すると、結合後のデータは以下のようになります。
| 注文ID | 注文金額（主） | 購入商品（詳細） | 商品価格 |
|---|---|---|---|
| 001 | 10,000円 | りんご | 3,000円 |
| 001 | 10,000円 | みかん | 2,000円 |
| 001 | 10,000円 | ぶどう | 5,000円 |
この状態で、Lookerで「注文金額の合計（SUM）」を計算するとどうなるでしょうか？
Lookerはデータベースに対してSQLを発行するため、10,000円 × 3行 = 30,000円 という間違った集計結果（本来の3倍）を出力してしまいます。
対処法
データをどの単位（粒度）で扱うのか、どのテーブルを「主（ベース）」にするのかを事前に整理し、Lookerの機能で適切に制御する必要があります。
なぜ、理解していても実務では詰まるのか？
ここまで読むと、 「意外とシンプルじゃないか」と感じるかもしれません。
実際に概念だけならそこまで難しくありません。
では、なぜ実務で詰まってしまうのか？
その主な要因としては、「正しく決める」こと自体が難しいという根本的な課題にあります。
例えば「売上」という指標ひとつでも、
- どのテーブルを基準にするか
- 売上の計算式はどうなっているのか
- キャンセルの扱い
- 日付の定義（受注日 / 出荷日 など）
といった複数の判断が必要になります。
さらに重要なのは、一度決めた定義を変更すると、既存のダッシュボードや過去データにも影響が及ぶため、見直しに一定のコストがかかる点です。
最後に
Lookerは非常に強力なツールですが、成果は「設計の質」に大きく依存します。
ただし実際には、
- 指標が何を意味するのかを整理する
- データをどのような構造で扱うかを設計する
- どのルールでデータを使っていくかを決める
これらをすべて対応するのは、想像以上に難易度が高い領域です。
「とりあえず作る」か、「最初に設計する」かで、かかるコストとやり直しの有無は大きく変わります。
もし、
- 何から決めるべきか分からない
- 作り直しを避けたい
- 最初から実用的な状態で運用したい
といった場合は、構築前の設計整理から進めることをおすすめします。
DataCurrentでは、利用目的や現状課題、業務フローを踏まえ、実運用を見据えたダッシュボード設計・運用をご支援しています。
具体的なプランが決まっていなくても、ご相談ベースから対応可能です。
まずはお気軽にお問い合わせください。
本件に関するお問い合わせは下記にて承ります。
株式会社DataCurrent
info@datacurrent.co.jp