diff --git a/_includes/manuals/1.0/en/contents.html b/_includes/manuals/1.0/en/contents.html
index 77626a0..24d7c7b 100644
--- a/_includes/manuals/1.0/en/contents.html
+++ b/_includes/manuals/1.0/en/contents.html
@@ -18,7 +18,7 @@
         <ul class="navbar-nav mr-auto">
             {% assign en_pages = site.pages | where: "layout", "docs-en" | where: "category", "Manual" | sort: "path" %}
             {% for item in en_pages %}
-            {% unless item.path contains "/index.md" or item.path contains "/convention/" %}
+            {% unless item.path contains "/index.md" or item.path contains "/convention/" or item.path contains "12-philosophy-behind.md" %}
             {% assign item_link = item.permalink | default: item.url %}
             <li class="nav-item">
                 <a class="nav-link {% if page.permalink == item_link %}active{% endif %}"
diff --git a/_includes/manuals/1.0/ja/contents.html b/_includes/manuals/1.0/ja/contents.html
index 7588b88..361448c 100644
--- a/_includes/manuals/1.0/ja/contents.html
+++ b/_includes/manuals/1.0/ja/contents.html
@@ -18,7 +18,7 @@
         <ul class="navbar-nav mr-auto">
             {% assign ja_pages = site.pages | where: "layout", "docs-ja" | where: "category", "Manual" | sort: "path" %}
             {% for item in ja_pages %}
-            {% unless item.path contains "/index.md" or item.path contains "/convention/" %}
+            {% unless item.path contains "/index.md" or item.path contains "/convention/" or item.path contains "12-philosophy-behind.md" %}
             {% assign item_link = item.permalink | default: item.url %}
             <li class="nav-item">
                 <a class="nav-link {% if page.permalink == item_link %}active{% endif %}"
diff --git a/manuals/1.0/en/11-reference-resources.md b/manuals/1.0/en/11-reference-resources.md
index 7d3c959..8269b55 100644
--- a/manuals/1.0/en/11-reference-resources.md
+++ b/manuals/1.0/en/11-reference-resources.md
@@ -1,6 +1,6 @@
 ---
 layout: docs-en
-title: "11. PR"
+title: "11. Reference"
 category: Manual
 permalink: /manuals/1.0/en/11-reference-resources.html
 ---
diff --git a/manuals/1.0/en/12-philosophy-behind.md b/manuals/1.0/en/12-philosophy-behind.md
index c7e5010..75a635a 100644
--- a/manuals/1.0/en/12-philosophy-behind.md
+++ b/manuals/1.0/en/12-philosophy-behind.md
@@ -1,7 +1,7 @@
 ---
 layout: docs-en
 title: "12. The Philosophy Behind"
-category: Philosophy
+category: Manual
 permalink: /manuals/1.0/en/12-philosophy-behind.html
 ---
 
