概要 — Karpathy が 2026 年に示した、新しい思考フレーム

2026年4月20日、Sequoia Capital が第4回 AI Ascent をサンフランシスコで開催した。冒頭の Fireside Chat に登壇したのが、OpenAI 共同創業者・Tesla AI 元責任者・Eureka Labs 創業者の Andrej Karpathy である。Sequoia パートナー Stephanie Zhan との対談で語られた内容は、Boris Cherny の「コーディングは解決された」（コーディング解決後の5論点近日公開）と並ぶ、2026年前半の AI 言説の中心になっている。

Karpathy の主張は、Boris の宣言を補完しつつ、より深い層を切り出している。要点は3つ。(1) ソフトウェア時代は 1.0 → 2.0 → 3.0 へ移行している、(2) AI の自動化境界を決めるのは「specify できるか」ではなく「verify できるか」である、(3) 次の世代のインフラは「ユーザーネイティブ」ではなく「エージェントネイティブ」である——。

▲ Sequoia Capital 公式：Andrej Karpathy × Stephanie Zhan「From Vibe Coding to Agentic Engineering」（YouTube・AI Ascent 2026, 2026年4月20日）

本記事では、Karpathy の対談動画と本人ブログ（karpathy.bearblog.dev）を起点に、彼のフレームを整理し、AX Boost「業務×検証可能性マトリクス」 として、日本企業の AI 推進担当者が「何を AI に任せ、何を人間が担うか」を判断するための道具として翻訳する。

Software 1.0 → 2.0 → 3.0 — コンテキストウィンドウがプログラム面になる

Karpathy は、ソフトウェア進化を3つの世代で捉える。

世代 プログラミング面 例
Software 1.0 人間が明示的にコードを書く C、Python、Java
Software 2.0 人間がニューラルネットワークの重みを訓練する 画像認識モデル、推薦エンジン
Software 3.0 人間が コンテキストウィンドウ を通じてモデルをプログラムする LLM プロンプト + ツール + メモリ + 例示

重要なのは、Software 3.0 では 「コンテキストウィンドウが新しいプログラミング面」 になるという視点だ。エンジニアの仕事は、コード行を書くことから、モデルに与える文脈（指示・ツール・例示・メモリ・スキーマ）を設計することに移る。

Karpathy 自身が開発した MenuGen（メニュー画像から料理写真を生成するアプリ）を例に、彼は「マルチモーダルモデルへの画像→画像変換で、従来のアプリスキャフォルディング（フロントエンド・バックエンド・データベース）を丸ごと省略できる」ことを示した。これは Software 3.0 の典型例である。

Vibe Coding vs Agentic Engineering — 「床を上げる」と「天井を上げる」

Karpathy が示したもう1つの構造が、コーディングの2つの方向性である。

Vibe Coding は 「床を上げる（raises the floor）」。自然言語の記述だけで非エンジニアでもアプリを作れる状態を指す。プロトタイプや個人ツールに最適で、コーディングを大衆化する方向性である。Boris Cherny が「Anthropic のチームでは PM もデザイナーも財務担当もコードを書く」と述べたのは、まさに Vibe Coding が組織に浸透した姿である。

Agentic Engineering は 「天井を上げる（raises the ceiling）」。プロフェッショナルエンジニアが、AI エージェント群を統率しながら、品質・セキュリティ・保守性 を維持する方向性である。求められるスキルは：

  • 詳細な仕様の設計
  • エージェントが生成したプランの監督
  • diff の検査と権限の管理
  • 評価ループの設計
  • システムの正しさの維持

Karpathy はこう述べた。「最高のエンジニアは、すべてのコード行を書く人ではない。エージェントを質を落とさず統率できる人だ」。10倍エンジニアと言われた時代を遥かに超えるスキルギャップが生まれる可能性があるという。

これは、2026年に Boris Cherny が「150PR/日記録」を出した姿と表裏一体である。Vibe Coding が大衆化を、Agentic Engineering が専門化を、それぞれ進める。組織はその両極に応じた人材戦略を持つ必要がある。詳しくは AI時代の人材戦略近日公開 で論じている。

検証可能性 — AI 自動化の境界を決める唯一の変数

Karpathy の中心的なテーゼがこれだ。

「Traditional software automates what you can specify. LLMs automate what you can verify.」 （従来のソフトウェアは specify できるものを自動化する。LLM は verify できるものを自動化する）

この一文が、なぜコーディングは急速に解決され、なぜ常識的なタスクは依然として難しいのか、を説明する。コーディングは テストが通るかどうか で結果が機械的に検証できる。一方、Karpathy が挙げる「カーウォッシュ問題」では、モデルは「車を運転して洗車場に行く」のではなく「50m歩いて洗車する」ような提案をする——常識的に正しいかの検証ループが学習プロセスに組み込まれていないからだ。

ここから導かれる 「ジャグド・インテリジェンス（jagged intelligence）」 という概念は、企業の AI 推進担当者にとって極めて実用的である。LLM は 10万行のコードベースをリファクタリングできる一方、基本的な推論で失敗することがある。能力分布は均一ではなく、ギザギザしている。

