@intlayer/docs 9.5.6 → 9.5.8

package/blog/ja/i18next_vs_intlayer.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "i18next vs Intlayer: 2026年ベンチマーク＆徹底比較"
 description: "Next.jsおよびTanStack Startにおけるreact-i18nextとnext-i18nextをIntlayerと比較測定。バンドルサイズ、コンテンツリーク、ロケール切り替えの応答性、開発者体験を検証。"
 keywords:
@@ -25,6 +25,8 @@ author: aymericzip
 
 # i18next VS Intlayer | React & Next.js 国際化 (i18n) ベンチマーク比較
 
+![i18next VS Intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18next-next-intl-intlayer.webp?raw=true)
+
 `i18next`は、JavaScriptエコシステムで最も広く利用されているi18nフレームワークです。`react-i18next`や`next-i18next`を通じて、数多くのReactおよびNext.jsアプリケーションで採用されています。Intlayerは、コンパイラ駆動型でコンポーネントスコープ設計を採用した新しい選択肢です。
 
 本記事では、機能リストの単なる比較ではなく、客観的な実測値に基づいて両者を比較します。掲載されている数値は、同一アプリケーションを各ライブラリでビルドし、ブラウザが実際にダウンロードするリソースを記録するオープンソーススイート[Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom)の測定結果に基づいています。
@@ -74,9 +76,7 @@ author: aymericzip
 
 ### 測定対象と環境
 
-[Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom)スイートは、各ライブラリを用いて**同一仕様のアプリケーション**を構築します。**10ページ**（home, about, blog, careers, contact, FAQ, pricing, products, settings, team）、**10ロケール**（`en`, `fr`, `es`, `de`, `it`, `pt`, `zh`, `ja`, `ko`, `ru`）、同一コンポーネント・同一コンテンツで検証し、測定は`en`および`fr`で行われます。
-
-各ライブラリは、基本的な構成から最適な構成まで最大4つの**読み込み戦略**でテストされています：
+[Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom)スイートは、各ライブラリを用いて**同一仕様のアプリケーション**を構築します。**10ページ**（home, about, blog, careers, contact, FAQ, pricing, products, settings, team）、**10ロケール**（`en`, `fr`, `es`, `de`, `it`, `pt`, `zh`, `ja`, `ko`, `ru`）、同一コンポーネント・同一コンテンツで検証し、測定は`en`および`fr`で行われます。各ライブラリは、基本的な構成から最適な構成まで最大4つの**読み込み戦略**でテストされています：
 
 | 戦略               | 概要                                                                                      | 想定ケース                                 |
 | ------------------ | ----------------------------------------------------------------------------------------- | ------------------------------------------ |
@@ -101,6 +101,10 @@ Intlayerには「scoped」バリアントが存在しません。コンパイラ
 
 ### Next.jsでの結果 (`next-i18next`)
 
+関心のある指標とライブラリを選択してください:
+
+<I18nBenchmark framework="nextjs" vertical/>
+
 | ライブラリ                      | 戦略           | Lib size (gz) | Page JS avg (gz) | Locale leak | Page leak | Component avg (gz) |   E2E応答性 | Hydration |
 | ------------------------------- | -------------- | ------------: | ---------------: | ----------: | --------: | -----------------: | ----------: | --------: |
 | **base** (i18nなし)             | -              |        0.0 KB |         141.0 KB |        0.0% |      0.0% |             0.9 KB |     13.4 ms |   11.8 ms |
@@ -121,6 +125,15 @@ Intlayerには「scoped」バリアントが存在しません。コンパイラ
 - **コンポーネントサイズ**: `useTranslation()`を使用するコンポーネントは構成に応じて26〜79 KBに膨らみますが、`useIntlayer()`を使う同一コンポーネントは6.9 KBで済みます。
 - **ハイドレーション**: `dynamic`構成では27.7 msに悪化します。クライアント側でReactがハイドレーションを開始する前に、i18nextインスタンスが初期化されバックエンドを解決する必要があるためです。
 
