金融機関の暗号資産カストディ｜ホット・コールドの分け方と送金承認・鍵の復旧

ある金融機関が、暗号資産を自社で保管する仕組み（カストディ）を作ることになりました。要件をまとめる役はCISOです。製品の説明会では「MPCだから鍵は盗まれない」「大半はコールドで保管するので安全」と聞きます。けれど、鍵の技術が確かでも、運用のすき間から事故は起こりえます。たとえば次のような事故です。

• 退職した担当者の端末や、入れ替えたはずの古い鍵の断片が、署名できるまま残っていた。
• 署名APIが時間切れになったので、取引を作り直して送った。実は最初の署名も成功していて、二重に送金された。
• 鍵をMPCで分散したのに、参加者を全部同じクラウドアカウントで動かしていた。そのアカウントが乗っ取られた時点で、分散の意味がなくなった。

こうした事故を防ぐ出発点は、2つを分けて設計することです。鍵をどう保管するかと、誰が資産を動かせるかです。そのうえで、保管区分、申請・承認・署名、残高の突き合わせ、鍵の復旧、委託先からの資産の引き上げまでを、同じ責任の枠組みで管理します。

以下では、このCISOが要件をまとめる順に進みます。最初に台帳を決め、保管区分と鍵の方式を選び、承認と送金の流れを作ります。最後に、復旧と委託先の評価、受入試験で締めくくります。CTOや内部統制・内部監査の責任者が確かめる点も、その都度見ていきます。

この記事でわかること

• 最初に作る5つの台帳と、ホット・ウォーム・コールドの決め方
• HSM・MPC・マルチシグの組み合わせ方と、職務分離の作り方
• 二重送金を防ぐ送金の管理、鍵の更新と復旧、受入試験で試す8つの場面

MPCの基本は「秘密鍵管理にMPCが必要な理由」、マルチシグの利点と弱点は「マルチシグの仕組みとリスク」で解説しています。

最初に、何を台帳にして結びつけるか

チェーン上の残高だけを資産の台帳にすると、その資産がどの区分にあり、どの鍵とルールで動き、誰が承認したかを追えません。そのため最初に作るのは、製品の比較表ではなく、次の5つの台帳です。共通のIDで結びます。

冒頭の「古い鍵の断片が署名できた」事故は、3行目の台帳を分けて管理しない場合に起きる失敗です。ただしこの台帳は、秘密情報そのものを一覧にするものではありません。秘密鍵やシェアはログに出さず、識別子、どこで守っているか、状態、担当の役割、版だけを追います。

IPA／CRYPTRECの暗号鍵管理システム設計指針（基本編）も、同じ考え方です。暗号方式の選び方だけでなく、鍵のライフサイクル、役割と責任、設計仕様・運用文書を一体で扱うよう整理しています。

ホット・ウォーム・コールドは「どう署名するか」で決める

同じMPCでも、リスクは構成で変わります。API連携の共同署名者（co-signer：自動で署名に参加するサーバー）で自動署名する構成と、切り離した端末へQRコード等で持ち込む構成は別物です。

このように、ネットワークにつながっているかどうかだけでは、リスクは決まりません。「オフラインだからコールド」と名前を付けるだけでは統制にならないので、区分は次の点まで含めて決めます。署名に使うシェアのありか、取引データの持ち込み方、承認者、残高の上限、復旧の手順です。

ホット

• 使いみち：決まった補充、少額で回数の多い処理
• 署名・承認：ルールの評価の後、サービスアカウントか共同署名者が署名する。人の承認を省く条件は絞る
• 制限：残高・1日の流出額・宛先・送金の速さ・チェーンを強く制限する
• 障害時：自動で止め、認証情報を失効させる。ウォームかコールドから新しいアドレスへ補充する

ウォーム

• 使いみち：通常の機関の送金、ホットへの補充
• 署名・承認：オンラインの端末を使うが、複数の役割による承認と強い端末認証を求める
• 制限：金額ごとの承認人数、登録済みの宛先、待機時間、業務時間
• 障害時：承認端末の再登録、シェアの更新（refresh：鍵を変えずに断片だけを作り直すこと）、代わりの承認者への切り替え

コールド

• 使いみち：長期の保管、大口、非常時の原資
• 署名・承認：ネットワークから切り離した（エアギャップ）環境へ、形を整えた取引データを持ち込む。複数人で突き合わせてから署名する
• 制限：決めた実施の枠、送金先の事前登録、署名作業の録画・立会い、物理的な入退室の管理
• 障害時：代わりの拠点での復旧、復旧用素材（recovery material）の開封、資産を新しいアドレスへまとめて移す（sweep）手順

