#ログ解析

最初に思ったのは、「便利そうな仕組みほど、放っておくと簡単に“置物”になるんだな」ということだった。 カスタム agent を何個も定義した時点で、もう何かを自動化した気になってしまう。でも実際には、呼び出されていなければただの設定ファイルでしかない。その当たり前を、30日分のログで突きつけられるのが少し痛い。 面白かったのは、この記事が「AI が賢くならないからダメ」という話に寄っていないところだと思う。むしろ逆で、AI に期待するより先に、周辺の仕組みをちゃんと監視しろと言っている。ログを取り、集計し、使われていない agent を炙り出す。派手ではないけれど、こういう地味な仕掛けのほうが長く効く気がする。自動化って、作ることより、壊れていないか確かめ続けることのほうが難しいのかもしれない。 それと、`defined = working` という思い込みへの指摘はかなり刺さった。説明文に「必ず使う」と書いてあっても、実際に呼ぶ側のロジックがなければ動かない。ここは人間の道具づくりでも同じで、棚に並べた瞬間に仕事が終わった気になる。でも本当に大事なのは、使われた痕跡があるかどうかだと

この記事を読んでまず思ったのは、やっぱり現場の話はきれいなデモとは全然違う、ということだった。 「Claudeでインシデント対応ができるのか」という問いに対して、筆者がかなりはっきり「まだ無理」と言っているのがむしろ好感だった。AIの話になると、どうしても成功例だけが独り歩きしがちだけれど、実際の運用ではそんなに単純じゃない。 面白かったのは、LLMが得意なところと苦手なところの境目がかなり生々しく書かれていた点だと思う。ログやtraceを眺めて、異常らしいものを拾うのはかなり強い。でも、root cause analysis、つまり「なぜそれが起きたのか」を因果で詰める段になると、まだ怪しい。ここは単なる能力差というより、仕事の性質そのものの違いなんだろう。観察は得意でも、説明責任は別物だ、という感覚に近い。 それと、筆者が「Claudeをダッシュボードより先に使うことがある」と言っていたのは、かなり現実的で驚いた。AIが人間の代わりになるというより、最初の視界を開く道具になっている。オンコール中って、何が壊れたかを掴むまでの数分がとにかくつらいので、その入口を少しでも短くできるなら

読んでまず思ったのは、これはかなり“地味だけど効く”種類の道具だな、ということだった。AIツールの利用量って、体感と実際がずれやすい。ちょっと触っただけなのに急に制限に当たると、「自分が使いすぎた」のか「裏で何かが回っていた」のか、感覚では分からない。そこを、端末に残っている session log だけで追いかける発想はかなり筋がいいと思う。 面白いのは、単なる token カウンターではなく、「なぜ増えたか」に寄せているところだ。大きいファイルを早い段階で読んだせいで後から何度も context に載り直す、とか、短い session が大量に並んでいるのは人間の作業ではなく automation の気配だ、とか。こういう説明が返ってくるなら、ただ数字を見てため息をつくよりずっと使える。特に、limit に引っかかった理由が“自分の作業”ではなく“どこかの仕組み”だったと分かるのは、気持ちの整理にもなるはずだ。 もう一つ、README で強く押しているのが「何も外に出さない」という点だった。usage の監査系ツールは、便利そうでもログをどこかのサーバーに投げるのが気になって踏み切

正直、いちばん面白かったのは「タグがあった」ことそのものより、筆者がそこで立ち止まって自分のログを掘り返したところだと思った。LLM の話って、ついモデルが何を“言ったか”で終わりがちだけど、ここでは実際の JSONL ログを grep して確かめている。しかも「自分の環境で本当に起きたのか」を、自分の手元の記録で確認している。この姿勢はかなり気持ちよかった。 一方で、少し怖さもある。hidden tag という言い方だと、つい「裏で秘密の命令が動いていたのか」と身構えるけれど、記事を読む限り、問題の中心はもっと地味で、もっと厄介だ。内容を完全には見せず、しかもその分のコストや影響がどれくらいあるのかも外からは分かりにくい。そこがモヤっとする。`<ip_reminder>` という名前自体は公開文書にも出てくるのに、実際の挙動や負担は見えづらいまま、という構図が引っかかった。 あと、この人が強調している「他人の Issue の数字をそのまま自分の話にしないで、自分のログを見ろ」という態度は、かなり本質的だと思う。LLM 周りは、ベンダーの説明、Issue の報告、SNS の切り抜きが混

GitHubの `delta-hq/cc-canary` は、Claude Code を使っているときの“挙動の変化”をあとから検査するためのツールです。ざっくり言うと、「最近のClaude Code、前より雑になってない？」「同じ作業なのに、やたら遠回りしてない？」みたいな違和感を、ログから拾い上げる仕組みです。 面白いのは、これが単なる使用状況の可視化ではなく、かなり“監査”寄りの発想で作られていることです。名前のとおり、炭鉱のカナリアみたいに、危ない変化を早めに知らせるのが狙い。個人的には、この比喩はかなりうまいと思いました。AIの品質って、毎回きれいに壊れるわけじゃなくて、じわじわ変調することがあるので、その違和感を拾う発想はかなり実用的です。 cc-canary は、Claude Code がローカルに残す JSONL 形式のセッションログを読みます。JSONL は、1行ごとに1件のデータが入っているログ形式のことです。難しく聞こえますが、要するに「会話や操作の記録がずらっと並んだファイル」です。 このログをもとに、モデルの挙動が「自分の作業の中で drift していないか」