モジュールごとの移植をエージェントが推進

Microsoftは、GitHub Copilotや同社の複数製品との統合機能を支えるランタイムをRustへ書き換えた。変換作業の大半にはコーディングエージェントを使った。プロジェクトは約43万行のTypeScriptを約80万行の本番用Rustへ移し、モデルのトークン利用に約12万ドル、開発者の作業時間に約3週間を費やした。

移植は14.5週間にわたり、135回を超えるリリースを通じて提供され、移植のプルリクエストは平均で1日約1.3件だった。モジュールは再設計するのではなく段階的に置き換え、当面の目標を動作の互換性に絞った。構造の最適化はその後に行う見込みだ。

ランタイムは、GitHub Copilotのコマンドラインインターフェース、アプリ、ソフトウェア開発キット、クラウドエージェントを支える。その派生版は、Visual Studio Code、Visual Studio、Excel、Outlook、PowerPointなど、Microsoftの製品やサービスでも使われる。従来のTypeScript実装はNode.jsとV8エンジンに依存していた。この組み合わせは迅速な開発には向くが、素早い起動、サーバー上の高密度で効率的な実行、Cのアプリケーションバイナリーインターフェースを通じた組み込みといった要件には、必ずしも適していなかった。

書き換えについて報告されたベンチマークは、特定の処理で大幅な改善を示した。100本のパイプラインを同時に動かし、1ターンのセッションのライフサイクルを1000回実行するテストでは、TypeScriptが毎秒7.55回だったのに対し、プロセス内で動作するRustは毎秒120回となり、15.9倍に向上した。別の比較では、10クライアントのエージェント一括処理にTypeScriptが1383MB、Rustが126MBを使った。これらの測定は特定のテストを示すものであり、すべてのCopilot処理で同じ改善が得られる保証ではない。

コンパイル成功でも動作上の失敗は防げず

プロジェクトは、エージェント主導の変換の限界も明らかにした。Rustのコンパイラーが通常どおりメモリー安全性と型安全性の規則を適用していたにもかかわらず、担当者は数十件の機能退行に直面した。問題には、曖昧な動作、ブランチ間のずれ、移し忘れた機能などがあった。妥当なRustコードであっても、誤った動作を実装したり、テストや仕様に記されていない要件を取りこぼしたりする可能性がある。

Microsoftのディスティングイッシュト・エンジニア、スティーブン・トーブは、この結果を、あらゆる大規模TypeScriptプログラムをRustで書き直すべき根拠と受け取らないよう注意を促した。このランタイムには、組み込み、起動時間、予測可能な資源使用量、定常動作時のオーバーヘッドに固有の制約があり、それらがRustを適した選択肢にした。

報道によると、エージェントは単に置き換えコードを生成するよりも、コードを調べ、仮説を立てることに多くの時間を使った。難しかった変換の一つには、3万行を超えるTypeScriptのセッション用ファイルがあった。その作業を担当したセッションは、まず文書を調べて多数のツール呼び出しを行い、その後、別々のワークツリーに子セッションを作り、重なり合う作業を調整した。

この過程は、大規模なエージェントによる移植がなお、強力なテスト、段階的な提供、人間の判断に依存することを示唆する。Rustは特定の種類の低水準の誤りを減らし、測定可能な資源面の利点をもたらしたが、機能退行は、コンパイラーの承認がアプリケーションの正しさと同じではないことを示している。ランタイムを機械的に翻訳するのではなく再設計する次の段階は、エージェントと人間の監督の組み合わせがアーキテクチャー上の作業にどこまで対応できるかを試す、さらなる機会となる。