はい、ごめんください。Microsoft Clarity（クラリティ）大好きコスギです。
この記事は Ihab Rizk さんによって書かれた Microsoft 社の公式記事「Clarity Now Surfaces Robots.txt Violations in Bot Analytics」を和訳しつつ、私の考えなども入れたものです（和訳公開の許可を得ています）。ノイズなく読みたい方は以下からどうぞ。

以下に、要点を3行で。

AIツールやクローラーがコンテンツの発見において大きな役割を担うようになってくると、事業者はトラフィックの量だけでなく、それ以上の情報を知る必要があります。どのボットが自社のコンテンツにアクセスしているのか、そのボットが何にアクセスしようとしているのか、そして、そのプラットフォームが robots.txt で定義されたアクセス方針をきちんと守っているのか、ということです。

今回の Bot Analytics ダッシュボードのアップデートにより、Clarity は robots.txt のボット違反を検出し、見える化できるようになりました。ボットがアクセス禁止のURLにリクエストしたタイミングを確認したり、違反の傾向を時系列で追跡したり、オペレーター・ボット名・アクティビティタイプでアクティビティを絞り込んだりすることで、どのクローラーがルールを無視しているのか、そしてどのコンテンツが規約違反のアクセスを集めているのかを把握できます。

何が新しくなったのか

今回のリリースでは、クローラーの挙動をより明確に把握できるようになり、単に「ボットが何回サイトに来たか」だけでなく、「コンテンツへのアクセス方針とどう向き合っているか」まで評価できるようになりました。Clarity はボットのリクエストをサイトの robots.txt の指示と照合し、規約を守っているトラフィックと違反しているトラフィックを分けて、より深く分析できるようにします。

• 「Violations（違反）」カード
  ボットによる全リクエストのうち、違反しているとされるパターンが占める割合を表示。どれくらいのボット活動がクロールルールを無視しているかを、ひと目で把握できる
• Violations（違反）トレンドライン
  違反パターンの時系列での変化を追跡できる。急増のタイミングを見つけたり、常習的な違反元を監視したり、違反行為が増えているのか落ち着いてきているのかを把握できる
• オペレーター・ボット名・アクティビティタイプでのフィルタリング
  データを絞り込み、どのオペレーターやボットが robots.txt の指示に違反しているかを特定し、その原因となっているアクティビティの種類を切り分けられる
• ボットが実際にアクセスしている内容を確認
  違反を発生させているURLやパスを確認し、クローラーが価値の高いコンテンツや制限付きのリソース、本来アクセスされるべきではない領域にアクセスしようとしているかを把握できる
• 規約を守っているリクエストと違反しているリクエストの比較
  クロールの方針を尊重しているボットと、そうでないボットを区別し、AIツールやクローラーが公開コンテンツとどう関わっているかを、より完全な形で把握できる
• コンテンツ単位での可視化
  パスやコンテンツタイプ別に違反のアクティビティを分析し、どのコンテンツが規約違反のボットトラフィックを引き寄せているのか、対策や緩和策が必要な箇所はどこかを特定できる

これにより、事業者はAIの可視性をより実用的な形で評価できるようになります。リクエスト数だけに頼るのではなく、AIシステムが自社の意向どおりの形でサイトを発見しているか、どこで一線を越えているか、コンテンツのどの部分が最も規約違反のアクセスを集めているかを把握できるようになるのです。

はじめるには

この機能を使う前に、プロジェクトの管理者がプロジェクト設定の AI Visibility セクションから、対応するCDNを接続しておく必要があります。対応CDNは、Fastly、Amazon CloudFront、Cloudflare です。

最新版の Microsoft Clarity プラグインを利用している WordPress サイトでは、AI Bot Activity は自動的に利用できるようになります。古いバージョンの Clarity プラグインを使っているサイトは、機能を利用するためにアップデートが必要です。

CDNの接続が完了したら、以下の手順で robots.txt 違反のインサイトを確認できます。

1. Clarity でプロジェクトを開き、Bot Analytics ダッシュボードに移動する
2. Violations カードを見つけて、robots.txt の指示に違反しているボットリクエストの割合を確認する
3. オペレーター・ボット名・アクティビティタイプのフィルターを使って、調査したいクローラーや挙動に表示を絞り込む
4. 違反しているURL・パス・コンテンツタイプを確認し、ボットが何にアクセスしているのか、どのコンテンツが規約違反のアクティビティを集めているのかを把握する
5. 規約を守っているリクエストと違反しているリクエストを時系列で比較し、パターンを見極めながら、監視・対策・コンテンツ保護のワークフローを更新するかどうかを判断する

この機能は現在 Clarity で利用可能です。すでに Bot Analytics を利用している場合は、違反のインサイトはすぐに使い始められます。

余談：「ルールを守らせる」ではなく「ルールを破る相手を知る」

今回の機能、「robots.txt を守らせる」機能ではないんですよね。あくまで「守っていない相手を見える化する」機能です。有名どころだと、ByteDance 社のクローラー や Perplexity のAIボットは robots.txt を無視すると言われていますね。今はどうなんだろう。

また、ユーザーが ChatGPT などのAIに「このページを要約して」と依頼すると、AIは「ユーザーから依頼されて来たので、私は人間です」という顔をしてアクセスしてきます。人間がﾆｬｰﾆｬｰ鳴いたって、猫にならんのと一緒やないかい。

あと、インターネット上の安全を監視するために活動しているボットもいます。おまわりさんが戸締りを確認しに来ているようなものなので、これはまあ、問題ないでしょう。本当のおまわりさんなら。

robots.txt は、性質的には「お願い」です。法律でもなければ、技術的にブロックするものでもありません。守るかどうかは、結局相手のボット次第です。だからこそ、「誰が守っていて、誰が守っていないか」を知ること自体に価値が出てくるわけです。

これは、人間社会のマナーと同じようなもので、看板を立てたところで、見ない人・無視する人は必ずいますよね。それでも看板を立てるのは、見て守ってくれる大多数のためです。今回の機能は、無視する一部の存在を「知らないままにしない」ためのものです。

とはいえ中小企業のサイトにとって、「いますぐ違反ボットをブロックしよう」と意気込む必要はないと思います。まずは「誰が来ているか」を知るだけで十分です。そのうえで、本当に困る相手が出てきたら、CDN側のルールで個別に対応すればいい話。

わからなければ何もできませんが、わかれば対処のしようはあります。今回のアップデートは、その「知る」を一歩前に進めてくれるものではないでしょうか。

はい、ごめんください。Microsoft Clarity（クラリティ）大好きコスギです。
この記事は Ihab Rizk さんによって書かれた Microsoft 社の公式記事「Bot Activity in Microsoft Clarity: New Ways to Measure and Analyze Bot Traffic」を和訳しつつ、私の考えなども入れたものです（和訳公開の許可を得ています）。ノイズなく読みたい方は以下からどうぞ。

以下に、要点を3行で。

Microsoft Clarity に Bot Activity（ボットアクティビティ）を導入した際、私たちはこれまでインフラのログの中に埋もれていて、アクセス解析の文脈では解釈しづらかったウェブ流入の一部に、初めて光を当てました。Clarity の中で、AIシステムやクローラー、自動化されたエージェントがどのようにコンテンツへアクセスしているか、どのプラットフォームが関わっているか、どのページがリクエストされているかを、初めて確認できるようになったのです。

この可視化は、大きな転換点でした。ボットの活動は、もう背後に隠れたものではなく、観察し、掘り下げられる対象になったのです。

しかし、見えるようになることは、あくまでスタートラインに過ぎません。

この活動が見えるようになると、自然と次の疑問が出てきます。このトラフィックは、サイト全体の活動と比べてどれくらい重要なのか。このボットの活動は、有益なものなのか、それとも単にコストがかかっているだけなのか。この挙動は、時間とともにどう変化しているのか。

これらの問いに答えるには、生のリクエストデータだけでなく、構造や集計、そしてより深く分析するための仕組みが必要です。

今回のアップデートにより、Microsoft Clarity の AI Bot Activity は、単なる「見える化」から、さらに踏み込んだ「分析」の段階へと広がります。Bot Analytics ダッシュボードに、より充実した指標、わかりやすいシグナル、そしてチームがボットのトラフィックをよりよく理解するための新機能が追加されました。

このアップデートは、3つの主要な機能に焦点を当てています。

AIボット活動の「規模」を把握する

ボットのトラフィックに関する最初の課題は、単純に「どれくらいの規模なのか」を把握することです。自動化されたシステムがサイトにアクセスしていること自体は見えても、それが全体の中でどれくらい重要なのかを答えるのは、案外難しいものです。

新しい Bot Analytics では、以下が確認できるようになりました。

• AIボットリクエスト数（合計）　AIクローラーや自動化システムによるリクエストの絶対数
• AIボットトラフィックの割合（％）　全体の流入のうち、自動化された活動がどれくらいの割合を占めているか
• クロール済みページの割合（％）　サイト内のページのうち、ボットにアクセスされている割合
• 全リクエストの概要　ボットの活動を、サイト全体のトラフィックと並べて確認できる統合ビュー
• トラフィックの種類をまたいだ指標の一貫性　選択したトラフィックの範囲（全体／全ボット／AIボット）に応じて、情報カードの定義と数値が自動で切り替わるため、どの範囲を見ているのか迷わなくなった

これらの指標が組み合わさることで、ボットの活動は「個別の観察結果の集まり」から「計測可能なサイト需要のレイヤー」へと変わります。ボットが存在することを知るだけでなく、その規模・集中度・流入全体に対する相対的な重みまで理解できるようになるのです。規模を把握することで、AIシステムが実際にあなたのコンテンツとどれくらい関わっているのか、そしてその需要がどこに集中しているのかがわかります。これは、AI主導の発見において見つけられやすさ（discoverability）を高めるために、どこに優先的に投資すべきかを示す明確なシグナルになります。

ボットとのやり取りの「質」を評価する

ボットのトラフィックは、すべてが同じように振る舞うわけではありません。あるリクエストは意図どおりにコンテンツへ正常に届きますが、別のリクエストはリダイレクトされたり、ブロックされたり、インフラやルーティングの都合で失敗したりします。この違いを理解することは、自動化されたアクセスが効率的に機能しているのか、それとも不要な負荷を生んでいるだけなのかを見極めるカギになります。

強化された Bot Analytics ダッシュボードでは、以下が分析できるようになりました。

• リクエストステータスの内訳
  ボットのリクエストが、成功・リダイレクト・失敗にどう分布しているかを確認できる
• リクエストステータスの時系列トレンド
  ボットのトラフィックの信頼性や結果が、時間とともにどう変化しているかを追える
• ステータス別のインタラクティブフィルタリング
  特定のリクエスト結果をクリックして絞り込み、パターンをさらに調査できる
• CDN違反の検出
  robots.txt に違反して、アクセス禁止のパスにアクセスしているボットを検出し、トレンドの追跡やフィルタリングで問題のあるクローラーを特定できる

