Andrej Karpathyによる2025年LLM年間レビュー

 (karpathy.bearblog.dev)
21 ポイント 投稿者 GN⁺ 2025-12-21 | 2件のコメント | WhatsAppで共有
  • 2025年は 検証可能な報酬に基づく強化学習（RLVR） がLLM訓練の新たな中核段階として台頭し、従来の事前学習-SFT-RLHFパイプラインに追加された
  • LLMが数学・コードパズルなどの 検証可能な環境 で自ら推論戦略を発展させ、人間には「思考」のように見える問題解決のやり方を獲得した
  • Cursorが LLMアプリの新しいレイヤー を定義し、特定のバーティカルでコンテキストエンジニアリングと複雑なLLM呼び出しのオーケストレーションを行う方法を示した
  • Claude Codeがユーザーのローカルコンピュータで動作する LLMエージェントの最初の説得力ある事例 として登場し、AIとの新しい相互作用パラダイムを提示した
  • バイブコーディング（Vibe Coding） により、非専門家でも英語だけでプログラムを作れるようになり、ソフトウェア開発の民主化と職業定義の変化を予告した

1. 検証可能な報酬に基づく強化学習（RLVR）の台頭

  • 2025年初頭まで、LLMのプロダクションスタックは 事前学習（Pretraining）、教師あり微調整（SFT）、人間のフィードバックによる強化学習（RLHF） の3段階構造だった
  • RLVR（Reinforcement Learning from Verifiable Rewards） が新たな主要段階として追加され、数学・コードパズルなどの 自動検証可能な報酬 に対してLLMを訓練する
  • LLMは自ら問題を 中間計算ステップへ分解 し、多様な問題解決戦略を開発するという、「推論」に似た振る舞いを自発的に獲得した
    • こうした戦略は最適な推論トレースが何か不明確であり、以前のパラダイムでは達成が難しかった
    • LLMは報酬最適化を通じて 自分に合ったやり方 を自ら見つけなければならない
  • SFT/RLHFと異なり、RLVRでは 客観的でゲーム化できない報酬関数 に対して、はるかに長い最適化が可能
  • RLVRの高い コスト対性能（capability/$） により、もともと事前学習向けだった計算資源がRLVRへ再配分された
    • 2025年の能力進歩の大半は、同程度の規模のLLMに より長いRL実行 を適用することで定義された
  • テスト時コンピューティング の調整という新たなノブ（およびスケーリング則）が登場し、より長い推論トレース生成と「思考時間」の増加によって能力を調整できるようになった
  • OpenAI o1（2024年末）が最初のRLVRモデルの実演であり、o3の公開（2025年初頭） が直感的に違いを感じられる変曲点だった

2. 幽霊 vs. 動物 / ぎざぎざの知能（Jagged Intelligence）

  • 2025年にはLLMの知能の 「形」 をより直感的に理解し始めた
  • LLMは「動物を進化・成長させる」ものではなく、「幽霊を召喚する」 ものだ
    • ニューラルアーキテクチャ、訓練データ、訓練アルゴリズム、最適化圧力のすべてが異なるため、知能空間において極めて異質な存在が生まれる
  • 人間の神経ネットワークは ジャングルで種として生き延びること のために最適化されてきたが、LLMの神経ネットワークは 人類のテキストの模倣、数学パズルの報酬獲得、LM Arenaでのアップボート獲得のために最適化されている
  • 検証可能な領域でRLVRが可能になったことで、LLMはその分野で能力が 「スパイク」 し、不均一な性能特性 を示すようになった
    • 同時に 天才的な博識家 でありながら 混乱した小学生 のようにも振る舞い、数秒で脱獄にだまされてデータ漏えいを起こし得る
  • ベンチマークに対する 信頼の喪失と無関心 が起きた
    • ベンチマークはほとんど定義上、検証可能な環境なので、RLVRや合成データ生成の弱い形に即座に脆弱になる
    • ベンチマークマキシング（benchmaxxing）の過程で、チームはベンチマーク埋め込み空間の近傍に環境を構築してカバーする
    • テストセット学習が新たな技術として定着する
  • 「すべてのベンチマークを通過してもAGIには到達していない」状況とはどのようなものだろうか？
  • 関連記事

