メインコンテンツまでスキップ

「karpathy」タグの記事が1件件あります

全てのタグを見る

2025年、AI業界の6つの転換(Karpathy氏2025年まとめ)

· 約16分
Mikyan
白い柴犬

2025年、AI業界は驚くべきスピードで進化している。2024年末までAIは「質問に答えるだけの文章生成ツール」に過ぎないと思われがちだったが、いまや各業界で実際のビジネス価値を生み出す存在へと変わってきた。 なぜたった一年でここまで進化したのか。振り返ってみると、カーパシー氏は6つの転換点を挙げている。この6つの転換点は、今後10年のLLMの進化にも影響しうるほど重要と思うので、ここで簡単に紹介したい。

もともとLLMの訓練パイプラインは、事前学習 → SFT → RLHF の3段階が定番でした。ところが2025年にはRLVRが一躍“第4の主要ステージ”として存在感を増しました。

LLMの発展をざっくり振り返ると、2020年ごろの主流は事前学習(Pretraining)です。大量のテキストを学習させ、言語の基礎能力を作ります。 その後、2022年ごろからSFT(教師あり微調整)とRLHFが広く使われるようになりました。

SFT(Supervised Fine-Tuning)は一言でいうと、**「お手本を見せて、指示に従う練習をさせる段階」**です。 事前学習を終えたモデルに対して、人間が用意した「質問 → 理想的な回答」のペアを大量に学習させ、出力の品質を引き上げます。

一方RLHF(Reinforcement Learning from Human Feedback)は、人間がLLMの出力を評価し、その人間の選好に基づく報酬でモデルを最適化することで、より好ましい回答を返せるように調整する手法です。

ただし、SFTもRLHFも人間がモデルに「推論そのもの(途中の思考プロセス)」を直接教えるのは難しく、推論力を狙った形で育てにくいという課題があります。 多くの場合、人間が与えるフィードバックは最終回答の良し悪しに寄りがちで、途中の考え方まで十分に教師信号として与えられないからです。

そもそも人間にとっても、「最善の推論ルート」を明確に定義するのは簡単ではありません。たとえば数学の問題を解くとき、頭の中では省略している判断や暗黙の手順が多く、それを文章として整理してLLMに伝えるのは難しいのです。

そこで登場したのがRLVR(Reinforcement Learning from Verifiable Rewards)です。RLVRを一言でいうと、人間が評価する代わりに「自動で正誤を検証できる採点器(verifier)」を用意し、その合否を報酬信号として学習させる手法です。

たとえば「数学なら答えが一致しているか」「コードならテストに通るか」のように、外部の検証器で白黒がつくタスクを作れます。

出力を採点器にかけて、合格ならスコア(報酬)= 1

不合格ならスコア(報酬)= 0(または低スコア)

この“自動採点ループ”を回しながら、モデルに大量の試行錯誤をさせます。

以前は「人間が先生」でしたが、RLVRでは「自動採点できる世界」を先に作り、モデルに大量の練習問題を解かせます。結果としてモデルは、正解に到達するための手順(推論の組み立て方)を、外部の正誤判定に合わせて内側で洗練していきます。

さらにRLVRは、SFTのように「短い微調整で終わる」だけではなく、報酬に向けた最適化を比較的長く回せるのが特徴です。実際に2025年は、パラメータを増やすよりも、RLVRを長く回す方向に計算資源が寄っていった――という見方もあります。

またRLVRが広がると、もう1つ重要な軸が出てきます。それが**「テスト時にどれだけ考えさせるか」**です。推論(考える過程)により多くの計算を使わせるほど、正解率が上がるケースがあります。

そのためアプリ側でも、ざっくり言えば、

Thinking(短い)=速い・安いが、難問に弱い

Thinking(長い)=遅い・高いが、難問に強い

のように、性能を“考える時間”で調整しやすくなりました。

RLVR方法に基づいて、OpenAIは2024年末で推論モデル(oシリーズ)を提供し始めます。o1は初めての推論モデルで、o3は高い推論能力を持っているモデルで注目されました。

転換2、我々は動物を育てているのではなく、幽霊を召喚している

人間(動物)の脳は「生存のため」に最適化されてきました。 しかしLLMは違います。LLMが最適化される圧力は、例えば次のようなものです:

  • 人類のテキストを模倣する(次の単語を当て続ける)

  • 数学やコードで報酬を取る

  • 人間の評価(ランキング)を取る

その結果として現れる知能の形は、人間や動物と同じになりません。

2025年のLLMは、**「ある分野では天才なのに、別の分野では驚くほど脆い」という特徴が目立ちます。 能力が滑らかに均一ではなく、領域ごとに尖ったり凹んだりする――この状態を、ここでは「ギザギザ」**と呼びます。

この見方をすると、「ベンチマークで勝っているのに、なぜAGIとは言い切れないのか?」という違和感も説明しやすくなります。

ベンチマークは多くの場合、正解が定義できる=検証可能です。 するとRLVRや合成データによって、**「ベンチマーク周辺だけ能力を盛る」**ことが相対的にやりやすくなります。

