#ベンチマーク

古いPCを正確に再現することに、Macがかなり向いているかもしれない――そんな少し意外な話だ。今回取り上げるのは、Mac mini M6でレトロPCエミュレータ「86Box」を動かし、Pentium II相当の環境をどこまで安定して回せるかを試したレビューである。単に「動いた」という話ではなく、音が途切れないこと、100%のエミュレーション速度を保てることまで含めて詰めているのが面白い。しかも結果は、かなり印象的だった。 元記事は、86Boxが古いPCをハードウェアレベルで再現する仕組みを前提に、Mac mini M6がどこまで重い負荷を耐えられるかを測っている。86BoxではCPUだけでなく、チップセット、ISA/PCIバス、グラフィックス、サウンド、ディスクコントローラまで再現対象になる。そのぶん精度は高いが、負荷の大半はホスト側のひとつのスレッドに集中する。つまり、コア数よりも単一コアの速さと持続力が効く。 テスト対象は、12コアCPUと24GBメモリを載せたMac mini M6のレビュー機と、ベース構成のMac mini M4だった。使ったのは、2026年5月31日に公開され

AnthropicのClaude Opus 5.5を、Artificial Analysisがベンチマークと価格の両面から分析した記事だ。単に「賢い」と言うだけではなく、どれくらいの料金で、どれくらいのトークンを使って、どの程度の速度で動くのかまで見ているのがポイントになる。大規模モデルは性能だけでは選べないので、この手の比較は実運用を考える人ほど気になる。今回の結果は、最上位級のモデルらしく能力は高い一方で、使いどころを選ぶタイプだと示している。 Artificial Analysisによると、Claude Opus 5.5は「Adaptive Reasoning, Max Effort, Default Fallback」という理由づけのある推論版のモデルで、表示上はAnthropicのProprietary modelとして、Released September 2026とされている。入力はtextとimageに対応し、出力はtextのみ。文脈長は1M tokensで、およそ1500ページ分のA4・12ptに相当すると説明されている。 性能面では、Artificial Analy

生成AIの話題は、文章作成やコード補助を離れて、ついに「車を動かす」段階にまで広がっている。DrivingBenchは、その期待をかなり露骨な形で試したベンチマークだ。舞台は仮想空間ではなく、実車のToyota Corolla。しかも操作は、会話のたびに少しずつ指示を出すのではなく、コーンで組んだコースを走らせながら、前に進むたびに判断を重ねていく。安全のため人間の監督者がブレーキを踏める状態にはしてあるが、それでも「前線級の言語モデルは車をどこまで動かせるのか」をかなり直球で測ろうとしている。 DrivingBenchは、frontier language models、つまり最先端クラスの言語モデルに実車の運転をさせ、その成績を競わせる研究用ベンチマークだ。対象はcomma装備のToyota Corollaで、評価は固定されたcone course、コーンで区切られたコース上で行う。モデルにはsteering、accelerator、brakesの制御権が与えられるが、もちろん放任ではない。人間のsupervisorがいて、必要なら止められる。 このベンチマークの面白いところは、単

この記事を読んでまず思ったのは、「速くする」って、結局はかなり地味な反復作業なんだな、ということだった。魔法みたいな最適化が一発で決まった話ではなくて、Slack のスレッドを増やし、計測を増やし、怪しいベンチマークは捨て、効くものだけを残していく。しかもそれを Claude 自身にやらせている。ここが面白い。 特に引っかかったのは、「測れるようになったら速くできる」という発想の強さだ。普通は、まず遅いところを人間が勘で当てて、あとから測定することが多い。でもこの記事では逆で、測定そのものを増やすことが仕事になっている。instruction count とか React commits とか、ユーザーからは見えない数字を先に置いて、そこを Claude が削っていく。しかもその数字が本当に体感速度につながるかを、壁時計時間で確かめる。かなり堅い。 一方で、少し怖さもある。こういう進め方はうまく回れば強いけれど、ベンチマークの置き方を間違えると、見かけだけ速くて実際は違う方向に進む危険がある。記事でもそこはかなり警戒していて、フレークするものやユーザー遅延と相関しないものは捨てたと書い

