BigQueryのDWHを非構造化データへ拡張する：データレイクハウスの全体像

BigQueryでDWH（データウェアハウス）を構築すると、売上・顧客・広告といった構造化データを統合して分析できるようになります。
そこに「議事録や過去の戦略資料からも示唆を出したい」という要望が来ることがあります。PDFやPowerPoint、音声はBigQueryのテーブルには入りません。

本記事では、DWH構築の経験を前提に、この要望への答えとしてデータレイクハウスの全体像を整理します。
レイクハウスとは何か、作り方が2通りあること、Apache Icebergはどこで必要になるのか、既存のDWH資産をどうするのか、までをご紹介します。

レイクハウスとは

レイクハウスは、データレイク（安価で柔軟なファイル置き場）とDWH（テーブル管理と分析機能）を統合したアーキテクチャです。
Google Cloudでは、構造化データはBigQuery、PDF・音声・画像のファイルはCloud Storage（GCS）と、データの種類ごとに適した場所へ保存し、BigQueryを入口として両方を参照・検索・AI処理できる状態を作ります。

PDFはPDFのまま、音声は音声のままGCSに置きます。
従来のDWH構築の思想が「分析したいデータをBigQueryのテーブルに集める」だったのに対して、レイクハウスは「全部をBigQueryから扱えるようにする」への転換です。

したがって、これまで作ってきたDWH（BigQueryへの物理集約 + dbtでのモデリング + BI）を捨てて作り直す話ではありません。
DWHはそのまま残し、その外側に非構造化データの置き場と接続の層を足して、扱える範囲を拡張します。以下、この構成を順に分解していきます。

BigQueryが担っている3つの役割

BigQueryは、3つの役割を1つのサービスとして提供しています。

1. ストレージ：データの実体を保持する

2. テーブル管理：スキーマ、どのデータが現在のテーブルを構成するか、更新の履歴を管理する

3. クエリエンジン：SQLを実行する

従来のDWH構築で、この3つを意識する必要はありませんでした。
CREATE TABLEしてデータを入れれば、実体の保存もテーブルの管理もクエリの実行も、全部BigQueryの中で完結していたためです。

レイクハウスは、この3役を分離して、役割ごとに担い手を選び直す設計です。
分離すると、ストレージはGCS、テーブル管理はオープンな規格（代表が後述するApache Iceberg）、クエリエンジンはBigQueryにもSparkにもできる、という選択肢が生まれます。

作り方は2通り：BigQuery中心型とIceberg中心型

3役をどこまで分離するかで、作り方は2通りに分かれます。

BigQuery中心型は、構造化データについては3役ともBigQueryのまま動かさない構成です。非構造化データだけGCSに置き、参照でBigQueryに繋ぎます（接続の仕組みは後述するObjectRefです）。
既存のdbtモデルとBIはそのまま使い続けられ、運用もこれまでのDWHとほぼ変わりません。

Iceberg中心型は、構造化データの正本もGCSに移す構成です。
データはGCS上のParquetファイルとして持ち、テーブル管理をApache Icebergというオープン規格に出します。
BigQueryは「そのテーブルを読み書きするエンジンの一つ」になり、SparkやTrinoからも同じテーブルを直接読み書きできます。

どちらを「レイクハウス」と呼ぶのか

ここで用語を正確にしておきます。
レイクハウスという語の原典は、Databricksの研究者らがデータベース分野の国際会議CIDRで2021年に発表した論文で、定義の第一要件は「Parquet等のオープンで直接アクセス可能なデータ形式に基づくこと」です。

同じ論文は「全データを、ストレージと計算を分離した独自形式のウェアハウスに格納する構成」を、普及しなかった次善策として名指しで退けています。BigQueryの内部形式は独自形式なので、BigQuery中心型はこの記述に該当します。

Google自身も、lakehouseの語はオープン形式の構成に対して使っています。Google Cloudのレイクハウス製品「Lakehouse for Apache Iceberg」はその名の通りIceberg構成の製品であり、公式ドキュメントのlakehouseの定義も「オープン形式でCloud Storageに保存する」ことを含みます。

つまり、原義のレイクハウスはIceberg中心型を指します。
ネットの記事には「BigQueryもレイクハウス」という言い方が流通していますが、一次ソースの裏付けがない緩い用法です。

