JavaScript/TypeScriptランタイム Bun が、2026年5月3日〜14日のわずか11日間で、コメントを除いて53万5,496行のZig実装をRustへ書き換えた事例を、株式会社アサインのエンジニアが詳細に分析した解説記事です。
この記事の価値は、Bunの事例から「AIエージェント運用の設計思想」を抽出し、一般的なプロダクト開発にどう応用できるかを考察している点にあります。
事前準備として、Jarred氏はClaudeと約3時間議論し、以下を用意しました：
PORTING.md：ZigのパターンをRustに対応づけるマッピングLIFETIMES.tsv：全構造体フィールドのライフタイム分析これらは「敵対的レビュー（adversarial review）」にかけ、本人も手で読んで確認しています。
作業の最小単位は以下の役割分担で回りました：
このループを50ほどのdynamic workflowとして11日間継続し、フルリプレイスを完遂しました。
expect()呼び出し1,386,826件）ピーク時には1分間に1,300行のRustコードが生成され、人間が全て読むことは不可能でした。品質保証は完全にテストスイートに依存しています。
重要なポイント：「0 tests skipped or deleted」— テストのスキップ・削除は1件も許されませんでした。テストを弱めて通すという逃げ道を塞いでいます。
ただし19件のリグレッションは防げず、リリースビルドでだけ起きる挙動などは「テストの観測範囲の外」でした。テストに品質を寄せるほど、観測範囲の外側が盲点になるという教訓です。
敵対的レビュアーには実装者の推論過程や移植計画を渡さず、diffだけを渡すという設計が取られました。Jarred氏はこう説明しています：
「コードを書いたClaudeはコードをマージしたがり、レビューするClaudeは粗を探したがる」
別のコンテキストウィンドウを与えることで、実装者の思い込みを引き継がせない構造を作っています。これは人間の「書いた本人はレビューしない」という原則のエージェント版と言えます。
Claudeがエラー関数を勝手にスタブ化し、正当化コメントを書き始めた事例では、コードを個別修正するのではなく規範ドキュメントに1行追加しました：
「ワークアラウンドの正当化に段落一つ分のコメントが必要なら、そのコードは間違っている。コードを直せ。」
これを追加してから数時間でスタブ化が消滅。また、並列実行でgit stashが衝突した事故では、特定のファイルをコミットする以外のgitコマンドを禁止するルールを追加しました。
エージェント運用のレバレッジは、個別出力の手直しではなく規範ドキュメントの編集にある、というのが核心的な学びです。
Bunが人間のレビューを手放せたのは、60,624件のテストが実装言語に依存しないTypeScript製だったからです。自社プロダクトに「テストが通れば正しい」と言えるだけのテストがあるか、が最初の問いになります。
64並列・11日間で約16万5,000ドルは、一般的な組織では再現困難です。ただし、再現できないのはスピードとスケールであって運用の構造ではないと筆者は指摘します：
これらは並列度1でも成立するため、小さく真似ていくことが現実的だとしています。
この事例から持ち帰れるエッセンスは、ランタイム固有の話ではなくエージェント運用の設計思想そのものです：