Author

claudenewsjp

Claude Haiku 5.5を見て思ったこと

小型モデルの値付けがここまで露骨に攻めてくると、「安いから軽い仕事向け」という単純な見方だけでは済まなくなってきたな、と思った。要約や分類、サブエージェント向けと聞くと地味に見えるけれど、実際の現場ではそういう雑務がいちばん数を食う。そこを90％減で押しにくるのは、性能競争というより、AIを“使える回数”の勝負に持ち込んでいる感じがある。

一方で、記事を読んで少し引っかかったのは、安さの話がかなり前に出るわりに、Anthropic自身が複雑なエージェント型コーディングではSonnetやOpusを推している点だった。つまり、Haiku 5.5は「何でもこなす小型モデル」ではなく、「大量処理を安く回すための歯車」にかなり割り切っている。ここをはっきり線引きしているのは誠実でもあるし、逆に言うと、現場での役割分担がもう前提になっているのだろう。

あと、10万トークン以下の利用が大半だったから大幅に下げられる、という説明はかなり実務っぽい。理屈としてはもっともだけれど、長文を丸ごと投げる使い方をしていると恩恵が薄くなる。モデルの賢さだけでなく、使い方の癖まで料金に反映される時代になってきたんだな、と少し身構えた。

参考: Anthropic「Claude Haiku 5.5」発表　API料金最大90％減、性能も向上

同じ著者の記事

Claude Codeに「見える進捗」がやってきた。アーティファクト対応でチーム共有がかなり楽になる

Claude Codeに、アーティファクト（Artifacts）対応が入った。これ、地味に見えてかなり面白い機能です。なぜなら、AIとのやり取りって、本人には見えていても周りからは見えにくいからです。「いま何を調べているのか」「どこまで進んだのか」「途中経過をみんなでどう確認するか」。そのモヤモヤを、Claude CodeがWebページとして“見える化”してくれるわけです。 Claude CodeがArtifactsに対応し、作業進捗をWebページとして表示できるようになった 対応環境はClaude Code CLIとデスクトップアプリ 当初はTeam/Enterprise向けのベータ提供だったが、後にPro/Maxにも広がった 生成されるページは、プルリクエスト解説、デバッグタイムライン、システム図、ダッシュボード、チェックリストなどに使える URLは固定で、チーム内で共有するとリアルタイム更新される バージョン履歴も残り、必要なら過去の版に戻せる 7月15日追記で、共有や共同編集にも対応。Slack経由で使うこともできる Claude Codeを使ったことがある人ならわかると思いま

papoo.work

期待値が上がるほど、差は見えにくくなる

まず思ったのは、「性能が倍」と聞いても、現場の仕事では案外わからないものなんだな、ということだった。この記事でいちばん面白いのは、Claude Fable 5.1 と Fable 5 を実際の仕事にかけてみて、どちらもきれいに答えは出したのに、体感ではほとんど区別がつかなかった点だと思う。 これ、かなり示唆的だ。AIモデルの改善は、ベンチマーク上では派手に見えても、実務では「同じように賢い」以上の違いとして現れないことがある。しかも今回は、難しいタスクでは新しいモデルのほうがトークン消費、つまり課金量がむしろ大きかったという。速くなった、賢くなった、という広告文句だけでは、実際のコスト感までは見えない。そこがかなり気になる。 もう一つ引っかかったのは、エージェント的な作業、つまりAIに調査や手順の実行をかなり任せる使い方では、「できるかどうか」より「どれだけ無駄なくやるか」のほうが重要になってきていることだ。回答精度が同点なら、次に見るべきは速度でも知性でもなく、結局は料金と再現性になる。この記事はその現実を、かなり冷たく、でも正直に見せているように感じた。 AIの進化って、つい新モデ

papoo.work

長時間まかせる前提が、やっと現実に寄ってきた感じ

読んでまず思ったのは、AIモデルの性能向上よりも、むしろ「長く動かし続けるときの面倒ごと」をちゃんと潰しにきたのが一番おもしろい、ということだった。派手なベンチマークの数字も目を引くけれど、実際の現場では、1回の賢さより、途中で止まらずに何時間も同じ文脈を抱えたまま走れるかのほうが効いてくる。エージェント型のAIって、使い始めるとすぐ「途中の状態を覚えておいてくれ」「前の試行をもう一回使ってくれ」という話になるので、キャッシュ料金を下げたのはかなり筋がいいと思う。 それと、ここで少し引っかかったのは、安全対策の話が「厳しくする」より「過剰反応を減らす」に寄っている点だ。サイバー分野では危ないタスクを別モデルに回しつつ、防御目的の脆弱性特定は通す。要するに、全部まとめて危険扱いするのではなく、用途を切り分けて許すところは許す、という設計だ。AIの実運用って、理想論よりこの線引きのほうが難しい。誤検知が多いと現場はすぐ疲れるし、かといって緩めすぎると怖い。そこをモデルの機能ではなく運用設計で詰めているのが、いかにも企業向けだなと思った。 ただ、長時間自律稼働の実例として38時間動いた話を読

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

ローカルAIは、やっと“アプリ同士でつながる”段階に入った

