MPCウォレットとAA（アカウントアブストラクション）の違いと組み合わせ｜「鍵の分散」と「アカウント制御」は層が違う

MPCウォレットとアカウントアブストラクションは、「どちらを選ぶか」を比較する関係にありません。MPC（Multi-Party Computation：複数の参加者が互いの秘密情報を開示せずに共同計算を行う暗号技術）を使ったウォレットは「秘密鍵をどう分散して安全に署名するか」という鍵管理層の技術、アカウントアブストラクション（Account Abstraction：アカウントの検証・実行ロジックをスマートコントラクトへ移す技術群。以下AA）は「その署名で何をどこまで許可するか」を制御するアカウント層の技術で、解決する問題の層が異なるからです。したがって実務の答えは、（1）秘密鍵の単一障害点をなくすことだけが要件ならMPC単独、（2）ガス代の肩代わり・利用条件の制限・鍵紛失時の復旧をオンチェーンで実装したいならAA、（3）両方の要件が重なる機関運用や組み込み型ウォレット（アプリに内蔵され、ユーザーが鍵を意識せず使うウォレット）では併用、という整理になります。MPCの署名は最終的に通常のECDSA署名（Ethereumの標準署名方式）としてチェーンに出るため、AA側からはMPCかどうかを区別できず、両者は技術的に干渉せずそのまま重ねられます。

一方で2026年時点のこの分野は、名前だけで判断すると誤る状況にあります。しきい値署名プロトコルは2023年の脆弱性公表（BitForge）を境に世代交代が進み、「MPCウォレット」と呼ばれる製品の中には、実際には署名を分散計算しないSSS（Shamir's Secret Sharing：鍵を断片に分割し、復元して使う方式）型やTEE（Trusted Execution Environment：外部から隔離されたハードウェア実行環境）型が含まれます。さらに2025年から2026年にかけて、Stripe・Consensys・eToroによる買収で主要プレイヤーの所属も変わりました。本記事は、層の違いと接続点、しきい値署名の現在地、組み合わせの4パターン、方式の実態区分、日本のカストディ規制との接点までを、2026年8月時点の一次情報で整理します。AA全体の俯瞰はAA完全マップ2026で扱っているため、本記事はMPCとの関係に集中します。

なぜ二者択一にならないのか — 担当する層が違う

ブロックチェーン上の資産移転は、「秘密鍵で署名を作る」工程と、「その署名を検証して実行する」工程に分かれます。MPCとAAはこの別々の工程に作用します。

接続点は単純で、MPCで管理する鍵を、スマートアカウントのowner（署名権限者）にするだけです。ERC-4337のスマートアカウントも、2025年5月のPectraアップグレードで導入されたEIP-7702の委任構成も、代表的な実装はownerのECDSA署名を検証するため、その署名が単一の鍵から出たのか、複数シェアの分散計算から出たのかをオンチェーン側は区別しません。規格の詳細はERC-4337の事業者向け解説とEIP-7702の事業者向け解説を参照してください。

MPC（しきい値署名）の仕組みと2026年の現在地

Web3で「MPCウォレット」と呼ばれるものの中核は、MPCの応用であるしきい値署名（TSS：Threshold Signature Scheme）です。鍵生成の段階から分散して行い（DKG：Distributed Key Generation、分散鍵生成）、秘密鍵は一度も完全な形で存在しません。各参加者が持つのは数学的に関連した「鍵シェア」で、署名時はt-of-n（例：2-of-3）のしきい値分の参加者が分散計算に参加し、鍵を復元しないまま有効な署名を生成します。

似た構成と比べると性質がはっきりします。

• オンチェーンマルチシグとの違い：Safeに代表されるマルチシグは「複数の署名をコントラクトで検証する」仕組みで、合意の証跡がチェーンに残る一方、コントラクトが存在するチェーンでしか使えません。TSSは合意がオフチェーンで完結し、チェーンからは1個の通常署名に見えるため、ECDSA/EdDSA系の署名を使うチェーンに横断適用できます。Safe型との使い分けはSafeのモジュラー構成の解説で扱っています。
• SSS（秘密分散）との違い：SSSも鍵を断片に分割しますが、署名のたびにどこかの一点で鍵を復元します。この復元点が攻撃面になるかどうかが、TSSとの本質的な差です。後述するとおり、市場で「MPCウォレット」と呼ばれる製品にはSSS型が含まれるため、この区別は製品選定に直結します。

