RWA事業を始める前に決めるべき技術要件｜チェーン選定より重要な権限・復旧・撤退の設計

執筆・監修：XTELA JAPAN株式会社 小幡拓弥

RWA事業では、トークンを発行した後も、裏付けとなる資産や権利を長期にわたって管理する必要があります。その際に考慮したいのが、ブロックチェーン基盤や開発会社、運用担当者が、事業の途中で変わる可能性です。

だからこそ、チェーンの性能やコストを比較する前に、管理権限の所在を明確にしておくことが重要になります。権限が曖昧なまま運用を始めると、障害発生時に必要な対応が取れず、復旧そのものが困難になるおそれもあるでしょう。

本記事では、ブロックチェーン開発に携わってきたXTELA JAPAN株式会社の小幡拓弥氏の知見や実務経験をもとに、RWA事業の開始前に決めておきたい技術要件を解説します。

RWAは「発行して終わり」ではなく「長く運用する事業」

RWA事業の特徴は、ブロックチェーン上のトークンだけでなく、その裏付けとなる現実の資産や権利も管理し続けなければならない点にあります。

例えば、不動産をトークン化した場合、発行後も権利関係や取引記録、資産の管理状況などを継続的に把握する必要があります。

こうした運用は長期にわたるため、担当者の退職やシステム障害、事業環境の変化によって、当初の管理体制を維持できなくなる可能性も考えられます。

Progmat、Avalancheへ移行

画像：Avalanche／移行内容の出典：Progmat公式発表（2026年7月13日）

実際に、事業の途中でブロックチェーン基盤を変更するケースもあります。

デジタル証券の発行・管理基盤を提供するProgmatは、2026年7月13日、既存のセキュリティトークン案件をCorda 5からAvalanche L1へ移行したと発表しました。移行対象は4,520億円超にのぼり、将来的なマルチチェーン対応を見据えた基盤整備も進めています。

参考：株式会社Progmat - Progmat基盤のAvalanche連携完了について

この事例からも、ブロックチェーン事業では、運用開始後の基盤変更を想定した設計が重要であることがわかります。

実際の開発現場でも、開発段階では想定していなかった問題が、運用開始後に明らかになるケースは少なくありません。

特にRWAでは、ブロックチェーン上のトークンだけでなく、その裏付けとなる現実の資産や権利も管理しなければなりません。

だからこそ、システムの構築方法だけでなく、管理権限の所在や障害時の対応、将来の移行・撤退まで、事業開始前に設計しておくことが重要です。

事業開始前に答えるべき4つの問い

RWA事業の技術要件を整理する際、チェーンの性能や手数料の比較から始めるケースがあります。しかし、それ以前に確認すべきなのが、運用や事業継続に関わる次の4つの問いです。

これらの問いは、それぞれ独立したものではありません。

例えば、権限の所在が不明確であれば、障害発生時の判断や復旧が滞る可能性があります。また、ソースコードや運用情報を引き継げなければ、システムの移行や事業の終了にも支障が生じるでしょう。

こうした運用上の問題は、要件定義の段階で洗い出し、あらかじめ対応方針を決めておくことが重要です。

ここからは、この4つの問いに沿って、具体的にどのような設計が必要になるのかを見ていきます。

権限設計：管理者の選定と鍵・ウォレットの権限設計

RWA事業では、誰がウォレットの運用責任を負い、秘密鍵をどのような方式で管理するのかを明確にしておく必要があります。

また、スマートコントラクトの管理者権限についても、権限を変更できる人、操作を承認する人、実際に操作する人を区別しておくことが重要です。

ブロックチェーンではウォレットを容易に作成できるため、管理対象が増えるにつれて、各ウォレットの管理者や用途を把握しにくくなります。

「誰がどこにいくら持っているかわからない」状態は危険

開発・運用の現場で特に注意したいのが、「誰がどこにいくら持っているかわからない」という状態です。

ウォレットは簡単に作成できるため、管理していなければ銀行口座が次々と増えていくような状況になります。

ブロックチェーン上ではアドレスを確認できても、それだけでは誰が管理しているのか、何のために使っているのかまではわかりません。

アドレスと管理者を対応付けた台帳がなければ、「このウォレットは何のために作ったのか」と確認する場面が増え、会計処理や資金照合にも支障が生じます。

こうした混乱を防ぐには、アドレスごとに管理者・用途・残高を整理した台帳が欠かせません。

数百の秘密鍵を管理する現場で見えた課題

小幡氏は、過去にクライアントのウォレットを含め、数百もの秘密鍵を管理した経験があるといいます。

秘密鍵を紙に書いて金庫に保管する方法は、一見すると安全に思えるかもしれません。しかし、管理する鍵が数百にもなると、どの鍵がどのウォレットに対応しているのかを把握するだけでも大きな負担になります。

