Update theory content for JA

2026-04-29 14:57:42 +00:00 · 2026-04-10 01:06:19 +09:00
parent 22aa9dfb7f
commit a29d4a459f
12 changed files with 372 additions and 375 deletions
--- a/src/data/modules/m00-setup.js
+++ b/src/data/modules/m00-setup.js
@@ -2397,7 +2397,7 @@ main();`,
 Imagina que tienes esto en tu script:

 \`\`\`
-const wallet = Wallet.fromSeed("sEdV9mHTYLPKPPPfBGB9xpGnFxsQo4r", {algorithm: 'secp256k1'});
+const wallet = Wallet.fromSeed("sEdV9mHTYLPKPPPfBGB9xpGnFxsQo4r");
 \`\`\`

 Esto es **muy peligroso** por varias razones:
@@ -2480,7 +2480,7 @@ Esto protege tanto tus claves (\`.env\`) como las librerías descargadas (\`node
 Imagine you have this in your script:

 \`\`\`
-const wallet = Wallet.fromSeed("sEdV9mHTYLPKPPPfBGB9xpGnFxsQo4r", {algorithm: 'secp256k1'});
+const wallet = Wallet.fromSeed("sEdV9mHTYLPKPPPfBGB9xpGnFxsQo4r");
 \`\`\`

 This is **very dangerous** for several reasons:
@@ -2563,7 +2563,7 @@ This protects both your keys (\`.env\`) and the downloaded libraries (\`node_mod
 スクリプトに次のようなコードがあるとします:

 \`\`\`
-const wallet = Wallet.fromSeed("sEdV9mHTYLPKPPPfBGB9xpGnFxsQo4r", {algorithm: 'secp256k1'});
+const wallet = Wallet.fromSeed("sEdV9mHTYLPKPPPfBGB9xpGnFxsQo4r");
 \`\`\`

 これはいくつかの理由で**非常に危険**です:
@@ -2578,8 +2578,8 @@ const wallet = Wallet.fromSeed("sEdV9mHTYLPKPPPfBGB9xpGnFxsQo4r", {algorithm: 's
 \`.env\`ファイル（"environment"の略）は**環境変数**を保存するプレーンテキストファイルです。コードに必要だがソースコードにあるべきではない機密設定を格納します:

 \`\`\`
-WALLET_A_SEED=sEdVxxxテストネットのシード
-WALLET_B_SEED=sEdYyy別のテストネットのシード
+WALLET_A_SEED=sEdVxxxYourTestnetSeed
+WALLET_B_SEED=sEdYyyAnotherTestnetSeed
 XAHAU_NODE=wss://xahau-test.net
 \`\`\`

@@ -2589,7 +2589,7 @@ XAHAU_NODE=wss://xahau-test.net
 - **環境ごとに1つの.env**: テストネット用とメインネット用を別々に持てる
 - **引用符なし**（値にスペースがある場合を除く）: \`KEY=value\`
 - **\`=\`の前後にスペースなし**: \`KEY=value\`（正しい）vs \`KEY = value\`（誤り）
- **各変数は独立した行に**
+- **各変数は別々の行に**

 ### dotenvのインストール

@@ -2635,10 +2635,10 @@ node_modules/

 ### セキュリティへの影響

- **テストネット**: テストネットのシードが漏洩しても実際のお金は失いませんが、テストに干渉される可能性がある
- **メインネット**: メインネットのシードが漏洩すると、**すべての資金を不可逆的に失う可能性があります**。ブロックチェーンでは盗まれた資金を回収する方法がない
- **パブリックリポジトリ**: シードがパブリックリポジトリにアップロードされたら、**侵害されたものとみなす**。直ちに資金を新しいアカウントに移動する
- **Gitの履歴**: ファイルを削除してもシードは履歴に残ります。Gitの履歴を書き直す必要があり、それは複雑です`,
+- **テストネット**: テストネットのシードが漏洩しても実際のお金は失いませんが、テストに干渉される可能性があります。
+- **メインネット**: メインネットのシードが漏洩すると、**すべての資金を永久に失う可能性があります**。ブロックチェーンでは盗まれた資金を回収する方法がありません。
+- **パブリックリポジトリ**: シードがパブリックリポジトリにアップロードされたら、**侵害されたものとみなします**。直ちに資金を新しいアカウントに移動してください。
+- **Gitの履歴**: ファイルを削除してもシードは履歴に残ります。Gitの履歴を書き直す必要があり、それは複雑な作業です。`,
      },
      codeBlocks: [
        {
--- a/src/data/modules/m01-blockchain-non-evm.js
+++ b/src/data/modules/m01-blockchain-non-evm.js
@@ -158,9 +158,9 @@ In this course we will focus on **Xahau**, a **public** blockchain designed for
 ### どのように機能するのか？

 データは**ブロック**にまとめられます。各ブロックには以下が含まれます：
-1. **トランザクション**のセット（例：「アリスがボブに10トークンを送る」）
-2. ブロックの**ハッシュ**（ユニークなデジタル指紋）
-3. **前のブロックのハッシュ**、これによってチェーンが形成される
+1. **トランザクション**のセット: 例：「アリスがボブに10トークンを送る」
+2. ブロックの**ハッシュ**: ユニークなデジタル指紋
+3. **前のブロックのハッシュ**: これによってチェーンが形成されます

 この構造により、古いブロックを改ざんすることは事実上不可能です。変更するとそのハッシュが変わり、その後のチェーン全体が壊れてしまうからです。

@@ -182,7 +182,7 @@ In this course we will focus on **Xahau**, a **public** blockchain designed for
 - **公開鍵/秘密鍵**：各ユーザーはアイデンティティとして機能する鍵ペアを持つ

 **トランザクション**
-ブロックチェーンの状態を変更する操作です：トークンの送信、コントラクトの作成、データの記録など。各トランザクションは送信者によって**デジタル署名**されています。
+トークンの送信、コントラクトの作成、データの記録などブロックチェーンの状態を変更する操作です。各トランザクションは送信者によって**デジタル署名**されています。

 ### ブロックチェーン vs 従来のデータベース

@@ -196,7 +196,7 @@ In this course we will focus on **Xahau**, a **public** blockchain designed for

 ### 何に使われるのか？

-ブロックチェーンは以下に使用されます：
+ブロックチェーンは次のような用途に使用されます。
 - **暗号通貨**：銀行なしでお金を送る（Bitcoin、XAH）
 - **トークン**：独自のデジタル資産を作成する
 - **NFT**：ユニークなデジタルオブジェクトの所有権を証明する
@@ -323,13 +323,13 @@ Unlike EVM networks, in Xahau:

 ### なぜNon-EVMなのか？

-**Xahau**のようなNon-EVMブロックチェーンは、特定のユースケースのためにゼロから設計されました：高速な支払い、トークン化、効率的なプログラマブルロジック。Ethereumのような「汎用コンピュータ」を目指すのではなく、**パフォーマンス、低コスト、高速な最終性**に最適化しています。
+**Xahau**のようなNon-EVMブロックチェーンは、高速な支払い、トークン化、効率的なプログラマブルロジックなど特定のユースケースのためにゼロから設計されました。Ethereumのような「汎用コンピュータ」を目指すのではなく、**パフォーマンス、低コスト、高速な最終性**に最適化しています。

 ### Xahau：Non-EVMブロックチェーン

 **Xahau**は**XRP Ledger（XRPL）**のアーキテクチャを継承し、**Hooks**（Cで書かれWebAssemblyにコンパイルされた軽量スマートコントラクト）を実行する能力を追加したレイヤー1ブロックチェーンです。

-EVMネットワークとは異なり、Xahauでは：
+EVMネットワークとは異なり、Xahauでは次の特徴があります。
 - トランザクションは**ネイティブかつ型付き**（Payment、TrustSet、OfferCreateなど）
 - レジャーは**構造化されたオブジェクト**を維持し、任意の状態ではない
 - スマートコントラクト（Hooks）はトランザクションに対する**リアクティブフィルタ**として実行される
@@ -506,8 +506,8 @@ In Ethereum, the state is an **account tree** where each account has its own **s

 - **AccountRoot**：残高、シーケンス、フラグ、インストールされたHooksを持つアカウントを表す
 - **RippleState（TrustLine）**：2つのアカウント間のトークンに対するトラストライン
- **Offer**：ネイティブDEXでの売買注文
- **URIToken**：関連するURIを持つ非代替可能トークン
+- **Offer**：ネイティブDEXでの売買オファー
+- **URIToken**：URIに紐づく非代替性トークン
 - **HookDefinition**：デプロイされたHookのWASMコード
 - **HookState**：Hookによって格納された永続的なデータ

@@ -793,10 +793,10 @@ As a fork of XRPL, Xahau leverages all the advantages of a proven blockchain opt

 ### 2008年 — Bitcoin：誕生

-すべては**サトシ・ナカモト**が公開した9ページの文書から始まりました。タイトルは*「Bitcoin: A Peer-to-Peer Electronic Cash System」*。アイデアはシンプルかつ革命的でした：**仲介者なしのデジタルマネー**。
+すべては**サトシ・ナカモト**が公開した*「Bitcoin: A Peer-to-Peer Electronic Cash System」*というタイトルの9ページの文書から始まりました。アイデアは**仲介者なしのデジタルマネー**というシンプルかつ革命的なものでした。

-Bitcoinが導入したもの：
- **プルーフ・オブ・ワーク（PoW）**：マイナーが数学的問題を解いてトランザクションを検証する
+Bitcoinが導入したものは次の通りです。
+- **Proof of Work (PoW)**：マイナーが数学的問題を解いてトランザクションを検証する
 - **完全な分散化**：銀行なし、中央サーバーなし
 - **不変性**：確認されたトランザクションは取り消せない
 - **デジタル希少性**：Bitcoinは2,100万枚しか存在しない
@@ -805,21 +805,21 @@ Bitcoinが導入したもの：

 ### 2012年 — XRP Ledger：マイニングなしの速度

-後に**XRP Ledger（XRPL）**が作られました。**プルーフ・オブ・ワークを使用しない**最初の主要なブロックチェーンです。代わりに、**信頼できるバリデーター（UNL）**に基づくコンセンサスプロトコルを使用します。
+後に**XRP Ledger（XRPL）**が作られました。**PoWを使用しない**最初の主要なブロックチェーンです。代わりに、**信頼できるバリデーター（UNL）**に基づくコンセンサスプロトコルを使用します。

-XRPLが導入したもの：
- **マイニングなしのコンセンサス**：3〜5秒でトランザクションが確認される
+XRPLが導入したものは次の通りです。
+- **マイニングなしのコンセンサス**：3〜5秒でトランザクションが確定する
 - **ネイティブDEX**：プロトコルに統合された分散取引所
- **ネイティブトークン**：スマートコントラクトなしでトークンを作成
- **最小手数料**：トランザクションあたり数セントの何分の一
+- **ネイティブのトークン発行**：スマートコントラクトなしでトークンを作成
+- **少ない手数料**：トランザクションあたり数セント

 限界：XRPLにはスマートコントラクト（カスタムプログラマブルロジック）を実行する能力がなかった。

 ### 2015年 — Ethereum：ワールドコンピュータ

-**ヴィタリック・ブテリン**は野心的なアイデアを持つEthereumホワイトペーパーを発表しました：**あらゆるプログラム**を実行できるブロックチェーン。こうして**Ethereum Virtual Machine（EVM）**が誕生しました。
+**ヴィタリック・ブテリン**は**あらゆるプログラム**を実行できるブロックチェーンといった野心的なアイデアを持つEthereumホワイトペーパーを発表しました。こうして**Ethereum Virtual Machine（EVM）**が誕生しました。

-Ethereumが導入したもの：
+Ethereumが導入したものは次の通りです。
 - **スマートコントラクト**：ブロックチェーン上に存在し自動的に実行されるプログラム
 - **Solidity**：コントラクトを書くためのプログラミング言語
 - **EVM**：コントラクトコードを実行する仮想マシン
@@ -832,7 +832,7 @@ Ethereumが導入したもの：

 Ethereumの問題が新しいブロックチェーンの波を引き起こしました：

- **Solana**（2020年）：プルーフ・オブ・ヒストリーによる高速（理論値約65,000 TPS）
+- **Solana**（2020年）：Proof of Historyによる高速（理論値約65,000 TPS）
 - **Avalanche**（2020年）：高速コンセンサスによるカスタマイズ可能なサブネット
 - **Polygon**（2020年）：Ethereumをスケールするためのレイヤー2ソリューション
 - **Arbitrum / Optimism**（2021年）：Ethereum外でトランザクションを処理するロールアップ
@@ -842,22 +842,22 @@ Ethereumの問題が新しいブロックチェーンの波を引き起こしま

 ### 2023年 — Xahau：XRPL + スマートコントラクト

-**Xahau**は**XRP Ledgerのフォーク**として誕生し、XRPLが常に必要としていた機能を追加しました：**スマートコントラクト**（**Hooks**と呼ばれる）。当初XahauはXRP Ledgerの一部になる予定でHooksがXRP Ledgerに組み込まれる予定でしたが、Rippleはコミュニティのこの改善を受け入れませんでした。何年もかけてきた作業を無駄にしないために、Xahauが誕生しました。
+**Xahau**は**XRP Ledgerのフォーク**として誕生し、XRPLが常に必要としていた**スマートコントラクト**（**Hooks**と呼ばれる）機能を追加しました。当初XahauはXRP Ledgerの一部になる予定でHooksがXRP Ledgerに組み込まれる予定でしたが、Rippleはコミュニティのこの改善を受け入れませんでした。何年もかけてきた作業を無駄にしないために、Xahauが誕生しました。

 Xahauが導入したもの：
 - **Hooks**：Cで書かれWebAssemblyにコンパイルされたスマートコントラクト
 - **XAH**：エミッション/報酬システムを持つネイティブトークン
 - **XRPLの継承**：速度、ネイティブDEX、低手数料を維持
- **EVMなし**：独自のアーキテクチャ、Solidityと非互換
+- **EVMなし**：独自のアーキテクチャ、Solidityと互換性なし

 ### なぜXahauはXRPLのフォークなのか？

-XRPLのフォークとして、Xahauは支払いとトークンのために実証され最適化されたブロックチェーンのすべての利点を活用し、欠けていたピースを追加します：プロトコル内で直接プログラマブルロジックを実行する能力。
+XRPLのフォークとして、Xahauは支払いとトークンのために実証され最適化されたブロックチェーンのすべての利点を活用し、プロトコル内で直接プログラマブルロジックを実行するという欠けていたピースを追加しました。

 1. **実証済みの基盤**：XRPLは2012年から大きな中断なく稼働している
 2. **ネイティブな速度**：XRPLのコンセンサスはすでに3〜5秒の最終確定を提供する
 3. **統合DEX**：分散取引所をゼロから構築する必要がない
-4. **ネイティブトークン**：TrustLinesとトークンシステムはすでに存在し機能している
+4. **ネイティブのトークン発行**：トラストラインとトークンシステムはすでに存在し機能している
 5. **既存のコミュニティ**：XRPLの開発者とツールが適応できる

 ### 年表まとめ
@@ -869,7 +869,7 @@ XRPLのフォークとして、Xahauは支払いとトークンのために実
 | 2015 | Ethereum | スマートコントラクト（EVM + Solidity） |
 | 2017 | ICOブーム | ERC-20トークン、分散型資金調達 |
 | 2020 | DeFiサマー | Ethereum上の分散型金融 |
-| 2020年以降 | L1s/L2s | Solana、Avalanche、Polygon、ロールアップ |
+| 2020以降 | L1/L2 | Solana、Avalanche、Polygon、ロールアップ |
 | 2023 | Xahau | XRPL + Hooks（C/WASMのスマートコントラクト） |`,
      },
      codeBlocks: [],
@@ -1086,17 +1086,17 @@ To obtain testnet XAH, use the **faucet**: a tool that sends free tokens to your

 ### XAH：ネイティブトークン

-**XAH**はXahauのネイティブ暗号通貨です。XRPLのXRPとは異なり、XAHには**インフレ型エミッションシステム**があります：アクティブなアカウントの保有者は定期的にXAHの報酬をリクエストできます。これによりネットワークへの参加と利用が奨励されます。
+**XAH**はXahauのネイティブ暗号通貨です。XRPLのXRPとは異なり、XAHにはアクティブなアカウントの保有者は定期的にXAHの報酬をリクエスト可能な**インフレ型エミッションシステム**があります。これによりネットワークへの参加と利用が奨励されます。

 XAHの特徴：
 - **手数料**（トランザクション手数料）の支払いに使用される
- アクティブなアカウントを維持するために**最小リザーブ**が必要
+- アクティブなアカウントを維持するために**少額の準備金**が必要
 - **エミッションシステム**がリクエストしたアクティブなアカウントにXAHを配布する
 - 送信、交換、Hooksでの使用が可能

 ### Xaman（旧XUMM）：メインウォレット

-**Xaman**（以前はXUMMとして知られていた）はXRPL/Xahauエコシステムで最も広く使用されているウォレットです。以下を可能にするモバイルアプリケーションです：
+**Xaman**（以前はXUMMとして知られていた）はXRPL/Xahauエコシステムで最も広く使用されているウォレットです。次のことが可能なモバイルアプリケーションです。

 - XahauとXRPLのアカウントを作成・管理する
 - XAHとトークンを送受信する
@@ -1120,7 +1120,7 @@ URL：[builder.xahau.network/](https://builder.xahau.network/)

 ### ブロックエクスプローラー

-**エクスプローラー**はブロックチェーン上で起きていることをすべて視覚的に確認できます：
+**エクスプローラー**はブロックチェーン上で起きていることをすべて視覚的に確認できます。

 - ハッシュでトランザクションを検索する
 - 任意のアカウントの状態を確認する（残高、トークン、Hooks）
@@ -1157,12 +1157,12 @@ Xahauには2つの主要なネットワークがあります：
 | WebSocket URL | wss://xahau-test.net | wss://xahau.network |
 | トークン | XAH（実際の価値なし） | XAH（実際の価値あり） |
 | 目的 | 開発とテスト | 本番環境 |
-| フォーセット | あり（テスト用の無料XAH） | なし |
+| faucet | あり（テスト用の無料XAH） | なし |
 | データ | 定期的にリセットされる場合がある | 永続的 |

 **このコースでは常にtestnetを使用します。** Testnetのトークンには実際の価値がないため、お金を失うリスクなく自由に実験できます。

-Testnet XAHを取得するには、**フォーセット**（蛇口）を使用します：テストアカウントに無料トークンを送るツールです。これは後のモジュールで詳しく説明します。`,
+Testnet XAHを取得するには、**faucet**（テストアカウントにテスト用トークンを送るツール）を使用します。これは後のモジュールで詳しく説明します。`,
      },
      codeBlocks: [
      ],
--- a/src/data/modules/m02-consensus.js
+++ b/src/data/modules/m02-consensus.js
@@ -121,53 +121,53 @@ Xahau is not based on competition (like PoW) or locked capital (like PoS), but o

 ### なぜコンセンサスが必要なのか？

-分散型ネットワークには、どのトランザクションが有効かを決定する中央権限が存在しません。コンセンサスは、複数の独立したノードが互いを信頼せずにどのように単一の状態に合意できるかという問題を解決します。
+分散型ネットワークには、どのトランザクションが有効かを決定する中央機関が存在しません。コンセンサスは、複数の独立したノードが互いを信頼せずにどのように単一の状態に合意できるかという問題を解決します。

 ### 二重支払い問題

-**二重支払い**はすべてのデジタルマネーシステムが解決しなければならない根本的な問題です：同じお金を2回使われるのをどうやって防ぐか？
+**二重支払い**はすべてのデジタルマネーシステムが解決しなければならない根本的な問題です。同じお金を2回使われるのを防ぐにはどうしたらいいでしょうか？

 物理的なお金ではこれは不可能です。誰かに紙幣を渡したら、自分はもう持っていません。しかしデジタルデータはコピーできます。コンセンサスメカニズムがなければ、アリスは10 XAHをボブに送ると同時に、その同じ10 XAHをキャロルに送ることができてしまいます。両方のトランザクションが別々に有効に見えます。

