著者:副業の宮殿|製造業に携わる現役エンジニア。技術士試験対策書籍をKindleで複数出版。技術ブログ「副業の宮殿」にて製造業DX・AI活用の情報を発信中。
Andrej Karpathyのポッドキャスト・YouTube動画「Andrej Karpathy on Code Agents, AutoResearch and the Loopy Era of AI」を視聴した。正直、序盤の10分で何度か手を止めた。「あ、これ時代が変わってるやつだ」という感覚が何度も来たからだ。 Karpathyと言えば、元OpenAIの研究ディレクターにして、スタンフォードのCS231n(深層学習の名講義)を作った人物。現在はソロ研究者として活動しており、その発言は業界の「少し先の地図」を示していることが多い。今回の動画もそうだった。単なるAI賛美でも技術解説でもなく、「今起きている変化の構造」を淡々と語る内容だった。 本記事では、この動画の内容を日本語で整理しながら、「なぜこれが重要なのか」「自分たちの開発にどう影響するか」を考察する。

「最近ほとんどコードを書いていない」——その一言の重さ

動画の中でKarpathyが言った言葉の中で、最も衝撃的だったのはこれだ。
「最近はほとんどコードを書いていない。Claude CodeやCodex的なエージェントを複数動かして、自分はレビューと方向付けをしている」
この発言をサラッと聞き流してしまうと大事なものを見逃す。Karpathyは「AIがコードを書いてくれるから楽になった」と言っているのではない。もっと根本的なことを言っている。 「AIが補助している」のではなく、「人間がAIチームを運営している」という感覚になっている、と言っているのだ。 この違いは大きい。補助ツールなら人間が主体であり、AIは「道具」だ。しかし「チームを運営している」という感覚は、自分が「プレイヤー」ではなく「マネージャー」になっていることを意味する。実装はAIがやる。自分は「何を作るか」「どのアプローチか」「この出力は正しいか」を判断する役割になっている。 これは「ソフトウェア開発」という概念の根底が変わりつつあることを示唆している。今後エンジニアに求められるスキルの中心は、「コードを書く能力」から「AIへの指示能力・タスク分解能力・評価能力」へとシフトしていくかもしれない。Claude Codeを毎日使っている人なら、この感覚の萌芽を既に感じているはずだ。「あ、これだとコード書くより指示を練る方に時間使うな」という瞬間が、確実に増えてきている。

AI Psychosis——「自分がボトルネックになる」という新しい感覚

Karpathyはこの感覚に「AI Psychosis(AI精神症)」という言葉を使った。やや過激な表現だが、内容は共感できる。 かつてのAI開発のボトルネックはGPUだった。「計算資源が足りない」「学習が終わらない」「推論が遅い」——そういう制約の中で人間は待ち続けた。しかし今、状況が逆転しつつある。 AIエージェントは24時間動き続けられる。複数並列で動かせる。疲れない。コーヒーも要らない。コードを書く速度は人間の数十倍だ。そしてある瞬間、気づく。「AIはもっと速く動けるのに、自分の指示が追いつかない」と。 AIが「次のタスクを待っている」状態になり、人間が判断・指示・評価を絞り出す側になる——この感覚こそがAI Psychosisだ。昔は「GPUが足りない」と焦っていた。これからは「自分の判断が足りない」と焦る時代になるかもしれない。 Claude Codeを実際に使っていると、この感覚は既にうっすらと始まっている。「あ、こっちの考えを整理するのが遅いせいでClaudeを待たせてる」という感覚。これが今後さらに加速する、というのがKarpathyの見立てだ。

AutoResearch——「AIが自分より良いパラメータを見つけた」という事件

AutoResearchの話は特に面白かった。これはKarpathyが取り組んでいる研究スタイルで、AIエージェントに「研究ループ」を自律的に回させるというものだ。 通常の研究プロセスはこうだ。研究者が仮説を立て、コードを書き、実験し、結果を評価し、良い変更だけ残す。これを何百回も繰り返す。一人の研究者にできる実験の数は、1日に数回〜数十回が限界だ。 AutoResearchはこのループをAIが回す。しかも並列で、24時間休まず。Karpathyが言っていたのは、このAutoResearchが「自分が考えつかなかったパラメータ設定を見つけた」という体験だ。 人間の研究者は経験と直感で「このパラメータはおそらくこの範囲」と仮説を持つ。その範囲内で丁寧に探索する。しかしAIは「おそらくこの範囲」という思い込みがない。人間なら「なんでそこを試すの?」と思うような場所を探索する。そして時に、その「なんで?」の場所に正解があったりする。 これは「専門家の直感 vs 無限の組み合わせ探索」という構図だ。人間の専門家は経験で探索空間を絞り込む。これは効率的だが、思い込みにもなる。AIは探索空間を絞り込む「常識」を持たない。その「常識のなさ」が、時に人間を超える発見につながる。AlphaGoがプロ棋士の「常識的な一手」ではなく、棋士が「変な手」と感じる一手で人間を超えていったことと、構造が似ている。

Loopy Era——AIが「考える→試す→評価する」閉ループになっていく

