Google BigQueryは、テラバイト級のアクセスログや購買履歴、基幹データを「置いておくだけ」で高速に集計できる、Googleのサーバーレスデータウェアハウスです。多くの企業が、まずここにデータを集めました。けれど次にぶつかるのが、「BigQueryの中の数字を、業務側でどう使うか」という壁です。PassworkのBigQueryコネクタは、テーブルの条件付き読み取り・Standard SQLの直接実行・行の書き込み（挿入／キーでのマージ）を、ノーコードのフローで扱えるようにします。DWHを「見るだけの倉庫」から「業務をまわす中継地」へ変えるデータ連携（ETL）を整理します。

01　Google BigQueryとは ── 「ためる」に強いDWH

Google BigQueryは、Google Cloud が提供するフルマネージドのデータウェアハウス（DWH）です。最大の特徴は、サーバーの台数やインデックス設計を気にせずに、数億〜数十億行のデータに対してStandard SQLで集計をかけられること。データの保管とクエリの計算が分離されているため、「とりあえず生ログを全部入れておき、必要なときに必要な切り口で集計する」という使い方に向いています。

使う企業も職種も幅広いのが実態です。ECやアプリ事業者がアクセスログ・行動ログの分析基盤として使い、小売・飲食チェーンがPOSの明細を貯める先として使い、マーケティング部門が各広告媒体のレポートを集約するハブとして使う。Google Analytics 4（GA4）のデータがそのままBigQueryへエクスポートできることもあって、「Webの数字はまずBigQueryに集める」という構成も定番になりました。データエンジニアだけでなく、SQLが書けるマーケター・アナリストが直接触る場面も多いDWHです。

つまりBigQueryは、社内に散らばったデータが最終的に合流してくる「貯水池」になりやすい。だからこそ、そこに溜まった数字をどう動かすかが、データ活用の次の論点になります。

02　BigQueryに溜めた数字が、現場で使われない理由

BigQueryへの集約が進むと、今度はこんな声が現場から上がります。

BigQueryは「集めて、集計する」までは圧倒的に強い一方、その結果を他の業務システムへ受け渡す部分は標準では用意されていません。SQLの実行も、結果のエクスポートも、人が手を動かして初めて進みます。せっかくの貯水池に、水を引き込む管はあっても、外へ送り出す管がない状態です。

もうひとつの論点が、逆方向 ── BigQueryへの書き戻しです。他システムで発生したデータや、加工・集計した結果を、再びBigQueryのテーブルに積み上げていきたい。ここも、アドホックなスクリプトで凌いでいる現場が少なくありません。

Passworkは、この「入口」と「出口」の両方を、ノーコードのフローで扱えるようにします。次章で、具体的に何ができるのかを見ていきます。

03　PassworkのBigQueryコネクタでできること（操作の全体像）

PassworkのBigQueryコネクタが提供する操作は、データを取り出す入力2つと、データを書き込む出力1つです。それぞれを業務の言葉に翻訳すると、次のようになります。

入力：必要なものだけ、ピンポイントで取り出す

テーブル読み取りは、データセットとテーブルを選び、取得したい列と絞り込み条件を指定するだけの、いちばん素直な取り出し方です。条件には等号・不等号のほか、「含む（LIKE）」「リストに含まれる（IN）」「空である／空でない」といった指定ができ、全列を引かずに必要な列だけを選べます。大きなテーブルから日々の差分を引くような用途に向きます。

一方のSQL直接実行は、テーブル読み取りの枠に収まらない集計のための逃げ道です。複数テーブルのJOIN、期間でのグループ集計、ランキング ── こうした「BigQueryだからこそ書ける重い集計」を、そのままのSQLで実行し、結果を後続のノードへ渡せます。「単純な抽出は読み取りで、複雑な集計はSQLで」と使い分けられるのがポイントです。

出力：積み上げと、重複しないマージ

