組み込み型ウォレット：その仕組みと収益の生み出し方

主なポイント

• 組み込み型ウォレットを使えば、ユーザーはアプリケーション内のフローから離れることなく、デジタル資産を保有、送信、受信、または利用することができます。

• 企業にとって、組み込み型ウォレットは、決済、ステーブルコインの送金、取引、報酬、およびプレミアムアカウント機能のためのアカウント基盤を提供します。

• 製品チームと開発チームは、鍵管理、トランザクションポリシー、チェーンのサポート、復旧、コンプライアンスワークフロー、およびSDKの適用範囲について、その取り扱い方法を決定します。

• その根幹にあるトレードオフは「管理権」です。カストディアル型モデルは、ユーザーの利便性を高め、資産の復旧を容易にする可能性があります。一方、ノンカストディアル型やハイブリッド型モデルでは、ユーザーや製品設計により多くの責任が課せられます。

組み込み型ウォレットとは、アプリケーションに直接組み込まれた暗号資産ウォレットのことで、ユーザーは別のウォレットアプリを開いたり、ブラウザ拡張機能を管理したり、登録時にシードフレーズを扱ったりすることなく、デジタル資産にアクセスできます。これにより、ウォレットの作成、署名、資産の移動が、製品体験の一部となります。

フィンテックプラットフォーム、消費者向けアプリ、エンタープライズソフトウェアプロバイダー、マーケットプレイス、決済事業者は、組み込み型ウォレットを活用して、既存のユーザーインターフェース内に決済やステーブルコインの送金、報酬や取引、資金管理、あるいは資産へのアクセス機能を追加しています。 場合によっては、これがデジタル資産バンキング商品（銀行のような口座体験を提供するものであり、認可や免許を受けた銀行機関ではない）の口座システムとなり、ユーザーは1つの口座から残高の保有、資金の移動、金融機能へのアクセスが可能になります。ユーザーには1つの口座として表示されます。企業は、新たな製品展開の機会、データ、顧客維持、および収益化の道筋を得ることができます。

インフラストラクチャの評価を行うチームは、組み込み型ウォレットのインフラストラクチャから着手することができます。

組み込み型ウォレットと接続型ウォレットの比較

フィンテック企業にとって、製品戦略上の重要な判断の一つは、「組み込み型ウォレット」と「接続型ウォレット」のどちらを採用するかという点です。組み込み型ウォレットは、アプリケーションのユーザー体験内で作成・管理されます。一方、接続型ウォレットは、ユーザーがアプリケーションの外で管理し、ブラウザ拡張機能、モバイルウォレット、WalletConnectフロー、または類似のインターフェースを通じて接続されます。

この決定は、変換、制御、責任、統合範囲、署名フロー、復旧、およびサポート負担に影響を及ぼします。組み込み型暗号資産ウォレットは、通常、スムーズなオンボーディング、反復的な取引、アカウント抽象化、または企業が管理するポリシー層を必要とする製品に適しています。一方、連携型ウォレットは、すでに自身の鍵を管理しており、ウォレットを直接制御することを期待するユーザーを対象とする製品に適しています。

組み込み型ウォレットの仕組み

組み込み型ウォレットは、アプリケーションがAPIまたはSDKを通じて、ユーザー、企業、アカウント、または内部エンティティ用のウォレットを作成した時点で開始されます。ウォレットは、サインアップ時、本人確認後、ユーザーが初めて資産を受け取った時、または特定の機能が有効化された時に生成される場合があります。 その後、アプリケーションはそのウォレットを、自社の台帳、データベース、権限モデル、およびサポートワークフロー内のユーザーのアカウントに紐付けます。

この技術システムは、主に4つの層で構成されています。

• ウォレットの作成時には、アドレスが生成または割り当てられます。

• 鍵管理により、誰がトランザクションに署名したり復元したりできるかが決定されます。

• トランザクションの署名により、選択された暗号モデルに従って資産の移動が承認されます。

• ポリシーの適用により、トランザクションがon-chainで処理される前に、各種の制御が行われます。

製品レベルでは、組み込み型ウォレットにより、アプリケーションはユーザーにブロックチェーンの仕組みそのものを直接触れることなく、暗号資産やステーブルコインの機能を提供できるようになります。技術的なレベルでは、ウォレットのインフラストラクチャ 認証、アカウントの状態、トランザクションキュー、Webhook、チェーンのインデックス作成、エラー処理、およびコンプライアンスチェックと連携する必要があります。

