6 ポイント 投稿者 GN⁺ 1 일 전 | 1件のコメント | WhatsAppで共有
  • 2025年11月は最近のLLMの変化を測る基準点となり、コーディングエージェントの実用化とノートPCで動くモデルの躍進が中心だった
  • Claude Sonnet 4.5の後、GPT-5.1、Gemini 3、Claude Opus 4.5が素早く競い合い、Opus 4.5が数か月にわたって先頭に見えた
  • OpenAIとAnthropicの検証可能な報酬に基づく強化学習は、CodexやClaude Codeのようなハーネスでコード品質の向上として現れた
  • 休暇シーズンの実験はmicro-javascriptのような興味深い結果を生んだが、バグ・速度・安全性のため実際の必要性は限られていた
  • Gemma 4、GLM-5.1、Qwen3.6-35B-A3Bのようなオープンウェイトモデルは、フロンティアモデルより弱くても期待を大きく超え始めた

6か月を分けた二つの流れ

  • 2025年11月の転換点は、直近6か月のLLMの変化を見るうえで格好の基準であり、とりわけコーディング分野で重要な月だった
  • この6か月の主な変化は二つに要約できる
    • コーディングエージェントが日常の実務に使えるほど良くなった
    • ノートPCで実行できるモデルが、フロンティアモデルよりは弱くても期待を大きく上回り始めた
  • モデル比較には自転車に乗るペリカンのSVG生成テストが使われる
    • ペリカンを描くのは難しく、自転車を描くのも難しいうえ、ペリカンは自転車に乗れず、どのAI研究所もこの課題のためにモデルを学習させた可能性は低い、という点がこのテストの背景にある

11月のフロンティアモデル競争

  • 11月初旬に広く「最高」と認められていたモデルは、9月29日に公開されたClaude Sonnet 4.5だった
  • その後、「最高」の座は三つの大手プロバイダーのあいだで素早く入れ替わった
  • Gemini 3はこの比較群の中で最も良いペリカンの絵を描いたが、ペリカンテストだけでモデル全体を評価することはできない
  • Claude Opus 4.5は、その後数か月にわたって先頭を維持したモデルに見えた

コーディングエージェントが品質の壁を突破

  • 11月の本当の変化は、コーディングエージェントの品質向上だった
  • OpenAIとAnthropicは2025年の大半を、モデルが書くコードの品質を高めるための検証可能な報酬に基づく強化学習(Reinforcement Learning from Verifiable Rewards)に注ぎ込んだ
  • この改善は、CodexClaude Codeのようなエージェントハーネスと組み合わせたときに特に際立った
  • 11月には、コーディングエージェントは「しばしば動く」段階から「だいたい動く」段階へと進んだ
  • 利用者が大半の時間を愚かなミスの修正に費やさなくても、実際の仕事を任せられる日常ツールの水準に達した

休暇シーズンの実験と過熱

  • 12月から1月にかけて、多くの利用者が休暇期間を使って新しいモデルやコーディングエージェントに何ができるかを試した
  • モデルとエージェントは多くのことを成し遂げ、一部の利用者は野心的なプロジェクトを素早く作り始めた
  • micro-javascriptは、MicroQuickJSをゆるくPythonに移植したJavaScript実装だった
  • ブラウザプレイグラウンドは、JavaScriptコードがmicro-javascriptライブラリで実行され、そのPythonコードがPyodideの中で、WebAssemblyの中で、JavaScriptの中で、ブラウザの中で動く構造だった
  • 成果物は興味深いものの、バグがあり遅く安全でもない、半ば完成したJavaScriptのPython実装を実際に必要とする人はいなかったし、同時期に作られた他のプロジェクトも静かに引退した

