RWAに使うブロックチェーンの選び方｜点数表の前に決める失格条件と撤退基準

ある金融機関で、社債のトークン化に使うブロックチェーンを選ぶ会議が開かれました。机に出てきたのは、候補チェーンを点数で比べた評価表です。性能が40点、費用が20点、開発のしやすさが…と足し合わせ、処理の速い候補が1位になっていました。

ところが、その1位の候補は、発行とアップグレードの鍵を1人で管理する作りでした。誤った取引を訂正する手段もありません。点数を足すと、こうした致命的な弱点が、処理の速さ（TPS）で帳消しになってしまうのです。

規制の対象になる資産では、選び方の順番を変えます。まず「1つでも当てはまれば採用しない」条件を決めます。見るのは次の6点です。

• 権利の正式な記録（正本）はどこにあるか、誰が参加できるか
• 誰に何が見えるか、いつ取引が確定するか
• 誰が管理の権限を持つか、障害からどう戻すか

そのうえで、残った候補を実際に動かし、わざと障害を起こして確かめます。採用するときには、やめるときの条件まで決めておきます。以下では、金融機関やRWA事業者のCTO・アーキテクトが、この順で選定を進める手順を見ていきます。

ブロックチェーンの種類そのものの違いはブロックチェーンの種類を比較｜企業に適した選び方で、RWAの基礎はRWAトークン化の解説で扱っています。

この記事でわかること

• チェーンの種類を見る前に答えておく6つの問いと、形態ごとの向き不向き
• 1件でも当たれば落とす失格条件と、PoCでわざと壊して確かめること
• 3年分の総費用の見積もり方と、採用時に決めておく撤退の条件

チェーンの種類を見る前に、6つの問いに答えを出しておく

「RWA」は、不動産、社債、受益権、債権、環境価値などを含む広い呼び名です。同じネットワークでも、必要な統制は変わります。トークンが法的な権利の正本なのか、原簿を参照して表示しているだけなのか、で違うからです。

日本のST（セキュリティトークン）では、ブロックチェーン上の投資家情報と受益権原簿を連動させて、保有者を管理する構成があります（日本銀行デジタル通貨フォーラム資料）。個別の商品で何を法的な正本にするかは、契約・法域・制度にもとづいて決まります。

チェーンを比べる前に、次の6つに答えを出します。

1. 権利：トークンの残高は何を表すか。発行・移転・償還・訂正を、どの記録が確定させるか。
2. 参加者：検証ノード、コントラクトを配置する担当、投資家のウォレット、カストディアン、閲覧者を、誰が承認し、誰が取り消せるか。
3. データ：残高・取引・属性をどこまで公開するか。個人情報をどこに保存し、監督・監査のときにどう開示するか。
4. 確定：チェーン上の確定（ファイナリティ）、業務の承認、資金の決済、原簿への反映を、どの順で終えたら完了とするか。
5. 権限：発行（mint）、焼却（burn）、凍結（freeze）、強制移転（forced transfer）、アップグレード、ノードの追加、障害時の訂正を、誰が承認するか。
6. 続けられるか：ネットワークの停止、RPC（ノードとの通信）の障害、reorg、鍵の侵害、運営者の離脱から、何時間で、どこまで戻せるか。

BISは、トークン化の仕組みを2つの層に分けています。資産と所有権を扱う中核の層と、ルールや統治を扱うサービスの層です（BIS Bulletin 72）。チェーンを選んでも、権利、決済、本人確認、資産の保管、例外の処理の責任が、自動で1つにまとまるわけではありません。6つの項目それぞれに、要件の番号、責任者、根拠、受け入れの試験を付けます。

公開型・コンソーシアム型・単一運営型は「誰を信じる前提か」で比べる

3つの形態は、向いている場面と、先に確かめるべき危険が違います。

• パブリック（許可不要）：独立した検証や、既存のウォレット・ツール・流動性とつながりたい場合に向く。先に確かめる危険は、個人・取引情報を推測されること、ガス代の変動、reorg、プロトコルの変更、取引の検閲への対応。
• コンソーシアム（許可型）：複数の組織で共同運営し、参加者が分かっていて、業務の要件に沿った秘匿が要る場合に向く。先に確かめる危険は、メンバーの離脱、合意に必要な数、責任の分担、アップグレードの合意、閉じたネットワークへの依存。
• 単一運営（許可型）：既存の業務とつなぎやすく、容量や変更の窓口を見通しやすい。先に確かめる危険は、一か所が止まる・支配されること、外から確かめにくいこと、特定ベンダーへの依存、運営者が破綻したときに続けられるか。

