Blog

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

今月に入り 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 の基礎概念については こちらのブログ で紹介しています。