Blog

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 システムの設計に広く適用できるかと思います。

今月に入り CNCF（Cloud Native Computing Foundation）が認定する 5 つの Kubernetes 関連資格を全て制覇し、Kubestronaut の称号を獲得しました。Kubernetes 認定資格はここ数年で試験内容のアップデートが続いており、日本語の具体的な攻略記事がまだまだ少ないと感じたため本記事を執筆することにしました。Kubestronaut の称号を得ることは、Kubernetes に関して運用・開発・セキュリティといったあらゆる側面から深く理解していることの証明になります。今回のブログでは、Kubernetes に興味を持っている方、実際に Kubestronaut を目標にしている方に向けて、私が実践した学習ロードマップや準備のプロセス、高得点を狙うための試験対策についてまとめたいと思います。本記事の内容は 2026 年 2 月時点のものです。試験内容は頻繁にアップデートされるため、受験の際は必ず公式サイトで最新の試験ガイドを確認してください。

CPU 使用率 > 80%、エラー数 > N 件といった、閾値ベースのアラートはユーザ影響との相関が薄く、ノイズの原因になりやすい設計です。一方で、ノイズを減らすために閾値を緩くすると、今度は Error Budget を着実に消費する緩やかな劣化を見逃します。SLO ベースのアラートは Error Budget がどれだけの速度で消費されているか を監視することで、この問題に対処します。Google SRE Workbook の Chapter 5: Alerting on SLOs では、このアプローチを 6 つの戦略で段階的に説明しています。今回のブログでは、Alerting on SLOs の内容に基づき、6 つの戦略を Precision・Recall・Detection Time・Reset Time の 4 属性で順に比較しながら、なぜ Multiwindow / Multi-Burn-Rate 戦略が推奨されるのかを整理してみたいと思います。SLI・SLO・Error Budget の基礎概念については こちらのブログ で紹介しています。

OpenTelemetry Collector はテレメトリデータを効率的に送信するためにデータをバッチ化する仕組みを備えています。従来、この役割は Batch Processor と呼ばれる Processor のコンポーネントが担っており、全ての Collector に設定することが推奨されていました。一方で、Batch Processor はエクスポート失敗時にバッチ全体がドロップされる問題や、gRPC の ResourceExhausted エラー等、本番運用においていくつかの深刻な課題が顕在化していました。これを受け、コアメンテナの Bogdan 氏はバッチ処理を Exporter レイヤへ移行することを提案しました。2026 年 1 月現在、Batch Processor は非推奨化となり、後継である Exporter Helper の sending_queue にバッチ機能が統合されています。今回のブログでは Batch Processor から Exporter Helper へのバッチ機能移行について紹介したいと思います。