カーパシー最新インタビュー：バイブコーディングは序章、真の重要点はエージェントエンジニアリング

アンドレイ・カルパティは、自分が生成された AI コードを修正したのがいつだったかさえも思い出せなくなっていると語った。

カルパティは OpenAI の創設に関わり、Tesla では Autopilot 視覚チームを率いた。昨年、彼の投稿によって「Vibe Coding（凭感觉编程）」という用語が誕生し、後に Collins 辞書で 2025 年の年間単語に選出された。

2026 年 4 月、カルパティは Sequoia Capital の AI Ascent 会場でパートナーのステファニー・ジャン（Stephanie Zhan）からインタビューを受けた。この 30 分間の対話では、プログラミングのパラダイムシフトに対する彼の実感、Software 3.0 の本質、AI がなぜ特定の分野では極めて強力なのに他の分野では驚くほど弱いのか、そして「Vibe Coding」の次に来るより真面目なステップとは何かについて語られた。

オリジナル動画：https://www.youtube.com/watch?v=96jN2OCOfLs

要点速览

• 2025 年 12 月はカルパティにとって個人的な転換点だった：AI の出力が「役に立つが修正が必要な状態」から「そのまま使える状態」へ変化し、彼は完全に Vibe Coding（凭感觉编程）の状態に入った。

• Software 3.0 の鍵は「自然言語でコードを書くこと」ではなく、プロンプトとコンテキストを通じて LLM（大規模言語モデル）という新しい情報処理インタープリターを操作することにある。

• MenuGen の事例により、カルパティはある AI アプリケーションが単に高速化されるのではなく、モデルのネイティブな能力によって直接吸収されてしまうことに気づいた。

• LLM の能力は極めて不均一である：10 万行のコードのリファクタリングやゼロデイ脆弱性の発見は可能だが、「50 メートル先にある洗車場へ行くのに歩くべきか車で向かうべきか」といった常識的な問いには誤答することもある。

• Vibe Coding（凭感觉编程）は、誰もがソフトウェアを作成できる下限を引き上げる。一方、Agentic Engineering（エージェント工学）は、エージェントを使用して速度を向上させる際にも、専門的なソフトウェアの品質・安全性・責任の基準を維持するものである。

• 人間はすべての API の詳細を記憶する必要はないが、システム構造や基盤となるメカニズム、品質基準を理解していなければ、エージェントを監督することはできない。

• カルパティは LLM を「幽霊」に例えた。それは動物のような知性ではなく、人間のドキュメント、事前学習された統計データ、そして強化学習の報酬によって形成された不規則な実体である。

• 知能が安価になった今、教育の重点は思考の外注化を拒絶することではなく、理解が依然として人間の脳に到達するように確保することにある。

【1】2025 年 12 月：プログラマーの降伏

ジャン氏：数ヶ月前、あなたは「これまで以上にプログラマーとしての遅れを感じている」と語った。それは興奮なのか、それとも不安なのか？

カルパティは両方あると答えた。

過去一年間、彼は Cursor などのエージェント型コーディングツールを使い続けてきた。初期のこれらのツールは有用でコードブロックを生成できたが、頻繁にエラーが発生し修正が必要だった。真の転換点は 2025 年 12 月に訪れた。その時期、ちょうど休暇中でサイドプロジェクトに取り組む時間があったため、最新モデルによって生成されたコードブロックが「そのまま使える」ようになったことを明確に実感した。

最初はモデルに少しだけ書かせてみた。結果が良かったので、さらに多くを書かせた。その後、自分がモデルの出力を直接修正するのをいつ以来か思い出せなくなり、システムへの信頼感が次第に高まっていった。最終的に、彼はその後に Vibe Coding（凭感觉编程）と呼ぶ状態へと入っていった。

**

私がそれを修正したのはいつだったかさえも覚えていない。そして、このシステムに対する信頼がますます強まってきた。**

この「Vibe Coding」という言葉は、単に「雰囲気プログラミング」と硬訳するのは適切ではありません。より正確には、「感覚に頼って AI にコードを書かせる」開発手法を指します：人間が自然言語で継続的に意図を提示し、モデルがコードを生成・修正・デバッグする一方、人間はかつてのように行ごとに書き込み、行ごとの差分（diff）を読み込む必要がなくなります。Karpathy 氏が 2025 年 2 月に X でこの用語を提唱した際、彼が描いたのは「コードそのものへの直接的な制御を手放し、感覚に任せてモデルを進めていく」という開発体験のことでした。

しかし、今回のインタビューにおいて Karpathy 氏の焦点は Vibe Coding のみにとどまりません。彼は強調します：多くの人が AI に対する印象をまだ「ChatGPT に似たもの」——つまり、質問すれば一つ答えが返ってくるようなもの——に留めていると。2025 年末以降、改めて注目すべきは「Agentic coherent workflow（エージェントによる整合的なワークフロー）」です。これはより一貫性のあるエージェントの作業流であり、モデルは単に回答するだけでなく、連続した計画立案、コード記述、デバッグ、実行を行い、環境からのフィードバックに基づいてさらに修正を加えることができます。

**

