GPTBotを名乗るアクセスは本物？Web Bot Authの仕組み

GPTBot と名乗るアクセスが来ても、名前だけでは本物か分かりません。 接続元の情報や、通信に付いた電子的な署名を確認する方法があります。 Web Bot Auth は、署名を使って bot の運営者を確認するための取り決めです。2026 年 9 月時点では、まだ草案の段階です [2][7]。

アクセス記録で「GPTBot が先週の 3 倍」と分かったとき、本当に OpenAI から来たのかを聞かれるかもしれません。Mozilla/5.0 ... GPTBot/1.4 という名前は、誰でも送れます。訪問の種類を分類することと、その会社から来たと確かめることは別です。

確認方法は、名乗った名前、接続元の番号、署名の 3 つに分けられます。どれか一つを見れば、相手のすべてが分かるわけではありません。2026 年 9 月 7 日時点の仕様や各社の案内を基に、何を確認できるかを整理します。設定を自分で操作しない担当者も、制作会社へ何を頼むかを決められます。

1. 名前・アクセス元・署名で確認する

名前は自己申告、IP は接続元、署名は鍵との対応を確認する情報です。 UA は訪問時に名乗る名前、IP アドレスは接続元を表す番号です。署名は、特定の鍵を使って通信内容に付ける、検証可能な情報を指します。

層	何を見るか	何が証明できるか	どこで崩れるか
1. UA (User-Agent)	リクエストヘッダの文字列 (GPTBot/1.4 など)	「そう名乗っている」ことだけ	誰でも同じ文字列を送れる
2. IP レンジ	各社が公開する JSON の IP 範囲、または逆引き DNS	「その会社のネットワークから来た」こと	クラウドの共有 IP、IP の付け替え、公開リストの更新遅れ
3. 暗号署名	HTTP メッセージに付いた署名と、公開鍵ディレクトリ	その鍵に対応する署名が正しいこと。公開元と期限なども検証する	送る側が署名しなければ何も始まらない。仕様が未完成

名前だけで、本物だと判定することはできません。公開された IP の一覧との照合は役立ちますが、一覧の更新日や接続経路も確認します。Web Bot Auth の草案も、IP の情報だけでは運営者を判断しにくい場合があると説明しています [7]。

説明の要約: IP の範囲だけでは、運営者を判断しにくい場合があります。[7]

IP は「どこから来たか」を調べる材料です。番号が一致したという事実を、利用者が誰か、どんな操作を許可したかまで分かったという意味に広げないでください。照合した一覧と確認日時を残すと、後から結果を見直せます。

クラウドでは、複数のサービスが同じ事業者の設備を使ったり、割り当てられる IP が変わったりします。以前その番号を使っていた相手と、今の相手が同じとは限りません。大きなクラウド事業者の範囲に入るだけで、特定の AI 企業だと決めることも避けます。

署名では、送信側が秘密に保管する鍵で通信に印を付け、受信側が公開された検証用の鍵で確かめます。Web Bot Auth は、この方法を bot の確認に使うための取り決めです。Cloudflare は、人と似た操作をする bot も、通信の署名から運営者を確認できるようにする目的を説明しています [10]。

説明の要約: 人と似た方法でアクセスする bot も、署名で運営者を確認できるようにする提案です。[10]

ただし、署名が正しいことと、その相手の行動が望ましいことは別です。確認できた相手にも、サイトの利用条件や操作権限を適用します。「署名あり」だけで、すべてのページへのアクセスを許可する仕組みではありません。

2. 署名の基本を定めるRFC 9421

RFC 9421 は、通信の選んだ部分に署名を付け、検証するための基本の仕組みです。 2024 年 2 月に Proposed Standard として発行された「HTTP Message Signatures」が正式名です [1]。Web Bot Auth は、この既存の仕組みを bot 向けに使います。

HTTP は、ブラウザやプログラムがページの情報をやり取りする仕組みです。RFC 9421 は、その通信の一部について、署名や認証コードを作り、受け取った側が検証する方法を定めています [1]。