まず思ったのは、「強いモデルです」と言うだけでは終わらせず、かなり細かく“使うといくらかかるか”まで前面に出しているのが、むしろ誠実だなということでした。AI の話は性能だけが独り歩きしがちですが、実際にはコストと出力量で印象がかなり変わる。そこを隠さずに並べているのは好感が持てます。 ただ、読んでいて少し引っかかったのは、賢さの指標が高いことと、実運用で気持ちよく使えることは別だ、という点がかなりはっきり見えてしまうところです。Intelligence Index が高くても、出力 tokens が多くて verbose だと、ユーザー体験としては「よく考えるけど長い」モデルになりやすい。たぶんこれは、ベンチマークで高得点を取るモデルほど起きやすい不自然さだと思います。点数は分かりやすいけれど、現場では「要点だけ返してほしい」のほうが価値が高い場面も多いはずです。 それと、1M tokens の context window はかなり目を引きました。ざっくり言えば、長い文書や大量の会話履歴を一度に抱えられるということですが、こうなると「何を覚えられるか」より「何を読ま

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

AIモデルを使っていて、ある日だけ急に賢く見えたり、翌日には妙に鈍く感じたりすることがある。Xで話題になっているのは、その違和感を「モデルが劣化した」と片づけず、実際にどこで差が生まれているのかを追った観察だ。投稿したのは Lon Lundgren さんで、Anthropic の Fable 5 をめぐる挙動を6週間かけて追跡した結果を共有している。読んでいて面白いのは、問題がモデルの中身というより「どういう推論設定で返されているか」にあるかもしれない、と切り込んでいる点だと思う。 Lon Lundgren さんの主張は、Anthropic が Fable 5 をサブスクリプションプランで恒久的に使えるようにしたあと、体感性能が大きく落ちたように見えた、というものだ。本人は当初、モデルが「dumber」になったと感じたが、その理由はすぐには説明できなかったという。 そこで後から測定を重ねたところ、8月は7月に比べて「thinking tokens」が大幅に少なかった。thinking tokens は、モデルが内部で推論に使う計算の痕跡のようなもので、これが少ないと一見すると同じモデル

生成AIの主役は、まだ文章を長く出すモデルです。ただ、実運用では「文章を作る」より先に「振り分ける」「危険か判定する」「点数を付ける」といった、もっと単純で速い判断が必要になる場面が多い。今回のLayaは、その部分だけを切り出して、しかも100以上の言語に対応させようという試みだ。記事の主張はかなり強いが、単なる速度自慢ではなく、なぜそういう設計が要るのかまで含めて読むと面白い。 元記事が紹介しているLayaは、「33ms Multilingual System 1 Decision Engine」と名付けられた判定モデル群だ。作ったのはConvAI Innovationsの創業者兼CEO、Nandakishor Mukkunnothで、2026年9月更新の記事として公開されている。中心にある考え方は、LLMに自由文を生成させるのではなく、構造化された問いに対して即座に確率つきの判断を返すことにある。 記事では、これを人間の脳でいうSystem 1、つまり瞬間的な反射にたとえている。たとえば、問い合わせメールをどの部署に回すか、受信メールがフィッシングかスパムか、入力文がjailbre

