以上、豆知識でした。

まあ、それはともかくとしてもう3月からサマータイムは始まっているので、日本の標準時との時差は-16時間であり、たとえ、太平洋標準時の2025/4/10 00:00に反映されたとしても、日本では10日の夕方の16時以降の反映となります。

そして、大抵は00:00にリリースされることも少ないので、現地時間の午前8時以降だったら日本では翌11日の0時以降の反映となるのです。

ちなみに、もう一つ豆知識というか時差と共にGoogleの各種サービスを使っていく上で注意が必要なポイントがあります。

それは、今回のようなアップデートがソリューション毎に年に数回から場合によっては10回以上あったりするのですが、その予告や発表が、英語版のリリースノートでしかされないことがあるということです。

今回のケースでは、日本の広告主ユーザーには日本語で告知メールが来たのですが、Googleタグマネージャーの「日本語」のリリースノートには、今回のリリースについて何も記述がありません。

一方、Google Tag Managerの「英語」の"Release notes"には、以下の記述があります。

March 10, 2025

Google Tag Manager containers will automatically load a Google tag starting in April 2025

Starting April 10, 2025 containers with Google Ads and Floodlight tags will automatically load a Google tag first, before sending events. We recommend adding the Google tag to your Google Tag Manager container using Initialization - All Pages trigger to preview the impact of these changes on your account(s). This improves the reliability of your Google Ads tracking and will not harm measurement performance. For many users, it will increase the volume of measurement data.

This enables:

• One-click access to features: Turn on features like Enhanced Conversions, Cross-domain tracking, and Autoevents easily from your Google tag settings page.

• Smoother data collection: If you've agreed to our Customer Data Terms of Service, this feature enables "User Provided Data" collection across your events. Your Google tag's settings, like user-provided data, will apply to events sent by Tag Manager the same way they apply to events sent by in-page code.

Google翻訳で日本語に翻訳をすると以下

2025年3月10日

Google タグ マネージャー コンテナは、2025 年 4 月から Google タグを自動的に読み込みます。

2025年4月10日より、Google 広告タグと Floodlight タグを含むコンテナは、イベントを送信する前に Google タグを自動的に読み込みます。アカウントへのこれらの変更の影響を事前に確認するには、 「初期化 - すべてのページ」 トリガーを使用して Google タグを Google タグ マネージャー コンテナに追加することをおすすめします。これにより、Google 広告トラッキングの信頼性が向上し、測定パフォーマンスに悪影響はありません。多くのユーザーにとって、測定データの量が増加します。

これにより、次のことが可能になります。

• ワンクリックで機能にアクセス:拡張コンバージョン、クロスドメイン トラッキング、自動イベントなどの機能を、Google タグ設定ページから簡単にオンにできます。

• よりスムーズなデータ収集：顧客データ利用規約に同意いただいた場合、この機能により、イベント全体で「ユーザー提供データ」の収集が可能になります。Googleタグの設定（ユーザー提供データなど）は、ページ内コードから送信されるイベントと同様に、タグマネージャーから送信されるイベントにも適用されます。

日本語の方のリリースノート更新が、昨年末のリリースで止まってしまっているように見えるのがちょっと心配ですが、何が注意が必要かと言いたいかというと、Googleおよび世界はもうシュリンクしていく日本市場に対してそこまで力（コスト）を割いてくれない＝ローカライズや日本語での情報提供をしてくれない、可能性があるということです。

昔から米国企業内ではファーイーストジャパンと呼ばれるように、アメリカから東を見て、大西洋超えてヨーロッパ、中東、インド、東南アジアなどをさらに超えた東の果ての日本に赴任するっていうのはある意味超絶な辺鄙な土地というイメージだったのかもしれませんが（ていうか西側＝太平洋側で見たら隣やんかというのは置いておいて）、外資企業のアジアの拠点、HQ＝ヘッドクォーターが日本の東京ではなく、シンガポールだったり、ソウルだったりすることも多いなと最近感じていますので、もうこれからはジャパンバッシングからジャパンパッシング、つまりスルーされてしまうことも増えてくるんじゃないかなと思うんですよ。そこで必要になるのが、その企業の本当のHQの言語での発表を見ること。今はテクノロジー企業のほとんどが米国に本社を置いていると思うので、当然ながら英語での発表を見ることが大事なのかなと思います。

