Looker Studio でダッシュボードを作り、社内に配っている分析担当の方向けの記事です。閲覧者が AI に質問できるようになったいま、AI が違う計算式で答える事故を防ぐために、今月どこを整えればよいかが分かります。読み終わると、自社のレポートを「質問できる状態」にしてよいかを、3つの条件で点検できるようになります。
この記事で分かること
- Looker Studio が Data Studio に名前を変え、会話型分析が一般提供になった経緯
- 質問から回答までを5つの段階に分けたとき、Data Studio・BigQuery（Google Cloud のデータ分析用データベース）・Snowflake（Snowflake 社が提供するクラウド型のデータ分析基盤）がそれぞれどこまで担っているか
- 数字のずれを防ぐための3条件（指標定義の一元管理・接続元の棚卸し・回答の記録）と、今月やる作業
- MySQL（広く使われているデータベースの一種）5.6/5.7 に関する期限など、既存レポートの持ち主が知っておくべき日付
ざっくり：Looker Studio は Data Studio になり、質問できるようになった
Google Cloud のリリースノートによると、2026年4月16日付で Looker Studio は Data Studio に名前が変わりました（Data Studio リリースノート）。名称変更を単独で説明する公式の告知ページは、筆者の調査では見つかりませんでした。
続いて2026年7月30日に、Data Studio の Conversational Analytics（会話型分析。グラフを眺める代わりに、文章で質問すると AI が表やグラフで答えてくれる機能）が GA（一般提供。試験段階を終えて正式に提供されている状態）になりました（同リリースノート）。筆者が日付から計算すると、名称変更から GA までは105日、GA から今日（10月28日）までは90日です。
閲覧者は「先月の売上の内訳は？」とレポートに直接聞けるようになります。問い合わせが減る可能性がある一方、AI が「売上」をどの式で求めたかを閲覧者は確かめにくいという心配も生まれます。
なぜ重要か：数字がずれる原因は「指標定義の置き場所」
「売上」という言葉ひとつでも、税込か税抜か、返品を引くか引かないかで数字は変わります。ダッシュボードなら作った人が計算式を固定していますが、AI は質問のたびに式を組み立てます。正しい定義がどこにも置かれていないと、毎回違う式で答えるおそれがあります。
このように、指標の名前と計算式を1か所にまとめて AI や BI ツールに渡す仕組みを セマンティック層（データに「意味」を与える層。「売上＝この列の合計から返品を引いたもの」といった約束事を集めた場所）と呼びます。数字のずれを防げるかどうかは、このセマンティック層をどこに置き、誰が管理するかで決まると考えられます。
質問できるレポートの仕組み：質問から回答までの5段階
質問してから数字が返るまでを、筆者は次の5つの段階に分けて整理しました。図1のとおり、どの段階がずれても、最後に返る数字はずれます。
途中の SQL（データベースからデータを取り出すための命令文）は AI が自動で書きます。参照する定義があいまいだと、AI は列の名前などから計算式を推測するしかありません。
分析：3製品は5つの段階をどこまで担っているか
Data Studio、BigQuery、Snowflake の3製品について、最近のリリースノートを5つの段階に当てはめました。結果は図2と次の表のとおりです。表の「確認できず」は、リリースノートの範囲では記述を見つけられなかったという意味で、機能がないと確かめたわけではありません。
| 段階 | Data Studio 会話型分析 | BigQuery 会話型分析 | Snowflake |
|---|---|---|---|
| 質問受付 | GA（2026/7/30） | GA（6/23）、複数プロジェクト横断の会話が GA（10/14） | Cortex Agent SDK が Preview（10/13） |
| 指標定義の管理 | 確認できず | カスタム用語集が Preview（2/24） | Semantic Studio が GA（9/30） |
| SQL 生成 | 確認できず | 確認できず | 確認できず |
| 実行（接続先） | PostgreSQL のプライベート IP 接続（9/24）、BigQuery Graph（10/22）、コネクタ16件 | 複数プロジェクトの全データソース | 確認できず |
| 記録（ログ・出力） | 確認できず | 会話ログ保存が GA（10/26）、PDF/CSV 出力が GA（10/15） | 確認できず |
出典は各社のリリースノート（記事末尾に一覧）です。実行の行に書いた Data Studio の接続先は Data Studio 全体のもので、会話型分析からそのまま使えるかはリリースノートで確認できていません。Preview（試験提供。仕様が変わる可能性がある段階）と GA を区別して書いています。
表に出てくる言葉も補足します。SDK（ソフトウェア開発キット。開発者が自社のアプリに機能を組み込むための部品一式）、PostgreSQL（MySQL と並んで広く使われているデータベースの一種）、プライベート IP（インターネットに公開せず、組織の内部ネットワークだけで使う接続先の番号）、BigQuery Graph（BigQuery のデータを、点と線のつながりとして問い合わせる機能）です。
筆者が数えると、記述を確認できた段階は Data Studio が5つ中2つ（うち1つは上の注意つきの接続先）、BigQuery が5つ中4つ、Snowflake が5つ中2つでした。ここから分かるのは、指標定義の管理は Snowflake（9月30日）、回答の記録は BigQuery（10月26日）で、それぞれ先に GA の機能が出たということです。質問の受け付けは Data Studio（7月30日）・BigQuery（6月23日、BigQuery リリースノート）ともに GA になっており、接続先の拡大は Data Studio で進んでいます。
参考までに、Data Studio とは別製品の Looker 本体の会話型分析は、LookML（Looker 本体で指標や結合のルールを書くための言語）のモデルから SQL を作る仕組みだと説明されています（Looker の Conversational Analytics）。定義を先に書いておく考え方の一例ですが、Data Studio に同じ機能があるとは読み替えないでください。
時期：10項目のうち9件がこの32日間に集中
図3は、本記事で取り上げた10項目を時間順に並べたものです。筆者が数えると、7月が1件、9月が4件、10月が5件でした。9月24日から10月26日までの32日間に、10件のうち9件が入っています。
これは本記事が選んだ項目の偏りで、各社のリリース頻度全体を示すものではありません。なお、BigQuery 会話型分析そのものの GA（6月23日）は図3の期間より前なので、10項目には数えていません。それでも、会話型分析と接続まわりの変更が重なったこの1か月は、運用を見直す区切りになると考えられます。
条件1：指標定義を一元管理する
1つ目の条件は、「売上」「CV」などの計算式を1か所にまとめ、変更の履歴を残すことです。CV（コンバージョン。購入や問い合わせなど、サイトの目的が達成された数）のように部署ごとに意味が揺れやすい指標ほど、先に決めておく必要があります。
参考になるのが Snowflake の Semantic Studio です。2026年9月30日に GA となり、セマンティックビュー（指標の定義をまとめたもの）を YAML（設定を人が読み書きしやすい形で書くテキスト形式）で直接編集して Snowflake に反映できます（Snowflake リリースノート）。さらに Git（ファイルの変更履歴を記録する仕組み）で版を管理し、定義の変更を追跡できると説明されています。
Data Studio の会話型分析で、同じように定義を一元管理する機能があるかは、リリースノートでは確認できませんでした。そのため Data Studio を使う場合は、まず手元で「指標定義表」を作るのが安全です。指標名・計算式・データソース・決めた人・変更日の5列があれば、問い合わせ時の照合にも使えます。
BigQuery 側では、2026年2月24日に会話型分析の エージェント（質問を受けてデータを調べ、答えを返す AI の担当役）向けの カスタム用語集（社内の言葉の意味を AI に教える辞書）が Preview になりました（BigQuery リリースノート）。筆者が日付から計算すると、今日まで246日たっていますが、GA になったという記述は確認できていません。
条件2：接続元を棚卸しする
2つ目の条件は、レポートの接続先を洗い出すことです。同じ「売上」を別々のデータソースから出していると、AI がどちらを使うかで答えが変わるおそれがあります。
2026年9月24日には、Data Studio にパートナーコネクタ（Google 以外の会社が作った接続部品）が16件追加されました（Data Studio リリースノート）。リリースノートには種類の分類がないため、筆者が用途で分けたのが図4と次の表です。
| 分類（筆者分類） | 件数 | 該当するコネクタ |
|---|---|---|
| 広告 | 5 | Facebook Ads Analytics、Nextdoor、AppLovin、Facebook Ads、快客-Microsoft Ads 串接 |
| 検索・SEO・サイト分析 | 4 | SEOmonitor、SimilarWeb、Google Search Console、Mangools AI Search Watcher |
| EC・在庫・業務管理 | 3 | Cin7 Core AppiWorks、Amazon Vendor Central、Contractors Cloud |
| メール・SMS配信 | 2 | Attentive、CleverReach |
| CRM・営業 | 2 | Salesforce、Leadinfo |
| データベース | 0 | なし |
Nextdoor を広告に、Contractors Cloud を業務管理に入れたのは筆者の判断で、別の分け方もありえます。この分類では、広告・検索・配信のマーケティング系が16件中11件（68.75%）を占めました。データベースへの接続の改善は、コネクタではなく、Cloud SQL（Google Cloud がデータベースの運用を代行するサービス）上の PostgreSQL へのプライベート IP 接続（9月24日）や BigQuery Graph への接続（10月22日）という形で来ています。
Search Console のコネクタは、3月9日（Porter Metrics 提供）と9月24日（Data Bloo 提供）にパートナー製が追加されています。どれを使ったレポートかを書き出しておくと、数字が食い違ったときに原因を探しやすくなります。
期限：MySQL 5.6/5.7 の新しいデータソースは2027年2月26日以降作れない
同じ9月24日のリリースノートでは、MySQL 5.6 または 5.7 に接続する 新しいデータソース は、2027年2月26日以降は作成できなくなると告知されました（Data Studio リリースノート）。筆者が計算すると、今日から期限まではあと121日です。
ここで書かれているのは「新しく作れなくなる」ことだけです。すでにあるデータソースやレポートがその後どう扱われるかは、リリースノートでは確認できませんでした。棚卸しの際に MySQL の版を確かめ、5.6/5.7 なら移行の計画を期限より前に立てておくのが安全側の対応です。
条件3：回答の記録を残す
3つ目の条件は、AI が何を聞かれ、何を答えたかを後から確認できるようにすることです。記録がないと、間違った数字が会議資料に貼られても、どの質問から生まれたのかをたどれません。
BigQuery では、会話型分析の 会話ログ（質問と回答のやり取りの記録）の保存が2026年10月26日に GA になり、ログはエージェントのプロジェクト内の BigQuery テーブルに保存されます（BigQuery リリースノート）。ただし、テーブルの項目や保存期間はリリースノートに書かれておらず、筆者は確認できていません。10月15日には、エージェントの回答（文章・グラフ・表・引用を含む）を PDF や CSV に出力する機能も GA になりました。
Data Studio の会話型分析で同様のログを残せるかは、リリースノートでは確認できませんでした。その場合は、会議などで使った回答を、質問文・日付・数字とあわせて共有の記録表に残してもらう運用が考えられます。
導入手順：既存ダッシュボードから段階的に切り替える
3条件を導入前のチェック表にまとめたのが図5です。1つずつ埋めてから閲覧者を広げるほうが、ずれた数字が出回る範囲を小さくできます。
| 条件 | 確認する問い | 確認方法 | 足りないときの対処 |
|---|---|---|---|
| 指標定義の一元管理 | 売上・CV の計算式が1か所に書かれているか | 計算フィールドとデータソースを一覧にして、定義表と照合する | 定義表を作り、変更履歴を残す（Git やスプレッドシート） |
| 接続元の棚卸し | 同じ数字を出すデータソースが複数ないか、古い MySQL はないか | レポートごとの接続先を書き出す | 重複を1つにまとめる。MySQL 5.6/5.7 の移行計画を2027年2月26日より前に立てる |
| 回答の記録 | AI の回答を後から確認できるか | 回答を保存する手段があるかを確かめる | BigQuery 会話型分析なら会話ログ保存と PDF/CSV 出力、Data Studio は運用で記録表を用意する |
具体的な進め方は次のとおりです。
- 問い合わせの多いダッシュボードを1つ選ぶ
- そのダッシュボードで使っている指標を書き出し、指標定義表を作る
- 接続しているデータソースを一覧にし、重複と MySQL の版を確かめる
- 回答を記録する方法を決める
- 一部の閲覧者にだけ質問機能を案内し、答えた数字を定義表と照らし合わせる
- ずれがなければ、対象のダッシュボードと閲覧者を広げる
つまずきやすい点
閲覧者が質問できる範囲を、Data Studio 側で絞れるかは分かっていません。 筆者の調査では、Data Studio の会話型分析で質問の範囲を制限する設定があるかを確認できませんでした。
Looker 本体の文書には、管理画面で機能ごとにオン・オフできるといった説明がありますが（Looker の Conversational Analytics）、別製品なので当てはめられません。範囲を絞りたい場合は、最初に案内する閲覧者を限ることで対応するのが現実的です。
BigQuery の横断会話は、権限の広さがそのまま答えの範囲になりえます。 2026年10月14日に、複数のプロジェクトの全データソースを対象にした会話の作成が GA になりました（BigQuery リリースノート）。便利な反面、どのプロジェクトまで見えるかを事前に確かめておかないと、想定外のデータから答えが作られると考えられます。
まとめ
- 指標定義の管理は Snowflake、回答の記録は BigQuery で、先に GA の機能が出ました。Data Studio 単体ではリリースノート上、定義の管理と記録を確認できませんでした。
- だからこそ Data Studio で質問を開放する前に、指標定義表と回答の記録表を手元の運用で用意しておくのが安全です。
- MySQL 5.6/5.7 の新しいデータソースは2027年2月26日以降作れなくなるため、接続元の棚卸しと一緒に移行計画を立てておきましょう。