🔏

セキュアなデータ共有を簡便に実現：データクリーンルームで分析ルールの適用が可能になりました

2024/06/07に公開

Google Cloud

BigQuery

tech

はじめに

こんにちは、クラウドエースデータソリューション部の森です。
データソリューション部では、Google Cloud が提供しているデータ領域のプロダクトについて、新規リリースをキャッチアップするための調査報告会を毎週開催しています。
新規リリースの中でも、特に重要と考えるリリースを記事としてまとめ、本ページのように公開しています。

クラウドエースデータソリューション部について

クラウドエースの IT エンジニアリングを担うシステム開発統括部の中で、特にデータ基盤構築・分析基盤構築からデータ分析までを含む一貫したデータ課題の解決を専門とするのがデータソリューション部です。
弊社では、新たに仲間に加わってくださる方を募集しています。もし、ご興味があればエントリーをお待ちしております！

本記事では、2024/04/04 にリリースされた、BigQuery データクリーンルーム（以下、データクリーンルーム）から分析ルールを適用できる機能について紹介します。

リリースの嬉しいポイント

今回のリリースによる嬉しいポイントは以下です。

分析ルールが、データクリーンルームにデータを追加する際に適用できるようになった。
データクリーンルームのコンソールから直接分析ルールを適用できるようになり、これまでクエリで設定していた作業が簡便になった。
既存のデータから、分析ルールを適用した新たなビューを簡単に作成、共有できるようになった。

リリースに関連するサービスの紹介

本セクションでは、以下のサービスについて紹介します。

データクリーンルーム
分析ルール

今回紹介する分析ルールは、BigQuery の機能の一つです。
データクリーンルームは、同じく BigQuery の機能の一つである Analytics Hub に含まれます。
BigQuery や Analytics Hub について詳しくない方は、以下を先にお読みいただくと理解がしやすいかもしれません。

データクリーンルームとは

データクリーンルームは、BigQuery のデータを安全に共有する機能です。
「安全に共有する」とは、共有するデータのコピーやエクスポートといった操作を制限することができることを意味します。

データクリーンルームでは、データを共有するために、データ提供者（パブリッシャー）とデータ利用者（サブスクライバー）の役割が存在します。

データ提供者（パブリッシャー）：データクリーンルームにデータを追加し、サブスクライバーと共有する。
データ利用者（サブスクライバー）：データクリーンルームのデータを参照し、分析することができる。

次に、データクリーンルームに追加できる BigQuery リソース（以下、リソース）を紹介します。
また、データクリーンルームの公式ドキュメントには記載されていませんが、追加するリソースの違いにより、共有されるリソースが変わるため、合わせてご説明します。

データクリーンルームに追加できるリソースは以下です。

テーブル
ビュー（Google Cloud 公式ドキュメントにおける論理ビュー）
- 分析ルールを適用したビュー
- 分析ルールを適用していないビュー
マテリアライズドビュー

上記の「ビュー」は分析ルール（後述）を適用しているかで、追加後に共有するリソースが変わるため、分けて記載しています。

各リソースを、追加した際に共有するリソースは、以下です。

追加するリソース	共有するリソース
テーブル	追加するリソースを参照元とする新規ビュー
分析ルールを適用したビュー	追加するリソースで指定した、分析ルールを適用したビュー
分析ルールを適用していないビュー	追加するリソースを参照元とする新規ビュー
マテリアライズドビュー	追加するリソースを参照元とする新規ビュー

データクリーンルームで「分析ルールを適用したビュー」以外のリソースを追加する際は、「追加するリソースを参照元とする新規ビュー」を作成し、共有します。

データクリーンルームの詳細は公式ドキュメントをご覧ください。
また、弊社にてデータクリーンルームの紹介記事を公開しているため、合わせてご参照ください。

分析ルールとは

分析ルールの説明

