デジタルカストディを導入する金融機関は、システムの提供元が止まったとき、誰が資産を返すのでしょうか。
鍵の管理や署名の機能を外部の製品で賄うのか、資産そのものを外部のカストディ事業者に預けるのか。どちらを選んでも、提供元の停止、受託者の倒産、自社の事業終了の後に、顧客へ資産を返す手段が要ります。
外部委託と事業継続編では、委託先が止まったときの返還、鍵と署名の仕組みの置き場所、リージョンの障害への備え、どこまで自前で持つか、既存のガバナンスへの載せ方を、確認項目と試験の条件まで整理します。保管方式の設計は保管設計編で、不正な取引を止める仕組みは不正送金の防止編で扱いました。制度の説明は資金決済法上の暗号資産を対象にします。
提供元は侵入の経路にも、返還の依存先にもなる
海外の大手交換業者Bybitの流出（2025年2月）では、ウォレットを提供するSafeの開発者の端末が侵入の起点でした。インドの交換業者WazirXでも2.3億ドル超が流出し、基盤を提供したカストディ事業者Liminalとの間で、改変がどちら側で起きたかの主張が対立しています。
鍵さえ手元にあれば顧客に返せると思われがちです。米国では、破産裁判所が信託会社Prime Trustを含むグループの倒産手続で、顧客ごとに追跡できなかった暗号資産を破産財団に属すると判断したと報じられています。WazirXでも、流出を免れた資産があっても、暗号資産の返還はシンガポールの高等法院での再建手続を待って約15か月止まったと報じられています。提供元は侵入の経路になり、止まれば返還を妨げる依存先にもなります。
1. 委託先が止まったら資産は返せるのか
停止・倒産・事業終了で返還の条件が違う
製品の提供元が事業を止めても、顧客への返還の義務は金融機関に残り、返せるかは提供元なしで復旧し、署名と移転を実行できるかで決まります。自社が事業を終える場合は、顧客の記録と資産を誰に引き継ぎ、どの条件で移管を終えるかを決め、移管先が扱わない資産は引き継げません。
受託者が倒産した場合、交換業者の顧客は、分別管理された利用者の暗号資産と、履行保証暗号資産（オンラインで管理する分と同じ種類・数量を交換業者が自己で保有する資産）について他の債権者に先立って弁済を受ける権利＊1を持ちますが、流出で不足した部分まで守られるわけではありません。信託では、信託法25条により受託者が破産しても信託財産は破産財団に属しませんが、流出した損失の補塡や即時の返還は別の問題です。
米国では、デラウェア州の破産裁判所がPrime Trustを含むPrime Coreグループの倒産手続で、顧客ごとに追跡できなかった暗号資産を破産財団に属すると判断したと報じられています。日本の信託会社等向けの監督指針は複数の信託の暗号資産を同じウォレットで管理することを認めており、問われるのは顧客ごとの持ち分を識別し立証できるかです。
右端の列が、それぞれの場面で事前に用意しておく準備です。
提供元がいない条件で復旧を試験する
ウォレット基盤を提供する米国のFireblocksの説明では、鍵の断片は3つで1か所にそろわず、署名機器にアクセスできなくなった場合や、可能性は低いとしつつFireblocks自身が事業を停止した場合に備えた復旧の手順を示しています。AWS CloudHSMでは鍵は既定で書き出し可能として作られ、書き出し不可にした鍵はどのような場合も書き出せず、後から変えることもできません。移行の手段は、導入時の鍵の設定で決まります。
復旧の経路は、それ自体が強い攻撃の経路にもなります。復旧の開始を誰が承認するか、復旧の情報をどこに分けて保管するか、復旧後に古い鍵や断片をどう扱うかを決め、権限のない者には復旧できないことと、定めた時間内に復旧できることの両方を試験します。試験は提供元のAPI、認証、ライセンス、担当者を使わない条件で行い、記録の復元から署名、移転、顧客台帳への反映までを確かめます。信託会社等向けの監督指針も、親会社等と共通のシステムを使う場合に、親会社等の関与なく暗号資産を移転できる手段と権限の確保を求めています。
鍵と記録が揃っても返還の手続は別に要る
返還は、移管先が対応する資産とネットワーク、顧客ごとの記録、移転を実行する権限、手続の合意がそろって初めて進み、鍵はその必要条件の1つです。
2. 鍵と署名の仕組みをどこに置くのか
配置形態で鍵を支配する者と止まったときに戻せる者が変わる
鍵と署名の仕組みの置き方は、オンプレミスのHSM（鍵の生成・保管と暗号処理を行う専用装置）、クラウドのHSM、提供元のクラウドと自社で鍵の断片を分けるハイブリッドのMPC（鍵を複数の参加者で分担して署名を作る方式）、鍵の管理ごと外部のカストディ事業者へ委託する形に分かれます。AWS CloudHSMは利用者専用のHSMで、FIPSモードのクラスターでは米国の暗号モジュールの認証規格FIPS 140-2または140-3のレベル3の認証を受けたHSMを使え、AWSから見えない暗号化で利用者が管理を担う分、利用者の責任が増えると説明しています。Azure Managed HSMは信頼の起点となる鍵を利用者だけが支配し、全HSMの喪失などの災害から復旧するときに復旧用データがなければ鍵は永久に失われ、Microsoftにも復旧の手段はないとしています。
ハイブリッドの例では、FireblocksのAPI Co-signerを利用企業の環境に置いて鍵の断片を1つ持ち、残る2つはFireblocksのクラウド上の共同署名者が持ちます。BitGoは利用者、バックアップ、BitGoの3つの鍵のうち2つで署名し、自己管理型（MPCとマルチシグの両方がある）では利用者とバックアップの鍵を顧客が、カストディ型では3つともBitGoが持ち、物理的に分散した金庫で保管してオフラインで署名します。金融庁のサイバーセキュリティガイドラインは、クラウドについて責任共有モデルを理解し、クラウド事業者との責任範囲を明確にするよう求めています。
下の行ほど鍵の支配が提供元に移り、止まったときの返還が契約の取決めに依存します。
3. リージョンの障害にどう備えるのか
リージョンを分けても止まる範囲は残る
クラウドでは、どのリージョン（データセンターの地域単位）に鍵とデータを置くかが加わります。金融庁の公表のとおり、2026年6月1日から金融庁は、利用者の保護などのため必要な場合に交換業者へ資産の国内保有を命じられるようになりましたが、常に国内保有を求める規定ではありません。主要行等向けの監督指針は海外で行われる外部委託も管理の対象とし、バックアップ体制が地理的集中を避けているかを確認項目に挙げています。交換業者向けの事務ガイドラインは、国内の営業所で閲覧できれば帳簿書類の国外保存を認めています。
米国東部のリージョンでは、2025年10月19日から20日（米国太平洋時間）にDNS管理の不具合から障害が起き、サインインなどの認証にも影響が及び、一部のサービスは全リージョンで影響を受けました。東京リージョンは4つ、大阪は3つの独立したデータセンター群を持ち、東京と大阪に分ければ片方の地域の障害に備えられますが、3つの鍵のうち2つで署名する構成で2つを同じ側に置けば、その側が止まると署名できません。クラウド事業者に共通する制御系の障害も残ります。
AWS CloudHSMのバックアップは別リージョンへコピーできますが、コピーから作ったクラスターは元と連動しない別の管理対象になります。Azure Managed HSMの複数リージョン構成で追加できるのは1リージョンだけです。
上段は構成ごとの止まる範囲とデータの所在、下段は署名に必要な鍵の数を増やしたときの不正への強さと止まりやすさの関係です。
署名に必要な鍵の数を増やすほど、停止に弱くなる
暗号資産の保管について業界団体C4がまとめたセキュリティ基準CCSSは、局地的な障害で資金を移転する能力が損なわれないよう鍵を異なる場所に保管し、バックアップを地理的に離れた場所に置くよう求めています。BitGoは3つの鍵を地理的に分散して保管し、2つで署名するとしています。一方、NISTの閾値暗号に関する報告（NISTIR 8214）は、閾値化はある性質を高める一方で別の性質を損ないうるとし、3つの参加者全員が必要な構成では、侵害された1つが応答しないだけで署名ができなくなると指摘しています。鍵を3つに分ける場合で考えます。1つで署名できるようにすれば、拠点が止まっても署名を続けられますが、1つ盗まれるだけで不正な送金が成立します。3つすべてを必要にすれば不正には強くなりますが、1つの拠点が止まるだけで署名できなくなります。BitGoの「3つのうち2つ」は、その中間を選んだ構成です。
金融庁のオペレーショナル・レジリエンスの考え方（2023年4月）は、中断は必ず起こることを前提に代替手段で早期に復旧するよう求め、銀行間の大口・大量決済など特に重要な決済業務は、既存の業務継続計画で当日中に再開する計画を最低ラインとしています。カストディの復旧目標は、業務の重要性と顧客への影響から自社で定めます。交換業者向けの事務ガイドラインは、重要なシステムにオフサイトのバックアップを事前に準備するよう求め、流出時の措置の例として、インターネットに接続した環境の秘密鍵等を直ちに隔離することを挙げています。署名に必要な鍵の数と鍵の置き場所は、この再開の目標と、隔離した後に誰がそろえば署名できるかから逆算します。
では、自社で構築するか、製品を使うか、外部に預けるかは、何で比べればよいのでしょうか。
4. どこまで自前で持つのか
方式の名前ではなく、誰が何を支配するかで比べる
自社で構築する、製品を使って自社で運用する、外部の事業者へ委託する、という3つの方式は実際には混ざります。BNYは2022年にカストディ基盤を始めた際、FireblocksとChainalysisの技術を組み込み、業務は銀行が自ら提供して鍵の管理には外部の製品を使いました。比べる軸は、鍵、承認、ルールの変更、顧客台帳、復旧を、それぞれ誰が支配するかです。
方式ごとの差が最も大きいのは、復旧の行です。
製品を使う場合に確かめるのは、提供元がいなくても復旧と移転ができることです。外部の受託者へ預ける場合は、管財人や後任の受託者を含めた返還の権限と手続を確かめます。顧客が外部の事業者と直接契約する紹介・取次の形では、法的な責任を資産、適用法、契約に照らして確かめます。
確認項目には証拠と合否の条件を付ける
導入前の確認は、機能の一覧ではなく、想定した条件で働くことを示す証拠で行います。表の上の3行は、署名の照合と権限の変更、被害上限について、不正送金の防止編と保管設計編で整理した項目です。
| 確認項目 | 責任を持つ部門 | 証拠 | 合否の条件 | 再確認のきっかけ |
|---|---|---|---|---|
| 承認内容と署名対象の一致 | 1線の業務部門（入力経路の変更権限は2線のリスク管理部門が確認） | 検証の構成図、改ざんデータと使用済み承認の試験記録 | 送付先や操作の種類を変えたデータと、使用済みの承認記録（一度使った承認を再び添えたもの）で署名が止まる | 署名機器や画面のプログラムの更新 |
| 権限と実装の変更 | 2線のリスク管理部門 | 経路ごとの拒否場所と承認者の一覧、待機・通知の試験記録 | 署名者の変更、ウォレットの検査機能（Guard）の解除、実装の変更が送金の承認だけでは通らない | 承認ルールや署名者の変更 |
| 被害の上限 | 2線のリスク管理部門 | 侵害の範囲ごとの残高、上限を強制する場所と変更権限、補充の設定（オンラインのウォレットへ自動で補充する条件と量） | 管理権限の侵害と補充の継続を含めた試験で、失う額が定めた上限以内 | 預かり残高の増加 |
| 鍵・署名者・管理者の独立性 | 1線のシステム部門 | 鍵の配置、管理者アカウント、認証基盤、リージョンの一覧 | 1つの管理者、クラウド、認証基盤の侵害で署名が成立せず、1リージョンの障害でも定めた時間内に署名を再開できる | 構成の変更 |
| 提供元の開発と配信 | 2線のリスク管理部門（契約の管理は1線の委託管理部門） | 再委託を含む契約、対象範囲を確かめた第三者保証報告書、本番変更の監視記録 | 画面のプログラムの改変を自社で検知でき、提供元の本番変更の監視の証拠がある | 提供元の事故や体制の変更 |
| 提供元がいない条件での復旧 | 1線の業務部門 | 復旧訓練の記録、復旧開始の承認記録 | 提供元のAPIと担当者なしで移転まで終わり、権限のない者には復旧できない | 製品の版の更新 |
| 顧客台帳と実際の残高 | 1線の業務部門 | 取引単位の突合（指図・承認記録・台帳・チェーン上の実績を1件ずつ突き合わせること）の結果、照合の入力経路を変更できる権限者の一覧 | 承認のない取引や重複した実行を取引単位の突合で検知できる | 取り扱う資産の追加 |
| 停止時の返還 | 2線を支える法務部門 | 契約、返還手順、移管先が対応する資産の一覧 | 準拠法、資産の帰属、請求の順位、実行の権限と必要な承認を文書で特定できる | 法令・府令の改正 |
責任を持つ部門は、既存のガバナンスに載せる3線（1線は業務部門、2線はリスク管理部門、3線は内部監査部門）の割り当てに合わせ、監査は3線が担います。設計上の整理として、システム部門と委託管理部門は1線、法務部門は2線を支える部門として扱います。
責任を持つ部門と証拠は、サイバーセキュリティガイドラインが委託先の管理で挙げる責任者の明確化、選定時の確認、契約、継続的なモニタリングに対応します。日本暗号資産ビジネス協会（JCBA）は、委託先であるシステム提供者の側から対応項目を10の領域に整理したプラクティス集をドラフトとして公表しています（2026年10月20日）。合否の条件と再確認のきっかけは、海外の事例から逆算した設計上の提案です。費用は、ライセンス料だけでなく、監査、夜間に変更を止める要員、復旧訓練、提供元から移る退出の費用まで含めて比べます。