From Translation to Superset: Benchmark-Driven Evolution of a Production AI Agent from Rust to Python

本論文は、LLM 支援による継続的なコード翻訳と公開ベンチマークを目的関数とした反復改善手法を用いて、64 万行の Rust 製 AI エージェント「Codex CLI」を 4 万行の Python へ移行し、機能の拡張とパフォーマンスの維持を両立させたことを報告するものです。

要約

この論文は、**「巨大で複雑なロボット（Rust 製）を、もっと手軽で柔軟なロボット（Python 製）に作り変える実験」**について書かれています。

金融大手の JP モルガン・チェースのチームが、自分たちが開発している「AI コーディングエージェント（コードを書く AI 助手）」を、元々使っていた堅牢な言語「Rust」から、AI 界で主流の「Python」へと完全に移植したという物語です。

以下に、専門用語を避け、身近な例え話を使って解説します。

---

1. 物語の舞台：堅固な城と、自由なキャンバス

• 元のシステム（Rust）：
  これは**「頑丈な城」**のようなものです。壁は厚く、設計図（型）が厳格で、崩れることはまずありません。しかし、城を改築するには大工（開発者）が特別な資格を持ち、長い時間がかかるため、新しい機能を追加するのが大変でした。
• 新しいシステム（Python）：
  これは**「自由なキャンバス」**のようなものです。すぐに描き足せるし、消しゴムも効きます。AI 業界ではこの言語が主流なので、新しい道具（ライブラリ）も手に入りやすく、多くの人が参加しやすい環境です。

課題：
「城」を「キャンバス」に作り変えるのは、単に壁を壊してキャンバスを貼るだけではダメです。**「元の城ができていたこと（タスク）を、新しいキャンバスでも同じように完璧にこなせるか」**が問われました。

2. 魔法の翻訳者（LLM）と、厳しすぎるテスト

チームは、巨大な言語モデル（LLM）という「魔法の翻訳者」を使って、城の設計図をキャンバスの絵柄に翻訳させました。

• 従来の方法：
  「この壁はここにあるはずだ」という**「単体テスト（チェックリスト）」**で確認するだけ。

• この論文のすごい方法：
  **「実戦テスト（ベンチマーク）」を「物差し」**として使いました。
  翻訳が終わるたびに、AI に「80 個の難しい問題（ターミナル操作やコード修正）を解かせて、何個正解したか」を測ります。

  • 発見： チェックリストは完璧でも、実戦では「AI が壁を叩き壊して失敗する」ことがありました。
  • 例え： 「料理のレシピ（コード）は完璧に翻訳されたのに、実際に火にかけると（実行すると）鍋が焦げてしまう」。これは、レシピの翻訳ミスではなく、「火加減の感覚（環境設定や API の仕様）」の違いだったのです。
  • 結果： 実戦テストの結果を元に「ここが焦げてるから直そう」と繰り返すことで、Python 版は Rust 版とほぼ同じ性能（70%〜74% の正解率）を達成しました。

3. 驚きの結果：「同じ性能」を超えて「スーパーパワー」へ

ここがこの論文の最大のハイライトです。

通常、言語を乗り換えるのは「同じことを同じようにやる」のがゴールです。でも、Python 版は**「元の城にはなかった超能力」**まで手に入れてしまいました。

• コードの縮小：
  Rust 版は64 万行のコードが必要でしたが、Python 版は4 万行で済みました。
  • 例え： 64 万ページの分厚い辞書で説明していたことが、4 万ページのスマートなマニュアルになったようなもの。約16 倍もシンプルになりました。
• 新機能の追加：
  Python 版には「マルチエージェント（複数の AI がチームで働く）」「音声モード」「コスト管理」など、Rust 版にはない30 種類もの新機能が追加されました。
  • 仕組み： これらは「スイッチ」でオンオフできます。スイッチを切れば「元の城と同じ性能」を比較でき、スイッチを入れれば「未来のスーパーロボット」になります。

4. なぜ Python でよかったのか？（ボトルネックの逆転）

「Rust は速いのに、なぜ遅い Python ？」という疑問が湧くかもしれません。

• ボトルネックは「AI の思考速度」：
  このシステムで一番時間がかかるのは、AI が「考え」て返事をする時間（1 秒〜10 秒）です。
• Python の遅さは「微々たるもの」：
  Python 自体の処理速度は Rust より遅いですが、AI が考える時間と比べれば、0.1% 以下の無視できるレベルです。
• 結論：
  「AI が考える時間」が支配的な世界では、「コードが短くて書き換えやすい（Python）」ことのメリットが、「計算が速い（Rust）」ことのメリットを圧倒的に上回りました。

5. まとめ：この実験が教えてくれること

この論文は、単なるプログラミングの技術報告ではなく、**「AI 時代におけるソフトウェア開発の新しいあり方」**を示しています。

1. テストより「実戦」： 完璧なチェックリストよりも、実際に使ってみて失敗するところを直す方が、真の品質が上がる。
2. 翻訳は「進化」のチャンス： 言語を乗り換えるのは「同じものを作る」ためではなく、**「より良いものに進化させる」**ためのきっかけにできる。
3. 継続的なアップデート： 元のシステム（Rust）が毎日更新されても、AI 翻訳と実戦テストを組み合わせることで、新しいバージョンを常に追いかけていける「生きている橋」を作ることができた。

一言で言えば：
「堅固だが重い城を、軽快で自由なキャンバスに作り変えたら、同じ強さを持ちながら、さらに新しい超能力まで手に入れた」という、AI 時代の開発成功物語です。

技術概要

この論文は、JP モーガン・チェースの LLM スイートチームによって執筆され、大規模なソフトウェアシステム（ここでは AI コーディングエージェント「CODEX CLI」）を、Rust から Python へ移行する際の実践的な手法と評価結果を報告しています。

