
7分で読めます
暗号資産ウォレットインフラ:実態と選び方
これから構築または購入しようとしているのは、ユーザーの資金を動かすシステムです。1つのレイヤーでも設計を誤れば、深夜2時に停止した出金、監査で表面化するコンプライアンスのギャップ、あるいは承認フローが防ぐはずだった盗難に直面することになります。
ウォレットアーキテクチャの設計ミスのコストは、毎回同じ形で現れます。資金の喪失、規制当局による処分、あるいはもっと有益な場所に使われるはずのエンジニアリング時間の浪費です。検討すべきは、この問題を真剣に受け止めるかどうかではありません。自社チームが各レイヤーを保有すべきか、それとも鍵を保持したままWaaS APIで運用すべきかです。
この記事では、暗号資産ウォレットインフラが実際に何をカバーするのか、各レイヤーがどのように機能するのか、ベンダーを評価する際に何を見るべきかを整理します。以下の4レイヤーモデルがその枠組みであり、[[internal: /en/waas]]はその実運用方法の1つです。
暗号資産ウォレットインフラの実態
暗号資産ウォレットインフラとは、入金アドレスを生成し、入金される資金をルーティングし、出金取引を承認し、コンプライアンスのためにユーザーと取引相手をスクリーニングする一連のシステムです。単一の製品ではなく、それぞれ独自の障害モードと保守領域を持つ、4つの独立した運用レイヤーです。
自社構築か購入かをめぐる混乱の多くは、これらのレイヤーを1つのものとして扱うことに起因します。実際は別物です。
4レイヤーモデル
取引所やPSP(決済サービスプロバイダー)における取引のライフサイクルは、4つの明確な段階を経ます。それらを個別に理解することが、筋の通った自社構築 vs 購入の分析を行う前提条件です。
1. 入金管理:アドレスの生成、資金の回収、入金アドレスに対するKYTスクリーニング
2. 出金の送出:設定可能な承認フローとガス管理を備えた自動支払い
3. 承認署名:承認を改ざん不可能かつ監査可能にする暗号学的な承認処理
4. コンプライアンススクリーニング:KYC書類検証、生体検知、不正チェック
各レイヤーは明確に定義され、社内で構築できますが、同時に常時の保守負担でもあります。問題は、そのうちどれを自社チームが保有すべきかです。
レイヤー1:入金管理
具体的な内容
すべての入金フローはアドレス生成から始まります。大規模に運用する場合、手動での対応は現実的ではありません。自動アドレス生成によりこのボトルネックは解消されますが、同時に検証の要件も生じます。システムは、ユーザーが資金を送る前に、生成されたすべてのアドレスが正当なものであることを確認できる必要があります。デジタル署名の検証がこれをカバーし、正当なアドレスを攻撃者の管理するアドレスに差し替えるフィッシングやリダイレクト攻撃から保護します。
次の障害ポイントはアドレス形式の検証です。不正な形式のアドレスへの送金は、取り消せないエラーになります。[[internal: /en/coinget]]は、資金が移動する前に形式を検証するアドレス形式検証APIをパブリックエンドポイントとして提供しています。
入金スクリーニングの面では、自動化されたKYT(Know Your Transaction)によるアドレスリスクスクリーニングが、資金の到着前に送金元アドレスに対して実行されます。これにより、リスクのある入金に対する手動のトリアージ作業が不要になります。
資金が到着すると、自動回収によって複数の入金アドレスからメインウォレットへとスイープされます。統合のロジックは、時間、残高しきい値、またはカスタムルールで設定できます。EVMチェーンについては、取引の加速を自動的に処理する自動加速スイーピングをオプションとして利用でき、監査目的の取引単位履歴も残ります。
コールドストレージが必要なチームでは、回収した資金はそのままコールドストレージへルーティングされます。リアルタイム入金通知により、運用チームは手動のポーリングなしにすべての入金取引を把握できます。
カストディについて:[[internal: /en/coinget]]は鍵シャード構成で利用でき、リストアにも対応しています。シャードはお客様のチームが保持します。CoinsDoがお客様の秘密鍵を保持することは決してありません。
社内構築で破綻する理由
大規模なアドレス生成は、問題が起こるまでは単純なものです。16以上のネットワークに対応する形式サポート、障害時に適切に処理するスイープロジック、自社のチェーンをカバーするプロバイダーとのKYT連携。それぞれは独立した問題ですが、合わさると1チーム分の保守工作量になります。
ベンダー選定で確認すべきポイント
- アドレス形式の検証が、裏側でのチェックではなくAPIエンドポイントとして利用できること
- 入金アドレスへのKYTスクリーニングが、資金の統合後ではなく統合前に実行されること
- (時間、残高、カスタムを)自分で設定できるスイープルールであり、固定スケジュールではないこと
- 自社で署名インフラを運用せずにシャード型カストディを実現したい場合の鍵シャードオプションがあること
レイヤー2:出金と送出
具体的な内容
自動出金は24時間365日稼働している必要があります。それは最低条件です。差別化のポイントは、その周りを囲む承認レイヤーにあります。
Coinsendは、設定可能な承認フローによる出金の送出を処理します。高額取引に向けた承認者ティア、しきい値、エスカレーションロジックです。承認の有効期限管理により、設定可能な有効期限を送出記録ごとに確認できるため、保留中の出金がオフラインの承認者をいつまでも待ち続けることがなくなります。
サブアカウントのロール管理では、サブアカウントごとにきめ細かなロールを割り当てられ、メインアカウントが各サブアカウントのセッションの有効性を制御します。マルチアカウント構造の取引所や企業クライアントを管理するPSPにとってこれは重要です。アカウントのアクセス権が変わるたびにプラットフォーム全体を再設定する必要のない、ロールの境界線が必要だからです。
ガス代管理により、手数料しきい値に基づいて送出を自動化できます。ガス代の急騰を避けるため手動で出金のタイミングを調整しているチームにとっては、この運用負荷を解消します。
API連携は非対称署名による認証を使用します。
次のスクリーンショットは、設定した承認ロジックに応じて、同じAPIが手動レビューから完全自動送出までの全範囲をどのように処理するかを示しています。
キャプション:Coinsendによる手動フロー
社内構築で破綻する理由
カスタム承認フローは、実際に構築するまでは単純に聞こえます。しかし、承認者が不在の場合、時間外にしきい値に達した場合、セッションを即時に失効させる必要があるサブアカウントの場合など、エッジケースを乗り越える必要のある承認者ティアのロジック、有効期限処理、エスカレーションパスを構築すると話が変わります。ロジックが正しくなければ、各エッジケースはインシデントの温床になります。
ベンダー選定で確認すべきポイント
- 単一の承認者ゲートではなく、ティアとしきい値に対応した承認フローであること
- 記録単位で可視化できる、設定可能な承認の有効期限であること
- メインアカウントレベルでセッションの有効性を制御できるサブアカウントロール管理であること
- 手動のタイミング調整ではなく、実際のしきい値に連動したガス代の自動化であること
レイヤー3:承認署名
具体的な内容
これは[[internal: /en/coinsend]]の機能であり、独立したモジュールではありません。CoinSignが、すべての承認を改ざん不可能かつ監査可能にする暗号学的な承認処理を担います。
署名方式はRSA/HMAC-SHA256です。CoinSignはCoinSendの機能であり独立したモジュールではなく、その承認アーキテクチャはMPCではありません。すべての承認は、単一の決定論的な署名済み記録を生成し、内部管理による監査とインシデント後のレビューでの検証が可能です。これは、障害の範囲が鍵シャード保持者間の調整に及ぶ閾値署名モデルとは異なります。承認はデジタル署名されるため、真正であり、承認者からシステムまでの間で改変されていないことが保証されます。モバイル、PC、ブラウザ拡張機能にまたがるクロスプラットフォームレビューに対応しているため、承認チームが1つのデバイスに縛られることもありません。
承認の記録(トレイル)は改ざん不可能です。これは外部のコンプライアンスと同様に内部管理にとっても重要です。承認と実行の間に操作が行われていれば、署名チェックがそれを検出します。
重要な理由
ウォレットインフラの議論の多くは鍵のカストディに集中しています。承認レイヤーはそれと同等に重要でありながら、あまり語られません。内部関係者によってバイパスや操作が可能な承認フローは、鍵がどれほど厳重に保護されていても、管理の失敗です。
ベンダー選定で確認すべきポイント
- (RSA/HMAC-SHA256または同等の)署名方式が文書化されており、ブラックボックスではないこと
- マルチプラットフォームのレビュー対応により、承認のボトルネックが特定のハードウェアを要求しないこと
- 単なるログエントリーではなく、監査可能で改ざん不可能な承認記録であること
レイヤー4:コンプライアンススクリーニング
Coinfaceは、インフラレイヤーでKYCを処理します。99.9%の精度を持つ書類OCRが、手入力なしに身分証明書やパスポートの情報を抽出します。生体検知がディープフェイクやなりすましを防ぎ、顔認識が書類を提示した人物と身分証明書の一致を確認します。
ブラックリストと不正スクリーニングは、独自およびカスタムデータベースに対してチェックを行います。重複エントリーの検出はマルチアカウント悪用を排除します。これは、大量のユーザーをオンボーディングする取引所にとって重大な不正の手口です。KYCフロー自体もカスタマイズ可能で、オンボーディングパイプラインを設定するのはベンダーではなくお客様自身です。
導入前後のシナリオ
インフラレベルのコンプライアンススクリーニングがない場合:運用責任者がチケットキューの中のフラグ付き書類を手動でレビューしています。生体検知は存在しないか、開発チームが保守する別ベンダーとの連携で処理されています。ユーザーは名前をわずかに変えた複数のアカウントを申請します。各チェックが互いに連携していないため、そのパターンはコンプライアンス監査で表面化するまで発覚しません。
入金レイヤーにCoinfaceを統合した場合:書類抽出、生体検知、顔照合、重複検出が同じオンボーディングフローの一部として実行されます。運用責任者がレビューするのは、すべての申請ではなく、本当にフラグが付いた例外のキューです。
ベンダー選定で確認すべきポイント
- 静的画像のなりすましだけでなく、ディープフェイクにも対応する生体検知であること
- セッション単位ではなく、ユーザーベース全体で機能する重複検出であること
- 固定のオンボーディングテンプレートではなく、自分で設定できるカスタマイズ可能なフローであること
選び方:意思決定のフレームワーク
暗号資産ウォレットインフラにおける自社構築か購入かという問題は、二択ではありません。ほとんどのチームは、一部のレイヤーを自社で構築し、他はAPIで運用するべきです。適切な切り分けは2つの要素によって決まります。
最初の問いは、どのレイヤーが自社の差別化に関わるかです。製品の価値が取引機能にあり、入金スイープのロジックやKYCオーケストレーションにあるのでないなら、それらのレイヤーにエンジニアリングの時間を割くべきではありません。社内構築がユーザーにとってより良い製品を生むのか、それとも保守業務を増やすだけなのかが問われます。
2つ目の要素は鍵のカストディです。CoinsDoがお客様の秘密鍵を保持することは決してありません。保持するのはお客様です。クライアントサイドウォレットは、AndroidまたはPC/クラウドに3分以内でデプロイできます。ベンダーとの関係が終わっても、資産は持ち運び可能です。完全な鍵シャードアーキテクチャが必要な場合は、Coingetがリストア機能付きで対応します。この要素こそ、本来であれば社内構築を余儀なくされるチームにとってWaaSを実現可能にするものです。カストディを手放さなくてよいのです。
コスト面およびチームへの影響についての詳しい比較は、こちらの記事で、自社構築 vs 購入の分析を完全に解説しています。
ベンダーを評価中の方は、こちらの記事で、2026年に利用可能なプロバイダーをベンチマークしています。
よくある質問
暗号資産ウォレットインフラとは何ですか?
暗号資産ウォレットインフラとは、入金アドレスの生成、入金資金のルーティング、出金取引の承認、コンプライアンススクリーニングを処理する一連のシステムです。4つの運用レイヤーで構成され、それぞれ独立して構築・保守できます。ほとんどのチームは、どのレイヤーが製品の差別化に関わるかに応じて、一部のレイヤーはWaaS APIで運用し、他は社内で保有しています。
鍵のカストディを維持するには、ウォレットインフラを自社構築する必要がありますか?
いいえ。秘密鍵のカストディを維持することは、鍵管理の意思決定であり、自社構築か購入かの意思決定ではありません。鍵を保持しないWaaSプロバイダーを利用すれば、チームが鍵を完全に管理したまま、API経由でインフラを運用できます。CoinsDoがお客様の秘密鍵を保持することは決してありません。ベンダーとの関係が終わっても、鍵とアドレスはお客様の手元に残ります。
承認署名と鍵のカストディの違いは何ですか?
鍵のカストディは、ウォレットを管理する秘密鍵を誰が保持するかの問題です。承認署名は、個々の取引が実行される前に、誰が承認し暗号学的に保証するかの問題です。この2つは異なるレイヤーで機能します。取引所は、自社の秘密鍵を保持しながら、ベンダーの承認署名インフラを使用して、すべての出金に監査可能で改ざん不可能な承認記録を持たせることができます。
結論
暗号資産ウォレットインフラは1つではなく4つのレイヤーです。入金管理、出金送出、承認署名、コンプライアンススクリーニングには、それぞれ明確なスコープ、明確な障害モード、明確な保守コストがあります。
問うべきは、各レイヤーを真剣に受け止めるかどうかではありません。自社チームが保守を担うのか、鍵のカストディを維持しながらAPIで運用するのかです。
鍵の管理権を手放すことを求めるベンダーの場合、機能リストの他の項目はすべて二の次です。
鍵を保持していれば、残りはエンジニアリングとコストの問題です。



