G-gen の菊池です。当記事では、 Looker のスケジュール配信機能で配信されたデータが古いままになっており、バッチ更新された最新のデータが反映されない問題の解決方法を解説します。 事象 原因 対処法 概要 手順1. データグループの定義 手順2. Explore への適用 手順3. 永続的な派生テーブル（PDT）への適用 手順4. ダッシュボードでのトリガー設定変更 事象 BigQuery のデータを可視化する Looker のダッシュボード環境を想定します。BigQuery のテーブルデータは、毎朝バッチ処理によって、前日分のデータが自動的に更新・追加される設計です。 バッチ処理が正常に完了し、BigQuery のデータが最新化されたタイミングで、Looker のダッシュボードを定期配信するスケジュール機能（メール送信など）を実行しています。 しかし、BigQuery のデータが最新になっているのにもかかわらず、スケジュール機能で自動配信されたレポートには前日分のデータが反映されておらず、古い内容のままで届いてしまう事象が発生しました。 ユーザーが Looker のダッシュボード画面を開き、手動で「キャッシュをクリアして更新」を実行した場合は、前日分を含む最新のデータがダッシュボード上に正しく表示されました。このため、配信レポートが古いままであることを防ぐために、担当者が毎朝わざわざダッシュボードを開いて手動で更新をかけるという、余計な手間や運用コストが発生してしまいます。 原因 この事象が発生する原因は、Looker が備えるクエリキャッシュ機能です。Looker はデータベースへのクエリ負荷を下げるために、過去に実行したクエリ結果を一時的にキャッシュします。Looker のデフォルト設定では、クエリのキャッシュ保持期間は 1 時間です。 参考 : クエリのキャッシング - Lookerにおけるキャッシュされたクエリの用途 手動でダッシュボード上の「キャッシュをクリアして更新」を実行すると、Looker はキャッシュを無視してデータベースに直接クエリを発行するため、データソースの最新のデータが表示されます。一方で、時間指定で動作するスケジュール配信は、 キャッシュ保持期間内だった場合、Looker に保存されている有効期限内のキャッシュ（古いデータ）をそのまま利用してレポートを作成して、送信してしまいます。 これが、スケジュール配信のレポートだけが古くなってしまう原因です。 参考 : ダッシュボードの表示 - ダッシュボードのデータの更新 対処法 概要 スケジュール配信で常に最新のデータを表示させるためには、データベースの更新タイミングと Looker のキャッシュ期限を同期させる必要があります。 これらを実現する機能が、Looker の データグループ （datagroup）です。 データグループを使用することで、データベースの更新を Looker が自動的に検知し、キャッシュをリセットできます。 Looker では、スケジュール配信の起動条件として「時間指定」だけでなく「データグループの更新完了」を指定できます。 データグループの更新完了をスケジュール配信のトリガーに設定すると、以下の順番で配信処理が行われます。 データベースの更新完了を Looker が検知する 最新のデータでキャッシュを再構築・クリアする キャッシュの更新プロセスが完了した後に、スケジュール配信を送信する これにより、バッチ処理の完了を待ってからレポートが送信されるため、データが古いまま送信されるリスクを完全に排除できます。 参考 : クエリのキャッシング - キャッシュ保持ポリシーを変更する 参考 : ダッシュボードのスケジューリングおよび送信 - データグループの更新によってトリガーされるスケジュール 手順1. データグループの定義 LookML のモデルファイルにデータグループを設定します。 datagroup : bigquery_daily_datagroup { sql_trigger : SELECT MAX(insert_timestamp) FROM `your_project.your_dataset.your_table` ; max_cache_age : "24 hours" label : "BigQuery Daily Batch Trigger" description : "毎朝のBigQueryデータ更新を検知しキャッシュをリセットするデータグループ" } BigQuery のデータ更新を検知するために、 sql_trigger パラメータを使用します。 sql_trigger に指定する SQL クエリは、バッチ処理の完了時に結果の値が変化するクエリを設定します。例として、更新タイムスタンプの最大値や、最新レコードの ID が挙げられます。この値が前回のチェック時から変化したことを Looker が検知すると、データグループがトリガーされます。 また、バッチ処理が失敗した際のセーフティとして、キャッシュの有効期限を定義する max_cache_age パラメータを組み合わせて設定します。クエリがキャッシュされてから max_cache_age に設定した期間を過ぎると、キャッシュは無効となり、次回のクエリ発行時に、データベースから最新の結果が取得されます。 ここで注意すべきなのは、Looker は sql_trigger 内の SQL クエリに対して、 タイムゾーン変換を自動で行わない という仕様です。 通常の Explore を介したクエリでは、 Looker のユーザータイムゾーン（User Time Zone）などの設定により、データベースに送信される日時の値が自動的に日本時間（JST）などに変換されます。 しかし sql_trigger で実行されるクエリは、データベース接続のバックグラウンドプロセスでそのまま実行されるため、Looker による自動的な変換処理が行われません。 たとえば、 BigQuery の標準のタイムゾーンは UTC です。 以下のように単純な SQL クエリを記述した場合、意図しないタイミングでトリガーが評価されてしまいます。 sql_trigger : SELECT CURRENT_DATE() ; 上記の例は、本来は日付が変わることをトリガーにした例です。しかし上記の SQL は BigQuery 上で実行され、デフォルトの UTC で処理されます。その結果、日本時間（JST）の午前9時にようやくトリガーが実行されることになり、朝一の配信に間に合わなくなります。 これを防ぐためには、以下のように SQL クエリ内で明示的にタイムゾーンを指定してください。 sql_trigger : SELECT CURRENT_DATE("Asia/Tokyo") ; また、バッチ処理の完了を検知するためにテーブルの最新のタイムスタンプを参照する場合も、以下のようにタイムゾーンを考慮した変換を組み込みます。 sql_trigger : SELECT DATE(MAX(insert_timestamp), "Asia/Tokyo" ) FROM `your_project.your_dataset.your_table`; このように、 sql_trigger に記述する SQL では常にデータベース本来の基準時間（UTC 等）で実行される前提で、クエリ自体に明示的なタイムゾーン指定を含める必要があります。 参考 : datagroup - sql_trigger 手順2. Explore への適用 定義したデータグループを、ダッシュボードが参照している Explore に紐付けます。 紐付けには persist_with パラメータを使用します。 特定の Explore に設定する場合は、以下のように記述します。 explore : your_explore_name { persist_with : bigquery_daily_datagroup } モデル全体（すべての Explore）に一括して適用する場合は、モデルファイルのトップレベルに記述します。 persist_with : bigquery_daily_datagroup 参考 : クエリのキャッシング - データグループを使用してExploreのクエリキャッシュリセットを指定する 参考 : persist_with (for Explores) 参考 : persist_with (for models) 手順3. 永続的な派生テーブル（PDT）への適用 ダッシュボード内の要素が、永続的な派生テーブル（以下、 PDT）を参照している場合は、保存された View ファイル内の derived_table 定義にもデータグループを適用します。 これにより、データベースの更新を検知した直後に PDT も自動的に再構築されます。 view : your_view_name { derived_table : { datagroup_trigger : bigquery_daily_datagroup sql : SELECT ... ; } } 参考 : クエリのキャッシング - データグループを使用してPDTの再構築トリガーを指定する 手順4. ダッシュボードでのトリガー設定変更 LookML での記述が完了したら、 Looker のユーザーインターフェース上で、ダッシュボードのスケジュール配信設定をデータグループの更新に同期させます。 具体的な設定手順は以下のとおりです。 対象のダッシュボードを開き、右上にあるその他メニュー（縦の3点リーダー）から「配信をスケジュール設定」を選択 「スケジュール配信」ウィンドウが開いたら、「繰り返し」のプルダウンメニューから「データグループの更新」を選択 新たに表示される「データグループ」の選択フィールドから、定義した bigquery_daily_datagroup を指定 宛先や形式（PDF、CSV zip 等）を必要に応じてカスタマイズし、ウィンドウ下部にある「保存」ボタンをクリック これで、毎朝のバッチ処理完了から、Looker のキャッシュクリアと PDT の再構築、スケジュール配信送信、という一連の流れが自動的に同期され、常に最新データが含まれるレポートを配信できます。 参考 : ダッシュボードのスケジューリングおよび送信 - データグループの更新によってトリガーされるスケジュール 菊池 健太 (記事一覧) 事業開発部クラウドサポート課。2024年7月より、G-genに入社。群馬出身のエンジニア。前職でLookerの使用経験はあるが、Google Cloudは未経験なので現在勉強中。

