robots.txtガイド

AIクローラー向けrobots.txt：検索・学習・アクセス制御の違い

AIクローラーをrobots.txtで制御する方法を解説。OAI-SearchBotとGPTBotの違い、noindexとの使い分け、安全な設定例を紹介します。

Robots.txt Tools Editorial Team による最終確認 2026-10-01約11分で読めます
AIクローラー向けrobots.txt：検索・学習・アクセス制御の違い

AIクローラーの設定で最初に分けるべきなのは、クロールを許可するか、検索や回答で見つけられたいか、提供元固有の学習用途を許可するかという3つの目的です。これらは同じ設定ではありません。AI関連のUser-agentを一括でDisallow: /にすると、意図せず検索での発見性まで失うことがあります。

OpenAIの現在の案内では、OAI-SearchBotとGPTBotは別の目的で扱われます。ChatGPT検索でコンテンツを発見・要約・引用されたいサイトはOAI-SearchBotをブロックしないことが案内されています。一方、学習に使用される可能性のある対象から除外したい場合はGPTBotを拒否できます。

現在のクローラー分類 — 2026年10月1日確認

AI関連のリクエストはすべて同じ目的・同じrobots.txt挙動ではないため、User-agent名を目的別に分けて扱う必要があります。

  • OpenAI: OAI-SearchBotはChatGPT Searchでの検索表示向け自動クローラー、GPTBotはモデル開発・学習向けです。ChatGPT-Userは一部のユーザー起点ページ取得に使われ、OpenAIはそのようなリクエストではrobots.txtが適用されない場合があると説明しています。OAI-AdsBotはChatGPT広告として送信されたランディングページのみを確認し、取得データは生成AI基盤モデルの学習には使われません。
  • Anthropic: ClaudeBotは学習候補データの収集、Claude-SearchBotは検索品質、Claude-Userはユーザー起点の取得に使われます。Anthropicは自社Botがrobots.txtを尊重し、非標準のCrawl-delayにも対応すると説明しています。
  • Google: Google-ExtendedはGeminiの学習とグラウンディングに関する制御トークンで、Google Searchへの掲載やランキングには影響しません。Google-CloudVertexBotは別用途で、サイト所有者がVertex AI Agents構築のために要求するクロールに使われます。
  • Perplexity: 現在のヘルプではPerplexityBotを検索インデックス用クローラーとして説明しています。ブロックされたサイトでは本文の全部または一部をインデックスしない一方、ドメイン、見出し、短い事実要約は保持される場合があります。

ブロックリストへ追加する前に、各トークンを 自動検索、モデル/学習制御、ユーザー/エージェント要求による取得、特定サービス用取得 のどれかに分類してください。

まず目的を決める

目的robots.txtでの考え方追加の制御
通常検索とAI検索の発見性を維持対象の検索クローラーをブロックしない検索結果に出したいページはindexableにする
AI検索は許可し、学習用クローラーだけ拒否検索用と学習用User-agentを分離提供元の最新ドキュメントを確認
公開ページを検索結果から除外robots.txtだけに依存しないクロールを許可してnoindexを読ませる
非公開情報を保護robots.txtをセキュリティとして使わない認証・認可を使う

RFC 9309のrobots.txtはクローラーへの指示であり、アクセス権限の仕組みではありません。DisallowしたURLでも、ルールを守らないソフトウェアからのアクセスを防ぐことはできません。

ChatGPT検索を許可しGPTBotを拒否する例

User-agent: OAI-SearchBot
Allow: /

User-agent: GPTBot
Disallow: /

User-agent: *
Allow: /

Sitemap: https://example.com/sitemap.xml

重要なのはテンプレートをそのままコピーすることではなく、目的ごとにグループを分けることです。クローラー名や方針は変更される可能性があるため、公開前には必ず提供元の最新資料を確認してください。

Disallowとnoindexは役割が違う

