技術ガイダンス：香港のステーブルコイン発行者向けスマートコントラクト実装ガイド

ステーブルコイン条例の正式可決を受け、香港金融管理局（HKMA）は2025年5月26日、「認可ステーブルコイン発行者に対する監督ガイドライン草案」を公表しました。これは、香港のステーブルコインエコシステムの安定性、セキュリティ、コンプライアンスを確保することを目的としています。このガイドラインは、認可ステーブルコイン発行者が遵守しなければならない規制要件と運用基準を詳述しています。

最近、スマートコントラクトのコンプライアンス実装について、SlowMistのセキュリティチームにご相談いただく機関が増えています。発行者がコンプライアンスに準拠したスマートコントラクトシステムをより深く理解し、導入できるよう、私たちは「香港ステーブルコイン発行者向けスマートコントラクト実装ガイド」を特別にリリースしました。このガイドは、明確な技術的アプローチと実践的な提案を提供し、香港ステーブルコインエコシステムの健全な発展を支援します。

パート1 インフラストラクチャとコンプライアンス戦略

このセクションでは、ステーブルコインシステムの高レベルのアーキテクチャ基盤を構築することを目的としています。これらのアーキテクチャ上の決定は、香港金融管理局（HKMA）のフレームワークにおける最も基本的な要件に基づいて行われます。ここでの選択は実装パス全体を決定し、設計の初期段階からテクノロジースタックにコンプライアンスが深く組み込まれることを保証します。

1. 基盤となる分散型台帳の選択

規制指令

ライセンシーは、使用する基盤となる分散型台帳技術（DLT）の堅牢性を評価する必要があります。この評価には、セキュリティインフラストラクチャ、一般的な攻撃（51%攻撃など）に対する耐性、トランザクションのファイナリティ保証、コンセンサス^{アルゴリズム1}の信頼性が含まれます。

スローミスト技術の説明

これは単なる技術の選好ではなく、中核的なコンプライアンス課題です。基盤となるブロックチェーンの選択には正式なデューデリジェンスが必要であり、評価プロセス全体を詳細に記録することで、規制当局による審査において十分な根拠を示す必要があります。基盤となる台帳の選択プロセスは、ステーブルコインシステム全体のセキュリティと安定性の方向性を決定づけるものです。

香港金融管理局（HKMA）が台帳の堅牢性を強調しているのは、本質的には、発行者に対し、実証されていない、過度に中央集権化されている、あるいはセキュリティに疑問のある新興ブロックチェーンの採用を避けるよう勧告しているに等しい。その安全性と安定性を証明する責任は、完全に発行者にある。発行者が、セキュリティが広く検証されていないチェーンを選択した場合、追加の補償的管理策を設計・実装する必要がある。

実装ガイド

成熟したパブリックチェーンを優先：EthereumやArbitrumといった、成熟度が高くセキュリティの高いパブリックブロックチェーンを優先することが推奨されます。これらのネットワークは、実証済みの耐性、大規模な検証ノードネットワーク、そして継続的な公的監視といった、自然な利点を備えています。高い攻撃コスト（経済的安全性）は、51%攻撃への耐性やトランザクションのファイナリティ確保に関する規制上の懸念に直接的に影響する可能性があります。
代替案の厳格な評価: コンソーシアムチェーンまたは他のタイプの分散型台帳を検討する場合、SlowMist セキュリティ監査などの厳密かつ定量化可能な比較分析を実施して、そのセキュリティ標準が主流のパブリックチェーンのセキュリティ標準よりも低くないこと、またはそれよりも優れていることを証明する必要があります。
リスク評価文書：評価報告書は、一般的な攻撃への耐性、コンセンサスアルゴリズムの種類、コード欠陥、脆弱性、脆弱性悪用、その他の^脅威2に関連するリスクを包括的に網羅し、これらのリスクがステーブルコインの発行、償還、および日常的な運用にどのような影響を与える可能性があるかを詳細に分析する必要があります。この文書は、規制当局に対して技術選択の慎重さを示すための重要な文書です。

2. コアトークン基準と規制機能の拡張

規制指令

この規制文書では、特定のトークン標準（ERC-20など）は規定されていません。ただし、発行、バーン、アップグレード、一時停止、再開、凍結、ブラックリスト登録、ホワイトリスト登録といった一連のコア管理機能の^実装が義務付けられています3。

スローミスト技術の説明