プロトコルの世代交代も押さえる必要があります。ECDSA向けしきい値署名の実装は長らくGG18/GG20（提案者名と発表年による通称）が事実上の標準でしたが、2023年8月にFireblocksの研究チームが、GG18/GG20のゼロ知識証明の欠落に起因して鍵全体を窃取できる脆弱性（BitForge、CVE-2023-33241）を公表しました。15社超のウォレット事業者が影響を受け、責任開示プロセスを経て修正されています。同時に公表されたLindell17実装の問題は、プロトコル自体ではなく論文からの実装逸脱が原因で、「学術的に安全なプロトコルでも実装が正しいとは限らない」ことを示した事例です。ECDSA向けでは、これらの問題への対策を含む後継方式の一つとしてCGGMP21が提案されており、GG18/GG20からの置き換え先の候補になっています（どの方式を採用しているかは実装ごとに異なります）。Schnorr/EdDSA系（Solana、Bitcoin Taprootなどが使う署名方式）では、FROSTが2024年6月にIETFのRFC 9591として標準化されました。ベンダー選定では「MPC対応」という表記ではなく、採用プロトコル名・監査履歴・BitForge類の修正対応を確認するのが2026年時点の実務です。

AAが追加する制御 — 署名の後段をプログラムする

MPCがどれだけ署名を安全にしても、その署名で「何ができるか」はアカウント側の仕組みで決まります。EOA（秘密鍵で直接操作する従来型アカウント）は有効な署名に対して全資産の移転を無条件に許すため、統制はすべて署名前のオフチェーン承認に依存します。AAはこの検証ロジック自体をプログラム可能にし、次のような制御をオンチェーンの強制力を持つ形で追加します（ERC-4337仕様）。

• 利用条件の制限：送金上限、宛先の許可リスト、操作可能なコントラクト・関数の限定。
• Session Key（期限・対象・上限を絞った一時的な署名権限）：ゲームや高頻度操作で、都度承認なしに範囲限定の操作を許可します。
• ガス代の肩代わり：Paymaster（ガス代の支払いをユーザー本人から差し替えるコントラクト）により、ユーザーがETHを持たない状態を作れます。費用構造はガスレストランザクションの経済性で詳述しています。
• 復旧の組み込み：owner鍵を失っても、事前に指定したGuardian（復元承認者）の合意でownerを差し替えられます（Social Recoveryの実装パターン）。

逆に、AAはsigner鍵の保管方法を何も規定しません。スマートアカウントのownerが単一のEOA鍵なら、その鍵の漏洩が全権の漏洩になる構図はEOAと変わりません。ここが鍵管理層との組み合わせが意味を持つ理由で、選択肢はMPCだけではなく、パスキー（顔・指紋などの生体認証を使うFIDO2ベースの認証鍵）をsignerにする経路もあります（パスキー×ERC-4337の解説）。パスキーはP-256という別方式の署名をオンチェーンで検証するのに対し、MPCは通常のECDSA署名のまま鍵管理だけを強化する、という位置づけの違いがあります。

組み合わせは4パターン — 要件から逆算する

鍵管理層とアカウント層の取り方で、実務の構成は次の4パターンに整理できます。

A（MPC単独）は、Fireblocksなど機関向けカストディ基盤の古典的構成です。Bitcoin・Solanaを含む複数チェーンを同じ鍵管理基盤で扱え、しきい値を組織の承認フローに一致させることで内部統制を作ります。コールド運用（シェアの一部をオフライン保管）に対応する実装もあります（Fireblocks: What is MPC?、2026年8月11日閲覧）。オンチェーンの強制力を持つ制約は作れないため、統制はオフチェーン承認の運用品質に依存します。

B（AA単独）は、signerを単一鍵やパスキーにしてスマートアカウントの機能だけを使う構成で、コンシューマ向けではこれで足りる場面が多くあります。組織として鍵の分散保有が必要な場合には、signer鍵が単一障害点として残ります。

C（MPC＋AA）は、人の合意による統制（MPCのしきい値）とシステムによる強制（AAの制約）を重ねる構成です。たとえば署名にはコンプライアンス担当を含む2-of-3の合意を必須にしつつ、それでも通ってしまう誤送金・内部不正に備えて、送金上限と宛先許可リストをオンチェーン側で強制する、という二重統制になります。統制要件の厳しい機関運用やB2B資産管理で検討される構成です。