OpenClawと個人AIアシスタント熱

  • 11月末に最初のコミットが上がった当時はほとんど知られていなかったリポジトリ「Warelay」が、その後急速に注目を集めた
  • 12月から1月にかけて何度も名前が変わった後、2月には最終名のOpenClawとして大きな関心を集めた
  • OpenClawは「個人AIアシスタント」であり、NanoClawやZeroClawのようなプロジェクトを含む総称としてClawsという表現が生まれた
  • シリコンバレー周辺では、Clawを動かすためにMac Miniを買う人が現れ、Mac Miniが品切れし始めた
  • Drew BreunigはClawを新しいデジタルペットになぞらえ、Mac MiniはClawにとって完璧な水槽だと冗談を言った
  • Clawsの比喩としては、2004年の映画Spider-Man 2でAlfred Molinaが演じたDoc Ockが挙げられる
    • 彼のクローはAIで駆動され、抑制チップが壊れない限り安全だったが、チップが損傷した後に邪悪になって彼を支配した

Gemini 3.1 Proとペリカンテストの拡張

  • 2月にはGemini 3.1 Proが公開され、自転車に乗るペリカンを非常に上手く描いた
  • 結果には、かごの中の魚まで含まれていた
  • GoogleのJeff Deanは自転車に乗るアニメーションのペリカン動画を投稿した
  • 同じ動画には、ペニーファージングに乗るカエル、小さな車を運転するキリン、ローラースケートを履いたダチョウ、スケートボードでキックフリップするカメ、ストレッチリムジンを運転するダックスフントも含まれていた
  • この結果は、AI研究所がペリカンテストのような奇妙な課題にも注意を払っていた可能性を、冗談めかして想起させた

4月のオープンウェイトモデル

  • GoogleはGemma 4モデルシリーズを公開した
  • Gemma 4は、米国企業のオープンウェイトモデルとして見た中で最も高性能なモデルと評価された
  • 中国のAI研究所GLMはGLM-5.1を公開した
    • GLM-5.1は1.5TB規模のオープンウェイトモデルだ
    • 動かせるハードウェアを用意できるなら、非常に有効なモデルだ
  • GLM-5.1は自転車に乗るペリカンをかなり巧みに描いたが、アニメーションの試みでは自転車が上方向に跳ねて歪んだ
  • CharlesがBlueskyで提案した「電動キックスクーターに乗るNorth Virginia Opossum」という課題では、他のモデルが近づけない結果を出した
    • 結果には「Cruising the commonwealth since dusk」という文句が含まれていた
    • 生成物はアニメーションとしても提供された

ノートPCで動くモデルが期待を超える

  • 4月のもう一つの注目すべき中国発オープンウェイトモデルはQwenから登場した
  • Qwen3.6-35B-A3BはノートPC上でClaude Opus 4.7より良いペリカンを描いた
  • このモデルは20.9GBのオープンウェイトモデルで、ノートPCで動作可能だ
  • この結果は、「自転車に乗るペリカン」が有用なベンチマークとしての限界をすでに超えていることも示した
  • ノートPCで実行可能なモデルはフロンティアモデルよりはるかに弱いが、この6か月で期待値を大きく上回る結果を出し始めた

