メインコンテンツにスキップ
AIエージェント検知

証拠を添えた、Webサイト向けAIエージェント検知

Webサイト上の各インタラクションが、人間、人間がAIと協働しているもの、自律エージェント、またはまだ証拠で特定できない स्रोतに由来するのかを確認できます。すべての結果には、その根拠が示されます。

早期アクセスを取得仕組みを探る
Toshendra Sharma

著 Toshendra SharmaFounder & CEO, AgentCredia · Updated November 13, 2026

あなたの Webサイトには、もう一種類以上の訪問者がいる

Web の大部分の歴史において、Webサイトは単純な前提で考えられていました。人がブラウザーを開き、あちこちをクリックし、必要ならサインインする。analytics、rate limits、onboarding flow、security check はすべて、その人を前提に設計されていました。

その前提は、もはや実際の traffic を説明しません。今日では、1つの Webサイトが、自分で閲覧する人、AI assistant に要約や入力を依頼する人、他者に代わってページを読み endpoint を呼び出す autonomous agent、そして多数の crawler や script を相手にしています。AI provider も、こうした訪問者の一部を自ら文書化しています。たとえば OpenAI は、search crawler、training crawler、そして ChatGPT user が質問したときにページを訪れる fetcher を別々の user agent として公開しています (OpenAI crawler documentation)。Anthropic も同様に、ClaudeBot、Claude-User、Claude-SearchBot を公開しています (Anthropic crawler documentation)。こうした訪問者の一部は歓迎されます。別の体験が必要なものもあります。敏感な操作を許可する前に、より慎重な確認が必要なものもあります。

課題は、こうしたインタラクションの多くが、見た目には最初の段階で似ていることです。login は、どの account が使われているかは示します。しかし、その session で人がクリックしているのか、assistant が代わりに動いているのか、それとも自動 client が別の誰かのために pricing page を読んでいるのかまでは示しません。Webサイト向けAIエージェント検知 は、この差を evidence で埋め、すべての traffic を同じように扱うのではなく、各 actor に応じて適切に対応できるようにすることです。関係するシグナルを実務的に確認したい場合は、Webサイトの traffic が AI agent によるものかを見分ける方法 を読み、production site での見え方は websites use case を参照してください。

単一の bot score では足りない理由

多くのツールは、この問いに 1つの数値で答えます。bot score、risk score、訪問者がどれだけ human らしいかを示すと主張する percentage です。魅力は明らかです。1つの数値なら、rule に入れやすいからです。

問題は、その数値が判断の理由を隠してしまうことです。score が session をおそらく自動化と示しても、その結論が verified signature に基づくのか、誰でも複製できる user-agent string に基づくのか、あるいは高速に入力する human にも一致する pattern に基づくのか、チームは見えません。その score を使って block や challenge を行えば、何が間違っていたのかを顧客、同僚、監査担当者に説明する手段なしに、その誤りをすべて引き受けることになります。

Proof of Actor は別のアプローチを取ります。すべての結果は、Human, AI-assisted or agent: a taxonomy for app traffic で説明される 4つの明確な class のいずれかであり、さらに各結果には根拠が示されます。結論と evidence を一緒に確認できるため、強い結果は信頼し、弱い結果は問い直し、evidence の質に合った policy を構築できます。

Webサイトで AI agent を検知する 4つの手順

すでに持っているツールだけで、Webサイト上の AI agent 検知を始められます。この 4つの手順は vendor-neutral で、Proof of Actor を使うかどうかに関係なく適用できます。Webサイトの traffic が AI agent によるものかを見分ける方法 のブログ記事では、それぞれをさらに詳しく説明しています。

  1. 自ら名乗る agent を洗い出す。 server や CDN の logs で、AI provider が公開している user agent を検索します。OpenAI は OAI-SearchBot、GPTBot、ChatGPT-User を文書化しており、ChatGPT-User は自動 crawl ではなく、user が ChatGPT に質問したときにページを訪れると説明しています。Anthropic は ClaudeBot、Claude-User、Claude-SearchBot を文書化しています。これにより、route ごとの agent traffic の最初の declared な把握ができます。
  2. 文字列を信じるのではなく、主張を検証する。 user agent は自己申告であり、複製も簡単です。operator 自身の verification method と照合してください。Google は Googlebot について、reverse DNS lookup の後に forward DNS lookup を行い、公開された IP range file も参照する方法を説明しています (Google: verifying Googlebot)。Bing も Bingbot について同じ reverse と forward の DNS check を説明しています (Bing: verifying Bingbot)。OpenAI は各 user agent の IP range file を公開しています。client が HTTP Message Signatures で request に署名する場合は、RFC 9421 で定義された署名を、operator が公開した key と照合してください。
  3. すべての結果に evidence を付け、Unknown を残す。 各結論が verified、declared、inferred のどれかを記録します。verified または declared の agent に一致せず、明確な human pattern も示さない traffic は、human や bot に無理に分類せず Unknown とします。ここが、役立つ report と単なる推測を分ける段階です。
  4. 行動する前に route ごとに観察する。 数週間にわたって、public content、signup、account settings、APIs ごとに結果を分けて観察します。そのうえで初めて、actor context が最も重要な route に対して、Unknown 向けの明示的な fallback を含む narrow な policy を作成します。

