はじめに
エアークローゼットでエンジニアをしているentherraです。最近はClaude Codeを使ったAgentic Engineeringを試行錯誤しています。
そもそもLLMがなぜこれほどコードを書けるのか気になって調べたら、90年分の歴史になりました。
長いので興味のあるところだけどうぞ。
| 興味 | おすすめ |
|---|---|
| 最近の現状だけ知りたい | SWE-bench 80%の現在地 |
| Copilot/GPTの仕組み | LLMの躍進 |
| エージェントとは | エージェントの台頭 |
| 今後の動向 | 未解決の課題 |
なぜ90年前から話を始めるのか
2025年11月、AnthropicのClaude Opus 4.5がSWE-bench Verifiedで80.9%を達成しました [Anthropic, Official Blog 2025]。実際のGitHub issueを解決する能力を測定するこのベンチマークで、わずか15ヶ月で33%から80%を超えたのです。
なぜ、これほど急速だったのでしょうか。
この問いに答えるには、技術の進歩だけでなく、「計算とは何か」「知能とは何か」という基礎的な問いの変遷も追う必要があります。1936年にAlan Turingが計算可能性を定義したとき、すでにその萌芽がありました。本稿では、この約90年の流れを追いながら、各時代の研究者たちが何を目指し、何に阻まれ、どう対処してきたのかを描きます。
ただし、歴史を語る際の注意点があります。本稿が描く「形式的手法」「帰納的学習」「エージェント」という三つの流れは、無数にあり得た物語の一つに過ぎません。遺伝的プログラミングやAnswer Set Programmingなど、本稿では触れない重要なアプローチも存在します。当時の研究者たちにとって、次のステップは決して自明ではありませんでした。
計算とは何だろうか（1936-1960）
プログラムを自動生成するには、まず「計算とは何か」を厳密に定義する必要があります。これは意外と難しい問題でした。1931年、Kurt Gödelが不完全性定理を発表しました [Gödel, Monatshefte für Mathematik und Physik 1931]。どんな形式体系にも、その体系内で証明も反証もできない命題が存在する。この発見はDavid Hilbertが掲げていた「数学の完全な形式化」という計画を頓挫させましたが、同時に新たな問いを生みました。ある問題が解けるかどうかを機械的に判定できるか。いわゆる決定問題（Entscheidungsproblem）です。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として知られるこの概念は、「計算可能な関数とは、チューリングマシンで計算できる関数である」という主張です。言い換えれば、Python、JavaScript、C++など、どのプログラミング言語で書いても、計算できる範囲は本質的に同じだということです。つまり、私たちが今日TypeScriptやPythonやRustで書いているあらゆるコードの「限界」と「可能性」は、コンピュータが生まれる前のこの瞬間に、すでに数学的に予言されていたということです。もう一人の重要人物がClaude Shannonです。1937年のMIT修士論文で、ブール代数とスイッチング回路の関係を示し [Shannon, MIT Master's Thesis 1937]、論理（真/偽）と物理（オン/オフ）を橋渡ししました。1948年には情報理論を確立 [Shannon, Bell System Technical Journal 1948]。ビットという概念はここで生まれました。テキストも画像も音声も、そしてプログラムも、すべて0と1の列として扱える。プログラムを情報として扱い、統計的に分析するという発想は、Shannonの情報理論に多くを負っています。ただし、「学習」の直接的な起源としては、同時代のNorbert Wiener（サイバネティクス／フィードバック制御）やFrank Rosenblatt（パーセプトロン）、あるいはTuring自身の学習機械への言及も重要な思想的系譜となっています。
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, Proceedings of the Western Joint Computer Conference 1957] を開発し、1956年のダートマス会議で発表しました。『Principia Mathematica』の定理をいくつか自動証明してみせたこのプログラムは、「機械が考える」ことの最初の実証でした。翌1957年にはGeneral Problem Solver（GPS） [Newell & Simon, Stanford Digital Repository] を開発。特定のタスクではなく、汎用的な問題解決能力の実現を目指したシステムです。翌1958年、McCarthyはLISPを開発しました [McCarthy, Communications of the ACM 1960]。これは単なるプログラミング言語ではなく、λ計算の概念を実用的な形で具現化したものでした。再帰関数、条件式、そしてガベージコレクションという概念がここで実装されました。以下はLISPのシンボリックな表現力を示す簡単な例です。
;; 現代的なLISP記法（Common Lisp/Scheme風）で書いた階乗
;; 1958年当時のLISP 1.5ではDEFINEはペアのリスト形式で書かれていた
(DEFINE (FACTORIAL N)
(COND ((ZEROP N) 1)
(T (TIMES N (FACTORIAL (SUB1 N))))))
;; 再帰的な定義が自然に表現できる
;; これは当時としては革新的だった
ここに、プログラム自動生成への二つの道が見え始めます。一つは形式的な証明に基づくアプローチ、もう一つは学習や探索に基づくアプローチです。
この二つの道は、本質的に異なる哲学を反映しています。形式的アプローチは「正しさを保証する」ことを最優先し、機械学習アプローチは「多くの場合に機能する」ことを目指します。前者は100%の確実性を追求するがゆえに適用範囲が限られ、後者は広範な適用を可能にするがゆえに誤りを完全には排除できません。2025年現在、コード生成AIの成功と限界は、この根本的なトレードオフを反映しています。両者の道は、その後60年以上にわたって別々に発展し、2020年代になってようやく再び交差し始めます。
この理論的基盤の上で、実際のプログラム合成がどのように試みられたかを見ていきます。
ソフトウェア危機と形式的アプローチ（1968-1990）
1960年代後半、ソフトウェア開発は壁にぶつかっていました。プロジェクトは予定より遅れ、予算を超過し、完成しても期待通りに動かない。そんな状況が続いていたのです。1968年3月、Edsger Dijkstraは "Go To Statement Considered Harmful" をCACMに発表し [Dijkstra, Communications of the ACM 1968]、プログラムの正しさを論理的に検証可能にするための議論を提起していました。goto文の無制限な使用はプログラムの論証を著しく困難にする、と彼は主張しました。1968年10月、NATOの後援でドイツのガルミッシュで開催された会議で、ソフトウェア開発の問題は「ソフトウェア危機」と名付けられました [Naur & Randell (Eds.), NATO Software Engineering Conference 1968]。Dijkstraもこの会議に参加し、構造化プログラミングの重要性を訴えました。この危機意識が、形式的手法によるプログラム合成への関心を高めました。もしプログラムを仕様から自動的に導出できれば、バグは原理的に存在し得ません。これは魅力的な夢でした。
同時期、プログラムの正しさを数学的に証明する理論的基盤も確立されつつありました。1967年、Robert Floydは "Assigning Meanings to Programs" で不変式を用いたプログラム検証手法を提案し、1978年にチューリング賞を受賞しました。1969年、Tony Hoareは "An Axiomatic Basis for Computer Programming" で Hoare triple {P} C {Q}（事前条件P、コマンドC、事後条件Q）を導入し [Hoare, Communications of the ACM 1969]、1980年にチューリング賞を受賞しています。Dijkstraは1976年の著書で最弱事前条件計算（weakest precondition calculus）を体系化し、Floyd-Hoareの理論を完成させました。この枠組みは現代の検証ツールDafnyやViperの基盤となっています。
同じ1969年、Stanford/SRI InternationalのCordell Greenは、定理証明をプログラム合成に応用する手法を提案しました [Green, IJCAI 1969]。古典論理の導出原理（Resolution Principle）に基づくQA3システムを開発し、仕様を論理式として表現し、その証明過程で得られる変数のバインディングからプログラムを抽出するという方法です。「答え（プログラム）が存在する」という証明を構築し、そこから具体的な解を取り出すアプローチでした。
一方、同時期に型理論の分野では別の重要な発見がありました。Curry-Howard同型対応です [Howard, To H. B. Curry: Essays 1980]。これは直観主義論理とλ計算（型理論）の間に深い対応関係があることを示すもので、命題は型に、証明はプログラムに対応するという洞察です。例えば、論理学の「A → B」（AならばB）という命題は、プログラミングにおける「A → B」という関数型に対応します。「AからBを導出する証明」を構成することは、「A型の値を受け取りB型の値を返す関数」を実装することと等価なのです。
Greenのアプローチ（導出原理による答え抽出）とCurry-Howard対応（証明の構造そのものがプログラム）は、哲学も技術的系譜も異なりますが、「証明とプログラムの関係」という共通のテーマを異なる角度から照らしています。
Curry-Howardの対応関係は驚くほど精密です。論理学の「かつ」（A ∧ B）は型理論のタプル型（A × B）に、「または」（A ∨ B）は直和型（A + B）に対応します。真（⊤）はユニット型に、偽（⊥）は空型（値が存在しない型）に対応します。つまり、型が棲息している（inhabitedである、つまりその型の値が存在する）とき、対応する命題は証明可能なのです。
この視点は現代のプログラミング言語設計に深い影響を与えました。Rustのライフタイム注釈、Haskellの高度な型クラス、TypeScriptの条件型は、すべて「型で正しさを保証する」という哲学の延長線上にあります。型エラーでプログラムがコンパイルできないとき、それは「証明に誤りがある」ことを意味しています。「正しく型付けされたプログラムはクラッシュしない」（Well-typed programs don't go wrong）という有名な格言は、この同型対応の実践的な表現です。
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（二分決定図）を用いた記号モデル検査で
エキスパートシステムの教訓
同時期、AIの別の潮流であるエキスパートシステムも、形式的アプローチと同様の壁に直面していました。1965年、StanfordのEdward FeigenbaumとJoshua Lederbergが開発したDENDRALは、質量分析データから化学構造を推定する最初のエキスパートシステムでした [Lindsay et al., Artificial Intelligence 1993]。続いて1970年代、StanfordのEdward Shortliffeが開発したMYCINは、血液中の細菌感染を診断し抗生物質を推奨するシステムでした。MYCINは治療推奨の許容可能性評価で65%を達成し、これはStanford医学部の専門家（42.5〜62.5%）を上回っていました [Yu et al., JAMA 1979]。Carnegie Mellon大学のJohn McDermottが開発したDECのR1/XCON（1978年〜）は商業的成功を収め、年間数千万ドルのコスト削減に貢献しました [McDermott, Artificial Intelligence 1982]。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の真の革新は、CEGIS（Counter-Example Guided Inductive Synthesis）と呼ばれるパラダイムを確立したことにあります。
CEGISの重要性は、帰納的アプローチと演繹的アプローチを橋渡しする点にあります。候補生成は帰納的ですが、検証は演繹的です。つまり、「当たりをつける」部分と「正しさを保証する」部分を分離したということです。この役割分担こそが、実用的なプログラム合成を可能にした鍵だったということです。
これはなぜ革新的だったのでしょうか。プログラム合成の計算量は膨大です。考えられるすべてのプログラムを列挙してテストするナイーブなアプローチでは、プログラムの長さに対して指数的に探索空間が拡大します。CEGISはこの爆発を二つの方法で抑えます。第一に、反例が新たな制約として働くことで、同じ失敗を繰り返さなくなります。第二に、SMT（Satisfiability Modulo Theories）ソルバーという強力な道具が、制約を満たす候補を効率的に見つけます。特にMicrosoft ResearchのLeonardo de MouraとNikolaj Bjørnerが2008年に発表したZ3 [de Moura & Bjørner, TACAS 2008] は、算術、配列、ビットベクトルなどの理論を扱え、現代の検証ツールの事実上の標準となっています。なお、de Mouraは2013年にLean証明支援系も開発しており、SMTソルバーと形式証明の両方でAIコード生成の基盤を築いた人物です。この「推測と検証」のパターンは、2025年現在のLLMとユニットテストの関係にも通じています。LLMがコードを生成し、テストが正しさを検証する。Solar-Lezamaが確立したパラダイムは、形を変えて現代のコード生成エージェントに受け継がれているということです。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]、プログラム合成研究が数億人のエンドユーザーに届きました。この論文はPOPL 2021でMost Influential Paper賞を受賞しています [ACM SIGPLAN, Most Influential POPL Paper Award]。FlashFillの成功は、同時にその限界も明らかにしました。文字列変換に特化したDSLは、その範囲内では驚異的な性能を発揮しますが、範囲外の問題には適用できません。新しいドメインには新しいDSLが必要であり、そのDSL設計自体が専門的なスキルを要求します。汎用性を追求すれば探索空間が爆発し、特化すれば適用範囲が限定されます。このジレンマを超える鍵は、まったく異なる方向から現れることになります。2010年代半ば、画像認識で革命を起こした深層学習が、コード生成の世界に参入し始めます。
深層学習とコード生成（2015-2020）
形式的アプローチが「何が正しいか」を追求したのに対し、帰納的学習は「大量の例から学ぶ」能力を追求してきました。この流れの理論的基盤は、1948年にBell研究所のClaude Shannonが発表した "A Mathematical Theory of Communication" に遡ります [Shannon, Bell System Technical Journal 1948]。Shannonは情報を確率的な概念として定量化し、エントロピー
ニューラルネットワークの長い道のり
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が解けることは理論的には当時も知られていました。しかし問題は、多層ネットワークを効果的に訓練する方法が広く普及していなかったことです。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]。逆伝播で計算される勾配は層を遡るごとに指数関数的に小さくなり、深い層の学習が困難になります。
Transformerへの道
2012年、ImageNetコンペティションでAlexNetが圧勝したことは、深層学習革命の始まりとして広く知られています [Krizhevsky, Sutskever & Hinton, NIPS 2012]。画像認識から始まったこの波は、自然言語処理、音声認識へと広がり、やがてコード生成にも及びました。2015年、Google ResearchのArvind Neelakantan、Quoc V. Le、Ilya Sutskeverは、Neural Programmerを発表しました [Neelakantan et al., arXiv 2015]。エンドツーエンドで微分可能なアーキテクチャにより、プログラムのアノテーションなしに実行結果のみから学習できることを示しました。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
DeepCoderの意義は、ニューラルネットワークがコードを書くという単純な構図を超えたところにあります。ニューラルネットワークは直感や当たりをつける役割を果たし、最終的な正しさの保証は従来の探索と検証が担います。つまり、「予測」と「保証」の役割分担ということです。これは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）により入力全体を並列に処理できます。計算量はシーケンス長
この論文の革新性は、逆説的な発想にあります。RNNやLSTMは順序を自然に捉えられるという利点があり、言語のような逐次的なデータに適していると考えられていました。Transformerはこれを完全に捨て去り、すべての入力を同時に見ることを選びました。しかし、順序情報を失うという致命的な問題が生じます。「犬が猫を追いかけた」と「猫が犬を追いかけた」は同じトークンで構成されていますが、意味は異なります。この問題に対する解決策が位置エンコーディングであり、三角関数を用いて各位置に固有のパターンを与えました。この単純な仕組みで十分でした。並列化によるスケーラビリティの恩恵は、逐次処理の利点を大きく上回りました。結果として浮かび上がった教訓は、順序を厳密に追うよりも、全体を一度に見て関係性を掴む方が、言語の理解には本質的だったということです。「シンプルさが勝つ」という原則は、その後のLLM開発全体を貫くことになります。
Transformerのエンコーダ・デコーダ構造。左がエンコーダ（入力を処理）、右がデコーダ（出力を生成）。Multi-Head Attentionが入力全体の関係性を並列に捉え、Positional Encodingが位置情報を補う。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億パラメータのモデルを大量のテキストで事前学習し、教師なしで言語の構造を学習させ、その後各タスク向けにファインチューニングするという手法でした。BERTが双方向で文脈を理解するのに対し、GPTは左から右への生成に特化しました。2019年2月、OpenAIはGPT-2を発表しました [Radford et al., OpenAI 2019]。パラメータ数は15億に増加し、Zero-shot学習の能力が出現しました。つまり、特定タスク向けのファインチューニングなしに、プロンプトの形式を変えるだけで多様なタスクをこなせるようになったのです。OpenAIは「悪用のリスク」を理由に当初フルモデルの公開を見送りましたが、これは後のAI安全性議論の先駆けとなりました。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 Paper賞を受賞し、Googleは同年末までに70以上の言語でBERTを検索に導入しています。GPT系（生成特化）とBERT系（理解特化）という二つの流れが生まれました。コード生成には生成能力が本質的に重要であり、後のCodexやCopilotはGPTの系譜を継ぐことになります。現代のコード生成AIが「書く」ことに長けているのは、この選択の結果だということです。逆に言えば、コードを「理解する」能力についてはBERT系のアプローチも依然として重要であり、CodeBERTなどの研究につながっています。2019年、GitHub と Microsoft Research が共同で構築したCodeSearchNetは、約600万の関数を含む大規模コードデータセットを提供しました [Husain et al., arXiv 2019]。Go、Java、JavaScript、PHP、Python、Rubyの6言語をカバーし、後のCodeBERT等の事前学習モデルの基盤となりました。しかし、真のブレイクスルーには、さらに大きなモデルとデータが必要でした。GPT-3以降のLLM革命は、劇的な変化をもたらしました。
LLMの躍進（2021-2023）
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億パラメータ）では劇的に機能する。この「創発」的な振る舞いは、量が質的変化を生む相転移のようにも見えます。なぜ巨大なモデルだけがこの能力を持つのか。この問いへの答えは、AIの将来を占う上で重要な意味を持ちます。
この成功を受け、コード生成に特化した大規模言語モデルの研究が加速しました。
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%、つまり中央値付近）に到達しました。AlphaCodeの手法は独特です。問題ごとに数百万のプログラムを生成し、フィルタリングとクラスタリングで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を調整します。この手法により、モデルは有害な出力を避け、有用で正確な回答を生成するようになります。
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]。
Microsoftは2023年2月にBing Chatの基盤としてGPT-4の早期バージョンを採用しており [Microsoft Blog, Reinventing Search 2023]、コーディング支援の品質も飛躍的に向上しました。
推論能力の進化
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]
GSM8Kベンチマーク（数学的推論）では、540Bパラメータモデルがファインチューニングされたモデルを上回る性能を達成しました。同年5月には、Kojimaらが「Let's think step by step」という一文を加えるだけで推論性能が向上するZero-shot CoTを発見しました [Kojima et al., NeurIPS 2022]。Wangらの「Self-Consistency」 [Wang et al., ICLR 2023] は、複数の推論パスをサンプリングし、多数決で最終回答を選ぶ手法です。GSM8Kで+17.9%の改善を達成しました。Zhouらの「Least-to-Most Prompting」 [Zhou et al., ICLR 2023] は、複雑な問題を小さな部分問題に分解し、順番に解くアプローチです。
コード生成において特に重要なのが、Gaoらの「PAL（Program-aided Language Models）」 [Gao et al., arXiv 2022] です。自然言語の推論をPythonコードに変換し、インタプリタで実行することで、LLMの算術エラーを回避します。GSM8Kでは従来のCoTを15%上回り、計算とコード生成の相乗効果を示しました。GoogleのFLAN研究 [Chung et al., arXiv 2022] は、Instruction Tuning（指示チューニング）の効果を実証しました。1,800以上のタスクでファインチューニングしたFlan-PaLM 540Bは、通常のPaLM 540Bを平均9.4%上回りました。LLMがタスク指示に従う能力は、人間の意図を理解する上で不可欠です。
2023年は、オープンソースのCode LLMが躍進した年でもありました。BigCode Projectが開発したStarCoder（15.5Bパラメータ） [Li et al., TMLR 2023] はHumanEvalで40%+のpass@1を達成し、MetaのCode Llama（7B〜70Bのファミリー） [Rozière et al., arXiv 2023] は最大67% pass@1を記録しました。特筆すべきは、これらのモデルが商用利用可能なライセンスで公開されたことです。研究コミュニティだけでなく、企業も自社のニーズに合わせてモデルをカスタマイズできるようになりました。
合成データによる効率的な訓練手法も発展しました。2023年6月、MicrosoftのSurya GunasekarらはPhi-1を発表しました [Gunasekar et al., arXiv 2023]。"Textbooks Are All You Need"（教科書さえあれば十分）と題されたこの研究は、わずか7Bトークンの「教科書品質」データで1.3Bパラメータモデルを訓練し、HumanEvalで50.6%を達成しました。これは10倍大きなモデルに匹敵する性能です。鍵は訓練データの質でした。GPT-3.5を用いて教科書形式の合成データと演習問題を生成し、品質フィルタリングを徹底したのです。同様のアプローチとして、WizardCoder [Luo et al., ICLR 2024] のEvol-Instruct（指示の複雑性を反復的に進化）、Magicoder [Wei et al., ICML 2024] のOSS-Instruct（オープンソースコード片から指示を生成）も登場しました。
効率的なファインチューニング手法も進化しました。2022年、MicrosoftのEdward Huらが発表したLoRA（Low-Rank Adaptation） [Hu et al., ICLR 2022] と、2023年のQLoRA [Dettmers et al., NeurIPS 2023] は、少ないリソースで大規模モデルをカスタマイズすることを可能にしました[6]。これらの技術はCode LLMの民主化を加速させ、企業がプロプライエタリなコードベースでカスタムモデルを訓練することを現実的にしました。
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]、訓練データとしてのオープンソースコードの法的取り扱いはまだ確立されていません。
しかし、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]
この問題への実践的な対策も研究されています。LangChainのLongContextReorder [Maxim AI, Blog 2024] は、検索結果を「最重要→最下位→中位」の順に並べ替えることで、重要な情報を先頭と末尾に配置します。「Found-in-the-Middle」研究 [Zhu et al., arXiv 2024] は、位置バイアスを補正するアテンション較正メカニズムを提案し、最大15%の性能向上を報告しています。また、LongLLMLingua [LlamaIndex, Blog 2024] はプロンプト圧縮により、トークン使用量を1/4に削減しつつ精度を21.4%向上させました。
これらの発見は、LLMの能力の限界を示しています。コンテキストウィンドウの拡大は万能の解決策ではなく、情報の配置や取り出し方を工夫する必要があるということです。この課題は、後のエージェントアーキテクチャにおけるメモリ管理の設計に大きな影響を与えました。ここまで、LLMの急速な発展と、そこで浮き彫りになった限界を検討してきました。単一ファイルのコード補完を超えて、実世界のソフトウェア開発に近づくには何が必要でしょうか。その答えの一つが「エージェント」という概念です。
エージェントの台頭（2023-2025）
「エージェント」という概念自体は、AI研究の黎明期から存在していました。1957年、Carnegie MellonのAllen NewellとHerbert SimonはGPS（General Problem Solver）を開発し [Newell & Simon, IRE Transactions 1961]、手段目標分析（means-ends analysis）という手法で自律的な問題解決を試みました。目標と現状の差を分析し、その差を埋める操作を選択するというアプローチです。しかしGPSは限定的な問題にしか適用できず、現実世界の複雑さには対応できませんでした。
1970年代から80年代にかけて、エージェント研究は専門家システムという形で発展しました。StanfordのMYCIN [Shortliffe, PhD Thesis 1974] は血液感染症の診断と抗生物質の推奨を行い、CarnegieMellonのR1/XCON [McDermott, AI Magazine 1980] はDECのコンピュータ構成を自動化しました。これらはルールベースの推論で成功を収めましたが、知識獲得のボトルネックという根本的な課題に直面しました。
1983年、MichiganのJohn Laird、Allen Newell、Paul RosenbloomはSOARを発表しました [Laird et al., Artificial Intelligence 1987]。SOARは汎用認知アーキテクチャとして設計され、問題空間の探索、チャンキング（学習）、インパス解消など、人間の認知をモデル化しようとしました。一方、1987年にはStanfordの哲学者Michael Bratmanが、BDI（Belief-Desire-Intention）アーキテクチャの理論的基盤を提示しました [Bratman, Harvard University Press 1987]。エージェントは信念（世界の状態についての知識）、欲求（達成したい目標）、意図（実行にコミットした計画）を持つという枠組みです。これらの研究は、1990年代のマルチエージェントシステム研究へと発展し、Wooldridge & Jennings [Wooldridge & Jennings, The Knowledge Engineering Review 1995] はエージェントの特性として自律性、社会性、反応性、能動性を定義しました。
2013年、DeepMindのVolodymyr Mnihらが発表したDQN（Deep Q-Network） [Mnih et al., arXiv 2013] は、深層学習と強化学習を融合させ、Atariゲームで人間レベルの性能を達成しました。2016年のAlphaGo [Silver et al., Nature 2016] は囲碁で世界チャンピオンを破り、複雑な環境での自律的意思決定の可能性を示しました。これらの成果は、ルールベースから学習ベースへのパラダイムシフトを象徴しています。
こうした数十年の蓄積の上に、2023年の ReAct [Yao et al., ICLR 2023] が登場しました。ReActはThought-Action-Observationループで推論と行動を融合し、LLMをエージェントとして機能させる枠組みを確立しました。GPSの手段目標分析、BDIの意図的行動、強化学習の環境との相互作用が、Transformerという共通基盤の上で統合されたのです。
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です。
これらのComputer Use技術の評価基準となるのが、OSWorld [Xie et al., NeurIPS 2024] です。OSWorldは実OS環境（Ubuntu、Windows、macOS）でのエージェント性能を測定するベンチマークで、369タスクで構成され、人間の達成率は72.36%です。Claude Computer Useの初期スコアは14.9%（スクリーンショットのみ、より多くのステップを許容すると22.0%）でしたが、2025年1月23日にOpenAIが発表したOperator [OpenAI, Operator 2025] はOSWorldで38.1%を達成してこれを上回りました。OperatorはComputer-Using Agent（CUA）モデルを搭載し、ウェブブラウザでのタスク自動化に特化してChatGPT Proユーザー向けに提供されています。ただし、Computer Useは新たなセキュリティリスクも提起しています。ウェブページに埋め込まれた悪意ある指示により、エージェントがマルウェアをダウンロード・実行するプロンプトインジェクション攻撃が実証されているのです [Rehberger, Claude Computer Use C2: The ZombAIs Are Coming 2024]。オープンソースエコシステムも活発であり、OpenHands（旧OpenDevin） [OpenHands, GitHub] は65K以上のGitHubスターを獲得し、Paul Gauthierが開発したAider [Gauthier, Aider GitHub] はターミナルベースのAIペアプログラミングツールとして人気を集めています。
単一エージェントから複数エージェントの協調へという進化も見られます。清華大学とDeepWisdomによるMetaGPT [Hong et al., ICLR 2024] は、プロダクトマネージャー、アーキテクト、エンジニアなど複数の役割を持つエージェントが協調してソフトウェアを開発するフレームワークです。HumanEvalで85.9%、MBPPで87.7% Pass@1を達成し、単一エージェントアプローチを大きく上回りました。同様のアプローチとしてChatDev [Qian et al., ACL 2024] も注目を集めています。対話型のマルチエージェント協調により、複雑なソフトウェア開発タスクを分担して処理します。一方、Agentless（UIUC） [Xia et al., arXiv 2024] は、複雑な自律エージェントを使わない3段階パイプライン（ローカライゼーション→修復→パッチ検証）で、極めて低コストにSWE-bench Liteで32.00%を達成しました[7]。
マルチエージェント vs シングルエージェント
2025年6月12日、Cognition AI（Devinの開発元）のCPO Walden Yanが "Don't Build Multi-Agents" というブログ記事を公開し、業界に波紋を広げました [Cognition AI, Blog 2025]。記事は、マルチエージェントシステムが「根本的に脆弱」であると主張しています。
Cognitionの主張の核心は、コンテキスト共有の困難さにあります。複数のエージェントが協調する際、各エージェントは他のエージェントの状態や判断を完全には理解できません。結果として、調整オーバーヘッドが性能を相殺してしまう。彼らは代わりに、単一スレッドの線形エージェントとコンテキスト圧縮を推奨しています。
対照的に、Anthropic、Microsoft、LangChainはマルチエージェントアプローチを支持しています。スケーラビリティ、専門化、並列処理の利点を強調し、複雑なタスクを分担処理できることを評価しています。2024年10月11日にリリースされたOpenAI Swarm [OpenAI, GitHub 2024] は、「ルーティンとハンドオフ」によるエージェント間の協調を実現する実験的なフレームワークであり、2025年にはOpenAI Agents SDKに進化しました。MicrosoftのAutoGen v0.4（2025年1月発表）[Microsoft Research, AutoGen 2025] は、イベント駆動型アーキテクチャを採用し、スケーラブルな分散エージェントシステムを目指しています。
このアーキテクチャ論争は未解決のままですが、すべての本番デプロイメントの設計判断に影響を与えています。正解は一つではなく、タスクの性質によって最適なアプローチが異なるというのが現時点での教訓だということです。
エージェントアーキテクチャの進化において、メモリ管理は重要な課題でした。前述の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" が単一の入力-出力ペアに焦点を当てていたのに対し、Context Engineeringはモデルが見るすべて（メモリ、履歴、ツール、システムプロンプト）を設計対象とします。
| 観点 | Prompt Engineering | Context Engineering |
|---|---|---|
| スコープ | 単一の入力-出力ペア | システム全体のコンテキスト |
| 設計対象 | プロンプトの文言 | メモリ、履歴、ツール、システムプロンプト、検索結果 |
| 時間軸 | 単発の対話 | 複数ターンにわたる長期的なセッション |
| 最適化目標 | 回答の品質 | コンテキストウィンドウの有用性最大化 |
| 典型的な課題 | 曖昧な指示、ハルシネーション | Lost in the Middle、メモリ管理、ツール統合 |
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ツールがコード生成を容易にするほど、この罠に陥りやすくなります。
Vibe Codingは週末プロジェクトやプロトタイピングには有効かもしれませんが、本番環境ではAgentic Engineeringの思想と12 Factor Agentsの原則が重要になります。速度と規律という永遠のトレードオフ。ツールが進化しても、この問いは消えません。むしろAIがコード生成を容易にするほど、その判断はより難しく、より重要になっていくのです。
では、2025年現在の到達点はどこにあるのでしょうか。
SWE-bench Verified 80%の現在地（2025年）
SWE-bench Verified[8]は、実際のGitHub issueを解決できるかを測定するベンチマークであり、現在のコード生成エージェント評価の事実上の標準となっています。
この約2年間の進化は劇的でした。SWE-bench（オリジナル）では2023年10月の約2%から2024年4月には約12%へ。2024年8月にリリースされたSWE-bench Verifiedでは、わずか15ヶ月で33%から80%超へと向上しました。
| 時期 | モデル/アプローチ | スコア | ベンチマーク | 出典 |
|---|---|---|---|---|
| 2023年10月 | RAG + Claude 2/GPT-3.5 | ~2% | SWE-bench | [Jimenez et al., ICLR 2024] |
| 2024年4月 | SWE-agent + GPT-4 Turbo | 12.47% | SWE-bench | [Yang et al., NeurIPS 2024] |
| 2024年8月 | GPT-4o | 33.2% | SWE-bench Verified | [OpenAI, SWE-bench Verified 2024] |
| 2024年9月 | OpenAI o1-preview | 41.3% | SWE-bench Verified | [OpenAI, o1 System Card 2024] |
| 2024年10月 | Claude 3.5 Sonnet (New) | 49.0% | SWE-bench Verified | [Anthropic, SWE-bench Sonnet 2024] |
| 2024年12月 | OpenAI o1 | 48.9% | SWE-bench Verified | [OpenAI, o1 Full Release 2024] |
| 2025年2月 | Claude 3.7 Sonnet | 63.7% | SWE-bench Verified | [Anthropic, Claude 3.7 2025] |
| 2025年4月 | OpenAI o3 | 69.1% | SWE-bench Verified | [OpenAI, o3 2024] |
| 2025年11月 | Claude Opus 4.5 | 80.9% | SWE-bench Verified | [Anthropic, Claude Opus 4.5 2025] |
SWE-bench Verifiedにおける各モデルの性能推移（2025年10月まで）。Anthropic（紫）、OpenAI（ピンク）、Google（青緑）、その他（茶）で色分け。Epoch AIによる独自測定のため、公式発表値と若干異なる場合があります。出典: [Epoch AI, SWE-bench Verified Benchmark]（CC-BY）
以下が2025年11月時点の最新状況です。
| 順位 | モデル | スコア | 発表日 |
|---|---|---|---|
| 1 | Claude Opus 4.5 | 80.9% | 2025年11月 |
| 2 | GPT-5.1-Codex-Max | 77.9% | 2025年11月 |
| 3 | Claude Sonnet 4.5 | 77.2% | 2025年9月 |
| 4 | Gemini 3 Pro | 76.2% | 2025年11月 |
ただし、より難しいSWE-bench Pro[9]（1,865タスク、うち公開セット731問）では様相が異なります [Scale AI, SWE-bench Pro Leaderboard]。
2025年11月時点の最新リーダーボードでは、Claude Sonnet 4.5が43.6%、Gemini 3 Pro Previewが43.3%、GPT-5 (High)が41.8%と、トップモデルでも40%台前半に留まっています。SWE-bench Verifiedで80%超を達成するモデルでも、より複雑な実世界の問題には依然として課題が残っていることを示しています。
ベンチマーク評価にはデータ汚染（Data Contamination）の懸念もあります。MBPPでは65.4%の問題が訓練データに含まれている可能性が指摘されており [Ni et al., EMNLP Findings 2024]、SWE-benchでも「解答がissue文中に含まれている」ケースが報告されています [Xie et al., arXiv 2024]。この問題への対策として、UC BerkeleyらはLiveCodeBenchを開発しました [Jain et al., arXiv 2024]。問題の公開日がモデルの訓練日より後であることを保証する「時間軸による汚染防止」という設計により、より信頼性の高い評価を可能にしています。
Claude Opus 4.5（2025年11月24日発表）[Anthropic, Official Blog 2025] は業界初の80%超えを達成しました[10]。価格も入力$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統合問題[11]を解決します。
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は2023年4月に述べています [Wired, Altman Interview 2023]。2024年12月リリースのDeepSeek-V3は競合モデルに匹敵する性能を約558万ドルのGPU計算コストで実現しました（総コストは推定13億ドル超）[12]。
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として2025年11月に評価額293億ドル（$29.3B）に到達しました [Anysphere, Cursor Blog 2025]。2024年8月の4億ドル評価から15ヶ月で73倍という驚異的な成長であり、ARRは10億ドルを突破しました。日次アクティブユーザーは100万人を超え、OpenAI、Shopify、Stripeなどが採用しています。Cognition AI（Devinの開発元）は2025年9月に102億ドル評価に達し、Windsurfの事業資産を買収しました。CursorのBugBotは100万以上のPRを自動レビューし、150万件の問題を発見しています [Anysphere, BugBot 2025]。Codeiumが2024年11月13日にローンチしたWindsurf [Codeium, Windsurf Launch 2024] は、「初のエージェント型IDE」を謳い、VS Codeフォークにエージェント機能 "Cascade" を統合しています。
自然言語からアプリを生成する「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%の効率向上が報告されています。
この認知バイアスは重要な示唆を含んでいます。AIツールはプロンプト作成、応答待ち、生成コードのレビューというオーバーヘッドを発生させます。新規プロジェクトや不慣れなコードベースでは効果的かもしれませんが、開発者が深く理解している大規模コードベースでは、直接コードを書く方が速い場合があります。つまり「AIは役立つ/役立たない」という二項対立ではなく、開発者の経験、コードベースへの習熟度、タスクの性質によって効果は大きく異なるのです。
コード品質への影響も懸念されています。GitClearが2020〜2024年の211万行を分析した結果 [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%が不信感を抱いています。利用は増えても、信頼は高まっていない。この乖離は示唆的です。
より深刻な懸念は、雇用市場全体の冷え込みです。2025年2月時点で、ソフトウェア開発者全体の求人は2020年1月比で65%水準という5年ぶりの低水準にあり、特にジュニアポジションの採用は20年ぶりの低水準とも報告されています [The Pragmatic Engineer, Jobs Report 2025]。2022年半ばには現在の3.5倍のピークを記録しており、追跡対象セクター中最大の急騰・急落サイクルを経験しています。テック業界のレイオフは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による30%の生産性向上を理由に挙げています [Salesforce Ben, No More Engineers 2025]。
この影響は教育市場にも波及しています。2024年時点で、コンピュータサイエンス専攻の新卒失業率は6.1%に達し、哲学専攻の3.2%のほぼ2倍、新卒全体の平均5.8%をも上回っています [Federal Reserve Bank of New York, College Labor Market 2024]。2025年秋学期の大学院レベルCS入学者は前年比15%減少し、2年制大学の学部課程でも5.8%減少しました [National Student Clearinghouse, Enrollment Estimates 2025]。2024年のエリートプログラム卒業生が主要テック企業に就職する割合は、2022年の25%から11-12%へと半減しています [SignalFire, State of Talent 2025]。一方、AIスキルを持つエンジニアには大幅な給与プレミアムがあります。Levels.fyiによれば、OpenAIでは94.5万ドル（中央値）、Scale AIでは72万ドル（最高）に達し、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]。しかし、ジュニアを採用しなければ、数年後に経験を積んだミッドレベルエンジニアが不足するという懸念があります。「ジュニア開発者は将来のシニア開発者である」という当たり前の事実が、短期的な効率化によって見落とされている可能性があります。
ただし、SWE-bench Verified 80%という数字の意味は慎重に解釈すべきです。SWE-bench+研究 [Xie et al., arXiv 2024] の詳細な分析は、問題の深刻さを明らかにしました。32.67%のケースでissue記述やコメントに解答が漏洩しており、モデルは独自に解決策を生成するのではなく、提供された情報から抽出していました。これとは別に、31.08%のケースでは、モデルの変更が不正確または不完全でありながらテストをパスしており、テスト自体が弱すぎることを示しています。これら2つの問題カテゴリには重複があり、少なくとも一方の問題を持つケースを合計すると63.75%に達しました。つまり、「正しく解けた」と見なせるケースは約36%に過ぎないということです。
2025年9月には新たな抜け穴も発見されました [SWE-bench Issue #465]。Claude Sonnet 4やQwen3-Coderがgit log --allコマンドで将来のコミット（修正内容を含む）を参照していたのです。SWE-benchは元々リモートを削除していましたが、タグやreflogには将来の情報が残っており、それが悪用されました。これは「モデルが問題を解いた」のではなく「答えをカンニングした」ことを意味します。
HumanEvalについても、GPT-4技術レポートは25%が事前学習データに混入していた可能性を認めています。UIUCのJiawei Liuらによる EvalPlus [Liu et al., NeurIPS 2023] は、さらに深刻な問題を発見しました。HumanEvalの元のテストケースは平均7.7件しかなく、多くの誤った解がテストを通過していました。EvalPlusはテストカバレッジを80倍に拡張し、その結果、正しいとされていた解の14〜19%が実際には不正確であることが判明しました。つまり、報告されていたベンチマークスコアは過大評価だったのです。
より本質的な問いは、ベンチマーク性能が実世界性能をどの程度反映しているかです。SWE-benchの問題は過去のものであり、新しいコードパターンや未知のバグに対する性能は測定していません。
こうした汚染問題への対策として、新しいベンチマークも登場しています。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の第1回では最高7.5%（OpenHermes-2.5-Mistral-7Bによる達成、計算制約下での評価）という結果でした。ただし、これは同一モデルでの比較ではなく、評価条件も異なるため、直接的な性能低下とは解釈できません。それでも、訓練データに含まれない新しい問題に対する汎化能力を測定する重要性を示しています。
現在のベンチマークは最低限の能力証明として有用ですが、実世界での有用性の完全な指標とはなり得ません。産業導入においては、ベンチマークスコアよりも、実際のワークフローに組み込んだときの効果を測定することが重要だということです。
ここまで、SWE-bench Verified 80%達成という現在地と、その数字の裏にある複雑な現実を見てきました。続いて、コード生成エージェントに残された課題と、今後の研究の方向性を考えます。
未解決の課題
コード生成AIは急速に発展しましたが、万能ではありません。LLMには本質的な限界があることも明らかになりつつあります。Arizona State UniversityのKarthik Valmeekamらによる研究 [Valmeekam et al., arXiv 2023] は、LLMの自律的計画生成能力を調査しました。国際計画競技（IPC）のドメインを用いた評価で、LLMの計画生成成功率は平均約3%に過ぎませんでした。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回目の反復で効果を失います。セルフ修正はモデル自身のフィードバック能力によって制約されており、より強力な外部モデルをフィードバックに使用すると大幅に改善することから、自己改善の限界が示唆されています。
しかし、改善の兆しもあります。2024年9月、OpenAIは「o1」をリリースしました [OpenAI, Blog 2024]。o1は従来のLLMとは根本的に異なるアプローチを採用しています。大規模な強化学習を用いて訓練され、回答を生成する前に長い「思考の連鎖」を内部で展開します。これは推論時計算スケーリング（test-time compute scaling）という新しいパラダイムの具現化です。
従来のスケーリング則 [Kaplan et al., arXiv 2020] は、モデルのパラメータ数
この発見の意義は、技術的な側面を超えています。それまでAI研究は職人芸の側面が強く、アーキテクチャの工夫や学習手法の改良が性能向上の主な源泉でした。しかしスケーリング則は、計算資源とデータがあれば予測可能な形で性能が向上することを示しました。これにより、AI研究は「発明」から「投資」の問題へと転換したのです。数十億ドル規模の投資が合理的になったのは、リターンが予測可能になったからです。同時に、これは研究の民主化とは逆方向への動きでもありました。最先端の研究には巨大な資本が必要になり、大企業と学術機関の間の格差が広がりました。
Kaplan et al.によるスケーリング則の実験結果。左から計算量（PF-days）、データ量・パラメータ数の増加に伴い、テスト損失がべき乗則に従って減少する（両対数グラフで直線関係）。出典: [Kaplan et al., arXiv 2020]
しかし2022年、DeepMindのJordan Hoffmannらによる「Chinchilla」研究 [Hoffmann et al., NeurIPS 2022] はKaplanの知見を修正しました。彼らは計算予算を固定したとき、パラメータ数
この発見の実務的影響は大きなものでした。当時の最大モデルであるGopher（280Bパラメータ）は、Chinchillaの基準では「過小訓練」でした。同じ計算予算で70Bパラメータのモデルを4倍のデータで訓練すれば、より高性能になる。実際、Chinchilla（70B）はGopher（280B）を上回りました。MetaのLLaMA [Touvron et al., arXiv 2023] はこの知見を直接応用し、7B〜65Bのモデルをより多くのトークンで訓練することで、より大きなモデルに匹敵する性能を実現しました。現在のオープンソースLLMの多くは、このChinchilla最適化の恩恵を受けています。
パラメータを増やせば性能は向上するが、収穫逓減が働く。しかしo1は、推論時（inference time）により多くの計算を投入することで性能を向上させます。Snellらの研究 [Snell et al., arXiv 2024] は、この推論時計算スケーリングを理論的に分析しました。問題の難易度に応じて「思考時間」を調整することで、同じモデルでもはるかに良い結果を得られます。簡単な問題には少ない計算を、難しい問題にはより多くの計算を割り当てる適応的なアプローチです。
o1のAIME（American Invitational Mathematics Examination）精度。左図は訓練時計算量、右図は推論時計算量に対するpass@1精度を示す。両者とも対数スケールで直線的に向上しており、推論時計算が訓練時計算と同様にスケールする新たな軸であることを示している。出典: [OpenAI, Learning to Reason with LLMs 2024]
o1はAIMEで83%の精度を達成し、競技プログラミングでも高い性能を示しました[13]。その後継であるo3は、さらに競技プログラミングで世界上位200人に匹敵する性能を達成しました [Codeforces Discussion Thread]。
DeepSeek-R1 [DeepSeek, arXiv 2025] は純粋な強化学習で同様の推論能力を向上させる可能性を示しました。
o1の成功を支える技術的要因として、Process Reward Model（PRM）の役割が重要だと考えられています。OpenAIの "Let's Verify Step by Step" 研究 [Lightman et al., arXiv 2023] は、報酬モデルの設計における重要な洞察を示しました。従来のOutcome Reward Model（ORM）は最終回答のみを評価しますが、PRMは推論の各ステップを評価します。
| 特性 | ORM（Outcome Reward Model） | PRM（Process Reward Model） |
|---|---|---|
| 評価対象 | 最終回答のみ | 推論の各ステップ |
| フィードバック | 正解/不正解の二値 | 各ステップの妥当性 |
| エラー検出 | 最後まで誤りに気づかない | 途中で軌道修正可能 |
| 訓練データ | 正解ラベルのみ必要 | ステップごとのラベル必要 |
MATH-500ベンチマークでは、PRMは78.2%の精度を達成し、ORMの72.4%を上回りました。各ステップを検証することで、途中で誤った推論に陥るのを防ぎ、より確実に正解へ到達できるのです。この知見がo1の設計に影響を与えたと推測されています。
ORM（結果監督）とPRM（プロセス監督）報酬モデルの比較。問題あたりの解候補数Nを増やすと、PRMはORMやMajority Votingを一貫して上回る。N=1860でPRMは78.2%、ORMは72.4%、Majority Votingは69.6%を達成。出典: [Lightman et al., arXiv 2023]
このアプローチの重要性は、スケーリングの軸を増やしたことにあります。モデルサイズの増大には物理的・経済的限界がありますが、推論時の計算量は問題ごとに柔軟に調整できます。困難な問題には数分間「考える」ことを許容し、簡単な問題には即座に回答する。これは人間の思考様式に近いアプローチであり、Chain-of-Thoughtプロンプティングの自然な発展とも言えます。
最近の研究は、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の夢が、まったく異なる技術的基盤の上で実現しつつあることを示しています。演繹的合成は計算量の壁に阻まれましたが、ニューラルネットワークの直感と形式システムの厳密性を組み合わせることで、その壁を回避できるかもしれません。
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では、透明性、著作権、安全性に関する要件が定められています。米国では包括的な連邦法はまだありませんが、大統領令でウォーターマーキング研究が求められています。
事前学習スケーリングの限界と研究の時代
ただし、ニューロシンボリック統合だけが答えとは限りません。2025年11月、OpenAIの共同創業者でありSafe Superintelligence Inc.のCEOであるIlya Sutskeverは、Dwarkesh Patelとのインタビューで示唆的な発言をしています [Sutskever, Dwarkesh Podcast 2025]。
Sutskeverによれば、AIは「スケーリングの時代」（2020-2025年）から「研究の時代」に戻りつつあります。スケーリングが「部屋の中の空気を全て吸い尽くした」ため、誰もが同じことをしていた。計算資源とデータを増やせば性能が向上するという単純なレシピは、その成功ゆえに多様なアプローチを抑圧してきました。しかし事前学習データには限りがある。これまでのレシピがこれからも機能するとは限りません。
より根本的な問題も指摘されています。「これらのモデルは、人間よりも劇的に汎化が悪い。これは非常に根本的なことだ」とSutskeverは述べています。ベンチマークでは優れた成績を収めるモデルが、実際のデプロイでは基本的なタスクで失敗する。バグを導入したり除去したりを繰り返す「奇妙なこと」が起きている。
具体例を挙げましょう。LLMは「97は素数か？」という質問に正しく答えられますが、「793は素数か？」になると途端に怪しくなります。訓練データに出現した数と、出現しなかった数への対応が劇的に異なる。人間はどちらも同じアルゴリズム（割り算の試行）で解けますが、LLMはそうではありません。コード生成でも同様です。標準的なAPIの使い方は完璧に書けても、ドキュメントにない使い方や、新しいバージョンの変更点には脆弱です。
人間が桁違いに少ないデータから学習しながら、なぜはるかに堅牢に汎化できるのか。認知科学では、人間は「抽象的な規則」を学習するのに対し、ニューラルネットワークは「統計的パターン」を学習するという見方があります。人間の子供は数個の例から「複数形は-sをつける」というルールを抽出し、見たことのない単語にも適用できます。LLMは膨大な例から表面的なパターンを学習しますが、そのパターンが「なぜ」機能するのかは理解していない可能性があります。
この汎化の謎には、まだ発見されていない「何か根本的なもの」があるのかもしれません。
これはなぜそれほど重要なのでしょうか。汎化能力の差は、コード生成AIの将来を左右する本質的な問題だからです。人間のプログラマは、初めて見るフレームワークでも基本的な設計原則を応用できます。なぜならプログラミングの「本質」を理解しているからです。一方、LLMは訓練データに類似したパターンがなければ途端に脆くなります。ベンチマークが示す能力と実務での信頼性の乖離は、この汎化ギャップの直接的な表れです。もしこの問題が解決されなければ、これらのツールは「補助ツール」から「自律的な開発者」への移行に根本的な壁があることになります。逆に解決されれば、ソフトウェア開発の性質そのものが変わる可能性があるということです。
Transformer以外の道
こうした背景から、Transformerアーキテクチャを超える研究も活発化しています。
計算効率の観点では、State Space Models（SSM）とDiffusion-based LLMsが注目されています。Mamba [Gu & Dao, arXiv 2023] に代表されるSSMは、Transformerの二次計算量
記憶と理解の観点では、Memory-Augmented ArchitecturesとWorld Modelsが進展しています。GoogleのTitans [Behrouz et al., arXiv 2024] は、従来のAttentionブロック（短期記憶）に加えてニューラル長期記憶（LTM）モジュールを導入し、現在のコンテキストウィンドウを超えた情報を保持することで、より人間的な記憶パターンに近づこうとしています。World Modelsは、コードを統計的なパターンとして学習するのではなく、プログラムの実行をシミュレートし因果関係を理解するアプローチで、パターンマッチングから因果理解への転換を目指しています。
これらのどれが正しいのか、あるいはまったく別の何かが必要なのか、現時点では誰にもわかりません。しかし、一つ確実なことがあります。事前学習スケーリング一辺倒の時代が終わりつつあることで、研究の多様性が回復しつつあるということです。次のブレイクスルーは、今日予測できない方向から来る可能性が高いと言えるでしょう。
タスク時間軸という新たな指標
能力を測る新しいアプローチとして、Epoch AIとMETRが共同開発した「タスク時間軸（Task Horizon）」メトリクスが注目されています。これは「AIエージェントが50%の信頼性で完了できるタスクの長さ」を測定するものです。
| モデル | タスク時間軸 |
|---|---|
| GPT-3.5 | 36秒 |
| GPT-4 Nov '23 | 9分 |
| Claude 3.5 Sonnet (Old) | 18分 |
| o1 | 39分 |
| o3 | 1時間32分 |
| GPT-5.1-Codex-Max | 2時間42分 |
各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]。Jaime Sevillaの完全な認知タスク自動化への中央予測は2035年（90%CI: 2027-2050）、Yafah Edelmanは2034年、Ege Erdilは10年以内のフルリモートワーク自動化に約30%の確率を割り当てています。
くどいようですが、これらはあくまで傾向の外挿であり、技術的ブレイクスルーや予期せぬ障壁によって大きく変動し得ます。「ベンチマークを解くこと」と「開発者を置き換えること」の間には依然として大きなギャップがあります。ここにMETR研究の重要な発見があります。モデルがSWE-benchで80%以上を達成しても、現実世界の複雑なコードベースでは経験豊富な開発者の生産性を19%低下させることがある。ベンチマークと実プロジェクトの間には、まだ大きな溝があるということです。
おわりに
冒頭で「なぜ、これほど急速だったのか」と問いました。
本稿を書きながら見えてきた一つの解釈は、三つの流れの収束という視点です。Greenの定理証明（1969年）に始まる形式的手法は「何が正しいか」の基準を、ShannonとRosenblattに遡る帰納的学習は「大量の例から学ぶ」能力を、SimonとNewellのGPS（1957年）に始まるエージェント研究は「自律的に問題を解く」枠組みを、それぞれ数十年かけて磨いてきました。これらが2020年代に同時に成熟期を迎え、Transformerと計算資源の指数関数的成長が収束を加速させた。その結果が、約2年間でのSWE-benchスコアの劇的な進化だったのです。
ただ、冒頭で述べたように、本稿が描いた三つの流れは無数にあり得た物語の一つに過ぎません。1956年のダートマス会議でMcCarthy、Minsky、Shannon、NewellとSimonが描いた夢は、部分的に実現しつつあります。しかし、彼らが想像した形とは異なるかもしれません。
現実は複雑です。ジュニア開発者に27-39%の生産性向上をもたらすツールが、シニア開発者には19%の低下をもたらすこともある。SWE-bench Verifiedで80%を超え、Microsoftの新規コードの30%を書くテクノロジーが、実際に開発者を助けるかどうかは、どう使われるかによって大きく異なります。正しいプログラムとは何か、知的なプログラミングとは何か、人間はプログラミングから解放されるべきか。私たちは今、答えの出ない新たな問いの前に立っています。
それでも、1936年にTuringが計算可能性を定義して以来、プログラムを自動生成したいという夢がこれほど実現に近づいたことはありませんでした。AI Coding Agentsは理論的・歴史的に面白いだけでなく、実用上の意義も大きいところが私は好きです。本稿が皆さんのAIによるコード生成について理解を深める参考になれば嬉しいです。
-
ただし公平を期すと、最初の「AIの冬」（1970年代）の原因は複合的でした。英国のLighthill報告（1973年） [Lighthill, Science Research Council 1973] による批判、過大な期待に対する失望、計算資源の限界なども大きな要因です。『Perceptrons』だけが原因という解釈にはMinsky自身も後年異議を唱えています。 ↩︎
-
2025年現在、この論文は20万回以上引用されており、21世紀で最も影響力のある論文の一つとなっています。 ↩︎
-
pass@kの不偏推定量は
\text{pass@}k = 1 - \frac{\binom{n-c}{k}}{\binom{n}{k}} n c k -
5日間で100万ユーザー、2ヶ月で1億ユーザーに到達しました [Reuters, ChatGPT Sets Record 2023]。 ↩︎
-
ただし、この主張には議論があります。MITのMartínez（2024）は、GPT-4の実際の順位は全体の69パーセンタイル以下、エッセイでは48パーセンタイル程度である可能性を指摘しています [Martínez, Artificial Intelligence and Law 2024]。 ↩︎
-
LoRAは重み行列を低ランク分解し、元のパラメータの0.01%程度の追加パラメータのみを訓練することで、消費者向けGPU（11-24GB VRAM）での訓練を可能にしました。QLoRAは4bit量子化を組み合わせ、65Bパラメータのモデルを単一48GB GPUで訓練可能にしました。 ↩︎
-
問題あたりの平均コストはわずか$0.70でした。シンプルな手法でも高性能が可能であることを示し、過度に複雑なアーキテクチャへの問題提起となりました。 ↩︎
-
SWE-bench Verifiedは2024年8月にリリースされた、より厳密に検証されたサブセット（500問）です [OpenAI, SWE-bench Verified 2024]。 ↩︎
-
SWE-bench Proは2025年にScale AIが発表した拡張ベンチマーク。従来のSWE-bench VerifiedやSWE-bench Liteとは別のデータセットです。 ↩︎
-
AnthropicのClaudeは、本稿冒頭で紹介した情報理論の父Claude Shannonにちなんで名付けられたとされています。情報を統計的に扱うというShannonの発想は、現代のLLMの理論的基盤そのものです。 ↩︎
-
N個のLLMとM個のツールを個別に接続するとN×M通りの統合が必要になる問題。標準プロトコルによりN+M通りに削減できます。 ↩︎
-
Mixture-of-Experts（671Bパラメータ中37Bがアクティブ）とFP8混合精度訓練により、2,788万H800 GPU時間で14.8兆トークンを学習。この558万ドルはGPU使用料のみであり、研究開発費、人件費、先行実験のコストは含まれていません。 ↩︎
-
AIME（American Invitational Mathematics Examination）は米国数学オリンピックの予選試験です。o1はCodeforcesで89パーセンタイルに到達しました。 ↩︎
-
AlphaProofが代数・数論の3問（P1, P2, P6）を、AlphaGeometry 2が幾何の1問（P4）を解きました。特にP6は609人の参加者中わずか5人しか解けなかった最難問題です。組合せ論の2問（P3, P5）は未解決のまま残りました。 ↩︎
-
FlashAttentionカーネルで最大32.5%の高速化、行列乗算カーネルで23%の高速化を達成し、Geminiの訓練時間を1%削減。数学的発見では、4×4複素数行列乗算を48回の演算で実現（1969年のStrassenアルゴリズムから改善）し、11次元のキッシング数問題で新しい下界を確立しています。 ↩︎
-
確認された脆弱性には、CWE-20（不適切な入力検証）、CWE-78（OSコマンドインジェクション）、CWE-89（SQLインジェクション）などがあります。 ↩︎
-
Python Software Foundationのセキュリティ開発者Seth Larsonが命名。"Slop"（AI生成の低品質コンテンツを指すスラング）と "Typosquatting"（タイポを悪用した攻撃）を組み合わせた造語です。 ↩︎
株式会社エアークローゼットは「発想とITで、人々の日常に新しいワクワクを創造する」をミッションに、ファッションレンタルプラットフォーム"airCloset"や、話題の商品のお試し利用が可能な家具家電レンタルサービス"airClosetMall"といった事業を展開しています。
Discussion