diff --git a/docs/src/pages/ja/(pages)/advanced/lexically-scoped-react-server-components.mdx b/docs/src/pages/ja/(pages)/advanced/lexically-scoped-react-server-components.mdx
new file mode 100644
index 00000000..e252c442
--- /dev/null
+++ b/docs/src/pages/ja/(pages)/advanced/lexically-scoped-react-server-components.mdx
@@ -0,0 +1,718 @@
+---
+title: レキシカルスコープを持つReact Server Components
+date: 2026-03-10
+author: Viktor Lázár
+github: lazarv
+category: Advanced
+order: 0
+---
+
+import Link from "../../../../components/Link.jsx";
+import Subtitle from "../../../../components/Subtitle.jsx";
+
+# レキシカルスコープを持つReact Server Components
+
+単一ファイル内で深くネストするクライアント/サーバーアイランド
+
+*react-serverが、任意のネスト深度からインラインの`"use client"`および`"use server"`ディレクティブをどのように抽出し、ファイル境界なしの真のサーバー/クライアントアイランド合成を可能にしているかの技術的な詳細解説です。*
+
+
+## 概要
+
+
+React Server Components(RSC)は、`"use client"`と`"use server"`ディレクティブによって、サーバーコードとクライアントコードの間にモジュールレベルの境界を導入しました。仕様上、これらのディレクティブはモジュール全体に適用されます。つまり、1つのファイルは、クライアントコンポーネントか、サーバー関数モジュールか、サーバーコンポーネントのいずれかです。このファイルレベルの粒度は、密結合したサーバー/クライアントロジックを複数のファイルに分割することを開発者に強制し、意図を見えにくくする間接参照を生み出します。
+
+本稿では、`@lazarv/react-server`に実装された、React Server Componentsのモジュール境界の制約を取り除くコンパイル時抽出アルゴリズムを紹介します。これにより、`"use client"`と`"use server"`ディレクティブを、任意のネスト深度にある個々の関数本体の内側に書けるようになります。単一のViteプラグインが、最も外側の関数から順に処理する複数パスの抽出を実行し、クエリパラメータ付きインポートチェーンで接続された仮想モジュールを生成します。このアルゴリズムは、レキシカルスコープのキャプチャ、モジュール状態の共有、深くネストしたディレクティブの交互配置(サーバー → クライアント → サーバー → …)、そして既存のRSCバンドラープロトコルとの透過的な統合を扱い、開発ビルドと本番ビルドの両方で動作します。
+
+この機能をサポートしているReactフレームワークは、現時点で他にありません。
+
+
+## 問題: アーキテクチャの制約としてのファイル境界
+
+
+標準のRSCモデルでは、ディレクティブはモジュールレベルの宣言です。
+
+```jsx
+// counter.jsx — クライアントモジュール
+"use client";
+import { useState } from "react";
+export function Counter() {
+ const [count, setCount] = useState(0);
+ return ;
+}
+```
+
+```jsx
+// page.jsx — サーバーコンポーネント
+import { Counter } from "./counter";
+export default function Page() {
+ return ;
+}
+```
+
+この分離には、3つの構造的なコストがあります。
+
+1. **ファイルの増殖。** 1つのクライアントボタンをレンダリングするサーバーコンポーネントには、2つのファイルが必要です。N個の異なるクライアントアイランドを持つページには、最低でもN+1個のファイルが必要になります。
+2. **人為的な間接参照。** 「このサーバーページはこのインタラクティブなウィジェットを含む」という論理的な単位が、ファイルシステム上に散らばります。コードのナビゲーションと理解が損なわれます。
+3. **不可能な合成。** 異なるクライアントコンポーネントを動的に構築して返すサーバー関数(ファクトリーパターンなど)は存在できません。サーバー関数とクライアントコンポーネントは別々のモジュールに置かなければならないため、サーバー関数は自身が返すクライアントコンポーネントをレキシカルに定義できないのです。
+
+3つ目が最も重要です。RSCのシリアライズプロトコル(`@lazarv/rsc`に実装)は、サーバー関数からクライアントコンポーネント参照を返すことをすでにサポートしています。制約は完全にバンドラー側にあります。`"use server"`関数の本体内に定義された`"use client"`コンポーネントを抽出できるツールは、これまで存在しませんでした。
+
+
+## 設計目標
+
+
+インラインディレクティブシステムは、次の不変条件を掲げて設計されました。
+
+1. **任意のネスト。** `"use server"`の中の`"use client"`の中の`"use server"`(さらに深くても)が動作すること。交互配置のたびに、新しいアイランド境界が作られます。
+2. **レキシカルスコープのキャプチャ。** 親関数スコープの変数は、抽出されたモジュールへ転送されなければなりません。クライアントコンポーネントに対してはpropsとして、サーバー関数に対してはバインドされた引数としてです。
+3. **モジュール状態の共有。** トップレベルの宣言(定数、可変変数、クラスインスタンス)は、抽出されたモジュールへ複製してはいけません。抽出されたモジュールは、同一性と変更のセマンティクスを保つために、元のモジュールからそれらをインポートしなければなりません。
+4. **RSCプロトコルとの透過的な統合。** 抽出されたモジュールは、RSCシリアライズ層から見て、手書きで分離されたファイルと区別がつかないものでなければなりません。クライアント参照、サーバー参照、マニフェストのすべてが同一に動作する必要があります。
+5. **単一ファイルでの開発。** プログラマーは1つのファイルを書きます。コンパイラが正しいモジュールグラフを生成します。コード生成の成果物がソースツリーに現れることはありません。
+6. **冪等な再抽出。** 抽出された仮想モジュール自体が、反対側の境界のディレクティブを含む場合(ネストのケース)、同じプラグインがそれを再処理し、より深い仮想モジュールを生成します。これは収束しなければなりません。
+
+
+## アーキテクチャの全体像
+
+
+システムは3つのコンポーネントで構成されています。
+
+| コンポーネント | 役割 |
+|---|---|
+| `use-directive-inline.mjs` | 単一のViteプラグイン。AST解析、抽出、仮想モジュールの提供、コード変換を実行します。ディレクティブの種類に対して汎用的です。 |
+| `use-client-inline.mjs` | `"use client"`用の設定オブジェクト。キャプチャされた変数を分割代入のpropsに変換する方法と、呼び出し箇所を`createElement`ラッパーに変換する方法を定義します。 |
+| `use-server-inline.mjs` | `"use server"`用の設定オブジェクト。キャプチャされた変数を`Function.prototype.bind`の引数に変換する方法と、呼び出し箇所を直接参照に変換する方法を定義します。 |
+
+プラグインは、両方の設定とともに一度だけインスタンス化されます。
+
+```javascript
+import useDirectiveInline from "./use-directive-inline.mjs";
+import { useClientInlineConfig } from "./use-client-inline.mjs";
+import { useServerInlineConfig } from "./use-server-inline.mjs";
+
+useDirectiveInline([useClientInlineConfig, useServerInlineConfig]);
+```
+
+この単一のプラグインが、統一されたパスですべてのディレクティブの種類を処理します。2つの設定は、スコープキャプチャの注入と呼び出し箇所の置き換えの戦略においてのみ異なります。
+
+
+## 抽出アルゴリズム
+
+
+### フェーズ1: 最も外側の関数を優先する探索
+
+ソースファイルが与えられると、プラグインは本体がディレクティブ文字列リテラル(`"use client"`または`"use server"`)で始まるすべての関数を見つけます。その後、**最も外側**のディレクティブ関数、つまり他のどのディレクティブ関数にも含まれていないものだけに絞り込みます。
+
+```
+findOutermostDirectiveFunctions(ast, ["use client", "use server"])
+```
+
+これは正しさのために不可欠です。次の例を考えてみます。
+
+```jsx
+function Outer() {
+ "use client";
+ async function Inner() {
+ "use server";
+ // ...
+ }
+ // ...
+}
+```
+
+`Outer`と`Inner`はどちらもディレクティブを含みますが、最も外側にあるのは`Outer`だけです。プラグインはまず`Outer`を抽出します。`Outer`の抽出モジュールが後で同じプラグインによって処理されるとき(フェーズ3を参照)、`Inner`は*そのモジュール内で*最も外側のものとして発見され、順に抽出されます。
+
+「最も外側を優先する」という不変条件は、次のことを保証します。
+
+- どの関数も二度抽出されない
+- ネストしたディレクティブは、特別扱いのロジックではなく再帰的な適用で処理される
+- 任意の有限なネスト深度でアルゴリズムが収束する
+
+### フェーズ2: スコープ解析
+
+最も外側の各ディレクティブ関数に対して、プラグインはレキシカルスコープ解析を実行し、**キャプチャされる変数**を特定します。それは、次の条件を満たす識別子です。
+
+- 関数本体の内側で参照されている
+- 中間の関数スコープで宣言されている(モジュールレベルでも、その関数自身のローカルでもない)
+- インポートバインディングではない(それらは抽出モジュールに直接含められます)
+- トップレベルの宣言ではない(それらは元のモジュールからのインポートによって共有されます)
+
+アルゴリズムは、スコープフレームのスタックを保持しながら、ルートからASTを走査します。各フレームは、関数のパラメータとローカルの`let`/`const`/`var`/`function`/`class`宣言によって宣言された変数を記録します。対象の関数に到達すると、すべての中間スコープの和集合と、対象関数の内側で使用されている識別子との積集合が取られます。
+
+```
+scopeStack: [App's locals] → [Component's locals] → target function
+captured = (App.locals ∪ Component.locals) ∩ target.usedIdentifiers
+ − importBindings − topLevelDeclarations
+```
+
+この3分割が本質的に重要です。
+
+| カテゴリ | 抽出モジュールでの扱い |
+|---|---|
+| **インポートバインディング** | インポート文としてそのままコピー |
+| **トップレベル宣言** | 元のファイルからインポート (`import { x } from "./original"`) |
+| **キャプチャされたスコープ変数** | 関数シグネチャに注入 |
+
+### フェーズ3: 仮想モジュールの生成
+
+抽出された各関数は、クエリパラメータ付きURLで識別される仮想モジュールを生成します。
+
+```
+original.jsx?use-client-inline=Counter
+original.jsx?use-server-inline=increment
+```
+
+ネストした抽出(すでに抽出された`"use client"`モジュールの中の`"use server"`)では、クエリパラメータが`&`で連結されます。
+
+```
+original.jsx?use-client-inline=Counter&use-server-inline=increment
+```
+
+仮想モジュールは次のものを含みます。
+
+1. ディレクティブ文字列 (`"use client";` または `"use server";`)
+2. 抽出された関数が使用するすべてのインポート文
+3. 参照されるトップレベル宣言のための `import { ... } from "./original"`
+4. キャプチャされた変数がパラメータリストに注入された関数本体
+5. その関数の`default`エクスポート
+
+プラグインの`load`フックが、クエリパターンに一致するあらゆるIDに対してこの生成コードを提供します。`resolveId`フックは、仮想モジュールIDが解決済みとして扱われることを保証し、さらに仮想モジュール内からの相対インポートについては、インポーターのパスからクエリパラメータを取り除いてから再解決することで処理します。
+
+### フェーズ4: 呼び出し箇所の書き換え
+
+元のファイルは変換され、抽出された各関数は仮想モジュールへの参照に置き換えられます。置き換え戦略は、ディレクティブの種類によって異なります。
+
+**`"use server"`関数の場合:**
+
+キャプチャされた変数がない場合 — 直接インポート:
+```javascript
+// 変換前:
+async function action(data) { "use server"; /* ... */ }
+// 変換後:
+import __action from "./file?use-server-inline=action";
+const action = __action;
+```
+
+キャプチャされた変数がある場合 — `bind`:
+```javascript
+// 変換前:
+async function action(data) { "use server"; /* ... */ }
+// 変換後:
+import __action from "./file?use-server-inline=action";
+const action = __action.bind(null, capturedVar1, capturedVar2);
+```
+
+抽出モジュールの関数シグネチャは、キャプチャされた変数を先頭に追加する形に書き換えられます。
+```javascript
+// 抽出モジュール:
+"use server";
+export default async function action(capturedVar1, capturedVar2, data) { /* ... */ }
+```
+
+実行時には、`.bind(null, capturedVar1, capturedVar2)`が最初の2つの引数が事前に埋められた関数を作るため、呼び出し箇所の`action(data)`は、サーバー上では`action(capturedVar1, capturedVar2, data)`になります。
+
+**`"use client"`コンポーネントの場合:**
+
+キャプチャされた変数がない場合 — 直接インポート(Viteの標準の解決で処理されます):
+```javascript
+// 変換前:
+function Counter() { "use client"; /* ... */ }
+// 変換後:
+import Counter from "./file?use-client-inline=Counter";
+```
+
+キャプチャされた変数がある場合 — propsを注入する`createElement`ラッパー:
+```javascript
+// 変換前:
+function Counter() { "use client"; /* ... */ }
+// 変換後:
+import { createElement as __useClientCreateElement } from "react";
+import __Counter from "./file?use-client-inline=Counter";
+const Counter = (__props) => __useClientCreateElement(__Counter, { ...__props, label });
+```
+
+抽出モジュールの関数シグネチャは、キャプチャされた変数を分割代入のpropsとして受け取る形に書き換えられます。
+```javascript
+// 抽出モジュール:
+"use client";
+export default function Counter({ label }) { /* ... */ }
+```
+
+これにより、キャプチャされた変数は通常のpropsとしてRSCシリアライズ境界を流れます。実行時プロトコルの拡張は一切不要です。
+
+### フェーズ5: モジュール状態のエクスポート
+
+抽出された関数がソースファイルのトップレベル宣言を参照する場合、それらの宣言はインポート可能でなければなりません。プラグインは、抽出された関数から使用されているがまだエクスポートされていないトップレベル宣言について、合成された`export { ... }`文を元のモジュールに追記します。
+
+これにより、**共有されたモジュール状態**が保たれます。トップレベル変数が元のモジュールによって変更され、抽出モジュールから読まれる場合(またはその逆)、ESモジュールのインポートセマンティクスによって同じモジュールインスタンスを共有しているため、双方は同じバインディングを見ることになります。
+
+
+## 再帰的な抽出と深いネストの問題
+
+
+このシステムの最も新しい側面は、任意の深さのネストの扱いです。次の例を考えてみます。
+
+```jsx
+import { useState, useTransition } from "react";
+
+async function getGreeting(name) {
+ "use server";
+
+ function GreetingCard({ message }) {
+ "use client";
+ const [liked, setLiked] = useState(false);
+ return (
+
+
{message}
+
+
+ {items.map(item => (
+ - setSelected(item.id)}>
+ {item.name} {selected === item.id && "✓"}
+
+ ))}
+
+ );
+ }
+
+ return ;
+}
+```
+
+このサーバー関数は、データを取得し、クライアントコンポーネントを定義し、そのデータをpropsとしてレンダリングした結果を返します。クライアントコンポーネントはハイドレートされ、完全にインタラクティブになります。このパターンは、モジュールレベルのディレクティブでは不可能です。
+
+### トップレベル`"use client"`ファイルとインラインのサーバーアクション
+
+```jsx
+"use client";
+
+import { useState, useTransition } from "react";
+
+export default function TodoApp() {
+ const [items, setItems] = useState([]);
+ const [, startTransition] = useTransition();
+
+ async function addItem(text) {
+ "use server";
+ return { id: Date.now(), text };
+ }
+
+ return (
+
+
+
+ {items.map(item => - {item.text}
)}
+
+