説明の要約: 通信の選んだ部分に、署名や認証コードを作り、検証する方法を定めます。[1]

普段のサイト運営で、署名を自分で計算する必要はありません。開発担当者には、対応する仕組みや部品を使い、仕様どおりに検証しているかを確認します。名前が似た独自のヘッダを付けただけでは、RFC 9421 の検証を実施したことにはなりません。

ヘッダは、通信に添える情報です。途中の配信サービスが一部を書き換える場合があるため、署名で確認する対象を選べるようになっています。すべての通信内容が自動で保護されるわけではありません。どの項目を署名の対象にしたかを確認する必要があります。

項目	RFC 9421 の定め
定義するヘッダ	Signature-Input (何に署名したか) / Signature (署名値) / Accept-Signature (署名を要求する)
署名パラメータ	created / expires / keyid / nonce / tag
署名対象に使える派生要素	@authority / @target-uri など (ホスト名や URL そのもの)
登録済みアルゴリズム	RSA-PSS / RSA v1.5 / HMAC-SHA256 / ECDSA P-256・P-384 / Ed25519 / JWS 系
リプレイ対策	本体に強制機構は無い。created expires nonce で緩和する構造 (§7.2.2)

署名された通信を、そのままもう一度送る攻撃への対策も必要です。これをリプレイ攻撃と呼びます。RFC 9421 だけで、あらゆる再送を自動で止められるわけではありません。Web Bot Auth は期限を表す expires などを定め、短い期間での利用を勧めています。 署名の計算が正しいかに加えて、期限や再利用の確認が必要です。

3. Web Bot Authの検討状況

作業部会は 2025 年 10 月 23 日に発足し、最初の作業部会の草案は 2026 年 9 月 1 日に公開されました。 予定表の期限 2 本は未達で、方式や運用について議論が続いています。草案が出た日と、正式な標準が完成した日を分けて読みます。

日付	出来事	出典
2025-03	IETF 122 (バンコク) でサイドミーティング	[2]
2025-07-21	IETF 123 (マドリード) で BoF (作業部会を作るかの検討会)	[2]
2025-09-26	Mark Nottingham が 2 回目の BoF 申請を提出、承認。「この領域の解決策に強く切迫した関心がある」	[2]
2025-10-23	作業部会「Web Bot Auth (webbotauth)」正式発足 。charter 承認。議長 David Schinazi / Rifaat Shekh-Yusef	[2][3]
2025-11-04	IETF 124。charter の方向性に強い反発 (5 章)	[4]
2026-04-13	中間会合。ユースケースごとの投票 (5 章)	[5]
2026-04-30	charter の期限 1: 認証技術と bot 情報伝達の Standards Track 文書を IESG に提出。未達	[2]
2026-07-22	IETF 126 (ウィーン、参加 75 名)。「HTTP Message Signatures を出発点とするか」の投票 Yes 22 / No 6 / 意見なし 5	[6]
2026-08-18	議長が Meunier 案の採択呼びかけをメーリングリストに投稿。35 通以上の返信	[8]
2026-08-31	charter の期限 2: 運用 BCP 文書を IESG に提出。未達	[2]
2026-09-01	最初の作業部会文書 draft-ietf-webbotauth-httpsig-protocol-00 投稿 (44 ページ、Standards Track、著者 Thibault Meunier (Cloudflare) / Sandor Major (Google))	[7]

2026 年 8 月 31 日は、運用に関する文書の提出目標日でした。標準の完成日ではありません。作業部会が 1 年近く活動し、9 月 1 日に草案が公開された時点では、この作業部会から発行された RFC はまだ 1 本もありません。すでに発行されている土台の RFC 9421 と混同しないでください。

活動の目的と範囲を定める文書を charter と呼びます。Web Bot Auth の charter は、運営者の確認と、追加情報の伝達を目的にしています [2]。

