Bytespider

Bytespiderとは何か

Bytespiderは、ByteDanceがAI訓練データ収集のために走らせる学習・収集系クローラーです。分類上は「AI Data Scraper（＝AIモデルの訓練用データセットに含めるためにWebコンテンツをダウンロードするボット）」にあたります。運営者（ByteDance）が、どのサイトを・どれくらいの頻度で・どこまで深く巡回するかを決めるため、挙動は予測しにくく、収集パス（＝一括収集の実行期間）が始まると大量にページを取得し、終わるとぱたりと止む、という波のある動き方をします。検索用クローラーよりも1回の来訪で取得するページ数がはるかに多いのが典型です。

公式のUA文字列は `Mozilla/5.0 (compatible; Bytespider; [email protected]) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.0.0 Safari/537.36` で、連絡先メールを含む形で名乗ります。サイト運営者はこのUA名を手がかりに検知し、robots.txtで拒否できます。第三者の観測データ（Webボット来訪を横断計測するサービス）によれば、世界の上位サイトのうち一定割合（同観測では約17%）がrobots.txtでBytespiderをブロックしており、AIデータ収集ボットの中でも警戒されやすい対象であることがうかがえます。

UA文字列の読み方

BytespiderのUA文字列で判別の軸になるのは、括弧内の「Bytespider」という語です。特徴的なのは、その直後に連絡先メール `[email protected]` を含めて名乗る点で、これはByteDance系であることの有力な手がかりになります。末尾の `Chrome/70.0.0.0 Safari/537.36` はブラウザ風の互換表記（＝古いブラウザ判定を通すための慣習的な名乗り）で、実際のChromeバージョンを意味しません。ここに惑わされず、読むべきは「Bytespider」の語と、併記される `[email protected]` です。ログ集計では「Bytespider」を部分一致で拾うのが基本ですが、UAは詐称できるため、後述のIP照合・逆引きDNSと組み合わせて本物かを確かめます。

なぜ重要か（量と可視化の切り分け）

Bytespiderが重要なのは、AI検索で「引用された成果」としてではなく、「サーバー負荷とログ解釈を歪めるノイズ源」としてです。アクセス量が突出しているため、AIボットの来訪を素朴に合計すると、Bytespiderの数字に全体が引きずられます。ここで「AIからのアクセスが増えた＝AI検索で評価が上がった」と読むのは典型的な誤りです。Bytespiderは訓練用の収集であって、回答での引用可視化とは無関係だからです。当ラボが学習系（訓練収集）と回答系（出典掲載）を厳密に分けて計測しているのは、まさにこの取り違えを防ぐためです。

なぜBytespiderの量がこれほど突出するのか、背景を押さえておくと解釈を誤りません。ByteDanceは、対話型AI「Doubao（ドウバオ／豆包）」をはじめとする自社AI群のために、できるだけ広く新しい公開Webを訓練データ候補として集めようとします。訓練用の収集は、検索インデックスの更新のように「差分だけ軽く見に来る」のではなく、対象を面で一気に取り込む性格が強いため、1回の収集パスあたりの取得ページ数が桁違いに大きくなりがちです。さらに、収集対象や頻度をByteDance側が随時決めるため、外から見ると予測しづらい波状のアクセスになります。この「面での大量取得×不規則なスケジュール」こそがBytespiderの数字を膨らませる正体であり、それ自体は自社コンテンツの評価とは無関係だ、と理解しておくことが重要です。

仕組み（学習系ゆえの特徴）

具体例・データ

• 公式UA：`Mozilla/5.0 (compatible; Bytespider; [email protected]) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.0.0 Safari/537.36`（連絡先メールを内包）。
• robots.txtでの拒否例：`User-agent: Bytespider` の行に続けて `Disallow: /` を書くとサイト全体を拒否できます（一部だけなら `/` を対象パスに変えます）。
• 観測傾向：Known Agents（旧Dark Visitors）の2026年7月31日時点の集計では、世界の上位1,000サイトのうち17%がrobots.txtでBytespiderをブロックしています。
• アクセス量：Cloudflareが2024年7月3日に公開した集計では、同社ネットワーク上で観測されたAIボットのうちBytespiderがリクエスト数で最多で、アクセスされたサイトの割合も40.40%と最も広い結果でした。
• 波のある巡回：収集パス中は大量アクセス、終了後は静止、という不規則なスケジュールになりやすいです。
• 逆引きDNSでの本物判定：疑わしいアクセスは、アクセス元IPを逆引きしてByteDance系の正規ホスト名に解決されるか、順引き逆引きが往復一致するか（forward-confirmed reverse DNS）を確かめます。UA名だけで遮断すると、正規ブラウザを巻き込む事故や、逆に詐称を見逃す取りこぼしが起きやすいです。
• 一部だけ拒否する例：`User-agent: Bytespider` の行に `Disallow: /` で全体拒否、`Disallow: /api/` のようにパス指定で部分拒否ができます。ただしrobots.txtは強制力のない要請なので、これだけを最終防衛線にしません。

よくある誤解・注意点

実務での扱い方

1. 方針を決める：訓練データへの利用を「無断学習は拒否」で止めるか、負荷が許容範囲なら放置するかを、自社の考えとサーバー負荷から判断します。
2. robots.txtで拒否する：止めるなら `User-agent: Bytespider` に `Disallow: /` を明記します。ただしrobots.txtは強制力のない要請なので、これだけに頼りません。
3. IPで裏を取る：大量アクセスや不審挙動は、UA名でなくアクセス元IPを照合し、なりすましを見極めます。
4. 確実に止めたい場合：robots.txtに加え、ファイアウォールやWAF（＝Webアプリを守る防御層）でIP単位・レート単位の遮断を併用します。
5. ログ集計を分ける：Bytespiderの量を、回答・検索系ボット（出典掲載に関わるもの）と混ぜて集計しません。「学習系」と「回答系」を必ず分けて可視化します。

当ラボのサーバーログ観測での見え方

当ラボの実観測では、AIボットの来訪をUAごとに数えると、Bytespiderが最大勢力になりやすいのが実情でした。しかもその現れ方は一定ではなく、収集パス（＝一括収集の実行期間）が始まると短期間に大量のページ取得が集中し、終わるとぱたりと止む「波状」のパターンを描きます。この山を素朴に月次の合計へ足し込むと、月によってAIアクセス総数が乱高下し、あたかも「AI検索での評価が上下している」ように見えてしまいます。これは典型的な読み違いです。Bytespiderは学習・収集系であり、山が来た月に回答での引用が増えたわけではありません。したがって当ラボでは、(1) Bytespiderを含む学習・収集系を独立した列で集計し、(2) 回答・検索系（出典掲載に関わるボット）とは別のダッシュボードで並べ、(3) 実際の回答出典モニタリングを「成果指標」として最上位に置く、という三層の切り分けで数字を読んでいます。ログの量は負荷管理の指標にはなっても、AI検索での可視化の成果指標にはなりません。

他の主要ボットとの比較

よくある質問（FAQ）