Gemini in BigQuery Studioで複数プロジェクトの分析を効率化する

はじめに：プロジェクトが増えると、データが迷子になる

中小ECや個人事業でデータ活用を続けていると、GCPプロジェクトやデータセットがいつの間にか増えていきます。

「本番のEC受注データはこのプロジェクト」「GA4のエクスポートは別プロジェクト」「広告費の取り込みはさらに別」——最初はきれいに分けたつもりでも、半年も経つと「あの集計、どのデータセットを参照していたっけ」と分からなくなりがちです。

一人で運用していると、自分の頭の中にだけ「どこに何があるか」の地図がある状態になりやすく、その地図は時間とともに少しずつ薄れていきます。久しぶりに触ったときに思い出すコストは、意外とばかになりません。

プロジェクトやデータセットの分割そのものは悪いことではありません。権限の切り分けやコスト管理の観点では、むしろ分けておいたほうが安全です。問題は、分けた結果として「全体像を把握する手間」が増えることにあります。分けたこと自体ではなく、分けたあとの見通しの悪さが課題なのです。

この記事では、BigQuery Studio と Gemini の支援機能を組み合わせて、複数プロジェクトにまたがるデータを横断的に探索し、分析を効率化する考え方を整理します。

対象として想定しているのは、専任のデータエンジニアがいない中小規模の現場です。プロジェクトを増やしたのは自分自身で、管理も自分、分析も自分——そんな「一人データ基盤」のような状況でも回せる、無理のない進め方を意識してまとめました。

なお、Gemini まわりの機能名やUIは更新が早い領域です。具体的な操作手順や画面の名称は、必ず最新の公式ドキュメントで確認してください。この記事は「どう使うと楽になるか」という運用の視点を中心にまとめています。

BigQuery Studio で横断的に探索する

BigQuery Studio とは

BigQuery Studio は、BigQuery のデータ分析作業を一つの画面でまとめて行えるワークスペースです。SQL の実行はもちろん、データの探索やノートブック的な作業まで、同じ場所で進められます。

複数プロジェクトを扱ううえでありがたいのは、自分が閲覧権限を持っているプロジェクトやデータセットを、同じエクスプローラ上から横断的にたどれる点です。プロジェクトごとにコンソールを切り替えなくても、「このプロジェクトのこのテーブル」「あちらのプロジェクトのあのテーブル」を行き来しながら作業できます。

地味な利点ですが、ブラウザのタブをいくつも開いて行ったり来たりする手間が減るだけでも、横断分析のストレスはかなり下がります。とくに「あのテーブル、どっちのプロジェクトだったか」を探す時間は、積み重なると無視できません。一つの画面で完結するというのは、それ自体が作業効率に直結します。

まず「どこに何があるか」を把握する

横断分析の第一歩は、自分がアクセスできる範囲の地図を作ることです。

エクスプローラのツリーを目で追うのも一つの方法ですが、対象が増えてくると目視では追いきれません。そこで役立つのが INFORMATION_SCHEMA です。プロジェクトやデータセット単位で、テーブルの一覧やサイズ、最終更新日などをクエリで取り出せます。

-- 特定データセット内のテーブル一覧とサイズを確認する例
-- ※ region 名やデータセット名は自分の環境に合わせて置き換えてください
SELECT
  table_schema,
  table_name,
  total_rows,
  ROUND(total_logical_bytes / POW(1024, 3), 2) AS size_gb
FROM
  `your_project`.`region-asia-northeast1`.INFORMATION_SCHEMA.TABLE_STORAGE
ORDER BY
  size_gb DESC;

こうした「棚卸し」をしておくと、後述の Gemini への質問もぐっと的確になります。INFORMATION_SCHEMA を使ったコストや利用状況の把握については、BigQueryのコストをINFORMATION_SCHEMAで監視する話で詳しく触れています。