本記事では、BigQuery中心型は「レイクハウスが解こうとした課題、つまり構造化データと非構造化データの統合利用への、Google Cloud上の現実的な別解」として扱います。

どちらを選ぶか

選ぶ基準は「非構造化データを扱うか」ではありません。
非構造化データを扱うだけなら、BigQuery中心型で足ります。

基準は「構造化データの正本をBigQueryの外に出して、複数のエンジンで共用したいか」です。
Icebergにすると、データがGoogle独自形式ではなくGCS上のオープン形式になるためロックインが減り、BigQueryとSparkが同じテーブルを使えるようになります（One Copy, Multiple Engines）。

裏返すと、分析がBigQuery・dbt・BIで完結していて、SparkもTrinoも使っていない場合、Icebergを入れる追加価値は小さいです。
冒頭の「議事録からも示唆を出したい」が目的なら、BigQuery中心型から始めるのが実務的です。

Apache Icebergとは

Apache Icebergは、GCSのようなオブジェクトストレージ上に置いた複数のParquetファイルを、1つの論理テーブルとして管理するためのオープンなテーブル形式です。

Icebergがない場合の問題から見ていきます。GCSに月次の売上ファイルが並んでいるとします。

gs://sales-data/
├── 2026-01.parquet
├── 2026-02.parquet
├── 2026-03.parquet
└── ...

これはあくまでファイルの集合であって、「salesというテーブル」はどこにも存在しません。
どのファイルが現在のsalesを構成するのか、スキーマは何か、更新したらどれが最新か、昨日時点の状態はどうだったかを、全部自分で管理することになります。

Icebergは、このファイル群の上にテーブル管理の層を作ります。
テーブル名・スキーマ・どのファイルが所属するか・各時点の状態（Snapshot）を管理し、利用者からは SELECT * FROM sales という1つのテーブルに見えます。

更新のたびに新しいSnapshotが作られ、過去の各時点の状態も残ります。
これにより、UPDATEやMERGE、昨日時点への問い合わせ（Time Travel）、列の追加（Schema Evolution）といった、DWHでは当たり前のテーブル操作が、GCS上のファイル群に対してできるようになります。

なお、Parquetはスキーマを持つ列指向の形式なので、議事録の書き起こしのような自由記述も、meeting_id・meeting_date・transcriptという列構成の1列（文字列型）として持てます。

意味的には非構造でも、器としては列構造を持ちます。ただし、PDF・音声・画像といったファイルそのものは行と列になりません。

非構造化データはObjectRefで繋ぐ

原則は「ファイル本体はGCS、BigQuery側にはそのファイルへの参照を持つ」です。ファイルの中身をBigQueryに二重保存はしません。

具体例で見ていきます。次のようなcustomersテーブルを持っているとします。

ここに最新の商談議事録を顧客データとして紐付けたいとします。
PDF本体は gs://company-data/meetings/ に置き、BigQuery側に customer_meetings テーブルを作ります。

このdocument_ref列がObjectRefで、GCS上のPDFを指します。

ObjectRefは、参照先のURIやアクセス権限の情報を持つSTRUCT型で、OBJ.MAKE_REF()関数でURIから生成できます。
2025年6月にPreviewとして発表され、2026年4月にGAになりました。

この仕組みの利点は2つあります。
第一に、顧客という1レコードの属性としてPDFを紐付けられるので、売上・ARRと議事録を同じデータモデルで扱えます。

第二に、ObjectRefをBigQueryのAI関数（AI.GENERATE等）に渡すと、SQLの中からGeminiでPDFの要約・分類・埋め込み生成ができます。
事前にPDFを行と列に変換しておく必要はありません。

Object Tableとの使い分け

もう1つの接続手段としてObject Tableがあります。
GCS上のファイル群そのものを「ファイル一覧のテーブル」としてBigQueryから見せる、読み取り専用のテーブルです。

使い分けは目的で決まります。
「社内の議事録PDFを全部まとめてAIで検索・処理したい」ならObject Table、「顧客・案件・商談といった業務レコードに文書を紐付けてデータモデルを作りたい」ならObjectRefです。

集約とモデリングはなくならない

ここまでで、置き場所と繋ぎ方は決まりました。
残る疑問は「データが散らばったままで、統合と言えるのか」「BigQueryへの集約とモデリングは、もう不要なのか」です。

