Author

claudenewsjp

仕事の輪郭が、少し溶けた感じがする

この記事を読んでまず思ったのは、「便利になった」の一言では片づかないな、ということだった。Claude Code みたいな coding assistant が入ると、単に実装が速くなるだけじゃなくて、仕事の中で人がやるべき部分そのものがずれていく。書く量が減るというより、考える時間の配分が変わる、という感覚に近いと思う。

一方で、そこに少し引っかかりもある。こういう話は聞いていて気持ちがいいし、実際に助かる場面は多いはずだけれど、便利さが強くなるほど「自分がどこまで理解しているか」が曖昧になりやすい。特に code は、動けば終わりではなくて、なぜそうなっているかを追えるかが大事だ。AI がその手前をかなり埋めてしまうと、短期的には楽でも、長い目では人の筋力が落ちないか少し気になる。

それでも、こうした感想が出る時点で、もう無視できない段階に来ているのだと思う。昔は「補助ツール」と言っても、せいぜい autocomplete の延長だった。今は、作業の流れそのものに入り込んで、エンジニアの仕事を再定義し始めている。嬉しさと不安が同時に来るタイプの変化だ。

参考: Reddit

同じ著者の記事

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

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

papoo.work

Claude Codeの技能を84個に分けた話を読んで

まず思ったのは、こういうのは「賢い自動化」というより、かなり地道な整理術なんだな、ということだった。大きなプロンプトを毎回貼るやり方が破綻するのは想像しやすいけれど、その代わりに84個まで分解するのは、発想としてはわりと徹底している。AIに何でも覚えさせるのではなく、必要な文脈だけを都度差し込む、という考え方は筋がいいと思う。 特に引っかかったのは、ここでやっていることが単なる「プロンプトのテンプレ化」ではない点だ。技能ごとに切り分けて、トリガーに応じて読み込ませる。要するに、長い指示文を一枚岩で持つのをやめて、作業単位で知識を分割している。人間の作業メモでも、巨大な一枚の資料より、用途別の短い手順書のほうが使いやすいことが多い。AI相手でも同じなんだろう、と思わされた。 一方で、ここまで細かく分ける運用は、作る側のメンテナンスがかなり大変そうでもある。84個という数字はインパクトがあるけれど、そのまま真似すると管理コストのほうが先に効いてきそうだ。技能を増やすほど楽になる面はあるだろうが、増やしすぎると今度は「どれを直せばいいのか」が難しくなるはずで、そこは記事の爽快さの裏で少し気に

papoo.work

公開発言だけで反トラストを組み立てる怖さ

この記事を読んでまず面白いと思ったのは、企業が「隠れて相談した」話ではなく、むしろ自分たちの公開発言そのものが法廷の材料になっている点でした。普通、カルテルや談合の話というと、内部メールや会議メモが出てくるイメージがあります。でもここでは、表に出た文章や発言のつながりだけで「合意があったのでは」と組み立てている。隠蔽がないぶん潔白に見える一方で、外から見ると逃げ道も少ない。そこがかなり不気味です。 とくに引っかかったのは、「安全のために速度を落とす」という話が、競争法の文脈ではそのまま正当化されないかもしれない、という点です。AIの危険性自体を否定していないのに、複数社で歩調を合わせると一気に“output-restricting cartel”として見られる。つまり、善意の安全策でも、横並びになった瞬間に別の顔を持つわけです。ここはかなり厄介だと思いました。各社が単独で慎重になるのは許されても、業界全体で「少し待とう」を共有すると、競争を止める合意に見えてしまう。安全と競争が真正面からぶつかる場面です。 もう一つ、この記事がうまいなと思ったのは、法的に勝てるかどうかとは別に、「この議

papoo.work

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

まず引っかかったのは、「速い」「安い」「安全性も上がった」が同じ記事の中で自然に並んでいることだった。ふつう、どれか一つを良くすると別のどこかで無理が出る印象があるのに、Anthropic はそこを全部まとめて押し上げたように語っている。もちろん、こういう発表文は盛りがちだし、ベンチマークの数字だけで現実の使い勝手を断定はできない。でも、少なくとも「高性能モデルは高コストで重いもの」という古い前提を崩しにきている感じはある。 それより面白かったのは、モデル名の付け方というか、製品群の切り分け方だ。Opus 5.5 が biology や cybersecurity では Mythos 5.1 相当だから、Fable 5.1 と同じ扱いではなく、同じくらい慎重な safeguards を付けて出す、という説明になっている。ここには、AI を単なるチャットの便利ツールではなく、使い方によってはかなり危ない道具として見ている姿勢がにじむ。性能競争の話なのに、結局は「何をどこまで許すか」の設計が本体なんだな、と思わされた。 あと、応答が 30% 以上速いとか、文章の先頭に重要情報を置いて自然に

papoo.work

ブラウザにAIを入れる話、便利さより先に不安が来た

