企業がビットコインを財務資産として持つとき|内部統制・鍵管理・毎日の照合
約14分で読めます
約14分
目次(タップで折りたたみ)
ある会社の取締役会が、ビットコインを財務資産として中長期で持つことを決議しました。財務の担当者は、取引所のAPIから最初の購入注文を出します。ところが応答が返ってこず、タイムアウトになりました。
担当者は「失敗した」と思い、同じ注文をもう一度出します。実は、最初の注文は取引所の側で通っていました。結果は二重の購入です。
この失敗は、注文が本当に通ったかを確かめずに送り直したことから起きています。そして、よく見るとほかの穴もあります。決議の「中長期で保有する」だけでは、1回の注文がいくらまでならよいのかをシステムが判断できません。注文を出す人と、結果を確かめる人も同じでした。
では、会社がビットコインなどを財務資産として持つとき、統制は何から作ればよいのか。短く言えば、順番は次のとおりです。
- 何を、いくらまで、どんな条件で持つかを取締役会が決め、その条件をシステムが注文のたびに判定できる形にする。
- 注文・承認・署名・記帳・照合を、別の人と別の仕組みに分ける。
- 鍵の事故や委託先の停止が起きても、残高と責任の所在を説明できるようにする。
以下では、この会社がCFO、CTO、財務、内部監査と一緒に統制を作っていく順に見ていきます。最後に、本番の前に確かめる12項目をまとめています。
この記事でわかること
- 取締役会の方針に書くことと、それを注文ごとの判定に変える方法
- 5つの役割の分け方、購入から保管までの追い方、毎日の突き合わせ
- 事故のときの止め方、やめるときの手順、本番前の12項目
この記事で使う言葉
- DAT(Digital Asset Treasury):暗号資産を財務の柱にする上場企業を指すこともある言葉。ここでは、企業がデジタル資産を財務資産として持ち、運用するための方針と業務を指す
- カストディアン:暗号資産を預かって保管する業者
- MPC/マルチシグ:複数の人や機器が鍵(またはその断片)を持ち、決めた数がそろったときだけ署名できる方式
- 署名対象データ:署名する前の、送金の中身(金額・宛先など)を表すデータ
- 相関ID:注文から仕訳まで、同じ番号で追うための共通の番号
取締役会の方針を、注文のたびに判定できる条件にする
冒頭のとおり、「中長期で保有する」と決議しただけでは、日々の売買を止めることも許すこともできません。ですから、取締役会の方針(権限を与える基本の方針)には、少なくとも次のことを書き込みます。
- 何を、何のために、どのお金で持つか(対象の資産、保有の目的、取得の原資)
- どこまで買い、どこまで売るか(取得・売却の上限、最低限の流動性)
- どこで扱うか(使ってよい取引所・カストディアン)
- 担保に入れる・貸し出す・ステーキングすることをしてよいか
- 報告の頻度、止める条件、例外を承認する人、やめるときの条件
法務・税務・会計の結論は、担当の部署と外部の専門家が出します。システムの側は、その結論を条件の版として保存します。
方針の数字を、表計算の中だけに置いてはいけません。表計算の数字は、注文のたびにシステムが自動で確かめることができないからです。方針の版、上限、1日に執行してよい上限、使ってよい取引所、最低限の現金、有効期間を、方針を判定するシステムに登録します(項目名は後半に載せています)。
注文のときには、どの版を使ったかと判定の結果を固定します。後で方針を変えても、過去の取引の根拠が消えないようにするためです。
実際の開示の例もあります。米国の上場会社Strategyは、2025年のForm 10-Kで、ビットコインの管理について評価した事項を開示しています。カストディアンの情報セキュリティ、内部統制、多要素認証、アクセス制御、鍵の管理、コールドストレージ(ネットワークから切り離した保管)です(Strategy Form 10-K)。これは特定の製品の安全を保証するものではなく、企業の側が、委託先と自社の統制を具体的に説明する必要がある、という例です。
方針・執行・記録・保管・照合を、5つの役割に分ける
鍵をMPCやマルチシグにしても、同じ管理者が注文、承認、署名、送付先の登録、会計の記録、照合をすべて操作できるとします。これでは、1人で資金を動かし、記録も合わせられてしまいます。つまり、職務を分けたことにはなりません。
そこで、最低限次の5つの役割を分けます。それぞれの役割について、IdP(社員のIDを管理する仕組み)のアカウント、端末、秘密の情報、管理者の権限まで別々にします。
| 役割 | できること | 1人ではできないこと |
|---|---|---|
| 方針の責任者 | 上限・対象・例外の条件を起案する | 注文の承認、署名、記録の書き換え |
| 財務の執行 | 上限の中で注文・移動を申請する | 自分で承認する、送付先を登録する |
| 承認者 | 目的・金額・宛先を承認する | 分散した鍵の管理、照合の完了 |
| カストディの運用 | 承認済みの署名対象データに署名する | 金額・宛先・目的を変える |
| 経理・照合 | 3つの記録を突き合わせ、差を起票する | 差を黙って消す、資産を動かす |
役割ごとに残す記録は、後半の表にまとめています。
鍵の管理の分野にも、同じ考え方があります。NIST SP 800-130は、鍵を管理する仕組みについて、文書にすべきことの枠組みを示しています。役割、各役割が使える機能、分けるべき役割、その分け方を保つ方法です(NIST SP 800-130)。会社の暗号資産の管理では、この考え方を署名の装置だけでなく、取引所のアカウント、送付先の許可リスト、会計との連携、ログの管理にも当てはめます。
購入から保管までを、1つの番号で追う
1回の購入は、いくつもの段階を通ります。購入注文、円の出金、約定、取引所の中の残高、カストディアンへの出庫、ブロックチェーン上での確定、帳簿への計上です。これらを別々のチケットで管理すると、途中にある資産が抜け落ちます。
そこで、財務の操作ごとに1つの番号(相関ID)を付けます。そして、方針の版、申請、承認、取引所の注文ID、銀行への指図ID、出庫ID、送付先のアドレス、トランザクションハッシュ、会計の仕訳IDを、その番号に結び付けます。
状態は、たとえば次のように分けます。
申請 → 承認 → 送金 → 約定 → 出庫の依頼 → ブロックチェーン上で確定 → 保管の確認 → 照合の完了
冒頭の二重購入を防ぐのも、この番号です。APIがタイムアウトしても、注文は相手の側で通っているかもしれません。ですから失敗と決めつけず、同じ注文ID、出庫ID、トランザクションハッシュで照会します。まだ反映されていないと確かめずに送り直すと、二重の購入や二重の出庫を起こしえます。
DeFiで運用する場合は、この後ろに、預け入れ・借り入れ・引き出しの状態が加わります(企業財務のDeFi運用ポリシーで扱います)。
送付先の許可リストへの追加や変更は、ふだんの送金よりも強く守ります。宛先を書き換えられると、正しい承認を経た送金でも別の場所へ届いてしまうからです。
- 登録する人と承認する人を分ける
- 待ち時間を置き、少額で試しに送る
- アドレス・ネットワーク・メモやタグを、画面とは別の手段で確かめる
署名の画面では、人が承認した金額・資産・ネットワーク・宛先と、実際の署名対象データを、ハッシュで結び付けます。途中で差し替えられたら、気づけるようにするためです。
鍵の方式より、資産を動かせるすべての道を洗い出す
残高を動かせる道は、ふだんの送金だけではありません。次のような道もあります。
- 管理者による方針の変更、APIキー、復旧の手続き
- カストディアンのサポートの手続き、取引所の中での振替
- 担保の差し入れ
このうち、いちばん弱い道の強さが、実際の守りの強さになります。自己管理、第三者のカストディ、MPC、HSM(鍵を守る専用の機器)、マルチシグのどれが優れているかを一言で決められないのは、このためです。すべての道を書き出してから比べます。
委託先には、次のことを確かめます。
- 資産と法的な主体の分け方、秘密鍵の管理、出庫の承認
- 再委託先のカストディアン、保険の対象と上限、障害の通知
- 監査の報告書、記録の取り寄せ、倒産・契約終了のときの移し替えの手順
保険があっても、損失がすべて補われるとは限りません。Strategyの開示でも、カストディ契約での責任は重大な契約違反などに限られると説明されています。プロトコルの障害や、利用者の側の誤った指図などは、除かれることがあります。
鍵の生成・保管・復旧・更新・漏えい・廃棄の詳細は、重なりを避けるため機関投資家向け暗号資産カストディ設計で解説しています。ここでは、その技術の守りを、会社の財務の方針と記録につなげることを見ています。
毎日、3つの記録を別々に取り寄せて突き合わせる
ブロックチェーンエクスプローラーで見える残高だけでは、証明できないことがあります。会社がそのアドレスを支配する権利。カストディアンの中の補助元帳。まだ確定していない取引。担保で動かせない分。会計の帳簿と合っているかどうかです。
ですから、毎日か、大きな取引の後に、次の3つの記録を別々に取り寄せて突き合わせます。
- 総勘定元帳と補助簿
- 取引所・カストディアンの取引の明細
- 独立したノードか、複数のデータ提供者から得たブロックチェーン上の残高
アドレスごとに、次の情報を結び付けておきます。資産、ネットワーク、ウォレットの用途、保管の区分、法的な持ち主、カストディアンのアカウント、帳簿の価額の単位、担保・貸出などの制限です。
差が出たら、理由のコードを付けます。未確定、手数料、社内の振替、フォーク(チェーンの分岐)やエアドロップ(無償で配られるトークン)、誤ったネットワーク、価格の出どころの違い、時刻の境目などです。担当者が合計の数字を直接書き換えることはしません。
監査の実務にも、この形が見られます。Grayscale Bitcoin Trust ETFの2025年のForm 10-Kに載った監査報告では、次の守りが監査の手続きの対象になっています。カストディアンの記録と自社の記録の比較、パブリックブロックチェーンとの取引の照合、承認、秘密鍵の管理と職務の分離です(GBTC Form 10-K)。会社の暗号資産の管理のための個別の要件を決めた資料ではありません。それでも、残高があることと権利を、1種類の証拠だけで説明しない実務の例です。
評価・開示の数字を、後から同じように出し直せるようにする
日本の企業会計基準委員会の実務対応報告第38号は、資金決済法の上の暗号資産について扱っています。活発な市場があるときの期末の評価や、ふだん使う取引所などの価格です(ASBJ 実務対応報告第38号)。自社にどの処理を当てはめるかは、会計監査人と決めます。システムには、その結論を方針の版として残します。
制度も動いています。2026年7月15日に「金融商品取引法及び資金決済に関する法律の一部を改正する法律」が成立し、7月23日に公布されました。暗号資産の取引の規制は、資金決済法から金融商品取引法へ移ります。施行は、公布から1年以内に政令で決める日です。施行の後、会計の扱いについて基準が見直されることもありえます。
ですから、価格の取り方や評価の区分をプログラムに直接書き込まず、版で差し替えられる設定にしておきます。事業者の側の準備の順序は暗号資産の金商法改正と実装準備にまとめています。
システムには、価格について次のことを残します。
- 価格の提供者、取引所、通貨の組み合わせ、取得した時刻、タイムゾーン
- 売値・買値・最終値などの種類、取れなかったときの代わりの処理
- 資産の対応付け、丸めの規則、承認した人
月末の値だけを保存するのではなく、受け取ったままの応答のハッシュと、変換の過程も持っておきます。保有量、平均の取得額、評価額、まだ実現していない損益、担保で動かせない分、売買の履歴。外に開示するこうした数字は、同じ基準時刻と残高の記録から、作り直せるようにします。
事故が起きたら、まず署名を止め、次に事実を確かめる
事故のときに焦って別のウォレットへ資産を移すと、その操作がさらなる損失や、証拠の消失を招くことがあります。そこで、対応を2つの段階に分けます。
不審な送金、認証情報の漏えい、端末の乗っ取り、カストディアンの障害、ブロックチェーンの停止、フォーク、残高の差を見つけたら、次のように動きます。
- 止める:新しい注文、出庫、許可リストの変更、復旧の操作を止める。
- 事実を確かめる:影響を受けるアドレス、未確定の取引、承認の履歴、署名対象データ、IdP・端末・カストディアンのログを保全し、資産が今どこにあるかを確かめる。
緊急の移し替えも、事前に決めた承認者の人数で行います。
連絡先には、財務、経理、情報セキュリティ、法務、経営、カストディアン、取引所、監査人を入れます。重大さの段階、知らせる期限、外への説明を誰が承認するかも決めます。
訓練は、場面ごとに分けて行います。鍵の漏えい、カストディアンのAPIの停止、誤った送金、内部の不正、価格データの異常、ブロックチェーンの巻き戻り(再編)です。机の上での演習だけでなく、実際に資産を移すテストもします。
やめるときは、売却の注文ではなく、残高ゼロの証明まで考える
会社が暗号資産の保有をやめるときは、市場で売るだけでは終わりません。次のことも含まれます。
- カストディアンの変更、取引所のアカウントの閉鎖、担保の解除
- APIキーの失効、ウォレットの廃止
- 会計・開示の締めくくり
資産ごとに、流動性、1日の上限、値動きによる約定の差、銀行の受付の締め切り、税務・会計の確認、取締役会の承認、緊急のときの順番を決めます。価格が下がったときにも業務の資金を確保できるよう、最低限の現金の余力を決めておきます。保有の上限を超えたときに、いつまでに直すかも、ふだんから決めておきます。
年に1回以上は、少額を代わりのカストディアンか、自分で管理できるアドレスへ移してみます。契約が終わるときに、資産、取引の履歴、取引の明細、監査の記録を取り戻せるかを確かめるためです。
やめるときは、ブロックチェーン上の残高、カストディアンの取引の明細、補助簿、総勘定元帳を同じ時点で突き合わせます。未確定・担保・手数料も含めて、残高がゼロか、承認した残高だけであることを証明します。
本番前に確認する12項目
- 保有目的、対象資産、上限、資金源、停止・退出条件を取締役会が承認している。
- 方針の版が注文ごとに固定され、後から判定の根拠を再現できる。
- 申請、承認、署名、記帳、照合、ログ管理を1人で完結できる人がいない。
- ふだん・管理・復旧を含め、資産を動かせるすべての道を洗い出している。
- 送付先の追加は、2人の承認、待ち時間、別の手段での確認、少額のテストを通る。
- 注文から仕訳まで1つの相関IDで追え、送り直しても二重に実行されない(冪等である)。
- 帳簿、カストディアンの記録、パブリックブロックチェーンを、それぞれ別の情報源から取って突き合わせる。
- 担保、貸出、未確定、手数料、フォークなどを、使える残高と分けている。
- 価格の出どころ、基準の時刻、丸め、代わりの処理、承認を再現できる。
- カストディアンの責任の上限、再委託先、監査、障害の通知、退出の手順を確かめた。
- 乗っ取り・誤送金・停止・差の演習と、緊急の移し替えのテストを行った。
- 売却、契約の終了、認証情報の失効、記録の回収、残高ゼロの突き合わせまでして、やめられる。
持っている資産の一部をDeFiで運用する場合は、損失の上限、許可の台帳、異常のときの回収の手順を上乗せします。続きは企業財務のDeFi運用ポリシー、鍵と保管の設計は機関投資家向け暗号資産カストディ設計をご覧ください。
実装する人向けの詳細
ここからは、この会社で財務のシステムを作るCTOと開発チームの話です。
方針を判定するシステムに登録する項目
方針の数字は、policy_version、asset_id、max_holding、daily_execution_limit、approved_venues、minimum_cash_buffer、有効期間として登録します。
役割ごとに残す記録
| 役割 | 主な証跡 |
|---|---|
| 方針責任者 | 決議、方針版、承認履歴 |
| 財務執行 | 注文ID、見積、資金源 |
| 承認者 | 承認時刻、条件、否認理由 |
| カストディ運用 | 署名対象データのハッシュ、署名者、トランザクションハッシュ |
| 経理・照合 | 残高スナップショット、差異、解消承認 |
相関IDと状態の名前
相関IDはtreasury_operation_idとして採番します。前半の状態は、たとえば REQUESTED → APPROVED → FIAT_SENT → ORDER_FILLED → WITHDRAWAL_SUBMITTED → ONCHAIN_CONFIRMED → CUSTODY_CONFIRMED → RECONCILED です。
XTELAができること
私たちは、取締役会方針を判定可能な条件に落とし込み、承認ワークフロー、ウォレット・カストディ連携、状態管理、日次照合、監視、監査ログを備えた財務システムを設計・開発します。少額の購入から照合・退出テストまでを通すPoC(概念実証)から始め、貴社の運用に合わせて本番へ広げます。法的な判断は弁護士と連携して進めます。技術・業務統制の具体化はお問い合わせからご相談ください。
主要参考資料
- 企業会計基準委員会「実務対応報告第38号」(2026年8月12日確認)
- 金融庁「金融商品取引法及び資金決済に関する法律の一部を改正する法律案 説明資料」(2026年9月24日確認)
- BUSINESS LAWYERS「2027年施行 暗号資産に関する金商法・資金決済法改正の概要」(成立・公布日の確認、2026年9月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
- Strategy Inc. Form 10-K (2025)
- Grayscale Bitcoin Trust ETF Form 10-K (2025)
- 金融庁「主要行等向けの総合的な監督指針 V-6 暗号資産に関する留意事項」(適用範囲の参考、2026年8月12日確認)
資料の確認日と注意
制度・一次資料は2026年8月12日に確認しました。日本の法改正の状況(成立・公布と施行時期)は、2026年9月24日に確認し直しています。内容は一般的な技術・業務設計の解説で、保有の是非や価格の見通しを示すものではありません。法務・税務・会計・投資の個別の判断は、実装・開示の時点の一次資料をもとに専門家へご確認ください。