3. Cursor / LLMアプリの新しいレイヤー

  • Cursorの急成長とともに、「LLMアプリ」の新しいレイヤー が明らかになった
    • 「Cursor for X」という表現が使われ始めた
  • CursorのようなLLMアプリは、特定のバーティカル向けにLLM呼び出しを束ねてオーケストレーションする
    1. コンテキストエンジニアリング を行う
    2. 複数のLLM呼び出しを次第に複雑な DAGとしてオーケストレーション し、性能とコストのバランスを調整する
    3. Human-in-the-Loop のためのアプリケーション固有GUIを提供する
    4. 「自律性スライダー」 を提供する
  • この新しいアプリレイヤーがどれほど 「厚い」 のかについて活発な議論がある
    • LLMラボがすべてのアプリケーションを席巻するのか、LLMアプリに機会があるのかをめぐって議論されている
  • LLMラボは一般に有能な大学生を輩出する傾向があるが、LLMアプリは特定のバーティカルで プライベートデータ、センサー、アクチュエータ、フィードバックループ を供給し、それらを組織化・微調整して実際の専門家として機能させると予想される

4. Claude Code / コンピュータに常駐するAI

  • Claude Code（CC）が LLMエージェントの最初の説得力あるデモ として登場した
    • ツール利用と推論をループ方式で接続し、拡張された問題解決を行う
  • CCはユーザーのコンピュータ上で プライベートな環境、データ、コンテキスト とともに動作する
  • OpenAIは初期のCodex/エージェントの取り組みを、ChatGPTでオーケストレーションされる クラウドコンテナ配備 に集中させたため、方向を誤った
    • 単に localhost ではなくクラウドに集中していた
  • エージェントのスウォームがクラウドで動作することは「AGIエンドゲーム」のようにも感じられるが、現状は 不均一な能力を持つ中間的で遅い飛躍の世界 だ
    • エージェントを開発者のコンピュータ上で直接実行するほうが合理的である
  • 重要な区別は「AIタスク」がどこで実行されるかではなく、すでに存在して起動済みのコンピュータ、インストール、コンテキスト、データ、シークレット、構成、低遅延の相互作用 に関するものだ
  • Anthropicはこの優先順位を正確に捉え、CCを 簡潔なCLIフォームファクタ にパッケージした
    • AIはGoogleのように訪れるウェブサイトではなく、コンピュータに 「常駐する」 小さな魂／幽霊だという新しい相互作用パラダイム

5. バイブコーディング（Vibe Coding）

  • 2025年は、AIが 英語だけで 多様で印象的なプログラムを作れる能力の閾値を超えた年だった
    • コードの存在自体を忘れてプログラミングできる
  • 「vibe coding」という用語をツイートで作ったが、これほど広まるとは予想していなかった
  • バイブコーディングによって、プログラミングは 高度に訓練された専門家だけの領域ではなく、誰でもできるものへと変わった
  • LLMは他のどの技術とも異なり、一般の人々が専門家、企業、政府よりもはるかに大きな恩恵 を受ける事例である
  • バイブコーディングは一般の人にプログラミングへのアクセスを提供するだけでなく、訓練された専門家が そうでなければ書かれなかったであろう（バイブコーディングされた）ソフトウェア をはるかに多く書けるようにする
  • 具体例:
    • nanochatでは、既存ライブラリの採用やRustの深い学習なしに、Rustによるカスタム高効率BPEトークナイザ をバイブコーディングした
    • menugen、llm-council、reader3、HN time capsuleなど、あったらいいと思うものを 高速なアプリデモ としてバイブコーディングした
    • 単一のバグを見つけるために 一回限りのアプリ全体 をバイブコーディングした。コードは突然、無料で、一時的で、柔軟で、使い捨てのものになった
  • バイブコーディングは ソフトウェアをテラフォーミング し、職業の定義を変えていくだろう

