SRE

こんにちは。ジェダイパンくず🍞 です。 以前の記事 自前開発した Prometheus Exporter で自宅ルータのメトリクス監視運用している話 や Prometheus Exporter 開発で Discord サーバ運営の健全化を図る では、Go で Prometheus Exporter を書いて Prometheus Server に scrape させていました。 最近は Grafana のエージェントとして Grafana Alloy を使う構成が増えています。Alloy は Prometheus の scrape や remote_write、OpenTelemetry、ログ収集などを 1 つのバイナリで扱えるテレメトリコレクタで、prometheus.exporter.* という形で多くの exporter を内蔵しています。そこで「自作 exporter を Alloy の世界に持ち込むにはどうするのか」「Alloy の component そのものを Go で書けるのか」を調べて、実際に手を動かしてみました。 コードは下記に置いてあります。 https://github.com/jedipunkz/alloy-playground 結論 自作のメトリクスを Alloy で扱う方法は大きく 2 つあります。 パターン 内容 A: 独立 exporter + prometheus.scrape 従来通り Go で exporter を書き、公式の Alloy から HTTP で scrape する B: Alloy を fork して component を追加 Alloy のソースツリーに internal/component/prometheus/exporter/<name> を足してビルドする Alloy の component は Go で書けます。ただし Alloy にはプラグイン機構が無く、exporter 系 component が使う API は internal/ 配下にあるため、パターン B は Alloy を fork してビルドするしかありません。自分のサービス向けの独自メトリクスであれば、運用コストの低いパターン A を選ぶのが良さそうだと感じました。 ...

こんにちは。ジェダイパンくず🚀 です。 以前の記事 Go によるコマンド履歴・ファイル・Git ブランチ/Worktree/コミットを検索する Fish Plugin 開発 で紹介した fuzz.fish は、Fish shell のコマンド履歴・ファイル・Git ブランチなどをファジー検索する Fish plugin です。plugin ですが、検索と TUI の本体は Go で実装していて、Fish 側のスクリプト（conf.d/fuzz.fish）はキーバインドの登録と Go バイナリの呼び出しだけを担っています。このツールを自分で毎日使いながら一人で開発・運用しています。最近はコードの大半を Claude Code や opencode といった AI agent に書いてもらっていて、自分はレビューとマージが中心です。 この開発スタイルで一番気になっていたのは、LLM に何を意識させ続けられるかでした。具体的には次の 4 つです。 セキュリティ: シェルに文字列を渡して実行する箇所や、サプライチェーンに穴を開けないこと バグ混入: 既存の挙動を壊さないこと、テストを減らさないこと パフォーマンス: キー入力のたびに走るフィルタ処理を遅くしないこと 設計思想: パッケージの依存方向や Bubble Tea の Model / Update / View の分担を崩さないこと これらは CLAUDE.md に書いてあります。ただ、プロンプトに書いたルールは守られる保証がありませんし、一度守られても次の変更では忘れられます。チームであれば他のメンバーのレビューで拾えることも、一人だと自分が見落とした時点で main に入ってしまいます。 そこで「ルールは CLAUDE.md で宣言し、違反は linter と CI で機械的に落とす」という方針でガードレールを 17 件 issue 化して実装しました。この記事はその記録です。 方針: 宣言 → 可視化 → gate 化 ガードレールは次の 3 段階で考えました。 ...

こんにちは。ジェダイパンくず🚀 です。 前回の記事 ADK Go 2.0 のグラフワークフローを読んで SRE Agent への応用を考える の最後に、こんな宿題を残していました。 インシデント対応は「調べて、分からなかったらもう少し調べる」という反復が本質なので、完全に静的なグラフでは表現しきれない部分があります。NewDynamicNode で調査ループを書き、確定した対処だけを静的グラフに戻す、というハイブリッドが現実解な気がしていますが、そうすると動的ノードの中身が結局ブラックボックスになるジレンマがあります。 その後、Claude Agent SDK の agent loop や、Claude Code の dynamic workflows を眺めていて、「自律的に、動的に回るループ」を Google の Agent Development Kit（ADK）でやるとどうなるのかが気になりました。結論を先に書くと、ループそのものは ADK でも回せます。ただし止める仕組みは自分で書く必要があります。この記事はその「止める仕組み」、つまりガードレールの話です。 記事中のコードは jedipunkz/adk-playground の investigation-loop にあり、ADK Go v2.5.0（2026-09-30 リリース）で go vet とテストを通しています。 「ループ」は 2 種類ある 最初に整理しておきたいのは、「自律的なループ」と言ったときに 2 つの別のものが混ざりがちだという点です。 Claude 側 ADK Go 側 agent loop（1 エージェントの中で、モデル → ツール → モデルを繰り返す） Claude Agent SDK の query() llmagent オーケストレーションのループ（エージェントを何度も呼び、結果を見て次を決める） Claude Code の dynamic workflows（loop until done パターン） workflow.NewDynamicNode Claude Code の dynamic workflows は、Claude 自身が JavaScript のオーケストレーション用スクリプトを書き、ランタイムがそれをバックグラウンドで実行する機能です。スクリプトの中では agent() でサブエージェントを起動し、parallel() / pipeline() で fan-out します。ループ・分岐・途中結果はスクリプトの変数が持つので、Claude のコンテキストには最終結果しか入りません。 ...