香港金融管理局は、ERC-20標準をはるかに超える機能を備えた「規制強化型」トークン標準を定義しています。この標準は、基本的なトークン流通機能だけでなく、運用上のセキュリティ、権限の制御性、リスクの追跡可能性も重視しています。コンプライアンス要件を満たしながらセキュリティを最大限に高めるには、広く監査され、コミュニティで認められた標準ライブラリ（OpenZeppelinなど）を採用し、それに基づいて機能を拡張するのが、最も効率的で安全な開発方法です。

実装ガイド

基本標準: トークンの均一性と、より広範なエコシステムにおける相互運用性を確保するために、ERC-20 が基本標準として採用されています。
機能拡張: 規制要件を満たすには、次の機能モジュールを統合する必要があります。

Pausable: すべてのトークンアクティビティのグローバルな一時停止と再開機能を実装するために使用されます。これは、重大なセキュリティインシデントに対応するための中核ツールです。

Mintable: ライセンス発行者が管理されたプロセスを通じて新しいトークンを鋳造し、発行されるトークンの量が十分な法定通貨準備資産に厳密に一致することを保証するという要件を実装するために使用されます。

Burnable: トークンを破棄する機能を提供します。具体的な実装では、この機能は権限によって厳密に制御され、ユーザーが自身でトークンを破棄することはできません。

Freezable: 特定のアカウント（疑わしい取引に関与したアカウントなど）のトークン転送機能を停止するために使用されます。

ホワイトリスト: 追加のセキュリティ対策を実装するために使用され、デューデリジェンスと承認に合格したアドレスのみがコアオペレーション（新しく発行された^{トークン4の}受信など）に参加できるようにします。

ブラックリスト：違法行為（マネーロンダリング、詐欺など）に関与するアドレスに対して、トークンの送受信を禁止するトランザクション禁止措置を実施します。ブラックリスト管理は、AML/CFTシステムと連携し、疑わしいトランザクションをリアルタイムで監視する必要があります。

アクセス制御：これは、洗練されたロールベースの権限管理システムを実装するための基盤です。職務分離5の要件を満たすため、すべての管理機能はこのモジュールを通じて制御する必要があります^。

3. 主なコンプライアンスモデル：ブラックリストとホワイトリストの選択

規制指令

継続的な監視に関しては、マネーロンダリング・テロ資金供与対策（AML/CFT）に関する協議文書で、「制裁対象または違法行為に関連していると特定されたウォレットアドレスをブラックリストに載せる」、あるいはより厳格な「ステーブルコイン保有者のウォレットアドレスのホワイトリスト、またはクローズドループモデル」 ^6など、さまざまな対策が提案されている。

スローミスト技術の説明

これは、システムアーキテクチャ全体の中で最も重要な決定ポイントであり、ステーブルコインのコンプライアンス運用のオープン性、実用性、複雑さを直接決定します。

ブラックリストモード：「デフォルトオープン」モード。デフォルトではすべてのアドレスが自由に取引でき、オンチェーンブラックリストに明確に識別され追加されたアドレスのみが制限されます。
ホワイトリストモード：「デフォルトで閉じている」クローズドループモード。発行者によって明示的に調査・承認され、オンチェーンのホワイトリストに追加されない限り、どのアドレスもトークンを保有または受け取ることはできません。

ホワイトリストモデルはAML（マネーロンダリング対策）制御機能を提供しますが、広く使用されるように設計されたステーブルコインの場合、厳格なホワイトリストシステムは、ステーブルコインが事前に審査された参加者間でのみ循環できることを意味し、柔軟なデジタル通貨というよりも、閉鎖的な銀行元帳システムに似ています。

したがって、規制当局も明確に言及しているブラックリストモデルと、規制当局が要求する強力なオフチェーン分析ツールを組み合わせることで、よりバランスの取れたソリューションが実現します。規制要件を満たすだけでなく、資産の実用性も維持されます。

設計面では、将来的に規制が強化されたりビジネスモデルが変化したりした際に、ホワイトリストモードへスムーズに移行・切り替えできるよう、アップグレード可能なシステム構築や両モードの同時実装が可能です。

実装ガイド

ブラックリストモード（デフォルトの推奨ソリューション） :

利点: 実用性が高く、広大な分散型金融 (DeFi) エコシステムとシームレスに相互運用できるため、ユーザーに使用ハードルが低く、スムーズなエクスペリエンスを提供できます。

デメリット: コンプライアンスは、不正なアドレスを迅速に検出してブロックするための強力なリアルタイムのオフチェーン監視および分析機能に大きく依存します。
実装方法: スマートコントラクトの転送機能にロジックチェックを追加して、トランザクションの送信元 (from) と受信者 (to) のアドレスがブラックリストに記録されないようにします。

ホワイトリストモード

