GTMとCRM・BigQuery連携で気をつけるセキュリティの落とし穴｜未経験から100日後にGTMのプロになる話【Day 35】

GTMは単体でも便利ですが、BigQueryやCRM、スプレッドシートといった他のツールと繋げることで、取得したデータを実際の意思決定や施策に活かせるようになります。ただし、繋ぎ方によっては重大なセキュリティリスクや、実運用での破綻を招くやり方もあるので、そこを正確に押さえておきます。

BigQuery連携は安全な選択肢

GA4の「管理」→「BigQueryのリンク」からプロジェクトを紐付け、データエクスポートを有効にするだけで、GA4のイベントデータをBigQueryに送れます。この連携はGoogleのサーバー間で完結するため、ブラウザ側で追加のコードを書く必要はありません。Day15で扱ったUNNESTを使ったクエリで、SQLベースの詳細分析ができます。

CRM連携を「ブラウザから直接」やってはいけない理由

ここが今日一番強調したい点です。GTMのカスタムHTMLタグから、ブラウザのfetch()で直接CRMのAPIエンドポイントにデータを送るような実装を見かけることがありますが、これは避けるべきです。理由は主に2つあります。

• 認証情報の露出：CRMのAPIを呼ぶには通常APIキーなどの認証情報が必要ですが、これをブラウザ側のJavaScriptに書いてしまうと、サイトを見ている誰でもソースコードや開発者ツールから認証情報を読み取れてしまいます。
• CORSで実際には動かないことが多い：多くのCRM APIはサーバー間通信を前提に設計されており、ブラウザからの直接アクセスを許可するCORSヘッダーを返しません。実装しても、ブラウザのコンソールにCORSエラーが出て送信できない、というオチになりがちです。

顧客データをCRMに連携したい場合の正しい構成は、Day29で扱ったサーバーサイドGTMを経由するか、あるいはそもそもGTM（ブラウザ側の仕組み）を使わず、フォーム送信を受け取った自社サーバーが裏側でCRMのAPIを呼び出す、というサーバー間の連携にすることです。ブラウザから直接、認証情報付きでサードパーティAPIを叩く実装は、見つけ次第まず疑ってかかってください。

スプレッドシートへのログ送信は「本番用」ではなく「検証用」と割り切る

Google Apps Script（GAS）をウェブアプリとして公開し、全ページビューのたびにfetchでログを送る実装も紹介されることがありますが、GASには1日あたりの実行回数やURL Fetch呼び出しの上限があります。それなりのアクセス数があるサイトで「すべてのページビュー」をトリガーにしてしまうと、あっという間にクォータに達し、正式な計測基盤としては成立しません。デバッグ中に少数のイベントを目視で確認したい、といった限定的な用途にとどめておくのが実態に即した使い方です。

今日のまとめ

BigQueryとの連携はサーバー間で完結するため安全ですが、CRMのようにブラウザから直接叩きたくなる連携ほど、認証情報の露出とCORSの壁に注意してください。本格的な外部システム連携は、サーバーサイドGTMかバックエンド間の連携に任せるのが正攻法です。次回は、GTMの最新機能とアップデート情報を扱います。