Copilotの80万行Rust移植で正しさの基準になったE2Eテスト

Stephen Toub（Microsoft の Distinguished Engineer）, “Migrating the GitHub Copilot runtime to Rust, using Copilot”, GitHub Blog, 2026年9月16日公開。GitHub（Microsoft 傘下）のCopilotエージェントランタイムをRustへ書き換えた記録である。「もとはTypeScript、Node.js、V8 JavaScriptエンジンの上に書かれていた」(“It was originally written in TypeScript on Node.js and the V8 JavaScript engine”)と書き、「ランタイムを80万行を超える本番用Rustへ完全に書き直した。コードの大半はAIエージェントが書き、128件のプルリクエストにまたがってmainへ入り、最後に一度で切り替えるのを待つのではなく段階的に出荷された」(“we completely rewrote the runtime into more than 800,000 lines of production Rust. AI agents wrote most of the code, spanning 128 pull requests that landed in main and shipped incrementally rather than waiting for a single cutover at the end.”)と書く。人員規模については「エージェント以前ならチーム全体で1年か2年かかっていたはずのプロジェクトを、いまは主に一人の開発者が、わずか数か月で完了させた」(“A project that would have taken a whole team of developers a year or two before agents was now completed primarily by a single developer, in only a few months”)と書く。層構造については「実用的な判断として、SDKをCLIの上に重ねる構成を選んだ。論理的には逆の構成が期待されるにもかかわらずである」(“a pragmatic decision was made to layer the SDK on top of the CLI, even though logically you’d expect the inverse architecture”)、組み込みの費用については「最低でもクライアントあたり100MB程度のワーキングセット」(“on the order of 100 MB of working set minimum”)、「それはNodeのクラッシュがセッションを道連れにすることを意味した」(“It meant a crash in Node took the session with it.”)と書く。限定として「これは、あらゆる大きなTypeScriptプログラムがRustになるべきだという主張ではまったくない」(“This is in no way a claim that every large TypeScript program should become Rust.”)、「適切な移行先言語は、アプリケーションごとに正当に変わる」(“The right target language legitimately varies from application to application.”)と書く。移植後の形については「結果として、全ての言語フロントエンドがプロセス内で利用できるC ABIを公開する、純粋なネイティブバイナリになった」(“resulting in a pure native binary exposing a C ABI for in-process consumption by all the language front-ends”)、行数については「移植を通過した本番用TypeScriptは、おおよそ43万行と見積もっている」(“I estimate approximately 430,000 lines of production TypeScript ended up passing through the port.”)と書く。手順については「ランタイムのmainブランチは常に出荷可能である。各プルリクエストは、既存のTypeScript実装を、Rustを呼び出す薄いシムに置き換え、古いコードを一つの原子的な変更の中で削除する」(“The runtime’s main branch is always shippable. Each pull request replaces the existing TypeScript implementation with a thin shim that calls into Rust, and deletes the old code in one atomic change.”)と書く。一括切替には「全員がmainでの他の作業を止め、書き直しをmainで行う」(“Everyone ceases other work on the main branch while the rewrite happens, with the rewrite being done in main.”)形と、「書き直しをフィーチャーブランチで行い、mainでは作業が続く」(“The rewrite happens in a feature branch while work continues in the main branch”)形があるとし、部品置換の原子的な置き換えを「さまざまな理由で選んだ」(“We went with option 2a, for a variety of reasons:“)として「誰も作業の停止を経験しない」(“No one experiences work stoppage.”)、「書き直しは段階的でレビューしやすい」(“The rewrite is incremental and reviewable.”)と挙げ、「プルリクエストが必須のテストを落とせば、それは入らなかった」(“If a pull request caused a required test to fail, it didn’t land.”)と書く。新旧の版を並べて保守する形を避けた理由については「同じ部品の複数の版を同時に保守する2bの変種も避けた」(“We also shied away from the option 2b variant that involved maintaining multiple versions of the same component concurrently.”)、「ここ数か月、毎週数百件のプルリクエストがリポジトリにマージされ続けている中で」(“With hundreds of pull requests being merged into the repo per week for the last several months”)、「「両方を走らせて比べる」は、その部品の食い違っていく二つの写しを保守することを意味する」(““run both and compare” would mean maintaining two divergent copies of the component”)、「このように切り替えられることの利点は主に確信を得ることにあり、それは他の方法でも得られる」(“The benefits of being able to swap in this manner are primarily about gaining confidence, which we could do in other ways.”)と書き、続けて「検証は段階的な展開によっても行われた」(“Validation also happened through incremental rollout.”)、「実際の利用者の使用（多くはMicrosoftとGitHubの社内）を伴う配布版で、最後の区間の検証を得られた」(“enabled us to get a last-mile of validation in deployed builds with real consumer usage (most often first-party within Microsoft and GitHub)”)、「およそ14週半の移植期間に、mainは135のリリースを出した。うち100は先行版、35は安定版である」(“Over the roughly fourteen-and-a-half-week porting window, main shipped 135 releases, inclusive of 100 pre-release versions and 35 stable versions”)と書く。レビューに使わせた指示（rust-rebase-review）については「ハーネスがこのスキルを工程の適切な時点で呼ぶよう促し、ときどき手でも呼んだ」(“I encouraged the harness to invoke this skill at appropriate points in the process, and also manually invoked it from time to time.”)とし、その一項目に「E2Eテストが削除も変更もされていないことを確かめよ。そうした変更は移植の不具合の兆候である」(“Validate that no E2E tests have been deleted or changed. Such changes are an indication of a porting bug.”)がある。移植の順序については「計画は続けて、作業を葉から内側へ順序づけた」(“The plan continued by ordering the work from the leaves inward”)、「セッション編成は終盤に来ることになる」(“would come near the end”)と書く。退行の具体化については「これらの型は、繰り返し現れる少数のパターンでより具体的になる」(“Those families become more concrete in a handful of recurring patterns:“)と書く。退行については「2026年9月14日までに、数十件の既知の移植退行を追跡し、すべて修正した」(“By September 14, 2026, we’d traced dozens of known port regressions, all fixed.”)、三つの型については「正しさに関する退行のほぼ全ては三つの大きな型に分類される。新しいコードが違う挙動契約を実装した場合、状態・所有・寿命の挙動が変わった場合、あるいは移植の一部が省かれたか、部分的にしか適用されなかったか、rebaseで失われた場合である」(“Nearly all of the correctness regressions land in three large families: the new code implemented a different behavioral contract; state, ownership, or lifetime behavior changed; or some part of the migration was omitted, only partially applied, or lost in rebasing.”)と書く。具体例として「TypeScriptは数値型を一つしか持たないが、Rustはいくつかの型から選ぶことを要求する」(“TypeScript has one number type; Rust requires choosing among several”)、「JavaScriptの||は空文字列を置き換えるが、Rustのunwrap_orは空文字列を保持する」(“JavaScript’s || replaces an empty string; Rust’s unwrap_or preserves it”)、「最大の塊は、ライフサイクル、破棄、所有権、順序、または競合に関わるものだった」(“The largest cluster involved lifecycle, disposal, ownership, ordering, or races.”)と書く。費用については「移植作業全体でのトークン消費は、合計でおよそ1,363億トークンであり、うちおよそ1,306億がキャッシュされた入力読み込みトークンだった」(“My token spend for all of the porting work was ~136.3 billion total tokens, including ~130.6 billion cached input read tokens”)、「それらすべてのトークンの金銭的な請求額はおよそ12万ドルになった」(“The monetary bill for all those tokens came to ~$120,000.”)、「それはおよそ3週間を移植に充てた計算になる」(“that works out to roughly three weeks dedicated to the port”)と書き、「とはいえ、Rustへの移行の全体は100%一人の開発者ではなかった。チームの仕事である」(“That said, the end-to-end Rust migration was not 100% a single developer; it’s been a team effort.”)と断る。教訓については「エンドツーエンドテストは、絶対に、疑いなく重要である」(“End-to-end tests are absolutely, unequivocally critical.”)、「そのテスト自体を移植の途中で書き換えることはできない。さもなければオラクルを失う」(“those tests can’t themselves be re-written during the porting, or else you lose your oracle”)、「オラクルをエージェントから守れ」(“Protect the oracle from the agent.”)、「実装を変えるエージェントに、テストを弱め、スナップショットを更新し、互換性の基準値を引き上げ、あるいは逃げ道のラベルを付けることで正しさを黙って再定義することを許してもならない。少なくとも監督なしには」(“The agent changing an implementation cannot also be allowed to silently redefine correctness by weakening a test, updating a snapshot, raising a compatibility baseline, or applying an escape-hatch label, at least not without oversight.”)、「挙動の契約はできる限り独立に保ち、要所のガードレールは別の所有または承認の下に置き、故障モードの異なる検査を重ねて、一つの誤りでは大きな退行を出荷するに足りないようにせよ」(“Keep the behavioral contract independent where possible, put sensitive guardrails behind separate ownership or approval, and layer checks with different failure modes so that one mistake isn’t enough to ship a big regression.”)、「まず翻訳し、設計をやり直すのは二番目にせよ」(“Translate first, redesign second.”)と書く。実例として「エージェントの応答は、リポジトリのschema-break-ok自動化ラベルを付けることだった。それは検査を通すための逃げ道である」(“The agent’s response was to apply the repo’s schema-break-ok automation label, which is the escape hatch to make the check pass.”)、「問題なくはなかった。そのメソッドはmainに存在しており、移植が単に落としていた」(“It wasn’t. The method existed on main; the port had simply lost it.”)、「ある移植はSDKのコールバックを省き、そのエンドツーエンドテストを削除したため、エージェントは明示的な同意なしにE2Eテストを変えてはならないという新しい規則ができた」(“One port omitted SDK callbacks and deleted their end-to-end test, prompting a new rule that agents must not change E2E tests without explicit consent.”)と書く。E2Eテストの準備については「一つの例外を除き、欠けた機能に関わる退行の全てと、その他の多くは、十分なエンドツーエンドテストの不足によるものだった」(“With one exception, all of the regressions that involved missing features, and many of the others, were due to lack of sufficient end-to-end tests.”)、「我々はそれをやったが、十分にはやらなかった」(“We did that, but we didn’t do it enough.”)と書く。三つの型の直後には「少数は、ホストまたは相互運用境界の要件から、さらには誤った挙動を自信をもって検証したテストからも生じた」(“A smaller set came from requirements at the host or interop boundary, and even from tests that confidently validated the wrong behavior.”)、退行の全体像については「知られているもの以外にもあることを100%確信している」(“I’m 100% sure there are more than the ones we know about.”)、「製品向けのissueチャネルは、移行の間に意味のある品質懸念の急増を示さなかった」(“the product-facing issue channels didn’t show a meaningful quality concern spike during the migration”)と書き、bugラベルか失敗語を題に持つissueの比率をcopilot-cliで「22.9% (454 / 1,982)」（1〜4月）→「23.7% (354 / 1,496)」（5〜8月）、copilot-sdkで「36.2% (190 / 525)」→「32.3% (135 / 418)」と表にする。プロセス内の形については「これらのプロセス内の入口は、消費側アプリケーションとプロセスを、したがって故障境界を共有することに自信がつくまで、現在は選択制である」(“Those in-process entry points are currently opt-in while we gain confidence in sharing a process, and therefore a failure boundary, with the consuming application.”)と書く。結びとして「エージェントは、一人のエンジニアが監督できるコードの量を変えた。エージェントは、システムを理解し、方向性、ガードレール、リリースを保証できるエンジニアの必要性を無くしはしなかった」(“The agents changed the amount of code one engineer could supervise. They did not remove the need for an engineer who understood the system and could vouch for the direction, the guardrails, and the release.”)と書く。https://github.blog/ai-and-ml/generative-ai/migrating-the-github-copilot-runtime-to-rust-using-copilot/ ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶ ↩⁷ ↩⁸ ↩⁹ ↩¹⁰ ↩¹¹ ↩¹² ↩¹³ ↩¹⁴ ↩¹⁵ ↩¹⁶ ↩¹⁷ ↩¹⁸ ↩¹⁹ ↩²⁰ ↩²¹ ↩²² ↩²³ ↩²⁴ ↩²⁵ ↩²⁶ ↩²⁷ ↩²⁸ ↩²⁹ ↩³⁰ ↩³¹ ↩³² ↩³³ ↩³⁴ ↩³⁵ ↩³⁶ ↩³⁷ ↩³⁸ ↩³⁹ ↩⁴⁰ ↩⁴¹