利点: 最高レベルの AML/CFT 制御を提供し、修復ではなく予防を実現します。

デメリット: ステーブルコインの汎用性と採用性が大幅に制限され、ホワイトリストの管理に多大な運用オーバーヘッドが発生し、広く受け入れられる交換手段となることが困難になる可能性があります。

実装方法：スマートコントラクトの送金関数にロジックチェックを追加し、トランザクションの送信元（from）アドレスと受信先（to）アドレスの両方がホワイトリストに登録されていることを条件とします。操作の利便性を高めるため、専用のWebユーザーバックエンドシステムを開発して運用することを推奨します。

パート2 スマートコントラクトの実装

このセクションでは、スマートコントラクトのコア機能の詳細な青写真を示し、複雑な規制要件を特定のコードレベルのロジック、セキュリティモデル、および運用プロトコルに変換します。

1. 洗練されたアクセス制御システムを設計する

規制指令

高リスクな操作は、「単一の当事者が関連する操作を一方的に実行できないようにする（例：マルチ署名プロトコル経由）」ように設計する必要があります^。7.異なる操作の責任は適切に分離する必要があります。

スローミスト技術の説明

これは、強力なロールベースアクセス制御システム（RBAC）が必須であることを意味します。単一の「所有者」または「管理者」秘密鍵を使用する形式は、いかなる形でも準拠していません。

実装ガイド

職務分離を実現し、単一障害点や共謀のリスクを最小限に抑えるためには、マルチシグネチャウォレットによって管理される異なる組織または従業員に明確な役割を定義し、割り当てる必要があります^{8 。}各役割は特定の機能に限定し、すべての操作にはマルチシグネチャによる承認が必要であり、1人の従業員が複数の高リスクな役割を同時に担うことがないようにする必要があります。すべての操作はログに記録され、毎年第三者による監査を受ける必要があります。また、権限の割り当ては管理者または取締役会によって監督されます。

MINTER_ROLE: 有効な発行リクエストを受け取ったときにトークンユニットを作成し、準備資産プールの対応する増加に合わせて鋳造を行うことなど、ステーブルコインの鋳造操作を担当します。
BURNER_ROLE: 有効な償還リクエストを受け取ったときにトークンユニットを破棄するなど、ステーブルコインのバーン処理を担当します。
PAUSER_ROLE: 異常なイベント (セキュリティ上の脅威など) が検出されたときに、転送、鋳造、償還を一時的に停止するなど、ステーブルコインの操作を一時停止する責任を負います。
RESUME_ROLE: 停止イベントが解決された後、転送、鋳造、償還の再有効化など、ステーブルコイン操作の再開を担当します。
FREEZER_ROLE: 疑わしいアクティビティ (マネーロンダリングのリスクなど) が検出された場合、資産を一時的に凍結するなど、特定のウォレットまたはトークンの凍結と解凍を担当します。
WHITELISTER_ROLE: 許可されたウォレットアドレスの追加または削除 (ミントをホワイトリストに登録されたアドレスに制限するなど) を含むホワイトリストの管理を担当します。
BLACKLISTER_ROLE: 転送を防ぐために疑わしいウォレットをブラックリストに登録するなど、ブラックリストの管理と削除を担当します。
UPGRADER_ROLE: アップグレード可能なモデルが採用されている場合、脆弱性を修正したり機能を追加したりするために契約コードを更新するなど、スマートコントラクトのアップグレードを担当します。

表1: ロールベースアクセス制御マトリックス（RBACマトリックス）

次の表は、開発者と監査人が使用できる明確で直感的な仕様を示しており、各特権操作を必要なロールと制御タイプに明示的にマッピングしています。

2. 発行（貨幣発行）の仕組み

規制指令

発行は「慎重かつ堅実」でなければならない。発行は「裏付けとなる準備資産プールの相応の増加と一致する」必要がある。発行者は、資金と有効な発行要求を受け取った場合にのみ、顧客への発行を行うべきである9。

スローミスト技術の説明

スマートコントラクト自体は「完全準備金」要件を強制することはできず、また強制する必要もありません。代わりに、スマートコントラクトは管理された台帳の役割を担い、鋳造機関が主要な管理ポイントとなります。完全準備金の遵守は、オフチェーンで行われる監査検証可能な操作です。規制では、鋳造は「有効な発行リクエスト」と「資金の受領」という2つのオフチェーンイベントに結び付けられています。したがって、オンチェーンの鋳造関数は、これらのオフチェーン条件が満たされていることを検証できる信頼できるエンティティ（つまり、発行者自身）によってのみ呼び出されるように設計する必要があります。

