秘密鍵管理にMPCが必要な理由とは？toCサービスのウォレット設計を解説

Web3技術を活用したtoCサービスを企画する際、最初にぶつかる壁が「ウォレットの秘密鍵を誰がどう管理するか」という問題です。事業者が預かればセキュリティリスクが集中し、ユーザーに任せればUXが崩壊する。この二律背反を解決する技術として注目されているのがMPC（Multi-Party Computation：マルチパーティ計算）です。

本記事では、toCサービスにおける秘密鍵管理の課題から、ウォレット設計の選択肢、MPCの仕組みと導入メリット、具体的な設計パターンまでを、事業責任者が判断材料として活用できる形で解説します。

toCサービスにおける秘密鍵管理の課題

toCサービスにおいてウォレットの秘密鍵管理は、セキュリティの問題である以前に、ユーザー体験と事業継続性を左右する設計上の最重要課題です。鍵の管理方式を誤ると、ユーザー離脱・サポートコスト増大・漏洩時の致命的損害に直結します。

ウォレット設計がユーザー離脱の原因になる理由

ブロックチェーンを活用したtoCサービスでは、ユーザーが最初に「ウォレットの作成」と「シードフレーズの保存」を求められます。しかし、ブロックチェーンに馴染みのない一般ユーザーにとって、12〜24個の英単語を安全に記録・保管するという行為は、サービス利用以前の段階でハードルになります。

結果として、「よく分からないからやめた」という形で登録途中の離脱が発生します。toCサービスにおけるウォレットは、機能の一つではなく「UXの入口」です。ここでつまずけば、サービス全体の価値が届く前にユーザーを失うことになります。

なお、XTELAではtoCサービスのウォレット設計に関するご相談を無料で承っております。「まだ構想段階」という方も、どうぞお気軽にご相談ください。

「秘密鍵を誰が管理するか」がUXと事業リスクを決める

ウォレット設計で最も重要な判断は、秘密鍵の管理主体を誰にするかです。事業者が管理すればUXは改善しますが、漏洩時の損害と規制上の責任を事業者が負います。ユーザーに管理を委ねればセキュリティ責任は分散しますが、紛失時にはサポートが成立しません。

この選択は、UX・セキュリティ・法規制・カスタマーサポート体制のすべてに影響します。秘密鍵管理の方式選定は、単なる技術的な判断ではなく、事業設計そのものです。

ウォレット設計の3つの選択肢 ― Custody型・Self-custody型・MPC型

toCサービスのウォレット設計には、事業者が鍵を管理するCustody型、ユーザーに委ねるSelf-custody型、そして鍵を誰も単独で持たないMPC型の3つの選択肢があります。それぞれにトレードオフがあり、サービスの特性に応じて最適解は異なります。

Custody型（事業者管理）のメリットとリスク

Custody型は、事業者がユーザーの秘密鍵を預かって管理する方式です。UXの観点では最も優れており、ユーザーは鍵の存在を意識する必要がありません。

しかし、事業者側に秘密鍵が集中するため、漏洩が発生した場合の損害は致命的です。実際に、秘密鍵をサービス側で預かる構成は、万が一の漏洩時に全ユーザーの資産が危険にさらされるため、「許容できない」と判断する事業者は少なくありません。加えて、カストディ業務に該当する場合は暗号資産交換業者としての登録義務など、規制面での負担も発生します。

Self-custody型（ユーザー管理）の限界

Self-custody型は、ユーザー自身が秘密鍵やシードフレーズを管理する方式です。Web3の思想としては「自分の資産は自分で守る」という原則に沿っていますが、toCサービスでは深刻な問題が発生します。

エンドユーザーの多くはブロックチェーンのリテラシーを持っていません。シードフレーズを安全に保管すること自体が難しく、紛失すれば資産に二度とアクセスできなくなります。さらに、「ウォレットの使い方がわからない」「トークンが消えた」といった問い合わせがカスタマーサポートに殺到し、運用が破綻するケースも実際に報告されています。

MPC型が「第三の選択肢」として注目される理由

MPC（Multi-Party Computation）型は、秘密鍵を複数のパーツに分割し、誰も単独で完全な鍵を持たない構成を実現する方式です。ユーザー体験はCustody型に近いWeb2ライクな操作感を提供しながら、事業者側も秘密鍵を保管しないNon-custodial設計を維持できます。

Custody型の「預かりリスク」とSelf-custody型の「UX崩壊」という二律背反を解消する選択肢として、toCサービスにおいて急速に採用が広がっています。

MPC（マルチパーティ計算）とは？仕組みとtoCウォレットでの活用

MPC（Multi-Party Computation：マルチパーティ計算）は、秘密鍵を複数のパーツに分割して生成・管理し、完全な鍵がどこにも存在しない状態を作る技術です。盗まれる「鍵そのもの」が存在しないため、従来の秘密鍵管理における最大のリスクを構造的に排除できます。

MPCの基本的な仕組み

MPCの仕組みを簡潔に整理すると、以下の3つのステップで成り立っています。

