トークン化資産を複数のチェーンに出すとき｜二重ミントを防ぐ4つの方式

あるセキュリティトークン（ST）の発行体が、1つのチェーンで出していた受益権のトークンを、別のチェーンでも使えるようにしようとしています。送る側のチェーンでトークンを消し、受け取る側のチェーンで同じ量を発行する。仕組みとしては単純に見えます。

設計を任されたアーキテクトは、こんな事故を思い浮かべました。送る側のチェーンで取引が1承認されたのを見て、受け取る側で発行した。ところがその後、送る側のチェーンで巻き戻り（チェーン再編）が起き、消したはずの取引がなかったことになる。同じ権利が2か所に存在する「二重ミント」です。

通信のタイムアウトを失敗と思い込み、新しい移転を作り直しても、同じことが起きます。

では、どう防ぐか。まず、権利と総発行量の正本をどの記録にするかを決めます。そのうえで、送った側で使えなくしてから、受け取った側で使えるようにする。この順番を、送り直し、巻き戻り、資格の失効が起きても崩れない形で作ります。

やり方は4つあり、どこから始めるかの目安もあります。以下、この発行体が決めていく順に見ていきます。

この記事でわかること

• 複数のチェーンに出す前に守る3つの約束と、4つのやり方の選び方
• 送った側で消えたのに届かないとき、巻き戻りや重複が起きたときの扱い
• 止め方、突き合わせ方、PoCで確かめる8つのこと

ブリッジそのものの仕組みと止め方の基本は、クロスチェーンブリッジの開発・設計で解説しています。

複数のチェーンに出す前に守る3つの約束

BISは、トークン化された請求権について、2つの層を区別しています。資産と所有権を持つ中心の層と、ルールや統治を持つサービスの層です（BIS Bulletin 72）。複数のチェーンにコントラクトを置いても、この役割分担は消えません。権利をどの記録で確定させるかは、チェーンを増やしても決めておく必要があるということです。

そこで、やり方を選ぶ前に、3つのことを決めます。資産を何が表すか。どの記録が権利を確定するか。どの状態を合計の発行量に数えるか。そのうえで守る約束は次の3つです。

1. 同じ権利を、2人が同時に持っている状態を作らない：同じ受益権・社債・持分を表す有効な残高が、同時に複数の持ち主に属さない。
2. 発行量をいつでも説明できるようにする：発行・償還を除き、全チェーンの有効な残高、移転中の残高、正規にロックした残高の関係を、いつでも説明できる。
3. 持ってよい人の判定を、どのチェーンでもそろえる：受け取る人、ウォレット、地域、商品の条件、凍結・失効を、実行する時点で、承認済みのルールの版で判定する。

日本のSTには、ブロックチェーン上の投資家の情報と受益権の原簿を連動させ、法律上の持ち主を管理する構成があります（日本銀行デジタル通貨フォーラム資料）。どの記録が法的な正本かは、商品・契約・地域で変わります。技術の側では、その結論を、資産のID、原簿を更新する順番、訂正の権限、監査の記録に組み込みます。

4つのやり方を、「権利を何が決めるか」で比べる

4つのやり方は、権利の残高を動かすかどうかで2つずつに分かれます。上の2つは動かさず、下の2つは動かします。

各チェーンでの見え方と、発行量の数え方は後半の表にまとめています。

正本台帳＋遠隔操作は、権利の残高を動かさず、別のチェーンのアプリから正本へ命令を届けます。つながりが乱れても、権利の写しは増えにくいのが利点です。一方で、正本が止まると、つないだ先すべてに響きます。また、命令はチェーンをまたいで届くので、別のチェーンのアプリからは、すぐに結果が返る処理のようには見せられません。

ミラーは、ほかのチェーンへ残高や属性の写し（スナップショット）を配ります。ミラー側のトークンを移せるようにすると、権利との境目があいまいになります。そこで、画面とコントラクトの窓口で、次のことをはっきり示します。参照専用であること、写した時点、元のブロック、原簿との法的な位置付けです。