説明の要約: 自動でアクセスするプログラムを暗号技術で確認し、運営者の情報をサイトへ伝えることが目的です。[2]

サイト側が「誰のプログラムからアクセスされたか」を判断する材料を得るためです。人の身分証を確認したり、その人が商品購入に同意したことを証明したりする仕組みではありません。本人確認という言葉を使う場合も、誰を確かめる話かを添えると誤解を減らせます。

対象には、検索用の巡回、Web ページの保存、リンク切れの確認、AI 学習用の取得、人の代わりに操作する AI が含まれます [2]。一方、利用者のログインや、サービスへの API 認証は対象外です。API はプログラム同士が機能を使うための窓口です。 bot の運営者が分かっても、その窓口を使う権限は別に確認します。

4. 署名と鍵をやり取りする方法

9 月 1 日の草案は、検証用の鍵をどこに公開し、通信に何を添えるかを定めています。 RFC 9421 の署名を、bot の確認に使うための具体的なルールです [7]。開発担当者は、参照する草案の版も合わせて確認します。

説明の要約: 公開元を示す情報、鍵の一覧の形式、共通の公開先を定めます。[7]

鍵の公開場所を示す情報が Signature-Agent、鍵の一覧の形式が JWKS、共通の公開先が well-known URI です。専門用語はそれぞれ、「公開元を示す情報」「鍵の一覧」「決められた置き場所」と考えれば流れを追えます。

詳しい設定名は次の表に残します。サイト運営者は、これらをすべて手入力するのではなく、利用する配信サービスや検証用の部品が、どの版に対応しているかを確認します。

項目	作業部会文書 -00 の定め
Signature-Agent ヘッダ	Dictionary 型の Structured Header。値は鍵を公開している HTTPS の URL
鍵ディレクトリの場所	/.well-known/http-message-signatures-directory
メディアタイプ	application/http-message-signatures-directory+json
必須パラメータ	created と expires の両方が必須。keyid は JWK の SHA-256 Thumbprint (base64url)。tag は web-bot-auth
有効期限	「24 時間以内が推奨」
署名対象	@authority または @target-uri の少なくとも一方 + signature-agent フィールド
アルゴリズム	IANA 登録済みのものに限定。Ed25519 は例示 (限定ではない)

受信側は、示された公開元から鍵を取得し、通信の署名を検証します。ただし、相手が自分で作った鍵の公開場所を示しただけでは、有名な AI 企業だとは分かりません。公開元の URL が意図した事業者のものか、取得した鍵が正しいか、署名と期限が適切かを確認します。

「鍵がある」「署名の文字がある」「検証に成功した」は、それぞれ別の状態です。

草案が勧める有効期限は、次のとおりです [7]。

説明の要約: 有効期限は 24 時間以内が推奨されています。[7]

24 時間以内という上限の目安があっても、その間なら同じ通信を何度受け入れてもよいという意味ではありません。操作の種類に応じて、再送や二重処理を防ぐ設計を確認します。署名の期限と、注文などの重複防止は、同じ設定だけで完結するとは限りません。

Cloudflare の案内は、1 分で十分な場合もあると説明しています [11]。短くすればよいという単純な話でもなく、通信や時計のずれを考慮した検証が必要です。利用する実装の案内に従い、期限切れと署名の不正を区別して記録します。

2026 年 3 月までの draft-meunier-web-bot-auth-architecture と draft-meunier-http-message-signatures-directory という 2 本の草案は、統合後の文書へ移っています [7]。

2026 年前半の解説を読む場合は、古い文書名だけで最新と判断しないでください。仕様の番号と更新日が分かる資料を、開発担当者と共有します。

5. 本人確認と操作の許可は別

運営者が分かることと、良い行動をすることは同じではない、という議論があります。 IETF 124 や、その後の会合では、何を解決する仕組みにするかが話し合われています [4][6]。署名の技術だけで、アクセスの許可方針まで決まるわけではありません。

