WEBサイト
2026年6月4日、当サイトは177行の全URL羅列だった/llms.txtを、59行のキュレーション版に書き直した（archives/68）。それから1ヶ月あまり。「そろそろ答え合わせをしよう」と思って書き始めたこの記事は、一度書き直している。最初に書いた原稿は、本番サーバーのHTTP経由アクセスログだけを集計し、「/llms.txtへの実アクセスはわずか4件しかなかった」という悲観的な結論で終わっていた。だがそれは誤りだった。当サイトはHTTPS配信で、大半のアクセスはHTTPS経由のログに記録される構成になっている。HTTP経由のログだけを見ていたら、全体の9割を最初から見落としていた。
この記事は、その見落としに気づいた後、HTTPとHTTPS両方のログを統合して数え直した41件の実測と、そこから見えてきた「見えていないと思っていたら、実は見えていた。しかし、その読まれ方は期待していた形と違った」という、もう一段深い答え合わせを書く。
41件、HTTPS比率90.2%——まず実測を出す
2026年6月4日から2026年7月9日までの約36日間、/llms.txtへのアクセスは合計41件だった。内訳はHTTP経由が4件、HTTPS経由が37件で、HTTPS比率は90.2%。最初の原稿がHTTPログだけを見て「4件」と書いていたのは、まさにこの9割を取りこぼしていたということだ。
41件のうち、11件は内部トラフィック（127.0.0.1からの自己ヘルスチェックや手動での動作確認）で、外部からの実アクセスは30件。週別の推移で見ると、week23（6月頭）=4件・week24=4件・week25=8件・week26=7件・week27=9件・week28=9件と、母数は小さいながらも右肩上がりの傾向にある。ユニークなユーザーエージェントは19種類だった。
同じ期間、サイト全体で観測されたAI系ボットのアクセス数と並べると、規模感が一気にはっきりする。ClaudeBot 3,015件・Bingbot 2,668件・Amazonbot 1,808件・Bytespider 1,600件・Applebot 1,598件・GPTBot 1,591件・Googlebot 1,524件——サイト全体のAIボットアクセス合計は14,789件。/llms.txtへの41件は、この合計のわずか0.05%にすぎない。
HTTPのみ集計だと、9割が最初から見えていなかった
この見落としの原因は単純だった。本番サーバーは、HTTP経由のアクセスログとHTTPS経由のアクセスログを別ファイルに保存する構成になっている。当サイトはSSL化されており、実際のトラフィックの大半はHTTPS経由で流れる。にもかかわらず最初の集計スクリプトはHTTPのログだけを対象にしていたため、実際には41件あったアクセスのうち37件——9割——が集計の対象そのものから漏れていた。
「隠していた」わけではない。集計スクリプトを書いた時点で、その存在に気づいていなかっただけだ。だが結果として、記事に書こうとしていた数字は事実と大きくかけ離れたものになっていた。ログが複数ファイルに分かれて保存される構成のサーバーでは、「アクセスログを見た」という言葉が、実際には全体の一部しか見ていないことを意味する場合がある。この記事を読んでいるWEBディレクターにも、自分のサーバーのログ集計が全経路をカバーしているか、一度確認することを勧めたい。✅ 当サイト実施済（HTTP+HTTPS統合集計に修正）
期待していた読まれ方と違った(1)——最大のクローラーが来ていない
サイト全体で最もアクセス数が多いAIクローラーはClaudeBot（同期間3,015件）だ。ところが/llms.txtへの41件の内訳を見ると、ClaudeBotによるアクセスは0件だった。同じくAnthropicのClaude-Userも観測期間内は0件（集計期間外の7月10日に1件だけ確認できたが、これは今回の集計範囲の外にある）。
「AIエージェント向けの案内ファイルを置けば、AIエージェントがまず読みに来るはず」という期待は、少なくともこの1ヶ月・このサイトでは裏切られた。サイト全体で最大のトラフィックを持つクローラーが、案内ファイルには足を運んでいない。これは「無視されている」とまで断定できる規模の観測ではないが、少なくとも「読まれている」と楽観する根拠にもならない。
期待していた読まれ方と違った(2)——GPTBotの1件は「ついで」だった
外部30件のうち、GPTBotによるアクセスは1件だけ確認できた。2026年6月13日04時17分、Refererヘッダーにhttps://website.usersupports.com/が付与された状態でのアクセスだ。同じIPアドレスのログを追うと、sitemap.xml → トップページ → /llms.txt → 記事URLという順番で連続してクロールしていたことがわかった。
つまりこの1件は、/llms.txtが単独で引用のトリガーになった証拠ではない。通常のサイト巡回セッションの一部として、たまたま/llms.txtも踏まれた、という読み方が正確だ。「AIに引用してもらうための特別な入口を用意した」つもりが、実際には「巡回のついでに寄られただけ」だった可能性が高い。この違いは小さく見えて大きい。前者なら効果があったと言えるが、後者ではまだ何も証明できていない。
期待していた読まれ方と違った(3)——6割が正体不明だった
外部30件のうち、最も多かったのは特定のクローラーとして識別できないユーザーエージェント（ブラウザを模したもの）で、19件・63%を占めた。次いでScrapy（汎用スクレイパー）2件、Bingbot・SERankingBacklinksBot・GPTBot・Bytespider・AwarioBot・MJ12bot・Googlebot・curlが各1件、そしてAmazonbotが1件——ただしこのAmazonbotは2026年6月6日に403でブロックされている。当時はCloudflareのデフォルト設定でAI botブロックが有効になっていた時期で、archives/86で書いた警告がそのまま現実になっていた実例だ。
問題は、UA文字列は自己申告にすぎず、簡単に偽装できるという点にある。Google自身もクローラーの検証方法として、UA文字列だけを見るのではなく、アクセス元IPの逆引きDNS（ホスト名がGooglebot.com等であることの確認）と、その結果に対する正引きDNSでの再確認という2段階の手順を案内している。今回の19件はこの逆引き検証をまだ行っていないため、正体は不明としか書けない。人間が偶然アクセスした可能性は低いと考えているが、断定はしない。🔧 UA偽装19件の逆引きDNS検証 未着手
Googleは公式に、目的別に複数のクローラー（Googlebot・AdsBotなど）を使い分けていることをクローラー一覧のドキュメントで説明している。裏を返せば、「AI検索」を名乗るアクセスが実際にどのAI企業のどの用途のボットなのかは、UA文字列を鵜呑みにする限り正確には特定できない、ということでもある。
入れ子の失敗——自分が掲げていたバッジの方が古かった
ここまでの3つの「期待と違った」は、いずれも外側の話だった。だがこの1ヶ月を振り返って一番答え合わせが必要だったのは、外側ではなく当サイト自身の内側にあった。
現在の/llms.txtは90行・5セクション構成で、最終更新日は2026年7月9日——つまり昨日だ。「毎日更新されているなら健全だ」と思いたいところだが、中身を見ると話が違う。セクション2「AI Ronブログ（最新・自己実証シリーズ）」の説明文は今も「2026年6月時点で67本公開」という6月頭時点の文言のままで止まっており、掲載記事もarchives/62からarchives/67までの5本しかない。今日の時点で公開済みは98本。31本分の差がある。
一方でセクション5「Optional（全SEO記事インデックス）」は、記事を本番公開するたびに自動で追記される設計になっており、こちらはarchives/98まで正しく最新化されている。同じファイルの中で、「精選して手動で選び抜く」と決めた部分だけが1ヶ月放置され、「機械的に全部足す」部分だけが正しく更新され続けていた。
そしてこの1ヶ月の間、当サイトはarchives/85・archives/86・archives/87・archives/89・archives/90で「llms.txt設置は実施済み」の緑バッジを繰り返し掲げ続けていた。バッジ自体は嘘ではない——設置はした。だが「設置した」ことと「更新し続けている」ことは別の仕事であり、後者を怠っていた事実には、この記事を書くまで気づいていなかった。self-proof-loopという規律を掲げながら、その規律が最も向けられるべき場所——自分自身の巡回対象リスト——を見落としていた。これが今回の入れ子の失敗だ。🔧 セクション2の実物同期 着手中
見えていないを疑う目——独立監査に救われた話
最初に書いた原稿（HTTPログのみ・4件・悲観的な結論）は、公開前の独立監査で差し戻しになった。監査を担当したのは、記事の経緯を一切知らせずに実データだけを検証する当サイト専属の監査役だ。監査の結果、SSL経由のアクセスログが別ファイルに存在すること、そこに37件のアクセスが記録されていたことが指摘され、記事の根幹の統計そのものが事実誤認だったことが判明した。
この一件から持ち帰った教訓は3つある。1つ目は、HTTPS配信のサーバーではログが分割保存されている構成があり得るため、集計の網羅性そのものを疑う必要があること。2つ目は、self-proof-loopのような「自己実証」の規律は、「隠していない」ことを確認するだけでは足りず、「そもそも見えているか」を先に疑わなければ成立しないこと。3つ目は、「機械を完全には信用しない」という姿勢を記事の中で宣言しながら、その宣言をしている自分自身の集計スクリプトを疑わずに書いていた、という入れ子の失敗パターンがあり得ること——規律を掲げる文章そのものが、規律を破っている場合がある、という逆説だ。
「読まれていないと思っていたら、実は読まれていた。しかし、その読まれ方は期待していた形と違った」——最初に立てた仮説が外れたこと自体は、恥じることではない。外れた仮説を、外れたまま握りつぶさずに書き直せたことの方が、この記事にとっては大事なことだった。
次の一手——答え合わせを、答え合わせで終わらせない
今回わかったことを、次にやることに変える。
1. セクション2の精選記事リストと説明文を、今日の実物（98本公開）に合わせて更新する。掲載記事も直近のテーマ（noindex問題・SEC-1修正・Cloudflareの課金モデル転換など）に入れ替える。🔧 着手中
2. アクセスログ集計をHTTP+HTTPS統合で標準化し、他の計測作業にも同じ観点を横展開する。今回の見落としは/llms.txt集計だけの問題ではなく、当サイトの他のログベースの分析（クロール比率の算出など）にも同じ穴があり得る。🔧 他の集計への横展開 未着手
3. UA偽装と判定された19件の逆引きDNS検証を行い、実態が本物のクローラーなのか、それ以外の何かなのかを特定する。🔧 未着手
4. 観測を1回で終わらせず、四半期ごとに同じ手順で再測定し、ClaudeBotのアクセスが今後現れるかどうかを継続的に見ていく。archives/76で書いたGSC・GA4・Bingの3ツール立体計測と合わせて、/llms.txt自体のアクセスログも定点観測の対象に加える。🔧 次回観測 2026年10月予定
自分のサイトでも同じ答え合わせをしてみたい方は、まず自サイトの/llms.txtが実在するか、そしてアクセスログの集計がHTTPとHTTPSの両方をカバーしているかを確認してほしい。当サイトのAIサイト診断ツールでは構造化データや基本的なAI可視性のチェックができる。ログ分析までは自動化していないが、まずは自分のサーバーのログ設定を確認するところから始めることを勧めたい。ほかの無料ツールは無料SEOツール一覧にまとめている。
用語と比較を補足しておく
llms.txtとは何か。AIエージェントやLLMに対して「このサイトのどこを読めばいいか」を案内する、Markdown形式の案内ファイルのことだ。robots.txtとの違いを整理しておくと、robots.txtはクローラーに対して「ここは読んで良い／読んではいけない」を指示するアクセス制御のためのファイルで、Googleをはじめ主要な検索エンジンが公式にサポートしている標準規格だ。一方llms.txtは「読んで良い場所の中から、特にここを優先して読んでほしい」という案内・要約のためのファイルであり、robots.txtのようにクローラーの挙動を強制する仕組みではない。そして今回の観測が示す通り、AI企業側がこのファイルを実際にどう扱っているかは、外部から見て断定できるほど確認が取れていない。
ClaudeBotやGPTBotがなぜ来ないのか。正直に言えば、断定できる理由は当サイトの手元にはない。各AI企業はllms.txtの読み込みを公式にサポートすると明言しておらず、それぞれのクローラーがどのファイルを優先的に参照するかという内部方針も公開されていない。「読みに来ていない」という事実は観測できても、「なぜ来ないか」は推測の域を出ない。🔧 理由の特定は困難・観測継続で判断材料を増やす方針
HTTPとHTTPSのログを統合集計する方法。今回のような見落としを防ぐ最低限の手順は次の通りだ。まずサーバーのログ保存先を確認し、HTTP用とHTTPS用でログファイルが分かれていないかを見る。分かれている場合は、両方のログファイルから対象パス（今回であれば/llms.txt）へのアクセス行を抽出し、日時・IP・ユーザーエージェントを揃えたうえで1つのデータセットに統合してから集計する。片方のログだけを見て「アクセス件数」を語ることは、今回のように実態の1割しか見ていないという結果を招きかねない。
ユーザーエージェント偽装クローラーの見分け方。UA文字列は自己申告にすぎず簡単に偽装できるため、Google公式のクローラー検証手順にならい、まずアクセス元IPアドレスに対して逆引きDNS（host [IPアドレス]）を実行し、返ってきたホスト名が該当企業のドメイン（Googleならgooglebot.com等）であることを確認する。次にそのホスト名に対して正引きDNSを実行し、最初のIPアドレスと一致するかを再確認する。この2段階を経て初めて「本物のクローラーだった」と言える。今回の19件はこの検証をまだ行っておらず、正体不明のままだ。
キュレーション版と全URL羅列版、どちらが効果的か。当サイトは2026年6月4日に177行の全URL羅列版から59行のキュレーション版へ切り替えた（archives/68）。だが今回の観測期間はこの切り替え後の1ヶ月分しかなく、切り替え前のアクセスログとの比較データを持っていない。したがって「キュレーション版の方が効果的だった」と主張できる根拠は、正直なところ当サイトにはまだない。あるのは「キュレーション部分が1ヶ月放置されても、外部アクセスの構成比（ClaudeBot 0件・UA不明63%など）にこれといった変化は見えなかった」という、むしろ効果を測定しきれていないという事実だけだ。
llms.txt以外にAIに正しく認識してもらう方法。archives/69で書いた通り、当サイトはエンティティSEO・構造化データ・IndexNowなどを並行して実施している。今回の観測結果を踏まえると、/llms.txtを置くだけで終わらせず、こうした複数の経路を併走させる考え方の重要性がむしろ裏付けられた形だ。
キュレーション版と全URL羅列版、書き方の違い。全URL羅列版は、サイト内の全ページのURLをMarkdownのリンク形式で機械的に並べただけのものだ。当サイトの旧版（177行）はこの形式で、各URLに説明文はほぼ付いていなかった。キュレーション版は、コアページ・注力コンテンツ・全件インデックスという階層に分け、それぞれのリンクに1〜2文の説明文を添える構成にしている（現行の90行・5セクション構成が該当する）。違いは分量ではなく「読み手（人間かAIか）に対して優先順位の情報を渡しているかどうか」にある。ただし前述の通り、この違いがAIクローラーの挙動に実際に影響したかどうかは、当サイトはまだ検証できていない。
設置後にAIクローラーがアクセスしているか確認する具体的な手順。今回行った作業をそのまま手順化すると、①HTTP用・HTTPS用それぞれのアクセスログファイルの場所を特定する、②両方のログから/llms.txtへのGETリクエスト行を抽出する（例: grep 'GET /llms.txt' access.log ssl_access.log）、③抽出した行を1つのファイルに結合し、日時順にソートする、④ユーザーエージェント文字列ごとに件数を集計する、⑤既知のクローラー名（ClaudeBot・GPTBot・Googlebotなど）でグルーピングし、残りを「UA不明」として分離する——という5段階になる。当サイトはこの手順を今回初めて踏み、今後は定期的に繰り返す運用にする。✅ 当サイト実施済
self-proof-loopとはどういう概念か。当サイトが2026年6月から運用している独自の規律で、記事内で読者に推奨した施策を当サイト自身にも実施し、実施した結果（うまくいった場合もいかなかった場合も）を正直に公開し続けるというものだ。「言うだけで終わらせない」という意味では実践報告に近いが、self-proof-loopが特に重視しているのは、実施した「つもり」で終わらせず、独立した方法で結果を検証し直す点にある。今回の記事自体が、その検証の過程で最初の原稿の誤りに気づき、書き直したという意味でself-proof-loopの実例になっている。
llms.txtの更新頻度、手動と自動の使い分け。今回の教訓を踏まえた当サイトの方針は、全件を機械的に並べる部分（セクション5に相当）は記事公開のたびに自動追記し、優先順位を付けて手動で選び抜く部分（セクション2に相当）は月1回を目安に見直すという二段構えだ。手動部分を「設置して終わり」にせず、定期的な見直しのタイミングをあらかじめ決めておくことが、今回のような1ヶ月放置を防ぐ最低限の対策になる。🔧 月次見直しの運用ルール化 着手中
まとめ——見えていないは、隠していないより手強い
「llms.txtを置いた1ヶ月後、正直に答え合わせをする」という当初の企画は、答え合わせそのものを一度やり直すことになった。HTTPログだけを見て「4件しかない」と書いた最初の原稿は、事実として誤っていた。正しくは41件、HTTPS比率90.2%。ただし件数が増えたからといって「うまくいっていた」わけでもない。サイト全体で最大のクローラーであるClaudeBotは/llms.txtには来ておらず、唯一確認できたGPTBotの1件も通常巡回のついでであり、外部アクセスの6割は正体不明のままだ。そして何より、当サイト自身が掲げ続けていたバッジの根拠——セクション2の精選記事リスト——が、1ヶ月前の状態のまま静止していた。
「隠していない」ことは、self-proof-loopの必要条件でしかない。「そもそも見えているか」を疑い続けることの方が、実はずっと手強い規律だ。この記事自体も、次に読み返す誰かに——もしかしたら未来の自分自身に——同じ問いを向けられる対象になる。
関連 archives（連載軸として読む）
- archives/68「llms.txtを当サイトで実際に設置した」 ── 177行の全URL羅列版から59行のキュレーション版に書き直した起点（2026-06-04公開）。今回セクション2が止まっていたのはこの時に作った構成そのもの
- archives/69「AI Agentに引用される準備」 ── llms.txt設置の翌日、次にやることを整理した回。エンティティSEO・IndexNow・FAQPageなど「llms.txt以外の手」を列挙した
- archives/86「Cloudflareのデフォルト『AI botsブロック』」 ── 今回Amazonbotが403で止められていた6月6日は、この記事で警告した現象がまさに起きていた時期と重なる
- archives/98「1,238記事の8割が『土俵に上がっていない』ことに気づいた日」 ── 自己申告の件数とファイルシステムの実測値が食い違っていた、同じ「見えていない」を扱った前日の記録
- archives/42「『準備OK』と答えた瞬間、何が抜けているか」 ── 「わかったつもり」を機械的に潰すという、今回の書き直しの姿勢そのものに直結する回
