xrpl-dev-portal/@i18n/ja/concepts/ledgers/ledger-close-times.md

---
html: ledger-close-times.html
parent: ledgers.html
seo:
    description: XRP Ledgerが、レジャーバージョンごとに一意の閉鎖時刻を計算する方法。
labels:
  - ブロックチェーン
---
# レジャーの閉鎖時刻

レジャーバージョンの閉鎖時刻は、[レジャーヘッダー](../../references/protocol/ledger-data/ledger-header.md)の`close_time`フィールドに記録されます。ネットワークの正確な閉鎖時刻についてコンセンサスを得やすくするため、この値は閉鎖時刻の精度に基づく秒数に丸められます(現在は10秒)。丸めによってレジャーの閉鎖時刻が親レジャーの閉鎖時刻と同じになる(または早くなる)場合、子レジャーの閉鎖時刻は親レジャーの閉鎖時刻に1を足した時刻に設定されます。これにより、有効なレジャーの閉鎖時刻が確実に増加することが保証されます。

通常、新しいレジャーバージョンは約3～5秒ごとに閉鎖するため、これらのルールの結果、レジャーの閉鎖時刻は、:00、:01、:02、:10、:11、:20、:21、...で終わるような、あいまいなパターンになります。2で終わることはあまりなく、3で終わることは非常にまれですが、どちらも、より多くのレジャーが10秒の時間内にランダムに閉鎖した場合にランダムに発生します。

一般的に、レジャーは閉鎖時刻よりも正確な時刻計測を行うことはできません。例えば、あるオブジェクトが有効期限を過ぎているかどうかを確認するには、親レジャーの閉鎖時刻と比較するルールになっています。(レジャーの閉鎖時刻は、そのレジャーに登録されるトランザクションの実行時点では確定していません)。これは、例えば[Escrow](../payment-types/escrow.md)が、Escrowオブジェクトで指定された時間ベースの有効期限より最大で約10秒遅い実世界の時刻に終了する可能性があることを意味します。

### 例

以下の例は、バリデータの観点から、レジャーの閉鎖時刻**12:00:00**の丸め動作を示しています。

**現在のコンセンサスラウンド**

1. バリデータは、レジャーが閉鎖してコンセンサスに達したのが**12:00:03**であったことを記録します。バリデータはこの閉鎖時刻を自分の提案に含めます。
2. バリデータは、(そのUNL上の)大多数のバリデータが閉鎖時刻を12:00:02と提案し、 残りのバリデータが閉鎖時刻を12:00:03と提案したことを確認します。そのバリデータは、提案された閉鎖時刻をコンセンサスの**12:00:02**に合わせます。
3. バリデータはこの値を最も近い時間に丸め、**12:00:00** とします。
4. 12:00:00は前のレジャーの閉鎖時刻より大きくないので、バリデータは閉鎖時刻を前のレジャーの閉鎖時刻のちょうど1秒後に調整します。その結果、調整後の閉鎖時刻は **12:00:01** となります。
5. バリデータはこれらの詳細情報を使ってレジャーを作成し、ハッシュを計算します。

検証を行わないサーバは、記録した閉鎖時刻をネットワークの他のサーバに提案しないことを除いて、すべて同じ手順を踏みます。

**次のコンセンサスラウンド**

1. 大多数のバリデータによると、次のレジャーは**12:00:04**にコンセンサスに入ります。
2. 閉鎖時刻は再び切り捨てられ、**12:00:00**となります。
3. これは前のレジャーの閉鎖時刻12:00:01より大きくないため、調整後の閉鎖時刻は**12:00:02**となります。

**その次のコンセンサスラウンド**

1. 大多数のバリデータによると、この次のレジャーは**12:00:05**にコンセンサスに入ります。
2. これは、閉鎖時刻の制度に基づいて、**12:00:10**に切り上げられます。
3. この値は前のレジャーの閉鎖時刻より大きいので、調整する必要はありません。**12:00:10**が正式な閉鎖時刻となります。