jedipunkz 🚀 のブログ

こんにちは。ジェダイパンくず🍞 です。 以前の記事 自作 Go ツールに導入したガードレール策 や Google ADK Go 2.x の Dynamic Workflow とその為のガードレール では、AI エージェントに作業させるときのガードレールをコードやワークフローの側で考えていました。一方で最近は LiteLLM 1.107.0 の PyPI パッケージ侵害 や、Cursor Marketplace で配布された Claude Code 拡張にバックドアが仕込まれた件 など、エージェントが動く開発環境そのものが狙われる事件が続いています。 そんな中で、NVIDIA の OpenShell が 0.1.x で安定したリリースサイクルに入り、Hacker News でも話題になっていました。OpenShell は「自律 AI エージェントのための安全でプライベートなランタイム」をうたうもので、エージェントが触れるファイル・ネットワーク・API をポリシーで宣言し、カーネルレベルで強制します。README を読むだけでは実際にどこまで防げるのかが分からなかったので、サンプル環境を作って手を動かしてみました。 コードは下記に置いてあります。 https://github.com/jedipunkz/openshell-playground 検証したバージョンは OpenShell v0.1.6、環境は macOS + Docker Desktop です。 結論 試したこと 結果 ポリシーを指定せずに外へ通信 TCP も DNS もすべて拒否される GitHub API を GET のみ許可 GET は通り、POST は L7 で 403 になる。ルール追加は再起動不要 credential を provider 経由で渡す エージェントには placeholder しか見えず、紐付けた宛先にだけ本物の値が送られる 窃取スクリプトの模擬 外部送信・許可ホストへの POST・別バイナリからの通信・metadata 参照・許可外パスへの読み書きは拒否される。書き込み可能な workspace への永続化は防げない policy prover 上限ポリシーを超える変更を反例付きで検出できる。CI に組み込める 「エージェントが何を持ち出せて、どこに送れるか」をホスト・メソッド・バイナリ単位で絞り込めて、その判定がすべてログに残るのが OpenShell の価値だと感じました。逆に、許可した範囲の中で何が起きるかまでは面倒を見てくれないので、workspace の扱いは別途考える必要があります。 ...

こんにちは。ジェダイパンくず🍞 です。 以前の記事 自前開発した 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 のコンテキストには最終結果しか入りません。 ...

前編 では、テーブル駆動テストからカバレッジまで、コードが正しく動くことを確かめるテストの書き方を整理しました。後編では、正しさ以外のことを確かめるテストを扱います。 性能: ベンチマーク、サブベンチマーク 堅牢性: Fuzzing 時間: testing/synctest 前編と同じく Go 1.27 を前提にしていて、実行結果は Go 1.27.1 で実行したものです。ベンチマークの数値は実行環境によって変わります。 コードは以下のレポジトリにあります。 https://github.com/jedipunkz/go-playground/tree/main/testing パターン9: ベンチマーク func BenchmarkXxx(b *testing.B) という関数を書き、go test -bench で処理時間とメモリ割り当てを計測するパターンです。 使い所 「+ で文字列を連結するより strings.Builder の方が速い」とよく言われますが、自分のユースケースでどれくらい差があるのかは、測ってみないと分かりません。ベンチマークを書いておけば、実装を選ぶときや性能改善をしたときに、効果を数値で確認できます。 テスト対象として、文字列を連結する 2 つの実装を用意しました。 package concat import "strings" // Plus は + 演算子で文字列を連結する func Plus(words []string) string { s := "" for _, w := range words { s += w } return s } // Builder は strings.Builder で文字列を連結する func Builder(words []string) string { var sb strings.Builder for _, w := range words { sb.WriteString(w) } return sb.String() } ベンチマークは for b.Loop() { ... } の中に計測したい処理を書きます。 ...

Go の再学習を続けています。今回はテストです。テーブル駆動テストやサブテスト、ベンチマークは普段から書いているのですが、それ以外にどんな書き方や機能があるのかを網羅的には把握できていませんでした。そこで標準の testing パッケージ周りを一通り調べ直し、前編・後編の 2 本にまとめることにしました。 前編 (この記事): 正しさを確かめる。テーブル駆動テスト、サブテスト、並列実行、テストヘルパー、テストダブル、httptest、Example テスト、カバレッジ 後編: 性能・堅牢性を確かめる。ベンチマーク、サブベンチマーク、Fuzzing、testing/synctest Go 1.27 を前提にしていて、古いバージョンとの違いには触れません。実行結果は Go 1.27.1 で実行したものです。 コードは以下のレポジトリにあります。 https://github.com/jedipunkz/go-playground/tree/main/testing Go のテストの基本 Go のテストは標準の testing パッケージと go test コマンドだけで書けます。ルールは次の 3 つです。 テストコードは xxx_test.go という名前のファイルに書く テスト関数は func TestXxx(t *testing.T) という形にする 失敗を報告するには t.Error / t.Errorf か t.Fatal / t.Fatalf を呼ぶ t.Error と t.Fatal の違いは重要です。t.Error は失敗を記録してテスト関数の実行を続けますが、t.Fatal は失敗を記録した時点でそのテスト関数を終了します。この違いがパターン 2 の話につながります。 この記事では、次の割り算の関数をテスト対象にして説明を始めます。 package calc import "errors" var ErrDivideByZero = errors.New("divide by zero") // Div は a を b で割った結果を返す func Div(a, b int) (int, error) { if b == 0 { return 0, ErrDivideByZero } return a / b, nil } よく使う go test のオプションは以下です。 ...

こんにちは。ジェダイパンくず☁️ です。 以前 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 は「現実の障害対応にどこまで近づけるか」を測る方向に振っています。 ...

こんにちは @jedipunkz です。 自作ツールの gm を Go から Rust に書き換えたことをきっかけに、Rust の構文を網羅的に理解する必要性を感じてサンプルコードを作成し動作確認した上で構文集を作成しました。この記事では Rust の主要な構文をまとめたいと思います。 サンプルコードは Rust 1.98 / Edition 2024 で動作確認しています。各コードは fn main() を含む単体のプログラムなので、rustc --edition 2024 main.rs でそのまま実行できます (非同期の節のみ tokio クレートを使います)。 ※ 気が向いたときに新しい構文が出てきた際に更新し続ける記事にしようと思っています。 目次 1. 基本的な型システム スカラー型 変数と可変性 型注釈と型推論 型変換 型エイリアス 2. 複合型 タプルと配列 文字列 構造体 列挙型 Option と Result 3. 制御フロー 条件分岐とループ パターンマッチ if let と let else と let チェーン 4. 所有権と借用 所有権とムーブ 参照と借用 ライフタイム 5. 関数とクロージャ 関数の定義 クロージャ 6. メソッドとトレイト impl ブロック トレイトの定義と実装 スーパートレイトとトレイトオブジェクト derive と標準トレイト 演算子オーバーロード 7. ジェネリクス ジェネリクスの基本 トレイト境界 関連型と const ジェネリクス 8. エラーハンドリング 独自のエラー型と ? 演算子 main から Result を返す 9. コレクションとイテレータ Vec HashMap と HashSet イテレータ 独自のイテレータ 10. スマートポインタ Box と Rc と RefCell 11. 並行処理と非同期 スレッド async と await 12. モジュール モジュールと可視性 クレートと Cargo 13. 高度な機能 マクロ 属性 テスト unsafe 基本的な型システム Rust は静的型付け言語で、すべての値の型がコンパイル時に決まります。型推論が強力なため、多くの場合は型を書かずに済みます。 ...