メインコンテンツにスキップ
比較

Proof of Actor と Mixpanel: プロダクト分析と actor の証拠を並べて見る

Mixpanel は、ユーザーがどのように自社プロダクトを採用し、継続して使うかを把握するのに役立ちます。Proof of Actor は、各インタラクションで何が acting しているのかを、その根拠とともにアプリケーションに伝え、コードが次に何をするかを決められるようにします。ここでは、その違いと、両者をどう組み合わせるかを示します。

Toshendra Sharma

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

Mixpanel はプロダクト分析プラットフォームです。チームはこれを使って、どの機能が採用されているか、どこでファネルから離脱するか、誰が翌週戻ってくるかを把握します。この用途には非常に優れており、多くのプロダクトチームにとって、ユーザー行動に関する問いに答える場所になっています。

今では、その問いに新しいものが加わっています。プロダクト内のイベントの一部は、もはや人がクリックして発生させるものではありません。実際の顧客のために acting する AI agents、AI アシスタントと一緒に作業する人、まだ説明できない automation から発生します。ファネルを読む前に、その中のイベントを誰または何が生成したのかを知る必要があり、アプリケーションはその場で同じことを知って応答する必要があります。AgentCredia の Proof of Actor は、そのために作られています。

このページでは、両者を公平に比較します。以下の Mixpanel に関する事実は、2026年11月時点の Mixpanel 自身のドキュメントに基づいています。

要点

Mixpanel Proof of Actor
主な問い ユーザーはどう採用し、変換し、継続するのか? このインタラクションで acting しているのは誰または何か。そしてその証拠は何か?
収集場所 client と server の SDK に加え、取り込み API。可能なら server-side tracking を推奨 server middleware、edge、HTTP API、MCP servers、そして承認済みの browser collector
agent と bot のラベル user agent から分類された agent, bot, none の $mp_actor_type basis を明示した Human, Human + AI, Agent, Unknown
検証済みの agent identity Mixpanel の bot traffic documentation では説明されていない 公開鍵に対して request signature が検証された場合は Verified basis
AI 支援の人 別クラスとしては説明されていない 主要な結果として Human + AI
不明なトラフィック agent や bot に一致しない場合は none と表示 Unknown として報告され、選択した fallback を使える
トラフィックに対して action を起こすか いいえ。イベントを分析するだけ observation の後、独自コードで policy に従って route ごとに制御

このページの残りでは、それぞれの行を説明します。

Mixpanel のイベントモデルが想定する用途

Mixpanel はイベントと、それに付随する properties を中心に設計されています。sign up、create project、invite teammate などの action を計測し、plan や platform といった properties を追加してから、イベントをそれらで分解し、funnel、retention curve、flow、cohort を構築します。Mixpanel におけるあらゆる分析の問いは、最終的にはどのイベントが、誰に対して、どの property 値とともに発生したか、という問いになります。

このモデルは、actor context がその中に自然に収まる理由でもあります。actor label は単なる別の property であり、それをイベントに付ければ、すべての funnel と retention chart をそれで分解できます。Mixpanel もすでに、自身の actor labeling でこの方向に進んでいます。未解決の問いは、その property が何を根拠にしているか、そして request の処理中にアプリケーションが同じ答えを使えるかどうかです。

Proof of Actor は、その答えを request path で生成します。各インタラクションは 4 つの class のいずれかになります。signals が人を示す場合は Human、人が宣言された、または対応する integration を通じて観測された AI 支援で acting した場合は Human + AI、自動化された、または agent 起点のインタラクションは Agent、そして evidence が信頼できる判断を支えない場合は Unknown です。各結果は evidence basis として verified, declared, inferred, unknown のいずれかを示し、property を単なるラベルから、強さが明示されたラベルへと変えます。

それぞれが動く場所

Mixpanel は client-side と server-side の両方の tracking を提供します。tracking method の選択 に関するドキュメントでは、可能な限り server から tracking し、必要に応じて client-side tracking を補完することを推奨しており、client-side tracking は ad blocker の影響を受けると述べています。

