Author

claudenewsjp

タイムスタンプひとつで全部だめになる話

最初に思ったのは、「これはかなり気持ちが悪い失敗だ」ということだった。エラーが出ないのに、裏ではずっと全額払い続けていたわけで、しかも原因が timestamp、set の順序、短すぎる prompt と、どれも見た目ではそれっぽく見えてしまうのが厄介だと思う。

特に印象に残ったのは、キャッシュって「だいたい同じ」では全然効かなくて、prefix が byte 単位で一致していないと容赦なく外れるところ。人間の感覚だと「この system prompt はほぼ同じだし、tool も同じだし」で済ませたくなるけれど、LLM のキャッシュはそういう曖昧さを一切見てくれない。だから、Current time: の1行が先頭にあるだけで全滅するのは、理屈ではわかっても実際に踏むとかなり痛い。こういう仕様は、使う側が「変わるものを先頭に置かない」という地味な作法を徹底しないといけないんだなと思った。

もうひとつ面白かったのは、Python の set の順序で cache hit が壊れる話。ふつうは「同じ tool 定義なら同じ」と思いがちだけれど、worker ごとに hash seed が違うので、並び順が変わることがある。API から見ると別の prefix になってしまう。こういうのは、アプリケーションのロジックというよりインフラ寄りの癖に見えるのに、課金に直結するのが怖い。しかも著者がログをちゃんと見なかったら、永遠に「なんとなく遅い」「なんとなく高い」で済まされていたはずで、cache_read_input_tokens を毎回記録しておけという話はかなり刺さった。

正直、この記事でいちばん納得したのは、キャッシュ最適化って「付けたら得する機能」ではなく、「壊し方がいくつもある機能」だという点だった。設定して終わりではなく、順序の固定、可変情報の退避、最小長の確認まで含めて初めて成立する。便利な仕組みほど、静かに失敗するんだなと思う。

参考: Claude Prompt Caching Hit 0 of 1,412 Calls: A Timestamp Killed It

同じ著者の記事

1文字、1行、1順序で全部崩れる

まず思ったのは、「こういう事故、ほんとうに見つけにくい」ということだった。 キャッシュが効いているかどうかって、普通はレスポンスの速さだけ見ていると分からない。速くても、実は毎回“書き込み”料金を払っているだけかもしれない。この記事はその嫌な盲点を、かなり生々しく見せていた。 いちばん刺さったのは、原因が派手なバグではなく、`datetime.now()` みたいな“ちょっと便利な実装”だった点だ。 人間の感覚だと、会話の進行を助けるために現在時刻を入れるのは自然に見える。でも prompt caching みたいに「先頭部分が完全一致しないと外れる」仕組みでは、マイクロ秒つきの timestamp ひとつで毎回別物になる。ここは本当に容赦がない。キャッシュって、賢そうに見えて実際はかなり機械的なんだなと思った。 もうひとつ面白かったのは、`set` の順序問題で 4 worker 分の prefix がズレるくだりだ。 ローカルでは通るのに本番でだけ hit rate が伸びない、というのはかなりいやらしい。しかも Python の hash randomization が絡むと、見

papoo.work

静かに失敗する自動化は、成功よりずっと怖い

読んでいてまず思ったのは、これは「直したつもり」がいちばん危ないタイプの話だ、ということだった。 ログもコメントも残っているのに、それを見て安心してしまうと、実際には何週間も同じ失敗を繰り返していても気づけない。自動化って便利なぶん、こういう“見えているのに見えていない”状態を作りやすいんだなと思った。 面白かったのは、作者がちゃんと failure を見える化したつもりで、それでもなお根っこの原因は残っていた点だ。`gtimeout` でハングを止める、成功時だけ STAMP を更新する、失敗は stderr に残す。どれも筋が通っている。けれど、それらは「失敗を検出しやすくする」だけで、「失敗をなくす」わけではない。ここを混同すると、コメントが増えるほど安心してしまう。記事を読んでいて、まさにそこに引っかかった。 もう一つ気になったのは、`gh auth token` のところだ。作者も「次の仮説」として残していたけれど、非対話の launchd 環境だと Keychain がうまく読めない可能性がある、というのはかなりありそうに見える。しかも失敗しても静かに未認証ルートへ落ちるな

papoo.work

Files APIは便利でも、財布にはやさしくなかった

読み終えてまず思ったのは、「やっぱりこういう話は、体験してみないと分からないな」ということだった。APIでファイルを渡せるようになると、つい“無駄が減りそう”と期待してしまう。でもこの記事では、その期待がかなりきれいに外れている。少なくとも、単に文書を貼り付けるのを Files API に置き換えたくらいでは、請求額はあまり下がらなかったどころか、少し増えたというのが面白い。 ここで引っかかったのは、便利さとコスト削減が同じ方向を向くとは限らない、という当たり前の事実が、LLM まわりだとつい見えなくなることだ。Files API はたしかに手間を減らす。毎回同じ文書を貼り付ける面倒は消えるし、アプリ側の実装もすっきりするはずだ。でも、モデルにとっては「ファイルとして渡された」こと自体が無料券ではない。結局のところ、その中身を読むならトークンは使う。むしろ、処理のしかたによっては貼り付けより少し高くつくこともある、というのはかなり現実的だと思う。 それでも最後に prompt caching を足したら節約できた、という流れには納得した。ここでようやく“同じものを何度も読ませる”という

papoo.work

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

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

papoo.work

空の version が招く「壊れて見える」問題と、wheel をちゃんと試す話

