ビットコインの企業保有で問われるのは、秘密鍵を守る技術だけではない。誰が資産を動かせるのか、誰が承認し、取締役会や監査人が残高と操作履歴をどう検証できるのかという企業統治が核心である。 CoinDeskの論説は、Coinbaseを巡る当事者間の対立を、真偽を外部から検証しにくい保管構造の問題として捉え直した。結論は、単一のログインや担当者に依存せず、権限分離・複数承認・独立照合を平時から設計すべきだということだ。
Coinbaseを巡る主張と、現時点で確定していないこと
CoinDeskが掲載したOnramp CEOマイケル・タンガマ氏の論説によると、BlockTower Capital創業者のアリ・ポール氏は、Coinbaseによる顧客資産の喪失や、複数機関に関係する侵害の隠蔽を公に主張した。これに対してCoinbaseは否定し、ポール氏は係争中であることを理由に証拠を公開していない。したがって、告発内容を確定事実として扱うことはできない。
ここで重要なのは、Coinbaseと告発者のどちらが正しいかを推測することではない。論説が問題視するのは、顧客企業、取締役会、投資家などの第三者が、公開情報だけで争点を解消できない状態そのものだ。ブロックチェーン上で残高を確認できても、そのアドレスが誰の資産なのか、簿外債務がないか、署名権限が誰にあるかまでは自動的に分からない。オンチェーンで見える情報と、法人内部の権利・承認・会計記録を結び付ける統制が必要になる。
「残高が見える」と「統治できる」は同じではない
Bitcoinでは取引履歴と未使用トランザクション出力を公開台帳上で追跡できる。しかし企業がCoinbaseなどのカストディアンへ預ける場合、利用者側の画面に表示される残高と、特定のオンチェーン資産との対応関係は必ずしも公開されない。アドレスを開示するだけでも不十分で、そのアドレスに対する法的権利、負債との対応、出金権限まで確認しなければならない。
銀行口座なら、利用者名、職務権限、送金限度、承認者、操作ログを社内規程へ落とし込める。ビットコインでも同じ問いが必要だ。経理担当者が出金申請を作成し、財務責任者が承認し、別の権限者が署名する、といった職務分掌を設ける。さらにCoinbaseのような外部保管先を使う場合でも、事業者の管理画面だけを唯一の証拠にせず、会計台帳、保管明細、オンチェーン記録を定期的に突合する。
DeFiでも事情は似ている。UniswapやAaveのスマートコントラクトが公開されていても、企業が操作に使うウォレットを一人の担当者が管理していれば、社内統制は弱いままだ。プロトコルの透明性は、利用企業の権限管理を代替しない。
QuadrigaCXとPrime Trustが残した教訓
Ontario Securities Commission（OSC）のQuadrigaCX調査は、単なる「創業者の死亡で鍵が失われた事件」という理解を修正している。OSCは、顧客が少なくとも1億6,900万カナダドル相当を失い、その大半は共同創業者兼CEOによる不正取引などに起因したと結論付けた。適切な内部監督、統制、帳簿がなく、顧客も資産の保管・移動・使用状況を意味ある形で検証できなかったという。
Prime Trustについては、ネバダ州金融機関局が、顧客資産を保全できず、すべての顧客の出金要求に応じられない状態だと公表し、管財人選任を裁判所へ申し立てた。QuadrigaCXとPrime Trustの経緯は同一ではないが、共通する教訓は明確だ。ブランド、許認可、画面上の残高だけでは、資産の実在性、アクセス可能性、負債との対応を保証できない。
企業は「事故が起きたら説明を受ける」のではなく、平時から検証資料を受け取れる契約と運用を整えるべきである。保管先が破綻、停止、買収、システム障害に直面した際の資産移管手順も、導入前に確認しなければならない。
取締役会が確認すべき実務チェック項目
Deloitteが北米の大企業のCFOを対象に行った調査では、暗号資産投資への懸念として「会計と統制の複雑さ」を挙げた回答が42％だった。価格変動だけでなく、統制設計が企業導入の障壁になっていることを示す。Coinbaseなどの保管先を選ぶ際は、次の項目を文書で確認したい。
- 資産の法的所有者と、破綻時の分別管理はどう定義されるか
- 出金申請、承認、署名を誰が担当し、単独操作を防げるか
- 担当者の退職、死亡、端末喪失、フィッシング時に権限をどう停止・復旧するか
- 保管明細とオンチェーン残高を、顧客側または独立監査人がどう照合できるか
- 例外操作、アドレス変更、限度額変更を含む監査証跡が保存されるか
- カストディアン停止時に、資産と必要な記録を別事業者へ移せるか
この一覧はBitcoinだけでなく、Aaveへの担保供給、Uniswapでの流動性管理、Curveを使ったステーブルコイン交換にも応用できる。企業ウォレットからスマートコントラクトへ資産を移す操作にも、申請者と承認者の分離、送信先の検証、取引後の照合が必要だ。
マルチシグは有力だが、それだけでは完成しない
Bitcoinの開発者向け資料が説明するように、スクリプト条件を使えば、複数の署名を要求する構成を実現できる。これにより、一人の担当者や一社のカストディアンだけで資産を移動できない設計が可能になる。鍵を社内、外部カストディアン、独立した復旧担当などへ分散すれば、単一障害点を減らせる。
ただし、マルチシグは署名条件を提供する技術であって、企業統治そのものではない。署名者同士が実質的に同じ指揮系統に属していれば、独立性は弱い。誰が申請を起こせるか、どの取引を承認できるか、鍵更新や緊急復旧を誰が決めるかは、別途規程化する必要がある。バックアップを同じ場所に保管すれば、災害や内部不正への耐性も下がる。
また、取締役会が毎回ブロックチェーンを直接解析する必要はない。必要なのは、保管残高、会計残高、署名ポリシー、例外ログを同じ報告単位で定期確認できることだ。技術チームだけに閉じず、財務、法務、監査、情報セキュリティが共通の証跡を見られる体制が現実的である。
DEX・DeFi利用企業にも同じ統制が必要
セルフカストディを選べば、外部カストディアンへの信用リスクは減らせる一方、鍵管理、誤送信、内部不正、事業継続の責任は自社へ戻る。Uniswapでトークンを交換する場合も、Aaveで担保を管理する場合も、Curveで流動性を運用する場合も、秘密鍵を持つ担当者が単独で動かせるなら、公開プロトコルを使っていても企業としての統制は不十分だ。
実務では、許可するプロトコルとコントラクト、利用可能な資産、取引上限、承認経路、緊急停止条件を事前に定める。署名前に送信先、関数、金額、スリッページ条件を別担当者が確認し、実行後はトランザクションIDと会計仕訳を結び付ける。新しいコントラクトやブリッジを利用するときは、既存の承認を流用せず、リスク評価をやり直すべきだ。
さらに、プロトコルのスマートコントラクトリスクと、企業側の運用リスクを分けて管理する必要がある。監査済みプロトコルでも秘密鍵流出は防げず、厳格な鍵管理でもコントラクトの不具合やオラクル障害は防げない。Coinbaseを巡る今回の論争は、中央集権型カストディだけの問題ではなく、デジタル資産を扱う企業全般に「誰が、何を根拠に、どこまで検証できるか」を問い直している。
まとめ
Coinbaseに対する告発は、当事者の主張が対立し、公開証拠だけでは結論を出せない。だからこそ、企業は個別事件の真偽を待つのではなく、自社の保管構造が第三者検証に耐えるかを確認すべきである。
QuadrigaCXとPrime Trustの事例は、単一人物への依存、内部統制の欠如、顧客側からの検証困難が重大な損失につながり得ることを示した。対策の中心は、複数承認、職務分掌、独立した残高照合、監査証跡、障害時の移管計画である。マルチシグはその有力な部品だが、規程、契約、監査を組み合わせて初めて企業統治として機能する。Bitcoin、Coinbase、Uniswap、Aave、Curveのいずれを使う場合も、「資産があるか」だけでなく、「誰が動かせるか」「誰が承認したか」「単一の人や組織が離脱しても継続できるか」を答えられる体制が必要だ。