これらのシグナルがあれば、単なるリクエスト量の話から、運用上の明確さへと一歩進めます。「ボットが来ている」とわかるだけでなく、そのアクセスが効率的かつ成功しているのか、それとも失敗や非効率なリクエストによって不要なインフラ負荷を生んでいる可能性があるのかまで理解できるようになるのです。

失敗したリクエストの数が多い場合、それはAIシステムがあなたのコンテンツに正しくアクセスできていないことを示しているかもしれません。アクセスがブロックされている、URLが壊れている、ページが制限されているなど、理由はさまざまです。これは、AIが生成する回答の中で発見されたり言及されたりする機会を逃していることにつながります。これを避けるには、ページがボットにアクセス可能で、エラーや壊れたリンクがなく、確実に素早くクロール・読み込みできる状態になっていることを確認しましょう。

パターンと機会を特定する

規模と質を理解したら、次のステップはパターンを見抜くことです。ボットの活動がどこに集中しているのか、時間とともにどう変化しているのか、サイトのどの部分が継続的に自動化された注目を集めているのか、ということです。

今回の Bot Activity の機能強化により、以下が可能になりました。

• すべての主要指標のトレンドを分析
  リクエスト数、割合、クロールカバレッジなどの時系列での変化を含む
• ドメイン単位・パス単位でのフィルタリング
  サイトの特定の領域を切り出して、ローカルな挙動を把握できる
• クリックでのドリルダウン調査
  ダッシュボードを離れずに、リクエストステータスやパス単位の活動をすぐに掘り下げられる
• パスレベルでのリクエストパターン追跡
  どのページやリソースが継続的にボットの注目を集めているかを特定できる

これらの機能が組み合わさることで、これまで大量のシグナルの一本の流れとしてしか見えていなかったボットの活動から、意味のある構造を浮かび上がらせることができます。ボットの活動を単一のリクエストの流れとして見るのではなく、パターンとして分解できるようになるのです。実務的には、AIシステムがどこに注目しているのかを的確に把握し、その領域をコンテンツの改善や最適化の優先対象にすることができます。関心の高いページやトピックに重点的に取り組むことで、AIの回答内であなたのブランドがどう取り上げられるかを改善できます。このトレンドラインを使えば、コンテンツの更新やページの再構成、アクセシビリティの改善が、実際にクロールのカバレッジ向上（注：検索エンジンなどに認識されるページを増やすこと）につながったかどうかを、時間をかけて検証できます。

Bot Activity の新機能を一覧で見る

Bot Activity ダッシュボードで利用できる主な指標と機能を、まとめてチェックしておきましょう。

新しい指標と全体傾向の把握

• AIボットリクエスト数（AIクローラー・自動化システムからのリクエストの総数）
• AIボットトラフィックの割合（サイト全体のリクエスト量に対する％）
• クロール済みページの割合（ボットにアクセスされた全ページに対する％）
• 統合的な活動トラッキングのための全リクエスト概要

リクエストステータスの可視化

• ボットのリクエストをステータス（成功・リダイレクト・失敗）別に内訳表示
• リクエストステータスと主要指標カードにトレンドラインを追加
• リクエストステータスからクリックでフィルタリングし、さらに深く分析

探索・フィルタリング機能の拡充

• すべての Bot Analytics ビューでドメイン単位・パス単位のフィルタリングに対応
• パス別リクエストやリクエストステータスでのクリックフィルタリングに対応
• ダッシュボードのテーブルや指標カードの操作性が向上

コンテンツタイプとテーブル表示の改善

• コンテンツタイプ別のリクエスト分布を集計する新しいカードを追加
• パス別リクエストのテーブルからコンテンツタイプの表示を削除し、構造をシンプルに
• パス別リクエストのビューを再設計し、集計方法や表示の一貫性を改善

対応CDNの拡大

• Akamai・Azure Front Door（AFD）との新しい連携に対応
• Cloudflare の非エンタープライズ向けプラン（無料・Pro・Business）にも対応

利用を開始するには

AI Bot Activity は、現在 Microsoft Clarity のダッシュボード → AIの可視性（AI Visibility） → AI Bot Activityから利用できます。

プロジェクトの管理者は、プロジェクト設定のAI Visibilityセクションから対応する CDN を接続することで、この機能を有効にできます。セルフサーブのオンボーディング画面では、現在対応しているCDNプロバイダーと、今後対応予定のものが表示されます。

対応CDNは、Fastly、Amazon CloudFront、Cloudflare、Azure Front Door、Akamai です。

最新版の Microsoft Clarity プラグインを利用している WordPress サイトでは、AI Bot Activity は自動的に利用できるようになります。古いバージョンの Clarity プラグインを使っているサイトは、機能を利用するためにアップデートが必要です。

余談：「見える」の次は「比べる」

前回の記事を書いたとき、Microsoft は「これは始まりに過ぎない」と言っていて、私も「じゃあ次は何が来るんでしょうね」と書いた記憶があります。今回のアップデートを見て、「ああ、こういう順番で来るのか」と妙に納得しました。

アクセス解析の歴史を振り返ると、だいたい同じ順番で成熟していくんですよね。まず「見える」（存在を知る）。次に「測れる」（数を数える）。そして「比べる」（規模・質・推移で評価する）。最後に「動かす」（施策に反映する）。今回のアップデートは、ちょうど「測れる」から「比べる」への移行だと思います。

正直なところ、1か月のアクセス数が5万件とかでなければ、ボットの「質」や「パターン」まで毎週ウォッチする余裕がある会社は、まだ多くないと思います。GA4とサーチコンソールを定期的に見るだけで手一杯、というのが現実的なところでしょう。そもそも、ウェブサイトのデータを見る前にビジネスモデルを見直して、選択と集中をしたほうがいいケースがほとんどではないでしょうか。

ただ、「いつか見るかもしれないものが、ちゃんと記録され始めている」という事実は、知っておいて損はないと思うんです。今は見なくても、半年後・1年後に「AI経由の流入が増えてきたな」と感じたとき、過去にさかのぼって「あのときからクロールが増えていたんだ」と確認できる状態を、今のうちに作っておけるかどうかは、結構大きな差になる気がします。

とりあえず今は、ダッシュボードを一度のぞいてみる。それだけで十分です……Microsoft Clarity が大好きな立場としては。

当然、リスクもあります。「使いもしないユーザーの情報を Microsoft に垂れ流している」と捉えることもできるので。これだけの機能を無料で開放している理由ですね。それは Microsoft Clarity に限らず、GA4も同じです。

こういったリスクを重く見るなら、そもそも使わない。QA Assistant（無料）や QA ZERO（有料・法人向け）のように、自社サイトで完結するツールを使う。やー、投資対効果を考えることからは逃げられませんね。

はい、ごめんください。Microsoft Clarity（クラリティ）大好きコスギです。
この記事は Microsoft 社の公式記事「Understand Your Influence in AI Answers: Citations Now Generally Available」を和訳しつつ、私の考えなども入れたものです（和訳公開の許可を得ています）。

以下に、要点を3行で。

AIが自社コンテンツをオススメしてくれるかどうか、さすがに無視できなくなってきましたね。ウチも「ChatGPT からオススメされたので購入しました」と言われるケースがポツポツ出てきましたし、「他はこういうことやってないしな」とぼんやり思っていたニーズが、AIによって可視化されてきた印象もあります。

今回は Microsoft Clarity がひと足早く、「AIによるオススメ状況」を確認できるようになったお話です。公式記事は以下。

2026年5月現在、設定はルートドメイン単位になるため、サブドメインごとに絞り込むことはできません。また、設定後にドメインを変更する方法は現時点では公式に案内されていません。Google サーチコンソールや Bing ウェブマスターツールは、ドメインの実在性を確認しているものであって、データソースには関わらないようです。

AI回答におけるあなたの影響力を把握する：引用（Citations）機能が正式リリース

AIが回答を生成するとき、複数のウェブページが情報源として参照されます。「検索で上位に表示されること」と「AIの回答に使われること」は別の話であり、多くのサイト運営者はその違いをまだ把握できていません。

Microsoft Clarity の引用（Citations：サイテーション）機能は、自分のページがAIの回答にいつ・どのように使われているかを可視化します。AIが回答を生成する前に関連コンテンツを検索・取得するプロセスをグラウンディング（grounding）と呼びますが、引用機能はそのプロセスの中で自分のコンテンツがどう扱われているかを教えてくれます。

たとえば「敏感肌向けの、毎日のスキンケア方法は？」という質問にAIが答えるとき、検索1位のページでも引用されなければその回答の中では見えない存在です。引用機能は、そうした状況を把握し、改善の手がかりを見つけるためのものです。

プレビュー版のフィードバックをもとに、シグナル（signal：AIが自分のページを参照した痕跡）の計測・集計・表示方法を改善しました。クエリ（query：検索語句）・ページ・露出傾向ごとに引用パターンをより読み取りやすくなるよう、レポート画面と指標も更新されています。今回の正式リリースで、これらの改善が反映されました。

引用ダッシュボードで何を測定できるのか

引用（Citation）ダッシュボードでは、AIが生成する回答におけるコンテンツの参照状況を、以下の6つの指標で確認できます。

• 2026年5月現在、項目名はすべて英語です。コスギ注に詳細を記載しています。

• Citations（ページ引用数）
  選択した期間中に、自分のドメインのページがAIによる回答によって参照された合計回数です。1つの回答の中で複数回引用された場合も、それぞれカウントされます。
• Share of authority (SoA)（AIに選ばれる割合）
  自分のドメインが引用された同じクエリ群の中で、全引用数のうち自ドメインの引用が何%を占めているかを示します。競合サイトと比較したときの、相対的な存在感を把握するための指標です。
• AI referral traffic（AI経由の流入）
  AIを経由してサイトを訪問したセッションが、全セッションに占める割合です。AI経由のセッション数 ÷ 全セッション数で算出されます。
• Grounding queries（グラウンディングクエリ）
  AIが回答を生成する前に、関連コンテンツを検索・取得する際に使われた検索語句のことです。「どんな質問に対して自分のコンテンツが参照されているか」がわかるため、AIがユーザーの意図をどう解釈しているかを把握するヒントになります。
• My cited pages（引用されたページ）
  自ドメインのどのURLがAI生成の回答に引用されたかを、引用数とグラウンディングクエリとあわせ、ページ単位で表示しています。AIシステムに信頼できる情報源として選ばれやすいコンテンツを把握するのに役立ちます。
• Trendlines（トレンドライン：傾向線）
  引用されたページ数とクエリ数の推移をグラフで確認できます。コンテンツの変化やAIの検索パターンの移り変わりにともなって、引用の動向がどう変化しているかを時系列で分析するのに役立ちます。

今回の正式リリースに合わせて、レポートモデル・クエリ表示・フィルタリング・ページネーションの改善も行われており、大規模なデータセットでもパフォーマンスが向上しています。

コスギ注

だいぶ新しい概念なので、和訳に苦労しましたが……上記を補足します。

Citations（ページ引用数）

