Bitcoinを買った後の10ステップ：セルフカストディ検証手順（2026年版）

資金について：CypherpunkGuideは監視型広告を載せていません。広告ネットワーク、トラッキングピクセル、スポンサー記事は使いません。資金源は、現在の読者寄付と、将来の購読・編集方針に沿ったアフィリエイトです。私たちが向き合う相手は、広告主ではなく読者です。

取引所に残高が表示されても、管理権の引き渡しが終わったとは限らない。取引所のステータス画面は、管理事業者が持つ記録である。それとは別に、自分のウォレットが追跡するアドレスへオンチェーンの出力が届いたことを確かめなければならない。ウォレットが持つのは端末の中のコインではなく、取引を承認する鍵だ。第三者管理では事業者が鍵へのアクセスを握り、セルフカストディ（自分で鍵を管理する方式。以下「自己管理」）では自分が握る。ただし、これは技術上の区別にすぎない。法律上の所有権は、事業者の規約と各地の法令によって決まる（SECの投資家向け資料、2025年）。

危ない近道は、数字が見えたところで引き渡しが済んだと思い込むことだ。隔離したBitcoin Core v31.1.0の検証では、資金を入れたウォレットにも、監視専用ウォレットにも、同じ0.01000000 BTCが表示された。だが監視専用側は秘密鍵が無効であり、部分署名Bitcoin取引への署名を求めるとcomplete=falseを返し、直接送金はRPCエラー**-4**で拒否された。正しい残高が見えても、分かるのは観測できるという事実までである。動かせる証拠にはならない。

では、安心させる画面を信用せずに、受領・署名・復旧ができると何で示せばよいのか。この10ステップのセルフカストディ検証は、その証拠を一つずつ作る。自己管理はリスクを消さない。鍵、端末、バックアップ、判断、緊急時の計画を通じて、リスクを自分側へ移すだけだ。

最初の原則：自己管理はリスクの移転である

#

自己管理を選ぶと、事業者に依存するリスクの一部を、自分が直接負う運用責任へ置き換えることになる。取引所への依存は減らせるが、秘密情報を一つ失う、バックアップが壊れる、急いで誤送金するといった失敗が、取り返しのつかない損失にもなりうる。

SECも両面を示している。管理事業者は鍵へのアクセスを握り、その事業者が破綻したり、サービスを停止したりする可能性がある。一方、自己管理を選んだ人は鍵の安全を引き受ける。「今すぐ全額を引き出せ」は、誰にでも当てはまる助言ではない。守れて、復旧できる金額だけを移すべきだ。

証拠にもとづく管理権の引き渡しは、受領、署名権限、復旧可能性の3つが確認できたところで終わる。それでも、自己管理が誰にとっても最善になるわけではない。まだ復旧情報を守れないなら、学んでいるあいだは金額を小さく抑えるべきだ。

受領・署名・復旧は、それぞれ別の証明である

#

受領（Receipt）は、意図したウォレットにBitcoinが届いたことを示す。署名（Signing）は、必要な鍵で取引を承認できることを示す。復旧（Recovery）は、紛失後に独立して復元しても、その署名権限を再現できることを示す。

この3つは、別々に失敗する。取引が承認済みでも、バックアップが壊れていることはある。監視専用ウォレットは、秘密鍵がなくても取引を表示できる。パスフレーズ、ウォレット形式、アカウント、アドレス形式、鍵の導出経路が違えば、シードから復元しても、残高ゼロの別ウォレットが開くことがある。

監視専用ウォレットは、署名鍵を持たずに取引を追跡する。PSBT（partially signed Bitcoin transaction、部分署名Bitcoin取引）を使うと、あるウォレットで取引を準備し、別の端末で署名できる。だが、残高が見えることも、PSBTを準備できることも、署名権限の証明にはならない。

10ステップのセルフカストディ検証

#

以下を順に行い、結果に曖昧さがあれば止めること。受領・署名・復旧のそれぞれについて、ウォレットの目立つ残高表示に頼らず説明できる証拠がそろうまで、残りの資金を移してはいけない。

ステップ1：購入記録を保存し、取引所アカウントを守る

#

