セルフホスト型サイトを AI エージェントに備えさせる方法

AI クローラーのトラフィックを扱った Hacker News のスレッドで、あるホスティング管理者が運用側から見た負荷を次のように説明しています。「かなり攻撃的な AI ボットが 6 種類ほど」おり、それらが商品バリエーションページやカテゴリページに周期的にはまり込み、おおよそ毎秒 1 リクエストのペースで叩き始める。しかもそのサイトは「1 ページの読み込みに往復まるまる 1 秒かかることがある（その大半は MySQL で消費される）」というものでした。同じコメントによれば、その累積的な影響は「毎日サイトが Slashdot 効果を受けているのに近い」とのことです。

ウェブサイトを AI エージェントに備えさせるのは、何よりもまずキャパシティの問題です。したがって作業の大半はサーバー設定であり、コンテンツ戦略はごくわずかです。このトラフィックの好都合な点は、大部分が匿名ではないことです。トラフィックを生み出す企業はクローラー名を公開し、それぞれの用途を文書化し、止め方まで案内しています。以下では、何を設定すべきか、各仕組みが実際に何を強制できるのか、そして私なら省く 2 つの手順、すなわち llms.txt の公開と AI 向けの schema マークアップの追加について説明します。

要約

• AI トラフィックは一般に、学習、AI 検索向けのインデックス作成、ユーザー操作を起点とする取得の 3 つに分かれます。OpenAI と Anthropic はこれらの用途ごとに別々のトークンを公開しているため、個別に制御できます。一方、多目的クローラーの中には複数の役割を 1 つの識別子にまとめているものもあります。
• OpenAI、Anthropic、Perplexity、Common Crawl はいずれも、自動クローラー向けの robots.txt 制御を文書化しています。例外はユーザー操作を起点とするフェッチャーです。Anthropic は Claude-User にも robots.txt を適用しますが、OpenAI は ChatGPT-User にはルールが適用されない場合があるとしており、Perplexity-User はおおむね無視します。
• robots.txt ファイルは同意を求める仕組みであって、アクセス制御ではありません。RFC 9309 はこのファイル自体に何の強制力も与えていません。ルールを守るボットが尊重してくれれば負荷は下がりますが、守らないトラフィックを絞ったり止めたりすることはできません。
• Ahrefs のアナリティクス顧客基盤に含まれる 137,210 ドメインを通じて、公開されている llms.txt ファイルの 97% は 2026 年 5 月にリクエストを 1 件も受け取りませんでした。置きたければ置いて構いませんが、その周りにツールを組み上げるのはやめましょう。
• 構造化データは従来の検索機能を支えている箇所ではそのまま維持してください。ただし Google の文書は、同社の AI 機能に特別なスキーマや AI 向けテキストファイルは一切必要ないと述べています。
• OpenAI、ClaudeBot、PerplexityBot、CCBot に読ませたい重要なコンテンツは、サーバー側でレンダリングしてください。Vercel の調査では、これらのクローラーは JavaScript を実行しません。Googlebot 経由の Gemini と AppleBot は例外です。
• 協調的な robots.txt のルールを超えた強制は、リバースプロキシ、自前で運用する WAF、あるいはプルーフ・オブ・ワークによるチャレンジの背後に存在します。コストもこの順に高くなります。

本記事が扱わないこと

ここで扱うのはエージェントに訪問されるサイトであって、エージェントと取引するサイトではありません。隣接する 4 つのテーマには踏み込みません。

• エージェントによるコマースと決済フロー。別種のサイトが抱える別の問題です。
• 学習データをめぐる法的・著作権上の議論。これはサーバー設定ではなく経営判断の問題です。
• WebMCP の実装手順の解説。この標準はまだオリジントライアルの段階だからです。
• 以下の Cloudflare の節を除く、CDN 固有の設定。

どの AI クローラーがあなたのサイトを叩いているのか

GPTBot と ClaudeBot は、モデルの学習に使われる可能性のあるコンテンツを収集します。OAI-SearchBot と Claude-SearchBot は AI 検索と情報取得を支えます。ChatGPT-User と Claude-User は、ユーザーの操作に応じてページを取得します。これらの役割はベンダーによっては分かれていますが、ウェブ上のすべてのクローラーが 1 つの用途にきれいに対応するわけではありません。