多くの人が昨年体験した AI はまだ「ChatGPT に似たもの」でした。しかし、あなたは本当に 12 月以降のバージョンをもう一度見る必要があるのです。**

かつてプログラマーの速度は、いかに多くのコードを書けるか、どれだけ多くの API を記憶できるか、どのようにデバッグするかによって決まっていました。現在では、その速度はもはや、強力だが誤りを犯しうるエージェント群を正しく指揮できるかどうかにかかってきています。

【2】Software 3.0：エージェントにテキストをコピー＆ペーストするだけで、それがプログラミングとなる

Zhan 氏からの質問：あなたは LLM（大規模言語モデル）を単なる改良されたソフトウェアではなく「新しいコンピュータ」とおっしゃいました。もしあるチームがこれを本当に信じるなら、そのチームは製品をどのように異なって構築することになるのでしょうか？

Karpathy 氏は自らが提唱するソフトウェアの分期から話を始めます。

Software 1.0 は従来のソフトウェアです：人間が明示的なコードを書き、コンピュータがルールに従って実行します。

Software 2.0 はニューラルネットワーク時代です：人間はもはやすべてのルールを直接書くのではなく、データセット・目的関数・ニューラルネットワークのアーキテクチャを設計し、訓練を通じてモデルの重みを得ます。Karpathy 氏はすでに 2017 年に『Software 2.0』という論文で、ニューラルネットワークを新たなソフトウェア開発手法として位置づけました。

そして Software 3.0 は大規模言語モデル（LLM）時代です。LLM は大規模なタスク訓練を経て、プログラミング可能なコンピュータへと進化します。もはやコードエディタ内で関数を書くだけでなく、プロンプト・コンテキストウィンドウ（context window：モデルが一度の呼び出しで参照できる情報の総体）、ファイル、ツール呼び出し、そして外部環境の間で、モデルに実行させる「文脈プログラム」を構成するようになります。

コンテキストウィンドウとは、モデルが一度の呼び出しにおいて視認可能な全情報を指します：指示・履歴対話・ファイル・エラーログ・コードスニペット・画像・ツールの返却結果などです。Karpathy 氏によれば、この文脈ウィンドウこそが、人間が LLM のインタプリタを操作するための「ハンドル」となります。

彼は OpenCL のインストール例を挙げました。従来の做法では、あらゆるマシン・プラットフォーム・環境に適応させるシェルスクリプト（shell script）を書く必要があります。対象となる環境が増えるにつれてスクリプトは膨張し、最後には維持が極めて困難になります。しかし Software 3.0 では、インストール手順そのものがエージェントにコピー＆ペーストできるテキストとなり得ます。エージェントはあなたのマシン環境を読み取り、手順を実行し、エラーが発生すればデバッグを行います。

**

現在問われているのは：どのテキストをエージェントにコピー＆ペーストすべきか？これが新たなプログラミングのパラダイムです。**

この文の核心は「プログラマーは今後はプロンプトを書くだけでよい」ということではありません。Karpathy 氏が伝えたいのは、プログラムの境界が拡大したという点です。かつてのプログラムはコードファイルでした。現在では、プログラムは説明テキスト・一つのコンテキストウィンドウ・一組のツール権限・テスト環境、そしてモデル内部に既に学習された膨大な統計構造を合わせたものとなり得ます。

【3】MenuGen：このアプリは存在すべきではない

Karpathy は続いて自身の MenuGen について語り始めました。

このアプリのアイデアは非常にシンプルです。人がレストランでメニューを受け取る際、通常は料理の写真が掲載されていません。多くの料理名、特に見慣れない料理体系のものは、文字だけを見てもそれが何なのか分かりません。Karpathy はそのような課題を解決するアプリを作ろうと考えました：メニューの写真を一撮りし、アプリがメニュー上の料理名を認識した上で、各料理に対しておおよその画像を生成し、最後にメニューを再レンダリングしてユーザーに「これらの料理はおそらくこんな見た目だ」というイメージを見せるというものです。

従来のパラダイムでこのアプリを作る場合、複数の中間ステップが必要になります：写真のアップロード、OCR による文字認識、料理名の抽出、画像生成器への呼び出しによる料理画像の生成、そして結果の再レイアウトと Vercel 上へのデプロイです。Karpathy は Vibe Coding（雰囲気コーディング）を用いてこのアプリを構築しました。

その後、彼は Software 3.0 のバージョンを目にします。

アプローチはこう変わりました：メニュー写真をそのまま Gemini に渡し、「Nano Banana にこれらの料理画像をメニュー上に重ねてほしい」と指示するだけです。Nano Banana が返すのは構造化データでも一連のコンポーネントでもなく、新しい一枚の画像です：元のメニューはそのまま残っており、対応する料理の位置がすでに画像内に直接レンダリングされています。

【注：Nano Banana は Google Gemini の画像生成および編集機能の名前であり、テキスト、画像、またはその両方を用いた対話型の生成と編集をサポートしています。】

Karpathy 氏は、自分が以前書いた MenuGen は不要だったと考えています。なぜならそれはまだ旧来のパラダイムに留まっているからです。

私の作った MenuGen はすべて無駄でした。まだ旧来のパラダイムに縛られています。あのアプリは存在すべきではありません。

この例は、今回のインタビュー全体を通じて最も重要なビジネス判断の一つです。

多くの AI アプリケーション企業が、自分たちは「より高速なソフトウェア」を作っていると思い込んでいます。例えば、過去には 10 のステップを要していたタスクが、現在はアプリによって 3 つのステップに圧縮されるようなケースです。しかし Software 3.0 では、モデル自体の入出力がこのタスクを直接カバーしてしまい、中間にあるアプリの構造はもはや不要になります。

Karpathy はさらに、この変化はコードの中だけではないと指摘します。従来のコードは構造化データ（テーブル、配列、データベースフィールド、明確なルール）の処理に優れています。しかし LLM（大規模言語モデル）は、より一般的な情報の再編成を扱うことができます。例えば彼の LLM Knowledge Bases（LLM 知識ベース）プロジェクトでは、記事やドキュメント、事実を個人や組織向けのウィキとして再構成します。これは従来のプログラムが本来得意とするところではありません。なぜなら、テキスト間の関係性を理解し、情報を再順序付けし、新しい知識構造を生成することが求められるからです。

より興奮するのは、既存のものをより速くすることではなく、以前は決して存在し得なかったようなものを作り出すことです。

【4】ニューラルコンピュータ：CPU がコプロセッサへ変貌する

Zhan 氏からの質問：この進展を 2026 年まで外挿した場合、今日ではまだ多くの人々が構築していないが、振り返れば当然のことだったと認識されるものは何でしょうか？

Karpathy は、より大胆かつ不確実性の高い構想を提示しました。それは将来、完全な「ニューラルコンピュータ」が登場する可能性です。

今日のコンピュータはまだ CPU、オペレーティングシステム、従来のプログラムを中心に動いています。ニューラルネットワークは既存のコンピュータ上で動作し、仮想化された能力モジュールのようなものです。しかし Karpathy は、未来には逆転する可能性があると想定しています：ニューラルネットワークが host process（主プロセス）となり、CPU、従来のコード、ツール呼び出しが協働プロセッサとして、決定論的なタスクを担当するという形です。

彼が提示した想像のシナリオとは、デバイスが生のビデオまたはオーディオを受け取り、ニューラルネットワークが現在のシーンを理解し、拡散モデル（diffusion model）を用いてその瞬間に固有の UI を生成する、というものです。ユーザーが見るインターフェースはもはや固定されたコンポーネントを組み合わせたものではなく、モデルが文脈に応じてリアルタイムで生成するものになります。

彼はまた、この判断に対してすぐに制限を設けました：このような外挿（推論）は奇妙に思えるかもしれませんが、具体的な道筋はまだ TBD（未定）であり、一夜にして起こるのではなく、断片的に訪れることになるでしょう。

「ニューラルネットワークが主プロセスとなる」というのは、すでに実現した製品的事実というよりは、方向性を説明するためのメンタルモデルに近いものです。

【5】LLM は 10 万行のコードをリファクタリングできるのに、あなたに徒歩で洗車に行かせようとする

Zhan 氏への質問：もし AI が検証可能な領域での自動化がより容易になるなら、どのような仕事が人々の予想よりも早く変化しますか？また、安全に見える職業の中で、実際には高度に検証可能なものは何ですか？

Karpathy は直接職業を列挙するのではなく、「検証可能性」について説明することに焦点を移しました。

彼の核心的な判断は以下の通りです：

**

従来のコンピュータでは、コードとして記述できるものを自動化しやすい；今世代の LLM（大規模言語モデル）では、検証可能なものを自動化しやすい。**

従来のソフトウェア自動化の前提は、人間がルールを正確に記述できることです。例えば税率計算、ソート処理、データベースクエリ、注文ステータスのフローなどです。ルールが明確であればコードを書くことができます。

LLM の自動化の境界線は異なります。必ずしもすべてのルールを記述する必要はありませんが、出力の良し悪しを判断する何らかの方法が必要です。数学の問題なら答えを検証できます。コードならテストを実行します。特定のセキュリティ問題なら脆弱性の再現によって判断できます。このようなタスクは強化学習（RL：Reinforcement Learning）環境に組み込むことができます：モデルが問題を試行錯誤し、システムが報酬またはペナルティを与え、モデルは大量のサンプルを通じて行動を最適化します。

したがって、モデルが数学、コード、および隣接分野での能力を急速に向上させているのは、「モデル全体がより賢くなったから」というだけでなく、Karpathy によればこれは最先端研究所におけるモデルの訓練方法にも起因しています。研究所は大量の検証可能なタスクを構築し、それらを訓練プロセスと強化学習フローに組み込みました。その結果、モデルはこれらの分野で卓越した能力を発揮するようになりました。

これが LLM の「ジグザグ型知能（jagged intelligence）」と呼ばれる現象の説明にもなります：能力曲線は滑らかに上昇するのではなく、ピークと断崖が存在します。あるタスクでは驚くほど強力ですが、別のタスクでは荒唐無稽に弱いのです。