最初に思ったのは、これは単なる desktop automation の道具箱ではなく、computer-use を「作る側」のための基盤を取りにきているんだな、ということでした。普通こういうプロジェクトは、ブラウザを触れて、OSを触れて、モデルもある、で終わりがちです。でも Cua はそこからもう一歩進んでいて、実行環境、評価、データ生成までまとめて面倒を見るつもりに見える。ここがかなり野心的です。 特に面白かったのは、Cua Driver と Cua Bench が並んで置かれているところです。前者は「アプリを動かす手段」、後者は「その動かし方が良かったかを測る手段」ですよね。AI エージェントの世界って、デモは派手でも、何がどれだけできたのかをちゃんと測るところが弱いことが多いので、この2つを最初からセットで出しているのは筋がいいと思いました。単に操作できるだけではなく、操作の成否を再現可能にする。そこまでやらないと、computer-use は研究にもプロダクトにもなりにくいので。 もうひとつ引っかかったのは、「System 1」という言い方です。人間の直感的な判断になぞらえて

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

AI が自律的に会社を運営する、そんな話はまだ実験室の比喩に聞こえるかもしれない。だが Andon Labs は、仮想環境のベンチマークだけでなく、実在する自販機や店舗、カフェまで AI に任せる実験を続けてきた。そのための基盤をまとめたのが Pion だ。今回は、その Pion を研究プレビューとして外部にも開くと同時に、なぜそこまで踏み込むのかを説明している。単なる新製品紹介ではなく、「AI が現実世界で資源を獲得できるのか」という、かなり重い問いへの答え方そのものが記事になっている。 Andon Labs は約2年にわたって、「AI システムは、いつ現実世界で自律的に資源を獲得できるようになるのか」を追ってきたという。最初は Vending-Bench というシミュレーションから始めた。これは LLM が自販機ビジネスを1年分、数万ステップにわたって運営する力を測るベンチマークだ。作り始めた2024年後半の時点では、どのモデルも複数の行動をつなげて実行するのが苦手で、長期計画の気配もなかった。たとえば Claude Sonnet 3.5 は、自分の銀行口座がハッキングされたと思い

Cognitionが、新しいコーディングモデル「SWE-2」を公開した。単に精度を上げたという話ではなく、推論にどれだけ時間やコストをかけるかという“使い勝手”まで含めて改善した、というのがこの記事の肝だ。人がコードを書くときと同じで、何でもかんでも深掘りすればよいわけではない。SWE-2は、その線引きをモデル側でうまくやれるようにした、とCognitionは主張している。今回はその中身と、そこにどこまで意味があるのかを見ていく。 CognitionはSWE-2を「これまでで最も高度なcoding model」と位置づけている。狙いは、能力とコストの両方を見たときの“Pareto frontier”を押し広げることだ。Pareto frontierとは、性能を上げようとするとコストが上がり、コストを下げようとすると性能が落ちる、というトレードオフの境界を指す。SWE-2はその境界上で、より安く、あるいはより高性能に動ける点を増やしたという説明になっている。 同社によれば、SWE-2はFrontierCode 1.1 Mainで50.0%を記録した。これはFable 5.1に1ポイント以

オープンモデルの出力が、別のモデルの「考え方」にどれだけ引っ張られるのかを確かめた短い実験が出てきた。題材は一見地味だが、モデル同士の学習のつながりを探るうえではかなり示唆がある。しかも今回は、教師役に GPT-5.5 Pro を使い、以前の実験と比べてどのモデルがどちら方向に寄るのかを見直している。単なるベンチマークではなく、「どのモデルが誰の影響を受けたのか」を探る話として読むと面白い。 元記事は、`reasoning-prefill-1-1.md` という Gist に置かれた実験メモだ。タイトルにある “Reasoning prefills on a few open models, v1.1” の通り、いくつかのオープンモデルに対して「推論の書き出し部分を先に与える」と、回答の見え方がどう変わるかを調べている。ここでいう reasoning prefill は、モデルが答えを出す前の“考える途中”の文面を、別のモデルから少しだけ差し込むやり方だ。今回はその教師を GPT-5.5 Pro に変えて、前回の実験をもう一度回した。 実験の手順はこうだ。各問題について、対象モデルには

