Gergely Orosz、AI を活用した移行の議論を提唱

こんにちは、ゲルゲーです。今回は『Pragmatic Engineer』ニュースレターの特別無料号をお届けします。

毎号、私はシニアエンジニアやエンジニアリングリーダーの視点から、ビッグテックとスタートアップの世界を解説しています。今回の記事では、先週発行された「The Pulse」の4つのトピックのうち1つを取り上げます。この記事を7日前に購読者向けに配信しました。もし転送されたメールをお読みなら、こちらから購読可能です。

OpenAIは、自社のツール「Codex」を活用して Asana が590万ドルのコスト削減を実現したという、印象的な事例を発表しました（太字は私による強調）。

「Asana は Codex を活用し、5 年分のエンジニアリング作業をわずか2週間で完了させました。OpenAI Codex を用いることで、同社は古くなったテストシステムを約1万2000ドルで2週間以内に置き換えることに成功しました。

今回のプロジェクトでは、Codex が Asana のエンジニアたちをサポートし、コードのアップグレードを困難にしていた古いテストライブラリ「Enzyme」の完全撤廃を実現しました。モデル利用料とインフラコストは合計約1万2000ドルでした。一方、従来の計画では人件費だけで約600万ドルが必要と見積もられていました。

エンジニアリング作業は1.5週間分を2週間にわたって実施し、Enzyme の完全撤廃が完了しました。モデル利用料とインフラコストの合計は約1万2000ドルです。比較のために：従来の計画では少なくとも5年かかり、費用も約600万ドルが必要でした。この経験により、同社は今後取り組むべき長期ソフトウェアプロジェクトの実現可能性に対する考え方が大きく変わりました。」

参考までに、Asana は Enzyme から React Testing Library へ移行しましたが、これは決して簡単な作業ではありませんでした。しかし、彼らが「5 年間、4 人のエンジニア（OpenAI の計算によると各社年収約 30 万ドル）を投入する」と見積もったことには、正直驚かされました。

しかし、この件をもう少し深く考えてみると、「Enzyme から React Testing Library への移行とは、具体的にどのような作業なのか？」という疑問が浮かび上がりました。

Enzyme から React Testing Library への移行

簡単なテスト例を見て、各ライブラリでどのように記述されるか比較してみましょう。

今回のテストでは、ボタンを押すとカウンターが増加することを確認します。まずは React のボタンを見てみましょう。

カウンターを増やすボタンです。次に、この動作を検証するテストを Enzyme で記述した例を見てみましょう。

Enzyme でのユニットテストです。では、このテストを React Testing Library で書き直してみましょう。

画像React Testing Library のユニットテスト

2 つのテストは同じことを実行していますが、記法は全く異なります。その違いを並列比較で見てみましょう。

画像全く異なる 2 つのファイル：共通しているのはインポートのみ

この違いの主な原因は、両方のフレームワークがテストに対して根本的に異なるアプローチを採用している点にあります。Enzyme はコンポーネントテストに焦点を当てています（テストがコンポーネントインスタンスを対象としている点にご注目ください）。一方、React Testing Library はレンダリングされたドキュメントオブジェクトモデル（クライアントに配信される HTML を表すデータ構造）上で動作します。つまり、テストは特定のコンポーネントだけでなく、レンダリングされたページ全体を認識します。

そのため、特に複雑なユーザーシナリオのテストにおいては、両フレームワークのアプローチは劇的に異なります。2 つのアプローチのトレードオフについては、React Testing Library の著者によるこちらの記事で詳しく解説されています。

Airbnb は AI を活用して 6 週間で 3,500 件のテストを移行しました

昨年のこと、Airbnb は LLM（大規模言語モデル）を活用して、3,500 件のコンポーネントテストファイルからなる Enzyme テストスイートの移行をわずか 6 週間で完了させたことを明らかにしました。もしこれを人手で行った場合、推定でエンジニアが 1.5 年かかる計算でした。

Airbnb は LLM を活用した移行を多段階のプロセスで実施しました。

image各ファイルごとの 5 つの移行フェーズ。出典：Airbnb

Airbnb のチームは、移行が失敗した場合に自動で再試行するループを構築する必要がありました。この仕組みを整えた結果、4 時間以内に全ファイルの 75% を移行することができました。残りの 25% については、より高度なリファクタリングパイプラインを構築し、その後のループ実行により 4 日以上の稼働で残りのテストの 97% をカバーしました。

最後に残った 3% は LLM の支援を受けつつエンジニアが手動で完了させ、トータルで 1 週間での完了に至りました。

