Looker StudioのBigQuery料金｜どの操作がクエリになり課金されるか

データポータル（英語名 Data Studio、旧 Looker Studio）自体は無料のツールですが、BigQuery につないだグラフは、置いたり条件を変えたりすると BigQuery へクエリを流し、BigQuery 側でそのクエリが読んだ量だけ料金がかかります。ただし、同じ条件でもう一度表示するだけなら、データポータルのメモリか BigQuery のキャッシュから結果が返り、当社の検証では課金は0でした。料金が増えるのは、新しい条件のクエリが流れたとき（グラフを置く、ディメンションや期間を変える、クロスフィルタをクリックする）と、元の表が更新された後の最初の表示です。

当社は BigQuery を中心にしたデータ基盤の設計・構築と、データポータルなどでの可視化を支援している会社です。「ダッシュボードを開くたびに料金がかかるのか」に、公式の説明だけでなく実際の本数と量で答えるため、2026年10月14日に当社の検証用の Google Cloud プロジェクトで、架空の受注明細600万行の表にデータポータルをつなぎ、操作を1つずつ行って、BigQuery に流れたクエリの本数・処理量・課金量を数えました。お客様の環境やデータではありません。

料金は読んだ量で払うオンデマンドの東京リージョン（asia-northeast1）の値で、容量課金（Editions）とカスタムクエリは扱いません。BigQuery の料金の全体像はBigQuery でデータ統合基盤を作る費用、クエリの書き方はBigQuery のクエリの最適化、レポート作りを外に頼む費用はデータポータル（旧 Looker Studio）の設定・外注費用にあります。Looker Studio は2026年4月に元の名前の Data Studio に戻り、日本語の画面と公式ドキュメントでは「データポータル」です（Google Cloud「データポータルへようこそ」）。

先に分けておく2つ：処理量と課金量、メモリとキャッシュ

BigQuery のオンデマンド料金は、クエリが読んだ列のバイト数（処理量）で決まります。ただし請求に使う課金量は、MB 単位で切り上げたうえで、参照する表ごと・クエリごとに最低 10 MB になります。東京リージョンの単価は 1 TiB あたり 7.50 米ドルで、毎月 1 TiB までは無料です。この記事の数字は、処理量と課金量を分けて書きます。

もう1つ、同じグラフをもう一度表示したときに BigQuery の表を読まずに済む仕組みが2段あります。1段目はデータポータルの「データの更新速度」です。レポートが流したクエリと結果を一時的にメモリに置き、設定した間隔のうちは同じクエリにメモリから返します。BigQuery の既定は12時間で、1〜50分ごと、1〜12時間ごとから選べます。2段目は BigQuery のキャッシュです。まったく同じ SQL の結果を約24時間持っていて、キャッシュから返したクエリは課金されません。キャッシュはユーザーごと・プロジェクトごとで、参照する表が変わると使われません。

ヘルプも、メモリを使わないクエリには、手動や自動の更新を含めて BigQuery の通常の料金がかかると注意しています。料金を読むには「どの操作が、メモリにもキャッシュにも無い新しいクエリを流すか」が分かればよく、以下はそれを1つのレポートで数えた結果です。

検証したレポート：600万行の表に、グラフを3つ

つないだ表は、検証用プロジェクトのデータセット blog_demo にある sales_part_clus です。架空の受注明細600万行・10列（order_id、order_date、store_id、channel、product_id、customer_id、quantity、unit_price、amount、note）で、order_date の日単位のパーティションと、store_id のクラスタを付けています。大きさは 873,331,772 バイト（約0.81 GiB）です。表の作り方と、列やパーティションで読む量がどう変わるかは料金の記事で書いています。

データポータルでは「レポートを作成」から「データのレポートへの追加」に進み、「データに接続」で BigQuery のコネクタを選んで、プロジェクト、データセット、表の順に選びました。パーティションのある表を選ぶと、「設定」に「パーティション分割テーブル」と「order_date を期間ディメンションとして使用」のチェックボックスが出ます。今回はオフのままにしました。データソースの認証情報は作成時のまま変えておらず、コネクタの画面の「データの認証情報」には作成者の名前が出ていました。データポータルの既定はオーナーの認証情報で、作成した人が認証情報のオーナーになります。レポートを開いて操作したのは当社のアカウント1つだけで、共有はしていません。置いたのは、レコード数のスコアカード、棒グラフ、表のグラフの3つです。

BigQuery に流れたクエリは、API で自分のジョブの一覧を取り、ラベル・処理量・課金量・キャッシュの有無・SQL を読みました。データポータルが流すクエリには、requestor: looker_studio のラベルが付きます。操作ごとの結果は次の表のとおりです。

表の26本のクエリの課金量は合わせて 1,363 MiB（約1.33 GiB）で、東京の単価に掛けると約0.01米ドル分です。無料枠の範囲に収まる量なので、金額ではなく、どの操作で何本・何 MiB 流れたかを読んでください。オンデマンドの課金は読んだ列の量で決まるので、表が大きくなれば、同じ操作でもその分だけ増えます。

出典：データポータル ヘルプ「クエリをモニタリングして分析する」、データポータル ヘルプ「データの認証情報」

データソースを追加した瞬間に、表のほぼ全部を読んだ

表を選んで「追加」を押した直後に、3本のクエリが同時に流れました。10列を3つに分け、それぞれを GROUP BY して LIMIT 100 で返す形です。そのうちの1本は次のとおりです（プロジェクト名は伏せています）。

SELECT clmn0_, clmn1_ FROM (
SELECT t0.`amount` AS clmn0_, t0.`note` AS clmn1_ FROM `your-project.blog_demo.sales_part_clus` AS t0
) GROUP BY clmn0_, clmn1_ LIMIT 100;

3本の処理量を足すと 873,331,772 バイトで、表の大きさとちょうど同じでした。LIMIT 100 で100行しか返さなくても、BigQuery は選んだ列を全部読むので、課金は 835 MiB です（LIMIT で読む量が減らないことは料金の記事でも確かめています）。いちばん大きかったのは amount と note（メモ欄の文字列）の2列を読んだ1本で、469 MiB でした。

間違えやすいのは、この3本がレポートの ID に結び付かないことです。この3本には requestor: looker_studio のラベルだけが付き、後のグラフのクエリに付いていたレポートとデータソースの ID のラベルはありませんでした。レポートごとに課金を集計すると、いちばん大きいこの分が抜けます。

今回は1回の観察で、データソースを作るたびに必ず同じクエリが流れるかまでは確かめていません。それでも、大きな表で試しにデータソースを作っては消す、を繰り返すと、そのたびに表全体の分がかかる可能性があります。このクエリは表のすべての列を読んだので、ダッシュボードに要る列だけを持つビューや表につなげば、この分は小さくなると考えられます。一方、グラフのクエリはもともと使う列しか読んでいないので、列を減らしただけでは変わりません。グラフのクエリまで小さくしたいときは、店舗と日付などで集計した表を作ってつなぎます。行が減る分、読む量も減ります。

グラフごとに少なくとも1本。読む量はディメンションの列で決まる

スコアカードを置くと、既定の指標「Record Count」（レコード数）で SELECT COUNT(1) のクエリが1本流れ、処理も課金も0バイトでした。行数を数えるだけのクエリでは、列を読まずに済んでいます。

次に棒グラフを置くと、データポータルが既定のディメンションに order_id（注文番号）を選びました。棒グラフからは、注文番号ごとに件数を数えるクエリ（order_id の列を全部読んで 63 MiB）と、上位9件以外の件数を数えるクエリ（WHERE … NOT IN (…)、63 MiB）の2本が流れました。後者は、棒グラフに出す「その他」の分と考えられます。表のグラフも order_id で置かれて同じ形のクエリが1本流れ、グラフ2つで3本、合わせて 189 MiB でした。

SELECT clmn0_, COUNT(1) AS `t0_qt_…` FROM (
SELECT t0.`order_id` AS clmn0_ FROM `your-project.blog_demo.sales_part_clus` AS t0
) GROUP BY clmn0_ ORDER BY `t0_qt_…` DESC LIMIT 2000001;