棚卸しの結果は、できればスプレッドシートやノートブックにメモしておくことをおすすめします。「このプロジェクトには受注系」「こちらは計測系」といった対応関係が一覧になっているだけで、後から自分が見返すときにも、ほかの人に引き継ぐときにも役立ちます。データ基盤の運用は、こうした地味なドキュメント化の積み重ねで楽になっていきます。

Gemini アシストの活用例

BigQuery Studio には、Gemini による支援機能が組み込まれています（一部は提供状況やプランによって異なります）。複数プロジェクトを扱う場面で、特に効いてくる使い方をいくつか紹介します。

1. 自然言語でクエリのたたき台を作る

「先月のプロジェクトAの受注テーブルから、商品カテゴリ別の売上を出したい」——こうした要望を自然言語で伝えると、Gemini が SQL の候補を提案してくれます。

複数プロジェクトを扱っていると、テーブル名やカラム名を正確に覚えているとは限りません。うろ覚えの状態でも、まず日本語で意図を伝えてたたき台を出してもらい、そこから直していくほうが速いことが多いです。

自然言語からの SQL 生成そのものの精度や使いどころは、BigQueryで自然言語からSQLを生成するGeminiの実力でも検証しています。あわせて読むと、どこまで任せられるかの感覚がつかめると思います。

2. 「このテーブルは何者か」を素早く理解する

別プロジェクトのテーブルを初めて触るとき、いちばん時間がかかるのは「このテーブルが何を表しているのか」を理解する工程です。

Gemini には、データセットやテーブルの中身を要約し、説明や利用のヒントを提示してくれる機能があります。カラムの意味や、どんな分析に使えそうかの当たりをつけるのに役立ちます。

ただし、生成された説明はあくまで補助です。特に金額やステータスを表すカラムは、実データを数行見て自分の理解と一致するか確認することをおすすめします。

たとえば「金額」と書かれたカラムが税込なのか税抜なのか、「ステータス」の数値がそれぞれ何を意味するのかは、説明文だけでは確定できません。Gemini の要約で当たりをつけ、実データと突き合わせて確証を取る——この二段構えにしておくと、別プロジェクトのテーブルでも安心して扱えるようになります。

3. データソースを文脈に加えて質問する

複数のデータソースを文脈（コンテキスト）に加えたうえで、自然言語でやり取りできる仕組みも用意されています。

たとえば「受注テーブル」と「商品マスタ」を文脈に入れておき、「この2つをどう結合すれば商品名つきの売上が出せるか」と尋ねる、といった使い方です。プロジェクトをまたいだテーブルを組み合わせる際の「最初の一歩」を、会話で詰めていけます。

大事なのは、Gemini に丸投げするのではなく「自分が何を知りたいか」を言語化する道具として使うことです。意図が曖昧なまま投げると、出てくる答えも曖昧になります。

4. 探索の過程そのものを残す

複数プロジェクトをまたいだ分析は、一回の質問で答えが出ることは少なく、たいていは「まず全体を見て、気になった点を掘り下げて、別の切り口で確かめる」という試行錯誤の連続になります。

この過程を、思いつくたびに別々のクエリで散発的にやってしまうと、後から「どういう順番で何を調べたのか」が分からなくなります。BigQuery Studio では、こうした探索の流れを一つの作業空間にまとめて残せます。分岐させながら複数の仮説を並行して試し、あとで見返せるようにしておくと、自分の思考の足あとがそのまま記録になります。

横断分析は「最終的な数字」だけでなく「そこに至った経緯」も資産です。とくにチームで運用している場合、過程が残っていると、ほかの人が同じ調査を一からやり直さずに済みます。

横断クエリで気をつけること

複数プロジェクトをまたぐクエリは便利な反面、独特の落とし穴があります。最低限おさえておきたい3点を挙げます。

リージョン（ロケーション）をそろえる

BigQuery では、原則として同じロケーションにあるデータ同士でないと結合（JOIN）できません。

