8月18日、Vigetが「Using AI to Migrate from Lit to React」と題した記事を公開した。この記事では、AIを活用してLitからReactへのフレームワーク移行を大幅に効率化した実践的な手法について詳しく紹介されている。
移行期間を「合計2ヶ月→数日＋2週間」に短縮
今回の事例で最も注目すべき数字がある。AIを使わなかった場合、コードの移行に約1ヶ月、QAにさらに1ヶ月、合計2ヶ月かかると見積もられていた作業が、AIを活用することで移行が数日、QAが約2週間に短縮されたという点だ。タイトルの「2ヶ月→数日」は移行単体ではなく、この合計工数を念頭に置いた表現であり、特にコーディング作業そのものは「1日程度で終わる」とも記事内で述べられている。
フレームワーク間のコード移行は、構文の差異が大きいほど単純作業の繰り返しになりやすい。この「単純だが量が多い」作業こそ、AIが最も力を発揮する領域だった。
LitからReactへ——なぜこの移行が起きるのか
LitはWeb Components標準に基づいたGoogleのライブラリで、フレームワーク非依存のコンポーネントを作れる点が強みだ。一方、ReactはMetaが開発し、現在もフロントエンド開発のデファクトスタンダードに近い地位を占める。エコシステムの豊富さ、採用事例の多さ、チームの習熟度などを理由にReactへ統一する判断は業界でよく見られる。
両者はコンポーネントの記述スタイルが根本的に異なる。LitはHTMLテンプレートリテラルやカスタム要素のライフサイクルを中心に設計されており、ReactのJSX・Hooksとは思想から違う。この構造的な差異が、機械的ではあっても量の多い変換作業を生み出し、AIが介入する余地を生んでいる。
「計画を書く」ことが品質を左右する
記事が強調するのは、AIに丸投げするのではなく、事前に移行計画を文書化し、小さなコンポーネントで試してから本番に臨むというアプローチだ。
Writing a plan and testing on a few small components saves a lot of time and prevents hours of rebuilding and refactoring AI code slop.
ここで言う「AI code slop」（AIコードスラップ）とは、AIが生成した雑然としたコードの山を指す俗語だ。動きはするが構造が乱雑で、後からのリファクタリングに多大なコストがかかる状態を表す。小さなコンポーネントから始めることで、AIの出力の癖や問題点を早期に把握でき、後から大規模な作り直しに追われる事態を防げる。
AIが苦手なのは「見た目」だった
移行後のテスト工程では、CSSとスタイリングの再現がAIの最も弱い部分として浮かび上がった。機能面のロジックはおおむね正確に変換できても、コンポーネントの見た目については複数回の修正が必要になるケースが多かったという。
記事ではStorybookなどのUIツールを使ってコンポーネントを視覚的に確認するフローを推奨している。また、デザイナーやプロジェクトマネージャーとの複数回のQAラウンドが発生することを想定しておく必要があると述べている。
テストの手順として記事が示すのは以下の流れだ：
- フルビルドを実行し、全テストを走らせて新コードベースが動作することを確認する
- 手動テストで各コンポーネントの動作を確認する（テストがカバーしていないエッジケースを拾うため）
- 機能バグが見つかった場合はテストも更新する
- Storybookなどで視覚的なチェックを行い、デザイン通りかを確認する
「AIがやる、人間が確かめる」という分業
記事全体を通じて繰り返されるメッセージは一貫している。
While AI can do the heavy lifting, there still needs to be a human reviewing and testing everything.
AIはコード変換の重労働を担えるが、移行の正確性を保証するのは人間のレビューとテストだという立場だ。「AIを使えば楽になる」ではなく、「AIを使っても手を抜ける工程と抜けない工程がある」という現実的な視点で書かれている点が、この記事の実用的な価値といえる。
QAに2週間かかるという見積もりは、コンポーネントの数によって変わるとも述べており、規模感を把握した上で計画に組み込む必要がある。大規模なコンポーネントライブラリを抱えるプロジェクトであれば、QA期間はさらに伸びる可能性がある点にも留意したい。
詳細はUsing AI to Migrate from Lit to Reactを参照していただきたい。
