Posts

こんにちは。ジェダイパンくず☁️ です。 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 がその最小形です。 ...

こんにちは。ジェダイパンくず☁️ です。 RAG (Retrieval Augmented Generation) という言葉はよく聞く様になったものの最初はどこからどこまでが RAG システムの責務なのかが分かりにくいと感じていました。「検索含め AI が勝手に全部やってくれるのでは？」もしくは「あくまでの検索結果を返すだけなのか？」等。そこで RAG を段階的に理解するための学習用環境を2つ作って理解する作業を行いました。ここではそれを順に説明しようと思います。 コードは下記に置いてあります。 https://github.com/jedipunkz/rag-playground 構成名 フォルダ名 構成内容 検索のみ構成 retrieve-only LLM 無し構成。Go のハッシュベース埋め込み + PostgreSQL(pgvector) で検索だけを行う LLM を使った構成 full-rag-ollama Ollama (all-minilm / llama3.2) + PostgreSQL(pgvector) で検索からプロンプト化、回答生成まで行う 2つの構成図 まず両者の構成を図で示します。 検索のみの構成 (フォルダ名: retrieve-only) flowchart LR M[Markdown files] --> L[load command<br/>Go] L -->|1 chunk + embed| P[(PostgreSQL<br/>pgvector)] U[curl / browser] -->|2 /search| S[search app<br/>Go HTTP API] S -->|3 embed query + vector search| P P -->|4 top-k chunks| S S -->|5 JSON results| U load コマンドが Markdown をチャンクに分割し、ベクトル化して PostgreSQL(pgvector) に保存する ユーザーが curl で /search?q=... を呼び出す search アプリがクエリを同じ方法でベクトル化し、pgvector で cosine 距離の近いチャンクを検索する PostgreSQL が近い順に top-k チャンクを返す search アプリが検索結果を JSON で返す LLM を使った構成 (フォルダ名: full-rag-ollama) flowchart LR M[Markdown files] --> L[load command<br/>Go] L -->|1 embed chunks| O[Ollama<br/>all-minilm] L -->|1 save chunks + vectors| P[(PostgreSQL<br/>pgvector)] U[curl / browser] -->|2 /answer| A[app<br/>Go HTTP API] A -->|3 embed query| O A -->|4 Retrieve| P P -->|top-k chunks| A A -->|5 Augment| PR[/prompt/] PR -->|6 Generate| G[Ollama<br/>llama3.2] G -->|answer| A A -->|7 JSON answer + sources| U load コマンドが Markdown をチャンクに分割し、Ollama (all-minilm) でベクトル化して PostgreSQL(pgvector) に保存する ユーザーが curl で /answer?q=... を呼び出す app がクエリを Ollama (all-minilm) でベクトル化する app が pgvector で近いチャンクを検索し、top-k チャンクを受け取る (Retrieve) app が質問と検索結果からプロンプトを組み立てる (Augment) app がプロンプトを Ollama (llama3.2) に渡し、LLM が回答を生成する (Generate) app が回答と根拠チャンクを JSON で返す 見比べると、LLM を使った構成は検索のみの構成に Ollama を足し、検索結果をプロンプト化して LLM に渡す経路が増えているだけ、というのが分かると思います。この「増えた部分」が RAG の Augment と Generate に相当します。それらについて次の項目で説明します。 ...

