Meteor.js は2026年でもまだ通用するのか？

答えは Yes。Meteor.js は現在も活発にメンテナンスされています。公式チェンジログによれば、バージョン 3.5.2 は2026年9月4日にリリースされました。

数年前に Meteor を最後に触ったという方には意外に感じられるかもしれません。Fibers、Blaze テンプレート、そして Babel 時代の独自バンドラーの上に成り立っていたあのフレームワークは、すでに置き換えられています。そして、その後継が何であるかは、Meteor を見限る前に、あるいは自分が抱えている 2.x アプリの扱いを決める前に、理解しておく価値があります。

本記事では、Meteor が何を目的に設計されたのか、なぜ話題に上らなくなったのか、2024年から2026年にかけて実際に何が変わったのか、そして現時点で誰が使うべきで、誰が使うべきでないのかを扱います。

Meteor.js は今も使われているのか？まず証拠から

このフレームワークは一定のペースでリリースを続けています。チェンジログには、2024年7月の 3.0 から 3.5.2 まで 3.x 系で18回のリリースが記録されており、その前段には2021年1月から2024年5月まで続いた 2.x 系の17のマイナーバージョンがあります。自分で確認する際に知っておくとよい点が一つあります。meteor/meteor リポジトリは GitHub Releases を公開していないため、リリースタブは空に見えます。正典となる記録は GitHub ではなくチェンジログです。

本番環境の利用者は今も存在し、ドキュメントは最新に保たれ、コアチームは毎リリースでコミュニティのプルリクエストをマージしています。ただし、それらが Meteor を良い選択にするかどうかは別の問題であり、本記事の残りの部分でその答えを示します。

Meteor は何のために作られたのか？

2012年のローンチ以来、Meteor の設計前提は「リアルタイムアプリケーションに API レイヤーは本来不要である」というものでした。一つの言語がクライアント、サーバー、データベースクエリを横断します。サーバーは Meteor の WebSocket プロトコルである DDP 経由で MongoDB のカーソルを publish し、クライアントは Mongo のクエリインターフェースをインメモリで再実装した MiniMongo に結果をキャッシュします。サーバー側でデータが変われば、接続中のクライアントは自動的に更新されます。REST エンドポイントも GraphQL リゾルバも、状態同期のコードも不要です。

この中核の周囲に、Meteor は小規模チームが必要とするものを一式まとめて同梱していました。MongoDB 統合、OAuth プロバイダーを備えた完全なアカウントシステム、設定不要のビルドツール、そしてワンコマンドデプロイです。2012年から2017年にかけて、このパッケージは JavaScript 界のどの選択肢よりも確実に速くリアルタイムアプリを出荷できる手段であり、だからこそ多くの支持とハッカソンを勝ち取りました。

なぜ Meteor の話を聞かなくなったのか？

「React が勝ったから」というのは全体の三分の一に過ぎません。Meteor 独自のテンプレートレイヤーである Blaze は React に敗れ、その差を埋めることはできませんでしたが、より深い傷は組織的なものでした。2016年頃、Meteor Development Group は関心を Apollo と GraphQL に移し、フレームワークは目に見えて同社の優先事項から外れていきました。無料の meteor.com ホスティングは消滅しました。著名なコミュニティメンバーが去り、チュートリアルは古びていき、Atmosphere 上のパッケージは放棄されました。

そして決定的だったのは、Fibers を撤去するリリースを待ち続けた期間です。Fibers は Meteor のサーバーコードを同期的に見せていたコルーチンライブラリでしたが、Node のアップグレードを阻害し、他のあらゆる Node コードベースの動作原理から乖離していました。その撤去は、2019年10月に Tiny が Meteor を買収する以前から何年も議論されていましたが、Meteor 3.0 が出荷されたのは2024年半ばのことでした。コミュニティの多くは待つのをやめました。ブランドはテクノロジーよりも早く死に、そのテクノロジーは沈黙のなかで改善を続けたのです。

Meteor 3.0 から 3.5 で何が変わったのか？

2024年7月15日にリリースされた Meteor 3.0 は、Fibers を完全に撤去してネイティブ async/await を採用し、HTTP レイヤーを Connect から Express に差し替えました。チェンジログによれば、それ以降のリリースは一つの流れをたどっています。

個々の行よりも、この一貫した流れの方が重要です。Meteor は独自仕様のランタイムであることをやめ、普通の Node.js アプリケーションになりました。Fibers ではなく async/await、Connect ではなく Express、独自の Babel パイプラインではなく SWC と Rspack、oplog tailing ではなく Change Streams です。ただし Change Streams には前提条件があります。データベースは MongoDB 6 以降で、レプリカセットまたはシャードクラスターとして動作している必要があります。そうでない環境では、Meteor が自動的に oplog tailing またはポーリングにフォールバックします。この「普通化」こそが、このフレームワークを再評価する意味を成り立たせているものです。

2.x のコードについては、移行は形式的には機械的な作業です。同期的なコレクション呼び出しを、対応する非同期版に置き換えていきます。

// Meteor 2.x
const doc = Tasks.findOne(taskId);
Tasks.insert({ text: "hello" });