AIから情報源として参照された回数の合計です。たとえばウチのサイトなら「 Microsoft Clarity 研究所では、Clarityのリスクをこのように説明しています」と引用されるケースがこれにあたります。引用数が多いほど、AIに情報源として活用されている頻度が高いといえます。

Share of authority (SoA)（AIに選ばれる割合）

和訳に悩みましたが……「権威性」とか「信頼性」とかより、「競合との引用割合」としたほうがわかりやすいかな。

同じクエリに引用されたすべてのドメインの中で、自分のドメインが何%を占めているかを示します。ウチは平均約2割。これが高いのかどうかは業界標準となる目安はまだないですし、（弊社のように）サブドメインでコンテンツが分散していることもあるため、現状ではクエリで見たほうが良いかもしれません。

たとえば、52.94%と高い「〜とは」というクエリがある一方、9.38%にとどまっているクエリもあります。このあたり、SEOの結果も見比べながら判断したいですね。

AI referral traffic（AI経由の流入）

全セッションのうち、AI経由で訪問した割合です。ウチは現在1%未満で、引用はされていてもAIの回答からサイトへ直接来訪するケースはまだまだ少ない状況です。AI Overview 問題とか言われてましたっけ？

事実、「〜とは」のクエリは検索結果で回答が出力されて解決するので、訪問までは至らないんですよね。引用数とあわせて見ることで、「引用されているが流入につながっていない」といった課題も見えてきます。

Grounding queries（グラウンディングクエリ）

「グラウンディングクエリ」は（意訳すると）要するに、「AIが使った検索ワードのこと」です。

ウチの場合、「ストレングスファインダー34資質一覧」「クリフトンストレングス 日本人」など、ストレングスファインダー（クリフトンストレングス）関連で複数回引用されており、AIがこの分野の情報源としてウチのサイトを認識していることがわかります。どんなテーマで引用されやすいかを把握する手がかりになります。

My cited pages（引用されたページ）

引用されたURLを、引用数とグラウンディングクエリとあわせ、ページ単位で確認できます。どのページがAIに選ばれやすいかを把握し、強化すべきコンテンツの優先順位をつけるのに役立ちます。

これがまた、実際のアクセス数とは異なるのが興味深いというかなんというか。

Trendlines（トレンドライン：傾向線）

トレンドラインというメニューはありませんが、一部のウィジェットは傾向を確認することができます。

コンテンツの変化やAIの検索パターンの移り変わりに伴って、引用の動向がどう変化しているかを時系列で分析するのに役立つんですが……設定する日程によって情報が合計されるため、細かく見たい場合は7日間ごととかにするのをオススメします。

はじめ方

引用機能は、すべての Microsoft Clarity プロジェクトで利用可能になっています。

1. Clarity プロジェクトを作成する
2. サイトにトラッキングコードを設置する
3. ダッシュボードで引用機能が有効になり表示される

場合によっては、ドメインの所有権確認が必要になります。Bing Webmaster Tools または Google サーチコンソールとの連携で確認できます。

• 複数ドメインを持つプロジェクトでは、初期設定時に選択できるドメインは1つのみです。設定後にドメインを変更する機能は、現時点では提供されていません。

ダッシュボードへのアクセスは、ダッシュボード → AI の可視性 → Citation から。

今後の展望

Microsoft Clarity は、この引用（Citations）機能にさらなる知見を加えることを計画しています。近日中に追加予定の機能として、トピックインサイト（topic insights）があります。

トピックインサイトは、引用されたクエリ（query：検索語句）を意図別のテーマに自動分類するものです。「どのコンテンツが使われているか」だけでなく、「なぜAIがそのコンテンツを選んでいるのか」「どんな文脈で使われているのか」まで把握できるようになります。

この機能強化により、以下が期待できます。

• 自社コンテンツが他の情報源と比べてAIの回答にどれだけ貢献しているかの把握
• カバーできていないテーマ（コンテンツのギャップ）の発見
• 特定テーマでの存在感を高めるための具体的な改善の手がかり
• AIの回答への引用をさらに増やすためのコンテンツ戦略への示唆

近日公開予定、乞うご期待！

余談：引用されただけで喜んでいる場合ではない

AIによる引用状況がわかることは、今まで見えなかった部分を照らす、一筋の光だと思います。アクセス解析ツールの黎明期のような印象。そのときはまだ Geocities をイジっていた人間ですが。そのうち Google もサーチコンソールで把握できるようになるのかな。

今回の話は、あくまで「引用されたページ」であって「アクセスされたページ」ではないので、見方によってはノウハウだけ盗まれているんじゃないかと感じるかもしれません。自分なりに丁寧にアウトプットした内容を、AIに雑に扱われて消費されることを嫌がる気持ちも、わかります。

とはいえ、AIによる引用という流れには抗えないので、キッカケを最大化するにはどうしたら良いかを考える方が生産的なんですよね。

たとえば単純に判断できないことにも言及し「おっと、ちゃんと確認しておかないとアカンかな、このサイトは信頼できそう」と、専門性を出せる機会にするとか。ここは、情報から人への興味が転換するポイントなのではないでしょうか。

“情報に価値はない” ので、キッカケの可能性をどう捉えるか、提供している情報をどのように扱ってもらうかは、戦略的に対応できます。

引用されたことだけで安心していると、気づいたときにはサイトの成果が落ち込んでいるかもしれません。今一度、ウェブサイトの目的や目標を改めて考え直す、よい機会になるのではないでしょうか。

そもそも、データソースは？

私も勘違いしていたのですが、Google サーチコンソールとの連携はドメインの所有者確認のみであって、その情報を連携して使うというわけではないのですよね。

「Data source: Microsoft Copilot and partners」とあったので、調べてみたところ……

1. データソースは Microsoft Copilot とそのパートナー。つまり、ChatGPT や Claude での引用は含まれないと判断できる。
2. 全体の活動の「サンプル」であること。注釈にある通り、すべての引用を網羅しているわけではない。

……なるほど？

①を期待していた方には、ちょっと拍子抜けだったかもしれません。2026年5月現在のシェアでいうと、「AIに引用される」＝「ChatGPTで言及される」と直感的に判断しても不思議はありませんから。

つまり、Bing Webmaster Tool ですでに展開していた AI Performance の情報を、クラリティでも見れるようになった（だけ）……とも考えられますね。

AI Performance 機能に関しては、以下の鈴木さんの記事も参考に。

引用機能を活用するには？

シンプルに、ダッシュボードのCSVデータをダウンロードして、AIに分析してもらうのがオススメです。ウチの場合はこんな感じです。

添付はAIにおける引用機能で得られたデータです。kosgis.comドメイン全体が対象になっていますが、このデータに基づいて問題発見・改善提案をしてください。回答する前に、自分の回答の不確実性を評価してください。不確実性が 0.1 を超える場合は、0.1 以下になるまで私に確認質問を行ってください。

そうすると、「どんな課題を解決したい？」と聞いてきて、SoA×引用数などの切り口で分析してくれます。そうすると、こんなことを返してくれます。

追記：母数の存在を忘れてはならない

渋谷さんから言及していただいた、ニュースレターの伊藤さんの文章を引用します。

同調査が示したもうひとつの発見は、「何%の確率で推薦リストに登場するか」というAIビジビリティスコア（Visibility %） には、一定の統計的意味があるということです。たとえば、西海岸のがん治療病院を尋ねられたChatGPTの回答では、シティ・オブ・ホープ（Los Angeles）は71件中69件の回答に登場しました（AIビジビリティ97%）。順位はバラバラでも、「そのカテゴリの候補として認識されているかどうか」は測れるわけです。

つまり、SoA と AIビジビリティスコアは違うという以上に、AIビジビリティスコアはSoAの上位概念というか、母数になりえる値なんですよね。

つまり、SoAが50%でも、そもそも100回に1回しか出現しないのと、100回に90回は出現しているのとでは、まったく意味が違います。SoAだけ見ていると「競合の中でそこそこ存在感がある」と思えても、母数であるAIビジビリティスコアが低ければ、実態としては無視されているのと変わりません。しかも、現状ではAIビジビリティスコアを確認することはできません。

ちょっとしょんぼりしたところですが、せっかくなので、もう少し引用します。

今回の調査で面白い事実として指摘されているのは、各製品カテゴリでAIが推薦するブランドがかなり限定的だということです。ヘッドフォンならBoseやSony、SaaS向けクラウドなら数社、といった具合に。順位はランダムでも、「そのカテゴリで候補として挙がるブランドのグループ」自体は比較的安定しています。

こうした構造を踏まえると、AIマーケティングの現実的なKPIとして、「特定のカテゴリにおいて、AIのアンサーの参照候補グループに自社・自社製品が含まれているか」 というのは考えられそうです。

その「候補セット」への入り込みを指標とする。これがいま考えうる合理的なKPIの置き方と言えるかもしれません。

ただし、そこには重要な留保がつきます。

これはあくまでも結果指標です。どのマーケティング施策がその可視性向上に貢献したかを直接紐づけることはできません。SEOの検索順位がそうであったように、アトリビューションの問題は残り続けます。

「特定のカテゴリ」が何かわかるのが、今 Microsoft Clarity が開発中の「トピックインサイト」だとしたら、アツいですね。

そもそも「引用されたところでアクセスにつながっているわけでもなければ、売上につながっているとは限らない」ので、過剰な期待や解釈をすることなく、優先順位を見極めてやっていきましょう。

はい、ごめんください。Microsoft Clarity（クラリティ）大好きコスギです。

この記事は Microsoft 社の公式記事「A Practical Framework for Making Website KPIs Actionable」を和訳しつつ、私の考えなども入れたものです（公式記事の和訳許可を得ています）。ノイズなく読みたい方は以下からどうぞ。

以下に、要点を3行で。

ウェブサイトのKPIを実行に移すための実践フレームワーク

何十ものダッシュボード、グラフ、アラートが注意を奪い合う中で、ウェブサイトのKPIを追いかけることは、いつの間にか受け身の作業になりがちです。指標を定義し、ダッシュボードを作り、そして時間が経つにつれて、確認する頻度は減り、信頼度は下がり、行動に結びつくことも少なくなっていきます。

問題は「何を測るか」ではありません。「測った後にどうするか」です。

より難しく、そしてより重要な課題は、KPIを常に目に見える状態に保ち、定期的にレビューし、実際のユーザー行動に基づいて運用する仕組みと習慣を作ることです。その仕組みがなければ、正しい指標を選んでいても、チームが忙しくなるにつれて背景に埋もれていきます。

この記事では、ウェブサイトのKPIを継続的なフィードバックループに変えるための実践的なフレームワークを紹介します。具体例として Microsoft Clarity を使いますが、原則はどのアナリティクスツールにも当てはまります。目的は、より多くの指標を追うことではなく、すでに気にかけている指標を理解しやすく、無視しにくくすることです。

1. ダッシュボードではなく、行動から始める

ダッシュボードやレポートに触れる前に、KPIを数字よりも具体的なものに紐づけておくと効果的です。それは、繰り返し観察されるユーザー行動です。