国内の暗号資産交換業者には、金融庁が原則を示しています。顧客から預かる暗号資産は、コールドウォレット等で管理するのが原則です。ホットウォレットでの管理は、業務に必要な最小限に限ります。その場合は、同じ種類・同じ量の暗号資産を別に持ち、流出に備えます（アクセスFSA 第201号、2020年）。

この規制は、改正法により金融商品取引法（金商法）へ移ります。改正法は2026年7月15日に成立し、7月23日に令和8年法律第64号として公布されました。改正金商法にも、原則コールドウォレット等で管理する同じような安全管理措置が設けられます（金融庁 法律案の概要）。

ただし、暗号資産関係の本体は、公布から1年以内の政令で定める日に施行されます。2026年9月24日時点では未施行なので、今の資金決済法と関係府令が引き続き当てはまります。施行までの準備は「暗号資産の金商法改正｜成立・施行を分けた事業者の実装準備」で整理しています。

HSM・MPC・マルチシグは、どう組み合わせるか

まず、3つがそれぞれ何を守っているかを見ます。

• HSM（Hardware Security Module）：鍵やシェアを守り、その中で暗号処理を行う装置
• MPC（Multi-Party Computation）の閾値署名：秘密を複数の参加者に分けて共同で署名する。通常は、秘密鍵の全体を一か所に戻さない
• マルチシグ：複数の独立した鍵による承認の条件を、チェーン上で確かめる

守っている場所が違うので、3つはどれか1つを選ぶ比較の対象ではありません。1つを選べば、残りの統制が要らなくなるわけでもありません。MPCのシェアをHSMやセキュアエンクレーブで守るように、組み合わせることもあります。どれを使っても、弱いところは残ります。

HSM中心にするか、MPCの閾値署名中心にするかは、どこが壊れる事態を防ぎたいかで決めます。判断の軸は後半の「実装する人向けの詳細」にまとめています。

NISTのIR 8214Cは、閾値方式を、秘密を複数の参加者へ分けて署名などを分散して行う仕組みとして整理しています。ただし2026年1月に公開されたこの文書は、閾値方式の提案を公募する募集文書です。参考資料づくりに生かすためのもので、商用のMPC製品を一律に認証する規格ではありません。つまり、「MPCを採用した」ことだけでは安全の裏付けになりません。

そのため、プロトコル、実装の版、シェアの置き方、復旧時に組み立て直す条件まで確かめます。冒頭の3つめの事故のように、全参加者を同じクラウドアカウントと同じCI用の認証情報で起動すれば、暗号の上では分散していても、運用では1か所に戻ってしまいます。

スマートコントラクトの管理者鍵や、relayer（ガス代を肩代わりして送信する中継サービス）の署名サービスの運用は、「HSM・MPCを使った署名鍵の本番運用」で扱っています。

職務分離は、名前を分けるだけでなく、操作できる人をシステムで絞る

申請者と承認者を別の人にしても、同じ管理者が役割の付与、ルールの変更、署名、監査ログの削除をできてしまうことがあります。そうなると、その管理者1人で全部を動かせるので、分離できていません。最低限、次の役割を分けます。

• 業務の申請、リスク・コンプライアンスの承認
• 署名、基盤の管理
• 突き合わせ、監査

兼務する場合も、同じ取引に複数の役割で参加できないようにします。特に、次の組み合わせはシステムで禁じます。

• 通常の送金で、申請した本人が最終承認する
• ルールの変更を、基盤の管理者が1人で変更・承認する
• 鍵・シェアの更新で、作業した運用者が監査の記録も管理する
• 非常用の復旧経路で、平時の管理者だけで復旧用素材を開封する

操作ごとの申請・承認・実行・事後確認の担当は、後半に表でまとめています。

NIST SP 800-130は、鍵管理システムについて、次の点をはっきりさせるよう求めています。役割、各役割が使える機能、分けるべき役割、その分離を保つ方法です。監査ログは、システム管理者以外が管理する例も示しています。

HSMにも、複数人の承認（M-of-N）を求める製品があります。たとえばAWS CloudHSMは、ユーザー管理や、鍵を使った署名などの操作を、承認人数の条件付きにできます（AWS CloudHSM quorum authentication）。