D（組み込み型ウォレット＋AA）は、SSOやパスキーでの認証から鍵シェアの利用を解錠し、ユーザーには署名もガス代も意識させない構成で、コンシューマ向けWeb3サービスの標準形になりつつあります。認証→分散署名→Session Keyによる透過的な操作→Paymasterによるガス肩代わり、という流れです。ただしこのパターンの「鍵管理層」は製品によって中身が大きく異なります。次章で整理します。

「MPCウォレット」の中身は1つではない — 方式の実態と勢力図

組み込み型ウォレット基盤は「MPCウォレット」と一括りに呼ばれがちですが、2026年8月時点の主要製品の公式ドキュメントを確認すると、鍵の守り方は少なくとも3方式に分かれます。

具体的には、Web3AuthのMPC Core KitはTSSベースの分散署名を実装しています（Web3Auth Docs）。一方Privyは、公式ドキュメントでSSSによる2-of-2のシェア分割とTEE内での復元・署名を明示しており、TSS型MPCを採用しない選択を脅威モデルと性能の判断として説明しています（Privy Security Architecture）。TurnkeyはMPCを使わないことを明言し、鍵の生成から署名までをAWS Nitro EnclavesのTEE内に閉じる設計です（Turnkey: Proven security）。CoinbaseのCDP Walletsも、現行のセキュリティ文書では、秘密鍵の生成・暗号化と復号・署名をAWS Nitro EnclavesのTEE内で行い、平文の鍵がenclaveの外に出ない構成として説明されています（CDP Docs: Wallet Security Overview）。なおCoinbaseは、自社の暗号資産保護に使われてきたMPCライブラリを基にした汎用ライブラリcb-mpcをオープンソースで公開していますが、これは開発者向けの部品であり、ホスト型のCDP Wallets自体がMPC構成であることを示すものではありません（cb-mpc）。

ここで重要なのは、SSSやTEEが一律に劣るわけではないことです。TEE型は分散計算のオーバーヘッドがなく低レイテンシで、SSS＋TEE型も復元点をハードウェア隔離環境に限定しています。差が出るのは評価の観点です。（1）鍵が揃う瞬間が存在するか、（2）信頼の置き場所がどこか（TSSはプロトコルと実装、TEEはハードウェアベンダーとクラウド事業者）、（3）事業者側の保有分だけで署名が完成するか。特に（3）は後述する日本のカストディ規制の該当性評価に直結します。

プレイヤーの所属も短期間で変わりました。2025年6月にStripeがPrivyの買収を発表し（Privy公式発表、2025年6月11日）、同月ConsensysがWeb3Authの買収を発表してMetaMaskのオンボーディングへの組み込みを表明（Consensys、2025年6月2日）、2026年4月にはeToroがMPCウォレットの先駆けZengoの買収（約7,000万ドル）を発表しています（eToroプレスリリース、2026年4月15日。背景はeToro×Zengo買収の解説）。CoinbaseもWallet as a Serviceの機能をCoinbase Developer Platform（CDP）のウォレット製品群へ再編しています。ベンダー選定の与件（提供主体・料金・サポート・製品の存続方針）が買収で変わり得ることは、この分野のロックイン評価に織り込む必要があります。

選定の判断軸 — どの要件がどの層を要求するか

4パターンのどれを選ぶかは、次の5つの要件を確認すると絞れます。

• 対応チェーン：スマートアカウント（ERC-4337/EIP-7702）はEVM系チェーンの仕組みです。BitcoinやSolanaを含む複数チェーンを1つの鍵管理基盤で扱う要件があるなら、横断部分はMPC側で統一し、AAはEVM圏の口座にだけ適用する構成になります。
• 統制の実装場所：「人の承認合意」で足りるならMPCのしきい値、承認をすり抜けた操作も機械的に止めたいならAAの制約が必要です。両方要るのがパターンCです。
• 復旧の経路：MPCはシェアの再発行（reshare）で、AAはGuardian合意によるowner差し替えで復旧します。組織運用ならバックアップシェアで鍵管理層に閉じられますが、コンシューマ向けで「ユーザーが何も保管しない」復旧を作るならAA側の仕組みが活きます。
• ガス代の負担：ユーザーにETHを持たせない要件があるなら、Paymasterを使うためにAAが実質必須です。
• 規制との接点：事業者がサーバー側シェアをどう持つかは、日本ではカストディ規制の該当性評価そのものです。次章で扱います。

日本の規制接点 — サーバー側シェアを持つ事業者はカストディか

