BunのRust書き直しは本当に「11日、16万ドル」だったのか — AI書き直し時代の完了の定義
BunのRust書き直しは本当に「11日、16万ドル」だったのか — AI書き直し時代の完了の定義
コードがmainにマージされたら書き直しは終わったのか。AIが崩壊させたのは書き直しのコストなのか、それとも「完了」という言葉の意味なのか。
導入
7月27日、開発者Tom Lockwoodが投稿した「BunのRust書き直しはどうなっているのか」という記事が、Hacker Newsで453ポイントと348コメントを集めた。発端は7月8日に遡る。JavaScriptランタイムBunの創始者Jarred Sumnerは、BunのコードベースをZigからRustへ全面的に書き直し、この作業をAnthropicのClaudeを活用して完了したと発表した。公開された数字は業界をざわつかせるに十分だった — 5月3日から14日までの11日間、APIコスト**$165,000**(1日約$15,000)。
数百万人が使うランタイムの言語移行を2週間で、シニアエンジニア1人の年収より安い金額で。これが事実なら、ソフトウェア産業のコスト構造に関する通念がひとつ崩れる事件である。Lockwoodの記事はまさにその「事実なら」を検証する試みだ。そして彼が公開データから引き出した絵は、発表文とはかなり違う。
Bunがどんなプロジェクトかを思い出せば重みが増す。BunはNode.jsより速い起動時間と組み込みのバンドラー・テストランナーを武器に2022年に登場し、npmを代替するパッケージマネージャーとして広く使われるインフラ級のソフトウェアだ。Zigという非主流言語の最大規模の実戦事例でもあった。そのコードベース全体を別の言語に、AIで、2週間で移したという発表は、だから単なるプロジェクトニュースではなく、業界全体に向けた実証主張だった。
この記事が扱うのはBunというプロジェクト一つの真偽論争ではない。AIエージェントが大規模書き直しの限界費用を劇的に下げた時代に、「完了」を何で定義し何で検証するのかという、今後すべてのエンジニアリング組織が直面する問いの、最初の公開ケーススタディである。
発表文と公開データの乖離
Lockwoodが指摘した事実を並べてみよう。すべて公開リポジトリとCIダッシュボードで確認可能な数字である。
第一に、リリースがない。 書き直しブランチがmainにマージされて6週間経った7月27日時点でも、リリースタグが存在しない。直前のリリースは5月12日 — 11週間前だ。数週間隔のリリースを維持してきたBunの歴史で前例のない空白である。書き直しが「終わった」なら、その成果物はなぜまだユーザーに届いていないのか。
第二に、PRの滞留が爆増した。 Claudeが生成したPRを上げるボットアカウントrobobunの未処理PRは、7月9日の1,277件から7月27日の2,475件へと18日でほぼ倍増した。マージ1件あたりCIが40〜90分かかる現在のパイプライン処理能力では、この滞留を消化するだけで86日分のCI時間が必要だという計算になる。生成速度が検証速度を圧倒している。
第三に、会計が不完全である。 $165,000はAnthropic APIのコストだけだ。マルチプラットフォームテストを回すBuildkite CIの費用は公開されておらず、Anthropic社員が直接関与した形跡は、計算に含まれない人件費を示唆する。Lockwoodは書き直し発表後も1日$10,000規模の支出が続いていると推定し、総コストが$800,000の方向に向かっている可能性があると見る。
HNスレッドではSumnerも反論を展開した。要旨を写せば、Rustで書き直されたBunはすでに1ヶ月以上Claude Codeに載って出荷されており、誰も気づかなかった — 数百万ユーザーの環境で目に見える問題なく動いていたなら、それこそが実戦検証だ、という論理である。CIコストについてはマルチプラットフォームテストに必然の支出だと防御した。これへの再反論も鋭かった。あるコメンターは、Claude Codeという単一ワークロードが使う機能のサブセットだけで書き直しの完成を主張するのは、Unreal Engine 5を別の言語に移植してテトリスが動くから完成だと宣言するようなものだと皮肉った (HNコメント要旨)。
「完了」の三つの定義
この論争を整理すると、争点は事実関係ではなく**「完了」の定義**である。歴史的文脈を先に敷いておこう。全面書き直しはソフトウェア工学で長らくタブーだった。Joel Spolskyが2000年に書いた「絶対にやってはいけないこと」は、Netscapeがブラウザエンジンをゼロから書き直すと決めた判断を「単一最悪の戦略的失敗」と名指しし、この教訓は一世代のエンジニアリング組織に内面化された。書き直しがタブーだった理由は二つのコストにある — 書き直している間止まる機能開発の機会費用、そして既存コードに蓄積されたエッジケースの知識の消失。AI書き直しは前者を劇的に減らす。11日なら機会費用は無視できる水準だ。だからこの事例が重要になる — タブーを支えていた二つのコストの一方が消えたとき、残る一方(知識の消失)だけでタブーが維持されるのかを示す最初の実験だからである。
その上で、三つの異なる完了が競合している。
定義1: コードが存在する(マージ基準)。 Sumnerの発表が立脚する定義だ。Rustで書かれたコードベースがmainにあり、コンパイルされ、主力ワークロードを回している。AI書き直しはこの定義の達成コストを実際に崩壊させた。11日と$165,000という数字自体はおそらく嘘ではないだろう — この定義の中では。
定義2: ユーザーに出荷された(リリース基準)。 伝統的な定義だ。すべてのサポート対象プラットフォームでテストを通過し、バージョンがタグ付けされ、既存ユーザーがアップグレードできる。この定義では書き直しは11週間経っても未完である。リリースの空白と2,475件のPR滞留は、定義1と定義2の間の距離を示す計器盤だ。
定義3: 組織がコードを理解している(保守基準)。 最も静かだが最も重い定義である。HNのある経験豊富な開発者は、今後のサポートと修正の必要性を指摘し、急速なLLM書き直しは開発者の深い理解を生まず、そうしたプロジェクトが歴史的にどう放置されてきたかを警告した (HNコメント要旨)。人間のチームが書き直しをすれば、その過程で組織にコード理解が蓄積される。AIが書き直しをすればコードは新しくなるが理解は蓄積されない — むしろ既存のZigコードベースへの理解まで減価償却される。
興味深い対照群が同じ週に現れた。7月24日のHNにはBuz — Bunをモダンな Zigの慣行でフォークし、1秒未満のインクリメンタルビルドを達成したというプロジェクト — が304ポイントを集めた。Buz側の主張の要旨は、Bunの問題はZigという言語ではなく自ら招いた構造にあった、というものだ (コミュニティの主張の要旨、未検証)。真偽と別に、このフォークの存在は「ZigからRustへ」というフレーム自体が書き直しの本質ではなかった可能性を示唆する。言語移行が目的なら、フォークが示すように別の道があった。ではこの書き直しの実際の機能は何だったのか — 技術的必要か、AI能力の実証か。
Lockwoodは後者の匂いを嗅ぎ取る。彼は同僚たちがこの書き直しをAI能力の証明として「息せき切って」祝うことを警戒し、企業の高いバリュエーションを支える主張には懐疑主義がデフォルトであるべきだと書く。BunはAnthropicと協業関係にあり、「Claudeが11日でランタイムを書き直した」という物語は双方に商業的価値がある。物語の利害関係者が物語の検証者を兼ねている構造 — これがこの事例で最も構造的な問題である。
書き直し経済学の再編
この事例から実務者が引き出せる教訓を整理する。
ボトルネックの移動を計画せよ。 AIはコード生成のコストを崩壊させたが、検証のコストには手を付けられなかった。robobunの2,475件の滞留はその定量的証拠だ。生成がタダに近づくほど、組織のスループットはCI容量、レビュー人員、リリースエンジニアリングが決める。AI導入計画でトークン予算より先に立てるべきは、検証パイプラインの増強計画である。
CI経済学を計算し直せ。 マージ1件あたり40〜90分というCI時間は、人間の開発者のPR頻度に合わせて設計されたものだ。1日数十件を上げるエージェントの前でこの設計は即座に破綻する。対応は二方向しかない — CIをエージェントのスループットに合わせて増強するか(コスト爆増)、エージェントの生成量をCIの処理能力に合わせてスロットリングするか(AI導入効果の半減)。robobunの滞留はこの選択を先送りした結果と読める。AI導入の稟議書にトークンコストしか書かれていないなら、その稟議書は総コストの半分以下しか見ていない。
完了宣言にリリース基準を要求せよ。 「AIでXをやった」という発表が今後溢れ返るだろう。そのたびに問うべき質問を、この事例は正確に教えてくれる — どの定義の完了なのか。タグはあるのか。全テストスイートは回るのか。ロールバック計画はあるのか。発表時点とリリース時点の間隔こそが、AI成果主張の最も正直な指標になるだろう。
理解の減価償却を会計に入れよ。 書き直し前のBunにはZigコードを深く知る少数の人間がいた。書き直し後のBunにはRustコードを深く知る人間が何人いるのか。AIが書いたコードの障害はAIにデバッグさせればよいという反論はあるだろうが、そのループが実戦の障害対応で検証された事例はまだない。保守可能性はコードの属性ではなくコードと組織の間の関係の属性であり、書き直しはその関係をリセットする。
展望すれば、この種の論争は増えるしかない。AI書き直しの限界費用が下がるほど「とりあえず書き直して発表する」インセンティブは大きくなり、検証されない完了宣言と実際の出荷の間の乖離は、コミュニティの探偵作業 — 今回のように公開PRカウントとリリースタグを突き合わせる — でしか明らかにならない。必要なのはAI時代の新しい慣例かもしれない。書き直し発表にリリースタグと全テスト通過の証拠を添付すること、いわば成果主張の再現可能性規範である。
結論
リード質問に戻ろう。AIが崩壊させたのは書き直しのコストではなく、「完了」という言葉の解像度である。コード生成という意味の完了は、本当に11日と$165,000で可能になったのだろう。しかし出荷という意味の完了は11週間経っても来ておらず、組織的理解という意味の完了は測定すら始まっていない。三つの定義の乖離を一語に丸めた発表は、意図が何であれ、業界全体の期待値を歪める。
Lockwoodの結びの文が適切な句点である — 「書き直しが『終わった』ということ、あるいは$165,000で『終わった』ということを、額面通りに受け取ることはできない」。あなたの組織で次のAI成果報告を受けるとき、その「完了」は三つの定義のどれなのか — そして残り二つの定義のコストは誰の予算に計上されているのか、問うてみてほしい。
出典: