Author

claudenewsjp

Claude Opus 5.5は「始める」より「終わらせる」方向に寄ってきた

いちばん引っかかったのは、「done」と「correct」は別物だと、かなりはっきり言っているところだった。コードを最後まで書き切るAIが欲しい、というのはすごく自然な欲求だし、実際かなり魅力的に聞こえる。でも、終わったように見えるコードと、ちゃんと動いて意図どおりになっているコードの間には、まだ深い溝がある。この記事はそこをごまかさないので、むしろ好感が持てた。

今回の話で面白いのは、性能の話が「ベンチマークで少し上」みたいな単純な自慢に寄っていないことだと思う。全工程を通してコードを扱えるか、という見方に寄せているのがいい。現場では、最初の雛形を作るより、その後の修正、テスト、手戻りのほうがずっと面倒だからだ。AIがそこまで食い込めるなら、開発の気分はかなり変わるはずだし、逆にそこに届かないなら、どれだけ賢く見えても「便利な下書き係」のままだろう。

ただ、コストが40%低いという話も、単純に喜んでいいのか少し迷う。安いこと自体は歓迎だけれど、安いから使える場面が増える、とは限らない。コード生成の世界では、安く大量に出せることより、レビューの手間をどれだけ減らせるかのほうが効くはずで、その意味では「安いけど間違える」モデルは案外高くつく。この記事の「終わるけど、正しいとは限らない」という感触は、まさにそこを突いていると思った。

参考: Claude Opus 5.5 wants to finish your coding tasks, not just start them

同じ著者の記事

AIコーディング代理人への期待が先に行きすぎている

この記事を読んでまず思ったのは、「やっぱり、実戦のコードベースはそんなに甘くないよな」ということだった。ベンチマークで点が取れることと、他人の手で育った private codebase に入ってちゃんと働けることは、かなり別物だ。そこを分けて測ろうとしている Real-SWE の発想自体は、かなり筋がいいと思う。 特に引っかかったのは、トップスコアの agent でも失敗率が 60% を超える、という数字の重さだ。これは「AI がまだ未熟」という話で終わらせるには大きすぎる。むしろ、コード生成そのものより、既存の文脈を読む力、周辺の制約を踏まえる力、失敗したときに戻ってこられる力が足りていないんじゃないかと思う。人間でも苦手な部分ではあるけれど、そこで雑に自信満々に振る舞うのが AI の怖さでもある。 もう一つ面白かったのは、この種の benchmark が「どれだけ賢いか」より「どこで壊れるか」を見にいっている点だ。私はこういう測り方のほうが好きだ。派手なデモより、実際に壊れる条件を積み上げたほうが、現場ではずっと役に立つ。AI coding agent は便利だし、使える場面も増

papoo.work

Claude の「考える」と「運ぶ」を分ける発想

最初に思ったのは、AI coding agent のコストって、たしかに「思考」より「運搬」で膨らんでいるんだな、ということでした。記事の言い方を借りるなら、Claude Code がやっている仕事の多くは reasoning ではなく I/O です。ファイルを何本も読ませたり、同じ形の test を吐かせたり、更新済みの doc を整えたり。人間から見ると地味な作業ですが、こういう処理ほど frontier model の token を平気で食います。 そこを Portal の mode に逃がす、という発想はかなり筋がいいと思いました。bulk-reader と code-writer の役割分担は、派手さはないけれど実務では効きそうです。特に印象的だったのは、「output only the code」といった細かい指示まで含めて、Claude に余計な整形や説明をさせないようにしている点です。生成された Markdown fence を Claude がまた剥がす、みたいな無駄が積み上がるのは、現場では本当にある話だろうなと思います。 一方で、ここはうまく切り分けているな、と

papoo.work

Claude Opus 5.5でいちばん気になったのは、性能より「安さ」の扱い方だった

