あなたのサイトは、すでにAIに読まれている。
ChatGPTやPerplexityが回答を組み立てるとき、その裏側ではボットが実際のページを取得している。学習のためのクロール、検索拡張(RAG)のための参照、ユーザー操作を起点とした取得——種類は異なるが、いずれもサーバーには確かにリクエストが届いている。
ところが、この痕跡はGA4には出てこない。ボットはJavaScriptを実行しないから、計測タグは発火しない。GSCにも出てこない。あれはGoogle検索の表示とクリックを記録する仕組みであって、AIボットの取得行動を記録する仕組みではない。
つまり、多くのサイト運営者が日常的に見ているダッシュボードには、AIからのアクセスが構造的に存在しない。見えていないだけで、無いわけではない。
AI時代の集客をめぐって、すでに多くの「対策」が語られている。構造化データを整える、AIに引用されやすい書き方をする——。
だが順序が逆だ。自分のサイトの何が、どのボットに、どれくらい読まれているのかを知らないまま施策を打つのは、アクセス解析を見ずにSEOをやるのと同じことになる。
AIの回答に自社がどう引用されたかを追う調査(出力側の観測)は既にいくつか存在する。しかしその手前——AIが何を読んだか(入力側の観測)——は、自分のサーバーでしか確認できない。ログはそこにある。見る道具がなかっただけだ。
一つだけ実データを示す。
あるサイトで、関連トピックへの関心が集中する季節性の大型イベント期間、search_rag系(検索拡張のためにページを参照するタイプ)のボットアクセスが、平常時ベースラインの約3倍に増加した。
これが示すのは単純な事実だ。人間の関心が動くとき、AI経由の情報需要も並行して動く。誰かがAIに質問し、AIがその根拠を取りに来る。イベントの期間中、そのサイトはAIというチャネルを通じても情報源として機能していた——GA4のどの画面にも映らないまま。
観測していなければ、この事実は存在しなかったことになる。
ここから先は方法論の話になる。
ボットアクセスの時系列が手元にあれば、GSCの検索クリックやページビューと同じ期間軸で並べられる。検索流入が伸びた期間に、AI経由のアクセスはどう動いたか。比率は一定か、それとも開いていくのか。
これは「サイトに対するAI利用比率」の推移を測る、ということだ。
一点だけ注意がある。この比較は、あくまで同一期間の独立したカウントを並べたものであって、因果やアトリビューションを主張するものではない。ボットのリクエストにはCookieもセッションもなく、人間の行動と紐付ける手段が原理的に存在しない。だからこそ、並行して数えるという方法自体に意味がある。断定できないものを断定しない計測は、断定してしまう計測より長く使える。
観測に大掛かりな準備は要らない。
サーバーの生ログにアクセスできるなら、User-Agentで既知のAIボットを抽出するだけで最初の集計はできる。WordPressなら、プラグインを入れれば今日から管理画面で確認できる。
そのために作ったのが EdgeShaping だ。
重要なのはツールの選択ではなく、記録を始める時期だ。生ログは後から遡って取得できない。今日観測を始めた人だけが、半年後に「変化」を語れる。
AIがサイトをどう扱っているかは、推測する対象ではなく、観測する対象である。まず、数えることから。