Gemini が utm_source=gemini を外した: iOS アプリからの流入は GA4 の Direct に入り、数えられるのはサーバーログだけ

9 月のおよそ 3 週間、Gemini の回答で引用されたリンクには utm_source=gemini が付いていました。ログを見ている人たちは、9 月 28 日ごろにこのタグが消えたことに気づきました。Google は、タグが付き始めた理由も外された理由も説明していません。その後の報道は、Gemini のトラフィックが見えなくなったかのような書きぶりです。実際にどういうことなのかを確かめるため、クライアント 3 社と自分のサイトの数字を出してみました。答えは劇的というより、厄介なものでした。タグは短い例外にすぎません。それ以外の期間、Gemini アプリを示す唯一の安定した目印はユーザーエージェントで、確認した 4 つの環境のどれでも、それはクエリできる場所に残っていませんでした。

2026 年 9 月、utm_source=gemini に何が起きたのか

Gemini は 9 月上旬から一部の引用リンクに utm_source=gemini を付け、9 月 28 日か 29 日ごろに付かなくなったことが観測されています。サーバーログでこれを追っている Natzir Turrado は、9 月 9 日ごろからタグ付きの訪問を確認しました。その割合は増え続け、9 月 21 日の週には Gemini リファラーの訪問のおよそ 3 分の 2 にタグが付いていましたが、その後一晩でなくなりました (PPC Land, Turrado)。PPC Land は、10 月下旬までタグ付きの訪問がぽつぽつと続いたことにも触れていますが、その理由は誰も説明していません。Search Engine Roundtable は 10 月 30 日にタグの停止を報じました。Google の社員がその数週間前にタグを確認したと認めてはいたものの、なぜ消えたのかについての声明はありません。

変わらなかったことが 2 つあります。デスクトップの Gemini は今も gemini.google.com のリファラーを送っており、Turrado によれば、その訪問数は期間を通じて横ばいでした。iOS アプリは今も自前の WebView でリンクを開き、リファラーを送りません。

私のクライアントデータで見えた期間は、もっと狭いものでした。タグ付きの訪問が少しでも現れたところでは、そのすべてが 9 月 17 日から 22 日の間に収まっており、報告された停止日の前の 6 日間には、タグ付きの訪問は 1 件もありませんでした。件数は少なかったので、私はこれを「タグがこれらのサイトにはまれにしか届かなかった」と読んでいます。ここから別の終了日を主張するつもりはありません。

タグが外れた後、Gemini のトラフィックは GA4 のどこに入るのか

ほかに何もアトリビューションされない新規セッションの場合、デスクトップのウェブ版からの訪問は AI Assistant チャネルに、iOS アプリからの訪問は Direct に入ります。Android アプリからの訪問も大半は Direct です。GA4 のデフォルトチャネルのルールでは、リファラーが Google の AI アシスタントのリストに一致するとメディアが ai-assistant になり、チャネルはそのメディアで定義されます。Direct にはソース (direct) が必要で、これはリファラーもキャンペーンタグもない訪問に付く値です。

難しいのは Android の行です。Turrado は Android の Gemini トラフィックが「ほぼ例外なく」Direct に入っていたことを確認しており、アプリには文書化された独自のユーザーエージェントもないため、ログのクエリで切り出せません。iOS アプリは自分を名乗るので、以下の内容の大半は iOS についてです。

報道が素通りしたのは最後の行です。GA4 ではキャンペーンタグがリファラーより優先されるため、utm_source=gemini だけを持つリンクでは、セッションのソースが gemini、メディアが (not set) になります。これはどのデフォルトルールにも一致しません。AI Assistant にはメディア ai-assistant、Direct にはソース (direct)、Referral にはメディア referral、app、link のいずれかが必要です。セッションは Unassigned に落ちます。クライアントのサイトで見つけた唯一のタグ付き GA4 セッションは、まさにその形、gemini / (not set) として記録されています。1 セッションで仕組みはわかりますが、量については何もわかりません。

つまり GA4 ユーザーにとっては、本来なら識別できていた Gemini のウェブ版の訪問が、その数週間、タグによって AI Assistant チャネルから押し出された可能性があります。Direct に入るはずだったアプリからのクリックの一部をタグが浮かび上がらせたかどうかは、私のデータからはわかりません。Turrado のログにはリファラーのないタグ付き訪問が出ているので、そうなった可能性はあります。

自分のプロパティで確認すること:

1. GA4 で 9 月 1 日から今日までの自由形式のデータ探索を作り、Session source / medium と Session default channel group を使って、ソースに gemini を含むものに絞り込みます。
2. 9 月の gemini / (not set) の行を探します。それが Unassigned に入っていれば、9 月と 10 月の AI Assistant をチャネルだけで比較しても、Gemini については歪んだ結果になります。
3. gemini.google.com と gemini の 2 種類のソースを、それぞれのチャネルと並べて推移を見ます。別のカウンターがあれば、それも並行して残しておきます。

