はじめに
Looker StudioはGoogleが無料で提供しているBIツールです。無料でもかなりの機能が揃っていることで、PoC的に運用を進めていくには非常に便利なものになっています。私もデータ活用の取り組みを小さく始めていくにあたっては、大変重宝しています。
とはいえ、無料のツールである以上、細かい調整はなかなかききにくいのも事実です。今回は、後回しにするとどうしようもなくなる（かもしれない）、Looker Studioの権限についてまとめておきます。
（追記：これらの難しい部分を補完するサービスとしてLooker Studio Proという有償版のサービスも提供されています。）
こんな方におすすめ
- 組織的な／組織をまたいだダッシュボード構築を進めようとしている方
- Looker Studioの利用経験が浅く、先に重要な設定を理解しておきたい方
本記事の内容については、2023/8/8現在の公式ドキュメントの情報に準拠しています。
Looker Studioで重要な2つの権限設定
Looker Studioを使うにあたっての重要な設定として、2つの権限設定があります。それは、
- レポートのオーナー権限
- データソースの認証情報の権限
になります。
前提としてのLooker Studioの構造
本題に入る前に、Looker Studioの構造をおさえておきましょう。基本的な要素としては、以下のようなものがあります。
| 要素 | 概要 |
|---|---|
| レポート | ダッシュボードを利用するときのひとまとまりのもの。Spreadsheetsでいうファイルを想像するとわかりやすい。レポート単位でオーナーが設定されるが、Spreadsheetsのファイル所有者のようなもの。 |
| ページ | レポートのなかの、それぞれの開かれる画面のこと。Spreadsheetsでいうシートを想像するとわかりやすい。 |
| コンポーネント | ページのなかの、それぞれの要素のこと。個々のグラフや文字、図形など。 |
| データソース | グラフのソースとなるデータ元のこと。レポートに埋め込みされる場合と、独立させる場合がある。レポート間でデータソースを再利用したい場合に独立させる。 |
私はTableauの方が利用経験は長いですが、Tableauで言うワークブック、ダッシュボード、ワークシート、データソースという感じですね。
レポートのオーナー権限
では、まずレポートのオーナーです。レポートのオーナーとは、レポートに対するすべての権限を持つユーザーです。Looker Studioでは、レポートを作成するとそのユーザー自身がオーナーになります。
ここまではいいのですが、組織的に／組織をまたいでダッシュボードを運用しようとすると、当然オーナーの譲渡を行いたくなります。その際に重要なのが下記の注記になります。
注: オーナー権限の譲渡は、自身のドメイン内でのみ行えます。Google Workspace と Cloud Identity のユーザーの場合は組織内の別のユーザーに、Google Workspace および Cloud Identity を利用していない標準ユーザーの場合は別の標準ユーザーに譲渡することになります。
（出典：公式ドキュメント「オーナー権限を譲渡する」）
あるユーザーが組織を離れるときは、管理者が Looker Studio のレポートやデータソースを別のユーザーに譲渡することで、重要な情報へのアクセスが失われるのを回避できます。
（出典：同上）
これを踏まえると大事なことが2つ考えられます。
- 組織的に活用する場合：レポートの所有権を組織／チームに付与することができないので、適切にオーナーの譲渡を行っていないと、担当者の退職に伴いダッシュボードが削除されるリスクがある
- 組織をまたいで活用する場合：組織Aの活用するダッシュボードを組織Bが作成すると、オーナー権限が組織Bの担当者に付与されるが、ドメインをまたぐのでオーナーの譲渡が行えない
したがって、特に組織をまたぐようなパターンについては、
- 利用する組織のドメインでアカウントを発行してもらい、そのアカウントで作業をする
- 利用する組織のアカウントでレポートを作成し、編集権限を付与して組織外のアカウントで作業をする
のいずれかの対応が必要になってきます。
ちなみに、組織ではなく個人アカウントではどうなのかについて検証をしてみましたが、
- 個人アカウント→個人アカウント：譲渡可能
- 組織アカウント→個人アカウント：譲渡不可能
- 個人アカウント→組織アカウント：譲渡不可能
という形になっていました。
せっかく作ったダッシュボードが消えるだとか、組織の管理下におけないというのはなかなかよろしくない話ですので、取り扱いには注意して対応しましょう。
ちなみに、独立したデータソースのオーナー権限も、レポートと同一の扱いになります。
データソースの認証情報の権限
次の話として、データソースの認証情報の権限があります。独立したデータソースでも、レポートに埋め込まれたデータソースでも扱いは同一になり、デフォルトはオーナーの認証情報になります。データの認証情報には、次の3つがあります。
- オーナーの認証情報：他のユーザーは、認証情報のオーナーの認証を使ってデータにアクセス可能
- 閲覧者の認証情報：個々のレポート閲覧者の認証情報に基づいてデータにアクセス
- サービス アカウントの認証情報：人間以外のユーザーを表す特別なタイプの Google アカウントに基づいて、データにアクセスするための認証および許可を受けることが可能
ユースケースとしては、
- オーナーの認証情報：データソース自体のアクセス権は付与したくないが、ダッシュボードは見せたい場合
- 閲覧者の認証情報：個々人のアクセス権限に応じてデータを見えるようにしたい場合
- サービスアカウントの認証情報：権限を個人単位ではなく個別に管理したい場合
のようなものが考えられます。
特に注意するのはオーナーの認証情報を利用する場合で、データソースのアクセス権がなくてもデータが見られてしまうので、本来提供してはいけない人にデータを見せてしまうリスクがあります。
次に、組織的に上手く管理しようとすると、サービスアカウントは便利なものではありますが、
- サービス アカウントの認証情報は Google Workspace または Cloud Identity の管理対象組織でのみ使用できます。
- サービス アカウントの認証情報は現在、BigQuery データソースでのみ使用できます。
（出典：公式ドキュメント「データの認証情報」
という制約があります。BigQueryのみになるので、PoC的な活用には若干の使いづらさを感じてしまいます。
Tips：カスタムクエリでのデータ制御
上記に関連して、1つTipsを紹介しておきます。オーナー／閲覧者の認証情報を使う場合、データが見える／見えないの2択になってしまいます。もちろんこれでもある程度のユースケースには対応できますが、細かな対応をしようとすると、カスタムクエリを利用するという方法もあります。
これは、データ抽出の際にカスタムクエリでSQLを書くことで、利用データを個人個人に応じて出し分けるという方法です。カスタムクエリのなかで@DS_USER_EMAILというパラメータを記載すると、利用者のメールアドレスを動的に取得し活用することができます。
（出典：公式ドキュメント「カスタムクエリでパラメータを使用する」
例えば、
SELECT
*
FROM
sales
WHERE
sales-rep-email = @DS_USER_EMAIL
という形で記載すると、利用者の分のみのデータを利用することができます。
ここまでの内容をまとめると、データの閲覧の範囲という観点では、データソースの閲覧権限としてオーナー／閲覧者／カスタムクエリを使い分けることで、適切な制限が求められてきます。また当然ですが、ダッシュボード自体の公開範囲も、指定のアカウントやGoogle Groupのみ／組織内／一般公開と適切に設定するよう注意しましょう。
さいごに
Looker Studioは過去にサービス名がData Portalから変更されたというのもあり、なかなかユーザーの記事が見つかりづらいように感じています。私もハマりかけた部分でしたので、本記事が利用をする誰かの役に立てると嬉しく思います。
追記：Google Workspaceでのユーザー削除とデータの移行
ユーザー削除時のデータの移行について、同僚の情シスの方から有益な情報をいただきました。削除時には以下のような画面となり、オーナー権限を移行できるそうです。
私にはこの画面を見る機会は全くないので、大変参考になりました！