1. 分割生成：秘密鍵を生成する段階で、鍵を複数の「キーシェア」に分割します。完全な秘密鍵は、生成の時点からどこにも存在しません。
2. 分散保管：各キーシェアは、ユーザーの端末・サービスのサーバー・第三者のリカバリノードなど、異なる場所に保管されます。
3. 協調署名：トランザクションの署名が必要なときだけ、各キーシェアの保持者が協調して計算を行います。鍵を一か所に集めることなく、署名を生成できます。

この仕組みにより、ハッカーが1つのキーシェアを盗み出しても、それだけではウォレットにアクセスできません。単一障害点が存在しないことが、MPCのセキュリティ上の最大の強みです。

toCウォレットにおけるMPCの典型的な構成

toCサービス向けのMPCウォレットでは、一般的に以下の3者でキーシェアを分散させます。

• ユーザー端末（スマホ / ブラウザ）：ユーザーが直接保持するキーシェアです。
• サービス側MPCノード：サービス事業者が管理するサーバー上のキーシェアです。
• Recoveryノード：端末紛失や機種変更に備えた、第三者またはクラウド上のバックアップ用キーシェアです。

この構成では、署名に必要なキーシェアの数（しきい値）を2-of-3に設定するのが一般的です。ユーザー端末とサービスノードの2つが揃えば署名が完了し、端末を紛失した場合はRecoveryノードとサービスノードで復旧できます。

MPCとマルチシグ・Shamir方式の違い

秘密鍵の分散管理にはMPC以外にもマルチシグやShamirの秘密分散（SSS）がありますが、それぞれ仕組みが異なります。

マルチシグは「複数の独立した秘密鍵」で署名を行う方式です。ブロックチェーンのプロトコルに依存するため、対応チェーンが限られ、署名者変更時にアドレスの再生成が必要になるケースがあります。

Shamir方式は秘密鍵を分割して保管し、復元時に一定数のシェアを集めて鍵を再構築します。ただし、復元の瞬間に完全な秘密鍵がメモリ上に一時的に存在するため、その時点が攻撃の対象になるリスクがあります。

MPCは、鍵を再構築せずに分散したまま署名を完了できる点で、マルチシグやShamir方式とは本質的に異なります。チェーンに依存しない柔軟性と、鍵の再構築リスクがないセキュリティを両立できるのがMPCの優位性です。

MPCウォレットがtoCサービスにもたらすメリット

MPCウォレットの最大のメリットは、エンドユーザーにブロックチェーンの複雑さを意識させずにサービスを提供でき、同時にサービス事業者も秘密鍵の保管リスクを負わずに済む点です。UXの改善と事業リスクの低減を同時に実現します。

UX面 ― Web2と同等のユーザー体験を実現

MPCウォレットを導入したtoCサービスでは、ユーザーのオンボーディングが大きく変わります。

• ログイン：メールアドレスやSNSアカウントで認証するだけで、ウォレットが裏側で自動生成されます。シードフレーズの保存は不要です。
• 日常操作：トランザクションの署名は1タップで完了します。設計次第でガス代もユーザーに意識させない構成が可能です。
• 紛失・機種変更：Recoveryノードを活用した復旧フローがあるため、端末を失くしてもサポート対応で復旧できます。

実際に、MPCウォレットプラットフォーム「Web3Auth」を活用した開発事例では、メールアドレスのみでログイン可能なWeb2ライクなUXを実現しています。ユーザーはウォレットの存在を意識することなくサービスを利用でき、事業者側も秘密鍵を保管するリスクを持たずに済む構成です。

事業面 ― サポートコスト削減と規制リスクのコントロール

• 離脱率の改善：ウォレット作成のハードルがなくなることで、初回登録時の離脱率が低下し、アクティブ率の向上が期待できます。
• CS負荷の軽減：「シードフレーズを失くした」「ウォレットが使えない」といった問い合わせが激減します。端末紛失時も復旧フローで対応可能なため、サポートとして成立する運用が構築できます。
• 規制リスクのコントロール：MPC型はNon-custodial設計が可能なため、事業者単独では資産を操作できない構成を維持できます。「預かっていないが、復旧の責任は持てる」という、toCサービスに適したポジションを取ることが可能です。

toC向けMPCウォレットの設計パターンと注意点

MPCウォレットの設計は、鍵の分割方式とリカバリ構成によって複数のパターンがあり、サービスの対象ユーザーや取り扱う資産の規模に応じて選定する必要があります。設計を誤ると実質Custody状態やUX劣化を招くため、注意点も押さえておくことが重要です。

代表的なMPC設計パターン（2-of-2 / 2-of-3 / デバイス分散型）

サービスの性質に応じて適切なパターンを選定してください。一般的なtoCサービスであれば2-of-3が汎用性とリカバリ性のバランスに優れており、最初の選択肢として検討しやすい構成です。

なお、XTELAではCustody型・MPC型など、自社サービスに合ったウォレット設計のご相談を無料で承っております。どうぞお気軽にお声がけください。

設計時に避けるべき落とし穴

実質Custodyになってしまう構成