Karpathyは、こうした“ベンチマーク対策”が高度化し、「テストで勝つ技術」そのものが一つの芸になっている、という冷めた見方も示しています。

転換3、CursorとLLMアプリの新しい層

2025年は「Cursor for X」という言い方が広がり、Cursorの台頭が**“LLMアプリ”という新しいレイヤー**をはっきり可視化しました。

ここで重要なのは、LLMアプリが単に「チャット画面を用意するだけ」ではなく、特定の業務(縦の領域)に向けてLLMを束ね、使える形に組み立てるところに価値がある点です。

Karpathyは、LLMアプリ(Cursorのようなプロダクト)がやっていることを大きく4つに整理しています。

  • コンテキスト設計(context engineering):何を、どう渡すかを設計する

  • 複数回呼び出しのオーケストレーション:裏で複数回LLMを回し、複雑な処理フロー(DAG)として組む(性能とコストのバランスも取る)

  • GUI(Human-in-the-loop):人間が介入・確認しやすいUIを用意する

  • 自律性スライダー(autonomy slider):どこまでAIに任せるかをユーザーが調整できるようにする

つまり「LLMを1回呼んで終わり」ではなく、業務に合わせて一連の流れとして設計・統合すること自体が価値になってきた、という話です。

Karpathyは、2025年に議論された論点として「この新しいアプリ層がどれだけ“厚く”なるか」を挙げています。

その上で、LLMラボは“汎用的に優秀な大学生”を育てる方向に進む一方、アプリ側はそれらを特定領域で稼働する“現場のプロ”に仕立てる方向に進むのではないか、と見ています。

その鍵になるのが、アプリ側が提供できる次の要素です。

  • 企業の私有データ
  • センサーや操作(アクチュエータ)=現実世界への入出力
  • フィードバックループ(使われながら改善される循環)

変化④:Claude Code「PCに住むAI」

4つ目はAnthropicの Claude Code(CC) です。Karpathyはこれを、**LLM Agentの“最初の説得力ある例”**として挙げています。チャットで助言するだけでなく、ツール利用と推論を行き来しながら、まとまった作業を最後までやり切れる感覚がある、という評価です。

CCの面白さは「クラウドで動くAI」ではなく、自分のPC上(localhost)で動くところにあります。開発者の環境やファイル、設定、履歴(そしてシークレット)と密接につながることで、AIは単なるWebサービスではなく、**PCに“住む存在”**に近づいていく――という見立てです。

この文脈でKarpathyは、OpenAIが一時期「クラウドのコンテナ上で動くエージェント(ChatGPT側のオーケストレーション)」に寄りすぎた点に、やや批判的です。能力がまだギザギザな過渡期だからこそ、現実的には開発者と並走しながらローカル環境で地に足をつけて動くほうが合理的だ、という視点になります。

さらにCCが ミニマルなCLI として提供されたことも象徴的です。AIは「Webサイトに行って使うもの」から、PCの中に常駐して必要なときに呼び出せる――いわば**“PCに住む小さな精霊”**のような存在へ。ここに新しい対話パラダイムが生まれた、というわけです。

変化⑤:Vibe coding(雰囲気でコーディング)

5つ目は、Karpathy自身が広めた言葉 「Vibe coding」 です。

2025年は、英語(自然言語)で指示するだけで、実用的なプログラムを作れるだけの能力閾値をLLMが越えた年でした。結果として、「コードを理解して手で書く」ことの比重が下がり、**“コードの存在を忘れて作る”**感覚が現実的になってきます。

このスタイルが広がると、開発はこう変わります。

  • とりあえず作る

  • すぐ捨てる

  • 目的のためだけに、短命なコードを書く(使い捨てのミニアプリ)

Karpathyは実際に、デモや小さな道具を次々に作ったり、**バグを1つ潰すためだけの“使い捨てアプリ”**を作ったりするようになった、と述べています。コードが「安く」「柔らかく」「捨てやすい」ものになった、というわけです。

これは一般の人にとっては“プログラミングの民主化”であり、プロにとっても「今までコスト的に作れなかったソフトが作れる」状態を生みます。そして仕事の定義や職能にも影響していく、と見ています。

変化⑥:Nano banana と LLMのGUI化

最後が、Google Geminiの “Nano banana” です。Karpathyはこれを、2025年の中でも特に印象的で“パラダイムシフト級”の例として挙げています。

ここで言いたいのは、単なる画像生成の性能向上だけではありません。

彼は「いまのLLMとの対話(チャット)」を、1980年代のコンソール操作になぞらえます。テキストはコンピュータには都合が良い一方で、人間にとっては読むのも書くのも遅く、疲れる。だからコンピュータ史ではGUIが生まれた――同じことがLLMでも起きる、という見立てです。

つまりLLMは、テキストだけでなく人間が得意な形式で返す方向へ進むはずだ、と。

  • 画像

  • インフォグラフィック

  • スライド

  • ホワイトボード

  • アニメーション/動画

  • Webアプリ

そしてnano bananaは、その“LLMのGUI化”の早い兆しだと言います。重要なのは、画像生成だけではなく、テキスト生成・画像生成・世界知識がモデルの中で一体になって働く点にある――という評価です。