暗号資産セルフカストディのインシデント対応・監視・相続準備

セルフカストディの安全性は平常運用だけでは測れない。本記事はハードウェアウォレット中心の自己管理において、デバイス調達時点の真正性確認から、監視、ログ規律、インシデント判断、資産移行、記録、そして所有者の不在時に備えた引継ぎ設計までを扱う「有事対応」の層を体系化する。アカウント設計・保守カデンス(tech-391)、送金実行手順(tech-392)、ウォレット種別・鍵管理の基礎(tech-238)を前提とし、本記事ではそれらの手順を「いつ・なぜ発動するか」を判断するレイヤーを扱う。情報カットオフ ~2025-08、confidence: medium 固定(ユーザー提供のリサーチノートを本セッションで統合したもので、2026-08 時点の一次情報の独立検証は未実施)。数値・手順は実務上の目安であり、プロトコル上の制限や保証、法的助言ではない。

正規デバイスの調達と初期化

ハードウェアウォレットは公式ストアまたは正規販売代理店からのみ購入する。フリマサイトや非正規の中古流通は改ざんリスクを排除できないため避ける。

初回起動時にはベンダー提供の真正性確認(genuine check)フローを必ず実行する。特に重要な原則として、PIN があらかじめ設定されている、またはシードフレーズがあらかじめ書き込まれた状態で届いたデバイスは、いかなる理由があっても使用してはならない。シードはユーザー自身がデバイス上でオンデバイス生成したものに限る。事前設定済みの PIN・シードは、出荷経路のどこかで第三者がシードを把握している可能性を意味し、真正性確認の合否に関わらず信頼できない。

PIN は他サービスで使い回さず、誕生日や連番などの推測されやすいパターンも避ける。シードのバックアップ(紙または金属プレート)はデバイス本体と物理的に別の場所に保管する(基本原則は tech-391 と同じだが、ここでは調達・初期化という「入口」の統制に焦点を当てる)。

ファームウェア・アプリのアップデート運用

ファームウェアとウォレットソフトウェアは公式チャネルからのみ更新し、更新自体は定期的に確認する。ただし、ファームウェア・ウォレットアプリ・ホスト OS の大型アップデートを、大口送金の直前にまとめて実施しない。複数のコンポーネントを同時に更新すると、送金直前に予期しない不具合や挙動変化が起きた際の切り分けが難しくなるためである(tech-392 の「大口送金の直前は避ける」と同趣旨だが、ここでは複数レイヤーをまとめて更新することの危険性を明示する)。更新後は、本番の大口送金・統合の前に必ず少額のテスト送金を行い、署名・着金・手数料計算が想定どおり機能することを確認する。

ウォッチオンリー監視とプライバシーのトレードオフ

残高・UTXO 状況の監視には、ウォッチオンリーウォレット(秘密鍵を持たず xpub や公開アドレスのみで残高を追跡)やローカルフルノードを使う方法と、公開ブロックエクスプローラーの API を使う方法がある。

同一の IP アドレスから同一の xpub やアドレス群を繰り返し公開エクスプローラーに問い合わせると、その問い合わせパターン自体から第三者がアカウント同士の関連性を推測できる可能性がある。プライバシー要件が高い場合は、xpub を外部エクスプローラーに一切渡さず、ローカルフルノードで完結させるか、外部への問い合わせを個別の txid 単位のルックアップに限定するのが望ましい。

いずれの方法であっても単一の監視ソースだけを信頼しない。ウォレットソフトウェア・ローカルノード・ブロックエクスプローラーのうち、少なくとも 2 系統以上を突き合わせて残高・UTXO 状態を相互確認する運用が、表示バグ・同期遅延・フィッシングサイトの偽表示などを早期に検知するうえで有効である。

ログ・証跡管理の作法

長時間あるいはリスクの高い署名セッションを始める前に、以下を記録しておく(tech-392 で扱った送金前チェックリストの延長として、より「有事対応の証拠保全」に主眼を置く)。

• タイムスタンプとタイムゾーン
• ウォレットソフトウェア/アプリのバージョン、デバイス機種、ファームウェアバージョン、コインアプリのバージョン
• 対象チェーン・アカウント種別
• 送金予定額、選択した UTXO の txid 一覧
• 各 UTXO の親トランザクションのインプット/アウトプット数
• 設定した手数料率(fee rate)
• 接続方式(ホストへの直結か、ハブ等を経由するか)

セッションが停止したように見える、または挙動が疑わしい場合、まずアプリを再起動・強制終了してはならない。多くのウォレットアプリは再起動でそのセッションのログを失う。先にアプリ自身のログ/設定メニューからログをエクスポートし、APDU 通信やアプリ内ログの行が継続的に進行しているかを確認する。進行が続いていれば処理継続中の可能性が高く、完全に停止していることを確認できた場合に限りキャンセルし、より少ない UTXO 数で再試行する。

