LLMを使って古くなったOSSプロジェクトを書き換える

大規模言語モデル（LLM）は、ソフトウェア開発のコスト構造、特に既存のオープンソースプロジェクトの書き換えというタスクを根本的に変えつつある。かつて、成熟した長年のオープンソースプロジェクトを書き換えるには、数十年にわたって蓄積されたエッジケース、プラットフォームの互換性、暗黙の設計判断に対処する必要があり、数年を要するのが一般的だった。しかし今、それらの障壁は取り除かれつつある。

本稿の著者は、Architectという企業に所属し、まさにそのような書き換えを経験している。LLMの助けを借りて、重要なツールであるCRIU（Checkpoint/Restore In Userspace）の書き換えが、通常必要な数年ではなく、数ヶ月で完了すると見込んでいる。CRIUはLinux上でプロセスのチェックポイント/リストアを実現する唯一のツールであり、runc、Podman、そしてKubernetesエコシステム全体に統合されている。しかし、10年以上の歴史を持つこのプロジェクトは陳腐化しつつある。コードベースはC言語であり、ホームページは時代遅れのMediaWikiインスタンスをまだ使用しており、メンテナはAIが生成した一見正しいがレビューに多大な時間を要するパッチやバグ報告に圧倒されている。

記事は、オープンソースプロジェクトがなぜ陳腐化するのかを深く分析している。第一に、メンテナは人間であり、情熱は冷めていく。プロジェクトは初期に活力に満ちているが、時間が経つにつれてメンテナンス作業は退屈になり、コア開発者は離れていく。第二に、世界は変化する。Go、Rust、Zigなどの新しい言語が登場し、eBPFやio_uringなどの新機能がカーネルに追加されるが、成熟したコードベースはこれらの変化に適応するのが難しい。第三に、大規模プロジェクトはしばしば革新を止める。安定性と後方互換性が最優先事項となり、大きな変更は統合されにくくなる。著者はこの状況を大企業になぞらえる。大企業は革新せず、革新したスタートアップを買収する。しかしオープンソースにはそのような仕組みがなく、革新は外部から来るしかない。

AIはどのように状況を変えるのか？鍵となるのは、LLMがコードを生成できるだけでなく、既存のプロジェクト自体が利用可能な参照仕様となることだ。数十年にわたって蓄積された決定、エッジケース、プラットフォームの詳細は、かつては書き換えの最大の障壁だったが、今では新しい実装を検証するための仕様となる。開発者はLLMを活用して、これらの仕様を満たす新しいコードを素早く生成でき、すべての詳細をゼロから理解する必要はない。AIはアーキテクチャ設計や判断力を代替するわけではないが、退屈な作業（ボイラープレートコードの作成、プラットフォーム特有の処理、テストマトリックスの構築など）を大幅に削減する。これにより、書き換えは「不可能」から「有限時間で実行可能」へと変わる。

具体的なケースに戻る。Architectの核となるビジネスはワークロードのライブマイグレーションであり、高速で予測可能、かついつでも修正可能なチェックポイント/リストアツールを必要としている。CRIUは機能的だが、C言語のコードベースのため統合や最適化が難しい。そこで彼らはCRIUをZigで書き換えることを決断した。Zigを選んだ理由は、モダンな機能、優れたメモリ安全性、既存のCコードとの相互運用性にある。LLMを活用することで、元のCRIUを参照仕様として新しいコードを迅速に生成し、特定のユースケースに最適化し、CRIUがあらゆる可能なシナリオに対応するために蓄積した複雑さを取り除いている。

もちろん、課題は残る。カーネルインターフェースや正確なプロセス状態のキャプチャなど、中核的な難所は依然として人間の対応を必要とする。しかしLLMは開発速度を大幅に加速する。チームは数ヶ月での書き換え完了を見込んでおり、これは通常の数年とは対照的だ。この記事は明確な視点を提供している。AIはソフトウェア開発を簡単にするわけではないが、多くのコストのかかるタスクを安価にし、古いプロジェクトの書き換えの経済性を変えている。