ただし、製品の中の承認人数は、申請が妥当か、送金先が許可リストにあるか、取引の上限、チェーン上の役割までは自動で確かめません。そのため製品の機能を有効にしただけでは職務分離になりません。認証基盤・端末・人員まで独立させて、初めて分離できます。

送金は、署名できた時点で終わりにしない

ブロックチェーンへ送信（broadcast）した後も、チェーン上で確定し、社内の台帳と突き合わせるまでは送金は終わっていません。そこで、次のものを同じ申請IDで最後まで追います。

• 申請した取引の中身と、当てはめたルール
• 承認と署名
• チェーン上の確定と、社内台帳との突き合わせ

申請から突き合わせまでは8つの状態に分けます。業務が完了するのは、社内の補助台帳と突き合わせて差がなくなったときです。

いちばん危ないのは、冒頭の2つめの事故です。署名APIが時間切れになったとき、新しいnonce（取引の通し番号）や取引を作ると、元の署名が実は成功していた場合に二重送金になります。署名要求のID、取引の中身のハッシュ、チェーンのnonceを保存しておきます。署名サービスの提供者とチェーンの両方に問い合わせ、実行されていないと確かめられるまで作り直しません。

送信が時間切れになったときも同じです。同じ署名済みの取引を送り直し、新しくは作りません。チェーンの再編成（reorg）、UTXO（ビットコイン型のチェーンで使う、未使用の受取分）の選び方、アカウントのnonce、手数料を上げた置き換えは、チェーンごとの接続部品（アダプター）で扱います。

DeFi取引では、さらに分かれ道が増えます。巻き戻り（revert）、取り下げ（dropped）、結果不明（unknown）などです。操作ごとに承認の中身を固定する方法は「機関DeFiの取引承認とウォレット権限」で扱います。

鍵は、作った後の更新・漏えい・廃棄で差が出る

鍵やシェアには状態を持たせます。使う前、使用中、一時停止、漏えい（危殆化）、無効化、破棄などです。それぞれを、ウォレットのアドレス、ルール、担当の役割、記録の保存期間と結びつけます。

アドレスを変えずに鍵だけを入れ替えられない資産もあります。その場合、鍵の入れ替え（ローテーション）には次の作業も含まれます。新しいアドレスへの資産の移動、スマートコントラクトの署名者の更新、取引先の許可リストの変更です。

• 生成：承認済みのアルゴリズム・楕円曲線と分散の条件で作る。テスト用の取引で、アドレス・署名・検証を確かめる。
• 有効化：残高の上限を小さく始める。監視、突き合わせ、停止の手順が動くと確かめてから、上限を上げる。
• バックアップ：秘密情報と、復号に要る要素を同じ場所に置かない。復元できる版、地域、担当者の承認人数を記録する。
• 更新：人員の交代、端末の交換、プロトコル・ファームウェアの更新、委託先の変更をきっかけに、シェアの更新か資産の移行を行う。
• 漏えい：疑いの段階で署名の経路を止める。影響するアドレスを特定し、守りを作り直した新しい場所へ資産を移す。
• 廃棄：古い鍵・シェア、バックアップ、キャッシュ、テスト用の写しまでを対象にし、復元できないことを確かめる。監査に要る管理情報（メタデータ）は残す。

NIST SP 800-57 Part 2 Rev.1は、文書にしておく枠組みを示しています。組織の鍵管理の方針、実施の規程、セキュリティ計画、鍵の一覧、バックアップと復旧です。

ただし暗号資産では、署名鍵を捨てると、そのまま資産を取り戻せなくなります。一般的な鍵の廃棄手順をそのまま当てはめてはいけません。廃棄の前に、対象アドレスの残高がゼロであることを確かめます。確定していない取引や、ステーキング・ブリッジ・スマートコントラクトの権限が残っていないかも見ます。

災害復旧と委託先からの退出は、資産を移せたかで確かめる

バックアップのファイルや、「提供者が止まっても復旧できる」という契約の文言があっても、自社の認証情報・ネットワーク・承認人数で期限内に戻せるとは限りません。そこで、本番の鍵をさらさない範囲で、切り離した環境に復旧ツールを用意します。そのうえで、次の流れを最後まで演習します。

1. 復旧用素材を開き、アドレスを導き出す
2. 署名して、別の基盤へ資産を移す
3. 突き合わせて、素材を封印し直す

合格とみなすのは、どの場面でも資産を実際に動かせたときです。演習では、次の場面を試します。測る値は後半にまとめています。