Karpathy は、現在のより適切な例として「洗車問題」を挙げました。「50 メートル先の洗車場で車を洗うために、車で移動すべきか、それとも歩くべきか？」という問いに対し、最先端のモデルは「近いので歩いたほうがよい」と答えるかもしれません。この回答は問題の本質を見落としています：洗うのは車であり、車は洗車場まで到達する必要があるのです。

**

最先端のモデルは 10 万行のコードをリファクタリングし、ゼロデイバグ（未公開または未修正のセキュリティ脆弱性）を発見できるのに、50 メートル先の車を洗うために歩くべきだと告げます。**

【注：ゼロデイバグとは、まだ公にされていないか、あるいはパッチが適用されていないセキュリティ上の脆弱性を指します。】

もしタスクがモデルの訓練と強化学習でカバーされた能力ループ内にあるなら、それは専門家のように振る舞う可能性があります。しかしデータ分布の外側にある場合、人間には簡単に見えるタスクであっても、エラーを犯すことがあります。

これは利用者にとって高い要求を課します。 モデルがコード処理において強力だからといって、すべてのエンジニアリング判断においても同様に優れていると仮定してはいけません。また、洗車問題のようなミスを犯したからといって、モデル全体が無効であると断定してはいけません。より正確なアプローチは、モデルの能力境界を探り、「能力ピーク」にあるタスクと「断崖」のそばにあるタスクを区別することです。

【6】能力は自然進化ではなく、実験室のデータ決定に依存する

Karpathy は一つの詳細な点を指摘しました。GPT-3.5 から GPT-4 へと移行する際、チェスにおける能力が劇的に向上したという事実です。多くの人々はこれを能力の自然な進化だと考えていますが、実際には OpenAI の誰かが、事前学習に大量のチェスデータを組み込むことを決定した結果なのです。データが分布に含まれることで、能力もそれに伴って向上します。

これは一見「モデルが強くなった」という物語を、「実験室が製品上の意思決定を行った」という物語へと再解釈するものです。

**

ある意味で、私たちは完全に、実験室がモデルにどのようなデータを供給したかに依存しています。もしあなたのユースケースが RL（強化学習）訓練によってカバーされる「能力のループ」内にあれば、モデルはあなたを飛躍させますが、そのデータ分布から外れてしまえば、モデルは極めて困難を感じることになります。**

実務的な示唆： あなたの適用シーンがカバーされた能力のループ内にあるなら、そのまま利用可能です。もし外側にあるなら、自分でファインチューニングを行う必要があり、LLM（大規模言語モデル）が最初からできることを期待してはいけません。

【7】起業の機会：RL でまだカバーされていない検証可能な領域を見つける

Zhan 氏からの質問： もし起業家が今日、解決すべき検証可能な問題に取り組もうとしているが、大規模モデルの実験室がすでに数学やコードといった最も明白な分野で加速している場合、起業家はどうすべきでしょうか？**

Karpathy の回答は具体的な競技種目を提示したわけではありませんが、機会を見つけるための一種の手法を示しました。

現在の技術パラダイムにおいて、「検証可能性」こそが問題を「解決可能」なものにします。 もしあなたが大量かつ多様な強化学習環境を構築し、モデルが試行錯誤して報酬を得られるようにできれば、大規模な実験室がこの分野を重点課題としていない場合でも、独自のファインチューニングと訓練を通じて優位性を築くことが可能です。

彼はここで、自分にとって非常に価値のある分野だと考えているものを挙げようとしたかのように見せましたが、そこで止まりました。

**

直接答えを出すつもりはありません……すみません、舞台上で曖昧な発言をしようとしていたわけではありません。

客席から笑いが起こりました。

この一瞬の停止自体が、彼の判断を示しています。機会とは「AI エージェントをもう一つ作る」といった漠然とした方向性ではなく、報酬環境を具体的に構築できる問題を見つけることにあります。

彼はさらに過激な一言も補足しました。「ほぼすべてのことは、最終的にはある程度において検証可能になる可能性がある」というのです。執筆やデザインといった一見主観的なタスクでさえ、LLM judges（モデル審査員）と呼ばれる一群のモデル評議会を想定し、何らかの近似評価を形成することができると言います。

この言葉は慎重に理解する必要があります。Karpathy はすべてのタスクが完璧に自動検証可能になると言っているわけではありません。彼が言いたいのは「程度」と「難易度」の問題です。数学やコードは答えやテストケースが比較的明確であるため比較的手軽ですが、執筆、審美性、戦略的判断などははるかに困難を伴います。

【8】Vibe Coding は下限を引き上げ、Agentic Engineering が上限を守る

Zhan 氏からの質問：昨年はあなたが Vibe Coding を提唱しました。今日私たちはより真面目な世界、つまり Agent engineering（エージェント工学）の世界に入りました。この二者の違いは何でしょうか？**

Karpathy の区別は非常に明確です。

Vibe Coding は下限を引き上げます。より多くの人々が自然言語と AI を用いてソフトウェアを作成できるようになります。コードを書けない人でも小規模なツールを作れるようになり、コードが書ける人もサイドプロジェクトをより迅速に作成できます。ソフトウェア創造の入口が広がったのです。

Agentic Engineering は上限を守ります。これは専門的なソフトウェアを対象としています。AI を使用したからといってセキュリティ上の脆弱性が導入されてはなりませんし、モデルによる高速な記述だからといって品質基準を下げてはなりません。また、コードがエージェントによって生成されたからといって責任所在が不明確になってはなりません。

Vibe Coding は誰もがソフトウェアを作成できる下限を引き上げるものであり、Agentic Engineering は専門的なソフトウェアが過去に持っていた品質基準を守り抜くものです。

Agentic Engineering は「インテリジェント・エージェンシー（智能体）エンジニアリング」と訳されます。これは特定のツールを指すものではなく、一種の工程規範です。AI エージェントのグループを設計し、調整し、監督する方法であり、品質や安全性、保守性を犠牲にすることなく開発を加速させるためのものです。

Karpathy 氏は、これらのエージェントは「スパイク・エンティティ（尖った実体）」であると述べています。彼らは能力が高い一方で、誤りを犯す可能性があり、ランダム性を持ち、不安定です。エンジニアの役割は盲目的に信頼することではなく、これらを適切なプロセスの中に組み込むことです。つまり、エージェントに案の作成やコード記述、テスト実行、相互チェックを行わせ、システムに境界線と検証機能、そしてロールバック機能を設けるのです。

Karpathy 氏はさらに、より強力な判断を示唆しています。過去のソフトウェア業界は「10x エンジニア」、つまり一般の人々よりもはるかに効率的なエンジニアを好んで称賛してきました。しかし、Agentic Engineering の文脈において、彼が目撃する加速の規模は単なる 10 倍をはるかに超える可能性があります。

10 倍という数字が得られる加速率ではありません。

真に熟練した人間は、複数のエージェント、ツール、テスト、そしてコンテキストを組織的に統合し、その生産速度はさらに劇的に増幅されます。

【9】AI ネイティブなエンジニア：問題集を解けることではなく、大規模プロジェクトを安全に完遂できること

Zhan 氏への質問：AI コーディングツールを使用する二人の人物、一人は普通で、もう一人が真に AI ネイティブだとしたら、その違いは何でしょうか？

Karpathy 氏はまず、AI ネイティブなエンジニアは利用可能なツールを最大限に活用し、自身のワークフロー設定に投資すると述べます。かつてのエンジニアたちが Vim、VS Code、コマンドライン、ショートカットキー、開発環境の設定に時間を費やしたように、現在も Cursor や Claude Code、あるいは同様のツールの設定に時間をかけ、それらが自分たちの作業スタイルに最適化されるように努めるべきです。

しかし、彼はすぐに話題を採用面接へと転じます。

多くの企業がまだ面接プロセスの再構築を行っていないと彼は考えます。もし依然として候補者に一連の小規模なパズルを与え、現場でアルゴリズム問題を解かせるのであれば、それは旧来のパラダイムです。これでは、Agentic Engineering の文脈において効率的に働けるかどうかを測定することはできません。

より良いテストは、大規模プロジェクトに基づくべきです。例えば、候補者に Twitter のクローンを作成させるのです。単に動作するだけでなく、高品質で安全である必要があります。その後、複数のエージェントを用いてそのサイトを攻撃し、破壊を試みて、システムが耐えうるかどうかを確認します。

**面接とは本来こうあるべきです：候補者に極めて大規模なプロジェクトを投げつけます。例えば、エージェント向けに Twitter のクローンを作成させ、絶対的な安全性を要求します。そして、私は 10 個の Cursor を「レッドチーム」として配置し、作成したサイトに対して容赦なく攻撃を試みます。

この評価方式の核心は、候補者が特定のアルゴリズムを手書きできるかどうかを見ることではなく、彼らが以下ができるかを見ることです：**

曖昧な目標を明確な仕様に変換すること；エージェントを指揮して大規模な実装を完了させること；セキュリティとアーキテクチャ上のリスクを特定すること；テストと検証を設定すること；モデルが生成した膨大なコードの中で品質判断を保ち続けること；最終システムが外部からの攻撃や負荷に耐えうるようにすること。

【10】Agent はコードを記述できるが、支払い先メールアドレスを誤って設定してしまう可能性もある

Zhan 氏への質問：Agent が行う作業が増えるほど、どのような人間のスキルがより価値を持つようになるのでしょうか？

Karpathy の答えは、「センス（品味）」、「判断力」、「審美眼」、「監督」、そして「仕様設計」です。

彼は現在の Agent をインターン生に例えています。この比喩は的確ですが、過度に人間化してはいけません。Agent は実際に人間の動機を持つ従業員ではなく、実行能力が次第に向上する一方で、人間にとっては自明な箇所でミスを犯す存在です。

Karpathy は MenuGen における実際の課題を挙げました。ユーザーは Google アカウントでログインしますが、クレジット購入時には Stripe アカウントを使用します。Google と Stripe の両方にメールアドレスが紐付いています。Agent が購入ロジックを実装する際、Stripe のメールアドレスを使って Google のメールアドレスと照合し、購入したクレジットを該当のユーザーに割り当てようとしました。