こんにちは。ジェダイパンくず☁️ です。 以前 2026年6月現時点において SRE がどう AI に向き合っているか調べてみた や Google が提唱する AI in SRE とは何か で、AI SRE エージェントの動向や Google の評価フレームワークについて書きました。その後 ADK Go 2.0 のグラフワークフローを読んで SRE Agent への応用を考える で、実際にインシデントトリアージのワークフローも書いてみています。 ここまでやってみて、ずっと引っかかっていたのが「で、そのエージェントはどれくらい正しく原因を当てられるの？」という問いです。ベンダーの発表では「MTTR が何割短縮」といった数字がよく出てきますが、その多くは自社インフラ上での自己申告で、横並びで比較できるものではありません。 そこで 2026 年に出た AI SRE エージェント向けの評価ベンチマーク 4 本を読んでみました。 OpenRCA 2.0 ORCA-bench Cloud-OpsBench SREGym 読んでみると、4 本ともアプローチは違うのに、エージェントが間違えるパターンについてはほぼ同じことを言っていて面白かったです。本記事では、各ベンチマークの中身、各論文が挙げる課題と解決策、そして自分で SRE エージェントを作るときに持ち帰れることを整理します。 なお 4 本ともプレプリント (arXiv) で、数値は論文に書かれたものをそのまま引用しています。 4 本の全体像 4 本とも「LLM エージェントは障害の root cause を特定できるか」という同じ問いを扱っていますが、何をエージェントに渡して、何を採点するかが違います。 ベンチマーク エージェントに渡すもの 採点の重点 規模 OpenRCA 2.0 静的なテレメトリ (trace / metrics / log) 答えに加えて、原因から症状までの伝播経路 500 件 ORCA-bench 曖昧なユーザー報告 + Grafana 経由の 6 日分テレメトリ + ソースコード on-call に近い条件で当てられるか 1,079 タスク Cloud-OpsBench 障害時の Kubernetes 状態を固めた snapshot を、診断ツール経由で調査 答えに加えて、必要な証拠を集めたか 754 件 SREGym 動いている Kubernetes 環境 診断に加えて、修復まで完了できるか 90 問 ざっくり言うと、OpenRCA 2.0 と Cloud-OpsBench は「答えが合っていても根拠が伴っているか」を測る方向、ORCA-bench と SREGym は「現実の障害対応にどこまで近づけるか」を測る方向に振っています。 ...

こんにちは。ジェダイパンくず☁️ です。 2026年6月30日に ADK (Agent Development Kit) for Go の 2.0 がリリースされました。目玉は「グラフベースのワークフローエンジン」で、エージェントアプリケーションをノードとエッジのグラフとして記述するという方向に大きく舵を切っています。 自分がこのリリースで一番興味を持ったのは、公式サンプルの examples/workflow/routing/llm/ に書かれていたこのコメントでした。 // This is the canonical "LLM as the brain, engine does the routing" pattern. LLM は「脳」であって「ルータ」ではない、分岐そのものはエンジン（＝決定的なコード）が担う、という設計思想です。これは SRE のインシデント対応エージェントを考える上でかなり本質的な話に見えたので、リポジトリを実際に clone して公式サンプルを読み、さらに自分でインシデントトリアージのワークフローを書いてビルド・実行するところまでやってみました。 この記事は以下の三本柱で構成します。 ADK の基本（そもそも ADK でエージェントをどう書くのか） 2.0 の新機能（グラフワークフローエンジンを中心に） SRE Agent における応用（実際に動くコードを書いてみた） なお、記事中のコードはすべて google/adk-go の実際のサンプルか、自分で書いて go vet とビルド・実行を通したものです。 ADK の基本 インストール 2.0 からモジュールパスが google.golang.org/adk/v2 に変わりました。Go 1.25 以上が必要です。 go get google.golang.org/adk/v2 最小のエージェント ADK の世界観は「エージェント = モデル + 指示 + ツール」です。公式の examples/quickstart/main.go がその最小形です。 ...

