Reworkd AI

考え方の核はこうだ。欲しいデータをスキーマに書けば、セレクタを書かされる代わりに基盤がスクレイパーを生成する。マークアップが変わるサイトでは敷居が下がる。CSS セレクタは改版が来た瞬間に壊れるからだ。スクレイピング専任のエンジニアがいないチームにとって、数週間の立ち上げ作業が一枚の記入フォームに置き換わる。

グループは、同じスキーマと同じスクレイピング頻度を共有するソース URL をまとめる。グループ内で各 URL はジョブになり、基盤がそれを段階に割る。まずカテゴリページ、次に一覧ページ、最後に詳細ページである。この構造のおかげで一つの定義がサイト全体と下層ページを覆い、10 件から 1 万件へ広げても作業をやり直さずに済む。

グループは決まった間隔で再実行するようスケジュールでき、ここが Reworkd と一度きりのクロールの分かれ目だった。データパイプラインは新鮮なレコードを必要とする。スケジュールは手動のスクレイピングを定常的なものに変えた。結果は重複除去済みのビューとして返り、グループが再実行されるたびに更新される。

集めたデータは三つの出口から外へ出た。UI からの一括エクスポート、出力をプログラムで取得する API、そしてスクレイピング途中のファイルダウンロード対応である。API があることで、Reworkd はわざわざ訪ねる終点ではなく、既存のパイプラインに組み込める道具になった。出力は重複除去されグループ単位で実体化されるため、利用側は生の重複ではなく整ったビューを受け取る。

サイトによっては内容をログインの奥に隠したり、状態を cookie やローカルストレージに置いたりする。Reworkd は cookie とローカルストレージを読み書きする API エンドポイントを公開しており、素の HTTP クライアントでは絶対に届かないページにスクレイパーが到達できた。アカウントの壁の内側すべてに関わる話で、単純なスクレイピングツールにありがちな穴でもある。

基盤はストリーミングのアーキテクチャで動いており、チームはエージェント型 AI と GenAI でリアルタイム抽出をどう拡張したかを公開で書いていた。共同創業者は、ブロックを避けつつ 1 日あたり数テラバイトを扱うと述べており、それが設計目標だった。想定していた利用者が、一度だけ表を拾う人ではなく本気で量をさばくチームだったことが分かる。