分析ルールは、実行できるクエリに制限をかける機能です。
制限をかけることにより、データのプライバシーを向上させることができます。
分析ルールの適用方法は以下の 2 つです。

クエリを使用した分析ルールの適用。
データクリーンルームを使用した分析ルールの適用。

「クエリを使用した分析ルールの適用」は、以下に記載するクエリの privacy_policy に値を設定することで、分析ルールを適用する方法です。

ビューに分析ルールを適用

CREATE OR REPLACE VIEW example_names
  OPTIONS (
    privacy_policy= '{
      "<分析ルール名>": {                   -- 設定したい分析ルール名を記載。
        "<分析ルールオプション 1 >" : <値>,    -- 設定したい分析ルールオプションを記載。
        "<分析ルールオプション 2 >" : <値>
      }
    }'
  )
  AS example;

注意点として、分析ルールはビュー（Google Cloud 公式ドキュメントにおける論理ビュー）にのみ適用可能です。
テーブルや、同じくビューの一つであるマテリアライズドビューに適用することはできません。
そのため、既存のテーブルやマテリアライズドビューのデータ参照を分析ルールで制限するには、データ参照用の新規ビューの作成と、分析ルールの適用が必要です。

もう一方の分析ルールの適用方法である「データクリーンルームを使用した分析ルールの適用」は、後述する「リリース内容」のセクションでご説明します。

続いて、分析ルールが適用されたビューにクエリを実行した場合の動作を以下に記載します。

クエリが分析ルールの条件を満たすと、クエリの実行が成功して結果が出力される。
クエリが分析ルールの条件を満たさないと、クエリの実行が失敗してエラーが出力される。

例として、集計しきい値の分析ルール（後述）を使用する際には、グループ化するクエリを記載する必要があります。

分析ルールの詳細については、公式ドキュメントをご確認ください。

BigQuery で利用可能な分析ルールの説明

記事執筆時点（2024/05/28）では、4 つの分析ルールが提供されています。
ここでは、4 つそれぞれの分析ルールについてご説明します。

集計しきい値分析ルール
差分プライバシー分析ルール
結合制限分析ルール
リスト重複分析ルール

集計しきい値分析ルール

概要
- クエリ内で集計関数を使用することを強制するルール。
詳細
- 種類の少ないデータから個人が特定されることを抑制できる。
  集計しきい値分析ルールを特定の列に適用でき、その列でグループ化した際に効力を発揮する。
  具体的には、ルールが適用された列内で、データの種類数が一定以上の結果のみが出力されるようにする。
使用が想定されるケース
- 特定の種類のデータが少ないために、グループ化しても個人が特定できてしまう可能性がある場合。

差分プライバシー分析ルール

概要
- 差分プライバシー句の使用を強制することによって、差分プライバシー（クエリ出力によって公開される個人情報を制限するもの）を適用できるルール。
詳細
- 差分データから個人が特定されることを抑制する機能。
  クエリ結果にノイズを加えることで、差分データが追加された場合等に、データの有用性を維持したまま、差分データの値が特定されることを抑制する。
使用が想定されるケース
- 差分データの追加が 1 件など、差分の前後比較による特定が可能と思われる場合。

データクリーンルームでの差分プライバシーの活用については Google Cloud blog にて紹介されているため、ご覧ください。
また、弊社にて差分プライバシーの紹介記事を公開しているため、合わせてご参照ください。

結合制限分析ルール

概要
- 特定の列で使用できる結合の種類を制限するルール。
詳細
- 特定の列で、結合を強制・禁止する等、列同士の結合に対する制限をかけられる。
  結合制限の対象列として一度に複数の列を指定できる。
使用が想定されるケース
- 特定列でのみの結合を許可したい場合や、結合を禁止したい場合。

リスト重複分析ルール

概要
- 特定の列で使用できる結合の種類を制限するルール。
  結合制限の分析ルールに似ていますが、他の分析ルールと併用することはできない。
