Karpathyは、プログラマーとして「取り残されている」と感じたことはかつてないと語った。
この言葉を他の誰かや私が口にしても普通だろうが……Karpathyが言うとなれば、その重みは格段に違う。
KarpathyはOpenAIの共同創業者であり、Tesla AIの責任者、現在はEureka Labsの創業者だ。ディープラーニング時代全体において最も影響力のある技術伝道師の一人である。造語が好きで、やや「インフルエンサー」的な側面もあるが、実力で名を上げた人物であり、そこに一片の曇りもない。
先週、彼はSequoia Capitalの「AI Ascent 2026」カンファレンスに登壇し、SequoiaのパートナーであるStephanie Zhan氏と30分間の炉辺対談を行った。
テーマはこうだ：ソフトウェアは三度目のパラダイムシフトを迎えている。
Stephanie Zhan氏はイベント終了後、次のような要約を投稿した。
「 昨年、彼は『バイブコーディング』という言葉を作った。今年、彼は『プログラマーとして取り残されていると感じたことはかつてない』と述べた。」
彼女はまた、一つの文章で対談全体の核心を要約した。
「 バイブコーディングが底上げするのは床（フロア）だ。エージェンティック・エンジニアリングが引き上げるのは天井（シーリング）だ。一つはアクセスに関するもので、より多くの人々が構築に参加できるようになる。もう一つは卓越性に関するもので、エージェントを使いながらも安全性、信頼性、保守性、そしてセンスを犠牲にしない。」
一方、Karpathy自身もイベント後に長文を投稿し、3つのテーマをまとめている。
中でも最も重要なのは、LLMの「ニューフロンティア」に関する一節だ。
01「 LLMは単に既存のワークフロー（コードを書くことなど）を加速させるだけのものではない。ある種のアプリケーションは、LLMによって完全に飲み込まれ、従来のコードを必要としなくなる。インストールスクリプトを.shスクリプトの代わりに英語の.mdファイルで代用できる。なぜなら『LLMは高級な英文インタープリタ』だからだ。LLM知識ベースのように、以前は非構造化データに対する計算が必要だったために決して実現できなかったものもある。」
ソフトウェア 1.0
ソフトウェア3.0とは何かを理解する前に、まず1.0と2.0を振り返ってみよう。
ソフトウェア 1.0は、我々に馴染み深い従来型のプログラミングだ。
プログラマーはPython、C++、Javaでコードを書き、すべての行が明確な命令だ。もしAならBを実行し、さもなくばCを実行する。ロジックは人間が書き、バグも人間が作り出す。
1950年代から現在に至るまで、大多数のソフトウェアがこのカテゴリーに属する。
このパラダイムはソフトウェア工学を半世紀以上にわたって支配してきた。
その利点は明らかで、決定論的であり、デバッグ可能で、説明可能であることだ。しかし、それには根本的な限界もある。拡張性が人間の知能と時間によって制限されるのだ。
あなたは、コンピューターに写真から猫を認識させるための手動ルールを書くことはできない。機械に中国語を英語に翻訳させるためのロジックを書くこともできない。ましてや、AIがゼロから囲碁を学ぶためのアルゴリズムを書くことなど到底できない。
なぜならこれらのタスクは……人間自身がそのルールを明確に説明できず、どうやってコードに落とし込めばいいのか分からないのだから。
022017年: ソフトウェア 2.0
2017年11月、KarpathyがまだTeslaでAutopilotを担当していた頃、Mediumに一つのブログ記事を書いた：ソフトウェア 2.0。
この記事は後に、AI分野で最も影響力のあるコンセプト論文の一つと見なされるようになった。
彼の核心的な主張はこうだ。ニューラルネットワークは単なる新しいツールではなく、全く新しいプログラミングパラダイムを代表している。
ソフトウェア 1.0 では、プログラマーがコードを書く。ソフトウェア 2.0 では、プログラマーはデータと目的関数を用意し、最適化アルゴリズム（勾配降下法）にニューラルネットワークの重みの組み合わせを探索させる。
「 ソフトウェア 2.0は、より抽象的で人間にとって不親切な言語、例えばニューラルネットワークの重みで書かれている。重みの数が膨大すぎるため（典型的なネットワークは数百万の重みを持つ）、誰もこれらのコードの作成に関与していない。直接コードを書くことはもはや不可能なのだ。」
言い換えれば、学習プロセスこそがプログラミングプロセスであり、データセットこそがソースコードである。
彼は記事の中で、ソフトウェア 2.0 が既にソフトウェア 1.0 を「侵食」した分野の長いリストを挙げている。
画像認識は手作りの特徴量エンジニアリングから深層畳み込みネットワークへ、音声認識は混合ガウスモデルからend-to-endのニューラルネットワークへ、機械翻訳はフレーズベースの統計手法からTransformerアーキテクチャへ、囲碁は手書きの評価関数からAlphaGo Zeroの自己対局へと移行した。
そして、ソフトウェア 2.0 の利点は、計算グラフが均質である（主に行列乗算）ためハードウェア最適化が容易であること、実行時間が予測可能で無限ループがないこと、動的メモリ割り当てが不要なためメモリリークがないこと、などにある。
さらに多くの分野で、そのパフォーマンスは既に人間の手書きによるソリューションをはるかに凌駕している。
記事の末尾でKarpathyは当時、我々が最終的にAGI（汎用人工知能）を作り上げる時、それは必ずソフトウェア 2.0 で書かれているだろうと予言した。
この予言は非常に成功したと言えるだろう。ただ、2026年の今日から見ると……半面しか当たっていないように思える。なぜなら：
033.0 の到来
Karpathy自身も、ソフトウェア 2.0 の記事を書くのが早すぎたと認めている。当時はまだGPTも登場しておらず、Transformerが発表されたばかりだった。彼は一つのものを予見できなかった：大規模言語モデル（LLM）だ。
ソフトウェア 2.0 のプログラミング方法は、データを用意し、ネットワーク構造を設計し、学習させる、というものだ。このプロセスには大量の機械学習の専門知識、GPUクラスタ、数週間から数ヶ月に及ぶ学習時間が必要だ。極めてハードルが高い。
一方、ソフトウェア 3.0 のプログラミング方法は、全く異なる。
プロンプトを書き、モデルにいくつかのコンテキストを与えれば、それが実行される。
学習も、勾配降下法も、ラベル付きデータも必要ない。
自然言語で「プログラミング」し、コンテキストウィンドウを「メモリ」として使う。ツール呼び出しを「システムコール」として使う。LLMは新型の計算インタープリタとなり、プロンプトこそがそのソースコードとなる。
Karpathyは今回のAI Ascentで、三世代のソフトウェアを明確に要約した。
• ソフトウェア 1.0：人間がコードを書く
• ソフトウェア 2.0：データで学習されたニューラルネットワーク
• ソフトウェア 3.0：プロンプト、コンテキスト、エージェント、ツール、記憶、検証によるプログラミング
コンテキストウィンドウが、新たなプログラミングインターフェースとなった。
04MenuGenの例
Karpathyは、自ら手がけたプロジェクトを例に挙げた：MenuGen。
こんなシナリオを想像してみてほしい。あなたがレストランに入り、メニューの写真を一枚撮る。するとアプリが自動で各料理の名前を認識し、料理の画像を検索し、再レイアウトして、写真付きの美しいメニューを生成する。
従来の方法でこれを行う場合、フローはおおよそ次のようになるだろう。まずOCRで文字を認識し、次にNLPで料理名を抽出し、それから画像検索APIを呼び出し、最後にフロントエンドを書いて再レイアウトする。少なくとも数百行のコードが必要で、おそらく1～2日はかかる。
ところがKarpathyは、写真を直接Geminiに投げ、元の画像の上に料理の画像を重ねさせることで、中間層のアプリ全体が不要になることに気づいた。
これこそがソフトウェア 3.0 の最も破壊的な点だ。一部のアプリケーションは、開発が速くなったのではなく、モデルのネイティブ能力によって直接的に飲み込まれてしまったのである。
05「 AIが何をより速く構築できるようになるかだけを問うてはいけない。AIが何を不要にするのかを問うべきだ。」
Vibe CodingからAgent Engineeringへ
「Vibe Coding」という言葉は、Karpathy自身が2025年初頭に作ったものだ。参照：レジェンド音楽プロデューサーRick Rubinが『道徳経』を魔改造したVibe Coding版『プログラミングの道』の舞台裏。
当時、AIプログラミングツールが登場したばかりで、彼はこの言葉を新しい開発スタイルを表現するために使った。コードの詳細は見ず、直感と自然言語でAIと協力し、「フィーリングが合えばそれでOK」というものだ。
そして、この言葉は大流行した。彼自身も驚くほどに。
しかし、Karpathyが今回言いたかったのは、Vibe Codingは単なるウォーミングアップに過ぎないということだ。
2025年12月、彼はある「反転」を経験したという。自分で80%のコードを書き、エージェントが20%を書く状態から、一気に20/80になったのだ。
2026年には、この比率はさらに傾き続けている。
彼はそのせいで「AI精神病」（AI psychosis）に陥った。毎日16時間もエージェントに話しかけ、エージェントが一つのタスクを完了するとすぐに次のタスクを開始したくなり、トークンを使い切らないと自分がサボっているように感じるのだという。
今回の講演で、Karpathyはこの変化をさらに二つの層に分解した。
Vibe Codingは床を底上げする。
プログラミングを全く知らない人でも、誰でも自然言語で要件を記述し、AIに使えるアプリケーションを生成させることができる。これは以前は想像もできなかったことだ。デザイナーはプロトタイプを作り、プロダクトマネージャーは内部ツールを作り、学生は自分のプロジェクトを作ることができる。参入障壁はほぼゼロに引き下げられた。
Agent Engineeringは天井を引き上げる。
プロの開発者がエージェントを使う方法は全く異なる。彼らは単に「AIにコードを書いてもらう」のではない。彼らはシステム全体を設計しているのだ。エージェントがソリューションを生成し、エージェントがコーディングし、エージェントがテストし、エージェント同士が相互チェックする。このプロセスは、セキュリティホールがなく、アーキテクチャがクリーンで、システムが堅牢であることを保証しなければならない。
これがKarpathyの言う「Agentic Engineering」、すなわちエージェンティック・エンジニアリングである。
06「 Vibe Codingが底上げするのは、誰もがソフトウェアを作れるようになる下限だ。Agentic Engineeringが守ろうとしているのは、プロフェッショナルなソフトウェアがこれまで保持してきた品質の基準だ。」
検証可能性
Karpathyは講演でさらに一つの見解を提示した：従来のソフトウェアが自動化するのは、仕様化できるものだ。一方、AIが自動化するのは、検証できるものだ。
これは私の目には、非常に核心的な点に映る。
コードが正しいかどうか？テストを実行すれば分かる。数学的に正しいか？計算してみれば分かる。セキュリティ上の脆弱性はあるか？スキャンツールで発見できる。
これらの領域には共通の特徴がある：出力を客観的に評価できるということだ。
まさに検証可能だからこそ、これらのタスクは強化学習のループに入り、モデルが訓練を重ねるほどに賢くなっていける。
これこそが、AIがプログラミング、数学、コードセキュリティなどの面で急速に進歩している一方で、「常識推論」においていつも信じられないようなミスを犯す理由でもある。
Karpathyは例を挙げた。モデルは10万行のコードベースをリファクタリングし、ゼロデイ脆弱性を発見できる。しかし同時に、「あなたの車は50メートル先の洗車場にあります。歩いていくことをお勧めします」と平然とアドバイスする。
このような現象を「ジャギーインテリジェンス」（jagged intelligence）と呼ぶ。
能力曲線は滑らかに上昇するのではなく、高峰がある一方で、断崖もある。高峰は、研究所にデータと報酬シグナルがカバーされている領域に現れる。断崖は、訓練データ分布の外側の領域に現れる。
Karpathyはさらに、イベント後の投稿でこう説明している。ジャギーな分布は検証可能性だけでなく、経済学とも関係している。収益と市場規模（TAM）が、最先端の研究所が強化学習の訓練でどの領域をカバーするかを決定するのだ。
「 あなたは、データ分布の内側にいて、強化学習（RL）の軌道の上を疾走しているか。さもなければ、軌道の外側で、鉈（なた）を手にジャングルの中で道を切り開いているかのどちらかだ。」
Claudeが10万行のコードをリファクタリングできるのは、誰かがその能力を学習させるためにお金を払ったからだ。しかし、「洗車場への行き方」といった問題については、誰も学習のためにお金を払っておらず、モデルの重点でもないのである。
これは実のところ、知能の問題ではなく、経済配分の問題なのだ。
起業家にとっての機会は、こうだ。検証環境を構築できるが、まだ大手研究所の強化学習の網羅範囲に入っていない領域を見つけること。もしあなたが独自に報酬関数を設計できれば、たとえ主流のモデルが特化した最適化を行っていなくても、ファインチューニングによって顕著な優位性を得ることができる。
07ハーネス
Karpathyはもう一つのコンセプトにも言及した：ハーネス（harness）だ。
この言葉は最近、エージェント技術において特に熱い。私も以前、これを紹介するために『モデルは重要ではない、ハーネスこそが重要だ』という記事を書いた。
ハーネスの概念は、今年2月にHashiCorpの共同創業者であるMitchell Hashimotoが最初に提唱した。彼はAIを使ってGhosttyプロジェクトを進める中で、一つの原則をまとめ上げた。
「 エージェントがミスを犯すのを発見するたびに、あなたは時間をかけて工学的な解決策を練り上げ、二度と同じミスを犯さないようにさせるのだ。」
後に、Cursor、OpenAI、Anthropicなども相次いでハーネスに関するエンジニアリングブログを発表した。
例えば、Anthropicのブログで議論されている核心的な問題はこうだ：AIエージェントは、どのようにして複数のコンテキストウィンドウ間で進捗を維持するのか？
彼らの解決策は、エージェントを初期化して環境を構築し、進捗ファイル（claude-progress.txt）を作成し、基準となるコミットを確立するというものだ。実行エージェントは機能を一つずつ完了し、新しいコンテキストウィンドウが始まるたびに、最初にgit logと進捗ファイルを読み込み、前のラウンドから続行する。
これは、エージェントに引き継ぎ書類を書くようなものだ。
Karpathyの見解はさらに急進的だ。将来のソフトウェアはエージェントのために書き直されるべきであり、人間のユーザーを全く考慮する必要はないと。
現在のソフトウェアインターフェースは人間用に作られており、ボタン、メニュー、マウスがある。しかし、エージェントはこれらを必要としない。エージェントが必要とするのは、機械が読み取り可能なインターフェース、明確な権限宣言、分解可能なワークフロー、明瞭な命令フォーマットだ。
彼は投稿でちょっとした例も挙げている。なぜまだ複雑な.shインストールスクリプトを書く必要があるのか？ あなたは完全に.mdファイルを使い、インストール手順を英語で明確に書き、ユーザーに「このファイルをあなたのLLMに見せてください」と伝えればいいのだ。
LLMは高級なインタープリタとして、あなたのシステム環境に応じてインストールプロセスをインテリジェントに調整し、問題があればインラインでデバッグすることもできる。
.mdを.shの代わりに、.pyや.goなどの代わりに使う。これは、私自身の最近のやり方でもある。
08人間の立ち位置
AIとエージェントについてこれだけ多くのことを語った後で、Karpathyは人間自身について語ることも忘れなかった。
彼の判断はこうだ：理解力は外部委託できない。
エージェントはAPIを呼び出し、コードを書き、テストを行うことができる。しかし、どうしてもできないことがいくつかある。
システム仕様設計：例えば、ユーザーシステムはメールアドレスではなく、安定的なユーザーIDを使って資金を関連付けるべきだ、といった判断。これにはビジネスロジックへの理解、経験、結果への予見が必要だ。
概念理解：テンソルとは何か、メモリビューがどのように機能するか、ストレージメカニズムの背後にある原理を、APIの名前を知っているだけでなく本当に理解する必要がある。さもなければ、エージェントが書いたコードが正しいことをしているかどうかを判断できない。
センス：エージェントが書くコードはしばしば「動くが見苦しい」。すべてのテストにパスし、機能的にも正しいが、アーキテクチャはめちゃくちゃ、ネーミングは無茶苦茶、複雑さが制御不能に陥っている。何が良い設計かを知っておく必要がある。
「 あなたは自分の思考を外部委託できるが、自分の理解を外部委託することはできない。」
もしシステムが何をしているのかを理解していなければ、エージェントがミスを犯したときに、どこが間違っているのかを知ることはできない。
そして、エージェントは必ずミスを犯す。
私も時々そう感じることがある。相手が真面目な仕事の質問に答える際に「AIは～と考えている」と言い出した時、私は彼を遮って「AIの考えやAIの判断ではなく、あなたの考え、あなたの判断は？」と言う。
09三世代のソフトウェア
これら三世代のソフトウェアパラダイムの進化を振り返ると、その主線は：人間の関与の仕方が絶えず変化していることにある。
ソフトウェア 1.0 の時代、プログラマーは作者だった。一行一行のコードは彼自身が打ち込み、ロジックは彼が設計し、バグは彼が修正した。彼はシステム全体に対して完全な制御権を持ち、同時に全責任を負っていた。
ソフトウェア 2.0 の時代、プログラマーはコーチになった。彼はもはやロジックを直接書くのではなく、訓練データを用意し、ネットワーク構造を設計し、ハイパーパラメータを調整し、最適化アルゴリズムに解決策を探索させる。彼の仕事は「機械にやり方を指示する」ことから「機械にやるべきことを見せる」ことへと変わった。
ソフトウェア 3.0 の時代、プログラマーは指揮官になった。彼はデータを準備する必要も、モデルを訓練する必要もない。自然言語で意図を記述し、コンテキストを与え、一群のエージェントに指示して実行させるだけでよい。彼の仕事は「機械に見せる」ことから「機械に何を望むかを伝える」ことへと変わった。
「ハウ」（how）から「ショー」（show）へ、そして「ホワット」（what）へ。
しかし、この主線のもう一面は、世代が移行するたびに、人間は実行の詳細に対するコントロールを失う代わりに、より高い次元のレバレッジ（てこ）を手に入れるということだ。
Karpathyが以前のポッドキャストで語ったように、以前の不安はGPUがアイドル状態であることだったが、今の不安はトークンを使い切れていないことだ。かつてのボトルネックは計算リソースだったが、今のボトルネックは人間なのだ。
あなたがどれだけのトークン処理能力をコントロールできるかが、あなたがどれだけのことを成し遂げられるかを決定する。
投稿の最後で、彼はさらに遠くを見据えた展望を投げかけている：完全ニューラルコンピューティング（fully neural computing）だ。
彼が思い描く未来では、大多数の計算はニューラルネットワークによって処理され、従来のCPUはむしろ「コプロセッサ」となり、一部の補助的なタスクだけを担当するようになる。
これは、彼が2017年のソフトウェア 2.0 の記事の末尾で行った予言と遠く呼応するものでもある。当時、彼はAGIは必ずソフトウェア 2.0 で書かれるだろうと言った。
今になって見ると、彼はAGIがむしろソフトウェア 3.0 によって生み出され、LLMが主役で従来型の計算が補助となる全く新しいアーキテクチャ上で動作する可能性が高いと考えているようだ。
103.0 時代
私の目には、今回のKarpathyは「未来の夢物語」をあまり語っていないように映る。彼が語ったのは、基本的に既に起こっていることばかりだ。
ソフトウェア 3.0 は単なる概念でも、予測でもない。もしあなたがこのアカウントのこの記事を読み終えることができるなら、おそらくあなたは、とうの昔にその渦中に身を置き、身をもって感じていることだろう。
Anthropicが今年発表した「2026 Agentic Coding Trends Report」では、2025年にはエージェンティックAIが多くの開発者のコーディング方法を変え、2026年はこの変革がソフトウェア開発のライフサイクル全体を再構築し始める年になると述べている。
そして私自身も、おそらく2025年後半か、いつからかは定かではないが、一行も手でコードを書かなくなり、毎日、数分から数時間、エージェントに話しかけるようになった……。
ソフトウェア 3.0 時代は、これから来る、もうすぐ来る、というものではない。
そうではなく、まさに今ここにあるのだ。
◇ ◆ ◇
• KarpathyのSoftware 2.0原文（2017年）：https://karpathy.medium.com/software-2-0-a64152b37c35
• AI Ascent 2026 完全版動画：https://www.youtube.com/watch?v=96jN2OCOfLs
• KarpathyのX（Twitter）投稿まとめ：https://x.com/karpathy/status/2049903821095354523
• Anthropic ハーネスブログ：https://www.anthropic.com/engineering/effective-harnesses-for-long-running-agents
• Stephanie ZhanのX（Twitter）投稿：https://x.com/stephzhan/status/2049518659513852109
• Sequoia Inference のSoftware 3.0について：https://inferencebysequoia.substack.com/p/andrej-karpathys-software-30-and