GTMの2025年8月1日付リリースノートで、新しいカスタムテンプレート用JavaScript APIが発表されました。
その名もreadAnalyticsStorage。これによりGA4のクライアントIDやセッションIDといった情報を、GTMのカスタムテンプレート内で手軽かつ安全に読み取れるようになります。
■ GoogleアナリティクスのクライアントIDとセッション情報とは？
まずは前提として、GA4のクライアントIDとセッション情報について簡単に整理しておきましょう。
クライアントID: ウェブサイト訪問者ごとに割り当てられる匿名の識別子です。GAではユーザーを識別するために、各訪問者のブラウザにクライアントIDというランダムなIDを保存しています。これにより、同じユーザーが再訪したかどうかを追跡できます。
セッションID: ユーザーの訪問ごとのセッション（訪問単位）を識別するIDです。GAではユーザーがサイトに訪れてから離脱するまでを1つのセッションとして扱い、セッションごとにIDや開始時間が記録されます。さらに何回目のセッションかを表すセッション番号（累計訪問回数）も保持されています。
これらの情報は通常、クッキーという仕組みを使ってユーザーのブラウザに保存されています。
GA4（Google アナリティクス4）の場合、_gaという名前のクッキー（プロパティごとに _ga_XXXX のようなクッキー）にクライアントIDやセッション情報がエンコードされた形で含まれます。例えばクライアントIDはクッキーの値の中に埋め込まれ、セッションごとのデータも一緒に保持されています。
■ 従来の課題: クッキー解析の必要性とその問題点
これまで、このクライアントIDやセッションIDを取得したい場合、開発者は自力でクッキーの値を解析する必要がありました。つまり、document.cookieから_gaクッキーの値を読み取り、文字列を分解してクライアントIDやセッション番号を取り出すようなカスタムコードを書く必要があったのです。これはいわばクッキーの「逆エンジニアリング」です。 しかし、この方法には大きな問題がありました。それはGoogle側でクッキーのフォーマットが変わると途端に動かなくなるリスクです
。
実際、Googleアナリティクスのクッキー形式は過去に変更されたことがあり、突然これまでの解析手法が通用しなくなるケースが発生しました。 例えばGA4では、2025年5月頃にクッキーの形式が大きく変更されています。旧来のクッキー値はGA1.2.123456789.987654321のようにドットで区切られたシンプルな形式でしたが、新しい形式ではGS2.1.s1823456789$o2$g1$t1823456890$j1$l1$h1といった複雑な文字列に変わりました。
この変更により、従来のパーサー（クッキー解析コード）は正しく動かなくなり、多くのトラッキングやデータ連携に支障をきたす可能性がありました。
具体的な影響としては、クライアントIDやセッションIDをクッキーから直接取得していた仕組みが気付かないうちにデータを取り逃したり、あるいはオフライン計測やサーバーサイド連携が破綻したりする恐れがあります。
このようにクッキーの形式に依存した実装は非常に不安定で、Google アナリティクス側のアップデートに振り回されてしまう問題があったのです。
GTMカスタムテンプレートとサンドボックスAPIとは？
ここで今回の主役であるreadAnalyticsStorage APIの話に入る前に、GTMのカスタムテンプレートとサンドボックスAPIについて簡単に説明します。
GTMカスタムテンプレート: GTMでは、ユーザーが独自のタグや変数のテンプレートを作成できます。これをカスタムテンプレートと呼びます。例えば、GTMに標準搭載されていない第三者の計測タグを組み込む際に、自分でテンプレートを作って使うことが可能です。カスタムテンプレートを使うと、毎回カスタムHTMLを埋め込むより安全かつ簡潔にタグを管理でき、コミュニティギャラリーで共有もできます。
サンドボックス化されたJavaScript (Sandboxed JS): カスタムテンプレート内で動くJavaScriptコードは、GTMによってサンドボックス（隔離環境）で実行されます。他のページ上のスクリプトから独立しており、GTMが提供する特定の機能（API）のみ利用可能という制限があります。これはGTMがセキュリティや安定性を確保するための仕組みです。カスタムテンプレート内ではrequire(‘機能名’)という形で、GTM側が用意したAPIを呼び出して様々な操作を行います。
このrequireで使える機能群がサンドボックスAPIです。
つまり、GTMのカスタムテンプレートを作成する際には、Googleが公式に用意したAPIを使ってブラウザ上の情報取得や動作をさせることができます。例えば「現在のページURLを取得するgetUrl」や「クッキーを書き込むsetCookie」など様々なAPIがあります。その中に今回新しく加わったのがreadAnalyticsStorageです。
新API readAnalyticsStorage の概要と使い方
readAnalyticsStorageは、GA4のクライアントIDおよびセッション情報を取得するための専用APIです。
カスタムテンプレート内でこのAPIを呼び出すことで、GAのクッキーに保存されたクライアント識別情報を簡単に取り出せます。
取得できるデータ: readAnalyticsStorage()を実行すると、クライアントIDと現在のセッション情報のオブジェクトが返ってきます。
具体的には、戻り値のオブジェクトは以下のような内容を含んでいます:
client_id: GAで使用されているクライアントID（文字列）。
sessions: 現在のセッションに関する情報オブジェクトの配列。通常、1つのGA測定ID（GA4のプロパティ）につき1要素ですが、複数の測定IDを運用している場合は複数含まれることもあります。それぞれのオブジェクトには次のフィールドがあります：
measurement_id: 測定ID（GA4の「G-XXXX」のID）を示す文字列。
session_id: 現在のセッションを識別するタイムスタンプ（文字列）。セッション開始時刻などを表します。
session_number: 当該ユーザーが何回目のセッションかを示す番号（数値）。例えばこの値が3なら、そのユーザーにとって3回目の訪問セッションという意味です。
このように、クッキー内の必要な部分を分解して見やすい形で返してくれるのがreadAnalyticsStorageです。
開発者は自分で文字列操作をしなくても、オブジェクトのプロパティ経由で欲しい値（クライアントIDやセッションID等）を直接取得できます。
使い方（コードのイメージ）:
カスタムテンプレートのコード内では、他のサンドボックスAPIと同様にまずrequireで機能を読み込み、それから関数を実行します。例えば以下のようなJavaScriptコードになります。
const readAnalyticsStorage = require(‘readAnalyticsStorage’);
const analyticsData = readAnalyticsStorage();
// 取得したクライアントIDやセッション情報を利用
const clientId = analyticsData.client_id;
const sessions = analyticsData.sessions;
なお、readAnalyticsStorageはオプションで特定のクッキープレフィックスやドメインを指定することもできます。
標準的な設定ではその必要はありませんが、例えば複数のドメインでCookieを共有している場合や、カスタムのクッキー名を使っている場合にオプションを渡すことで対応できます。
権限設定: GTMカスタムテンプレートでは、使用するAPIに応じて必要な権限（Permissions）をテンプレートに宣言する必要があります。readAnalyticsStorageを使う場合、テンプレートの権限にread_analytics_storage（Analyticsストレージの読み取り）を追加する必要があります。
これはテンプレートエディタ上でチェックボックスをオンにする形で設定できます。適切な権限設定を行うことで、テンプレートがクッキー情報にアクセスすることをGTMが許可します。
■ 新APIがもたらすメリット
readAnalyticsStorageの導入により、GTMユーザーや開発者には次のようなメリットが生まれます。
安心・安定: 公式APIを使うことで、GA側の変更に振り回されにくくなるのが最大の利点です。Googleがクッキーの内部構造を変更しても、readAnalyticsStorage自体がアップデートに追随してくれるため、こちらのコードを直す必要がありません。
いわゆる将来への耐性（future-proof）が高まります。
実装の簡略化: 複雑な文字列操作やパーサーを書く必要がなくなり、コードがシンプルになります。誰が見ても明確に「クライアントIDを取得している」とわかるため、実装ミスも減るでしょう。また、GTMのテンプレート内で完結するので他のスクリプトに頼る必要もありません。
データ活用の幅が拡がる: クライアントIDやセッションIDを容易に取得できることで、マーケティングや分析の高度な施策に活用しやすくなります。後述するように、オフラインコンバージョン計測との連携やカスタム分析など、これまでハードルが高かった実装も取り組みやすくなるでしょう。
■ どんな場面で役立つのか？活用シナリオの例
いくつか例を紹介します。
オフラインコンバージョン計測との連携: ウェブ上で取得したクライアントIDを使って、オフラインのコンバージョンデータ（例えば実店舗での購入やコールセンターでの契約など）を後からGAに送信するといったケースがあります。
これを行うには、ユーザーのクライアントIDをWeb上で取得して保存しておき、後でそのIDとコンバージョン情報を紐付けてGAのMeasurement Protocolで送信する必要があります。
readAnalyticsStorageを使えば、GTMからこのクライアントIDを簡単に取得できるため、オフラインデータとの統合がスムーズになります（実際、公式ドキュメントの例でも取得したclient_idを使ってsendOfflineEventするコードが示されています）。
カスタマージャーニー分析やユーザー識別: クライアントIDはユーザーをまたいだ分析に使えるキー情報です。サイト内の動きを独自に追跡したり、CRMシステムのユーザーデータと付き合わせたりする際にも、このIDが利用できます。従来はページ上に埋め込んだGAコードから取得したりクッキーを直接読んだりと苦労しましたが、GTMのカスタムテンプレートで取得できるようになれば、より一貫した方法でデータ収集と活用が可能になります。
セッションベースのカスタムトリガーやロジック: セッション番号やセッションIDを利用して、「ユーザーの訪問〇回目にだけ発火するタグ」を作る、といったアイデアも考えられます。例えば新規訪問（セッション番号1）時にはウェルカムメッセージのタグを発火させるが、リピート訪問時には別の処理をする、といったセッション情報に基づくカスタムロジックをGTMで実装できるようになるかもしれません。
以上のように、readAnalyticsStorageが提供するクライアントID・セッション情報は、マーケティングの高度化やサイト改善のための様々なシナリオで活用可能です。GTM初心者の方でも、「こういうことができるんだ」と今後の学習や施策のヒントにしていただければと思います。
まとめ
GTMの新API readAnalyticsStorageは、Google アナリティクスの重要な識別情報（クライアントID・セッション情報）を公式に安全に取得できる手段として登場しました。これにより、これまで課題だったクッキー解析の苦労や不安定さから解放され、より信頼性の高い実装が可能になります。
コメント