2025年11月、東京で開催された
本記事では当日の様子をダイジェストで紹介する。
Keynote Vue Vite Update（Evan You氏）
KeynoteではVue.
Vueは今、非常に安定し、成熟したフレームワークだ。そして、Vue 2からVue 3への移行があったこともあり、私たちの主な焦点は安定性
Vue.jsの成長と今後
2025年10月13日時点でVue.
Vue 3は現在、Vue全体の利用の77.
Vue 3.6の主要機能
Vue 3.
- alien-signalsの採用
-
Vue 3.
6では、新しいリアクティビティエンジンとしてalien-signalsが採用される。 alien-signalsはVueコアチームメンバーのJohnson Chu氏によって開発され、JavaScript実装の中で最速のシグナル実装となっている。Svelte 5やSolidJSなど、他のフレームワークでもシグナルパラダイムが広く採用されている[2]。
- Vapor Mode
-
Vapor Modeは、極限のパフォーマンスを実現するための新しいオプトインコンパイル戦略だ[3]。Vueのアーキテクチャにより、既存コードに影響を与えることなく実装が可能で、アプリケーションの一部から段階的に採用できる。
Vapor Modeは互換性に重点を置いており、通常のVueとVapor Modeで同じAPIを使用できる。多くの場合、既存のVue単一ファイルコンポーネントがそのままVaporコンポーネントとして動作する。
同じAPIで動作しながら、JavaScriptのサイズが小さく、メモリ効率が高く、パフォーマンスが大幅に向上する。
Vapor Modeの開発には時間がかかっているが、これはVueの全機能との機能面での同一性を確保する必要があるためだ。teleport、transition、async component、scoped stylesなどの組み込みコンポーネント、そしてサーバーサイドレンダリングアプリケーションのハイドレーションなど、高度な機能の実装が必要となっている。
現在、VitePressのデフォルトテーマをVapor Modeで実行でき、すべてが正しくハイドレートされて動作する段階に到達している。
最新のJS Framework Benchmarkでは、Vue Vapor ModeがSvelteやSolidJSを上回るパフォーマンスを記録し、現在の主流なフレームワークでは最速となっている。
Vue 3.
Vue Language Tools 3.0
今年初めにリリースされたVue Language Tools 3.
重要な改善点として、ハイブリッドモードがデフォルトで有効になり、大幅な安定性向上が実現された。また、Johnson Chu氏との協力により、以前はInsiderプログラムで提供されていた高度な機能がすべてのユーザーに公開されるようになった。
JavaScriptビルドツールのこれまでと、現在のVite関連ツールの状況
VoidZeroは、JavaScriptのビルドツールを開発する会社だ。Evan You氏は、なぜJavaScriptにビルドツールが必要なのかという基本的な問いから説明を始めた。
JavaScriptの高度化・アプリの複雑化
JavaScriptは元々スクリプト言語として発明され、Brendan Eich氏は10日間でこの言語を作成した。当時、現在のような複雑なアプリケーションを構築することは想定されていなかった。しかし現在、ウェブ上でより複雑で野心的なアプリケーションが構築されており、スケールが大きくなるにつれて課題も増えている。
ファイルが大きくなりすぎれば、モジュールに分割する必要がある。ネットワークリクエストが多すぎれば、バンドリングが必要になる。ES2015が登場した際、すべてのブラウザが新機能をサポートしていなかったため、Babelのようなコンパイラが発明された。ファイルが大きくなれば、読み込み速度を改善する必要がある。テストランナー、リンター、型チェッカー、フォーマッターなども必要になる。そしてビルドが大規模で複雑になると、ビルドに何分もかかるようになり、モノレポキャッシングランナーなどが使われるようになった。
第一世代と次世代のツール
初期のJavaScriptビルドツールは、JavaScript自体で書かれていた。Babel、Acorn、Esprimaなどがその例だ。これらはNode.
現在よりも5年ほど前に、次世代ツールが登場した。それらはJavaScriptのために作られているが、ネイティブ言語で書かれている。SWC、Oxc、Biome、esbuild、Rspack、turbopackなどがその例だ。これらのツールの多くはRustで書かれている。
VoidZeroではRustを選択した。これはチームが最も慣れており、パフォーマンスとその他の要素の適切なバランスを持つ言語だと考えているためだ。
一般的な目安として、ネイティブ言語で書かれたツールは、JavaScriptで書かれた同等のツールより50〜100倍高速だ。JavaScriptも高速にできるが限界がある。JavaScriptは本質的にシングルスレッドであり、完全な並列化は非常に困難だ。しかしネイティブ言語は複数のコアを活用でき、よりメタル
これらの次世代ツールで驚異的なパフォーマンス向上が見られているが、まだ断片化されている。最新のツールスタックを構築するには、多くの異なるツールを組み合わせる必要がある。また、1〜2年ごとに新しいツールに移行する必要があり、開発者は疲弊している。
VoidZeroの背後にあるアイデアは、統一されたツールチェーンだ。
パーサーから始め、その上にトランスフォーマー、リンター、フォーマッター、ミニファイアを構築する。そしてそのバンドラーを使ってViteを動かし、ViteでVitestを動かすことで、すべてが同じAST形式を使用し、スムーズに連携する統一されたツールチェーンを実現する。
各ツールの最新状況
Viteの成長
Viteは現在、週間3600万ダウンロードに達しており、過去1年で100%以上の成長を記録した。
Vitest
Vitestは多くのエンタープライズアプリケーションで急速にJestを置き換えている。
Rolldown
RolldownはRustベースのバンドラーとして開発が開始された。当初はRollupの移植として始まったが、最終的にEsbuildの速度、RollupのAPIサーフェス、Webpackの高度な機能を兼ね備えたものに進化した。
1年前はダウンロード数がほとんどなかったが、現在は大規模企業の本番環境で使用されており、ダウンロード数が急増している。
Oxc
Oxc自体
oxlint
oxlintはOxc上に構築されたリンターで、ESLintの直接的な置き換えとして設計されている。Rustで書かれ、マルチコアを活用できるため、50〜100倍高速だ。
600以上のESLintルールが移植されており、ルール数は増え続けている。また、型対応リンティングの実験的サポートも含まれている。
ESLintでは、型対応リンティングにTypeScript ESLintを使用する必要があるが、これはtscを経由するため非常に遅い。一部の企業のコードベースは非常に大きく、メモリ不足になるため型対応リンティングをまったく実行できない。
幸い、TypeScriptチームはTypeScriptをGoに移植している
tsgolintのパフォーマンスは、TypeScript ESLintより約10〜15倍優れている。これはoxlint自体と比較するとまだ遅いが、現在のESLintワークフローよりもはるかに高速だ。oxlintは数千のファイルをミリ秒でリントできるが、tsgolintはそれを8〜10倍遅くする。
oxlintはカスタムJSプラグインサポートも提供する。これは重要な機能だ。世界中に非常に多くのカスタムESLintプラグインとルールがあり、人々はそれらに依存している。これらのルールをサポートできなければ、エコシステム全体を移行させることはできない。
oxfmt
oxfmtはOxc上に構築されたPrettier互換のフォーマッターだ。現在アルファ状態で、npmで公開されており試用可能だ。
Prettierとのテスト適合性は92%。現在も増加中だ。パフォーマンス面では、同じくRustで書かれたBiomeの2〜3倍、Prettierの45倍高速だ。
単なるPrettierの厳密な移植ではなく、行の折り返しオプションに関してより柔軟性を追加している。Prettierの主な問題の1つは、行の折り返しに関して非常に厳格であることだ。内部でRFCを作成しており、Prettierを使用したいが行の折り返し動作が嫌いな人々に適した中間点を提供する予定だ。
oxfmtには、インポートソート、Tailwind CSSクラスソートなど、スタイリスティックおよびソート機能も含まれている。コードを美しく見せることに関連するすべてがoxfmtに統合される。
現在、oxfmtはJavaScriptとTypeScript以外のファイル拡張子のサポートが限定的だが、短期的にはPrettier自身のプラグインシステムを通じてサポートし、徐々にこれらの追加機能をRustに移植していく予定だ。
Rolldownの進化
1年前、Rolldownはまだ準備ができていなかったが、過去1年でより多くの機能を追加し、より高速になった。
現在、Rolldownはesbuildよりも一貫して高速だ。最近、誰かがAWS LambdaビルドをesbuildからRolldownに置き換え、マルチコアセットアップで2倍のパフォーマンス向上を実現した。また、同じくRustで書かれたRspackよりも3倍高速だ。
バンドルサイズの大幅な改善も実現しており、ミニフィケーション、ツリーシェイキング、出力の最適化において最先端に近づいている。
ウェブサイト構築サービスを提供するFramerは、esbuildからRolldownに切り替え、現在本番環境で顧客ウェブサイトの100%をRolldownでバンドルしている。過去1年にわたって深く協力してきたため、多くの機能リクエストと安定性の問題が本番ワークロードで検証されている。
また、Angular BuildでもRolldownが実験的に使用されている。次期バージョンのAngularでは、追加のチャンク最適化にRolldownが使用される可能性がある。
2024年12月のRolldownの最初のベータリリースと最新版を比較すると、1年未満でRolldownは33%高速になり、バンドルサイズは34.
Vite 7.0とVitest 4
Vite 7.
Vitest 4は今週リリースされた[4]。ブラウザモードが安定版になり、同じVitest設定でコンポーネントやトランスフォームのユニットテストを作成でき、Playwrightを通じて実際のブラウザで実行される。これにより、インタラクションテストのためにより実際の環境に近いテスト結果が得られる。Vitestにはビジュアル回帰テスト
Rolldown搭載のVite
Rolldownを構築している理由は、それをViteに統合するためだ。現在、完全な互換性に近づいている。
RolldownでViteを完全に動かすためには、バンドラー作業以外にも実際の作業が必要だ。Viteには以前すべてRollupプラグインとして実装されていた独自の特別なロジックがある。システム全体を高速化するため、これらの内部ViteプラグインのほとんどもRustに移植した。Rolldown搭載のViteでは、これらがデフォルトで有効になっている。
Rolldown搭載のViteでは、現在のViteと比較して本番ビルドが最大20倍高速になる。これはVite 8ベータとしてまもなくリリースされ、完全にRolldownを搭載したViteをVite 8として2026年初頭にリリースする予定だ[5]。
Module Modeの導入
Vite 8で登場するもう1つの重要な機能は、フルモジュールモードだ。これは現在まだ実験的で、作業を開始したばかりで予備的な結果が出ている。
合成ベンチマークでは、10,000のReactコンポーネントを読み込んでいる。実際のアプリはおそらくそこまで大きくないが、非常に大規模なアプリケーションでViteを使用したことがある場合、開発サーバーを最初に起動してページを開こうとするときに非常に遅い時間を経験したことがあるだろう。ページが読み込まれるのを待って、スピンし続けるのを見ることになる。
これはViteがデフォルトで提供するアンバンドル開発サーバーの根本的な制限だ。フルモジュールモードは本質的にバンドリングに戻ることであり、依存関係とコードの両方を非常に高速に処理できるバンドラーを持っているためだ。
フルモジュールモードにより、サーバー起動とページ読み込み時間を15倍削減でき、ページのリロードは10倍高速になる。現在、フルViteアプリケーションであるLinearでこれをテストし、開発エクスペリエンスを改善しようとしている。
JavaScriptプラグインの高速化
驚異的なパフォーマンス向上が見られているが、これらはすべて純粋なRustアプリケーションと現在の状況を比較したものだ。
Rustは高速だが、JavaScript開発者はJavaScriptでプラグインを書くことを好む。VueやSvelteのようなフレームワークコンパイラもまだJavaScriptで書かれている。ESLintのカスタムプラグインやルールも多数あり、ReactコンパイラもまだJavaScriptだ。
これらのJavaScriptベースのトランスフォームを、
すべてをRustで書き直すことは現実的ではないため、他の方法を見つける必要がある。答えは、JavaScriptプラグインを高速にすることだ。
Raw Transfer for AST
多くのカスタムプラグイン、特にトランスフォームプラグインは、JavaScriptで追加のパースを行っている。Rustバンドラーはすでにコードをパースしており、ASTを持っているのに、トランスフォームプラグインを実行しようとするとJavaScriptパーサーを使ってコードを再度パースしている。これは非常に無駄だ。
最初のアイデアは、Rust側にすでに存在するASTをJavaScript側に渡すことだ。しかし、これも遅いことが判明した。
例として、BabelでJavaScriptファイルをパースする時間とOxcでのパースを比較すると、Oxc自体はBabelより約19〜20倍高速だ。しかし、ASTをRustからJavaScriptに送信しようとすると、ほぼ同じ速度になってしまう。メモリ内のデータをクローンし、RustとJavaScriptの境界を越えて送信するコストが非常に高く、全体を14倍遅くする。
この問題について、Oxcの設計のおかげで、Rust側のASTはアリーナアロケーターと呼ばれる連続したメモリチャンクに保持されているため、そのメモリチャンクをクローンせずに共有アレイバッファを使用してJavaScriptに直接送信
転送自体はこれでよくなるが、JavaScript側でメモリをオブジェクトに変換する必要がある。このステップはデシリアライゼーションと呼ばれる。デシリアライゼーションには依然として多くの時間がかかる。また、多くの小さなASTノードを割り当てるためガベージコレクターも必要になり、これも遅くなる原因だ。
遅延デシリアライゼーション
リンタールールを実装する際、すべてのASTノードにアクセスする必要はないことに気付いた。たとえば、no-debuggerリンタールールを実装している場合、debuggerステートメントだけを気にすればよい。それ以外のすべてを無視し、debuggerステートメントのASTノードだけをインスタンス化できればどうだろうか。
これが遅延デシリアライゼーション
この仕組み
Fast Magic String Transform
Rolldownでは、fast magic string transformという新しいトランスフックを提供する。Viteプラグインのトランスフックの中で、遅延デシリアライゼーションを使用して現在のファイルのASTを直接受け取ることができる。その上で、magic string APIを使用してコードを操作できる。
magic-stringは非常に人気のあるJavaScriptユーティリティで、JavaScriptコードを取得して操作できる。テキストを変更したり、追加したり、移動したりでき、最終的に新しい文字列とそれらの変更のソースマップを生成できる。これはViteプラグインで非常によく使用されており、実際にはフレームワークコードでも使用されている。
現在、magic stringを使用する場合、Rustからコード文字列を取得し、ASTをパースし、ASTをトラバースし、メソッドを呼び出す必要がある。JavaScript側で最終的な文字列とソースマップを生成し、最終的にそれらをRustに戻す。すべての中間ステップがJavaScript側で発生するため、遅い。
できるだけ多くの作業をJavaScriptからRustに移動したい。
fast magic string transformの後は、RustからrawのASTを取得する。これははるかに高速だ。JavaScript側では、ASTを遅延トラバースする。興味のあるノードだけを訪問する。そしてmagic stringメソッドを呼び出す。これらのメソッドの呼び出しは非常に安価だ。呼び出した瞬間には実際には何もしないためだ。これらのメソッド呼び出しをバッファリングし、メソッド呼び出しとその引数だけをRustに送り返す。転送する必要があるデータを最小化する。そして最終的に、最終的な文字列生成とソースマップ生成をRustに処理させる。
これにより、作業の大部分をJavaScriptからRustに戻し、2つの言語境界間の転送コストも最小化する。これがRustベースのビルドツールチェーン上でJavaScriptトランスフォームプラグインを高速化する方法だ。Vite用のカスタムトランスフォームプラグインを書いている場合は、Vite 8が出たらこれを検討し、移行することを強く推奨する。
Vite+：統一ツールチェーンの実現
多くのオープンソースをリリースし、さまざまなプロジェクトを行っているが、会社を立ち上げたときに話した統一ツールチェーンビジョンはどうなったのか。
Vite+は、WebとJavaScript用の統一ツールチェーンだ。viteplus.
高レベルでは、Vite+はツールチェーンだ。Vite自体のドロップインリプレイスメントである。手元にViteアプリケーションがある場合、Vite+にエイリアスするとアプリケーションはまったく同じように動作し続けるが、vite-lint、vite-format、vite-test、vite-taskなどの追加コマンドにアクセスできるようになる。
独自の依存関係の組み合わせを設定した経験があれば、これらすべてに対して単一の依存関係を持つことの良さが分かるだろう。
Vite+プラグインの拡張
Vite+の次のステップは、プラグインの機能を拡張することだ。Vite+自体がViteのスーパーセットであるように、Vite+プラグインもViteプラグインのスーパーセットだ。
今のViteプラグインはViteに機能を追加して、トランスフォームプラグインを注入したりといった、主にビルドに関することができる。Vite+プラグインは、たとえばカスタムジェネレーター、スキャフォールド、カスタムテスト環境、テストアサートマッチャーを注入できる。独自のリンタールールを注入できる。プラグインはツールチェーンのより多くの側面にアクセスできる。
また、フレームワークをViteプラグインとして提供するトレンドがある。たとえば、TanStack StartやSvelteKitなどがViteプラグインとして提供されている。理論的には、Vite+により、プラグインとしてのこれらのフレームワークは、ツールチェーンの他のコマンドに対して独自の追加のフレームワーク固有の拡張機能を提供できるようになる。
AIとの統合
長期的には、統一ツールチェーンがAIとどのようにうまく連携できるかについても考えている。現在、AIを使用して独自のフレームワークを構築する開発者がますます増えている。AIエージェントやAIアシスタントコードツールがこれらの開発ツールと連携することも増えている。
エージェントとツールは密接に関連していると考えている。エージェントはツーリングレイヤーからの優れた支援を必要としている。統一ツールチェーンにより、エージェントがそれとどのように連携するかを理解しやすくなる。一元化されたドキュメントを持つことができ、エージェント指示に入れるためのデフォルトの推奨プロンプトを持つことができる。エージェントと連携していることに気付いたとき、開発エクスペリエンスに小さな微調整を加えて、エージェントとうまく連携させることができる。
たとえば、ブラウザランタイムエラーをコンソールに転送することに取り組んでいる。エージェントが正確に何が起こっているかを理解できるように、人間の可読性ではなくエージェント向けに最適化された出力にも取り組んでいる。全体的な目標は、AI支援でVite+を使用する際の速度、精度、トークン効率を向上させることだ。
Vite+の価格設定
Vite+には価格設定要素がある。VoidZeroは企業であり、持続可能なオープンソースを実現したいと考えている。
Vite+はオープンソースプロジェクトによって支えられている。現在オープンソースであるすべてのもの、つまりVitest、Rolldown、Oxcは、MITライセンスのままで永続的にオープンソースとして提供される。これらを使い続けることについて心配する必要はまったくない。
Vite+は完全に新しいものだ。現時点では予備的な計画だが、価格設定の詳細については後日発表される予定だ。詳細についてはウェブサイトとブログ投稿で確認できる。
主要フレームワーク開発者が語る「AI時代のWeb開発」
Vue、React、Svelteの開発者が一堂に会し、AI時代におけるフレームワーク開発の未来について議論した。
登壇したのはVueとViteの作者Evan You氏、Reactコアチームの一員でReduxやoverreacted.
Vueの作者、Reactのオピニオンリーダー、Svelteコミュニティでtoolingなどで活躍する人物が一同に会した。
プロダクションコードでAIコーディングは使えるのか
冒頭、モデレーターから
Evan You氏（Vue）の慎重な姿勢
Evan氏は、そもそも最近は
一方で、VoidZeroでのRustプロジェクト
ただし、AIコーディングが成功するには条件があると指摘する。コードは比較的新しく、よく構造化されている必要がある。リポジトリ内に良いコンテキストドキュメントがあることも重要だ。そしてツールチェーンと言語は厳格で予測可能でなければならない。そうでないとAIがミスを犯しやすくなる。
Evan氏は、
自分で手を動かす代わりに、AIという部下に何をすべきか指示を出し、その作業を管理する。
Dominik G氏の明確な拒否
対照的に、Dominik氏は明確にAIツールを使わないと宣言した。
「私は自分でコードを書くことを好みます。自分のミスに責任を持ちたいのです」
フレームワークのような低レベルコードでは、LLMの学習データが少なすぎて良い出力が得られないと説明。
Dan Abramov氏の実験的活用
Dan氏は、最近の2つのサイドプロジェクトを完全にVibe Codingで構築したという。
1つ目は、TypeSpecという言語のためのプラグイン開発だった。TypeSpec自体についても、コンパイル先のフォーマットについても何も知らない状態だったが、それがVibe Codingに最適なプロジェクトだったと振り返る。週末の数日間で、完全なテストスイートを含めて動作するものを作ることができた。何度かコントロールを取り戻さなければならなかったが、知らないドメインで大きな進歩を遂げられることに感銘を受けたという。
2つ目は趣味で作っているソーシャルアプリだ。こちらも一切コードを書かず進めた。ルートを作ってスタブ化したり、望むアーキテクチャを説明すれば何度か試行錯誤の末にレイヤードアーキテクチャを作ってくれたりと、有用な場面もあった。
しかし課題も多いと率直に語る。AIが同じファイルのコピーを2つ作り、それぞれに異なる変更を加えようとして、完全な混乱に陥ったようなケースもあった。手作業なら30分で済むところ、Vibe Codingだとクリーンアップに3時間かかってしまった。こういった愚かなミスもたくさんしたという。
それでもDan氏は全体としてはVibe Codingを楽しんでいる。Vibe Codingにはガイドラインが必要で、何をしているか理解し、レビューできる必要があると結論づけた。コースを逸れ始めたらすぐに軌道修正しなければならない。放置すると混乱が混乱を生み、さらなる混乱を作り出してしまうからだ。
AIは「請負業者」か「ペアプログラマー」か
議論は、AIコーディングの未来の方向性へと移った。AIを外部の請負業者のように扱うべきか、それともペアプログラミングのパートナーとして扱うべきか。
Dan氏の柔軟なアプローチ
Dan氏は両方を混在させていると説明した。時にはAIに大胆な再設計を任せ、時には細かく指示を出す。
AIの得意分野として
特に効果的だと感じたのはテスト作成だ。Dan氏自身はテストを書くのは好きではないが、どんな形にすべきかは分かっている。趣味のコンソールアプリプロジェクトで、普段なら人生で絶対に書かないようなテストスイートを、AIに1時間で作ってもらった。期待される出力をチェックするエンドツーエンドのテストスイートを含め、プロフェッショナルなプロジェクトで見られるような仕上がりだったという。
心理的な側面も重要だと指摘する。できるけど、やりたくない作業にAIは最適だと。
Dominik氏の警告
Dominik氏は、ビジネスサイドがAIで開発者を排除したがっているという現実をユーモラスに指摘しつつ、懸念を表明した。
Dominik氏は自身の最初の仕事でビジネス側がまだ作っていない機能を公開して顧客に販売し、それから開発チームに伝えてきたという事件を振り返った。週末の2日間で作らなければならなかった。このことから読み取れるのは、もしビジネス側がAIを使って機能追加ができるようになれば、どんどん機能を作り出してしまうだろうということだ。
しかし、無制限に機能を作れる能力は、優れたプロダクトにとって良いことではないとDominik氏は強調する。経験上、機能開発における最も重要な決定は、何を追加しないかを決めることだ。これがプロダクトの真のコアアイデンティティを保つことにつながる。
AIに自分たちのアイデンティティを理解させることは非常に難しい。それは学習データセットにないからだ。平均的なものしか作れないのだ。
Evan氏のバランスの取れた見解
Evan氏は
Vibe Codingという言葉には、そもそも
一方、より構造化されたアプローチもある。今では、CursorやClaudeでプランモードを使うべきだという話をよく聞く。まずプランを立てさせ、何度か議論を重ね、最終的に選んで実行する。このように、プロセスにより多くの構造とコントロールを持ち込むことができる。
人々はAIをより良く使うための方法論やスキルを発見しつつある。最終的には、ほとんどのエンジニアが何らかの形でAIを使うようになるだろう。ただし、取り組んでいるプロジェクトの種類によって、使い方は大きく異なる。
実際に1万人が参加したオンラインVibe Codingハッカソンの審査員を務めた経験から、Evan氏は厳しい現実を語った。提出された作品の90%は控えめに言っても、そのコードのおそらく99%がslop
簡単になりすぎると、人々は考える時間を減らしてしまう。だから、目標が良いソフトウェアを作ることなら、AIを使っても考える時間が必要だ。AIをうまく使う方法を学ぶ必要がある。
Evan氏は将来、ソフトウェアエンジニアの能力は2つの側面で測られると予測する。
1つは、本当に難しい問題を解決するアルゴリズムを考え出す純粋な能力だ。Evan氏自身、この点では得意ではないと認める。
もう1つは、問題を高いレベルから見て、良い計画、良い設計、良い推論を思いつき、トレードオフを判断し、最終的に正しい設計決定を下す能力だ。そして実行の詳細を決める。このスキルセットの部分が、将来より重要になると考えている。なぜなら、実行部分がAIによってどんどん簡単になっているからだ。
フレームワーク設計はAIを考慮すべきか
AIの台頭は、フレームワークの設計自体にも影響を与えるのだろうか。
Dominik氏の「人間第一」原則
Dominik氏は明確な立場を示した。
ドキュメントをAIのために要約することについて、チーム内で議論があったという。ドキュメントは多くの単語を含むため、トークン数が非常に高くなる。そこで、AIがアクセスしやすく、よりトークンを節約できるように、ドキュメントを要約してはどうかという提案が出た。
しかし、すべてのドキュメントを要約するのは長く退屈な作業だ。長く退屈な作業にはAIを使うべきと考えるかも知れないが、自分たちのドキュメントを要約するためにAIを使うことは、情報の損失を伴う非可逆
AIは要約に小さなミスを犯す可能性があり、それが見過ごされて、その要約を別のAIエージェントに渡してサードパーティのアプリを作らせると、同じミスをまた犯し、それが増幅される。推論の連鎖で新しいステップに進むたびに、ミスの可能性があり、最終結果にエラーが含まれる確率がはるかに高くなる。だから、それはやりたくない。
同時に、ドキュメントがLLMにとって理解しにくいなら、人間にとっても理解しにくいという認識に達した。AIにとって冗長なら、それは人間にとっても読みづらいものだ。こういった要約こそがドキュメントにもたらされるべきだ。
だからドキュメントでは非常に簡潔であろうと努力している。もっと良くしようとしている。LLM.
興味深い取り組みとして、Svelte MCPを通じた実践的な対策を紹介した。SvelteのESLintプラグインが持つ寛容なパーサーを活用し、LLMの出力をリアルタイムで解析する。古いSvelte 4のコードを検出すると、
Evan氏のメジャーバージョン対応
Evan氏は、メジャーバージョンのアップデートがAI時代の新たな課題だと指摘した。
初期の頃、Vue関連の質問をAIにすると、Vue 2とVue 3の間を行ったり来たりしていたという苦情が多かった。Options APIとComposition APIのどちらを使うべきか決めるのも難しそうだった。データセットが更新されるにつれて改善されてきたが、フレームワークに変更を加えたり、新しいものを追加したりするとき、今ではAIを使っているすべての人々のモデルが実際に最新の情報に更新されているか考える必要がある。
そして、モデルのデータセットには常に遅延があるため、新しい主要機能をリリースするときは、それに付随するドキュメントを用意する必要がある。そうすればAIが既存のフレームワークの理解と統合できるようになる。
もし仮にVue 4をリリースするとしたら、とEvan氏は仮定の話として語る。その場合、非常に明示的な変更点リストが必須になる。それをエージェントの指示に入れて、
この懸念は一部現実的なものだ。たとえば最新のRemix 3は、AI第一を念頭に置いて設計したいというスローガンを掲げている。最終的な設計についてはまだ分からないが、少なくとも、まさに指摘されたことを実践している人々がすでにいる。新しいフレームワークを設計する際、最初からAIを念頭に置いているのだ。
Dan氏の「ローカル推論」原則
Dan氏は、Reactの核心原則である
「ローカル推論とは、限られた知識で変更を加えられることを意味します。このファイルのこのコンポーネントを変更しても、アプリの他の部分を壊さないと分かっている状態です」
これはAIのコンテキストウィンドウの制限にも当てはまる。
さらに、APIはツールから検査可能であるべきだと強調した。
「MCPを通じて公開したり、高度な開発者ツールを持つことが重要です。AIがReact DevToolsのMCPにアクセスして、
スキル
「小さな、再利用可能な指示のパックです。
フレームワークは大きくなるべきか、小さくなるべきか
AIの登場により、フレームワークの設計哲学も問い直されている。LaravelやRailsのような
Evan氏の統合アプローチ
Evan氏は、VoidZeroでの取り組みを
「すべてのフレームワークが必要とするであろう、リンティング、テスト、型チェックなどの共通基盤を見つけようとしています。AIにガードレールを与えることが重要で、これらのツールはAIが正しい軌道に留まるのを助けます」
「JavaScriptには、すぐに使える完全なツールセットがありません。それを提供したいのです」
Dominik氏の多様性の重要性
Dominik氏は、異なるフレームワークが異なるトレードオフを持ち続けることの重要性を強調した。
「Next.
「フレームワークのランドスケープが単一のソリューションに収束することはないと思います。もしそうなったら、悪いことです。なぜなら、新しいより良いものを見つけるためには、多様性と異なる探求が必要だからです」
Dan氏の互換性の重要性
Dan氏は、バージョン間の混乱を避けることの重要性を指摘した。
「異なるバージョンがある場合、一方でコンパイルできないほど十分に異なっている方がいいかもしれません。そうすれば役立つエラーメッセージが出ます。実際、互換性がないほど壊れてしまうが、修正方法を示す良いエラーメッセージがあれば、それが実現可能な移行パスになるかもしれません」
これからのエンジニアに必要なスキル
最後に、AI時代の若手エンジニアが身につけるべきスキルについて議論が交わされた。
Dominik氏の「学ぶ力」の重要性
何よりも、常に好奇心を持つ必要がある。技術は今まで以上に速く変化するので、特定のことを学ぶのではなく、学ぶスキルが重要だとDominik氏は強調する。
そしてAIが学習自体に与える影響について警告した。Dominik氏は哲学的なレベルで、AIは学習にとって本当に危険だと考えている。反復的な情報が多すぎて、意味のある学習リソースを見つけるのが難しい。もちろんAIに聞くこともできる。教えてくれと。しかし、まだ何も学んでいなければ、それが作り話なのか本物なのか判断できない。
学習には新しい課題があり、教育にも新しい課題がある。Dominik氏が描く悪夢のようなシナリオはこうだ：教師がChatGPTでテスト問題を作成し、学生がChatGPTで回答し、教師が再びChatGPTで採点する。この連鎖の中で、ChatGPTが問題を書き、答え、採点したことになる。そして最も重要な疑問が残る——学生は何か学んだのか？
「これはプログラミングだけでなく、すべての分野に当てはまります。しかし、今のところ十分な注目を集めていないと思います」
現在、焦点のほとんどは、多くの新しいアプリケーションを作れることや、誰もが自分のアプリケーションを構築できるようになることに向けられていると思う。それが十分な注目を集めているかは分からない。
個人的には、より多くのアプリケーションが必要だとは思わない。より良いアプリケーションが必要だ。だが今のところ、AIは良いアプリケーションを構築するのが得意ではない。
現在の私の雲に向かって叫ぶ老人のようなアドバイス[7]は、難しい方法で学ぼうとすることだ。Vibe CodingやAI支援に頼りすぎるのはやめよう。質問はしても解決策は求めるな。
これは多くのクライアントとの経験から学んだことでもある。彼らは自分たちの問題に対する解決策のアイデアを持ってくる。そして私は、技術的に健全な解決策を考え出す前に、彼らが実際に抱えている問題を逆設計しなければならない。
問題のドメインについて何も知らないとき、まず調査をして情報を集めなければならないのと同じだ。ただChatGPTに話して、これを解決してくれとは言えない。なぜなら、解決策が正しいかどうか分からないからだ。
だから、好奇心を持ち続け、学び続け、すぐにVibe Codingに飛びつかないこと。もちろんできるし、おそらくそれで報酬も得られる。しかし、社会全体にとって持続可能なことではない。
最後に、Dominik氏は日本への賛辞で締めくくった。初めて日本に8日間来たが、すべてに込められた歴史と職人技を本当に感謝している。それを続けてほしい、と。学習は依然としてスキルであり、工芸なのだ。
Evan氏の「基礎の重要性」
Evan氏は、実際のハッカソン審査の経験から語った。
Vibe Codingで到達できる範囲には明確な限界があり、その限界は実際の開発者としてのスキルレベルと非常に相関している。BoltやReplitで人々が作ったものを見ると、Vibe Codingでどこまで行けるかの非常に明確な限界がある。
だからこの新世代の開発者、Vibe Codingがすでに存在する分野に入ってくる人々にとって、基礎は実際に差別化要因になる。実際に物事がどう機能するかを知ることが、他の多くの人々がおそらくslopを生産することで生き延びている中で、アドバンテージになる。
人々が
知人が今、いくつかのスタートアップに助言している。そして文字通り、彼が関わっている会社のコードをクリーンアップするために飛び込まなければならなかった。なぜなら2人の創業者が全体をVibe Codingし、もう修正方法が分からなくなったからだ。
だから、AIの助けでかなり遠くまで行けるとしても、実際に高品質なコードを生産し、それが動き続け、持続可能なビジネスとして維持できるようにしたいなら、品質は依然として極めて重要だ。そして、Vibe Codingだけでは得られない。若い開発者として分野に入ってくるなら、他人のバイブコードされた混乱を修正できることで、多くの機会が得られるだろう。
Dan氏の「プロセスの重要性」
Dan氏は、実際のデバッグ体験から重要な洞察を語った。
趣味で作っているアプリでスクロールのちらつきバグが発生したとき、Claudeに修正を依頼したが
そこでDan氏は、ジュニアエンジニアに教えるように、Claudeに体系的なデバッグプロセスを指示した。まず測定可能な基準を設定し
「この種のプロセスについて知らないのは、この経験がないからだ。しかし、経験豊富なエンジニアはこのプロセスに従う方法を知っている」
さらに、こうしたプロセスは体系化可能だと指摘する。
Dan氏は最後に重要な留保を示した。
「エンジニアにとって、これらのプロセスを学ぶことが重要だ。しかし、将来的にはエージェントもこれらのプロセスを使うようになるかもしれない。だから、どんな仕事が残るのかを言うのは本当に難しい」
それぞれが最も期待していること
最後に、生成AIに限らず、各氏が今後1〜3年で最も期待していることを語った。
Evan You氏：VoidZeroの統合ツールチェーン
「私の個人的な不満は、JavaScriptにはすぐに使える完全なツールセットがないことです。LaravelやRailsのように、箱から出してすべてが揃っている、あるいはRustのCargoのようなもの。私たちが作っているものは文字通りすべてをカバーするわけではありませんが、時の試練に耐えてきたAPIデザインを、より高性能で堅牢な形でまとめて提供したい。新しい開発者が
Dominik G氏：新しいブラウザエンジンとレジストリ
「新しいWeb API、特にTemporalに期待しています。数年前と比べて、Web APIの状態には非常に満足しています。IE6を学ぶ必要がなかった皆さんは、今あるものに感謝すべきです」
「Chromium以外のブラウザエンジンが登場することを願っています。エンジン市場での真の競争です。これは本当に大きな課題ですが、誰かがこれに取り組んでくれることを願っています」
「もう1つは、JSRよりも少し優れた新しいレジストリです。現在のNPMレジストリとその内容の状態は本当にひどい。これらをより良くするためにe18eがあります」
Dan Abramov氏：ATプロトコルとオープンソーシャル
「実は、フロントエンドとは直接関係ないけれど、ちょっと関係あるものに最も興奮しています。ATプロトコルという、Blueskyが開発しているWeb標準のようなものの上に小さなソーシャルアプリを作っています」
「投稿、いいね、フォロー、コメント、チェックインなど、あなたが生成する公共データが実際に意味のある形であなたに所有されます。すべてのアプリがお互いの公開データを見て、それを集約できます。つまり、製品を移植できるのです」
「私がそれを
「アプリ間の境界をぼかす本当にクールな方向性だと思います。これがオープンソーシャルアプリを作ることを楽しくしていると思いますし、もっと多くの人がやってくれることを期待しています」
多様な発表
Vue Fes 2025では本記事で主に取り上げた以外にも多くの興味深い発表があった。
Johnson Chu氏による
映像作家の橋本麦氏による
盛況だったイベント会場
会場となった大手町プレイス ホール＆カンファレンスは、今年も大きな盛り上がりを見せていた。スポンサーブースも盛況で各社、単なる会社紹介に留まらず、技術クイズやオリジナルのノベルティ配布などを通じて参加者との交流を深めていた。また、Vue.
アフターパーティーで提供されたVueやViteをイメージしたオリジナルカクテルも、参加者同士の会話を弾ませる演出だった。
Vue、Viteの今後に期待
VueはVue 3移行後安定期に入り、ViteもRolldownの全面投入が見えてきて、それぞれ外からわかりやすい進化は減ってきている。しかし、APIの互換性や安定性を保ちつつも、開発は活発に続けられている。今後もフロントエンドの進化の最前線にいるライブラリ・