実際の B2B サイトで Gemini と Direct の数字はどう見えるか

見える Gemini トラフィックは、どのクライアントのプロパティでもセッションの 0% から 0.31% で、Direct は 19% から 52% でした。以下は GA4 の 9 月 1 日から 11 月初めまでのデータで、クライアントの 7 サイトについてセッションに占める割合を示します。

注意点が 2 つあります。一部のサイトは、訪問者が同意バナーを承諾するまで GA4 をブロックしており、承諾するのは少数派です。そのため、そこでの割合はすべて、同意したトラフィックに占める割合です。そして、比較的小さいサイトの AI Assistant チャネルに何かが記録されていた場合、そのすべてが chatgpt.com からでした。このサンプルでは、Gemini は脇役のアシスタントです。そのぶん Gemini のアプリからのトラフィックは見つけにくくなります。週に数セッション程度では、Direct の普段の日々の変動に埋もれてしまいます。

ウェブ版からのリファラルは、タグの件を通じて途切れませんでした。これらのサイトの一部で動いているサーバーサイドトラッカーは、9 月も 10 月も、gemini.google.com リファラーのページビューを同じくらいの少ない水準で数え続けていました。

サーバーログで Gemini iOS アプリの訪問を見つけるには

生のアクセスログで、アプリのユーザーエージェントに含まれるトークンを検索します。これで得られるのはリクエスト数で、それを訪問に換算するにはもう一段階必要です。上のプロパティではどれも実行できませんでした。検索できるログを渡してくれたところが 1 つもなかったためです。ですから、以下は方法であって結果ではありません。

Turrado と PPC Land によれば、アプリのユーザーエージェントには、バージョン番号付きの GeminiiOS トークンと WebView のマーカーが含まれています。

GeminiiOS/<version>
GoogleWv/1.0 (WKWebView)

バージョンはアプリのリリースごとに変わるので、プレフィックスで一致させます。nginx や Apache の combined ログ形式では、行をダブルクォートで分割すると 6 番目のフィールドがユーザーエージェントです。行全体を grep するより安全です。

# 1. requests whose user agent is the Gemini iOS app
awk -F'"' '$6 ~ /GeminiiOS\//' access.log > gemini-ios.log
wc -l < gemini-ios.log
 
# 2. requested pages (assets dropped, query string removed)
awk -F'"' '{ split($2, r, " "); p = r[2]; sub(/\?.*/, "", p);
  if (p !~ /\.(css|js|png|jpe?g|gif|svg|webp|ico|woff2?)$/) print p }' gemini-ios.log \
  | sort | uniq -c | sort -rn | head -20
 
# 3. rough daily visitors: distinct IP + user agent per day
awk -F'"' '{ split($1, a, " "); print substr(a[4], 2, 11), a[1], $6 }' gemini-ios.log \
  | sort -u | cut -d' ' -f1 | uniq -c

ステップ 2 は、これらの訪問者がリクエストしたすべてのページを、ランディングもその後のクリックも区別せずに一覧にします。ステップ 3 は、本格的なセッション化をせずに生ログから得られる訪問者数にもっとも近いものですが、IP とユーザーエージェントの組は 1 人の人間と同じではありません。

ステップ 3 の日次の数字を、同じ日・同じページの GA4 の Direct ユーザー数と並べます。Direct に占める割合ではなく、並べて報告してください。ログは全員からのリクエストを数え、GA4 はタグが捉えたものだけを数えるので、2 つの単位はきれいに割り算できません。ログに 1 日数十人の Gemini アプリの訪問者が出ていて、Direct が数人分しか動かないなら、どちらに転んでも何かがわかったことになります。

規模の目安として、Turrado 自身の推定では、Gemini は通常の週で Direct の少なくとも 0.05% から 0.23% を占めます。彼は、識別できる iOS アプリのトラフィックに、タグが付いていた間にタグによって見えるようになったリファラーなしの訪問を足してこの数字を出しています。対象サイトも計算も公開していないので、私はこれを一人の実務家による下限として読み、それ以上一般的なものとは見ていません。

Gemini トラフィックのユーザーエージェントログがない場合はどうするか

その場合に役立つ作業は、ユーザーエージェントがどこで捨てられたのかを突き止めることです。私が確認した環境では、どれもクエリできる場所にユーザーエージェントが残っていませんでした。理由はよくあるものです。サーバーにアクセスできないマネージドホスティング、サイトの担当チームが持っていないアカウントにある CDN ログ、ホスティングパネルに数日だけ残るアクセスログ、そしてユーザーエージェント文字列の代わりに解析済みのブラウザと OS を保存するアナリティクスです。完全なユーザーエージェントはフィンガープリンティングの材料になるため、意図的にユーザーエージェントを区分にまで縮めるトラッカーもあります。そうしたトラッカーが Gemini アプリにフラグを立てられるのは、収集時にそのチェックが動く場合だけです。すでに保存されたデータに後から追加することはできません。

