GSP934

概要

Looker は、Google Cloud 上で提供される最新のデータ プラットフォームです。データをインタラクティブに分析および可視化できるほか、詳細なデータ分析、複数のデータソースにまたがるインサイトの統合、実行可能なデータドリブン ワークフローの構築、さらにはカスタム データ アプリケーションの開発まで行うことができます。

このラボでは、Liquid パラメータとテンプレート フィルタを活用して Looker のユーザー インタラクティビティを向上させる方法を学びます。また、それらを用いて動的なディメンションやメジャーを作成する方法を実践します。

目標

このラボでは、次の方法について学びます。

• Liquid パラメータを使用して動的なディメンションを作成する
• テンプレート フィルタを使用して動的なディメンションを作成する
• テンプレート フィルタを使用して動的なメジャーを作成する

前提条件

LookML および Liquid に関する基礎知識が必要です。本ラボを開始する前に、「Liquid を使用して Looker のユーザー エクスペリエンスをカスタマイズする」ラボを修了しておくことをおすすめします。

セットアップ

[ラボを開始] ボタンをクリックする前に

こちらの説明をお読みください。ラボの時間は制限されており、一時停止することはできません。タイマーは、Google Cloud のリソースを利用できる時間を示しており、[ラボを開始] をクリックするとスタートします。

このハンズオンラボでは、シミュレーションやデモ環境ではなく、実際のクラウド環境を使ってご自身でラボのアクティビティを行うことができます。そのため、ラボの受講中に Google Cloud にログインおよびアクセスするための、新しい一時的な認証情報が提供されます。

このラボを完了するためには、下記が必要です。

• 標準的なインターネット ブラウザ（Chrome を推奨）

注: このラボの実行には、シークレット モードまたはシークレット ブラウジング ウィンドウを使用してください。これにより、個人アカウントと受講者アカウントの競合を防ぎ、個人アカウントに追加料金が発生しないようにすることができます。

• ラボを完了するための時間（開始後は一時停止できません）

注: すでに個人の Google Cloud アカウントやプロジェクトをお持ちの場合でも、このラボでは使用しないでください。アカウントに追加料金が発生する可能性があります。

ラボを開始して Looker にログインする方法

1. 準備ができたら、[ラボを開始] をクリックします。

   [ラボの詳細] ペインに、このラボで使用する一時的な認証情報が表示されます。

   ラボの料金をお支払いいただく必要がある場合は、表示されるポップアップでお支払い方法を選択してください。

   [ラボの詳細] ペインに表示されているラボの認証情報を確認してください（このラボの Looker インスタンスにログインする際に使用します）。

   注: 他の認証情報を使用すると、エラーが表示されたり料金が発生したりします。

2. [Open Looker] をクリックします。

3. 提供されたユーザー名とパスワードを、[Email] フィールドと [Password] フィールドに入力します。

   ユーザー名:

   {{{looker.developer_username | Username}}}

   パスワード:

   {{{looker.developer_password | Password}}} 重要: このページの [ラボの詳細] ペインに表示されている認証情報を使用する必要があります。Google Cloud Skills Boost の認証情報は使用しないでください。ご自身の Looker アカウントをお持ちの場合でも、このラボでは使用しないでください。

4. [Log In] をクリックします。

   正常にログインすると、このラボで使用する Looker インスタンスが表示されます。

タスク 1. Liquid を使用してインタラクティビティを向上させる

LookML では、ディメンションやメジャーのタイプ、sql、drill_fields など、多くの要素を「パラメータ」と呼びます。また、「parameter」という名前のオブジェクト自体も存在します。本ラボでは区別を明確にするため、このオブジェクトを「Liquid パラメータ」と呼びます。

パラメータとテンプレート フィルタは、Liquid を活用することで Explore、Look、ダッシュボードの操作性を向上させることができます。これは、生成される SQL をより柔軟に制御したい場合に特に有効です。ディメンション フィルタを使用すると、外部クエリの WHERE 句のみが更新されます。メジャー フィルタを使用すると、外部クエリの HAVING 句が更新されます。どちらの場合も、結果セットを「絞り込みすぎて」しまうことがあります。

パラメータとテンプレート フィルタ

パラメータとテンプレート フィルタは、Liquid を使用する場面では両者がほぼ同じ目的を果たすため、「パラメータとテンプレート フィルタ」とひとまとめにして言われることがよくあります。主な違いは、パラメータでは 1 つの特定の固定値しか指定できないのに対し、テンプレート フィルタではデータ型に応じたフィルタ演算子の全範囲を使用できる点です。文字列型の場合は、「に等しい」、「に等しくない」、「を含む」、「で始まる」などの演算子が該当します。両者の違いは次のとおりです。

• パラメータ: ユーザーが入力でき、Liquid を用いて SQL クエリに直接渡せる特定の固定値
• テンプレート フィルタ: 条件分岐を工夫して記述したロジックを用いて、ユーザー入力の値を SQL クエリに渡すもの

パラメータとテンプレート フィルタを使用すると、記述される SQL クエリにユーザー入力をどのように反映するかをより柔軟に制御できます。パラメータとテンプレート フィルタで、次のものを作成できます。

• 動的なディメンションとメジャー（コードを集約できるだけでなく、ユーザー体験の向上にもつながります）
• 動的な派生テーブル（データの粒度とフィルタリングを制御できます）
• 条件に応じて結果セットやラベルに表示される値

これらはすべて素晴らしい機能のように見えますが、Looker 上で具体的にどのような流れで動くのでしょうか。

• ステップ 1: まず、開発者がバックエンド ロジックを設定します。これは次の 2 つの部分で構成されます。
  • パラメータまたはテンプレート フィルタ。これは、ユーザーが操作できるように UI に表示されます。
  • sql パラメータ内の、パラメータまたはフィルタ値を呼び出してなんらかの処理を行う場所。
• ステップ 2: エンドユーザーがパラメータまたはテンプレート フィルタに値を入力します。これは、Explore、Look、ダッシュボードにある「通常の」ディメンション フィルタまたはメジャー フィルタに似ています。
• ステップ 3: その値が SQL に挿入され、変更された SQL を使用してクエリが作成されます。
• ステップ 4: そのクエリが実行され、ユーザーが入力した値を反映した Explore が返されます。このサイクルが、テンプレート フィルタとパラメータの両方に適用されます。

パラメータの方が概念的に理解しやすいので、パラメータの使い方から見ていきましょう。

タスク 2. Liquid パラメータを使用して動的なディメンションを作成する

Liquid パラメータは、ユーザーが選択した特定のハードコードされた値を受け取るように定義されており、これらの値が、生成された SQL クエリに渡されます。

このセクションでは、order_items ビュー内にパラメータと動的ディメンションを作成し、ユーザーが [Order Items] Explore で異なる注文作成日フィールドを選択できるようにします。ユーザーは Date、Week、Month のいずれかを選択でき、どれを選択したかに応じてクエリの結果が変わります。

1. まず、Looker のユーザー インターフェースの左下にある切り替えボタンをクリックして Development Mode に切り替えます。

2. [Develop] タブをクリックし、qwiklabs-ecommerce という LookML プロジェクトを選択します。order_items ビューファイルに移動します。

まず、ユーザーが UI で操作するものを作成する必要があります。これは parameter オブジェクトになります。ディメンションやメジャーと同じように、オブジェクトに名前を付けます（例: select_timeframe）。type は unquoted にする必要があります。これは、値が一重引用符で囲まれないようにするためです。

次に、allowed_values を 1 つ以上ハードコードします。value サブパラメータには実際に SQL クエリに挿入されるものを記述し、label サブパラメータにはその値の UI ラベルを指定します。これらの allowed_value 値のいずれかを default_value として設定することもできます。この例では、月を選択します。