たとえばAWS CloudHSMには、災害復旧の機能があります。バックアップからクラスタを作ったり、バックアップを別のリージョンへ写したりできます（CloudHSM cluster backups）。しかし、機能があることと、自社の認証情報・ネットワーク・承認人数で期限内に戻せることは別です。

Fireblocksは、提供者が止まったときも含めて使える復旧ツールを公式に説明しています。BitGoは、セルフカストディのウォレットをBitGoなしで取り戻せるWallet Recovery Wizardを説明しています（Fireblocks Recovery Tools、BitGo Wallet Recovery Wizard）。これらは製品の例で、推奨ではありません。

復旧の経路は、通常のルールを迂回しえます。そのため、平時の管理者から切り離した承認人数、エアギャップの環境、全操作の立会いと事後の突き合わせを求めます。

委託先の評価では、証明書のほかに何を確かめるか

SOC報告書、ISO認証、FIPS認証済みのモジュールは大事な材料です。ただ、報告書や認証には、対象期間、リージョン、製品のエディション、利用者側の責任（customer responsibility）、例外事項といった範囲があります。そのため、自社の使い方そのものを保証するものではありません。再委託先を含めてこれらを確かめ、自社の統制と結びつけます。

委託先には、次の問いを投げます。

• 誰が鍵・シェアを作り、どの法人・クラウド・端末・HSMに置くか。完全な鍵が現れる例外はあるか。
• ルールの変更、ユーザーの追加、共同署名者の更新、復旧の開始に、何人の承認が要るか。提供者の社員だけでできる操作は何か。
• チェーン・資産ごとの署名方式、アドレスの導き方、nonce・UTXOの管理は誰の責任か。フォーク・エアドロップ・ステーキング・コントラクト操作はどうか。
• 監査ログを、自社のログ分析基盤（SIEM）へすぐに送れるか。時刻、申請、承認、ルールの版、署名、トランザクションハッシュを互いにたどれるか。
• インシデントの通知時間、調査用の証拠、停止・再開の権限、資産の補償、再委託先の変更、データの保存期間を契約で決められるか。
• 契約が終わるとき、鍵・シェア、ウォレットの管理情報、アドレス、ルール、取引履歴、監査の記録をどの形式で受け取るか。残った写しをどう捨てるか。

銀行グループについては、金融庁の主要行等向けの総合的な監督指針 V-6があります。暗号資産の取得等について、不正アクセス等による流出の防止を含むシステムリスクの管理態勢を見るとしています。専門家による定期的な検証・見直しも着眼点です。求められる中身は業態や保有の目的で違いますが、技術を委託しても、自社のリスク評価と責任は残ります。

前に触れた改正金商法は、委託についても定めを置きます。暗号資産取引業の一部を委託する場合の、委託先の指導・品質管理です。暗号資産の管理に使う重要なシステムの提供業者には、事前の届出とシステムの安全性の確保を求めます（金融庁 法律案の概要）。対象のシステムの範囲は、今後の政令・内閣府令で決まります。ウォレット基盤やMPC製品を選ぶ段階から、提供者の届出の状況を確かめる項目を評価表に入れておきます。

本番の受入試験では、統制が壊れる場面を試す

PoCで1回送金できても、カストディの運用を受け入れる試験にはなりません。次の場面を、少額の検証用の資産か、適切なテスト環境で実行します。資産の差、記録の欠け、手作業での介入、目標復旧時間を記録します。

• 申請の後に宛先・金額・チェーン・手数料を書き換えると、それまでの承認が無効になる
• ルールを変えた直後に処理中だった申請は、申請したときの版のまま進む
• 署名APIの時間切れ、送信の時間切れ、チェーンの再編成が起きても、二重送金しない
• 退職者、なくした端末、止めたサービスアカウント、古いシェアが署名に加われない
• ホットの残高上限、送金の速さの制限、未登録の宛先、いつもと違う時間帯で自動で止まる
• コールドの署名作業で、取引の中身を別の経路から突き合わせ、署名の後の書き換えを見つけられる
• 提供者のAPIと主なRPCを止めても、代わりの経路で残高の確認・署名・送信・突き合わせができる
• 非常用の復旧経路を使った後に、復旧用素材を封印し直し、使った認証情報をすべて更新できる

合格の条件は、「資産を失わなかった」だけではありません。次の点がそろうことです。

• 各操作が、承認済みの責任者に限られている
• 申請から突き合わせまで、記録が途切れない
• 例外のときに自動でやり直さず、決めた時間内に資産の状態を確定できる

監査担当は、システム管理者とは別の経路でログを取り出し、保全します。

実装する人向けの詳細