6. Nano Banana / LLM GUI

  • Google Gemini Nano Banana は、2025年で最も驚くべきパラダイムシフトモデルの1つだ
  • LLMが1970〜80年代のコンピュータに類する 次の主要なコンピューティングパラダイム だという世界観では、同種の革新が根本的に同様の理由で起きることになる
    • パーソナルコンピューティング、マイクロコントローラ（認知コア）、インターネット（エージェントの）などに相当するものが登場するはずだ
  • UIUXの観点では、LLMと 「チャット」 することは1980年代のコンピュータコンソールに命令を出すことに似ている
  • テキストはコンピュータ（およびLLM）にとって好ましい生データ表現だが、人間にとって好ましい形式ではない
    • 特に入力面では、人はテキストを読むのを好まない。遅く、努力が必要だからだ
  • 人は情報を 視覚的かつ空間的に 消費するのを好むため、従来のコンピューティングではGUIが発明された
  • 同様にLLMも、人間が好む形式である 画像、インフォグラフィック、スライド、ホワイトボード、アニメーション/動画、ウェブアプリ などでコミュニケーションすべきだ
  • 現在の初期バージョンは絵文字やMarkdownのようなものだ。見出し、太字、斜体、リスト、表などでテキストを 「視覚的に装飾し」 配置している
  • Nano Bananaは LLM GUI がどのようなものになるかについての最初の初期的ヒントだ
    • 画像生成そのものだけでなく、テキスト生成、画像生成、世界知識 がモデル重みにすべて絡み合った 結合能力 が重要である

TLDR; 総まとめ

  • 2025年はLLMにとって刺激的で、少し驚きのある年だった
  • LLMは 予想よりはるかに賢い一方で、同時に予想よりはるかに愚か な 新しい種類の知能 として台頭した
  • いずれにせよLLMは非常に有用であり、現在の技術レベルでも業界はその潜在力の10%も活用できていない と考えている
  • 試してみる価値のある アイデアは無尽蔵 であり、概念的にこの分野は まだ先が長いように見える
  • （見かけ上は逆説的だが）今後 速く持続的な進歩 があると信じる一方で、まだ やるべきことは多い とも考えている

関連記事

2件のコメント

 
laeyoung 2025-12-21

「menugen、llm-council、reader3、HN time capsule など、あったらいいものを高速なアプリのデモとしてヴァイブコーディング」

さすがヴァイブコーディングの父だけあって、ヴァイブコーディングで作るものが、私が作ったささやかなものとは桁違いですね。🤣
 
