工場と証書―― AIソフトウェア工場の到達点と、大規模移植の証明可能性をめぐって

＜今週くらいでAIエージェントやAI工場ネタは卒業しよう。うーん、また船ですか＞

目次

序 —— 速さから、信用へ................................................... 2

第一章 発端 —— 十一日間の移植と、実製品への先行投入........... 3

第二章 「十一日」の正体 —— 移植を工場化するということ............ 5

第三章 工場の解剖 —— 確認できる骨格と想定される層.................... 6

第四章 世界の収束 —— 同じ設計へ集まる主要各社...................... 7

第五章 二つの物差し —— 機能充足度と証拠水準を分ける.............. 9

第六章 四つの工場類型.................................................................... 11

第七章 中国の位置 —— 工場の部品は揃うが、外部検証可能な実績は限られる..................... 12

第八章 敵対的レビューの独立性という限界..................................... 15

第九章 条件依存性 —— 成功を支えた検証資産は、多くの現場で不足している..................... 17

第十章 証書なき成功 —— 船級制度の視点から................................. 19

結語 —— 競争対象の転換.............................................................. 21

注記と留保................................................................................... 22

参考文献................................................................................... 23

序 —— 速さから、信用へ

二〇二六年七月、あるJavaScriptランタイムの開発言語を、AIのコーディング・エージェント群を用いて十一日間で別言語へ移し替えたという事例が話題を集めた。さらに、その移植版が、同じAIベンダーの配布するコーディング支援ツールの内部で早くも使われている疑いが指摘された。表層だけを追えば「AIが十一日で巨大ソフトを書き直した」という速度の物語に見える。しかし、この出来事の重心はそこにない。

本稿の見立てを一言で述べれば、これは「AIがコードを書く速度」よりも、「移植した巨大ソフトを、どうやって信用できる状態まで持っていくか」が主戦場になったことを示す事例である。コードの生成量や所要日数は結果にすぎない。決定的だったのは、テスト、役割の分離、敵対的なレビュー、失敗したときに巻き戻して直し続けるループといった、生成物を検証し保証するための「外側の生産設備」を、人間が設計したことである。速く書けること自体は、もはや驚きではない。驚くべきは、速く書かれたものを、どうやって「正しいと言える状態」へ持っていくかという問いに、一定の答えが出はじめたことである。

この視点は、企業向けAI基盤をめぐる近年の議論とも通底する。各社は「つなぐ・意味づける・実行する」までは競って提示するが、「止める・遡る・移す・第三者が検める」という保証の層はほとんど誰も提示していない。今回の移植も、まさにこの保証の層をどう満たすかという問題として読める。生成能力だけでは差がつきにくくなりつつあり、いま開こうとしているのは検証と巻き戻しの側である。本稿は、この一件を起点に、AIソフトウェア工場と呼ぶべきものの世界的な到達点を俯瞰し、その到達がどこまで一般化できるのかを見定めることを目的とする。

なお、本稿が繰り返し立ち返る対比は、速さと信用である。速さは測りやすく、見出しになりやすい。信用は測りにくく、地味である。しかし、ソフトウェアが社会の基盤を担ういま、速く作れることよりも、作ったものを信用に足る状態へ持っていけることのほうが、はるかに希少で価値がある。今回の一件が重要なのは、速さの記録としてではなく、信用をどう工学的に生み出すかという問いに、具体的な形を与えたからである。

以下では、この事例の何が新しく、何が誇張で、そして何が一般化しないのかを、順を追って整理する。あらかじめ三点を断っておく。第一に、登場する個々の人物名は役割で記すが、企業名と製品名は明記する。比較の対象を検証可能にするためであり、匿名化はかえって本稿の主題である検証可能性に反するからだ。第二に、生成行数・日数・各種ベンチマーク値など、一次検証を経ていない数字は「報じられている」「とされる」と明示し、末尾の留保と参考文献にまとめた。第三に、各社の機能についての記述は、原則として「同社は…と説明している」という帰属の形をとる。ベンダーの発表を、独立監査を経た事実と同じ強度では扱わない。

あわせて、本稿が近い意味で使い分ける言葉を先に定めておく。検証とは、仕様やテストに照らして正しさを調べることをいう。妥当性確認とは、利用目的に照らして適しているかを確かめることをいう。適合評価とは、明示された基準への適合を判定することをいう。認証とは、第三者がその適合を証明する制度的な行為をいう。証跡とは、工程と判断を後から復元できる記録をいう。保証とは、リスクを受け入れられる水準まで抑えたという総合的な確信をいう。そして証書とは、検査や認証の結果を表す文書をいう。以降、これらは区別して用いる。