MPCを導入しても、サービス事業者が単独で署名できる構成になっていれば、実態としてはCustody型と変わりません。例えば、サービス側が復旧用キーシェアを含む2つ以上のキーシェアを保持し、ユーザーの承認なく署名可能な状態は、Non-custodialとは言えません。規制上のリスクと、ユーザーからの信頼を損なう要因になります。

UXを壊すMPC実装

MPC導入の目的はUXの向上ですが、実装によっては逆効果になるケースがあります。署名処理に数秒以上かかる、署名失敗時にユーザーへの説明が不十分、カスタマーサポートがMPCの仕組みを理解していないといった状況は、ユーザー離脱の原因になります。技術導入と同時に、運用体制・CS研修も設計に含めることが重要です。

MPCウォレットをtoCサービスに導入する際の具体的な進め方

MPCウォレットの導入を成功させるには、技術選定の前にサービス要件を明確にし、自社開発と外部プラットフォーム活用のどちらが適しているかを判断することが重要です。ここでは、導入前に整理すべき要件と、開発工数・コストの目安を解説します。

MPCウォレット導入前に整理すべき要件と検討の進め方

導入を検討する段階で、以下の要件を事前に整理しておくと、開発パートナーとの打ち合わせがスムーズに進みます。

• 対象ユーザーの規模とリテラシー：一般消費者向けか、一定のリテラシーを持つユーザー向けかによって、求められるUXの水準とリカバリ設計が変わります。
• 取り扱う資産の種類と価値：NFT会員証のようなライトな用途か、高額資産を扱うかで、セキュリティ要件と設計パターンの選択が異なります。
• カストディ規制への対応方針：Non-custodial設計を維持する必要があるか、どの法域の規制を想定するかを明確にします。
• 既存システムとの連携：認証基盤（OAuth、メール認証等）や決済システムとの統合要件を事前に整理します。

開発工数・コストの目安と外部プラットフォーム活用の選択肢

MPCウォレットの構築には、大きく分けて「外部プラットフォーム活用」と「カスタム開発」の2つのアプローチがあります。

Web3AuthやFireblocksなどの外部プラットフォームを活用する場合、SDKの組み込みにより比較的短期間でMPCウォレット機能をサービスに統合できます。開発工数を抑えられる一方、プラットフォームの仕様に依存する部分が出るため、カスタマイズの自由度とのトレードオフがあります。

自社固有のガバナンスルールや独自の署名ポリシーが必要な場合は、カスタム開発が適しています。ただし、MPCプロトコルの実装にはセキュリティの専門知識が求められ、開発工数・コストともに大きくなるため、実績のある開発パートナーとの連携が不可欠です。

秘密鍵管理・MPCウォレットに関するよくある質問

秘密鍵管理やMPCウォレットの導入を検討する際によく寄せられる質問とその回答をまとめました。プロジェクトの要件に応じた判断の参考としてご活用ください。

MPCは既存のウォレットに後から導入できますか？

技術的には可能ですが、既存の秘密鍵管理体系からMPCへの移行には、鍵のマイグレーション設計が必要です。新規プロジェクトでの採用が最もスムーズですが、既存サービスへの段階的な導入も、設計次第で実現できます。開発パートナーに現行の構成を共有し、移行プランを策定することを推奨します。

MPC以外にUXとセキュリティを両立する方法はありますか？

Account Abstraction（AA）を活用したスマートコントラクトウォレットも有力な選択肢です。AAでは、送金制限・クールダウン期間の設定・Guardian承認・不正時の凍結など、スマートコントラクトレベルでセキュリティルールを柔軟に設定できます。MPCとAAを組み合わせることで、より高度なセキュリティとUXの両立も可能です。

どのようなtoCサービスにMPCが適していますか？

特に相性が良いのは、NFTを活用した会員証・保証書サービス、Web3ゲーム、ブランド×Web3の施策、ポイント・決済系サービスです。いずれも、エンドユーザーにブロックチェーンの複雑さを意識させたくないサービスに適しています。一方で、完全匿名性を求めるサービスや、上級DeFiユーザーを対象とする場合は、Self-custody型の方が適する場合もあります。

まとめ

toCサービスにおけるウォレット設計は、Web3の思想をどう実現するかという抽象的な議論ではなく、UXと事業継続性を左右する具体的な設計問題です。

秘密鍵管理の方式は、Custody型・Self-custody型・MPC型の3つに大別されますが、toCサービスではCustody型の預かりリスクとSelf-custody型のUX崩壊を同時に回避できるMPC型が、現実的かつ有力な選択肢です。

MPCウォレットの設計は、対象ユーザーの規模・資産の種類・規制対応方針によって最適なパターンが異なります。2-of-2、2-of-3、デバイス分散型それぞれの特徴を理解し、自社サービスに合った構成を選定することが重要です。

XTELAでは、Web3Authを活用したMPCウォレットの開発実績をもとに、要件整理から設計・開発・運用まで一貫して対応しています。toCサービスのウォレット設計でお悩みの方は、構想段階からお気軽にご相談ください。