@intlayer/docs 9.5.1 → 9.5.2

package/docs/ja/benchmark/nextjs.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-04-20
-updatedAt: 2026-05-18
+updatedAt: 2026-09-11
 title: 2026年におけるNext.jsの最適なi18nソリューション - ベンチマークレポート
 description: next-intl、next-i18next、IntlayerなどのNext.js国際化（i18n）ライブラリを比較。バンドルサイズ、リーク、反応性に関する詳細なパフォーマンスレポート。
 keywords:
@@ -17,6 +17,9 @@ slugs:
 author: aymericzip
 applicationTemplate: https://github.com/intlayer-org/benchmark-i18n
 history:
+  - version: 9.5.1
+    date: 2026-09-11
+    changes: "ベンチマーク結果を更新"
   - version: 8.9.8
     date: 2026-05-18
     changes: "GitHub スター比較を追加"
@@ -56,7 +59,7 @@ style="border:none;"
 
 アプリが成長するにつれて、バンドルサイズが指数関数的に増大し、パフォーマンスが著しく低下する可能性があります。
 
-最悪のケースでは、国際化によってページサイズが4倍近くに膨れ上がることがあります。
+最悪のケースでは、国際化によってページサイズが2倍近くに膨れ上がることがあります。
 
 また、i18nライブラリのもう一つの影響として、開発の遅延が挙げられます。コンポーネントを多言語対応に作り変える作業は時間がかかります。
 
@@ -68,7 +71,7 @@ Intlayerは、これらの各側面において最適化を試みています。
 
 - **Intlayer** & **next-translate**: Next.jsのパフォーマンスにおいて最適な選択肢。最小のフットプリントと最高の静的レンダリングサポートを提供。
 - **next-intl**: 最もトレンドのオプションだが、大規模なアプリケーション向けに最適化するには重く、複雑。
-- **next-i18next**: 人気がありプラグインも豊富だが、バンドル重量が非常に大きい（Intlayer의約3倍）。
+- **next-i18next**: 人気がありプラグインも豊富だが、バンドル重量が非常に大きい（Intlayer의約3.5倍）。
 - **避けるべき**: **gt-next** と **lingo.dev**。深刻なパフォーマンスの問題、ベンダーロックイン、ビルドを破壊するバグのため。
 
 ## アプリをテストする
@@ -109,19 +112,21 @@ WebpackやTurbopackを使用し、`[locale]/page.tsx`のようなルートを宣
 このベンチマークでは、以下のライブラリを比較しました。
 
 - `Base App`（i18nライブラリなし）
-- `next-intlayer` (v8.7.12)
-- `next-i18next` (v16.0.5)
-- `next-intl` (v4.9.1)
-- `@lingui/core` (v5.3.0)
-- `next-translate` (v3.1.2)
+- `next-intlayer` (v9.5.1)
+- [`@intlayer/next-intl`](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ja/compat/next-intl.md) (v9.5.1)
+- [`@intlayer/next-i18next`](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ja/compat/next-i18next.md) (v9.5.1)
+- `next-i18next` (v16.3.0)
+- `next-intl` (v4.14.2)
+- `@lingui/core` (v6.6.0)
+- `next-translate` (v3.2.0)
 - `next-international` (v1.3.1)
 - `@inlang/paraglide-js` (v2.15.1)
-- `@tolgee/react` (v7.0.0)
-- `@lingo.dev/compiler` (v0.4.0)
-- `wuchale` (v0.22.11)
-- `gt-next` (v6.16.5)
+- `@tolgee/react` (v7.2.0)
+- `@lingo.dev/compiler` (v0.4.12)
+- `wuchale` (v0.26.6)
+- `gt-next` (v11.1.24)
 
-Next.jsのバージョンは`16.2.4`（App Router）を使用しました。
+Next.jsのバージョンは`16.3.4`（App Router）を使用しました。
 
 **10ページ**と**10言語**を持つ多言語アプリを作成しました。
 
@@ -175,15 +180,15 @@ GitHubのスターは、プロジェクトの普及度、コミュニティの
 
 遭遇した問題：
 
-**(General Translation)** (`gt-next@6.16.5`):
+**(General Translation)** (`gt-next@11.1.24`):
 
