Web の歴史の大半において、自動化されたトラフィックがセキュリティスタックの中で果たす役割は 1 つでした。それを特定し、止めることです。bot management はその役割のために発達してきました。インフラの edge に置かれ、リクエストをスコアリングし、悪用のように見えるものをブロックするか challenge します。その用途には非常に優れており、使い続けるべきです。
AI agent は、アプリケーションが知る必要のある内容を変えました。いまでは、自動化されたリクエストの増加分の多くが、実際の顧客のために動く agent から来ています。たとえば、プランを比較する assistant、support ticket を提出する agent、タスクを完了するためにあなたの MCP server を呼び出す client です。同時に、多くの人が AI assistant を隣に置いてプロダクトを使っています。これらは攻撃ではありません。ユーザーです。ブロックページではなく、適切な体験を与えるべき対象です。
このギャップを埋めるのが Proof of Actor です。このページでは、どちらがどこに属するのかを明確に比較します。
要点
| bot management | Proof of Actor | |
|---|---|---|
| 主な問い | このリクエストを止めるべきか? | 誰、または何が acting しているのか、そして証拠は何か? |
| 実行場所 | edge, アプリケーションの前面 | アプリケーション、API または MCP server の内部 |
| 典型的な出力 | allow, block, challenge のいずれか。多くの場合スコア付き | Human, Human + AI, Agent, Unknown のいずれかに basis を加えたもの |
| AI 支援下の人を | たいてい他の人と区別しない | Human + AI という別の class として扱う |
| 不明瞭なトラフィックを | challenge されるか block されることが多い | Unknown として扱い、route ごとに選べる fallback を用意する |
| 応答を決めるのは誰か | edge の rule set | アプリケーションコード |
| インストール直後の既定動作 | enforcement | observation。policy を追加するまで何も変わらない |
| 得意分野 | credential stuffing、scraping の悪用、ボリューム型攻撃の停止 | すべての actor に対する product、analytics、policy の判断 |
このページの残りでは、それぞれの行を説明します。
2 つの異なる問い
Bot management は 保護 の問いに答えます。その目的は、悪用される自動化をインフラ、アカウント、在庫から遠ざけることです。収集する signal はすべてその目的のために使われ、出力は判断です。リクエストを通すか、止めるか、あるいは challenge を挟むかです。
Proof of Actor は 理解 の問いに答えます。その目的は、各 interaction を動かしているのが誰、または何かをアプリケーションに伝え、どう提供するかを決められるようにすることです。出力はリクエストに対する verdict ではありません。証拠つきの classification です。
- Human: 観測可能な signal が、人による指示に基づく interaction を示しています。
- Human + AI: 人が AI の支援を受けて interaction を指示しており、そのことが declared または観測されています。
- Agent: 自動化された、または agent 起点の interaction で、検証可能な identity か、条件を満たした inference によって裏付けられています。
- Unknown: その evidence では信頼できる判定を支えられません。
各結果には evidence basis も示されます。verified、declared、inferred、unknown です。それこそが product の判断に必要な情報であり、保護スコアが担うようには設計されていない情報です。
それぞれが動く場所
Bot management は通常、network edge か reverse proxy で、すべての前段に置かれます。その位置は保護に最適です。トラフィックを早期に確認し、被害が発生する前に attack を吸収し、origin server をきれいに保ちます。
Proof of Actor は、アプリケーションロジックがある場所で動きます。server middleware、Next.js、制御下にある edge layer、承認済みの browser integration、汎用の HTTP API、または MCP server です。その位置によって、どの route が呼ばれているか、どの workflow に属するか、自社 assistant が action を実行したか、client が自分を宣言したかといった、アプリケーションが知っている情報にアクセスできます。詳細は integration paths を参照してください。
2 つは異なる場所で動くため、同じ仕事を奪い合いません。リクエストは bot management を通過してアプリケーションに届き、そのあと actor の文脈を受け取って応答が形作られます。
スコアと evidence
多くの保護製品は、判断をスコアとして表します。スコアは block の判断には効率的です。しきい値を決めて、その上なら対応すればよいからです。しかし「この actor にどんな experience を与えるべきか」という問いには、ずっと向いていません。
スコアだけでは、低リスクのリクエストが人から来たのか、assistant を使っている人から来たのか、それとも行儀のよい agent から来たのかは分かりません。結論のどの部分が verified で、どの部分が inferred なのかも分かりません。そして、数値に押し込めることなく「分からない」と表現することもできません。
Proof of Actor は、その区別を保ちます。verified な agent の結果は、たとえば HTTP Message Signatures を通じて、公開された key に対して request signature が検証されたことを意味します。declared な結果は、client か自社アプリケーションがそう述べたことを意味します。inferred な結果は、inference としてラベル付けされます。そして Unknown は、隠れた既定値ではなく、第一級の答えです。チームはすべての結果を読み、それが何に基づくのかを正確に確認できます。
AI 支援下の人は bot ではない
多くのアプリケーションで最も増えているのは、AI と一緒に作業する人です。assistant でメッセージを下書きし、支援を受けながらフォームを埋め、AI tool を横に置いてプロダクトを使います。保護用の tooling は、彼らを他の人から分けるために作られておらず、その必要もありません。
一方で、プロダクトにはそれが必要なことがあります。AI で下書きされた support ticket にラベルを付けて適切な team が扱えるようにしたいかもしれません。AI 支援ユーザーが onboarding をどう進むかを測定したいかもしれません。あるいは、より滑らかな経路を提供したいかもしれません。Proof of Actor はこのグループに Human + AI という独自の class を与え、支援が declared されるか、サポートされた integration を通じて観測された場合にのみ報告します。詳しくは AI-assisted interaction の glossary entry を参照してください。
Unknown は脅威ではなく答え
すべての classifier は、説明できないトラフィックに遭遇します。保護システムは慎重寄りに作られているため、不明瞭なトラフィックには challenge が返されることが多くなります。edge では、それは妥当な選択です。
しかしアプリケーション内では、慎重な既定動作が 1 つだけでは不十分なことがよくあります。公開ドキュメントページへの Unknown なリクエストと、アカウントの password を変更する Unknown なリクエストでは、必要な扱いがまったく異なります。Proof of Actor は Unknown を独立した結果として返し、fallback を route ごとに設定できます。公開ページでは通す、アカウント変更では既存の確認を維持する、影響の大きい action では review に回す、といった具合です。Unknown traffic の扱い のガイドでパターンを確認できます。
応答を決めるのは誰か
bot management では、edge の rule set が判断します。これは効率的で、各 property で一貫した decision を保てます。
Proof of Actor では、アプリケーションが判断します。product が actor の文脈を提供し、コードが policy を適用します。verified な agent には人向けページではなく構造化された API を返す、通常の session では標準の experience を維持する、AI 支援の submission にラベルを付ける、条件が必要と判断された敏感な action ではより強い credential を求める、といったことができます。policy は route ごと、actor class ごと、basis ごとに記述され、他の business logic のすぐ隣に置かれます。
まずは observation
Bot management は通常、悪用を止めること自体が価値なので、enforcement のために導入されます。
Proof of Actor は observation mode から始まります。導入しても、アプリケーションの振る舞いは何も変わりません。route ごとの実際の actor の内訳を確認し、evidence を見直し、実トラフィックに対する policy の影響を preview し、準備が整ったら 1 つの route ずつ enforcement します。actor-aware policies を安全に展開する方法 のガイドで手順を説明しています。
2 つをどう組み合わせるか
最も強い構成は、レイヤーごとに両方を使うことです。
- edge では bot management が credential stuffing、scraping の悪用、ボリューム型攻撃を止めます。
- アプリケーション内では Proof of Actor が、通過したトラフィックを Human、Human + AI、Agent、Unknown に basis 付きで分類します。
- コード内では policy がその文脈を使い、体験を選びます。verified な agent には構造化された API、人には通常の flow、AI 支援の submission にはラベル、Unknown には明示的な fallback を与えます。
- analytics では どの actor class がどの route や workflow を使っているかを team が確認でき、product と security が同じ picture を見て動けます。
edge の判断を actor の結果の隣に記録すると、picture は完全になります。つまり、保護が何をしたか、そして実際に誰が acting していたかです。
どちらを選ぶべきか
主な問題が悪用であるなら、bot management を選んでください。たとえば account takeover の試行、在庫の独占、攻撃的な scraping、トラフィックの flood です。
主な問いがユーザーに関するものであるなら、Proof of Actor を選んでください。たとえば、どれだけの人がすでに product を agent と一緒に使っているか、どの agent が API や MCP server を呼び出しているか、AI 支援ユーザーがどこでつまずくか、どの route に actor-aware policy が必要か、という点です。
実運用の application、API、MCP server を運用する多くの team は両方の答えを必要としており、そのため 2 つは同じ stack に属します。
始め方
Proof of Actor は private beta です。選ばれた founding developer team は、合意された usage limit の範囲で最長 12 months の無料 access を受けられ、開発チームから直接 support を受けられます。early access に申し込む から、理解したい application と interaction について教えてください。