#コード生成

読んでまず思ったのは、「そりゃそうなるよな」という納得と、「でも、そこまで戻すのか」という少しの驚きが同時に来る記事だった。Claude Codeみたいなagenticな coding tool は便利だけれど、便利さの裏で、誰が書いたか曖昧なコードがそのまま業務に入り込む怖さがある。特に銀行の trading desk だと、ただの効率化では済まない。 この記事で引っかかったのは、Goldman Sachs が以前は trader や banker の現場発の“vibe coding”をかなり歓迎していたように見えるのに、今は engineer 以外のアクセスを絞ったことだ。現場に近い人が自分の手で試作して、あとで engineering team が磨く、という流れはすごく現代的だし、うまく回れば強い。でも、そこに「その人が書いたコードを誰がレビューするのか」「情報の壁をどう守るのか」という金融業特有の問題が乗ると、一気に話が重くなる。 個人的には、ここで面白いのは「AI が危ない」というより、「AI を誰が使ってよいか」ではなく「AI が書いたものに誰が責任を持つか」がまだ整理し

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

Mistralが、フラッグシップモデル「Mistral Large 4（Le Chonk）」のweightsをopen weightとして公開した。単なる“モデルの発表”ではなく、開発者や企業が自前で扱える形に踏み込んだ点が大きい。しかもこのモデルは、コード生成やcybersecurity、reasoningの効率まで押し上げたとされる。Mistralが「sovereign AI」を掲げる会社だということを考えると、今回の発表は技術面だけでなく、AIの持ち方そのものをどうするかという話にもつながっている。 Mistralは、Mistral Large 4（Le Chonk）のweightsを公開したと発表した。このモデルは1 trillion parametersのnatively multimodal modelで、もともと今月初めにpublic previewとして出されていたものだ。今回の公開は、その後にreinforcement learningをさらに回したうえでのアップデート版にあたる。Mistralによれば、コード、defensive cybersecurity、reas

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

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

AIでソフトウェアを書くとき、まず計画を立てるべきか、それともとにかく作り始めるべきか。Ayman Nadeem のこの文章は、その問いに対して自分の考えがどう変わったかをかなり率直に書いている。彼は今年前半、計画こそがAI時代の開発で最重要になると信じ、その思想を前提にしたデスクトップ向けのコーディングアプリ「Nuanced」まで作った。ところが実際に使われてみると、Plan mode は期待した役割を果たさなかったという。この記事は、単なる製品の反省文ではなく、AIコーディングツールが「計画」をどう扱うべきかという設計論にも踏み込んでいるので、今読んでおく価値がある。 Ayman Nadeem は、AIによってコード生成の速度と量が一気に増えた一方で、それを支えるインターフェースが追いついていないと見ていた。そこで作ったのがデスクトップのコーディングアプリ Nuanced だった。彼の問題意識は、機械が人間よりずっと速くコードを増やしていく状況で、人間がソフトウェア全体の理解を失わずにいられるのか、という点にある。数千行のコードが数分で生成されれば、作る前に「何を作るのか」「なぜ作

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

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

この記事を読んでまず思ったのは、「やっぱり、実戦のコードベースはそんなに甘くないよな」ということだった。ベンチマークで点が取れることと、他人の手で育った private codebase に入ってちゃんと働けることは、かなり別物だ。そこを分けて測ろうとしている Real-SWE の発想自体は、かなり筋がいいと思う。 特に引っかかったのは、トップスコアの agent でも失敗率が 60% を超える、という数字の重さだ。これは「AI がまだ未熟」という話で終わらせるには大きすぎる。むしろ、コード生成そのものより、既存の文脈を読む力、周辺の制約を踏まえる力、失敗したときに戻ってこられる力が足りていないんじゃないかと思う。人間でも苦手な部分ではあるけれど、そこで雑に自信満々に振る舞うのが AI の怖さでもある。 もう一つ面白かったのは、この種の benchmark が「どれだけ賢いか」より「どこで壊れるか」を見にいっている点だ。私はこういう測り方のほうが好きだ。派手なデモより、実際に壊れる条件を積み上げたほうが、現場ではずっと役に立つ。AI coding agent は便利だし、使える場面も増