詳細
- クエリ内で INNER JOIN を強制することができる。
  最低一つの列に対して、結合制限分析ルールを設定する必要がある。
  （公式ドキュメントに詳細な記載がないため、Google Cloud コンソール上から確認した結果を元に記載。）
使用が想定されるケース
- INNER JOIN による結合を強制したい場合。

BigQuery で利用可能な分析ルールの詳細は公式ドキュメントをご覧ください。

リリース内容

今回のリリースで、分析ルールが、データクリーンルームにデータを追加する際に適用できるようになりました。

データクリーンルームから分析ルールを適用できるようになったことで、クエリから設定していた分析ルールを、データクリーンルームの Google Cloud コンソールのみで、一括して実装できます。
具体的な使い方は、後述する「実際に分析ルールを使用してみる」のセクションで紹介しています。

分析ルールの適用対象について確認します。
データクリーンルームでは、前述した表（以下）の通り、「追加するリソース」に分析ルールがない場合、「追加するリソース」を参照元とする新規ビューを作成し、共有するのでした。

追加するリソース	共有するリソース
テーブル	追加するリソースを参照元とする新規ビュー
分析ルールを適用したビュー	追加するリソースで指定した、分析ルールを適用したビュー
分析ルールを適用していないビュー	追加するリソースを参照元とする新規ビュー
マテリアライズドビュー	追加するリソースを参照元とする新規ビュー

データクリーンルームの分析ルールは、上記の「共有するリソース」に適用できます。
一方で、分析ルールのない「追加するリソース」に分析ルールは適用できません。

そのため、分析ルールを適用していない既存のリソースは未変更のまま、共有用の新たなリソース（ビュー）のみでプライバシーを高めるといったことが可能です。
また、分析ルールを適用できないテーブルやマテリアライズドビューも「追加するリソース」の対象であるため、「分析ルールの説明」で先述した「データ参照用の新規ビューの作成と、分析ルールの適用」をデータクリーンルームから一括して実装できます。

データクリーンルーム上で分析ルールを追加する機能の料金

分析ルールの適用方法は以下の 2 通りありますが、どちらも無料で利用できます。

クエリを使用した分析ルールの適用。
データクリーンルームを使用した分析ルールの適用。

また、データクリーンルーム上で分析ルールを追加する機能自体の料金も無料で利用できます。

一方で、クエリの実行及び、データの保管費用については BigQuery の料金構成に基づくため、それぞれ以下の形で料金が発生します。

コンピューティング料金
- クエリを実行するプロジェクト側で BigQuery 料金が適用される。
ストレージ料金
- データソースを格納しているプロジェクト側で料金が発生する。

BigQuery の料金構成に基づき、データクリーンルームを利用する場合には、データ提供者（パブリッシャー）側ではストレージ料金が発生します。
データ利用者（サブスクライバー）側では、クエリを実行した場合にコンピューティング料金が発生します。

各サービスの料金の詳細については、以下をご覧ください。

また、BigQuery 料金モデルの違いによる以下の注意点があるため自分がどの料金モデルを使用しているのかを把握しておく必要があります。

データ利用者（サブスクライバー）は、エディション以外のサービスまたは Enterprise Plus エディションを使用していないと、データクリーンルームを使用できない。
分析ルールが設定されているビューに対してクエリする場合には、エディション以外のサービスまたは Enterprise Plus エディションを使用する必要がある。

データクリーンルーム上で分析ルールを追加する機能の制約

データクリーンルーム上で分析ルールを追加する機能に制約はありません。

一方で、データクリーンルームでデータを共有する際の制限事項は把握しておく必要があります。