-コンセンサスはこれを解決します：ネットワークのすべてのノードがトランザクションの**唯一の順序**について合意します。ボブへのトランザクションが最初に処理されれば、アリスにはもうその資金がないのでキャロルへのトランザクションは拒否されます。
+コンセンサスはこれを解決します。ネットワークのすべてのノードがトランザクションの**一意の順序**について合意します。ボブへのトランザクションが最初に処理されれば、アリスにはもうその資金がないのでキャロルへのトランザクションは拒否されます。

 ### ビザンチン将軍問題

-二重支払いは分散コンピューティングのより一般的な問題の特殊なケースです：**ビザンチン将軍問題**（1982年、ランポート、ショスタク、ピース）。
+二重支払いは分散コンピューティングのより一般的な問題である**ビザンチン将軍問題**（1982年、ランポート、ショスタク、ピース）の1つのケースです。

-敵の都市を包囲した軍の複数の将軍を想像してください。攻撃するか撤退するかを調整しなければなりません。一部だけが攻撃すると負けます。問題は、彼らは使者を通じて通信し、**一部の将軍は混乱を引き起こすために矛盾した命令を送る裏切り者かもしれない**ことです。
+敵の都市を包囲した軍の複数の将軍を想像してみましょう。攻撃するか撤退するかを調整しなければなりません。一部だけが攻撃すると負けます。問題は、彼らは使者を通じて通信し、**一部の将軍は混乱を引き起こすために矛盾した命令を送る裏切り者かもしれない**ことです。

 ブロックチェーンに当てはめると：
 - **将軍**は**ノード/バリデーター**
 - **メッセージ**は**トランザクションと提案**
 - **裏切り者**は不正を試みる**悪意のあるノード**（例：二重支払いの承認）

-コンセンサスプロトコルは**参加者の一部が嘘をついたり失敗しても**正しく機能しなければなりません。これを**ビザンチン障害耐性（BFT）**と呼びます。各コンセンサスメカニズムはこれを異なる方法で解決します：
+コンセンサスプロトコルは**参加者の一部が嘘をついたり失敗しても**正しく機能しなければなりません。これを**ビザンチン障害耐性（BFT）**と呼びます。各コンセンサスメカニズムはこれを異なる方法で解決します。
 - **PoW**：嘘をつくことを非常に高価にする（エネルギーの消費が必要）
 - **PoS**：嘘をつくことに経済的な結果をもたらす（ステークを失う）
- **フェデレーテッドコンセンサス（Xahau）**：信頼できるバリデーターの少なくとも80%の合意が必要
+- **連合型コンセンサス（Xahau）**：信頼できるバリデーターの少なくとも80%の合意が必要

 ### 主なコンセンサスの種類

-**プルーフ・オブ・ワーク（PoW）** — Bitcoin
+**Proof of Work (PoW)** — Bitcoin
 - マイナーが数学的問題を解いて競争する
 - 高エネルギー消費
- 確率的な最終性（複数の確認を待つ必要がある）
+- 確率的なファイナリティ(最終性)（複数の確認を待つ必要がある）

-**プルーフ・オブ・ステーク（PoS）** — Ethereum
+**Proof of Stake (PoS)** — Ethereum
 - バリデーターがトークンをステーク（担保）に入れる
 - PoWより効率的
- より高速な最終性だが再編成の可能性あり
+- より高速なファイナリティだが再編成の可能性あり

-**フェデレーテッドコンセンサス / UNL** — Xahau
+**Federated consensus / UNL** — Xahau
 - バリデーターが有効なトランザクションに投票する
 - マイニングもステーキングも不要
- 数秒での決定論的な最終性
+- 数秒での決定論的なファイナリティ
 - 低エネルギー消費

 ### Xahauのコンセンサスは何が違うのか？