遵守状況の実態は、よく使われる大まかな言い方が示唆するよりも精密です。 Anthropic のクローラー文書 には、ClaudeBot、Claude-User、Claude-SearchBot が robots.txt を尊重すると記されています。 OpenAI のボット文書 によれば、同社の自動クローラーは独立した制御手段を用いますが、ChatGPT-User については人が起点となる要求のため robots.txt のルールが適用されない場合があります。 Perplexity のクローラー文書 も同様の区別をしています。PerplexityBot はウェブマスターの設定に従う一方、Perplexity-User はおおむね robots.txt を無視します。したがって「AI ボットは robots.txt を無視する」という大雑把な主張は、ファイルを尊重する文書化されたクローラーと、ベンダーごとに挙動が異なるユーザー起点のフェッチャー、さらには一切名乗らないスクレイパーを、まとめて混同していることになります。

以下の表は執筆時点のものです。新しいトークンは記事が追いつけない速さで登場するため、賞味期限の短い出発点の地図として扱ってください。

AI クローラー向けの robots.txt ルールを書く

RFC 9309 によれば、robots.txt のルールはアクセス認可の一形態ではありません。IETF は 2022 年 9 月に構文・パース・キャッシュを標準化しましたが、このファイルを強制の仕組みに変えたわけではありません。実務で効いてくる要点は構文の下にあります。ファイルは UTF-8 でエンコードされていること、パーサーは少なくとも 500 キビバイトを処理すること、ディレクティブが競合した場合は最も具体的なパス一致が優先されること。ルールがファイルのどこに書かれているかは、まったく関係ありません。

AI ボット向けの robots.txt は、すでにお使いのファイルと構文をそのまま使います。変わるのはトークンの一覧だけです。ルールを意図ごとに整理しておけば、ベンダーの顔ぶれが変わっても長持ちします。反対しているのが学習であれば、学習用トークンをブロックし、インデックス用はそのままにしておきましょう。

# Block training, keep AI search indexing
User-agent: GPTBot
Disallow: /

User-agent: ClaudeBot
Disallow: /

User-agent: CCBot
Disallow: /

User-agent: Google-Extended
Disallow: /

User-agent: OAI-SearchBot
Allow: /

User-agent: Claude-SearchBot
Allow: /

User-agent: PerplexityBot
Allow: /

表に挙げたすべての名前付きトークンにサイト全体のオプトアウト signal を送りたい場合は、1 つのルールにまとめてください。Disallow を 11 回繰り返す必要はありません。

# Send a site-wide opt-out signal to named AI tokens
User-agent: GPTBot
User-agent: OAI-SearchBot
User-agent: ChatGPT-User
User-agent: OAI-AdsBot
User-agent: ClaudeBot
User-agent: Claude-User
User-agent: Claude-SearchBot
User-agent: PerplexityBot
User-agent: Perplexity-User
User-agent: Google-Extended
User-agent: CCBot
Disallow: /

それでもなお、これは万能のブロックではありません。Anthropic は Claude-User にも robots.txt を適用しますが、OpenAI は ChatGPT-User にはルールが適用されない場合があるとしており、Perplexity-User はおおむね無視します。こうしたユーザー起点の取得を、思いとどまらせるのではなく確実に止める必要があるなら、その判断はプロキシか WAF で強制してください。

Google-Extended は最も誤解されやすいトークンであり、検索トラフィックが売上を支えているなら、この区別は重要です。 Google のクローラー文書 では、これをスタンドアロンの製品トークンとして説明しています。クロールしたコンテンツを検索の外での Gemini の学習やグラウンディングに使ってよいかを制御するもので、サイトの Google 検索への掲載や順位には影響しないとされています。これをブロックしても、Googlebot の検索での動作には一切触れません。

トークンの一覧を手作業で最新に保つのは、午後の使い方として賢明ではありません。 コミュニティが維持している ai.robots.txt リポジトリ リポジトリは AI のユーザーエージェントを追跡し、robots.txt、nginx、Caddy、HAProxy、Lighttpd、Apache 向けの設定を生成します。Apache を運用しているなら、生成されたブロックを他の ディレクトリ単位の .htaccess ルールの隣に置けます.

プロのヒント： user-agent 文字列を信用しないでください。あれはヘッダーであり、ヘッダーは無償で偽装できます。 Common Crawl の CCBot 文書 は、CCBot を騙るクローラーがいると警告しています。IPv4 の場合は、次のドメイン配下で順方向確認済みの逆引き DNS によって検証してください。 *.crawl.commoncrawl.orgIPv6 については、逆引き DNS が現在サポートされていないため、Common Crawl が公開している IP レンジを使ってください。上記の各ベンダーのページでも、他の名前付きクローラーの現行 IP レンジが公開されています。これはこれらのベンダーについて文書化された検証手段であって、AI クローラー一般の性質ではありません。

