Googleタグマネージャーは10月8日にgtagのconfigコマンドの扱いを標準化し、12日にコンテナからの直接送信を加えた ── 自分のコンテナに意図せず発火するタグと二重の計測がないか確かめる13項目（2026年10月時点）

目次

1. 01 何が起きたか — 2026年10月8日と12日、タグマネージャーのリリースノートに「gtag('config')の標準化」と「コンテナからの直接送信」が載った
   1. 公式のリリースノートに書かれた2つの項目
   2. 10月8日の項目 — gtag('config')コマンドの標準化
   3. 10月12日の項目 — コンテナから直接送る
   4. 2つの変更を表にまとめる
   5. 公式のページが書いていないこと
2. 02 なぜ・背景 — 「configを待つ」から「読み込み時に初期化」へ。すべてに反応するトリガーが新しいイベントに当たる
   1. GTMとgtag.jsは、別の部品である
   2. これまで、GTMのスニペットはconfigを認識し、待つことがあった
   3. dataLayerは、タグやトリガーが共有する伝言板である
   4. カスタムイベントのトリガーは、イベント名で当たる
3. 03 この記事に出てくる用語
   1. ワイルドカードのカスタムイベントトリガー
   2. GTMのIDとGoogleタグのID
   3. 送り先（destination）とGoogleタグ
   4. プレビューモードとTag Assistant
4. 04 型別 — 適用範囲・この発表が測っていないこと・確かめる順番
   1. 🅰 適用範囲 — 影響を受けうる構成と、受けにくい構成
   2. 🅱 この発表が測っていないこと
   3. 🅲 手順 — 確かめる5段
   4. 手順1 — ページのソースで、読み込みを数える
   5. 手順2 — GTMのトリガーを一覧にする
   6. 手順3 — プレビューで、gtag.configのイベントを探す
   7. 手順4 — 発火したタグを、意図と照らす
   8. 手順5 — 直接送信の案内を、変更する前に見る
5. 05 明日、自社のサイトで確認できることチェックリスト
6. 06 代替・他の選択肢 — 実装の形ごとに、何が変わるか
   1. 実装のパターンを4つに分ける
   2. どれを選ぶかは、管理の分担で決まる
   3. 確認に使う道具の使い分け
7. 07 当サイトの例 — gtag.jsを直接読む構成だった。GTMは読んでいない
   1. 2026年10月16日に、6ページのソースを数えた
   2. 確かめられていないこと
   3. 数えるのは数分で済む。運用にするかは別の話
8. 08 このテーマの、これまで
   1. 2025年3月10日と4月4日 — Googleタグを先に読み込む動きと、診断の追加
   2. 2026年7月9日 — 読み込みの経路ではなく、IDで挙動が決まる
   3. 2026年10月8日と12日 — 今回の2項目
   4. この記事の説明は、2026年10月16日に確認した時点のものである
9. 09 この記事のまとめ

01 何が起きたか — 2026年10月8日と12日、タグマネージャーのリリースノートに「gtag('config')の標準化」と「コンテナからの直接送信」が載った

公式のリリースノートに書かれた2つの項目

Google Tag Manager（略称GTM）は、サイトに入れたタグ（計測や広告のための小さなプログラム）を、管理画面から追加・変更・公開できるサービスである。公式のヘルプには、変更のたびに日付つきで追記される「リリースノート」があり、2026年10月に2つの項目が加わった。

• 10月8日の項目 — gtag('config')というコマンドの扱いを、GTMのコンテナのスニペットでそろえる（原題: Standardizing gtag('config') command behavior for Google Tag Manager）
• 10月12日の項目 — GTMのコンテナが、Googleの計測製品へデータを直接送れるようになる（原題: Optimizing Google Tag Manager containers）

どちらも、タグが「どの経路で、どの順番で動くか」に関わる変更で、画面の見た目は変わらない。

10月8日の項目 — gtag('config')コマンドの標準化

gtag('config')は、ページの中に書く「Googleタグの設定を始める」命令である。10月8日の項目には、次のように書かれている。

"Google is standardizing the behavior of tagging snippets to ensure consistency, reliability, and high performance across all websites that use the Google tag. With this update, all Google Tag Manager (gtm.js) container snippets will initialize on container load, regardless of any gtag('config') commands."

