NotGPTBotAtAll でも 403？さくらのレンタルサーバの「ウェブサイトアクセス制御」を curl で調べてみた

Last updated at 2026-10-07Posted at 2026-10-07

さくらインターネットは1996年12月23日創業とのことなので、2026年は創業30周年だそうです。なお、本記事は、さくらインターネット株式会社とは無関係の一ユーザーによる自主検証です。公式見解ではありません。

TL;DR

2026年2月、さくらのレンタルサーバに「ウェブサイトアクセス制御」という機能が追加されました。設定画面には次の3項目があります。

AIデータスクレイパー
AI検索クローラー
AIアシスタント

最初は「AIからのアクセスを止める機能なんだな」くらいに考えて全部制限していました。
しかし、よく考えてみると AI検索やAIアシスタントまで止めると、AI経由で自分のサイトを見つけてもらう機会まで減らすのでは？ という疑問が出てきます。

さらに公式ヘルプを読んでも、

では技術的には、何を見てAIからのアクセスを判定しているのか、どう止めているのか？

までは分かりません。
そこで curl を使って簡単に調べてみました。
2026年10月7日時点、筆者のさくらのレンタルサーバ環境で確認できた挙動を先にまとめると、次の通りです。

制限対象のUser-Agentを名乗ると 403 Forbidden
許可すると即座に 200 OK
403レスポンスはnginxの標準的な短いエラーページ
OpenAI公式IPでない自宅回線から GPTBot と名乗るだけでも403になる
GPTBot / gptbot / xxxGPTBotxxx / NotGPTBotAtAll は全部403
GPT Bot / GPT-Bot / GPT_Bot は200
他社ボットでもほぼ同じ傾向
3カテゴリごとに別々のUser-Agent分類が存在するように見える
一方、登録されていないAI系User-Agentも少なくない

したがって、観測結果を最も単純に説明するモデルは、

前段nginx付近で、既知AIボットのUser-Agent文字列を大文字小文字を無視した部分一致で照合し、3カテゴリのどれかに分類。契約者の設定が「制限する」ならApacheへ渡す前に403を返す

というものです。
ただし、内部実装は公開されていません。以下は公式資料と外部から観測できる挙動を組み合わせた推測です。

なぜ今、AIボットを分けて考える必要があるのか

従来のWebサイト運営では、ざっくり言えば、

人間
  ↓
検索エンジン
  ↓
Webサイト

を考えておけば済みました。
しかし生成AI時代をむかえ、同じ「AIからのアクセス」だとしてもアクセスの目的が違います。たとえばOpenAIは、現在少なくとも次のようにUser-Agentを分けています。

User-Agent	主な用途
`GPTBot`	生成AIモデル改善・学習に使われる可能性があるクロール
`OAI-SearchBot`	ChatGPTの検索機能にWebサイトを掲載するための検索クロール
`ChatGPT-User`	ユーザープロンプトをもとにその場でページを取得

OpenAI自身も、GPTBot と OAI-SearchBot は独立して制御できると説明しています。

つまり、

モデル学習のためにデータを集める
検索のために索引を作っておく
ユーザーの依頼で今読む

は別の用途です。

Cloudflareも2026年7月からAIアクセスを主に、

Training
Search
Agent

の3つの振る舞いに分けて制御する方向へ進めています。

さくらの

AIデータスクレイパー
AI検索クローラー
AIアシスタント

も、ほぼ同じ問題意識から生まれた分類と考えると分かりやすいです。

自動化トラフィックが人間を超えている

この機能を調べようと思ったもう一つのきっかけが、Cloudflareの2026年のAnnual Founders' Letterでした。その中で、Cloudflareは、自社ネットワークで観測する自動化トラフィック全体が2026年5月に人間からのトラフィックを上回ったとしています。

ここは誤解しやすいのですが「AIだけのトラフィックが人間を超えた」という意味ではありません。検索クローラーなどを含む自動化トラフィック全体の話です。ただ、その逆転をAIエージェントやAIクローラーの急増が前倒しした、という説明です。今後もこの傾向は続き、5年以内に人間の1000倍になるのではと予測しています。昔、「モバイルからのアクセスがPCからのアクセスを超えたよ、へぇ」みたいな話があったと思いますが、桁が違います。1000倍です、1000倍。人間からのアクセスなんて誤差になる時代が来るのです。

