← ブログに戻る

「AI経由の流入が増えた」は自分で作れる。導線を入れる前に測り方を分けた

この記事を含む総合ガイド LLMO 総合ガイド

2026年8月2日に、LLMOを一通り実装した自分のサイトで、AI経由の流入は全セッションの3%弱だった と書きました。

その2週間後、その3%を自分で膨らませられる導線を、同じサイトに実装しました。

何を入れたか

記事一覧と課題ページの下に、「ChatGPTで開く」「Claudeで開く」というボタンを置きました。押すと、そのAIとの新しい会話が開きます。プロンプトには、私が書いた日本語記事と書籍のカタログURLが入っています。読者が自分の課題を伝えると、AIがその一覧から3本選んで返す。そういう導線です。

記事一覧の下に置いた「AIに選んでもらう」カード。ChatGPT / Claude / Perplexity / Gemini の4ボタンとプロンプトのコピーボタンが並ぶ

実物は ブログ一覧課題から探す の下にあります。押すと本当に会話が開きます。

139本ある日本語記事の中から自分に合うものを探すのは、検索窓でもタグでも辛いです。課題の側から引ける地図は別途作りましたが、そこに載っていない困りごとを持ってきた人は取りこぼします。地図から漏れた分をAIに拾ってもらう。それがこの導線の役割です。

URLにプロンプトを載せて各社の新規会話を開くだけなので、仕組み自体は単純です。ただし各社の deep link には癖があって、そこで何度か落ちました。実装側の話は別途書きます。この記事では計測だけを扱います。

この導線は、測ろうとしている指標を自分で作れる

導入を検討している段階で引っかかったのが、ここでした。

すでに私のサイトを読んでいる訪問者が、ボタンを押してChatGPTへ飛ぶ。AIがカタログを読んで記事を3本挙げる。訪問者がそのリンクを踏んで戻ってくる。

この往復は、AI referral として計上されます

新しい人が私のサイトを見つけてくれたわけではありません。もともとサイトにいた人が、一度外へ出て戻ってきただけです。それでも数字は増えます。

GA4は2026年5月13日に「AIアシスタント」チャネルをデフォルトチャネルグループへ追加しました(鈴木謙一氏の解説)。リファラが認識済みのAIアシスタントと一致すると ai-assistant が自動で割り当てられる仕組みです。認識される側として挙げられているのは ChatGPT、Gemini、Claude、Deepseek、Copilot、Grok の6つ。

私が置いたボタンのうち、ChatGPTとClaudeとGeminiはここに入ります。Perplexityは一覧に無いので、おそらくReferralに落ちます。つまり自作の往復のうち3社分は、素直に「AIアシスタント」チャネルへ積み上がります

この施策は「AI経由の流入が増えた」という結果を、施策の効果とは無関係に生み出せます。

同じ「AI経由」でも経路は2つある。ボタン由来の往復はutm付きでReferralに落ち新規到達なし、自然なAI流入はutmなしでAIアシスタントチャネルに入り新規到達あり

構造が気になったので、実装より先に計測設計を決めました。

2系統に分ける

分け方はこうしました。

系統何を測るか実装
ボタン側押された回数、アシスタント別、設置場所別GA4イベント ai_assist_click / ai_assist_copy
戻り側押した人が実際に記事まで来た回数カタログ内URLの utm_source=ai_assist

ポイントは戻り側です。AIに読ませるカタログ(/ai/ja-articles.md)に載せる記事URLに、あらかじめ utm を付けておきます。

https://kenimoto.dev/ja/blog/<slug>/?utm_source=ai_assist&utm_medium=referral&utm_campaign=ask_ai

AIは提示するURLをそのままの形で書き出すことが多いので、ボタン由来の往復で戻ってきたセッションには utm が付き、GA4上ではReferralに落ちます。一方、私のサイトを知らなかった人がChatGPTに何かを聞いて偶然たどり着いた場合は、utmなしの source=chatgpt.com として「AIアシスタント」チャネルに入ります。

ここは100%ではありません。AIがURLを整形して落とす、読者がアドレスバーに打ち直す、といった経路では utm が剥がれます。剥がれた分はAIアシスタント側へ混ざります。完全な分離ではなく、混入を「見える状態にする」仕掛けだと考えています。

