Software 3.0 とは — AI 時代のプログラミング・パラダイムとエンジニアの新しい役割

Andrej Karpathy が 2025 年に提唱した Software 3.0 という言葉が、エンジニア界隈で急速に広まりました。「ソフトウェアを書く」という行為そのものの定義が変わる、という主張です。

本稿では Software 1.0 / 2.0 / 3.0 の違い、Software 3.0 が 2025-2026 年に実装可能になった理由、エンジニアに求められる新しい役割 を整理します。Claude Code や Codex の実運用の観点から見ていきます。

Karpathy の 3 段階フレーム

Software 1.0 — 人間が書くコード

1945 年の ENIAC から 2024 年までのソフトウェアは、ほぼすべて 人間がソースコードを書き、コンパイラが機械語に変換する という形で作られてきました。

• 入力: 人間が書いた C++ / Python / Rust の文字列
• 変換: コンパイラ / インタプリタ
• 出力: CPU が実行する機械語

このパラダイムで 80 年近く、世界中のソフトウェア産業が回ってきました。GitHub の数億リポジトリも、ほぼこれ。

Software 2.0 — データから学ばせる重み

2017 年、Karpathy は「ニューラルネットワークはソフトウェアを書く新しい方法だ」と宣言します（Medium の「Software 2.0」記事）。

• 入力: ラベル付きデータセット
• 変換: 勾配降下法（gradient descent）
• 出力: 重み（weights）のテンソル

重みは**実行可能な「プログラム」**ですが、人間が読んで理解できる形ではありません。畳み込み層・全結合層・attention の数値列です。

Tesla の自動運転も、GPT の初期も、Google の検索ランキングも、2017-2024 年にかけて徐々に Software 1.0 の塊を Software 2.0 で置き換えてきました。「C++ で書かれた画像認識」が「学習済み CNN の重みファイル」に差し替わり、精度は上がり、コードは減りました。

ただしここまでは 「ソフトウェアを作る人」は依然として機械学習エンジニアであり、Python でモデルを定義し、PyTorch で学習ループを書く 必要がありました。1.0 と 2.0 の境界で生産していたのは、やはり専門エンジニアです。

Software 3.0 — プロンプトで動く LLM 自身

2023 年の ChatGPT 以降、Karpathy は 3 段目を提唱します:

• 入力: 自然言語のプロンプト
• 変換: LLM（GPT / Claude / Gemini など）
• 出力: その場で生成されるテキスト・コード・画像・意思決定

プログラムが「文字列で記述された意図」になる。LLM 自身が実行環境を兼ねる。

従来のプログラミングは「どう計算するか」を書く必要がありました。Software 3.0 では「何がしたいか」を書くだけで、「どう」の部分は LLM が選びます。

2025-2026 年に起きたこと — 理論から実装へ

Software 3.0 は 2023 年に理論として提唱されたとき、まだ「おもちゃ」の域でした。短いプロンプトで動くデモはあっても、本番コードを LLM に任せるのは無理筋だった。

2025-2026 年にこれが実運用に移行した理由は 3 つあります。

1. コンテキストウィンドウの爆発

• 2023 年: GPT-4 の 32K トークン
• 2024 年: Claude 3 の 200K、Gemini の 1M
• 2025 年: Claude 4 の 200K + 外部メモリ、GPT-5 の 400K

200K トークンあれば、中規模なコードベース全体を一度に LLM に見せられます。関数単位の補完ではなく、プロジェクト全体を踏まえた設計変更が可能になりました。

2. ツール使用の成熟 — Agentic Coding

2024 年までの LLM は「コードを書いて返す」までが仕事でした。2025 年の Claude Code、OpenAI Codex、Gemini CLI は、ファイル編集・テスト実行・コミット・PR 作成まで自律的にやります。

これは Software 3.0 の本質的な進化です。プロンプトで指示するだけで、LLM が 「どのファイルを読む」「どのコマンドを打つ」「どのテストを走らせる」 を自分で選ぶ。1.0 の世界で人間がやっていた「エディタ操作」「ビルド起動」「デバッガ使用」の全部が、LLM の内側に入りました。

3. 誰でも試せる価格帯

Claude の Pro プラン、ChatGPT Plus、Gemini Advanced — どれも月額 20 ドル前後で、個人エンジニアが日常的に Software 3.0 を使える価格です。企業向けには Claude Enterprise や GitHub Copilot Enterprise が整い、組織的な導入も進みました。

バイブコーディング — Software 3.0 の実践形

2025 年に流行した バイブコーディング (vibe coding) は、Software 3.0 の実践スタイルを指します。Karpathy 自身が X で使った言葉です。

“I’ve been doing vibe coding lately where I just fully give in to the vibes, embrace exponentials, and forget that the code even exists.” — Andrej Karpathy, 2025

意訳すると:

「最近はバイブコーディングばかりやっている。vibes に身を委ね、指数関数的進化を受け入れ、コードの存在すら忘れる」

実際にやると:

1. Claude Code や Codex を起動する
2. 「X 機能を追加したい、こんな UX で」とプロンプトで伝える
3. LLM がコードを書き、テストを走らせ、通ったら report する
4. 人間はレビューしてマージ、または追加の方向性を自然言語で指示する

ここで人間が「コードを書く時間」は、全体の 10-30% 程度です。残りは意思決定、レビュー、方向性の調整。

これは Software 1.0 と比較すると、文字通り数倍の速度で動きます。Singularity Society BootCamp 第 4 期の参加者も、1 人で 3-5 体の AI エージェントを並列で動かしながらプロダクトを作っています。

1.0 / 2.0 / 3.0 は共存する

Software 3.0 が広まったからといって、1.0 と 2.0 がなくなるわけではありません。

決済バックエンドは今も Software 1.0 で書くべきだし、顔認識は Software 2.0、ドキュメント生成や社内ツールは Software 3.0 — のような使い分けになります。

実際のプロジェクトは 3 つが混ざった形で、Karpathy もそう言っています。重要なのは「どの層でどのパラダイムを選ぶか」を意識すること。

エンジニアに求められる新しい役割

Software 3.0 の時代に、エンジニアの仕事は消えるのか — というのは繰り返し議論されています。実感としては 「消えない。ただし形は根本的に変わる」 が近い。

1. 意図の設計者 (Intent Architect)

LLM にコードを書かせるとき、最も時間を使うのは 「何を作るべきか」を精度高く記述する部分です。曖昧なプロンプトで曖昧な実装が返ってきて、何度もやり直す — というのは、要件定義が甘いときに Software 1.0 で起きたことと同じです。

Software 3.0 では、要件定義書・ユーザーストーリー・受入基準が実質的なソースコードになります。

2. レビュアー / 品質ゲート

LLM が書いたコードを、ちゃんと読める人が要ります。10 倍のスループットで出てくる PR をちゃんと落とす人がいないと、プロジェクト全体の品質が崩壊します。

これは従来のコードレビューより重い役割です。「書いた人の意図を再構築する」のではなく「LLM が意図を正しく解釈したか」を判定するので、ドメイン理解と Software 1.0 的な実装読解力の両方が要ります。

3. ツール作者 (Tool Builder)

Software 3.0 を実際に回すインフラ — MCP サーバー、カスタムスキル、エージェントフレームワーク、評価系（evals） — を作る人の価値が上がっています。1 人のツール作者が、100 人のエンジニアの生産性を押し上げます。

MulmoTerminal や MulmoClaude は、まさにこの層のインフラ投資です。

4. アーキテクト

LLM にコードを書かせても、システム全体の構造判断は依然として人間の仕事です。マイクロサービスを切るか / モノリスで行くか、どの境界で DB を分けるか、どのツールを採用するか — これらは Software 3.0 でも AI に完全に任せられない領域です。

Software 3.0 を今日から始めるには

• Claude Code / Codex / Gemini CLI のどれかを使い始める — 月額課金で済む
• 1 日 1 本の小さな issue を AI に任せる — 最初は補完として、慣れたら PR 単位で
• MCP でツールを拡張 — MCP 入門 参照
• 並列実行を試す — MulmoTerminal で 3-5 体のエージェントを同時に動かすと、生産性の限界が見えてくる

バイブコーディングのワークフローは、本を読んで理解するより、1 週間試す方が速く身に付きます。

まとめ

• Software 3.0 は Karpathy のフレーム。1.0 が人間のコード、2.0 がデータの重み、3.0 がプロンプトで動く LLM
• 2025-2026 年にコンテキスト拡大・ツール使用・個人価格の 3 条件が揃い、理論から実装に移行
• バイブコーディングは Software 3.0 の実践形。コードを書くより、意図を記述する時間が長い
• 1.0 / 2.0 / 3.0 は共存する。使い分けを意識する
• エンジニアの役割は「意図の設計者」「レビュアー」「ツール作者」「アーキテクト」の 4 つに重心が移る

これは 「書く量が減って、読む量と判断する量が増える」 時代の始まりです。

関連リンク

• Andrej Karpathy — Software 2.0 (Medium, 2017)
• MCP (Model Context Protocol) 入門 — AI エージェントに外の世界を触らせる標準
• MulmoTerminal — Claude Code / Codex を並列実行するブラウザコックピット
• MulmoClaude — 自分だけの AI アシスタントを育てる
• Cursor の代替 — 複数の AI エージェントを並列に動かすなら MulmoTerminal
• 中島聡 YouTube — 「Software 3.0」解説動画

Singularity Society はテクノロジー集団として MulmoClaude / MulmoTerminal / MulmoCast を開発しています。エンジニア・起業家向けの実践プログラム BootCamp も運営しています。