AIエージェントにリアルタイムウェブデータを食べさせる方法：プロダクションパイプラインガイド

TL;DR:

• AIエージェントのためのリアルタイムウェブデータは、モデルの問題以前にデータエンジニアリングの問題である。収集、検証、鮮度、出所が、エージェントが取得したものを信頼できるかどうかを決定する。
• スケジュールされた取り込みは、ユーザーに向けたエージェントの呼び出しとは分けて行うこと。一般的な質問には準備されたストアから応答し、ライブ取得は価値が急速に低下する事実のみに留める。
• すべてのページに、正規URL、コンテンツハッシュ、スキーマバージョン、収集時間、出所ポリシーを付与する。Embeddingやプロンプトに到達する前に無効なレコードを拒否する。
• 繰り返し可能なサイト取り込みにはCrawlを使用し、範囲が限定されたインタラクティブなタスクにはBrowser MCPツールを使用する。どちらも同じ検証と出所契約に供給されるべきである。
• 鮮度ラグ、取得時間、重複率、スキーマ拒否率、受け入れられた文書あたりのコストを測定する。モデルのレイテンシーだけではユーザー体験を記述しない。

AIエージェントは受け取ったコンテキストに基づいて推論ができる。そのコンテキストが古く、重複している、形が不適切、または出所が欠けている場合、より強力なモデルでも弱い回答しか出せない。

そのため、AIエージェントのためのリアルタイムウェブデータはパイプライン設計の問題である。目標は、すべての会話の中でページをスクレイプすることではなく、エージェントが取得し引用できる形で、定義された鮮度ウィンドウ内で適切な公的証拠を提供することだ。

なぜ新鮮なウェブデータが独自のシステムを必要とするのか

モデルのトレーニングはスナップショットを作成する。製品価格、在庫、ポリシーページ、文書、イベントスケジュール、ニュースは、そのスナップショットが作られた後に変化する。取得はそのギャップを埋めることができるが、ソースレイヤーが次の4つの質問に答えたときのみ可能だ：

1. どの決定に対して十分に新鮮か？ 製品の可用性確認には数分が必要かもしれないし、技術的な参照ページはデイリーのリフレッシュを許容するかもしれない。
2. どこから収集されたのか？ レコードには正規のソースURLと収集時間が必要だ。
3. どの契約の下で有効か？ コンテンツは、下流ツールが期待するスキーマを満たさなければならない。
4. この用途に許可されているか？ ソースルール、ロボット指令、サイトの利用規約、プライバシーの義務、内部ポリシーは蓄積の決定に属する。

したがって、「リアルタイム」はラベルではなくサービスの目標であるべきだ。ソースクラスごとに許容される最大年齢を定義する。その年齢を超えたレコードについては、エージェントがライブリフレッシュを要求したり、保存されたコピーが古いことを明らかにしたり、回答を拒否したりできる。

エージェント向けウェブパイプラインのリファレンスアーキテクチャ

生産経路は9つのステージに分けることができる：

ソースレジストリ → スケジューラーまたはエージェントリクエスト → URLフロンティア → 取得 → コンテンツ検証 → 正規化と重複排除 → 構造化ストレージ → 取得インデックス → エージェントツール

各境界には狭い責任がある。

エージェント向けツールは、ターゲットHTMLを理解する必要がない。title、source_url、collected_at、content、content_hash、schema_versionのような安定したオブジェクトを受け取るべきである。

ユースケースと評価基準に関する補完的な見解については、既存のAIエージェント用ウェブデータベンチマークを参照してください。このガイドは、これらのアプリケーションの背後にある生産パイプラインに焦点を当て続けます。

収集を開始する前に鮮度の経路を選択する

取得には3つの有用なパターンがある。

スケジュールされたバックグラウンド取り込み

多くのユーザーが繰り返しクエリを行うソースには、スケジュールされた取り込みを使用する。会話経路の外でデータをクローリングし、クリーンアップし、インデックスを作成する。エージェントは準備されたレコードを読み込むため、遅いソースがユーザー向けのレイテンシーにならない。

