robots.txt は、誰が書いているのか — 観測が正しくても、直し方は変わる

• 最終検証日：2026年8月26日
• Methodology バージョン：2026.08.228（訂正）
• 本文中の「2026.08.xx」：その変更・訂正を記録した Methodology の版の番号です（診断基準 v26 とは別の版番号）。公開した版は書き換えず、訂正は新しい版として残しています
• 位置づけ：SILVE の運用方針。業界標準ではありません
• 関連記事：AI クローラーの分類 / 掲載資格はどこにあるか / 効果検証
• 難易度：実務（診断結果をどう読み、どこを直すかの話です）

要点

一文で言うと — robots.txt に何が書いてあるかは、読めば分かります。しかし「どこを直せば書き換わるか」は、そのファイルを誰が生成しているかで変わります。

• 観測のやり方は、生成元に依存しません。 RFC 9309 と Google の仕様は robots.txt の取得場所を定めていますが、その内容を誰が生成したかを要件にはしていません
• 改善手順は、生成元に依存します。 オリジン側のファイルだけを編集しても、生成された区画の内容は生成元の設定で決まります
• ただし、私たちが取得した内容が各社の受け取る内容と同じだとは言えません。 同じ URI でも、要求によって返る表現は変わり得ます
• これは新しい問題ではありません。 Google は自社の資料で「CMS では robots.txt を直接編集できないことがある」と、以前から明記しています
• 実務では —— 診断結果が「拒否されている」と出たら、直す前に、その行がどこで書かれているかを見てください。 直す場所が違えば、いくら編集しても変わりません

この記事を書いた理由は、私たちの誤りです

Cloudflare がある告知を出したのは 2026 年 8 月 21 日（協定世界時。日本時間では 22 日）、私たちの週次の収集がそれを拾ったのは 8 月 25 日でした。読んでみると、SILVE が出している「直し方」が、ある場合に誤りになると分かりました。

そのときまで、私たちはこう書いていました。

意図せず拒否している場合は、robots.txt の Disallow を見直し、掲載経路のクローラーを許可します。

その robots.txt を、サイトの持ち主が書いているとは限りません。

規格は「誰が書いたか」を見ていない

まず、観測の側から確かめます。

取得側の規格（RFC 9309）は、robots.txt の場所をこう定めています。

The rules MUST be accessible in a file named "/robots.txt" (all lowercase) in the top-level path of the service.

提供元自身の仕様も同じです。

You must place the robots.txt file in the top-level directory of a site, on a supported protocol.

どちらも、取得場所を定めています。そして、その内容を誰が生成したかは要件にしていません。

これは SILVE にとって重要な確認です。CDN が生成していようと、CMS が出力していようと、公開されているレスポンスを取得して解析するというやり方は変わりません。

生成元が何であることも、私たちの観測のやり方を変える理由にはなりません。

ただし「各社も同じ内容を受け取る」とは言えません

ここは、はっきり分けておきます。

RFC 9309 が定めているのは URI・書式・取得失敗時の扱い・キャッシュなどであって、同じ URI へのすべての要求に同じ内容が返ることまでは定めていません。 HTTP はもともと、1 つの資源が複数の表現を持ち得ることを認めています。

A target resource might be provided with, or be capable of generating, multiple representations that are each intended to reflect the resource's current state.

要求ヘッダやネットワーク上の条件によって応答が変わる構成は、実際にあり得ます。したがって SILVE が確認できるのは「診断の時点で、SILVE の要求に対して返ってきた内容」までです。

これは私たちが「取得の安定性」で既に採っている射程と同じ形です —— SILVE が 403 を受けたことは、各社のクローラーも 403 を受けることの証拠になりません。同じ規律を robots.txt にも当てます。

変わるのは、直す場所のほう

Cloudflare は 2026 年 8 月 21 日、Bot Preference Sync という仕組みを告知しました。ダッシュボードで設定した AI ボットの方針を、robots.txt へ反映するというものです。

Bot Preference Sync is a new feature that keeps your robots.txt reflecting the AI bot preferences you've already set for Search, Agent, and Training on the Cloudflare zone-level dashboard. If a site owner already has a robots.txt file, the contents added by Bot Preference Sync will be prepended to the existing material, so any existing Disallow directives are maintained.

出力はこういう形になると説明されています。

# BEGIN Cloudflare Bot Preference Sync

User-agent: TrainingBot1
User-agent: TrainingBot2
Disallow: /

# END Cloudflare Bot Preference Sync

自分で書いた Disallow は保持されます。残るのは別の問題です —— この区画の内容は、ファイルではなく Cloudflare 側の設定によって決まります。 オリジンの robots.txt をいくら編集しても、設定を変えなければ、この区画は設定どおりのままです。

表明することと、遮断することは違う

なお、robots.txt の Disallow は、遮断でも、検索結果からの除外でもありません。別々の資料が、別々のことを言っています。