これは一見すると理にかなっているように思えますが、エンジニアリングの観点からは危険です。ある一人のユーザーが、Google へのログインには一つのメールアドレスを使い、支払いには別のメールアドレスを使うことは十分にあり得ます。もしシステムがメールアドレスを通じて資金を紐付けるのであれば、購入記録がどのユーザーのものか特定できなくなったり、資金の誤配分が発生したり、アカウントが混乱したりするリスクがあります。正しいアプローチは、システムの内部で安定した永続的なユーザー ID を使用して、ユーザーの身元と支払い記録を結びつけることです。

なぜメールアドレスを使って資金を相互に関連付けようとするのですか？それらは任意のものでよく、異なるメールアドレスを使用することも可能です。このやり方はあまりに奇妙です。

このような問題には文法エラーはなく、コードも実行可能で、テストも通過するかもしれませんが、システム設計そのものが誤っています。Agent は、身元（アイデンティティ）、支払い、資金の帰属に関するリスクを真に理解していません。

そのため Karpathy は、仕様（spec）については人間が責任を負わなければならないと言います。あなたは Agent にこう指示する必要があります。「すべての資金とユーザーの状態は、外部のメールアドレスではなく、内部の一意なユーザー ID に紐付けるべきだ」と。あなたはトップレベルの設計、制約条件、判断基準を担う必要があります。Agent は実装の詳細を埋めることはできますが、システムの境界を理解する代わりにはなりません。

彼はさらに技術的な例も挙げました。現在、彼は PyTorch、NumPy、pandas 間の細かな API の違い（例えば keepdims と keepdim、dim と axis、reshape、permute、transpose の書き方の違いなど）をすべて記憶する必要はなくなりました。これらの詳細はモデルの記憶能力が優れているため、Agent に任せることができます。

しかし彼は依然として、人間が基礎的な概念を理解している必要があると強調します。例えば、テンソル（tensor）とは何か、view と storage の関係はどういったものか、いつ単に同一メモリ領域のビューを変更するだけで済むのか、いつデータをコピーするのかといった点です。これらの基礎メカニズムを知らなければ、モデルが非効率なコードや誤ったコードを書いてしまう可能性があります。

これは「何を学ぶべきか」について非常に具体的な答えを提供します：細部は外部委託可能だが、理解は外部委託できない。 API 名を忘れることはあっても、概念構造を失ってはなりません。

【11】モデルが記述したコードは動作するが、時として「醜い」

Zhan 氏の追及：センス（taste）と判断力（judgment）は、モデルの進化に伴って次第に重要でなくなるのでしょうか？

カルパシーは断定的な発言を避けています。彼はモデルの進化を期待しており、品味や審美性、簡潔性の向上を根本的に阻む要因はないと考えていますが、少なくとも現時点ではこれらの能力が十分に訓練されていないと指摘しています。おそらく、それらが十分な質の強化学習（RL）による報酬環境に組み込まれていないためでしょう。

彼がモデルによって生成されたコードを見る際、時折「心臓を掴まれるような感覚」を覚えます。コードは動作しますが、必ずしも良いものではありません。非常に冗長で、コピー＆ペーストが多く、不自然な抽象化があり、構造が脆弱で保守が困難です。

**

時々、彼が書いたコードを見ると、心臓を掴まれるような感じがします。動くのですが、本当に気持ち悪いです。**

また、MicroGPT プロジェクトについても言及しました。彼は LLM 学習（LLM training）を究極まで簡素化し、トレーニングプロセスを可能な限り小さく、明確で理解しやすいものにしたいと考えています。彼がモデルに「さらに簡略化して」と求め続ける一方で、モデルはそれに応えることができません。その感覚は「歯を抜かれる」ほど困難です。

**

私は LLM に「さらに簡略化して」と繰り返し求めますが、それはできません。自分が強化学習（RL）のループの外にいるのがわかります。まるで歯を抜いているようです。**

カルパシーの説明によれば、このタスクはモデルが強化学習によってカバーされた能力の範囲を超えている可能性があります。モデルは一般的なエンジニアリングのパターン生成には長けていますが、極限まで簡素化し、抑制され、優雅な抽象的な圧縮を行うことには不得意です。

【12】私たちは動物を作っているのではない：カルパシーは「幽霊」を召喚していると言う

ザン氏への質問：あなたは「動物対幽霊」に関する記事を書かれましたが、核心となる意味は「私たちは動物を作っているのではなく、幽霊を召喚している」という点です。この枠組みがなぜ重要なのでしょうか？

カルパシーは、彼自身がこれらのモデルが何者なのかを理解しようとしているからこそ、この記事を執筆したのだと述べました。モデルとは何かについてより良いメンタルモデルを持っていれば、それをより巧みに扱えるようになります。

「幽霊」という言葉は神秘的に聞こえますが、カルパシーの意図は神秘主義的なものではありません。彼は2つの知能の源泉を対比させています。

動物の知能は進化、身体性、環境との相互作用、内的動機、好奇心、楽しさ、継続学習から生まれます。動物は世界の中で行動し、結果によって形成され、生命過程を通じて絶えず適応していきます。