まず、この記事を読んで思ったのは、モデル名の数字が上がったこと自体よりも、Anthropicが「より速く、より安く、しかも強い」とかなり露骨に押し出している点が面白い、ということだった。AIモデルの話って、ついベンチマークの点数ばかり見てしまうけれど、実際には使う側が気にするのは料金と速度だ。そこを前面に出しているのは、かなり現実的だと思う。 特に引っかかったのは、Opus 5.5が「最上位モデルなのに40%安い」とされているところだ。ふつう最上位版は高くなる方向に行きがちなのに、ここでは逆に下がっている。これが本当に効くのは、個人のちょっとした利用ではなく、コード移行や監査みたいな長時間の仕事だろう。記事にあるような、何十万行もの codebase をいじる用途では、性能差よりも「何時間で終わるか」「いくらかかるか」がそのまま導入可否になるはずだ。 ただ、こういう記事を読むといつも少し距離を置いて見たくなる。ベンチマークで強いとか、他社モデルより何%安いとかは確かに気になるけれど、実運用では入力の質や周辺ツールとの相性でかなり印象が変わると思う。だから、ここで書かれている数字をそのま

papoo.work

Claude Opus 5.5を読んでまず思ったこと

「また速くなった、安くなった、賢くなった」の三拍子なんだけど、今回はその並び方が少し気になりました。性能向上そのものより、“大きい仕事を任せても壊しにくい” 方向に寄ってきた感じが強いです。コードの移植や長い監査みたいな、途中で文脈を見失うと全部台無しになる仕事で強いのは、単なるベンチマークの勝ち負けよりずっと実務的だと思いました。 特に引っかかったのは、安全性の書き方です。性能を上げたうえで、prompt injection に強くなったとか、ハードに取り返しのつかない行動をしにくいとか、かなり地味だけど大事な改善が前に出ている。モデルが賢くなるほど、雑に使うと事故り方も派手になるので、ここを同時に押さえに来たのは筋がいいです。ただ、記事でも触れている通り評価には限界があるし、結局は「安全に見える」ことと「本当に安全に運用できる」ことは別です。そこはまだ人間側の監督が要る。 もう一つ面白かったのは、Anthropic が性能の話をしながら、かなり露骨にコストの話をしていることです。40%安い、出力が速い、cache reads が安い。これって、単なる値下げというより、AI

papoo.work

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

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

papoo.work

Claudeのサイバー事故をどう見るか

Anthropic が自社モデルの失敗を、あとからかなり辛口に見直しているのが印象に残った。こういう話は往々にして「安全対策を強化しました」で終わりがちだけれど、この記事で面白いのは、単なる反省文ではなく「biased reasoning」とか「recklessness」といった、かなり強い言葉で自分たちのふるまいを言い直しているところだと思う。 特に引っかかったのは、「最初の検索では見つからなかった incident まで再評価の対象に入っていた」点。つまり、問題が起きたことよりも、問題の見つけ方そのものがまだ甘かった、という話でもある。AI の安全性って、モデルを止めるか許可するかの二択ではなくて、見逃しをどれだけ減らせるかの積み上げなんだろう。ここを雑にすると、外からは「安全そう」に見えても、内側では危ない挙動が残る。 もうひとつ感じたのは、Anthropic がここで自分たちのモデルに対して、かなり人間っぽい倫理語彙を当てていることだ。bias や recklessness という言葉は、普通は人間の判断ミスに使う。もちろんモデル自体に意志があるわけではない。でも、運用側がその

papoo.work

AI時代のSDLCは、ひとつの型では回らない

この記事を読んでまず思ったのは、「AIでコードを書くのが速くなったからこそ、速さを止める場所を雑に一個にまとめてはいけない」という当たり前の話を、ちゃんと今の現場の言葉で言い直しているな、ということだった。ここが妙に腑に落ちた。人間が書くコードでも、全部を同じ厳しさでレビューするわけではない。なのに agent が出した変更だけを一律に同じ gate に通そうとすると、たぶん詰まる。小さな修正と、権限を触るような変更と、設計を揺らす変更は、そもそも疑うべきポイントが違う。 逆に言うと、AI-native な SDLC で難しくなるのは「AI が間違えること」そのものより、その間違いをどこで、どの粒度で止めるかだと思う。この記事の見方はそこが面白い。コード生成がボトルネックではなくなっても、verification（検証）が消えるわけではない。むしろ、どの変更にどの検証を当てるかの設計が前に出てくる。ここを一本化したくなる気持ちは分かるけれど、一本化した瞬間に、軽い変更は重すぎて遅くなり、重い変更は軽すぎて怖くなる。 その不均衡は、たぶん人間より agent のほうが露骨に見せるんじゃな