こんにちは。ジェダイパンくず☁️ です。 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🚀 です。 HackerNews を毎日読みたいのですが、昔は狂ったように巡回していたものの最近は厳しく英語も何だか疲れてしまうし、そして1日に流れてくる記事数が多すぎて自分の関心領域（SRE / Platform Engineering / AI）に絞り込むのが面倒、という課題がありました。そこで「興味のある記事だけを日本語に翻訳し、AI でサマライズして RSS リーダーに流す」パイプラインを作りました。ポイントは、翻訳・要約・ホスティングまで含めてすべて無料サービスだけで完結している点です。 全体アーキテクチャ パイプラインは下記のように、クロール → 翻訳 → AI 要約 → RSS 配信という流れになっています。 (1) HackerNews をクロール (GitHub Actions + Go + Algolia API) (2) contents/YYYY-MM-DD/*.md として保存 (Google Tranalate) (3) AI 翻訳 (GitHub Models - gpt-4o-mini (4) summaries/YYYY-MM-DD.json 保存 (5) Astro ビルド -> rss.xml 配信 (Vercel) クロールと要約は2つの GitHub Actions ワークフローに分かれていて、前者の完了をトリガーに後者が走るようにしています。要約結果の JSON が main に push されると Vercel が自動でビルドし、RSS が更新されます。 1. クロールと翻訳（GitHub Actions + Go） 最初のステップは HackerNews からの記事取得です。これは Go で書いたツールが担当しています。HackerNews 公式 API ではなく Algolia の HN Search API を使うことで、期間指定や検索が簡単になります。API キーは不要です。 ...

jedipunkz🚀 です。 最初に、これから書く仕組みの完成イメージとして、実際に scrape 処理が走っている動画を貼っておきます。docker compose up scheduler で Go 製スクレイパーが PhilArchive / PhilPapers / arXiv を巡回し、inbox/ 配下に Scrape 結果が次々と書き出されていく様子です。 個人で哲学者・著作ごとのノートを管理しているのですが Notebook LM や Claude Cowork を使い色々と試してきたものの下記の点を課題として持っていました。 新しい情報源の取得の自動化 モバイルアプリでの記事の整理 そこで、Go 製スクレイパーを Docker Compose で定期実行し、PhilArchive / PhilPapers / arXiv といった情報源から関心キーワードに沿った論文を自動収集して inbox/ に蓄積するパイプラインを作りました。蓄積された素材は Codex / Claude Code が読み、既存ノートと照合しながら 研究動向/ ディレクトリに日本語のまとめノートとして統合します。 レポジトリはこちらです: https://github.com/jedipunkz/philosophy 全体アーキテクチャ +-----------------+ | scrape.yaml | +--------+--------+ v +--------------------------------------------------+ docker compose | +------------------+ +------------------+ | | | scraper (Go) | | scheduler (Go) | | | +---------+--------+ +---------+--------+ | | | | | | +-----------+-----------+ | | | | | fetch via HTTP / arXiv API | | | | | +--------------------v-------------------+ | | | PhilArchive / PhilPapers / arXiv | | | +--------------------+-------------------+ | +-------------------------|------------------------+ v +----------------------------+ | inbox/*.md | Obsidian Vault +-------------+--------------+ | | git commit v +----------------------------+ | GitHub (philosophy repo) | +-------------+--------------+ | | pulled from other devices v +----------------------------+ | Codex / Claude Code | reads inbox + existing notes +-------------+--------------+ | v +----------------------------+ | research-trends/*.md | curated Japanese notes +----------------------------+ ポイントは 3 つです。 ...

jedipunkz🚀 です。 もともと自分は AWS ECS を使ってコンテナシステムを組むことが多かったのですが Google Cloud を扱う環境に変化したので Cloud Run をベースとした環境構築について調べてみました。今回作った環境は Cloud Run を利用する際に必須になってくる CI/CD パイプライン、WAF、Load Balancer を組み合わせています。 今回は下記のリポジトリに置いた Terraform コードをベースに、ベストプラクティスに沿った Cloud Run 本番構成の設計と実装のポイントを紹介します。 https://github.com/jedipunkz/gcp-playground/tree/main/cloudrun 概要 今回構築する構成の主な技術要素は次のとおりです。 Cloud Run: ステージング・本番の 2 環境をサーバーレスで運用 Cloud Deploy: ステージング → 本番への段階的デプロイ（手動承認ゲート付き） Cloud Build: GitHub リポジトリへの push をトリガーにしたビルドパイプライン Cloud Load Balancing: グローバル HTTPS ロードバランサーと HTTP → HTTPS リダイレクト Cloud Armor: OWASP WAF ルール + レートリミットによるエッジ防御 Artifact Registry: Docker イメージのライフサイクル管理付きレジストリ VPC / Subnet: Cloud Run Direct VPC Egress 用のカスタムネットワーク IAM: Cloud Run / Cloud Build / Cloud Deploy のサービスアカウント分離 CI/CD の流れとしては、開発者が GitHub にコードを push すると Cloud Build がコンテナイメージをビルドして Artifact Registry に格納し、Cloud Deploy がステージング環境へ自動デプロイします。ステージングでの確認後、手動承認を経て本番環境へプロモートされます。本番の Cloud Run へのアクセスは Load Balancer 経由のみに制限し、Cloud Armor で WAF とレートリミットを適用します。 ...

こんにちは。@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 はログ、メトリクス、トレース、変更履歴、過去インシデントという情報を横断的に相関させ、「何が起きているか」だけでなく「なぜ起きたか」という原因候補を提示します。 ...

Go の再学習をしている最中なのですが、学習当初 Go Interface は「なんとなく分かるが使いこなせない」という感覚を持っていました。自分のコードでも使っているのですが、どのようなパターンで使えるのかを網羅的には知っていない状態だったのでこれを機に調べてみました。この記事では基本的な定義から実務でよく登場するパターンまでをサンプルコードと共に整理しました。 コードは以下のレポジトリにあります。 https://github.com/jedipunkz/go-tips interface とは interface はメソッドのシグネチャの集合を定義する型です。ある型が interface に定義されたメソッドをすべて持っていれば、自動的にその interface を満たします。 この設計により、既存のコードを変更せずに後から interface に適合させることができます。 パターン1: 基本的な interface 最もシンプルな interface の定義と利用です。Shape interface を定義し、Circle と Rectangle がそれを実装します。 使い所 図形の面積や周長を計算する処理を書く場合、Circle や Rectangle ごとに別々の関数を用意すると、新しい図形が増えるたびに呼び出し側の修正が必要になります。Shape interface を定義して関数が Shape を受け取るようにすると、新しい図形を追加しても既存の関数はそのまま使え、拡張が容易になります。 package main import ( "fmt" "math" ) // Shape インターフェースを定義する // メソッドセットを持つ型はこのインターフェースを満たす type Shape interface { Area() float64 Perimeter() float64 } type Circle struct { Radius float64 } func (c Circle) Area() float64 { return math.Pi * c.Radius * c.Radius } func (c Circle) Perimeter() float64 { return 2 * math.Pi * c.Radius } type Rectangle struct { Width, Height float64 } func (r Rectangle) Area() float64 { return r.Width * r.Height } func (r Rectangle) Perimeter() float64 { return 2 * (r.Width + r.Height) } // インターフェース型を引数に取ることで、どの Shape 実装でも受け付ける func printShapeInfo(s Shape) { fmt.Printf("面積: %.2f, 周長: %.2f\n", s.Area(), s.Perimeter()) } func main() { c := Circle{Radius: 5} r := Rectangle{Width: 4, Height: 6} fmt.Print("Circle: ") printShapeInfo(c) fmt.Print("Rectangle: ") printShapeInfo(r) } printShapeInfo は Shape を受け取るだけで、Circle か Rectangle かを意識しません。新たに Triangle を追加したとしても、Area() と Perimeter() を実装するだけで既存コードの変更なく動きます。 ...