ここで、ユーザー入力を受け取る Liquid パラメータを作成します。このパラメータには created_date、created_week、created_month の 3 つの値のみがハードコードされており、ユーザーはこれらの値を選択できます。

3. order_items ビューファイルで、すべてのディメンションの上（drill_fields の下の 6 行目あたり）に次の新しいパラメータの構文を追加します。

parameter: select_timeframe { type: unquoted default_value: "created_month" allowed_value: { value: "created_date" label: "Date" } allowed_value: { value: "created_week" label: "Week" } allowed_value: { value: "created_month" label: "Month" } }

まとめると、サブパラメータは次のように定義されます。

• label: UI でフィルタ オプションとして表示される文字列
• value: SQL クエリに挿入される値
• default_value: ユーザーが何も選択しなかった場合に自動的に挿入される値

ファイルは次のようになります。

次に、ユーザーが選択した指標やデータ粒度に基づいて、ダッシュボードや Look に表示されるフィールドを動的に変更したい場合があります。先ほど作成した LookML パラメータをディメンションに適用し、このパラメータのフィルタ値を異なる期間フィールドに関連付けることができます。

4. 次に、同じビューファイルで動的ディメンションを定義します。order_items ビューファイルで、パラメータ定義の後（23 行目あたり）に次の新しい動的ディメンションの構文を追加します。

dimension: dynamic_timeframe { label_from_parameter: select_timeframe type: string sql: {% if select_timeframe._parameter_value == 'created_date' %} ${created_date} {% elsif select_timeframe._parameter_value == 'created_week' %} ${created_week} {% else %} ${created_month} {% endif %} ;; }

これで、ユーザーがダッシュボードで選択したパラメータ値に基づいて、指定した期間フィールドが返されます。label_from_parameter を使用して、選択された値のラベルをタイルに渡していることに注意してください。

${created_week} と ${created_month} の期間は（使用しているデータベース言語によっては ${created_date} も）Looker によって文字列にキャストされるため、dynamic_timeframe ディメンション全体を文字列にする必要があります。

これは、ビジネス ユーザーが Explore でこのディメンションを使用する際に並べ替え順を再確認しなければならないことを意味します。Looker のデフォルトの並べ替え動作では、日付または時刻のディメンションがあるかどうかが確認され、ない場合は最初のメジャーで並べ替えられます。つまり、これは技術的には文字列型なので、初期状態では最初のメジャーで並べ替えられます。そのため、時系列が乱れる可能性があります。

それなら何の意味があるのか？不必要な複雑さを招くだけではないか？と思われるかもしれません。次の 2 つの点に留意してください。Looker のビジネス ユーザーのほとんどは閲覧者であり、エクスプローラではありません。つまり、ユーザーは用意されたダッシュボードや Look を見るだけであり、Explore で作成日や作成週などの異なるフィールドを選択することはできません。ユーザーが表示内容を変更できる手段はフィルタのみです。

閲覧者ユーザーは、他者が作成したコンテンツを見ます。そのため、dynamic_timeframe が技術的には文字列であり、手動で並べ替える必要があるという事実は、閲覧者ユーザーにはまったく影響しません。

ファイルは次のようになります。

注: 前のステップで作成したパラメータが、label_from_parameter と sql パラメータで参照されていることに注意してください。可視化タブでは、期間オプションは、ディメンション名（Dynamic Timeframe）ではなく Month、Week、Date として表示されます。

これで、Order Items Explore で動的ディメンションをテストできます。

5. [Save Changes] をクリックします。次に、[Order Items] Explore に移動します。

6. [Order Items] ビューで、新しい [Dynamic Timeframe] ディメンションと [Order Count] メジャーを選択します。

7. [Select Timeframe] という新しいフィルタ専用フィールドの横にあるフィルタ アイコンをクリックします。

   注: これは Liquid パラメータであり、[Order Items] ビューの下の [Dimensions] リストの上に表示されます。