-- 110kbのアプリに対して、`gt-next`は440kb以上の余分なデータを追加します。
+- 141kbのアプリに対して、`gt-next`は50kb以上の余分なデータを追加します。
 - General Translationを使用した最初のビルドで「Quota Exceeded, please upgrade your plan（クォータ超過、プランをアップグレードしてください）」と表示されました。
 - 翻訳がレンダリングされません。`Error: <T> used on the client-side outside of <GTProvider>`というエラーが発生しましたが、これはライブラリのバグのようです。
 - **gt-next**を実装中、ライブラリの[問題](https://github.com/generaltranslation/gt/issues/1210#event-24510646961)にも遭遇しました。`does not provide an export named 'printAST' - @formatjs/icu-messageformat-parser`というエラーでアプリケーションが壊れました。この問題を報告した後、メンテナは24時間以内に修正しました。
 - このライブラリはNext.jsページの静的レンダリングをブロックします。
 
-**(Lingo.dev)** (`@lingo.dev/compiler@0.4.0`):
+**(Lingo.dev)** (`@lingo.dev/compiler@0.4.12`):
 
 - AIのクォータを超過し、ビルドが完全にブロックされました。つまり、支払いをしない限りプロダクションへのデプロイができません。
 - コンパイラが翻訳コンテンツの約40%を認識していませんでした。動作させるために、すべての`.map`をフラットなコンポーネントブロックに書き換える必要がありました。
@@ -192,7 +197,7 @@ GitHubのスターは、プロジェクトの普及度、コミュニティの
 
 ### 2 - 実験的なソリューション
 
-**(Wuchale)** (`wuchale@0.22.11`):
+**(Wuchale)** (`wuchale@0.26.6`):
 
 `Wuchale`の背後にあるアイデアは興味深いものですが、まだ実用的ではありません。反応性の問題に遭遇し、アプリを動作させるためにプロバイダーの強制的な再レンダリングが必要でした。ドキュメントもかなり不明瞭で、導入のハードルが高いです。
 
@@ -202,21 +207,21 @@ GitHubのスターは、プロジェクトの普及度、コミュニティの
 個人的には、プッシュのたびにJSファイルを再生成しなければならないのが嫌いです。これはPRを通じて常にマージ競合のリスクを生み出します。また、このツールはNext.jsよりもViteにフォーカスしているように見えます。
 最後に、他のソリューションと比較して、Paraglideはコンテンツをレンダリングするために現在のロケールを取得するためのストア（例：Reactコンテキスト）を使用しません。パースされる各ノードについて、localStorageやクッキーなどからロケールをリクエストします。これにより、コンポーネントの反応性に影響を与える不要なロジックが実行されます。
 
-> paraglideについての注意：このソリューションは、インポートのためにコードベースにコードを注入します。その結果、ベンチマークレポートの「ライブラリサイズ」指標はほぼ0になります。コード生成は良いことです。なぜなら、使用される関数には必要なロジック（すべてのプレフィックス対プレフィックスなし、クッキー対ストレージなど）のみが含まれるからです。対照的に、Intlayerはビルド時に環境変数を注入して、ロジックに応じてコンテンツをツリーシェイキングするようバンドラーに強制します。このおかげで、paraglideとintlayerは、i18nextやnext-intlよりも6〜10倍軽量なソリューションとなっています。
+> paraglideについての注意：このソリューションは、インポートのためにコードベースにコードを注入します。その結果、ベンチマークレポートの「ライブラリサイズ」指標はほぼ0になります。コード生成は良いことです。なぜなら、使用される関数には必要なロジック（すべてのプレフィックス対プレフィックスなし、クッキー対ストレージなど）のみが含まれるからです。対照的に、Intlayerはビルド時に環境変数を注入して、ロジックに応じてコンテンツをツリーシェイキングするようバンドラーに強制します。このおかげで、paraglideとintlayerは、i18nextやnext-intlよりも3〜8倍軽量なソリューションとなっています。
 
 ### 3 - 許容できるソリューション
 
-**(Tolgee)** (`@tolgee/react@7.0.0`):
+**(Tolgee)** (`@tolgee/react@7.2.0`):
 
 `Tolgee`は前述の問題の多くに対処しています。しかし、同様のツールよりも導入が難しいと感じました。型安全性が提供されていないため、コンパイル時に紛失したキーを見つけることも困難です。キーの不備を検出するために、Tolgeeの関数を自前の関数でラップする必要がありました。
 
-**(Next Intl)** (`next-intl@4.9.1`):
+**(Next Intl)** (`next-intl@4.14.2`):
 
-`next-intl`は最もトレンディな選択肢であり、AIエージェントが最も推奨するものですが、私の見解ではそれは間違いです。導入は簡単です。しかし実際には、リークを制限するための最適化は複雑です。動的ロード、ネームスぺーシング、TypeScriptの型を組み合わせると、開発スピードが著しく低下します。パッケージもかなり重いです（`NextIntlClientProvider` + `useTranslations`で約13kb、これは`next-intlayer`の2倍以上です）。**next-intl**はかつてNext.jsページの静的レンダリングをブロックしていました。`setRequestLocale()`というヘルパーを提供していますが、`en.json`や`fr.json`のような集中管理されたファイルに対しては部分的に対処されているものの、コンテンツが`en/shared.json`、`fr/shared.json`、`es/shared.json`のようにネームスペースに分割されている場合、依然として静的レンダリングが壊れます。
+`next-intl`は最もトレンディな選択肢であり、AIエージェントが最も推奨するものですが、私の見解ではそれは間違いです。導入は簡単です。しかし実際には、リークを制限するための最適化は複雑です。動的ロード、ネームスぺーシング、TypeScriptの型を組み合わせると、開発スピードが著しく低下します。パッケージもかなり重いです（`NextIntlClientProvider` + `useTranslations`で約14.7kb、これは`next-intlayer`の2.5倍以上です）。**next-intl**はかつてNext.jsページの静的レンダリングをブロックしていました。`setRequestLocale()`というヘルパーを提供していますが、`en.json`や`fr.json`のような集中管理されたファイルに対しては部分的に対処されているものの、コンテンツが`en/shared.json`、`fr/shared.json`、`es/shared.json`のようにネームスペースに分割されている場合、依然として静的レンダリングが壊れます。
 
-**(Next I18next)** (`next-i18next@16.0.5`):
+**(Next I18next)** (`next-i18next@16.3.0`):
 
-`next-i18next`は、JavaScriptアプリにおける最初期のi18nソリューションの一つであったため、おそらく最も人気のある選択肢です。多くのコミュニティプラグインがあります。これには`next-intl`と同じ大きな欠点があります。パッケージが非常に重いです（`I18nProvider` + `useTranslation`で約18kb、`next-intlayer`の約3倍）。
+`next-i18next`は、JavaScriptアプリにおける最初期のi18nソリューションの一つであったため、おそらく最も人気のある選択肢です。多くのコミュニティプラグインがあります。これには`next-intl`と同じ大きな欠点があります。パッケージが非常に重いです（`I18nProvider` + `useTranslation`で約19.7kb、`next-intlayer`の約3.5倍）。
 
 メッセージ形式も異なります。`next-intl`はICU MessageFormatを使用しますが、`i18next`は独自の形式を使用します。
 
@@ -224,17 +229,17 @@ GitHubのスターは、プロジェクトの普及度、コミュニティの
 
 `next-international`も上記の問題に取り組んでいますが、`next-intl`や`next-i18next`と大きな違いはありません。ネームスペース固有の翻訳のために`scopedT()`が含まれていますが、それを使用してもバンドルサイズへの影響はほとんどありません。
 
-**(Lingui)** (`@lingui/core@5.3.0`):
+**(Lingui)** (`@lingui/core@6.6.0`):
 
 `Lingui`はしばしば賞賛されます。個人的には、`lingui extract` / `lingui compile`のワークフローが他の選択肢よりも複雑で、明確な利点が見出せませんでした。また、AIを混乱させる一貫性のない構文（例：`t()`、`t''`、`i18n.t()`、`<Trans>`）も見受けられました。
 
 ### 4 - 推奨事項
 
-**(Next Translate)** (`next-translate@3.1.2`):
+**(Next Translate)** (`next-translate@3.2.0`):
 
-`t()`スタイルのAPIがお好みなら、`next-translate`が私の主な推奨事項です。`next-translate-plugin`を介して優雅に動作し、Webpack / Turbopackローダーを使用して`getStaticProps`経由でネームスペースをロードします。また、今回の中で最も軽量な選択肢です（約2.5kb）。ネームスぺーシングについては、設定ファイルでページやルートごとにネームスペースを定義する方法がよく考えられており、**next-intl**や**next-i18next**のような主要な選択肢よりもメンテナンスが容易です。バージョン`3.1.2`では、静的レンダリングが機能せず、Next.jsが動的レンダリングにフォールバックすることに気づきました。
+`t()`スタイルのAPIがお好みなら、`next-translate`が私の主な推奨事項です。`next-translate-plugin`を介して優雅に動作し、Webpack / Turbopackローダーを使用して`getStaticProps`経由でネームスペースをロードします。また、今回の中で最も軽量な選択肢の一つです（約3.5kb）。ネームスぺーシングについては、設定ファイルでページやルートごとにネームスペースを定義する方法がよく考えられており、**next-intl**や**next-i18next**のような主要な選択肢よりもメンテナンスが容易です。バージョン`3.1.2`では、静的レンダリングが機能せず、Next.jsが動的レンダリングにフォールバックすることに気づきました。
 
-**(Intlayer)** (`next-intlayer@8.7.12`):
+**(Intlayer)** (`next-intlayer@9.5.1`):
 
 客観性を保つため、自分自身のソリューションである`next-intlayer`については個人的な判断を控えさせていただきます。
 

package/docs/ja/benchmark/solid.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-04-20
-updatedAt: 2026-05-18
+updatedAt: 2026-09-11
 title: 2026年 Solid向けの最高のi18nソリューション - ベンチマークレポート
 description: solid-primitives、solid-i18next、IntlayerなどのSolid国際化（i18n）ライブラリを比較します。バンドルサイズ、リーク、反応性に関する詳細なパフォーマンスレポート。
 keywords:
@@ -17,6 +17,9 @@ slugs:
 author: aymericzip
 applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-solid-template
 history:
+  - version: 9.5.1
+    date: 2026-09-11
+    changes: "ベンチマーク結果を更新"
   - version: 8.9.8
     date: 2026-05-18
     changes: "GitHub スター比較を追加"
@@ -62,9 +65,9 @@ style="border:none;"
 
 ## TL;DR
 
-- **Intlayer**: 高度な機能と最適化を必要とするプロフェッショナルなSolidアプリケーションに推奨される選択肢（v8.7.12）。
+- **Intlayer**: 高度な機能と最適化を必要とするプロフェッショナルなSolidアプリケーションに推奨される選択肢（v9.5.0）。
 - **@solid-primitives/i18n**: シンプルなプロジェクトには優れた軽量な代替案ですが、遅延ロードなどの高度な機能に欠けます。
-- **solid-i18next**: 標準的ですが重い選択肢（Intlayerの約4.7倍）で、React i18nextと同じ欠点があります。
+- **solid-i18next**: 標準的ですが重い選択肢（Intlayerの約3.5倍）で、React i18nextと同じ欠点があります。
 - **Paraglide**: 革新的なアプローチですが、一部のセットアップではDXが複雑で、ツリーシェイキングの問題があります。
 
 ## アプリをテストする
@@ -97,10 +100,10 @@ i18nリークの問題を素早く特定するために、無料のスキャナ
 このベンチマークでは、以下のライブラリを比較しました。
 
 - `Base App` (i18nライブラリなし)
-- `solid-intlayer` (v8.7.12)
+- `solid-intlayer` (v9.5.0)
 - `@solid-primitives/i18n` (v2.2.1)
-- `solid-i18next` (v17.0.2)
-- `@inlang/paraglide-js` (v2.17.0)
+- `i18next` (v26.0.8) + `@mbarzda/solid-i18next` (v1.4.1)
+- `@inlang/paraglide-js` (v2.25.1)
 
 フレームワークは `Solid` で、**10ページ**と**10言語**を持つ多言語アプリを使用しました。
 
@@ -154,11 +157,11 @@ GitHubのスターは、プロジェクトの普及度、コミュニティの
 
 ### 2 - 許容できるソリューション
 
-**(solid-i18next)** (`solid-i18next@17.0.2`):
+**(solid-i18next)** (`i18next@26.0.8`):
 
 `solid-i18next` は、JavaScriptアプリのi18nニーズに応えた最初のソリューションの一つであったため、おそらく最も人気のあるオプションです。また、特定の問題を解決するためのコミュニティプラグインも幅広く揃っています。
 
-パッケージは重いです（~14.6kb。これは `solid-intlayer` の約4.7倍です）。
+パッケージは重いです（~14.9kb。これは `solid-intlayer` の約3.5倍です）。
 
 それでも、`t('a.b.c')` 上に構築されたスタックと同じ主要な欠点を共有しています。最適化は可能ですが非常に時間がかかり、大規模なプロジェクトでは悪い習慣（名前空間 + 動的ロード + 型）に陥るリスクがあります。
 
@@ -167,7 +170,7 @@ GitHubのスターは、プロジェクトの普及度、コミュニティの
 Solid primitive は非常に軽量で効率的です。小規模なプロジェクトにはこのソリューションを推奨しますが、クッキー管理、プロキシリダイレクト、フォーマッタなどを含むプロフェッショナルなソリューションには機能が不足しがちです。
 また、ページサイズの最適化のための遅延ロードや名前空間のスコーピングも欠けています。
 
-**(Paraglide)** (`@inlang/paraglide-js@2.17.0`):
+**(Paraglide)** (`@inlang/paraglide-js@2.25.1`):
 
 `Paraglide` は革新的でよく考えられたアプローチを提供しています。それでも、このベンチマークでは、彼らが宣伝しているツリーシェイキングは私の実装では機能しませんでした。ワークフローとDXも他のオプションより複雑です。
 個人的には、プッシュする前に毎回JSファイルを再生成しなければならないのが好きではありません。
@@ -175,7 +178,7 @@ Solid primitive は非常に軽量で効率的です。小規模なプロジェ
 
 ### 3 - 推奨事項
 
-**(Intlayer)** (`solid-intlayer@8.7.12`):
+**(Intlayer)** (`solid-intlayer@9.5.0`):
 
 客観性を保つため、`solid-intlayer` については私自身のソリューションであるため、個人的な評価は控えます。
 

package/docs/ja/benchmark/svelte.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-04-20
-updatedAt: 2026-05-18
+updatedAt: 2026-09-11
 title: 2026年 Svelte向けの最高のi18nソリューション - ベンチマークレポート
 description: svelte-i18n、Paraglide、IntlayerなどのSvelte国際化（i18n）ライブラリを比較します。バンドルサイズ、リーク、反応性に関する詳細なパフォーマンスレポート。
 keywords:
@@ -17,6 +17,9 @@ slugs:
 author: aymericzip
 applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-svelte-template
 history:
+  - version: 9.5.1
+    date: 2026-09-11
+    changes: "ベンチマーク結果を更新"
   - version: 8.9.8
     date: 2026-05-18
     changes: "GitHub スター比較を追加"
@@ -62,9 +65,9 @@ style="border:none;"
 
 ## TL;DR
 
-- **Intlayer**: 最もパフォーマンス効率が高く、フットプリントが最も小さい選択肢（v8.7.12）。
+- **Intlayer**: 最もパフォーマンス効率が高く、フットプリントが最も小さい選択肢（v9.5.0）。
 - **Paraglide**: ツリーシェイキング（tree-shaking）の強力な候補ですが、開発者エクスペリエンスがより複雑で、反応性のオーバーヘッドがあります。
-- **svelte-i18n**: Svelte向けの標準的で機能が充実したソリューションですが、バンドル重量が非常に大きくなります（Intlayerの約7倍）。
+- **svelte-i18n**: Svelte向けの標準的で機能が充実したソリューションですが、バンドル重量が非常に大きくなります（Intlayerの約4.5倍）。
 
 ## アプリをテストする
 
@@ -96,9 +99,9 @@ i18nリークの問題を素早く特定するために、無料のスキャナ
 このベンチマークでは、以下のライブラリを比較しました。
 
 - `Base App` (i18nライブラリなし)
-- `svelte-intlayer` (v8.7.12)
+- `svelte-intlayer` (v9.5.0)
 - `svelte-i18n` (v4.0.1)
-- `@inlang/paraglide-js` (v2.17.0)
+- `@inlang/paraglide-js` (v2.25.1)
 
 フレームワークは `Svelte` で、**10ページ**と**10言語**を持つ多言語アプリを使用しました。
 
@@ -152,7 +155,7 @@ GitHubのスターは、プロジェクトの普及度、コミュニティの
 
 ### 2 - 許容できるソリューション
 
-**(Paraglide)** (`@inlang/paraglide-js@2.17.0`):
+**(Paraglide)** (`@inlang/paraglide-js@2.25.1`):
 
 `Paraglide` は革新的でよく考えられたアプローチを提供しています。Vite + Svelte アプリの文脈では、彼らが宣伝しているツリーシェイキングは期待通りに機能しており、素晴らしいことです。
 しかし、React + TanStack Start の場合、ツリーシェイキングは期待通りに機能せず、Next.jsでも同様でした。とはいえ、Svelte および TanStack Start プロジェクトにおける Paraglide の使用は再確認する価値があるでしょう。
@@ -162,13 +165,13 @@ GitHubのスターは、プロジェクトの普及度、コミュニティの
 
 > paraglideに関する注意：このソリューションはインポートのためにコードベースにコードを注入するため、ベンチマークレポートの「ライブラリサイズ（lib size）」メトリックはほぼ0になります。コード生成は、使用される関数に必要なロジック（接頭辞あり vs 接頭辞なし、クッキー vs ストレージなど）のみが含まれるため、良いことです。比較すると、Intlayer はビルド時に環境変数を注入することでこのフィルタリングを行い、ロジックに応じてコンテンツをツリーシェイクするようにバンドラーに強制します。このおかげで、paraglide と intlayer は i18next や next-intl よりも 6〜10倍軽量なソリューションとなります。
 
-**(svelte-i18n)** (`svelte-i18n@3.4.0`):
+**(svelte-i18n)** (`svelte-i18n@4.0.1`):
 
-このソリューションは、Svelteプロジェクトにおけるi18nのすべてのニーズに応えます。しかし、i18nextや他の主要なi18nソリューションと同様に、少し重いです（~15.9kb。これは `svelte-intlayer` の約7倍です）。
+このソリューションは、Svelteプロジェクトにおけるi18nのすべてのニーズに応えます。しかし、i18nextや他の主要なi18nソリューションと同様に、少し重いです（~16.6kb。これは `svelte-intlayer` の約4.5倍です）。
 
 ### 3 - 推奨事項
 
-**(Intlayer)** (`svelte-intlayer@8.7.12`):
+**(Intlayer)** (`svelte-intlayer@9.5.0`):
 
 客観性を保つため、`svelte-intlayer` については私自身のソリューションであるため、個人的な評価は控えます。
 

package/docs/ja/benchmark/tanstack.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-04-20
-updatedAt: 2026-05-18
+updatedAt: 2026-09-11
 title: 2026年におけるTanStack Startの最適なi18nソリューション - ベンチマークレポート
 description: react-i18next、use-intl、IntlayerなどのTanStack Start国際化ライブラリを比較。バンドルサイズ、リーク、反応性に関する詳細なパフォーマンスレポート。
 keywords:
@@ -17,6 +17,9 @@ slugs:
 author: aymericzip
 applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-tanstack-start-template
 history:
+  - version: 9.5.1
+    date: 2026-09-11
+    changes: "ベンチマーク結果を更新"
   - version: 8.9.8
     date: 2026-05-18
     changes: "GitHub スター比較を追加"
@@ -62,7 +65,7 @@ history:
 
 ## TL;DR
 
-- **Intlayer**: TanStack Startにおいて最高のパフォーマンスと最小のバンドルサイズ（v8.7.12）を提供します。
+- **Intlayer**: TanStack Startにおいて最高のパフォーマンスと最小のバンドルサイズ（v9.5.1）を提供します。
 - **react-i18next** & **use-intl**: 大規模なエコシステムを持つ成熟した代替案ですが、大幅に重く、最適化がより複雑です。
 - **Paraglide**: 革新的なツリーシェイキングのアイデアですが、実際には機能しません。TanStack StartにおいてはDXが複雑で、反応性のオーバーヘッドがあります。
 - **避けるべき**: **General Translation (GT)** と **Lingo.dev**。深刻なパフォーマンスの問題、AIクォータの制限、およびベンダーロックインのためです。
@@ -97,16 +100,18 @@ i18nのリーク問題を素早く特定するために、無料のスキャナ
 このベンチマークでは、以下のライブラリを比較しました。
 
 - `Base App`（i18nライブラリなし）
-- `react-intlayer` (v8.7.12)
-- `react-i18next` (v17.0.2)
-- `use-intl` (v4.9.1)
-- `@lingui/core` (v5.3.0)
+- `react-intlayer` (v9.5.1)
+- `@intlayer/use-intl` (v9.5.1)
+- [`@intlayer/lingui`](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ja/compat/lingui.md) (v9.5.1)
+- `react-i18next` (v17.0.13)
+- `use-intl` (v4.14.2)
+- `@lingui/core` (v6.6.0)
 - `@inlang/paraglide-js` (v2.15.1)
-- `@tolgee/react` (v7.0.0)
-- `react-intl` (v10.1.1)
-- `wuchale` (v0.22.11)
-- `gt-react` (vlatest)
-- `lingo.dev` (v0.133.9)
+- `@tolgee/react` (v7.2.0)
+- `react-intl` (v10.1.26)
+- `wuchale` (v0.26.6)
+- `gt-react` (v10.18.3)
+- `lingo.dev` (v0.138.7)
 
 フレームワークは`TanStack Start`で、**10ページ**と**10言語**を持つ多言語アプリを使用しました。
 
@@ -160,15 +165,15 @@ GitHubのスターは、プロジェクトの普及度、コミュニティの
 
 遭遇した問題：
 
-**(General Translation)** (`gt-react@latest`):
+**(General Translation)** (`gt-react@10.18.3`):
 
-- 約110kbのアプリに対して、`gt-react`は440kb以上の余分なデータを追加することがあります（同ベンチマークのNext.js実装で見られた規模）。
+- 約111kbのアプリに対して、`gt-react`は170kb以上の余分なデータを追加することがあります（同ベンチマークのNext.js実装で見られた規模）。
 - General Translationを使用した最初のビルドで「Quota Exceeded, please upgrade your plan（クォータ超過、プランをアップグレードしてください）」と表示されました。
 - 翻訳がレンダリングされません。`Error: <T> used on the client-side outside of <GTProvider>`というエラーが発生しましたが、これはライブラリのバグのようです。
 - **gt-tanstack-start-react**を実装中、ライブラリの[問題](https://github.com/generaltranslation/gt/issues/1210#event-24510646961)にも遭遇しました。`does not provide an export named 'printAST' - @formatjs/icu-messageformat-parser`というエラーでアプリケーションが壊れました。この問題を報告した後、メンテナは24時間以内に修正しました。
 - これらのライブラリは、`initializeGT()`関数を通じてアンチパターンを使用しており、バンドルがクリーンにツリーシェイキングされるのを妨げています。
 
-**(Lingo.dev)** (`lingo.dev@0.133.9`):
+**(Lingo.dev)** (`lingo.dev@0.138.7`):
 
 - AIのクォータを超過（またはサーバー依存関係のブロック）し、支払いをしない限りビルドやプロダクションへのデプロイがリスクとなります。
 - コンパイラが翻訳コンテンツの約40%を認識していませんでした。動作させるために、すべての`.map`をフラットなコンポーネントブロックに書き換える必要がありました。
@@ -178,7 +183,7 @@ GitHubのスターは、プロジェクトの普及度、コミュニティの
 
 ### 2 - 実験的なソリューション
 
-**(Wuchale)** (`wuchale@0.22.11`):
+**(Wuchale)** (`wuchale@0.26.6`):
 
 `Wuchale`の背後にあるアイデアは興味深いものですが、まだ実用的ではありません。反応性の問題に遭遇し、TanStack Startでアプリを動作させるためにプロバイダーの強制的な再レンダリングが必要でした。ドキュメントもかなり不明瞭で、導入のハードルが高いです。
 
@@ -188,9 +193,9 @@ GitHubのスターは、プロジェクトの普及度、コミュニティの
 
 `Paraglide`は革新的でよく考えられたアプローチを提供しています。それにもかかわらず、このベンチマークでは、Next.jsの実装やTanStack Startにおいて、彼らが宣伝していたツリーシェイキングは機能しませんでした。ワークフローとDXも他の選択肢より複雑です。個人的には、プッシュのたびにJSファイルを再生成しなければならないのが好きではありません。これはPRを通じて常にマージ競合のリスクを生み出します。
 
-> paraglideに関する注意：このソリューションはインポートのためにコードベースにコードを注入するため、ベンチマークレポートの「lib size」メトリクスはほぼ0になります。コード生成は、使用される関数に必要なロジック（すべてのプレフィックス対プレフィックスなし、クッキー対ストレージなど）のみが含まれるため、良いことです。対照的に、Intlayerはビルド時に環境変数を注入してこのフィルタリングを行い、ロケールに応じたコンテンツをバンドラーにツリーシェイクさせます。このおかげで、paraglideとintlayerは、i18nextやnext-intlよりも6〜10倍軽量なソリューションとなります。
+> paraglideに関する注意：このソリューションはインポートのためにコードベースにコードを注入するため、ベンチマークレポートの「lib size」メトリクスはほぼ0になります。コード生成は、使用される関数に必要なロジック（すべてのプレフィックス対プレフィックスなし、クッキー対ストレージなど）のみが含まれるため、良いことです。対照的に、Intlayerはビルド時に環境変数を注入してこのフィルタリングを行い、ロケールに応じたコンテンツをバンドラーにツリーシェイクさせます。このおかげで、paraglideとintlayerは、i18nextやnext-intlよりも3〜10倍軽量なソリューションとなります。
 
-**(Tolgee)** (`@tolgee/react@7.0.0`):
+**(Tolgee)** (`@tolgee/react@7.2.0`):
 
 `Tolgee`は前述の問題の多くに対処しています。しかし、同様のアプローチを持つ他のツールよりも導入が難しいと感じました。型安全性が提供されていないため、コンパイル時に紛失したキーを見つけることが非常に困難です。キーの不備を検出するために、TolgeeのAPIを自前のAPIでラップする必要がありました。
 
@@ -198,37 +203,37 @@ TanStack Startでは反応性の問題もありました。ロケール変更時
 
 TanStack Start でも反応性の問題がありました。ロケール変更時にプロバイダーを強制的に再レンダリングし、locale-change イベントをサブスクライブして、別の言語での読み込みが正しく動作するようにする必要がありました。
 
-**(use-intl)** (`use-intl@4.9.1`):
+**(use-intl)** (`use-intl@4.14.2`):
 
 `use-intl`は、Reactエコシステムにおける最もファッショナブルな「intl」の一部であり（`next-intl`と同じファミリー）、AIエージェントによって頻繁に推奨されますが、パフォーマンス重視の設定においては間違いであるというのが私の見解です。導入は比較的簡単です。しかし実際には、リークを最適化し制限するプロセスは非常に複雑です。同様に、動的ロード、ネームスぺーシング、TypeScriptの型を組み合わせると、開発が著しく遅くなります。
 
 TanStack Startでは、Next.js特有の罠（`setRequestLocale`、静的レンダリング）は回避できますが、根本的な問題は同じです。厳格な規律がなければ、バンドルはすぐに大量のメッセージを抱え込み、ルートごとのネームスペースの維持は苦痛になります。
 
-**(react-i18next)** (`react-i18next@17.0.2`):
+**(react-i18next)** (`react-i18next@17.0.13`):
 
 `react-i18next`は、JavaScriptアプリのi18nニーズに応えた初期のソリューションの一つであったため、おそらく最も人気のある選択肢です。特定の課題に対するコミュニティプラグインも豊富です。
 
 それでも、`t('a.b.c')`上に構築されたスタックと同じ大きな欠点を共有しています。最適化は可能ですが非常に時間がかかり、大規模プロジェクトでは悪い習慣（ネームスペース、動的ロード、型）に陥るリスクがあります。
 
-このパッケージは特に重い (~17.3kb、これは `react-intlayer` の約 3.5 倍)。
+このパッケージは特に重い (~18.4kb、これは `react-intlayer` の約 3.5 倍)。
 
 メッセージ形式も異なります。`use-intl`はICU MessageFormatを使用しますが、`i18next`は独自の形式を使用しており、これらを混ぜるとツールや移行が複雑になります。
 
-**(Lingui)** (`@lingui/core@5.3.0`):
+**(Lingui)** (`@lingui/core@6.6.0`):
 
 `Lingui`はしばしば賞賛されます。個人的には、`lingui extract` / `lingui compile`を巡るワークフローが他のアプローチよりも複雑で、このTanStack Startベンチマークにおいて明確な利点が見出せませんでした。また、AIを混乱させる一貫性のない構文（例：`t()`、`t''`、`i18n.t()`、`<Trans>`）も見受けられました。
 
-**(react-intl)** (`react-intl@10.1.1`):
+**(react-intl)** (`react-intl@10.1.26`):
 
 `react-intl`は、Format.jsチームによるパフォーマンス重視の実装です。DXは冗長なままです。`const intl = useIntl()` + `intl.formatMessage({ id: "xx.xx" })`は複雑さを増し、JavaScriptの余分な作業を増やし、グローバルなi18nインスタンスをReactツリーの多くのノードに結びつけます。
 
-このパッケージは重い（~14.4kb で、`react-intlayer` の約 3 倍）です。
+このパッケージは重い（~15.3kb で、`react-intlayer` の約 3 倍）です。
 
 ### 4 - 推奨事項
 
 このTanStack Startベンチマークには、`next-translate`（Next.jsプラグイン + `getStaticProps`）に直接相当するものはありません。成熟したエコシステムと`t()` APIを切望するチームにとって、`react-i18next`や`use-intl`は「妥当な」選択肢であり続けますが、リークを回避するための最適化には多くの時間を投資することを覚悟してください。
 
-**(Intlayer)** (`react-intlayer@8.7.12`):
+**(Intlayer)** (`react-intlayer@9.5.1`):
 
 客観性を保つため、自分自身のソリューションである`react-intlayer`については個人的な判断を控えさせていただきます。
 

package/docs/ja/benchmark/vue.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2026-04-20
-updatedAt: 2026-05-18
+updatedAt: 2026-09-11
 title: 2026年 Vue向けの最高のi18nソリューション - ベンチマークレポート
 description: vue-i18n、fluent-vue、IntlayerなどのVue国際化（i18n）ライブラリを比較します。バンドルサイズ、リーク、反応性に関する詳細なパフォーマンスレポート。
 keywords:
@@ -17,6 +17,9 @@ slugs:
 author: aymericzip
 applicationTemplate: https://github.com/intlayer-org/benchmark-i18n-vue-template
 history:
+  - version: 9.5.1
+    date: 2026-09-11
+    changes: "ベンチマーク結果を更新"
   - version: 8.9.8
     date: 2026-05-18
     changes: "GitHub スター比較を追加"
@@ -62,7 +65,7 @@ style="border:none;"
 
 ## TL;DR
 
-- **Intlayer**: スコーピング（scoping）と動的ロードを内蔵した、最も軽量なソリューション（v8.7.12）。
+- **Intlayer**: スコーピング（scoping）と動的ロードを内蔵した、最も軽量なソリューション（v9.5.0）。
 - **vue-i18n**: 豊かなエコシステムを持つ業界標準ですが、非常に重くなる可能性があり、大規模アプリケーションでのコード分割の最適化が難しい場合があります。
 - **fluent-vue**: 革新的なメッセージ構成ですが、型安全性が欠けており、非常に重いソリューションです。
 
@@ -96,7 +99,8 @@ i18nリークの問題を素早く特定するために、無料のスキャナ
 このベンチマークでは、以下のライブラリを比較しました。
 
 - `Base App` (i18nライブラリなし)
-- `vue-intlayer` (v8.7.12)
+- `vue-intlayer` (v9.5.0)
+- [`@intlayer/vue-i18n`](https://github.com/aymericzip/intlayer/blob/main/docs/docs/ja/compat/vue-i18n.md) (v9.5.1)
 - `vue-i18n` (v11.4.0)
 - `fluent-vue` (v3.8.2)
 
@@ -156,14 +160,14 @@ GitHubのスターは、プロジェクトの普及度、コミュニティの
 
 - **vue-i18n** は間違いなくVueで最も使用されているi18nライブラリであり、多くの機能と巨大なエコシステムを持っています。しかし、内部的にはかなり重いソリューションです。メッセージの遅延ロードを統合していても、スコーピング（scoping）機能が欠けています。標準的なVue SPAアプリの場合は問題ありませんが、@nuxt/i18nを使用するNuxtアプリの場合、すべてのページのメッセージが単一のページに含まれてしまうことになります。10ページを超える大規模なNuxtアプリでは、これが深刻な問題になる可能性があります。
 
-パッケージは非常に重いです（~24.3kb。これは `vue-intlayer` の約9倍です）。
+パッケージは非常に重いです（~24.3kb。これは `vue-intlayer` の約6倍です）。
 
-**(fluent-vue)** (`fluent-vue@0.5.0`):
+**(fluent-vue)** (`fluent-vue@3.8.2`):
 
-- **fluent-vue** は .ftl 形式を通じて革新を試みています。メッセージの構成は素晴らしく、始めやすいです。しかし実際には、型安全性の欠如によりエラーのリスクが高まり、デバッグに時間がかかる可能性があります。さらに、このソリューションはViteプラグインを使用してメッセージをロードしますが、これによりすべての言語の全コンテンツが各ページに強制的にロードされます。加えて、これは極めて重いソリューションです（~92.7kb。これは `vue-intlayer` の約34倍です）。
+- **fluent-vue** は .ftl 形式を通じて革新を試みています。メッセージの構成は素晴らしく、始めやすいです。しかし実際には、型安全性の欠如によりエラーのリスクが高まり、デバッグに時間がかかる可能性があります。さらに、このソリューションはViteプラグインを使用してメッセージをロードしますが、これによりすべての言語の全コンテンツが各ページに強制的にロードされます。加えて、これは極めて重いソリューションです（~29.7kb。これは `vue-intlayer` の約7.5倍です）。
 
 ### 3 - 推奨事項
 
-**(Intlayer)** (`vue-intlayer@8.7.12`):
+**(Intlayer)** (`vue-intlayer@9.5.0`):
 
 客観性を保つため、`vue-intlayer` については私自身のソリューションであるため、個人的な評価は控えます。

package/docs/ja/cli/build.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-11
-updatedAt: 2025-11-22
+updatedAt: 2026-09-12
 title: 辞書のビルド
 description: コンテンツ宣言ファイルからIntlayerの辞書をビルドする方法を学びます。
 keywords:
@@ -14,6 +14,9 @@ slugs:
   - cli
   - build
 history:
+  - version: 9.5.2
+    date: 2026-09-12
+    changes: "`--ci` フラグを追加"
   - version: 8.1.5
     date: 2026-02-23
     changes: "checkTypesオプションを追加"
@@ -92,6 +95,10 @@ bun x intlayer build --watch
 
   > 例: `npx intlayer build --no-cache`
 
+- **`--ci`**: モノレポ内のすべての Intlayer プロジェクトでコマンドを実行します（プロジェクトディレクトリ内から実行した場合はそのプロジェクトのみ）。プロジェクトごとの資格情報は、プロジェクトパスを `{ "clientId", "clientSecret" }` に対応付ける JSON オブジェクト `INTLAYER_PROJECT_CREDENTIALS` から挿入できます。
+
+  > 例: `npx intlayer build --ci`
+
 - **`--check-types`**: コンテンツ宣言ファイルの型をチェックします。
 
   > 例: `npx intlayer build --check-types`

package/docs/ja/cli/configuration.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-11
-updatedAt: 2025-11-22
+updatedAt: 2026-09-12
 title: 設定の管理
 description: Intlayerの設定をCMSに取得およびプッシュする方法を学びます。
 keywords:
@@ -51,6 +51,7 @@ bun x intlayer configuration get
 - **`--base-dir`**: プロジェクトのベースディレクトリを指定します。
 - **`--verbose`**: デバッグのために詳細なログ出力を有効にします。（CLIではデフォルトでtrue）
 - **`--no-cache`**: キャッシュを無効にします。
+- **`--ci`**: モノレポ内のすべての Intlayer プロジェクトでコマンドを実行します（プロジェクトディレクトリ内から実行した場合はそのプロジェクトのみ）。プロジェクトごとの資格情報は、プロジェクトパスを `{ "clientId", "clientSecret" }` に対応付ける JSON オブジェクト `INTLAYER_PROJECT_CREDENTIALS` から挿入できます。
 
 ## 設定のプッシュ
 
@@ -84,5 +85,6 @@ bun x intlayer configuration push
 - **`--base-dir`**: プロジェクトのベースディレクトリを指定します。
 - **`--verbose`**: デバッグのために詳細なログ出力を有効にします。（CLIではデフォルトでtrue）
 - **`--no-cache`**: キャッシュを無効にします。
+- **`--ci`**: モノレポ内のすべての Intlayer プロジェクトでコマンドを実行します（プロジェクトディレクトリ内から実行した場合はそのプロジェクトのみ）。プロジェクトごとの資格情報は、プロジェクトパスを `{ "clientId", "clientSecret" }` に対応付ける JSON オブジェクト `INTLAYER_PROJECT_CREDENTIALS` から挿入できます。
 
 設定をプッシュすることで、プロジェクトはIntlayer CMSと完全に統合され、チーム間での辞書管理がシームレスに行えるようになります。

package/docs/ja/cli/doc-review.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-11
-updatedAt: 2026-06-17
+updatedAt: 2026-09-12
 title: ドキュメントのレビュー
 description: 異なるロケール間での品質、一貫性、完全性を確認するためのドキュメントファイルのレビュー方法を学びます。
 keywords:
@@ -16,6 +16,9 @@ slugs:
   - cli
   - doc-review
 history:
+  - version: 9.5.2
+    date: 2026-09-12
+    changes: "`--ci` フラグを追加"
   - version: 9.0.0
     date: 2026-06-17
     changes: "--log オプションを追加"
@@ -138,6 +141,10 @@ bun x intlayer doc review
 
   > 例: `npx intlayer doc review --base-dir ./docs --env-file .env.production.local`
 
+- **`--ci`**: モノレポ内のすべての Intlayer プロジェクトでコマンドを実行します（プロジェクトディレクトリ内から実行した場合はそのプロジェクトのみ）。プロジェクトごとの資格情報は、プロジェクトパスを `{ "clientId", "clientSecret" }` に対応付ける JSON オブジェクト `INTLAYER_PROJECT_CREDENTIALS` から挿入できます。
+
+  > 例: `npx intlayer doc review --ci`
+
 **ログオプション:**
 
 - **`--verbose`**: デバッグのために詳細なログを有効にします。（CLIではデフォルトでtrue）

package/docs/ja/cli/doc-translate.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-11
-updatedAt: 2025-11-22
+updatedAt: 2026-09-12
 title: ドキュメントの翻訳
 description: AI翻訳サービスを使用してドキュメントファイルを自動的に翻訳する方法を学びます。
 keywords:
@@ -113,6 +113,10 @@ bun x intlayer doc translate
 
   > 例: `npx intlayer doc translate --base-dir ./docs --env-file .env.production.local`
 
+- **`--ci`**: モノレポ内のすべての Intlayer プロジェクトでコマンドを実行します（プロジェクトディレクトリ内から実行した場合はそのプロジェクトのみ）。プロジェクトごとの資格情報は、プロジェクトパスを `{ "clientId", "clientSecret" }` に対応付ける JSON オブジェクト `INTLAYER_PROJECT_CREDENTIALS` から挿入できます。
+
+  > 例: `npx intlayer doc translate --ci`
+
 **ログオプション:**
 
 - **`--verbose`**: デバッグのために詳細なログを有効にします。（CLIではデフォルトでtrue）

package/docs/ja/cli/extract.md

@@ -1,6 +1,6 @@
 ---
 createdAt: 2024-08-11
-updatedAt: 2025-11-22
+updatedAt: 2026-09-12
 title: 文字列の抽出
 description: コンポーネントの近くに .content ファイルを作成して、コンポーネントから文字列を抽出する方法を学びます。
 keywords:
@@ -69,6 +69,7 @@ bun x intlayer extract
 - **`--env`**: 環境を指定します。
 - **`--env-file`**: カスタムの環境ファイルを指定します。
 - **`--verbose`**: 詳細なログ出力を有効にします。
+- **`--ci`**: モノレポ内のすべての Intlayer プロジェクトでコマンドを実行します（プロジェクトディレクトリ内から実行した場合はそのプロジェクトのみ）。プロジェクトごとの資格情報は、プロジェクトパスを `{ "clientId", "clientSecret" }` に対応付ける JSON オブジェクト `INTLAYER_PROJECT_CREDENTIALS` から挿入できます。
 
 **必須プラグイン:**