この2つが別チャネルになっていれば、効果を語れます。 混ざったままだと、増えた分がどちらなのか永久に分かりません。

utm_medium=referral を選んだのは、外部クロスポストから自サイトへの流入に使っている既存の規約に合わせたからです。以前 utm_medium=article を使っていた時期があり、GA4の標準チャネルグループに article が無いためUnassignedに落ちて、350セッション中62件の出所が分からなくなったことがあります。標準チャネルに乗る値を使うのは、そのときの反省です。

なお私のサイトでは内部リンクにUTMを付けないルールにしています。内部クリックでセッションが切れてアトリビューションが壊れるからです。今回のカタログは外部のAIが読んで、外部から戻ってくる経路なので、新しいセッションが切れるのが正しい挙動になります。ルールの対象外です。

GA4でどう見るか

見るときに使うディメンションを書いておきます。特別なものは要りません。

ボタン側は探索レポートで、ディメンションに「イベント名」、指標に「イベント数」を置きます。ai_assist_clickai_assist_copy を絞り込めば、押された回数が出ます。イベントパラメータをカスタムディメンションに登録しておくと、アシスタント別(assistant)と設置場所別(area)に割れます。ここを登録しないとイベント数の合計しか見えないので、先にやっておいたほうがいい部分です。

戻り側は「セッションの参照元」に ai_assist を指定します。utm_source に入れた値がそのままセッションの参照元になるので、ボタン由来の戻りだけが抽出できます。そして混入の監視には「セッションのデフォルトチャネルグループ」を期間比較で使います。導線を入れた日を境に、AIアシスタントチャネルとReferralの ai_assist が同じ方向へ同じ勢いで動いていたら、utm が剥がれた分が混ざっている可能性を疑う、という見方です。逆に ai_assist だけが伸びて AIアシスタントが横ばいなら、分離は効いています。

計測を分けるコストは、この程度。イベントを2本と、カタログのURL生成に utm を1行。それだけでした。

何をもって「効果あり」と言うか

1ヶ月後に見る数字を、先に決めておきました。

  1. ai_assist_click の発火数。そもそも押されるのか
  2. utm_source=ai_assist の戻りセッション数。押した人が記事まで来るのか
  3. AIアシスタントチャネルの数字が、ボタン由来で膨らんでいないか

1が少なければ、この導線は読者に必要とされていません。外します。1が多くて2が少なければ、AIが記事を選べていないか、選んだ記事が刺さっていません。カタログの書き方を直す話になります。

3は自分への監視です。2系統に分けても、utmが剥がれるパターン(AIがURLを短縮する、読者が手で打ち直す)は残ります。1と3が同時に伸びていたら、混入を疑います。

AI流入を増やす施策は、たいてい自分で数字を作れる

一般化すると、こういうことだと思っています。

AI経由の流入を増やすための施策は、その多くが「自分のサイトの訪問者をAIに触れさせる」形をとります。llms.txt を置くのも、構造化データを足すのも、AIに読ませる前提のページを作るのも同じ方向です。そして訪問者がAIを経由して戻ってくると、それは参照元がAIのセッションになります。

施策が効いたのか、経路が増えただけなのか。この2つは、測り方を分けておかないと事後には分離できません。

今朝、自分のサイトのアクセスが伸びているのを見て内訳を調べたら、シンガポールのデータセンターからのボットが28日間の22%を占めていました。あれは外から来たノイズです。今回のは自分で作るノイズです。方向は逆でも、数字を鵜呑みにできない点は変わりません。

指標が動いたときに「なぜ動いたか」を言えるかどうかは、施策を打つ前にどこまで分けておいたかで決まります。導線そのものは1時間で作れました。分けるほうを先にやってよかったと思っています。

判定は9月17日。そのとき手元にあるのは、ボタンが何回押されて、そのうち何回が記事まで届いたかという2つの数字です。どちらも小さければ外します。

なぜあなたのサイトはChatGPTに無視されるのか 関連書籍 なぜあなたのサイトはChatGPTに無視されるのか LLMO 実践ガイド | AI検索最適化・llms.txt・JSON-LD・引用率改善の体系書 書籍ページを見る →