こうした経験からも、技術的な安全性だけでなく、人が日常的に無理なく運用できる仕組みの重要性がうかがえます。

RWA事業でも、管理するウォレットが増えることを想定し、管理者や用途を記録した台帳と、定期的に管理状況を確認する体制が求められます。

「退職者が鍵を持ったまま」は特に危険

もう一つ注意したいのが、スマートコントラクトの管理者権限を持つ秘密鍵です。

例えば、秘密鍵を保有していた担当者が退職した場合、単に「パスワードを引き継いだ」だけでは十分とはいえません。

退職者が引き続き秘密鍵を知っている以上、不正利用や漏洩のリスクが残るためです。こうしたリスクに対応するには、新しい鍵への切り替えや、管理者権限の変更が必要となります。

ただし、ウォレットやスマートコントラクトの仕様によっては、権限の変更が難しい場合もあります。特に、唯一の管理者権限を失い、代替の変更手段も用意されていなければ、コントラクトの再構築やシステムの移行が必要になる可能性もあります。

図解：ブロックチェーン・スマートコントラクトの管理者権限

重要なのは、誰が管理者となり、誰が秘密鍵を保有し、誰の承認によって権限を変更できるのかを明確にしておくことです。

管理権限の設計は、単なる技術上の問題ではありません。経営管理や内部統制の一環として考える必要があります。

障害時の復旧：止める判断と訂正できない記録への対応

RWA事業では、誤送金や秘密鍵の紛失、トークンの誤発行など、さまざまなトラブルを想定しておく必要があります。

障害が発生した際に誰が判断し、どのような操作を行えるのかも、開発前に決めておきたい重要な項目です。

例えば、障害発生時の対応は、次のような流れが考えられます。

• 異常を検知した担当者が報告する
• 影響範囲を確認し、責任者が必要な停止措置を判断・承認する
• 原因を調査し、復旧方法を検討する
• 責任者の承認を経て、権限を持つ担当者が復旧作業を実施する
• 残高や取引データを照合し、再開までの対応を記録する

図解：障害発生時の基本フロー

ただし、実際に停止や復旧の操作ができるかどうかは、採用するチェーンやスマートコントラクトの仕様によって異なります。

トークンを誤発行した場合、誰がどう対応するのか

例えば、実際の裏付け資産に対して、誤って多くのトークンを発行してしまったケースを考えてみましょう。

この場合、まず発行対象や数量、保有者、取引状況を特定する必要があります。

そのうえで、取引の一時停止や過剰発行分の償却（バーン）、権利関係の訂正などを検討します。

ただし、トークンがすでに第三者へ移転している場合には、保有者の権利関係やコントラクトの仕様を確認しなければなりません。発行者が一方的に償却できるとは限らないため、技術担当者だけでなく、事業責任者や法務担当者も含めた判断が必要です。

ここで重要なのは、訂正作業を実施する権限と、その作業を承認する権限を分けることです。

例えば、次のような役割分担が考えられます。

※一般的な役割分担を示した想定例であり、実際の対応は事業の法的構成やコントラクトの実装によって異なります。

また、RWA向けのトークン規格であるERC-3643には、投資家が秘密鍵を紛失した場合に備え、本人確認や権限を持つ管理者による操作を通じて、新しいウォレットへトークンを移すための回復機能が定義されています。

ただし、これは失われた秘密鍵そのものを復元する機能ではありません。また、発行者側の管理者権限を失った場合に、同じ方法で対応できるとは限らない点にも注意が必要です。

参考：Ethereum Improvement Proposals - ERC-3643

技術サイドの内部統制が追いついていない

従来の企業における資金管理では、申請書やワークフロー、上司の承認といった内部統制の仕組みが整備されています。

一方、ブロックチェーンでは資金の移動と技術的な操作が密接に結びついているにもかかわらず、技術面の内部統制が十分に整っていないケースがあります。

開発現場では、スマートコントラクトが増えるほど管理対象も増え、全体を把握しにくくなるという課題があります。

設計の良し悪し以前に、そもそも内部統制を十分に意識しないまま、開発や運用が進んでしまうこともあります。

そのため、障害発生時の原因調査や修正方法だけでなく、誰が停止を判断し、誰が対応を実施し、どの条件を満たせば運用を再開できるのかまで、あらかじめ設計しておくべきでしょう。

秘密鍵を紛失した場合、どう復旧するのか

秘密鍵を紛失すると、ウォレットを操作できなくなるおそれがあります。ただし、復旧できるかどうかは、事前にどのような仕組みを導入しているかによって異なります。