たとえば一方のデータセットが asia-northeast1（東京）、もう一方が US にあると、そのまま JOIN しようとしてエラーになります。複数プロジェクトを横断する前に、対象データセットのロケーションが一致しているかを確認しておきましょう。ずれている場合は、データのコピーや転送でロケーションをそろえる対応が必要になります。

新しくデータセットを作るときは、組織内でロケーションの方針を決めておくと、後々この問題に悩まされにくくなります。日本向けのサービスなら asia-northeast1 に統一しておく、といったシンプルなルールで十分です。あとから直すのは手間がかかるので、最初に決めておく価値があります。

権限を確認する

横断クエリを動かすには、参照するすべてのプロジェクト・データセットに対して、自分（または実行するサービスアカウント）が適切な閲覧権限を持っている必要があります。

スケジュールクエリやノートブックから定期実行する場合は、実行主体となるアカウントの権限が足りているかを特に注意してください。手元では動いたのに自動実行で失敗する、というケースの多くは権限の問題です。

複数プロジェクトをまたぐ構成では、必要な権限を最小限にとどめつつ、横断分析に必要な範囲だけを過不足なく付与する設計が理想です。とはいえ最初から完璧を目指す必要はなく、まずは「読めない・動かない」を解消し、運用しながら少しずつ絞り込んでいけば十分です。

コストの出どころを意識する

複数プロジェクトをまたぐクエリでも、課金されるのは基本的にクエリを実行したプロジェクトです（オンデマンド課金の場合、スキャンしたデータ量に応じて課金されます）。

別プロジェクトの巨大なテーブルを SELECT * でうっかりフルスキャンすると、想定外のコストにつながります。横断分析を始める前に、

必要なカラムだけを選ぶ
パーティションやクラスタリングで読む範囲を絞る
試行時はプレビューや LIMIT ではなく、見積もり（ドライラン）でスキャン量を確認する

といった基本を徹底しておくと安心です。コスト監視の仕組みづくりは、前述の INFORMATION_SCHEMA の記事も参考にしてください。

とくに自然言語で生成したクエリは、内部でどれだけのデータを読むのかが直感的につかみにくいことがあります。Gemini に作ってもらった SQL でも、実行前にドライランでスキャン量を確かめる習慣をつけておくと、「便利に使っていたら月末のコストが跳ねていた」という事態を防げます。便利さとコスト感覚は、セットで持っておきたいところです。

まとめ

プロジェクトやデータセットを分けて運用すること自体は、権限やコストの観点で理にかなっています。問題になるのは「分けた結果、全体が見えにくくなる」ことでした。

その手間を減らすうえで、BigQuery Studio と Gemini の支援機能は相性が良い組み合わせです。要点を整理します。

BigQuery Studio で、権限のある複数プロジェクトを同じ画面から横断的にたどる
まず INFORMATION_SCHEMA で「どこに何があるか」を棚卸ししておく
Gemini には、自然言語でのクエリ生成・テーブルの要約・複数ソースを文脈にした質問を任せる
ただし生成結果は鵜呑みにせず、金額やステータスは実データで検算する
横断クエリでは リージョン・権限・コスト の3点を必ず確認する

Gemini はあくまで「探索を速くする道具」であり、最終的に何を信じて意思決定するかは人の仕事です。道具に任せる部分と、自分で確かめる部分の線引きをはっきりさせておくと、複数プロジェクトの分析もずっと扱いやすくなります。

最初から大きな仕組みを作り込む必要はありません。まずは手元のプロジェクトを一つ棚卸しし、Gemini にひとつ質問を投げてみるところから始めれば十分です。小さく試して、効きそうなところだけ広げていく——そのくらいの距離感が、無理なく続けるコツだと感じています。

機能名やUIは変わりやすいので、実際に手を動かす際は最新の公式ドキュメントを必ず確認してください。