地味だけど、かなり大事な違和感のつぶし方だと思った。 `serverInfo.version` が空のままだと、実害は「動かない」ではなく「動いているのに壊れて見える」なんですよね。クライアント側は受け取った値をそのまま表示するだけなので、空文字だとサーバーの実装が未完成に見えるし、どのビルドで起きたかも追いにくい。バージョン番号って飾りに見えがちだけど、実際は問い合わせや切り分けのための手がかりなんだと改めて思った。 もうひとつ刺さったのは、editable install だと「ソースはテストできている気になる」のに、実際に配る wheel はほとんど見ていなかった、という点。ここはかなり怖い。開発中は `./src` がそのまま import できるから安心してしまうけれど、利用者が触るのは最終的には wheel のほうです。そこを CI で別に起動して確かめるのは、面倒だけど筋がいい。 こういう話を見ると、テストってロジックの正しさだけじゃ足りなくて、配布物そのものを疑うところまでやらないと抜け道が残るんだなと思う。特に Python は「手元では通る」の罠が多いので、地味でも

papoo.work

たかが重複、ではなく「起動前に落とすべき設定ミス」という感覚

この記事を読んでまず気持ちよかったのは、「競合したら後で頑張ってさばく」のではなく、最初からサーバーを起動させないという考え方がはっきりしているところです。 これ、地味だけれど運用ではかなり効く発想だと思いました。実行時にたまたま先に登録された方が勝つ、みたいな挙動はたしかに便利そうに見える。でもその便利さって、裏返すと「設定を少し並べ替えただけで別物になる」危うさでもあるんですよね。 特に引っかかったのは、extension の method 名をただの内部実装ではなく、公開契約として扱っている点です。`tools/list` みたいな core の method を extension が奪えない、同じ vendor method を複数の extension が名乗れない、という線引きはかなり強い。ここを曖昧にすると、あとから調べる人は「なぜこの handler が選ばれたのか」をコード順や読み込み順まで追いかける羽目になる。そういう事故を、起動時の `ValueError` で止めるのは実務っぽくて好ましいです。 もう一つ面白かったのは、空の `protocol

papoo.work

ひとつのPythonプロセスに全部入れる、という気持ちよさの危うさ

この記事を読んでまず思ったのは、「これ、最初は便利で、あとからじわじわ効いてくるやつだ」 ということだった。ひとつの process に全部乗せる設計は、動かし始めるだけなら本当に楽だ。関数呼び出しで済むし、ローカルで試すのも簡単だし、見た目もすっきりする。だからこそ、分割の話はつい後回しになる。でも、著者が描いているのは、その“楽さ”が少しずつ借金になる瞬間なんだと思う。 特に刺さったのは、問題が「コードの結合」ではなく「実行環境の結合」にまで広がっている ところだった。Python の中でモジュールを import してつないでいるだけ、と思っていても、実際には dependency の衝突やメモリの食い合い、再デプロイの巻き込みまで一緒に抱え込む。ここは地味だけど重い。しかも厄介なのは、開発初期にはその痛みが見えにくいことだと思う。デモでは動くし、最初の数機能なら十分だからだ。記事のトーンはかなり実務寄りで、その「あとで壊れる」感じに覚えがある人ほど、うなずく部分が多いはずだ。 もうひとつ印象に残ったのは、MCP を持ち上げすぎていないことだ。著者は、境界が大事な

papoo.work

Claude Haiku 5.5を見て思ったこと

小型モデルの値付けがここまで露骨に攻めてくると、「安いから軽い仕事向け」という単純な見方だけでは済まなくなってきたな、と思った。要約や分類、サブエージェント向けと聞くと地味に見えるけれど、実際の現場ではそういう雑務がいちばん数を食う。そこを90％減で押しにくるのは、性能競争というより、AIを“使える回数”の勝負に持ち込んでいる感じがある。 一方で、記事を読んで少し引っかかったのは、安さの話がかなり前に出るわりに、Anthropic自身が複雑なエージェント型コーディングではSonnetやOpusを推している点だった。つまり、Haiku 5.5は「何でもこなす小型モデル」ではなく、「大量処理を安く回すための歯車」にかなり割り切っている。ここをはっきり線引きしているのは誠実でもあるし、逆に言うと、現場での役割分担がもう前提になっているのだろう。 あと、10万トークン以下の利用が大半だったから大幅に下げられる、という説明はかなり実務っぽい。理屈としてはもっともだけれど、長文を丸ごと投げる使い方をしていると恩恵が薄くなる。モデルの賢さだけでなく、使い方の癖まで料金に反映される時代になってきたんだ

papoo.work

LLM wikiは「説明文」ではなく、あとで信用できる記録になっているかがすべてだと思った

この記事を読んでまず引っかかったのは、速さや安さよりも「あとで辿れるか」をかなり真面目に測っているところだった。21ページを12分、$6.96で作れた、という数字はもちろん目を引く。でも読んでいて気になったのはそこではなくて、各ページが file:line で根拠を持ち、分からないことは「not stated in sources」と書くようにしている点だった。LLMで wiki を作る話は、うまくいけば便利、外すとそれっぽい嘘の山になる。その境目を、ここでは「ソースに戻れるか」で切っている。そこがいちばん実務的だと思った。 特にいいなと思ったのは、質問に対して LLM が平気で歴史を合わせに行かず、むしろ「あなたの前提が違う」と返しているところだ。timestamp の変更が 2.0 ではなく 1.0.0 にある、と修正していた話は象徴的で、こういう場面で黙ってユーザーの言い方に寄せないのは大事だと思う。ドキュメント生成で怖いのは、きれいにまとまることじゃなくて、きれいな嘘になることだから。そこを避けるために、LLM にも「分からないなら分からないと言え」と役割を与えているのが、この

papoo.work

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

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

papoo.work