アジェンティック AI に欠けるレイヤー — オキシラボ Giedrius Šteimantas

アジェンティック AI の「見えない壁」を崩す：ブラウザ依存からの脱却とインフラ設計の鉄則

アジェンティック AI（自律型 AI）の開発において、多くの開発者が陥っている致命的なミスは、LLM（大規模言語モデル）の接続に注力するあまり、その背後にある「データ取得基盤」を軽視している点です。ブラウザ自動化ツールを安易に全工程で使いこなそうとする姿勢が、CAPTCHA による捕捉や高コスト・低信頼性という壁を生み出しています。

本記事では、スクレイピング業界の知見を持つ Oxylabs の Giedrius Šteimantas氏が提唱する、「必要不可欠な場合のみブラウザを使用し、コンテンツを検証してから LLM に渡す」という鉄則をベースにした、アジェンティック AI の最適化戦略を解説します。

開発者が陥る「ブラウザ全工程」の罠

友人が構築した AI パーソナルショッパーの事例から、この問題の実態が見えてきます。このチャットボットは顧客の好みを聞き出し、AI エージェントに指示を出してオンライン購入までを行うものでしたが、実運用では深刻な問題が発生していました。

開発者は、商品の発見から検証、購入に至るすべての工程で、ブラウザ自動化ツール（例：Playwright など）をそのまま使用していたのです。その結果、以下の課題が浮き彫りになりました。

• CAPTCHA による捕捉: 高速かつ大量のアクセスを試みたことで、サイト側から「人間ではない」と判断され、アクセス自体がブロックされる頻発。
• コストと速度の悪化: ブラウザを起動・操作するオーバーヘッドが大きく、処理が遅く、実行コストも跳ね上がりました。
• 信頼性の欠如: 捕捉が発生するとリトライ機構が必要になり、プロセス全体が不安定になります。また、結果として「商品が見つからない」「在庫がない」という失敗が頻発し、最終的に製品は実用化できない状態に陥りました。

「彼はインフラ層やその下層の仕組みについて考えずに、ブラウザ自動化ツールを何でも屋のように使っていたのです」

この失敗の本質は、「インフラの欠落」にあります。エージェントが自由に活動できるための基盤設計がおろそかだったため、システム全体が脆いものになってしまったのです。

3 つのフェーズ別最適化戦略

スクレイピング業界で長年培われた原則をアジェンティック AI に適用することで、この問題を劇的に解決できます。開発プロセスは「発見（Discovery）」「検証・意思決定（Decision）」「実行（Purchase）」の 3 フェーズに分類され、それぞれで最適なインフラを使い分けるハイブリッド構成が有効です。

1. 発見フェーズ：軽量な検索 API で網羅性を確保

最初のステップは、対象商品が存在するページを探す「発見」です。ここで開発者が行っていたのは、事前に決めたリストのサイトを検索ページで回ることでした。しかし、ブラウザを使うには重すぎます。

解決策: 専用の高速検索 API を導入します。

• 軽量なレスポンス: 2,000 トークン以下のコンパクトな JSON データを返すため、LLM の処理負荷が極めて低いです。
• 高速性: 平均応答時間は 700 ミリ秒未満で、エージェントの回転速度を劇的に向上させます。
• 高成功率: ブラウザを使わずに検索エンジンのインデックスを活用するため、CAPTCHA に捕捉されるリスクがほぼゼロです。

このアプローチにより、エージェントは限定的なリストではなく、Web 全体を検索して関連 URL を効率的に選定できるようになります。また、軽量なレスポンスのため、複雑なモデルを使わずとも高速に処理を進められます。

2. 検証フェーズ：コンテンツの「真偽」を API で保証する

次に、候補となったページにアクセスし、価格や在庫状況、商品説明が条件に合致するかを検証します。ここで多くの開発者が再びブラウザを使用しますが、これが最大のボトルネックになります。

問題点: ブラウザで 10 サイトを開いた場合、CAPTCHA に捕捉されて 7 サイトが失敗していたとします。しかし、開発者は「HTTP ステータスコードが 200（OK）」という表面的な指標だけで判断し、失敗したサイトの HTML データも LLM に送ってしまいます。

「LLM が『これは CAPTCHA のページだ』と見分けるためにトークンを消費するのは、70% を無駄にしているようなものです」

解決策: ブラウザを使わず、ステルス機能付きのスクレイパー API を使用します。

• コンテンツ検証の自動化: 失敗（CAPTCHA やブロック）した場合、明示的なエラーメッセージを返すため、「無効なデータ」を LLM に送る前にフィルタリングできます。
• No Cure, No Pay の仕組み: 成功した結果のみに対して課金されるため、失敗によるコストロスが発生しません。
• 軽量かつ多機能: REST API で数百リクエストを並列処理可能。また、動的コンテンツのレンダリングや地理的位置情報（Geo-location）にも対応しており、現地の在庫情報を正確に取得できます。

この段階で「有効なデータ」のみを LLM に渡すことで、トークンコストを大幅に削減し、エージェントが選択できる候補の幅を広げることができます。

3. 実行フェーズ：本格的なブラウザ自動化の活用

最終的にユーザーが購入を確認した後の「実行（購入）」フェーズでは、状況が一変します。ここでは入力処理や動的なコンテンツの操作が必要となるため、本格的なブラウザ自動化が必須です。

ここで重要なのは、単に Playwright などのツールを使うだけでなく、その背後にあるインフラを強化することです。開発者が直面していたのは、やはり「アクセスブロック」でした。

解決策: Oxylabs のヘッドレスブラウザ（Playwright MCP 互換）を導入します。

• ソースコードレベルのステルス化: 長年のスクレイピング経験に基づき、ブラウザ自体に高度な隠蔽機能を組み込んでいます。
• 住宅用プロキシの自動付与: 自動的に信頼性の高い IP アドレスが割り当てられ、ブロックを回避します。
• 地理的位置情報の活用: 検証フェーズと同様に、現地の在庫や価格情報を正確に反映した状態で購入フローを進められます。

これにより、エージェントは「サイズ選択→カート追加→決済完了」という一連の複雑な操作を、安定して実行できるようになります。

まとめ：コストと信頼性を両立する設計思想

アジェンティック AI の構築において重要なのは、LLM の能力に頼りすぎないことです。開発者が忘れてはいけないのは、「インフラの質」がシステムの成否を分けるという事実です。

• 原則 1: ブラウザは「絶対に必要」という場合のみ使用する。
• 原則 2: LLM に渡す前に、コンテンツの有効性を必ず検証する。
• 原則 3: 適切なインフラ層（検索 API、スクレイパー API、ステルスブラウザ）を組み合わせることで、コストと信頼性の両立を実現する。

「コストは重要だ。そして、欠落しているレイヤーを適切なインフラで埋めることで、開発者は本質的な機能構築に集中できる」

このように、スクレイピング業界の知見を AI エージェント設計に取り入れることで、安価かつ信頼性の高い自動化ワークフローが実現可能になります。単なる「LLM の接続」を超え、データ取得と処理の基盤設計を見直すことが、真のアジェンティック AI 開発への第一歩です。