Update Japanese translation files

2025-11-22 12:45:50 +00:00 · 2020-06-05 17:21:18 -07:00
parent 5d47d4f288
commit fcad9d0376
110 changed files with 9094 additions and 2955 deletions
--- a/content/tutorials/get-started/get-started-with-the-rippled-api.ja.md
+++ b/content/tutorials/get-started/get-started-with-the-rippled-api.ja.md
@@ -1,14 +1,37 @@
 # XRP Ledger APIの使用開始

-`rippled`サーバーに対してコマンドを実行するには、接続先のサーバーをあらかじめ把握しておく必要があります。大多数のサーバーは、外部ネットワークからの直接のAPI要求を受け入れないよう設定されています。
+XRP Ledgerのコアサーバーソフトウェアは[`rippled`](the-rippled-server.html)です。XRP Ledgerでの開発に進むには、`rippled`サーバーのAPIにアクセスします。

-別の方法として、[`rippled`の独自のローカルコピーを運用](install-rippled.html)することもできます。[管理用のメソッド](admin-rippled-methods.html)のいずれかにアクセスする場合、これは必須です。この場合、サーバーのバインド用として設定したIPアドレスとポートを使用する必要があります（例えば`127.0.0.1:54321`）。また、管理機能にアクセスするには、構成ファイルで管理用としてマークされているポートおよびIPアドレスから接続しなければなりません。
+APIにアクセスする最も簡単な方法は、[**WebSocket API Tool**](websocket-api-tool.html)を使用するか、[XRP Ledger Explorer](https://livenet.xrpl.org/)を使用してレジャーの進行状況をその場で確認することです。
+
+[`rippled`の独自のインスタンスを実行](install-rippled.html)したり、[公開サーバー](#公開サーバー)を使用したりすることもできます。
+
+## 公開サーバー
+
+Rippleは、XRP Ledgerコミュニティ向けにいくつかの公開サーバーを提供しています。
+
+| 演算子 | [ネットワーク][ | JSON-RPC URL | WebSocket URL | 注記 |
+|:----------|:----------|:----------|:----------|:----------|
+| Ripple | **Mainnet** | `https://s1.ripple.com:51234/` | `wss://s1.ripple.com/` | 汎用サーバークラスター |
+| Ripple | **Mainnet** | `https://s2.ripple.com:51234/` | `wss://s2.ripple.com/` | [すべての履歴が記録されるサーバー](ledger-history.html#すべての履歴)クラスター |
+| Ripple | Testnet | `https://s.altnet.rippletest.net:51234/` | `wss://s.altnet.rippletest.net/` | Testnet公開サーバー |
+| Ripple | Devnet | `https://s.devnet.rippletest.net:51234/` | `wss://s.devnet.rippletest.net/` | Devnet公開サーバー |
+
+[ネットワーク]: parallel-networks.html
+
+これらの公開サーバーは継続的な使用やビジネスでの使用を想定したものではなく、いつでも使用不可となる可能性があります。日常的な使用については、独自の`rippled`サーバーを自社で運用するか、信頼できる事業者と運用委託契約を締結します。
+
+
+## 管理者アクセス権限
+
+`rippled`サーバーの[管理メソッド](admin-rippled-methods.html)を使用するには、次のように行います。この場合、サーバーのバインド用として設定したIPアドレスとポートを使用する必要があります（例えば`127.0.0.1:54321`）。また、管理機能にアクセスするには、構成ファイルで管理用としてマークされているポートおよびIPアドレスから接続しなければなりません。

 [構成ファイルの例](https://github.com/ripple/rippled/blob/8429dd67e60ba360da591bfa905b58a35638fda1/cfg/rippled-example.cfg#L1050-L1073)では、ローカルループバックネットワーク上（127.0.0.1）のポート5005でJSON-RPC（HTTP）、ポート6006でWebSocket（WS）の接続をリッスンし、接続されるすべてのクライアントを管理者として扱っています。

+
 ## WebSocket API

-いくつかのメソッドをXRP Ledgerで試すことを予定している場合は、独自のWebSocketコードを記述することなく、[Ripple WebSocket APIツール](websocket-api-tool.html)でAPIをすぐに使用できます。後ほど、独自の`rippled`サーバーへの接続が必要となった時点で、[ブラウザー](https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_client_applications)または[Node.jsで独自のクライアントをビルド](https://www.npmjs.com/package/ws)することが可能です。
+いくつかのメソッドをXRP Ledgerで試すことを予定している場合は、独自のWebSocketコードを記述することなく、[Ripple WebSocket APIツール](websocket-api-tool.html)でAPIをすぐに使用できます。後ほど、独自の`rippled`サーバーへの接続が必要となった時点で、[ブラウザー](monitor-incoming-payments-with-websocket.html)または[Node.jsで独自のクライアントをビルド](https://www.npmjs.com/package/ws)することが可能です。

 ### 要求フォーマット

@@ -20,25 +43,13 @@

 応答はJSONオブジェクトとして返されます。

-### 公開サーバー
-
-現在、Ripple社は以下の一連の公開WebSocketサーバーを運用しています。
-
-| `Domain`        | ポート | 注記                                 |
-|:----------------|:-----|:--------------------------------------|
-| `s1.ripple.com` | 443  | `wss://`のみ。汎用サーバー |
-| `s2.ripple.com` | 443  | `wss://`のみ。すべての履歴が記録されるサーバー    |
-
-これらの公開サーバーは継続的な使用やビジネスでの使用を想定したものではなく、いつでも使用不可となる可能性があります。日常的な使用については、独自の`rippled`サーバーを自社で運用するか、信頼できる事業者と運用委託契約を締結します。
-
-
 ## JSON-RPC

-任意のHTTPクライアント（[RESTED for Firefox](https://addons.mozilla.org/en-US/firefox/addon/rested/)や[Postman for Chrome](https://chrome.google.com/webstore/detail/postman/fhbjgbiflinjbdggehcddcbncdddomop?hl=en)など）を使用して、JSON-RPCで`rippled`サーバーを呼び出すことができます。ほとんどのプログラミング言語には、HTTP要求を組み込むためのライブラリーが用意されています。
+任意のHTTPクライアント（[RESTED for Firefox](https://addons.mozilla.org/en-US/firefox/addon/rested/)、[Postman for Chrome](https://chrome.google.com/webstore/detail/postman/fhbjgbiflinjbdggehcddcbncdddomop?hl=en)、[Online HTTP client ExtendsClass](https://extendsclass.com/rest-client-online.html)など）を使用して、JSON-RPCで`rippled`サーバーを呼び出すことができます。ほとんどのプログラミング言語には、HTTP要求を組み込むためのライブラリーが用意されています。

 ### 要求フォーマット

-JSON-RPC要求を作成するには、`rippled`サーバーがJSON-RPC接続をリッスンしているポートおよびIPアドレス上で、HTTP **POST**要求をルートパス（`/`）に送信します。HTTP/1.0またはHTTP/1.1を使用できます。HTTPSを使用する場合は、TLS v1.2を使用してください。セキュリティーの維持を理由として、`rippled` _は_ SSL v3以前をサポートしていません。
+JSON-RPC要求を作成するには、`rippled`サーバーがJSON-RPC接続をリッスンしているポートおよびIPアドレス上で、HTTP **POST**要求をルートパス（`/`）に送信します。HTTP/1.0またはHTTP/1.1を使用できます。HTTPSを使用する場合は、TLS v1.2を使用してください。セキュリティーの維持を理由として、`rippled`はSSL v3以前を _サポートしていません_ 。

 値を`application/json`として、`Content-Type`ヘッダーを常に記述してください。

@@ -51,17 +62,6 @@ JSON-RPC要求を作成するには、`rippled`サーバーがJSON-RPC接続を

 応答もJSONオブジェクトになります。

-### 公開サーバー
-
-現在、Ripple社は以下の一連の公開JSON-RPCサーバーを運用しています。
-
-| `Domain`        | ポート  | 注記                  |
-|:----------------|:------|:-----------------------|
-| `s1.ripple.com` | 51234 | 汎用サーバー |
-| `s2.ripple.com` | 51234 | すべての履歴が記録されるサーバー    |
-
-これらの公開サーバーは継続的な使用やビジネスでの使用を想定したものではなく、いつでも使用不可となる可能性があります。日常的な使用については、独自の`rippled`サーバーを自社で運用するか、信頼できる事業者と運用委託契約を締結します。
-

 ## コマンドライン

@@ -71,13 +71,14 @@ JSON-RPC要求を作成するには、`rippled`サーバーがJSON-RPC接続を
 rippled --conf=/etc/rippled.cfg server_info
 ```

-**注記:** コマンドラインインターフェイスは、管理の目的でのみ使用されることを想定しています。_サポートされるAPIではありません_。
+**注記:** コマンドラインインターフェイスは、管理の目的でのみ使用されることを想定しています。 _サポートされるAPIではありません_。


 ### 要求フォーマット

 コマンドラインでは、通常の（先頭にダッシュが付いた）コマンドラインオプションに続けてコマンドを記述した後、一連の限定的なパラメーターを空白文字で区切って記述します。空白文字などの特殊な文字が含まれている可能性があるパラメーター値は、一重引用符で囲みます。

+
 ## 要求の例

 <!-- MULTICODE_BLOCK_START -->
@@ -102,7 +103,7 @@ POST http://s1.ripple.com:51234/
    "method": "account_info",
    "params": [
        {
-            "account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
+           "account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
            "strict": true,
            "ledger_index": "validated"
        }
@@ -118,6 +119,7 @@ rippled account_info r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59 validated true

 <!-- MULTICODE_BLOCK_END -->

+
 ## 応答フォーマット

 ### 成功した場合の応答の例
@@ -128,7 +130,7 @@ rippled account_info r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59 validated true

 ```
 {
-  "id": 2,
+   "id": 2,
  "status": "success",
  "type": "response",
  "result": {
@@ -151,7 +153,7 @@ rippled account_info r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59 validated true
 *JSON-RPC*

 ```
-HTTP Status: 200 OK
+HTTP Status:200 OK
 {
    "result": {
        "account_data": {
@@ -165,11 +167,12 @@ HTTP Status: 200 OK
            "Sequence": 1400,
            "index": "4F83A2CF7E70F77F79A307E6A472BFC2585B806A70833CCD1C26105BAE0D6E05"
        },
-        "ledger_index": 6761012,
-        "status": "success"
+         "ledger_index": 6761012,
+         "status": "success"
    }
 }
 ```
+
 *コマンドライン*

 ```
@@ -196,13 +199,28 @@ HTTP Status: 200 OK

 成功した場合の応答に含まれているフィールドは、以下のとおりです。

-| `Field`         | 型     | 説明                                     |
-|:----------------|:---------|:------------------------------------------------|
-| `id`            | （場合により異なる） | （WebSocketのみ）この応答の要求元となった要求で提供されているID。 |
-| `status`        | 文字列   | （WebSocketのみ）値が`success`である場合、要求がサーバーによって正常に受信され、理解されたことを示します。 |
-| `result.status` | 文字列   | （JSON-RPCおよびコマンドライン）値が`success`である場合、要求がサーバーによって正常に受信され、理解されたことを示します。 |
-| `type`          | 文字列   | （WebSocketのみ）値が`response`である場合、コマンドに対する正常な応答であることを示します。[非同期の通知](subscribe.html)では、`ledgerClosed`や`transaction`など、異なる値が使用されます。 |
-| `result`        | オブジェクト   | クエリーの結果。内容はコマンドによって異なります。 |
+| `Field` | 型 | 説明 |
+|:----------|:----------|:----------|
+| `id` | （場合により異なる） | （WebSocketのみ）この応答の要求元となった要求で提供されているID。 |
+| `status` | 文字列 | （WebSocketのみ）値が`success`である場合、要求がサーバーによって正常に受信され、理解されたことを示します。 |
+| `result.status` | 文字列 | （JSON-RPCおよびコマンドライン）値が`success`である場合、要求がサーバーによって正常に受信され、理解されたことを示します。 |
+| `type` | 文字列 | （WebSocketのみ）値が`response`である場合、コマンドに対する正常な応答であることを示します。[非同期の通知](subscribe.html)では、`ledgerClosed`や`transaction`など異なる値が使用されます。 |
+| `result` | オブジェクト | クエリーの結果。内容はコマンドによって異なります。 |

 ### コマンドライン
+
 コマンドラインのメソッドはJSON-RPCと同一のインターフェイスを使用しているため、応答フォーマットはJSON-RPCの応答と同一です。
+
+## 関連項目
+
+- **コンセプト:**
+  - [XRP Ledgerの概要](xrp-ledger-overview.html)
+  - [ソフトウェアエコシステム](software-ecosystem.html)
+  - [並列ネットワーク](parallel-networks.html)
+- **チュートリアル:**
+  - [RippleAPI for JavaScriptの使用開始](get-started-with-rippleapi-for-javascript.html)
+  - [信頼できるトランザクションの送信](reliable-transaction-submission.html)
+  - [rippledサーバーの管理](manage-the-rippled-server.html)
+- **リファレンス:**
+  - [rippled APIリファレンス](rippled-api.html)
+  - [Ripple Data API v2](data-api.html)
--- a/content/tutorials/get-started/look-up-transaction-results.ja.md
+++ b/content/tutorials/get-started/look-up-transaction-results.ja.md
@@ -1,21 +1,449 @@
 # トランザクションの結果の確認

-トランザクションの最終結果を確認するには、[txメソッド][]または[account_txメソッド][]を使用するか、`rippled`の他の応答を使用します。コンセンサスにより検証されたレジャーバージョンがこの応答に使用されていることを示す`"validated": true`を検索します。
+XRP Ledgerを効果的に使用するには、[トランザクション](transaction-basics.html)の結果を次のように把握することが重要です。トランザクションは成功したか？トランザクションは何を遂行したか？失敗した場合は、なぜか？

-| フィールド                  | 値   | 説明                               |
-|:-----------------------|:--------|:------------------------------------------|
-| meta.TransactionResult | 文字列  | 結果を以下のように分類するコード（`tecPATH_DRY`など） |
-| validated              | ブール値 | この結果が検証済みレジャーの結果であるかどうか。`false`の場合、結果は暫定的です。`true`の場合、結果は最終結果です。 |
+XRP Ledgerは共有システムとなっていて、すべてのデータが公開された形で正確に記録され、データはそれぞれ新しい[レジャーバージョン](ledgers.html)で安全に更新されます。誰もが任意のトランザクションの結果を確認し、[トランザクションメタデータ](transaction-metadata.html)によってその実行内容を確認できます。
+
+このドキュメントでは、トランザクションの結果がもたらされた理由を把握する方法について、詳細に説明します。エンドユーザー向けには、トランザクションの処理内容を表示するとわかりやすいです。例えば、[XRPチャートを使用して、記録されたトランザクションについての説明を英語で参照](https://xrpcharts.ripple.com/#/transactions/)できます。
+
+## 前提条件
+
+これらの手順で説明されているトランザクションの結果を理解するには、以下が必要となります。
+
+- 理解する対象となるトランザクションがわかっている。トランザクションの[識別用ハッシュ][]がわかっていれば、それによりトランザクションを検索できます。また、最近のレジャーで実行されたトランザクションまたは特定のアカウントに最後に影響を及ぼしたトランザクションを確認することもできます。
+- 信頼できる情報と、トランザクションの送信日時に関する必要な履歴を提供する`rippled`サーバーにアクセスできる。
+  - 最近送信したトランザクションの結果を確認する場合、トランザクションの送信時に使用したサーバーがネットワークと同期されていれば、そのサーバーにアクセスできるだけで十分です。
+  - 古いトランザクションの結果については、[全履歴を記録するサーバー](ledger-history.html#すべての履歴)を使用できます。
+
+**ヒント:** この他にも、[Data API](data-api.html)やエクスポートされた他のデータベースを使用するなど、XRP Ledgerからトランザクションのデータを照会する方法があります。ただし、これらのインターフェイスは正式なものではありません。このドキュメントでは、最も直接的で信頼できる結果を得るために、`rippled` APIを直接使用してデータを確認する方法を説明します。
+
+
+## 1. トランザクションステータスの取得
+
+トランザクションが成功したか失敗したかを確認するには、2つの問いが必要です。
+
+1. トランザクションが検証済みレジャーに記録されたか。
+2. 記録されていた場合、結果としてレジャーの状態はどのように変化したか。
+
+検証済みレジャーにトランザクションが記録されていたかどうかを確認するには、通常、トランザクションが記録されている可能性のあるすべてのレジャーにアクセスする必要があります。最も簡単で確実な方法は、[全履歴を記録するサーバー](ledger-history.html#すべての履歴)でトランザクションを検索する方法です。[txメソッド][]、[account_txメソッド][]またはその他の`rippled`からの応答を使用します。コンセンサスにより検証されたレジャーバージョンがこの応答に使用されていることを示す`"validated": true`を検索します。
+
+- 結果に`"validated": true`がない場合は、その結果は一時的である可能性があり、トランザクションの結果が最終的なものであるかどうかを知るには、レジャーが検証されるまで待機する必要があります。
+- 結果に目的のトランザクションが含まれていない場合、または`txnNotFound`エラーが返される場合は、サーバーにある利用可能な履歴に保存されているどのレジャーにもそのトランザクションはありません。ただし、このことだけでトランザクションが失敗したかどうかを判断できないことがあります。サーバーに保存されていない検証済みレジャーバージョンにトランザクションが記録されている、または今後検証されるレジャーにトランザクションが記録されている場合があるためです。以下を把握することで、トランザクションが記録されるレジャーの範囲を制限することができます。
+  - トランザクションが記録されている可能性のある最古のレジャー。つまり、**トランザクションを初めて送信した _後に_ 最初に検証されるレジャー**。
+  - トランザクションが記録されている可能性のある最新のレジャー。つまり、トランザクションの`LastLedgerSequence`フィールドで定義されるレジャー
+
+以下の例では、成功したトランザクションが[txメソッド][]によって返され、検証済みレジャーバージョンに記録されています。わかりやすくするために、JSON応答のフィールドの順序を並べ替え、一部を省略しています。

 ```json
-   "hash": "E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7",
-   "meta": {
-     ...
-     "TransactionResult": "tesSUCCESS"
-   },
-   "validated": true
+{
+  "TransactionType": "AccountSet",
+  "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
+  "Sequence": 376,
+  "hash": "017DED8F5E20F0335C6F56E3D5EE7EF5F7E83FB81D2904072E665EEA69402567",
+
+  ... (省略) ...
+
+  "meta": {
+    "AffectedNodes": [
+      ... (省略) ...
+    ],
+    "TransactionResult": "tesSUCCESS"
+  },
+  "ledger_index": 46447423,
+  "validated": true
+}
 ```

+この例では、rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpnというアドレスを持つ[アカウント](accounts.html)が、[シーケンス番号][] 376を使用して、[AccountSetトランザクション][]を送信したことを示しています。トランザクションの[識別用ハッシュ][]は`017DED8F5E20F0335C6F56E3D5EE7EF5F7E83FB81D2904072E665EEA69402567`で、その[結果](transaction-results.html)は`tesSUCCESS`です。トランザクションは、検証済みのレジャーバージョン46447423に記録されたため、結果は最終的なものです。
+
+
+### ケース: 検証済みレジャーに記録されていない
+
+**トランザクションが検証済みレジャーに記録されていない場合は、共有XRP Ledgerの状態には _いかなる_ 影響も及ぼしません。** 今後レジャーに記録されるトランザクションの失敗が[_最終的_](finality-of-results.html)となる場合、その失敗が将来影響を及ぼすことはありません。
+
+トランザクションの失敗が最終的でない場合は、 _将来の_ 検証済みレジャーに記録される可能性があります。トランザクションを現在のオープンレジャーに適用して得た暫定的な結果から、トランザクションが最終レジャーに及ぼすと思われる影響を事前に確認できます。ただし、実際の結果は[さまざまな要因](finality-of-results.html#未確定の結果はどのように変更できますか)によって変わる場合があります。
+
+
+### ケース: 検証済みレジャーに記録されている
+
+トランザクションが検証済みレジャーに記録 _されている_ 場合、[トランザクションメタデータ](transaction-metadata.html)にはトランザクションの処理結果として、レジャーの状態に対して行われたすべての変更を網羅したレポートが含まれます。メタデータの`TransactionResult`フィールドには、以下のような、結果を要約した[トランザクション結果コード](transaction-results.html)が含まれます。
+
+- コード`tesSUCCESS`は、トランザクションが、おおよそ成功したことを示します。
+- `tec`-クラスコードは、トランザクションが失敗したことを示します。このことがレジャーの状態に及ぼす影響は、XRP[トランザクションコスト](transaction-cost.html)を消却し、場合によっては[有効期限切れのオファー](offers.html#オファーの有効期限)の削除および[Payment Channelの閉鎖](payment-channels.html#payment-channelのライフサイクル)などのブックキーピングを行うことだけです。
+- どのレジャーにもその他のコードは表示されません。
+
+結果コードは、トランザクションの結果の要約にすぎません。トランザクションの実行内容を詳しく理解するには、トランザクションの指示とトランザクションの実行前のレジャーの状態に照らして残りのメタデータを確認する必要があります。
+
+
+## 2. メタデータの解釈
+
+トランザクションメタデータは、以下に示すフィールドをはじめとして、トランザクションがレジャーに適用された方法を _正確に_ 示します。
+
+{% include '_snippets/tx-metadata-field-table.md' %} <!--_ -->
+
+ほとんどのメタデータは、[`AffectedNodes`配列](transaction-metadata.html#affectednodes)に含まれています。この配列で探す対象は、トランザクションのタイプによって異なります。ほぼすべてのトランザクションが、送金元の[AccountRootオブジェクト][]を変更してXRP[トランザクションコスト](transaction-cost.html)を消却し、[アカウントのシーケンス番号](basic-data-types.html#アカウントシーケンス)を増やします。
+
+**情報:** このルールの例外として[疑似トランザクション](pseudo-transaction-types.html)があります。このトランザクションは実在するアカウントから送信されないため、AccountRootオブジェクトを変更しません。その他の例外として、AccountRootオブジェクトの`Balance`フィールドを変更せずに、AccountRootオブジェクトを変更するトランザクションがあります。[Free Key Resetトランザクション](transaction-cost.html#key-resetトランザクション)の場合、送金元のXRP残高は変わりません。トランザクションによって消却される金額と同額のXRPをアカウントが受け取る場合（ただし、このようなことはほとんどありません）、そのアカウントの正味残高は変わりません。（XRPを受領したアカウントに関係なくトランザクションコストはメタデータの別の場所に反映されます。）
+
+以下は、上記のステップ1からの応答全文例です。レジャーに対して行われた変更を把握できるか確認してください。
+
+```json
+{
+  "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
+  "Fee": "12",
+  "Flags": 2147483648,
+  "LastLedgerSequence": 46447424,
+  "Sequence": 376,
+  "SigningPubKey": "03AB40A0490F9B7ED8DF29D246BF2D6269820A0EE7742ACDD457BEA7C7D0931EDB",
+  "TransactionType": "AccountSet",
+  "TxnSignature": "30450221009B2910D34527F4EA1A02C375D5C38CF768386ACDE0D17CDB04C564EC819D6A2C022064F419272003AA151BB32424F42FC3DBE060C8835031A4B79B69B0275247D5F4",
+  "date": 608257201,
+  "hash": "017DED8F5E20F0335C6F56E3D5EE7EF5F7E83FB81D2904072E665EEA69402567",
+  "inLedger": 46447423,
+  "ledger_index": 46447423,
+  "meta": {
+    "AffectedNodes": [
+      {
+        "ModifiedNode": {
+          "LedgerEntryType": "AccountRoot",
+          "LedgerIndex": "13F1A95D7AAB7108D5CE7EEAF504B2894B8C674E6D68499076441C4837282BF8",
+          "FinalFields": {
+            "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
+            "AccountTxnID": "017DED8F5E20F0335C6F56E3D5EE7EF5F7E83FB81D2904072E665EEA69402567",
+            "Balance": "396015164",
+            "Domain": "6D64756F31332E636F6D",
+            "EmailHash": "98B4375E1D753E5B91627516F6D70977",
+            "Flags": 8519680,
+            "MessageKey": "0000000000000000000000070000000300",
+            "OwnerCount": 9,
+            "Sequence": 377,
+            "TransferRate": 4294967295
+          },
+          "PreviousFields": {
+            "AccountTxnID": "E710CADE7FE9C26C51E8630138322D80926BE91E46D69BF2F36E6E4598D6D0CF",
+            "Balance": "396015176",
+            "Sequence": 376
+          },
+          "PreviousTxnID": "E710CADE7FE9C26C51E8630138322D80926BE91E46D69BF2F36E6E4598D6D0CF",
+          "PreviousTxnLgrSeq": 46447387
+        }
+      }
+    ],
+    "TransactionIndex": 13,
+    "TransactionResult": "tesSUCCESS"
+  },
+  "validated": true
+}
+```
+
+この[no-opトランザクション](cancel-or-skip-a-transaction.html)によって行われた _唯一_ の変更は[AccountRootオブジェクト][]の更新で、送金元のアカウントは以下のように表されています。
+
+- `Sequence`値は376から377に増えます。
+
+- このアカウントのXRPの`Balance`は、`396015176`から`396015164`（[XRPのdrop数](basic-data-types.html#xrp)）に変わります。残高から差し引かれた12dropは[トランザクションコスト](transaction-cost.html)で、このトランザクションの`Fee`フィールドに指定されています。
+
+- このトランザクションが、このアドレスから送信された最新のトランザクションとなったことを反映して[`AccountTxnID`](transaction-common-fields.html#accounttxnid)が変わります。
+
+- このアカウントに影響を及ぼした以前のトランザクションは、レジャーバージョン46447387で実行されたトランザクション`E710CADE7FE9C26C51E8630138322D80926BE91E46D69BF2F36E6E4598D6D0CF`で、`PreviousTxnID`および`PreviousTxnLgrSeq`フィールドに指定されています。（このことは、アカウントのトランザクション履歴をさかのぼる際に役立つ場合があります。）
+  
+  **注記:** メタデータには明示的に示されませんが、トランザクションがレジャーオブジェクトを変更すると、必ずそのオブジェクトの`PreviousTxnID`および`PreviousTxnLgrSeq`フィールドが現在のトランザクションの情報で更新されます。同じ送金元の複数のトランザクションが1つのレジャーバージョンに含まれている場合、最初のトランザクション以降の各トランザクションは、これらすべてのトランザクションを記録するレジャーバージョンの[レジャーインデックス](basic-data-types.html#レジャーインデックス)を値とする`PreviousTxnLgrSeq`を提供します。
+
+rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpnのアカウントの`ModifiedNode`エントリーが`AffectedNodes`配列の唯一のオブジェクトであるため、このトランザクションの結果として、このレジャーに対してその他の変更は行われませんでした。
+
+**ヒント:** トランザクションによってXRPが送信または受信される場合、送金元の残高の変動額はトランザクションコストと合算され、`Balance`フィールドの正味金額は1回で変更されます。例えば、1XRP（1,000,000drop）を送信し、トランザクションコストで10drop消却した場合、メタデータには`Balance`が1,000,010（XRPのdrop数）減少したと示されます。
+
+### 汎用的なブックキーピング
+
+ほぼすべてのトランザクションにより、以下のような変更が行われます。
+
+- **シーケンスとトランザクションコストの変更:** 送金元のシーケンス番号を増やし、トランザクションコストの支払いに使用するXRPを消却するために、[前述のとおりどのトランザクション（疑似トランザクションを除く）も、送金元の`AccountRoot`オブジェクトに変更を加えます](#2-メタデータの解釈)。
+- **アカウントのスレッド化:** オブジェクトを作成する一部のトランザクションでは、目的の受取人または宛先のアカウントの[AccountRootオブジェクト](accountroot.html)も変更し、そのアカウントに関連する何らかの要素が変更されたことを示します。このアカウントを「タグ付け」する手法で、オブジェクトの`PreviousTxnID`および`PreviousTxnLgrSeq`フィールドのみを変更します。これにより、これらのフィールドに指定されたトランザクションの「スレッド」を追跡することで、アカウントが保持するアカウントのトランザクション履歴を効率よく検索することができます。
+- **ディレクトリーの更新:** レジャーオブジェクトを作成または削除するトランザクションは、多くの場合[DirectoryNodeオブジェクト](directorynode.html)を変更して、どのオブジェクトが存在しているかを追跡します。また、トランザクションによって、アカウントの[所有者準備金](reserves.html#所有者準備金)に反映されるオブジェクトが追加されると、所有者の[AccountRootオブジェクト][]の`OwnerCount`が増加します。オブジェクトを削除すると、`OwnerCount`が減少します。
+
+アカウントの`OwnerCount`を増やす例:
+
+```json
+{
+  "ModifiedNode": {
+    "FinalFields": {
+      "Account": "r9cZA1mLK5R5Am25ArfXFmqgNwjZgnfk59",
+      "Balance": "9999999990",
+      "Flags": 0,
+      "OwnerCount": 1,
+      "Sequence": 2
+    },
+    "LedgerEntryType": "AccountRoot",
+    "LedgerIndex": "4F83A2CF7E70F77F79A307E6A472BFC2585B806A70833CCD1C26105BAE0D6E05",
+    "PreviousFields": {
+      "Balance": "10000000000",
+      "OwnerCount": 0,
+      "Sequence": 1
+    },
+    "PreviousTxnID": "B24159F8552C355D35E43623F0E5AD965ADBF034D482421529E2703904E1EC09",
+    "PreviousTxnLgrSeq": 16154
+  }
+}
+```
+
+多くのトランザクションのタイプで、[DirectoryNodeオブジェクト](directorynode.html)が作成または変更されます。これらのオブジェクトは、ブックキーピングに使用します。アカウントが所有するすべてのオブジェクト、またはすべてのオファーを追跡して、同じ為替レートで通貨を交換します。トランザクションがレジャーに新しいオブジェクトを作成した場合、トランザクションは既存のDirectoryNodeオブジェクトにエントリーを追加するか、別のDirectoryNodeオブジェクトを追加してディレクトリーの別のページを表さなければならないことがあります。トランザクションがレジャーからオブジェクトを削除した場合、トランザクションは不要となった1つ以上のDirectoryNodeオブジェクトを削除しなければならないことがあります。
+
+新しいオファーディクトリーを表すCreatedNodeの例:
+
+```json
+{
+  "CreatedNode": {
+    "LedgerEntryType": "DirectoryNode",
+    "LedgerIndex": "F60ADF645E78B69857D2E4AEC8B7742FEABC8431BD8611D099B428C3E816DF93",
+    "NewFields": {
+      "ExchangeRate": "4E11C37937E08000",
+      "RootIndex": "F60ADF645E78B69857D2E4AEC8B7742FEABC8431BD8611D099B428C3E816DF93",
+      "TakerPaysCurrency": "0000000000000000000000004254430000000000",
+      "TakerPaysIssuer": "5E7B112523F68D2F5E879DB4EAC51C6698A69304"
+    }
+  }
+},
+```
+
+トランザクションメタデータを処理する際に探すその他の項目は、トランザクションのタイプによって異なります。
+
+### 支払い
+
+[Paymentトランザクション][]はXRP間の直接トランザクション、[複数通貨間の支払い](cross-currency-payments.html)、または[（XRP以外の）発行済み通貨](issued-currencies.html)での直接トランザクションを表します。発行済み通貨からXRPへのトランザクション、またはXRPから発行済み通貨へのトランザクションなど、XRP間の直接トランザクション以外はすべて[partial payment](partial-payments.html)が可能です。
+
+XRPの額は、`AccountRoot`オブジェクトの`Balance`フィールドで追跡されます。（XRPは[Escrowオブジェクト](escrow-object.html)および[PayChannelオブジェクト](paychannel.html)にも存在する可能性がありますが、Paymentトランザクションがそれらに影響を及ぼすことはありません。）
+
+支払いでいくら支払われたかを確認するには、必ず[delivered_amountフィールド](partial-payments.html#delivered_amountフィールド)を使用する必要があります。
+
+支払いにLedgerEntryTypeが`AccountRoot`の`CreatedNode`が含まれている場合は、その支払いによってレジャーの[新しいアカウントへの資金供給](accounts.html#アカウントの作成)が行われたことを意味します。
+
+#### 発行済み通貨での支払い
+
+発行済み通貨を利用する支払いは、多少複雑です。
+
+発行済み通貨残高の変更は、[トラストライン](trust-lines-and-issuing.html)を表す[RippleStateオブジェクト](ripplestate.html)にすべて反映されます。一方の当事者のトラストラインで残高が増加すると、相手側当事者の残高は同じ額だけ減少すると考えられます。このことは、メタデータには、RippleStateオブジェクトの共有`Balance`に対する1回の変更としてのみ記録されます。この変更が「増加」または「減少」のどちらで記録されるかは、どちらのアカウントのアドレスが数値として大きいかによって決まります。
+
+1回の支払いは、複数のトラストラインとオーダーブックで構成される長い[パス](paths.html)をたどる場合があります。間接的に当事者間を接続する複数のトラストラインの残高を変更するプロセスを[Rippling](rippling.html)と呼びます。トランザクションの`Amount`フィールドに指定された`issuer`に応じて、支払先アカウントに結び付けられている複数のトラストライン（`RippleState`アカウント）で支払額を分割することもできます。
+
+**ヒント:** 変更されたオブジェクトがメタデータに表示される順序は、支払いを処理するときにこれらのオブジェクトにアクセスした順序とは必ずしも一致しません。`AffectedNodes`メンバーを並べ替えて資金がレジャーまでたどったパスを再構成すると、支払いの実行の詳細を把握しやすくなります。
+
+複数通貨間の支払いでは、[オファー](offer.html)の一部または全額を消費して、通貨コードとイシュアーが異なる通貨間で変更が行われます。トランザクションで`Offer`タイプの`DeletedNode`オブジェクトが示される場合は、全額が消費されたオファーを示しているか、または処理の時点で[期限切れになるか、または資金化されない](offers.html#オファーのライフサイクル)ことがわかったオファーを示している可能性があります。トランザクションで`Offer`タイプの`ModifiedNode`が示される場合は、オファーの一部が消費されたことを示します。
+
+[トラストラインの`QualityIn`および`QualityOut`設定](trustset.html)は、トラストラインの一方の側における発行済み通貨の額に影響を与える可能性があるため、残高の数値の変化は、送金元におけるその通貨の額と異なります。`delivered_amount`は、受取人による評価額でいくら送金されたのかを示します。
+
+送金額と受取額が[発行済み通貨の精度](currency-formats.html#発行済み通貨の精度)の範囲外である場合は、一方のトランザクションで0に丸められる金額が、他方から引き出される可能性があります。そのため、両当事者が、お互いの残高に10<sup>16</sup>倍の差があるときに取引をすると、丸めることによって少額の発行済み通貨が「作成」または「消却」される可能性があります。（XRPは丸められないので、XRPではこの状況は発生しません。）
+
+[パス](paths.html)の長さに応じて、複数通貨間の支払いのメタデータは _長く_ なります。例えば、[トランザクション8C55AFC2A2AA42B5CE624AEECDB3ACFDD1E5379D4E5BF74A8460C5E97EF8706B](https://xrpcharts.ripple.com/#/transactions/8C55AFC2A2AA42B5CE624AEECDB3ACFDD1E5379D4E5BF74A8460C5E97EF8706B)では、rHaaans...が発行した2.788 GCBを送金しXRPを支払いますが、2人のイシュアーのUSDを経由し、2つのアカウントにXRPを支払います。r9ZoLsJからのEURをETHと交換する資金供給されていないオファーを削除し、変更された合計17の異なるレジャーオブジェクトのブックキーピングを行います。
+
+### オファー
+
+[OfferCreateトランザクション][]では、成立した額や、トランザクションが`tfImmediateOrCancel`などのフラグを使用したかどうかによって、レジャーにオブジェクトが作成される場合と作成されない場合があります。トランザクションがレジャーのオーダーブックに新しいオファーを追加したどうかを確認するには、LedgerEntryTypeが`Offer`の`CreatedNode`エントリーを探します。例:
+
+```json
+{
+  "CreatedNode": {
+    "LedgerEntryType": "Offer",
+    "LedgerIndex": "F39B13FA15AD2A345A9613934AB3B5D94828D6457CCBB51E3135B6C44AE4BC83",
+    "NewFields": {
+      "Account": "rETSmijMPXT9fnDbLADZnecxgkoJJ6iKUA",
+      "BookDirectory": "CA462483C85A90DB76D8903681442394D8A5E2D0FFAC259C5B0C59269BFDDB2E",
+      "Expiration": 608427156,
+      "Sequence": 1082535,
+      "TakerGets": {
+        "currency": "EUR",
+        "issuer": "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq",
+        "value": "2157.825"
+      },
+      "TakerPays": "7500000000"
+    }
+  }
+}
+```
+
+タイプ`Offer`の`ModifiedNode`は、成立し、かつ一部が消費されたオファーを示します。1つのトランザクションで多数のオファーを消費できます。2種類の発行済み通貨を交換するオファーが、[オートブリッジング](autobridging.html)によってXRPを交換するオファーを消費することもあります。両替取引のすべてまたは一部をオートブリッジングできます。
+
+LedgerEntryTypeが`Offer`の`DeletedNode`は、すべて消費された成立オファー、処理の時点で[期限切れになるか、または資金化されない](offers.html#オファーのライフサイクル)ことがわかったオファー、または新しいオファーを発行する過程でキャンセルされたオファーを示すことができます。キャンセルされたオファーは識別できます。これは、キャンセルされたオファーを発行した`Account`は、そのオファーを削除するトランザクションの送信元であるためです。
+
+削除されたオファーの例:
+
+```json
+{
+  "DeletedNode": {
+    "FinalFields": {
+      "Account": "rETSmijMPXT9fnDbLADZnecxgkoJJ6iKUA",
+      "BookDirectory": "CA462483C85A90DB76D8903681442394D8A5E2D0FFAC259C5B0C595EDE3E1EE9",
+      "BookNode": "0000000000000000",
+      "Expiration": 608427144,
+      "Flags": 0,
+      "OwnerNode": "0000000000000000",
+      "PreviousTxnID": "0CA50181C1C2A4D45E9745F69B33FA0D34E60D4636562B9D9CDA1D4E2EFD1823",
+      "PreviousTxnLgrSeq": 46493676,
+      "Sequence": 1082533,
+      "TakerGets": {
+        "currency": "EUR",
+        "issuer": "rhub8VRN55s94qWKDv6jmDy1pUykJzF3wq",
+        "value": "2157.675"
+      },
+      "TakerPays": "7500000000"
+    },
+    "LedgerEntryType": "Offer",
+    "LedgerIndex": "9DC99BF87F22FB957C86EE6D48407201C87FBE623B2F1BC4B950F83752B55E27"
+  }
+}
+```
+
+オファーでは、両方のタイプの[DirectoryNodeオブジェクト](directorynode.html)を作成、削除、変更して、オファーの発行者と、どのオファーがどのような為替レートで利用可能になっているのかを追跡できます。一般的に、ユーザーがこのブックキーピングに細かな注意を払う必要はありません。
+
+削除するオファーがなかった場合でも、[OfferCancelトランザクション][]には、コード`tesSUCCESS`が含まれる可能性があります。トランザクションが実際にオファーを削除したことを確認するには、LedgerEntryTypeが`Offer`の`DeletedNode`を探します。削除されていなかった場合は、そのオファーは以前のトランザクションによってすでに削除された可能性があります。またはOfferCancelトランザクションで、`OfferSequence`フィールドに誤ったシーケンス番号が使用された可能性があります。
+
+OfferCreateトランザクションが、タイプが`RippleState`の`CreatedNode`を示す場合は、取引で受け取った発行済み通貨を保持するために、[オファーがトラストラインを作成した](offers.html#オファーとトラスト)ことを示しています。
+
+### Escrow
+
+成功した[EscrowCreateトランザクション][]は、レジャーに[Escrowオブジェクト](escrow-object.html)を作成します。LedgerEntryTypeが`Escrow`の`CreatedNode`エントリーを探します。`NewFields`には、escrowに預託されたXRPと同じ`Amount`と、指定したその他のプロパティが示されます。
+
+成功したEscrowCreateトランザクションは、送金元から同じ額のXRPを引き出します。最終的なフィールドの`Account`がトランザクションの指示にある`Account`のアドレスと一致する、LedgerEntryTypeが`AccountRoot`の`ModifiedNode`を探します。XRPの`Balance`は、（トランザクションコストの支払いのためにXRPが消却されたのに加えて）XRPがescrowに預託されたため減少します。
+
+成功した[EscrowFinishトランザクション][]は、受取人の`AccountRoot`を変更して（`Balance`フィールドの）XRP残高を増やし、`Escrow`オブジェクトを削除し、escrow作成者の所有者数を減らします。escrow作成者、受取人および終了者をすべて異なるアカウントにしても、同じアカウントにしてもかまわないため、結果としてLedgerEntryTypeが`AccountRoot`の`ModifiedNode`オブジェクトが _1～3個_ になる可能性があります。XRPがescrowの最初の作成者に返されることを除けば、成功した[EscrowCancelトランザクション][]は極めて類似しています。
+
+EscrowFinishは、escrowの条件を満たす場合にのみ成功し、EscrowCancelはEscrowオブジェクトの期限が前のレジャーの閉鎖時刻よりも前である場合にのみ成功します。
+
+Escrowトランザクションでは、関係する送金元の所有者準備金やアカウントのディレクトリーを調整するために通常の[ブックキーピング](#汎用的なブックキーピング)も行われます。
+
+次に示すコードの抜粋では、r9UUEX...の残高が10億XRP増加し、その所有者の数が1人減少しています。これは、そのアカウントからの自分自身へのescrowが正常に終了したためです。[第三者がescrowを完了した](https://xrpcharts.ripple.com/#/transactions/C4FE7F5643E20E7C761D92A1B8C98320614DD8B8CD8A04CFD990EBC5A39DDEA2)ため`Sequence`番号は変更されません。
+
+```json
+{
+ "ModifiedNode": {
+    "FinalFields": {
+      "Account": "r9UUEXn3cx2seufBkDa8F86usfjWM6HiYp",
+      "Balance": "1650000199898000",
+      "Flags": 1048576,
+      "OwnerCount": 11,
+      "Sequence": 23
+    },
+    "LedgerEntryType": "AccountRoot",
+    "LedgerIndex": "13FDBC39E87D9B02F50940F9FDDDBFF825050B05BE7BE09C98FB05E49DD53FCA",
+    "PreviousFields": {
+      "Balance": "650000199898000",
+      "OwnerCount": 12
+    },
+    "PreviousTxnID": "D853342BC27D8F548CE4D7CB688A8FECE3229177790453BA80BC79DE9AAC3316",
+    "PreviousTxnLgrSeq": 41005507
+  }
+},
+{
+  "DeletedNode": {
+    "FinalFields": {
+      "Account": "r9UUEXn3cx2seufBkDa8F86usfjWM6HiYp",
+      "Amount": "1000000000000000",
+      "Destination": "r9UUEXn3cx2seufBkDa8F86usfjWM6HiYp",
+      "FinishAfter": 589075200,
+      "Flags": 0,
+      "OwnerNode": "0000000000000000",
+      "PreviousTxnID": "D5FB1C7D18F931A4FBFA468606220560C17ADF6DE230DA549F4BD11A81F19DFC",
+      "PreviousTxnLgrSeq": 35059548
+    },
+    "LedgerEntryType": "Escrow",
+    "LedgerIndex": "62F0ABB58C874A443F01CDCCA18B12E6DA69C254D3FB17A8B71CD8C6C68DB74D"
+  }
+},
+```
+
+### Payment Channel
+
+Payment Channelの作成時に、LedgerEntryTypeが`PayChannel`の`CreatedNode`を探します。また、送金元の残高の減少を示す、LedgerEntryTypeが`AccountRoot`の`ModifiedNode`も探す必要があります。アドレスが送金元に一致することを確認するために`FinalFields`の`Account`フィールドを探し、XRP残高の変化を確認するために`Balance`フィールドの差異を確認します。
+
+[fixPayChanRecipientOwnerDir Amendment](known-amendments.html#fixpaychanrecipientownerdir) :not_enabled: が有効な場合は、メタデータは宛先のアカウントの[所有者ディレクトリー](directorynode.html)を変更して、新しく作成されるPayment Channelをリストで示す必要もあります。これにより、アカウントがオープンPayment Channelの受取人である場合に、そのアカウントが[削除される](accounts.html#アカウントの削除)ことを防ぎます。（fixPayChanRecipientOwnerDir Amendmentが有効になる前にPayment Channelが作成された場合は、アカウントを削除できます。）
+
+Payment Channelの閉鎖を要求する方法は、Payment Channelの不変の`CancelAfter`時刻（作成時にのみ設定されます）以外にもいくつかあります。トランザクションでChannelの閉鎖をスケジュールする場合は、そのChannel用にLedgerEntryTypeが`PayChannel`の`ModifiedNode`エントリーがあり、`FinalFields`の`Expiration`フィールドには閉鎖時刻が新たに追加されています。以下の例は、送金元がクレームを清算せずにChannelを閉鎖するよう要求した場合に`PayChannel`に対して行われる変更を示します。
+
+```json
+{
+  "ModifiedNode": {
+    "FinalFields": {
+      "Account": "rNn78XpaTXpgLPGNcLwAmrcS8FifRWMWB6",
+      "Amount": "1000000",
+      "Balance": "0",
+      "Destination": "rwWfYsWiKRhYSkLtm3Aad48MMqotjPkU1F",
+      "Expiration": 608432060,
+      "Flags": 0,
+      "OwnerNode": "0000000000000002",
+      "PublicKey": "EDEACA57575C6824FC844B1DB4BF4AF2B01F3602F6A9AD9CFB8A3E47E2FD23683B",
+      "SettleDelay": 3600,
+      "SourceTag": 1613739140
+    },
+    "LedgerEntryType": "PayChannel",
+    "LedgerIndex": "DC99821FAF6345A4A6C41D5BEE402A7EA9198550F08D59512A69BFC069DC9778",
+    "PreviousFields": {},
+    "PreviousTxnID": "A9D6469F3CB233795B330CC8A73D08C44B4723EFEE11426FEE8E7CECC611E18E",
+    "PreviousTxnLgrSeq": 41889092
+  }
+}
+```
+
+### TrustSetトランザクション
+
+TrustSetトランザクションは、[`RippleState`オブジェクト](ripplestate.html)として表される[トラストライン](trust-lines-and-issuing.html)を作成、変更、または削除します。1つの`RippleState`オブジェクトに、関与する両当事者の設定が含まれます。これには両当事者の制限や[Ripplingの設定](rippling.html)などがあります。トラストラインの作成と変更によって[送金元の所有者準備金と所有者ディレクトリーの調整](#汎用的なブックキーピング)も行われます。
+
+以下の例は、**rf1BiG...** が**rsA2Lp...** によって発行されたUSDを最大110 USDまで保持するという新しいトラストラインを示します。
+
+```json
+ {
+  "CreatedNode": {
+    "LedgerEntryType": "RippleState",
+    "LedgerIndex": "9CA88CDEDFF9252B3DE183CE35B038F57282BC9503CDFA1923EF9A95DF0D6F7B",
+    "NewFields": {
+      "Balance": {
+        "currency": "USD",
+        "issuer": "rrrrrrrrrrrrrrrrrrrrBZbvji",
+        "value": "0"
+      },
+      "Flags": 131072,
+      "HighLimit": {
+        "currency": "USD",
+        "issuer": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
+        "value": "110"
+      },
+      "LowLimit": {
+        "currency": "USD",
+        "issuer": "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
+        "value": "0"
+      }
+    }
+  }
+}
+```
+
+
+### その他のトランザクション
+
+その他のほとんどのトランザクションは、特定のタイプのレジャーエントリーを作成し、[送金元の所有者準備金と所有者ディレクトリーの調整](#汎用的なブックキーピング)を行います。
+
+- [AccountSetトランザクション][]は、送金元の既存の[AccountRoot object][]を変更し、指定されたとおりに設定とフラグを変更します。
+- [DepositPreauthトランザクション][]は、特定の送金元の[DepositPreauthオブジェクト](depositpreauth-object.html)を追加または削除します。
+- [SetRegularKeyトランザクション][]は、送金元の[AccountRootオブジェクト][]を変更し、指定されたとおりに`RegularKey`フィールドを変更します。
+- [SignerListSetトランザクション][]は、[SignerListオブジェクト](signerlist.html)を追加、削除、または置換します。
+
+### 疑似トランザクション
+
+[疑似トランザクション](pseudo-transaction-types.html)にもメタデータがありますが、これらのトランザクションは通常のトランザクションのすべてのルールに従うとは限りません。これらのトランザクションは、実在のアカウントには関連付けられていないため（この`Account`の値は、[base58エンコード形式の数字の0](accounts.html#特別なアドレス)です）、レジャーのAccountRootオブジェクトを変更して`Sequence`シーケンス番号を増やしたり、XRPを消却したりしません。疑似トランザクションは、特別なレジャーオブジェクトに対して特定の変更のみを行います。
+
+- [EnableAmendment疑似トランザクション][]は、[Amendmentレジャーオブジェクト](amendments-object.html)を変更して、有効なAmendment、過半数の支持を得ている保留中のAmendment、および保留中の期間を追跡します。
+- [SetFee疑似トランザクション][]は、[FeeSettingsレジャーオブジェクト](feesettings.html)を変更して、[トランザクションコスト](transaction-cost.html)および[必要準備金](reserves.html)のベースレベルを変更します。
+
+## 関連項目
+
+- **コンセプト:**
+  - [結果のファイナリティー](finality-of-results.html) - トランザクションの成功また失敗が最終的なものとなるタイミングを判断する方法。（簡単な説明: トランザクションが検証済みレジャーにある場合は、その結果とメタデータは最終的なものです。）
+- **チュートリアル:**
+  - [信頼できるトランザクションの送信](reliable-transaction-submission.html)
+  - [WebSocketを使用した着信ペイメントの監視](monitor-incoming-payments-with-websocket.html)
+- **リファレンス:**
+  - [レジャーオブジェクトタイプのリファレンス](ledger-object-types.html) - レジャーオブジェクトの使用可能なすべてのタイプのフィールド
+  - [トランザクションのメタデータ](transaction-metadata.html) - メタデータフォーマットとメタデータに表示されるフィールドの概要
+  - [トランザクションの結果](transaction-results.html) - トランザクションのすべての結果コードを掲載した表一覧
+
+
 <!--{# common link defs #}-->
 {% include '_snippets/rippled-api-links.md' %}
 {% include '_snippets/tx-type-links.md' %}
--- a/content/tutorials/get-started/monitor-incoming-payments-with-websocket.ja.md
+++ b/content/tutorials/get-started/monitor-incoming-payments-with-websocket.ja.md
@@ -0,0 +1,601 @@
+# WebSocketを使用した着信ペイメントの監視
+
+このチュートリアルでは、[WebSocket `rippled` API](rippled-api.html)を使用して、着信[ペイメント](payment-types.html)を監視する方法を説明します。すべてのXRP Ledgerトランザクションは公開されているため、誰もが任意のアドレスへの着信ペイメントを監視できます。
+
+WebSocketは、クライアントとサーバーが1つの接続を確立し、その接続を経由して両方向にメッセージを送信するモデルに従います。この接続は、明示的に閉じる（または接続に障害が発生する）まで続きます。これは、要求ごとにクライアントが新しい接続を開いて閉じるHTTPベースのAPIモデル（JSON-RPCやRESTful APIなど）とは対照的です[¹](#footnote-1)<a id="from-footnote-1"></a>。
+
+**ヒント:** このページの例はJavaScriptを使用しているため、Webブラウザーでネイティブに実行できます。JavaScriptで開発している場合は、[JavaScript向けRippleAPIライブラリ](rippleapi-reference.html)も利用すると、一部の作業を簡素化できます。このチュートリアルでは、RippleAPIを使用できないその他のプログラミング言語にステップを適合できるよう、RippleAPIを使用 _しない_ でトランザクションを監視する方法を説明します。
+
+## 前提条件
+
+- このページの例では、すべての主要な最新ブラウザーで使用できるJavaScriptおよびWebSocketプロトコルを使用しています。JavaScriptにある程度習熟し、WebSocketクライアントを使用する他のプログラミング言語の専門知識があれば、選択する言語に手順を適合させながら進めていくことができます。
+- 安定したインターネット接続と`rippled`サーバーへアクセスが必要です。埋め込まれている例では、Rippleの公開サーバーのプールに接続します。[独自の`rippled`サーバーを運用](install-rippled.html)する場合は、ローカルでそのサーバーに接続することもできます。
+- 丸め方によるエラーを発生させることなくXRPの価値を適切に処理するには、64ビット符号なし整数で計算できる数値タイプを使用できる必要があります。このチュートリアルの例では、[big.js](https://github.com/MikeMcl/big.js/)を使用しています。[発行済み通貨](issued-currencies.html)を使用する場合は、さらに高い精度が求められます。詳細は、[通貨の精度](currency-formats.html#xrpの精度)を参照してください。
+
+<!-- Helper for interactive tutorial breadcrumbs -->
+<script type="application/javascript" src="assets/vendor/big.min.js"></script>
+<script type="application/javascript" src="assets/js/interactive-tutorial.js"></script>
+<script type="application/javascript">
+// Helper stuff for this interactive tutorial specifically
+
+function writeToConsole(console_selector, message) {
+  let write_msg = "<div class='console-entry'>" + message + "</div>"
+  $(console_selector).find(".placeholder").remove()
+  $(console_selector).append(write_msg)
+  // TODO: JSON pretty-printing, maybe w/ multiple input args?
+}
+
+</script>
+
+{% set n = cycler(* range(1,99)) %}
+
+## {{n.next()}}. XRP Ledgerへの接続
+
+着信ペイメントを監視する最初のステップとして、XRP Ledger、つまり`rippled`サーバーに接続します。
+
+以下のJavaScriptコードでは、Rippleの公開サーバーのクラスターの1つに接続します。その後、コンソールにメッセージを記録し、[pingメソッド][]を使用して要求を送信します。次に、サーバー側からのメッセージを受信するときに、ハンドラーを設定してコンソールに再度メッセージを記録します。
+
+```js
+const socket = new WebSocket('wss://s.altnet.rippletest.net:51233')
+socket.addEventListener('open', (event) => {
+  // This callback runs when the connection is open
+  console.log("Connected!")
+  const command = {
+    "id": "on_open_ping_1",
+    "command": "ping"
+  }
+  socket.send(JSON.stringify(command))
+})
+socket.addEventListener('message', (event) => {
+  console.log('Got message from server:', event.data)
+})
+socket.addEventListener('close', (event) => {
+  // Use this event to detect when you have become disconnected
+  // and respond appropriately.
+  console.log('Disconnected...')
+})
+```
+
+上記の例では、[Test Net](xrp-test-net-faucet.html)上にあるRippleの公開APIサーバーの1つに対して、安全な接続（`wss://`）を開きます。代わりにデフォルトの構成を使用してローカルで運用している`rippled`サーバーに接続するには、最初の行に以下を使用して、ローカルのポート**6006**で _安全ではない_ 接続（`ws://`）を開きます。
+
+```js
+const socket = new WebSocket('ws://localhost:6006')
+```
+
+**ヒント:** デフォルトでは、ローカル`rippled`サーバーに接続することで、インターネット上の公開サーバーに接続する際に使用できる[パブリックメソッド](public-rippled-methods.html)以外に、すべての[管理メソッド](admin-rippled-methods.html)と、[server_info][server_infoメソッド]などの一部の応答に含まれる管理者専用データを利用できます。
+
+例:
+
+{{ start_step("Connect") }}
+<button id="connect-button" class="btn btn-primary">Connect</button>
+<strong>Connection status:</strong>
+<span id="connection-status">Not connected</span>
+<div id='loader-{{n.current}}' style="display: none;"><img class='throbber' src="assets/img/xrp-loader-96.png"></div>
+<h5>Console:</h5>
+<div class="ws-console" id="monitor-console-connect"><span class="placeholder">(Log is empty)</span></div>
+{{ end_step() }}
+
+<script type="application/javascript">
+let socket;
+$("#connect-button").click((event) => {
+  socket = new WebSocket('wss://s.altnet.rippletest.net:51233')
+  socket.addEventListener('open', (event) => {
+    // This callback runs when the connection is open
+    writeToConsole("#monitor-console-connect", "Connected!")
+    $("#connection-status").text("Connected")
+    const command = {
+      "id": "on_open_ping_1",
+      "command": "ping"
+    }
+    socket.send(JSON.stringify(command))
+
+    complete_step("Connect")
+    $("#connect-button").prop("disabled", "disabled")
+    $("#enable_dispatcher").prop("disabled",false)
+  })
+  socket.addEventListener('close', (event) => {
+    $("#connection-status").text("Disconnected")
+    $("#connect-button").prop("disabled", false)
+  })
+  socket.addEventListener('message', (event) => {
+    writeToConsole("#monitor-console-connect", "Got message from server: " +
+          JSON.stringify(event.data))
+  })
+})
+</script>
+
+
+## {{n.next()}}. ハンドラーへの着信メッセージのディスパッチ
+
+WebSocket接続では、複数のメッセージをどちらの方向にも送信することが可能で、要求と応答の間に厳密な1:1の相互関係がないため、各着信メッセージに対応する処理を識別する必要があります。この処理をコーディングする際の優れたモデルとして、「ディスパッチャー」関数の設定が挙げられます。この関数は着信メッセージを読み取り、各メッセージを正しいコードのパスに中継して処理します。メッセージを適切にディスパッチできるように、`rippled`サーバーでは、すべてのWebSocketメッセージで`type`フィールドを使用できます。
+
+- クライアント側からの要求への直接の応答となるメッセージの場合、`type`は文字列の`response`です。この場合、サーバーは以下も提供します。
+  
+  - この応答に対する要求で指定された`id`に一致する`id`フィールド（応答が順序どおりに到着しない可能性があるため、これは重要です）。
+  
+  - APIが要求の処理に成功したかどうかを示す`status`フィールド。文字列値`success`は、[成功した応答](response-formatting.html)を示します。文字列値`error`は、[エラー](error-formatting.html)を示します。
+    
+    **警告:** トランザクションを送信する際、WebSocketメッセージの先頭にある`success`の`status`は、必ずしもトランザクション自体が成功したことを意味しません。これは、サーバーによって要求が理解されたということのみを示します。トランザクションの実際の結果を確認するには、[トランザクションの結果の確認](look-up-transaction-results.html)を参照してください。
+
+- [サブスクリプション](subscribe.html)からのフォローアップメッセージの場合、`type`は、新しいトランザクション、レジャーまたは検証の通知など、フォローアップメッセージのタイプを示します。または継続している[pathfinding要求](path_find.html)のフォローアップを示します。クライアントがこれらのメッセージを受信するのは、それらをサブスクライブしている場合のみです。
+
+**ヒント:** [JavaScript向けRippleAPI](rippleapi-reference.html)は、デフォルトでこのステップに対応しています。すべての非同期API要求はPromiseを使用して応答を提供します。また[`.on(event, callback)`メソッド](rippleapi-reference.html#listening-to-streams)を使用して、ストリームをリッスンできます。
+
+以下のJavaScriptコードでは、API要求を便利な非同期[Promise](https://developer.mozilla.org/en-US/docs/Web/JavaScript/Guide/Using_promises)に変換するヘルパー関数を定義し、他のタイプのメッセージをグローバルハンドラーにマップするインターフェイスを設定します。
+
+```js
+const AWAITING = {}
+const handleResponse = function(data) {
+  if (!data.hasOwnProperty("id")) {
+    console.error("Got response event without ID:", data)
+    return
+  }
+  if (AWAITING.hasOwnProperty(data.id)) {
+    AWAITING[data.id].resolve(data)
+  } else {
+    console.error("Response to un-awaited request w/ ID " + data.id)
+  }
+}
+
+let autoid_n = 0
+function api_request(options) {
+  if (!options.hasOwnProperty("id")) {
+    options.id = "autoid_" + (autoid_n++)
+  }
+
+  let resolveHolder;
+  AWAITING[options.id] = new Promise((resolve, reject) => {
+    // Save the resolve func to be called by the handleResponse function later
+    resolveHolder = resolve
+    try {
+      // Use the socket opened in the previous example...
+      socket.send(JSON.stringify(options))
+    } catch(error) {
+      reject(error)
+    }
+  })
+  AWAITING[options.id].resolve = resolveHolder;
+  return AWAITING[options.id]
+}
+
+const WS_HANDLERS = {
+  "response": handleResponse
+  // Fill this out with your handlers in the following format:
+  // "type": function(event) { /* handle event of this type */ }
+}
+socket.addEventListener('message', (event) => {
+  const parsed_data = JSON.parse(event.data)
+  if (WS_HANDLERS.hasOwnProperty(parsed_data.type)) {
+    // Call the mapped handler
+    WS_HANDLERS[parsed_data.type](parsed_data)
+  } else {
+    console.log("Unhandled message from server", event)
+  }
+})
+
+// Demonstrate api_request functionality
+async function pingpong() {
+  console.log("Ping...")
+  const response = await api_request({command: "ping"})
+  console.log("Pong!", response)
+}
+pingpong()
+```
+
+{{ start_step("Dispatch Messages") }}
+<button id="enable_dispatcher" class="btn btn-primary" disabled="disabled">Enable Dispatcher</button>
+<button id="dispatch_ping" class="btn btn-primary" disabled="disabled">Ping!</button>
+<h5>Responses</h5>
+<div class="ws-console" id="monitor-console-ping"><span class="placeholder">(Log is empty)</span></div>
+{{ end_step() }}
+
+<script type="application/javascript">
+const AWAITING = {}
+const handleResponse = function(data) {
+  if (!data.hasOwnProperty("id")) {
+    writeToConsole("#monitor-console-ping", "Got response event without ID:", data)
+    return
+  }
+  if (AWAITING.hasOwnProperty(data.id)) {
+    AWAITING[data.id].resolve(data)
+  } else {
+    writeToConsole("#monitor-console-ping", "Response to un-awaited request w/ ID " + data.id)
+  }
+}
+
+let autoid_n = 0
+function api_request(options) {
+  if (!options.hasOwnProperty("id")) {
+    options.id = "autoid_" + (autoid_n++)
+  }
+  let resolveFunc;
+  AWAITING[options.id] = new Promise((resolve, reject) => {
+    // Save the resolve func to be called by the handleResponse function later
+    resolveFunc = resolve
+    try {
+      // Use the socket opened in the previous example...
+      socket.send(JSON.stringify(options))
+    } catch(error) {
+      reject(error)
+    }
+  })
+  AWAITING[options.id].resolve = resolveFunc
+  return AWAITING[options.id]
+}
+
+const WS_HANDLERS = {
+  "response": handleResponse
+}
+$("#enable_dispatcher").click((clickEvent) => {
+  socket.addEventListener('message', (event) => {
+    const parsed_data = JSON.parse(event.data)
+    if (WS_HANDLERS.hasOwnProperty(parsed_data.type)) {
+      // Call the mapped handler
+      WS_HANDLERS[parsed_data.type](parsed_data)
+    } else {
+      writeToConsole("#monitor-console-ping", "Unhandled message from server: " + event)
+    }
+  })
+  complete_step("Dispatch Messages")
+  $("#dispatch_ping").prop("disabled", false)
+  $("#tx_subscribe").prop("disabled", false)
+})
+
+async function pingpong() {
+  const response = await api_request({command: "ping"})
+  writeToConsole("#monitor-console-ping", "Pong! " + JSON.stringify(response))
+}
+
+$("#dispatch_ping").click((event) => {
+  pingpong()
+})
+</script>
+
+## {{n.next()}}. アカウントのサブスクライブ
+
+トランザクションがアカウントに影響を及ぼすたびに即座に通知を取得するには、[subscribeメソッド][]を使用してアカウントをサブスクライブします。実際には、このアカウントはあなた自身のアカウントでなくてもかまいません。すべてのトランザクションは公開されているため、任意のアカウントで、または複数のアカウントでもサブスクライブできます。
+
+1つ以上のアカウントをサブスクライブした場合、指定したアカウントのいずれかに何らかの影響を及ぼす各検証済みトランザクションについて、`"type": "transaction"`が含まれるメッセージがサーバーから送信されます。これを確認するには、トランザクションメッセージで`"validated": true`を探します。
+
+以下のコードサンプルは、Test Net Faucetの送信側アドレスをサブスクライブします。このコードサンプルでは、前のステップのディスパッチャーにハンドラーを追加することで、該当する各トランザクションのメッセージを記録します。
+
+```js
+async function do_subscribe() {
+  const sub_response = await api_request({
+    command:"subscribe",
+    accounts: ["rUCzEr6jrEyMpjhs4wSdQdz4g8Y382NxfM"]
+  })
+  if (sub_response.status === "success") {
+    console.log("Successfully subscribed!")
+  } else {
+    console.error("Error subscribing: ", sub_response)
+  }
+}
+do_subscribe()
+
+const log_tx = function(tx) {
+  console.log(tx.transaction.TransactionType + " transaction sent by " +
+              tx.transaction.Account +
+              "\n  Result: " + tx.meta.TransactionResult +
+              " in ledger " + tx.ledger_index +
+              "\n  Validated? " + tx.validated)
+}
+WS_HANDLERS["transaction"] = log_tx
+```
+
+以下の例では、別のウィンドウまたは別のデバイスで[Transaction Sender](tx-sender.html)を開くことと、サブスクライブしているアドレスへのトランザクションの送信を試みます。
+
+{{ start_step("Subscribe") }}
+<label for="subscribe_address">Test Net Address:</label>
+<input type="text" class="form-control" id="subscribe_address" value="rUCzEr6jrEyMpjhs4wSdQdz4g8Y382NxfM">
+<button id="tx_subscribe" class="btn btn-primary" disabled="disabled">Subscribe</button>
+<h5>Transactions</h5>
+<div class="ws-console" id="monitor-console-subscribe"><span class="placeholder">(Log is empty)</span></div>
+{{ end_step() }}
+
+<script type="application/javascript">
+async function do_subscribe() {
+  const sub_address = $("#subscribe_address").val()
+  const sub_response = await api_request({
+    command:"subscribe",
+    accounts: [sub_address]
+  })
+  if (sub_response.status === "success") {
+    writeToConsole("#monitor-console-subscribe", "Successfully subscribed!")
+  } else {
+    writeToConsole("#monitor-console-subscribe",
+                   "Error subscribing: " + JSON.stringify(sub_response))
+  }
+}
+$("#tx_subscribe").click((event) => {
+  do_subscribe()
+  complete_step("Subscribe")
+  $("#tx_read").prop("disabled", false)
+})
+
+const log_tx = function(tx) {
+  writeToConsole("#monitor-console-subscribe",
+                  tx.transaction.TransactionType + " transaction sent by " +
+                  tx.transaction.Account +
+                  "<br/>&nbsp;&nbsp;Result: " + tx.meta.TransactionResult +
+                  " in ledger " + tx.ledger_index +
+                  "<br/>&nbsp;&nbsp;Validated? " + tx.validated)
+}
+WS_HANDLERS["transaction"] = log_tx
+</script>
+
+## {{n.next()}}. 着信ペイメントの読み取り
+
+アカウントをサブスクライブすると、 _アカウントへのすべてのトランザクションとアカウントからのすべてのトランザクション_ 、および _アカウントに間接的に影響を及ぼすトランザクション_ に関するメッセージが表示されます。この例として、[発行済み通貨](issued-currencies.html)の取引があります。アカウントが着信ペイメントを受け取った日時を認識することを目的とする場合、トランザクションストリームを絞り込んで、実際に支払われた額に基づいて支払いを処理する必要があります。以下の情報を探します。
+
+- **`validated`フィールド**は、トランザクションの結果が[最終的である](finality-of-results.html)ことを示します。これは、`accounts`をサブスクライブする場合に常に当てはまりますが、`accounts_proposed`または`transactions_proposed`ストリーム _も_ サブスクライブしている場合は、サーバーは未確認のトランザクションに関して同様のメッセージを同じ接続で送信します。予防策として、`validated`フィールドを常に確認することをお勧めします。
+
+- **`meta.TransactionResult`フィールド**は、[トランザクションの結果](transaction-results.html)です。結果が`tesSUCCESS`でない場合は、トランザクションは失敗したため、値を送信できません。
+
+- **`transaction.Account`** フィールドはトランザクションの送信元です。他の人が送信したトランザクションのみを探している場合は、このフィールドがあなたのアドレスと一致するトランザクションを無視できます（自身に対する複数通貨間の支払いが _可能である_ 点に注意してください）。
+
+- **`transaction.TransactionType`フィールド**はトランザクションのタイプです。アカウントに通貨を送金できる可能性があるトランザクションのタイプは以下のとおりです。
+  
+  - **[Paymentトランザクション][]** はXRPまたは[発行済み通貨](issued-currencies.html)を送金できます。受取人のアドレスを含んでいる`transaction.Destination`フィールドによってこれらを絞り込み、必ず`meta.delivered_amount`を使用して実際に支払われた額を確認します。XRPの額は、[文字列のフォーマットで記述されます](basic-data-types.html#通貨額の指定)。
+    
+    **警告:** 代わりに`transaction.Amount`フィールドを使用すると、[Partial Paymentの悪用](partial-payments.html#partial-paymentの悪用)に対して脆弱になる可能性があります。不正使用者はこの悪用を行ってあなたをだまし、あなたが支払ったよりも多くの金額を交換または引き出すことができます。
+  
+  - **[CheckCashトランザクション][]** :not_enabled: では、アカウントは別のアカウントの[CheckCreateトランザクション][]によって承認された金額を受け取ることができます。**CheckCashトランザクション**のメタデータを確認すると、アカウントが受け取った通貨の額を確認できます。
+  
+  - **[EscrowFinishトランザクション][]** は、以前の[EscrowCreateトランザクション][]によって作成された[Escrow](escrow.html)を終了することでXRPを送金できます。**EscrowFinishトランザクション**のメタデータを確認すると、escrowからXRPを受け取ったアカウントと、その額を確認できます。
+  
+  - **[OfferCreateトランザクション][]** はアカウントがXRP Ledgerの[分散型取引所](decentralized-exchange.html)で以前発行したオファーを消費することで、XRPまたは発行済み通貨を送金できます。オファーを発行しないと、この方法で金額を受け取ることはできません。メタデータを確認して、アカウントが受け取った通貨（この情報がある場合）と、金額を確認します。
+  
+  - **[PaymentChannelClaimトランザクション][]** では、[Payment Channel](payment-channels.html)からXRPを送金できます。メタデータを確認して、トランザクションからXRPを受け取ったアカウント（この情報がある場合）を確認します。
+  
+  - **[PaymentChannelFundトランザクション][]** は、閉鎖された（期限切れの）Payment Channelから送金元にXRPを返金することができます。
+
+- **`meta`フィールド**には、1つまたは複数の通貨の種類とその正確な金額、その送金先などを示す[トランザクションメタデータ](transaction-metadata.html)が示されています。トランザクションメタデータを理解する方法の詳細は、[トランザクションの結果の確認](look-up-transaction-results.html)を参照してください。
+
+以下のサンプルコードは、上に示したすべてのトランザクションのタイプのトランザクションメタデータを確認し、アカウントが受け取ったXRPの金額をレポートします。
+
+```js
+{% include '_code-samples/monitor-payments-websocket/read-amount-received.js' %}
+```
+
+{{ start_step("Read Payments") }}
+<button id="tx_read" class="btn btn-primary" disabled="disabled">Start Reading</button>
+<h5>Transactions</h5>
+<div class="ws-console" id="monitor-console-read"><span class="placeholder">(Log is empty)</span></div>
+{{ end_step() }}
+
+<script type="application/javascript">
+function CountXRPDifference(affected_nodes, address) {
+  // Helper to find an account in an AffectedNodes array and see how much
+  // its balance changed, if at all. Fortunately, each account appears at most
+  // once in the AffectedNodes array, so we can return as soon as we find it.
+
+  // Note: this reports the net balance change. If the address is the sender,
+  // any XRP balance changes combined with the transaction cost.
+
+  for (let i=0; i<affected_nodes.length; i++) {
+    if ((affected_nodes[i].hasOwnProperty("ModifiedNode"))) {
+      // modifies an existing ledger entry
+      let ledger_entry = affected_nodes[i].ModifiedNode
+      if (ledger_entry.LedgerEntryType === "AccountRoot" &&
+          ledger_entry.FinalFields.Account === address) {
+        if (!ledger_entry.PreviousFields.hasOwnProperty("Balance")) {
+          writeToConsole("#monitor-console-read", "XRP balance did not change.")
+        }
+        // Balance is in PreviousFields, so it changed. Time for
+        // high-precision math!
+        const old_balance = new Big(ledger_entry.PreviousFields.Balance)
+        const new_balance = new Big(ledger_entry.FinalFields.Balance)
+        const diff_in_drops = new_balance.minus(old_balance)
+        const xrp_amount = diff_in_drops.div(1e6)
+        if (xrp_amount.gte(0)) {
+          writeToConsole("#monitor-console-read", "Received " + xrp_amount.toString()+" XRP.")
+          return
+        } else {
+          writeToConsole("#monitor-console-read", "Spent " + xrp_amount.abs().toString() + " XRP.")
+          return
+        }
+      }
+    } else if ((affected_nodes[i].hasOwnProperty("CreatedNode"))) {
+      // created a ledger entry. maybe the account just got funded?
+      let ledger_entry = affected_nodes[i].CreatedNode
+      if (ledger_entry.LedgerEntryType === "AccountRoot" &&
+          ledger_entry.NewFields.Account === address) {
+        const balance_drops = new Big(ledger_entry.NewFields.Balance)
+        const xrp_amount = balance_drops.div(1e6)
+        writeToConsole("#monitor-console-read", "Received " + xrp_amount.toString() + " XRP (account funded).")
+        return
+      }
+    } // accounts cannot be deleted at this time, so we ignore DeletedNode
+  }
+
+  writeToConsole("#monitor-console-read", "Did not find address in affected nodes.")
+  return
+}
+
+function CountXRPReceived(tx, address) {
+  if (tx.meta.TransactionResult !== "tesSUCCESS") {
+    writeToConsole("#monitor-console-read", "Transaction failed.")
+    return
+  }
+  if (tx.transaction.TransactionType === "Payment") {
+    if (tx.transaction.Destination !== address) {
+      writeToConsole("#monitor-console-read", "Not the destination of this payment. (We're " +
+                      address + "; they're " + tx.transaction.Destination + ")")
+      return
+    }
+    if (typeof tx.meta.delivered_amount === "string") {
+      const amount_in_drops = new Big(tx.meta.delivered_amount)
+      const xrp_amount = amount_in_drops.div(1e6)
+      writeToConsole("#monitor-console-read", "Received " + xrp_amount.toString() + " XRP.")
+      return
+    } else {
+      writeToConsole("#monitor-console-read", "Received non-XRP currency.")
+      return
+    }
+  } else if (["PaymentChannelClaim", "PaymentChannelFund", "OfferCreate",
+          "CheckCash", "EscrowFinish"].includes(
+          tx.transaction.TransactionType)) {
+    CountXRPDifference(tx.meta.AffectedNodes, address)
+  } else {
+    writeToConsole("#monitor-console-read", "Not a currency-delivering transaction type (" +
+                tx.transaction.TransactionType + ").")
+  }
+}
+
+$("#tx_read").click((event) => {
+  // Wrap the existing "transaction" handler to do the old thing and also
+  // do the CountXRPReceived thing
+  const sub_address = $("#subscribe_address").val()
+  const old_handler = WS_HANDLERS["transaction"]
+  const new_handler = function(data) {
+    old_handler(data)
+    CountXRPReceived(data, sub_address)
+  }
+  WS_HANDLERS["transaction"] = new_handler
+  // Disable the button so you can't stack up multiple levels of the new handler
+  $("#tx_read").prop("disabled", "disabled")
+  complete_step("Read Payments")
+})
+</script>
+
+## 次のステップ
+
+- [トランザクションの結果の確認](look-up-transaction-results.html)で、トランザクションの実行内容を確認し、適切に対応するソフトウェアを構築します。
+- あなた自身のアドレスから[XRPの送金](send-xrp.html)を試します。
+- [Escrow](escrow.html)、[Checks](checks.html)または[Payment Channel](payment-channels.html)のような高度なタイプのトランザクションの監視と着信通知への応答を試します。
+<!--{# TODO: uncomment when it's ready. - To more robustly handle internet instability, [Follow a Transaction Chain](follow-a-transaction-chain.html) to detect if you missed a notification. #}-->
+
+## その他のプログラミング言語
+
+多くのプログラミング言語には、WebSocket接続を使用して、データの送受信を行うためのライブラリが用意されています。JavaScript以外の言語で`rippled`のWebSocket APIとの通信を効率良く始めるには、同様な機能を利用している以下の例を参考にしてください。
+
+<!-- MULTICODE_BLOCK_START -->
+
+*Go*
+
+```go
+package main
+
+// Connect to the XRPL Ledger using websocket and subscribe to an account
+// translation from the JavaScript example to Go
+// https://developers.ripple.com/monitor-incoming-payments-with-websocket.html
+// This example uses the Gorilla websocket library to create a websocket client
+// install: go get github.com/gorilla/websocket
+
+import (
+	"encoding/json"
+	"flag"
+	"log"
+	"net/url"
+	"os"
+	"os/signal"
+	"time"
+
+	"github.com/gorilla/websocket"
+)
+
+// websocket address
+var addr = flag.String("addr", "s.altnet.rippletest.net:51233", "http service address")
+
+// Payload object
+type message struct {
+	Command  string   `json:"command"`
+	Accounts []string `json:"accounts"`
+}
+
+func main() {
+	flag.Parse()
+	log.SetFlags(0)
+
+	var m message
+
+	// check for interrupts and cleanly close the connection
+	interrupt := make(chan os.Signal, 1)
+	signal.Notify(interrupt, os.Interrupt)
+
+	u := url.URL{Scheme: "ws", Host: *addr, Path: "/"}
+	log.Printf("connecting to %s", u.String())
+
+	// make the connection
+	c, _, err := websocket.DefaultDialer.Dial(u.String(), nil)
+	if err != nil {
+		log.Fatal("dial:", err)
+	}
+	// on exit close
+	defer c.Close()
+
+	done := make(chan struct{})
+
+	// send a subscribe command and a target XRPL account
+	m.Command = "subscribe"
+	m.Accounts = append(m.Accounts, "rUCzEr6jrEyMpjhs4wSdQdz4g8Y382NxfM")
+
+	// struct to JSON marshalling
+	msg, _ := json.Marshal(m)
+	// write to the websocket
+	err = c.WriteMessage(websocket.TextMessage, []byte(string(msg)))
+	if err != nil {
+		log.Println("write:", err)
+		return
+	}
+
+	// read from the websocket
+	_, message, err := c.ReadMessage()
+	if err != nil {
+		log.Println("read:", err)
+		return
+	}
+	// print the response from the XRP Ledger
+	log.Printf("recv: %s", message)
+
+	// handle interrupt
+	for {
+		select {
+		case <-done:
+			return
+		case <-interrupt:
+			log.Println("interrupt")
+
+			// Cleanly close the connection by sending a close message and then
+			// waiting (with timeout) for the server to close the connection.
+			err := c.WriteMessage(websocket.CloseMessage, websocket.FormatCloseMessage(websocket.CloseNormalClosure, ""))
+			if err != nil {
+				log.Println("write close:", err)
+				return
+			}
+			select {
+			case <-done:
+			case <-time.After(time.Second):
+			}
+			return
+		}
+	}
+}
+```
+
+<!-- MULTICODE_BLOCK_END -->
+
+**ヒント:** 目的のプログラミング言語の例がない場合があります。このページの最上部にある「GitHubで編集する」リンクをクリックして、作成したサンプルコードを提供してください。
+
+## 脚注
+
+[1.](#from-footnote-1)<a id="footnote-1"></a>実際には、HTTPベースのAPIを何度も呼び出す場合、クライアントとサーバーは複数の要求と応答を処理する際に同じ接続を再利用できます。この方法は、[HTTP永続接続、またはキープアライブ](https://en.wikipedia.org/wiki/HTTP_persistent_connection)と呼ばれます。開発の観点から見ると、基本となる接続が新しい場合でも、再利用される場合でも、HTTPベースのAPIを使用するコードは同じです。
+
+## 関連項目
+
+- **コンセプト:**
+  - [トランザクションの基本](transaction-basics.html)
+  - [結果のファイナリティー](finality-of-results.html) - トランザクションの成功また失敗が最終的なものとなるタイミングを判断する方法（簡単な説明: トランザクションが検証済みレジャーにある場合は、その結果とメタデータは最終的なものです）。
+- **チュートリアル:**
+  - [信頼できるトランザクションの送信](reliable-transaction-submission.html)
+  - [トランザクションの結果の確認](look-up-transaction-results.html)
+- **リファレンス:**
+  - [トランザクションのタイプ](transaction-types.html)
+  - [トランザクションのメタデータ](transaction-metadata.html) - メタデータフォーマットとメタデータに表示されるフィールドの概要
+  - [トランザクションの結果](transaction-results.html) - トランザクションのすべての結果コードを掲載した表一覧
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}			
+{% include '_snippets/tx-type-links.md' %}			
+{% include '_snippets/rippled_versions.md' %}
--- a/content/tutorials/get-started/set-up-secure-signing.ja.md
+++ b/content/tutorials/get-started/set-up-secure-signing.ja.md
@@ -0,0 +1,127 @@
+# 安全な署名の設定
+
+[トランザクション](transaction-basics.html)をXRP Ledgerに送信するには、[秘密鍵](cryptographic-keys.html)のセキュリティを損なわない方法でトランザクションにデジタル署名する必要があります。（他の人があなたの秘密鍵にアクセスできる場合、その人はあなたと同じようにあなたのアカウントを操作できるため、すべての資金が盗まれたり消却されたりする可能性があります。）このページでは、トランザクションに安全に署名できる環境の設定方法について説明します。
+
+**ヒント:** ネットワークにトランザクションを送信していない場合は、Rippleが運用しているサーバーなど、信頼できる公開サーバーを安全に使用して、着信トランザクションの監視やその他のネットワークアクティビティの読み取りを行うことができます。XRP Ledgerのすべてのトランザクション、残高、データは公開されています。
+
+セキュリティのレベルが異なるさまざまな構成があるため、状況に応じて適したものは異なります。次の中からニーズに最適なものを選択してください。
+
+- [`rippled`をローカルで実行](#ローカルでrippledを実行する)または[同じLAN内で実行](#同じlan内でrippledを実行する)
+- ローカル署名を行える[クライアントライブラリを使用](#ローカル署名機能のあるクライアントライブラリを使用する)
+- XRP Ledgerの署名に対応した[専用の署名デバイスを使用](#専用の署名デバイスを使用する)
+- 信頼できる[リモート`rippled`マシンに接続するために安全なVPNを使用](#リモートrippledサーバーに対して安全なvpnを使用する)
+
+<!-- Source for all diagrams in this article: https://docs.google.com/presentation/d/1BfGyWgC0njoPiKUZz3gXHMVSUINE3Q-_lHqY_D0TGwg/ -->
+
+## 安全でない構成
+
+[![安全でない構成の図](img/insecure-signing-options.png)](img/insecure-signing-options.png)
+
+外部のソースからあなたの秘密鍵にアクセスできる構成は危険で、不正使用者によってあなたのすべてのXRP（およびあなたのXRP Ledgerのアドレスにあるすべてのもの）が盗まれる可能性があります。そのような構成の例としては、インターネット経由で他の人の`rippled`サーバーの[signメソッド][]を使用する構成や、秘密鍵をインターネットを経由してプレーンテキストで自己所有サーバーに送信する構成などがあります。
+
+秘密鍵の秘匿性は常に保持する必要があります。自分にメールで送信したり、人の目に触れるところで入力したりしてはいけません。秘密鍵を使用しないときは、決してプレーンテキストではなく、暗号化された形式で保存する必要があります。セキュリティと利便性のバランスは、アドレスの保有額によっても変わります。さまざまな目的に合わせてさまざまなセキュリティ構成の複数のアドレスを使用することをお勧めします。
+
+<!-- Note: I'd link "issuing and operational addresses" for an explanation of hot/cold wallet security, but it's particularly gateway/issued-currency centric, which is not appropriate for this context. -->
+
+
+## ローカルでrippledを実行する
+
+[![署名にローカルrippledサーバーを使用する構成の図](img/secure-signing-local-rippled.png)](img/secure-signing-local-rippled.png)
+
+この構成では、トランザクションを生成するマシンで`rippled`を実行します。  秘密鍵はマシンから出ていかないため、マシンへのアクセス権がない人は秘密鍵にアクセスできません。もちろん、マシンのセキュリティ保護に関する業界標準のプラクティスに従ってください。この構成を使用するには、次の手順を実行します。
+
+1. [`rippled`をインストール](install-rippled.html)します。
+   
+   ローカルマシンが[`rippled`の最小システム要件](system-requirements.html)を満たしていることを確認します。
+
+2. トランザクションに署名する必要がある場合は、`localhost`または`127.0.0.1`のサーバーに接続します。シングル署名の場合は[signメソッド][]、マルチ署名の場合は[sign_forメソッド][]を使用します。
+   
+   [構成ファイルの例](https://github.com/ripple/rippled/blob/8429dd67e60ba360da591bfa905b58a35638fda1/cfg/rippled-example.cfg#L1050-L1073)では、ローカルループバックネットワーク上（127.0.0.1）のポート5005でJSON-RPC（HTTP）、ポート6006でWebSocket（WS）の接続をリッスンし、接続されるすべてのクライアントを管理者として扱っています。
+   
+   **注意:** 署名に[コマンドラインAPI](request-formatting.html#コマンドライン形式)を使用する場合は、コマンドラインでないクライアントで[Websocket APIやJSON-RPC APIを使用](get-started-with-the-rippled-api.html)する場合よりもセキュリティが弱くなります。コマンドライン構文を使用すると、秘密鍵がシステムのプロセスリストで他のユーザーに見える可能性があり、シェル履歴にプレーンテキスト形式でキーが保存される可能性があります。
+
+3. サーバーの使用中は、稼働状態と最新状態を維持して、ネットワークと同期されるようにしておく必要があります。
+   
+   **注記:** トランザクションを送信していないときは`rippled`サーバーをオフにすることが _可能_ ですが、再び起動したときにネットワークとの同期に最大15分かかります。
+   
+
+## 同じLAN内でrippledを実行する
+
+[![署名にLAN経由でrippledサーバーを使用する構成の図](img/secure-signing-lan-rippled.png)](img/secure-signing-lan-rippled.png)
+
+この構成では、署名するトランザクションを生成するマシンと同じプライベートローカルエリアネットワーク（LAN）内の専用マシンで`rippled`サーバーを実行します。この構成では、`rippled`を実行する専用の1台のマシンを使用しながら、中程度のシステムスペックの1台以上のマシンでトランザクションの指示を組み立てることができます。自己所有のデータセンターやサーバールームがある場合に魅力的な選択肢です。
+
+この構成を使用するには、`rippled`サーバーをLAN内の`wss`および`https`接続を受け入れるように設定します。[証明書ピンニング](https://en.wikipedia.org/wiki/Transport_Layer_Security#Certificate_pinning)を使用する場合は自己署名証明書を使用できます。あるいは、社内や既知の認証局が署名した証明書を使用できます。[Let's Encrypt](https://letsencrypt.org/)などの一部の認証局は無料で証明書を自動発行しています。
+
+<!--{# TODO: link api-over-lan.html with the detailed instructions when those are ready #}-->
+
+必ず、マシンのセキュリティ保護に関する業界標準のプラクティスに従ってください。例えば、ファイアウォール、ウイルス対策、適切なユーザー権限を使用するなどです。
+
+
+## ローカル署名機能のあるクライアントライブラリを使用する
+
+[![ローカル署名機能のあるクライアントライブラリを使用する構成の図](img/secure-signing-client-library.png)](img/secure-signing-client-library.png)
+
+この構成では、トランザクションにローカルで署名するために使用しているプログラミング言語のクライアントライブラリを使用します。使用しているプログラミング言語に対応するクライアントライブラリが必要です。Rippleは、XRP Ledgerのトランザクションにローカルで署名することができる次のクライアントライブラリを公開しています。
+
+- **RippleAPI（ripple-lib）for JavaScript**
+  - [設定](get-started-with-rippleapi-for-javascript.html)
+  - [APIリファレンス](rippleapi-reference.html)
+- **Signing Library for C++**（`rippled`に付属）
+  - [ドキュメント](https://github.com/ripple/rippled/tree/develop/Builds/linux#signing-library)
+
+Rippleが公開したものでないクライアントライブラリを使用する場合は、そのライブラリが実装している署名アルゴリズムの実装が適切で安全であることを確認してください。（例えば、クライアントライブラリがデフォルトのECDSAアルゴリズムを使用している場合は、そのライブラリは[RFC6979](https://tools.ietf.org/html/rfc6979)に記載されているとおりに決定論的ノンスを使用している必要があります。)Rippleが公開している上記のすべてのライブラリは、業界のベストプラクティスに従っています。
+
+最高レベルのセキュリティを実現するために、クライアントライブラリを安定した最新バージョンの状態に保ってください。
+
+### RippleAPIを使用したローカル署名の例
+
+以下のサンプルコードは、RippleAPI for JavaScriptを使用してトランザクションの指示にローカルで署名する方法を示しています。
+
+```js
+{% include '_code-samples/secure-signing/js/signPayment.js' %}
+```
+
+セキュリティを強化するために、[Vault](https://www.vaultproject.io/)などの管理ツールから秘密鍵を読み込みます。
+
+
+## 専用の署名デバイスを使用する
+
+[![専用の署名ハードウェアの使用の図](img/secure-signing-dedicated-hardware.png)](img/secure-signing-dedicated-hardware.png)
+
+専用の署名デバイスが各社から販売されており、例えば[Ledger Nano S](https://www.ledger.com/products/ledger-nano-s)は、秘密鍵をデバイスから出さずに使ってXRP Ledgerトランザクションに署名できます。すべてのタイプのトランザクションに対応していないデバイスもあります。
+
+この構成の設定は、特定のデバイスによって異なります。場合によっては、署名デバイスと通信するためにマシンで「マネージャー」アプリケーションを実行する必要があります。そのようなデバイスの設定と使用方法については、メーカーの手順を参照してください。
+
+
+## リモートrippledサーバーに対して安全なVPNを使用する
+
+[![VPNを経由してリモート`rippled`に安全に接続する構成の図](img/secure-signing-over-vpn.png)](img/secure-signing-over-vpn.png)
+
+この構成では、コロケーション施設や遠隔地のデータセンターなどにあるリモートでホストされている`rippled`サーバーを使用し、暗号化されたVPNを使用してそのサーバーに接続します。
+
+この構成を使用するには、[プライベートLANで`rippled`を実行](#同じlan内でrippledを実行する)するための手順に従いますが、VPNを使用してリモート`rippled`サーバーのLANに接続します。VPNの設定手順は環境によって異なり、このガイドでは説明しません。
+
+
+## 関連項目
+
+- **コンセプト:**
+  - [暗号鍵](cryptographic-keys.html)
+  - [マルチ署名](multi-signing.html)
+- **チュートリアル:**
+  - [rippledのインストール](install-rippled.html)
+  - [レギュラーキーペアの割り当て](assign-a-regular-key-pair.html)
+  - [信頼できるトランザクションの送信](reliable-transaction-submission.html)
+  - [パブリック署名の有効化](enable-public-signing.html)
+- **リファレンス:**
+  - [signメソッド][]
+  - [submitメソッド][]
+  - [RippleAPIリファレンス](rippleapi-reference.html)
+
+
+
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}			
+{% include '_snippets/tx-type-links.md' %}			
+{% include '_snippets/rippled_versions.md' %}
--- a/content/tutorials/manage-account-settings/offline-account-setup.ja.md
+++ b/content/tutorials/manage-account-settings/offline-account-setup.ja.md
@@ -0,0 +1,340 @@
+# オフラインでのアカウント設定のチュートリアル
+
+きわめて安全な[署名構成](set-up-secure-signing.html)では、XRP Ledger[アカウント](accounts.html)の[暗号鍵](cryptographic-keys.html)をオフラインの物理的に隔離されたマシンに安全に保管します。この構成を設定すると、さまざまなトランザクションに署名して、署名済みトランザクションのみをオンラインコンピューターに転送し、秘密鍵をオンラインにいる不正使用者に見せることなくそれらのトランザクションをXRP Ledgerネットワークに送信できます。
+
+**注意:** オフラインマシンを保護するためには、適切な運用セキュリティ対策が必要です。例えば、オフラインマシンは信頼できない人がアクセスできない場所に物理的に設置する必要があり、信頼できるオペレーターはマシンに悪用されたソフトウェアを転送しないように注意する必要があります。（例えば、ネットワークに接続されたコンピューターに接続したことがあるUSBドライブは使用してはいけません。）
+
+## 前提条件
+
+オフライン署名を使用するには、次の前提条件を満たしている必要があります。
+
+- オフラインマシンとして使用する1台のコンピューターを用意していること。このマシンは[サポートされているオペレーティングシステム](system-requirements.html)でセットアップされている必要があります。オフラインセットアップの手順については、使用するオペレーティングシステムのサポートを参照してください（例: [Red Hat Enterprise Linux DVD ISOインストール手順](https://access.redhat.com/solutions/7227)）。使用するソフトウェアと物理メディアがマルウェアに感染していないことを確認します。
+- オンラインマシンとして使用する別のコンピューターを用意していること。このマシンは`rippled`を実行する必要はありませんが、XRP Ledgerネットワークに接続し、共有レジャーの状態についての正確な情報を受信できる必要があります。例えば、[公開サーバーへのWebSocket接続](get-started-with-the-rippled-api.html)を使用できます。
+- 署名済みのトランザクションバイナリデータをオフラインマシンからオンラインマシンに転送する安全な方法を用意していること。
+  - その方法の1つは、オフラインマシンでQRコードジェネレーターを使用し、オンラインマシンでQRコードスキャナーを使用することです。（この場合、「オンラインマシン」はスマートフォンなどの携帯デバイスだとよいでしょう。）
+  - 別の方法としては、物理メディアを使ってオフラインマシンからオンラインマシンにファイルをコピーします。この方法を使用する場合、オフラインマシンが悪意のあるソフトウェアに感染するおそれのある物理メディアは使用しないよう注意します。（例えば、オンラインマシンとオフラインマシンで同じUSBドライブを再利用しないようにします。）
+  - オンラインマシンにデータを手動で入力することも _可能_ ですが、面倒でミスが発生しやすくなります。
+
+
+## 手順
+
+{% set n = cycler(* range(1,99)) %}
+
+### {{n.next()}}. オフラインマシンの設定
+
+オフラインマシンには、安全な永続ストレージ（暗号化されたディスクドライブなど）と[トランザクションに署名する](set-up-secure-signing.html)ための方法が必要です。一般的には、必要なソフトウェアをオンラインマシンでダウンロードして、物理メディアを使ってオフラインマシンに転送します。オンラインマシン、物理メディア、ソフトウェア自体がマルウェアに感染していないことを確認する必要があります。
+
+XRP Ledgerで署名するためのソフトウェアオプションは次のとおりです。
+
+- パッケージ（`.deb`または`.rpm`。使用するLinuxディストリビューションによって異なる）ファイルから[`rippled`をインストール](install-rippled.html)し、[スタンドアロンモードで実行します](rippled-server-modes.html)。
+- [ripple-lib](rippleapi-reference.html)とその依存関係をオフラインでインストールします。例えば、Yarn Package Managerでは、[オフラインでの使用に関して推奨される手順](https://yarnpkg.com/blog/2016/11/24/offline-mirror/)があります。
+- 関連項目: [安全な署名の設定](set-up-secure-signing.html)
+
+オフラインマシンでトランザクションの指示を生成するプロセスを容易にするために、カスタムソフトウェアを設定することもできます。例えば、ソフトウェアで次に使用する[シーケンス番号][]を追跡したり、送信するトランザクションのタイプに応じた設定済みテンプレートを含めるといったことが可能です。
+
+### {{n.next()}}.暗号鍵の生成
+
+**オフラインマシン**で、アカウントで使用する[暗号鍵](cryptographic-keys.html)のペアを生成します。鍵は、単純なパスフレーズやエントロピーが十分でないその他のソースから生成するのではなく、安全なランダム手続きで生成してください。（例えば、`rippled`の[wallet_proposeメソッド][]を使用することができます。）
+
+<!-- MULTICODE_BLOCK_START -->
+
+
+_rippledコマンドライン_
+
+```sh
+$ ./rippled wallet_propose
+Loading: "/etc/opt/ripple/rippled.cfg"
+2019-Dec-09 22:58:24.110862955 HTTPClient:NFO Connecting to 127.0.0.1:5005
+
+{
+   "result" : {
+      "account_id" : "r4MRc4BArFPXmiDjmLdrufyFManSYhfKE6",
+      "key_type" : "secp256k1",
+      "master_key" : "JANE GIBE LIST TEND NU RUDE JIG PA FLOG DEFT SAME NASH",
+      "master_seed" : "shYHSiJod8CLPTj1SNJ2PdUFj4pFk",
+      "master_seed_hex" : "8465FDB80B2E2620A7D58274C26291A0",
+      "public_key" : "aBQLW8imt7VChRJU1NMVCB7fE3jSL3VNEgLDKf88ygAhnfuZh3oo",
+      "public_key_hex" : "03396074ED4B8155ACF9A8DC3665EFA53B5CFA0A1E91C3879303D37721EB222644",
+      "status" : "success"
+   }
+}
+```
+
+<!-- MULTICODE_BLOCK_END -->
+
+次の値をメモします。
+
+- **`account_id`**:  これはキーペアに関連付けられているアドレスです。このアドレスは、XRPを供給（このプロセスの先で実行）した後に、XRP Ledgerでの **[アカウント](accounts.html)アドレス**になります。`account_id`は公開しても安全です。
+- **`master_seed`**:  これはキーペアの秘密シード値です。この値は、アカウントからのトランザクションに署名する際に使用します。最高レベルのセキュリティを実現するために、この値をオフラインマシンのディスクに書き込む前に暗号化してください。暗号化キーとして、人間のオペレーターが覚えやすい安全なパスフレーズや、物理的に安全な場所に書き留めたパスフレーズを使います。例えば、適切な重さのサイコロを使用して作成する[ダイスウェアパスフレーズ](http://world.std.com/~reinhold/diceware.html)などがあります。第2の要素として物理セキュリティキーを使用することもできます。この段階で取る対策の程度はご自身で決めてください。
+- **`key_type`**:  これは、このキーペアに使用する暗号化アルゴリズムです。有効なトランザクションに署名するには、どのようなタイプのキーペアを所有しているかを知る必要があります。デフォルトは`secp256k1`です。
+
+`master_key`、`master_seed`、`master_seed_hex`の値はどこにも共有**しないでください**。これらはこのアドレスに関連付けられている秘密鍵を再作成するために使用できます。
+
+
+
+### {{n.next()}}.新しいアドレスへの資金の供給
+
+オンラインマシンから、ステップ1でメモした**アカウントアドレス** に十分なXRPを送金します。詳細は、[アカウントの作成](accounts.html#アカウントの作成)を参照してください。
+
+**ヒント:** テストの目的で、[Testnet Faucet](xrp-testnet-faucet.html)を使用して、テスト用のXRPが入った新しいアカウントを取得できます。そのアカウントを使用して、オフラインで生成されたアドレスに資金を供給します。
+
+
+
+### {{n.next()}}.アカウントの詳細の確認
+
+前のステップからのトランザクションがコンセンサスにより検証されたら、アカウントが作成されたことになります。オンラインマシンから、[account_infoメソッド][]を使用して、アカウントのステータスを確認します。応答に`"validated": true`が含まれていることを確認し、この結果が最終的なものであることを確認します。
+
+結果の`account_data`の`Sequence`フィールドにある、アカウントのシーケンス番号をメモします。この後のステップでアカウントのトランザクションに署名するために、このシーケンス番号を把握しておく必要があります。
+
+[DeletableAccounts Amendment](known-amendments.html#deletableaccounts) :not_enabled:がenabledになっている場合、新しく資金を供給したアカウントの`Sequence`番号は、資金を供給したときの[レジャーインデックス][]と一致します。enabledになっていない場合、新しく資金を供給したアカウントの`Sequence`番号は常に1です。
+
+<!-- MULTICODE_BLOCK_START -->
+
+_rippledコマンドライン_
+
+```sh
+$ ./rippled account_info rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn
+
+Loading: "/etc/opt/ripple/rippled.cfg"
+2019-Dec-11 01:06:21.728637950 HTTPClient:NFO Connecting to 127.0.0.1:5005
+{
+   "result" : {
+      "account_data" : {
+         "Account" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
+         "Balance" : "5000000000000",
+         "Flags" : 0,
+         "LedgerEntryType" : "AccountRoot",
+         "OwnerCount" : 0,
+         "PreviousTxnID" : "00C5B713B11DA775C6F932D38CE162C16FA88B7269BAFC6FDF4C6ADB74419670",
+         "PreviousTxnLgrSeq" : 3,
+         "Sequence" : 1,
+         "index" : "13F1A95D7AAB7108D5CE7EEAF504B2894B8C674E6D68499076441C4837282BF8"
+      },
+      "ledger_current_index" : 4,
+      "status" : "success",
+      "validated" : false
+   }
+}
+```
+
+<!-- MULTICODE_BLOCK_END -->
+
+### {{n.next()}}.オフラインマシンでのシーケンス番号の入力
+
+オフラインマシンでアカウントの開始シーケンス番号を保存します。オフラインマシンを使用してトランザクションを準備するときは、必ずこの保存されたシーケンス番号を使用し、シーケンス番号を1増やして、新しい値を保存します。
+
+この方法で複数のトランザクションを前もって準備しておき、署名済みのトランザクションを一度にオンラインマシンに転送して、すべてを送信できます。各トランザクションの形式が有効で、十分な[トランザクションコスト](transaction-cost.html)を支払っていれば、XRP Ledgerネットワークは最終的にこれらのトランザクションを検証済みレジャーに含めて、共有XRP Ledgerにあるアカウントのシーケンス番号と、オフラインマシンで追跡している「現在の」シーケンス番号と同期が保たれるようにします。（ほとんどのトランザクションでは、ネットワークに送信して15秒以内に最終的な検証済みの結果が得られます。）
+
+任意で、現在のレジャーインデックスをオフラインマシンに保存します。この値を使用して、今後のトランザクションに適切な`LastLedgerSequence`値を選択できます。
+
+
+
+### {{n.next()}}.初期設定トランザクションの署名（ある場合）
+
+オフラインマシンで、アカウントの設定用のトランザクションを準備して署名します。詳細は、アカウントを使用する目的によって異なります。例えば次のようなことができます。
+
+- 定期的なローテーションで使用できる[レギュラーキーペアを割り当てる](assign-a-regular-key-pair.html)。
+- ユーザーが送金理由や送金相手をタグ付けせずに送金できないようにするために、[宛先タグを要求する](require-destination-tags.html)。
+- アカウントセキュリティを強化するために、[マルチ署名を設定する](set-up-multi-signing.html)。
+- 明示的に承認した送金、または事前に承認した相手からの送金のみを受け取れるようにするために、[DepositAuthを有効にする](depositauth.html)。
+- ユーザーがあなたの許可なくあなたへの[トラストライン](trust-lines-and-issuing.html)を開けないようにするために、[RequireAuthを有効にする](become-an-xrp-ledger-gateway.html#enabling-requireauth)。XRP Ledgerの分散型取引所や発行済み通貨機能を使用する予定がない場合は、これを対策として行うことをお勧めします。
+- 発行済み通貨[ゲートウェイ](become-an-xrp-ledger-gateway.html)には次のような追加の設定がある場合があります。
+  - 発行済み通貨を送金するユーザーに対して[TransferRateを設定する](become-an-xrp-ledger-gateway.html#transferrate)。
+  - このアドレスを発行済み通貨のみに使用する予定の場合は、[XRPペイメントを禁止する](become-an-xrp-ledger-gateway.html#disallowxrp)。
+
+この段階では、トランザクションに署名をするだけで、まだ送信しません。各トランザクションに対して、`Fee`（[トランザクションコスト](transaction-cost.html)）や`Sequence`（[シーケンス番号][]）など、通常は自動入力可能なフィールドを含めて、すべてのフィールドに入力する必要があります。一度に複数のトランザクションを準備する場合は、トランザクションの実行順にシーケンシャルに増やした`Sequence`番号を使用する必要があります。
+
+例（RequireAuthを有効にする）:
+
+<!-- MULTICODE_BLOCK_START -->
+
+_rippledコマンドライン_
+
+```sh
+$ rippled sign sn3nxiW7v8KXzPzAqzyHXbSSKNuN9 '{"Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn", "Fee": "12", "Sequence": 1, "TransactionType": "AccountSet", "SetFlag": 2}' offline
+
+Loading: "/etc/opt/ripple/rippled.cfg"
+2019-Dec-11 00:18:31.865955978 HTTPClient:NFO Connecting to 127.0.0.1:5005
+{
+   "result" : {
+      "deprecated" : "This command has been deprecated and will be removed in a future version of the server. Please migrate to a standalone signing tool.",
+      "status" : "success",
+      "tx_blob" : "1200032280000000240000000120210000000268400000000000000C7321039543A0D3004CDA0904A09FB3710251C652D69EA338589279BC849D47A7B019A174473045022100D5C92D7705036CD7EBB601C8DFCD90927FA591A62AF832C489E9C898EC8E2FA0022052F1819340EB73E9749B8930A6935727362B8E141D1B2E246B49F912223FFD4381144B4E9C06F24296074F7BC48F92A97916C6DC5EA9",
+      "tx_json" : {
+         "Account" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
+         "Fee" : "12",
+         "Flags" : 2147483648,
+         "Sequence" : 1,
+         "SetFlag" : 2,
+         "SigningPubKey" : "039543A0D3004CDA0904A09FB3710251C652D69EA338589279BC849D47A7B019A1",
+         "TransactionType" : "AccountSet",
+         "TxnSignature" : "3045022100D5C92D7705036CD7EBB601C8DFCD90927FA591A62AF832C489E9C898EC8E2FA0022052F1819340EB73E9749B8930A6935727362B8E141D1B2E246B49F912223FFD43",
+         "hash" : "F81C34E7F05423DC1C973CB5008CA41AE984DE142EAA3975A749FABF0D08FA63"
+      }
+   }
+}
+```
+
+<!-- MULTICODE_BLOCK_END -->
+
+一定の時間内に _すべて_ のトランザクションで最終結果が得られるように、[`LastLedgerSequence`](reliable-transaction-submission.html#lastledgersequence)フィールドに入力してください。この値は、現行のレジャーインデックス（オンラインマシンから検索する必要がある）と、トランザクションを有効に保つ時間に基づいたものである必要があります。オンラインマシンからオフラインマシンへ、オフラインマシンからオンラインマシンへ切り替える時間を取れるだけの十分に大きな`LastLedgerSequence`値を設定するようにしてください。例えば、現行のレジャーインデックスより256大きな値では、トランザクションは約15分間有効になります。詳細は、[結果のファイナリティー](finality-of-results.html)と[信頼できるトランザクションの送信](reliable-transaction-submission.html)を参照してください。
+
+
+### {{n.next()}}.オンラインマシンへのトランザクションのコピー
+
+トランザクションに署名したら、次のステップは署名済みのトランザクションデータをオンラインマシンに入れることです。その方法の例については、[前提条件](#前提条件)を参照してください。
+
+
+
+### {{n.next()}}.設定したトランザクションの送信
+
+次のステップはトランザクションの送信です。ほとんどのトランザクションは、送信後の次の検証済みレジャー（約4秒後）、またはキューに入っている場合はその後のレジャー（10秒未満）で最終結果が得られるはずです。トランザクションの最終結果を追跡する詳細な手順については、[信頼できるトランザクションの送信](reliable-transaction-submission.html)を参照してください。
+
+単純なトランザクションを送信する例:
+
+<!-- MULTICODE_BLOCK_START -->
+
+_rippledコマンドライン_
+
+```sh
+$ rippled submit 1200032280000000240000000120210000000268400000000000000C7321039543A0D3004CDA0904A09FB3710251C652D69EA338589279BC849D47A7B019A174473045022100D5C92D7705036CD7EBB601C8DFCD90927FA591A62AF832C489E9C898EC8E2FA0022052F1819340EB73E9749B8930A6935727362B8E141D1B2E246B49F912223FFD4381144B4E9C06F24296074F7BC48F92A97916C6DC5EA9
+
+Loading: "/etc/opt/ripple/rippled.cfg"
+2019-Dec-11 01:14:25.988839227 HTTPClient:NFO Connecting to 127.0.0.1:5005
+
+{
+   "result" : {
+      "deprecated" : "Signing support in the 'submit' command has been deprecated and will be removed in a future version of the server. Please migrate to a standalone signing tool.",
+      "engine_result" : "tesSUCCESS",
+      "engine_result_code" : 0,
+      "engine_result_message" : "The transaction was applied. Only final in a validated ledger.",
+      "status" : "success",
+      "tx_blob" : "1200032280000000240000000120210000000268400000000000000C7321039543A0D3004CDA0904A09FB3710251C652D69EA338589279BC849D47A7B019A174473045022100D5C92D7705036CD7EBB601C8DFCD90927FA591A62AF832C489E9C898EC8E2FA0022052F1819340EB73E9749B8930A6935727362B8E141D1B2E246B49F912223FFD4381144B4E9C06F24296074F7BC48F92A97916C6DC5EA9",
+      "tx_json" : {
+         "Account" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
+         "Fee" : "12",
+         "Flags" : 2147483648,
+         "Sequence" : 1,
+         "SetFlag" : 2,
+         "SigningPubKey" : "039543A0D3004CDA0904A09FB3710251C652D69EA338589279BC849D47A7B019A1",
+         "TransactionType" : "AccountSet",
+         "TxnSignature" : "3045022100D5C92D7705036CD7EBB601C8DFCD90927FA591A62AF832C489E9C898EC8E2FA0022052F1819340EB73E9749B8930A6935727362B8E141D1B2E246B49F912223FFD43",
+         "hash" : "F81C34E7F05423DC1C973CB5008CA41AE984DE142EAA3975A749FABF0D08FA63"
+      }
+   }
+}
+```
+
+<!-- MULTICODE_BLOCK_END -->
+
+**ヒント:** 一度に10件を超えるトランザクションを送信しようとしている場合、10件未満のグループに分けて送信すると成功の可能性が高まります。[トランザクションキュー](transaction-queue.html)では同じ送信者から一度に送信されるトランザクションを10件に制限しているためです。10件の1グループのトランザクションを送信した後に、すべてのトランザクションがキューから出るのを待ってから、次のグループを送信します。
+
+[最終的でない結果](finality-of-results.html)が得られて失敗したトランザクションの送信をやり直します。同じトランザクションが2回以上処理される可能性はありません。
+
+### {{n.next()}}.トランザクションの最終ステータスの確認
+
+送信した各トランザクションについて、トランザクションの[最終結果](finality-of-results.html)をメモします。例えば、[txメソッド][]を使用します。例:
+
+<!-- MULTICODE_BLOCK_START -->
+
+_rippledコマンドライン_
+
+```sh
+$ ./rippled tx F81C34E7F05423DC1C973CB5008CA41AE984DE142EAA3975A749FABF0D08FA63
+
+Loading: "/etc/opt/ripple/rippled.cfg"
+2019-Dec-11 01:38:30.124771464 HTTPClient:NFO Connecting to 127.0.0.1:5005
+{
+   "result" : {
+      "Account" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
+      "Fee" : "12",
+      "Flags" : 2147483648,
+      "Sequence" : 1,
+      "SetFlag" : 2,
+      "SigningPubKey" : "039543A0D3004CDA0904A09FB3710251C652D69EA338589279BC849D47A7B019A1",
+      "TransactionType" : "AccountSet",
+      "TxnSignature" : "3045022100D5C92D7705036CD7EBB601C8DFCD90927FA591A62AF832C489E9C898EC8E2FA0022052F1819340EB73E9749B8930A6935727362B8E141D1B2E246B49F912223FFD43",
+      "date" : 629343510,
+      "hash" : "F81C34E7F05423DC1C973CB5008CA41AE984DE142EAA3975A749FABF0D08FA63",
+      "inLedger" : 4,
+      "ledger_index" : 4,
+      "meta" : {
+         "AffectedNodes" : [
+            {
+               "ModifiedNode" : {
+                  "FinalFields" : {
+                     "Account" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
+                     "Balance" : "4999999999988",
+                     "Flags" : 262144,
+                     "OwnerCount" : 0,
+                     "Sequence" : 2
+                  },
+                  "LedgerEntryType" : "AccountRoot",
+                  "LedgerIndex" : "13F1A95D7AAB7108D5CE7EEAF504B2894B8C674E6D68499076441C4837282BF8",
+                  "PreviousFields" : {
+                     "Balance" : "5000000000000",
+                     "Flags" : 0,
+                     "Sequence" : 1
+                  },
+                  "PreviousTxnID" : "00C5B713B11DA775C6F932D38CE162C16FA88B7269BAFC6FDF4C6ADB74419670",
+                  "PreviousTxnLgrSeq" : 3
+               }
+            }
+         ],
+         "TransactionIndex" : 0,
+         "TransactionResult" : "tesSUCCESS"
+      },
+      "status" : "success",
+      "validated" : true
+   }
+}
+```
+
+<!-- MULTICODE_BLOCK_END -->
+
+すべてのトランザクションが処理された後で送信側アカウントの[account_info][account_infoメソッド]を確認すると便利です。アカウントの現在のシーケンス番号（`Sequence`フィールド）と、必要に応じてXRP残高をメモします。
+
+失敗したトランザクションについては、どうするか決める必要があります。
+
+- トランザクションが`tefMAX_LEDGER`コードで失敗した場合、トランザクションが処理されるように、より高い[トランザクションコスト](transaction-cost.html)を指定する必要があります。（これはXRP Ledgerネットワークに負荷がかかっていることを示している可能性があります。）トランザクションを、より高いコストを支払い、より高い`LastLedgerSequence`パラメーター（ある場合）を持つ新しいバージョンに置き換えるのも1つの方法です。
+- トランザクションが[`tem`クラスコードで](tem-codes.html)で失敗した場合は、トランザクションの生成時にスペルミスなどのミスをした可能性があります。トランザクションを再度確認し、有効な形式に置き換えます。
+- トランザクションが[`tec`クラスコード](tec-codes.html)で失敗した場合は、失敗した具体的な理由に応じてケースバイケースで対処する必要があります。
+
+調整や置き換えをするトランザクションについては、オフラインマシンに戻るタイミングについての詳細をメモします。
+
+
+
+### {{n.next()}}.オフラインマシンのステータスの調整
+
+オフラインマシンに戻り、カスタムサーバーに保存されている設定に必要な変更を加えます。例えば次のような変更です。
+
+- アカウントの現在の`Sequence`番号を更新する。すべてのトランザクションが検証済みレジャーに含まれている場合（成功または`tec`コードで終了）、オフラインマシンに保存されているシーケンス番号はすでに正確であるはずです。含まれていない場合は、保存されているシーケンス番号を、前のステップでメモした`Sequence`値と一致するように変更する必要があります。
+- 新しいトランザクションで適切な`LastLedgerSequence`値を使用できるように、現在のレジャーインデックスを更新する。（新しいトランザクションを生成する直前に必ずこれを行う必要があります。）
+- _（省略可）_ オフラインマシンで使用可能なXRPの金額を追跡している場合は、使用可能なXRPの実際の金額を更新する。
+
+その後で、前のステップで失敗したトランザクションの置き換えとなるトランザクションを調整して署名します。以前の手順と同様に、オフラインマシンでトランザクションを生成し、オンラインマシンから送信します。
+
+
+
+## 関連項目
+
+- **コンセプト:**
+  - [アカウント](accounts.html)
+  - [暗号鍵](cryptographic-keys.html)
+- **チュートリアル:**
+  - [安全な署名の設定](set-up-secure-signing.html)
+  - [レギュラーキーペアの割り当て](assign-a-regular-key-pair.html)
+  - [マルチ署名の設定](set-up-multi-signing.html)
+- **リファレンス:**
+  - [基本的なデータタイプ: ](basic-data-types.html#アカウントシーケンス)[ ](basic-data-types.html#アカウントシーケンス)[アカウントシーケンス](basic-data-types.html#アカウントシーケンス)
+  - [account_infoメソッド][]
+  - [signメソッド][]
+  - [submitメソッド][]
+  - [txメソッド][]
+  - [AccountSetトランザクション][]
+
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}			
+{% include '_snippets/tx-type-links.md' %}			
+{% include '_snippets/rippled_versions.md' %}
--- a/content/tutorials/manage-account-settings/require-destination-tags.ja.md
+++ b/content/tutorials/manage-account-settings/require-destination-tags.ja.md
@@ -0,0 +1,94 @@
+# 宛先タグの要求
+
+`RequireDest`設定（RippleAPIの`requireDestinationTag`）は、送金先を識別する[宛先タグ](source-and-destination-tags.html)を顧客が付け忘れている場合にあなたのアドレスに[送金](payment-types.html)できないようにするためのものです。有効にすると、XRP Ledgerは宛先タグが付いていないあなたのアドレスへの送金を拒否します。
+
+以下は、ローカルでホストされている`rippled`の[submitメソッド][]を使用して、`RequireDest`フラグを有効にする[AccountSetトランザクション][]を送信する例です。
+
+要求:
+
+<!-- MULTICODE_BLOCK_START -->
+
+*JSON-RPC*
+
+```json
+POST http://localhost:5005/
+Content-Type: application/json
+
+{
+    "method": "submit",
+    "params": [
+        {
+            "secret": "sn3nxiW7v8KXzPzAqzyHXbSSKNuN9",
+            "tx_json": {
+                "Account": "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
+                "Fee": "15000",
+                "Flags": 0,
+                "SetFlag": 1,
+                "TransactionType": "AccountSet"
+            }
+        }
+    ]
+}
+```
+
+{% include '_snippets/secret-key-warning.md' %}
+<!--{#_ #}-->
+
+<!-- MULTICODE_BLOCK_END -->
+
+応答:
+
+<!-- MULTICODE_BLOCK_START -->
+
+*JSON-RPC*
+
+```json
+200 OK
+
+{
+   "result" : {
+      "deprecated" : "Signing support in the 'submit' command has been deprecated and will be removed in a future version of the server. Please migrate to a standalone signing tool.",
+      "engine_result" : "tesSUCCESS",
+      "engine_result_code" : 0,
+      "engine_result_message" : "The transaction was applied. Only final in a validated ledger.",
+      "status" : "success",
+      "tx_blob" : "12000322000000002400000179202100000001684000000000003A98732103AB40A0490F9B7ED8DF29D246BF2D6269820A0EE7742ACDD457BEA7C7D0931EDB7446304402201C430B4C29D0A0AB94286AE55FB9981B00F84C7985AF4BD44570782C5E0C5E290220363B68B81580231B32176F8C477B822ECB9EC673B84237BEF15BE6F59108B97D81144B4E9C06F24296074F7BC48F92A97916C6DC5EA9",
+      "tx_json" : {
+         "Account" : "rf1BiGeXwwQoi8Z2ueFYTEXSwuJYfV2Jpn",
+         "Fee" : "15000",
+         "Flags" : 0,
+         "Sequence" : 377,
+         "SetFlag" : 1,
+         "SigningPubKey" : "03AB40A0490F9B7ED8DF29D246BF2D6269820A0EE7742ACDD457BEA7C7D0931EDB",
+         "TransactionType" : "AccountSet",
+         "TxnSignature" : "304402201C430B4C29D0A0AB94286AE55FB9981B00F84C7985AF4BD44570782C5E0C5E290220363B68B81580231B32176F8C477B822ECB9EC673B84237BEF15BE6F59108B97D",
+         "hash" : "3F2B233907BE9EC51AE1C822EC0B6BB0965EFD2400B218BE988DDA9529F53CA4"
+      }
+   }
+}
+```
+
+<!-- MULTICODE_BLOCK_END -->
+
+
+## 関連項目
+
+- **コンセプト:**
+  - [アカウント](accounts.html)
+  - [ソースタグと宛先タグ](source-and-destination-tags.html)
+  - [トランザクションコスト](transaction-cost.html)
+  - [支払いタイプ](payment-types.html)
+- **チュートリアル:**
+  - [XRP Ledgerのビジネス](xrp-ledger-businesses.html)
+- **リファレンス:**
+  - [account_infoメソッド][]
+  - [AccountSetトランザクション][]
+  - [AccountRootのフラグ](accountroot.html#accountrootのフラグ)
+
+
+
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}
+{% include '_snippets/tx-type-links.md' %}
+{% include '_snippets/rippled_versions.md' %}
--- a/content/tutorials/manage-account-settings/set-up-multi-signing.ja.md
+++ b/content/tutorials/manage-account-settings/set-up-multi-signing.ja.md
@@ -1,37 +1,34 @@
 # マルチ署名の設定

-マルチ署名は、XRP Ledgerのトランザクションを承認する3種類の方法の1つです。マルチ署名の他に[レギュラーキーとマスターキー](cryptographic-keys.html)で署名する方法があります。3種類のトランザクション承認方法を自由に組み合わせて使用できるようにアドレスを設定できます。
+[マルチ署名](multi-signing.html)は、XRP Ledgerの[トランザクション](transaction-basics.html)を承認する3種類の方法の1つです。マルチ署名の他に[レギュラーキーとマスターキー](cryptographic-keys.html)で署名する方法があります。3種類のトランザクション承認方法を自由に組み合わせて使用できるように[アドレス](accounts.html)を設定できます。

 このチュートリアルでは、アドレスのマルチ署名を有効にする方法を説明します。


 ## 前提条件

- 資金供給のあるXRP Ledgerアドレスが必要です。
+- トランザクションを送信するための十分なXRPが供給されていて、新しい署名者リストの[必要準備金](reserves.html)を満たしている資金供給のあるXRP Ledger[アドレス](accounts.html)が必要です。
+  
+  - [MultiSignReserve Ａmendment][]が有効な場合、マルチ署名を使用するには、使用する署名と署名者の数に関わらず、アカウントの準備金として5 XRPが必要です。（MultiSignReserve Amendmentは**2019年4月7日**以降、本番環境のXRP Ledgerで有効になっています。)
+  
+  - [MultiSignReserve Amendment][]が有効ではないテストネットワークでは、マルチ署名を使用するには[アカウント準備金](reserves.html)に通常よりも多くのXRPが必要となります。必要額は、リストの署名者の数に応じて増加します。

 - XRP Ledgerフォーマットでキーペアを生成するツールを利用できる必要があります。この処理に`rippled`サーバーを使用する場合は、[wallet_proposeメソッド][]が管理者専用であるため、管理者アクセス権限が必要です。
+  
+  - あるいは、すでにXRP Ledgerアドレスを持っている人をあなたのアドレスの署名者として承認するには、その人または組織のアカウントアドレスを知っている必要があります。

- マルチ署名は使用可能である必要があります。マルチ署名は、2016年6月27日以降、XRP Ledger Consensusプロトコルに対する[**Amendment**](amendments.html)により利用できるようになりました。
+- マルチ署名は使用可能である必要があります。（MultiSign Amendmentは**2016年6月27日**以降、本番環境のXRP Ledgerで有効になっています。)

+## 1. 構成の設計

-## 1. 資金供給のあるアドレスの準備
-
-トランザクションを送信でき、利用可能なXRPを十分に保有するXRP Ledgerアドレスが必要です。
-
-[MultiSignReserve Amendment][]が有効ではない場合、マルチ署名を使用するには[アカウント準備金](reserves.html)および[トランザクションコスト](transaction-cost.html)に通常よりも多くのXRPが必要となります。必要額は、使用する署名および署名者の数に応じて増加します。
-
-[MultiSignReserve Amendment][]が有効な場合、マルチ署名を使用するには、使用する署名と署名者の数に関わらず、アカウントの準備金として5 XRPが必要です。マルチ署名済みトランザクションの[トランザクションコスト](transaction-cost.html)は、このAmendmentの影響を受けず、使用する署名と署名者の数に応じて増加します。
-
-`rippled`を[スタンドアロンモード](rippled-server-modes.html#rippledサーバーをスタンドアロンモードで実行する理由)で新しいジェネシスレジャーで開始した場合は、以下の操作を行う必要があります:
-
-1. 新しいアドレスのキーを生成するか、またはすでに所有するキーを再利用します。
-2. ジェネシスアカウントから新しいアドレスに資金を供給するため、Paymentトランザクションを送信します。（[XRPのdrop数][]で100,000,000以上を送信してください。）
-3. 手動でレジャーを閉鎖します。
+含めたい署名者の数を決定します（最大8）。特定のトランザクションに必要な署名の数に基づいて、署名者リストの定数と署名者の重みを選択します。シンプルな「M-of-N」の署名設定では、各署名者に重み **`1`** を割り当て、リストの定数が「M」になるように設定します。これが必要な署名の数です。


 ## 2. メンバーキーの準備

-複数のXRP Ledgerキーセット（アドレスとシークレット）をSignerListのメンバーに追加する必要があります。SignerListには、レジャーに既存の資金供給のあるアドレス、または[wallet_proposeメソッド][]で生成した新しいアドレスを追加できます。例:
+署名者リストにメンバーとして加える有効な形式のXRP Ledgerアドレスが1つ以上必要です。あなた、またはあなたが選択した署名者は、これらのアドレスに関連付けられた秘密鍵を知っておく必要があります。アドレスは、レジャーに存在する資金供給されたアカウントにすることもできますが、必ずしもそうである必要はありません。
+
+[wallet_proposeメソッド][]を使用して新しいアドレスを生成できます。例:

    $ rippled wallet_propose
    Loading: "/etc/opt/ripple/rippled.cfg"
@@ -94,7 +91,7 @@
       "result" : {
          "engine_result" : "tesSUCCESS",
          "engine_result_code" : 0,
-          "engine_result_message" : "The transaction was applied.Only final in a validated ledger.",
+          "engine_result_message" : "The transaction was applied. Only final in a validated ledger.",
          "status" : "success",
          "tx_blob" : "12000C2200000000240000000120230000000368400000000000271073210303E20EC6B4A39A629815AE02C0A1393B9225E3B890CAE45B59F42FA29BE9668D74473045022100BEDFA12502C66DDCB64521972E5356F4DB965F553853D53D4C69B4897F11B4780220595202D1E080345B65BAF8EBD6CA161C227F1B62C7E72EA5CA282B9434A6F04281142DECAB42CA805119A9BA2FF305C9AFA12F0B86A1F4EB1300028114204288D2E47F8EF6C99BCC457966320D12409711E1EB13000181147908A7F0EDD48EA896C3580A399F0EE78611C8E3E1EB13000181143A4C02EA95AD6AC3BED92FA036E0BBFB712C030CE1F1",
          "tx_json" : {
@@ -136,21 +133,9 @@
 **注記:** [MultiSignReserve Amendment][]が有効ではない場合は、SignerListのメンバーの増加に応じて、アドレスの[所有者準備金](reserves.html#所有者準備金)のXRP額を増加する必要があります。アドレスに十分なXRPがないと、トランザクションは[tecINSUFFICIENT_RESERVE](tec-codes.html)で失敗します。[MultiSignReserve Amendment][]が有効な場合は、SignerListの署名者の数に関係なく[所有者準備金](reserves.html#所有者準備金)として必要なXRPは5 XRPです。関連項目: [SignerListと準備金](signerlist.html#signerlistと準備金)


-## 4. レジャーの閉鎖
+## 4. 検証の待機

-本番環境のネットワークでは、レジャーが自動的に閉鎖するまでに4～7秒かかる場合があります。
-
-スタンドアロンモードで`rippled`を実行している場合は、[ledger_acceptメソッド][]を使用してレジャーを手動で閉鎖します。
-
-    $ rippled ledger_accept
-    Loading: "/etc/opt/ripple/rippled.cfg"
-    Connecting to 127.0.0.1:5005
-    {
-       "result" : {
-          "ledger_current_index" : 6,
-          "status" : "success"
-       }
-    }
+{% include '_snippets/wait-for-validation.md' %} <!--#{ fix md highlighting_ #}-->


 ## 5. 新しい署名者リストの確認
@@ -181,14 +166,14 @@
                   },
                   {
                      "SignerEntry" : {
-                         "Account" : "raKEEVSGnKSD9Zyvxu4z6Pqpm4ABH8FS6n",
-                         "SignerWeight" : 1
+                         "Account" : "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
+                         "SignerWeight" : 2
                      }
                   },
                   {
                      "SignerEntry" : {
-                         "Account" : "rUpy3eEg8rqjqfUoLeBnZkscbKbFsKXC3v",
-                         "SignerWeight" : 1
+                         "Account" : "rsA2LpzuawewSBQXkiju3YQTMzW13pAAdW",
+                         "SignerWeight" : 2
                      }
                   }
                ],
@@ -211,7 +196,25 @@ SignerListが予期した内容で存在していれば、アドレスでマル
 これで、アドレスから[マルチ署名済みトランザクションを送信](send-a-multi-signed-transaction.html)できます。次の操作も実行できます。

 * `asfDisableMaster`フラグを使用して[AccountSetトランザクション][]を送信し、アドレスのマスターキーペアを無効化。
-* [SetRegularKeyトランザクション][]を送信してアドレスのレギュラーキーペアを削除（レギュラーキーペアをすでに設定している場合）。
+* [SetRegularKeyトランザクション][]を送信して[アドレスのレギュラーキーペアを削除](change-or-remove-a-regular-key-pair.html)（レギュラーキーペアをすでに設定している場合）。
+
+## 関連項目
+
+- **コンセプト:**
+  - [暗号鍵](cryptographic-keys.html)
+  - [マルチ署名](multi-signing.html)
+- **チュートリアル:**
+  - [rippledのインストール](install-rippled.html)
+  - [レギュラーキーペアの割り当て](assign-a-regular-key-pair.html)
+  - [信頼できるトランザクションの送信](reliable-transaction-submission.html)
+  - [パブリック署名の有効化](enable-public-signing.html)
+- **リファレンス:**
+  - [wallet_proposeメソッド][]
+  - [account_objectsメソッド][]
+  - [sign_forメソッド][]
+  - [submit_multisignedメソッド][]
+  - [SignerListSetトランザクション][]
+  - [SignerListオブジェクト](signerlist.html)

 <!--{# common link defs #}-->
 {% include '_snippets/rippled-api-links.md' %}			
--- a/content/tutorials/manage-the-rippled-server/configuration/configure-history-sharding.ja.md
+++ b/content/tutorials/manage-the-rippled-server/configuration/configure-history-sharding.ja.md
@@ -10,10 +10,10 @@

 履歴シャードを保管できるように`rippled`サーバーを設定する前に、履歴シャードストアーに割り当てるディスク容量を決定する必要があります。これはまた、デフォルトのレジャーストアーに保持する履歴の量にも影響します。シャードストアーのサイズを設定する際には、以下の点を考慮してください。

- レジャーストアー（`[node_db]`スタンザにより定義される）は、履歴シャードストアーとは別のストアーです。レジャーストアーはすべてのサーバーに必要であり、そこには一定範囲の最近の履歴が保管されている _必要があります_ 。保管する範囲は、`online_delete`パラメーターに使用可能な状態で維持するレジャーの数によって定義されます。）（デフォルトの設定では、最新のレジャー2000個が保管されます。）
-    - レジャーストアーに2^15個以上のレジャー（32768）が保持されている場合は、レジャーストアーからシャードストアーへ最近の履歴のグループを効率的にインポートできます。
- 履歴<sup></sup>シャードストアー（`[shard_db]`スタンザにより定義される）は、履歴シャードを保管する場合にのみ必要です。履歴シャードを保管しないサーバーではこの構成スタンザを省略する必要があります。履歴シャードストアーのサイズは`max_size_gb`パラメーターでギガバイト単位で定義されます。サーバーは完全なシャードを保管するため、この容量を最大限利用します。
- シャードには2^14個のレジャー（16384）が含まれており、シャードの経過期間に応じて約200 MB～4 GBを専有します。古いシャードほどXRP Ledgerでのアクティビティが少ないため、サイズが小さくなります。
+- レジャーストアー（`[node_db]`スタンザにより定義される）は、履歴シャードストアーとは別のストアーです。レジャーストアーはすべてのサーバーに必要であり、そこには一定範囲の最近の履歴が保管されている必要があります。保管する範囲は、`online_delete`パラメーターに使用可能な状態で維持するレジャーの数によって定義されます。（デフォルトの設定では、最新のレジャー2000個が保管されます。）
+  - レジャーストアーに2<sup>15</sup>個以上のレジャー（32768）が保持されている場合は、レジャーストアーからシャードストアーへ最近の履歴のグループを効率的にインポートできます。
+- 履歴シャードストアー（`[shard_db]`スタンザにより定義される）は、履歴シャードを保管する場合にのみ必要です。履歴シャードを保管しないサーバーではこの構成スタンザを省略する必要があります。履歴シャードストアーのサイズは`max_size_gb`パラメーターでギガバイト単位で定義されます。サーバーは完全なシャードを保管するため、この容量を最大限利用します。履歴シャードストアーは、 _必ず_ ソリッドステートディスクまたは同様の高速なメディアに保管します。従来の回転式ハードディスクでは不十分です。
+- シャードには2<sup>14</sup>個のレジャー（16384）が含まれており、シャードの経過期間に応じて約200MB～4GBを専有します。古いシャードほどXRP Ledgerでのアクティビティが少ないため、サイズが小さくなります。
 - 履歴シャードストアーとレジャーストアーはファイルパスを分けて保管する _必要があります_ 。必要に応じて、レジャーストアーと履歴ストアーをそれぞれ別のディスクやパーティションに配置するように設定できます。
 - 完全なレジャー履歴をレジャーストアーと履歴シャードストアーの両方に保持できますが、冗長な処理となります。
 - シャードの取得にかかる時間、`rippled`サーバーに必要なファイルハンドル数、およびメモリーキャッシュ使用率は、シャードのサイズの影響を直接受けます。
@@ -24,7 +24,7 @@

 {% include '_snippets/conf-file-location.md' %}<!--_ -->

-以下のスニペットに、`[shard_db]` スタンザの例を示します。
+以下のスニペットに、`[shard_db]`スタンザの例を示します。

 ```
 [shard_db]
@@ -33,9 +33,9 @@ path=/var/lib/rippled/db/shards/nudb
 max_size_gb=50
 ```

-**ヒント:** シャードストアーにはNuDB（`type=NuDB`）を使用することが推奨されます。NuDBはRocksDBに比べ、シャードあたりの使用ファイルハンドル数が少なくなります。RocksDBは、保管するデータのサイズに応じて拡張するメモリーを使用するため、大量のメモリーオーバーヘッドが必要になる可能性があります。ただし、NuDBはSSDドライブで使用するように設計されており、回転型ディスクでは機能しません。 <!-- NOTE: out of date; needs to be re-translated. NuDB is required as of v1.3.1. -->
+`type`フィールドは省略できます。省略しない場合は、`NuDB`である _必要があります_ 。[新規: rippled 1.3.1][]

-**注意:** 履歴シャーディングを有効にした後にシャードストアーのデータベースタイプを変更する場合は、パスを変更するか、または設定されているパスから既存のデータを削除する必要があります。`rippled`がシャードストアーパスで不適切なデータを検出すると、[起動できない](server-wont-start.html)可能性があります。
+**注意:** `rippled`がシャードストアーパスで不適切なデータを検出すると、[起動できない](server-wont-start.html)可能性があります。シャードストアーには新しいフォルダーを使用する必要があります。以前にRocksDBシャードストアー（`rippled` 1.2.x以前）を使用していた場合は、別のパスを使用するか、RocksDBシャードデータを削除します。

 詳細は、[rippled.cfgの設定例](https://github.com/ripple/rippled/blob/master/cfg/rippled-example.cfg)の`[shard_db]`の例を参照してください。

@@ -51,4 +51,26 @@ systemctl restart rippled

 このフォルダーには、サーバーに保管されている各シャードのフォルダーが番号付きで保存されています。常に、最大で1つのフォルダーに、未完了であることを示す`control.txt`ファイルが保存されています。

-<!-- TODO: add download_shard and crawl_shards commands when they get added. -->
+[download_shardメソッド][]を使用して、サーバーにアーカイブファイルからシャードをダウンロードしてインポートするように指示できます。
+
+サーバーとそのピアが使用できるシャードのリストを表示するには、[crawl_shardsメソッド][]か[ピアクローラー](peer-crawler.html)を使用します。
+
+
+## 関連項目
+
+- **コンセプト:**
+  - [レジャー履歴](ledger-history.html)
+    - [オンライン削除](online-deletion.html)
+- **チュートリアル:**
+  - [オンライン削除の設定](configure-online-deletion.html)
+  - [ピアクローラーの設定](configure-the-peer-crawler.html)
+  - [容量の計画](capacity-planning.html)
+- **リファレンス:**
+  - [download_shardメソッド][]
+  - [crawl_shardsメソッド][]
+  - [レジャーデータフォーマット](ledger-data-formats.html)
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}
+{% include '_snippets/tx-type-links.md' %}
+{% include '_snippets/rippled_versions.md' %}
--- a/content/tutorials/manage-the-rippled-server/configuration/connect-your-rippled-to-the-xrp-test-net.ja.md
+++ b/content/tutorials/manage-the-rippled-server/configuration/connect-your-rippled-to-the-xrp-test-net.ja.md
@@ -1,54 +1,112 @@
-# XRP Test Netへのrippledの接続
+# XRPL Altnetへのrippledの接続

-Rippleは、XRP Ledgerのテストプラットフォームを提供するため[XRP Test Network](https://ripple.com/build/xrp-test-net/)を開発しました。XRP Test Netの資金は実際の資金ではなく、テスト専用の資金です。本番環境のXRP Ledger Networkに接続する前に、`rippled`サーバーをXRP Test Netに接続して、`rippled`の機能をテストして理解できます。また、XRP Test Netを使用して、作成したコードが`rippled`と正しくやり取りすることを検証できます。
+Rippleは[代替となるテスト用および開発用ネットワーク](parallel-networks.html)を作成しており、開発者が最新のXRP Ledgerの非本番バージョン（Testnet）でアプリケーションをテストしたり、最新のベータバージョン（Devnet）で機能をテストして実験したりできるようにしています。 **これらのネットワークで使用する資金は実際の資金ではなく、テスト専用の資金です。** TestnetまたはDevnetの[`rippled`サーバー](the-rippled-server.html)に接続できます。

-**注記:** XRP Test Netのレジャーと残高は定期的にリセットされます。
+**注記:** XRP TestnetとDevnetのレジャーと残高は定期的にリセットされます。

-`rippled`サーバーをXRP Test Netに接続するには、以下の構成を設定します。
+`rippled`サーバーをXRP TestnetまたはDevnetに接続するには、以下の構成を設定します。

 1. `rippled.cfg`ファイルで以下の手順に従います。
-
-    a. 以下のセクションのコメントを解除します。
-
+   
+   a. [Testnet](xrp-testnet-faucet.html)に接続するには、以下のセクションのコメントを解除し、次のように追加します。
+   
        [ips]
-        r.altnet.rippletest.net 51235
-
-    b. 以下のセクションを次のようにコメントアウトします。
-
+        s.altnet.rippletest.net 51235
+   
+   b. [Devnet](xrp-testnet-faucet.html)に接続するには、以下のセクションのコメントを解除し、次のように追加します。
+   
+        [ips]
+        s.devnet.rippletest.net 51235
+   
+   c. 以下のセクションを次のようにコメントアウトします。
+   
        # [ips]
        # r.ripple.com 51235

+
+
 2. `validators.txt`ファイルで以下の手順に従います。
+   
+   2a. Altnetに接続するための変更
+   
+        a. 以下のセクションのコメントを解除し、Altnetに接続するようにします。
+       
+            [validator_list_sites]
+            https://vl.altnet.rippletest.net
+       
+            [validator_list_keys]
+            ED264807102805220DA0F312E71FC2C69E1552C9C5790F6C25E3729DEB573D5860
+       
+        b. 以下のセクションを次のようにコメントアウトします。
+       
+            # [validator_list_sites]
+            # https://vl.ripple.com
+            #
+            # [validator_list_keys]
+            # ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734
+   
+   2b. Devnetに接続するための変更
+   
+        a. 以下のセクションをコメントアウトします。
+       
+            # [validator_list_sites]
+            # https://vl.altnet.rippletest.net
+       
+            # [validator_list_keys]
+            # ED264807102805220DA0F312E71FC2C69E1552C9C5790F6C25E3729DEB573D5860        
+       
+            # [validator_list_sites]
+            # https://vl.ripple.com
+            #
+            # [validator_list_keys]
+            # ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734
+       
+        b. 次の信頼できるバリデータをvalidator.txtファイルに追加します。
+       
+            # Hard-coded List of Devnet Validators
+            [validators]
+            n9Mo4QVGnMrRN9jhAxdUFxwvyM4aeE1RvCuEGvMYt31hPspb1E2c
+            n9MEwP4LSSikUnhZJNQVQxoMCgoRrGm6GGbG46AumH2KrRrdmr6B
+            n9M1pogKUmueZ2r3E3JnZyM3g6AxkxWPr8Vr3zWtuRLqB7bHETFD
+            n9MX7LbfHvPkFYgGrJmCyLh8Reu38wsnnxA4TKhxGTZBuxRz3w1U
+            n94aw2fof4xxd8g3swN2qJCmooHdGv1ajY8Ae42T77nAQhZeYGdd
+            n9LiE1gpUGws1kFGKCM9rVFNYPVS4QziwkQn281EFXX7TViCp2RC
+            n9Jq9w1R8UrvV1u2SQqGhSXLroeWNmPNc3AVszRXhpUr1fmbLyhS

-    a. 以下のセクションのコメントを解除します。
-
-        [validator_list_sites]
-        https://vl.altnet.rippletest.net
-
-        [validator_list_keys]
-        ED264807102805220DA0F312E71FC2C69E1552C9C5790F6C25E3729DEB573D5860
-
-    b. 以下のセクションを次のようにコメントアウトします。
-
-        # [validator_list_sites]
-        # https://vl.ripple.com
-        #
-        # [validator_list_keys]
-        # ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734

 3. `rippled`を再起動します。

-4. `rippled`がXRP Test Netに接続していることを確認するため、サーバーで[server_infoメソッド][]を使用して、その結果をTest Net のパブリックサーバーの結果と比較します。両方のサーバーで`validated_ledger`オブジェクトの`seq`フィールドが同一である必要があります（確認中にこの数が変化した場合は、1～2の差が生じる可能性があります）。
-
-    以下のコマンドは、`s.altnet.rippletest.net` にあるTest Net サーバーの最新の検証済みレジャーをチェックします。
-
+4. `rippled`がXRP TestnetまたはDevnetに接続していることを確認するため、サーバーで[server_infoメソッド][]を使用して、その結果をTestnetまたはDevnetの公開サーバーの結果と比較します。両方のサーバーで`validated_ledger`オブジェクトの`seq`フィールドが同一である必要があります（確認中にこの数が変化した場合は、1～2の差が生じる可能性があります）。
+   
+   以下のコマンドは、`s.altnet.rippletest.net`にあるTestnetサーバーの最新の検証済みレジャーをチェックします。
+   
        $ ./rippled --rpc_ip 34.210.87.206:51234 server_info | grep seq
-
-    以下のコマンドは、ローカルの `rippled` の最新検証済みレジャーシーケンスをチェックします。
-
+   
+   以下のコマンドは、`s.devnet.rippletest.net`にあるDevnetサーバーの最新の検証済みレジャーをチェックします。
+   
+        $ ./rippled --rpc_ip 34.83.125.234:51234 server_info | grep seq
+   
+   以下のコマンドは、ローカルの`rippled`の最新検証済みレジャーインデックスをチェックします。
+   
        $ ./rippled server_info | grep seq


+## 関連項目
+
+- **ツール:**
+  - [XRP Faucet](xrp-testnet-faucet.html)
+  - [WebSocket APIツール](websocket-api-tool.html) - 接続オプションで「Testnet公開サーバー」を選択します。
+- **コンセプト:**
+  - [並列ネットワーク](parallel-networks.html)
+  - [コンセンサスについて](intro-to-consensus.html)
+- **チュートリアル:**
+  - [バリデータとしてのrippledの実行](run-rippled-as-a-validator.html)
+  - [スタンドアロンモードでの`rippled`のオフラインテスト](use-stand-alone-mode.html)
+  - `rippled`の[トラブルシューティング](troubleshoot-the-rippled-server.html)
+- **リファレンス:**
+  - [server_infoメソッド][]
+
+

 <!--{# common link defs #}-->
 {% include '_snippets/rippled-api-links.md' %}
--- a/content/tutorials/manage-the-rippled-server/configuration/run-rippled-as-a-validator.ja.md
+++ b/content/tutorials/manage-the-rippled-server/configuration/run-rippled-as-a-validator.ja.md
@@ -1,12 +1,12 @@
 # バリデータとしてのrippledの実行

-バリデータモードで実行されている`rippled`サーバーは、ストックサーバーが実行するあらゆる処理を実行します。
+[バリデータモード](rippled-server-modes.html)で実行されている[`rippled`サーバー](the-rippled-server.html)は、ストックサーバーが実行するあらゆる処理を実行します。

- ピアのネットワークへの接続
+- [ピアのネットワーク](consensus-network.html)への接続

- 暗号署名されたトランザクションの中継
+- 暗号署名された[トランザクション](transaction-basics.html)の中継

- 共有グローバル台帳全体のローカルコピーの維持
+- 完全な共有グローバル[レジャー](ledgers.html)のローカルコピーの維持

 バリデータが _特異である_ のは、検証メッセージも発行するという点です。これらのメッセージは、[コンセンサスプロセス](consensus-principles-and-rules.html#コンセンサスの仕組み)の進行中、XRP Ledgerネットワークによる評価の対象となる候補のトランザクションです。

@@ -21,20 +21,20 @@
 バリデータ（サーバー）が以下の特質を常に備えるよう努めます。優れたバリデータであることは、`rippled`サーバーの運用者や[https://vl.ripple.com](https://vl.ripple.com)などのバリデータリスト発行者が、バリデータを彼らのUNLに追加する際に、バリデータを信頼する上で後押しになります。

 - **可用性**
-
-    優れたバリデータは、常に稼働し、提案されるあらゆるレジャーについて検証投票を送信します。100%のアップタイムを実現するよう努めてください。
+  
+  優れたバリデータは、常に稼働し、提案されるあらゆるレジャーについて検証投票を送信します。100%のアップタイムを実現するよう努めてください。

 - **合意**
-
-    優れたバリデータの投票は、可能な限り高い頻度で、コンセンサスプロセスの結果と合致します。これに該当しない場合は、バリデータのソフトウェアが最新のものではないか、不具合があるか、意図的な偏りがあることを示唆している可能性があります。常に[最新の`rippled`リリース](https://github.com/ripple/rippled/tree/master)を、修正を加えることなく実行します。新規リリースについて知るために、[`rippled`のリリースを確認](https://github.com/ripple/rippled/releases)してください。
+  
+  優れたバリデータの投票は、可能な限り高い頻度で、コンセンサスプロセスの結果と合致します。これに該当しない場合は、バリデータのソフトウェアが最新のものではないか、不具合があるか、意図的な偏りがあることを示唆している可能性があります。常に[最新の`rippled`リリース](https://github.com/ripple/rippled/tree/master)を、修正を加えることなく実行します。新規リリースについて知るために、[`rippled`のリリースを確認](https://github.com/ripple/rippled/releases)してください。

 - **適時の投票**
-
-    優れたバリデータの投票は、コンセンサスラウンドが終了する前に、素早く届きます。適時の投票を維持するには、バリデータが推奨される[システム要件](system-requirements.html)を満たしていることを確認してください。これには、高速のインターネット接続が含まれます。
+  
+  優れたバリデータの投票は、コンセンサスラウンドが終了する前に、素早く届きます。適時の投票を維持するには、バリデータが推奨される[システム要件](system-requirements.html)を満たしていることを確認してください。これには、高速のインターネット接続が含まれます。

 - **身元の確さ**
-
-    優れたバリデータには、身元が明確な所有者が存在します。[ドメイン検証](#6-ドメイン検証の提供)を提供することは、その第一歩になります。XRP LedgerネットワークのUNLに、多くの法的な管轄域および地域のさまざまな所有者によって運営されているバリデータが含まれていると理想的です。結果として、信頼できるバリデータの公正な運用が地域特有の事象によって損なわれるおそれが低減されます。
+  
+  優れたバリデータには、身元が明確な所有者が存在します。[ドメイン検証](#6-ドメイン検証の提供)を提供することは、その第一歩になります。XRP LedgerネットワークのUNLに、多くの法的な管轄域および地域のさまざまな所有者によって運営されているバリデータが含まれていると理想的です。結果として、信頼できるバリデータの公正な運用が地域特有の事象によって損なわれるおそれが低減されます。

 Ripple社は、推奨される一連のバリデータを記載した[バリデータリスト](https://github.com/ripple/rippled/blob/develop/cfg/validators-example.txt)を公開しています。本番環境のサーバーでは、このリストを使用することを強くお勧めします。

@@ -42,7 +42,7 @@ Ripple社は、推奨される一連のバリデータを記載した[バリデ

 ## 2. `rippled`サーバーのインストール

-詳細については、[`rippled`のインストール](install-rippled.html)を参照してください。
+詳細は、[`rippled`のインストール](install-rippled.html)を参照してください。



@@ -50,42 +50,42 @@ Ripple社は、推奨される一連のバリデータを記載した[バリデ

 `rippled`サーバーで検証を有効にすることは、サーバーの`rippled.cfg`ファイルにあるバリデータトークンを提供することを意味します。バリデータキーとトークンを安全に生成して管理するために、`validator-keys`ツール（`rippled` RPMに含まれる）を使用することをお勧めします。

-バリデータ（サーバー）**以外の** 場所で、以下の手順に従います。
+バリデータ（サーバー）**以外の**場所で、以下の手順に従います。

 1. `validator-keys`ツールを`rippled` RPMを通じてまだインストールしていない場合は、手動でビルドして実行します。
-
-    `validator-keys`ツールを手動でビルドして実行する方法については、[validator-keys-tool](https://github.com/ripple/validator-keys-tool)を参照してください。
+   
+   `validator-keys`ツールを手動でビルドして実行する方法については、[validator-keys-tool](https://github.com/ripple/validator-keys-tool)を参照してください。

 2. `create_keys`コマンドを使用して、バリデータキーペアを生成します。
-
+   
        $ validator-keys create_keys
-
-      Ubuntuでの出力の例:
-
+   
+   Ubuntuでの出力の例:
+   
        Validator keys stored in /home/my-user/.ripple/validator-keys.json
-
+       
        This file should be stored securely and not shared.
-
-      macOSでの出力の例:
-
+   
+   macOSでの出力の例:
+   
        Validator keys stored in /Users/my-user/.ripple/validator-keys.json
-
+       
        This file should be stored securely and not shared.
-
-      **警告:** 生成した`validator-keys.json`キーファイルは、暗号化されたUSBフラッシュドライブなど、安全かつ回復可能なオフラインの場所に保管してください。内容には修正を加えないでください。特に、キーの使用場所となるバリデータにキーファイルを保存しないようにします。バリデータの`secret_key`が悪用された場合は、ただちに[キーを破棄](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md#key-revocation)します。
-
-      `validator-keys`ツールおよびツールで生成されるキーペアの詳細は、[Validator Keys Tool Guide](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md)を参照してください。
+   
+   **警告:** 生成した`validator-keys.json`キーファイルは、暗号化されたUSBフラッシュドライブなど、安全かつ回復可能なオフラインの場所に保管してください。内容には修正を加えないでください。特に、キーの使用場所となるバリデータにキーファイルを保存しないようにします。バリデータの`secret_key`が悪用された場合は、ただちに[キーを破棄](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md#key-revocation)します。
+   
+   `validator-keys`ツールおよびツールで生成されるキーペアの詳細は、[Validator Keys Tool Guide](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md)を参照してください。

 3. `create_token`コマンドを使用して、バリデータトークンを生成します。
-
+   
        $ validator-keys create_token --keyfile /PATH/TO/YOUR/validator-keys.json
-
-      出力の例:
-
+   
+   出力の例:
+   
        Update rippled.cfg file with these values:
-
-        # validator public key: nHUtNnLVx7odrz5dnfb2xpIgbEeJPbzJWfdicSkGyVw1eE5GpjQr
-
+       
+       # validator public key: nHUtNnLVx7odrz5dnfb2xpIgbEeJPbzJWfdicSkGyVw1eE5GpjQr
+       
        [validator_token]
        eyJ2YWxpZGF0aW9uX3NlY3J|dF9rZXkiOiI5ZWQ0NWY4NjYyNDFjYzE4YTI3NDdiNT
        QzODdjMDYyNTkwNzk3MmY0ZTcxOTAyMzFmYWE5Mzc0NTdmYT|kYWY2IiwibWFuaWZl
@@ -99,100 +99,109 @@ Ripple社は、推奨される一連のバリデータを記載した[バリデ
 バリデータ（サーバー）で、以下の手順に従います。

 1. `[validator_token]`とその値を、バリデータの`rippled.cfg`ファイルに追加します。
-
-    以前に、`validator-keys`ツールを使用せずにバリデータを設定している場合は、`[validation_seed]`とその値を`rippled.cfg`ファイルから削除します。これにより、バリデータの公開鍵が変更されます。
+   
+   以前に、`validator-keys`ツールを使用せずにバリデータを設定している場合は、`[validation_seed]`とその値を`rippled.cfg`ファイルから削除します。これにより、バリデータの公開鍵が変更されます。

 2. `rippled`を再起動します。
-
+   
        $ sudo systemctl restart rippled.service

 3. `server_info`コマンドを使用してバリデータの情報を取得し、バリデータとして実行されていることを確認します。
-
+   
        $ rippled server_info
+   
+   - 応答に含まれている`pubkey_validator`の値は、バリデータで使用するために生成した`validator-keys.json`ファイルの`public_key`と一致している必要があります。
+   
+   - `server_state`の値は、 _**proposing**_ にする必要があります。

-      - 応答に含まれている`pubkey_validator`の値は、バリデータで使用するために生成した`validator-keys.json`ファイルの`public_key`と一致している必要があります。
-
-      - `server_state`の値は、 _**proposing**_ にする必要があります。
-
-
+**セキュリティのヒント:** `rippled.cfg`ファイルに対する権限をより制限的なものに変更します。Linuxでは、`0600`にすることを推奨します。`chmod 0600 rippled.cfg`を使用して変更できます。

 ## 4. ネットワークへの接続

-バリデータのオペレーターが果たすべき重要な責任の1つは、信頼できる安全な接続によってバリデータがXRP Ledgerネットワークに接続されるようにすることです。ネットワーク上の潜在的に悪意のあるピアに無作為に接続するのではなく、以下のいずれかの方法でネットワークに接続するようにバリデータに指示できます。
+このセクションでは、バリデータをXRP Ledgerネットワークに接続するために使用できる3種類の構成について説明します。ユースケースに最適な構成を使用してください。

- - [公開ハブ](#公開ハブを使用した接続)
- - [プロキシ](#プロキシを使用した接続)
+- [検出されたピア](#検出されたピアを使用した接続): ピアツーピアネットワーク内の任意のサーバーに接続します。

-これらのいずれかの構成を使用すると、[DDoS](https://en.wikipedia.org/wiki/Denial-of-service_attack)攻撃からバリデータを保護するとともに、ネットワークへの信頼できる接続をバリデータに提供する上で役立ちます。
+- [プロキシ](#プロキシを使用した接続): ストック`rippled`サーバーを、バリデータとピアツーピアネットワークの他の部分との間のプロキシとして実行します。
+
+- [公開ハブ](#公開ハブを使用した接続): 評価の高い特定の公開サーバーにのみ接続します。
+
+これらのアプローチの違いについては、[ピア接続設定のメリットとデメリット](peer-protocol.html#ピア接続設定のメリットとデメリット)を参照してください。


-### 公開ハブを使用した接続
+### 検出されたピアを使用した接続

-この構成では、ネットワークに接続している1つ以上の公開ハブにバリデータを接続します。適切に運用されている公開ハブには、以下の特徴があります。
+この構成では、[検出されたピア](peer-protocol.html#ピアの検出)を使用してバリデータをXRP Ledgerネットワークに接続します。これは`rippled`サーバーのデフォルトの動作です。

- 十分な帯域幅。
- 多数の信頼できるピアとの接続。
- メッセージを確実に中継する能力。
-
-公開ハブに接続することの利点は、安全かつ信頼できる多くのネットワーク接続にアクセスしやすいことです。このような接続は、バリデータの健全性の維持に役立ちます。
-
-公開ハブを使用してバリデータをネットワークに接続するには、バリデータの`rippled.cfg`ファイルで以下の構成を設定します。
-
-1. 以下の`[ips_fixed]`スタンザを記述します。2つの値`r.ripple.com 51235`と`zaphod.alloy.ee 51235`が公開ハブです。このスタンザは、これらの公開ハブとのピア接続を常に維持するよう`rippled`に指示します。
-
-        [ips_fixed]
-        r.ripple.com 51235
-        zaphod.alloy.ee 51235
-
-    他の`rippled`サーバーのIPアドレスをここに記述することもできますが、それらのサーバーに対して以下の事項を期待できる場合に _**限ります**_ 。
-
-      - メッセージを検閲することなく中継する。
-      - オンライン状態を常に維持する。
-      - サーバーに対するDDoS攻撃を実行しない。
-      - サーバーをクラッシュさせようとしない。
-      - 未知の相手にバリデータのIPアドレスを公開しない。
-
-2. 以下の`[peer_private]`スタンザを記述し、`1`に設定します。この設定を有効にすると、バリデータのピアに対して、バリデータのIPアドレスをブロードキャストしないよう指示することになります。また、バリデータに対して、`[ips_fixed]`スタンザで設定されているピアにのみ接続するよう指示することになります。これにより、既知の信頼できるピア`rippled`サーバーに対してのみ、バリデータが接続を確立し、IPアドレスを共有することが保証されます。
-
-    **警告:** バリデータのIPアドレスを、その他の方法で公開していないことを確認してください。
-
-        [peer_private]
-        1
-
-    `[peer_private]`が有効になっている場合、`rippled`は、`[ips]`スタンザで指定されている接続をすべて無視します。現在`[ips]`スタンザにあるIPアドレスに接続する必要がある場合は、代わりに`[ips_fixed]`スタンザに記述します。ただし、それらのIPアドレスに対して、ステップ1で説明した挙動を期待できる場合に _**限ります**_ 。
+_**検出されたピアを使用してバリデータをXRP Ledgerネットワークに接続するには、**_ バリデータの`rippled.cfg`ファイルで`[peer_private]`スタンザを省略するか、それを`0`に設定します。この構成の[サンプルのrippled.cfgファイル](https://github.com/ripple/rippled/blob/develop/cfg/rippled-example.cfg)が提供されています。


 ### プロキシを使用した接続

-この構成では、バリデータと発着信ネットワークトラフィックの間でプロキシとして使用するストック`rippled`サーバーを実行します。
+この構成は、自社で運用するストック`rippled`サーバーを通じてバリデータをネットワークに接続します。これらのプロキシサーバーは、バリデータと発着信ネットワークトラフィックの間に設置します。

-**注記:** これらのサーバーはプロキシとして動作しますが、HTTP(S)トラフィック用のWebプロキシではありません。
+_**プロキシを使用してバリデータをXRP Ledgerネットワークに接続するには、次の手順を実行します。**_

-この設定の利点は、自社で運用するプロキシサーバーを通じて、安全かつ信頼できる多くのネットワークへの接続の冗長性やアクセス性が高まることです。このような接続は、バリデータの健全性の維持に役立ちます。
+1. ストック`rippled`サーバーを設置します。詳細は、[rippledのインストール](install-rippled.html)を参照してください。
+
+2. バリデータとストック`rippled`サーバーを設定して、[クラスター](cluster-rippled-servers.html)内で実行します。
+
+3. バリデータの`rippled.cfg`ファイルで、`[peer_private]`を`1`に設定します。そうすることで、バリデータのIPアドレスが転送されないようにします。詳細は、[プライベートピア](peer-protocol.html#プライベートピア)を参照してください。また、これによりクラスター内でバリデータを実行するよう`[ips_fixed]`スタンザで定義したサーバー以外のサーバーに、バリデータが接続しないようになります。
+   
+   **警告:** バリデータのIPアドレスを、その他の方法で公開していないことを確認してください。
+
+4. 以下のトラフィックのみを許可するように、バリデータのホストマシンのファイアウォールを構成します。
+   
+   - 着信トラフィック: 構成したクラスター内にあるストック`rippled`サーバーのIPアドレスが発信元である場合のみ
+   
+   - 発信トラフィック: 構成したクラスター内にあるストック`rippled`サーバーのIPアドレスおよびポート443経由の<https://vl.ripple.com>が送信先である場合のみ
+
+5. `rippled`を再起動します。
+   
+        $ sudo systemctl restart rippled.service
+
+6. いずれかのストック`rippled`サーバーにある[ピアクローラー](peer-crawler.html)エンドポイントを使用します。応答には、バリデータが含まれていないはずです。これにより、バリデータの`[peer_private]`構成が機能していることが確認されます。バリデータの`[peer_private]`を有効にした場合の効果の1つは、バリデータのピアによって、ピアクローラーの結果にバリデータが含まれないことです。
+   
+        $ curl --insecure https://STOCK_SERVER_IP_ADDRESS_HERE:51235/crawl | python3 -m json.tool

 <!-- { TODO: Future: add a recommended network architecture diagram to represent the proxy, clustering, and firewall setup: https://ripplelabs.atlassian.net/browse/DOC-2046 }-->

-1. `rippled`サーバーで[検証を有効に](#3-rippledサーバーで検証を有効化)します。

-2. ストック`rippled`サーバーを設置します。詳細については、[rippledのインストール](install-rippled.html)を参照してください。
+### 公開ハブを使用した接続

-3. バリデータとストック`rippled`サーバーを設定して、[クラスター](cluster-rippled-servers.html)内で実行します。
+この構成では、2つの[公開ハブ](rippled-server-modes.html#公開ハブ)を使用してバリデータをネットワークに接続します。この構成は、[自社で運用しているプロキシを使用した接続](#プロキシを使用した接続)と似ていますが、公開ハブを通じて接続します。

-4. バリデータの`rippled.cfg`ファイルで、`[peer_private]`を`1`に設定して、バリデータのIPアドレスが転送されないようにします。詳細については、[プライベートピア](peer-protocol.html#プライベートピア)を参照してください。
+_**公開ハブを使用してバリデータをネットワークに接続するには、次の手順を実行します。**_

-    **警告:** バリデータのIPアドレスを、その他の方法で公開していないことを確認してください。
+1. バリデータの`rippled.cfg`ファイルに、次の`[ips_fixed]`スタンザを含めます。2つの値`r.ripple.com 51235`と`zaphod.alloy.ee 51235`がデフォルトの公開ハブです。このスタンザは、これらの公開ハブとのピア接続を常に維持するよう`rippled`に指示します。
+   
+        [ips_fixed]
+        r.ripple.com 51235
+        zaphod.alloy.ee 51235
+   
+   **注意:** この構成では、デフォルトの公開ハブを使用してバリデータをネットワークに接続します。これらは _デフォルト_ の公開ハブであるため、ビジー状態になってバリデータにネットワークへの接続を提供できない場合があります。この問題を避けるために、接続する公開ハブの数を増やすか、デフォルトでない公開ハブに接続するようにします。
+   
+   他の`rippled`サーバーのIPアドレスをここに記述することもできますが、それらのサーバーに対して以下の事項を期待できる場合に _**限ります**_ 。
+   
+   - メッセージを検閲することなく中継する。
+   - オンライン状態を常に維持する。
+   - サーバーに対するDDoS攻撃を実行しない。
+   - サーバーをクラッシュさせようとしない。
+   - 未知の相手にバリデータのIPアドレスを公開しない。

-5. 以下のトラフィックのみを許可するように、バリデータのホストマシンのファイアウォールを構成します。
-
-    - 着信トラフィック: 構成したクラスター内にあるストック`rippled`サーバーのIPアドレスが発信元である場合のみ
-
-    - 発信トラフィック: 構成したクラスター内にあるストック`rippled`サーバーのIPアドレスおよびポート443経由の<https://vl.ripple.com>が送信先である場合のみ
-
-6. `rippled`を再起動します。
+2. また、バリデータの`rippled.cfg`ファイルに、次の`[peer_private]`スタンザを含めて、それを`1`に設定します。それにより、バリデータのピアに対して、バリデータのIPアドレスをブロードキャストしないよう指示することになります。また、バリデータに対して、`[ips_fixed]`スタンザで設定されているピアにのみ接続するよう指示することになります。これにより、既知の信頼できるピア`rippled`サーバーに対してのみ、バリデータが接続を確立し、IPアドレスを共有することが保証されます。
+   
+        [peer_private]
+        1
+   
+   **警告:** バリデータのIPアドレスを、その他の方法で公開していないことを確認してください。
+   
+   `[peer_private]`が有効になっている場合、`rippled`は、`[ips]`スタンザで指定されている接続をすべて無視します。現在`[ips]`スタンザにあるIPアドレスに接続する必要がある場合は、代わりにそれを`[ips_fixed]`スタンザに記述します。ただし、それらのIPアドレスに対して、ステップ1で説明した確実な挙動を期待できる場合に _**限ります**_ 。

+3. `rippled`を再起動します。
+   
        $ sudo systemctl restart rippled.service

-7. いずれかのストック`rippled`サーバーにある[ピアクローラー](peer-crawler.html)エンドポイントを使用します。応答には、バリデータが含まれていないはずです。これにより、バリデータの`[peer_private]`構成が機能していることが確認されます。バリデータの`[peer_private]`を有効にした場合の効果の1つは、バリデータのピアによって、ピアクローラーの結果にバリデータが含まれないことです。


 ## 5. ネットワーク接続の確認
@@ -200,14 +209,14 @@ Ripple社は、推奨される一連のバリデータを記載した[バリデ
 ここでは、バリデータがXRP Ledgerネットワークへの健全な接続を保持していることを検証する方法をいくつか紹介します。

 - [`peers`](peers.html)コマンドを使用して、バリデータに接続しているすべての`rippled`サーバーのリストを取得します。`peers`の配列が`null`である場合、ネットワークへの健全な接続が存在していません。このドキュメントの手順に従ってバリデータを設置した場合、`peers`の配列には、`[ips_fixed]`スタンザで定義されているピアの数と同数のオブジェクトが含まれています。
-
-    公開ハブを`[ips_fixed]`スタンザに記述した場合、そのハブがビジーになっているときは、バリデータの接続が拒否されることがあります。この場合、接続の数は、`[ips_fixed]`スタンザで設定した数よりも最終的に少なくなることがあります。初めて拒否された場合、バリデータは接続を再試行します。
-
-    ネットワークへの安全かつ信頼できる接続を維持することが困難であり、公開ハブまたはプロキシを使用して接続を設定していない場合、[4. ネットワークへの接続](#4-ネットワークへの接続)を参照してください。このセクションで説明されているいずれかの方法は、バリデータがネットワークへの健全な接続を維持する上で有用となる可能性があります。
+  
+  公開ハブを`[ips_fixed]`スタンザに記述した場合、そのハブがビジーになっているときは、バリデータの接続が拒否されることがあります。この場合、接続の数は、`[ips_fixed]`スタンザで設定した数よりも最終的に少なくなることがあります。初めて拒否された場合、バリデータは接続を再試行します。
+  
+  ネットワークへの安全かつ信頼できる接続を維持することが困難であり、公開ハブまたはプロキシを使用して接続を設定していない場合、[4. ネットワークへの接続](#4-ネットワークへの接続)を参照してください。このセクションで説明されているいずれかの方法は、バリデータがネットワークへの健全な接続を維持する上で有用となる可能性があります。

 - [`server_info`](server_info.html)コマンドを使用して、バリデータに関するいくつかの基本情報を取得します。`server_state`は、`proposing`に設定されているはずです。`full`または`validating`に設定されている場合もありますが、`proposing`に移行するまでの数分間に限られます。
-
-    `server_state`が`proposing`に設定されている時間が大部分を占めていない場合、XRP Ledgerネットワークにバリデータが完全に参加できていないことを示している可能性があります。サーバーの状態および`server_info`エンドポイントを使用してバリデータの問題を診断する方法の詳細は、[`rippled`サーバーの状態](rippled-server-states.html)および[`server_info`の取得](diagnosing-problems.html#server_infoの取得)を参照してください。
+  
+  `server_state`が`proposing`に設定されている時間が大部分を占めていない場合、XRP Ledgerネットワークにバリデータが完全に参加できていないことを示している可能性があります。サーバーの状態および`server_info`エンドポイントを使用してバリデータの問題を診断する方法の詳細は、[`rippled`サーバーの状態](rippled-server-states.html)および[`server_info`の取得](diagnosing-problems.html#server_infoの取得)を参照してください。

 - [`validators`](validators.html)コマンドを使用して、バリデータによって使用される、公開済みかつ信頼できるバリデータの最新リストを取得します。`validator_list_expires`の値が、`never`（無期限）、期限が切れていない、または期限切れ間近のいずれかであることを確認してください。

@@ -225,37 +234,37 @@ Ripple社は、推奨される一連のバリデータを記載した[バリデ

 ドメイン検証を提供するには、以下の手順に従います。

-1. バリデータと公に関連付ける、所有しているドメインの名前を選択します。そのドメインのポート443で外部に公開されるHTTPSサーバーを実行中であり、そのサーバーのTLS証明書に関連付けられている秘密鍵ファイルへのアクセス権を持っている必要があります。（注記: [TLSの旧称はSSLです](https://en.wikipedia.org/wiki/Transport_Layer_Security)）。
+1. バリデータと公に関連付ける、所有しているドメインの名前を選択します。そのドメインのポート443で外部に公開されるHTTPSサーバーを実行中であり、そのサーバーのTLS証明書に関連付けられている秘密鍵ファイルへのアクセス権を持っている必要があります。（注記: [TLSの旧称はSSLです](https://en.wikipedia.org/wiki/Transport_Layer_Security)。）DDoS攻撃への対策として、ドメイン名によってバリデータのIPアドレスが解決されないようにする必要があります。

 2. バリデータの公開鍵を公開し、特に他の`rippled`オペレーターに知らせます。例えば、Webサイト、ソーシャルメディア、[XRPChatコミュニティーフォーラム](https://www.xrpchat.com/)、またはプレスリリースでバリデータの公開鍵を公表できます。

 3. この[Googleフォーム](https://docs.google.com/forms/d/e/1FAIpQLScszfq7rRLAfArSZtvitCyl-VFA9cNcdnXLFjURsdCQ3gHW7w/viewform)を使用して、自身のバリデータをXRP Chartsの[バリデータレジストリー](https://xrpcharts.ripple.com/#/validators)に登録するための要求を送信します。バリデータをこのレジストリーに登録することは、そのバリデータとドメインを所有していることを示す、別の形での公的な証拠になります。フォームに漏れなく記入するには、以下の情報が必要です。
-
-      1. バリデータのサーバーで以下のコマンドを実行して、バリデータの公開鍵を検出します。
-
-            $ /opt/ripple/bin/rippled server_info | grep pubkey_validator
-
-        返された値を、Googleフォームの**Validator Public Key**フィールドに入力します。
-
-      2. WebドメインのTLS秘密鍵を使用して、バリデータの公開鍵に署名します。TLS秘密鍵ファイルをバリデータのサーバーに保存する必要はありません。
-
-            $ openssl dgst -sha256 -hex -sign /PATH/TO/YOUR/TLS.key <(echo YOUR_VALIDATOR_PUBLIC_KEY_HERE)
-
-        出力の例:
-
+   
+   1. バリデータのサーバーで以下のコマンドを実行して、バリデータの公開鍵を検出します。
+      
+      $ /opt/ripple/bin/rippled server_info | grep pubkey_validator
+   
+          返された値を、Googleフォームの**Validator Public Key**フィールドに入力します。
+   
+   2. WebドメインのTLS秘密鍵を使用して、バリデータの公開鍵に署名します。TLS秘密鍵ファイルをバリデータのサーバーに保存する必要はありません。
+      
+      $ openssl dgst -sha256 -hex -sign /PATH/TO/YOUR/TLS.key <(echo YOUR_VALIDATOR_PUBLIC_KEY_HERE)
+   
+          出力の例: 
+       
            4a8b84ac264d18d116856efd2761a76f3f4544a1fbd82b9835bcd0aa67db91c53342a1ab197ab1ec4ae763d8476dd92fb9c24e6d9de37e3594c0af05d0f14fd2a00a7a5369723c019f122956bf3fc6c6b176ed0469c70c864aa07b4bf73042b1c7cf0b2c656aaf20ece5745f54ab0f78fab50ebd599e62401f4b57a4cccdf8b76d26f4490a1c51367e4a36faf860d48dd2f98a6134ebec1a6d92fadf9f89aae67e854f33e1acdcde12cfaf5f5dbf1b6a33833e768edbb9ff374cf4ae2be21dbc73186a5b54cc518f63d6081919e6125f7daf9a1d8e96e3fdbf3b94b089438221f8cfd78fd4fc85c646b288eb6d22771a3ee47fb597d28091e7aff38a1e636b4f
-
-        返された値を、Googleフォームの**SSL Signature**フィールドに入力します。
-
-      3. [`validator-keys`ツール](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md)（`rippled`のRPMに収録）を使用して、ドメイン名に署名します。
-
-            $ validator-keys --keyfile /PATH/TO/YOUR/validator-keys.json sign YOUR_DOMAIN_NAME
-
-        出力の例:
-
+       
+          返された値を、Googleフォームの**SSL Signature**フィールドに入力します。
+   
+   3. [`validator-keys`ツール](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md)（`rippled`のRPMに収録）を使用して、ドメイン名に署名します。
+      
+      $ validator-keys --keyfile /PATH/TO/YOUR/validator-keys.json sign YOUR_DOMAIN_NAME
+   
+          出力の例: 
+       
            E852C2FE725B64F353E19DB463C40B1ABB85959A63B8D09F72C6B6C27F80B6C72ED9D5ED6DC4B8690D1F195E28FF1B00FB7119C3F9831459F3C3DE263B73AC04
-
-        返された値を、Googleフォームの**Domain Signature**フィールドに入力します。
+       
+          返された値を、Googleフォームの**Domain Signature**フィールドに入力します。

 4. 記入したGoogleフォームを送信すると、ドメイン検証の成否を通知するメールがXRP Chartsから送信されます。ドメイン検証が成功した場合は、XRP Chartsの[バリデータレジストリー](https://xrpcharts.ripple.com/#/validators)にバリデータとドメインが表示されます。

@@ -268,3 +277,27 @@ Ripple社は、推奨される一連のバリデータを記載した[バリデ
 バリデータのマスター秘密鍵が漏えいした場合は、ただちに永続的に破棄する必要があります。

 `validator-keys`ツールでバリデータ用に生成したマスターキーペアを破棄する方法については、[Key Revocation](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md#key-revocation)を参照してください。
+
+
+## 関連項目
+
+- **コンセプト:**
+  - [XRP Ledgerの概要](xrp-ledger-overview.html)
+  - [コンセンサスネットワーク](consensus-network.html)
+  - [`rippled`サーバー](the-rippled-server.html)
+- **チュートリアル:**
+  - [rippledサーバーのクラスター化](cluster-rippled-servers.html)
+  - [`rippled`のインストール](install-rippled.html)
+  - [容量の計画](capacity-planning.html)
+  - [XRP Ledgerのビジネス](xrp-ledger-businesses.html)
+- **リファレンス:**
+  - [Validator Keysツールガイド](https://github.com/ripple/validator-keys-tool/blob/master/doc/validator-keys-tool-guide.md)
+  - [consensus_infoメソッド][]
+  - [validator_list_sitesメソッド][]
+  - [validatorsメソッド][]
+
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}			
+{% include '_snippets/tx-type-links.md' %}			
+{% include '_snippets/rippled_versions.md' %}
--- a/content/tutorials/manage-the-rippled-server/configure-peering/configure-a-private-server.ja.md
+++ b/content/tutorials/manage-the-rippled-server/configure-peering/configure-a-private-server.ja.md
@@ -0,0 +1,90 @@
+# プライベートサーバーの設定
+
+[プライベートサーバー](peer-protocol.html#プライベートピア)は、オープンなピアツーピアネットワーク内の検出されたピアに直接接続するのではなく、特定の信頼できるピアのみを通じてネットワークに接続する`rippled`サーバーです。この種の構成は、[バリデータ](run-rippled-as-a-validator.html)に一般的に推奨される任意の対策ですが、その他の特定の目的でも役立ちます。
+
+## 前提条件
+
+プライベートサーバーを使用するには、次の前提条件を満たしている必要があります。
+
+- [`rippled`をインストール](install-rippled.html)して最新バージョンにアップデートし、まだ実行していない状態である必要があります。
+- 自社で運用している**プロキシ**を通じて接続するか、**公開ハブ**を通じて接続するかを決める必要があります。これらの選択肢の違いについては、[ピアリング構成のメリットとデメリット](peer-protocol.html#ピア接続設定のメリットとデメリット)を参照してください。
+  - プロキシを使用している場合、`rippled`がインストールされていてプロキシとして使用し実行される別のマシンが必要です。これらのサーバーは、外部のネットワークとプライベートサーバーに接続できる必要があります。
+  - どちらの構成でも、接続先のピアのIPアドレスとポートを把握しておく必要があります。
+
+## 手順
+
+特定のサーバーをプライベートピアとして設定するには、次の手順を実行します。
+
+1. `rippled`の構成ファイルを編集します。
+   
+        vim /etc/opt/ripple/rippled.cfg
+   
+   {% include '_snippets/conf-file-location.md' %}<!--_ -->
+
+2. プライベートピアリングを有効にします。
+   
+   構成ファイルに以下のスタンザを追加するか、コメントを解除します。
+   
+        [peer_private]
+        1
+
+3. 固定数のピアを追加します。
+   
+   構成ファイルに`[ips_fixed]`スタンザを追加するか、コメントを解除します。このスタンザの各行は、接続先のピアのホスト名またはIPアドレス、1個の空白文字、このピアがピアプロトコル接続を受け付けるポートの順に記載されている必要があります。
+   
+   例えば、**公開ハブ**を使用して接続する場合は、以下のスタンザを使用できます。
+   
+        [ips_fixed]
+        r.ripple.com 51235
+        zaphod.alloy.ee 51235
+   
+   サーバーが**プロキシ**を使用して接続している場合は、IPアドレスとポートが、プロキシとして使用している`rippled`サーバーの構成と一致している必要があります。これらの各サーバーについては、ポート番号が、サーバーの構成ファイルに記載されている`protocol = peer`ポート（通常は51235）と一致している必要があります。例えば、構成は次のようになります。
+   
+          [ips_fixed]
+          192.168.0.1 51235
+          192.168.0.2 51235
+
+4. プロキシを使用している場合、プロキシをプライベートピアと互いを含めてクラスター化します。
+   
+   公開ハブを使用している場合は、このステップをスキップします。
+   
+   プロキシを使用している場合、プライベートピアを含む[クラスターとしてプロキシを構成](cluster-rippled-servers.html)します。クラスターの各メンバーは、クラスターの_他の_各メンバーをリストにした`[ips_fixed]`スタンザを持っている必要があります。ただし、`[peer_private]`スタンザを持つのは**プライベートサーバーのみ**とします。
+   
+   各プロキシで`rippled`を再起動します。各プロキシサーバーで、次のようにします。
+   
+        sudo service systemctl restart rippled
+
+5. プライベートサーバーで`rippled`を起動します。
+   
+        sudo service systemctl start rippled
+
+6. [peersメソッド][]を使用して、プライベートサーバーが自身のピアに _のみ_ 接続していることを確認します。
+   
+   応答の`peers`配列に、構成済みのピアのいずれでもない`address`を持つオブジェクトが含まれていてはなりません。含まれている場合は、構成ファイルを再度確認して、プライベートサーバーを再起動します。
+
+
+## 次のステップ
+
+追加の予防対策として、自身のピアでないサーバーからプライベートサーバーへの着信接続をブロックするようにファイアウォールを設定する必要があります。プロキシサーバーを実行している場合は、ファイヤーウォールを通じてプロキシに[ピアポートを転送](forward-ports-for-peering.html)するようにします。ただし、プライベートピアで**ない**ものに転送します。この設定方法の具体的な手順は、使用するファイアウォールによって異なります。
+
+ファイアウォールがポート80で発信HTTP接続を**ブロックしない**ことを確認します。デフォルトの設定では、このポートを使用して**vl.ripple.com**から最新の推奨バリデータリストをダウンロードします。バリデータリストがないと、サーバーはどのバリデータを信頼してよいかわからず、ネットワークが、いつコンセンサスに至ったかを認識できません。
+
+## 関連項目
+
+- **コンセプト:**
+  - [ピアプロトコル](peer-protocol.html)
+  - [コンセンサス](consensus.html)
+  - [並列ネットワーク](parallel-networks.html)
+- **チュートリアル:**
+  - [ピアクローラーの設定](configure-the-peer-crawler.html)
+- **リファレンス:**
+  - [peersメソッド][]
+  - [connectメソッド][]
+  - [fetch_infoメソッド][]
+  - [ピアクローラー](peer-crawler.html)
+
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}			
+{% include '_snippets/tx-type-links.md' %}			
+{% include '_snippets/rippled_versions.md' %}
--- a/content/tutorials/manage-the-rippled-server/configure-peering/configure-peering.ja.md
+++ b/content/tutorials/manage-the-rippled-server/configure-peering/configure-peering.ja.md
@@ -0,0 +1,5 @@
+# ピアリングの設定
+
+XRP Ledgerのピアツーピアプロトコルは、ほとんどの場合、ピア接続を自動的に管理します。場合によっては、サーバーが接続するピアを手動で調整して、サーバーの可用性とネットワークの他の部分との接続性を最大限に高めたいというケースがあります。
+
+同じデータセンター内で複数のサーバーを稼動させている場合は、[クラスター化](cluster-rippled-servers.html)して効率を向上させたいケースがあります。ピアツーピアネットワークのトポロジー内の重要なハブなど、稼動していないが接続を維持したいサーバー用の予約済みピアスロットを使うことができます。他のピアについては、サーバーはピアを自動検出し、その接続を管理しますが、望ましくない動作をするピアをブロックするように手動で介入することもできます。
--- a/content/tutorials/manage-the-rippled-server/configure-peering/forward-ports-for-peering.ja.md
+++ b/content/tutorials/manage-the-rippled-server/configure-peering/forward-ports-for-peering.ja.md
@@ -0,0 +1,59 @@
+# ピアリングのポート転送
+
+XRP Ledgerのピアツーピアネットワーク内にあるサーバーは、[ピアプロトコル](peer-protocol.html)を介して通信します。セキュリティとネットワークの他の部分との接続を両立させるために、ファイアウォールを使用して、サーバーをほとんどのポートから保護し、ピアプロトコルポートだけを開放するか転送するようにする必要があります。
+
+`rippled`サーバーの稼動中に、[server_infoメソッド][]を実行すると、いくつのピアがあるか確認することができます。`info`オブジェクトの`peers`フィールドは、サーバーに現在接続しているピアの数を示します。この数が10または11の場合、通常はファイアウォールが着信接続をブロックしていることを示します。
+
+ファイアウォールが着信ピア接続をブロックしていると思われるためピアが10個しかないことを示している`server_info`の結果の例（一部省略）は次のとおりです。
+
+```json
+$ ./rippled server_info
+Loading: "/etc/opt/ripple/rippled.cfg"
+2019-Dec-23 22:15:09.343961928 HTTPClient:NFO Connecting to 127.0.0.1:5005
+
+{
+   "result" : {
+      "info" : {
+         ...（省略）...
+         "load_factor" : 1,
+         "peer_disconnects" : "0",
+         "peer_disconnects_resources" : "0",
+         "peers" : 10,
+         "pubkey_node" : "n9KUjqxCr5FKThSNXdzb7oqN8rYwScB2dUnNqxQxbEA17JkaWy5x",
+         "pubkey_validator" : "n9KM73uq5BM3Fc6cxG3k5TruvbLc8Ffq17JZBmWC4uP4csL4rFST",
+         "published_ledger" : "none",
+         "server_state" : "connected",
+         ...（省略）...
+      },
+      "status" : "success"
+   }
+}
+```
+
+着信接続を許可するために、ピアプロトコルポートを転送するようにファイアウォールを設定します。ピアプロトコルポートは、デフォルトの構成ファイルでは**ポート51235**で提供されます。ポートの転送の手順はファイアウォールによって異なります。例えば、Red Hat Enterprise Linuxで`firewalld`ソフトウェアファイアウォールを使用している場合は、[`firewall-cmd`ツールを使用](https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/html/security_guide/sec-port_forwarding)して、TCPトラフィックを次のように転送します。
+
+```sh
+$ sudo firewall-cmd --add-forward-port=port=51235:proto=tcp:toport=51235
+```
+
+その他のソフトウェアファイアウォールとハードウェアファイアウォールについては、メーカー公式のドキュメントを参照してください。
+
+
+## 関連項目
+
+- **コンセプト:**
+  - [ピアプロトコル](peer-protocol.html)
+  - [`rippled`サーバー](the-rippled-server.html)
+- **チュートリアル:**
+  - [容量の計画](capacity-planning.html)
+  - [`rippled`サーバーのトラブルシューティング](troubleshoot-the-rippled-server.html)
+- **リファレンス:**
+  - [connectメソッド][]
+  - [peersメソッド][]
+  - [printメソッド][]
+  - [server_infoメソッド][]
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}
+{% include '_snippets/tx-type-links.md' %}
+{% include '_snippets/rippled_versions.md' %}
--- a/content/tutorials/manage-the-rippled-server/configure-peering/manually-connect-to-a-specific-peer.ja.md
+++ b/content/tutorials/manage-the-rippled-server/configure-peering/manually-connect-to-a-specific-peer.ja.md
@@ -0,0 +1,72 @@
+# 特定のピアへの手動接続
+
+サーバーをXRP Ledgerネットワーク内の特定の[ピア](peer-protocol.html)に手動で接続するには、次の手順を実行します。
+
+**ヒント:** サーバーが起動時にこのサーバーに自動的に接続して、以降も接続を維持するようにするには、そのピアに対して[ピアリザベーション](use-a-peer-reservation.html)を設定することができます。
+
+
+## 前提条件
+
+- 接続先のピアのIPアドレスを把握しておく必要があります。
+- 接続先のピアがXRP Ledger[ピアプロトコル](peer-protocol.html)に使用するポートを把握しておく必要があります。デフォルトでは、ポート51235です。
+- サーバーからピアへのネットワーク接続を用意する必要があります。例えば、ピアサーバーは[ファイアウォールを通じて適切なポートを転送する](forward-ports-for-peering.html)必要があります。
+- ピアサーバーに使用可能なピアスロットがある必要があります。ピアがすでにピアの最大数に達している場合、ピアサーバーのオペレーターに依頼して、サーバーの[ピアリザベーション](use-a-peer-reservation.html)を追加してもらいます。
+
+## 手順
+
+接続するには、[connectメソッド][]を使用します。例:
+
+<!-- MULTICODE_BLOCK_START -->
+
+*WebSocket*
+
+```
+{
+    "command": "connect",
+    "ip": "169.54.2.151",
+    "port": 51235
+}
+```
+
+*JSON-RPC*
+
+```
+{
+    "method": "connect",
+    "params": [
+        {
+            "ip": "169.54.2.151",
+            "port": 51235
+        }
+    ]
+}
+```
+
+
+*コマンドライン*
+
+```
+rippled connect 169.54.2.151 51235
+```
+
+<!-- MULTICODE_BLOCK_END -->
+
+
+## 関連項目
+
+- **コンセプト:**
+  - [ピアプロトコル](peer-protocol.html)
+  - [`rippled`サーバー](the-rippled-server.html)
+- **チュートリアル:**
+  - [容量の計画](capacity-planning.html)
+  - [`rippled`サーバーのトラブルシューティング](troubleshoot-the-rippled-server.html)
+- **リファレンス:**
+  - [connectメソッド][]
+  - [peersメソッド][]
+  - [printメソッド][]
+  - [server_infoメソッド][]
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}
+{% include '_snippets/tx-type-links.md' %}
+{% include '_snippets/rippled_versions.md' %}
--- a/content/tutorials/manage-the-rippled-server/configure-peering/set-max-number-of-peers.ja.md
+++ b/content/tutorials/manage-the-rippled-server/configure-peering/set-max-number-of-peers.ja.md
@@ -0,0 +1,48 @@
+# ピアの最大数の設定
+
+`rippled`サーバーには、接続先の[ピア](peer-protocol.html)の数を定める設定可能なソフト最大数があります。ピアのデフォルトの最大数は**21**です。
+
+**注記:** 内部的に、サーバーは受信ピアと送信ピアのおおよそのクォータを生成します。[固定ピアやピアリザベーション](peer-protocol.html#固定ピアとピアリザベーション)を使用している場合、あるいは[connectメソッド][]を使用して追加のピアに手動で接続している場合は、このソフト最大数を超える可能性があります。
+
+サーバーが許可するピアの最大数を変更するには、以下の手順を実行します。
+
+1. `rippled`の構成ファイルを編集します。
+   
+        $ vim /etc/opt/ripple/rippled.cfg
+   
+   {% include '_snippets/conf-file-location.md' %}<!--_ -->
+
+2. 構成ファイルで、`[peers_max]`スタンザのコメントを解除して編集するか、まだない場合は追加します。
+   
+        [peers_max]
+        30
+   
+   スタンザの内容は、許可するピアの合計数を示す整数のみである必要があります。デフォルトでは、サーバーは受信ピアが約85%、送信ピアが約15%という比率を維持するように試みますが、送信ピアの最小数が10であるため、68未満の値にしても、サーバーが行う送信ピア接続の数は増えません。
+   
+   `[peers_max]`値を10未満にした場合でも、サーバーはハードコーディングされた最小数である10台の送信ピアを許可するため、ネットワークとの接続を維持できます。すべての送信ピア接続をブロックするには、[サーバーをプライベートピアとして設定](run-rippled-as-a-validator.html#プロキシを使用した接続)します。
+   
+   **注意:** 接続先のピアサーバーが増えると、`rippled`サーバーが使用するネットワーク帯域幅も増えます。`rippled`サーバーに良好なネットワーク接続があり、使用する帯域幅のコストを許容できる場合にのみ、ピアサーバーの数に大きな値を設定してください。
+
+3. `rippled`サーバーを再起動します。
+   
+        $ sudo systemctl restart rippled.service
+
+
+## 関連項目
+
+- **コンセプト:**
+  - [ピアプロトコル](peer-protocol.html)
+  - [`rippled`サーバー](the-rippled-server.html)
+- **チュートリアル:**
+  - [容量の計画](capacity-planning.html)
+  - [`rippled`サーバーのトラブルシューティング](troubleshoot-the-rippled-server.html)
+- **リファレンス:**
+  - [connectメソッド][]
+  - [peersメソッド][]
+  - [printメソッド][]
+  - [server_infoメソッド][]
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}
+{% include '_snippets/tx-type-links.md' %}
+{% include '_snippets/rippled_versions.md' %}
--- a/content/tutorials/manage-the-rippled-server/configure-peering/use-a-peer-reservation.ja.md
+++ b/content/tutorials/manage-the-rippled-server/configure-peering/use-a-peer-reservation.ja.md
@@ -0,0 +1,178 @@
+# ピアリザベーションの使用
+
+[ピアリザベーション][]を使用すると、`rippled`サーバーが予約とマッチしたピアからの通信を常に受け入れるように設定できます。このページでは、ピアリザベーションを使用して2台のサーバー間のピアツーピア通信を、各サーバーの管理者の協力のもと一貫して維持する方法について説明します。
+
+ピアリザベーションは、2台のサーバーが異なる組織によって運用されていて、着信接続を受信するサーバーが、多くのピアを持つ[ハブサーバー](rippled-server-modes.html#公開ハブ)である場合に特に便利です。分かりやすいように、これらの手順では次の用語を使用します。
+
+- **ストックサーバー**は発信接続を行うサーバーです。このサーバーは、ハブサーバー上のピアリザベーションを _使用_ します。
+- **ハブサーバー**は着信接続を受信するサーバーです。管理者は、このサーバーにピアリザベーションを _追加_ します。
+
+ただし、一方または両方のサーバーがハブ、バリデータ、ストックサーバーのいずれあっても、これらの手順を使用してピアリザベーションを設定できます。また、よりビジーな状態にあるサーバーから発信接続をする場合にもピアリザベーションを使用できますが、以下のプロセスではそのような構成については説明しません。
+
+## 前提条件
+
+これらの手順を実行するには、次の前提条件を満たしている必要があります。
+
+- 両方のサーバーの管理者が`rippled`を[インストール](install-rippled.html)して実行している。
+- 両方のサーバーの管理者が協力することに合意し、連絡が取り合える。秘密情報を共有する必要はないため、パブリックな通信チャネルを使用してもかまいません。
+- ハブサーバーが着信ピア接続を受信できる。ファイアウォールをそのように設定する手順については、[ピアリングのポート転送](forward-ports-for-peering.html)を参照してください。
+- 両方のサーバーが、同じ[XRP Ledgerネットワーク](parallel-networks.html)（本番XRP Ledger、Testnet、Devnetなど）と同期するように設定されている。
+
+## 手順
+
+ピアリザベーションを使用するには、以下の手順に従います。
+
+### 1.（ストックサーバー）永続ノードキーペアを設定する
+
+ストックサーバーの管理者が、以下の手順を実行します。
+
+永続ノードキーペア値をすでにサーバーに設定している場合は、[ステップ2: ノード公開鍵をピアの管理者に連絡する](#2-communicate-the-stock-servers-node-public-key)に進んでください。（例えば、各サーバーの永続ノードキーペアは[サーバークラスターの設定](cluster-rippled-servers.html)の一環として設定します。）
+
+**ヒント:** 永続ノードキーペアの設定は省略可能ですが、この設定をしておけば、サーバーのデータベースの消去や新規マシンへの移行が必要となった場合にピア接続の設定を容易に維持することができます。永続ノードキーペアを設定しない場合は、[server_infoメソッド][]の応答の`pubkey_node`フィールドに表示される、サーバーが自動生成したノード公開鍵を使用できます。
+
+1. [validation_createメソッド][]を使用して新しいランダムキーペアを生成します。（`secret`値を省略します。）
+   
+   例:
+   
+        rippled validation_create
+       
+        Loading: "/etc/rippled.cfg"
+        Connecting to 127.0.0.1:5005
+        {
+           "result" : {
+              "status" : "success",
+              "validation_key" : "FAWN JAVA JADE HEAL VARY HER REEL SHAW GAIL ARCH BEN IRMA",
+              "validation_public_key" : "n9Mxf6qD4J55XeLSCEpqaePW4GjoCR5U1ZeGZGJUCNe3bQa4yQbG",
+              "validation_seed" : "ssZkdwURFMBXenJPbrpE14b6noJSu"
+           }
+        }
+   
+   `validation_seed`（ノードシード値）と`validation_public_key`値（ノード公開鍵）を保存します。
+
+2. `rippled`の構成ファイルを編集します。
+   
+        vim /etc/opt/ripple/rippled.cfg
+   
+   {% include '_snippets/conf-file-location.md' %}<!--_ -->
+
+3. 前のステップで生成した`validation_seed`値を使用して、`[node_seed]`スタンザを追加します。
+   
+   例:
+   
+        [node_seed]
+        ssZkdwURFMBXenJPbrpE14b6noJSu
+   
+   **警告:** すべてのサーバーの`[node_seed]`値が一意である必要があります。構成ファイルを別のサーバーにコピーする場合は、`[node_seed]`値を削除するか、変更してください。`[node_seed]`は公開しないようにします。不正使用者がこの値にアクセスできた場合、それを使用してサーバーを偽装し、XRP Ledgerのピアツーピア通信を行う可能性があります。
+
+4. `rippled`サーバーを再起動します。
+   
+        systemctl restart rippled
+
+### 2.ストックサーバーのノード公開鍵を連絡する
+
+ストックサーバーの管理者が、ハブサーバーの管理者にストックサーバーのノード公開鍵を伝えます。（ステップ1の`validation_public_key`を使用します。）ハブサーバーの管理者はこの値を以降のステップで使用する必要があります。
+
+### 3.（ハブサーバー）ピアリザベーションを追加する
+
+ハブサーバーの管理者が、以下の手順を実行します。
+
+[peer_reservations_addメソッド][]を使用し、前のステップで入手したノード公開鍵を使用して予約を追加します。例:
+
+```sh
+$ rippled peer_reservations_add n9Mxf6qD4J55XeLSCEpqaePW4GjoCR5U1ZeGZGJUCNe3bQa4yQbG "Description here"
+
+Loading: "/etc/opt/ripple/rippled.cfg"
+Connecting to 127.0.0.1:5005
+
+{
+  "result": {
+    "status": "success"
+  }
+}
+```
+
+**ヒント:** 説明はオプションのフィールドです。この予約は誰のためにしたものかを人間が読み取れる形式のメモを追加できます。
+
+### 4.ハブサーバーの現在のIPアドレスとピアポートを連絡する
+
+ハブサーバーの管理者は、サーバーの現在のIPアドレスとピアポートをストックサーバーの管理者に伝える必要があります。ハブサーバーが、ネットワークアドレス変換（NAT）を行なうファイアウォールの内側にある場合は、サーバーの _外部_ IPアドレスを使用します。デフォルトの構成ファイルは、ピアプロトコルにポート51235を使用します。
+
+### 5.（ストックサーバー）ピアサーバーに接続する
+
+ストックサーバーの管理者が、以下の手順を実行します。
+
+[connectメソッド][]を使用して、サーバーをハブサーバーに接続します。例:
+
+<!-- MULTICODE_BLOCK_START -->
+
+*WebSocket*
+
+```
+{
+    "command": "connect",
+    "ip": "169.54.2.151",
+    "port": 51235
+}
+```
+
+*JSON-RPC*
+
+```
+{
+    "method": "connect",
+    "params": [
+        {
+            "ip": "169.54.2.151",
+            "port": 51235
+            
+        }
+    ]
+}
+```
+
+*コマンドライン*
+
+```
+rippled connect 169.54.2.151 51235
+```
+
+<!-- MULTICODE_BLOCK_END -->
+
+ハブサーバーの管理者が上記の手順に従ってピアリザベーションを設定した場合、自動的に接続され、可能な限り接続が維持されます。
+
+
+## 次のステップ
+
+サーバーの管理者は、サーバーに設定された他のピアへの予約を管理できます。（他のサーバーからの予約は確認できません。）次のことを実行できます。
+
+- [peer_reservations_addメソッド][]を使用して、ピアリザベーションの追加や説明の更新を行う。
+- [peer_reservations_listメソッド][]を使用して、予約先のサーバーを確認する。
+- [peer_reservations_delメソッド][]を使用して、予約を削除する。
+- [peersメソッド][]を使用して、現在接続しているピアと使用している帯域幅の量を確認する。
+
+**ヒント:** 不正なピアからの接続を即座に切断するAPIメソッドはありませんが、`firewalld`などのソフトウェアファイアウォールを使用すれば、不正なピアからのサーバーへの接続をブロックできます。例については、コミュニティーによって作成された[rbhスクリプト](https://github.com/gnanderson/rbh)を参照してください。
+
+
+## 関連項目
+
+- **コンセプト:**
+  - [ピアプロトコル](peer-protocol.html)
+  - [コンセンサス](consensus.html)
+  - [並列ネットワーク](parallel-networks.html)
+- **チュートリアル:**
+  - [容量の計画](capacity-planning.html)
+  - [`rippled`のトラブルシューティング](troubleshoot-the-rippled-server.html)
+- **リファレンス:**
+  - [peersメソッド][]
+  - [peer_reservations_addメソッド][]
+  - [peer_reservations_delメソッド][]
+  - [peer_reservations_listメソッド][]
+  - [connectメソッド][]
+  - [fetch_infoメソッド][]
+  - [ピアクローラー](peer-crawler.html)
+
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}
+{% include '_snippets/tx-type-links.md' %}
+{% include '_snippets/rippled_versions.md' %}
--- a/content/tutorials/manage-the-rippled-server/installation/build-run-rippled-macos.ja.md
+++ b/content/tutorials/manage-the-rippled-server/installation/build-run-rippled-macos.ja.md
@@ -1,113 +1,117 @@
 # macOSでのrippledの構築と実行

-現時点において、Rippleでは`rippled`の本番環境にmacOSの使用を推奨していません。本番環境には、最高レベルの品質管理とテストを経た、[Ubuntuプラットフォーム](install-rippled-on-ubuntu-with-alien.html)のご使用をご検討ください。
+[`rippled`](the-rippled-server.html)の本番環境にmacOSプラットフォームを使用することは推奨されていません。本番環境には、最高レベルの品質管理とテストを経た、[Ubuntuプラットフォーム](install-rippled-on-ubuntu-with-alien.html)のご使用をご検討ください。

-しかしながら、macOSは多くの開発やテストの作業に適しています。 `rippled` は、10.13 High SierraまでのmacOSでテスト済みです。
+しかしながら、macOSは多くの開発やテストの作業に適しています。`rippled`は、10.13 High SierraまでのmacOSでテスト済みです。

-開発目的の場合は、`sudo`を使用するのではなく、自身のユーザーとして`rippled`を実行することをお勧めします。
+開発目的の場合は、`sudo`を使用するのではなく、非管理者ユーザーとして`rippled`を実行します。

 1. [Xcode](https://developer.apple.com/download/)をインストールします。

 0. Xcodeコマンドラインツールをインストールします。
-
+   
        $ xcode-select --install

 0. [Homebrew](https://brew.sh/)をインストールします。
-
+   
        $ ruby -e "$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)"

 0. Homebrewをアップデートします。
-
+   
        $ brew update

 0. Homebrewを使用して依存関係をインストールします。
-
+   
        $ brew install git cmake pkg-config protobuf openssl ninja

-0. Boost 1.71.0をインストールします。 `rippled` 1.4.0はBoost 1.70以上と互換性を持ちます。
+0. Boost 1.70.0以降をインストールします。`rippled`1.4.0はBoost 1.70.0以降と互換性があります。HomebrewのリポジトリにあるBoostの最新バージョンでは不十分であるため、Boostを手動でインストールする必要があります。（次の例では、本書執筆時点の最新バージョンであるBoost 1.71.0を使用しています。）
+   
+   1. [Boost 1.71.0](https://dl.bintray.com/boostorg/release/1.71.0/source/boost_1_71_0.tar.bz2)をダウンロードします。
+   
+   2. フォルダに抽出します。場所をメモしておいてください。
+   
+   3. ターミナルで以下を実行します。
+      
+      cd /LOCATION/OF/YOUR/BOOST/DIRECTORY 
+      ./bootstrap.sh 
+      ./b2 cxxflags="-std=c++14"

-      1. [Boost 1.71.0](https://dl.bintray.com/boostorg/release/1.71.0/source/boost_1_71_0.tar.bz2)をダウンロードします。
-
-      2. フォルダに抽出します。場所をメモしておいてください。
-
-      3. ターミナルで以下を実行します。
-
-            cd /LOCATION/OF/YOUR/BOOST/DIRECTORY
-            ./bootstrap.sh
-            ./b2 cxxflags="-std=c++14"
-
-0. `BOOST_ROOT`環境変数が、Boostのインストールで作成されたディレクトリーを指すようにします。Boostのインストールディレクトリーを見つけるには、`brew info boost`を使用します。この環境変数を`.bash_profile`ファイルに追加すると、ログイン時に自動的に設定されます。例えば、次のようにします。
-
-        export BOOST_ROOT=/Users/my_user/boost_1_71_0
-
-0. 前のステップで`.bash_profile`ファイルをアップデートした場合には、それを読み込みます。例:
+0. `BOOST_ROOT`環境が、Boostのインストールで作成されたディレクトリーを指すようにします。
+   
+   1. Boostディレクトリーを確認するには、Boostを手動でインストールした場合は`pwd`、Homebrewを使用してインストールした場合は`brew --prefix boost`を使用します。
+   
+   2. 以下のコードをBoostディレクトリーの場所に編集して実行し、Boost環境変数が`.bash_profile`ファイルに追加されるようにします。そうすることで、ログイン時にこの環境変数が自動的に設定されます。
+      
+      $ echo $"export BOOST_ROOT=/Users/my_user/boost_1_71_0" >> ~/.bash_profile

+0. 前のステップで`.bash_profile`ファイルをアップデートした場合には、新しいターミナルウィンドウでそれを読み込みます。例:
+   
        $ source .bash_profile

 0. 希望の場所に`rippled`ソースコードをクローンし、`rippled`ディレクトリーにアクセスします。これを行うには、Git（Homebrewを使用して前にインストール済み）とGitHubを設定する必要があります。例えば、GitHubアカウントを作成し、SSHキーを設定します。詳細は、[Set up git](https://help.github.com/articles/set-up-git/)を参照してください。
-
+   
        $ git clone git@github.com:ripple/rippled.git
        $ cd rippled

 0. デフォルトでは、クローンを実行すると`develop`ブランチに移動します。開発作業をしていて、未テストの機能の最新セットを使用したい場合にはこのブランチを使用します。
-
-      最新の安定したリリースを使用したい場合には、`master`ブランチをチェックアウトします。
-
-        $ git checkout master
-
-      最新のリリース候補をテストしたい場合には、`release`ブランチをチェックアウトします。
-
-        $ git checkout release
-
-      または、[GitHub](https://github.com/ripple/rippled/releases)にリストされたタグ付きのリリースをチェックアウトすることもできます。
+    
+    最新の安定したリリースを使用したい場合には、`master`ブランチをチェックアウトします。
+    
+         $ git checkout master
+    
+    最新のリリース候補をテストしたい場合には、`release`ブランチをチェックアウトします。
+    
+         $ git checkout release
+    
+    または、[GitHub](https://github.com/ripple/rippled/releases)にリストされたタグ付きのリリースをチェックアウトすることもできます。

 0. クローンしたばかりの`rippled`ディレクトリー内にビルドディレクトリーを作成し、そこにアクセスします。例:
-
-        $ mkdir my_build
-        $ cd my_build
+    
+         $ mkdir my_build
+         $ cd my_build

 0. `rippled`を構築します。ハードウェアの仕様にもよりますが、これには約5分ほどかかります。
-
-        $ cmake -G "Unix Makefiles" -DCMAKE_BUILD_TYPE=Debug ..
-
-      `CMAKE_BUILD_TYPE`を`Debug`または`Release`ビルドタイプに設定できます。標準的な4つの[`CMAKE_BUILD_TYPE`](https://cmake.org/cmake/help/v3.0/variable/CMAKE_BUILD_TYPE.html)の値がすべてサポートされています。
+    
+         $ cmake -G "Unix Makefiles" -DCMAKE_BUILD_TYPE=Debug ..
+    
+    `CMAKE_BUILD_TYPE`を`Debug`または`Release`ビルドタイプに設定できます。標準的な4つの[`CMAKE_BUILD_TYPE`](https://cmake.org/cmake/help/v3.0/variable/CMAKE_BUILD_TYPE.html)の値がすべてサポートされています。

 0. CMakeを使用してビルドを実行します。ハードウェアの仕様にもよりますが、これには約10分ほどかかります。
-
-        $ cmake --build .-- -j 4
-
-      **ヒント:** この例では、`-j`パラメーターが`4`に設定されています。これにより、4つのプロセスを使用し、並行してビルドします。使用する最適なプロセス数は、お使いのハードウェアで使用可能なCPUコア数によって異なります。`sysctl -n hw.ncpu`を使用して、CPUのコア数を調べてください。
+    
+         $ cmake --build .-- -j 4
+    
+    **ヒント:** この例では、`-j`パラメーターが`4`に設定されています。これにより、4つのプロセスを使用し、並行してビルドします。使用する最適なプロセス数は、お使いのハードウェアで使用可能なCPUコア数によって異なります。`sysctl -n hw.ncpu`を使用して、CPUのコア数を調べてください。

 0. サーバー実行可能ファイルに組み込まれたユニットテストを実行します。ハードウェアの仕様にもよりますが、これには約5分ほどかかります。（省略可能ですが、推奨します）
+    
+         $ ./rippled --unittest

-        $ ./rippled --unittest
-
-0. `rippled` は、`rippled.cfg`構成ファイルの実行を必要とします。`rippled/cfg`に、サンプル構成ファイルの`rippled-example.cfg`があります。このファイルをコピーし、`rippled`を非ルートユーザーとして実行できる場所に`rippled.cfg`という名前で保存します。`rippled`ディレクトリーにアクセスして、以下を実行します。
-
-        $ mkdir -p $HOME/.config/ripple
-        $ cp cfg/rippled-example.cfg $HOME/.config/ripple/rippled.cfg
+0. `rippled`は、`rippled.cfg`構成ファイルの実行を必要とします。`rippled/cfg`に、サンプル構成ファイルの`rippled-example.cfg`があります。このファイルをコピーし、`rippled`を非ルートユーザーとして実行できる場所に`rippled.cfg`という名前で保存します。`rippled`ディレクトリーにアクセスして、以下を実行します。
+    
+         $ mkdir -p $HOME/.config/ripple
+         $ cp cfg/rippled-example.cfg $HOME/.config/ripple/rippled.cfg

 0. `rippled.cfg`を編集し、必要なファイルパスを設定します。`rippled`を実行するユーザーは、ここで指定するすべてのパスへの書き込み権限を持っている必要があります。
+    
+    * `[node_db]`パスを、台帳データベースを保存する場所に設定します。
+    
+    * `[database_path]`パスを、その他のデータベースデータを保存する場所に設定します。（この場所には、構成データを持つSQLiteデータベースも含まれ、通常、`[node_db]`パスフィールドの1つ上のレベルになります。）
+    
+    * `[debug_logfile]`を`rippled`がログ情報を書き込めるパスに設定します。
+    
+    `rippled`を正常に起動するために必要な構成はこれだけです。その他の構成はすべて省略可能であり、作業サーバーをセットアップしてから調整することもできます。詳細は、[Additional Configurations](#その他の構成)を参照してください。

-      * `[node_db]`パスを、台帳データベースを保存する場所に設定します。
-
-      * `[database_path]`パスを、その他のデータベースデータを保存する場所に設定します。（この場所には、構成データを持つSQLiteデータベースも含まれ、通常、`[node_db]`パスフィールドの1つ上のレベルになります。）
-
-      * `[debug_logfile]`を`rippled`がログ情報を書き込めるパスに設定します。
-
-      `rippled`を正常に起動するために必要な構成はこれだけです。その他の構成はすべて省略可能であり、作業サーバーをセットアップしてから調整することもできます。詳細については、[追加構成](#additional-configuration)を参照してください。
-
-0. `rippled` は、`validators.txt`ファイルの実行を必要とします。`rippled/cfg/`に、サンプルバリデータファイルの`validators-example.txt`があります。このファイルをコピーし、`rippled.cfg`ファイルと同じフォルダーに`validators.txt`という名前で保存します。`rippled`ディレクトリーにアクセスして、以下を実行します。
-
-        $ cp cfg/validators-example.txt $HOME/.config/ripple/validators.txt
-
-      **警告:** Rippleは、安全を第一に考えて分散プランをデザインしました。特にRippleから勧められない限り、移行中に`validators.txt`ファイルを変更しないでください。小さな変更であっても、バリデータの設定に変更を加えると、サーバーがネットワークから分岐し、古い、不完全、または正しくないデータについて報告する原因となることがあります。そのようなデータを使用すると、経費の無駄になります。
+0. `rippled`は、`validators.txt`ファイルの実行を必要とします。`rippled/cfg/`に、サンプルバリデータファイルの`validators-example.txt`があります。このファイルをコピーし、`rippled.cfg`ファイルと同じフォルダーに`validators.txt`という名前で保存します。`rippled`ディレクトリーにアクセスして、以下を実行します。
+    
+         $ cp cfg/validators-example.txt $HOME/.config/ripple/validators.txt
+    
+    **警告:** Rippleは、安全を第一に考えて分散プランをデザインしました。特にRippleから勧められない限り、移行中に`validators.txt`ファイルを変更しないでください。小さな変更であっても、バリデータの設定に変更を加えると、サーバーがネットワークから分岐し、古い、不完全、または正しくないデータについて報告する原因となることがあります。そのようなデータを使用すると、経費の無駄になります。

 0. ビルドディレクトリー（`my_build`など）にアクセスし、`rippled`サービスを開始します。
-
-        $ ./rippled
-
-      以下は、ターミナルに表示される内容の抜粋です。
+    
+         $ ./rippled
+    
+    以下は、ターミナルに表示される内容の抜粋です。

 ```
      2018-Oct-26 18:21:39.593738 JobQueue:NFO Auto-tuning to 6 validation/transaction/proposal threads.
@@ -157,7 +161,7 @@
      2018-Oct-26 18:23:03.034750 InboundLedger:WRN Want: 8DFAD21AD3090DE5D6F7592B3821C3DA77A72287705B4CF98DC0F84D5DD2BDF8
 ```

-`rippled`ログメッセージの詳細については、[ログメッセージについて](understanding-log-messages.html)を参照してください。
+`rippled`ログメッセージの詳細は、[ログメッセージについて](understanding-log-messages.html)を参照してください。

 ## 次のステップ

@@ -165,6 +169,21 @@

 ## 関連項目

- [Ubuntu Linuxでrippledをインストール](install-rippled-on-ubuntu-with-alien.html)（本番環境用の、Ubuntu上の事前構築済みバイナリー）
- [Ubuntuでの`rippled`の構築と実行](build-run-rippled-ubuntu.html)（Ubuntuで`rippled`を自分でコンパイル）
- [その他のプラットフォーム用のコンパイル手順](https://github.com/ripple/rippled/tree/develop/Builds)
+- **コンセプト:**
+    - [`rippled`サーバー](the-rippled-server.html)
+    - [コンセンサスについて](intro-to-consensus.html)
+- **チュートリアル:**
+    - [Ubuntu Linuxでrippledをインストール](install-rippled-on-ubuntu.html)（本番環境用の、Ubuntu上の事前構築済みバイナリーをインストール）
+    - [rippledの構成](configure-rippled.html)
+    - [rippledのトラブルシューティング](troubleshoot-the-rippled-server.html)
+    - [rippled APIの使用開始](get-started-with-the-rippled-api.html)
+- **リファレンス:**
+    - [rippled APIリファレンス](rippled-api.html)
+      - [`rippled`コマンドラインの使用](commandline-usage.html)
+      - [server_infoメソッド][]
+
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}
+{% include '_snippets/tx-type-links.md' %}
+{% include '_snippets/rippled_versions.md' %}
--- a/content/tutorials/manage-the-rippled-server/installation/build-run-rippled-ubuntu.ja.md
+++ b/content/tutorials/manage-the-rippled-server/installation/build-run-rippled-ubuntu.ja.md
@@ -1,6 +1,6 @@
 # Ubuntuでのrippledの構築と実行

-`rippled` は、XRP Ledgerを管理するコアのピアツーピアサーバーです。`rippled`サーバーは、ピアのネットワークに接続し、暗号で署名された取引を中継し、共有のグローバル台帳の完全なローカルコピーを維持します。
+`rippled`は、XRP Ledgerを管理するコアのピアツーピアサーバーです。`rippled`サーバーは、ピアのネットワークに接続し、暗号で署名された取引を中継し、共有のグローバル台帳の完全なローカルコピーを維持します。

 `rippled`の概要については、[Operating rippled Servers](install-rippled.html)を参照してください。

@@ -18,102 +18,105 @@
 次の手順では、UbuntuのAPT（Advanced Packaging Tool）を使用し、`rippled`の構築と実行に必要なソフトウェアをインストールします。

 1. `apt-get`でインストールまたはアップグレードできるパッケージのリストを更新します。
-
+   
        sudo apt-get update

 2. 現在インストールされているパッケージをアップグレードします。
-
+   
        sudo apt-get -y upgrade

 3. 依存関係をインストールします。
-
+   
        sudo apt-get -y install git pkg-config protobuf-compiler libprotobuf-dev libssl-dev wget

 4. CMakeをインストールします。
-
-    `rippled`のバージョン1.4.0は、CMake 3.9.0以降を必要とします。このチュートリアルでは、執筆時の最新バージョンだったCMake 3.13.3を使用しました。
-
-    CMake 3.9.0以降をすでにインストールしてある場合には、このステップはスキップできます。
-
-    CMake 3.13.3をインストールするには、以下を実行します。
-
+   
+   `rippled`のバージョン1.4.0は、CMake 3.9.0以降を必要とします。このチュートリアルでは、執筆時の最新バージョンだったCMake 3.13.3を使用しました。
+   
+   CMake 3.9.0以降をすでにインストールしてある場合には、このステップはスキップできます。
+   
+   CMake 3.13.3をインストールするには、以下を実行します。
+   
        wget https://github.com/Kitware/CMake/releases/download/v3.13.3/cmake-3.13.3-Linux-x86_64.sh
        sudo sh cmake-3.13.3-Linux-x86_64.sh --prefix=/usr/local --exclude-subdir
-
-    `cmake --version`を使用し、正常にインストールされたことを確認します。
+   
+   `cmake --version`を使用し、正常にインストールされたことを確認します。

 5. Boostをコンパイルします。
-
-    `rippled` 1.4.0はBoost 1.70以上と互換性を持ちます。Ubuntu（18.04も16.04も）のソフトウェアリポジトリに、Boostバージョン1.70.0がないため、自分でコンパイルする必要があります。
-
-    以前に`rippled`用にBoost 1.71.0をインストールしていて、`BOOST_ROOT`環境変数を構成した場合には、このステップはスキップできます。
-
-      1. Boost 1.71.0をダウンロードします。
-
-              wget https://dl.bintray.com/boostorg/release/1.71.0/source/boost_1_71_0.tar.gz
-
-      2. `boost_1_71_0.tar.gz`を抽出します。
-
-              tar xvzf boost_1_71_0.tar.gz
-
-      3. 新しい`boost_1_71_0`ディレクトリーに移動します。
-
-              cd boost_1_71_0
-
-      4. 使用するBoost.Buildシステムを準備します。
-
-              ./bootstrap.sh
-
-      5. 個別にコンパイルされたBoostライブラリを構築します。ハードウェアの仕様にもよりますが、これには約10分かかります。
-
-              ./b2 -j 4
-
-          **ヒント:** この例では、4つのプロセスを並行して構築します。使用する最適なプロセス数は、お使いのハードウェアで使用可能なCPUコア数によって異なります。`cat /proc/cpuinfo`を使用して、ハードウェアプロセッサーに関する情報を取得できます。
-
-      6. `BOOST_ROOT`環境変数を、新しい`boost_1_71_0`ディレクトリーを参照するように設定します。ログイン時に自動的に設定されるようにするため、この環境変数を、シェル用の`.profile`またはそれに相当するファイルに入れることをお勧めします。ファイルに次の行を追加します。
-
-              export BOOST_ROOT=/home/my_user/boost_1_71_0
-
-      7. 更新した`.profile`ファイルを読み込みます。例:
-
-              source ~/.profile
+   
+   `rippled`のバージョン1.4.0は、Boostバージョン1.70.0以降を必要とします。Ubuntu 18.04（または16.04）ソフトウェアリポジトリにBoostバージョン1.70.0以降がないため、自分でコンパイルする必要があります。（次の例では、執筆時点の最新バージョンであるBoost 1.71.0を使用しています。）
+   
+   以前に`rippled`用にBoost 1.71.0をインストールしていて、`BOOST_ROOT`環境変数を構成した場合には、このステップはスキップできます。
+   
+   1. Boost 1.71.0をダウンロードします。
+      
+           wget https://dl.bintray.com/boostorg/release/1.71.0/source/boost_1_71_0.tar.gz
+   
+   2. `boost_1_71_0.tar.gz`を抽出します。
+      
+           tar xvzf boost_1_71_0.tar.gz
+   
+   3. 新しい`boost_1_71_0`ディレクトリーに移動します。
+      
+           cd boost_1_71_0
+   
+   4. 使用するBoost.Buildシステムを準備します。
+      
+           ./bootstrap.sh
+   
+   5. 個別にコンパイルされたBoostライブラリを構築します。ハードウェアの仕様にもよりますが、これには約10分かかります。
+      
+           ./b2 -j 4
+      
+      **ヒント:** この例では、4つのプロセスを並行して構築します。使用する最適なプロセス数は、お使いのハードウェアで使用可能なCPUコア数によって異なります。`cat /proc/cpuinfo`を使用して、ハードウェアプロセッサーに関する情報を取得できます。
+   
+   6. `BOOST_ROOT`環境変数を、新しい`boost_1_71_0`ディレクトリーを参照するように設定します。ログイン時に自動的に設定されるようにするため、この環境変数を、シェル用の`.profile`またはそれに相当するファイルに入れることをお勧めします。ファイルに次の行を追加します。
+      
+           export BOOST_ROOT=/home/my_user/boost_1_71_0
+   
+   7. 更新した`.profile`ファイルを読み込みます。例:
+      
+           source ~/.profile

 6. 作業ディレクトリーから、`rippled`ソースコードを取得します。`master`ブランチに最新のリリースバージョンがあります。
-
+   
        git clone https://github.com/ripple/rippled.git
        cd rippled
        git checkout master

 7. コミットログを調べ、正しいバージョンをコンパイルしていることを確認します。最新のコミットは、よく知られるRipple開発者によって署名され、バージョン番号が最新のリリースバージョンに設定されています。例:
-
+   
        $ git log -1
+       
+        commit 06c371544acc3b488b9d9c057cee4e51f6bef7a2
+        Author: Nik Bougalis <nikb@bougalis.net>
+        Date:   Mon Nov 25 22:58:03 2019 -0800
+       
+            Set version to 1.4.0
+

-        commit e1adbd7ddd5dfa9f2a9791aa3c0fcc1fdb4e8236
-        Author: Manoj doshi <mdoshi@ripple.com>
-        Date:   Wed Jul 24 15:21:56 2019 -0700

-            Set version to 1.3.1

 8. 以前に`rippled`を構築したことがある場合、または（そしてもっと重要なのは）構築しようとして失敗したことがある場合には、クリーンな状態から開始するために、次のステップに移る前に`my_build/`ディレクトリー（またはユーザーが付けた名前）を削除する必要があります。このディレクトリーを削除しないと、セグメンテーションエラー（segfault）が原因で`rippled`実行可能ファイルがクラッシュするなど、予期しない動作が発生することがあります。
-
-    `rippled`1.0.0以上を構築するのが初めての場合には、`my_build/`ディレクトリーはないため、次のステップに進むことができます。
+   
+   `rippled` 1.0.0以上を構築するのが初めての場合には、`my_build/`ディレクトリーはないため、次のステップに進むことができます。

 9. CMakeを使用して、ソースコードから`rippled`バイナリー実行可能ファイルを構築します。その結果、`my_build`ディレクトリーに`rippled`バイナリー実行可能ファイルが構築されます。
-
-      1. ビルドシステムを生成します。ビルドは、ソースツリールートとは別のディレクトリーで実行します。この例では、`rippled`のサブディレクトリーである`my_build`ディレクトリーを使用します。
-
-              mkdir my_build
-              cd my_build
-              cmake ..
-
-          **ヒント:** デフォルトのビルドには、本番環境では有用ではないものの、開発環境に便利なデバッグ記号が含まれています。`rippled`を本番環境用サーバーで使用するには、`cmake`コマンドの実行時に`-DCMAKE_BUILD_TYPE=Release`フラグを追加します。
-
-      2. `rippled`のバイナリー実行可能ファイルを構築します。ハードウェアの仕様にもよりますが、これには約30分かかります。
-
-              cmake --build .
+   
+   1. ビルドシステムを生成します。ビルドは、ソースツリールートとは別のディレクトリーで実行します。この例では、`rippled`のサブディレクトリーである`my_build`ディレクトリーを使用します。
+      
+           mkdir my_build
+           cd my_build
+           cmake ..
+      
+      **ヒント:** デフォルトのビルドには、本番環境では有用ではないものの、開発環境に便利なデバッグ記号が含まれています。`rippled`を本番環境用サーバーで使用するには、`cmake`コマンドの実行時に`-DCMAKE_BUILD_TYPE=Release`フラグを追加します。
+   
+   2. `rippled`のバイナリー実行可能ファイルを構築します。ハードウェアの仕様にもよりますが、これには約30分かかります。
+      
+           cmake --build .

 10. _（省略可能）_`rippled`ユニットテストを実行します。テストエラーがない場合には、`rippled`実行可能ファイルがほぼ確実に正しくコンパイルされています。
-
+    
        ./rippled -u


@@ -122,23 +125,23 @@
 `rippled`を正常に起動させるために必要な以下の構成を行います。その他の構成はすべて省略可能であり、作業サーバーをセットアップしてから調整することもできます。

 1. `rippled`フォルダーに移動して、サンプル構成ファイルのコピーを作成します。構成ファイルをこの場所に保存すると、`rippled`を非ルートユーザーとして実行できます（推奨）。
-
+   
        mkdir -p ~/.config/ripple
        cp cfg/rippled-example.cfg ~/.config/ripple/rippled.cfg

 2. 構成ファイルを編集し、必要なファイルパスを設定します。`rippled`を実行するユーザーは、ここで指定するすべてのパスへの書き込み権限を持っている必要があります。
-
-      1. `[node_db]`のパスを、台帳データベースを保存する場所に設定します。
-
-      2. `[database_path]`を、その他のデータベースデータを保存する場所に設定します。（この場所には、構成データを持つSQLiteデータベースも含まれ、通常、`[node_db]`パスフィールドの1つ上のレベルになります。）
-
-      3. `[debug_logfile]`を`rippled`がロギング情報を書き込めるパスに設定します。
+   
+   1. `[node_db]`のパスを、台帳データベースを保存する場所に設定します。
+   
+   2. `[database_path]`を、その他のデータベースデータを保存する場所に設定します。（この場所には、構成データを持つSQLiteデータベースも含まれ、通常、`[node_db]`パスフィールドの1つ上のレベルになります。）
+   
+   3. `[debug_logfile]`を`rippled`がログ情報を書き込めるパスに設定します。

 3. サンプルの`validators.txt`ファイルを`rippled.cfg`と同じフォルダーに保存します。
-
+   
        cp cfg/validators-example.txt ~/.config/ripple/validators.txt
-
-    **警告:** Rippleは、安全を第一に考えて[分散プラン](https://ripple.com/dev-blog/decentralization-strategy-update/)をデザインしました。特にRippleから勧められない限り、移行中に`validators.txt`ファイルを変更*しない*でください。小さな変更であっても、バリデータの設定に変更を加えると、サーバーがネットワークから分岐し、古い、不完全、または正しくないデータについて報告する原因となることがあります。そのようなデータを使用すると、経費の無駄になります。
+   
+   **警告:** Rippleは、安全を第一に考えて[分散プラン](https://xrpl.org/blog/2017/decent-strategy-update.html)をデザインしました。特にRippleから勧められない限り、移行中に`validators.txt`ファイルを変更*しない*でください。小さな変更であっても、バリデータの設定に変更を加えると、サーバーがネットワークから分岐し、古い、不完全、または正しくないデータについて報告する原因となることがあります。そのようなデータを使用すると、経費の無駄になります。


 ## 3. `rippled`の実行
@@ -193,10 +196,10 @@ Watchdog: Launching child 1
 2018-Jun-06 00:52:33.379747629 LedgerConsensus:WRN {"accepted":true,"account_hash":"CC1F1EC08E76BC9FE843BBF9C6068C5B73192E6957B9CC1174DCB2B94DD2025A","close_flags":0,"close_time":581561550,"close_time_human":"2018-Jun-06 00:52:30.000000000","close_time_resolution":30,"closed":true,"hash":"94354A7FECAB638C29BBC79B18CFDBDC05E4FF72647AD62F072DB4D23A5E0317","ledger_hash":"94354A7FECAB638C29BBC79B18CFDBDC05E4FF72647AD62F072DB4D23A5E0317","ledger_index":"3","parent_close_time":581561490,"parent_hash":"80BF92A69F65F5C543E962DF4B41715546FDD97FC6988028E5ACBB46654756CA","seqNum":"3","totalCoins":"100000000000000000","total_coins":"100000000000000000","transaction_hash":"0000000000000000000000000000000000000000000000000000000000000000"}
 ...
 2018-Jun-06 00:53:50.568965045 LedgerConsensus:WRN {"accepted":true,"account_hash":"A79E6754544F9C8FC74870C95A39CED1D45CC1206DDA4C113E51F9DB6DDB0E76","close_flags":0,"close_time":581561630,"close_time_human":"2018-Jun-06 00:53:50.000000000","close_time_resolution":10,"closed":true,"hash":"6294118F39F5F2B8349E7CC6D4D5931011622E78DD4E34D91372651E9F453E2F","ledger_hash":"6294118F39F5F2B8349E7CC6D4D5931011622E78DD4E34D91372651E9F453E2F","ledger_index":"29","parent_close_time":581561623,"parent_hash":"5F57870CE5160D6B53271955F26E3BE63696D1127B91BC7943F9A199B313CB85","seqNum":"29","totalCoins":"100000000000000000","total_coins":"100000000000000000","transaction_hash":"0000000000000000000000000000000000000000000000000000000000000000"}
-2018-Jun-06 0:53:50.569776678 LedgerConsensus:WRN Need consensus ledger 6A0DE66550B6BA9636E3F8FDB71C2E924D182A1835E4143B2170DAA1D33CAE8D
-2018-Jun-06 0:53:51.576778862 NetworkOPs:WRN We are not running on the consensus ledger
+2018-Jun-06 00:53:50.569776678 LedgerConsensus:WRN Need consensus ledger 6A0DE66550B6BA9636E3F8FDB71C2E924D182A1835E4143B2170DAA1D33CAE8D
+2018-Jun-06 00:53:51.576778862 NetworkOPs:WRN We are not running on the consensus ledger
 2018-Jun-06 00:53:53.576524564 LedgerConsensus:WRN View of consensus changed during establish status=establish,  mode=wrongLedger
-2018-Jun-06 0:53:53.576783663 LedgerConsensus:WRN 6A0DE66550B6BA9636E3F8FDB71C2E924D182A1835E4143B2170DAA1D33CAE8D to 1CB9C9A1C27403CBAB9DFCFA61E1F915059DFE4FA93524537B885CC190DB5C6B
+2018-Jun-06 00:53:53.576783663 LedgerConsensus:WRN 6A0DE66550B6BA9636E3F8FDB71C2E924D182A1835E4143B2170DAA1D33CAE8D to 1CB9C9A1C27403CBAB9DFCFA61E1F915059DFE4FA93524537B885CC190DB5C6B
 2018-Jun-06 00:53:53.577079124 LedgerConsensus:WRN {"accepted":true,"account_hash":"5CAB3E4F5F2AC1A764106D7CC0729E6E7D1F7F93C65B7D8CB04C8DE2FC2C1305","close_flags":0,"close_time":581561631,"close_time_human":"2018-Jun-06 00:53:51.000000000","close_time_resolution":10,"closed":true,"hash":"201E147BD195CE3C56B0C0B8DF58386FC7BFF450E1E5B286A29AB856926D5F79","ledger_hash":"201E147BD195CE3C56B0C0B8DF58386FC7BFF450E1E5B286A29AB856926D5F79","ledger_index":"30","parent_close_time":581561630,"parent_hash":"6294118F39F5F2B8349E7CC6D4D5931011622E78DD4E34D91372651E9F453E2F","seqNum":"30","totalCoins":"100000000000000000","total_coins":"100000000000000000","transaction_hash":"0000000000000000000000000000000000000000000000000000000000000000"}
 ```

@@ -205,8 +208,32 @@ Watchdog: Launching child 1

 * これでストック`rippled`サーバーを実行できたので、次に検証サーバーとして実行してみましょう。検証サーバーの詳細について、そして検証サーバーを実行する理由については、[rippledのセットアップチュートリアル](install-rippled.html)を参照してください。

-* `rippled` APIを使用して`rippled`サーバーと通信する方法については、[`rippled` API reference](rippled-api.html)を参照してください。
+* `rippled` APIを使用して`rippled`サーバーと通信する方法については、[`rippled` APIリファレンス](rippled-api.html)を参照してください。

-* 開発のベストプラクティスとして、`rippled` `.deb`ファイルを構築することをお勧めします。詳細は、_Ubuntu Packaging Guide_ の[Packaging New Software](http://packaging.ubuntu.com/html/packaging-new-software.html)を参照してください。
+* 開発のベストプラクティスとして、`rippled` `.deb`パッケージをビルドすることをお勧めします。CMakeビルドのdebパッケージターゲットを使用して、ソースツリーから直接`deb`パッケージをビルドできます。ビルドマシンには[Dockerをインストール](https://docs.docker.com/install/#supported-platforms)している必要があります。このプロセスを完了するのに1時間以上かかる場合があります。`deb`パッケージをビルドするには、以下の手順に従います。
+  
+        mkdir -p build/pkg && cd build/pkg
+        cmake -Dpackages_only=ON ../..
+        cmake --build . --target dpkg

-* また、`systemd`をインストールすることもできます。詳細については、[systemd for Upstart Users](https://wiki.ubuntu.com/SystemdForUpstartUsers)を参照してください。[公式の`rippled`システムユニットファイル](https://github.com/ripple/rippled-package-builder/blob/staging/rpm-builder/rippled.service)をそのまま使用するか、ニーズに合わせてファイルを編集して使用できます。
+* また、`systemd`をインストールすることもできます。詳細は、[systemd for Upstart Users](https://wiki.ubuntu.com/SystemdForUpstartUsers)を参照してください。[公式の`rippled`システムユニットファイル](https://github.com/ripple/rippled/blob/master/Builds/containers/shared/rippled.service)をそのまま使用するか、ニーズに合わせてファイルを編集して使用できます。
+
+## 関連項目
+
+- **コンセプト:**
+    - [`rippled`サーバー](the-rippled-server.html)
+    - [コンセンサスについて](intro-to-consensus.html)
+- **チュートリアル:**
+    - [rippledの構成](configure-rippled.html)
+    - [rippledのトラブルシューティング](troubleshoot-the-rippled-server.html)
+    - [rippled APIの使用開始](get-started-with-the-rippled-api.html)
+- **リファレンス:**
+    - [rippled APIリファレンス](rippled-api.html)
+      - [`rippled`コマンドラインの使用](commandline-usage.html)
+      - [server_infoメソッド][]
+
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}
+{% include '_snippets/tx-type-links.md' %}
+{% include '_snippets/rippled_versions.md' %}
--- a/content/tutorials/manage-the-rippled-server/installation/install-rippled-on-centos-rhel-with-yum.ja.md
+++ b/content/tutorials/manage-the-rippled-server/installation/install-rippled-on-centos-rhel-with-yum.ja.md
@@ -13,19 +13,37 @@
 ## インストール手順

 1. Ripple RPMリポジトリをインストールします。
+   
+        $ cat << REPOFILE | sudo tee /etc/yum.repos.d/ripple.repo
+        [ripple-stable]
+        name=XRP Ledger Packages
+        baseurl=https://repos.ripple.com/repos/rippled-rpm/stable/
+        enabled=1
+        gpgcheck=0
+        gpgkey=https://repos.ripple.com/repos/rippled-rpm/stable/repodata/repomd.xml.key
+        repo_gpgcheck=1
+        REPOFILE

-        $ sudo rpm -Uvh https://mirrors.ripple.com/ripple-repo-el7.rpm
+2. 最新のrepoのアップデートを取得します。
+   
+        $ sudo yum -y update

-2. `rippled`ソフトウェアパッケージをインストールします。
+3. 新しい`rippled`パッケージをインストールします。
+   
+        $ sudo yum install rippled
+   
+   バージョン1.3.1では、構成ファイル（`rippled.cfg`および`validators.txt`）を変更する必要はありません。このアップデート手順では、既存の構成ファイルが現在のまま残ります。

-        $ sudo yum install --enablerepo=ripple-stable rippled
-
-3. システム起動時に開始するように、`rippled`サービスを設定します。
+4. systemdユニットファイルを再度読み込みます。
+   
+        $ sudo systemctl daemon-reload

+5. 起動時に開始するように、`rippled`サービスを設定します。
+   
        $ sudo systemctl enable rippled.service

-4. `rippled`サービスを開始します。
-
+6. `rippled`サービスを開始します。
+   
        $ sudo systemctl start rippled.service


@@ -33,9 +51,23 @@

 {% include '_snippets/post-rippled-install.md' %}<!--_ -->

+
 ## 関連項目

- [CentOS/Red Hatでの自動更新](update-rippled-automatically-on-centos-rhel.html)
- [Ubuntu Linuxでrippledをインストール](install-rippled-on-ubuntu-with-alien.html)（Ubuntu上の事前構築済みバイナリー）
- [Ubuntuでの'rippled'の構築と実行](build-run-rippled-ubuntu.html)（Ubuntuで`rippled`を自分でコンパイル）
- [その他のプラットフォーム用のコンパイル手順](https://github.com/ripple/rippled/tree/develop/Builds)
+- **コンセプト:**
+    - [`rippled`サーバー](the-rippled-server.html)
+    - [コンセンサスについて](intro-to-consensus.html)
+- **チュートリアル:**
+    - [rippledの構成](configure-rippled.html)
+    - [rippledのトラブルシューティング](troubleshoot-the-rippled-server.html)
+    - [rippled APIの使用開始](get-started-with-the-rippled-api.html)
+- **リファレンス:**
+    - [rippled APIリファレンス](rippled-api.html)
+      - [`rippled`コマンドラインの使用](commandline-usage.html)
+      - [server_infoメソッド][]
+
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}
+{% include '_snippets/tx-type-links.md' %}
+{% include '_snippets/rippled_versions.md' %}
--- a/content/tutorials/manage-the-rippled-server/installation/install-rippled-on-ubuntu.ja.md
+++ b/content/tutorials/manage-the-rippled-server/installation/install-rippled-on-ubuntu.ja.md
@@ -0,0 +1,104 @@
+# UbuntuまたはDebian Linuxへのインストール
+
+このページでは、[`apt`](https://help.ubuntu.com/lts/serverguide/apt.html)ユーティリティを使用して、**Ubuntu Linux 16.04以降**または**Debian 9（Stretch）** に`rippled`の安定した最新バージョンをインストールする場合の推奨手順を説明します。
+
+以下の手順では、Rippleによってコンパイルされたバイナリーをインストールします。
+
+
+## 前提条件
+
+`rippled`をインストールする前に、[システム要件](system-requirements.html)を満たす必要があります。
+
+
+## インストール手順
+
+1. リポジトリを更新します。
+   
+        $ sudo apt -y update
+
+2. ユーティリティをインストールします。
+   
+        $ sudo apt -y install apt-transport-https ca-certificates wget gnupg
+
+3. Rippleのパッケージ署名用のGPGキーを、信頼できるキーのリストに追加します。
+   
+        $ wget -q -O - "https://repos.ripple.com/repos/api/gpg/key/public" | \
+          sudo apt-key add -
+
+4. 追加したキーのフィンガープリントを確認します。
+   
+        $ apt-key finger
+   
+   出力に、次のようなRipple用のエントリーが含まれています。
+   
+        pub   rsa3072 2019-02-14 [SC] [expires: 2021-02-13]
+              C001 0EC2 05B3 5A33 10DC 90DE 395F 97FF CCAF D9A2
+        uid           [ unknown] TechOps Team at Ripple <techops+rippled@ripple.com>
+        sub   rsa3072 2019-02-14 [E] [expires: 2021-02-13]
+   
+   特に、フィンガープリントが一致することを確認してください。（上記の例では、フィンガープリントは2行目の`C001`で始まる部分です。）
+
+5. 使用しているオペレーティングシステムのバージョンに対応する適切なRippleリポジトリを追加します。
+   
+        $ echo "deb https://repos.ripple.com/repos/rippled-deb bionic stable" | \
+            sudo tee -a /etc/apt/sources.list.d/ripple.list
+   
+   上記の例は、**Ubuntu 18.04 Bionic Beaver**に適切です。その他のオペレーティングシステムについては、`bionic`という単語を次のいずれかに置き換えます。
+   
+   - **Ubuntu 16.04 Xenial Xerus**の場合は`xenial`
+   - **Debian 9 Stretch**の場合は`stretch`
+   
+   `rippled`の開発バージョンまたはプレリリースバージョンにアクセスするには、`stable`ではなく次のいずれかを使用します。
+   
+   - `unstable` - プレインストールビルド（[`release`ブランチ](https://github.com/ripple/rippled/tree/release)）
+   - `nightly` - 実験/開発ビルド（[`develop`ブランチ](https://github.com/ripple/rippled/tree/develop)）
+   
+   **警告:** 安定版ではないナイトリービルドはいつの時点でも壊れる可能性があります。これらのビルドを本番環境のサーバーに使用しないでください。
+
+6. Rippleリポジトリを取得します。
+   
+        $ sudo apt -y update
+
+7. `rippled`ソフトウェアパッケージをインストールします。
+   
+        $ sudo apt -y install rippled
+
+8. `rippled`サービスのステータスをチェックします。
+   
+        $ systemctl status rippled.service
+   
+   `rippled`サービスが自動的に開始します。開始しない場合は、手動で開始できます。
+   
+        $ sudo systemctl start rippled.service
+   
+   起動時に自動で起動するようにするには、以下の手順に従います。
+   
+        $ sudo systemctl enable rippled.service
+
+
+
+## 次のステップ
+
+{% include '_snippets/post-rippled-install.md' %}
+<!--_ -->
+
+
+## 関連項目
+
+- **コンセプト:**
+    - [`rippled`サーバー](the-rippled-server.html)
+    - [コンセンサスについて](intro-to-consensus.html)
+- **チュートリアル:**
+    - [rippledの構成](configure-rippled.html)
+    - [rippledのトラブルシューティング](troubleshoot-the-rippled-server.html)
+    - [rippled APIの使用開始](get-started-with-the-rippled-api.html)
+- **リファレンス:**
+    - [rippled APIリファレンス](rippled-api.html)
+      - [`rippled`コマンドラインの使用](commandline-usage.html)
+      - [server_infoメソッド][]
+
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}
+{% include '_snippets/tx-type-links.md' %}
+{% include '_snippets/rippled_versions.md' %}
--- a/content/tutorials/manage-the-rippled-server/installation/rippled-1-3-migration-instructions.ja.md
+++ b/content/tutorials/manage-the-rippled-server/installation/rippled-1-3-migration-instructions.ja.md
@@ -0,0 +1,106 @@
+# rippled v1.3.xへの移行手順
+
+このドキュメントでは、`rippled` 1.2.4以前のバージョンから`rippled` v1.3以降に移行するプロセスについて説明します。`rippled`のインストールプロセスがバージョン1.3では変更されたため、この移行プロセスは必須です。
+
+このドキュメントでは、サポートされるプラットフォームでアップグレードするための移行手順について説明します。
+
+- [CentOSまたはRed Hat Enterprise Linux（RHEL）](#centosまたはred-hat-enterprise-linuxrhelでの移行)
+- [Ubuntu Linux](#ubuntu-linuxでの移行)
+
+その他のプラットフォームについては、ソースからコンパイルするためのアップデート手順を参照してください。（[Ubuntu](build-run-rippled-ubuntu.html)、[macOS](build-run-rippled-macos.html)、または[Windows](https://github.com/ripple/rippled/tree/develop/Builds/VisualStudio2017)）
+
+
+## CentOSまたはRed Hat Enterprise Linux（RHEL）での移行
+
+Rippleの公式RPMリポジトリとそれを使用するための手順が変更されました。[自動更新](update-rippled-automatically-on-linux.html)を有効にしている場合は、システムで移行が自動的に実行されます。以前のリポジトリから新しいリポジトリに手動で移行するには、以下の手順を実行します。
+
+1. `rippled`サーバーを停止します。
+   
+        $ sudo systemctl stop rippled.service
+
+2. 以前のRippleリポジトリパッケージを削除します。
+   
+        $ sudo rpm -e ripple-repo
+   
+   `rippled-repo`パッケージは、現在**廃止予定**です。このパッケージはバージョン1.3.1に対応するために、最後にもう一度だけ更新されました。今後は、リポジトリに変更があれば、`ripple.repo`ファイルに手動で変更を加える必要があります。
+
+3. Rippleの新しいyumリポジトリを追加します。
+   
+        $ cat << REPOFILE | sudo tee /etc/yum.repos.d/ripple.repo
+        [ripple-stable]
+        name=XRP Ledger Packages
+        baseurl=https://repos.ripple.com/repos/rippled-rpm/stable/
+        enabled=1
+        gpgcheck=0
+        gpgkey=https://repos.ripple.com/repos/rippled-rpm/stable/repodata/repomd.xml.key
+        repo_gpgcheck=1
+        REPOFILE
+
+4. 新しい`rippled`パッケージをインストールします。
+   
+        $ sudo yum install rippled
+   
+   バージョン1.3.1では、構成ファイル（`rippled.cfg`および`validators.txt`）を変更する必要はありません。このアップデート手順では、既存の構成ファイルが現在のまま残ります。
+
+5. systemdユニットファイルを再度読み込みます。
+   
+        $ sudo systemctl daemon-reload
+
+6. `rippled`サービスを開始します。
+   
+        $ sudo systemctl start rippled.service
+
+
+**警告:** [自動更新](update-rippled-automatically-on-linux.html)を使用している場合、この移行プロセスを実行した後も自動更新が続きます。ただし、**`ripple-repo`パッケージは、現在は廃止予定**です。そのため、今後は、Rippleのリポジトリへの変更があれば、各自がrepoファイルを手動で更新する必要があります。
+
+
+## Ubuntu Linuxでの移行
+
+バージョン1.3より前では、Ubuntu Linuxに`rippled`をインストールする方法として、Alienを使用してRPMパッケージをインストールする方法がサポートされていました。`rippled`v1.3.1から、RippleはUbuntuおよびDebian Linux向けのネイティブパッケージを提供しており、これが推奨のインストール方法となります。すでにRPMパッケージをインストールしている場合は、[インストール手順](install-rippled-on-ubuntu.html)を実行して、パッケージをアップグレードし、ネイティブAPT（`.deb`）パッケージに切り替えます。
+
+構成ファイル（`/opt/ripple/etc/rippled.cfg`および`/opt/ripple/etc/validators.txt`）に変更を加えている場合は、インストール中に`apt`から、構成ファイルをパッケージからの最新バージョンで上書きするかどうかを尋ねられる場合があります。バージョン1.3では、構成ファイルに変更を加える必要はありません。そのため、既存の構成ファイルはそのまま維持できます。
+
+1.3用のネイティブAPTパッケージをインストールした後で、サービスを再読み込み/再起動する必要があります。
+
+1. systemdユニットファイルを再度読み込みます。
+   
+        $ sudo systemctl daemon-reload
+
+2. `rippled`サービスを再起動します。
+   
+        $ sudo systemctl restart rippled.service
+
+他のパッケージ用にAlienを使用する必要がなくなった場合は、必要に応じて、次の手順でAlienとその依存関係をアンインストールできます。
+
+1. Alienをアンインストールします。
+   
+        $ sudo apt -y remove alien
+
+2. 使用していない依存関係をアンインストールします。
+   
+        $ sudo apt -y autoremove
+
+### 自動更新
+
+`rippled` v1.3パッケージには、UbuntuおよびDebian Linuxで動作する最新のauto-updateスクリプトが含まれています。詳細は、[Linuxでの`rippled`の自動更新](update-rippled-automatically-on-linux.html)を参照してください。
+
+## 関連項目
+
+- **[`rippled` v1.3.1リリースノート](https://github.com/ripple/rippled/releases/1.3.1)**
+- **コンセプト:**
+  - [`rippled`サーバー](the-rippled-server.html)
+  - [コンセンサスについて](intro-to-consensus.html)
+- **チュートリアル:**
+  - [Linuxでの自動更新](update-rippled-automatically-on-linux.html)
+  - [rippledのトラブルシューティング](troubleshoot-the-rippled-server.html)
+  - [rippled APIの使用開始](get-started-with-the-rippled-api.html)
+- **リファレンス:**
+    - [rippled APIリファレンス](rippled-api.html)
+      - [`rippled`コマンドラインの使用](commandline-usage.html)
+      - [server_infoメソッド][]
+
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}
+{% include '_snippets/tx-type-links.md' %}
+{% include '_snippets/rippled_versions.md' %}
--- a/content/tutorials/manage-the-rippled-server/installation/system-requirements.ja.md
+++ b/content/tutorials/manage-the-rippled-server/installation/system-requirements.ja.md
@@ -5,14 +5,15 @@
 ネットワークに参加するための費用を抑えるため、`rippled`サーバーは一般製品のハードウェア上で快適に実行できる必要があります。Rippleでは、現時点で以下の最小要件を推奨します。

 - オペレーティングシステム:
-    - 本番環境: CentOSまたはRedHat Enterprise Linux（最新リリース）、またはUbuntu （16.04以降）をサポート
+    - 本番環境: CentOSまたはRedHat Enterprise Linux（最新リリース）、Ubuntu（16.04以降）、Debian（9.x）をサポート
    - 開発環境: Mac OS X、Windows（64ビット）、またはほとんどのLinuxディストリビューション
- CPU: 64ビットx86_64、2つ以上のコア
+- CPU: 64ビット x86_64、2つ以上のコア
 - ディスク: データベースパーティション用に最低50GB。SSDを強く推奨（最低でも1000IOPS、それよりも多いことが望ましい）
 - RAM: 8GB以上

 作業負荷によっては、Amazon EC2の`m3.large` VMサイズが適切な場合があります。高速のネットワーク接続が望ましいです。サーバーのクライアント処理負荷が増加すると、必要なリソースも増加します。

+
 ## 推奨される仕様

 企業の本番環境で最良のパフォーマンスを実現するため、Rippleでは、以下の仕様のベアメタルで`rippled`を実行することを推奨しています。
@@ -21,10 +22,31 @@
 - CPU: Intel Xeon 3以上、GHzプロセッサー、4コア、ハイパースレッディング有効
 - ディスク: SSD（7000回以上の書き込み/秒、10,000回以上の読み取り/秒）
 - RAM:
-  	- テスト用: 8GB以上
-  	- 本番環境用: 32GB
+  - テスト用: 8GB以上
+  - 本番環境用: 32GB
 - ネットワーク: ホスト上にギガビットネットワークインターフェイスを備える企業データセンターネットワーク

+## システム時刻
+
+`rippled`サーバーは、正確な時刻が維持されていることを前提としています。`ntpd`や`chrony`などのデーモンで、ネットワークタイムプロトコル（NTP）を使用してシステムの時刻を同期することを推奨します。
+
+
 ## 関連項目

-実稼働向けの推奨仕様および計画について詳しくは、[容量の計画](capacity-planning.html)を参照してください。
+- **コンセプト:**
+    - [`rippled`サーバー](the-rippled-server.html)
+    - [コンセンサスについて](intro-to-consensus.html)
+- **チュートリアル:**
+    - [容量の計画](capacity-planning.html) - 本番環境向けの推奨仕様および計画についての詳細情報
+    - [`rippled`のインストール](install-rippled.html)
+    - [rippledのトラブルシューティング](troubleshoot-the-rippled-server.html)
+- **リファレンス:**
+    - [rippled APIリファレンス](rippled-api.html)
+      - [`rippled`コマンドラインの使用](commandline-usage.html)
+      - [server_infoメソッド][]
+
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}
+{% include '_snippets/tx-type-links.md' %}
+{% include '_snippets/rippled_versions.md' %}
--- a/content/tutorials/manage-the-rippled-server/installation/update-rippled-automatically-on-linux.ja.md
+++ b/content/tutorials/manage-the-rippled-server/installation/update-rippled-automatically-on-linux.ja.md
@@ -0,0 +1,37 @@
+# Linuxでの自動更新
+
+Linuxでは、`rippled`が1回限りの`cron`構成を使用して最新バージョンに自動的にアップグレードされるように設定できます。可能であれば自動更新を有効にしておくことが推奨されます。
+
+以下の手順では、`rippled`が[`yum`リポジトリから（CentOS/RedHat）](install-rippled-on-centos-rhel-with-yum.html)、または[`apt`（Ubuntu/Debian）を使用して](install-rippled-on-ubuntu.html)インストールされていることを前提としています。
+
+自動更新を設定するには、以下の手順に従います。
+
+1. `/opt/ripple/etc/update-rippled-cron`が存在することを確認します。存在しない場合は、（[CentOS/Red Hat](update-rippled-manually-on-centos-rhel.html)または[Ubuntu/Debian](update-rippled-manually-on-ubuntu.html)を）手動で更新します。
+
+2. `cron.d`フォルダーに、`/opt/ripple/etc/update-rippled-cron`構成ファイルへのsymlinkを作成します。
+   
+        $ sudo ln -s /opt/ripple/etc/update-rippled-cron /etc/cron.d/
+   
+   このcron構成は、インストール済みの`rippled`パッケージを新版のリリース後1時間以内に更新するためのスクリプトを実行します。同時に更新を実行しているすべてのサーバーが停止する可能性を抑えるため、このスクリプトはランダムな分数（最大で59）で更新を遅延して行います。
+
+**注意:** 将来的には、Rippleのリポジトリが変更された場合に、更新を検索するスクリプトが実行されるURLの手動更新が必要となることがあります。必要な変更についての最新情報は、[XRP Ledgerブログ](/blog/)または[ripple-serverメーリングリスト](https://groups.google.com/forum/#!forum/ripple-server)でお知らせします。
+
+
+## 関連項目
+
+- **コンセプト:**
+    - [`rippled`サーバー](the-rippled-server.html)
+    - [コンセンサスについて](intro-to-consensus.html)
+- **チュートリアル:**
+    - [容量の計画](capacity-planning.html)
+    - [rippledのトラブルシューティング](troubleshoot-the-rippled-server.html)
+- **リファレンス:**
+    - [rippled APIリファレンス](rippled-api.html)
+      - [`rippled`コマンドラインの使用](commandline-usage.html)
+      - [server_infoメソッド][]
+
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}
+{% include '_snippets/tx-type-links.md' %}
+{% include '_snippets/rippled_versions.md' %}
--- a/content/tutorials/manage-the-rippled-server/installation/update-rippled-manually-on-centos-rhel.ja.md
+++ b/content/tutorials/manage-the-rippled-server/installation/update-rippled-manually-on-centos-rhel.ja.md
@@ -0,0 +1,41 @@
+# CentOS/Red Hatでの手動更新
+
+このページでは、CentOSまたはRed Hat Enterprise Linuxで最新リリースの`rippled`に手動で更新する手順を説明します。可能であれば手動更新ではなく[自動更新](update-rippled-automatically-on-linux.html)を設定することが推奨されます。
+
+以下の手順は、[`rippled`がすでに`yum`リポジトリからインストール](install-rippled-on-centos-rhel-with-yum.html)されていることを前提としています。
+
+**ヒント:** これらの手順をすべて一度に実行するには、`rippled`パッケージに含まれている`/opt/ripple/bin/update-rippled.sh`スクリプトを実行します。このスクリプトは`sudo`ユーザーとして実行する必要があります。
+
+手動で更新するには、以下の手順を実行します。
+
+1. 最新の`rippled`パッケージをダウンロードしてインストールします。
+   
+        $ sudo yum update rippled
+
+2. `systemd`ユニットファイルを再度読み込みます。
+   
+        $ sudo systemctl daemon-reload
+
+3. `rippled`サービスを再起動します。
+   
+        $ sudo service rippled restart
+
+
+## 関連項目
+
+- **コンセプト:**
+    - [`rippled`サーバー](the-rippled-server.html)
+    - [コンセンサスについて](intro-to-consensus.html)
+- **チュートリアル:**
+    - [`rippled` v1.3.xへの移行手順](rippled-1-3-migration-instructions.html) <!-- Note: remove when versions older than v1.3 are basically extinct -->
+    - [rippledのトラブルシューティング](troubleshoot-the-rippled-server.html)
+- **リファレンス:**
+    - [rippled APIリファレンス](rippled-api.html)
+      - [`rippled`コマンドラインの使用](commandline-usage.html)
+      - [server_infoメソッド][]
+
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}
+{% include '_snippets/tx-type-links.md' %}
+{% include '_snippets/rippled_versions.md' %}
--- a/content/tutorials/manage-the-rippled-server/installation/update-rippled-manually-on-ubuntu.ja.md
+++ b/content/tutorials/manage-the-rippled-server/installation/update-rippled-manually-on-ubuntu.ja.md
@@ -0,0 +1,45 @@
+# UbuntuまたはDebianでの手動更新
+
+このページでは、Ubuntu Linuxで最新リリースの`rippled`に手動で更新する手順を説明します。以下の手順は、[`rippled`がすでにネイティブパッケージを使用してインストール](install-rippled-on-ubuntu.html)されていることを前提としています。可能であれば手動更新ではなく[自動更新](update-rippled-automatically-on-linux.html)を設定することが推奨されます。
+
+**注意:** Ubuntu Linuxで`rippled` 1.2.xから1.3.1以降にアップグレードするには、[1.3.1への移行手順](rippled-1-3-migration-instructions.html)に従う必要があります。以下の手順は、バージョン1.3.1以降で提供されているネイティブAPTパッケージがインストール済みであることを前提としています。
+
+**ヒント:** これらの手順をすべて一度に実行するには、`rippled`パッケージに含まれている`/opt/ripple/bin/update-rippled.sh`スクリプトを実行します。`rippled`バージョン1.3.1以降、このスクリプトはUbuntuおよびDebianと互換性があります。このスクリプトは`sudo`ユーザーとして実行する必要があります。
+
+手動で更新するには、以下の手順を実行します。
+
+1. リポジトリを更新します。
+   
+        $ sudo apt -y update
+
+2. `rippled`パッケージをアップグレードします。
+   
+        $ sudo apt -y upgrade rippled
+
+3. `systemd`ユニットファイルを再度読み込みます。
+   
+        $ sudo systemctl daemon-reload
+
+4. `rippled`サービスを再起動します。
+   
+        $ sudo service rippled restart
+
+
+## 関連項目
+
+- **コンセプト:**
+    - [`rippled`サーバー](the-rippled-server.html)
+    - [コンセンサスについて](intro-to-consensus.html)
+- **チュートリアル:**
+    - [`rippled` v1.3.xへの移行手順](rippled-1-3-migration-instructions.html) <!-- Note: remove when versions older than v1.3 are basically extinct -->
+    - [rippledのトラブルシューティング](troubleshoot-the-rippled-server.html)
+- **リファレンス:**
+    - [rippled APIリファレンス](rippled-api.html)
+      - [`rippled`コマンドラインの使用](commandline-usage.html)
+      - [server_infoメソッド][]
+
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}
+{% include '_snippets/tx-type-links.md' %}
+{% include '_snippets/rippled_versions.md' %}
--- a/content/tutorials/manage-the-rippled-server/stand-alone-mode/load-a-saved-ledger-in-stand-alone-mode.ja.md
+++ b/content/tutorials/manage-the-rippled-server/stand-alone-mode/load-a-saved-ledger-in-stand-alone-mode.ja.md
@@ -1,8 +1,10 @@
 # スタンドアロンモードでの保存済みレジャーの読み込み

-`rippled`サーバーが以前にXRP Ledgerピアツーピアネットワーク（本番環境ネットワークまたは[Test Net](parallel-networks.html)）と同期されている場合は、ディスクに保存されたレジャーバージョンから開始できます。
+以前にディスクに保存していた[履歴レジャーバージョン](ledgers.html)を使用して、`rippled`サーバーを[スタンドアロンモード](rippled-server-modes.html)で起動できます。例えば、以前に`rippled`サーバーをXRP Ledgerのピアツーピアネットワーク（[本番Mainnet、Testnet、Devnetなど](parallel-networks.html)）と同期していた場合は、過去にサーバーで使用できていた任意のレジャーバージョンを読み込むことができます。

-## 1.`rippled`を通常の方法で起動します。
+履歴レジャーバージョンを読み込むことにより、レジャーを「リプレイ」して、トランザクションがネットワークのルールに従って処理されていたか検証したり、異なる[Amendment](amendments.html)を有効にした場合のトランザクションセットの処理の結果を比較したりすることができます。万が一、[XRP Ledgerのコンセンサスメカニズムに対する攻撃](consensus-protections.html)が発生して共有レジャーの状態に悪影響が及んでも、このプロセスを始めることで、バリデータのコンセンサスを以前の良好だったネットワークの状態に「ロールバック」できる可能性があります。
+
+## 1. `rippled`を通常の方法で起動します。

 既存のレジャーを読み込むには、最初にネットワークから当該のレジャーを取得する必要があります。`rippled`をオンラインモードで通常の方法で起動します。

@@ -10,7 +12,7 @@
 rippled --conf=/path/to/rippled.cfg
 ```

-## 2.`rippled`が同期されるまで待ちます。
+## 2. `rippled`が同期されるまで待ちます。

 [server_infoメソッド][]を使用して、ネットワークに対するサーバーの状態を確認します。`server_state`に以下のいずれかの値が示される場合は、サーバーは同期しています。

@@ -20,7 +22,7 @@ rippled --conf=/path/to/rippled.cfg

 詳細は、[考えられるサーバーの状態](rippled-server-states.html)を参照してください。

-## 3.（省略可）特定のレジャーバージョンを取得します。
+## 3. （省略可）特定のレジャーバージョンを取得します。

 最新レジャーのみを必要とする場合は、このステップをスキップできます。

@@ -28,7 +30,7 @@ rippled --conf=/path/to/rippled.cfg

 特定の履歴レジャーバージョンをリプレイする場合は、リプレイするレジャーバージョンとその直前のレジャーバージョンの両方を取得する必要があります。（前のレジャーバージョンにより、リプレイするレジャーバージョンに記述されている変更を適用する初期状態が設定されます。）

-## 4.`rippled`をシャットダウンします。
+## 4. `rippled`をシャットダウンします。

 [stopメソッド][]を使用します。

@@ -36,7 +38,7 @@ rippled --conf=/path/to/rippled.cfg
 rippled stop --conf=/path/to/rippled.cfg
 ```

-## 5.スタンドアロンモードで`rippled`を起動します。
+## 5. スタンドアロンモードで`rippled`を起動します。

 最新のレジャーバージョンを読み込むには、`-a`オプションと`--load`オプションを指定してサーバーを起動します。

@@ -50,9 +52,9 @@ rippled -a --load --conf=/path/to/rippled.cfg
 rippled -a --load --ledger 19860944 --conf=/path/to/rippled.cfg
 ```

-スタンドアロンモードで`rippled`を起動するときに使用できるオプションについての詳細は、[コマンドラインの使用リファレンスの「スタンドアロンモードのオプション」](commandline-usage.html#スタンドアロンモードのオプション)を参照してください。
+スタンドアロンモードで`rippled`を起動するときに使用可能なオプションについての詳細は、[コマンドラインの使用: スタンドアロンモードのオプション ](commandline-usage.html#スタンドアロンモードのオプション)を参照してください。

-## 6.レジャーを手動で進めます。
+## 6. レジャーを手動で進めます。

 スタンドアロンモードで`--ledger`を使用してレジャーを読み込むと、読み込まれたレジャーが現行のオープンレジャーになるので、[レジャーを手動で進める](advance-the-ledger-in-stand-alone-mode.html)必要があります。

@@ -60,7 +62,21 @@ rippled -a --load --ledger 19860944 --conf=/path/to/rippled.cfg
 rippled ledger_accept --conf=/path/to/rippled.cfg
 ```

+## 関連項目
+
+- **コンセプト:**
+    - [`rippled`サーバー](the-rippled-server.html)
+      - [`rippled`サーバーのモード](rippled-server-modes.html)
+    - [コンセンサスについて](intro-to-consensus.html)
+    - [Amendment](amendments.html)
+- **リファレンス:**
+    - [ledger_acceptメソッド][]
+    - [server_infoメソッド][]
+    - [`rippled`コマンドラインの使用](commandline-usage.html)
+- **ユースケース:**
+    - [`rippled`へのコードの提供](contribute-code-to-rippled.html)
+
 <!--{# common link defs #}-->
 {% include '_snippets/rippled-api-links.md' %}
 {% include '_snippets/tx-type-links.md' %}
-{% include '_snippets/rippled_versions.md' %}
+{% include '_snippets/rippled_versions.md' %}
--- a/content/tutorials/manage-the-rippled-server/troubleshooting/diagnosing-problems.ja.md
+++ b/content/tutorials/manage-the-rippled-server/troubleshooting/diagnosing-problems.ja.md
@@ -14,29 +14,71 @@
 rippled server_info
 ```

-このコマンドに対する応答には大量の情報が含まれています。これについては、[server_infoメソッド][]で説明します。
-トラブルシューティングで最も重要なフィールドは以下のとおりです（最も一般的に使われるものから順に説明します）。
+このコマンドに対する応答には大量の情報が含まれています。これについては、[server_infoメソッド][]で説明します。トラブルシューティングで最も重要なフィールドは以下のとおりです（最も一般的に使われるものから順に説明します）。

- **`server_state`** - ほとんどの場合、このフィールドには`proposing`（[バリデータとして設定されている](run-rippled-as-a-validator.html)サーバーの場合）または `full`（バリデータではないサーバーの場合）が表示されます。値が`connected`の場合は、サーバーはピアツーピアネットワークの他の部分と通信できますが、共有レジャーの状態を追跡するのに十分なデータがありません。通常、レジャーの残りの部分の状態を同期するには起動後5～15分かかります。
-
-    - サーバーが数時間にわたり`connected`状態である場合、または`full`あるいは`proposing`状態になってから`connected`状態に戻る場合は通常、サーバーがネットワークの他の部分よりも遅れています。最も一般的なボトルネックはディスクI/O、ネットワーク帯域幅、RAMです。
+- **`server_state`** - ほとんどの場合、このフィールドには`proposing`（[バリデータとして設定されている](run-rippled-as-a-validator.html)サーバーの場合）または`full`（バリデータではないサーバーの場合）が表示されます。値が`connected`の場合は、サーバーはピアツーピアネットワークの他の部分と通信できますが、共有レジャーの状態を追跡するのに十分なデータがありません。通常、レジャーの残りの部分の状態を同期するには起動後約5～15分かかります。
+  
+  - サーバーが数時間にわたり`connected`状態である場合、または`full`あるいは`proposing`状態になってから`connected`状態に戻る場合は通常、サーバーがネットワークの他の部分よりも遅れています。最も一般的なボトルネックはディスクI/O、ネットワーク帯域幅、RAMです。
+  
+  - 例えば、以下のサーバー状態情報は、正常なサーバーで同期が3分以内に完了しており（`disconnected`、`connected`、`syncing`の状態に分かれている）、現在は完全に同期された`proposing`状態が約90分間続いていることを示しています。
+    
+          $ ./rippled server_info
+          Loading: "/etc/opt/ripple/rippled.cfg"
+          2020-Jan-03 22:49:32.834134358 HTTPClient:NFO Connecting to 127.0.0.1:5005
+        
+          {
+            "result" : {
+                "info" : {
+                ...（省略）...
+                  "server_state" : "proposing",
+                  "server_state_duration_us" : "5183282365",
+                  "state_accounting" : {
+                    "connected" : {
+                      "duration_us" : "126164786",
+                      "transitions" : 1
+                    },
+                    "disconnected" : {
+                      "duration_us" : "2111321",
+                      "transitions" : 1
+                    },
+                    "full" : {
+                      "duration_us" : "5183282365",
+                      "transitions" : 1
+                    },
+                    "syncing" : {
+                      "duration_us" : "5545604",
+                      "transitions" : 1
+                    },
+                    "tracking" : {
+                      "duration_us" : "0",
+                      "transitions" : 1
+                    }
+                  },
+                ...（省略）...
+             }
+            }
+          }
+    
+    サーバーが同じ状態間で複数の`transitions`を示している場合、サーバーが同期状態を維持できなかったことを示します。`full`または`proposing`状態でない場合、サーバーはまだネットワークに同期されていません。長期の間には、インターネット接続が不安定になってサーバーの同期が時々失われる場合があります。そのためこれが問題になるのは、同期されていない時間がアップタイムのかなりの部分を占める場合のみです。アップタイムが約24時間経過した後に、`full`または`proposing`状態だった時間がサーバーの合計実行時間の99%に満たない場合、不安定になっている原因を調査することをお勧めします。
+  
+  - 同期の問題をデバッグする際の参考として、[サーバーが同期しない](server-doesnt-sync.html)を参照してください。

 - **`complete_ledgers`** - このフィールドは、サーバーに完全なレジャーデータが保管されている[レジャーインデックス](basic-data-types.html#レジャーインデックス)を示します。通常、正常なサーバーには連続した最新のレジャーのセット（`"12133424-12133858"`など）があります。
-
-    - 連続していない完全なレジャーのセット（`"11845721-12133420,12133424-12133858"`など）がある場合、サーバーで断続的な障害が発生したか、またはネットワークの他の部分との同期が一時的にできなかった可能性があります。このようなケースの最も一般的な原因は、ディスクI/Oまたはネットワーク帯域幅の不足です。
-
-    - 通常、`rippled`サーバーはピアから最新のレジャー履歴をダウンロードします。レジャー履歴のギャップが数時間以上続く場合は、欠落データを所有しているピアに接続されていない可能性があります。この状況が発生した場合は、構成ファイルに次のスタンザを追加して再起動すれば、完全な履歴が保管されているRippleのパブリックサーバーの1つにサーバーを強制的にピア接続できます。
-
-            [ips_fixed]
-            s2.ripple.com 51235
+  
+  - 連続していない完全なレジャーのセット（`"11845721-12133420,12133424-12133858"`など）がある場合、サーバーで断続的な障害が発生したか、またはネットワークの他の部分との同期が一時的にできなかった可能性があります。このようなケースの最も一般的な原因は、ディスクI/Oまたはネットワーク帯域幅の不足です。
+  
+  - 通常、`rippled`サーバーはピアから最新のレジャー履歴をダウンロードします。レジャー履歴のギャップが数時間以上続く場合は、欠落データを所有しているピアに接続されていない可能性があります。この状況が発生した場合は、構成ファイルに次のスタンザを追加して再起動すれば、完全な履歴が保管されているRippleのパブリックサーバーの1つにサーバーを強制的にピア接続できます。
+    
+          [ips_fixed]
+          s2.ripple.com 51235

 - **`amendment_blocked`** - このフィールドは通常`server_info`応答では省略されます。このフィールドの値が`true`の場合は、ネットワークにより承認された[Amendment](amendments.html)がサーバーに導入されていません。ほとんどの場合は、最新バージョンに[rippledを更新する](install-rippled.html)ことで修正できます。また[featureメソッド][]を使用して、現在有効なAmendment ID、サーバーでサポートされているAmendment ID、サーバーでサポートされていないAmendment IDを確認することもできます。

 - **`peers`** - このフィールドは、サーバーが接続しているXRP Ledgerピアツーピアネットワーク内のその他のサーバーの数を示します。特定のピアのみに接続するように明示的に構成されているサーバーを除き、正常なサーバーでは通常5～50ピアと表示されます。
-
-    - ピアの数が0の場合、サーバーがネットワークに接続できないか、またはシステムクロックが正しくない可能性があります。（サーバーのクロックを同期するため、すべてのサーバーで[NTP](http://www.ntp.org/)デーモンを実行することが推奨されます。）
-
-    - ピアの数が10の場合、`rippled`が[NAT](https://en.wikipedia.org/wiki/Network_address_translation)を使用したルーター経由での着信接続を受信できていない可能性があります。接続を改善するには、ルーターのファイアウォールがピアツーピア接続に使用するポート（[デフォルトでは](https://github.com/ripple/rippled/blob/8429dd67e60ba360da591bfa905b58a35638fda1/cfg/rippled-example.cfg#L1065)ポート51235）を転送するように設定します。
+  
+  - ピアの数が0の場合、サーバーがネットワークに接続できないか、またはシステムクロックが正しくない可能性があります。（サーバーのクロックを同期するため、すべてのサーバーで[NTP](http://www.ntp.org/)デーモンを実行することが推奨されます。）
+  
+  - ピアの数が10の場合、`rippled`が[NAT](https://en.wikipedia.org/wiki/Network_address_translation)を使用したルーター経由での着信接続を受信できていない可能性があります。接続を改善するには、ルーターのファイアウォールがピアツーピア接続に使用するポート（[デフォルトでは](https://github.com/ripple/rippled/blob/8429dd67e60ba360da591bfa905b58a35638fda1/cfg/rippled-example.cfg#L1065)ポート51235）を転送するように設定します。

 ### サーバーから応答がない場合

@@ -44,10 +86,10 @@ rippled server_info

 ```json
 {
-  "error" : "internal",
-  "error_code" : 71,
-  "error_message" : "Internal error.",
-  "error_what" : "no response from server"
+   "error" : "internal",
+   "error_code" : 71,
+   "error_message" : "Internal error.",
+   "error_what" : "no response from server"
 }
 ```

@@ -57,7 +99,6 @@ rippled server_info
 - サーバーに接続するために異なる[パラメーターを`rippled`コマンドラインクライアントに](commandline-usage.html#クライアントモードのオプション)渡す必要があります。
 - `rippled`サーバーがJSON-RPC接続を受け入れるように構成されていない可能性があります。

-
 ## サーバーログの確認

 [デフォルトでは](https://github.com/ripple/rippled/blob/master/cfg/rippled-example.cfg#L1139-L1142)`rippled`はサーバーのデバッグログを`/var/log/rippled/debug.log`ファイルに書き込みます。このデバッグログの位置は、サーバーの構成ファイルにより異なる可能性があります。`rippled`サービスを（`systemctl`または`service`を使用して開始するのではなく）直接開始した場合、デフォルトではログメッセージはコンソールにも出力されます。
@@ -68,7 +109,19 @@ rippled server_info

 さまざまな種類のログメッセージに関する詳しい説明については、[ログメッセージについて](understanding-log-messages.html)を参照してください。

+## 関連項目

+- **コンセプト:**
+    - [`rippled`サーバー](the-rippled-server.html)
+    - [Amendment](amendments.html)
+- **チュートリアル:**
+    - [容量の計画](capacity-planning.html)
+    - [rippledの構成](configure-rippled.html)
+- **リファレンス:**
+    - [rippled APIリファレンス](rippled-api.html)
+      - [`rippled`コマンドラインの使用](commandline-usage.html)
+      - [log_levelメソッド][]
+      - [server_infoメソッド][]

 <!--{# common link defs #}-->
 {% include '_snippets/rippled-api-links.md' %}
--- a/content/tutorials/manage-the-rippled-server/troubleshooting/server-doesnt-sync.ja.md
+++ b/content/tutorials/manage-the-rippled-server/troubleshooting/server-doesnt-sync.ja.md
@@ -0,0 +1,109 @@
+# rippledサーバーが同期しない
+
+このページでは、[`rippled`サーバー](the-rippled-server.html)が正常に起動したのに、ネットワークに完全に接続できずに[「connected」状態](rippled-server-states.html)のままになっている場合の原因について説明します。（サーバーが起動中または起動直後にクラッシュした場合は、[サーバーが起動しない](server-wont-start.html)を参照してください。）
+
+以下の手順では、サポートされているプラットフォームに[`rippled`がインストール](install-rippled.html)されていることを前提としています。
+
+## 通常の同期動作
+
+ネットワークとの同期は、通常はおよそ5分から15分で完了します。その間に、サーバーは次のようなさまざまなことを行います。
+
+- 推奨バリデータリストを読み込み（通常は`vl.ripple.com`から）、信頼できるバリデータを判断します。
+- [ピアサーバーを検出](peer-protocol.html#ピア発見)して接続します。
+- ピアから最新のレジャーの[ヘッダー](ledger-header.html)と完全な[状態情報](ledgers.html#ツリーの形式)をダウンロードし、それを使用してレジャーデータの内部データベースを構築します。
+- 信頼できるバリデータをリッスンして、最近検証されたレジャーハッシュを見つけます。
+- 新たにブロードキャストされたトランザクションを収集し、それを進行中のレジャーに適用します。
+
+サーバーがこれらのタスクを行うときにネットワークに同調して対応できなかった場合は、サーバーはネットワークと同期しない状態になります。
+
+## 最初のステップ: 再起動
+
+多くの同期の問題は、サーバーを再起動することで解決できます。最初に同期が失敗した原因がどのようなものであっても、2回目では成功する場合があります。
+
+[server_infoメソッド][]で[`server_state`](rippled-server-states.html)が`proposing`または`full`以外の状態であると示され、`server_state_duration_us`が`900000000`（15分のマイクロ秒表記）より大きい場合は、`rippled`サービスをシャットダウンしてから数秒間待ち、再起動してください。場合によっては、マシン全体を再起動します。
+
+問題が解決しない場合は、このページに記載されている他の原因を確認してください。いずれも当てはまらないと思われる場合は、[`rippled`リポジトリに問題を登録](https://github.com/ripple/rippled/issues)し、「Syncing issue」ラベルを追加します。
+
+## 同期の問題のよくある原因
+
+同期の問題の原因として最もよくあるのは、[システム要件](system-requirements.html)を満たしていないことです。要件を満たせない主な原因は次の3つです。
+
+-  **低速なディスク。** 安定して高速な性能を発揮するソリッドステートディスク（SSD）が必要です。AWSなどのクラウドプロバイダーはディスク性能を保証しておらず、ハードウェアを共有する他のユーザーの影響を受ける可能性があります。
+-  **不十分なRAM。** メモリー要件はさまざまな要因に大きく左右されます。例えば、ネットワークの負荷やXRP Ledgerがどのように使われるかなど、予測しづらい要因もあるため、念のため最小システム要件よりも大きいメモリーを用意することをお勧めします。
+-  **品質の悪いネットワーク接続。** ネットワーク要件は、主にXRP Ledgerをユーザーがどのよう使うかによって左右されますが、接続が低速または不安定な場合、XRP Ledgerに追加された新しいトランザクションやデータとの同期がとれなくなる可能性があります。
+
+同期の問題が解消されない場合は、サーバーがシステム要件を満たしているかもう一度確認してください。サーバーの使用方法によっては、「最小」要件よりも高い「推奨」要件を満たす必要があります。「推奨」要件を満たしていても、まだ同期ができない場合は、このページの他の原因を試してみてください。
+
+## バリデータリストを読み込めない
+
+デフォルトの構成では、`vl.ripple.com`から受信した推奨バリデータリストを使用します。このリストは、Rippleの暗号鍵ペアで署名されており、有効期限が組み込まれています。サーバーが何らかの理由でリストを`vl.ripple.com`からダウンロードできない場合、サーバーは信頼できるバリデータのセットを選択せず、有効として宣言できるレジャーを決定できません。（[Testnetや別の並列ネットワーク](parallel-networks.html)に接続している場合、サーバーは代わりにそのネットワークの信頼できるバリデータのリストを使用します。）
+
+[server_infoメソッド][]応答の`validator_list`ブロックは、バリデータリストの有効期限などのステータスを示します。リストがあるが期限切れである場合、サーバーは以前はそのバリデータリストのサイトに接続できていたものの、その後接続できなくなった可能性があります。その場合、現在のリストはサーバーがそれより新しいリストをダウンロードできなかったために期限切れとなった可能性があります。
+
+また、[validator_list_sitesメソッド][]を使用して、より詳細な情報を取得することもできます。応答内のバリデータサイトオブジェクトに`last_refresh_status`および`last_refresh_time`フィールドがない場合、サーバーからバリデータリストのサイトへの接続に問題があることを示しています。ファイアウォールの設定をチェックして、ポート80（HTTP）または443（HTTPS）の発信トラフィックをブロックしていないことを確認してください。また、DNSがバリデータリストのサイトのドメインを解決できることも確認してください。
+
+<!-- TODO: create a tutorial for how to sideload a validator list from file and link it here -->
+
+
+## 十分な数のピアがない
+
+サーバーが十分な数の[ピアサーバー](peer-protocol.html)に接続していない場合、サーバーは十分なデータをダウンロードできず、ネットワークが新しいトランザクションを処理するときに同期がとれなくなる可能性があります。この問題は、ネットワーク接続の信頼性が低い場合や、十分な数の信頼できる固定ピアを追加せずにサーバーを[プライベートサーバー](peer-protocol.html#プライベートピア)として構成している場合に起こる可能性があります。
+
+[peersメソッド][]を使用して、サーバーの現在のピアについての情報を取得します。ピアの数が10または11の場合、ファイアウォールが着信ピア接続をブロックしていることを示しています。[ポートフォワーディングを設定](forward-ports-for-peering.html)して、より多くの着信接続を許可します。サーバーがプライベートサーバーとして構成されている場合は、構成ファイルの`[ips_fixed]`スタンザの内容と構文を再度確認し、可能であればプロキシと公開ハブをさらに追加します。
+
+
+## データベースの破損
+
+まれに、`rippled`サーバーの内部データベースに保存されているデータが破損していることで同期の問題が発生する場合があります。サーバーが稼動中でなければ、ほとんどの場合、サーバーのデータベースを安全に削除できます。データの破損は、ディスクにコピーまたは書き込みするときに起こった一時的なハードウェア障害や、より深刻なディスク障害、別のプロセスがクラッシュしてディスクの誤った部分に書き込んだなど、さまざまな問題の結果として起こる可能性があります。
+
+テストとして、十分な空き容量があれば、サーバーのデータベースへのパスを一時的に変更することで、現行のレジャーをダウンロードし直して、別の設定を保存できます。
+
+**注記:** データベースのパスを変更した場合、サーバーはサーバーの現在の[ノードキーペア][]や[ピアリザベーション](peer-protocol.html#固定ピアとピアリザベーション)など、保存されている一部の設定を読み込めません。データベースのパスを変更することでサーバーの同期の問題が解決した場合は、これらの設定の一部を再作成することをお勧めします。
+
+1. `rippled`サーバーが稼働中の場合は停止します。
+   
+        $ sudo systemctl stop rippled
+
+2. 新しいデータベースを格納するための新しい空のフォルダーを作成します。
+   
+        $ mkdir /var/lib/rippled/db_new/
+        $ mkdir /var/lib/rippled/db_new/nudb
+
+3. 新しいパスを使用するように構成ファイルを編集します。`[node_db]`スタンザの`path`フィールド**と**`[database_path]`スタンザの値を変更します。
+   
+        [node_db]
+        type=NuDB
+        path=/var/lib/rippled/db_new/nudb
+       
+        [database_path]
+         /var/lib/rippled/db_new
+   
+    {% include '_snippets/conf-file-location.md' %}<!--_ -->
+
+4. `rippled`サーバーを再起動します。
+   
+        $ sudo systemctl start rippled
+   
+   新しいデータベースを使用してサーバーが同期に成功したら、以前のデータベースを格納していたフォルダーを削除できます。また、ハードウェア障害、特にディスクとRAMの障害を確認することもお勧めします。
+
+
+## 関連項目
+
+- **コンセプト:**
+    - [`rippled`サーバー](the-rippled-server.html)
+    - [ピアプロトコル](peer-protocol.html)
+    - [技術に関するよくある質問](technical-faq.html)
+- **チュートリアル:**
+    - [ログメッセージについて](understanding-log-messages.html)
+    - [容量の計画](capacity-planning.html)
+- **リファレンス:**
+    - [rippled APIリファレンス](rippled-api.html)
+      - [peersメソッド][]
+      - [server_infoメソッド][]
+      - [validator_list_sitesメソッド][]
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}
+{% include '_snippets/tx-type-links.md' %}
+{% include '_snippets/rippled_versions.md' %}
+
--- a/content/tutorials/manage-the-rippled-server/troubleshooting/server-wont-start.ja.md
+++ b/content/tutorials/manage-the-rippled-server/troubleshooting/server-wont-start.ja.md
@@ -1,46 +1,45 @@
 # rippledサーバーが起動しない

-このページでは、`rippled`サーバーが起動しない際に考えられる原因とその修正方法を説明します。
+このページでは、[`rippled`サーバー](the-rippled-server.html)が起動しない際に考えられる原因とその修正方法を説明します。

 以下の手順では、サポートされているプラットフォームに[`rippled`がインストール](install-rippled.html)されていることを前提としています。

-
 ## ファイル記述子の制限

 一部のLinuxバリアントでは、`rippled`を実行しようとすると以下のようなエラーメッセージが出力されることがあります。

-```テキスト
+```text
 WARNING: There are only 1024 file descriptors (soft limit) available, which
 limit the number of simultaneous connections.
 ```

 これは、セキュリティの点からシステムで1つのプロセスが開くことができるファイルの数に制限があるが、その制限が`rippled`にとっては少なすぎる場合に発生します。この問題を修正するには、**ルートアクセス権限が必要です**。以下の手順に従い、`rippled`が開くことができるファイルの数を増やします。

-1. 次の行を`/etc/security/limits.conf` ファイルの終わりに追加します。
-
+1. 次の行を`/etc/security/limits.conf`ファイルの終わりに追加します。
+   
        *                soft    nofile          65536
        *                hard    nofile          65536

 2. [開くことができるファイルの数のハード制限](https://ss64.com/bash/ulimit.html)が現在`65536`であることを確認します。
-
+   
        ulimit -Hn
-
-    このコマンドの出力は`65536`になるはずです。
+   
+   このコマンドの出力は`65536`になるはずです。

 3. `rippled`をもう一度起動します。
-
+   
        systemctl start rippled

 4. それでも`rippled`が起動しない場合は、`/etc/sysctl.conf`を開き、以下のカーネルレベル設定を付加します。
-
+   
        fs.file-max = 65536
-
+        

 ## /etc/opt/ripple/rippled.cfgを開くことができない

-`rippled` が起動時にクラッシュし、以下のようなエラーが出力される場合は、`rippled`が構成ファイルを読み取ることができません。
+`rippled`が起動時にクラッシュし、以下のようなエラーが出力される場合は、`rippled`が構成ファイルを読み取ることができません。

-```テキスト
+```text
 Loading: "/etc/opt/ripple/rippled.cfg"
 Failed to open '"/etc/opt/ripple/rippled.cfg"'.
 Terminating thread rippled: main: unhandled St13runtime_error 'Can not create "/var/opt/ripple"'
@@ -52,16 +51,16 @@ Aborted (core dumped)
 - 構成ファイル（デフォルトのロケーションは`/etc/opt/ripple/rippled.cfg`）が存在しており、`rippled`プロセスを実行するユーザー（通常は`rippled`）にこのファイルの読み取り権限があることを確認します。

 - `rippled`ユーザーが読み取ることができる構成ファイルを`$HOME/.config/ripple/rippled.cfg`に作成します（`$HOME`は`rippled`ユーザーのホームディレクトリを指しています）。
+  
+    **ヒント:** `rippled`リポジトリには、RPMのインストール時にデフォルトの構成として提供される[`rippled.cfg`サンプルファイル](https://github.com/ripple/rippled/blob/master/cfg/rippled-example.cfg)が含まれています。このファイルがない場合は、上記のリンク先からコピーできます。

-    **ヒント:**`rippled`リポジトリには、RPMのインストール時にデフォルトの構成として提供される[`rippled.cfg`サンプルファイル](https://github.com/ripple/rippled/blob/master/cfg/rippled-example.cfg)が含まれています。このファイルがない場合は、上記のリンク先からコピーできます。
-
- `--conf` [コマンドラインオプション](commandline-usage.html)を使用して、使用する構成ファイルのパスを指定します。
+- `--conf`[コマンドラインオプション](commandline-usage.html)を使用して、使用する構成ファイルのパスを指定します。

 ## バリデータファイルを開くことができない

 `rippled`が起動時にクラッシュし、以下のようなエラーが出力される場合は、`rippled`はプライマリ構成ファイルを読み取ることはできても、この構成ファイルに指定されている別のバリデータ構成ファイル（通常は`validators.txt`）を読み取ることができません。

-```テキスト
+```text
 Loading: "/home/rippled/.config/ripple/rippled.cfg"
 Terminating thread rippled: main: unhandled St13runtime_error 'The file specified in [validators_file] does not exist: /home/rippled/.config/ripple/validators.txt'
 Aborted (core dumped)
@@ -70,19 +69,19 @@ Aborted (core dumped)
 考えられる解決策:

 - `[validators.txt]`ファイルが存在し、`rippled`ユーザーにこのファイルの読み取り権限があることを確認します。
-
-    **ヒント:**`rippled`リポジトリには、RPMのインストール時にデフォルトの構成として提供される[`validators.txt`サンプルファイル](https://github.com/ripple/rippled/blob/master/cfg/validators-example.txt)が含まれています。このファイルがない場合は、上記のリンク先からコピーできます。
+  
+    **ヒント:** `rippled`リポジトリには、RPMのインストール時にデフォルトの構成として提供される[`validators.txt`サンプルファイル](https://github.com/ripple/rippled/blob/master/cfg/validators-example.txt)が含まれています。このファイルがない場合は、上記のリンク先からコピーできます。

 - `rippled.cfg`ファイルを編集し、`[validators_file]`設定を変更して、`validators.txt`ファイル（またはこれに相当するファイル）の正しいパスを指定します。ファイル名の前後に余分な空白があるかどうかを確認します。

 - `rippled.cfg`ファイルを編集し、`[validators_file]`設定を削除します。バリデータ設定を`rippled.cfg`ファイルに直接追加します。例:
-
+  
        [validator_list_sites]
        https://vl.ripple.com
-
+      
        [validator_list_keys]
        ED2677ABFFD1B33AC6FBC3062B71F1E8397C1505E1C42C64D11AD1B28FF73F4734
-
+        

 ## データベースパスを作成できない

@@ -111,8 +110,8 @@ Aborted (core dumped)

 ```text
 2018-Aug-21 23:06:38.675117810 SHAMapStore:ERR state db error:
- writableDbExists false archiveDbExists false
- writableDb '/var/lib/rippled/db/rocksdb/rippledb.11a9' archiveDb '/var/lib/rippled/db/rocksdb/rippledb.2d73'
+  writableDbExists false archiveDbExists false
+  writableDb '/var/lib/rippled/db/rocksdb/rippledb.11a9' archiveDb '/var/lib/rippled/db/rocksdb/rippledb.2d73'

 To resume operation, make backups of and remove the files matching /var/lib/rippled/db/state* and contents of the directory /var/lib/rippled/db/rocksdb

@@ -149,7 +148,7 @@ path=/var/lib/rippled/custom_nudb_path

 以下のようなエラーメッセージが出力される場合、`rippled.cfg`ファイルの`[ledger_history]`と`online_delete`に矛盾する値が指定されています。

-```テキスト
+```text
 Terminating thread rippled: main: unhandled St13runtime_error 'online_delete must not be less than ledger_history (currently 3000)
 ```

@@ -162,7 +161,7 @@ Terminating thread rippled: main: unhandled St13runtime_error 'online_delete mus

 以下のようなエラーが出力される場合は、`rippled.cfg`ファイルの`node_size`設定の値が誤っています。

-```テキスト
+```text
 Terminating thread rippled: main: unhandled N5beast14BadLexicalCastE 'std::bad_cast'
 ```

@@ -173,23 +172,43 @@ Terminating thread rippled: main: unhandled N5beast14BadLexicalCastE 'std::bad_c

 以下のようなエラーが出力される場合は、`rippled.cfg`の[履歴シャーディング](history-sharding.html)の設定が不完全です。

-```テキスト
+```text
 Terminating thread rippled: main: unhandled St13runtime_error 'shard path missing'
 ```

 設定に`[shard_db]`スタンザが含まれている場合、このスタンザには`path`フィールドが指定されている必要があります。このフィールドは、`rippled`がシャードストアーのデータを書き込むことができるディレクトリを指しています。このエラーが発生する場合は、`path`フィールドが欠落しているか、誤った位置に指定されています。構成ファイルで余分な空白やスペルミスがないかどうかを確認し、[シャード設定の例](configure-history-sharding.html#2-rippledcfgの編集)と比較してください。

+## サポート対象外のシャードストアータイプ: RocksDB

-## ShardStoreがRocksDBを開くかまたは作成することができない
+RocksDBは、[履歴シャーディング](history-sharding.html)のバックエンドとしてサポートされなくなりました。RocksDBシャードストアーを定義している既存の構成がある場合は、サーバーが起動に失敗します。[新規: rippled 1.3.1][]

-[履歴シャーディング](history-sharding.html)を有効にし、その後設定を変更してNuDBではなくRocksDBを使用するように設定した場合、サーバーは既存のNuDBデータをRocksDBデータとして読み取ろうとし、起動に失敗します。この場合、サーバーは以下のようなエラーを書き込みます。
+この場合、log startupコマンドの直後にプロセスが終了し、出力ログの早い段階で次のようなメッセージが表示されます。

-```テキスト
-ShardStore:ERR shard 504 error: Unable to open/create RocksDB: Invalid argument: /var/lib/rippled/db/shards/504: does not exist (create_if_missing is false)
+```text
+ShardStore:ERR Unsupported shard store type: RocksDB
 ```

-この問題を修正するには、以下のいずれかを行います。

- 設定されているフォルダーから既存のシャードデータを移動する。
- ディスク上のシャードストアーの位置を変更するため、`rippled.cfg`ファイルの`[shard_db]`スタンザの`path`を変更する。
- NuDBを使用するようにシャードストアーを変更する。
+この問題を修正するには、以下のいずれかを行ってからサーバーを再起動します。
+
+- 代わりにNuDBを使用するようにシャードストアーを変更します。
+- 履歴シャーディングを無効にします。
+
+
+## 関連項目
+
+- **コンセプト:**
+    - [`rippled`サーバー](the-rippled-server.html)
+    - [技術に関するよくある質問](technical-faq.html)
+- **チュートリアル:**
+    - [ログメッセージについて](understanding-log-messages.html)
+    - [容量の計画](capacity-planning.html)
+- **リファレンス:**
+    - [rippled APIリファレンス](rippled-api.html)
+      - [`rippled`コマンドラインの使用](commandline-usage.html)
+      - [server_infoメソッド][]
+
+<!--{# common link defs #}-->
+{% include '_snippets/rippled-api-links.md' %}
+{% include '_snippets/tx-type-links.md' %}
+{% include '_snippets/rippled_versions.md' %}
--- a/content/tutorials/manage-the-rippled-server/troubleshooting/understanding-log-messages.ja.md
+++ b/content/tutorials/manage-the-rippled-server/troubleshooting/understanding-log-messages.ja.md
@@ -1,6 +1,6 @@
 # ログメッセージについて

-以下のセクションでは、`rippled`サーバーのデバッグログに出力される最も一般的なログメッセージタイプとその解釈を説明します。
+以下のセクションでは、[`rippled`サーバー](the-rippled-server.html)のデバッグログに出力される最も一般的なログメッセージタイプとその解釈を説明します。

 これは、`rippled`の[問題を診断する](diagnosing-problems.html)上で重要なステップです。

@@ -27,11 +27,26 @@ Terminating thread rippled: main: unhandled St13runtime_error
 上記のいずれにも該当しない場合は、その問題をセキュリティ上重要なバグとしてRippleに報告してください。Rippleでクラッシュを再現できる場合は、報奨を受領できる可能性があります。詳細は<https://ripple.com/bug-bounty/>を参照してください。


+## Already validated sequence at or past
+
+以下のようなログメッセージが出力される場合は、サーバーが異なるレジャーインデックスの検証を順不同で受信しています。
+
+```text
+2018-Aug-28 22:55:58.316094260 Validations:WRN Val for 2137ACEFC0D137EFA1D84C2524A39032802E4B74F93C130A289CD87C9C565011 trusted/full from nHUeUNSn3zce2xQZWNghQvd9WRH6FWEnCBKYVJu2vAizMxnXegfJ signing key n9KcRZYHLU9rhGVwB9e4wEMYsxXvUfgFxtmX25pc1QPNgweqzQf5 already validated sequence at or past 12133663 src=1
+```
+
+この種類のメッセージが時折発生しても通常は問題ありません。この種類のメッセージが同じ送信バリデータで頻繁に発生する場合は、以下のような問題がある可能性があります（可能性の高いものから順に示しています）。
+
+- メッセージを書き込むサーバーにネットワークの問題がある。
+- メッセージに表示されているバリデータにネットワークの問題がある。
+- メッセージに表示されているバリデータが悪意のある振る舞いをしている。
+
+
 ## Connection reset by peer

 以下のメッセージは、ピア`rippled`サーバーによって接続が閉じられたことを示します。

-```テキスト
+```text
 2018-Aug-28 22:55:41.738765510 Peer:WRN [012] onReadMessage: Connection reset by peer
 ```

@@ -43,28 +58,44 @@ Terminating thread rippled: main: unhandled St13runtime_error
 - サーバーからの要求でピアに過剰な負担がかかり、ピアがサーバーをドロップした。


-## No hash for fetch pack
+## InboundLedger 11 timeouts for ledger

-以下のようなメッセージは、[履歴シャーディング](history-sharding.html)のために履歴レジャーをダウンロードする際に、`rippled` v1.1.0以前のバグが原因で発生します。
-
-```テキスト
-2018-Aug-28 22:56:21.397076850 LedgerMaster:ERR No hash for fetch pack.Missing Index 7159808
+```text
+InboundLedger:WRN 11 timeouts for ledger 8265938
 ```

-これらは安全に無視できます。
+これは、サーバーがそのピアに対して特定のレジャーデータを要求する際に問題が発生していることを示しています。[レジャーインデックス](basic-data-types.html#レジャーインデックス)が、[server_infoメソッド][]により報告される最新の検証済みレジャーのインデックスよりもかなり小さい場合は、サーバーが[履歴シャード](history-sharding.html)のダウンロード中である可能性があります。
+
+これは厳密には問題ではありませんが、レジャー履歴を迅速に取得したい場合は、`[ips_fixed]`構成スタンザを追加または編集してからサーバーを再起動することで、すべての履歴が記録されたピアに接続するように`rippled`を構成できます。たとえば、すべての履歴が記録されたRippleのサーバーに常に接続するには、以下のようにします。
+
+```
+[ips_fixed]
+s2.ripple.com 51235
+```
+
+
+## InboundLedger Want hash
+
+以下のようなログメッセージは、サーバーが他のサーバーにレジャーデータを要求していることを示しています。
+
+```text
+InboundLedger:WRN Want: 5AE53B5E39E6388DBACD0959E5F5A0FCAF0E0DCBA45D9AB15120E8CDD21E019B
+```
+
+これは、サーバーの同期中、埋め戻し中、[履歴シャード](history-sharding.html)のダウンロード中は正常です。


 ## LoadMonitor:WRN Job

 以下のようなメッセージは、機能の実行に時間がかかっている場合（この例では11秒以上）に出力されます。

-```テキスト
+```text
 2018-Aug-28 22:56:36.180827973 LoadMonitor:WRN Job: gotFetchPack run: 11566ms wait: 0ms
 ```

 以下のようなメッセージは、ジョブの実行待機に時間がかかっている場合（この例でも11秒以上）に出力されます。

-```テキスト
+```text
 2018-Aug-28 22:56:36.180970431 LoadMonitor:WRN Job: processLedgerData run: 0ms wait: 11566ms
 2018-Aug-28 22:56:36.181053831 LoadMonitor:WRN Job: AcquisitionDone run: 0ms wait: 11566ms
 2018-Aug-28 22:56:36.181110594 LoadMonitor:WRN Job: processLedgerData run: 0ms wait: 11566ms
@@ -89,89 +120,107 @@ type=RocksDB
 ```


-## View of consensus changed during open
+## No hash for fetch pack

-以下のようなログメッセージが出力される場合は、サーバーがネットワークの他の部分と同期していません。
+以下のようなメッセージは、[履歴シャーディング](history-sharding.html)のために履歴レジャーをダウンロードする際に、`rippled` v1.1.0以前のバグが原因で発生します。

-```テキスト
-2018-Aug-28 22:56:22.368460130 LedgerConsensus:WRN View of consensus changed during open status=open,  mode=proposing
-2018-Aug-28 22:56:22.368468202 LedgerConsensus:WRN 96A8DF9ECF5E9D087BAE9DDDE38C197D3C1C6FB842C7BB770F8929E56CC71661 to 00B1E512EF558F2FD9A0A6C263B3D922297F26A55AEB56A009341A22895B516E
-2018-Aug-28 22:56:22.368499966 LedgerConsensus:WRN {"accepted":true,"account_hash":"89A821400087101F1BF2D2B912C6A9F2788CC715590E8FA5710F2D10BF5E3C03","close_flags":0,"close_time":588812130,"close_time_human":"2018-Aug-28 22:55:30.000000000","close_time_resolution":30,"closed":true,"hash":"96A8DF9ECF5E9D087BAE9DDDE38C197D3C1C6FB842C7BB770F8929E56CC71661","ledger_hash":"96A8DF9ECF5E9D087BAE9DDDE38C197D3C1C6FB842C7BB770F8929E56CC71661","ledger_index":"3","parent_close_time":588812070,"parent_hash":"5F5CB224644F080BC8E1CC10E126D62E9D7F9BE1C64AD0565881E99E3F64688A","seqNum":"3","totalCoins":"100000000000000000","total_coins":"100000000000000000","transaction_hash":"0000000000000000000000000000000000000000000000000000000000000000"}
+```text
+2018-Aug-28 22:56:21.397076850 LedgerMaster:ERR No hash for fetch pack. Missing Index 7159808
 ```

-サーバー起動後の最初の5～15分間に、サーバーがネットワークの他の部分と同期せず、このようなメッセージが出力されることは特に異常な動作ではありません。サーバー起動後かなり経過してからこれらのメッセージが書き込まれる場合は、問題が発生している可能性があります。一般的な原因としては、信頼性の低いネットワーク接続や不十分なハードウェアスペックなどが考えられます。また、同じハードウェアで実行されている他のプロセスがリソースをめぐって`rippled`と競合している場合にも発生する可能性があります。（`rippled`とリソースをめぐって競合する可能性のある他のプロセスの例としては、スケジュール済みバックアップ、ウィルススキャナー、定期的なデータベースクリーナーなどがあります。）
-
-
-## Already validated sequence at or past
-
-以下のようなログメッセージが出力される場合は、サーバーが異なるレジャーシーケンスの検証を順不同で受信しています。
-
-```テキスト
-2018-Aug-28 22:55:58.316094260 Validations:WRN Val for 2137ACEFC0D137EFA1D84C2524A39032802E4B74F93C130A289CD87C9C565011 trusted/full from nHUeUNSn3zce2xQZWNghQvd9WRH6FWEnCBKYVJu2vAizMxnXegfJ signing key n9KcRZYHLU9rhGVwB9e4wEMYsxXvUfgFxtmX25pc1QPNgweqzQf5 already validated sequence at or past 12133663 src=1
-```
-
-この種類のメッセージが時折発生しても通常は問題ありません。この種類のメッセージが同じ送信バリデータで頻繁に発生する場合は、以下のような問題がある可能性があります（可能性の高いものから順に示しています）。
-
- メッセージを書き込むサーバーにネットワークの問題がある。
- メッセージに表示されているバリデータにネットワークの問題がある。
- メッセージに表示されているバリデータが悪意のある振る舞いをしている。
-
-
-## Unable to determine hash of ancestor
-
-以下のようなログメッセージは、サーバーがピアからの検証メッセージを認識するけれども、サーバーが基盤としている親レジャーバージョンを認識しない場合に発生します。これは、サーバーがネットワークと同期している場合には正常です。
-
-```テキスト
-2018-Aug-28 22:56:22.256065549 Validations:WRN Unable to determine hash of ancestor seq=3 from ledger hash=00B1E512EF558F2FD9A0A6C263B3D922297F26A55AEB56A009341A22895B516E seq=12133675
-```
-
-サーバー起動後の5～15分以外の時点でこのメッセージが頻繁に発生する場合は、問題が発生している可能性があります。
-
-
-## InboundLedger Want hash
-
-以下のようなログメッセージは、サーバーが他のサーバーにレジャーデータを要求していることを示しています。
-
-```テキスト
-InboundLedger:WRN Want: 5AE53B5E39E6388DBACD0959E5F5A0FCAF0E0DCBA45D9AB15120E8CDD21E019B
-```
-
-これは、サーバーの同期中、埋め戻し中、[履歴シャード](history-sharding.html)のダウンロード中は正常です。
-
-
-## InboundLedger 11 timeouts for ledger
-
-```テキスト
-InboundLedger:WRN 11 timeouts for ledger 8265938
-```
-
-これは、サーバーがそのピアに対して特定のレジャーデータを要求する際に問題が発生していることを示しています。[レジャーインデックス](basic-data-types.html#レジャーインデックス)が、[server_infoメソッド][]により報告される最新の検証済みレジャーのインデックスよりもかなり小さい場合は、サーバーが[履歴シャード](history-sharding.html)のダウンロード中である可能性があります。
-
-これは厳密には問題ではありませんが、レジャー履歴を迅速に取得したい場合は、`[ips_fixed]`構成スタンザを追加または編集してからサーバーを再起動することで、すべての履歴が記録されたピアに接続するように`rippled`を構成できます。たとえば、すべての履歴が記録されたRippleのサーバーに常に接続するには、以下のようにします。
-
-```
-[ips_fixed]
-s2.ripple.com 51235
-```
+これらは安全に無視できます。


 ## Potential Censorship

-XRP Ledgerが取引検閲の可能性を検出すると、以下のようなログメッセージが出力されます。ログメッセージと取引検閲検出機能の詳細については、[取引検閲の検知](transaction-censorship-detection.html)を参照してください。
+XRP Ledgerが取引検閲の可能性を検出すると、以下のようなログメッセージが出力されます。ログメッセージと取引検閲検出機能の詳細は、[取引検閲の検知](transaction-censorship-detection.html)を参照してください。

 **警告メッセージ**

-```テキスト
+```text
 LedgerConsensus:WRN Potential Censorship: Eligible tx E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7, which we are tracking since ledger 18851530 has not been included as of ledger 18851545.
 ```

 **エラーメッセージ**

-```テキスト
-LedgerConsensus:ERR Potential Censorship: Eligible tx E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7, which we are tracking since ledger 18851530 has not been included as of ledger 18851605.Additional warnings suppressed.
+```text
+LedgerConsensus:ERR Potential Censorship: Eligible tx E08D6E9754025BA2534A78707605E0601F03ACE063687A0CA1BDDACFCD1698C7, which we are tracking since ledger 18851530 has not been included as of ledger 18851605. Additional warnings suppressed.
 ```


+## シャード: No such file or directory
+
+`rippled` 1.3.1のバグが原因で、[履歴シャーディング](history-sharding.html)を有効にしたときに次のようなログメッセージが書き込まれることがあります。
+
+```text
+ShardStore:ERR shard 1804: No such file or directory
+ShardStore:ERR shard 354: No such file or directory
+ShardStore:ERR shard 408: No such file or directory
+ShardStore:ERR shard 2927: No such file or directory
+ShardStore:ERR shard 2731: No such file or directory
+ShardStore:ERR shard 2236: No such file or directory
+```
+
+これは、サーバーが新しい履歴シャードの取得を開始しようとしたものの、シャードを格納するための新しいディレクトリーを作成できなかったことを示します。このバグにより、rippled 1.3.1は新しいシャードを取得できません。[修正は近日リリース予定](https://github.com/ripple/rippled/pull/3014)です。
+
+このエラーは、上記のバグのほかに、`rippled`が**起動後**に基となるファイルシステムに書き込めなくなった場合にも起こります。考えられる原因は次のとおりです。
+
+- ストレージメディアのハードウェア障害
+- ファイルシステムがアンマウントされた
+- シャードフォルダーが削除された
+
+**ヒント:** 一般的に、サービスが停止している場合は、`rippled`のデータベースファイルを削除しても安全ですが、サーバーの稼働中には決してデータベースファイルを削除しないでください。
+
+
+## Unable to determine hash of ancestor
+
+以下のようなログメッセージは、サーバーがピアからの検証メッセージを認識するけれども、サーバーが基盤としている親レジャーバージョンを認識しない場合に発生します。これは、サーバーがネットワークの他の部分と同期していない場合に発生することがあります。
+
+```text
+2018-Aug-28 22:56:22.256065549 Validations:WRN Unable to determine hash of ancestor seq=3 from ledger hash=00B1E512EF558F2FD9A0A6C263B3D922297F26A55AEB56A009341A22895B516E seq=12133675
+```
+
+{% include '_snippets/unsynced_warning_logs.md' %}
+<!--_ -->
+
+
+## View of consensus changed during open
+
+以下のようなログメッセージが出力される場合は、サーバーがネットワークの他の部分と同期していません。
+
+```text
+2018-Aug-28 22:56:22.368460130 LedgerConsensus:WRN View of consensus changed during open status=open,  mode=proposing
+2018-Aug-28 22:56:22.368468202 LedgerConsensus:WRN 96A8DF9ECF5E9D087BAE9DDDE38C197D3C1C6FB842C7BB770F8929E56CC71661 to 00B1E512EF558F2FD9A0A6C263B3D922297F26A55AEB56A009341A22895B516E
+2018-Aug-28 22:56:22.368499966 LedgerConsensus:WRN {"accepted":true,"account_hash":"89A821400087101F1BF2D2B912C6A9F2788CC715590E8FA5710F2D10BF5E3C03","close_flags":0,"close_time":588812130,"close_time_human":"2018-Aug-28 22:55:30.000000000","close_time_resolution":30,"closed":true,"hash":"96A8DF9ECF5E9D087BAE9DDDE38C197D3C1C6FB842C7BB770F8929E56CC71661","ledger_hash":"96A8DF9ECF5E9D087BAE9DDDE38C197D3C1C6FB842C7BB770F8929E56CC71661","ledger_index":"3","parent_close_time":588812070,"parent_hash":"5F5CB224644F080BC8E1CC10E126D62E9D7F9BE1C64AD0565881E99E3F64688A","seqNum":"3","totalCoins":"100000000000000000","total_coins":"100000000000000000","transaction_hash":"0000000000000000000000000000000000000000000000000000000000000000"}
+```
+
+{% include '_snippets/unsynced_warning_logs.md' %}
+<!--_ -->
+
+
+## We are not running on the consensus ledger
+
+```text
+NetworkOPs:WRN We are not running on the consensus ledger
+```
+
+{% include '_snippets/unsynced_warning_logs.md' %}
+<!--_ -->
+
+
+## 関連項目
+
+- **コンセプト:**
+    - [`rippled`サーバー](the-rippled-server.html)
+    - [技術に関するよくある質問](technical-faq.html)
+- **チュートリアル:**
+    - [問題の診断](diagnosing-problems.html)
+    - [容量の計画](capacity-planning.html)
+- **リファレンス:**
+    - [rippled APIリファレンス](rippled-api.html)
+      - [`rippled`コマンドラインの使用](commandline-usage.html)
+      - [server_infoメソッド][]
+
 <!--{# common link defs #}-->
 {% include '_snippets/rippled-api-links.md' %}
 {% include '_snippets/tx-type-links.md' %}