移行のつらさは誰が引き受けるのか── Vue.js と Next.js を比べて見えたこと

2026/07/17 開催「OPTiM Frontend Meetup #1」でのオプティム 白木の発表資料です。

https://optim.connpass.com/event/396222/

Transcript

1. © 2019-2026 OPTiM Corp. All rights reserved. © 2019-2026 OPTiM Corp. All rights reserved. 移行のつらさは誰が引き受けるのか ── Vue.js と Next.js を比べて見えたこと 白木(shirokuma)
2. © 2019-2026 OPTiM Corp. All rights reserved. 2 白木 (shirokuma) 4年目 趣味 ◼読書 ◼テニス ◼Designship 2026 の運営 プロダクト ◼OPTiM AIR 2023年~ ⚫自社のPaaS基盤の開発と保守 ◼OPTiM Collaboration Portal 2025年~ ⚫ポータルサイト作成・管理のアプリ ◼新規プロダクトの開発 2026年~ ⚫プレスリリース前 自己紹介
3. © 2019-2026 OPTiM Corp. All rights reserved. 3 考察ではなく批評です 答えはない 未来予想を楽しみましょう はじめに
4. © 2019-2026 OPTiM Corp. All rights reserved. 4 AI前提のフレームワークが流行する ◼AIが実装しやすいフレームワーク ◼AIが検索で引用しやすいコンテンツを作る（SEOからAEOへ） 要望に応じてフレームワークが作られたり、変更されたりする ◼よって、破壊的変更を受け入れる前提になっていく 破壊的変更を許容し、破壊的変更を前提にコードを書く事になる 私の予想
5. © 2019-2026 OPTiM Corp. All rights reserved. 5 フレームワークの破壊的変更のつらさはなんだろうか？
6. © 2019-2026 OPTiM Corp. All rights reserved. 6 破壊的(後方互換性のない)変更に対応するのが大変 ◼Vue.js 2 系から Vue.js 3 系にアップデートするのが大変 開発者目線 ◼変更箇所が多く工数がかかる ◼書き方が変わり、認知負荷が高い ◼デフォルト設定の変更でバグが混入する マネージャー目線 ◼アプリの機能は変わらないため、売り上げに繋がらない ◼デグレートによる品質・売上損失のリスク つらさ① フレームワークの破壊的変更 https://v3-migration.vuejs.org/ja/migration-build
7. © 2019-2026 OPTiM Corp. All rights reserved. 7 依存方向と影響方向が逆転 ◼React v18 に上げたい ◼React Router や Storybook など周辺パッケージが React 18 に対応していないと React が上げられない 開発者目線 ◼周辺パッケージが足枷になり更新できない ◼新しい機能使いたいのに使えない マネージャー目線 ◼脆弱性を突いた攻撃を受けるリスク ◼プロダクトの品質を保ちたい ◼ビックバンリリースは避けたい つらさ② 周辺パッケージが未対応
8. © 2019-2026 OPTiM Corp. All rights reserved. 8 AI・MCP が発達したら、この「負担の置き場所」はどう変わる？
9. © 2019-2026 OPTiM Corp. All rights reserved. 9 Vue.js 2 系から 3 系へ移行 ◼2023年12月31日 に End Of Life (EOL) のため、AI Agentはいない 破壊的変更が大きすぎた ◼社内コンポーネントライブラリの Vue.js 3 対応 ◼社内コンポーネントライブラリのカタログアプリの Vue.js 3 対応 ◼アプリケーションの Vue.js 3 対応 段階を踏んで移行する(影響の大きさに応じる) ◼Node.js のバージョンアップと動作確認 ◼Vue 3 互換モードで警告を消す ◼Vue 3 ビルドで動くようにする ◼リグレッションテストを行う AI ・MCP の登場前 コンポーネントライブラリ アプリケーション カタログアプリ
10. © 2019-2026 OPTiM Corp. All rights reserved. 10 Next.js v 14 から v 15 へ 移行内容の調査方法と移行作業の負担が変わった ◼next-devtools-mcpを元に破壊的変更の内容を調査 ◼修正作業をAIに任せる 動作確認に集中する ◼破壊的変更と実際のコードを比較して、確認項目を作成 ◼動作確認に時間を取る AI ・MCP の登場後 https://github.com/vercel/next-devtools-mcp
11. 11 © 2019-2026 OPTiM Corp. All rights reserved. AI活用で破壊的変更の移行がどうなったか？ docs-first / 動作確認 / 検証
12. © 2019-2026 OPTiM Corp. All rights reserved. 12 Vercel公式のMCP ◼ブラウザ検証やアップグレード支援のような開発補助 移行対応の記事を読ませる ◼MCPが使えなくても大丈夫 ◼ドキュメントをAIに読ませる MCPの有無よりもAIがドキュメントを読んで理解してくれるのが大きい AI を docs-first で動かしやすい
13. © 2019-2026 OPTiM Corp. All rights reserved. 13 注力した作業 ◼Vue.js v 2 → v 3 では、移行作業に注力 Next.js v 14 → v 15 では、注意事項 ◼ Vue.js と Next.js で単純に比較できない ◼破壊的変更の影響範囲が大きく異なる ◼動作確認に注力 AI Agentにより負担する作業が変わった 観点 Vue.js 2→3 + 移行ガイド Next.js 14→15 + MCP 情報取得 人間が移行ガイドを読んで解釈する MCP で情報を AI に渡す 移行ブログで情報を渡せる 確認方法 開発者が網羅的に確認項目を作成する 変更点に絞り込んで動作確認しやすい 移行方法 人間が移行ガイドに沿って移行する AIに移行させる
14. © 2019-2026 OPTiM Corp. All rights reserved. 14 AIが作業したことに対して責任を持つのは人 ◼AI Slopへの対策を入れる ◼要所は人がレビューをする ◼バグが出ることを前提に、移行作業を進める ◼動作確認やテストが大事になる 動作確認やテストがボトルネックになる ◼AI Agent登場後に開発プロセスにおいて、動作確認やテストがボトルネック化する現象と同じ 顕在化した問題 AI Slopとは 労力や意味の欠如と圧倒的な数量を特徴とする、 生成人工知能技術を用いて生成された文章や画像などの低品質なメディアを指す用語である[1][4][5]。 https://ja.wikipedia.org/wiki/AIスロップ
15. © 2019-2026 OPTiM Corp. All rights reserved. 15 next-devtools-mcp には browser automation の導線がある 最低限の確認を代行できる ◼画面が表示されるか ◼ルーティングが壊れていないか ◼フォームや検索が崩れていないか ◼ブラウザ上でエラーが出ていないか next-devtools-mcpの偉い機能 https://github.com/vercel/next-devtools-mcp
16. 16 © 2019-2026 OPTiM Corp. All rights reserved. テストプロセスが成熟したら フレームワーク移行の関係者それぞれの視点
17. © 2019-2026 OPTiM Corp. All rights reserved. 17 フレームワークの利用者 ◼大きな不安を、小さな確信の積み重ねに変えられる ◼柔軟にフレームワークやライブラリを再選択することができる マネージャー ◼安定した品質でサービスを提供できる フレームワークの開発者 ◼移行ドキュメントを充実させることを引き換えに、破壊的変更を出しやすくなる ◼よりAIフレンドリーなフレームワーク・ライブラリ開発に進む フロントエンドに関わるエンジニア ◼破壊的変更の許容ハードルが下がる ◼破壊的変更を前提にフレームワーク、ライブラリに依存しないようなアプリ作りをする ◼フレームワーク、ライブラリを行き来しやすくなる テストプロセスが成熟したら
18. © 2019-2026 OPTiM Corp. All rights reserved. 18 移行作業はAI Agentが引き受ける 移行時の動作確認がつらくなる
19. © 2019-2026 OPTiM Corp. All rights reserved. 19 フレームワークの利用者 ◼移行作業の省力化の恩恵を引き換えに動作確認コストの比重が大きくなる マネージャー ◼移行作業のコスト省力化を引き換えにジュニアエンジニア育成の場を失う ◼将来的にはテストの維持コストが発生する フレームワークの開発者 ◼破壊的変更を出しやすくなる ◼一方で、移行ドキュメントの整備が開発者の責務として重くなる フロントエンドに関わるエンジニア ◼破壊的変更が増えることに適応する ◼一方で恒常的にテストと向き合うことになる 移行作業はAI Agentが引き受けることによる影響
20. © 2019-2026 OPTiM Corp. All rights reserved. 20 フレームワークやライブラリの破壊的変更の許容されていく 破壊的変更が活発になるかはわからないが、動作確認やテストの重要度は高くなる 現実問題では動作確認やテスト戦略、テスト文化の定着が難しい 品質担保がボトルネックになるため、テストの導入とテストの勉強が必要になる 未来予想の批評は楽しい まとめ 出典： ［入門］ Webフロントエンド E2E テスト ――PlaywrightによるWebアプリの自動テストから良いテストの 書き方まで https://gihyo.jp/book/2024/978-4-297-14220-9 ソフトウェアテスト徹底指南書 〜開発の高品質と高スピードを両立させる実践アプローチ https://gihyo.jp/book/2025/978-4-297-14909-3
21. © 2019-2026 OPTiM Corp. All rights reserved.