Review and improve Japanese manual expressions

manuals/1.0/en/05-metamorphosis-patterns.md

@@ -91,7 +91,7 @@ Like UNIX pipes that combine simple commands to create powerful systems, Be Fram
 cat access.log | grep "404" | awk '{print $7}' | sort | uniq -c
 ```
 
-In UNIX, the shell controls the pipeline. In Be Framework, objects declare their own destiny with `#[Be()]`. There is no external control such as controllers or orchestrators.
+In UNIX, the shell controls the pipeline. In Be Framework, objects declare their own destiny with `#[Be()]`—no controller or orchestrator controls the flow.
 
 Heraclitus said "the flowing is the river." Just as it is not that a river flows, but that the flowing itself is the river, domains in the Be Framework are temporal existence that never rest until they reach their end.
 

manuals/1.0/en/12-philosophy-behind.md

@@ -104,8 +104,6 @@ function processUser(ValidatedUser $user) {
 
 The idea: rather than handling errors, make certain errors impossible to represent.
 
-Sartre wrote "Existence precedes essence"—we exist first, then define ourselves. In Be Framework: Existence precedes action—what you ARE determines what you CAN DO.
-
 ---
 
 ## 4. Heraclitus: Everything Flows

manuals/1.0/ja/01-overview.md

@@ -36,7 +36,7 @@ $user->save();
 $user->notify();
 ```
 
-BeフレームワークはBEING（何であるか）に着目します：
+Be FrameworkはBEING（何であるか）に着目します：
 ```php
 $userInput = new UserInput($name, $email);
 $validatedUser = new ValidatedUser($userInput);
@@ -63,27 +63,27 @@ BEINGに着目すると：
 // 従来型：汎用的な型
 function processUser(User $user) { }
 
-// Beフレームワーク：特定の存在状態
+// Be Framework：特定の存在状態
 function processUser(ValidatedUser $user) { }
 function saveUser(SavedUser $user) { }
 function archiveUser(DeletedUser $user) { }
 ```
 
-各型はただのデータではなく、オブジェクトの特定の状態を表現しています。つまり、オブジェクトの時間的な変化が型で表されていて、その時に可能なことだけが行えます。例えば、存在しないオブジェクトに削除を命じることはできません。
+各型はただのデータではなく、オブジェクトの特定の状態を表しています。時間的な変化が型で表されるので、その時点で可能な操作だけが行えます。たとえば、削除済みのオブジェクトにさらに削除を命じることはできません。
 
 ## なぜ「コントローラー」ではないのか？
 
-従来のMVCフレームワークにおける「コントローラー (Controller)」は、その名の通り「制御・支配」を目的としています。 しかし、システムが複雑になるにつれて、この「全てを支配しようとするアプローチ」は困難になります。
+従来のMVCフレームワークでは、コントローラーがアプリケーション全体の流れを制御します。しかし、システムが複雑になるにつれて、この「全てを制御しようとするアプローチ」は困難になります。
 
-コントローラーは全てのモデルやコンポーネントに無制限にアクセスできる「全能の自由」を持っていますが、制約がないということは、逆に言えばシステム内のあらゆる手続きについて、自分自身で制御し整合性を保つという「無限の責任」を負うことを意味します。
+コントローラーは全てのモデルやコンポーネントに無制限にアクセスできる「全能の自由」を持っています。しかし制約がないということは、システム内のあらゆる手続きの整合性を自分で保つという「無限の責任」を負うことを意味します。
 
-Be Frameworkは異なるアプローチを採ります。操作が目的のデータをつくり出すのではなく、種子のような単純な入力オブジェクトが他のオブジェクトと出会い、自然に成長し、目的の最終オブジェクトへと「自ら変容（Metamorphosis）」していきます。
+Be Frameworkは異なるアプローチを採ります。操作が目的のデータをつくり出すのではなく、種子のような単純な入力オブジェクトが他のオブジェクトと出会い、自然に成長し、最終オブジェクトへと自ら変容していきます。
 
 ### Commander (司令官) から Gardener (庭師) へ:
-* 司令官は、部下（オブジェクト）に「動け」と命令します。しかし、複雑な自律的な動きを全て命令し続けることは不可能です。
+* 司令官は部下（オブジェクト）に「動け」と命令します。しかし、システムが複雑になるほど、すべてを命令で制御し続けるのは困難です。
 * 庭師は、植物に命令しません。ただ、水や光という環境を整えるだけです。
 
-植物は、自らの変容のみに関心を持ちます。他者を変えようとするのではなく、環境を受け入れて自らを自律的に変容（Metamorphosis）させ、在るべき姿に成ります。Beフレームワークも最初に入力を与えると、自らが最終オブジェクトになるような環境を整えます。制御を手放し、自律的な変容に委ねる。これがBe Frameworkのコアコンセプトです。
+植物は他者を変えようとせず、環境を受け入れて自らを変容させ、あるべき姿に成ります。Be Frameworkも同じです。入力を与えると、自らが最終オブジェクトになるような環境を整えます。制御を手放し、自律的な変容に委ねる。これがBe Frameworkのコアコンセプトです。
 
 ## このマニュアルで学べること
 

manuals/1.0/ja/02-input-classes.md

@@ -13,9 +13,9 @@ permalink: /manuals/1.0/ja/02-input-classes.html
 
 ## 出発点
 
-入力クラスは、Beフレームワークにおけるすべての変容の出発点です。
+入力クラスは、Be Frameworkにおけるすべての変容の出発点です。
 
-ここにはオブジェクト自身が持つ要素だけが含まれ、外部依存がありません。いわばオブジェクトのアイデンティティです。オブジェクトの内側にあるものなので、これを**内在（Immanence）**と呼びます。
+入力クラスにはオブジェクト自身が持つ要素だけが含まれ、外部依存がありません。これがオブジェクトの本質的な属性です。オブジェクトの内側にあるものなので、これを**内在（Immanence）**と呼びます。
 
 ## 基本構造
 
@@ -32,7 +32,7 @@ final readonly class UserInput
 
 ## 主要な特徴
 
-**純粋なアイデンティティ**: 入力クラスはオブジェクトが根本的に*何であるか*のみを含みます—外部依存関係や複雑なロジックはありません。
+**純粋なアイデンティティ**: 入力クラスはオブジェクトが*何であるか*だけを含みます。外部依存や複雑なロジックはありません。
 
 **ユースケースの起点**: すべてのユースケースは固有の入力クラスを持ちます。
 

manuals/1.0/ja/03-being-classes.md

@@ -15,7 +15,9 @@ permalink: /manuals/1.0/ja/03-being-classes.html
 
 入力クラスが「始まり」なら、存在クラスは「変容した存在」を表現します。
 
-入力クラスのpublicプロパティが存在クラスのコンストラクタに引き継がれます。その引き継いだ値は**内在（Immanence）** と呼ばれます。変容しながらアイデンティティを保ちます。コンストラクタでは外部から提供される力—**超越（Transcendence）**がインジェクトされ**内在**を変容します。
+入力クラスのpublicプロパティは、存在クラスのコンストラクタに引き継がれます。この引き継がれた値を**内在（Immanence）**と呼びます。内在はオブジェクトのアイデンティティであり、変容を経ても保たれます。
+
+コンストラクタには外部から**超越（Transcendence）**もインジェクトされます。超越は内在と出会い、新しい内在へと変容させます。
 
 ## 基本構造
 
@@ -39,7 +41,7 @@ final readonly class ValidatedUser
 
 ## 時間的存在としてのオブジェクト
 
-Be Frameworkにおいて、オブジェクトは静的なデータ構造ではなく、特定の時間の中でのみ存在する時間的存在として扱われます。
+Be Frameworkでは、オブジェクトを静的なデータ構造ではなく、特定の時間の中でのみ存在する時間的な存在として捉えます。
 
 ### 誕生
 
@@ -51,13 +53,13 @@ Be Frameworkにおいて、オブジェクトは静的なデータ構造では
 
 ### 生
 
-オブジェクトは `public readonly` プロパティとして、その「あるべき姿」を世界に晒します。しかしそのプロパティを触るものはいません。生まれた直後に次のオブジェクトのために消滅するからです。
+オブジェクトは `public readonly` プロパティとして、その「あるべき姿」を世界に晒します。しかし、そのプロパティが参照されることはありません。生まれた直後に、次のオブジェクトへ引き継がれて消滅するからです。
 
 ### なりたい自分になる
 
 すべての変容は、最終的な「なりたい自分、なるべき自分（Final Object）」になるための旅です。
 
-出会った超越は、新しい内在に影響を与えて消滅します。幼少期の友人のように、私を形作り私の一部にはなりますが、その時だけの時間的存在として、もうそこにはいなくなります。
+出会った超越は、新しい内在に影響を与えて消滅します。幼少期の友人のように、オブジェクトを形作りその一部となりますが、その時だけの存在として、やがて消えていきます。
 
 ## 変容の例
 
@@ -85,11 +87,11 @@ final readonly class OrderCalculation
 
 ## 変容についての考察
 
-内在だけでは変われません。データがどれほど豊かでも、それ自身の力で新しい存在にはなれないのです。変容には必ず超越—自分の外にある力—との出会いが必要です。そして出会った超越は内在を変え、自らは消えていきます。この「出会い、変わり、消える」というパターンは、コードに限った話ではありません。小麦粉はイーストと熱に出会ってパンになり、ぶどうは酵母と時間に出会ってワインになり、種は土と水と光に出会って花になります。あらゆるドメインの変容がこのパターンに従います。
+内在だけでは変われません。データがどれほど豊かでも、それ自身の力で新しい存在にはなれないのです。変容には必ず超越—自分の外にある力—との出会いが必要です。そして出会った超越は内在を変え、自らは消えていきます。この「出会い、変わり、消える」というパターンは、コードに限った話ではありません。小麦粉はイーストと熱に出会ってパンになります。ぶどうは酵母と時間に出会ってワインになります。種は土と水と光に出会って花になります。あらゆるドメインの変容がこのパターンに従います。
 
 ## 自然な流れ
 
-存在クラスは何かを「する」のではありません。自分が持つもの（内在）と、外部から与えられる力（超越）が出会うことで、自然にあるべき姿へと変容します。この流れを指揮するものはいません。各オブジェクトはただ次の存在に渡されるだけです。
+存在クラスは何かを「する」わけではありません。自分が持つもの（内在）と、外部から与えられる力（超越）が出会うことで、自然にあるべき姿へと変容します。この流れを指揮するものはいません。各オブジェクトはただ次の存在に渡されるだけです。
 
 ---
 

manuals/1.0/ja/04-final-objects.md

@@ -50,7 +50,7 @@ final readonly class SuccessfulOrder
 }
 ```
 
-入力クラスとは対照的に、最終オブジェクトはドメインの豊かさを完全に表現した存在です。内在が超越と出会い、変容を経て、これ以上変わる必要のない完全な状態に達しています。成功も失敗も同じ構造です。`FailedOrder`も`BeenRejected`という`$been`を持ちます。
+入力クラスとは対照的に、最終オブジェクトはドメインの豊かさを完全に表現した存在です。内在が超越と出会い、変容を経て、これ以上変わる必要のない完全な状態に達しています。成功も失敗も同じ構造です。たとえば`FailedOrder`も、拒否の証跡として`$been`を持ちます。
 
 ## 時間的存在の完全性
 
@@ -59,7 +59,7 @@ Be Frameworkでは、オブジェクトの時間的存在を二つの軸で捉
 - **`#[Be]`**: なりたい自分、向かう先（未来への方向性）
 - **`$been`**: 完了した自分（過去完了の証跡）
 
-`$orderId`や`$confirmationCode`といった本質的な値はpublicプロパティです。`$been`はそれとは異なり、いつ・誰が・何を根拠に完了したかという完了の証跡を記録します。
+`$orderId`や`$confirmationCode`はビジネス上の本質的な値です。一方`$been`は、いつ・誰が・何を根拠に完了したかという証跡を記録します。
 
 ## 内側からの完全性
 

manuals/1.0/ja/04a-becoming.md

@@ -19,7 +19,7 @@ permalink: /manuals/1.0/ja/04a-becoming.html
 $finalObject = $becoming(new EmailInput($name, $email));
 ```
 
-`EmailInput` → `EmailValidation` → `UserCreation` → `WelcomeMessage`。各クラスの`#[Be()]`宣言に従い、チェーン全体が自動的に実行されます。各オブジェクトは生まれた瞬間に次の存在へと引き継がれ、消滅します。存在が無になり、無から次の存在が生まれる——この運動がチェーンの終端まで続きます。
+`EmailInput` → `EmailValidation` → `UserCreation` → `WelcomeMessage`。各クラスの`#[Be()]`宣言に従い、チェーン全体が自動的に実行されます。各オブジェクトは次のオブジェクトを生み出すと消滅し、この連鎖が終端まで続きます。
 
 ## Becomingの取得
 

manuals/1.0/ja/05-metamorphosis-patterns.md

@@ -13,7 +13,7 @@ permalink: /manuals/1.0/ja/05-metamorphosis.html
 
 ## 時間とドメインは分割できない
 
-アインシュタインが時間と空間の不可分性を発見したように、Beフレームワークでは時間とドメインは分割できない一つの実体です。承認プロセスには承認の時間が、決済には決済の時間があり、それぞれのドメインロジックが持つ固有の時間軸に沿って変容が自然に現れます。
+アインシュタインが時間と空間の不可分性を発見したように、Be Frameworkでは時間とドメインは分割できない一つの実体です。承認プロセスには承認の時間が、決済には決済の時間があり、それぞれのドメインロジックが持つ固有の時間軸に沿って変容が自然に現れます。
 
 ## 不可逆的時間の流れ
 
@@ -64,7 +64,7 @@ final readonly class ApplicationReview
 
 ## 型による継続
 
-`#[Be()]`で指定された候補クラスの中から、現在のオブジェクトのpublicプロパティの型がコンストラクタの`#[Input]`引数にマッチするクラスが自動的に選択されます：
+次の変容先は自動的に選択されます。具体的には、`#[Be()]`で指定された候補クラスのうち、現在のオブジェクトのpublicプロパティの型と`#[Input]`引数の型が一致するクラスが選ばれます：
 
 ```php
 // ApplicationReviewのプロパティがApprovedApplication型なら
@@ -84,16 +84,16 @@ final readonly class ApprovalNotification
 
 ## 自己組織化パイプライン
 
-Unixパイプが単純なコマンドを組み合わせて強力なシステムを作るように、Beフレームワークは型付きオブジェクトを組み合わせて自然な変容の流れを作ります。
+Unixパイプが単純なコマンドを組み合わせて強力なシステムを作るように、Be Frameworkは型付きオブジェクトを組み合わせて自然な変容の流れを作ります。
 
 ```bash
 # Unix: テキストが流れる外部制御のパイプライン
 cat access.log | grep "404" | awk '{print $7}' | sort | uniq -c
 ```
 
-Unixではshellがパイプを制御しますが、Beフレームワークではオブジェクト自身が`#[Be()]`で運命を宣言します。コントローラーもオーケストレーターといった、外部の制御が存在しません。
+Unixではshellがパイプを制御しますが、Be Frameworkではオブジェクト自身が`#[Be()]`で運命を宣言します。コントローラーやオーケストレーターのような外部の制御は存在しません。
 
-ヘラクレイトスは「流れているのが川だ」と言いました。川が流れるのではなく、流れそのものが川であるように、Beフレームワークのドメインは終端まで静止することがない時間的存在です。
+ヘラクレイトスは「流れているのが川だ」と言いました。川が流れるのではなく、流れそのものが川であるように、Be Frameworkのドメインは、終端に至るまで流れ続ける時間的存在です。
 
 ---
 

manuals/1.0/ja/06-semantic-variables.md

@@ -33,9 +33,9 @@ public function __construct(string $email) {}
 
 一度定義すれば、`$email`という名前のすべてのコンストラクタ引数に自動的に適用されます。`$email`の値が正しいのは偶然ではなく、必然です。正しくなれないものは存在できません。
 
-## 名前の装飾
+## 属性による制約の拡張
 
-同じ名前に属性を加えることで、存在条件をより精密にできます。`#[Validate]`メソッドに属性が付いている場合、コンストラクタ引数の属性とマッチしたときだけ実行されます：
+同じ名前に属性を加えることで、存在条件をより精密にできます。`#[Validate]`属性が付いたメソッドでは、メソッド引数に属性（例: `#[Teen]`）が指定されていると、コンストラクタ側に同じ属性があるときだけ実行されます：
 
 ```php
 // $ageの基本制約（0-150歳）
@@ -72,7 +72,7 @@ public function __construct(#[Teen] int $age) {}
 
 ## 名前が関係を持つ
 
-意味変数は単独の制約だけでなく、変数間の関係も制約として持ちます。`#[Validate]`メソッドの引数名がコンストラクタの引数名と部分マッチすると、対応する値が自動的に渡されます：
+意味変数は単独の制約だけでなく、変数間の関係も制約として持ちます。`#[Validate]`属性が付いたメソッドの引数名がコンストラクタの引数名と部分一致すると、対応する値が自動的に渡されます：
 
 ```php
 // フォーマット検証 — メールアドレスの一致確認