Blog

Cloud Run Job はリスニングポートを持たず、外部からのインバウンド接続を受け付けることができません。 この制約はバッチ処理や CI ジョブといったワンショットなタスクでは問題になりませんが、Job 内でブラウザのリモート表示や映像ストリーミングのような双方向通信が必要な場面では課題が生じます。直感的な解決策として Job の中でも HTTP サーバを立ち上げるという発想が浮かぶかもしれませんが、Cloud Run Job のコンテナには外部からアクセスできるエンドポイント（URL）が割り当てられないため、ポートをバインドしてもブラウザからそのポートに到達できません。そこで Job 側から専用の中継サーバへアウトバウンド接続を確立させ、中継サーバがブラウザとの通信を橋渡しするアーキテクチャ（以後 Relay パターンと呼ぶ）を取ります。今回のブログでは、Job 内で動作するブラウザの画面をリモートストリーミングするユースケース（一時的に仮想ブラウザを起動して完了後は破棄したい）を例に、Relay パターンで Cloud Run Job の WebSocket 双方向通信を実現する方法について紹介したいと思います。

rrweb は Web アプリケーション上のユーザ操作をブラウザレベルで記録・再現できる OSS ライブラリです。 一般にデバッグや不具合追跡の際に、スクリーンショットや画面録画を用いることがありますが、これらから DOM の状態や入力値の詳細を正確に把握するのは困難です。rrweb はページ全体の DOM をスナップショットとして記録し、以降の変化は差分イベントとして追記します。 クリックや入力操作、ページ遷移といったユーザ操作から DOM の変化まで、ブラウザイベントを構造化されたフォーマット（JSON）で丸ごと保存・取得できます。この仕組みはモニタリング・分析プロダクトのブラウザ操作記録機能のバックエンドとして広く採用されており、有名どころでは Datadog RUM、LogRocket、PostHog、Sentry の Session Replay でバグ再現やユーザ行動の分析に活用されています。今回のブログでは、rrweb の概要や取得できるイベント、内部構造について整理した上で、実際に記録したデータからユーザ操作を抽出するための実装例を紹介したいと思います。

Datadog Agent を v7.66 から v7.76 にアップグレードしたところ、agent コンテナの CPU 使用率が 2〜3 倍に急増する問題を引きました。影響は istio-proxy が多数稼働するノードに集中しており、Agent が内部で利用する Python ベースの prometheus-client ライブラリのパーサ回帰によって、Prometheus テキスト形式のパース処理コストが大幅に増大したことが原因でした。今回のブログでは flare を使った原因の絞り込み方、パーサ回帰の技術的な詳細と特定の環境で影響が顕著になった理由、現時点でのコミュニティの認識と対応方針について整理したいと思います。

Playwright や Selenium に代表される従来のブラウザ操作ツールは、人間がテストコードを書くことを前提に設計されています。これらのツールを使うには CSS セレクタや XPath で要素を特定し、TypeScript や Python でスクリプトを記述するプロセスが必要です。AI エージェントにこのアプローチを取らせると、構造的な問題が生じます。LLM はページの DOM を直接参照できないため、input[type='search'] や .hamburger-icon といった CSS セレクタを一般的な知識から推測して生成することになりますが、一般にサイト構造はプロジェクト毎に異なるため、推測ベースのセレクタは高い確率で失敗します。加えて、コードを生成・実行し、エラーを解釈して修正するサイクルはトークンを浪費する課題もあります。Vercel が公開した agent-browser はこうした課題に対して CSS セレクタの推測自体を不要にするアプローチを取っています。agent-browser はページのアクセシビリティツリーからインタラクティブ要素を抽出し、@e1、@e2 のような Refs と呼ばれる参照を割り当てます。LLM はコードを書く代わりに、この Refs を対象とした click @e1、fill @e2 "text" のようなシンプルなコマンドを実行するだけでブラウザを操作できます。今回のブログでは、agent-browser の Refs やセマンティックロケータといった基本概念を整理した上で、内部アーキテクチャやトークン削減の仕組みを深掘りしてみたいと思います。

LLM を中心とした Agent システムの実装では、ReAct パターン・ToolUse・MCP・AgentLoop・Guardrails といった多くの設計概念が登場します。これらの概念はそれぞれ独立したものではなく、Agent がゴールに向かって自律的に動作するための仕組みとして互いに依存しています。例えば、LLM がツールを呼び出す ToolUse は、どのツールをどの順番で呼ぶかを決める ReAct パターンの中で動作し、ツール呼び出しの結果を次の判断に使う AgentLoop の一部として機能します。MCP はツール定義のインターフェースを標準化し、Guardrails は AgentLoop の各イテレーションで出力の安全性を検証します。こうした概念間の関係を把握しないまま個別に導入すると、設計の全体像が見えず、どこに何を組み込めばよいかの判断が難しくなります。今回のブログではこれらの概念を以下の 4 つのカテゴリに分類し、Agent システムの Orchestrator を軸にそれぞれの役割と関係を整理してみたいと思います。なお、このブログでは、AIAgent によるブラウザ操作の自動化を具体例として取り上げますが、各概念は汎用的な Agent システムの設計に広く適用できるかと思います。