データクリーンルームから、分析ルールが適用されていない（適用できない）テーブルやビュー、マテリアライズドビューを追加する際に、新規ビューに分析ルールを適用せずに共有できます。
分析ルールを適用せずに新規ビューを共有すると、データ利用者（サブスクライバー）は、新規ビューに記載されたクエリを制限がない状態で実行・閲覧できてしまいます。
そのため、データクリーンルームで共有するデータを追加する際には、分析ルールを適用せずに共有してよいリソースか、分析ルールを設定できているかを確認して追加するようにしましょう。

分析ルール及び、データクリーンルームの制限事項の詳細については、分析ルールの制限事項及び、データクリーンルームの制限事項をご覧ください。

実際に分析ルールを使用してみる

実践内容のサマリは以下となります。

実践する内容の確認
事前準備
データクリーンルームから分析ルールを適用
分析ルールが適用されているかを確認
分析ルールが適用されているビューでクエリを実行

実践する内容の確認

ここからは、以下に記載するデータを共有する上での課題と、共有するデータを元に要件を決め、その要件に沿って実際にデータを共有したいと思います。

課題

とある企業が、BigQuery に格納されている自社の受験者データを、個人が特定されないような形で共有したいが、以下 3 つの課題がある。

受験者の個人情報が出力されないように、受験者以外の項目でのグループ化処理を必須としつつ、受験者の項目ではグループ化処理ができないようにしたい。
受験者が少ない試験のデータは、受験者が特定される可能性が高いため、試験の受験者が 3 人以上のデータのみを閲覧可能としたい。
データを結合する場合には、個人を特定できる情報が入っていない列のみでの結合を許可する。

使用データ（テスト受験者のテーブルデータ）

使用するデータは分析ルールの公式ドキュメントに記載のものを使用します。

CREATE TABLE mydataset.ExamTable AS (
  SELECT "Hansen" AS last_name, "P91" AS test_id, 510 AS test_score UNION ALL
  SELECT "Wang", "U25", 500 UNION ALL
  SELECT "Wang", "C83", 520 UNION ALL
  SELECT "Wang", "U25", 460 UNION ALL
  SELECT "Hansen", "C83", 420 UNION ALL
  SELECT "Hansen", "C83", 560 UNION ALL
  SELECT "Devi", "U25", 580 UNION ALL
  SELECT "Devi", "P91", 480 UNION ALL
  SELECT "Ivanov", "U25", 490 UNION ALL
  SELECT "Ivanov", "P91", 540 UNION ALL
  SELECT "Silva", "U25", 550);

各列の説明は以下です。
- last_name：受験者
- test_id：試験 ID
- test_score：試験成績

これにより作成されたデータのプレビューは以下の画像となります。
use_01

要件

課題及び、使用データを元に要件を整理します。

BigQuery に格納されているテスト受験者のテーブルデータを共有する必要がある。
共有する際には、以下の対応が必要。
1. last_name 列以外でのグループ化処理が必須であり、last_name 列ではグループ化できない。
2. last_name 列の中に異なる値が 3 つ以上ある場合のみ、集計結果に表示する。
3. test_id 列が結合条件の場合のみ、データの結合を許可する。

1. と 2. の要件は集計しきい値の分析ルールを、 3. の要件は結合制限の分析ルールを使用することで、上記要件を満たした形での共有ができそうです。
以降では、検証用の環境を作成していきます。

事前準備

ここでは、分析ルールを適用するための事前準備をします。
作業内容は大きく以下のステップに分かれています。

「データを共有するプロジェクト」と「データを利用するプロジェクト」をそれぞれ準備
共有するデータを準備
分析ルールを適用し、共有するためのデータクリーンルーム環境を準備

また、各種リソースの操作に必要となるロール（権限のセット）の付与及び、API の有効化については、今回紹介したい分析ルールそのものに関わらないため、本記事では割愛しますが、ご了承ください。
割愛した部分も含めたデータクリーンルームの操作方法は、公式ドキュメントをご確認ください。

プロジェクト準備

まずは、以下に記載するプロジェクトを 2 つを用意します。