参加・検証・データの見え方・変更の統治まで並べた比較表は、後半の「実装する人向けの詳細」にあります。

「許可」の範囲は、2段に分けて考えます。ネットワークに参加できる組織を限ることと、資産を持ったり移したりできるウォレットを限ることは、別の話です。

たとえばERC-3643は、許可された人だけが持てるトークンの規格です。パブリックなネットワークの上でも、Identity Registry（本人情報の登録簿）とComplianceで、受け取る人の資格と移転のルールを判定できます（ERC-3643 Final仕様、実装の詳細はERC-3643の許可型トークン設計）。反対に、許可型のネットワークでも、ノードの参加資格だけでは表せないものがあります。資産ごとの販売できる国、保有の上限、売れない期間（ロックアップ）です。

Hyperledger Fabricは、身元（identity）とポリシーにもとづく許可型のネットワークです。チャネル（参加者の一部だけで台帳を共有する仕組み）などで、データを共有する範囲を設計します（Hyperledger Fabric Identity公式Docs）。Cordaでは、notary（公証ノード）が、同じ状態を二重に使うことを防ぐ役目を担います（R3 Corda Notaries Docs）。比べるのは名前ではありません。採用するバージョンの実装と運用する人が、要件を満たす証拠です。

国内外のRWAで使われている基盤の例（2026年9月24日時点）

候補を自社に当てはめて考えやすいよう、形態ごとの実例を挙げます。どれも特定のチェーンをすすめるものではありません。後で述べる失格条件と試験で、同じように評価する対象です。

• パブリック：BlackRockのトークン化MMF「BUIDL」は、Ethereumで始まり、Arbitrum、Avalanche、Optimism、Polygon、Solana、Aptosなどへ広がっています（Securitize）。
• パブリック上の専用チェーン：国内STの基盤Progmatは、Corda 5からAvalancheの専用L1へ、既存のSTを全件移したと2026年7月に報じられました（Japan FinTech Observer）。
• コンソーシアム：BOOSTRYの「ibet for Fin」は、参加する金融機関が共同で運営するコンソーシアム型の基盤です。社債や不動産などのSTに使われています（ibet for Fin）。
• 秘匿性を重んじた許可型のネットワーク：Canton Networkは、取引の当事者だけが該当する部分を見られる設計です。金融機関のトークン化資産や担保の移転に使われています（Canton Protocol）。

国内のEthereum互換チェーンはJapan Open Chain徹底解説、許可型の実行環境を持つL2はzkSync Prividium徹底解説で個別に扱っています。

点数を付ける前に、1件でも当たれば落とす条件を置く

冒頭の評価表のように、性能を40点、費用を20点と足し合わせると、秘密鍵の単独管理や訂正できないことを、高いTPSで打ち消せてしまいます。規制の対象になる資産では、まず譲れない点を合格か不合格かで判定します。合格した候補だけを、費用・開発のしやすさ・周辺ツールの充実度で順位付けします。

確かめる点ごとの失格条件と、PoCでの確かめ方は次のとおりです。

候補に求める証拠（データの持ち方、権限表、手順書など）は、後半にまとめました。

金融庁の監督指針は、電子記録移転有価証券表示権利等に使うネットワークのリスクについて、続けて審査する観点を示しています。必要に応じて専門家の検証を経る、などです（金融商品取引業者等向けの総合的な監督指針 IV-3-7）。採用のときに1回だけ監査報告を出すのでは足りません。変更の後も同じ要件を確かめられる証拠を、出し続ける仕組みが必要です。

「確定」は秒数ではなく、権利・資金・原簿が取り消せなくなる時点で決める

ブロックが作られる間隔、承認の回数、ファイナリティ、業務の完了は、同じ意味ではありません。

Ethereum PoSでは、区切りのブロック（チェックポイント）がjustified（仮の合意）を経てfinalized（確定）になります。finalizedのブロックを覆すには、大きな経済的な罰を伴う条件があります（ethereum.org PoS Docs）。許可型のネットワークでも、公証ノードや順序付けのサービスが返した「成功」と、原簿の更新・資金の決済・顧客への通知の完了は、分けて扱います。

そこで取引ごとに業務の番号を付け、次のものを結び付けます。チェーン上のトランザクションハッシュ、ブロックか公証ノードの記録、使ったポリシーの版、原簿の記録、決済の指図、承認の記録です。

取引の状態は、少なくとも次の流れで区別します。

受付 → チェーンで受理 → チェーン上で確定 → 原簿に記帳 → 資金を決済 → 完了（例外は保留）