ログには xpub・アドレス・アカウント ID など機微な情報が含まれうる。サポートフォーラムや外部のコミュニティにログを共有する必要が生じた場合は、共有前に必ずこれらの識別子をスクラブ(削除・マスキング)する。

インシデント判断のトリアージ

以下は、代表的な 4 つの有事シナリオに対する「何を確認し、どの順で判断するか」の枠組みである。実際の送金・移行操作の機械的な手順は tech-392 に委譲し、ここでは判断の骨格を示す。

シード・鍵の露出が疑われる場合: シードやリカバリーフレーズがオンライン接続のあるデバイス(スマートフォン・PC)に一度でも入力・表示・スクリーンショットされた、クラウドに同期された、あるいはフィッシングサイトに入力してしまった可能性がある場合は、「大丈夫かもしれない」を挟まず直ちに全面侵害として扱う。トークン承認(allowance)の悪用のみが疑われシード自体の露出がないと確信できる場合に限り、該当承認の取り消し(revoke)のみで完結することもあるが、シードが少しでも露出した可能性があれば承認取り消しだけでは不十分で、新しいシードへの全面移行が必要になる。

デバイスの紛失・盗難: 端末がロック状態(PIN 保護)であったか、PIN やシードへのアクセスを許す形跡(メモを同封していた等)がなかったかを確認する。ロックが保たれアクセス経路を排除できると判断できる場合と、それが確信できない場合とで緊急度は異なるが、確信が持てない場合は「シード・鍵の露出が疑われる場合」と同様に扱う。

宛先誤り・誤送金: まず該当 txid を独立した 2 つ以上のブロックエクスプローラーで確認する。確定済みか、ブロードキャスト済みで未確定(mempool 内)かを判定する——未確定であれば RBF(Replace-By-Fee)による再送・手数料引き上げでの是正が間に合う可能性がある。次に、送金先が自分の管理下にある別アドレス(セルフトランスファー)か真に外部の第三者アドレスかを確認する。オンチェーンでの取消しは一般に不可能である前提のもと、それでも txid・タイムスタンプ・送金額・宛先の性質を記録として残す。

署名セッションの停滞・挙動不審: 「ログ・証跡管理の作法」節の手順に従い、まずログをエクスポートしてから停止の真偽を判断する。真の停止を確認できた場合のみキャンセルし、UTXO 数を減らして再試行する。

インシデント下での資産移行

シード・鍵の露出、あるいはデバイス紛失・盗難で「侵害されたもの」として扱うと判断した場合の移行方針は次のとおりである(実行の機械的な手順は tech-391・tech-392 に譲り、ここでは判断上の優先順位を扱う)。

1. 疑わしいデバイスをネットワークから隔離する。
2. 新品または工場出荷状態にリセットした別の正規デバイス上で、新しいシードをオンデバイス生成する。旧シードを「まだ大丈夫かもしれない」と復元して使い続けない。
3. 資産の移行は流動性の高いものから優先する。UTXO チェーンでは署名が重い(親トランザクションが大きい)UTXO も対象に含め、手数料最適化より移行の緊急性を優先し、複数バッチに分けて相応に高い手数料で実施する。
4. EVM チェーンでは、侵害アドレスを監視する自動化された「スイーパー」ボットの存在を前提に動く。ガス補給の瞬間にそのガスごと即座に奪われる場合があるため、送金トランザクションを事前準備し、補給から送金までの時間を最小化する。nonce 順序・ガス・トークン承認・ステーキング/ロック状態も事前確認する。
5. オンチェーン移行と並行して、取引所の API キー・ログインメール・2FA をローテーションする(オンチェーン対応の完了を待たず並行して進める)。
6. すべての移行と着金確認が完了して初めて旧デバイスを初期化・廃棄する。

連絡先とインシデント記録

インシデント対応中およびその後に、次を保存・記録しておく。

• 関連する txid、発生・対応の各段階のタイムスタンプ
• 画面・アプリのスクリーンショット
• デバイス/アプリのログ(「ログ・証跡管理の作法」節でスクラブ済みのもの)
• 取引所・カウンターパーティへの連絡内容と、それに対する回答

これらの記録は、事後の税務・法的な説明(自己資産の移転、盗難・詐欺被害であったことなど)を裏付ける資料として必要になる場合がある(一般的な記録管理・税務の考え方は tech-252 を参照)。ただし盗難・誤送金・相続に関する日本国内の税務・法律上の取り扱いは事案ごとに個別性が高く、本記事の記述は一般的な整理にとどまる。税務・法律上の助言ではなく、実際の対応では当該時点の公式ガイダンスおよび税理士・弁護士等の専門家に確認すること。