Proof of Actor も server-side で動作しますが、その位置づけは異なります。あなたのアプリケーションの request path, Node.js middleware, Next.js, 自分で管理する edge layer, 汎用 HTTP API, または MCP server に置かれ、承認済みページでは任意で browser collector も使えます。これにより、request の瞬間に signals を確認できます。たとえば、client が signature を提示したか、client が自分を宣言したか、そして自分の assistant がその action を実行したか、です。完全な一覧は integrations ページを参照してください。

Mixpanel における bot と AI agents の扱い

Mixpanel はこの領域で実際の support を追加しており、それは評価に値します。Mixpanel の bot traffic documentation によると:

  • Mixpanel の JavaScript library は、Googlebot や Bingbot を含む既知の crawler の短い一覧をデフォルトで除外します。
  • $ignore property を設定して送信されたイベントは取り込み時に破棄されるため、自前の filtering logic を書けます。
  • Mixpanel の取り込み API は各イベントの user agent を分類し、$mp_actor_type (Actor Type) を、ユーザーの代わりに acting する LLM からの request には agent、crawler や search indexer のような一般的な automated traffic には bot、どちらでもない場合には none に設定します。type が agent または bot の場合、$mp_actor_name (Actor Name) には GPTBot や ClaudeBot などの分類された identity が入ります。
  • server-side tracking では、分類は Mixpanel に届いた request の user agent を使います。つまり、あなたの server の HTTP library の値が使われます。必要なら、たとえば $mp_raw_user_agent で end user's user agent を転送できます。そうしないと分類が不正確になる可能性があると Mixpanel は述べています。
  • Mixpanel のイベントは immutable なので、すでに記録された bot イベントは削除ではなく、分析から除外することで扱います。

これは有用な report label です。しかし設計上、user agent string から導かれたラベルでもあります。user agent string は自己申告であり、模倣も容易です。この問題は user agent spoofing の項目で扱っています。そしてドキュメントには、AI 支援で作業する人のための class や、証拠が弱すぎて判断できないと示す方法は記載されていません。

$mp_actor_type と Proof of Actor の class を並べて比較する

両方の結果を同じ Mixpanel event に載せられるので、その関係を確認すると分かりやすくなります。

$mp_actor_type 何に基づくか Proof of Actor class が追加できること
agent ユーザーのために acting する LLM に一致した user agent request に有効な signature が含まれていれば Verified basis、それ以外でも declared または inferred basis を持つ Agent
bot crawler と indexer に一致した user agent evidence がそれを支える場合は Agent、crawler 風の user agent に他の裏付けがなければ Unknown
none user agent に agent や bot の一致がない Human, Human + AI, Unknown のいずれかになり、支援を受けた人や説明のつかないトラフィックが同じ bucket に隠れなくなる

主な違いは、それぞれの答えがどこで生成されるかにあります。

user agent string を超える evidence. $mp_actor_type は user agent から導かれますが、前述のとおり自己申告で、模倣も容易です。user agent spoofing の項目で説明しているように、Verified な Proof of Actor の結果とは、HTTP Message Signatures を RFC 9421 で定義された方法で用い、Web Bot Auth でも使われている公開鍵に対して request signature を検証したことを意味します。

AI 支援の人のための class. $mp_actor_type では、assistant を使って下書きを行う人は、他のすべての user と一緒に none に入ります。Proof of Actor は、支援が宣言された場合、または対応する integration を通じて観測された場合に Human + AI を報告します。そのため、Mixpanel の funnel で、AI 支援ユーザーがより早く activation するのか、あるいは別の場所で停滞するのかを確認できます。

none ではなく Unknown. none は一致が見つからなかったことを意味します。Unknown は、判断に足るだけの evidence がなかったことを意味します。この違いは重要で、より有用です。Unknown rate を route ごとに追跡でき、Unknown traffic の扱い方 のガイドで fallback pattern を説明しています。

tracking を通らないイベント. agent は UI をクリックするよりも、API や MCP servers を呼び出すことが多くあります。Proof of Actor はそのような interaction を発生地点で分類し、MCP tool call も含みます。詳細は MCP servers のユースケース を参照してください。

request 時点での decision. Mixpanel の event は immutable で、後から分析するためのものです。それは analytics に適しています。Proof of Actor はさらに、あなたの application が route、class、basis ごとに allow、adapt、challenge、review に送る、または rate-limit することも可能にします。最初は observation mode で始まるため、enforce するまでは何も変更されません。

Mixpanel と Proof of Actor を併用する

  1. request 時点で classify する。 Proof of Actor は、あなたの application、API、または MCP server における各 interaction に対して class と basis を返します。
  2. 2 つの event property を追加する。 すでに送信している Mixpanel event に、たとえば actor_class と actor_basis と名付けた property として class と basis を付与します。server-side tracking なら、application 側に結果があるため簡単です。
  3. $mp_actor_type も保持する。 end user's user agent を転送して、Mixpanel 自身のラベルが正確なままになるようにし、2 つの property を比較します。食い違う場合は、Proof of Actor の basis がどの evidence を信頼すべきかを示します。
  4. 既存の report を分解する。 funnel, retention, flow を actor class で分けて、agent-driven の sign up が human と同じように継続するのか、AI 支援ユーザーがより早く activation に到達するのかを確認します。SaaS apps のユースケース は、この違いが最も重要になる場面を示しています。
  5. 重要な場所で action を起こす。 actor class によって体験を変えるべき route には policy を書きます。actor-aware policy を安全に展開する方法 のガイドで、その手順を説明しています。

どちらを選ぶべきか

Mixpanel を選ぶのは、問いが product behavior に関する場合です。activation、conversion、retention、feature adoption、そしてユーザーがたどる path が対象です。その $mp_actor_type ラベルは、その分析の中で agent と bot を切り分ける最初の有効な手がかりになります。

Proof of Actor を追加するのは、そのラベルに evidence が必要なとき、AI 支援ユーザーがプロダクトにとって重要なとき、多くの agent traffic が API や MCP servers 経由で届くとき、または application が report ではなく request 時点で応答する必要があるときです。Mixpanel は、あなたのプロダクトがどう使われているかを示します。Proof of Actor は、各 interaction で誰が使っているのかを evidence つきで示し、コードがそれに基づいて action を起こす方法を与えます。

始める

Proof of Actor は private beta です。founding developer program を通じて、選ばれたチームは合意済みの利用上限の範囲で最長 12 か月の無料利用を、通常の自動課金なしで受けられます。早期アクセスに申し込む から、あなたのプロダクトと、理解したい interaction について教えてください。

Mixpanel は Mixpanel, Inc. の商標です。

開発者向け

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

よくある質問

Mixpanel を Proof of Actor に置き換える必要がありますか?

いいえ。ファネル、継続率、プロダクトイベント分析には、引き続き Mixpanel が適しています。Proof of Actor は、インタラクションごとの actor classification を証拠の基準つきで追加し、それに基づいてアプリケーションがルーティングできるようにします。多くのチームは Mixpanel を使い続け、そのうえで Proof of Actor を追加します。

actor class を Mixpanel に送れますか?

はい。アプリケーションは各 Proof of Actor の結果を受け取るので、すでに追跡しているイベントに actor class と basis を event または user property として追加できます。そのうえで、Mixpanel のファネルや継続率を Human, Human + AI, Agent, Unknown で分解できます。

Mixpanel はすでに agent にラベルを付けています。なぜ Proof of Actor を追加するのですか?

Mixpanel のドキュメントによると、2026年11月時点では、その Actor Type property は user agent から分類されます。Proof of Actor は各結果の basis を明示し、HTTP Message Signatures で request signature を公開鍵に対して検証でき、AI 支援の人を Human + AI として報告し、証拠が薄い場合は Unknown を返し、結果に対して action を起こすための policy をコードに提供します。

Mixpanel はデフォルトで bot を除外しますか?

Mixpanel のドキュメントによると、その JavaScript library は既知の crawler の短い一覧をデフォルトで除外し、さらに $ignore property を設定すれば他のイベントを落とせます。また、取り込み API は各イベントの Actor Type を agent, bot, none のいずれかとして追加し、レポートでその値を基にフィルタできます。

Proof of Actor は何かをブロックしますか?

いいえ。導入時は observation mode から始まり、インストールしても何も変更しません。実際のトラフィックに対して policy を preview し、各 route ごとに自分のコードで enforce します。

Proof of Actor は server-side tracking と連携できますか?

はい。Proof of Actor は Node.js middleware、Next.js、edge、汎用 HTTP API、MCP servers で動作するため、ブラウザーを一切通らないインタラクションも分類できます。

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

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

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