CAPTCHAは単純な考え方です。訪問者の前に、人間なら解けて機械には解けない課題を置き、通過した人をそのまま通します。長いあいだ、それは妥当な取引でした。人は数秒失い、最悪の自動化は遅くなりました。
しかし、3つのことが変わりました。機械は課題を解くのが上手くなり、人はそれにうんざりし、そして新しい種類の訪問者が現れました。実際の顧客のために動くAIエージェントと、AIアシスタントを使って作業する人です。「あなたは人間ですか?」と尋ねるテストには、そのどちらにもよい答えがありません。
Proof of Actorは別のアプローチを取ります。すべての訪問者をテストする代わりに、結論の背後にある証拠とともに、アプリケーションに誰が、または何が行動しているかを伝え、チャレンジが本当に必要かどうかをコードに判断させます。
短く言うと
| CAPTCHA | Proof of Actor | |
|---|---|---|
| 主な問い | この訪問者は人間向けのテストを通過できるか? | 誰が、または何が行動しているのか、そして証拠は何か? |
| コストを負うのは誰か | チャレンジを見るすべての訪問者 | 誰もいない。分類はバックグラウンドで行われる |
| あり得る答え | 通過または失敗 | Human、Human + AI、Agent、Unknown、そしてbasis |
| 正当なAIエージェント | 止められるか、テストを回避することを強いられる | 認識され、適切な体験に振り分けられる |
| AIアシスタントを使う人 | ほかの訪問者と同じように扱われる | Human + AIという別のクラス |
| 判別が難しいトラフィック | 同じテストを通過しなければならない | Unknown。ルートごとに選ぶフォールバックあり |
| 適用範囲 | 置いたページ | 統合がカバーするすべてのroute |
| 導入時の既定動作 | 目に見えるチャレンジ | 観測。policyを追加するまで何も変わらない |
テストと証拠
CAPTCHAが返す情報は1ビットだけです。訪問者が通過したか、失敗したかです。訪問者が誰だったのか、アシスタントと一緒に作業していたのか、結果にどれくらい確信を持つべきかは分かりません。しかも、その1ビットは訪問者に作業をさせることで得られます。
Proof of Actorは分類とそのevidence basisを返します。verifiedな結果は、公開鍵に照らして検証できる要求署名のように、確認可能な主張が検証されたことを意味します。declaredな結果は、クライアントまたはあなた自身のアプリケーションがそう述べたことを意味します。inferredな結果は推論としてラベル付けされます。Unknownは、証拠が判断を支えないことを意味します。チームは各結果を読み、何に基づくものかを確認でき、訪問者は何もする必要がありません。
すべての人をチャレンジするコスト
すべてのチャレンジは、最も良いユーザーの上に摩擦を置いて、最も悪い利用を遅くするものです。サインアップページではコンバージョンを失い、チェックアウトでは売上を失います。アクセシビリティの観点では、人を完全に締め出すこともあります。チームがそのコストを受け入れるのは、相手側に誰がいるのかを示す、よりよいシグナルを持っていないからです。
actor contextがあれば、その取引は変わります。人が主導するセッションには通常の体験を保ち、証拠が十分な場所ではチャレンジを省き、まだ価値がある狭い範囲にだけ残せます。たとえば、パスワード変更や高価値アクションでのUnknown結果です。ほとんどの訪問者は、もうチャレンジを目にしません。
正当なエージェントにはパズルではなく経路が必要です
CAPTCHAはソフトウェアを止めるために作られています。ページを訪れるソフトウェアのほとんどが不要だった時代には、それで意味がありました。今は違います。
現在では、アシスタントが顧客のためにあなたのプランを比較し、エージェントがアプリケーション経由で会議を予約し、AIクライアントがタスクを完了するためにあなたのMCP serverへ呼び出しを行うことがあります。それらを止めることは、顧客を止めることです。人間向けに作られたページやパズルを通らせると、変更のたびに壊れる脆い自動化になります。
Proof of Actorはエージェントを認識し、署名付きリクエストがあれば、その背後にある鍵とオペレーターを検証できます。するとアプリケーションは、チャレンジよりも優れたことができます。構造化されたAPIを提供する、エージェント向けのフローを用意する、あるいは自動化に合わせたrate limitを適用するのです。AIエージェントに構造化コンテンツを提供する方法のガイドで、その進め方を示しています。
認証済みの本人確認と、許可は同じではありません。有効な署名は、どの鍵が要求に署名したかを示すだけです。そのエージェントがアクションを実行してよいかは、あなたのauthorization decisionです。Proof of Actorは、その2つの問いを分けて保ちます。
AIを使う人も、引き続きあなたのユーザーです
アシスタントを使ってサポートメッセージを書いたり、AIの助けでフォームに入力したりする人は、顧客です。人間向けテストはそれについて何も有益なことを言いません。通過するか、あるいは挙動が通常と違って見えるためにブロックされるかのどちらかです。
Proof of Actorは、それらの人に独自のクラスであるHuman + AIを与えます。これは、支援が申告された場合、または対応する統合を通じて観測できる場合に報告されます。これにより、AIで作成された送信内容を適切なチーム向けにラベル付けし、支援を受けたユーザーが製品内をどう移動するかを調べ、体験を滑らかに保てます。詳しくはAI支援インタラクションの用語集エントリをご覧ください。
不確かなケースは意図的に扱う
一部のトラフィックは、いつでも不明確です。CAPTCHAはそれをどこでも同じように扱います。全員がテストを受けます。
Proof of ActorはUnknownを第一級の結果として返し、既定で人間とも悪意あるものとも扱いません。fallbackはrouteごとに選び、リスクに合わせます。
- 公開ページとドキュメント: allowし、標準体験を維持する。
- サインアップと問い合わせフォーム: allowし、通常の不正対策を適用する。
- アカウント変更: 既存の再認証フローを維持する。
- 影響の大きいアクション: reviewに振り分けるか、必要ならここでチャレンジを適用する。
ここが、チャレンジがまだ役割を持てる場所です。すべての訪問者に課す料金ではなく、機微なrouteにおける1つの意図的なpolicy outcomeとして使うのです。
判断はどこで行われるか
CAPTCHAのウィジェットは、表示されたその瞬間に、置かれたページ上で、そして1回だけ判断します。
Proof of Actorでは、あなたのアプリケーションが判断します。統合がカバーするすべてのrouteで、server middleware、Next.js、edge、承認済みのブラウザ統合、汎用HTTP API、またはあなたのMCP server上でです。policyはactor classとbasisを組み合わせて使います。allow、adapt、challenge、review、rate-limitです。それらは、ほかのビジネスロジックと並んでコードの中にあり、ページを再設計せずに変更できます。
展開の進め方
Proof of Actorは観測モードから始まります。導入しても、ユーザーが見るものは何も変わりません。包括的なチャレンジから離れるための妥当な手順は次のとおりです。
- Observe. 既存のチャレンジはそのままにして、Proof of Actorを追加します。各routeでactor mixとUnknown率を確認します。
- Compare. チャレンジがあるrouteごとに、それが人間のセッション、AI支援ユーザー、verifiedなエージェントのどれに当たっているかを確認します。
- Preview. 証拠が十分な場所ではチャレンジを省き、機微なアクションでのUnknownに対しては残すpolicyを書きます。実際のトラフィックに対する効果をpreviewします。
- Enforce. 文書化したfallbackとロールバックスイッチを用意したうえで、1つのrouteずつpolicyを有効化します。
actor-aware policyを安全に展開する方法のガイドで、各ステップを詳しく説明しています。
CAPTCHAが今でも意味を持つ場面
チャレンジは、いくつかの場面では今でも有用です。機微なアクションに対する判別困難なトラフィックの急増、現在進行中の不正利用下にあるフォーム、あるいはまだほかのシグナルがないrouteです。Proof of Actorは、そのツールを捨てるよう求めません。役立つ場所だけで使うための文脈を与えます。
始める
Proof of Actorはprivate betaです。選定されたfounding developerチームは、合意された利用上限の範囲で、最長12か月の無料アクセスを受けられます。実装チームからの直接サポートも含まれます。early accessに申し込む を選び、今どのrouteにチャレンジをかけているかを教えてください。