1万件のURLを一度にスクレイピングすることより難しいのは、得られた1万件の結果をエージェントが安心して使えるようにすることです。Olostepの本当の価値は、大量リクエストそのものではなく、URLリストを識別・構造化・検証・再処理できるデータパイプラインへ変えることにあります。
1万URLはスクレイピング作業ではなく、データ契約の問題です
Olostepは、単一URLのスクレイピング、サイトクロール、URLマップ、大量バッチ、検索、回答を1つのAPI製品群として提供しています。Product Huntの紹介でも、大規模なURLリストを本番データパイプラインとして処理し、結果をMarkdown・HTML・JSONなどに整理する用途を前面に出しています。 すでに収集対象のURLリストがあるなら、この中で /v1/batches が適切な出発点です。
1つのバッチには最大1万URLを入れられ、公式ドキュメントでは処理時間をバッチサイズにかかわらずおよそ5〜8分と案内しています。ただし、新規アカウントは当初バッチあたり100件に制限される場合があるため、実際の1万件ジョブの前にアカウント上限を確認する必要があります。50件未満なら、バッチより単一スクレイピングリクエストを並列送信するほうが速いという推奨もあります。 この時間は製品ドキュメント上の目安であり、対象サイトやネットワーク条件を反映したSLAとして受け取るべきではありません。
最初から1万件を投入しないでください。
同じパーサーとフィールド契約で20件、100件、1,000件を順に通してから拡大するほうが安全です。ログインページ、在庫切れ商品、地域別表示、JavaScriptの遅延読み込みなど、小さなサンプルで漏れた種類は、大量実行では数百件の静かなエラーになり得ます。
最初に決めるべきなのはURLではなく、結果の1行に対する契約です。たとえば商品監視なら、source_url、canonical_url、title、price、currency、availability、observed_atのように、エージェントが実際に判断に使うフィールドを先に選んでください。JSON Schemaでは、propertiesに書いただけでフィールドが自動的に必須になるわけではないため、requiredを別途指定する必要があります。想定外のキーを防ぐには、additionalProperties: falseも明示できます。
Olostepのバッチは、送信・完了・取得の3段階に分かれます
バッチリクエストにはitems配列を含め、各項目にurlとcustom_idを付与します。公式例では、URLのSHA-256ハッシュの一部からcustom_idを作る方法が示されています。 実務では、大文字小文字を保持すべきパスがないか確認してから、トラッキングパラメータの削除、フラグメントの削除、ホストの正規化といったルールを適用し、その結果からIDを作成してください。これにより、同じページが異なるIDで重複保存されることを減らせます。
| パイプライン状態 | 必ず保存する値 | 次の判断 |
|---|---|---|
| 送信前 | custom_id、元URL、正規化URL、スキーマバージョン | 重複と収集許可範囲を確認 |
| バッチ作成 | batch_id、送信時刻、対象件数 | Webhook受信または状態照会 |
| 項目完了 | custom_id、retrieve_id、処理状態 | コンテンツを取得 |
| 検証完了 | 検証結果、エラーコード、原文の保存場所 | ロードまたは再処理キューへ移動 |
構造化JSONが目的なら、バッチ作成時に対象サイトに合ったパーサーIDを渡す必要があります。一方、原文を後から別ロジックで構造化する予定なら、MarkdownまたはHTMLを取得できます。パーサーが画面構造をフィールドへ変換し、皆さんのJSON Schema検証器がその結果が内部契約を守っているか確認するように役割を分けるとよいでしょう。パース成功とデータ品質通過を同じ状態として扱わないことが重要です。
バッチが終わったら、GET /v1/batches/{batch_id}/itemsで項目一覧を取得します。一覧APIはcompletedとfailedの状態フィルターをサポートし、結果が多い場合は前の応答のcursorを次のリクエストに渡してページを巡回します。ドキュメントでは一度に10〜50件取得することを推奨しています。 最初の50件だけを受け取って1万件が完了したと表示するミスを防ぐには、カーソルがなくなるまで繰り返す必要があります。
各完了項目のretrieve_idを/v1/retrieveに渡すと、必要な形式だけを取得できます。応答のjson_contentは文字列なので、もう一度JSONのパースとスキーマ検証を行う必要があります。 公式のバッチ例では、ホストされたコンテンツの保持期間を7日と案内しているため、リンクだけを保存せず、ジョブ完了直後に必要な原文と構造化結果を自分たちのストレージへ移すほうが安全です。
エージェントの前には、もう1つ検証・再処理ゲートが必要です
エージェントが読むデータセットには成功行だけを入れ、収集失敗と品質失敗は別々のキューに分けてください。HTTPエラーやタイムアウトは収集失敗であり、価格が文字列なのに通貨がない、あるいはタイトルが空といった場合は品質失敗です。前者は指数バックオフで再リクエストできますが、後者はパーサーやスキーマを直さずに再試行しても、同じ結果が繰り返される可能性が高いです。
| 状態 | 例 | 処理方法 |
|---|---|---|
| 配信失敗 | 接続エラー、一時的なサーバーエラー | 回数制限付きのバックオフ再試行 |
| 収集失敗 | ブロックページ、削除済みURL | failed項目だけを別バッチにする |
| パース失敗 | JSON構文エラー、フィールド型の不一致 | 原文を保存してからパーサーを修正 |
| 意味的品質失敗 | 価格が0、空のタイトル、古い観測値 | 業務ルールで検証または人が確認 |
完了検知はポーリングの代わりにWebhookへ切り替えられます。Olostepはbatch.completedイベントを送信し、失敗した配信を約30分間で最大5回再試行します。同じイベントIDは再試行のたびに維持されるため、受信側はそのIDで重複処理を防ぐ必要があります。 Webhookを受け取ってすぐに長い検証を実行せず、速やかに2xxを返してから内部キューで処理してください。
セキュリティ上の注意点も1つあります。現在のWebhookドキュメントでは、暗号学的署名検証が「Coming Soon」と表示されています。 したがって、Webhook本文だけを信頼してデータロードを確定するのではなく、通知で受け取ったbatch_idを使い、認証済みAPIで状態と項目を再照会するためのトリガーとして扱うほうがよいです。
収集できるからといって、収集してよいとは限りません。対象サイトの利用規約とアクセス権限を確認し、自動クライアント向けのパスアクセス規則を提供する/robots.txtも確認してください。RFC 9309はrobots.txtを、アクセス許可やセキュリティ装置ではなく、クローラーが従うべきアクセス規則として定義しています。 個人情報、ログイン後のコンテンツ、著作権のある資料には別途法的な確認が必要です。
実際に1万URLのパイプラインを作る手順
1. 20件のゴールデンサンプルで結果契約を作成します
通常ページだけでなく、在庫切れ、削除済み、空フィールド、地域制限、動的読み込みページも混ぜてください。フィールド型と必須性、許容する空値、schema_versionを決め、JSON Schemaの検証テストを作成します。
2. URLマニフェストと固定IDを生成します
CSVまたはテーブルにcustom_id、元URL、正規化URL、対象ドメイン、収集目的を保存します。重複URLを除外し、robots.txt・規約・アクセス権限を確認した行だけを送信対象としてマークします。
3. 100件からバッチを段階的に拡大します
POST /v1/batchesにitems、パーサーID、必要に応じてwebhookを入れてください。新規アカウントの上限を確認し、100件で成功率・必須フィールド充足率・重複率を測定した後、1,000件と1万件へ拡大します。
4. カーソルを最後まで巡回し、結果を検証します
カーソルがなくなるまで/itemsを照会し、各retrieve_idで結果を取得してください。JSONのパース、スキーマ検証、業務ルール検証を通過した行だけを、エージェント用インデックスまたはデータベースへ送ります。
5. 失敗原因ごとに再処理キューを運用します
配信エラーは回数を制限して再試行し、ブロック・削除済みURLは保留し、フィールドエラーは原文とともにパーサー修正キューへ送ります。ダッシュボードには総件数よりも、有効行率、必須フィールド充足率、重複率、再処理後の回復率を載せてください。
さらに深く知りたい場合
Batch Endpoint - Olostep Docs — バッチサイズ、新規アカウント制限、パーサー、Webhookの使い方を確認できる中核ドキュメントです。 docs.olostep.com
Get the content of multiple websites in one go - Olostep Docs — バッチ作成から状態確認、項目照会、コンテンツ取得までをPython例で説明しています。 docs.olostep.com
Batch Items - Olostep Docs — 完了・失敗フィルターとカーソルベースページネーションの正確なリクエストフィールドを確認できます。 docs.olostep.com
JSON Schema - object — requiredとadditionalPropertiesを使って構造化結果のフィールド契約を作る方法を説明しています。 json-schema.org
RFC 9309: Robots Exclusion Protocol — 自動収集前に確認すべきrobots.txtの標準動作と限界を扱います。 rfc-editor.org
