同じ日に出た二つの記事 — パレートフロンティアと、読めないコード
同じ日に出た二つの記事 — パレートフロンティアと、読めないコード
コーディングモデルの競争がコスト対スコアへ収束するとき、スコアが数えないコストは誰が払うのか?
導入
2026年9月11日、Hacker Newsのトップページにコーディングエージェントを扱う記事が二つ並んだ。一つはCognitionの「SWE-2を紹介する: パレートフロンティアを押し広げる」で427ポイントを集めた。もう一つはArmin Ronacherの「Astra for Coding: 我々はなぜまたこれをやっているのか」で388ポイントを集めた。
前者は数字の記事だ。SWE-2はFrontierCode 1.1 Mainで50.0%を記録し、Fable 5.1と1ポイント以内でありながら64%安いと述べる。発表文は、RLを初めて数兆パラメータ規模まで拡張し、中核となる追加点はすべての推論努力レベルを一度の実行で学習させるRLアルゴリズムだと説明する。コスト・性能のフロンティア全体をまとめて押し上げたという主張である。基盤モデルはKimi K3で、既にエージェンティックコーディングのための広範なRLを経た2.8兆パラメータのモデルだ。
後者は数字のない記事である。Ronacherは週末のあいだ「ソフトウェア工場」を動かした。モデルにワークフローのやり方を全面的に決めさせ、自分のコンテキストを管理して agent-notes フォルダに記録を残し、サブエージェントを起こさせた。目標は仮想スレッドとレキシカルスコープを備えたPythonを作ることだった。彼はChatGPTのトークンを一サイクル分まるごと燃やし、それはおよそ40億トークンだったと記す。そして35時間後、この工場は価値あるものを何一つ生み出さず、より良い工場の運営法も教えてくれなかった。
二つの記事を並べて読むと問いが生まれる。ベンチマークは上がっているのに、なぜこうした報告が同じ日の同じ場所に並ぶのか。
発表された数字と、その数字の出所
まずCognitionが示した表をそのまま写しておこう。SWE-2はFrontierCode 1.1 Main 50.0%、DeepSWE 1.1 73.0%、Terminal-Bench 2.1 92.8%、Terminal-Bench 4 27.3%である。比較対象はKimi K3(44.2 / 68.5 / 88.3 / 21.5)、Grok 4.6(48.0 / 67.5 / 88.4 / 20.3)、Fable 5.1(50.9 / 67.4 / 91.4 / 55.8)、GPT-5.6 Sol(47.5 / 72.7 / 88.8 / 37.3)、GPT-6 Astra(53.3 / 74.1 / 89.9 / 57.9)、そして直前世代のSWE-1.7(42.0 / 37.7 / 81.5 / 7.6)だ。
表を横に読めば発表文の主張が見える。SWE-2は二つのベンチマークでスコアとコストの両方においてSWE-1.7とGrok 4.6を上回り、GPT-5.6 SolおよびFable 5/5.1と同等のスコアをはるかに低い価格で出す。しかし表を縦に読むと別のものが見える。Terminal-Bench 4でSWE-2は27.3%だが、Fable 5.1は55.8%、GPT-6 Astraは57.9%だ。二倍の差である。発表文が自ら示した表の中に「一部の課題ではフロンティアと依然として遠い」という事実が含まれている。
Hacker Newsの最初の反応もこの地点を突いた。ある利用者は、FrontierCodeがCognition自身の作ったベンチマークである点を指摘し、このモデルが同じ日にリリースされたDeepSeek v4.1 Flashよりあらゆる面で劣って見えると付け加えた。投稿者のアカウントが非常に新しく自己宣伝が疑わしいという言葉も添えていた(@harmonic18374)。自社ベンチマークで自社モデルがフロンティアに近いという主張は、構造的に検証力が弱い。表の一番左の列名が会社名と同じであるとき、その列は測定ではなく定義に近づく。
別の利用者は期待値を調整する側だった。SWE作業においてモデル性能はムラがあると予想され、少なくともモデルの名前でそれを認めているという。既に蒸留されたモデルからさらに蒸留したものだが、64%安いという数字が保たれるなら、それでも価値はあるかもしれないと見た(@airstrafer)。この表現をめぐって用語の議論が続いたが、それ自体が有益だ。ある利用者は、蒸留とは教師モデルの重みを持たずに教師の回答だけで小さいモデルを教えることであり、ファインチューニングは元のモデルの重みを実際に持った状態で違う答え方を訓練することだと整理した(@FergusArgyll)。別の利用者はより厳密に、蒸留は教師モデルのトークンごとのロジットを要求し実務的にはモデル自体を保有することを意味する、先の説明は単なる合成データだ、と正した(@Bolwin)。
用語が重要なのは、これがSWE-2の素性を決めるからである。発表文によればSWE-2はKimi K3から事後学習されており、RLが多くのベンチマークで5〜6ポイントを加え、K3のコスト・性能フロンティア全体を移動させた。つまりこれは基盤モデルを作った仕事ではなく、他者が作った基盤モデルの上にRLの層を載せた仕事だ。それ自体は正当な工学だが、「フロンティアを押し広げた」という表現が指す範囲はその分だけ狭くなる。
ベンチマークが数えないコスト
ここでRonacherの記事へ移ろう。彼の診断はスコアではなく学習目標を狙う。
彼は、訓練の過程で何かが「うまくいっていない」のではないかと疑っていると書いた。モデルは長期的な課題を成功させることに対して大きく報われるが、「ひどいコード」に対して罰を与える仕組みはほとんどないように見えるというのだ。その結果として現れるのが、彼が収集しておいた出力である。最も印象的な例は、サブエージェントがパッチツールを使う代わりにPythonの手動文字列操作でCコードを編集した場合だ。Path(...).read_text().replace(...) でヘッダファイルの定数定義を変え、s.index(...) で見つけた位置に文字列を継ぎ足してC関数を挿入する、といった具合である。
この観察は彼だけのものではなかった。Hacker Newsで複数の利用者が同じ症状を報告した。ある利用者は、新しいモデルたちが読めない、存在するあらゆるオプションフラグを動員したbashコマンドやPythonスクリプトを走らせようとすると述べ、レビューが不可能で正規表現より読みにくいと書いた(@Gigachad)。別の利用者はツール選択がハーネスの設定と絡んでいる点を指摘した。標準の読み書きツールを使えとシステムプロンプトに追記しておいたが、特定のモードではツール構成がbash中心のコマンドを助長する方へ傾いたという(@chambored、@IceDane)。三人目の利用者は成果物の質についてこう整理した。あるモデルは自分が行う多くの作業で全般的により賢いソフトウェア開発エージェントだが、GPUシェーダのようなものを書くときに出てくるコードは、整形も可読性もまったく試みられていない状態だというのだ(@meowface)。
ここで二つの記事が出会う。Cognitionの発表文で最も丁寧に説明されている技法はコストペナルティである。単一のRL実行の中で努力レベルごとに線形のコストペナルティを適用し、各ペナルティを基盤モデルのパレートフロンティアの局所的な傾きに合わせて調整するという。目的は実際のユーザーコストを学習にできるだけ直接反映することだと述べている。
優れた設計だ。しかしここでいう「実際のユーザーコスト」はトークンのコストである。Ronacherが指摘するコストはトークンではなくレビューだ。文字列操作でCコードを編集したパッチはトークンを少なく使えるかもしれないが、人がその変更を検討するのにかかる時間は増える。そしてその時間はどのベンチマークにも捕捉されない。課題を通過したかどうかだけが採点されるからである。
Ronacherがこの状況に付けた名前は正確だ。彼は中国語の内巻(neijuan)と英語のinvolutionを持ち出す。もともと農業の内巻化とは、単位面積あたりの生産性を上げながら一人あたりの生産性は据え置く集約化を指す。努力と競争は増え続けるのに、産出は良くならない状態だ。いまのAIがそう感じられるというのである。彼はAstra自体が非常に印象的なモデルであることを何度も認めている。コンピュータ操作に長け、画像と複雑な主題を理解し、完遂に向けて執拗だという。ただ当面は、実際のソフトウェアエンジニアリングでそれとどう働けばよいのか分からないと書く。
何を測定とするのか
実務者に残る問題はモデル選定ではない。評価基準である。
第一に、ベンダー自身のベンチマークと独立したベンチマークを分けて記録すべきだ。SWE-2の代表値が出たFrontierCodeはCognitionが作ったものである。これが不正だという意味ではない。ただその数字で調達を決めるなら、第三者ベンチマークでの順位と自社ベンチマークでの順位が食い違うかを確認しなければならない。そして発表文が併せて示したTerminal-Bench 4の27.3%対55.8%のような差は、ベンダーが隠さず表に載せた情報だ。表のすべての列を読むだけでもかなりの検証になる。
第二に、「安い」の分母を確認すべきだ。64%安いという主張は、同じ課題を同じ回数で解決するという前提でのみ成り立つ。課題がムラの大きい領域なら、安いモデルを三回回すコストが高いモデルを一回回すコストを超える。Ronacherの事例はこの計算の極端である。40億トークンと35時間を使って成果物がゼロだったなら、トークン単価は決定に何の影響も持たない。
第三に、レビュー可能性を独立した指標へ昇格させるべきだ。これが今回の二つの記事が共に指し示す結論である。チームで実際に測れる形に直すと、こういう問いになる。エージェントが作った変更のうち、人が読んで承認した割合はどれだけか。承認までにかかったレビュー時間の中央値は、モデルを変えた後に増えたか減ったか。ツール呼び出しが標準の編集ツールではなく即席スクリプトでファイルを直した割合はどれだけか。最後の項目は特に実用的だ。Hacker Newsの議論が示すように、これはハーネスの設定でかなりの部分を制御できる変数であり、制御可能な変数は指標にする価値がある。
見通しは分かれる。楽観的に見れば、これは学習目標の問題なので学習で直せる。コード品質とレビューのしやすさに対する報酬信号を入れればよい。Cognitionがコストペナルティを直接RLに入れたのと同様、可読性ペナルティを入れられない原理的な理由はない。悲観的に見れば、その信号は自動採点が難しい。課題の通過は機械が判定するが「読めるか」はそうではなく、採点できないものは最適化されない。現実的には、競争は当面いまの軸に沿って続く。ベンチマークのスコアとトークン単価は表に載せられるが、レビュー時間はそうではないからだ。
結論
Cognitionの発表文はパレートフロンティアを押し広げたと言う。その主張は彼らが選んだ軸の上では真でありうる。問題は軸の選択だ。能力とコストという二つの軸で描いたフロンティアには、「人が結果を検討するのにかかるコスト」という次元がない。
Ronacherが内巻化を持ち出した理由はここにある。単位面積あたりの産出は上がり続けるのに、一人が持ち帰る取り分は変わらない状態。ベンチマークのスコアは四半期ごとに上がり、トークン単価は下がり、それでも週末じゅう40億トークンを燃やした結果がゼロでありうる。この二つの事実は矛盾しない。互いに別のものを測っているだけである。
あなたのチームはコーディングエージェントを評価するとき、どの数字を見ているだろうか。その数字のリストに「この変更を人が読んで理解するのにかかった時間」は入っているだろうか。入っていないなら、いま削っているコストがどこへ移ったのかは、まだ測定されていない。
出典: