エージェント基盤構築の5層要件とは

TL;DR: Web エージェントにはブラウザ以上のものが必要です。大規模運用では、ウォームプールの確保、隔離、サイトが受け入れるアイデンティティの管理、可観測性、そして各判断の背後にあるモデルゲートウェイが不可欠です。それぞれの層は個別に構築可能ですが、それらを統合したシステムを維持するには、シニアエンジニアによるチームの専有が必要です。この記事ではこれら 5 つの層を分解し、自社で構築する価値があるかどうかを見極める方法を解説します。

Web で実際に作業を行うエージェントには、それを遂行するための「手」が必要です。その手とは、マークアップを取得する HTTP クライアントではなく、ページの JavaScript を実行し、ナビゲーション間でセッションを保持し、モデルが推論する DOM をレンダリングし、ログインの壁を突破できる本物のブラウザのことです。モデルは「何をすべきか」を決定しますが、実際にページを描画するのはブラウザです。

しかし、「手」を用意することは始まりに過ぎません。見過ごされがちですが、私たちがラップトップを開くとき、想像以上に多くの機能を持ち寄っているものです。人間がオープンウェブ上で作業するようにエージェントが動くためには、人間の他の能力も必要になります。サイトが認識して通過させるパスポートのようなもの、実行中に何が起こったかを監視する「目」、そして各クリックの背後にある判断や推論です。それでも、エージェントに生物学はありません。そのすべてを支えるのは、コンピューター equivalent の基盤、つまり数千のエージェントを同時に稼働させながら互いに漏洩しないように支える配管のようなインフラストラクチャです。

ブラウザ環境を立ち上げるのは意外と簡単です。Chromium や Playwright はオープンソースですし、コンテナ運用の経験があれば、その日のうちにエージェントがフロー操作を開始できる状態にできます。

週末のプロジェクトとして始めるのも悪くないでしょう。ただし、本番環境での運用まで見据えると話は別です。

監視していたブラウザが一つ増えるだけで、管理すべき数は数千に膨れ上がります。各ブラウザは、サイトから信頼される「パスポート」を保持し、拒絶されやすいページへ到達し、タスク途中でセッションが切断された際に復旧し、失敗した 1 万分の 1 のケースでもデバッグ可能な十分なログを残す必要があります。もちろん、既存のツールでこれら全てを構築することは不可能ではありませんが、単に Chromium を起動するだけとは比べ物にならないほど複雑です。

重要なのは、これらはすべて「エージェントそのもの」ではないという点です。パスポート管理、プール、分離、プロキシ、観測性（オバザビリティ）、モデルのルーティングは、すべてエージェントとウェブの間を繋ぐ基盤（サブストレート）に過ぎません。つまり、これを構築・維持するために四半期を費やすことは、他社には真似できない独自の製品機能の開発時間を削ることを意味します。

では、人間のようにウェブを利用するエージェントのインフラを構築する際に考慮すべき点を整理しましょう。

エージェントはリクエストパスにブラウザを組み込むため、処理フローは以下のようになります。まずモデルがアクションを選択し、ブラウザがそれを実行、そしてページがレンダリングされて戻ってきます。このページこそが、ループが再度実行される前にモデルが確認できる唯一の視点です。したがって、ブラウザのレイテンシはそのままエージェントのレイテンシとなり、タスク中にコールドスタートが発生すれば、待機する下流プロセスのために実行中のエージェントが停止してしまいます。

ローカル環境ではこうした問題は感じないものです。Chromium を一度起動して常時稼働させておけば、セッションがクラッシュしても手動で再起動すれば済みます。しかしスケールすると「手」は存在しなくなります。小さな数値ももはや小さくありません。監視する担当者がいない数千台のブラウザ群において、かつては丸め誤差に過ぎなかった 0.1% のクラッシュ率が、数千セッションにわたる継続的なインシデントとして現れてしまいます。ローカルなら再起動で済んだメモリリークが、ファーム全体では慢性的な OOM（Out Of Memory）として顕在化します。

これに加えて、コールドスタートのコストも重くのしかかります。イメージの取得から Chromium の起動、そしてコマンド受け入れまでの数秒間は、エージェントがブラウザの準備完了を待ってブロックされている「死んだ時間」です。これを解決するには、事前にブラウザを準備しておく「ウォームプール」の活用です。すでに起動済みでアイドル状態にあるブラウザが、次のリクエストを待ち構えている仕組みです。

