BigQuery におけるMaterialized View の優位点と活用事例
2026年01月13日
AI・DX室 dx
こんにちは、社内DX室です。
BigQuery を使ったデータ分析や BI ダッシュボード運用において、「クエリが遅い」「利用コストが安定しない」と感じたことはないでしょうか。
そのような課題に対して有効な選択肢の一つが Materialized View(マテリアライズドビュー) です。
今回は BigQuery の Materialized View について、「どのようなケースで使うと効果が出るのか」を軸に、通常の View との違いや具体的な活用事例を紹介します。
BigQueryにおけるView と Materialized View の違い
通常の View とは
View は SQL を保存しただけの「仮想テーブル」です。
データそのものは保持せず、参照するたびに元テーブルに対してクエリが実行されます。
CREATE VIEW v_sales AS
SELECT * FROM big_table WHERE kubun_num = 2;
この View を SELECT すると、内部では毎回 big_table が参照され、条件に合致するデータが再計算されます。
そのため、データ量が増えるにつれて表示時間やクエリコストが比例して増加するというポイントがあります。
Materialized View とは
一方、Materialized View はクエリ結果を実データとして保持する仕組みです。
CREATE MATERIALIZED VIEW mv_sales AS
SELECT kubun_num, SUM(amount)
FROM big_table
GROUP BY kubun_num;
この定義を行うと、集計結果が BigQuery 内に保存され、元データの更新に応じて自動で増分更新されます。
参照時は、あらかじめ集計済みのデータを読むだけで済むため、計算処理がほとんど発生しません。
View と Materialized View の比較
|
項目 |
通常の View |
Materialized View |
|---|---|---|
|
データの保存 |
保存しない(仮想) |
保存する(実体化) |
|
クエリ速度 |
遅くなりがち |
高速 |
|
クエリコスト |
毎回フルスキャン |
低コスト |
|
更新タイミング |
常にリアルタイム |
自動増分更新 |
|
主な用途 |
SQL の共通化 |
大量データの集計 |
|
制約 |
ほぼなし |
SQL に制約あり ※サブクエリ等一部関数が使用不可 |
|
ストレージ |
不要 |
必要 |
Materialized View には、以下のような制約があります。
- サブクエリが利用できない
- 他の View を FROM 句で参照できない
- 検索条件を事前に固定しづらいワード検索のような処理には向かない
一方で、検索条件や集計の形があらかじめ限定されている場合では効果が発揮されます。
たとえば「月次条件*区分表示の切り替え」といったシンプルな集計結果を表示する場合には繰り返し計算をするViewではなく、事前計算した値を表示する Materialized Viewが適しています。
Materialized View が向いているケース
Materialized View は、次のようなケースで特に効果を発揮します。
- 1回のクエリで数十MB以上をスキャンしている
- 日次・月次で数百万〜数千万レコード規模になっている
- 毎日・毎時間同じ集計結果を使う
- 時系列で増え続けるデータを扱っている
リックソフトでの活用事例
リックソフトでは、各種データを BigQuery 上で管理し、BI ダッシュボードとして可視化していました。
当初はすべてのダッシュボードで通常の View を利用していましたが、利用が増えるにつれて次の課題が顕在化しました。
- 画面操作のたびにクエリが実行され、表示にラグが発生する
- 同じような集計処理が何度も走り、クエリコストが安定しない
- ダッシュボード利用者が増えるほど負荷とコストが増大する
これらの課題に対し、多くのタイミングで繰り返し使われている参照View を Materialized View に置き換える対応を行いました。
具体的には、
- SUM や GROUP BY などの重い集計処理
- ダッシュボードで頻繁に参照される固定ロジックの集計結果
を Materialized View として事前計算・実体化しています。
導入後の効果
BigQuery のジョブエクスプローラで確認すると、Materialized View を参照しているクエリは合計スロット時間が 0.03〜0.07 秒程度で完了しています。
一方、Materialized View を使っていない集計クエリでは数秒〜数十秒かかっており、差は一目で分かる状態です。

この変更により、「ダッシュボードが遅い」という問い合わせがほぼなくなりました。
以前まで問い合わせが発生した際は、
- データ量が増えた影響なのか
- BI ダッシュボードの仕様や不具合の可能性なのか
などを検討・調査する必要がありましたが、Materialized View 導入後はそのような調査自体が不要になりました。
調査対応にかかっていた工数が大きく削減されたことが、運用面で最も大きな効果だと感じています。
まとめ
Materialized View は
- 大量データを扱う
- 同じ集計を繰り返し利用する
- パフォーマンスやコストに課題を感じている
といったケースにおいて、非常に強力な選択肢です。
すべてを Materialized View にする必要はありませんが、ダッシュボードで頻繁に参照される集計処理に限定して使うことで、表示速度とコストのバランスを取りやすくなります。
BigQuery を使った分析やダッシュボード運用を一段レベルアップさせたい方は、ぜひ Materialized View の活用をご検討ください。
AI・DX室 dx
この記事を読んだ⼈におすすめのページ
本情報はブログを公開した時点の情報となります。
Software Collection
Jira Service Management
Customer Service Management
Assets
Rovo
Focus
Jira Align
Talent


モダン開発の落とし穴『認知負荷』の正体――。複雑なエンジニアリング環境を救うIDP (Compass)の価値を一般家庭に例える
SFA・Excel・データ整形の限界を突破!Workatoで予実管理を自動化する方法|月末の「あの作業」がなくなる
Jira通知の種類と設定を比較解説|メール・Slack・Teams・フィルターのベストプラクティス
【プロンプトあり・POC手順つき】会議事録からJira課題を自動起票する方法|Workato×VertexAI活用