2026年においてvue-i18nは時代遅れなのか？

Vueエコシステムにおいて、vue-i18nほど広く定着したライブラリは他にありません。Vue 2時代からKazupon氏を中心に開発が続けられ、@nuxtjs/i18nの基盤としても採用されており、多言語対応Vueプロジェクトの第一候補となってきました。

しかし2026年のベンチマーク検証により、意外な事実が判明しました。vue-i18nは、検証したすべての主要フロントエンドフレームワークの中で最も重いローカライズランタイムだったのです。

Vite + Vueで構築した素の初期状態（31.5 KB）にvue-i18nを導入したところ、ページあたりの平均JavaScriptサイズは136.4 KBに達し、元の4倍以上に膨らみました。

軽量さを売りにするフレームワークで、なぜ国際化ツールがこれほど巨大になってしまうのでしょうか？そして従来のランタイム指向モデルは今も通用するのでしょうか？

主なポイント

検証中もっとも重いランタイム:

テキストを追加する前の状態で24.3 KB（gzip圧縮後、Minifiedで83.2 KB）あり、intlayerのコアランタイム（2.7 KB）と比較して約9倍のサイズです。

ページ容量が330%増加:

vue-i18nによって初期31.5 KBだったVueページが136.4 KBまで膨張しました。対照的にIntlayerは59.3 KBにとどまり、56%軽量なペイロードを実現します。

ブラウザ内に含まれるコンパイラ:

バンドラーで適切なエイリアス設定を行わない限り、vue-i18nはブラウザ上で文字列を解析するためにフルスペックのメッセージコンパイラをクライアントへ送り込みます。

更新ペースの現状:

過去1年間でvue-i18nのコミットは約259回行われましたが、主にバグ修正とVueのマイナー追従が中心です。

次世代開発ツールの不在:

Language Server（LSP）、AI向けMCPサーバー、CLIを通じた自動翻訳パイプラインなど、公式の現代的ツールが揃っていません。

保守状況と現代ツールの比較

テーブルのすべての内容を表示

テーブルのすべての内容を表示

テーブルをモーダルで開き、すべてのデータを明確に表示

リポジトリ	スター数	総コミット数	年間コミット数	最終コミット
intlify/vue-i18n
aymericzip/intlayer

過去12か月間の実績:

• intlify/vue-i18n: 259コミット（Vue 3およびNuxt向けの定期保守）。
• aymericzip/intlayer: 4,343コミット（コンパイラ最適化、LSP機能、AI連携ツールの継続開発）。

歴史あるライブラリには安定性の利点があります。しかし近年の開発手法は、ビルド時のAST解析、デッドコード除去、AIによる自動化を前提としています。クライアント上での実行に依存するアーキテクチャでは、こうした進化を取り入れるのが難しくなります。

Vite + Vueでの性能測定

ViteとVue 3による10ページ、10言語構成のアプリケーションで測定:

実ブラウザ環境で本番用gzip圧縮を適用して計測。詳細はVueベンチマークドキュメントをご覧ください。

初期ライブラリのサイズ

翻訳テキストを読み込む前のフットプリント:

vue-i18nのランタイムだけで24.3 KB（gzip圧縮後）を占め、Vueのコア全体に近い容量です。これに対してIntlayerはわずか2.7 KBにとどまります。

ページサイズと不要データの混入率

主な分析結果

相対的な増大率の高さ:

Vue自体のフットプリントが非常に小さいため（約31 KB）、vue-i18nを追加することでページ全体の容量が4倍以上に跳ね上がります。

他ページ翻訳の混入:

デフォルト設定では、特定のルートに届くテキストデータの90%が他のページ用です。Intlayerはこれをビルド時に完全に排除し、0.0%に抑えます。

スコープ付きコンポーネントの肥大化:

辞書が重複してバンドルされるため、vue-i18nを使ったスコープ付きコンポーネントの平均サイズは196 KBに達しました。一方、Intlayerでは6.5 KBです。

なぜvue-i18nは重いのか？

ブラウザへ同梱されるASTコンパイラ

vue-i18nはメッセージフォーマット用の独自コンパイラを内蔵しています。複数形判定や変数置換を、ブラウザの実行時に構文木（AST）へ変換して解釈します。

これを回避するには、バンドラー設定でvue-i18n/dist/vue-i18n.runtime.esm-bundler.jsへのエイリアスを指定し、@intlify/unplugin-vue-i18nを用いて事前コンパイルを行う必要がありますが、多くのプロジェクトで見落とされています。

モノリシックな多機能設計

日付・数値フォーマッター、リンクメッセージ、旧来のOptions API向けブリッジ（$t, v-t）、リアクティブプロキシなどが一体となっています。<script setup>内でごく単純なテキストを表示したいだけであっても、すべての機能群が読み込まれます。

動的キーによるTree-shakingの阻害