LLM はそうではありません。今日のアプローチにある最先端の LLM は、まず大規模な事前トレーニングに基づいています：モデルは膨大な量の人間によるドキュメント上で統計的構造を学習します。その後、強化学習や嗜好データ、ツール呼び出しなどの後処理プロセスが重ねられます。それらは動物のような知能ではなく、人間のドキュメント、統計パターン、報酬関数によって形成されたシミュレーションされた実体です。

インタビューの中で、彼はこの比喩を実用的な原則に落とし込みました：LLM を動物として扱わないでください。 大声で怒鳴っても、恐怖心からより一生懸命働くようにはなりません。励ましても、内的動機を刺激するわけではありません。モデルは動物のような感情を持っていません。その行動は統計的シミュレーション、文脈、ツール、トレーニングデータ、報酬メカニズムに由来します。

**

大声で怒鳴っても、それがより良くも悪くも働くわけではなく、何の影響もありません。**

カルパシーはまた、「幽霊」という枠組みには哲学的な側面があることを認めています。彼はこの枠組みが直接的に5つのシステム最適化の提案を生み出すとは言っていません。それは誤用を防ぐための提醒のようなものです。「AI は賢いのか」と漠然と問うのではなく、どのトレーニング分布において強いか、どのような報酬信号によって形成されたか、どのタスクで急激な性能低下（ジグザグ状の断崖）が起きうるかを問うべきです。

【13】エージェントファースト基盤：一言で MenuGen を構築・デプロイする

ザン氏への質問：エージェントが単なるチャットを超え、権限を持ち、ローカルな文脈を理解し、人間に代わって行動できるようになった時、世界はどのように変わるのでしょうか？

Karpathy は、ほぼすべてを再構築する必要があると言います。現在のツール、ドキュメント、サービス、セットアッププロセスは、依然として主に人間のために設計されています。

例えば、あるフレームワークのドキュメントでは、「特定の URL にアクセスし、設定をクリックし、キーをコピーし、メニューを開き、DNS を設定する」といった手順が示されます。Karpathy の反応は「なぜまだ私にやり方を教えるのか？私はそんなことをしたくない。私が知りたいのは、Agent にコピーして任せることができるコードの断片だ」です。

**

なぜまだ誰かが私に何をすべきかを教えてくるのか？私は何もしたくない。「Agent にコピー＆ペーストで渡すものは何か？」**

これは怠惰ではなく、パラダイムシフトです。Agent-first infrastructure（エージェントファースト基盤）の目標は、世界を Agent が理解できる入力と、Agent が安全に呼び出せるアクションインターフェースに分解することです。

ソフトウェアインフラストラクチャにおいては、ドキュメント、API、権限、ログ、デプロイ、設定、請求書、ロールバックなどが、すべて Agent にとって使いやすくする必要があります。Agent に人間がウェブページを操作するのを模倣させるのではなく、Agent が直接状態を理解し、アクションを呼び出し、フィードバックを受け取るようにします。

Karpathy は再び MenuGen の話に戻ります。彼は、MenuGen を作る上で最も面倒な部分はコードを書くことではなく、デプロイにあると言います：Vercel 上へのデプロイ、各種サービスの接続、異なる設定ページへのアクセス、DNS の設定、そしてすべての要素を連携させることです。

彼が将来目指すテスト基準は、「Build MenuGen」という LLM への指示に対して、コードを書くだけでなく、デプロイを完了し、インターネット上に公開し、依存サービスを適切に設定し、人間が個々のメニューをクリックして操作する必要なく、一連のプロセスを完遂できることです。

さらに先を見据えると、彼は個人や組織それぞれが独自の「Agent representation（エージェント表現）」を持つようになる未来を想定しています。将来は、会議の調整や細部の処理、事項の連携などが、「私の Agent とあなたの Agent が話し合う」形になるかもしれません。

【14】インテリジェンスが安価になった後、最も高価なのは理解である

Zhan は最後に尋ねました。「インテリジェンスが安価になった今、何を深く学ぶ価値があるのでしょうか？」

Karpathy はある言葉を引用しました。

**

思考はアウトソーシングできるが、理解をアウトソーシングすることはできない。**

この言葉は励志的な格言として書き換えられがちですが、Karpathy の説明は非常に具体的です。

彼は依然としてシステムの一部であり、情報は彼の頭脳に入らなければなりません。彼は自分がボトルネックになりつつあると感じています：何を作っているのか、なぜそれをする価値があるのか、そしてどのように自分の Agent を指導するのかを知る必要があります。思考のステップはモデルが何度も実行できますが、人間が理解していなければ、どのルートが正しいかを判断できず、良質な仕様書を書くこともできず、Agent がアイデンティティバインディング、システム構造、コード品質において犯したエラーを発見することもできません。

**

私は自分がボトルネックになりつつあると感じています：私たちは何を作っているのか、なぜそれをする価値があるのか、そしてどのように私の Agent を指導するのかを知る必要があります。**

これが彼が LLM の知識ベースに興味を持つ理由でもあります。彼は記事や資料、事実を wiki として再投影することを好みます。異なる情報組織化の方法が、彼に洞察をもたらすからです。彼にとってこれは AI に理解を代替させることではなく、AI で理解を強化することです。

