技術要約：失敗を安全にする：オープンウェブ・データ収集のための制約付き検証可能エージェント・フレームワーク

1. 問題定義

本論文は、LLM（大規模言語モデル）やエージェントを直接的なオープンウェブ・データ収集に使用することの信頼性の低さを扱う。LLMは自然言語からスクレイパーコードを生成できるが、直接適用すると、ヘテロジニアス（異種混合的）なウェブページによる構造的な脆弱性と、LLMによるコード生成の確率的な不整合に直面する。一般的な失敗モードには、依存関係のエラー、セレクターの破損、スキーマの不一致、出力フォーマットの一貫性の欠如などが含まれる。従来のパイプラインは手動の作業に依存している一方で、制約のないエージェントのアプローチは検証可能性に欠け、本番環境における失敗の監査、測定、修正を困難にしている。

核心となる課題は、「完璧なエージェントの推論」から「検証可能な収集パイプライン」へとシフトすることである。すなわち、すべてのステージの入力と出力がチェック、測定、監査可能である必要がある。

2. 手法

著者らは、自由形式のコード生成を、型定義されたJSONコレクター設定の生成に置き換える制約付き検証可能エージェント・フレームワークを提案している。このシステムは「生成–実行–チェック–修正」のクローズドループで動作し、LLMの役割（要件理解と構成生成）と実行エンジン（静的なAirflow DAG）を分離している。

2.1 6種類のコレクター・タクソノミー（分類学）

構造的な境界を強制するために、本フレームワークは6種類のコレクター・タイプを定義しており、それぞれに明示的な機能的境界と構成ルールが定められている：

1. Search（検索）: キーワードを通じて候補となるURLを発見する（コンテンツ抽出は行わない）。
2. List（リスト）: ページネーションされたリストを辿り、詳細へのリンクを見つける（深いコンテンツ抽出は行わない）。
3. Detail（詳細）: 単一のページから構造化されたフィールドを抽出する。
4. API: 公開APIを呼び出し、レスポンスフィールドをマッピングする（ブラウザ操作は行わない）。
5. Interactive（インタラクティブ）: 動的なページ上でクリックや入力を実行する（認証やCAPTCHAの回避は行わない）。
6. File（ファイル）: 公開ファイル（PDF、Excel）をダウンロードし、解析する。

2.2 制約付きエージェント・フレームワーク

フレームワークは、4つの制約カテゴリの下で動作する5つのモジュールで構成される：

1. 要件理解エージェント: 自然言語による記述 ($d$) を、対象サイト（ホームページ、サイトマップ、サンプルページ）を積極的に探索してソースコンテキスト ($x$) を抽出することで、完全なタスク表現 ($R$) へと変換する。
2. コレクター実体化エージェント: 「リファレンス・コーディング ＋ テンプレート・スロットフィリング」のアプローチを用いて、JSON構成 ($M$) を生成する。エージェントはコードを書く代わりに、以下の制約に従ってテンプレートの空欄を埋める：
   • タスクタイプ制約: 正しいコレクタータイプが選択されていることを保証する。
   • 構成構造制約: JSON Schemaへの準拠を強制する。
   • ツール再利用制約: 新しいコードを生成するのではなく、構築済みのユーティリティ関数を再利用する。
3. Airflowによる検証とスケール実行: 静的なAirflow DAGがJSON構成を実行する。検証実行では、エラーを低コストのプレプロダクション段階に移行させるために小規模サンプルのパラメータを使用し、スケール実行では本番用パラメータを使用する。これにより、実行段階でのLLMトークンの消費をゼロにする。
4. 品質チェック・モジュール: ルールベースの決定論的な評価器（LLMは使用しない）が、構造、コンテンツ、関連性、添付物、実行の5つの次元で結果をスコアリングする。これは複合スコア ($S$) とエラーレポートを生成する。
5. フィードバック修正モジュール: 品質レポートを構造化されたフィードバック制約（例：失敗ブラックリスト、禁止された仮説）に変換する。実体化エージェントは、これらの新しい制約の下で構成を再生成し、クローズドループを形成する。

