robots.txt

robots.txtとは、サイト直下に置き、クローラーに「取得してよい範囲」を伝えるテキストファイルです。2022年にRFC 9309として標準化されました。AIクローラーを個別に許可・拒否できる主要な手段ですが、強制力はなく「お願い」に過ぎません。準拠するかは各ボット次第で、user-triggered fetcherは従わないことがあります。

robots.txtとは（正確な定義）

robots.txtは、Robots Exclusion Protocol（ロボット排除プロトコル）を実装するファイルです。サイトのルート直下、つまり https://ドメイン/robots.txt という決まった場所に1つ置き、クローラーはページを取得する前にまずここを読んで、自分に適用されるルールを確認します。この取り決めは1994年に非公式に始まり、長く事実上の標準として使われた後、2022年にRFC 9309（Proposed Standard＝標準化過程の提案標準）として正式に文書化されました。RFCはインターネットの技術仕様を定める公開文書群です。

RFC 9309で標準化されたことの意味は、長年ばらついていた解釈が公式に統一された点にあります。ファイルの置き場所、User-agent行とDisallow/Allow行の対応関係、複数のルールが競合したときにどれを優先するか（より具体的・より長い一致を優先する等）といった細部が、文書として明確に定められました。ただし標準化されたのは「書式と解釈の仕方」であって、「必ず従わせる強制力」ではありません。robots.txtはあくまで、クローラーが自発的に読んで尊重することを前提にした協調の仕組みです。この「協調が前提」という性格が、後述する注意点の根っこにあります。

なぜ重要か（AI検索での位置づけ）

AI検索対策では、robots.txtが「AIに読ませる／読ませない」を表明する中心的な手段になります。学習には使われたくないがAI検索の結果には出したい、といった細やかな出し分けを、ボット名ごとのルールで実現できます。GoogleのGoogle-Extended（＝Gemini〈ジェミニ〉の学習にコンテンツを使ってよいかを制御する識別名）のような、学習利用の可否だけを制御する専用トークンも、このrobots.txtで指定します。つまりrobots.txtは、AI各社に対する自社の意思表示の窓口です。

AI検索が広がる中で、robots.txtの位置づけは「クロール範囲の交通整理」から「自社コンテンツをAIにどう使わせるかの意思表示」へと重みを増しました。報道機関や出版社が学習系ボットをrobots.txtで拒否する動きが世界的に見られるのは、この意思表示の役割が強く意識されている表れです。一方で、AI検索の流入を新たな集客経路と捉え、検索系ボットは積極的に許可する事業者も増えています。どちらが正解ということはなく、自社のコンテンツ戦略に沿って、ボット種別ごとに態度を決めて書き分けるための道具が robots.txt だと理解するのが要点です。

robots.txtの歴史も、その性格を理解する助けになります。この仕組みは1994年、当時Webサーバーへの過剰なクローラーアクセスが問題になったことをきっかけに、関係者の合意として非公式に生まれました。強制する仕組みを持たず、あくまで良識ある協調に頼るという設計は、この生い立ちに由来します。以来四半世紀にわたり事実上の標準として機能し、2022年にRFC 9309として正式に文書化されました。「みんなが守る前提の紳士協定」という本質は、標準化された今も変わっていません。AIクローラーの多くがrobots.txtに対応しているのも、この長年の慣習の延長線上にあります。

仕組み／書式

robots.txtは、User-agent行で対象ボットを指定し、それに続くDisallow／Allow行で範囲を示す「グループ」の集まりです。基本の書式は次のとおりです。

• User-agent: 対象のボット名（トークン）。すべてを対象にするなら * を書く
• Disallow: 取得を控えてほしいパス。/ だけなら全体、/private/ ならその配下
• Allow: Disallowの例外として取得を許可するパス（より具体的な指定が優先）
• Sitemap: サイトマップ（ページ一覧ファイル）の場所を任意で示す

実際の記述例を挙げます。用途別に「グループ」を並べて書けます。

ポイントは、OpenAIの学習用（GPTBot）と検索用（OAI-SearchBot）が独立して制御できることです。GPTBotをDisallowにしつつOAI-SearchBotをAllowにすれば、「学習には使わせないがChatGPTの検索結果には出す」という方針を表明できます。Google-Extendedも同様に、通常の検索クロール（Googlebot）とは別に、Gemini学習への利用可否だけを切り分けられます。

書き方の細かな作法もいくつかあります。User-agentの後に続くDisallow/Allowは、その直前のUser-agent行が指す相手にだけ適用されます。ワイルドカードの * は「他に個別指定のないすべてのボット」を意味し、特定ボット向けのグループを別に書けば、そのボットは * のグループではなく自分専用のグループに従います。Disallow行を空（Disallow:）にすると「何も禁止しない＝全許可」を意味するなど、直感に反する記法もあるため、更新後は必ず実際の挙動をサーバーログで確かめるのが安全です。OpenAIの案内では、robots.txtの更新が検索側の挙動に反映されるまで時間がかかることもあるとされ、変更が即座に効くとは限らない点も念頭に置きます。

AI検索対策の観点でrobots.txtを位置づけ直すと、それは「自社コンテンツをAI各社にどう使わせたいかを、機械可読な形で宣言する窓口」です。学習には使わせたくないのか、AI検索には出したいのか、その意思を、ボット種別ごとのルールとして表明します。ただし宣言は宣言であって、実際にどう扱われるかは相手の運用に委ねられます。だからこそrobots.txtは「意思表示の第一歩」として整えつつ、確実性が要る場面ではサーバー側の実効的な手段と組み合わせる、という二段構えで臨むのが現実的です。robots.txtを万能視も軽視もせず、その性格に見合った使い方をすることが、AI時代のサイト運営の基本作法になります。まずは自社の方針をボット種別ごとに言語化し、それを正しい書式でrobots.txtに落とし込み、更新後はサーバーログで挙動の変化を確かめる——この一連の流れを回せるようになることが、AI検索対策の実務における到達点のひとつです。