1件のコメント

 
GN⁺ 1 일 전
Hacker Newsの意見
  • このペリカンが自転車に乗るテストは馬鹿げた指標だと言われがちだが、実は約3年前の Microsoft の初期 GPT レポート "Sparks of Artificial General Intelligence: Early experiments with GPT-4" [1] で紹介されていたことは、あまり覚えられていないように思う
    その後すぐに宣伝アカウントのネットワークが追随して広め、AI の誇大宣伝をする人たちがモデルを「テスト」するたびに使うものになった
    マーケティング100%、科学0%
    [1] https://arxiv.org/pdf/2303.12712

    • 気になる人のために補足すると、Simon がこれを最初に公に使ったのは 2024年10月25日[0] のようだ
      論文で「自転車に乗るペリカン」プロンプトが具体的にテストされた事例[1]は知らないが、GPT 論文には複数の SVG や tikz のテストがあり、実際の画像はかなり恣意的だ
      特定の1枚の画像に最適化するのは望ましくないが、学習がある程度きちんとしていれば、自転車に乗るペリカン程度はそこまで難しくないはずで、[0] の複数ページを見るとかなり良い例もいくつかある
      [0] https://simonwillison.net/tags/pelican-riding-a-bicycle/?pag...
      [1] Simon の知名度を考えると、きっとどこかにはあるはずだ
    • 生成 AI が出てきた当初から、個人的に使っていた非公式テストは「川の上で自転車に乗る老人の絵」だった
      さっき ChatGPT のデフォルトモデル (5.5) で試したところ、老人は古びた自転車に乗っていて、その自転車はゆるく張られた綱の上にあり、その綱が川の上へと伸び、背景には中世の村がある
      要点は、プロンプトに微妙な両義性があることだ。「老人はどうやって川を渡るのか?」という部分では、ほとんどの人間は川をまたぐ普通の橋をすぐ思い浮かべ、そのような橋がある程度に開発された地域の川辺の風景を想像するはずだ
      だから、こうしたモデルは条件をだいたい満たすものを見つけたり生成したりする能力は向上しているが、人が自然に引き出す常識的な前提をまだ取りこぼしている部分があると思う
  • 「変曲点」が本当の現象なのかマーケティングなのか気になる
    モデルがある程度良くなったのは事実だが、今でも最新モデル (Codex + gpt5.5、gpt5.3-codex の組み合わせ) でゲームをバイブコーディングしようとすると、かなり苦戦する
    骨組みは確かに作って動かしてくれるが、完成度の高いアプリケーションとは程遠い

    • Opus 4.5 以前はかなり手取り足取りで、自分でも多くコーディングしていたが、あの日以降ほとんどコードを書いていないことを非常にはっきり覚えている
      Enigma 暗号機の仕組みを学ぶために自分で何かを書いたことはあるが、それは学習目的だった
      業務的には11月からコーディングをやめたようなものだ
    • 逆説的だが、中核能力の限界効用が下がり始めても、複数回の変曲点は起こり得ると思う
      特定用途で「十分に良くなる」という閾値超えが起きると、機能が急に開くからだ
      昔の釘打ち機は重く太い電源ケーブルが必要で、非常に高価だった
      それがより軽く、安く、バッテリーパック式になったことで、ある時点から屋根職人の作業フローに自然に溶け込み、こなせる作業量を劇的に増やした
      その後の限界改善は、同じレベルの「解放」を生まないかもしれない。すでに閾値を超えているからだ
    • 最近、Codex 5.5 と Claude Code Opus 4.7 を組み合わせて、かなり複雑なものまで「バイブ」で作った
      重要なのは、最初に全体設計文書へかなり時間をかけ、それを具体的で制約のある段階に分解することだった
      その文書を2つのモデルの間で行き来させ、両方が満足するまで磨き込む
      各段階ごとに実装計画を作り、終わったら何を納品し何を発見したかの要約文書を残す。これが次の段階への入力になる
      文書と実際の作業内容は確認し、テストも見て、一部はより慎重に確認する。コード構造が気に入るかどうかも部分的に点検する
      主に Claude をコーディングに、Codex を設計と段階ごとのコードレビューに使い、段階が終わるたびに両方へテストカバレッジを確認させた
      このやり方で、自分では1行もコードを書かずにツールやライブラリを実装でき、実際かなり有用だった
      非同期に進むので、モデルがゆっくり処理している間に別の作業ができる
      ただし普遍的ではないと思う。テストしやすく、達成したい目標は明確だが正確な方法までは決まっていない作業では印象的だった
    • スタートラインまでは運んでくれるが、コードをのぞくと重複コード、責務の混在、悪い構造、トークンを食い潰す1万行ファイルのようなひどい状態が見える
      Web サイトやソーシャルからテキストと画像が混在した非構造イベントデータを収集するのに LLM を使っているが、妥当なコストで100%一貫した結果を得るには、作業を非常に小さな断片に分割して誤差範囲を大幅に減らすしかなかった
      現在のそこそこ複雑な作業では、Codex/Claude は喜んでユーザーを高くつく袋小路へコーディングしてしまうことがある
    • 2025年11月のOpus 4.5は本当に、皮肉抜きで変曲点であり、現在の熱狂を生んだ唯一の理由だと思う
      GPT 5.5 は GPT 5.4 よりかなり改善されたが、変曲点とは呼ばない
  • 「コーディングエージェントが本当に良くなった」と言われると、2025年11月のいわゆる「変曲点」以後でも、いったい誰にとって本当に良くなったのか気になる
    観察した限りでは、ツール呼び出しや大規模コードベースへの質問応答、とくに探すべきパターンが曖昧な質問には良くなっており、その用途では非常に有用だ
    しかし多くの指示と面倒見を加えても、本番コード生成にはまったく至っておらず、個人的な経験ではまだその近くにすら来ていない
    マーケティング過熱の中で 1 と 0 のように語るのはもうやめるべきだ。エージェントの能力は連続的なスペクトラムで、作業中のコードベースの複雑さに大きく依存する
    誰もが日常業務の中でこの道具をどううまく適用するかを、まだ模索している段階だと思う
    ところが、これは現在のナラティブと衝突する。そのナラティブは、私たちの仕事をいつも同じで簡単に自動化できるものへと平板化してしまうが、実際はそうではない
    だから議論がこうも二極化するのだと思う。共有された経験がないのだ

    • 二極化は、異なる人たちがこの道具を使うときに出会うコーディング体験と出力品質が大きく異なるから生じる
      たとえば私の経験は真逆で、Claude で非常に高品質な成果物を作ってきた(https://github.com/kstenerud/yoloai)
      使っている技術のバグや癖に対処する過程で、エージェントは実装段階で何度もつまずかないよう、それらを発見して一覧化するのに大いに役立った: https://github.com/kstenerud/yoloai/blob/main/docs/dev/backe...
      エージェントは着実に良くなっている。ここ1か月だけ見ても、研究、設計、アーキテクチャ、計画文書を作る際に、問題を予測し含意を適切に推論する能力がかなり優れていた
      コーディング段階になると大半は機械的な過程で、Sonnet に渡しても欠陥率はごく小さい
    • 最新モデルが、指示や面倒見をつけても本番コードを作れるほど良くないと感じるというのは驚きだ
      私の経験では Claude Code、主に Opus 4.6 はこの作業に素晴らしい。少なくとも JS、TS、Elixir、Ruby ではそうだ
      たしかに面倒見は必要で、頭の中のモデルは「ジュニア開発者」ではなく外骨格に近い。だが体感として非常に強力な外骨格で、ほとんどの作業で速度を簡単に10倍にしてくれる
      とくに --dangerously-skip-permissions も使わないし、Claude Code の自動モードも使わない。書かれる行を一つずつ軽く確認しながら細かく管理するので、同時に生成するセッションは普通2つを超えない
      失望は、人々がこれを委任し、脱線しないと信じようとするときに多く生じるのではないかと思う。まだ私にそこまでの信頼を得ていないし、まだその必要もなかった
      ただ、主にテスト込みで 2万〜3万行程度の中小規模コードベースで作業している。これが前向きな経験の要因なのか気になる
    • コーディングにおける良し悪しは、単に不均等に分布している
      実際には (a) 人々の AI との働き方が無数の小さな島のようにばらばらで、(b) ボトルネックは開発者ごと、コードベースごと、作業ごとに大きく異なる
      また現代には、変化=進歩、生産性という内在的バイアスがあると思う
      1990〜2000年の「ネットワークコンピューティング革命」を見ると、コンピューターはあらゆる机とポケットに入り、事務作業には強力だった
      しかし最終結果は「変化」だった。手紙よりはるかに多くのメールを送り、はるかに多くコミュニケーションするようになり、秘書は消えたが「事務」そのものは増えた
      大学教員には普通さらに多くの事務職員がつき、企業は経理、人事、プロジェクトマネージャーをさらに多く雇う
      もしかすると事務は、そもそも本当のボトルネックではなかったのかもしれない
      コードにもこういう面が多い。誰にでもロードマップやウィッシュリストがあり、「コード生産能力」がボトルネックに見える
      だが大半の会社は、ソフトウェアをもっと多く作ればもっと価値を生み出せるわけではないのかもしれない
      体感として、多くの中堅企業はスタック移行やモダナイゼーションのような作業をしている。機能を大量投入して価格や売上を上げるという話はあまり聞かない
      ほとんどのボトルネックは別のボトルネックの上流にあるだけで、本当の「ダム」は稀だ
    • 変曲点があったかは分からないが、この1年で自動補完以上の用途には確実に有用になった
      最近の個人プロジェクトは Wasm から Go へ変換するトランスパイラだが、最新モデルたち (Sonnet、Opus、Gemini を使い、GPT よりずっと成功した) がプロジェクト全体を把握して複数の層を扱えることには非常に感心した
      トランスパイラを実装する Go コード (Wasm のパース、AST 構築)、AST を .go ファイルへシリアライズして生成される Go コード、AST を操作して最適化する Go コードとそれが生成コードへ与える影響、より高度な命令を実装するため生成コードへ接ぎ木する Go コードと AST での相互作用、C コードが Wasm にコンパイルされ Go に翻訳された後に Go から呼ばれる流れ、C 標準ライブラリを実装するためその C コードから呼ばれる Go コード、さらには Wasm 仕様テストを実装する WAT/WAST ファイルに至るまで、すべてを扱える
      これらの層を全部考えるには私でもかなり頭を使うし、多くのプログラマーにとっても難しいと思うので印象的だ
      そして「このコードを生成したいので、それを行う AST を作ってくれ」と書くほうが、Go コード内で括弧を数えるよりずっと簡単なことが多い。LISP の経験が多少あってもなお、そのほうが楽だ
      コードレビューや批判は歓迎する。バイブコーディングではないが、生成 AI の助けは大いに借りた
      https://github.com/ncruces/wasm2go
    • 昨日は Anthropic の一般向け 20ドル購読制限のおかげで、一日中上限に引っかからず遊べて本当に楽しかった
      小さなブラウザゲームなので、セキュリティや完全性の要求は非常に低いが、「実際に動かしてみること」と「楽しさ」の要求は高い作業で、ある種の本番コードとは言える
      生成されたコードにはコンパイルエラーが 0 件で、1つの作業について 10 個の ToDo を説明しても全部こなしていった
      有用になるために、これ以上ずっと良くなる必要はない。研究者のように数学はどうせ検証が必要だが、テストデータのフィルタリング、変換、実行コードをうまく書けない人たちには、すでに非常に有用だ
      小さな Web サイト、遊びのプロジェクト、補助ツールのような用途にも、もう十分良い
      同時に裏では、さらに多い計算資源、より良いアルゴリズム、より多い強化学習といったことが進み続けている
      私たちが気づかないうちに「AI がコーディングの仕事を奪う」の95%地点まで、すでに来ているのかもしれない。残りの5%があまりに重要だからだ
  • 今どこかで人間のアーティストが、大手 AI 研究所の訓練データとして使われる自転車に乗るペリカンの絵を描いている気がする

    • 現代の画像生成モデルはどれも、自転車の上のペリカンを簡単に生成できる
      このテストの要点は、画像を表すSVG テキストを生成することで、そこがより複雑なのだ
      ラスター画像を SVG に変換して訓練データに使う方法もあるが、誰の時間にとっても良い使い道ではない
    • Gemini のペリカン品質は1回の反復で大きすぎる段差的変化を見せ、他のベンチマークはかなり横ばいだったので、その可能性はあると思う
      ただ、彼らがペリカンそのものを狙ったのか、単にSVGを狙ったのかは分からない
  • この6か月は、人類が LLM に対する統制力を失った期間のように見える
    ローカル AI 導入を緩和し得た優れたオープンモデルが登場したにもかかわらず、メモリ市場の掌握が起き、世界中の企業に知的財産流出ツールが急速に浸透した
    開発者たちは、自分で読める量を超えるコードを作っている
    自律エージェントはアテンション経済を吸い尽くしてオープンソースを殺し、オンラインコミュニティ (HN を含む) を壊し、戦争 (標的指定、プロパガンダなど) にも使われている
    広範な脆弱性が発見され、大規模なサプライチェーン攻撃が続いている
    不平等の拡大、認識の分裂、緑色の指標と暗い現実が並存している

    • 悪いニュースばかり読めば、とくに最近の大衆ニュースのようにより売れるものばかり見ていれば、そういう絵になるだろう
      だが個人的には、バイオテックで信じがたいことが起きているのを見てきた。こんな未来に生きる可能性があること自体が信じられないほどだ
      すでにAlphaFoldを使って開発された実際の治療薬が、現実の臨床試験でテストされており、今後 3〜5 年で臨床入りする次世代は驚くべきものになるだろう
      後になって、私たちは今の医学を今日の中世を見るような目で振り返ることになる気がする
    • AI 過熱は、もともと存在していたソフトウェアエンジニアリングの亀裂をより露わにしただけだと思う
      理想を言えば、この過熱サイクルを通り抜けたあとに、より良い実践を学んで出てこられるといい
    • 広範な脆弱性が発見されるのは良いことだ
    • Metal Gear Solid 2 は、2025年までは奇妙で笑える作品だった
    • 「メモリ市場の掌握」って、ちょっと待って、それは何なんだ?
      「世界中の企業に知的財産流出ツールが急速に浸透」は、むしろ利点の側に入ると思う
      アテンション経済に関わるものが消えるのは、私にとっては全部「どうぞご自由に」に近い
  • 非プログラマー視点で、この6か月がどうだったのか気になる
    他分野の人たちは、どんな協働ツールやそれに近い最適化を経験したのだろうか?

    • 見習い制度を運営する講師なのだが、新しい上司は業界で20年ほど働き、社内でもっとも尊敬されている人の1人だ
      最近うちのチームに加わって教えるようになり、2週間のコースに参加しているのだが、初日に AI にすべての授業計画を書かせ、その計画をまた AI に入れてスライドを作れという指示を受けた
      これをきっぱり拒んでくれればいいのだが、そうしないと受講生たちは、その人の経験や人間味、伝えられるものを何一つ得られなくなる
      講師として私は6か月ごとにレビューを受けるが、毎回同じことを言われる。「授業で AI をどう使えますか?」
      なぜそれが望ましいのか、なぜ必要なのかを説明する必要すら感じていない。ただの純粋な流行便乗
      信じがたいことに同僚の大半は AI に非常に前向きだが、授業準備以外のどこで使っているのか誰も話していない。考えたり準備したりする時間を使わないために使っているだけで、それこそが職場で唯一大事な仕事なのに、だ
      私にはまったく理解できない
    • 純粋数学では、GPT-5.4 以前の用途は非常に限られていた
      賢い人たちはモデルからある程度の成果を引き出していたが、常に真剣な作業と非常に相性のよい問題が必要だった
      もちろん宿題問題は解けたが、教える立場からすると、それはむしろ欠点にも感じられた
      GPT-5.4 (2026年3月) 以後は「うわっ」となるリリースだった。以前は専門家を詰まらせていた MathOverflow 級の問題に、突然答え始めた
      まだ幻覚はあったが、可能なときには小さな例で主張を検証しようと内蔵 Python 能力を使うくらいには賢かった
      抽象的で「哲学的」な数学より、公式の多い数学にはるかに強いようだ
      GPT-5.5 は MO 級の難問について、魅力的でかなり非自明かつ非常に教育的な本に載っていそうな証明を出してきて、今それを文章にまとめているところだ
      運や良いプロンプトのおかげだったのかもしれない。5.4 から質的飛躍とまでは感じないが、量的改善でもいつでも歓迎だ
      依然として相性のよい問題は必要だが、最初から相性が悪いと切り捨てるのはずっと難しくなった
      Claude と Gemini は引き続き二軍で、今もそうだ。Claude は秘書のような作業に使い、たまに簡単な証明も見つけるが、たいていは私が明白な点を見落としていたからだ
      そして GPT、少し劣るが Claude も、数学の誤りを見つけるのに素晴らしい。これまでのプロンプトのたぶん90%は、自分の文章を校正するのに使ってきた
    • 企業向けに AI を展開する会社で働いている
      平均的な事務職の社員は Copilot に驚いている。IDE 内の Copilot ではなく、Windows に同梱されたアプリのほうだ
      主に資料を会社支給の ChatGPT/Gemini にコピペし、Facebook/Instagram で「業務生産性のためのベストなプロンプト5選」みたいなコツを得ている
      大規模に業務を自動化するエージェントを見せると、ほとんど魔法のように受け止められる
    • 周囲の非技術職の人たちにとっては、Claude in Officeが転換点だった
      いまや皆のスライドデッキはきれいに整い、財務チームは BI の助けをずっと必要としなくなった。かなり印象的だ
    • ビジネスでは協働ツールを使ってメールをチェックし、保管方法を提案させ、ファイルやフォルダを管理し、毎日イントラネット上の興味深く関連性のある内容をざっと見させている
      個人的には、妻が母語ではない小中高生に自分の母語を教えているのだが、今では子どもたちが皆こうしたツールを使って学校の授業計画に合わせた新しい練習コンテンツを生成している
      数か月前より、子どもたちの上達がずっと早くなっている
  • Simon のブログがあまりに有名であることを考えると、どの AI 研究所もそんな馬鹿げた課題向けにモデルを訓練していないだろうという話は、もはや確信しにくい

    • 記事でも「AI 研究所が結局は注目したのかもしれない」、「自転車に乗るペリカンは有用なベンチマークとしての限界を明らかに超えてしまったことを主に示している」と認めている
    • Simon は記事の後半で、Jeff Dean が自転車に乗るペリカン課題に触れたことや、現在のモデルがどれだけうまくやるかを踏まえると、もはや良いベンチマークではないと言っている
      いまや電動キックボードに乗るフクロネズミの番だ
    • その部分は発表ではもっと受けた気がする。後で出てくるジョークのための前振りだった
    • 事実上ベンチマークになってしまった。何人かの友人は、"strawberry" に含まれる R の数を数えさせるようモデルを具体的に訓練している
  • このスレッドを読むと、変曲点論争のかなりの部分は、何が改善したのかについて互いに食い違って話していることから来ているように見える
    私の解釈では、11月ごろにモデル自体の能力が大きく跳ねたというより、その周辺のハーネスがずっと安定し、2025年初頭の RLVR の取り組みがモデルをそのハーネス内でうまく振る舞うよう訓練してきたのだと思う
    そのため、両者が出会ったとき、それぞれ単独では劇的でなくても、合成効果によって段差的変化のように感じられた可能性が高い
    だから、このスレッドでは経験がここまで違うのだろう。モデルにコードを尋ねて貼り付けるようなフローを使っていた人には改善は緩やかで、なぜこんなに大騒ぎなのかともっともに不思議がるはずだ
    逆に、すでにエージェントを20段階ループで回していた人には、はるかに大きな変化だっただろう。以前は12段階目の失敗が20段階あたりでゴミに増幅されるのが問題だったが、その部分が大きく改善したからだ
    Simon が軽く流したローカルモデルの話も、同じ理由で興味深い。20GB モデルがノート PC 上でまともなペリカンを描くこと自体は、単独ではかわいい豆知識にすぎない
    注目すべきは、良いハーネスの中にある有能なローカルモデルが、ハーネスなしで最前線モデルを回すよりも、いまや最前線性能により近づいている点だ

  • Gemini に「Hyde Park で一輪車に乗るペリカン」の動画を頼んだら、結果にかなり驚いた
    https://gemini.google.com/share/55e250c99693

    • 原文著者の説明によれば、このテストを使う理由は、ペリカンは描くのが難しく、自転車も描くのが難しく、ペリカンは自転車に乗れず、どの AI 研究所もこんな馬鹿げた課題向けにモデルを訓練する可能性がないからだという
      この時点では、競合する AI 研究所が、いまやよく知られたこの「テスト」をなぜ訓練しないのかという気もする
    • グラフィックとしては完璧だが、内容としてはおかしい
      ペリカンの重心が明らかに車輪の後ろにある。車輪の上か、せいぜい少し前であるべきだ
    • Grok も驚かされた
      https://grok.com/imagine/post/8d1eab88-737f-4d46-ba92-9b6502...
      画像生成より動画生成のほうが、ペリカンがペダルをこぐ様子をうまく作れているのが興味深い
    • Google/Gemini の視聴覚能力はかなり印象的だ
      Claude に造園写真へマルチを追加してくれと頼んだら、MS Paint のオレンジ色スプレーツールで塗ったように見えた
      Nano Banana は実物にかなり近い結果を出した
    • 本当に印象的で、映画・アニメーション・モデリング分野のクリエイターにとっては少し不安になる
  • 「PyCon US 2026 での5分ライトニングトーク用に注釈付きスライドを作った」と言っていたが、この発表の動画や音声があるのか気になる