LookMLで実装する「動的フィルタリング」完全ガイド

はじめに

どうも、ざきです！今日はLookerであまり解説されていない 「動的フィルタリング」 の実装方法について解説します。

Lookerにおける「動的フィルタリング」は、単なるUIの便利機能ではなく、 「SQL生成プロセスのどこを動かすか」 という設計問題です。ここを誤ると、以下のような典型的なBI負債に繋がります。

• ダッシュボードが用途別に増殖する
• LookMLが分岐だらけになり、可読性が低下する
• 「直せないから複製する」という力技の運用に陥る

この記事では「動的にできるかどうか」ではなく、 「どのレイヤーを動かすのが設計として妥当か」 という観点で、Lookerの動的フィルタリングを整理します。

記事の対象者

• LookMLの設計に自信がない初学者の方
• 「フィルタを動的に切り替えたい」という要望に直面している人
• LookMLのViewやModelの肥大化に課題を感じている人
• Looker StudioやTableauとの設計思想の違いで詰まった人
• 冗長なダッシュボードのメンテナンスコストを減らしたい人

Lookerにおける「動的フィルタリング」とは何か

1.1 よくある誤解

• フィルタはUI側だけで完結するもの
• ダッシュボードフィルタ = 単なるSQLの WHERE 句
• Lookerなら何でも簡単に動的に切り替えられる

これらは 半分正しくて、半分間違い です。
なぜならLookerの本体はUIではなく、**「LookML → SQLへのコンパイル」**だからです。UI操作はあくまでトリガーであり、実際に変わるのは「生成されるSQL」そのものです。

---

1.2 Looker の設計思想

Lookerは モデル駆動（LookML） です。
ユーザーがダッシュボードで操作を行ってからデータが表示されるまで、以下のプロセスを辿ります。

つまり「動的」とは、このプロセスの 2番と3番（SQLを生成する前）に介入して、SQLの構造を書き換えること を指します。UI操作はあくまでトリガーであり、本体はLookMLによるSQLの制御なのです。

動的フィルタリングの分類

実装方法を5段階で分類しました。番号が若いほど安全で標準的、下に行くほど柔軟な反面、取り扱い（メンテナンス）が難しくなります。

パターン	主な用途	主役となる機能	柔軟性
1.静的フィルタ	単純な条件指定	filter	低
2.UI連動	ユーザーによる絞り込み	dashboard filter	低
3.条件分岐 (quoted)	値に基づくロジック切替	parameter	中
4.条件分岐 (unquoted)	SQL構文レベルの制御	parameter (unquoted)	高
5.SQL直接制御	複雑な列・条件の切替	Liquid	高

「動的フィルタを実装したいが、どの方法がベストか？」と迷ったときは、以下のフローに沿って判断してください。

これだけだとイメージがしづらい部分もあるので、各段階ごとにそれぞれ解説をしていきます。

---

1.静的フィルタ（filter）

目的と解決できること

日付やステータスなど、特定の項目に対してユーザーが任意の値でデータを絞り込めるようにしたい場合に使用します。LookMLにおいて最も標準的なフィルタリングの実装です。

主な利用シーン

• 注文日を指定して、特定の期間のデータに絞り込みたい
• 注文ステータスを completed（完了済み）のみに限定して分析したい

# ユーザーが値を入力するためのフィルタを定義
filter: order_date {
  label: "注文日指定"
  type: date
}

# フィルタで受け取った条件をWHERE句に反映させる記述
dimension: is_in_period {
  type: yesno
  sql: {% condition order_date %} ${TABLE}.order_date {% endcondition %} ;;
}

動作の仕組み

ユーザーがダッシュボードやExploreで日付を選択すると、Lookerがその値を解釈し、SQL生成時に WHERE order_date BETWEEN ... といった条件句を自動的に構成します。

導入の判断基準

フィルタリングの第一選択肢として検討してください。
表示する列（カラム）や計算ロジック自体を動的に切り替える必要がないのであれば、
この方法が最もシンプルで、長期的なメンテナンスコストも低く抑えられます。

---

2.UI連動（dashboard filter）

目的と解決できること

LookMLを編集することなく、ダッシュボード上の操作だけで表示データを一括制御したい場合に使用します。複数のチャート（タイル）に対して、共通の切り口でフィルターをかけられるLookerの最も一般的なインターフェースです。

主な利用シーン

• 「事業部セレクター」を設置し、ダッシュボード全体の数字を一括で切り替えたい
• 「地域」や「カテゴリ」を選択して、関連するすべてのグラフを連動させたい

動作の仕組み

ユーザーがUI上で値を操作すると、Lookerが自動的に各タイルのクエリへ WHERE 句を追加します。LookML側に特別なロジックを書き込む必要がなく、GUI上で設定が完結するのが特徴です。

導入の判断基準

