AI、特に大規模言語モデル（LLM）の登場は、ソフトウェア開発の世界に大きな変化をもたらしています。
Y Combinator AI Startup SchoolでのAndrej Karpathy氏の講演「Software in the era of AI」では、この変化の本質と、エンジニアがどのように新しい機会を捉え、課題に取り組むべきかについて、深い洞察が示されました。ソフトウェアの進化は、人間が直接コードを書く「Software 1.0」、ニューラルネットワークの重みがプログラムとなる「Software 2.0」を経て、現在はLLMを自然言語プロンプトで操作する「Software 3.0」という新しい段階に入っています。
この新しいパラダイムは、開発のあり方を根本から変え、プログラミングの専門知識がない人々でもアイデアを形にできる「Vibe Coding」のような新しい開発スタイルを生み出す可能性を秘めています。しかし、LLMは万能ではなく、その特性を理解し、人間とAIが効果的に協調する仕組みを構築することが、これからのソフトウェア開発において非常に重要になります。
この記事では、Karpathy氏の講演内容を基に、ソフトウェア開発エンジニアが知っておくべきLLM時代の変化と機会について、具体的なポイントを解説します。
動画の内容超要約
- ソフトウェア開発はAI、特にLLMによって根本的に変化している。エンジニアは新しいツールと開発パラダイムへの適応が急務。
- ソフトウェアの進化は3段階: 1.0 (コード)、2.0 (重み)、3.0 (プロンプト)。Software 3.0はプログラミングの概念を拡張し、自然言語が新たなインターフェースとなる。
- LLMは新しい種類のコンピュータであり、ユーティリティ、Fab、OSのような特性を持つ。LLMの経済性、開発体制、プラットフォームとしての可能性を多角的に理解する必要がある。
- LLMには特有の「心理学」（幻覚、ギザギザの知性、前向性健忘、騙されやすさ）がある。LLMの出力を盲信せず、その限界を補う設計と検証プロセスが不可欠。
- 主な機会は「部分的な自律性アプリ」と「エージェント向けインフラ/ドキュメント」。人間とAIの協調を前提としたUI/UX設計や、LLMエージェントが利用しやすいサービス設計にビジネスチャンスがある。
- 「Vibe Coding」はプログラミングの民主化を促進するが、DevOpsの重要性は残る。アイデアの具現化は容易になるが、製品化には依然としてエンジニアリングの専門性が求められる。
- 人間とAIの協調ループの高速化と、AIの適切な制御（短いリードで保つ）が重要。AIの能力を最大限に引き出しつつ、リスクを管理するバランス感覚が開発者に求められる。
ソフトウェア進化の3段階とLLMの登場
Software 1.0：伝統的なコードによる開発
ソフトウェア開発の初期段階から続く、人間がプログラミング言語を用いてコンピュータに直接的な指示を与える伝統的な手法です。エンジニアはC++、Java、Pythonなどの言語を使い、アルゴリズムやロジックを明示的に記述します。このアプローチの利点は、システムの動作が予測可能で、ロジックが明確であることです。代表的なプラットフォームとしてGitHubが挙げられ、多くのコード資産が蓄積・共有されてきました。しかし、自然言語の曖昧なニュアンスの理解や、複雑な現実世界のパターン認識といったタスクには限界がありました。
Software 2.0：ニューラルネットワークと重みによる変革
Software 2.0は、ニューラルネットワーク、特にその「重み（weights）」がプログラムそのものとして機能するという考え方です。エンジニアは、大量のデータセットを用意し、最適化アルゴリズム（例：バックプロパゲーション）を実行することで、ニューラルネットワークのパラメータを調整します。これにより、画像認識モデル（例：AlexNet）や音声認識モデルのように、従来のSoftware 1.0では実現が難しかったタスクを実行するプログラムが学習によって生成されます。HuggingFace Model Atlasのようなプラットフォームは、これらの学習済みモデルが共有され、再利用されるエコシステムの中心となっています。この段階では、データサイエンスや機械学習のスキル、そして大量のデータを扱う能力がエンジニアにとって重要になりました。
Software 3.0：LLMとプロンプトによる新時代
そして現在、大規模言語モデル（LLM）の登場により、ソフトウェア開発は「Software 3.0」という新しいパラダイムに突入しています。LLMは、それ自体が非常に強力で汎用的なプログラム可能なニューラルネットワークであり、人間は自然言語（主に英語）による「プロンプト」を通じてLLMに指示を与え、望む情報処理やコンテンツ生成を行わせることができます。これは、LLMが新しい種類の「コンピュータ」として機能し、プロンプトがそのコンピュータを操作するための新しい「プログラミング言語」と見なせることを意味します。この変化は、ソフトウェア開発の敷居を劇的に下げ、より多くの人々がソフトウェアを作成できるようになる大きな可能性を秘めています。
LLMの多面的な特性：エンジニアが理解すべきアナロジー
LLMは社会インフラ：ユーティリティとしての側面
LLMサービスは、電力供給のような社会基盤（ユーティリティ）としての特性を持っています。開発・訓練には巨額の初期投資（CAPEX）と継続的な運用コスト（OPEX）がかかり、多くはAPI経由でトークン数などに応じた従量課金で提供されます。ユーザーからは低遅延、高可用性、一貫した品質が求められ、サービスダウンは「知性のブラウンアウト」とも言える広範囲な影響を及ぼします。OpenRouterのようなサービスは、複数のLLMプロバイダーを切り替えて利用することを可能にし、電力系統の切替スイッチのような役割を果たします。
LLM開発は最先端工場：Fabとしてのアナロジー
最先端LLMの開発は、高度な技術と莫大な資本を要する半導体工場（Fab）の運営に例えられます。訓練には莫大な計算資源が必要で、その技術（アーキテクチャ、訓練データ、訓練手法）は深い専門知識と研究開発を要し、多くが企業秘密とされています。NVIDIA GPUを利用するファブレスモデルと、GoogleのTPUのような垂直統合モデルが存在する点も半導体産業と類似しています。
LLMは新しいOS：プラットフォームとしての可能性
Karpathy氏が特に強調するのが、LLMを新しい種類のオペレーティングシステム（OS）として捉える視点です。LLMは単なるAPIではなく、WindowsやmacOS、Linuxのように、それ自体が複雑な機能を持ち、多様なアプリケーションがその上で動作するプラットフォームとしての性格を強めています。LLM（CPUに相当）がコンテキストウィンドウ（RAMに相当）を管理し、ビデオ入力、オーディオ出力、ブラウザアクセス、他のLLM連携などを周辺機器としてオーケストレーションするイメージです。オープンソースモデルの登場により、ソフトウェアとしての柔軟性も高まっていますが、異なるLLM間には機能やAPI仕様の違いによる「スイッチングフリクション」も存在します。
LLMの「心理学」：人間らしさと付き合い方
LLMの人間的な認知特性と課題
LLMは人間が生成したテキストで学習するため、人間のような認知特性やバイアスを持つことがあります。これを「LLMの心理学」と呼び、その理解が効果的な活用の鍵となります。
- 百科事典的な知識/記憶: 映画『レインマン』の主人公のように、LLMは膨大な情報を記憶し、人間一人では持ち得ない知識を提示できます。
- 幻覚 (Hallucinations): 事実ではない情報をもっともらしく生成することがあり、ファクトチェックが不可欠です。
- ギザギザの知性 (Jagged intelligence): 特定のタスクでは超人的ですが、簡単なタスクで間違いを犯すことがあります（例：「strawberryに’r’はいくつ？」）。
- 前向性健忘 (Anterograde amnesia): コンテキストウィンドウがワーキングメモリに相当し、継続的な学習や「睡眠」による知識の長期的な定着がありません。映画『メメント』や『50回目のファーストキス』に例えられます。
- 騙されやすさ (Gullibility): プロンプトインジェクション攻撃に脆弱であり、入力のサニタイズや出力の検証が必要です。
これらの特性を理解し、LLMの出力を盲信せず、その限界を補う設計と検証プロセスを組み込むことが、エンジニアにとって重要です。これは、従来のソフトウェア開発とは異なる、新しい種類のエンジニアリングと言えます。
LLM時代の開発機会：部分的な自律性とエージェント志向
部分的な自律性を持つLLMアプリの設計
多くの実用的アプリケーションでは、AIが完全に自律するのではなく、人間とAIが協調する「部分的な自律性」が鍵となります。AIが生成（Generation）し、人間が検証（Verification）するループを高速化することが重要です。これには、ユーザーがAIの自律度を調整できる「自律性スライダー」（例：CursorやPerplexity）や、AIの提案を効率的に評価できるカスタムGUI（例：コード差分の視覚的表示）の設計が求められます。人間が常にループの中心にいて、AIを賢く監督・指導できるシステムが理想です。
エージェント向けインフラとドキュメントの構築
LLMエージェントは、人間や従来のコンピュータプログラムとは異なる、新しいタイプの情報消費者です。現在のウェブサイトやドキュメントは人間向けに最適化されていますが、LLMエージェントが情報を効率的に取得・活用するためには、より構造化され、機械可読性の高い形式で情報を提供する必要があります。例えば、VercelやStripeは実験的にllms.txt（robots.txtのLLM版）やマークダウン形式のドキュメントを提供し始めています。また、人間向けの「クリック」操作ではなく、エージェントが実行可能なAPIエンドポイント（cURLコマンドで表現されるようなもの）の提供が重要になります。AnthropicのModel Context Protocol (MCP)のような標準化の動きも注目されます。
Vibe Coding：プログラミングの新しい形
LLMの登場により、厳密なプログラミング知識がなくても、「雰囲気」や「意図」を伝えることでコードを生成できる「Vibe Coding」が可能になりました。Karpathy氏自身も、Swiftの経験がほとんどないにも関わらず、LLMを使って簡単なiOSアプリ「MenuGen」（https://www.menugen.app/）を開発した経験を共有しています。これによりソフトウェア開発の敷居は下がりますが、実際の製品化にはLLM APIキー管理、外部API連携、デプロイ、認証、支払いといったDevOps作業が依然として重要であり、Karpathy氏は「コードは最も簡単な部分だった」と述べています。この新しい開発スタイルは、アイデアの迅速なプロトタイピングや、非専門家の開発参加を促進する一方で、エンジニアリングの専門性の重要性を再認識させます。
以下の表は、Karpathy氏が「Vibe Coding」でMenuGenを開発した際に、コード記述（LLMが主に担当）と、それ以外のDevOps的作業（人間が主に担当）の難易度を比較したものです。
| タスク | 主な担当 | Karpathy氏の体感難易度 |
|---|---|---|
| LLM APIキーの管理 | 人間 (DevOps) | 😊 (比較的容易だが手間) |
| Flux (画像生成) APIキーの管理 | 人間 (DevOps) | 🤔 (やや手間) |
| ローカルでの実行 | LLM / 人間 | ✅ (容易) |
| Vercelへのデプロイメント | 人間 (DevOps) | 😥 (困難) |
| ドメイン名の設定 | 人間 (DevOps) | 😥 (困難) |
| 認証 (Clerk) | 人間 (DevOps) | 😥 (困難) |
| 支払い処理 (Stripe) | 人間 (DevOps) | 😥 (困難) |
| アプリケーションのコアロジック (コード) | LLM (Vibe Coding) | 😮 (最も容易な部分) |
この経験は、LLMがコード生成を助ける一方で、アプリケーションを実際に機能させるための周辺作業の重要性が相対的に高まることを示唆しています。
