Google Tag Manager（GTM）のコンテナタグは、<head> 要素の中の、できるだけ上部に設置するのが正解です。Google 公式ドキュメントが「<head> 内のなるべく上の位置」と明示しており、dataLayer の早期初期化や同意モードの動作要件を満たすためにも、この配置が前提となります。
この記事では、なぜ <head> 上部設置が推奨されるのか、他の位置に置いたときに何が起きるのか、そしてページ速度や Core Web Vitals への影響を分解して整理します。WordPress での実装ポイントと、当サイトで実際に位置を最適化したときの落とし穴も併せて解説します。
GTM を head 上部に置くべき 3 つの理由
「なんとなく head 内に入れておけば動く」と思われがちですが、設置位置が違うと取りこぼしや誤計測が発生します。<head> 上部に置くべき理由は次の 3 点です。
1. Google 公式が「head 内の可能な限り上部」と明言している
Google Tag Manager のヘルプセンター（Install Google Tag Manager）には、コンテナスニペットの設置場所として「Place the first part of the code as high in the <head> of the page as possible（コードの 1 つ目の部分はページの <head> 内のできるだけ上に配置する）」と明記されています。Google が公式に推奨している唯一の配置位置はこの 1 つです。
SEO・解析タグの設置で迷ったとき、公式ドキュメントの推奨を外す合理的な理由はほぼありません。GA4 を GTM 経由に移行する場合も、この位置が出発点になります。
2. dataLayer を早期初期化してタグの取りこぼしを防ぐ
GTM の中核は window.dataLayer という配列です。各種タグ（GA4 イベント、コンバージョン計測など）は、この dataLayer に push されたデータを受け取って発火します。GTM スニペットが読み込まれる前に dataLayer に push が走ると、その値は通常記録されません。
例えばページ内に「ユーザー属性をサーバーサイドレンダリング時に dataLayer へ書き出す」コードが含まれている場合、GTM が後ろにあるとその値を拾えません。<head> 上部に置けば、他のスクリプトが動き出す前に dataLayer の受け皿が用意されるため、取りこぼしが防げます。
3. 同意モード（Consent Mode v2）の前提を満たす
Google の同意モード v2（Consent Mode v2）は、Cookie 同意の状態を GTM 経由で広告・解析タグに伝える仕組みです。同意モードの仕様では「ページ読み込みのできるだけ早い段階」でデフォルト同意状態を宣言することが求められます。GTM 自体が <head> 上部にないと、同意宣言が遅れ、Google 広告のスマートビッディングなどに使われる「Consent Mode シグナル」が欠損します。
設置位置 3 パターンの違い
GTM コンテナタグは実装現場でしばしば次の 3 か所に置かれます。それぞれの違いを比較表にまとめます。
| 設置位置 | 発火タイミング | 取りこぼしリスク | 同意モード対応 | 公式推奨度 |
|---|---|---|---|---|
<head> 上部 | 最も早い | 低い | ○ | ◎ 公式推奨 |
<head> 下部（</head>直前） | やや遅れる | 中（早期 push で取りこぼし） | △（同意宣言が遅れる） | △ 公式推奨外 |
<body> 直後 | 遅い | 高い | ×（同意宣言の機会を逸する） | × 非推奨 |
なお Google が配布する 2 つ目のスニペット（<noscript> 部分）は別ルールで、こちらは <body> 直後に置くのが正解です。1 つ目（<script> 部分）と混同しないよう注意してください。
パフォーマンスへの影響を分解する
「GTM を head 上部に置くと重くならない？」という疑問はよく出ます。結論から言えば、GTM スニペット自体が原因で遅くなることはほとんどありません。速度劣化の原因は「GTM 内で発火するタグ数」です。
GTM スニペットは非同期読み込み
Google が配布する GTM コンテナタグは、内部で script 要素を動的に挿入する形式で、デフォルトで非同期読み込みになっています。async 属性を後付けする必要はなく、レンダリングをブロックしません。そのため LCP（Largest Contentful Paint）や FCP（First Contentful Paint）に直接の悪影響を与えにくい設計です。
「重い」原因は GTM 内のタグ数と内容
ページ速度に影響するのは GTM そのものではなく、GTM 経由で読み込まれるタグの中身です。次のような構成では Total Blocking Time（TBT）や INP（Interaction to Next Paint）が悪化します。
- 広告タグを 5 種類以上同時に「All Pages」トリガーで発火させている
- 外部のチャットウィジェットを「Window Loaded」より前で読み込んでいる
- カスタム HTML タグで重い JavaScript を同期実行している
対策は「GTM 配置位置を変える」ことではなく、「重いタグのトリガーを Window Loaded やスクロールなど遅延発火に切り替える」ことです。ページ速度改善の方法 — Core Web Vitals を最適化すると組み合わせて運用するのが王道です。
preload や Critical CSS との順序
<head> 上部に GTM を置く際、注意したいのが画像やフォントの preload タグ・Critical CSS との順序です。基本的には「Critical CSS（インライン） → GTM → preload」または「Critical CSS → preload → GTM」のどちらでも体感差はほぼありません。Critical CSS は最優先で、GTM は CSS の手前か直後かでも LCP は通常変わりません。
ただし、Critical CSS をインラインで持たず <link rel="stylesheet"> で同期読み込みしている場合、GTM をその前に置くと CSS 取得が遅れることがあります。この場合は GTM を CSS link の直後に置くか、Critical CSS をインライン化する方を優先します。
WordPress での実装ポイント
WordPress テーマで GTM を <head> 上部に設置する場合、テーマ自作か汎用テーマかで方法が変わります。それぞれのケースを整理します。
自作テーマ・子テーマで直接編集する場合
header.php の <head> 開始タグの直後（meta タグや viewport の宣言よりは後、wp_head() よりは前）に GTM スニペットを貼り付けます。重要なのは wp_head() より前に配置することです。wp_head() はプラグインや SEO 関連のスクリプトを出力するアクションフックなので、GTM が後ろにあると他プラグインのスクリプトが先に読み込まれ、せっかくの「<head> 上部」の効果が薄れます。
プラグイン経由で設置する場合
「GTM4WP」「Site Kit by Google」など、GTM 設置を担うプラグインを使う場合は、設置位置オプションを必ず確認します。プラグインによっては wp_head フックの末尾に出力する実装になっており、「head 内ではあるが上部ではない」状態になりがちです。GTM4WP では設定画面の「General」タブで wp_head の優先度を変更できます。
<noscript> タグは body 直後に
GTM の 2 つ目のスニペット（<noscript> 部分）は <body> 開始タグの直後に配置します。WordPress では wp_body_open() アクションフックを使うのが標準です。1 つ目のスニペットを head 上部に置いただけで満足せず、必ず両方を設置してください。
設置時の落とし穴（実体験ベース）
当サイトでも GTM の設置位置を wp_head() の後ろから前へ移動するリファクタリングを行いました。その際に気付いた点を共有します。
既存の preload タグとの順序を整理する
テーマで LCP 用にロゴやヒーロー画像の <link rel="preload"> を入れている場合、GTM をその前に置くか後に置くかで悩むかもしれません。実測した範囲では LCP への影響はほぼ誤差レベルです。判断基準は「Google 公式の <head> 上部推奨を優先」で、GTM を先に置き、preload はその後でかまいません。
SEO プラグインの head 出力との競合
All in One SEO や Yoast SEO のような SEO プラグインは、wp_head フック経由で title・description・OGP・JSON-LD を出力します。GTM を wp_head() より前に置けば、これらより先に GTM が読み込まれます。両者の順序を入れ替えても SEO スコアや構造化データの認識には影響しないため、GTM 上部配置を優先してください。
GTM Server-Side を使う場合の例外
GTM Server-Side（サーバーサイドコンテナ）を使っている場合、クライアント側のコンテナと並行運用するケースがあります。この場合もクライアント側 GTM の <head> 上部配置ルールは同じです。Server-Side コンテナのエンドポイント設定（カスタムドメイン）は別レイヤーの話なので、本記事の範囲では割愛します。
よくある質問（FAQ）
Q. GTM を body 直後に置いている既存サイトは作り直すべきですか？
計測の取りこぼしや同意モードの不全がない範囲で運用しているなら、緊急で作り直す必要はありません。ただし、Google 広告のスマートビッディングや Consent Mode v2 を活用する予定があるなら、<head> 上部への移動を優先的にスケジュールに入れることを推奨します。次回テーマ修正やリニューアル時に合わせると工数が抑えられます。
Q. GTM を head 上部に移動したらページが遅くなりました
GTM スニペット自体は数 KB の非同期スクリプトなので、配置位置だけで体感差が出ることはほぼありません。原因は別の場所にあります。GTM 管理画面で発火しているタグを「ページビュー」「All Pages」「DOM Ready」ごとに分類し、Window Loaded やスクロールトリガーへ移動できるものを洗い出してください。PageSpeed Insights の「Reduce JavaScript execution time」項目もあわせて確認します。
Q. GTM スニペットに async / defer 属性を追加するべきですか？
不要です。Google 公式が配布するスニペットは内部で script 要素を動的生成しており、その時点で非同期読み込み扱いになります。自分で async や defer を付けると、配布形式から逸脱する上、副作用が読みづらくなるため避けてください。
Q. AMP ページにも GTM コンテナタグを入れて良いですか？
通常版の GTM コンテナタグは AMP では動作しません。AMP 専用の「AMP コンテナ（amp-analytics を使う形式）」を別途用意する必要があります。GTM 管理画面からコンテナを新規作成する際、ターゲットプラットフォームで「AMP」を選択してください。WordPress で AMP プラグインを使っている場合は、プラグイン側の AMP 設定欄に GTM コンテナ ID を入力する形になります。
Q. noscript タグも head 内に置いて良いですか？
仕様上は不可です。HTML5 では <head> 内の <noscript> は <link>・<style>・<meta> 要素のみを内包できます。GTM の <noscript> は <iframe> を含むため、必ず <body> 開始タグの直後に置いてください。WordPress テーマでは wp_body_open() アクションフックを使うのが最も安全です。
まとめ
GTM コンテナタグの設置位置に関する要点を整理します。
- GTM コンテナタグ（1 つ目）は
<head>内の可能な限り上部に設置する（Google 公式推奨） <noscript>スニペット（2 つ目）は<body>直後に設置する（仕様上 head 内不可）- WordPress では
wp_head()より前に GTM を出力する - GTM スニペット自体は非同期で軽量 — 速度問題は GTM 内のタグ数・トリガー設計が原因
- 同意モード v2 を使う前提なら、上部配置はマスト
GTM の設置位置だけでなく、サイト全体の SEO・パフォーマンスをまとめてチェックしたい場合は、SEO 診断ツールが便利です。
関連記事
▶ WordPress で GA4 を GTM 経由に移行する方法
▶ GA4 直接埋め込み vs GTM 経由 — メリット・デメリット比較
