GitHub CopilotランタイムをRustへ移植、80万行超をAIエージェントが主導

何が発表されたのか

GitHubは2026年9月17日、CopilotエージェントランタイムをRustへ書き直したとブログで説明した。このランタイムは、GitHub Copilot CLI、GitHub Copilotアプリ、GitHub Copilot SDKに共通する土台であり、アプリケーションやサービスに組み込めるエージェント実行基盤(エージェントハーネス)と位置づけられている。もともとはTypeScriptで、Node.jsとV8 JavaScriptエンジン上に実装されていた。移植後のコードは80万行を超えるプロダクションRustで、その大半をAIエージェントが書いたという。

変更は128件のプルリクエストとしてmainブランチに取り込まれ、最後に一括で切り替えるのではなく段階的に出荷された。避けられなかった少数の回帰は、その都度すばやく発見・修正されたとしている。ブログでは、エージェント以前なら開発者チーム全員で1〜2年かかったであろうプロジェクトが、主に1人の開発者によって数カ月で完了したと述べられている。その間、チームの他のメンバーはランタイムの機能拡張を続けていたという。

なぜRustへ移植したのか

ランタイムはCopilot CLIだけを支えているわけではない。VS CodeやVisual Studio、CCA(Copilot cloud agent)、Copilot Code Review(CCR)、Copilot Cowork、Copilot Studio、そしてExcel、Outlook、PowerPoint、Wordなど、Microsoft・GitHub・エコシステムの多数の製品が同じランタイムを土台にしている。各製品は独自のエージェントループを実装するのではなく、ランタイムへの入り口であるGitHub Copilot SDKを使う形に置き換えてきた。

問題は、共有する対象であるランタイムの作りにあった。SDKは当初、論理的には逆であるべき構造、つまりランタイムの上にCLIが載る構造ではなく、CLIの上にSDKを重ねる形で作られた。SDKから利用するたびにCLIが子プロセスとして起動され、JSON-RPCで関数呼び出しをやり取りする仕組みだった。そのためC#、Python、Go、Java、Rustなど各言語のSDKは、クライアントごとにNode.jsやV8を含むバイナリを同梱する必要があり、最小でも約100MBのワーキングセットを要したという。

Rustを選んだ理由と移植手法

Rustが選ばれた理由として、依存とオーバーヘッドが小さいこと、C ABI経由でインプロセスに埋め込めること、起動時や常時稼働時の負荷が小さくリソース使用を予測しやすいこと、6種類のSDK言語からFFIで扱いやすいこと、サプライチェーンリスクの小さいツールチェーンが使えることが挙げられている。一方で、すべての大規模TypeScriptプログラムをRustにすべきだという主張ではないとも明記されている。

移植は、新実装を完成させてから一括で切り替える「ビッグバン」ではなく、コンポーネントごとにTypeScriptからRustへ原子的に置き換える「インプレース」方式で進められた。mainブランチは常に活発なままで、常に出荷可能な状態が保たれたとしている。各プルリクエストの変更範囲が1つのコンポーネントやスライスに限定されるため、差分のレビューもしやすかったという。

規模の見積もりと残る課題

当初の移植計画は2026年5月初旬に立てられ、ランタイムは約13万行のTypeScriptと見積もられていた。しかし移植と並行してTUI層からランタイム層へ押し下げられるコードがあり、さらに週に数百件のプルリクエストが新規TypeScriptを追加し続けた。結果として、約43万行のプロダクションTypeScriptが移植を通過したと推定されている。移植期間中、ランタイムは約30万行のTypeScriptを取り込み約43万行を削除し、Rustは約120万行が入り約36.5万行が削除されたという。

ブログは、CLIが今もランタイムの内部を直接呼び出している箇所が複数あり、SDKの公開サーフェス上に完全に移す作業は継続中だとしている。TUIとランタイムを分離する作業も進行中で、今回の記事が主に扱うのはランタイムの移植である。1人の開発者とAIエージェントで数カ月という期間で完了したとされるが、使用したモデルや具体的な運用手順は本文では示されていない。同じ進め方が他の組織でそのまま再現できるかは、現時点では判断できない。