OpenAIのGPT-6 Astraをめぐって、モデル性能そのものだけでなく、その内部で何をしているのかにも注目が集まっている。Sebastian Raschka氏は、Astraの初期印象、looped transformersと呼ばれる構造、そして「推論の途中経過を隠しているのではないか」という噂を同じ記事の中で追っている。新モデルの実力を眺めるだけでなく、近ごろのLLMがどこへ向かっているのかを読む材料として面白い内容だ。とくに、computer use と reasoning の関係をどう見るかは、今後のモデル設計を考えるうえでかなり示唆的だと思う。 Raschka氏はまず、OpenAIが公開したGPT-6 Astraをここ数日使ってみて、これまで触った中で最良クラスのモデルだと書いている。ただし、単に「賢い」と言って終わらせず、どの領域で伸びたのかを細かく見ているのがこの文章の中心だ。Astraは、文章生成、数学、coding などほぼ全カテゴリで前モデルのGPT-5.6を上回り、とくに3D rendering と animation のようなグラフィカルな作業で目立って強いと

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

ローカルLLMを動かすとき、どこまで圧縮しても実用に耐えるのかは切実な問題です。GPUメモリは限られていますし、モデルを小さくしたい気持ちは強い一方で、精度が落ちすぎれば意味がありません。QuesmaのPiotr Migdał氏は、Qwen3.8 27Bの複数のquantizationを実測し、その境界線をベンチマークで確かめました。結果はかなりはっきりしていて、4bitは驚くほど健闘し、1bitは一気に崩れます。 元記事で扱っているのは、Qwen3.8 27BのGGUF量子化版です。著者はUnslothがHugging Faceで配布しているものを使い、8bitのQ8_0、4bitのQ4_K_M、2bitのUD-Q2_K_XL、そして最小の1bitであるUD-IQ1_Sを比較しました。フルのBF16モデルは55GBあり、一般的なコンシューマーGPUには重すぎますが、Q4_K_Mは17GBに収まり、RTX 4090の24GB級カードでも動かせるとしています。 検証にはllama.cppを使い、GPQA Diamond、IFBench、Terminal-Bench 2.1の3つを回しまし

