#opentelemetry

AIエージェント向けの「memory」が、いまかなりバラバラな形で広がっている。あるものはMarkdownファイル、あるものはJSONLの知識グラフ、別のものはサービスの中に閉じたレコードだ。LoreKitのMads Thinesは、その断片化が観測基盤の世界で起きたこととよく似ていると指摘し、OpenTelemetryのような共通の土台が必要ではないか、と投げかけている。単なる理想論ではなく、すでに複数の提案が出ている今だからこそ、何を共通化し、どこを競争領域に残すのかを整理する意味がある。 元記事がまず示すのは、現場の散らかり方だ。典型的な開発環境では、リポジトリ内の AGENTS.md や CLAUDE.md、Cursor の .cursor/rules/*.mdc のような指示ファイルがあり、Anthropic の memory tool は /memories ディレクトリにファイルを書き込む。GitHub Copilot は GitHub 側にリポジトリごとの知識を持ち、memory MCP server は JSONL の知識グラフを扱う。これだけで、少なくとも四つの異な

CIの話なのに、いちばん先に気になったのは「ついにここまで来たか」という感覚だった。Buildkite がやっているのは、単にビルドを回す基盤を強くするだけじゃなくて、失敗したパイプラインをAI agentに読ませて直させる方向まで踏み込んでいる。CIは昔から「壊れたら人間がログを読む」世界だったけれど、その前提をじわじわ崩しにきている感じがある。 ただ、読んでいて素直にうれしかったのは、派手な agentic 機能よりも、むしろ secrets の扱いのほうだった。pipeline単位で secret を閉じ込められるのは地味だけれど、現場ではかなり効く。secret の漏れ方って、機能が足りないというより「権限が広すぎた」「どこで使っていいか曖昧だった」で起きることが多いので、こういう粒度が細かい制御はちゃんと価値があると思う。しかも branch や queue、build source まで条件にできるなら、かなり現実的だ。 一方で、MCP tool の話は面白いけれど、少し警戒もした。validate_pipeline みたいに、ビルドを始める前に YAML の構造を見てくれ

正直、こういう「使ったAIの料金をあとから集計できる」話はもっと早く当たり前になってほしかった、という感想が先に来ました。Claude Code の請求額そのものを眺めるだけだと、「誰が」「どのモデルで」「どんな種類の呼び出しをした結果」増えたのかが見えない。そこを OpenTelemetry で取れて、Grafana で面にしてしまうのはかなり筋がいいと思います。 面白かったのは、この記事が単に「ログを送れる」では終わらず、コストとトークンをそのまま運用の観測対象にしているところです。ふつう observability というと障害検知や遅延監視の話になりがちですが、ここでは「AI にいくら払っているのか」を監視している。しかも、main の会話と subagent の呼び出しを分けて見たり、キャッシュがどれくらい効いているかを確認したりできるので、感覚ではなく数字で会話できるようになるのが大きいです。 一方で、少し引っかかったのは、ここで見える USD があくまで近似値だと明記されている点です。請求書の正式な金額ではないし、座席課金のプランならなおさら「消費量の目安」に近い。これは

What surprised me here isn’t that Claude Code can emit telemetry. It’s that the piece makes a pretty strong case that you can get from “we think spend is rising” to “show me which model, which user, and which kind of call did it” with almost no infrastructure. That’s useful. But I’m also a little wary of how clean it sounds, because a lot of observability demos look effortless right up until you try them against real teams, real auth, and real billing boundaries. The most interesting part is not

MCP（Model Context Protocol）は、AIエージェントが外部ツールやデータベース、APIとやり取りするための共通規格として注目されています。今回のDZone記事は、そのMCPをOpenTelemetryでどう監視するか、しかも「1回の呼び出しで終わらない」「途中で人間の確認を挟んで再開する」ようなややこしいケースに焦点を当てています。 ここ、地味にかなり重要です。AIエージェントの実運用って、きれいな1往復のAPI呼び出しでは終わらないんですよね。ツールを呼ぶ、追加情報が必要になる、ユーザーに確認を求める、また別のHTTPリクエストで再開する……みたいな流れになりがちです。人間から見ると「同じ仕事の続き」なのに、監視基盤から見ると「別々のリクエスト」に見えてしまう。これ、運用担当としてはかなり嫌なやつです。 最新のMCP仕様では、W3C Trace Context の利用が前提になる これにより、分断されたAIエージェントの処理をひとつのトレースとして追いやすくなる 特に厄介なのが、途中で人間確認を挟む **InputRequiredResu