// Meteor 3.x
const doc = await Tasks.findOneAsync(taskId);
await Tasks.insertAsync({ text: "hello" });

パフォーマンスについて。Meteor 自身が Galaxy Cloud アプリで計測したビルド数値では、SWC によりビルドが約60%高速化、Rspack によりビルドが3.5倍以上高速化し、クライアントバンドルは最大88%小さくなったと報告されています。また、Meteor チームが Galaxy コンテナ上で実施した別の負荷テストでは、Change Streams 下での同時接続キャパシティが oplog より40%増加したと報告されています。これらはベンダーによるベンチマークとして受け取ってください。

メンテナンスされていることは、健全であることと同じではない

「Meteor はメンテナンスされているか」と「そのエコシステムは健全か」は、別々の答えを持つ別々の問いです。フレームワークはリリースを続けていますが、その周辺のエコシステムは依然として薄いままです。採用人材のプールは小さく、しかも10年にわたって縮小してきました。Meteor のパッケージレジストリである Atmosphere は、主流の npm が提供するものと比べればごく一部に過ぎず、手を伸ばしたいパッケージの多くは、放棄されたオリジナルをコミュニティが引き継いだフォークです。データレイヤーは設計上 MongoDB 中心なので、データがリレーショナルであればフレームワークと戦うことになります。

より大きな問題は適合性です。接続中のクライアントへソケット経由でライブデータをプッシュするという Meteor の中核的な強みは、率直に言って、今のほとんどのチームが最適化しようとしている対象ではありません。Node 案件の大きな部分はサーバーレンダリングされ、SEO 主導で、コンテンツ量の多いサイトであり、その仕事に Meteor は不適切な道具です。成功指標に Googlebot が絡むのであれば、それ向けに作られたものを選ぶべきです。

2026年に Meteor.js を使うべきか？

2026年の Meteor はメンテナンスされ、近代化されており、特定の用途群に対しては妥当な選択です。ダッシュボード、チャット、コラボレーションツールといったリアルタイム前提のアプリケーション。エコシステムの規模よりも「単一言語で API レイヤー不要」であることが勝つ社内ツール。そして高速なプロトタイピングです。2.x アプリを抱えているなら、3.x へのアップグレードパスは実在し、公式マイグレーションガイドに文書化されています。EOL のランタイム上でアプリを腐らせるよりも、その道を選ぶ価値があります。一方で Meteor は汎用のデフォルト選択肢ではなく、コンテンツサイトや一般公開の SEO 資産にこれを選ぶのは誤りでしょう。チェンジログは自分の目で確認し、リアルタイム性の適合があるならプロトタイプに対して npx meteor を走らせて、記憶の中のフレームワークではなく、今存在するフレームワークで判断してください。

FAQ

Meteor で MongoDB 以外のデータベースを使えますか？

使えますが、フレームワーク最大の利点を失います。Meteor のリアクティビティスタック（publications、MiniMongo、Change Streams ドライバー）は MongoDB でしか機能せず、組み込みのアカウントシステムもユーザー情報をそこに保存します。PostgreSQL のようなデータベースは、Meteor メソッド内で標準の npm ドライバーを通じて動作しますが、データ取得コードは自分で書くことになり、ライブクエリも得られません。初日からデータがリレーショナルであるなら、別のフレームワークを選んでください。

Meteor 3 では Blaze が必須ですか、それとも React、Vue、Svelte を使えますか？

Meteor はビューレイヤーに非依存です。meteor create を実行するとデフォルトで React アプリが生成され、Vue、Svelte、Solid、Blaze 向けの公式スケルトンも存在します。Meteor はビルドシステム、DDP データレイヤー、アカウント機能を提供し、UI のレンダリングは選択したライブラリが担います。Blaze も引き続き動作し、コミュニティによるメンテナンスも続いていますが、現行のドキュメント、スケルトン、パッケージ活動の大半は React を前提としています。

Meteor 2.x アプリを直接 3.x にアップグレードできますか、それとも中間ステップが必要ですか？

推奨される道筋は 2.x から始まります。非同期のコレクションメソッド（findOneAsync、insertAsync など）は Meteor 2.8 で導入されているため、2.x のまま段階的にサーバーコードを変換し、Fibers 的な同期呼び出しに依存するものがなくなった時点で 3.x に移ることができます。通常の障害となるのはサードパーティの Atmosphere パッケージです。アプリが使用している各パッケージが 3.x 互換バージョンを出していることが、切り替えの前提になります。

Meteor アプリのデプロイに Galaxy は必要ですか？

いいえ。meteor build を実行すると標準的な Node.js アプリケーションが生成され、Node と MongoDB 接続を提供するホストであれば、VPS、Docker、クラウドプロバイダーのいずれでも実行できます。Galaxy は Meteor Software による任意のマネージドホスティングです。3.5 でデプロイ時に一点重要なのは、Change Streams のリアクティビティを得るには MongoDB がバージョン 6 以降で、レプリカセットまたはシャードクラスターとして構成されている必要があるという点です。それ以外の構成では、設定不要で Meteor が自動的に oplog tailing またはポーリングに戻ります。