はじめに こんにちは。全社データ技術局データビジュアライゼーションチームの與田龍人です。 モダンデー ...

G-genの菊池です。Looker におけるデータモデリングにおいて、複雑な分析や集計を効率化する 派生テーブル （Derived Tables）について、その機能分類と選定の基準を解説します。 Looker の派生テーブルとは 定義方法による分類 概要 ネイティブ派生テーブル SQL ベースの派生テーブル データの保持方法による分類 概要 一時的な派生テーブル 永続的な派生テーブル（PDT） 永続性戦略 概要 トリガーベースの戦略 保存期間ベースの戦略 データベースが管理する戦略（マテリアライズドビュー） 増分 PDT 概要 利用するための必須条件 Looker 派生テーブルの選定基準 概要 定義方法の選定基準 データの保持方法の選定基準 PDT の永続性戦略や増分 PDT の選定基準 Looker の派生テーブルとは Looker の 派生テーブル とは、LookML 内で定義したクエリ結果を、データベース内の実際のテーブルのように使用できるようにする機能です。 派生テーブルを使用することで、複数の種類のデータを事前結合したり大量のデータを集計したりした結果を、あたかも1つのテーブルであるかのように扱うことができます。 例えば、顧客が行った注文の数や初回注文日時など、顧客ごとの集計値を事前に計算した派生テーブルを作成することで、データベース内の他のテーブルと同じようにデータ探索ができます。 参考 : Lookerの派生テーブル 定義方法による分類 概要 派生テーブルは定義に方法に応じて「ネイティブ派生テーブル」「SQL ベースの派生テーブル」に分類することができます。 参考 : Lookerの派生テーブル - ネイティブ派生テーブルとSQLベースの派生テーブル ネイティブ派生テーブル ネイティブ派生テーブル は、LookML を使用して定義される派生テーブルです。既存の Explore （エクスプローラ）の定義を再利用して作成します。 ネイティブ派生テーブルの大きなメリットとして、まずデータモデルの可読性と保守性が向上します。ネイティブ派生テーブルは、LookML 内ですでに定義されているディメンションやメジャーを参照して定義されます。そのため、SQL を直接記述するアプローチと比較して、データをモデル化するときの読みやすさと理解しやすさが向上します。 また、コードを記述する手間を大幅に削減できるという利点があります。Looker の Explore 機能の画面上で派生テーブルとして表示したいデータの形を整えた後、そこからネイティブ派生テーブル用の LookML を自動生成してコピーできるため、一から手動でコードを記述する手間を省くことができます。 Explore 機能で表示データ作成 ネイティブ派生テーブルの LookML を取得 さらに、フィルタ機能の簡単な適用とシームレスな連携が可能です。豊富なフィルタ機能をLookMLの構文で直接適用できることに加え、 bind_filters や bind_all_filters といった機能を使用することで、元の Explore でユーザーが設定した日付などのフィルタ条件を、派生テーブル側のクエリにも簡単に連携させることができます。 ネイティブ派生テーブルの注意点として、ネイティブ派生テーブルは LookML の構文に依存しているため、複数ステップの処理を必要とする SQL 構文やカスタム DDL（データ定義言語）が必要なケースには対応できません。 さらに、既存の LookML モデルへの依存度が高い点も挙げられます。ネイティブ派生テーブルは既存の Explore（エクスプローラ）の定義をベースに構築されるため、参照したいテーブルや結合関係が LookML 上にまだ定義されていない場合は、まずその基礎となるデータモデリングから始める必要があります。 SQL ベースの派生テーブル SQL ベースの派生テーブル は、標準的な SQL クエリを直接記述して定義する派生テーブルです。 SQL ベースの派生テーブルの大きなメリットとして、まず既存の SQL 資産を手軽に流用できる点が挙げられます。Looker の「SQL Runner」機能で作成・テストした SQL クエリを、そのまま派生テーブルの定義へと簡単に変換できるショートカット機能が用意されています。これにより、すでに動作確認済みの SQL や、データアナリストが書き慣れた SQL クエリを素早く Looker のデータモデルに組み込むことができます。 SQL Runner 機能で SQL クエリ作成 SQL ベース派生テーブルの LookML を取得 また、ネイティブ派生テーブル（LookML）では表現が難しい、高度で複雑な処理を実現できる点も重要な強みです。単一の SQL ステートメントでテーブルを作成できず複数ステップの処理が必要な環境や、BigQuery ML のようなデータベース固有のカスタム DDL コマンドを実行したいといった、極めて高い柔軟性が求められるケースに対応できます。 ただし、保守性や運用面においては注意が必要です。SQL ベースの派生テーブルは、基盤となるデータベースのスキーマで列の追加や削除などがされた際、エラーを防ぐために手動で SQL の記述を修正しなければなりません。そのため、基本的には可読性やメンテナンス性が高いネイティブ派生テーブルの利用を第一に検討し、どうしても SQL の直接記述や特殊な機能が必要な場面に限って SQL ベースの派生テーブルを採用することが推奨されます。 データの保持方法による分類 概要 派生テーブルは「ネイティブ派生テーブル」「SQL ベースの派生テーブル」という分類のほかに、データの保持方法に応じて「一時的な派生テーブル」「永続的な派生テーブル（PDT）」にも分類できます。 それぞれの組み合わせで、4種類の派生テーブルがあり得ることになります。 参考 : Lookerの派生テーブル - 一時的な派生テーブルと永続的な派生テーブル 一時的な派生テーブル 一時的な派生テーブル は、データベースに物理的なテーブルとして書き込まれない派生テーブルです。 ユーザーが Explore などでデータをリクエストするたびに、Looker が派生テーブルの定義を使用して SQL クエリを構成し、都度データベースに対して新しいクエリを実行します。 ただし、有効なキャッシュが存在する場合はそれが使用されます。 データベースに実際のテーブルを作成しないため、Looker 用の書き込み権限や専用のスキーマを事前に準備する必要がありません。 また、リクエストのたびにクエリが実行されるため、常にベースとなるテーブルの最新のデータ状態を反映した結果を得ることができます。そのため、一時的な派生テーブルは、常に最新データを取得したい場合や、実行速度が速くデータベースに過度な負荷をかけない軽量なクエリに向いています。 一方で、クエリの実行に長時間を要する重い処理の場合は、パフォーマンスの低下を避けるために永続的な派生テーブル（PDT）を使用します。 永続的な派生テーブル（PDT） 永続的な派生テーブル （Persistent Derived Tables、略称 PDT）は、定義されたクエリの実行結果をデータベース上の スクラッチスキーマ （書き込み用の一時スキーマ）に実際のテーブルとして書き込み、指定したスケジュール（永続性戦略）に基づいて再構築する派生テーブルです。 一時的な派生テーブルがクエリのたびに都度計算されるのに対し、PDT は計算済みのデータをデータベース内に保持する仕組みを持っています。 PDT の最大のメリットは、頻繁に実行されるクエリの結果を保持することで、実行速度を向上させ、データベースへの負荷を大幅に削減できる点です。 特に、大量のデータや複数種類のデータを扱う場合（例：初回注文日を基準に顧客をコホート別に分類するなど）に有効で、リアルタイムで実行すると重い処理を事前に1度だけ計算し、その結果を PDT として再利用できます。 さらに、開発を効率化できる点も魅力です。データベース管理者（DBA）のサポートがなくても、Looker 上でインデックスやソートキーなどの最適化オプションを自らテストし、パフォーマンスの向上を確認してから DBA に本番環境への適用を依頼することができます。 永続性戦略 概要 永続性戦略 とは、永続的な派生テーブル（PDT）の再構築タイミングを決める設定のことです。PDT はデータベース上に実テーブルとして書き込まれることになるため、データを最新化するタイミングが重要になります。 特定の値が変化したことなどを検知するトリガーベースの戦略、時間経過をきっかけとする保存期間ベースの戦略、データベースが管理する戦略（マテリアライズドビュー）があります。 参考 : Lookerの派生テーブル - 永続性戦略 トリガーベースの戦略 データグループ（ datagroups ）を使用する、最も推奨される戦略です。 データベースの特定の値を監視する SQL クエリ（ sql_trigger ）を定義し、その値が変化したとき（例として ETL 処理の完了を示すフラグが立ったとき）に PDT を再構築します。これにより、ソースデータの更新に合わせて効率的にテーブルを更新できます。 保存期間ベースの戦略 persist_for パラメータを使用して、PDT を保持する時間を指定します。 指定した時間が経過した後にクエリが実行されると、PDT が再構築されます。厳密な更新タイミングを必要としない場合や、設定の簡略化を優先する場合に使用します。 データベースが管理する戦略（マテリアライズドビュー） Google Cloud の BigQuery など、データベース側の マテリアライズドビュー 機能を利用する戦略です。 LookML で materialized_view: yes を指定することで、Looker の PDT 管理ロジックではなく、データベース側の自動更新ロジックに委ねることができます。 増分 PDT 概要 増分 PDT （Incremental PDTs）は、PDT をすべて作り直すのではなく、新しく追加されたデータのみを既存のテーブルに追加する機能です。 通常の PDT は再構築のたびにテーブル全体を削除して作成し直しますが、増分 PDT では increment_key （日付やタイムスタンプなど）を基準に、新しいデータのみを取得して追加します。 これにより、テーブルの再構築にかかる時間とデータベースのリソース消費を大幅に削減できます。 参考 : 増分 PDT 利用するための必須条件 増分 PDT を導入する際には、システム上必須となる条件（必須条件）と、パフォーマンスに影響する推奨条件の2つがあります。 まず、増分 PDT を有効にするための必須条件について説明します。 増分 PDT は、再構築のタイミングを制御する「永続性戦略」において、必ずトリガーベースの戦略を採用していなければなりません。保存期間をベースとする戦略では、Looker の仕様上サポートされていないためです。 また、新しいデータの追加範囲を Looker に認識させるため、照会期間を定義する increment_key パラメータの設定が不可欠です（SQL ベースの場合はさらに Liquid フィルタの追加も必要になります）。 加えて、派生テーブルの定義方法にも制約があります。SQL ベースで定義する場合、必ず標準の sql パラメータを使用する必要があります。複雑なカスタム DDL ステートメント（ sql_create など）を利用すると、Looker が正確な増分作成に必要なコマンドを判別できなくなり、構築に失敗してしまうためです。 また、制約として、接続先のデータベース自体が増分更新に必要な操作に対応している（行の削除や挿入を行う DDL コマンドをサポートしている）必要があります。これらを一つでも満たしていない場合、増分 PDT という機能を利用することができません。 一方、システム的な必須条件ではないものの、実運用において強く求められる推奨条件が存在します。 それは、元のソーステーブルに対して、時間ベースのクエリに向けた最適化（パーティショニングやインデックス、並べ替えキーの付与など）を施しておくことです。 増分 PDT はテーブルを更新するたびに、まずソーステーブルに対してクエリを実行し、増分キーの「最新値」を調べるという仕様になっています。もしソーステーブルが最適化されていないと、この最新値を探し出す処理そのものに膨大な時間とコストがかかってしまいます。つまり、この条件を満たしていなくても増分 PDT を構築すること自体は可能ですが、構築時間を短縮するという本来のメリットが失われ、かえって非効率になってしまうため、事前の最適化が強く推奨されています。 Looker 派生テーブルの選定基準 概要 基本的には、メンテナンス性の高いネイティブ派生テーブルかつ、データベースに負荷をかけない一時的な派生テーブルから構築を始めるのが第一選択です。 その後、クエリの重さに応じて一時的なテーブルを使うか、PDT を使うか検討します。 さらにデータ量が多く再構築コストが高ければ全体の再構築を伴う PDT ではなく、増分 PDT を使用することを判断します。 このように、パフォーマンス要件に合わせて最適な設定を選択するのが、Looker の派生テーブルのベストプラクティスです。 詳細を、以下に記載します。 定義方法の選定基準 派生テーブルのクエリをどのように記述するかによる分類です。基本的にはメンテナンス性の高いネイティブ派生テーブルを第一選択とします。 分類 定義 有用なケース 向いていないケース ネイティブ派生テーブル LookML （Explore やフィールド参照）を使用して定義する派生テーブル 既存の LookML 指標を再利用したい場合。データモデルの読みやすさと理解しやすさ（保守性）を高めたい場合 単一のSQLで完結しない処理やカスタムDDLが必要な場合など、特殊なSQL構文を要するケース SQL ベースの派生テーブル 標準的な SQL クエリを直接記述して定義する派生テーブル LookMLだけでは表現が難しい特殊な処理や複数ステップの処理が必要な場合。SQL Runner でテスト済みのクエリをそのまま流用したい場合 スキーマ変更の影響を受けやすいため、保守性を重視する場合。既存の LookML 指標を参照したい場合 データの保持方法の選定基準 クエリ結果をデータベースに物理的に保存するかどうかの分類です。絶対に不可欠になるまでは一時的な派生テーブルを使用し、パフォーマンス要件に応じて PDT 化を検討するのがベストプラクティスです。 分類 定義 有用なケース 向いていないケース 一時的な派生テーブル リクエストのたびにデータベースで都度クエリが実行され、物理的に保存されない派生テーブル 実行速度が速くデータベースへの負荷が低いクエリの場合。常に最新のデータ状態を反映した結果を得たい場合。データベースが読み取り専用の環境である場合 クエリの実行に長時間を要する重い処理や、頻繁に実行される複雑な事前集計の場合 永続的な派生テーブル（PDT） クエリの結果をデータベースの専用スキーマに実際のテーブルとして書き込み、保持する派生テーブル 大量のデータの事前結合や集計が必要な重い処理を1度だけ計算し、結果を再利用してパフォーマンスを向上させたい場合 パフォーマンス上の問題がなく常に最新のデータが必要な場合。ストレージやリソースコストの消費が許容できない場合 PDT の永続性戦略や増分 PDT の選定基準 PDT を使用する場合、永続性戦略や（再構築のタイミング）や増分 PDT を使用するか否かも選定する必要があります。 分類（戦略・種類） 定義 有用なケース 向いていないケース トリガーベースの戦略 指定したデータグループや時間間隔等に基づき自動的に再構築する戦略 複雑な重い処理で、ユーザーにクエリ完了の待機時間を発生させたくない場合（構築中も古いデータを返すため） ユーザー属性やテンプレートフィルタを使用するクエリ（サポート対象外） 保存期間ベースの戦略 最初にクエリを実行したタイミングで構築され、指定期間保持された後に削除される戦略 常に最新である必要はなく、一定期間結果を保持して再利用できれば十分な場合 期限切れ後にクエリを実行するユーザーに待機時間を発生させたくない場合。増分 PDT を利用したい場合 データベース管理 （マテリアライズドビュー） データベース側のマテリアライズドビュー機能を利用してテーブル更新を管理する戦略 データベース側で新しいデータが検出されるたびに更新されるため、リアルタイムなデータが必要なシナリオ データベース側が非対応な場合。マテリアライズドビューに関する高度な知識がない環境 増分 PDT 全体を再構築するのではなく、新しいデータ（増分）のみを追加して構築する設定 データ量が膨大で、テーブル全体の初期構築や再構築に大きなコストや時間がかかる場合 ソーステーブルの時間ベースの列がクエリ用に最適化（パーティショニング等）されていない場合。保存期間ベースの戦略を採用している場合 菊池 健太 (記事一覧) 事業開発部クラウドサポート課。2024年7月より、G-genに入社。群馬出身のエンジニア。前職でLookerの使用経験はあるが、Google Cloudは未経験なので現在勉強中。