diff --git a/manuals/1.0/en/faq.md b/manuals/1.0/en/faq.md
new file mode 100644
index 0000000..7a8304b
--- /dev/null
+++ b/manuals/1.0/en/faq.md
@@ -0,0 +1,222 @@
+---
+layout: docs-en
+title: "FAQ"
+category: Manual
+permalink: /manuals/1.0/en/faq.html
+---
+
+# Be Framework FAQ
+
+> Last updated: 2025-09-13
+
+## 0) TL;DR
+
+### Q. Is this a new "programming paradigm"?A. Yes. Be Framework proposes BE-oriented programming ("Whether?" = can this state exist?) in contrast to traditional DO-oriented approaches (Imperative = "How?", OOP = "Who?", FP = "What?").
+
+It makes temporal existence first-class citizens and designs based on "what something is" rather than "what it does." While it's a significant paradigm shift philosophically, implementation-wise it coexists with OOP/FP/DDD and doesn't require replacing existing styles.
+
+---
+
+## 1) Paradigm & Concepts
+
+### Q1. How is this different from MVC or DDD?**  
+A. MVC is a structural pattern for responsibility separation, DDD is a modeling methodology.  
+Be Framework is a design paradigm centered on "existence conditions and temporal transformation," where flow self-organizes through `#[Be]` and `$being`.
+
+### Q2. Is this OOP or FP?**  
+A. It works with both. It emphasizes immutability and referential transparency while realizing one-time complete transformation in constructors (entelecheia) using OOP containers.
+
+### Q3. What's the benefit of defining "BEING (what something is)" first?**  
+A. It makes invalid states impossible to generate upfront (drastically reducing defensive if/guard statements).  
+Type = reachable state becomes API specification.
+
+### Q4. What does "type = temporal state" mean?**  
+A. Types like `ValidatedUser`, `SavedUser`, `DeletedUser` express the "when" in progress.  
+Time and domain are inseparable (details: [Metamorphosis](./05-metamorphosis.html)).
+
+---
+
+## 2) Core Features
+
+### Q5. What does `#[Be]` do?**  
+A. It declares destiny (what to become next).  
+Given single/multiple candidates, the continuation is automatically selected at runtime by the type of `$being`.  
+(Reference: [Type-Driven Metamorphosis](./07-type-driven-metamorphosis.html))
+
+### Q6. What's the role of the `$being` property?A. It holds the next existence that the current existence leads to. Union types explicitly show all possibilities of results.
+
+### Q6.5. Are `$being` and `$been` specially treated properties?A. No. These are not magically interpreted by the framework—they are mere conventions.
+
+`becoming()` doesn't read property names, but looks at the types declared on properties to select the next class.
+
+Therefore, the names `$being` / `$been` are not required. `public Success|Failure $result;` works the same way with different names.
+
+However, using these names according to documentation, samples, and design philosophy provides the benefit of immediately recognizing "transformation destination (being)" and "completion evidence (been)".
+
+### Q7. How is the metamorphosis chain controlled?
+
+A. Through the chain of `#[Be]` attributes, the next transformation is automatically determined.
+
+When multiple transformation destinations are possible, they are expressed as union types in the `$being` property, and the next transformation destination is determined by the type actually assigned. This mechanism allows complex business logic to be expressed declaratively.
+
+### Q8. What are "Semantic Variables"?**  
+A. Variable name = meaning + constraints. `$email` must be a "valid Email" to exist.  
+It integrates into types validations that tend to scatter (controller/validator/docs).  
+([Semantic Variables](./06-semantic-variables.html))
+
+### Q8.5. How do you handle variables with different meanings but same constraints (`$userId`, `$authorId`, etc.)?A. Share constraints through common base classes or traits while separating meaning through inheritance.
+
+```php
+// src/Semantic/Abstract/Id.php - Common constraint base class
+namespace App\Semantic\Abstract;
+
+abstract readonly class Id {
+    public function __construct(public string $value) {
+        if (!preg_match('/^[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}/', $value)) {
+            throw new InvalidIdException();
+        }
+    }
+}
+
+// src/Semantic/UserId.php - Semantic variables through inheritance
+readonly class UserId extends \App\Semantic\Abstract\Id {}
+readonly class AuthorId extends \App\Semantic\Abstract\Id {}
+
+// Usage: variable names carry semantic meaning
+function updateArticle(UserId $userId, AuthorId $authorId) {
+    // $userId and $authorId cannot be confused
+}
+```
+
+### Q9. What is the "Reason Layer"?**  
+A. It injects **the foundation = tool set** that enables a certain existence state as objects.  
+It **bundles related tools meaningfully** from traditional individual DI, improving testability.  
+([Reason Layer](./08-reason-layer.html))
+
+### Q10. What is `$been` (self-proof) for?**  
+A. It **internally contains** the trail of that existence's **completion** (who, when, what).  
+It aligns well with external tests and audit logs.  
+([Final Objects](./04-final-objects.html))
+
+---
+
+## 3) Design & Implementation
+
+### Q11. Where do side effects occur?A. Principally **completed by delegating to Reason within constructors**. This eliminates the need for external orchestrators and huge service layers.
+
+### Q12. How are exceptions handled?A. Using **semantic exceptions** that hold failures as collections (supporting multilingual messages). "Partial success/partial failure" can also be expressed as **valid existence** of **Invalid~**. ([Error Handling](./09-error-handling.html))
+
+### Q13. What's the testing strategy?
+
+A. Verify each existence (type) individually. Preconditions = `#[Input]`, postconditions = `public` properties. Use cases can be kept sufficiently thin with `#[Be]` chain smoke tests.
+
+### Q15. When to choose "linear," "branching," or "nested"?
+A. Procedure-dependent = **linear** / Results exclusive by conditions = **branching** / Convergence of independent processes = **nested**. When in doubt, start with **minimal linear**. ([Implementation Guidelines](./05-metamorphosis.html))
+
+---
+
+## 4) Integration with Existing Assets
+
+### Q16. Can this be introduced to existing MVC apps?A. Yes. Replace the **Use Case layer** with Be, and just call `becoming(new …Input)` from Controllers. Gradually organize into **immanent/transcendent**.
+
+### Q17. Where do you use DB or external APIs?A. In **Reason**. Storage and transmission means are consolidated in Reason, **separated** from existence (state) definition.
+
+### Q18. Framework dependencies?A. Core uses PHP standard + DI (e.g., Ray.Di). Integration with Laravel/Symfony etc. is possible via **adapters**.
+
+### Q19. Do static analysis and IDE completion work?A. **Very well** since types are "states." Branching is made explicit with union types, and completion is safe too.
+
+---
+
+## 5) Operations, Logging & Auditing
+
+### Q20. How are logs recorded?A. **Semantic logging** is recommended (Koriym.SemanticLogger integration). Record transformation (from/to/reason/evidence) as **structured JSON**. ([Semantic Logging](./10-semantic-logging.html))
+
+### Q21. Audit compliance?A. `$been` (self-proof) + semantic logging can provide **complete audit trails**. Personal information follows **minimum privilege** principles at the Reason layer.
+
+---
+
+## 7) Migration
+
+### Q24. Migration steps for existing code? (Minimal steps)
+1. Choose one representative use case
+2. Extract input as `…Input` (immanent only)
+3. Design transformation target as `…` (existence), add `#[Be]`
+4. Consolidate external dependencies into Reason
+5. Call `becoming(new …Input)` from Controller
+6. Migrate validation to semantic variables / replace exceptions semantically
+7. Introduce semantic logging
+
+---
+
+## 8) Future Features
+
+### Q25. What about `#[Accept]` (Extended Decision Making)?A. Conceptual stage. Plans to **delegate undeterminable decisions to experts or AI**, handling certainty and uncertainty in one framework. ([Type-Driven Metamorphosis](./07-type-driven-metamorphosis.html) end note)
+
+---
+
+## 9) Examples & Snippets
+
+### Q26. Minimal example of typical flow?
+```php
+// 1) Input (immanent only)
+#[Be(UserProfile::class)]
+final readonly class UserInput {
+    public function __construct(public string $name, public string $email) {}
+}
+
+// 2) Being (moment of transformation)
+final readonly class UserProfile {
+    public function __construct(
+        #[Input] string $name,
+        #[Input] string $email,
+        #[Inject] NameFormatter $fmt,
+        #[Inject] EmailValidator $v
+    ) {
+        $this->display = $fmt->format($name);
+        $this->isValid = $v->validate($email);
+    }
+    public string $display;
+    public bool $isValid;
+}
+
+// 3) Execution (self-organization)
+$profile = $becoming(new UserInput($name, $email));
+
+// Result: UserProfile object
+// $profile->display: "Formatted name"
+// $profile->isValid: true (for valid email)
+```
+
+---
+
+## 10) Detailed Term Explanations
+
+### Being-oriented / Ontological
+A design philosophy that treats existence possibility and time as primary abstractions. It's a way of thinking that centers on "what can exist" rather than the traditional "what to do," understanding program states as temporal existence.
+
+### Immanence / Transcendence
+Immanence refers to the intrinsic properties and information that an object naturally possesses. Transcendence refers to capabilities and information provided by the external environment or dependencies. In Be Framework, new existence emerges from the combination of these two.
+
+### Entelecheia
+A concept derived from Aristotelian philosophy, representing the "moment of transformation" when potentiality moves to actuality. In Be Framework, it refers to the moment when immanence and transcendence meet in the constructor to complete a new existence.
+
+### Reason Layer
+An aggregation of the foundation and tool set necessary for establishing a certain existence state as objects. It enhances testability and maintainability by meaningfully bundling traditional DI (Dependency Injection).
+
+### Semantic Variables
+A concept where variable names themselves express meaning and constraints. For example, `$validEmail` expresses the constraint that it must be a "valid Email" to exist, integrating scattered validation logic at the type level.
+
+### Semantic Exceptions / Semantic Logging
+A mechanism for holding failures and history not as simple strings, but as structured data with meaning. It supports multilingual compatibility and audit requirements, making system behavior traceable at the semantic level.
+
+---
+
+## 11) Related Chapter Links
+
+* **[Overview](./01-overview.html)**: First encounter with being-oriented programming
+* **[Metamorphosis](./05-metamorphosis.html)**: Inseparability of time and domain
+* **[Semantic Variables](./06-semantic-variables.html)**: Domain-specific validation and type safety
+* **[Type-Driven Metamorphosis](./07-type-driven-metamorphosis.html)**: Self-determining objects
+* **[Reason Layer](./08-reason-layer.html)**: Raison d'être and object existence foundations
+* **[Error Handling](./09-error-handling.html)**: Semantic exceptions and multilingual messages
+* **[Semantic Logging](./10-semantic-logging.html)**: Structured recording and audit trails
diff --git a/manuals/1.0/en/index.md b/manuals/1.0/en/index.md
index f4301a9..d41ae9b 100644
--- a/manuals/1.0/en/index.md
+++ b/manuals/1.0/en/index.md
@@ -42,6 +42,9 @@ Structured recording and audit trails of object metamorphosis
 ## [11. Reference](./11-reference-resources.html)
 Essential resources and links for framework development
 