まず規格は、アクセスの認可ではないと明記しています。

These rules are not a form of access authorization.

Google が言っているのは別のことで、クロールを拒否しても検索結果から消えるとは限らないというほうです。

it is not a mechanism for keeping a web page out of Google

そして今回の主題にいちばん近いのは、Cloudflare 自身が同じ記事の冒頭で 2 つを分けていることです。

Some mechanisms simply state your preference, assuming best intent from crawlers, and other approaches actually lock down content by outright blocking with a Bot Management solution.

Bot Preference Sync は、Cloudflare 側の方針と、公開する robots.txt 上の表明を揃える仕組みです。表明と遮断が同じものになるわけではありません。

この項目が数えているのは、robots.txt 上の表明です。特定の AI クローラーがネットワーク層で実際に遮断されているかどうかは、この項目では確認していません。

もう 1 つの訂正 — 告知を、現在の事実として書いてしまった

私たちは 2026.08.225 で、この仕組みについて「新規の顧客は既定でオン」と書きました。間違っていたのは内容ではなく、時制です。

Cloudflare は確かに「For all new customers, Bot Preference Sync will be on by default」と書いています。ただし、同じ記事はこうも書いています。

Bot Preference Sync will be available to all customers, on every plan, in the coming week.

つまり「正式に提供されたあと、新規顧客には既定でオンになる」という予定です。私たちはそれを「いま、そうなっている」と現在の仕様として書きました。

なお、この告知の中には時制の揺れがあります。冒頭では「available to all customers from the Free tier to Enterprise」と書かれている一方、末尾では「in the coming week」、既存顧客については「upcoming launch」です。したがって私たちは「提供前だ」とも断定しません。少なくとも、全顧客への提供が完了したことを、告知時点の事実としては扱いません。2026 年 8 月 26 日に提供元の変更履歴を見ましたが、該当の項目は見当たりませんでした（見落としの可能性は排除できません）。

告知を読んだその日に、予定を現在形へ変えて書いた —— これは私たちが記事の側で繰り返し戒めていることです。2026.08.226 で訂正しました。

外から観測できる範囲でも確かめました。Cloudflare を通っている 6 サイトの robots.txt を取得しましたが、この区画は見つかりませんでした。ただし これは「まだ出ていない」の証拠にはなりません。設定していないだけかもしれず、6 件では何も言えません。分からないので、分からないと書きます。

今回の本質 — 新しい仕様への追随漏れではなかった

サイトの持ち主が robots.txt を直接編集できるとは限らないことは、Google が以前から自社の資料に書いています。

If you use a CMS, such as Wix or Blogger, you might not need to (or be able to) edit your robots.txt file directly. Instead, your CMS might expose a search settings page or some other mechanism to tell search engines whether or not to crawl your page.

しかも私たちは、同じ形の注意書きを別の項目では書けていました。「インデックスの禁止」の手順には「HTTP ヘッダでの指定はページのソースに出てこないため、サーバやリバースプロキシの設定も確認してください」とあります。

「見えている場所と、直す場所は違う」 —— まったく同じ話が、noindex では書けていて robots.txt では書けていませんでした。

つまり今回の誤りは、新しい仕様への追随漏れではありません。既に知っていた原則を、改善手順へ一貫して適用できていなかったことが原因です。告知は気づく契機であって、原因ではありません。

公開内容が変わっても、各社への反映は同時ではない

もう 1 つ、手順に関わる事実があります。取得側はキャッシュします。

Crawlers SHOULD NOT use the cached version for more than 24 hours, unless the robots.txt file is unreachable.

Google generally caches the contents of robots.txt file for up to 24 hours, but may cache it longer in situations where refreshing the cached version isn't possible.

向きに注意してください。キャッシュするのは取得側です。SILVE は前回の取得内容を再利用せず、再診断のたびに取得し直します。

ただし、それは「すぐ新しい内容が返る」という意味ではありません。 配信側のキャッシュや、設定変更そのものの反映の時間差があれば、私たちの次の取得にも古い内容が返り得ます。

そのうえで、ここから言えるのは逆のほうです —— SILVE で変更を確認できたことは、各社がすでにその変更を取得したことの証拠になりません。

これは効果検証の記事で書いている「施策後に起きた ≠ 施策によって起きた」の、取得側での現れ方です。ただし、規格が定めているのは取得側への推奨であって、各社が実際に何時間で読み直すかを示すものではありません。

SILVE はどう扱うか

観測は変えない

「AI 検索クローラーの許可状況」の数え方は変えていません。読んでいるのは、診断の時点で公開されていた robots.txt です。生成元の話は、その取得と解析のやり方を変えません。

手順に分岐を入れた

診断結果の「直し方」を、1 つの段落から手順の並びに変えました。どこを直すかが分岐する以上、段でしか書けません。