購入日、数量、法定通貨での価額、手数料、注文IDを含む購入記録を保存する。後で出金記録と取引IDも加える。ただし、シード、秘密鍵、PIN、パスフレーズは同じ場所に保存しない。資金が取引所にあるあいだは、使い回していないパスワードまたはパスキー（端末などで認証するログイン手段）と、強固な多要素認証を使う。

税務ルールは国や地域で異なる。記録は保存し、そのうえで、現在住んでいる地域の税務当局または専門家に、必要な項目と対象となる出来事を確認すること。他国のチェックリストをそのまま使ってはいけない。個人間で買った場合は、本人確認（KYC）なしでBitcoinを買う方法も確認すること。

ステップ2：今日引き受けられる責任の大きさを決める

#

設定を間違えても致命傷にならない金額を選ぶ。ソフトウェアウォレットは利便性を重視しやすい。ハードウェア署名機は鍵を隔離し、独立した画面を持てる。マルチシグは、一つを失っても復旧できる余地を増やす一方、失敗しうる箇所も増やす。どれを選んでも、自動的に安全になるわけではない。

マルウェア、端末の紛失、火災、物理的アクセス、強要、判断能力の喪失、死亡など、実際に備えるべき脅威を書き出す。解除や署名を強制されうるなら、操作を始める前に強要下の管理を扱う脅威モデルを確認すること。

ステップ3：検証できる公式経路からウォレットを入手する

#

プロジェクトの公式サイトまたは公式リポジトリ（ソースコードの保管場所）を使う。ソフトウェアの公開版は、プロジェクトが示す手順で検証する。ハードウェアは梱包状態を確認し、自分で初期化する。あらかじめ書かれたシードフレーズは、決して受け入れない。更新は、製造元が認証した経路だけで行う。

保守状況、バックアップ形式、アドレス確認方法、復旧手順の文書も確かめる。選ぶべきなのはブランドではない。自分で検証し、繰り返せる作業手順である。

ステップ4：ウォレットを作り、復旧に必要な情報をすべて記録する

#

復旧情報は、使用するウォレットまたは署名機の上で生成する。公式手順がオフライン作業を求めるなら従う。写真を撮る、クラウド上のメモに貼る、チャットで送る、ウェブサイトに入力するといったことはしない。信頼できる端末で公式の復旧を自分から始めた場合を除き、シードフレーズを求める要求は、不正なものとして扱う。

「シードフレーズ」とだけ書いて終わってはいけない。BIP39では、その単語列（ニーモニック）と正確なパスフレーズからシードを作る。どのパスフレーズからも有効なシードが生まれるため、入力を間違えると別のウォレットが開く。

BIP380は、鍵だけのバックアップではスクリプト種別や導出情報が欠ける場合があると警告している。ウォレット名とバージョン、バックアップ規格、アカウント、スクリプト（アドレス）種別、鍵の導出経路（ウォレットが鍵を探す道筋）、パスフレーズの要否を記録すること。シードだけでは、別のウォレットで復旧できる保証はない。拡張公開鍵（xpub）や公開鍵だけを含むディスクリプタでは履歴を監視できるが、署名はできない。共有すれば取引履歴のプライバシーも漏れる。秘密鍵を含むディスクリプタは、秘密として扱う。

ステップ5：全額を入れる前にバックアップを確認する

#

製造元に公式のバックアップ確認機能があれば使う。たとえばTrezorのSafe 3の確認手順は、入力したバックアップを端末と照合する。分かるのは、その単語列が端末と一致したことまでだ。パスフレーズや導出情報が正しいこと、復元後に送金できることまでは証明しない。

本物のバックアップを、ウェブサイト、チャット、メモ入力欄、信頼できないコンピューターで試してはいけない。安全な確認機能がないなら、互換性が分かっているハードウェアを使い、隔離した復元を計画する。予行演習で転記ミスは見つけられる。復旧経路全体を試すのはステップ10である。

ステップ6：新しいアドレスを作り、全文字を照合する

#

新しいBitcoin受取アドレスを作る。独立した画面を持つ端末では、そこに出たすべての文字をウォレットアプリおよび取引所の入力欄と照合する。先頭と末尾だけを比べてはいけない。Trezorのウォレットアドレスの解説も、全文字の確認を案内している。端末画面で証明できるのは、その端末が生成した内容である。正しいネットワークや受取人を選んだことまで保証するものではない。

