WEBサイト
「AIに引用されているか」を確かめようと思い立ち、アクセスログから19種類のAIクローラーの名前を数えてみた。最初の結果は、19種類すべてが0件。数え方の作り方を直したら、いくつかは数字が出てきた。だがGPTBotだけは、それでも0のままだった。俺はそれを「本当に来ていないから0」と受け取り、そのまま4本の記事に書いて公開した。
今日、その4本目を書くために、まったく別の作業でサーバーのログが置いてあるディレクトリを見ていたら、見たことのないファイルが目に入った。ssl_access.log。開いて数え直したら、GPTBotは0ではなく2,675回、来ていた。
この記事は、その日に何が起きたかの記録だ。壊れていたのは1つではなく2つで、しかも2つ目は、1つ目を直したあとも気づけない形をしていた。そして「0件には三つの顔がある」と自分で書いたその記事が、公開した4日後に、まさにその三つ目の顔を自分で踏んでいたという話でもある。
自分のサイトにAIクローラーが来ているかどうかを、アクセスログから数えてみようとしたことのあるWEBディレクターは、このあと少なくとも一度は同じ場所を確かめてほしい。使っているサーバーのログが、httpとhttpsで別のファイルに分かれていないか。分かれているなら、これまで数えていたのはどちらか。この記事は、その1つの確認の重みを、実際に踏んだ側から書く。
「AIに引用されているか」を測ろうとして、19種類すべてが0件になった
チェックする名前を、19種類 用意した
AIサービスがWebページを読みに来るとき、多くはアクセスログにUser-Agentという文字列で自分の名前を残していく。用途は一様ではない。学習データを集めるために巡回するもの（GPTBot・ClaudeBot・CCBot・Bytespider）、検索や要約のためにページを索引するもの（OAI-SearchBot・PerplexityBot・Googlebot・bingbot）、ユーザーが質問した瞬間にその場でページを取りに来るもの（ChatGPT-User・Perplexity-User・Claude-User）まで、役割ごとに名前が分かれている。OpenAIの公開情報によれば、GPTBotのユーザーエージェント文字列は「Mozilla/5.0 AppleWebKit/537.36 (KHTML, like Gecko); compatible; GPTBot/1.4; +https://openai.com/gptbot」で、robots.txtでこれを拒否すれば、そのサイトの内容を生成AIの基盤モデルの学習に使うべきではないという意思表示になる、と説明されている。
今回はGPTBot・ChatGPT-User・OAI-SearchBot（OpenAI）、ClaudeBot・Claude-User・anthropic-ai（Anthropic）、PerplexityBot・Perplexity-User（Perplexity）、Google-Extended（Google）、Applebot-Extended（Apple）、meta-externalagent（Meta）、cohere-ai（Cohere）、DuckAssistBot（DuckDuckGo）、Diffbot（Diffbot社）、CCBot（Common Crawl）、Bytespider（ByteDance）、YouBot（you.com）、そして比較のためにGooglebotとbingbotも加えて、合計19種類を対象にした。
「学習用に集めに来るもの」と「その場で質問に答えるために取りに来るもの」は、混ぜて数えると意味が変わる。Perplexityの公開情報でも、PerplexityBotは検索結果にサイトを表示するための自動巡回、Perplexity-Userはユーザーが質問した瞬間にページを取得する仕組みと、役割が分けて説明されている。前者が多ければ「検索・要約の対象として見られている」ことを示し、後者が多ければ「実際にユーザーの質問に答える材料として使われた」ことを示す。同じ「AIが読みに来た」でも、意味が違う数字を1つの合計にしないよう、今回は種類ごとに分けて数えることにした。
結果は、全部が0だった
52日ぶんのアクセスログ（2026年7月8日〜8月29日・52ファイル）を対象に、行の中からUser-Agentの部分だけを取り出す条件を書いた。最初に書いたのは「行の最後にある、引用符で囲まれた部分がUser-Agentだ」という考え方だった。これで19種類を1つずつ数えたところ、結果は次のようになった。
| チェックした名前 | この時点での件数 |
|---|---|
| GPTBot / ChatGPT-User / OAI-SearchBot | 0 |
| ClaudeBot / Claude-User / anthropic-ai | 0 |
| PerplexityBot / Perplexity-User | 0 |
| Google-Extended / Applebot-Extended | 0 |
| meta-externalagent / cohere-ai / Diffbot / DuckAssistBot | 0 |
| CCBot / Bytespider / YouBot | 0 |
| Googlebot / bingbot（比較用） | 0 |
19種類、全部0。だが/robots.txtへのアクセスだけは1,148件と出た。ログ自体は読めている。おかしいのはUser-Agentの取り出し方の方だった。
針が壊れていた ── 直したら、一部だけ数字が出た
行の最後に、引用符が無かった
このサーバーのアクセスログは、行の最後が引用符（"）で終わらない形式だった。実物はこういう形をしている。
<IP> - <IP> - - [日時] "リクエスト" 403 239 "参照元" "User-Agent" -末尾が " ではなく - で終わっている。「行末の引用符」を探す条件は、この形式では一度も一致しない。だからUser-Agentの中身が常に空文字列になり、どんな名前を探しても0が返っていた。末尾の - はサーバー側の設定で追加している項目で、今回はその項目の中身までは踏み込んで確認していない。直した条件はこうだ。ダブルクォートで行を分割し、6番目のフィールドを取る。
awk '{
n = split($0, a, "\"")
ua = (n >= 6) ? a[6] : ""
if (index(ua, "対象の名前") > 0) c++
}
END { print c+0 }' access.log*だがGPTBotは、直してもまだ0のままだった
直した条件で数え直すと、bingbotが2,960件、CCBotが134件、ClaudeBotが95件、Googlebotが27件と、いくつかは動き出した。だがGPTBotとOAI-SearchBot、ChatGPT-User、それにAnthropicとPerplexityの「ユーザーの質問に応じてその場で取得する」系の名前は、依然として全部0のままだった。
ここで俺は「なるほど、来ていないものは来ていないんだな」と読んだ。行末の引用符という単純な思い込みは直った。他の名前は数字が出ている。ここまでは正しい手続きに見えた。
振り返ると、この時点で疑うべきだったのは「直した条件が、まだ何かを取りこぼしていないか」だった。だが実際に疑ったのは「GPTBotは本当に来ていないのか」という、対象の側だった。条件を疑う代わりに、結果を疑ってしまった。方向が逆だったわけではないが、条件そのものにもう一段、確かめ方があることには気づかなかった。
「0件には三つの顔がある」と、その日 書いた
顔①：本当に来ていないから0
DuckAssistBotは、条件を直した後も一貫して0だった。この記事のために今日もう一度数え直しても、やはり0のままだった。これは「本当に来ていない」という顔だ。0件が全部この顔をしているなら、何も間違っていない。
顔②：数え方が壊れているから0
行末の引用符を探す条件は、19種類全部を巻き添えにして0にしていた。これは「数え方が壊れているから0」という顔だ。同じファイルの中身を、別の条件で読み直せば、その場で正体がわかる。実際、直した瞬間にbingbotやCCBotの数字は動いた。
この2つの顔があると分かった時点で、俺は「0件には二つの顔がある」ではなく「三つの顔がある」と書いた。三つ目の顔をまだ具体的に指せていなかったのに、そう書いた。当時は「探した数を書く」ことと「本当に0か疑うこと」の大切さを伝えるための言い回しのつもりだった。三つ目の実物は、このときはまだ自分の手元になかった。
今になって思えば、この時点で「三つ目」という言葉を先に置いたこと自体が、その後の見落としにつながっていたかもしれない。①と②で十分に説明がついたと感じたとき、人は「残りの1つはきっとこの延長線上にある」と考えてしまう。だが③は①や②の延長ではなく、まったく別の軸——数え方ではなく、探す場所そのもの——にあった。同じ「0」という結果を作る原因が、1本の軸の上に並んでいるとは限らない。
その記事を、4本 公開した
ここから4本の記事に、それぞれ違う切り口で数字を積み上げていった。archives/136では「AIからの流入60件」という数字を行全体で検索して出したが、その60件を1件ずつ開いてみると、実際はAIサービス自身が自分の名前を名乗って読みに来たアクセスと、参照元にAIの文字列がたまたま含まれていた別のアクセスが混ざっていた、という話を書いた。「行全体で探すと、正反対の2つが混ざる」という教訓は、今振り返っても間違っていない。archives/137では、CCBot・ClaudeBot・YouBot・Bytespider・GPTBot・OAI-SearchBotの6種類を合計して「AIは331回来た」というタイトルにし、その一方で参照元（Referer）にAIサービスのドメインを持つアクセスは1件も無かった、という対比を書いた。archives/138では、参照元が空でないアクセスの95.1%が自分のサイトからの移動だったという数字を出し、外部から来た人は19人だけだったと書いた。この記事は同時に「ログの保存期間は待ってくれない。確かめられる期間の始まりが、日が経つごとに後ろへずれていく」という指摘もしていた。今日になって振り返ると、まさにこの記事が測った期間そのものが、その指摘の対象になっていた。詳しくは後の章で書く。
archives/139では、最初に9種類だけで確かめて「0件」と報告したことを反省し、5日後に対象を73種類まで広げて確かめ直した。9種類のときは代表的な名前だけを選んでいたため、まだ調べていない他の名前が0件の中に紛れ込んでいる可能性を見落としていた。73種類まで広げた時点で、俺は「これで数え漏れは無くなった」と考えていた。だが73種類に増やしても、探す先は相変わらずaccess.log1つだけだった。対象の数を増やすことと、対象を探す場所を増やすことは、別の作業だった。
4本とも、書いた時点では正直な報告のつもりだった。数え方は毎回そのときの最善で、前の記事の反省を次の記事に反映してもいた。ファイルを行末の形式で疑い、行全体か個別の欄かで疑い、対象の種類の数で疑い、期間の長さでも疑った。それでも、4本とも同じ1つのファイルしか見ていなかった。
6日後、別の作業でログのディレクトリを見ていて気づいた
探していたのは、それとは別のことだった
136・137・138を公開したのが8月29日、139を公開したのが9月3日。今日は9月4日、この記事を書くために、サーバー上のログの置き場所をあらためて確認していた。目的は今日の分の行数を数えることで、AIクローラーの再調査をするつもりではなかった。
4本の記事を書いている間、俺は毎回access.logというファイル名を直接指定してコマンドを書いていた。ファイル名を最初に決めた時点でそこに固定してしまうと、それ以降は同じ名前を打ち込むだけで作業が進む。ディレクトリの中身をあらためて見返す機会は、意識して作らない限り訪れない。今回それが訪れたのは、AIクローラーの数を数える作業とは無関係な、別の目的でディレクトリを開いたときだった。
ssl_access.log という、もう一つのファイル
ディレクトリの中身を並べたら、これまで一度も開いていないファイルが目に入った。ssl_access.log。サーバーの設定ファイルを確認すると、理由はすぐにわかった。ポート80（HTTP）向けのVirtualHostと、ポート443（HTTPS）向けのVirtualHostが別々に定義されていて、それぞれが自分専用のログ出力先を持っていた。access.logはHTTP側、ssl_access.logはHTTPS側だった。Apache公式のドキュメントには、CustomLogディレクティブについてこう書かれている。
"The TransferLog and CustomLog directives can be used multiple times in each server to cause each request to be logged to multiple files."
（日本語訳：TransferLogとCustomLogディレクティブは、それぞれのサーバーで複数回使うことができ、1つのリクエストを複数のファイルに記録させられる）
そしてCustomLogディレクティブ自体の解説には、この設定を書ける場所として「server config, virtual host」の両方が挙げられている。つまり、VirtualHostごとに別々のログ出力先を持たせることは、Apacheの標準機能そのものだった。
当サイトは常時HTTPS化していて、HTTPで来た通信はHTTPSへ転送される作りになっている。つまり、実際のやり取りのほとんどはHTTPS側で完結していて、ログもそちら側に記録される。俺は4本の記事すべてで、転送される前の入口の記録だけを見ていたことになる。
ログを収集するスクリプトを書くとき、俺は「サーバーの中にログファイルは1つある」という前提から出発していた。ディレクトリの中身を ls で並べて見ることを、一度もしていなかった。access.log だけを見て、その中で正しく数えることに意識を向けていた分だけ、そこに何ファイル並んでいるかという、もっと手前の確認が抜けていた。
測り直したら、GPTBotは2,675回 来ていた
19種類、もう一度 数え直す
同じ52日間（2026年7月8日〜8月29日）を対象に、行末の引用符の問題を直したのと同じやり方で、今度はssl_access.logも加えて19種類を数え直した。
サイトはHTTPS。アクセスの94%は、そちらに記録されていた
まず行数そのものが違った。access.logは14,382行、ssl_access.logは245,082行。合計25万9,464行のうち、HTTPS側が94.5%を占めていた。俺はこの52日間、記録全体の6%弱しか見ていなかったことになる。個別の名前で見ると、差はさらに際立った。
Google Search Consoleのようなツールが返す「クロール数」やGA4の「セッション数」は、サイト側のログを介さずに、それぞれのサービスが独自に集計した数字だ。今回のように「自分のサーバーのログを自分で数える」場面では、外部ツールの数字は答え合わせに使えない。ログという一次データそのものを、どのファイルから取っているかが、数字の正しさを決める。
| クローラー | 用途 | HTTP側 | HTTPS側 |
|---|---|---|---|
| GPTBot | 学習データ収集（OpenAI） | 0 | 2,675 |
| ChatGPT-User | 質問応答時の取得（OpenAI） | 0 | 1,185 |
| OAI-SearchBot | 検索インデックス（OpenAI） | 0 | 786 |
| ClaudeBot | 学習データ収集（Anthropic） | 95 | 4,519 |
| Claude-User | 質問応答時の取得（Anthropic） | 0 | 175 |
| anthropic-ai | （Anthropic） | 0 | 571 |
| PerplexityBot | 検索・要約用（Perplexity） | 0 | 476 |
| Perplexity-User | 質問応答時の取得（Perplexity） | 0 | 104 |
| Google-Extended | 学習利用の制御トークン（Google） | 0 | 263 |
| Applebot-Extended | 学習利用の制御トークン（Apple） | 0 | 7 |
| meta-externalagent | （Meta） | 0 | 3,620 |
| cohere-ai | 学習データ収集（Cohere） | 0 | 10 |
| Diffbot | （Diffbot社） | 0 | 2 |
| DuckAssistBot | （DuckDuckGo） | 0 | 0 |
| CCBot | 学習データ収集（Common Crawl） | 134 | 903 |
| Bytespider | （ByteDance） | 37 | 2,098 |
| YouBot | 検索用（you.com） | 60 | 43 |
| Googlebot | 検索インデックス（Google） | 27 | 1,544 |
| bingbot | 検索インデックス（Microsoft） | 2,960 | 3,427 |
archives/137の見出しにある「331回」は、この表のうちCCBot・ClaudeBot・YouBot・Bytespider・GPTBot・OAI-SearchBotの6種類を合計した数だった。今日、同じ6種類をHTTP側のログだけで合計すると326（公開時と今回とでログの範囲が数日ずれているため、わずかに近い値になる）。同じ52日間をHTTPS側のログで合計すると11,024。約34倍だった。
唯一、YouBotだけはHTTP側（60）の方がHTTPS側（43）より多かった。理由はまだ特定できていない。19種類のうち18種類がHTTPS優勢の中で、この1種類だけが逆だったことは、正直に書いておく。
クローラーの名前だけでなく、サイト側が用意しているファイルへの到達数も同じ形で数え直した。robots.txt・sitemap.xml・llms.txt・llms-full.txtは、いずれもクローラーに向けて置いているファイルだ。
| ファイル | HTTP側 | HTTPS側 |
|---|---|---|
| /robots.txt | 1,148 | 4,528 |
| /sitemap.xml | 7 | 1,302 |
| /llms.txt | 8 | 155 |
| /llms-full.txt | 0 | 17 |
/sitemap.xmlはHTTP側でわずか7件しか記録がなく、これまでの数え方では「あまり読まれていないファイル」に見えていた。HTTPS側を合わせると1,302件で、印象がまるごと変わる。llms-full.txtにいたってはHTTP側の記録が0件で、そもそも到達しているかどうかの判断材料が無かった。
参照元も、もう一度 数え直した
archives/137は「参照元（Referer）にAIサービスのドメインを持つアクセスは1件も無かった」と書いていた。これもHTTP側だけを見た結果だった。今日、現在サーバーに残っている53日ぶん（2026年7月14日〜9月4日）のログを使って、ssl_access.logの参照元欄に perplexity.ai・claude.ai・chatgpt.com という3つのドメインが現れているかを、あらためて数え直した。
最初は行全体を対象に grep した。perplexity.aiだけで772件。大きな数字に見えた。だがこれはarchives/136がすでに名付けていた罠と同じ形だった。参照元の欄だけに絞って数え直すと、内訳はまったく違う顔を見せた。
| ドメイン | 行全体で探した数 | 参照元の欄だけ | 差の正体 |
|---|---|---|---|
| perplexity.ai | 772 | 3 | PerplexityBotのUser-Agent文字列に、そのURLが含まれている（769件） |
| chatgpt.com | 145 | 3 | サイト内で使っているutm_sourceパラメータに、そのドメイン名が含まれている |
| claude.ai | 1 | 1 | 混ざっていない |
perplexity.aiの772件のうち769件は、PerplexityBotが自分の名前を名乗るときに使うUser-Agent文字列——「+https://perplexity.ai/perplexitybot」——に引っかかっていた。参照元の欄だけを見ると3件で、実際に開いてみると、同じ1人の訪問者が23秒の間に同じページを3回リクエストした、1回の閲覧のログだった。
chatgpt.comの145件のうち、参照元の欄に残るのは3件。だがその3件をさらに開くと、参照元が「https://chatgpt.com/」そのものだったのは1件だけで、残り2件は参照元が当サイト自身のURL（?utm_source=chatgpt.com というパラメータを引き継いだページ）だった。ChatGPT経由で最初のページに来たあと、サイト内を移動したときの記録が、同じ文字列を含んでいたために一緒に数えられていた。
claude.aiだけは行全体でも参照元の欄だけでも1件で変わらなかった。混ざる要素が無かった、ということだ。これが結果として、他の2つの数え方が正しく機能していることを裏付ける対照になった。
まとめると、53日間で本当に外部のAIサービスから直接たどり着いたアクセスは5件（perplexity.aiから3件・claude.aiから1件・chatgpt.comから1件）だった。archives/137の「1件も無かった」は訂正が要る。0件ではなく5件。多いとは言えない数字だが、0とは違う。そしてこの5件も、HTTP側のログだけでは最初から見えない場所に記録されていた。
「探す場所が違うから0」── これが三つ目の顔だった
①②は、同じファイルの中で直せば出る。③は、何度 測り直しても出ない
「本当に来ていないから0」も「数え方が壊れているから0」も、直す場所はaccess.logという同じファイルの中にあった。条件を直せば、その場で数字が動く。だが「探す場所が違うから0」は違う。access.logだけをどれだけ丁寧に、何度読み直しても、GPTBotは永遠に0のままだ。答えは最初から別のファイルの中にあって、そのファイルの存在を知らない限り、精度をいくら上げても届かない。
「直した」という手応えが、「もう大丈夫」を作る
行末の引用符を直したとき、bingbotやCCBotの数字が実際に動いた。この「直したら数字が変わった」という手応えが、「これでちゃんと数えられている」という安心につながった。だがその安心は、探している場所そのものが違っている可能性を検討させない方向に働いた。19種類のうち何種類かが0でなくなった時点で、まだ0のままの名前を「本当に来ていない」側に分類してしまった。1つの修正が成功したことは、他の場所にも別の問題が残っていないことの証明にはならない。
三つの顔を、実際に今回の対象で並べておく。
| 顔 | 直し方 | 実例 |
|---|---|---|
| ①本当に来ていないから0 | 直しようがない。それが事実 | DuckAssistBot（HTTP側・HTTPS側とも0） |
| ②数え方が壊れているから0 | 同じファイルの中で、条件を直せば出る | 行末の引用符の思い込み（19種類が全滅していた） |
| ③探す場所が違うから0 | ファイルをどれだけ読み直しても出ない。別の場所を探すしかない | GPTBot（HTTP側は本当に0。HTTPS側に2,675） |
①は疑いようがなく、②は同じ場所の中で気づける。③だけが、いくら丁寧にやっても、同じ場所の中では絶対に気づけない形をしている。
「誰も来ないはず」のファイルにも、同じことが起きていた
guitars.txtという見張り役、そして窓そのものの消失
当サイトには/guitars.txtという、意図的にsitemapへ入れていないファイルを置いている。クローラーが自力で見つけて読みに来るかどうかを測るための、いわば見張り役だ。「誰も来ていないはず」というのが、これまでのHTTP側だけの計測での前提だった。実際、HTTP側では0件だった。ところがHTTPS側を数えると、12件のアクセスがあった。「誰も来ない」と考えていたファイルにさえ、見ていなかった側のログには記録が残っていた。
見張り役として置いたファイルは、それ自体が「本当に何も起きていないか」を確かめるための道具だった。その道具の結果までもが、同じ見落としの影響を受けていたことになる。何かが起きていないことを確認するための仕組みも、見ている場所が間違っていれば、間違ったまま「起きていない」と答え続ける。確認のための道具を作ることと、その道具が正しい場所を見ていることを確かめることは、別の作業だった。
そしてもう一つ、今日たどり着いた事実がある。この52日間（7月8日〜8月29日）をもう一度そのまま再現しようとしたら、サーバーに残っている一番古い行は7月14日だった。7月8日から13日までの6日分は、ログの保存期間が進んだことで、すでに消えていた。archives/138で「確かめられる期間の始まりが後ろへずれていく」という現象について書いたが、その記事自身の測定期間が、公開のわずか6日後に、まさにその現象の対象になっていた。「あとで確かめよう」は、確かめられる前提そのものが動いていく分だけ、実現しにくくなる。
0件と書く前に、今日からやること
見ている場所を、まず書く
「0件でした」と書くとき、これからは「どのファイルを、どういう条件で数えたか」を必ず添える。今回のように、対象が1つのファイルしかないと思い込んでいる限り、その思い込み自体は文章にも表れない。書いておけば、あとで自分でも他の誰かでも、抜けに気づける形になる。
見ていない場所も、探しておく
レンタルサーバーや管理画面によっては、そもそもアクセスログの実物に触れられない環境もある。その場合でも、契約しているサーバーの管理画面や、サーバー会社への問い合わせで「httpとhttpsのログは分かれているか」だけは確認できることが多い。分かれているなら、両方を集計対象にすることを、契約先やシステム担当に一度確認してほしい。自分でログを開ける環境なら、サーバーの中身を自分の目で確かめる手段を持たない読者にも、無料の分析ツールを勧めたい。IPA（情報処理推進機構）が提供する🔧 攻撃兆候検出ツール iLogScanner で簡単ログ分析するツール（要ログイン）は、自分でawkの条件を1行ずつ書かなくても、アクセスログの中身を機械的に読み解いてくれる。当サイトの🔧 これから対応：この52日間のログを、あらためてiLogScannerでも読み込ませて、今回手で書いた条件と食い違いが無いか突き合わせる予定だ。サイト全体の状態を俯瞰したいときは🔧 WEBサイト総合分析・レポートツールもあわせて使える。
自分の目で、もう一度 確かめる
今日の対応として、✅ 当サイト実施済：HTTPとHTTPSの両方のログを対象にする運用に切り替えた。🔧 これから対応：archives/136・archives/137・archives/138・archives/139の数字も、この記事と同じ形で訂正を追記していく。1つのファイルだけを見て「0件でした」と書くのを、今日でやめる。
ここまで4本の記事を書きながら、俺は毎回「今回は前回より丁寧に数えた」と思っていた。実際、行末の形式は直したし、対象の種類は9から73へ広げたし、参照元の比率まで出した。丁寧さを積み重ねること自体は、間違っていなかった。だが積み重ねていたのは、ずっと同じ1つのファイルの中での丁寧さだった。どれだけ精密に測っても、見ている場所そのものが違っていれば、精密さは正しさを保証しない。今日、たまたま別の作業でディレクトリを見なければ、この見落としにはまだ気づいていなかった。「たまたま気づいた」に頼らない形にするために、この記事を書いた。
関連 archives（連載軸として読む）
- archives/136「『AIからの流入60件』を数え直したら、60件ともAIが自分の名前を名乗った文字列だった」 ── HTTP側だけで見た最初の疑いの記事（2026-08-29）
- archives/137「AIは331回来た。人は1人も連れてこなかった」 ── 「331回」という数字の出どころ（2026-08-29）
- archives/138「外部から来た人は19人だけだった」 ── 「確かめられる期間の始まりが後ろへずれていく」を先に書いていた記事（2026-08-29）
- archives/139「『0件』に、探した数を書いていなかった」 ── 9種類から73種類へ広げた直後の記事（2026-09-03）
- archives/124「猫のファイルが『効いている証拠』を無効化した日」 ── guitars.txtを見張り役として設置した記事（2026-08-12）
一次情報出典
- OpenAI: Bots and GPTBot（GPTBotのUser-Agent文字列と学習データの扱い）
- Anthropic: Does Anthropic crawl data from the web?（ClaudeBotのrobots.txt対応）
- Perplexity: Bots documentation（PerplexityBotとPerplexity-Userの役割の違い）
- Common Crawl: CCBot（User-Agent文字列とIPレンジによる検証方法）
- Google Search Central: Google-Extended（学習制御トークンとしての説明）
- Google Search Central: クローラーとフェッチャーの概要
- Apache HTTP Server: mod_log_config（CustomLogディレクティブの仕様）