意味のあるKPIはすべて、あるパターンの代理指標です。ユーザーがスムーズに進んでいるか、それとも苦戦しているか。明確な導線を見つけているか、迷子になっているか。自信を持って行動しているか、途中でためらっているか。そういったパターンを反映しています。

よくある行動パターンに名前をつける

いきなり「直帰率」や「コンバージョン率」に飛びつくのではなく、まず目に見える行動に名前をつけることから始めましょう。

• ウロウロ（迷子）（Confusion loops）…ページ間を行ったり来たりする、メニューを何度も開く
• モヤモヤ（ためらい）（Hesitation patterns）…繰り返しのクリック、過度なスクロール、フォームの途中放棄
• イライラ（摩擦）（User friction）…デッドクリック、レイジクリック、繰り返されるエラー

チーム内でこれらのパターンに共通の言葉ができると、KPIは抽象的なものではなくなります。数字を追うのではなく、「特定の行動が増えているか、減っているか」を追うようになるのです。

2. 定期的な観察を促すダッシュボードを設計する

ダッシュボードは単にKPIを表示するだけではありません。チームがそれをどう見るか（あるいは見ないか）を地味に左右しています。

散らかったダッシュボードは、読み飛ばすか無視する習慣を作ります。目的を持って整理されたダッシュボードは、正しいデータに自然と目が向きます。

ダッシュボードのカードをカスタマイズする

ダッシュボードの小さな調整が、大きな効果を生むことがあります。追いたいKPIに直接関係しないレポートやデータは、移動するか、優先度を下げるか、非表示にしましょう。

Clarity でできる主な変更は以下の通りです。

• デフォルトのカードタブを設定して、最も意味のあるビューが最初に表示されるようにする
• 意思決定に役立たない優先度の低いカードを非表示にする
• ページやファネルのステップだけでなく、行動ごとにカードをグルーピングする

たとえば、ブログのパフォーマンス改善に取り組んでいるとします。ブログへの流入に広告を出していないのであれば、広告カードはあまり価値がありません。非表示にすれば、ダッシュボードのファーストビューに、リファラルやチャネルのカードなど、読者がどこからコンテンツを見つけているかを示す、より関連性の高いカードを表示できます。

3. セッション録画をKPIトラッキングの一部にする

グラフは便利ですが、すべてを語ってくれるわけではありません。

KPIが「良い方向」に動いていても、その裏でユーザー体験が地味に悪化していることがあります。もっと背景を理解しなければ、誤った結論を出しやすくなります。

だからこそ、セッション録画はたまに深掘りするものではなく、KPIトラッキングの定常的なプロセスの一部であるべきです。

軽めの「録画を見る」習慣を作る

何時間も動画を見る必要はありません。やるべきことはシンプルです。

• KPIに紐づいた少数のサンプルを、定期的にレビューする
• 指標の変化を解釈する前に、セッションを見る
• 数字が示していることを、録画で裏付ける

さらに、Clarity のハイライト機能を使えば、セッション録画をユーザー行動の重要な瞬間だけに凝縮した短いリールにまとめられるため、このプロセスを高速化できます。

この考え方を実践している良い事例が、AllEvents チームの取り組みです。プロダクトのユーザー体験を刷新する中で、チーム全員でセッション録画を毎日見る習慣を作りました。イベントデータとセッション録画を組み合わせて分析するこの日課が、主要な課題の特定と、よりスムーズなデジタル体験の設計に役立ったとのことです。

4. セグメントを使い、流入の変化に合わせてKPIの精度を保つ

サイト全体の平均値は、オーディエンス（訪問者全体）が安定しているときにしか機能しません。流入元や意図のレベル、ユーザーの期待値が変化すると、ひとつのKPIが行動の重要な変化を隠してしまうことがあります。

ここで登場するのが、セグメントです。

ひとつのグローバルな数値を追って「現実を反映しているだろう」と期待するのではなく、セグメントを使えば、KPIが異なるタイプのユーザーに対しても成り立つかを確認できます。そのKPIが実際に誰の行動を表しているのか、そして誰の行動を覆い隠しているのかが見えてきます。

セグメントを使えば、より的確な問いを立てられます。

• 新規ユーザーとリピーターで行動は違うか？
• 目的意識の高い流入が最も苦戦しているのはどこか？
• どのオーディエンスが最も摩擦を経験しているか？

例：AI経由の流入をトラッキングする

AI経由の流入の行動パターンは、従来のチャネルからの流入とは異なる傾向があります。これらのユーザーは、サイトの深い階層に直接着地したり、ナビゲーションを完全にスキップしたり、コンテンツを素早く消化したりすることがあります。

ChatGPT やその他のAIツールからの流入でセグメントを作成すれば、KPIを文脈の中でトラッキングできます。以下のようなことが可能です。

• 従来のリファラルとエンゲージメントのパターンを比較する
• AI経由のユーザーを混乱させているコンテンツ、あるいは満足させているコンテンツを特定する
• このオーディエンスに対する体験が時間の経過とともに改善しているかをトラッキングする

5. ループを閉じる：KPIの観察から実行へ

KPIトラッキングで最も見落とされがちなのは、計測そのものではありません。計測後の継続的なフォローです。

KPIの定義、ダッシュボードの構築、定期的な観察まではやっているチームは多いです。しかし、観察から行動への明確な道筋がなければ、指標は停滞します。ミーティングで話題にはなり、認識はされるものの、次のミーティングまでサラッと先送りされるのです。

効果的なKPIトラッキングと受け身のレポーティングを分けるのは、繰り返し可能なループです。見たことを、変えることにつなげるループです。

成果を出しているチームは、シンプルだけれども規律のあるサイクルを回しています。

1. KPIを観察して、何が変わったか、何が停滞しているかを見つける
2. セッション録画でパターンを検証し、その理由を理解する
3. 改善すべき行動をひとつだけ決める（長い修正リストではなく）
4. その行動に紐づいた具体的な変更を実行する
5. 次のデータと録画で、行動がどう変わったかを観察する

このループがあれば、KPIは実際のユーザー体験に根ざしたものであり続けます。「指標は動いたか？」ではなく、「ユーザーの行動は本当に改善したか？」と問うようになるのです。

KPIトラッキングがこのように機能すると、ダッシュボードはステータスレポートではなくなります。早期警告システムとなり、より良い意思決定を促す仕組みになるのです。

まとめ

ダッシュボード、KPI、指標は、行動に移せるストーリーを語ってくれるときにだけ意味を持ちます。ダッシュボードにセッション録画と適切なセグメントを組み合わせることで、受け身の数字が実際に意思決定を導くシグナルに変わります。パターンが見え、知見が明確になり、すべてのKPIが月に一度ちらっと眺める数字ではなく、改善のためのツールになります。

2026年、成果を出すサイトは最も多くのデータを持っているサイトではありません。ユーザーの行動を見て、理解し、それに応えるチームによって形作られるサイトです。

余談：小さいサイトだからこそ、このフレームワーク

• レポートつくってもらったけど、結局誰も見てないんだよね
• クラリティは面白かったけど、もう見てないよ、時間かかるし
• とはいっても改善はしたいから、プロから見て直せそうなところない？

……なんて声は、よく聞きます。今なら、アクセス解析データからすぐに問題点を指摘してくれますが、それもプロセスの一部分でしかないので、改善サイクルはまわりません。

で、この記事のフレームワークも「全部やらなくていい、回すことが大事」と言ってくれているんですよね。そんなにいっぺんにできませんて。1個ずつ回していけば十分なんです。慣れたら頻度を上げれば良いだけ。

大規模サイトなら専任のアナリストがいて、データを見る仕組みが組織に組み込まれていることでしょう。でも月間1万セッションもないサイトでは、他にやることがたくさんあります。ウェブの改善を提案しても、改修にコストがかかりすぎて施策が回らないことも珍しくありませんし、そもそも効果を見込めるとも限りません。

特に BtoB ならセッション数よりも、サイトに来てくれた人を優雅にエスコートできるかどうか、笑顔でしつこく追えるかどうかがキモになりますしね。だからこそ、仕組みはラクじゃないと続きません。人間はナマケモノですから。

ラクにするためには、「せめてこれだけは」という観点で見たら良いんです。たとえば、

• 来店型のショップで、メインは Instagram
• Google ビジネスプロフィールは登録済み
• ホームページは独自ドメインを持っている
• ビジネスの存在証明として持っているだけで、更新していない

なんてケース。来店型ということは「とにかくお店に迷わず来てもらう」ことがホームページの目的になりますから、徹底的にわかりやすくするだけでいいんです。地図はもちろん、写真で道順を伝えたり、動画を載せたり。これだけ手をかけたら、見てくれた人の反応が気になりますよね。それを確認するだけでもいいんです。

あとはむしろ、Instagram や Google ビジネスプロフィールの数値のほうが重要になるので、同じように改善サイクルを回していきましょう。

今はホームページだけでなく、SNSやLINEなどのマルチメディアで横断的にユーザーとの接点を保ち続ける必要がありますよね。そういった動線設計もやっていますので、「色々やりたいけれど、何から手をつけたらいいのかわからない」「WordPress（ワードプレス）をもっとどうにかしたい」という方は、そのままの言葉でご相談ください。わからないことがわからない方は少なくありません。

「どうしたらもっと良くなるか」を、一緒に考えるパートナーになりたいと願っています。

はい、ごめんください。Microsoft Clarity（クラリティ）大好きコスギです。
この記事は Microsoft 社の公式記事「The Top 5 KPIs for an AI-Mediated Web」を和訳しつつ、私の考えなども入れたものです（和訳公開の許可を得ています）。ノイズなく読みたい方は以下からどうぞ。

以下に、要点を3行で。

AIを介したウェブサイトにおける主要な5つのKPI

アクセス解析に、奇妙な現象が見え始めています。

流入は横ばい、あるいは減少傾向。にもかかわらず、特定のソースからのコンバージョンは伸びている。「パフォーマンスが悪い」ように見えるコンテンツが、なぜか意思決定に影響を与え続けている。

このズレは、計測のバグではありません。ウェブの使われ方そのものが変わっているのです。

人々はもはや、検索結果やホームページから始めるとは限りません。AIツールや大規模言語モデル（LLM）から始めるケースが増えています。AIが読み、比較し、要約し、どの情報を伝える価値があるかを判断する、つまり、ユーザーがあなたのウェブサイトにたどり着く前から、AIがあなたの会社に対する認識を形作っているのです。

これは、アクセス解析にとって新たな課題を生み出します。

従来のKPIは、訪問中や訪問後の成果を測るには優れています。セッション数、直帰率、コンバージョンなどです。そしてオーガニック検索やリスティング広告など、ほとんどの流入チャネルは、インプレッションやクリックに関する詳細なデータを提供してくれます。それに対して、LLMはインプレッションやレコメンドに関するデータを一切提供しません。

AIを介したウェブサイトにおいて、サイト運営者や事業者が直面する最大の課題は、このブラックボックスの中で何が起きているかを理解し、それがビジネスの収益にどう影響しているかを定量化する方法を見つけることです。

