業務で長年運用してきた基幹システムや社内ツールに手を入れる際、障害や長期停止のリスクは常に大きな課題となります。生成AIを活用したコード生成が身近になった現在でも、影響範囲の広い大規模なリファクタリングやアーキテクチャ刷新を一気に適用するのは現実的ではありません。

こうした課題に対して実践的な示唆を与えてくれるのが、2026年9月17日に公開されたGitHub公式ブログのランタイム移行記事です。GitHubはCopilot CLIや各種SDKの基盤となっているエージェントランタイムを、TypeScriptおよびNode.js環境からRustへと全面的に書き換えました。移行期間となった2026年5月から8月21日までの約14.5週間のあいだ、mainブランチの開発や出荷を継続し、135回に及ぶリリースを重ねながら、80万行を超える本番Rustコードへの移行を完了させたと報告しています。実際のシステムで停止を伴わずに移行できるかは個別の構成や検証条件によりますが、出荷可能な状態を維持する設計として参考になります。

起動負荷とプロセス境界を解消するための移行

もともとCopilotのエージェントランタイムは、Node.jsとV8 JavaScriptエンジンを基盤とするTypeScriptで構築されていました。コンソール向けツールとして迅速に開発を進める上では合理的な選択でしたが、エージェントランタイムがCLIだけでなく各種エディタや多様な言語向けSDKの基盤として広く組み込まれるにつれて、アーキテクチャ上の制約が顕在化しました。

各言語のSDKからランタイムを利用するたびに別のNode.jsプロセスを起動する必要があり、プロセス間通信のオーバーヘッドやメモリ消費（クライアントあたり約100MB以上のワーキングセット）が重なり、起動速度やサーバリソースの効率的な利用を阻んでいたとGitHubは説明しています。そこで、単一プロセス内にネイティブライブラリとして組み込めるC ABIを備え、低レイテンシかつ省メモリで動作するRustへの移行が決定されました。

一括切替を避け、薄いshimで置き換える段階的戦略

この移行で特筆すべき点は、移行作業のためにメインブランチの開発を止めたり、長期運用の別ブランチで一括切替（ビッグバン移行）を行ったりしなかったことです。GitHubは既存コードを部分ごとに段階的に置き換える「in-place」方式を採用しました。

具体的には、移行対象のコンポーネントごとに、既存のTypeScript実装をRustを呼び出す薄いshim（中継層）へと置き換え、旧コードをその場で削除する変更をプルリクエスト単位で実施しました。移行期間中にマージされたプルリクエストは128件にのぼり、mainブランチからはプレリリース100回、安定版35回を含む計135回のリリースの出荷が継続して行われました。1回あたりの変更範囲を小さく保ち、実環境に近い経路で検証を重ねることで、問題が発生した場合でも原因の特定を直前の変更単位に絞り込める構成をとっています。

AIが実装を担い、人間が問題設定と品質ゲートを管理する

この取り組みではAIエージェントが大半のコード作成を担ったとされていますが、エンジニアの役割が不要になったわけではありません。発表者自身の自己報告によれば、自身の役割は構文を直接書く作業から、問題の枠付け、境界設定、品質ゲートの運用、例外事項の判断へと移行していたと説明されています。

セッションログの分析では、コンパイラによるチェックで検出されたエラーの多くは名前解決や型の不一致といった機械的な接続ミスであり、静的型付けによる素早いフィードバックループがAIの実装速度を支えていたことが示されています。一方で「コンパイルが通るコードが仕様上正しいとは限らない」という点も強調されています。数値型の解釈の違い（整数の識別子が浮動小数点数として扱われるなど）や、JavaScriptの暗黙的な動作（タイムゾーン処理や空文字列の扱い）の抜け漏れなど、コンパイラをすり抜けるセマンティクス上の不整合は実際に発生しており、人間による受入確認と意図の明確化が不可欠でした。

受入確認を支えるE2Eテストの存在

小さな変更を安全に取り込み続けるための決定打となったのが、変更ごとに実行されるE2E（エンドツーエンド）テストでした。GitHubでは、CLIやSDKにまたがる既存のE2EテストスイートをRustコードに対しても毎回実行し、必須テストが失敗したプルリクエストはmainへ取り込まない運用を徹底しました。

変更単位ごとに業務フロー全体の整合性を確かめる重要性は、他社の品質改善の取り組みでも共通しています。たとえば品質ゲート設計の補足となるShopifyのE2Eテスト基盤に関する解説記事では、同社のモバイルアプリを対象に、操作ごとのアサーションと視覚的要素検出を組み合わせた基盤へ移行した結果、個別テスト成功数を総実行数で割る指標において98%の安定性を得られたと自己報告しています。これはGitHubのランタイム移行自体の成果値ではありませんが、AI支援によってコード生成の速度が上がるほど、実装の内部構造だけでなく利用者の操作フローが保たれているかを自動で検証できる品質ゲートの価値が高まります。

既存システムの改修を検討する企業への示唆

今回のGitHubの事例は特殊な言語移行に見えるかもしれませんが、設計思想そのものは一般的な業務システムの改修にも応用できます。たとえば、既存の受発注管理システムにおいて通知処理を別のマイクロサービスや新コンポーネントへ段階的に切り出すような場面を考えてみます。

いきなり全体のアーキテクチャを一括刷新しようとすると、停止リスクが高まり検証工数も膨らみます。ただし、GitHubのように旧コードを即座に削除しながら進める原子的置換がすべての環境に適するとは限らず、対象システムの前提や要件に応じた判断が必要です。実務では、まず業務の利用フローに沿って変更対象を機能単位で分割し、既存テストで受入確認ができる境界を明確にすることが出発点となります。

その上で、GitHubが採用した原子的置換と旧コード削除の方式をとるか、依存関係や切戻し要件に応じて新旧実装を切り替え可能に保つ二重構造とするかは、既存テストの網羅性やシステムの制約に照らして判断します。あわせて、仕様の整合性や権限管理、例外発生時の処理、障害時の切戻し手順について、人間が責任を持って判断するレビュー体制をあらかじめ定めておくことが重要です。

AI支援ツールを活用して改修を進める場合でも、ツールにすべてを委ねるのではなく、どの業務単位で切り離し、どのようなテストで安全性を保証するかという事前の境界設計が成否を分けます。

既存システムのAI活用と段階移行のご相談

社内で長年使われている業務システムやWebサービスを段階的に見直したいものの、何から手をつければよいか迷うケースは少なくありません。影響範囲が広がるほど、技術的な実装だけでなく、業務フローのどこを切り出してどのような順序で進めるかという整理が重要になります。

デノフのサービス案内では、Webシステム開発や業務システムの設計・運用保守に加え、中小企業向けのAI導入支援や業務自動化の構築を一貫して提供しています。個別のシステム構成や運用環境に合わせ、業務への影響や変更範囲を考慮した境界設計、AI支援開発における変更単位の検討などについてご相談いただけます。具体的な進め方にお悩みの方は、デノフへの相談窓口よりお気軽にお問い合わせください。