以下に、論文の技術的要点を問題定義、手法、主要な貢献、結果、および意義の観点から詳細に要約します。

1. 問題定義 (Problem)

大規模なソフトウェアシステムの言語間移行（クロスランゲージマイグレーション）は、従来の手法では以下の課題に直面していました。

• 高コストとエラー: 手動による移行は労働集約的で、バグが発生しやすい。
• 分断と保守性の欠如: 移行が完了すると、ソース（Rust）とターゲット（Python）は永続的に分断される。ソース側での変更（アップストリーム）をターゲット側に反映させるには、手動での再移行が必要となり、特にアップストリームが毎日更新されるような高速なプロジェクトでは維持が困難。
• 検証の限界: 単なる構文変換やユニットテストだけでは、エンドツーエンドの動作や実世界のタスクにおける機能同等性を保証できない。

2. 手法 (Methodology)

著者らは、**「LLM 支援による継続的なコード翻訳」と「ベンチマークを目的関数とした反復的改善」**という新しいアプローチを提案しました。

• LLM 支援翻訳: 大規模言語モデル（LLM）を翻訳エンジンとして使用し、Rust のモジュールを Python の慣用的なコードへ変換します。単なる機械的なトランスパイルではなく、Rust のパターン（Result<T, E>, Tokio 並行処理など）を Python のそれ（例外処理、asyncio など）へ適切にマッピングします。
• ベンチマークを目的関数 (Benchmark-as-Objective-Function):
  • ユニットテスト（2,621 件）に加え、公開されたエージェントベンチマーク（Terminal-Bench と SWE-bench Verified）を「目的関数」として活用します。
  • 翻訳後の Python ポートと元の Rust 実装を同じベンチマークタスクで実行し、スコアを比較します。
  • ベンチマークの失敗（スコア低下）が、API プロトコルの不一致、環境汚染、ツール不足などの統合レベルのバグを特定し、LLM に修正を指示するフィードバックループを形成します。
• 継続的なアップストリーム同期アーキテクチャ:
  • Git サブモジュールで Rust リポジトリを追跡し、差分（Diff）を抽出。
  • 変更された部分のみを LLM で翻訳し、ベンチマーク回帰テストで検証する「Diff-Translate-Test」ループを構築。これにより、Python ポートは Rust の最新変更を継続的に吸収できます。

3. 主要な貢献 (Key Contributions)

1. ベンチマーク駆動開発の手法論: 言語間翻訳において、公開ベンチマークが単なる検証ツールではなく、翻訳品質を向上させる「目的関数」として機能することを実証しました。
2. 同等性から機能の超集合（Superset）への進化: 単なる Rust の複製（Parity）で終わらず、Python ポートは codex.enhancements モジュールを通じて、マルチエージェント編成、セマンティックメモリ、コスト追跡、音声モードなど、Rust には存在しない 30 種類の機能拡張を備える「機能の超集合」へと進化しました。機能フラグにより、厳密な同等性モードと拡張モードを切り替え可能です。
3. 継続的同期アーキテクチャ: 高速に変化するアップストリームコードを、LLM 支援の差分翻訳とベンチマーク回帰テストを通じて自動的に追跡・統合するシステムを設計しました。
4. 包括的な実証評価: コード量、複雑度、テストカバレッジ、ランタイム性能、そして実タスクベンチマークの 9 つの次元で、Rust 版と Python 版を包括的に比較評価しました。

4. 結果 (Results)

• コードの削減: Rust 版（648K LOC、65 クレート）から Python 版（41K LOC、28 モジュール）へ移行し、15.9 倍のコード削減を達成しました。
• ベンチマーク性能:
  • Terminal-Bench: Python 版は 42.5%（Rust 版 47.5%）。API エラー回復などの修正により、Rust 版との差は 5% 以内に収まりました。
  • SWE-bench Verified: Python 版は 59/80（73.8%）、Rust 版は 56/80（70.0%）。Python 版がわずかに上回る結果となりました。
  • 結論: 実世界のエージェントタスクにおいて、両者はほぼ同等の性能を達成しました。
• パフォーマンス:
  • AI エージェントのボトルネックは LLM API のレイテンシ（1〜10 秒）であり、Python のローカル計算オーバーヘッド（ツール実行など）は 25ms 未満（セッション時間の 0.1% 未満）です。
  • Python の表現力の高さによるコード削減と保守性の向上が、Rust のパフォーマンス優位性を上回ることが示されました。
• バグ発見: ユニットテストでは検出されなかった重要なバグ（WebSocket の空レスポンス問題、API 400 エラー時のクラッシュ、環境汚染など）を、ベンチマーク駆動のデバッグによって発見・修正しました。

5. 意義 (Significance)

• AI エージェント開発における言語選択の再考: LLM API のレイテンシが支配的な AI エージェントシステムにおいて、Rust のような低レベル言語の性能優位性は相対的に小さく、Python の表現力、エコシステム、開発速度の優位性がシステム全体の効率性を高めることが実証されました。
• 移行の新たなパラダイム: 言語移行は「一度きりの作業」ではなく、ベンチマークを目的関数とした「継続的なプロセス」として捉えるべきであるという示唆を与えています。
• 拡張性の確保: 同等性を達成した後、ターゲット言語（Python）の特性を活かして独自機能を追加し、元のシステム（Rust）を超えたプラットフォームへと進化させることが可能であることを示しました。

この研究は、大規模な AI システムの言語間移行において、自動化されたベンチマークと LLM を組み合わせたアプローチが、高品質で保守性の高いシステムを構築するための有効なフレームワークであることを実証しています。