G-gen の菊池です。Gemini Enterprise のサブスクリプションでライセンス数を削減しようとした際に直面するエラーと、その解決策について解説します。 事象 原因 ライセンス削減の仕様制限 サブスクリプションを新規作成する際の壁 対処の手順 概要 手順1: 自動更新の停止 手順2: 契約の期限切れを待つ 手順3: 新しいサブスクリプションの購入 手順4: ライセンスの自動更新 事象 Google Cloud の請求先アカウントに紐づく、Gemini Enterprise のサブスクリプション（月間プラン、または年間プラン）を利用している環境を想定します。 利用者の減少などにより、不要になったライセンス分の課金を停止したいケースがあります。公式ドキュメントでは、Google Cloud コンソールのサブスクリプションの詳細画面からライセンス数の更新が可能であると記載されています。この画面からライセンス数を 増やす 場合は、問題なく変更を保存できます。 しかし、同じ画面でライセンス数を 減らそうと した際、以下のエラーが表示され、変更を保存できない事象が発生しました。 ライセンス数は、現在のライセンス数以上である必要があります 参考 : Get subscriptions and assign licenses for Gemini Enterprise - Update subscription settings なお、Gemini Enterprise の正式名称は Gemini Enterprise app ですが、公式ドキュメントでも多くの場合で単に Gemini Enterprise と記載されているため、当記事でも Gemini Enterprise の名称を採用します。 原因 ライセンス削減の仕様制限 公式ドキュメントを確認すると、2026年8月現在、Gemini Enterprise の仕様上、有効なサブスクリプション契約の期間中にライセンスの合計数を減らすことはできないことが明記されています。 参考 : Frequently asked questions about Gemini Enterprise subscriptions and licenses - Can I reduce the license count Can I reduce the license count? No, you can't reduce the license count during an active subscription term. License reductions are only possible when the subscription term ends or is up for renewal. (引用者訳: いいえ、有効な契約期間中はライセンス数を減らすことはできません。ライセンス数の削減は、契約期間が終了するか、更新時期が近づいた場合にのみ可能です。) また、Gemini Enterprise では、途中解約、残期間分の支払いの免除や返金もできません。 そのため、契約途中に実際の利用人数に合わせて、Google Cloud コンソールの画面からライセンス数を減らすことはできません。なお、契約期間中であってもライセンス数を 増やす ことは可能です。 ライセンス数を減らすには、現在のサブスクリプションの自動更新をオフにして、契約期間が切れてから、適切なライセンス数で 新しいサブスクリプションを作成 する必要があります。 この対応は、月間プランであれば月単位で各月の契約満了時に実施でき、年間プランであれば年単位になります。 サブスクリプションを新規作成する際の壁 前述の通り、ライセンス数を減らすには「現在の契約が切れてから新規購入する」必要があります。しかし、Google Cloud コンソールでサブスクリプションを購入する際、契約の開始日を選択する項目はありません。未来の開始日を指定してサブスクリプションを予約購入することはできず、購入が完了した日から即座に有効になります。 よって、ライセンス数を減らして新しいサブスクリプションを購入しようとすると、古い契約が失効してから新しい契約を購入するまでの間に、Gemini Enterprise が利用できない空白期間が発生することになります。 そこで、このリードタイムをなくすための代替案として、「一時的な重複課金を許容してでも、元の契約期間がわずかに残っている時点で、あらかじめ少ないライセンス数の新しいサブスクリプションを購入しておく」というアプローチが考えられます。 しかしこの代替案にも、 Subscription already exists エラー というシステム上の仕様が存在するため、 実現できません 。 Gemini Enterprise のサブスクリプションは、プロジェクト単位ではなく、請求先アカウントレベルで管理されます。 同一の請求先アカウント内において、「同じエディション（例: Standard）」かつ「同じ期間（月間または年間）」のサブスクリプションを重複して保持しようとすると、Subscription already exists エラーが発生し、購入がブロックされます。 例えば、別プロジェクトでサブスクリプションを管理したいといった理由で、既存契約とは別のプロジェクトにサブスクリプションを新規作成しようとした場合であっても、同様にエラーが発生します。重複はあくまで、請求先アカウントのレベルでチェックされるからです。 単に別プロジェクトで Gemini Enterprise を利用したい場合であれば、既存サブスクリプションのライセンスを別プロジェクトへ配布（Distribute）することで対応できます。しかし、今回のように「ライセンス数を削減したい」という目的を達成するためには、配布による運用では対応できないため、次章で解説する手順が必要です。 参考 : Get subscriptions and assign licenses for Gemini Enterprise - Distribute licenses 対処の手順 概要 前述のエラーと仕様制限を回避してライセンス数を削減するには、 現在のサブスクリプションが失効するのを待ってから新規購入 する必要があります。 この手順を採用する場合、契約期間が満了して古い契約が失効してから、新しい契約を購入するまでの間、Gemini Enterprise が利用できない空白期間が発生します。 その点に留意したうえで、以下の手順を実施します。 手順1: 自動更新の停止 Google Cloud コンソールの「サブスクリプションを管理」画面から、現在のサブスクリプションの [ 編集 ] を開きます。自動更新が有効なままだと、削減前のライセンス数のまま次回の契約が更新されてしまうため、自動更新をオフに設定し、現在の契約期間の満了を待ちます。 手順2: 契約の期限切れを待つ サブスクリプションの契約期間が終了し、完全に失効（Expired）状態になるのを待ちます。契約期間が満了するまでは新規購入がエラーとなります。 手順3: 新しいサブスクリプションの購入 既存契約の失効を確認した後、削減後の必要なユーザー数を指定した新たなサブスクリプションを購入します。 手順4: ライセンスの自動更新 ユーザーが Gemini Enterprise を使えない空白期間を最小限にするため、手動での割り当てだけでなく、新しいライセンスが自動的に割り当てられる設定が推奨されます。Google Cloud コンソールの Gemini Enterprise ページから [ ユーザーの管理 ] を開き、以下の設定を行います。 [ ライセンスを自動的に割り当てる ] を選択し、手順 3 で購入した新しいサブスクリプションを指定する。 [ 期限切れのライセンスを自動更新する ] を選択する。 この設定により、古いサブスクリプションの有効期限が切れたユーザーが次にログインした際、新しいサブスクリプションからライセンスが自動的に付与されます。 参考 : Get licenses for Gemini Notebook Enterprise - Automatically transfer users to an active subscription 菊池 健太 (記事一覧) 事業開発部クラウドサポート課。2024年7月より、G-genに入社。群馬出身のエンジニア。前職でLookerの使用経験はあるが、Google Cloudは未経験なので現在勉強中。

はじめに こんにちは。クラウドエース株式会社 第一開発部の猪野です。 データ活用が当たり前になった昨今、Google Cloud が提供するエンタープライズ向け BI プラットフォーム「Looker（ルッカー）」はご存知でしょうか？ 「Looker って名前は聞くけど、なんだか難しそう……」 そんな Looker 初学者の方 に向けたチュートリアルです。 データポータルとの決定的な違いは「LookML」による一元管理 機能が似ている「データポータル (旧 Looker Studio)」は直感的にグラフを作れる反面、各レポート内に計算ロジックを持たせるため、「A さんと B さんの