プロジェクト	用途
プロジェクト A	データクリーンルームにて分析ルールを適用したデータを共有するプロジェクト
プロジェクト B	共有されたデータを利用するプロジェクト

データ準備（プロジェクト A、B）

続いて、プロジェクト A とプロジェクト B の両方にデータを準備します。
データを利用するプロジェクト B でもデータを準備する理由は、結合の検証の際に使用するためです。

データ準備として、BigQuery にデータを用意します。
手順は以下です。

共有するデータを格納するためのデータセットを作成する。
- データセット名：analysis_rules_test
共有するデータ（テーブル）を作成する。
- テーブル名：ExamTable
- 使用するデータは、実践する内容の確認でお伝えした通り、分析ルールの公式ドキュメントに記載のものを使用。

上記のようにデータセットとテーブルを作成すると以下の画像のようになります。
use_02

データクリーンルーム準備（プロジェクト A）

データの準備ができたため、続いてはデータクリーンルームの作成です。

Analytics Hub のコンソールページへ遷移する。
データクリーンルームを作成する。

ここでは、以下の画像のようにデータクリーンルームを設定しました。
use_03

上記画像の赤枠部分にある「クリーンルームの作成」を押下すると、「データクリーンルームの権限 (省略可)」画面が表示されます。
ここでは、データクリーンルームでデータ提供者やデータ提供者を管理するために必要なロール（権限のセット）を設定できます。
今回は、先述した通り、事前に検証に必要な権限を付与しているため、入力を行わずに以下画像の赤枠部分にある「スキップ」を押下します。
use_rev_03

以上で事前準備が完了です。

データクリーンルームから分析ルールを適用（プロジェクト A）

事前準備が完了したため、ここからはデータクリーンルームから分析ルールを適用していきたいと思います。
作業内容は大きく以下のステップに分かれています。

データクリーンルームに追加するデータを選択
分析ルールを適用
設定する内容の最終確認

まずは、データを追加する作業です。
はじめに、データクリーンルームのコンソールから、以下画像の赤枠部分にある「データを追加」を押下し、データを追加する画面に移動します。
画像内に赤枠が 2 つありますが、どちらもデータを追加する画面に遷移します。
use_04

では早速、分析ルールを適用したデータを共有するための設定をしていきましょう。
以下画像のように 3 ステップでデータの公開ができます。
use_05

データを選択（プロジェクト A）

データクリーンルームに追加するデータを設定します。
以下画像の赤枠内にある項目に対して設定をしました。
use_06

以下に、各項目の説明を記載します。

ソースデータ
- データセット：共有するデータが格納されているデータセットを指定する。
- テーブル / ビューの名前：共有するデータが格納されているテーブル / ビューを指定する。
- 公開する列：以下の 2 項目のうち、いずれかを指定する。
  - すべての列を使用する：ソースデータに指定したデータのすべての列を使用する。
  - 公開する列をカスタムで選択する：ソースデータに指定したデータの特定の列を使用する。
    最低でも 1 列は指定する必要があり、すべての列を指定することも可能。
新しいビューの保存
- ビュー名：新規作成されるビューの名前を記載する。
メタデータ
- メインの連絡先：連絡先の担当者アドレスを記載する。
- 説明（省略可）：共有するビューの説明を記載する。

設定が完了したら、コンソール左中央の「次へ」を押下します。

分析ルールを適用（プロジェクト A）

共有する際の分析ルールを適用します。
今回のケースで求められる以下 3 つの要件を満たすために、どの分析ルールをどのように設定するかを考えてみます。

last_name 列以外でのグループ化処理が必須であり、last_name 列ではグループ化できない。

last_name 列の中に異なる値が 3 つ以上ある場合のみ、集計結果に表示する。

test_id 列が結合条件の場合のみ、データの結合を許可する。

1. と 2. については、グループ化処理と列の中に異なる値が 3 つ以上の要件を満たすことが可能な集計しきい値分析ルールを使用します。
要件を元に、以下に使用する分析ルールと設定値を記載します。

