デジタル証券（STO）の国内動向── 制度と技術の折り合いをどうつけるか

金融商品取引法の改正で電子記録移転有価証券表示権利等という区分が設けられて以降、国内のデジタル証券は不動産や社債を裏付けとする案件を中心に積み上がってきました。技術的な目新しさで語られる段階は過ぎ、いまは既存の証券インフラとどう共存させるかが実装上の主題になっています。

本稿では、法制度が権利をどう捉えているかを確認したうえで、その制約のもとでスマートコントラクトに何を担わせられるのかを整理します。移転制限の実装、権利者名簿との関係、そして二次流通の設計が中心になります。

制度が定める枠と、その帰結

国内のデジタル証券は、電子情報処理組織を用いて移転できる権利として位置づけられ、原則として第一項有価証券に相当する規制が及びます。この整理から導かれる実装上の帰結は明確で、移転が自由なトークンにはできないという点です。取得者の適格性確認を経ない移転が技術的に可能な設計は、制度と整合しません。

したがって、実装の出発点は移転制限をどこに置くかの選択になります。選択肢は三つあり、コントラクト側で許可済みアドレスのみ移転可能とする方式、移転そのものを発行者の承認を経る二段階にする方式、そしてチェーン上は記録に徹し移転の可否判断をオフチェーンの業務システムに委ねる方式です。

実務では、コントラクト側に許可リストを持たせつつ、リストの更新を業務システムから行う折衷が多く採られます。チェーン上で拒否できることに意味があり、同時に判断ロジックは可変であるべきだからです。

許可リストの粒度も設計事項です。アドレス単位で持つと、保有者が鍵を変更するたびに更新が要ります。投資家の識別子を別に持ち、アドレスとの対応表を管理する構成にすると、鍵の変更を対応表の更新だけで吸収できます。権利の主体と暗号鍵を分けて扱うことが、運用の柔軟性につながります。

また、移転制限には期間的な要素も含まれます。譲渡制限期間、投資家区分ごとの保有上限、募集後の一定期間における制限といった条件は、単純な許可リストでは表現できません。判断を外部に委譲する構成にしておくと、こうした条件を後から追加できます。

権利者名簿とチェーン上の記録の関係

ここが設計でもっとも誤解されやすい部分です。チェーン上の残高が法的な権利の所在を直接決めるわけではなく、多くのスキームでは権利者名簿が正として位置づけられます。チェーンは名簿の更新を裏づける記録として機能します。

この前提を置くと、実装の焦点は整合性の担保に移ります。名簿とチェーンが食い違った場合にどちらを優先し、どう修正するかを事前に決めておかないと、障害時に権利関係が宙に浮きます。実務的には、名簿側を単一の真実の源とし、チェーンへの反映が失敗した場合は再送で追いつかせる設計が扱いやすくなります。

// 移転制限は「拒否できること」に意味がある。
// 可否の判断ロジックは差し替え可能な外部コントラクトへ委譲する。
interface ITransferPolicy {
    function canTransfer(address from, address to, uint256 amount)
        external view returns (bool ok, bytes32 reasonCode);
}

contract SecurityToken {
    ITransferPolicy public policy;

    function transfer(address to, uint256 amount) external returns (bool) {
        (bool ok, bytes32 reasonCode) = policy.canTransfer(msg.sender, to, amount);
        require(ok, string(abi.encodePacked("transfer denied: ", reasonCode)));
        _move(msg.sender, to, amount);
        return true;
    }
}

スマートコントラクトに載せるべきもの、載せないもの

配当や利払いの分配をコントラクトで自動化する構想はよく語られますが、実装では注意が要ります。分配の原資は法定通貨で保有されることが多く、チェーン上の処理だけでは完結しません。またコントラクトはデプロイ後の修正が難しいため、税制や約款の変更に追随しにくいという性質があります。

判断の目安として、コントラクトには変更頻度が低く、改ざん耐性が価値になる処理を置きます。保有残高の記録、移転の可否判定、移転履歴の追跡がこれにあたります。一方、計算ロジックが制度変更に連動するもの、外部データを必要とするもの、例外処理が多いものは業務システム側に置きます。

アップグレード可能なコントラクトを採る場合も、誰がどの手続きで更新できるかを明示し、更新権限の管理を運用設計に含めます。更新できることは同時に改ざんできることでもあるため、権限分掌と多重署名が前提になります。

二次流通を成立させる条件

デジタル証券の価値提案として流動性の向上が挙げられますが、実際に二次流通が機能するには複数の条件が揃う必要があります。取引の場が用意されていること、価格形成に足る参加者がいること、そして決済が確実に完了することです。

技術面では、資金と証券の受け渡しを同時に成立させるDVP 決済の実現方式が論点になります。資金側が法定通貨のまま銀行口座を経由する場合、証券の移転と資金の移動を原子的に結びつけられません。この場合はエスクローや条件付き移転で近似することになり、その分だけ処理の状態管理が複雑になります。

資金側もチェーン上に載せられれば同時決済に近づきますが、その場合は資金の性質と規制上の扱いを別途整理する必要があります。ここは制度の動向を見ながら判断する領域です。

取引の場としては、私設取引システムを介する方式と、相対取引を仲介する方式があります。前者は価格の透明性が高い一方で参加者を集める必要があり、後者は少数の参加者でも成立しますが価格形成が働きにくくなります。裏付け資産の性質と想定する保有者層から、どちらが適しているかを先に決めておくと、システムの設計方針が定まります。

いずれの方式でも、約定から決済までの状態遷移を明示的に管理する必要があります。約定済みで未決済の状態、決済処理中の状態、失敗して差し戻された状態を区別できないと、障害時にどこまで戻すべきかが判断できません。

運用に入ってから効いてくる設計

発行時には見えにくく、運用開始後に効いてくる要素がいくつかあります。第一に鍵管理で、保有者が鍵を失った場合の再発行手続きを定めておかないと、権利が事実上凍結されます。名簿を正とする設計であれば、鍵の再割当てで復旧できます。

第二にチェーンの選定です。移行の可能性を考えると、特定チェーンの機能に深く依存した実装は避け、コントラクトのインターフェースと業務システムの境界を明確にしておく価値があります。第三に監査で、移転履歴とその判断根拠を長期保存できる形で残しておく必要があります。

チェーンの選定では、手数料の変動も運用コストに直結します。移転のたびに手数料が発生する構成では、その負担を誰が持つかを決めておく必要があります。発行者が肩代わりする設計にする場合、手数料が高騰した局面で処理が滞らないよう、上限と待機の方針を組み込んでおきます。

コントラクトの監査も、デプロイ前の一度きりで終わりにはできません。依存しているライブラリに脆弱性が見つかることがあり、アップグレード可能な設計であればその適用手順が、そうでなければ移行手順が要ります。発行時に運用終了までの手順を書いておくことが、長期の商品を扱ううえでは実務的です。

まとめ

国内のデジタル証券は、技術的な可能性を制度の枠にどう収めるかという実装の段階にあります。移転制限を差し替え可能な形で持たせ、権利者名簿を正としてチェーンを記録として使い、変更頻度の高いロジックは業務システムに残す。この構成が、現行制度のもとでは扱いやすい落としどころになります。

金融テクノロジー総合研究所では、デジタル証券基盤の設計、スマートコントラクトの監査、実世界資産のトークン化に関する調査・実装を受託しています。スキームの検討段階からご相談いただけます。お問い合わせよりご連絡ください。

FTL の技術スタックと受託開発の進め方は FTLの技術とは？ にまとめています。