これは通常、文書、カタログ、ポリシーリポジトリ、および監視されたニュースソースに最適である。スケジュールは普遍的な時間単位のジョブではなく、観察された変更頻度に従うべきである。

オンデマンド取得

答えの価値が急速に失われる場合や、事前にURLが知られていない場合は、ライブリクエストを使用する。エージェントは範囲が制限されたツールを呼び出し、コンテンツを受け取り、検証し、現在のタスクに証拠を追加する。
ホストされているScrapeless Browser MCP ドキュメントは、scrape_markdown、scrape_html、およびブラウザセッションアクションなどのツールをリストしています。プロトコル自体は、ツールが機能と結果をモデルにどのように公開するかを標準化しています。Model Context Protocol 仕様がそのインターフェースの権威です。

ハイブリッドリフレッシュ

インデックスされたレコードを最初に提供し、その後はその経過時間がソースの目的を超えるか、ユーザーが明示的に最新の状態を要求するまでリフレッシュしないようにします。これにより、一般的なパスを迅速に保ちながら、現在の証拠へのルートを保持します。

ハイブリッド設計はまた、製品に明確なフォールバックを提供します。ライブ取得が利用できない場合、エージェントは最も最近受け入れられたレコードの年齢を特定でき、現在のものとして静かに提示するのを避けます。

各ソースを適切な取得層にルーティングする

シンプルなページは初回のHTMLで完全なコンテンツを公開する場合があります。他のページはJavaScriptで重要なフィールドをレンダリングしたり、地理的に変化したり、期待されるページの代わりにインタースティシャルを返したりします。

ルーティングはページの動作を使用する必要があります：

Srapeless Crawl クイックスタートは、Markdown、HTML、リンク、およびメタデータ出力を使用したシングルページ、バッチ、およびサブページ収集を文書化しています。インタラクティブレンダリングについては、Scraping Browser製品がエージェントアプリケーションの外でブラウザ実行を維持します。

HTTPリクエストが完了したからといって、応答を受け入れてはいけません。ページ固有のマーカー、最小コンテンツ長、言語、MIMEタイプ、および必要なフィールドをチェックしてください。チャレンジページ、同意シェル、または空のアプリケーションルートは、知識インデックスではなく検疫に入れるべきです。

URLを正規化し、埋め込み前に重複を削除する

URLの重複排除は、重複した取得を防ぎます。コンテンツの重複排除は、重複したチャンクが取得で競合するのを防ぎます。

正規化には通常、以下が含まれます：

• ホスト名の小文字化；
• フラグメントの削除；
• 相対リンクの解決；
• 承認されたトラッキングパラメータのソートまたは削除；
• 1つのサイトポリシーの下でのトレーリングスラッシュの正規化；
• ソースレジストリ外のスキームとホストの拒否。

次に、2つのハッシュを計算します：

• URLハッシュ： 収集と保存のための冪等性キー；
• コンテンツハッシュ： ボイラープレート削除後の変更検出器。

URLハッシュが存在し、コンテンツハッシュが変更されていない場合は、別の埋め込みセットを作成せずに新鮮さメタデータを更新します。コンテンツハッシュが変更される場合は、監査またはロールバックポリシーのために前のバージョンを十分な期間保持し、その後新しい受け入れられたレコードをインデックスします。

取り込み契約の検証

JSON Schemaは、パイプラインに機械で確認可能な境界を提供します。その公式ステップバイステップガイドでは、タイプ、必須プロパティ、およびネストされた制約が有効なJSONをどのように定義するかを説明しています。

以下のブロックは説明用スキーマです。チームはこれを独自のソース分類および保持ルールで拡張する必要があります。

{
  "$schema": "https://json-schema.org/draft/2020-12/schema",
  "type": "object",
  "required": [
    "source_url",
    "collected_at",
    "content",
    "content_hash",
    "schema_version"
  ],
  "properties": {
    "source_url": { "type": "string", "format": "uri" },
    "collected_at": { "type": "string", "format": "date-time" },
    "title": { "type": ["string", "null"] },
    "content": { "type": "string", "minLength": 200 },
    "content_hash": { "type": "string", "pattern": "^[a-f0-9]{64}$" },
    "schema_version": { "const": "agent-document-v1" },
    "provenance": {
      "type": "object",
      "required": ["collector", "permission_class"],
      "properties": {
        "collector": { "enum": ["crawl", "browser-mcp", "direct-api"] },
        "permission_class": { "enum": ["public-authorized", "owned"] }
      }
    }
  },
  "additionalProperties": false
}

