ボット検知

TRACIOのボット検知は、ブラウザエージェントによるクライアントサイドの収集と サーバーサイドの分析という二層アーキテクチャを用いて、自動化ブラウザ、 ヘッドレスツール、スクリプト化された攻撃を識別します。主要な自動化フレームワーク、 ヘッドレスブラウザ、AIブラウジングエージェント、アンチディテクトブラウザを ほぼゼロの誤検知でカバーし、同時に正規の検索エンジンクローラーを自動的に 許可リストへ登録します。

TRACIOが検知するもの

• 自動化フレームワーク — Selenium、Puppeteer、Playwright、Cypress、PhantomJS、NightmareJSなどのツール。
• ヘッドレスブラウザ — ヘッドレスChromeおよび関連ランタイム。
• AIブラウジングエージェント — Browser-Use、Claude Computer Use、Fellou、Genspark、Skyvernなどのエージェントランタイム。
• アンチディテクトブラウザ — フィンガープリントの偽装やローテーションを目的とするブラウザビルド。
• 検証済みクローラー — Googlebot、Bingbot、Applebot、GPTBot、Yandex、DuckDuckGoなど。偽装されたuser-agentが通過しないよう検証されます。

判定が導き出される仕組み

ブラウザエージェントは幅広いチェックを実行し、その結果を報告します。サーバー側では、 それらの結果が重み付けされてボットスコアとなり、スコアが判定にマッピングされます。 ごく少数の明白な指標はそれ単独で決定的であり、他の結果にかかわらず bot 判定を 強制します。

どのチェックが実行され、どのように重み付けされ、しきい値がどこに置かれているかは、 どのプランでも公開されません。 それらを文書化することは、保護を通過するために何を 変えればよいかをボット運営者に正確に教えることになります。代わりに提供されるのは、 判定、ボットタイプのラベル、そしてBusiness以上では判断の背後にある観測のクラスを 示す理由コードです。

結果フォーマット

すべての識別にはボット判定が伴います。webhookペイロードでは bot.result として、クライアントSDKでは result.bot として届きます。

判定の値

これは、ダッシュボードとwebhookペイロード全体で使用されるビジネス上の decision.action フィールド（real、fake、suspicious）にマッピングされます。

判定には bot.score が伴います。webhookペイロードのバージョン2では 0..100 の 小数であり、そのアクセスについてダッシュボードが表示するのと同じ数値です。 （凍結されたバージョン1のスキーマでは 0..1 の割合です。Webhooksを 参照してください。）

ボットタイプ

bot.type は結果が bot の場合に存在します。認識されたボットまたはランタイムの 名前か、具体的なチェック名を挙げると検知器の内部構造が明らかになってしまう場合の ファミリーのいずれかです:

この一覧は意図的に閉じられています: 明日検知器に追加されたチェックは、内部名を 漏らすのではなく other として現れます。bot.type は分岐に使うラベルとして扱い、 検証のための網羅的なenumとしては扱わないでください — 名前付きのランタイムは今後も 追加されていきます。

理由コード（Business以上）

BusinessおよびEnterpriseプランでは、webhookペイロードに reasons 配列が含まれます — 最大8件、重要度順にソートされます。コードは観測のクラスを示すもので、その背後にある チェックを示すことは決してありません:

severity は high、medium、low のいずれかであり、そのアクセスにおいて このクラスが判定に占める割合であって、コードに固定された性質ではありません。 同じコードがあるアクセスでは high、別のアクセスでは low として届くことがあるため、 定数としてキャッシュしないでください。

privacy_hardening はとりわけ注意が必要です: 回避行為と同じくらい、ごく普通の プライバシー意識の高い訪問者に対しても発火します。単独で対処せず、他の要素と 併せて評価してください。

virtual_environment はエミュレータ検知から生じます。Webには「ハイパーバイザー上で 動作している」という独立した判定はありません。ブラウザから見える手がかり——汎用の ソフトウェアレンダラー、異常に少ないコア数——は、GPUドライバのない普通のマシンや リモートデスクトップのセッションでも同じくらい頻繁に現れるため、お客様が疑わざるを えないような判定には変換していません。

プランごとの提供状況

アンチディテクトのスコアリングは現在も較正中です。 bot.antidetectScore は、 お客様が観察してご自身のポリシーを調整できるように報告されます。単独でブロックする 理由としてではなく、リスク判断への入力として扱ってください。

モバイル専用のチェックはWebでは有効ではありません。 root化、脱獄、 クローン／デュアルアプリ、Fridaの検知は、ブラウザでは収集できないネイティブの シグナルに依存します。TRACIOが提供するのはブラウザSDKのみですので、 Webで完全に機能する自動化、ヘッドレス、AIエージェント、アンチディテクト、エミュレータ、 行動の各判定をご利用ください。

検証済みクローラー

既知の良性ボットはuser-agentによって認識され、その後接続元IPに対して検証されます — IPの逆引きDNS、得られたホスト名が運営者のドメインに属するかの確認、そしてそれが同じIPに 解決されることを確かめる正引きです。これはクローラー運営者自身が公開している検証手順です。

検証済みクローラーは human として解決されます。Googlebotを名乗りながら、そのIPが 明らかに別の主体に属しているリクエストはボットとして分類されます — 逆引きが単に 見つからなかった、あるいはタイムアウトしただけでは、偽装の証拠とは見なされません。

行動分析

インタラクションのダイナミクス（ポインターの動き、キーボードのリズム、スクロール）は、 どの人間であるかではなく、人間がその場にいるかどうかの証拠として判定に 反映されます。Business以上では、その集約結果がwebhookの behavior ブロックで届きます:

{
  "behavior": {
    "score": 87,
    "verdict": "human",
    "confidence": 0.92
  }
}

score は 0..100（高いほど人間らしい）、verdict は human、uncertain、bot の いずれか、confidence（0..1）は判定がどれだけの証拠に基づいているかを示します — ポインターの動きが2回しかない短い訪問は、判定が決定的に見えてもここでは低い値に なります。

このブロックは、そのアクセスで実際に行動スコアリングが実行された場合にのみ 存在します。ブロックがないことは「データなし」を意味するのであって、 「疑わしい点がない」ことを意味することは決してありません — 不在を良好なシグナルとして 読まないでください。

統合例

ログイン時のボットのブロック（クライアント）

クライアントSDKは、便利なブール値 result.bot.detected と、0..100 スケールの confidence を公開します:

const result = await tracio.getResult()

if (result.bot.detected) {
  console.warn(`Bot detected (confidence ${result.bot.confidence})`)
  showCaptcha()
  return
}

await login(credentials)

サーバーサイドでのボットチェック

サーバー側では、webhookの配信に基づいて対処します。ボット判定は bot オブジェクト — bot.result と bot.type にあります:

// `event` is the webhook delivery body (/docs/webhooks)
app.post("/webhook/tracio", async (req, res) => {
  const event = req.body

  if (event.bot?.result === "bot") {
    await db.blockedRequests.insert({
      visitorId: event.visitorId,
      botType: event.bot.type,
      ip: event.ip,
      timestamp: new Date(),
    })
  }

  res.status(200).send("OK")
})

ゼロ値と空の値はペイロードから省略されるため、bot.type はスキーマで必須とするのでは なく、防御的に読み取ってください。

誤検知への対処

TRACIOのボット検知はほぼゼロの誤検知を目指して設計されていますが、エッジケースは 存在します:

誤検知が見られる場合は、bot.type（およびBusiness以上では reasons）を確認して どのクラスの観測が発火したかを把握し、ポリシーを調整してください。よくある原因は トラブルシューティングを参照してください。