GN⁺ 2025-12-21
Hacker Newsの意見

  • 今年、自分にとって最も印象的だった革新は Claude Code だった
    Cursorは良い概念実証だったが、実際に自分がLLMをコーディングに使うようになったきっかけはClaude Codeだった
    Claudeが生成するコードは、ほとんど自分で書いたコードと同じで、まるで自分の考えを読んでいるように感じる
    そのおかげでClaudeが作ったコードを保守するのも簡単だ
    コードスタイルを90〜95%くらい予測できるし、自分よりはるかに速く書いてくれる
    Geminiも印象的だが、特に Nano Banana はグラフィックデザインに役立つ
    コーディングにはまだGeminiを使っていない。Claude Codeがあまりに優秀なので、これ以上速くコーディングできるようになるとかえって 決定疲れ が来そうだ
    自分はアーキテクチャやUXの判断を急がず、1日か2日考えてから実装を始めるタイプだ。一つの方向に進み始めると戻りづらく、埋没費用の誤謬 によって間違った選択に固執してしまうからだ

    • もうCursorを使う理由をほとんど感じていない
      IntelliJ IDEAにClaude Codeプラグインを入れて、IDEはコード探索やレビュー用にしか使っていない
      もう2行以上のコードを自分で直接書いた記憶がない
      Claude Codeのおかげで生産性は少なくとも 5倍以上 向上したし、テストを書くコストがほとんどないのでテストカバレッジもずっと良くなった
      Claudeと一緒に計画を立て、質問し、実装させ、レビューし、修正を依頼するという完全な AIエージェントワークフロー を使っている
      手動コーディングはまったくない。完全にゼロだ
    • Nano Banana Pro は、きちんと扱い方がわかっていれば本当にとんでもないツールだ
      こんなものを公開したなんて、いまだに信じられない
    • 最初はGLMのコーディングプラン（月2ドル程度）を使ってエージェントコーディングを始めた
      だが毎回Claudeに、コードをもっと エレガントで読みやすく してほしいと頼んでいるうちに、結局Claude Codeに乗り換えた
      GLMも良いプロンプトを使えばかなり近いところまで行くが、1日0.6ドルでそうした心配をしなくて済むなら悩む必要はないと感じた
    • 毎月新しいツールを評価する時間がないのでCursorに落ち着いている
      同じモデルを使っていて、自分が何を見落としているのか気になる

  • Karpathyの文章は好きだが、最近は “It’s not X, it’s Y” のような LLM的な文構造 を見ると本能的に身構えてしまう
    3年前なら何とも思わなかったのに、今ではこういう文体が完全に壊れてしまったように感じる

    • その通り。そう指摘されてからというもの、自分も その文体が気になって 仕方がない
    • 以前は文中で em dash(—) をよく使っていたが、人から「AIが書いたみたいだ」と言われて、書き方を変えざるを得なかった
    • Karpathyの文章を読みに来たのに、もうLLMに聞いたほうがいいのではと思ってしまう
    • 自分はLLM以前からこういう文が嫌いだった
      “It’s not just a website…” のような文は 修辞的な贅肉(rhetorical fat) と呼んでいる
      そうした贅肉を落とせば、単調ではあっても明快な文になる
      特に “little spirit” のような表現は大げさに感じて、思わず目を丸くしてしまう
      もちろん著者は強調のために装飾しているのだろうが、自分の理想とする文章とは合わないので拒否感がある
      “It’s not just about image generation…” のような文は 不要な概念的緊張感 を与える
      むしろ「画像生成はテキスト生成と組み合わさるともっと面白い」と書いたほうがよいと思う
    • もうその文体が気になってしまって、インターネットを楽しむのが難しくなった

  • 素晴らしくて現実的なレビューだった
    「LLMは予想以上に賢いのに同時に間抜けでもある」という言葉が気がかりだ
    どちらの面に出くわすか、どうやって見極めればいいのだろうか？
    コーディングでは誤りを見つけやすいが、一般的な領域では難しいのではないかと思う
    また「一般の人々のほうが専門家よりLLMの恩恵を受ける」という主張について、昔の AppleScriptやVB、ビジュアルプログラミング にもそうした期待があったが、結局AIは賢い検索エンジンのように使われている
    しかし、その領域こそ 幻覚(hallucination) が最も深刻な場所でもあり、それが問題だと思う。解決策が知りたい

  • Andrejの楽観的な姿勢は好きだが、2025年に 産業の権力集中 がどう変わったのか、オープンソースとローカル推論、ハードウェア制約 のようなテーマについて彼がどう見ているのかも聞いてみたい
    たとえば彼はClaude Codeが「ローカルで動く」と書いていたが、実際には TUIだけがローカル で、推論はクラウドで行われている
    こうした構造が2026年以降どう発展していくのか気になる

    • CCのポイントは データと環境コンテキスト に関するものであって、計算をどこで行うかではない
      クラウド設定が不便なのは計算のせいではなく、UI/UXとユーザーループ のためだ
    • llama.cpp は現在Anthropicのメッセージ形式をサポートしていて、Claude Code と一緒に使える
    • ローカルで動かせる興味深いコーディングエージェントの一つは OpenAI Codex だ
      Ollamaでホストされるgpt-ossモデルと一緒に実行できる
      codex --oss -m gpt-oss:20b のように使え、さらに大きなモデル（120b）も可能だ
    • Karpathyが言う「ローカルで動くエージェント」とは、LangChainのようなウェブサービスではなく、LLM APIを呼び出すソフトウェアラッパー(Harness) を意味している
      このエージェントはBashを呼び出し、ファイルシステムを扱い、OS上でほぼ何でもできる
      つまり、モデルは遠く離れた 頭脳 で、エージェントは 機械スーツ のようなものだ
    • Claude Codeの部分はやや 曖昧に 書かれていたと思う
      彼は推論ではなく、エージェントがローカルで動く という意味で書いたのだろう
      OpenAIがCodexをクラウド中心に設計したのに対し、CCはローカル優先のアプローチを取ったことを強調したかったようだ
      ただ、こうした区別はもっと明確に説明される必要がある

  • Karpathyが言った「動物を飼うこと vs 幽霊を召喚すること」というRLVRの比喩は、現在の ギザギザした知能(jagged intelligence) を説明する完璧なモデルだと感じる
    私たちは一般的な生存者を作っているのではなく、検証可能な報酬に合わせて特定領域だけを過剰最適化している
    また「vibe coding による使い捨てソフトウェア」という概念にも共感する
    一つの問題をデバッグするために一時的なアプリを作って、すぐ消すという流れは本当に変化に思える

    • ただ、「動物 vs 幽霊」の比喩がそこまで洞察的だとは思わない
      人間や動物は本物の 知的存在 だが、LLMは人間の産出物を 狭い範囲で反響 しているにすぎない
      真の人工知能になるには、自律性、継続的学習、好奇心、仮想的身体性 のような特性が必要だ
      大半の動物は本能的だが、人間のように汎化された学習能力を持つ存在だけが真の知能を持つ
    • ただし、今のLLM利用は 補助金 があるから成り立っている面もある
      実際のコストを払うようになっても、こうした使い捨てアプリ作成が続くのかは見守る必要がある
    • 自分はもう何カ月もそういう使い方をしている。本当に楽しい
      自分の投稿 にまとめたが、Jupyterが始めたことを完結させるスタックだ
      関数型フェンス(fence) 構造で、呼び出し可能かつ合成可能だ
      MCPと同じような形で、特別な学習なしにパターンだけ覚えればよい
      しかも 18世紀のピアノ教育法とコンテキストエンジニアリングを結びつける関手(functor) まで存在する

  • Karpathyが言う「LLMは画像、スライド、ホワイトボードなど ユーザーが好む形式 で対話すべきだ」という部分は興味深い
    だが、LLMが毎回ユーザーごとに新しいUXを作るなら、予測不能なインターフェース地獄 になるかもしれない
    「このアプリでCommand-Wは何をするんだ？」のような状況が起きるだろう

    • 逆に、最近のエージェントの一部は アクセシビリティ(accessibility) を気にし始めている
      Codexのようなものは、人間よりむしろ丁寧なくらいだ
    • 人間の実際のコミュニケーション様式を見ると、1位は テキスト/音声、2位は 画像 だと思う
    • でも実のところ、LLMはすでにその問題を解決している
      LLMそのものが最高の UI だ
      複数言語や抽象概念を理解するので、わざわざランダムなUIを生成する必要はない
      自分は非英語圏の利用者だが、ドイツ語の単語を混ぜて書いてもちゃんと理解してくれる

  • 多くのAIインフルエンサーは「テキストUIは消える」と確信しているが、実際には テキストインターフェースが依然として中心 だ

    • 数日前、AI 3Dモデリングツールの購読を解約しようとして、5分間ボタンが見つからなかった
      結局、料金プランカードの 低コントラストな三点メニュー の中に隠れていて、クリックすると AIチャットボットの会話ウィンドウ が開いた
      “unsubscribe” とプロンプト入力して初めてボタンが現れた
      こういう 自動応答電話型のUX をアプリに持ち込むのはひどいと思う
      フロントエンドエンジニアとして、こういうトレンドは恐ろしく感じる
    • 自分が生きてきた間に、人はますます 会話より文字入力 をするようになった気がする

  • Andrejが今年の 高速モデル 群（Gemini 3 Flash、Grok 4 Fast）をどう見ているのか気になる
    これほど速く、安く、優秀なモデルが出てきたのに、コミュニティはほとんど注目していないようだ
    視覚的インターフェースのためのLLMビジョンが実現するには、こうしたモデルが不可欠だと思う

    • おそらく、こうした小型モデルは大型モデルの 蒸留(distillation) 版である可能性が高い
      大型モデルが生成した 推論トレース(reasoning traces) で学習したのだろうと推測している
    • Sasha Luccioni の研究を参照するとよい

  • 2025年は 訓練データに幽霊が宿り始めた年 でもある
    今やX（Twitter）の半分は、LLMがLLMに返信する構造になっている
    つまり、データセット内部で呼び出しが起きている状況 だ

    • こうしたLLMアカウントを 見分けるコツ があるなら知りたい。ボットと議論したくない

  • o3が 転換点 だったという話に共感する
    o3やo4-miniは実質的にgpt-5級だったと言う人もいた
    だが名前が馴染みにくくて注目されず、その代わりgpt-5は 漸進的な改善 にとどまって期待外れだった
    o4-miniは会話文の言い回しがぎこちないので標準モデルには向かなかっただろうが、“gpt-5 pro” のような名前で20ドルプランに入っていたらよかったのにと思う

    • 自分も同意する。当時o3を使った人はほとんどおらず、名前も変で注目を集められなかった
      今振り返ると、あの時が メジャーリリースのタイミング だったと思う