グラフのディメンションを替えると、今回は替えたグラフのクエリだけが1本流れました。表のグラフを store_id（店舗）にすると 35 MiB、棒グラフを channel（販売チャネル）にすると 39 MiB でした。同じ600万行でも、注文番号の列は店舗の列の約1.8倍の量があり、どの列を軸にするかで、そのグラフが表示のたびに読む量が決まります。棒グラフを channel にした後の表示や更新では、グラフ3つで3本でした。

見落としやすいのは、編集中の試行錯誤もそのたびにクエリになることです。編集画面には、編集中だけデータの取得を止める「更新を一時停止」があり、ヘルプは、編集中のリクエストを減らしてクエリの費用を抑えられると説明しています。一時停止は、操作した人のレポートにだけ効きます。今回は使っていませんが、大きな表でグラフを組み立てるときは、止めて形を決めてから再開すれば、途中で試したディメンションの分を読まずに済みます。

出典：データポータル ヘルプ「レポートの更新を一時停止する」

クロスフィルタのクリック1回で、ほかのグラフの分が流れた

棒グラフの棒（注文番号の1件）をクリックすると、クロスフィルタでほかの2つのグラフがその注文番号で絞り込まれ、2本のクエリが流れました。スコアカードは WHERE clmn0_ IN ('O02276508') の付いた件数で 63 MiB、表のグラフは store_id の集計に order_id の絞り込みが付いて 98 MiB です。

絞り込む前は、スコアカードが0、表のグラフが 35 MiB でした。条件に使った列も読むので、絞ったほうが読む量が増えています。読む量が減るのはパーティションの列で絞ったときで、後の期間の節で確かめます。

クロスフィルタは、ほとんどのコネクタで既定で有効です。グラフを選んでプロパティ パネルの「データ」タブの下端にある「グラフ インタラクション」の「クロスフィルタリング」で、グラフごとにオフにできます。閲覧者のクリックも、まだ流れていない条件なら新しいクエリになります。閲覧者に絞り込みを使ってもらうグラフと、見せるだけのグラフを分けて決めておくと、料金の見通しが立てやすくなります。

出典：データポータル ヘルプ「グラフのクロスフィルタリング」

開き直しと再表示は課金0だった

表示モードで同じグラフを表示し直すと、3本のクエリは流れましたが、3本とも BigQuery のキャッシュから返り、処理も課金も0でした。ブラウザでページを再読み込みしたときは、BigQuery にクエリが1本も届きませんでした。データポータルのメモリから返ったと考えられます。表示モードの「︙」メニューから「データを更新」を押しても、表が変わっていなければ3本ともキャッシュから返り、課金は0でした。なお、閲覧者が「データを更新」を使えるのは、編集者がレポート設定で「閲覧者のデータ更新」を有効にしたときだけです。

同じ人が同じ条件で見直すだけなら、料金は増えないということです。ただし、どちらも保証ではありません。データポータルのヘルプは、更新速度の間隔の中でもメモリから返る保証はないと書いており、BigQuery のキャッシュも、ふつうは24時間持ちますがベストエフォートで、それより前に無効になることがあります。手動の「データを更新」は、直前の更新から1分以内には効きません。

画面に出しっぱなしにするレポートで使うデータポータル Pro の自動更新（既定はオフ、間隔は5分ごとから1日1回まで）も、データソースの更新速度は変えず、更新速度より短い間隔ならメモリから返ります。BigQuery を読み直す間隔を決めるのは、データソースの更新速度です。

出典：データポータル ヘルプ「データの更新速度を管理する」、Google Cloud「キャッシュに保存されているクエリ結果を使用する」、データポータル ヘルプ「レポートの自動更新を管理する」

表が更新されると、次の表示でグラフの数だけ読み直した

