不明なトラフィック

未知の自動トラフィックを可視化する

多くのアプリケーションは、自身に流入する自動トラフィックのかなりの部分を判別できません。Proof of Actor は、そのトラフィックを独立したクラスとして可視化し、測定し、縮小し、意図を持って扱えるようにします。

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

誰にも名前を付けられないトラフィック

アプリケーションのログを詳しく見ると、説明のつかないリクエストが見つかります。ブラウザの文脈を持たないクライアントから来ており、user-agent strings は一般的だったり、空だったり、よく知られたブラウザのものをコピーしていたりします。リクエスト署名もしません。誰が送ったのかも述べません。無害なスクリプトもあれば、実際のユーザーのために動くエージェントもあります。まったく提供したくないツールもあります。

これが unknown automated traffic です。多くのチームはこれを 2 つのどちらかで扱います。ひとつは、人間として静かに数えてしまい、分析を歪めてリスクのある活動を通してしまう方法です。もうひとつは、既定で敵対的だとみなしてしまい、正当なユーザーやエージェントまで他のものと一緒にブロックしてしまう方法です。どちらも同じ欠点を持っています。欠けている証拠を、仮定で置き換えているのです。

Proof of Actor は逆の見方を取ります。証拠が信頼できる判断を支えないなら、正しい答えは Unknown です。そして Unknown は、可視で、測定できて、意図的に扱えるべきです。ブログ記事なぜ Unknown は AI トラフィックに対する有効な結果なのかで、その考え方を詳しく説明しています。

なぜ Unknown が第一級の結果なのか

Proof of Actor は、すべてのインタラクションを Human, Human + AI, Agent, Unknown の 4 クラスのいずれかに分類します。Unknown はエラー状態でも、製品の欠落でもありません。これは明確な意味を持つ、意図的な結果です。つまり、利用可能な証拠では信頼できる判断を支えられないということです。

この正直さには、実務上の利点があります。

分析の精度が保たれます。 Human と Agent の件数は、裏付ける証拠があるインタラクションだけを含むため、数字の意味がぶれません。
カバレッジを測定できます。 各ルートでの Unknown の割合を見ることで、どこに追加の証拠が必要かが正確に分かります。
ポリシーをより安全にできます。 不確かなケースは、黙って信頼済みとして扱われたり、推測でブロックされたりせず、あなたが選んだフォールバックに流れます。

Unknown は Human に変換されることはなく、既定で悪意あるものとして扱われることもありません。詳しくは、Unknown classification の用語集エントリ、Detection & Limitations、そしてなぜ Unknown は AI トラフィックに対する有効な結果なのかを参照してください。websites と APIs のユースケースでは、チームが実際に Unknown のフォールバックをどう設定するかを示しています。

Unknown な自動トラフィックはどこから来るのか

発生源を理解すると、扱い方を決めやすくなります。

署名されていない自動クライアント

HTTP Message Signatures によるリクエスト署名は、RFC 9421 で定義されており、これは任意です。また、IETF Web Bot Auth working group は、こうした方法で自動クライアントをどう認証するかを現在も標準化しています。署名がなければ、クライアントの身元は、自分自身について何を名乗るかに依存します。

コピーされた、または一般的な user agents

user-agent strings は簡単に設定できます。有名なブラウザやクローラーを名乗るクライアントが、本当にそうである場合もあれば、そう装っている場合もあります。 user-agent spoofing のエントリでは、このヘッダーだけでは分類を担えない理由を説明しています。検索エンジンが別の検証方法を文書化しているのも、このためです。Google は Googlebot の検証のために逆引きと順引きの DNS ルックアップ、および公開 IP 範囲を示しており、Bing は Bingbot の検証に同じ DNS チェックを示しています。

統合がないルート

ルートにブラウザ統合がなく、基本情報以外のサーバー側コンテキストもない場合、観測できるものは単純に少なくなります。そうしたルートでの Unknown は、脅威ではなくカバレッジの兆候です。

証拠の不足または遅延

タイムアウト、スクリプトのブロック、または不完全なリクエストにより、証拠が足りない結果になることがあります。Proof of Actor は、その不足を埋めずに、正直に報告します。

Proof of Actor が Unknown を扱えるものにする方法

Proof of Actor は、作業を 3 つの機能に整理しています。どれも未知の自動トラフィックに役立ちます。

Detect: Unknown を分離して保つ

シグナルは、verified, declared, inferred, unknown の基準で確認され、ラベル付けされます。判断を支えない場合、結果は Unknown となり、利用できたものとできなかったものの要約が付与されます。別のクラスに推測で押し込まれることはありません。

Understand: Unknown がどこにあるかを見る

Understand ビューでは、Unknown が各内訳、ルート別、時間経過ごとに表示されます。どのルートに未知の活動が最も多いか、統合を追加した後にどう変わるか、個々のインタラクションでどの証拠が存在したかを確認できます。これにより、曖昧な不安が具体的な地図に変わります。

Route: ルートごとにフォールバックを選ぶ

ルートごとに、異なるフォールバックが必要です。多くのアプリケーションにとって、妥当な出発点は次のとおりです。

公開ページとドキュメント: 標準の rate limits で Unknown を allow する。
Signup と onboarding: 既存のチェックは維持し、自社の条件が必要とする場合にのみ review を追加する。
アカウント変更やその他の機微なアクション: actor の推測ではなく、既存の認証と step-up controls に依拠する。
影響の大きい API 操作: その API がすでにサポートしている、より強い認証情報または controls を要求する。

