定義
Unknown の分類は、アクター・インテリジェンス・システムが、インタラクションについて利用可能な証拠では信頼できる判定を下せないときに返す結果です。つまり、観測できた内容だけでは、これが人間なのか、AI を使う人間なのか、Agent なのかは判断できない、ということを正確に示します。
Unknown は、Proof of Actor における 4 つのクラスの 1 つで、Human、Human + AI、Agent と並びます。これは第一級の結果であり、エラー状態でも、丁寧な言い換えで「たぶん bot です」と伝えているわけでもありません。AI トラフィックの分類において Unknown が有効な結果である理由については、why Unknown is a valid result when classifying AI traffic の記事で詳しく説明しています。
Unknown が価値を持つ理由
常に答えを 1 つ選ばなければならない分類システムは、自信のある推測に陥ります。その推測はデータのように見え、ダッシュボードやポリシーに流れ込み、静かに害を生みます。正規の顧客が確認を求められたり、機械的なクライアントが重要なルートで人間として扱われたりします。
代わりに Unknown を報告すると、チームは 3 つのものを得られます。
- 正直なカバレッジ。 Unknown の割合を見ることで、統合がどこまで可視化できていて、どこが見えていないかが分かります。
- より安全なポリシー。 ポリシーは、隠れた推測を継承するのではなく、各ルートで Unknown が何を意味するかを明確に定義できます。
- 改善への道筋。 あるルートで Unknown の割合が高いなら、その箇所にブラウザ統合や署名付き Agent リクエストのサポートなど、より良いシグナル源を追加できます。
Unknown の一般的な原因
- そのルートでサポート対象の統合が動いていない。たとえばブラウザ・コレクターが存在しない。
- クライアントが JavaScript を実行せず、身元に関する証拠を送っていない。
- 観測されたインタラクションのシグナルが少なすぎる。たとえばセッションが非常に短い。
- リクエストに署名がなく、クライアントの説明も一般的すぎるか欠落している。
- 存在する証拠同士が矛盾しており、どの要素も判断するには十分に強くない。
アプリケーションは Unknown をどう扱うべきか
Unknown は、アプリケーションの所有者がルートごとに選ぶ明示的なフォールバックに対応させるべきです。
- 公開されている低リスクのページ: 追加の摩擦なしに allow する。
- 読み取り専用の APIs: 標準的な rate limit 付きで allow する。
- アカウント変更など影響の大きい操作: 再認証など、アプリケーション既存のチェックを維持し、Unknown の結果そのものだけで何かを決めない。
同じ考え方は、タイムアウトやテレメトリー不足にも当てはまります。あるルートを fails open or fails closed のどちらにするかは、偶然ではなく、事前に下す意図的な判断です。
よくある誤解
"Unknown は疑わしいという意味です。" いいえ。証拠が不十分だという意味です。ごく普通の訪問者でも Unknown の結果になることはあります。
"Unknown は既定で Human にすべきです。" それは違います。Unknown を Human に変換すると、ギャップが見えなくなり、Human レベルの信頼を自動化に与えてしまう可能性があります。
"優れたシステムには Unknown がありません。" Unknown がないシステムは、推測しているシステムです。見える形で説明された Unknown の割合は、誠実な分類器であることの証拠です。
Proof of Actor における Unknown
Proof of Actor は、evidence basis が判定を支えない場合に Unknown を返し、それを Human に変換することはなく、分析でも Unknown の割合を可視化したままにします。チームは、いかなるポリシーも有効化する前に、observation mode の間に各ルートのフォールバックを定義します。完全なモデルについては Detection & Limitations を、または apply for early access をご覧ください。