「AIに読まれているか」は3つの層で別々に測る

自社サイトが生成AIに読まれているか、引用されているかを測ろうとして、2か月ほど回り道をしました。結論から書きます。

この記事の数字の出どころは、当社サイトに置いた元データです（期間・母数・除外条件つき）。引用するときは、こちらを出典にしてください。
https://braincommunity.jp/jissoku/ai-kensaku.html

「AIに読まれているか」を1つの数で答えようとすると、必ず間違えます。 別々の層が3つあり、それぞれ違う道具でしか測れません。そして3つのうち2つは、放っておくと嘘の数を返します。

実際、同じサイト・ほぼ同じ期間で、この3つの数はこうなりました。

層	測る道具	数
① AIのクローラが取りに来たか	サーバのアクセスログ	13日で 267回（名乗りは1,092回）
② AIの答えに出たか	Search Console の生成AI機能	3か月で 204回
③ 人が実際に来たか	GA4 の参照元	75日で 9セッション

②と③は23倍ちがいます。どれも正しい数です。ちがう事実を数えているだけです。

この記事に載せたのは抜粋です。名乗り11種の内訳（全部・成功・部品を除いた後・存在しない所）、3種類ごとの数、ユーザ起点で実際に読まれたページ、測り方と「この数字で言えないこと」は、元データの方にだけ載せています。
→ https://braincommunity.jp/jissoku/ai-kensaku.html

層① サーバログ：来たか

一番下の層は「AIの名乗りを持つ巡回器が、実際にHTTPリクエストを投げてきたか」です。これはサーバのアクセスログにしかありません。

計測範囲＝2026-09-06〜09-18 の13日間（日本時間）、ログ25,110行（この13日に残っていた全量）。

名乗り	回数
ClaudeBot	422
bingbot	361
Googlebot	201
OAI-SearchBot	143
PerplexityBot	92
Google-Extended	50

ここで最初の罠です。

罠1：名乗りの6割が偽物だった

OAI-SearchBot の 143回のうち89回、PerplexityBot の 92回のうち84回 は、/.env などへのリクエストで、応答は404でした。存在しないファイルを探しています。AIの名乗りを借りた脆弱性スキャナです。

つまり生の回数をそのまま「AIが来ている」と読むと、片方は6割、もう片方は9割が水増しになります。

数える前に、最低でもこの3つで絞ります。

1. ステータスが 200 のものだけを数える
2. robots.txt・sitemap.xml・favicon・画像を除く
3. 同じIPが短時間に存在しないパスを連打していないか見る

同じ13日にこの絞り込みをかけると、AIの名乗り8種の要求は 1,092回 → 成功451回 → 部品を除いて267回 になりました。約4分の3が落ちます。

罠2：AIの名乗りは3種類あり、混ぜると意味が変わる

同じ「AIのクローラ」でも、目的が3つに分かれます。ここを混ぜたまま合計すると、何も言っていない数ができあがります。

種類	代表的な名乗り	来た意味
学習・取り込み	GPTBot / ClaudeBot	蔵書に入っただけ。誰かに読まれたことを意味しない
検索索引	OAI-SearchBot / Claude-SearchBot / PerplexityBot	AI検索の索引を作っている
ユーザ起点	ChatGPT-User / Claude-User / Perplexity-User	いま誰かの質問に答えるために取りに来ている

「AI検索に出たらしい」と言えるのは3つ目だけです。1つ目がいくら多くても、それは誰にも読まれていない可能性があります。

ただし、その3つ目の名乗りも偽物だらけでした。Perplexity-User の69回は1回も成功していません（全部404）。Claude-User は135回のうち122回、ChatGPT-User は133回のうち85回が404です。成功した読み取りに絞ると、ユーザ起点は13日で52回でした。

そして Google-Extended は、そもそもクローラではありません。Googleの公式ドキュメントに、Google検索の掲載順位にもランキングにも影響しないと明記されています。これはクロールの主体ではなく、学習利用の可否を示す制御トークンです。アクセスログに名前が出ることはあっても、それを「検索に効いた／効かない」の根拠にはできません。

層② Search Console：AIの答えに出たか

次の層は「生成AIの回答面に、自サイトが表示されたか」です。Google Search Console の「生成AI機能」で見られます。

計測範囲＝2026-06-19〜09-18 の3か月。

表示回数 204回
出たページ 73枚
上位はトップ93回、会社概要9回、著者ページ6回

同じころの普通の検索（API・2026-06-23〜09-18・88日）はこうでした。

表示 2,431 ／クリック 211 ／ CTR 8.68% ／平均掲載順位 12.3

AI面での表示は、通常検索の表示の約8%。 無視できる量ではありません。

ただしこのレポートには検索語の軸がありません（ページ・国・デバイス・日だけ）。「どの質問で出たか」は分かりません。ここを勘違いして「AI検索での流入キーワードが分かる」と言うと、後で全部やり直しになります。

層③ GA4：人が実際に来たか

一番上の層は「AIの回答を読んだ人が、リンクを踏んでサイトに来たか」です。

計測範囲＝記録が残っている 2026-07-09〜09-21 の75日、全1,229セッション（06-23 からを指定しましたが、記録は 07-09 からしかありません）。