Proof of Actor はこれらの手順を application 内で自動化します。統合で観測できるシグナルを収集し、根拠付きで class を返し、route ごとの Unknown を追跡し、policy はあなたの code に委ねます。

Proof of Actor はどのように Webサイト上の AI agent を検知するか

Proof of Actor は、シンプルな流れを中心に設計されています。すなわち、統合が観測できるシグナル、明示的な根拠を伴う分類、そして最終判断はあなたの手に残ることです。全体の流れは How It Works ページで確認できます。ここでは短く説明します。

統合から得られるシグナル

各統合は、そのコンテキストで許されるものを確認します。server-side integration は request context、protocol の詳細、そして client が対応していれば request signature を確認します。browser integration は、実行されるページ上の interaction signal を確認します。application は、AI 支援で下書きされたことを user が明示する宣言や、agent client が自らを名乗る情報など、自身の宣言も記録できます。

Proof of Actor は、実際に存在する evidence とだけ連携します。Webサイトが観測できないものを見えているふりはしません。

特定の意味を持つ 4つの class

各インタラクションは、次の 4つの class のいずれかに入ります。

  • Human: 観測可能なシグナルが、人間主導のインタラクションを示しています。
  • Human + AI: AI 支援が宣言されたか、またはそれを確認できる対応済みの統合で観測されました。
  • Agent: 検証可能な identity、または慎重に条件付けられた推論によって裏付けられた、自動化または agent 起点のインタラクションです。
  • Unknown: 利用可能な evidence だけでは、信頼できる判断を支えられません。

各 class には、明確な定義と明確な限界があります。Human の結果は verified identity ではありません。Agent の結果は、その agent が authorized であることを意味しません。Unknown の結果は、非難ではありません。完全な taxonomy は Detection & Limitations ページで確認できます。

各結果に付く根拠

class に加えて、すべての結果には basis として verified、declared、inferred、unknown のいずれかが付きます。公開された key に対して有効な signature を持つ request は、その検査において verified です。自ら agent であると名乗る client は、それを declared しています。自動化と整合する behavior pattern は inferred です。この区別があるからこそ、policy を正確にできます。読み取り専用 route 上の verified な signed agent と、account settings page 上の self-declared client を同じように扱うべきではありません。Proof of Actor なら、そうする必要はありません。evidence basis の glossary entry で、それぞれをさらに詳しく説明しています。

チームが得られるもの: Detect, Understand, Route

Proof of Actor は、連携して動く 3つの機能を持つ 1つの product です。

Detect

統合で利用できる actor signal を収集し、verified な主張と behavior inference を分離します。Unknown traffic は推測に埋もれず、独立した category として可視化され続けます。どのインタラクションについて自信を持って語れるか、どれがさらに evidence を必要とするかを常に把握できます。

Understand

AI agent traffic を文脈の中で確認します。route と時間ごとに interaction type を探り、人間、AI支援、agent、Unknown の活動の trends を追跡し、任意の classification を開いて、何が分かっていて、何が分かっておらず、その結果が何に基づいているのかを確認します。ここで product、platform、security team は、誰が Webサイトを利用しているのかについて、共通の説明可能な見取り図を得ます。

Route

独自の policy を使って、特定のインタラクションを allow、adapt、challenge、review、または limit します。文書を読む verified な agent には、構造化された response を返します。人間主導の session には標準の experience を維持します。敏感な account 変更では、条件に応じてより強い check を求めます。Unknown 結果と timeout には、route ごとに明示的な fallback を選びます。enforcement は常に application 内で行われ、チームが確認した policy に従います。

Webサイトを置き換えるのではなく、組み込むために設計されている

Proof of Actor は、すでに運用している tool と並んで動作します。authentication、authorization model、既存の abuse control を置き換えるものではありません。それらに actor context を加えるものです。

一般的な Webサイト統合は、actor context が最も重要な route から始まります。agent が多く読む public content、signup と onboarding flow、account settings などの敏感な action、そしてサイトを支える任意の API です。Founding team は当社の engineer と協力し、これらの route を選び、対象となる signal に合意し、code を本番に出す前に data の扱いを確認します。

判断レイヤーはあなたの code の中にあるため、experience を自分で制御できます。まずは internal dashboard で数週間結果を表示し、その後で 1つの route に対して 1つの narrow な policy を有効にし、結果が信頼に値すると確認できたら拡大できます。Unknown traffic の扱い方 の guide では、最初の rule をどのように設計するかを説明しています。

まずは observation mode から始める

AI agent 検知で最も早く価値を得る方法は、最初に止めるのではなく、観察することです。observation mode では、Proof of Actor は結果を記録しますが、Webサイトの動作は導入していない場合とまったく同じです。そのうえで team は、すでに理解している outcome と classification を比較できます。たとえば support ticket、既知の integration、社内 tool、そしてすでに認識している crawler です。

