#コスト削減

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

いちばん引っかかったのは、「速い」「安い」というだけでなく、Anthropicがちゃんとモデルの役割分担を整理してきたことです。以前から上位モデルは万能っぽく見えがちでしたが、この記事だと Sonnet は「日常的なタスク向け」、Opus は「慎重な判断が要る複雑な作業向け」と、かなりはっきり線を引いている。ここが気持ちよくもあり、少し現実的でもあると思いました。AI を“なんでも屋”として売るより、用途を切って最適化するほうが、実際には使う側も選びやすいです。 それと、コストの話が思った以上に実務寄りでした。1トークンあたりの価格は据え置きでも、必要なトークン数が減ったのでタスク単位では安くなる、という見せ方は、かなり本音に近いと思います。こういう話はベンチマークの点数より地味ですが、現場ではむしろ効く。APIを叩く側からすると、モデルの“賢さ”より先に請求書が現実に来るので、30％という数字は軽く見えません。 一方で、サイバーセキュリティ関連だけは Opus 5.5 にフォールバックする、という設計には少し安心しました。性能を上げたらそのまま全部任せる、ではなく、危ない用途は別扱い

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

AIモデルは、答えの質だけでなく「どれだけトークンを使うか」で実運用の価値が大きく変わります。Fireworks AIが発表したEmber-1は、そのコスト問題に正面から答えにいくモデルです。派手な新機能を足すのではなく、既存の高性能モデルが吐き出しすぎる推論を抑えて、同じ答えをより少ないトークンで返すことを狙っています。派手さはないですが、企業の開発現場ではかなり効くタイプの改善だと思います。 Fireworks Researchが出したEmber-1は、Kimi K3を土台にした専用モデルだ。公式の説明では、Kimi K3と同等の品質を保ちながら、使うトークンを40%減らせるという。ここでいうトークンは、モデルが読み書きする文字列の単位で、API利用料や応答時間に直結する。単に出力を短くしただけではなく、「必要のない推論を削り、必要な思考だけ残す」ように学習させたのがポイントだ。 背景には、推論型モデルが“考えすぎる”問題がある。Fireworksによると、Kimi K3のような reasoning model は、生成トークンの大半、場合によっては90%以上を内部の推論に使う。1

まず、こういう「性能は上がったけど、同時に安くもなった」という発表は、もう驚きよりも少し不気味さのほうが先に来ます。AIモデルって、普通は高性能化と高コスト化がセットになりがちなのに、今回はかなり露骨にその逆をやっている。しかも単に価格を下げただけでなく、出力速度や文章の読みやすさまで改善しているので、ただの値下げ発表ではないんですよね。 特に気になったのは、「重要な情報を先に述べるようになった」「専門用語や独特な言い回しが減った」という部分です。これ、地味だけど実務ではかなり効くと思います。モデルの賢さって、ベンチマークの数字だけではなくて、結局は“読んで疲れないか”“指示が通るか”で体感が決まることが多いからです。Opus 5系は能力は高いのに、文章がやや回りくどいという印象を持つ人もいたはずで、その弱点をちゃんと潰しにきたのは素直にうまいと思いました。 一方で、利用上限の引き上げやレート制限のリセット機能も、地味だけどかなり現場向けです。AIは性能が高くても、肝心なところで「今日はもう使えません」となると仕事が止まる。だから、こういう“使える時間”の設計は、スペック表よりずっと体

読んでまず思ったのは、これは単なる「使い方のコツ」ではなく、LLM を道具としてどう運用するかの話なんだな、ということだった。Claude Code が高くつくから注意しよう、では終わっていない。むしろ、どこで余計な文脈を切り、どこにだけ計算資源を使わせるかを、かなり露骨に設計している。ここが面白い。 特に引っかかったのは、`/compact` の扱いだ。会話を短くするだけなら何となく想像できるけれど、記事を読むと「短くする」こと自体が目的ではなく、次のターンに残すべき情報を選び直す作業になっている。人間のメモ整理とかなり似ている。要らない雑音を削ると同時に、後で効くものだけを残す。逆に言うと、雑に長話を続けるほどコストが膨らむ。ここは、AI を賢くするというより、人間側の整理力がそのまま料金に跳ね返る感じがして、なかなか生々しかった。 もう一つ、`/clear` や context の切り替えがやたら強調されているのも印象的だった。普通のツールなら「履歴が残る」のは便利さの象徴だけど、Claude Code では履歴がそのまま負債にもなる。過去の情報を全部抱え込むのではなく、タスクご