8. UI の上部にあるフィルタ オプションで、[is] を選択したままにします。プルダウン メニューから [Month] を選択します。

9. [Run] をクリックして、結果を確認します。[SQL] タブをクリックして SQL を確認することもできます。

10. 次に、[Week] フィルタと [Date] フィルタを選択します。[Run] をクリックして、それぞれの更新された結果を確認します。

11. 実行ごとに [SQL] タブをクリックして、パラメータがどのように変わり、SQL クエリにどのように挿入されているかを確認します。

12. [Order Items] ビューに戻ります。

変更を commit して本番環境にデプロイする

1. [LookML を検証] をクリックしてから、[Commit Changes & Push] をクリックします。

2. commit メッセージを追加して、[Commit] をクリックします。

3. 最後に、[本番環境にデプロイ] をクリックします。

[進行状況を確認] をクリックして、上記のタスクを実行したことを確認します。 Liquid パラメータを使用して動的ディメンションを作成する

タスク 3. テンプレート フィルタを使用して動的なディメンションを作成する

テンプレート フィルタは、パラメータと同じ論理パターンに従います。もう一度言いますが、両者の大きな違いは、テンプレート フィルタではエンドユーザーが必要なフィルタ演算子を選択できる点です。数値データ型の場合は、「等しい」、「より大きい」、「範囲内」などがこれに該当します。

フィルタでは、値はハードコードしません。ユーザーが入力した値が、生成された SQL クエリに渡されます。ただし、フィルタ定義で Explore とディメンションを指定することで、選択肢のプルダウン メニューを表示できます。

このセクションでは、商品カテゴリの入力値を受け取り、選択されたカテゴリとその他すべてのカテゴリの 2 つのグループを結果に作成する動的ディメンションを作成します。

1. Looker IDE に戻り、products ビューファイルに移動します。

Liquid パラメータと同様に、まず UI にエンドユーザーが操作するものを作成する必要があります。テンプレート フィルタの場合は、filter オブジェクトが必要です。

注: 最適なパフォーマンスを得るため、提案値に必要なベースビューのみをクエリする小さな非表示の Explore（explore: products {} など）を作成できます。

2. ここで、ユーザー入力を受け取るフィルタ オブジェクトを作成します。products ビューファイルで、すべてのディメンションの上（drill_fields の下の 6 行目あたり）に次の新しいフィルタの構文を追加します。

ご覧のとおり、パラメータの場合とは異なり、テンプレート フィルタの allowed_values をハードコードすることはできません。

3. 推奨される方法は、suggest_explore と suggest_dimension を使用してフィルタ候補のプルダウン メニューをエンドユーザーに提供することです。

filter: select_category { type: string suggest_explore: order_items suggest_dimension: products.category }

まとめると、サブパラメータは次のように定義されます。

• suggest_explore: 提案されたフィルタ値のリストを取得するためにクエリされる Explore
• suggest_dimension: 提案されたフィルタ値のリストを提供するために提案された Explore 内で使用されるディメンション

ファイルは次のようになります。

次に、ユーザーのフィルタ入力をどこかに実装します。この例では、同じビューファイルで動的ディメンションを定義します。

テンプレート フィルタは、Liquid ブロック内で {% condition filter_name %} という構文を使用して参照されます。これにより、Liquid がテンプレート フィルタを適用する準備ができます。次に、そのフィルタを適用するフィールドの名前を指定し、{% endcondition %} タグで Liquid ブロックを終了します。これは、パラメータの参照方法とは少し異なります。ここでは、テンプレート フィルタを適用するフィールドと endconditon を指定する必要があります。

4. products ビューファイルで、フィルタ定義の後（12 行目あたり）に次の新しい動的ディメンションの構文を追加します。前のステップで作成したフィルタが sql パラメータで参照されていることに注意してください。

dimension: category_comparison { type: string sql: CASE WHEN {% condition select_category %} ${category} {% endcondition %} THEN ${category} ELSE 'All Other Categories' END ;; }