これは 2025 年 3 月の話です。当時は最先端のコーディングモデルとして Claude 3.7 Sonnet が注目されていました。しかし現在では、GPT-5.6 Sol や Claude Fable 5 など、さらに能力の高いモデルが登場しています。

AI によって不可能と思われた移行が現実のものに

Airbnb の事例から 1 年後、Asana も同様に複雑なテストインフラを Enzyme から RTL へ移行するのに要した期間がわずか 2 週間だったと報じられています。これは Airbnb のケースと比較しても十分に納得できる結果です。

OpenAI が提示した時間と 600 万ドルというコストは、実際には過大評価されているように思えます。おそらくこの数字は、「フルタイムのエンジニアが 1 日に最大 X 件の移行を完了できる」という前提に基づいた見積もりから算出されたのでしょう。ここで言う X は 5 から 10 の間と想定されます。これをもとに、プロジェクト全体に必要なエンジニアリング期間（例えば 20 年分）を計算し、それにエンジニアの単価を乗じているはずです。

実は、エンジニアにとってやりたくないプロジェクトだと判断された場合こそ、こうした見積もりがなされるものです。

では、この視点から考えてみましょう。見積もりの期間が 1.5 年（Airbnb の事例）なのか、仮に 5 年半（Asana のようなケース）なのか。あるいはコストが 100 万ドルなのか 500 万ドルなのか。いずれにせよ、それは非現実的な移行であり、愚かな試みです。少なくとも「従来の」方法では、期間が長すぎて集中力が削がれ、 distracting（気が散る）要因にしかなりません。

AI が登場する以前は、数年かかるような大規模な移行は稀でした。2021 年、Sentry はフロントエンドのコードベースを JavaScript から TypeScript へ移行しましたが、これには 1.5 年の歳月がかかりました。対象となったのは 1,100 ファイル、95,000 ラインのコードです。この移行作業には約 10 名のエンジニアが携わりました。仮にエンジニア 1 人あたりのコストを 30 万ドルと見積もれば、95,000 ラインのコードに対する総コストは 200 万〜400 万ドルとなります。

実際、Asana が報告した 12,000 ドルの移行コストは、コスト最適化に徹底的に取り組めばさらに下がる可能性があります。OpenAI の 10 分の 1 という安さを実現するモデル、つまり推論プロバイダー上で動作するオープンソースモデルを使わない手はありませんか？そもそもなぜ最も高価なモデルを使う必要があるのでしょうか？特に企業がすでに GPU を保有し、自前でモデルを動かしている場合、電力コストを除けば推論は事実上無料です。最初の試行であれば、エンジニアに 30 万ドルを支払う企業にとって 12,000 ドルは許容範囲でしょう。しかし、2 回目以降の移行では、コスト最適化に時間を割いて、1 回あたり 1 万ドル（それ以上）を節約する価値があるはずです。

Asana の内部から得た追加情報

私は Asana で開発者生産性グループを率いる Dan Ubilla 氏と連絡を取り合い、同社のサイトにある Enzyme 移行に関する投稿についていくつかの点を明確にしました。

Asana は 2024 年に Enzyme 移行を開始しました。チームには 4,000 件以上の Enzyme ファイルがあり、当時 LLM を活用して最初の移行を試みました。既存のテストを移行するだけでなく、このフェーズでは将来のテストをより自然な書き方で記述できるようコードベースを整えることに注力しました。具体的には、モック処理の改善、データセットアップの見直し、カバレッジ計測機能の強化などです。最終的に約 25% のファイルを RTL（React Testing Library）へ移行し、投資対効果が高いテスト——つまり移行が容易なテストや頻繁に更新されるテスト——を優先して選定しました。

残りの移行タスクは優先度が低くなりました。Asana では、移行を「直ちに実施必須（must do soon）」「重要（important to do soon）」「機会主義的（nice to have）」の 3 つに分類しています。同社には多くの重要かつ必須の移行案件があり、「Enzyme」移行はその中の一項目として、機会主義的な扱いで並んでいました。

当初の見込みでは、この移行完了まで約 5 年かかる予定でした。これは「チームが 5 年間、休むことなくプロジェクトに取り組む」という意味ではありません。あくまで、優先度の低い Enzyme 移行を現実的に完了させるまでの期間を示したものです。すでに 2 年かけて進められていたことを考慮すれば、5 年という見積もりは妥当なものでした。