llms.txt に効果はあるのか

現時点の証拠に照らせば、ほぼ何もしません。llms.txt は、サイトのルートに置くことが提案されているプレーンテキストファイルで、言語モデルに対してコンテンツの整理された要約を提示するものです。公開するコストは安いものの、今ある証拠は投資する理由をほとんど与えてくれませんし、Google の文書も、同社の AI 検索機能には不要だと述べています。

フォーマットは最小限です。 llms.txt の提案 は 2024 年 9 月に登場し、置き場所は /llms.txtであり、必須のセクションはサイト名またはプロジェクト名を記した H1 ひとつだけです。

結論は実測データから出てきます。 Ahrefs による 137,210 ドメインの調査 では、計測対象ドメインの 28% が llms.txt ファイルを公開しており、そのうち 97% が 2026 年 5 月にリクエストを 1 件も受け取らなかったことが分かりました。実際に届いたリクエストのうち 19.5% は名前の知れた AI ツールからのものでした。Ahrefs は、取得されたからといって実際に利用された証拠にはならないとも注意を促しています。

このデータについての私の読みはこうです。llms.txt は、それが想定した当のシステムが広くは採用していない慣習に賭けている、ということです。ルートを整然と保ちたいなら公開して構いません。ただし、その周りに生成パイプラインを組まないこと、デプロイのブロッキング工程にしないこと、そしてこれを順位や引用のてこだと売り込む相手は、証拠よりかなり先を走っていると見なすことです。

重要なポイント: Ahrefs の調査では、公開されている llms.txt ファイルの 97% が 2026 年 5 月にリクエストをまったく受け取りませんでした。

ページを機械可読にする

Vercel によるクローラーの計測 では、OpenAI の各クローラー、ClaudeBot、PerplexityBot、Meta-ExternalAgent、Bytespider、CCBot はいずれも JavaScript を実行しないことが分かりました。Googlebot 経由の Gemini と AppleBot は実行します。実行しないクローラーにとって、クライアント側のハイドレーション後にしか現れないコンテンツは存在しないも同然なので、重要なものはすべてサーバー側でレンダリングしてください。マークアップのほうは答えが簡単で、これに関する Google 自身の指針は珍しいほど率直です。

「これらの機能に表示されるために、新しい機械可読ファイルや AI 向けテキストファイル、マークアップを作成する必要はありません。追加すべき特別な schema.org の構造化データもありません。」

Google Search Central の AI 向けガイダンス

FAQ スキーマを支持する根拠として引き合いに出されることのある 40% の可視性向上は、 GEO 論文 KDD 2024 に採択されたものです。論文は最大 40% の向上を報告していますが、そこで検証された介入は、出典の明示、引用、統計、専門用語、流暢な言い回しといったコンテンツ側の変更であり、FAQPage をはじめとする Schema.org のマークアップではありません。数字自体は正しく、それをスキーマ マークアップに結びつけるのが誤りなのです。

構造化データは、従来の検索機能を支え、かつ実際に見えるページと一致している箇所に残してください。Google は、自社の AI 機能の対象となる条件は通常の検索インデックス登録を通るものであり、別途マークアップの要件はないとしています。ただ、それが AI による引用を動かすことは示されていないのです。

robots.txt では足りないとき: サーバー側でのレート制限と WAF

ディレクティブが効くのは、それに従うと決めたボットに対してだけです。 先ほどと同じ Hacker News のスレッドでは、そうしないトラフィックについて複数の運用者が語っています。膨大な IP ブロックのプールにリクエストを分散させ、ユーザーエージェントを次々に変えて普通の訪問者のように見せかけるクローラーです。これは素朴な IP 単位の制限も、ユーザーエージェント照合も同時に無力化します。これはコミュニティの証言として受け取ってください。スレッド内で計測値を公開していた人はいません。とはいえ、robots.txt がそもそも届くようには作られていなかった層を的確に描いています。

そのはしごを登る前に、まだ協調してくれているトラフィックには、もっと安上がりな一手があります。速度を落とすことです。

User-agent: ClaudeBot
Crawl-delay: 1

プロのヒント： ブロックする前にまず絞ること。Anthropic の文書は ClaudeBot について Crawl-delay をサポートしている 。おかげで、負荷は重いが行儀のよいクローラーを、切り捨てずに減速させられます。同じページには、IP ブロックは持続的なオプトアウトの仕組みではないとも書かれています。いずれも Anthropic 固有の話であり、 Crawl-delay は普遍的なディレクティブではないので、まず各ベンダーの文書を確認してください。

