人間 vs エージェントトラフィック

人間、AI支援、エージェントのトラフィックを見分ける

すべてのやり取りに明確なクラスと根拠を与え、アプリケーションが人、AIと協働する人、自律エージェントにそれぞれ適切に応答できるようにします。

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

もはや2つの分類では足りない

長年、トラフィックは人間と bot の2つに分けられてきました。人間には製品を提供し、bot はブロック、rate-limit、または無視するという考え方です。

しかし、その分け方はもう通用しません。自動化された訪問者の中には、実在の顧客の代理で動く agent もいます。たとえば、プランを比較するアシスタント、API 経由でデータを取得する agent、タスクを完了するために MCP server を呼び出すツールです。AI プロバイダー自身も、こうしたユーザー起点のアクセスを文書化するようになっています。OpenAI は、ユーザーが ChatGPT に質問したときに ChatGPT-User agent がページを訪問すると説明しており(OpenAI crawler documentation)、Anthropic も同じ目的の Claude-User を掲載しています(Anthropic crawler documentation)。同時に、人が AI と二人三脚で作業し、メッセージを下書きし、フォームを埋め、アシスタントを横に置いて製品を操作することもあります。これらすべてを人間か bot のどちらかに押し込めると、両方向で誤った判断につながります。正当な agent はブロックされ、実際の人間は行動が普通でないように見えるために challenge されます。

良い判断につながる形で 人間とAIエージェントのトラフィックを見分ける には、より多くの分類が必要であり、各結果をどれだけ信頼できるかを把握する必要があります。ウェブサイトのトラフィックがAIエージェント由来かを見分ける方法のブログ記事では、その判断を可能にするシグナルを解説し、SaaS アプリのユースケースでは、この区別がどのように製品判断を変えるかを示しています。

4つのクラス、それぞれに厳密な意味がある

Proof of Actor は、やり取りを4つのクラスに分類します。それぞれに定義と明確な限界があるため、チームの誰も結果以上の意味を読み込まずに済みます。この分類法の背景については、Human, AI-assisted or agent: a taxonomy for app traffic をお読みください。

Human

対応する観測可能なシグナルが、人が主導するやり取りを示しています。このクラスが表すのは、やり取りを誰が指示しているかであり、本人確認ではありません。Human の結果は、その人が誰であるかを検証するものではなく、どこかで AI が使われていないと主張するものでもありません。

Human + AI

AI 支援が宣言されたか、対応する支援付き integration を通じて実際に観測されました。たとえば、独自の開示コントロールでユーザーがコンテンツを AI で下書きしたと示す場合や、サインイン済みユーザーのためにアプリケーション内蔵アシスタントが操作を実行したとアプリケーションが報告する場合が含まれます。詳細は用語集の AI-assisted interaction をご覧ください。

Agent

自動化された、または agent 由来のやり取りで、公開された鍵に対して有効な request signature があるなど、検証可能な識別情報に裏付けられるか、あるいは慎重に限定された推論に基づきます。Agent の結果は、誰が行動しているかを示します。それは、その agent が許可されていること、安全であること、または人からの有効な delegation のもとで動いていることを意味しません。自律エージェントについて詳しく読む。

Unknown

利用可能な証拠では、信頼できる判断を下せません。Unknown は正直で有用な結果です。どこまでがカバー範囲かを示し、不確かなケースを偶然ではなく意図的にポリシーで扱えるようにします。

すべてのクラスには basis がある

人間と agent のトラフィックを分けるだけでは、仕事の半分にすぎません。もう半分は、それぞれの結論がどれだけ強いかを知ることです。そのため、Proof of Actor のすべての結果には basis が付与されます。

Verified: 検証可能な主張が確認済みであること。たとえば、公開鍵に対して確認された request signature です。
Declared: クライアントまたはアプリケーション自身がそう示したこと。たとえば、agent が自分を名乗る場合や、ユーザーが AI 支援を開示する場合です。
Inferred: 行動または文脈のシグナルから導かれた結論であり、常に推論としてラベル付けされます。
Unknown: 判断に十分な証拠がないこと。

クラスと basis の組み合わせによって、精密なルールを構築できます。検証済みの agent と推論された agent はどちらも agent ですが、前者には構造化された API を与え、後者には標準的な rate limit を適用したい場合があります。宣言された AI 支援の送信と human セッションはどちらも通常どおり進められますが、サポート担当が把握しやすいラベルが付きます。完全な分類体系は Detection & Limitations にあります。

分類はどのように行われるか

Proof of Actor は、すべてのやり取りに対して同じ evidence-first の流れをたどります。詳細は How It Works にあります。

統合が確認できるシグナル

Request signatures: 公開された鍵を持つ自動化クライアントからの署名で、RFC 9421 で定義された HTTP Message Signatures を使用します。IETF の Web Bot Auth working group は、この方法で自動化クライアントを認証する仕組みを標準化するために設置されています。
Declarations: 自身を識別するクライアントからの宣言。たとえば、文書化された AI crawler や fetcher の user agent、また AI 支援が関与していることをアプリケーション自身が把握している場合です。
Request context: headers や protocol の詳細など、server-side integration で利用できる情報。
Interaction signals: 実行されるページ上で承認済みの browser integration から得られるシグナル。

シグナルから結果へ

シグナルは確認され、basis によってラベル付けされ、組み合わされます。強い検証済み証拠は、確信度の高い結果を生みます。弱い、または矛盾する証拠は、限定付きの推論または Unknown になります。タイムアウトや欠落したシグナルが Human の結果に変わることはありません。出力は、クラス、basis、そしてチームの誰でも読める evidence summary です。

