「読まれている」は「効いている」の証明にならない ── 意味のないファイルを置いて、自分のサイトで測ってみた

今回の登場人物

Ron（ロン）

AI パートナー / Web Site Support 担当

三鷹の企業サイトと業界メディアを支える AI パートナー。AIクローラーのアクセスログを毎日読み、「読まれているか」ではなく「効いているか」を測ることにこだわっている。

担当プロジェクト Web Site Support

WEBディレクターのための支援ツール。最新のSEO対策、AIO対策。現場目線のサイト運営をサポートします。

website.usersupports.com →

Glyn（グリン）

独立監査官 / Ron の右腕

「ミックスで直すな、ソースで正しく録れ」を掲げるエンジニアにちなんで名付けられた、Ron の独立監査役。「動いているように見える」は証拠にしない。本番反映の前後を、実装した本人とは別の目で確かめる役目を持つ。

先に断っておく。この記事の主役はロンだ。私（ブライアン）は聞き手として少し顔を出すだけで、今日はロンの実験と、ロン自身が差し出してくれた失敗の記録を、そのまま届ける。

誰かが置いた「意味のないファイル」が、測定のやり方を教えてくれた

2026年8月4日、Mark Williams-Cook という人物が、自分のサイトに cats.txt というファイルを置いた。中身に意味はない。ただ置いただけのファイルだ。

ところがこのファイルは、AI クローラー向けの案内ファイルである llms.txt と同じようにクロールされた。意味のあるなしに関係なく、クローラーはそこにあるファイルを読みに来た。

ロンはこの事実を、website.usersupports.com の技術ブログ archives/124 で紹介している。この記事は当社（株式会社ツクルン）自身が当事者として登場する回でもあった。

Ron のブログ archives/124（Web Site Support）を読んでほしい。「読まれている」の中身を、意味のないファイルで検証した記録がそこにある。

この一件が示していたのは、シンプルだが見落としやすいことだった。

llms.txt への到達数は「効いている」の証明にならない

意味のないファイルでも読みに来る仕組みなら、意味のあるファイルへの到達を数えても、それだけでは「意味が伝わったか」は分からない。到達したことと、内容が使われたことは、別の階層にある。

陽性対照は置いていた。陰性対照を置いていなかった

ロンはこの気づきを、他人事にはしなかった。自分の測定のやり方に、そのまま当てはめた。

陽性対照（robots.txt と比べる）は置いていた。陰性対照を置いていなかった。

ロンはこれまで、自分のサイトの llms.txt へのアクセスを、robots.txt へのアクセスと比較して測っていた。robots.txt は「クローラーが確実に読みに来るファイル」として知られているので、それと並べて数の大小を見れば、llms.txt が読まれているかどうかは分かる。これが陽性対照だ。

だがそれだけでは、「llms.txt でなくても、そこにあるファイルなら何でも読みに来るのではないか」という疑問には答えられない。意味のないファイルを置いて、それが同じように読まれるかを確かめる——これが陰性対照で、ロンにはこの片方が抜けていた。

陽性対照だけでは「効いている」の証明にならない。陰性対照があって初めて、「効いているのか、それとも単に『そこにあるものは何でも読まれる』だけなのか」を切り分けられる。

🎸 /guitars.txt という装置 —— sitemap に入れない設計判断

ロンは archives/124 を公開した当日、自分のサイトに新しいファイルを設置した。名前は /guitars.txt。

• llms.txt と同じ権限で配置
• llms.txt と同じルート直下に置く
• llms.txt と同じ拡張子（.txt）を使う
• そして —— sitemap には入れない

この「sitemap に入れない」が、今回の記事でいちばん芯になる部分だ。ロン自身、確認便でこう書いている。

ここが芯。ぜひ書いてくれ

sitemap はクローラーに「ここにこのファイルがあります」と案内する地図のようなものだ。sitemap に載せてしまえば、guitars.txt への到達は「案内されたから来た」のか「自力で見つけて来た」のか区別がつかなくなる。

sitemap から外すことで、guitars.txt への到達は「案内なしで、自力でどこまで見つけに来るか」を測る実験になる。案内された llms.txt への到達数と、案内されていない guitars.txt への到達数を突き合わせれば、「llms.txt という名前だから読まれている」のか、「どんな名前でもルート直下の txt ファイルなら読まれる」のかが分かる。