+<ClickToOpenIframe
+src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-nextjs.md"
+width="100%"
+height="600px"
+style="border:none;"
+/>
+
+> すべてのライブラリと戦略を網羅した詳細な表は、[Next.jsベンチマークレポート](https://intlayer.org/ja/doc/benchmark/nextjs)をご覧ください。
+
 ### TanStack Startでの結果 (`react-i18next`)
 
 Next.js特有のオーバーヘッドを排除するため、TanStack Start上で純粋な`react-i18next`を使用した比較です。
@@ -143,8 +156,19 @@ Next.js特有のオーバーヘッドを排除するため、TanStack Start上
 - Intlayerの`static`は、該当ページのコンポーネントがインポートした辞書のみをバンドルするため、初期状態で**ページリーク0%**です。`importMode: 'dynamic'`を設定すれば、言語リークも0%になります。
 - **コンポーネントサイズ**: `react-i18next`の24〜27 KBに対し、Intlayerは6〜8 KBです。
 
+<ClickToOpenIframe
+src="https://intlayer.org/markdown?url=https%3A%2F%2Fraw.githubusercontent.com%2Fintlayer-org%2Fbenchmark-i18n%2Fmain%2Freport%2Fscripts%2Fsummarize-tanstack.md"
+width="100%"
+height="600px"
+style="border:none;"
+/>
+
+> 詳細な表は[TanStack Startベンチマークレポート](https://intlayer.org/ja/doc/benchmark/tanstack)をご覧ください。
+
 ## なぜこれほどの差が出るのか？ グローバルインスタンス vs コンパイル済み辞書
 
+![Centralized catalogs versus per-component dictionaries](https://github.com/aymericzip/intlayer/blob/main/docs/assets/project_stucture_18n_vs_intlayer.png?raw=true)
+
 `i18next`は2012年にランタイム主導で設計されました。グローバルインスタンスがリソースストアを保持し、プラグインがそれを拡張し、描画時に`t()`がキーを検索します。この構造が高い汎用性をもたらす一方で、オーバーヘッドの原因となっています：
 
 ```bash
@@ -168,7 +192,13 @@ Next.js特有のオーバーヘッドを排除するため、TanStack Start上
                 └── page.tsx     # ["common", "about"]が必要であることを把握しておく必要がある
 ```
 
-インスタンスはコンポーネントがどのキーを必要とするか事前に知ることができないため、指定された名前空間をすべて保持します。最適化のためには、**開発者自身**がカタログを名前空間に分割し、ページごとの依存関係を定義し、コンポーネントの移動に合わせてメンテナンスし続ける必要があります。[ベンチマークノート](https://github.com/intlayer-org/benchmark-bloom/blob/main/report/NOTE.md)にある通り、「型安全性を保ちながら各ページに必要な名前空間を正確に把握・維持することは非常に過酷な作業」です。
+インスタンスはコンポーネントがどのキーを必要とするか事前に知ることができないため、指定された名前空間をすべて保持します。最適化のためには、**開発者自身**がカタログを名前空間に分割し、ページごとの依存関係を定義し、コンポーネントの移動に合わせてメンテナンスし続ける必要があります。
+
+ページとロケールの両方の軸で無駄なコストが同時に膨らみます:
+
+![Theoretical content leakage by architecture](https://github.com/aymericzip/intlayer/blob/main/docs/assets/theorical_content_leakage.webp?raw=true)
+
+[ベンチマークノート](https://github.com/intlayer-org/benchmark-bloom/blob/main/report/NOTE.md)にある通り、「型安全性を保ちながら各ページに必要な名前空間を正確に把握・維持することは非常に過酷な作業」です。
 
 Intlayerはグローバルインスタンスを排除します。コンテンツはコンポーネントのすぐ隣で宣言され、コンパイラがビルド時に依存関係グラフを解決します：
 
@@ -195,7 +225,8 @@ Intlayerはグローバルインスタンスを排除します。コンテンツ
 
 ### セットアップの比較
 
-**next-i18next (App Router)**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-i18next" value="i18next">
 
 ```ts fileName="src/app/i18n/server.ts"
 import { createInstance } from "i18next";
@@ -230,7 +261,8 @@ export const initI18next = async (
 
 これに加えて、クライアント側の`I18nProvider`の作成、`generateStaticParams`の設定、各ページでの名前空間リストの指定が必要です。
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="intlayer.config.ts"
 import { type IntlayerConfig, Locales } from "intlayer";
@@ -266,9 +298,13 @@ const LocaleLayout: NextLayoutIntlayer = async ({ children, params }) => {
 export default LocaleLayout;
 ```
 
+</Tab>
+</Tabs>
+
 ### クライアントコンポーネント
 
-**react-i18next**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="react-i18next" value="i18next">
 
 ```json fileName="src/locales/en/about.json"
 {
@@ -306,7 +342,8 @@ export const Counter = () => {
 
 > このコンポーネントを描画するページは`about`名前空間をロードする必要があり、`CustomTypeOptions`を拡張しない限り`t("counter.label")`の型安全性は保証されません。
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="src/components/Counter/index.content.ts"
 import { t, type Dictionary } from "intlayer";
@@ -347,9 +384,13 @@ export const Counter = () => {
 
 `label`と`increment`は厳格に型付けされており、キーのタイポはTypeScriptエラーになり、フランス語の翻訳欠落はビルド時にエラーとして検出されます。
 
+</Tab>
+</Tabs>
+
 ### 同期サーバーコンポーネント
 
-**next-i18next**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-i18next" value="i18next">
 
 ```tsx fileName="src/components/ServerCounter.tsx"
 type ServerCounterProps = {
@@ -368,7 +409,8 @@ export const ServerCounter = ({ t, locale, count }: ServerCounterProps) => (
 
 ページ側で`i18n.getFixedT(locale, "about")`を呼び出し、Propsを通じて`t`と`locale`を渡す必要があります。
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```tsx fileName="src/components/ServerCounter.tsx"
 import { useIntlayer } from "next-intlayer/server";
@@ -387,6 +429,9 @@ export const ServerCounter = ({ count }: { count: number }) => {
 };
 ```
 
+</Tab>
+</Tabs>
+
 ## i18nextのAPIのままIntlayerの最適化を享受する
 
 既存のコンポーネントを書き換えることなく、上記のベンチマーク性能を得ることも可能です。`@intlayer/i18next`、`@intlayer/react-i18next`、`@intlayer/next-i18next`はドロップイン互換アダプターとして機能します。`useTranslation`、`t()`、`<Trans>`、`{{interpolation}}`、複数形接尾辞、コンテキスト接尾辞、`returnObjects`がそのまま動作し、背後ではIntlayerコンパイラが辞書を最適化して供給します。
@@ -417,18 +462,85 @@ export default defineConfig({
 
 ## どちらを選ぶべきか？
 
-- **i18nextを選ぶべき場合**: 豊富なプラグインエコシステム（各種バックエンド、ICU、Locize等）が不可欠な場合、React以外の領域（Node.jsサービス、Vanilla JS、他フレームワーク）でも同一ツールを使いたい場合、チームがすでに習熟している場合、翻訳プラットフォームが`locales/{lng}/{ns}.json`を前提としている場合。ただし、パフォーマンスを追求する場合は名前空間の設計やページマッピングの維持に十分なリソースを確保してください。
-- **Intlayerを選ぶべき場合**: **コンポーネントスコープのコンテンツ管理**、**厳格なTypeScript型付け**、**ビルド時の翻訳漏れ検出**、**自動ツリーシェイキングと遅延ロード**、瞬時のロケール切り替え、同期サーバーコンポーネント、統合編集ツール（ビジュアルエディタ、CMS、AI翻訳支援、MCPサーバー）を重視する場合。モジュール化されたコードベースやデザインシステムに最適です。
-- **`@intlayer/*-i18next`アダプターを選ぶべき場合**: すでにi18nextを採用しており、大規模なコード書き換えなしにバンドルサイズと応答性の向上を図りたい場合。
+<AccordionGroup>
+<Accordion header="i18nextを選ぶ場合">
+
+豊富なプラグインエコシステム（各種バックエンド、ICU、Locize等）が不可欠な場合、React以外の領域（Node.jsサービス、Vanilla JS、他フレームワーク）でも同一ツールを使いたい場合、チームがすでに習熟している場合、翻訳プラットフォームが`locales/{lng}/{ns}.json`を前提としている場合。ただし、パフォーマンスを追求する場合は名前空間の設計やページマッピングの維持に十分なリソースを確保してください。
+
+</Accordion>
+<Accordion header="Intlayerを選ぶ場合">
+
+**コンポーネント指向のコンテンツ管理**、**厳格なTypeScript型安全性**、**ビルド時の翻訳キー欠落検出**、**設定不要のTree-shakingと遅延読み込み**、瞬時のロケール切り替え、同期サーバーコンポーネント、そして組み込みのエディタツール群（[ビジュアルエディタ](https://intlayer.org/ja/doc/concept/editor)、[CMS](https://intlayer.org/ja/doc/concept/cms)、[AI自動翻訳](https://intlayer.org/ja/doc/concept/auto-fill)、[MCPサーバー](https://intlayer.org/ja/doc/mcp-server)）を重視する場合。特に大規模でモジュール化されたコードベースやデザインシステムに最適です。
+
+</Accordion>
+<Accordion header="@intlayer/*-i18nextアダプターを選ぶ場合">
+
+すでにi18nextを使っており、コンポーネントを書き換えることなくバンドル削減と反応性の向上を得たい場合。既存の `locales/{lng}/{ns}.json` ファイルはそのまま真実の単一ソースとして機能します。[i18next vs @intlayer/i18next](https://intlayer.org/ja/blog/i18next-vs-intlayer-i18next) で実際の比較測定を行っています。
+
+</Accordion>
+</AccordionGroup>
+
+## よくある質問 (FAQ)
+
+<FAQ>
+
+<Question title="なぜi18nextは他のライブラリよりもこれほど重いのですか？">
+
+フレームワーク非依存のランタイムとして設計されたためです。グローバルインスタンス、プラグインパイプライン、リソースストア、キーリゾルバーを備えています。その柔軟性がすべてのバンドルにコンパイルされます。ライブラリをインポートするだけの空のコンポーネントでも、`next-i18next` では **19.7 KB gzip** かかり、`next-intlayer` の **5.5 KB** と比較して大幅に大きく、コンテンツ量に関係なくすべてのページでそのコストが発生します。
+
+</Question>
+
+<Question title="バックエンドによる遅延読み込みで解決できますか？">
+
+ファイルサイズは改善されますが、遅延（レイテンシ）は改善されません。`i18next-resources-to-backend` に切り替えると1ページあたり約49 KB節約できますが、言語切り替え時にネットワーク通信が発生します。Intlayerの **3-4 ms** に対して、`dynamic` 構成では **123 ms**、`scoped-static` では **185 ms** かかります。また、Reactのハイドレーション前にインスタンスがバックエンドを解決するため、ハイドレーション時間も27.7 msに跳ね上がります。
+
+</Question>
+
+<Question title="i18nextでコンテンツリークを0%にすることは可能ですか？">
+
+はい、`scoped-dynamic` を使用すれば可能です。ルートごとに1つの名前空間、リソースバックエンド、手動管理のページ対名前空間マップが必要です。Next.jsで1ページあたり163.4 KBまで削減できますが、設定不要のIntlayer（141.3 KB）より依然として **+22 KB** 重くなります。詳細は[バンドル最適化](https://intlayer.org/ja/doc/concept/bundle-optimization)をご覧ください。
+
+</Question>
+
+<Question title="移行するためにコンポーネントを書き直す必要がありますか？">
+
+いいえ。`@intlayer/i18next`、`@intlayer/react-i18next`、`@intlayer/next-i18next` は、`useTranslation`、`t()`、`<Trans>`、`{{interpolation}}`、`_one` / `_other` の複数形、コンテキスト接尾辞、`returnObjects` を完全に維持します。`next.config.ts` や `vite.config.ts` にプラグインを1行追加するだけです。手順は [next-i18next移行ガイド](https://intlayer.org/ja/doc/migration/next-i18next) をご覧ください。
+
+</Question>
+
+<Question title="既存のi18nextプラグインはどうなりますか？">
+
+バックエンドや言語検出プラグインは受け入れられますが、何も動作しません。ランタイムでロードや検出を行う必要がなくなるためです。ロケール検出はIntlayerのルーティング設定（URLプレフィックス、Cookie、ヘッダー）に置き換わります。リクエスト時にCMSから翻訳を取得している場合は、代わりに [Intlayer CMS](https://intlayer.org/ja/doc/concept/cms) または `intlayer pull` / `push` を使用してください。
+
+</Question>
+
+</FAQ>
 
 ## 関連する比較記事
 
-- [next-intl vs Intlayer](https://intlayer.org/ja/blog/next-intl-vs-intlayer)（同一ベンチマーク）
-- [Lingui vs Intlayer](https://intlayer.org/ja/blog/lingui-vs-intlayer)（同一ベンチマーク）
-- [vue-i18n vs Intlayer ベンチマーク](https://intlayer.org/ja/blog/vue-i18n-vs-intlayer-benchmark)（同一ベンチマーク）
+同じベンチマーク、他のライブラリとの比較:
+
+- [next-intl vs Intlayer](https://intlayer.org/ja/blog/next-intl-vs-intlayer)
+- [Lingui vs Intlayer](https://intlayer.org/ja/blog/lingui-vs-intlayer)
+- [vue-i18n vs Intlayer benchmark](https://intlayer.org/ja/blog/vue-i18n-vs-intlayer-benchmark)
 - [next-i18next vs next-intl vs Intlayer](https://intlayer.org/ja/blog/next-i18next-vs-next-intl-vs-intlayer)
 - [react-i18next vs react-intl vs Intlayer](https://intlayer.org/ja/blog/react-i18next-vs-react-intl-vs-intlayer)
+
+i18nextについてさらに詳しく:
+
+- [i18next vs @intlayer/i18next](https://intlayer.org/ja/blog/i18next-vs-intlayer-i18next) 同一アプリでのアダプター測定結果
 - [i18nextは時代遅れか？](https://intlayer.org/ja/blog/is-i18next-outdated)
+- [i18nextでIntlayerを使用する](https://intlayer.org/ja/blog/intlayer-with-i18next) および [react-i18nextでの使用](https://intlayer.org/ja/blog/intlayer-with-react-i18next)
+- [next-i18nextを使用したNext.jsアプリの国際化方法](https://intlayer.org/ja/blog/nextjs-internationalization-using-next-i18next)
+
+関連リファレンスドキュメント:
+
+- [Next.jsベンチマークレポート](https://intlayer.org/ja/doc/benchmark/nextjs) および [TanStack Startベンチマークレポート](https://intlayer.org/ja/doc/benchmark/tanstack)
+- 互換アダプター: [i18next](https://intlayer.org/ja/doc/compatibility/i18next), [react-i18next](https://intlayer.org/ja/doc/compatibility/react-i18next), [next-i18next](https://intlayer.org/ja/doc/compatibility/next-i18next)
+- 移行ガイド: [i18next](https://intlayer.org/ja/doc/migration/i18next), [react-i18next](https://intlayer.org/ja/doc/migration/react-i18next), [next-i18next](https://intlayer.org/ja/doc/migration/next-i18next)
+- [バンドル最適化](https://intlayer.org/ja/doc/concept/bundle-optimization) と [Intlayerコンパイラ](https://intlayer.org/ja/doc/compiler)
+- [コンポーネント単位 vs 集中型 i18n](https://intlayer.org/ja/blog/per-component-vs-centralized-i18n)
+- [コンパイラ駆動 vs 宣言型 i18n](https://intlayer.org/ja/blog/compiler-vs-declarative-i18n)
 
 ## GitHubスター
 

package/blog/ja/is_intlayer_lighter_than_paraglide.md

@@ -0,0 +1,284 @@
+---
+createdAt: 2026-09-23
+updatedAt: 2026-09-23
+title: Intlayer は Paraglide より軽い？
+description: Paraglide はコードがリポジトリ内に直接生成されるため、i18n ベンチマークではほぼノーコストのように見えます。その容量が実際にはどこに移動しているのか、ノードごとのロケール読み取りがなぜコストになるのか、そして Intlayer の動的読み込みが全言語ではなく必要なロケールのみを配信する仕組みを解説します。
+keywords:
+  - Paraglide
+  - Intlayer
+  - 国際化
+  - i18n
+  - Bundle size
+  - Tree shaking
+  - Benchmark
+  - Blog
+slugs:
+  - blog
+  - is-intlayer-lighter-than-paraglide
+author: aymericzip
+---
+
+# Intlayer は Paraglide より軽い？
+
+結論から言うと、軽いです。
+
+`Paraglide` は極めて軽量な i18n ソリューションとして知られており、一見すると [ベンチマーク](https://intlayer.org/ja/doc/benchmark/tanstack) でもそれが裏付けられているように見えます。ライブラリサイズはほぼゼロです。しかし、ライブラリサイズがゼロであることは、配信されるバイト数がゼロであることを意味しません。その指標がカウントしていない別の場所にバイトが隠れているに過ぎません。
+
+<TOC/>
+
+## 主なポイント
+
+**ライブラリサイズは消えたのではなく、隠されているだけ：**
+
+Paraglide はランタイムとメッセージ関数をご自身のコードベース内に生成します。そのコードはブラウザに送信されますが、ライブラリではなく「あなた自身のコード」としてカウントされます。
+
+**Provider なしは無料の勝利ではない：**
+
+`m.my_key()` の呼び出しごとにロケールを個別に解決し、レンダリングされるノードごとに Cookie やストレージを読み取ります。コンテキストから一度だけ読み取る方式ではありません。
+
+**動的読み込み（Dynamic Loading）に対応していない：**
+
+Paraglide はメッセージのすべての言語をクライアントバンドルにインポートします。Intlayer で `importMode: 'dynamic'` または `'fetch'` を使用すると、現在表示されているロケールのみが読み込まれます。
+
+**Tree Shaking は保証されない：**
+
+いくつかのベンチマーク環境では、Paraglide がアピールする Tree Shaking が機能しませんでした。ご自身のバンドルで検証することをおすすめします。
+
+## Paraglide の容量はどこへ消えたのか？
+
+ベンチマークレポートの「ライブラリサイズ」指標は、コンテンツを追加する前の空のコンポーネントにおける各 i18n ライブラリの Provider とフックのサイズを測定しています。
+
+| ライブラリ (TanStack Start)   | ライブラリサイズ (gz) | ライブラリサイズ (min) |
+| ----------------------------- | --------------------- | ---------------------- |
+| `@inlang/paraglide-js@2.15.1` | 1.8 KB                | 4.5 KB                 |
+| `react-intlayer@9.5.1`        | 5.0 KB                | 15.2 KB                |
+
+この数値だけを切り取れば Paraglide の勝ちに見えます。しかし Paraglide はコンパイラです。`messages/*.json` ファイルを読み込み、リポジトリ内に `paraglide/` フォルダを生成します。その中には `runtime.js`（ロケール検出、Cookie やストレージ戦略、URL ローカライズ）と、メッセージごとの JavaScript 関数が出力されます。
+
+```bash
+src/paraglide/
+├── runtime.js      # ロケール検出、各種戦略、URL ヘルパー
+├── server.js
+├── messages.js     # 全メッセージの再エクスポート
+└── messages/
+    ├── _index.js
+    ├── en.js
+    └── fr.js
+```
+
+このコードは `src/` フォルダ内に配置され相対パスでインポートされるため、バンドラーはこれを `node_modules` のパッケージではなく、アプリケーション自身のコードとして分類します。そのため、ライブラリサイズの列にはほとんど何も表示されませんが、ページバンドル内には全く同じロジックが配信されています。
+
+コードを生成すること自体は悪いアイデアではありません。生成されたランタイムには、設定で必要とされたロジック（プレフィックス戦略、Cookie vs ローカルストレージなど）のみが含まれます。Intlayer は異なるアプローチで同じ成果を実現しています。ビルド時に環境変数を注入することで、バンドラーが設定で使用されていない分岐を自動的に削除します。どちらのアプローチも、`i18next` や `next-intl` と比べて 3〜10 倍軽量です。
+
+したがって、公平な比較の基準はライブラリサイズではありません。**ページごとに実際に送信される JavaScript の総量**です。
+
+## 実測されたページ容量
+
+TanStack Start アプリケーション、10 ページ構成、`en` および `fr` ルートで計測（gzip 圧縮）：
+
+| 構成                               | ページ JS 平均 (gz) | ベース比    | ロケール漏洩率 | 他ページ漏洩率 |
+| ---------------------------------- | ------------------- | ----------- | -------------- | -------------- |
+| ベース (i18n なし)                 | 111.0 KB            | -           | 0.0%           | 0.0%           |
+| `paraglide` (すべての戦略)         | 125.1 KB            | +14.1 KB    | 49.7%          | 0.0%           |
+| `intlayer` (`importMode: static`)  | 125.8 KB            | +14.8 KB    | 50.0%          | 0.0%           |
+| `intlayer` (`importMode: dynamic`) | **118.6 KB**        | **+7.6 KB** | **0.0%**       | **0.0%**       |
+
+Next.js 16 App Router、同一アプリケーション：
+
+| 構成               | ページ JS 平均 (gz) | ベース比    |
+| ------------------ | ------------------- | ----------- |
+| ベース (i18n なし) | 141.0 KB            | -           |
+| `paraglide-next`   | 155.3 KB            | +14.3 KB    |
+| `next-intlayer`    | **141.3 KB**        | **+0.3 KB** |
+
+<I18nBenchmark framework="tanstack" vertical/>
+
+> 詳細なデータは [TanStack Start ベンチマークレポート](https://intlayer.org/ja/doc/benchmark/tanstack) および [Next.js ベンチマークレポート](https://intlayer.org/ja/doc/benchmark/nextjs) を参照してください。すべてのバンドルは [ベンチマークリポジトリ](https://github.com/intlayer-org/benchmark-i18n) で確認できます。
+
+2 つの重要な事実が浮き彫りになります：
+
+- `static` モードにおいて、Intlayer は Paraglide とほぼ同じサイズのコンテンツを配信します（125.8 KB vs 125.1 KB）。これは当然です。どちらもページが使用するメッセージの全言語を含んでいるからです。
+- Paraglide は動的モードを持たないため、どのような戦略を選択しても 125.1 KB のままです。上記の表の各行は静的読み込みに相当します。
+
+## Provider なし：一見良さそうで実はそうではない設計
+
+Paraglide には Provider がありません。メッセージをインポートして呼び出すだけです：
+
+```tsx fileName="Hero.tsx"
+import { m } from "../paraglide/messages.js";
+
+export const Hero = () => (
+  <section>
+    <h1>{m.hero_title()}</h1>
+    <p>{m.hero_description()}</p>
+    <button>{m.hero_cta()}</button>
+  </section>
+);
+```
+
+コンテキストも、ラッパーも、フックもありません。シンプルに見えます。しかし、ロケール情報はどこかから取得する必要があります。生成される各メッセージ関数は、大まかに以下のようになっています（簡略化版）：
+
+```js fileName="paraglide/messages/_index.js"
+export const hero_title = (inputs = {}, options = {}) => {
+  const locale = options.locale ?? getLocale(); // 呼び出しごとに毎回解決される
+
+  if (locale === "en") return en.hero_title(inputs);
+  if (locale === "fr") return fr.hero_title(inputs);
+  // ...言語ごとの分岐
+};
+```
+
+そして `getLocale()` は設定された戦略（Cookie、ローカルストレージ、URL、ベースロケール）を走査して現在のロケールを探します。つまり、描画する各テキストノード（`<>{m.my_key()}</>`）が、ブラウザの `document.cookie` の読み取りを含む独自のロケール解決を実行します。200 個の翻訳文字列があるページでは、1 回のレンダリングで 200 回ロケールが解決され、再レンダリングのたびにそれが繰り返されます。
+
+Provider を利用するライブラリは、ロケールを **1 回だけ** 読み取り、コンテキスト（またはシグナル、ストア）に保存します。各ノードはすでにメモリ上にある値を参照するだけです。Provider のコストはわずか数百バイトです。それを省くことはレンダリングごとの CPU 負荷につながり、ベンチマークにも明確に現れています。TanStack Start において Paraglide のページ読み込み時間と言語切り替え速度は、Intlayer より一貫して劣っています（ページ読み込みで 22.1 ms vs 14.6 ms、E2E リアクティビティで 4.3 ms vs 3.2 ms）。
+
+## 開発体験（Developer Experience）
+
+Paraglide の信頼できる情報源（Source of Truth）は JSON ですが、JSON を直接インポートすることはありません。生成された `.js` をインポートします：
+
+<Tabs defaultTab="intlayer" group="techno">
+  <Tab label="Paraglide" value="paraglide">
+
+```json fileName="messages/en.json"
+{
+  "hero_title": "Ship your app in every language"
+}
+```
+
+```json fileName="messages/ja.json"
+{
+  "hero_title": "すべての言語でアプリを公開しましょう"
+}
+```
+
+```tsx fileName="Hero.tsx"
+// コンパイラが JSON から再生成した後にのみ存在します
+import { m } from "../paraglide/messages.js";
+
+export const Hero = () => <h1>{m.hero_title()}</h1>;
+```
+
+  </Tab>
+  <Tab label="Intlayer" value="intlayer">
+
+```ts fileName="Hero.content.ts"
+import { t, type Dictionary } from "intlayer";
+
+export default {
+  key: "hero",
+  content: {
+    title: t({
+      ja: "すべての言語でアプリを公開しましょう",
+      en: "Ship your app in every language",
+    }),
+  },
+} satisfies Dictionary;
+```
+
+```tsx fileName="Hero.tsx"
+import { useIntlayer } from "react-intlayer";
+
+export const Hero = () => {
+  const { title } = useIntlayer("hero");
+
+  return <h1>{title}</h1>;
+};
+```
+
+  </Tab>
+</Tabs>
+
+このサイクルにはデメリットが伴います：
+
+- JSON ファイルを変更するたびに、インポートが解決されたり型が更新されたりする前に再生成を実行する必要があります。
+- 生成された `paraglide/` フォルダを Git にコミットするか（テキストを変更する PR ごとに生成ファイルでコンフリクトが発生）、除外するか（型チェック、テスト、CI ジョブの前に毎回生成ステップが必要になる）の二者択一になります。
+- すべての文字列が関数呼び出しになります。単なる静的値で十分な場所を含め、至る所で定数が `m.key()` に置き換わります。
+
+## Tree Shaking：バンドルを確認してください
+
+Paraglide の最大のセールスポイントは、各メッセージが独立したエクスポートであるため、使用されていないメッセージが Tree Shaking によって削除されることです。Svelte + Vite のベンチマークでは、宣伝どおりに動作します。
+
+しかし、他の環境ではそうではありませんでした。[Next.js](https://intlayer.org/ja/doc/benchmark/nextjs) の計測では、Paraglide のページはベースアプリより 14 KB 増加したのに対し、`next-intlayer` の増加は 0.3 KB にとどまりました。TanStack Start の初期計測でも、他のページのメッセージがルートバンドルに混入していることが確認されました。
+
+Tree Shaking の成否は、バンドラー（Turbopack、Rolldown、Rollup）、メッセージのインポート方法（`import { m }` vs `import * as m`）、および副作用（Side Effects）の解析精度に左右されます。サイズを理由に Paraglide を採用する場合は、バンドルアナライザーを開いて、ご自身のアプリで正しく動作しているか確認してください。
+
+## 動的読み込み（Dynamic Loading）の欠如
+
+これが構造的な限界です。Paraglide には 1 言語ずつ読み込む手段がありません。各メッセージ関数が各言語の実装を静的にインポートするため、すべての言語がクライアントバンドルに含まれてしまいます。
+
+2 言語の場合、翻訳データの半分が無駄になり、上記の測定で判明した約 50% のロケール漏洩に一致します。10 言語では 90% が無駄になり、30 言語では 97% に達します。
+
+動的読み込みに変更しても解決にはなりません。メッセージごとに関数が分かれているため、それぞれを遅延読み込みすると数千回ものネットワークリクエストが発生してしまうからです。
+
+Intlayer では、グローバルまたは辞書単位で柔軟に設定を選択できます：
+
+```ts fileName="intlayer.config.ts"
+import { Locales, type IntlayerConfig } from "intlayer";
+
+const config: IntlayerConfig = {
+  internationalization: {
+    locales: [Locales.ENGLISH, Locales.FRENCH, Locales.SPANISH],
+    defaultLocale: Locales.ENGLISH,
+  },
+  dictionary: {
+    importMode: "dynamic", // 'static' | 'dynamic' | 'fetch'
+  },
+};
+
+export default config;
+```
+
+| `importMode` | クライアントに配信される内容               | vs Paraglide                        |
+| ------------ | ------------------------------------------ | ----------------------------------- |
+| `static`     | ページで使用される辞書の全言語             | 理論上は同等の容量                  |
+| `dynamic`    | 現在のロケールのみ、辞書ごとに遅延読み込み | N 言語の場合、**N 分の 1 に軽量化** |
+| `fetch`      | 現在のロケールのみ、Live Sync API から取得 | N 言語の場合、**N 分の 1 に軽量化** |
+
+[ビルド変換](https://intlayer.org/ja/doc/concept/bundle-optimization) と `importMode: 'static'` を組み合わせることで、Intlayer は理論上 Paraglide とまったく同じ容量を配信します。`'dynamic'` または `'fetch'` を使用すれば、現在のロケールに必要なものだけを読み込むため、N 言語対応のアプリでは翻訳ペイロードが Paraglide と比較して N 分の 1 に削減されます。
+
+## Paraglide が適しているユースケース
+
+<AccordionGroup>
+<Accordion header="言語数が少ない Svelte + Vite 環境">
+
+スタックが Svelte + Vite であり、サポートする言語が 2〜3 言語程度であれば、Tree Shaking は仕様どおりに機能し、言語によるオーバーヘッドも小さく抑えられます。
+
+</Accordion>
+<Accordion header="既存の inlang ワークフロー">
+
+チームがすでに inlang エコシステム（Fink、Sherlock、メッセージフォーマットプラグイン）を活用している場合、Paraglide はネイティブに連携できます。
+
+</Accordion>
+</AccordionGroup>
+
+## ご自身のアプリで検証してみてください
+
+無料の [i18n SEO Scanner](https://intlayer.org/i18n-seo-scanner) を使って、本番アプリケーションの転送量とロケール漏洩をチェックできます：
+
+<ClickToOpenIframe src="https://intlayer.org/i18n-seo-scanner" width="100%" height="600px" style="border:none;"/>
+
+Intlayer の導入手順：
+
+```bash packageManager="npm"
+npx intlayer init --interactive
+```
+
+```bash packageManager="pnpm"
+pnpm dlx intlayer init --interactive
+```
+
+```bash packageManager="yarn"
+yarn dlx intlayer init --interactive
+```
+
+```bash packageManager="bun"
+bunx intlayer init --interactive
+```
+
+## 関連リファレンス
+
+- [TanStack Start i18n ベンチマーク](https://intlayer.org/ja/doc/benchmark/tanstack)
+- [Next.js i18n ベンチマーク](https://intlayer.org/ja/doc/benchmark/nextjs)
+- [バンドル最適化と `importMode`](https://intlayer.org/ja/doc/concept/bundle-optimization)
+- [React 向け i18n ライブラリの選び方](https://intlayer.org/ja/blog/how-to-pick-react-i18n-library)
+- [コンパイラ駆動型国際化のメリットとデメリット](https://intlayer.org/ja/blog/compiler-vs-declarative-i18n)