@intlayer/docs 9.5.6 → 9.5.7

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)
 
 ## 結論
 

package/blog/ja/next-intl_vs_intlayer.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-09-13
-updatedAt: 2026-09-13
+updatedAt: 2026-09-22
 title: "next-intl vs Intlayer: 2026 ベンチマーク＆比較"
 description: Bundle size、content leakage、locale-switch の反応性、および Next.js と TanStack Start での開発者体験を測定。2026年ではどのi18nライブラリを選ぶべきでしょうか？
 keywords:
@@ -24,6 +24,8 @@ author: aymericzip
 
 # next-intl VS Intlayer | Next.js 国際化 (i18n) ベンチマーク
 
+![next-intl VS Intlayer](https://github.com/aymericzip/intlayer/blob/main/docs/assets/i18next-next-intl-intlayer.webp?raw=true)
+
 `next-intl`はNext.jsで最も人気のあるi18nライブラリです。Intlayerはコンパイラベース、コンポーネントスコープの代替案です。どちらもApp Routerアプリケーションをローカライズします。問題は、アプリがビルドされた後、それぞれがどの程度のコストがかかるかということです。
 
 この記事はチュートリアルではありません。[Benchmark Bloom](https://github.com/intlayer-org/benchmark-bloom)からの数値に基づいた比較です。Benchmark Bloomはオープンソースのベンチマークスイートで、各ライブラリで同じアプリケーションをビルドし、ブラウザが実際にダウンロードして実行するものを測定します。
@@ -96,6 +98,10 @@ Intlayerには「scoped」バリアントがありません。compilerはコン
 
 ### Next.js（App Router）の結果
 
+関心のあるメトリクスとライブラリを選択してください:
+
+<I18nBenchmark framework="nextjs" vertical/>
+
 | Library                        | Strategy       | Lib size (gz) | Page JS avg (gz) | Locale leak | Page leak | Component avg (gz) | E2E reactivity | Hydration |
 | ------------------------------ | -------------- | ------------: | ---------------: | ----------: | --------: | -----------------: | -------------: | --------: |
 | **base** (i18n なし)           | -              |        0.0 KB |         141.0 KB |        0.0% |      0.0% |             0.9 KB |        13.4 ms |   11.8 ms |
@@ -116,6 +122,15 @@ Intlayerには「scoped」バリアントがありません。compilerはコン
 - **コンポーネントサイズ。** `useTranslations()`を呼び出すコンポーネントは平均21.8 KBにコンパイルされ、`useIntlayer()`を使用した同じコンポーネントは6.9 KBにコンパイルされます。`scoped-static`セットアップでは、各コンポーネントがそのnamespace catalogをインラインで含めるため、`next-intl`コンポーネントは80.1 KBにジャンプします。
 - **リアクティビティとhydration**は、Next.js上の両方のライブラリで同じ範囲内です（15-18 ms）。ここではどちらもボトルネックではありません。
 
+<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`のframework-agnosticなコアです。同じAPI、同じメッセージフォーマット。TanStack Startで`intlayer`と比較することで、方程式からNext.js固有の部分を削除します。
@@ -139,8 +154,19 @@ Intlayerには「scoped」バリアントがありません。compilerはコン
 - **コンポーネントサイズはアーキテクチャが表れる場所です**：`use-intl`ではコンポーネントあたり76～87 KB対Intlayerの6～8 KB。`useTranslations()`は各コンポーネントをグローバルメッセージツリーにバインドします。`useIntlayer()`はそれを独自の辞書にバインドします。
 - **ロケール切り替え**は Intlayer で 2 倍～4 倍高速化されています（3 ms 対 7-21 ms）。
 
+<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)
+
 `next-intl` は従来のモデルに従います：ロケールごとに 1 つの JSON、`getRequestConfig` で読み込み、`NextIntlClientProvider` にプッシュされ、`t("namespace.key")` で読まれます。
 
 ```bash
@@ -162,6 +188,10 @@ Intlayerには「scoped」バリアントがありません。compilerはコン
 
 ランタイムはページがどのキーを使用するかを知ることができないため、安全なデフォルトはカタログ全体を送信することです。最適化するには、**あなた**がカタログを namespace に分割し、**あなた**が各ページに必要な namespace を決定し、**あなた**がコンポーネントが移動するにつれてそのマッピングを同期させ続ける必要があります。ベンチマークの `scoped-dynamic` 行はその作業の報酬であり、ほとんどのチームはそこに到達しません。
 
+その最適化を行わない場合のコストは、ページ数とロケール数の2つの軸で同時に増大します:
+
+![Theoretical content leakage by architecture](https://github.com/aymericzip/intlayer/blob/main/docs/assets/theorical_content_leakage.webp?raw=true)
+
 Intlayer は責任を逆転させます。コンテンツはコンポーネントの隣に宣言されます：
 
 ```bash
@@ -189,7 +219,8 @@ Intlayer は責任を逆転させます。コンテンツはコンポーネン
 
 ### Client component
 
-**next-intl**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-intl" value="next-intl">
 
 ```json fileName="messages/en.json"
 {
@@ -226,7 +257,8 @@ export const Counter = () => {
 
 > このコンポーネントをレンダリングするすべてのページで、`NextIntlClientProvider`に渡されるメッセージに`counter`名前空間を含めることを忘れないでください。
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```ts fileName="src/components/Counter/index.content.ts"
 import { t, type Dictionary } from "intlayer";
@@ -269,11 +301,14 @@ export const Counter = () => {
 
 ページに登録する必要はありません。コンポーネントが独自のコンテンツを提供します。
 
+</Tab>
+</Tabs>
 ### 同期サーバーコンポーネント
 
 Design-system pieces (navbar, footer, cards) はしばしば client components の子として render される server components であるため、`async` にすることはできません。
 
-**next-intl**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-intl" value="next-intl">
 
 ```tsx fileName="src/components/ServerCounter.tsx"
 type ServerCounterProps = {
@@ -291,7 +326,8 @@ export const ServerCounter = ({ t, formattedCount }: ServerCounterProps) => (
 
 ページは `await getTranslations("counter")` と `await getFormatter()` を実行し、その結果を props として下に渡す必要があります。コンポーネントはもはや self-contained ではありません。
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```tsx fileName="src/components/ServerCounter.tsx"
 import { useIntlayer } from "next-intlayer/server";
@@ -311,9 +347,12 @@ export const ServerCounter = ({ count }: { count: number }) => {
 };
 ```
 
+</Tab>
+</Tabs>
 ### メタデータ
 
-**next-intl**
+<Tabs defaultTab="intlayer" group="techno">
+<Tab label="next-intl" value="next-intl">
 
 ```tsx fileName="src/app/[locale]/about/page.tsx"
 import type { Metadata } from "next";
@@ -348,7 +387,8 @@ export const generateMetadata = async ({
 };
 ```
 
-**Intlayer**
+</Tab>
+<Tab label="Intlayer" value="intlayer">
 
 ```tsx fileName="src/app/[locale]/about/page.tsx"
 import { getIntlayer, getMultilingualUrls } from "intlayer";
@@ -372,6 +412,9 @@ export const generateMetadata = async ({
 };
 ```
 
+</Tab>
+</Tabs>
+
 ## next-intl API を維持しながら Intlayer の出力を取得する
 
 ベンチマーク結果を得るためにコンポーネントを書き換える必要はありません。`@intlayer/next-intl` はドロップイン アダプターです。`useTranslations`、`getTranslations`、`useFormatter`、`t.rich()`、ICU複数形、および `next-intl/navigation` ヘルパーを保持し、Intlayer コンパイラでコンパイルされた Intlayer辞書から提供します。
@@ -393,17 +436,84 @@ export default withIntlayer(nextConfig);
 
 ## どちらを選ぶべきか？
 
-- **next-intl を選ぶべきケース**: Next.js のエコシステム標準を重視する場合、ICU MessageFormat に依存している場合、アプリが小〜中規模の場合、または中央集権型の JSON を想定する翻訳プラットフォーム（Crowdin、Phrase、Lokalise など）と統合する場合。パフォーマンスが重要な場合は、名前空間カタログの分割やページごとのメッセージ抽出に時間を割く必要があります。
-- **Intlayer を選ぶべきケース**: **コンポーネント単位のコンテンツ**、**厳格な TypeScript**、**ビルド時のキー不足エラー検出**、**設定不要のツリーシェイキングと遅延読み込み**、同期サーバーコンポーネント、組み込みの編集ツール（ビジュアルエディター、CMS、AI 翻訳、MCP サーバー）を求める場合。特に大規模でモジュール化されたコードベースやデザインシステムに適しています。
-- **`@intlayer/next-intl` を選ぶべきケース**: すでに `next-intl` を使用しており、コードを書き換えることなくバンドルサイズの削減効果を得たい場合。
+<AccordionGroup>
+<Accordion header="next-intl を選ぶ理由">
+
+Next.js のエコシステム標準を求め、ICU MessageFormat に依存しており、アプリが中小規模であるか、集中型 JSON を前提とする翻訳プラットフォーム（Crowdin、Phrase、Lokalise...）と連携する場合。パフォーマンスを重視するなら、カタログをネームスペースに分割し、ページごとに `pick()` でメッセージを選別する工数を確保してください。
+
+</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/next-intl を選ぶ理由">
+
+すでに `next-intl` を導入しており、コードを書き直すことなくバンドルサイズの削減効果を得たい場合。[互換アダプター](https://intlayer.org/ja/doc/compatibility/next-intl)により、既存のインポートと `messages/{locale}.json` ファイルを信頼できる唯一の情報源として維持できます。[next-intl vs @intlayer/next-intl](https://intlayer.org/ja/blog/next-intl-vs-intlayer-next-intl) で直接比較されています。
+
+</Accordion>
+</AccordionGroup>
+
+## FAQ
+
+<FAQ>
+
+<Question title="next-intl は Intlayer より遅いですか？">
+
+レンダリング時は変わりません。違いはブラウザに配信されるサイズにあります。`next-intl` は各ページで **+12.6 KB gzip** のランタイムを要し、一般的な構成では他のページのテキストの約90%を一緒に配信してしまいます。Next.js でのロケール切り替えとハイドレーション時間はほぼ同等です（15-18ミリ秒）。TanStack Start では `use-intl` が7-21ミリ秒かかるのに対し、Intlayer は3-4ミリ秒です。
+
+</Question>
+
+<Question title="next-intl で漏洩率0%を達成できますか？">
+
+はい、`scoped-dynamic` 構成を採用すれば可能です。`messages/{locale}.json` をルートごとのネームスペースに分割し、各ページで `pick(messages, [...])` を適用し、コンポーネント移動時にもそのマッピングを正確に維持します。ベンチマークの `scoped-*` 行はその作業の成果を示しています。Intlayer はコンパイラがコンポーネントごとにコンテンツをスコープ化するため、何もしなくてもデフォルトで0%を達成します。[バンドル最適化](https://intlayer.org/ja/doc/concept/bundle-optimization)を参照してください。
+
+</Question>
+
+<Question title="移行のためにコンポーネントを書き直す必要がありますか？">
+
+いいえ。`@intlayer/next-intl` は `useTranslations`、`getTranslations`、`useFormatter`、`t.rich()`、ICU複数形、ナビゲーションヘルパーを維持し、コンパイル済み辞書から提供します。`next.config.ts` にプラグインを1行追加するだけです。詳細は [next-intl 移行ガイド](https://intlayer.org/ja/doc/migration/next-intl) をご覧ください。
+
+</Question>
+
+<Question title="Intlayer は ICU MessageFormat をサポートしていますか？">
+
+ネイティブAPIでのICUサポートは順次拡張中です。互換アダプター（`@intlayer/next-intl`、`@intlayer/use-intl`）はすでにICUを実行可能です。複数形、`select`、`selectordinal`、`#`、`{ts, date, long}` は Intlayer のICUリゾルバーを介して処理されます。詳しくは [ICU メッセージ形式の解説](https://intlayer.org/ja/blog/icu-message-format) をお読みください。
+
+</Question>
+
+<Question title="messages/{locale}.json ファイルを維持できますか？">
+
+はい。[JSON同期プラグイン](https://intlayer.org/ja/doc/compatibility/next-intl)がそれらを読み込み、トップレベルのキーを辞書に分割し、CLIやCMSの更新時に同じファイルへ翻訳を書き戻します。翻訳チームのワークフローを変える必要はありません。
+
+</Question>
+
+</FAQ>
 
 ## 関連する比較
 
-- [i18next vs Intlayer](https://intlayer.org/ja/blog/i18next-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) (同一ベンチマーク)
+同じベンチマーク、他のライブラリ:
+
+- [i18next vs Intlayer](https://intlayer.org/ja/blog/i18next-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)
-- [next-intl は時代遅れか？](https://intlayer.org/ja/blog/is-next-intl-outdated)
+- [react-i18next vs react-intl vs Intlayer](https://intlayer.org/ja/blog/react-i18next-vs-react-intl-vs-intlayer)
+
+next-intl についてさらに詳しく:
+
+- [next-intl vs @intlayer/next-intl](https://intlayer.org/ja/blog/next-intl-vs-intlayer-next-intl), 同一アプリで測定されたアダプター
+- [Is next-intl outdated?](https://intlayer.org/ja/blog/is-next-intl-outdated)
+- [Using Intlayer with next-intl](https://intlayer.org/ja/blog/intlayer-with-next-intl)
+- [How to internationalize a Next.js app with next-intl](https://intlayer.org/ja/blog/nextjs-internationalization-using-next-intl)
+
+リファレンスドキュメント:
+
+- [Next.js ベンチマークレポート](https://intlayer.org/ja/doc/benchmark/nextjs) および [TanStack Start ベンチマークレポート](https://intlayer.org/ja/doc/benchmark/tanstack)
+- [互換アダプター: next-intl](https://intlayer.org/ja/doc/compatibility/next-intl) および [移行ガイド](https://intlayer.org/ja/doc/migration/next-intl)
+- [バンドル最適化](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 STARS