3 ポイント 投稿者 kingtw 4 시간 전 | まだコメントはありません。 | WhatsAppで共有

ユーザーの実際のブラウザセッションでデータを収集しつつ、何をどう収集するかはサーバーがランタイムで動的に発行する self-hosted 収集システムです。サーバーがクライアント(ブラウザ)をリモート制御するCommand-Execute-Reportパターン。

クローラーを新しく書くたびに直面する3つの問題 — ターゲットのバックエンド負荷・ブロック、ログインの壁、収集ロジックが変わるたびのクライアント再配布 — を設計で解決します。

  • Zero-Footprint: ターゲットサーバーへ直接リクエストせず、すでにログイン済みのユーザーブラウザが代わりに収集 → ログインの壁の内側にも人間と同じようにアクセスでき、バックエンド負荷やブロックを回避。
  • サーバー動的制御: ブックマークレットは一度登録すれば永続的に不変。収集ルール(セレクター・アクション・抽出)はサーバーが型付きコマンドとして発行 → ロジック変更時のクライアント再配布は0。単一ソースの Pydantic から TS 型を自動生成。
  • クリックでレシピ作成: WebUI で要素をクリックするとセレクターを自動生成し、アクションシーケンス(click・drag・scroll・swipe)→ extract レシピを保存。script の eval は禁止(ホワイトリスト方式)。
  • 無損失ロード: write-ahead(同期コミット後に 202)+ 冪等性 + 再起動時の自動復旧。
  • MCP エージェント制御: ライブパイプを MCP ツールとして公開(host allowlist・rate-limit・op TTL ガード)。ただし、ボット回避・大量スクレイピングは目的外
  • secure-by-default: 管理認証はデフォルトで ON(Jupyter 方式の自動トークン)、サーバー応答の eval(script)・外部ビーコン(beacon)実行の境界、フィンガープリンティング不使用。
  • 無コスト・移植性: SQLite + インメモリキュー + 単一 FastAPI。外部有料サービスは0。uv で OS を問わず再現可能。MIT。

公開サイトの収集では、ブラウザの Private Network Access 制約により公開 URL が必要ですが、ENABLE_TUNNEL=1 で cloudflared の一時トンネルを立ち上げて回避します(実測: 実際のニュースサイト収集に成功)。

まだコメントはありません。

まだコメントはありません。