（訳: Googleは、Googleタグを使うすべてのサイトで一貫性・信頼性・高い性能を確保するため、タグのスニペットの挙動を標準化している。この更新により、すべてのGoogle Tag Manager（gtm.js）のコンテナのスニペットは、gtag('config')のコマンドにかかわらず、コンテナの読み込み時に初期化される。）

続く段落には、ふだんの運用に直接響く文がある。

"These changes to the gtag mean that config commands will now surface in the dataLayer as visible gtag.config events. If your Google Tag Manager containers use wildcard custom event triggers, this change may cause those tags to fire."

（訳: gtagのこの変更により、configコマンドはdataLayerの中で、見える形のgtag.configイベントとして現れるようになる。Google Tag Managerのコンテナがワイルドカードのカスタムイベントのトリガーを使っている場合、この変更によってそれらのタグが発火することがある。）

つまり、これまで見えなかったgtag.configというイベントが、イベントの一覧に出るようになり、すべてのイベントに反応する設定のトリガーが、それに反応してタグを動かすことがある、というのが公式の書き方である。

10月12日の項目 — コンテナから直接送る

10月12日の項目は、データの送り方そのものの変更である。

"This release introduces a new capability to Google Tag Manager containers to send data directly to Google measurement products."

（訳: このリリースは、Google Tag Managerのコンテナが、Googleの計測製品へデータを直接送る新しい機能を導入する。）

"Previously, Google Tag Manager loaded extra javascript (gtag.js) to send data to a Google destination, which could cause latency in measurement transmission."

（訳: これまでGoogle Tag Managerは、Googleの送り先へデータを送るために追加のJavaScript（gtag.js）を読み込んでおり、それが計測データの送信の遅れにつながることがあった。）

同じ項目は、利点として、サイトの表示の高速化、データ収集の改善、設定とアクセス権をコンテナで一元管理できることを挙げている。

2つの変更を表にまとめる

公式のページが書いていないこと

2つの項目を読んでも、分からないことがある。

• 変更が、すべてのコンテナに同じ日に反映されたのか。リリースノートは「With this update（この更新により）」と書いている。一方、設定のヘルプ（出典欄の「Set up your Google tag installation correctly for gtag.js」）は「will soon be updated（まもなく更新される）」と書いている。2つのページで書き方が違い、実際に反映された日はどちらのページからも分からない
• 自分のコンテナで、実際に何件のタグが新しく発火するのか
• 日本語の管理画面での、項目や警告の表示名

02 なぜ・背景 — 「configを待つ」から「読み込み時に初期化」へ。すべてに反応するトリガーが新しいイベントに当たる

GTMとgtag.jsは、別の部品である

公式のヘルプ「Google Tag Manager vs. gtag.js」は、2つを次のように分けている。

"gtag.js is a JavaScript tagging framework that allows you to send data from your site to Google measurement products."

（訳: gtag.jsは、サイトからGoogleの計測製品へデータを送るための、JavaScriptのタグ付けの仕組みである。）

gtag.jsはGoogleの製品へ送る専用で、サイトのコードにスニペットを置いて使う。GTMは、サイトのコードをあまり変えずに、管理画面でタグを増減する仕組みである。今回の変更は、この2つが同じページに同居するときに関わる。

これまで、GTMのスニペットはconfigを認識し、待つことがあった

設定のヘルプには、変更の前の姿を示す一文がある。

"Google Tag Manager (gtm.js) snippets will soon be updated to no longer recognize or wait for any gtag('config') commands."

（訳: Google Tag Manager（gtm.js）のスニペットは、まもなく更新され、gtag('config')のコマンドを認識することも、待つこともなくなる。）

逆に読むと、これまでは、GTMのスニペットがページ内のgtag('config')を認識し、待つことがあった。ここから先は筆者の読みになるが、ページに直接書いたconfigの影響で、GTMの初期化の順番が左右される構成が、実際にあったと考えられる。

dataLayerは、タグやトリガーが共有する伝言板である

dataLayerは、ページの中の情報とイベントを、GTMのタグやトリガーに渡す入れ物である。公式の開発者向けのページは、イベントの送り方を次の形で示している。

dataLayer.push({'event': 'event_name'});

gtag.jsの標準のスニペットは、gtag()という関数を定義し、その中でdataLayerに値を積む。公式が「正しい実装」として示すスニペットには、function gtag(){dataLayer.push(arguments);}という行がある。10月8日の変更は、configコマンドも、他のイベントと同じように、dataLayerのイベントの一覧に見える形で並ぶという意味である。

