本番稼働中の言語ランタイムがTypeScriptから83万2,378行のRustへと作り直されました。性能差は明確です。1ターンのセッションライフサイクルを1,000回処理するベンチマークは毎秒7.55回から120回へ伸び、クライアント10台分のエージェントバッチのメモリは1,383MBから126MBまで下がりました。作業期間は2026年5月12日から8月21日まで。コーディングエージェントを監督する一人の開発者が中心となって進め、その全容はMicrosoftの主席エンジニア、Stephen Toub氏による詳細な技術記事にまとめられています。
要点
- エージェントは14.5週間で128本のプルリクエストをマージし、本番のTypeScript約43万行を83万2,378行のRustへ置き換えました。
- 1ターンのセッションライフサイクルを1,000回計測するベンチマークは、TypeScriptの毎秒7.55回に対しインプロセスのRustで毎秒120回。クライアント10台のエージェントバッチのメモリは1,383MBから126MBに減りました。
- セッションログに残るユーザーメッセージ3万1,247件のうち、人間が実際に入力したのは約2,600件。おおよそ12件に1件です。
移植を支えた数字
エージェントは本番コードとは別に、46万8,689行のRust単体テストも生成しました。移植のプルリクエストは1日あたり約1.3本のペースで届き、その間も135回の公開リリースが出ています。一括切り替えではなく、モジュールを一つずつその場で差し替えたためです。The Registerはトークン費用を約12万ドルと伝えています。
一時的な足場の推移も同じ物語を示します。二つの世界をつなぐN-APIエクスポートは8月3日に2,019件でピークを迎え、TypeScript側の呼び出し箇所は3,356か所ありました。どちらも最終的にゼロになっています。
このランタイムが動かしているもの
このエンジンは、触れている人の大半には見えません。CopilotのCLI、Copilotデスクトップアプリ、6言語で提供されるCopilot SDK、クラウドエージェントを支え、最近のVS CodeとVisual Studioにも同梱されています。ExcelやOutlook、PowerPoint、Wordにまで届いています。
当初の実装はNode.jsとV8の上で動くTypeScriptでした。反復開発は速かったものの、同じエンジンをC ABI経由でこれだけ多くのホストへ組み込む段階になると、起動レイテンシとサーバー集約度が弱点になりました。Toub氏は結論の範囲を慎重に区切っています。この取り組みは大規模なTypeScriptプログラムをすべてRust化すべきだという主張では決してなく、今回はC ABIでの組み込み、低い定常オーバーヘッド、予測可能なリソース使用という要件が際立っていたと述べました。
エージェントが書くより読む時間を費やした理由
ログには1,276万995件のイベントと185万7,409件のツール起動が記録されました。Gitの状態を調べるコマンドだけで計測上608時間を消費しています。プロンプトキャッシュのヒット率は96.22%に達し、これがなければこれほど長いセッションは費用的に成立しませんでした。
AIがコードを吐き出すという一般的なイメージは、ほぼ���だ。この規模では、作業は反復的な調査にずっと近い。
ランタイム全体に関わる3万行のファイルsession.tsの移植には、25時間のセッションを要しました。最初の編集に入るまでに56分を読解に費やし、確認のためのツール呼び出しを122回行っています。その後7波にわたって15の子セッションを立ち上げ、89件の調整メッセージをやり取りしました。モデルは得意分野に応じて割り当てられ、GPT-5.6 SolとAnthropicのClaude Opus 4.8が併用されました。
コンパイラが捕まえられなかったもの
Rustの難しさを語るとき必ず話題になる借用チェッカーは、ほとんど存在感がありませんでした。8,678件のコンパイルエラーのうち、所有権・借用・ライフタイムの問題は1.7%にとどまり、名前とインポートの解決が37%を占めています。unsafeコードは36ファイル158ブロックに収まり、その大半はC ABI、Windows API、POSIXの境界に位置していました。
問題はリグレッションでした。数十件が追跡され、多くはプレリリースチャネルで表面化し、完全に解消したのは9月14日です。内訳は未完了の移行、状態とライフタイムの問題、振る舞いの契約の不一致、ホスト境界の問題、誤ったテストの期待値に分かれます。いずれもコンパイラが判定してくれない種類のものです。モントリオールのRustConfで、コンサルタントのLisa Crossman氏はコンパイラを正解装置として扱わないよう警告しました。Rustはエージェントがメモリ安全でないコードを書くことは防げても、間違ったプログラムを正しく書くことは防げないという指摘です。Toub氏も近い見方に至り、コンパイルが通るコードは正しいコードだという言い回しは冗談としてしか使えないと述べています。
今後の見通し
比較対象になるのは、Anthropic傘下のJavaScriptランタイムBunです。開発者のJarred Sumner氏はおよそ53万5,000行のZigを、ほぼ全面的にClaudeエージェントでRustへ移しました。実験的な移植版は7月30日時点でLinux x64 glibc上のBunテストの99.8%に合格しています。ただし安定版は依然としてZigからビルドされており、Zigの作者Andrew Kelley氏はその成果物をレビューされていない粗悪品だと切り捨てました。GitHubは逆の道を選び、構造を変えずにモジュールを一対一で置き換えました。つまり本来の最適化作業はまだ始まってすらいません。この構図は、エンジニア2人で進んだOpenAIのRust書き換えとも重なります。少人数の人間、桁違いのエージェント処理量、そして残る唯一のボトルネックとしてのレビューです。
よくある質問
RustのコードはすべてAIエージェントが書いたのですか
大半はエージェントが生成しましたが、設計・レビュー・最終判断には人間が関与し続けました。セッションログでは、ユーザーメッセージ3万1,247件に対して人間が入力したのは約2,600件。おおむね12ターンに1回、人が介入した計算になります。
Rust版ランタイムはどれだけ速くなりましたか
公開されたベンチマークの一つは、クライアントを共有し100本のパイプラインを並行させて1ターンのセッションライフサイクルを1,000回計測しました。この条件でRustビルドは毎秒120回、TypeScriptは7.55回で、15.9倍の差が出ています。クライアント10台のエージェントバッチのメモリは1,383MBから126MBに下がりました。
他のTypeScriptプロジェクトもRustへ移行すべきですか
Toub氏は一般化を明確に避けています。今回Rustを選んだ根拠は、C ABI経由での組み込み、起動コストの低さ、多数のホストアプリケーションにまたがる予測可能なリソース使用でした。大半のTypeScriptコードベースには当てはまらない条件です。
