User-Agent 許可リストは、Web で最も古いパターンの 1 つです。信頼するクローラーやクライアントの名前を一覧にしておきます。リクエストが届き、その User-Agent ヘッダーが一致すれば、通過させたり、チャレンジを省略したり、軽いページを返したりします。設定には数分しかかからず、チーム全員が理解できます。
このパターンは、主な自動訪問者が検索クローラー数種といくつかの監視ツールだけだった時代には、より理にかなっていました。今では、AI エージェント、アシスタント、自動クライアントが増え続けており、その多くが名前を名乗ります。その名前の中には本物もあれば、複製されたものもあります。ヘッダーだけでは、そのどちらかは分かりません。
Proof of Actor は別の方法を取ります。User-Agent 文字列はあくまで宣言として扱い、その根拠がある場合は、より強い証拠と並べて表示します。このページでは、名前による許可リストの限界、ネットワークレベルの確認が役立つ場面、そして検証済み署名と明示的な Unknown クラスがどう見え方を変えるのかを説明します。
要点
| User agent 許可リスト | Proof of Actor | |
|---|---|---|
| 主な証拠 | User-Agent ヘッダー内の名前 | 署名、宣言、シグナル。いずれも根拠つきで表示 |
| クライアントは偽装できますか? | はい。同じ文字列を送れば可能です | declared basis は主張できます。verified basis には署名鍵が必要です |
| 出力 | リスト内かどうか | Human, Human + AI, Agent, Unknown のいずれかに加え、根拠 |
| 不明確なトラフィック | 許可リスト外として扱うか、既定で許可する | Unknown として扱い、ルートごとに選ぶフォールバックを適用 |
| AI を使う人 | 見えない。通常のブラウザを使うため | 宣言または観測に基づき、Human + AI という別クラスとして扱う |
| 保守 | 名前が変わるたびに手動で更新 | エージェント運用者が公開する鍵。ポリシーはあなたのコード内にある |
| インストール時の既定 | リストが許すものなら何でも | observation。ポリシーを追加するまで何も変わらない |
| 最も得意なこと | よく振る舞う既知クライアントの安価なルーティング | 製品とポリシー判断のための、証拠に基づく actor コンテキスト |
以降では、それぞれの行を説明します。
User-Agent による許可リストが偽装可能な理由
User-Agent ヘッダーはクライアント側で設定されます。ブラウザが設定し、スクリプトが設定し、エージェントフレームワークが設定します。HTTP には、その値が真実かどうかを確認する仕組みはありません。許可リストが文字列を信頼するなら、その文字列をコピーした誰でも同じ扱いを受けます。
これは user agent spoofing と呼ばれ、単純な理由で一般的です。コストがかからないからです。チャレンジを避けたいスクレイパーは、信頼されているクローラーの名前を借りるだけで済みます。不適切に振る舞うクライアントは、人気のあるアシスタントを名乗れます。正当なツールであっても、ライブラリの既定値のせいで一般的なブラウザ文字列を送ることがあります。
その結果、User-Agent 許可リストには 2 つの失敗モードがあります。
- 誤った信頼: 信頼されていないクライアントが信頼済みの名前を名乗り、通過する。
- 誤った疑い: 正当なクライアントが想定外または一般的な文字列を送り、失敗する。
このどちらも、ヘッダーだけでは見えません。これが根本的な限界であり、リスト管理をどれだけ続けてもなくなりません。
それでもヘッダーが役立つ場面
だからといって、User-Agent 文字列を無視すべきという意味ではありません。素直に振る舞うクローラーやエージェントは正直に自分を名乗りますし、その名前はルーティング、分析、デバッグに役立つ手がかりです。クライアントが自分を何だと言っているかを教えてくれます。
その情報の置き場所は、単独でアクセスを解放する鍵ではなく、他の証拠と並べて評価される 宣言 です。Proof of Actor はそれをそのまま記録します。
逆引き DNS と IP リスト: 部分的な手段
多くのチームは、ネットワーク確認を加えて許可リストを強化します。これは役に立ちますし、正確に理解する価値があります。
逆引き DNS 検証
一部のクローラー運用者は、検証手順を文書化しています。まずリクエストの IP アドレスからホスト名を検索し、それが運用者のドメインに属しているかを確認します。次にそのホスト名を検索し、同じ IP に戻ることを確認します。この往復が成功すれば、そのリクエストが運用者のインフラから来たという実際の証拠があります。
ただし、制約は実務的です。この方法は、文書化して対応している運用者にしか使えません。キャッシュが必要な DNS 参照も増えます。そして、それが教えてくれるのはネットワークについてであり、そのネットワーク上でどの製品やエージェントがリクエストしたかではありません。
公開 IP 範囲
別の運用者は、自動クライアントが使う IP 範囲を公開しています。リクエストをそれらの範囲と照合する方法は高速で、逆引き DNS と似た証拠を与えます。IETF では、これらの範囲を公開するための標準形式について継続的に議論がありますが、2026-11 現在、確定した標準はなく、どの運用者が公開するかにカバレッジは依存します。
IP による証拠も、エージェントが共有クラウド基盤上、プロキシの背後、またはユーザー自身の端末から実行されるにつれて弱くなります。1 つのクラウドアドレスに無関係な複数のクライアントが載ることもありますし、人のブラウザから動くエージェントは、その人のネットワークに見えます。
ネットワーク確認で分かること
逆引き DNS と IP リストは、一部の著名な運用者について、いくつかの宣言をより強いものに変えます。ただし、エージェントやツールの長い尾まではカバーできませんし、AI と並んで作業する人についてはまったく役に立ちません。これらは部分的な手段です。使う価値はありますが、単独では十分ではありません。
署名と宣言の違い
より強い証拠は、暗号署名です。HTTP Message Signatures は RFC 9421 で定義されており、クライアントは各リクエストの選択された部分に秘密鍵で署名します。検証側は運用者が公開した公開鍵を取得し、署名を確認します。検証できれば、そのリクエストはその鍵の保有者が署名したものであり、署名された部分は途中で改変されていないことが分かります。
IETF の Web Bot Auth ワーキンググループは、自動クライアントがこれらの署名をどう使い、どう鍵を公開するかを標準化しています。私たちの Web Bot Auth for product teams の解説では、現在の状況を説明しています。
Proof of Actor では、有効な署名を verified の証拠として扱います。User-Agent 文字列、client hint、または request body 内の自己記述は declared とみなします。行動シグナルや文脈シグナルは inferred とみなし、そのようにラベルを付けます。どの結果も、その根拠が何かを明示するので、チームが主張と確認を取り違えることはありません。完全な定義は evidence basis の項目を参照してください。
1 つの制約は、verified の証拠にも当てはまります。有効な署名は、どの鍵がリクエストに署名したかを証明しますが、そのエージェントが求めている動作を実行する権限があることまでは証明しません。それは agent authorization の問題であり、アプリケーション側に残ります。
推測せずに Unknown を扱う
許可リストは、すべてのリクエストを 2 つの箱のどちらかに入れることを強制します。リストにあるか、ないかです。実際には、はっきりしないトラフィックは既定値で扱われますが、その既定値は通常、サイト全体で 1 回だけ決められます。
Proof of Actor は Unknown を第一級の結果として扱います。証拠が信頼できる判定を支えられないときは、推測せずにそう伝えます。そのうえでポリシーが、各ルートで Unknown をどう扱うかを決めます。
- 公開ドキュメントやマーケティングページでは、許可する。
- 検索や一覧取得のエンドポイントでは、通常の rate limit 付きで許可する。
- アカウント変更では、既存の確認を維持する。
- 影響の大きい操作では、レビューに回すか、より強いシグナルを求める。
handling Unknown traffic のガイドと unknown classification の項目では、これらのパターンを説明しています。Unknown の割合を時間とともに追跡すると、どれだけのトラフィックがまだ弱い証拠に依存しているかも分かります。
AI を使う人はどうなるのか?
User-Agent 許可リストでは、通常のブラウザ内で AI アシスタントを使う人について何も分かりません。その User-Agent は普通のブラウザ文字列だからです。それでも多くの製品は、たとえば AI で下書きされた投稿にラベルを付けたり、AI を使うユーザーがオンボーディングをどう進むかを理解したりするために、そのやり取りを認識したいと考えます。
Proof of Actor は、支援が宣言されているか、対応済みの統合を通じて観測された場合、そのやり取りを Human + AI として報告します。文体だけで推測することはしません。詳しくは AI-assisted interaction をご覧ください。
許可リストから証拠ベースのポリシーへ移行する
初日から許可リストを削除する必要はありません。安全な進め方は次のようになります。
- observation mode で導入する。 Proof of Actor は何も変更しません。許可リストはそのまま動きます。
- 比較する。 ルートごとに、どの許可済みリクエストが verified の証拠を持ち、どれが宣言だけで、どれが Unknown になるかを確認します。
- ポリシーを preview する。 verified なエージェント、宣言されたエージェント、Unknown を別々に扱うポリシーを作成し、実際のトラフィックへの影響を preview します。
- ルートごとに enforce する。 名前の偽装が最も問題になるルートから始めます。
- 許可リストは手がかりとして残す。 名前は引き続きルーティングと分析に役立ちますが、今ではその根拠も見えるようになります。
rolling out actor-aware policies safely のガイドでは各手順を説明し、verified automated requests では署名付きクライアントがどう組み込まれるかを解説しています。
許可リストで十分な場合
公開コンテンツ上で既知のクローラーに軽いページを返すような、重要度の低いルーティングでは、User-Agent 許可リストで十分なことがよくあります。名前を偽装されるコストは小さいからです。
チャレンジを省略する、より豊富なデータを公開する、書き込みを許可するといった判断に結果が伴う場合は、確認できる証拠が必要です。そのために Proof of Actor があり、すでに運用しているネットワーク確認やエッジ制御と並んで動きます。
始める
Proof of Actor は private beta です。選ばれた founding developer teams は、合意済みの利用上限の範囲で、最大 12 か月の無料利用を受けられます。自動課金はありません。早期アクセスを申請 して、今どのクライアントを許可リストに入れているか、どのルートをより良い証拠で守りたいかを教えてください。