カスタムイベントのトリガーは、イベント名で当たる

GTMのトリガーは、ページで起きたことを待ち受けて、タグに「今だ」と伝える。公式のヘルプ「About triggers」には、次の一文がある。

"New triggers default to fire on all events for the associated event type."

（訳: 新しいトリガーは、既定では、対応する種類のすべてのイベントで発火する。）

カスタムイベントのトリガーでは、イベント名の欄に名前を書く。「正規表現を使用」にチェックを入れると、名前の欄に正規表現を書ける。ここで、「.*」のような広く当たる書き方をすると、何が起きるかが次の公式の文に書かれている。

"The .* regex means that your trigger will execute on all detected events, including events that Google Tag Manager and Google tag emit automatically. It’s recommended that you use a more restricted regex when using regex matching."

（訳: 「.*」の正規表現は、トリガーが、Google Tag Managerとgoogleタグが自動的に出すイベントを含む、検出されたすべてのイベントで実行されることを意味する。正規表現を使うときは、もっと範囲を絞った正規表現を使うことが勧められる。）

新しく見えるgtag.configは、この「自動で出るイベント」の仲間が1つ増える形である。範囲を絞ったトリガーは、影響を受けにくい。

03 この記事に出てくる用語

ワイルドカードのカスタムイベントトリガー

便利さの面では、イベント名を1つずつ書かずに済む。反対に、イベントが増えるたびに、動くタグも増える。10月8日の項目が名指しで注意しているのは、この構成である。

GTMのIDとGoogleタグのID

公式のヘルプ「Manage tagging behavior using the container ID」は、次のように書いている。

"If your container ID starts with product-specific prefixes like G- or AW-, your container is limited to Google tags."

（訳: コンテナIDが、G-やAW-のような製品ごとの接頭辞で始まる場合、そのコンテナはGoogleのタグに限られる。）

「GTM-」で始まるIDは、第三者のスクリプトや、自分で書いたHTMLのタグも含めて動かせる。2026年7月9日のリリースノートにも、この区別が書かれている。

送り先（destination）とGoogleタグ

公式の「Optimize your Google Tag Manager container」には、管理画面のバナーを使った手順が書かれている。概要ページ上部のバナーから「詳細を確認」を押す、または、設定ページの「Google Destinations」欄から始める、という入口がある。

プレビューモードとTag Assistant

GTMには、公開前に動作を確かめる「プレビューモード」がある。公式のヘルプは、その使いどころを次のように書いている。

"Use the information in the debug interface to find out if tags and triggers fire properly and what data they pass to their respective services."

（訳: デバッグ画面の情報を使って、タグとトリガーが正しく発火しているか、それぞれのサービスにどんなデータを渡しているかを調べる。）

プレビューは、Google Tag Assistantという画面につながって、どのタグが、どの順番で発火したかを見せる。この記事の手順3と手順4で使う。

04 型別 — 適用範囲・この発表が測っていないこと・確かめる順番

🅰 適用範囲 — 影響を受けうる構成と、受けにくい構成

変更の影響は、サイトの構成によって大きく違う。公式の2つのページから読み取れる範囲で、次の3つに分けて考える。

• GTMのコンテナを入れていて、ページ内にgtag('config')も直接書いている構成 — 設定のヘルプが「サポートされない実装」と呼ぶ形に近い。公式は、この形をやめて、gtag.jsの正式なスニペットに置き換えることを求めている
• GTMのコンテナを入れていて、すべてのイベントに当たるトリガーを使っている構成 — 新しいgtag.configイベントで、意図しない発火が起こりうる
• gtag.jsだけを入れている構成、またはGTMだけを入れていてconfigを書いていない構成 — 10月8日の項目が直接に名指ししている形ではない。ただし、実際に影響がないかは、手順で確かめる

🅱 この発表が測っていないこと

リリースノートの2項目からは、自分のサイトの結果は分からない。次の3つは書かれていない。

• 自分のコンテナで、実際に新しく発火するタグがあるかどうか
• 発火が増えたときに、計測の数字が二重になるのか、広告の費用が増えるのか
• 10月12日の「直接送信」を使ったときの、計測の数字の動き

また、Googleは、この変更の影響を受けるコンテナが全体のどれくらいの割合なのかを公表していない（2026年10月16日時点・リリースノートと移行の案内のページで確かめた）。自分のコンテナが多数派なのか少数派なのかは、ここからは分からない。

