あるエンジニアが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を取得し、response（JSONを含む）をパースし、フォームを送信し、到達可能性を確認し、返ってきた内容から特定のテキストやリンクを抽出できます。各エージェントには明示的なアクセス権があるか、ないかのどちらかです。エージェントごとのガバナンスにより、「すべてのエージェントがインターネットにアクセスできてしまう」というfootgun（自爆行為）を防ぎます。
興味深いのは、エージェントがURLにアクセスできること自体ではありません。Web検索は1年前からエージェントプラットフォームに存在していました。興味深いのは、浮かび上がってきたツールの「形」です。
Web検索とURL抽出は異なるタスクです。検索は「インターネットはXについて何と言っているか？」を調べるためのものです。広範で、生成的な、要約レベルの情報です。一方、抽出は「ここにURLまたはendpointがある。これを取得して構造化された回答をくれ」というものです。信頼性の要件も、コストプロファイルも、失敗のモードも異なります。これらを1つのツールに混在させると、どちらの回答も中途半端なものになります。
Dawnのインテグレーションでは、これらを別個のものとして扱っています。広範なタスクには /web-research 機能を用意しています。FourAは、ターゲットを絞ったタスク用です。エージェントは、実際に必要なものに基づいて適切なツールを選択します。And that's the maturation pattern we're starting to see across agent platforms in 2026: extraction is graduating from "search bolted-on" to its own primitive.
これを読んでいるプラットフォームエンジニアへ
DawnはFourAを8つの名前付きツールとして公開しており、それぞれが一般的な抽出パターンに対応しています。
- HTMLおよびテキストページ用の
foura_fetch_page - クリーンで読みやすいコンテンツ用の
foura_extract_text - ナビゲーション、フォーム、スクリプト、スタイル用の
foura_extract_links - API endpoint用の
foura_fetch_json - header、ステータス、リダイレクト用の
foura_head_url - 高速な到達可能性チェック用の
foura_probe_site - ログイン不要のフォーム送信用の
foura_submit_form - 任意のHTTP用の
foura_single_request
エージェントは質問の要求に応じて選択します。上記のtopstartupsのクエリでは、取得、抽出、フォローアップという3つのツールを順に実行しました。
インテグレーションは1日で完了するほどシンプルです。その下層には2つのrequestスタイルが存在します。アグレッシブなアクセス制限を行わないサイト向けのブラウザレベルのフィンガープリントを備えたダイレクトモードと、それ以外のすべてに対応するproxyルーティングモードです。どちらも同じrequest形状（URL、オプションのheaderとbody、オプションのresponseパース）を共有しています。エージェントは、対象サイトの要求に基づいて選択します。
プラットフォームがエージェントに提供するコントラクトは、通常以下のようになります。
- 小さな機能セット（fetch / extract / probe / submit）。それぞれにエージェントが利用できる特化したツール定義が用意されている
- デフォルトはproxyモード、レイテンシやコストが重視される場合はダイレクトモードにフォールバック
- プラットフォームの顧客がガバナンスを維持できるようにするための、エージェントごとの権限設定
- システムプロンプトに埋め込むのではなく、ツールのパラメータとして公開された構造化responseパース
しかし、ほとんどのプラットフォームエンジニアが過小評価しているのは、テールエンドで発生する問題です。80%のケース（200msで取得に成功し、クリーンなHTMLを返す）は簡単な半分にすぎません。残りの20%（TLSフィンガープリントで制限をかけるサイト、responseにJSチャレンジを仕掛けてくるサイト、クラウドのIPブロックで403を返すサイト）こそが、エージェントが正確な回答を返すか、ハルシネーションを起こすかを左右します。私たちはまさにそのテールエンドに対応するためにrequestパスを再構築しました。「信頼できそう」と「実際に信頼できる」の差を埋めることこそが、開発作業の大部分を占めています。
したがって、もしあなたがエージェントプラットフォームを運営しており、顧客から「エージェントにこのURLをちょっと確認させたいだけなのだが」と聞かれ続けているなら、それが解決のパターンです。ドキュメントは /docs にあります。喜んでご案内いたします。
それ以外のみなさまへ
あなたがこれらを目にすることはありません。ただ、実際のWebページを今すぐ確認する必要がある質問をAIアシスタントに投げたとき、推測したり謝罪したりする代わりに、正確に回答することに気づくだけです。
それが、インテグレーションのグリッドでGitHubやGoogle Driveの隣に並ぶほど信頼性の高い抽出プリミティブがもたらす、ユーザー向けの成果です。それは研究プロジェクトであることをやめ、インフラ（配管）になり始めています。
なぜこれが重要なのか
6ヶ月前、Webページを読み取る必要のあるエージェントはカスタムビルドでした。オーダーメイドのプロンプト、壊れやすいスクレイパー、手動で実装されたリトライ、調子が良い日でも6割の成功率。レイヤーがまだ存在しなかったため、その形は不適切でした。そして、エージェントがアクセスするサイトは常に変化し続けました。アンチボット技術が静的なシグナルから振る舞い検知へと移行したため, その場しのぎのスクレイパーは、開発チームがパッチを当てるよりも早く劣化していきました。
現在、そのレイヤーが形成されつつあります。Dawnはそれをいち早く取り入れ、インテグレーションをリリースしました。今年はさらに多くのエージェントプラットフォームがこれに続くと予想しており、そのコントラクトは収束していくと考えています。つまり、検索用の専用ツール、抽出用の専用ツール、エージェントごとのガバナンス、そして予測可能なコストです。
まだ初期段階です。しかし、何かが台頭するとはこういうことです。ある機能がプロジェクトであることをやめ、プラグ（差し込むだけのもの）になるときです。
もしあなたがエージェントプラットフォームを構築しており、同じような形をリリースしたい場合は、お問い合わせください。Dawn上でエージェントを構築している場合、FourAはすでにそこにあります。トグルをオンにしてください。