こんにちは。ファインディ株式会社でデータエンジニアをしている 開 です。 2026年4月28日（火）に、データソリューションチーム主催の採用イベント 「事業成長に効かせるファインディ流データエンジニアリングの実践」 を開催しました。 findy-inc.connpass.com この記事では、イベントを企画した背景と当日の3本のセッションを参加できなかった方にもイメージが伝わるようにまとめます。 イベント開催の背景 セッション1: ファインディの事業拡大を支える拡張可能なデータ基盤へのリアーキテクチャ セッション2: データモデリングを通して管理会計のオペレーションを再設計 セッション3: 社内で使われるLooker整備の進め方 まとめ イベント開催の背景 ファインディでは、既存4プロダクトに加えて、新たに4つのプロダクトをリリースし、エンジニアの皆さまへサービスを多角的に展開しています。会社規模の拡大とともに、扱うデータの量と種類は急速に広がってきました。 prtimes.jp 変化の激しい事業環境のなかで客観的な意思決定を支えるには、社内の情報流通をより活性化させる仕組みが欠かせません。私たちは、その土台を担うのがデータエンジニアリングだと考えています。 データソリューションチームは少数精鋭で推進してきましたが、事業成長のスピードに合わせてデータ基盤をさらにスケールさせるには、共に挑戦してくれる仲間の存在が不可欠です。今回のイベントは、ファインディがどのような課題に向き合い、どのような技術と組織で解いているかを直接お話しする機会としました。 セッションは3本立てで、データ基盤・データモデリング・BIの3つの観点からファインディのデータエンジニアリングをお話ししました。 セッション1: ファインディの事業拡大を支える拡張可能なデータ基盤へのリアーキテクチャ 登壇者: 開 speakerdeck.com 事業拡大に合わせてデータ基盤をどうリアーキテクチャしているかを紹介しました。直近1年でデータソースは10倍、Google Cloudプロジェクトは6倍に増える一方、データエンジニアは3名のままで、認知コストと運用負荷が膨らんでいました。 これまでは事業＝ドメインとしたデータメッシュ的な構成で、技術選定も各チームに委ねていました。アジリティは出る一方で、ドメイン間の連携不足や技術のばらつき、作業重複が課題になっていました。 そこで、データメッシュの利点は残しつつ実装を見直し、Google Cloudプロジェクトの統合、IAMのデータセット単位での管理、dbt Platformへのオーケストレーション集約やマネージドサービスの活用を進めています。これによりマネージドサービスのAPIやMCPを用いてAIエージェントに運用を一部移譲することができています。作成したスキルやサブエージェントは以前テックブログで紹介したプラグインとしてチーム全体で使えるようにしています。 tech.findy.co.jp DataOpsの省力化が進む一方、コスト透明性の低下といった新しい課題も見え、FinOps体制の構築や、浮いた時間をデータ活用者との会話やイネーブリングに使っていくことを次のテーマにしています。 セッション2: データモデリングを通して管理会計のオペレーションを再設計 登壇者: 田頭さん speakerdeck.com 経営判断に直結する管理会計という業務領域に対して、データモデリングの観点からオペレーションを再設計した取り組みを紹介しました。 ファインディの管理会計は、長らくスプレッドシートを中心に回っていました。月次のたびに関数とピボットを手作業で組み直し、IMPORTRANGEやVLOOKUPで絡み合ったスプレッドシートのリネージは50件を超え、どこか1枚崩れると全体が連鎖して壊れる脆さを抱えていました。同じKPIが部署ごとに別ロジックで計算されて数字が合わない、月次締めに2〜3日かかって意思決定が後追いになる、といった状態も常態化していました。 再設計の起点に置いたのは、技術選定ではなく業務担当者へのヒアリングです。「計上組織」「補助科目」「配賦」「予算番号」といった専門用語が飛び交うなか、勘定元帳やマクロを眺めるだけでは掴めない集計粒度や分析軸を、経営管理部の担当者と何度もMTGを重ねて引き出していきました。書籍 『アジャイルデータモデリング 組織にデータ分析を広めるためのテーブル設計ガイド』 のBEAM✲を参考に、誰が・何を・いつ・どこで集計したいのかを対話から輪郭化し、総勘定元帳を起点に売上・費用・原価を月次粒度のファクトとして整理しています。 実装は、会計データソースをGoogle DriveにアップロードしてTROCCOで取り込み、dbtで集計してLookerやスプレッドシートから参照する構成に落としています。これにより、ワンボタンで月次の実績値が揃い、想定外の科目も自動で検出できるようになりました。「どの数字が正しいか」を議論する場面はなくなり、月次締めの所要時間と数字の信頼性が同時に改善しています。 今後は、実績ファクトと同じ粒度で予算・見通しを取り込んだ予実分析の自動化や、整備済みのファクトを起点にAIエージェントが自然言語で会計分析を行える基盤への展開を進めています。 セッション3: 社内で使われるLooker整備の進め方 登壇者: 出相さん speakerdeck.com 社内で実際に使われるBIにするためにLookerをどのように整備してきたかを紹介しました。「ダッシュボードを作った瞬間がピークになって使われなくなる」「事業部からはデータ活用の入口が見えない」「スプレッドシート運用が属人化して限界が見えている」といった、よくある課題を出発点にしています。 ファインディでは、Lookerを意思決定にひも付くダッシュボードを定常的に見る場としてだけでなく、Exploreや会話分析でデータそのものを探索する場にすることを目指しています。ただし、最初はLookerを見に行く習慣もExploreの操作にも慣れていないため、進め方の工夫が欠かせません。 そこで、ヒアリングで課題を引き出す → 最低限の機能に絞って最初のダッシュボードを素早く提供する → 共有MTGで一緒に触りながら改善ループを回す → 利用が定着してからディメンショナルモデルやメタデータを整える、という4ステップで価値を積み上げてきました。完璧な設計よりも早い体験提供を優先し、苦労していたことから先に解消していくことを大切にしています。詳しい進め方は以前のテックブログでも紹介しています。 tech.findy.co.jp その結果、MAUは2026年1月から4月途中で約1.5倍、WAUは1月中旬から4月中旬で約2.6倍に成長しました。経営管理部からも「BigQueryやLookerを駆使したモニタリングが事業拡大に不可欠」というコメントが届くなど、Lookerが信頼できるデータソースとして社内に定着してきています。 まとめ 今回のイベントを通じて、ファインディがデータエンジニアリングをどのように事業に効かせようとしているかを、3つの異なる切り口でお伝えできたと思います。データ基盤・データモデリング・BIのいずれも、技術そのものよりも「事業や業務にどう接続するか」を軸に進めてきた取り組みです。 参加してくださった皆さん、ありがとうございました！ ファインディでは、データエンジニアリングの力で事業成長を支える仲間を募集しています。今回のイベント内容に少しでも興味を持っていただけた方は、ぜひお気軽にカジュアル面談などでお話しできるとうれしいです。 herp.careers