Cloudflareはその時代の問題として、「AIエージェントが昼食先を決めるために1,000店舗のメニューを読んでも、実際に顧客を得るのは1店舗だけかもしれない」という例を挙げています。AIにとっては便利でも、残り999店舗はHTTPリクエストを処理するコストだけ負う可能性があるのです。

この問題を考えると、さくらがまず「サーバー負荷の低減」をAIアクセス制御の目的に挙げているのも理解できます。

さくらの「ウェブサイトアクセス制御」とは

さくらインターネットは2026年2月10日、レンタルサーバ／マネージドサーバ向けに「ウェブサイトアクセス制御機能」を提供開始しました。公式発表では、次の3種類です。

設定	公式説明を要約
AIデータスクレイパー	ページから情報を抽出・取得するAIボットを制御
AI検索クローラー	AI検索サービスなどのために巡回するボットを制御
AIアシスタント	対話型AIアシスタントによる閲覧・収集を制御

目的として「サーバー負荷の低減や不正利用防止」が挙げられています。
さらに「AIデータスクレイパー」は、未設定の利用者について2026年3月17日以降、自動的に制限が有効化されています。
なお、Googlebotなど通常の検索エンジンのSEO関連ボットは制御対象外です。

公式資料

普通の企業・店舗サイトなら、どう設定すべき？

技術検証に入る前に、実用上の結論を書いておきます。

商品・サービス・店舗・会社情報などを一般公開している普通のサイトでは、まず次から始めるのが良いでしょう。

項目	推奨
AIデータスクレイパー	制限する
AI検索クローラー	許可する
AIアシスタント	許可する

考え方は単純です。

AIが大量にデータを持ち帰って将来の学習等に使う
       ↓
      制限

AI検索で自社を見つけてもらう
       ↓
      許可

人間がAIに「このサイトを読んで」と頼む
       ↓
      許可

AI検索は、これからの「発見経路」となる

従来なら、

Googlebot
   ↓
Google検索
   ↓
訪問者

でした。

これからは、

OAI-SearchBotなど
   ↓
AI検索
   ↓
ユーザーへの回答・引用

という経路も増えていくでしょう。

検索用途まで全部止めてしまうと、AIから見て自サイトが発見されにくくなる可能性があります。

オプション「AIアシスタント」は人間からのアクセスに近い

たとえばユーザーがAIに、

この会社のWebサイトを読んで、サービスの特徴を整理して

というプロンプトをわたした場合です。

人間
 ↓
AIアシスタント
 ↓
あなたのサイト

なので、これはボットの自動データ大量収集ではなく「実際の訪問者」に近いアクセスです。

ただし、サイトの性質によって正解は違う

もっとも、ニュース、有料記事、写真、創作物など、コンテンツそのものが商品のサイトなら話は変わってきます。

サイト	データスクレイパー	AI検索	AIアシスタント
企業・店舗サイト	制限	許可	許可
ECサイト	制限	許可	許可
一般技術ブログ	制限〜許可	許可	許可
OSSドキュメント	許可寄り	許可	許可
広告収益メディア	制限	許可	ケース次第
有料記事・会員コンテンツ	制限	公開部分のみ	制限寄り

「AIだから全部拒否」ではなく、用途ごとに得られる価値がなにかを考える方が現実的でしょう。

では、さくらは技術的には何をしているのか？

さて、ここからが本題です。

公式ヘルプには「AIボットのアクセス制御（HTTP/HTTPS）」とあります。
robots.txt を書き換える機能ではありません。robots.txt は基本的に、単なるサイト側の意思表示です。相手側が守らなければHTTPリクエスト自体は届きます。

一方、さくらの機能は実際にHTTPステータス 403 Forbidden を返します。では、どこで判定しているのでしょうか。

さくらのWebサーバ構成

さくらの公式仕様によると、レンタルサーバのWebは、

nginx + Apache 2.4系

です。

公式用語集では、さらに明確に、

Internet
   ↓
nginx（前段・入り口）
   ↓
Apache（後段・PHP等）

という構成だと説明されています。