表に架空の1行を足してから「データを更新」を押すと、BigQuery のキャッシュは使われず、棒グラフ（channel）で 39 MiB、表のグラフ（store_id）で 35 MiB を読み直しました。スコアカードの件数は0のままです。BigQuery のキャッシュは、参照する表が変わると使われないためです。足した1行は、検証の後に消しています。

毎日データを入れる表なら、入れた後の最初の表示（更新速度の間隔が切れた後か、だれかが「データを更新」を押した後）で、見られたグラフと条件の数だけ読み直しがかかる、と見ておくのが安全です。計算の例として、今回の2つのグラフ（39 MiB と 35 MiB）を、毎日1回の更新の後に1回ずつ表示すると、1日 74 MiB、30日で 2,220 MiB（約2.2 GiB）です。東京の単価に掛けると約0.016米ドルで、無料枠の中に収まります。この量は、表の大きさと、見られる条件（期間やフィルタの組み合わせ）の数に比例して増えます。

気をつけたいのは、ストリーミング挿入で数分おきに行を入れ続ける表です。BigQuery のヘルプでは、最近ストリーミング挿入を受けた表を参照するクエリの結果は、キャッシュに保存されません。そういう表では、データポータルのメモリだけが頼りになり、更新速度の間隔が切れるたびに読み直しになると考えられます（今回は試していません）。この場合は、更新速度を必要以上に短くしないか、集計した小さな表を別に作ってそちらにつなぎます。

出典：Google Cloud「キャッシュに保存されているクエリ結果を使用する」

期間で絞るとパーティションが効いた。ただし1本 10 MiB の最低課金

期間設定のコントロールを置き、2026年9月1日〜30日に固定すると、3つのグラフのクエリに order_date の条件が入りました。

SELECT clmn0_, COUNT(1) AS `t0_qt_…` FROM (
SELECT t0.`channel` AS clmn0_, t0.`order_date` AS clmn1_ FROM `your-project.blog_demo.sales_part_clus` AS t0
) WHERE (clmn1_ >= DATE '2026-09-01' AND clmn1_ <= DATE '2026-09-30')
GROUP BY clmn0_ ORDER BY `t0_qt_…` DESC LIMIT 2000001;

order_date はパーティションの列なので、BigQuery は9月のパーティションだけを読みました。条件に合わないパーティションを読まずに飛ばす仕組みで、パーティションのプルーニングと呼ばれます。処理量は、棒グラフ（channel）が期間なしの 38.1 MiB から 2.5 MiB へ、表のグラフ（store_id）が 34.3 MiB から 2.4 MiB へと、それぞれ約15分の1と約14分の1になりました。

ところが課金量は3本とも 10 MiB でした。オンデマンドの最低課金が、クエリごとに 10 MB あるためです。公式の表記は 10 MB ですが、実際に課金されたのは 10,485,760 バイト（10 MiB）でした。棒グラフは 39 MiB から 10 MiB に、表のグラフは 35 MiB から 10 MiB に減りましたが、0だったスコアカードは、order_date の列を読む必要ができて 10 MiB に増えました。3つの合計では 74 MiB から 30 MiB です。

今回は「order_date を期間ディメンションとして使用」のチェックをオフのままにしていましたが、期間設定が order_date に掛かったので、絞り込みは効きました。ヘルプによると、このチェックをオンにすると、そのデータソースのグラフにはパーティションの列が期間ディメンションとして自動で使われ、常に既定の期間のフィルタが掛かります（「自動」なら過去28日間）。BigQuery の表で「パーティション フィルタを要求」を設定していると、このチェックは自動でオンになり、外せません。この仕組みが使えるのは、日単位で分けた DATE・DATETIME・TIMESTAMP のパーティションだけです。

期間で見るダッシュボードなら、パーティションの日付の列を期間ディメンションにして、既定の期間を決めておくことをお勧めします。全期間を読むクエリが既定で流れるのを防げるからです。一方で、最低課金はクエリ1本ごとにかかるので、期間で絞った後は、新しい条件で表示したときの課金の下限がグラフの数で決まります（キャッシュから返れば0ですが、そうでなければグラフ3つで30 MiB）。小さな集計のグラフを1ページに何十も並べると、この下限が積み上がります。