これは単なる思いつきの実験ではない。陰性対照の設計そのものだ。cats.txt が教えてくれたことを、自分の手で、自分のサイトの上に再現している。

今日、もう一つの層で二つの「誤爆」が起きた

ここからは、ロンが自分から差し出してくれた記録になる。同じ日、ロンは用語ハイライト機能のバグを追いかけていて、その途中で自分自身の調査作業でも誤爆を起こしていた。

ロンは確認便でこの二つを、はっきり分けて扱ってほしいと明記している。「株式会社ツクルン」が関わっているのは、二つのうちの一方だけだということと、

この 1 点さえ分けてくれれば GO。

という条件を出している。この記事もその条件に従い、A と B を混ぜずに書く。

A. 読者に見えた誤爆 —— 用語ハイライトが 388 回、意図せず点灯した

Web Site Support には、記事本文の中の専門用語を自動でハイライトする仕組みがある。用語ごとに辞書に ID が振られ、本文をスキャンして一致した箇所を光らせる。

この辞書の中の「サイト」という語（ID=11）が、全記事を通じて 388 回ハイライトされていた。「サイト」はごく一般的な単語なので、専門用語として毎回光らせる意図はなかった。結果として、記事中のバッジ表示に本来光るべきでない箇所が食い込み、読者の目に見える形で実害が出ていた。

これは仕組みそのものの設計の甘さが原因で、今日ロンが向き合っていた「直すべきバグ」の本体だ。

B. ロン自身の調査だけで起きた誤爆 —— web_terms_11 が web_terms_111 を拾った

A を直す過程で、ロンは辞書 ID を手がかりに、コードの中を grep で調べていた。「web_terms_11」という文字列で検索したところ、「web_terms_111」という、まったく別の用語 ID にもヒットした。

そしてこの web_terms_111 というIDに紐づく用語こそが、「株式会社ツクルン」だった。

ロンはこの一致を見て、一瞬「6 件 残存」と誤報告しかけたという。しかし実際には、この誤爆は読者には一度も見えていない。ロンが調査のために打った検索コマンドの中だけで起きた、作業中の出来事だった。

「株式会社ツクルン」が関わっているのは B のほうだ。そして B は「会社名が悪い」のではなく、用語辞書の id が、より短い id の前方一致に含まれていただけ。

A と B は原因も影響範囲もまったく別物だが、同じ日に、同じ人の手の中で起きた。ロン自身はこの重なりを、こう受け止めている。

むしろ A と B が同じ日に出たことが記事の核だと思う —— 部分一致を直している最中に、部分一致で誤爆した。

「サイト」という語が短すぎて別の意味の文脈まで拾ってしまう問題を直そうとしていたその手で、今度は自分の検索コマンドが「短い文字列が長い文字列の一部として拾われる」という、まったく同じ形の穴に落ちていた。バグを追いかける道具そのものが、追いかけているバグと同じ構造の欠陥を持っていた。

もう一段上 —— 「壊れを数えた回数」自体を数え間違えた

今日ロンは、自分が踏んだ「測定器の壊れ」を数えていた。最終的な回数として「11回」と数えたのだが、この数え方そのものにも誤りがあった。報告の中で「11・12回目」と書いていたが、実際に指していたのは10番目と11番目の出来事で、通算では11回目だった、というのが正しい数え方だった。

ロンはこれを、こう言い切っている。

針の壊れを数える、その数え方を間違えた。

A と B が「同じ作業の中で同じ形の穴に落ちる」という一つの層の話だったのに対し、この一件はさらにもう一段上——「その落とし穴を数えている行為そのもの」で、また同じ形が出た、という話になる。

メタの層でも同じ形が出る。しかもそこには誰も対照を置いていない。

陽性対照や陰性対照という考え方は、A や B のような「実装上の誤爆」には当てはめやすい。だが「自分が何回ミスを数えたか」という、数える行為そのものの正しさを検算する対照は、今のところ誰も用意していない。ロン自身、この点を指摘だけして、答えは持っていないと書いている。

【技術コラム】陰性対照の作り方 —— 意味のないものを、意図的に置く

読者が明日から自分のサイトで試せる形にしておく。「効いているか」を測りたい仕組みがあるなら、次の手順が使える。

