---
title: "コールドウォレット：オフライン署名、復旧、運用管理"
description: "キージェネレーション、ウォレットの識別、バックアップ、トランザクションの確認、オフライン署名、マルチシグ、リカバリー、インシデント対応におけるコールドウォレットのカストディの設計と検証方法を学びます。"
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.
# コールドウォレット：オフライン署名、復旧、運用管理
> 教育目的のみ；投資の助言ではありません。投資は損失を招く可能性があります。
## 直接の答え
コールドウォレットとは、秘密の署名用材料と決定的な承認手続きを、インターネット接続されたソフトウェアの通常の露出範囲の外に保持する管理システムです。資産はブロックチェーン上に留まります。システムは、状態変更を承認できる鍵やその他の権限を制御します。「コールドウォレット」は運用上のラベルであり、プロトコルで定義されたデバイスクラスではなく、コールドであることはブランドや接続タイプではなく、ワークフロー全体の性質です。
ハードウェアサイナーは、プライベートキーが隔離されたままである可能性があるため、USBで接続されていてもコールドストレージをサポートできます。しかし、ユーザーが未検証の宛先や不透明なコントラクト呼び出しに署名する場合、ワークフローは安全ではありません。逆に、エアギャップコンピュータは、ネットワークインターフェースがないだけでは安全ではありません：侵害されたエントロピー、インストールメディア、トランザクションパーサ、リムーバブルメディア、バックアップ、またはディスプレイによっても境界が破られる可能性があります。コールドストレージはリモートでのキー抽出リスクを低減しますが、トランザクションの意図、ソフトウェアの正確性、リカバリ、プライバシー、または最終性を証明するものではありません。
復旧用コピーは「単なるバックアップ」ではありません。ニーモニックフレーズ、元のシード、拡張秘密鍵、または同等の復旧用シェアは支出権限を再作成できるため、署名デバイスと同等の保護が必要です。想定したアドレスを復元するには、パスフレーズ、導出パス、ネットワーク、スクリプト種別、ウォレットディスクリプター、鍵順序、しきい値ポリシーも必要な場合があります。公開情報だけを持つウォッチオンリーウォレットは通常署名できませんが、`xpub`やディスクリプターはアドレスの関連性や取引履歴を明らかにします。また、BIP-32の拡張公開鍵は通常の公開鍵より慎重に扱う必要があります。
## コールドストレージの設計と検証方法
### 1. 権限と脅威モデルを定義する
ネットワーク、資産、アカウントまたは出力ポリシー、所有者、受益者、回収権限、予想される取引頻度、および最大運用リスクを正確に記録してください。リモートマルウェア、悪意のあるアプリケーション、サプライチェーンの侵害、内部者の共謀、物理的窃盗、強制、火災、洪水、損失、無力、相続を別々の脅威として特定します。何を冷静に保つべきかを決めます:単一の秘密鍵、閾値内のすべての鍵、署名者の定足数、EIP-712認証鍵、またはウォレットコードを変更できる管理者。
### 2. 信頼できるエントロピーとソフトウェアを初期化する
デバイスやソフトウェアは認証されたチャネルを通じて入手し、初期化状態を検査し、サポートされている場合はリリースを確認し、パッケージ内や補助者から提供された事前生成のニーモニックフレーズや秘密は拒否してください。制御された環境でエントロピーを生成し、どの標準と実装がそれを作成したかを記録してください。BIP-39 は `128` から `256` ビットのエントロピーをニーモニックフレーズとしてエンコードし、ニーモニックフレーズとオプションのパスフレーズから `512-bit` シードを導出します；これは記憶に残る文章を安全なウォレットに変換するための標準ではありません。
### 3. 再現可能なウォレット識別情報を固定する
十分な資金を投入する前に、ネットワーク、マスターフィンガープリント、導出標準と完全なパス、アカウントインデックス、アドレスまたはスクリプトタイプ、そして最初に確認済みの受信アドレスを記録してください。Bitcoinポリシーの場合は、出力ディスクリプタ、チェックサム、キーオリジン、しきい値、署名者数、キーの順序、および変更ブランチを保存してください。各署名者について、そのキーおよび表示されているポリシーが意図したものであることを独立して確認してください。`xpub`は機密メタデータとして扱ってください：非ハード化公開子を導出でき、プライバシーを損なう可能性があり、対応する非ハード化子秘密鍵と組み合わせると、BIP-32下で親の拡張秘密鍵を露出させる可能性があります。
### 4. バックアップと復旧をテストする
ニーモニックフレーズやシェア、オプションのパスフレーズ、ディスクリプタやスマートアカウントの設定、導出パス、リカバリ手順を含む、すべての必要なリカバリ入力を保護してください。ニーモニックフレーズの単語を即席の断片に分割してスキームを作成しないでください。単一のコピーでは十分でない場合は、指定された閾値やマルチシグ設計を使用してください。コピーは真に独立した障害ドメインに配置し、内容を公開せずにアクセスを追跡してください。信頼できる予備機や再初期化したサイナーで、復元をリハーサルし、テスト環境を消去する前に、予想されるフィンガープリント、ポリシー、受信アドレスと比較してください。
### 5. 完全な署名意図を構築して検証する
オンラインコーディネーターはチェーンの状態を取得し、署名されていないリクエストを作成することができますが、信頼できるわけではありません。Bitcoin `PSBT`の場合、ネットワーク、すべての入力とUTXO額、受信者の出力、金額、手数料、手数料率、ロックタイム、シグネチャハッシュポリシー、および他のすべての出力が認証済みの変更であるかどうかを検証してください。EVMトランザクションの場合、`chainId`、`nonce`、`to`、`value`、ガスリミット、手数料上限、そしてデコードされた`data`を検証してください。EIP-712の場合、ドメイン、`chainId`、`verifyingContract`、メッセージフィールド、適用可能な場合にはノンスおよび締め切りを検証してください。EIP-712はデータを構造化し、ドメインを分離しますが、標準自体は明示的にリプレイ保護を提供していません。
### 6. 管理された転送境界を越えて署名する
必要な未署名または部分的に署名されたペイロードのみを、承認されたQR、カード、ケーブル、またはその他のチャネルを通じて移動させてください。エアギャップやQRコードは、パーサーやメディアを信頼できるものにするわけではありません：署名者はペイロードを解析し、ポリシーと変更を認証し、結果の影響を表示し、サポートされていないフィールドを拒否する必要があります。マルチシグの場合は、署名者、オペレーター、場所、ベンダー、およびリカバリパスを脅威モデルに合わせて独立させてください。コーディネーターは交換可能であり、ポリシーを目立たずに変更できないものとして扱ってください。ブロードキャスト前に、署名されたトランザクションまたは操作を承認された意図と比較してください。
### 7. 照合、保守、移行準備を行う
放送後、取引識別子、含まれる取引、出力またはログ、実際の手数料、変更、アカウントノンス、許可、および結果としての残高を署名された意図と照合し、その後チェーンおよびユースケースに適した最終確定を待ちます。互換性のあるソフトウェア、検証済みファームウェアパス、読み取り可能なバックアップ、文書化されたディスクリプタ、および生産用の秘密をオンラインデバイスに入力せずに定期的な復旧演習を維持します。署名または復旧用の秘密が漏洩する可能性がある場合、単純な単一キーアカウントはそのキーを取り消すことができません：新しい権限を確立し、資産と役割を移行し、プロトコルが許す場合には残りの許可を無効化し、インシデント記録を保持します。
## 例題
### 段階的な配分と資金提供
カストディ計画では、オンライン操作用ウォレットの上限を`5%`とします。資産価値の総額が`100,000 units`なら、ホット側は`100,000 × 5% = 5,000 units`、コールド側は`95,000 units`です。コールド宛先にはまず`100-unit`のテスト送金を行い、残額は`95,000 - 100 = 94,900 units`です。両方の送金後のコールド残高目標は`100 + 94,900 = 95,000 units`です。少額テストで検出できるのは一時点の設定ミスに限られ、将来の署名やバックアップ復旧までは検証できません。
### Bitcoin PSBT 手数料と変更
`PSBT`は`0.80 BTC`と`0.35 BTC`の入力を消費し、合計`1.15 BTC`になります。受取人に`1.00 BTC`を支払い、`250 vbytes × 8 sat/vbyte = 2,000 sat = 0.000020 BTC`を見積もります。したがって、認証されたお釣りは`1.15 - 1.00 - 0.000020 = 0.149980 BTC`でなければなりません。署名者が記録されたポリシーからそのお釣りの出力を特定できない場合、合計の算術が釣り合っていても署名すべきではありません。
### EVM 最大予算対実際料金
EVMアカウントは`5 ETH`で始まり、`1.2 ETH`の送金を承認します。`30,000 gas`の制限と`50 gwei`の最大手数料は、`30,000 × 50 gwei = 0.001500 ETH`の手数料予算を意味します。取引で`21,000 gas`を有効価格`25 gwei`で使用する場合、実際の手数料は`21,000 × 25 gwei = 0.000525 ETH`となり、`5 - 1.2 - 0.000525 = 3.799475 ETH`が残ります。署名者は手数料の上限と`data`を確認する必要があり、最大予算が請求されると仮定したり、空に見えるインターフェースが通常の送金を証明すると考えたりしてはいけません。
### 2-of-3署名者構成の耐障害性
`2-of-3` ポリシーは、署名者 `A`、`B`、および `C` を持ち、`3` の有効な署名ペア: `AB`、`AC`、および `BC` があります。もし一人の署名者が利用できない場合、正確に `1` のペアが残ります。一人の署名者が侵害された場合、その署名者だけが `0` の有効なペアを制御します。二人の署名者が侵害された場合、彼らは `1` の有効なペアを制御し、使用できます。したがって、この設計は一人の喪失または一回の孤立した侵害を許容しますが、二回は許容せず、回復には依然として正しいディスクリプタ、派生データ、および鍵の順序が必要です。
## リスクとレビューの失敗
- **ネットワークまたはポリシーの誤り：** 誤ったチェーン、アドレス形式、スクリプト、アカウント、スマートアカウントポリシーで有効な鍵を復元すると、別のアドレスや利用不能なアドレスが表示されます。
- **エントロピー不足：** 予測可能な乱数、ブレインウォレット、侵害された生成器では、オフライン鍵でも推測される可能性があります。
- **第三者が用意した秘密：** 印刷済み、事前インポート済み、撮影済み、または補助者が提供したニーモニックフレーズは、攻撃者の管理下にあるおそれがあります。
- **バックアップ漏えい：** 紙、金属媒体、クラウドコピー、プリンター、カメラ、配送経路、相続資料から完全な支出権限が漏れる可能性があります。
- **パスフレーズ障害：** BIP-39パスフレーズを紛失または誤入力すると、エラーが出ないまま別のウォレットが導出されることがあります。
- **導出設定の不一致：** パス、コイン種別、アカウント番号、ウォレット固有の規則が欠けると、本来復旧できる資産が表示されない場合があります。
- **構成情報の紛失：** マルチシグ鍵だけが残っても、ディスクリプター、しきい値、スクリプト種別、鍵の出所、鍵順序がなければ入金済みウォレットを再現できない場合があります。
- **公開メタデータ漏えい：** `xpub`、ディスクリプター、アドレス一覧、コーディネーターデータベースは、残高、関連性、将来のアドレスを明らかにする可能性があります。
- **サプライチェーン侵害：** 改変されたハードウェア、ファームウェア、ソフトウェア、梱包、更新経路がエントロピー、アドレス、署名を差し替えるおそれがあります。
- **ホストによる差し替え：** オンラインコーディネーターは、受取先、金額、手数料、おつり、calldata、型付きメッセージ、未署名ペイロードを差し替えられます。
- **表示能力の不足：** 省略表示、ブラインド署名、未対応スクリプト、不完全なデコードによって重要な権限が隠れる可能性があります。
- **おつりアドレス攻撃：** 署名デバイスがポリシーに基づいておつりを検証しなければ、Bitcoin取引の偽装おつり出力が攻撃者へ送られる可能性があります。
- **手数料またはnonceの誤り：** 過大な手数料、古いEVM nonce、誤ったロックタイム、意図しないsighashモードは、実行を遅延、置換、変質させる可能性があります。
- **残存するコントラクト権限：** トークン承認、permit、モジュール、委任、管理者呼び出しは、目の前の取引より長く有効な場合があります。
- **転送経路攻撃：** QR、USB、メモリーカード、ケーブル、パーサー形式が悪意あるペイロードやメタデータ流出を運ぶ可能性があります。
- **しきい値の相関：** 署名デバイスの同一場所保管、シード共有、単一ベンダー、単一運用者、単一復旧拠点への依存は、しきい値の独立性を損ないます。
- **物理攻撃：** 盗難、強要、監視、改ざん、秘密の発見は、ネットワーク接続がなくても起こり得ます。
- **環境による喪失：** 火災、洪水、腐食、媒体劣化、金庫へのアクセス不能、死亡、行為能力喪失により、正しい秘密でも利用不能になります。
- **互換性の劣化：** 古いファームウェア、未対応の導出方式やスクリプト種別、未記録の移行は、将来の復旧や署名を妨げる可能性があります。
- **不完全なインシデント対応：** 鍵、役割、承認、復旧権限を移行せず残高だけ確認すると、元の侵害が有効なまま残ります。
## 一般的な誤解
### コールドウォレットは永久に物理的に切断されたままでなければなりませんか？
いいえ。セキュリティの特性は、秘密の権限が孤立したままであり、署名が制御された検証可能な境界を通じて行われることです。ケーブル接続されたハードウェア署名者はその特性を維持できるかもしれません；エアギャップされたコンピュータで、セットアップやペイロードのレビューが侵害されている場合は、維持できないかもしれません。
### コインはハードウェアデバイスの中に保管されていますか？
いいえ。ブロックチェーンの状態は資産を記録します。そのデバイスは取引に署名できる権限を保護または使用し、互換性のあるリカバリ素材は別の実装でその権限を再現することができます。
### ニーモニックフレーズのバックアップは署名デバイスより機密性が低いですか？
いいえ。完全なニーモニックフレーズと必要なパスフレーズでウォレットを再作成できます。バックアップは通常使われていなくても、侵害されれば稼働中の署名鍵を抽出された場合と同じほど重大です。
### マルチシグはバックアップや設定記録の必要性をなくしますか？
いいえ。しきい値は選ばれた単一の障害点を減らしますが、各キーには回復計画が必要であり、ウォレットのポリシーまたはディスクリプタは再現可能でなければなりません。残っているキーが少なすぎたり、構成を失った場合でも資金がロックされる可能性があります。
### 成功したテスト転送は、コールドストレージシステムが安全であることを証明しますか？
いいえ。それは一度に限られた経路を確認するものです。エントロピーの品質、バックアップの秘密性、復元、将来の取引の解読、定足数の独立性、ソフトウェアの更新、契約の安全性、またはインシデントの回復を証明するものではありません。
## 関連するトピック
- [ハードウェアウォレット](/ja/crypto/hardware-wallet/)
- [シードフレーズ](/ja/crypto/seed-phrase/)
- [公開鍵と秘密鍵](/ja/crypto/public-private-key/)
- [マルチシグウォレット](/ja/crypto/multisig-wallet/)
- [取引シミュレーション](/ja/crypto/transaction-simulation/)
## 情報源
- [ブロックチェーン技術の概要](https://doi.org/10.6028/NIST.IR.8202) - NIST（アクセス日：2026-08-19）
- [BIP 32: 階層型決定論ウォレット](https://bips.dev/32/) - Bitcoin 改善提案（アクセス日: 2026-08-19）
- [BIP 39: 決定論的キーを生成するためのニーモニックフレーズコード](https://bips.dev/39/) - Bitcoin 改善提案（アクセス日: 2026-08-19）
- [BIP 44: 決定論的ウォレットのためのマルチアカウント階層](https://bips.dev/44/) - Bitcoin 改善提案（アクセス日: 2026-08-19）
- [BIP 174: 部分署名済み Bitcoin トランザクション形式](https://bips.dev/174/) - Bitcoin 改善提案（アクセス日: 2026-08-19）
- [BIP 380: 出力スクリプト記述子の一般的な操作](https://bips.dev/380/) - Bitcoin 改善提案（参照日：2026-08-19）
- [BIP 129: Bitcoin セキュアマルチシグ設定](https://bips.dev/129/) - Bitcoin 改善提案（参照日: 2026-08-19）
- [EIP-712: 型付けされた構造化データのハッシュ化と署名](https://eips.ethereum.org/EIPS/eip-712) - Ethereum 改善提案（参照日：2026-08-19）
Source: https://wiki.fcontext.com/ja/crypto/cold-wallet/index.mdx