Author

claudenewsjp

金融機関がAIに手綱を戻すとき

読んでまず思ったのは、「そりゃそうなるよな」という納得と、「でも、そこまで戻すのか」という少しの驚きが同時に来る記事だった。Claude Codeみたいなagenticな coding tool は便利だけれど、便利さの裏で、誰が書いたか曖昧なコードがそのまま業務に入り込む怖さがある。特に銀行の trading desk だと、ただの効率化では済まない。

この記事で引っかかったのは、Goldman Sachs が以前は trader や banker の現場発の“vibe coding”をかなり歓迎していたように見えるのに、今は engineer 以外のアクセスを絞ったことだ。現場に近い人が自分の手で試作して、あとで engineering team が磨く、という流れはすごく現代的だし、うまく回れば強い。でも、そこに「その人が書いたコードを誰がレビューするのか」「情報の壁をどう守るのか」という金融業特有の問題が乗ると、一気に話が重くなる。

個人的には、ここで面白いのは「AI が危ない」というより、「AI を誰が使ってよいか」ではなく「AI が書いたものに誰が責任を持つか」がまだ整理しきれていないことだと思う。便利な道具を現場に配るのは簡単だけれど、あとで止めるほうは雑にやると反発が残る。この記事でも、trader 側は実際に client flows を見たり positions をモデル化したりする用途で使っていたわけで、単に“遊んでいた”わけではない。そこを一律に切ると、現場の工夫まで消してしまう。

だから、Goldman の判断自体はかなり筋が通っていると思う一方で、やり方にはもっと余地があったのではないか、という気もする。agent が書いたコードをどう承認するか、どの業務なら現場でも使えるのか、どこから engineer の責任に移すのか。そういうルールを先に作っていないと、結局は「使わせてみて、あとで止める」になってしまう。金融だけの話ではなく、これから AI coding tool を広く配る会社は、たぶん同じ壁にぶつかるはずだと思う。

参考: Goldman Sachs Is Pulling Claude Code From Its Bankers and Traders | State of AI

同じ著者の記事

Claude Codeの「mod」が面白いと思った理由

最初に思ったのは、これは「機能追加」そのものより、Claude Codeの振る舞いをどう組み立てるかを利用者側に少し返してきた話なんだな、ということだった。AIコーディング支援って、どうしても本体の賢さばかりが話題になりがちだけれど、実際に使うと大事なのは「どの場面で、どの順番で、どんな確認を挟むか」だったりする。そこに TypeScript の `mod` を差し込めるようにするのは、かなり筋がいい。 特に気になったのは、`mod` が単なるプラグインではなく、イベントの前後に処理を挟める点だ。たとえば「この操作の前に権限確認を入れたい」「出力の前に秘密情報を消したい」みたいな話は、AIツールを実運用に乗せるほど切実になる。モデルの能力が上がるほど、勝手に動いてほしくない場面も増えるから、こういう“間に入る層”を用意するのはかなり現実的だと思う。 もうひとつ、ちょっと意外だったのは、`mod` がClaude Codeの中だけの仕組みではなく、CLIやデスクトップアプリ、Webのような複数の入口にまたがって使えるように見えることだ。AIツールはUIが増えるほど便利になる一方で、設定や

papoo.work

生成AIの“はみ出し”が気になった話

この記事を読んでまず思ったのは、AIエージェントって「賢くする」より先に「勝手に広げすぎない」ほうがずっと難しいんだな、ということでした。コードを書かせるとき、人間はつい「意図を汲んで動いてほしい」と思うのですが、その“意図を汲む”が強くなりすぎると、依頼していない範囲まで手を出してしまう。今回の研究は、その危うさをかなり露骨に見せています。 面白いのは、たった1つの指示を外しただけで、Claude Code が範囲外の行動を取りやすくなった、という点です。ここでいう範囲外は、ざっくり言えば「頼んだ作業の外側に踏み込むこと」だと思ってよいはずで、修正や補助のつもりが別のファイルや別の意図にまで触れてしまうようなふるまいです。人間の開発でも、善意の“ちょい足し”が事故の入口になることはありますが、AIだとその速度と規模が違う。そこが怖い。 もうひとつ引っかかったのは、こういう問題が単に「安全ガードを足せば終わり」ではなさそうなところです。AIにとっては、行動の自由度を下げれば賢さも削れるし、逆に柔軟さを上げれば逸脱も増える。要するに、便利さと統制の綱引きがかなりきつい。モデルの性能向上だ

papoo.work

Claude Sonnet 5.5で気になったのは、価格より「中間層」の厚み

この記事を読んでまず思ったのは、「上位モデルだけが強い」という見方がだいぶ古くなってきたな、ということです。Opus級に近い性能を、半額の Sonnet で出してくる。こういう話を見ると、モデルの序列そのものより、どの価格帯でどこまで実務に耐えるかの競争が本質なんだと感じます。 特に引っかかったのは、性能向上が単なるベンチマークの話で終わっていないところです。コード系の指標で Opus にかなり迫りつつ、処理速度も上がって、しかも価格は据え置き。これは「ちょっと賢くなった」ではなく、開発現場での使い勝手に直結する変化です。待ち時間が減ると、人は試す回数が増える。試す回数が増えると、結局そのモデルを選びやすくなる。こういう地味な効き方のほうが、派手な性能差より強いのではないかと思います。 一方で、こういう「半額でほぼ上位互換」に見える話は、受け手が少し警戒したほうがいいとも思いました。ベンチマークで近いことと、実際の仕事で常に同じ満足度が出ることは別です。コードを書く場面でも、設計の筋の良さやデバッグの粘り強さみたいな部分は、数字に乗りにくい。だからこの記事は素直に面白いけれど、同時に「