出典：Google Cloud「パーティション分割テーブルに対してクエリを実行する」、データポータル ヘルプ「日付パーティション分割テーブルに接続する」

見る人が増えると料金は増えるか：認証情報で変わる

ここからは公式の説明を読み合わせたことで、今回は試していません。データソースの認証情報は、既定の「オーナーの認証情報」のほか、「閲覧者の認証情報」と「サービス アカウントの認証情報」から選べます。オーナーの認証情報なら、閲覧者は BigQuery の権限がなくてもグラフを見られ、データの更新速度のメモリはレポートの閲覧者全員で1つです。閲覧者の認証情報にすると、閲覧者ごとに BigQuery の権限（BigQuery データ閲覧者と BigQuery ジョブユーザー）が要り、更新速度のメモリも閲覧者ごとに分かれます。

BigQuery のキャッシュもユーザーごと・プロジェクトごとで、ほかのユーザーのキャッシュを使えるのは Enterprise・Enterprise Plus エディションの場合です。2つを合わせると、オンデマンドで閲覧者の認証情報にした場合、同じ条件のグラフでも閲覧者ごとに最初の表示で読み直しがかかると考えられます。オーナーの認証情報なら、だれかの表示で流れたクエリの結果をほかの閲覧者も使えます。

データポータルのヘルプも、クエリの費用とパフォーマンスの効率を最大にするには、再利用できるデータソースとオーナーの認証情報を検討するよう勧めています。閲覧者ごとに見せる行を変えたいなど、閲覧者の認証情報が要る理由があるときは、人数の分だけ読み直しがかかる前提で、読む量の小さい表につなぎます。

費用を払うプロジェクトは、データソースを作るときに選ぶプロジェクトで決まり、データのあるプロジェクトとは別のプロジェクトに課金することもできます。代理店がお客様の BigQuery につなぐ場合などは、どちらに請求が来るかをつなぐ前に取り決めておきます。

出典：データポータル ヘルプ「データの認証情報」

BI Engine と抽出データは、条件を読んでから選ぶ

公式のドキュメントは、表示を速くする手段として BI Engine と抽出データを挙げています。料金への効き方は、それぞれの仕組みから読みます。どちらも今回は試していないので、公式の条件だけを書きます。

BigQuery BI Engine は、よく使うデータをメモリに置いてクエリを速くする BigQuery の機能です。オンデマンド料金では、BI Engine が高速化した段階は処理量0として課金され、その後の段階にも追加のオンデマンド料金はかかりません。その代わり、クエリを流すプロジェクトで BI Engine の容量を予約し、その容量に料金を払います。ワイルドカードで複数の表を読むクエリ、外部テーブル、行レベルのセキュリティなどには効きません。予約の料金が読み直しの料金を上回るかどうかは、ラベルで数えた実際の課金量と比べて決めます。

抽出データは、元のデータソースから必要な項目だけを取り出して保存した、別のデータソースです。作成後、レポートからのデータのリクエストは、元のデータセットではなく、この保存したスナップショットに送られます。取り出したデータは静的で、新しくするには「自動更新」のスケジュールを設定します。上限は 100 MB・750,000 行で、今回の600万行の明細はそのままでは入りきりません。抽出の画面で合計などの集計方法を選び、行を減らして使うことになります。抽出や自動更新のときに BigQuery がどれだけ読むかは、今回確かめていません。

出典：Google Cloud「BigQuery の料金」、データポータル ヘルプ「BigQuery データソースのパフォーマンスを最適化する」、Google Cloud「BI Engine の概要」、データポータル ヘルプ「データポータルのパフォーマンスを改善する」、データポータル ヘルプ「パフォーマンス向上のためにデータを抽出する」

作る前に決める順番

ここまでの検証の結果から、決める順番とその理由を並べます。前に決めたものが、後のクエリの大きさや回数の前提になる順です。

