2026年7月21日に一般提供が始まったマイナウォレットは、Ethereum の Account Abstraction と公的個人認証を組み合わせ、秘密鍵や端末を失っても復旧できる一般利用者向けウォレットを実現している。同じことは Cardano でもできる。足りないのは技術ではなく、統合された標準である。
Cardano に必要なのは新しいウォレットアプリではなく、ERC-4337 に相当するエコシステム共通の復旧可能スマートウォレット標準である。
部品はすでにある。マルチシグ、時間ロック、Plutus validator、状態 UTxO、そして CIP-1854・106・141・146。統合されていないだけである。
本稿は執筆の過程で、公開情報の読み違いによる訂正を複数回行っている。そこで全主張について 6 系統の並行調査を行い、一次資料まで遡って裏を取った。以後、主要な事実には確度を明示する。
exp_mod_integer ビルトイン（CIP-109）が 2026 年 7 月 18 日の Van Rossem ハードフォークでメインネット有効化された。zkFold が Google の RSA 署名で同じことを実測している。マイナウォレット製品版のパスキー検証方式・復旧の待機期間や取消の有無・コントラクトアドレス・監査報告は、いずれも公開されていない。またスマートコントラクトによる自動移転が法的に有効な相続と認められるかは、肯定・否定いずれの当局見解も裁判例も存在しない。これらは推測で埋めず、未確認のまま記載する。
専門用語をぜんぶ抜いて、この資料が何の話をしているのかだけを書く。ここだけ読んでも筋は通るようにしてある。
いまのウォレットは鍵そのものが口座。
スマートウォレットは口座と鍵が別々。
変な家を想像してほしい。鍵の形から、その家の住所が決まる家である。
すると、こうなる。鍵を新しいものに変えたら、住所まで変わってしまう。だから鍵は一生変えられない。そしてなくしたら、その家には二度と入れない。家ごと消えたのと同じことになる。
シードフレーズは、この鍵を作るための元にあたる。だから絶対になくせない。いまのウォレットが「24 語を一生なくさないでください」と言うのは、意地悪だからではなく、構造がそうなっているからである。
ふつうの家では、住所は住所、鍵はただの鍵である。
鍵をなくしたら、鍵屋を呼んで錠前を交換する。住所は変わらない。中の荷物も動かない。鍵は「いま使っている合鍵」にすぎないので、なくしたら作り直せばいい。
やろうとしているのは、これだけである。ウォレットを、ふつうの家にする。
いまのウォレット 鍵 ──→ 住所が決まる 鍵を変える = 住所が変わる = 別の家になる 鍵をなくす = 家ごと消える スマートウォレット ルール ──→ 住所が決まる 鍵は「ルールの中身」として別に書いてある 鍵を変える = 錠前の交換。住所はそのまま
五行で書ける。
アドレスは「ルールの文章」から計算される。「いまの鍵は誰か」は、その文章の中に書かれていない。
だからアドレスを変えずに、鍵だけを変えられる。
逆に言うと、鍵をルールの文章の中に直接書いてしまうと、鍵を変えたときに文章が変わり、アドレスまで変わってしまう。第 II 部で「ネイティブスクリプトだけでは足りない」と書いたのは、まさにこの理由による。
「シードフレーズなし」って、鍵がないということ？
いいえ。鍵はある。パスキーの中、端末の中にある。なくなるのは「一生保管し続けなければいけない、たった一つの秘密」のほうである。取り戻し方が、秘密から人・機関・時間に変わる、と言ったほうが近い。
チャールズが話していた ZK の復旧とは、どう違うの？
あれは 24 語を他人に見せずに証明できるようにするもので、24 語は根っこに残っている。この資料の話は、24 語そのものを要らなくするもの。似て見えるが別のことにあたる。
WASM やシャーディングの話とは関係あるの？
別の軸になる。あちらは速さの話で、チェーンがどれだけ速く安く動くか。こちらは入り口の話で、人がどうやって中に入るか。いくら速くなっても、鍵をなくした人は入れないままである。どちらも要るが、片方がもう片方を解くことはない。
Cardano ではパスキーが使えないの？
「使う」に三段階ある。パスキーでログインして、裏にある別の鍵で署名する——これは今日でも作れる。利用者から見れば顔認証で送金できるので、体験としては完成する。
できていないのは三段階目、パスキーの署名そのものをチェーンが直接確かめるところである。ここが要るのは、裏に別の鍵を置くと「その鍵は誰が持っているのか」という問題が新しく生まれるためにあたる。詳しくは第 II 部の補足に書いた。
結局、いちばんの難所はどこ？
技術ではなく合意である。作れることは分かっている。ウォレット事業者と dApp が同じやり方を採らないと、利用者から見て「どのウォレットでも使える口座」にならない。第 IV 部と第 V 部はその話をしている。
本稿の初期の版は、ここを混ぜて書いていた。「今週できるようになった」と「ずっとできた」を並べていたので、「Cardano でスマートウォレットが作れるようになった」と読めてしまう書き方になっていた。それは正しくない。先に分ける。
| 何の話か | いつからできるのか | 種類 |
|---|---|---|
| スクリプトでウォレットを作る | ずっと前から（Plutus） | ― |
| dApp と繋ぐ（CIP-141） | 2023 年から可能。採用されていないだけ | 決め事だけ |
| 公的個人認証の署名をチェーンが直接確かめる | 2026-07-18 〜（CIP-109 / Van Rossem） | 台帳変更 |
| パスキーの署名をチェーンが直接確かめる（P-256） | まだできない | 台帳変更が要る |
| 次期マイナンバーカードの署名を確かめる（P-384） | まだできない。カード側は 2029 年度予定 | 台帳変更が要る |
7 月 18 日に変わったのは、3 行目だけである。ウォレットの構造にも、鍵の交換にも、dApp 接続にも関係しない。それらは全部、以前からできた。
署名とは「この文書は確かに私が作りました」を数学で証明する仕組みで、ハンコの電子版にあたる。RSA はその方式の一つで、1977 年からある古典的なやり方である。巨大な素数の掛け算を使う。マイナンバーカードはこれを使っている。
Cardano がもともと使えたのは Ed25519 という別方式だった。方式が違うと計算のやり方がまったく違うので、「Ed25519 は確かめられるが RSA は確かめられない」という状態があり得た。7 月 18 日に、RSA の検証に必要な計算（べき剰余）が Plutus に入った。
ここが本稿でいちばん誤解されやすい。公的個人認証を使うこと自体は、以前からできた。認定を受けた事業者に委託すれば、カードを読んで本人確認をすること自体に障害はなかった。
カードをタッチ ↓ PF が署名を検証（オフチェーン） ↓ 「本人確認できました」 ↓ 自社サーバが自分の鍵で 「この人は本人です」に署名 ↓ validator は 自社サーバの署名を確認
カードをタッチ ↓ カードが RSA 署名を出す ↓ その署名をそのまま トランザクションに入れる ↓ validator が RSA 署名を自分で確かめる
左でも動く。ずっと動いた。しかし左では、チェーンは「会社がそう言っている」を信じているだけである。validator には、本当にカードがタッチされたのか、サーバが勝手にそう言ったのかを区別する手段がない。サーバの鍵が漏れても、内部で不正が起きても、外から圧力がかかっても、チェーン側には分からない。
信頼の根っこが、会社からカードに移った。チェーンが「カードが署名した」ことを、自分で数学的に確認できるようになった。
| チェーンだけで完結するか | |
|---|---|
| 署名が正しいか | 7/18 からできる |
| 証明書が本物か（認証局が発行したものか） | 工夫すればできる |
| 失効していないか | できない。J-LIS に問い合わせるしかない |
カードを紛失して一時停止した、転居で失効した ―― これはオンチェーンでは原理的に分からない。したがって認定事業者は引き続き必要になる。ただし役割が変わる。
7/17 まで 「本人確認しました」と保証する人 ← 信頼の根っこ 7/18 以降 「この証明書はまだ有効です」と答える人 ← 一部だけ
確ここは見落とすと設計を間違える。次期マイナンバーカードは RSA をやめる。デジタル庁「次期個人番号カードタスクフォース 最終とりまとめ（案）」（2024-03-18）に、こう書かれている。
・ その前提として、10年の有効期間に耐えうる強固な暗号方式に移行する。 （公開鍵暗号方式について ECDSA 384（192ビットセキュリティ）、 ハッシュ関数について SHA-384（192ビットセキュリティ）） また、カードの仕様としては256ビットセキュリティの暗号方式 （公開鍵暗号方式について ECDSA 521、共通鍵暗号方式について AES256、 ハッシュ関数について SHA-512）に対応できるものの採用を検討する
確提供時期は2029 年度を目指すとされている（デジタル庁の重点計画。2026-07-21 報道）。移行は自然更新で進める方針で、同文書は「次期カード導入時期以降、現行カードの電子証明書の更新の際には、更新ではなく次期カードの取得を推奨する」としている。現行 RSA2048 の利用がいつまで許容されるかは「判断し、具体的な対応案を検討する」とされ、未期限は未定である。
現行カード（RSA 2048）― CIP-109 により、2026 年 7 月 18 日から Cardano で検証できる。今日から使える。
次期カード（ECDSA P-384）― Cardano に対応する検証機能は存在しない。Cardano が持つ ECDSA は CIP-49 の secp256k1 であり、同じ ECDSA でも曲線が違うのでそのままでは検証できない。
つまり 7 月 18 日に手に入った能力には、寿命がある。
なお同文書は、カードに新旧両方の暗号を載せるのではなく利用者の端末側のソフトウェアで新旧を扱う方針を示している。したがって移行期には RSA のカードと ECDSA のカードが併存し、どちらにも対応する必要が生じる。また将来的な PQC（耐量子計算機暗号）の採用も否定されていない。
混同しやすいので分けておく。どちらも楕円曲線だが、曲線が違う。
電子署名
├─ RSA ─────────── 現行マイナンバーカード（2048ビット）
└─ 楕円曲線
├─ Ed25519 ─── Cardano の標準署名
└─ ECDSA
├─ secp256k1 ─ Bitcoin / Ethereum。CIP-49 で対応済み
├─ P-256 ───── パスキー・WebAuthn・Secure Enclave
└─ P-384 ───── 次期マイナンバーカード（案）確CIPs・Plutus・cardano-ledger の三つのリポジトリを検索したが、secp256r1・WebAuthn・passkey のいずれもヒットは 0 件だった。提案すら存在しない。「できるようになりそう」ではなく「誰も言い出していない」が現状にあたる。
Cardano が署名方式を増やした前例はある。Ed25519 だけだったところに CIP-49 が提案され、secp256k1 の ECDSA・Schnorr が追加され、ハードフォークで有効化された。通ったのは、Bitcoin・Ethereum との相互運用という明確な需要があったからである。同じ道筋（CIP を書く → 安全性と実装コストを検証 → 組込関数として実装 → ハードフォーク）を辿ることになる。
P-256 と P-384 はどちらも NIST の P 曲線である。ひとつの CIP でまとめて提案できる可能性がある。そしてその提案には、他に例のない強みが二つある。
ただし現状は、未誰も提案していない。「2029 年に必要になるから Cardano 側が自動的に準備する」という状態ではない。誰かが問題を明文化する必要がある段階にある。そして第 IV 部で見たとおり、鍵管理・復旧・認証を主題とする CPS（問題提起文書）は 21 件中 1 件も存在しない。
まず、プログラマブルウォレットが従来のウォレットと何が違うのかを整理する。
いまのウォレットは、利用者に次の運用を求めている。
24 語のシードフレーズを安全に保管してください 他人には絶対に見せないでください 紛失したら誰にも復旧できません 盗まれたら資産を奪われる可能性があります
暗号資産に慣れた人には当然に見えるが、高齢者、子ども、機種変更に不慣れな人、紙のバックアップを安全に保てない人、家族に資産を引き継ぎたい人にとって、「24 語を一生なくさず誰にも見せずに管理する」は現実的ではない。台帳がどれほど堅牢でも、紙を一枚なくしただけで資産に永久に触れなくなるなら、社会インフラとしては弱点が残る。
問題は秘密鍵の存在ではなく、秘密鍵が唯一絶対の条件であることにある。鍵の紛失、盗難、フィッシング、端末故障、相続、認知機能の低下、誤操作。人間の側で普通に起きることに、この構造は何も対応できない。
現在の一般的なウォレットも複数の UTxO を持つが、それらは基本的に同じ秘密鍵系統で管理されている。
シードフレーズ │ 鍵を生成 ▼ 支払い秘密鍵 │ ├─ UTxO ① 100 ADA ├─ UTxO ② NFT └─ UTxO ③ USDM
資産の箱は複数あるが、開ける条件は基本的に正しい秘密鍵の署名があることの一点。したがってシードフレーズを失えば、すべての箱が同時に開かなくなる。
各 UTxO を秘密鍵だけでなく Plutus スクリプトのルールで保護する。鍵や復旧設定そのものは、独立した状態 UTxO に台帳として記録される。
Cardano Smart Wallet │ ├─ 状態 UTxO │ ├─ 現在の操作鍵 │ ├─ 復旧鍵 ・ guardian │ ├─ 復旧待機時間 │ ├─ 送金上限 │ └─ ウォレット識別子 │ ├─ 資産 UTxO ① 100 ADA ├─ 資産 UTxO ② NFT └─ 資産 UTxO ③ USDM
これらをウォレットアプリがまとめて、利用者には一つの残高・一つの口座として見せる。資産を動かすとき、スクリプトは操作の種類ごとに異なる条件を判定する。
プログラマブルウォレットでも、内部では通常どおり鍵を使う。パスキーの暗号鍵、Cardano の署名鍵、ハードウェアキー、guardian の鍵。変わるのは鍵の有無ではなく、一つの秘密鍵だけがウォレット全体を永久に支配する構造ではなくなるという点である。
鍵 A を持っているか？
│
├─ Yes → 全操作可能
└─ No → 何もできない
今回の操作は
設定された条件を
満たしているか？
│
└─ 通常送金 ／ 高額送金 ／
復旧ごとに判定
表現を整えるなら、プログラム可能な金庫室の中に、複数の UTxO という資産箱が入っていると考えると分かりやすい。
| Ethereum AA | Cardano で考えられる構成 |
|---|---|
| スマートアカウント | Plutus スクリプトで管理される論理ウォレット |
| コントラクトの保存状態 | 状態 UTxO |
| アカウント残高 | 関連する資産 UTxO 群 |
| owner の変更 | 状態 UTxO 内の操作資格情報を更新 |
| social recovery | guardian 署名＋時間制限 |
| Paymaster | 手数料 UTxO を提供するスポンサー |
| ウォレットアドレス | スクリプトアドレス＋ウォレット識別子 |
Cardano でも、秘密鍵で直接支配される UTxO 群をウォレットと考えるのではなく、プログラム可能なルールで管理される UTxO 群と状態 UTxO を、一つの論理的なスマートウォレットとして扱えばよい。
この資料の出発点になった疑問。結論から言うと、前提が少しずれている。
Ethereum の EOA は、プロトコルレベルで secp256k1 の ECDSA 署名を検証するという規則が焼き付けられている。この検証ロジックは差し替えられない。つまり Ethereum では「鍵を持っているか」以外の条件でアカウントを守ることが、そもそも原理的にできなかった。
ERC-4337 が取った解決は、プロトコルを変更せずに済ませることだった。通常のトランザクションとは別に、UserOperation → Bundler → EntryPoint というもう一本のパイプラインをアプリケーション層に作る。EntryPoint も Paymaster も Bundler も、EOA の制約を迂回するために必要になった部品であって、スマートウォレットという概念に本質的に必要な部品ではない。
2025年5月の Pectra アップグレードで入った EIP-7702 は、既存の EOA が一時的にコントラクトとして振る舞えるようにするもので、これも「すでに大量にある EOA をどう救うか」という Ethereum 固有の移行問題に対する答えである。
確迂回路とはいえ、実運用では十分に育っている。BundleBear の集計では 2026 年 7 月時点で 12 チェーン・6,253 万アカウント・累計 12.1 億件の UserOperation。ただしこのアカウント数は「デプロイ済み数」ではなく「UserOp を 1 回以上出したアカウント数」であり、また 12 チェーンは集計対象の数であって ERC-4337 が動くチェーンの数ではない。Cardano 側にこれに相当する運用実績はない。
eUTxO では、スクリプトアドレスがそのままスマートアカウントである。validator に書いた条件が、そのアドレスの資産を動かす条件になる。EOA とコントラクトアカウントという区別が構造として存在しないので、「アカウントの検証ロジックを差し替える」という課題自体が発生しない。
したがって「Cardano には AA がない」というより、AA が解こうとした問題が Cardano にはない、というのが正確なところになる。「Cardano には口座をプログラム化する発想がない」という説明を見かけるが、これは正確ではない。スクリプトアドレスは最初からプログラム可能な口座である。
Cardano にはネイティブスクリプトという、Plutus より下の層がある。ここで atLeast（M-of-N）と時間ロックが書ける。つまり第 I 部で挙げた「guardian 2 人＋48 時間の待機」は、実はスクリプトを書かなくても表現できる。
any
├─ 本人の鍵 ← 通常時
└─ all
├─ atLeast 2 of [G1, G2, G3] ← guardian
└─ after (slot + 48h) ← 待機Plutus を使わないので手数料が安く、後述するコラテラルも不要。ただし状態を持てないのが決定的な差になる。送金上限のような動的な判定ができず、何より鍵を入れ替えるとスクリプトが変わり、アドレスそのものが変わってしまう。
第 I 部で状態 UTxO を分けて置いたのは、まさにこれを避けるためである。アドレスを固定したまま中の資格情報だけを差し替えられること。それが Plutus と状態 UTxO を持ち出す理由になる。
「原理的にできる」と「製品にできる」の間にあるものを、具体的に並べる。
Plutus に組み込まれている署名検証は Ed25519 と、CIP-49 で 2023 年に追加された secp256k1 の ECDSA／Schnorr。一方、パスキー・Secure Enclave・YubiKey・WebAuthn が使うのは P-256（secp256r1）で、これを検証するビルトインは、2026 年 7 月時点で標準に入っていない。Ethereum は L2 が 2024 年、メインネットも 2025 年 12 月に導入済みである。
影響：マイナウォレットの「パスキーで操作」を、そのままオンチェーン条件にできない。パスキーはアプリ側の認証に留めて別途 Ed25519 鍵を持たせるか、ZK で検証する（高コスト）ことになる。ここが一番具体的な差。
口座の状態を一つの UTxO に置くと、それを消費するトランザクションは同時に一つしか通らない。連続送金がぶつかる。eUTxO で口座モデルを素直に真似ると必ずここに当たる。
回避策は確立している。Vasil で入った参照入力（CIP-31）を使えば、状態 UTxO を消費せずに読むだけにできる。通常送金では参照のみ、鍵の更新など状態を書き換えるときだけ消費する、と設計を分ければ競合しない。
Plutus スクリプトを実行するトランザクションはコラテラルを差し出す必要があり、そのコラテラルはスクリプトアドレスに置けない。通常の鍵アドレスにある、他トークンを含まない純粋な ADA でなければならない。
つまり完全にスクリプト管理のウォレットでも、手数料・コラテラル用の平の UTxO を別に持ち続けることになる。ここを誰が用意するかが、そのまま手数料スポンサー（Paymaster 相当）の設計論点になる。
dApp とウォレットをつなぐ CIP-30 は、signTx が署名の witness を返すモデルになっている。しかしスクリプトウォレットで必要なのは署名ではなく、validator を満たすトランザクションを組み立てることである。実際、マルチシグ向けの拡張である CIP-106 は signTx() と signData() を無効化し、代わりに非同期の submitUnsignedTx() / getCompletedTx() を置いている。署名モデルが合わないことが、規格の側でも認められている。
後述するとおり拡張案自体は存在する（CIP-106・CIP-141）。ただしいずれも Proposed で、複数ウォレット・複数 dApp に広く採用された共通標準にはなっていない。
前節を「パスキーは使えない」と要約すると不正確になる。三つの水準を分けて考える必要がある。利用者から見れば三つとも「顔認証で送金できた」で同じだが、裏側はまったく違う。
| 水準 | 何が起きているか | 今日できるか |
|---|---|---|
| 1 ログイン |
パスキーは本人確認だけに使い、実際の署名はサーバ・MPC・組込ウォレットが Ed25519 で行う | できる。一般的な Web 技術で足りる |
| 2 開錠 |
端末内に Cardano の Ed25519 鍵を置き、顔認証に成功したら使えるようにする | できる。チェーンから見れば通常の署名 |
| 3 直接検証 |
資産をスクリプトアドレスに置き、パスキーの P-256 署名を Plutus が検証する | 標準化・本番実績・十分なベンチマークが確立していない |
したがって正確な言い方はこうなる。
Cardano の標準トランザクション署名は、一般的なパスキーの P-256 署名に直接対応していない。パスキーで別の Cardano 鍵を操作する方法は今日でも作れるが、P-256 署名を Cardano 上で直接・低コストに検証する標準的な仕組みは、まだ確立していない。
水準 1 と 2 でも、利用者の体験は成立する。しかし鍵の所在という問題が残る。
水準 3 まで到達すると、パスキーそのもの――セキュアチップから外に出ない鍵――が、ウォレットの操作資格になる。別の鍵を管理する必要がなくなり、鍵の所在という問題自体が消える。だからこれは利便性の話ではなく、信頼をどこに置くかの話にあたる。
そして水準 3 に至る道は、P-256 ビルトインの追加だけではない。第 VII 部で述べるとおり、CIP-381 による ZK 証明の検証という経路がすでに開いている。ただしそちらも、P-256 回路での実測は確認できていない。
ここは正確に押さえておく必要がある。Ethereum では水準 3 が仮説ではなく、プロトコルの標準機能として動いている。
Base、Optimism、Polygon、Arbitrum、zkSync などに導入。3,450 gas で P-256 署名を検証でき、コントラクトによる自前実装と比べて約 100 分の 1 になった。Coinbase Smart Wallet のように、パスキーをそのままアカウントの操作資格にする実装が成立している。
確Fusaka アップグレードで有効化（slot 13,164,544）。secp256r1 のプリコンパイルが Ethereum L1 の標準機能になった。ガスは 6,900 で、L2 の 3,450 とは異なる。また EIP-7951 は RIP-7212 と互換を保ちつつRIP-7212 のセキュリティ上の欠陥を修正したものであり、「そのままメインネットに来た」わけではない。
つまりマイナウォレットが対応する 6 チェーンのすべてで、パスキーの署名をチェーンが直接検証できる状態にある。未同社が実際にどの水準を採っているかは公開情報から判断できないが、少なくとも基盤の側に制約はない。
確なお実装方式は「プリコンパイルか Solidity か」の二者択一ではない。Coinbase Smart Wallet はプリコンパイルを優先し、無ければ Solidity 実装にフォールバックするハイブリッドで、Safe や ZeroDev も同じ形に収束している。Solidity 実装は約 30〜40 万 gas なので、約 2 桁の差がある。
本稿が挙げた四つの欠落のうち、P-256 だけは性質が異なる。他の三つ（状態設計・コラテラル・接続規格）は Cardano 側の設計と標準化で解けるが、これは台帳が持つ機能そのものの差にあたる。
同時に、これは第 V 部の主張を補強する。Ethereum はメインネットで、L2 は 2024 年から、Solana も前例がある。「狭い暗号プリミティブの追加であり、前例が揃っている」という論拠は、当初の想定よりはるかに強い。
「誰も考えていない」わけではない。むしろ議論され、合意に至らずに閉じられている。
「Arbitrary Script as Native Script spending conditions」。ネイティブスクリプトに RequireScript という条件を足し、同じトランザクション内に指定の Plutus スクリプトがあるときだけ使えるようにする案。当時「Cardano に Account Abstraction を」と報じられた。狙いは、利用者が datum の構造を知らなくてもスクリプトウォレットに送金できるようにすること。
確ここは本稿の初期の版が誤って書いていた部分である。二重充足（double satisfaction）の懸念や「ネイティブスクリプトを拡張するより Plutus 自体を一般化すべき」という反論は実際に出たが、クローズの理由は「後継提案に取って代わられた（superseded）」だった。
確任意の検証ロジックを台帳アクションから切り離す新しい script purpose を追加し、同じ合成可能性の問題を Plutus ネイティブに解決した。つまり話は止まっていたのではなく、より良い形で前に進んでいた。
スクリプトアドレスを持つウォレットと dApp をつなぐ CIP-30 拡張。更新可能マルチシグ、多要素認証、相続、セミカストディアルなど、まさにスマートウォレットの用途が並んでいる。以後 Proposed のまま。
Charles Hoskinson が、24 語のリカバリーフレーズを明かさずに所有を証明し、スマートコントラクトのプールから資産を解放する復旧方式を実験中と表明。これは「シードフレーズを失っても復旧できる」ものではなく、「シードフレーズを見せずに証明できる」ものである点に注意。根が 24 語である以上、後述する身元ベースの復旧の代わりにはならない。
ERC-4337 と公的個人認証による復旧を実装した一般向けアプリが、EVM 6 チェーン対応で出荷された。Cardano は含まれていない。
比較対象が実在の製品になったので、公開情報から読み取れる範囲で構成を確認する。
これを分けないと、公開情報を読み違える。本稿も初期の版で混同していた。
| ① 研究プロトタイプ | ② 出荷製品 | |
|---|---|---|
| 時期 | 2023〜2024 | 2026-07 提供開始 |
| 主体 | a42x 株式会社 | マイナウォレット株式会社（2024-12-19 に商号変更） |
| 署名者 | マイナンバーカードの RSA 鍵（owner = RSA modulus） | パスキー |
| 検証 | オンチェーン RSA（PKCS#1 SHA-256）。後に ZKP 化を研究 | 非公開 |
| ソース | GitHub 公開（GPL-3.0） | 非公開 |
| デプロイ | Polygon Mumbai / Sepolia のテストネットのみ | Ethereum ほか 6 チェーン（アドレス非公開） |
確①の GitHub organization は全リポジトリが 2024 年 5 月以前で更新停止している（monorepo の最終 push は 2024-04-01）。①のコントラクトは ERC-4337 準拠（EntryPoint v0.6 系）、UUPSUpgradeable を継承するがアップグレード権限は onlySelf で運営会社のバックドアはなく、復旧機能は実装されていない（コードに // TODO add time lock? が残る）。
したがって、①のソースコードを根拠に②の性質を論じることはできない。以下、②について公開情報から言えることと、言えないことを分けて記す。
確2026年7月21日、マイナウォレット株式会社が一般提供を開始（アプリの初回リリースは 7月16日）。「KYC 済みノンカストディアルウォレット」と説明され、Account Abstraction 技術と公的個人認証サービスを活用することで、デバイスや秘密鍵の紛失時でもアカウントの復旧が可能とされている。
確Ethereum Foundation の ERC-4337 Account Abstraction Grant Round への採択は事実で、EF 側の受領者リストに「MynaWallet — Wallet integrating Japanese national ID (Myna Card)」と明記されている（2023 年、18 チーム採択のうちの 1 つ）。助成金額は非公開。確2025 年 6 月にシードラウンドで 2 億円を調達（gmjp holdings、Coincheck Group N.V.）。
確同社は 2025 年 10 月 24 日付で、公的個人認証法第 17 条第 1 項第 6 号の主務大臣認定を取得している（デジタル庁お知らせ、2025-10-29）。デジタル庁の「プラットフォーム事業者一覧」（2026-06-30 時点、28 社）と総務省の民間利用一覧（令和 8 年 6 月 1 日現在、大臣認定 27 社）の双方に掲載がある。
用語について正確に書いておくと、「認定プラットフォーム事業者」は法令上の名称ではない。正式には「主務大臣（内閣総理大臣及び総務大臣）の認定を受けた署名検証者」であり、「プラットフォーム事業者」はガイドラインが「いわゆる」を付して使う通称にあたる。
興味深いことに、同社は総務省の一覧に二重に掲載されている。認定事業者（PF）としての掲載と、ポケットサイン社配下の SP 事業者としての掲載（用途欄「マイナウォレットアプリにおける本人確認」）である。自社認定を取る前は他社基盤を経由していたことが読み取れる。
ここは記述が割れている。確プレスリリースは「ガス代準備不要」「基本的な利用にかかるガス代をスポンサーしており」とする一方、利用規約第 6 条第 4 項は「ユーザーは、当社が別途定める場合を除き、…ガス代…を自己の費用と責任において負担する」と定めている。
確そして実際に有料の仕組みが存在する。特定商取引法表記に「チャージ残高」があり、保有上限 1,000 円、App Store の課金は ¥50〜¥130、払戻し・換金・第三者譲渡は一切不可。取引確認画面に「本件システム等利用料」を表示し、送信時にこの残高から支払う設計になっている。
つまり「ガス代無料」は無条件ではなく、条件を超えると利用者が支払う。条件（チェーン・上限・回数）の具体値は未公開されていない。なお「Paymaster」という語は②の公開資料に一度も現れない（①のプロトタイプには MynaWalletPaymaster.sol が存在した）。
評価にあたって最も重要な部分が、揃って非公開である。憶測で埋めず、そのまま列挙する。
確利用規約第 7 条 1 項(2) は「ユーザーのみが自己のユーザーアカウントにアクセスでき、当社その他の第三者は当該ユーザーアカウント等に一切アクセスできない」と定める。一方で公式サイトは「パスキーを失くしても JPKI で復旧できる」と述べる。
両立させる実装は複数あり得るため矛盾とは言えないが、どれを採用しているかは公開されていない。これは事実の指摘であって、疑義の提示ではない。
確なお同社は、金融庁の暗号資産交換業者・資金移動業者・電子決済手段等取引業者のいずれの登録一覧にも掲載がない（2026 年 6 月末時点の各登録簿を直接検索）。政府提出資料では一貫して「Self Custodial Wallet」と自己記述している。この位置づけの法的な意味は第 VIII 部で扱う。
確もう一つ設計上目を引く条項がある。規約第 4 条 5 項は、利用者証明用・署名用電子証明書に含まれる公開鍵の一部をブロックチェーンや分散台帳の上に公開することを禁じている。これは第 VIII 部で述べる制度上の制約と対応している。
カード自体が資産を直接動かす署名鍵になっているとは限らない。公開情報から見る限り、役割はこう分かれていると考えられる。
スマートフォンのパスキー
↓
日常的な送金・操作
マイナンバーカード ＋ JPKI
↓
本人性の確認
↓
紛失時の復旧プロセス
↓
新しいパスキーを操作権限として登録つまりカードは毎回金庫を開ける鍵ではなく、鍵をなくしたときに本人であることを証明して錠前を交換するための公的な本人確認手段に近い。第 I 部の guardian の位置づけと同じである。
端末・鍵をなくした → カードをタッチして復旧（自宅で完結） カードもなくした → 役所でカード再発行（従来の窓口手続き） → 新しいカードでウォレット復旧
注目すべきは、新しい復旧制度を作る必要がないことである。カード再発行という既存の窓口業務が、そのまま最終的な復旧経路になる。
| 知識ベース | 身元ベース | |
|---|---|---|
| 根拠 | シードフレーズを知っていること | 現実世界の本人性 |
| 例 | 24 語、ZK による所有証明 | JPKI、guardian、窓口での本人確認 |
| 全部失ったら | 復旧できない | やり直せる |
| 必要な構造 | HD ウォレットで足りる | 鍵を交換できる論理口座が必要 |
ZK による復旧は、24 語を他人に見せずに証明するもので、依然として左の列にある。マイナウォレットが選んだのは右の列であり、この二つは代替関係にない。そして右の列は、アドレスを保ったまま操作鍵を差し替えられる構造がなければ実装できない。だからスマートウォレットが要る。
判断基準は「利用者が秘密鍵を直接見ているか」ではなく、サービス提供者が利用者の意思なしに資産を動かせるかである。
通常送金
└ 本人のパスキーのみ
復旧
└ 本人確認 ＋ 別要素
＋ 待機時間
運営会社
├ 単独では送金不可
└ 単独では所有者変更不可
運営会社 ├ 管理鍵で所有者を変更可能 ├ 任意に資産を移動可能 ├ 口座を凍結可能 └ 復旧を単独承認可能
同じ「AA を使ったウォレット」でも、この両極のあいだのどこにでも実装できる。Account Abstraction だから安全なのではなく、どのような復旧条件を実装したかで安全性が決まる。
マイナンバーカードだけで復旧が成立するのか、新端末のパスキーも必要か、待機時間はあるか、旧端末に通知され拒否できるか、運営会社が単独で所有者を変更できるか、コントラクトはアップグレード可能か、その権限は誰が持つか。2026年7月21日時点の公開情報だけでは、これらは確認できない。客観的な評価には、コントラクトアドレス、ソースコード、監査報告、復旧条件、管理者権限、サービス終了時の移行方法の公開が要る。
JPKI の署名検証そのものは、EVM 上でオンチェーンに行うのは現実的ではない。したがってオフチェーンで本人確認を行い、その結果をオンチェーンに伝える主体が必要になる。この点について、マイナウォレット社は公的個人認証の認定プラットフォーム事業者であり、自社で本人確認を完結できるとされる。外部の検証事業者を挟む構成ではない。
これは利用者にとって経路が短くなる一方、設計上は論点を一つに絞り込む。検証主体が運営会社自身であるということは、復旧における実質的な guardian が運営会社だということである。したがって問うべきは「誰が本人確認するのか」ではなく、次の一点になる。
運営会社の承認「だけ」で操作鍵を差し替えられるか？
Yes → 実質的に運営会社が口座を掌握できる
（資産を直接動かせなくても、
鍵を自分のものに替えれば同じこと）
No → 承認に加えて次が要る設計になっているか
├─ 新端末のパスキー登録
├─ 待機期間
└─ 旧端末からの取消資産を直接動かす権限を持たないことと、所有者を変更できないことは別の話である。第 VI 部の復旧ステートマシンで待機期間と異議申立てを必須にしているのは、まさにこの差を埋めるためにあたる。なお第 VII 部で述べるとおり、この構図は ZK による資格提示で相当程度まで緩和できる。
身元ベースの復旧を採ると、身元を示す物体が新しい攻撃対象になる。ただし単純な話ではない。
まず、カード単体では復旧できない。JPKI による署名には暗証番号が必要で、数回の誤入力でロックされ、解除は窓口に限られる。総当たりは成立しない。加えて、紛失・盗難に気づいた時点で電子証明書を一時停止できる窓口が 24 時間開いている。したがって「盗まれた＝即時に資産喪失」ではない。
問題は二つ、別のところにある。
ふつうの盗難
カードを盗む → 使うには被害者の端末が要る
復旧を使った乗っ取り
カードを盗む → 自分の端末に復旧する
→ 被害者の端末は無関係になるここで効いてくるのが時間である。カード盗難の場合、被害者はまだ端末とパスキーを保持している。したがって復旧に待機期間があり、旧端末へ通知が届く設計であれば、本人が異議を申し立てて止められる。逆に認証が通った時点で即座に完了する設計なら、気づいた時には終わっている。
公開情報からは、マイナウォレットの復旧に待機期間や旧端末への通知があるかを読み取れなかった。ないと断定はできない。ただし評価にあたって最初に確認すべき質問はこれになる ―― JPKI 認証が通った時点で、復旧はその場で完了するのか。
第 VI 部で復旧をステートマシンとして設計し、待機期間と異議申立てを必須にしているのは、装飾ではなくこの攻撃を止めるためにあたる。そして本稿の主張は、ここで一行増える。「なくしても戻せる」「誰にも見られない」に加えて、「勝手に戻されない」。
公開直後の反応には、冷ややかなものも少なくない。理由は素朴で、しかし正当である。公的 ID とウォレットが結びつくなら、残高も履歴も国に見えるのではないか。
この懸念は、素朴な形で身元連携を実装した場合には技術的に正しい。公開台帳の上で、認定事業者が本人確認の結果をアカウントに紐づける構成なら、少なくともその事業者は「誰の、どのアドレスか」を知る。そしてアドレスさえ分かれば、残高も送金履歴も誰でも追える。ブロックチェーンはそういうものだからである。
しかも、想定されている用途がこれを重くする。円建てステーブルコインでの日常的な支払いを考えるなら、対象は投資ではなく生活費の履歴にあたる。どこで何を買ったかが紐づく。「投資家が使う道具」なら我慢できたことが、「生活の口座」では我慢できない。
日常決済の受け皿としては、JPYC のような円建てステーブルコインが想定される。少額の範囲であれば柔軟に扱えるとされるが、送金上限などの制度的な条件は本稿では未確認であり、一次情報の確認が必要である。
この冷ややかさは、弱点の指摘であると同時に差別化の余地の指摘でもある。復旧できることとプライバシーは両立しうるのに、いまの実装はまだそこを取っていない。
第 VII 部で述べるとおり、ZK による資格提示を使えば、認定事業者は「本人確認をした」ことしか知らず、どのアドレスかを知らない構成にできる。復旧の能力は与えるが、監視の能力は与えない。ここが Cardano 側が取りにいける唯一の明確な差にあたる。
ゼロからではない。個別の仕様は存在する。統合されていないだけである。
Cardano Improvement Proposal の略で、「みんなでこうしましょう」という取り決めの文書にあたる。法律ではないので強制力はない。みんなが従えば標準になる、というだけのものである。USB の規格に近い。誰でも書けて、GitHub に提出する。
そして CIP には性質の異なる二種類がある。ここを混ぜると、難易度の見積もりを間違える。
ハードフォークが要る
全ノードの合意が要る
通すのが大変
例）CIP-109
RSA 検証の追加
（7/18 に有効化）
プロトコルは変わらない
「同じやり方をすれば
繋がる」というだけ
例）CIP-30、CIP-141
ウォレットと dApp の
つなぎ方
後述する CIP-141 は後者にあたる。したがって止まっている理由は技術的な難しさではなく、単に誰も採用していないことにある。
Cardano のサイトで「ウォレットを接続」を押すと Eternl や Lace が出てくる。あれを可能にしているのが CIP-30 である（こちらは Active＝実際に使われている）。サイトとウォレットの会話のルールを決めている。
サイト「残高を教えて」 → getBalance() サイト「アドレスを教えて」 → getUsedAddresses() サイト「これに署名して」 → signTx() ← ここが前提を作っている
signTx() は「この取引に、あなたの秘密鍵で署名してください」という意味である。つまり CIP-30 はウォレット＝鍵を持っている人だと決めつけて作られている。
ところが本稿が扱ってきたウォレットには、「その署名」というものが存在しない。資産はスクリプトアドレスにあり、動かすには validator の条件を満たす取引を組み立てる必要がある。サイト側が、そのウォレットの validator のルール・datum の形・redeemer の種類を知っていないと、取引が作れない。ウォレットごとに全部違えば、サイトは対応しようがない。
これが「共通規格が要る」の具体的な中身にあたる。関連する CIP-106（マルチシグ用）が signTx() と signData() を明示的に無効化しているのは、「署名を返す」というモデル自体が合わないと、規格の側でも認めているということである。
ウォレット自体は作れる。しかし、どの dApp とも繋がらない。作ったものが孤島になる。「技術的にはできるのに普及しない」の正体は、かなりの部分がこれである。
複数当事者の署名を要するウォレットの鍵派生を定義する。purpose=1854' で通常ウォレット（CIP-1852）と区別し、支払い・委任のスクリプトテンプレート、部分署名トランザクションの検証と署名手順を規定する。四つのうち唯一 Active。ただし対象は鍵の派生と管理であり、スマートウォレット全体を定義するものではない。
dApp とマルチシグウォレットの通信を定義する CIP-30 拡張。スクリプト記述子の提供、長時間に及ぶ署名のための非同期 API（submitUnsignedTx() / getCompletedTx()）、Plutus V2 以降向けのコラテラル管理を加える。前述のとおり signTx() / signData() は無効化される。
前節の穴を埋めるための提案。保有アドレスが公開鍵ではなく Plutus スクリプトに対応するウォレットのための CIP-30 拡張である。2023 年 10 月に Leo という人物が提出した。
想定用途として並んでいるのが、本稿がこの数日で辿り着いたものと、ほぼ同じである。
・更新可能なマルチシグウォレット ・定期支払いウォレット ・多要素認証ウォレット ・セミカストディアルウォレット ・トークン化されたウォレット ・相続管理ウォレット ・Cardano 以外のアドレスで制御されるウォレット
つまり発想自体は 3 年前に文書化されていた。そして今も Proposed のまま動いていない。実装者として名前が挙がっているのは BroClan / KeyPact の一つだけである。
マルチシグウォレットをオンチェーンに登録し、関係者やウォレットソフトから発見できるようにする。メタデータラベル 1854 にネイティブスクリプトとウォレット情報を格納し、CIP-1854 の派生パスから検証鍵を導いて該当する登録を検索する。参加者情報やオフチェーン JSON 共有、CIP-83 による暗号化にも対応。
ここを混ぜると、状況を読み違える。三つはネイティブスクリプトの世界の話で、Plutus の話は一つだけである。
| CIP | 何の話か | 層 | 状態 | 実装者 |
|---|---|---|---|---|
| 1854 | マルチシグ用の鍵の作り方 | ネイティブ | Active | 各ウォレット |
| 146 | 作ったマルチシグを見つける方法 | ネイティブ | Proposed | Eternl |
| 106 | dApp と繋ぐ（マルチシグ用） | ネイティブ | Proposed | BroClan |
| 141 | dApp と繋ぐ（Plutus 用） | Plutus | Proposed | BroClan |
Eternl は実在する主要なウォレットだが、スマートコントラクトウォレットではない。マルチシグ機能はネイティブスクリプトで作られている。したがって CIP-146 の実装者であることは、本稿が論じている種類のウォレットへの対応を意味しない。未なお Eternl が CIP-146 を実際に出荷済みか、実装者として記載があるだけかは確認していない。
ここから分かるのは、「誰も何もしていない」わけではないということである。ネイティブスクリプトのマルチシグには、実際に動いている製品と、それを支える標準化の動きと、利用者がいる。止まっているのは、そこから一段上がった Plutus ウォレットの層だけにあたる。土台はある。
並べてみると、Cardano にはマルチシグ鍵の標準・dApp 接続インターフェース・Plutus ウォレットの構想・ウォレットの登録と発見が個別に存在する。しかし、パスキー、社会的復旧、鍵交換、手数料スポンサー、ステーキング、ガバナンス、dApp 接続を一人の利用者の一つの口座として統合した標準にはなっていない。ERC-4337 が持っている「一つの合意点」がない。
本稿は当初「Cardano に復旧可能なスマートウォレットはまだ存在しない」と書いた。これは誤りだった。存在する。ただし大半が testnet 段階で、一般提供されている完成品ではない。
確資金を Cardano のスクリプトにロックし、Google OAuth の JWT を持っていることの証明で解錠する。Aiken／Plutus V3。シードフレーズ不要で、Google アカウントが復旧要素になる。SDK には 2-of-3 のキーシェア分割も実装されている。Catalyst Fund 12 で 50 万 ADA・全 6 マイルストーン完了。testnet ローンチは 2025 年 4 月、v2 コントラクトの公開は 2026 年 7 月 20 日。未メインネット提供は未確認（v2 の README に「残作業はデプロイ設定と end-to-end の testnet 検証」とある）。
確Aiken バリデータ＋ZK 回路。Google ログインで解錠しつつ、ZK により Google ID とアドレスの紐付けを秘匿する。preprod／preview で実際に成立したトランザクションが公開されている。既知の限界も README に明記：Google の鍵ローテーションに対応するオラクルがなく手動移行が要る、スクリプトアドレスは自前でコラテラルを出せないためスポンサーウォレットが必須。
確署名者の動的な追加・削除と閾値の変更が可能＝実質的な鍵ローテーション。Multisig NFT でリプレイを防ぎ、支出上限機能も持つ。Catalyst Fund 11 資金提供。最終更新 2025-05 でやや停滞。
Aiken／Plutus V3。30 日〜5 年のあいだ送金がなければ受益者が資産を請求できる。作者が 2025 年 11 月に「Production-ready、Cardano Mainnet で稼働中」と投稿（サービス料 100 ADA）。未第三者検証・監査は確認できていない。
確両 CIP の Implementors 欄に記載された唯一の実装者。現状の主軸はネイティブスクリプトのマルチシグで、未Plutus ウォレット部分がどこまで出荷済みかは確認できなかった。
MPC / 秘密分散 /
ソーシャルログインで
秘密鍵そのものを分散保管
オンチェーンから見れば
ふつうの鍵アドレス
例: NuFi（mainnet 提供中）
VESPR Keyless
資金がスクリプトアドレスに
ロックされ、validator が
支出条件を判定する
鍵の交換・guardian 復旧が
原理的に可能
例: zkFold, zklogin-aiken,
Anastasia Labs
本稿が論じてきたのは B である。A は「秘密を紙から分散保管に移した」ものであり、アドレスと鍵が一体である構造は変わっていない。
技術要素は 2026 年 7 月時点で揃っている。欠けているのは (a) 標準化（CIP-141 は Proposed 止まり、該当する CPS が存在しない）、(b) 資金（Catalyst の関連提案は軒並み不承認。F12「Account Abstraction: Replacing Seed Phrases」120k ADA、F13、F14「VESPR Keyless」250k ADA がいずれも落選し、通ったのは zkFold の 50 万 ADA のみ）、(c) コラテラル／リレイヤー問題、(d) メインネットでの一般提供実績の四点にあたる。
したがって正確な言い方は「存在しない」ではなく、「動く実装は複数あるが、標準化と資金供給が追いついていない」になる。
第 II 部の四つの欠落が技術的な穴だとすれば、こちらは設計上の負担にあたる。
Ethereum ならコントラクトのストレージに owner、guardian、limit、recoveryDelay と書けば済む。Cardano では状態は UTxO であり、旧状態を消費して新状態を作る遷移として表す。明示的で決定論的という利点の裏で、ウォレット側は現在の状態 UTxO の発見、資産 UTxO の選択、datum と redeemer の構築、新状態の正しい生成まで面倒を見ることになる。
validator は UTxO が使われようとしたときに可否を判定するだけで、「48 時間経ったので自動的に鍵を変更する」という取引を自ら発生させることはない。誰かが組み立てて提出する必要がある。
ただし致命的ではない。ウォレットアプリ、リレーヤー、復旧サービスが取引を構築・提出し、validator がオンチェーンで正当性を判定すればよい。むしろ判定と実行が分離しているのは監査上の利点でもある。
ERC-4337 には Paymaster がある。Cardano でも第三者が手数料 UTxO やコラテラルを提供する取引は設計できるが、誰が取引を作るか、どの UTxO を出すか、署名順序、コラテラルの扱い、悪用防止、dApp との共通インターフェースが標準化されていない。
Cardano のウォレットは単なる支払い口座ではない。アドレスは支払い資格情報とステーク資格情報を持ち、委任、報酬引き出し、DRep 委任、投票が関わる。したがって Cardano 版スマートアカウントは、支払い鍵の復旧だけでなくステーク権限とガバナンス権限の復旧まで設計に含める必要がある。Ethereum の AA には対応する論点がない。
「提案はあったがまとまらなかった」という経緯を、競合との関係でどう読むか。
マイナウォレットが EVM を選んだのは、Ethereum が優れていたからというより、統合コストが最も低かったからと見るのが自然である。したがって「ERC-4337 のアカウント数に追いつく」ことにはほとんど意味がない。
本当に固着するのは別のところにある。公的 ID との連携である。自治体の地域通貨や給付金は、法務レビューと調達を通る。一度 EVM ベースで導入されれば 5 年 10 年は動かない。認定事業者の側も、一度作った本人確認からウォレットへの接続仕様を作り直したがらない。
暗号業界のニュースサイクル ← ここではない 数週間〜数ヶ月 行政・自治体の調達サイクル ← こちら 数年、導入後は 5〜10 年動かない
この意味で「急ぐ理由」は実在する。ただし急ぐ対象は、機能のパリティではなく統合先として選ばれる状態を先に作ることにあたる。
第 III 部で見た「全部、国に把握されるのか」という反応は、そのまま入り込む余地を示している。復旧できることとプライバシーは、原理的には両立する。いまの実装がまだそこを取っていないだけである。
したがって狙うべきは「ERC-4337 と同じことが Cardano でもできます」ではない。「復旧できて、しかも誰にも見られない」——この一点だけが、後発が先発を追い抜ける位置にあたる。速さでも手数料でも機能の数でもない。
あの提案が合意に至らなかった理由は具体的である。ネイティブスクリプトに RequireScript を足すという台帳変更を求めた。台帳変更は広い合意を要し、二重充足のようなセキュリティ上の反論を必ず呼ぶ。そして CIP-38 には、その反論と天秤にかける実物がなかった。仕様書だけが議論の場に置かれていた。
対して ERC-4337 の歴史は逆である。
アカウント抽象化の構想自体はこの時点で提示されている。
Safe や Argent が、スマートコントラクトウォレットを標準なしで出荷。社会的復旧も先に実装された。
最初の提案から約 7 年。動いている実践を後から成文化したものであり、白紙から作られた規格ではない。
規格を先に出さない。動くものを先に出して、それを規格化する。
本稿のフェーズ 1 を「台帳変更なしで作れる範囲」に限定したのはこのためである。いま提案文書をもう一本書いて CIP に投げるのは、2022 年の再演になりかねない。
実装の積み上げで回避できない要求が一つある。NIST P 曲線（P-256 と P-384）の検証機能である。ただしこれは CIP-38 と性質が異なる。
つまり反対しにくい。台帳変更はリードタイムが最も長いので、実装の完成を待たず並行して着手する価値がある。政治的な資本を使うなら、まずここ一点に絞るのが妥当だろう。
ERC-4337 との機能パリティを追うこと。EntryPoint も Bundler も Cardano には要らない部品である。「Cardano 版 Paymaster」を仕様から作りにいくと、また抽象度の高い議論に戻る。手数料スポンサーは、実装の中で必要になった形が固まってから標準化すればよい。
なお、以上は公開された標準化プロセスの経緯から読める範囲の判断であり、Intersect の優先順位、CIP エディタの関心、誰が資金を出しうるかといった内部の力学は含んでいない。「実装を先に出せ」と言っても、それを誰がやるのかが最大の問題として残る。
問題提起で終わらせず、現在の Cardano で実装可能な範囲から積み上げる。
「Account Abstraction」という Ethereum 固有の語をそのまま使ってもよいが、Cardano はアカウントモデルではないため、対外的には Recoverable Wallet ／ Programmable Wallet ／ Smart Wallet ／ Plutus Wallet のほうが誤解が少ない。既存の CIP-141 が「Plutus wallets」を名乗っている以上、その語彙に寄せるのが実際的だろう。
口座設定を表す状態 UTxO を定義する。一意性は NFT（ウォレット識別トークン）で保証し、「どれが正規の状態 UTxO か」を判別できるようにする。
状態 UTxO を毎回消費する設計にすると、第 II 部で述べた単一書き込み点の問題に直行する。通常送金では参照入力（CIP-31）として読むだけにし、消費するのは鍵の更新・復旧・ポリシー変更のときに限る。この分離が実用性を左右する。
資産 UTxO は同じウォレットの validator で保護し、取引ごとに次を確認する。正しい状態 UTxO を参照しているか、通常操作の認証を満たすか、復旧中でないか、送金上限以内か、高額送金に追加承認があるか、許可された送金先か、状態更新が正しいか。
通常状態 ↓ 復旧申請（新しい操作鍵を提示） 待機状態 ↓ 異議申立期間（24h / 48h / 7d） │ ├─ 旧端末・予備鍵が「不正だ」と取消 → 通常状態へ戻る │ ↓ 期間満了 復旧確定（primaryCredential を更新）
この段階化により、本人確認事業者の認証が漏えい・誤用された場合でも、即座に全資産を奪われることを防げる。単一の guardian が単独で口座を掌握できない構造は、ここで担保される。
公的 ID と組み合わせる場合、guardian に求められるのは資産を預かる能力ではなく、本人確認をやり直す能力である。窓口と戸籍を持つ主体はその意味で適任にあたる。カード紛失時の再発行と、鍵紛失時の復旧は構造が同じだからである。
ただし guardian にできるのは鍵の入れ替えに参加することだけで、資産を動かす権限は持たせない。そして単独の guardian（1 of 1）にした時点で、それは social recovery ではなく預託になる。しきい値の中の一票として置いて初めて意味を持つ。
guardian 3 のうち 2 ＋ 48 時間の待機 ├─ 公的機関 ： 本人確認の担い手 ├─ 家族・信頼できる第三者 └─ 自分の別端末・予備鍵 → 公的機関の署名は必要だが、それだけでは足りない → 待機中は旧端末から取消できる
逆に、公的機関でなければ扱えない場面もある。相続（死亡の事実を確認できるのは戸籍を持つ側だけ）、成年後見、法的手続きに基づく差押え。これらは「秘密鍵を持つ者が本人」という従来型ウォレットでは原理的に表現できず、プログラマブルウォレットにして初めて条件として書ける領域になる。裏を返せば、公的機関を guardian に入れることは凍結・検閲の経路を自ら設けることでもあり、利便性とのトレードオフとして意識的に選ぶ話になる。
確電子証明書は二種類あり、性質が非対称である。転居・氏名変更で失効するのは署名用のみで、利用者証明用は失効しない。また 15 歳未満・成年被後見人への発行制限も署名用だけで、利用者証明用に制限はない。署名用は基本 4 情報（氏名・住所・生年月日・性別）を含むが、利用者証明用は含まない。
したがって復旧のアンカーを利用者証明用に置けば、引っ越しで経路が切れる問題も、年齢・後見による除外も、同時に解消する。プライバシー上も有利になる。本稿の初期の版はここを取り違えていた。
暗証番号は署名用が英数字 6〜16 文字（5 回でロック）、利用者証明用が数字 4 桁（3 回でロック）。ロック解除は原則として窓口。紛失時の一時停止は 24 時間 365 日受け付けている（スマホ搭載分も対象）。
JPKI は「この人物が以前登録された本人と同一である」ことの確認に使い、事業者が資産を保有したり直接送金したりする設計にはしない。個人情報はオンチェーンに載せない。代わりに、認証事業者の署名、一時的な認証トークン、ゼロ知識証明、個人情報を含まない復旧承認証明のいずれかを validator が検証する形にする。マイナウォレット社も、第三者へ公開する情報を最小化するため ZK を活用したプライバシー保護機能を研究していると説明している。
パスキーは端末内の鍵管理・アクセス制御に用い、最終的な Cardano 署名は端末内の Ed25519 鍵で行う。P-256 が検証できない現状で唯一すぐ実装できる形。利用者から見た体験は生体認証で完結する。
Plutus が WebAuthn・パスキー由来の署名、またはその証明を直接検証できるようにする。P-256 ビルトインの追加、または ZK による証明が前提になる。
複数端末、ハードウェアキー、公的本人確認、社会的復旧を一つのポリシーとして扱う。
一般利用者向けには「ADA を持っていないので送金できない」も解く必要がある。
スポンサーは「1 日 N 回まで」「地域通貨の送金のみ」「特定トークンのみ」「一定額以下」「KYC 済み利用者のみ」といった条件を付けられる。重要なのは、スポンサーが資産の操作権限を持つのではなく、手数料部分だけを提供する設計にすることである。
すべてを同じ鍵にする必要はない。むしろ分離することで、「一つのシードフレーズがすべてを支配する」構造より安全にできる。
少額送金 └ スマホのパスキー 高額送金 └ スマホ ＋ ハードウェアキー ステークプール変更 └ スマホのパスキー DRep 変更 └ スマホ ＋ 追加確認 復旧 └ 公的本人確認 ＋ 予備鍵 ＋ 待機時間
台帳変更なしで、いまの Plutus と UTxO モデルだけで構築する。スクリプト管理ウォレット、主鍵＋予備鍵、2-of-3 の社会的復旧、時間制限付き鍵交換、状態 UTxO、スマートフォンアプリ、CIP-141 ベースの dApp 接続、通常の Cardano 署名方式（P-256 が使えないため）、手数料スポンサーの試験実装。この段階で「シードフレーズを失っても予備鍵や guardian で復旧できる Cardano ウォレット」を実証できる。
生体認証、複数端末、セキュリティキー、復旧通知、待機期間、送金上限、送金先制限。第 VII 部のとおり、CIP-381 を使えば P-256 ビルトインを待たずにここへ進める可能性がある（要実測）。
認証事業者との接続、個人情報を載せない認証証明、不正復旧対策、自治体地域通貨、給付金、KYC 済みウォレット。
新 CIP の作成と、CIP-141・106・146 との統合。複数ウォレット・複数 dApp での実装、SDK、リファレンス validator、セキュリティ監査、バグ報奨金。
MVP を実装してボトルネックが明確になった場合に限り、署名方式（P-256 ビルトイン）、スポンサー取引、スクリプト効率、状態管理、ウォレット発見などのプロトコル改善を提案する。最初から「Cardano の台帳モデルでは無理」と結論づける必要はない。
確2026 年 7 月 20 日、Wanchain の Cardano ブリッジから 5 億 1,520 万 NIGHT（報道により 900 万〜1,300 万ドル）が約 8 分で流出した。Midnight 本体とは無関係の第三者ブリッジだが、原因となったバグは、本稿の設計にそのまま当てはまる種類のものである。順を追って説明する。
guardian が復旧を承認するとき、実際に署名するのは日本語の文ではない。複数の項目を並べて作った一本のバイト列である。たとえばこう作ったとする。
ウォレットID = "W7"
新しい鍵 = "K42"
連番 = "3"
↓ そのまま繋ぐ
"W7K423" ← これに署名するところが、同じ "W7K423" になる別の読み方が存在する。
ウォレットID = "W7K"
新しい鍵 = "42"
連番 = "3"
↓ そのまま繋ぐ
"W7K423" ← まったく同じguardian は前者を承認したつもりで署名した。しかし攻撃者は同じ署名を、後者の承認として使える。署名は正しく検証を通る。バイト列が同一だからである。これを非単射なエンコーディングという。項目の組み合わせとバイト列が一対一に対応していない状態を指す。
確問題の TreasuryCheck validator は、14 個の可変長フィールドを、区切り文字も長さの表示もなしに生のまま連結していた。攻撃者は、正規に発行された署名が別の切り分け方で読めることを見つけた。結果、約 3,110 NIGHT に対する署名が、2 億 300 万 NIGHT の承認として通った。増幅率およそ 65,000 倍である。
複数の項目を繋いで
メッセージを作り、
それに対する署名を
validator が検証する
← 復旧承認は
まさにこの形
Wanchain は共同金庫
全員の資産が一箇所
本稿の設計は
利用者ごとに別の
ウォレット
← 被害は一人分を
超えない
つまり同じバグが刺さる構造だが、爆発範囲は桁違いに小さい。「同じ種類のコード」と一括りにするのは正確ではない。ただし刺さること自体は間違いないので、対策は最初から設計に入れる必要がある。
2|W7|3|K42|1|3 のようにすれば、読み方は一通りに定まる。nonce を置いたのはこのためである。この四つは、標準に書き込むべき最初の項目にあたる。validator を小さく単純に保つという原則は、こういう事故を避けるためにある。
対策復旧事業者単独では変更不可とし、複数要素を必須化する。オンチェーンの待機期間、旧端末からの取消、guardian の利用者選択、復旧事業者の交換可能性。
確本稿の執筆中、2026 年 7 月 20 日に実例が起きた。Wanchain の Cardano–BNB ブリッジから 5 億 1,520 万 NIGHT（報道により 900 万〜1,300 万ドル）が約 8 分間で流出している。原因は Plutus V2 の TreasuryCheck validator にあり、14 個の可変長 redeemer フィールドを区切り文字も長さプレフィックスも無しで生連結していたため、署名を再利用できた（約 3,110 NIGHT 分の署名が 2 億 300 万 NIGHT に転用。増幅率およそ 65,000 倍）。Midnight 本体とは無関係の第三者ブリッジだが、我々が書こうとしているのと同じ種類のコードである。
対策小さく単純な validator。redeemer と datum のエンコーディングを単射（non-injective にしない）に設計すること――上記の事故はここ一点である。形式手法とプロパティテスト、複数監査、オープンソース、段階的な利用上限、バグ報奨金、安全な移行機能。
対策アップグレード不可の固定版を用意する。移行は利用者の明示承認があるときのみ。タイムロック、マルチシグ管理、オンチェーン告知、旧バージョンから資産を直接回収できる出口。
対策プリセットを用意する。個人・簡単（本人のスマホ＋予備端末）／個人・安全（スマホ＋ハードウェアキー＋家族）／行政サービス向け（パスキー＋公的本人確認＋待機時間）／法人（担当者 3 名中 2 名＋監査担当）。
対策状態 UTxO の形式を公開し、他ウォレットへの移行を標準化する。復旧プロバイダーの交換、複数実装、オープン SDK、サービス終了時の退避取引。
ここから先は設計の探索であり、実装も検証もされていない。ただし前提となる部品は、調べた限りすでに揃っている。
これは本稿の他の部分を書き換えるだけの事実にあたる。
17 の組込関数と 3 つの型を追加し、G1／G2 上の演算、ペアリング、曲線へのハッシュを提供する。Chang ハードフォークに含まれて有効化済み。Groth16 証明の検証は実行予算の約 23%で収まることがベンチマークで確認されている。
残るボトルネック。現状の Plutus では MSM が非効率で、G1 点 10 個の MSM で計算予算の 7.74%、129 点以上はトランザクションに収まらない。Groth16 検証は公開入力に対する MSM を含むため、公開入力を小さく保つ設計が必須になる。
つまり「ZK は将来の話」ではない。証明の検証は今日の Cardano L1 でできる。制約は「公開入力を少なくすること」であって、回路の複雑さではない。Groth16 の検証コストは回路の大きさによらずほぼ一定だからである。
第 II 部で「パスキーの署名がオンチェーンで検証できない」を最大の欠落として挙げた。しかし CIP-381 があるなら、迂回路がある。
端末（証明の生成）
├─ WebAuthn / パスキーで署名（P-256）
└─ 「有効な P-256 署名を持っている」ことを
回路の中で証明 → Groth16 証明を生成
↓
Plutus validator（証明の検証）
└─ CIP-381 のペアリングで証明を検証
※ コストは回路の複雑さによらずほぼ一定重い処理は端末側の証明生成に移る。P-256 の演算を BLS12-381 上の回路で扱うのは非ネイティブ演算になるため証明生成には時間がかかるが、それは端末の待ち時間の問題であって、チェーンの制約ではない。
言えるのは「前提となる部品は揃っている」ところまでである。P-256 回路での実測は確認できていない。証明生成に端末上で何秒かかるか、検証が実行予算に収まるか、公開入力を十分小さくできるかは、実装して測る必要がある。
したがって第 II 部の言い方を踏襲するなら、「P-256 署名を Cardano 上で直接・低コストに検証する標準的な仕組みは、まだ確立していない」が正確であり、「原理的にできない」でも「もうできる」でもない。P-256 ビルトインが入ればこの経路は不要になるので、第 V 部の「台帳への要求は P-256 一点に絞る」という結論は変わらない。変わるのは、それを待つ必要がないかもしれない、という点である。
紛失や機種変更なら、本人がまだ存在する。しかし相続では、本人はもういない。従来のやり方はすべて、相続人に「事前に何かを持たせる」ことで解こうとしてきた。そしてすべてに欠陥がある。
ZK を使うと、この前提そのものを外せる。
相続人には何も持たせない。請求の根拠を、事前に配る秘密ではなく、その人がもともと持ち歩いている「自分が誰であるか」から導く。
この設計の安全性は暗号ではなく、時間が担保している。死亡の証明が偽造された場合、本人がまだ生きているなら、本人が取り消せる。これは相続という文脈では特に強い性質にあたる。生きている本人ほど、自分の死亡を否認する動機と能力を持つ者はいないからである。
偽の相続請求
↓
待機期間（例：30 日）
↓
本人の端末に通知
↓
├─ 本人が生きている → 取消。攻撃は失敗する
└─ 本当に死亡している → 誰も取り消さない → 確定相続の待機期間は、紛失時の 48 時間より長く取ってよい。急ぐ理由がないからである。
本稿は当初、Midnight が資格の発行と選択的開示を担えると書いた。監査の結果、現時点ではその部品が存在しないことが分かった。以下は修正後の記述である。
確Midnight のメインネットは 2026 年 3 月末に稼働（公式ブログの告知は 3 月 29 日、未genesis の正確な日時は公式に明記されていない）。現在は Kūkolu フェーズ＝許可制の federated 運用で、バリデータは Google Cloud・MoneyGram・Worldpay など 9 社。公式に名指しされた本番 dApp は存在せず、公開されているサンプルはほぼ全て Preprod である。設計上の特徴は選択的開示で、一般には秘匿しつつ当局には開示できる形を前提にしている。
midnight-zk-stdlib には p256() チップと非ネイティブ体演算が実装されているが、Compact に公開されておらず、呼び出す公式経路は文書化されていない。しかも同ライブラリは未監査と明記されている。disclose() 構文のみ。OpenZeppelin の Compact ライブラリは Ownable／Pausable／FungibleToken だけで、しかも「本番で使用しないこと」と公式に警告されている。つまり「第三者が発行した資格を ZK で提示する」ための既製品は、まだない。作るなら自前になり、その前に Compact から署名検証ができないという壁がある。
確DUST は registerNightUtxosForDustGeneration による明示的な登録で生成が始まり（自動ではない）、1 NIGHT あたり最大 5 DUST、フルまで約 1 週間。裏付けの NIGHT を使うと 1 週間でゼロに減衰する。譲渡はできない。
確スポンサーシップは公式の Wallet 開発者ガイドと Wallet API リファレンスに記載がある（用語集・FAQ・索引には無いため、表面的な検索では「無い」と誤判定しやすい）。利用者が自分の資産分だけ帳尻を合わせ、スポンサーが balanceFinalizedTransaction で DUST 分を埋める二段構成。TTL は 30 分。
さらに Redesignation という第二の機構があり、自分の NIGHT が生む DUST を別の DUST アドレスに向けられる。
確そして Cardano L1 との関係で重要なのは、pallet_cnight_observation が Cardano L1 上の cNIGHT UTxO を観測して DUST 生成に変換する点である。つまり NIGHT を Cardano L1 に置いたまま Midnight の手数料資源を得られる。確ただし資産の橋は cNIGHT → mNIGHT の片方向のみで、逆方向は存在しない（公式ドキュメント内に、これと整合しない曖昧な記述があるので注意）。
本稿の設計に照らすと、役割分担はこうなる。
重要なのは、Midnight は必須ではないという点である。証明の検証は L1 でできる以上、資格の発行を担う層は認定事業者のサーバでも構わない。Midnight が効いてくるのは、その資格が誰にも紐づけられずに流通し、必要なときだけ当局に開示できるようにしたい場合である。
Midnight の手数料は DUST でのみ支払われ、DUST は NIGHT の保有量に応じて時間とともに再生する。譲渡はできないが、スポンサーが取引の手数料部分だけを埋める形の肩代わりが実装されており、利用者は NIGHT も DUST も持たずに取引できる。
ここで効くのは金額ではなく費用の性質である。ERC-4337 の Paymaster では事業者が実費を燃やし続けるのに対し、Midnight では事業者は NIGHT を保有しているだけでよく、利用量が増えても在庫が減らない。手数料を運営費ではなく資産保有として扱えることになる。自治体や事業者に導入を提案する局面では、毎年の予算計上を要求するかどうかの差として現れる。
ただしこれは Midnight 上の取引に関する話であり、資産を Cardano L1 に置く本稿の設計では、L1 側の手数料は依然として ADA で支払う必要がある。資産をどちらに置くかは、本稿ではまだ決めていない。(A) 資産は L1、資格のみ Midnight ―― L1 の手数料問題は自力で解く。(B) 日常決済を Midnight 側に置く ―― 手数料は解けるが、L1 資産との接続が課題になる。この選択は次の検討事項にあたる。
ZK 検証の能力そのものでは、Ethereum のほうが先行している。BN254 のペアリングプリコンパイルは 2017 年から動いており、コストも安い。したがって「Midnight があるから Cardano が勝てる」とは言えない。差があるとすれば暗号の能力ではなく、プライバシー専用チェーンを本体と並べて持ち、それを規制対応（選択的開示）前提で設計していることであり、これは製品戦略上の位置取りにすぎない。つまり保証された優位ではなく、身元連携の文脈でそれを最初に使い切ったところが取るという性質のものである。
第 VI 部で、公的機関を guardian に入れることは凍結・検閲の経路を自ら設けることでもある、と書いた。ZK による資格提示は、この副作用の一部を実際に消せる。
公的機関が
「このアドレスは
A さんのものだ」
と知っている
↓
資産・履歴が
すべて紐づく
↓
凍結・追跡が容易
公的機関は
「本人確認をした」
としか知らない
↓
どのアドレスかを
知らない
↓
復旧の能力は与えるが
監視の能力は与えない
本人確認の能力と、口座を特定・監視する能力を分離できる。これは第 III 部で見た「認定事業者が実質的な guardian になる」構図に対する、最も直接的な緩和策にあたる。事業者は復旧を助けられるが、誰のどの資産かは知らない。
sha256WithRSAEncryption / 2048 bit）。スマホ用も同一の認証局から発行されるため同じ。楕円曲線ではない。exp_mod_integer ビルトイン（CIP-109）が 2026 年 7 月 18 日の Van Rossem ハードフォークでメインネット有効化され、zkFold が Google の RSA 署名で同種の検証を実測している（実行予算 CPU 約 36.5%、手数料 約 1.23 ADA）。未JPKI の証明書チェーンと失効確認をどう扱うかは別問題として残る。ここは技術より先に効く。当局の一次資料に、答えの一部がすでに書かれていた。
日本の資金決済法は「他人のために暗号資産の管理をすること」を暗号資産交換業の登録対象としている（第 2 条第 15 項第 4 号）。判断基準は金融庁の事務ガイドラインにあり、「利用者の関与なく、単独又は関係事業者と共同して、利用者の暗号資産を移転でき得るだけの秘密鍵を保有する場合など、事業者が主体的に利用者の暗号資産の移転を行い得る状態にある場合」が該当するとされる。
本件に最も直接効くのは、2020 年 4 月 3 日のパブリックコメント回答 No.17・18 である。スマートコントラクトウォレットを提供する事業者について、該当しない条件をこう書いている。
…当該サービスを提供する事業者が、
スマートコントラクト内に保管されている
利用者の暗号資産を移転するために必要な
① 秘密鍵にアクセスする権限を有しておらず、
② 当該スマートコントラクトによる暗号資産の
移転先を指定し、又は変更し得る権限を
有していない
…など、当該事業者が主体的に利用者の暗号資産の
移転を行い得る状態にない場合には、基本的には、
…「他人のために暗号資産の管理をすること」に
該当しないと考えられます。確非該当の条件が二つ並んでいることが要点である。鍵にアクセスできないことに加えて、移転先を指定・変更できないこと。
推裏を返せば、事業者がスマートウォレットの操作鍵を一方的に差し替えられる設計は、秘密鍵を一切持たなくてもカストディと評価されるリスクがある。ただしこれは非該当要件の反対解釈であり、金融庁が「該当する」と明言したわけではない。断定はできない。
そして本稿が第 III 部で立てた問い ――「運営会社の承認だけで操作鍵を差し替えられるか」―― は、自己管理性の問題であると同時に、登録要否の問題でもあった。
同じパブコメの No.14 が、2-of-3 の事例で結論を分けている。ここは設計要件に直結する。
| 構成 | 判定 |
|---|---|
| 各社が別個独立して利用者から委託を受ける | 両社とも非該当 |
| A 社が受託し、その一部を B 社に再委託 | A 社は該当（＝登録が必要） |
確つまり「関係事業者と共同して」の判定は、鍵が物理的に分散しているかではなく、契約上の委託関係で決まる。guardian や復旧事業者を子会社・委託先に束ねる設計は、ここで捕捉される。
関連して、鍵を保有しているかだけでなく生成・再構成できるかも審査対象になる。確2024 年 10 月 8 日のグレーゾーン解消制度回答（パスキー認証を用いるウォレット）は、事業者側の材料だけでは鍵を生成できないことを非該当の理由に挙げている。MPC や鍵導出型の設計では、ここが決定的になる。
この論点を確定させる方法は、実質的にグレーゾーン解消制度による事前照会しかない。前述の 2024 年の案件は、照会から回答まで 26 日（令和 6 年 9/12 → 10/8）で処理されている。設計を固める前に照会する価値がある。
→ 照会書のたたき台を 別紙 に用意した。
なお 確2025 年 12 月 10 日の金融審議会ワーキング・グループ報告は、脚注 72 で「署名鍵の一部を預かるにとどまる場合には…登録は不要とされている」と再確認したうえで、「直ちに規制を設ける必要性は低い」「どのように規制していくべきか、将来的な課題として検討していくことが適当」としている。当面は現状維持だが、中長期では別枠の規制がありうる。
これは素直に設計すると真っ先に踏む。公的個人認証の技術的基準（第 31 条第 4 号）は、電子証明書のシリアル番号について次を定めている。
シリアル番号は
電子署名等確認業務以外の業務において、
個人を識別し管理するための符号として
直接に使用してはならず、
また、次の場合を除いて外部に提供してはならない
ア 本人の求めに応じ、本人又は本人が指定する者へ
イ 最新基本4情報の提供を受けるため機構へ
ウ 電子署名等確認業務に必要な場合確したがって、シリアル番号をオンチェーンの識別子やウォレットアドレスの導出元に使うことは原則として認められない。また SP 事業者は電子証明書そのものも発行番号も保持してはならない。未（ア）の例外がオンチェーン公開に及ぶかは判断が示されておらず、未確立である。
第 III 部で触れた、マイナウォレットの利用規約が「公開鍵の一部をブロックチェーン・分散台帳上に公開すること」を禁じているのは、この制度制約と地続きだと読める。
第 VII 部で相続の設計を書いたが、法的な裏づけについては正直に書く必要がある。
自動移転が実行されても、遺留分侵害額請求（民法 1046 条）や遺産分割の対象から外れるわけではない。つまりオンチェーンの結果と法律上の権利帰属が乖離しうる。技術的に鍵を渡せることと、法的に有効な相続であることは別の問題にあたる。設計は「法的手続きを置き換えるもの」ではなく「法的手続きの結果を実行する手段」として位置づけるのが安全だろう。
2026年7月、マイナンバーカードを活用したデジタル資産ウォレット「マイナウォレット」が一般公開されました。注目すべきなのは、マイナンバーカードで本人確認できること自体ではありません。Ethereum の Account Abstraction を用い、通常時はパスキーで操作しながら、端末や秘密鍵を失った場合には公的個人認証でアカウントを復旧できる点です。
従来のウォレットは「シードフレーズを絶対になくさないでください。なくしたら誰にも復旧できません」という前提に立っています。一般利用者、高齢者、子ども、自治体サービスの利用者に、この責任をすべて負わせることは現実的でしょうか。
Account Abstraction は秘密鍵をなくす技術ではありません。秘密鍵を資産を操作する唯一絶対の条件ではなくし、パスキー、予備端末、ハードウェアキー、家族や guardian、公的本人確認、待機期間、高額送金時の追加承認を組み合わせられるようにする発想です。
Cardano でも、Plutus スクリプト、マルチシグ、時間ロック、状態 UTxO を組み合わせれば同様のウォレットは実現できます。実際に、マルチシグ鍵の CIP-1854（Active）、dApp 接続の CIP-106、Plutus ウォレットの CIP-141、登録・発見の CIP-146 という動きがあります。ただしこれらは個別の仕様にとどまり、パスキー・鍵交換・社会的復旧・手数料スポンサー・ステーキング・ガバナンス・dApp 接続を一つのスマートウォレット標準として統合するところまでは進んでいません（後者三つはいずれも Proposed）。
Cardano は UTxO モデルであるため、Ethereum のスマートアカウントをそのまま移植することはできません。一方で、資産 UTxO 群とウォレット設定を持つ状態 UTxO を、一つの論理的な口座として扱うことは可能です。たとえば ―
Cardano に必要なのは新しいウォレットアプリではなく、シードフレーズを唯一の復旧方法としない Cardano Recoverable Smart Wallet Standard を、エコシステム共通の仕様として整備することです。まずは現在の Cardano 上で、主鍵・予備鍵・社会的復旧・待機期間を備えた Plutus ウォレットを実証できます。その後、パスキー対応、手数料スポンサー、公的本人確認連携、ステーク／DRep 権限、他ウォレットへの移行、dApp 接続、複数事業者による共通実装へ広げるべきです。
Cardano はブロックチェーン自体の安全性を重視してきました。次に必要なのは、人間が鍵をなくすこと、端末を失うこと、判断を誤ることまで前提にしたウォレット設計ではないでしょうか。
Cardano は「シードフレーズをなくしたら終わり」という自己管理の形を守り続けるのではなく、自己管理性を維持したまま鍵を交換・復旧できる、Cardano ネイティブなスマートウォレット標準を優先的に整備すべきである。
足りないのは技術そのものより、問題を最優先課題として定義すること、分散した CIP を統合すること、リファレンス実装を作ること、ウォレット事業者と dApp 事業者が共通仕様を採ること、そして一般利用者向け UX として完成させることである。
CIP-141 を軸に、復旧・鍵交換・スポンサーまで含めて一つの標準へ束ねる。
状態 UTxO の読み書きと取引組み立てを、アプリが意識せず扱える層。
guardian の招待、待機中の通知、取消操作までを含む利用者向けの手順。
パスキーを直接検証するためのビルトイン。フェーズ 5 の主要議題。
この資料は 2 枚組で、こちらは技術の裏づけを載せた詳しいほうにあたる。「では誰に、どこで届けるのか」は別紙にまとめてある。技術を知らない相手と話すときは、そちらから渡すほうが早い。