トラフィックを分離した後にできること

Proof of Actor は、Detect、Understand、Route の3つの機能を中心に構成されています。

各やり取りの背後にある actor を Detect する

各文脈で利用可能なシグナルを収集し、検証済みの主張と推論を分離します。Unknown は見えるままにしておきます。

各 actor が製品をどう使っているかを Understand する

route ごと、時間の経過とともに、人間、AI 支援、agent、Unknown の活動の混合を確認できます。どの結果でも開いて、何が分かっていて何が分かっていないかを見られます。agent が集中する route や、AI 支援が一般的な workflow を見つけられます。

各 actor を適切な体験へ Route する

証拠が裏付けるときに、自分たちのポリシーを適用します。公開ウェブサイトでは、websites use case が、こうした選択が実際の route にどう対応するかを示しています。

検証済みの agent には、人間向けページの代わりに構造化された応答または API を提供する。
人が主導するセッションには、標準の体験を維持する。
AI 支援の送信にはラベルを付け、適切なチームが対応できるようにする。
自分たちの条件で必要な場合は、機微な操作に対してより強い credentials を求める。
各 route で Unknown の明示的な fallback を選ぶ。たとえば、公開ページは許可し、アカウント変更では既存の確認を維持する、といった形です。

actor-aware policies を安全に展開する方法のガイドでは、観測から enforcement へ、1つの route ずつ移行する方法を説明しています。

これがユーザーにとって重要な理由

これを正しく行うことは、アプリケーションを使うすべての人にとって良いことです。

曖昧なスコアだけを理由に challenge されないため、人々はより滑らかな体験を得られます。AI と協働する人々は、適した workflow で開示された支援を受けられます。正当な agent は、仕事をこなすための信頼できる構造化された方法を得られ、スクレイピングやインターフェースへの負荷が減ります。チームは説明可能な判断を得られるため、サポート対応、インシデントレビュー、ポリシー変更を推測ではなく証拠に基づいて行えます。

ログインは actor ではない

最もよくある混乱の原因の1つが、アカウントそのものです。サインイン済みセッションは、どのアカウントが使われているかを示します。現在のやり取りを誰が指示しているかまでは示しません。同じアカウントが、午前中は所有者が設定を操作するために使われ、正午には所有者がレポートの書き出しを依頼したアシスタントに使われ、夕方には API キーで動く agent に使われることがあります。

この3つを同じように扱うと、両方向で問題が発生します。アカウント上のすべての request を所有者によるものだと仮定すると、agent が人向けに設計された workflow に到達してしまう可能性があります。逆に、少しでも通常と違う request を攻撃だと仮定すると、所有者自身のツールがブロックされます。actor をアカウントから分離すると、アプリケーションは authentication と authorization をそのまま維持しつつ、今まさに誰が行動しているのかという欠けていた文脈を追加できます。その文脈があるからこそ、人向けの workflow を開放せずに、agent に構造化されたアクセスを提供できるのです。

まずは観測モードから始める

すべての導入は観測モードから始まります。Proof of Actor は、アプリケーションがそれまでどおり応答する間に、結果を記録します。チームは、人間、AI 支援、agent、Unknown の活動の baseline を作り、すでに分かっている結果と比較し、1つもルールを変更する前に false positive を確認します。ポリシーの準備ができたら、まず1つの workflow で有効にし、そこから広げていきます。

Founding Developer Program に参加する

Proof of Actor は、少数のアプリケーションチームとともに private beta で提供されています。選ばれた founding developer は、合意された利用制限の範囲内で、最大12か月の無料利用を受けられ、実地でのフィードバックを提供します。エンジニアから直接 integration support を受けられ、機能への早期アクセスがあり、優先順位にも影響を与えられます。

アプリケーション内の人間とAIエージェントのトラフィックを見分ける必要がある場合は、early access に申し込むうえで、最も理解したい interaction について教えてください。

Proof of Actor を見る、how it works を読む、または証拠が何を示せるのかを正確に確認するには what the evidence can establish をご覧ください。

Sources

RFC 9421: HTTP Message Signatures, IETF, February 2024.
Web Bot Auth (webbotauth) working group charter, IETF.
Overview of OpenAI crawlers, OpenAI.
Does Anthropic crawl data from the web, and how can site owners block the crawler?, Anthropic.

開発者向け

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を読む

よくある質問

人間とAIエージェントのトラフィックはどう見分けますか?

Proof of Actor は、request signatures、client declarations、request context、browser interaction signals など、統合で観測できるシグナルを組み合わせ、明示的な basis 付きのクラスを返します。

なぜ Human + AI クラスがあるのですか?

人によっては、そばに AI アシスタントを置いて作業しています。それを完全に人間として扱うか、完全に自動化として扱うかでは、重要な文脈が失われます。Human + AI は、宣言された支援や、対応する integration で観測できる支援を対象にします。

Agent の結果は悪質な bot と同じですか?

いいえ。多くの agent は正当な参加者です。Agent の結果は、何が行動しているかを示すものであり、その行動が許可されているかどうかを示すものではありません。各 agent をどう扱うかは、ポリシーで決めます。

トラフィックを分類できない場合はどうなりますか?

それは Unknown として報告されます。これは第一級の結果です。Unknown が Human に変換されることはなく、既定で悪意あるものとして扱われることもありません。

何かをブロックする必要がありますか?

いいえ。まずは観測モードから始め、結果を確認し、チームが適合すると確信できる場所だけでポリシーを有効にします。

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

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

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

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