これをうまく運用するには、3 つのポイントに集約されます。

1 つ目はサイズ設定です。ウォームブラウザ数が少なすぎると、リクエストがコールドスタートの待ち行列に詰まり、本来排除しようとしていたレイテンシが再び発生します。逆に多すぎれば、何もしないブラウザのためにコストを払い続けることになります。適切な数はトラフィックに追従するものであり、プールは固定されたままではなく、1 日のうちで増減する必要があります。

2 つ目はアイドル比率です。ここが経済性の鍵となります。アクティブなブラウザ 1 台あたり、いくつの予備ブラウザを保有すべきかは、トラフィックのスパイク具合に依存します。バースト的で予測不能な負荷がかかるプロダクトの場合、ピーク時に耐えられるよう過剰に用意する必要があり、使用されているブラウザ 1 台に対して予備のブラウザも 1 台温存しておく必要があります。しかし、独立したトラフィックを同じプールに分散させれば、バーストは平滑化されます。その結果、予備のブラウザ 1 台で複数のアクティブなセッションをカバーできるようになり、セッションあたりのコストが低下します。

この比率は、処理量が増加するにつれて改善していきます。

3 つ目はドレイン（排水）です。セッションは状態を持ち、長期間継続するため、ステートレスなワーカーのように負荷が下がった瞬間に即座にキャパシティを解放することはできません。セッションの最中にブラウザを停止させれば、実行中の作業が中断されてしまいます。スケールダウンするには、セッションが完了するまで待って初めてキャパシティを回収できます。そのため、デプロイを行う際は、フラートを段階的にドレインしてリフィルするサイクルを組む必要があります。

これら 3 つの要素はすべてトラフィックに連動するため、一度設定して放置しておくことはできません。これは反復的な作業であり、今日調整したプールも、利用状況が少し変わっただけで最適化から外れてしまいます。

これが最初のレイヤーです。本質的には、状態管理によって複雑化した通常のオートスケーリングに過ぎません。応答性を保つために保有するアイドル容量のコストは、決してゼロになることはありません。

ブラウザは、サンドボックス内で信頼できないコードを実行するように設計された唯一の存在です。それ以外のコンポーネントは、すべて自社で記述またはレビューしたコードを実行しますが、ブラウザはエージェントがナビゲートした任意のページを読み込み、そのページが提供する JavaScript を、自社のプロセス内および自社のコンピュータ上で実行します。

これは普段のノートパソコンでは問題になりませんが、数千台のブラウザを同時に起動し、誰も検証していないページにアクセスさせ、さらにインフラを共有している状況では大きなリスクとなります。1 台でもブラウザが侵害されれば、そこは他のすべてのセッションと共有されているホストへの足掛かりになります。悪意のあるページが Chromium の脆弱性を突いてブラウザプロセスから脱出し、共有インフラ上ではその抜け道が並行して実行中のセッション全体に波及します。

これは想像以上に頻繁に起こる問題です。Chromium は常にセキュリティ修正をリリースしており、その多くは高レベルまたはクリティカルな評価を受けています。中には、実際に野外で悪用されていることが確認されてからようやくパッチが適用されるケースもあります。世界中で最も攻撃の標的となるソフトウェアを、制御できない入力に対して同時に数千コピーも稼働させるのは、非常に大きな課題です。

この問題は 2 つの側面から対処します。

まず重要なのは「隔離」そのものです。すべてのセッションには明確な境界線が必要であり、ブラウザからの脱出を試みたページがホストに到達するのではなく壁にぶつかるようにする必要があります。感染は防げます。つまり、1 つのサンドボックス内に 1 つのブラウザを配置し、できれば共有カーネルではなく軽量な仮想マシン（VM）ごとに分けることが理想です。これにより、Chromium のレンダラーで発生した脆弱性攻撃が脱出しても、ホストや隣接するセッションに到達できなくなります。多くのブラウザを 1 つのコンテナ内で共有するような単純な構成は、1 つの悪意あるページによってチーム全体が停止してしまうリスクを抱えています。

当社の計算層は Firecracker を基盤としており、これによりフルサイズの仮想マシンを個別に用意するコストをかけずに、ブラウザレベルでの完全な隔離を実現しています。

考慮すべきもう一つの要素はパッチ適用です。CVE（Common Vulnerabilities and Exposures）は絶えることなく発生し続けるため、パッチ適用もまた継続的な作業となります。すべてのリリースは迅速にテストされ、ファーム全体へ展開される必要があります。なぜなら、修正情報が公開されてから攻撃が武器化されるまでの時間は極めて短いからです。公開された CVE は、その時間窓を狙って侵入しようとする者にとって格好の標的となります。

やがて気づくことになるのは、パッチ適用とステルス性の追求は両立しにくいという事実です。もしステルス性を高めるために Chromium をフォークしたのであれば、本番リリース前にそのフォークに対してすべてのアップストリームからのセキュリティパッチを再適用する必要があります。つまり、カスタムによる回避策に依存すればするほど、最新状態を維持することがいかに困難になるかということになります。セキュリティ対策と回避策は、結局同じバイナリを巡って競合する同一のリリースパイプラインとして機能してしまうのです。

エージェントがアクセスするすべてのサイトは、その正体を評価し、2 つの問いを投げかけます。「これは誰か？」「どこから来たのか？」。人間であれば無意識にこの質問に応じますが、エージェントには「パスポート」のような証明を提示して信頼を得る必要があります。オープンウェブ上では、エージェントが認められれば通過でき、認められなければ拒絶されます。

ローカル環境ではこれらの問いは投げかけられず、誰かがあなたを検証することはありません。しかしスケールした運用においては、すべてのリクエストに対して両方の問いが確認されます。デフォルトの設定では、これらに直面すると CAPTCHA やレート制限、あるいは完全なブロックといった課題に遭遇し、通過できなくなってしまうのです。

サイト側から見た識別情報

ブラウザは、接続するたびに固有の「身元」を持っています。これはサイトが読み取れる一連のシグナルの集合体であり、ネットワーク層からアプリケーション層まで幅広く存在します。

ネットワークレベルでは、TLS ハンドシェイク の結果として指紋（JA3 またはより新しい JA4）が生成され、HTTP/2 フレームの順序付けもシグネチャとなります。これらは本物の Chrome ブラウザと、自動化ツールで使われるスタックの間では明確に異なります。

さらに上位の層では、ページ側が navigator.webdriver の値を読み取ったり、インストールされているフォントやプラグインを列挙したり、Canvas や WebGL の描画結果をハッシュ化して、グラフィックススタックがどのようにレンダリングされるかを解析できます。さらには、マウスの移動経路やクリック間のタイミングといった行動パターンまで監視可能です。

目立つ特徴を消し去ることは比較的容易です。ヘッドレス版の Chromium は、navigator.webdriver を true に設定し、「HeadlessChrome」というユーザーエージェントを送信し、プラグインを一切公開せず、Canvas の描画にもランダム性（エントロピー）を持たせません。これらはそれぞれ Chromium のフォーク を作成して修正を加えることで解消できます。

しかし、真に難しいのは「整合性」の確保です。検知システムはすべてのシグナルを総合的に読み取ります。そのため、「Windows 上で Chrome であるかのように振る舞いながら、Linux のレンダラー文字列を持ち、フォントの計測値が一致せず、IP アドレスの地理的位置とタイムゾーンが合わない」といったブラウザは、手つかずのヘッドレスブラウザよりも容易に特定されてしまいます。なぜなら、そのような組み合わせを呈する実機は存在しないからです。

GPU の識別情報から OS、フォント、ロケールに至るまで、すべての信号が一貫していることを維持する必要があります。また、トラフィックを分散させるためにこれらの要素をローテーションする際も、各要素の整合性を保ち続けることが求められます。

次に CAPTCHA の問題があります。ある程度の規模を超えると、ID がどれだけ清潔であっても、一部のセッションで検証が課されるようになります。そのため、解決パスを設け、直面している課題の種類を検知して、その回答をページ内に返す仕組みが必要です。

接続元について

完璧な ID を持っていたとしても、接続元が適切でなければ正体はバレてしまいます。2 つ目のポイントは IP アドレスに関するもので、クラウドから直接送信されるトラフィックにはデータセンターの住所が含まれるため、デフォルトの設定では即座に失敗します。主要プロバイダの IP 範囲は公開されているため、多くのサイトではページが読み込まれる段階で、それらのアドレスからのアクセスを自動化されたものとみなしてブロックしてしまいます。