ここでは、ユーザーが選択したフィルタ条件を select_category から取得し、${category} ディメンションに適用しています。カテゴリ値が実際に条件を満たしている場合は、category_comparison ディメンションにそれが表示されます。カテゴリ値が条件を満たしていない場合は、一致しない他のすべてのカテゴリ値とともに「All Other Categories」としてまとめられます。

ファイルは次のようになります。

これで、Order Items Explore で動的ディメンションをテストできます。

5. [Save Changes] をクリックします。次に、[Order Items] Explore に移動します。

6. [Products] ビューで、[Category Comparison] というディメンションを選択します。

7. [Select Category] という新しいフィルタ専用フィールドの横にあるフィルタ アイコンをクリックします（注: これはテンプレート フィルタであり、[Products] ビューの下の [Dimensions] リストの上に表示されます）。

8. Order Items ビューで、Order Count メジャーを選択します。

9. UI の上部にあるフィルタ オプションで、[is equal to] を選択したままにします。

10. 空のテキスト ボックスをクリックしてプルダウン メニューを表示するか、「Jeans」と入力します（プルダウン メニューには他の候補値も表示されます）。

11. [Run] をクリックして結果を確認します。結果には、Jeans が 38,910 件、All Other Categories が 294,449 件と表示されるはずです。

12. テンプレート フィルタのロジックは、ユーザーがフィルタを更新すると自動的に調整されます。次のことを実際に試してください。

    • フィルタに複数の値を追加してみます。
    • フィルタを「is equal to」から「contains」または「starts with」に変更してみます。どのような結果になりましたか？

13. 実行ごとに [SQL] タブをクリックして、SQL を確認します。

注: [SQL] タブは、LookML からどのような形式のクエリが生成されたかを確認するのに役立ちますが、SQL の内容を分析すること自体が、エラーを解決するための適切なプロセスを実践することにつながります。

14. [Products] ビューに戻ります。

変更を commit して本番環境にデプロイする

1. [LookML を検証] をクリックしてから、[Commit Changes & Push] をクリックします。

2. commit メッセージを追加して、[Commit] をクリックします。

3. 最後に、[本番環境にデプロイ] をクリックします。

[進行状況を確認] をクリックして、上記のタスクを実行したことを確認します。 テンプレート フィルタを使用して動的ディメンションを作成する

タスク 4. テンプレート フィルタを使用して動的なメジャーを作成する

テンプレート フィルタと非表示のディメンションを組み合わせることで、フィルタされるメジャーのフィルタ条件を調整してメジャー値を動的に変更できます。

たとえば、マーケティング チームの一般的なユースケースとして、各トラフィック ソースからアクセスしたユーザーの構成比を分析することが挙げられます。このセクションでは、このユースケースに対応するため、ユーザーが使用可能なトラフィック ソースを選択して、そのトラフィック ソースのユーザー数を（国などのディメンション別に）動的に表示できるメジャーを作成します。

1. Looker IDE に戻り、users ビューファイルに移動します。

今回も、まず UI にエンドユーザーが操作するものを作成する必要があります。テンプレート フィルタの場合は、filter オブジェクトが必要です。

2. users ビューファイルで、すべてのディメンションの上（drill_fields の下の 6 行目あたり）に次の新しいフィルタの構文を追加します。

filter: select_traffic_source { type: string suggest_explore: order_items suggest_dimension: users.traffic_source }

値はハードコードされていませんが、Explore とディメンションの提案値があります。これらは、ユーザーが操作できるプルダウン メニューの選択肢を取得するために使用されます。ユーザーは他の値を入力することもできます。

注: これは、前のセクションで作成したフィルタと非常によく似ています。ただし、ここでは Explore を order_items に、ディメンションを users.traffic_source に設定しています。

ファイルは次のようになります。

3. 次に、同じビューファイルで非表示ディメンションを定義します。users ビューファイルで、フィルタ定義の後（12 行目あたり）に次の新しい非表示ディメンションの構文を追加します。前のステップで作成したフィルタが sql パラメータで参照されていることに注意してください。