資金決済法は「他人のために暗号資産の管理をすること」を業として行う行為を暗号資産交換業の対象とし、金融庁の事務ガイドラインは、事業者が利用者の暗号資産を移転するのに足りる秘密鍵を保有し、主体的に移転を行い得る状態にあるかを該当性の基準として示しています。非該当の例として、（1）秘密鍵の一部の保有にとどまり、事業者の保有分だけでは単独でも関係事業者と共同でも移転できない場合、（2）保有する秘密鍵が暗号化されており復号に必要な情報を保有しない場合、の2類型が明示されています（金融庁事務ガイドライン第三分冊16）。

MPC構成にこの基準を当てると、問いは「MPCだから非該当」ではなく、「事業者（と委託先）の保有分が、署名しきい値に達するか」という設計の問題になります。確認すべき点は次のとおりです。

• 通常運用の署名経路：2-of-2でユーザーデバイス側シェアが必須の設計なら、事業者側だけでは署名が完成しません。逆に、事業者と委託先（クラウドHSM運用者など）のシェアを合わせてしきい値に達するなら、「単独では不可」でも「共同で可」となり整理が変わり得ます。
• 復旧経路：通常運用で署名できなくても、事業者がreshareや復旧フローを通じて単独署名可能な状態を作れるなら、その経路も評価対象です。
• バックアップの持ち方：暗号化シェアを預かる場合、復号情報（パスワード、復号鍵）を誰が持つかで上記2類型目の整理が左右されます。

この評価は構成の名称ではなく実質で行われます。SSS型やTEE型のように鍵が事業者インフラ内で復元される方式では、「復元された鍵に事業者がアクセスし得るか」がTEEの隔離設計・運用権限を含めて問われることになり、TSS型とは論点の形が変わります。なお、パスキーでユーザー自身が鍵を管理するアンホステッド型の構成については、2024年10月にグレーゾーン解消制度を通じて「暗号資産の管理に該当しない」との金融庁確認が出た先例があります。スマートアカウント側の権限分解（Session Key・Guardian・アップグレード権限など）を含めた該当性の全体像はAAの規制該当性の解説で扱っています。該当性の最終判断は個別の設計・契約に依存する法的判断であり、弁護士等の専門家の領域です。本記事は技術設計側で整理すべき論点の提示にとどめます。

実装・運用で事故が起きやすい箇所

MPC×AA構成の障害・インシデントは、プロトコルの数学ではなく初期設計と運用の詰めの甘さから起きるのが典型です。

• DKG（分散鍵生成）セレモニーの軽視：初期鍵生成時の環境が汚染されていれば、以後の分散管理は意味を持ちません。隔離環境・複数者の立会い・手順の記録を初回から設計します。
• シェア配置の障害ドメイン集中：複数シェアを同一クラウド・同一リージョン・同一組織の管理下に置くと、分散の意味が失われます。障害・侵害・組織リスクのドメインを分けて配置します。
• reshare運用の欠落：担当者の退職・端末の紛失・定期ローテーションに対応するシェア再発行のフローを、発生してから考えるのではなく初期設計に含めます。
• 監査範囲の分界の誤認：MPCベンダーの監査は自社が実装するスマートアカウント側を守りません。BitForgeが示したとおり、プロトコルが安全でも実装逸脱で破られるため（前掲Fireblocks）、「ベンダー利用＝監査済み」とは扱えません。AA側の攻撃面はAAセキュリティリスクの解説で整理しています。
• 署名スキームと対象チェーンの不整合：ECDSA（EVM、Bitcoin）とEdDSA/Schnorr（Solana、Bitcoin Taproot）ではしきい値署名のプロトコル自体が異なります（前掲RFC 9591）。対象チェーンの拡張予定を先に確定し、ベンダーの対応スキームと突き合わせます。
• Session Key・モジュール権限の緩さ：アカウント層側では、Session Keyの対象・上限・期限の粒度設計と、Validator等のモジュール差し替え権限の管理が定番の事故箇所です。権限が緩いほど前章の規制評価にも跳ねます。

まとめ

