@intlayer/docs 9.5.6 → 9.5.8

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スターの推移
 

package/blog/ja/next-intl_vs_intlayer-next-intl.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "next-intl vs @intlayer/next-intl: 同じAPI、異なるBundle"
 description: Next.js アプリケーションの next-intl インポートが @intlayer/next-intl compat アダプターによって提供される場合に何が変わるかを説明します。Bundle サイズ、リーケージ、コンポーネントサイズ、および同じコードで測定されたハイドレーション、およびアダプターが保持、無視、および置き換えることができない内容。
 keywords:
@@ -26,6 +26,8 @@ author: aymericzip
 
 # next-intl VS @intlayer/next-intl | 同じAPI、異なるBundle
 
+![next-intl VS Intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18next-next-intl-intlayer.webp?raw=true)
+
 `@intlayer/next-intl` は互換性アダプタです。`next-intl` API (`useTranslations`、`getTranslations`、`useLocale`、`t.rich()`、ICU複数形、`NextIntlClientProvider`...)を公開し、Intlayerによってコンパイルされたディクショナリから提供します。アプリケーションコードは変わりません。bundleが変わります。
 
 この記事は、同じNext.jsアプリケーションで2つを比較しており、1回は`next-intl`で構築し、もう1回はアダプタで構築しています。数値は[Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom)から得られており、これはブラウザが実際にダウンロードするものを記録するオープンソーススイートです。ライブラリとして`next-intl`とIntlayerの比較が必要な場合は、[next-intl vs Intlayer](https://intlayer.org/blog/next-intl-vs-intlayer)をお読みください。このドキュメントは、コンポーネントをそのままにしておいたときにアダプタが何を変更するかについてです。
@@ -110,6 +112,10 @@ const AboutPage = () => {
 
 ### Next.js での結果
 
+関心のある指標とライブラリを選択してください：
+
+<I18nBenchmark framework="nextjs" vertical/>
+
 | Setup                     | Strategy       | Lib size (gz) | Page JS avg (gz) | Locale leak | Page leak | Component avg (gz) | E2E reactivity |   Hydration |
 | ------------------------- | -------------- | ------------: | ---------------: | ----------: | --------: | -----------------: | -------------: | ----------: |
 | **base** (no i18n)        | -              |        0.0 KB |         141.0 KB |        0.0% |      0.0% |             0.9 KB |        13.4 ms |     11.8 ms |
@@ -130,6 +136,15 @@ const AboutPage = () => {
 - **Hydrationが2ms高速** (12.8 vs 14.7 ms): RSCペイロードから逆シリアル化するメッセージオブジェクトがないため、Reactが水和できます。
 - **アダプターはネイティブランタイムではありません。** `next-intlayer`は**141.3 KB**で、ベースアプリの上に+0.3 KBで、5.5 KBのランタイムを備えています。アダプターはIntlayerのコア上に`next-intl` APIサーフェス(`useFormatter`、`t.rich`、ICUリゾルバ)を搭載しており、したがって8.0 KBと1ページあたり+6 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上の結果 (`use-intl`)
 
 `use-intl`は`next-intl`のフレームワークに依存しないコアです。そのアダプター`@intlayer/use-intl`は、Viteプラグイン(`@intlayer/use-intl/plugin`)を使用して同じ設計に従います。
@@ -153,11 +168,24 @@ const AboutPage = () => {
 - **ロケール切り替えが高速。** 最適化された`use-intl`セットアップは`html[lang]`を更新するのに**13～21 ms**かかります。アダプターは**4～9 ms**かかります。再レンダリングされるコンポーネントが少なく、メッセージツリーから再取得されるものがありません。
 - **`static`はすべてのロケールを保持する。** アダプターの`static`行は49.7%のロケールリークを示しており、これはネイティブIntlayerの`static`モードと同じです。すべてのロケールがバンドルされ、ページの辞書のみが対象です。1行の設定（`importMode: 'dynamic'`）でこれを削除できます。
 
+<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)をご覧ください。
+
 ## 数字が変わる理由
 
+![The Intlayer compiler extracts content from components](https://github.com/aymericzip/intlayer/blob/main/docs/assets/compiler.webp?raw=true)
+
 コンポーネント内では何も変更されていないため、利益はすべて`useTranslations`がバインドされているもの由来です。
 
-**`next-intl`の場合**、バインディングはプロバイダーです。`NextIntlClientProvider`はロケールの`messages`オブジェクト全体を受け取り、すべての`useTranslations("about")`がそこから読み込まれます。バンドラーは1つのコンポーネントが1つのフックをインポートしており、そのフックが1つのコンテキストを読み込んでいることを認識しますが、`about`ブランチのみが使用されていることを知ることはできません。以下のルートはすべて同じメッセージオブジェクトを共有しているため、page-leakカラムは自分でファイルを分割するまで〜90%を読み込みます。
+**`next-intl`の場合**、バインディングはプロバイダーです。`NextIntlClientProvider`はロケールの`messages`オブジェクト全体を受け取り、すべての`useTranslations("about")`がそこから読み込まれます。バンドラーは1つのコンポーネントが1つのフックをインポートしており、そのフックが1つのコンテキストを読み込んでいることを認識しますが、`about`ブランチのみが使用されていることを知ることはできません。以下のルートはすべて同じメッセージオブジェクトを共有しているため、page-leakカラムは自分でファイルを分割するまで〜90%を読み込みます, そして無駄なオーバーヘッドは、ページとロケールの両軸で同時に増大します：
+
+![Theoretical content leakage by architecture](https://github.com/aymericzip/intlayer/blob/main/docs/assets/theorical_content_leakage.webp?raw=true)
 
 ```bash
 .
@@ -281,25 +309,106 @@ export default withIntlayer(nextConfig);
 
 ## 開始する前に知っておくべき制限事項
 
-- **ルーティング設定が `intlayer.config.ts` に移動します。** `createNavigation(routing)` と `createMiddleware(routing)` はシグネチャを保持しますが、引数を無視します。ロケール、デフォルトロケール、プレフィックス戦略は Intlayer の `routing` 設定から取得されます。`next-intl` のローカライズされた `pathnames`（`/about` → `/a-propos`）を使用している場合、アダプタはそれらをインターポレートしません。Intlayer の `routing.rewrite` がそのケースをカバーしますが、これは別の変更です。
-- **名前空間なしの `useTranslations()` はバインドされません。** 最適化パスは、どの辞書をインポートするかを知るための静的な名前空間が必要です。ベアコールは依然として機能しますが、すべての辞書を参照するランタイムレジストリを通じて機能します。これは正確に削除しようとしていたリークです。名前空間を渡してください。
-- **アダプターは無料ではありません。** `next-intlayer` の 5.5 KB に対して 8.0 KB のランタイム、ネイティブビルドよりページあたり +6-7 KB です。これは `next-intl` の API サーフェスの代償です。すべてのコンポーネントが `useIntlayer` に移行した時点で、アダプターを削除してください。
-- **プロバイダーの `messages`、`timeZone`、`now` は無視されます。** フォーマッターはネイティブの `Intl` によってバックアップされており、ロケールのみがその出力に影響します。ハイドレーション安定日時のために強制タイムゾーンや固定の `now` に依存している場合は、呼び出しサイトで処理してください。
+<AccordionGroup>
+<Accordion header="ルーティング設定は intlayer.config.ts に移行します">
+
+`createNavigation(routing)` と `createMiddleware(routing)` は関数のシグネチャを維持しますが引数は無視されます。ロケール、デフォルトロケール、プレフィックス戦略は Intlayer の `routing` 設定から取得されます。`next-intl` のローカライズされた `pathnames`（`/about` から `/a-propos`）を使用している場合、アダプターはそれらを補間しません。Intlayer の `routing.rewrite` がそのケースをカバーしますが、これは別の設定変更となります。
+
+</Accordion>
+<Accordion header="名前空間のない useTranslations() はバインドされません">
+
+最適化パスは、インポートする辞書を特定するために静的な名前空間を必要とします。名前空間なしの呼び出しは、すべての辞書を参照するランタイムレジストリを介して引き続き動作しますが、これはまさに排除しようとしていたリークそのものです。名前空間を渡してください。
+
+</Accordion>
+<Accordion header="アダプターは完全な無料ではありません">
+
+`next-intlayer` の 5.5 KB に対して 8.0 KB のランタイムが必要であり、ネイティブビルドと比較してページあたり +6-7 KB 増加します。これは `next-intl` API サーフェスを維持するための代償です。すべてのコンポーネントが `useIntlayer` に移行したら、アダプターを削除してください。
+
+</Accordion>
+<Accordion header="provider の messages、timeZone、now は無視されます">
+
+フォーマッターはネイティブの `Intl` に基づいており、ロケールのみが出力に影響します。ハイドレーションが安定した日付のために強制的なタイムゾーンや固定の `now` に依存している場合は、呼び出し側で処理してください。[日付、時刻、数値のフォーマット](https://intlayer.org/ja/blog/date-time-number-formatting-locales)を参照してください。
+
+</Accordion>
+</AccordionGroup>
 
 ## どれを使うべきか?
 
-- **`next-intl` に留まってください** アプリが小規模で、バンドルサイズが問題でなく、チームがネームスペースとページごとの `pick()` の管理に問題がない場合。
-- **`@intlayer/next-intl`を使用する** 現在`next-intl`を使用していて、バンドルサイズの削減、リークの防止、ハイドレーションの改善、型安全なキー、CLIおよびCMSツールが必要で、書き直したくない場合に推奨されます。これは既存の`next-intl` codebaseへの推奨エントリーポイントです。
-- **ネイティブに移行する（`next-intlayer`）** 新しいプロジェクト、またはアダプターがその役割を終えた後に推奨されます。3つの中で最も軽量（5.5 KB、ページあたり+0.3 KB）で、同期型サーバーコンポーネント、コンポーネント単位の`.content.ts`ファイル、および全機能セットをアンロックします。
+<AccordionGroup>
+<Accordion header="next-intl を使い続ける">
+
+アプリが小さく、バンドルサイズが懸念事項ではなく、チームがページごとに名前空間と `pick()` を手動管理することに慣れている場合。
+
+</Accordion>
+<Accordion header="@intlayer/next-intl を使用する">
+
+現在すでに `next-intl` を使用しており、コードを書き直すことなくバンドル削減、リーク防止、ハイドレーションの高速化、型付けされたキー、CLI / CMS ツールを活用したい場合。これは既存の `next-intl` コードベースにとって推奨されるエントリポイントです。
+
+</Accordion>
+<Accordion header="ネイティブ（next-intlayer）に移行する">
+
+新規プロジェクト、またはアダプターがその役割を果たした後に適しています。3つの中で最も軽量であり（5.5 KB、ページあたり +0.3 KB）、同期サーバーコンポーネント、コンポーネントごとの `.content.ts` ファイル、およびすべてのフル機能を活用できます。[Next.js での Intlayer の導入](https://intlayer.org/ja/doc/environment/nextjs)から始めてください。
+
+</Accordion>
+</AccordionGroup>
+
+## FAQ
+
+<FAQ>
+
+<Question title="アプリケーションコードは本当に変更しなくてよいのですか？">
+
+Next.js において、コンポーネントは変更不要です。ベンチマークのビルドでは `next.config.ts` と `intlayer.config.ts` のみを変更しました。`src/i18n.ts` 内の `getRequestConfig`、provider の `messages` プロパティ、およびページごとの `pick()` 呼び出しはデッドコードとなり、後から削除できます。
+
+</Question>
+
+<Question title="ICU メッセージはどうなりますか？">
+
+そのまま動作し続けます。`t("key", { count })`、`t.rich()`、`t.markup()`、`select`、`selectordinal`、`#`、`{ts, date, long}` は Intlayer の ICU リゾルバーによって解決されます。[ICU メッセージフォーマット](https://intlayer.org/ja/blog/icu-message-format)を参照してください。
+
+</Question>
+
+<Question title="なぜアダプターはネイティブの next-intlayer より重いのですか？">
+
+Intlayer コアの上に `next-intl` API サーフェス（`useFormatter`、`t.rich`、ICU リゾルバー、ナビゲーションヘルパー）を搭載しているためです。これにより 5.5 KB に対して 8.0 KB となり、ページあたり +6 KB 増加します。これは架け橋であり、最終目的地ではありません。
+
+</Question>
+
+<Question title="コンポーネントごとに段階的に移行できますか？">
+
+はい。任意のコンポーネントで、同一階層に `.content.ts` を配置することで `useTranslations("about")` から `useIntlayer("about")` へ移行できます。JSON と `.content.ts` の辞書は共存してマージされます。
+
+</Question>
+
+<Question title="ローカライズされたパス名（pathnames）は機能しますか？">
+
+`next-intl` の `pathnames` 経由では機能しません。アダプターは型チェック用に受け入れますが補間は行いません。代わりに Intlayer の `routing.rewrite` を使用してください。
+
+</Question>
+
+</FAQ>
 
 ## 関連する比較
 
-- [next-intl vs Intlayer](https://intlayer.org/blog/next-intl-vs-intlayer) （ライブラリ、同じベンチマーク）
-- [i18next vs @intlayer/i18next](https://intlayer.org/blog/i18next-vs-intlayer-i18next) （同じアダプターシリーズ）
-- [Lingui vs @intlayer/lingui](https://intlayer.org/blog/lingui-vs-intlayer-lingui) (同じアダプターシリーズ)
-- [vue-i18n vs @intlayer/vue-i18n](https://intlayer.org/blog/vue-i18n-vs-intlayer-vue-i18n) (同じアダプターシリーズ)
-- [移行ガイド: next-intl to Intlayer](https://intlayer.org/doc/migration/next-intl)
-- [互換性アダプターリファレンス: next-intl](https://intlayer.org/doc/compatibility/next-intl)
+同じアダプターシリーズ：
+
+- [i18next vs @intlayer/i18next](https://intlayer.org/ja/blog/i18next-vs-intlayer-i18next)
+- [Lingui vs @intlayer/lingui](https://intlayer.org/ja/blog/lingui-vs-intlayer-lingui)
+- [vue-i18n vs @intlayer/vue-i18n](https://intlayer.org/ja/blog/vue-i18n-vs-intlayer-vue-i18n)
+
+両ライブラリの直接比較：
+
+- [next-intl vs Intlayer](https://intlayer.org/ja/blog/next-intl-vs-intlayer), 同じベンチマーク
+- [next-i18next vs next-intl vs Intlayer](https://intlayer.org/ja/blog/next-i18next-vs-next-intl-vs-intlayer)
+- [Is next-intl outdated?](https://intlayer.org/ja/blog/is-next-intl-outdated)
+
+参考ドキュメント：
+
+- [Compat adapter: next-intl](https://intlayer.org/ja/doc/compatibility/next-intl)
+- [移行ガイド：next-intl から Intlayer へ](https://intlayer.org/ja/doc/migration/next-intl)
+- [Next.js ベンチマークレポート](https://intlayer.org/ja/doc/benchmark/nextjs) および [TanStack Start ベンチマークレポート](https://intlayer.org/ja/doc/benchmark/tanstack)
+- [バンドル最適化](https://intlayer.org/ja/doc/concept/bundle-optimization) および [Intlayer コンパイラー](https://intlayer.org/ja/doc/compiler)
+- [ビジュアルエディター](https://intlayer.org/ja/doc/concept/editor)、[CMS](https://intlayer.org/ja/doc/concept/cms) および [AI 翻訳](https://intlayer.org/ja/doc/concept/auto-fill)
 
 ## 結論