このオンチェーン検証では、送金元と受取ウォレットの双方が同じBitcoinネットワークに対応していることを確認し、オンチェーンのBitcoinを選ぶ。ネットワークが一致しなければ、資金へアクセスできなくなるおそれがある。Lightningなど別の仕組みを意図して使うなら、その公式の受取手順に従う。アドレスの再利用やUTXO（unspent transaction output、Bitcoinが追跡する送金可能な単位）の後日の統合は、取引のつながりを明かすことがある。オンチェーンのプライバシーとSilent Paymentsも参照してほしい。

ステップ7：損失を限定するテスト出金を行う

#

取引所の最低出金額を上回り、現在と将来の手数料を差し引いても使える金額を出金する。最終確認でもアドレス全文を見直す。出金ID、手数料、数量、取引IDは、外部へ漏れない形で記録する。

このテストで限定できるのは、この受領経路でアドレス、ネットワーク、手順を間違えた場合の損失である。手数料次第では、何度も繰り返すのが現実的でないこともある。成功しても、署名や復旧が証明されたわけではない。

ステップ8：受領を証明する

#

金額とリスクに合う承認数まで待つ。取引ID、宛先、出金手数料を差し引いた数量を照合する。承認で分かるのは、取引がブロックチェーンに入ったことだ。バックアップから署名機を再現できるかどうかは分からない。

公開ブロックエクスプローラー（取引検索サービス）より、自分のノードを使うほうが、照会時のメタデータを外部へ明かしにくい。ブロックエクスプローラーには、アドレスと接続元の情報が伝わる可能性がある。残高、ラベル、アドレス、取引IDが写ったスクリーンショットを共有してはいけない。

ステップ9：少額送金で署名を証明する

#

自分が管理する新しいアドレスへ、別の少額取引を準備する。署名機に独立した画面があるなら、宛先全文、金額、手数料をそこで確認する。独立した画面がなければ、宛先は取引を準備するPCやスマートフォン上でしか確認できない。その端末が侵害されていれば、確認結果も信用できない。署名し、ネットワークへ配信し、承認まで確認する。お釣り出力（残額を自分のウォレットへ戻す出力）と、UTXOをまとめることで生じるプライバシーへの影響も確認する。

検証した監視専用ウォレットはPSBTを準備できたが、complete=falseを返した。直接送金は**-4**で失敗した。監視側は要求を準備できるが、取引を承認するのは秘密鍵である。この一連の操作で分かるのは、現在の署名能力までだ。紛失後の復旧は、まだ証明されていない。

ステップ10：復旧を証明し、運用計画を完成させる

#

隔離され、互換性が分かっている環境で独立して復元する。想定どおりのアドレスまたはディスクリプタ、入金済みのUTXOを確認し、すべての出力を照合したうえで少額取引に署名する。端末が壊れる前に試すこと。信頼できる予備端末か、オフライン環境を使う。秘密情報を含まない結果だけを記録したら、復元に使った一時端末を公式手順で初期化する。唯一の有効なバックアップは、決して破壊しない。

私たちは、受取ウォレットへ資金を入れる前にバックアップを作った。復元したウォレットは0.01000000 BTCを見つけ、0.00200000 BTCの送金に署名し、1承認を得た。つまり、このバックアップは検証対象の鍵と署名権限を再生成できた。

運用計画を見直す周期、同じ事故で同時に失われない2か所の保管場所、緊急時の計画を記録する。見つけ方の説明と署名用の秘密は分ける。ウォレットやパスフレーズを大きく変更したら、もう一度演習する。残りの資金には新しいアドレスを使い、確認を最初から繰り返す。テストに成功したという理由だけで、一つのアドレスを使い回してはいけない。

隔離環境のBitcoin Core 31.1検証で分かったこと

#

Bitcoin Coreのローカルな回帰テスト用ネットワーク「regtest」を202.22秒動かし、残高を見る能力と、署名・復旧する能力を切り分けた。実際のBitcoinは使わず、P2Pネットワークを無効にし、最後までnetworkactive=false、接続数は0だった。