ロック・ミントは、今あるトークンを送る側のプールに預けて動かなくし、受け取る側で対応するトークンを発行します。Swiftの相互運用の実証報告には、こうした記録があります。ロック・ミントは総発行量を見通しやすいという意見がある。一方で、ラップ版のトークンの法的な根拠、ロックした資産、コントラクトの持ち主の責任が論点になる（Swift公式実証報告）。

バーン・ミントは、送る側の残高を消してから、受け取る側で同じ量を発行します。ロックした残高は残りません。その代わり、次のことを発行体の1つの管理の仕組みで扱う必要があります。全チェーンの発行の権限、移転中の量、受け取る側でまだ実行されていないときの請求権です。特定のプロトコルを使うだけで、この統制が自動でできあがるわけではありません。

ここから、どこから始めるかの目安が出てきます。権利を動かさずに、ほかのチェーンの機能を使いたいだけなら、正本台帳＋遠隔操作かミラーから始めます。権利の残高を動かさないので、新たに信頼しなければならない相手を増やさずに済むからです。流通そのものを複数のチェーンに広げる段階になったら、ロック・ミントかバーン・ミントを選びます。決め手は、発行体が全チェーンの発行の権限を統制できるかです。

どのチェーンでも、同じ資産だと分かるようにする

コントラクトのアドレスやトークンの記号は、チェーンごとに違います。同じ名前のトークンも作れます。ですから、資産を見分けるのには使えません。発行体の側で管理の記録を持ち、変わらない資産のIDを付けます。記録に持たせる項目は後半にまとめています。

小数の桁数（decimals）にも注意が要ります。チェーンによって桁数が違うと、桁の多いチェーンから少ないチェーンへ送ったとき、端数が受け取る側で表せません。

Chainlink CCIPの公式のToken Pools Docsも、この点を説明しています。桁数が違うと丸めが起きる。ロック・リリースでは送る側のプールに端数が残り、バーン・ミントでは受け取る側の発行量に含まれない。そのうえで、できれば同じ桁数を使うこと、違う場合はTokenPool v1.6.0以降を使うことを勧めています（CCIP Token Pools）。

できれば全チェーンで同じ桁数にします。違う場合は、いちばん小さく送れる単位、端数の勘定、行って戻る試験を仕様に入れます。

発行量の見張り方にも注意が要ります。移転の途中の量や、ロックした量があるので、各チェーンの発行量を足すだけでは全体を見張れません。やり方ごとに、次の関係が成り立ち続けるかを見ます。

• バーン・ミント：発行を認めた総量＝各チェーンで流通している量＋送る途中で消した量
• ロック・ミント：出回っているラップ版の量が、対応する元のトークンのロック量を超えない

発行の権限で作った量と、チェーン間のメッセージから生まれた量も分けて数えます。

送り先のチェーンには、「保有してよい」という判定結果だけを渡す

STでは、受け取る人がその商品を持ってよく、送る人と受け取る人の組み合わせが移転のルールを満たす必要があります。ですから、送り先のウォレットが技術的に受け取れるだけでは足りません。

ERC-3643は、この2つを別々に確かめる作りです。本人が確認済みかの判定と、移転してよいかの判定を分け、一時停止、凍結、回復、強制移転も標準の窓口に含めています（ERC-3643 Final仕様、実装はERC-3643の許可型トークン設計で詳しく扱っています）。

送り先が知りたいのは、その人が持ってよいかどうかです。ですから、チェーン間のメッセージに、氏名、住所、本人確認の資料は入れません。送り先が確かめられる、最小限の資格の証明か、承認への参照を使います。必要な項目は次のとおりです。

• 本人・身元のID、対象の資産のID、ルールの版
• 有効期限、発行した人、失効の確かめ方
• ウォレットとの結び付け、地域・投資家の区分など

個人情報は、必要な人と保存先に分けて持ちます。

送る側で適格でも、受け取る側で実行するまでに資格が失効することがあります。設計では、次のどれにするかをはっきりさせます。