Claude Fable 5.1 と Claude Mythos 5.1 のベンチマークが話題になっている、という空気だけは伝わってきたのに、肝心の本文がほぼ見えないのが逆に引っかかった。Reddit ってこういうことがある。タイトルだけが先に独り歩きして、「どっちが勝った」「どれだけ伸びた」といった断片だけで盛り上がる。でも、ベンチマークは数字の見せ方次第で印象がかなり変わるので、私はそこにあまり飛びつけない。 特に気になるのは、こういう話題だと「性能が上がった」という一点だけで雑に語られがちなことだと思う。ベンチマークは便利だけれど、実際の使い勝手とはズレることがある。速いのか、賢いのか、長文に強いのか、安定しているのか。ひとまとめにしないで見ないと、数字だけ良く見えるモデルをありがたがることになる。記事自体の中身が読めないぶん断定はできないが、少なくともこの手の投稿を見るたびに、「そのベンチマークで何を測っているのか」を先に疑う癖は必要だなと思う。 --- > 参考: [Reddit](https://www.reddit.com/r/artificial/comments/1w

OpenAIがGPT-6 AstraでKiCad上の回路設計デモを見せたことで、AIに電子回路を任せる話が一段現実味を帯びてきた。EEBenchは、その「それっぽく見える」デモが本当に使える設計なのかを測るための仕組みを公開している。単に回路図を描けるかではなく、制約を満たし、シミュレーションに通り、しかも現実の部品条件でも破綻しないかまで見るのが肝だ。この記事は、そのベンチマークの狙いと、今のモデルがどこまで来ているかをまとめたものだ。 元記事の中心にあるのは、AIが回路基板を作れるかどうかを、見た目ではなく結果で判定しようという話だ。EEBenchのチームは、OpenAIの発表でGPT-6 AstraがKiCad上で回路ボードを扱うデモを見て、電子工作が大きなモデル発表に入ってきたことを面白い変化だと受け止めている。ただし、そこからすぐに「AIにスマホ一式を一発で作らせられる」段階ではないとも言う。だからこそ、生成された電子回路が本当に良いものかを測る方法が必要になる。 その答えとしてEEBenchは、GUIをマウスで操作させるよりも、宣言的コードで回路を表す atopile を使

OpenRouterに、OpenAIの新しいフラッグシップモデル「GPT-6 Astra」の案内ページが載った。単に新モデルが追加されたという話ではなく、価格、コンテキスト長、出力上限、提供プロバイダー数、そして第三者ベンチマークまで一緒に並んでいるのが目を引く。大規模モデルの競争が、単純な性能比べから「実運用でどれだけ安定して使えるか」に移っていることがよく見える。とくに今回は、OpenRouterが得意とするマルチプロバイダー配信の文脈と強く結びついているのが面白い。 OpenRouterのページでは、GPT-6 Astraを「OpenAIのフラッグシップモデル」と位置づけている。用途として挙げられているのは、advanced analysis、software engineering、deep research、scientific work、document creation で、とくに computer や browser を使う long-horizon agentic tasks に強いとしている。要するに、短い応答を返すだけのモデルではなく、ツールを使いながら長い手順を

AIの能力が伸びたとき、その裏で何が効いたのかを追うのは面白い。Mithil Vakdeの新しい投稿は、ARC-AGI-1という難問ベンチマークで、小さなTransformerをゼロから学習させて44%を出した話だ。しかも計算コストは67セントだという。数字だけ見ると派手だが、中身はかなり実験臭い。だからこそ、単なる「高得点報告」ではなく、どこをいじると効くのか、何を削ると落ちるのかまで見ておく価値がある。 本人の説明では、これはARC-AGIに関する3本目のブログで、前回より速く、安く、それでいてオープンソースのまま性能を上げたアップデート版だという。使ったのは小さなTransformerで、5090上で1.5時間学習させた。ARC-AGI-1のpublic evalで44%、ARC-2では7%を出したと書いている。比較対象は、test time trainingを行う系統のモデルに絞っている。 手法の骨格はシンプルだ。各input-output pairをトークン列に変換し、その列をTransformerで自己回帰的に学習する。学習はtest timeに行い、train setだけ

100%という数字は、正直かなり気持ちがいい。でもこの記事を読んで最初に思ったのは、そこに素直に拍手していいのか、という引っかかりだった。ARC-AGI-3みたいな推論ベンチマークで、あるモデル単体では30%だったものが、NvidiaのAVOというagent systemに包むと100%まで跳ねる。たしかに派手だし、デモとしては強い。でも同時に、「それはモデルが賢いのか、それとも外側の仕組みがうまく問題を解いたのか」は切り分けて見ないといけないと思う。 この手の話でいつも面白いのは、モデルの性能そのものよりも、周辺の設計がどれだけ結果を変えるかが露骨に見えるところだ。Claude Opus 5が30%しか取れないのに、agent systemをかませただけで全183レベルで100%というのは、AIの能力が一枚岩ではないことをはっきり示している。人間の感覚に近いのはむしろこっちで、実際の仕事でも「頭脳」だけでなく、確認の仕方、道具の使い方、試行錯誤の流れで結果が大きく変わる。だからこの結果自体は、単なる誇張として片づけるより、「推論はモデル単体ではなく実行系込みで測るべきだ」という方向に

読んでまず思ったのは、いちばん怖いのはモデルの失敗じゃなくて、失敗を数えている側の思い込みだな、ということだった。しかもこの話はかなり実務っぽい。LLM の eval って、つい「点が出た」「下がった」で安心してしまうけれど、実際には“どの失敗を失敗と呼んでいるのか”が曖昧だと、数字がきれいなほど危ない。 特に引っかかったのは、multi-step な作業を single-step の問題として採点してしまう部分だった。たとえば thread_ts のように、最初の操作をしないと次の引数が取れないものを、最初から完成形の入力がある前提で評価してしまう。これ、言われてみれば当たり前なのに、ベンチマークを作る側はけっこうやりがちだと思う。モデルが「まだ足りない」と判断して保留したのに、採点側はそれを不正解にしてしまう。つまり、慎重さが減点される。 もうひとつ面白かったのは、静的なチェックと LLM の eval が、別々の方法なのに同じところでつまずく、というくだりだ。名前の紛らわしい tool 同士があると、モデルも迷うし、静的ルールでも危ないと出る。ここはかなり気持ちいい発見で、安い静

この記事を読んで最初に思ったのは、これはベンチマーク記事というより「ベンチマークを雑にやると、たぶん簡単に自分たちをだませる」という警戒心の表明だな、ということだった。SREの調査支援ツールは、見た目が賢そうでも、実際に事故対応で役に立つかはかなり怪しい。しかも同じ質問でも答えがぶれる。だから、ただデモで気持ちよくなるのではなく、同じ条件を固定して、しかも答えを盲検で採点する、という発想はかなり筋がいいと思う。 特に引っかかったのは、合成データの作り方にかなり神経を使っている点だ。現実の障害っぽいノイズを入れつつ、わざと似たような別の異常も混ぜる。さらに、公開データセットをそのまま使うと学習済みの知識で当ててしまうかもしれないから、オリジナルのシナリオを作る。ここまでやると、ようやく「LLMが過去に見たパターンを思い出しているだけではない」と言えそうだし、逆に言うと、ここまでしないと評価がかなり怪しくなるのだろうと思った。 もう一つ面白かったのは、ClickHouseを直接SQLで触らせる方法より、ClickStack MCPのように「高レベルの観測用プリミティブ」を渡したほうが、単に

Bruce Schneierが紹介しているのは、AnthropicのOpus 5が「prompt injection」に対してかなり粘るようになった、というベンチマーク結果です。 IPI benchmarkでは、15回試したときの攻撃成功率が Opus 4.8 の 5.5% から 2.0% に低下しました。1回だけの試行でも 0.5% から 0.2% に下がっています。 同じ基準では、Opus 5は Sonnet 5 や Mythos 5 よりも頑丈で、評価されたモデルの中で最も防御性能が高かったとされています。 Claude系以外のモデルでは、最も頑丈だった Muse Spark でも15回以内の成功率は 16.5%。Opus 5の 2.0% と比べると、差はかなり大きいです。 ただし、Schneierは最後に「一般論としてはprompt injectionを完全に防ぐのは不可能だが、個別のケースではかなり改善している」と締めています。 Bruce Schneierの短い記事は、ほとんどベンチマークの数字だけで勝

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

Semgrepは、IDOR（本来見えるべきでない他人のデータに触れてしまう脆弱性）を見つけるベンチマークで、いくつかのモデルを同じ条件で比較した その結果、open-weightモデルのGLM 5.2が、素のプロンプトだけでClaude Codeを上回った ただし、Semgrepの自社パイプラインは依然として強く、モデル単体の勝負とは別のレイヤーで性能を引き出している この記事の本質は「どのモデルが一番強いか」より、「ハーネス（周辺の仕組み）がどれだけ効くか」を切り分けた点にある open-weightは、社内環境で動かしやすいので、セキュリティ用途ではかなり魅力があると思う Semgrepのこの記事、AIモデルのランキング発表に見えて、実はかなり地味で重要な問いを突いています。 「脆弱性検出の性能って、モデルそのものの力なのか、それとも周辺の仕組みの力なのか？」という話です。 これ、地味ですがめちゃくちゃ大事です。 生成AIの世界では、つい「どのモデルが最強か」に目が行きがちです。でも実務では、モデル単体よりも、どうやってコードを読ませ、どこを見せ、どう検索させ、どう結果を整えるかの