そして、競争優位を生む示唆がここにある。Karpathy は 「フロンティアラボが訓練を集中させていない、検証可能でビジネス価値の高い領域」 を見つけることが、新興 AI ネイティブ企業の機会だと示唆する。具体例として挙げられたのは、金融オペレーション、コンプライアンス、契約レビュー、保険請求処理 など——いずれもルール明確・検証可能・ビジネス価値高の領域である。

AX Boost フレーム — 業務×検証可能性マトリクス

Karpathy の検証可能性論を、日本企業の AI 推進担当者向けに翻訳する。AX Boost は、業務領域を 「検証可能性」 と 「ビジネス価値」 の2軸で分類することを提案する。

ビジネス価値: 高 ビジネス価値: 低
検証可能性: 高 第1象限 / AI 先行投資領域 ：コード生成、データ品質チェック、契約レビュー、定型法務、月次クロージング、KYC 第2象限 / コモディティ化進行領域 ：定型データ入力、単純なドキュメント変換
検証可能性: 低 第3象限 / カスタム RL 環境の機会領域 ：戦略立案、複雑な交渉、新規事業評価、組織人事判断 第4象限 / 後回しでよい領域 ：曖昧な雑談、嗜好判定

それぞれの象限への対応原則：

第1象限: フロンティアラボが訓練を集中させている領域。市場では大手プレイヤーの製品（Claude Code、Cursor、GitHub Copilot、Microsoft 365 Add-ins、Claude Finance 等）が次々と進化する。企業の戦略は「自社で作る」より「最先端を選定して取り込む」に置くべき。

第2象限: コモディティ化が進む領域。差別化を狙わず、汎用ツールで処理する。

第3象限: AX Boost が最も価値を出せる領域。自社業務固有の検証フレームワーク を設計することが競争優位の源泉になる。Karpathy が「カスタム RL 環境を構築できる領域」と表現した、新興 AI 企業の機会領域でもある。経営判断・複雑な交渉・新規事業評価などは、汎用 LLM では verify できないため、企業独自の評価ループを組み込む価値が高い。

第4象限: 検証可能性もビジネス価値も低い領域。AI 投資の優先順位は低い。

このマトリクスの実装には、評価フレームワークの設計力が決定的になる。詳しくは AI評価フレームの実装論近日公開 で論じた「LLM-as-Judge × ベンチマーク × 人手評価」の3層構造を参照されたい。

エージェントネイティブインフラ — 次のフロンティア

Karpathy は、Software 3.0 時代のインフラには「ユーザーネイティブ」ではなく「エージェントネイティブ」が求められると述べる。具体的には：

  • マシン可読のドキュメント — Markdown と構造化スキーマ
  • CLI / API ファーストの設計 — GUI 経由ではなくプログラム経由のアクセスを優先
  • MCP サーバ — 監査可能なアクション実行
  • 安全な権限モデル — 細かい粒度での認可設計

Karpathy のベンチマークは明快だ。「『MenuGen を作って』とエージェントに指示すれば、手動クリックなしですべてデプロイされる」 状態である。

これは、企業のシステム調達基準が変わることを意味する。SaaS 製品を評価する際に、「GUI が美しいか」ではなく「エージェントが操作できるか」 が新しい基準になる。Anthropic の Model Context Protocol が業界標準として広がる背景も同じ文脈である。詳しくは MCP完全解説近日公開 を参照。

NVIDIA GTC 2026 で発表された OpenClaw／NemoClaw も、まさにこのエージェントネイティブインフラを OS レベルで提供する試みである（NVIDIA GTC 2026 徹底解説 も参照）。プラットフォームベンダーが揃って「次はエージェント実行環境だ」と動いている現状を、企業は IT 戦略に反映する必要がある。

「Ghosts, Not Animals」— LLM の本質を誤解しない

Karpathy がもう1つ強調したのが、LLM の本質を 「動物（biological）ではなく、幽霊（ghosts）」 として捉える視点である。LLM は 「事前学習・事後学習・RL・プロダクトフィードバック・経済的インセンティブによって形作られた統計的シミュレーション回路」 であって、生物のような内発的動機を持つわけではない。

この視点は、AI 導入時の組織内コミュニケーションでも重要だ。「AI に任せれば常識で判断する」という期待は危険である。10万行のコードベースをリファクタリングできる一方で、子供でも分かる推論で失敗する——これが「ジャグド・インテリジェンス」の現実だ。経営層に AI の本質を正しく伝える こと自体が、AI 推進担当者の重要な仕事になる。

その実務的な落とし穴については AIハルシネーション対策の実装論近日公開 と AI定着失敗の典型7パターン も参照されたい。

「Thinking はアウトソースできるが、Understanding はできない」

Karpathy が最も印象的に語ったメッセージがこれである。

「You can outsource your thinking, but you can't outsource your understanding.」 （思考はアウトソースできるが、理解はアウトソースできない）

