NRIネットコム Blog

NRIネットコム社員が様々な視点で、日々の気づきやナレッジを発信するメディアです

注目のタグ
    トップ > クラウド > BigQuery INFORMATION_SCHEMA×Looker セルフサービスExploreで簡単にできるサービス横断的な分析

    BigQuery INFORMATION_SCHEMA×Looker セルフサービスExploreで簡単にできるサービス横断的な分析

    クラウド Google Cloud Looker 初心者 データ分析

    はじめに

    はじめまして、入社1年目の井上です。
    普段はGoogle Cloudを用いたデータ分析基盤の保守運用、生成AIも扱えるBIツールであるLookerのPoC支援を行っています。

    大学時代は情報系の学部でJava/Python/C++/JavaScriptといったプログラミング言語をいじくりまわすことしかしてこなかったため、触ったことのないクラウドに苦戦しながらも数多くの新しい学びを楽しみながら業務にあたっています。

    そんな初心者データエンジニアが日々システムログやリリースノートとにらめっこする中で気づいたのは、最近試験的にLookerへ導入された新機能「セルフサービスExplore」がとても便利ということ。

    そこで本ブログではこの新機能を使って、LookMLの専門知識なしで簡単にできるサービス横断的な分析を、Lookerから発行されたクエリのダッシュボード別/分析手法別コスト分析を例に紹介したいと思います。

    Lookerとは

    Google Cloudが提供するBIツールで、以下のような特徴があります。

    • データを保持せずにDWHへ直接アクセスする
    • LookMLによるデータモデリングが可能
    • 大規模データセットや複雑なモデルにも耐えうるスケーラビリティ
    • Gemini for Google Cloudを活用して、自然言語による問い合わせでデータ分析ができる

    LookMLとは...
    Lookerでデータを「どう見るか」を定義するための言語のことです。SQLを毎回書かずに再利用できるデータモデルを作ることができます。

    cloud.google.com docs.cloud.google.com

    セルフサービスExploreとは

    LookMLを書かずに、ユーザ自身がCSV/Excelファイルをアップロードして分析できる機能です。（Looker25.20以降、2026/2時点ではラボ機能）

    docs.cloud.google.com

    通常、Lookerでデータを分析する前段階の準備として以下の作業が必要です。

    • LookMLモデルの作成
    • データベースへの接続設定

    LookMLモデルはLooker最大の特徴でもあり、データガバナンスの強化といったメリットはあるものの、専門知識が必須なので精通したエンジニアの介入がどうしても必要です。

    「手元にあるデータを分析して今すぐ検証に使いたい！！」といった要望が生じても、一時的な検証のためだけにエンジニアの工数を割いて対応しなければいけません。

    そんな手間を省き、ユーザ自身で手元にあるデータを手軽にアップロードし、Git管理バージョン管理やLookMLモデルを構成することなく素早く分析できるようにした機能、それがセルフサービスExploreです。


    分析に利用するログデータ

    本ブログで分析に使用するデータたちの紹介です。

    BigQuery INFORMATION_SCHEMA.JOBS_BY_PROJECT

    プロジェクト内で実行されたBigQueryジョブの実行履歴や処理量などを確認できるシステムビューです。BigQueryにあるデータへクエリが投げられる度に、誰が・いつ・どんなクエリを・どれだけのコストをかけて実行したのか等のデータが記録されていきます。
    扱いやすさのため、今回は以下のフィールドのみを使用することにします。

    フィールド名 説明
    creation_time クエリが実行された日時（UTC）
    labels.value
    (labels.key = 'looker-context-user_id')     		Looker内部で使用する識別キー
    labels.value
    (labels.key = 'looker-context-history_slug')     		Looker内部の実行ユーザID
    cache_hit キャッシュが使われたか（T/F）
    metadata_cache_statistics.table_metadata_cache_usage.table_reference.table_id 参照対象となったテーブル名
    total_bytes_billed 合計課金対象バイト数
    total_bytes_processed 合計スキャン量
    total_slot_ms 合計スロット消費量
    query SQL文

    ※labels.value(labels.key = 'looker-context-〇〇')とは、keyがlooker-context-〇〇であるデータのvalueを取ってくるという意味

    Looker System Activity

    Lookerインスタンス内部の利用状況を分析できる監視データセットです。
    今回の分析では主に以下のフィールドを使用します。

    フィールド名 説明
    History Slug Looker System Activityで使用される履歴の識別キー
    History Source クエリの発行元を示す
    （explore/sqlrunner/dashboard/lookなど）
    User ID 実行したLookerユーザのID
    User Name 実行したLookerユーザの名前
    Query Model 参照したLook MLのModelファイル名


    BigQuery×Lookerログ連携構成

    以下が今回の全体概要図になります。赤枠部分でBigQueryとLookerのログを統合させます。


    やってみよう

    BigQueryからログデータを抽出する

    以下のクエリをBigQueryで実行してクエリログを抽出、ローカルにDLします。

    ※ローカルへのDLは10MBまでという制限があります
    ※Cloud Storageなどのストレージサービスに保存→ローカルへDLするのもおすすめです 

    SELECT 
 creation_time,
 (SELECT value FROM UNNEST(labels) WHERE key = 'looker-context-user_id' LIMIT 1) as user_id, 
 (SELECT value FROM UNNEST(labels) WHERE key = 'looker-context-history_slug' LIMIT 1) as history_slug,
 cache_hit,
 (SELECT table_reference.table_id FROM UNNEST(metadata_cache_statistics.table_metadata_cache_usage) LIMIT 1) as table,
 total_bytes_billed/(POW(1024,3)) as total_bytes_billed_gb, -- GBへ変換 -- 好きな単位に変換してください
 total_bytes_processed/(POW(1024,3)) as total_bytes_processed_gb, -- GBへ変換 -- 好きな単位に変換してください
 total_slot_ms,
 query
