ダッシュボードは、変化した世界を数えています
多くのアナリティクススタックは、1 つの問いに答えるために作られてきました。それは「サイトで人は何をしているのか?」という問いです。セッション、ページビュー、ファネル、キャンペーンは、どのインタラクションにも人がいることを前提にしています。
その前提は、もはやすべてのインタラクションには当てはまりません。AI アシスタントはユーザーの代理でページを開きます。たとえば OpenAI は、ユーザーが ChatGPT に質問するとページを訪問する ChatGPT-User エージェントについて文書化しています (OpenAI crawler documentation)。自律エージェントは API と MCP ツールを呼び出してタスクを完了します。人は同じセッション内で AI と並走し、時にはそれを明示し、時にはしません。クローラーやスクリプトは、到達できるものを読み続けます。
その結果、チームが依存している数値には静かな歪みが生まれます。コンバージョン率が、誰にも説明できない理由で動きます。人気の API ルートが、実際には少数の自動クライアントに駆動されていたことが分かります。マーケティングの成果に見えた急増が、実際にはエージェントによるドキュメント閲覧だったこともあります。actor の文脈がなければ、どのチャートもまったく異なる振る舞いを 1 本の線に混ぜてしまいます。さらに、一部のツールは、あなたが見る前に状況の一部を取り除いてしまいます。Google は、Google Analytics が既知の bot と spider からのトラフィックを自動的に除外し、どれだけ除外されたかは確認できないと述べています (Google Analytics: known bot-traffic exclusion)。
AI エージェント トラフィック分析 は、各インタラクションに新しい次元を加えることで、それを解消します。それは「誰または何が作用しているのか」、そして「どれだけ確かなのか」という次元です。ウェブサイトのトラフィックが AI エージェント由来かを見分ける方法 では、その次元を支えるシグナルを扱い、websites のユースケース では実運用サイトへの適用例を示しています。
actor を意識したアナリティクスで分かること
Proof of Actor は、Human, AI-assisted or agent: a taxonomy for app traffic で説明している 4 つのクラスにトラフィックを整理し、それぞれに証拠を付与します。
- Human: 観測可能なシグナルが人による操作を示しているインタラクション。
- Human + AI: AI の支援が宣言されている、または対応済みの統合を通じて観測されたインタラクション。
- Agent: 検証可能な ID、または慎重に条件付けられた推論によって裏付けられた、自動化またはエージェント起点のインタラクション。
- Unknown: 証拠が信頼できる判定を支えないインタラクション。
各結果には、verified、declared、inferred、unknown の basis も付きます。この 2 つ目の次元が、アナリティクスの信頼性を支えます。API トラフィックの 3 分の 1 がエージェントだとするダッシュボードも、その結果が署名で verified されたものなのか、リクエストパターンから inferred されたものなのかで意味が大きく変わります。Proof of Actor では、両方を確認でき、どちらでも絞り込めます。
ルートとワークフローごとに
actor の構成は、アプリケーション内で大きく異なります。公開ドキュメント、価格ページ、カタログページには、エージェントやアシスタントが集まりやすくなります。サインアップ、チェックアウト、アカウント設定にはエージェントは少ない一方で、現れると影響はより大きくなります。API ルートと MCP ツールは、自動クライアントが大半を占めることもあります。Proof of Actor は結果をルートとワークフローごとに分解するため、各チームは自分たちが責任を持つ範囲だけを見られます。
時間の経過とともに
トレンドを見ると、プロダクトがどの方向へ進んでいるかが分かります。重要なルートで agent と AI-assisted のアクティビティ比率がどう変化しているかを追い、新しい agent operator がコンテンツを読み始めたタイミングを把握し、より多くのクライアントがリクエストに署名するにつれて Unknown から verified に移るトラフィック量を追跡できます。
説明つきで
ダッシュボード上のどの数値も、個々のインタラクションまで掘り下げられます。各項目では、クラス、basis、分かっていること、分かっていないこと、そして適用される policy 出力を確認できます。これにより、チャートは、プロダクト、プラットフォーム、セキュリティの各チームが共に対応できるものになります。
仕組み
Proof of Actor は evidence-first の流れで動きます。詳細は How It Works で確認できます。
- アプリケーションがリクエストまたはイベントを受け取る: ページビュー、API 呼び出し、MCP ツール呼び出し、またはアプリ内アクション。
- 統合が、その文脈で利用できるシグナルを収集する: サーバー上のリクエスト文脈と署名、collector が動作するブラウザー内のインタラクションシグナル、クライアントや自社アプリケーションからの宣言。
- シグナルを検証し、basis を付け、組み合わせることで分類にする。
- 結果を記録する。basis と証拠の要約を含めて、アナリティクスに流し込む。
- アプリケーションが判断する: 監視のみで進めるか、policy を適用するか。
アナリティクスと判断が同じ結果を使うため、あなたが確認する数値は、そのまま policy が作用する数値です。ダッシュボードが示す内容と、アプリケーションの実動作の間にずれはありません。
Detect, Understand, Route
AI エージェント トラフィック分析は、Proof of Actor の 3 つの能力の中間にあります。
Detect
各統合で利用できる actor シグナルを収集し、verified の主張と行動ベースの推論を分離します。Unknown は独立したクラスとして可視のまま残るため、カバレッジの欠落が他の数値の中に隠れることはありません。
Understand
これがアナリティクス層です。actor の内訳、インタラクションのトレンド、ルート単位のビュー、説明可能な分類を提供します。チームは、エージェントが依存するルート、ワークフローが受ける AI-assisted アクティビティの量、policy を支えるのに十分な証拠がある場所などを答えるために使います。
Route
アナリティクスが明確なパターンを示したら、自社のルールで対応します。verified なエージェントには、よく読むコンテンツへの構造化された経路を与えます。人が主導するセッションには標準の体験を維持します。機密性の高い操作には、自社の条件が正当化するときだけ review を追加します。Unknown とタイムアウトには、明示的なフォールバックを設定します。
アプリ、API、MCP server 向けに設計
エージェントの活動は、機械が歓迎される場所に集中します。API、ドキュメント、カタログ、ツールです。そのため Proof of Actor は、ページビュー以上をカバーします。
- SaaS アプリと website では、ブラウザー セッションとそれを支えるサーバー ルートに actor の文脈が付きます。詳しくは SaaS Apps & Websites を参照してください。
- API では、署名済みのクライアント ID と API 認証情報および認可を分離するリクエスト単位の文脈が得られます。詳しくは APIs を参照してください。
- MCP server では、各ツール呼び出しごとに actor の文脈が得られるため、どのクライアントがどのツールを使っているかを確認できます。詳しくは MCP Servers を参照してください。
Founding チームには、当社エンジニアが直接サポートします。 Node.js app に actor context を追加する方法 のガイドでは、一般的な request handler のどこに統合が入るかを示しています。
なぜ量より証拠が重要なのか
agent traffic の大きな数値を出すのは簡単です。browser fingerprint のない全リクエストを数えて automation と呼べばよいからです。問題は、そのような数値では意思決定を支えられないことです。本物がどれだけ含まれているのか、誰にも分からないからです。
Proof of Actor は、すべての数値を説明可能にするように設計されています。verified 結果は、実際に通過したチェックから得られます。declarations は declaration としてラベル付けされます。inferences は inference としてラベル付けされます。Unknown は Unknown として報告されます。agent traffic を経営層、セキュリティ チーム、顧客に示すとき、各数値の出所を正確に説明できます。
これにより、時間が経ってもアナリティクスはより役立ちます。agent operator が RFC 9421 HTTP Message Signatures に基づく署名付きリクエストを採用し、Web Bot Auth のような標準化作業が IETF の webbotauth working group で進むにつれて、トラフィックのより多くが verified basis に移ります。読み方を変えずに、チャートはより鮮明になります。
まず監視し、その後に判断する
Proof of Actor の導入は、すべて observation モードから始まります。結果が記録され、アナリティクスが埋まり、アプリケーションの応答はそれまでとまったく同じです。その期間に、チームはベースラインを作り、すでに分かっている結果と比較し、policy が本当に役立つ最初のルートを特定します。
準備ができたら、1 つのワークフローに policy を有効化し、影響を測定し、そこから広げます。Proof of Actor を入れたからといって、何かがブロックされることはありません。すべての enforcement の判断はあなたのものです。
Founding developer program に参加する
Proof of Actor は private beta です。選定された founding developer チームには、実務的な製品フィードバックと引き換えに、合意した利用上限の範囲で最大 12 か月の無料アクセスが提供されます。直接の統合サポート、新機能への早期アクセス、ロードマップへの関与を得られます。
チーム全体で信頼できる AI エージェント トラフィック分析をお探しなら、早期アクセスに申し込んでください。アプリケーション、重視しているルート、アナリティクスで答えたい問いをお知らせください。
Proof of Actor を確認し、仕組みを見る、または evidence で何が立証できるか をお読みください。
出典
- OpenAI crawlers の概要, OpenAI.
- Known bot-traffic exclusion, Google Analytics Help.
- RFC 9421: HTTP Message Signatures, IETF, February 2024.
- Web Bot Auth (webbotauth) working group charter, IETF.