Agent-Reachの本番環境デプロイにおけるプロキシコストとトークンを削減するインフラ設計
makedream2026年6月19日
0
Computing/Software
Comments (0)
Log in to leave a comment
No posts yet
makedreammakedreamLog in to leave a comment
No posts yet
ローカルのCLIでは問題なく動作していたAgent-Reachベースのエージェントも、本番サーバーに上げた途端、至る所で壁にぶつかります。数万件ものスクレイピングリクエストが殺到すると、CloudflareのようなCDNのセキュリティ網に検知され、IPが次々と遮断されます。かといって、有料の住宅用プロキシだけに頼っていては、帯域幅のコストを賄いきれません。生のHTMLをそのままLLMに投入すれば、コンテキストウィンドウが溢れ、トークン料金の請求額に頭を抱えることになります。この問題を解決するには、動的ルーティングアーキテクチャと前処理パイプラインが必要です。
Agent-Reachを無防備に運用すれば、有料の住宅用プロキシ費用だけで数千ドルを消費することになります。1日10万件のリクエストを処理し、ページあたりの平均サイズが150KBのシステムで失敗率が50%まで上昇した場合、月間のデータ転送量は675GBに達します。Bright DataやOxylabsのようなプレミアムな住宅用プロキシは、1GBあたり4ドルから8ドル程度です。すべてのトラフィックをここに流すと、月額コストは5,400ドルまで高騰します。
オープンソースのプロキシ・アグリゲーターであるScrapoxyをDockerコンテナベースのスーパープロキシとしてデプロイすれば、単一エンドポイントを維持しながらインフラコストを制御できます。まず、プロジェクトルートにdocker-compose.ymlファイルを作成し、valkey/valkey:7.2-alpineイメージとfabienvauchelles/scrapoxy:latestイメージを定義します。Valkeyコンテナに--appendonly yes --requirepass [パスワード]コマンドを指定して、クレデンシャルキャッシュの永続性を確保します。Scrapoxyの環境変数にユーザー名とパスワードを設定した後、docker compose up -dコマンドでコンテナを起動します。この構成により、有料サービスへの購読費用を月200ドル以上節約できます。
ターゲットプラットフォームのセキュリティポリシーに応じてIPのローテーション周期を二元化しなければ、セッションが切断されてしまいます。認証が不要な公開Read-Onlyリクエストは、30秒から3分の間隔で攻撃的なTTLを設定し、ラウンドロビン方式で毎回新規IPを強制割り当てします。しきい値ベースの遮断を回避するための措置です。一方、XやRedditのようにセッションクッキーの保持が不可欠な認証ベースのプラットフォームは、Scrapoxyのクッキーインジェクション機能を有効にして、5分から10分間、同一の住宅用IPノードを固定します。地理的なIPが突然切り替わり、認証セッションが無効化される現象を防ぐためです。
コストをさらに削るには、NGINX APIゲートウェイレイヤーでトラフィックルーティングを最適化する必要があります。NGINX設定ファイル（/etc/nginx/nginx.conf）のupstreamブロックに、1GBあたり1ドル程度のDataImpulseなどの低コストなデータセンタープロキシプールと、Scrapoxyの住宅用プロキシプールをそれぞれ定義します。serverブロック内に/fetch/generic/ロケーションを作成し、RSSフィードやGitHub検索など、セキュリティ強度が低い公開HTMLトラフィックをデータセンタープロキシに転送します。続いて/fetch/social/ロケーションを作成し、高摩擦なソーシャルエンドポイントへのリクエストのみをScrapoxyバックエンドにルーティングしてヘッダーを注入します。この2トラックルーティングを適用すれば、高価な住宅用プロキシの帯域幅の無駄を防ぎ、全体的なプロキシコストを最大90%削減できます。
生のHTMLデータは、重複したDOM要素、スタイルシート、インラインスクリプトの塊です。これをそのままLLMに入力すると、不必要なトークンを消費し、推論結果も曖昧になります。Webページの内容を整形されないままコンテキストウィンドウに注入する代わりにマークダウンに変換すれば、データサイズは75%から90%まで削減されます。パイプラインの前処理段階で正規表現ベースのクリーニングとマークダウンへのシリアライズを行えば、LLM APIのトークン消費量を40%以上削減しつつ、ウィンドウ超過エラーを防止できます。
パーサーコンポーネントであるTrafilaturaとhtml2textを組み合わせ、入力データを前処理するPython関数を実装します。trafilatura.extract()関数を呼び出す際、favor_recall=Falseオプションを指定してサイドバーや広告を排除し、本文テキストのみを抽出します。メインコンテンツの抽出に失敗した場合に備え、html2text.HTML2Text()オブジェクトを作成し、ignore_images=Trueおよびbody_width=0を設定するフォールバックコードを挿入します。抽出されたマークダウンテキストから<script>や<style>などの不要なタグを除去する正規表現（re.sub）と、連続する空白行を圧縮するルーチンを実行すれば、エージェントの応答遅延時間が短縮されます。
長い文書を分割する際は、単純な文字数ベースのチャンキングではなく、意味的な類似度を基準にコンテキストを維持する細分化アルゴリズムを導入する必要があります。文単位で分割されたテキストの埋め込みベクトル間でコサイン類似度を計算し、意味が断絶する箇所を特定します。
Similarity(u, v) = rac{u cdot v}{\|u\| \|v\|}隣接する文章間の距離を計算した後、距離の差が文書全体の95パーセンタイルを超える境界線をセマンティックな分割点として確定し、チャンクリストを生成します。固定長チャンキング方式よりも意味論的チャンキングを適用する方が、関連情報が異なるチャンクに分かれて消失する現象を防ぎ、LLMの情報検索精度を向上させます。
XやLinkedInのようなプラットフォームは、速度制限が厳格です。HTTP 429や403エラーが頻発します。このような一時的な障害状況下で、同期式アプリケーションプロセスが即座に再試行を繰り返すと、サーバーリソースが枯渇し、IP遮断のレベルが上がるだけです。システムの回復力を確保するには、発生した例外の性質を解明し、ターゲットサーバーにかかる負荷を動的に調節する非同期式の例外処理ミドルウェアが必要です。
エラーハンドラークラスを設計する際は、一時的なエラーと恒久的なエラーを正確に分岐させる必要があります。HTTPステータスコードが429、502、503、504であるか、エラーメッセージに'timeout'、'connection refused'が含まれる場合は一時的なエラーとして分類し、再試行対象に指定します。一方、401や400などは恒久的なエラーと判定し、即座にデッドレターキュー（DLQ）に隔離します。一時的なエラーの場合、同時刻にリクエストが集中して発生するThundering Herd問題を防止するため、任意のミリ秒単位のランダムなジッターを含む指数バックオフアルゴリズムを適用します。待機時間の算出式は以下の通りです。
初期の基準遅延時間（）を30秒に設定し、最大上限（）を600秒に制限すれば、3回目の再試行時には約240秒前後の分散された待機時間が保証され、ターゲットプラットフォームの遮断ポリシーを回避できます。
特定のプラットフォームの障害やセキュリティ強化がワークフロー全体を麻痺させる連鎖障害を防ぐため、Redisベースのバルクヘッドパターンをミドルウェアレイヤーに実装します。単一のグローバルキューではなく、宛先ドメインごとに分離された独立したRedisリスト（queue:bulkhead:twitter、queue:bulkhead:reddit、queue:bulkhead:general）を作成します。各キューを消費するワーカープールの最大同時実行数を、Twitterは3、General Webは25といった具合に個別に割り当てます。失敗したタスクの再試行スケジュールを管理するため、RedisのSorted Setを活用して復帰タイムスタンプをスコアとして登録する遅延処理ルーチンを作成します。このバルクヘッド構造を適用すれば、特定のソーシャルメディアでAPI遮断事態が発生しても、該当するワーカーが待機状態になるだけで、エージェント全体の調査作業完了成功率を95%以上に維持できます。
多様なWebソースから無作為に収集した生データには、日付の不一致や虚偽の事実が含まれており、LLMが歪んだ推論を行う可能性が高まります。生成AIモデルにコンテキストを提供する前に、マークダウンファイルの内容の信頼性を計算し、数値的な整合性を検証する不連続な検証レイヤーをパイプラインの終端に結合することで、ハルシネーションを遮断できます。
収集されたメタデータの時間的有効性と、プラットフォームソースごとの重みを計算する決定論的なフィルタークラスを設計します。システム時間基準で未来のタイムスタンプを持つ文書や、妥当でないISO形式の日付を含む文書は、データセットから即座に除外します。また、プラットフォームごとの信頼度ウェイトをマッピングする辞書を宣言し、GitHubには0.95、Wikipediaには0.90を付与し、Reddit（0.50）やTwitter（0.40）のようなソーシャルメディアの情報には低い基本スコアを割り当てます。文書内の著者名とタイトルが完全に保持されている場合にのみ0.05のメタデータウェイトボーナスを追加するロジックを経て、最終的な信頼度スコアを生成します。スコアが基準に満たない情報資産は、LLMのプロンプト組み立て段階で根本から排除されます。
出力データの品質を最終保証するため、生成された回答候補を元のコンテキストと照らし合わせる採点スクリプトを実行します。
\b\d+(?:\.\d+)?%?\b）を活用し、元のデータセットに存在する数字のセットと、生成された文章内の数字のセットを交差演算します。ソースにない任意の数値や通貨単位が検出された場合、数値不一致フラグを発行し、即座にルーティングミドルウェアを通じて再実行を要求します。このような多層検証レイヤーを連動させることで、クロールベースのエージェントが引き起こす数値の改ざんや虚偽の引用問題をアーキテクチャレベルで遮断し、完全に検証されたリサーチ結果のみを最終ユーザーに提供します。