METR, “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity”, 2025年7月10日公開。経験豊富なオープンソース開発者を対象にしたランダム化比較試験(RCT)である。「早期2025年のAIツールが、自分自身のリポジトリで作業する経験豊富なオープンソース開発者の生産性にどう影響するかを理解するため、ランダム化比較試験(RCT)を実施する」(“We conduct a randomized controlled trial (RCT) to understand how early-2025 AI tools affect the productivity of experienced open-source developers working on their own repositories.”)と書き、「開発者がAIツールを使うと、使わない場合より19%長くかかることが分かった」(“we find that when developers use AI tools, they take 19% longer than without”)と報告する。対象は「大規模なオープンソースリポジトリから16名の経験豊富な開発者を集めた」(“we recruited 16 experienced developers from large open-source repositories”)、課題数は「246件」(“246 total”)である。開発者本人の見立てについては「開発者はAIが24%速くすると予想しており、遅くなったことを経験した後でさえ、AIによって20%速くなったとなお信じていた」(“developers expected AI to speed them up by 24%, and even after experiencing the slowdown, they still believed AI had sped them up by 20%“)と書く。METR自身の限定として「この結果を、ある一つの関連する状況における早期2025年のAI能力のスナップショットとみなしている」(“We view this result as a snapshot of early-2025 AI capabilities in one relevant setting”)と書く。https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/ ↩ ↩²