これを突破するには、一般ユーザーが利用しているような住宅用 IP を経由する必要があります。これにより、ウェブ側からは通常のトラフィックとして認識されます。しかし、一歩進んで二歩下がる結果にもなりかねません。なぜなら、ここで新たな調達先と評判の問題が生じるからです。これらのアドレスはどこから入手する必要があるのか、そしてその供給元は自らの責任で保証できるものでなければなりません。また、評判も固定されたものではありません。アドレスがフラグを立てられたり、プール全体が使えなくなったり、同じプールを共有する他のユーザーのノイズによって評判が低下したりするリスクがあるためです。

IP レピュテーションは、一度購入して終わりではなく、継続的に維持する資産のようなものです。これは常に動き続ける要素の一つです。アドレスをローテーションし、フラグが立ったものは廃棄し、プールとしての容量が劣化すれば代替容量を補充し、さらにアドレスの由来を常に見直す必要があります。

これらの課題はそれぞれ独自のペースで進行します。検知システムは都合の良い時に更新され、プールは徐々に劣化していきます。今月まで機能していた ID とネットワーク構成でも、誰かがブロック率を監視して両方の要素を最新の状態に保たなければ、翌月にはブロックされるようになります。

最初の 3 つのレイヤーでエージェントがページへ到達し、行動を開始できるようになります。次の段階は、実際にその行動が行われたことを確認することです。監視できないエージェントを信頼することはできません。そのため、エージェントインフラストラクチャには「目」としてのログ機能が必要です。ブラックボックスからデバッグ可能なワークフローへと進化させるのです。

これはローカル環境ではすでに実現されています。ブラウザが目の前にあるため、フローを進める様子を直接観察でき、何か不審な点があれば開発者ツールを開いて確認できます。1 つのセッションで 1 つの画面に限定される限り、この可視性は無料で得られます。

しかしスケールすると状況は一変します。エージェントは自分が監視できないマシン上で動作し、67 ステップからなるタスクの 40 番目で失敗します。その際提示されるのは「クリックが着地しなかった」という *極めて詳細な* ログ行だけです。ボタンを処理したモーダルや、最初に発火したリダイレクトは見えません。デバッグするにはブラウザが見たものを確認する必要があり、つまりセッションの記録が必要です。しかし、これにはかなりのコストがかかります。

ビデオと DOM の比較

セッションを記録する方法には主に 2 つあり、それぞれが逆方向の弱点を抱えています。

ビデオ方式は、セッション実行中の実際のピクセルをエンコードします。レンダリングされた通りすべてを正確に捉えることができますが、多数の同時ストリームをエンコードすると、ブラウザを実行しているホスト上で CPU リソースを大量に消費してしまいます。つまり、観測機能（オバザビリティ）とファームウェアのリソース競合が生じるのです。

一方、DOM 再構築方式は、rrweb rrweb のように DOM とその変更点を記録し、後で新しいページ上で再生します。動画ではなく変更ストリームを保存するため、軽量です。しかし、実際のウェブが複雑になる領域では機能しなくなります。ネストされた iframe、シャドウ DOM、クロスオリジンのフレーム、そして Canvas はきれいに再構築されません。そのため、最もデバッグが必要なホスティングサイト上の不審なセッションほど、再生時に誤った挙動を示す可能性が高いのです。

ここでは、ユースケースに応じてどちらの失敗を受け入れるかを選ぶ必要があります。ビデオ方式は計算資源とストレージコストがかかりますが、真実を映し出します。再構築方式は安価ですが、信頼性が時折損なわれます。堅牢なシステムでは両方を併用するのが一般的で、忠実さが重要な場所にはビデオを、それ以外は再構築を採用します。つまり、1 つの記録パイプラインではなく、2 つのパイプラインを運用することになります。

なぜ起きたのか、何が起きたかを見る

