エンジニアがDawnを開き、次のように要求する。「https://topstartups.io/ をスクレイピングし、最初の10社のスタートアップを取得して。名前、説明、本社、設立年、URL、ソーシャルページを含め、テーブル形式でフォーマットすること。」
エージェントは少し考え、ページをフェッチし、リストをパースし、各スタートアップのプロファイルをたどり、テーブルを返す。10行。すべての列が埋まっている。Pogo、Auctor、Scalify、Omnea、Rivan、Listen Labs、Doppel、Blossom、Avoca、Traba。本社はブルックリン、ニューヨーク、ロンドン、サンフランシスコ、リモートなど。大半がLinkedInあり。設立年は2020年から2026年。
このテーブルは数回のFourA呼び出しの出力である。
今週、Dawnはエージェントプラットフォーム内で FourAをファーストクラスのツールとしてリリースした。Notion、GitHub、Google Driveと並んでインテグレーショングリッドに配置されている。FourAへのアクセスを許可されたエージェントは、公開WebページやHTTP endpointをフェッチし、レスポンス(JSONを含む)をパースし、フォームを送信し、到達可能性を確認し、返されたものから特定のテキストやリンクを抽出できる。各エージェントは明示的なアクセス権を持つか持たないかのいずれかである。エージェントごとのガバナンスであり、「すべてのエージェントがインターネットにアクセスできる」というような危険な設計ではない。
興味深いのは、エージェントがURLを叩けることではない。エージェントプラットフォームにおけるWeb検索は1年前から存在している。興味深いのは、明らかになりつつあるツールの形である。
Web検索とURLからの抽出は異なるジョブである。検索は「インターネットでXについて何と言われているか」のためのものだ。広範で生成的で要約レベルの情報である。抽出は「ここにあるURLまたはendpointをフェッチし、構造化された回答を返す」ためのものだ。信頼性の要件、コストプロファイル、障害モードが異なる。これらを1つのツールに混在させると、どちらにとっても中途半端な回答になる。
Dawnのインテグレーションではこれらを区別している。広範なジョブ用には /web-research 機能がある。FourAはターゲットを絞ったジョブ用である。エージェントは実際に必要なものに基づいて適切なツールに手を伸ばす。そして、これは2026年にエージェントプラットフォーム全体で見られ始めている成熟のパターンである。すなわち、抽出は「検索のオマケ」から独自のプリミティブへと卒業しつつある。
これを読んでいるプラットフォームエンジニアへ
DawnはFourAを8つの名前付きツールとして公開しており、それぞれが一般的な抽出パターンにマッピングされている。
- HTMLとテキストページ用の
foura_fetch_page - クリーンで読みやすいコンテンツ用の
foura_extract_text - ナビゲーション、フォーム、スクリプト、スタイル用の
foura_extract_links - API endpoint用の
foura_fetch_json - ヘッダー、ステータス、リダイレクト用の
foura_head_url - 高速な到達可能性チェック用の
foura_probe_site - ログイン不要のフォーム送信用の
foura_submit_form - 任意のHTTP用の
foura_single_request
質問の要求に応じてエージェントが選択する。上記のトップスタートアップのクエリでは、フェッチ、抽出、フォローアップという3つが順番に使用された。
このインテグレーションは1日で行えるほどシンプルだ。基盤には2つのrequestフレーバーがある。アクセス制限が厳しくないサイト向けのブラウザレベルのrequestシグネチャを持つダイレクトモードと、それ以外すべてのためのproxyルーティングモードだ。どちらも同じrequest形状(URL、オプションのヘッダーとボディ、オプションのresponseパース)を共有する。ターゲットサイトの要求に基づいてエージェントが選択する。
プラットフォームがエージェントに提供するコントラクトは、次のようになる傾向がある。
- 少数セットの機能(fetch / extract / probe / submit)。それぞれにエージェントが利用できる焦点を絞ったツール定義がある。
- デフォルトはproxyモード。レイテンシやコストが重要な場合はダイレクトにフォールバックする。
- プラットフォームの顧客がガバナンスを維持できるようにするためのエージェント単位の権限。
- システムプロンプトに埋もれるのではなく、ツールパラメータとして公開される構造化されたresponseパース。
しかし、ほとんどのプラットフォームエンジニアが過小評価しているのは、テールで何が起こるかである。80%のケース(fetchが200msで成功し、クリーンなHTMLを返す)は簡単な部分だ。残りの20%(requestシグネチャで制限をかけるサイト、responseにJSチャレンジを仕掛けるサイト、クラウドIPブロックで403を返すサイト)が、エージェントが正確な回答を出力するか、ハルシネーションを起こすかを決定する。私たちは まさにそのテールのために requestパスを再構築した。「信頼できそう」と「実際に信頼できる」の違いが、作業の大部分を占める。
したがって、エージェントプラットフォームを運営していて、顧客から「このURLをただチェックする」にはどうすればよいか尋ねられ続けているなら、これがそのパターンだ。ドキュメントは /docs にある。喜んでご案内する。
その他の方々へ
皆さんがこれらの裏側を見ることはない。AIアシスタントに実際のWebページを見る必要がある質問をしたとき、推測や謝罪ではなく、正確に回答することに気づくだけだろう。
それが、インテグレーショングリッドでGitHubやGoogle Driveと並んで配置できるほど信頼性の高い抽出プリミティブの、ユーザー向けの結果である。研究プロジェクトであることをやめ、インフラになり始めるのだ。
なぜこれが重要なのか
6ヶ月前、Webページを読み取る必要があるエージェントはカスタムビルドだった。専用のプロンプト、脆弱なスクレイパー、手作りのリトライ、調子が良くて60%の成功率。レイヤーがまだ存在していなかったため、形が間違っていたのだ。そして、エージェントがアクセスするサイトは常に変化していた。アンチボット技術は 静的なシグナルから振る舞いチェックへと移行したため、継ぎ接ぎのスクレイパーはチームがパッチを当てるよりも早く劣化していった。
現在、そのレイヤーが形成されつつある。Dawnはこれを採用し、インテグレーションをリリースした。今年はさらに多くのエージェントプラットフォームがこれに続くと予想しており、コントラクトは収束していくと考えている。すなわち、検索専用ツール、抽出専用ツール、エージェントごとのガバナンス、予測可能なコストである。
まだ初期段階だ。しかし、これが何かが台頭していく時の姿である。機能がプロジェクトであることをやめ、プラグになり始める時だ。
エージェントプラットフォームを構築しており、同じ形をリリースしたい場合は、声をかけてほしい。Dawnでエージェントを構築している場合、FourAはすでにそこにある。オンに切り替えるだけだ。