この点は先ほどのエンジニアリングの例と結びついています：

• Agent は API の詳細を記憶できますが、人間はテンソル、ビュー、ストレージ、メモリ効率を理解する必要があります；
• Agent は支払いロジックを書くことができますが、人間はユーザーのアイデンティティと資金の帰属を理解する必要があります；
• Agent は大量のコードを生成できますが、人間は抽象化が肥大していないか、構造が脆弱ではないかを判断する必要があります；
• Agent は多くの解決策について考えるのを手伝えますが、人間はその目標が達成する価値があるかどうかを知る必要があります。

したがって、知能が安価になった後でも、学習が不要になるわけではありません。むしろ、学習の重心が変わるのです。機械的な記憶や低レベルの実行に費やす時間は減り、システム理解、問題定義、品質判断、因果関係、そして分野ごとの直感に時間を割くようになります。

Q&A 速覧

問：2025 年 12 月には何が起きたのでしょうか？

答：最新モデルが生成したコードは修正不要となり、継続的なプロジェクトにおいても信頼性が維持されています。

問：Software 3.0（ソフトウェア 3.0）と従来との違いは何ですか？

答：従来のコードは構造化データを処理するものでしたが、現在はあらゆる情報を処理できるようになりました。以前は不可能だったことが可能になったのです。これは単なる加速ではなく、新たな可能性の出現です。

問：なぜ最先端の AI モデルは単純なタスクで初歩的なミスを犯すのでしょうか？

答：能力の分布は、強化学習（RL）トレーニングがカバーする領域と、実験室でのデータ選択に依存します。検証可能な分野における能力は急激に向上していますが、それ以外の分野では依然として弱い可能性があります。

問：Vibe Coding と Agentic Engineering の違いは何ですか？

答：Vibe Coding はすべての人の基礎水準を高めるものであり、Agentic Engineering は専門的な基準を維持した上でエージェントを活用して加速を図るものです。

問：いつになったら人間の品味や判断が不要になるのでしょうか？

答：その可能性はありますが、前提として実験室が審美性への報酬を強化学習（RL）のトレーニング目標に組み込む必要があります。現状では、エージェントが生成するコードは「動作はするが、見た目が悪い」ことがよくあります。

【結び】**

今回のインタビューで、Karpathy の判断にはいくつか注目すべき緊張関係があります。

第一に、彼は Agent が生成したコードの醜さに心臓発作を起こすほど驚きつつも、自分自身は修正を止めたと言っています。「信頼は品味の問題を解決しない」——動作するコードと良質なコードは別物です。しかし、「醜いものを使いつつも使い続ける」というこの状態こそが、あらゆる過剰な期待（hype）よりも、真の Vibe Coding の現状に近いのかもしれません。

第二に、彼は「過小評価されている強化学習（RL）の機会」がある領域を暗示しつつも、それを公にはしません。ステージ上で曖昧な投稿をするのを避ける人物が自ら回避する行為自体がシグナルです：その窓はまだ閉じられていません。注目すべきは、彼の会社 Eureka Labs が AI 教育に取り組んでいる点です。教育とはまさに、出力を評価でき、標準化された試験で測定可能な分野なのです。

第三に、彼は「動物対幽霊」という枠組みの格下げを行い、「思考はアウトソースできるが、理解はアウトソースできない」という言葉で対談全体を収束させました。これら二つを合わせて読むと、彼の判断は真に希少なのは特定のスキルそのものではなく、「私たちが何をすべきか、なぜそれを行う価値があるのか」を判断する能力であるということです。「ほぼすべての分野が最終的に検証可能になる」という判断が正しければ、ボトルネックは実行側ではなく、目標設定側にあります。

しかし、ここには暗黙の「時間の疑問符」が存在します。Karpathy 自身も認めているように、品味や判断が一時的に代替不可能な理由は単に「実験室がまだ行っていないから」です。この判断が正しければ、人類が代替不可能であるのは人間がユニークだからではなく、トレーニング手法がまだ整っていないからです。これは、「思考はアウトソースできるが理解はできない」という命題の有効期限に疑問符を投げかけることになります。

今後 6〜12 ヶ月で注目すべき具体的なシグナルは以下の 3 つです：

• 最先端の実験室がプログラミングや数学以外のどの分野に強化学習（RL）データを注入するか——そこで能力が突然現れるでしょう
• エージェントファーストのインフラストラクチャ（デプロイ、認証、決済）で最初の収束が見られるか——MenuGen のデプロイにおける苦痛が続く限り、「自動化社会」への道は遥かに遠くなります
• モデルの次期アップデートに、審美性やコード品質に関する強化学習（RL）目標が含まれるかどうか

原始视频：https://www.youtube.com/watch?v=96jN2OCOfLs

必至 JSON 形式で返してください。translation フィールドのみ。他のフィールド (technical_terms 等) は一切追加しないこと — 余計なフィールドを書こうとして本文翻訳がトークン上限で打ち切られる事故を防ぐため:

{"translation": "翻訳全文"}