アプリで Unknown トラフィックをどう扱うか

Unknown はエラーですか、それとも結果ですか？

インタラクションを Human, Human + AI, Agent, Unknown として分類し始めると、Unknown の件数はしばしば想定より多くなります。Unknown を隠すための抜け穴のように扱いたくなることがあります。たとえば Unknown を Human にまとめてしまう、あるいは疑わしいものとして扱う、といったやり方です。どちらも問題を生みます。

Unknown は、利用可能な証拠だけでは信頼できる判定を支えられないことを意味します。JavaScript を実行しないクライアントからの request、signal を収集しない endpoint への呼び出し、1 ページで終了した session などは、いずれも完全に正当でありえますが、誰が何をしていたのかを断定できるだけの情報は与えません。

Unknown を正直に報告することが、他のクラスの信頼性を保ちます。システムが Unknown を一切返さないなら、すべての Human 結果には一部推測が混じっていることになり、その部分を見分けられません。AI traffic を分類する際に Unknown が妥当な結果である理由については、why Unknown is a valid result when classifying AI traffic の記事で詳しく説明しています。

このガイドでは、実運用で Unknown をどう扱うかを説明します。ルートごとの明示的なフォールバック、他のクラスへ混ざらないようにするルール、監視の方法、そして重要な箇所で減らす方法を取り上げます。

Step 1: Human をデフォルトにしない

最もよくある間違いは、automation signal が見つからなかったときに Human を返す classification 関数です。一見もっともらしいですが、誤りです。bot signal がないことは、human signal があることを意味しません。

// Wrong: silence becomes Human
function classifyWrong(e: Evidence) {
  if (e.signatureValid) return { actor: "agent", basis: "verified" };
  if (e.declaredAgent) return { actor: "agent", basis: "declared" };
  return { actor: "human", basis: "inferred" };
}

// Right: Human requires positive evidence, otherwise Unknown
function classify(e: Evidence) {
  if (e.signatureValid) return { actor: "agent", basis: "verified" };
  if (e.declaredAgent) return { actor: "agent", basis: "declared" };
  if (e.interactiveSession) return { actor: "human", basis: "inferred" };
  return { actor: "unknown", basis: "unknown" };
}

結果を生成するすべての場所で同じルールを適用してください。timeout、error、古い cache entry、欠落した telemetry は、いずれも Unknown を返すべきです。これらの経路それぞれに test を書いておけば、挙動が静かに後退することを防げます。下の例では、組み込みの Node.js test runner を使っています。

import { test } from "node:test";
import assert from "node:assert/strict";

test("missing evidence is unknown, not human", () => {
  const r = classify({ signatureValid: false, declaredAgent: false, interactiveSession: false });
  assert.equal(r.actor, "unknown");
});

Step 2: 各 route に明示的な fallback を与える

Unknown には定義された behavior が必要であり、適切な behavior は route によって異なります。ルートごとに決め、文書化し、configuration に保持してください。これらの fallback がより広い policy model にどう組み込まれるかは、designing app-level policies for humans and AI agents を参照してください。

パターンは単純です。低リスクの route では、Unknown は通常の traffic と同じように扱います。高リスクの route では、Unknown にその route すでに持っている保護を適用します。どちらの場合も、未分類だが正当な user に対して、actor result が不利に働くことはありません。

type Fallback = "allow" | "standard_limit" | "existing_checks" | "review";

const unknownFallback: Record<string, Fallback> = {
  "GET /docs/*": "allow",
  "GET /api/catalog": "standard_limit",
  "POST /signup": "existing_checks",
  "POST /account/password": "existing_checks",
  "POST /exports": "review",
};

Step 3: timeout と error は同じように扱う

Actor evaluation は request path 上にあるため、厳密な time budget が必要です。budget を超えたら Unknown を返し、route fallback を適用してください。評価が遅かったという理由で request を block してはいけません。

async function withBudget<T>(work: Promise<T>, ms: number, onTimeout: T): Promise<T> {
  let timer: NodeJS.Timeout;
  const timeout = new Promise<T>((resolve) => {
    timer = setTimeout(() => resolve(onTimeout), ms);
  });
  try {
    return await Promise.race([work, timeout]);
  } finally {
    clearTimeout(timer!);
  }
}

const result = await withBudget(evaluateActor(req), 150, { actor: "unknown", basis: "unknown" });

結果が Unknown になった理由を記録してください。証拠がないのか、timeout なのか、evaluation error なのか、古い証拠なのか。そうした理由は、何を修正すべきかを示します。

Step 4: Unknown を疑わしいものとして扱わない

Unknown は risk score ではありません。多くの正当な client は、いくつかの route では常に Unknown になります。たとえば、command-line tools、署名のない server-side integration、accessibility tools、privacy-focused browser、単純な feed reader などです。大規模な AI operator でさえ、現時点では fetcher を user agent と公開された IP range で識別することがほとんどです。たとえば OpenAI's crawler documentation では、2026年11月時点で、各 bot について user agent string と公開された IP address file が示されています。

疑わしい behavior に対応したいなら、request rate、login failure pattern、abuse report など、説明可能な behavior に基づいてください。その behavior には独自の証拠を持たせてください。actor class とそのロジックは分けて、どちらも歪めないようにします。

Step 5: Unknown rate はどう監視しますか？

Unknown rate は、Unknown に分類された interaction の割合です。route ごと、integration context ごと、時間の経過に沿って追跡してください。これは最も有用な health metric の 1 つです。