FROM
 `region-us`.INFORMATION_SCHEMA.JOBS_BY_PROJECT  -- ご自身が利用しているリージョンを指定してください
 WHERE
 DATE(creation_time) >= '2026-01-01'  -- 取得対象期間の開始年月を'yyyy-mm-dd'の形式で入力してください
 AND DATE(creation_time) < '2026-02-01' -- 取得対象期間の終了年月を'yyyy-mm-dd'の形式で入力してください(指定日よりも前)
 AND job_type = 'QUERY'
 AND statement_type != 'SCRIPT'
 AND state = 'DONE'
 AND user_email = ''  -- ご自身がLookerプロジェクトで利用しているサービスアカウントを入力してください(複数ある場合はOR条件で追記)
ORDER BY
 creation_time asc

    Lookerへファイルをアップロードする

    Lookerホーム画面左上の「作成」から「データのアップロード」を選択して、先ほどDLしたBigQueryログデータをアップロードします。
    ※GoogleスプレッドシートのURLがあればクラウドからインポートすることも可能です
    ※セルフサービスExploreでアップロード出来るデータは100MBまでです（2026/2時点）

    Lookerがデータ型やフィールド名を自動で検出して、データフィールドの一覧を表示してくれるので確認しましょう。必要に応じてユーザ独自のディメンション/メジャーを追加することもできます。
    今回は数値型データフィールドの合計・平均・最小・最大を次のように追加します。
    ※ファイルの1行目にヘッダー行があることを前提として、そこからフィールド名を決定しているようです
    ※ヘッダー行に日本語名が入っていると文字化けすることがあります**(2026/2時点)

    Exploreで分析してみる

    データの確認ができたら、Exploreで分析をしてみます。
    例えばディメンションにCreation Date -> Date、メジャーに自分で追加したtotal_bytes_billed（合計）を指定するとLookerから実行されたクエリコストが実行日ごとに可視化できます。

    これはBigQuery上でも可視化はできますが、僕みたいにSQLがパパッと叩けない方はとても不便ですよね。
    可視化するためだけにいちいち調べて・・・ああでもないこうでもないと試行錯誤しても上手くできなかったり。

    そんな手間を省いて、直感的な操作で分析の目的に合わせて柔軟なディメンション/メジャーの組み合わせですぐ分析できるだけでも十分便利ですよね。

    System Activityと連携させる意義

    Lookerから実行したクエリログは内部のSystem Activityに保持されますが、コストやスキャン量等の情報は含まれていません。
    それらは実際にクエリが実行され、リソースが消費されるBigQuery内部のINFORMATION_SCHEMAに保持されます。

    一方で、BigQueryのログに含まれるLooker起因の情報は以下の通りです。

    • User Email（Service Account）
    • User ID
    • History Slug
    • Instance Slug

    そのため、どのダッシュボードを実行したクエリか、どんな分析手法でクエリを実行したかといった情報はBigQueryのログには含まれません。

    つまり
    Looker System ActivityだけではLooker自身が発行したクエリやダッシュボードごとのコスト効率性などといった利用状況を分析できないということです。

    クエリ統合を用いてBigQueryとLookerのログに含まれない情報をお互いに補填し、オブザーバビリティを向上させます。

    クエリ統合を使う

    Lookerからクエリを実行すると、BigQueryのログデータには、クエリ情報とともに、Looker System Activityで使用される識別キーである"History Slug"が格納されます。
    このHistory Slugを外部キーとしてSystem ActivityのHistoryテーブルとクエリを以下のように統合させて、統合結果を分析することができます。

    別の外部キーを用いたもう少し実用的な例を一つ紹介します。

    【例】会話分析によるテーブル別クエリ課金数
    Lookerで一般機能として提供され始めたAIを活用してデータと会話できる「会話分析」。これもBigQueryにアクセスするため、実行すればクエリコストが発生します。
    サービスを導入するにあたってコストを把握するのは不可欠。ということで、以下の観点で分析していきます。

    • どのユーザが
    • どのテーブルに対して
    • 会話分析を使って分析して
    • どのくらいのコストをかけているのか

    「会話分析」という分析手法によるクエリのログデータをフィルタリングするには、Looker System Activityに保持されているHistory Sourceの情報が不可欠です。
    統合クエリにより、BigQueryとLooker System Activityを紐づけ、このデータを適切にフィルタリングできます。

    <統合イメージ>
    以下のデータ項目を外部キーとしてクエリを統合させます。

    <手順>

    1. プライマリクエリであるLooker System Activity - Historyのクエリを実行する
    Historyには履歴情報が保存されているため、こちらを分析の基点とします。
    まず、以下のディメンションを追加します。

    • User ID
    • User Name
    • History Slug

    フィルタに以下を追加して実行します。

    • History Conversational Analytics Conversation IDがnullではない
    • History Created Date がBigQueryから取得したログの期間の範囲内

    右上の歯車アイコンから「結果の統合」をクリックします。

    2. 統合するクエリを実行する
    先ほどアップロードしたファイルのExplore（今回は「cost_test」）を選択し、以下をディメンション/メジャーに追加します。

    • Cost Test User ID
    • Cost Test History Slug
    • Cost Test Table
    • Cost Test Total Bytes Billed Gb（合計）

    右上の保存をクリックします。

    <クエリ結果>
    テーブル名をキーにピボットテーブル化し、グラフの体裁を整えたら以下のようになります。

    これで対象期間におけるBigQueryテーブルごとの会話分析によるクエリコストを可視化することが出来ました。

    注意点

    • ログの保持期間について
      BigQueryとLookerのログには以下の保持期間が設定されています。これを超えたログは順次消失していきます。
      あくまで検証のための分析なので、本番運用となった際にはBigQuery等のDWHにログをエクスポートして蓄積していくのがベターです。

      • BigQuery INFORMATION_SCHEMA：180日間
      • Looker System Activity：90日間

    • ログの閲覧権限について
      BigQueryからのログ取得や、LookerでのSystem Activity分析には、それぞれのサービスで適切な権限を付与する必要があります。


    おわりに

    今回は、Lookerの新機能「セルフサービスExplore」の概要とその利用方法を、実際にクエリコスト分析を行いながら紹介しましたが、いかがだったでしょうか。
    既にLookerを利用されている方、これからBIツールを使ってみたい方など、多くの方の参考になれば幸いです。

    執筆者：井上拓海 システムエンジニア