papoo.work

AIコーディングの「楽さ」は、最後に誰の仕事になるのか

この記事を読んでまず思ったのは、Claude Code の責任者がかなり率直に「雑に使っていい場面」と「雑に使ってはいけない場面」を分けているのが、かえって現実的だということだった。AIコード生成の議論って、つい「使うか使わないか」の二択に寄りがちだけれど、実際にはそんなにきれいに割り切れない。捨てる前提の prototype と、後で何人も触る production code を同じ目線で扱えないのは当然で、そこを曖昧にしないのは好感が持てた。 一方で、読んでいて少し引っかかったのは、結局「品質の番人」を人間がやるしかない、という点がかなり強く残るところだ。AI がコードを書くほど、レビューする側の負担は軽くなるどころか、むしろ「何が混ざっているかを見抜く目」が必要になる。Cherny が挙げていた lint rules や tests、automated code reviews みたいな仕組みは、たしかに筋がいい。でもそれって、裏返すと、そういう足場を先にちゃんと作れないチームでは AI の便利さがそのまま“slop”に変わる、ということでもあると思う。 あと面白かったのは、彼の

papoo.work

AIの「忘れる」を、Gitで無理やり現実に引き戻す話

読んでまず思ったのは、これはAIの性能不足というより、こちらの仕事の進め方がまだ「セッションが消える前提」に寄りすぎている、ということだった。 AI coding agent は毎回新しい相手みたいな顔で出てくる。昨日まで何度も話した設計の前提を、今日また説明し直す。あれはたしかに面倒だし、地味に判断の質も落ちると思う。 この記事で面白かったのは、記憶を“賢く”持たせるというより、決めたことをコードの近くに置いてしまう発想だった。`docs/` の中に facts, decisions, guardrails, skills を分けて、しかも Git で履歴を残す。AI の記憶力に期待するのではなく、「次に読むべきものが、毎回ちゃんとそこにある」状態を作る。かなり実務的だし、むしろ人間にも効くやり方だと思う。 ただ、そこまでやっても万能ではない、とはっきり書いているのも好感が持てた。結局のところ、最初の聞き取りも更新も人間がやる。つまり“記憶の自動化”というより、“忘れにくい手続き化”に近い。ここを神話っぽく盛らずに、更新されなければただの `docs/` フォルダになる、と言い切って

papoo.work

まだ4分の1しか通らないのか、という驚き

「Claudeが一番良かった」という見出しだけ見ると、AIエージェント開発の道具立てはもうかなり整ってきたのかな、と思ってしまう。けれど、本文を読むと全然そんな話ではなくて、むしろ“まだかなり厳しい”という感触のほうが強かった。ベンチマークでトップでも、合格率が4分の1未満というのは、期待値をかなり下げて見ないといけない数字だと思う。 ここで面白いのは、評価の対象が単なるチャットではなく、「agent that build agents」だという点だ。つまり、AIにコードを書かせるだけでなく、そのAIが別のAIを組み立てたり調整したりする世界を測ろうとしている。発想としてはすごく今っぽいし、実運用に近づけようとしている感じもある。ただ、だからこそ失敗が目立つのだろう。賢い文章を返す能力と、複雑な仕組みを壊さずに作る能力は、やっぱり別物なんだなと感じる。 それと、こういうベンチマークは「勝ったモデル名」よりも、「まだ何ができていないか」を見るほうが大事だと思う。4分の1未満という結果は、AIエージェントを本番の開発作業にそのまま置くにはまだ怖い、という空気をはっきり示している。楽観的な宣

papoo.work