最低限のインシデント記録テンプレートとして、以下の項目を用意しておくと後の説明が容易になる。

相続・引継ぎ設計

セルフカストディの相続・引継ぎは、tech-391・tech-392 が扱ってこなかった領域であり、本記事で新たに扱う。ここには構造的な緊張がある。セルフカストディの安全原則は「シードをオンライン接続のあるデバイスや単一の平文ドキュメントに一切触れさせない」ことを求める一方、相続・引継ぎは「所有者が対応できなくなった場合に、信頼できる後継者が単独で復旧できる」ことを求める。この 2 つの要求は正面から衝突するため、単純に「シードを紙に書いて金庫に入れ、鍵の在り処を家族に伝える」だけでは、平常時のセキュリティホール(単一障害点かつ単一の窃取対象)を作ってしまう。

サーベイレベルで検討に値するアプローチを挙げる。

• マルチシグ(multisig): 単一のシードではなく、あらかじめ定義された署名者集合としきい値(例: 3-of-5)で構成する。所有者本人が単独で使える署名鍵の数をしきい値未満に保てば、単一の鍵の紛失・露出だけでは資産にアクセスできない設計にできる。後継者に一部の署名権限を持たせておくことで、所有者不在時の復旧経路を作れる。
• Shamir’s Secret Sharing / 分割バックアップ: シードを複数のシェアに分割し、あらかじめ定めたしきい値(例: 5 分割中 3 つ揃えば復元可能)を満たしたときにのみ復元できるようにする。各シェアを異なる信頼できる関係者・保管場所に分散させることで、単一の関係者・場所の侵害だけでは復元できない構成にできる。
• アクセス制御された「索引」ドキュメント: シードやシェア自体を書かず、「誰が何を保持しているか」「復旧手順がどこにあるか」「誰が復旧を実行する権限を持つか」だけを記した、それ自体はベアラー資産(読んだ者がそのまま資産にアクセスできてしまう情報)ではないドキュメントをアクセス制御して用意する。ドキュメント自体の露出が直接の資産喪失につながらない設計が要点である。
• 後継者の明示的な指定と発動条件: 誰が正当な後継者か、どのような状況(死亡・長期の意識不明等)で復旧プロセスが発動するかを明示する。発動条件の法的な実効性(遺言・信託等の法的手続きとの整合)は法域によって大きく異なり本記事の範囲外である。相続・信託の具体的な法的手続きは、必ず当該法域の専門家(弁護士・司法書士・税理士等)に相談すること。

いずれのアプローチでも「復旧可能性を高める設計変更は平常時の攻撃対象領域も広げうる」というトレードオフを踏まえ、しきい値・シェアの保管場所・後継者の人数は最小限に留める。相続・引継ぎ設計自体もタイムスタンプ・変更履歴を残し、定期的に(tech-391 のバックアップ復元検証と同様のタイミングで)有効性を確認することが望ましい。

チェックリスト

デバイス調達・初期化時:

• 公式ストア/正規代理店から購入したか
• ベンダーの真正性確認フローを実行したか
• PIN・シードが事前設定された状態で届いていないか確認したか
• シードをデバイス上でオンデバイス生成したか

監視・平常運用:

• 残高・UTXO を 2 系統以上のソースで相互確認しているか
• 外部エクスプローラーへの xpub 提供やクエリ頻度がプライバシー要件と整合しているか
• 大口送金の直前にファームウェア/アプリ/OS をまとめて更新していないか

インシデント発生時:

• ログをエクスポートしてから対応を判断したか(先にアプリを再起動していないか)
• シード露出の可能性がある場合、承認取り消しのみで済ませず全面移行を検討したか
• 誤送金の場合、2 系統以上のエクスプローラーで txid を確認したか
• 取引所 API キー・ログインメール・2FA のローテーションをオンチェーン対応と並行して進めたか
• txid・タイムスタンプ・スクリーンショット・ログを記録として保存したか

相続・引継ぎ設計:

• シード全体を単一の平文ドキュメントに残していないか
• マルチシグまたは分割バックアップのしきい値を定義したか
• 索引ドキュメント自体がベアラー資産になっていないか
• 後継者と発動条件を明示し、法域の専門家に確認したか

本記事の判断枠組みは、tech-391 のアカウント設計・保守カデンス、tech-392 の実行手順と組み合わせて機能する——両記事が「平常時にどう設計・運用するか」を扱うのに対し、本記事は「有事にどう気づき、どう判断し、何を残すか」を扱う。