「エージェントにシークレットを持たせない」— Browser-UseがAWS Bedrock AgentCoreで構築した数百万エージェント実行基盤の設計

7月12日、Browser-Useが「How We Built Secure, Scalable Agent Infrastructure with AWS Bedrock AgentCore」と題した記事を公開した。本番環境で数百万のAIエージェントを実行しているBrowser-Useが、そのランタイム層をAWS Bedrock AgentCoreへ移行した経緯と、ゼロシークレット原則に基づく設計の全貌を明かしている。

Browser-Useは、AIエージェントがWebブラウザを自動操作できるPaaS型のサービスだ。ユーザーの指示をもとにエージェントがブラウザセッションを起動し、フォーム入力・情報収集・RPA的なタスクをクラウド上で代行する。各エージェントはプライベートなマイクロVM上で動作し、VMにはクレデンシャル（認証情報）を一切持たせない設計を採用している。この設計思想の根幹は半年前のブログ記事で解説済みだが、今回はそのランタイム層をAWS Bedrock AgentCoreへ移行した経緯と具体的な実装が明かされている。

AWS Bedrock AgentCoreは、2025年に発表されたAWSのマネージドエージェントランタイムサービスだ。AIエージェントのセッション管理・スケーリング・ストレージといったインフラ層をAWSが担い、開発者はエージェントのロジックに集中できる。

「エージェントに盗まれるものを持たせない」設計

このアーキテクチャの核心は、ゼロシークレット原則にある。

エージェントが動くマイクロVMのIAMロールには最小限の権限しか与えられていない。ECRからイメージをpullし、CloudWatchにログを書くだけだ。S3、データベース、その他のAWS APIには直接触れない。アウトバウンドの通信もコントロールプレーンとパブリックHTTPSのみに絞られている。

VMにはシークレットを一切埋め込まない。ランタイムが保持するのはコントロールプレーンのURLだけで、セッショントークンやセッションIDなどの情報は /invocations ペイロードでリクエストごとに渡される。リクエストが終われば、VM上には何も残らない。

コントロールプレーンがクレデンシャルの門番になる

エージェントがLLMを呼び出す際も、ファイルをS3にアップロードする際も、すべての通信はコントロールプレーンを経由する。エージェントがAWSの実際のAPIキーを見ることは一切ない。

LLMプロキシの仕組みはシンプルだ。エージェントのSDKは通常通りプロバイダーのエンドポイントを呼び出すが、ベースURLがコントロールプレーン（/api/v4/llm/anthropic/v1、/api/v4/llm/openai/v1など）に向いている。コントロールプレーンはセッショントークンを検証し、本物のAPIキーに差し替えて上流プロバイダーに転送する。レスポンスは逆の経路で戻ってくるが、実際のAPIキーはサンドボックスに届かない。コスト上限の管理や課金処理もこの経路上で行われる。

ファイルアクセスも同様の仕組みだ。エージェントがファイルをS3と授受する場合、コントロールプレーンにプリサインドURLを発行してもらい、そのURLを使ってHTTPS経由でやり取りする。AgentCoreのセッションストレージにより、各セッションには独立したワークスペース（/mnt/workspace）が割り当てられ、セッションの停止・再開をまたいで状態が保持される。

スパイク需要に追従するエラスティックスケール

Browser-Useのワークロードは典型的なスパイク型だ。静かな時間帯が続いたかと思うと、数千の同時エージェントセッションが短時間で立ち上がる。

固定フリート構成では、ピークに合わせてサイジングすれば平時のコストが無駄になり、平均に合わせればスパイク時にリクエストが詰まる。AgentCoreは各セッションをプリミティブとして扱い、オンデマンドで起動し、アイドル時には停止する。課金は実行時間分だけだ。

コントロールプレーンはECS FargateのプライベートサブネットでALBの背後に置かれ、CPU使用率に基づいてオートスケールする。サンドボックス側はAgentCoreが独立してスケジューリングする。各レイヤーが自分のボトルネックに応じて独立してスケールする構造だ。

boto3の2つのAPIコールで動く

実装面では、AgentCoreとのインテグレーションは bedrock-agentcore クライアントへの2種類のboto3呼び出しで完結している。

# エージェントセッションにタスクをディスパッチ
client.invoke_agent_runtime(
    agentRuntimeArn=RUNTIME_ARN,
    runtimeSessionId=session_id,
    payload=json.dumps(invocation).encode(),
    contentType="application/json",
    accept="application/json",
)

# 実行中のセッションを強制終了
client.stop_runtime_session(
    agentRuntimeArn=RUNTIME_ARN,
    runtimeSessionId=session_id,
)

セッションのコンテキストはVMの環境変数ではなく /invocations ペイロードで渡されるため、同一VMで実行される2つのタスクがまったく異なるコンテキストを持つことができ、どちらもリクエスト完了後には残らない。

本番運用で重要なパラメータは2つ：アイドルタイムアウト（15分）と最大ライフタイム（8時間）だ。Terraformでは aws_bedrockagentcore_agent_runtime リソース1つと標準的な実行ロールの定義で管理されている。

まとめ

「エージェントに盗む価値のあるものを持たせず、保存する価値のあるものも持たせない」という設計原則は変わっていない。変わったのは、ランタイム層もAWSネイティブになったことだ。IAM、VPC、S3、CloudWatchで統一されたスタックは、運用上の「異物」を排除する。

このアーキテクチャが示す示唆は、Browser-Use固有の話にとどまらない。エージェントが長時間・大量に動作する時代において、「エージェント自身に何を持たせるか」という設計判断はセキュリティと運用コストの両面で重要性を増している。コントロールプレーンをクレデンシャルの集約点として機能させ、エージェントランタイムは使い捨て前提で設計するというパターンは、マルチエージェント基盤を構築するうえで今後広く参照されるアーキテクチャになり得る。※編集部の考察

詳細はHow We Built Secure, Scalable Agent Infrastructure with AWS Bedrock AgentCoreを参照していただきたい。