2025 年 11 月 4 日の IETF 124 では、Eric Rescorla、Martin Thomson、Brian Campbell が、先に問題を明確にする必要を述べました。Alissa Cooper も、身元を行動の良し悪しの代わりに使うことへ疑問を示しています [4]。

説明の要約: 身元が分かることは、良い行動をすることの代わりにはならない、という指摘です。[4]

たとえば、大手の運営する bot だと確認できても、過剰にアクセスしてサイトへ負荷をかけるなら、対処が必要です。反対に、小さな研究用のプログラムが署名に未対応でも、それだけで悪意があるとは言えません。名前の確認と、実際の行動を見る作業を分けます。

署名に対応できる事業者だけが優遇され、小規模な bot が利用しにくくなるという懸念も議事録にあります。共同議長 David Schinazi は、作業部会を作る前に、もう一度検討会を行うべきだったという趣旨を述べています [4]。この議論を、特定の会社同士の対立だけに単純化しないことが大切です。

2026 年 4 月 13 日の中間会合では、用途ごとに賛否を確認しています [5]。用途によって票の傾向が違うことが分かります。

ユースケース	Yes	No
特定の bot 単位でアクセスを制御したい	17	5
IP アドレスが移動しても bot を追いたい	14	0
IP を共有していても bot を見分けたい	11	0
robots.txt との整合を取りたい	3	9

IP が変わる場合や共有される場合の確認には賛成が集まり、robots.txt との関係では反対が多くなっています。ただし、会合の投票を、そのまま最終的な標準への承認と扱うことはできません。票数と質問の内容を一緒に読む必要があります。

別案として、Rescorla と Richard Barnes の匿名 bot 認証案もあります。draft-rescorla-anonymous-webbotauth-01 は 2026 年 7 月 19 日の文書です [9]。どの bot かを明かさず、許可された相手であることを示す考え方です。 運営者の名前を分かるようにする方法とは、目的の置き方が違います。

2026 年 7 月 22 日の IETF 126 では、HTTP Message Signatures を出発点にすることに Yes 22、No 6、意見なし 5 でした [6]。賛否を示した票のうち、反対はおよそ 2 割です。運用の推奨事項を採択するには、活動範囲の小さな変更も必要と記録されています。

反対があることだけで作業の失敗と結論付けず、何が議論されているかを確認します。

サイト運営者への意味は、署名を使うだけでアクセス方針が完成するわけではない、という点です。どの相手に何を許可するか、未対応の相手をどう扱うか、問題のある行動をどう止めるかは、運用側の判断として残ります。

6. 対応が確認できたサービス

今回の調査で、公式に実装を確認できたのは Cloudflare と Vercel です。 Akamai と Fastly は確認できた資料がなく、Google は仕様への関与と自社の利用を分けて見る必要があります。未確認は、未対応と断定する意味ではありません。

事業者	確認できたこと	確認できなかったこと
Cloudflare	Web Bot Auth を Verified bots の検証方法の 1 つとして提供 (ドキュメント更新 2026-07-01)。 Ed25519 のみ対応 。2026-07-01 に Signed Agents を Verified bots に統合。Enterprise 向けの bot ディレクトリ BotBase (2026-08-28 に運営者向け機能)	—
Vercel	2025-08-12 に bot 検証で Web Bot Auth 対応を発表。ドキュメント (2026-08-11 更新) で IP / 逆引き DNS / 暗号検証の 3 方式。WAF ルールで Signature-Agent ヘッダを条件に使える	—
Google	作業部会文書の共著者 (Sandor Major) が Google 所属。IP 公開フォーマット (jafar) とクローラのベストプラクティス案が提出されている	Google 自身のクローラや Google-Agent が署名しているという公式発表
Akamai	—	ドキュメントがログイン必須で本文を確認できず。公式ブログにも該当記事が見つからず
Fastly	—	公式資料が見つからず