スキーマ検証はチャンク処理の前に行われるべきです。そうでないと、形式が不正なドキュメントが高コストの埋め込みを生成し、エージェントが欠落フィールドを期待しているときに失敗する可能性があります。

最小限のクローリング取り込み機能を構築する

現在のScrapeless Node SDKは、ページとサイトの収集のためにScrapingCrawlを公開しています。この前提条件の例は、Node.js、@scrapeless-ai/sdkバージョン1.3.1、SCRAPELESS_API_KEY、および承認された公開ターゲットを必要とします。これは、上記で使用される契約にページを正規化します。スキーマ検証とターゲット環境のストレージを追加した後にのみ実行してください。

import { createHash } from "node:crypto";
import { ScrapingCrawl } from "@scrapeless-ai/sdk";

const crawl = new ScrapingCrawl({
  apiKey: process.env.SCRAPELESS_API_KEY
});

function sha256(value) {
  return createHash("sha256").update(value).digest("hex");
}

export async function collectAgentDocument(sourceUrl) {
  const result = await crawl.scrapeUrl(sourceUrl, {
    formats: ["markdown"],
    onlyMainContent: true,
    timeout: 15000
  });

  const content = result.markdown ?? result.data?.markdown;
  if (typeof content !== "string" || content.length < 200) {
    throw new Error("収集したコンテンツが受け入れ契約を満たしていません");
  }

  return {
    source_url: new URL(sourceUrl).href,
    collected_at: new Date().toISOString(),
    title: result.metadata?.title ?? null,
    content,
    content_hash: sha256(content),
    schema_version: "agent-document-v1",
    provenance: {
      collector: "crawl",
      permission_class: "public-authorized"
    }
  };
}

このコードは、可読性のために取得と正規化を一緒に保っています。生産環境では、スキーマ検証、ストレージ、およびインデックスを別のコンシューマに配置し、各ステージが独立してスケールし、観察できるようにします。

エージェントの取得のためにクリーンデータを公開する

Markdownは、見出しがドキュメントの構造を保持するため、意味的なチャンク処理に役立ちます。 JSONは、製品、価格、場所、スケジュールなどのエンティティにはより適しています。多くのシステムは両方を必要とします：

• 引用とパッセージ取得のために正規化されたMarkdownを保存する。
• フィルターと計算のために安定したJSONフィールドを抽出する。
• 監査や後のパースが必要な場合にのみ生のHTMLを保持する。
• 各チャンクと構造化された行に起源を付加する。

ベクトル検索だけでは完全な取得設計ではありません。ソース、ロケール、コレクションの古さ、許可クラスのメタデータフィルターを使用します。キーワード検索は正確な識別子やエラーコードを保持できます。その後、ハイブリッドランキングステージは、意味的な類似性と正確な一致や新鮮さを組み合わせることができます。

エージェントツールは、無限のドキュメントダンプではなく、証拠バンドルを返すべきです。有用な応答には、選択されたパッセージ、ソースURL、収集時間、および新鮮さの決定が含まれます。これにより、引用のレンダリングと拒否の動作が決定的になります。

パイプラインを可観測にする

スケジューリングからエージェントの応答まで、ソースURLに沿った相関IDで各境界を計測します。OpenTelemetryは、トレース、メトリクス、ログ、バゲージをテレメトリ信号として定義しています。

これらの測定から始めます：

想像上のパフォーマンス数値を公開することを避けてください。承認されたURLのテストセットを確立し、ステージのタイムスタンプを記録し、ソースミックスとサンプルサイズのパーセンタイルを報告します。エンドツーエンドのユーザー遅延には、リクエストが実際にライブパスを取るときにのみ取得を含めるべきです。

古くなったものを隠すことなくコストとレイテンシを削減する

