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

Microsoftは、GitHub Copilotやその他の多くのMicrosoft製品の基盤となるソフトウェアエンジンを、AIエージェントがポート作業の大部分を担う形で、完全にRustで書き直しました。 この移行には、AIトークン使用量で約12万ドル、開発者の時間で約3週間を要しました。しかし、マネージャーは結果として生じたコードの数十件の回帰（リグレッション）にも対処する必要があり、Rustを理解する上でのAIの継続的な課題を示唆しています。 この作業は、14.5週間にわたる135件以上のリリースを通じて、モジュールごとにランタイムを更新して完了しました。1日あたり約1.3件のポートプルリクエストが開かれました。 ポートを可能な限りシンプルにするため、TypeScriptモジュールはケースバイケースで置き換えられました。ランタイム自体の構造を最適化することは目的とされていませんでしたが、それは次のステップとなります。 そして、その軽量なパフォーマンスで知られるRustは期待を裏切りませんでした。あるベンチマークでは、共有クライアントと100の同時パイプラインを使用して、ランタイムが1,000回の1ターンセッションライフサイクルをどれだけ速く完了できるかを測定しました。元のTypeScript実装は毎秒7.55回のライフサイクルを完了したのに対し、インプロセスで実行されたRustは毎秒120回を達成し、その特定のワークロードで15.9倍の高速化を実現しました。 メモリに関しては、10クライアントのバッチエージェントはTypeScriptで1,383MBを消費しましたが、Rustへの書き換えは同じスウォームにサービスを提供しながらわずか126MBしか消費しませんでした。Rust内では、TypeScriptで必要とされていた外部バックグラウンドプロセスの起動ではなく、作業はインプロセスで維持されました。 CopilotはVS CodeからMicrosoft Officeまで 一見すると、ほとんどのユーザーはCopilotランタイムがどれほど普及しているかを知らないかもしれません。それはGitHub Copilotコマンドラインインターフェイス（CLI）、Copilotアプリ、SDK、そしてGitHub Copilotクラウドエージェントをバックアップしています。VS Code、Visual Studio、Excel、Outlook、PowerPoint、そして数え切れないほどの他のMicrosoftクラウドサービスに登場します。 元々、ランタイムはTypeScriptで書かれ、フレームワークとしてNode.js、実行エンジンとしてV8を使用していました。TypeScriptとNodeは迅速な開発には最適でしたが、大規模に使用すると、高速な起動とサーバー密度を提供するという点で苦労しました。 MicrosoftのDistinguished EngineerであるStephen Toub氏は、プロセス全体を説明した投稿で、「これは、すべての大規模なTypeScriptプログラムがRustになるべきだという主張では決してありません。私たちの要件は、C ABIを介した埋め込み、低速な起動と定常状態のオーバーヘッド、そして予測可能なリソース使用を強調しました。Rustはそれらの目標を可能にしました」と述べています。 このプロジェクトでは、Copilot自身を使ってCopilotを書き直しました。そして、そのCopilotは、それぞれのLLMの自然な強みに応じて、仕事の異なる部分を実行するために、GPT-5.6 SolとClaude Opus 4.8という複数のLLMを使用しました。 よく読んでいるが、おしゃべりなエージェント Toub氏は、エージェントの使用を概ね成功したと評価しました。実際、このプロジェクトを手作業で行っていたら、何年もかかり、数百万ドルかかったでしょう。Toub氏は、エージェントがいくつかの驚くべき創発的な振る舞いを示したと指摘しました。一つには、コードを書くよりも情報収集に far より多くの時間を費やしたことです。「AIがコードを吐き出すという一般的なイメージは、ほとんど逆です。この規模では、作業は反復的な調査、現在の状態の検査、仮説の形成、ターゲットを絞った変更、そして繰り返しのプロセスのように見えました」と彼は書いています。もう一つの驚きは、セッションが他のセッションとどれほど頻繁に相互作用したかということです。それらが生成したセッションであれ、完全に別のセッションであれ。 最も厄介な変換の一つは、ランタイムのすべての側面に触れる30,000行以上のTypeScriptファイルであるsession.tsでした。完了に25時間かかったポート作業は、ドキュメントを読み、明確化のために122回のツール呼び出しを行うために56分を費やすことから始まりました。その後、15個の子セッションを生成し、それぞれが独自のワークツリーとエージェントを作成しました。そして、それらは互いに通信を開始しました。 組み込みのオーケストレーションスキルを使用して、1つのセッションが他のすべてのアクティブなセッションを見つけ、ミッションが重複しているセッションにメッセージを送信し、調整を要求しました。 コンパイラは教師であり、神託ではない パフォーマンス上の利点から、Rustはアプリケーションの書き直しに人気のある言語であることが証明されています。例えば、Bunの作成者であるJarred Sumner氏は最近、Anthropicが所有するJavaScriptランタイムとツールキット（約535,000行のZigコードを含む）を、ほぼ完全にClaudeエージェントを使用してRustにポートしました。7月30日現在、実験的なRustポートはLinux x64 glibcでBunの既存テストの99.8％をパスしており、安定版リリースは依然としてZigコードベースから出荷されています。 その仕事はトークンで165,000ドルかかりました。しかし、Toub氏が発見したように、Rustを使用することには隠れた危険性もあります。LLMにとっても、怠惰なプログラマーにとっても、コードがコンパイルされれば、それは有効なRustです。 しかし、プロセス全体を通して、プロジェクトはコード内で数十件の回帰に遭遇しました。回帰とは、更新後に機能しなくなったものです。例えば、コンパイラは、関数が正しい順序にあるかどうか、ジョブが許容できるコストで完了するかどうか、開発者の暗黙の要件を満たしているかどうか、あるいはそもそも内部的に一貫性があるかどうかを知る由がありません。 先週モントリオールで開催されたRustConfで、コンサルタントのLisa Crossman氏は、コンパイラを「神託」、つまりRustコードが有効かどうかを判断する最後の言葉として扱うことについて警告しました。「Rustはエージェントがメモリ安全でないコードを書くのを止めますが、エージェントが間違ったプログラムを正しく書くのを止めるわけではありません」と彼女は言いました。 賢明な人間開発者は、コンパイラを教師として扱い、エラーを言語のドメインへのより深い理解への道として解読します。一方、LLMは、コンパイラをブラックボックスとして使用し、それが合格するまで（おそらくこれがZigの作成者Andrew KelleyがBunのRustコードを「レビューされていないゴミ」と呼んだ理由かもしれません）鈍く、非効率的な回避策で叩きのめします。Toub氏の場合、コンパイラによって承認された回帰は、曖昧なセマンティクスと振る舞い、ブランチのドリフト、移植されなかった欠落機能、そして置き換えられたコードからの異なる振る舞いに起因する可能性があることを見つけました。「それはRustのコンパイラに対する議論では決してありません」とToub氏は書いています。「しかし、『コンパイルされれば正しい』というのは、ジョークとしてしか役に立ちません。」