分析ルール：集計しきい値分析ルール
対象列：last_name
出力に反映されるしきい値：3 以上

3. については、データの結合を許可の要件を満たすことが可能な結合制限分析ルールを使用します。
要件を元に、以下に使用する分析ルールと設定値を記載します。

分析ルール：結合制限分析ルール
対象列：test_id
結合を含まないクエリの実行可否：結合処理の記載がない場合でもクエリの実行は可能。

上記で整理した内容を元に、以下画像の赤枠内の項目を設定しました。
use_07

2 つの赤枠の内容をそれぞれ見ていきましょう。
まずは、ルールの種類を指定する部分です。
use_08
ここでは、[集計 / 差分プライバシー / 重複リスト] の 3 つの分析ルールのうち、いずれかが指定できます。
今回は、集計しきい値分析ルールを使用するため、集計を選択しています。
また、ここでは設定できない結合制限分析ルールの設定方法は以下で説明します。

続いて、列に対する設定部分を確認します。
use_09
上記画像では、2種類の分析ルールが設定されているため、それぞれ青枠及び、緑枠として分けて説明します。

青枠：集計しきい値分析ルールの対象となる列及び、しきい値を設定する項目。
- 対象列：last_name
  - last_name 列を対象にする。
    指定された列は、グループ化処理ができない。
- しきい値：3
  - データ種類数が、3 以上の結果の場合のみ出力に反映する。
緑枠：結合制限分析ルールの対象となる列及び、結合条件を指定する項目。
- 対象列：test_id
  - test_id のみで結合を可能に制限する。
- 結合条件：「結合は必要ありません」
  - 結合処理の記載がない場合でもクエリを実行可能にする。

以上で、分析ルールの入力が完了したため、画面赤枠の「次へ」ボタンを押下して完了させます。
use_rev_01

設定する内容の最終確認（プロジェクト A）

これまでに入力した設定内容を確認します。
設定内容に問題がなければ、赤枠の「データを追加」を押下し、データの追加が完了です。
use_10

分析ルールが適用されているかを確認（プロジェクト A）

データクリーンルームへのデータの追加により、新たなビューが作成されているため、ビューの情報を確認したいと思います。

BigQuery Studio からビューの詳細を確認したところ、新たに share_view が作成されており、ビューの情報の赤枠部分から、分析ルールで設定した内容が反映していることが確認できました。
use_11

分析ルールが適用されているビューでクエリを実行（プロジェクト B）

プロジェクト A から共有されたデータを、プロジェクト B で使用し、分析ルールに従ったクエリのみを実行できるのかを検証します。

共有されたデータを登録する（プロジェクト B）

プロジェクト A から共有されたデータを、プロジェクト B で使用できるように登録します。

まずは、プロジェクト A に作成したデータクリーンルーム名をコピーします。
続いて、プロジェクト B に移動し、BigQuery Studio を開きます。
BigQuery Studio の左上にある「＋追加」を押下し、開いたサイドパネルから「Analytics Hub」を選択します。
use_12

Analytics Hub の検索ページが開いたら、コピーしていたデータクリーンルーム名で検索し、対象のデータクリーンルームを選択します。
use_13

プロジェクト A にて作成したデータクリーンルームであれば、左上の「登録」を押下します。
use_14

「クリーンルームへのプロジェクトの追加」ページに移動後、宛先プロジェクトがプロジェクト B であることを確認し、左下の「登録」を押下します。
use_rev_02

これにより、新たなデータセットが BigQuery Studio に登録されます。
以下画像の赤枠内のように、手順で追加したデータクリーンルーム（今回だと clean_room_analysis_rules_test）が表示されており、その下に共有されたビュー（share_view）が表示されていれば、プロジェクト A から共有されたデータを、プロジェクト B で利用できる状態となります。
use_15

