令和6年10月8日にいわゆるアンホステッドウォレットサービスについて資金決済法上の暗号資産交換業（管理業）に該当しない旨のグレーゾーン回答をが公表されていますが、回答書だけを見ても分かりにくく、照会書と照合するのも大変なので、整理してみました。
図は、照会者が公表しているものをもとに、赤で加筆しています（赤は全て私による加筆です）。回答書は、定義語が多く読みにくかったので、定義箇所を太字にし、定義された語を四角で囲い、赤の丸付き番号で図との対応関係を明示しています。補足等は、私のコメントであり、照会書からは分かりにくいこと、照会書からは分からないがセキュリティの一般的知識に基づいて推測できることなどを書いています。
背景と本グレーゾーン回答の意義
- 「他人のために暗号資産の管理をすること」は、暗号資産交換業に該当し（資金決済法2条15項4号）、内閣総理大臣（実際には財務局長）の登録を受ける必要がある（同法63条の2）。
- この「管理」について、金融庁は、「利用者の関与なく、単独又は関係事業者と共同して、利用者の暗号資産を移転でき得るだけの秘密鍵を保有する場合など、事業者が主体的に利用者の暗号資産の移転を行い得る状態にある場合には、同号に規定する暗号資産の管理に該当する」との解釈を示していた（事務ガイドライン（第三分冊：金融会社関係）（16 暗号資産交換業者関係）I-1-2-2の③）。もっとも、その外延は必ずしも明らかではなかった。
- 令和6年10月8日グレーゾーン回答は、「管理」についての初めての判断事例であり、かつ、照会に係るアンホステッドウォレットサービスがこれに該当しないことを示したものとして、実務上重要な意義を有する。
「ユーザー登録」の図解と補足
（図）
（回答書）
（補足等）
- 「BC事業者」はウォレットアプリ（図では左下の事業者アプリ）を提供する者であり、「照会者」（図では右上の当法人）はBC事業者に対し認証機能を提供する。
- 「パスキー認証デバイス」とは、典型的にはスマートフォンである。当該デバイス上で「パスキー機能」（OSのものが想定されていると思われる）と「事業者アプリ」が動作する。「事業者アプリ」がウォレットアプリであり、BC秘密鍵の生成（とそのためのパスキー識別ID、ユーザー識別IDの取得）に関し、照会者が開発した機能を使用し、かつ、照会者の認証サーバからユーザー識別IDを受け取る。
- 「パスキー秘密鍵」と「パスキー公開鍵」はパスキー認証デバイスのパスキー機能で生成される。これらは対になっており、パスキー公開鍵のみが照会者認証サーバに送信される（③）。
- 「注」のうち、
- 第1文は、パスキーの仕組みを説明したものである。パスキーは公開鍵暗号方式によるデジタル署名を使用した本人確認（当人認証）の方法である。
- 第2文は、パスキー秘密鍵を複数のパスキー認証デバイス（例えばスマートフォンとPC、スマートフォンとタブレット）で使えるようにする方法を説明したものである。「パスキー機能の提供者」とは、例えばGoogleやAppleである。「エンドツーエンドで暗号化」は「暗号化」と同じ意味だと思われる。「同一ユーザーによる認証」は、上記GoogleやAppleが設定する適宜のログイン方法であり、例えばID/PWとログイン済みの別アプリによる承認などが考えられる（GoogleアカウントやiCloudへのログイン方法を考えればよい）。
「BC秘密鍵の利用方法」の図解と補足
（図）
（回答書）
（補足等）
- 事業者アプリとは、つまりウォレットアプリのことである。
- パスキー識別IDとユーザー識別IDからBC秘密鍵が生成されるようであるが（⑤）、その仕組みは明らかにされていない。おそらく生成の仕組み（関数、アルゴリズム？）自体は秘匿されておらず、仕様が分かる立場の人であれば、パスキー識別IDとユーザー識別IDが分かればBC秘密鍵を生成することは可能なのだと思われる（この点は重要なので明記してほしかったところ）。
金融庁の回答の整理
（回答書）
（補足等）
- ⑩は、本サービスの通常のプロセスにおいて、照会者およびBC事業者が秘密鍵を取得しないことをいうものである。
- ⑪⑫はセットであり、照会者が(a)ユーザー識別IDをユーザーのリクエストに応じる以外の場面で利用することは予定しておらず、(b)仮に利用したとしても、パスキー識別IDを知り得ないため、BC秘密鍵を知り得ないことをいうものである。
- ⑬は、BC事業者が(a)ユーザー識別IDとパスキー識別IDのいずれも知り得ないことをいうものであり、(b)（照会者が⑪⑫のとおりである以上）照会者と共同したとしても（意思を通じても、くらいの意味であろう）、BC秘密鍵を知り得ないことをいうものである。
- その上で、照会者については⑩〜⑫から、BC事業者については⑩⑬から、管理該当性を否定している。
コメント
- 本回答において関係事業者の管理該当性が否定された根拠は、端的に言えば、別々に管理され、ユーザーのみがその双方を知りうる2つの値（パスキー識別IDとユーザー識別ID）もとに、ユーザー端末で秘密鍵を生成する、という仕組みにあると思われる。
- 上記の仕組みは、マルチデバイスでの認証を可能にすることと、関係事業者の管理該当性を回避することを両立するために取られていると思われる。管理該当性を回避する最も簡単な方法は、ユーザー端末に秘密鍵を保存することであるが、それでは複数の端末でトランザクションを起こすことができない。しかし、秘密鍵を単純にクラウドで同期しようとすれば、当該クラウドの提供が管理に該当してしまう。そこで、秘密鍵の生成に必要な2つの鍵を別々に管理することとした。
- 逆に言えば、ユーザー識別IDを要求していることが、パスキーの同期に使われるサービスの管理該当性を否定する根拠となっており、一方、パスキー識別IDを要求していることが、照会者の管理該当性を否定する根拠となっている。なお、これらの根拠は、BC事業者の管理該当性を否定する根拠にもなっているが、論理的には、どちらか片方でもBC事業者の管理該当性を否定するには十分のはずである。
- 上記の仕組みは、マルチシグと発想としては同じである。例えばイーサリアムではマルチシグは標準仕様ではないようなので、秘密鍵ではない2つの値を使って1つの秘密鍵を生成することにしたのかもしれない。
- ⑩とは別に⑪〜⑬にも言及した上で管理該当性を否定しているのは興味深い。このことは、通常のプロセスで取得しない（⑩）だけでは管理該当性を否定するには十分ではなく、例外的な場合においても秘密鍵の取得が一定以上困難となっている場合に初めて管理該当性が否定されることを示唆していると思われる。
-
なお、照会者認証サーバや事業者アプリに問題があった場合、BC秘密鍵が漏洩したり、不正に生成されるリスクが否定できない。このような事態が生じないよう、照会者認証サーバや事業者アプリを当局の直接又は間接の監督下に置く必要があるようにも思われる。しかしそうしなかったのは、単に照会者の主張を前提とした可能性がある一方、現状の暗号資産交換業規制の厳重さも考慮すると、上記のリスクをコントロールするためだけにそれを適用するのは適切ではないとの判断ないし感覚に基づいている可能性もある。