そこで、まず次の仮説を立てました。

AIアクセス制御は、ApacheやWordPressより前のnginx付近でUser-Agentを見ているのではないか？

実験1：GPTBotを名乗ってアクセスしてみる

以下、実験時のドメイン名・ユーザー名・IPアドレスなどは記事用に匿名化しています。

制限時

curl -v \
  -A 'Mozilla/5.0 (compatible; GPTBot/1.0; +https://openai.com/gptbot)' \
  https://www.example.com/

結果の重要部分だけ抜粋すると、

> GET / HTTP/2
> Host: www.example.com
> User-Agent: Mozilla/5.0 (compatible; GPTBot/1.0; +https://openai.com/gptbot)

< HTTP/2 403
< server: nginx
< content-type: text/html
< content-length: 146

<html>
<head><title>403 Forbidden</title></head>
<body>
<center><h1>403 Forbidden</h1></center>
<hr><center>nginx</center>
</body>
</html>

nginxらしい素な403です。

許可時

コントロールパネルで制限を解除し、同じUser-Agentで再度アクセスします。

< HTTP/2 200
< server: nginx
< content-type: text/html; charset=UTF-8
< content-security-policy: ...
< link: <https://www.example.com/wp-json/>; rel="https://api.w.org/"
< ...

今度はWordPress由来と考えられるレスポンスまで返ってきます。
設定変更はほぼ即時に反映されました。

わかったこと

許可時にもフロントのnginxを通るため、server: nginx だけでは、nginx自身が403を作った証拠にはなりません。しかし、

制限時は146バイトの簡素なnginx 403ページ
許可時はWordPress等の後段で付与されたヘッダーが存在
設定変更が即時反映

という差から考えると、

AI bot
   ↓
nginx
   ↓
ここで403
   ×
Apache
   ×
WordPress

という経路が最も自然だと考えられます。内部実装は非公開なので断定はできませんが、Apacheへ渡す前の前段で遮断している可能性はかなり高いでしょう。

実験2：IPアドレスも確認しているのか？

次の疑問は、

User-Agentだけでなく、送信元のOpenAI公式IPも確認しているのか？

です。この判断は簡単です。手元のターミナルから GPTBot を名乗っているので、当然OpenAI公式クローラーのIPアドレスではありません。

それでも403になります。つまり、

GPTBotというUser-Agent文字列だけで拒否条件を満たせます。

なお「IPアドレスを内部で一切見ていない」ことまで証明したわけではありませんが、公式IPによる送信元確認は、403にするための必須条件ではないということです。

ここはCloudflareのVerified Botのような方式とは性格が違うようです。

実験3：どんな感じでUser-Agentを見ている？

次は実際にどの文字列をマッチしているのかが気になりましたので、まずは GPTBot の文字列を変形してアクセスしました。

for ua in \
  'GPTBot' \
  'GPT Bot' \
  'GPT-Bot' \
  'GPT_Bot' \
  'AGPTBotB' \
  'gPtBoT' \
  'GPTBot/999' \
  'NotGPTBotAtAll'
do
  printf '%-20s ' "$ua"
  curl -o /dev/null -s -w '%{http_code}\n' \
    -A "$ua" \
    https://www.example.com/
done

結果はこうです。

GPTBot               403
GPT Bot              200
GPT-Bot              200
GPT_Bot              200
AGPTBotB             403
gPtBoT               403
GPTBot/999           403
NotGPTBotAtAll       403

NotGPTBotAtAll 「断じてGPTBotではない」でも403です(笑)。

一方、GPT Bot のように文字列を分断すると200になります。

シンプルな表現にすると

lower(User-Agent).contains("gptbot")

です。nginx設定風なら、

~*GPTBot

のような大文字小文字を無視した部分一致です。

実験4：他社のAIボットの扱いを調べる

次に、OpenAIだけでなく複数社のAI関連User-Agentの調査です。
2026年10月7日時点で、以下の4条件を切り替えながら測定しました。

3カテゴリすべて制限
AIデータスクレイパーだけ制限
AI検索クローラーだけ制限
AIアシスタントだけ制限

対象にはOpenAI、Anthropic、Perplexity、Amazon、Meta、Google、Apple、ByteDance、Common Crawl、DuckDuckGo、Mistralなどを含めました。比較用として通常ブラウザUA、Googlebot、bingbotも入れています。

再現用の簡易スクリプト

もし、実行する場合、ターゲットURLは必ず自分が管理するサイトに変更してください。

#!/usr/bin/env bash

URL="${URL:-https://www.example.com/}"

BOTS=(
  "Control|Mozilla/5.0"
  "OpenAI|GPTBot"
  "OpenAI|OAI-SearchBot"
  "OpenAI|ChatGPT-User"
  "OpenAI|OAI-AdsBot"
  "Anthropic|ClaudeBot"
  "Anthropic|Claude-SearchBot"
  "Anthropic|Claude-User"
  "Perplexity|PerplexityBot"
  "Perplexity|Perplexity-User"
  "Amazon|Amazonbot"
  "Amazon|Amzn-SearchBot"
  "Amazon|Amzn-User"
  "Meta|meta-externalagent"
  "Meta|meta-webindexer"
  "Meta|meta-externalfetcher"
  "Meta|FacebookBot"
  "Google|Google-CloudVertexBot"
  "Google|Google-Extended"
  "Apple|Applebot"
  "Apple|Applebot-Extended"
  "ByteDance|Bytespider"
  "CommonCrawl|CCBot"
  "DuckDuckGo|DuckAssistBot"
  "Mistral|MistralAI-User"
  "Google|Googlebot"
  "Microsoft|bingbot"
)

printf "%-14s %-24s %s\n" "PROVIDER" "USER-AGENT" "HTTP"

for row in "${BOTS[@]}"; do
  IFS='|' read -r provider ua <<< "$row"

  code=$(
    curl \
      --connect-timeout 5 \
      --max-time 10 \
      -o /dev/null \
      -sS \
      -w '%{http_code}' \
      -A "$ua" \
      "$URL"
  )

  printf "%-14s %-24s %s\n" "$provider" "$ua" "$code"
  sleep 0.2
done

コントロールパネルの設定を1カテゴリずつ手動で切り替えて、結果を保存し比較しました。

実測した分類

2026年10月7日時点、筆者環境では次のようになりました。

事業者	User-Agent	さくら側で観測された分類
OpenAI	`GPTBot`	AIデータスクレイパー
OpenAI	`OAI-SearchBot`	AI検索クローラー
OpenAI	`ChatGPT-User`	AIアシスタント
OpenAI	`OAI-AdsBot`	未分類
Anthropic	`ClaudeBot`	AIデータスクレイパー
Anthropic	`Claude-SearchBot`	AI検索クローラー
Anthropic	`Claude-User`	未分類
Perplexity	`PerplexityBot`	AI検索クローラー
Perplexity	`Perplexity-User`	未分類
Amazon	`Amazonbot`	AI検索クローラー
Amazon	`Amzn-SearchBot`	AI検索クローラー
Amazon	`Amzn-User`	未分類
Meta	`meta-externalagent`	AIデータスクレイパー
Meta	`meta-webindexer`	AI検索クローラー
Meta	`meta-externalfetcher`	未分類
Meta	`FacebookBot`	未分類
Google	`Google-CloudVertexBot`	未分類
Google	`Google-Extended`	未分類
Apple	`Applebot`	AI検索クローラー
Apple	`Applebot-Extended`	AI検索クローラー相当で403
ByteDance	`Bytespider`	AIデータスクレイパー
Common Crawl	`CCBot`	AIデータスクレイパー
DuckDuckGo	`DuckAssistBot`	AIアシスタント
Mistral	`MistralAI-User`	未分類
Google	`Googlebot`	未分類（通常検索として通過）
Microsoft	`bingbot`	未分類（通常検索として通過）

この表でいう「未分類」は、

今回試した3カテゴリのいずれを単独で制限しても200だった

という意味であり、「その会社のアクセスを一切検知できない」というものではありません。

OpenAIは3分類がきれいに分かれた

OpenAIは非常に分かりやすいです。

GPTBot
  ↓
AIデータスクレイパー

OAI-SearchBot
  ↓
AI検索クローラー

ChatGPT-User
  ↓
AIアシスタント

これはOpenAI自身が説明している用途ともよく対応しています。さくらの3つのチェックボックスは単なるUI上の説明ではなく、内部でもUser-Agentごとにカテゴリを持っている可能性が高そうです。

Anthropicもほぼ同じ結果。ただし `Claude-User` は未分類

ClaudeBot
  ↓
AIデータスクレイパー

Claude-SearchBot
  ↓
AI検索クローラー

Claude-User
  ↓
今回のテストでは未分類

ここでのポイントは、

「AIアシスタントを制限」にすれば、世の中のAIアシスタントからのアクセスを全部止められる

わけではないことです。今回の実測でAIアシスタントとして403になったのは、

ChatGPT-User
DuckAssistBot

だけでした。一方、

Claude-User
Perplexity-User
Amzn-User
meta-externalfetcher
MistralAI-User

はすべて200でした。つまり少なくとも現在時点での挙動は、既知User-Agentのリスト方式と考えるのが自然です。

Amazonbotは「AI検索」扱い

Amazonの公式資料では、

Amazonbot：製品・サービス改善、AIモデル学習に使われる可能性
Amzn-SearchBot：検索用途
Amzn-User：ユーザー操作起点

と説明されています。しかし今回のさくら側の挙動では、

Amazonbot
Amzn-SearchBot

の両方が「AI検索クローラー」として403になりました。つまり、さくらが各社公式のカテゴリをそのまま機械的にコピーしているとは限らなさそうです。

`Applebot-Extended` 実験結果の解釈

3カテゴリすべて制限した状態では、

Applebot-Extended → 403

でした。一見すると、

Applebot-Extendedもさくらのリストに登録されている

ようにも見えます。

しかし、User-Agentを少し変形させてみると、

Applebot-Extended → 403
Applebot Extended → 403
Applebot_Extended → 403

でした。ここから Applebot-Extended 全体ではなく、その中の

Applebot

だけにヒットしていると考えれば説明できます。実際、Applebot 単体もAI検索カテゴリで403です。したがって、

Applebot-Extendedが明示的に登録されている証拠にはならない

と考えられます。

変形テストで「大文字小文字無視の部分一致」は再現

403になった主なUser-Agentについては変形版を投げてみました。例として OAI-SearchBot では、

oai-searchbot          403
OAI-SEARCHBOT          403
xxxOAI-SearchBotxxx    403
OAI-SearchBotFake      403
NotOAI-SearchBotAtAll  403
OAI-SearchBot/999      403

OAI SearchBot          200
OAI_SearchBot          200
OAI-Search Bot         200
OAI-Search-Bot         200

同じ傾向は、

GPTBot
ClaudeBot
Claude-SearchBot
PerplexityBot
Amzn-SearchBot
meta-externalagent
meta-webindexer
CCBot
DuckAssistBot

などでも再現しています。したがって少なくともこれらについては、

大文字小文字無視　部分一致

と考えられます。

推定される内部実装

ここまでの結果をもとに、さくらの「AIアクセス制御」について概念図にすると

                    HTTP Request
                         │
                         ▼
                ┌─────────────────┐
                │      nginx      │
                │  HTTP / TLS入口 │
                └────────┬────────┘
                         │
                    User-Agent
                         │
                         ▼
              ┌─────────────────────┐
              │ AI bot UA table     │
              │                     │
              │ GPTBot → scraper    │
              │ OAI-SearchBot       │
              │       → search      │
              │ ChatGPT-User        │
              │       → assistant   │
              │ ClaudeBot→scraper   │
              │ ...                 │
              └──────────┬──────────┘
                         │
                    category
                         │
                         ▼
             ┌────────────────────────┐
             │ 契約者のアクセス設定   │
             │                        │
             │ scraper   allow/deny   │
             │ search    allow/deny   │
             │ assistant allow/deny   │
             └───────────┬────────────┘
                         │
                  ┌──────┴──────┐
                 DENY          ALLOW
                  │              │
             nginx 403         Apache
                                 │
                                 ▼
                           PHP / WordPress

nginxの設定を書けば、挙動だけなら次のようなものです。

# あくまで挙動を説明するための疑似例。さくらの実設定ではありません。

map $http_user_agent $ai_category {
    default "";

    ~*GPTBot              scraper;
    ~*ClaudeBot           scraper;
    ~*meta-externalagent  scraper;
    ~*Bytespider          scraper;
    ~*CCBot               scraper;

    ~*OAI-SearchBot       search;
    ~*Claude-SearchBot    search;
    ~*PerplexityBot       search;
    ~*Amazonbot           search;
    ~*Amzn-SearchBot      search;
    ~*meta-webindexer     search;
    ~*Applebot            search;

    ~*ChatGPT-User        assistant;
    ~*DuckAssistBot       assistant;
}

そして契約者ごとに、

scraper   = deny
search    = allow
assistant = allow

のようなフラグを持っている、と考えるとほぼ全観測結果を説明できます。もちろん、実際には設定DB、生成されたnginx設定、共有メモリ、独自モジュールなど別の実装かもしれません。

さくらは「AI検出」ではなく「既知AI UAの検出」

今回の実験で一番大切なポイントはここです。たとえば、

NotGPTBotAtAll

でも403になります。つまり本当にOpenAIのGPTBotかどうかを確認しているわけではありません。逆に悪意あるスクレイパーが、

Mozilla/5.0

とだけ名乗れば、このUser-Agent判定を回避できる可能性は高いです。したがって、この機能は、

高度なAIボット検知システム

ではありません。むしろ、

正直に既知のUser-Agentを名乗ってアクセスしてくるAI事業者を、共有レンタルサーバ上で低コストに制御する仕組

と考えれば合理的です。大量リクエストをPHPやWordPressまで通してから拒否するより、入り口のnginxで即座に403を返す方が圧倒的に軽いからです。

robots.txtとの違い

robots.txt は基本的に「お願い」です。

User-agent: GPTBot
Disallow: /

と書いても、相手が無視してHTTP GETすればWebサーバに到達します。一方、今回のさくらの機能は、

GPTBotを名乗る
 ↓
サーバ側で判定
 ↓
403

です。つまり、

robots.txt
    = 立入禁止の看板

さくらのアクセス制御
    = 入り口のゲート

という違いがあります。ただし、そのゲートは「名前（UA）を名乗った相手」を見ているだけなので、

Cloudflare の　Verified Bot
Web Bot Auth
IP range検証　や　reverse DNS

のような厳格な確認とは別物です。

Cloudflareとの違い

Cloudflareは現在、AI関連アクセスを Search / Training / Agent といったふるまいで分類し、AI Crawl ControlやWAF、Bot Management等を組み合わせています。また、Verified Botの仕組みも持っており、「どんな名前を名乗ったか」だけでなく、より強い識別を行う方向です。
対して今回観測したさくらの方式はかなりシンプルでした。

	さくら（今回の観測）	Cloudflare
主な目的	共有ホスティングの負荷軽減・アクセス制御	AIアクセス全体の可視化・制御
用途別分類	3分類	Search / Training / Agent等
強制ブロック	403	WAF等で可能
UA判定	実測で確認	利用
Verified Bot相当	今回は確認できず	あり
robots.txtとの統合	公式資料では限定的	Managed robots.txt等あり
分析画面	限定的	AI Crawl Controlで詳細分析

同じ問題を扱っていますが、サービスの性格がかなり違います。
さくらは「レンタルサーバ利用者が難しいことを考えなくても入口で軽く止められる」ことに重点があるように見えます。

※先行記事と比較すると、ルールが更新されている可能性もある

今回の実験の前に非常に参考になったのが、ユーチューブビジネスサポートさんの検証記事です。

2026年9月4日時点で、AIデータスクレイパーだけ制限していた環境では、

Claude-SearchBot → 403

だったと報告されています。ところが筆者が2026年10月7日に測定した環境では、

AIデータスクレイパーのみ制限
Claude-SearchBot → 200

AI検索クローラーのみ制限
Claude-SearchBot → 403

でした。つまり筆者環境では、Claude-SearchBot は明確に「AI検索クローラー」に分類されています。これだけで、

9月から10月の間にさくらがルールを書き換えた

と断定はできません。サーバ環境や測定条件の差も考えられます。ただ、User-Agent分類テーブルが中央側で更新され得る仕組みだと考えれば、あり得る話です。この点は今後も時間を置いて再測定すればわかるかもしれません。

参考：

AIクローラーを拒否する方法｜robots.txtの前に70社を調べた結果

この機能については、さくら自身による

AI時代のWebサイト運営入門～AIクローラー・スクレイピング対策とアクセス制御の考え方～

というセミナーがも2026年8月に予定されていました。ただ、2026年8月18日に「諸般の事情」により延期が発表されています。内容紹介を見る限り、今回知りたかったテーマそのものなので、再開催や資料公開があればぜひ確認したいところです。

AI時代のWebサイト運営入門 - さくらインターネット

では結局、何を設定すればよい？

筆者としては、一般公開の企業・店舗・サービスサイトなら、まず、

AIデータスクレイパー  制限する
AI検索クローラー      制限しない
AIアシスタント        制限しない

を基準にするのがよいと思います。理由は、

負荷だけ生みやすい大量データ収集は抑えつつ、AI時代の「発見される経路」は残す

ためです。一方、記事や写真などコンテンツ自体を商品としているサイトでは、より厳しくする合理性があるかと思います。AIによるゼロクリック問題です。

また、あわせて考えなければならない重要なポイントとして、さくらの「AIアクセス制御」設定だけで完全な制御ができるわけではないということがあげられます。今回の実験でも未分類のAI User-Agentが複数あることが確認できました。またUser-Agentを偽れば容易に回避できます。

したがって、

さくらのアクセス制御
robots.txt
WAFやCDN
必要なら認証
そもそも公開してよい情報かの確認

を用途に応じて組み合わせて考えていくべきでしょう。

まとめ

今回、さくらのレンタルサーバの「ウェブサイトアクセス制御」が何をしているのかを、公式資料と curl を使ってブラックボックス的に調べてみました。

実測から分かったことは、

AI関連User-Agentに対して実際にHTTP 403を返す
403はnginxの標準的なレスポンスに見える
さくら公式の構成も前段nginx＋後段Apache
自宅回線からでもUser-Agentを名乗るだけでブロックされる
少なくとも拒否時に公式IP認証は必須ではない
大文字小文字を無視した部分一致に見える
3カテゴリごとに既知User-Agentの分類テーブルがあるように見える
一方で未登録のAI User-Agentも存在する

というものでした。

この仕組みは「AIであることを高度に見抜く」ものではありません。しかし、共有レンタルサーバという環境で、既知のAIクローラーからの大量アクセスを安価に入口で止める仕組みとしては、かなり合理的だと思います。

そして個人的には、この3つのスイッチが示している考え方の方が興味深いです。これからのWebサイト運営では、

AIを許可する / AIを拒否する

という二択ではなく、

学習に使ってよいか
検索で見つけてもらいたいか
人間の代理として読みに来るAIを許可するか

を別々に考える必要がありそうです。30年前に生まれた人間がアクセスする前提のWebでは、こんな設定は必要ありませんでした。

さくらインターネット創業30周年の年に、レンタルサーバの管理画面にこの3つのチェックボックスが追加されているのは、Webそのものが次の時代に入りつつあることを象徴しているようで、なかなか面白いと思います。

検証上の注意

本記事の結果は、2026年10月7日に筆者が管理する1つのさくらのレンタルサーバ環境で行ったブラックボックス試験です。

以下は保証できません。

全プラン・全サーバで同一実装であること
内部でnginxの map や正規表現を実際に使っていること
IPアドレス等を補助情報として一切利用していないこと
今後もUser-Agent一覧や分類が変わらないこと
403になるUser-Agentが本物のAI事業者のボットであること

特にUser-Agent分類は今後更新される可能性があります。この記事を読んだ時点の挙動を確認したい場合は、自分が管理するサイトで再テストしてください。

大量のリクエストを送る必要はありません。この記事の試験も、1 User-Agentあたり数回程度の低頻度アクセスで行っています。

参考資料

さくらインターネット公式

AI事業者・Cloudflare公式

参考にさせていただいた記事

更新履歴

2026-10-07: 初版。さくらのレンタルサーバ環境での実測結果を反映。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up

NotGPTBotAtAll でも 403？ さくらのレンタルサーバの「ウェブサイトアクセス制御」を curl で調べてみた