分析ルールが適用されたテーブルへクエリを実行（プロジェクト B）

要件に基づいた形でクエリの実行が制限されているかを確認しましょう。

集計しきい値分析ルールの検証（プロジェクト B）

検証の目的は、以下の要件が満たせているか確認することです。

last_name 列以外でのグループ化処理が必須であり、last_name 列ではグループ化できない。
last_name 列の中に異なる値が 3 つ以上ある場合のみ、集計結果に表示する。

まずは、集計しきい値分析ルールが適用されたビューに対して、データの全件を取得するクエリを実行してみます。
クエリ内容と実行結果は以下です。

SELECT *
FROM clean_room_analysis_rules_test.share_view

/*         実行結果         */
You must use SELECT WITH AGGREGATION_THRESHOLD for this query because a privacy policy has been set by a data owner.

You must use SELECT WITH AGGREGATION_THRESHOLD for this query because a privacy policy has been set by a data owner. というエラーが出ました。
これは、集計しきい値（AGGREGATION_THRESHOLD）ルールが適用されているが、クエリがルールに則っていないため、エラーになっている状態です。

改修したクエリと実行結果を以下に記載します。
今回のクエリでは、AGGREGATION_THRESHOLD 句を用いて、test_id を出力するクエリを記載しています。

- SELECT *
+ SELECT WITH AGGREGATION_THRESHOLD
+  test_id,
FROM clean_room_analysis_rules_test.share_view

/*         実行結果         */
You must use GROUP BY or aggregation function in a SELECT WITH AGGREGATION_THRESHOLD query, but it was absent at [2:3]

You must use GROUP BY or aggregation function in a SELECT WITH AGGREGATION_THRESHOLD query, but it was absent at [2:3]
今度は、グループ化または集計関数を使用する必要があるとして、エラーが出ています。

クエリを改修し、test_id 列と last_name 列をグループ化するクエリに改修し、test_id ごとのテスト受験者数を出力するクエリを実行してみます。

  SELECT WITH AGGREGATION_THRESHOLD
    test_id,
+   COUNT(DISTINCT last_name) AS student_count,
  FROM clean_room_analysis_rules_test.share_view
+ GROUP BY test_id, last_name;

/*         実行結果         */
You cannot GROUP BY privacy unit column when using SELECT WITH AGGREGATION_THRESHOLD.

You cannot GROUP BY privacy unit column when using SELECT WITH AGGREGATION_THRESHOLD.
AGGREGATION_THRESHOLD 句を用いる場合、集計しきい値分析ルールで指定した列では GROUP BY することができないとエラーが出ています。
この結果から、集計しきい値分析ルールで指定した列である last_name 列ではグループ化できないことが確認できました。

再度クエリを改修し、今回のクエリでは、test_id でグループ化し、test_id ごとのテスト受験者数を出力するクエリを記載しています。

SELECT WITH AGGREGATION_THRESHOLD
  test_id,
  COUNT(DISTINCT last_name) AS student_count,
FROM clean_room_analysis_rules_test.share_view
- GROUP BY test_id, last_name;
+ GROUP BY test_id;

/*         実行結果         */
/*---------+---------------*
 | test_id | student_count |
 +---------+---------------+
 | P91     | 3             |
 | U25     | 4             |
 *---------+---------------*/

クエリが成功し、結果が出力されました。

このことから、AGGREGATION_THRESHOLD 句と、グループ化を用いることでルールが正しく設定されており、ルールに則っていないクエリは失敗することを確認できました。

続いて、last_name 列の中に異なる値が 3 つ以上ある場合のみ、集計結果に表示する。についても確認します。
集計しきい値分析ルールが適用されているビューでは、上記クエリ結果にて 2 行出力されていることが確認できています。
では、集計しきい値分析ルールが適用されていないソーステーブルでのクエリと実行結果はどうでしょうか。

