GitHubのRust移植、コード編集はわずか24時間——着手可否を分ける前提条件

誰におすすめ

数十万行規模のレガシーコードベース(モノリスや、置き換えたい言語・ランタイム)を抱える個人開発者・少人数チームのテックリードや技術責任者で、この事例を見て「エージェントを使えばうちの大規模リライトも今期やれるのでは」と考え始め、次の四半期の工数配分に乗せるかどうかを決めようとしている人。

何をすべきか

GitHubが2026年9月16日に公開した記録によれば、Copilotランタイム約43万行のTypeScriptを83万行のRustへ移植する作業で、コード編集(Editツール)にかかった時間はわずか40,591回・24.1時間だった。一方でPowerShell実行に2,833.9時間、Task実行に2,329.0時間、ファイル閲覧621.7時間・git参照608.1時間・ripgrep408.4時間(合計1,638.2時間)が費やされている——コード編集以外の操作に、編集の2桁上の時間がかかっている計算だ。ただしGitHubはこの内訳が何のための時間かを明らかにしていない。

この規模の移植が成立した土台としてGitHubが挙げるのは、17万4,675行のE2EテストとSDKの互換性を守るスキーマ破壊検知CI、そして移植中も凍結できた公開SDK呼び出し箇所(ピーク時3,356箇所、完了時0箇所)だ。GitHub自身も「あらゆる大規模TypeScriptをRustにすべきという主張では断じてない」と明記しており、ドル建てコストや請求単価、トークン消費量は「機微な情報のため意図的に開示しない」としている。

読者が判断すべきは、この記事にある「エージェントがどれだけ賢いか」ではない。自分のリポジトリに、GitHubと同じ規模の検証装置——凍結できる公開契約、数万行規模の既存テスト、CIとプレリリース配信経路——が既にあるかどうかだ。それが揃っていなければ、同じ移植を試みたときに機械が拾うはずだった契約不一致やホスト境界の見落としが、そのまま人間のレビューに戻ってくる。

注意点

• 数値はいずれもGitHub自身の非公開リポジトリに基づく自己申告であり、外部による独立検証はない(10.5%のプレリリース利用率、158個のunsafeブロックの内訳を含む)。
• 失敗事例(状態/ライフタイムのずれ、42.0対42のような契約不一致、CREATE_NO_WINDOWの見落とし、ビルド競合で人間がスケジューラ役になった経緯)も担当エンジニア本人の自己申告であり、第三者による裏付けはない。
• ドル建てコスト・請求単価・トークン消費量は意図的に非公開とされており、この記事からは採算の試算はできない。独立した論評も「移植データ・不具合分類・分析・ベンチマークはすべてGitHub自身の発表による」と指摘している。