実装ガイド

事前チェック: 鋳造関数を実行する前に、関数はターゲットアドレスがブラックリストまたは凍結状態にあるかどうかを確認する必要があります。

操作プロセス：

オフチェーン・デューデリジェンス：お客様は、必要なすべてのオフチェーンKYCおよびCDDプロセス10を完了します。さらに、AML/CFT規制では、一定の金額（例：HK$8,000）を超える取引関係を構築または不定期に行うお客様にCDD11の実施が義務付けられています。
資金受取：顧客は、発行者が指定した銀行口座に法定通貨相当額を振り込みます。
内部検証: 発行者の内部システムが資金の受領を確認し、それに応じて準備資産の会計記録を更新します。
オンチェーン実行：運用チームはマルチ署名トランザクションを作成して署名し、スマートコントラクトのミントトークン関数を呼び出し、新しく鋳造されたステーブルコインを顧客の事前登録および検証済みのウォレットアドレスに送信します。

3. 償還（破壊）メカニズム

規制指令

ライセンシーは、有効な償還請求を「可能な限り速やかに、かつ請求受領後1営業日以内に」処理しなければならない12。準備資産の引き出しは、「流通している指定ステーブルコインの額面価格の対応する減額と一致する」13。

スローミスト技術の説明

償還は、オンチェーンとオフチェーンのやり取りを含む2段階のプロセスです。償還プロセス中は、法定通貨の送金が失敗するリスクを考慮し、トークンの破棄は法定通貨の決済が確認される前ではなく、確認された後に行う必要があります。これにより、発行者は償還が最終的に失敗した場合にトークンを早期に破棄してしまうことを防ぐことができます。

発行者が先にトークンを破棄し、銀行振込が失敗した場合、対応する資産がないまま負債が発生します。逆に、発行者が先に法定通貨を支払ったものの、対応するトークンを破棄しなかった場合も、損失が発生します。

そのため、償還手続きにおいては、ユーザーはトークンを発行者が管理する指定アドレスに送金する必要があり、発行者は法定通貨での支払い完了後にトークンを破棄します。このモデルにより、ユーザーはトークンを償還のために「ロック」することができ、発行者は法定通貨での支払い義務を履行した後にのみトークンを破棄するため、双方にとってより安全な操作プロセスが実現します。

実装ガイド

償還の準備: ユーザーはまず、償還するトークンを発行者が管理する指定のアドレスに転送する必要があります。

操作プロセス：

オフチェーンリクエスト：ユーザーは発行者のプラットフォームを通じてオフチェーン償還リクエストを送信します。リクエストを処理する前に、発行者は顧客に対して適切な顧客デューデリジェンス（CDD）を実施する必要があります。
システム検証: 発行者のシステムはリクエストの有効性を検証し、ユーザーがチェーン上で対応するトークン転送操作を完了したかどうかを確認します。
法定通貨による支払い: 発行者は、相当額の法定通貨を、ユーザーの事前登録および確認済みの銀行口座に送金します。
オンチェーン破棄: 法定通貨の転送が成功したことを確認した後、BURNER_ROLE を保持しているマルチ署名ウォレットは破棄関数を呼び出して、指定されたアドレスから対応する数のトークンを破棄します。

4. 緊急時の制御を実施する：停止と凍結

規制指令

契約では、一時停止、再開、ブラックリストへの登録、ブラックリスト解除、凍結、凍結解除といったアクションをサポートする必要があります。これらはインシデント管理フレームワーク14の主要な構成要素です。

スローミスト技術の説明

規制文書では「一時停止」と「凍結」が別々の項目として記載されており、規制当局は発行者に柔軟かつ階層化されたインシデント対応能力を備えることを期待していることを示しています。一時停止は、契約の不正利用などの重大な危機に対応する手段であり、凍結は特定の法的またはコンプライアンス上の問題（単一アカウントに対する裁判所命令など）に対処するための的確な手段です。これら2つは機能的に異なるため、別々に実装する必要があります。

一時停止: 転送、鋳造、破棄など、契約のすべてのコア機能を即座に停止するグローバルな「緊急停止スイッチ」。
フリーズ: 特定のアドレスがトークンを送受信できないようにするアカウントレベルの制限ですが、ネットワーク内の他のアドレスの通常のアクティビティには影響しません。

実装ガイド

一時停止機能：PAUSER_ROLEを持つマルチシグウォレットによってのみ呼び出され、コントラクト機能をグローバルに停止するために使用されます。トリガー条件には、取締役会または上級管理職の承認を必要とする異常イベント（ネットワーク攻撃や準備資産の不一致など）の検出が含まれます。回復機能は、職務分離を実現するために、別のRESUME_ROLEによって処理されます。

