#開発体験

最初に思ったのは、「それ、速くなった気がするのはかなり大事だけど、嬉しさの種類はだいぶ限定的だな」ということだった。会話の続きを毎回まるごと送り直さなくてよくなるなら、体感速度は確かに上がるはずだし、長いやり取りをしているときのモッサリ感も減ると思う。けれど、記事がはっきり書いている通り、token の消費量は変わらない。ここが妙にAnthropicらしいというか、ユーザーが欲しい「安くなる」は避けて、「速くなる」だけを切り出しているのが少し生々しい。 面白いのは、この改善がわりと地味な実装の差で効いていそうなところだ。LLMの世界はつい「より賢いモデル」「より長いコンテキスト」に話が行きがちだけれど、実際の使い勝手を左右するのは、こういう周辺の作法だったりする。毎回全文を投げ直すのではなく、message threads で差分っぽく扱う。人間のチャットアプリなら当たり前に感じるけれど、LLM API の使い方だとそこが律儀に無駄になっていた、という見方もできる。 ただ、5分で切れるという条件はかなり気になる。コーヒーを取りに行ったらもう続きが切れていた、という記事の冗談は半分笑い話

まず引っかかったのは、「自分のディスクにある `AGENTS.md` を読むかどうか」が、ローカルの事情ではなく remote feature flag で決まっていることです。そこまで大げさに管理する種類の機能には見えないし、しかも telemetry を無効にした途端に黙って無視されるのは、かなり嫌な感じがします。拒否されるなら拒否されるでいいのに、何も言わないのがいちばん困る。 この記事でいちばん腑に落ちたのは、筆者が怒っている理由です。単に「新機能がうまく動かない」ではなく、「telemetry を切ると診断情報だけでなく、ローカルにあるはずの入力まで失われる」のが問題なんですよね。ユーザー側から見ると、設定ファイルが読まれないのか、モデルが無視したのか、通信まわりで止まったのか、切り分けようがない。結局、プロンプトを直したり、指示文を疑ったりして時間を溶かすことになる。こういう静かな失敗は本当に厄介だと思います。 もうひとつ面白かったのは、回避策が `CLAUDE.md` に `@AGENTS.md` を書くだけ、というあまりにも地味なことです。機能追加のために増えたはずの