🛁

BigQuery Analytics Hubのデータクリーンルーム、チョット理解した

snhryt

2026/01/20に公開

 まえおきご無沙汰しています。みなさん、2026年もデータやってますか？
https://x.com/iwashi86/status/2012393301874528434
「データこそが唯一のMOAT」な時代で、昨今、その貴重な自社データを使って直接的なマネタイズをする動きが国内外で見られるようになってきました。この流れを推し進めている一因（ないしは、このムーブメントに乗じた作戦）として、DWHサービスを提供する各社が、データの共有・販売のプラットフォーム自体の整備を進めていることが挙げられます。
BigQuery (Google Cloud) にも、ご存知の方が多いと思いますが Analytics Hub (BigQuery Sharing)[1] というデータ共有の機能が備わっていて、昨年には国内での販売事例なども出ていました↓
https://prtimes.jp/main/html/rd/p/000000121.000033212.html
では、ここで、そんな偉大な Analytics Hub の公式ドキュメントを見てましょう。

https://docs.cloud.google.com/bigquery/docs/analytics-hub-introduction?hl=ja より
な、なんだってばよ・・このGoogle語のオンパレード・・・！！！
せっかく便利なサービスのはずなのに、少なくとも僕は、とてもとっつきづらく感じてしまいました。そんな折にちょうど業務で本機能を触る機会があったので、社内向けの引き継ぎも兼ねて、ナレッジや手順を整理してみました。

 前提知識
 やさしい用語解説いったんGoogle語の呪縛を解くために、厳密さを無視して、雰囲気で用語の解説をします。

パブリッシャー: データを提供する側[2]

サブスクライバー: データを使う側

リスティング: データを使う側がデータを選択する場所

エクスチェンジ: 一般的なデータの提供手段

クリーンルーム: エクスチェンジよりもセキュアなデータの提供手段

 「エクスチェンジ」と「クリーンルーム」の使い分けざっくりの思想としては、使い分けは簡単に整理できます。
ただし、フローにも落とし込んでいますが、クリーンルームのほうがエクスチェンジよりも後発であることに注意してください。すなわち、クリーンルームのほうが機能として発展途上の部分が多いです。
外部にデータ共有するときなんて、十中八九、厳格に共有したいに決まってますからね。少なくとも2026年1月現在においては、使い勝手とガバナンスのトレードオフを考慮したうえで最終的なジャッジをするのがいい気がしています。
なお、この記事では表題の通り「クリーンルーム」のほうに焦点を当てて書いていきます。情報量が少ないからこそ、少しでもコミュニティ貢献をしたい！

 クリーンルームでテーブルを共有する流れ
 パブリッシャー側（準備）必要なものは以下のとおり。詳細はこちら参照。
Google Cloud側
Analytics Hub API 有効化
「Analytics Hub 管理者」のロール (roles/analyticshub.admin)
「BigQuery データ編集者」のロール (roles/bigquery.dataEditor)

サブスクライバーのGoogle Cloudサインイン時のメールアドレス

手順
キャプチャ
補足

事前に共有するテーブルを作成しておく

後段でビューを作るが、その自由度と使い勝手が極めてbadなため、先にテーブルを作ってしまうことを推奨

Analytics Hubの画面を開いて「クリーンルームの作成」

クリーンルームの構成

・クリーンルーム名=サブスクライバー側のデータセット名になる
・メールのロギングは基本ONにしておくほうがよさそう（OFFにすると、誰が使っているかが後述の INFORMATION_SCHEMA 等から追えなくなる）

クリーンルームの権限

あとで設定できる項目なのでskipでOK

作成されたクリーンルームをクリック

データを追加していく

ソース、ビュー名、メタデータを設定

・サブスクライバーはここで定義したビュー名を使って クリーンルーム名.ビュー名 でデータをクエリすることになる
・ビューを新規作成するが、ここではカラムのselectしかできない
・作成したビューを配置するデータセットは指定できず、ソースのテーブルと同じデータセット内に自動的に作られる ∴ 既存のテーブル・ビューと名前が重複するとエラーになる
・メタデータに設定した内容はサブスクライブ画面にのみ表示される