「Loopy Era(ループの時代)」というKarpathyの言葉は、LLMの本質的な変化を表している。 従来のLLMは、シンプルな「入力→出力」だった。質問を入れたら答えが出る。一回勝負のフォワードパスだ。優れているが、「試行錯誤しながら改善する」という能力はなかった。 これからのAI(すでに始まっているが)は違う。考える→試す→評価する→改善する→再挑戦する、という「閉ループ」を自律的に回し続ける。一回の出力で終わらず、自分で自分を改善し続ける。 AlphaZeroを思い出してほしい。AlphaZeroは人間の棋譜データを一切使わず、自分自身と対局するセルフプレイのループを回し続けることで、数日で人類最強の棋士を超えた。このループ構造こそが、AlphaZeroの本質的な強さだった。Karpathyが「Loopy Era」と呼ぶ時代は、この「ループ」をコード生成・研究・設計・実験のあらゆる領域に適用し始めた時代だ。 重要なのは、ループの中に「現実のフィードバック」が入ってくることだ。コードを書いたらテストを実行する。テストが落ちたら修正する。修正したらまたテストする。この「コード生成→実行→評価→修正」のループがAI側で閉じることで、人間の介入なしに完成度が上がっていく。Claude Codeがまさにこれをやり始めている。

「アプリが消える」——AI Native OSという未来

Karpathyが語ったスマートホームの話は、未来のUI像を端的に示していた。スマートホームのデバイスを操作するために、照明アプリ・空調アプリ・音楽アプリ・セキュリティアプリ……と複数のアプリを使い分けることが、すでに面倒くさくなってきた、という話だ。 理想は「部屋を映画モードにして」と言えば、照明・空調・音響・カーテンが自動で適切な状態になること。この「自然言語での意図伝達→適切なAPIの実行」という構造では、アプリという中間レイヤーは邪魔になる。 Karpathyが描く未来の構造はこうだ。
  • 従来:人間 → アプリUI → サービス
  • 未来:人間 → AI → 各種API(直接)
アプリは「人間とAPIの間のGUIブリッジ」だった。しかし人間が自然言語でAIと話し、AIが適切なAPIを呼ぶなら、GUIブリッジとしてのアプリは不要になる。あるいは、AIが状況に応じて必要なUIを動的に生成する形になる。 これはMCP(Model Context Protocol)の思想とも一致する。MCPはAIが外部ツール・APIをツールとして使う仕組みだ。個別のアプリを経由せず、AIが直接ツールを呼ぶ——この設計思想は「アプリの概念の終わり」の始まりかもしれない。「AI Native OS」という言葉がリアルに感じられてきた。

MulmoClaude的世界観との一致——動的GUI生成という考え方

Karpathyが描くAI Native Futureと、MulmoClaude的な世界観は驚くほど一致している。 MulmoClaude的な世界観とは、AIを中心に置いたシステム設計だ。人間がAIに意図を伝え、AIが状況に応じてGUIやAPIを動的に組み合わせる。Tool Use、長期記憶、複数エージェントのオーケストレーション——これらを組み合わせることで、固定的なアプリUIではなく「その瞬間の目的に最適化された動的なインターフェース」が生成される。 従来のソフトウェア設計では、まずUIを設計し、そのUIに従ってユーザーが操作する。UIは固定されており、ユーザーがUIに合わせる。しかしAI Native設計では逆転する。ユーザーが意図を伝え、AIがその意図に合わせてUIとAPIを動的に組み立てる。 これが実現すると何が変わるか。「このアプリの使い方を覚える」という概念が消える。「ここのメニューを開いて、この設定を変えて……」という手順を記憶しなくていい。「〇〇したい」と言えば、AIが最適な手順で実行してくれる。ユーザーは「目的」だけ持てばいい。 Karpathyの「アプリが消える」という話は、この動的UI生成の世界観を別の角度から語っていたのだと思う。

ロボティクスへの影響——「デジタルは速いが、ロボットは遅い」

Karpathyが言った「デジタル世界は速いが、ロボットは遅い」という指摘は、ロボティクス研究者にとって非常にリアルな話だ。 ソフトウェアのAIエージェントなら、1秒で何百回もの計算ループを回せる。AutoResearchで一晩に何千もの実験を試せる。しかしロボットは違う。物理世界は遅い。センサーのノイズがある。アクチュエータには遅延がある。摩擦があり、転倒があり、安全上の制約がある。何より、「試してみる」コストが高い——1回の実験が失敗するとロボットが壊れるかもしれない。 これがロボティクスAIの進化がデジタルAIより遅い根本的な理由だ。DeepMindがAlphaGoで人間を超えるまで数年かかった一方、物理世界で動くロボットはまだ人間の動作の精度・汎用性に遠く及ばない。 しかし逆に見ると、これはロボティクスが「AIにとって巨大な未開拓領域」であることを意味する。デジタル世界ではすでにAIが人間を超え始めている。物理世界はこれからだ。シミュレーションと現実のギャップ(Sim-to-Real gap)を埋める技術、少ないデータから素早く学習するFew-Shot学習、不確実な環境でロバストに動くプランニング——これらの課題を解決したとき、ロボティクスは「第二のAI爆発」を起こす可能性がある。

