Author

claudenewsjp

Claude Codeの“待たされ感”だけ減る、けれど請求書は軽くならない

最初に思ったのは、「それ、速くなった気がするのはかなり大事だけど、嬉しさの種類はだいぶ限定的だな」ということだった。会話の続きを毎回まるごと送り直さなくてよくなるなら、体感速度は確かに上がるはずだし、長いやり取りをしているときのモッサリ感も減ると思う。けれど、記事がはっきり書いている通り、token の消費量は変わらない。ここが妙にAnthropicらしいというか、ユーザーが欲しい「安くなる」は避けて、「速くなる」だけを切り出しているのが少し生々しい。

面白いのは、この改善がわりと地味な実装の差で効いていそうなところだ。LLMの世界はつい「より賢いモデル」「より長いコンテキスト」に話が行きがちだけれど、実際の使い勝手を左右するのは、こういう周辺の作法だったりする。毎回全文を投げ直すのではなく、message threads で差分っぽく扱う。人間のチャットアプリなら当たり前に感じるけれど、LLM API の使い方だとそこが律儀に無駄になっていた、という見方もできる。

ただ、5分で切れるという条件はかなり気になる。コーヒーを取りに行ったらもう続きが切れていた、という記事の冗談は半分笑い話で半分本気だと思う。開発作業って、むしろ中断されるものだし、短い休憩や別タスクをまたぐことも多い。だからこの仕様は、常時つなぎっぱなしの素直な加速というより、「短時間で連続入力する人向けの最適化」なんだろう。便利ではあるけれど、万能ではない。

参考: Anthropic speeds up Claude Code with message threads. But your token bill stays the same.

同じ著者の記事

テレメトリを切ったら、ローカル設定まで消えた話

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

papoo.work

Claude Code の“隠しタグ”を読んでしまった話で、いちばん引っかかったこと

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

papoo.work

Claude Sonnet 5.5を選んでも、裏で別のモデルに切り替わるかもしれない話

この記事を読んでまず思ったのは、「モデル名を選んだつもりでも、そのとおりの挙動になるとは限らない」のかという、かなり嫌だけど大事な現実です。APIやLLMを使う側は、`Sonnet 5.5` という名前に安心したくなります。性能も癖も、そのモデルを前提に設計したくなるからです。そこに「状況によっては Sonnet 5 に回される」と聞くと、ちょっとした実装上の話では済まない気がします。 特に引っかかったのは、これが単なる負荷分散ではなく、cyber safety のための仕組みとして入っている点です。危ないリクエストをそのまま通さず、classifier と fallback を挟む。安全側に倒す設計としては筋が通っています。でも開発者の立場だと、出力の再現性やデバッグのしやすさが一気に難しくなる。昨日と同じプロンプトなのに結果が違う、しかもその理由が「裏で別モデルに切り替わったから」だとしたら、原因切り分けがかなり面倒です。 もうひとつ面白かったのは、AI の安全対策が、もはや「危険なプロンプトを止める」だけではなく、どのモデルをどの条件で見せるかという運用の話にまで

papoo.work

Anthropicの小型モデル値下げで考えたこと

モデルが小さくなったから安い、という話ではなくて、「小さいモデルでもエージェント用途に使える」と本気で言いにきているのが面白いと思った。LLMの話はどうしても「大きいほど賢い」に引っ張られがちだけれど、実運用ではそこだけ見ていても意味がない。待ち時間、コスト、失敗したときの痛さ。このへんが効いてくるので、安い小型モデルに「effort controls」が付くのは、かなり実務寄りの匂いがする。 ただ、そこで少し引っかかったのは、ベンチマークの伸びがそのまま現場の安心に直結するわけではないことだ。computer-use や command-line 系で強い、というのはたしかにわかりやすい。でも、こういう用途は一回の正解率より、むしろ変な操作をしないか、途中で迷走しないかのほうが大事だったりする。effort を抑える機能は便利そうな一方で、「どこまで考えさせるか」を開発者がちゃんと調整しないと、安いけど荒っぽい、みたいなモデルになりかねない。そこは期待と同時に、少し怖さもある。 それでも、こういう値付けの動きは歓迎したい。高性能モデルを全部の処理に使うのは、やっぱり贅

papoo.work

料金が下がっても、互換性が壊れたら怖い

この記事を読んでまず思ったのは、安くなったことより「その安さで何を壊したのか」のほうがずっと重い、ということだった。モデルの値下げは普通は歓迎される。でも、エージェントが前提にしている `thinking` や tool use、computer use の挙動が変わって、既存の実装に 400 error が出るなら、現場では値下げどころではない。むしろ「安くなったから乗り換えよう」が、そのまま「既存システムの修理コストが発生する」に変わる。 特に引っかかったのは、AI の改善がそのまま互換性の改善にはならない点だ。人間向けのチャットなら多少の出力差は「賢くなった」で済むけれど、エージェントは違う。モデルの応答が少し変わるだけで、ツール呼び出しの条件分岐やリトライの設計が崩れる。つまり、LLM はただの文章生成器ではなく、半分は外部サービスみたいに扱わないといけないんだな、と改めて思った。バージョンアップのたびに挙動確認が必要になるなら、API の更新というより、かなり厄介なミドルウェアの変更に近い。 それでも、こういう記事が出るのは意味があると思う。AI の話はどうしても「性能が上が

papoo.work

Anthropicの値下げで感じた、安さより怖いもの

