---
title: "階層的決定性（HD）ウォレット"
description: "HDウォレットが一つのシードから鍵のツリーを導出する仕組み、強化導出と通常導出の違い、完全で検証可能なウォレットバックアップに必要な情報を解説します。"
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.
# 階層的決定性（HD）ウォレット
> 教育目的の情報であり、投資助言ではありません。投資により損失が生じる可能性があります。
## 端的な答え
階層的決定性（HD）ウォレットは、一つのルートシードから再現可能な暗号鍵ペアのツリーを導出します。BIP-32は鍵ツリーの仕組みを定義しています。各ノードは、鍵と`32-byte`のチェーンコードを含む拡張鍵であり、各子ノードはインデックスによって選択されます。同じルート素材、導出規則、パスを使えば、同じ子鍵を再現できます。
「決定性」はバックアップを実用的にしますが、すべてのウォレットに互換性を持たせるものではありません。ニーモニックフレーズは、エントロピーを符号化してシードを生成する方法の一つです。一方、導出パスはノードを選び、アドレスまたはスクリプトの規則がその公開鍵をチェーンの認識できる形式に変換します。パスフレーズ、パス、ネットワーク、スクリプト形式、アカウント探索規則が異なると、単語だけを復元しても空のウォレットが表示されることがあります。
「階層的」とは、権限をサブツリーごとに分割できるという意味です。アカウントレベルの拡張公開鍵があれば、監視専用サービスは支出用の鍵を持たずに通常導出の子孫公開鍵を生成できます。拡張秘密鍵は対応する秘密鍵のサブツリーを導出できるため、一つのアドレスではなく、一群の秘密鍵と同じように保護する必要があります。
HDウォレットは鍵管理の設計であり、オンチェーンのウォレットオブジェクトではありません。ブロックチェーンはニーモニック、シード、パス、ラベル、バックアップを保存しません。これらはウォレットソフトウェアと利用者が管理するオフチェーンの記録です。
## 仕組み
### 1. エントロピーからルートまで
BIP-39はBIP-32の前段で広く使われていますが、両者は別々の規格です。BIP-39は`128-256 bits`のエントロピーとチェックサムを`12-24 words`として符号化し、正規化したニーモニックと任意のパスフレーズに対してPBKDF2-HMAC-SHA512を`2048`回反復し、`512-bit`のシードを生成します。どのパスフレーズも有効でありながら異なるシードを生成するため、パスフレーズの欠落や入力ミスが「パスワードが無効」というメッセージで確実に検出されるわけではありません。
BIP-32は、`Bitcoin seed`を鍵とするHMAC-SHA512を使って、シードのバイト列からマスター秘密鍵とマスターチェーンコードを生成します。このルート拡張秘密鍵がBIP-32ツリーの起点です。すべての決定性ウォレットがBIP-39やBIP-32を使うわけではないため、復元時にはリカバリーワードの存在から推測するのではなく、実際の方式を特定しなければなりません。
### 2. 拡張鍵と子鍵の導出
BIP-32の拡張秘密鍵は秘密鍵とチェーンコードを組み合わせたものです。秘密鍵情報を除いた拡張公開鍵は、対応する公開鍵と同じチェーンコードを組み合わせたものです。通常の子鍵導出では、親公開鍵、チェーンコード、子インデックスを使うため、拡張公開鍵から通常の子公開鍵を導出できます。ただし、子秘密鍵は導出できません。
強化された子ノードは`2^31`から`2^32 - 1`までのインデックスを使い、親秘密鍵の情報を計算に組み込みます。そのため、親拡張公開鍵からは導出できません。パスでは通常、`m/84'/0'/0'`のようにアポストロフィで強化ノードを示します。強化導出は、BIP-32特有の次の問題による被害を抑えます。親拡張公開鍵と、それに対応する非強化子秘密鍵が一つあれば、親拡張秘密鍵が漏えいする可能性があります。
### 3. パスが鍵ツリーに意味を与える
BIP-44は`m / purpose' / coin_type' / account' / change / address_index`を定義しています。最初の`3`階層は強化され、`change`と`address_index`は通常導出です。そのため、アカウント公開鍵から受取用アドレスとお釣り用アドレスを生成できます。慣例では、ブランチ`0`が外部用、ブランチ`1`が内部のお釣り用です。BIP-44の探索では取引履歴を走査し、未使用の外部アドレスが連続`20`個に達することをギャップリミットとします。
パスはメタデータであり、秘密でも普遍的な保証でもありません。BIP-84は、ネイティブSegWit P2WPKHアカウントに用途`84'`を割り当てています。別の用途やウォレット固有の配置では、別のサブツリーが生成されます。コインタイプは名前空間の慣例であり、ブロックチェーンが強制する規則ではありません。
### 4. 鍵だけではウォレット全体を表せない
公開鍵には、さらにネットワークとアドレスまたはスクリプトの規則が必要です。Bitcoinでは同じ鍵を異なる出力スクリプトで使用でき、マルチシグウォレットにはしきい値、共同署名者の鍵、鍵の順序、導出元も必要です。BIP-380の出力ディスクリプターは、鍵とその導出元を明示的なスクリプト式に結び付け、チェックサムを含めることもできます。このため、シードだけのバックアップでは、元のウォレットが監視または支出できた内容を再構築できない場合があります。
ウォレットのラベル、連絡先、取引メモ、インポートした鍵、アカウント名、一部のコントラクトやスマートアカウントの復旧設定は、通常は決定的に導出できません。個別にエクスポートまたは記録する必要があります。
### 5. バックアップと復元は検証を伴うプロセス
ウォレットの実装、ニーモニックまたはシードの形式、パスフレーズの有無、マスターフィンガープリント、関連するパス、ネットワーク、アカウントインデックス、Bitcoinディスクリプターまたは同等のポリシーデータを記録します。可能であれば、ルートの秘密情報をオフラインに保ち、公開可能な復元用メタデータとは分けて保管します。`xpub`だけで支出はできませんが、残高、アドレス同士の関係、将来の通常導出アドレスを漏らす可能性があります。
バックアップを頼りにする前に、信頼できる環境で復元をテストします。まず資金を動かさずに既知のアドレスやディスクリプターと照合し、その後、受取用とお釣り用の両ブランチ、後続のアカウント、取引履歴を確認し、管理された少額取引で署名を検証します。信頼できないウェブサイトやサポートチャットに、ニーモニック、パスフレーズ、`xprv`を入力してはいけません。
## 例
`m/84'/0'/0'`にあるBitcoinのネイティブSegWitアカウントを考えます。用途`84'`はBIP-84の規則を、`0'`はBitcoinのコインタイプ名前空間を選び、最後の`0'`は最初のアカウントを選びます。監視専用システムはアカウント拡張公開鍵を受け取り、アカウント秘密鍵を受け取ることなく通常ブランチを導出できます。
最初の外部受取鍵は`m/84'/0'/0'/0/0`、次は`m/84'/0'/0'/0/1`にあります。最初の内部お釣り鍵は`m/84'/0'/0'/1/0`にあります。いずれも同じアカウントから派生しますが、ブランチとインデックスによって別の鍵が選ばれます。同じシードを`m/44'/0'/0'/0/0`で使うと、別のサブツリーと別の出力規則が選ばれます。結果が空でも、シードが間違っているとは限りません。
完全なBitcoin復元記録を作るには、ルート秘密情報のバックアップを、フィンガープリント、パス、拡張公開鍵、スクリプト形式、チェックサムを示すディスクリプターまたは同等のメタデータとは分けて保管します。両ブランチで過去に使用した複数のアドレスを確認してください。最初の受取アドレスだけが見つかったとしても、それは一つの正しいリーフを示す証拠にすぎず、すべてのアカウント、お釣り出力、ウォレットポリシーが復元された証明にはなりません。
## リスク
- **単一ルートへの集中：** ルートシードや十分に上位の拡張秘密鍵が侵害されると、その範囲のすべての子孫が漏えいする可能性があります。
- **バックアップの紛失：** 唯一のシードバックアップ、または別に管理していた未記録のBIP-39パスフレーズを失うと、すべての派生鍵を復元できなくなる可能性があります。
- **パスフレーズへの誤った安心感：** 誤ったBIP-39パスフレーズは、別の有効なウォレットを作ります。そのため、復元に成功したものの空だったように見える場合があります。
- **パスまたはスクリプトの不一致：** 正しいシードでも、用途、アカウント、ブランチ、ネットワーク、出力形式が間違っていれば、有効ではあるものの無関係なアドレスが生成されます。
- **ポリシーの不完全なバックアップ：** シードとパスだけでは、マルチシグ、ディスクリプター、スマートアカウント、ウォレット固有の支出条件を再構築できない場合があります。
- **拡張公開鍵によるプライバシー漏えい：** `xpub`は一群の関連アドレスを明らかにし、通常導出の子孫を継続的に追跡できるようにする可能性があります。
- **BIP-32の親鍵侵害：** 親`xpub`と、漏えいした対応する非強化子秘密鍵があれば、親秘密鍵のサブツリーが漏えいする可能性があります。
- **信頼できない復元ツール：** ウェブサイト、拡張機能、偽造端末、クリップボードツール、画面共有によって、ルート秘密情報全体が盗まれる可能性があります。
- **未検証の保存媒体：** 紙、金属、暗号化ファイル、ハードウェアバックアップは、転記ミス、腐食、パスワード忘れ、非対応形式によって使えなくなることがあります。
- **不完全な移行：** 表示されているコインだけを移し、トークン、お釣り出力、コントラクトの役割、承認、後続アカウントを古いルートの下に残すと、リスクも残ります。
## よくある誤解
### 一つのバックアップフレーズにウォレットのすべての情報が含まれますか？
いいえ。ルート鍵の素材は再現できても、パスフレーズ、導出規則、ネットワーク、スクリプト、マルチシグポリシー、ラベル、インポートした鍵、アカウント探索履歴までは含まれない場合があります。実際のウォレットに必要なメタデータを保存してください。
### `xpub`は支出できないので公開しても安全ですか？
いいえ。通常は署名できませんが、過去と将来の通常導出アドレス、およびそれらをまとめた履歴を明らかにする可能性があります。上記のBIP-32の問題では、対応する非強化子秘密鍵と組み合わせると、親サブツリーも侵害される可能性があります。
### 新しいアドレスを作ると、独立したバックアップも作られますか？
いいえ。新しいアドレスはアドレスの再利用を減らし、プライバシーを高めますが、決定的に導出された子孫は同じ祖先の管理下にあります。支払いごとに新しいアドレスを使っていても、ルートが侵害されればサブツリー全体に影響します。
### 見覚えのあるアドレスを一つ復元できれば、ウォレット全体の復元を確認できますか？
いいえ。確認できるのは、ルート素材、パス、アドレス構築の一つの組み合わせだけです。復元では、受取用とお釣り用のブランチ、使用したすべてのアカウント、スクリプトまたはポリシー、関連ネットワークを網羅する必要があります。
## 関連トピック
- [ウォレットの導出パス](/ja/crypto/derivation-path/)
- [シードフレーズ](/ja/crypto/seed-phrase/)
- [公開鍵と秘密鍵](/ja/crypto/public-private-key/)
- [ハードウェアウォレット](/ja/crypto/hardware-wallet/)
- [コールドウォレット](/ja/crypto/cold-wallet/)
## 出典
- [BIP 32：階層的決定性ウォレット](https://bips.dev/32/) - Bitcoin Improvement Proposals（参照日：2026-08-20）
- [BIP 39：決定性鍵を生成するためのニーモニックコード](https://bips.dev/39/) - Bitcoin Improvement Proposals（参照日：2026-08-20）
- [BIP 44：複数アカウントの階層構造](https://bips.dev/44/) - Bitcoin Improvement Proposals（参照日：2026-08-20）
- [BIP 84：P2WPKHアカウントの導出方式](https://bips.dev/84/) - Bitcoin Improvement Proposals（参照日：2026-08-20）
- [BIP 380：出力スクリプトディスクリプターの一般的な処理](https://bips.dev/380/) - Bitcoin Improvement Proposals（参照日：2026-08-20）
Source: https://wiki.fcontext.com/ja/crypto/hd-wallet/index.mdx