Bitcoin Core v31.1.0の配布アーカイブについて、SHA256 b80d9c3e04da78fb6f0569685673418cf686fadba9042d926d13fb87ff503f9eとMichael Fordの署名（E777299FC265DD04793070EB944D35F9AC3DB76A）を照合した。

結果とスクリプトには、鍵、アドレス、取引、バックアップ、認証情報、ホスト識別情報を含めていない。スクリプトは管理権の検証ロジックを一度の新規実行で再現する。JSONは、別途検証したリリースと、測定値を得た2段階の実測を記録している。スクリプトは検証済みのバイナリを使う前提で、アーカイブのチェックサムや署名を再確認するものではない。

このregtest実験は論理検証であり、メインネットの性能測定ではない。1承認は、検証を完了させる条件にすぎない。Bitcoin Core 31.1のローカルヘルプでは、listunspent.spendableを「(DEPRECATED) Always true」と説明しているため、署名の合否判定には使えない。この同梱アセットが示すのはv31.1で観察した挙動である。一方、アーカイブ済みのBitcoin Core 30資料はprivate_keys_enabledと監視専用残高の区分を定義し、issue #21104は残高を見られる反例を記録している。だから署名の証明には、フィールド名ではなく、実際に署名した取引を使う。

結論：残りを移す前に、管理権の引き渡しを終わらせる

#

取引所の記録を守れ。引き受けられる管理範囲を決め、全文を照合したアドレスへテスト金額を送れ。その後、受領・署名・復旧を別々に証明せよ。

一つでも失敗したら止まれ。承認済みの出金で証明できるのは受領であって、復旧ではない。形式、設定、パスフレーズが合わなければ、シードだけでは足りない。新しく引き受ける責任を実際に試してから、残りの資金を移せ。

よくある質問

#

答えの境界は共通している。自己管理で変わるのは、誰がリスクを負うかである。テスト出金が証明するのは受領だけで、復旧にはウォレット固有の情報一式が必要になる。

Bitcoinは取引所からすぐに引き出すべきですか？

#

必ずしもそうではありません。取引所での管理には、事業者やアカウントのリスクがあります。急いで自己管理へ移せば、鍵やバックアップを失うリスクがあります。まずアカウントを守り、テスト金額から始めてください。金額を増やすのは、受領・署名・復旧の3つに合格してからにしてください。

ハードウェアウォレットは必要ですか？

#

どの金額にも必要とは限りません。保守されているソフトウェアウォレットは、少額の支払い用残高に合うことがあります。ハードウェア署名機は一部のオンライン攻撃経路を減らし、独立した画面を持てます。ただし、不完全なバックアップを直すことも、強要を防ぐことも、表示内容を代わりに確認することもできません。

テスト出金に成功すれば、自己管理できた証明になりますか？

#

アドレス全文、取引、金額、承認状況が一致すれば、受領の証明になります。監視専用ウォレットも、署名できないまま同じ残高を表示できます。不完全または互換性のないバックアップでは、復旧にも失敗します。3つの検証をすべて行ってください。

どのウォレットでも、シードフレーズからBitcoinを復旧できますか？

#

できません。復旧には規格、正確なパスフレーズ、導出情報、アカウント、スクリプト種別、実装の互換性が関わります。互換性が明記された手順か、元のウォレットの公式手順に従ってください。本物のシードフレーズをウェブサイトへ入力してはいけません。

Bitcoinを買った後、どの税務記録を残すべきですか？

#

購入記録と出金記録を保存し、現在住んでいる地域の税務当局または専門家が求める項目に従ってください。米国向けやインターネット上の一覧を、世界共通だと思わないでください。この記事は、税務上の分類や個別の税務助言を行うものではありません。

Cora Aegis

Cora Aegisは、CypherpunkGuideを執筆するペンネームです。一次資料と再現可能な検証にもとづき、プライバシーを最優先する実践ガイドを書いています。

Coraについてもっと読む →

一次資料とアーカイブ

#

以下の一次資料または公式資料が、安全に関わる主張を支えている。すべての原文・アーカイブの組み合わせには正確なタイムスタンプがあり、再生時の同一性も確認済みである。