凍結機能：FREEZER_ROLE を持つマルチシグウォレットによって呼び出され、特定のアドレスへの送金を制限します。トリガー条件には、AML アラートや裁判所命令などの疑わしいアクティビティが含まれます。これらのアクティビティは、実行前にオフチェーン検証が必要となります。凍結解除も同じロールによって処理されますが、不正使用を防ぐため、追加の監査検証と関連アナウンスメントが必要となります。

5. 住所審査とブラックリストの仕組み

規制指令

ライセンシーは、「制裁対象または違法行為に関連すると特定されたウォレットアドレスをブラックリストに登録する」15 などの措置を講じるべきです。これは継続的な監視のための中核的な管理策であり、発行者は違法または疑わしい行為に関連する取引を特定するために、ブロックチェーン分析ツールなどの技術的ソリューションを活用する必要があります16。

スローミスト技術の説明

これはオンチェーンでの強制メカニズムでなければなりません。オフチェーンで警告を発するだけでは不十分で、プロトコルレベルでトランザクションの発生を阻止する必要があります。ブラックリスト要件では、ライセンシーはリアルタイムのブロックチェーン分析ツール／サービス（MistTrack、Chainalysis、Ellipticなど）を導入する必要があります。コンプライアンスチームは、これらのツールによって得られた結果に基づき、複数の署名で署名されたトランザクションを安全に変換し、オンチェーンのブラックリストを更新します。

実装ガイド

関数の実装: ブラックリストの追加とブラックリストの削除を実装する関数で、BLACKLISTER_ROLE を保持するマルチ署名ウォレットからのみ呼び出すことができます。
転送制限: ブラックリストに登録されたアドレスはトークンの転送/受信が禁止されます。
動作プロセス：分析ツールがアラームを発し、社内コンプライアンスレビューが開始されます。コンプライアンスチームによるレビューと確認後、BLACKLISTER_ROLEマルチシグウォレットはブラックリスト追加トランザクションを開始します。

6. スマートコントラクトのアップグレード可能性

規制指令

ステーブルコインに関連するすべてのスマートコントラクトアーキテクチャは、「アップグレード可能性」17 を採用することができます。スマートコントラクトが「アップグレード」されるたびに、監査を受ける必要があります18。

スローミスト技術の説明

設計段階からのアップグレード可能性は、規制枠組みにおける技術的柔軟性とリスク管理の中核要件です。これにより、発行者は既存の契約状態を中断することなくロジックを更新し、バグ修正、機能拡張、規制変更に対応できるようになります。

しかし、これは高いリスクも伴います。アップグレードプロセスが悪用され、契約の挙動に予期せぬ変化が生じたり、新たな脆弱性が生じたりする可能性があります。したがって、アップグレードは高リスクな操作として扱う必要があり、単一の当事者による一方的な実行を防止するように設計する必要があり（マルチ署名プロトコルなど）、ロールベースアクセス制御システム（RBAC）と統合する必要があります。

規制当局が重視する監査要件は、アップグレードが単なるコードの置き換えではなく、新しいロジックコントラクトが展開前に第三者によって検証され、脆弱性やセキュリティ上の欠陥がないことを確認するための厳格な変更管理プロセスに組み込まれた制御されたイベントでもあることを意味します。

実装ガイド

プロキシモデル: EVM タイプのスマートコントラクトでは、成熟した ERC-1967 プロキシモデルを採用してアップグレード性を実現できます。
権限制御: アップグレード機能は、UPGRADER_ROLE を保持するマルチ署名ウォレットによってのみ呼び出される必要があります。
変更管理プロセス: 規制要件に従い、アップグレードを提案する前に、新しいロジックコントラクトの包括的で独立したサードパーティのセキュリティ監査を含む厳格な変更管理プロセスを完了する必要があります。

7. 分析とレポートのためのオンチェーンイベントログ

規制指令

ライセンシーは、「オンチェーンとオフチェーンの両方の情報を含むすべての事業活動をタイムリーかつ正確に記録し」、「適切な監査証跡を維持する」ための堅牢な「情報および会計システム」を確立する必要があります19。

スローミスト技術の説明

スマートコントラクトは、すべてのオンチェーンアクティビティにおける主要な真実の源泉です。オフチェーンシステムがログ記録、監視、レポート生成を行えるよう、スマートコントラクトは重要な状態変化ごとに詳細なイベントを発行する必要があります。これらのイベントは、ブロックチェーン上に不変かつ永続的なログを作成します。このログは、すべてのオフチェーン監視、会計、レポートシステムの主要なデータソースであり、監査のための強固な基盤となります。