適切に設計された組み込み型暗号資産ウォレットは、アドレスを生成します。このウォレットでは、送金を開始できるユーザー、対応資産、制限や承認、エラー処理、および内部の口座記録との照合について定義されます。

組み込みウォレットの鍵管理とセキュリティ

鍵管理は、組み込み型ウォレットの設計における主要な判断事項です。これにより、誰が資産を管理するか、誰がアクセス権を回復できるか、誰が資産の移動を承認できるか、そして問題が発生した場合に責任が誰にあるかが決定されます。各チームは、製品、管轄区域、ユーザー層、およびリスク許容度に基づいて、適切なモデルを選択します。

カストディ型モデルでは、規制対象または契約に基づくカストディアンが秘密鍵を管理し、必要な確認を経て送金を実行します。これにより、ユーザーの復旧やサポートが簡素化されます。一方で、カストディ、コンプライアンス、および契約上の義務が生じる可能性もあります。 非カストディアルモデルでは、ユーザーまたは企業が鍵の管理権を保持します。これにより、直接的な保管リスクを軽減できます。その一方で、復旧、デバイスの紛失、ユーザーへの啓発といった課題は、製品開発上のより困難な課題となります。

カストディ型モデルと非カストディ型モデルのいずれも、MPCを含むさまざまな署名技術を利用することができます。MPC暗号資産ウォレット 署名を複数の鍵シェアに分散させることで、一か所で秘密鍵を再構築することなくトランザクションの承認が可能になります。実装方法によっては、MPCは承認ワークフロー、職務分離、および復旧プロセスをサポートすることができます。

セキュリティは、運用管理にも左右されます。チームには、取引限度額、役割に基づく承認、アドレスの許可リスト、不正監視、監査ログ、およびインシデント対応・復旧手順が必要です。重要な点は、ユーザーが端末を紛失したり、スタッフの役割が変更されたり、チェーンが一時停止したり、取引が失敗したり、攻撃者がサポートワークフローを標的にしたりした場合でも、運用モデルがセキュリティを維持できるかどうかです。

アプリに組み込みウォレットを追加する方法

組み込み型ウォレットの導入は、運用モデルから始まります。チームはまず、プロバイダーと鍵管理モデルを選定します。この決定によって、法的枠組み、復旧プロセス、署名ワークフロー、およびオンボーディング、送金承認、サポートへのエスカレーションの際にユーザーがどのような体験をするかが決まります。

次に、チームはウォレットポリシーを設定します。これらのポリシーには、取引限度額、承認権限、対応する送金先、資産・地域ごとのアクセス権限、および例外処理が含まれる必要があります。また、ポリシーは、プロダクト管理者、コンプライアンス審査担当者、財務チーム、サポート担当者などの社内ロールと紐付ける必要があります。

その組み込みウォレットSDK そして、アプリケーションとウォレットおよびアドレスの作成、トランザクションの開始・署名、ステータスの監視、通知を連携させます。開発チームは、サンドボックス環境および実際の製品フローにおいて、このSDKをテストする必要があります。これには、署名の失敗、リクエストの遅延や重複、未対応の資産、ネットワーク手数料の変更、および取り消された送金などが含まれます。

リリース前にチェーンのサポート設定を行う必要があります。各チームは、リリース時点でどの資産、ネットワーク、取引タイプを利用可能にするかを決定し、ユーザーがウォレットを移行することなく新しいチェーンを追加する方法を定義する必要があります。本番環境への移行前に、復旧テスト、コンプライアンス審査、送金ブロック、Webhookの障害、残高照合、およびサポート・インシデント対応のテストを実施してください。

その結果として、アプリケーションのフロー内で動作し、明示的な制御の対象となるウォレット機能が実現されるべきです。これにより、管理対象の製品機能と、管理対象外の暗号資産関連アドオンとを区別することができます。

組み込み型ウォレットの収益創出の仕組み

組み込み型ウォレットは、ウォレットを基盤としたアクションやアカウントの階層に対して課金を行うことで収益を生み出します。これらは、アプリケーション内では実現が困難、あるいは不可能だった収益モデルを実現するためのアカウント基盤を提供します。ウォレットは、暗号資産、ステーブルコイン、決済、報酬、送金、その他の残高ベースの機能のためのアカウント層となります。