こんにちは。ジェダイパンくず☁️ です。 Google SRE チームが公開したレポート「AI in SRE: How Google is Engineering the Future of Reliable Operations」を読んで、その内容を体系的にまとめました。著者は Ioannis Papapanagiotou、Stevan Malesevic、Chris Heiser、Ruslan Meshenberg の4名です。 読んでみて感じたのは、これは単なる「AI でアラートを減らそう」という効率化の話ではない、ということです。SRE そのものが AI によって構造的に変容していく過程を、具体的なシステム名・フレームワーク・測定結果を交えて論じた内容になっています。以前 2026年6月現時点において SRE がどう AI に向き合っているか調べてみた という記事で業界全体の動向を俯瞰しましたが、この Google のレポートはその中でも「いつ・どこまで自律度を上げるか」をデータで決める仕組みまで踏み込んでいる点で抜きん出ています。本記事ではその設計思想を順を追って整理します。 なお本記事の後半、具体的な方法論を扱う章には「自分たちの現場での実践方法考案」という節を添えました。自分たちの現場では現時点では Google Cloud + Datadog + AWS というプラットフォームで構成されていて、Google ほどの規模はありません。なので Google が内製した仕組みを、なるべくプロダクトを利用する方向に反転させて考えています。その最有力候補が、DASH 2026 で AI 機能を大きく広げた Datadog の Bits シリーズです。後半の具体論に対して「これは Google だから出来ることなのか？日本のスタートアップでも現実的に回せるのか」を考えていきます。 AI in SRE とはどのような概念なのか AI 支援開発によって生産性が最大4倍向上することを目指す組織が急増しています。それ自体は良いことなのですが、問題はその先にあります。コードレビューや運用プロセスという「人間がボトルネック」になる部分は、コード生成と同じ速度では4倍速になりません。AI 生成コードの量に対して従来のコードレビュー手法はスケールせず、システム複雑性の急速な増加に標準的な運用プロセスが追いつかない、という歪みが顕在化します。 Google SRE はこの課題に対して、AI を既存業務に貼り付けるのではなく、信頼性の基盤そのものを作り直すという立場を取っています。 “SRE is architecting a new foundation for reliability” ...

こんにちは。@jedipunkz です。 2026年6月現時点において、SRE の領域で AI はどう活用されているのか、世の中の SRE はどのように AI に向き合っているのか気になり調査を行いました。普段自分は具体の技術に興味がある人間なのであまりこういう抽象的な話は好まないのですが、AI の進化はここ数ヶ月でも激しく推進しているので SRE の活動にも変化が生じているだろうと気になり調査した次第です（本記事は 5 月に書いたものを 6 月時点の動向で更新しています）。 ここ数ヶ月でひとつ大きかったのは、AI SRE がひとつの独立した市場カテゴリとして認知されたことです。Gartner は 2026 年初頭に初の Market Guide for AI Site Reliability Engineering Tooling を公開し、2029 年までに 85% の企業が AI SRE ツールを運用に使うようになる（2025 年時点では 5% 未満）と予測しています (Komodor)。Komodor、CAST AI、Firefly などが Representative Vendor として挙げられ、加えて Microsoft は Azure SRE Agent を 2026 年 3 月 10 日に GA しています。実験段階のツールが乱立する状態から、評価軸や代表的プレイヤーが定まりつつある段階に移ったと言えそうです。 AI SRE の分類 調査の結果、AI を SRE 領域に適用するアプローチは概ね以下の施策に分類できました。 1. AI によるインシデントトリアージと原因分析 最も広く普及しているアプローチが AI によるインシデント対応です。AI はログ、メトリクス、トレース、変更履歴、過去インシデントという情報を横断的に相関させ、「何が起きているか」だけでなく「なぜ起きたか」という原因候補を提示します。 ...