実装ガイド

ERC-20 標準で必要な転送イベントと承認イベントに加えて、コントラクトはすべての管理アクションと状態変更に対してカスタムイベントを定義して発行する必要があります。

トークンの鋳造/燃焼イベント
契約一時停止/再開イベント
BlacklistAdded / BlacklistRemoved イベント
WhitelistAdded / WhitelistRemoved イベント
AddressFrozen / AddressUnfrozen イベント
RoleGranted / RoleRevoked イベント
契約アップグレード（アップグレード）イベント

パートIII 運用安全とライフサイクル管理

このセクションでは、スマートコントラクトを取り巻く重要な運用セキュリティ手順について詳しく説明します。これらの手順はコード自体と同様に重要であり、包括的なセキュリティとコンプライアンスを実現するために不可欠です。

1. 安全な鍵管理アーキテクチャ

規制指令

これは、規制の中でも最も詳細かつ厳格な分野の一つです。ライセンシーは、秘密鍵の生成、保管、使用、バックアップ、破棄を含む、秘密鍵のライフサイクル全体にわたって強力な管理を実施する必要があります20。「重要なシード鍵および／または秘密鍵」（アップグレード、ロール管理、大規模なコイン鋳造に使用される鍵など）には、より高度なセキュリティ基準が求められ、「エアギャップ環境」21でのオフライン生成やハードウェアセキュリティモジュール（HSM）22への保管などが含まれます。

スローミスト技術の説明

HKMAは、本質的には「従来型金融レベル」のセキュリティ体制を暗号資産ネイティブ運用に適用することを求めています。このレベルの鍵管理を実装するには膨大なコストと複雑さが伴い、ライセンスを取得した発行者にとって中核的な運用要素となるでしょう。このセキュリティモデルは、典型的なDeFiプロジェクトの標準的な慣行をはるかに超えています。規制文書は、鍵管理に関する詳細なチェックリストを提供し、HSM（ハードウェアセキュリティモジュール）、エアギャップ環境、キーセレモニー、マルチ署名について明示的に言及しています。これは、多層防御の鍵管理アーキテクチャの構築を事実上義務付けています。ハードウェアウォレットに保有されるアカウントは、マルチ署名ウォレットの署名者として機能し、マルチ署名ウォレット自体がスマートコントラクトの管理役割を担います。最高レベルのセキュリティを実現するには、これらのハードウェアウォレット自体を、物理的に安全なエアギャップ環境で管理する必要があります。このアーキテクチャ全体が、鍵の侵害に対抗するための多層防御システムを構築します。

実装ガイド

鍵生成: 物理的に安全で、外部から完全に隔離されたエアギャップ環境で、十分に文書化された「鍵セレモニー」23 を通じて完了する必要があります。
鍵の保管：すべての管理ロールは、マルチシグネチャウォレットによって管理される必要があります。これらのマルチシグネチャウォレットの署名者が使用する秘密鍵は、HSMまたはその他の安全なハードウェアウォレットに保管する必要があります。最も重要なロールについては、対応する鍵は、オンライン環境から物理的に隔離されたエアギャップシステムに保管する必要があります。
鍵の使用法：マルチ署名ポリシーを強制する必要があります。「重要な秘密鍵」を含むトランザクションの署名については、関係者が直接立ち会う必要がある場合があります24。
バックアップとリカバリ: キーシャードまたはニーモニックのバックアップは、香港 (または規制当局が承認した場所) 内の複数の安全で地理的に分散した場所に、改ざん防止パッケージに入れて保存する必要があります25。

2. 完全なデプロイメントプロセスとランタイム監視

規制指令

ライセンシーは、少なくとも年に1回、および導入、再導入、またはアップグレードのたびに、「資格のある第三者機関によるスマートコントラクト監査」を実施する必要があります。監査では、コントラクトが正しく実装され、期待どおりに機能し、脆弱性やセキュリティ上の欠陥が「高い信頼度で」存在しないことを確認する必要があります26。ライセンシーは、ニーモニックや秘密鍵の使用を監視するための対策（IPチェック、動作監視、重要なアクティビティアラート、デバイススクリーニング、オンチェーン監視、アクセス制御監視など）を実施する必要があります27。また、ライセンシーは、新たな脅威を検知するために、脅威インテリジェンスを監視するための適切な対策を講じる必要があります。脅威インテリジェンスは分析され、緩和策をタイムリーに実施できるようにする必要があります28。