チームは LLM（大規模言語モデル）が移行作業を劇的に加速できることを証明したかったため、優先度の低い機会主義的な案件を選定しました。Enzyme 移行は急ぐ必要のある重要な案件ではなく、数年間放置される可能性が高いものだったのです。つまり、LLM を使えば長期間かかる移行も大幅に短縮できると示すのに最適な候補でした。

最後に、私からの補足です。

600 万ドルというコストは概算値です。この見積もりがどのように導き出されたのかを Dan に尋ねたところ、彼は「多くのエンジニアが同様の手法で推定を行っている」と回答しました。

具体的には以下の手順です：

• エンジニアが Enzyme ファイル 1 つを手動で移行（書き換え＋検証を含む）するのにかかる時間を概算する。この際、やや多めに見積もる。

これを、移行対象となる未処理ファイルの数（3,000 件以上）で掛け算します。

さらに、フレームワークの痕跡や監視ツール、静的解析ツールの削除にかかる時間を加算し、一般的なエンジニアの時給を乗じます。

……すると、結果は 600 万ドルとなりました。

この試算には、手作業での移行において「10 件のファイルを移行する時間は、単一ファイルの 10 倍ではなく、むしろそれ以下になる（習熟による効率化）」という現実も、「LLM の活用」も考慮されていません。これはあくまで、AI が登場する以前に、Asana の全エンジニアが隙間時間を見つけて数件のファイルを順次移行していた場合の作業規模を把握するためのベースラインです。私の見解では、この金額は実際より過大評価されている可能性がありますが、重要なのは数字そのものよりも、「これほど膨大な作業量になる」という事実を伝える点にあります。

現在、Asana のチームと経営陣は、LLM が移行作業に有用であることを確信しており、今後他の長期間にわたる、かつては骨の折れる作業となっていた移行プロジェクトでも活用していく方針です。

これまで先送りされ続けてきた大規模な移行が、ついに実現するでしょう。

数ヶ月前、Uber は AI を活用し、わずか 2 名のエンジニアで 4 ヶ月という短期間に大規模な JUnit の移行を完了したと発表しました。これは、サポート終了となった JUnit 4 から JUnit 5 への移行であり、1,500 万行に及ぶコードに跨る 60 万件のユニットテストを移動させたものです。移行期間中には、125 万行のコードが修正されました。かつては非現実的とされていたこの種の移行ですが、AI ツールの導入により、8 エンジニア月分の工数と AI コストで実現可能となりました。

例えば、Bun の移行では AI を活用して 2 週間で Zig から Rust へ 53 万行のコードを移行し、API コストはわずか 16.5 ドルで済みました。これは、AI を用いた移行が劇的に高速化されている好例です。

AI を活用した迅速な移行の最大の利点は、「古い」ライブラリのサポートを気にする必要がなくなる点にあります。これまでライブラリ移行が厄介だった主な理由の一つは、移行期間中に旧ライブラリや旧技術を引き続きサポートし続けなければならないという負担でした。この期間を短縮できれば、移行コストが増加しても十分に価値があると言えるでしょう。少なくとも、これらの移行にかかる時間とコストを劇的に削減する方法が見つかるまでは、そのように考えるのが妥当です。

上記のすべての移行に共通するのは、エンジニアが事前に計画を立て、検証ループを設計し、プロセス全体に関与し続けなければならない点です。私はこれまで移行作業を常に恐れていましたが、このような「地味な仕事」に使える新しいツールが登場したことは朗報だと捉えています。

先週の『The Pulse』の全文を読むか、今週の『The Pulse』をチェックしてください。今号では以下を取り上げています。

Meta は AI を理由にチーム規模を 60% 削減すると本当に決めたのか？

Reuters の詳細な報道によると、Meta の経営陣は 1 月に計画を立てて、同社史上最大規模の人員削減を実行する方針でした。しかし、マーク・ザッカーバーグが直前で方針を変更したため、現在は社内の士気が歴史的な低水準に落ち込み、退職者が相次ぎ、かつて誇り高かった企業文化が軍事的な雰囲気に変わってしまっています。分析記事はこちら。

Ramp の社内 AI インフラに関する追加の考察。自社で AI ツールを開発することは、AI エンジニアリングのための「内部ブートキャンプ」のようなものであり、多くのテック企業においてこの取り組みを正当化する十分な理由となるだろう。

業界の動向。GitHub の負荷増加が加速しているほか、Stripe が OpenRouter を買収し、Ramp が一般公開で Ramp Router をリリースした。また、キャリアにおける「ダブル・ブーマーラング」現象や、Apple において App Store の収益が史上初めて減少したという話題に加え、「バグとは何か」という問いについても触れられる。