• 受け取る側で実行するときに、最新のルールで確かめ直す。失効していれば、保留用のウォレットに取り置く。
• 短い有効期限の付いた承認を送る側で固め、その版を受け取る側が確かめる。
• 移転を始める前に両方のチェーンで予約し、ルールが変わったら、決済の済んでいない移転をはっきり取り消すか、確認に回す。

どれを選んでも、「資格が失効しているのに発行済み」「消したのに受け取れない」を、ふつうの失敗として捨ててはいけません。原簿の責任者、コンプライアンスの担当者、運用する人が処理できる例外の状態と、その記録を用意します。

送った側で消えたのに届かないときは、どうするか

送る側の取引が成功しても、受け取る側での実行はその後です。APIのタイムアウトを失敗と思い込んで新しい移転を作ると、二重ミントにつながります。

そこで、チェーン間の移転を1回の取引としてではなく、段階を追って進む記録として扱います。移転ごとに一意の番号を付け、送る側の取引、メッセージ、受け取る側の取引、資産、量、ルールの版を、1つの記録に結びます。段階は、おおよそ次のとおりです。

1. 依頼を受け付ける
2. 送る側の取引を送る
3. 送る側のロックか消去が、確定の基準を満たす
4. メッセージとルールを確かめ、受け取る側で実行できる状態になる
5. 受け取る側の取引を送り、確定する
6. 両方のチェーンと原簿を突き合わせて完了

どこかで様子が分からなくなったら、「不明・保留」として取り置きます。新しい発行や消去はしません。状態ごとのやり直しの決まりは後半の表にまとめています。

Circle CCTP（V2）も、段階を分けています。送る側で消し、チェーンの外で証明し、受け取る側で発行します。メッセージごとに、最低限必要な確定の水準も指定します。確定する前の段階で証明したメッセージを、確定済みとして証明し直す経路もあります（CCTP Technical Guide）。これはUSDCの例です。ただ、「送る側で受け付けられた」と「受け取る側を安全に実行できる」を分けるという考え方は、ほかのトークン化資産にも当てはまります。

受け取る側のコントラクトの誤りや手数料（ガス）の不足で、自動の実行が失敗することもあります。CCIPの公式Docsは、その場合の経路を説明しています。トークンの移転と受け取る側の処理を、すべて成功か、すべて取り消しかの形で巻き戻す。原因を直した後で、同じメッセージを手動で実行する（CCIP Manual Execution）。

このように、送る側で消えても、同じメッセージを後から実行できる場合があります。ですから、運用の画面には、「送る側で消えたから紛失」と出してはいけません。今どの段階にいて、何をやり直せるかを示します。

巻き戻り・順序の入れ替わり・重複を、ふつうに起きることとして試す

冒頭の事故は、送る側の出来事を1承認で確定とみなし、受け取る側で発行した後に、送る側が巻き戻ったときに起きます。発行量が増えてしまうのです。そこで、チェーンごとに確定の基準を決め、版を付けて管理します。ブロックの番号だけでなく、ブロックのハッシュ、取引のハッシュ、ログの位置も保存します。

メッセージは、遅れる、重なる、順番が入れ替わることがあります。「1回だけ、順番どおりに届く」と決めつけず、次のように作ります。

• 重複：同じメッセージは1回だけ使う。
• 順番の入れ替わり：ルールの更新、凍結、移転が前提にしている版を確かめ、前提がまだ届いていなければ保留する。
• 抜け：送る側の出来事を見て回った結果と、メッセージの状態を定期的に突き合わせ、届いていないものを取り直す。
• 長い停止：移転中のものを勝手に返金したり発行したりせず、やり方ごとに決めた「取り消せる時点」と承認の手順に従う。

Swiftの実証でも、例外の場面を試しています。同じ通し番号の使い回し、期限切れ、アドレスの不一致、誤ったチェーンID、中身の不一致などです。そのうえで、各出来事の状態を、今ある金融メッセージに対応させています。うまくいく流れだけを試すPoCでは、運用できるかを判断できません。ブリッジの検証者や署名鍵が破られたら何が起きるかは、Kelp DAOのハックで考えるブリッジセキュリティが具体例になります。

止めるときは、範囲を絞って止める