3. 主な貢献

1. 6種類のコレクター・タクソノミー: 収集タスクを標準化するための、明示的な境界と構成ルールを持つ形式的な分類システム。
2. 制約付きエージェント・フレームワーク: LLMの出力を、自由形式のコードから、4層の入れ子状の制約（タイプ $\to$ テンプレート $\to$ ユーティリティ $\to$ 検証）の下での型定義されたJSON構成へとシフトさせるシステム。
3. 検証可能なクローズドループ: ルールベースの品質ゲートと構造化されたフィードバック修正を用いた「生成–実行–チェック–修正」メカニズムにより、監査可能な失敗シグナルを実現。
4. マルチレベルの実験的検証: 要件分類、コレクター実体化、実行時LLMベースラインに対する品質・コストのトレードオフ、およびAirflowとの互換性を網羅する包括的なテスト。

4. 実験結果

フレームワークは、138件の収集タスク（うち80件はソース検証済み）のデータセットを用いて評価された。

• 要件分類: システムは、コレクタータイプの分類においてMacro-F1 0.7793を達成し、ルールベースのキーワード・ベースライン（0.7562）を上回った。ただし、著者らは、記述のみでは曖昧なタスク（例：「detail」か「list」か）に対して不十分であり、積極的なプロービング（探索）が必要であると指摘している。
• コレクター実体化: 制約付きフレームワークは、平均品質スコア 0.5369 およびパス率 55.07% を達成し、制約のないLLM生成（品質 0.4876、タイプ一致率 18.84%）およびルールベースのベースラインを大幅に上回った。
• 品質・コストのトレードオフ（80件のソース検証済みタスク）:
  • 実行時LLMベースライン（例：Schema-constrained LLM, Crawl4AI）: 高いワンショット品質（0.7051 および 0.6996）とパス率（81.25% および 80.00%）を達成したが、高いコスト（1ランあたり3,400–4,200トークン）と長い実行時間（14–16秒）を要した。
  • 提案フレームワーク: より低いワンショット品質（0.5631）とパス率（50.00%）となったが、実行段階でのLLMトークン消費はゼロであり、最短の実行時間（5.052秒）を達成した。
• フィードバック修正: 意図的に欠陥のある構成に適用した場合、フィードバック修正によって平均最終品質は0.5087から 0.9007 へ、パス率は0.72%から 100% へと向上し、既知の欠陥タイプに対する修復メカニズムの有効性が示された。
• エンジニアリング検証: 生成された138件の構成はすべて共有テンプレートに基づいており（再利用率100%）、Airflow 2.8.0内で正常に実行された。

5. 重要性と主張

本論文は、このフレームワークを、実行時のLLMによる抽出の一般的な代替物としてではなく、繰り返されるスケジュールされたデータ収集に適した、再利用可能で低コストかつ検証可能な実行パスとして位置づけている。

• 「失敗を安全にする」という哲学: 著者らは、制御された明示的な失敗（型制約、スキーマ検証、ルールベースのゲートによるもの）は、制御されていない沈黙の成功よりも好ましいと主張している。失敗は、静かなデータの破損ではなく、監査可能で追跡可能なシグナルとなる。
• トレードオフの承認: 論文では、実行時LLMベースラインが優れたワンショット品質を提供する一方で、提案されたフレームワークは決定論的で償却可能なコストモデルを提供することを謙虚に認めている。LLMのコストを実行時の構成生成という一度限りのステップにシフトすることで、フレームワークは、実行速度とトークンコストが極めて重要となる高頻度のスケジュール収集タスクにおいて経済的に実行可能となる。
• 限界: 著者らは、構築された要件を使用していること、生のユーザーリクエストではないこと、長期的な有意性検定が不足していること、および複雑なインタラクティブページや認証境界に対するシステムの感度について、明示的に限界を述べている。本フレームワークは、コンプライアンスを遵守した公開アクセス可能なデータシナリオ向けに設計されている。