AIがコードを書く時代になるまでの90年をまとめてみた

はじめに

エアークローゼットでエンジニアをしているentherraです。最近はClaude Codeを使ったAgentic Engineeringを試行錯誤しています。

AIがコードを書けるようになった背景を調べていたら、約90年前のTuringにまで遡ることになりました。思いのほか長くなったので、興味のあるセクションだけでもぜひ。

TL;DR

• GitHub issueの自動解決能力を測るSWE-bench Verifiedが15ヶ月で33%から80%へ急速に進化しました（Claude Opus 4.5）。本記事では、形式手法・帰納的学習・エージェント研究という三つの流れが2020年代に収束した結果と捉えています。
• ただし80%はベンチマーク飽和の兆候でもあり、SWE-bench Proでは40%台に落ちます。評価は次々と難しいベンチマークへ移行しています。
• 生産性への影響は文脈に依存します。ジュニア開発者や不慣れなコードベースでは効果的ですが、熟練開発者が慣れた環境で使うと逆効果という報告もあります。むしろ質的変化として、エンジニアの役割は「コード作成者」から「AIの監督者」へ移行しています。
• 大規模言語モデル（LLM）の能力については学術的議論が続いています。「洗練されたパターンマッチング」という批判と「創発的な理解」という反論があり、次の波はニューロシンボリック統合と見られています。
• 知識獲得は手動エンコードから自動学習へ進化しました。それでも目標定義と結果検証の責任は人間に残ります。

なぜ90年前から話を始めるのか

2025年11月、AnthropicのClaude Opus 4.5がSWE-bench Verifiedで80.9%を達成しました [Anthropic, Official Blog 2025]。実際のGitHub issueを解決する能力を測定するこのベンチマークで、わずか15ヶ月で33%から80%を超えました。

なぜこれほど急速に進歩したのでしょうか。2020年代に突然何かが発明されたわけではありません。今日のAI Coding Agentsは、少なくとも三つの研究の流れが数十年かけて成熟し、2020年代に収束した結果です。

• 形式手法（1969年〜）：「正しいプログラム」を数学的に証明したい
• 帰納的学習（1958年〜）：仕様を書くより例から学ばせたい
• エージェント研究（1957年〜）：指示待ちでなく自分で判断させたい

これらの源流をたどると、1936年にAlan Turingが計算可能性を定義した地点に行き着きます。2025年から数えて約90年前のことです。

ただし、遺伝的プログラミングやAnswer Set Programmingなど、本記事では触れない重要なアプローチも存在します。

計算可能性の定義（1936-1960）

プログラムを自動生成するという発想が理論的な基盤を得るには、まず「計算とは何か」を厳密に定義する必要がありました。

20世紀初頭、数学者David Hilbertは野心的な計画を掲げていました [Hilbert, Abhandlungen aus dem Mathematischen Seminar der Universität Hamburg 1922]。数学のすべてを公理と推論規則で形式化し、あらゆる数学的命題の真偽を機械的な手順で判定できるようにする。1928年、彼はWilhelm Ackermannとの共著でこれを「決定問題」（Entscheidungsproblem）として定式化しました [Hilbert & Ackermann, Grundzüge der theoretischen Logik 1928]。任意の論理式を入力として受け取り、それが妥当かどうかを有限ステップで判定するアルゴリズムは存在するか、という問いです。

1931年、Kurt Gödelが不完全性定理を発表しました [Gödel, Monatshefte für Mathematik und Physik 1931]。算術を含む任意の無矛盾な形式体系には、その体系内で証明も反証もできない命題が必ず存在する。Hilbertの計画は根本から揺らぎました。しかし、決定問題への最終的な答えはまだ出ていませんでした。「証明できない命題がある」ことと「証明できるかどうかを判定できない」ことは別の問題だからです。

1936年、この問いに対してAlonzo ChurchとAlan Turingがそれぞれ独立に答えを出しました。Churchはλ計算（関数を記号的に表現する数学体系で、関数型プログラミングの理論的基盤） [Church, American Journal of Mathematics 1936]、Turingはチューリングマシン [Turing, Proceedings of the London Mathematical Society 1936] という異なるアプローチで、「解けない問題が存在する」ことを証明したのです。Turingの論文はこう始まります。

The "computable" numbers may be described briefly as the real numbers whose expressions as a decimal are calculable by finite means.

「計算可能」数とは、簡潔に言えば、その小数表現が有限の手段によって計算できる実数のことである。

「できないこと」を証明しようとした彼らは、結果的に「できること」を定義しました。なぜ「できないこと」を証明しようとして「できること」の定義が生まれたのでしょうか。限界を示すには、まず対象を厳密に定義しなければならないからです。Church–Turing thesisとして知られるこの概念は、「計算可能な関数とは、チューリングマシンで計算できる関数である」という主張です。

チューリング完全な言語であれば計算できる範囲は同じであり、計算可能性の限界は1936年、コンピュータが生まれる前に数学的に確立されました。