解析済みのブラウザ区分からは、部分的なシグナルが 1 つ得られます。Umami のものを含め、一部のパーサーには iOS のアプリ内 WebView 用の区分があります。私のサイトでは、1 か月でそこに入った Direct の訪問者はほんの数人で、Direct 全体のごくわずかでした。パーサーが Gemini の WebView をこの区分に入れるのかどうかはわからないので、これが教えてくれるのは見える部分がどれだけ小さいかであって、Gemini については何も教えてくれません。ウェブ版からのリファラルはタグなしでも届いています。

ログがないなら、現実的な選択肢は多くありません。

1. ホスティング会社や CDN に、何をどれだけの期間保持しているか尋ねます。 保持期間は数日ということがよくあります。生ログを 1 週間分エクスポートできれば、上の確認を一度実行するには十分です。
2. すでに手元にある解析済みのブラウザ区分を見ます。 アプリ内ブラウザのトラフィックがひとまとまりで見えますが、アプリ名はわかりません。
3. 収集時に何を計算するかを決めます。 自前のトラッカーを運用しているなら、ユーザーエージェントを解析する箇所に GeminiiOS/ のチェックを入れるのは安上がりです。正規表現 1 つと区分の値を 1 つ追加するだけです。手間がかかるのは、トラッカーが動いているすべての場所にデプロイすることです。

Gemini の UTM の変更が ChatGPT のトラッキングにとって重要な理由

ChatGPT のアトリビューションは Gemini 以上にタグに頼っており、そのタグはすでに一度消えたことがあるからです。上のサイトの一部で動いているファーストパーティのトラッカーは、最近 AI アシスタント経由のトラフィックにラベルを付け始めました。最初の数日で、ページビューのおよそ 0.5% がそのラベルに入り、その 10 件に 9 件以上はリファラーがなく、utm_source=chatgpt.com だけを持って届いたもので、トラッカーの以前のルールでは Direct として数えられていたはずです。

数サイトで数日というのは例示であって、統計と呼ぶつもりはありません。それでも、ChatGPT が Gemini と同じようにタグを外したら、この環境で何が起きるかは示しています。そうした訪問のほかの条件が何も変わらないと仮定すると、現在識別できている AI 経由の訪問の 10 件に 9 件以上が Direct に入ることになります。Turrado は 10 月 7 日から 16 日まで ChatGPT のリンクがタグなしで出ていくのを確認し、その期間に自分のログで ChatGPT の訪問の 68% から 74% を失いました。タグが戻ったという報告は 10 月 15 日に出ています (Search Engine Roundtable)。私のサイトでは、ChatGPT はタグを通じて現れ、リファラーを通じて現れることはほとんどありません。これについては ChatGPT のコンバージョン率でわかること、わからないことに書きました。

同じトラッカーは、それ以前にある B2B サイトで逆の問題を見つけていました。リードのおよそ 20 件に 1 件は ChatGPT か Perplexity のリファラーを持つセッションから来ていましたが、そのすべてが referral に分類されていました。どちらの方向も一般化はできません。タグかリファラーか、1 つのシグナルの上に作られたチャネルは、そのシグナルが変わった日に壊れます。そして、もう一方も記録していなければ、それに気づくこともできません。

GA4 の Direct にはどれだけの AI トラフィックが隠れているのか: Gemini とそのほかについての私の見方

見えている AI トラフィックは下限で、実際の数字はもっと大きい、というのが私の見方です。それを測るのに GA4 の AI Assistant チャネルは信頼していません。GA4 が同意を待つ設定では、拒否した訪問者は一切見えません。そしてどの設定でも、リファラーもタグもない訪問は、どのアプリから来たものであれ Direct に入ります。実際の数字がどれだけ大きいかは、国、業界、ニッチによって大きく変わります。クライアントに「Direct に含まれる AI トラフィック」として 1 つの数字を渡すつもりはありませんし、自前のログを持たない人が誠実にそれを出せるとも思いません。

あの表でいちばん気になるのは、そこにない列です。7 行のどれか 1 つにでもユーザーエージェントがあれば、答え方を説明する代わりに、問いそのものに答えられていました。

ですから、助言は退屈なものになります。このデータが必要なら、外部ベンダーの定義に縛られないファーストパーティのアナリティクスを自分で運用し、何を残すかを収集時に決めてください。ベンダーのチャネルは他人のルールセットで、9 月が示したように、その裏にあるシグナルは予告なく変わりえます。AI での可視性を長期的に測ることについても同じです。届いたときに記録しなかった証拠は、後からどれだけ分析しても取り戻せません。