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 が 過大評価 される
-
比率を下げても「どのチャネルが売ったか」 は別問題
Direct を 15% まで下げても、GA4 標準が見せるのはセッション数と CV 数まで。予算配分は、チャネル別の実売上・RPS・購入率を1画面で見比べて初めて判断できます
1.「Direct/(none)」とは—GA4の判定条件#
Direct / (none) は、流入元の手がかり——utm も referrer も——が何も残っていないセッションの集約先です。
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つの原因#
Direct / (none) が膨らむ理由は無数にあるように見えて、正体は2種類しかありません。
突き詰めると原因は「キャンペーンパラメータが付いていない」 か「referrer が消える」 のどちらかに集約されます。 発生頻度の高い順に 5 つ:

原因1:utm_sourceの欠損—配信側の設定漏れ#
最も頻度が高いのがこれ。 Meta 広告・Google 広告・LINE 広告・Yahoo 広告・メルマガ・LINE 公式アカウント・X の投稿リンク。 これらに utm_source / utm_medium を付け忘れると、ランディング側でキャンペーンパラメータが取得できず、referrer も Cookie 同意ダイアログ等で消えていれば Direct 判定に落ちます。Meta 広告で utm_medium に入れるべき正解値はMeta広告のutm_mediumは何を入れる?GA4公式の正解値で解説しています。
特に多いのが メルマガ・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.診断と対処順#
対処は、工数が小さく効果が大きいものから着手します。優先すべきは utm 欠損(原因1)と、リダイレクトで utm が消えるケース(原因4)です。
診断—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)との向き合い方#
対策を尽くしても Direct / (none) は残りますし、仮に 15% 以下まで下げられても、GA4 の標準レポートで分かるのはセッション数と CV 数まで。どのチャネルに予算を寄せるかは、チャネル別の実売上・RPS・客単価・購入率を1画面で見比べて初めて判断できます。
5 つの原因にすべて対処しても、Direct / (none) は 0% にはなりません。 本当のブックマーク経由・直接 URL 入力・referrer 非送信ブラウザの存在があるためです。 実務上の到達目標:
- 広告主体の EC : 15% 以下
- メディア主体のサイト : 20〜25% が許容上限
- B2B SaaS : 20% 前後 が現実解
ここまで下げられれば、Paid / Organic / Social のチャネル分類は信頼できるレベルになります。ただし「分類が正しい」 ことと「どのチャネルがいくら売ったか」 が分かることは別問題です。対処後も 40% 超えが残るなら、計測の前提 (タグ実装・コンセント管理ツールの設定) から見直すサインです。
RevenueScopeの解決策
Direct を本来のチャネルに振り戻せても、「そのチャネルがいくら売ったのか」は、再分類をどれだけ頑張っても GA4 の標準レポートからは出てきません。再分類を入口にして、その先の売上まで見えるようにするのが RevenueScope です。
Direct/(none) が多いと、本来は広告や検索が連れてきたはずの売上が、流入元を失って Direct に紛れ込みます。RevenueScope は、自前のトラッキングで参照元を保持し、Direct に紛れた流入を本来のチャネルに振り戻します。ただし、この再判定は前処理にすぎません。本体は、bot を除いたクリーンな数字で、チャネル別の実売上・RPS(Revenue Per Session)・客単価・購入率を 1 画面で見比べて、どのチャネルに次の 1 円を投じるべきかを判断できることです。

RevenueScope のダッシュボード(表示はデモデータ)。Direct を含むチャネル別の実売上を1画面で見比べる。
たとえば上の画面では、Direct は ¥900K で全体の 16% を占めます。もしこの大半が、実は広告や検索から来た訪問だとしたら、その売上は本来、別のチャネルの成果として評価すべきものです。Direct の中身を切り分けて本来の流入元に戻したうえで、bot を除いたチャネル別の実売上・RPS・購入率を1画面で見比べて初めて、どのチャネルに次の予算を投じるべきかが判断できます。これが、計測の穴で広告判断を誤らないための次の一手です。
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 標準では困難です。探索レポートで仮説検証はできますが、過去データを遡って再分類する機能はありません。さらに、仮に再分類できたとしても「そのチャネルがいくら売ったか」 を売上で見比べる機能は GA4 標準にはありません。RevenueScope はこの 2 つ(Direct の再判定と、チャネル別の実売上比較)をまとめて担います。
まとめ—Direct/(none)は「ユーザーの行動」ではなく「計測の問題」#
Direct / (none) が増えると、多くの事業者は「ブランドが浸透して直接来訪が増えた」 と前向きに解釈しがちです。 しかし本記事で見た通り、その大半は 計測の取りこぼし。 広告の効果が見えなくなり、ROAS が過大評価され、結果として広告予算の判断が歪みます。
最初の一歩は比率の月次観測です。ただし本当のゴールは比率を下げること自体ではなく、「どのチャネルが実際に売上を作っているかを根拠に、次の広告予算を配分すること」 です。Direct/(none) を 15% まで下げても、残ったチャネルの実売上・RPS・購入率が1画面で見えなければ、結局 ROAS だけを頼りに予算を動かすことになります。
RevenueScope は、Direct / (none) を構成するセッションを再判定して本来の流入元に振り戻したうえで、bot を除いたチャネル別の実売上・RPS・購入率を 1 画面で見比べられます。比率を下げる作業の先で、「どのチャネルがいくら売ったか」 を売上で確かめ、予算配分を決めるための土台です。
どの広告が売上を生んでいるか、一目でわかる
月5,000セッションまで、AIアナリストもずっと無料。クレジットカード不要。最短5分で導入。
参考文献#
[1] Google Analytics Help 「Default channel group」 2026 年 4 月
[2] W3C 「Referrer Policy」 2026 年 4 月
[3] Google Analytics Help 「[GA4] Direct traffic」 2026 年 4 月






