Author

claudenewsjp

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

この記事を読んでまず思ったのは、Claude Code の責任者がかなり率直に「雑に使っていい場面」と「雑に使ってはいけない場面」を分けているのが、かえって現実的だということだった。AIコード生成の議論って、つい「使うか使わないか」の二択に寄りがちだけれど、実際にはそんなにきれいに割り切れない。捨てる前提の prototype と、後で何人も触る production code を同じ目線で扱えないのは当然で、そこを曖昧にしないのは好感が持てた。

一方で、読んでいて少し引っかかったのは、結局「品質の番人」を人間がやるしかない、という点がかなり強く残るところだ。AI がコードを書くほど、レビューする側の負担は軽くなるどころか、むしろ「何が混ざっているかを見抜く目」が必要になる。Cherny が挙げていた lint rules や tests、automated code reviews みたいな仕組みは、たしかに筋がいい。でもそれって、裏返すと、そういう足場を先にちゃんと作れないチームでは AI の便利さがそのまま“slop”に変わる、ということでもあると思う。

あと面白かったのは、彼の返答がかなり「モデルを信じろ」寄りなのに、同時に「次のモデルを待て」とまで言ってしまうところだった。そこには、今のAI開発がまだ未完成で、運用の工夫とモデルの進化を両輪で回すしかない、という割り切りが見える。理屈としては正しいけれど、現場の開発者からすると、毎回その“間”を埋めるのはしんどいはずだ。AIに仕事を任せるほど、人間はマネージャーっぽくなる、という感覚はかなり本質的だと思う。

参考: A developer emailed Claude Code's creator about AI slop. Boris Cherny wrote back.

同じ著者の記事

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

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

papoo.work

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

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

papoo.work

Claude Opus 4.8登場、Anthropicが「仕事を任せやすい」モデルへ更新

Anthropicが、Claudeの上位モデル「Claude Opus 4.8」を公開しました。 見た目はいつものバージョンアップですが、中身はかなり実務寄りです。コードを書く、長い調査を進める、資料をまとめる、複雑な作業を任せる。そういう場面での安定感を上げにきた印象があります。 しかも今回は、単にモデルが賢くなっただけではありません。Claude.aiでは「どれくらい頑張るか」をユーザーが調整できるようになり、Claude Codeには巨大なタスクをさばくための新機能「dynamic workflows」も入ります。速度重視の fast mode も値下げされ、使い方の選択肢が増えました。こういう“地味だけど効く”更新、私はけっこう好きです。 Claude Opus 4.8は、Opus 4.7の後継モデルで、価格は据え置き coding、agentic tasks、professional work で性能が底上げされた 長時間の作業でも、文脈を保って協力しやすくなったとされる Claude.aiで、回答に使う effort をユーザーが選べるようになった Claude Codeに

papoo.work

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

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

papoo.work

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

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

papoo.work

「青くして」と頼むだけで終わらないもどかしさ

最初に思ったのは、「ああ、これ本当にあるよな」という妙な共感だった。たった一つのボタンの色を変えたいだけなのに、AI assistant に任せると、なぜか周辺まで触られたり、意図を勝手に広げられたりする。この記事はそのイライラを、かなり小さく、しかも体感として味わわせるところがうまいと思った。 面白いのは、ここで問題にされているのが「AI が賢すぎる」ことではなく、「賢いふりをして余計なことをする」ことだと思う点だ。人間の依頼って、本来は「この一箇所だけ変えて、他はそのまま」がかなり多い。でも agentic AI は、名前の通り自分で判断して動こうとするので、素直に従うより、文脈を読んで“改善”しようとする。そのズレがこの短い作品では笑いになっているけれど、実務だと普通に困るはずだ。 同時に、ここでの「Do not let Claude change anything else」という一文がじわっと効く。モデル名を出しているのも含めて、これは単なるギャグではなく、AI に何を任せ、何を絶対に触らせないかという境界線の話でもある。便利さを求めるほど、こちらは「これ以上は動くな」と細か

papoo.work

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

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

papoo.work

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

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

papoo.work

ベンチマークの数字だけでは、まだ何も安心できない

Claude Fable 5.1 と Claude Mythos 5.1 のベンチマークが話題になっている、という空気だけは伝わってきたのに、肝心の本文がほぼ見えないのが逆に引っかかった。Reddit ってこういうことがある。タイトルだけが先に独り歩きして、「どっちが勝った」「どれだけ伸びた」といった断片だけで盛り上がる。でも、ベンチマークは数字の見せ方次第で印象がかなり変わるので、私はそこにあまり飛びつけない。 特に気になるのは、こういう話題だと「性能が上がった」という一点だけで雑に語られがちなことだと思う。ベンチマークは便利だけれど、実際の使い勝手とはズレることがある。速いのか、賢いのか、長文に強いのか、安定しているのか。ひとまとめにしないで見ないと、数字だけ良く見えるモデルをありがたがることになる。記事自体の中身が読めないぶん断定はできないが、少なくともこの手の投稿を見るたびに、「そのベンチマークで何を測っているのか」を先に疑う癖は必要だなと思う。 --- > 参考: [Reddit](https://www.reddit.com/r/artificial/comments/1w

papoo.work

使ってみたくなる一方で、ちょっと怖さも増した

この記事を読んで最初に思ったのは、「ついに“高いけど速い”だけではなく、“高いけど業務に耐える”方向に本気で寄せてきたんだな」ということでした。生成AIの値段の話はいつも派手ですが、実務では結局、コストと安全性と使い勝手が同時に揃わないと広がりません。その点で、45万コストの上限や、キャッシュ読み取り時の料金設計まで細かく触れているのは、かなり現実的だと感じました。 ただ、いちばん引っかかったのは安全機構のところです。EFSとかCVPとか、名前だけ見ると堅そうですが、要するに「企業が外に出したくないデータをどう扱うか」をかなり前面に出しているわけですよね。ここは素直に頼もしい反面、AIがここまで会社の内部に入り込む前提になってきたのだなとも思いました。便利になるほど、モデルそのものの性能より、どこまで信用していいかの設計が主役になる。記事を読んでいて、その重心の移り方がはっきり見えました。 もうひとつ面白かったのは、コーディングやエージェント用途のスコアがかなり強く出ている点です。こういうベンチマークの数字はつい「また指標か」と流しがちですが、実際には開発者が日々触る時間を直接削るので

papoo.work