SCOUTロボット研究との接点——「Physical Claude Code」という発想

この動画を見て、個人的に一番興奮したのは、自分が研究しているSCOUTロボットの研究スタイルとKarpathyの話が深く重なると感じた点だ。 SCOUTロボットの研究では、Teach & Repeat(経路を教えてから繰り返し走行させる)やVPR(Visual Place Recognition、画像で場所を認識する)、状態監視、service callベースの制御インターフェースといった技術を扱っている。そしてAutoResearch的な考え方との接点が見えてきた。 例えば、VPRのパラメータチューニング。特徴抽出の手法・マッチングの閾値・記憶画像のサンプリング間隔——これらを人間が経験則で決めてきた部分を、AIエージェントが実験ループを回しながら自動的に最適化できるかもしれない。Karpathyの「AutoResearchが自分より良いパラメータを見つけた」という体験が、ロボットのナビゲーションパラメータ最適化でも起きる可能性がある。 さらに面白いのは「service callベース制御」との相性だ。ROS(Robot Operating System)のservice callは、MCP的なTool Useと本質的に同じ構造を持つ。「AIエージェントがROSのserviceを直接呼んでロボットを操作する」——これはまさに「Physical Claude Code」と呼べるような発想だ。
  • デジタルClaude Code:コードを書く→実行する→テストする→修正する(ループ)
  • Physical Claude Code:行動を計画する→ロボットに指示する→センサーで評価する→修正する(ループ)
LoopyなAIエージェントが物理世界の閉ループ制御と融合したとき、ロボティクス研究の進め方は根本から変わるかもしれない。「研究者がパラメータを調整する」のではなく、「AIエージェントが自律的に実験を繰り返して最適解を探す」——そのループにロボットの物理動作が含まれる未来が見えてきた。

一番本質的だったこと——「コードを書く」から「AI組織を運営する」へ

動画全体を通じて、最も衝撃的だったのはKarpathyのこの変化だ。 かつて(2〜3年前):コードを書く人間 → AIが補助 今(Karpathyの現在):AIチームを運営する人間 → AIが実装 この変化は単なる「ツールの変化」ではない。仕事の性質そのものが変わっている。コードを書く能力は、農業社会における「耕作技術」のようなものだった——産業革命で耕運機が来るまでは、それが主要スキルだった。今、コーディングに「耕運機」が来ている。 これからエンジニアに求められる能力は何か。Karpathyの話から読み取ると、こうなる。
  • AIへの指示能力:何をやるべきかを的確に言語化し、AIに伝える能力
  • タスク分解能力:大きな目標を、AIが実行可能な小さなタスクに分解する能力
  • 評価能力:AIのアウトプットが正しいかを判断する能力(これにはドメイン知識が必要)
  • 実験設計能力:何を試せば有益な情報が得られるかを設計する能力
  • オーケストレーション能力:複数のAIエージェントを適切に組み合わせて目標を達成する能力
面白いことに、これらのスキルは「優秀なマネージャー・リサーチャーに必要なスキル」と大きく重なる。「何をすべきかを定義する力」「チームの成果を評価する力」「実験を設計する力」——これらは元々、優秀なエンジニアが「コードを書く技術」の上に持っていたメタスキルだった。AIが台頭することで、このメタスキルの重要性が一気に前面に出てきた。 AIは「ツール」を超えて「チームメイト」になり始めている。そして「チームメイトを持つこと」の意味も変わり始めている。24時間働き、疲れず、複数並列で動き、自分でループを回して改善し続けるチームメイト。これと一緒に仕事をするとは、どういうことか。 Karpathyが「最近ほとんどコードを書いていない」と言った瞬間、その問いがリアルに迫ってきた。自分はこの変化に対して、何を準備すべきか——そう考え始めたのが、この動画を見た後の正直な感想だ。

まとめ——Loopy Eraは既に始まっている

Karpathyが語った「Code Agents・AutoResearch・Loopy Era」は、遠い未来の話ではなかった。Claude Codeを毎日使っている人なら、その「始まり」を既に体感しているはずだ。 重要な変化を整理すると:
  • AIは「補助ツール」から「実装担当のチームメイト」になりつつある
  • 人間のボトルネックは「GPUの遅さ」ではなく「自分の指示・判断の速度」になりつつある
  • AIが閉ループで自律改善するLoopy Eraが来ると、探索空間の広さが競争優位になる
  • アプリというUIレイヤーは「AI→API直結」に置き換わっていく可能性がある
  • ロボティクスはデジタルAIの次の大きなフロンティアだ
最後に、Karpathyの言葉で一番記憶に残ったものを引用して終わりにしたい。
「AIエージェントは間違えるし、ハルシネーションする。でも人間も間違える。重要なのは、AIを管理・評価・修正するシステムを作ることだ」
AIが「チームメイト」になる時代、必要なのはAIを盲信することでも恐れることでもなく、「AIと一緒に働くためのシステム設計能力」だ。それは古くて新しい、エンジニアとしての本質的な能力だと思う。