AI が大量の作業を肩代わりする時代になっても、理解（understanding） は依然として人間にしか担えない。Karpathy が挙げた「人間が引き続き責任を持つべき領域」：

  • テイスト・美的判断
  • システム設計の正しさ
  • 仕様の権威（specification authority）
  • セキュリティ境界と脅威モデリング
  • エージェントが脱線したときに気づく力

具体例として挙げられた MenuGen の 決済バグ が示唆深い：エージェントが「永続的なユーザー ID」ではなく「メールアドレス」で Stripe と Google を紐付けてしまい、別人の Stripe アカウントに支払いが流れる不具合が発生した。これは「ドメイン判断（payment ID の設計原則）」を理解していれば防げたが、エージェントには見えなかった。

企業の AI 推進担当者の仕事は、コード生成の自動化ではなく、「組織のドメイン理解を、AI が活用できる形に言語化する」 ことに移る。

日本企業の AI 推進担当者にとっての含意

以上を踏まえ、Karpathy のフレームを日本企業向けに翻訳する。

(1) 業務マッピングを「検証可能性」軸で再分類する 従来の業務マッピング（営業／マーケ／経理など機能別）に加え、「検証可能性が高いか低いか」軸を持ち込むと、AI 投資の優先順位が明確になる。第1象限（高検証×高価値）の業務から取り組むのが定石である。

(2) 第3象限の業務に「企業独自の検証ループ」を作る 戦略立案・複雑な交渉・新規事業評価といった「LLM が苦手な領域」こそ、自社固有の評価ループを設計 することで競争優位が生まれる。これは外部ベンダーには作れない、組織のドメイン知識資産である。

(3) システム調達基準を「エージェントネイティブ性」で見直す 新規 SaaS や社内システムを導入する際、「Claude や ChatGPT 等のエージェントが操作できるか（MCP 対応・CLI / API 公開）」 を評価軸に追加する。詳しくは 業務AIインフラの技術選定近日公開 を参照。

(4) 人材戦略を「Vibe Coding 大衆化」と「Agentic Engineering 専門化」の両極で組む 全社員のリテラシー底上げ（Vibe Coding を使いこなす）と、専門エンジニアの「天井を上げる」育成（Agentic Engineering を統率する）の両方が必要になる。

(5) 「理解」の組織化に投資する コード生成・タスク実行は自動化できても、「自社業務をなぜそう設計しているのか」という Understanding は組織が育てなければならない。これは AX Boost の FDE型コンサルティング（FDE型コンサルティング完全解説）が現場常駐で支援する核心領域である。

反論・限界 — Karpathy のフレームをどこまで信じるか

Karpathy のフレームは強力だが、無条件に受け入れる前に以下の留保を置きたい。

(1) 「検証可能性」自体の判定が難しい 「契約レビュー」は一見ルールベースで verify できそうだが、契約の文脈や交渉戦略を考えると、verifier 自身がドメイン知識を持つ必要がある。「verify できるかどうか」の判定自体に、専門家の関与が要る場合が多い。

(2) MenuGen は趣味プロジェクト規模の事例 Karpathy の「MenuGen をエージェントが全部デプロイ」というベンチマークは、規模・複雑性が限定的な趣味プロジェクト相当である。エンタープライズの本番システム（数百万行コード、コンプライアンス制約、SLA 要件）にそのまま当てはまるかは別問題だ。本番運用の難しさは AI PoC止まり脱出フレームワーク で論じている。

(3) 日本企業に「カスタム RL 環境」を作る能力があるか 「第3象限はカスタム RL 環境を作れば勝てる」と言うのは易しいが、実際に組むには ML エンジニアリングの深い能力が必要だ。多くの日本企業はそのケイパビリティを持たない。外部パートナーや FDE 型支援の活用、もしくは現実的な妥協（既製モデル＋プロンプト＋人手レビューのループ）の判断が必要になる。

(4) 印刷機類推への懐疑 Karpathy も Boris と同様、印刷機を引き合いに出す傾向がある。ただし コーディング解決後の5論点近日公開 でも論じたように、ソフトウェアの「正しさ」と書字の「読みやすさ」は質が違う。生成された大量コードを誰がレビュー・保守・責任を持つかは、引き続き組織課題である。

まとめ — 「何を verify できるか」を組織の言葉で問い直す

Andrej Karpathy が Sequoia AI Ascent 2026 で示したフレームは、Boris Cherny の「コーディングは解決された」と並んで、2026 年の AI 言説における2つの極を成している。Boris が「自分はもうコードを書かない」と宣言の側であるのに対し、Karpathy は「ではどこまでが解決され、何が残るのか」を 検証可能性 という1つの軸で精密に切り分けた。

日本企業の AI 推進担当者にとって、最も実務的な問いはこれだ。「自社の業務のうち、何が verify できるのか？」。この問いに組織として答えられるかどうかが、AI 時代の競争優位を決める。

AX Boost は、FDE型コンサルティング として、業務の検証フレームワーク設計・第3象限のカスタム評価ループ構築・エージェントネイティブ化への調達基準改訂まで、現場に入り込んで支援している。詳しくは AX支援サービスの選び方近日公開 と AXコンサルティングとは も参照されたい。

主要参考資料