Software 3.0、ヴァイブ・コーディング、そしてエージェントの十年
なぜ Andrej Karpathy の地図を読むのか
AI を使った開発の話をしようとすると、語彙がまだ足りていない、と感じることが多い。コードを生成する、エージェントに任せる、プロンプトを書く ── どれも輪郭がぼやけている。何が新しくて、何が昔と同じなのか、自分の言葉では切り分けにくい。
そういうとき、Andrej Karpathy という人物がいる。Stanford で深層学習の入門講座 CS231n を作り、OpenAI の創業メンバーになり、Tesla の AI ディレクターとして自動運転の実戦を率い、いま Eureka Labs という教育会社で LLM を一から教える講座を作っている。研究、量産、教育のすべてを内側から見てきた、希少な経歴の人だ。
彼の重要な仕事はもうひとつある。用語を提供することだ。「Software 2.0」「データ・エンジン」「コンテキスト・エンジニアリング」「ヴァイブ・コーディング」「ゴースト、動物ではなく」「エージェントの十年」── これらの言葉はいずれも、彼の講演や X、ブログから業界に広まっていった。
この本は Karpathy の 地図を借りて、AI 時代の開発を整理し直すための小冊子だ。彼の言葉が便利なのは、答えを与えてくれるからではない。輪郭を引いてくれるからだ。輪郭が引かれて初めて、自分のプロダクトで何を試すべきかが見えてくる。
各章は二段構えにしてある。前半 (思想) で Karpathy がそこをどう見ているかを読み、後半 (実務) で「では月曜の朝から何を変えるか」を具体的な行動に落とす。サイドノートには英語原文と出典 URL を添えた。彼の語感そのものを残したかったからだ。
通読には30分弱かかる。コーヒーを淹れて、はじめよう。
置換ではなく、重畳。コードベースには三層が同居する
Karpathy の地図の出発点は、「ソフトウェアの書き方には三つの世代がある」という整理だ。最初の整理は 2017 年のエッセイ Software 2.0 で示され、2025 年の AI Startup School の講演 Software Is Changing (Again) で 3.0 が加わって完成形になった。
Software 1.0 は、私たちが当たり前にやってきた書き方だ。人間が if や for を Python や Java や Rust で書き下す。コードがそのままプログラムになる。仕様は人間の頭の中にあり、それを言語に翻訳する作業がプログラミングだった。
Software 2.0 は、ニューラルネットの登場で生まれた。ここではコードを書く代わりに、データを集め、損失関数を決め、最適化器に重みを書かせる。プログラムの実体は、もはやソースコードではなく 重みの数列だ。Tesla の自動運転のように、かつて C++ で何万行も書かれていた知覚ロジックが、ニューラルネットに「食われて」消えていく現象を Karpathy はその目で見てきた。
Software 3.0 は LLM の登場で開けた第三層だ。プロンプトがプログラムになり、LLM がそのインタプリタとして振る舞う。私たちは 英語でプログラミングしている。コードベースの一部 (たとえば文章要約、分類、検索クエリの正規化) は、もう Python の関数として書かれていない。プロンプトとして書かれ、LLM 呼び出しで動く。
重要なのは、これらが 置換ではなく重畳だという点だ。2.0 が出たとき、1.0 のコードがすべて消えたわけではない。3.0 が出たいまも、1.0 と 2.0 は健在だ。今日のプロダクトは、ほとんどの場合この三層が同居している。だからこそ、自分が今書いているコードが何層目なのかを意識する必要が出てきた。
では月曜から何ができるか。手っ取り早い演習は、いま触っているリポジトリのファイルを、頭の中で三色に塗り分けてみることだ。
塗り分けが終わると、いくつかの気づきが出てくる。たとえば「赤い領域が一箇所に集中せず、コードベースの至るところに散らばっている」「赤を呼び出す関数のテスト戦略が、青と同じになっている」「緑と赤が直接話していなくて、間に毎回 1.0 のグルーコードが挟まっている」── こうした観察が、次に投資すべき設計判断を教えてくれる。
もうひとつ大事なのは、新しい機能を作るとき、まず三層のどれで書くかを意識的に選ぶ習慣だ。同じ「メール本文を生成する」という要件でも、テンプレート (1.0) で書くのか、LLM (3.0) で書くのか、ベクトル類似度で過去のメールから引っ張る (2.0) のか。選択肢が三層あるという前提を持つだけで、設計の解像度が上がる。
人間でも動物でもない、召喚された奇妙な知性に向き合う
LLM をうまく使えるかどうかは、技術力よりも「相手をどう捉えているか」で決まる。Karpathy が一貫して強調してきたのは、LLM を人間のメタファーで考えてはいけないということだ。彼は二つの強力なアナロジーを用意している。OS としての LLM、そしてゴーストとしての LLM。
Karpathy が AI Startup School で繰り返したアナロジーはこうだ。LLM は CPU に相当する。コンテキストウィンドウは RAM。ツール呼び出し (検索、コード実行、ファイルシステム) は 周辺機器。そして OS の中核として、入力のスケジューリング、メモリの割り当て、I/O の調停をしているのが LLM 本体だ。
このアナロジーが効くのは、いまの LLM の置かれた状況が、1960 年代の中央集権コンピューティングに似ているからだ。計算資源は高価で、限られたデータセンターに集約され、利用者は遠隔の端末から「タイムシェアリング」で使う。Karpathy はこの状況を「fabbed by labs, distributed like utilities」と表現する ── 半導体工場のように少数の研究所が作り、電力や水道のように配給される。
もう一つのアナロジーは、もっと不穏なものだ。Karpathy は LLM を「進化する動物」ではなく「召喚されたゴースト」だと言う。人間の脳は数億年の進化と肉体を通して育ってきた。LLM はインターネットのテキストから蒸留され、肉体も連続した記憶もない。だから、人間ぽい応答をしても、その内側で起きていることはまったく違う。
このゴーストには、Karpathy が「jagged intelligence (尖った知性)」と呼ぶ性質がある。微積分やプログラミング競技は驚くほど解く一方で、「strawberry に r はいくつ?」のような幼児的な問いに転ぶ。賢さの形が人間とずれている。同じモデルが、ある領域では博士で、別の領域では混乱した小学生になる。
そして、もうひとつの重要な性質が 逆向性健忘 (anterograde amnesia)。LLM はセッションを越えて記憶を持たない。昨日の会話を覚えていないし、今日学んだことを来週には忘れている。長期記憶も、自己認識も、まだ持っていない。
この心理学を理解すると、設計判断が変わる。第一に、ハルシネーション (幻覚) は欠陥ではなくデフォルトの挙動として扱う。LLM は「自信がないので答えません」という機能を持って生まれてきたわけではない。だから、外側にガードレールを置くのは呼び出し側の責任だ。検証可能な領域 (数値、SQL、コード、URL) は機械的に検証する。検証できない領域 (要約、翻訳、意見) は人間の眼を残すか、別モデルで二重評価する。
第二に、記憶の不在を前提に状態を設計する。会話履歴、ユーザーの好み、ドメイン辞書、過去の決定 ── これらはアプリ側で永続化し、呼び出し時に必要なぶんだけ context に注ぐ。LLM 自身が覚えていることに依存してはいけない。
第三に、タスク単位でモデルを選ぶ。Karpathy 自身も 2025 年の振り返りで、用途に応じて Cursor / Claude Code / GPT-5 Pro を使い分けていることを語っている。コスト・速度・精度の三角形のどこに今のタスクが位置するかを見て、毎回「どのモデルをブートするか」を選ぶ。これは Software 1.0 では発生しなかった、新しい意思決定の種類だ。
プロンプトの一文ではなく、窓の中身を設計する
「プロンプト・エンジニアリング」という言葉が出てきた頃、それは魔法の一文を考える芸のように受け取られていた。Karpathy は 2025 年の半ば、X 上で短い投稿をした。+1 for "context engineering" over "prompt engineering" ── 言葉を変えるべきだ、と。
プロンプト・エンジニアリングが「日常的に LLM に渡す短い指示」を連想させるのに対して、業務レベルの LLM アプリで本当に必要なのは、もっと広い問いだ。次の一歩のために、いまコンテキストウィンドウに何を入れるべきか。これを Karpathy は「繊細な技芸」と呼んだ。
第2章の OS アナロジーに戻れば、これは「OS としての自分が、限られた RAM に何をロードし、何をエビクトするか」という決定だ。プロンプトが一文ならローカル変数の話だが、コンテキスト・エンジニアリングは メモリ管理の話になる。
プロンプトは「魔法の呪文」を考える行為。
コンテキスト・エンジニアリングは「映画の全脚本」を書く行為。LLM が次のシーンを演じるために必要な背景、登場人物、過去の出来事、舞台装置を、限られた窓に過不足なく並べる。
実装に落とすと、コンテキスト・エンジニアリングはいくつかのレイヤーに分かれる。
1. システムプロンプト ── 役割と原則。変わらない指示はここに置く。エージェントの性格、出力フォーマット、絶対に守るべき制約。長すぎると後段の指示を押しのけるので、削れる文は削る。
2. RAG (検索拡張) ── 知識の注入。ドキュメント、過去ログ、社内ナレッジを必要なぶんだけ引いてくる。引きすぎはノイズになり、引かなさすぎはハルシネーションを誘う。embedding の精度よりも、ランキングと カットオフのチューニングがふだん効く。
3. ツール定義 ── 行動の選択肢。LLM に使わせる関数のシグネチャと、いつ使うべきかの記述。これも「全部のツールを毎回見せる」と判断が鈍る。タスク種別ごとに見せるツールを絞ると、エージェントの精度が目に見えて上がる。
4. スクラッチパッド ── 中間状態。長い推論を一発で出させるのではなく、思考メモを書きながら進ませる。Chain-of-thought の本質はこれで、書く場所を context の中に確保しておくのが設計判断になる。
そして、忘れがちなのが エビクション戦略だ。会話が長くなると、初期のシステムプロンプトと最後のユーザー発話だけが効き、中盤が忘れられる ("lost in the middle" 現象)。タスクが切り替わったら古いコンテキストをサマリーに圧縮する、長期記憶は外部 DB に逃がす、重要な制約は会話の終端に再度差し込む ── こうした泥臭い工夫が、結局のところ品質を決める。
Iron Man スーツは、Iron Man ロボットではない
2025 年の春以降、業界は「フル自動エージェント」のデモに溢れた。Karpathy はそれに静かに反論する。今のエージェントが目指すべきなのは、ロボットの自律ではなく、スーツの拡張だ、と。
Iron Man スーツは Tony Stark の身体を増幅する。スタークは依然としてループの中にいて、判断し、操縦する。一方の Iron Man ロボットは自走する。判断も操縦も AI が握る。技術的に困難な順序は明らかで、まずスーツが先に来る ── 自律は後から、徐々にスライダーが右へ動いていく。
この発想は Karpathy が Tesla で学んだものだ。自動運転は Level 1 (運転支援) から Level 5 (完全自動) までスライダー上に並んでいる。一気に Level 5 を狙うのではなく、低い段で安全に動かしながら、運転手がどこまで手を放せるかを少しずつ広げていく。これが 部分自律性 (partial autonomy) の思想だ。
Cursor も Perplexity も同じ構造を持っている。Cursor の「タブで補完」は最も低い自律度、「Composer に丸投げ」は最も高い自律度。ユーザーは状況に応じて、その日のタスクに応じて、自分でスライダーを動かす。AI に与える権限は、固定値ではなく 可変パラメータだ。
では月曜から何ができるか。Karpathy が繰り返し強調するのは、「生成 (generation) と検証 (verification) のループを高速に」という原則だ。AI が何かを提案する。人間が一目で判断できる。承認すれば適用、却下すれば次の案。このサイクルが速ければ速いほど、部分自律性は実用になる。
具体的な設計パターンとしては:
もうひとつ大切なのは、スライダーの両端を作ること。最も保守的なモード (たとえば「読み取り専用、提案のみ」) と最も積極的なモード (「自動で適用、自動でテスト、失敗時のみ通知」) の両端を用意し、その間に何段かのプリセットを置く。ユーザーは自分のタスクに合わせて選ぶ。「フル自動」ではなく、「いまはここの目盛り」という選択がデフォルトになる。
AI 機能の UI 設計は、権限の固定ではなく スライダーの提供。ユーザーが信頼度に応じて自律度を動かせるとき、プロダクトは「フル自動の到来を待つ」必要がなくなる。今すぐ出荷しながら、徐々に右へ動かしていける。
コードが ephemeral になった世界での開発リズム
2025 年 2 月、Karpathy は X に短い投稿をした。それが思いがけず時代の言葉になった。"vibe coding" ── ヴァイブに身を委ね、指数関数を受け入れ、コードが存在していることすら忘れる。冗談半分の言葉だったが、Collins 英語辞典の 2025 年の言葉に選ばれるほど、業界に広まった。
ヴァイブ・コーディングの本質は、「コードを読まないで進む」ことではない (それは誤解だ)。本質は、コードが ephemeral (一時的・使い捨て) になったという認識だ。Karpathy は 2025 年の年末振り返りでこう書いている ── 「コードは突然、自由で、移ろいやすく、しなやかで、捨てられるものになった」。
これまでの開発文化は、コードが 耐久財であるという前提に立っていた。長く維持する、ドキュメントを書く、変更コストを最小化する、保守性を最大化する。それが「いいコード」だった。ところがヴァイブ・コーディングの世界では、「明日もう書き直すかもしれないコード」が大量に作られる。今晩のアイデア検証、週末の習作、社内ツール、調査用の使い捨てスクリプト ── これらは保守性ではなく、到達速度で評価される。
もうひとつの新しい言葉が ambient programming (アンビエント・プログラミング)だ。Karpathy は Claude Code のような道具を「ローカルマシンに住む小さなゴースト」と呼ぶ。コンテナの中で動くサービスではなく、自分の開発環境にずっと居て、隣で一緒に作業してくれる。音声入力 (SuperWhisper) と組み合わせれば、もはやコーディングは「机に向かって書く」行為から、「歩きながら声で指示する」行為に変質しはじめる。
ヴァイブ・コーディングは万能ではない。Karpathy 自身、本番の Tesla 自動運転コードをヴァイブで書いたりはしない。判断軸は明快で、そのコードがどれくらい長生きするか、そして 失敗の代償がどれくらい大きいかだ。
| 領域 | ヴァイブ適性 | 理由 |
|---|---|---|
| プロトタイプ・PoC | ◎ | 使い捨て前提。到達速度が最重要 |
| 個人ツール・スクリプト | ◎ | 失敗してもやり直せる |
| 社内ダッシュボード | ○ | 影響範囲が限定的 |
| 本番アプリの新機能 | △ | 下書きはヴァイブ、レビューと検証は厳密に |
| セキュリティ・課金 | × | 失敗の代償が大きい。明示的に書く |
| 長寿命の基盤コード | × | 保守性 > 到達速度 |
Karpathy 自身が公開している、三層のツール使い分けも参考になる:
そして、ヴァイブ・コーディングが快適に回るための前提条件として、Karpathy が暗に示しているのが 速いフィードバックループだ。型チェック、テスト、ローカル実行、preview デプロイ ── これらが秒単位で返ってくる環境がないと、ヴァイブは事故に変わる。「コードを読まないで進む」が成立するのは、機械が即座に「動かない」と教えてくれる場合だけだ。
ここまでの議論は 2025 年の地図だ。2026 年 5 月の Sequoia AI Ascent で、Karpathy は自身のヴァイブ論を 自己更新した。タイトルがそのままズバリ ── "From Vibe Coding to Agentic Engineering"。
新しい整理はこうだ。ヴァイブ・コーディングと agentic engineering (アジェンティック・エンジニアリング) は別物で、目的が違う。
| ヴァイブ・コーディング | Agentic Engineering | |
|---|---|---|
| 目的 | 床を上げる ── 誰でも作れる | 天井を伸ばす ── プロの品質を保つ |
| 適性 | プロトタイプ・個人ツール | 本番・チーム開発 |
| 姿勢 | 生成を受け入れて進む | 仕様を書き、計画を監督する |
Karpathy が agentic engineer の責務として挙げるのは次のとおりだ ── 仕様を書く / 計画を監督する / diff を一行ずつ精査する / テストを書く / eval ループを作る / 権限を管理する / worktree を分離する / 品質基準を守る。エージェントは「鋭利だが当てにならない強力な存在 (spiky, fallible, stochastic)」であり、彼らを調整して速く動かしつつ、品質バーを犠牲にしないのがエンジニアリング規律になる。
もう一つの強い 2026 のフレーズが、コーディング・ワークフローの転換点に関するものだ。
Karpathy 自身、2025 年 11 月までは手書き 80% / AI 20% だったコーディング比率が、12 月以降にほぼ反転したと書いている。December 2025 inflection point ── エージェントが「使えるツール」から「主役」に変わった点 ── は、いまや業界共通の認識になりつつある。
実務的な含意は明快だ。本章で論じたヴァイブ・コーディングは「これで全部済ませる手法」ではなく、agentic engineering の中に組み込まれる一つのモードになった。プロトタイプはヴァイブで一気に作る。本番化のときは agentic engineering の規律に切り替える。スライダーは autonomy 軸だけでなく、品質バー軸にもあると考えるとよい。
競争優位は「データ」ではなく「データ・エンジン」が握る
Karpathy の地図には、評価について二段階の言葉がある。一段目は 2026 年 5 月に Sequoia AI Ascent で打ち出された、強い 公理だ。
自動化できる領域の境界線が、「コードで仕様を書き下せるか」から「機械的に検証できるか」へと移った、という宣言だ。検証可能な領域 ── 数学、コード、SQL、URL の到達性、構造化された出力 ── では LLM は驚くほど強い。検証できない領域 ── 文体、ユーモア、戦略判断、人間関係の機微 ── では、いまだに不安定なままだ。
この一文は、第2章の jagged intelligence の現象論を、戦略原則として書き直したものだ。能力が尖って見える理由は、検証関数を作れる領域に研究所が RL の計算を集中投下してきたからだ。だから「うちのプロダクトに AI を入れるか」の判断は、「うちの仕事の中で、検証関数を書ける部分はどこか」を探す作業に置き換わる。
検証できることだけが、自動化される。逆に言えば、検証関数を書ける領域を見つけることが、AI 機能の最初の設計判断になる。eval は QA 工程の末端ではなく、製品仕様の 上流にある。
二段目が、もっと古くからある言葉 ── データ・エンジン。Karpathy が Tesla で 5 年間率いていたのは、世界最大級の Software 2.0 プロジェクトだ。何百万台ものクルマからストリームされるカメラ映像を、ニューラルネットの訓練データに変え、再訓練し、配信し、その挙動をテレメトリで観測し、また新しい失敗例を集める ── このループを回し続けることが、すなわち自動運転の開発だった。彼はそこから得た一文を、後にこう書いた。
含意は強い。「データを持っている」は静的な資産だが、「データ・エンジン」は動的な仕組みだ。エンジンを早く回せる組織が、データを持っているだけの組織を追い抜いていく。
Tesla のデータ・エンジンの中核には アクティブ・ラーニングがある。モデルが苦手な事例 (難しいカーブ、特殊な天候、希少な看板) を本番フリートから探し出し、人間にラベリングさせ、訓練データに加え、再訓練する。「上手にできない例を集めて、そこを集中的に学ばせる」── これを延々と回す。
2025 年、この発想は LLM の世界にも本格的に流れ込んだ。それが RLVR (Reinforcement Learning from Verifiable Rewards) だ。数学やコードのように「正解が機械的に判定できる」領域で、モデルに大量に試行錯誤させ、報酬関数で学習を駆動する。RLVR で訓練されたモデルは、推論ステップを自発的に伸ばすようになる。これは事前学習や教師あり微調整に並ぶ「新しい第三の訓練ステージ」だと Karpathy は 2025 年の年末振り返りで書いた。
RLVR が成立するためには、報酬を判定する 評価関数 (eval) が要る。そして eval が訓練の上流にきた以上、評価設計はもはや QA の仕事ではなく、訓練の一部だ。これは LLM を組み込むプロダクト開発でも同じ構図になる。
Karpathy はベンチマークについて懐疑的だ。ベンチマークは公開された瞬間から RLVR の対象になり、すぐに飽和する (Goodhart の法則)。だから「公開ベンチで強い」ことよりも、「自分のドメインで効くか」を測る社内 eval の方がはるかに重要になる。
LLM 機能をプロダクトに入れるとき、いきなり Tesla 規模を目指す必要はない。最小構成は次の 5 ステップだ。
そして、Karpathy が再三言うのが「"vibe check" を eval に昇格させよ」という話だ。LLM 機能を作っているとき、最初は手元で何度か試して「いい感じ」を確かめる。その「いい感じ」の判定基準を、できる限り早く 自動評価に書き出す。最初は粗くていい。「出力に必ずこのキーが含まれる」「URL が valid である」「文字数が範囲内」── そういう機械チェックでいい。そこから徐々に、LLM-as-a-judge や人間の二択比較 (A/B 評価) を足していく。
もう一つ重要なのは、失敗事例こそが資産だという感覚だ。エンジニアは成功例を眺めて満足しがちだが、エンジンが回るかどうかは、いかに「うまくいかなかった事例」を貯められるかで決まる。失敗事例の収集を、ユーザーからのフィードバック UI と紐付けて、自動的に集まる仕組みにする。これが回り始めると、プロダクトは時間とともに賢くなる。
デモから本番までの距離は、9 の数で測られる
2024 年から 2025 年にかけて、「year of agents」というフレーズが業界を駆け抜けた。Karpathy はそれに静かに反論した。年ではなく、十年だ、と。
その根拠を、彼は Tesla で学んだ「march of nines (ナインの行進)」という言葉で説明する。デモが 90% の確率でうまくいく状態を作るのは、最初の 9 を取ることだ。次に 99%、99.9%、99.99% と、9 を一つずつ伸ばしていく。そして、9 を一つ進めるのは、それまでと同じくらいの仕事量がかかる。指数関数的に減るのは失敗確率であって、開発コストではない。
自動運転がこの法則の最も鮮明な例だ。Waymo は 2014 年に完璧なデモ走行を公開していた。それから 10 年以上が経った 2026 年でも、自動運転は限定的な地域でしか動いていない。デモから本番までの距離は、デモを見ただけでは測れない。
Karpathy が「エージェントは 動かない」と言うとき、彼は具体的に四つの不足を挙げる。
これらは「次の四半期で解決される」種類の問題ではない。だから Karpathy は「this is the decade of agents, not the year of agents」と言う。年単位の話としてマーケティングするのは煽りだが、十年単位の話として投資する価値は十分にある、という両面の主張だ。
これを日々の意思決定にどう翻訳するか。第一に、AI 機能のロードマップを 9 の単位で書き直す。「Q3 にエージェントをリリース」ではなく、「Q3 に 90% 動くプロトタイプ」「Q4 に 99% (社内ユーザー限定)」「翌年に 99.9% (一部本番)」── という具合に。各段階で何を測り、どこで人間を残すかを明示する。
第二に、失敗時の人間フォールバックを設計の一級市民として扱う。エージェントが詰まったとき、誰が、どう介入するか。これを「例外処理」ではなく、製品仕様の中核として書く。Tesla Autopilot がドライバーをループに残し続けたのと同じ発想だ。
第三に、「エージェントが読める Web」を意識する。自社のドキュメント、API、SDK、エラーメッセージは、いまや人間より先にエージェントが読む。llms.txt、構造化されたエラー、機械可読な変更履歴、エージェント用のクイックスタート ── これらを整備しておくと、外部のエージェントが自社プロダクトを 使える状態になる。
エージェントの「年」ではなく「十年」を信じるなら、設計の重心は マラソンの装備に移る。完成形を待つのではなく、毎年 9 を一つ伸ばせる工程を作る。途中で人間が降りられる停留所をたくさん設ける。エージェントが読みやすい Web を整える。これらが、十年の中盤で差を生む。
Software 3.0 の時代にこそ、基盤の理解が効く
ここまで、Karpathy の七つの地図を辿ってきた。最後の章では少し角度を変えて、彼の 学習者としての姿勢を見る。なぜか。AI 時代の開発手法は、ツールやベストプラクティスのリストにはならない。それらは半年で陳腐化する。残るのは、自分が学び続けられる筋肉だけだからだ。
Karpathy が公開してきた教育リポジトリには明確な系譜がある。micrograd (自動微分エンジンを 100 行で)、makemore (文字レベル言語モデルを段階的に)、nanoGPT (GPT-2 を 300 行で再実装)、そして 2025 年の nanochat (4 時間・100 ドルで自分の ChatGPT を最初から最後まで作る)。
共通する哲学はこうだ。巨大なシステムを丸ごと触るのではなく、最小限のスクラッチ実装を一行ずつ読み、自分で動かす。ライブラリの中身がブラックボックスでなくなった瞬間、抽象の隙間が見えてくる。Software 3.0 の時代、つまり LLM がコードを書いてくれる時代に、なぜわざわざスクラッチから書くのか。答えは逆説的だ。AI に書かせるからこそ、基盤を自分で持っていないと、出てきたコードの良し悪しが分からない。
ヴァイブ・コーディングが普及するほど、開発者のあいだに差が出にくくなる、と思われがちだ。事実はおそらく逆だ。誰でも「動くもの」を出せるようになるからこそ、「何を作るか」「どう作るか」の判断 ── すなわち taste ── の差が、可視化される。
Taste は美的感覚と訳されがちだが、ここでは「無数の選択肢の中から、いいものを選び取る感覚」のことだ。UI の手触り、API のシグネチャ、エラーメッセージの文面、コードの読みやすさ、ドキュメントの順序。これらは LLM がいくらでも草稿を生成してくれるが、その中から「これを採用する」と決めるのは依然として人間の仕事だ。そしてその判断は、長年の経験と無数の比較から育つ。
では月曜から何を続けるか。Karpathy の地図全体から導かれる、開発者として磨くべき三つの筋肉はこうだ。
| 筋肉 | 定義 | 日々の演習 |
|---|---|---|
| Orchestration | LLM 呼び出しを束ね、context を設計し、エージェントを組む技術 | 週に一つ、自分の作業の一部をエージェントに置き換える。失敗したら何が context に足りなかったかを記録する |
| Evaluation | 出力の良し悪しを測る基準を作り、自動化する技術 | "vibe check" で済ませそうになったら、3 件だけテストケースを書く。それを CI に乗せる |
| Taste | 無数の選択肢の中から、いいものを選び取る感覚 | 優れた製品・コード・文章を毎週読む。なぜ良いと感じたかを言語化する |
そして、スクラッチから一つ作る。LLM ではなくても、自動微分でも、トークナイザでも、小さなレイトレーサでもいい。完成形をコピペするのではなく、一行ずつ読み、自分で型のエラーに遭い、自分で動かすまで持っていく。これをやった経験が、AI が書いてきたコードを読むときの目になる。
最後に Karpathy 自身が引用される言葉を一つ。彼は nanochat の README にこう書いた ── 「最小限・読みやすい・ハックしやすい・フォークしやすい 強いベースライン」。これは彼が作るものすべてに通底する美学であり、AI 時代の開発者が自分のコードに対して持つべき態度でもある。
ゴーストと働くための、八つの言葉
八つの章を辿ってきた。Software 3.0 という三層の地図、ゴーストとしての LLM、コンテキスト・エンジニアリング、オートノミー・スライダー、ヴァイブ・コーディング、データ・エンジンと evals、ナインの行進、そして スクラッチから作る筋肉。これらの言葉はバラバラに見えて、実は一つの姿勢で繋がっている。
その姿勢を一言で書くなら、「ゴーストを過信せず、過小評価もしない」ということだ。LLM は人間ではないので、人間の代わりにはならない。だが、人間が苦手な作業の多くを ── プロトタイプ、ボイラープレート、書き直し、要約、検索 ── 劇的に速くしてくれる。その境界をどこに引くかが設計者の腕で、境界は固定ではなくスライダーで、年単位で少しずつ右へ動く。
Karpathy が地図屋として優れているのは、彼が「答え」を提供しないからだ。彼の言葉は、輪郭を引いてくれるだけ。輪郭が引かれて初めて、自分のプロダクトで、自分のチームで、自分の文脈で、何を試すかが見えてくる。地図を持つ意味はそこにある。
地図は領土ではない。
でも、地図がなければ、領土を歩けない。
この本の役目はここまでだ。あとは、月曜の朝に、自分のコードベースを開いて、塗り分けを始めるところから。
最後に、Karpathy 自身が 2026 年 5 月の Sequoia Ascent で締めくくった一文を借りておく。これは、本書全体の主張を、彼自身の言葉で言い切ったものだ。
考えることは外注できる。理解することは外注できない。地図を借りるのはいいが、自分の足で歩くのは結局あなただ。
あなたのゴーストとの旅が、いいものになりますように。
本書がよりかかった、Karpathy 自身の言葉と作品
本書中の英語原文引用は、上記出典からの抜粋。日本語訳は本書著者による意訳で、原文のニュアンスを優先した部分があります。