通信が途中で切れても、新しい番号で送り直してはいけません。同じ番号で、今どこまで進んでいるかを照会します。状態の英語名は後半に載せました。

証券と資金を同時に扱う場合も、同じチェーンに置くだけでDvP（証券と資金を同時に受け渡すこと）が完成するわけではありません。証券側と資金側のそれぞれの確定、失敗したときの埋め合わせの処理、締めの時刻を合わせます。具体的な状態の移り方はトークン化証券のアトミックDvP設計で補足しています。

プライバシーは「誰が、何を、いつ読めるか」で試す

トークンを持てる人を許可リストで限っても、公開された残高、時刻、相手、ガス代を払った人から、取引の関係を推測できる場合があります。反対に、プライベートなネットワークでも、全ノードが平文を持ち、運用者がバックアップを見られるなら、機密はあまり守られていません。「公開か非公開か」の二択では、こうした漏れ方をとらえられないのです。

秘匿の要件は、「誰が」「どの項目を」「いつ」「どの細かさで」読めるかに分けて決めます。

• 投資家・実質的な保有者の身元と、ウォレットのひも付け
• 残高、価格、数量、相手、時刻、資産の種類
• 検証ノード、RPC事業者、インデクサー、カストディアン、監査人からの見え方
• ふだん、障害の調査のとき、規制当局・監査への対応のとき、保存期限の後の開示

ゼロ知識証明（ZK）や完全準同型暗号（FHE、暗号化したまま計算できる方式）を使っても、残る課題があります。入力するときの本人確認、鍵の管理、メタデータ、失効、障害時の開示です。方式ごとに誰を信じる前提かはオンチェーン金融のプライバシー設計で整理しています。

PoCでは、わざと壊しても守られるべきことが守られるかで合否を決める

PoCの目的は、デモを動かすことではありません。候補の基盤が失格条件に当たらないという証拠を、早く得ることです。候補ごとに同じ資産、参加者、ポリシー、取引量を使い、次の試験を自動で回します。

1. 権利が保たれるか：発行・移転・償還・強制移転の後も、トークンの残高、原簿、保管、資金の対応が1つに決まる。
2. 二重に処理しないか：APIのタイムアウト、呼び出し側の送り直し、出来事の取り直しがあっても、同じ業務の番号から二重に発行・記帳しない。
3. 確定の障害：reorg、検証者・公証ノード・順序付けサービスの停止、ネットワークの分断、遅れの後も、確定していないものを完了扱いしない。
4. 資格の変更：ウォレット、運用者、ノードの失効と取引をぶつけ、禁止した取引を断るか、保留の勘定（SUSPENSE）に切り分ける。
5. 秘匿性：ノード、RPC、インデクサー、ログ、バックアップ、分析ツールから、禁止した項目を復元できない。
6. 特権の侵害：発行、一時停止、アップグレード、メンバー追加の鍵を1つずつ侵害させ、被害が及ぶ範囲と気づくまでの時間を測る。
7. 復旧：スナップショット、出来事、原簿から新しい環境へ戻し、RPO（許せるデータの損失）とRTO（復旧にかかる時間）を実際に測る。
8. 容量：平均だけでなく、ピーク、一括処理、月末、やり直しを流し、p95/p99の遅れ（遅いほうから5%・1%の境目）、失敗率、たまった処理がはけるまでの時間を測る。

結果には、あとから同じ判断を確かめられる情報を残します。要件の番号、試験データ、ソフトウェア・コントラクトのコミット、ネットワークの設定、時刻、トランザクションID、期待した値、実際の値、判定した人です。

BIS/CPMIは、トークン化について、統治、法的な不確かさ、運用・サイバーのリスク、相互運用性などを横断して検討しています（CPMI「Tokenisation in the context of money and other assets」）。性能のベンチマークだけでは、選定の証拠になりません。

総費用には、チェーンの手数料以外の運用の責任も入れる

公開型なら、検証ノードを自分で動かさなくても、やることがあります。RPCの冗長化、ガス代の調達、プロトコルの変更の追跡、インデクサー、MEV（取引の並べ替えで利益を得る行為）・取引の検閲の監視です。許可型なら、ガス代が固定か不要でも、参加する組織でノード、証明書、メンバーの管理、合意形成、アップグレード、災害復旧の環境を保ちます。

少なくとも3年の想定で、次のものを見積もります。