正直、まず思ったのは「そりゃ便利だけど、そこまで信用していいのか」ということだった。 ブラウザの中でAIがページを見て、クリックして、入力までやる。発想としてはすごく自然だし、たしかに人の手間はかなり減る。でも、ブラウザって今やメールも決済も社内システムも全部集まる場所なので、そこに“操作できるAI”を入れるのは、便利さと危うさが同じ大きさで立ち上がってくる感じがある。 記事で面白かったのは、Anthropicがその危うさをかなり真正面から扱っているところだった。単に「使えます」ではなく、prompt injectionみたいな、Webページ側に仕込まれた命令にAIが引っ張られる問題をどう抑えるかを前提にしている。AIは画面の見えている文字をそのまま信じてしまいがちなので、Webの世界と相性がいいようで実はかなり悪い。ここを“技術の難しさ”として書いているのは、かなり誠実だと思った。 それでも、3層くらいの防御を入れたうえで、一定の条件ではかなり攻めた自動化ができるようにしているのがAnthropicらしい。人間がいちいち面倒を見なくても動く、でも勝手に何でもやらせるわけではない。その

papoo.work

AIコーディングの話なのに、売り文句より先に「道具箱」として見せてきたのがよかった

この記事を読んでまず思ったのは、AIコーディングを“魔法”として持ち上げるのではなく、ちゃんと現場の道具として並べているのが好ましい、ということだった。Claude Code、VS Code、GitHub Copilot、Cursor。名前だけ並ぶと華やかだけれど、記事の温度はかなり実務寄りで、派手な成功談よりも「どう使い分けるのか」「どこに効くのか」に寄っている。その距離感が、むしろ信頼できる。 特に引っかかったのは、「トークン」という言葉を前提にしているところだ。AIの文脈では当たり前でも、普通の開発者にとってはまだ少し抽象的だと思う。要するに、AIが一度に扱える情報量の単位みたいなものだが、それが増えると会話やコード全体をまたいだ作業がしやすくなる。一方で、量が増えれば何でも解決するわけでもない。記事はそこを煽りすぎず、トークンの扱いが実用上の差になる、という線で止めている。その控えめさがよかった。 もう一つ、AIコーディングを「個人の生産性向上」だけで終わらせず、チームや開発プロセス全体の話に接続しているのも印象に残った。AIがコードを書く速さは目立つけれど、本当に面倒なのはそ

papoo.work

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

いちばん引っかかったのは、「性能が上がった」という話よりも、むしろ“使う側の扱いやすさ”にかなり力が入っている点だった。モデルの賢さを競う記事として読むと、40％のコスト減とかベンチマークの順位が目に入る。でも実際には、上限の引き上げやリセット、出力速度の改善、さらに `thinking` を切れなくした設計変更のほうが、日常の使い勝手には効いてきそうだと思った。 特に、`thinking` を無効にできなくしたのは面白い。自由度が減ったようにも見えるけれど、Anthropicとしては「推論の深さは effort で調整してね」という方向に寄せたかったのだろう。ここには、モデルを“何でも好きにいじれる道具”として出すより、一定の作法の中で安定して使わせたい、という意思を感じる。開発者にとっては少し窮屈かもしれないが、事故を減らすには合理的ではある。 それと、ペース調整を訴えるエッセイのすぐ後にこのリリースが来るのも、なかなか象徴的だった。慎重さを掲げつつ、きちんと新モデルは出す。止まる気はないが、無制限に突き進むつもりでもない、という距離感に見える。外部機関の評価やセーフガードの説明が

papoo.work

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

いちばん引っかかったのは、「done」と「correct」は別物だと、かなりはっきり言っているところだった。コードを最後まで書き切るAIが欲しい、というのはすごく自然な欲求だし、実際かなり魅力的に聞こえる。でも、終わったように見えるコードと、ちゃんと動いて意図どおりになっているコードの間には、まだ深い溝がある。この記事はそこをごまかさないので、むしろ好感が持てた。 今回の話で面白いのは、性能の話が「ベンチマークで少し上」みたいな単純な自慢に寄っていないことだと思う。全工程を通してコードを扱えるか、という見方に寄せているのがいい。現場では、最初の雛形を作るより、その後の修正、テスト、手戻りのほうがずっと面倒だからだ。AIがそこまで食い込めるなら、開発の気分はかなり変わるはずだし、逆にそこに届かないなら、どれだけ賢く見えても「便利な下書き係」のままだろう。 ただ、コストが40%低いという話も、単純に喜んでいいのか少し迷う。安いこと自体は歓迎だけれど、安いから使える場面が増える、とは限らない。コード生成の世界では、安く大量に出せることより、レビューの手間をどれだけ減らせるかのほうが効くはずで

papoo.work

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

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

papoo.work

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

いちばん引っかかったのは、「性能が上がった」より先に「安くなった」が前に立っていることだった。AIモデルの新製品発表って、どうしてもベンチマークの数字合戦になりがちだけど、この件はそこよりも「同等級の仕事を、もっと低いコストで回せる」という話が中心に見える。モデルの賢さそのものより、運用の現実に目線が移ってきた感じがする。 その一方で、Anthropic自身が「ベンチマーク差はこのレベルだと当てになりにくい」と言っているのはかなり正直だと思った。数字が細かく並んでいるのに、最後は「実際の差はそこまで大きくない」と自分で釘を刺している。こういう書き方は、派手さはないけれど、むしろ信頼感がある。AIの性能評価って、見栄えのいい表の裏で、実務ではそんなに単純じゃないんだろうなと感じる。 それから、安全面の扱いも気になった。前のモデルで cybersecurity を訓練から外した、という話があった直後に、今回は biology や cybersecurity に近い能力があるので、利用を一部振り分けたり、認証した組織だけに広く開放したりしている。便利さを増やすほど、扱いを絞る必要も増える。こ

papoo.work