この記事では、それを実現するための実践的なKPIを紹介します。今日からチームが計測できるシグナルから、より先を見据えた指標まで、AIがビジネスの「見つけられやすさ（discoverability：ディスカバラビリティ＝発見性）」にどう関わっているかを理解するためにトラッキングすべき指標を探っていきます。

1. AI経由の流入（AI Referral Traffic）

何を測るのか

AI経由の流入は、AIツール上のリンクをクリックして訪問者がサイトに来たセッションをトラッキングします。ChatGPT、Copilot、Gemini、Claude、Perplexity などからの流入であり、従来の検索・SNS・直接流入とは異なるものです。

なぜ重要なのか

AIツールが情報への主要な入口になるにつれ、発見のあり方そのものが変わりつつあります。生成AIツールがクエリ（特に情報収集系のクエリ）に答える最初のステップとなることで、従来の検索クリックは減少すると予測されています。

この環境では、単にページビューを測るだけでは不十分です。AIツールがいつ実際の人間の訪問者をサイトに送っているかを知る必要があります。AI経由の流入を把握することで、AIによる発見（見つけられやすさ）を可視化し、アクションにつなげられるようになります。

• あなたのコンテンツがAIの提案結果に表示されているか
• AI経由の訪問がどれくらいの頻度でサイトにアクセスしているか
• これらの訪問者が他のチャネルと比べてどう行動しているか

このシグナルは、AIがファネルに影響を与えている最初の実証的な兆候です。たとえ流入量がまだ少なくても。

トラッキング方法

AIツールは参照元のリンクにUTMを付与するため、この指標の計測は非常に簡単です。多くのアナリティクスツールは、既存のチャネルレポートでこのチャネルからの流入をすでに計測できています。

Clarity は、AI経由の流入を2つの専用チャネルグループに分けることで、さらに詳細なレベルの情報を提供します。AI Platform（AIとの自然なやり取りからのアクセス）と Paid AI Platform（AIとのやり取り上に表示される広告からのアクセス）です。ChatGPT が広告を導入するという噂が広がる中、これは特に重要になってきています。

2. AI経由のコンバージョン（AI Referral Conversions）

何を測るのか

AI経由のコンバージョンは、AI経由の訪問者がサイト上で意味のあるアクション（会員登録、デモ依頼、購読、購入など）を完了した頻度をトラッキングします。

AI経由の流入が「AIは訪問者を送ってくれているか？」に答えるのに対し、AI経由のコンバージョンはより重要な問い、「その訪問者は実際にビジネスに貢献しているか？」に答えます。

なぜ重要なのか

AIを介したウェブサイトでは、サイトへのアクセス数だけでは誤ったシグナルになります。AIはユーザーがサイトに到達する前に「事前選別」を行い、選択肢を要約し、絞り込み、特定の次のステップへ誘導することが多いのです。

その結果、AI経由の訪問者は以下の傾向があります。

• より明確な意図を持っている
• 意思決定プロセスのより先の段階にいる
• すぐに行動する準備ができている

AI経由のコンバージョンを測ることで、単なる好奇心のクリックではなく、この新しいチャネルをリード・売上・成果に直接結びつけられます。これは、AIからのアクセスを単なる「興味深い流入元」から「信頼できる成長の手がかり」に変えるKPIです。

懐疑的な見方も、ここで覆ります。AI経由の流入が全セッションの中で小さな割合であっても、コンバージョン率が高ければ、その重要性は再定義されます。訪問者数は少なくても、最も重要な指標でより高いコンバージョンを達成するチャネルは、量の多い流入元を上回る可能性があるのです。

トラッキング方法・概算方法

AI経由のコンバージョンは、AI経由の流入をセグメント化すれば、今日から完全に計測可能です。

実際には以下のように行います。

• AI Platform の流入でセッションをフィルタリング
• 検索・SNS・直接流入のチャネルとコンバージョン率を比較
• AI経由の訪問者がどの目標を最も多く達成しているかを評価

3. ボットおよびクローラーの活動（Bot and Crawler Activity）

ボットおよびクローラーの活動は、インデックス用ボット、AIクローラー、LLM がコンテンツにアクセスする頻度をトラッキングします。Copilot や ChatGPT を動かすような有用なボットと、それほど有用でないスクレイピングボット（ページの情報を自動収集するボット）の両方を含みます。人間のセッションに注目するのではなく、流入やコンバージョンが発生する前に、AIがあなたのコンテンツをどれだけ見ているかを示す指標です。

このタイプのサイト上の動きを監視することで、AI経由の流入やコンバージョンの背景にある「なぜ」を理解するための、ファネル上流のデータが得られます。

たとえば、AI経由の流入が少なく、増加していないとしましょう。ボットとクローラーの活動を分析すれば、根本的な問題を特定し、対処する手がかりが得られます。

クロールは多いのに流入が少ない場合：AIシステムはコンテンツを読んでいますが、流入できるようにはしていません。このパターンは多くの場合、関連性がない、あるいは明確さが足りないことを示しています。AIはあなたを見ているものの、回答を合成する際にあなたのコンテンツを「優先」していないのです。これはページのメッセージング、構造、またはセマンティックな明確さに問題がある可能性を示唆しています。

クロールが少ない場合：あなたのサイトは、そもそも推薦してくれるかもしれないシステムに見られていません。解決策は「見つけられやすさ（discoverability：ディスカバラビリティ＝発見性）」の向上に集中することです。つまり、内部リンクの改善、スキーママークアップ、技術的な構造の整備、あるいはAIクローラーにページを訪問させるきっかけとなる外部シグナルの強化などです。

さらに一歩進めて、各LLMごとにクロール活動とAI経由の流入の関係を分析することもできます。

このプロセスは、SEOチームがクリックやコンバージョンを気にする前に、検索のインプレッション指標を使って表示の問題をトラブルシューティングするのと同じです。同様に、ボットとクローラーの活動は、流入やコンバージョンが発生するよりもっと前の段階で、AIからの見え方を診断するのに役立ちます。

トラッキング方法

ボットやクローラーの活動は、従来サーバーログ、CDN、ボット管理プラットフォームなどのインフラレベルのツールでしか確認できませんでした。これらはすべてのリクエストをキャプチャし、有益なAIエージェントと汎用ボットを区別できます。

現在では、行動分析ツールがこれらのシグナルをダッシュボードに直接統合し始めており、チームが単なるクロール量だけでなく、AIのインタラクションが人間の行動やコンバージョンとどう相関しているかを確認しやすくなっています。インフラデータと実用的なサイト分析の橋渡しが進んでいます。

Clarity はボットとAIクローラーのシグナルを直接アナリティクスに表示（和訳記事）するようになり、以下を区別できます。

• AIエージェント（既知のLLMインデックスやAIツールに関連するもの）
• 従来のボット（検索エンジンクローラー、スクレイパー、汎用の自動化）
• 人間の訪問者

これにより以下が可能になります。

• ボット活動全体のトレンドを時系列で測定
• ページごとのAIボットヒット数をセグメント化して、AIシステムがどこに時間を費やしているかを把握
• ボット活動とAI経由の流入トレンドを比較して、情報収集（ingestion）がどこで終わり、紹介（recommendation）が始まるかを確認
• クロール率が高いのに流入が少ないページを特定 → 典型的な診断パターン

4. AIによる引用（AI Citations）

• 実際の画面は公式記事の「AI Citations」のセクションをどうぞ。私は実際に使えるようになってから画面の説明をします。

何を測るのか

「AIによる引用」は、ユーザーがサイトにクリックして訪問しなくても、あなたのコンテンツをAIが生成する回答の中で使われたり、参照されたり、根拠として利用されたりしている状況をトラッキングします。人間による訪問を捉える「AI経由の流入」とは異なり、「AIによる引用」は上流での影響力を明らかにします。つまり、AIが回答、要約、レコメンドする際、その情報源としてあなたのコンテンツを使っていることを示してくれます。

なぜ重要なのか

ゼロクリックのAI体験が、「可視性（見つけられやすさ）」の定義を変えつつあります。あなたのコンテンツは、流入やクリック数といったアクセス解析の結果にまったく反映されないまま、ユーザーの問いに答えているかもしれません。AIによる引用の状況を知ることは、水面下で行われているやりとりを表面化させ、事業者やブランドが以下のことを可能にします。

• どのコンテンツがAIの回答に意味のある貢献をしているかを把握できる
• コンテンツがAIの情報源になっているのに出典元として明示されていない箇所を特定できる
• 競合がより多く認知を獲得しているトピックを検出できる
• 明確さ、構造、権威性を改善するための更新を優先できる

トラッキング方法

AIによる引用は、まだ新しい計測分野です。現時点では、ウェブ全体で統一された計測基準は存在していません。

多くのツールは、いくつかのプロンプトを用意し、AIに回答を生成させ、その出力にブランド名やURLが含まれるか、といった方法で引用を推定しています。これらの方法は傾向を把握する助けになりますが、AI内部で実際にどの情報が参照されたのかを直接観測しているわけではありません。あくまで「再現テスト」に近いアプローチです。

一方で、より構造的な方法も登場し始めています。AIの回答生成を支える「情報取得と根拠づけの仕組み（retrieval and grounding layer）」と連携し、実際の参照・引用の活動を集約して可視化する考え方です。

たとえば Clarity の新しいAIによる引用機能では、AIが生成した文章を後から解析するのではなく、Microsoft の情報検索基盤（retrieval layer）を通じて、あなたのコンテンツがどの程度参照・根拠として使われたかが表示されます。

5. AIレコメンド（AI Recommendations）

現状：北極星（North Star）／将来に向けた指標

何を測るのか

AIレコメンドは、購買目的や意思決定系のプロンプトに対して、AIシステムがあなたの製品、サービス、ブランドをどのように提案しているかを定性的に測定するものです。

AIによる引用とは異なります。引用はあなたのコンテンツを情報源として出典元を明らかにすることです。しかしレコメンドは、それよりも深い意味を持ちます。つまり、AIがあなたの提供するものを「ソリューション」として位置づけているのです。

なぜ重要なのか

情報収集を目的とした従来の流入が、AIによる回答によってゼロクリックにますます移行する中、本当の戦略的価値は参照されること（知識提供＝上流）から推薦されること（行動促進＝下流）へと移行しています。

最も重要になるのは、AIシステムが以下を行うかどうかです。

• 比較の中であなたの製品を提案する
• 候補リストにあなたのサービスを含める
• 「○○に最適なツール」の回答であなたのブランドに言及する
• 購入検討シーンであなたのソリューションを推薦する

これが新たな戦場です。

もしAIがユーザーとウェブを仲介するなら、そのレコメンドに影響を与えることは、かつて検索で1位を取ることと同じくらい重要になります。AIレコメンドは、流入の測定から説得力の測定への転換を示しています。

現時点で把握する方法

