何年ものあいだ、自動化クライアントが自分の正体を Web サイトに伝える方法は、User-Agent ヘッダーの名前と、いくつかの大規模運用者については公開された IP アドレス一覧や reverse DNS の確認にほぼ限られていました。名前は簡単に偽装できます。ネットワーク一覧は、それを維持している運用者にしか対応できません。AI エージェントが Web 全体で実際のユーザーのために動き始めるにつれ、このギャップは単なるセキュリティ上の問題ではなく、製品上の問題になりました。
Web Bot Auth は、そのギャップを埋めるための先導的な取り組みです。自動化クライアントが、自分で管理し公開したキーを使ってリクエストに署名し、サイトが名前を信用する代わりに署名を確認できるようにします。この解説は、仕様書を最初から最後まで読まなくても、何であり、何が変わり、何が変わらないのかを理解する必要があるプロダクト マネージャーとエンジニアリング リード向けです。
要点
- 何か: IETF のワーキンググループ webbotauth と、自動化 HTTP クライアントの認証のために標準化している手法です。
- 仕組み: クライアントは各リクエストの一部を HTTP Message Signatures (RFC 9421) で署名し、公開鍵のディレクトリを指し示します。サイトはそのキーを取得して署名を検証します。
- 何を証明するか: どのキーがリクエストに署名したか、そして署名された部分が転送中に変更されていないことです。
- 何を証明しないか: エージェントがその操作を許可されていること、そのエージェントが特定のユーザーのために動作していること、あるいは適切に振る舞うことです。
- 2026年11月時点での状況: RFC 9421 は公開済みの Proposed Standard です。Web Bot Auth のプロトコル文書は working group Internet-Draft であり、まだ RFC ではありません。
- どうするか: 有効な署名は強い証拠として扱い、署名のないトラフィックも引き続き処理し、認可の判断は自分たちのコードに残してください。
IETF の Web Bot Auth の取り組みとは何か
IETF は、Web サイトに対して暗号学的に自動化クライアントを認証し、その背後にいる運用者についてより多くの情報を提供する方法を標準化するために、Web Bot Auth ワーキンググループを設立しました。チャーターは主に人間向けのサイトを対象としており、対象クライアントとして、クローラ、Web アーカイブ、リンクチェッカー、AI 訓練用クローラ、エンドユーザーのために動作する AI エージェントを広く挙げています。
チャーターで特に除外されている点は、製品チームにとって重要です。エンドユーザーの認証は対象外です。つまり、これは人をログインさせるための方法ではありません。ボットのレピュテーション追跡も対象外です。つまり、この標準はリクエストに署名したのが誰かを示しますが、その運用者が信頼できるかどうかまでは示しません。
チャーターには、3種類の成果物が記されています。
- 人間向けに構築された Web サイトに対して自動化クライアントを認証するための手法に関する Standards track 文書。
- ドメイン名や URL など既存の識別子を使って、要求元ボットに関するより多くの情報を伝えるための Standards track 文書。
- 鍵管理、ライフサイクル、デプロイなどの運用面に関する Best current practice または informational 文書。
2026年11月時点での文書の状況
2026年11月時点で、ワーキンググループには採択済みの文書が1つあります。draft-ietf-webbotauth-httpsig-protocol で、タイトルは "HTTP Message Signatures for automated traffic"、revision 01、日付は 2026年10月29日です。これは Internet-Draft であり、まだ変更される可能性がある進行中の作業を意味します。RFC ではありません。
いくつかの個別ドラフトもグループに関連付けられ、議論されています。たとえば、registry と agent card 形式に関する提案、匿名ボット認証、自動化クライアントの IP 範囲を公開するための JSON 形式、署名済みエージェント メタデータ用のヘッダーなどです。個別ドラフトは提案です。この日付時点で、いずれもグループに採択されていません。
チャーターでは、2026年中に仕様を IESG に送って承認を得るためのマイルストーンが設定されていました。2026年11月時点でも、プロトコル文書は working group draft のままです。現在の状況は IETF datatracker のワーキンググループ ページ と プロトコル ドラフト で確認できます。
HTTP Message Signatures の仕組み
Web Bot Auth は、2024年2月に Proposed Standard として公開された RFC 9421, HTTP Message Signatures を基盤にしています。RFC 9421 は一般的な仕組みで、HTTP メッセージの選択した部分に署名する方法と、その署名をヘッダーで運ぶ方法を定義しています。Web Bot Auth は、それを自動化クライアント向けにプロファイル化したものです。
平易に言うと、署名付きのエージェント リクエストは次のように動きます。
- 運用者が鍵ペアを作成する。 秘密鍵は秘匿し、公開鍵を公開します。
- クライアントが署名対象を選ぶ。 宛先の host や URI、生成時刻など、リクエストの一部を選択します。現在のドラフトでは authority か target URI を含めることが求められており、あるサイト向けの署名を別のサイトに再利用することはできません。
- クライアントが署名して送信する。 リクエストには、何がどのキーで署名されたかを示す
Signature-Inputヘッダーと、署名値を含むSignatureヘッダーが付きます。ドラフトはweb-bot-authタグを使い、各署名に生成時刻と有効期限を求めます。 - サイトが検証する。 公開鍵を見つけ、受け取ったリクエストから署名対象部分を再構成し、署名を確認します。検証が通れば、そのリクエストはそのキーの保有者によって署名されており、対象部分は変更されていません。
ドラフトでは、サイト側から署名を要求することもできます。オリジンは通常、拒否とともに Accept-Signature ヘッダーを送ることで、署名付きリクエストを望んでいることを示せます。
キー ディレクトリの考え方
署名は、サイトが適切な公開鍵を見つけられて初めて有用です。Web Bot Auth は、そのために キー ディレクトリ を使います。
現在の working group draft では、クライアントは HTTPS URL を含む Signature-Agent ヘッダーを追加します。その URL は、運用者の公開鍵のディレクトリを JSON Web Key Set として配信します。サイトはそのディレクトリを取得し、署名の key identifier に一致するキーを選び、検証します。ドラフトはまた、運用者がディレクトリを公開できる well-known パス /.well-known/http-message-signatures-directory も定義しています。
製品チームにとって重要なのは、URL が ID になる という点です。エージェントの運用者は、キーを公開している場所で識別されます。これにより、署名は運用者が管理するドメインに結び付けられます。鍵のローテーションは、新しいキーを古いキーと並べて公開し、その後で古いキーを削除することで行います。
検証する側のサイトは、ディレクトリを慎重に扱う必要があります。通常の HTTP ルールに従ってキャッシュし、サイズ制限とタイムアウトを設定し、プライベート ネットワーク アドレスからの取得を避けてください。これらは標準的なエンジニアリング上の注意点であり、多くのチームが検証を自分たちの代わりに行うコンポーネントを好む理由でもあります。
有効な署名が証明すること、証明しないこと
これは、プロダクト ポリシーを書く人にとって最も重要なセクションです。
有効な署名が証明すること:
- リクエストは、特定の秘密鍵の保有者によって署名されたこと。
- そのキーは、運用者が管理するディレクトリ URL に公開されていること。
- リクエストの署名対象部分が転送中に変更されておらず、署名が有効期間内であること。
有効な署名が証明しないこと:
- エージェントがその行為を 認可されている こと。識別できることは権限ではありません。agent authorization を参照してください。
- そのエージェントが特定の人物のために動作していること、またはその人物が与えた権限の範囲内で動作していること。delegated authority を参照してください。
- 運用者が信頼できること、またはエージェントが適切に振る舞うこと。レピュテーションはワーキンググループの明確な対象外です。
- 署名されていないリクエストに関すること。署名のないトラフィックは、別途扱う必要があります。
有効な署名は、誰がリクエストを送ったか の強い証拠として扱い、その後で自分たちのアクセス制御が その送信者に何を許可するか を決めるようにしてください。
製品チームがどう対応すべきか
RFC を待ってから計画を立てる必要はありません。署名付きエージェント トラフィックは今から準備できます。ドラフトの一部は変更される可能性がある、という前提で進めてください。
1. 判断する前に計測する
どの程度のトラフィックが自動化されているか、エージェントがどのルートを使っているか、どの程度が署名済みかを把握してください。まずは observation mode で始め、ユーザーに対する挙動は変えないまま計測します。
2. 証拠とポリシーを分ける
証拠が示す内容, verified, declared, inferred, unknown を、実際に何をするかという判断から分離して記録してください。そうすることでポリシーを読みやすく保ち、再計装せずに厳格化も緩和もできます。evidence basis の項目では4段階を説明しています。
3. verified なエージェントにより良い経路を与える
適切な場合は、verified なエージェントに対して、人間向けページではなく、構造化コンテンツやエージェント向けのフローを提供してください。AI エージェントに構造化コンテンツを提供する のガイドにパターンがあります。
4. 認可は自分たちのコードに残す
署名は、誰が求めているかを知るために使ってください。何を許可するかは、既存の権限、スコープ、確認手順で決めてください。影響の大きい操作では、署名者が誰であっても人間の確認が必要な場合があります。機密操作をエージェントをブロックせずに保護する を参照してください。
5. 署名のないトラフィックと Unknown トラフィックを想定する
署名への対応はエージェントやツールによって異なるため、しばらくは署名済みリクエストと未署名リクエストの混在を想定してください。サイト全体で一律に決めるのではなく、ルートごとに declared、inferred、Unknown のトラフィックをどう扱うかを決めてください。Unknown トラフィックの扱い のガイドで手順を説明しています。
Proof of Actor は Web Bot Auth をどう使うか
Proof of Actor は、各インタラクションで何が動作しているのかを Human, Human + AI, Agent, Unknown のいずれかとしてアプリケーションに伝え、その証拠 basis を示します。Web Bot Auth の署名は、その中でも最も強い証拠ソースの1つです。
エージェントが HTTP Message Signatures でリクエストに署名すると、Proof of Actor はその署名を運用者が公開したキーに照らして検証します。検証が通れば、結果は reviewed 可能な証拠とともに verified basis になります。クライアントがヘッダーで自分を名乗るだけなら、結果は declared です。判断が行動上または文脈上のシグナルに基づく場合は inferred とラベル付けされます。証拠が不十分なら、結果は Unknown です。
その文脈をどう扱うかは、アプリケーション側が決めます。ポリシーはルートごと、actor class ごと、basis ごとに記述し、allow、adapt、challenge、review、rate-limit などの結果を設定できます。既定で強制されるものはありません。実際のトラフィックに対してポリシーを preview し、自分たちのコードでルートごとに enforce します。
Founding チームは、Node.js ミドルウェア、Next.js、エッジ統合、許可済みページ上のブラウザ コレクタ、汎用 HTTP API、または MCP server 統合を通じて証拠を収集できます。integrations と、署名付きエージェント リクエストの検証 のガイドで実践手順を確認してください。
Proof of Actor は、標準が定める限界をそのまま守ります。verified な署名が示すのは、どのキーがリクエストに署名したかであって、そのエージェントが認可されているかどうかではありません。認可はあなたに残ります。証拠と限界 のページでは、各結果が何を支えられ、何を支えられないかを明確にしています。
始める
Proof of Actor は private beta です。選定された founding developer チームは、合意された利用上限の範囲で最長 12か月の無料アクセスを受けられ、自動課金はありません。早期アクセスを申請する から、署名付きエージェントが使うと見込むルートと、それに対して何をしたいかをお知らせください。