そこから先はすべて、自前で運用する強制の話であり、コストと効果が段階的に上がる 3 段のはしごになります。それぞれ何かを買い、何かを手放します。

第 1 段: リバースプロキシのディレクティブとレート制限

AI クローラーのレート制限は、リバースプロキシから始まります。スタックの中で最初にリクエストを目にし、アプリケーションやデータベースが仕事を始める前に速度を落とせる層だからです。 NGINX のレート制限に関する文書 には、キーが空のリクエストはカウントされないと記されています。したがって map を使えば、絞りたいクローラートークンにだけレート制限キーを与え、一致しないリクエストは次の対象外にできます。 limit_req_zone.

# /etc/nginx/nginx.conf, inside the http block
map $http_user_agent $ai_rate_key {
    default              "";
    ~*GPTBot             $binary_remote_addr;
    ~*OAI-SearchBot      $binary_remote_addr;
    ~*ClaudeBot          $binary_remote_addr;
    ~*Claude-SearchBot   $binary_remote_addr;
    ~*PerplexityBot      $binary_remote_addr;
    ~*CCBot              $binary_remote_addr;
}

limit_req_zone $ai_rate_key zone=ai_slowlane:10m rate=20r/m;

# /etc/nginx/sites-available/example.conf, inside the server block
location / {
    limit_req zone=ai_slowlane burst=10 nodelay;
    proxy_pass http://127.0.0.1:8080;
}

調整すべき組み合わせは burst=10 nodelayです。平均レートを超えるリクエストはバースト分を即座に使い切ることができ、それをさらに超えたリクエストには既定で 503 が返ります。締めすぎると、正当なクローラーをクロールの途中で弾き出すことになり、これは障害よりも診断に時間のかかる問題です。Caddy は同じ 2 つの考え方を matcher と handler で表現します。両者で迷っているなら、 設定ファイルを並べて比較したもの のほうが、合成ベンチマークのスループット数値より役に立ちます。

この段の限界は、スローレーンが依然として申告されたユーザーエージェントに依存している点です。Chrome を装ったスクレイパーは、このクローラー専用のキーを丸ごと迂回します。そうしたトラフィックを捕まえるには、IP やパスの挙動に基づくより広いレート制限か、下に出てくる WAF の段が必要です。

第 2 段: 自前で運用する Web アプリケーションファイアウォール

WAF は判断の根拠を、たった 1 つのヘッダーから、リクエストのパターン・パス・頻度をまとめて読むルールセットへと移します。トラフィックが名乗るのをやめた時点で必要になるのは、まさにこれです。自前のマシンで動かせば、ルールもログも自分のディスクに残り、深夜 3 時に grep できます。 BunkerWeb はそうしたプロジェクトのひとつであり、 SafeLine がもうひとつです。ホストがプロジェクトのアーキテクチャと必要リソースの条件を満たしていれば、どちらも VPS 上で動きます。セットアップの手間を省けるよう、両方のワンクリック版を用意していますが、パッケージングは本題ではありません。

それはこの段のコストでもあります。ルールには保守が必要で、しつこいスクレイパーを捕らえられるほど厳しく詰めたルールは、いずれ人間も捕らえます。SafeLine の Monitor、Balanced、Strict の各モード は、そのトレードオフを明示しています。WAF に自動で 403 を返させる前に、まずは誤検知を洗い出せるだけの期間、トラフィックを観察するところから始めましょう。

第 3 段: プルーフ・オブ・ワークによるチャレンジ

Anubis は、識別の問題そのものを回避します。チャレンジをかけると決めたトラフィックについては、オリジンが応答する前に、そのリクエストへわずかな計算コストを支払わせます。 ポリシー機構 は、マッチルールに従ってリクエストを許可・拒否・チャレンジすることもできます。 プロジェクトの README は、これをスクレイパーボットから上流のリソースを守るために、チャレンジを軸に構築された Web AI Firewall Utility と呼んでいます。すべてのボットが正しく名乗ることを前提にせずに機能します。

プロジェクト自身がこの手法を「核兵器的な対応」と表現しており、その留保は妥当です。負担は、ポリシーがチャレンジをかけたトラフィックすべてにかかります。ルールが広すぎれば、低速な端末を使っている人間や正当なクローラーまで巻き込みかねません。この段は、本当に敵対的なトラフィックのために取っておきましょう。熱心すぎるクローラーはたいていレート制限の問題であり、そのレート制限はもう手元にあります。

バーストに備えたサイジング

