はじめに
GWは、AIから離れて好きな TrySail の動画でも観ようと YouTubeを開いたら、Andrej Karpathy（アンドレイ・カルパシー）さんの新しいインタビュー動画がレコメンドに上がっていました。「バイブコーディングからエージェント・エンジニアリングへ」というタイトル（原題は、"Andrej Karpathy: From Vibe Coding to Agentic Engineering"）。ついつい視聴したらなかなか面白かった（興味深い方）ので備忘録も兼ねてまとめてみます。
ちなみに、日本語のオートダビングもありますので、おススメです！
カルパシーさんといえば、OpenAIの共同創業者の一人で、テスラのAutopilotを率いた人物ですね。更に、「バイブコーディング（vibe coding）」という言葉を世に広めたことでも有名です。そして、最近では、エージェント・エンジニアリングと言っているらしいということは知っていたのですが、何とかエンジニアリングが多過ぎて追えていませんでした。そんな、エージェント・エンジニアリング初見の私の個人的な咀嚼メモです。技術解説というよりはポエムです。気楽に読み流していただければ嬉しいです。
なお、この記事の内容は私個人の感想・解釈であり、所属する企業・団体・組織を代表するものではありません。
また、このブログを公開した後にカルパシーさん自身が対談のハイライトをXに投稿してくれていて、そこでこの動画には大きく3つのテーマがあったことが明かされていました。当初の私の記事ではそのうちの一つ（ギザギザ／エージェント・エンジニアリング）にしか触れていなかったので、抜けていた1つ目のテーマと3つ目のテーマを加筆しました（2026/5/1 10:00）。
LLMは「既存のものの高速化」だけじゃない 〜 3つの新しい地平 〜
カルパシーさんが対談で「最初に押したかった」というのが、このテーマです。LLMの話というと、つい「コーディングが速くなる」「既存の業務が効率化される」みたいな話になりがちですが、彼は 「それはLLMのほんの一側面でしかない」 と強調していました。
新しいパラダイムが来るたびに、目につくのはまず「既存のものをちょっと速く・うまくする」話です。でも本当に面白いのは、 「そもそも今まで存在し得なかった機能」 や 「逆にもう存在しなくていいんじゃないかという機能」 が現れることだ、と。彼が挙げていたのは次の3つの例です。
① MenuGen 〜 LLMに完全に飲み込まれたアプリ 〜
カルパシーさんが開発した MenuGen は、レストランの（文字ばかりの ）メニューを写真に写すだけで、各料理の画像を生成してメニューを視覚化する Web アプリです。
日本だとほとんどのレストラン、飲食店に写真入りのメニューが置かれているのでどんな料理か見れば一目瞭然ですが海外に行くと本当に文字だけのメニューが多いですよね。カルパシーさんも写真があるべきだと思ったみたいです。
このMenuGenは、画像を入力して画像を出力するアプリなわけですが、 もし、これを今の技術で作るなら 古典的なコード（Software 1.0）がほぼ不要 だそうです。LLMがネイティブにその処理を全部こなしてしまう。アプリ全体がLLMに「飲み込まれて」しまってう例ですね。
これまで、画像から画像への変換にはがっつりコードを書く必要があったのに、LLMで完結してしまう プログラムコードとしての アプリが無くなってしまう 例ですね。
② .sh スクリプトの代わりに .md スキルをインストールする
ソフトウェアをインストールするとき、これまでは複雑な bash スクリプト（install.sh）を書いて配布していました。OS の違い、依存関係、エラー処理…と、考えることはたくさんあります。
カルパシーさんはこう言います。
「インストール手順を 自然言語（.md） で書いて、『これをあなたのLLMに見せてね』と言うだけでよくないか？」
LLMは英語（自然言語）の 高度なインタプリタ として機能できるので、ユーザーの環境に合わせてインストールをインテリジェントにターゲティングし、つまずいたらその場でデバッグまでしてくれる。Software 1.0 で何百行ものシェルスクリプトを書いていた営みが、 マークダウン1枚で終わってしまう 可能性があるわけですね。
実際、最近の コーディング・エージェントにはSkillという仕組みがありますし、AGENTS.md みたいな流れもあって、すでに片鱗が見えてきていますよね。私もちょこちょこ Skill を書きますけど、詳細なインストール手順は書きませんし、ポピュラーなソフトウェアなら環境に無かったらインストールしてと書くだけですよね。そこを狙ったサブライチェーン・アタックなんかもあるわけですが....
③ LLM知識ベース 〜 古典的なコードでは原理的に不可能だったもの 〜
3つ目は、①や②とは少し毛色が違って、 「古典的なコードでは原理的に作れなかった」 というタイプの新しい機能です。
LLM知識ベースは、任意のソース・任意のフォーマットの 非構造化データ（知識）に対する計算 をする仕組みです。テキスト記事、PDF、メモ書き、なんでも放り込める。これを古典的なコードでやろうとすると、 そもそも「どうデータを構造化するか」の段階で行き詰まります 。
①と②が「もう存在しなくていいんじゃないか」というタイプの新地平だとすると、③は 「ずっとやりたかったけど不可能だった」 タイプの新地平。LLMがあって初めて成立する機能ということですね。
ここでカルパシーさんが言いたかったのは、 「LLM＝既存業務の高速化ツール」というフレームだけで見ていると、本当に面白いところを見逃すよ ということなんでしょう。コーディングが速くなる話は、入口に過ぎないわけです。
ギザギザな知能 〜 10万行リファクタできるのに洗車場まで歩けと言うAI 〜
動画の中で私が一番声に出して笑ってしまったのが、この話です。
カルパシーさんは、最新のフロンティアモデルが示す「能力のムラ」を ジャギッド（jagged）な知能 と呼んでいます。日本語にすると「ギザギザした知能」という感じでしょうか。
その代表例として、こんな話を紹介していました。
「最先端のOpus 4.7は、10万行のコードベースをリファクタリングしたり、ゼロデイ脆弱性を見つけたりできる」
「同時に、 『50メートル先の洗車場に行きたい。歩くべきか車に乗るべきか？』と聞くと、最先端のモデルが『近いから歩いてください』と答える 」
50メートル先で洗車してもらうのに歩いていったら、その間あなたの車はどこにあるんですか、という話ですよね。
ちなみに本当かなと思って、Cluade Desktop でモデルを Opus 4.7 にして同じ質問をしてみました（日本語で聞いちゃいましたが）。
車で行きましょう。洗車場に着いたらそのまま車を洗えますし、50メートルなら歩くのと運転するのとで時間もほぼ変わりません。歩いて行ったら、車を洗うために結局取りに戻ることになります 🚗
うちの子はちゃんと答えてくれました（まー、そんなもんですよね）。
それはさておき、このようにある領域では人を超えるような能力があるのに別の領域ではポンコツになることを彼は、ギザギザな知能（jagged intelligence）と呼んでいます。
なぜこんなことが起きるのか。カルパシーさんは、2本柱で説明 しています。 検証可能性（verifiability） と 経済（economics） の二つです。
柱①：検証可能性（verifiability）
強化学習が大規模に行われた領域か、そうでないかで説明できるってことなんですね。 強化学習を大規模に回すためには、モデルの出力に対して報酬を自動的に与える仕組み（報酬関数）が必要です。つまり、問題の正誤が自動的に検証可能である必要があります。 そのため、数学やコーディングのような自動的な検証が可能な領域では膨大な強化学習を行える環境を構築することができて、LLMは優れた能力を獲得できています。でも、正誤判定が曖昧な領域では十分な強化学習が行われていないため低い能力に留まっているということなんですね。なるほど。
柱②：経済（economics） 〜 売上・TAMが学習データ分布を決める 〜
そして、彼が後日の投稿でより整理された形で紹介した2つ目の柱です。
「フロンティアラボがRL時にどんな訓練データ分布をパッケージするかは、 収益やTAM（市場規模） によって決まる」
要するに、 検証可能性の問題をクリアできた領域の中でも、さらに「ビジネスとしてやる価値があるか」でラボが取捨選択している ということですね。コーディングは検証可能で、なおかつ巨大なTAMがあるから、フロンティアラボは全力でRLを回す。
その結果、こんな比喩が登場します。
「あなたが訓練データ分布の中にいれば（RL回路のレールに乗っていれば）飛ぶように進める。 そこから外れたら、ジャングルでマチェーテ（なたの大きなもの？）を振りながらオフロード走行する ことになる」
私たちが「あれ？このタスクなんでこんなに苦手なの？」と感じる瞬間は、たぶん マチェーテ振り回しゾーン に踏み込んでいるんですね。
さらに、というかこっちが面白いと思ったのは、彼がもう一つ強調していた点です。 「価値が高い領域だから磨かれる」 だけでなく、 「ラボの誰かが面白がって・気合を入れてその分野のデータを混ぜたから磨かれる」 というケースもある、と。
具体例として、GPT-3.5からGPT-4にかけてチェスの能力が大きく上がったことに触れていました。これは自然な成長ではなく「OpenAIの誰かがチェスのデータを大量に事前学習に混ぜると決めたから」だと（これは公開情報だそうです）。
日本のアニメ風の絵が得意なモデルがありましたね～
私たちが日常的に「AIって◯◯は得意だけど△△はびっくりするほどポンコツだよね」と話すあの違和感には、ちゃんと理由があったのだと、すごく納得感がありました。この話を聞くまでは学習データの量の違いで納得しようと思ってましたがちょっと違和感あったんです。
ちなみに、カルパシーさん自身も「このギザギザの説明モデルは まだ100%満足のいくものではなく、現在進行形で組み立てている最中 だ」と認めています。LLMの能力の正確なメンタルモデルを作るのは、なかなか終わらない格闘戦のようですね。
バイブコーディング vs エージェント・エンジニアリング
そしていよいよタイトルの本題、 エージェント・エンジニアリング の話です。
カルパシーさんはこの2つを、こう対比しています。
バイブコーディング 〜 底上げ 〜
バイブコーディングは、 「誰でもソフトウェアを作れる」という底上げ です。これまでコードを書けなかった人が、雰囲気でアプリを作れるようになる。これはとても素晴らしいことですし、世界を広げる動きです。
エージェント・エンジニアリング 〜 品質基準を保つもの 〜
一方で、プロが書くソフトウェアには品質基準があります。脆弱性を入れてはいけないし、責任を負うのは依然として人間です。バイブコーディングの勢いのまま本番システムを作ったら事故るのは目に見えていますね。
「エージェント・エンジニアリングとは、これらのスパイキー（とがった、ギザギザな）エージェントたちを、品質を犠牲にせずにどう オーケストレーション して速度を出すかという、 エンジニアリング規律 だ」
エージェント・エンジニアリングはギザギザな知能と表裏一体の概念 だったんですね。バイブコーディングがとんでもなく便利な一方で胃が痛くなるようなことがあるのもこのギザギザに原因があると、そして、それを補うのがエージェント・エンジニアリングなんですね。
エージェント・エンジニアリングで具体的にどうやって品質基準を保つのかという話はこの動画の対談では出てこなかったようです。次の「10倍エンジニアでは足りない時代」に少しヒントがあるかもしれません。
「10倍エンジニア」では足りない時代
過去には「10倍生産性のエンジニア（10x engineer）」という言葉が使われていたそうです。私はこの言葉は知りませんでしたが、一人で10人分の仕事をするスーパーエンジニアですね。
カルパシーさんは動画でさらりとこう言っています。
「エージェント・エンジニアリングが本当に上手な人は、たぶん10xどころじゃない」
10xでは表現しきれない生産性の差が、これから個人の間に生まれていく、という話です。既にそんな予感はありますよね。
仕事でも ChatGPT に挨拶しただけで止まっている人と、Claude Code やCodex でトークン溶かしまくっている人、全然違いますよね、会話する時、コンテキストの切り替えが大変です。
ではその差は何で決まるのか？
- 自分のセットアップに投資すること（昔のエンジニアがVimやVSCodeを磨き込んだのと同じ感覚）
- 利用可能なツールの機能をフル活用すること
- 大きなプロジェクトを丸ごとAIに任せて回せること
- AIが書いたコードを「壊しに来る別のAI」を使ってセキュリティを検証できること
最後の「AIに書かせて、別のAIに攻撃させる」発想は、もう完全にギザギザな知能を前提としたエンジニアリングですね。 AIの強みを使って、AIの弱みを補う という。
LLM 自体をエージェント・エンジニアリングがいらないように強化学習できるのか？
カルパシーさんは、ある程度できると言っているように感じました。彼は、「RL環境を増やせば、コード品質や美的センスのギザギザも埋められるはず。ただラボがまだそこに手をつけていないだけ」とか「最終的にはほぼ何でも検証可能にできると思う」と言っていました。とはいえ、現時点ではまだ埋まっていないので、当面は人間がエージェント・エンジニアリングで補う必要があるという感じですね。
あとは、なぜそれを作るの？みたいなところですね。これは強化学習の報酬関数を作れるのかな？....
エージェント・ネイティブな経済（agent-native economy）
そして、対談の最後のテーマがこの エージェント・ネイティブな経済 です。私の当初記事では書ききれていなかったのですが、ここはカルパシーさんらしい未来像が詰まっていて面白かったので加筆します。
製品やサービスを「センサー／アクチュエータ／ロジック」に分解する
カルパシーさんは、これからの製品・サービスは センサー（情報を取り込む部分）／アクチュエータ（外界に作用する部分）／ロジック（判断する部分） の3つに分解して考えるべきだ、と言います。そしてその各パーツが、 Software 1.0（古典コード）／2.0（ニューラルネット）／3.0（LLM）の3つのパラダイムに分散して実装される 世界観です。
これまでアプリは「全部1.0で書く」のが当たり前でしたが、これからは「ここはLLMに任せ、ここはニューラルネット、ここは古典コード」という3層ハイブリッドが普通になっていく、ということですね。
LLMにとって情報を「読みやすく（legible）」する
エージェント・ネイティブな世界では、 「LLMにとって情報がどれだけ読みやすいか（legibility）」が決定的に重要 になります。人間用のUI（GUIや動画）はLLMから見るとノイズが多くて読みにくい。これからの製品・ドキュメント・APIは、 LLMが理解しやすい形に整える ことが、競争力に直結していく、と。
.sh を .md にする話とも繋がりますね。LLMにとって情報がどれだけ素直に届くかが、エージェント時代の勝負どころになるわけです。
採用とエンジニアリングのスキルセットも変わる
エージェント・エンジニアリングというスキルセットが急速に立ち上がっていて、 採用や人材戦略にも影響を与え始めている とカルパシーさんは話していました。「10xではすまない」生産性の差が出るというのも、ここに繋がってきます。
そして、フルニューラル計算という夢
最後にカルパシーさんが匂わせていたのが、 「ほぼ全ての計算がニューラルで行われ、古典的なCPUはコプロセッサとして補佐する」 という未来像です。
これは衝撃的なビジョンで、これまで「ニューラルネットはCPUの上で動くアプリから呼ばれる存在」だったのが、 主従が逆転する ということですよね。CPUが「補助役」になる世界。
「夢」「ヒント」レベルの話とは言っていましたが、 Software 3.0（LLM中心）が当たり前になった先には、計算機アーキテクチャ自体が再定義される という壮大な絵を描いている。さすがカルパシーさんという感じです。
まとめ
- AIの能力はギザギザしている。だから「ここはAIに全振り、ここは人間が必ず見る」という線引きが、これからのエンジニアリングの中心的な仕事になる
- 「バイブコーディング」と「エージェント・エンジニアリング」は対立概念ではなく、 役割が違う 。「バイブコーディング」は底上げで、誰もがコーディングできるようにしてくれる。ところが能力がギザギザでムラがある、後者はこのギザギザを補って、品質基準を保つ。
- ラボ（AIを作っている企業など）がどの領域の強化環境を整備したかで、AIの強み・弱みが決まる。だから「自分の領域はAIにとって得意か不得意か」を見極める観察眼が、ビジネス側の人間にも必要
最後までお読みいただきありがとうございました。元の動画もぜひご覧ください。30分弱です。では！
Andrej Karpathy: From Vibe Coding to Agentic Engineering（YouTube）