ブラウザの再生機能は「ページ上で何が起こったか」を教えてくれます。しかし、エージェントにとってはそれが重要なのではありません。エージェントが行動した背景にはモデルの判断があります。そのため、実行に失敗した際にはその判断を問う必要があります。「モデルはページを読み間違えたのか」「ツールの結果が悪かったのか」、あるいは「存在しないボタンを思い込んでいたのではないか」。これらを検証するには、セッション全体に対してすべてのモデル呼び出しとツール呼び出しを追跡し、アクションを選択する瞬間のページ状態を確認できる仕組みが必要です。再生機能と追跡機能はそれぞれ物語の半分しか語らないため、両者は一つのタイムライン上に統合されなければなりません。具体的なアプローチとしては、セッションの再生記録、ネットワークログ、イベントログ、そしてモデルとツールのトレースを一つのビューに集約することです。

これらすべてのデータを意味のある期間保存・インデックス化する必要があります。フルレコーディングと、ファーム全体でのステップごとの追跡データはテラバイト規模になります。実際に必要になるのは、先週失敗した実行の古いログであることが多いでしょう。したがって、データの保持期間は極めて重要です。

ブラウザは「手」であり、モデルは「判断力」です。この判断力は、接続されたあらゆるラボへの API 呼び出しによって支えられています。ローカル環境では、SDK は一つ、キーは一つ、プロバイダーも一つで十分機能します。

しかし、スケールすると単一のプロバイダーでは不十分なケースが増えます。ステップごとに最適なモデルが異なるためです。安価で高速なモデルがルーティングを担い、高コストなモデルが複雑な推論を担当するといった使い分けが必要です。価格体系や利用制限、あるいは最先端技術そのものが毎月変化する中で、単一のモデルやラボに縛られるのは苦しいものです。

複数のエージェントを呼び出す瞬間、あなたは事実上、自社のエージェントとそれらすべてのサービス間をつなぐゲートウェイの運用を引き受けたことになります。どのフレームワークを採用していても、この事実は変わりません。

このゲートウェイを運用するには、主にいくつかの要素が重要になります。

まず挙げられるのがルーティングとキー管理です。各プロバイダーには独自の SDK、認証方式、リクエスト形式、レスポンスフォーマットが存在します。エージェントに直接各プロバイダーを接続することも可能ですが、通常は薄いラッパー（抽象化レイヤー）を設け、エージェントが単一のインターフェースを通じて通信するようにするのがベストプラクティスです。これにより、内部の 1 つの呼び出しが、そのステップで必要なラボ（モデル）へ自動的にルーティングされ、すべてのプロバイダーのキーや利用枠（クォータ）をコードベース全体に散在させるのではなく、一元管理できるようになります。

この構成は、特定のプロバイダーがダウンしている場合でも稼働し続けます。レート制限に引っかかったり、モデルの品質が低下したりしても、エージェントがタスクの最中に停止してはいけません。ゲートウェイには、指数バックオフを伴うリトライ機能や、プライマリモデルが応答しない場合に別のモデルへフォールバックする機能が備わっています。

誰もが知っている通り、コストはあっという間に膨らみます。エージェントの実行はチャット（会話）が多く、1 つのタスクを実行するために数十回のモデル呼び出しが必要になることもあります。大規模な運用（フリートボリューム）では、トークン使用量による請求額も莫大なものになります。ゲートウェイは、実行ごとのコストをメーターリングする場所であると同時に、キャッシュ戦略が効果を発揮する場所でもあります。例えば、あるステップで同じページを同じ方法で解析する処理が数千回の実行で繰り返される場合、ゲートウェイはモデルに再度呼び出すのではなく、すでに解決済みのアクションを即座に返却できます。これにより、呼び出し自体をスキップでき、レイテンシの短縮と請求額の削減という両方のメリットを得られます。素晴らしい機能ですが、その分、構築と維持の手間が増えることも事実です。

エージェントインフラストラクチャのビルダーが、モデルのパイプライン整備を行う「配管工」へと変貌する瞬間です。

では、これらを運用するには実際どれほどのコストがかかるのでしょうか。以下の数値は一例であり、中規模のファームを想定したものです。実際の数字に合わせて形状を変換すれば、そのまま適用できます。

例えば、24 時間体制で 8 つのブラウザコンテナを稼働させ、常にキャパシティを確保しているとしましょう。必要な計算リソースを考慮すると、1 コンテナあたり約 0.1 ドル/時間となります。これを 8 つ常時稼働させる場合、インフラの原価だけで年間約 5,800 ドルになります。これは請求書に明細として現れる金額であり、決して高すぎるわけではありません。