CDN は、サイトの内容を配信するサービスです。同じ種類のサービスでも、署名の対応方式や利用条件は異なります。Cloudflare と Vercel で確認できたことを、ほかの配信サービスへそのまま当てはめないでください。契約しているサービスの担当者に、検証方法と記録の見方を確認します。

Cloudflare は、運営者と目的の説明を確認した bot を Verified bots として扱います [12]。

説明の要約: 運営者と目的の説明を Cloudflare が確認した bot やエージェントです。[12]

「検証済み」という表示は、何を確認した結果かを読みます。署名、IP、ドメイン名など、確認方法が違う場合があります。実行した操作がすべて安全であるとか、利用者本人が操作を承認したという意味には広げないでください。

Cloudflare の確認方法は 3 つで、Web Bot Auth、安定した UA と公開 IP 一覧、逆引き DNS です [12]。逆引き DNS は、IP から対応するドメイン名を調べる方法です。運営形態も、単一の運営者の Direct と、複数の利用者が使うサービスの Intermediary に分かれます。

Search、Agent、Training、Transact などの分類は、検索、代理操作、学習、取引といった目的を示します。

2025 年 8 月 28 日の Signed Agents の案内では、ChatGPT agent、Goose、Browserbase、Anchor Browser が初期パートナーとして挙がっています [13]。bot の会社名だけでなく、人の依頼で動くサービスとして扱う点が特徴です。

説明の要約: 利用者の指示で動くエージェントを対象にしています。[13]

ただし、サービスの運営者を確認できても、その先の利用者が誰か、何を許可したかは別です。予約や購入を扱うサイトでは、通常のログインや取引の確認を続けます。署名があることを、利用者の包括的な同意として扱わないようにします。

2026 年 8 月 28 日の BotBase for Operators は、登録時の検証を自動化する機能を説明しています [14]。

説明の要約: IP やドメイン名、署名の確認を自動化します。[14]

IP の一覧取得、ドメイン名の照合、署名の検証を自動で行うという内容です。人が手作業で照合する負担を減らせますが、サイトごとの許可方針まで自動で決まるわけではありません。結果を使って、受け入れる操作やアクセス量を判断します。

Vercel は、接続元のネットワークに依存しない確認方法として、署名の利点を説明しています [15]。

説明の要約: 接続元のネットワークだけに頼らず、署名から確認できると説明しています。[15]

IP が変わっても、適切な鍵との対応を検証できることが利点です。一方で、鍵の公開元や期限を正しく確認する必要があります。ヘッダに Signature-Agent があることを条件にしたルールと、実際に署名の検証を通った結果に基づくルールは、同じではありません [16]。

7. 各社が公開する名前・IP・署名の情報

各社は名乗る名前や接続元の情報を公開していますが、署名を付ける製品の範囲は十分に分かっていません。 OpenAI、Anthropic、Google、Perplexity、Apple、Meta の 6 社について、2026 年 9 月時点で確認した情報を並べます [17][19][20][21][22][23][24]。 鍵の公開と、個々の通信への署名は区別します。