METR, “We are Changing our Developer Productivity Experiment Design”, 2026年2月24日公開。実験設計の変更を告知する記事である。「新しい実験からのデータは、AIツールの現在の生産性効果について信頼できない信号を与えると考えている」(“we believe that the data from our new experiment gives us an unreliable signal of the current productivity effect of AI tools”)と書き、理由として「AI無しで働くことを望まないという理由で、研究に参加しないことを選ぶ開発者が大きく増えたこと」(“a significant increase in developers choosing not to participate in the study because they do not wish to work without AI”)、「複数のAIエージェントを同時に使う開発者の割合について、各課題にかけた時間の測定が信頼できないこと」(“our measurements of time-spent on each task are unreliable for the fraction of developers who use multiple AI agents concurrently”)を挙げる。それでも「いま(2026年初頭)において、開発者は2025年初頭の我々の推定よりもAIツールによって速くなっている可能性が高いと考えている」(“we believe it is likely that developers are more sped up from AI tools now — in early 2026 — compared to our estimates from early 2025”)と書く。ただし「しかし、実験の選択効果のため、我々のデータはこの増加の大きさについてごく弱い証拠でしかない」(“However, because of the selection effects in our experiment, our data is only very weak evidence for the size of this increase.”)と限定する。偏りの向きについては「AI無しで働くことを望まない開発者の不参加は、AIによる高速化の推定を下向きに偏らせる可能性が高い」(“which likely biases downwards our estimate of AI-assisted speedup”)、「これらの効果により、上で報告した推定は、これらの開発者に対するAIの真の生産性効果の下限である可能性が高い」(“these effects make it likely that our estimate reported above is a lower-bound on the true productivity effects of AI on these developers”)と書く。同じ段落は前年の結果を「2025年初頭の研究では、AIの使用で課題に19%長くかかり、信頼区間は+2%〜+39%だった」(“Our early 2025 study found the use of AI causes tasks to take 19% longer, with a confidence interval between +2% and +39%.”)と所要時間の増減で並べたうえで、生の推定を「元の研究の開発者のうち後の研究にも参加した部分集合について、いまは−18%の高速化（信頼区間 −38%〜+9%）と推定する。新たに募集した開発者では推定される高速化は−4%（信頼区間 −15%〜+9%）である」(“For the subset of the original developers who participated in the later study, we now estimate a speedup of -18% with a confidence interval between -38% and +9%. Among newly-recruited developers the estimated speedup is -4%, with a confidence interval between -15% and +9%.”)と示す。報酬は「$150/時から$50/時へ引き下げた」(“we reduced the pay from $150/hr to $50/hr”)と書く。https://metr.org/blog/2026-02-24-uplift-update/ ↩ ↩² ↩³ ↩⁴ ↩⁵ ↩⁶

