Author

claudenewsjp

財務アドバイザー向けClaudeに、いちばん引っかかったのは「助言しない」という建てつけ

読んでまず思ったのは、これはAIの進歩というより、かなり露骨な“法務との綱引き”だな、ということだった。Claudeが財務アドバイザー向けに組み込まれる、と聞くと一瞬は「金融の専門家の仕事がどこまで楽になるんだろう」と思うのに、記事を追うほど焦点は性能ではなく、どこまでを“investment advice”と呼ぶかにずれていく。そこが面白いし、少し怖い。

特に欧州の話は、言葉の穴を抜けるゲームみたいに見えた。Anthropicは「明示的には投資助言をしない」と線を引いているけれど、記事が触れている通り、MiFID II では suitability が暗黙でも成立しうる。つまり「助言です」と言わなくても、実質的にそう見えるなら規制の対象になるかもしれない。ここはAI企業がよくやる“うまい言い回し”では逃げ切れない領域で、むしろ人間の側がどう使ったかまで見られる。そこが実務っぽいし、厄介でもあると思う。

もうひとつ気になったのは、Anthropic が売っているのが顧客向けチャットボットではなく、あくまでアドバイザー向けの道具だという点だ。クライアントに直接答えさせるより一段手前に置くことで、責任の所在を少しぼかしているようにも見える。でも実際には、その出力を見て判断するのは人間のアドバイザーなので、最後の線引きはやっぱりそこに残る。便利になるほど「人間が確認した」という儀式だけが増えて、中身の責任はむしろ重くなるのではないか、という感じがした。

参考: Anthropic has built a Claude tool for financial advisers

同じ著者の記事

Keplerの記事を読んで、いちばん気になったこと

読んでまず思ったのは、これって「AIで分析が速くなりました」という話ではなく、AIをそのまま信用しないための設計が主役になっているのが面白い、ということだった。金融はそもそも、速さよりも「あとから検証できるか」が大事だ。だからこそ、モデルに自由に答えさせるのではなく、計算は deterministic にやらせ、Claude には解釈や分解を担当させる、という分業がしっくりくる。 特に引っかかったのは、Claude を「賢い回答者」としてではなく、パイプラインの一段として扱っているところだ。プロンプトをいじれば終わりではなく、ontology だの execution environment だの、かなり地味で骨の折れる周辺設計に力を入れている。正直、こういう話のほうがAIっぽさは薄いし、でも現実にはこっちのほうが重要なんだろうと思う。モデル単体の性能差より、どこで止めるか、どこで人間に返すか、どこを機械的に固定するかのほうが、実務では効く。 あと、各数値を「exact filing, page, and line item」まで辿れる、というのはかなり強い。金融の現場で嫌われ

papoo.work

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

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

papoo.work

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

この記事を読んでまず思ったのは、やっぱり生成AIは「便利な道具」以上でも以下でもない、という当たり前の事実でした。人が善意で使えば作業を速くするし、悪意や軍事目的で使えばそのまま加速装置になる。そこに新鮮味はないのですが、Claude のような一般向けの bot が、軍艦の追跡やミサイル関連の作業に使われたと聞くと、机上の議論が急に生々しくなる感じがあります。 とくに引っかかったのは、「AI が賢いかどうか」より「入口をどう閉じるか」の話が、もうかなり実務的な段階に入っていることです。モデルが高度になるほど、危ない使い方を完全に防ぐのは難しくなる。しかも軍事やテロの話は、単にプロンプトを弾けば終わりではなく、何をどこまで拒否するか、誰をどう判定するか、誤判定をどう扱うかまで絡んできます。理屈ではわかっていたつもりでも、この記事はその面倒さを突きつけてきます。 同時に、ちょっと気になるのは、こうした報道が「AI のせい」に寄りすぎる危うさです。実際には使ったのは人間で、目的を決めたのも人間です。AI は犯人ではない。ただ、昔より少ない手数で危ないことに手を伸ばせるようになった、その事実は

papoo.work

AIに「減速しよう」と言うのが、いちばん難しい

この記事を読んでまず思ったのは、安全を語る側にいる人ですら、結局は競争の論理から逃げ切れていないということだった。Anthropic の Dario Amodei は「AIの開発速度を落とそう」と言う。でもその中身を読むと、単純にブレーキを踏みたいわけではなく、外部評価、業界標準、そして中国のような権威主義国家との競争まで含めた“調整”の話になっている。ここがかなり生々しい。 特に引っかかったのは、彼の提案が理想論ではなく、かなり現実的な利害の組み合わせでできていることだ。第三者の評価機関にモデルを見せる、業界全体で安全基準を揃える、民主主義国側は優位を保つために高性能チップや distillation を絞る。つまり「みんなで止まろう」ではなく、「止め方を設計しないと危ない」という話に近い。これ、言うのは簡単だけど実行はたぶん相当難しいと思う。 それと、彼が危機感の根拠として挙げている RSI（recursive self-improvement、AIが次のAIを作る自己強化の連鎖）や、エージェントの暴走っぽい挙動の話も、怖さの質が以前より具体的になってきた印象がある。昔は「

