エンジニアが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 - header、ステータス、リダイレクト向けの
foura_head_url - 高速な疎通確認向けの
foura_probe_site - ログイン不要なフォーム送信向けの
foura_submit_form - 任意のHTTP処理向けの
foura_single_request
エージェントは要求内容に応じてツールを選択します。前述のtopstartupsクエリでは、取得、抽出、追跡という3つのツールを順次使用しました。
統合は1日で完了できるほどシンプルです。基盤には2種類のrequest方式があります。過度なアクセス制限がないサイト向けのブラウザ級requestシグネチャを備えたdirectモードと、それ以外のサイト向けのproxyルーティングモードです。どちらも同じrequest構造（URL、任意のheaderとbody、任意のresponse解析）を共有します。エージェントは対象サイトの要件に応じて適切な方式を選択します。
プラットフォームがエージェントに提供するインターフェースは、通常以下のようになります。
- エージェントが利用できる明確なツール定義を持つ、少数に絞られた機能群（fetch / extract / probe / submit）
- デフォルトはproxyモード、レイテンシやコストを優先する場合はdirectモードへのフォールバック
- プラットフォームの顧客がガバナンスを維持できるようにするためのエージェント単位のパーミッション
- システムプロンプトに埋め込まず、ツール引数として公開された構造化response解析
しかし、多くのプラットフォームエンジニアが見落としがちなのは、エッジケース（テール）で発生する問題です。全体の80%を占める標準的なケース（200msでfetchに成功し、クリーンなHTMLが返る）の処理は難しくありません。残りの20%（requestシグネチャによる制限、responseに差し込まれるJSチャレンジ、クラウドIPブロックによる403エラーなど）への対応こそが、エージェントが正確な回答を返すか、ハルシネーションを起こすかの分かれ目となります。私たちはまさにそのエッジケースに対応するためにrequestパスを再構築しました。「動いているように見える」状態と「実際に高信頼である」状態の差を埋めることこそが、開発作業の大部分を占めています。
エージェントプラットフォームを運営していて、顧客から「このURLをエージェントに確認させたいだけなのだが」と頻繁に求められているなら、この構成が解になります。ドキュメントは/docsにあります。導入のサポートも随時受け付けています。
一般ユーザーにとっての変化
ユーザー側でこれらを意識することはありません。今の実際のWebページを確認する必要がある質問をAIアシスタントに投げた際、推測で答えたり謝罪したりする代わりに、正確に回答するようになるだけです。
これは、GitHubやGoogle Driveと並んで連携グリッドに配置できるほど高信頼な抽出プリミティブがもたらすユーザー体験です。もはや実験的なプロジェクトではなく、標準的なインフラとなります。
これが重要な理由
半年前まで、Webページを読み取る必要のあるエージェントは都度カスタム構築されていました。専用のプロンプト、壊れやすいスクレイパー、手作りのリトライロジック、調子が良くても成功率は60%程度でした。基盤レイヤーが存在しなかったため、構成自体に無理がありました。さらに、エージェントがアクセスするサイト側も常に変化していました。Bot検出が静的なシグナルから振る舞いベースのチェックへと移行したため、応急処置で作られたスクレイパーの劣化速度にチームのパッチ適用が追いつきませんでした。
現在、そのレイヤーが形作られつつあります。Dawnはいち早くこれを採用し、インテグレーションをリリースしました。今年中にさらに多くのエージェントプラットフォームがこれに続き、検索用の専用ツール、抽出用の専用ツール、エージェントごとのガバナンス、予測可能なコストといった共通のインターフェースに収束していくと予想しています。
まだ初期段階ですが、新たな標準が立ち上がる過程とはこのようなものです。特定の機能が研究プロジェクトであることをやめ、プラグとして機能し始める瞬間です。
同様の構成を自社のエージェントプラットフォームに組み込みたい場合は、お問い合わせください。Dawn上でエージェントを構築している場合、FourAはすでに利用可能です。有効化してご利用ください。