事業者	公開している UA (主なもの)	IP レンジの公開	署名 (Web Bot Auth)
OpenAI	GPTBot / ChatGPT-User / OAI-SearchBot / OAI-AdsBot	openai.com の gptbot.json (21 prefix) / chatgpt-user.json (2026-09-04 更新、184 prefix) / searchbot.json (35 prefix) / adsbot.json	chatgpt.com の well-known に Ed25519 鍵 1 本を公開 (signature_agent: https://chatgpt.com、purpose: ai)。ただし OpenAI の bots ページに署名の記述は無い
Anthropic	ClaudeBot (学習) / Claude-User (ユーザー起点) / Claude-SearchBot (検索品質)	claude.com/crawling/bots.json (2026-08-18 更新、IPv4 26 prefix)	記述なし。well-known は 404
Google	Google-Agent (ユーザー指示で動くエージェント) / Google-GeminiNotebook。Google-Extended は robots.txt 用のトークンで独自 UA を持たない	JSON 5 本。user-triggered-agents.json は 2026-03-03 作成、4 prefix	公式発表なし (仕様策定には関与)
Perplexity	PerplexityBot / Perplexity-User	perplexity.ai の perplexitybot.json (8 prefix) / perplexity-user.json (4 prefix)	記述なし。well-known は 404
Apple	Applebot。学習利用の制御は Applebot-Extended (robots.txt 用)	applebot.json (2026-07-31 更新、33 prefix)、または逆引き *.applebot.apple.com	記述なし
Meta	facebookexternalhit / meta-webindexer / meta-externalads / meta-externalagent (学習・索引) / meta-externalfetcher (ユーザー起点)	現行ページに IP 検証の記述なし	記述なし

表を使う際の注意は 3 つです。署名の対象、robots.txt の扱い、一覧の更新日を確認します。数値は調査時点の記録で、固定された設定値ではありません。

1 つ目は、OpenAI の鍵の一覧が公開されていることです [18]。Cloudflare は ChatGPT agent、Vercel は ChatGPT operator の署名利用を説明しています [13][15]。ただし、鍵が公開されているだけでは、すべての OpenAI 製品の通信に署名が付くとは証明できません。

どの製品がどの通信に署名するかは、OpenAI の案内で確認できた範囲が限られます。署名を使える相手が OpenAI だけだとも断定できません。

2 つ目は、人の依頼でページを読む場合の robots.txt の扱いです。OpenAI は ChatGPT-User に、ルールが適用されない場合があると説明しています [17]。

説明の要約: 利用者の依頼による動作のため、robots.txt が適用されない場合があります。[17]

robots.txt は、ページを読むプログラムへ許可や拒否を伝えるファイルです。アクセスを物理的に止める仕組みではありません。利用者の依頼による取得か、自動的な巡回かで、各社の扱いが違う場合があります。

Google-Agent、Perplexity-User、Meta-ExternalFetcher にも、利用者の依頼に基づく取得の説明があります [20][22][24]。一方、Anthropic は Claude-User を含むプログラムに robots.txt の制御を案内しています [19]。

「エージェントは全部止まらない」とまとめないでください。詳しくは AI クローラーの種類と設定 を参照できます。

3 つ目は、公開 IP の一覧が更新されることです。ChatGPT-User の記録では、2026 年 9 月 4 日更新で 184 prefix でした [17]。prefix は、IP の範囲をまとめた単位です。184 台の端末という意味ではありません。

1 年前の一覧で照合していると、現在の本物の接続元が載っていない可能性があります。

8. 日付や仕様名で間違えやすい点

提出予定日、草案の統合、署名する製品の範囲は、特に混同しやすい点です。 次の 3 点を確認すると、古い解説から誤った結論を出すことを減らせます。

1. 2026 年 8 月 31 日は標準の完成予定日ではない。 8 月 31 日は charter に書かれた「運用 BCP 文書を IESG に提出する目標日」で、しかも未達でした [2]。標準化どころか、最初の作業部会文書が出たのは翌日の 9 月 1 日です [7]。
2. architecture と directory の 2 本だけを最新と考えない。 両方とも期限切れで、draft-ietf-webbotauth-httpsig-protocol-00 の 1 本に統合されています [7]。
3. OpenAI のすべての通信に署名があると考えない。 一次ソースで言えるのは、chatgpt.com に鍵ディレクトリが公開されていることと、Cloudflare と Vercel が「ChatGPT agent / operator は署名する」と述べていることまでです [13][15][18]。GPTBot が署名しているという資料はありません。

関連する認可の仕組みも別に考えます。Cloudflare の 2026 年 8 月 5 日の「The Agent Access Model」は、AI がサービスやツールへアクセスする権限の話で、RFC 8693、RFC 9449、MCP を参照しています [25]。

MCP の 8 月 22 日の方針も、DPoP や Workload Identity Federation を挙げています [26]。これらは、許可を安全に渡す方法やシステム間の身元確認に関する名前です。サイトが訪問した bot を確認する Web Bot Auth と、同じ仕様ではありません。

9. botを確かめる手順と記録表

名乗った名前、公式の接続元、署名に関する情報を順に確認します。 3 段階のうち、どこまで確かめたかを記録します。署名の有無を残すだけでは検証にはなりません。すでに配信サービスの検証を使える場合は、その結果の見方も確認します。

9-1. チェックリスト

順	やること	判定できること
1	アクセスログの UA から、7 章の表にある文字列 (GPTBot / ChatGPT-User / ClaudeBot / Claude-User / Google-Agent / PerplexityBot / Perplexity-User / Applebot / meta-externalagent など) を抽出する	「名乗っている bot」の一覧
2	各社の公開 JSON (openai.com/gptbot.json、claude.com/crawling/bots.json、Google の user-triggered-agents.json、perplexity.ai の JSON、Apple の applebot.json) をダウンロードし、送信元 IP が含まれるか照合する	名乗りと出所が一致するか
3	一致しなかったものを「未検証」として別に数える。即ブロックしない (JSON の更新遅れがある)	公式の一覧で確認できなかった件数
4	リクエストに Signature-Agent / Signature-Input / Signature の 3 ヘッダが付いているかをログに残す	署名用の情報が付いた割合。検証の成功とは別
5	月に 1 回の報告でも、照合には最新の JSON を使う。更新頻度は提供元に合わせる	リストの鮮度

IP が一覧にない場合は、直ちに偽装と決めません。9 月 4 日の ChatGPT-User の更新のように、公開情報が変わることもあります [17]。記録した接続元が途中の配信サービスの番号になっていないか、照合したファイルが最新かを担当者に確認します。 未確認という区分を残すことが大切です。

9-2. 記録シート (そのままコピーして使えます)

月	名乗り (UA)	件数	IP 一致	IP 不一致	署名ヘッダあり	備考
2026-09	GPTBot
2026-09	ChatGPT-User
2026-09	Claude-User
2026-09	Google-Agent
2026-09	Perplexity-User

3 か月分を記録すれば、未確認のアクセスがどの程度あるかを追えます。ただし、IP 不一致の件数を、そのまま偽装件数にはできません。Cloudflare の 2026 年 7 月 1 日の報告には、通信の 50% が非人間という値があり [28]、2025 年には利用者の操作による AI の取得が 15 倍以上に増えたという値もあります [27]。

これらは偽装率の数字ではありません。自社の記録も、何を数えた値かを明確にします。

9-3. 署名を自前で検証する場合

Cloudflare は cloudflare/web-bot-auth という署名と検証の部品を公開しており、Rust と npm 向けの更新が 2026 年 9 月 5 日時点でも続いています。草案は -00 の段階で、今後の変更があり得ます。

自社で実装する場合は、利用中の配信サービスで代替できるかを確認し、仕様変更や鍵の更新、検証失敗の扱いまで保守できるかを検討します。

10. AgentSignalの訪問者分類で分かること

AgentSignal の人間・AI エージェント・bot の分類は、訪問の情報に基づく推定です。 署名による本人確認ではありません。 現行の分類には、名乗った名前、既知の bot の情報、一部の IP のルール、ブラウザの環境情報が使われています。

タグが記録した訪問に対して、まず既知の名前のルールなどを照合し、該当しないものには IP や環境情報を使います。Google 系の一部の範囲を確認する処理はありますが、表にある全社の最新 IP 一覧を、すべての訪問で照合しているわけではありません。未知の名前を見直す仕組みもあります。

分類名が OpenAI でも、署名を検証して同社の通信だと証明した結果とは区別してください。

画面では、記録できた訪問を次のように確認できます。記録されない取得や、分類し切れない操作がある可能性も残ります。

• ダッシュボード : 過去 7 日のセッション数と「エージェント比率」。取得できた情報に基づく分類で、Direct の訪問をすべて復元するものではありません
• Web 録画 : 種別の列に 人間 / AI エージェント / bot が出て、紹介元に chatgpt.com などがあれば、その経路の手掛かりになります。紹介元だけで人間か AI かは確定できません。AI エージェントは人間と同じく録画され、bot は録画されず録画クォータも消費しません
• フィルタ : 種別で絞り込めるので、「AI エージェントだけ」「bot だけ」の一覧が 1 クリックで出ます

署名の検証は、現行の分類で利用できる機能として案内しません。Signature-Agent の有無、鍵の取得、署名の検証、期限の確認は、それぞれ実装が必要です。草案が -01、-02 と更新されたことだけで、自動的に対応が完了するわけでもありません。

利用者は、配信サービスの検証結果と AgentSignal の訪問分類を分けて確認します。

「GPTBot が 3 倍」という報告には、名乗った件数なのか、IP を照合した件数なのか、署名まで検証した件数なのかを添えます。3 列を埋めれば何でも分かるわけではありませんが、確認済みと未確認を分けて伝えられます。タグの設置は 計測タグを設置する、画面操作の確認は WebMCP とは に説明があります。

名前の分類と、実際の操作の記録を合わせて読むと、追加で調べる場所を決めやすくなります。

調査を頼むときに添える情報

「怪しい bot が来た」とだけ伝えると、担当者もどのアクセスを調べるか迷います。確認した日時、対象のページ、記録上の名前、アクセス元の IP をまとめます。自社の前段に配信や保護のサービスがある場合は、そのサービスの記録か、サイト本体の記録かも書きます。

同じアクセスでも、記録する場所によって見える IP が変わるためです。

依頼する内容は、「この名前を信じてよいか」より「公式の方法で相手を確認できるか」のほうが明確です。担当者には、参照した公式の IP 一覧と確認日、署名があれば検証の成否を返してもらいます。一覧との不一致や検証失敗があった場合は、理由が分かったものと、調査中のものを分けます。 理由が分からない件数を、偽物の件数として報告しません。

対応の相談では、相手の確認結果と、実際に起きた問題を並べます。本物でも短時間の大量アクセスでサイトが重くなるなら、頻度の制限を考えます。確認できない相手でも、すぐに悪意があるとは限りません。どのページで、どの操作が、どの程度困っているかを示すと、サイト全体を止めるような広い対応を避けやすくなります。

まとめ

名前を名乗ることと、本物だと確認できることは別です。 接続元や署名を調べ、どこまで確認した結果かを報告に添えます。

• bot の本人確認は UA (自己申告) / 公開 IP レンジ (出所) / 暗号署名 (鍵の持ち主) の 3 層。作業部会文書自身が「IP ブロックだけでは混乱した話になりうる」と書いている
• 署名の土台 RFC 9421 は 2024 年 2 月に完成済み。bot 向けの取り決め Web Bot Auth は、IETF 作業部会 (2025-10-23 発足) の最初の文書が 2026-09-01 に出たばかりで、charter の期限 2 本 (4/30・8/31) は未達、RFC は 0 本
• 目的と方式の議論が続いている。IETF 124 で「身元は評判の代理にならない」「高速レーンになる」と反発、IETF 126 の方向性投票は Yes 22 / No 6、匿名認証の対案が並走
• 実装を確認できたのは Cloudflare (Ed25519 のみ) と Vercel。OpenAI は chatgpt.com に鍵ディレクトリを公開しているが、どの製品が署名するかの公式資料は無い。他 5 社は署名の記述なし
• 利用者の依頼による取得でも、robots.txt の扱いは会社ごとに違う。Claude-User を一律の無視対象に含めない
• 今日できるのは「UA → 公開 IP JSON → 署名ヘッダの有無」の 3 段階の照合と、月次の記録。AgentSignal の 3 分類は名前や一部の IP、環境情報による推定。署名検証済みの表示ではない (2026-09-07 時点)