計算可能性の理論的基盤が確立される中、それを実際の機械で扱うための別の重要な発展もありました。Claude Shannonは1937年のMIT修士論文で、ブール代数とスイッチング回路の関係を示し [Shannon, MIT Master's Thesis 1937]、論理（真/偽）と物理（オン/オフ）を橋渡ししました。1948年には情報理論を確立 [Shannon, Bell System Technical Journal 1948]。ビットという概念はここで生まれました。テキストも画像も音声も、そしてプログラムも、すべて0と1の列として扱える。プログラムを情報として扱い、統計的に分析するという発想は、この理論に多くを負っています。

こうした理論的・技術的基盤が整った1956年夏、ダートマス大学にJohn McCarthy、Marvin Minsky、Claude Shannon、Nathaniel Rochesterらが集まりました。提案書 [McCarthy et al., Dartmouth Proposal 1955] には野心的な一文がありました。

"every aspect of learning or any other feature of intelligence can in principle be so precisely described that a machine can be made to simulate it"

学習や知能のあらゆる側面は、原理的に機械でシミュレートできるほど正確に記述できる。

この予測の実現には、彼らの想定をはるかに超える時間がかかることになります。McCarthyが名付けた「人工知能」という言葉はこの会議から広まりました。

Herbert SimonとAllen Newellは1955年から1956年にかけてLogic Theorist [Newell, Shaw & Simon, IRE Transactions on Information Theory 1956] を開発し、このダートマス会議で発表しました。『Principia Mathematica』の定理をいくつか自動証明してみせたこのプログラムは、「機械が考える」ことの最初の実証でした。翌1957年にはGeneral Problem Solver（GPS） [Newell, Shaw & Simon, Western Joint Computer Conference 1957] を開発。特定のタスクではなく、汎用的な問題解決能力の実現を目指したシステムです。

翌1958年、McCarthyはLISPを開発しました [McCarthy, Communications of the ACM 1960]。これは単なるプログラミング言語ではなく、λ計算の概念を実用的な形で具現化したものでした。再帰関数、条件式、ガベージコレクションという概念がここで実装されました。以下はLISPのシンボリックな表現力を示す簡単な例です。

;; Schemeで書いた階乗の再帰的定義
(define (factorial n)
  (if (zero? n)
      1
      (* n (factorial (- n 1)))))

ここに、プログラム自動生成への二つの道が見え始めます。一つは形式的な証明に基づくアプローチ、もう一つは学習や探索に基づくアプローチです。

この二つの道は、本質的に異なる哲学を反映しています。形式的アプローチは「仕様に対する正しさの証明」を目指し、機械学習アプローチは「多くの場合に機能する近似解」を目指します。前者は数学的な正しさを追求しますが、仕様自体の妥当性や実行環境の正しさまでは保証できず、また完全な形式化には限界があります。後者は広範な適用を可能にしますが、誤りを完全には排除できません。2025年現在のコード生成AIの成功と限界は、このトレードオフを反映しています。両者は60年以上別々に発展し、2020年代に収束し始めます。

ソフトウェア危機と形式的アプローチ（1968-1990）

1968年3月、Dijkstraは "Go To Statement Considered Harmful" を発表しました [Dijkstra, CACM 1968]。goto文の乱用がプログラムの理解と検証を困難にしていると主張し、構造化プログラミングを提唱したのです。同年10月、NATOガルミッシュ会議で「ソフトウェア危機」が公式に認識されました [Naur & Randell (Eds.), NATO Software Engineering Conference 1968]。遅延、予算超過、品質問題が常態化していました。

この危機意識が、形式手法によるプログラム合成への関心を高めました。もしプログラムを仕様から自動的に導出できれば、バグは原理的に存在し得ません。当時の研究者たちはこの可能性を追求しました。

この時期、プログラムの正しさを数学的に証明する理論的基盤も相次いで確立されました。1967年、Robert Floydは "Assigning Meanings to Programs" で不変式（ループ実行中に常に成り立つ条件）を用いたプログラム検証手法を提案し、1978年にチューリング賞を受賞。1969年、Tony Hoareは "An Axiomatic Basis for Computer Programming" でHoare tripleを導入しました [Hoare, Communications of the ACM 1969]。{P} C {Q} という記法で「事前条件Pのもとでコマンドを実行すれば事後条件Qが成り立つ」ことを表現します。{x = 5} x := x * 2 {x = 10} のように、コードの振る舞いを論理式として捉える発想です。Hoareも1980年にチューリング賞を受賞しています。Dijkstraは1976年に最弱事前条件計算を体系化し、この枠組みを完成させました。現代の検証ツールDafnyやViperはこの理論の直系です。

同じ1969年、Stanford/SRI InternationalのCordell Greenは別のアプローチを取りました [Green, IJCAI 1969]。定理証明の過程で変数に具体値が束縛されていき、その副産物としてプログラムを得るという発想です。仕様を論理式で書き、「この仕様を満たす答えが存在する」という証明を構築すると、証明の中に答え（プログラム）が埋め込まれています。

型理論の分野では、William Alvin Howardが1969年に執筆し1980年に発表した論文でCurry-Howard同型対応を確立しました [Howard, To H. B. Curry: Essays 1980]。一言で言えば、「定理を証明することと、プログラムを書くことは本質的に同じ」という発見です。これは直観主義論理（証明の構成可能性を重視し、「存在する」と主張するには具体例を示す必要がある論理体系）とλ計算（型理論）の間に深い対応関係があることを示すもので、命題は型に、証明はプログラムに対応するという洞察です。例えば、論理学の「A → B」（AならばB）という命題は、プログラミングにおける「A → B」という関数型に対応します。「AからBを導出する証明」を構成することは、「A型の値を受け取りB型の値を返す関数」を実装することと等価なのです。

Greenのアプローチ（導出原理による答え抽出）とCurry-Howard対応（証明の構造そのものがプログラム）は、哲学も技術的系譜も異なりますが、「証明とプログラムの関係」という共通のテーマを異なる角度から照らしています。

この対応関係は体系的に成り立ちます。論理学の「かつ」（A ∧ B）は型理論のタプル型（A × B）に、「または」（A ∨ B）は直和型（A + B）に対応します。真（⊤）はユニット型に、偽（⊥）は空型（値が存在しない型）に対応します。つまり、型がinhabited（その型の値が存在する）とき、対応する命題は証明可能なのです。例えば、A → A（AならばA）という自明な命題は、恒等関数 fn(x: A) -> A { x } として実装できます。関数が書けた＝証明が構成できた、ということです。一方、Rustの!型やScalaのNothing型は値を持たないのでuninhabitedであり、対応する命題（偽）は証明不可能です。「偽からは何でも導ける」という論理学の原理は、fn(x: Never) -> T が任意の型Tを返せる（決して呼ばれないので）というプログラミングの事実に対応しています。

この視点は、型システムを通じてプログラムの正しさを保証するという方向性の理論的基盤となりました。現代のHaskellやRust、証明支援系Coq/Leanはこの対応関係を直接活用しています。

Greenの研究を体系化したのが、StanfordのZohar MannaとSRI InternationalのRichard Waldingerです。彼らの共同研究は1970年から始まり、1980年の論文 "A Deductive Approach to Program Synthesis" で集大成を迎えました [Manna & Waldinger, ACM TOPLAS 1980]。核心は "The proof constitutes a demonstration of the correctness of this program"（証明を構築する過程がそのままプログラムの正しさの証明になる）という点です。Deductive Tableau Methodと呼ばれるこの証明構築手法は、演繹的合成の標準的な参照となり、両者は2016年にHerbrand Awardを共同受賞しています。

理論は整っていたのですが、実用化は困難を極めました。形式仕様を書くこと自体が専門的なスキルを必要とし、証明探索の計算量は問題サイズとともに急激に増加したのです。この状況を打開しようとしたのが、Kestrel InstituteのDouglas R. Smithです。彼のKIDS（Kestrel Interactive Development System）は、1990年のIEEE TSE論文で発表されました [Smith, IEEE TSE 1990]。KIDSは対話的な開発環境を提供し、人間の知識と機械の探索能力を組み合わせることで、実用的な問題を解けるようにしました。1993年の応用研究では、米国空軍の戦略輸送スケジューリングにおいて、15,460件の移動要件を71秒で処理するという成果を上げました [Smith & Parra, 1993]。

%% 演繹的合成の概念を示す擬似的なProlog風コード
%% 仕様：リストの最大値を求める

%% 仕様（論理式として）
max_spec(List, Max) :-
    member(Max, List),           % MaxはListの要素である
    forall(member(X, List), X =< Max).  % すべての要素はMax以下

%% 証明（＝プログラムの導出）
%% 帰納法：空リストの場合と非空リストの場合を分ける
max_program([X], X).             % 基底ケース
max_program([H|T], Max) :-       % 帰納ステップ
    max_program(T, TMax),
    (H >= TMax -> Max = H ; Max = TMax).

KIDSの成功は同時にその限界も示していました。高度な専門知識を持つ人間との対話が必要であり、汎用的なプログラム合成はまだ実現困難な課題でした。

証明構築の手間を省く別のアプローチも発展していました。Edmund Clarke、Allen Emerson、Joseph Sifakisは、システムのすべての状態を自動探索して時相論理の性質を検証するモデル検査を開発し、2007年にチューリング賞を共同受賞しました。1989年にはKen McMillanがBDD（二分決定図）を用いた記号モデル検査で10^{20}状態を扱えるようにし、ハードウェア検証の実用性を大きく高めました。2013年チューリング賞受賞者Leslie Lamportが開発したTLA+は、Amazon Web Servicesで2011年から採用され、DynamoDB、S3、EBSで「他の手段では発見できなかった微妙なバグ」を発見しています [Newcombe et al., Communications of the ACM 2015]。

エキスパートシステムの教訓

形式的手法がプログラムの正しさを保証しようとしていた同時期、AIの別の潮流であるエキスパートシステム（専門家の知識をif-thenルールとしてエンコードし、特定ドメインの問題を解決するシステム）も発展していました。しかしこちらも、形式的アプローチと同様の壁に直面することになります。

最初の成功例は1965年のDENDRALでした [Lindsay et al., Artificial Intelligence 1993]。StanfordのEdward FeigenbaumとJoshua Lederbergが開発したこのシステムは、質量分析データから化学構造を推定します。

続く1970年代のMYCINは、細菌感染症の診断と抗生物質推奨を行うシステムでした。髄膜炎症例の評価で、MYCINの推奨は65%が「適切」と判定され、教員専門家（42.5〜62.5%）を上回りました [Yu et al., JAMA 1979]。医療という高リスク領域で専門家を定量的に上回った事例として注目されました。

商業的成功を収めたのはDECのR1/XCON（1978年〜）です [McDermott, Artificial Intelligence 1982]。Carnegie Mellon大学のJohn McDermottが開発したこのシステムは、年間数千万ドルのコスト削減に貢献しました。1980年代半ばには「第五世代コンピュータ」への期待が高まりました。

しかし、1980年代後半から問題が顕在化します。知識獲得ボトルネック（Knowledge Acquisition Bottleneck）と呼ばれる現象です。専門家の暗黙知を明示的なルールとして抽出することは極めて困難でした。MYCINの約450のルールを構築するのに何年もかかり、新しいドメインへの拡張には同様の労力が必要でした。さらに学習したドメインの外では脆弱であり、自ら学習する能力もありませんでした。

この失敗は、後のLLMがなぜ成功したかを理解する鍵となります。エキスパートシステムとLLMは何が違うのでしょうか。根本的な違いは、知識獲得の方法にあります。エキスパートシステムが明示的なルールを人手でエンコードしたのに対し、LLMは大量のデータから暗黙的にパターンを学習します。LLMはエキスパートシステムが直面した知識獲得ボトルネックを、大規模なテキストコーパスからの自動学習で回避しました。加えて、モデルサイズとデータ量を増やすほど性能が予測可能に向上するというスケーリング則の発見が、大規模投資を正当化しました。

例から学ぶという発想（2006-2015）

形式仕様を書くという障壁を越える方法はないのでしょうか。研究者たちは古くからこの問いを抱えていました。1980年代にはすでに帰納的プログラム合成の研究が存在しましたが、実用的な成果には至っていませんでした。転機は2000年代後半に訪れます。UC Berkeley（後にMIT）のArmando Solar-Lezamaは2006年、Sketchというシステムを発表しました [Solar-Lezama, PhD Thesis 2008]。Sketchの核心はhole（穴）という概念です。プログラマが完全なコードを書く代わりに、未確定の部分を ?? で表します。

// Sketchによるビットカウントの合成
int countBits(int x) {
  int count = 0;
  while(x != 0) {
    if (??) count++;  // 条件が不明
    x = x >> ??;      // シフト量が不明
  }
  return count;
}

// 合成器は以下のような解を見つける：
int countBits_synthesized(int x) {
  int count = 0;
  while(x != 0) {
    if (x & 1) count++;  // 最下位ビットが1なら
    x = x >> 1;          // 右に1シフト
  }
  return count;
}

合成器は、すべての穴を埋めて、与えられたテストケースをパスするプログラムを見つけます。Sketchの真の革新は、Counter-Example Guided Inductive Synthesis（CEGIS）と呼ばれるパラダイムを確立したことにあります。

CEGISは帰納的アプローチと演繹的アプローチを橋渡ししています。候補生成は帰納的、検証は演繹的。この分離により、実用的なプログラム合成が可能になりました。

プログラム合成の計算量は膨大です。すべてのプログラムを列挙してテストするナイーブなアプローチでは、探索空間が指数関数的に爆発します。CEGISはこの爆発を二つの方法で抑えました。第一に、反例が制約として蓄積されることで同じ失敗を繰り返さなくなる。第二に、SMT（Satisfiability Modulo Theories）ソルバーが制約を満たす候補を効率的に見つける。SMTソルバーは「x > 0 かつ x < 10 かつ x + y = 15」のような制約を投げると、x = 5, y = 10 のような具体解を返してくれるエンジンで、Microsoft Researchのde Mouraらが2008年に発表したZ3 [de Moura & Bjørner, TACAS 2008] は、算術、配列、ビットベクトルなどの理論を扱え、現代の検証ツールの事実上の標準となっています。なお、de Mouraは2013年にLean証明支援系も開発しており、SMTソルバーと形式証明の両方でAIコード生成の基盤を築いた人物です。

この「推測と検証」のパターンは、テストを活用するコード生成エージェントによく似ています。LLMがコードを生成し、テストが正しさを検証する。Solar-Lezamaが2006年に確立したパラダイムは、形を変えて20年後のコード生成エージェントに継承されています。

Microsoft ResearchのSumit Gulwaniは、プログラム合成を一般ユーザーに届けることに成功した稀有な研究者です。2009年12月、フランクフルトからシアトルへの帰国便で、隣席の女性からExcelでの名前列のマージ方法を質問されました [Gulwani, SIGPLAN Blog 2021]。多くの人々が日常的に行うデータ操作は、プログラマにとっては自明ですが、そうでない人には高い壁となります。

2011年のPOPL論文で発表されたFlashFillは、入出力例からプログラムを推論します [Gulwani, POPL 2011]。ユーザーは "John Smith → J. Smith" のような例を一つか二つ示すだけで、残りのデータに同じ変換が適用されます。

FlashFillの動作例：

入力例:
  "John Smith" → "J. Smith"
  "Mary Jane Watson" → "M. Watson"

FlashFillが推論するDSLプログラム:
  Concatenate(
    Substring(input, 0, 1),   // 最初の1文字
    ConstStr(". "),           // ". " を挿入
    GetToken(input, Word, -1) // 最後の単語
  )

適用結果:
  "Robert Johnson" → "R. Johnson"
  "Alice Bob Carol" → "A. Carol"

技術的には、Version Space Algebra（VSA）による候補プログラムの効率的表現と、文字列変換に特化したDomain-Specific Language（DSL）の設計が鍵となりました。2013年、FlashFillはExcel 2013に搭載され [Microsoft Research, Flash Fill Project 2013]、プログラム合成研究が数億人のエンドユーザーに届きました。この論文はPOPL 2021でMost Influential Paper賞を受賞しています [ACM SIGPLAN, Most Influential POPL Paper Award 2021]。

FlashFillの成功は、同時にその限界も明らかにしました。文字列変換に特化したDSLは、その範囲内では優れた性能を発揮しますが、範囲外の問題には適用できません。新しいドメインには新しいDSLが必要であり、そのDSL設計自体が専門的なスキルを要求します。汎用性を追求すれば探索空間が爆発し、特化すれば適用範囲が限定されます。

深層学習は、このジレンマに対して根本的に異なるアプローチを取りました。DSLを手で設計する代わりに、大量のデータから暗黙的にパターンを学習します。

深層学習とコード生成（2015-2020）

形式的アプローチが「何が正しいか」を追求したのに対し、帰納的学習は「大量の例から学ぶ」能力を追求してきました。この流れの理論的基盤は、1948年にBell研究所のClaude Shannonが発表した "A Mathematical Theory of Communication" に遡ります [Shannon, Bell System Technical Journal 1948]。Shannonは情報を確率的な概念として定量化し、エントロピーH = -\sum p_i \log p_iという尺度を導入しました。

この情報理論は、単なる通信の数学ではありませんでした。同時期にNorbert Wienerが提唱したサイバネティクス [Wiener, MIT Press 1948] と相まって、「学習」を情報処理として捉える視点を確立したのです。機械が環境からフィードバックを受け取り、自らの振る舞いを調整するというアイデアは、後のニューラルネットワーク研究の土壌となりました。

ニューラルネットワークの長い道のり

2012年のAlexNet以降、深層学習は急速に発展しましたが、そこに至る60年は決して平坦ではありませんでした。1958年、Cornell大学のFrank Rosenblattはパーセプトロンを発表しました [Rosenblatt, Psychological Review 1958]。これは生物の神経細胞を模した計算モデルであり、入力の重み付き和を閾値と比較して出力を決定する単純な仕組みでした。1960年には実際のハードウェアMark I Perceptronが完成し、画像認識のデモンストレーションが行われました [Cornell Chronicle, Professor's perceptron paved the way for AI 2019]。しかし1969年、MITのMarvin MinskyとSeymour Papertは著書『Perceptrons』 [Minsky & Papert, MIT Press 1969] で、単層パーセプトロンがXOR（排他的論理和）を学習できないことを数学的に証明しました。多層パーセプトロンなら隠れ層による空間変換でXORは解けますが、当時は多層ネットワークを効果的に訓練する方法がありませんでした。

入力層、隠れ層、出力層からなる多層パーセプトロン。隠れ層が入力空間を非線形に変換することで、単層では解けないXOR問題を解決できる。出典: [Zhang et al., Dive into Deep Learning 2023]

これはなぜ影響が大きかったのでしょうか。Minsky自身がダートマス会議の創設者の一人であり、AI分野の権威でした^[1]。それでも、この時期に多くの研究者がニューラルネットワークの分野を離れ、残った者たちは「コネクショニズム」「並列分散処理（PDP）」など別の名称でひっそりと研究を続けました。

回復への鍵となったのが誤差逆伝播法（バックプロパゲーション）です。Paul Werbosが1974年の博士論文 [Werbos, PhD Thesis, Harvard University 1974] で形式化し、1986年にDavid Rumelhart、Geoffrey Hinton、Ronald Williamsが Nature誌で発表した論文 [Rumelhart et al., Nature 1986] により広く知られるようになりました。多層ネットワークの各重みに対して、出力誤差がどれだけ影響しているかを連鎖律で計算し、勾配降下法で更新します。この手法により、XOR問題も解けるようになりました。

一方、深いネットワークには別の問題がありました。1991年、Sepp HochreiterはDiploma論文（ドイツの学位論文）で勾配消失問題を形式的に分析しました [Hochreiter, Diploma Thesis, TU Munich 1991]。逆伝播で計算される勾配は層を遡るごとに指数関数的に小さくなり、深い層の学習が困難になります。L層のネットワークで各層の勾配係数が\gammaの場合、最初の層に伝わる勾配は\gamma^Lに比例します。

\gamma < 1（例えば\gamma = 0.5）なら、10層で0.5^{10} \approx 0.001、100層では10^{-30}以下に減衰します。深い層の重みはほとんど更新できません。

1997年、HochreiterとJürgen Schmidhuberは長短期記憶（LSTM）を発表しました [Hochreiter & Schmidhuber, Neural Computation 1997]。ゲート機構により勾配の流れを制御し、長期的な依存関係を学習できるようになりました。LSTMは後に音声認識、機械翻訳、コード生成の基盤となりました。

言語の構造を捉える技術も進化しました。2013年、GoogleのTomas Mikolovらが発表したWord2Vec [Mikolov et al., ICLR Workshop 2013] は、単語を密なベクトル空間に埋め込み、意味的関係を算術演算で表現できることを示しました。"king - man + woman ≈ queen" という有名な例は、言語の構造がベクトル空間で捉えられることを直感的に示しています。

この分散表現の概念は、自然言語からコードへと応用されていきます。Tel Aviv大学のUri Alonらが2019年に発表したCode2Vec [Alon et al., POPL 2019] は、Abstract Syntax Tree（AST）の経路をベクトル化し、コードの意味的類似性を捉えることに成功しました。関数名予測タスクで高い精度を示し、「コードを理解する」技術の基盤となりました。

自然言語とコードの両方を理解するモデルも登場しました。2020年のCodeBERT [Feng et al., EMNLP Findings 2020] は自然言語とプログラミング言語の双方向事前学習を実現し、後続のGraphCodeBERT [Guo et al., ICLR 2021] はデータフローグラフを活用して意味構造を捉えました。これらの研究は、現代のRAGシステムにおけるコード検索の基盤となっています。

Transformerへの道

2012年、ImageNetコンペティションでAlexNetが圧勝したことは、深層学習の転機として広く知られています [Krizhevsky, Sutskever & Hinton, NIPS 2012]。画像認識から始まったこの波は、自然言語処理、音声認識へと広がり、やがてコード生成にも及びました。

「ニューラルネットワークでプログラムを学習できないか」という問いへの初期の回答が、2015年のNeural Programmerでした [Neelakantan et al., arXiv 2015]。Google ResearchのArvind Neelakantan、Quoc V. Le、Ilya Sutskeverが発表したこの手法は、エンドツーエンドで微分可能なアーキテクチャにより、プログラムのアノテーションなしに実行結果のみから学習できることを示しました。

ほぼ同時期に、DeepMindのScott ReedとNando de FreitasによるNeural Programmer-Interpreters（NPI） [Reed & de Freitas, ICLR 2016] は、プログラムの階層的・モジュラーな学習を可能にしました。加算からバブルソートまで、21のサブプログラムを単一のネットワークで学習でき、後のメタ学習研究の基盤となりました。

2017年、Microsoft Research + CambridgeのDeepCoderは、ニューラルネットワークとプログラム探索を組み合わせるという重要なパラダイムを確立しました [Balog et al., ICLR 2017]。

# DeepCoderのアプローチ（実装例）

# DSL関数の例
DSL_FUNCTIONS = [
    "HEAD",      # リストの先頭
    "LAST",      # リストの末尾
    "TAKE",      # 先頭n個を取得
    "DROP",      # 先頭n個を除去
    "ACCESS",    # i番目の要素
    "MINIMUM",   # 最小値
    "MAXIMUM",   # 最大値
    "REVERSE",   # 反転
    "SORT",      # ソート
    "SUM",       # 合計
    "MAP",       # 各要素に関数適用
    "FILTER",    # 条件で抽出
    "COUNT",     # 条件を満たす数
    "ZIPWITH",   # 2リストを結合
    "SCANL1",    # 累積適用
]

def deepcoder_approach(input_output_examples):
    # Step 1: ニューラルネットワークで各関数の使用確率を予測
    probabilities = neural_network.predict(input_output_examples)
    # 例: {"HEAD": 0.1, "SORT": 0.8, "TAKE": 0.7, ...}

    # Step 2: 確率の高い関数を優先して探索
    for program in enumerate_programs_by_probability(probabilities):
        if satisfies_all_examples(program, input_output_examples):
            return program

    return None

ニューラルネットワークは直感や当たりをつける役割を果たし、最終的な正しさの保証は従来の探索と検証が担う。「予測」と「保証」の役割分担です。これはSketchのCEGISと同じ構図であり、ニューラルネットワークの追加により探索空間の効率的な絞り込みが可能になりました。

同年、Microsoft ResearchのJacob DevlinらによるRobustFill [Devlin et al., ICML 2017] は、FlashFillをニューラル化し、実世界テストセットで92%の精度を記録しました。入出力例にタイポがあっても動作するノイズ耐性を備えています。

これらの研究はニューラルネットと探索の融合における初期の成功例でしたが、アーキテクチャ的にはRNN/MLPベースの限界もありました。大きな転換点は、アーキテクチャそのものの刷新から始まります。

同じ2017年、Googleの研究者8名が発表した論文 "Attention Is All You Need" [Vaswani et al., NeurIPS 2017] は、現代のLLMすべての基盤となるTransformerアーキテクチャを提案しました。従来のRNN（再帰型ニューラルネットワーク）やLSTMが逐次的に入力を処理していたのに対し、Transformerは自己注意機構（Self-Attention）により入力全体を並列に処理できます。Self-Attentionは、入力中の各トークンが他のすべてのトークンとの関連度を計算し、重要な部分に注目する仕組みです。計算量はシーケンス長nに対してO(n^2)ですが、並列化により訓練速度は顕著に向上しました。これにより、長い文脈の依存関係を効率的に捉えられるようになり、大規模な並列計算が可能になりました^[2]。

この論文の革新性は、逆説的な発想にあります。RNNやLSTMは逐次的に処理することで順序を自然に捉えられるという利点があり、言語のような逐次的なデータに適していると考えられていました。Transformerは並列処理を可能にするため、すべての入力を同時に見る設計を選びました。

しかし、並列処理では順序情報が自動的には保持されないという問題が生じます。「犬が猫を追いかけた」と「猫が犬を追いかけた」は同じトークンで構成されていますが、意味は異なります。この問題に対する解決策が位置エンコーディングです。三角関数を用いて各位置に固有のパターンを与え、順序情報を明示的にモデルに注入しました。つまり、Transformerは順序を捨てたのではなく、順序の扱い方を暗黙的な逐次処理から明示的な位置エンコーディングに転換したのです。

並列化によるスケーラビリティの恩恵は、逐次処理の利点を大きく上回りました。順序を厳密に追うよりも、全体を一度に見て関係性を掴む方が言語の理解には有効でした。シンプルさが勝つという傾向は、その後のLLM開発全体を通じて確認されることになります。

Transformerのエンコーダ・デコーダ構造。左がエンコーダ（入力を処理）、右がデコーダ（出力を生成）。Multi-Head Attentionが入力全体の関係性を並列に捉え、位置エンコーディングが位置情報を補う。N×は層の積み重ねを示す。GPTはデコーダのみ、BERTはエンコーダのみを使用する。出典: [Vaswani et al., arXiv 2017]

2018年6月、Transformerの片側（デコーダ部分）のみを使用するアプローチがOpenAIから発表されました。GPT-1（Generative Pre-trained Transformer）です [Radford et al., OpenAI 2018]。1.17億パラメータのモデルを大量のテキストで事前学習し、教師なしで言語の構造を学習させ、その後各タスク向けにファインチューニングするという手法でした。

2019年2月、OpenAIはGPT-2を発表しました [Radford et al., OpenAI 2019]。パラメータ数は15億に増加し、Zero-shot学習の能力が出現しました。つまり、特定タスク向けのファインチューニングなしに、プロンプトの形式を変えるだけで多様なタスクをこなせるようになりました。OpenAIは「悪用のリスク」を理由に当初フルモデルの公開を見送りましたが、これは後のAI安全性議論の先駆けとなりました。GPT-2は、スケーリングが新しい能力を創発させるという重要な洞察を与えました。

時系列を少し戻ると、GPT-2の数ヶ月前の2018年10月にGoogleのJacob Devlinらが発表したBERT（Bidirectional Encoder Representations from Transformers） [Devlin et al., arXiv 2018] は、自然言語処理の標準的手法を塗り替えました。BERTの特徴は双方向性にあります。従来のモデルが左から右（または右から左）への一方向で文脈を学習していたのに対し、BERTは両方向から同時に文脈を捉えます。

これを可能にしたのがMasked Language Modeling（MLM）です。入力の一部（約15%）をランダムにマスクし、周囲の文脈から予測させます。例えば "The cat sat on the [MASK]" という入力に対し、左右両方の文脈から "mat" を予測します。加えてNext Sentence Prediction（NSP）タスクでは、二つの文が連続しているかどうかを判定させ、文間の関係性を学習させました。

大規模なテキストコーパスで事前学習し、特定のタスクでファインチューニングするというパラダイムを確立しました。SQuAD v1.1ではアンサンブルモデルで人間を超える93.2%のF1スコアを記録し、11のNLPベンチマークで最高性能を記録しました。事前学習の有効性を決定的に示した結果です。2019年にはNAACL Best Long Paper賞を受賞し、Googleは同年末までに70以上の言語でBERTを検索に導入しています。

Transformerアーキテクチャには三つの系譜が生まれました。Encoder-only（BERT系）は双方向の文脈理解に優れ、Decoder-only（GPT系）は自己回帰的な生成に特化し、Encoder-Decoder（T5, BART）は構造化された入出力タスクに適しています。コード生成には自己回帰的な生成能力が本質的に重要であり、後のCodexやCopilotはDecoder-only（GPT）の系譜を継ぎます。現代のコード生成AIが書くことに長けているのは、この選択の帰結です。一方で、コードを理解する能力についてはEncoder系のアプローチも重要であり、CodeBERTなどの研究につながっています。

2019年、GitHubとMicrosoft Researchが共同で構築したCodeSearchNetは、約600万の関数を含む大規模コードデータセットを提供しました [Husain et al., arXiv 2019]。Go、Java、JavaScript、PHP、Python、Rubyの6言語をカバーし、後のCodeBERT等の事前学習モデルの基盤となりました。

真のブレイクスルーには、さらに大きなモデルとデータが必要でした。GPT-3以降、LLMは大きく進化していきます。

LLMの躍進（2020-2024）

2020年、OpenAIがGPT-3を発表しました [Brown et al., NeurIPS 2020]。1,750億パラメータという前例のない規模のモデルが、Few-shot学習で高い汎化性能を示しました。なぜファインチューニングなしに新しいタスクに適応できるのでしょうか。この論文で示されたIn-Context Learning（文脈内学習）がその鍵でした。モデルの重みを更新することなく、プロンプトに数個の例を含めるだけで新しいタスクに適応できる。これは従来のファインチューニング前提を覆すアプローチでした。

ただし、なぜこれが機能するのかは2025年現在も完全には解明されていません。モデルは本当に「学習」しているのでしょうか、それとも事前学習で獲得したパターンを巧みに組み合わせているだけなのでしょうか。

この問いに対し、いくつかの仮説が提案されています。Stanford/MITの研究者らは、In-Context Learningを「暗黙的な勾配降下」として解釈する理論を提示しました [Akyürek et al., ICLR 2023]。彼らの分析によれば、Transformerの順伝播は、例示から暗黙的に重みを学習する過程と数学的に類似しています。モデルは重みを更新していないように見えて、アテンション機構を通じて「疑似的な学習」を行っている可能性があります。

別の見方もあります。ICLは「学習」ではなく「検索」だという主張です。モデルは事前学習で膨大なパターンを記憶しており、プロンプトの例はそのパターンを活性化するトリガーに過ぎないという解釈です。この見方では、ICLは新しい能力の獲得ではなく、既存の知識の効率的な引き出しということになります。両者は排他的ではなく、実際には両方の側面が共存しているのでしょう。

重要な点として、この能力はある規模を超えたモデルでのみ出現すると報告されています。GPT-2（15億パラメータ）ではほとんど機能しなかったICLが、GPT-3（1,750億パラメータ）では有効に機能する。Wei et al.はこの現象を「創発能力」と呼び、スケーリングによる質的変化として記述しました [Wei et al., arXiv 2022]。創発能力とは、小さいモデルにはなかった能力が、ある規模を超えると突然現れる現象です。水が100度で突然沸騰するような相転移に似ています。

ただし、この解釈には異論もあります。Schaeffer et al.は、創発能力の多くは評価指標の選択によるアーティファクト（見かけ上の現象）である可能性を指摘しました [Schaeffer et al., NeurIPS 2023]。彼らの分析によれば、非線形な評価指標を使用すると急激な性能向上に見えるが、連続的な指標では滑らかな改善曲線が観察されます。なぜ巨大なモデルでこの能力が顕著になるのか、あるいはそれが真の創発なのかについては、2025年現在も議論が続いています。

2021年7月、OpenAIはCodex論文を発表しました [Chen et al., arXiv 2021]。GPT-3の12Bパラメータ版をGitHubの159GB Pythonコードでファインチューニングし、新設されたHumanEvalベンチマーク（164問）で28.8% pass@1を達成しました。HumanEvalは関数のdocstringを与えて、その実装を生成させる形式のベンチマークです。同年8月、GoogleはMBPP（Mostly Basic Python Problems）を発表しました [Austin et al., arXiv 2021]。974問のクラウドソースされたPythonプログラミング問題で構成され、HumanEvalよりも多様な問題をカバーします。HumanEvalが164問と比較的小規模であることへの補完として、コード生成モデルの評価において重要な役割を果たすようになりました。これらのベンチマークはpass@k評価指標を採用しています^[3]。k個の候補を生成し、少なくとも1つがテストに合格する確率を測定することで、モデルの一発勝負の精度（pass@1）と、複数回試行での成功率（pass@10、pass@100）を区別できるようになりました。

# HumanEval形式の例

def has_close_elements(numbers: List[float], threshold: float) -> bool:
    """Check if in given list of numbers, are any two numbers
    closer to each other than given threshold.
    >>> has_close_elements([1.0, 2.0, 3.0], 0.5)
    False
    >>> has_close_elements([1.0, 2.8, 3.0, 4.0, 5.0, 2.0], 0.3)
    True
    """
    # モデルがここを生成する
    for i, n1 in enumerate(numbers):
        for j, n2 in enumerate(numbers):
            if i != j and abs(n1 - n2) < threshold:
                return True
    return False

2021年6月、GitHub Copilotがテクニカルプレビューを開始し [GitHub Blog, Introducing GitHub Copilot 2021]、2022年6月に一般公開されました [GitHub Blog, GitHub Copilot is Generally Available 2022]。対照試験では開発者の作業完了時間が55.8%短縮されることが示され [Peng et al., arXiv 2023]、AIペアプログラミングが実用段階に達したことを証明しました。

競技プログラミングという、より困難な領域でも進展がありました。DeepMindのAlphaCode [Li et al., Science 2022] は、Codeforcesのコンテストで平均的な競技プログラマのレベル（上位約54%）に到達しました。手法は独特で、問題ごとに数百万のプログラムを生成し、フィルタリングとクラスタリングで10プログラムに絞り込みます。計算コストは高いですが、多様な解法を探索できるという利点がありました。

2022年11月30日、状況を一変させる出来事が起きました。OpenAIがChatGPTを無料の研究プレビューとして公開しました [OpenAI, ChatGPT Release 2022]。GPT-3.5をベースに、RLHF（Reinforcement Learning from Human Feedback）で対話向けにファインチューニングしたこのチャットボットは、当時史上最速でユーザーを獲得しました^[4]。

RLHFはLLMの振る舞いを人間の好みに合わせるための重要な技術です [Christiano et al., NeurIPS 2017]。以下は技術的な詳細です。まず人間のラベラーがモデルの出力に対して好みをランク付けし、そのデータから報酬モデル（Reward Model）を訓練します。次にPPO（Proximal Policy Optimization）を使って、報酬モデルのスコアを最大化するようにLLMを調整します。PPOは更新幅を制限することで学習を安定させる手法です。また、KLペナルティにより元のSFTモデルから大きく逸脱することを防ぎ、報酬ハッキング（報酬スコアは高いが意味不明な出力を生成する現象）を抑制します。この手法により、モデルは有害な出力を避け、人間が好む出力を生成するようになります。

ChatGPTは技術的には革新的ではありませんでしたが、対話型インターフェースによりLLMの能力を一般の人々に示したという点で、社会的インパクトは大きいものでした。プログラマでなくてもAIにコードを書かせられることを多くの人が初めて体験し、AIコーディングツールへの期待と投資が急増しました。

2023年3月14日、OpenAIはGPT-4を発表しました [OpenAI, GPT-4 Technical Report 2023]。GPT-4はテキストと画像の両方を入力として受け付けるマルチモーダルモデルであり、GPT-3.5から性能が大きく改善しました。司法試験では受験者の上位10%に相当するスコアを記録したとOpenAIは発表しました（GPT-3.5は下位10%）^[5]。

コーディング性能も上がり、HumanEvalでGPT-4は67.0%に到達しました（GPT-3.5は48.1%）。同月、GitHubはGPT-4を基盤とするCopilot Xを発表 [GitHub Blog, Copilot X 2023]。IDE内での対話型コーディング支援という新しいパラダイムが始まりました。

推論能力の進化

LLMの能力の伸びは、モデルサイズの拡大だけでなく、推論を引き出す手法の発展によっても加速しました。

2021年、Google ResearchのMaxwell Nyeらは "Scratchpad" という手法を提案しました [Nye et al., arXiv 2021]。LLMに中間計算ステップを出力させることで、複雑な多段階計算の性能が改善することを示しました。これはChain-of-Thought（CoT）の先駆けとなる重要な発見でした。

2022年1月、同じくGoogleのJason Weiらは "Chain-of-Thought Prompting" を発表しました [Wei et al., NeurIPS 2022]。「まず〜を計算し、次に〜」という中間推論ステップを含む例をプロンプトに含めることで、LLMの推論能力が高まります。

標準プロンプティング（左）とChain-of-Thought Prompting（右）の比較。標準プロンプティングでは誤答するが、CoTでは推論過程（青・緑でハイライト）を明示することで正答に到達する。算術、常識推論、記号推論など複雑なタスクに有効。出典: [Wei et al., NeurIPS 2022]

推論ステップの例を与えなくても、"Let's think step by step"（ステップごとに考えてみよう）という一文をプロンプトに加えるだけで、LLMは自ら推論過程を生成します [Kojima et al., NeurIPS 2022]。GSM8Kベンチマークでは、この一文を加えるだけで精度が10.4%から40.7%へと約30ポイント向上しました。モデルの重みは一切変えていません。この発見は、LLMの能力が訓練時に固定されるのではなく、推論時の引き出し方に大きく依存することを示しています。

コード生成においてこの原理を最も巧みに応用したのが、PAL（Program-aided Language Models） [Gao et al., arXiv 2022] です。自然言語の推論をPythonコードに変換し、インタプリタで実行します。LLMは算術計算が苦手ですが、計算を書くことは得意だという逆説的な特性を利用しました。これは、LLMが 23×47 を正確に計算するのは難しくても、print(23*47) というコードを生成することは訓練データのパターンから容易にできるためです。実際の計算は外部のPythonインタプリタが行います。GSM8Kでは従来のCoTを15%上回りました。

一方、訓練手法の革新も進みました。2023年6月のPhi-1 [Gunasekar et al., arXiv 2023] は、データの質がモデルサイズを補えることを実証しました。わずか7Bトークンの「教科書品質」データで1.3Bパラメータモデルを訓練し、10倍大きなモデルに匹敵するHumanEval 50.6%を達成。量より質という単純な教訓ですが、再現は容易ではありません。高品質なデータをどう定義し、どう生成するかが新たな競争軸になりました。

オープンなCode LLM^[6]も躍進しました。StarCoder [Li et al., TMLR 2023] が33.6%（プロンプティングで40%に到達）、Code Llama-34B-Python [Rozière et al., arXiv 2023] が53.7%のHumanEval pass@1を記録。これらが商用利用可能なライセンスで公開されたことで、企業が自社コードベースでカスタマイズする道が開けました。

この民主化を技術的に支えたのが、LoRA [Hu et al., ICLR 2022] とQLoRA [Dettmers et al., NeurIPS 2023] です^[7]。フルファインチューニングには数百GBのVRAMが必要だったものが、消費者向けGPUで可能になりました。大企業だけでなく、スタートアップや研究室でもコードモデルのカスタマイズが現実的になりました。

2024年後半から2025年にかけて、オープンなCode LLMはクローズドモデルに着実に追いつきました。

StarCoder2 [Lozhkov et al., arXiv 2024] は619言語をカバーするThe Stack v2データセット（v1の4倍）で訓練されました。AlibabaのQwen 2.5 Coder 32B [Qwen Team, arXiv 2024] はHumanEvalで92.7%に到達し、オープンモデルとして初めてGPT-4に匹敵する性能を示しています。

DeepSeek V3 [DeepSeek AI, arXiv 2024] は671BパラメータのMixture of Experts（MoE）アーキテクチャを採用し、2,048台のH800 GPUでわずか2ヶ月という効率的な訓練を達成しました。この「大きくても安く訓練できる」アプローチにより、計算資源の限られた組織でも大規模モデルを扱えるようになりました。

ただし、オープンソースのコード訓練データには法的な課題もあります。The Stack [Kocetkov et al., arXiv 2022] はGitHubの許容ライセンス（MIT、Apache等）のコードのみを収集していますが、GPLなどのCopyleftライセンスは派生物の定義が曖昧なため除外されています。2022年11月に提起されたGitHub Copilot訴訟（Doe v. GitHub, Inc., Case No. 4:22-cv-06823-JST, N.D. Cal.）は2025年時点で第9巡回控訴裁判所への中間上訴中であり [CourtListener, Doe v. GitHub 2022]、訓練データとしてのオープンソースコードの法的取り扱いはまだ確立されていません。

こうしたオープンモデルの発展とその法的課題はさておき、Code LLM全体が直面していた技術的限界があります。HumanEvalの限界も明らかになりつつありました。単一の関数を書くタスクは、実世界のソフトウェア開発のごく一部に過ぎません。リポジトリ全体を理解し、複数ファイルを編集し、テストを実行するという複合的なタスクには、新しいパラダイムが必要でした。

さらに深刻な問題も浮上しました。LLMはコンテキストウィンドウが拡大しても、その全体を有効に活用できていませんでした。StanfordのNelson F. Liuらによる"Lost in the Middle" 研究 [Liu et al., TACL 2023] は、LLMが入力の先頭と末尾に比べて中間部分の情報をうまく利用できないことを定量的に示しました。20文書のマルチドキュメントQAで、GPT-3.5-Turboは先頭位置で75.8%、末尾で63.2%の精度を達成する一方、中間位置では53.8%まで低下しました。これはclosed-book（文書なし）の56.1%をも下回ります。文書を与えているにもかかわらず、中間に置かれた情報は「ないも同然」になってしまいます。

NVIDIAのRULERベンチマーク [Hsieh et al., arXiv 2024] の発見も示唆的です。ほとんどのオープンモデルは、公称コンテキスト長（モデルが処理可能と公表している最大トークン数）の50%未満しか実効的に（実際のタスクで有効に）利用できていません。128Kを主張するモデルの実効コンテキストは64K、200Kを主張するモデルでも実効32K程度という例が珍しくありません。Needle-in-a-Haystackテスト（長文中から特定情報を探す）では好成績を収めるモデルでも、より複雑なタスクではコンテキスト長の増加とともに性能が急落します。

20文書QAにおけるGPT-3.5-Turboの精度。正解文書が先頭にあると約75%だが、中間（10番目付近）では約54%まで低下し、赤破線のclosed-book（約56%）を下回る。文書を与えているのに「ないより悪い」状態になる。出典: [Liu et al., TACL 2023]

対策としては、重要情報を先頭・末尾に配置する方法や、入力自体を圧縮する方法が提案されています。コンテキストウィンドウの拡大は万能ではなく、この課題は後のエージェントアーキテクチャにおけるメモリ管理の設計に影響を与えました。

スケーリング則の発見と進化

LLMの性能向上は、単なるアーキテクチャの改良だけでなく、規模の拡大によって実現されてきました。

2020年、OpenAIのJared Kaplanらはスケーリング則を発見しました [Kaplan et al., arXiv 2020]。モデルのパラメータ数Nと事前学習データ量Dを増やすと、損失Lがべき乗則に従って減少します。

この発見の意義は、技術的側面にとどまりません。それまでAI研究は職人芸の側面が強く、アーキテクチャの工夫や学習手法の改良が性能向上の主な源泉でした。しかしスケーリング則は、計算資源とデータがあれば予測可能な形で性能が向上することを示しました。これにより、AI研究は「発明」から「投資」の問題へと転換しました。数十億ドル規模の投資が合理的になったのは、リターンが予測可能になったからです。同時に、これは研究の民主化とは逆方向への動きでもありました。最先端の研究には巨大な資本が必要になり、大企業と学術機関の間の格差が広がりました。

スケーリング則の実験結果。計算量・データ量・パラメータ数の増加に伴い、テスト損失がべき乗則に従って減少する（両対数グラフで直線関係）。出典: [Kaplan et al., arXiv 2020]

2022年、DeepMindのJordan Hoffmannらによる「Chinchilla」研究 [Hoffmann et al., NeurIPS 2022] はKaplanの知見を修正しました。彼らは計算予算（GPU時間×GPU数で決まる総計算量）を固定したとき、パラメータ数Nと訓練トークン数Dをどう配分すべきかを体系的に調査しました。この問いは実務的に重要です。「予算内で最も高性能なモデルを作るには？」という問いに直接答えるからです。結論は明快でした。「パラメータ数とトークン数は同じ比率でスケールすべきである」。Kaplanは「パラメータを増やせ」と示唆していましたが、Chinchillaは「データも同じだけ増やせ」と主張しました。

この発見の実務的影響は大きなものでした。当時の最大モデルであるGopher（280Bパラメータ）は、Chinchillaの基準では「過小訓練」でした。同じ計算予算で70Bパラメータのモデルを4倍のデータで訓練すれば、より高性能になる。実際、Chinchilla（70B）はGopher（280B）を上回りました。MetaのLLaMA [Touvron et al., arXiv 2023] はこの知見を直接応用し、7B〜65Bのモデルをより多くのトークンで訓練することで、より大きなモデルに匹敵する性能を実現しました。現在のオープンLLMの多くは、このChinchilla最適化の恩恵を受けています。

推論時計算という新しい軸

しかし、パラメータを増やしてもデータを増やしても、収穫逓減が働きます。事前学習だけでは限界があるのではないか。2023年、OpenAIの "Let's Verify Step by Step" 研究 [Lightman et al., arXiv 2023] は、別のアプローチを示しました。従来のOutcome Reward Model（ORM）は最終回答のみを評価するのに対し、Process Reward Model（PRM）は推論の各ステップを評価します。

MATH-500ベンチマークでは、PRMは78.2%の精度を示し、ORMの72.4%を上回りました。各ステップを検証することで、途中で誤った推論に陥るのを防ぎ、より確実に正解へ到達できます。

ORM（結果監督）とPRM（プロセス監督）報酬モデルの比較。問題あたりの解候補数Nを増やすと、PRMはORMやMajority Votingを一貫して上回る。N=1860でPRMは78.2%、ORMは72.4%、Majority Votingは69.6%を達成。出典: [Lightman et al., arXiv 2023]

この知見は、2024年9月にOpenAIがリリースしたo1に結実しました [OpenAI, Blog 2024]。o1は従来のLLMとは根本的に異なるアプローチを採用しています。大規模な強化学習を用いて訓練され、回答を生成する前に長い「思考の連鎖」を内部で展開します。これは推論時計算スケーリング（test-time compute scaling）という新しいパラダイムの具現化です。

Snellらの研究 [Snell et al., arXiv 2024] は、この推論時計算スケーリングを理論的に分析しました。問題の難易度に応じて思考時間を調整することで、同じモデルでもはるかに良い結果を得られます。簡単な問題には少ない計算を、難しい問題にはより多くの計算を割り当てる適応的なアプローチです。

o1のAIME（American Invitational Mathematics Examination）精度。左図は訓練時計算量、右図は推論時計算量に対するpass@1精度を示す。両者とも対数スケールで直線的に向上しており、推論時計算が訓練時計算と同様にスケールする新たな軸であることを示している。出典: [OpenAI, Learning to Reason with LLMs 2024]

o1はAIMEで83%の精度を達成し、競技プログラミングでも高い性能を示しました^[8]。その後継であるo3は、Codeforcesで2727のレーティング（世界175位相当、99.8パーセンタイル）を達成しました [OpenAI, Competitive Programming with LRMs 2025]。DeepSeek-R1 [DeepSeek, arXiv 2025] は純粋な強化学習で同様の推論能力を向上させる可能性を示しました。

このアプローチの重要性は、スケーリングの軸を増やしたことにあります。モデルサイズの増大には物理的・経済的限界がありますが、推論時の計算量は問題ごとに柔軟に調整できます。困難な問題には数分間「考える」ことを許容し、簡単な問題には即座に回答する。人間が難問に直面したとき時間をかけて熟考するのと同じです。Chain-of-Thoughtプロンプティングの自然な発展とも言えます。

一方、実際の開発ではファイル操作、テスト実行、デバッグといった複数ステップを自律的にこなす必要があります。この役割を担うのがエージェントです。

エージェントの台頭（2024-2025）

「エージェント」という概念自体は、AI研究の黎明期から存在していました。

NewellとSimonが1957年に開発したGPS（General Problem Solver） [Newell & Simon, 1961] は、目標と現状の差を分析して操作を選択する「手段目標分析」を提案しました。しかしGPSは限定的な問題にしか適用できませんでした。1970-80年代の専門家システム（MYCIN [Shortliffe, PhD Thesis 1975]、R1/XCON [McDermott, Artificial Intelligence 1982]）も同様に、知識獲得のボトルネックに阻まれました。人間の専門家から知識を抽出し、ルールとして記述するコストが膨大だったのです。

1980年代に提案された概念の多くは、今日のエージェントにそのまま残っています。SOARの問題空間探索 [Laird et al., Artificial Intelligence 1987]、BDIの信念-欲求-意図モデル [Bratman, Harvard University Press 1987]、Wooldridge & Jenningsによるエージェントの定義 [Wooldridge & Jennings, The Knowledge Engineering Review 1995]。Wooldridge & Jenningsはエージェントを、外部制御なく独立して行動し（自律性）、他のエージェントや人間と協調し（社会性）、環境の変化を知覚して応答し（反応性）、目標に向かって主体的に行動を起こす（能動性）存在として定義しました。アーキテクチャのアイデアは揃っていました。足りなかったのは、人間が言語で表現してきた暗黙知を大規模に獲得する方法でした。

2013年のDQN（Deep Q-Network） [Mnih et al., arXiv 2013]、2016年のAlphaGo [Silver et al., Nature 2016] は、深層学習と強化学習の融合で環境との相互作用から学習できることを示しました。ただし、これらは明確に定義されたゲーム環境でのみ機能し、オープンエンドなタスクには適用できませんでした。

LLMがブレイクスルーとなった理由は、Transformerアーキテクチャによる並列処理と長距離依存の学習が、知識獲得のボトルネックを解消したからです。インターネット上のテキストから暗黙知を大規模に獲得し、自然言語でのインターフェースを可能にしました。2023年のReAct [Yao et al., ICLR 2023] のThought-Action-Observationループは、GPSの手段目標分析やBDIの意図的行動と概念的な類似性を持っています。ただし、ReActの論文自体はこれらの古典的研究を直接引用しておらず、アーキテクチャとしては別系統の発展と見るべきでしょう。半世紀前から存在した目標指向の問題解決という概念が、LLMの言語能力と組み合わさることで初めて実用的になりました。

2023年10月、PrincetonのCarlos E. JimenezとJohn Yangらが発表したSWE-benchは、コード生成エージェント評価のパラダイムを一変させました [Jimenez et al., ICLR 2024]。SWE-benchは、Django、scikit-learn、matplotlib等の12の人気Pythonリポジトリから収集した2,294のGitHub issue-PRペアで構成されています。モデルはissue記述を読み、実際にパッチを生成してテストをパスさせなければなりません。

これはHumanEvalとは根本的に異なります。コードベース全体を理解し、適切なファイルを見つけ、一貫した編集を行い、既存のテストを壊さないようにする必要があります。発表時、最高性能のモデルでも解決率は数%に過ぎませんでした。

2024年3月12日、スタートアップCognition AIが発表したDevinは、最初のAI Software Engineerとして注目を集めました [Cognition Labs, Official Blog 2024]。X（Twitter）での発表は3,100万ビュー以上を記録し、元Tesla AIディレクターのAndrej Karpathyが印象的なデモと評しました。発表時のSWE-bench性能は13.86%（unassisted）で、当時の最高スコアでした。

Devinは単なるコード補完ツールではなく、自律的にブラウザを操作し、ターミナルでコマンドを実行し、ファイルを編集するエージェントでした。しかし、冷静な分析も必要です。Devinのデモは印象的でしたが、実際の開発現場での性能は限定的だったという報告もあります。エージェントの評価は、ベンチマークスコアだけでは不十分であることが明らかになりつつありました。

エージェントを支える基盤技術

現代のコード生成エージェントは、複数の重要な研究成果の上に構築されています。

2020年に発表されたRAG（Retrieval-Augmented Generation） [Lewis et al., NeurIPS 2020] は、LLMの知識の限界を外部データベースで補完するアプローチです。エージェントがコードベースを検索し、関連するファイルを取得してコンテキストに含めるという動作は、RAGの応用です。

MetaのSchickらによるToolformer [Schick et al., arXiv 2023] は、LLMが自律的に外部ツールの使い方を学習できることを示しました。計算機、検索エンジン、翻訳システムなど、LLMが苦手とするタスクを外部ツールに委譲することで、モデルの弱点を補完します。この研究は、現代のエージェントにおけるツール使用の理論的基盤となりました。

推論の構造化も進展しました。PrincetonのYaoらによるTree-of-Thoughts [Yao et al., NeurIPS 2023] は、Chain-of-Thoughtを木構造に拡張し、複数の推論パスを探索・評価・バックトラックできるようにしました。Game of 24タスクでは、GPT-4のCoTが4%しか解けなかったのに対し、ToTは74%を達成しました。Graph of Thoughts [Besta et al., AAAI 2024] はこれをさらに発展させ、推論を任意のグラフ構造で表現することで、複数の思考を統合・洗練・分岐させることを可能にしました。

現代のエージェントの行動様式の基盤となっているのが、PrincetonのShunyu Yaoらによる ReAct（Reasoning and Acting）です [Yao et al., ICLR 2023]。ReActの核心は、Thought → Action → Observationのループで推論と行動を融合することにあります。

以下はReActの実装例です。

# ReActループの実装例

class ReActAgent:
    def __init__(self, model, environment):
        self.model = model
        self.env = environment
        self.context = []

    def solve(self, task):
        self.context = [f"Task: {task}"]

        while not self._is_completed():
            # 思考：現状を分析
            thought = self.model.generate(
                self.context + ["Thought:"],
                stop=["\n"]
            )
            self.context.append(f"Thought: {thought}")

            # 行動：具体的なアクションを決定
            action = self.model.generate(
                self.context + ["Action:"],
                stop=["\n"]
            )
            self.context.append(f"Action: {action}")

            # 観察：環境からのフィードバック
            observation = self.env.execute(action)
            self.context.append(f"Observation: {observation}")

        return self._extract_result()

上記の実装が生成するトレースの例を示します。

Task: user_auth.pyのバグを修正（スペース入りメールでログイン失敗）
Thought: まずファイルを確認する必要がある
Action: read_file("src/user_auth.py")
Observation: [ファイル内容]
Thought: 正規表現がスペースを処理していない
Action: edit_file("src/user_auth.py", line=42, ...)
Observation: 更新完了
Thought: テストで確認する
Action: run_tests("tests/test_auth.py")
Observation: 全テスト合格

同じPrincetonチームが2024年5月に発表したSWE-agent [Yang et al., NeurIPS 2024] は、Agent-Computer Interface（ACI）という概念を導入しました。LMエージェントとコンピュータ間の抽象化レイヤーを最適化し、ファイルナビゲーション、編集、テスト実行などの操作を効率化しています。

コンピュータを操作するエージェント

コード生成の次の段階は、コンピュータそのものの操作でした。2024年10月22日、AnthropicはClaude Computer Useを発表しました [Anthropic, Computer Use 2024]。スクリーンショットを視覚的に認識し、マウス操作やキーボード入力を自律的に行う初のフロンティアAIです。

実際に試すと、その可能性と限界の両方が見えてきます。OSWorld [Xie et al., NeurIPS 2024] というベンチマーク（人間の達成率72.36%）で、Claude Computer Useの初期スコアは14.9%。2025年1月のOpenAI Operator [OpenAI, Operator 2025] でも38.1%です。デモで見る印象とは裏腹に、人間のスコア（72.36%）と比較するとまだ大きな開きがあります。

さらに厄介な問題があります。ウェブページに埋め込まれた悪意ある指示で、エージェントがマルウェアをダウンロード・実行するプロンプトインジェクション攻撃が既に実証されています [Rehberger, Claude Computer Use C2: The ZombAIs Are Coming 2024]。人間が見ても気づかない指示に、エージェントは従ってしまいます。自律性の向上は、攻撃対象の拡大と表裏一体です。

一方、オープンソースコミュニティでは別のアプローチが広がっています。OpenHands [All-Hands-AI, OpenHands GitHub 2024] やAider [Gauthier, Aider GitHub 2024] は、フルスクリーン操作ではなくターミナルベースのペアプログラミングに焦点を当てています。派手さはありませんが、攻撃面も小さくなります。

マルチエージェント vs シングルエージェント

マルチエージェントという方向性も模索されています。MetaGPT [Hong et al., ICLR 2024] やChatDev [Qian et al., ACL 2024] は、プロダクトマネージャー、アーキテクト、エンジニアなど複数の役割を分担して協調します。しかしUIUCのAgentless [Xia et al., arXiv 2024] は、エージェントを使わない3段階パイプライン（ローカライズ→修正→検証）で、問題あたりわずか$0.70という低コストでSWE-bench Liteの32.00%を達成しました。複雑なマルチエージェント協調がなくても、問題の構造を捉えたシンプルな設計で競争力のある性能が得られることを示しています。

2025年6月12日、Cognition AI（Devinの開発元）のCo-founder Walden Yanが "Don't Build Multi-Agents" というブログ記事を公開しました [Cognition AI, Blog 2025]。記事は、マルチエージェントシステムが根本的に脆弱であると主張しています。

Cognitionの主張の核心は、コンテキスト共有の困難さにあります。複数のエージェントが協調する際、各エージェントは他のエージェントの状態や判断を完全には理解できません。結果として、調整オーバーヘッドが性能を相殺してしまう。彼らは代わりに、単一スレッドの線形エージェントとコンテキスト圧縮を推奨しています。

一方、翌日の6月13日にAnthropicはResearch機能のマルチエージェント実装について詳細な技術記事を公開しました [Anthropic, Engineering Blog 2025]。ただしAnthropicの基本スタンスは "Building Effective Agents" [Schluntz & Zhang, Anthropic 2024] で示された「シンプルから始め、必要な場合にのみ複雑さを追加する」という原則であり、マルチエージェントは特定のユースケース（並列リサーチなど）での設計選択です。

MicrosoftやLangChainもマルチエージェントのツールやフレームワークを提供していますが、これは「支持」というより「選択肢の提供」という位置づけです。2024年10月にリリースされたOpenAI Swarm [OpenAI, GitHub 2024] は、「ルーティンとハンドオフ」によるエージェント間の協調を実現する実験的なフレームワークであり、2025年にはOpenAI Agents SDKに進化しました。MicrosoftのAutoGen v0.4（2025年1月発表）[Microsoft Research, AutoGen 2025] は、イベント駆動型アーキテクチャを採用し、スケーラブルな分散エージェントシステムを目指しています。

この論争は、モノリス vs マイクロサービスの構図に類似しています。両アプローチはLLMの根本的制約（ステートレス性とコンテキストウィンドウの限界）に対する異なる回避策であり、一貫性とスケーラビリティのトレードオフは依然として存在します。

コンテキストエンジニアリング

エージェントアーキテクチャの進化において、メモリ管理は重要な課題でした。前述のLost in the Middle問題が示すように、LLMは長いコンテキストを効果的に活用できません。この制約を回避するため、OSのメモリ管理に着想を得たアプローチが登場しました。

UC BerkeleyのCharles Packerらが提案したMemGPT [Packer et al., arXiv 2023] は、LLMをOSのプロセッサに見立て、メインコンテキスト（RAM相当）と外部コンテキスト（ディスク相当）の階層的メモリを導入しました。エージェントは関数呼び出しによってメモリ間でデータを移動させ、限られたコンテキストウィンドウを仮想的に拡張します。このアプローチにより、コンテキストウィンドウを超える長大なドキュメントの分析や、複数セッションにまたがる対話が可能になりました。

PrincetonのNoah Shinnらによる Reflexion [Shinn et al., NeurIPS 2023] は、別の方向からメモリ問題にアプローチしました。Reflexionは重みを更新せずに言語的フィードバックのみで学習する手法です。エージェントはタスク実行後に自己反省を行い、その内容をエピソード記憶として保持します。次のトライアルではこの反省を参照して行動を改善します。この手法はHumanEvalで91% pass@1を達成し、同論文でのGPT-4ベースライン（80%）を大きく上回りました。モデルの再訓練なしにこの改善が得られた点が示唆的です。

これらのメモリアーキテクチャは、単なるコンテキスト拡張を超えた意味を持ちます。エージェントが過去の経験から学び、失敗を繰り返さない仕組みへの取り組みです。

2025年6月、こうした課題への取り組みを統合する概念が確立されました。"Context Engineering" です。元Tesla AIディレクターのAndrej Karpathyは [Karpathy, X/Twitter 2025]、こう定義しています。

context engineering is the delicate art and science of filling the context window with just the right information for the next step.

コンテキストエンジニアリングとは、次のステップに必要な情報を的確にコンテキストウィンドウに収める、繊細な技術であり科学である。

従来のPrompt Engineeringとの違いを整理します。

Anthropicの定義によれば、「コンテキストとはLLMからサンプリングする際に含まれるトークンの集合であり、エンジニアリングの問題はLLMの固有の制約に対してそれらのトークンの有用性を最大化すること」です [Anthropic, Effective Context Engineering for AI Agents 2025]。

エージェントの失敗の多くは、もはやモデルの失敗ではなくコンテキストの失敗です。Lost in the Middle、MemGPT、Reflexionといった研究は、この問題の異なる側面に取り組んでいたことになります。

Vibe CodingとAgentic Engineering

2025年、AI支援開発をめぐる哲学的な対立が鮮明になりました。2025年2月、Karpathyは "Vibe Coding" を提唱しました [Karpathy, X 2025]。"forget that the code even exists"（コードの存在すら忘れる）という宣言のもと、差分を読まず、エラーをそのままコピペし、コードが理解を超えて成長するスタイルです。この用語は急速に広まり、Collins Dictionaryが2025年のWord of the Yearに選出するほどの影響力を持ちました [Collins Dictionary, Word of the Year 2025]。Y Combinator CEO Garry Tanは「2025年冬バッチの25%で、95%のコードがLLM生成」と報告しています [Garry Tan, X 2025]。

しかし、この用語には批判もあります。Google Brainの共同創業者Andrew Ngは "It's unfortunate that that's called vibe coding"（残念な名前だ）と述べ、「実際には深く知的な作業であり、一日中AIとコーディングすると正直疲れ果てる」と指摘しました [Andrew Ng, LangChain Interrupt 2025]。Djangoの作者Simon Willisonも "Vibe coding your way to a production codebase is clearly risky"（Vibe Codingでプロダクションコードベースを作るのは明らかにリスクがある）と警告しています [Willison, simonwillison.net 2025]。

対極に位置するのが "Agentic Engineering" です。2025年6月、ZedエディタのNathan Soboがこのコンセプトを体系化しました [Zed, Agentic Engineering 2025]。"measure our contribution not in lines of code generated, but in reliable, well-designed systems"（貢献は生成されたコード行数ではなく、信頼性が高く設計の良いシステムで測るべきだ）というのが核心です [Zed Blog, Software Craftsmanship 2025]。AIがコード生成を容易にするからこそ、設計の質を高めるべきだという主張です。乱雑なコードベースは人間だけでなくAIツールの効果も低下させるため、技術的負債の影響は増幅されます。

本番環境向けエージェント設計の原則も確立されてきています。HumanLayerのDex Horthyが2025年初頭に発表した "12 Factor Agents" は、2011年のHerokuによる12-Factor App [Wiggins, The Twelve-Factor App 2011] の精神をAIエージェントに適用したものです [HumanLayer, 12 Factor Agents 2025]。

"most of the products out there billing themselves as 'AI Agents' are not all that agentic [...] And that's fine!"（「AIエージェント」を名乗る製品のほとんどは、それほどエージェント的ではない。でもそれで良いのだ）と述べ、本当に成功しているAIエージェントのほとんどは、決定論的なコードにLLMを適切に組み込んだものだと指摘しています。核心的な原則として、プロンプトとコンテキストウィンドウの明示的管理、制御フローの所有、人間へのエスカレーションをツール呼び出しとして扱うこと、100ツール未満・20ステップ未満の小さく焦点を絞ったエージェント設計などが挙げられています。

この対立は開発手法の違いにとどまりません。コードが動くことと、コードを理解していることは別です。Vibe Codingは前者を、Agentic Engineeringは後者を重視します。

ただ、この二項対立は実践的ではありません。問いは「どちらを選ぶか」ではなく「いつ、どちらを使うか」です。プロトタイプでは速度が、本番システムでは保守性が優先されます。

こうした技術的負債は、AIがコード生成を容易にするほど蓄積しやすくなります。速度と規律のトレードオフは永遠の課題ですが、ツールが強力になるほど判断の重みは増します。12 Factor Agentsのような設計原則は、この複雑さを管理するための具体的な指針を提供しています。

SWE-bench Verified 80%の現在地（2025年）

数字だけ見れば、進化は目覚ましいものがあります。SWE-bench Verified^[9]は実際のGitHub issueを解決できるかを測定するベンチマークですが、オリジナルのSWE-benchで2023年に約2%だったスコアが、2024年8月のVerified版リリース時に33%、2025年には80%超へと急上昇しました [Epoch AI, SWE-bench Verified 2025]。

しかし、この急上昇はモデルの能力向上だけでなく、ベンチマークの飽和（saturation）という現象も反映しています。Epoch AIの研究によれば、ベンチマークスコアが100%に近づくと、モデル間の差異を測定できなくなります [Epoch AI, Rosetta Stone 2025]。GSM8K、MATH、HumanEvalといった従来のベンチマークはすでに飽和に達しており、SWE-bench Verifiedも同様の傾向を示しています。80%という数字は「すごい」というより「このベンチマークでの差別化が困難になりつつある」サインでもあります。

SWE-bench Verifiedにおける各モデルの性能推移（2025年10月まで）。Anthropic（紫）、OpenAI（ピンク）、Google（青緑）、その他（茶）で色分け。Epoch AIによる独自測定のため、公式発表値と若干異なる場合があります。出典: [Epoch AI, SWE-bench Verified Benchmark 2025]（CC-BY）

2025年11月時点の上位モデル：

しかし、より難しいSWE-bench Pro^[10]になると状況は一変します [Scale AI, SWE-bench Pro Leaderboard]。トップモデルでも40%台前半（Claude Sonnet 4.5が43.6%、Gemini 3 Pro Previewが43.3%）。SWE-bench Verifiedが飽和に近づく一方、Proではまだ十分な差別化が可能です。この差が示すのは、問題の複雑さによる性能劣化です。Verifiedは比較的よく定義された単一ファイルの修正が中心ですが、Proはより複雑な依存関係、曖昧な要件、複数ファイルにまたがる変更を含みます。ベンチマークが飽和するたびに、より難しいベンチマークへ移行する。これがAI評価の現実です。

Epoch AIはベンチマーク飽和の問題に対処するため、複数のベンチマークを統合したEpoch Capabilities Index（ECI）を開発しました [Epoch AI, ECI 2025]。個別のベンチマークが飽和しても、異なる難易度のベンチマークを組み合わせることで、モデル間の能力差を継続的に測定できます。

ベンチマークの信頼性

ベンチマーク評価にはデータ汚染（Data Contamination）の懸念があります。MBPPでは65.4%の問題が訓練データに含まれている可能性が指摘されています [Ni et al., EMNLP Findings 2024]。ベンチマークの過半数が汚染されているとすれば、スコアの意味は根本から問い直されます。

SWE-benchについては、SWE-bench+研究 [Aleithan et al., arXiv 2024] が詳細な分析を行いました。32.67%のケースでissue記述やコメントに解答が漏洩しており、モデルは独自に解決策を生成するのではなく、提供された情報から抽出していました。これとは別に、31.08%のケースでは、モデルの変更が不正確または不完全でありながらテストをパスしており、テスト自体が弱すぎることを示しています。少なくとも一方の問題を持つケースは63.75%に達し、「正しく解けた」と見なせるケースは約36%に過ぎません。

2025年9月には新たな抜け穴も発見されました [SWE-bench Issue #465]。Claude Sonnet 4やQwen3-Coderがgit log --allコマンドで将来のコミット（修正内容を含む）を参照していたのです。SWE-benchは元々リモートを削除していましたが、タグやreflogには将来の情報が残っており、それが悪用されました。これは「モデルが問題を解いた」のではなく「答えをカンニングした」ことを意味します。

HumanEvalについても、GPT-4技術レポートは25%が事前学習データに混入していた可能性を認めています。EvalPlus [Liu et al., NeurIPS 2023] は、HumanEvalの元のテストケースが平均7.7件しかなく、多くの誤った解がテストを通過していたことを発見しました。テストカバレッジを80倍に拡張した結果、正しいとされていた解の14〜19%が実際には不正確でした。従来の評価がいかに楽観的だったかを示しています。

こうした汚染問題への対策として、新しいベンチマークも登場しています。LiveCodeBench [Jain et al., arXiv 2024] は、LeetCode、AtCoder、CodeForcesから継続的に新しい問題を収集し、問題の公開日がモデルの訓練日より後であることを保証する「時間軸による汚染防止」という設計を採用しています。BigCodeBench [Zhuo et al., arXiv 2024] は1,140タスクで139ライブラリの実践的な使用を評価し、GPT-4oが60%を達成する一方、人間の専門家は97%と、依然として大きなギャップがあります。

K Prize [Konwinski, K Prize 2025] は、2025年3月12日以降のGitHub issueのみを使用する汚染フリーのベンチマークです。第1回の結果は示唆的でした。SWE-bench Verifiedで75%を達成するモデルが存在する一方、K Prizeでは最高7.5%という結果でした。評価条件が異なるため直接比較はできませんが、訓練データに含まれない新しい問題への汎化能力が、既存ベンチマークでは測定できていないことが明らかになりました。

現在のベンチマークは最低限の能力証明として有用ですが、実世界での有用性を完全に測ることはできません。K PrizeやSWE-bench Proのようなより現実に近いベンチマークを参照しつつ、産業導入においてはレビュー時間の短縮やバグ発生率の変化といった実務指標で評価する必要があります。

Claude Opus 4.5（2025年11月24日発表）[Anthropic, Official Blog 2025] は業界初の80%超えを達成しました^[11]。価格も入力$5/出力$25 per million tokensと、前モデルから約66%値下げされ、性能と経済性の両立を示しています。

GPT-5.1-Codex-Max [OpenAI, Official Blog 2025] はCompaction機能で複数のコンテキストウィンドウをまたいだ作業を可能にし、24時間以上の連続タスク実行を可能にしました。

エージェントエコシステムの標準化も進んでいます。2024年11月、Anthropicが発表したModel Context Protocol（MCP） [Anthropic, MCP Announcement 2024] は、エージェントとツールの統合方法を標準化しました。JSON-RPC 2.0上で動作するオープン標準として、従来のN×M統合問題^[12]を解決します。

2025年3月にはOpenAIが採用、Google DeepMindとの統合も進行中です。2025年4月にはGoogleがAgent-to-Agent Protocol（A2A）を発表しました [Google Developers Blog, A2A 2025]。MCPがLLMとツール間の「垂直統合」を担うのに対し、A2Aはエージェント間の「水平統合」（タスク委譲や協調）を標準化します。同年6月にはLinux Foundationに寄贈され、AWS、Microsoft Azure、Adobe、Salesforceを含む150以上の企業が参加を表明しています。GoogleはA2AをMCPの「補完」と位置づけており、両プロトコルの共存によるエコシステム標準化が進んでいます。

産業導入も加速しています。GitHub Copilotは2025年7月時点で累計2,000万ユーザーを突破し、Fortune 100企業の90%が採用しています [TechCrunch, GitHub Copilot 2025]。Accentureとの共同研究では、コーディング速度が55%向上し、開発者の67%が週5日以上使用していると報告されています。

投資と経済性の転換点

AIコードツール市場は急成長を続けています。Grand View Researchによれば、AI Code Tools市場は2023年の48.6億ドルから2030年には260億ドル規模に成長すると予測されており、年平均成長率は27.1%です [Grand View Research, AI Code Tools Market 2024]。2024年の生成AI全体へのベンチャー投資は560億ドル（885件）に達し、2023年の291億ドルから92%増加しました [TechCrunch, GenAI Funding 2025]。

訓練コストの効率化も進んでいます。GPT-4の訓練には1億ドル以上がかかったとSam Altman CEOは述べています [Wired, Altman Interview 2023]。2024年12月リリースのDeepSeek-V3は競合モデルに匹敵する性能を約558万ドルのGPU計算コストで達成しました（総コストは推定13億ドル超）^[13]。

APIコストも急落しています。GPT-4は2023年3月に$30入力/$60出力（100万トークンあたり）でローンチしましたが [OpenAI, GPT-4 API Pricing 2023]、2024年8月のGPT-4oでは$2.50入力/$10出力と90%削減されました。DeepSeek-V3は2025年2月時点で$0.27入力/$1.10出力と、GPT-4oより約10倍安価です（2025年2月以前のプロモーション価格$0.14/$0.28からは値上げ）。

ツール市場の成長速度は異常です。CursorはVS Codeフォークのエージェント型IDEとして、2024年8月の4億ドル評価から15ヶ月で73倍の293億ドルに到達しました [Anysphere, Cursor Blog 2025]。ARR（年間経常収益）10億ドル突破、日次アクティブユーザー100万人超。OpenAI、Shopify、Stripeなど名だたる企業が採用しています。CursorのBugBotは100万以上のPRを自動レビューし、150万件の問題を発見したと報告されています [Anysphere, BugBot 2025]。

Cognition AI（Devin開発元）は2025年9月に102億ドル評価に達し、Windsurfの事業資産を買収しました。Codeiumが2024年11月にローンチしたWindsurf [Codeium, Windsurf Launch 2024] は「初のエージェント型IDE」を謳い、VS Codeフォークにエージェント機能 "Cascade" を統合していましたが、わずか1年で買収されました。

自然言語からアプリを生成するAIアプリビルダーも台頭しています。StackBlitzのBolt.newは5ヶ月で0から4,000万ドルのARRを達成し、2025年3月時点で500万ユーザーを獲得しました [Sacra, Bolt.new 2025]。VercelのV0は、UIコンポーネント生成から完全なエージェントプラットフォームへと進化しています。Replitは2025年9月にAgent 3をリリースし、最大200分の自律実行を実現しました [Replit, Agent 3 2025]。Computer Useアプローチより3倍高速で10倍コスト効率的とされています。

数字だけ見れば、開発者がこれらのツールを熱狂的に受け入れているように見えます。企業での導入事例も華々しく報告されています。日立製作所は2024年時点でGitHub Copilotを約2,000名で利用し、コーディング・単体テストで平均10-20%、最大30%の生産性向上を報告 [Microsoft Customer Stories, Hitachi 2024]。Google内部ではAI生成コードが新規コードの30%以上に達し、エンジニアリング速度は約10%向上したとSundar Pichai CEOは述べています [Alphabet, Earnings Call 2025]。

ただし、これらの数字には注意が必要です。METR 2025研究 [METR, arXiv 2025] は重要な知見を報告しています。16人の経験豊富なオープンソース開発者が、平均5年の経験を持つ成熟したプロジェクトで246タスクに取り組んだランダム化比較試験です。

結果は予想外でした。タスク開始前、開発者たちはAIツールが作業時間を24%短縮すると予測しました。タスク完了後も、20%短縮できたと感じていました。しかし実測値は逆でした。AIツールを使用した場合、タスク完了時間は19%長くなっていました。経済学の専門家は39%の改善を、機械学習の専門家は38%の改善を予測していましたが、いずれも大幅な過大評価でした。

多くの専門家が予測を誤った背景には、複数の認知バイアスが絡み合っています。AIが素早くコードを補完する瞬間、複雑な関数を一発で生成する体験は記憶に残ります。一方で、AIの提案を修正した時間、生成されたコードをレビューした時間、プロンプトを何度も調整した時間は、目に見えにくいオーバーヘッドとして埋もれていきます。さらに、開発者には「自分はAIを上手く使いこなしている」という自己効力感があります。タスク完了後も20%の短縮を感じていたという事実は、主観的な体験と客観的な測定の乖離を如実に示しています。

専門家・開発者の予測と実測値の乖離。緑は予測（時間短縮）、赤は実測（時間増加）。経済学専門家は-39%、ML専門家は-38%、開発者は事前-24%・事後-20%の短縮を予測したが、実測では+19%の時間増加が観測された。出典: [METR, arXiv 2025]

ただし、この研究の適用範囲には注意が必要です。調査対象は「経験豊富な開発者が、自分の熟知したコードベースで作業する」という特定の状況でした。逆に、Pengらの研究 [Peng et al., arXiv 2023] では、不慣れなコードベースや経験の浅い開発者では55.8%の効率向上が報告されています。

2025年8月のAnthropicの内部調査 [Anthropic, AI at Anthropic Research 2025] は、異なる視点を提供しています。132名のエンジニア・研究者と20万件のClaude Code使用ログを分析した結果、日次コードコミット数は67%増加していました。

同調査では、仕事の質的変化も報告されています。バックエンドエンジニアが複雑なUIを構築し、セキュリティチームが不慣れなコード分析に取り組むようになりました。27%の作業は「AIがなければ着手しなかった」もの、つまり従来は費用対効果に見合わなかった探索的な試みでした。エンジニアの役割は「コード作成者」から「AIの監督者」へ移行しており、「70%以上がコードレビューと修正」という回答もありました。

ただ、あるエンジニアは「デバッグ中にドキュメントやコードを読む時間が失われ、システムの理解モデルが構築できなくなっている」と警告しています。AIツールの製造元による調査である点は考慮すべきですが、生産性向上と引き換えに何が失われるかという問いは、この分野全体に関わります。

これらの研究は、単純な「効果あり/なし」という二項対立を超えた理解を促します。先述の隠れたオーバーヘッドの影響は状況によって異なり、新規プロジェクトや不慣れなコードベースでは効果的でも、開発者が深く理解している大規模コードベースでは直接コードを書く方が速い場合があります。

コード品質への影響も懸念されています。GitClearが2020〜2024年の2億1100万行を分析した結果 [GitClear, Code Quality Report 2025]、コピー＆ペーストコードが48%増加、リファクタリングが61%減少、2週間以内のチャーン率（書き直し率）が84%増加していました。Google DORA 2024レポートでも、AI採用25%増加ごとに配信安定性が7.2%低下するという相関が報告されています [DORA, State of DevOps 2024]。ソフトウェア開発コンサルタントのJason Gormanは、この現象を「Comprehension Debt（理解負債）」と呼んでいます [Gorman, Comprehension Debt 2025]。チームがLLM生成コードを理解するスピードより速く生成すると、将来の修正時に深刻な問題を引き起こすという警告です。品質を重視するチームはレビューと修正に時間をかけますが、それは時間短縮効果を相殺します。速度と品質のトレードオフは、AIコーディングツール導入における重要な考慮事項です。

開発者体験の変容

Stack Overflow 2025 Developer Survey [Stack Overflow, Survey 2025] によれば、84%の開発者がAIツールを使用中または使用予定です（2024年の76%から上昇）。とはいえ、AIの正確性を信頼する開発者はわずか33%に留まり、46%が不信感を抱いています。「使うけど信じない」という乖離が、現状を物語っています。

この姿勢は合理的です。AIをドラフト生成ツールとして使い、最終判断は人間が行うという分業パターンが、現時点での生産的な使い方として定着しています。

より深刻な懸念は、雇用市場全体の冷え込みです。2025年2月時点で、ソフトウェア開発者の求人は5年ぶりの低水準にあり、特にジュニアポジションの採用は20年ぶりの低水準とも報告されています [The Pragmatic Engineer, Jobs Report 2025]。2022年半ばのピークからは急落しており、追跡対象セクター中最大の急騰・急落サイクルを経験しています。

テック業界のレイオフは2024年に約15万人に達しました [Layoffs.fyi, Tech Layoffs 2024]。Microsoftは2025年に1.5万人以上を削減しつつAIに800億ドルを投資すると発表し [Fortune, Nadella Memo 2025]、CEOのSatya Nadellaは「GitHub Copilotが新規コードの30%を執筆している」と述べています。Salesforceも2025年にエンジニアの新規採用を停止し、AIによる生産性向上を理由に挙げています [Salesforce Ben, No More Engineers 2025]。人を減らしてAIに投資するという動きは、一企業の判断ではなく業界全体のトレンドになっています。

この影響は教育市場にも波及しています。2024年時点で、コンピュータサイエンス専攻の新卒失業率は6.1%に達し、哲学専攻の3.2%のほぼ2倍です [Federal Reserve Bank of New York, College Labor Market 2024]。かつて「就職に強い」とされた専攻が、いまや新卒全体の平均を上回る失業率を記録しています。

2025年秋学期のCS大学院入学者は前年比15%減少し [National Student Clearinghouse, Enrollment Estimates 2025]、エリートプログラム卒業生が主要テック企業に就職する割合も2022年の25%から11-12%へと半減しています [SignalFire, State of Talent 2025]。学生たちは敏感に市場の変化を感じ取っているのでしょう。

対照的に、AIスキルを持つエンジニアには顕著な給与プレミアムがあります。OpenAIでは年収94.5万ドル（中央値）、Staff Engineer以上ではAI専門家が非AI専門家を18.7%上回ります [Levels.fyi, AI Engineer Compensation 2025]。市場全体が縮小する中での二極化です。

2024年のMicrosoft Research調査によれば、AIツールの恩恵を最も受けるのはジュニア開発者です（生産性27-39%向上）。シニア開発者の改善は7-16%に留まります [Microsoft Research, GenAI Field Experiments 2024]。しかし、ジュニアを採用しなければ、数年後に経験を積んだミッドレベルエンジニアが不足するという懸念があります。「ジュニア開発者は将来のシニア開発者である」という当たり前の事実が、短期的な効率化によって見落とされている可能性があります。

未解決の課題

LLMはプログラミングを「理解」しているのでしょうか。それとも洗練されたパターンマッチングに過ぎないのでしょうか。

コード生成AIは大きく進歩しましたが、万能ではありません。LLMには本質的な限界があることも明らかになってきています。Arizona State UniversityのKarthik Valmeekamらによる研究 [Valmeekam et al., NeurIPS 2023] は、LLMの自律的計画生成能力を調査しました。国際計画競技（IPC）のドメインを用いた評価で、その時点で最も優秀なGPT-4でも平均約12%という限定的な成功率でした。LLMは既存の計画パターンを認識し再構成することには長けていますが、新しい状況での計画立案は苦手としています。

Apple GSM-Symbolic研究（ICLR 2025） [Mirzadeh et al., ICLR 2025] は、この問題をさらに深堀りしました。数学的問題において、無関係だが一見関連する節を追加すると性能が最大65%低下し、数値のみを変更しても有意な低下が見られました。研究チームは「言語モデルにおける形式的推論の証拠は見つからなかった...その振る舞いは洗練されたパターンマッチングで説明できる」と結論づけています。

セルフデバッグにも限界があります。GoogleのXinyun Chenらは「Teaching Large Language Models to Self-Debug」 [Chen et al., ICLR 2024] で、LLMが自らのコードをラバーダックデバッグのように説明・修正する手法を提案しました。この手法は一定の効果を示しましたが、MIT/Microsoft ResearchのTheo X. Olaussonらの批判的研究 [Olausson et al., ICLR 2024] は、修正コストを考慮すると「性能向上は控えめで一貫性がない」ことを発見しました。さらに、複数回の修正反復は効果的ではなく、GPT-4は3回目、GPT-3.5は4回目の反復で効果を失います。セルフ修正はモデル自身のフィードバック能力によって制約されており、より強力な外部モデルをフィードバックに使用すると大幅に改善することから、自己改善の限界が示唆されています。

なぜこうした限界が生じるのでしょうか。LLMは「人間よりもはるかに汎化が悪い」と、OpenAIの共同創業者Ilya Sutskeverは指摘しています [Sutskever, Dwarkesh Podcast 2025]。ベンチマークでは優れた成績を収めるモデルが、実際のデプロイでは基本的なタスクで失敗する。バグを導入したり除去したりを繰り返す「奇妙なこと」が起きています。

具体例を挙げましょう。LLMは「97は素数か？」という質問に正しく答えられますが、「793は素数か？」になると途端に怪しくなります。訓練データに出現した数と、出現しなかった数への対応が大きく異なります。人間はどちらも同じアルゴリズム（割り算の試行）で解けますが、LLMはそうではありません。コード生成でも同様です。標準的なAPIの使い方は完璧に書けても、ドキュメントにない使い方や、新しいバージョンの変更点には脆弱です。

人間が桁違いに少ないデータから学習しながら、なぜはるかに堅牢に汎化できるのでしょうか。認知科学では、人間は「抽象的な規則」を学習するのに対し、ニューラルネットワークは「統計的パターン」を学習するという見方があります。人間の子供は数個の例から「複数形は-sをつける」というルールを抽出し、見たことのない単語にも適用できます。LLMは膨大な例から表面的なパターンを学習しますが、そのパターンが「なぜ」機能するのかは理解していない可能性があります。

この汎化の謎は、現在のアーキテクチャの根本的な限界を示唆しています。ベンチマークの数字と実務での信頼性の乖離は、この汎化ギャップの直接的な表れです。

この汎化ギャップへの対策として、形式手法との融合が模索されています。

ニューロシンボリック統合

最近の研究は、1969年にCordell Greenが追求した形式的アプローチと再び交差しています。Google DeepMindのAlphaProofとAlphaGeometry 2（2024年7月） [DeepMind, Official Blog 2024] は、IMO 2024で6問中4問を解き、28/42点で銀メダルレベル（金メダルまであと1点）を達成しました^[14]。AlphaProofはLLMと形式的証明システムの融合であり、候補証明をニューラルネットワークが生成し、Lean言語で記述された証明を自動検証します。

AlphaProofの技術的な核心は、AlphaGoで培われた自己対戦強化学習をIMO問題に適用したことにあります。まず、IMO問題を自然言語からLean 4の形式言語に変換します。この形式化により、証明の正しさは「Leanコンパイラが通るか」という客観的な基準で判定できます。次に、Geminiベースのモデルが候補となる証明ステップを生成し、AlphaZeroスタイルの木探索で有望な方向を探ります。正しい証明が見つかると、それが「正解」として強化学習の報酬になります。囲碁で自己対戦から学んだように、数学証明でも自己生成した正しい証明から学習できます。

なぜP6（最難問）を解けたのでしょうか。DeepMindは詳細を公開していませんが、形式化と探索の相乗効果が鍵だと推測されます。P6は609人中5人しか解けなかった問題ですが、形式化された問題空間での探索は、人間の直感に頼らない解法の発見を可能にします。AlphaProofは競技時間を大幅に超える計算時間を使いましたが、それでもこの結果は重要です。

DeepSeek-Prover V2（2025年4月） [Ren et al., arXiv 2025] は671Bパラメータモデルで、MiniF2F-testで88.9%を達成しました。CaltechのLean Copilot [Song et al., PMLR vol 288] は、手動で入力する証明ステップを3.86から2.08に削減し、74.2%の証明ステップを自動化しました。これらの研究は、56年前のGreenの夢が、まったく異なる技術的基盤の上で実現に向かっていることを示しています。演繹的合成は計算量の壁に阻まれましたが、ニューラルネットワークの直感と形式システムの厳密性を組み合わせることで、その壁を回避できるかもしれません。

1969年のCordell Greenと2024年のAlphaProofは、同じ問いに取り組んでいます。「証明を構築する過程でプログラムが生まれる」というアイデアは、技術的手段は異なっても、55年間変わっていません。

Gary Marcusが長年提唱してきたニューロシンボリック統合への関心が高まっています。StanfordのXia Wuら（Barrett, Narodytskaとの共著）によるLEMUR [Wu et al., ICLR 2024] は、LLMとSMTソルバーを形式的に健全な形で統合した最初のフレームワークです。LLMがループ不変式を提案し、境界モデル検査器が検証し、反例をフィードバックするというCEGISパターンをLLMに適用しています。同じ10分のタイムアウトで、SMTベースの検査器ESBMC単体では68問しか解けなかったベンチマークに対し、LEMUR（GPT-4）は107問を解決。不変式合成専用に設計されたCode2Invをも上回る性能を達成しました。Kambhampatiらの LLM-Modulo Frameworks [Kambhampati et al., ICML 2024] は、LLMを単独で計画に使用するのではなく、外部の計画検証システムと組み合わせることを提案しています。Sakana AIのDarwin Gödel Machine（2025年） [Zhang et al., arXiv 2025] は、自身のコードを書き換える自己改善コーディングエージェントで、SWE-benchで20% → 50%、Polyglotで14.2% → 30.7%の性能向上を達成しました。

Google DeepMindのAlphaEvolve（2025年5月） [DeepMind, Blog 2025] は、ニューロシンボリック統合の産業応用として注目に値します。Gemini FlashとGemini Proを組み合わせ、LLMが候補プログラムを生成し、自動評価メトリクスで検証、進化的アルゴリズムで最適化するというアプローチです。1年以上にわたりGoogleの本番環境で稼働し、データセンター全体で0.7%の計算リソースを継続的に回収しています^[15]。これは「LLM + 自動検証 + 進化的探索」という組み合わせが実用的な成果を生み出せることを示す重要な事例です。

これらの研究は、純粋なニューラルアプローチと純粋な形式的アプローチの両方に限界があることを示しています。パターンマッチングでは見たことのない状況への汎化が難しく、形式的アプローチは計算量の壁に阻まれます。両者の長所を組み合わせるニューロシンボリック統合は、次のブレイクスルーの候補として注目されています。

セキュリティと法的課題

AI生成コードのセキュリティは深刻な課題として浮上しています。NYU Tandon School of EngineeringのHammond Pearceらによる研究 [Pearce et al., IEEE S&P 2022] は、GitHub Copilotが生成するコードの約40%にセキュリティ脆弱性が含まれることを示しました。OWASPトップ10に含まれる深刻な脆弱性が多数確認されています^[16]。

StanfordのNeil Perryらによる後続研究 [Perry et al., CCS 2023] は、AIコーディングアシスタントを使用した開発者が、使用しなかった開発者よりもセキュリティ上問題のあるコードを書く傾向があることを発見しました。さらに懸念されるのは、AIアシスタントを使用した参加者は自分のコードがより安全だと過信する傾向があったことです。AIが生成するコードへの過度な信頼は、新たなリスク要因となっています。

"Slopsquatting"^[17] は、LLMが存在しないパッケージ名を幻覚として生成する傾向を悪用したサプライチェーン攻撃です [Lanyado et al., Socket Security 2024]。攻撃者がLLMが頻繁に推奨する架空のパッケージ名でマルウェアを公開し、開発者がAIの提案に従ってインストールするのを待ちます。研究によれば、LLMは約20%の確率で存在しないパッケージを推奨することがあります。

法的な課題も山積しています。2022年11月、作家でプログラマーのMatthew Butterick氏らがGitHub、Microsoft、OpenAIを提訴しました（Doe v. GitHub, Inc., Case No. 4:22-cv-06823-JST）[FindLaw, Butterick v. GitHub 2024]。主な争点は、オープンソースコードを訓練データとして使用する際のライセンス遵守と、生成コードにおける著作権表示の欠如（DMCA §1202(b)）です。2024年1月に多くの請求は棄却されましたが、ライセンス違反と契約違反に関する請求は第9巡回控訴裁判所で継続しています（Case No. 24-7700）。この訴訟の結果は、AI訓練データの法的取り扱いに大きな影響を与える可能性があります。

EU AI Act（Regulation (EU) 2024/1689、2024年8月発効）[EU, Official Journal 2024] は、AIシステムのリスクベース規制を確立しました。コード生成ツールは「最小リスク」カテゴリに分類される見込みですが、2025年7月に最終化されたGPAI Code of Practiceでは、透明性、著作権、安全性に関する要件が定められています。米国では包括的な連邦法はまだありませんが、大統領令でウォーターマーキング研究が求められています。

スケーリングの限界とTransformer以外の道

セキュリティや法的リスクへの対応が進む一方で、技術的な限界も見えてきています。ニューロシンボリック統合だけが答えとは限りません。OpenAIの共同創業者Ilya Sutskeverによれば、AIは「スケーリングの時代」（2020-2025年）から「研究の時代」に戻っています。スケーリングが「部屋の中の空気を全て吸い尽くした」ため、誰もが同じことをしていました。計算資源とデータを増やせば性能が向上するという単純なレシピは、その成功ゆえに多様なアプローチを抑圧してきました。しかし事前学習データには限りがあります。これまでのレシピがこれからも機能するとは限りません。

汎化の問題が解決されなければ「補助ツール」から「自律的な開発者」への移行には根本的な壁があり、解決されればソフトウェア開発の性質そのものが変わるでしょう。Transformerの限界が見えてきた今、研究者たちは根本的な問いに立ち返っています。

一つは計算量の壁です。Attentionは入力長の二乗に比例するO(n^2)の計算量を要求します。100万トークンのコードベースを処理するには、現実的ではない計算資源が必要になります。Mamba [Gu & Dao, arXiv 2023] に代表されるState Space Modelsは、これを線形O(n)に抑えることを目指しています。

もう一つは生成の順序です。コードを書く人間は、最初から順番に書くわけではありません。スケルトンを書いて、戻って修正して、別の場所に追加して、また戻る。これに対し自己回帰LLMは左から右への一方通行。Diffusion-based LLM [Sahoo et al., NeurIPS 2024] は、ノイズから全体を段階的に洗練することで、この制約を外そうとしています。

記憶の問題もあります。人間のプログラマは、先週書いたコードを覚えています。先月のバグを覚えています。Transformerのコンテキストウィンドウは、どれだけ拡張しても今見ているものに限られます。GoogleのTitans [Behrouz et al., arXiv 2024] は、ニューラル長期記憶モジュールを導入してこの壁を超えようとしています。

最も根本的なアプローチは、パターンマッチングを超えることです。World Modelsは、コードを統計的パターンとして学習するのではなく、プログラムの実行をシミュレートして因果関係を理解しようとする。これが機能すれば、LLMの汎化問題は解決に向かう可能性があります。

どれが正解かは誰にもわかりません。ただ、スケーリング一辺倒の時代が終わり、研究の多様性が回復している兆候は見えています。

こうした多様なアプローチが並行する中で、能力そのものをどう測定するかも重要な課題です。

タスク時間軸という新たな指標

Epoch AIとMETRが共同開発した「タスク時間軸（Task Horizon）」メトリクスが注目されています。これは「AIエージェントが50%の信頼性で完了できるタスクの長さ」を測定するものです。

各LLMが50%の確率で完了できるソフトウェアエンジニアリングタスクの時間軸。Y軸は人間が要する作業時間、X軸はLLMのリリース日。GPT-2/GPT-3時代はほぼゼロだったが、2024-2025年に急成長し、GPT-5.1-Codex-Maxは2時間42分に到達。出典: [METR, Task Horizon 2025]

このタスク時間軸は過去6年間、約7ヶ月ごとに倍増してきたことが確認されています。これを「人間が1ヶ月（167時間）かけて行うタスク」まで外挿すると、80%信頼区間で2028年末〜2031年初頭という予測が得られます。2024-2025年のより速いトレンドが継続すれば、2027〜2028年初頭に前倒しされる可能性もあります。

Epoch AIの研究者たちは、より長期的な予測も提示しています [Epoch AI, AI in 2040 2024]。Jaime Sevillaの完全な認知タスク自動化への中央予測は2035年（90%CI: 2027-2050）、Yafah Edelmanは2034年、Ege Erdilは10年以内のフルリモートワーク自動化に約30%の確率を割り当てています。

ただし、これらはあくまで傾向の外挿であり、技術的ブレイクスルーや予期せぬ障壁によって大きく変動し得ます。「ベンチマークを解くこと」と「開発者を置き換えること」の間には依然として大きなギャップがあります。ここにMETR研究の重要な発見があります。モデルがSWE-benchで80%以上を達成しても、現実世界の複雑なコードベースでは経験豊富な開発者の生産性を19%低下させることがあります。ベンチマークと実プロジェクトの間には、まだ大きな溝があります。

おわりに

冒頭の問いに戻ります。オリジナルのSWE-benchで2023年に約2%だったスコアが、2024年8月のSWE-bench Verifiedでは33%、2025年には80%超へと急上昇しました。この背景には何があったのでしょうか。

一つの解釈は、三つの流れの収束という視点です。Greenの定理証明（1969年）に始まる形式手法は「何が正しいか」の基準を、ShannonとRosenblattに遡る帰納的学習は「大量の例から学ぶ」能力を、SimonとNewellのGPS（1957年）に始まるエージェント研究は「自律的に問題を解く」枠組みを、それぞれ数十年かけて磨いてきました。これらが2020年代に同時に成熟期を迎え、Transformerと計算資源の指数関数的成長が収束を加速させた。その結果が、約2年間でのSWE-benchスコアの急速な向上でした。

1956年のダートマス会議に集まった研究者たちが描いた夢は、部分的に実現に近づいています。ただし、彼らは「機械が人間のように推論する」ことを想像していました。現実に起きたのは「大量のテキストから統計的パターンを学習する」という、まったく異なるアプローチでした。

生産性研究は時系列で追うと変化が見えてきます。2023年の初期研究ではジュニア開発者に顕著な効果が報告され、2024年のMicrosoft調査では27-39%の向上が確認されました。しかし2025年7月のMETR研究は、熟練開発者が慣れたコードベースで使うと19%の時間増加という逆の結果を報告しています。同年8月のAnthropicの調査は、別の視点を提示しました。「同じタスクを速くできるか」ではなく「何が新しく可能になるか」という問いです。約3割は、従来なら費用対効果の観点から見送っていた探索的な作業でした。SWE-bench Verifiedで80%を超え、Microsoftの新規コードの30%を書くテクノロジーの価値は、既存の仕事を速くすることだけでなく、新しい仕事を可能にすることにあるのかもしれません。

1936年にTuringが計算可能性を定義して以来、プログラムを自動生成する試みは続いてきました。皮肉なことに、現在の成功は「正しさの証明」を諦めることで得られました。形式手法は正しさを保証できますが、人間が仕様を書く必要があります。LLMは仕様を自然言語から推測してくれますが、正しさは保証しません。知識獲得のボトルネックは解消されましたが、検証のボトルネックが新たに生まれています。80%の正解率は、20%の誤りをどう見つけるかという問題でもあります。

この記事が、AIコード生成の現在地を考えるきっかけになれば嬉しいです。