• MPCは鍵管理層（署名を作るまで）、AAはアカウント層（署名後の検証・実行）の技術で、二者択一ではなく組み合わせられます。MPCの署名は通常のECDSA署名としてチェーンに出るため、両者は干渉しません。
• 構成は「MPC単独」「AA単独」「MPC＋AA」「組み込み型ウォレット＋AA」の4パターンで、対応チェーン・統制の実装場所・復旧経路・ガス負担・規制接点の5軸から逆算して選びます。
• しきい値署名プロトコルは、BitForge（2023年、CVE-2023-33241）を機にGG18/GG20の見直しが進み、後継方式の一つとしてCGGMP21が提案されています。Schnorr/EdDSA系はFROST（RFC 9591）が標準化されています。選定時は「MPC対応」の表記ではなくプロトコル名と監査・修正履歴を確認します。
• 「MPCウォレット」と呼ばれる製品の実態はMPC-TSS・SSS＋TEE・TEE単独の3方式に分かれ、鍵が揃う瞬間の有無、信頼の置き場所、事業者側だけで署名が完成するかが評価の分かれ目です。この分野は2025〜2026年の買収（Stripe・Consensys・eToro）で提供主体も変わっており、ロックイン評価が必要です。
• 日本のカストディ該当性は「事業者の保有分で移転に足りるか」の実質で評価され、通常運用の署名経路だけでなく復旧経路・バックアップの復号情報も対象になります。最終判断は専門家の領域です。

関連記事

前提となる規格の理解：

• アカウントアブストラクション（AA）完全マップ 2026 — AA全体の俯瞰と採用形態の判断軸
• ERC-4337の事業者向け解説 — EntryPoint・Bundler・Paymaster・Smart Accountの役割分担
• EIP-7702の事業者向け解説 — 既存EOAをスマート化する補完規格

組み合わせる各要素の深掘り：

• Safeのモジュラー構成 — オンチェーンマルチシグ型スマートアカウントとの使い分け
• パスキー（WebAuthn）×ERC-4337 — MPCと並ぶsigner側のもう1つの選択肢
• Social Recoveryの実装パターン — アカウント層側の復旧設計
• ガスレストランザクションの経済性 — Paymasterの費用実勢と負担設計
• AAセキュリティリスク — スマートアカウント側の攻撃ベクトルと監査観点

規制・業界動向：

• AAの規制該当性 — カストディ該当性の現行基準と署名権限の分解
• eToro×Zengo買収の解説 — MPCセルフカストディを巡る業界再編

XTELAが支援できる範囲

MPCとAAの組み合わせは、「どの統制を人の合意に置き、どの制約をオンチェーンに置くか」という設計判断が先にあり、ベンダー選定はその後です。XTELAは、要件整理とアーキテクチャ設計レビュー、鍵管理方式（MPC-TSS/SSS/TEE）とAA構成の比較選定、Session Key・Paymaster・Recoveryを含むスマートアカウントの実装支援、監査前の設計レビューまで、Web3サービスの技術面を支援しています。カストディ該当性など規制面の判断は弁護士等の専門家の領域として切り分けたうえで、その検討に必要な技術構成の文書化を支援します。

ウォレットアーキテクチャ設計について相談する

主要参考資料

• ERC-4337: Account Abstraction Using Alt Mempool
• EIP-7702: Set Code for EOAs
• Fireblocks: BitForge — 責任開示ブログ（2023年8月9日）
• Canetti et al.: UC Non-Interactive, Proactive, Threshold ECDSA（CGGMP21）
• IETF RFC 9591: The FROST Protocol（2024年6月）
• Fireblocks: What is MPC?（2026年8月11日閲覧）
• Web3Auth Docs: MPC Core Kit（2026年8月11日閲覧）
• Privy Docs: Security Architecture（2026年8月11日閲覧）
• Turnkey: Proven security — why Turnkey built beyond MPC（2026年8月11日閲覧）
• Coinbase Developer Platform: Wallet Security Overview（2026年8月11日閲覧）
• Coinbase: cb-mpc（Coinbase由来の汎用MPCライブラリ）
• Consensys: Web3Auth買収発表（2025年6月2日）
• Privy: Privy and Stripe — Bringing crypto to everyone（買収公式発表、2025年6月11日）
• eToro: Zengo買収プレスリリース（2026年4月15日）
• 金融庁: 事務ガイドライン第三分冊16（暗号資産交換業者関係）

本記事の前提

本記事は2026年8月11日時点で確認した一次情報に基づく技術・事業設計上の論点整理であり、投資助言・法的助言ではありません。各社の製品構成、採用プロトコル、提供主体、規格のバージョンは今後変わり得ます。導入判断の際は最新の公式ドキュメントを確認し、カストディ該当性など法令・会計・税務の判断は有資格の専門家に相談してください。