+## [FAQ](./faq.html)
+Frequently asked questions and answers
+
 ---
 
 *"Be, Don't Do"*
\ No newline at end of file
diff --git a/manuals/1.0/ja/12-philosophy-behind.md b/manuals/1.0/ja/12-philosophy-behind.md
index 7449ee0..9133ab5 100644
--- a/manuals/1.0/ja/12-philosophy-behind.md
+++ b/manuals/1.0/ja/12-philosophy-behind.md
@@ -1,7 +1,7 @@
 ---
 layout: docs-ja
 title: "12. 背後にある哲学"
-category: Philosophy
+category: Manual
 permalink: /manuals/1.0/ja/12-philosophy-behind.html
 ---
 
diff --git a/manuals/1.0/ja/faq.md b/manuals/1.0/ja/faq.md
new file mode 100644
index 0000000..06dc1b8
--- /dev/null
+++ b/manuals/1.0/ja/faq.md
@@ -0,0 +1,307 @@
+---
+layout: docs-ja
+title: "FAQ"
+category: Manual
+permalink: /manuals/1.0/ja/faq.html
+---
+
+# Be Framework FAQ
+
+> 最終更新: 2025-09-13
+
+## 0) 要旨（TL;DR）
+
+### Q. これは新しい"プログラミングパラダイム"ですか？
+
+A. はい。Be Frameworkは、 時間的存在を一次市民に据え、「何をするか」ではなく「何であるか」に基づいて設計します。
+
+思想面では大きなパラダイム転換ですが、実装面ではOOP/FP/DDDと共存可能で、既存スタイルを置き換える必要はありません。
+
+---
+
+## 1) パラダイム & 概念
+
+### Q1. MVCやDDDとどう違いますか？
+
+A. MVCは責務分割の構造パターン、DDDはモデリングの方法論です。
+
+Be Frameworkは「存在条件と時間的変容」を中核に据える設計パラダイムで、`#[Be]`と`$being`によりフローが自己組織化されます。
+
+### Q2. OOP/FPのどちらですか？
+
+A. どちらの要素もあります。
+
+不変性・参照透明性を重視しながら、コンストラクタでの一回完結の変容（エンテレケイア）をOOPの枠組みで実現しています。
+
+### Q3. 「BEING（何であるか）」を先に定義する利点は？
+
+A. 不正状態を事前に生成不能にできます。
+
+防御的なif/guard文が激減し、型＝到達可能状態がAPI仕様となります。
+
+### Q4. 「時間的存在の型」とは何ですか？
+
+A. `ValidatedUser`、`SavedUser`、`DeletedUser`など、進行中の特定の時を型名で表現しています。
+
+Be Frameworkは時間とドメインは不可分と考えます。詳細は[メタモルフォーシス](./05-metamorphosis.html)をご覧ください。
+
+---
+
+## 2) 主要機能
+
+### Q5. `#[Be]`属性は何をしますか？
+
+A. オブジェクトの運命（次に何になるか）を宣言します。
+
+単一または複数の変容候補を指定し、実行時に`$being`プロパティの型で継続先が自動選択されます。
+
+詳しくは[型駆動変容](./07-type-driven-metamorphosis.html)をご参照ください。
+
+### Q6. `$being`プロパティの役割は何ですか？
+
+A. 現在の存在が導く次の存在を保持します。
+
+ユニオン型を使用することで、結果の全可能性を明示しています。
+
+### Q6.5. `$being`や`$been`は特別なプロパティですか？
+
+A. いいえ、特別なプロパティではありません。
+
+これらはフレームワークが魔法的に解釈するものではなく、**単なる規約**です。
+
+`becoming()`関数はプロパティ名を読むのではなく、**プロパティに宣言された型**を見て次のクラスを選択します。
+
+そのため、`$being`や`$been`という名前である必要はありません。`public Success|Failure $result;`のように別の名前でも同じように動作します。
+
+ただし、ドキュメント・サンプル・設計思想に合わせてこの名前を使用することで、「変容先（being）」「完了の証跡（been）」が一目で分かるというメリットがあります。
+
+### Q7. 変容の連鎖はどのように制御されますか？
+
+A. `#[Be]`属性の連鎖により、自動的に次の変容が決定されます。
+
+複数の変容先が可能な場合は、`$being`プロパティのユニオン型で表現し、実際に代入された型によって次の変容先が決まります。この仕組みにより、複雑なビジネスロジックも宣言的に表現できます。
+
+### Q8. 「意味変数」とは何ですか？
+
+A. 変数名＝意味＋制約です。`$email`は「有効なEmail」でなければ存在できません。
+
+分散しがちな検証（controller/validator/docs）を型に統合します。
+
+（詳細：[意味変数](./06-semantic-variables.html)）
+
+### Q8.5. 意味は違うが制約が同じ変数（`$userId`、`$authorId`など）はどう扱いますか？
+
+A. 共通の基底クラスやトレイトで制約を共有し、継承で意味を分離します。
+
+```php
+// src/Semantic/Abstract/Id.php - 共通制約を持つ基底クラス
+namespace App\Semantic\Abstract;
+
+abstract readonly class Id {
+    public function __construct(public string $value) {
+        if (!preg_match('/^[0-9a-f]{8}-[0-9a-f]{4}-4[0-9a-f]{3}/', $value)) {
+            throw new InvalidIdException();
+        }
+    }
+}
+
+// src/Semantic/UserId.php - 意味変数として継承
+readonly class UserId extends \App\Semantic\Abstract\Id {}
+readonly class AuthorId extends \App\Semantic\Abstract\Id {}
+
+// 使用例：変数名に意味が込められる
+function updateArticle(UserId $userId, AuthorId $authorId) {
+    // $userIdと$authorIdは混同不可能
+}
+```
+
+### Q9. 「存在理由層（Reason）」とは何ですか？
+
+A. ある存在状態を成立させる根拠＝道具一式をオブジェクトとして注入します。
+
+従来の個別DIを意味で束ねてテスト容易性を高めます。
+
+（詳細：[存在理由層](./08-reason-layer.html)）
+
+### Q10. `$been`（自己証明）は何のためですか？
+
+A. その存在が完了した証跡（誰が・いつ・何を）を内在させます。
+
+外部テストや監査ログと整合しやすくなります。
+
+（詳細：[最終オブジェクト](./04-final-objects.html)）
+
+---
+
+## 3) 設計・実装
+
+### Q11. どこで副作用を起こしますか？
+
+A. 原則としてコンストラクタの中でReasonに委譲して完結させます。
+
+外部オーケストレーターや巨大なservice層を不要にします。
+
+### Q12. 例外はどう扱いますか？
+
+A. 意味的例外を用いて、失敗を集合で保持します（多言語メッセージ対応）。
+
+「部分成功・部分失敗」もInvalid〜の"有効な存在"として表現できます。
+
+（詳細：[エラーハンドリング](./09-error-handling.html)）
+
+### Q13. テスト戦略は？
+
+A. 各存在（型）を単体で検証します。
+
+事前条件＝`#[Input]`、事後条件＝`public`プロパティ。ユースケースは`#[Be]`連鎖のスモークで十分に薄く保てます。
+
+DIコストはありますが、副作用の局在化とバグ削減で総合的にプラスになります。ホットパスはReason実装で最適化可能です。
+
+### Q15. いつ「線形」「分岐」「ネスト」を選びますか？
+
+A. 手順依存=線形／条件で結果が排他的=分岐／独立処理の合流=ネストです。
+
+迷ったら最小限の線形から始めることをお勧めします。
+
+（詳細：[実装指針](./05-metamorphosis.html)）
+
+---
+
+## 4) 既存資産との統合
+
+### Q16. 既存のMVCアプリに導入できますか？
+
+A. はい、可能です。UseCase層をBeで置き換えて、Controllerからは`becoming(new …Input)`を呼ぶことで実現できます。
+
+徐々に内在/超越へ整理していくことができますので、段階的な移行が可能です。
+
+### Q17. DBや外部APIはどこで使いますか？
+
+A. Reasonで。
+
+保存や送信の手段はReasonに集約し、存在（状態）定義と分離します。
+
+### Q19. 静的解析やIDE補完は効きますか？
+
+A. 型が"状態"なので効果的に効きます。
+
+ユニオン型で分岐が明示化され、補完も安全です。
+
+---
+
+## 5) 運用・ログ・監査
+
+### Q20. ログはどう残りますか？
+
+A. 従来のログと違い、実行全体が型づけされた意味的ログになります。
+
+変容（from/to/理由/証跡）を構造化JSONで記録します。
+
+（詳細：[意味的ログ](./10-semantic-logging.html)）
+
+### Q21. 監査対応はどうなりますか？
+
+A. `$been`（自己証明）＋意味的ログで完全な監査証跡を提供可能です。
+
+個人情報はReasonレイヤで最小権限を徹底します。
+
+---
+
+## 7) マイグレーション
+
+### Q24. 既存コードの移行手順は何ですか？（最小ステップ）
+
+A. 以下の手順をお勧めします：
+
+1. 代表ユースケースを1つ選びます
+2. 入力を`…Input`として抽出します（内在のみ）
+3. 変換先を`…`（存在）として設計し、`#[Be]`を付与します
+4. 外部依存をReasonに集約します
+5. Controllerから`becoming(new …Input)`を呼びます
+6. 意味変数へ検証を移管／例外を意味的に置換します
+7. 意味的ログを導入します
+
+---
+
+## 8) 将来機能
+
+### Q25. `#[Accept]`（拡張意思決定）はどのような機能ですか？
+
+A. 構想段階の機能です。
+
+確定できない判断を専門家やAIへ委譲し、確定性と不確実性を一つのフレームで扱う予定です。
+決定を第一級市民として外部から制御可能にします。
+
+（詳細：[型駆動変容](./07-type-driven-metamorphosis.html)末尾の注記）
+
+---
+
+## 9) 例とスニペット
+
+### Q26. 典型フローの最小例はどのようなものですか？
+
+A.
+
+```php
+// 1) 入力（内在のみ）
+#[Be(UserProfile::class)]
+final readonly class UserInput {
+    public function __construct(public string $name, public string $email) {}
+}
+
+// 2) 存在（変容の瞬間）
+final readonly class UserProfile {
+    public function __construct(
+        #[Input] string $name,
+        #[Input] string $email,
+        #[Inject] NameFormatter $fmt,
+        #[Inject] EmailValidator $v
+    ) {
+        $this->display = $fmt->format($name);
+        $this->isValid = $v->validate($email);
+    }
+    public string $display;
+    public bool $isValid;
+}
+
+// 3) 実行（自己組織化）
+$profile = $becoming(new UserInput($name, $email));
+
+// 結果: UserProfile オブジェクト
+// $profile->display: "フォーマット済みの名前"
+// $profile->isValid: true (有効なメールの場合)
+```
+
+---
+
+## 10) 重要用語の詳細解説
+
+### 存在指向 / Ontological（オントロジカル）
+存在可能性と時間を一次の抽象として扱う設計観念です。従来の「何をするか」ではなく「何が存在できるか」を中心に据えた思考法で、プログラムの状態を時間的な存在として捉えます。
+
+### イマナンス / トランセンデンス（内在 / 超越）
+イマナンス（内在）は、オブジェクトが本来持っている性質や情報を指します。トランセンデンス（超越）は、外部環境や依存関係から与えられる能力や情報を指します。Be Frameworkでは、この二つの組み合わせによって新しい存在が生まれます。
+
+### エンテレケイア（Entelecheia）
+アリストテレス哲学に由来する概念で、潜在性が現実性へ移行する「変容の瞬間」を表します。Be Frameworkでは、コンストラクタで内在と超越が出会って新しい存在が完成する瞬間を指します。
+
+### 存在理由層（Reason Layer）
+ある存在状態が成立するために必要な根拠や道具一式をオブジェクトとして集約したものです。従来のDI（依存注入）を意味でまとめて、テスト容易性と保守性を高めます。
+
+### 意味変数（Semantic Variables）
+変数名そのものが意味と制約を表現する概念です。例えば`$validEmail`は「有効なEmail」でなければ存在できないという制約を名前で表現し、分散しがちな検証ロジックを型レベルで統合します。
+
+### 意味的例外 / 意味的ログ
+失敗や履歴を単純な文字列ではなく、意味を持った構造化されたデータとして保持する仕組みです。多言語対応や監査要件に対応し、システムの動作を意味レベルで追跡可能にします。
+
+---
+
+## 11) 関連章へのリンク
+
+* **[概要](./01-overview.html)**: 存在指向プログラミングとの出会い
+* **[メタモルフォーシス](./05-metamorphosis.html)**: 時間とドメインの不可分性
+* **[意味変数](./06-semantic-variables.html)**: ドメイン固有の検証と型安全性
+* **[型駆動変容](./07-type-driven-metamorphosis.html)**: 自己決定オブジェクト
+* **[存在理由層](./08-reason-layer.html)**: オブジェクトの存在根拠
+* **[エラーハンドリング](./09-error-handling.html)**: 意味的例外と多言語メッセージ
+* **[意味的ログ](./10-semantic-logging.html)**: 構造化記録と監査証跡
diff --git a/manuals/1.0/ja/index.md b/manuals/1.0/ja/index.md
index 1da92fc..491eb89 100644
--- a/manuals/1.0/ja/index.md
+++ b/manuals/1.0/ja/index.md
@@ -41,6 +41,9 @@ permalink: /manuals/1.0/ja/
 ## [11. リファレンス](./11-reference-resources.html)
 フレームワーク開発に必要なリソースとリンク集
 
+## [FAQ](./faq.html)
+よくある質問と回答集
+
 ---
 
 > Be, Don't Do