最初に決めるのは、つなぐ表と列です。今回は、データソースを追加しただけで、グラフを1つも置く前に表の全列を読み、835 MiB かかりました。この分は後の設定では減らせず、表を替えてつなぎ直せば、またかかる可能性があります。グラフのクエリの大きさも、つないだ表の行と列で決まるので、集計した表につなぐかどうかもここで決まります。

次が期間です。グラフを置いた時点で、既定のディメンションのクエリが全期間に対して流れました（③で 189 MiB）。期間ディメンションのチェックはデータソースの設定で、オンにするとグラフに常に既定の期間のフィルタが掛かるので、グラフを置く前に決めておけば、最初から絞ったクエリになります。

期間で絞ると、残るのは1本ごとの最低課金です。⑪では処理量が3本で約6 MiB でも、課金は 30 MiB でした。そのため、3番目にグラフの数を決めます。軸にする列とクロスフィルタも、1本ごとの量（order_id で 63 MiB、store_id で 35 MiB、クリック1回で 161 MiB）を決めます。

1〜3で決まるのは、新しい条件で1回表示したときの課金です。それが何回かかるかを決めるのが認証情報なので、レポートを共有する前に決めます。今回は作成者の認証情報のままで、同じ条件の再表示・再読み込み・表が同じときの「データを更新」は0でした。閲覧者の認証情報では、これが閲覧者ごとになると考えられます（試していません）。

データの更新速度を最後にしたのは、今回の結果では、課金を分けたのが更新速度ではなく表の更新だったからです。表が変わらなければ「データを更新」でもキャッシュから返って0、表が変わると読み直して 74 MiB でした。間隔が課金に直接効くのは、ストリーミング挿入の表のようにキャッシュが効かない表だと考えられるので、そういう表を見せるときに、間隔を詰めすぎないよう決めます。設定は、データソースの編集画面の「データの更新速度」で、「最新のデータを確認する」の間隔を選びます。

出典：データポータル ヘルプ「日付パーティション分割テーブルに接続する」、データポータル ヘルプ「データの更新速度を管理する」

自分のレポートの課金は、ジョブのラベルで数える

実際のレポートで何が流れているかは、BigQuery のクエリ履歴で、データポータルが作った SQL をそのまま確かめられます。オーナーの認証情報のデータソースで、BigQuery のプロジェクトのオーナー権限を持つ人なら、グラフの右上に出る BigQuery のアイコンから「Powered by BigQuery」のダイアログを開き、そのグラフの SQL と、請求対象のバイト数を見ることもできます。レポートの左下には最後にデータを取得した日時が出ていて、それが最後に期間やフィルタを変えた時刻より前なら、そのページのグラフはメモリから返っています。

まとめて数えるなら、ジョブのラベルを使います。データポータルが BigQuery に送るクエリには requestor: looker_studio のラベルが付きます。今回の検証では、グラフのクエリにはさらに looker_studio_report_id と looker_studio_datasource_id のラベルも付いていました。INFORMATION_SCHEMA.JOBS ビューの labels と total_bytes_billed をこのラベルで集計すれば、レポートごとの課金量が出せます。ただし、上で書いたとおり、データソースを追加したときの3本にはレポートの ID が付いていませんでした。また、容量課金（Editions）のプロジェクトでは、total_bytes_billed は請求額ではなく参考の値です。

自分のダッシュボードの料金を知りたいときは、まず1週間分のデータポータルのジョブを、このラベルで課金量の多い順に並べてみてください。データソースの作り直しが多いのか、グラフの数か、閲覧者の絞り込みか、表の更新の頻度かで、上の順番のどこから手を付けるかが決まります。

当社は、BigQuery の表の設計から、データポータルのレポートを料金の見通しが立つ形で組むところまでをデータ分析の支援で手伝っています。

料金と仕様は、2026年10月14日に Google Cloud の公式ドキュメントで確かめたものです。検証の数字は、当社の検証用プロジェクトで同じ日に1回だけ計ったもので、表の大きさや操作の順番が違えば変わります。

出典：データポータル ヘルプ「クエリをモニタリングして分析する」、データポータル ヘルプ「データの更新速度を管理する」、Google Cloud「JOBS ビュー」