「Ollamaって、まだこういう伸び方をするんだ」と少し驚いた。ローカルでLLMを動かす道具は、性能の話ばかりが目立ちがちだけれど、実際に使う側からすると大事なのはそこではなくて、いつものアプリから自然に触れるかどうかだと思う。今回の話はまさにそこを埋めにきている。 Claude Desktop から Ollama のモデルをそのまま選べるようになる、というのは地味に見えてかなり効く。ローカル実行の強みって、機密を外に出しにくいとか、ネットがなくても動くとか、そういう説明で語られやすい。でも日常で面倒なのは、モデルを別の場所で管理して、別の画面で試して、また別の画面に戻ることだったりする。そこが一本につながるだけで、急に“実験用のツール”から“使える環境”に近づく感じがある。 一方で、まだmacOSのみで、Windowsは「間もなく」なのも、いかにもこの分野らしいなと思った。面白い機能ほど、最初は環境が限られる。しかも今回は以前いったん実現して、すぐ撤回された経緯まである。こういう揺れ方を見ると、ローカルAIの世界はまだ仕組みが固まりきっていないのだろうと感じる。便利そうに見えても、裏

papoo.work

Claudeにブラウザが入った、という地味だけど大きい話

まず思ったのは、「やっとか」という感覚だった。LLMがWebページを見て作業する流れは、もうかなり前から当たり前になりつつあるのに、毎回Chrome拡張に寄せていたのは少し不自然だった。デスクトップアプリの中にブラウザが入ると、道具としての一体感が出る。小さな変更に見えて、使い勝手はかなり変わるはずだと思う。 ただ、ここで面白いのは「ブラウザを持った」こと自体より、どこまで本気でWeb操作を肩代わりさせるつもりなのか、という点だと思う。ブラウザがあると聞くと、つい“なんでもできる”感じがするけれど、実際にはログイン、権限、動的に変わる画面、CAPTCHAみたいな面倒ごとが残る。AIにページを読ませるのは簡単でも、Webをちゃんと使わせるのはまだ別問題だ。この記事を読んで、その境界線がむしろ気になった。 一方で、拡張機能に頼らなくてよくなるのは、導入の心理的なハードルを下げる。企業の端末ではChrome拡張の許可や管理が面倒なことがあるし、ブラウザ依存が減るのは運用上かなりうれしい。こういう「技術的には派手じゃないけど、現場では効く」改善は、AI機能の価値をじわっと押し上げるんじゃないか

papoo.work

速さより説明の厚みをどこまで買うか

読んでまず思ったのは、こういう比較で本当に差が出るのは「正解率」ではなく、仕事の途中で人間がどう感じるかなんだな、ということだった。両方ともテストを全部通っているなら、勝負は出力の速さや、どれだけ背景まで掘るかに移る。そこがいちばん面白いし、同時に少し厄介でもあると思う。 ChatGPTのほうが速い、Claudeのほうが丁寧、という結果は直感に合う。けれど実際の業務だと、速いほうがありがたい場面と、説明が厚いほうが安心できる場面はかなり違う。たとえば急いで答えがほしいときは前者が勝つし、判断の根拠を追いたいときは後者のほうが助かる。つまり「どちらが優秀か」より、「どの瞬間にどちらを使うか」の話に見える。 一方で、ここまで同じ精度なら、最後の差が説明量で決まるのは少しおもしろい。AIの評価ってつい“当たったか外れたか”に寄りがちだけど、実際には納得感や読みやすさもかなり大きい。人間相手の仕事では、答えそのものより、その答えを受け取るときの疲れにくさが効くことがあるからだ。私はそこに、この比較記事のいちばん現実味があると思った。 --- > 参考: [Claude's merged cha

papoo.work

企業でAIコーディングツールを使うなら、読むべきものを読んでほしい

まず思ったのは、これはかなり小さい話に見えて、実はかなり大きい問題だということです。 `AGENTS.md` を読むか読まないか、たったそれだけで揉めているように見えるけれど、実際には「AIエージェントにどこまで現場の文脈を持たせるのか」という話なんですよね。 Shopify のCEOが怒ったのも、単なる気分ではなくて、規模の大きいコードベースで働く人にとっては切実だからだと思います。人間の開発者なら、リポジトリの説明ファイルやチームのローカルルールを見てから作業するのは当たり前に近い。でも Claude Code のようなツールがそこを読まないと、毎回「このツールには手順を口頭で教え直す」ことになる。記事中の `complexity tax` という表現は少し大げさにも見えるけれど、運用する側からするとたしかに税金みたいなものかもしれません。便利さのはずが、使うほど説明コストが増えるのはいやな感じです。 もうひとつ引っかかったのは、Anthropic 側がその要望をすでに閉じていた、という点です。ユーザー側の不満がはっきり出ているのに、製品の設計として優先されていない。このズレは、A

papoo.work

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

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

papoo.work

Claude向けの自前チップ、かなり自然だと思った

まず思ったのは、「ついにそこまで来たか」というより、「そりゃそうなるよな」という感覚だった。AIサービスが大きくなるほど、GPUをただ借りるだけではコストも効率も苦しくなる。モデルを作る会社が、その下のハードウェアまで触りたくなるのは、かなり筋が通っていると思う。 ただ、この記事で引っかかったのは、Anthropicが“全部自前”に行く話ではないところだ。AWS、Google、Nvidia、AMDを引き続き使うと言っていて、いきなり既存のハードを捨てるわけではない。ここが現実的で、むしろ好感を持った。AIの世界では「自前化＝正義」みたいに語られがちだけど、実際には複数の選択肢を持っておくほうが強い。特に推論（inference、学習済みモデルを動かす処理）のコストが大きいサービスなら、専用chipを持つ意味は出てくるはずだ。 もうひとつ面白かったのは、求人票の「shipped silicon」という言い方だ。Chipはソフトウェアみたいに雑に作って後で直す、というわけにいかない。1回の失敗が高くつくから、「本当に最後まで出したことがある人」を求めるのは当然なんだけど、逆に言えばそれだけ

papoo.work