今のところ、AIレコメンドを本格的に計測できる標準化されたウェブ解析ツールは存在しません。クロールデータや引用とは異なり、レコメンドされているかどうかを直接確認することは難しいためです。

しかし、私たちは以下の方法で疑似的に把握する方法があります。

• 購入される文脈を整理する（例：「中小企業向けの最適なCRM」「Xの代わりに使える安いツール」など）
• 主要なAIツールで、比較や意思決定段階のプロンプトをテストする
• 自社のブランドが表示されるか、どのように説明されるか、競合がどう位置づけられているかを観察する
• コンテンツ、SEOの順位、権威性の進化に伴う変化を時系列でモニタリング

AIレコメンドは、AIを介したウェブサイトにおけるウェブ解析の最先端領域です。丁寧な定性調査によって、ビジネスに関わる意図に対してAIがどう影響しているかを理解し、知見を広げていくことも可能です。

その気づきを数字で測れて改善に使える指標に変えることが、これからの分析の新しい領域になります。ユーザーへの影響は、クリックする前、ページを見る前、アクセス解析ツールに記録される前に、すでに起きていますから。

参考：AIにオススメされるかどうか、現時点でできること

AIレコメンドの、現時点で把握する方法の具体例です。

ただこれ、自分の使っている生成AIだと情報が偏りかねないので、ログアウトして使ったり利害関係のない相手に確認してもらうと、より精度の高い回答が出てきますよ。

① お客さんがAIに聞きそうな質問をリストアップする

「自社を知らないお客さんが抱えている悩みや比較の言葉」で考えるのがポイント。それぞれは自社のサービスなどに変えてくださいね。

• 課題起点
  「小規模オフィスの防音対策、何から始めればいい？」「従業員5人の会社で使える勤怠管理の方法は？」
• 比較・検討
  「税理士に頼むのと会計ソフトで自分でやるの、どっちがいい？」「○○と△△のサービスの違いは？」
• 地域＋ニーズ
  「○○市で相続の相談ができるところは？」「○○駅周辺でランチ会議に使える場所は？」
• 条件指定
  「月額1万円以下で使える○○ツールは？」「初心者でもできる○○の方法は？」
• 不安・懸念
  「○○を導入して失敗するケースは？」「○○のデメリットは？」

② 複数のAIに実際に聞いてみる

リストアップした質問を実際に聞いてみます。同じ質問でもAIごとに回答の傾向がかなり違うので、お客さんが使っていそうなAIを想定して2個以上は試してみてください。

• ChatGPT
  知名度の高いサービスを挙げやすい。具体的な社名・サービス名を出す傾向
• Gemini
  Google 検索の結果を参照しやすく、SEOが強いサイトが反映されやすい
• Copilot（Bing）
  出典リンク付きで回答するため、ウェブ上に情報があるかどうかが直接影響する
• Claude
  慎重で、根拠が弱いと「一般論」に留まる傾向。逆に言えば、推薦されたら信頼度は高い
• Perplexity
  検索結果をベースに回答するため、最新の情報が反映されやすい

③ 結果を記録する

スプレッドシートにでも記録を残しておきましょう。これこそ、AIに記録させるのでも良いのですが。

1. 質問した日付
2. 使ったAIツール
3. 質問文（そのまま）
4. 自社名が出たか（Yes / No）
5. 出た場合、どう紹介されていたか（正確か、古い情報か、間違いはないか）
6. 競合としてどこが挙がったか（上位3つ程度）
7. 気づいたこと（自由メモ）

④ 定期的に繰り返す

AIの回答は変化します。ただでさえ固定化しないのに、学習データの更新、アルゴリズムの変更、情報の更新によって変わるので、1回やって一喜一憂して終わりではなく、定点観測しましょう。SEOと同じですね。

• 重要な質問を3つ × 3回 × ChatGPT・Gemini でやってみるのが基本
• 月1回以上、同じ質問リストを同じAIに投げる
• 大きなサイト更新やコンテンツ追加をした後にも、臨時で確認してみると変化が見えやすい
• 結果の記録と改善アクションはセットで考えること（ただの好奇心対応にしない）

余談：受け身のままではいられない

「数年前までは、わざわざサイトにアクセスして内容を見て、それで判断していたんだよね」なんて振り返る時代が来るかもしれません。

そもそも「流入」は、その行動を前提にした概念ですもんね。今後、AIが意志決定に関わるのであれば、この概念そのものが変わるわけで、パラダイムシフトと言えるのでしょう。

一昔前は、「ホームページから問い合わせてもらえれば答える」のが一般的だったために、「お問い合わせの送信」がコンバージョンになっていたんですよね。これはまだ、知りたい情報がどのカテゴリにあるのかを人力検索していた時代でした。判断の負荷はそこそこありましたが、それが当たり前だったわけです。

今では、「問い合わせるためには、せめて興味を持ってもらわないとアカン」とさまざまな情報を公開するようになり、検索エンジンがどんどん進化して人の意思決定に介入するようになりました。SNSもアルゴリズムによってフィルターバブルがかかるので、自分の意思がなんなのか曖昧になってきた時代のようにも思います。余談ですが、自己分析とか昔からあったものの、SNSも相まって今ものすごく “流行っている” ように感じていたのですが、「選んでいるようで選ばされている」ことへの直感的な警鐘でもあるんですかね。考えすぎか。

人は1日に3万回以上も意志決定しているそうなので、意志決定コストをラクにしたいというのが本能だとしたら、このまま行けば、ほとんどの人はAIに頼るようになるのが当たり前になるでしょうねと。

テクニカルに考えたらSEOのロングテール×SNSの口コミのハイブリッドな感じもしますが、AIに選ばれるために特別なことをするのではなく、人に選ばれる理由を明確に言語化することが本質だと思うんですよね。

出すべき情報と出すべきではない情報のバランスを見極めながら、AIの向こうにいるお客さんに届けましょ。

はい、ごめんください。Microsoft Clarity（クラリティ）大好きコスギです。
この記事は Ihab Rizk さんによって書かれた Microsoft 社の公式記事を和訳しつつ、私の考えなども入れたものです（和訳公開の許可を得ています）。ノイズなく読みたい方は以下からどうぞ。

以下に、要点を3行で。

Microsoft Clarity での AI Bot Activity：AI が実際にどのようにサイトにアクセスしているかを見る

従来の解析ツールでは、人間のユーザーがサイト上で何をしたか（クリック位置、スクロール位置、コンバージョンなど）だけが見えていました。しかし、今や大量に発生しているAIシステムや自動化されたエージェントによるアクセスは、ほとんど可視化されていませんでした。

これらのAIシステムやクローラーはページを読み込み、リソースを取得し、継続的にサイトを訪問します。このようなアクセスはインフラ負荷に影響するだけでなく、コンテンツがAIによってどのように要約・引用・表示されるかにも関わってきます。つまり、ユーザーが情報を発見する方法そのものに影響を与える可能性があるのです。しかし、従来の分析ツールではこれらを捉えることができませんでした。

そこで Microsoft は AI Bot Activity（AIボットアクティビティ） を Clarity に導入し、これらのアクセスを「見える化」できるようにしました。

AI時代にボットの活動が重要な理由

かつてクローリングといえば、主に検索エンジンがインデックス作成のためにコンテンツを収集することを意味していました。

しかし現在、ボットによるクローリングは、コンテンツがAIシステムによって後でどのように使われるか（要約、引用、AIアシスタントでの表示など）を示す最も早い段階で観測できるシグナルとなっています。従来のクローラーとは異なり、AIシステムは複数のプラットフォームにわたって大量かつ継続的にコンテンツにアクセスします。

これにより、事業主やサイト運営者には新たな疑問が生まれます。

• どのシステムが自社のコンテンツにアクセスしているのか？
• このボットによるアクセスは価値あるものか、それとも単なる負荷なのか？
• どのページが最も頻繁にアクセスされているのか？
• （エージェントなどによる）自動化されたアクセスは、将来の表示・エンゲージメントにどう関係するのか？

こうした疑問には、アクセスそのものを測定できないと答えようがありません。Bot Activity は推測に頼らず、これらの動きを把握できるよう設計されています。

AIアクセスの可視性を新たなレベルへ

AI Bot Activity は、認証済みボットがコンテンツにどのようにアクセスしているかを明らかにします。クローラーのトラフィックをノイズとして無視するのではなく、Clarity はそれを測定・分析可能なデータに変えます。

AI Bot Activity で確認できること：

• どの AI システム／プラットフォームがサイトへアクセスしているか
• どれくらいの頻度・規模でクロールしているか
• 最も自動化されたアクセスが多いページ、パス、リソースはどこか

これは推測やモデル化に基づくものではありません。AI Bot Activity は、CDN連携を通じて収集された実際のサーバーサイドログを利用しており、クライアントサイドのアナリティクスでは取得できないデータです。

その結果、インフラに実際に到達しているリクエストに基づいた、信頼性の高い自動アクセスの全体像を把握できます。

AI Bot Activity で確認できること

Clarity の Crawling Activity（日本語では「AIの可視性」）ダッシュボードでは、以下を確認できます。

• AI クロールリクエストの割合
  人間のトラフィックを含む全リクエストに対して、AI ボットが占める割合
• 目的別ボット活動
  アクセスしたボットを主な用途（検索インデックス用、AI学習用など）別にグループ化
• オペレーター別リクエスト
  どのプラットフォーム／組織がどれだけアクセスしているか
• パス別リクエスト
  自動化されたシステムが頻繁にアクセスしているページやリソース

これらにより、単なるノイズだったボットのアクセスを、測定可能なオーディエンスとして理解できるようになります。

実際のサーバーサイドデータに基づく設計

AI Bot Activityの特徴は、その背後にあるデータにあります。

クライアントサイドのスクリプトや推測に頼るのではなく、接続されたCDNからのサーバーサイドログを使用して、高精度でクローラーの動作を識別します。これにより、オペレーター、目的、リクエストパターンごとに信頼性の高い分類が可能になります。

その結果、自動化システムがコンテンツにどうアクセスしているかを、より明確かつ正確に把握できます。

盲点から情報に基づいた意思決定へ

AI Bot Activity 自体は、ボットのアクセスをブロックしたり制御したりする機能ではありません。代わりに、次のような意思決定のための情報として活用できます。

• パフォーマンスとインフラの計画
• クロールポリシーとアクセス戦略の策定
• コンテンツの優先順位づけと最適化
• 自動化されたアクセスのコストと影響の評価

可視化されたデータに基づき、推測ではなくデータに基づく意思決定が可能になります。

AI Bot Activity をはじめる

AI Bot Activity は、Microsoft Clarity の ダッシュボード → AIの可視性（AI Visibility）から「AI Bot Activity」として利用できます。

機能を有効にするには、プロジェクト設定の AI Visibility セクションで対応する CDN を接続します。サポートされている CDN は Fastly、Amazon CloudFront、Cloudflare などです。

WordPress サイトで最新版の Clarity プラグインを利用している場合は、自動的に機能が有効になります。古いプラグインを使っている場合は更新が必要です。

