#可観測性

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

これを読んでまず思ったのは、ようやくプロトコルとアプリケーションの責任分界が少しまともになりそうだ、ということだった。 セッションを前提にした設計って、実装する側からすると地味に面倒なんですよね。sticky session だの session store だのを抱え込むと、スケールさせたいだけなのにインフラが妙に重くなる。MCP がそこを削って、「プロトコルは stateless、でもアプリは必要なら stateful でいい」と寄せたのは、かなり筋がいいと思う。 特に引っかかったのは、これで楽になる部分と、逆に後ろに押し出される責任がはっきりしたところです。セッション維持のための仕組みは減るけれど、その代わり retry、idempotency、observability は別レイヤーでちゃんと考えろ、という話になる。ここはかなり現実的だなと思う一方で、便利な抽象化が一つ消えたぶん、雑に作ると事故りやすくもなる。たとえば side effect を持つ tool call は、失敗時に二重実行されても困らないようにしておかないといけない。クラウド側が軽くなったから終わり、ではない

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