分析ルールの選択

・クエリ結果のコピーとエクスポートの許可が設定可能。デフォルトでは許可設定になっているので注意
・分析ルールは、なし（無選択）[3]、「集計」、「差分プライバシー」、「重複リスト」の4種類
・各ルールの詳細は こちらのZenn記事 に詳しくまとまっています

→ 今回は「重複リスト」を選択

・指定したカラムでJOINしたクエリしか発行できなくなるルール
・結合条件に関するプルダウンは2026年1月時点では「すべて」しか選択できない[4]

データを追加

データ追加後に編集可能なのはメタデータとビューでselectするカラムのみ。コピー/エクスポートの許諾や分析ルールなどは変更不可

追加されていたらOK

クリーンルームの画面に戻ってサブスクライバーの権限設定をする

プリンシパルを追加

サブスクライバーのemailを指定して「Analytics Hub サブスクライバー」のロールを付与

追加されたら準備完了

ここまで準備が整ったら、サブスクライバーに以下対応を依頼します。

 サブスクライバー側必要なものは以下のとおり。
Google Cloud側
Analytics Hub API 有効化
「Analytics Hub サブスクリプション オーナー」のロール（roles/analyticshub.subscriptionOwner）
BigQueryでクエリ実行とデータセットの作成が可能な権限 e.g. roles/bigquery.user

クエリ実行のたびにコンピュートコスト💰️が発生する認識

手順
キャプチャ
補足

Analytics Hubの画面を開いて「リスティングを検索」

フィルタのクリーンルームにチェック→作成したクリーンルームを開く

クリーンルーム作成〜リスティングへの反映までの時間はまちまち。秒で反映されることもあれば、10分ぐらい待たないと反映されないケースもあった

サブスクライブするビューを選択

パブリッシャーが設定したメタデータがここで表示される

プロジェクト名を選択して登録（サブスクライブ）

BigQuery Studioに遷移すると、選択したプロジェクト配下にデータセットとビューが作成されている

クエリ実行確認①
select * は実行できない

クエリ実行確認②
joinすれば実行できる

分析ルールでコピーとエクスポートが禁止されているので、「結果の保存」がグレーアウトされて使えなくなっている

!Access Deniedのエラーが出てクエリが実行できないケースがありました。同じソースデータに対して別のデータ（ビュー）を追加して、それをサブスクライブしなおすことで解消したのですが、発生する原因が分かっていません。

 パブリッシャー側（確認＆運用）
 サブスクライバー確認クリーンルームの「サブスクリプション」タブでサブスクライバー一覧が確認できます。

 使用状況確認クリーンルームの「使用状況の指標」タブでサブスクリプション数の推移、ジョブ数が確認できます。

INFORMATION_SCHEMA.SHARED_DATASET_USAGE にクエリを発行すればより詳細を確認可能です。
クエリの例select
  job_id,
  -- ---------------------------------------------
  -- 実行jobの情報
  -- ---------------------------------------------
  job_start_time,
  job_end_time,
  num_rows_processed,    -- 処理された行数
  total_bytes_processed, -- 処理されたクエリサイズ
  -- ---------------------------------------------
  -- サブスクライバー側の情報
  -- ---------------------------------------------
  job_principal_subject, -- パブリッシュ時点でメールのロギングをOFFにしているとnullになる
  job_location,
  job_project_number,
  linked_dataset_id,
  shared_resource_id,
  -- ---------------------------------------------
  -- パブリッシャー側の情報
  -- ---------------------------------------------
  referenced_tables, -- ARRAY<STRUCT> で project_id, dataset_id, table_id が入っている
from
  `region-US`.INFORMATION_SCHEMA.SHARED_DATASET_USAGE
order by
  job_start_time desc
!誰が、いつ、どのぐらいの規模の、というところまでは追えますが、具体的なクエリの内容を追うことはできません。Audit Logでも不可能で、確認した限り、具体的なクエリの内容を追う術は現状ないようです。[5]