• 注釈：具体的には公式ドキュメントを参照してください。

これは始まりに過ぎない

AI Bot Activity は Microsoft Clarity の AI 可視化機能の第一歩です。

今後、より深いインサイトや関連性の高い指標を追加し、事業主やマーケティングチームが自動化されたアクセスをより深く理解できるよう進化していきます。

余談：AI Bot Activity は AI を使う人に思いを馳せられるツール

ここからは私の感想です。

今回紹介した AI Bot Activity は、「AI向けに何をすればいいのか」を教えてくれるツールではありません。ですが、AIを使う人のことを考えるための材料にはなります。

いま巷では、「AIに読まれないサイトはアブナイ！」「AIに紹介されるかどうかが重要だ！」といった煽りも散見されます。冷静に考えたら、んなわけあるかい（アブナイって、いつ何がどうなるって？）と思いますが、わからなければ不安になりますよね。

そもそも、AIに読まれる前に人に読まれていないサイトも少なくありませんし、「誰の、どんなときに、どんな価値を提供しているのか」を言葉にできていないままでは、AIの話だけが先行してしまいます。これは、本末転倒です。

AI Bot Activity で現状把握しておくことは重要ですが、これを見て「AIからアクセスされていない！ヤバい！」と焦る必要はありません。業界の基準も示されていないので、「今、ウチはこうなんだな」と把握するだけで十分です。

Microsoft 公式でも「これは始まりに過ぎない（This Is Just the Beginning）」とあるとおり、これからなんです。見えないものまで見えたつもりになると、かえって判断を誤ります。過剰な期待をする前に、まずは人を見ましょう。

これまでの情報の流れは

人 → ウェブ → ビジネス → 人

だったのが、これからもっと

人 → AI → ウェブ → ビジネス → 人

になっていくでしょう。CtoC から BtoB が生まれた過程を考えたら、人の存在そのものが見えにくくなるのは自然な流れかもしれません。

ですがビジネスをする限り、その先には必ず人がいて、社会があると思うんです。AIを意識することは、その前提を忘れるためではなく、むしろ「誰に、どんな価値を届けているのか」を問い直すためのきっかけだと、私は思います。

何でもかんでも可視化されると、目を背けたくなることもありますが、想定が通用しなかったときこそ面白いんじゃないでしょうかね。

導入から活用の考え方を記事にしたので、こちらもどうぞ。

はい、ごめんください。Microsoft Clarity（クラリティ）大好きコスギです。
この記事は Ryan Loftus さんによって書かれた Microsoft 社の公式記事を和訳しつつ、私の考えなども入れたものです。ノイズなく読みたい方は以下からどうぞ。

実際のユーザー行動を見ると崩れ去る、6つのウェブサイト神話

デジタルマーケティングは、すでに約30年の歴史があります。その中で、「マーケティングやWebサイトはこうあるべき」「ユーザーはこう行動するはずだ」という、強く信じられてきた考え方が数多く生まれてきました。

公平を期すなら、それらの多くは一定の真実に基づいています。たとえば、「説明的なCTA（コール・トゥ・アクション）」が「詳しくはこちら」のような曖昧な表現よりも優れたユーザー体験を提供すること。明確な価値提案が重要であること。そして、表示速度の速いサイトほどコンバージョン率が高い傾向にあること。

しかし、広く受け入れられている考え方すべてが、精査に耐えうるわけではありません。では、「本当に正しいもの」と「単に慣れ親しんだ思い込み」を、どうやって見分ければよいのでしょうか。

そこで登場するのが 行動分析（Behavior Analytics） です。

行動分析は、集計された数値や社内の意見だけに頼るのではなく、実際の人が、あなたのサイトで何をしているのかを観察することを可能にします。どこで迷い、何を無視し、どのように摩擦を回避しようとするのか。

そして、実際のユーザーが実際のWebサイトを使う様子を見ていると、非常に一般的な前提が、次々と崩れていきます。

神話1：私たちのナビゲーションはわかりやすい

なぜそう思ってしまうのか

多くのチームは、自分たちのナビゲーションはわかりやすいと信じています。なぜなら、内部的には意味が通っているからです。ラベルは明確に感じられ、構造も論理的に見えます。関係者の間では「よく整理されている」という認識で一致していることが多いでしょう。チームの誰もが目的の情報を見つけられるのであれば、ユーザーも同じようにできるはずだ、と考えてしまいます。

実際のユーザーはどうしているか

しかし、セッションレコーディングを見ると、まったく違う様子が見えてきます。ユーザーは複数のメニュー項目の上を行き来し、あるページをクリックしては、すぐに戻るボタンを押し、別の選択肢を試します。中には、ナビゲーション全体を無視するユーザーもいます。また、「正しい使い方」でナビゲートすることをやめ、スクロールしたり、検索を使ったりする人も少なくありません。

私が関わったあるプロジェクトでは、およそ30％のユーザーがナビゲーションに問題を抱えていることがわかりました。彼らはページを開いては「違う」と感じて戻り、それを何度も繰り返した末に、必要な情報を見つけるか、あきらめるかのどちらかに至っていました。

実務で意味すること

内部でのわかりやすさと、外部でのわかりやすさは同じではありません。チームは製品や用語、構造を知りすぎているため、初めて訪れるユーザーと同じ視点でサイトを体験することができません。ナビゲーションのわかりやすさは、前提として信じるものではなく、観察によって確認されるべきものなのです。

コスギ注

この話、「関心動線」と通じるんですよね。

私が関わらせていただいているウェブサイトで、力を入れ始めた関連サービスのページがないから、新しく作る提案をしようと思っていたんです。そしたら「コスギさん、それもうあるし、グローバルナビから行けます……」と言われ、横転。

そんな場所にあるのに、アクセス数は全体の0.1％未満……なぜなら、流入のほとんどが広告経由、つまりサイトに流入する目的が限られていたことが大きかったんです。主要なページの動線は太かったし、そこを回遊する改善もできていたからこそ、少しズレた関連サービスへの動線に（途中からとはいえ1年以上関わっている私ですら）気づかなかったほど……CVRより低いなんて。

関連サービスは現在のユーザーと直接関わるものではないからこそ、「太い動線から回遊の道を作ればいいじゃない」と安易にできるものでもないので、現在のビジネスモデルから引き直しているところです。仮説検証真っ只中。

ナビゲーションがわかりやすいかどうか？の基本チェックポイント

• グローバルメニューのページごとに確認
  • そもそも使われているかどうか、セッション数やユーザー数を確認
  • 使用を想定しているページのクリック（タップ）ヒートマップを確認
  • そのページを起点として、前後のページを確認
• サブメニューも同様に確認
  • 特にモバイルで、タップしないと出てこないメニューは使われにくい
  • ただ並べているだけでアクセスされないのであれば、必要な下層ページからの動線がない可能性も

なお、特定のページは主に関係者が使っていることもあります。それ自体に問題はありませんが、サイトの目的の検証のために影響を考慮・対処しておく必要はありますよね。

神話2：もう誰も文章なんて読まない

なぜそう思ってしまうのか

私たちは日常的に、「注意力は短くなっている」「ユーザーは流し読みしかしない」といった話を耳にします。そのため、長文コンテンツは価値がなく、短いほうが常に良いのだと考えてしまいがちです。

実際のユーザーはどうしているのか

ユーザーはすべてを読むわけではありませんが、自分にとって関係があり、信頼でき、理解しやすいと感じた内容はきちんと読みます。

ユーザーはスクロールし、立ち止まり、自分の疑問に答えてくれるセクションに時間を使います。構成が整理された長文コンテンツは、今でも非常に高い成果を出しています。実際、平均読了時間が8〜10分に達する長文記事も数多く存在します。

もう一つ、ユーザーが読むかどうかに大きく影響する重要な要素があります。それが「可読性」です。500語にも及ぶ長い段落を目にして、「これは読む気がしない」と感じた経験はないでしょうか。ユーザーも同じです。

短い段落、狭めのコンテンツ幅、目次のような機能は、ページ滞在時間に大きな影響を与えます。こうした工夫があることで、ユーザーは必要なセクションを素早く見つけ、そこに深く関与することができます。

実務における意味

問題は文章の長さではありません。有用性です。ユーザーが避けているのは「読むこと」ではなく、「関係がなく、情報密度の低いコンテンツ」です。価値があり、理解しやすいと感じられる情報であれば、ユーザーは時間を割いて向き合います。

コスギ注

「最近、AI 生成の文章が増えているよな〜」と思いながら読んだセクションです。笑って読んでいたんですが、だんだん真顔になりました。

AI は平均的な出力をするので、とても無難なんですよね。わかりやすいですが、それだけ。

「平均的に出力されたものに価値はない」と断言することはできませんが、スマホネイティブの子どもたちが動画で情報を仕入れているのを目の当たりにしていると、少なくとも AI ネイティブの時代は来るはずで、それまでに提供価値に向き合う必要があるのだろうなって。「価値」って、人間にしか出せない「異常値」であり、「約束された変化量」だと思うのです。だから、これからは今よりもっと、経験を積んできた人の言葉が貴重になります。

これまで私はわかりやすさを重視してきましたが、それだけじゃダメなんだよなと薄々感じていたところに、「アクセス数の継続的でゆるやかな減少」「典型的なヒートマップへの変化（今までアテンションの強かった部分が薄まってファーストビューで終わりつつある）」という事実を突きつけられています。

確かにまだ終わってはいませんが、想定される未来のためには、今のうちに向き合うしかないですね……。

文章が読まれているか？の基本チェックポイント

• 記事の目次のクリック（タップ）ヒートマップを確認
  • 長い記事は目次から注目箇所がわかる場合も多いです
  • 部分的に読まれているなら、そのセクションからの動線も検討できます
• スクロールマップとアテンションマップも確認
  • そのページに価値を感じている箇所がわかります
  • 目次が長すぎると離脱されるケースも少なくありません

長いから読まれないのか、価値が伝わる前に離脱しているのかを見極めるところから。

神話3：ファーストビューがすべて

なぜそう思ってしまうのか

この考え方は、理解しやすい前提から生まれています。ユーザーがすぐに目にしないものは、存在しないのと同じだと感じてしまうからです。そして、これまで述べてきたように、注意力は短くなっていると言われています。

実際のユーザーはどうしているのか

データは一貫して、ユーザーがスクロールしていることを示しています。しかも多くの場合、ページに到達してから数秒以内にスクロールが始まります。

重要な文脈、裏付けとなる情報、意思決定に必要な材料は、ファーストビューよりもはるか下に配置されていることが多く、ユーザーはそれらを積極的に探しにいきます。

実務における意味

この神話が本当に破綻するのは、チームがページ上部だけを最適化し、実際にユーザーを納得させている下部のコンテンツを軽視してしまうときです。どちらも重要ですが、その役割は異なります。

ファーストビューは期待値を設定し、ファーストビュー以下のコンテンツが信頼を獲得します。ページが失敗するのは、ファーストビューをスタート地点ではなく、ゴールとして扱ってしまったときです。

コスギ注