数字を他人の調査から借りて自分のサイトに当てはめるときの注意は、「+28%」と「+9%」は、同じ調査の、同じプラットフォームの数字だった ── 他人が測った数字を自分のサイトに当てはめる前に確かめる3点にまとめてある。

🅲 手順 — 確かめる5段

手順は、「ページを見る」「コンテナを見る」「プレビューで動かす」「結果を照らす」「直接送信の案内を見る」の5段である。05章のチェックリストは、この順番に並べてある。

手順1 — ページのソースで、読み込みを数える

ページのソースで「googletagmanager.com/gtm.js」「googletagmanager.com/gtag/js」「gtag('config'」を検索し、出現数を書く。gtm.jsとgtag('config'が同じページにあると、公式の言う「サポートされない実装」に近い形である。

手順2 — GTMのトリガーを一覧にする

GTMの管理画面でトリガーを一覧にし、種類が「カスタムイベント」のものを数える。「正規表現を使用」にチェックがあり、イベント名に「.*」や「.+」が入っているものに印を付ける。印の付いたトリガーが、10月8日の項目の注意の対象である。

手順3 — プレビューで、gtag.configのイベントを探す

プレビューモードで自社のトップページを開き、Tag Assistantのイベントの一覧にgtag.configの行が出るかを確かめる。公式のヘルプによると、接続したURLの末尾にデバッグ用のパラメータ（_dbg）が付くので、アドレス欄の変化は異常ではない。

手順4 — 発火したタグを、意図と照らす

gtag.configの行を開き、そのイベントで発火したタグを一覧にする。動かす意図がなかったタグがあれば、そこが原因である。タグの数を書き、設計した覚えのないタグを3つまで担当者に聞く。

手順5 — 直接送信の案内を、変更する前に見る

10月12日の項目に対応する案内が、コンテナの概要ページ上部のバナーに出ることがある。公式の手順では、変更の一覧のプレビューを見てから、ワークスペースに追加する。追加後はプレビューモードで試せて、元にも戻せる、と公式は書いている。

05 明日、自社のサイトで確認できることチェックリスト

以下は、自社のサイトでタグマネージャーを使っている担当者が、10月8日と12日の変更に当たるかを確かめる項目である。1〜2番目はページのソース、3〜6番目はコンテナの中身、7〜10番目はプレビューでの動き、11〜12番目は直接送信の案内、13番目は記録と再確認である。チェックの状態はブラウザに保存され、サーバーには送られない。

• 自社のトップページを開いてソースを表示し、「googletagmanager.com/gtm.js」と「googletagmanager.com/gtag/js」を検索して、それぞれの読み込みの数を書き留める
• 同じソースで「gtag('config'」を検索して回数を数え、gtm.jsを読んでいるページにも1回でもあれば、そのページのURLを書き留める
• 計測の担当者に、サイトに入れている「GTM-」で始まるコンテナと、「G-」「AW-」で始まるタグの数を聞いて、それぞれの数を書き留める
• GTMの管理画面でトリガーを一覧にして、種類が「カスタムイベント」のものを数える
• カスタムイベントのトリガーのうち、「正規表現を使用」にチェックが入っているものを数え、イベント名の欄に「.*」または「.+」を含むものに印を付ける
• 印を付けたトリガーに結び付いているタグを書き出し、各タグが計測・広告・他社のどれに当たるかを1行ずつ書く
• プレビューモードで自社のトップページを開き、Tag Assistantのイベントの一覧に「gtag.config」が出るか、出た回数を書き留める
• gtag.configの行を開き、そのイベントで発火したタグの数を書き留める
• 発火したタグのうち、設計した覚えのないものを3つまで書き出して、担当者に用途を聞く
• 同じプレビューの発火したタグの一覧で、GAのページビューを送るタグが1回の表示で2回以上発火していないか数え、2回以上なら該当のタグの名前を書き留める
• コンテナの概要ページの上部に、コンテナの最適化を案内するバナーが出ているか確認し、出ていれば画面を1枚保存する
• バナーから変更のプレビューを開き、変更の一覧（タグ・送り先・権限）を書き留める（ワークスペースへの追加は押さない）
• 判定・数えた数・日付を1枚にまとめ、変更を公開した日の1週間後に、手順1・2・7をやり直す予定をカレンダーに入れる

06 代替・他の選択肢 — 実装の形ごとに、何が変わるか

実装のパターンを4つに分ける

公式のヘルプが示す内容を、実装の形ごとに整理すると次のようになる。

どれを選ぶかは、管理の分担で決まる

公式の「GTM vs gtag.js」は、Googleタグだけを使う構成を「開発チームをすぐには用意できないマーケティング担当者や、CMSを使うサイトに向く」と位置づけ、GTMを「Googleと他社のタグをまとめて管理する担当者に向く」と位置づけている。この記事の確認は、どちらを選ぶかを決める作業ではなく、今の構成が10月の変更に当たるかを確かめる作業である。

確認に使う道具の使い分け

確認には、次の道具が使える。

• ページのソース — 手順1。読み込みの数を、ログインなしで数えられる
• GTMのプレビューとTag Assistant — 手順3・4。発火の順番と、発火したタグが見える
• ブラウザの開発者ツールのNetworkタブ — 公式の確認手順が使っている。リクエストの送り先が、gtag/jsなのかgtm.jsなのかを見る
• 当サイトの無料ツール — ページ全体の状態を見るなら🔧 サイト総合分析・レポートのツール、ページの重さを測るなら🔧 Lighthouseで最大3ページを監査するツール（利用には無料の会員登録が必要）

07 当サイトの例 — gtag.jsを直接読む構成だった。GTMは読んでいない

2026年10月16日に、6ページのソースを数えた

当サイトでも、この記事の手順1と手順2に当たる確認をした。トップ・解説記事・運営者ブログの記事・無料ツール・サイト紹介・解説記事の一覧の6ページのソースを取得し、HTMLのコメントの中を除いて、読み込みの数を数えた。

数の上では、公式が「正しい実装」の例として示す形（gtag.jsの読み込み1本と、configの記述1回）と同じである。GTMのコンテナは読み込んでいないため、10月8日の項目が名指しする「GTMと、ページ内のconfigの組み合わせ」には当たらないと考えられる。

確かめられていないこと

この確認で分かったのは、ページのソースにある語の数だけである。次のことは確かめていない。

• Tag Assistantで、実際にタグが正しく検出されるか
• 会員画面など、今回の6ページ以外のページの構成
• ページを開いたあとに、スクリプトが別のタグを足していないか

数えるのは数分で済む。運用にするかは別の話

ソースを6ページ数える作業は数分で済んだ。ただ、1回数えたことは、次の変更のときの確認にはならない。公開のたびに数える運用にするかは、まだ決めていない。出力が在るのに誰も測っていなかった例は、出力は在った。だから誰も測らなかった ── datePublished・og:type・用語ハイライト・sitemapで見つけた4つの「値だけ違う」穴で書いた。

08 このテーマの、これまで

2025年3月10日と4月4日 — Googleタグを先に読み込む動きと、診断の追加

2025年3月10日の項目には、4月10日から、Google広告とFloodlightのタグを持つコンテナが、イベントの送信の前に、Googleタグを自動で先に読み込むようになる、と書かれている。2025年4月4日の項目には、タグの診断に「Missing gtag config command（gtagのconfigのコマンドがない）」が加わった、とある。configの扱いは、この流れの中で、少しずつ整理されてきた。

2026年7月9日 — 読み込みの経路ではなく、IDで挙動が決まる

2026年7月9日の項目は、/gtag/jsのような対応していない経路でコンテナを読み込んだときの扱いを直している。

"Containers loaded with a GTM-XXXX ID won’t be restricted, while product-specific ID types like G-XXXX or AW-XXXX will only permit tags and variables provided by Google."

（訳: GTM-XXXXのIDで読み込まれたコンテナは制限されないが、G-XXXXやAW-XXXXのような製品ごとのIDは、Googleが提供するタグと変数だけを許可する。）

2026年10月8日と12日 — 今回の2項目

今回の2項目は、この流れの続きである。10月8日はconfigの扱いの標準化、10月12日はコンテナからの直接送信である。いずれも、タグの経路を、IDとコンテナの側に寄せる方向の変更だと読める。

この記事の説明は、2026年10月16日に確認した時点のものである

この記事に書いた内容は、2026年10月16日に、GTMのリリースノートと関連するヘルプを開いて確認した時点のものである。設定のヘルプの「まもなく」が、いつ「済み」に変わるかは追えていない。数週間後に両方の文面を見直し、変わっていれば01章に追記する。