デジタル資産バンキング体験の実現を目指すプラットフォーム（銀行免許を取得しているわけではない）において、ウォレットは多くの場合、ビジネスモデルの基盤となる口座システムとなっています。これにより、プラットフォームは、ユーザーを外部の暗号資産ウォレットに誘導することなく、残高管理、送金、決済、換金、およびレポート機能を提供することが可能になります。

最も直接的なビジネスモデルは、取引手数料収入です。プラットフォームは、ユーザーが資産を送金したり、資金を引き出したり、資産を交換したり、ステーブルコインを移動させたり、決済機能を利用したりする際に手数料を課すことができます。取引頻度の高いサービスの場合、1回あたりの少額な手数料でも継続的な収益源となります。価格設定は、透明性を保ち、一貫性があり、その操作がユーザーにもたらすメリットに見合ったものでなければなりません。

「変換スプレッド」も一般的なビジネスモデルのひとつです。ユーザーが法定通貨、ステーブルコイン、暗号資産の間で資金を移動する際、プラットフォームはその変換に対してスプレッドや手数料を徴収する場合があります。これは、利便性、流動性、統合された執行機能によって、明確に開示されたコストが正当化される他の金融アプリケーションのビジネスモデルと似ています。

ウォレットでは、プレミアムアカウントの階層もサポートされています。プラットフォームは、上限額の引き上げ、決済の迅速化、承認管理、レポート機能、および複数事業体の管理や専任サポートなどを提供することで、企業や上級ユーザーから料金を徴収することができます。企業向け環境では、プラットフォームはワークフローの管理、信頼性、レポート機能、および運用規模を収益源としていることがよくあります。

決済の受け入れは、新たな収益源となる可能性があります。加盟店、クリエイター、ベンダー、またはマーケットプレイスがステーブルコインによる決済を受け入れられるようにするプラットフォームは、取引手数料、月額プラットフォーム利用料、または付加価値サービス手数料を徴収することができます。許可され、対応している場合、残高ベースの商品には報酬や利回り分配の仕組みが含まれることもありますが、そうしたモデルについては、法的側面、商品内容、および開示事項について慎重な検討が必要です。

追加したいチームはアプリ内の暗号資産機能 収益化は、製品アーキテクチャの問題として捉えるべきです。ウォレットは、ユーザーが何ができるかを定義します。ビジネスモデルは、それらの行動のうちどれが持続可能な収益につながるかを定義します。金融機関がデジタル資産関連の製品や収益機会をどのように構築できるかについて、より広い視点から知りたい場合は、BitGoの「銀行向け暗号資産インフラ」レポート.

組み込み型ウォレット・プラットフォームにおけるコンプライアンス上の考慮事項

組み込み型ウォレットを追加すると、アプリケーションのコンプライアンス上の位置づけが変わる可能性があります。遵守すべき義務は、管轄区域、ユーザーの所在地、資産の種類、カストディモデル、および送金、交換、Staking、報酬、加盟店での利用受付などの決済機能によって異なります。

製品がユーザーの視点から見るとデジタル資産銀行に類似している場合、コンプライアンス審査の重要性は高まります。たとえプラットフォーム側が自らをそのように位置付けていなくても、規制当局やパートナーは、保管、送金、換金、決済、口座へのアクセスなど、実際に提供されている機能に注目する可能性があります。

一般的な監査対象分野には、資金送金、本人確認およびマネーロンダリング対策、制裁措置などが含まれます。トラベル・ルールに関するワークフロー、消費者への情報開示、ステーブルコイン特有の義務、および記録・苦情の処理などです。非カストディアル型のインターフェースは、カストディアル型の口座商品とは異なる義務を負う場合があります。分析の内容は、商品の詳細によって決まります。ユーザーのオンボーディング、送金権限、変換、または支払いのルーティングを管理するプラットフォームであっても、それらの活動に関するコンプライアンス・ワークフローが必要となる場合があります。

リリース前に、ウォレットのフローにコンプライアンス設計を組み込むことが重要です。本人確認、リスクスコアリング、ブロック済みアドレスの管理、承認キュー、監査ログ／レポート、およびサポートへのエスカレーションは、ウォレットシステムに組み込まれるべきです。

BitGoの組み込み型ウォレットインフラストラクチャ

