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