GitHubは、GitHub Copilot CLI、Copilotアプリ、Copilot SDKの基盤となるランタイムを再構築した。以前はTypeScript、Node.js、V8エンジンに依存していた。GitHubのブログに掲載された記事によると、その結果、プロダクション向けに作られたRustコードは80万行を超え、その大部分はAIエージェントの支援を受け、メインブランチに段階的にマージされた128件のプルリクエストによって完成した。
著者によると、この作業は数か月で、主に1人の開発者が担当して完了した。その間もチームの他のメンバーはランタイムの機能開発と利用範囲の拡大を続けていた。GitHubは移行後にパフォーマンスが「大幅に」向上したとしているが、記事の公開部分では、この改善を測定するための詳細な数値は示していない。
問題はコマンドラインインターフェースだけではなかった
CopilotランタイムはCLIの実行だけに使われるものではない。GitHub Copilot CLI、Copilotアプリ、Copilot SDKに加え、VS Code、Visual Studio、Cloud Agent、Copilot Code Review、Copilot Cowork、Copilot Studio、Excel、Outlook、PowerPoint、Wordの各アプリケーションなど、複数のバージョンや製品が共有するレイヤーである。
以前の設計では、ランタイムとCLIの結び付きが非常に強かった。製品がプログラムからアクセスする必要が生じた際には、SDKは実質的にCLIの上に構築され、Node.jsプロセスを別途起動して、JSON-RPC経由で通信していた。この方式は迅速で柔軟だった一方、利用する各アプリケーションに運用上のコストを課していた。
新しいCopilotClientを作成するたびに、Node.jsとV8をホストするプロセスの追加起動、TypeScriptから生成されたJavaScriptコードの解析、エンジンに関連するメモリの負担が発生した。また、Node.jsのクラッシュによってセッションが終了する可能性があり、アプリケーションは少なくとも2つのプロセスを監視する必要があった。記事によると、C#、TypeScript、Python、Rust、Go、Javaで書かれたSDKパッケージは、ほかの用途でNode.jsを必要としていない場合でも、追加ランタイムだけでワーキングセットに最低約100メガバイトのメモリを負担していた。
なぜRustが選ばれたのか
GitHubは新しいレイヤーについて明確な目標を定めた。ランタイムをTUIから分離すること、依存関係と運用コストを削減すること、同一プロセス内への組み込みを可能にすること、スケーラビリティと信頼性を向上させることだった。さらに、異なるFFI機構を通じて6種類のSDKからランタイムを利用できるC ABIも必要だった。
記事によると、Rustはこれらの要件の実現に役立ったほか、より新しいセキュリティ体制を支援するツールチェーン、サプライチェーンリスクの低減、設計上正しいコードをより多く支援する仕組みも提供した。ただし同時に、この経験はすべての大規模なTypeScriptプロジェクトをRustへ変換することを推奨するものではないと強調している。この選択は、起動時間、メモリ、組み込み、リソース消費の予測可能性に関する具体的な要件から導かれたものだった。
全面的な書き換えではなく段階的な置き換え
GitHubは、長期間存続するブランチや、最後に一度だけ変換するプロセスによってプロジェクトを実行しなかった。メインブランチ上で、各TypeScriptコンポーネントを個別にRustコンポーネントへ置き換える方式を選んだ。各プルリクエストでは、Rustを呼び出す薄いバインディング層を追加すると同時に、同じ変更の中で古い実装を削除した。そのため、ブランチは出荷可能な状態を保ち、新しいコードをシステム内で直接テストできた。
- プロジェクトを停止することなく、ほかの開発者による通常の作業を継続できた。
- 全面的な書き換えよりも、各変更が小さくなり、レビューしやすくなった。
- 各ステップでCLIとSDKのエンドツーエンドテストを実行した。
- リグレッションを移行中に発見して修正でき、最終的な切り替え時まで先送りしなかった。
GitHubはまた、各コンポーネントについて2つのバージョンを長期間並行して維持することも避けた。リポジトリでは毎週数百件のプルリクエストが発生しており、2つの言語による2つの実装と依存関係の集合を維持すれば、複雑性が増していた。可変状態を管理するコンポーネント、たとえばセッションのフォーマットでは、コールバックを扱い、システムの広い部分に接続するため、2つのバージョンを比較することがさらに難しくなる。
数字が示すもの
初期の見積もりは2026年5月時点で約13万行のTypeScriptだったが、実際の作業量を反映していなかった。TUIレイヤーに含まれると考えられていたコンポーネントが後にランタイムへ移され、移行と並行して新しいTypeScriptコードも追加され続けたためである。その結果、実際には約43万行のTypeScriptが移行作業の対象となった。
同じ期間に、約30万行のプロダクション用TypeScriptがプロジェクトに追加され、約43万行が削除された。一方、約120万行のRustが追加され、約36万5,000行が削除された。これらの数字は、リポジトリ上で見えるTypeScriptの規模が安定していたからといって進展がなかったわけではなく、追加、削除、責任範囲の再配置が大規模に行われていたことを示している。
なぜこのニュースが重要なのか
この取り組みの実務的な価値は、Rustを使ったことだけにあるのではない。多数の製品が共有する基盤レイヤーの書き換えを管理した方法にある。各コンポーネントをアトミックに置き換え、ブランチを出荷可能な状態に保ちながら継続的にテストを実行することで、「ビッグバン型の移行」のリスクを抑え、ロールバックや問題箇所の特定を明確にできる。
一方で、この記事はこの方式がすべての組織に適していることや、AIエージェントだけでこの規模の書き換えの品質を保証できることを証明しているわけではない。また、公開されている部分では、移行前後の消費量に関する測定値や、レビュー、テスト、リグレッション対応にかかった人的コストの詳細も示されていない。したがって、最も明確な教訓は、Rustやエージェントをあらゆる移行の一般的な解決策とみなすことではなく、段階的なエンジニアリングとレイヤー分離に関するものだ。