• 発行・移転・償還のふだんの量、ピーク、やり直しに要るトランザクション費用
• RPC・ノード、インデクサー、鍵の管理、監視、SIEM（ログを集めて異常を見つける仕組み）、バックアップ、災害復旧の固定費
• プロトコル・コントラクトのアップグレード、監査、脆弱性への対応、メンバー変更の人件費
• 障害時の手作業、突き合わせ、顧客対応、規制・監査への報告の費用
• ベンダー・コンソーシアムからの退出、データの書き出し、コントラクトの配置し直し、ウォレットの移行の費用

パブリックのリスクに挙げたとおり、ガス代は変動します。そのため、特定のチェーンの今の手数料を、固定の値として採用の理由にはできません。基本・ピーク・ストレスの3つの想定で、単価、数量、為替、復旧の作業時間を変えてみます。どの前提で順位が入れ替わるかを確かめます。

採用するときに、やめる条件と移せるかどうかまで決めておく

運用中の基盤を別のチェーンに移す判断は、実際に起きています。前に挙げたProgmatの例です。移すには、身元の情報や資産の目録を書き出せる形、止める順番、記録の残し方が要ります。いざ移すと決めてから用意し始めると、そのあいだも古い基盤を使い続けることになります。ですから「将来必要なら移す」では遅すぎます。

採用のときに、撤退の条件を決め、その基準値と測り方も決めておきます。条件の例は、停止時間、確定の悪化、検証者の集中、重大な脆弱性、プロトコルの変更、手数料、ベンダーのサービス水準、メンバーの数、監査での指摘です。移すための準備は、次のとおりです。

複数のチェーンにいつも展開する場合は、移す準備とは別に、供給量、身元の情報、メッセージの確定を統制します。詳しくはトークン化資産のマルチチェーン相互運用設計を、ブリッジそのものの設計はクロスチェーンブリッジの開発・設計をご覧ください。

選定の成果物は「おすすめのチェーン名」ではなく、たどれる判断の根拠一式

最後にまとめるものは、次のとおりです。

• 要件と責任の分け方、候補ごとの失格条件、想定する攻撃、データの流れ
• 権限表、確定の方針、PoCの結果
• 総費用の前提、障害対応の手順書、撤退の条件

1つひとつの結論を、要件の番号と証拠にたどれるようにしておきます。そうすれば、プロトコル、法令、業務の量が変わったとき、選定を全部やり直さずに、影響する部分だけを評価し直せます。

実装する人向けの詳細

ここからは、評価と試験を実際に組むアーキテクト向けに、前半で後回しにした表と状態名をまとめます。

形態ごとの比較表

失格条件ごとに候補へ求める証拠

取引の状態名

各取引へbusiness_transaction_idを付け、状態は少なくともREQUESTED、CHAIN_ACCEPTED、CHAIN_FINAL、LEDGER_POSTED、CASH_SETTLED、COMPLETED、SUSPENSEを区別します。タイムアウト後は新しいIDで再送せず、同じIDの現在地を照会します。

XTELAができること

私たちは、規制対象資産のブロックチェーン選定で、要件と失格条件の整理、候補ごとのアーキテクチャ案、障害注入を含むPoC、監視・照合・移行の設計と開発を行います。候補チェーンを同じ試験で並べ、貴社が採否を決めるための証拠一式を作るところまで担います。法的な判断が必要な論点は弁護士と連携して進めます。選定の進め方はお問い合わせから相談できます。

主要参考資料

• 金融庁「金融商品取引業者等向けの総合的な監督指針 IV-3-7」（2026年8月12日確認）
• 日本銀行デジタル通貨フォーラム「セキュリティ・トークン（ST）とCBDCについて」
• CPMI「Tokenisation in the context of money and other assets」
• BIS Bulletin 72「The tokenisation continuum」
• ethereum.org「Proof-of-stake」
• Hyperledger Fabric「Identity」
• R3 Corda「Notaries」
• Ethereum ERC-3643 Final仕様
• Securitize「BlackRock BUIDL」（2026年9月24日確認）
• BOOSTRY「ibet for Fin コンソーシアム」（2026年9月24日確認）
• Canton Network「Canton: A privacy-enabled blockchain protocol」（2026年9月24日確認）
• Japan FinTech Observer「Progmat Completes Avalanche Migration」（2026年7月13日）

資料の確認日と注意

法令・監督資料と技術仕様は2026年8月12日に、国内外の基盤の採用例は2026年9月24日に確認しました。一般的な技術情報です。法令・監督指針・プロトコル・手数料は更新されるので、採用するときは、対象の資産・法域・バージョンの一次資料と契約を、専門家とあわせて確かめてください。