---
title: "ハッシュ時間ロック契約（HTLC）"
description: "ハッシュ時間ロック契約では、受取人は期限前にプリイメージを示して支払いを受け取り、支払人は期限後に別の支出経路で払い戻せます。HTLC が決済チャネルとアトミックスワップをどう連携させ、どこで失敗し得るかを解説します。"
image: "https://wiki.fcontext.com/og.png"
---

> Documentation Index
> Fetch the complete documentation index at: https://wiki.fcontext.com/llms.txt
> Use this file to discover all available pages before exploring further.

# ハッシュ時間ロック契約（HTLC）

> 教育目的のみであり、投資、法律、セキュリティ上の助言ではありません。HTLC の安全性は、実際のスクリプトまたはコントラクト、チェーン規則、承認方針、手数料、監視、適時の対応に左右されます。

<a id="answer"></a>

## 直接の答え

ハッシュ時間ロック契約（HTLC）は、競合する二つの支出経路を持つ条件付き支払いです。期限前なら、受取人はハッシュがコミット済みの値 `h = H(x)` と一致する値 `x` を公開し、必要な署名または認可を満たして請求できます。期限後は、支払人が払い戻し経路を使えます。境界での厳密な順序はチェーンとコントラクトが決めるもので、自然言語の「前」だけでは決まりません。

ハッシュロックは動作を連結します。参加者は下流への支払い後に同じプリイメージを知ることで、関連する上流支払いを決済できる場合があります。タイムロックは資金が条件付きである期間を制限します。決済チャネルはこれらの性質で支払いを転送し、アトミックスワップは別々のシステム上の移転を調整できます。

HTLC が自動的にトラストレス、アトミック、非公開、または自動実行になるわけではありません。安全性には、正しいスクリプトやコントラクト、互換性のあるハッシュとプリイメージの符号化、ずらした期限、ファイナリティの前提、手数料へのアクセス、継続監視、期限前の承認も必要です。Lightning の HTLC は仕様化された Bitcoin 設計の一つであり、別チェーンのコントラクトは意味が大きく異なり得ます。

- **ハッシュ分岐：** 経路が有効な間に必要なプリイメージを公開し、成功経路の認可を満たします。
- **タイムアウト分岐：** 適用される絶対または相対ロックの満期後、払い戻し経路の認可を満たします。

<a id="mechanism"></a>

## 仕組み

単一の条件付き支払いで、Bob が新しく予測不能なプリイメージ `x` を選び、`h = H(x)` を計算して `h` を Alice に渡すとします。Alice は `h` にコミットし、認可された当事者と期限 `T` を定める規則で資金をロックします。

- Alice は資金提供前に、ハッシュ方式、バイト符号化、金額、資産、受取人、払い戻し先、チェーン、期限を確認します。
- Bob は取引の下書きや画面表示を信用せず、実際に資金が入った出力またはデプロイ済みコントラクトを確認します。
- Bob が成功分岐で請求する場合は `x` を提示し、支出ロジックが `H(x) = h` と必要な認可を検証します。
- `x` がチェーンで公開されるかプロトコルで伝達されると、Alice または中継者は同じ支払いハッシュを持つ別の HTLC を決済できる場合があります。
- 成功分岐が間に合わなければ、払い戻し分岐は `T` で利用可能になりますが、それだけで払い戻しが配信・承認されるわけではありません。
- 参加者はなお、正しい取引を作成または保持し、十分な手数料を払い、送信し、置換と競合を監視して必要な承認深度を得る必要があります。
- `x` を相手方または公開チェーンへ示した時点で開示済みとみなし、無関係な条件に再利用してはいけません。

Bitcoin は絶対ロックと相対ロックを区別します。BIP 65 の `OP_CHECKLOCKTIMEVERIFY` は取引ロック時間を通じて、指定ブロック高またはブロック時刻まで支出を制限します。BIP 112 の `OP_CHECKSEQUENCEVERIFY` は入力の相対経過時間が十分になるまで支出を制限します。スクリプトには互換性のある取引フィールドも必要です。したがってタイムロックは検証規則であり、スケジューラではありません。

Lightning では `update_add_htlc` が金額、`payment_hash`、`cltv_expiry` を運びます。各中継ホップは対応する受信 HTLC より早く期限切れになる送信 HTLC を提示し、プリイメージ取得後に上流へ請求する時間を確保します。BOLT 3 はコミットメント出力、`HTLC-success`、`HTLC-timeout` の経路と、署名、失効処理、ダスト除外、追加遅延を定義します。二分岐の概略だけでは完全な Lightning チャネル実装になりません。

<a id="example"></a>

## 例

Alice が `1 BTC` と Bob の `20 ETH` を交換する教材上の例を考えます。これは順序だけを示します。本番の Bitcoin と Ethereum の実装にはチェーン固有のレビュー済みコードが必要で、この名目上の期間をそのまま使うべきではありません。

