@intlayer/docs 9.5.6 → 9.5.7

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/lingui_vs_intlayer.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "Lingui vs Intlayer: 2026年ベンチマーク＆機能比較"
 description: "Next.jsおよびTanStack Startで測定された2つのコンパイラベースi18nライブラリ。バンドルサイズ、コンテンツリーク率、コンポーネントサイズ、ハイドレーション、言語切り替え応答性、および開発者体験の徹底比較。"
 keywords:
@@ -24,6 +24,8 @@ author: aymericzip
 
 # Lingui VS Intlayer | React & Next.js 国際化 (i18n) ベンチマーク比較
 
+![JavaScript i18n library ecosystem](https://github.com/aymericzip/intlayer/blob/main/docs/assets/cloud_i18n_logo.webp?raw=true)
+
 LinguiとIntlayerは、本ベンチマークにおいて純粋なランタイムではなく**コンパイラ**を活用する2つのライブラリです。Linguiはビルド時にマクロからメッセージを抽出し、言語ごとにカタログをコンパイルします。Intlayerはコンポーネント単位で辞書をコンパイルし、言語ごとにTree-shakingを行います。理論上は非常に近い性能になるはずですが、実測データはその決定的な違いを浮き彫りにしています。
 
 測定データは、各ライブラリで同一のアプリケーションを構築しブラウザが実際にダウンロード・実行する内容を記録するオープンソースの検証スイート [Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom) に基づいています。
@@ -96,6 +98,10 @@ Intlayerには個別の "scoped" バリアントは存在しません。コン
 
 ### Next.jsでの測定結果
 
+関心のある指標とライブラリを選択してください：
+
+<I18nBenchmark framework="nextjs" vertical/>
+
 | ライブラリ          | 戦略           | Lib size (gz) | Page JS 平均 (gz) | 言語リーク | ページリーク | コンポーネント平均 (gz) |   E2E応答性 | ハイドレーション |
 | ------------------- | -------------- | ------------: | ----------------: | ---------: | -----------: | ----------------------: | ----------: | ---------------: |
 | **base** (i18nなし) | -              |        0.0 KB |          141.0 KB |       0.0% |         0.0% |                  0.9 KB |     13.4 ms |          11.8 ms |
@@ -114,6 +120,15 @@ Intlayerには個別の "scoped" バリアントは存在しません。コン
 - **原文フォールバックによるリーク。** 最適化構成であっても、**フランス語ページに英語文字列が3〜15%混入**します。Linguiマクロはフォールバック用として原文をバンドル内に保持するためです。Intlayerはビルド時にフォールバックを解決し、要求された言語のみを配信します。
 - **`scoped-dynamic` でコンポーネントが肥大化。** 個別にコンパイルされたコンポーネントは平均 **152.6 KB** に達します。インポートを通じて各ルートのカタログに到達可能となるためです。同じコンポーネントを `useIntlayer()` で組んだ場合は平均 **6.9 KB** です。
 
+<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での測定結果
 
 | ライブラリ                | 戦略           | Lib size (gz) | Page JS 平均 (gz) | 言語リーク | ページリーク | コンポーネント平均 (gz) |  E2E応答性 | ハイドレーション |
@@ -135,8 +150,19 @@ Intlayerには個別の "scoped" バリアントは存在しません。コン
 - **Intlayerの `static` は最初からページリーク0%。** 該当ページのコンポーネントがインポートする辞書のみをバンドルするためです。設定に `importMode: 'dynamic'` を1行追加すれば言語リークも完全に解消されます。
 - **`@intlayer/lingui`** はLinguiのマクロ構文を維持したままIntlayerの辞書からコンテンツを供給します。ページサイズ（マクロランタイムが残るため137 KB）を少し犠牲にする代わりに、コンポーネントの軽量化（12.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)をご覧ください。
+
 ## なぜ差がつくのか？ 2つのコンパイラと2つの作業単位
 