チェーンをまたぐ資産は、止めた瞬間にも、送る側・移転中・受け取る側に散らばっています。一時停止の権限を1つ置くだけでは、止めた後の資産の状態を説明できません。そこで、止める単位を次のように分けます。

• 資産全体、送る側のチェーン、受け取る側のチェーン
• レーン（チェーンの組み合わせと向き）、トークンのプール、特定のウォレット
• 発行・消去、メッセージを受け取る側

障害のときは、新しい受付を止めても、送る側ですでに確定したメッセージを、安全な保留の状態へ落ち着かせる必要がある場合があります。

権限の表には、誰が、どの記録にもとづいて、どの範囲を、何時間止め、誰が再開を承認するかを書きます。発行、消去、一時停止、アップグレード、遠隔での設定変更、流量の制限、身元情報の発行者の変更を、1本の鍵に集めてはいけません。マルチシグ、複数人の承認、実行までの待ち時間（タイムロック）、緊急権限の期限を組み合わせます。

金融庁の監督指針も、電子記録移転有価証券表示権利等に使うネットワークのリスクを、必要に応じて専門家の検証を経ながら、続けて審査する観点を示しています（金融商品取引業者等向け監督指針）。

突き合わせは、総量だけでなく移転1件ごとに行う

毎日の突き合わせでは、次の記録を比べます。各チェーンの有効な発行量、ブリッジ・プールのロック残高、消去・発行の出来事、移転中、保留、原簿、カストディの記録です。

合計が合っていても、投資家AとBの残高が入れ替わっていれば、不一致です。資産、ウォレット・身元、移転の1件ごとに差を追います。差の種類ごとの確かめ方は、後半の表にまとめています。

どの記録が法的な正本かは、商品・契約・地域で変わります。ですから、「チェーンの上がいつも正しい」「社内の原簿がいつも正しい」と、一律には決めません。資産ごとに、正本と、合わせる責任を決めます。訂正するときは元の出来事を消さず、処理の番号、理由、申請した人、承認した人、変更の前後、法務・業務の判断への参照を、追記だけで残します。

PoCで確かめる8つのこと

PoCの合否は、ふつうに送れた件数ではなく、3つの約束が守れるかと、復旧にかかる時間で決めます。

1. 資産のID、権利の正本、すべての置き先、小数の桁数、ルールの版、権限を、資産の目録からたどれる。
2. すべてのチェーンの組み合わせで、発行・移転・償還の後の発行量の関係と、端数の勘定が合う。
3. 送る側の巻き戻り、メッセージの重複・抜け・入れ替わり、受け取る側の巻き戻し、中継する人の停止を起こしても、二重ミントしない。
4. 資格の失効、ウォレットの凍結、ルールの更新が移転中の処理とぶつかっても、保留の状態に安全に収まる。
5. タイムアウトの後に新しい移転を作らず、同じ番号から今の段階を戻せる。
6. 資産・チェーン・レーン・ウォレットの単位で止め、承認済みの手順で再開できる。
7. 原簿、各チェーン、プール、メッセージの層、カストディを移転1件ごとに突き合わせ、差を見つけるまでの時間と復旧の時間を測れる。
8. アップグレード、発行・消去、一時停止、身元情報の発行者、流量の制限の権限が分かれていて、操作の記録が残る。

ここまでの設計は、特定のプロトコルやチェーンを勧めるものではありません。BIS/CPMIも、複数の基盤に分かれることで、流動性が縛られる、つなぎ方が長くなる、仕組みが複雑になる、第三者への依存が増える、といったことが起こりうると整理しています（Tokenisation in the context of money and other assets）。つなぐ先を増やす目的と、そのぶん増える信頼の相手・運用の手間を、同じ受け入れの表で評価します。

よくある質問

ブリッジとマルチチェーン展開は何が違いますか

ブリッジは、チェーンのあいだでメッセージや資産を運ぶ仕組みそのものです。マルチチェーン展開は、同じ資産を複数のチェーンでどう表し、どれを正本とし、発行量をどう保つか、という発行体の側の設計です。ブリッジを選んでも、3つの約束と突き合わせの仕組みは、発行体が別に持つ必要があります。

