ウェブクローラーはどのように進化してきたのか? Google社員が語るその歴史

[レベル: 中級]

Google 検索リレーションズチームによるポッドキャストシリーズの『Search Off the Record』のエピソード 92 では、Gary Illyes(ゲイリー・イリース)氏と Matin Splitt(マーティン・スプリット)氏が、ウェブクローラーの歴史、設計、そして未来についてディスカッションしました。

Google のクローラーの進化をたどり、帯域幅とホスト負荷に関する考慮事項を強調し、ウェブの混雑が増す中で現れている新たな課題について 2 人は探っています。

初期のウェブクローリング

  • 1994 年の学術クローラ「World-Wide Web Worm(WWWW)」は約 11 万ページを、そのあとに続いた WebCrawler は 200 万ページをインデックス化した。いずれも今日の基準からするとごくわずかな数だが、当時としては巨大だった。
  • Google の前身 BackRub(1996)はシェルスクリプト風の単純なフェッチャを用い、その後専用クローラー「Googlebot」が誕生。
  • 当時のページサイズは平均 約 7 kB で、数十万ページを取得しても帯域負担は小さかった。

単一クローラから共有インフラへ

  • 初期は Google の全プロダクトが Googlebot を使い回し、サイト管理者は目的の判別が困難だった。
  • 2006 年ごろに製品別ユーザーエージェント(例:AdsBot)を導入しつつ、ロボット排除ルール (robots.txt) とホスト負荷制御を統一したバックエンド基盤に統合。
  • この共通プラットフォームにより、エンジニアはカスタムユーザーエージェント文字列を指定しつつ、共通の礼儀正しさのルールを継承できるため、メンテナンスの複雑さが軽減され、「不正な」独自開発クローラーの発生を防げる。

礼儀正しさ、帯域幅、クロールバジェット

  • 責任あるクローラーは Robots Exclusion Protocol(ロボット排除プロトコル)を尊重し、ホストが負荷を示した場合には動的にクロール速度を調整することで、偶発的な DoS(サービス拒否)攻撃を回避する。
  • サイトのクロールバジェットは、そのサイズと構成に依存する。単一サイトの場合、URL 数が約 100 万未満であれば多くの場合快適な状態を保てる。
  • Google は最近、リクエストごとのオーバーヘッドを 7 バイト削減したが、新しい AI 機能によって時には 8 バイトが追加されることもあり、絶え間ない最適化が行われている。

ユーザー主導フェッチ vs. 自動クローラ

  • Search Console の確認のようなタスクは、ユーザーに代わって即座に取得処理を行い、多くの場合 robots.txt やキューの遅延を迂回する。
  • 対照的に、ライブテストは、より高い優先度ではあるものの、依然として通常のクローラーキューを使用する。
  • これらのモードを区別することで、レイテンシ(遅延)要件とサイト管理者からの指示との尊重とのバランスを取っている。

今後の展望

  • クローラーや AI エージェント、データセット収集プログラムを誰もが立ち上げられるようになり、ウェブは増大する混雑に直面している。
  • 現在の HTTP/2、将来の HTTP/3 のようなプロトコルの進歩は多重化を改善するが、インデックス作成と配信という中核的な処理コストの問題を解決するものではない。
  • Common Crawl のようなコミュニティプロジェクトは共有データセットを提供している。現状のように、多くの利用者が完全に独立したクロールを実行する代わりに、こうした中央集権化されたアーカイブに依存するようになれば、重複トラフィックを削減できる可能性がある。

主要ポイントまとめ

  • スケールの拡大:1990 年代の数十万ページから、今日では数十億ページへとクロール規模が拡大。高度なインフラストラクチャが必要になった。
  • 統合基盤:Google は、複数のプロダクトフェッチャーを 1 つのクローラープラットフォームに統合し、robots.txtの遵守と礼儀正しさのルールを統一的に施行している。
  • 帯域幅最適化:数バイトの削減でもグローバル規模では大きな効果、ただしインデックス処理が最大コスト。
  • デュアル取得モード:ユーザー起因のフェッチは速度を優先し、robots.txt を無視することがある。一方、自動化されたクローラーは URL をキューに入れ、サイトの制限を厳密に遵守する。
  • 今後の課題:より多くのクローラーやAIエージェントの登場は継続的な負荷を意味し、共有データセットとプロトコルの効率性が不可欠。

最近は、AI Overview/AI Mode 関連の記事が続いていて過食気味でした。
たまには、こういった原点に帰るトピックも箸休めに良いのではないでしょうか。

ポッドキャスト全体はこちらから聴けます。