ダッシュボード利用者（非エンジニア）向けの操作性を優先したい場合の最適解です。
ただし、あくまで「データの絞り込み」が目的であり、「計算ロジックそのものの切り替え」には向いていません。より複雑な制御が必要な場合は、次に紹介する parameter の出番となります。

---

3.条件分岐（parameter/quoted）

目的と解決できること

ユーザーが選択した項目に応じて、計算ロジック（CASE文など）を動的に切り替えたい場合に使用します。1つのグラフで複数の指標を切り替えて表示できるため、ダッシュボードの枚数を削減するのに非常に有効です。

主な利用シーン

• 1つのグラフで「売上額」と「注文数」を切り替えて表示したい
• 集計単位を「合計（SUM）」と「平均（AVG）」でユーザーに選ばせたい

parameter: metric_type {
  label: "表示指標を選択"
  type: string
  allowed_value: { label: "売上額" value: "sales" }
  allowed_value: { label: "注文数" value: "count" }
}

measure: dynamic_metric {
  label_from_parameter: metric_type
  type: number
  sql: 
    CASE
      WHEN {% parameter metric_type %} = 'sales' THEN ${sales_amount}
      WHEN {% parameter metric_type %} = 'count' THEN ${order_count}
      ELSE NULL
    END ;;
}

{% parameter %} は自動的にシングルクォートで囲まれた値を返します（例: 'sales' = 'sales'）

動作の仕組み

ユーザーが選択した値が「文字列（quoted）」としてSQL内に埋め込まれます。LookerはそれをもとにSQLの CASE WHEN 文を実行し、条件に合致する方のロジックを採用します。

導入の判断基準

ロジックの切り替えが必要な際の第一候補です。
生成されるSQLが標準的なCASE文になるため、可読性が高くデバッグも容易です。

---

4.条件分岐（parameter/unquoted）

目的と解決できること

SQLの構文そのもの（参照する列名やテーブル名など）を直接書き換えたい場合に使用します。quotedとの最大の違いは、値としてではなく、SQLのパーツとして展開される点にあります。

主な利用シーン

• 参照するカラム自体（sales_amount か profit_amount か）を動的に差し替えたい
• 大規模データにおいて、CASE文を通すことによるパフォーマンス低下を避けたい

parameter: column_selector {
  label: "集計対象の列を選択"
  type: unquoted
  allowed_value: { label: "売上金額" value: "sales_amount" }
  allowed_value: { label: "利益金額" value: "profit_amount" }
}

dimension: dynamic_column {
  label_from_parameter: column_selector
  type: number
  # 選択された値がそのまま「列名」として展開される
  sql: ${TABLE}.{% parameter column_selector %} ;;
}

動作の仕組み

UIでの選択内容が「引用符なし（unquoted）」でSQLに直接パッチされます。

1. UIで「売上金額」を選択した場合、Looker内部で以下のようにSQLが組み立てられます。

# 生成されるSQLイメージ
SELECT
    orders.sales_amount AS dynamic_column -- そのまま列名として注入される
FROM orders

2. UIで「利益金額」を選択した場合、パラメータのvalueに指定した文字列が、そのままSQLのパーツになります。

# 生成されるSQLイメージ
SELECT
    orders.profit_amount AS dynamic_column -- 構文そのものが書き換わる
FROM orders

導入の判断基準

CASE文では対応できない「構造の変更」が必要な場合にのみ使用してください。
非常に強力ですが、データウェアハウスによっては大文字小文字の区別に注意が必要です。また、SQLインジェクションのようなリスクを避けるため、allowed_value で選択肢を限定して使うのが鉄則です。

---

5.SQL制御（Liquid）

目的と解決できること

特定の条件（ユーザー属性や選択内容）によって、SQLの記述そのものを大幅に改変したい場合に使用します。Lookerにおける動的制御の「最終手段」です。

主な利用シーン

• 特定のフィルタが選ばれている時だけ、別のテーブルをJOINさせたい
• ログインユーザーの権限に応じて、参照するスキーマを動的に変えたい

dimension: dynamic_value {
  sql:
    # view_name は実際のView名に置き換える
    {% if view_name.metric_type._parameter_value == "sales" %}
      ${TABLE}.sales
    {% else %}
      ${TABLE}.order_count
    {% endif %} ;;
}

動作の仕組み

LookerがSQLをデータベースに投げる前の段階で、LiquidエンジンがSQLのテキスト自体を書き換えます。

導入の判断基準

他の方法ではどうしても実現できない複雑な要件がある場合のみ採用してください。
多用するとLookMLの解読が困難になるため、利用箇所には必ずコメントを残すなど、保守性を意識した設計が求められます。

最後に

今回はLookerの動的フィルタリングを分類して解説しました。
設計の段階で意識すべきは、 「可能な限りシンプルな方法（番号の若い順）を採用すること」 です。

それぞれのトレードオフを認識し、ユースケースに合わせて適切な実装を選択することで、LookMLのViewの肥大化やモデルの増殖を劇的に抑えることができます。
ぜひ、明日のLookML開発から意識してみてください！