- Alice は新しい `x` と `h = H(x)` を生成し、Bob がプリイメージで請求でき、Alice が `48 hours` 後に払い戻せるよう `1 BTC` をロックします。
- Bob は Bitcoin 取引と選択した承認方針を確認後、互換性のあるハッシュと符号化で `20 ETH` をロックします。Alice の成功経路は `24 hours` 後に終わり、その後 Bob の払い戻し経路が使えます。
- Alice は `x` を公開して `20 ETH` を請求する前に、Ethereum のチェーン ID、コントラクトのバイトコードとアドレス、トークンまたはネイティブ資産、金額、当事者、`h`、両経路を確認します。
- Bob は成功した請求または合意済みプロトコルメッセージから `x` を知り、遅い方の期限前に Bitcoin の成功経路を試します。
- 開示前に交換が止まれば、各払い戻しは各チェーンの規則でのみ利用可能になり、双方が該当取引を送信して承認を得なければなりません。

`48 hours` と `24 hours` の差は対応バッファであり、普遍的に安全な設定ではありません。再編成、ブロック時間の変動、ファイナリティ、コントラクト実行、中継の前提、メンプール方針、手数料急騰、検閲、運用遅延を両システムでモデル化する必要があります。後から動く側は、画面に「承認済み」と出ただけで進めてはいけません。

<a id="risks"></a>

## リスク

- **誤ったコミットメント：** 両レッグでハッシュ方式、プリイメージ長、符号化が異なり、同じ `x` が両方を満たしません。
- **誤った成果物：** 資金提供済み出力、チェーン ID、コントラクトアドレス、バイトコード、資産、金額、受取人、払い戻し先が画面表示と異なります。
- **危険な期限順序：** 同じ期限または不十分な差により、中継者や交換相手が下流へ払った後に上流へ請求できません。
- **境界の誤解：** ブロック高、ブロック時刻、タイムスタンプ、相対経過時間、`<` と `<=` のような比較は同じ意味ではありません。
- **自動払い戻しではない：** 満期は支出を有効にするだけで、ウォレット、ノード、利用者、監視サービスが動く必要があります。
- **手数料とダストの失敗：** 請求が不経済、Lightning コミットメントから除外、低手数料で停止、またはネイティブ手数料資産不足で実行不能になり得ます。
- **承認と再編成のリスク：** 取引やプリイメージが見えても、どちらのチェーンでも不可逆な決済とは限りません。
- **競合と混雑のリスク：** 成功支出、タイムアウト支出、置換、競合、悪意ある遅延が対応時間を奪います。
- **実装リスク：** スクリプト、スマートコントラクト、ウォレット、署名、nonce、RPC、クライアントの欠陥が意図した経路を壊し得ます。
- **監視リスク：** オフラインの参加者は開示、期限、強制閉鎖、置換、実用上最後の配信時点を逃し得ます。
- **プライバシー漏えい：** 再利用した支払いハッシュ、公開プリイメージ、金額、時刻、チャネル事象が送金や経路の関連付けに使われ得ます。
- **選択権と妨害：** 一方は相手の流動性をロックして中止でき、条件付き決済は完了も遅延補償も保証しません。

価値を危険にさらす前に、無視できる金額で成功と払い戻しの両経路を試し、正確な成果物と期限を記録し、手数料を確保して、障害時の監視・配信担当を決めてください。

<a id="misconceptions"></a>

## よくある誤解

- **「期限になると資金は自動で戻る。」** 通常は払い戻し支出が可能になるだけで、誰かが配信し承認を得る必要があります。
- **「`H(x) = h` の一致が契約のすべてだ。」** 署名、スクリプト分岐、取引フィールド、チェーン規則、失効ロジック、認可も重要です。
- **「両レッグを同じ期限にするのが公平だ。」** 中継者や後手側には `x` を知った後の意図的な上流バッファが必要です。
- **「プリイメージが見えれば請求時間は保証される。」** 承認遅延、再編成、混雑、手数料、検閲が残り時間を使い切り得ます。
- **「アトミックとは両チェーンが一つの不可分取引で変わることだ。」** クロスチェーン交換は別々の状態遷移を調整し、中止・払い戻し経路や一時的な片側状態が残ります。
- **「HTLC は匿名で、すべての信頼をなくす。」** 相関情報を漏らし得るうえ、プロトコルコード、チェーン挙動、鍵、監視、運用前提に依存します。

<a id="related"></a>

## 関連トピック

- [暗号学的ハッシュ](/ja/crypto/cryptographic-hash/)
- [MPC ウォレット](/ja/crypto/mpc-wallet/)
- [マルチシグモジュールのリスク](/ja/crypto/multisig-module-risk/)
- [スマートコントラクト](/ja/crypto/smart-contract/)
- [ステートチャネル](/ja/crypto/state-channels/)

<a id="sources"></a>

## 出典

- [BIP 65：OP_CHECKLOCKTIMEVERIFY](https://bips.dev/65/) - Bitcoin Improvement Proposals（参照日：2026-08-20）
- [BIP 112：CHECKSEQUENCEVERIFY](https://bips.dev/112/) - Bitcoin Improvement Proposals（参照日：2026-08-20）
- [BOLT #2：チャネル管理用ピアプロトコル](https://github.com/lightning/bolts/blob/master/02-peer-protocol.md) - Lightning BOLTs（参照日：2026-08-20）
- [BOLT #3：Bitcoin の取引とスクリプト形式](https://github.com/lightning/bolts/blob/master/03-transactions.md) - Lightning BOLTs（参照日：2026-08-20）
- [BOLT #4：オニオンルーティングプロトコル](https://github.com/lightning/bolts/blob/master/04-onion-routing.md) - Lightning BOLTs（参照日：2026-08-20）

Source: https://wiki.fcontext.com/ja/crypto/htlc/index.mdx