区画が見つかった場合は、こう出ます。

1. 意図していない場合は、robots.txt のどこに書かれているかを見てください。この robots.txt には Cloudflare Bot Preference Sync が生成した区画があり、その中の内容は Cloudflare Bot Preference Sync 側の設定によって決まります。
2. 区画の中にある場合は、Cloudflare Bot Preference Sync の設定（AI ボットの Search / Agent / Training）を変更してください。ファイルだけを編集しても、設定を変えなければ区画は設定どおりのままです。区画の外にある場合は、robots.txt の Disallow を直します。

最後の段には、反映の時間差も入れています。

1. 直したあと、robots.txt はキャッシュされます。測り直しても、配信側の反映が済むまでは以前の内容が返ることがあり、各社のクローラーが同じ変更を取得済みとも限りません。

区画があるときだけ、その提供元の名前で言う

• マーカーが無ければ、何も言いません。「CDN を使っていそうだ」は観測ではありません
• 閉じの無い区画は、区画として扱いません。どこまでが管理下か言えないものを「ここからここまで」と書きません
• 確認できた提供元の名前でしか述べません。 他社が同じ仕組みを持つかは、調べていません

区画があることと、それが原因であることを分ける

区画の中に対象のクローラーが含まれていても、同じクローラーが区画の外でも拒否されていることはあり得ます。「区画に何が含まれていたか」までを書き、「だから拒否されている」とは書きません。

診断項目は増やさない

「robots.txt が生成されているか」を診断項目にはしません。

• 欠けていて機械に何かが伝わらなくなるものではありません
• 何個中何個で数えられる実体でもありません

診断項目の入場条件を満たさないので、観測の付随情報として結果に出し、手順の分岐に使うだけにします。話題になっているから項目を足す、をやりません。

まだ言えないこと

• 私たちが取得した robots.txt と、各社のクローラーが受け取る内容が同じかどうか。同じ URI でも要求によって返る表現は変わり得ます。確認していません
• 他の CDN・ホスティング・CMS が同種の生成を行っているか。調べていません。だから「robots.txt は生成されていることがある」を一般的な前提としては書きません
• この仕組みが、いつ全顧客へ行き渡るか。告知記事は段階的な提供予定としており、2026 年 8 月 26 日時点で全面提供の完了を確認できていません。外からの観測でも見つかっていません
• 各社のクローラーが、変更後どれだけの時間で読み直すか。規格と Google の仕様が保持期間を述べているだけで、他社の実際の挙動は確認していません
• 2026 年 9 月 15 日に予定されている、Cloudflare の AI ボット方針の既定値変更が実際どうなるか。これは 7 月 1 日の別の告知にある予定で、Bot Preference Sync の既定値の話ではありません。まだ来ていません

混同しないもの

1. 公開されているファイル ≠ 持ち主が書いたファイル
2. 観測が正しい ≠ 手順が正しい
3. 区画がある ≠ その区画が拒否の原因である
4. 告知された ≠ 提供されている
5. 提供された ≠ 使われている
6. SILVE が取得した内容 ≠ 各社のクローラーが取得した内容
7. SILVE で変更を確認した ≠ 各社への反映が完了した
8. robots.txt で拒否を表明した ≠ ネットワークで遮断した
9. 1 社が始めた ≠ 業界がそうなる

再検証

14 日。告知記事では段階的な提供予定が示されており、2026 年 8 月 26 日時点で全面提供の完了を確認できていません。提供状況・既定値・対象ボットの一覧は、いずれも変わり得ます。 2026 年 9 月 15 日に予定されている Cloudflare の AI ボット方針の既定値変更は、到来後に別途確認します。

一次資料

• Cloudflare — Say it once: introducing Bot Preference Sync（2026-08-21） https://blog.cloudflare.com/bot-preference-sync/
• Cloudflare — Your site, your rules: new AI traffic options for all customers（2026-07-01） https://blog.cloudflare.com/content-independence-day-ai-options/
• IETF — RFC 9309: Robots Exclusion Protocol https://www.rfc-editor.org/rfc/rfc9309.html
• IETF — RFC 9110: HTTP Semantics（同じ URI が複数の表現を持ち得ること） https://www.rfc-editor.org/rfc/rfc9110.html
• Cloudflare — Changelog（2026-08-26 に確認。該当項目は見当たらず） https://developers.cloudflare.com/changelog/
• Google Search Central — How Google interprets the robots.txt specification https://developers.google.com/search/docs/crawling-indexing/robots/robots_txt
• Google Search Central — Robots.txt Introduction and Guide https://developers.google.com/search/docs/crawling-indexing/robots/intro

次に読む

• AI クローラーを「用途」で分ける —— そもそも何を数えているのか
• サイトを直すだけでは足りない条件がある —— サイトの外にある条件
• GEO 施策は本当に効いたのか —— 直したあとに何を確かめるか