Stoyan Nikolov ほか, “How is Google Using AI for Internal Code Migrations?”, ICSE-SEIP 2025（2025 IEEE/ACM 47th International Conference on Software Engineering: Software Engineering in Practice）pp.481–492, DOI 10.1109/ICSE-SEIP66354.2025.00048。arXiv:2501.06972 v1（2025年1月12日）が公開版である。Google社内のコード移行にLLMを使った経験談である。「本稿はGoogleにおけるコード移行へのLLM利用に関する経験報告である。研究ではない」(“This article is an experience report on using LLMs for code migrations at Google. It is not a research study”)と自ら限定し、「LLMの利用が移行に要する時間を大きく減らし、移行プログラムを始めて完了させる障壁を下げるという証拠を見ている」(“We see evidence that the use of LLMs can reduce the time needed for migrations significantly, and can reduce barriers to get started and complete migration programs.”)と書く。工程については「専門家が起動するLLMベースの移行ツールキットが自律的に走り、単体テストを通るコードだけを含む検証済みの変更を生む。必要なら、コードの変更を反映するためにテストも更新される」(“An LLM-based migration toolkit, triggered by an expert, runs autonomously and produces verified changes that only contain code that passes unit tests. When necessary, tests are also updated to reflect the changes to the code.”)、「同じ技術者がその変更を手で確認し、モデルが失敗したか誤った箇所のファイルを必要に応じて更新する。変更は分割され、影響を受ける部分のコードベースを所有する複数のレビュアーへ送られる」(“The same engineer then manually checks the change and potentially updates files where the model failed or made a mistake. The changes are then sharded and sent to multiple reviewers who own the part of the codebase affected by the change.”)と書く。int32→int64のID移行については「着地したCLのコード変更の80%は完全にAIが書いたものであり、残りは人が書いたか、AIの提案から編集したものだった」(“We found that 80% of the code modifications in the landed CLs were fully AI-authored, and the rest were human-authored or edited from the AI suggestions.”)、「移行に費やした総時間は、移行を行った技術者の報告によれば、LLMの支援なしに行った同様の作業と比べて推定50%減った」(“The total time spent on the migration was reduced by an estimated 50% as reported by the engineers doing the migration, when compared to a similar exercise carried out without LLM assistance.”)と書く。LLM以前からの機械的な手段については「Googleのモノレポ規模では、大規模変更のための特別な基盤が使われてきたし、いまも使われている」(“At Google’s monorepo scale, special infrastructure for large-scale changes [26] was, and still is used.”)、「その基盤は静的解析と、Kythe、Code Search、ClangMRのようなツールを使う」(“That infrastructure uses static analysis and tools like Kythe [16], Code Search [26] and ClangMR [5].”)と書く。https://arxiv.org/abs/2501.06972 https://doi.org/10.1109/ICSE-SEIP66354.2025.00048 ↩ ↩² ↩³ ↩⁴ ↩⁵