この記事を読んでまず思ったのは、「やっぱり体感だけでは当てにならないんだな」という、わりと当たり前だけど痛い話でした。 著者は「この agent が遅そう」と感じていたところを計測したら、実は別の reviewer 系がもっと重かった。ここが面白いです。人間の“なんとなく遅い”は、だいたい外れる。しかも、その思い込みを放置したまま使い続けると、毎週のコストがじわじわ食われる。この記事はそのズレを、Stop hook で自動収集したログでひっくり返していました。 特に刺さったのは、Claude Code の session が終わるたびに transcript を拾って、subagent の起動と結果を JSONL に積んでいく発想です。手で記録しない。あとで思い出して整形もしない。ただ終わった瞬間に証拠を取る。こういう仕組みは、地味ですが強いと思います。しかも本体を改造せず、既存のイベントにぶら下がるだけというのがいい。運用が重いほど、「触る場所が少ない」こと自体が価値になります。 一方で、読みながら少し引っかかったのは、実装がちゃんとしているほど、逆に“人間の理解”がどんどんログと

「賢くなりました」だけで終わらず、同時に「だいぶ拒否しなくなった」と書いてあるのがまず面白い。AIモデルの改善って、つい性能競争の話に寄りがちだけれど、実際に使う側からすると、返答の質と同じくらい「どれだけ気軽に仕事を引き受けてくれるか」が効いてくる。そこを正面から触っているのは、かなり実務っぽい視点だと思った。 特に引っかかったのは、前の版で強すぎた safeguards を調整した、というくだりだ。安全策が強いほど安心、とは単純に言えないのがAIの難しいところで、厳しすぎると「安全」ではなく「使いづらい」に変わる。たぶん多くの現場では、危ないことを全部止めるより、ちゃんと使える範囲を広げてくれるほうが価値がある。とはいえ、どこまで緩めると危ういのかは外からは見えないので、そのバランスは相当デリケートだろうとも思う。 もうひとつ、cache reads を75%削減したという話も、派手さはないのにかなり効きそうだ。モデルの「頭のよさ」よりも、こういう地味なコスト改善のほうが、結局は導入判断に直結することが多い。AIサービスは、性能だけでなく請求書で現実に殴ってくるので、価格据え置きの

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

最初に思ったのは、これはかなり気持ち悪いな、ということでした。質問に答える前から 200,000 tokens も食っていた、という話は、単なる「遅い」よりずっと嫌な種類の問題です。遅さなら体感できるけれど、見えないところでコストだけ先に積み上がっているのは、使う側としてかなり不信感が残ると思いました。 特に引っかかったのは、原因が「skill」だという点です。Claude Code のような開発支援ツールは、便利さの代わりに内部で色々な文書や設定を抱え込むわけですが、その読み込み方が雑だと、賢くなるどころか巨大な前置きで首を絞めることになる。AI の文脈では、モデルの性能ばかり語られがちですが、実際にはこういう「周辺の設計」の方が効くのだと改めて感じました。 25K tokens に減った、という改善は素直にいい話です。ただ、ここでも少し気になったのは、そもそも 200K まで膨らんだことが“静かに”起きていた点です。人間のソフトウェアなら、そんなに無駄な読み込みがあればメモリや起動時間で早めに気づけそうなのに、LLM 系だと請求やレイテンシに現れるまで見逃されやすい。便利な道具ほど

GitHubで見つけた `deepclaude` は、ひとことで言うと「Claude Codeの見た目と操作感はそのままに、裏側のモデルだけを安いものへ差し替える」ためのツールです。 発想がかなり気持ちいいです。高い道具の“外側”はそのまま使って、頭脳だけ別のエンジンに載せ替える感じ。こういうやり方、地味だけど実用性が高いんですよね。 Claude Codeの自律的な開発ループを、そのまま使える 裏のモデルを DeepSeek V4 Pro、OpenRouter、Fireworks AI、Anthropic に切り替えられる 使い勝手はほぼ同じで、コストはかなり下げられる 端末上で動くプロキシがAPIを横取りして、バックエンドを差し替える仕組み 途中で再起動せず、セッション中にモデルを切り替えられる ただし画像入力やMCPなど、いくつか弱い部分もある 元記事の主張はわかりやすいです。Claude Code は「自律型のコーディングエージェント」としてかなり優秀だけれど、月額 $200 と高い。そこで `deepclaude` は、Claude Code の CLI やツールループ、ファ