コードを書くAIに相談すると、こちらが知りたい結論より先に、前置きや気遣いが長く続いてしまうことがあります。GitHubに公開された `i-have-adhd` は、その“回りくどさ”を抑えて、答えを先に出すためのskill/pluginです。名前はかなり挑発的ですが、狙いはふざけたものではありません。読む人の集中を削らない出力に寄せよう、という提案です。AIコーディング支援が当たり前になった今だからこそ、こういう「出し方」の工夫が意外と効いてきます。 このリポジトリは、GitHub CopilotやClaude Codeのようなコーディング用エージェントに「答えを埋め込まず、先に出せ」と教えるためのskill/pluginとして公開されています。トップには「ADHD-friendly outputs. No ADHD diagnosis needed!」とあり、読む側が集中を切らさずに済む出力を目指す、という立て付けです。インストール方法も載っていて、CLIのプロンプトに `Install the i-have-adhd skill/plugin from https://githu

最初に思ったのは、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 がまた剥がす、みたいな無駄が積み上がるのは、現場では本当にある話だろうなと思います。 一方で、ここはうまく切り分けているな、と

Meta が開発者向けに Muse Spark 1.3 を公開した。単なる新モデルのお知らせではなく、AI を“会話がうまい道具”から“作業を前に進める実務者”へ寄せようとしている点が目を引く。記事を見る限り、Meta はこのモデルをエージェント型の作業、特にコーディングでの使い勝手に強く振っている。しかも、画像や動画も扱えるという話まで入っているので、コード補助にとどまらない広がりも見せている。 Meta の説明によると、Muse Spark 1.3 は「agentic workflows」、つまり AI が途中で止まらず、道具を呼び出しながら作業を進めるようなワークフロー向けに学習されている。競争の激しい coding performance にも最適化されていて、開発者は初回の試行でより高い正答率と、信頼できる tool calling を期待できるという。 記事の中心にあるのは、長い流れの作業をこなす能力だ。Muse Spark 1.3 は、文脈と前の結果を追いかけながら動き、入力が雑だったり矛盾していたりしてもそこを飲み込んで進める。必要ならユーザーに確認を返す、と Meta

最初に思ったのは、「もうここまで来たか」という驚きと、同時に「そりゃそうだよな」という妙な納得感だった。 Claude Code の auto mode は、要するに毎回の確認ダイアログを減らして、ある程度はエージェントに任せるモードだ。コード生成ツールとしては便利でも、勝手にファイルを書き換えたり削除したりする可能性がある以上、普通は慎重になる。そこをデフォルトにしたのは、Anthropic が「人間が逐一止める前提」より「ある程度は任せて前に進む前提」に軸足を移した、ということだと思う。 一方で、数字の出し方はかなり強気に見えた。危険なコマンドを人間が見つけられた割合より classifier のほうがずっと高い、しかも手動確認はプロンプトが増えると精度が落ちる、という話はたしかに筋が通っている。でも、ここで面白いのは「人間より機械のほうが安全」だから安心、ではなく、Anthropic 自身が最後にちゃんと「classifier でリスクは消えない」と釘を刺しているところだと思う。便利にするほど、責任の置き場所はむしろ曖昧になる。そこを完全には隠していないのは好感が持てた。 あと、

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

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

DeepReinforceが公開した Ornith-1.0 は、ひとことで言うと「agentic coding」に特化したオープンソースのLLMファミリーです。 ここでいう *agentic coding* は、ただコードを1発で出すだけではなく、ターミナルを触ったり、テストを回したり、途中で試行錯誤しながら仕事を進めるタイプのコード生成を指します。実務の開発にかなり近い世界です。 面白いのは、このモデルが単に「賢いコード生成器」という話ではないところです。Ornith-1.0は、解法そのものだけでなく、解法を引き出すための“足場”まで自分で作るという発想を取っています。これはかなり野心的ですし、個人的にはかなり好きな方向性です。モデルに「どう考えるか」まで学ばせるわけで、いかにも次の世代っぽい。 Ornith-1.0は、agentic coding向けのオープンソースモデル群 サイズは 9B Dense から 397B MoE まで幅広い 中核アイデアは、人間が固定の実行枠組みを作るのではなく、モデル自身が枠組みを改善していくこと **

GLM-5.2は、中国のZ.aiが出したopen-weightモデルで、AI研究者や開発者の間でかなり強い反応を呼んだ。 特にcoding harness（AIにコードを書かせる実運用の枠組み）に入れたときの「使える感じ」が大きく、単なるベンチマーク上の数字以上のインパクトがあった。 著者Nathan Lambertは、これは「オープンモデルでも本当に最前線級のagent体験を出せる」と示した転換点だと見ている。 価格競争、open model経済圏の拡大、そして規制や安全保障の議論にも波及しそうだと指摘している。 個人的には、性能そのもの以上に「これで十分仕事になる」と感じる人が増える瞬間が本当に怖くて、同時に面白いところだと思う。 この記事でNathan Lambertが言っているのは、GLM-5.2は「ちょっと良くなった新モデル」ではなく、オープンモデルの見方そのものを変える出来事だ、という話です。 最初はいつもの版番号アップに見えます。GLM-5.1の次なら、せいぜい順当な改善だろう、と。ところが実際には、かなり多くの人が使ってみて「これ、もう普通に強いじゃん」となった。ここが