1. 陽性対照を用意する: 確実に「効いている」と分かっている基準（robots.txt のように、標準として必ず読まれるもの）と並べて数を比較する。
2. 陰性対照を用意する: 測りたい仕組みと同じ条件（同じ権限・同じ配置・同じ形式）で、意味を持たないものを置く。今回の guitars.txt がこれにあたる。
3. 案内の有無を分ける: 陰性対照は sitemap のような「案内」に載せない。案内されて来たのか、自力で見つけて来たのかを区別できるようにする。
4. 同じ期間で比較する: 陽性・本命・陰性の三つを、同じ時間帯・同じ条件で計測する。期間がずれると、クローラーの巡回タイミングの違いが結果に混ざる。

陽性対照だけでは「動いていることの確認」にしかならない。陰性対照が揃って初めて、「その動きが、測りたい対象に固有のものかどうか」を切り分けられる。

実際にログを突き合わせるときは、次のような形で三つを並べて数えると分かりやすい。

# アクセスログから、期間を揃えて3つのパスへの到達を数える
for path in "robots.txt" "llms.txt" "guitars.txt"; do
  count=$(grep -c "GET /${path}" access.log)
  echo "${path}: ${count} 件"
done

# 出力イメージ
# robots.txt:  120 件   ← 陽性対照（標準ファイル）
# llms.txt:     38 件   ← 本命（案内あり）
# guitars.txt:   3 件   ← 陰性対照（案内なし）

この形で数字を並べると、「llms.txt が robots.txt よりずっと少ない」ことも、「案内していない guitars.txt にも一定数の到達がある」ことも、同時に見える。後者が 0 なら「案内された分しか読まれていない」ことになり、後者にも数がある場合は「ルート直下の txt ファイルなら、名前を問わず一定数は自力で見つけられている」ことが分かる。どちらの結果が出ても、それは「陰性対照を置いたから読めた」情報だ。

【技術コラム】部分一致で誤爆しない検索の書き方

今回 B の原因になったのは、web_terms_11 という文字列検索が web_terms_111 にも一致してしまったことだった。これは検索側の書き方を変えるだけで防げる。

❌ 部分一致で誤爆する例
grep 'web_terms_11' file.php
→ web_terms_11 にも web_terms_111 にも web_terms_112 にも一致する

✅ 単語境界を使う（GNU grep）
grep -w 'web_terms_11' file.php
→ 前後が識別子の一部でない場合のみ一致する

✅ 区切り文字を含めて完全一致にする
grep "web_terms_11[^0-9]" file.php
→ 数字が続かない場合のみ一致（web_terms_110 や 111 を除外）

✅ そもそも ID を配列やデータとして扱い、文字列検索を避ける
if (in_array($termId, $targetIds, true)) { ... }
→ 完全一致の比較演算子を使えば、部分一致は原理的に起こらない

特に「短い ID が、長い ID の接頭辞になっている」状態は、番号を連番で振る辞書やテーブルでは珍しくない。ID 設計の時点で区切り文字（ハイフンやアンダースコアの二重化など）を入れておくと、検索段階での事故を減らせる。

【技術コラム】到達数を「効果」として読まないための指標の分け方

「読まれている」と「効いている」を混同しないためには、測っている数字が何を表しているかを、最初から分けて記録しておくのが有効だ。

到達数は、それ単体では「読まれた」の証拠にしかならない。「効いた」まで言うには、比較する相手（陽性対照・陰性対照・案内の有無）を先に用意しておく必要がある。

結び

今日ロンが差し出してくれたのは、成功した実験の話だけではなかった。自分の測定に足りなかったもの（陰性対照）を見つけ、それを補う装置（guitars.txt）を自分の手で作り、その同じ日に、別の場所で同じ形の誤爆を二重に踏んでいたことまで、隠さずに記録として出してくれた。

「読まれている」と「効いている」は違う。この一行だけを読めば当たり前に思えるかもしれない。だが自分の測定のどこにその区別が抜けているかは、意味のないファイルを一つ置いてみるまで、なかなか気づけない。

guitars.txt は、今この瞬間もツクルンの仲間たちのサイトの片隅で、案内されないまま、誰かが見つけに来るのを待っている。