未知のトラフィックの扱い方のガイドでは、各リスク層ごとの fail-open と fail-closed の選択を含め、これらのフォールバック設計を解説しています。

時間とともに Unknown を縮小する

目標は、Unknown を一晩でなくすことではありません。適切な理由で、毎月少しずつ小さくすることです。

重要な場所に統合を追加する。 キーページにブラウザ統合を、主要ルートにサーバー側統合を入れると、利用可能な証拠が増えます。
署名付きリクエストをサポートする。 エージェント運用者が HTTP message signatures を採用すると、Unknown だったトラフィックは、検証済みの Agent トラフィックになります。
自社アプリで宣言を記録する。 アプリケーションが AI 支援の関与を把握しているなら、それを明示してください。その証拠は正確で、コストも低いです。
エージェントの入口を用意する。 エージェント向けに構造化された経路を公開すると、隠れるのではなく名乗る動機になります。

Proof of Actor はルートごとに Unknown を追跡するため、これらの変化を数値で確認できます。

仕組み

すべてのインタラクションは、How It Works で詳しく説明されている同じ証拠優先の流れに従います。アプリケーションがリクエストまたはイベントを受け取り、統合がそのコンテキストで利用できるシグナルを収集し、シグナルは正規化され、明示的な基準付きで分類され、その結果は分析のために記録され、アプリケーションは独自のポリシーを適用するか、単に観測します。

タイムアウトと不足したテレメトリーは、明示的に処理されます。統合はそのルートで選んだフォールバックを使い、証拠が不足していたという理由で結果が Human に格上げされることはありません。

数か月後に良い状態とはどう見えるか

未知の自動トラフィックをうまく扱うチームは、たいてい同じ健全な状態に行き着きます。Unknown は、重要なすべてのルートで既知の量になり、人間とエージェントの活動と同じダッシュボードで追跡されます。各ルートには、プロダクト、プラットフォーム、セキュリティの各チームが合意した文書化済みのフォールバックがあります。より多くの運用者がリクエストに署名するにつれて、verified なエージェントトラフィックは増え、それらのエージェントはページをスクレイピングするのではなく、構造化された経路で提供されます。機微なアクションは、アプリケーションがすでに信頼している認証と step-up controls で保護され、actor の文脈はゲートキーパーではなく追加の入力として扱われます。

最も重要なのは、誰も推測していないことです。先週のトラフィックのうち、どれだけが自動だったのかを尋ねられたとき、答えはその基準とともに示されます。これだけが verified、これだけが declared、これだけが inferred、そしてこれだけがまだ Unknown です。これは、チームが計画の土台にできる数字です。また、経営層との会話も変えます。問題は「ボットが問題かどうか」ではなく、「どのルートにもっと証拠が必要で、どのフォールバックを洗練すべきか」になるからです。

観測モードから始める

Proof of Actor は、既定では何もブロックしません。観測モードでは、結果は記録される一方で、アプリケーションはこれまでどおり応答します。チームは、各ルートが受け取る未知の自動トラフィック量を把握し、すでに分かっている成果と比較し、実際のパターンに基づいてフォールバックを設計できます。ポリシーは 1 ルートずつ有効化され、チームが適合すると確信したときにのみ適用されます。

Founding Developer Program に参加する

Proof of Actor は private beta です。選定された founding developer team は、合意された利用上限の範囲で、製品フィードバックへの協力と引き換えに、最大 12 months の無料アクセスを受けられます。さらに、当社のエンジニアによる直接の統合支援も提供されます。

未知の自動トラフィックが分析やセキュリティ判断を曇らせているなら、early access に申し込むをご利用ください。アプリケーションのこと、そして Unknown が最も重要になるルートについてお知らせください。

Proof of Actor を確認し、how it works を読み、または証拠で何が立証できるかをご覧ください。

出典

RFC 9421: HTTP Message Signatures, IETF, February 2024.
Web Bot Auth (webbotauth) working group charter, IETF.
Verifying Googlebot and other Google crawlers, Google Search Central.
How to verify that Bingbot is Bingbot, Bing Webmaster Blog.

開発者向け

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 を使う人間か、自律エージェントかを信頼して示せない活動です。多くの場合、ブラウザの文脈がなく、一般的な user-agent strings かコピーされた user-agent strings を持つ署名なしのクライアントです。

未知のトラフィックは、単純にブロックすればよいのではありませんか?

Unknown は悪意と同じではありません。正当なクライアント、プライバシー重視のブラウザ、自分を名乗らないツールも含まれます。これを一律にブロックすると、実際の被害が出ます。ルートごとに意図的なフォールバックを設定する方がはるかに有効です。

Proof of Actor は Unknown を Human に変えることがありますか?

ありません。証拠が不足している場合やチェックがタイムアウトした場合も含め、Unknown の結果は Unknown のままです。各ルートのフォールバックは、あなたのポリシーが決めます。

未知のトラフィックは時間とともに減らせますか?

はい。より多くのルートで統合を追加し、署名付きリクエストをサポートし、アプリ内で宣言を記録すると、トラフィックは Unknown から、明確な基準を持つクラスへ移ります。

未知のトラフィックはどこで見られますか?

Understand ビューでは、Unknown が各内訳、ルート別、時間経過ごとに独自のクラスとして表示され、各インタラクションで利用可能だった証拠も確認できます。

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

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

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

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