同じトークンを複数のチェーンに出しても問題ありませんか

権利の正本、全チェーンの発行量の関係、持ってよいかの判定を、1か所で管理できていれば可能です。チェーンごとに別々に発行し、合計を後から足し合わせる運用では、二重の権利や、資格のない人の保有を見つけられません。

実装する人向けの詳細

ここからは、この発行体で仕組みを作るアーキテクトと開発チームの話です。

4つの方式の表れ方と発行量の数え方

資産の管理レコード

• asset_id：法的権利・商品・受益権クラスを一意に表す不変のID
• network_id + contract_id：承認済みのデプロイ先。実装のハッシュ、decimals（小数桁数）、版を含む
• rights_version：分配、議決、償還、移転制限等の条件の版
• policy_version：保有資格、法域、保有上限、ロックアップ、凍結規則の版
• supply_role：正規、ミラー、ロック中、移転中、保留（suspense）の区分
• authority_set：ミント、バーン、一時停止、ポリシー更新、アップグレード、訂正の権限としきい値

供給量の監視式

単純なsum(totalSupply)ではなく、バーン・ミントならauthorized supply = Σ(active supply) + Σ(in-flight burned claims)、ロック・ミントならwrapped outstanding ≤ corresponding canonical lockedを続けて評価します。

保有資格の判定

ERC-3643では、Identity RegistryのisVerifiedとComplianceのcanTransferが分かれています。チェーン間で渡す資格の証明には、asset_idとpolicy_versionを含めます。

チェーン間移転の状態遷移

各移転に一意なtransfer_idを付け、送信元のトランザクションハッシュ、メッセージIDとnonce、送信先のトランザクションハッシュ、資産、数量、ポリシーの版を1つの記録に結びます。nonceは、同じメッセージの使い回しを断るための連番か一意の値です。

CCTP（V2）では、メッセージごとにminFinalityThreshold（最低限必要な確定の水準）を指定し、確定前に証明したメッセージを再証明（reattest）する経路があります。重複はtransfer_id + source eventまたはメッセージIDを一度だけ消費して防ぎます。

照合の差異と復旧の判断

関連記事

• トークン化資産の仕組みとユースケースの基礎はRWAトークン化の入門記事で扱っています。
• どのチェーンを候補にするかの選び方はRWAのブロックチェーン選定にまとめています。
• 証券と資金を同時に受け渡す設計はトークン化証券のアトミックDvP設計で解説しています。

XTELAができること

私たちは、トークン化資産を複数チェーンへ展開する際の方式選び、資産の管理レコードと供給量の監視、移転の状態機械、停止単位を分けた権限設計、移転単位の照合をまとめて設計し、開発します。reorgやメッセージの重複を注入するPoCで二重ミントが起きないことを確かめてから本番へ進めます。権利の正本をどこに置くかといった法的な判断が必要な論点は弁護士と連携して進めます。展開の相談はお問い合わせから受け付けています。

主要参考資料

• BIS Bulletin 72: The tokenisation continuum
• BIS/CPMI: Tokenisation in the context of money and other assets
• BIS FSI: Financial stability implications of tokenisation
• Swift: blockchain interoperability experiments results report
• Chainlink CCIP: Token Pools（2026年9月24日確認）
• Chainlink CCIP: Manual Execution（2026年9月24日確認）
• Circle CCTP Technical Guide（2026年9月24日確認）
• ERC-3643 Final: T-REX permissioned token standard
• 日本銀行デジタル通貨フォーラム「セキュリティ・トークン（ST）とCBDCについて」
• 金融庁「金融商品取引業者等向けの総合的な監督指針」

資料の確認日と注意

プロトコルの仕様と監督の資料は2026年8月13日に確認しました。Chainlink CCIPとCircle CCTPの記述は、2026年9月24日に確認し直しています。内容は公開情報にもとづく一般的な技術・業務設計の解説です。個別の資産の法的な分類、権利の正本、移転の対抗要件（権利を第三者に主張するための手続き）、本人確認、監督上の扱いは、専門家と所管部門の判断をシステムの仕様に反映してください。