思想として、サブスクライバー側で発行したクエリはサブスクライバー側の資産と捉えて、あえてそれが流出しない仕様にしているのだと思われます。

 サブスクリプションの取り消し

手順
キャプチャ

取り消したいemailを選択して「サブスクリプションを取り消す」

取り消し

ステータスが無効になっていたらOK

無効化されたサブスクライバーは直ちにクエリ実行ができなくなり、再度サブスクライブしようとしても以下のようなメッセージが表示されてサブスクライブできなくなっています。
!パブリッシャーによるサブスクリプション取り消しは不可逆で、一度取り消してしまうと、同じアドレスからはそのクリーンルームを再度サブスクライブできなくなっているみたいです。
あまりケースとしては多くないと思いますが、サブスクライバー側から能動的にサブスクリプションを解除したい場合は、リンクされたデータセットを削除すればOKです。

 クリーンルーム自体の削除削除すればOK（雑）

なお、クリーンルームを削除しても、ここ で追加したビュー自体は削除されないので、必要に応じて手動で削除してください。

 クエリテンプレート → 断念前述のとおり、パブリッシャー側はログからサブスクライバーの詳細な行動を追うことができません。そのため、サブスクライバーが悪意をもって情報を抜こうとしていたり、あるいは使い方がわからず困っていたり、そういったことをシステマティックに検知することができません。これらに対する対策として用意されているのがクエリテンプレート機能で、現在Public Previewで機能が提供されています。
https://docs.cloud.google.com/bigquery/docs/query-templates?hl=ja
ただ、残念なことに、現状かなりお粗末です。。。
たとえば、テンプレート機能の核でもある テーブル値関数 (TVF) による動的なテンプレート生成ですが、2025年10月のリリース以降、残念ながらこの記法は無効化されています。
また、テンプレートはたとえパブリッシャー自身が作者であっても、作成→審査→承認というプロセスが必須になるのですが、一度審査に出されたテンプレートは、なんと差し戻しも削除もできません。 たとえば、審査に出したテンプレートが動作しないクエリになっていた場合[6]なんかは、クリーンルームを消さない限り、無用の長物として残し続けるしか選択肢がないです。差し戻しできなくてもいいから、せめて削除だけはさせてほしかった・・・
整備された暁には確実に重要な機能になるので、今後の発展に期待ですね！

 さいごにBigQuery の Analytics Hub でデータクリーンルームを作る手順や関連知識を自分なりにまとめてみました。今後、同じ試みをする誰かの参考になれば幸いです。また、かなり付け焼き刃の知識で書いたため、もし間違ったことを書いていたらご指摘頂けますと幸いです！
マイベストではまだPoC的な位置づけでの利用に留まっていますが、実際に複数のユーザー・企業向けにクリーンルームを作成するとなったときに、どういう粒度でクリーンルームを切り、データセットやテーブルの命名をどうやっていくのか、また現状タグや自由記述欄、有効期限の管理機能等がない中でサブスクリプションの管理をどう徹底していくのかなど、運用観点のGoodプラクティスもぜひ模索していきたいところです。

脚注
公式ドキュメントのタイトルでは "BigQuery Sharing（旧 Analytics Hub）" と記載されていますが、一方でGoogle CloudのUI上だと "共有（Analytics Hub）" というフランス料理みたいな名前で表示されています。ドキュメント内でも表記が揺れてますし、結局国内での正式な名称ってなんなんでしょう？あるあるですが、改名するならするでバツっといってほしいものです。 ↩︎
本当はパブリッシャー側にも「オーナー」と「データ提供者」の区別がありますが、本記事では簡単のためにパブリッシャー = オーナーとして進めていきます。 ↩︎
分析ルールを一度選択してしまうと、分析ルールなしに戻すためには、一度作成をキャンセルしないといけない。不可逆なセレクトボックスとは・・・ ↩︎
けっこうシュールなUIになっています↓
 ↩︎
