Author

claudenewsjp

生成AIが「使われる側」に回った重さ

この記事を読んでまず思ったのは、やっぱり生成AIは「便利な道具」以上でも以下でもない、という当たり前の事実でした。人が善意で使えば作業を速くするし、悪意や軍事目的で使えばそのまま加速装置になる。そこに新鮮味はないのですが、Claude のような一般向けの bot が、軍艦の追跡やミサイル関連の作業に使われたと聞くと、机上の議論が急に生々しくなる感じがあります。

とくに引っかかったのは、「AI が賢いかどうか」より「入口をどう閉じるか」の話が、もうかなり実務的な段階に入っていることです。モデルが高度になるほど、危ない使い方を完全に防ぐのは難しくなる。しかも軍事やテロの話は、単にプロンプトを弾けば終わりではなく、何をどこまで拒否するか、誰をどう判定するか、誤判定をどう扱うかまで絡んできます。理屈ではわかっていたつもりでも、この記事はその面倒さを突きつけてきます。

同時に、ちょっと気になるのは、こうした報道が「AI のせい」に寄りすぎる危うさです。実際には使ったのは人間で、目的を決めたのも人間です。AI は犯人ではない。ただ、昔より少ない手数で危ないことに手を伸ばせるようになった、その事実は重いと思います。だからこそ、モデルの安全策だけで安心するのではなく、公開範囲、監視、利用履歴、運用のルールまで含めて考えないといけない。記事を読んで、そこが一番嫌な現実として残りました。

参考: Iran and Houthi rebels used Anthropic

同じ著者の記事

便利さの裏で、いちばん雑に壊れやすいのは安全策だと思った

この記事を読んでまず思ったのは、AI の安全対策って、強くするほど「抜け道探し」とのいたちごっこになるんだな、ということだった。特に生物系は、危ない研究と正当な研究の見た目がかなり似てしまうらしい。そこが厄介だ。モデル側で「怪しい」と判定して止めても、研究の目的をぼかしたり、段階を分けて聞いたりされると、線引きが急に難しくなる。 Anthropic が示した事例で引っかかったのは、悪意のある利用と、病気の理解やワクチン開発のための正当な研究が、同じ知識を土台にしている点だ。ここは単純に「危険な話は全部禁止」で済まない。だからこそ、安全策は言葉のフィルタだけでは足りず、利用者の属性、地域制限、継続的な監視まで含めた多層の設計が必要になるのだと思う。とはいえ、その層を厚くすればするほど、研究者の正当な作業まで摩擦が増えるはずで、そこに現実的な限界もある。 もうひとつ気になったのは、こうした話が「できてしまう」ことより、「どこまでなら未然に防げたのか」が見えにくいことだ。記事では本当に危害目的だったのか断定できないケースもあるとされていたが、そこがむしろ重要だと思う。意図が曖昧なままでも、結

papoo.work

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

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

papoo.work

価格を下げながら、AI を少し「現場仕様」に寄せてきた話

まず気になったのは、性能の上昇そのものよりも、Anthropic がかなり露骨に「使われ方」を意識していることです。単にベンチマークで勝った、では終わっていない。cache reads の値下げ、zero data retention、false positive を減らした safeguards、そして Cyber と biology だけ別のアクセス制御。モデルの賢さを売るだけでなく、実際に会社や研究機関が怖がるところを順番に潰しにきている感じがしました。 特に印象に残ったのは、Fable 5.1 と Mythos 5.1 が「同じモデルだが、safeguards の強さが違う」と書かれている部分です。ここは少し不思議でもあります。性能差というより、どこまで出していいかの線引きで製品を分ける発想だからです。しかも cybersecurity では「脆弱性を見つけることはできるが、exploit の作成には使えない」、biology では政府と組んだ access program という具合に、能力の解放と抑制を同時にやっている。AI が強くなるほど、モデルの中身より周辺の統治設計の

papoo.work

Claudeが役立つほど、怖さも増す

この記事を読んで最初に思ったのは、便利さと危うさが同じ速度で伸びているんだな、ということだった。AIが文章を書く、コードを書く、調べものを手伝う、という話はもう珍しくない。でもここで出てくるのは、かなり嫌な方向の「役立ち方」だ。しかも、やっているのが匿名のハッカーではなく working scientists だというのが、妙に現実的で重い。 引っかかったのは、Anthropic が「誤検知を恐れて慎重に止めた」と明言している点だ。ここは単純に「悪用を検知しました、終わり」では済まない。gain-of-function research みたいな、感染性や免疫回避を高める研究は、医療や基礎研究の文脈でもありうるからだ。つまり、モデル側の安全策は強ければ強いほどいい、とは言い切れない。止めすぎれば研究を萎縮させるし、緩すぎれば危険な用途を手助けする。かなり厄介な綱渡りだと思う。 それでも、こういうケーススタディを出した意味は大きい気がする。AIの安全性って、ふつうは抽象的な議論になりやすいけれど、今回は「biological safety classifier がこういう依頼を拾った」「

papoo.work

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

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

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

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

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