robots.txtのDisallowはクロール制御です。noindexは、対応する検索システムにインデックス登録をしないよう伝える指示です。ページをrobots.txtでブロックすると、クローラーがHTMLを取得できず、ページ内のnoindexを読めないことがあります。

たとえば次の組み合わせは注意が必要です。

User-agent: OAI-SearchBot
Disallow: /campaign-preview/

<meta name="robots" content="noindex">

公開ページを検索結果に出したくないだけなら、クローラーがページを取得できる状態でnoindexを返す方が目的に合います。本当に非公開にしたい情報は認証で保護してください。

AIボットの巨大なブロックリストを盲目的に使わない

AI関連User-agentの長い一覧は管理しにくく、すぐ古くなります。検索用、学習用、ユーザー操作による取得用など目的が異なるクローラーを混在させると、何をブロックしているのか説明できなくなります。

小さなルールセットにし、特殊なグループには理由をコメントで残す方が安全です。

# ChatGPT検索での発見を許可
User-agent: OAI-SearchBot
Allow: /

# 学習用途に関する方針
User-agent: GPTBot
Disallow: /

通常のサイト運用ルールと組み合わせる

AIクローラーを許可する場合でも、カート、アカウント、内部検索など低価値なアプリケーションパスを制御できます。

User-agent: OAI-SearchBot
Disallow: /account/
Disallow: /cart/
Allow: /

User-agent: GPTBot
Disallow: /

User-agent: *
Disallow: /account/
Disallow: /cart/
Allow: /

複数のルールが一致する場合は、行の上下ではなく、より具体的なパスが重要です。実際のURLをテスターで確認してください。

公開前チェック

  • /robots.txtが対象ホストのルートから200で取得できるか
  • GooglebotやBingbotの重要ページを誤ってブロックしていないか
  • AIクローラー名が最新の公式ドキュメントと一致しているか
  • 検索発見と学習用クローラーを必要に応じて分離しているか
  • noindexを読ませたいページがクロール可能か
  • 機密情報は認証・認可で保護しているか
  • Sitemapが正しいcanonical URLを含んでいるか
  • 代表URLでAllow/Disallowの判定を確認したか

robots.txtの変更は即時にすべてのクローラーへ反映されるとは限りません。公開後はライブファイル、HTTPステータス、アクセスログ、解析データを確認します。OpenAIはChatGPT検索からの参照URLにutm_source=chatgpt.comが付くと案内しているため、流入の確認にも利用できます。

長期的には、クローラーの目的ごとに方針を決め、必要最小限のルールを書き、公式資料を定期的に再確認するのが最も安全です。

実際のポリシー設計では目的を分けて記録します

AI関連のUser-agentを一つのblocklistとして管理すると、検索での発見、model training、user-requested fetch、広告やservice-specific fetchまで同じ扱いにしてしまいます。私たちは各tokenについて「誰が運用しているか」「自動crawlかユーザー起点か」「robots.txtが適用されると公式に説明されているか」「blockした場合に検索・引用・agent利用へどんな影響があるか」を表にしてからpolicyを決めます。

たとえば OAI-SearchBot と GPTBot は用途が異なり、ChatGPT-User はさらに別です。Anthropicでも ClaudeBot、Claude-SearchBot、Claude-User を分けます。Google-Extendedも通常のGoogle Search crawlerとは目的が異なります。この区別を残しておけば、将来providerの仕様が変わったときに「AI botを全部許可/全部拒否」という粗い判断をやり直さずに済みます。

変更後は公開 /robots.txt を取得し、対象User-agentごとに代表URLをtesterで確認します。さらに公式crawler documentの更新日を定期的に見直し、新しいtokenが追加された場合は、既存presetへ自動追加する前に用途とrobots.txt適用範囲を確認します。AI crawler policyは一度作って終わる静的設定ではなく、provider documentationと一緒に保守する運用項目です。

関連ガイド