gemini.google.com から 6
chatgpt.com から 3
合計 9セッション（0.73%）
perplexity・copilot ほかは 0

罠3：この 0 は「来ていない」ではない

Gemini をはじめ、参照元(リファラ)を送らない経路がかなりあります。 ここで 0 と出ても、それは「来ていない」の証明ではなく、「この道具では測れない」という意味です。

この 0 は、下限として読むのが正しい。 原因を名指ししてはいけない数です。計測が存在しない面について、原因を語ることはできません。

数字が23倍ちがう理由

並べ直すと、こうです。

AIの答えに出た       204回  （3か月・Search Console）
         ↓  ここで大半が落ちる
リンクを踏んで来た      9回  （90日・GA4／参照元を送る経路のみ）

AIの回答は、リンクを踏ませないことが仕事です。答えがその場で出るからです。だから「表示」と「来訪」の落差は、検索結果のCTRよりはるかに大きくなります。

ここから言えることは2つ。

AI面の効果を「来訪」だけで測ると、ほぼゼロに見える。 効いていないのではなく、その指標では見えない
逆に「表示」だけを効果と呼ぶのも間違い。 表示は来訪でも売上でもない

判定は「上下したか」ではなく、差に説明が付くかで行います。

罠4：robots.txt を開けても、引用されないことがある

これは実装の話です。

AIのクローラに特定のディレクトリを開けようとして、robots.txt に Allow: を足しました。それでも引用されませんでした。原因は別のところにありました。

配信側のヘッダに X-Robots-Tag: noai, noimageai が全ページに付いたままだったのです。

robots.txt        → Allow: /guide/     （開けた）
ホスティングの設定  → X-Robots-Tag: noai （全ページに残っていた）
                   ↑ こちらが勝つ

2か所が揃って初めて開きます。 片方だけ直すと「開けたつもり」で終わります。

しかもこの2か所は別のファイルにあり、別の人（別の作業）が触ります。だから、同じ並びであることを機械に検査させました。

# robots.txt で塞いでいる場所と、配信設定の X-Robots-Tag の場所が
# 一致していなければ止める
assert set(robots_disallow()) == set(xrobots_paths()), \
    "robots.txt と配信設定の並びがずれている"

この検査には、自己検査を12項目付けています。素で通る／故意に壊したら止まる／戻したらまた通る、の3つ揃いです。片方だけ直した状態を、機械が必ず捕まえます。

さらに同種の穴がもう1つありました。サイトのアイコン3本が、AIクローラ向けの Allow のどれにも入っていませんでした。 開けたつもりの面でも、そこから参照される画像は取りに行けません。開ける単位は「ページ」ではなく「そのページが必要とするもの全部」です。

罠5：robots.txt に日本語のコメントを書かない

最後は細かいですが、実害のある話です。

一時期、robots.txt に日本語で「生成AIの学習を…」といった注意書きを書いていました。robots.txt は誰でも開けます。 自社の警戒をそこに書くのは、気づいていなかった人に発想を与えるのと同じです。

機械が読む指示だけを置き、意図は社内の記録に書きます。

ところが、一度は日本語0文字・コメント0行に直したのに、その後の作業で「なぜ開けたか」の注釈が少しずつ戻り、この記事を書いた時点の本番は注釈41行・日本語923字でした。数える見張りが無かったからです。いまは見張りが毎回数え、注釈が1行でも入ると配信が止まります。

まとめ：測り方の手順

1. サーバログで「来たか」を数える
   - status=200 だけ
   - robots.txt / sitemap / 画像 / favicon を除く
   - 学習・検索索引・ユーザ起点の3つに分けて別々に数える
   - 名乗りを疑う（404が多い名乗りは偽物）

2. Search Console の生成AI機能で「答えに出たか」を見る
   - 検索語の軸は無い。そこは分からないと認める

3. GA4 で「人が来たか」を見る
   - 0 は下限。参照元を送らない経路がある

4. 3つを同じ表に並べる
   - 1つでも欠けると、どこで落ちたかを名指しできない

どの数にも、期間・母数・除外条件を必ず添えます。添えられない数は出しません。

2か月かけて分かったのは、AI検索の対策そのものより、自分が何を測っているのかを取り違えないほうが難しいということでした。ここに挙げた5つの罠は、全部いちど踏んでいます。

元データと引用のしかた

この記事の数字は、期間・母数・除外条件と「この数字で言えないこと」を添えて、当社サイトに置いています。数字を引用するときは、記事ではなく元データを出典にしてください。そのまま貼れる形はこうです。

出典：ブレインコミュニティ合同会社「AIに読まれているかを、3つの層に分けて測った記録」
https://braincommunity.jp/jissoku/ai-kensaku.html （2026-09-23 測定）

当社が自分で測ったほかの数字も、同じ置き場にまとめています。
→ https://braincommunity.jp/jissoku/

（2026-09-23 訂正：①の回数、名乗りごとの回数、③の期間と母数を、元データに合わせて直しました。①の「1,214回」は出どころを辿れない数でした。）

業務システムの内製化と、AI活用の受託開発をしています。
ブレインコミュニティ合同会社 — https://braincommunity.jp/