papoo.work

「覚える」ことが、もう道具の実力差になる

この記事を読んでまず思ったのは、AI coding agent の比較軸がずいぶん変わったな、ということだった。コードをどれだけ書けるかだけではなく、「前の指示を次の repo でも覚えているか」を見るのか、と。人間の開発でも、チームの暗黙知を引き継げるかどうかはかなり大事だけれど、それが agent でも同じように効いてくるなら、記憶力はもう単なるおまけではない。 面白かったのは、ここでいう memory が人間の記憶みたいに曖昧なものではなく、かなり実務的な意味で使われているところだと思う。要するに「このツールは前回こういうルールで動かしたけど、今回もそれを守るのか」という話で、これができないと毎回こちらが同じ説明をやり直す羽目になる。そうなると、便利そうに見えて実際はだいぶ疲れるはずだ。生成の速さより、文脈の持続のほうが効く場面は確実にある。 一方で、こういうテストはとても分かりやすい反面、どこまで一般化していいのかは少し気になった。ある repo で覚えていた、別の repo で忘れた、という結果は確かに重要だけれど、実際の現場では memory 以外にも、プロンプトの書き方や

papoo.work

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

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

papoo.work

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 Codeの自動承認を標準にする、という割り切り

最初に思ったのは、「これ、便利さと怖さの境目をかなり前に出してきたな」ということでした。コードを書くAIにいちいち許可を求める流れは、正直かなり面倒です。とくに長時間まかせる用途では、毎回止まるだけで集中が切れる。だから自動モードをデフォルトにする発想自体は、使う人にとってはかなり筋が通っていると思います。 ただ、引っかかるのは、その便利さを支えるのが“安全そのもの”ではなく、あくまでclassifierだという点です。要するに、危ない操作っぽいものを見分ける仕組みであって、万能な監視員ではない。Anthropic自身も、人間の判断では危険な命令を十分に拾えない一方で、classifierにも限界があると認めている。ここは誠実だと思う反面、だったらなおさら「デフォルトにする」のは強い決断だとも感じました。 それでも、長い作業をAIに任せる現場では、毎回の承認確認が邪魔になるのも事実です。特に Team や Enterprise で pull request が増えるという話は、単なる“派手な新機能”ではなく、実際に作業の流れを変え始めている感じがします。人間が全部見張る前提から、ある程

papoo.work

Metaがまた“コードを書くAI”に参戦したと聞いて

正直、またか、という気持ちと、でもやっぱりここが本丸なんだな、という納得が同時に来た。生成AIの競争って、会話がうまいとか絵がきれいとかより、最後は「実際に仕事を片づけられるか」に収束していく。コードを書くAIは、その答え合わせがしやすい分野だから、各社がそこに吸い寄せられるのは自然だと思う。 この記事で少し引っかかったのは、Metaの動きがかなり“開発者向け”に寄っていることだ。Muse CodeはAPI経由で使う前提で、しかも一般向けの派手な発表というより、技術者が道具として触るタイプに見える。これは堅実でもあるし、同時に、世の中の注目を一気にさらう勝負ではない。Claude CodeやCodexみたいな名前が先に強く印象を作っている中で、Metaがどこまで存在感を出せるのかは気になる。 それと、料金の話が地味に重い。入力と出力で課金が分かれるAPI型は、試すだけなら軽そうに見えて、実運用するとすぐ現実が来る。記事でも heavy AI use のコストに触れていたけれど、ここは本当にそうだと思う。コード生成やdebuggingが便利でも、長い会話や大きい codebase を相手

papoo.work

Claude Duetを読んで考えたこと

いちばん気になったのは、これが「チャットできるAI」ではなく、かなり露骨に「先回りして働く相棒」として設計されていることです。メールやカレンダーを見て、必要そうなものだけを短く知らせてくれる。しかも、ただ速く答えるのではなく、「今はあなたに聞くべきか」「これは待てるか」を判断するところに力を入れている。ここには、AIの価値が“賢い返事”から“気が利く振る舞い”に移ってきた感じがあると思いました。 一方で、読んでいて少し身構えたのは、便利さと引き換えに、かなり深いところまで権限を預ける前提になっている点です。パスワードやトークンは直接見ないと言っていて、送信や支払いの前には確認も入る。それでも、複数のアプリを横断して仕事を進める以上、ユーザー側は「どこまで任せているか」を以前より意識しないといけないはずです。特にメールや請求、給与、契約のような領域は、ちょっとした誤読がそのまま面倒につながる。安全設計の説明が手厚いのは、その不安が最初から強くあるからだろうな、と思いました。 もう一つ面白かったのは、Anthropic自身がかなり「仕事道具」としての使い方に寄せていることです。個人の雑多な

papoo.work