6月24日、Dataconomyが「Structuring AI agents for Perplexity's Python-to-Rust migration」と題した記事を公開した。この記事では、PerplexityのSearch & APIエンジニアであるAleksandr Nikolenkoが、AIエージェントを活用してPythonからRustへの大規模な検索システム移行をどのように安全に進めたかについて詳しく紹介されている。
なぜPerplexityはPythonからRustへ移行したか
Perplexityの検索システムはPythonで構築されていたが、AIサービスとしてのトラフィック規模が拡大するにつれ、レイテンシとスループットの改善が経営上の優先事項となっていた。Rustはシステムプログラミング言語として、GCによる停止なしにC/C++に近いパフォーマンスを実現できる点が広く知られており、CloudflareやDropboxといった企業でも本番システムへの採用事例が積み重なっている。Perplexityにとってこの移行は、性能改善という具体的なゴールに裏付けられた判断だった。
問題は「なぜRustか」ではなく「どうやって安全に移行するか」だ。除去したコードは約5万行のPythonで、対象は実際の検索トラフィック。規模だけ見れば十分にリスクの高い作業だが、NikolenkoはそこにAIエージェントを投入した。
「既存のPythonコードが仕様書になる」という発想転換
多くのチームがAIエージェントに対して「設計を草案し、実装を提案せよ」という開放的なタスクを与えがちだ。この場合、モデルは解法と成功基準を同時に"発明"しなければならない。
Nikolenkoが強調するのは、この移行がそうではなかった点だ。既存のPython製検索パスそのものが「正しい振る舞いの仕様書」として機能した。新しいRustパスは同じ入力に対して実行でき、進捗は最初から定量的に測定可能だった。エージェントはプロンプトを追いかけるのではなく、本番環境が検証済みのベースラインとの差分を埋める作業に集中できた。
「答えが既に存在していた」ことがエージェントへの委譲を成立させた、というのが彼の主張の核心だ。
「Goal・Verifier・Workspace」の3要素フレームワーク
Nikolenkoはエージェントへの委譲に必要な最小構造として、Goal（目標）・Verifier（検証器）・Workspace（作業空間）の3つを挙げる。
- Goal：編集すべきファイルではなく、達成すべき成果を定義する。今回は「実装をRustに移しながら、プロダクトの観察可能な振る舞いを保持すること」
- Verifier：目標をシグナルに変換する。比較テストによってエージェントは「それらしいコード」ではなく「正しい振る舞い」へと誘導される
- Workspace：本番環境に触れることなく、調査・変更・リトライができる安全な空間
「Verifierのないゴールは意見に過ぎず、Workspaceのないゴールはゴールだけの空虚な指示になる。3つは一体でなければ機能しない。この構造を設計するのはエンジニアで、エージェントはその中で動く」とNikolenkoは述べている。
最大のリスクは「クラッシュ」ではなく「静かな品質劣化」
移行で最も恐れていたのは明示的な障害ではない。頻出クエリのトップ結果がずれる、ランキングやスニペットが微妙に変わる——ユーザーは感じるが、コードレビューでは見えない種類の劣化だ。
実際、あるケースではRust側の変更がコードレビューも標準ユニットテストも通過したにもかかわらず、特定クラスの入力でフィールドが欠落し、下流のバリデーションを破壊していた。パースとシリアライゼーションのミスマッチが原因だったが、ライブ挙動をベースラインと比較して初めて発覚した。
コードの見た目ではなく、「システム全体が実世界でも正しく振る舞っているか」を問う検証ループが不可欠だという主張は、モデルが高速にコードを生成できるようになった現在、さらに重みを増している。
シャドウワークスペースで「失敗を安価に」する
シャドウワークスペース（shadow workspace）とは、本番トラフィックと同等の入力でRustパスを"リハーサル"させつつ、実ユーザーへはPythonパスが引き続き応答する構成だ。比較レイヤーが両パスの差分をキャプチャし、差異が説明されるまで新しい出力がユーザーに届くことはない。
ABテストやカナリアリリースと混同されやすいが、役割は異なる。カナリアリリースは一部のユーザーに新バージョンを段階的に当てることでリスクを分散する手法であり、ABテストはユーザー体験の差異を統計的に評価するものだ。これに対してシャドウワークスペースは実ユーザーに一切の変更を届けないまま、新旧パスの出力を並走させて差分を検出することに主眼を置く。移行の「前提条件チェック」に近い位置づけと言える。
この仕組みにより、パス間の不一致は「ユーザーがすでに被った障害」ではなく「調査対象」として扱われる。エージェントはノイズと真のリグレッションを分離し、証拠付きの修正案を返す役割に専念できた。ロールアウトの判断基準も変わった。「コードの感触」を議論するのではなく、「十分な実挙動を観測したか」を問えるようになり、トラフィックの段階的な切り替えを自信を持って進められた。
エンジニアの役割はどう変わるか
Nikolenkoは「仕事の中心は、各変更を書くことから、安全に委譲できるシステムを設計することへ移る」と述べている。エージェントが成熟するほど、その周囲の検証インフラ——ガードレール、安全な実行環境、段階的ロールアウト、受け入れ基準——が実際に手放せる量を決める要素になる。
コード生成が安価になるにつれて、「正しさとは何か」「エージェントがどこまで行動してよいか」「変更はいつシップして安全か」を定義するスキルが差別化要因になる、というのが彼の見立てだ。AIエージェントによる大規模コード移行の先行事例としては、GitHubのCopilot Workspaceを活用したリファクタリング事例なども参照に値する。本稿で紹介したフレームワークはPerplexity固有の話にとどまらず、レガシーシステムを抱える多くのチームにとって汎用的な示唆を持つ。
詳細はStructuring AI agents for Perplexity's Python-to-Rust migrationを参照していただきたい。