次に問題となるのがトークン数です。ファーム規模が大きくなるとモデル利用料が急増します。キャッシュ（ゲートウェイがモデルを呼び出さずに回答できる反復ステップ）の活用度合いにもよりますが、コストは計算リソースと同程度か、それ以上に膨らむ可能性があります。この規模では年間数千ドル、さらに規模が拡大すればその倍以上になるでしょう。

しかし、真に大きなコストは「これらが自動で動くわけではない」点にあります。前述した各レイヤーには、常に維持管理が必要なシステムが存在します。スケーリングが必要なウォームプール、各 CVE に対応して再パッチ適用が必要な Chromium のフォーク、 drifting するアイデンティティ、フラグが立つプール、リプレイパイプライン、そしてゲートウェイです。これらすべてを誰かが責任を持って運用する必要があります。おそらくシニアエンジニアからなるチームが必要となり、その人件費は一人あたり年間約 220,000 ドル程度になります。

もちろん、エンジニアがすべてをここで過ごすわけではありませんが、それでもかなりの割合を占めます。インフラ構築にエンジニアチームの年間作業時間の 10〜20% を割くとしても（これはかなり控えめな見積もりですが）、ブラウザの稼働維持のためにたった一人のエンジニアに年間で 22,000 ドルから 44,000 ドルの人件費がかかる計算になります。

コンプライアンスについても忘れてはいけません。ヘルスケアや金融分野で活動する場合、SOC 2 Type II や HIPAA の準拠、ペネトレーションテストの実施、データ完全消去の保証などが求められますが、これらはそれぞれ独立したプロジェクトとして立ち上げる必要があります（監査と維持管理も含まれます）。ただし、これらの対策を講じても、エージェント自体の性能が向上するわけではありません。あくまで実環境で運用するための「許可」を得るためのコストです。

ここまで説明してきたのは、自社構築時に負うべき負担の大きさを示す事例に過ぎません。だからといって、決して自社で構築すべきではないという話ではありません。スタックを自前で持つことが最適なケースも確かに存在します。

最も明確な例は、ブラウザインフラ自体が製品である場合です。ステルス機能やプロキシ、あるいは独自のブラウザプラットフォームを販売しているなら、前述の 5 つのレイヤーこそがチームが構築すべき核心となります。

それ以外の理由で自社開発を選ぶ場合は、技術的な必要性よりも戦略的な判断であることがほとんどです：

• エンジニアリングのリソースに余裕があり、自前で構築して制御権を握りたいと考えている場合。大規模なチームであれば、これを所有するコストを負担でき、明確な理由があるなら、自前構築は決して間違った選択ではありません。
• 外部プロバイダーに依存できない状況です。オンプレミスでの運用が必須だったり、外部ベンダーの導入を禁止するポリシーがあったり、データ境界の制約からすべてを自社内で完結させなければならない場合があります。こうした制約が現実的なものなら、効率性の議論はすべて無効化され、「やらざるを得ない」ため自前で構築することになります。
• 自社のハードウェア上で動かしたいという要望です。一部のチームでは、所有し完全に制御できるベアメタル上にブラウザを構築することを望んでいます。

ただし、これらの理由だけで多くのビルド判断がなされるわけではありません。実際には、「1 日目にはデモが成功した」ということがきっかけで、スケールする段階になって初めて真のコストが浮き彫りになるケースがほとんどです。「早く始めること」自体も、自前構築を正当化する十分な理由にはなりません。数回のセッションを実行して概念を検証しているプロトタイプ段階であれば、通常は購入して、プロバイダー上で Proof of Concept (PoC) を実行し、問題の規模を実際に把握した後に「ビルドか購入か」を見直すのが正解です。必要性すら不明な状態でインフラを構築して PoC を回すのは、非常に高価な作業を先送りすることになります。

ここからどう進むべきか

エージェントとオープンウェブの間に 5 つのレイヤーが存在し、それぞれが自前で構築可能であり、稼働すれば独立したシステムとして機能します。では、ビルドすべきか、それとも購入すべきか？

次に読むべきいくつかの記事をご紹介します：

⋆˚꩜｡ harsehaj