最大の節約は、モデル推論の前に発生することが多いです：

1. 取得前に許可されていないURLや範囲外のURLをフィルタリングします。
2. 詳細ページをリクエストする前にURLハッシュをチェックします。
3. 正規化されたコンテンツハッシュが変更されていない場合は、埋め込みをスキップします。
4. 固定のフラグメントではなく、ドキュメント構造ごとにチャンクします。
5. 長いテキストから小さな構造化されたフィールドを別々に保存します。
6. すべてを1回のメルクでリフレッシュするのではなく、ソースごとの新鮮さの目標を適用します。
7. インタラクティブなブラウザ作業を、必要なページのみにルーティングします。
   リンクされたページが多数あるワークロードの場合、Scrapeless Crawlは、発見とページ取得を担い、アプリケーションはポリシー、スキーマ、ストレージ、取得を管理します。Scrapelessの料金ページで取得予算を受け入れられた文書の測定コストと比較してください。この分離により、チームはエージェントをブラウザ操作に結びつけることなく、各レイヤーを最適化できます。

公開ウェブデータのガバナンスチェックリスト

ソースを追加する前に：

• データが公開されており、その使用が認可されていることを確認する；
• 適用される条件、契約、プライバシールール、地元の法律を確認する；
• サイトのロボットポリシーとリクエストレートガイダンスに従う；
• 文書化された法的根拠とアクセス許可が存在しない限り、個人、認証済み、または敏感なデータは除外する；
• ソースの所有者、ビジネス目的、保持期間、削除方法を記録する；
• 下流のユーザーには、タスクに必要なフィールドのみへのアクセスを許可する。

ロボット排除プロトコルは、RFC 9309で標準化されています。ロボット規則は、条件、プライバシーの義務、または法的レビューを置き換えるものではなく、ソースポリシーへの一つの入力です。

結論：デザインの新鮮さをデータ契約として

AIエージェントのためのリアルタイムウェブデータは、新鮮さ、有効性、起源、許可が明確なフィールドであるときに管理可能になります。スケジュールされたCrawlジョブは一般的な知識を準備し、制約されたBrowser MCPアクションはインタラクティブな事実を処理できます。両方の経路は、同じ検証と取得契約に収束するべきです。

最初の生産スライスを構築するには、Scrapelessアカウントを作成し、一つの認可されたソースを選び、その新鮮さの目標を設定し、Crawlを通じて収集し、さらにドメインを追加する前に、取得から受け入れられた証拠までの道を測定します。

よくある質問

AIエージェントのためのリアルタイムウェブデータとは何ですか？

エージェントの判断と一致する新鮮さのウィンドウ内で収集されたウェブコンテンツです。記録にはそのソース、収集時間、スキーマ、起源が含まれ、エージェントが安全に取得し引用できるようにします。

AIエージェントは毎回リクエストするたびにウェブをスクレイピングすべきですか？

いいえ。頻繁に使用するソースは、通常、バックグラウンドで収集し、インデックス化されたストアから提供する方が良いです。事実がすぐに変わる場合、URLがタスク中に発見される場合、または保存された記録が古すぎる場合には、ライブ取得が適切です。

CrawlとBrowser MCPの違いは何ですか？

Crawlは、繰り返し可能なページ、バッチ、およびリンクサイトの取り込みに適しています。Browser MCPは、インタラクティブなタスク中にMCP互換のエージェントが呼び出すことができる制限されたブラウザおよび抽出ツールを公開します。その出力は、同じ検証と起源のレイヤーを共有できます。

パイプラインはどのように重複したエージェントのコンテキストを防ぐべきですか？

重複する収集ジョブを防ぐために正規化されたURLハッシュを使用し、変更されていない文書を検出するために正規化されたコンテンツハッシュを使用します。受け入れられたコンテンツが変更されたときのみ埋め込みを再構築します。

公開ウェブデータは自動的に使用しても安全ですか？

いいえ。公共の可視性は契約、プライバシー、知的財産、ロボット、または管轄権の義務を除外するものではありません。承認されたソースポリシーを定義し、意図した使用のために法的ガイダンスを取得してください。