Microsoft、AIエージェントを用いてCopilotランタイムをRustへポート、費用12万ドル

Microsoft、AIエージェントを活用してCopilotランタイムをRustへ12万ドルで移植

GitHub Copilotや増え続けるMicrosoft製品の基盤となっているソフトウェアエンジンが、AIエージェントによるポート作業の大部分を経て、完全にRustで書き直されました。

この移行には、AIトークン使用量で約12万ドル、開発者時間で約3週間かかりました。しかし、管理者は結果として得られたコードに数十件の回帰（リグレッション）が発生したことにも対処する必要があり、これはRustの理解におけるAIの継続的な課題を示唆しています。

この取り組みでは、14.5週間にわたる135件以上のリリースを経て、モジュールごとにランタイムを更新し、作業を完了させました。1日あたり約1.3件のポートプルリクエストが開かれました。

REG AD

全体として、エージェントは43万行のTypeScriptを80万行のプロダクションRustに変換しました。ポートを可能な限りシンプルにするため、TypeScriptモジュールはケースバイケースで置き換えられました。ランタイム自体の構造を最適化する作業は行われませんでした。その作業は次に行われます。

REG AD

そして、その軽量なパフォーマンスで知られるRustは期待を裏切りませんでした。

あるベンチマークでは、共有クライアントと100の同時パイプラインを使用して、ランタイムが1,000回の1ターンセッションライフサイクルをどれだけ速く完了できるかを測定しました。元のTypeScript実装は1秒あたり7.55ライフサイクルを完了しましたが、インプロセスで実行されたRustは1秒あたり120を管理し、その特定のワークロードで15.9倍の高速化を達成しました。

メモリに関しては、10クライアントのバッチエージェントはTypeScriptでは1,383MBを消費しましたが、Rustのリライトは同じスウォームにサービスを提供しながらわずか126MBしか消費しませんでした。Rust内では、TypeScriptで必要とされていた外部バックグラウンドプロセスの起動ではなく、作業はインプロセスで維持されました。

VS CodeからMicrosoft OfficeまでのCopilot

一見したところ、ほとんどのユーザーはCopilotランタイムがどれほど普及しているかを知らないかもしれません。これは、GitHub Copilotコマンドラインインターフェイス（CLI）、Copilotアプリ、SDK、およびGitHub Copilotクラウドエージェントをバックエンドで支えています。これは、VS Code、Visual Studio、Excel、Outlook、PowerPoint、その他数え切れないほどのMicrosoftクラウドサービスに登場します。

当初、ランタイムはTypeScriptで記述され、フレームワークとしてNode.js、実行エンジンとしてV8を使用していました。TypeScriptとNodeは迅速な開発には最適でしたが、大規模に使用すると、高速な起動とサーバー密度を提供するという点で問題がありました。

「これは、すべての大規模なTypeScriptプログラムがRustになるべきだという主張では決してありません。私たちの要件は、C ABIを介した埋め込み、低い起動および定常状態のオーバーヘッド、そして予測可能なリソース使用を強調しました。Rustはそれらの目標を可能にしました」と、MicrosoftのDistinguished EngineerであるStephen Toub氏は、プロセス全体を説明する投稿で述べています。

このプロジェクトでは、Copilotを使用してCopilotを書き直しました。Copilotは、それぞれのLLMの得意分野に応じて、GPT-5.6 SolとClaude Opus 4.8という複数のLLMを使用しました。

REG AD

よく読み込むが、おしゃべりなエージェント

Toub氏は、エージェントの使用を概ね成功したと評価しました。実際、このプロジェクトを手作業で行っていたら、数年かかり、数百万ドルかかっていたでしょう。

Toub氏が指摘したように、エージェントはいくつかの驚くべき創発的な振る舞いを示しました。まず、コードを書く時間よりも情報を収集するのに多くの時間を費やしました。

「AIがコードを吐き出すという一般的なイメージは、ほぼ逆です。この規模では、作業は反復的な調査、現在の状態の検査、仮説の形成、ターゲットを絞った変更、洗浄、繰り返しのようでした」と彼は書いています。

もう一つの驚きは、セッションが他のセッションとどれほど頻繁にやり取りしていたか、それが生成したセッションであれ、完全に別のセッションであれ、という点でした。

最も困難な変換の1つは、ランタイムのあらゆる側面に触れる30,000行を超えるTypeScriptファイルであるsession.tsでした。25時間かかったポート作業は、ドキュメントを読み、明確化のために122回のツール呼び出しを行うのに56分を費やすことから始まりました。その後、15個の子セッションが生成され、それぞれが独自のワークツリーとエージェントを作成しました。そして、それらは互いに通信を開始しました。

組み込みのオーケストレーションスキルを使用して、1つのセッションが他のすべてのアクティブなセッションを見つけ、ミッションが重複しているセッションにメッセージを送信し、調整を要求しました。

コンパイラは教師であり、神託ではない

REG AD

パフォーマンス上の利点から、Rustはアプリケーションのリライトに人気の言語であることが証明されています。例えば、Bunの作成者であるJarred Sumner氏は最近、Anthropicが所有するJavaScriptランタイムとツールキット（約535,000行のZigコードが含まれていました）を、ほぼ完全にClaudeエージェントを使用してRustに移植しました。7月30日現在、実験的なRustポートはLinux x64 glibcでBunの既存テストの99.8パーセントをパスしており、安定版リリースは依然としてZigコードベースから出荷されています。

その作業にはトークンで16万5千ドルかかりました。

しかし、Toub氏が発見したように、Rustを使用することには隠れた危険性もあります。

LLMにとっても、怠惰なプログラマーにとっても、コードがコンパイルされれば、それは有効なRustです。

しかし、プロセス全体を通して、プロジェクトはコード内で数十件の回帰に遭遇しました。回帰とは、更新後に以前は機能していたものが機能しなくなることです。

例えば、コンパイラは、関数が正しい順序であるか、ジョブが許容できるコストで完了するか、開発者の暗黙の要件を満たしているか、あるいはそもそも内部的に一貫性があるかを知る由がありません。

先週モントリオールで開催されたRustConfで、コンサルタントのLisa Crossman氏は、コンパイラを「神託」、つまりRustコードが有効かどうかの最終決定として扱う慣行について警告しました。「Rustはエージェントがメモリ安全でないコードを書くのを止めますが、エージェントが間違ったプログラムを正しく書くのを止めるわけではありません」と彼女は言いました。

賢明な人間開発者はコンパイラを教師として扱いますが、エラーを言語のドメインへの理解を深めるための道として解読します。一方、LLMはコンパイラをブラックボックスとして使用し、それがパスするまで（おそらくこれがZigの作成者Andrew KelleyがBunのRustコードを「レビューされていないスラッジ」と呼んだ理由かもしれません）、それを鈍く非効率的な回避策で叩くのです。

Toub氏の場合、コンパイラによって承認された回帰は、曖昧なセマンティクスと振る舞い、ブランチのドリフト、移植されなかった欠落機能、および置き換えコードの異なる振る舞いから生じる可能性があることを見つけました。

「それはRustのコンパイラに対する議論では決してありません」とToub氏は書いています。「しかし、『コンパイルされれば正しい』というのは、ジョークとしてしか役に立ちません。」®