って、大分話が脱線してしまいましたが、

本筋に戻るとして、で、今回の変更、大丈夫なの？と言えば、まあ大丈夫です。今まで「設定ミス」で設定意図とは違ってうまく取れていなかったデータを取れるようにGoogleさんがしてくれるというだけなので、よくなっても、悪くなることはないかと。

その辺は、Googleアナリティクス360などの公式リセラーであり、Googleさんにいろいろ直接聞くことが出来るアユダンテさんが詳しく調べて、その内容を公表してくれています。

「Googleタグマネージャー仕様変更：2025年4月からの自動タグ読み込みと実務対応」
https://ayudante.jp/column/2025-03-28/11-00/

アユダンテさんがまとめてくれているように、今回のアップデートはあくまで計測設定ミスのフォローをGoogleさんが自動でやってくれるということで、本来ならば、計測設定ミスは今すぐにでも直したほうが良いというもの。

でも、Univarsal Analytics（UA）が終了する際にも、多くの企業で対応が直前、場合によっては人知れずUAプロパティがGA4プロパティに移行され、そして人知れずUAプロパティが消え去っていったことも多かったのではないでしょうか？

これは、WEBアナリティクスの世界が、計測を始める前の設計や設定は大変だけれども、一度設計設定を終わらせてしまえば、設計設定する人の仕事はほぼ無くなり、あとはほぼデータを見ることが業務になるので初期に設計設定をした人はお役御免になり、どこかに行ってしまう事が多いことが影響しているかと思います。

そして、いつの間にやらデータを見ることすらされなくなり、折角Webページから送信されたユーザーの行動履歴も誰の目にも触れずにGoogleのディスクの肥やしにもならずに2ヶ月から長くても14ヶ月で霧散していくことになります。

おっと、なんかアナリティクス界隈の老人の愚痴のようになってしまいましたが、今回のアップデートは、そんな放置されたアカウントやプロパティでも少しでもデータの精度を良くしたい（Googleがデータをもっと取得して学習するためのデータを集めて効率を上げたい）というGoogleの親心（下心？）なのです。

というわけで、まだ自動アップデートがされていない間の、gtag.jsなどの挙動を保存しておいて、アップデート後の差異を見るためにデータを取得しておきましょう。

昔だったらGoogle Chromeの開発者ツールの画面から一つ一つ構成ファイルやリクエスト情報が記述されたHARを保存していたのですが、今や、生成AIに頼めばあっという間に自動でヘッドレスブラウザを使ってそれを実現してくれるようなコードを生成してくれます。

以下のようなnode.js＋pupperteerで動くコードをMacのターミナルで実行すれば、

const puppeteer = require('puppeteer');

const fs = require('fs');

const path = require('path');

const PuppeteerHar = require('puppeteer-har');

(async () => {

const browser = await puppeteer.launch({ headless: true });

const page = await browser.newPage();

const har = new PuppeteerHar(page);

const urls = [

'https://abc.go2020.tokyo/gtm_gtag_new/index.html',

'https://abc.go2020.tokyo/gtm_gtag_new/index1.html',

'https://abc.go2020.tokyo/gtm_gtag_new/index2.html',

'https://abc.go2020.tokyo/gtm_gtag_new/index3.html',

'https://abc.go2020.tokyo/gtm_gtag_new/index4.html',

'https://abc.go2020.tokyo/gtm_gtag_new/index5.html',

'https://abc.go2020.tokyo/gtm_gtag_new/index6.html',

'https://abc.go2020.tokyo/gtm_gtag_new/index7.html',

'https://abc.go2020.tokyo/gtm_gtag_new/index8.html',

'https://abc.go2020.tokyo/gtm_gtag_new/index9.html',

'https://abc.go2020.tokyo/gtm_gtag_new/index10.html',

'https://abc.go2020.tokyo/gtm_gtag_new/index11.html',

'https://abc.go2020.tokyo/gtm_gtag_new/index12.html'

];

for (let i = 0; i < urls.length; i++) {

const url = urls[i];

const harFilename = path.join(__dirname, `page_${i}.har`);

const resourceFolder = path.join(__dirname, `page_${i}_resources`);

fs.mkdirSync(resourceFolder, { recursive: true });

const resourceCounter = {};

const responseHandler = async (response) => {

try {

const responseUrl = response.url();

if (!responseUrl || responseUrl.startsWith('data:')) return;

const parsedUrl = new URL(responseUrl);

let pathname = parsedUrl.pathname;

let baseName = path.basename(pathname) || 'index.html';

if (resourceCounter[baseName] === undefined) {

resourceCounter[baseName] = 1;

} else {

resourceCounter[baseName]++;

const ext = path.extname(baseName);

const nameWithoutExt = path.basename(baseName, ext);

baseName = `${nameWithoutExt}_${resourceCounter[baseName]}${ext}`;

}

const outputPath = path.join(resourceFolder, baseName);

if (fs.existsSync(outputPath)) return;

const buffer = await response.buffer();

fs.writeFileSync(outputPath, buffer);

console.log(`Saved resource: ${outputPath}`);

} catch (err) {

console.error("Error saving resource:", err);

}

};

// レスポンスリスナーの登録

page.on('response', responseHandler);

await har.start({ path: harFilename });

await page.goto(url, { waitUntil: 'networkidle0' });

await har.stop();

// イベントリスナーを解除（修正箇所）

page.off('response', responseHandler);

console.log(`Saved HAR: ${harFilename}`);

}

await browser.close();

})();

あっという間に、リクエスト内容のHARと構成ファイルが出力され、HARを分析するためのツールも生成AIに任せればものの数分でできてしまいます。

それがこちら

HAR TIMELINE VIEWER

https://abc.go2020.tokyo/HARVIEWER/

先ほどのnode.jsでMacのターミナルで動作するプログラムで出力されたHARをドラッグドロップするとこんな感じ。

1〜12のページは基本的に全ての同じソースですが、別のGTMコンテナのスニペットが入っており、GA4イベントタグとGoogle広告のCV（イベント）スニペット、GA4とGoogle広告のID両方とリンクしたGoogleタグが入っています（11,12はわざと別のIDのものを入れてある）。

ちなみに、テストページのソースも生成AIにサクッと作ってもらい、GTMのコンテナIDを変えた12ページを用意するのも、ターミナルで動作するシェルスクリプトのワンライナーを書いてもらって本当に秒で12ページを作ることができました。

NO	GoogleTag	GTAGタイミング	GA4イベントタグ	GA4タイミング	Google広告CVタグ	G広告タイミング	備考
0							タグマネ実装もなし
1	有	INI	有	PV	有	PV	正常設定
2	有	PV	有	PV	有	PV	不安定かも
3	有	PV	有	INI	有	INI	GA4はNG、G広告は不安定かも
4	有	DOM	有	PV	有	PV	不十分
5			有	PV			GA4イベントのみ実装、不十分
6					有	PV	G広告CVのみ実装、不十分
7	有	PV					GTAGのみ
8	有	INI					GTAGのみ
9							タグマネリクエストだけ
10			有	PV	有	PV	不十分
11	有	INI	有	PV	有	PV	GoogleタグのIDが不正
12	有	INI	有	PV	有	PV	GoogleタグのIDが不正

見ていただくと、１の正常設定と順番だけ変えた２〜４は、大分リクエスト数が異なることがわかると思います。

つまり、それだけ計測可能な内容が減っているということです。

これが今回の対応でどのように変化するか、さあお楽しみに、ということで、日本時間の11日か12日には結果をお伝えしますねー。