行の書き込みは、他システムから持ってきたデータや加工結果を、BigQueryのテーブルへ戻す操作です。単純に挿入（インサート）して行を積み上げることも、キー列を指定してマージすることもできます。マージを使えば、同じキーの行は更新・新しいキーの行は追加となるため、何度フローを流しても二重行が増えないのが利点です。日次で回す集計テーブルの更新や、外部データのBigQueryへの取り込みで効いてきます。

04　ユースケース ── DWHを業務の中継地にする

操作が分かったところで、実際の連携の形を3つ見ていきます。BigQueryが「見るだけの倉庫」から「業務をまわす中継地」に変わる感覚をつかんでください。

① BigQuery × Salesforce ── 集計スコアを営業の手元へ戻す

ECやSaaS事業で、購買・利用ログはBigQueryに集まっているのに、営業が見るのはSalesforce ── という分断はよくあります。ここで、BigQueryのSQL直接実行で「直近90日の利用金額・ログイン頻度から算出した健全度スコア」を顧客ごとに集計し、その結果をSalesforceコネクタでアカウントへ書き戻します。

営業は普段どおりSalesforceを開くだけで、「スコアが落ちている＝離反予備軍」の顧客に気づけます。分析基盤の知見が、営業の行動に変わる瞬間です。BigQueryで重い集計を担い、Salesforceを現場の窓口にする ── それぞれの強い場所に役割を置く構成です。Salesforce側でどうレコードを取得・Upsertするかは、Salesforce連携 ── 商談・顧客データをSOQLで取り出し、外部キーでUpsertまで自動化するで詳しく解説しています。

② BigQuery × Tableau ── 集計済みテーブルを決まった形で配る

BigQueryの生ログを、毎回Tableauから直接重いクエリで叩くと、ダッシュボードが重くなりがちです。そこで、PassworkでBigQueryのSQL直接実行により日次・週次の集計テーブルを作り、その結果をTableau連携で決まったデータソースへ流し込みます。

Tableau側は軽い集計済みデータを参照するだけになり、表示が速くなります。実際に、集計したデータをTableauにつないで店舗別のロイヤルカスタマー分析・ヘルスチェックを実現したキルフェボン株式会社様の導入事例もあります。さらにこの考え方を一歩進めれば、集計結果をそのままLINEやメール配信へ戻す（リバースETL）こともでき、BigQueryのセグメントが「見る」だけで終わらなくなります。

③ 各システムの数字をBigQueryへ集約し、書き戻す

逆方向の流れも重要です。POSや基幹、各SaaS、あるいは取引先がFTPへ置くCSVから取得したデータを、PassworkのフローでBigQueryへ行の書き込み（マージ）して集約します。キーを指定したマージなら、毎日流しても重複が生まれず、「全社のデータがBigQueryに揃っている」状態を仕組みで維持できます。

こうして整ったBigQueryは、顧客セグメント別の統合分析の土台にもなります。バラバラだった数字が一箇所に集まり、横断で見られるようになる ── これが、DWHを中継地として使う本当の価値です。

05　まとめ：BigQueryに「入口」と「出口」を通す

Google BigQueryは、データを「ためて、集計する」ことにかけては圧倒的に強いDWHです。しかし、その数字を業務側で使うには、外へ送り出す出口と、戻ってくる入口が必要でした。

PassworkのBigQueryコネクタは、その両方をノーコードのフローで担います。

• テーブル読み取りで、必要な列と条件を指定してピンポイントに取り出す
• SQL直接実行で、JOINや集計を含む重いクエリをそのまま走らせる
• 行の書き込み（挿入／マージ）で、結果や外部データを重複なく書き戻す

そして真価は、SalesforceやTableauなど他コネクタとの掛け算にあります。集計はBigQueryで、行動は営業の手元で、可視化はTableauで ── それぞれの強い場所に役割を置き、Passworkがその間を確実につなぐ。こうしてBigQueryは、見るだけの倉庫から、業務をまわす中継地に変わります。