クローラーの負荷はしばしば波となって押し寄せますが、それが CPU 負荷なのか、データベース負荷なのか、I/O 負荷なのかは、アプリケーションとクロールされている URL によって変わります。前述の WordPress の例では、運用者は 1 ページ 1 秒のうち大半を MySQL までたどりました。つまりあの事例は、トラフィック問題の装いでやってきたデータベースのボトルネックだったわけです。

そうなるとサイジングは配分の問題になり、しかも居心地の悪い問題になります。余裕には常に金を払い続けるのに、その元が取れるのは自分では制御できないスパイクのときだけだからです。それでもスパイクを見込んで確保してください。BunkerWeb をアプリケーションやデータベースと同じホストに同居させるなら、8 GB をスタック全体への推奨値と受け取らないでください。 BunkerWeb のクイックスタートガイド では、テスト用途やサービス数がごく少ない構成には 2 vCPU と 8 GB RAM、多数のサービスを保護する本番環境には少なくとも 4 vCPU と 16 GB RAM を推奨しています。そのうえに、アプリケーション自身の CPU ピーク、データベースのメモリ、I/O の余裕を積み増してください。

リクエスト処理やクエリ実行が CPU 律速のときはクロックの高いコアが効き、同時に進めたい仕事が増えるときはコア数が効きます。サイジングは、クローラーのトラフィックだけでなく、ピーク時の同時実行数、p95 応答時間、データベースの CPU と I/O 待ち、キャッシュミス率から算出してください。

この層を自前で運用するとなると、下のマシンに求めるものは 2 つです。1 つは root 権限。上で挙げた仕組みはどれも、自分で編集する設定ファイルと、自分で再起動するサービスだからです。もう 1 つは、ルールが働いている間にバーストでサイトが落ちない程度の余裕です。そのためにマシンを見積もったり移したりしているなら、当社の Linux VPS Linux VPS なら、このスタックが必要とする root 権限が得られ、長期的なサイズを決める前にプロキシと WAF の構成を試せます。

root権限、NVMe、AMD EPYCのパワーを備えたLinux VPSで開発を。

Linuxプランを見る

Cloudflare の新しい AI トラフィック既定値

Cloudflare は AI トラフィックを Search、Agent、Training の 3 カテゴリーに分類しました。それが示されているのが 2026 年 7 月の AI トラフィックに関する発表。2026 年 9 月 15 日以降、Cloudflare に新規登録するドメインでは、広告を表示するページで Training と Agent が既定でブロックされ、Search は許可されたままになります。既存顧客はそれ以前に設定を変更でき、これらの制御はすべてのプランで利用できます。

ここから借りるべきは、Cloudflare が自らの発表の中で名指ししている厄介さです。同社の分類では、Googlebot、Applebot、Bingbot はいずれも検索の仕事と学習の仕事を兼ねています。そのため Training カテゴリーをブロックした顧客は、それらのクローラーごと、つまり残したかったはずの検索の挙動までブロックしてしまいます。多目的クローラーを「役割はひとつ」と見なすカテゴリー単位の制御には、どれも同じ落とし穴が待っています。

サイトが Cloudflare の背後にないなら、ここに挙げたどれも自分で引けるレバーではありません。それでも来ることは知っておいてください。9 月にはトラフィックの流れ方が変わるからです。あなたの手元に残る制御手段は、robots.txt のトークンと、上で述べたプロキシ層です。

WebMCP: 注視する価値はあるが、作り込む価値はまだない

WebMCP は、エージェントが推測ではなく構造化されたツールを呼び出すための取り決めである Model Context Protocol の、ブラウザー側の対応物です。Chrome の WebMCP オリジントライアルの発表 は目的を率直に述べています。エージェントにボタンや入力欄の役割を推測させるのではなく、サイト側が構造化された関数と注釈付きのコントロールを公開し、エージェントがそれを直接呼び出せるようにする、というものです。

これは、エージェントにあなたのサイトで「読む」以外の仕事を与える初の説得力ある試みであり、だからこそ本記事で最も興味深い話題です。同時に、実験的で未完成でもあります。2026 年 6 月に開始された Chrome 149 のオリジントライアルです。仕様は追いかけましょう。ただし、まだ本番の依存関係を組まないこと、そしてキャパシティ計画には入れないことです。

よくある質問

User-agent: GPTBot
Disallow: /

grep -ohE 'GPTBot|ClaudeBot|CCBot|PerplexityBot|OAI-SearchBot|ChatGPT-User' \
  /var/log/nginx/access.log | sort | uniq -c | sort -rn