-Xahauは競争（PoWのような）にも、ロックされた資本（PoSのような）にも基づいていません。UNLリストを通じた**バリデーター間の信頼**に基づいています。`,
+Xahauは（PoWのような）競争にも、（PoSのような）ロックされた資本にも基づいていません。UNLリストを通じた**バリデーター間の信頼**に基づいています。`,
      },
      codeBlocks: [
        {
@@ -255,20 +255,20 @@ getValidators();`,
          visual: "🤝",
        },
        {
-          title: { es: "PoW vs PoS vs Federated", en: "PoW vs PoS vs Federated", jp: "PoW vs PoS vs フェデレーテッド" },
+          title: { es: "PoW vs PoS vs Federated", en: "PoW vs PoS vs Federated", jp: "PoW vs PoS vs 連合型コンセンサス" },
          content: {
            es: "⛏️ PoW → Minería (Bitcoin)\n💰 PoS → Staking (Ethereum)\n🗳️ Federado → Votación (Xahau)\n\nXahau: sin minería, sin staking\nFinalidad determinística en segundos",
            en: "⛏️ PoW → Mining (Bitcoin)\n💰 PoS → Staking (Ethereum)\n🗳️ Federated → Voting (Xahau)\n\nXahau: no mining, no staking\nDeterministic finality in seconds",
-            jp: "⛏️ PoW → マイニング（Bitcoin）\n💰 PoS → ステーキング（Ethereum）\n🗳️ フェデレーテッド → 投票（Xahau）\n\nXahau：マイニングなし、ステーキングなし\n数秒での決定論的な最終性",
+            jp: "⛏️ PoW → マイニング（Bitcoin）\n💰 PoS → ステーキング（Ethereum）\n🗳️ 連合型コンセンサス → 投票（Xahau）\n\nXahau：マイニングなし、ステーキングなし\n数秒での決定論的なファイナリティ",
          },
          visual: "⚡",
        },
        {
-          title: { es: "¿Por qué consenso federado?", en: "Why federated consensus?", jp: "なぜフェデレーテッドコンセンサスなのか？" },
+          title: { es: "¿Por qué consenso federado?", en: "Why federated consensus?", jp: "なぜ連合型コンセンサスなのか？" },
          content: {
            es: "Xahau eligió consenso federado por:\n\n• Velocidad → Finalidad en 3-5 segundos\n• Eficiencia energética → Sin minería costosa\n• Finalidad determinística → Sin reorgs ni forks\n• Sin barreras económicas → No requiere staking\n• Confianza distribuida → Validadores diversos\n\nIdeal para pagos y aplicaciones financieras",
            en: "Xahau chose federated consensus for:\n\n• Speed → Finality in 3-5 seconds\n• Energy efficiency → No costly mining\n• Deterministic finality → No reorgs or forks\n• No economic barriers → No staking required\n• Distributed trust → Diverse validators\n\nIdeal for payments and financial applications",
-            jp: "Xahauがフェデレーテッドコンセンサスを選んだ理由：\n\n• 速度 → 3〜5秒での最終性\n• エネルギー効率 → コストのかかるマイニング不要\n• 決定論的な最終性 → 再編成やフォークなし\n• 経済的障壁なし → ステーキング不要\n• 分散した信頼 → 多様なバリデーター\n\n支払いと金融アプリケーションに最適",
+            jp: "Xahauが連合型コンセンサスを選んだ理由：\n\n• 速度 → 3〜5秒でのファイナリティ\n• エネルギー効率 → コストのかかるマイニング不要\n• 決定論的なファイナリティ → 再編成やフォークなし\n• 経済的障壁なし → ステーキング不要\n• 分散した信頼 → 多様なバリデーター\n\n支払いと金融アプリケーションに最適",
          },
          visual: "🏆",
        },
@@ -332,7 +332,7 @@ Each node maintains a **UNL**, the list of validators whose opinions it consider
 ### Difference from Proof of Stake

 In PoS, security is backed by economic capital (staked tokens). In Xahau's consensus, security is backed by the **reputation and diversity** of validators. Validators are operated by independent entities (universities, companies, foundations, or individuals).`,
-        jp: `Xahauは**フェデレーテッドコンセンサスメカニズム**を使用しています。このプロトコルは、各ノードが信頼するバリデーターのリストである**UNL（Unique Node List）**の概念に基づいています。
+        jp: `Xahauは**連合型コンセンサスメカニズム**を使用しています。このプロトコルは、各ノードが信頼するバリデーターのリストである**UNL（Unique Node List）**の概念に基づいています。

 ### どのように機能するのか？

@@ -340,7 +340,7 @@ In PoS, security is backed by economic capital (staked tokens). In Xahau's conse
 2. **投票**：バリデーターが自分のUNLの他のバリデーターの提案と比較する
 3. **収束**：複数のラウンドを通じて、バリデーターは共通のトランザクションセットに収束する
 4. **検証**：UNLバリデーターの少なくとも**80%**が合意すると、レジャーが検証される
-5. **クローズ**：新しいレジャーがクローズし、ネットワークの公式状態となる
+5. **閉鎖**：新しいレジャーがクローズし、ネットワークの公式状態となる

 ### UNL（Unique Node List）

@@ -348,13 +348,13 @@ In PoS, security is backed by economic capital (staked tokens). In Xahau's conse

 ### Xahauのコンセンサスの特性

- **決定論的な最終性**：レジャーが検証されると、それは最終的です。再編成はありません（Bitcoin/Ethereumとは異なる）
+- **決定論的なファイナリティ**：レジャーが検証されると、それは最終的です。再編成はありません（Bitcoin/Ethereumとは異なる）
 - **速度**：レジャーは**3〜5秒**ごとにクローズする
 - **エネルギー効率**：PoWのような集中的な計算を必要としない
 - **ステーキング不要**：バリデーターは資本をロックする必要がない
 - **障害耐性**：UNLバリデーターの少なくとも80%が稼働している限りネットワークは機能する

-### プルーフ・オブ・ステークとの違い
+### Proof of Stakeとの違い

 PoSでは、セキュリティは経済的資本（ステークされたトークン）によって裏付けられています。Xahauのコンセンサスでは、セキュリティはバリデーターの**評判と多様性**によって裏付けられています。バリデーターは独立した組織（大学、企業、財団、または個人）によって運営されています。`,
      },
@@ -558,7 +558,7 @@ When the 80% threshold is not reached, the ledger simply **does not close**. Dis

 敵の都市を包囲した軍の複数の将軍を想像してください。勝つには同時攻撃を調整しなければなりません。一部だけが攻撃すると負けます。問題は、使者を通じて通信しており、**一部の将軍が矛盾したメッセージを送る裏切り者かもしれない**ことです。

-これが1982年にランポート、ショスタク、ピースが定式化した**ビザンチン将軍問題**です。ブロックチェーンに当てはめると：
+これが1982年にランポート、ショスタク、ピースが定式化した**ビザンチン将軍問題**です。ブロックチェーンに当てはめると次のようになります。
 - **将軍**は**バリデーター**
 - **メッセージ**は**トランザクションの提案**
 - **裏切り者**は**悪意のあるまたは欠陥のあるノード**
@@ -726,7 +726,7 @@ When a UNL validator stops responding:

 1. A developer proposes a change to the protocol and implements it with a unique amendment ID
 2. Validators **vote** on whether they support activating that amendment
-3. If an amendment receives support from **80% of validators** for **2 consecutive weeks**, it is automatically activated
+3. If an amendment receives support from **80% of validators** for **5 consecutive days**, it is automatically activated
 4. Once activated, it is permanent and irreversible

 Examples of amendments include: new transaction types, new blockchain features.
@@ -740,11 +740,11 @@ How do you measure if a network is truly decentralized? Some key metrics:
 - **Operator diversity**: Different types of entities (companies, universities, individuals)
 - **Infrastructure diversity**: Different hosting providers, not all on AWS or Google Cloud
 - **UNL overlap**: What percentage of validators the different UNLs share`,
-        jp: `これまでバリデーターについて理論的に話してきました。このレッスンでは**実践的に**どのように機能するかを見ていきます：誰が運営するか、1つ実行するために何が必要か、そしてネットワークがエンメントメントシステムを通じてどのように進化するか。
+        jp: `これまでバリデーターについて理論的に話してきました。このレッスンでは、誰が運営するか、1つ実行するために何が必要か、そしてネットワークがエンメントメントシステムを通じてどのように進化するか、など**実践的に**どのように機能するかを見ていきます。

 ### Xahauで誰がバリデーターを運営するのか？

-分散型ネットワークの強さはその**バリデーターの多様性**に依存します。Xahauでは、バリデーターは以下によって運営されます：
+分散型ネットワークの強さはその**バリデーターの多様性**に依存します。Xahauでは、バリデーターは次のような組織によって運営されます。

 - エコシステムの**財団と組織**
 - ネットワーク上に構築する**企業**
@@ -754,7 +754,7 @@ How do you measure if a network is truly decentralized? Some key metrics:

 ### バリデーターを運営するための要件

-Xahauでバリデーターノードを実行するには以下が必要です：
+Xahauでバリデーターノードを実行するには次のような要件があります。

 - **ハードウェア**：少なくとも8GBのRAM、4つのCPU、高速SSDストレージを持つサーバー
 - **ネットワーク**：低遅延と高可用性の安定したインターネット接続
@@ -779,26 +779,26 @@ Xahauでバリデーターノードを実行するには以下が必要です：

 ### バリデーターが切断された場合はどうなるのか？

-UNLバリデーターが応答を停止した場合：
+UNLバリデーターが応答を停止した場合
 1. 他のバリデーターはそれなしで続行する
-2. クォーラムは**アクティブな**バリデーターに基づいて計算される
-3. あまりにも多くのバリデーターがダウンした場合（80%未満利用可能）、ネットワークは新しいレジャーの**検証を停止する**（破損せず、一時停止するだけ）
+2. 閾値は**アクティブな**バリデーターに基づいて計算される
+3. あまりにも多くのバリデーターがダウンした場合（80%未満）、ネットワークは新しいレジャーの**検証を停止する**（破損せず、一時停止するだけ）
 4. 十分なバリデーターが戻ると、ネットワークは自動的に再開する

-### エンメントメント（修正案）とプロトコル投票
+### Amendment（修正案）とプロトコル投票

-**エンメントメント**はXahauが分散型の方法でプロトコルを更新するメカニズムです：
+**Amendment**はXahauが分散型の方法でプロトコルを更新するメカニズムです：

-1. 開発者がプロトコルへの変更を提案し、一意のエンメントメントIDで実装する
-2. バリデーターがそのエンメントメントのアクティベーションを支持するかどうか**投票する**
-3. エンメントメントが**2週間連続して**バリデーターの**80%のサポート**を受けると、自動的にアクティベートされる
+1. 開発者がプロトコルへの変更を提案し、一意のAmendmentIDで実装する
+2. バリデーターがそのAmendmentのアクティベーションを支持するかどうか**投票する**
+3. Amendmentが**5日間連続して**バリデーターの**80%のサポート**を受けると、自動的にアクティベートされる
 4. 一度アクティベートされると、永続的かつ不可逆です

-エンメントメントの例：新しいトランザクションタイプ、新しいブロックチェーン機能。
+Amendmentの例：新しいトランザクションタイプ、新しいブロックチェーン機能。

 ### 分散化の指標

-ネットワークが本当に分散化されているかどうかをどのように測定するか？主要な指標：
+ネットワークが本当に分散化されているかどうかをどのように測定するか？主要な指標は次の通りです。

 - **中本係数**：ネットワークを侵害するために共謀する必要がある最小エンティティ数。高いほど良い
 - **地理的分布**：異なる国や大陸のバリデーター
@@ -1052,8 +1052,8 @@ checkNetworkFees();`,
          title: { es: "Enmiendas: gobernanza descentralizada", en: "Amendments: decentralized governance", jp: "エンメントメント：分散型ガバナンス" },
          content: {
            es: "Las actualizaciones del protocolo\nse votan de forma descentralizada:\n\n1. Se propone un cambio (amendment)\n2. Los validadores votan a favor o en contra\n3. 80% de apoyo durante 2 semanas\n4. Se activa automáticamente\n5. Es permanente e irreversible",
-            en: "Protocol updates\nare voted on in a decentralized way:\n\n1. A change is proposed (amendment)\n2. Validators vote for or against\n3. 80% support for 2 weeks\n4. It is activated automatically\n5. It is permanent and irreversible",
-            jp: "プロトコルの更新は\n分散型の方法で投票される：\n\n1. 変更（エンメントメント）を提案する\n2. バリデーターが賛否を投票する\n3. 2週間、80%の支持を得る\n4. 自動的にアクティベートされる\n5. 永続的かつ不可逆",
+            en: "Protocol updates\nare voted on in a decentralized way:\n\n1. A change is proposed (amendment)\n2. Validators vote for or against\n3. 80% support for 5 days\n4. It is activated automatically\n5. It is permanent and irreversible",
+            jp: "プロトコルの更新は\n分散型の方法で投票される：\n\n1. 変更（エンメントメント）を提案する\n2. バリデーターが賛否を投票する\n3. 5日間、80%の支持を得る\n4. 自動的にアクティベートされる\n5. 永続的かつ不可逆",
          },
          visual: "🗳️",
        },
--- a/src/data/modules/m03-first-wallet.js
+++ b/src/data/modules/m03-first-wallet.js
@@ -73,7 +73,7 @@ Unlike Ethereum, in Xahau an account **does not exist on the ledger until it rec

 ### 鍵ペア

-Xahau（および多くの他のブロックチェーン）では、各アカウントは楕円曲線暗号に基づいています：
+Xahau（および多くの他のブロックチェーン）では、各アカウントは楕円曲線暗号に基づいています。

 - **秘密鍵（Secret/Seed）**：絶対に共有してはならない秘密の値。トランザクションの署名に使用される。通常 \`s\` で始まる「ファミリーシード」として表される（例：\`sEdV....\`）
 - **公開鍵**：秘密鍵から導出される。署名の検証に使用される
@@ -89,7 +89,7 @@ Xahauは2つの署名アルゴリズムをサポートしています：

 ### アカウントのアクティベーション

-Ethereumとは異なり、Xahauではアカウントは**最初の入金を受け取るまでレジャーに存在しません**。アカウントをアクティベートするには最低 **1 XAH**（ベースリザーブ）が必要です。このXAHはアカウントが存在する限りリザーブとしてロックされます。
+Ethereumとは異なり、Xahauではアカウントは**最初の入金を受け取るまでレジャーに存在しません**。アカウントをアクティベートするには最低 **1 XAH**（基本準備金）が必要です。このXAHはアカウントが存在する限り準備金としてロックされます。

 ### セキュリティ

@@ -290,19 +290,19 @@ Once your account is activated, you can verify its existence by querying the \`a

 ### テストネットとは？

-テストネットは開発用に設計されたXahauネットワークのコピーです：
+テストネットは開発用に設計されたXahauネットワークのコピーです。
 - トークン（テストXAH）は**実際の価値がない**
- **フォーセット**から無料でトークンを取得できる
+- **Faucet**から無料でトークンを取得できる
 - トランザクションはメインネットと同様に機能する
 - 学習と実験に最適な場所

-### フォーセット
+### Faucet

-フォーセットはテストトークンをウォレットに送るサービスです。\`xahau\` ライブラリを使ってコードから直接使用できます。フォーセットのWebインターフェースからテストXAH付きのウォレットを取得することもできます：[xahau-test.net](https://xahau-test.net)。その後、シードをコードで使用するか、Xamanにインポートできます。
+Faucetはテストトークンをウォレットに送るサービスです。\`xahau\` ライブラリを使ってコードから直接使用できます。FaucetのWebインターフェース([xahau-test.net](https://xahau-test.net))からテストXAH付きのウォレットを取得することもできます。その後、シードをコードで使用するか、Xamanにインポートできます。

 ### アカウントの確認

-アカウントがアクティベートされたら、\`account_info\` コマンドを照会してその存在を確認できます。以下が表示されます：
+アカウントがアクティベートされたら、\`account_info\` コマンドを照会してその存在を確認できます。以下の情報が表示されます。
 - **Balance**：アカウントのXAH残高（dropsで：1 XAH = 1,000,000 drops）
 - **Sequence**：次のトランザクションのシーケンス番号
 - **Flags**：アカウントの設定
@@ -711,7 +711,7 @@ Each transaction has a unique **hash** (a long hexadecimal string). You can sear

 ### Xahauテストネットのエクスプローラー

-**テストネット**（このコースで使用するもの）のアカウントを確認するには、以下のエクスプローラーを使用してください：
+**テストネット**（このコースで使用するもの）のアカウントを確認するには、以下のエクスプローラーを使用してください。

 - [test.xahauexplorer.com](https://test.xahauexplorer.com)
 - [xahau-testnet.xrplwin.com](https://xahau-testnet.xrplwin.com)
@@ -722,7 +722,7 @@ Each transaction has a unique **hash** (a long hexadecimal string). You can sear
 1. テストネットのエクスプローラーを開く
 2. 検索バーに**アドレス**（\`r\`で始まる文字列）を貼り付ける
 3. Enterキーを押すか検索ボタンをクリック
-4. アカウント情報が表示されます：
+4. アカウント情報が表示されます。
   - XAHの**残高**
   - 保有している**トークン**（トラストライン）
   - 最近の**トランザクション**
@@ -731,7 +731,7 @@ Each transaction has a unique **hash** (a long hexadecimal string). You can sear

 ### トランザクションの確認

-各トランザクションには一意の**ハッシュ**（長い16進数の文字列）があります。そのハッシュをエクスプローラーで検索すると、以下が確認できます：
+各トランザクションには一意の**ハッシュ**（長い16進数の文字列）があります。そのハッシュをエクスプローラーで検索すると、以下が確認できます。
 - トランザクションの**タイプ**（Payment、TrustSet、AccountSetなど）
 - **送信元**と**送信先**のアカウント
 - 送信された**金額**
@@ -980,11 +980,11 @@ Multi-signing is ideal for:
 - Organization treasuries
 - Shared accounts between partners
 - Any situation where a single person should not have total control`,
-        jp: `ブロックチェーンで作業する際、ウォレットのセキュリティは最も重要なことです。ウォレットが侵害されると、資金の**完全かつ不可逆的な損失**を意味します。このレッスンでは、アカウントを保護するためのベストプラクティスを学びます。
+        jp: `ブロックチェーンで作業する際、ウォレットのセキュリティは最も重要なことです。ウォレットが侵害されると、資金の**完全かつ永久的な損失**を意味します。このレッスンでは、アカウントを保護するためのベストプラクティスを学びます。

 ### シード／秘密鍵を絶対に共有しないこと

-あなたのシード（秘密鍵）は、**アカウントをコントロールする唯一の方法**です。あなたのシードを持っている人は、あなたの代わりにあらゆるトランザクションに署名できます：すべての資金を送ったり、設定を変更したりなど。これを元に戻す方法はありません。
+あなたのシード（秘密鍵）は、**アカウントをコントロールする唯一の方法**です。あなたのシードを持っている人は、あなたの代わりにすべての資金を送ったり、設定を変更したりなどあらゆるトランザクションに署名できます。これを元に戻す方法はありません。

 基本ルール：
 - チャット、メール、その他のデジタル手段でシードを**絶対に**送らない
@@ -1016,7 +1016,7 @@ Multi-signing is ideal for:

 ### テストネットのシード：例外

-**テストネット**のシードは教育的なコンテキストで共有しても安全です。理由：
+**テストネット**のシードは教育的なコンテキストでは共有しても安全です。理由は次の通りです。
 - テストネットのトークンは**実際の価値がない**
 - テストネットはいつでもリセットできる
 - 他の開発者との問題のデバッグに役立つ
@@ -1025,7 +1025,7 @@ Multi-signing is ideal for:

 ### よくある詐欺とその回避方法

-**フィッシング（Phishing）**：
+**フィッシング**：
 - 正規のインターフェースを模倣した偽のWebサイト
 - アカウントを「確認する」ためにシードを入力するよう求める
 - URLを必ず確認し、不審なリンクはクリックしない
@@ -1062,18 +1062,18 @@ Xahauは**レギュラーキー（Regular Key）**と呼ばれる高度な機能
 3. これにより、レギュラーキーのみがトランザクションに署名できる
 4. レギュラーキーが侵害された場合、マスターキーを再アクティベートしてコントロールを取り戻せる

-これは追加の保護レイヤーを加えます：誰かがマスターシードを入手しても、無効化されている間は使用できません。
+これは追加の保護レイヤーを加えます。誰かがマスターシードを入手しても、無効化されている間は使用できません。

-### マルチシグニング：複数の署名
+### マルチシグ：複数の署名

-高額アカウントやガバナンス用に、Xahauは**マルチシグニング（multi-signing）**をサポートしています：
+高額アカウントやガバナンス用に、Xahauは**マルチシグ（multi-signing）**をサポートしています。

- 承認された署名者のリストと**クォーラム**（必要な最小ウェイト）を設定する
+- 承認された署名者のリストと**閾値**（必要な最小ウェイト）を設定する
 - 各署名者には重みが割り当てられる
- トランザクションはクォーラムに達するのに十分な署名を受け取った場合にのみ有効
- 例：各重み1の3人の署名者、クォーラム2 → 3人中少なくとも2人の署名が必要
+- トランザクションは閾値に達するのに十分な署名を受け取った場合にのみ有効
+- 例：各重み1の3人の署名者、閾値2 → 3人中少なくとも2人の署名が必要

-マルチシグニングに適した用途：
+マルチシグに適した用途：
 - 組織の資金管理
 - パートナー間の共有アカウント
 - 一人の人物が完全な管理権を持つべきでない状況`,
@@ -1231,14 +1231,14 @@ Account flags are stored as a numeric field where each bit represents a flag. Yo
 ### 重要なフラグ

 **asfRequireDest（RequireDestTag）**
- すべての着信ペイメントに**デスティネーションタグ**を含めることを要求する
+- すべての着信ペイメントに**宛先タグ**を含めることを要求する
 - タグを使用してユーザーを識別する取引所やサービスに役立つ
- このフラグがないと、タグなしでXAHを送ることができ、誰から来たかを知ることが不可能になる
+- このフラグがないと、タグなしでXAHを送ることができ、誰から来たかを知ることができなくなる
 - フラグID：\`1\`

 **asfDisallowXRP（DisallowXAH）**
 - アカウントが**XAHを直接受け取ることを希望しない**ことを示す
- これは信号に過ぎず、技術的にはペイメントはまだ到達できる
+- これは情報提供に過ぎず、技術的にはペイメントはまだ到達できる
 - 発行されたトークン（IOU）のみを扱うアカウントに役立つ
 - フラグID：\`3\`

@@ -1257,15 +1257,15 @@ Account flags are stored as a numeric field where each bit represents a flag. Yo

 **ドメイン**：アカウントにWebドメインを関連付けることができます。ドメインの16進数値として保存されます。これにより、アカウントがそのドメインの所有者に属することを確認できます。

-**EmailHash**：メールのMD5ハッシュで、アバターの表示に使用されます（Gravatarのような）。メールアドレスを直接公開しません。
+**EmailHash**：メールのMD5ハッシュで、（Gravatarのような）アバターの表示に使用されます。メールアドレスを直接公開しません。

-### ビットとしてのフラグ
+### ビットフラグ

 アカウントフラグは、各ビットがフラグを表す数値フィールドとして保存されます。AccountSetトランザクションの\`SetFlag\`フィールドでフラグを有効化し、\`ClearFlag\`で無効化できます。

 | フラグ | ID | 目的 |
 |--------|-----|------|
-| asfRequireDest | 1 | デスティネーションタグを要求 |
+| asfRequireDest | 1 | 宛先タグを要求 |
 | asfRequireAuth | 2 | トラストラインの承認を要求 |
 | asfDisallowXRP | 3 | XAHの受け取りを希望しないことを示す |
 | asfDisableMaster | 4 | マスターキーを無効化 |
@@ -1798,9 +1798,9 @@ Once Xaman is installed, you can import the account you generated via code using
 7. Confirm with your PIN or biometrics
 8. Your account will appear in the Xaman account list

-### Add the Xahau network in Xaman
+### Add the Xahau Testnet in Xaman

-By default, Xaman connects to **XRPL Mainnet**. To work with **Xahau**, you need to add the network:
+By default, Xaman connects to **XRPL Mainnet**. To work with **Xahau Testnet**, you need to add the network:

 1. In Xaman, go to **Settings** (gear icon)
 2. Find the **"Advanced"** section
@@ -1854,14 +1854,14 @@ This is useful for:
 - Monitoring other accounts (exchanges, contracts)
 - Watching your mainnet account without exposing the seed on your phone
 - Checking balances quickly`,
-        jp: `**Xaman**（以前はXUMM）は、XRPLおよびXahauエコシステムで最も広く使用されているモバイルウォレットです。これまでJavaScriptコードからウォレットを操作してきましたが、アカウントを視覚的に管理し、スマートフォンからトランザクションに署名し、分散型アプリケーションと対話するには、アカウントをXamanにインポートする必要があります。
+        jp: `**Xaman**（以前はXumm）は、XRPLおよびXahauエコシステムで最も広く使用されているモバイルウォレットです。これまでJavaScriptコードからウォレットを操作してきましたが、アカウントを視覚的に管理し、スマートフォンからトランザクションに署名し、分散型アプリケーションと対話するには、アカウントをXamanにインポートする必要があります。

 ### Xamanとは？

-Xamanは**iOS**と**Android**で利用できるモバイルアプリケーションで、以下として機能します：
+Xamanは**iOS**と**Android**で利用できるモバイルアプリケーションで、次のような機能を提供します：
 - **ウォレット**：デバイス上に鍵を安全に保存
- **トランザクション署名者**：QRコードのスキャンまたはxAppからトランザクションを承認できる
- **アカウントマネージャー**：複数のXahauおよびXRPLアカウントを管理できる
+- **トランザクションへの署名**：QRコードのスキャンまたはxAppからトランザクションを承認できる
+- **アカウント**：複数のXahauおよびXRPLアカウントを管理できる
 - **xAppsへのゲートウェイ**：Xamanに統合された分散型アプリケーション

 ダウンロード：[xaman.app](https://xaman.app)
@@ -1869,7 +1869,7 @@ Xamanは**iOS**と**Android**で利用できるモバイルアプリケーショ
 ### Xamanのインストール

 1. **App Store**（iOS）または**Google Play**（Android）を開く
-2. **「Xaman」**を検索（以前はXUMMという名前でした）
+2. **「Xaman」**を検索
 3. アプリをダウンロードしてインストール
 4. Xamanを開き、初期設定に従う：
   - **PINコード**または**生体認証**（指紋/Face ID）を設定する
@@ -1890,9 +1890,9 @@ Xamanをインストールしたら、コードで生成したアカウントを
 7. PINまたは生体認証で確認
 8. アカウントがXamanのアカウントリストに表示される

-### XamanにXahauネットワークを追加する
+### XamanにXahauテストネットを追加する

-デフォルトでは、Xamanは**XRPLメインネット**に接続しています。**Xahau**で作業するには、ネットワークを追加する必要があります：
+デフォルトでは、Xamanは**XRPLメインネット**に接続しています。**Xahauテストネット**で作業するには、ネットワークを追加する必要があります：

 1. Xamanで**設定**（歯車アイコン）に移動
 2. **「Advanced」（詳細）**セクションを見つける
@@ -1909,7 +1909,7 @@ Xamanをインストールしたら、コードで生成したアカウントを

 ### Xamanでトランザクションに署名する

-Xamanは2つの方法でトランザクションに署名できます：
+Xamanは次の2つの方法でトランザクションに署名できます。

 **アプリから直接**：
 - Xamanから直接ペイメントを送れる
@@ -1934,7 +1934,7 @@ Xamanは2つの方法でトランザクションに署名できます：

 ### 読み取り専用でのインポート

-トランザクションに署名せずにアカウントを**監視**だけしたい場合：
+トランザクションに署名せずにアカウントを**監視**だけしたい場合は次のようにします。

 1. Xamanで**「アカウントを追加」**をタップ
 2. **「既存のアカウントをインポート」**を選択
@@ -1942,7 +1942,7 @@ Xamanは2つの方法でトランザクションに署名できます：
 4. アドレス\`r...\`を入力（シードではない）
 5. アカウントが読み取り専用モードで追加される

-これは以下に役立つ：
+これは次のような場合に役立ちます。
 - 他のアカウント（取引所、コントラクト）の監視
 - スマートフォンでシードを公開せずにメインネットアカウントを監視する
 - 残高をすばやく確認する`,
--- a/src/data/modules/m04-querying-data.js
+++ b/src/data/modules/m04-querying-data.js
@@ -87,7 +87,7 @@ The Xahau API provides commands to query:

 ### 照会の種類

-Xahau APIは以下を照会するコマンドを提供しています：
+Xahau APIは次のようなコマンドを提供しています。
 - **サーバー情報**：\`server_info\`、\`server_state\`
 - **アカウント**：\`account_info\`、\`account_lines\`、\`account_objects\`、\`account_tx\`
 - **レジャー**：\`ledger\`、\`ledger_data\`、\`ledger_entry\`
@@ -96,9 +96,9 @@ Xahau APIは以下を照会するコマンドを提供しています：

 ### 重要な概念

- **レジャーインデックス**：番号で特定のレジャーを照会できる。最後に検証されたものには\`"validated"\`を使用
- **ドロップ（Drops）**：XAHの量はドロップで表現される（1 XAH = 1,000,000ドロップ）
- **マーカー（Markers）**：大量の結果をページングするために、APIはマーカーを使用する`,
+- **レジャーインデックス** (\`ledger_index\`)：番号で特定のレジャーを照会できる。最後に検証されたものには\`"validated"\`を使用
+- **ドロップ（drops）**：XAHの量はドロップで表現される（1 XAH = 1,000,000ドロップ）
+- **マーカー** (\`marker\`)：大量の結果をページングするために、APIはマーカーを使用する`,
      },
      codeBlocks: [
        {
@@ -383,16 +383,16 @@ You can query the details of a specific transaction using its **hash** with the

 ### アカウントオブジェクト

-\`account_objects\`コマンドはアカウントに関連するすべてのレジャーオブジェクトを返します：
+\`account_objects\`コマンドはアカウントに関連するすべてのレジャーオブジェクトを返します。
 - TrustLine（トラストライン）
 - Offer（DEXの注文）
 - URIToken（NFT）
 - インストールされたHook
- Hookのステート
+- HookState

 ### リアルタイムサブスクリプション

-\`subscribe\`コマンドを使用して、イベントが発生したときに通知を受け取ることができます：
+\`subscribe\`コマンドを使用して、イベントが発生したときに通知を受け取ることができます。
 - **ledger**：新しいレジャーが閉じるたびに通知
 - **transactions**：ネットワークのすべてのトランザクション
 - **accounts**：特定のアカウントに影響するトランザクション
@@ -749,7 +749,7 @@ Many API commands return paginated results. When there is more data than fits in
 - **Handle disconnections**: Listen for the client's \`disconnected\` event and reconnect automatically
 - **Rate limiting**: Public nodes may throttle requests. Add pauses between bulk requests
 - **Timeouts**: Configure a reasonable timeout to prevent your application from hanging`,
-        jp: `Xahau APIを使用する際、2つの側面をマスターすることが不可欠です：大量の結果セットの**ページネーション**と、堅牢なアプリケーションを構築するための**エラー処理**です。
+        jp: `Xahau APIを使用する際、大量の結果セットの**ページネーション**と、堅牢なアプリケーションを構築するための**エラー処理**といった2つの側面をマスターすることが不可欠です。

 ### マーカーシステム

@@ -1077,7 +1077,7 @@ These indexes are deterministic: you can always recalculate them if you know the

 \`ledger_entry\`を使用すると、**インデックス**（64文字の16進数ハッシュ）を使用してレジャーの特定のオブジェクトを照会できます。これは、必要なオブジェクトの正確な識別子がすでにわかっている場合に役立ちます。

-### 照会可能なオブジェクトタイプ
+### 照会可能なオブジェクトタイプの例

 | タイプ | 説明 |
 |---|---|
@@ -1090,7 +1090,7 @@ These indexes are deterministic: you can always recalculate them if you know the

 ### タイプフィルターを使用したaccount_objectsコマンド

-\`account_objects\`コマンドは、特定のタイプのオブジェクトのみをフィルタリングするために\`type\`パラメータを受け付けます。有効な値には：
+\`account_objects\`コマンドは、特定のタイプのオブジェクトのみをフィルタリングするために\`type\`パラメータを受け付けます。有効な値には次のようなものがあります。
 - \`"state"\` → RippleState（トラストライン）
 - \`"offer"\` → Offer（DEXの注文）
 - \`"uri_token"\` → URIToken
@@ -1098,11 +1098,11 @@ These indexes are deterministic: you can always recalculate them if you know the

 ### レジャーインデックスの理解

-レジャーの各オブジェクトには、その識別データのSHA-512Halfハッシュとして計算された**一意のインデックス**があります。例えば：
+レジャーの各オブジェクトには、その識別データのSHA-512Halfハッシュとして計算された**一意のインデックス**があります。例えば次のようなものがあります。
 - AccountRootのインデックスはアカウントアドレスから計算される
 - RippleStateのインデックスは2つのアカウントと通貨から計算される

-これらのインデックスは決定論的です：入力データがわかれば、いつでも再計算できます。`,
+これらのインデックスは決定論的です。入力データがわかれば、いつでも再計算できます。`,
      },
      codeBlocks: [

--- a/src/data/modules/m05-transaction-anatomy.js
+++ b/src/data/modules/m05-transaction-anatomy.js
@@ -163,7 +163,7 @@ Unlike blockchains with probabilistic finality (Bitcoin, Ethereum), in Xahau the

 ### 完全なフロー

-Xahauのトランザクションは、作成されてからレジャーに永久記録されるまで、**5つのフェーズ**を経ます：
+Xahauのトランザクションは、作成されてからレジャーに永久に記録されるまで、**5つのフェーズ**を経ます。

 1. **構築（Build）**: トランザクションのフィールドを定義します（タイプ、送信元、宛先、金額など）
 2. **準備（autofill）**: クライアントが技術的フィールドを自動的に埋めます（Fee、Sequence、LastLedgerSequence、NetworkID）
@@ -173,7 +173,7 @@ Xahauのトランザクションは、作成されてからレジャーに永久

 ### フェーズ1：構築

-トランザクションのフィールドを含むJavaScriptオブジェクトを定義します：
+トランザクションのフィールドを含むJavaScriptオブジェクトを定義します。

 \`\`\`
 const tx = {
@@ -188,12 +188,12 @@ const tx = {

 ### フェーズ2：準備（autofill）

-\`client.autofill(tx)\`メソッドがノードに問い合わせて不足フィールドを埋めます：
+\`client.autofill(tx)\`メソッドがノードに問い合わせて不足しているフィールドを埋めます。

 - **Fee**: トランザクションコスト（drops単位）。現在のネットワーク負荷に基づいて計算されます
- **Sequence**: アカウントのシーケンス番号（トランザクションごとに増加）
+- **Sequence**: アカウントのシーケンス番号（トランザクションを送信するごとに増加）
 - **LastLedgerSequence**: トランザクションを含められる最大レジャー番号（「ゴースト」トランザクションからの保護）
- **NetworkID**: ネットワーク識別子（testnet対mainnet）
+- **NetworkID**: ネットワーク識別子（testnet/mainnetなど）

 ### フェーズ3：署名

@@ -221,7 +221,7 @@ const tx = {
 3. **UNLの80%以上**が合意すると、組み込まれます
 4. レジャーが閉じられ、結果は**最終的かつ不可逆**です

-### どのくらいかかる？
+### 処理にはどのくらいの時間がかかる？

 送信から検証まで、通常**3〜5秒**かかります。これはXahauでレジャーが閉じるまでの時間です。ビットコインの10分ブロックや可変確認時間はありません。

@@ -649,14 +649,14 @@ You can attach data to any transaction using the **Memos** field:

 - **MemoType**: MIME type in hexadecimal (e.g., "text/plain")
 - **MemoData**: The content in hexadecimal
- Memos are **public** and permanent on the ledger
+- Memos are **public** and permanently stored as transaction data
 - They do not affect the transaction logic, they only store additional information
 - If you do not need to use them, it is recommended to avoid these fields to prevent storing unnecessary data on the blockchain`,
        jp: `Xahauのすべてのトランザクションは**特定のフィールドを持つオブジェクト**です。必須フィールド、任意フィールド、\`autofill()\`が埋めるフィールドがあります。各フィールドを理解することで、トランザクションを完全に制御できるようになります。

 ### すべてのトランザクションに共通するフィールド

-これらのフィールドは**すべてのトランザクションタイプ**に存在します：
+これらのフィールドは**すべてのトランザクションタイプ**に存在します。

 | フィールド | 必須 | 説明 |
 |---|---|---|
@@ -671,7 +671,7 @@ You can attach data to any transaction using the **Memos** field:

 ### TransactionType：トランザクションタイプ

-Xahauは多くのトランザクションタイプをサポートしています。最も一般的なもの：
+Xahauは多くのトランザクションタイプをサポートしています。最も一般的なものは次の通りです。

 - [Payment](https://xahau.network/docs/protocol-reference/transactions/transaction-types/payment/) — XAHまたはトークンの送金
 - [TrustSet](https://xahau.network/docs/protocol-reference/transactions/transaction-types/trustset/) — トラストラインの作成または変更
@@ -681,8 +681,8 @@ Xahauは多くのトランザクションタイプをサポートしています
 - [SetHook](https://xahau.network/docs/protocol-reference/transactions/transaction-types/sethook/) — Hookのインストールまたは管理（スマートコントラクト）
 - [URITokenMint](https://xahau.network/docs/protocol-reference/transactions/transaction-types/uritokenmint/) — NFTの作成（URIToken）
 - [URITokenBuy](https://xahau.network/docs/protocol-reference/transactions/transaction-types/uritokenbuy/) — URITokenの購入
- [URITokenCreateSellOffer](https://xahau.network/docs/protocol-reference/transactions/transaction-types/uritokencreateselloffer/) — URITokenの販売出品
- [EscrowCreate](https://xahau.network/docs/protocol-reference/transactions/transaction-types/escrowcreate/) — 条件付き支払いの作成
+- [URITokenCreateSellOffer](https://xahau.network/docs/protocol-reference/transactions/transaction-types/uritokencreateselloffer/) — URITokenの売却オファーの作成
+- [EscrowCreate](https://xahau.network/docs/protocol-reference/transactions/transaction-types/escrowcreate/) — エスクローの作成
 - [EscrowFinish](https://xahau.network/docs/protocol-reference/transactions/transaction-types/escrowfinish/) — エスクローの完了
 - [EscrowCancel](https://xahau.network/docs/protocol-reference/transactions/transaction-types/escrowcancel/) — エスクローのキャンセル

@@ -698,17 +698,17 @@ XahauのFeeは他のブロックチェーンとは異なります：

 ### Sequence：トランザクションの順序

-Sequenceはアカウントの**インクリメンタルカウンター**です：
+Sequenceはアカウントの**インクリメンタルカウンター**です。

 - アカウント有効化時に割り当てられた番号から開始します
- 成功したトランザクションごとに1増加します
+- トランザクションを送信し、ネットワークに登録されるごとに1増加します
 - トランザクションが**順序通りに**処理されることを保証します
 - 同じSequenceで2つのトランザクションを送信した場合、1つだけ処理されます
 - 中間のSequenceが欠落した場合（例：5、6、8を送信して7がない）、7が解決されるまで8以降のトランザクションはキューに入ります

 ### LastLedgerSequence：ゴーストトランザクション対策

-LastLedgerSequenceフィールドはトランザクションの**有効期限**です：
+LastLedgerSequenceフィールドはトランザクションの**有効期限**です。

 - 含められる**最大レジャー番号**を指定します
 - 現在のレジャーがこの番号を超えてもトランザクションが処理されていない場合、廃棄されます
@@ -717,7 +717,7 @@ LastLedgerSequenceフィールドはトランザクションの**有効期限**

 ### Flags：動作修飾子

-多くのトランザクションタイプは、動作を変更する**Flags**フィールドを受け付けます：
+多くのトランザクションタイプは、動作を変更する**Flags**フィールドを受け付けます。

 - FlagsはビットOR演算で組み合わせる**数値**です
 - 例：URITokenMintの\`Flags: 1\`で\`tfBurnable\`を有効化
@@ -726,11 +726,11 @@ LastLedgerSequenceフィールドはトランザクションの**有効期限**

 ### Memos：添付データ

-**Memos**フィールドを使ってトランザクションにデータを添付できます：
+**Memos**フィールドを使ってトランザクションにデータを添付できます。

 - **MemoType**：16進数のMIMEタイプ（例："text/plain"）
 - **MemoData**：16進数のコンテンツ
- Memosは**公開**でレジャーに永久保存されます
+- Memosは**公開情報**でトランザクション情報として永久に保存されます
 - トランザクションのロジックには影響せず、追加情報を保存するだけです
 - 必要でない場合は、ブロックチェーンに不必要なデータを保存しないためにこれらのフィールドの使用を避けることを推奨します`,
      },
@@ -1248,7 +1248,7 @@ Xahau supports **multi-signing**: a transaction that requires signatures from **

 ### デジタル署名とは？

-デジタル署名は以下を証明する数学的証明です：
+デジタル署名は次のことを証明する数学的証明です。
 1. **あなたがトランザクションを作成した**（認証）
 2. **署名後に誰も変更していない**（完全性）
 3. **署名したことを否定できない**（否認不可）
@@ -1280,7 +1280,7 @@ Xahauは2つの暗号アルゴリズムをサポートしています：

 \`\`\`
 wallet.sign(prepared)
-// 返す：{ tx_blob: "1200002280000000...", hash: "A1B2C3..." }
+// 結果：{ tx_blob: "1200002280000000...", hash: "A1B2C3..." }
 \`\`\`

 - **tx_blob**：シリアライズされた署名済みトランザクション（16進数）
@@ -1288,7 +1288,7 @@ wallet.sign(prepared)

 ### 署名の検証

-ノードがtx_blobを受信すると：
+ノードがtx_blobを受信すると次のようになります。

 1. blobをデシリアライズしてフィールドを抽出します
 2. \`SigningPubKey\`と\`TxnSignature\`を取り出します
@@ -1300,7 +1300,7 @@ tx_blobの**1ビットでも**変更されると、署名が無効になりト

 ### オフライン署名

-**インターネット接続なし**でトランザクションに署名できます：
+**インターネット接続なし**でトランザクションに署名できます。

 1. 接続デバイスで：\`autofill()\`でトランザクションを準備します
 2. 準備済みトランザクションをオフラインデバイスにコピーします
@@ -1308,14 +1308,14 @@ tx_blobの**1ビットでも**変更されると、署名が無効になりト
 4. \`tx_blob\`を接続デバイスにコピーします
 5. \`client.submit(tx_blob)\`で送信します

-これは**コールドウォレット**に役立ちます—秘密鍵がインターネット接続デバイスに触れることはありません。
+これは**コールドウォレット**からトランザクションに署名する場合に役立ちます。秘密鍵がインターネット接続デバイスに触れることはありません。

-### マルチ署名（MultiSign）
+### マルチシグ（MultiSign）

-Xahauは**マルチ署名**をサポートしています：有効になるために**複数のアカウントの署名**を必要とするトランザクション。\`SignerListSet\`で設定します：
+Xahauは**マルチシグ**をサポートしています。**複数のアカウントの署名**を必要とするためには\`SignerListSet\`トランザクションを使用します。

 - 重みを持つ署名者リスト（SignerList）を定義します
- 最小クォーラムを設定します
+- 最小の閾値を設定します
 - 各署名者がトランザクションに個別に署名します
 - 署名を組み合わせて一緒に送信します
 - 共有アカウント、DAO、または追加セキュリティに役立ちます`,
@@ -1956,7 +1956,7 @@ result.result.hash                     → Unique transaction hash

 ### submit対submitAndWait

-\`xahau\`ライブラリはトランザクション送信に2つのメソッドを提供します：
+\`xahau\`ライブラリはトランザクション送信に次の2つのメソッドを提供します。

 **client.submit(tx_blob)**：
 - トランザクションを送信して**即座に**返します
@@ -1972,7 +1972,7 @@ result.result.hash                     → Unique transaction hash

 ### 結果コードのカテゴリ

-トランザクション結果は**プレフィックス**に基づいてカテゴリに分けられます：
+トランザクション結果は**接頭辞**に基づいてカテゴリに分けられます：

 ### tes：成功

@@ -2005,7 +2005,7 @@ result.result.hash                     → Unique transaction hash
 | **tefMAX_LEDGER** | LastLedgerSequenceがすでに過去（トランザクション期限切れ） |
 | **tefALREADY** | トランザクションはすでにキューにある |

-### tem：フォームエラー
+### tem：形式エラー

 \`tem\`コードはトランザクションが**不正な形式**で、有効になり得ないことを示します：

@@ -2024,12 +2024,12 @@ result.result.hash                     → Unique transaction hash
 | コード | 意味 |
 |---|---|
 | **terPRE_SEQ** | 前のトランザクションが保留中（前のSequence） |
-| **terQUEUED** | トランザクションはキューで待機中（飛行中が多すぎる） |
+| **terQUEUED** | トランザクションはキューで待機中（処理中のトランザクションが多すぎる） |
 | **terINSUF_FEE_B** | 現在の負荷に対してFeeが不足 |

 ### 完全な結果の読み取り

-結果オブジェクトには必要なすべての情報が含まれています：
+結果オブジェクトには必要なすべての情報が含まれています。

 \`\`\`
 result.result.meta.TransactionResult  → コード（tesSUCCESSなど）
@@ -2543,11 +2543,11 @@ If a validator computes a different hash from 80% of the UNL, its ledger is disc

 ### AffectedNodes：トランザクションの足跡

-\`meta.AffectedNodes\`フィールドは、レジャーで**正確に何が変わったか**を説明する配列です。影響を受けた各ノードは3つのタイプのいずれかになります：
+\`meta.AffectedNodes\`フィールドは、レジャーで**正確に何が変わったか**を説明する配列です。影響を受けた各ノードは次の3つのタイプのいずれかになります。

 ### CreatedNode：新しいオブジェクト

-レジャーに新しいオブジェクトが作成されました：
+レジャーに新しいオブジェクトが作成された。

 \`\`\`
 {
@@ -2563,11 +2563,11 @@ If a validator computes a different hash from 80% of the UNL, its ledger is disc
 }
 \`\`\`

-例：新しいトラストライン、新しいDEXオファー、新しいURIToken。
+例：新しいトラストライン、新しいDEXオファー、新しいURIToken

 ### ModifiedNode：変更されたオブジェクト

-既存のオブジェクトが変更されました：
+既存のオブジェクトが変更された。

 \`\`\`
 {
@@ -2589,7 +2589,7 @@ If a validator computes a different hash from 80% of the UNL, its ledger is disc

 ### DeletedNode：削除されたオブジェクト

-レジャーからオブジェクトが削除されました：
+レジャーからオブジェクトが削除された。

 \`\`\`
 {
@@ -2604,11 +2604,11 @@ If a validator computes a different hash from 80% of the UNL, its ledger is disc
 }
 \`\`\`

-例：完了/キャンセルされたオファー、削除されたトラストライン（残高ゼロ）、バーンされたURIToken。
+例：完了/キャンセルされたオファー、削除されたトラストライン（残高ゼロ）、バーンされたURIToken

 ### 残高の変化：お金の流れを追う

-支払いトランザクションでは、\`AccountRoot\`タイプの\`ModifiedNode\`エントリを観察して、お金がどのように移動したかを正確に追跡できます：
+Paymentトランザクションでは、\`AccountRoot\`タイプの\`ModifiedNode\`エントリを観察して、お金がどのように移動したかを正確に追跡できます。

 - 送信元アカウント：\`Balance\`が減少（XAHを送信）
 - 宛先アカウント：\`Balance\`が増加（XAHを受信）
@@ -2616,14 +2616,14 @@ If a validator computes a different hash from 80% of the UNL, its ledger is disc

 トークン（IOU）の場合、変更は\`RippleState\`タイプの\`ModifiedNode\`エントリで確認できます。

-### リザーブ：リザーブシステム
+### 準備金：準備金システム

-Xahauレジャーは利用可能な残高に影響する**リザーブ**システムを使用します：
+Xahauでは利用可能な残高に影響する**準備金**システムを使用します。

- **基本リザーブ**：1 XAH—アカウントが存在するための最小値
- **所有者リザーブ**：アカウントが所有する各オブジェクトにつき0.2 XAH
+- **基本準備金**：1 XAH — アカウントが存在するための最小値
+- **所有者準備金**：アカウントが所有する各オブジェクトにつき0.2 XAH

-レジャー内の各オブジェクト（トラストライン、オファー、URIToken、Hook）がリザーブを増加させます。オブジェクトを削除するまで、リザーブされたXAHは使用できません。
+レジャー内の各オブジェクト（トラストライン、オファー、URIToken、Hook）が準備金を増加させます。オブジェクトを削除するまで、準備金としてロックされたXAHは使用できません。

 ### レジャー内の処理順序

@@ -2638,7 +2638,7 @@ Xahauレジャーは利用可能な残高に影響する**リザーブ**シス

 ### レジャーハッシュ

-レジャーが閉じると、以下を要約した**ハッシュ**が計算されます：
+レジャーが閉じると、以下を要約した**ハッシュ**が計算されます。
 - 前のレジャーのハッシュ（レジャーの連鎖）
 - 含まれるすべてのトランザクションとそのメタデータ
 - レジャーの完全な状態（状態ツリー）
--- a/src/data/modules/m06-payments.js
+++ b/src/data/modules/m06-payments.js
@@ -163,7 +163,7 @@ XahauのFeeは非常に低く予測可能です：

 ### ネイティブXAHの代わりにIOU（トークン）を送る

-ネイティブXAHを送る場合、\`Amount\`フィールドはdrops単位の**文字列**です。しかし**IOU**（USDやEURなど、アカウントが発行したトークン）を送る場合、\`Amount\`は3つのフィールドを持つ**オブジェクト**になります：
+ネイティブXAHを送る場合、\`Amount\`フィールドはdrops単位の**文字列**です。しかし**IOU**（USDやEURなど、アカウントが発行したトークン）を送る場合、\`Amount\`は3つのフィールドを持つ**オブジェクト**になります。

 \`\`\`
 {
@@ -175,7 +175,7 @@ XahauのFeeは非常に低く予測可能です：

 **IOUを送るための前提条件：**
 - **送信者に残高が必要**：あなたのアカウントはそのIOUの残高を持っている必要があります。以前の支払い、DEXでの取引、またはトークン発行者から直接取得できます。
- **受信者にTrustLineが必要**：宛先アカウントは同じ発行者のそのIOUに対して事前にTrustLine（\`TrustSet\`）を作成している必要があります。TrustLineなしでは、\`tecPATH_DRY\`または\`tecNO_LINE\`で支払いが失敗します。
+- **受信者にトラストラインが必要**：宛先アカウントは同じ発行者のそのIOUに対して事前にトラストライン（\`TrustSet\`）を作成している必要があります。トラストラインなしでは、\`tecPATH_DRY\`または\`tecNO_LINE\`で支払いが失敗します。

 ### なぜXAH以外のIOUやトークンにこれらのフィールドが必要なのか？

@@ -183,10 +183,10 @@ XahauのFeeは非常に低く予測可能です：

 ### Paymentの詳細情報

-Paymentトランザクションには、ここで説明するよりも多くのオプションフィールド、フラグ、エラーコードがあります。完全なリファレンスは[公式ドキュメント](https://xahau.network/docs/protocol-reference/transactions/transaction-types/payment/)を参照してください。
+Paymentトランザクションには、ここで説明するよりも多くの任意フィールド、フラグ、エラーコードがあります。完全なリファレンスは[公式ドキュメント](https://xahau.network/docs/protocol-reference/transactions/transaction-types/payment/)をご覧ください。

-そこでは以下が見つかります：
- すべてのオプションフィールド（SendMax、DeliverMin、InvoiceIDなど）
+リファレンスには次のような情報があります。
+- すべての任意フィールド（SendMax、DeliverMin、InvoiceIDなど）
 - 利用可能なフラグ（tfPartialPayment、tfLimitQualityなど）
 - エラーコードの完全なリストとその原因
 - 特殊ケースと高度な動作`,
@@ -569,16 +569,16 @@ Each transaction returns a result code:
 - \`tecNO_DST_INSUF_XAH\`: The destination does not have enough XAH for the reserve`,
        jp: `基本的な支払いに加えて、Xahauは支払いにコンテキストと機能を追加できる追加フィールドをサポートしています。

-### Destination Tag
+### 宛先タグ(Destination Tag)

-**Destination Tag**は受信者が個別の支払いを識別できる整数です。特に以下に役立ちます：
+**宛先タグ**は受信者が個別の支払いを識別できる整数です。特に次のような場合に役立ちます。
 - **取引所**：どのユーザーへの入金かを識別する
 - **サービス**：支払いを注文または請求書と関連付ける
 - アカウントに\`RequireDestTag\`フラグが有効な場合、**タグなしでは支払いを送れません**

-システムはDestination Tagに最大32ビットを許可しており、最大4,294,967,295の整数を使用できます。支払い前に受信者が求める正しいDestination Tagを常に確認することが重要です。タグなしまたは間違ったタグで必要とするアカウントに支払いを送ると、資金を失う可能性があります。
+システムは宛先タグに最大32ビットを許可しており、最大4,294,967,295の整数を使用できます。支払い前に受信者が求める正しい宛先タグを常に確認することが重要です。タグなしまたは間違ったタグで必要とするアカウントに支払いを送ると、資金を失う可能性があります。

-また**Source Tag**も存在し、送信者のために同じ機能を提供します。ただし、実際にはDestination Tagの方がはるかに一般的で広く使われています。
+また**送信者タグ(Source Tag)**も存在し、送信者のために同じ機能を提供します。ただし、実際には宛先タグの方がはるかに一般的で広く使われています。

 ### Memo

@@ -1068,8 +1068,8 @@ The \`tfPartialPayment\` flag (value: \`0x00020000\`) allows a payment to delive

 ### パスファインディングシステム

-パスファインディングは通貨間の変換ルートを見つけるメカニズムです：
- Xahauはトラストラインとデックス注文を通じた**パス**を検索します
+パスファインディングは通貨間の変換ルートを見つけるメカニズムです。
+- XahauはトラストラインとDEX注文を通じた**パス**を検索します
 - 複数の中間変換をチェーンできます
 - 常に利用可能な**最良のレート**を見つけようとします

@@ -1084,17 +1084,17 @@ The \`tfPartialPayment\` flag (value: \`0x00020000\`) allows a payment to delive

 ### ripple_path_findコマンド

-クロスカレンシー支払いを送る前に、\`ripple_path_find\`を使って：
+クロスカレンシー支払いを送る前に、\`ripple_path_find\`を使って次のことが可能です。
 - 2つの通貨間のパスが存在するか確認する
 - トランザクションに必要な\`Paths\`を取得する
 - 推定コスト（\`source_amount\`）を知る

 ### 部分支払い（tfPartialPayment）

-\`tfPartialPayment\`フラグ（値：\`0x00020000\`）は支払いが\`Amount\`に指定された額より**少なく**配信することを許可します：
+\`tfPartialPayment\`フラグ（値：\`0x00020000\`）は支払いが\`Amount\`に指定された額より**少なく**送信することを許可します。
 - クエリと実行の間で流動性が変わる可能性がある場合に便利
 - \`DeliverMin\`を使って許容できる最小額を設定する
- **重要**：支払いを受け取る際、メタデータの\`delivered_amount\`を常に確認してください。\`Amount\`フィールドでは**なく**。攻撃者は高い\`Amount\`を表示しながらずっと少ない額を配信する部分支払いを送れます`,
+- **重要**：支払いを受け取る際、メタデータの\`delivered_amount\`を常に確認してください。\`Amount\`フィールドでは**なく**。攻撃者は高い\`Amount\`を表示しながらずっと少ない額を送信する部分支払いを送れます`,
      },
      codeBlocks: [

--- a/src/data/modules/m07-tokens.js
+++ b/src/data/modules/m07-tokens.js
@@ -12,7 +12,7 @@ export default {
      title: {
        es: "TrustLines y el modelo de tokens en Xahau",
        en: "TrustLines and the token model in Xahau",
-        jp: "TrustLineとXahauのトークンモデル",
+        jp: "トラストラインとXahauのトークンモデル",
      },
      theory: {
        es: `En Xahau, los tokens fungibles funcionan de manera diferente a ERC-20 en Ethereum. No necesitas desplegar un smart contract para crear un token. En su lugar, se usa un sistema basado en **TrustLines** (líneas de confianza).
@@ -107,50 +107,50 @@ One of the advantages of Xahau's token system is that the issuing account can co
 **Important**: Some configurations are irreversible (\`NoFreeze\`) and others must be activated before issuing tokens (\`Clawback\`). Plan your issuer's configuration carefully before you start distributing tokens.

 We will cover each of these configurations in detail in the following sections of this module.`,
-        jp: `XahauのFungibleトークンは、EthereumのERC-20とは異なる仕組みで動作します。トークンを作成するためにスマートコントラクトをデプロイする必要はありません。代わりに、**TrustLine**（信頼ライン）に基づくシステムが使用されます。
+        jp: `Xahauの(代替可能)トークンは、EthereumのERC-20とは異なる仕組みで動作します。トークンを作成するためにスマートコントラクトをデプロイする必要はありません。代わりに、**TrustLine**（トラストライン）に基づくシステムが使用されます。

 ### 仕組み

 1. **発行者（Issuer）**: どのアカウントもトークンを発行できます。発行アカウントはそのトークンの「中央銀行」となります
-2. **TrustLine**: トークンを受け取るには、受取人が先に発行者への**TrustLine**を作成する必要があります。これは「このアカウントをこのトークンのX量まで信頼する」と宣言するようなものです
-3. **転送**: TrustLineが存在すれば、発行者はPaymentトランザクションで受取人にトークンを送ることができます
+2. **トラストライン**: トークンを受け取るには、受取人が先に発行者への**トラストライン**を作成する必要があります。これは「このアカウントをこのトークンのX量まで信頼する」と宣言するようなものです
+3. **転送**: トラストラインが存在すれば、発行者はPaymentトランザクションで受取人にトークンを送ることができます

 ### トークンの識別

-各トークンは2つのフィールドで識別されます：
+各トークンは次の2つのフィールドで識別されます。
 - **currency**: 3文字のコード（例："USD"、"EUR"）または長い名前用の40文字の16進数コード
 - **issuer**: 発行アカウントのアドレス

 同じ\`currency\`でも\`issuer\`が異なれば、それは**まったく別のトークン**です。

-### TrustLine vs ERC-20
+### トラストライン vs ERC-20

-| 特徴 | ERC-20 (Ethereum) | TrustLine (Xahau) |
+| 特徴 | ERC-20 (Ethereum) | トラストライン (Xahau) |
 |---|---|---|
 | トークン作成 | Solidityコントラクトのデプロイ | アカウントから直接発行 |
-| トークン受取 | 自動（許可不要） | TrustLineの作成が必要（オプトイン） |
-| 数量制限 | コントラクトで定義 | 受取人がTrustLineで定義 |
+| トークン受取 | 自動（許可不要） | トラストラインの作成が必要（オプトイン） |
+| 数量制限 | コントラクトで定義 | 受取人がトラストラインで定義 |
 | 転送 | コントラクト関数 | ネイティブPaymentトランザクション |
 | コスト | 高価なガス代 | 最小限のFee（〜12 drops） |

-### アカウントリザーブ
+### アカウント準備金

-各TrustLineはアカウントの**オーナーリザーブ**を消費します。つまり、作成するTrustLineごとに追加のXAHをロックしておく必要があります。
+各トラストラインはアカウントの**所有者準備金**を消費します。つまり、作成するトラストラインごとに追加のXAHをロックしておく必要があります。

 ### トークン作成時の発行者設定

-Xahauのトークンシステムの利点の一つは、発行アカウントがトークン発行**前後**に\`AccountSet\`トランザクションを使って様々なプロパティを設定できることです。これらの設定はネットワーク上でのトークンの動作を定義します：
+Xahauのトークンシステムの利点の一つは、発行アカウントがトークン発行**前後**に\`AccountSet\`トランザクションを使って様々なプロパティを設定できることです。これらの設定はネットワーク上でのトークンの動作を定義します。

 | 設定 | Flag / フィールド | 説明 |
 |---|---|---|
 | **DefaultRipple** | \`SetFlag: 8\` | 第三者間でトークンを自由に転送できるようにします。このフラグなしでは、トークンは発行者との間でしか移動できません |
-| **TransferFee** | \`TransferRate\` | 第三者間の転送ごとに割合（例：0.1%）を徴収します。フィーは発行者に入ります |
-| **RequireAuth** | \`SetFlag: 2\` | ホルダーがトークンを受け取れるようにする前に、発行者が各TrustLineを承認する必要があります。KYCトークンに最適 |
-| **Freeze** | \`SetFlag: 7\`（グローバル） | 個別またはすべてのTrustLineを凍結して転送を防ぐことができます |
+| **TransferFee** | \`TransferRate\` | 第三者間の転送ごとに割合（例：0.1%）を徴収します。手数料は発行者に入ります |
+| **RequireAuth** | \`SetFlag: 2\` | ホルダーがトークンを受け取れるようにする前に、発行者が各トラストラインを承認する必要があります。KYCを必要とするトークンに最適 |
+| **Freeze** | \`SetFlag: 7\`（グローバル） | 個別またはすべてのトラストラインを凍結して転送を防ぐことができます |
 | **NoFreeze** | \`SetFlag: 6\` | 凍結能力の**恒久的**かつ取り消し不能な放棄。信頼のシグナル |
-| **Clawback** | \`SetFlag: 17\` | 発行者がどのホルダーからもトークンを回収できるようにします。TrustLineを作成する**前**に有効化が必要 |
+| **Clawback** | \`SetFlag: 17\` | 発行者がどのホルダーからもトークンを回収できるようにします。トラストラインを作成する**前**に有効化が必要 |

-**重要**: 一部の設定は取り消し不能（\`NoFreeze\`）で、他はトークン発行前に有効化する必要があります（\`Clawback\`）。トークンの配布を開始する前に、発行者の設定を慎重に計画してください。
+**重要**: 一部の設定は取り消し不能（\`NoFreeze\`）で、一部はトークン発行前に有効化する必要があります（\`Clawback\`）。トークンの発行を開始する前に、発行者の設定を慎重に計画してください。

 これらの設定の詳細は、このモジュールの以降のセクションで説明します。`,
      },
@@ -527,7 +527,7 @@ console.log(currencyToHex("EURZ"));
 | Create TrustLine | \`TrustSet\` | Reserve account |
 | Issue supply | \`Payment\` (Amount as IOU) | Issuer |
 | Distribute | \`Payment\` (Amount as IOU) | Reserve account |`,
-        jp: `TrustLineの仕組みを理解したところで、独自トークンを作成して配布するための完全なプロセスを見ていきましょう。他のブロックチェーンとは異なり、Xahauでは**コントラクトをデプロイする必要はありません**。プロセスはすべてネイティブトランザクションで行われます。
+        jp: `トラストラインの仕組みを理解したところで、独自トークンを作成して配布するための完全なプロセスを見ていきましょう。他のブロックチェーンとは異なり、Xahauでは**コントラクトをデプロイする必要はありません**。プロセスはすべてネイティブトランザクションで行われます。

 ### プロセスの概要

@@ -536,18 +536,18 @@ console.log(currencyToHex("EURZ"));
 1. **発行アカウントの準備**: トークン発行専用のアカウントを作成（または使用）する
 2. **発行者フラグの設定**: 第三者間でトークンが転送できるよう\`DefaultRipple\`を有効化する
 3. **リザーブ/配布アカウントの準備**: 初期サプライを受け取り、トークンを配布するための2つ目のアカウントを作成（または使用）する
-4. **リザーブアカウントからTrustLineを作成**: 配布アカウントが発行者へのTrustLineを作成する
-5. **トークンの発行**: 発行者がPaymentトランザクションでリザーブアカウントに全サプライを送信する
-6. **配布**: リザーブアカウントからエンドユーザーにトークンを配布する（ユーザーはあらかじめTrustLineを持っている必要がある）
+4. **リザーブアカウントからトラストラインを作成**: 配布アカウントが発行者へのトラストラインを作成する
+5. **トークンの発行**: 発行者がPaymentトランザクションでリザーブアカウントに全供給量を送信する
+6. **配布**: リザーブアカウントからエンドユーザーにトークンを配布する（ユーザーはあらかじめトラストラインを持っている必要がある）

 ### なぜ2つのアカウントを分けるのか？

-**発行アカウント**と**配布アカウント**を分けることはベストプラクティスです：
+**発行アカウント**と**配布アカウント**を分けることはベストプラクティスとして推奨されています。

 - **発行アカウント**: トークンの発行と設定（freeze、clawbackなど）にのみ使用。マルチサインで保護したり、設定完了後にマスターキーを無効化することができる
- **配布/リザーブアカウント**: 流通サプライを保持し、日常業務（DEXでの販売、ユーザーへの配布など）に使用する
+- **配布/リザーブアカウント**: 流通供給量を保持し、日常業務（DEXでの販売、ユーザーへの配布など）に使用する

-この分離によりリスクが低減されます：配布アカウントが侵害された場合、発行者がトークンを凍結できます。すべてが1つのアカウントにある場合、侵害により発行と配布の両方が危険にさらされます。
+この分離によりリスクが低減されます。配布アカウントが侵害された場合、発行者がトークンを凍結できます。すべてが1つのアカウントにある場合、侵害により発行と配布の両方が危険にさらされます。

 ### 通貨コード：3文字 vs 16進数

@@ -571,8 +571,8 @@ console.log(currencyToHex("EURZ"));
 | ステップ | トランザクション | 実行アカウント |
 |---|---|---|
 | 発行者を設定 | \`AccountSet\` (SetFlag: 8) | 発行者 |
-| TrustLineを作成 | \`TrustSet\` | リザーブアカウント |
-| サプライを発行 | \`Payment\`（IOUとしてAmount） | 発行者 |
+| トラストラインを作成 | \`TrustSet\` | リザーブアカウント |
+| 供給量を発行 | \`Payment\`（IOUとしてAmount） | 発行者 |
 | 配布 | \`Payment\`（IOUとしてAmount） | リザーブアカウント |`,
      },
      codeBlocks: [
@@ -580,7 +580,7 @@ console.log(currencyToHex("EURZ"));
          title: {
            es: "Proceso completo: configurar emisor, crear TrustLine, emitir y distribuir token",
            en: "Complete process: configure issuer, create TrustLine, issue and distribute token",
-            jp: "完全なプロセス：発行者の設定、TrustLineの作成、トークンの発行と配布",
+            jp: "完全なプロセス：発行者の設定、トラストラインの作成、トークンの発行と配布",
          },
          language: "javascript",
          code: {
@@ -1136,24 +1136,24 @@ For token names longer than 3 characters, a 40-character hexadecimal code is use
 - Example: "EURZ" -> hex -> padded to 40 chars`,
        jp: `トークンを作成したら、残高の照会、発行アカウントの設定、ユーザー間のトークン転送など、さまざまな側面を管理できます。

-### TrustLineと残高の照会
+### トラストラインと残高の照会

-\`account_lines\`コマンドはアカウントのすべてのTrustLineを返し、保有または発行した各トークンの現在の残高を表示します。
+\`account_lines\`コマンドはアカウントのすべてのトラストラインを返し、保有または発行した各トークンの現在の残高を表示します。

 ### 発行者の設定

 発行アカウントで重要なフラグを設定できます：

 - **DefaultRipple**: 発行者を経由せずに第三者間でトークンを転送できるようにします。トークンを自由に転送可能にしたい場合は**有効化が必要**です
- **RequireAuth**: 誰かがトークンを受け取れるようにする前に、発行者が各TrustLineを承認する必要があります
+- **RequireAuth**: 誰かがトークンを受け取れるようにする前に、発行者が各トラストラインを承認する必要があります

 ### 第三者間の転送（Rippling）

-**DefaultRipple**フラグなしでは、トークンは発行者にしか送り返せません。有効化すると、トークンは「リップル」できます。つまり、同じ発行者へのTrustLineを持つアカウント間で転送できるようになります。
+**DefaultRipple**フラグなしでは、トークンは発行者にしか送り返せません。有効化すると、トークンは「ripple(波及)」できます。つまり、同じ発行者へのトラストラインを持つアカウント間で転送できるようになります。

 ### 特殊な通貨コード

-3文字を超えるトークン名には、40文字の16進数コードが使用されます：
+3文字を超えるトークン名には、40文字の16進数コードが使用されます。
 - 形式：名前を16進数に変換し、ゼロで埋める
 - 例："EURZ" -> hex -> 40文字に埋める`,
      },
@@ -1373,7 +1373,7 @@ When a new order matches an existing one (prices cross), it is automatically exe
 - **tfImmediateOrCancel**: The order executes immediately against existing orders. Whatever isn't filled is canceled instantly. Nothing remains in the order book
 - **tfPassive**: The order only executes against existing orders with an equal or better price. It is not placed in the book if there's no immediate match
 - **tfFillOrKill**: The order is either fully executed or canceled. Partial executions are not allowed
- **tfSell**: Indicates the order is a sell (rather than a buy). Affects how TakerPays and TakerGets are interpreted
+- **tfSell**: Exchange the entire TakerGets amount, even if it means obtaining more than the TakerPays amount in exchange.

 Visit more information about flags in the [official documentation](https://xahau.network/docs/protocol-reference/transactions/transaction-types/offercreate/#offercreate-flags).

@@ -1392,12 +1392,12 @@ All in a single transaction, transparently. This significantly improves DEX liqu

 ### OfferCreate：DEXに注文を出す

-\`OfferCreate\`トランザクションにより、DEXの注文書に買いまたは売り注文を出すことができます。2つの主要フィールドがあります：
+\`OfferCreate\`トランザクションにより、DEXのオーダーブックに買いまたは売り注文を出すことができます。次の2つの主要フィールドがあります。

 - **TakerPays**: **受け取りたい**もの（「テイカー」が支払うもの）
 - **TakerGets**: **提供する意思がある**もの（「テイカー」が受け取るもの）

-例えば、100 USDをXAHで売りたい場合：
+例えば、100 USDをXAHで売りたい場合は次のように設定します。
 - TakerPays: 受け取りたいXAHの量
 - TakerGets: 100 USD（提供するもの）

@@ -1407,32 +1407,32 @@ All in a single transaction, transparently. This significantly improves DEX liqu

 ### 注文書の仕組み

-DEXは各トークンペアの**注文書**（オーダーブック）を管理します：
+DEXは各トークンペアの**オーダーブック**を管理します。
 - **Bids（買い注文）**: トークンを買いたい注文
 - **Asks（売り注文）**: トークンを売りたい注文

-新しい注文が既存の注文と一致した場合（価格が交差）、完全にまたは部分的に自動実行されます。
+新しい注文が既存の注文と一致（価格が交差）した場合、完全にまたは部分的に自動的に約定します。

 ### OfferCreateの特殊フラグ

- **tfImmediateOrCancel**: 注文は既存の注文に対して即座に実行されます。満たされなかった部分は即座にキャンセルされます。注文書に何も残りません
- **tfPassive**: 注文は同等またはより良い価格の既存注文に対してのみ実行されます。即時マッチがない場合、注文書には追加されません
- **tfFillOrKill**: 注文は完全に実行されるかキャンセルされます。部分的な実行は許可されません
- **tfSell**: 注文が（買いではなく）売りであることを示します。TakerPaysとTakerGetsの解釈方法に影響します
+- **tfImmediateOrCancel**: 注文は既存の注文に対して即座に約定します。約定しななかった部分は即座にキャンセルされます。オーダーブックには注文は残りません
+- **tfPassive**: 注文は同等またはより良い価格の既存注文に対してのみ約定します。即時マッチがない場合、オーダーブックには追加されません
+- **tfFillOrKill**: 注文は完全に約定されるかキャンセルされます。部分的な約定は許可されません
+- **tfSell**: TakerPaysの金額よりも多く取得することになっても、TakerGetsの金額を約定します。

 フラグの詳細については[公式ドキュメント](https://xahau.network/docs/protocol-reference/transactions/transaction-types/offercreate/#offercreate-flags)をご覧ください。

-### 注文書の照会：book_offers
+### オーダーブックの照会：book_offers

 \`book_offers\`コマンドでトークンペアの未決注文を表示できます。最良の注文を価格順に返します。

 ### XAHを通じたオートブリッジング

-XahauのDEXはXAHを通じてマルチホップ取引を自動的にルーティングできます。USDをEURに交換したいが直接USD/EUR注文がない場合、DEXは：
+XahauのDEXはXAHを通じてマルチホップ取引を自動的にルーティングできます。USDをEURに交換したいが直接USD/EUR注文がない場合、DEXは次の処理を1つのトランザクションで透過的に行います。
 1. USDをXAHに売る
 2. XAHでEURを買う

-これをすべて1つのトランザクションで透過的に行います。これによりDEXの流動性が大幅に向上します。`,
+これによりDEXの流動性が大幅に向上します。`,
      },
      codeBlocks: [
        {
@@ -1897,8 +1897,8 @@ cancelOffer();`,
          title: { es: "OfferCreate: anatomía de una orden", en: "OfferCreate: anatomy of an order", jp: "OfferCreate：注文の構造" },
          content: {
            es: "TakerPays → Lo que quieres RECIBIR\nTakerGets → Lo que estás dispuesto a DAR\n\nFlags especiales:\n• tfImmediateOrCancel → Ejecutar o cancelar\n• tfPassive → Solo match existente\n• tfFillOrKill → Ejecutar todo o nada\n• tfSell → Indica que es una venta\n\nOfferCancel → Cancelar orden abierta",
-            en: "TakerPays -> What you want to RECEIVE\nTakerGets -> What you are willing to GIVE\n\nSpecial flags:\n• tfImmediateOrCancel -> Execute or cancel\n• tfPassive -> Only match existing\n• tfFillOrKill -> Execute all or nothing\n• tfSell -> Indicates it's a sell\n\nOfferCancel -> Cancel open order",
-            jp: "TakerPays -> 受け取りたいもの\nTakerGets -> 提供する意思があるもの\n\n特殊フラグ：\n• tfImmediateOrCancel -> 実行またはキャンセル\n• tfPassive -> 既存注文にのみマッチ\n• tfFillOrKill -> 全量実行またはキャンセル\n• tfSell -> 売り注文であることを示す\n\nOfferCancel -> 未決注文をキャンセル",
+            en: "TakerPays -> What you want to RECEIVE\nTakerGets -> What you are willing to GIVE\n\nSpecial flags:\n• tfImmediateOrCancel -> Execute or cancel\n• tfPassive -> Only match existing\n• tfFillOrKill -> Execute all or nothing\n• tfSell -> Receive as much as TakerGets amount\n\nOfferCancel -> Cancel open order",
+            jp: "TakerPays -> 受け取りたいもの\nTakerGets -> 提供する意思があるもの\n\n特殊フラグ：\n• tfImmediateOrCancel -> 実行またはキャンセル\n• tfPassive -> 既存注文にのみマッチ\n• tfFillOrKill -> 全量実行またはキャンセル\n• tfSell -> 可能な限り多くの金額を受け取る\n\nOfferCancel -> 未決注文をキャンセル",
          },
          visual: "🔄",
        },
@@ -1996,22 +1996,22 @@ The issuer can charge a percentage on each transfer of their token between third
 - Configured with the \`TransferRate\` field in \`AccountSet\`
 - The value is an integer: 1000000000 = 0%, 1001000000 = 0.1%, 1010000000 = 1%
 - Only applies to transfers between third parties, not when sending to the issuer
- Example: With a 0.1% fee, sending 100 tokens charges 100.1 from the sender
+- Example: With a 0.1% fee, sending 100 tokens receives 99.9 tokens from the receiver (charges 0.1 from the receiver)

 ### Authorized TrustLines: RequireAuth

 The \`RequireAuth\` flag (asfRequireAuth) on the issuing account requires the issuer to **explicitly authorize** each TrustLine before a holder can receive tokens. Useful for tokens that need KYC or prior verification.`,
-        jp: `Xahauはトークン発行者に高度な制御ツールを提供します：**Freeze**（凍結）、**Clawback**（強制回収）、**Transfer fees**（転送手数料）、**Authorized TrustLines**（承認済みTrustLine）。
+        jp: `Xahauはトークン発行者に**Freeze**（凍結）、**Clawback**（強制回収）、**Transfer fees**（転送手数料）、**Authorized TrustLines**（承認済みトラストライン）のような高度な制御ツールを提供します。

-### Freeze：TrustLineの凍結
+### Freeze：トラストラインの凍結

-トークンの発行者はTrustLineを凍結して、ホルダーがトークンを転送できないようにすることができます。3つのレベルがあります：
+トークンの発行者はトラストラインを凍結して、ホルダーがトークンを転送できないようにすることができます。次の3つのレベルがあります。

 ### 個別Freeze
-発行者とホルダー間の特定のTrustLineを凍結します。\`tfSetFreeze\`フラグを使った\`TrustSet\`で行います。凍結中はホルダーそのトークンを送受信できません。解除するには\`tfClearFreeze\`を使います。
+発行者とホルダー間の特定のトラストラインを凍結します。\`tfSetFreeze\`フラグを使った\`TrustSet\`で行います。凍結中はホルダーそのトークンを送受信できません。解除するには\`tfClearFreeze\`を使います。

 ### グローバルFreeze
-発行したトークンの**すべての**TrustLineを凍結します。\`SetFlag: 7\`（asfGlobalFreeze）を使った\`AccountSet\`で有効化します。すべてのホルダーが同時に凍結されます。\`ClearFlag: 7\`で解除できます。
+発行したトークンの**すべての**トラストラインを凍結します。\`SetFlag: 7\`（asfGlobalFreeze）を使った\`AccountSet\`で有効化します。すべてのホルダーが同時に凍結されます。\`ClearFlag: 7\`で解除できます。

 ### NoFreeze（取り消し不能）
 \`AccountSet\`で\`SetFlag: 6\`（asfNoFreeze）を有効化すると、発行者は凍結能力を**恒久的**に放棄します。これは取り消せません。ホルダーへの信頼のシグナルです。
@@ -2023,24 +2023,24 @@ The \`RequireAuth\` flag (asfRequireAuth) on the issuing account requires the is

 ### Clawback：ホルダーからのトークン回収

-**Clawback**は発行者が任意のホルダーからトークンを回収できるようにします。これは強力なツールで、トークン発行**前**に設定する必要があります：
+**Clawback**は発行者が任意のホルダーからトークンを回収できるようにします。これは強力なツールで、トークン発行**前**に設定する必要があります。

-1. \`AccountSet\`で\`asfAllowTrustLineClawback\`（フラグ17）を**TrustLine作成前**に有効化する
+1. \`AccountSet\`で\`asfAllowTrustLineClawback\`（フラグ17）を**トラストライン作成前**に有効化する
 2. 有効化後、\`Clawback\`トランザクションを使ってトークンを回収する
 3. **NoFreezeとは組み合わせ不可** — 凍結を放棄した場合、Clawbackもできません

 ### Transfer fees：転送手数料

-発行者は第三者間のトークン転送ごとに割合を徴収できます：
+発行者は第三者間のトークン転送ごとに割合を徴収できます。

 - \`AccountSet\`の\`TransferRate\`フィールドで設定
 - 値は整数で指定：1000000000 = 0%、1001000000 = 0.1%、1010000000 = 1%
 - 発行者への送信時ではなく、第三者間の転送にのみ適用
- 例：0.1%の手数料で100トークン送信すると、送信者から100.1が徴収される
+- 例：0.1%の手数料で100トークン送信すると、受信者に99.9トークンが入金され（受信者から0.1が徴収される）

 ### Authorized TrustLines：RequireAuth

-発行アカウントの\`RequireAuth\`フラグ（asfRequireAuth）は、ホルダーがトークンを受け取れるようになる前に、発行者が**各TrustLineを明示的に承認**することを要求します。KYCや事前確認が必要なトークンに便利です。`,
+発行アカウントの\`RequireAuth\`フラグ（asfRequireAuth）は、ホルダーがトークンを受け取れるようになる前に、発行者が**各トラストラインを明示的に承認**することを要求します。KYCや事前確認が必要なトークンに便利です。`,
      },
      codeBlocks: [
        {
--- a/src/data/modules/m08-nfts.js
+++ b/src/data/modules/m08-nfts.js
@@ -85,7 +85,7 @@ A URIToken is a **unique** object on the ledger that contains:

 ### URITokenとは？

-URITokenはレジャー上の**ユニークな**オブジェクトで、以下を含みます：
+URITokenはレジャー上の**ユニークな**オブジェクトで、次のフィールドが含まれます。
 - **ID**: トークンの一意識別子（LedgerIndex）
 - **URI**: NFTのメタデータまたはコンテンツ（画像、JSONなど）へのリンク
 - **Digest**: URIが指すコンテンツのオプションのハッシュ（整合性検証用）
@@ -113,7 +113,7 @@ URITokenはレジャー上の**ユニークな**オブジェクトで、以下

 ### URITokenMintのフラグ

- **tfBurnable (1)**: 発行者がもはやオーナーでなくなってもトークンをバーンできるようにする`,
+- **tfBurnable (1)**: 発行者以外が保有している場合でも発行者によってトークンをバーンできるようにする`,
      },
      codeBlocks: [
        {
@@ -841,7 +841,7 @@ Following a standard similar to ERC-721, the JSON metadata for a URIToken typica

 ### URIフィールド：何を入れるか

-URIはNFTのコンテンツまたはメタデータを指すリンクです。いくつかのオプションがあります：
+URIはNFTのコンテンツまたはメタデータを指すリンクです。次のようなオプションがあります。

 - **IPFSリンク**（\`ipfs://QmXxx...\`）：分散型ストレージ。コンテンツは不変でハッシュアドレス指定されます。本番環境では**推奨**オプション
 - **HTTPSリンク**（\`https://my-server.com/metadata/1.json\`）：集中型ストレージ。実装は簡単ですがサーバーの可用性に依存します
@@ -852,7 +852,7 @@ URIはNFTのコンテンツまたはメタデータを指すリンクです。

 ### JSONメタデータ標準

-ERC-721と同様の標準に従い、URITokenのJSONメタデータには通常以下が含まれます：
+ERC-721と同様の標準に従い、URITokenのJSONメタデータには通常次のようなフィールドが含まれます。

 \`\`\`json
 {
@@ -880,7 +880,7 @@ ERC-721と同様の標準に従い、URITokenのJSONメタデータには通常

 | オプション | メリット | デメリット |
 |---|---|---|
-| **IPFS** | 分散型、不変、ハッシュアドレス指定 | 永続化にピニングが必要 |
+| **IPFS** | 分散型、不変、ハッシュアドレス指定 | 永続化にピンニングが必要 |
 | **集中型サーバー** | シンプル、高速 | 単一障害点、変更可能 |

 ### ベストプラクティス
@@ -888,7 +888,7 @@ ERC-721と同様の標準に従い、URITokenのJSONメタデータには通常
 - **常にDigestを設定する**：いつでもコンテンツの整合性を検証できます
 - **本番環境ではIPFSを使用する**：不変性と分散化がNFTの価値を保護します
 - **JSONを一貫して保つ**：マーケットプレイスやエクスプローラーとの互換性のためにメタデータ標準に従います
- **URIに機密データを入れない**：レジャー上のすべては公開です`,
+- **URIに機密データを入れない**：レジャー上のすべては公開情報です`,
      },
      codeBlocks: [
        
--- a/src/data/modules/m09-smart-contracts.js
+++ b/src/data/modules/m09-smart-contracts.js
@@ -115,12 +115,12 @@ Every Hook must include a call to \`_g(id, maxiter)\` to prevent infinite loops.

 ### リアクティブモデル

-最も重要な違いは**実行モデル**です：
+最も重要な違いは**実行モデル**です。

 - Ethereumでは、コントラクトにトランザクションを送ることで**あなたがスマートコントラクトを呼び出す**
 - Xahauでは、Hookがインストールされたアカウントにトランザクションが通過するとき、Hooksが**自動的に実行される**

-Hooksはトランザクションに反応する**フィルター**や**インターセプター**のようなものです。多くのオプションの中で、以下のことができます：
+Hooksはトランザクションに反応する**フィルター**や**インターセプター**のようなものです。多くのオプションの中で、次のようなことができます。
 - トランザクションを**承認**する（\`accept()\`）
 - トランザクションを**拒否**する（\`rollback()\`）
 - 新しいトランザクションを**発行**する（\`emit()\`）
@@ -134,7 +134,7 @@ Hooksはトランザクションに反応する**フィルター**や**インタ

 ### 必須関数

-すべてのHookは2つの関数を実装する必要があります：
+すべてのHookは次の2つの関数を実装する必要があります。
 - \`hook(uint32_t reserved)\` — アカウントにトランザクションが到着したときに実行される。必須
 - \`cbak(uint32_t reserved)\` — Hookが発行したトランザクションのコールバックとして実行される。任意

@@ -390,7 +390,7 @@ int64_t hook(uint32_t reserved) {
 La forma más rápida de empezar. [builder.xahau.network](https://builder.xahau.network) te permite escribir, compilar y desplegar Hooks desde el navegador. Incluye ejemplos, documentación y un entorno de desarrollo integrado. Ideal para pruebas rápidas y aprendizaje. Solo disponible para **Xahau Testnet**.

 **2. Desarrollo local**
-Para desarrollo local (y posteriormente Xahau Mainnet) necesitas [xahau-toolkit](https://hooks-toolkit.com/), incluye una librería completa para poder compilar tus hooks y desplegarlos con scripts personalizados.
+Para desarrollo local (y posteriormente Xahau Mainnet) necesitas [hooks-toolkit](https://hooks-toolkit.com/), incluye una librería completa para poder compilar tus hooks y desplegarlos con scripts personalizados.

 ### Desplegar un Hook

@@ -538,7 +538,7 @@ Para una referencia completa de \`SetHook\`, incluyendo todos los campos, flags,
 The fastest way to get started. [builder.xahau.network](https://builder.xahau.network) lets you write, compile and deploy Hooks from the browser. It includes examples, documentation and an integrated development environment. Ideal for quick tests and learning. Only available for **Xahau Testnet**.

 **2. Local development**
-For local development (and later Xahau Mainnet) you need [xahau-toolkit](https://hooks-toolkit.com/), which includes a complete library to compile your hooks and deploy them with custom scripts.
+For local development (and later Xahau Mainnet) you need [hooks-toolkit](https://hooks-toolkit.com/), which includes a complete library to compile your hooks and deploy them with custom scripts.

 ### Deploying a Hook

@@ -649,7 +649,7 @@ If you also want to **clean all state** from that Hook's namespace, add the \`hs
 |---|---|---|
 | \`hsfOverride\` | 1 | Allows replacing or deleting an existing Hook at that position |
 | \`hsfNSDelete\` | 2 | Deletes all namespace state upon uninstall |
-| \`hsfCollect\` | 4 | Collects grants from the previous Hook |
+| \`hsfCollect\` | 4 | Allow execution as weakTSH. |

 ### HookOn: Transaction filter

@@ -686,7 +686,7 @@ For a complete reference on \`SetHook\`, including all fields, flags, validation
 最も早く始められる方法。[builder.xahau.network](https://builder.xahau.network) ではブラウザからHooksを記述、コンパイル、デプロイできます。例、ドキュメント、統合開発環境が含まれています。クイックテストと学習に最適。**Xahau Testnet**専用。

 **2. ローカル開発**
-ローカル開発（後にXahau Mainnet）には[xahau-toolkit](https://hooks-toolkit.com/)が必要です。Hooksのコンパイルとカスタムスクリプトでのデプロイに必要な完全なライブラリが含まれています。
+ローカル開発（Xahau Mainnetへのデプロイを含む）には[hooks-toolkit](https://hooks-toolkit.com/)が必要です。Hooksのコンパイルとカスタムスクリプトでのデプロイに必要な完全なライブラリが含まれています。

 ### Hookのデプロイ

@@ -696,7 +696,7 @@ For a complete reference on \`SetHook\`, including all fields, flags, validation

 ### SetHookトランザクション

-\`SetHook\`トランザクションはHookを管理するために必要な唯一のトランザクションです。これを使ってアカウントのHooksを**インストール**、**更新**、**削除**できます。\`Hooks\`配列内のHookオブジェクトの主なフィールドは：
+\`SetHook\`トランザクションはHookを管理するために必要な唯一のトランザクションです。これを使ってアカウントのHooksを**インストール**、**更新**、**削除**できます。\`Hooks\`配列内のHookオブジェクトの主なフィールドは次のとおりです。

 | フィールド | 説明 |
 |---|---|
@@ -776,7 +776,7 @@ Hook: {

 ### 4. Hookを削除する（Delete操作）

-位置からHookを削除するには、次の条件を満たす必要があります：その位置にHookが存在すること、\`hsfOverride\`フラグが有効であること、\`HookHash\`を送信しないこと、\`CreateCode\`が存在するが**空**であること：
+配列の特定の位置のHookを削除するには、次の条件を満たす必要があります。その位置にHookが存在すること、\`hsfOverride\`フラグが有効であること、\`HookHash\`を設定しないこと、\`CreateCode\`が存在するが**空**であること。

 \`\`\`
 Hook: {
@@ -786,8 +786,8 @@ Hook: {
 \`\`\`

 削除時：
- \`HookDefinition\`の**参照カウンター**が減少します。ゼロに達すると（そのコードを使用している他のアカウントがない）、定義はレジャーから削除されます
- その位置のHookオブジェクトが**削除**され、位置が空になります
+- \`HookDefinition\`の**参照カウンター**が減少します。ゼロに達すると（そのコードを使用している他のアカウントがない）、\`HookDefinition\`はレジャーから削除されます
+- その位置のHookオブジェクトが**削除**され、その位置が空になります

 そのHookのNamespaceからすべてのステートを**クリア**したい場合は、\`hsfNSDelete\`フラグ（値2）と\`hsfOverride\`を組み合わせて追加します：\`Flags: 3\`。これにより関連するNamespaceのすべての\`HookState\`エントリが削除されます。

@@ -797,13 +797,13 @@ Hook: {
 |---|---|---|
 | \`hsfOverride\` | 1 | その位置の既存のHookを置き換えまたは削除することを許可する |
 | \`hsfNSDelete\` | 2 | アンインストール時にNamespaceのすべてのステートを削除する |
-| \`hsfCollect\` | 4 | 前のHookのGrantsを収集する |
+| \`hsfCollect\` | 4 | weakTSHとしての実行を許可する |

 ### HookOn：トランザクションフィルター

-\`HookOn\`フィールドは、Hookがどのトランザクションタイプで起動するかを制御します：
- この[計算機](https://richardah.github.io/xrpl-hookon-calculator/)を使って特定のビットを設定してタイプを有効または無効にできます
- 支払いトランザクションのみで起動するように設定すると、アカウントが支払いを受信または送信したときにのみHookが実行されます。計算機の結果は\`0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffbffffe\`です。\`0x\`の部分を削除し、結果を大文字に変換してHookOnフィールドで使用します。例：\`FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFBFFFFE\`。
+\`HookOn\`フィールドは、Hookがどのトランザクションタイプで起動するかを制御します。
+- この[HookOn計算機](https://richardah.github.io/xrpl-hookon-calculator/)を使って特定のビットを設定してHookを実行するトランザクションタイプを有効または無効にできます
+- Paymentトランザクションのみで起動するように設定すると、アカウントが支払いを受信または送信したときにのみHookが実行されます。この場合、計算機の結果は\`0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffbffffe\`です。\`0x\`の部分を削除し、結果を大文字に変換してHookOnフィールドで使用します。例：\`FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFBFFFFE\`。
 - 複数のトランザクションを同時にマークできます。不要なトランザクションタイプでHookが起動しないようにHookOnの設定には注意が必要です。これにより不要な手数料が発生し、予期しないアクションのリスクが増加する可能性があります。

 ### HookCanEmit：トランザクション発行の制御
@@ -812,20 +812,20 @@ Hook: {

 \`HookCanEmit\`は、Hookが発行できるトランザクションタイプを明示的に定義する配列です。設定されている場合、Hookは**リストされたトランザクションのみを発行でき**、含まれていないタイプを発行しようとするとネットワークによって拒否されます。\`HookOn\`と同様に機能しますが、Hookの起動を制御する代わりに発行能力を制御します。

- この[計算機](https://richardah.github.io/xrpl-hookon-calculator/)を使って特定のビットを設定してタイプを有効または無効にできます
- 支払いトランザクションの発行のみを許可するようにマークすると、計算機の結果は\`0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffbffffe\`です。\`0x\`の部分を削除し、結果を大文字に変換して\`HookCanEmit\`フィールドで使用します。例：\`FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFBFFFFE\`。
- \`HookCanEmit\`はオプションフィールドですが、悪意のあるHookからの望ましくないアクションを防ぐために使用することが推奨されます。
+- HookOnと同じ[計算機](https://richardah.github.io/xrpl-hookon-calculator/)を使って特定のビットを設定してemitを許可するトランザクションタイプを有効または無効にできます
+- Paymentトランザクションの発行のみを許可するようにマークすると、計算機の結果は\`0xffffffffffffffffffffffffffffffffffffffffffffffffffffffffffbffffe\`です。\`0x\`の部分を削除し、結果を大文字に変換して\`HookCanEmit\`フィールドで使用します。例：\`FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFBFFFFE\`。
+- \`HookCanEmit\`は任意フィールドですが、悪意のあるHookからの望ましくないアクションを防ぐために使用することが推奨されます。

 **なぜセキュリティに重要か？**

- **最小権限の原則**：Hookは必要な権限のみを持つべきです。Hookが支払いの送信のみが必要な場合、\`SetHook\`、\`AccountDelete\`やその他の敏感なトランザクションを発行できるべきではありません。
+- **最小権限の原則**：Hookは必要な権限のみを持つべきです。Hookが支払いの送信のみが必要な場合、\`SetHook\`、\`AccountDelete\`やその他の**重要度が高い**トランザクションを発行できるべきではありません。
 - **バグに対する保護**：Hookに脆弱性がある場合、\`HookCanEmit\`は実行できるアクションを制限することで潜在的な被害を制限します。
 - **監査と透明性**：アカウントにインストールされたHookをレビューする際、\`HookCanEmit\`により自律的に実行できる操作を迅速に確認できます。
 - **ベストプラクティス**：Hookのロジックに必要な最小限のトランザクションセットで\`HookCanEmit\`を常に設定します。

 ### 詳細情報

-すべてのフィールド、フラグ、バリデーションルール、特殊ケースを含む\`SetHook\`の完全なリファレンスについては、[公式ドキュメント](https://xahau.network/docs/protocol-reference/transactions/transaction-types/sethook/)を参照してください。`,
+すべてのフィールド、フラグ、バリデーションルール、特殊ケースを含む\`SetHook\`の完全なリファレンスについては、[公式ドキュメント](https://xahau.network/docs/protocol-reference/transactions/transaction-types/sethook/)をご覧ください。`,
      },
      codeBlocks: [

@@ -1474,7 +1474,7 @@ Here are some functions we can use to read or write information in \`Namespace\`

 ### ステートの構造

-Namespaceは16進数の32バイト（256ビット）で識別されます。ステートは**キーと値**のペアとして整理されます：
+Namespaceは16進数の32バイト（256ビット）で識別されます。ステートは**キーと値**のペアとして管理されます。

 - **キー**：32バイト（256ビット）。キーが短い場合はゼロで埋められる
 - **値**：エントリあたり最大256バイト
@@ -1807,7 +1807,7 @@ When an emitted transaction **completes** (with success or failure), Xahau calls

 ### etxn_reserve()でスペースを確保する

-Emitする前に、この実行で何個のトランザクションをEmitするかを**確保**する必要があります：
+Emitする前に、この実行で何個のトランザクションをEmitするかを**確保**する必要があります。

 \`\`\`
 etxn_reserve(1);  // 1回のEmitのためのスペースを確保
@@ -1824,11 +1824,11 @@ etxn_reserve(1);  // 1回のEmitのためのスペースを確保

 ### cbak()関数

-EmitされたトランザクションがEmitしたHookの**完了**（成功または失敗）時に、Xahauは\`cbak()\`関数を呼び出します：
+EmitされたトランザクションがEmitしたHookの**完了**（成功または失敗）時に、Xahauは\`cbak()\`関数を呼び出します。

 - \`cbak()\`はEmit結果に関する情報を受け取る
 - \`cbak()\`を使用してステートを更新したり、結果を記録したり、追加のアクションを取ったりできる
- 何もする必要がない場合、\`cbak()\`は単に0を返せる
+- 何もする必要がない場合、\`cbak()\`は単に0を返して良い

 ### ユースケース

@@ -2279,7 +2279,7 @@ Throughout your first steps developing Hooks, you'll encounter needs like transl

 ### otxn_param() HookのためのトランザクションParameters

-\`otxn_param()\`は、その正確な瞬間に**Hookを実行しているトランザクション**（発信元トランザクション）に含まれているParametersを読み取ります。\`hook_param\`とは異なり、これらの値はトランザクションを実行する人が送信し、**各呼び出しで変わります**。
+\`otxn_param()\`は、その**Hookを実行しているトランザクション**（発信元トランザクション）に含まれているParametersを読み取ります。\`hook_param\`とは異なり、これらの値はトランザクションを実行する人が送信し、**各呼び出しで変わります**。

 \`\`\`c
 // 関数シグネチャ
@@ -2300,14 +2300,14 @@ int64_t otxn_param(

 | | \`hook_param()\` | \`otxn_param()\` |
 |---|---|---|
-| **ソース** | SetHook（インストール） | Hookを起動するトランザクション |
+| **ソース** | SetHook（インストール） | Hookを呼び出すトランザクション |
 | **誰が設定するか** | Hookのインストーラー | 各txの送信者 |
-| **いつ変わるか** | Hookを更新するときのみ | 各トランザクションで |
+| **いつ変わるか** | Hookを更新するときのみ | 各トランザクション毎に |
 | **典型的な使用法** | 静的設定 | 動的命令 |

 ### JavaScriptからトランザクションにHookParametersを含める方法

-トランザクションParametersは、Hookを起動する任意のtxの\`HookParameters\`フィールドに追加されます。名前と値は16進数である必要があります：
+トランザクションParametersは、Hookを起動する任意のtxの\`HookParameters\`フィールドに追加されます。名前と値は16進数である必要があります。

 \`\`\`javascript
 // 名前 "ACTION"（hex: 414354494F4E）と値 "01"（hex）
@@ -2329,7 +2329,7 @@ const tx = {

 ### Hooksを使いやすくするためのリソース

-Hooks開発の最初のステップで、パラメーターを読みやすい値に変換するなどのニーズに遭遇するでしょう。こちらに有用なページがあります：
+Hooks開発の最初のステップで、パラメーターを読みやすい値に変換するなどのニーズに遭遇するでしょう。次のような便利なツールがあります。
 - [HookOn計算機](https://richardah.github.io/xrpl-hookon-calculator/)：HookOnとHookCanEmitフィールドを簡単に計算する
 - [HEXビジュアライザー](https://transia-rnd.github.io/xrpl-hex-visualizer/)：文字列を複数の形式でhexに変換したりその逆をしたりする
 - [時間ビジュアライザー](https://transia-rnd.github.io/xrpl-time-visualizer/)：Xahauの時間形式（Ripple Epoch）と読みやすい日付を変換する
@@ -3136,7 +3136,7 @@ Traces have an execution fee cost and increase WASM size. Once the Hook works co

 \`\`\`c
 // テキストメッセージをEmit
-trace(SBUF("hookが正常に開始されました"), 0);  // 0 = 文字列として表示
+trace(SBUF("hook started correctly"), 0);  // 0 = 文字列として表示

 // バッファの内容を16進数でEmit
 uint8_t account_buf[20];
@@ -3154,11 +3154,11 @@ trace(SBUF(account_buf), 1);                    // 1 = hexとして表示

 \`\`\`c
 int64_t drops = AMOUNT_TO_DROPS(amount_buf);
-trace_num(SBUF("受信したdrops: "), drops);
+trace_num(SBUF("drops received: "), drops);

 // エラーを検出するために関数の戻り値を確認する
 int64_t result = state_set(SBUF(counter_buf), SBUF(state_key));
-trace_num(SBUF("state_set結果: "), result);
+trace_num(SBUF("state_set result: "), result);
 // 負の値 = エラー; 正またはゼロ = 成功
 \`\`\`

@@ -3170,7 +3170,7 @@ Hooksは**XFL**（eXtended Float）フォーマットを使って非整数の金
 // スロットからXFLとしてamountを取得する
 int64_t slot_no = slot_set(SBUF(amount_buf), 0);
 int64_t xfl_amount = slot_float(slot_no);
-trace_float(SBUF("XFLの金額: "), xfl_amount);
+trace_float(SBUF("amount in XFL: "), xfl_amount);
 \`\`\`

 ### macro.h：Hooks Builderで利用可能なデバッグマクロ
@@ -3213,7 +3213,7 @@ Hooks Builderには、\`trace*\`関数をラップし、\`DEBUG\`定数が定義
 // macro.hはHooks Builderで自動的に利用可能
 \`\`\`

-\`DEBUG\`が\`0\`または未定義の場合、コンパイラは生成されたWASMからマクロを完全に削除します：手数料コストもサイズの増加もありません。
+\`DEBUG\`が\`0\`または未定義の場合、コンパイラは生成されたWASMからマクロを完全に削除します。手数料コストやサイズの増加もありません。

 **使用例：**

@@ -3262,7 +3262,7 @@ int64_t r = state_set(SBUF(val), SBUF(key));
 trace_num(SBUF("state_set: "), r);  // rが< 0なら何かが失敗した

 int64_t r2 = emit(SBUF(emithash), SBUF(tx_buf));
-trace_num(SBUF("emit結果: "), r2);
+trace_num(SBUF("emit result: "), r2);
 \`\`\`

 **4. バイナリバッファをhexとしてトレースする**
@@ -3291,17 +3291,17 @@ if (tt == 0) {

 **6. Emitのデバッグのためにcbakをトレースする**

-Emitされたトランザクションがサイレントに失敗する場合、\`cbak()\`を計装なしに知ることは難しいです。
+Emitされたトランザクションがサイレントに失敗する場合、\`cbak()\`をトレースなしに知ることは難しいです。

 \`\`\`c
 int64_t cbak(uint32_t reserved) {
    _g(1, 1);
    uint8_t txtype[4];
    int64_t t = otxn_type();
-    trace_num(SBUF("cbak: EmitされたtxのType: "), t);
+    trace_num(SBUF("cbak: emitted tx type: "), t);
    // Emitされたtxの結果を読み取る
    int64_t result = otxn_field(...);
-    trace_num(SBUF("cbak: Emit結果: "), result);
+    trace_num(SBUF("cbak: emitted tx result: "), result);
    return 0;
 }
 \`\`\`
@@ -3315,7 +3315,7 @@ int64_t cbak(uint32_t reserved) {
          title: {
            es: "Hook instrumentado con todas las funciones de traza",
            en: "Hook instrumented with all trace functions",
-            jp: "すべてのトレース関数を使って計装されたHook",
+            jp: "すべてのトレース関数を利用したHook",
          },
          language: "c",
          code: {
@@ -3760,7 +3760,7 @@ A large and consistent test suite is key to ensuring your Hook behaves correctly

 ### メインタブ

-BuilderはHooks開発ワークフロー全体をカバーする3つのメインタブを持っています：
+BuilderはHooks開発ワークフロー全体をカバーする次の3つのメインタブを持っています。

 - **Develop**：C言語でHooksを記述およびコンパイルする
 - **Deploy**：アカウントを管理しHooksをデプロイする
@@ -3768,11 +3768,11 @@ BuilderはHooks開発ワークフロー全体をカバーする3つのメイン

 ### ステップ1：Deployでアカウントを管理する

-開発を始める前に、少なくとも1つのTestnetアカウントが必要です。**Deploy**タブで：
+開発を始める前に、少なくとも1つのTestnetアカウントが必要です。**Deploy**タブでは次のことができます。

 **新しいアカウントを作成する**
 1. **"Generate Account"**またはアカウント作成ボタンをクリックする
-2. Builderは自動的にキーペア（アドレス + シード）を生成し、フォーセットからTestnet XAHでアカウントに資金を提供する
+2. Builderは自動的にキーペア（アドレス + シード）を生成し、FaucetからTestnet XAHでアカウントに資金を提供する
 3. ブラウザを閉じたときに必要になるので、シードを安全な場所に保存する

 **既存のアカウントをインポートする**
@@ -3780,11 +3780,11 @@ BuilderはHooks開発ワークフロー全体をカバーする3つのメイン
 2. Testnetアカウントの**シード**（secret）を入力する
 3. アカウントはその残高とインストールされたHooksとともにリストに表示される

-少なくとも**2つのアカウント**を持つことを推奨します：1つはHookのインストール用、もう1つはテストトランザクションの送信用。**セキュリティのためBuilderでXahau Mainnetアカウントのシードを使用しないでください**。新しいシードが必要な場合は、Builder内で生成するか[xahau-test.net](https://xahau-test.net/)を訪問してください。
+少なくとも**2つのアカウント**を持つことを推奨します：1つはHookのインストール用、もう1つはテストトランザクションの送信用。**セキュリティのためBuilderでXahau Mainnetアカウントのシードを使用しないでください**。新しいシードが必要な場合は、Builder内で生成するか[xahau-test.net](https://xahau-test.net/)を利用してください。

 ### ステップ2：Developで開発およびコンパイルする

-**Develop**タブで：
+**Develop**タブでは次のことができます。

 1. サイドメニューから**例を選択する**か、新しいファイルを作成する
 2. **CでHookを記述する**、エディターにはシンタックスハイライトと基本的な自動補完がある
@@ -3798,7 +3798,7 @@ BuilderはHooks開発ワークフロー全体をカバーする3つのメイン

 ### ステップ3：Deployでデプロイする

-HookのコンパイルができたらDeploy**タブに戻る：
+HookのコンパイルができたらDeploy**タブに戻ります。

 1. Hookをインストールする**アカウントを選択**し、**Set Hook**をクリックしてインストールフォームを開く
 2. **パラメーターを設定する**：
@@ -3814,7 +3814,7 @@ HookのコンパイルができたらDeploy**タブに戻る：

 ### ステップ4：Testでテストする

-**Test**タブでHookが正しく機能することを確認します：
+**Test**タブでHookが正しく機能することを確認します。

 1. **Transaction type**：送信したいトランザクションタイプを選択する（Payment、OfferCreateなど）。
 2. **Account**：トランザクションの送信者。
@@ -4080,7 +4080,7 @@ For complete information on hooks-cli, advanced compilation options and the full

 ### hooks-cliとは？

-**hooks-cli**はHooksのコンパイルプロセス全体を簡素化するコマンドラインツールです：
+**hooks-cli**はHooksのコンパイルプロセス全体を簡素化するコマンドラインツールです。

 - CコードをWebAssembly（.wasm）にコンパイルしてデプロイ可能な状態にする
 - 必要なすべての依存関係を含む（コンパイラー、ヘッダー、hookapi.h）
@@ -4128,7 +4128,7 @@ yarn install

 ### Hookをコンパイルする

-CファイルをWebAssembly（.wasm）にコンパイルするには：
+CファイルをWebAssembly（.wasm）にコンパイルするには次のようにします。

 \`\`\`bash
 # Hookをコンパイルする
@@ -4143,7 +4143,7 @@ yarn run build

 ### XahauへのHookのデプロイ

-Hookが.wasm形式になったら、Xahauにデプロイする必要があります。このプロセスを自動化するには、\`xahau\`ライブラリを使用して.wasm形式のHookコードを含む\`SetHook\`トランザクションを生成できます：
+Hookが.wasm形式になったら、Xahauにデプロイする必要があります。このプロセスを自動化するには、\`xahau\`ライブラリを使用して.wasm形式のHookコードを含む\`SetHook\`トランザクションを生成できます。

 \`\`\`javascript
 const createHook = {
@@ -4153,9 +4153,9 @@ const createHook = {
      "Hooks": [
        {
          "Hook": {
-            "CreateCode": fs.readFileSync('base.wasm').toString('hex').toUpperCase(), //https://bqsoczh.dlvr.cloud/base.wasm
-            "HookOn": 'FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFFFFFFFFFFFFFBFFFFF', //https://richardah.github.io/xrpl-hookon-calculator/
-            "HookCanEmit": "FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFBFFFFFFFFFFFFFFFFFFFBFFFFF", //ClaimRewardをEmitできる
+            "CreateCode": fs.readFileSync('base.wasm').toString('hex').toUpperCase(), // https://bqsoczh.dlvr.cloud/base.wasm
+            "HookOn": 'FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFFFFFFFFFFFFFBFFFFF', // https://richardah.github.io/xrpl-hookon-calculator/
+            "HookCanEmit": "FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFBFFFFFFFFFFFFFFFFFFFBFFFFF", // ClaimRewardをEmitできる
            "HookNamespace": crypto.createHash('sha256').update('base').digest('hex').toUpperCase(),
            "Flags": 1,
            "HookApiVersion": 0
--- a/src/data/modules/m10-escrows-checks.js
+++ b/src/data/modules/m10-escrows-checks.js
@@ -120,7 +120,7 @@ Xahau supports crypto-conditions from the **Interledger (ILP)** protocol:

 ### EscrowCreate：エスクローの作成

-\`EscrowCreate\`トランザクションタイプは、条件付きでXAHの金額をロックします：
+\`EscrowCreate\`トランザクションタイプは、条件付きでXAH/IOUの金額をロックします。

 | フィールド | 説明 |
 |---|---|
@@ -137,21 +137,21 @@ Xahau supports crypto-conditions from the **Interledger (ILP)** protocol:

 ### EscrowFinish：エスクローの完了

-任意のアカウントが\`EscrowFinish\`を実行して受取人に資金をリリースできます：
+任意のアカウントが\`EscrowFinish\`を実行して受取人に資金をリリースできます。
 - \`FinishAfter\`後にのみ機能します（指定されている場合）
 - \`Condition\`がある場合は、正しい\`Fulfillment\`を提供する必要があります
 - \`Owner\`と\`OfferSequence\`フィールドが完了するエスクローを特定します

 ### EscrowCancel：エスクローのキャンセル

-\`EscrowCancel\`で資金が作成者に返還されます：
+\`EscrowCancel\`で資金が作成者に返還されます。
 - \`CancelAfter\`後にのみ機能します
 - 任意のアカウントがキャンセルを実行できます
 - 資金はエスクローを作成したアカウントに戻ります

 ### 暗号条件

-Xahauは**Interledger (ILP)**プロトコルの暗号条件をサポートします：
+Xahauは**Interledger (ILP)**プロトコルの暗号条件をサポートします。
 - **PREIMAGE-SHA-256**標準に基づいています
 - 作成者は\`Condition\`（ハッシュ）を生成し、\`Fulfillment\`（プリイメージ）を保存します
 - エスクローを完了するには、\`Condition\`に一致する\`Fulfillment\`を提供する必要があります
@@ -754,7 +754,7 @@ Either party (sender or recipient) can cancel a check. An expired check can also
 - \`tecNO_LINE\`: For IOUs, the recipient has no TrustLine with the token issuer
 - \`tecUNFUNDED\`: The check issuer has insufficient funds at the time of cashing
 - \`tecEXPIRED\`: The check has expired`,
-        jp: `**チェック**は従来の銀行小切手に似ています：送信者は特定の金額のチェックを作成し、受取人はいつでも換金できます。直接支払いとは異なり、資金は**即座に転送されません**—受取人がチェックを換金するための行動を取る必要があります。
+        jp: `**チェック**は従来の銀行小切手に似ています。送信者は特定の金額のチェックを作成し、受取人はいつでも換金できます。直接支払いとは異なり、資金は**即座に転送されません**。受取人がチェックを換金するための行動を取る必要があります。

 ### 直接支払いの代わりにチェックを使う理由は？

@@ -774,7 +774,7 @@ Either party (sender or recipient) can cancel a check. An expired check can also
 | \`Expiration\` | （オプション）チェックが失効するタイムスタンプ |
 | \`InvoiceID\` | （オプション）チェックの目的を識別する256ビットのハッシュ |

-\`SendMax\`はIOUの場合、文字列（XAH drops）またはAmountオブジェクトになります：
+\`SendMax\`はIOUの場合、文字列（XAH drops）またはAmountオブジェクトになります。
 \`\`\`
 // ネイティブXAHのチェック
 "SendMax": "10000000"  // 10 XAH（drops単位）
@@ -789,7 +789,7 @@ Either party (sender or recipient) can cancel a check. An expired check can also

 ### CheckCash：チェックの換金

-受取人は\`CheckCash\`でチェックを換金します。2つのモードがあります：
+受取人は\`CheckCash\`でチェックを換金します。次の2つのモードが存在します。

 1. **Amount**：正確な金額を換金（SendMax以下でなければなりません）
 2. **DeliverMin**：少なくともこの金額を換金（価値が変動する可能性のあるIOUで便利）
@@ -1278,7 +1278,7 @@ If you no longer need a Ticket, you can cancel it to release the reserve. There

 ### チケットとは？

-Xahauの各アカウントには、トランザクションごとにインクリメントされる\`Sequence\`番号があります。これはトランザクションが厳密な順序で処理される必要があることを意味します。チケットはこの問題を解決します：
+Xahauの各アカウントには、トランザクションごとにインクリメントされる\`Sequence\`番号があります。これはトランザクションが厳密な順序で処理される必要があることを意味します。チケットはこの問題を解決します。

 - チケットは将来の使用のためにシーケンス番号を**予約**します
 - チケットを使用するトランザクションは\`Sequence\`の代わりに\`TicketSequence\`を指定します
@@ -1293,7 +1293,7 @@ Xahauの各アカウントには、トランザクションごとにインクリ

 ### TicketCreate：チケットの予約

-\`TicketCreate\`トランザクションは1つ以上のシーケンス番号を予約します：
+\`TicketCreate\`トランザクションは1つ以上のシーケンス番号を予約します。

 | フィールド | 説明 |
 |---|---|
@@ -1303,13 +1303,13 @@ Xahauの各アカウントには、トランザクションごとにインクリ

 ### 予約コスト

-作成された各チケットは、TrustLineやDEXのオファーと同様に、アカウントの**オーナーリザーブ**を消費します。つまり、アクティブなチケットごとにアカウントに追加のXAHをロックしておく必要があります。チケットは使用またはキャンセルされたときに削除され（リザーブが解放されます）。
+作成された各チケットは、トラストラインやDEXのオファーと同様に、アカウントの**所有者準備金**を消費します。つまり、アクティブなチケットごとにアカウントに追加のXAHをロックしておく必要があります。チケットは使用またはキャンセルされたときに削除され（所有者準備金が解放されます）。

 ### 制限

 - **トランザクションあたりの最大数**：単一の\`TicketCreate\`トランザクションで最大**250チケット**を作成可能
 - **アカウントあたりの最大数**：アカウントは最大**250チケット**を同時にアクティブにできます
- チケットは**失効しません**—使用またはキャンセルされるまでレジャーに残ります
+- チケットは**失効しません**：使用またはキャンセルされるまでレジャーに残ります

 ### トランザクションでのチケットの使用

@@ -1317,11 +1317,11 @@ Xahauの各アカウントには、トランザクションごとにインクリ
 - \`Sequence: 0\` — 通常のシーケンスを使用しないことを示す
 - \`TicketSequence: N\` — 消費するチケット番号

-チケットは使用時に自動的に破棄され、リザーブが解放されます。
+チケットは使用時に自動的に破棄され、所有者準備金が解放されます。

 ### 未使用チケットのキャンセル

-チケットが不要になった場合、キャンセルしてリザーブを解放できます。チケットをキャンセルするための特定のトランザクションはありません。代わりに、チケットを消費する空の\`AccountSet\`トランザクション（変更なし）を使用できます。`,
+チケットが不要になった場合、キャンセルして所有者準備金を解放できます。チケットをキャンセルするための特定のトランザクションはありません。代わりに、チケットを消費する空の\`AccountSet\`トランザクション（変更なし）を使用できます。`,
      },
      codeBlocks: [
        {
@@ -1685,11 +1685,11 @@ If for any reason you want to stop participating in the rewards system, you can

 ### Xahauの報酬の仕組みは？

-ステーキングが必要なProof of Stakeブロックチェーンとは異なり、Xahauではアクティブなバランスを維持するアカウントに報酬が配布されます。仕組みは以下の通りです：
+ステーキングが必要なProof of Stakeブロックチェーンとは異なり、Xahauではアクティブなバランスを維持するアカウントに報酬が配布されます。仕組みは以下の通りです。

- XAHのバランスに基づいて報酬が自動的に累積されます
+- XAHの残高に基づいて報酬が自動的に累積されます
 - 受け取るには、定期的に\`ClaimReward\`トランザクションを送信する必要があります
- 請求時に報酬がアカウントバランスに直接追加されます
+- 請求時に報酬がアカウントの残高に直接追加されます
 - デリゲート、資金のロック、バリデータノードの実行は不要です

 ### ClaimRewardトランザクション
@@ -1714,7 +1714,7 @@ If for any reason you want to stop participating in the rewards system, you can
 - 報酬はバランスと最後の請求からの経過時間によって異なります
 - \`ClaimReward\`トランザクションのfeeは標準（他のトランザクションと同様）です
 - Hooksがインストールされたアカウントと互換性があります
- \`Issuer\`アドレスは各ネットワーク（testnet vs mainnet）によって異なります`,
+- \`Issuer\`アドレスは各ネットワーク（testnet / mainnet）によって異なります`,
      },
      codeBlocks: [
        {
@@ -2005,7 +2005,7 @@ Hooksはトランザクションがアカウントを通過したときにリア
 | \`Account\` | Invokeを送信するアカウント |
 | \`Destination\` | （オプション）実行したいHookを持つアカウント。指定しない場合、アカウント自身のHooksを実行します |

-### InvokeのメカニズムInvokeはさまざまな目的で使用できます：
+### InvokeのメカニズムInvokeはさまざまな目的で使用できます

 - HookがInvokeを発行して別のHookを実行する
 - 必要なときにHookのロジックを実行するための手動トリガーとして\`Invoke\`を使用する
@@ -2013,8 +2013,8 @@ Hooksはトランザクションがアカウントを通過したときにリア

 ### 自分のアカウントへのInvoke vs 他のアカウントへのInvoke

- **Destinationなし**：\`Invoke\`はあなた自身のアカウントのHooksを実行します。メンテナンスや自己管理Hooksに便利
- **Destinationあり**：\`Invoke\`は宛先アカウントのHooksを実行します。宛先HookはInvokeを送った人を識別して適切に対応できます
+- **Destinationなし**：\`Invoke\`はあなた自身のアカウントのHooksを実行します。メンテナンスや自己管理Hooksに便利です。
+- **Destinationあり**：\`Invoke\`は宛先アカウントのHooksを実行します。宛先HookはInvokeを送った人を識別して適切に対応できます。

 ### 注意事項

@@ -2242,13 +2242,13 @@ Si añades \`Flags: 1\` (\`tfImmutable\`) al crear una Remark, **no podrá ser m
 | \`tecIMMUTABLE\` | Se intenta modificar una Remark con \`tfImmutable\` |
 | \`tecTOO_MANY_REMARKS\` | El objeto ya tiene 32 Remarks (el máximo permitido) |`,
        en: "",
-        jp: `\`SetRemarks\`トランザクションは、Xahauレジャーの既存のオブジェクトに**キーと値のペア**を添付します。これはトランザクションでメッセージを送ったりデータを記録したりする方法ではありません。これはレジャーオブジェクト（アカウント、オファー、エスクロー、チェック、URIToken、TrustLine...）にオブジェクト自体に関連付けられたメタデータを**注釈する**メカニズムです。
+        jp: `\`SetRemarks\`トランザクションは、Xahauの既存のオブジェクトに**キーと値のペア**を添付します。これはトランザクションでメッセージを送ったりデータを記録したりする方法ではありません。これはレジャーオブジェクト（アカウント、オファー、エスクロー、チェック、URIToken、トラストライン...）にオブジェクト自体に関連付けられたメタデータを**注釈する**メカニズムです。

 ### どのタイプのオブジェクトがRemarksをサポートするか？

-\`SetRemarks\`は以下のタイプのレジャーオブジェクトにメタデータを添付できます：
+\`SetRemarks\`は以下のタイプのオブジェクトにメタデータを添付できます。

- **AccountRoot** — アカウント自体（アドレス、バランス、フラグ）
+- **AccountRoot** — アカウント自体（アドレス、残高、フラグ）
 - **Offer** — DEXのオファー
 - **Escrow** — 条件付き支払い
 - **Ticket** — シーケンスチケット
@@ -2256,16 +2256,16 @@ Si añades \`Flags: 1\` (\`tfImmutable\`) al crear una Remark, **no podrá ser m
 - **Check** — チェック
 - **DepositPreauth** — デポジット事前承認
 - **URIToken** — 非代替性トークン
- **RippleState** — TrustLine
+- **RippleState** — トラストライン

-オブジェクトの**所有者または発行者**のみがRemarksを変更できます（URITokensとTrustLineを除き、トークン発行者が権限を持ちます）。
+オブジェクトの**所有者または発行者**のみがRemarksを変更できます（トラストラインを除き、発行者が権限を持ちます）。

 ### SetRemarksのフィールド

 | フィールド | タイプ | 必須 | 説明 |
 |---|---|---|---|
 | \`TransactionType\` | String | Yes | \`"SetRemarks"\` |
-| \`Account\` | String | Yes | トランザクションを送信するアカウント（オブジェクトの所有者/発行者でなければなりません） |
+| \`Account\` | String | Yes | トランザクションを送信するアカウント（オブジェクトの発行者でなければなりません） |
 | \`ObjectID\` | Hash256 | Yes | Remarksを添付するレジャーオブジェクトのID |
 | \`Remarks\` | Array | Yes | 作成、変更、または削除する\`Remark\`オブジェクトの配列 |

@@ -2316,7 +2316,7 @@ Remarkを作成するときに\`Flags: 1\`（\`tfImmutable\`）を追加する
 | エラー | 原因 |
 |---|---|
 | \`temDISABLED\` | Remarks Amendmentがネットワークで有効になっていない |
-| \`tecNO_PERMISSION\` | アカウントがオブジェクトの所有者/発行者ではない |
+| \`tecNO_PERMISSION\` | アカウントがオブジェクトの発行者ではない |
 | \`tecIMMUTABLE\` | \`tfImmutable\`フラグ付きのRemarkを変更しようとしている |
 | \`tecTOO_MANY_REMARKS\` | オブジェクトにすでに32個のRemarks（最大許容数）がある |`,
      },
@@ -2902,7 +2902,7 @@ All these costs are deducted from the sending account (\`Account\`), plus the st
 ### More information

 For a complete reference to \`Remit\`, including all fields and possible errors, see the [official documentation](https://xahau.network/docs/protocol-reference/transactions/transaction-types/remit/).`,
-        jp: `\`Remit\`トランザクションは、Xahau独自の操作で、単一のトランザクションに複数のアクションを組み合わせます。**アカウントの有効化**、**支払いの送信**（XAHまたはIOU）、**URIToken操作**（転送またはミント）をすべて一度に実行できます。また、アカウントの有効化、TrustLine、URITokenリザーブのための**すべてのfeeを支払います**。
+        jp: `\`Remit\`トランザクションは、Xahau独自の操作で、単一のトランザクションに複数のアクションを組み合わせます。**アカウントの有効化**、**支払いの送信**（XAHまたはIOU）、**URIToken操作**（転送またはミント）をすべて一度に実行できます。また、アカウントの有効化、トラストライン、URITokenの準備金のための**すべてのfeeを支払います**。

 ### なぜRemitを使うのか？

@@ -2916,15 +2916,15 @@ For a complete reference to \`Remit\`, including all fields and possible errors,
 | \`Destination\` | Yes | 宛先アカウント |
 | \`Amounts\` | No | 支払いを含む最大**32**個の\`AmountEntry\`オブジェクトの配列 |
 | \`URITokenIDs\` | No | 転送する最大**32**個のURIToken IDの配列 |
-| \`MintURIToken\` | No | 宛先で直接新しいURITokenをミントするオブジェクト |
-| \`DestinationTag\` | No | 宛先の数値タグ |
+| \`MintURIToken\` | No | 宛先に対して直接ミントする新しいURITokenの情報 |
+| \`DestinationTag\` | No | 宛先タグ |
 | \`Inform\` | No | トランザクションの通知を受けるHookを持つアカウント |
-| \`Blob\` | No | Hookが使用するための任意の16進数データ（最大128 KB） |
-| \`InvoiceID\` | No | トランザクションの理由を示す256ビットの識別子 |
+| \`Blob\` | No | Hookで使用するための任意の16進数データ（最大128 KB） |
+| \`InvoiceID\` | No | トランザクションの追加情報を示す256ビットの識別子 |

 ### AmountEntry

-\`Amounts\`配列の各エントリには、ネイティブXAH（drops文字列）またはIOU（\`currency\`、\`issuer\`、\`value\`を持つオブジェクト）の\`Amount\`フィールドが含まれます：
+\`Amounts\`配列の各エントリには、次のようにネイティブXAH（drops文字列）またはIOU（\`currency\`、\`issuer\`、\`value\`を持つオブジェクト）の\`Amount\`フィールドが含まれます。

 \`\`\`
 "Amounts": [
@@ -2937,11 +2937,11 @@ For a complete reference to \`Remit\`, including all fields and possible errors,
 ]
 \`\`\`

-配列内の同じ通貨の重複した金額は許可されません。
+配列内で同じ通貨を複数回指定することはできません。

 ### MintURIToken

-\`MintURIToken\`フィールドにより、宛先アカウントに直接割り当てられる新しいURITokenを作成できます：
+\`MintURIToken\`フィールドを利用することで、宛先アカウントに対して直接新しいURITokenをミントすることができます。

 | フィールド | 説明 |
 |---|---|
@@ -2951,16 +2951,16 @@ For a complete reference to \`Remit\`, including all fields and possible errors,

 ### URITokenの転送

-\`URITokenIDs\`を使用すると、単一のトランザクションで最大32個の既存URITokenを宛先に転送できます。URITokenは送信アカウントに属し、必要な権限を持っている必要があります。
+\`URITokenIDs\`を使用すると、単一のトランザクションで最大32個の既存URITokenを宛先に転送できます。URITokenは送信アカウントが保有し、必要な権限を持っている必要があります。

-### feeとリザーブ
+### feeと準備金

-Remitは各アクションに関連する追加コストを自動的に支払います：
- **アカウントの有効化**：宛先アカウントが存在しない場合、ベースリザーブで有効化されます
- **TrustLine**：IOUが送信され、宛先アカウントが新しいTrustLineを必要とする場合、作成されてリザーブがカバーされます
- **URITokenリザーブ**：転送またはミントされたURITokenのリザーブが自動的にカバーされます
+Remitは各アクションに関連する追加コストを自動的に支払います。
+- **アカウントの有効化**：宛先アカウントが存在しない場合、基本準備金で有効化されます
+- **トラストライン**：IOUが送信され、宛先アカウントが新しいトラストラインを必要とする場合、作成されて準備金がカバーされます
+- **URIToken準備金**：転送またはミントされたURITokenの準備金が自動的にカバーされます

-これらのコストはすべて送信アカウント（\`Account\`）から差し引かれ、標準のトランザクションfeeに加算されます。
+これらのコストはすべて送信アカウント（\`Account\`）から差し引かれ、標準のトランザクション手数料に加算されます。

 ### 詳細情報

@@ -3252,8 +3252,7 @@ const cronDelete = {
 |---|---|
 | \`temDISABLED\` | La feature CronSet no está activada en la red |
 | \`temMALFORMED\` | Combinación de campos inválida (p.ej. solo uno de \`DelaySeconds\`/\`RepeatCount\`) |
-| \`tecEXPIRED\` | \`StartTime\` en el pasado o más de 365 días en el futuro |
-| \`tefBAD_LEDGER\` | No existe el objeto Cron que se intenta eliminar |`,
+| \`tecEXPIRED\` | \`StartTime\` en el pasado o más de 365 días en el futuro |`,
        en: `The \`CronSet\` transaction allows scheduling the **automatic and periodic execution** of a Hook directly from the Xahau protocol, without depending on any external service. It is the network's native cron job mechanism.

 ### What is CronSet?
@@ -3337,23 +3336,22 @@ const cronDelete = {
 |---|---|
 | \`temDISABLED\` | The CronSet feature is not enabled on the network |
 | \`temMALFORMED\` | Invalid field combination (e.g. only one of \`DelaySeconds\`/\`RepeatCount\`) |
-| \`tecEXPIRED\` | \`StartTime\` in the past or more than 365 days into the future |
-| \`tefBAD_LEDGER\` | The Cron object being deleted does not exist |`,
+| \`tecEXPIRED\` | \`StartTime\` in the past or more than 365 days into the future |`,
        jp: `\`CronSet\`トランザクションは、外部サービスに依存することなく、Xahauプロトコルから直接、Hookの**自動かつ定期的な実行**をスケジュールできます。これはネットワークのネイティブなcronジョブメカニズムです。

 ### CronSetとは？

-\`CronSet\`を使用すると、Xahauにアカウントのフックを定期的に実行するよう指示できます：X秒ごと、特定の日付から、特定の回数。すべてがレジャーに記録され、ネットワークが実行を担当します。
+\`CronSet\`を使用すると、XahauにアカウントのフックをX秒ごと、特定の日付から、特定の回数のように定期的に実行するよう指示することができます。すべてがレジャーに記録され、ネットワークが実行を担当します。

-定期的な\`Invoke\`パターン（外部サービスがトランザクションを送信する場合）とは異なり、\`CronSet\`は**完全にオンチェーン**です：常時実行されている外部スクリプトは不要です。
+定期的な\`Invoke\`パターン（外部サービスがトランザクションを送信する場合）とは異なり、\`CronSet\`は**完全にオンチェーン**であり、常時実行のための外部スクリプトは不要です。

 ### 前提条件

-\`CronSet\`を使用する前に、2つのステップでHookを持つアカウントを準備する必要があります：
+\`CronSet\`を使用する前に、次の2つのステップでHookを持つアカウントを準備する必要があります。

 1. **\`hsfCOLLECT\`フラグ付きのHookをインストール**：このフラグはHookがネットワークのcronシステムによって自動的に呼び出されるように設計されていることを示します。

-2. **アカウントでTSH Collectを有効化**（\`asfTshCollect\`、\`SetFlag: 11\`）：ネットワークがTransaction Signature Hook Collectionメカニズムを介してHookを実行できるようにします。
+2. **アカウントでTSH Collectを有効化**（\`asfTshCollect\`、\`SetFlag: 11\`）：ネットワークがHook Collectメカニズムを介してHookを実行できるようにします。

 \`\`\`javascript
 // TSH Collectを有効化
@@ -3422,8 +3420,7 @@ const cronDelete = {
 |---|---|
 | \`temDISABLED\` | CronSet機能がネットワークで有効になっていない |
 | \`temMALFORMED\` | 無効なフィールドの組み合わせ（例：\`DelaySeconds\`/\`RepeatCount\`のどちらか一方のみ） |
-| \`tecEXPIRED\` | \`StartTime\`が過去または365日以上先 |
-| \`tefBAD_LEDGER\` | 削除しようとしているCronオブジェクトが存在しない |`,
+| \`tecEXPIRED\` | \`StartTime\`が過去または365日以上先 |`,
      },
      codeBlocks: [
        {
@@ -3672,7 +3669,7 @@ async function deleteCron() {

  if (txResult === "tesSUCCESS") {
    console.log("CronSet eliminado. El Hook ya no se ejecutará automáticamente.");
-  } else if (txResult === "tefBAD_LEDGER") {
+  } else {
    console.log("No existe un CronSet activo para esta cuenta.");
  }

@@ -3710,7 +3707,7 @@ async function deleteCron() {

  if (txResult === "tesSUCCESS") {
    console.log("CronSet deleted. The Hook will no longer run automatically.");
-  } else if (txResult === "tefBAD_LEDGER") {
+  } else {
    console.log("No active CronSet found for this account.");
  }

@@ -3748,7 +3745,7 @@ async function deleteCron() {

  if (txResult === "tesSUCCESS") {
    console.log("CronSetが削除されました。Hookは自動的に実行されなくなります。");
-  } else if (txResult === "tefBAD_LEDGER") {
+  } else {
    console.log("このアカウントにアクティブなCronSetが見つかりません。");
  }

--- a/src/data/modules/m11-xaman-sdk.js
+++ b/src/data/modules/m11-xaman-sdk.js
@@ -152,7 +152,7 @@ Your app                  Xaman API             Xaman (mobile)

 ### XUMM SDKとは？

-**xumm** npmパッケージはXaman APIとの連携を簡素化する公式SDKです。以下のことができます：
+**xumm** npmパッケージはXaman APIとの連携を簡素化する公式SDKです。次のようなことが可能です。

 - ユーザーがスマホで署名する**SignIn**によるユーザー認証
 - あらゆるXahauトランザクションタイプの**ペイロード**（署名リクエスト）の作成
@@ -477,7 +477,7 @@ const qrUrl   = created.refs.qr_png;  // QR image — show it in your modal
 const deepLink = created.next.always; // deep link for mobile
 const result   = await resolved;      // wait for sign or reject
 \`\`\``,
-        jp: `最初に構築する連携は**Xamanログイン**です：ユーザーがXamanアプリでQRをスキャンし、あなたのWebアプリケーションに認証されるフローです。Xahauエコシステムにおける「MetaMaskで接続」に相当します。
+        jp: `最初に構築する連携はユーザーがXamanアプリでQRをスキャンし、あなたのWebアプリケーションに認証されるフローである**Xamanログイン**です。これはXahauエコシステムにおける「MetaMaskで接続」に相当します。

 ### Xamanログインの仕組み

@@ -1236,7 +1236,7 @@ const txid   = result.txid;                              // transaction hash
 }
 \`\`\`

-金額は常に**drops**（XAHの最小単位）で表します。変換：\`drops = XAH × 1,000,000\`
+金額は常に**drops**（XAHの最小単位）で表します。\`drops = XAH × 1,000,000\`

 ### SDKでペイロードを作成する

@@ -2328,7 +2328,7 @@ xaman-backend/
    │   └── payment.js # Payment routes
    └── webhook.js    # Xaman webhook handler
 \`\`\``,
-        jp: `前のレッスンではフロントエンドがブラウザから直接ペイロードを作成しました（APIキーのみ使用）。**バックエンド**アプローチはセキュリティレイヤーとビジネスロジックを追加します：サーバーがAPIキーと**APIシークレット**を使ってペイロードを作成し、フロントエンドは表示するQRのみを受け取ります。
+        jp: `前のレッスンではフロントエンドがブラウザから直接ペイロードを作成しました（APIキーのみ使用）。**バックエンド**アプローチはセキュリティレイヤーとビジネスロジックを追加します。サーバーがAPIキーと**APIシークレット**を使ってペイロードを作成し、フロントエンドは表示するQRのみを受け取ります。

 ### なぜバックエンドを使うのか？

@@ -2341,23 +2341,23 @@ xaman-backend/
 ### バックエンドプロジェクトのアーキテクチャ

 \`\`\`
-Frontend (React)          Backend (Express)          Xaman API
-     │                          │                         │
+Frontend (React)           Backend (Express)          Xaman API
+     │                           │                         │
     │── POST /payment ────────▶ │                         │
     │   { destination, amount } │── ペイロード作成 ────────▶│
-     │                          │◀── UUID + QR URL ─────────│
-     │◀── { qrUrl, uuid } ───── │                         │
-     │                          │                         │
-     │ （ユーザーにQR表示）       │                         │
-     │                          │◀── Webhook: signed ──────│
-     │                          │   （ユーザーが署名）       │
-     │                          │── DBに保存               │
-     │                          │── レジャーで確認          │
+     │                           │◀── UUID + QR URL ───────│
+     │◀── { qrUrl, uuid } ────── │                         │
+     │                           │                         │
+     │ （ユーザーにQR表示）         │                         │
+     │                           │◀── Webhook: signed ─────│
+     │                           │   （ユーザーが署名）       │
+     │                           │── DBに保存               │
+     │                           │── レジャーで確認          │
 \`\`\`

 ### Webhookと WebSocketサブスクリプション

-署名通知を受け取る方法は2つあります：
+署名通知を受け取る方法には次の2つがあります。

 **Webhook**（本番環境推奨）：
 - ユーザーが署名するとXamanがサーバーにHTTP POSTを送信
@@ -2385,9 +2385,9 @@ XUMM_API_SECRET=your-api-secret-here
 PORT=3001
 \`\`\`

-\`.env\`を\`.gitignore\`に追加して認証情報がGitHubに上がらないようにしましょう。
+\`.env\`を\`.gitignore\`に追加して認証情報がGitHubにPushされないようにしましょう。

-APIシークレットが漏洩した疑いがある場合は、Xummダッシュボードから認証情報をローテーションしてください：新しいAPIキー＋APIシークレットのペアを生成し、バックエンドを新しい認証情報で更新して、古いものを削除します。
+APIシークレットが漏洩した疑いがある場合は、Xummダッシュボードから認証情報をローテーションしてください。新しいAPIキー+APIシークレットのペアを生成し、バックエンドを新しい認証情報で更新して、古いものを削除します。

 ### バックエンドプロジェクトの構造