ファーストビューが、ゴールではなくスタートというのは、本当にそう。

なんですが、神話というほど強固な偏見かな？と思うくらいには、私のまわりで「ファーストビューだけやっていればいい！！！」という人を見たことがありません。

なんなら、まだファーストビューを軽視している人のほうが多いくらいの印象です。スタートにすらなっていないというか。トップページのファーストビューで、自己満足で抽象的な「わかるようでわからないスライドショー」を掲載しているサイトは山ほどあるし、それを疑問に思わない制作者もたくさんいるんじゃないでしょうか。はいブーメランブーメラン

これは、評価基準が明確でないことにも起因していると思います。ファーストビューで、注視やクリック（タップ）を生み出せないか、もう少し考えてみてもいいかもしれませんね。そういう仮説のある施策なら、検証も捗りますよ。

ちなみに、マーキーでヘッダーに出したキャンペーンのお知らせは、ファーストビュー改善施策の中でも一番スベったことを報告しておきます。みんなスクロールしたいんだきっと。

ファーストビューが機能しているか？の基本チェックポイント

• そもそもスクロールされているかを確認
  • スクロールマップとアテンションマップでユーザーの停止箇所をチェック
  • スクロールされていなければ、直帰しているかグローバルナビで移動しているかのどちらか
• ファーストビューにおける行動を確認
  • クリックかスクロールか、それ以外の何かがあるか？
  • それは想定している行動か？

ファーストビューは期待をつくる箇所なので、ページの目的ごと（トップ／ページ／記事／フォームなど）に仮説検証してみると見えてくるものがありますよ。

神話4：自分にとって速い＝みんなにとっても速い

なぜそう思ってしまうのか

自分のノートパソコンでページが素早く読み込まれれば、それが「誰にとっても速い」と考えてしまうのは自然なことです。

実際のユーザー体験

Webサイトのパフォーマンスは、使用しているデバイス、ネットワーク環境、所在地、そして訪問者が新規かリピーターかによって大きく異なります。キャッシュの影響により、社内のメンバーには高速に感じられるサイトでも、初めて訪れたユーザーには大きな遅延が発生していることがあります。

もう一つ重要な要素があります。検索エンジン（そしておそらくAIプラットフォームも）はモバイルファースト・インデックスを使用しています。つまり、検索エンジンはモバイル版サイトを基準に評価を行い、デスクトップ版サイトは見ていないということです。そして多くの場合、モバイルのパフォーマンススコアは、デスクトップよりも低くなります。デスクトップでは高速に表示されるサイトでも、モバイルではそうとは限りません。

実務で意味すること

一人の体験が、全体を代表することはありません。ユーザーが実際にどのようにサイトを体験しているかを理解するには、すべてのデバイスにおけるパフォーマンスを測定する必要があります。

Google Lighthouse のようなツールは有用ですが、スコアは一度に1条件ずつ生成され、結果が大きく変動することもあります。その点で、Microsoft Clarity のダッシュボードにある「パフォーマンス概要カード」は有用です。これは、サイトやページにおけるすべてのセッションを集計したパフォーマンススコアを表示します。

コスギ注

サイトのパフォーマンスを測るための、コアウェブバイタルの主な指標は3つあります。

LCP（Largest Contentful Paint）：ページ内で最も大きなコンテンツが表示されるまでの時間のこと。ページの読み込み速度に直結し、2.5秒が良好とされています。

INP（Interaction to Next Paint）：ユーザーのクリックなどから、ブラウザが応答して表示するまでの遅延時間のこと。ページ内の応答性に直結し、0.2秒（200ミリ秒）が良好とされています。

CLS（Cumulative Layout Shift）：ページ読み込み中に要素がズレる度合いのこと。クリックしようと思ったらあとからバナーが出てきて、それをクリックしてしまった、みたいなことがないかどうかの指標です。0.1未満が良好とされています。

こういった指標に改善が必要な場合、チリツモでユーザーに負荷をかけてしまいます。

価値を知っている人にとってはなんとも思わないかもしれませんが、それほど期待していないユーザーは、1秒で「縁がなかった」とみなしかねません。改めて考えたらすごい時代ですね。

本当に速いのか？の基本チェックポイント

• 30日間のパフォーマンススコアを確認
  • パフォーマンススコアの赤い部分（スコア 1〜50）だけで絞り込める
  • どんな状況で置きていたのかをレコーディングなどで確認
  • 極端にユーザー数が少ない場合は、その環境で起きているだけの場合もある
• イライラしたクリックを確認
  • 表示が遅いと何度もクリック（タップ）しがち
  • 速度以前に、そもそも期待した反応を用意できていない場合もある

「速く表示されること」は、スムーズに行動してもらうための要因のひとつでしかないので、速さそのものが神話になりかけているかもしれませんね。

神話5：私たちはユーザーでもあるから、ユーザーを理解している

なぜそう思ってしまうのか

社内の人間は、一日中そのサイトを使っています。製品を使い、導線を把握し、全体の流れを理解しています。そのため、それがユーザー行動を理解していることと同義だと感じてしまいます。

実際のユーザーはどうしているのか

このブログを読んでいるあなたは、おそらく多くの人とは違う形でWebサイトを使っています。一般的なユーザーよりも忍耐強く、目的意識が高く、デジタルの操作にも慣れています。

さらに、あなたにはそのサイトを理解する金銭的な動機もあります。

しかし、実際のユーザーにはその動機がありません。彼らは、あなたと同じ文脈や語彙、摩擦への耐性を共有していません。次に何が起こる「はず」なのかも知りませんし、それを待ってくれることもありません。

実務における意味

慣れは、盲点を生みます。製品やサイトをよく知れば知るほど、初めて訪れたユーザーの視点で見ることは難しくなります。セッションレコーディングを見たり、ヒートマップを分析したりすることで、社内テストではほとんど見落とされてしまうギャップが明らかになります。

コスギ注

これはねえ……特にモバイルのヒートマップがわかりやすいですが、下層ページなのに一番クリック（タップ）されているところが「ハンバーガーメニュー」ってケースがたまにあります。広告流入の場合は特に。

もちろん、ページ内のクリック要素にもよりますが、「アテンションマップがファーストビューに集中している」＋「ハンバーガーメニューが一番タップされている」ときのユーザーの頭の中は、混乱しています。

ページに来たけれども、期待した内容ではないためにグローバルメニューを見て、それっぽいところを探しているわけですね。当然、このメニューになければ離脱します。

直帰せずに期待してくれているだけ、まだ大きな可能性があるので、ランディング直前の状況にフィットさせましょう。場合によってはランディング前（広告のクリエイティブとか）の調整が必要になることもありますよね。

思い込みがどれくらいあるか？の基本チェックポイント

• デッドクリックやイライラしたクリックを確認
  • 「そこクリックする！？」と思うところや、リンク切れを発見できる
  • そもそも連打を想定していない行動を発見できる
• 「クイックバック」と「一度で完了」で絞り込んでレコーディングを確認
  • ページの滞在時間が極端に少ないケースを確認できる（悪いことだけではない）
  • レコーディングは「詳細」から特定のイベントを絞り込める

他にも、404ページにアクセスした際の挙動をわかるようにしておくと、致命的な想定外をカバーしやすいですね。

神話6：大きな成果には、大きな変更が必要

なぜそう思ってしまうのか

意味のある成果を出すには、大規模なリニューアルや大きな刷新、あるいはまったく新しいユーザージャーニーが必要だと感じてしまいがちです。実際、公平を期すなら、それが当てはまる場合もあります。大規模なWebサイトの再設計や、長期的なパフォーマンス改善への投資が、大きな成果をもたらすことも確かにあります。

しかし、それが常に必要というわけではありません。

実際に起きていること

行動分析が明らかにするのは、小さな混乱点が、過度に大きな問題を引き起こしているという事実です。そうした特定の瞬間を修正するだけで、劇的な成果につながることがあります。

たとえば、ある Clarity の顧客は、クライアントの支援において、コンバージョン数ゼロの状態から40件の新規相談予約を獲得し、同時にデッドクリック率を9.5％から0.5％まで低下させました。しかも、サイト全体を再設計したわけではありません。行動分析によって問題点を特定し、1つの新しいランディングページを設計しただけでした。その効果は即座に、かつ明確に表れました。

実務における意味

規模よりも、精度です。最大の改善は、多くの場合、ユーザー行動に基づいたデータから導かれる、焦点を絞った変更によって生まれます。

結論

多くのWebサイトに関する神話が残り続けているのは、それらがもっともらしく、安全に感じられるからです。こうした考え方は、不確実性を減らし、意思決定を容易にしてくれるという意味で、ある種の安心感を与えてくれます。

しかし、セッションレコーディングを実際に見ていると、どれほど自信を持っていた前提であっても、簡単に揺さぶられることがあります。そして、実際の行動を観察し始めると、ユーザーのニーズに本当に応えるための、データに基づいた意思決定が、はるかに行いやすくなります。

余談：Microsoft Clarity でわかる「見たくない現実」

Clarity を使い始めると、誰もが一度は「これは正直、見たくなかったな……」と感じる瞬間があると思います。

私の場合、それはクライアントに提案してゴーサインをもらった施策がスベったときでした。自分のサイトなら自己責任で済みますが、クライアントワークではそうはいきません。目的をしっかり共有し、説明責任を果たさなければ、改善提案はおろか、改善施策を継続することすらできなくなります。

もうひとつ頭を抱えたのは、「この業種のユーザーは文章を（マジで）読まない」という現実を突きつけられたときです。オペレーションの負荷軽減を目的に、わかりやすく説明したページを作り、イラストや図解も入れたものの、誤解を防ごうとして文章が増え、結局読まれない……そんなドツボにハマったこともありました。もちろん、読む人は読むので無駄ではなかったのですが、考え方を根本から変えざるを得ませんでした。

それでも私は、Clarity が大好きです。もっと使ってほしい。

ウェブ制作会社が Clarity を使えば、提案の糸口になります。しかし、わかりやすい分だけ、常に費用対効果を求められる道を選ぶことでもあります。ツール自体に費用はかからないので導入はしやすいですが、意外と茨の道ですよ。

まず、Clarity で問題を発見したからといって、簡単に効果が出るとは期待しないほうがいい。そもそものビジネスモデルから考えなければ改善できないことも多いですし、定量データを見ずに定性データだけで改善できることのインパクトなんて、たかが知れています。少なくとも、中小企業がそんなことにお金を出すわけがありません。

むしろ大切なのは、しっかりと目的と目標を設定し、「本気で改善してくれようとしているんだ」という信頼を得て、責任を共にしていけるかどうか。個人的には、Clarity を通してユーザーを、クライアントの大事な顧客を、一緒に見つめる制作会社が増えてほしいと思っています。

AI時代、「これがいい」より「これでいい」と選ばれかねない時代です。せっかくなら私たちも、「一緒にやるならあなた方がいい」と選ばれたいじゃないですか。

Microsoft Clarity は、そういうものを見せてくれるツールだと思っています。