GA4のレポートを開いたとき、「Direct / (none)」（あるいは「直接 / (none)」）の行が全体の30%や40%を占めていて、違和感を覚えた経験はないでしょうか。
直接URLを叩いて来る人がそんなに多いはずはない、ブックマーク経由がそこまで多いはずもない、と感覚で分かっているのに、レポート上では「不明な流入」が膨らんでいきます。これは多くの場合、ユーザー行動の問題ではなく、計測の取りこぼしの問題 です。
本記事では、Direct / (none) が増える5つの原因を、Google Analytics公式の判定ロジックとW3C Referrer Policy仕様から逆引きで整理し、原因別の診断方法と対処の優先順位を解説します。
この記事のまとめ#
- Direct / (none) は「流入元が判定不能」の旗印。GA4が
utmパラメータとreferrerのどちらも取得できなかったセッションがここに集まる - 原因の8割は自社で対処可能。utm欠損・プロトコル切替・リダイレクト・referrer policy はいずれも自社側の設定で大半が解決する
- 比率が20%超えたら警戒、40%超えたら広告分析が崩壊。Direct / (none) の中に広告流入が混ざり込み、ROAS が過大評価される
1. 「Direct / (none)」とは何か — GA4の判定条件#
GA4が 「Direct / (none)」 にセッションを分類する条件は、Google Analyticsのヘルプドキュメントに明記されています[1]。要約すると次の2つを同時に満たす場合です。
- セッションのランディングURLに
utm_source/utm_mediumなどのキャンペーンパラメータが付与されていない - ブラウザから渡される
Refererヘッダー（GA4内ではreferrerディメンション）が空、または自社ドメインと一致する
つまり「広告でも検索でもSNSでもない、流入元の手がかりが何も残っていない」セッションが Direct / (none) に集約されます。本来ブックマーク・直接URL入力・メーラーからのクリック程度に限定されるべき分類なのですが、現実には 本来は広告経由・ソーシャル経由のセッションがここに紛れ込み続けている のが多くの事業者の実態です。
Direct / (none) の比率が高くなるほど、広告分析・チャネル別ROAS・コンテンツ別流入評価のすべての精度が下がります。実務上の目安として、私が広告運用の現場で使っている閾値は次の通りです（業界一般論ベース・参考目安）。
- 〜20%：健全。許容範囲内
- 20〜30%：黄色信号。原因特定を始める段階
- 30〜40%：要改善。広告レポートに「目安」の注記が必要なレベル
- 40%超え：分析崩壊。Direct / (none) を分解しないと、ROASを語れない
40%超えの状態で「Paid SearchのROASが400%」と報告書に書いても、Direct / (none) の中に Paid Search の取りこぼしが含まれている可能性があるため、その数値は事実より高めにブレます。広告予算の意思決定に直結する数字である以上、ここの精度は譲れません。
2. Direct / (none) を生む5つの原因#
Direct / (none) が増える原因は、突き詰めると 「キャンペーンパラメータが付いていない」か「referrer が消える」のどちらか に集約されます。実務でよく遭遇する5つを発生頻度の高い順に整理しました。
原因 1：utm_source の欠損 — 配信側の設定漏れ#
最も頻度が高いのがこれです。Meta広告・Google広告・LINE広告・Yahoo広告・メルマガ・LINE公式アカウント・X（旧Twitter）の投稿リンク。これらに utm_source / utm_medium を付け忘れると、ランディング側でキャンペーンパラメータが取得できず、referrer も Cookie同意ダイアログ等で消えていれば Direct 判定に落ちます。
特に多いのが メルマガ・LINEメッセージ・QRコード経由のリンク です。広告のように代理店が並走しないチャネルほど、運用者が個人で URL をコピペしている分、utm が抜けやすい構造になっています。
原因 2：https → http 遷移によるreferrer 消失#
広告ネットワークやランディングページが http のまま運用されている場合、HTTPS のサイトから HTTP のサイトへ遷移する際にブラウザは 意図的に Referer ヘッダーを送信しません。これは W3C の Referrer Policy 仕様で「downgrade を防ぐ」目的で定められているデフォルト動作です[2]。
中継するランディングページが http、計測対象サイトが https、というケースで頻発します。「自社サイトはhttpsだから関係ない」と思っていても、広告経由で経由する 中間ドメインが http ならば referrer は到着時点で空になります。
原因 3：アプリ内ブラウザ経由のタップ — 構造的な制約#
LINE・Instagram・Facebook・X のアプリ内ブラウザでURLをタップしてサイトを開くと、Referer ヘッダーがアプリ側で付与されない、もしくは独自の値（例：com.facebook.katana）になるケースがあります。GA4側でこれらは「ソーシャルサイト」のリストにマッチしないため、Direct 判定に落ちます。
スマホからの流入比率が高い D2C・BtoC EC ほど影響が大きく、SNS マーケティング経由の売上が Direct / (none) に紛れ込みやすい構造です。utm を確実に付与しておくことが、この原因を実質的に唯一防ぐ方法です。
原因 4：リダイレクトによる referrer 消失#
短縮URL（bit.ly・lin.ee・t.co）や中間ドメインを経由するリダイレクトでも、リダイレクト元の情報は基本的に最終ランディングページに引き継がれません。サーバーリダイレクト（HTTP 301/302）の挙動はブラウザによって差があり、JavaScript リダイレクトに至ってはほぼ確実に referrer が消えます。
「広告効果計測のために短縮URLを噛ませている」運用が、結果として GA4 では Direct / (none) を増やす方向に作用する、という逆説が起きます。utm パラメータがリダイレクトチェーンを通して維持されているかは、別途検証が必要です。
原因 5：referrer policy による意図的な制限#
W3C の Referrer Policy 仕様により、サイト側は <meta name="referrer"> タグや HTTP レスポンスヘッダーで、自サイトから他サイトへ遷移する際にどこまで referrer を渡すかを制御できます[2]。多くのモダンブラウザのデフォルトは strict-origin-when-cross-origin で、これは クロスオリジン遷移ではホスト名までしか渡さない 仕様です。
メディアサイト・ニュースサイト・SNSのほとんどがこのデフォルト挙動を採用しており、リファラとして「ホスト名のみ」が GA4 に届く形になります。これ自体は Direct には落ちませんが、より厳しい no-referrer ポリシーを採用しているサイトからの流入は、完全に referrer が空になり Direct / (none) に分類されます。
3. 診断方法 — GA4探索レポートで原因を分解する#
「Direct / (none) が30%ある」と分かっても、その内訳が utm欠損なのか、リダイレクト経由なのか、SNSアプリ内ブラウザ経由なのかが分からなければ対処できません。GA4の 探索レポート で次のディメンションを組み合わせると、Direct / (none) の中身を分解できます。
| 分解軸 | ディメンション | 切り分けられる原因 |
|---|---|---|
| デバイスカテゴリ | デバイスカテゴリ | mobile に偏っていれば 原因③ アプリ内ブラウザの可能性大 |
| ランディングページ | ランディング ページ + クエリ文字列 | 特定LPに集中していれば 原因①②④ の可能性 |
| 時間帯 | 日付 + 時間 | キャンペーン配信時間と一致していれば 原因① |
| 国・地域 | 国 | 海外比率が高ければ 原因⑤（厳しいreferrer policyの地域） |
referrer 消失から Direct / (none) 判定に至る経路を1枚にまとめると次のようになります。
5つの原因のいずれを通っても、最終的に referrer が消えれば GA4 は Direct / (none) に分類します。ここを 構造的に理解 しておくと、対処の優先順位を判断しやすくなります。
4. 対処法 — 原因別の優先順位#
| 優先度 | 原因 | 対処 | 工数 |
|---|---|---|---|
| 高 | ① utm欠損 | 配信側URL生成ルールを統一・テンプレ化 | 小 |
| 高 | ④ リダイレクト | リダイレクトチェーン全段で utm を維持・検証 | 小 |
| 中 | ② https→http遷移 | 中間ドメインを https 化 | 中 |
| 中 | ③ アプリ内ブラウザ | utm徹底でカバー（ブラウザ挙動は変えられない） | 小 |
| 低 | ⑤ referrer policy | 自社制御不可。utmで代替する以外なし | — |
最初に手を付けるべきは 原因① utm欠損 と 原因④ リダイレクトでの utm欠損 です。両方とも「utm を確実に付与する」「経路の途中で消えていないか検証する」という同じ対策で同時に解消できます。
特に効果が大きいのは、配信プラットフォーム側で URL ビルダーを統一すること です。Meta広告・Google広告・LINE広告それぞれで utm_source の値が facebook / Facebook / meta のように分かれていると、Direct / (none) を解消した後にも別の問題（チャネル分類の崩壊）が残ります。utm の表記揺れについては別記事 Meta広告のutm_source、結局何を入れるのが正解か で詳しく整理しています。
5. それでも残る Direct / (none) との向き合い方#
5つの原因にすべて対処しても、Direct / (none) は 0% にはなりません。本当のブックマーク経由・直接URL入力・referrer非送信ブラウザの存在があるからです。実務上の到達目標は次の通りです。
- 広告主体のEC：Direct / (none) を 15%以下 に抑える
- メディア主体のサイト：Direct / (none) は 20〜25% が許容上限
- B2B SaaS：Direct / (none) は 20%前後 が現実解
ここまで下げられれば、Paid / Organic / Social のチャネル別レポートが意思決定に使えるレベルになります。逆に、対処後も40%超えが残るのであれば、計測の前提（タグの実装・コンセント管理ツールの設定）から見直すべきサインです。
まとめ — Direct / (none) は「ユーザーの行動」ではなく「計測の問題」#
Direct / (none) が増えると、多くの事業者は「ブランドが浸透して直接来訪が増えた」と前向きに解釈しがちです。しかし、本記事で見た通り、その大半は 計測の取りこぼし です。広告の効果が見えなくなり、ROASが過大評価され、結果として広告予算の判断が歪みます。
最初の一歩は「Direct / (none) の比率を月次で観測すること」と「20%・40%の閾値を社内のレポートに明記すること」です。比率さえ追えていれば、広告分析の精度がいつ・どの程度ブレているかが見えるようになります。
RevenueScopeでは、流入URLのutm表記揺れの自動名寄せに加え、Direct / (none) を構成するセッションをチャネル分類ロジックで再判定し、本来の流入元に振り戻す設計にしています。「GA4のDirect / (none)が膨らんでいるが、過去データを遡って分解する工数がない」という状況に対する、補完ツールの1つとして設計しました。
本記事の関連トピックは /news でも扱っています。
- Meta広告のutm_source、結局何を入れるのが正解か
- GA4 eコマース設定を30分で終わらせるチェックリスト — Shopify編
- GA4導入7割、自動化は1割 — データが示す日本マーケの『完全活用』の壁
- GA4は売上を見るツールではない — アトリビューションの盲点
- 広告予算の判断を歪める『ラストクリックの罠』
参考文献#
- Google Analytics Help 「Default channel group」 2026年4月
- W3C 「Referrer Policy」 2026年4月
- Google Analytics Help 「[GA4] Direct traffic」 2026年4月