+![The Intlayer compiler extracts content from components](https://github.com/aymericzip/intlayer/blob/main/docs/assets/compiler.webp?raw=true)
+
 両者ともコンパイルを行います。決定的な違いは**何を**コンパイルするかです。
 
 **Linguiはカタログをコンパイルします。** ソース内のマクロは言語ごとの `.po` ファイルに抽出され、言語ごとのJSモジュールにコンパイルされます。単位は**ロケール（言語全体）**です。これ以上細かく（ルート別やコンポーネント別に）分割するには、複数のカタログを作成し、`lingui.config.ts` でファイルごとに抽出元を設定し、各ルートで適切なファイルを読み込む必要があります。`I18n` インスタンスはグローバルであり、すべての `useLingui()` がコンポーネントをそこへ接続します。
@@ -176,7 +202,9 @@ Intlayerには個別の "scoped" バリアントは存在しません。コン
             └── about.content.ts
 ```
 
-これが、`scoped-dynamic` パターンがIntlayerにとって「自動出力」であり、Linguiにとっては「手動の設定プロジェクト」となる理由です。
+これが、`scoped-dynamic` パターンがIntlayerにとって「自動出力」であり、Linguiにとっては「手動の設定プロジェクト」となる理由です. その差はページとロケールの両軸で同時に拡大します：
+
+![Theoretical content leakage by architecture](https://github.com/aymericzip/intlayer/blob/main/docs/assets/theorical_content_leakage.webp?raw=true)
 
 > `dynamic` 行の測定結果を再現するには、`intlayer.config.ts` で `dictionary.importMode: 'dynamic'` を指定してください。詳細は [バンドル最適化ドキュメント](https://intlayer.org/ja/doc/concept/bundle-optimization) をご覧ください。
 
@@ -184,7 +212,8 @@ Intlayerには個別の "scoped" バリアントは存在しません。コン
 
 ### 初期設定
 
-**Lingui**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="Lingui" value="lingui">
 
 ```ts fileName="lingui.config.ts"
 import { defineConfig } from "@lingui/cli";
@@ -215,7 +244,8 @@ export const loadCatalog = async (locale: string) => {
 
 さらに `@lingui/babel-plugin-lingui-macro`（または `@lingui/swc-plugin`）をバンドラーに追加し、コード編集後に `lingui extract` を実行し、ビルド前に `lingui compile` を行い、ツリーを `<I18nProvider i18n={i18n}>` でラップします。
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="intlayer.config.ts"
 import { type IntlayerConfig, Locales } from "intlayer";
@@ -232,9 +262,12 @@ export default config;
 
 `vite.config.ts` に `intlayer()` を追加（Next.jsの場合は `next.config.ts` に `withIntlayer()` を追加）し、ツリーを `<IntlayerProvider>` でラップするだけです。抽出やコンパイルの個別コマンドは不要で、バンドラー実行時に自動処理されます。
 
+</Tab>
+</Tabs>
 ### コンポーネント実装
 
-**Lingui**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="Lingui" value="lingui">
 
 ```tsx fileName="src/components/Counter.tsx"
 import { useState } from "react";
@@ -258,7 +291,8 @@ export const Counter = () => {
 
 英語テキストはコンポーネント内に記述し、フランス語テキストは `lingui extract` 実行後に `src/locales/fr/messages.po` 内のハッシュ化IDの下に生成されます。抽出やコンパイルを忘れると、無言で英語原文が表示されます。
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="src/components/Counter/index.content.ts"
 import { t, type Dictionary } from "intlayer";
@@ -297,11 +331,14 @@ export const Counter = () => {
 
 両言語がコンポーネントの隣の同一ファイルに同居します。`fr` の値が欠けていればビルドエラーになり、キー名を誤記すればTypeScriptが即座にエラーを報告します。
 
+</Tab>
+</Tabs>
 ### コンポーネント外部での利用
 
 メタデータ、ローダー、サーバー関数など、Reactツリーが存在しない場所での利用です。
 
-**Lingui**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="Lingui" value="lingui">
 
 ```ts fileName="src/routes/$locale/about.tsx"
 import { setupI18n } from "@lingui/core";
@@ -324,7 +361,8 @@ export const loader = async ({ params }: { params: { locale: string } }) => {
 
 呼び出しごとに新しい `I18n` インスタンスを生成し、適切なカタログを手動でインポートし、`t` ではなく `msg` + `i18n._()` を使用します。[ベンチマークノート](https://github.com/intlayer-org/benchmark-bloom/blob/main/report/NOTE.md)でも指摘されている通り、`t`、`` t` ` ``、`i18n.t()`、`msg`、`<Trans>` の使い分けは直感的とは言えません。
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="src/routes/$locale/about.tsx"
 import { getIntlayer } from "intlayer";
@@ -336,6 +374,9 @@ export const loader = async ({ params }: { params: { locale: string } }) => {
 };
 ```
 
+</Tab>
+</Tabs>
+
 ## Linguiマクロを維持したままIntlayer辞書を利用する
 
 `@intlayer/lingui` は、`@lingui/core` および `@lingui/react` 用のドロップインアダプターです。マクロはこれまで通りコンパイルされ、内部の `i18n._()` 呼び出しはIntlayer辞書から提供されます。`.po` 同期プラグインにより既存のカタログファイルをそのまま真実のソースとして保持可能です。ICUの複数形や条件分岐も同一にレンダリングされます。
@@ -353,16 +394,82 @@ export default defineConfig({
 
 ## どちらを選択すべきか？
 
-- **Linguiを選ぶべきケース**: 型付きマクロで **ICU MessageFormat** をフル活用したい場合、翻訳者が既存のTMS連携のもと **`.po`** ファイルで作業している場合、JSX内に原文を直接書きたい場合、および抽出・コンパイル・カタログ分割の工程をチームで無理なく運用できる場合。遅延ロードが確立されていれば、ページ容量は極めて良好です。
-- **Intlayerを選ぶべきケース**: **コンポーネントスコープのコンテンツ**、**厳格なTypeScript型チェック**、**ビルド時の未翻訳キー検出**、**設定不要の自動Tree-shaking＆遅延ロード**、軽量なコンポーネント、高速なハイドレーション、瞬時の言語切り替え、組み込みの編集ツール（Visual Editor、CMS、AI翻訳、MCPサーバー）を求める場合。特に大規模アプリやデザインシステムに最適です。
-- **`@intlayer/lingui` を選ぶべきケース**: 既存のLinguiアプリで、マクロを修正することなくIntlayerの辞書アーキテクチャへ段階的に移行したい場合。
+<AccordionGroup>
+<Accordion header="Lingui を選ぶ理由">
+
+型付きマクロを使用した **ICU MessageFormat** を求め、翻訳者が既存の TMS パイプラインで **`.po`** ファイルを扱い、JSX 内に直接ソース文字列を記述することを好み、チームが抽出・コンパイル・カタログ分割ワークフローの管理に慣れている場合。遅延読み込みを設定すれば、ページあたりの JS は十分に競争力があります。
+
+</Accordion>
+<Accordion header="Intlayer を選ぶ理由">
+
+**コンポーネントスコープのコンテンツ**、**厳格な TypeScript**、**ビルド時のキー欠落エラー**、**設定不要のツリーシェイキングと遅延読み込み**、軽量なコンポーネント、高速なハイドレーション、即時のロケール切り替え、および組み込みの編集ツール（[ビジュアルエディター](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/lingui を選ぶ理由">
+
+現在 Lingui を使用しており、マクロに手を加えることなく段階的に Intlayer の辞書へ移行したい場合。[PO 同期プラグイン](https://intlayer.org/ja/doc/compatibility/lingui)により、`.po` カタログは引き続き信頼できる単一の情報源として機能します。[Lingui vs @intlayer/lingui](https://intlayer.org/ja/blog/lingui-vs-intlayer-lingui) で詳細を測定しています。
+
+</Accordion>
+</AccordionGroup>
+
+## FAQ
+
+<FAQ>
+
+<Question title="Lingui もコンパイルしますが、なぜ出力がこれほど異なるのですか？">
+
+コンパイルの単位が異なるためです。Lingui は**ロケールごとに1つのカタログ**をコンパイルします。それ以下の単位（ルートごとのカタログ、遅延読み込み、フォールバックの除外）はすべて追加の設定が必要です。Intlayer は**コンポーネントごとに1つの辞書**をコンパイルするため、ルートごとのスコープがビルド時に自動的に生成されます。これが、単独でコンパイルされた Lingui コンポーネントが 6-8 KB に対し 58-153 KB になる理由です。
+
+</Question>
+
+<Question title="Lingui でロケールリークが 0% にならないのはなぜですか？">
+
+マクロは実行時のフォールバックとして元のメッセージを利用可能にしておくため、英語の文字列が翻訳と一緒にバンドルに含まれます。最適化されたすべての構成において、ベンチマークでは **`fr` ページ内に 3-15% の `en` 文字列が含まれる** ことが測定されています。Intlayer はビルド時にフォールバックを解決し、アクティブなロケールのみを配信します。
+
+</Question>
+
+<Question title="Lingui のページあたり JavaScript は本当に競争力がありますか？">
+
+はい、TanStack Start では僅差で勝利しています（`dynamic` で Intlayer の 118.6 KB に対し 115.2 KB）。ハッシュ化された ID を持つコンパイル済みカタログは非常にコンパクトです。ただしコストは別の場所に現れます。ハイドレーションは 11-14 ms に対し 28-34 ms であり、`scoped-dynamic` 構成でのロケール切り替えには **42 ms** かかります。
+
+</Question>
+
+<Question title="移行するためにマクロを諦める必要がありますか？">
+
+いいえ。`@intlayer/lingui` は `` t`...` ``、`<Trans>`、`msg`、`plural`、`select`、`selectOrdinal` を従来どおりコンパイルします。`i18n._()` が解決する参照先のみが変わります。ビルド構成で `@lingui/babel-plugin-lingui-macro` または `@lingui/swc-plugin` をそのまま維持してください。[Lingui 互換性ドキュメント](https://intlayer.org/ja/doc/compatibility/lingui)を参照してください。
+
+</Question>
+
+<Question title="抽出とコンパイルの手順はどうなりますか？">
+
+マクロ部分には残りますが、Intlayer 独自のコンテンツでは不要になります。`.content.ts` 辞書はバンドラーの実行時に自動構築され、個別の CLI コマンドは不要です。また、[`intlayer test`](https://intlayer.org/ja/doc/concept/cli) はキーが欠落している場合に元の文字列へ無言でフォールバックするのではなく、CI を失敗させます。
+
+</Question>
+
+</FAQ>
 
 ## 関連する比較記事
 
-- [next-intl vs Intlayer](https://intlayer.org/ja/blog/next-intl-vs-intlayer)（同一ベンチマーク）
-- [i18next vs Intlayer](https://intlayer.org/ja/blog/i18next-vs-intlayer)（同一ベンチマーク）
-- [vue-i18n vs Intlayer](https://intlayer.org/ja/blog/vue-i18n-vs-intlayer-benchmark)（同一ベンチマーク）
-- [コンパイラ型 vs 宣言型 i18n](https://intlayer.org/ja/blog/compiler-vs-declarative-i18n)
+同じベンチマーク、他のライブラリ：
+
+- [next-intl vs Intlayer](https://intlayer.org/ja/blog/next-intl-vs-intlayer)
+- [i18next vs Intlayer](https://intlayer.org/ja/blog/i18next-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)
+
+さらに詳しく：
+
+- [Lingui vs @intlayer/lingui](https://intlayer.org/ja/blog/lingui-vs-intlayer-lingui), 同一アプリで測定されたアダプター
+- [Compiler-driven vs declarative i18n](https://intlayer.org/ja/blog/compiler-vs-declarative-i18n)
+- [Per-component vs centralized i18n](https://intlayer.org/ja/blog/per-component-vs-centralized-i18n)
+- [ICU message format explained](https://intlayer.org/ja/blog/icu-message-format)
+
+参考ドキュメント：
+
+- [Next.js ベンチマークレポート](https://intlayer.org/ja/doc/benchmark/nextjs) および [TanStack Start ベンチマークレポート](https://intlayer.org/ja/doc/benchmark/tanstack)
+- [Compat adapter: Lingui](https://intlayer.org/ja/doc/compatibility/lingui)
+- [バンドル最適化](https://intlayer.org/ja/doc/concept/bundle-optimization) および [Intlayer コンパイラー](https://intlayer.org/ja/doc/compiler)
 
 ## GitHubスターの推移