8月28日、Gergely Oroszが「The Pulse: We need to talk about migrations with AI」と題した記事を公開した。AIを活用することで、5年・約600万ドル（約8.5億円）と見積もられていた大規模マイグレーションが2週間・約1万2,000ドル（約170万円）で完了したという事例が登場している。長年「やりたいがコストが見合わない」として先送りにされてきた技術的負債の解消に、AIが現実的な選択肢をもたらしつつある実態を、複数の企業事例を通じて詳しく論じている。
AsanaがEnzymeマイグレーションを2週間・約170万円で完了
OpenAIが公開したケーススタディによると、AsanaはOpenAI Codexを使い、5年・約600万ドル（約8.5億円、1ドル≒141円換算）と見積もられていたマイグレーションを2週間・約1万2,000ドル（約170万円）で完了させた。
対象はフロントエンドのテストフレームワーク「Enzyme」から「React Testing Library」（RTL）への移行だ。EnzymeはReactコンポーネントの内部状態を直接操作・検査するスタイルのテストライブラリで、Airbnbが開発した。一方RTLは、実際にレンダリングされたDOM（ブラウザに届くHTML構造）を通じてテストを書くアプローチを取る。この哲学の違いが、コードの見た目を根本から変える。
記事中では両者のコード比較が示されており、「ボタンを押すとカウンターが増える」という同一の振る舞いを検証するテストでも、共通するコードはimport文だけという状態になる。構文が完全に異なるため、単純な置換では済まず、手動移行のコストが膨らむ根本的な理由がここにある。
6M$見積もりの内訳
Asanaでデベロッパー生産性グループを率いるDan Ubilla氏が記事内で詳細を補足している。
- 2024年にマイグレーションを開始済みで、4,000件以上のEnzymeファイルのうち約25%はすでにRTLへ移行していた
- 残り75%は「あればいい（opportunistic）」な低優先度タスクとして積み残されており、5年という見積もりは「専任チームが5年かける」ではなく「低優先度のまま放置した場合にいつ終わるか」の予測だった
- 600万ドルの試算は、「1ファイルの手動移行コスト × 残ファイル数 × エンジニア単価」という典型的なざっくり計算によるもの
記事著者のGergelyは「この数字はおそらく過大評価だが、ポイントは数字の正確さより『とにかく膨大な作業量』を伝えることにある」と述べている。
Codexを使ったパイプラインの設計
Asanaのマイグレーションでは、OpenAI Codexを活用した自動変換パイプラインが中心的な役割を果たした。エンジニアがパイプラインの設計・変換ルールの定義・出力のレビューを担い、ファイル単位の変換処理そのものをAIが実行するという分業体制を採った。変換後のテストが自動で実行されてパスしたファイルはそのままマージし、失敗したファイルだけをエンジニアが手動確認するループを組むことで、レビューコストを最小化した。このように「AIに丸投げ」するのではなく、検証ループをパイプラインに組み込む設計がスループットと品質を両立させた鍵だったと記事は指摘する。
AirbnbとUberの先行事例
Asanaは突出したケースではない。過去1年で複数の企業が同様の成果を報告している。
Airbnb（2025年3月）：3,500件のEnzymeテストファイルを6週間でLLMを使って移行。手動での見積もりは1.5エンジニア年だった。移行は5フェーズのパイプラインで構成され、最初のループで75%のファイルを4時間で処理。残り25%向けに高度なリファクタリングパイプラインを追加構築し、4日間で97%を処理。最後の3%はエンジニアが1週間で完了させた。段階的に難易度の高いケースへ対応範囲を広げていくこのアーキテクチャは、Asanaのアプローチとも共通している。
Uber：JUnit 4からJUnit 5への移行を2名のエンジニアと4か月で完了。対象は60万件のユニットテスト、1,500万行のコード。コード変更は125万行に及んだ。JUnit 4はすでにサポートが終了しており、長年の技術的負債だった。
また記事では、JavaScriptランタイム「Bun」の開発チームが実施した大規模な言語マイグレーション事例も言及されている。BunはもともとZigで書かれていた部分をRustへ移行する作業を行い、53万行・2週間・API費用16万5,000ドルで完了させた。ZigとRustはいずれもシステムプログラミング言語だが、構文・メモリモデル・エコシステムが大きく異なるため、このスケールの移行は通常であれば数名のエンジニアが数か月を要するプロジェクトとなる。AIを活用した変換パイプラインにより、その期間が劇的に短縮された。
何が変わったのか
これらの事例に共通するのは、エンジニアが計画・検証ループの設計・レビューを担い、実際の変換作業の大半をAIが担うという分業だ。
Gergelyは「AIが実用的なマイグレーションの範囲を広げた本質的なメリットは、旧ライブラリのサポートを長期間維持せずに済む点にある」と指摘する。従来、マイグレーション中は新旧両方のライブラリを並走させる必要があり、それ自体がコストと複雑さを生んでいた。移行期間が数週間に短縮されれば、この問題は大幅に緩和される。
コスト最適化の余地も大きい。記事では「OpenAIより10倍安価なオープンモデルを使えば、1万2,000ドルの移行コストをさらに下げられる。自社GPUを持つ企業なら推論コストはほぼ電力代のみ」と指摘されている。
Asana社内では、このマイグレーションの成功を受けて、他の長期積み残しマイグレーションにもLLMを活用する方針が固まったという。「やりたいが割に合わない」として凍結されてきたマイグレーション案件を抱えるエンジニアリング組織にとって、今後の意思決定に影響を与えうる事例群といえる。
詳細はThe Pulse: We need to talk about migrations with AIを参照していただきたい。
