二千のエージェントが二週間で自分を書き換えた：Prime Agent が TypeScript を Rust へ移した方法

二千人規模のチーム、その誰もが人間ではない

2026 年 8 月にようやく正式リリースされたコーディングエージェント Prime Agent は、2 か月で 30 万回を超えるダウンロードを集め、8 兆トークン以上を処理した。10 月 9 日、その開発元である Prime Intellect は、さらに目を引く出来事を公表した。このツールが自分自身で書き直されたのだ。TypeScript から Rust へ、わずか 2 週間で。手を動かしたのは 2000 を超える自律エージェントだった。

これは宣伝文句にある「AI がコードを書いてくれる」という話ではない。移植の全過程で、人間のチームが主にやったことは一つだけだ。受け入れ基準を整え、エージェントが自分で正しくできたかを測れるようにする。残りのオーケストレーション、コーディング、レビュー、検証はすべて機械に任された。

コストと規模：2000 億トークンの引っ越し

公式ブログによれば、この書き直しは 2000 を超えるエージェントを動員し、10000 を超える Prime サンドボックスをまたいで並行して作業させ、Prime Inference の GLM-5.3 エンドポイントから 2000 億トークン以上を消費した。実際に Rust を書いた段階は 1981 個のエージェントが担い、約 1929.9 億トークンを使った。続く 3 日間の性能立ち上げ段階ではさらに 228 個のエージェントが投入され、約 357 億トークンを消費した。

これらの数字そのものが一つのシグナルだ。オープンなモデル GLM-5.3 が本番級のエージェントスウォームの主力推論エンジンになったことは、「あるモデルのスコアがまた 1 点上がった」という話とは違う。長期にわたり、大量に、安定したツール呼び出しを必要とするエンジニアリングの場面で、オープンウェイトモデルのコスト効率が実際のプロジェクトに受け入れられる水準に達したことを示している。

オーケストレーション：ルートエージェントは業務コードを書かない

最も真似する価値があるのは「2000 個のエージェントを使った」という点ではなく、その分業のしかただ。書き直し全体は一つのルートエージェントが指揮したが、それ自身は製品コードを一行も書かない。やることは三つだけだ。タスクをトポロジカルな順序を持つグラフに分解し、各タスクの進捗を追跡し、完了した作業をマージする。

各タスクは四つの役割を順に通過する。

• プランナー：仕様書、機能設計、「模範解答」を書く。模範解答は TypeScript 版の既存の挙動からそのまま取る。
• 実装者：独立した worktree で Rust コードを書き、異なる機能を並行して進められるようにする。
• レビュアー：別のモデル、別のコンテキストに切り替え、この変更の欠陥を敵対的に探す。
• 検証者：まっさらなサンドボックスでコードをコンパイルし、一貫性テストを走らせる。

レビューか検証のどちらかが通らなければ、タスクは結論を添えて実装者に差し戻される。両方を通過して初めて、変更はマージを許される。Prime Intellect は「生成」と「評価」をあえて分離した。理由は率直だ。コードを書いた当のエージェントに自分の成果を評価させれば、それは当然自分に甘くなる。

本当のガードレール：4 種類の一貫性検証

プロセスだけでは足りない。客観的な正誤基準も必要だ。チームは同じ機能の異なる側面をカバーする 4 種類のパリティチェックを組んだ。

• TUI 差分テスト：TypeScript と Rust の 2 つのバイナリを同じスクリプト化モデルの下で走らせ、ターミナル画面をフレーム単位で比較する。起動、メニュー、ツール呼び出し、セッション復元、サブエージェント、クラッシュ復旧をカバーする。
• ハーネス一貫性：両側が生成したセッション記録と、それぞれがモデルプロバイダーへ送るリクエストを比較する。
• プロトコル一貫性：デーモンプロトコルのすべてのメッセージ種別を TypeScript 実装と突き合わせて検証する。
• 機能監査：スクリプトでは届かない箇所を、エージェントがコンポーネントごとに照合し、「一致」「部分一致」「欠落」と印を付ける。

こうした客観的な物差しがあれば、エージェントは自分で進捗を判断し、マージ前にリグレッションを止められる。人間によるレビューの必要性もそれだけ下がる。チームも率直だ。すり抜けたバグはテストがまったく及んでいなかったもので、最後は社内で毎日使って初めて露見した。

結果：コールドスタート 14 倍、メモリは 2 割減

公式の比較データでは、コールドスタートから入力可能までの遅延は TypeScript 版の 737.8 ミリ秒から 55.8 ミリ秒に下がり、14.18 倍の高速化。ウォームスタートは 13.34 倍。プロセスツリー全体のメモリ使用量は 607.4 MB から 106 MB に減り、およそ 8 割を節約。インストールサイズも 172.1 MB から 59.6 MB に縮んだ。最初の可視出力は 23.6 ミリ秒。立ち上げ段階では計 144 件の実験を記録し、69 件の有効な変更をマージした。ただし注意したいのは、この横並び比較は公式自身のランタイムスイートを使ったもので、統一ベンチマークが欠けていると公式も述べている点だ。数字は慎重に読むべきだ。

構造上の変化は速度よりも長く残るかもしれない。コードは 9 つの crate に分割され、依存関係は一方向で、Cargo によって強制される。最大のソースファイルは約 15000 行から約 2500 行に縮み、5000 行を超えるファイルはもうない。各セッションは自分のワーカープロセスで動くため、一つが落ちても他に影響しない。Windows 対応はプラットフォーム抽象がきれいになった副産物として実現し、モデルカタログは実行時に取得する方式に変わり、新モデルの提供がリリースに依存しなくなった。

なぜ Rust なのか

チームが挙げた TypeScript の痛点は具体的だ。型は任意でランタイムには消える。エラーは未チェック例外として伝播する。レンダリングや大きなセッションの解析のような CPU を食う処理がキーボード入力と同じイベントループを奪い合う。どのプロセスも JavaScript ランタイムとガベージコレクションを抱えなければならない。常駐し、セッションごとにワーカープロセスを立てるデーモンにとって、GC のないネイティブコードこそがメモリと起動時間を改善する主な源泉だ。

そしてコードを主にエージェントが書くとなると、「コンパイル時の保証」の価値は増幅される。網羅的な enum、所有権とライフタイム、さらに Clippy の厳格な lint は、コードが動く前にひとまとまりのバグを排除できる。言い換えれば、コンパイラが人間のレビュアーの判断の一部を肩代わりしている。

これが人によって何を意味するか

エンジニアリングチームを率いているなら、再利用できるのは「2000 個のエージェント」という数字ではなく、その手法だ。まず受け入れ基準を客観的で自動実行できるチェックにし、次に生成と評価を別々のモデルとコンテキストに割り当て、最後にエージェントをガードレールの内側で自走させる。Primer Intellect はすでにこの四役割パターンを再利用可能なワークフローとして製品化しつつある。理由は「きちんと定義されたスウォーム工場」のほうが、プロジェクトごとに場当たりで組むより信頼できるからだ。

ただの一般ユーザーなら、これは一つのことを説明してくれる。Prime Agent のようなツールの更新速度は、これからますます従来のソフトウェアらしくなくなる。製品が自分自身を書き直せるようになれば、バージョン番号の意味も変わる。これはまた、「リファクタリングで 14 倍高速化」といった結論を見たら、まず脚注を開いて誰が測り、何と比べたのかを確かめよという警告でもある。エージェントは使えるコードを書けるが、自信満々の自己賛美も同じように書けてしまう。