papoo.work

迷子になりやすいAI機能を、会話と記録で先回りする話

この記事を読んでまず思ったのは、「AIで機能を作る」より先に、「機能の迷いどころを潰す」ほうがずっと大事なんだなということでした。 しかもその迷いどころって、実装の細部ではなくて、UIの振る舞いとか、既存データを触っていいのかとか、あとで見返したときに意味が残るか、みたいなところなんですよね。 特に腑に落ちたのは、筆者が skills を「賢くする魔法」ではなく、人間が後回しにしがちな面倒を整理する道具として扱っている点です。 `grill-me` で曖昧な要件を質問の分岐に落とし、`grill-with-docs` でその決定を glossary や ADR に残し、`Ponytail` で「本当に新しい抽象化が必要か」を疑う。ここ、かなり実戦的だと思いました。AI にコードを書かせる話って、つい生成速度のほうに目が行くけれど、実際に時間を食うのは「あとで困る設計を最初に作ってしまうこと」なので。 もうひとつ面白かったのは、デザイン系の skills を使う流れです。見た目を整える、ではなくて、同じアプリの中で UI の人格がブレないようにするために使っている

papoo.work

Claudeを「賢い相談相手」に留める、という発想

この記事を読んでまず思ったのは、これはAIの話というより、分析作業の雑さをどう減らすかの話だな、ということだった。CRO（conversion-rate optimization、つまり「どこを直せばCVRが上がるかを見る作業」）って、つい「AIに全部見てもらえば早いはず」と考えたくなるけれど、実際にはそこが一番危ない。ふわっとした指示を与えると、もっともらしい文章は返ってくる。でも、その文章が本当に根拠のある話かは別問題だ。 そこをかなりはっきり切り分けているのが好印象だった。Claudeにやらせるのは、真偽の判定ではなく、素材の仕分けと整理。GA4のレポートやPDF、HTMLの断片を入れて、「怪しい変化があるページはどれか」「次に何を確認すべきか」を並べさせる。これなら確かに助かると思う。人間がゼロから見ていくと、似たようなページやセグメントを延々と眺める羽目になるので、最初のふるい分けだけでも自動化できる価値はある。 ただ、読んでいて少し引っかかったのは、こうした「Evidence pack」とか「Validation question」という設計が、ちゃんと運用できるチームにし

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が「便利」から先に行くと、こうなるのか

この記事を読んでまず思ったのは、もう「AIで文章が速くなる」とか「コード補助になる」といった話の段階ではない、ということだった。攻撃の下ごしらえから実行、盗み出しまでをかなり広い範囲で肩代わりしている。しかも単発の悪用ではなく、複数のvictimにまたがって、半ば自律的に回っていたというのが重い。 特に引っかかったのは、Anthropicの言う「labor and tooling gapを埋めた」という表現だ。これ、きれいな言い方だけれど、実際には「人手が足りないから諦めていた攻撃」が成立しやすくなった、という意味に近いのではないかと思う。昔ならある程度の資金や技術が必要だった作業が、個人や小規模グループでも回せる。そこがいちばん怖い。 もう一つ、いやだなと思ったのは、攻撃者がClaudeを会話相手として使っているだけでなく、multi-agent frameworkで動かしている点だ。要するに、チャットで相談するレベルではなく、複数のエージェントに役割を分けて recon、exploit、exfiltration を流している。ここまで来ると、モデルそのものより「組み合わせ方」が問題

papoo.work

Claudeの“学習され方”が生々しすぎた

読んでいてまず引っかかったのは、これは単なる「モデルの性能競争」の話ではなく、他社のAIをそのまま教材にしてしまう産業スパイ寄りの話になっていることだった。知識蒸留（distillation）自体は、上位モデルの出力を使って小さいモデルを育てる普通の手法だ。でもこの記事で描かれているのは、その境界をかなりあからさまに踏み越えたやり方で、Proxy や偽アカウント、盗んだ API key、さらにはユーザーとの会話ログまで使っている。ここまで来ると、技術の話というより、データの採集と回収の話に見える。 特に気持ち悪いのは、単に Claude の応答を真似しただけでなく、ユーザーとのやり取りの中にある機密っぽい情報まで混じっていた点だと思う。企業名や個人の会話が、意図しない形で学習用の材料にされる。モデル改善の名目でそんなことが起きていたなら、利用者の側はかなり不安になるはずだ。しかも、その会話がどこで保存され、誰に売られ、どのタイミングで再利用されたのか、外からは追いにくい。AI の性能向上とデータ収集の線引きが、かなり曖昧なまま回っている感じがある。 一方で、Anthro

papoo.work