よくある誤解・注意点

なぜuser-triggered fetcherは従わないことがあるのか、という点は理解しておく価値があります。これらは自律的に大量巡回する「クローラー」ではなく、人間が明示的にそのページを見に行くよう指示した操作を代行する「取得役」だからです。人がブラウザでURLを開く行為をrobots.txtが止めないのと同じ理屈で、ユーザーの意思による単発の取得は、自動巡回とは別扱いにされることがあります。したがって「robots.txtでAI関連を全部止めたから安心」とはならず、人の操作を起点にした取得までは止まらない前提で設計する必要があります。

もう一つ誤解されやすいのが、robots.txtとページ単位の制御（noindexやメタタグ、HTTPヘッダーでの指定）の役割分担です。robots.txtは「取得しに来ないでほしい」という入口の要請で、いったん取得を止めるとページ内のnoindex指定すら読まれなくなるため、かえって「取得はされないがURLだけ検索結果に残る」状態を招くことがあります。検索結果やAIの回答から確実に外したいページは、robots.txtで遮断するのではなく、取得は許しつつページ側でnoindex等を明示する、という逆の設計が正しい場合があります。robots.txtは万能の遮断装置ではない、と割り切ることが肝心です。

• Disallowは「取得しないでほしい」という要請で、公開自体を止めるものではありません。URLを直接知っていれば人はアクセスできる
• robots.txtでDisallowにしても、他サイトからのリンクなどで検索結果にURLだけ載ることはある（掲載を確実に止めるにはnoindex等が別途必要）
• User-agentのトークンは各社指定の名前で書きます。誤ったスペルはルールが効かない原因になる
• ファイルはサイトのルート直下（/robots.txt）に置かないと読まれません。サブディレクトリに置いても無効
• 学習拒否（オプトアウト）は、GPTBotやGoogle-Extended等、学習に関わるトークンを個別にDisallowして表明する

学習拒否（オプトアウト）の実務

「自社コンテンツをAIの学習に使わせたくない」という要望（オプトアウト＝利用からの離脱表明）は、robots.txtでの実務の中心テーマのひとつです。基本は、学習に関わるトークン（GPTBot、Google-Extended等）を個別にDisallowして意思表示します。ここで重要なのは、学習拒否と検索拒否を分けて考えることです。学習系だけをDisallowし、検索系（OAI-SearchBot、PerplexityBot等）はAllowのままにすれば、「学習には使わせないが、AI検索の結果には出て流入は得る」という現実的な落としどころを選べます。全AIボットを一律拒否してしまうと、守りは固くなる一方でAI検索での露出機会を丸ごと失う点に注意が必要です。

ただし、robots.txtによるオプトアウトはあくまで「宣言」であり、その宣言を尊重するかは各社の運用に委ねられている点は繰り返し意識すべきです。良識的な事業者は公開したトークンでの拒否を尊重しますが、robots.txtに従わないボットや、そもそも名乗らないボットまで止められるわけではありません。学習利用を確実に避けたい強い要望がある場合は、robots.txtでの宣言に加えて、契約や利用規約での明示、必要に応じたアクセス制限といった多層の対応を組み合わせることになります。robots.txtは第一歩として有効ですが、それだけで完結する魔法ではない、と理解して運用します。

書式の細部と落とし穴

robots.txtは一見単純ですが、細部に落とし穴があります。まず、User-agent行とその配下のDisallow/Allow行は「グループ」を成し、あるボットに複数のグループが該当する場合、そのボット向けの最も具体的なグループだけが適用されます。* のグループと個別ボットのグループが両方あるなら、個別ボットは自分専用のグループに従い、* のグループは無視します。次に、Disallow/Allowが競合したときは、より長く一致するルールが優先されます（例：Disallow: /archive/ と Allow: /archive/public/ が両方あれば、/archive/public/ 配下は許可されます）。この優先ルールを知らないと、意図と逆の結果になりかねません。

さらに実務でつまずきやすい点を挙げます。robots.txtはサイトのルート直下（/robots.txt）にしか置けず、サブディレクトリに置いても無効です。サブドメイン（例：blog.example.com）は別のホスト扱いなので、それぞれに専用のrobots.txtが要ります。ファイルの文字コードやHTTPステータスにも注意が必要で、robots.txt自体が取得できない（サーバーエラーを返す）と、ボットによっては安全側に倒して「全部取得しない」と解釈することも、逆に「制限なし」と解釈することもあります。robots.txtを更新したら、実際にそのURLをブラウザで開いて内容が正しく配信されているかを確認し、その後サーバーログでボットの挙動が変わったかまで見届けるのが、確実な運用です。

実務での扱い方（学習拒否・出し分けの手順）

1. 方針を決める: 学習利用を許すか／AI検索の結果に出したいかを、ボット種別ごとに整理する
2. ルート直下に robots.txt を用意する（既にあれば追記する）
3. 検索系（OAI-SearchBot、PerplexityBot）は Allow、学習系（GPTBot、Google-Extended等）は方針に応じて Disallow を書く
4. 共通で守りたいパス（/admin/ 等）は User-agent: * のグループで Disallow する
5. サーバーログで、拒否したボットが実際に減ったか、許可したボットが取得できているかを観測する
6. 確実に止めたい相手には、robots.txtに加えIP遮断や認証などの実効的な手段を併用する
7. 公式トークン名・方針は変わるため、周期を決めて robots.txt を見直す