ここからは、CISOがまとめた要件をもとに、CTOのチームが基盤を組むときの表です。

HSM中心とMPC閾値署名中心の採用判断

方式ごとに、受入時に確かめる証拠

操作ごとの職務分離

送金の8つの状態

すべての状態を、同じcustody_request_idで追います。

鍵・シェアの状態

鍵またはシェアにはPRE_ACTIVATION、ACTIVE、SUSPENDED、COMPROMISED、DEACTIVATED、DESTROYEDなどの状態を持たせ、ウォレットのアドレス、ポリシー、担当の役割、証跡の保存期間と対応付けます。

復旧演習で測る値

関連して読む

• ブロックチェーンウォレットの導入・開発と運用設計のポイント — ウォレットの種類とサービス導入の全体像
• 秘密鍵管理にMPCが必要な理由とは？toCサービスのウォレット設計 — MPCの基本的な仕組み
• マルチシグのメリットとリスク — マルチシグの基本
• MPCウォレットとAccount Abstractionの違い — 鍵管理の層とアカウント制御の層の技術的な境界
• Account Abstractionのセキュリティリスク — スマートアカウントを採用する場合の実装上のリスク
• Safeのモジュラーアカウント設計 — オンチェーンのマルチシグ・モジュール構成を検討する場合
• HSM・MPCを使った署名鍵の本番運用 — コントラクト管理者鍵・relayerの署名サービス
• 機関DeFiの取引承認とウォレット権限 — DeFi操作ごとに承認内容を固定する方法
• 企業のデジタル資産保有と内部統制 — 財務としての保有方針・照合・売却
• 企業財務のDeFi運用ポリシー — 利用上限・停止・資金回収
• マルチシグ・タイムロックによる本番権限管理 — 待機時間と緊急権限の決め方
• 暗号資産の金商法改正と事業者の実装準備 — 改正法の成立から施行までの移行計画

XTELAができること

私たちXTELAは、資産・ウォレット・鍵とシェア・ポリシー・証跡をつなぐデータ設計、ホット・ウォーム・コールド間の資金移動と承認の流れ、チェーンごとの接続部品、監視と照合の仕組みを設計・開発しています。製品の比較検証、PoC、災害復旧や委託先からの退出を想定した演習の設計から、本番システムの要件定義・実装・運用設計まで一緒に進めます。法的な判断が必要な点は弁護士と連携して進めます。貴社のカストディ構成について整理したい場合は、お問い合わせからご連絡ください。

主要参考資料

• 衆議院「閣法 第221回国会 57 金融商品取引法及び資金決済に関する法律の一部を改正する法律案」審議経過（2026年7月15日成立、7月23日公布、令和8年法律第64号。2026年9月24日確認）
• 金融庁「金融商品取引法及び資金決済に関する法律の一部を改正する法律案 概要」（安全管理措置、委託先、重要なシステムの提供業者、施行期日。2026年9月24日確認）
• 金融庁「同法律案 説明資料」（2026年4月）
• 金融庁「アクセスFSA 第201号」（2020年4月。暗号資産の管理・カストディに関する制度の説明）
• 金融庁「主要行等向けの総合的な監督指針 V-6 暗号資産に関する留意事項」（2026年9月24日確認）
• JVCEA「利用者財産管理・システム安全管理等」（各規則・ガイドラインは2026年6月版。2026年9月24日確認）
• IPA／CRYPTREC「暗号鍵管理システム設計指針（基本編）」（第1.1版、2026年4月24日公開）
• NIST SP 800-130: A Framework for Designing Cryptographic Key Management Systems
• NIST SP 800-57 Part 2 Rev.1: Best Practices for Key Management Organizations
• NIST IR 8214C: First Call for Multi-Party Threshold Schemes（2026年1月）
• AWS CloudHSM: quorum authentication (M of N access control) using CloudHSM CLI
• AWS CloudHSM: cluster backups and disaster recovery
• Fireblocks Developer Docs: Recovery Tools（製品例）
• BitGo Developer Portal: Wallet Recovery Wizard（製品例）
• Cryptoassets Governance Task Force「暗号資産カストディアンのセキュリティ対策」第4版

資料の確認日と注意

制度と主な一次資料は、2026年9月24日に確認しました。ここに書いたのは、その資料にもとづく技術・業務の設計の整理です。ホット・ウォーム・コールドの区分の例は、法律で決まった保管の比率や、登録が要るかの判断基準ではありません。個別の当てはめは、弁護士等の専門家に確かめてください。