ソフトウェアが扱う状態や入力の候補は、システムを構成する要素が増えるにつれて急速に増える。二つの値しか取らない変数が \(n\) 個あるだけでも、入力の組み合わせは \(2^n\) 通りになる。変数が 10 個なら 1,024 通りだが、100 個なら約 \(1.27\times10^{30}\) 通りである。さらに、複数のコンポーネントが互いに依存し、その依存関係自体にも複数の構成があり得るなら、候補となるシステム構造は入力の組み合わせよりさらに大きくなる。
この事実から、「人間があらかじめすべての条件をコードへ書き込む方式は、システム規模の増大に耐えられない」という説明が導かれることがある。人間が事前に判断規則を実装する従来型ソフトウェアでは、問題の組み合わせが増えるほど開発者が扱うべき場合分けも増える。それに対して AI エージェントは、利用時の要求や環境を読み、その時点で必要な処理を判断できる。すべての場合を開発時に固定しなくてよいのなら、AI エージェントの方が巨大な問題空間に対して有利だという推論である。
この推論を検討するには、最初に「何が増えているのか」を分けなければならない。あるシステムが取り得る状態の総数、正しい振る舞いを指定するために必要な記述量、一つの入力から結果を求めるための計算量は、それぞれ別の量であり、一つが指数的に増えるからといって、残りも同じ速度で増えるとは限らない。
例えば、100 個の二値変数からなる入力空間には約 \(1.27\times10^{30}\) 通りの入力が存在する。入力に共通する規則を一つ記述できれば、個別の答えをすべて保存せず、その規則を各入力へ適用できる。多数のケースを一つの規則へまとめることができるなら、入力空間の大きさとプログラムの大きさは一致しない。
反対に、入力ごとの正しい出力に共通規則がなく、すべてのケースを別々に区別しなければならないなら、その区別に必要な情報をどこかへ保持する必要がある。この制約は、判断主体を人間から AI へ移しても残る。ソースコードに保存しなくても、モデルの重み、プロンプト、コンテキスト、外部記憶、データベース、ツールから得る情報のどこかに、正しい判断を可能にする情報が存在しなければならない。
この二つを分けると、AI エージェントを評価するときの問いも変わる。「指数的に増える状態空間を AI が処理できるか」だけでは足りない。状態間にどの程度の規則性があるのか、その規則性をどれだけ短く記述できるのか、正しい判断に必要な情報を開発時と実行時のどちらで取得するのかを分けて考える必要がある。
AI エージェントによって変化するのは、この最後の部分である。従来型ソフトウェアでは、開発者が要求を分析し、判断規則の多くをコード、設定、データ構造、テストとして開発時に固定する。AI エージェントでは、その一部を実行時まで確定せず、現在の要求や環境を観測してからモデルに選ばせることができる。複雑性が消えるというより、開発時に処理していた判断の一部を実行時へ移せる。
この違いを明らかにするため、まず最も単純な場合から考える。可能な入力が指数的に多いというだけで、プログラムまで指数的に複雑になるのかを確認する。
1. 可能な状態が多いことと、複雑なプログラムが必要なことは同じではない
1.1 入力が \(2^n\) 通りあっても、\(2^n\) 個の処理を書く必要はない
\(n\) bit の入力を考える。それぞれの bit は 0 または 1 の二つの値を取るため、可能な入力の総数は次の式で表せる。
\[
|\mathcal{X}_n|=2^n
\]
\(\mathcal{X}_n\) は入力として与えられる bit 列の集合であり、\(|\mathcal{X}_n|\) はその要素数を表す。1 bit なら 0 と 1 の 2 通り、2 bit なら 00、01、10、11 の 4 通り、3 bit なら 8 通りになる。bit が一つ増えるたびに、それまでの各入力について末尾が 0 の場合と 1 の場合が生じるため、候補数は 2 倍になる。
| bit 数 | 入力候補数 | 候補数の増え方 |
|---|---|---|
| 1 | 2 通り存在する。 | 0 と 1 の二つを区別する。 |
| 10 | 1,024 通り存在する。 | \(2^{10}\) として計算できる。 |
| 20 | 1,048,576 通り存在する。 | 10 bit の場合の 1,024 倍になる。 |
| 100 | 約 \(1.27\times10^{30}\) 通り存在する。 | 個別に列挙することが現実的でない規模になる。 |
100 bit の場合にすべての入力を列挙し、それぞれについて専用の処理を書く方式を採れば、確かに現実的なプログラムにはならない。しかし、入力候補が \(2^{100}\) 通り存在することから、「正しい処理を記述するには \(2^{100}\) 個の条件分岐が必要である」とは導けない。この二つの間には、入力どうしに共通する規則を利用できるかという条件が入る。
例えば、入力された bit のうち 1 が偶数個なら 0、奇数個なら 1 を返す parity 関数を考える。この関数は、すべての入力 bit の排他的論理和として次のように書ける。
\[
f_n(x)=x_1\oplus x_2\oplus\cdots\oplus x_n
\]
\(x_1,\ldots,x_n\) は入力を構成する各 bit、\(\oplus\) は排他的論理和を表す。二つの入力が異なるときに 1、同じときに 0 を返す演算である。例えば、入力が 1、0、1 の 3 bit なら、
\[
1\oplus0\oplus1=0
\]
となる。1 が二つ含まれているため結果は 0 になる。入力が 1、0、0 なら、
\[
1\oplus0\oplus0=1
\]
となり、1 が一つだけなので結果は 1 になる。
この計算を実行するために、000、001、010、011 といった入力を事前にすべて列挙する必要はない。最初の bit から順番に排他的論理和を取り、最後の結果を返せばよい。入力が 100 bit なら 100 bit を順番に処理し、1,000 bit なら 1,000 bit を処理する。入力候補数そのものは \(2^n\) だが、一つの入力に対して必要な処理回数は \(n\) に比例する。
この違いを計算量の記法で表すと、parity の実行時間は
\[
T(n)=\Theta(n)
\]
になる。\(\Theta(n)\) は、入力長を 2 倍にすれば処理量もおおむね 2 倍になる線形の増え方を表す。一方、可能な入力数は
\[
|\mathcal{X}_n|=2^n
\]
である。入力空間は指数的に増えているが、一回の計算量は線形にしか増えていない。
1.2 アルゴリズムは個別の答えではなく、答えを作る規則を保存する
parity の例は、プログラムが多数の入力を扱える基本的な仕組みを示している。個々の入力と答えの組をすべて保存する代わりに、入力から答えを導く規則を保存している。
二つの方式を比較すると違いが見える。100 bit のすべての入力について結果をあらかじめ計算し、入力と答えを対応させた表を用意するなら、表には \(2^{100}\) 件のエントリーが必要になる。この方式では、入力空間の大きさがそのまま保存量へ現れる。
これに対して、parity の規則を保存する場合、必要なのは「各 bit の排他的論理和を取る」という処理である。入力が何通り存在するかに関係なく、同じ規則を適用できる。入力が増えたときに必要なのは、その入力を読む追加の計算時間であり、入力候補一件ごとに別のプログラムを追加することではない。
| 方式 | 保持するもの | 入力候補が増えたときの影響 |
|---|---|---|
| 全ケース列挙 | 入力ごとの正しい出力を個別に保持する。 | 区別する入力が増えるほど、対応表の大きさも増える。 |
| アルゴリズム | 入力から出力を計算する共通規則を保持する。 | 同じ規則を適用できる限り、入力候補の総数を個別に保存する必要はない。 |
ソートも同じ構造を持つ。\(n\) 個の互いに異なる値を並べる順序は \(n!\) 通り存在するが、ソートプログラムは \(n!\) 種類の入力順序を個別に記録しているわけではない。比較と交換を組み合わせた規則によって、どの順序で入力されても並べ替える。加算、検索、構文解析、経路探索にも、それぞれ扱う入力空間より短い規則を利用できる問題がある。
この構造があるため、「可能なケースが多い」という事実だけでは、人間がどれだけの判断を事前にコード化しなければならないかを決められない。必要な記述量を左右するのは、ケース数そのものだけではなく、ケース間に共通する性質を一つの規則へまとめられるかである。
1.3 状態数、記述量、計算量を分けなければ複雑性を比較できない
parity の例から、少なくとも三つの量を分けられる。
| 量 | parity の場合 | 何を測っているか |
|---|---|---|
| 状態空間 | \(2^n\) 通り存在する。 | 入力として区別し得るケースの総数を測っている。 |
| 記述量 | 各 bit の排他的論理和を取るという短い規則で表現できる。 | 正しい振る舞いを指定するために必要な情報を測っている。 |
| 実行計算量 | \(\Theta(n)\) になる。 | 一つの入力から結果を得るために必要な処理量を測っている。 |
この三つは関連していても同一ではない。状態空間は「どれだけ多くのケースを区別し得るか」を示す。記述量は「そのケースに対する正しい振る舞いをどれだけ短い規則で表せるか」を示す。実行計算量は「与えられた一つのケースについて、その規則から答えを得るためにどれだけ処理するか」を示す。
状態空間だけを見てソフトウェアの複雑性を評価すると、この三つが一つに潰れる。\(2^n\) 通りの入力があるという事実から、開発者が \(2^n\) 通りを理解しなければならず、プログラムも \(2^n\) 個の判断を持たなければならず、一回の処理にも \(2^n\) の計算が必要だという推論へ進んでしまう。parity は、その三つが一致しない具体的な反例になっている。
この区別は、AI エージェントとの比較にも直接影響する。従来型ソフトウェアが巨大な状態空間を扱うために全状態を事前列挙しているなら、実行時に判断できる AI エージェントには明確な構造上の優位がある。しかし、従来型ソフトウェアも共通規則を使って状態空間を圧縮しているなら、比較すべき対象は状態数ではなく、その規則をどれだけ短く表せるか、その規則を事前に確定できるか、実行時まで確定できない情報がどれだけあるかになる。
入力候補が指数的に増えるという事実は、複雑性を考える出発点にはなる。その事実だけでは従来型ソフトウェアの限界も、AI エージェントの優位も証明できない。次に確認すべきなのは、多数のケースを短い規則へまとめられるとき、何が圧縮されているのかである。
2. 規則性がある問題は、巨大な状態空間でも短く記述できる
2.1 状態の候補数と、振る舞いを指定する情報量は別に数える
前章では、\(2^n\) 通りの入力が存在しても、一つの入力を処理する計算量まで \(2^n\) になるとは限らないことを parity の例で確認した。ここではもう一段進めて、「正しい振る舞いそのものを指定するために、どれだけの情報が必要なのか」を考える。入力候補の数、入力の出現確率、特定の振る舞いを再現するための記述量は、それぞれ異なる対象を測っている。
Shannon は、ある記号がどの確率で現れるかという分布をもとに、通信によって伝える情報量と平均符号長の関係を定式化した[1]。この枠組みが扱うのは、ある確率分布から発生する情報を平均的にどれだけ効率よく表現できるかという問題である。一方、Chaitin は個々の有限二進列について、その列を生成するプログラムの長さから複雑性を捉える議論を示した[2]。Shannon の情報量と Chaitin のプログラム長は同一の量ではないが、本稿で必要になる区別をそれぞれ別の側面から与える。候補が多数存在することと、そのうち一つの対象や規則を短く記述できることは両立する。
例えば 100 bit の入力には、約 \(1.27\times10^{30}\) 通りの候補がある。この数字は「入力として何通りを区別し得るか」を示している。入力に対して「1 の個数を数える」「最大値を求める」「一定の規則で並べ替える」といった処理を行う場合、その振る舞いを \(1.27\times10^{30}\) 件の対応表として保存する必要はない。すべての入力へ共通して適用できる規則が存在するため、その規則だけを記述すればよい。
候補数が大きくても記述量を小さくできる直接の理由は、複数のケースが同じ規則を共有していることにある。個別ケースを一件ずつ保存する方式では、ケース数の増加がそのまま保存量の増加につながる。共通規則を保存する方式では、多数のケースが一つの記述を共有するため、ケース数と記述量が切り離される。アルゴリズムによる圧縮とは、この共有可能な構造を取り出すことである。
2.2 短いプログラムで再現できるなら、入力空間全体を保存する必要はない
この関係を数式で表すため、関数 \(f_n\) の振る舞いを再現する最短のプログラム記述の長さを bit 単位で \(K(f_n)\) と書く。ここでの \(K(f_n)\) は、固定した計算モデルのもとで \(f_n\) を計算する手続きをどれだけ短く記述できるかを表す尺度として用いる。計算モデルの選び方によって定数分の差は生じ得るが、本稿で問題にするのは、全入力に対する出力を個別列挙した記述量に対して、共通規則を使った記述量がどの程度小さくなるかという桁の違いである。
\(n\) bit の入力集合を \(\mathcal{X}_n\) とすれば、その要素数は
\[
|\mathcal{X}_n|=2^n
\]
である。この式は、入力として区別し得る bit 列が \(2^n\) 個存在することだけを表している。ここには、それぞれの入力に対してどのような出力を返すべきかという規則は含まれていない。
もし \(f_n\) が parity のような Boolean 関数で、簡潔な規則を持つなら、その振る舞いは、全入力に対する出力を個別に並べた真理値表よりはるかに短く記述できる。\(n\) bit の入力すべてに 1 bit の出力を割り当てる真理値表の記述長を \(L_{\mathrm{table}}(f_n)\) とすれば、
\[
L_{\mathrm{table}}(f_n)=2^n\ \text{bit}
\]
であり、簡潔な規則を持つ関数では、
\[
K(f_n)\ll L_{\mathrm{table}}(f_n)
\]
となり得る。ここでは両辺とも振る舞いを表す記述長を bit 単位で比較している。入力集合の要素数が \(|\mathcal{X}_n|=2^n\) であることだけから、最短プログラムの記述長 \(K(f_n)\) まで指数的に増えるとは導けない。
具体的には、parity の場合、入力長が 100 bit から 1,000 bit、1,000,000 bit へ増えても、「各 bit の排他的論理和を順番に取る」という規則自体はほとんど変わらない。増えるのは主として一回の実行で読む入力の長さであり、入力候補一件ごとの振る舞いを追加記述する必要はない。状態空間は \(2^n\) の速度で増えても、それを処理する規則の記述量は同じ速度では増えない。
| 対象 | 表しているもの | 規則性がある場合 |
|---|---|---|
| 入力候補数 \(|\mathcal{X}_n|\) | 区別し得る入力が何通り存在するかを表す。 | \(n\) bit なら \(2^n\) 通りまで増える。 |
| 記述量 \(K(f_n)\) | 入力から正しい出力を得る規則をどれだけ短く記述できるかを表す。 | 共通規則が簡潔なら、真理値表として個別列挙する \(2^n\) bit より大幅に小さくできる。 |
| 実行計算量 | 一つの入力について規則を実行するための処理量を表す。 | parity なら入力長 \(n\) に比例する。 |
この三つを分けることで、「巨大な問題空間」という表現の中身を具体化できる。入力候補が巨大であることは事実でも、同じ規則を多数の入力へ適用できるなら、その候補を個別に記述する必要はない。入力空間の指数的増加が直ちに開発量やプログラム長の指数的増加へ変換されるためには、「入力間の規則性を利用できず、ケースを個別に区別しなければならない」という追加条件が必要になる。
2.3 ソフトウェア開発は、状態を列挙するより構造を固定する
実際のソフトウェア開発では、可能な状態を一件ずつ頭の中で走査する代わりに、入力形式に共通する性質を型やスキーマとして定義し、処理に共通する規則をアルゴリズムへ落とし、変更の影響を局所化するためにデータ構造やモジュール境界を設ける。個別ケースをすべて覚える代わりに、「どのケースを同じ規則で扱えるか」を決めている。
例えば Web サーバーは、将来到着する HTTP リクエストを一件ずつ事前登録しているわけではない。メソッド、パス、ヘッダー、認証状態などの構造を読み取り、それぞれに共通するルーティング規則やアクセス制御を適用する。データベースも、将来格納される全レコードを列挙して設計するのではなく、スキーマ、制約、インデックス、問い合わせ規則によって、未到着のデータを処理できる構造を先に定義する。
この設計が可能なのは、現実のソフトウェアが扱う問題に完全な無秩序を仮定していないからである。HTTP リクエストにはプロトコル上の形式があり、データベースにはスキーマがあり、ファイルシステムには名前空間と操作規則がある。ソフトウェア工学は、存在し得る全状態を保存する代わりに、このような規則性を明示的な構造へ変換することで巨大な状態空間を扱ってきた。
この観点を入れると、「状態空間が人間の認知能力を超えるから、静的ソフトウェアは必然的に限界へ達する」という推論には一段足りないことが分かる。必要なのは状態数と人間の記憶容量の比較ではなく、その状態集合をどれだけ短い規則へ圧縮できるかの評価である。圧縮可能な構造を抽出できる限り、人間は全状態を保持する必要がなく、ソフトウェアも全ケースを個別に実装する必要がない。
ただし、この結論は「どの問題でも短く記述できる」という意味ではない。規則性によって多数のケースを一つへまとめられる問題がある一方で、ケースごとの違いを圧縮できない問題も存在する。前者だけを見れば、巨大な状態空間からソフトウェアの複雑性を直接導く議論は崩れる。後者まで含めて AI エージェントの優位を検討するには、圧縮できない情報を AI が本当に回避できるのかを確認する必要がある。
3. 規則性がなければ AI も必要な情報量を消せない
3.1 任意の対応を許すと、関数の数は入力数よりさらに速く増える
前章では、入力候補が \(2^n\) 通り存在しても、入力間に共通規則があれば、振る舞いを入力候補数より短く記述できることを確認した。では、その共通規則を仮定できない場合はどうなるのか。ここでは、\(n\) bit の入力を受け取り、0 または 1 を返す Boolean 関数を考える。
\[
f:\{0,1\}^n\rightarrow\{0,1\}
\]
入力は \(2^n\) 通り存在する。それぞれの入力に対して、出力を 0 にするか 1 にするかを独立に選べるとする。すると、異なる Boolean 関数の総数は次のようになる。
\[
|\mathcal{F}_n|=2^{2^n}
\]
この指数が二重になる理由は、二つの選択が重なっているからである。まず入力が \(2^n\) 個ある。次に、その入力一つ一つについて出力を 0 または 1 の 2 通りから選ぶ。\(2^n\) 個の入力すべてについて二者択一を行うため、関数の総数は \(2^{2^n}\) 個になる。
例えば \(n=2\) なら、入力は 00、01、10、11 の 4 通りである。この 4 入力それぞれに 0 または 1 を割り当てるため、異なる関数は
\[
2^4=16
\]
個存在する。ある関数は四つすべてに 0 を返し、別の関数は 00 にだけ 1 を返し、さらに別の関数は 00 と 11 に 1 を返す。このような対応をすべて許した結果が 16 通りである。\(n\) を一般化すると \(2^{2^n}\) になる。
| 入力 bit 数 | 入力候補数 | Boolean 関数の総数 |
|---|---|---|
| 1 | \(2\) 通り存在する。 | \(2^2=4\) 個存在する。 |
| 2 | \(2^2=4\) 通り存在する。 | \(2^4=16\) 個存在する。 |
| 3 | \(2^3=8\) 通り存在する。 | \(2^8=256\) 個存在する。 |
| \(n\) | \(2^n\) 通り存在する。 | \(2^{2^n}\) 個存在する。 |
前章の parity は、この巨大な関数集合の中でも短い規則で記述できる一例だった。しかし、\(2^{2^n}\) 個あるすべての関数が同じように短く記述できるわけではない。入力ごとの出力に利用できる共通構造がなければ、どの入力に 0 を返し、どの入力に 1 を返すのかという区別そのものを情報として保持しなければならない。
3.2 すべての関数を区別するには、最悪の場合 \(2^n\) bit が必要になる
この必要情報量は、関数の総数を数えるだけで下限を求められる。固定された推論器を一つ用意し、その推論器へタスクごとに \(b\) bit の情報を与えるとする。推論器自体は変更せず、与えられた \(b\) bit によって、どの Boolean 関数を実行するかを指定する。
\(b\) bit で区別できる異なる情報列は最大で
\[
2^b
\]
個である。例えば 1 bit なら 0 と 1 の 2 通り、2 bit なら 00、01、10、11 の 4 通りしか区別できない。ところが、実現しなければならない Boolean 関数は
\[
2^{2^n}
\]
個ある。すべての関数を正確に区別して指定するには、利用可能な情報列の数が関数の数以上でなければならない。
\[
2^b\ge 2^{2^n}
\]
底が同じ 2 なので指数を比較すると、
\[
b\ge 2^n
\]
となる。つまり、どの Boolean 関数が与えられるかについて何の規則性も仮定せず、すべてを正確に実現できるようにするなら、最悪の場合には少なくとも \(2^n\) bit のタスク固有情報が必要になる。
ここで数えているのは、実行時に消費する計算量ではなく、どの振る舞いを実現すべきかを区別するための情報量である。モデルが高速に推論できるか、並列計算できるか、長いコンテキストを処理できるかとは別の制約になる。正しい対応そのものを知らなければならない以上、その対応を特定する情報はどこかから与えられなければならない。
この下限は、タスク固有情報の保存場所を限定していない。従来型ソフトウェアなら、ソースコード、設定ファイル、データベース、対応表として保持できる。AI エージェントなら、プロンプト、コンテキスト、長期記憶、検索結果、Skill、追加学習によって変更されたモデル重みとして保持できる。固定されたモデルの重みそのものに必要な規則がすでに含まれているなら、その情報は事前学習によってモデル側へ移されている。
| 保持場所 | タスク固有情報の例 | 情報量との関係 |
|---|---|---|
| ソースコード | 条件分岐、アルゴリズム、定数、ルールとして保持する。 | 必要な区別をプログラムの記述として保持する。 |
| データ | 対応表、設定、データベースとして保持する。 | 規則として圧縮できない区別をデータとして保持できる。 |
| モデル重み | 事前学習や追加学習で獲得した規則を保持する。 | 情報の保存場所をコードからモデルへ移せるが、必要な情報そのものが不要になるわけではない。 |
| コンテキスト・記憶 | タスク説明、過去の状態、検索結果、実行履歴を保持する。 | 実行時に必要な区別を外部から供給する。 |
例えば、固定された AI エージェントが未知の 100 bit 入力に対して任意の正解表を完全に再現しなければならないとする。その正解表に圧縮可能な規則がなく、学習データにも含まれず、外部データからも取得できないなら、モデルが「推論する」という操作だけで正解表を復元することはできない。正解を決める情報が入力されていないからである。推論は与えられた情報から結果を導く処理であり、任意の未知情報を無条件に生成する仕組みではない。
3.3 AI が利用する規則性も、問題側の構造から生まれる
現実の AI エージェントが有用なのは、自然言語、ソースコード、Web ページ、業務手順に大量の規則性があり、事前学習されたモデルはその規則性を利用できる。コード修正であれば、プログラミング言語の構文、一般的な API の使い方、既存コードの局所的なパターン、テスト結果と原因の対応などを再利用できる。
このとき AI は、個々のタスクについてゼロから \(2^n\) bit の対応表を受け取っているわけではない。多数のタスクに共有される構造をモデル重みへ圧縮しておき、個別タスクではリポジトリー、課題、テスト結果などの追加情報と組み合わせている。AI が少ない入力から有効な判断を生成できるのは、問題側に規則性があり、その規則性についてモデルが事前情報を持っているからである。
この説明は、前章で従来型ソフトウェアについて見た構造と対称になっている。従来型ソフトウェアも、問題に存在する共通規則をアルゴリズムとして圧縮する。AI エージェントも、問題に存在する共通規則をモデルやツールを通じて利用する。両者の違いは、規則をどのような表現で保持し、どの時点で個別ケースへ適用するかにある。
No Free Lunch theorem も、この区別を別の角度から示している。Wolpert と Macready は、探索・最適化問題について、対象となる目的関数を一様に平均すれば、あるアルゴリズムが他のアルゴリズムより普遍的に優れるわけではないことを示した[3]。現実の問題で特定のアルゴリズムが高い性能を示せるのは、現実の問題分布に偏りや規則性があり、その方式がそれを利用しているからである。
本稿の計数による議論は No Free Lunch theorem の証明を AI エージェントへ適用したものではない。扱っている対象も異なる。共通しているのは、問題側について何の構造も仮定しないまま、計算方式だけを理由に普遍的な優位を主張できないという点である。
| 問題の性質 | 従来型ソフトウェア | AI エージェント |
|---|---|---|
| 共通規則を利用できる | 規則をアルゴリズム、データ構造、モジュールとして記述し、多数の入力へ再利用できる。 | 事前学習されたモデル、プロンプト、ツールを通じて共有された規則性を個別タスクへ適用できる。 |
| タスク固有の追加情報が必要 | 設定、入力データ、外部データベースなどから取得する。 | コンテキスト、検索、長期記憶、ツールの応答などから取得する。 |
| 共通規則がなく任意の対応を正確に再現する | ケースを区別する情報をコードまたはデータとして保持する必要がある。 | ケースを区別する情報をモデル重み、コンテキスト、記憶、外部データのいずれかから供給する必要がある。 |
3.4 規則性の有無だけでは AI エージェントの普遍的優位を導けない
前章と本章を合わせると、AI エージェントと従来型ソフトウェアの比較には対称的な制約が生じる。
問題に圧縮可能な規則性がある場合、従来型ソフトウェアもその規則性をアルゴリズムとして利用できる。入力候補が指数的に多いことだけを理由に、静的なプログラムが指数的な記述量を必要とするとは言えない。
反対に、問題に利用可能な規則性がなく、任意の入力と出力の対応をすべて正確に区別しなければならない場合、AI エージェントも必要な情報をモデルの推論だけで消すことはできない。対応を特定する情報は、モデル重み、入力、コンテキスト、記憶、外部データのいずれかに存在する必要がある。
この二つを数式でまとめれば、次の関係になる。
\[
\begin{cases}
\text{圧縮可能な構造がある} &\Rightarrow \text{従来型ソフトウェアも構造を利用できる} \\
\text{圧縮可能な構造がない} &\Rightarrow \text{AI も必要情報量を回避できない}
\end{cases}
\]
この結果は、AI エージェントの実用的な優位と両立する。事前学習によって広い問題分布の規則性を保持できること、自然言語で与えられた要求を実行時に解釈できること、検索やツールを使って不足情報を取得できることには、従来型ソフトウェアとは異なる実用上の性質がある。
ただし、その優位を「指数的な状態空間を AI だけが回避できるから」と説明することはできない。AI が利用しているのも問題に存在する規則性と、事前学習や実行時取得によって与えられた情報だからである。AI エージェントと従来型ソフトウェアの差を調べるには、次に、従来型ソフトウェアが複雑な依存関係をどのように制限してきたのかを見る必要がある。
4. ソフトウェア工学は組み合わせを構造で制約する
4.1 依存関係の候補総数と、実際のシステムが持つ依存関係は別である
入力状態について「候補数」と「実際に必要な記述量」を分けたのと同じ区別が、コンポーネント間の依存関係にも必要になる。\(n\) 個のコンポーネントがあり、任意の二つの間に依存関係を置けるとする。依存関係を無向グラフとして単純化すると、二つのコンポーネントを選ぶ組み合わせは
\[
\binom{n}{2}=\frac{n(n-1)}{2}
\]
通りある。これは、グラフ上で辺を置くことのできる候補位置の数である。
各候補位置について、辺を置くか置かないかの 2 通りを選べるため、構成可能なグラフの総数は
\[
2^{\binom{n}{2}}
\]
個になる。例えば \(n=4\) なら辺候補は
\[
\binom{4}{2}=6
\]
本であり、異なる無向グラフは \(2^6=64\) 個存在する。\(n=10\) なら辺候補は 45 本になり、グラフ候補は \(2^{45}\) 個まで増える。
この数は、「10 個のコンポーネントから作り得る依存構造が非常に多い」ことを示している。しかし、一つのソフトウェアシステムが \(2^{45}\) 個の依存構造を同時に持つわけではない。実際に構築されるシステムは、その候補集合から選ばれた一つのグラフである。候補となる設計の数と、選択された一つの設計を理解・変更するための複雑性は分けて考えなければならない。
| 量 | 数え方 | 表しているもの |
|---|---|---|
| コンポーネント数 | \(n\) 個として数える。 | システムを構成する要素の数を表す。 |
| 辺候補数 | \(\binom{n}{2}\) 本として数える。 | 任意の二要素間に依存関係を置ける位置の総数を表す。 |
| 依存グラフ候補数 | \(2^{\binom{n}{2}}\) 個として数える。 | 構成可能な依存構造全体の候補数を表す。 |
| 実システムの辺数 | 実際に採用した依存関係だけを数える。 | 選択された一つのシステムで直接管理すべき関係の数を表す。 |
この区別を置かずに依存グラフ候補数をそのまま開発者が扱うべき複雑性とみなすと、「\(n\) が増えるほど、人間は \(2^{\binom{n}{2}}\) 個の構成を考慮しなければならない」というモデルになる。通常の設計では、アーキテクチャー上の制約を先に置き、許される依存関係そのものを減らす。
4.2 モジュール化は、依存関係の数だけでなく依存可能性そのものを制約する
完全グラフと木構造を比べると、この差が具体的に見える。すべてのコンポーネントがすべての他コンポーネントへ直接依存できる完全グラフでは、辺数は
\[
\frac{n(n-1)}{2}=\Theta(n^2)
\]
になる。コンポーネント数を 2 倍にすると、直接依存の本数はおおむね 4 倍になる。変更した一要素が多数の要素へ直接影響し得るため、変更範囲の推定や回帰確認も広がりやすい。
一方、木構造なら辺数は
\[
n-1=\Theta(n)
\]
である。コンポーネント数が 2 倍になっても、辺数はほぼ 2 倍にしかならない。完全グラフと木構造は同じ \(n\) 個の頂点を持っていても、実際に管理する依存関係の数と変更の伝播経路が異なる。
| 構造 | 辺数 | 変更時に生じる性質 |
|---|---|---|
| 完全グラフ | \(\Theta(n^2)\) 本になる。 | 各コンポーネントが多数の他要素へ直接依存できるため、局所変更が広い範囲へ波及しやすい。 |
| 木構造 | \(\Theta(n)\) 本になる。 | 接続経路が限定されるため、依存関係の総数と影響経路を抑えられる。 |
| モジュール境界を持つ階層構造 | 実装によって異なる。 | 外部へ公開する依存点を限定することで、内部変更を他モジュールから遮蔽できる。 |
ソフトウェア工学におけるモジュール化や情報隠蔽は、この構造差を意図的に作るための設計である。コンポーネントを単に複数の箱へ分けるだけではない。どの情報を外部へ公開し、どの実装判断を内部へ隠し、どの方向への依存だけを許すかを決める。その結果、理論上は存在し得る多数の依存関係を、実システムでは成立しない関係として排除できる。
例えば、データ保存方式を直接参照するモジュールが 20 個ある場合、保存方式の変更は 20 個の利用側へ波及し得る。保存処理を一つのインターフェースの背後へ隠し、利用側がそのインターフェースだけに依存する構造へ変えれば、保存方式の変更を内部へ閉じ込められる。コンポーネント数そのものは減っていなくても、変更によって再検討すべき依存関係は変わる。
このとき得られる効果は、「同じ依存グラフを少し効率よく扱える」という定数倍の改善だけではない。設計前には許されていた直接依存を禁止し、実際のグラフ構造そのものを変えている。完全結合に近い構造を階層化された構造へ変えれば、辺数の増え方や変更伝播の経路も変わり得る。
4.3 Simon と Parnas が扱ったのは、複雑性を構造で閉じ込める方法である
Simon は複雑なシステムについて、階層構造と near-decomposability が理解可能性を支えることを論じた[4]。near-decomposability は、部分同士が完全に独立しているという意味ではない。部分内部の相互作用が部分間の相互作用より強い、または速いという構造を持つことで、全体を常に一枚の巨大な系として扱わなくても、部分ごとの振る舞いをある程度分離して考えられる。
ソフトウェアへ置き換えると、モジュール内部では多数の処理が相互に依存していても、その内部状態を外部へ直接公開せず、限定されたインターフェースだけで接続すれば、他モジュールは内部の全状態を理解しなくても利用できる。内部変更が外部契約を破らない限り、影響範囲もそのモジュール内へ閉じ込めやすい。
Parnas は、モジュール分割の単位を単なる処理手順ではなく、将来変更され得る設計判断を隠す境界として考えるべきだと示した[5]。同じ機能を実現するシステムでも、処理の実行順序に沿って分割する場合と、変更され得る設計判断をそれぞれ一つのモジュール内部へ隠す場合では、変更時に理解し直す範囲が異なる。
例えばファイル形式、データ配置、入出力装置、アルゴリズムの選択といった判断を複数モジュールへ露出させれば、その判断を変更するたびに利用側を広く修正する必要がある。判断を一つの境界の内側へ閉じ込めれば、変更時に再検討する範囲を狭められる。ここで管理しているのはコンポーネントの個数ではなく、変更理由がどの範囲まで伝播するかである。
この構造は、依存グラフ候補が指数的に存在するという事実への直接の応答になる。ソフトウェア工学は、依存の方向、公開境界、変更理由を制約し、実際に成立するグラフを扱いやすい形へ設計する方法を発展させてきた。
4.4 本質的複雑性が残ることと、構造設計が漸近的性質を変えないことは同じではない
Brooks は、ソフトウェア開発の困難を、問題そのものに由来する本質的な困難と、表現手段や開発道具に由来する偶発的な困難に分けた[6]。要求の複雑さ、他システムとの適合、変更可能性といった性質は、より優れたプログラミング言語や開発環境を導入しただけでは消えない。ここからは、単一の技術によってソフトウェア開発全体が桁違いに単純になるという主張には慎重であるべきだと読める。
ただし、「本質的複雑性が残る」という命題と、「モジュール化や構造設計は定数倍しか改善しない」という命題は一致しない。ある問題について避けられない判断が残っていても、その判断がシステム全体へ伝播する構造と、一部へ閉じ込められる構造では、変更時に確認すべき範囲が異なる。本質的な判断を消せなくても、その影響の広がり方は設計できる。
例えば、外部 API の仕様変更へ対応するという仕事自体は消せないとしても、API 呼び出しが 100 個のモジュールへ直接埋め込まれている場合と、一つのアダプターに集約されている場合では、変更箇所と回帰確認範囲が異なる。必要な変更理由は同じでも、依存構造によって作業量の増え方は変化する。
Lehman が扱ったソフトウェア進化（software evolution）も、この点と接続する。運用環境で使われ続けるソフトウェアは、要求や環境の変化に合わせて継続的に変更される[7]。一度完成した構造を永久に維持するのではなく、変更が加わるたびに依存関係も変化し得る。このためソフトウェア工学では、初回実装の正しさだけでなく、変更後にも理解可能性と整合性を維持できる構造が必要になる。
| 論点 | 消せないもの | 設計によって変えられるもの |
|---|---|---|
| 要求への対応 | 要求そのものを理解し、正しい振る舞いを決める必要は残る。 | 要求変更がどのモジュールまで影響するかは境界設計で変えられる。 |
| 外部システムとの接続 | 外部仕様に適合する必要は残る。 | 外部仕様への依存をどこへ集中させるかは設計できる。 |
| 継続的変更 | 運用中の変更要求そのものは避けられない。 | 変更の伝播範囲と回帰確認範囲は依存構造によって変えられる。 |
ソフトウェア工学が複雑性を扱う役割は、問題に必要な判断を残したまま、同時に考慮しなければならない範囲を狭め、変更理由を局所化し、依存方向を制御することにある。
4.5 候補グラフの総数から従来型ソフトウェアの限界は導けない
ここまでを依存グラフの議論へ戻すと、候補総数
\[
2^{\binom{n}{2}}
\]
が非常に大きいことから分かるのは、\(n\) 個の要素から多様な依存構造を作り得るということまでである。その値は、実際に選ばれたグラフの辺数、モジュール境界、依存方向、変更伝播の大きさを表していない。
完全グラフと木構造が同じ候補集合の中に存在すること自体が反例になる。両者は同じ \(n\) 個のコンポーネントを持つが、辺数はそれぞれ \(\Theta(n^2)\) と \(\Theta(n)\) で異なる。さらに情報隠蔽を使えば、内部依存を外部から見えない形に閉じ込め、変更時に考慮する範囲を局所化できる。
このため、「可能な依存構造が指数的に増える」という事実と、「従来型ソフトウェアを人間が扱うためのコストが同じ速度で増える」という命題の間には、設計構造をどう選ぶかという段階が抜けている。ソフトウェア工学はまさにその段階へ介入する。
ここまでで、従来型ソフトウェアが巨大な状態空間や依存候補を単純列挙によって扱っているという前提は成立しないことが分かる。それでも AI エージェントには、従来のアルゴリズムやモジュール化だけでは説明できない違いがある。あらかじめ判断規則を固定する代わりに、利用時の状態を観測し、その時点で行動を選べることである。次に検討すべきなのは、その違いが複雑性を消しているのか、それとも複雑性を処理する時点を変えているのかである。
5. AI エージェントが変えるのは、判断を処理する時点である
5.1 従来型ソフトウェアは、判断規則の多くを開発時に固定する
前章までで、従来型ソフトウェアが巨大な状態空間や依存候補を一件ずつ列挙しているわけではないことを確認した。アルゴリズム、データ構造、モジュール境界、インターフェースによって共通規則を圧縮し、実際に成立する依存関係を制約している。では、その上で AI エージェントには何が新しいのか。差が現れるのは、判断規則をどの時点で確定するかである。
従来型ソフトウェアでは、入力に対してどの処理を行うかという判断の多くを、開発時にコード、設定、ルール、ワークフローとして固定する。例えば、HTTP リクエストのパスが特定の値なら特定の処理へ振り分ける、認証状態が不足していれば処理を拒否する、在庫数が 0 なら注文を受け付けない、といった判断である。
この方式では、実行時の入力が変わっても、判断方法そのものは事前に定義されている。新しい条件を扱う必要が生じ、その条件が既存の規則に含まれていなければ、開発者が仕様を変更し、コードや設定へ反映し、テストして再配布する必要がある。複雑性の多くを開発時に処理する代わりに、実行時には確定済みの規則を再利用できる。
AI エージェントでは、このうち一部の判断を実行時まで確定しない構成を取れる。モデルは現在の要求、環境から得た観測、過去の実行履歴、利用可能なツールを入力として受け取り、その時点で次の行動を選ぶ。開発者がすべての条件分岐を事前に列挙しなくても、観測結果に応じて処理経路を変更できる。
この差を単純化すると、従来型ソフトウェアは
\[
\text{要求}
\rightarrow
\text{設計}
\rightarrow
\text{実装}
\rightarrow
\text{固定された実行規則}
\]
という流れを強く持つ。それに対して AI エージェントは、
\[
\text{要求}
\rightarrow
\text{観測}
\rightarrow
\text{推論}
\rightarrow
\text{行動}
\rightarrow
\text{新しい観測}
\]
という閉ループを実行時に持てる。違いは、入力を受け取った後に、次の処理経路そのものをどこまで動的に決めるかにある。
5.2 ReAct と Reflexion は、判断を実行時へ戻す構造を示している
ReAct は、大規模言語モデルが推論と環境への行動を交互に生成し、行動結果を次の推論へ戻す構造を示した[8]。モデルは最初から最後までの処理列を一度に固定するのではなく、途中で得た観測を使って次の行動を変える。
例えば、ある情報を調査するエージェントが最初に検索を行い、検索結果が不足していれば別の検索語を選び、必要な文書が見つかれば内容を読み、その結果に応じて次の処理を決める。このとき、開発者が「検索結果 A なら処理 B、結果 C なら処理 D」という分岐をすべてコードへ事前登録しているわけではない。どの観測を次の行動へ結び付けるかの一部をモデルが実行時に決める。
Reflexion は、このループへ過去の試行結果を加える。失敗した試行について言語的な振り返りを生成し、それをエピソード記憶として保存し、次の試行時に参照する方式を示した[9]。現在の入力だけでなく、以前に何を試し、どこで失敗したかという履歴も次の判断材料になる。
| 方式 | 実行時に追加される情報 | 判断への影響 |
|---|---|---|
| 固定された処理規則 | 現在の入力だけを既定の分岐へ当てはめる。 | 開発時に定義された経路の中から処理を選ぶ。 |
| ReAct | ツール実行や検索などから得た新しい観測を利用する。 | 観測結果に応じて次の行動をその場で選び直す。 |
| Reflexion | 現在の観測に加えて、過去の試行と失敗についての記録を利用する。 | 以前の失敗を避けるように後続の判断を変更する。 |
この構造によって、事前に予測できなかった環境変化へ対応できる範囲が広がる。直接原因は、実行途中で得た情報を次の判断へ入力できることにある。その背後には、判断規則の一部がソースコードからモデル推論へ移り、実行時まで確定されなくなったという構造変化がある。
5.3 ソフトウェア開発では、どの判断をモデルへ渡すかで性能が変わる
この違いは、ソフトウェア開発エージェントでも確認できる。SWE-agent は、大規模言語モデルへ単にリポジトリーを与えるだけでなく、ファイル検索、内容表示、編集、テスト実行といった操作を行う Agent-Computer Interface を設計し、そのインターフェースが性能に影響することを示した[10]。
モデルがソフトウェアを修正するとき、必要なのはコード生成だけではない。どのファイルを調べるか、どの範囲を読むか、どの変更を試すか、どのテストを実行するかを選ぶ必要がある。これらをすべてモデルへ自由に任せれば探索可能な行動空間は広がるが、不要なファイルを読み続ける、同じ操作を繰り返す、誤った修正方針へ進むといった失敗も生じる。
Agentless は、この自由度を意図的に狭めた対照例になる。複雑な自律的行動計画を繰り返さず、問題箇所の局所化、修正案の生成、候補の検証という限定された工程へ処理を分け、それでも SWE-bench Lite で競争力のある結果を報告した[11]。
SWE-agent と Agentless の比較から、AI エージェントの性能を「モデルがどれだけ自由に判断できるか」だけで説明できないことが分かる。自由度を増やせば、実行時に対応できる状況は広がる。一方で、選択肢が増えるほど、誤った行動を選ぶ余地、不要な探索へ計算資源を使う余地、検証すべき経路も増える。
| 設計 | モデルへ渡す判断 | 生じる性質 |
|---|---|---|
| 自由度の高いエージェント | 探索先、操作手順、修正順序、再試行方針などを広くモデルへ渡す。 | 未知の状況へ適応しやすい一方、探索経路と失敗経路も増える。 |
| 工程を限定したエージェント | 局所化、修正、検証など一部の判断だけをモデルへ渡す。 | 適応範囲は狭くなるが、探索空間と検証対象を限定できる。 |
| 固定ワークフロー | モデルの利用箇所と処理順序を開発時に固定する。 | 未知条件への適応性は下がるが、実行経路を予測しやすい。 |
エージェント設計で決めるべきなのは、モデルに判断させるか否かという二者択一ではない。どの判断を実行時へ移し、どの判断を開発時の固定規則として残すかである。この境界によって、適応可能性と検証可能性の配分が変わる。
5.4 開発過程を扱えることは、コード生成だけでは説明できない
Lingma SWE-GPT は、完成済みのコードだけではなく、ソフトウェア開発過程に含まれる相互作用を学習対象へ取り込み、SWE-bench Verified で 72B モデルが 30.20％、7B モデルが 18.20％の課題を解決したと報告した[12]。ここで評価されているのは、与えられた仕様から一度にコードを書く能力だけではない。既存リポジトリーの内容を調べ、問題箇所を特定し、変更を作り、テスト結果を受けて修正する一連の開発過程である。
この構造では、最初の入力だけで最終的な処理を決め切る必要がない。探索で得たコード、テスト失敗、依存関係などを途中で受け取り、その結果に応じて後続処理を変えられる。実行時まで判断を遅らせることで、開発時には予測できなかった個別リポジトリーの状態へ対応できる。
LangChain が紹介した Cisco の Agentic Engineering のパイロットでは、複数エージェント、共有状態、可観測性を組み合わせ、20 件を超えるデバッグワークフローで、過去の所要時間との比較において 根本原因の特定時間（root-cause identification time）が 93％短縮されたと報告されている[13]。この値は企業ブログによる事例報告であり、無作為化比較試験や独立した再現実験ではないため、一般的な効果量として扱うことはできない。それでも、複数の処理主体が現在状態を共有し、途中結果を観測しながら次の作業を選ぶ構造が、実務上どのように組み込まれているかを示す具体例にはなる。
ここでコード生成だけを見ていると、AI エージェントの差を捉え損ねる。ソフトウェア開発では、正しいコード片を生成できても、変更すべき場所を誤れば成果物にはならない。正しいファイルを変更しても、関連テストを実行しなければ回帰を検出できない。エージェント型の開発では、生成能力と、現在状態を観測して次の操作へ接続する能力が仕事全体の成否を左右する。
5.5 実行時へ判断を移すと、適応性と同時に新しい検証対象が生まれる
従来型ソフトウェアと AI エージェント型の差を、判断時点に沿って整理すると次のようになる。
| 処理 | 従来型ソフトウェア | AI エージェント型 |
|---|---|---|
| 判断規則 | コード、設定、ルールとして開発時に固定する割合が大きい。 | 現在状態をモデルへ与え、実行時に選択する割合を増やせる。 |
| 未知条件への対応 | 既存規則で扱えなければ、仕様変更、実装、テスト、再配布が必要になる。 | 観測可能な情報とモデル能力の範囲では、その場で行動を変更できる。 |
| 実行経路 | 事前に定義された分岐と制御構造を通る。 | 観測結果によってツール選択や処理順序そのものが変わり得る。 |
| 検証対象 | 固定された規則と実装を事前テストし、その結果を多数の実行へ再利用できる。 | 事前にシステム全体を検証するだけでなく、実行時に選ばれた行動や生成物も確認する必要が生じる。 |
実行時判断には、開発時にすべての状況を予測しなくてもよいという利点がある。要求や環境が変化するたびにソースコードへ新しい分岐を追加する代わりに、観測結果をモデルへ与えてその場で対応できる。この性質は、条件が利用時まで確定しない仕事ほど価値を持つ。
その代わり、開発時に固定しなかった判断は、実行時に正しさを確認しなければならない。モデルがどのツールを選ぶか、どのファイルを変更するか、どの生成物を採用するかが事前に一意でなければ、その実行経路について静的なテスト結果だけを再利用することはできない。適応性を得た直接の代償として、実行時に観測・評価・検証すべき対象が増える。
このため、AI エージェントによる変化を「従来型ソフトウェアが抱えていた複雑性をモデルが除去する」と表すと、何が起きているかを過大に単純化する。開発時に人間が引き受けていた判断の一部を、モデル、コンテキスト、ツール、記憶、環境観測から成る実行時ループへ移しているのである。
この移動によって、事前実装の量を減らせる場合がある。しかし、判断そのものが不要になったわけではない。誰かが開発時に決める代わりに、システムが実行時に決める。そのとき必要になる推論、情報取得、結果検証には別の費用が発生する。次章では、この違いを構築費用、実行費用、検証費用に分け、AI エージェントの優位がどの条件で成立するのかを考える。
6. 実行時へ移した複雑性には、推論と検証のコストが付く
6.1 開発時に決めなかった判断は、実行時に処理しなければならない
前章では、AI エージェントの特徴を、判断規則の一部を開発時に固定せず、利用時の観測結果を使って実行時に決められることとして整理した。この構造には、未知の条件へその場で対応できるという利点がある。要求、対象データ、外部サービスの状態、リポジトリーの内容が利用時まで確定しない仕事では、すべての分岐を事前にコードへ書くより、現在状態を読み取って処理を選ぶ方が実装量を減らせる場合がある。
ただし、開発時に決めなかった判断が不要になるわけではない。どの情報を取得するか、どのツールを使うか、どの候補を採用するか、失敗したとき再試行するかといった判断は、実行時に処理される。判断時点を後ろへ移した結果、開発時の実装量を減らせても、その代わりに推論、情報取得、ツール実行、結果確認という処理が一回ごとの利用に加わる。
従来型ソフトウェアでは、同じ入力形式と同じ規則を繰り返し処理するなら、設計と検証にかけた費用を多数の実行へ再利用できる。AI エージェント型では、個別状況へ適応するために、実行ごとにモデル推論や追加の検証が必要になる場合がある。両者の違いは、複雑性の総量だけでなく、費用をいつ支払うかという配分にも現れる。
6.2 構築費用と実行費用を分けると、優位条件を式で表せる
この違いを単純なコストモデルで表す。従来型ソフトウェアの総費用を、
\[
\mathrm{Cost}_S(n,q)=B_S(n)+V_S(n)+qR_S(n)
\]
とする。\(n\) は問題やシステムの規模、\(q\) は同じ仕組みを利用する回数である。\(B_S(n)\) は設計と実装に必要な構築費用、\(V_S(n)\) は事前に行うテストやレビューなどの検証費用、\(R_S(n)\) は一回の実行費用を表す。
この式では、構築費用と事前検証費用は一度だけ発生し、その後の \(q\) 回の実行では \(R_S(n)\) だけを繰り返し支払う。例えば、一度十分にテストした税率計算、文字コード変換、画像形式変換のような固定規則を数百万回実行する場合、最初の設計と検証の費用を大量の実行へ償却できる。
AI エージェント型については、比較のため、
\[
\mathrm{Cost}_A(n,q)=B_A(n)+q\left(R_A(n)+V_A(n)\right)
\]
と置く。\(B_A(n)\) はエージェント、プロンプト、ツール接続、権限、実行環境などを用意する初期費用、\(R_A(n)\) は一回の実行で必要になる推論、検索、ツール利用などの費用、\(V_A(n)\) はその実行で選択・生成された結果を確認する費用である。
このモデルは、従来型ソフトウェアには実行時検証がなく、AI エージェントには事前検証がないという意味ではない。実際には双方に事前検証と実行時検証があり得る。ここでは、判断を実行時へ移すほど、一回ごとの推論と結果確認へ費用が移りやすいという差を取り出すために単純化している。
| 費用 | 従来型ソフトウェア | AI エージェント型 |
|---|---|---|
| 初期構築 | 判断規則をコード、設定、データ構造として具体化する費用が発生する。 | すべての判断規則を事前実装しなくてもよい場合があるが、モデル、ツール、権限、コンテキスト構築などの基盤は必要になる。 |
| 事前検証 | 固定された規則と実装をテストし、その結果を多数の実行へ再利用しやすい。 | 利用可能なツール、権限、基本動作は事前検証できるが、実行時に生成される行動列をすべて事前確定することはできない。 |
| 実行 | 確定済みの処理を再利用するため、一回当たりの追加判断を小さくできる。 | 個別状況に応じた推論、検索、ツール利用が一回ごとに発生し得る。 |
| 実行時検証 | 入力検査や業務ルール確認は必要だが、固定された処理経路について事前テストを再利用できる。 | その場で選択された操作や生成物について、追加のテスト、評価、承認が必要になる場合がある。 |
6.3 実行回数が増えると、事前投資を再利用できる方式が有利になる場合がある
二つの方式のどちらが有利かは、初期費用だけでは決まらない。差を取ると、AI エージェント型が従来型より総費用を小さくする条件は、
\[
B_A+q(R_A+V_A) < B_S+V_S+qR_S
\]
である。整理すると、
\[
B_S+V_S-B_A > q(R_A+V_A-R_S)
\]
となる。左辺は、従来型ソフトウェアを事前に構築・検証するために追加で支払う初期費用に対応する。右辺は、AI エージェント型が一回の利用ごとに追加で負担する推論・検証費用を \(q\) 回分積み上げた量に対応する。
例えば、要求が毎回異なり、同じ処理をほとんど再利用できない仕事では、従来型ソフトウェアへ新しい分岐を追加し続ける初期費用が大きくなる。AI エージェントが自然言語の要求を解釈し、既存ツールを組み合わせて処理できるなら、\(B_A\) を相対的に小さくできる可能性がある。この条件では、一回ごとの推論費用を払っても総費用で有利になり得る。
反対に、同じ規則を大量に反復する仕事では、最初にコード化して検証した方が有利になりやすい。例えば固定された形式変換を 1 回だけ行うなら、専用プログラムを設計するより既存の AI エージェントへ任せる方が安い場合がある。しかし同じ変換を 1 億回実行するなら、毎回モデル推論と結果検証を行う方式は、一度確定したアルゴリズムを繰り返す方式に比べて実行費用が積み上がる。
ここで効いているのは、同じ判断を何回再利用できるかである。事前に固定した判断は再利用回数が増えるほど一回当たりの初期費用が小さくなる。実行時に判断する方式は、状況適応性を得る代わりに、判断費用の一部を各実行へ残す。
6.4 検証費用は、生成後の結果をどれだけ安く判定できるかで変わる
AI エージェント型の費用を考えるとき、推論費用だけを見ると比較を誤る。モデルが結果を生成できても、その結果が正しいかを確認できなければ業務へ採用できないからである。特にソフトウェア開発では、もっともらしいパッチを生成することと、そのパッチが課題を解決し、既存機能を壊していないことは別の条件になる。
SWE-bench は、実在する GitHub issue と対応するリポジトリーを使い、モデルが作成したパッチをテストによって評価するベンチマークとして導入された[14]。モデルがコードを生成しただけでは成功にならず、課題に対応するテストを通過して初めて解決と判定される。この評価方式自体が、生成と検証を別の工程として扱っている。
OpenAI は 2024 年に、問題記述とテストの妥当性を人間のソフトウェア開発者が確認した 500 問からなる SWE-bench Verified を公開した[15]。元の問題には、課題記述だけでは解けないものや、テストが正しい修正を十分に判定できない課題が含まれていたため、人間による確認で評価集合を絞り込んだ。
ところが 2026 年には、OpenAI 自身が SWE-bench Verified を最先端のコーディング能力の評価へ使うことを推奨しないと公表した[16]。理由には、テストが意図した振る舞いを十分に判定しない問題や、ベンチマーク内容がモデルの学習データへ混入している可能性が含まれる。モデルが高いスコアを出したとしても、評価器側が正しさを十分に識別できなければ、その数値をそのまま能力として読めない。
この経緯は、AI エージェントの性能評価に限った特殊事情ではない。生成結果の正しさを安価かつ自動的に判定できる仕事では、\(V_A\) を小さくできる。コンパイラー、型検査、単体テスト、数値比較のように明確な検証器がある場合が該当する。一方、要求が曖昧で、正解が一意でなく、人間による意味判断が必要な仕事では、生成より検証の方が高価になることもある。
| 検証条件 | AI エージェント型への影響 | 具体例 |
|---|---|---|
| 正解を機械的に判定できる | 実行時検証を自動化しやすく、\(V_A\) を抑えられる。 | コンパイル可否、単体テスト、数値制約、形式検証などが該当する。 |
| 複数の正解があり評価基準を定義できる | 評価器を設計できるが、評価基準そのものの妥当性を確認する必要がある。 | コード品質、要約品質、検索結果の関連性などが該当する。 |
| 正しさが人間の意味判断に依存する | 人間レビューが残り、生成を高速化しても検証費用が主要な制約になり得る。 | 曖昧な要求に対する仕様判断、業務上の妥当性、責任を伴う採用判断などが該当する。 |
AI エージェントが仕事を安くするには、生成費用だけでなく、結果を採用可能な状態まで確認する費用も含めて比較する必要がある。生成量が増えれば、検証対象も増える。検証器が弱いまま生成能力だけを高めると、処理できる候補数は増えても、正しい候補を確定する工程がボトルネックとして残る。
6.5 モデルの外側にある仕組みが、実行時判断を仕事として成立させる
既稿「AI に仕事を任せるには、モデルの外側を設計する」では、モデルへ指示を与えるだけでは仕事の完了条件を満たせず、観測、ツール、外部状態、検証、権限、人間介入を含む閉ループが必要になると整理した[17]。今回のコストモデルで見ると、これらは \(R_A\) と \(V_A\) を構成する実体である。
例えばコード修正エージェントなら、モデルがパッチを生成するだけでは足りない。現在のリポジトリー状態を取得し、変更可能な範囲を確認し、対象ファイルを編集し、テストを実行し、その結果が失敗なら原因を読み取り、必要なら修正を戻す。モデルの推論はこのループの一部であり、実際の仕事を成立させるにはモデル外部の状態と操作が必要になる。
権限設計も費用と検証へ直接影響する。エージェントへ広い操作権限を与えれば、実行時に対応できる範囲は広がる。一方、誤った判断が与える影響も大きくなるため、承認、監査、ロールバックといった追加制御が必要になる。権限を狭くすれば失敗時の影響範囲は小さくできるが、処理できないケースでは人間への返却が増える。
このため、AI エージェントの実行時コストは単純なモデル API の料金だけでは表せない。少なくとも、情報取得、コンテキスト構築、モデル推論、ツール実行、検証、再試行、人間介入まで含めて考える必要がある。判断を実行時へ移すほど、その場で仕事を完了させるための周辺機構が増える。
6.6 AI エージェントの優位は、問題規模ではなく費用構造の条件で決まる
ここまでのモデルから、AI エージェントが有利になりやすい条件を具体化できる。
| 条件 | AI エージェントが有利になりやすい理由 | 従来型ソフトウェアが有利になりやすい反対条件 |
|---|---|---|
| 要求変化の頻度 | 要求が頻繁に変われば、実行時解釈によって再実装を減らせる可能性がある。 | 要求が長期間固定されるなら、一度実装した規則を再利用しやすい。 |
| 利用回数 | 一回限り、または少数回の利用なら、専用実装の初期費用を避ける効果が大きい。 | 大量反復なら、初期費用を多数の実行へ償却できる。 |
| 実行時情報の必要性 | 利用時まで条件が確定しない仕事では、その場で観測して判断できる価値が大きい。 | 必要情報と処理規則を事前に確定できるなら、動的推論を毎回行う必要がない。 |
| 検証費用 | 結果を自動テストなどで安価に確認できれば、実行時判断を増やしやすい。 | 人間による高価なレビューが毎回必要なら、生成量を増やしても総費用が下がらない場合がある。 |
| 失敗時の影響 | 失敗を局所化し、容易に再試行・ロールバックできる仕事では自律判断を許容しやすい。 | 一度の誤判断が大きな損失につながる仕事では、事前検証や人間承認の比重が増える。 |
この比較では、「システムが大きくなれば AI エージェントが有利になる」という単一の境界は出てこない。同じ規模の問題でも、要求が固定され大量に反復される処理と、毎回条件が変わり少数回しか実行されない処理では、適した方式が異なる。
AI エージェントが実用的な優位を持つ場面はある。しかし、その優位は状態空間が指数的に増えるという事実から自動的に決まるのではない。開発時に支払う構築・検証費用と、実行時に支払う推論・検証費用をどのように配分するかによって決まる。
そして実行が一回で終わらず、変更を繰り返しながら長期間続く場合には、もう一つの費用が現れる。ある時点の出力が次の時点の状態になるため、一回ごとの誤りを検出できなければ、その誤りが後続処理へ引き継がれる。次章では、一回の修正に成功する能力と、変更を積み重ねながらシステムの整合性を保つ能力を分けて考える。
7. 一回の修正に成功することと、ソフトウェアを進化させ続けることは違う
7.1 長期開発では、前回の出力が次回の前提になる
一件の課題を解決する能力と、変更を積み重ねながら同じソフトウェアを維持し続ける能力は分けて考える必要がある。単発の修正では、ある時点のリポジトリーを入力として受け取り、要求を満たす変更を作り、その結果をテストすれば評価できる。一方、継続的な開発では、その変更後のリポジトリーが次の要求を処理するときの入力になる。
例えば、時点 \(t\) のソフトウェア状態を \(S_t\)、その時点で行う変更を \(\Delta_t\) とすると、次の状態は単純化して
\[
S_{t+1}=F(S_t,\Delta_t)
\]
と表せる。\(F\) は現在状態へ変更を適用して次の状態を作る処理である。この式で注目すべきなのは、次の変更が初期状態 \(S_0\) ではなく、過去の変更をすべて反映した \(S_t\) に対して行われることである。
時点 \(t\) の変更に未検出の誤りが含まれていれば、その誤りも \(S_{t+1}\) の一部になる。次のエージェントは、その状態を正しい前提としてファイルを読み、依存関係を推定し、さらに変更を加える可能性がある。局所的な一回の誤りが、その場の失敗だけで終わらず、後続判断の入力条件そのものを変える。
このため、長期開発で扱うべき失敗は「あるパッチが間違っていた」という一点だけではない。誤ったパッチが受理された結果、次の修正が誤った前提から始まり、その修正によってさらに別の部分が変更されるという二段階以上の伝播が起こる。ソフトウェアを継続的に変更する場合、履歴そのものが現在状態を構成する一部になる。
| 評価単位 | 入力状態 | 失敗した場合の影響 |
|---|---|---|
| 単発修正 | 評価開始時に与えられた固定リポジトリーを入力とする。 | その課題の失敗として評価を終了できる。 |
| 継続的変更 | 過去の変更を累積した現在のリポジトリーを入力とする。 | 未検出の誤りが次の変更の前提となり、後続判断へ伝播し得る。 |
単発ベンチマークで高い成功率を得ても、この履歴依存性まで保証したことにはならない。長期能力を評価するには、個々の変更を生成する能力と、変更後の状態を正しく確定して次の処理へ安全に引き渡す能力を見る必要がある。
7.2 一回当たりの成功率が高くても、長い処理列の成功率は下がる
この違いを単純な確率モデルで確認する。各判断について、それ以前のすべての判断が正しかったという条件のもとでも、少なくとも確率 \(p\) で失敗するとする。言い換えると、各段階の条件付き成功率は最大でも \(1-p\) である。
\(H\) 回の判断をすべて正しく終える確率は、確率の連鎖則を使って
\[
P(\text{success})
=
\prod_{t=1}^{H}
P(\text{step }t\text{ succeeds}\mid\text{steps }1,\ldots,t-1\text{ succeeded})
\]
と書ける。各項が最大 \(1-p\) なので、
\[
P(\text{success})\le(1-p)^H
\]
となる。この上界には、各判断が互いに独立であるという仮定は必要ない。それ以前の判断がすべて成功している場合でも、各段階に一定以上の失敗確率が残るという条件だけを置いている。
例えば \(p=0.01\)、つまり各段階の条件付き成功率が最大 99％だとする。10 回すべて成功する確率の上限は約 90.4％、100 回なら約 36.6％、1,000 回なら約 \(4.3\times10^{-5}\) になる。
| 判断回数 \(H\) | 各段階の成功率 | 全段階成功確率の上限 |
|---|---|---|
| 10 | 99％以下とする。 | 約 90.4％になる。 |
| 100 | 99％以下とする。 | 約 36.6％になる。 |
| 1,000 | 99％以下とする。 | 約 \(4.3\times10^{-5}\) になる。 |
実際のソフトウェア開発をこの式だけで表すことはできない。失敗確率は作業内容によって異なり、複数の判断が相関する場合もある。さらに、テストによって途中の誤りを検出し、その変更を修正または破棄できる。上の式が示すのは実測成功率ではなく、「一回の成功率が十分高いから、同じ方式を長く繰り返しても同じ信頼性を維持できる」という推論が成立しないことである。
7.3 長期成功率を維持するには、失敗率そのものを下げるか途中で状態を確定する必要がある
長期タスク全体の成功率を \(1-\delta\) 以上に保ちたいとする。途中で一度でも誤れば全体失敗になる単純なモデルでは、
\[
(1-p)^H\ge1-\delta
\]
が必要になる。これを \(p\) について解くと、
\[
p\le1-(1-\delta)^{1/H}
\]
となる。\(H\) が大きく、\(\delta\) が小さい範囲では、おおよそ
\[
p\lesssim\frac{\delta}{H}
\]
と見なせる。処理列が長くなるほど、各段階に許容される失敗率を反比例する程度まで小さくしなければ、全体の成功率を同じ水準へ保てない。
例えば、1,000 段階からなる処理全体を 99％以上の確率で成功させたいなら、単純モデルでは一段階当たりの失敗率を約 \(10^{-5}\) の規模まで抑える必要がある。現在のコード生成エージェントに限らず、多数の確率的判断を無検証で直列接続する方式にとって非常に厳しい条件である。
現実のソフトウェア工学は、この条件を「すべての処理をほぼ絶対に失敗させない」ことだけで満たそうとはしない。途中で状態を検証し、誤りを検出した時点で修正し、必要なら以前の確定状態へ戻す。長い処理列を一つの成功確率へ賭ける代わりに、検証可能な単位へ分割する。
例えば 1,000 回の変更を一度も確認せず連続適用する場合と、各変更後にコンパイル、単体テスト、回帰テストを行い、失敗した変更を次の状態へ持ち越さない場合では、同じ一回当たりの生成能力でも長期結果が異なる。検証は単に最終品質を確認する工程ではなく、誤りが将来状態へ伝播する経路を途中で切断する制御として働く。
7.4 長期ベンチマークでは、単発課題より性能が低下している
近年のソフトウェア開発エージェント向けベンチマークでも、単発課題と長期課題の差が測定され始めている。SWE-Bench Pro は、専門家が数時間から数日を要する課題を含む 1,865 問を構成し、統一した共通実行基盤で評価した当初の結果では、最良の構成でも Pass@1 が 25％未満だった[18]。
ここで難しくなる理由は、単純にコード量が増えるからだけではない。長い課題では、問題箇所の特定、複数ファイル間の依存関係の理解、変更方針の維持、途中結果の確認を複数段階にわたって行う必要がある。初期段階で誤った仮説を採用すれば、その仮説に沿ったファイル探索や修正へ後続処理が進み、後になってから広い範囲をやり直すことになる。
SWE-EVO は、単発課題の修正からソフトウェア進化へ評価対象を広げた。7 個の成熟した Python プロジェクトから 48 件の進化タスクを構成し、一つのタスクは平均 21 ファイルにまたがる。GPT-5 と OpenHands の組み合わせでは、SWE-bench Verified における解決率が 65％だったのに対し、SWE-EVO では 21％だったと報告している[19]。
この比較ではベンチマークの課題構成自体が異なるため、「タスクが長くなったことだけが 65％から 21％への低下を引き起こした」と因果的に断定することはできない。それでも、単発課題の解決で得られた性能を、複数ファイルにまたがる長期的な進化能力へそのまま外挿できないことは示されている。
7.5 継続的変更では、過去の自分が作った状態を次の自分が引き受ける
EvoClaw は、この履歴依存性そのものを評価対象にしている。孤立した一回の変更ではなく、同じソフトウェアへ変更を連続して適用するソフトウェア進化を評価し、12 の最先端モデルと 4 種類のエージェントフレームワークを比較した[20]。
報告された結果では、単発課題で 80％を超える総合性能スコアを示す構成があった一方、継続設定では最大でも 38％だった[20]。EvoClaw は長期的なシステム整合性とエラー蓄積を評価対象に置いており、「一件の変更を正しく作れるか」と「以前の変更を含む現在状態を壊さず、次の変更を積み重ねられるか」を分離している。
継続設定では、エージェント自身が以前に生成した変更も次の入力へ含まれる。そこで残った不要な依存関係、設計上の妥協、未検出の回帰、誤ったコメントやテストは、次回のエージェントにとって既存コードの一部になる。エージェントはそれを正しい設計意図と解釈して、その上へ実装を積み重ねる可能性がある。
この構造では、誤りの影響が時間方向へ増幅される。一回目の誤りが直接二回目の誤りを生むとは限らないが、一回目の変更によって探索対象や依存構造が変化し、その状態をもとに二回目の判断が行われる。局所的な生成精度だけでは、現在状態そのものが次第に正しい設計から離れていく過程を評価できない。
| 評価 | 確認できる能力 | 確認しにくい能力 |
|---|---|---|
| 単発課題 | 固定された初期状態から一件の要求を解決する能力を確認できる。 | 過去の自己生成変更を引き継いだ状態で整合性を維持する能力は確認しにくい。 |
| 長期課題 | 複数段階の探索、修正、検証を一つの課題内で維持する能力を確認できる。 | 複数回の独立した要求を長期間積み重ねる履歴管理までは必ずしも含まれない。 |
| 継続的進化 | 過去の変更を含む現在状態へ新しい変更を追加し、整合性を維持する能力を確認できる。 | 実運用で数年続く変更履歴や組織上の判断まで直接評価するわけではない。 |
7.6 「生成済み」と「後続工程が依存できる状態」を分けなければならない
既稿「AI による大規模開発では、未確定な状態を一件ずつ閉じる」では、AI がコードを生成した状態と、その成果を後続工程が前提として利用できる確定状態を区別した[21]。長期エージェントでは、この区別が単なる進捗管理ではなく、誤差伝播を制御するための条件になる。
例えば、エージェントが機能 A を実装し、その直後に機能 B の実装へ進むとする。機能 A がまだテストされていなければ、機能 B は未確定な実装を前提に作られる。後から機能 A の設計ミスが判明した場合、修正対象は A だけでは済まず、A の挙動を前提に書かれた B にまで広がる可能性がある。
反対に、A の実装後にコンパイル、対象テスト、回帰テスト、必要なレビューを通し、「後続変更が依存してよい状態」として確定してから B へ進めば、A に含まれる誤りが B の設計前提へ混入する確率を下げられる。失敗を完全にゼロにはできなくても、誤りが何段階も先まで伝播してから発見される範囲を狭められる。
長期開発で必要なのは、履歴を大量に保存することだけではない。どの変更が検証済みで、どの前提が現在も成立し、どの失敗からどの状態へ戻れるかを再構成できなければならない。状態保存があっても、誤った状態を正しい履歴として保存するだけなら長期信頼性は高まらない。
7.7 長期能力を支えるのは、生成能力より状態遷移を制御する仕組みである
単発修正と継続的進化の差を整理すると、長期化によって必要になる機構が見える。
| 機構 | 直接の役割 | 長期的な役割 |
|---|---|---|
| 状態保存 | 現在のコード、設定、依存関係、実行結果を保持する。 | 次の判断がどの状態から開始されたかを再現可能にする。 |
| 回帰検証 | 新しい変更が既存機能を壊していないか確認する。 | 過去に確定した性質が変更によって失われることを検出する。 |
| 不変条件 | 変更後も必ず成立すべき条件を定義する。 | エージェントの判断内容が変化しても、越えてはならない境界を固定する。 |
| ロールバック | 失敗した変更を以前の状態へ戻す。 | 誤った状態を後続変更の前提として固定することを防ぐ。 |
| 確定状態の管理 | 検証を通過した変更と未検証の変更を区別する。 | 後続処理が依存してよい前提を明示する。 |
これらの機構は、モデルの次トークン予測精度を高めるものではない。エージェントが誤る可能性を前提に、その誤りを検出し、将来状態へ持ち越さず、必要なら以前の状態へ戻すための制御である。個々の判断精度を高めるだけでは達成しにくい長期信頼性を、状態遷移の管理によって補う。
AI エージェントが 1,000 回連続して操作できることと、その 1,000 回を経た後にもソフトウェアが要求を満たし続けることは異なる。前者は処理を継続できる能力であり、後者は履歴を通じて整合性を維持する能力である。
この差は、AI エージェントによってソフトウェア工学が不要になるという見方とは逆方向を向く。実行時判断を増やし、変更を自律的に積み重ねるほど、状態管理、回帰検証、不変条件、ロールバック、確定状態の管理が必要になる。コード生成を人間からモデルへ移しても、変更を安全な状態遷移として成立させる仕事までは消えない。
ここまでで、状態空間の大きさ、必要情報量、依存構造、実行時判断の費用、長期的な誤差蓄積をそれぞれ分けてきた。この枠組みを使えば、「AI エージェントは複雑性のスケーリング則から必然的に従来型ソフトウェアより優位になる」という主張を、単なる将来予測ではなく数理モデルとして検証できる。
8. 「AI エージェントは必然的に良くスケールする」という数理モデルは成立しない
ここまで、状態空間の大きさ、振る舞いを指定する情報量、依存構造、実行時判断の費用、長期的な誤差蓄積を別々の量として整理してきた。この枠組みを使うと、2026 年に公開された Zhenfeng Cao の論文「The End of Software Engineering: How AI Agents Are Fundamentally Restructuring the Software Paradigm」が提示する「First-Principles Necessity」を数理的に検証できる。
同論文は、従来型ソフトウェアでは人間が判断規則を静的なコードへ符号化するのに対し、AI エージェント型では LLM が主要な推論主体となり、必要なコードを実行時に生成・破棄できると整理する。そのうえで、システム規模の増大に伴って問題空間が指数的に増える一方、人間の認知能力はほぼ固定され、モデル能力は計算資源の増加とともに向上するため、AI エージェントは従来方式より「必然的に良くスケールする」と主張している[22]。
この結論を成立させるには、少なくとも二つの関係が必要になる。第一に、システム規模 \(n\) が増えると、従来型ソフトウェアが必要とする処理量 \(T_S(n)\) が急速に増えること。第二に、AI エージェント側の処理量 \(T_A(n)\) は、それより遅い速度で増えること。この二つが示されて初めて、
\[
T_A(n)=o(T_S(n))
\]
という漸近的な優位を主張できる。ところが、論文中の数式と前提を追うと、この関係は導かれていない。
8.1 依存グラフの式が同じ漸近量になっていない
最初の問題は、論文内部の数式そのものにある。論文はコンポーネント数 \(n\) に対して、相互作用パターン（interaction pattern）の数を
\[
P(n)\in\Theta(2^n)
\]
と置く一方、各コンポーネント対が依存するか否かを選べるため、依存グラフ（dependency graph）の候補数は
\[
2^{\binom{n}{2}}
\]
になると説明している[22]。
しかし、
\[
\binom{n}{2}=\frac{n(n-1)}{2}
\]
なので、
\[
2^{\binom{n}{2}}
=
2^{n(n-1)/2}
=
2^{\Theta(n^2)}
\]
である。これは \(\Theta(2^n)\) とは異なる。両者の比を取ると、
\[
\frac{2^{\binom{n}{2}}}{2^n}
=
2^{(n^2-3n)/2}
\]
となり、\(n\) が大きくなるほど無限に増える。\(2^n\) と \(2^{\binom{n}{2}}\) はどちらも指数関数的に増えるが、同じ漸近クラスではない。
| 式 | 増え方 | 意味 |
|---|---|---|
| \(2^n\) | \(2^{\Theta(n)}\) として増える。 | \(n\) 個の二値変数が作る状態数などに対応する。 |
| \(2^{\binom{n}{2}}\) | \(2^{\Theta(n^2)}\) として増える。 | \(n\) 頂点間の各辺について存在・不存在を選んだ無向グラフ候補数に対応する。 |
この不整合だけでも、「\(P(n)\in\Theta(2^n)\) だから」という形で依存グラフの候補数を根拠にすることはできない。ただし、論文の中心命題を反証するうえでは、この式を訂正するだけでは足りない。より大きな問題は、\(2^{\binom{n}{2}}\) という値が何を数えているかにある。
8.2 候補空間の大きさは、一つのシステムを扱う計算量ではない
\(2^{\binom{n}{2}}\) が表しているのは、\(n\) 個のコンポーネントから構成可能な無向グラフの総数である。これは「設計候補が何通り存在するか」を数えているのであって、「一つの設計済みシステムを理解・変更するために何回の計算が必要か」を表していない。
例えば \(n\) 個のコンポーネントを持つ二つのシステムを考える。一方が完全グラフなら、辺数は
\[
\binom{n}{2}=\Theta(n^2)
\]
である。もう一方が木構造なら、辺数は
\[
n-1=\Theta(n)
\]
である。両者は同じ \(n\) 個のコンポーネントを持ち、同じ巨大な候補集合の一要素である。しかし、実際に存在する依存関係の数と変更伝播の構造は異なる。
第 4 章で見たモジュール化や情報隠蔽は、この違いを設計によって作る。公開インターフェースを限定し、内部実装への直接依存を禁止すれば、理論上は可能だった依存関係を実システムから排除できる。候補グラフ総数が変わらなくても、実際に管理するグラフの構造は変えられる。
したがって、
\[
\text{number of possible graphs}
\]
から、
\[
\text{cost of maintaining one chosen graph}
\]
を直接導くことはできない。この間には、どの依存関係を許し、どの境界で切り、どの変更理由を局所化するかという設計段階が存在する。
8.3 状態空間が指数的でも、静的ソフトウェアの計算量は指数的とは限らない
候補空間と実際の計算量を混同している点は、入力状態についても同じである。第 1 章で扱った parity 関数が直接の反例になる。
\(n\) bit の入力は
\[
|\mathcal{X}_n|=2^n
\]
通り存在する。しかし parity は、各 bit の排他的論理和を順番に計算すればよいため、静的なプログラムで
\[
T(n)=\Theta(n)
\]
時間に計算できる。
ここで状態空間は指数的に増えているが、一回の計算量は線形である。したがって、
\[
|\mathcal{X}_n|=2^n
\]
という事実から、
\[
T_S(n)=\Theta(2^n)
\]
を導くことはできない。
この差が生じる理由は、静的ソフトウェアが全状態を個別に列挙しているわけではないからである。複数の入力に共通する規則を一つのアルゴリズムとして記述し、その規則を実行時の入力へ適用する。状態候補の総数と、状態を扱うアルゴリズムの長さや計算量は別の量である。
論文は、人間の開発者が問題空間を「mentally traverse」し、その判断を静的コードへ符号化しなければならないというモデルを置いている[22]。しかし、アルゴリズム設計やモジュール設計が行っているのは全状態の精神的走査ではない。多数の状態に共通する構造を抽出し、それを規則として固定することである。
このため、「状態空間が指数的に増える」「人間の認知能力は固定である」という二つの事実だけでは、静的ソフトウェアの開発複雑性が指数的に増えるという結論にはつながらない。
8.4 圧縮できない問題では AI も情報量の下限を回避できない
では、静的ソフトウェアが規則性を利用できない問題なら、AI エージェントが優位になるのだろうか。第 3 章の計数による議論は、ここにも制約を与える。
\(n\) bit の入力から 0 または 1 を返す Boolean 関数は、
\[
2^{2^n}
\]
個存在する。固定された推論器へ \(b\) bit のタスク固有情報を与え、このすべてを区別するには、
\[
2^b\ge2^{2^n}
\]
が必要であり、
\[
b\ge2^n
\]
となる。規則性を仮定できない最悪の場合には、少なくとも \(2^n\) bit のタスク固有情報をどこかに保持しなければならない。
AI エージェントを使っても、この情報量の下限は自動的には消えない。必要な情報は、モデル重み、プロンプト、コンテキスト、長期記憶、検索結果、ツールの応答、追加学習データなどのいずれかから供給される必要がある。
この結果から、二つの場合に分けられる。
| 問題の性質 | 従来型ソフトウェア | AI エージェント |
|---|---|---|
| 圧縮可能な規則性がある | 規則をアルゴリズム、データ構造、モジュールとして利用できる。 | モデル重みやツールを通じて同じ規則性を利用できる。 |
| 圧縮可能な規則性がない | ケースを区別するための情報をコードやデータとして保持する必要がある。 | ケースを区別するための情報をモデル、コンテキスト、記憶、外部情報として供給する必要がある。 |
規則性がある場合には、静的ソフトウェアも指数的なケース列挙を回避できる。規則性がない場合には、AI も必要な情報量を回避できない。この二分だけでも、「AI エージェントだけが指数的複雑性から逃れられる」という一般命題は成立しない。
8.5 モデル能力が計算資源とともに向上することと、問題サイズに対して良くスケールすることは別である
論文では、人間の認知能力 \(C_H\) は生物学的にほぼ固定である一方、モデル能力 \(C_M\) はモデル規模、学習時の計算資源、推論時の計算資源とともに向上することが、AI エージェントの優位を支える根拠になっている[22]。
モデル規模や学習・推論に投入する計算資源をまとめた資源条件を \(r\) と書けば、この主張はモデル能力を
\[
C_M=C_M(r)
\]
として捉えることに対応する。より多くの資源を投入したモデルが高い能力を持ち得るという主張と、問題サイズを増やしたときの計算量の増え方は、異なる変数についての主張である。
問題サイズ \(n\) に対して方式を比較するなら、AI エージェント側の処理量を資源条件も含めて \(T_A(n;r)\)、従来型ソフトウェア側を \(T_S(n)\) として考える必要がある。固定した資源条件 \(r=r_0\) のもとで漸近優位を主張するには、
\[
T_A(n;r_0)=o(T_S(n))
\]
を別途示さなければならない。反対に、問題サイズ \(n\) の増加に合わせてモデル側の資源も増やすなら、必要な資源条件 \(r(n)\) と、その資源を用意する計算費用までモデルへ含める必要がある。
| 変数 | 何を変化させているか | 答えられる問い |
|---|---|---|
| 資源条件 \(r\) | モデル規模、学習時の計算資源、推論時の計算資源などを変化させる。 | 投入資源を増やしたときにモデル能力がどのように変わるかを議論できる。 |
| 問題サイズ \(n\) | 入力、状態、コンポーネント数など対象問題の規模を変化させる。 | 同じ資源条件のもとで、方式の処理量が問題規模に対してどう増えるかを議論できる。 |
モデル能力を計算資源によって高められるという主張と、AI エージェント方式が問題サイズに対して漸近的に優れるという主張は別である。前者から後者を導くには、問題サイズと必要資源量の関係を含む追加のモデルが必要になる。
8.6 人間の認知能力を定数と置いても、静的ソフトウェアの複雑性は決まらない
論文では、人間の認知能力がほぼ固定であることも重要な前提として置かれている。しかし、人間一人が同時に保持できる情報量が有限であることから、ソフトウェアシステム全体の管理可能規模が直接決まるわけではない。
ソフトウェア工学は、人間一人がシステム全体を常時記憶しなくても開発できるように、外部表現と分業を利用する。仕様書、ソースコード、型、テスト、インターフェース、バージョン管理、課題管理、レビュー記録は、判断や状態を人間の作業記憶の外へ固定する仕組みである。
モジュール境界を使えば、一人の開発者がシステム全体の内部実装を理解しなくても、限定された契約だけを前提に一部分を変更できる。人間の認知容量が一定でも、一度に必要な認知対象を局所化すれば、扱えるシステム全体の規模はその容量だけでは決まらない。
したがって、
\[
C_H=O(1)
\]
という仮定を置いたとしても、そこから従来型ソフトウェアの開発が \(n\) の増大に伴って実行不能になるとは自動的に導かれない。必要なのは、人間の内部認知だけではなく、外部記憶、表現、分業、モジュール化を含む開発システム全体のモデルである。
8.7 反証は一つの反例だけでも成立する
論文の主張が「AI エージェントは複雑性のスケーリング則から必然的に従来方式より良くスケールする」という普遍命題であるなら、その反証には、同じ前提のもとで AI エージェントが漸近的に優位にならない問題族を一つ構成すれば足りる。
例えば parity 関数族を考える。静的ソフトウェアでは、
\[
T_S(n)=\Theta(n)
\]
で計算できる。一方、正確な parity を計算する方式は、最悪の場合すべての入力 bit に依存する。ある一つの bit を一度も参照しない方式があれば、その bit だけを反転した二つの入力を区別できず、正しい parity を必ず返すことができない。
このため、AI エージェント型であっても正確に計算するなら、入力情報を読むために少なくとも
\[
T_A(n)=\Omega(n)
\]
が必要になる。静的ソフトウェアが \(\Theta(n)\)、AI エージェント型が \(\Omega(n)\) なので、少なくともこの問題族について、
\[
T_A(n)=o(T_S(n))
\]
とはならない。
この反例だけで、「すべての問題について AI エージェントが必然的に漸近優位になる」という普遍命題は成立しない。第 3 章の情報量下限も合わせれば、圧縮不能な問題についても AI だけが指数的情報量を回避できるわけではないことが分かる。
8.8 反証されるのは AI エージェントの有用性ではなく、普遍的な必然性である
ここまでの反証によって、AI エージェントが実用上有用であることまで否定されるわけではない。第 5 章で見たように、要求や環境が実行時まで確定しない仕事では、判断を開発時に固定せず、その場の観測結果を使って選べること自体が価値になる。
第 6 章のコストモデルでも、初期構築費用が大きく、利用回数が少なく、実行時に結果を安価に検証できる条件では、AI エージェント型が総費用で有利になり得る。反対に、固定された規則を大量反復し、事前検証を多数の実行へ再利用できる場合には、静的実装の方が有利になり得る。
第 7 章で見た長期タスクでは、モデルが一回の変更に成功する能力と、過去の変更を含む状態を維持し、誤りを検出し、必要ならロールバックする能力が必要になる。ここでも、モデル能力だけで優位が決まるわけではない。
| 論文の主張を支える要素 | 数理的な確認結果 | 不足している段階 |
|---|---|---|
| 状態や依存候補が指数的に増える | 候補総数が急増すること自体は成立する。 | 候補総数から一つの設計済みシステムの計算量や開発量は直接導けない。 |
| 人間の認知能力はほぼ固定である | 個人の内部認知容量には制約がある。 | 外部記憶、モジュール化、分業を含む開発システム全体の能力とは一致しない。 |
| モデル能力は投入資源とともに向上し得る | モデル規模や学習・推論計算量を増やしたときの能力向上としては成立し得る。 | 問題サイズに対する漸近計算量の優位を示すには、問題サイズと必要資源量の関係が別途必要になる。 |
| AI エージェントは実行時に判断できる | 従来方式とは異なる実用上の性質である。 | 判断に必要な情報量、推論費用、検証費用、長期状態管理の下限は別途残る。 |
このため、否定されるのは「AI エージェントが役に立つ」という経験的命題ではない。否定されるのは、状態空間や依存グラフ候補が指数的に増えるという事実だけから、AI エージェントが従来型ソフトウェアより漸近的かつ普遍的に優位になるという必然性である。
AI エージェントの優位は、問題にどの程度の規則性があるか、同じ判断を何回再利用するか、実行時推論にいくらかかるか、結果をどれだけ安価に検証できるか、変更を何段階積み重ねるか、環境がどの頻度で変化するかによって条件付きで決まる。
数理モデルから得られる結論は、「AI エージェントだから複雑性のスケーリング則を超えられる」ではない。従来型ソフトウェアと AI エージェントは、同じ問題に存在する規則性と情報を異なる場所、異なる時点で利用している。次章では、この違いを複雑性の消滅ではなく、複雑性を処理する場所の移動としてまとめる。
9. AI エージェントは複雑性を消すのではなく、その処理場所を変える
9.1 従来型ソフトウェアは、判断の多くを開発時に固定する
ここまでの議論を一つにまとめると、従来型ソフトウェアと AI エージェント型の差は、複雑性を持つか持たないかではなく、判断をどの時点で確定するかにある。従来型ソフトウェアでは、要求を分析し、許容する入力、処理条件、依存関係、エラー処理をコードや設定として開発時に固定する割合が大きい。
この事前固定には弱点もある。開発時には予測できなかった要求や環境条件が現れ、その状況を既存規則で扱えなければ、仕様を解釈し直し、実装を変更し、検証して再配布しなければならない。事前に確定する範囲を増やすほど実行時の処理は単純になる一方、未知条件へ対応するには開発工程へ戻る必要がある。
9.2 AI エージェントは、判断の一部を実行時まで確定しない
AI エージェント型では、この境界を後ろへ移せる。モデルが現在の要求を読み、必要な情報を検索し、コンテキストを構成し、利用可能なツールから操作を選び、その結果を観測して次の判断を変える。最初から処理列全体を固定する必要がなく、途中で得た情報を後続判断へ組み込める。
このため、AI エージェント型ではコードだけを見てもシステム全体の振る舞いを説明できない。実際の行動は、少なくともモデル、プロンプト、現在のコンテキスト、長期記憶、利用可能なツール、外部状態、権限、評価器、過去の実行履歴の組み合わせから決まる。同じモデルを使っていても、この周辺構造が違えば実行経路も変わる。
9.3 複雑性の保存先が変わると、管理対象も変わる
従来型ソフトウェアと AI エージェント型を、複雑性を保持する場所で比較すると、単純な置き換えではないことが分かる。
| 管理対象 | 従来型ソフトウェアでの主な保持場所 | AI エージェント型で追加される保持場所 |
|---|---|---|
| 判断規則 | ソースコード、設定、ルール、ワークフローとして保持する。 | モデル重み、プロンプト、ポリシー、ツール選択規則へ一部を移せる。 |
| 現在状態 | データベース、ファイル、プロセス状態、外部システムとして保持する。 | 会話コンテキスト、作業履歴、長期記憶、途中生成物も判断材料として保持する。 |
| 正しさの条件 | 型、仕様、制約、テスト、監視条件として保持する。 | 評価器、実行時検証、承認条件、人間への返却条件を追加する必要がある。 |
| 失敗からの回復 | 例外処理、再試行、トランザクション、ロールバック、運用手順として実装する。 | モデルによる再計画を加えられるが、復元可能な状態とロールバック機構自体は残る。 |
| 変更履歴 | バージョン管理、変更記録、監査ログとして保持する。 | モデルがどの観測からどの判断を行ったかという実行履歴も追跡対象になる。 |
この表で増えているのは、単なる実装手段ではない。従来はコードの中に比較的明示されていた判断の一部が、モデル推論と実行時状態の組み合わせによって決まるようになる。その結果、ソフトウェアの正しさを確認するために見るべき対象も、静的な成果物だけでは足りなくなる。
例えば同じプロンプトでも、検索結果が変われば判断が変わり得る。長期記憶に誤った情報が保存されれば、その誤りが後続判断へ影響する。利用可能なツールが増えれば対応範囲は広がるが、誤操作できる範囲も広がる。モデル出力とともに、どの情報が入力され、どの権限で何を実行し、どの検証を通過したかまで管理しなければ、結果の再現性と責任範囲を説明できない。
9.4 複雑性を実行時へ移すと、適応性と検証負担が同時に増える
第 6 章のコストモデルでは、この移動を構築費用と実行費用の配分として表した。従来型ソフトウェアでは設計と検証を事前に行い、その結果を多数の実行へ再利用できる。AI エージェント型では、初期実装を減らせる場合がある一方、実行ごとに推論、情報取得、ツール実行、結果検証が発生する。
AI エージェントの柔軟性と検証負担は別々の現象ではない。同じ原因から生じている。開発時に判断を固定しないから環境へ適応でき、固定しないから実行時にその判断の正しさを確認しなければならない。
9.5 長期化すると、複雑性は状態と履歴にも蓄積する
第 7 章では、実行時判断を一回だけ行う場合と、それを長期間積み重ねる場合を分けた。エージェントが一件の修正に成功しても、その変更後の状態が次の修正の前提になると、未検出の誤りが履歴を通じて後続処理へ伝播する。
この段階では、現在状態を保持するだけでは足りない。どの状態が検証済みなのか、どの変更によって現在状態へ到達したのか、どの不変条件が現在も成立しているのか、失敗した場合にどの時点まで戻れるのかを管理する必要がある。
9.6 生成主体が変わっても、採用主体は消えない
AI がコードを書いた場合でも、その成果物が自動的にプロジェクトの正しい成果物になるわけではない。生成されたパッチ、設定変更、設計変更を正式な状態として受け入れるには、その結果が要求、品質基準、セキュリティー条件、運用条件を満たしていると判断する必要がある。
既稿「AI が書いたコードを、誰が引き受けるのか」では、生成 AI が介在したコードについて、生成主体と、その成果をプロジェクトの成果物として採用し、説明し、保守する主体を分けて考えた[23]。AI エージェントが実行時に多くの判断を引き受けるほど、この境界はコード生成だけに限定されなくなる。
例えば、エージェントが依存ライブラリーを更新し、データベーススキーマを変更し、本番環境へ反映するところまで自律化されたとする。各操作をモデルが生成したとしても、その変更を許可する条件、影響範囲、失敗時の回復手順、監査記録を誰が設計するかという判断は残る。モデルに操作権限を与えること自体が、人間または組織による設計判断だからである。
自律化によって人間の判断が消えるのではなく、人間が直接行っていた個別操作の一部が、事前に定めた権限、制約、検証条件、承認条件へ変換される。人間の役割は、各行を手で書くことから、エージェントがどこまで判断してよいかを決めることへ移る。
9.7 数理モデルが否定したのは、AI だけが複雑性から逃れられるという説明である
第 8 章で反証したのは、AI エージェントの有用性ではなく、「複雑性のスケーリング則によって AI エージェントの普遍的な優位が必然的に導かれる」という主張である。規則性がある問題では従来型ソフトウェアもその構造を圧縮でき、規則性がない問題では AI も正しいケースを区別する情報量を回避できない。
AI エージェントが実際に持つ優位は別の場所にある。自然言語やコードに含まれる規則性を事前学習によって広く保持し、利用時の要求や環境を読み、その場で不足情報を取得し、処理経路を組み立てられることである。この能力は実用上大きな差を生むが、「情報量や計算量の下限そのものを超えた」という意味ではない。
9.8 ソフトウェア工学の対象は、コードから実行過程へ広がる
この結論から見ると、「AI がコードを書けるようになればソフトウェア工学が不要になる」という見方は、ソフトウェア工学をコード記述作業と同一視している。コードを書く作業の一部が自動化されても、システムが許す状態、依存関係、変更条件、検証条件、回復手順を設計する仕事は残る。
むしろ、実装を実行時に生成できる範囲が広がるほど、固定されたコードだけでは正しさを定義できなくなる。モデルが現在状態をどう観測し、何を記憶し、どのツールを選び、どの権限で実行し、どの結果を成功として採用するかまで含めて、一つの実行過程として設計しなければならない。
従来型ソフトウェアでは、コードそのものが判断のかなりの部分を固定していた。AI エージェント型では、コードの一部がその場で生成されるため、固定すべき対象は一段外側へ移る。どの情報をモデルへ見せるか、どこまで操作を許可するか、どの不変条件を越えてはならないか、どの検証に失敗したら処理を止めるかという境界が、システムの振る舞いを決める。
| 設計対象 | コード中心の設計で主に決めること | AI エージェント型で追加して決めること |
|---|---|---|
| 入力 | 形式、型、範囲、前提条件を定義する。 | モデルへ提示するコンテキストと検索可能な情報範囲を定義する。 |
| 処理 | アルゴリズム、制御構造、依存関係を定義する。 | モデルが選択できる行動、ツール、再試行範囲を定義する。 |
| 正しさ | 仕様、型、テスト、不変条件で確認する。 | 実行時評価、承認条件、人間への返却条件まで含めて確認する。 |
| 失敗 | 例外処理、ロールバック、復旧手順を定義する。 | モデルの誤判断を検出し、確定状態へ戻す境界を定義する。 |
| 責任 | 実装、レビュー、運用の担当範囲を定義する。 | モデルの生成・判断と、人間または組織による採用・承認の境界を定義する。 |
コードが自動生成されるほど、ソフトウェア工学の中心は「どのコードを書くか」だけでは説明できなくなる。判断を実行時へ残すなら、その判断が行われる環境、利用できる情報、許可された操作、正しさの判定、失敗後の回復までを一つの系として設計する必要がある。
9.9 AI エージェントが変えるのは、複雑性の量より配置である
本稿の出発点は、状態空間が指数的に増えるなら、実行時に推論できる AI エージェントだけがその複雑性を扱えるのかという問いだった。数理モデルを分解すると、その説明は成立しなかった。
入力候補の数と振る舞いの記述量は一致しない。規則性があれば、巨大な状態空間でも短いアルゴリズムで扱える。規則性がなければ、AI も正しいケースを区別する情報を必要とする。依存関係についても、候補グラフの総数と、一つの設計済みシステムを管理する複雑性は同じではない。
そのうえで AI エージェントには、従来方式と異なる実用上の性質がある。開発時には確定できなかった判断を、利用時の観測結果を使って実行時に処理できることである。この性質によって未知条件へ対応しやすくなる。同時に、推論費用、実行時検証、状態管理、履歴管理、エラー回復が新たな設計対象になる。
複雑性がコードからモデルへ単純に移るわけでもない。判断規則の一部はモデルへ、タスク固有情報はコンテキストや外部記憶へ、正しさの条件は評価器やテストへ、失敗処理はロールバックや人間介入へ分散する。従来は開発時に集中していた判断が、実行時の複数の構成要素へ再配置される。
AI エージェントは複雑性を回避するのではない。問題に規則性があれば従来型ソフトウェアもその規則性を圧縮でき、規則性がなければ AI も必要な情報量を回避できない。AI エージェントによって変わるのは、複雑性そのものよりも、その複雑性をいつ確定し、どこに保持し、どの仕組みで検証し、失敗時に誰が引き受けるかである。
この変化によって、ソフトウェア工学の対象は消えるのではなく広がる。実装を事前に固定する工学から、実行時に判断する系の状態、制約、評価、回復可能性まで設計する工学へ重心が移る。AI エージェントがソフトウェア工学を終わらせるのではなく、コードを書くことの外側に以前から存在していた設計問題を、より明示的な形で表面化させている。
参考文献
- Claude E. Shannon, A Mathematical Theory of Communication, Bell System Technical Journal, Vol. 27, 1948. https://onlinelibrary.wiley.com/doi/10.1002/j.1538-7305.1948.tb01338.x
- Gregory J. Chaitin, On the Length of Programs for Computing Finite Binary Sequences, Journal of the ACM, Vol. 13, No. 4, 1966. https://doi.org/10.1145/321356.321363
- David H. Wolpert, William G. Macready, No Free Lunch Theorems for Optimization, IEEE Transactions on Evolutionary Computation, Vol. 1, No. 1, 1997. https://doi.org/10.1109/4235.585893
- Herbert A. Simon, The Architecture of Complexity, Proceedings of the American Philosophical Society, Vol. 106, No. 6, 1962. https://www.jstor.org/stable/985254
- David L. Parnas, On the Criteria To Be Used in Decomposing Systems into Modules, Communications of the ACM, Vol. 15, No. 12, 1972. https://doi.org/10.1145/361598.361623
- Frederick P. Brooks Jr., No Silver Bullet: Essence and Accidents of Software Engineering, Computer, Vol. 20, No. 4, 1987. https://www.cgl.ucsf.edu/Outreach/pc204/NoSilverBullet.html
- M. M. Lehman, Program Evolution, Information Processing & Management, Vol. 20, Issues 1-2, 1984. https://doi.org/10.1016/0306-4573(84)90037-2
- Shunyu Yao et al., ReAct: Synergizing Reasoning and Acting in Language Models, 2022. https://arxiv.org/abs/2210.03629
- Noah Shinn et al., Reflexion: Language Agents with Verbal Reinforcement Learning, 2023. https://arxiv.org/abs/2303.11366
- John Yang et al., SWE-agent: Agent-Computer Interfaces Enable Automated Software Engineering, 2024. https://arxiv.org/abs/2405.15793
- Chunqiu Steven Xia et al., Agentless: Demystifying LLM-based Software Engineering Agents, 2024. https://arxiv.org/abs/2407.01489
- Yingwei Ma et al., Lingma SWE-GPT: An Open Development-Process-Centric Language Model for Automated Software Improvement, 2024. https://arxiv.org/abs/2411.00622
- Renuka Kumar, Prashanth Ramagopal, Agentic Engineering: How Swarms of AI Agents Are Redefining Software Engineering, LangChain Blog, 2026-04-17. https://www.langchain.com/blog/agentic-engineering-redefining-software-engineering
- Carlos E. Jimenez et al., SWE-bench: Can Language Models Resolve Real-World GitHub Issues?, ICLR 2024. https://proceedings.iclr.cc/paper_files/paper/2024/hash/edac78c3e300629acfe6cbe9ca88fb84-Abstract-Conference.html
- OpenAI, Introducing SWE-bench Verified（2024-08-13）. https://openai.com/index/introducing-swe-bench-verified/
- OpenAI, Why SWE-bench Verified no longer measures frontier coding capabilities（2026-02-23）. https://openai.com/index/why-we-no-longer-evaluate-swe-bench-verified/
- id774, AI に仕事を任せるには、モデルの外側を設計する（2026-08-21）. https://blog.id774.net/entry/2026/08/21/5544/
- Xiang Deng et al., SWE-Bench Pro: Can AI Agents Solve Long-Horizon Software Engineering Tasks?, 2025. https://arxiv.org/abs/2509.16941
- Minh V. T. Thai et al., SWE-EVO: Benchmarking Coding Agents in Long-Horizon Software Evolution Scenarios, 2025. https://arxiv.org/abs/2512.18470
- Gangda Deng et al., EvoClaw: Evaluating AI Agents on Continuous Software Evolution, 2026. https://arxiv.org/abs/2603.13428
- id774, AI による大規模開発では、未確定な状態を一件ずつ閉じる（2026-08-15）. https://blog.id774.net/entry/2026/08/15/5503/
- Zhenfeng Cao, The End of Software Engineering: How AI Agents Are Fundamentally Restructuring the Software Paradigm, 2026. https://arxiv.org/html/2606.05608v1
- id774, AI が書いたコードを、誰が引き受けるのか（2026-08-03）. https://blog.id774.net/entry/2026/08/03/5435/