これにより、enforcement の前に次の 3つが得られます。

  1. ベースライン。 route ごとに、traffic のどれだけが human 主導、AI支援、agent 駆動、Unknown なのか。
  2. evidence への信頼。 Webサイトでどの signal が強く、どこで coverage を広げる必要があるのか。
  3. より良い policy。 仮定ではなく実際の pattern に基づいて設計された rule。false positive は、誰にも影響が及ぶ前に確認されます。

policy の準備が整ったら、そのために設計された特定の workflow に対して有効化し、必要に応じていつでも調整できるようにしておきます。

なぜ証拠に基づく検知が、不透明な score より優れているのか

Webサイトはすでに、agent、assistant、AI と協働する人々を並べて提供しています。これにうまく対応できる team は、最も厳しい filter を持つ team ではありません。判断を説明できる team です。

evidence に基づく結果は、その説明を可能にします。support agent から、なぜ user に追加の verification step が表示されたのかと尋ねられたとき、適用された evidence と policy を示せます。agent operator から、なぜ signed request に structured response が返されたのかと尋ねられたとき、verified な basis を示せます。evidence が薄い場合、結果は Unknown と表示され、fallback はあなたが意図して選んだ方法で処理されます。

このアプローチは web の拡大にも対応します。より多くの agent operator が request に署名し、IETF の Web Bot Auth working group のような標準化作業が HTTP Message Signatures に基づいて自動 client の cryptographic authentication を標準化していくにつれて、traffic のより多くが inferred または unknown から verified に移り、policy は書き直さずにより精密になります。

Founding developer program に参加する

Proof of Actor は、少数の application team とともに private beta で提供されています。選定された founding developer には、実践的な product feedback と引き換えに、合意した利用上限の範囲で最長 12 months の無料アクセスが提供されます。engineer から直接 integration support を受けられ、利用可能になり次第、新しい capability に早くアクセスでき、次に何を作るかにも実際に影響できます。

あなたの Webサイトが人、AI支援ユーザー、agent にサービスを提供しており、次に何が起こるかを決める前に、誰が使っているのかを知りたいなら、early access に申し込んでください。Webサイトについて、そして最も理解したいインタラクションについて教えてください。現在の beta に適しているかを確認します。

まず詳細を確認したいですか? Proof of Actor を見て、how it works を読み、evidence で何を確認できて何を確認できないか を正確に確認してください。

出典

開発者向け

What your code receives

Every interaction resolves to one result record. Your application reads the class and the basis and applies its own policy.

Result record
{
  "route": "GET /api/v1/catalog",
  "class": "agent",
  "basis": "verified",
  "evidence": [
    { "signal": "http_message_signature", "result": "valid", "keyid": "assistant.example" },
    { "signal": "client_declaration", "value": "assistant.example" }
  ],
  "observed_at": "2026-11-13T10:42:07Z"
}
class
Human, Human + AI, Agent, Unknown。
basis
証拠の強さです: Verified, Declared, Inferred, Unknown。
evidence
結果の背後にあるsignalsです。理由をチームが確認できます。

observation modeから始めます。結果をlogの横に記録し、policyを選ぶまで何も変更しません。 Node.js integration guideを読む

よくある質問

Proof of Actor は Webサイト向けのAIエージェント検知とどう連携しますか?

Proof of Actor は、統合を通じて利用できるシグナルを収集します。たとえば、request signatures、client の宣言、インタラクションシグナルなどです。そのうえで、verified、declared、inferred、unknown のいずれかを根拠とする分類を返します。

導入すると訪問者をブロックしますか?

いいえ。Proof of Actor はまず observation mode で開始します。チームが結果を確認している間も、Webサイトの動作はこれまでとまったく同じです。その後で、どの policy を適用するかを決められます。

別のタブで誰かが AI を使ったことは分かりますか?

どの Webサイトでも、別のタブや別のデバイスでの動作を確認することはできません。Proof of Actor は、対応する統合で宣言された場合、または観測可能な場合に AI 支援を報告します。それ以外は、設計上そのまま事実に忠実に扱います。

証拠が明確でない場合はどうなりますか?

結果は Unknown になります。Unknown は第一級の結果であり、デフォルトで Human とみなされることも、デフォルトで悪意ありとみなされることもありません。各 route をどう扱うかは policy が決めます。

Proof of Actor は誰向けに作られていますか?

SaaS applications、Webサイト、APIs、MCP servers を運用し、体験やアクセスの policy を決める前に、誰が何を行っているのかを理解したいチーム向けです。

どうすれば利用できますか?

Proof of Actor は private beta です。early access に申し込んでください。選定された founding developer team には、合意した利用上限の範囲で最長 12 months の無料アクセスが提供されます。

誰があなたの app を使っているかを把握します。

少数のfounding developer向けのprivate betaです。

早期アクセスを取得価格を見る

先に話しますか? 創業者に相談する