"home.hero.title"が実行時に解釈されるため、バンドラーはどのキーが実際に使用されているかを追跡できません。不要なテキストもそのままバンドル内に残存します。

<script setup>
import { useI18n } from "vue-i18n";

const { t } = useI18n();
</script>

<template>
  <h1>{{ t("home.hero.title") }}</h1>
</template>

<script setup>
import { useIntlayer } from "vue-intlayer";

const { title } = useIntlayer("hero");
</script>

<template>
  <h1>{{ title }}</h1>
</template>

Intlayerコンパイラはアクセスされたプロパティを正確に追跡し、クライアント用チャンクをビルドする前に未使用データをカットします。詳細はバンドル最適化をご覧ください。

開発体験（DX）の比較

分離されたJSONとコンポーネント共配置

vue-i18nでは翻訳文が遠く離れたlocales/フォルダに保存されます。Intlayerならコンポーネントのすぐ隣にコンテンツファイルを配置できます。

{
  "hero": {
    "title": "Ship in every language"
  }
}

{
  "hero": {
    "title": "あらゆる言語でリリースしよう"
  }
}

<script setup>
import { useI18n } from "vue-i18n";

const { t } = useI18n();
</script>

<template>
  <h1>{{ t("hero.title") }}</h1>
</template>

import { t, type Dictionary } from "intlayer";

export default {
  key: "hero",
  content: {
    title: t({
      en: "Ship in every language",
      ja: "あらゆる言語でリリースしよう",
    }),
  },
} satisfies Dictionary;

<script setup>
import { useIntlayer } from "vue-intlayer";

const { title } = useIntlayer("hero");
</script>

<template>
  <h1>{{ title }}</h1>
</template>

Hero.vueをリネームまたは削除すれば、対応するコンテンツ定義も連動して処理されます。

エディタ補完と厳密な完全性の違い

DefineLocaleMessageを使用すればエディタ上でキーの候補が表示されます。しかし全言語の網羅性まではチェックされません。ja.jsonからキーが欠落していてもTypeScriptはビルドを止めません。

Intlayerでは辞書の内容が厳密に検証されます。strictModeを有効にすれば、いずれかの言語で翻訳が不足している場合にビルドエラーが発生します。

エディタおよびAIツールのサポート

翻訳ワークフロー

vue-i18nには翻訳を自動生成するコマンドがありません。外部のCrowdinやPhrase等へファイルを送るのが通例です。

Intlayerは自前のツールチェーンを提供しています。

ローカルAI翻訳機能（intlayer fill）:

自身のOpenAI、Anthropic、Mistral、GeminiのAPIキーを使って、不足しているキーを自動翻訳します。

セルフホスト対応ビジュアルCMS:

Intlayer CMSを起動し、非エンジニアのメンバーがWeb上で修正した内容を直接Gitに保存できます。

オープンソースライセンス:

すべてのツールがApache 2.0ライセンスで利用可能です。

今もvue-i18nが選択肢となるケース

既存のvue-i18n環境を向上させるには？

Intlayerは、vue-i18nおよび@nuxtjs/i18nの関数シグネチャ（useI18n、$t、<i18n-t>）をそのまま再現するドロップイン互換パッケージを提供しています。テンプレートやComposableを書き換えることなく、コンパイラ主導の軽量アーキテクチャの恩恵を受けることができます。

導入はコマンド1行で完了します:

npx intlayer init --interactive

この対話型CLIは以下の作業を自動で行います:

1. @intlayer/vue-i18nまたは@intlayer/nuxt-i18n互換パッケージをインストール。
2. ViteまたはNuxtバンドラーのエイリアスを設定し、既存のインポートやテンプレート記述をシームレスにIntlayerへルーティング。これによりvue-i18nをpackage.jsonから安全に削除できます。
3. Language Server（LSP）診断の即時有効化、クライアントバンドルからの24KB ASTパーサーの完全排除、ローカルAI翻訳ワークフローを大規模なリファクタリングなしで利用可能にします。

詳しい手順については、以下のガイドをご覧ください:

• 互換レイヤーの活用: vue-i18n互換レイヤーまたは@nuxtjs/i18n互換レイヤーを使うことで、既存のテンプレートを維持したまま導入できます。
• 移行ガイドライン: 既存のJSONファイルを型付き辞書へ移行するためのドキュメントを用意しています。vue-i18nからの移行、@nuxtjs/i18nからの移行。
• ハイブリッド構成: ランタイムとしてvue-i18nを使い続けながら、Intlayerとvue-i18nを連携させて厳格な型安全性とローカルAI翻訳を活用することも可能です。

自社サイトのサイズと翻訳漏れは無料のi18n SEOスキャナーで診断できます。

おすすめの記事

• Vue & Vite i18nベンチマーク: パフォーマンス詳細比較
• vue-i18n vs Intlayer: 項目別比較
• 2026年においてnext-intlは時代遅れなのか？
• コンパイラ主導型国際化と宣言的i18nの比較