こんにちは！リンクアンドモチベーションでフロントエンドエンジニアをしている中上です。
本記事は2025年10月25日（土）に開催された『Vue Fes Japan 2025』で登壇した内容をテックブログ用に書き起こし、まとめたものです。
当日は本当にたくさんの方に聞いていただくことができ、嬉しい限りでした。「VueとAIは相性が悪い」という都市伝説について登壇したのですが、より多くの方の誤解を解きたかったのでブログにしました。
Vue好きな方もそうでない方もぜひ読んでください。
セッション概要
登壇資料
はじめに
こんにちは！株式会社リンクアンドモチベーションでフロントエンドエンジニアをしている中上と申します。
突然ですが皆さん、Vueは好きですか？（この記事を読んでくださっているあなたは、きっと好きですよね！）
私も皆さんに負けないくらいVueが大好きです。
そんな私が最近気になるのは、「生成AIを使うならReact」という風潮です。Reactが悪いわけではありませんし、私も良いフレームワークだと思っています。
しかし「React以外、つまりVueはAIと相性良くない」になっちゃったら「それは違うだろう」「まずいぞ」と。
それなら自分自身が「そんなことはない」と否定する一つの事例になるべく、半年間VueのプロダクトでAI活用に挑戦してきました。
その結果、Vueでの開発の全工程でAIを活用できるようになり、「AIが全て実装したPR（プルリクエスト）」が全体の60%まで到達しました。つまり、開発の半分以上をAIが担っている状態です。
この実例をもとに「VueはAIと相性が良くないのか？→そんなことは全然ないよ！」というお話をさせていただきます。
AI活用の3つの実践例
活用例1：コンポーネントの実装
まず、実現できた活用例の一つ目は「コンポーネントの実装」です。
最近事例が増えていますが、Figmaで設計されたデザインからコンポーネントをAIに生成させています。
Figma MCP（Machine Comprehension Platform/Mechanism）を使ってFigmaからデザインデータを読み込ませ、そのデータをもとに、AIにコンポーネントを作成させます。
加えて、プロダクトのデザインガイドラインに沿ったコンポーネントにするために、デザインシステムの情報もAIに読み込ませます。
弊社で採用しているデザインシステム管理ツールであるSupernovaのデータもMCP経由でAIに読み込ませることで、生成されるVueコンポーネントの精度をあげるようにしています。
【活用ポイント】
よくあるのが「画面を丸ごと指定してコードを生成させる」ケース。
人間が一画面丸ごと作るのが大変なのと同様に、AIも丸ごと全部じゃ精度が下がってしまいます。
これで「思ったのと違う→VueとAIの相性は悪い」と判断されるのは心外です。
押さえていただきたいのは、コンポーネントごとに分割して生成させることです。
タスクをきちんと分解して、コンポーネントごとに一つずつ実装を進めることで、全体としての精度を保つことができます。
ここを押さえればVueでも十分にAIを活用することができます。
活用例2：ロジックの実装
次に、コンポーネントが実装できたら「ロジックの実装」もAIにやってもらいたいですよね。フロントエンドでは通信系の処理が多いためこれを例に挙げます。
人間がAPIの設計を行いOpenAPIを作成します。これをAIにインプットすると、まずAPIクライアント（APIを叩く処理）を実装させます。
弊社ではデータフェッチのキャッシュ管理に Pinia Colada(https://github.com/posva/pinia-colada) を採用しているため、更新系の処理はCommand、取得系の処理はQueryと、AIがルールに基づき適切に判断し実装してくれます。
生成されたコードには必ずユニットテストを書くルールになっているため、AIはユニットテストを作成し、さらにAPIのユニットテストではMSW (Mock Service Worker)を使ってAPIモックを行うルールに基づき、MSWのモックも作成します。
これらの流れを全てAIが自動で実行してくれます。
【活用ポイント】
よくあるのがコード生成を指示した後に「やっぱこれをやって欲しかった」「このライブラリを使って欲しかった」といった暗黙的なルールを都度後出しするケース。
これで「自分でやった方が早かった→VueとAIの相性は悪い」と言われるのは心外です。
問題の原因は、暗黙的なルールを言語化していないことです。なので、押さえるべきポイントは明確なルールを設定し、AIに教えてあげることです。
例えば、「QueryとCommandに分け、Pinia/coladaを使ってください」「Queryはこういう書き方で、こういう観点をテストしてください。」といった期待値をきっちりAIに伝えましょう。
また、QueryとCommandのように責務や関心ごとでレイヤーを区切ることで、そのレイヤーに対しより具体的でより明確なルールを書くことができるようになります。
このような点を押さえればVueでも十分にAIを活用することができます。
活用例3：PRレビュー/QA
最後に、作成したコードに対する「PRレビュー/QA」です。
現在、弊社ではPRを出すと複数のAIがこぞってレビューをしてくれます。例えば「コーディング規約に基づくコードレビュー」「アーキテクチャ設計に基づく設計レビュー」「修正内容に基づくテスト観点のレビュー」です。
【活用ポイント】
目的が曖昧なまま「このPRレビューして」と依頼すると、AIは一般的なことや無難なことしか言えず「使えない」と判断されがちですが、これもまた心外です。
押さえるべきは、明確なレビュー観点と必要十分な情報を与えることです。
例えば「テスト観点のレビュー」の場合は以下のような情報を提供することで、より精度の高いレビューが期待できます。
- E2Eテスト観点に基づいてレビューして欲しい。 → E2Eテスト観点を言語化してAIに提供する。
- 修正内容に基づいてレビューして欲しい。→ 「PRのDiffがAPI関係の場合は結合観点のレビューを中心にすれば良い」というルールを提供する。
- 影響範囲に基づいてレビューして欲しい。→ 依存関係グラフを用いて影響範囲をツールで算出した結果を提供する。
このような点を押さえればVueでも十分にAIを活用することができます。
結論
これまで話したとおり、活用ポイントを押さえることでAI活用を進めてきましたが、ご覧の通り、これまでの工夫はフレームワークに依存していません。
結局のところ、フレームワークの影響よりも、「AIの働きやすさ」の方がはるかに重要であるということです。
したがって、「VueとAIの相性が良くない」というのは全くの誤解であると言い切れます。
おわりに
AI活用で成果を出すためにやったことは、次の3つだけです。
- 問題を小さく分解する
- 明確なルールを設定する
- AIが扱える必要十分な情報を揃える
しかし、この「3つだけ」を実践するのがとても大変でした。
自分たちが暗黙的に持ってたこだわりやルール、基準を根気強く言語化し続ける必要があったからです。
それでもやってこれたのは「VueでAIが使えることを証明したい」「これが出来たらすごいぞ、やってやろう」というプロダクトや技術に対する「情熱」や「こだわり」、「好き」という気持ちが支えてくれたからだと思います。
そう考えると、AIの登場によってフレームワークの違いによる影響が小さくなっていくことで「好きを諦めなくていい」時代が来るんじゃないでしょうか？そう考えると少しワクワクしてきませんか？
ということなので、「Vueが好き」だと手を上げてくださった方（そしてこの記事を読んでくださってる方！）は、ぜひ明日からVue使っていきましょう！
登壇を終えて
昨年に続いて2回目の登壇となりましたが、毎回スタッフの皆さんや会場の温かい雰囲気に助けられて、今回も緊張はしつつも楽しく話すことができました。
終わった後も多くの方から温かい言葉をいただき、「登壇してよかった」と心から思える時間でした。こんな素敵なイベントを開催してくれている運営の皆様には本当に感謝です。
こんな素敵なイベントがこれからも長く続き、より多くの人が参加してくれる場になるよう、Vueとそのコミュニティをより一層盛り上げていきましょー！
コメント