価格を20%下げた、という話だけなら普通は「使いやすくなったな」で終わる。でもこの記事を読んで引っかかったのは、そのあとにある“静かに別のモデルへ回されることがある”という部分だった。ここ、かなり重要だと思う。 LLMのAPIを使うとき、開発者が本当に欲しいのは単なる返答ではなく、「このモデルをこの条件で使った」という再現性だ。ところが safety classifier の判断で、処理の途中から older model に切り替わるなら、見た目は同じでも中身は別物になる。エージェント開発って、タスクを分解して長い手順を回すぶん、どこかで挙動が変わると原因追跡が急に難しくなる。安くなったのに、デバッグコストが上がる可能性があるわけで、そこは素直に喜びにくい。 それでも、こういう話が表に出てくるのは悪くないとも思った。AI の品質って、ベンチマークの数字だけでは見えない。実運用では「どのモデルが、どの時点で、なぜ選ばれたか」がかなり効く。今回の件は、モデルの性能競争が進むほど、モデルそのもの以上に“ルーティングの透明性”が重要になる、と突きつけている感じがした。 --- > 参考: [A

papoo.work

Claude Codeの「増えたようで減る」話に引っかかる

読んでまず思ったのは、これはかなり説明の仕方がうまい、というより少し意地悪だな、ということだった。 「25%増える」と言われると普通は歓迎したくなるけれど、実際には今の一時的な上乗せが終わるだけで、足元から見ると17%減る。数字の見せ方ひとつで印象がここまで変わるのは、サブスク系の料金や利用制限ではよくあることだけど、今回みたいに開発者向けの道具でやられると、なおさら気になる。 Claude Code って、ただのチャットUIではなくて、日々の作業にかなり深く入り込む道具だと思う。だから「週あたりの利用枠」が少し削られるだけでも、体感はわりと大きいはずだ。しかも Anthropic 自身がいったん元のスレッドを消して、あとから「今日と比べると17%減る」と言い直している。最初の言い方に自信がなかったのか、あるいは炎上しそうだと判断したのか。ここは少し気になるところだった。 一方で、利用量が会話の長さや tool usage で変わる以上、週の上限を固定の回数で語れないのも分かる。だからこそ、ユーザー側は「何回使えるか」より「自分の使い方だとどれくらい余裕があるか」を見ないといけない。便

papoo.work

Claude Codeの自動モード、便利さと怖さの境目

最初に思ったのは、「また便利さがデフォルトに寄ってきたな」ということだった。 Claude Code の auto mode は、毎回人間に確認を求めずに先へ進めるモードらしい。コードを書く流れを速くするにはたしかに気持ちよさそうだけど、プログラマーの感覚からすると、確認を省く方向にデフォルトが寄るのは少し落ち着かない。 記事の中でいちばん引っかかったのは、「危険な操作だけ止める」という設計が、どこまで本当に頼れるのかという点だ。Anthropic はテストで harmful actions の 89% を auto mode が見つけたと言っていて、人間の 13.6% より高いらしい。数字だけ見るとかなり強い。でも、ここで気になるのは「残りの11%」がどんな場面なのかだと思う。破壊的で元に戻せない操作は止める、という説明は筋が通っている一方で、実際の開発では、壊れ方がゆっくり来るミスのほうが厄介だったりする。そこをどこまで拾えるのかは、記事だけでは見えない。 それでも、デフォルトでオンにする判断自体は、Anthropic がこの機能を“実験”ではなく“日常の道具”として押し出したいの

papoo.work

Claude Codeの「複数エージェント化」を読んで思ったこと

これ、便利そうというより先に「もう人間の仕事の区切り方に寄せてきたな」と感じました。AIに1つの質問を投げて答えを待つ、という段階はかなり前からありましたが、この記事のClaude Codeはその先に行っていて、ひとつの作業を複数の thread に割り振り、coordinator がまとめる。要するに、小さなチームをそのままクラウドの中に作る発想です。 面白いのは、各 thread が別ブランチと別コピーの repo で動く、という点です。ここはかなり現実的だと思いました。AI が同じコードを触ると怖いのは、勝手に整合性を壊すことですが、そこを merge conflict まで含めて普通のPRと同じ扱いにしている。魔法っぽく見せるのではなく、Git の流儀に押し込んでいるのが Anthropic らしいというか、ちゃんと開発現場に降ろそうとしている感じがあります。 ただ、同時に「結局、扱う人の側にかなりの管理能力が要るのでは」とも思いました。thread が増えるほど速くなるのは確かに魅力ですが、増えた分だけ指示の粒度や責任の所在がぼやけやすい。coordinator がいるとはい

papoo.work

研究論文にClaude Codeを当てる発想が、まず面白い

最初に思ったのは、「それ、かなり雑に見えて、実は相性がいいのではないか」ということだった。研究論文って、コードベースみたいに明確なAPIがあるわけじゃない。でも、PDFの中には方法、前提、実験条件、関連研究のつながりが詰まっていて、読む側は毎回そこを手でほどいていく。そこにClaude Codeのような、文脈を追いながら作業する道具を当てるのは、かなり筋がいいと思う。 ただ、同時に少し引っかかる。論文読むときに本当に欲しいのは、要約をうまく返すチャットボットというより、「この主張はどこまで論文内で支えられているのか」を一緒に追ってくれる相棒だ。研究では、細部の条件がズレると結論の意味が変わる。たとえば「平均では良い」が「特定のデータセットでは弱い」みたいな話は、人間でも読み飛ばしやすい。そういうズレを見落とさずに扱えるなら強いけれど、逆にそこを平気で丸めるなら、便利さのわりに危ない道具にもなると思う。 あと、この手の話でいつも気になるのは、道具そのものより「どこまで信じていいか」の線引きが曖昧になりやすいことだ。論文はもっともらしい文体で書かれているぶん、LLMの出力もそれっぽく見えや

papoo.work