Web Bot Auth とは？署名で正体確認
目次
この記事でわかること
- 「Web Bot Auth」が何を指すか、ボットがどうやって正体を証明するか
- RFC 9421（HTTP Message Signatures）との関係と、鍵ディレクトリの公開方法
- robots.txt との違い（お願い vs 証明）と、中小企業サイトでの位置づけ
Web Bot Auth とは
Web Bot Auth は、ボットが送信するリクエストに暗号署名を付けて、自分の正体を証明する仕組みです。これまでボットの身元は User-Agent 名のような「自己申告」に頼っており、第三者が同じ名前を名乗ればなりすませました。Web Bot Auth では、各リクエストをボットが持つ秘密鍵で署名し、受け取ったサーバが対応する公開鍵で検証します。署名が正しければ「確かにそのボット本人だ」と判断できる、という考え方です。
この仕組みは、AI エージェント（自律的に Web を読み、操作するプログラム）が一般化する流れの中で注目されています。サイト側が「どのボットを通すか」を判断するには、まず相手が名乗りどおりの存在かを確かめられる必要があるためです。Web Bot Auth は Cloudflare の Verified Bots プログラムでも利用されています。
RFC 9421（HTTP Message Signatures）との関係
Web Bot Auth は、ゼロから作られた独自規格ではありません。RFC 9421（HTTP Message Signatures）という発行済みの標準仕様を、ボット向けに使うプロファイルとして定義されています。RFC 9421 は「HTTP リクエストやレスポンスの一部に署名を付け、改ざんや差し替えを検出する」ための汎用的な枠組みです。
具体的には、リクエストに 2 つのヘッダが付きます。Signature-Input には署名の対象とメタデータ（鍵を示す keyid、作成時刻 created、失効時刻 expires、アルゴリズム、そして用途を示す tag="web-bot-auth"）が入ります。Signature には実際の暗号バイト列が入ります。サーバはこの情報をもとに、署名が本物か、有効期限内かを検証します。
ここで成熟度を正しく押さえておきましょう。RFC 9421 自体は発行済みの標準ですが、それをボット向けに使う Web Bot Auth プロファイルと鍵ディレクトリの仕様は、まだ IETF のドラフト（策定中）です。アーキテクチャは draft-meunier-web-bot-auth-architecture、鍵ディレクトリは draft-meunier-http-message-signatures-directory として議論が進んでいます。仕様が今後変わる可能性がある段階だと理解しておくのが安全です。
鍵ディレクトリの公開方法
サーバが署名を検証するには、ボットの公開鍵を入手する必要があります。Web Bot Auth では、ボットの運用者が公開鍵を決まった場所に公開します。それが /.well-known/http-message-signatures-directory という鍵ディレクトリです。
このディレクトリは JWKS（JSON Web Key Set） の形式で署名鍵の公開鍵を配信します。配信には条件があり、HTTPS での配信が必須で、Content-Type は application/http-message-signatures-directory+json を使います。サーバ側は、リクエストの keyid に対応する公開鍵をこのディレクトリから取得し、署名を検証する、という流れになります。
robots.txt との違い: お願い vs 証明
「ボットを制御する」という点では robots.txt と似て見えますが、性質はまったく異なります。
robots.txt は「このページは読まないでください」というお願いを書いたテキストで、従うかどうかはボット側の任意です。相手が正体を偽っていても、それを見破る仕組みはありません。一方 Web Bot Auth は、署名によって相手が名乗りどおりのボットだと暗号的に証明します。なりすましは検証で弾けます。robots.txt が「お願い」なのに対し、Web Bot Auth は「正体の証明」という一段進んだ仕組みだと整理できます。用途別の許可・ブロックの考え方はGPTBot / ClaudeBot の許可・ブロック判断も参照してください。
中小企業はどう向き合うべきか
結論として、中小企業のサイトにとって Web Bot Auth は先進領域であり、現時点では任意です。仕様がまだドラフト段階であること、対応するボットや検証側の実装がこれからであることを踏まえると、今すぐ導入を急ぐ必要はありません。
まず優先すべきは、robots.txt や sitemap.xml といった基礎の整備です。これらの位置づけはAI エージェント対応とはで全体像を解説しています。Web Bot Auth はその先にある選択肢として、動向を把握しておけば十分です。
よくある質問
Web Bot Auth は今すぐ設定しないといけませんか
いいえ。Web Bot Auth プロファイルと鍵ディレクトリの仕様はまだ IETF のドラフト段階です。中小企業のサイトでは、まず robots.txt と sitemap.xml の整備を優先し、Web Bot Auth は動向を見ながら任意で検討すれば十分です。
robots.txt があれば Web Bot Auth は不要ですか
役割が違います。robots.txt は「読まないでほしい」というお願いで、相手の正体は確認できません。Web Bot Auth は署名で相手の正体を証明する仕組みです。両者は対立せず、目的に応じて補い合うものと捉えるのが正確です。
公開鍵はどこに置くのですか
/.well-known/http-message-signatures-directory という決まったパスに、JWKS 形式で公開します。HTTPS での配信が必須で、Content-Type は application/http-message-signatures-directory+json を使います。
まとめ
- Web Bot Auth は、ボットが署名で自分の正体を暗号的に証明する仕組み
- RFC 9421（発行済み標準）を使うが、ボット向けプロファイルと鍵ディレクトリは IETF ドラフト
- 公開鍵は
/.well-known/http-message-signatures-directoryに JWKS 形式・HTTPS で配信 - robots.txt が「お願い」なのに対し、Web Bot Auth は「正体の証明」。中小企業には任意の先進領域
まずは自社サイトの基盤を確認しませんか
Web Bot Auth のような先進的な仕組みの前に、まず整えるべきは DNS・robots・SSL といった Web インフラの土台です。自社ドメインの SPF / DKIM / DMARC / SSL / DNS の状態は、ドメイン番人の無料診断で数十秒で確認できます。robots.txt や .well-known などの対応状況は、URL を入れるだけで採点できるAI エージェント対応チェックで確認できます。単発のチェックツールは無料ツール一覧にまとめています。