diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/get-started/tutorial.md b/i18n/ja/docusaurus-plugin-content-docs/current/get-started/tutorial.md
index 46ef4b4e92..8c18e275f1 100644
--- a/i18n/ja/docusaurus-plugin-content-docs/current/get-started/tutorial.md
+++ b/i18n/ja/docusaurus-plugin-content-docs/current/get-started/tutorial.md
@@ -39,7 +39,7 @@ sidebar_position: 2
 
 Feature-Sliced Designの特徴は、ページが互いに依存できないことです。つまり、1つのページが他のページのコードをインポートすることはできません。これは**層のインポートルール**によって禁じられています。
 
-*スライス内のモジュールは、下層にあるスライスのみをインポートできる。*
+*スライス内のモジュール（ファイル）は、下層にあるスライスのみをインポートできる。*
 
 この場合、ページはスライスであるため、そのページ内のモジュール（ファイル）は、他のページではなく、下層からのみコードをインポートできます。
 
diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/guides/examples/auth.md b/i18n/ja/docusaurus-plugin-content-docs/current/guides/examples/auth.md
index 264a970c26..a35f108866 100644
--- a/i18n/ja/docusaurus-plugin-content-docs/current/guides/examples/auth.md
+++ b/i18n/ja/docusaurus-plugin-content-docs/current/guides/examples/auth.md
@@ -192,7 +192,7 @@ FSDプロジェクトには、ユーザーエンティティや現在のユー
 
 APIクライアントは通常、`shared/api`に配置されるか、エンティティ間で分散されるため、このアプローチの主な問題は、他のリクエストがトークンにアクセスできるようにしつつ、[レイヤーのインポートルール][import-rule-on-layers]を破らないことです。
 
-> スライス内のモジュールは、下層にあるスライスのみをインポートできる。
+> スライス内のモジュール（ファイル）は、下層にあるスライスのみをインポートできる。
 
 この問題にはいくつかの解決策があります。
 
diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/guides/migration/from-custom.md b/i18n/ja/docusaurus-plugin-content-docs/current/guides/migration/from-custom.md
index 94b6a2e3bb..c0a0f2e9e2 100644
--- a/i18n/ja/docusaurus-plugin-content-docs/current/guides/migration/from-custom.md
+++ b/i18n/ja/docusaurus-plugin-content-docs/current/guides/migration/from-custom.md
@@ -1,5 +1,5 @@
 ---
-sidebar_position: 3
+sidebar_position: 1
 sidebar_label: カスタムアーキテクチャからの移行
 ---
 
diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/guides/migration/from-v1.md b/i18n/ja/docusaurus-plugin-content-docs/current/guides/migration/from-v1.md
index d6003f47d2..282faaecdc 100644
--- a/i18n/ja/docusaurus-plugin-content-docs/current/guides/migration/from-v1.md
+++ b/i18n/ja/docusaurus-plugin-content-docs/current/guides/migration/from-v1.md
@@ -1,8 +1,8 @@
 ---
-sidebar_position: 4
+sidebar_position: 2
 ---
 
-# v1からの移行
+# v1からv2への移行
 
 ## なぜv2なのか？ {#why-v2}
 
diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/guides/migration/from-v2-0.md b/i18n/ja/docusaurus-plugin-content-docs/current/guides/migration/from-v2-0.md
new file mode 100644
index 0000000000..a29c7f7d2f
--- /dev/null
+++ b/i18n/ja/docusaurus-plugin-content-docs/current/guides/migration/from-v2-0.md
@@ -0,0 +1,45 @@
+---
+sidebar_position: 3
+---
+
+# v2.0からv2.1への移行
+
+v2.1の主な変更点は、インターフェースを分解するための「ページファースト」という新しいメンタルモデルです。
+
+v2.0では、FSDは分解のためにエンティティ表現やインタラクティビティの最小部分まで考慮し、インターフェース内のエンティティとフィーチャーを特定することを推奨していました。そうしてから、エンティティとフィーチャーからウィジェットやページが構築されていきました。この分解モデルでは、ほとんどのロジックはエンティティとフィーチャーにあり、ページはそれ自体にはあまり重要性のない構成層に過ぎませんでした。
+
+v2.1では、分解をページから始めること、または場合によってはページで止めることを推奨します。ほとんどの人はすでにアプリを個々のページに分ける方法を知っており、ページはコードベース内のコンポーネントを見つける際の一般的な出発点でもあります。この新しい分解モデルでは、各個別のページにほとんどのUIとロジックを保持し、Sharedに再利用可能な基盤を維持します。複数のページでビジネスロジックを再利用する必要が生じた場合は、それを下層のレイヤーに移動できます。
+
+Feature-Sliced Designへのもう一つの追加は、`@x`表記を使用したエンティティ間のクロスインポートの標準化です。
+
+## 移行方法 {#how-to-migrate}
+
+v2.1には破壊的な変更はなく、FSD v2.0で書かれたプロジェクトもFSD v2.1の有効なプロジェクトです。しかし、新しいメンタルモデルがチームや特に新しい開発者のオンボーディングにとってより有益であると考えているため、分解に対して小さな調整を行うことを推奨します。
+
+### スライスのマージ
+
+移行を始めるための簡単な方法は、プロジェクトでFSDのリンターである[Steiger][steiger]を実行することです。Steigerは新しいメンタルモデルで構築されており、最も役立つルールは次のとおりです。
+
+- [`insignificant-slice`][insignificant-slice] — エンティティ、またはフィーチャーが1ページでのみ使用されている場合、このルールはそのエンティティ、またはフィーチャーをページに完全にマージすることを提案します。
+- [`excessive-slicing`][excessive-slicing] — レイヤーにスライスが多すぎる場合、通常は分解が細かすぎるサインです。このルールは、プロジェクトのナビゲーションを助けるためにいくつかのスライスをマージ、またはグループ化することを提案します。
+
+```bash
+npx steiger src
+```
+
+これにより、1回だけ使用されるスライスを特定できるため、それらが本当に必要か再考することができます。そのような考慮において、レイヤーはその内部のすべてのスライスのための何らかのグローバル名前空間を形成することを念頭に置いてください。1回だけ使用される変数でグローバル名前空間を汚染しないようにするのと同様に、レイヤーの名前空間内の場所を貴重なものとして扱い、慎重に使用するべきです。
+
+### クロスインポートの標準化
+
+以前にプロジェクト内でクロスインポートがあった場合、Feature-Sliced Designでのクロスインポートのための新しい表記法`@x`を活用できます。これは次のようになります。
+
+```ts title="entities/B/some/file.ts"
+import type { EntityA } from "entities/A/@x/B";
+```
+
+詳細については、リファレンスの[クロスインポートの公開API][public-api-for-cross-imports]セクションを参照してください。
+
+[insignificant-slice]: https://github.com/feature-sliced/steiger/tree/master/packages/steiger-plugin-fsd/src/insignificant-slice
+[steiger]: https://github.com/feature-sliced/steiger
+[excessive-slicing]: https://github.com/feature-sliced/steiger/tree/master/packages/steiger-plugin-fsd/src/excessive-slicing
+[public-api-for-cross-imports]: /docs/reference/public-api#public-api-for-cross-imports
diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/guides/tech/with-nuxtjs.mdx b/i18n/ja/docusaurus-plugin-content-docs/current/guides/tech/with-nuxtjs.mdx
index a0b7de7e16..f3ec6eacb1 100644
--- a/i18n/ja/docusaurus-plugin-content-docs/current/guides/tech/with-nuxtjs.mdx
+++ b/i18n/ja/docusaurus-plugin-content-docs/current/guides/tech/with-nuxtjs.mdx
@@ -111,7 +111,7 @@ export default defineNuxtConfig({
 例えば、プロジェクトに`Home`ページを追加するには、次の手順を行います。
 - `pages`層内にページスライスを追加する
 - `app`層内に適切なルートを追加する
-- スライスのページとルートを統合する
+- スライスのページをルートに接続する
 
 ページスライスを作成するには、[CLI](https://github.com/feature-sliced/cli)を使用します。
 ```shell
diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/guides/tech/with-sveltekit.mdx b/i18n/ja/docusaurus-plugin-content-docs/current/guides/tech/with-sveltekit.mdx
index c7b450db92..17460fac88 100644
--- a/i18n/ja/docusaurus-plugin-content-docs/current/guides/tech/with-sveltekit.mdx
+++ b/i18n/ja/docusaurus-plugin-content-docs/current/guides/tech/with-sveltekit.mdx
@@ -62,7 +62,7 @@ fsd pages home
 `ui`セグメント内に`home-page.svelte`ファイルを作成し、公開APIを介してアクセスできるようにします。　
 
 ```ts title="src/pages/home/index.ts"
-export { default as HomePage } from './ui/home-page';
+export { default as HomePage } from './ui/home-page.svelte';
 ```
 
 このページのルートを`app`層内に作成します。
@@ -81,7 +81,7 @@ export { default as HomePage } from './ui/home-page';
 │   │   │   ├── index.ts
 ```
 
-最後に`index.svelte`ファイル内にページコンポーネントを追加します。
+最後に`+page.svelte`ファイル内にページコンポーネントを追加します。
 
 ```html title="src/app/routes/+page.svelte"
 <script>
diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/reference/index.mdx b/i18n/ja/docusaurus-plugin-content-docs/current/reference/index.mdx
index 577abbd725..c5b2c63852 100644
--- a/i18n/ja/docusaurus-plugin-content-docs/current/reference/index.mdx
+++ b/i18n/ja/docusaurus-plugin-content-docs/current/reference/index.mdx
@@ -26,7 +26,7 @@ FSDの重要な概念に関するセクション
 />
 <NavCard
     title="公開API" 
-    description="堅牢で統合しやすいモジュール設計に関する実践"
+    description="公開APIの定義と目標、@xによるクロスインポート、トラブルシューティング"
     to="/docs/reference/public-api"
     Icon={ApiOutlined}
 />
diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/reference/isolation/_category_.yaml b/i18n/ja/docusaurus-plugin-content-docs/current/reference/isolation/_category_.yaml
deleted file mode 100644
index b6ec783a3f..0000000000
--- a/i18n/ja/docusaurus-plugin-content-docs/current/reference/isolation/_category_.yaml
+++ /dev/null
@@ -1 +0,0 @@
-label: 分離
diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/reference/isolation/coupling-cohesion.md b/i18n/ja/docusaurus-plugin-content-docs/current/reference/isolation/coupling-cohesion.md
deleted file mode 100644
index ff23863bcd..0000000000
--- a/i18n/ja/docusaurus-plugin-content-docs/current/reference/isolation/coupling-cohesion.md
+++ /dev/null
@@ -1,146 +0,0 @@
----
-sidebar_position: 1
----
-
-# 低結合と高凝集
-
-アプリケーションのモジュールは、**強い結合性**（明確なタスクを解決することに焦点を当てる）と**弱い結合性**（他のモジュールからできるだけ依存しない）を持つように設計されるべきです。
-
-<figure>
-    <img src="/img/coupling-cohesion-light.svg#light-mode-only" alt="" />
-    <img src="/img/coupling-cohesion-dark.svg#dark-mode-only" alt="" />
-    <figcaption>
-        インスパイア先: https://enterprisecraftsmanship.com/posts/cohesion-coupling-difference/
-    </figcaption>
-</figure>
-
-FSDでは、以下の方法で達成されます。
-
-* アプリケーションを層とスライスに分割する - 特定の機能を実現するモジュール。
-* 各モジュールには、[公開API][refs-public-api]を提供することが求められます。
-* モジュール間の相互作用に特別な制限を設ける - 各モジュールは「下位」のモジュールにのみ依存でき、同じ層またはそれ以上の層のモジュールには依存できません。
-
-## コンポーネントの構成（UIレベル） {#components-composition-ui-level}
-
-ほとんどの現代のUIフレームワークやライブラリは、各コンポーネントが独自のプロパティ、状態、子コンポーネントを持つことができるコンポーネントモデルを提供しています。
-
-このモデルにより、**直接的に関連しないさまざまなコンポーネントの構成**としてインターフェースを構築し、**コンポーネントの弱い結合性**を達成することができます。
-
-### 例 {#example}
-
-**ヘッダー付きリスト**の例を考えてみましょう。
-
-#### 拡張性を考慮する {#laying-the-extensibility}
-
-リストコンポーネントは、ヘッダーとリストアイテムの構造を自ら定義せず、代わりにそれらをパラメータとして受け取ります。
-
-```tsx
-interface ListProps {
-    Header: React.ReactNode;
-    Items: React.ReactNode;
-}
-
-const List: Component<ListProps> = ({ Header, Items }) => (
-    <div class="wrapper">
-        {Header}
-        <ul class="...">
-            {Items}
-        </ul>
-    </div>
-)
-```
-
-#### 構成を使用する {#using-the-composition}
-
-これにより、**異なるバージョンのヘッダーやリストアイテムのコンポーネントを再利用し、独立して変更する**ことが可能になります。ヘッダーとリストアイテムのコンポーネントは、それぞれ独自のローカル状態やアプリケーションの共通状態の任意の部分へのバインディングを持つことができ、リストコンポーネントはそれについて何も知らず、したがってそれに依存しません。
-
-```tsx
-<List Header={<FancyHeader />} Items={<ToDoItems />} />
-
-<List Items={<CartItems />} />
-
-<List Header={<FancyHeaderV2 color="red" />} Items={<FancyItems />} />
-```
-
-## 層の構成（アプリレベル） {#layer-composition-app-level}
-
-FSDは、ユーザーにとって価値のある機能を個別のモジュール - **フィーチャー（features）** - に分割し、ビジネスエンティティに関連するロジックを**エンティティ（entities）**に分けることを提案します。フィーチャーとエンティティは、**高い結合性を持つモジュール**として設計されるべきであり、すなわち**特定のタスクを解決することに焦点を当てる**か、**特定のエンティティの周りに集中する**べきです。
-
-これらのモジュール間のすべての相互作用は、上記のUIコンポーネントの例と同様に、**さまざまなモジュールの構成**として整理されるべきです。
-
-### 例 {#example}
-
-チャットアプリケーションの例を考えてみましょう。
-
-* 連絡先リストを開いて友達を選択できる
-* 選択した友達とのチャットを開くことができる
-
-FSDに基づいて、次のように表現できます。
-
-エンティティ
-
-* ユーザー（ユーザーの状態を含む）
-* 連絡先（連絡先リストの状態、特定の連絡先を操作するためのツール）
-* チャット（現在のチャットの状態とその操作）
-
-フィーチャー
-
-* メッセージ送信フォーム
-* チャット選択メニュー
-
-#### すべてを結びつける {#lets-tie-it-all-together}
-
-アプリケーションには、最初に1つのページがあり、インターフェースは最初の例の少し修正されたコンポーネントに基づいています。
-
-```tsx title="page/main/ui.tsx"
-<List
-    Header={<ConversationSwitch />}
-    Items={<Messages />}
-    Footer={<MessageInput />}
-/>
-```
-
-#### データモデル {#data-model}
-
-ページのデータモデルは、**フィーチャーとエンティティの構成**として整理されます。この例では、フィーチャーはファクトリーとして実装され、これらのファクトリーのパラメータを介してエンティティのインターフェースにアクセスします。
-
-> ただし、ファクトリーとしての実装は必須ではなく、フィーチャーは下位層に依存し、直接的にアクセスすることもできます。
-
-```ts title="pages/main/model.ts"
-import { userModel } from "entitites/user"
-import { conversationModel } from "entities/conversation"
-import { contactModel } from "entities/contact"
-
-import { createMessageInput } from "features/message-input"
-import { createConversationSwitch } from "features/conversation-switch"
-
-import { beautifiy } from "shared/lib/beautify-text"
-
-export const { allConversations, setConversation } = createConversationSwitch({
-    contacts: contactModel.allContacts,
-    setConversation: conversationModel.setConversation,
-    currentConversation: conversationModel.conversation,
-    currentUser: userModel.currentUser
-})
-
-export const { sendMessage, attachFile } = createMessageInput({
-    author: userModel.currentUser,
-    send: conversationModel.sendMessage,
-    formatMessage: beautify
-})
-```
-
-## まとめ {#summary}
-
-1. モジュールは**強い結合性**を持つべきであり（1つの責任を持ち、特定のタスクを解決する）、[**公開API**][refs-public-api]を提供する必要があります。
-2. **弱い結合性**は、UIコンポーネント、フィーチャー、エンティティの要素の構成を通じて達成されます。
-3. また、結合性を低下させるために、モジュールは**公開APIを介してのみ互いに依存するべきです** - これにより、モジュールは互いの内部実装から独立します。
-
-## 参照 {#see-also}
-
-* [(記事) 低結合と高凝集についての視覚的説明](https://enterprisecraftsmanship.com/posts/cohesion-coupling-difference/)
-  * *最初の図はこの論文からインスパイアを受けています*
-* [(記事) 低結合と高凝集。デメトリの法則](https://medium.com/german-gorelkin/low-coupling-high-cohesion-d36369fb1be9)
-* [(プレゼンテーション) 設計原則について（低結合と高凝集を含む）](https://www.slideshare.net/cristalngo/software-design-principles-57388843)
-
-[refs-public-api]: /docs/reference/public-api
diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/reference/isolation/decouple-entities.mdx b/i18n/ja/docusaurus-plugin-content-docs/current/reference/isolation/decouple-entities.mdx
deleted file mode 100644
index e4162bdd1e..0000000000
--- a/i18n/ja/docusaurus-plugin-content-docs/current/reference/isolation/decouple-entities.mdx
+++ /dev/null
@@ -1,21 +0,0 @@
----
-sidebar_position: 2
-sidebar_class_name: sidebar-item--wip
----
-
-import WIP from '@site/src/shared/ui/wip/tmpl.mdx'
-
-# エンティティの分離
-
-<WIP ticket="202" />
-
-> タイプのクロスインポート、アダプター、エンティティ間の明示的な関係の構築について
-
-> また、神話的な完全に分離されたエンティティについても
-
-## 参照 {#see-also}
-
-- [(スレッド) エンティティの分解と明示的な関係の構築に関するメモ](https://t.me/feature_sliced/3633)
-- [(スレッド) 「関連するエンティティ」（ユーザー/ペット/友人）の分解の例](https://t.me/feature_sliced/3316)
-- [(スレッド) エンティティにおけるタイプ/アダプターのクロスインポートについて](https://t.me/feature_sliced/4276)
-- [(スレッド) エンティティと機能の境界について](https://t.me/feature_sliced/4521)
\ No newline at end of file
diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/reference/isolation/index.md b/i18n/ja/docusaurus-plugin-content-docs/current/reference/isolation/index.md
deleted file mode 100644
index cb6c499f85..0000000000
--- a/i18n/ja/docusaurus-plugin-content-docs/current/reference/isolation/index.md
+++ /dev/null
@@ -1,61 +0,0 @@
-# モジュールの分離
-
-FSDの枠組みの中で、すべてのモジュールは責任の領域（レイヤー、スライス、セグメント）に分配されています。
-
-レイヤーは縦に組織されています。
-
-- "下層"には再利用可能なモジュール（ui-kit、プロジェクトの内部ライブラリ）があり、最も抽象的です。
-- "上層"に進むにつれて、より特定的なモジュールが配置されます。
-
-どのスライスに属していても、各モジュールは[**公開アクセスインターフェースを提供する義務があります**][refs-public-api]。
-
-## 要件 {#requirements}
-
-各モジュールが他のアプリケーションと相互作用する際には、いくつかの要件を考慮して設計されます。
-
-1. **他のモジュールとの弱い結合**
-    - *1つのモジュールの変更は、他のモジュールに対して弱く予測可能な影響を与えるべきです。*
-1. **高い結合性** - 各モジュールの責任は「1つのタスク」に焦点を当てています。
-    - *モジュールがあまりにも多くの責任を持つ場合（「やりすぎる」場合）、それはできるだけ早く認識されるべきです。*
-1. **アプリケーション全体での循環依存の不在**
-    - *これはしばしば予期しない望ましくない動作を引き起こすため、完全に避けるべきです。*
-
-## ルール {#rule}
-
-これらの要件を満たすために、方法論の枠組みの中で基本的なルールを守る必要があります。
-
-:::info 重要
-
-モジュールは「下層」のモジュールにのみ依存でき、同じ層またはそれ以上の層のモジュールには依存できません。
-
-:::
-
-- `features/auth` **は** `features/filters` **に依存できません** **し、逆も同様です。**
-- `features/auth` **は** `shared/ui/button` **に依存できますが、逆はできません。**
-
-このルールに従うことで、依存関係を**「一方向」に保つ**ことができ、これにより**循環インポートを自動的に排除し**、モジュール間の依存関係の追跡を大幅に**簡素化**します。
-
-## 問題の特定 {#identifying-problems}
-
-<!-- 
-TODO 方法論の経験を積んだ後、このセクションをより詳細にする
--->
-このルールの違反は問題の信号です。
-
-1. モジュールが自層の他のモジュールから**インポートを持つ**
-    - モジュールが**過剰に細分化されている**か、**余分な責任を持っている**可能性があります。
-    - インポートされたモジュールと**統合する**か、**部分的または完全に下層に移動する**か、上層のモジュールに依存関係のロジックを移動する必要があります。
-1. モジュールが自層の多くのモジュールから**インポートされる**
-    - モジュールが**余分な責任を持っている**可能性があります。
-    - **部分的または完全に下層に移動する**か、上層のモジュールに依存関係のロジックを移動する必要があります。
-1. モジュールが自層の多くのモジュールから**インポートを持つ**
-    - モジュールが**別の責任領域に属している**可能性があります。
-    - **部分的または完全に上層に移動する**必要があります。
-
-## 参照 {#see-also}
-
-- [(ディスカッション) 方法論におけるエンティティとその結合性](https://github.com/feature-sliced/documentation/discussions/49)
-- [(ディスカッション) クロスインポートと依存関係の分析について](https://github.com/feature-sliced/documentation/discussions/65#discussioncomment-480822)
-- [パターン **GRASP**](https://ru.wikipedia.org/wiki/GRASP)
-
-[refs-public-api]: /docs/reference/public-api
diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/reference/layers.mdx b/i18n/ja/docusaurus-plugin-content-docs/current/reference/layers.mdx
index 665317d047..e2746fbe25 100644
--- a/i18n/ja/docusaurus-plugin-content-docs/current/reference/layers.mdx
+++ b/i18n/ja/docusaurus-plugin-content-docs/current/reference/layers.mdx
@@ -5,20 +5,13 @@ pagination_next: reference/slices-segments
 
 # レイヤー
 
-レイヤー（層）は、Feature-Sliced Designにおける組織階層の最初のレベルです。その目的は、コードを必要な責任の量とアプリケーション内の他のモジュールへの依存度に基づいて分割することです。
+レイヤーは、Feature-Sliced Designにおける組織階層の最初のレベルです。その目的は、コードを責任の程度やアプリ内の他のモジュールへの依存度に基づいて分離することです。各レイヤーは、コードにどれだけの責任を割り当てるべきかを判断するための特別な意味を持っています。
 
-:::note
+合計で**7つのレイヤー**があり、責任と依存度が最も高いものから最も低いものへと配置されています。
 
-このページでのモジュールは、アプリケーション内のファイルやインデックスファイルを持つディレクトリを指している。npmパッケージと混同しないでください。
+<img src="/img/layers/folders-graphic-light.svg#light-mode-only" width="180" style={{ float: "right", margin: "0 1em" }} alt="A file system tree, with a single root folder called src and then seven subfolders: app, processes, pages, widgets, features, entities, shared. The processes folder is slightly faded out." />
+<img src="/img/layers/folders-graphic-dark.svg#dark-mode-only" width="180" style={{ float: "right", margin: "0 1em" }} alt="A file system tree, with a single root folder called src and then seven subfolders: app, processes, pages, widgets, features, entities, shared. The processes folder is slightly faded out." />
 
-:::
-
-各レイヤーは、コード内のモジュールにどれだけの責任を割り当てるべきかを判断するのに役立つ特別な意味を持っています。レイヤー名とレイヤーの意味は、Feature-Sliced Designを使用して構築されたすべてのプロジェクトで標準化されています。
-
-合計で<b>7つのレイヤー</b>があり、最も責任と依存度が高いものから最も低いものへと配置されています。
-
-<img src="/img/layers/folders-graphic-light.svg#light-mode-only" width="180" style={{ float: "right", margin: "0 1em" }} alt="ファイルシステムのツリーは、1つのルートフォルダsrcと7つのサブフォルダ（app、processes、pages、widgets、features、entities、shared）で構成されています。processesフォルダは少し薄く表示されています。" />
-<img src="/img/layers/folders-graphic-dark.svg#dark-mode-only" width="180" style={{ float: "right", margin: "0 1em" }} alt="ファイルシステムのツリーは、1つのルートフォルダsrcと7つのサブフォルダ（app、processes、pages、widgets、features、entities、shared）で構成されています。processesフォルダは少し薄く表示されています。" />
 
 1. App (アップ)
 2. Processes (プロセス、非推奨)
@@ -28,154 +21,133 @@ pagination_next: reference/slices-segments
 6. Entities (エンティティ)
 7. Shared (シェアード)
 
-プロジェクトで全てのレイヤーを使用する必要はないので、プロジェクトに価値をもたらすレイヤーだけを追加してください。
+プロジェクトにすべてのレイヤーを使用する必要はありません。プロジェクトに価値をもたらすと思う場合のみ追加してください。通常、ほとんどのフロントエンドプロジェクトには、少なくともShared、Page、Appのレイヤーがあります。
+
+実際には、レイヤーは小文字の名前のフォルダーです（例えば、`📁 shared`、`📁 pages`、`📁 app`）。新しいレイヤーを追加することは推奨されていません。なぜなら、その意味は標準化されているからです。
+
+## レイヤーに関するインポートルール
+
+レイヤーは _スライス_ で構成されており、これは非常に凝集性の高いモジュールのグループです。スライス間の依存関係は、**レイヤーに関するインポートルール**によって規制されています。
 
-## レイヤーのインポートルール {#import-rule-on-layers}
+> _スライス内のモジュール（ファイル）は、下位のレイヤーにある他のスライスのみをインポートできます。_
 
-レイヤーは、強く結合されたモジュールのグループである<i>スライス</i>から構成されています。Feature-Sliced Designは低い結合度をサポートしているため、スライス間の依存関係は<b>レイヤーのインポートルール</b>によって制御されます。
+例えば、フォルダー `📁 ~/features/aaa` は「aaa」という名前のスライスです。その中のファイル `~/features/aaa/api/request.ts` は、`📁 ~/features/bbb` 内のファイルからコードをインポートすることはできませんが、`📁 ~/entities` や `📁 ~/shared` からコードをインポートすることができ、例えば `~/features/aaa/lib/cache.ts` などの同じスライス内の隣接コードもインポートできます。
 
-> _スライス内のモジュールは、下層のレイヤーにあるスライスのみをインポートできる。_
+AppとSharedのレイヤーは、このルールの**例外**です。これらは同時にレイヤーとスライスの両方です。スライスはビジネスドメインによってコードを分割しますが、これらの2つのレイヤーは例外です。なぜなら、Sharedはビジネスドメインを持たず、Appはすべてのビジネスドメインを統合しているからです。
 
-例えば、`~/features/aaa` では、スライスは `aaa` であるため、`~/features/aaa/api/request.ts` ファイルは `~/features/bbb` フォルダー内のモジュールからコードをインポートすることはできませんが、`~/entities` や `~/shared` から、また `~/features/aaa` 内の隣接モジュールからはインポートできます。
+実際には、AppとSharedのレイヤーはセグメントで構成されており、セグメントは自由に互いにインポートできます。
 
 ## レイヤーの定義
 
-### Shared層
+このセクションでは、各レイヤーの意味を説明し、どのようなコードがそこに属するかの直感を得るためのものです。
 
-Shared層は、プロジェクトやビジネスの特性から切り離された、孤立したモジュール、コンポーネント、抽象化のことです。
+### Shared
 
-このレイヤーは他のレイヤーとは異なり、スライスではなく直接セグメントで構成されています。
+このレイヤーは、アプリの残りの部分の基盤を形成します。外部世界との接続を作成する場所であり、例えばバックエンド、サードパーティライブラリ、環境などです。また、特定のタスクに集中した自分自身のライブラリを作成する場所でもあります。
 
-**内容の例**
+このレイヤーは、Appレイヤーと同様に、_スライスを含みません_。スライスはビジネスドメインによってレイヤーを分割することを目的としていますが、Sharedにはビジネスドメインが存在しないため、Shared内のすべてのファイルは互いに参照し、インポートすることができます。
 
-* UIライブラリ
-* APIクライアント
-* ブラウザAPIと連携するコード
+このレイヤーで通常見られるセグメントは次のとおりです。
 
-### Entities層
+- `📁 api` — APIクライアントおよび特定のバックエンドエンドポイントへのリクエストを行う関数
+- `📁 ui` — アプリケーションのUIキット
+  このレイヤーのコンポーネントはビジネスロジックを含むべきではありませんが、ビジネスに関連することは許可されています。例えば、会社のロゴやページレイアウトをここに置くことができます。UIロジックを持つコンポーネントも許可されています（例えば、オートコンプリートや検索バー）
+- `📁 lib` — 内部ライブラリのコレクション
+  このフォルダーはヘルパーやユーティリティとして扱うべきではありません（[なぜこれらのフォルダーがしばしばダンプに変わるか][ext-sova-utility-dump]）。このフォルダー内の各ライブラリは、日付、色、テキスト操作など、1つの焦点を持つべきです。その焦点はREADMEファイルに文書化されるべきです。チームの開発者は、これらのライブラリに何を追加でき、何を追加できないかを知っているべきです
+- `📁 config` — 環境変数、グローバルフィーチャーフラグ、アプリの他のグローバル設定
+- `📁 routes` — ルート定数、またはルートをマッチさせるためのパターン
+- `📁 i18n` — 翻訳のセットアップコード、グローバル翻訳文字列
 
-Entities層は、プロジェクトの本質を形成する現実世界の概念です。通常、これはビジネスがプロダクトを説明するために使用する用語です。
+さらにセグメントを追加することは自由ですが、これらのセグメントの名前は内容の目的を説明するものでなければなりません。例えば、`components`、`hooks`、`types` は、コードを探しているときにあまり役立たないため、悪いセグメント名です。
 
-このレイヤーの各スライスは、ユーザーインターフェースの静的要素、データストレージ、およびCRUD（作成・読み取り・更新・削除）操作を含みます。
+### Entities
 
-**スライスの例**
+このレイヤーのスライスは、プロジェクトが扱う現実世界の概念を表します。一般的には、ビジネスがプロダクトを説明するために使用する用語です。例えば、SNSは、ユーザー、投稿、グループなどのビジネスエンティティを扱うかもしれません。
 
-<table>
-<thead><tr><th> SNS </th><th> Gitフロントエンド（例：GitHub） </th></tr></thead>
-<tbody><tr><td><ul>
-<li>ユーザー</li>
-<li>投稿</li>
-<li>グループ</li>
-</ul></td><td><ul>
-<li>リポジトリ</li>
-<li>ファイル</li>
-<li>コミット</li>
-</ul></td></tr></tbody></table>
+エンティティスライスには、データストレージ（`📁 model`）、データ検証スキーマ（`📁 model`）、エンティティ関連のAPIリクエスト関数（`📁 api`）、およびインターフェース内のこのエンティティの視覚的表現（`📁 ui`）が含まれる場合があります。視覚的表現は、完全なUIブロックを生成する必要はなく、アプリ内の複数のページで同じ外観を再利用することを主に目的としています。異なるビジネスロジックは、プロップスやスロットを通じてそれに付加されることがあります。
 
-:::tip
+#### エンティティの関係
 
-Gitフロントエンドの例では、<i>リポジトリ</i>が<i>ファイル</i>を含むことに気付くかもしれません。これは、リポジトリが他のエンティティを内包する高レベルのエンティティであることを示しています。このような高レベルのエンティティを作成ことは一般的が、この場合、レイヤーのインポートルールを破らないことは時に難しいです。
+FSDにおけるエンティティはスライスであり、デフォルトではスライスは互いに知ることができません。しかし、現実の世界では、エンティティはしばしば互いに相互作用し、一方のエンティティが他のエンティティを所有、または含むことがあります。そのため、これらの相互作用のビジネスロジックは、フィーチャーやページのような上位のレイヤーに保持されるのが望ましいです。
 
-この問題を解決するためのいくつかの提案があります。
-* エンティティのUIは、下位レベルのエンティティを挿入するためのスロットを含むべき
-* エンティティ間の相互作用に関連するビジネスロジックは、通常、Features層に配置されるべき
-* データベースのエンティティインターフェースは、APIクライアントの近くにあるShared層に抽出できる
+一つのエンティティのデータオブジェクトが他のデータオブジェクトを含む場合、通常はエンティティ間の接続を明示的にし、`@x`表記を使用してスライスの隔離を回避するのが良いアイデアです。理由は、接続されたエンティティは一緒にリファクタリングする必要があるため、その接続を見逃すことができないようにするのが最善です。
 
-:::
+例：
+
+```ts title="entities/artist/model/artist.ts"
+import type { Song } from "entities/song/@x/artist";
+
+export interface Artist {
+  name: string;
+  songs: Array<Song>;
+}
+```
 
-### Features層
+```ts title="entities/song/@x/artist.ts"
+export type { Song } from "../model/song.ts";
+```
 
-Features層は、ユーザーがアプリケーション内でビジネスエンティティとインタラクションするために行うアクションで、価値のある結果を達成するためのものです。ここには、ユーザーのためにアプリケーションが実行するアクションも含まれています。
+`@x`表記の詳細については、[クロスインポートの公開API][public-api-for-cross-imports]セクションを参照してください。
 
-このレイヤーのスライスは、価値を生み出すアクションを実行するためのインタラクティブなUI要素、内部状態、およびAPIリクエストを含むことができます。
+### Features
 
-**スライスの例**
+このレイヤーは、アプリ内の主要なインタラクション、つまりユーザーが行いたいことを対象としています。これらのインタラクションは、ビジネスエンティティを含むことが多いです。
 
-<table>
-<thead><tr><th> SNS </th><th> Gitフロントエンド（例：GitHub） </th><th> ユーザーの代わりに行うアクション </th></tr></thead>
-<tbody><tr><td><ul>
-<li>ログイン</li>
-<li>投稿を作成</li>
-<li>グループに参加</li>
-</ul></td><td><ul>
-<li>ファイルを変更</li>
-<li>コメントを残す</li>
-<li>ブランチをマージ</li>
-</ul></td><td><ul>
-<li>ダークテーマを自動的に有効にする</li>
-<li>バックグラウンドで計算を実行する</li>
-<li>User-Agentに基づくアクション</li>
-</ul></td></tr></tbody></table>
+アプリのフィーチャーレイヤーを効果的に使用するための重要な原則は、**すべてのものがフィーチャーである必要はない**ということです。何かがフィーチャーである必要がある良い指標は、それが複数のページで再利用されるという事実です。
 
-### Widgets層
+例えば、アプリに複数のエディターがあり、すべてにコメントがある場合、コメントは再利用されるフィーチャーです。スライスはコードを迅速に見つけるためのメカニズムであり、フィーチャーが多すぎると重要なものが埋もれてしまいます。
 
-Widgets層は、独立したUIブロックであり、エンティティやフィーチャーなどの低レベルユニットの組み合わせです。
+理想的には、新しいプロジェクトに入ったとき、既存のページやフィーチャーを見ると、アプリの機能性が分かります。何がフィーチャーであるべきかを決定する際には、プロジェクトの新参者が重要なコードの大きな領域を迅速に発見できるように最適化してください。
 
-このレイヤーは、エンティティのインターフェースに残されたスロットを、他のフィーチャーからのインタラクティブ要素やエンティティで埋めることを可能にしています。したがって、通常、このレイヤーにはビジネスロジックは配置されず、代わりにフィーチャーに保存されます。このレイヤーの各スライスは、使用可能なUIコンポーネントを含み、時にはビジネスロジック以外のロジック（例えば、ジェスチャー、キーボードとの相互作用など）を含むことがあります。
+フィーチャーのスライスには、インタラクションを実行するためのUI（例えばフォーム、`📁 ui`）、アクションを実行するために必要なAPI呼び出し（`📁 api`）、検証および内部状態（`📁 model`）、フィーチャーフラグ（`📁 config`）が含まれる場合があります。
 
-時には、このレイヤーにビジネスロジックを配置する方が便利な場合もあります。これは、ウィジェットがかなりのインタラクティブ性を持っている場合（例えば、インタラクティブテーブル）で、その中のビジネスロジックが再利用されない場合によく発生します。
+### Widgets
 
-**スライスの例**
+ウィジェットレイヤーは、大きな自己完結型のUIブロックを対象としています。ウィジェットは、複数のページで再利用される場合や、所属するページにある複数の大きな独立したブロックの一つである場合に最も便利です。
 
-<table>
-<thead><tr><th> SNS </th><th> Gitフロントエンド（例：GitHub） </th></tr></thead>
-<tbody><tr><td><ul>
-<li>投稿カード</li>
-<li>ユーザープロフィールのヘッダー（アクション付き）</li>
-</ul></td><td><ul>
-<li>リポジトリ内のファイル一覧（アクション付き）</li>
-<li>スレッド内のコメント</li>
-<li>リポジトリカード</li>
-</ul></td></tr></tbody></table>
+UIのブロックがページの大部分を構成し、再利用されない場合、それは**ウィジェットであるべきではなく**、代わりにそのページ内に直接配置するべきです。
 
 :::tip
 
-ネストされたルーティングシステム（例えば、[Remix][ext--remix]ルーター）を使用している場合、Widgets層をPages層と同様に使用することが便利なケースがあります。例えば、バックエンドからのデータを取得し、読み込み状態やエラー処理を含むインターフェースブロックを作成する際に役立てます。また、Pages層のレイアウトをここに配置することもできます。
-:::
+ネストされたルーティングシステム（[Remix][ext-remix]のルーターのような）を使用している場合、ウィジェットレイヤーを、フラットなルーティングシステムがページレイヤーを使用するのと同じように使用することが役立つかもしれません。それは関連データの取得、ローディング状態、エラーバウンダリを含む完全なルーターブロックを作成するためです。
+
+同様に、このレイヤーにページレイアウトを保存することもできます。
 
-### Pages層
+:::
 
-Pages層は、ページベースのアプリケーション（例えば、ウェブサイト）のページや、画面ベースのアプリケーション（例えば、モバイルアプリ）の画面やアクティビティです。
+### Pages
 
-このレイヤーは、その構成的な性質においてWidgets層に似ていますが、より大きな規模で構成されています。Pages層の各スライスは、ルーターに接続できるUIコンポーネントを含むほか、データ取得やエラー処理のロジックを含むこともできます。
+ページは、ウェブサイトやアプリケーションを構成するものです（スクリーンやアクティビティとも呼ばれます）。通常、1ページは1つのスライスに対応しますが、非常に似たページが複数ある場合、それらを1つのスライスにまとめることができます。例えば、登録フォームとログインフォームです。
 
-**スライスの例**
+チームがナビゲートしやすい限り、ページスライスに配置できるコードの量に制限はありません。ページ上のUIブロックが再利用されない場合、それをページスライス内に保持することは完全に問題ありません。
 
-<table>
-<thead><tr><th> SNS </th><th> Gitフロントエンド（例：GitHub） </th></tr></thead>
-<tbody><tr><td><ul>
-<li>ニュースフィード</li>
-<li>コミュニティページ</li>
-<li>公開ユーザープロフィール</li>
-</ul></td><td><ul>
-<li>リポジトリページ</li>
-<li>ユーザーのリポジトリ</li>
-<li>リポジトリ内のブランチ</li>
-</ul></td></tr></tbody></table>
+ページスライスには、通常、ページのUIやローディング状態、エラーバウンダリ（`📁 ui`）、データの取得や変更リクエスト（`📁 api`）が含まれます。ページが専用のデータモデルを持つことは一般的ではなく、状態の小さな部分はコンポーネント自体に保持されることがあります。
 
-### Processes層
+### Processes
 
 :::caution
 
-このレイヤーは、廃止されています。現在の仕様バージョンでは、これを避け、内容を `features`層 と `app`層 に移動することを推奨しています。
+このレイヤーは非推奨です。現在の仕様では、これを避け、その内容をFeaturesやAppに移動することを推奨しています。
 
 :::
 
-Processes層は、複雑なマルチページインタラクションが必要な際に使用されます。
+プロセスは、マルチページインタラクションのための逃げ道です。
 
-このレイヤーは意図的にあまり定義されていません。ほとんどのアプリケーションにはこのレイヤーは必要ありません。ルーターやサーバーレベルのロジックはApp層に残すべきです。このレイヤーは、App層が成長しすぎて管理できなくなった場合にのみ使用を検討してください。
+このレイヤーは意図的に未定義のままにされています。ほとんどのアプリケーションはこのレイヤーを使用せず、ルーターやサーバーレベルのロジックをAppレイヤーに保持するべきです。このレイヤーは、Appレイヤーが大きくなりすぎてメンテナンスが困難になった場合にのみ使用することを検討してください。
 
-### App層
+### App
 
-App層は、アプリ全体に関するすべてのことです。技術的な意味（例えば、コンテキストプロバイダー）とビジネス的な意味（例えば、分析）を含みます。
+アプリ全体に関するあらゆるもの、技術的な意味（例えば、コンテキストプロバイダー）やビジネス的な意味（例えば、分析）を含みます。
 
-このレイヤーは通常、Shared層と同様にスライスを含まず、直接セグメントで構成されています。
+このレイヤーには通常、スライスは含まれず、Sharedと同様に、セグメントが直接存在します。
 
-**内容の例**
+このレイヤーで通常見られるセグメントは次のとおりです。
 
-* スタイル
-* ルーター
-* データストレージやその他のコンテキストプロバイダー
-* 分析の初期化
+- `📁 routes` — ルーターの設定
+- `📁 store` — グローバルストアの設定
+- `📁 styles` — グローバルスタイル
+- `📁 entrypoint` — アプリケーションコードへのエントリポイント、フレームワーク固有
 
-[ext--remix]: https://remix.run
\ No newline at end of file
+[public-api-for-cross-imports]: /docs/reference/public-api#public-api-for-cross-imports
+[ext-remix]: https://remix.run
+[ext-sova-utility-dump]: https://dev.to/sergeysova/why-utils-helpers-is-a-dump-45fo
diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/reference/public-api.md b/i18n/ja/docusaurus-plugin-content-docs/current/reference/public-api.md
index 8b07850319..3b6ee63517 100644
--- a/i18n/ja/docusaurus-plugin-content-docs/current/reference/public-api.md
+++ b/i18n/ja/docusaurus-plugin-content-docs/current/reference/public-api.md
@@ -1,216 +1,159 @@
 ---
 sidebar_position: 3
-sidebar_label: 公開API
-pagination_next: about/index
 ---
 
 # 公開API
 
-FSDでの各エンティティは、**使いやすく統合しやすいモジュール**として設計されています。
+公開APIは、モジュールのグループ（スライスなど）とそれを使用するコードとの間の**契約**です。また、特定のオブジェクトへのアクセスを制限し、その公開APIを通じてのみアクセスを許可します。
 
-## 目的 {#goals}
+実際には、通常、再エクスポートを伴うインデックスファイルとして実装されます。
 
-モジュールの使いやすさと統合しやすさは、*いくつかの目的*を達成することによって実現されます。
-
-1. アプリケーションは、個々モジュール内部構造の**変更から保護されるべき**
-1. モジュール内部構造の再設計は、**他のモジュールに影響を与えてはならない**
-1. モジュールの動作の重要な変更は、**簡単に特定できるべき**
-    > **モジュールの動作に関する重要な変更**とは、モジュール利用者の期待を壊す変更
-
-これらの目的を達成するために、公開API（公開インターフェース）が導入され、モジュール機能への単一アクセス点を提供し、モジュールと外部世界との相互作用の「契約」を定義します。
-
-:::info 重要
-
-エンティティの構造は、公開APIを提供する単一のエントリーポイントを持つべき
-
-:::
-
-```sh
-└── features/                          # 
-   └── auth-form/                      # フィーチャーの内部構造
-            ├── ui/                    #
-            ├── model/                 #
-            ├── {...}/                 #
-            └── index.ts               # フィーチャーの公開APIを持つエントリーポイント
-```
-
-```ts title="**/**/index.ts"
-export { Form as AuthForm } from "./ui"
-export * as authFormModel from "./model"
+```js title="pages/auth/index.js"
+export { LoginPage } from "./ui/LoginPage";
+export { RegisterPage } from "./ui/RegisterPage";
 ```
 
-## 公開APIの要件 {#requirements-for-the-public-api}
-
-下記の要件を満たすことで、モジュールとの相互作用を**公開API契約の実行**に制限し、モジュールの信頼性と使いやすさを達成できます。
-
-### 1. アクセス制御 {#1-access-control}
+## 良い公開APIとは？
 
-公開APIは、モジュール内容への**アクセス制御**を行うべきです。
+良い公開APIは、他のコードとの統合を便利で信頼性の高いものにします。これを達成するためには、以下の3つの目標を設定することが重要です。
 
-- アプリケーションの他の部分は、**公開APIで提供されるモジュールのエンティティのみを使用できる**
-- 公開APIのないモジュールの内部部分は、**モジュール自身のみがアクセスできる**
+1. アプリケーションの残りの部分は、スライスの構造的変更（リファクタリングなど）から保護されるべきです。
+2. スライスの動作における重要な変更が以前の期待を破る場合、公開APIに変更が必要です。
+3. スライスの必要な部分のみを公開するべきです。
 
-#### 例 {#examples}
+最後の目標には重要な実践的な意味があります。特にスライスの初期開発段階では、すべてをワイルドカードで再エクスポートしたくなるかもしれません。なぜなら、ファイルからエクスポートする新しいオブジェクトは、スライスからも自動的にエクスポートされるからです。
 
-##### プライベートインポートからの排除 {#suspension-from-private-imports}
 
-- **悪い例**: 公開APIをバイパスしてモジュールの内部部分に直接アクセスすることは危険であり、特にモジュールのリファクタリング時に問題を引き起こす可能性がある。
-
-    ```diff
-    - import { Form } from "features/auth-form/components/view/form"
-    ```
-
-- **良い例**: APIは事前に必要なものだけをエクスポートし、モジュールの開発者はリファクタリング時に公開APIを壊さないことだけを考えればよい。
-
-    ```diff
-    + import { AuthForm } from "features/auth-form"
-    ```
-
-### 2. 変更への耐性 {#2-sustainability-for-changes}
+```js title="バッドプラクティス, features/comments/index.js"
+// ❌ これは悪いコードの例です。このようにしないでください。
+export * from "./ui/Comment";  // 👎
+export * from "./model/comments";  // 💩
+```
 
-公開APIは、モジュール内部の**変更に対して耐性があるべきです**。
+これは、スライスの理解可能性を損ないます。インターフェースが理解できないと、スライスのコードを深く掘り下げて統合方法を調べなければいけなくなってしまいます。もう一つの問題は、モジュールの内部を誤って公開してしまう可能性があり、誰かがそれに依存し始めるとリファクタリングが難しくなることです。
 
-- モジュールの動作を壊す変更は、公開APIの変更として反映されるべき
+## クロスインポートのための公開API {#public-api-for-cross-imports}
 
-#### 例 {#examples}
+クロスインポートは、同じレイヤーの別のスライスからインポートする状況です。通常、これは[レイヤーに関するインポートルール][import-rule-on-layers]によって禁止されていますが、しばしば正当な理由でクロスインポートが必要です。たとえば、ビジネスエンティティは現実世界で互いに参照し合うことが多く、これらの関係をコードに反映させるのが最善です。
 
-##### 実装からの抽象化 {#abstracting-from-the-implementation}
+この目的のために、`@x`表記として知られる特別な種類の公開APIがあります。エンティティAとBがあり、エンティティBがエンティティAからインポートする必要がある場合、エンティティAはエンティティB専用の別の公開APIを宣言できます。
 
-内部構造の変更は、公開APIの変更を引き起こすべきではありません。
+- `📂 entities`
+  - `📂 A`
+    - `📂 @x`
+      - `📄 B.ts` — エンティティB内のコード専用の特別な公開API
+    - `📄 index.ts` — 通常の公開API
 
-- **悪い例**: このコンポーネントをフィーチャー内で移動、または名前変更すると、すべての使用場所でインポートをリファクタリングする必要が生じる。
+その後、`entities/B/`内のコードは`entities/A/@x/B`からインポートできます。
 
-    ```diff
-    - import { Form } from "features/auth-form/ui/form"
-    ```
+```ts
+import type { EntityA } from "entities/A/@x/B";
+```
 
-- **良い例**: フィーチャーのインターフェースは内部構造を反映せず、外部の「ユーザー」はフィーチャー内のコンポーネントの移動や名前変更の影響を受けない。
 
-    ```diff
-    + import { AuthForm } from "features/auth-form"
-    ```
+`A/@x/B`という表記は「AとBが交差している」と読むことを意図しています。
 
-### 3. 統合性 {#3-integrability}
+:::note
 
-公開APIは、**簡単で柔軟な統合を促進するべきです**。
+クロスインポートは最小限に抑え、**この表記はエンティティレイヤーでのみ使用してください**。クロスインポートを排除することがしばしば非現実的だからです。
 
-- 公開APIは、アプリケーションの他の部分での使用が便利であり、特に名前衝突問題を解決する必要がある。
+:::
 
-#### 例 {#examples}
+## インデックスファイルの問題
 
-##### 名前の衝突 {#name-collision}
+`index.js`のようなインデックスファイル（Barrelファイルとも呼ばれる）は、公開APIを定義する最も一般的な方法です。作成は簡単ですが、特定のバンドラーやフレームワークで問題を引き起こすことがあります。
 
-- **悪い例**: 名前の衝突が発生してしまう。
+### 循環インポート
 
-    ```ts title="features/auth-form/index.ts"
-    export { Form } from "./ui"
-    export * as model from "./model"
-    ```
+循環インポートとは、2つ以上のファイルが互いに循環的にインポートすることです。
 
-    ```ts title="features/post-form/index.ts"
-    export { Form } from "./ui"
-    export * as model from "./model"
-    ```
+<!-- TODO: 画像に背景を追加し、モバイルで確認 -->
 
-    ```diff
-    - import { Form, model } from "features/auth-form"
-    - import { Form, model } from "features/post-form"
-    ```
+<figure>
+    <img src="/img/circular-import-light.svg#light-mode-only" width="60%" alt="三つのファイルが循環的にインポートしている" />
+    <img src="/img/circular-import-dark.svg#dark-mode-only" width="60%" alt="三つのファイルが循環的にインポートしている" />
+    <figcaption>
+        上の図には、`fileA.js`、`fileB.js`、`fileC.js`の三つのファイルが循環的にインポートしている様子が示されています。
+    </figcaption>
+</figure>
 
-- **良い例**: インターフェースレベルで名前の衝突が解決される。
+これらの状況は、バンドラーにとって扱いが難しく、場合によってはデバッグが難しいランタイムエラーを引き起こすことさえあります。
 
-    ```ts title="features/auth-form/index.ts"
-    export { Form as AuthForm } from "./ui"
-    export * as authFormModel from "./model"
-    ```
+循環インポートはインデックスファイルなしでも発生する可能性がありますが、インデックスファイルがあると、循環インポートを誤って作成する明確な機会が生まれます。これは、公開APIのスライスに2つのオブジェクト（例えば、`HomePage`と`loadUserStatistics`）が存在し、`HomePage`が`loadUserStatistics`に以下のようにアクセスすると循環インポートが発生してしまいます。
 
-    ```ts title="features/post-form/index.ts"
-    export { Form as PostForm } from "./ui"
-    export * as postFormModel from "./model"
-    ```
 
-    ```diff
-    + import { AuthForm, authFormModel } from "features/auth-form"
-    + import { PostForm, postFormModel } from "features/post-form"
-    ```
+```jsx title="pages/home/ui/HomePage.jsx"
+import { loadUserStatistics } from "../"; // pages/home/index.jsからインポート
 
-##### 柔軟な使用 {#flexible-use}
+export function HomePage() { /* … */ }
+```
 
-- **悪い例**: 書きにくく、読みづらく、「ユーザー」は不便を感じます。
+```js title="pages/home/index.js"
+export { HomePage } from "./ui/HomePage";
+export { loadUserStatistics } from "./api/loadUserStatistics";
+```
 
-    ```diff
-    - import { storeActionUpdateUserDetails } from "features/auth-form"
-    - dispatch(storeActionUpdateUserDetails(...))
-    ```
 
-- **良い例**: 「ユーザー」は必要なものに対して反復的かつ柔軟にアクセスできます。
+この状況は循環インポートを作成します。なぜなら、`index.js`が`ui/HomePage.jsx`をインポートしますが、`ui/HomePage.jsx`が`index.js`をインポートするからです。
 
-    ```diff
-    + import { authFormModel } from "features/auth-form"
-    + dispatch(authFormModel.effects.updateUserDetails(...)) // redux
-    + authFormModel.updateUserDetailsFx(...) // effector
-    ```
+この問題を防ぐために、次の2つの原則を考慮してください。
+- ファイルが同じスライス内にある場合は、常に**相対インポート**を使用し、完全なインポートパスを記述すること
+- ファイルが異なるスライスにある場合は、常に**絶対インポート**を使用すること（エイリアスなどで）
 
-##### 衝突の解決 {#resolution-of-collisions}
+### Sharedにおける大きなバンドルサイズと壊れたツリーシェイキング {#large-bundles}
 
-名前の衝突は、実装レベルではなく公開APIのレベルで解決されるべきです。
+インデックスファイルがすべてを再エクスポートする場合、いくつかのバンドラーはツリーシェイキング（インポートされていないコードを削除すること）に苦労するかもしれません。
 
-- **悪い例**: 名前の衝突が実装レベルで解決される。
+通常、これは公開APIにとって問題ではありません。なぜなら、モジュールの内容は通常非常に密接に関連しているため、1つのものをインポートし、他のものをツリーシェイキングする必要がほとんどないからです。しかし、公開APIのルールが問題を引き起こす非常に一般的なケースが2つあります。それは`shared/ui`と`shared/lib`です。
 
-    ```ts title="features/auth-form/index.ts"
-    export { AuthForm } from "./ui"
-    export { authFormActions, authFormReducer } from "model"
-    ```
+これらの2つのフォルダーは、しばしば一度にすべてが必要ではない無関係なもののコレクションです。たとえば、`shared/ui`にはUIライブラリのすべてのコンポーネントのモジュールが含まれているかもしれません。
 
-    ```ts title="features/post-form/index.ts"
-    export { PostForm } from "./ui"
-    export { postFormActions, postFormReducer } from "model"
-    ```
+- `📂 shared/ui/`
+  - `📁 button`
+  - `📁 text-field`
+  - `📁 carousel`
+  - `📁 accordion`
 
-- **良い例**: 名前の衝突がインターフェースレベルで解決される。
+この問題は、これらのモジュールの1つが重い依存関係（シンタックスハイライトやドラッグ＆ドロップライブラリ）を持っている場合、悪化します。ボタンなど、`shared/ui`から何かを使用するすべてのページにそれらを引き込むことは望ましくありません。
 
-    ```ts title="features/auth-form/model.ts"
-    export { actions, reducer }
-    ```
+`shared/ui`や`shared/lib`の単一の公開APIによってバンドルサイズが不適切に増加する場合は、各コンポーネントやライブラリのために別々のインデックスファイルを持つことをお勧めします。
 
-    ```ts title="features/auth-form/index.ts"
-    export { Form as AuthForm } from "./ui"
-    export * as authFormModel from "./model"
-    ```
+- `📂 shared/ui/`
+  - `📂 button`
+    - `📄 index.js`
+  - `📂 text-field`
+    - `📄 index.js`
 
-     ```ts title="features/post-form/model.ts"
-    export { actions, reducer }
-    ```
+その後、これらのコンポーネントの消費者は、次のように直接インポートできます。
 
-    ```ts title="features/post-form/index.ts"
-    export { Form as PostForm } from "./ui"
-    export * as postFormModel from "./model"
-    ```
+```js title="pages/sign-in/ui/SignInPage.jsx"
+import { Button } from '@/shared/ui/button';
+import { TextField } from '@/shared/ui/text-field';
+```
 
-## 再エクスポートについて {#about-re-exports}
 
-JavaScriptでは、モジュールの公開APIは、モジュール内部のエンティティを`index`ファイルで再エクスポートすることによって作成されます。
+### 公開APIを回避することに対する実質的な保護がない
 
-```ts title="**/**/index.ts"
-export { Form as AuthForm } from "./ui"
-export * as authModel from "./model"
-```
+スライスのためにインデックスファイルを作成しても、誰もそれを使用せず、直接インポートを使用することができます。これは特に自動インポートにおいて問題です。なぜなら、オブジェクトをインポートできる場所がいくつかあるため、IDEがあなたのために決定しなければならないからです。時には、直接インポートを選択し、スライスの公開APIルールを破ることがあります。
 
-### 欠点 {#disadvantages}
+これらの問題を自動的にキャッチするために、[Steiger][ext-steiger]を使用することをお勧めします。これは、Feature-Sliced Designのルールセットを持つアーキテクチャリンターです。
 
-- ほとんどの人気のバンドラーでは、再エクスポートのために**コード分割の効果が低下してしまいます**。なぜなら、このアプローチでは[ツリーシェイキング](https://webpack.js.org/guides/tree-shaking/)が安全にモジュール全体しか削除することができないからです。
-   > 例えば、ページモデルで`authModel`をインポートすると、たとえ使用されていなくても、`AuthForm`コンポーネントがそのページのチャンクに含まれてしまいます。
+### 大規模プロジェクトにおけるバンドラーのパフォーマンスの低下
 
-- 結果として、チャンクの初期化が高コストになり、ブラウザはその中のすべてのモジュールを処理する必要があります。
+プロジェクト内に大量のインデックスファイルがあると、開発サーバーが遅くなる可能性があります。これは、TkDodoが[「Barrelファイルの使用をやめてください」][ext-please-stop-using-barrel-files]という記事で指摘しています。
 
-### 可能な解決策 {#possible-solutions}
+この問題に対処するためにできることはいくつかあります。
 
-- `webpack`は、再エクスポートファイルを[**副作用なし**](https://webpack.js.org/guides/tree-shaking/#mark-the-file-as-side-effect-free)としてマークすることを可能にしています。これにより、`webpack`はそのファイルを扱う際に攻撃的な最適化を使用できるようになります。
+1. [「Sharedにおける大きなバンドルサイズと壊れたツリーシェイキング」](#large-bundles)のセクションと同じアドバイス — `shared/ui`や`shared/lib`の各コンポーネントやライブラリのために別々のインデックスファイルを持つこと。
+2. スライスを持つレイヤーのセグメントにインデックスファイルを持たないようにすること。  
+   たとえば、「コメント」フィーチャーのインデックス（`📄 features/comments/index.js`）がある場合、そのフィーチャーの`ui`セグメントのために別のインデックスを持つ理由はありません（`📄 features/comments/ui/index.js`）。
+3. 非常に大きなプロジェクトがある場合、アプリケーションをいくつかの大きなチャンクに分割できる可能性が高いです。  
+   たとえば、Google Docsは、ドキュメントエディターとファイルブラウザに非常に異なる責任を持っています。各パッケージが独自のレイヤーセットを持つ別々のFSDルートとしてモノレポを作成できます。いくつかのパッケージは、SharedとEntitiesレイヤーのみを持つことができ、他のパッケージはPagesとAppのみを持つことができ、他のパッケージは独自の小さなSharedを含むことができますが、他のパッケージからの大きなSharedも使用できます。
 
-## 参照 {#see-also}
+<!-- TODO: 詳細を説明するページへのリンクを追加する（存在する場合） -->
 
-- [**SOLID**原則][ext-solid]
-- [**GRASP**パターン][ext-grasp]
+<!-- TODO: Next/Remixでのサーバー/クライアントコードの混在に関する問題を議論する -->
 
-[ext-solid]: https://ja.wikipedia.org/wiki/SOLID
-[ext-grasp]: https://ja.wikipedia.org/wiki/GRASP
+[import-rule-on-layers]: /docs/reference/layers#import-rule-on-layers
+[ext-steiger]: https://github.com/feature-sliced/steiger
+[ext-please-stop-using-barrel-files]: https://tkdodo.eu/blog/please-stop-using-barrel-files
\ No newline at end of file
diff --git a/i18n/ja/docusaurus-plugin-content-docs/current/reference/slices-segments.mdx b/i18n/ja/docusaurus-plugin-content-docs/current/reference/slices-segments.mdx
index a3f29279a5..3250e537cf 100644
--- a/i18n/ja/docusaurus-plugin-content-docs/current/reference/slices-segments.mdx
+++ b/i18n/ja/docusaurus-plugin-content-docs/current/reference/slices-segments.mdx
@@ -8,50 +8,64 @@ pagination_next: reference/public-api
 
 ## スライス
 
-スライスは、Feature-Sliced Designの組織階層における第2のレベルです。その主な目的は、プロダクト、ビジネス、または単にアプリケーションに対する意味に基づいてコードをグループ化することです。
+スライスは、Feature-Sliced Designの組織階層の第２レベルです。主な目的は、プロダクト、ビジネス、または単にアプリケーションにとっての意味に基づいてコードをグループ化することです。
 
-スライスの名前は標準化されておらず、アプリケーションのビジネス領域によって直接決定されます。例えば、フォトギャラリーには`photo`、`create-album`、`gallery-page`というスライスがあるかもしれません。SNSには、`post`、`add-user-to-friends`、`news-feed`のようなスライスが必要になるでしょう。
+スライスの名前は標準化されていません。なぜなら、それらはアプリケーションのビジネス領域によって直接決定されるからです。たとえば、フォトギャラリーには `photo`、`effects`、`gallery-page` というスライスがあるかもしれません。SNSには、`post`、`comments`、`news-feed` などの別のスライスが必要です。
 
-密接に関連するスライスは、同じフォルダーに構造的にグループ化できますが、他のスライスと同じ隔離ルールを遵守する必要があります。この場合、ディレクトリには、**複数のスライスによって共有されるコードは存在してはなりません**。
+Shared層とApp層にはスライスが含まれていません。これは、Sharedがビジネスロジックを含むべきではないため、プロダクト的な意味を持たないからです。また、Appはアプリケーション全体に関わるコードのみを含むべきであり、したがって分割は必要ありません。
 
-![「compose」（作成）、「like」（いいね）、「delete」（削除）の機能が「post」（投稿）フォルダーにグループ化されています。このフォルダーには「some-shared-code.ts」というファイルもあり、その名前は取り消し線が引かれており、そこに存在してはいけないことを示しています。](/img/graphic-nested-slices.svg)
+### 低結合と高凝集 {#zero-coupling-high-cohesion}
 
-Shared層とApp層にはスライスが含まれていません。それは、Shared層がビジネスロジックを含むべきではないため、プロダクトに対して意味を持っていないからです。また、App層はアプリケーション全体に関係するコードのみを含むべきであるため、分割の必要がないからです。
+スライスは、独立した強く凝集しているコードファイルのグループとして設計されています。以下の図は、凝集（cohesion）と結合（coupling）といった複雑な概念を視覚化するのに役立ちます。
+
+<figure>
+    <img src="/img/coupling-cohesion-light.svg#light-mode-only" alt="" />
+    <img src="/img/coupling-cohesion-dark.svg#dark-mode-only" alt="" />
+    <figcaption>
+        この図は、https://enterprisecraftsmanship.com/posts/cohesion-coupling-difference/ に触発されています。
+    </figcaption>
+</figure>
+
+理想的なスライスは、同じレベルの他のスライスから独立しており（低結合）、その主な目的に関連するコードの大部分を含んでいます（高凝集）。
+
+スライスの独立性は、[層のインポートルール][layers--import-rule]によって保証されます。
+
+> _スライス内のモジュール（ファイル）は、厳密に下の層にあるスライスのみをインポートできます。_
 
 ### スライスの公開APIルール
 
-スライス内では、コードは自由に整理でき、スライスが質の高い公開APIを提供している限り、それに問題がありません。これが**スライスの公開APIルール**の本質です。
+スライス内では、コードは自由に整理できますが、スライスが質の高い公開APIを持っている限り、問題はありません。これが<b>スライスの公開APIのルール</b>の本質です。
 
-> _すべてのスライス（およびスライスを持たないレイヤーのセグメント）は、公開APIの定義を含む必要がある_
+> _各スライス（およびスライスを持たない層のセグメント）は、公開APIの定義を含む必要があります。_
 >
-> _スライス/セグメントの外部にあるモジュールは、スライス/セグメントの内部ファイル構造ではなく、公開APIのみを参照すべき_
+> _あるスライス/セグメントの外部モジュールは、そのスライス/セグメントの内部ファイル構造ではなく、公開APIのみを参照できます。_
+
+公開APIの要求の理由や、作成のベストプラクティスについては、[公開APIのガイド][ref-public-api]を参照してください。
+
+### スライスのグループ
+
+密接に関連するスライスは、フォルダに構造的にグループ化できますが、他のスライスと同じ隔離ルールを遵守する必要があります。グループ化用のフォルダ内での<b>コードの共有は許可されていません</b>。
 
-公開APIの要件とその作成に関するベストプラクティスについては、[公開APIガイド][ref--public-api]を参照してください。
+![「compose」、「like」、「delete」機能が「post」フォルダにグループ化されています。このフォルダには、禁止を示すために取り消し線が引かれた「some-shared-code.ts」ファイルもあります。](/img/graphic-nested-slices.svg)
 
 ## セグメント
 
-セグメントは、組織階層の第3レベルおよび最終レベルであり、その目的は技術的な性質に基づいてコードをグループ化することです。
+セグメントは、組織階層の第３および最後のレベルであり、その目的は、技術的な目的に基づいてコードをグループ化することです。
 
 いくつかの標準化されたセグメント名があります。
-* `ui` - UIコンポーネント、データフォーマット関数
-* `model` - ビジネスロジックとデータストレージ、これらのデータを操作するための関数
-* `lib` - 補助的なインフラストラクチャコード
-* `api` - 外部APIとの通信、バックエンドAPIメソッド
 
-他のセグメントも許可されていますが、必要に応じてのみ作成されるべきです。カスタムセグメントの最も一般的な場所は、スライスが意味を持たないApp層とShared層です。
+- `ui` — UIに関連するすべてのもの：UIコンポーネント、日付フォーマッタ、スタイルなど。
+- `api` — バックエンドとのインタラクション：リクエスト関数、データ型、マッパーなど。
+- `model` — データモデル：スキーマ、インターフェース、ストレージ、ビジネスロジック。
+- `lib` — スライス内のモジュールに必要なライブラリコード。
+- `config` — 設定ファイルとフィーチャーフラグ。
 
-### 例
+[レイヤーに関するページ][layers--layer-definitions]には、これらのセグメントが異なる層でどのように使用されるかの例があります。
 
-| レイヤー       | `ui`         | `model`      | `lib`        | `api`        |
-| :-----------  | :----------- | :----------- | :----------- | :----------- |
-| Shared層      | UIライブラリ | 通常は使用されない | 複数の関連ファイルからのユーティリティモジュール。<br />個別のヘルパー関数が必要な場合は、[`lodash-es`][ext--lodash]などのユーティリティライブラリを検討してください。 | 認証やキャッシュなどの追加機能を持つシンプルななAPIクライアント。 |
-| Entities層    | インタラクティブ要素のスロットを持つビジネスエンティティの骨組み | エンティティのインスタンスのデータストレージと、それらのデータを操作するための関数。<br />サーバーからのデータを保存するのに最適。[TanStack Query][ext--tanstack-query]や他の暗黙的なストレージメソッドを使用する場合、省略できる。 | データストレージに関連しないエンティティのインスタンスを操作するための関数 | Shared層からのAPIクライアントを使用してバックエンドとの通信を簡素化するAPIメソッド |
-| Features層    | ユーザーが機能を使用できるためのインタラクティブ要素 | 必要に応じてビジネスロジックとインフラストラクチャデータストレージ（例：アプリケーションの現在のテーマ）。ユーザーに価値を提供するコードがここにある | `model`セグメントのビジネスロジックを簡潔に説明するためのインフラストラクチャコード | バックエンドで機能を表すAPIメソッド。<br />Entities層からのAPIメソッドを組み合わせることがある。 |
-| Widgets層     | Entities層とFeatures層を自己完結型のUIブロックに構成する。<br />エラーバウンダリやローディング状態を含むこともできる。 | 必要に応じてインフラストラクチャデータストレージを含むことができる | ページ上でウィジェットブロックが機能するために必要な非ビジネスインタラクション（例：ジェスチャー）やその他のコード | 通常は使用されないが、ネストされたルーティングの文脈でデータローダーを含むことがある（例: [Remix][ext--remix]） |
-| Pages層       | Entities層、Features層、Widgets層の構成。<br />エラーバウンダリやローディング状態を含むこともできる。 | 通常は使用されない | UXを提供するために必要な非ビジネスインタラクション（例：ジェスチャー）やその他のコード | SSR（サーバーサイドレンダリング）指向のフレームワーク用のデータローダー |
+独自のセグメントを作成することもできます。カスタムセグメントの最も一般的な場所は、スライスが意味を持たないApp層とShared層です。
 
-[ref--public-api]: /docs/reference/public-api
+これらのセグメントの名前が、その内容が何のために必要かを説明するものであることを確認してください。たとえば、`components`、`hooks`、`types` は、コードを探すときにあまり役に立たないため、悪いセグメント名です。
 
-[ext--lodash]: https://www.npmjs.com/package/lodash-es
-[ext--tanstack-query]: https://tanstack.com/query/latest
-[ext--remix]: https://remix.run
+[layers--layer-definitions]: /docs/reference/layers#layer-definitions
+[layers--import-rule]: /docs/reference/layers#import-rule-on-layers
+[ref-public-api]: /docs/reference/public-api