従来のウォレットでは、秘密鍵や復元フレーズを失い、ほかに復旧手段がなければ、資産へのアクセスを取り戻すことは困難です。

一方、近年はMPC（マルチパーティ計算）などを活用したウォレット管理も広がっています。

MPCでは、秘密鍵に関わる情報を複数の要素に分散して管理することで、単一の鍵や担当者への依存を減らす設計が可能です。

小幡氏も、クライアント向けの開発で、メールアドレスを利用したウォレットの仕組みを導入した経験があるといいます。

こうした仕組みを利用すれば、利用者が秘密鍵を直接管理しなくても、あらかじめ用意された認証・復旧手段によってウォレットへのアクセスを回復できる場合があります。

ただし、MPCやメール認証を導入すれば、あらゆる鍵の紛失に対応できるわけではありません。復旧の可否は実装や管理方式によって異なります。

また、RWA向けのトークン規格であるERC-3643には、投資家が秘密鍵を紛失した場合に備え、本人確認などを経て新しいウォレットへトークンを移すための回復機能が定義されています。

ただし、これはトークンへのアクセスを回復するための仕組みであり、失われた秘密鍵そのものを復元するものではありません。発行者側の管理者権限を失った場合に、同じ方法で対応できるとは限らない点にも注意が必要です。

参考：Ethereum Improvement Proposals：ERC-3643

RWA事業では、利用者のウォレットだけでなく、発行者や管理者の鍵を失った場合も想定し、それぞれの復旧手順を設計する必要があります。

ベンダーロックイン：何に依存しているかを把握する

RWA事業では、一度構築したシステムを長期間にわたって運用することになります。その間に開発会社が変わったり、特定の技術者がプロジェクトを離れたりする可能性もあるでしょう。

こうした状況に備えるには、特定の開発会社やサービスへの依存を減らすだけでなく、システムの引き継ぎに必要な情報を自社でも把握できる状態にしておく必要があります。

特に重要なのが、管理者権限に関わる秘密鍵と、稼働中のスマートコントラクトに対応するソースコードです。

デプロイされたコントラクトの元ソースコード

スマートコントラクトは、デプロイ時にソースコードからバイトコードへと変換されます。

ブロックチェーン上には基本的にバイトコードが記録されるため、元のソースコードやコンパイラの設定情報を保管し、稼働中のコントラクトと照合できる状態にしておくことが重要です。

開発の引き継ぎでは、「ステージング環境と本番環境でコードが異なる」「ブランチ管理が不十分で、どのコードが本番で使われているかわからない」といった問題が起こりえます。

こうした問題を避けるには、実際にデプロイされたコードの確認が欠かせません。

Etherscanでは、「Contract」タブの「Code」欄からソースコードの検証結果を確認できます。ただし、検証結果には「Exact Match」と「Similar Match」があり、両者の意味は異なります。

「Exact Match」は、公開されたソースコードを指定されたコンパイラ設定で再現した結果が、デプロイ時のコードおよびコンストラクタ引数と一致することを示す判定です。

一方、「Similar Match」は、別の検証済みコントラクトとのバイトコードの類似性に基づく判定です。コンストラクタ引数などに差異が残る可能性があるため、Exact Matchと同じ検証結果として扱うことはできません。

引き継ぎ時には、まず対象のネットワークとコントラクトアドレスを特定し、検証種別を確認します。そのうえで、公開ソースコード、コンパイラのバージョンや最適化設定、コンストラクタ引数、デプロイ済みバイトコードを照合することが重要です。プロキシ構成の場合は、実装先コントラクトのアドレスやコードも別途確認する必要があります。

なお、Etherscanの「Similar Match Method ID」は、取引データの関数識別子から呼び出し関数を推定した表示であり、ソースコードの一致を証明するものではありません。

参考：Etherscan公式 Types of Contract Verification ／ Navigating the Contract Code tab

こうした情報が整理されていなければ、システムを変更する際にも、まず現在の構成を調査するところから始めなければなりません。

開発段階からソースコードやデプロイ履歴を整理し、別の技術者でも本番環境の構成を把握できる状態にしておくことが重要です。

ブロックチェーン特有の難しさ

ブロックチェーンには、確定した記録を簡単に訂正したり、巻き戻したりできないという特性があります。

一般的なデータベースであれば、バックアップから以前の状態に戻せる場合があります。

一方、ブロックチェーンでは、確定した取引を原則として取り消すことはできません。誤った処理を修正する場合も、新たな取引による訂正や、コントラクトの再構築が必要になることがあります。

だからこそ、「現在動いているシステムが、どのようなコードや設定で構成されているのか」を正確に把握しておくことが重要です。

設計意図が十分に共有されないまま運用されていたり、プロトタイプとして開発したものが、そのまま本番環境で使われていたりするケースにも注意が必要でしょう。

AIを活用すれば、コードの解析や仕様の推測を効率化できる場合もあります。しかし、それだけで元の設計意図や運用上の判断まで正確に把握できるわけではありません。

秘密鍵やソースコードに加え、デプロイ履歴、コントラクトアドレス、設定情報、運用手順なども必要です。

ベンダーロックインを防ぐには、ソースコードや秘密鍵だけでなく、鍵管理サービス、外部API、運用ツール、特定の技術者が持つ知識なども含めて、依存関係を把握しておく必要があります。

そのうえで、どの情報と権限を自社で管理し、どの業務を外部に委託するのかを明確にしておくことが、将来の円滑な引き継ぎにつながります。

チェーン移行と撤退：採用する時点でやめる方法も決める

チェーンの移行や事業撤退を考える際には、技術的に移行・停止できるかだけでなく、資産や保有者の権利、取引記録をどう扱うかまで決めておく必要があります。

システムを技術的に停止できることと、事業を適切に終了できることは、必ずしも同じではありません。

移行の実務：チェーン分離と引き継ぎ項目

冒頭で紹介したProgmatの事例では、業務機能を特定のチェーンから切り離し、複数のチェーンに対応しやすい基盤を整備しています。

ただし、チェーンによって利用できる機能や実装方法は異なります。

移行時には、コントラクトの仕様や外部システムとの連携に加え、トークン残高、保有者の権利、取引履歴をどのように引き継ぐかも確認しなければなりません。

移行前後の二重処理をどう防ぐか、移行中の取引をどう扱うか、新しいシステムへいつ切り替えるかといった点も、あらかじめ業務手順として定めておきます。

チェーンを変更しても、現実資産に関する権利や契約上の責任がなくなるわけではありません。技術面の切り替えと、資産・権利・運用体制の引き継ぎを一体的に計画することが重要です。

撤退を見据えた実物資産の裏付け証明

事業撤退まで見据えるうえで、最初に考えておきたいのが、実物資産の裏付けをどう証明するかという問題です。

例えば、宝石50個を裏付け資産として、100個のNFTを発行すること自体は技術的に可能です。

もちろん、1つの資産を複数のトークンに分割する設計であれば、必ずしも問題とは限りません。しかし、NFT1個につき宝石1個と交換できる仕組みであれば、発行数量に対して裏付け資産が不足することになります。

つまり、トークンを発行できることと、約束した権利を実際の資産で裏付けられることは、別の問題なのです。

「実物資産をトークンとして扱う」と宣言するだけでは、裏付けの信頼性は担保できません。

資産の実在や数量を誰が確認し、どのような証拠を残すのか、あらかじめルールを決めておく必要があります。

ステーブルコインで準備資産の確認に監査が用いられるのと同様に、RWAでも第三者による確認や証明データの管理体制が重要になります。

参考：Steven S. McNew, Senior Managing Director and Global Practice Lead, Blockchain and Digital Assets「StockX Vault NFTに関する専門家証言報告書」

事業を終了する際も、トークンを発行したという記録が残っているだけでは十分ではありません。

保有者の権利や資産の取り扱い、証明資料の保存方法、関係者への説明、撤退時の責任分担まで決めておく必要があります。

RWA事業では、システムの構築だけでなく、事業を終了する際の手順まで見据えた設計が求められます。

まとめ：事業開始前の技術要件チェックリスト

RWA事業では、チェーンを選ぶ前に、権限の所在、障害時の判断と復旧、システムの引き継ぎ、移行・撤退時の対応を整理しておくことが重要です。

事業開始前に、少なくとも次の5項目を確認しておきましょう。

ブロックチェーンの開発において、技術的に実現できることと、それを事業として安全に運用し続けられることは別の問題です。

特にRWAでは、ブロックチェーン上の記録だけでなく、現実の資産や権利も扱います。技術的な安全性と、事業としての継続性の両方を考える必要があるのです。

「どう担保するか」はビジネス要件、「どう実装するか」は技術要件。

この2つを切り離さず、事業開始前にセットで考えておくことが、RWA事業の長期運用や将来の移行・撤退にも対応できる基盤づくりにつながります。

解説・技術監修

小幡 拓弥｜XTELA JAPAN株式会社

2015年からブロックチェーン技術に携わり、Ethereum黎明期からスマートコントラクトやWeb3プロダクトの開発に従事。ウォレット管理、ブロックチェーンを活用した事業開発、技術設計などの経験を持つ。現在はXTELA JAPAN株式会社にて、AI・Web3領域の技術開発に取り組み、事業構想から実装・運用までを見据えた技術活用を推進している。