BitGoは、プラットフォームがアプリケーションにウォレットベースのデジタル資産機能を追加するために利用できる、ウォレットインフラおよび暗号資産サービスを提供しています。デジタル資産バンキング製品を開発している企業にとっては、BitGoのWallet-as-a-Service 本サービスは、エンドユーザー向けのウォレットや受信アドレスの作成・管理をプログラム的に行うことを目的としており、ウォレットやアドレスの作成、トランザクションの署名、監視、ポリシー制御、およびユーザー管理のためのAPIおよびSDKをサポートしています。

～のために保管を重視した設計また、BitGoは、規制に準拠した適格なカストディ、オフラインのコールドストレージ、セキュリティチェック、およびポリシー管理を基盤とした、機関投資家向けのウォレットインフラも提供しています。自己管理型の設計については、BitGoは、顧客が鍵の管理権限を保持し、ポリシーに基づいた共同署名やウォレットの運用にBitGoのインフラを利用するモデルをサポートしています。 BitGoは、投資、法律、税務、会計に関する助言は提供しておらず、本記事の内容はいかなる種類の提案や勧誘でもありません。各プラットフォームは、製品やライセンスに関する決定を行う前に、自社の法務、コンプライアンス、財務アドバイザーに相談する必要があります。

よくある質問

カストディ型とノンカストディ型の組み込みウォレットには、どのようなトレードオフがあるのでしょうか？

カストディ型モデルは、復旧やサポートを簡素化できます。また、直接的な保管およびコンプライアンス上の義務が生じる場合があります。非カストディ型モデルでは、鍵の管理権限の多くがユーザーや企業側に移行します。そのため、より強固な復旧体制、教育、およびサポート体制の設計が必要となります。鍵の管理方法の選択肢を評価しているチームは、以下を比較することができます。自己管理型ウォレットの選択肢.

ユーザーが端末や認証情報を紛失した場合、鍵管理はどのように機能するのでしょうか。また、復旧の責任は誰が負うのでしょうか。

復旧は、選択したモデルに従って行われます。カストディ型ウォレットは通常、プロバイダーが管理する検証および復旧ワークフローに依存しています。ノンカストディ型およびハイブリッド型ウォレットでは、バックアップキー、ソーシャルリカバリー、パスキー、または外部署名者を利用する場合があります。責任の所在は、契約書、利用規約、およびサポート手順において明確に定義されるべきです。

組み込み型ウォレットの統合において、どの部分をBitGoのSDKに委ねることができるでしょうか？

通常、SDKを活用することで、ウォレットの作成、アドレスの生成、署名、トランザクションの監視、ネットワーク接続に関する作業を軽減できます。ただし、認証、UX／アカウントのマッピング、コンプライアンスロジック、照合／テスト、分析／サポートツールに関しては、依然として一定の労力が必要です。その範囲は、カストディモデル、チェーン、資産、およびローンチ要件によって異なります。

組み込みウォレットは、ユーザーがネイティブトークンを持たなくても取引を行えるように、ガス料金をどのように処理しているのでしょうか？

プラットフォームは、スポンサー付きトランザクション、手数料の抽象化、ステーブルコイン建ての手数料、内部課金、または事前入金済みの運用用ウォレットを通じて、ガス代を処理することができます。チェーン、資産、ユーザーフロー、およびカストディモデルに基づいて、適切なアプローチを選択してください。その目的は、ユーザーが取引を行う前に、別途ネイティブトークンの残高を用意する必要がないようにすることです。

アプリ内でユーザーが資産を保有したり移動させたりできるようにした時点で、組み込み型ウォレットを利用するフィンテック企業には、どのようなコンプライアンス上の義務が生じるのでしょうか？

義務には、KYC／AML、制裁対象者スクリーニング、資金移動分析、トラベル・ルールのワークフロー、ステーブルコインに関する開示、取引モニタリング、および記録保持などが含まれる場合があります。分析の内容は、管轄区域、カストディモデル、資産の種類、ユーザー層、およびアプリが送金、換金、報酬、または支払いをサポートしているかどうかによって異なります。

組み込み型ウォレットを採用しているフィンテック企業は、ユーザーにウォレットの移行を強いることなく、どのようにチェーンの対応やアップグレードを行っているのでしょうか？

マルチチェーンウォレットの運用、設定可能な資産対応、および明確な資産対応プロセスをサポートするインフラストラクチャを選択してください。アプリケーションでは、ユーザーアカウントのIDとチェーン固有のアドレスを分離し、顧客アカウントモデルを再構築することなく新しいネットワークを追加できるようにする必要があります。リリース前に、移行テストおよび未対応資産のシナリオについてテストを行ってください。