type Row = { route: string; actor: string };

export function unknownRate(rows: Row[]) {
  const byRoute = new Map<string, { total: number; unknown: number }>();
  for (const r of rows) {
    const s = byRoute.get(r.route) ?? { total: 0, unknown: 0 };
    s.total += 1;
    if (r.actor === "unknown") s.unknown += 1;
    byRoute.set(r.route, s);
  }
  return [...byRoute].map(([route, s]) => ({ route, rate: s.unknown / s.total, total: s.total }));
}

数字が示すこと:

• ある route で高く安定している 場合は、そこに signal が不足していることが多いです。browser integration を一度も読み込まない page や、署名付き request を一度も受け取らない API は、ほぼ Unknown のままです。
• 急な上昇 は、stack で何かが変わったことを示すことがよくあります。たとえば header を落とす release、signature header を削除する CDN rule、app の declaration を送らなくなった frontend change などです。
• 急な低下 も確認する価値があります。Unknown が下がって Human が増えたなら、fallback が静かに変わったのではなく、新しい証拠が入ったことを確認してください。

絶対値ではなく、急激な変化に alert を出してください。アプリケーションごとに正常値は異なります。

Step 6: 重要な箇所で Unknown をどう減らしますか？

Unknown をゼロにする必要はありません。意思決定が重要な route で十分な証拠があればよいのです。影響の大きい順に進めてください。

1. 影響の大きい route から先に証拠を追加する。 アカウント変更の多くが Unknown なら、browser integration か server-side check が最も効果を発揮する場所です。
2. 自動化された client に自己識別を促す。 API のための documentation を公開し、agent が HTTP Message Signatures と IETF の Web Bot Auth conventions を使って request を署名する方法を説明してください。また、検証済みの client には、より高い limit や structured response のような、より良い experience を与えます。verify できる client は、そうするようになります。
3. アプリケーション自身の知識を使う。 user が組み込み assistant を使っているなら、それを declaration として記録してください。アプリは network より多くを知っていることがよくあります。
4. 基盤を修正する。 proxy が依存している header を転送しているか、evaluation に完了するのに十分な time budget があるかを確認してください。

Unknown から traffic を動かす signal を実務的に見るには、how to tell if website traffic comes from AI agents を読んでください。

Step 7: ダッシュボードでは Unknown を正直に表示する

Unknown を他の class と同じ visual weight で独立した series として表示してください。"other" bucket に隠さず、alert のような色にしないでください。stakeholder が Unknown の割合の大きさを見たときの正しい反応は、「どこで証拠を増やす必要があるか」であって、「どこに bot がいるか」ではありません。

Step 8: 仮定ではなく結果で Unknown をレビューする

数週間ごとに、最も重要な route から Unknown interaction をサンプルし、実際に何が起きたかを確認してください。session は購入を完了したのか、project を作成したのか、3 本の記事を読んだのか、それとも login で何度も失敗したのか。Outcome は、早まった label を押し付けることなく、その bucket にどのような traffic が入っているかを教えてくれます。

見つかったものは、実用上の 3 つの category にまとめてください。

1. 正当で低リスク。 Feed reader、link preview、monitoring tool、そして privacy 設定を使う人たちです。route fallback はそのままにします。
2. 自己識別できる正当な automation。 構造化された path や request 署名を使えるならそうしたい integration や agent です。guidance を公開し、可能な範囲で働きかけてください。
3. 独自の control が必要な behavior。 Credential stuffing や scraping の pattern で、どちらも OWASP Automated Threats to Web Applications プロジェクトに整理されています。これらには、login failure rate など独自の証拠を持つ behavior-based control で対処し、actor class とは分けてください。

この review により、fallback が実際の traffic に基づいたものになり、次にどこへ証拠を追加すべきかが明確になります。

よくある質問

Unknown は rate limit の対象に含めるべきですか？ 標準の limit を使ってください。verified agent に対して class ごとに rate limiting を行うのは問題ありません。verified agent はより高い limit を得られるからです。ただし Unknown には、罰則的な limit ではなく通常の limit を適用すべきです。

Unknown ユーザーに challenge を出せますか？ その状況ですでに route が全員に challenge を出している場合に限ります。結果が Unknown だからという理由だけで challenge を追加すると、signal が少ない client を使う正当な user に不利益を与えます。

標準が成熟すれば Unknown は減りますか？ 署名付き request を送る automated client が増えるにつれて、より多くの agent traffic は Unknown または declared から verified に移ります。監視により、その変化を route ごとに確認できます。

Proof of Actor がどこに当てはまるか

Proof of Actor は、Unknown を reason 付きの第一級の結果として報告し、Human に変換しません。アプリケーションは各 route の fallback を選び、analytics は coverage の終点を示すので、重要な箇所に証拠を追加できます。

本番アプリケーションでこれを当社チームと一緒に設定するには、apply for early access してください。証拠が正確に何を立証できるのかを理解するには、Detection & Limitations を読んでください。

Sources

• RFC 9421: HTTP Message Signatures: automated client が request に署名するために使える standard
• draft-ietf-webbotauth-httpsig-protocol: 署名付き automated traffic のための IETF Web Bot Auth draft (2026年11月時点で作業中)
• OpenAI: Overview of OpenAI Crawlers: OpenAI の bot の user agent string と公開された IP address file
• OWASP Automated Threats to Web Applications: credential stuffing や scraping のような automated threat の taxonomy
• Node.js test runner: 例で使われている node:test module