dimension: hidden_traffic_source_filter { hidden: yes type: yesno sql: {% condition select_traffic_source %} ${traffic_source} {% endcondition %} ;; }

ファイルは次のようになります。

4. 最後に、同じビューファイルで動的メジャーを定義します。users ビューファイルで、すべてのディメンション定義の後（105 行目あたり）に次の新しい動的メジャーの構文を追加します。

注: 前のステップで作成した非表示ディメンションがフィルタ パラメータで参照されていることに注意してください。 measure: dynamic_count { type: count_distinct sql: ${id} ;; filters: [ hidden_traffic_source_filter: "Yes" ] }

ファイルは次のようになります。

これで、Order Items Explore で動的メジャーをテストできます。

5. [Save Changes] をクリックします。次に、[Order Items] Explore に移動します。

6. [Users] ビューで、[Country] ディメンション（または属性別にカウントを取得する他のディメンション）を選択します。

7. [Users] ビューで、新しい [Dynamic Count] メジャーを選択します。

8. [Select Traffic Source] という新しいフィルタ専用フィールドの横にあるフィルタ アイコンをクリックします（注: これはテンプレート フィルタであり、Explore の左側のメニューの [Dimensions] の上に表示されます）。

9. UI の上部にあるフィルタ値で、[is equal to] を選択したままにします。

10. 空のテキスト ボックスをクリックしてプルダウン メニューを表示するか、「Email」と入力します（プルダウン メニューには他の候補値も表示されます）。

11. [Run] をクリックして、結果を確認します。トラフィック ソースが「Email」と等しいすべてのユーザーの数が国別に表示されます。

[進行状況を確認] をクリックして、上記のタスクを実行したことを確認します。 テンプレート フィルタを使用して動的メジャーを作成する

12. 他のフィルタ値をいくつか試してみます。実行ごとに [SQL] タブをクリックして、パラメータがどのように変わり、SQL クエリにどのように挿入されているかを確認します。

13. [Users] ビューに戻ります。

変更を commit して本番環境にデプロイする

1. [LookML を検証] をクリックしてから、[Commit Changes & Push] をクリックします。

2. commit メッセージを追加して、[Commit] をクリックします。

3. 最後に、[本番環境にデプロイ] をクリックします。

お疲れさまでした

このラボでは、Looker で Liquid を使用して、パラメータ、テンプレート フィルタ、動的なディメンションとメジャーを作成しました。まず、ユーザーが異なる注文作成日フィールドを選択できるようにするため、パラメータと動的ディメンションを作成しました。次に、商品カテゴリの入力値を受け取り、選択されたカテゴリとその他すべてのカテゴリの 2 つのグループを結果に作成する動的ディメンションを作成しました。最後に、ユーザーが使用可能なトラフィック ソースを選択して、そのトラフィック ソースのユーザー数を動的に表示できる動的メジャーを作成しました。

次のステップと詳細情報

• LookML クイック リファレンス
• LookML の用語と概念
• Looker コミュニティ
• LookML の基礎の補足

Google Cloud トレーニングと認定資格

Google Cloud トレーニングと認定資格を通して、Google Cloud 技術を最大限に活用できるようになります。必要な技術スキルとベスト プラクティスについて取り扱うクラスでは、学習を継続的に進めることができます。トレーニングは基礎レベルから上級レベルまであり、オンデマンド、ライブ、バーチャル参加など、多忙なスケジュールにも対応できるオプションが用意されています。認定資格を取得することで、Google Cloud テクノロジーに関するスキルと知識を証明できます。

マニュアルの最終更新日: 2026 年 2 月 3 日

ラボの最終テスト日: 2026 年 2 月 3 日

Copyright 2026 Google LLC. All rights reserved. Google および Google のロゴは Google LLC の商標です。その他すべての企業名および商品名はそれぞれ各社の商標または登録商標です。