集約とモデリングは完全には消えません。
ARRやChurnのような重要KPIを、毎回複数のシステムを横断参照して算出する設計は取りません。
頻繁に使う構造化データはこれまで通りBigQueryへ物理的に集め、dbtでCore / Mart / KPIをモデリングします。

理由はクエリ性能、KPI定義の統一、履歴の保持です。
「アクセスできること」と「分析しやすいデータモデルがあること」は別問題で、レイクハウスが解くのは前者です。

一方で、全部をコピーする必要もなくなっています。
たまにしか参照しないCloud SQL上のデータは、federated query（EXTERNAL_QUERY関数）を使えば、コピーも移動もせずにBigQueryから参照できます。実体を動かして集めるデータと、参照で繋ぐだけのデータを使い分けます。

そしてAI活用の観点で最後に効くのは、customer_id = C001 を引けば、BigQueryの売上・契約と、GCSの議事録が全部つながって出てくる状態です。
ファイルをGCSに集めただけでは、この状態にはなりません。共通キーとメタデータで繋いで初めて、AIが顧客を横断して読めるようになります。

この「どこに何があり、それが何を意味し、何とつながるか」を管理するのがカタログです。ARRの定義・Owner・更新頻度といった用語の管理から、この指標はどのテーブルから作られたかという系譜（Lineage）まで含みます。
データと利用者とAIエージェントが増えるほど、カタログの重要度が上がります。

整理すると、変わったのは「物理的に一箇所へ集めること」が統合の必須条件ではなくなった点です。
頻繁に使うデータは集めてモデリングし、そうでないデータは参照とカタログで繋ぎます。「全部集める」から「必要なものだけ集め、残りは繋ぐ」への変化であり、集めた後のモデリングの仕事はそのまま残ります。

Google自身の製品もこの方向に進んでいます。
ObjectRefは「全部をBigQueryに保存するのではなく、全部をBigQueryから扱えるようにする」を製品機能にしたものです。

さらに2026年7月のNext Tokyoで発表された「borderless Lakehouse」は、AWSやSnowflake、Databricksといった他クラウド・他基盤にあるデータを、コピーせずBigQueryやAIから直接クエリする構想を打ち出しています。

全部Googleでやる必要はない

ここまでの設計を実際の製品に割り付けます。BigQueryとGCSを使うからといって、全レイヤーをGoogle製品で固める必要はありません。

Googleで固定する価値が高いのは、BigQuery + GCS + ObjectRef周辺です。ObjectRefはBigQuery固有の機能なので、この接続を使うならこの3つはセットになります。

逆にIngestion・Modeling・Catalog・Orchestration・BI・AIは交換可能で、既存資産を優先してよい領域です。
dbtで作ってきたモデルをDataformに移行する必要はありません。

何から始めるか

順序は4段で考えます。

1. まずBigQuery + GCS + ObjectRef / Object Tableで、構造化 + 非構造化の統合利用を作る。冒頭の要望への直接の答えがここです

2. データ・利用者・AIエージェントが増えてきたら、カタログを本格整備する

3. コピーする意味が薄い外部データは、Federationで論理接続する

4. Icebergは、複数エンジン共用・正本の独立という要求が実際に出てから導入する。最初から全面採用する必要はありません

最後に、調べる際に混乱しやすいので、製品名の現状を整理しておきます（2026年8月時点）。

BigLakeは2026年4月20日付で「Lakehouse for Apache Iceberg」に改称されました（API名・CLI名は旧称のまま残ります）。
BigLake metastoreは「Lakehouse runtime catalog」へ、Dataplex Universal Catalogは4月10日付で「Knowledge Catalog」へ改称されています。
機能の提供状況は、Iceberg Managed TablesとObjectRefはGA、Spark / Trino等との読み書き相互運用はPreviewです。

さいごに

DWH構築の経験を前提に、レイクハウスの全体像を整理しました。
「議事録からも示唆を出したい」への答えは、いま持っているDWHの外側に、GCSという置き場とObjectRefという参照の層を足すことです。
DWHを捨てて作り直す必要はありません。Icebergもカタログも、必要になった時に足せばよいものです。

この記事が全体像を掴む一助になれば幸いです。