スローミスト技術の説明

デプロイメントプロセスとランタイム監視は、技術リスク管理に関する規制枠組みの直接的な延長であり、脆弱性の発生源防止と運用リスクの継続的な監視を重視しています。デプロイメント前監査では、スマートコントラクトを重要なインフラストラクチャとして扱い、ユニットテスト、独立監査、コードフリーズなどの多層検証を通じて欠陥がないことを確認することが求められます。これは、ステーブルコインの発行、償還、または日常的な運用に影響を与えるコード欠陥や脆弱性悪用を回避するために、「高度に信頼できる」標準を規制当局が追求していることを反映しています。ランタイム監視は、リアルタイムの脅威検出に重点を置き、秘密鍵の使用状況監視（行動分析など）と脅威インテリジェンス分析を組み合わせて、閉ループの対応メカニズムを形成します。これは、インシデント管理フレームワークのニーズを満たすだけでなく、システムが新たなリスクに動的に対応できることを保証します。全体として、この部分の技術的実装では、オンチェーンツールとオフチェーンツールを統合して追跡可能な監査証跡を作成し、受動的な防御を能動的なコンプライアンスへと転換する必要があります。

実装ガイド

正式な展開の前に、「展開前チェックリスト」を作成し、厳密に従う必要があります。

包括的なテスト: ユニットテストカバレッジが 95% を超えていること、コアコードカバレッジが 100% であることを確認し、ユニットテストカバレッジレポートが出力されることを確認します。
独立監査: 信頼できる監査会社による独立したセキュリティ監査レポートを少なくとも 1 つ、できれば 2 つ作成します。
コード凍結: 監査が完了すると、コードはオンラインになるまで凍結され、コードの変更は行われません。
回帰テスト: 正式な展開の前に、ユニットテストと回帰テストを実行します。
コンプライアンスの承認: 契約ロジックが関連するすべての規制要件を満たしていることを確認するために、社内のコンプライアンスチームから正式な承認を取得します。
デプロイメントドリル: 詳細なデプロイメントスクリプトを準備し、メインネット環境とまったく同じテストネット上で完全なデプロイメントドリルを実施します。
承認されたデプロイメント: 最終的なデプロイメント操作は、承認されたウォレットによって実行されます。

導入後は、特権ロールの使用状況を監視し、新たな脅威に対する緩和策を実施するための適切な監視対策を実施する必要があります。

オンチェーンアクティビティモニタリング: 管理ロールの使用状況を監視し (たとえば、SlowMist セキュリティモニタリングシステム MistEye を使用して主要なロールのアクティビティモニタリングを追加する)、不正な状況を迅速に検出します。
脅威インテリジェンスの監視: 新たな脅威は速やかに検出され (たとえば、SlowMist セキュリティ監視システム MistEye の脅威インテリジェンスサブスクリプションを使用する)、脅威インテリジェンスを分析して、緩和策を適時に実施できるようにする必要があります。

3. 事業継続と撤退計画に関する技術サポートを提供する

規制指令

ライセンシーは、「ライセンスを受けたステーブルコイン事業を秩序ある形で終了させるための事業撤退計画」29 を策定しなければならない。この計画には、準備資産の換金手続きと保有者への収益分配手続きが含まれていなければならない。

スローミスト技術の説明

これは、スマートコントラクトが設計当初から独自の「引退」プロセスを考慮し、秩序あるシャットダウンを可能にする状態とメカニズムを備える必要があることを意味します。終了メカニズムの要件は、スマートコントラクトのライフサイクルがデプロイメントで終了するのではなく、プロトコルレベルで明確に定義された「寿命終了」プロトコルが必要であることを意味します。これは、「永続的」なコントラクトの構築に慣れている多くの開発者にとって斬新な概念であり、「終了を考慮した設計」という考え方をも促進してきました。秩序ある清算プロセスには、シャットダウン時点で誰が何を所有しているかについての、明確で最終的な、そして議論の余地のない記録が必要です。トランザクションがまだ進行中の混沌とした状態でシャットダウンが実行された場合、この目標を達成することは困難です。したがって、コントラクトの状態を凍結できる機能は、この規制要件を直接的に技術的に具体化したものです。こうして、オンチェーン状態は、清算人の手中にある最終的で監査可能な真実の源泉となります。

実装ガイド

事業終了計画を策定する: この計画では、秩序ある終了につながる可能性のあるさまざまなシナリオを網羅し、これらのシナリオの実際または潜在的な発生を監視するための対策を盛り込みます。

オンチェーン終了プロセス30:

準備資産の清算利益を最大限に確保し、市場全体の安定性への影響を最小限に抑えるために、スマートコントラクトを一時停止してすべてのトークン転送を停止する必要があります。
償還機能とホワイトリスト機能を利用して、ステーブルコイン保有者が償還申請を提出できるよう支援します。

パートIVの付録：規制要件の相互参照表

この表は、スマートコントラクトシステムの各技術的特徴を、それを義務付ける特定の規制テキストに直接マッピングしています。

関連資料

[1]香港金融管理局（2025年5月26日）規制対象ステーブルコイン取引に対するAML/CFT要件案に関する諮問文書。https://www.hkma.gov.hk/media/eng/regulatory-resources/consultations/20250526_Consultation_Paper_on_the_Proposed_AMLCFT_Req_for_Regulated_Stablecoin_Activities.pdf

[2]香港金融管理局（2025年5月）認可ステーブルコイン発行者の監督に関するガイドライン案。https://www.hkma.gov.hk/media/eng/regulatory-resources/consultations/20250526_Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf

参考文献

[1]ライセンス付きステーブルコイン発行者の監督に関するガイドライン草案に関する協議.pdf、21ページ、6.5.5

[2]ライセンス付きステーブルコイン発行者の監督に関するガイドライン草案に関する協議.pdf、21ページ、6.5.5

[3]ライセンス付きステーブルコイン発行者の監督に関するガイドライン草案に関する協議.pdf、20ページ、6.5.3

[4]ライセンス付きステーブルコイン発行者の監督に関するガイドライン草案に関する協議.pdf、20ページ、6.5.3

[5]ライセンス付きステーブルコイン発行者の監督に関するガイドライン草案に関する協議.pdf、21ページ、6.5.4

[6]AMLCFT規制対象ステーブルコイン活動に関する提案に関する協議書.pdf、13ページ、3.6.2

[7]ライセンス付きステーブルコイン発行者の監督に関するガイドライン草案に関する協議.pdf、20ページ、6.5.3

[8]ライセンス付きステーブルコイン発行者の監督に関するガイドライン草案に関する協議.pdf、21ページ、6.5.4

[9]ライセンス付きステーブルコイン発行者の監督に関するガイドライン草案に関する協議.pdf、10ページ、3.1.1

[10]ライセンス付きステーブルコイン発行者の監督に関するガイドライン草案に関する協議.pdf、12ページ、3.4.1

[11]AMLCFT規制対象ステーブルコイン活動に関する提案に関する協議書.pdf、9ページ、3.2.1

[12]ライセンス付きステーブルコイン発行者の監督に関するガイドライン草案に関する協議.pdf、11ページ、3.2.3

[13]ライセンス付きステーブルコイン発行者の監督に関するガイドライン草案に関する協議.pdf、11ページ、3.2.5

[14]ライセンス付きステーブルコイン発行者の監督に関するガイドライン草案に関する協議.pdf、38ページ、6.8.2

[15]AMLCFT規制ステーブルコイン活動に関する提案に関する協議書.pdf、13ページ、3.6.2

[16]AMLCFT規制ステーブルコイン活動に関する提案に関する協議書.pdf、11ページ、3.4.2

[17]ライセンス付きステーブルコイン発行者の監督に関するガイドライン草案に関する協議.pdf、20ページ、6.5.2

[18]ライセンス付きステーブルコイン発行者の監督に関するガイドライン草案に関する協議.pdf、21ページ、6.5.5

[19]ライセンス付きステーブルコイン発行者の監督に関するガイドライン草案に関する協議.pdf、51ページ、8.1.1

[20]ライセンス付きステーブルコイン発行者の監督に関するガイドライン草案に関する協議.pdf、22ページ、6.5.8

[21]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf、23ページ、6.5.8(ii)

[22]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf、23ページ、6.5.8(iv)

[23]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf、22ページ、6.5.8(ii)

[24]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf、24ページ、6.5.8(vii)

[25]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf、25ページ、6.5.8(x)

[26]ライセンス付きステーブルコイン発行者の監督に関するガイドライン草案に関する協議.pdf、21ページ、6.5.5

[27]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf、24ページ6.5.8(ix)

[28]Consultation_on_Draft_Guideline_on_Supervision_of_Licensed_Stablecoin_Issuers.pdf、34ページ 6.5.20(ii)

[29]ライセンス付きステーブルコイン発行者の監督に関するガイドライン草案に関する協議.pdf、42ページ、6.8.16

[30]ライセンス付きステーブルコイン発行者の監督に関するガイドライン草案に関する協議.pdf、42ページ、6.8.16