Amazon Nova ActはWebページを理解し、操作することができます。2026年において、本番環境のWebエージェントにとって難しい部分はモデルではありません。Webアクセス、つまり適切なジオターゲティングとコンプライアンスを維持しながら、ライブWebに安定してアクセスすることです。この記事では、Nova ActとBright DataのAIエージェント向けWebアクセス層を組み合わせており、ここで紹介する測定値はライブ実行から得られたものです。
TL;DR
本番AIウェブエージェントのボトルネックはモデルではなく、Webアクセスです。解決策は役割分担です。Amazon Nova Actがマルチステップのブラウザ判断を行い、Bright DataのWebアクセス層がアクセス、コンプライアンス、スケールを担います。Bright DataのData for AI 2026レポートによると、AI組織の97%がリアルタイムWebデータに依存しており、90%がアクセス制限によりAIイニシアチブが制限されていると回答しています。
すべてのインポート、スキーマ、ヘルパーを含む完全な実行可能スクリプトはコンパニオンリポジトリにあります。実行する場合はここからコピー＆ペーストするのではなく、クローンしてください。
実行にはPython 3.10以上、pip install nova-act、およびnova.amazon.com/actからのNova Act APIキーが必要です。また、Browser APIゾーンを持つBright Dataアカウントと、データ層呼び出し用のAPIキーも必要です。Node.jsはWeb MCPセクションのみで必要です。
ブラウザエージェントのデフォルトが不十分な理由
ブラウザエージェントの明白なアプローチは、すべてをエージェントに任せることです。ページを開き、クッキーバナーを閉じ、スクロールし、抽出する。デモでは見栄えがしますが、ほとんどのデータ作業においてこれは誤ったデフォルトです。
- 重量が大きい。実際の一般的なページ（eBay検索）は、ブラウザを通じて約3.4 MBを転送しました。これを数百万ページに掛け合わせると、3つのフィールドを抽出するためだけにレンダリングされたWeb全体（すべての画像を含む）を転送するコストが発生します。
- 操作時に不安定になる。booking.comに向けた場合、ページ自体は正常に読み込まれているにもかかわらず、Nova Actはポップアップや遅延読み込みコンテンツと格闘して
ActActuationErrorを発生させました。単純な読み取りは通常信頼性がありますが、複雑なマルチステップ操作はそこで機能しなくなります。 - 非決定論的である。信頼性は急速に低下します。90%の信頼性を持つ10ステップの処理は、計画なしには
0.9¹⁰ ≈ 35%程度になります。
これはブラウザエージェントが役に立たないということではありません。エージェントにしかできないこと（マルチステップのアクションと判断）に使用し、それ以外はすべてインフラストラクチャに委ねましょう。
Amazon Nova Actとは何か、そして何ではないか
Nova Actは、2026年半ば時点でバージョン3.4.xのAWS SDKであり、Pythonでブラウザエージェントを構築するためのリサーチプレビューから本番環境へと移行中です。その設計思想は、一つの巨大なプロンプトとは正反対です。ワークフローを小さく、アトミックで、信頼性の高いコマンドに分割し、通常のPythonで接続します。2つのコマンドはアクションと型付き読み取りです：
from nova_act import NovaAct
from pydantic import BaseModel
class Product(BaseModel):
title: str | None = None
price: str | None = None
availability: str | None = None
with NovaAct(starting_page="https://example.com/product/123") as nova:
nova.act("search for wireless headphones") # an action
data = nova.act_get( # a typed read
"Return the product title, price, and availability.",
schema=Product.model_json_schema(),
)Pydanticスキーマを使用すると、act_getは壊れやすいセレクターなしにページを型付きデータに変換できます。Nova Actは内部でPlaywrightを通じて実際のChromiumを動かしており、これは接続において重要な詳細です。Nova Actは推論、ナビゲーション、構造化抽出を提供しますが、オープンWebの敵対性への回答は提供しません。ジオリーチ、スケールでのブロック解除、組み込みのコンプライアンスはありません。それはNova Actの仕事ではなく、インフラストラクチャ層の仕事です。
Bright Data、Webアクセス層
この層は一つのアイデアを中心に構築されています：AIのためのWebのアンロックです。Web MCPはModel Context Protocolサーバーで、エージェントが直接呼び出せる構造化されたWebツールを提供します。Web UnlockerとSERP APIはクリーンなページと検索結果を返します。Web Scraper APIとデータセットはバルク構造化取得を行います。Browser APIはエージェントが操作する必要がある場合に遠隔操作するクラウドChromeです。その下には195カ国にわたる4億以上のレジデンシャルIPのネットワークがあり、一般的なCAPTCHAチャレンジ、フィンガープリント管理、ジオターゲティングが処理されます。
Bright Dataの「Data for AI 2026」調査では、組織の87%が「二層インターネット」が台頭していることに同意しており、人間のものと並行して自動トラフィックのエージェントWebが走っています。そして65%はすでに、社内でアクセスを構築するのではなく、専用のWebデータインフラプロバイダーに依存しています。
これはツールではなく、層です。エージェントスタックは変わります。その下のWebアクセス層は変わりません。つまり、エンジニアリングの問いは抽象的なブラウザ対APIではありません。仕事を二つに分割します：エージェントが判断を担い、インフラストラクチャがアクセスを担います。
アーキテクチャ：上部に頭脳、下部にインフラ
Nova Actがアクションを送り、構造化データが返ってきます。
Nova Actが判断とアクションを行います。Bright DataのWebアクセス層がアクセス、コンプライアンス、地理、スケールを処理し、ライブWebにアクセスします。
アクションモードでは、Nova ActはChrome DevTools Protocol（CDP）を通じてBright DataのBrowser APIに接続します。これはPlaywright（したがってNova Act）がすでに使用しているのと同じプロトコルです。ブラウザを交換してエージェントをそのまま使います。
接続設定と予想されるセットアップエラー
Browser APIゾーンを作成すると（CAPTCHAソルバーはデフォルトでオン）、ダッシュボードにURLが表示されます：
wss://brd-customer-<id>-zone-<name>:<password>@brd.superproxy.io:9222この文字列はゾーンの概要タブのアクセス詳細の下にあります。
Browser APIゾーンのアクセス詳細。ダッシュボードはインライン認証情報を含むwss://文字列を提供します（パネル上部に表示されているauth+@host形式）。モダンなPlaywrightはそのインライン形式を拒否するため、split_cdp()が認証情報をAuthorization: Basicヘッダーに移動します。左側のIPホワイトリストも別の落とし穴です。IPがそこに記載されていない場合、呼び出しは空のボディを返し、理由はステータスコードではなくレスポンスヘッダーに届きます。
Invalid URLエラー：Playwrightがインラインwss://認証情報を拒否する
それをそのままNova Actに貼り付けると失敗します：
playwright._impl._errors.Error: BrowserType.connect_over_cdp:
Invalid URL: wss://brd-customer-...:[email protected]:9222これは最初の実行でよくある失敗です。Nova Act 3.4にバンドルされているモダンなPlaywright（バージョン1.56）は、WebSocket URLに埋め込まれた認証情報を拒否します。ダッシュボードがインライン形式を表示するのは、古いクライアントでは機能するからですが、Nova Act内のPlaywrightでは機能しません。修正方法は認証情報を取り除き、cdp_headersを通じてAuthorization: Basicヘッダーとして渡すことです。
import os
import base64
def split_cdp(raw_url: str) -> tuple[str, dict | None]:
"""Bright Data gives an inline-credential wss URL; Playwright rejects that.
Move credentials into a Basic auth header. (Parsed manually because
Python 3.14's urlsplit also rejects the multi-colon netloc.)"""
scheme, sep, rest = raw_url.partition("://")
if not sep or "@" not in rest:
return raw_url, None
creds, _, hostport = rest.rpartition("@")
user, _, pwd = creds.partition(":")
token = base64.b64encode(f"{user}:{pwd}".encode()).decode()
return f"{scheme}://{hostport}", {"Authorization": f"Basic {token}"}
endpoint, headers = split_cdp(os.environ["BRIGHTDATA_CDP_URL"])
with NovaAct(starting_page=URL, cdp_endpoint_url=endpoint, cdp_headers=headers,
logs_directory="runs/demo") as nova: # NOTE: logs dir must already exist
...断続的なInvalidScreenResolutionの落とし穴
もう一つの大きな落とし穴はビューポートです。Bright Dataのリモートブラウザは、Nova Actが期待する約1600×900よりも小さい約1280×585のウィンドウをNova Actに提供します。Nova Actは適切にデグレードしません。断続的なハードInvalidScreenResolution ActErrorを発生させます。各クラウドセッションで少し異なるサイズになるため断続的であり、診断が難しく、再試行が必要な不安定なエージェントと誤解しやすいです。接続されたページに対してサポートされているサイズを強制します：
with NovaAct(starting_page=URL, cdp_endpoint_url=endpoint, cdp_headers=headers,
screen_width=1600, screen_height=900, logs_directory="runs/demo") as nova:
nova.page.set_viewport_size({"width": 1600, "height": 900}) # force a supported size to stop InvalidScreenResolution
...二つの小さな落とし穴：StartFailedと不足しているlogs_directory
cdp_endpoint_urlと一緒にheadless=Trueを渡さないでください。リモートブラウザはすでにヘッドレスであり、StartFailedが発生します。また、logs_directoryはNova Actがパスを検証して作成しないため、開始前に存在している必要があります。
エージェントの用途
接続が確立されたら、エージェントに何をさせるかが問題です。単純な読み取りはエージェントが提供する中で最も特徴のないものであり、Bright DataのWeb Scraper APIはそれをより良く、より安価に行います。エージェントはスクレイパーより価値があります。なぜなら、エージェントは操作できるからです。
最も有用なアクションは、フォームの後ろにあるデータに到達することです。事前に知るべき静的URLもなく、APIもないため、スクレイパーはアクセスできません。エージェントはフォームに入力して結果を読み取ることができます。そこで、Nova Actを米国の権威ある薬物承認データベースであるDrugs@FDAに向け、薬物記録を取得するよう求めました：
nova.act("Search for the drug named ibuprofen") # fill the form, submit
drug = nova.act_get("Return the brand name, active ingredient, application number, "
"and marketing status of the first result.", schema=Drug.model_json_schema())そのトレースは、URLでは捉えられない4ステップのフローを示しています。検索ボックスに入力してEnterを押し、最初の結果が折りたたまれているのを見つけてクリックして展開し、詳細ページへのリンクをクリックし、フィールドを読み取りました：
{'drug_name': 'ACETAMINOPHEN AND IBUPROFEN', 'active_ingredient': 'ACETAMINOPHEN; IBUPROFEN',
'application_number': '214836', 'marketing_status': 'Over-the-counter'} # all 4 DOM-groundedブラウザ上のその4ステップ：
実行のフレームごとの実際の録画です。Nova ActはDrugs@FDAで「ibuprofen」を検索し、最初の結果を開き、実行が返した同じ申請番号であるANDA #214836を読み取りました。
一貫性を確認するために異なる薬物で実行しました：aspirinは8-HOUR BAYER（#016030）を返し、metforminはACTOPLUS MET（#021842）を返しました。ibuprofenを含めると、3/3、すべてのフィールドが根拠あり。これがエージェントがそのコストを正当化する場面です。エージェントはフォームに入力し、スクレイパーでは到達できないフォームに保護された権威ある公開データに移動します。深いWebの公開データにAIを根拠付けることは実際の問題です。協力的でよく構造化されたサイトでは、信頼性があります。
ロングテール
同じアプローチがロングテール、つまり事前構築されたスクレイパーがないニッチなサイトをカバーします。Bright DataのWeb Scraper APIはすでに高価値なものを100以上カバーしています。BoardGameGeekに向けると、Nova Actはクリーンな6フィールドのレコード（Catan / 1995 / 3,4 players / 60,120 min / rating 7.1 / lowest price）を返しました。同じセッションでPlaywrightハンドルであるnova.pageを通じてライブDOMに対して検証できます：
assert game.parsed_response["bgg_rating"] in nova.page.inner_text("body") # 7.1 -> present二つの根拠付けの教訓が浮かび上がりました。比較前に正規化すること。ページのエンダッシュ3,4とエージェントのハイフン3-4の違いは偽の不一致であり、ハルシネーションではありません。そしてセッション内で検証し、後でしないこと。ライブマーケットプレイスの価格は抽出時に根拠付けられ、リロード時には消えてしまうため、揮発性データの二次チェックは誤りになる可能性があります。これらにより、6つのフィールドすべてが根拠付けられました。5方向の同時実行でも保持されました。
境界はタスクではなく地形に関するものです。Nova ActはeBayやbooking.comのような敵対的な消費者サイトで苦戦します：クッキーウォール、カスタムバリエーションウィジェット、遅延読み込みコンテンツを持つボット防御のeコマースサイトです。これらのサイトでは、マルチステップのアクションが遅くなって不安定になり、複雑なチェーンがタイムアウトします。公共データベース、内部アプリ、よく構築されたフォームなどの協力的で構造化されたサイトでは信頼性があります。敵対的な消費者サイトでは脆弱です。アクションを少なく保ち、nova.pageですべてのフィールドを検証し、再試行し、敵対的で大量のケースはBright Dataのデータ層に任せましょう。
ジオルーティングが実際に変えること
同じルーティングインフラなしにローカルブラウザでこれを行うことはできません。Bright DataのユーザーネームにCountry-XXを追加することで、3カ国を経由して主要な予約サイトで同じホテル検索を実行しました：
| 経由国 | 通貨 | サンプル一泊料金 |
|---|---|---|
| アメリカ合衆国 | US$ | US$30、US$128、US$171 |
| イギリス | £ | £30、£167、£194 |
| ドイツ | € | €40、€194、€225 |
通貨はクリーンに切り替わり、価格は変換ではなく実際の市場差を反映しています。地理はインフラストラクチャの仕事であり、エージェントの仕事ではないため、これら3つを生のブラウザで読み取りました。エージェントは、US経由のeBay実行と同様に、向けられた市場を抽出します。これは競合価格監視、運賃集約、またはローカル顧客として見る必要がある場合に重要です。
実行で重要なのはどのIPから出るかであるため、各ルーティングセッションを確認しました。出口IPは実際の消費者ISPとして返ってきました。データセンター範囲ではありませんでした：主要な米国ケーブルプロバイダー、英国ブロードバンドキャリア、ドイツのモバイルネットワーク、日本のキャリア、ブラジルの地域ISP。
これがローカルに見えることとローカルであることの違いです。リクエストはその国の実際の住宅ユーザーとして届きます。そのため、価格、在庫、アンチボットの扱いは、フラグが立てられたデータセンター範囲が受けるものよりも、ローカル顧客が見るものに近くなります。
コンプライアンス、90%の問題
これはアクセス制限が重要な場所、つまり90%の問題そのものです：ほとんどのAI組織がそれらの制限がAIイニシアチブを制限していると述べています。ここでBright Dataがガードレールとして機能します。フライトメタ検索サイトに向けると、エージェントは拒否されました：
Page.navigate: Requested URL (kayak.com/flights/...) is restricted in accordance
with robots.txt. Ask your account manager to get full access (brob)ローカルの生ブラウザは少し前に同じサイトを問題なくスクレイプしました。Bright Dataは拒否しました。拒否することは、弱い動作ではなく、より有能な動作です。Bright Dataはデフォルトでrobots.txtを適用し、Know Your Customer（KYC）チェックの背後に機密ターゲットをゲートします。これは企業の法務チームが承認できるアプローチです。
ほとんどの企業ターゲットでは問題ありません。確認したところ、booking.com、Expedia、Hotels.com、Airbnb、eBay、Best Buy、Tripadvisorはすべてクリアしました。制限されているものはアカウントマネージャーとの会話であり、回避策ではありません。インフラストラクチャがアクセス側のコンプライアンスを処理するため、コードがそれを行う必要はありません。
コストと信頼性の予算
調達担当者は二つの質問をします：信頼性はどの程度か、そしてコストはいくらか。
信頼性
信頼性には一つの主要なレバーと一つのハード上限があります。レバーはビューポートの修正です。設定する前は、約半分の実行がInvalidScreenResolutionで失敗しており、そのバグが不安定なエージェントに見えるものの大部分でした。
修正後、サンドボックスではなく実際のサイトで測定しました。5方向の同時eBay読み取りは、5/5を返し、すべての値がnova.pageを通じてライブDOMで確認され、順次約198秒に対して47秒、4.2倍でした。各セッションは新しいBright Data IPで実行され、単一IPへのリクエスト集中を避けました。
これは無料の線形スケーリングではありません。12同時まで押し上げると、12のうち8がクリーンに返ってきました。これはエージェントが壊れているのではなく、無料および従量課金制ティアの同時実行の上限です。実際の企業規模のボリュームは、5つのセッションが5000に無料でスケールすると仮定するのではなく、ゾーンの同時実行制限を引き上げて再試行を予算に組み込むことを意味します。
同時実行からの利益は実在しますが、線形ではありません。プランの同時実行上限を超えると、12の同時読み取りのうち8がクリーンに返ってきました。
単一の軽いアクション（ソート後に読み取り）は時々再試行が必要であり、残った失敗はセッション開始時の一時的なStartFailedでした。したがって、作業を小さなべき等ステップに分割し、再試行でラップし、約1.2から1.5倍の予算を組み、nova.pageですべての出力を検証してください。
残りの制限は地形です。構造化された側では信頼性が維持されます。3つのDrugs@FDAルックアップはそれぞれ同じフローを実行しました：入力、送信、クリック展開、ナビゲート、抽出。3つすべてが3/3、すべてのフィールドが根拠ありで返ってきましたが、それぞれ約50〜90秒と遅かったです。消費者側では、マルチステップチェーンは依然として遅くなりタイムアウトします。
信頼性の数値を一覧で示します：
| シナリオ | 結果 | 意味 |
|---|---|---|
| ビューポート修正前 | 約半分の実行が失敗 | InvalidScreenResolutionが主な失敗 |
| 修正後5方向同時読み取り（eBay） | 5/5根拠あり | 順次約198秒に対して47秒、4.2倍、セッションごとに新しいIP |
| 12同時まで押し上げ（生） | 12のうち8 | 従量課金制の同時実行上限、エージェントではない |
| 単一の軽いアクション（ソート後読み取り） | 時々再試行 | 失敗は再試行可能なStartFailed |
| マルチステップFDAフォーム、3薬物 | 3/3根拠あり | 協力的なサイトだが各約50〜90秒と遅い |
コスト
帯域幅コストは測定可能であり、モデルコストはオープンな問題です。Browser APIはGB単位で請求され、従量課金制で約$8/GBです（ここでの価格はすべて2026年半ば時点）。実際のページの重さを測定しました：
| ページタイプ | 重さ | Browser API @ $8/GB |
|---|---|---|
| 重い消費者ページ（eBay検索） | 約3.4 MB | 約$0.027/ページ → 約$27 / 1,000ページ |
| 軽いページ（サンドボックス製品） | 約0.2 MB | 約$0.0016/ページ → 約$1.60 / 1,000ページ |
再試行乗数を加え、さらにNova Actの推論コストを加えます。これは今日公開されていません。無料ティアは収集量を計測し、本番はAWSを通じて公開価格なしで実行されます。したがって、予算は2行に集約されます。Browser APIの帯域幅は既知で予測可能な費用項目です。エージェントの推論はスケーリング前にAWSで確認する必要があるコストです。
3つのフィールドを抽出するために3.4 MBを移動することも、バルク作業でブラウザをまったく使用しない理由です。データ層はギガバイトではなくリクエストごとに請求します。SERP APIとWeb Unlockerは1,000件あたり約$1.50で実行されますが、ブラウザを通じた重いページ1,000件あたり約$27と比較して。
エージェントを使うべき時とデータ層を使うべき時
Bright DataはWeb MCPとWeb Scraper APIを提供しているため、すべてのことにブラウザを使う必要はありません。分岐点は判断の複雑さです：
- 固定の既知スキーマプル（100,000 SKUの価格と在庫など）。エージェントを使用しないでください。Web Scraper APIは3.4 MBのページも推論コストも一時的な失敗もなく、レコードだけを返します。より安価で信頼性が高いです。
- スクレイプでは捉えられない推論：マルチステップナビゲーション、条件付きロジック（例：制約を満たす最安値の払い戻し可能な運賃）、フォーム送信、WebアプリQA、または事前構築されたスクレイパーがない不慣れなポータル。そこでNova ActとBrowser APIがコストを正当化します。
ルール：固定スクレイプまたはAPI呼び出しとして表現できる場合は、そうしてください。実際のシステムでは二つが組み合わさります。Nova Actが判断フローを処理し、バルク取得をBright Dataの構造化APIに渡します。
実践におけるデータ層
「バルク作業にはデータ層を使用する」が通常のアドバイスです。同じBright Dataアカウントに対して実行した3つの呼び出し、ブラウザなし、エージェントなしです。
1回の呼び出しで構造化検索（SERP API）：AIを根拠付けるための新鮮な解析済み検索結果をJSONとして返します：
requests.post("https://api.brightdata.com/request",
headers={"Authorization": f"Bearer {BRIGHTDATA_TOKEN}"},
json={"zone": "serp_api2", "format": "raw", # gl/hl pin the locale so results are stable
"url": "https://www.google.com/search?q=amazon+nova+act+sdk&brd_json=1&gl=us&hl=en"})9 organic results → 1. github.com/aws/nova-act · 2. nova.amazon.com/act · 3. docs.aws.amazon.com/nova-act …任意のURLをクリーンなLLM対応マークダウンに（Web Unlocker）：エージェントがフォームに入力することで到達した同じFDA薬物記録を直接取得：
json={"zone": "web_unlocker", "format": "raw", "data_format": "markdown",
"url": "https://www.accessdata.fda.gov/.../ApplNo=214836"}→ 8.4 KB of clean markdown, one call, no browser, no CAPTCHA handling, no parsing.既知のソースから構造化レコードのみ（Web Scraper API）：事前構築されたコレクターをトリガーして、ページではなくクリーンなフィールドを取得します。1社のCrunchbaseスクレイパーを実行しました：
requests.post("https://api.brightdata.com/datasets/v3/trigger?dataset_id=gd_l1vijqt9jfj7olije",
headers={"Authorization": f"Bearer {BRIGHTDATA_TOKEN}"},
json=[{"url": "https://www.crunchbase.com/organization/anthropic"}]) # -> snapshot_id, then poll→ 89 structured fields (employees, HQ, CB rank, status, funding …),
ready in ~70s, no browser, no agent, no 3.4 MB page, no parsing.コントラストはアーキテクチャです。ここでエージェントが適切なツールでした。データに到達するために操作する必要があったからです。URLが存在しなかったため、フォームを検索してアプリケーション214836に移動しました。URLが存在する場合、または検索結果や既知スキーマのバルクレコードが必要な場合は、ブラウザを使用しません。データ層を呼び出します。より決定論的で、より速く、より安価で、エージェントの信頼性予算をはるかに少なく使います。Nova Actが発見して操作します。Bright Dataのデータ層がスケールで取得します。
エージェントがBright Dataのツールを直接呼び出す
これまでの統合は手動でオーケストレーションされていました。SERPとWeb Unlockerを呼び出し、エージェントにブラウザを渡しました。より密な統合があります。Nova ActにBright DataのWeb MCPサーバーをツールとして提供し、エージェント自身が検索、スクレイプ、または発見するタイミングを決定します。Nova ActはAWSのStrandsフレームワーク上で動作するため、MCPツールを直接受け入れます：
from strands.tools.mcp import MCPClient
from mcp import StdioServerParameters
from mcp.client.stdio import stdio_client
bd_mcp = MCPClient(lambda: stdio_client(StdioServerParameters(
command="npx", args=["-y", "@brightdata/mcp"], env={"API_TOKEN": BRIGHTDATA_TOKEN})))
with bd_mcp:
tools = bd_mcp.list_tools_sync() # search_engine, scrape_as_markdown, discover, batch…
with NovaAct(starting_page="https://example.com", tools=tools,
cdp_endpoint_url=endpoint, cdp_headers=headers) as nova:
nova.act_get("Use the search_engine tool to find 'Amazon Nova Act SDK'; "
"return the top result's URL.", schema=Out.model_json_schema())実行したところ、エージェント自身のトレースに示されています。「ツール呼び出しは成功し、検索の情報が返ってきました。トップのオーガニック結果は’https://github.com/aws/nova-act’です…」そして{'top_result_url': 'https://github.com/aws/nova-act'}を返しました。エージェント自身がBright Dataのsearch_engineツールを選択し、Bright Dataが検索を実行し、エージェントが結果を使用しました。1回のact呼び出しで約32秒かかり、ブラウザエージェントがおそらくブロックされるような検索ページのスクレイピングはありませんでした。
これが二つのツールを一緒に使用することと、もう一方を自ら呼び出す一つのエージェントの違いです。この実行では、エージェントは直接5つのツールを取得します：search_engine、scrape_as_markdown、search_engine_batch、scrape_batch、discoverです。これはブラウザエージェントが最も苦手とする仕事、つまり検索とバルクフェッチに対するクリーンでコンプライアントなパスです。
組み合わせたパイプライン：広さと深さ
これまでの各コンポーネントは単独で機能します。組み合わせると、トピックに関する根拠のある構造化されたインテリジェンスレコードを構築します。オープンWebから広さを引き出し、フォームに保護された権威あるソースから深さを引き出します。注目の製薬カテゴリであるGLP-1薬で実行しました：
# 1. BREADTH , Bright Data SERP API discovers authoritative sources (no browser)
sources = serp_api("Ozempic semaglutide")[:3]
# 2. FETCH , Bright Data Web Unlocker pulls the top source as markdown (no browser)
context = web_unlocker(sources[0])
# 3. DEPTH , Nova Act fills the Drugs@FDA form for the authoritative record (agent)
fda = nova_act_fda("semaglutide") # verified against the live DOM実際のエンドツーエンドの出力：
{
"web_sources": ["ozempic.com", "mayoclinic.org/…semaglutide…", "accessdata.fda.gov/…/209637lbl.pdf"],
"web_context_chars": 59270,
"fda_authoritative": {"drug_name": "OZEMPIC", "active_ingredient": "SEMAGLUTIDE",
"application_number": "209637", "marketing_status": "Discontinued"},
"fda_grounded": true
}それぞれの半分が、もう一方ではできないことを行いました。データ層は2回のAPI呼び出しでオープンWebを検索し、3つの権威あるソースと59 KBのクリーンなLLM対応コンテキストを返しました。ブラウザもエージェントもありません。エージェントはデータ層だけでは到達できない場所に行きました。FDAの検索フォームに入力し、権威ある規制レコード、アプリケーション209637、そのプロダクト行のステータスは「中止」に移動しました。URLのないフォームの後ろにあるデータです。
そして二つが互いを確認します。データ層はエージェントが操作することで到達した同じアプリケーション番号のFDAラベル209637lbl.pdfを独立して返しました。広さが深さを確認します。
この実行は計画すべき失敗も示しています。エージェントのFDAステップはブランド名「Ozempic」で3回ActAgentFailedで失敗し、活性成分「semaglutide」で成功しました。それが地形の信頼性コストです。だからfda_grounded: trueで検証し、再試行を予算に組み込みます。
同じパイプライン、異なる業界
これは製薬業界を超えて機能し、検証しました。異なる業界、金融コンプライアンスで同一のパイプラインを実行しました。SERPは会社のWeb存在、自社サイトと金融データプロフィールを見つけました。エージェントはブローカーディーラーの権威ある規制レコード（会社名、CRD番号、規制機関、開示件数）にFINRAのBrokerCheck（FDAのフォームよりも難しいAngularアプリ）をナビゲートしました。1回の再試行で根拠付けられました。
製薬から金融まで、クエリとスキーマ以外のコード変更なしで同じパイプラインが機能しました。競合価格設定、市場調査、製品安全監視にも同様に拡張できるはずです。データ層が広さとスケールを処理し、エージェントがゲートされた深さを処理し、エージェントのフィールドはライブページに対して根拠付けられます。
1つのレコードから市場へ
1つのレコードから市場にもスケールします。GLP-1薬市場全体で同一のパイプラインを実行し、構造化された競合データセットを取得しました。データ層が広さを処理し、エージェントが各薬物の権威あるFDAレコードを提供しました：
| 活性成分 | FDAブランド | 申請番号 | ステータス | トップソース（SERP） |
|---|---|---|---|---|
| semaglutide | OZEMPIC | 209637 | 処方箋 | drugs.com |
| tirzepatide | MOUNJARO | 215866 | 処方箋 | ncbi.nlm.nih.gov |
| liraglutide | LIRAGLUTIDE | 212552 | 処方箋 | drugs.com |
市場実行はライブの不一致も明らかにしました。アプリケーション209637は上記の単一レコード実行ではDiscontinuedと読まれ、この表ではPrescriptionと読まれました。FDAアプリケーションは異なるステータスを持つ複数の製品レコードを保持できるため、各エージェント読み取りは1行のスナップショットです。だからこそ、すべての読み取りを検証するのです。
スクリプト外のreCAPTCHA
スクリプト化していなかった一瞬が、アーキテクチャのケースを単独で示しました。3つのルックアップのうち2つで、FDAサイトがエージェントにreCAPTCHAを提示しました。
実行中にDrugs@FDAでエージェントが遭遇した実際のreCAPTCHA。Nova Actのガードレールはそれを解くことを拒否しました。セッションはBright DataのBrowser API上で動作しているため、レコードに到達しました。
Nova Actのガードレールは、それをパズルとして解くことを拒否しました。そのトレースから、一言一句：「私は人間を偽ったり、CAPTCHAやその他のチャレンジを解くことで人間であるかのように見せかけることをしてはなりません。」これが自律エージェントに求められる動作です。
それでも通過できました。セッションがBright DataのBrowser API上で動作しているからです。ローカルの生ブラウザはFDAサイトを読み込むことさえできませんでした。そのブラウザは90秒で2回タイムアウトしましたが、同じ実行でexample.comには問題なく到達しました。CAPTCHAにもデータにも到達しませんでした。Bright Dataセッションはレコードに到達しました。
つまり、役割分担は実際に検証されています。エージェントはCAPTCHAを解きません。解かないし、解くべきではありません。データ層はフォームをナビゲートできません。Bright Data上のエージェントだけが仕事を完了します。
CAPTCHAは断続的であり、後の生の実行では発生しませんでした。CAPTCHAが発生した2つのエージェントルックアップは、約1分50秒と2分37秒の実際の摩擦がかかりました。データセットは3行ですが、パターンは市場全体に当てはまります。
これがNova ActとBright Dataの組み合わせです。どちらのツールも単独では解決できません。
制限事項
- Nova Actはまだ初期段階です。2026年半ば時点でリサーチプレビューであり、英語のみで、インタラクションを制限する無料ティアがあります。すべての実行で「Amazonはこのバージョンのインタラクションに関するデータを収集します」と表示されます。本番はIAM、S3、Bedrock AgentCoreを持つAWSと結合しています。重要なものを構築する前に、AWSで本番ティアの条件と価格を確認してください。
- エージェントはポップアップが多い消費者サイトで脆弱です。booking.comでは、
ActActuationErrorはBright Dataがサービスを提供できないのではなく、エージェントがページと格闘していました。直接的な結果URLを好み、ポップアップを明示的に閉じ、再試行予算に頼るか、データ層にオフロードしてください。 - コンプライアンスには二つの側面があります。必要なガードレールですが、制限されたターゲットはアカウントマネージャーまたはKYCのステップを意味するため、リードタイムを計画してください。また、AIのためのスクレイピングの合法性は2026年に争われており、画期的な公開データ判決、EU AI法、著作権訴訟がまだ進行中です。公開データは自動的な許可ではないため、法務チームを関与させてください。
- 検出は軍拡競争です。エージェントのフィンガープリンティングとクロールごとの支払いは増加し続けています。先を行くことは継続的な作業であり、だからこそこの層は一度限りの修正ではなく管理された依存関係です。
- 自律ブラウザは攻撃面です。ページはエージェントを誘導するプロンプトインジェクションを含む可能性があり、Nova Act自身のドキュメントもそれを指摘しています。制限してください。URLのホワイトリストとブロックリストを使用し、必要のないページから遠ざけてください。モデルに入力させる代わりに、認証情報や支払いなどの機密入力は
nova.pageを通じた直接Playwrightで処理してください。
次のステップ
Nova Actを来年のエージェントに交換しても分割は依然として適用されます：下のレイヤーが耐久性のある部分です。したがって、ツールではなく仕事を分類することから始めてください。ターゲットに安定したURLまたは事前構築されたコレクターがある場合は、データ層に送ってブラウザをスキップしてください。アクションが必要なもの（入力するフォーム、マルチステップのパス、スクレイパーがないポータル）にNova Actを予約してください。
複数回実行する予定のものについては、最初のセッションからこれらを設定してください：
- ゾーンのインライン認証情報を
Authorization: Basicヘッダーに移動し、IPをゾーンのホワイトリストに追加してください。どちらかを省略するとInvalid URLまたはレスポンスヘッダーに理由がある空のボディが返ってきます。 - 接続されたページに1600×900のビューポートを強制し、実行開始前に
logs_directoryを作成してください。 - 同じセッションで
nova.pageに対してすべての抽出フィールドを根拠付け、再試行に1.2から1.5倍の予算を組んでください。
1つのゾーンが追いつかなくなったら、エージェントを責める前に同時実行制限を引き上げてください。バルク取得をSERP API、Web Unlocker、またはWeb Scraper APIに移動してください。Browser APIとWeb MCPはどちらも無料ティアで提供されているため、コミットする前に分割をテストできます。制限されたターゲットはアカウントマネージャーとの会話であり、回避策ではありません。
ここでのすべてのデモの実行可能スクリプトはコンパニオンリポジトリにあります。クローンして、独自のターゲットに向け、分割のどちら半分が実際に必要かを確認してください。
よくある質問
Amazon Nova Actとは何ですか？
Amazon Nova ActはPythonでブラウザエージェントを構築するためのAWS SDKです。ワークフローを小さく信頼性の高いコマンドに分割します：アクションにはact()、型付き抽出にはact_get()です。Playwrightを通じて実際のChromiumを動かします。2026年半ば時点ではリサーチプレビューです。
Nova ActはBright Dataと連携しますか？
はい、Chrome DevTools Protocolを通じて。Nova Actはcdp_endpoint_urlとcdp_headersを通じてBright DataのBrowser APIに接続します。セットアップの注意点は、モダンなPlaywrightがインライン認証情報のwss:// URLを拒否するため、認証情報をAuthorization: Basicヘッダーに移動して1600×900のビューポートを強制する必要があることです。
Nova Actでプロキシを使用できますか？
CDP経由で接続する場合、ネイティブのproxyパラメーターでは使用できません。Nova ActはCannot specify a proxy when connecting over CDPというメッセージでValidationFailedを発生させます。代わりにCDP経由でBright DataのBrowser APIに接続してください。そこでは、ブロック解除、ジオルーティング、CAPTCHA処理がBright Data側で行われます。
Nova Actは本番環境に対応していますか？
2026年半ば時点ではリサーチプレビューであり、英語のみで、従量課金制の無料ティアがあります。本番はIAM、S3、Bedrock AgentCoreを持つAWSで動作します。私たちの実行では、協力的で構造化されたサイトでは信頼性があり、敵対的な消費者サイトでは脆弱でした。構築する前にAWSで本番の条件と価格を確認してください。
この方法でブラウザエージェントを実行するコストはいくらですか？
Bright DataのBrowser APIは従量課金制で約$8/GBを請求します（2026年半ば）。重いページは約3.4 MBを移動しました：再試行前に1,000ページあたり約$27です。上に1.2から1.5倍の予算を組んでください。軽いページは1,000ページあたり約$1.60です。Nova Actの推論は公開価格がないため、バルク作業にはブラウザではなくデータ層を使用してください。
なぜ独自のヘッドレスブラウザとプロキシを使用しないのですか？
測定された失敗モードは回答の半分に過ぎません。ブラウザを動かすことは重く、マルチステップの操作で脆弱であり、非決定論的です。しかし、自分で実行するのがより難しい半分は、地理、コンプライアンス、スケールです：決して終わらない軍拡競争です。インフラストラクチャ層がそれを実行するため、エンジニアリングがそれを行う必要はありません。
データ層ではなくエージェントを使うべき時はいつですか？
仕事が固定の既知スキーマプルであれば、ページも推論コストもないレコードを返すWeb Scraper APIを使用してください。スクレイプでは捉えられない推論（マルチステップナビゲーション、フォーム送信、条件付きロジック）が必要な場合は、エージェントを使用してください。実際のシステムでは二つが組み合わさります。