SELECT
  test_id,
  COUNT(DISTINCT last_name) AS student_count,
FROM analysis_rules_test.ExamTable
GROUP BY test_id;

/*         実行結果         */
/*---------+---------------*
 | test_id | student_count |
 +---------+---------------+
 | C83     | 2             |
 | P91     | 3             |
 | U25     | 4             |
 *---------+---------------*/

それぞれの実行結果を確認すると、
集計しきい値分析ルールが適用されていないソーステーブルでは、student_count（last_name の一意の数）が 2 の行も出力されましたが、
集計しきい値分析ルールが適用されているビューでは、student_count が 3 以上の行のみが出力されることを確認できました。

以上で、下記の要件を満たしていることを確認できました。

last_name 列以外でのグループ化処理が必須であり、last_name 列ではグループ化できない。
last_name 列の中に異なる値が 3 つ以上ある場合のみ、集計結果に表示する。

結合制限分析ルールの検証（プロジェクト B）

最後に、結合制限分析ルールが有効かについて確認します。
検証の目的は、要件の 3. である test_id 列が結合条件の場合のみ、データの結合を許可する。が満たせているか確認することです。

今回の設定では、test_id 列のみで結合でき、それ以外の列は結合できない状態のはずです。
集計しきい値分析ルールで使用したクエリを改修し、test_id での結合文を加えました。

分析ルールの適用されたビューに対して実行したクエリと実行結果を以下に記載します。
クエリ内の INNER JOIN で使用されている ExamTable は、データ準備の際にプロジェクト B に作成したテーブルです。

SELECT WITH AGGREGATION_THRESHOLD
  test_id,
-  COUNT(DISTINCT last_name) AS student_count,
+  COUNT(DISTINCT share_view.last_name) AS student_count,
FROM clean_room_analysis_rules_test.share_view
+  INNER JOIN analysis_rules_test.ExamTable USING (test_id)
GROUP BY test_id;

/*         実行結果         */
/*---------+---------------*
 | test_id | student_count |
 +---------+---------------+
 | P91     | 3             |
 | U25     | 4             |
 *---------+---------------*/

エラーになることなく、結合処理が完了しました。

続いて、test_id 列以外の列も加えた結合を試してみます。

SELECT WITH AGGREGATION_THRESHOLD
  test_id,
  COUNT(DISTINCT share_view.last_name) AS student_count,
FROM clean_room_analysis_rules_test.share_view
-  INNER JOIN analysis_rules_test.ExamTable USING (test_id)
+  INNER JOIN analysis_rules_test.ExamTable USING (test_id, last_name)
GROUP BY test_id;

/*         実行結果         */
Join occurring on a restricted column.

Join occurring on a restricted column.
制限された列で結合が発生しているというエラーが出ました。
その他様々に試した結果、以下の場合に同じように Join occurring on a restricted column. となりました。

last_name のみでの結合。
test_score のみでの結合。
test_id での結合と、test_score での結合の組み合わせ。
test_id での結合と、test_score での結合と、last_name での結合の組み合わせ。

これにより、要件の 3. である test_id 列が結合条件の場合のみ、データの結合を許可する。を満たしていることが確認できました。

以上で、データクリーンルームから分析ルールを適用することにより、今回設定した以下の要件をすべて満たした形で、データを共有できていることが検証できました。

BigQuery に格納されているテスト受験者のテーブルデータを共有する必要がある。

共有する際には、以下の対応が必要。

last_name 列以外でのグループ化処理が必須であり、last_name 列ではグループ化できない。

last_name 列の中に異なる値が 3 つ以上ある場合のみ、集計結果に表示する。

test_id 列が結合条件の場合のみ、データの結合を許可する。

まとめ

今回は、データクリーンルームの分析ルールが適用できるようになった機能について紹介しました。
プライバシー保護の観点から、データの共有に課題を感じている場合には、本機能の利用を検討してみてはいかがでしょうか！