少し古いですが、2024年8月に同じ質問がGoogle Cloudのコミュニティで行われていて、Noの回答になっていました: Audit queries against a shared table in Analytics Hub ↩︎
一応、作成段階でちゃんと文法エラーは出してくれます。ただ、実際に遭遇した事象として、審査まではpassするが、承認がpassしない、ということが発生しました。 ↩︎

手順	キャプチャ
取り消したいemailを選択して「サブスクリプションを取り消す」
取り消し
ステータスが無効になっていたらOK

マイベストテックブログPublication

株式会社マイベストのテックブログです！採用情報はこちら > notion.so/mybestcom/mybest-information-for-Engineers-8beadd9c91ef4dc2b21171d48a4b0c49

手順	キャプチャ	補足
事前に共有するテーブルを作成しておく		後段でビューを作るが、その自由度と使い勝手が極めてbadなため、先にテーブルを作ってしまうことを推奨
Analytics Hubの画面を開いて「クリーンルームの作成」
クリーンルームの構成		・クリーンルーム名=サブスクライバー側のデータセット名になる・メールのロギングは基本ONにしておくほうがよさそう（OFFにすると、誰が使っているかが後述の INFORMATION_SCHEMA 等から追えなくなる）
クリーンルームの権限		あとで設定できる項目なのでskipでOK
作成されたクリーンルームをクリック
データを追加していく
ソース、ビュー名、メタデータを設定		・サブスクライバーはここで定義したビュー名を使って `クリーンルーム名.ビュー名` でデータをクエリすることになる・ビューを新規作成するが、ここではカラムのselectしかできない・作成したビューを配置するデータセットは指定できず、ソースのテーブルと同じデータセット内に自動的に作られる ∴ 既存のテーブル・ビューと名前が重複するとエラーになる・メタデータに設定した内容はサブスクライブ画面にのみ表示される
分析ルールの選択		・クエリ結果のコピーとエクスポートの許可が設定可能。デフォルトでは許可設定になっているので注意・分析ルールは、なし（無選択）^[3]、「集計」、「差分プライバシー」、「重複リスト」の4種類・各ルールの詳細はこちらのZenn記事に詳しくまとまっています
→ 今回は「重複リスト」を選択		・指定したカラムでJOINしたクエリしか発行できなくなるルール・結合条件に関するプルダウンは2026年1月時点では「すべて」しか選択できない^[4]
データを追加		データ追加後に編集可能なのはメタデータとビューでselectするカラムのみ。コピー/エクスポートの許諾や分析ルールなどは変更不可
追加されていたらOK
クリーンルームの画面に戻ってサブスクライバーの権限設定をする
プリンシパルを追加
サブスクライバーのemailを指定して「Analytics Hub サブスクライバー」のロールを付与
追加されたら準備完了

手順	キャプチャ	補足
Analytics Hubの画面を開いて「リスティングを検索」
フィルタのクリーンルームにチェック→作成したクリーンルームを開く		クリーンルーム作成〜リスティングへの反映までの時間はまちまち。秒で反映されることもあれば、10分ぐらい待たないと反映されないケースもあった
サブスクライブするビューを選択		パブリッシャーが設定したメタデータがここで表示される
プロジェクト名を選択して登録（サブスクライブ）
BigQuery Studioに遷移すると、選択したプロジェクト配下にデータセットとビューが作成されている
クエリ実行確認① select * は実行できない
クエリ実行確認② joinすれば実行できる		分析ルールでコピーとエクスポートが禁止されているので、「結果の保存」がグレーアウトされて使えなくなっている

まえおき

前提知識

やさしい用語解説

「エクスチェンジ」と「クリーンルーム」の使い分け

クリーンルームでテーブルを共有する流れ

パブリッシャー側（準備）

サブスクライバー側

パブリッシャー側（確認＆運用）

サブスクライバー確認

使用状況確認

サブスクリプションの取り消し

クリーンルーム自体の削除

クエリテンプレート → 断念

さいごに

Discussion