電話番号のないSignal — ゼロ知識証明が肩代わりするもの、しないもの

電話番号を取り除いた場所に入るのはプライバシーなのか、それとも別の名前の本人確認なのか?

導入

2026年9月13日(UTC)、Hacker Newsのトップに「Signalの電話番号なし登録はゼロ知識証明を使うことになる」という題の投稿が上がり、397ポイントを集めた。リンク先はSignalの公式ブログではなく、Signalコミュニティフォーラムの古いスレッド「Registration without a phone number」の10ページ目である。このスレッドの投稿番号はすでに200を超えている。電話番号なしで登録させてほしいという要望は、それほど長く続いてきた。

今回変わったのは要望ではなく、証拠である。8月中旬からSignal-Androidの公開リポジトリに「numberless」という語を含むコミットが次々と現れ、フォーラムの利用者はベータリリースのたびにそれを転載した。8月17日「電話番号なし登録のためのネットワークのプレースホルダーを追加」、9月2日「電話番号なしアカウントを登録する基本機能を追加」と「電話番号なしアカウントに新しいzkgroup資格情報を使用」、9月9日「Signalログインの支払い機能を追加」という流れだ。

HNのタイトルはゼロ知識証明(ZKP)を前面に出したが、コミットを実際に開いてみると話の中心は課金である。電話番号の代わりに一回限りの購入が入り、ゼロ知識証明はその購入がアカウントと結び付かないようにする仕掛けとして使われる。とすれば問いはこう言い換えられる。電話番号がSignalで担っていた仕事は何だったのか。そして課金とゼロ知識証明の組み合わせは、そのどこまでを肩代わりするのか。

本稿ではまずコミット、フォーラム、HNの議論から確認できる事実を整理し、その上に分析を分けて書き加える。リリース日や価格など、まだ公開されていない部分はそう明記する。

コミットが語ること

まず9月9日のコミット「Add ability to pay for a signal login」の構造から見ていく。このコミットは、Google Playの一回限りの商品購入を扱うbillingモジュールと、登録画面の支払いステップを追加している。サーバーAPI側には GET /v1/subscription/configuration から「login」項目を読み出す関数ができた。レスポンスには販売するPlay商品IDとともに、その購入が持つ「レシートレベル(receipt level)」が含まれる。クライアントのコードはこの値を300とし、App Storeの商品IDフィールドも定義したうえで、Androidでは使わないとコメントに記している。iOSの経路も設計に入っていると読めるが、iOS側の実装は本稿では確認できていない。

肝心なのは支払い後の流れだ。コードがimportしているクラス名がそれをそのまま示している。クライアントはランダムな ReceiptSerial を作り、それで ReceiptCredentialRequestContext を生成する。サーバーがPlayの購入を確認したうえで ReceiptCredentialResponse を返すと、クライアントはそれを検証して ReceiptCredential を受け取る。そして登録時には、その資格情報そのものではなく、そこから作った ReceiptCredentialPresentation を提出する。9月2日のコミットのコメントはこう整理している。登録リクエストにはSMSセッションID、リカバリーパスワード、レシート資格情報のプレゼンテーションのうち、ちょうど一つを渡さなければならない。プレゼンテーションを渡すと電話番号のないアカウントが作られる。その際、電話番号フィールドとPNI用の事前鍵は必ず空でなければならず、「電話番号で検索可能」属性もnullでなければならない。

この zkgroup.receipts 系は新しく作られたものではない。Signalは2025年9月にセキュアバックアップを紹介した際、月1.99ドルの有料プランを出し、「グループをメタデータを露出させずに動かしているのと同じゼロ知識技術」を使って、バックアップアーカイブを特定の支払いやアカウントと直接結び付けずに保存すると説明した。フォーラムでは、寄付バッジとバックアップは似た仕組みで動いていると説明する利用者がいた。Signalは支払った人のリストは持っているが、クライアントは「その中の一人」であることを証明するだけで、「誰」なのかは明かさない、という説明だ。正確な暗号学的構成はフォーラムの説明より複雑だろうが、今回の登録経路が既存の「支払いとアカウントを結び付けない」インフラを再利用していることは、importの一覧から確認できる。

支払いフローの細部も興味深い。リポジトリのコードコメントによれば、購入は引き換え(redeem)の前にまずディスクへ保存され、支払い後にどこで失敗しても、やり直せば同じ購入を引き継いで使う。サーバーは同じ購入を別のリクエストで再び引き換えようとすると拒否するため、引き換え済みの購入に新しいリクエストコンテキストを作ると恒久的な「AlreadyRedeemed」エラーになると書かれている。購入は引き換えの後にはじめてPlay上で「消費(consume)」され、そうしてはじめて二つ目のアカウントのために再購入できる。つまり一回の支払いは、ちょうど一つのアカウントになる。

もう一つ目を引くコミットがある。「Use new zkgroup credential for numberless accounts」はグループ認証のコードを修正している。従来、グループサーバーに自分を証明する資格情報はACI(アカウント識別子)とPNI(電話番号識別子)をまとめて束ねていた。電話番号のないアカウントにはPNIがないため、新しいコードはPNIがないとき、登録時にサーバーから渡されたソルトを代わりに入れる receiveAuthCredentialWithoutPni の経路をたどる。電話番号は登録の関門だけでなく、グループプロトコルの資格情報の構造にまで染み込んでいたということだ。

最後に、登録後のアカウントの姿である。他のコミットは電話番号の検索可能設定を隠してデフォルトをfalseに固定し、PINのリマインダーを止め、バックアップのオンボーディングを手直ししている。8月末のコミットでは登録の過程でユーザー名をその場で決められるようになり、利用者の報告によればTOTPや物理セキュリティキーを使った二要素認証も選択肢に入るようだ。電話番号のないアカウントは「ユーザー名+別途のログイン資格」という、Webサービスで見慣れた形に近づいていく。

電話番号が担っていた仕事と、ゼロ知識証明が肩代わりする仕事

ここからは分析である。電話番号はSignalで少なくとも二つの役割を同時に担ってきた。一つは連絡先の発見、つまりアドレス帳にいる人がSignalを使っているかを知るための識別子としての役割だ。もう一つは登録コスト、すなわち一人がアカウントを無限に量産できないようにするシビル(sybil)対策としての役割である。

一つ目の役割は、2024年の時点ですでにかなり切り離されている。Signalは2024年2月にユーザー名を導入した際、電話番号を会話相手にデフォルトで見せないようにし、「電話番号で自分を見つけられる人」を「誰もいない」に設定するオプションを加えた。ただし当時の告知は括弧の中ではっきり書いていた。登録には引き続き電話番号が必要である、と。つまり識別子としての露出は減らしたが、サーバーと通信キャリアが「この番号はSignalアカウントを持っている」と知る構造は残った。

二つ目の役割が今回の変化の本体である。HNでkarel-3dは、「門番なし」「誰でも誰にでもメッセージを送れる」「スパムが少ない」の三つを同時に持つことはできないとまとめた(直接の引用ではなく、コメントの要旨の要約)。EGregとiamsyrも同じ問いを投げている。電話番号を外したらシビル攻撃は何で防ぐのか、攻撃者が安く量産できないものは何なのか(直接の引用ではなく、コメントの要旨の要約)。

コミットが示した答えは単純だ。お金である。9月16日に公開された8.28ベータの告知はこれを明言した(後述の追記を参照)。だが電話番号とお金は、コストとしての性質が違う。Cider9986は、Signal登録用の電話番号は10セントほどで買え、スパマーはもっと安く手に入れているだろうと指摘しつつ、それでも番号をなくす心配がないので自分はお金を払うと書いた(直接の引用ではなく、コメントの要旨の要約)。この指摘が正しければ、電話番号はスパマーにとってはすでに安いコストであり、むしろ一般の利用者にとって高いコストだったことになる。番号を変えればアカウントが揺らぎ、海外に移住すればSMSが届かず、検閲のある国では認証コードそのものが届かない。フォーラムのロシアの利用者は、SMSコードが届かないか、支払えば処罰されるリスクがあり、どちらの選択肢も合わないと書いている。

課金ベースのコストの利点は、価格をサービス自身が決められることだ。電話番号の価格は通信市場と仮想番号業者が決めるが、「Signalログイン」の価格はSignalがサーバー設定で決める。コードが商品IDとレベルをサーバーから受け取るように設計されているのは、このダイヤルを自分の手に握るという意思表示だと読める。ただし9月14日時点で価格は公開されていない。フォーラムでは価格帯を問う投票が立てられただけである。

ynnivは、「ゼロ知識」と言って手を振ってもプライバシーは生まれず、この情報だけでは判断できないと書いた(直接の引用ではなく、コメントの要旨の要約)。この懐疑はもっともだ。ならば、何が証明され何が証明されないのかを切り分けてみよう。

ゼロ知識のレシート資格情報が肩代わりするのは、「サーバーのデータベース内の結び付き」である。サーバーはPlayの購入トークンを検証して資格情報を発行する。後で登録リクエストにプレゼンテーションが届くと、サーバーはそれが有効で未使用の資格情報であることは分かるが、どの発行分から来たのかは数学的に結び付けられないよう設計されている。teravorは、こうした「クーポンを買って帰属なしに使う」構造ならブラインド署名でも十分だと指摘した(直接の引用ではなく、コメントの要旨の要約)。PinkiesBrainは、支払いの参照がサーバーのDBにあれば結局識別できるのではないかと問うたが(直接の引用ではなく、コメントの要旨の要約)、まさにその結び付きを断つのがこの資格情報の役割だ。サーバーが持つのは「支払いがあった」と「アカウントができた」という二つの切り離された事実であり、その間の矢印は保存されない。

しかし、ゼロ知識証明が肩代わりできないものが少なくとも三つある。

第一に、決済代行者が知っていることだ。Google Playは、どのGoogleアカウントが「Signalログイン」商品を買ったかを知っている。opengrassはコミット上Google Play Billingでの購入が必要だと整理し、wolvoleoはAndroidでGoogleアカウントを要求するなら受け入れられないと反発した(いずれも直接の引用ではなく、コメントの要旨の要約)。mr_big_bowlsは、これはある識別子を別の識別子に取り替えただけではないかと表現した(直接の引用ではなく、コメントの要旨の要約)。ゼロ知識証明はSignalサーバー側の結び付きを断つだけで、「この人はSignalアカウントを一つ買った」という事実が決済側に残ることは防げない。電話番号での登録で通信キャリアが知っていた事実が、決済事業者へ移るだけである。違いがあるとすれば、通信キャリアは番号と実名を紐付けていることが多い一方、Playアカウントはプリペイドのギフトカードなどで比較的緩く作れるという点だ。フォーラムでも、現金でストアクレジットを買う方法が挙がっていた。

第二に、タイミングとネットワークの相関である。このフローでは、購入、資格情報の発行、登録が一つの画面で数秒間隔のうちに起きる。ゼロ知識証明はデータベースのレコード間の数学的な結び付きを断つが、同じIPから数秒違いで届いた二つのリクエストをサーバーがログとして保管していれば、統計的に再び結び付けられる。寄付やバックアップのように支払いと引き換えの間に時間が空き得るケースと違い、登録は支払い直後に引き換えるのが自然な流れだ。これはコードで確認された脆弱性ではなく構造から導かれる推論であり、Signalがそうしたログを残しているかは確認されていない。ただ、「ゼロ知識」という言葉が保証する範囲を考えるうえで外せない点である。

第三に、スパムそのものだ。ゼロ知識証明は、コストを支払ったという事実を匿名で証明するにすぎない。コストがいくらなのかは証明の問題ではなく価格政策の問題である。価格が10セントの仮想番号より低ければ、スパマーにとってはむしろ好都合な経路になる。高ければ一般の利用者、とりわけSignalを最も必要とする地域の利用者にとって障壁になる。フォーラムのある利用者が指摘したように、既存の電話番号アカウントの番号を「切り離す」機能を無料で提供すれば、一つの番号で登録と切り離しを繰り返してアカウントを無限に作れてしまう。コミットはこれまでのところ新規登録の経路だけを扱っており、既存アカウントの番号切り離しについては根拠が見当たらない。

まとめると、ゼロ知識証明が肩代わりするのは「誰が支払ったかをSignalに知られないようにすること」である。「誰が支払ったかを誰にも知られないようにすること」と「お金がスパムを防ぐのに十分であること」は肩代わりできない。前者は決済手段の問題であり、後者は経済学の問題だ。

展望と示唆

いくつかのシグナルを整理しておく。第一に、決済手段の多様化が次の争点になるだろう。HNでもフォーラムでも、MoneroやBitcoin、あるいはSignalアプリにすでにある暗号資産決済を使おうという要望が出た。コードが商品定義をサーバー設定に切り出し、App Storeのフィールドまで用意しているのを見ると、決済経路を追加する構造的な余地はある。ただ、どの決済手段が加わるかについては根拠がない。

第二に、この設計は「番号のないメッセンジャー」陣営との違いをはっきりさせる。user10235は、SimpleXとDelta Chatがすでに何年も前から支払いなしで番号のない登録を提供していると指摘した(直接の引用ではなく、コメントの要旨の要約)。それらのプロジェクトはグローバルな識別子そのものをなくす方向を選んだ。Signalは中央サーバーとグローバルなアカウントを維持しつつ、サーバーが知り得ることを数学的に減らす方向を選んだ。同じ「番号なし」でも脅威モデルが違う。

第三に、sarjannが触れたように、AIエージェント用のアカウントのように人間ではない主体がメッセンジャーのアカウントを必要とするケースが増えている(直接の引用ではなく、コメントの要旨の要約)。課金ベースの登録はそうした需要に道を開くと同時に、「一人一番号」という暗黙の上限が消えることも意味する。アカウント一つの価格が、そのまま自動化されたアカウント一つの価格になる。

第四に、最も実務的な示唆は設計の方法論だ。一つの識別子が複数の役割を兼ねているとき、それを取り除くには役割を一つずつ引き剥がしていくしかない。Signalは2024年に発見機能を、2026年に登録コストを切り離しつつあり、その過程でグループ資格情報のように隠れていた依存関係まで直さなければならなかった。自分が運用するサービスで、メールアドレスや電話番号がいくつの役割を同時に担っているかを数えてみるのは意味のある練習である。

(9月16日追記:フォーラムのスレッドによれば、Android 8.28ベータの告知は、電話番号なしで任意に登録できるようになったこと、スパム防止のために少額の一回限りの料金が必要だが、このアプリ内購入は新しいSignalアカウントと直接関連付けられないことを明らかにした。9月17日には当面Google Playでしか支払えない点がフォーラムで指摘され、9月23日には「Enable phoneless registration」コミットが共有された。価格は本稿で確認した資料の中には見当たらなかった。)

結論

HNのタイトルはゼロ知識証明を前に立てたが、コミットを追うと今回の変化の実体は「電話番号というコストをお金というコストに置き換えること」であり、ゼロ知識証明はその交換がSignalサーバーに新たな結び付きを残さないようにする補助装置である。その装置は、すでに寄付とバックアップで使われていたものだ。

この交換には、一般の利用者にとって明確な利点がある。番号をなくしてもアカウントは揺らがず、通信キャリアが「この番号はSignalを使っている」と知る必要もない。しかし決済事業者が知ること、数秒間隔で届くリクエストの相関、そして価格がスパムを防ぐのに十分かという問題は、数学が解いてくれるものではない。

だから「ゼロ知識」という言葉を聞いたときに問うべきことは一つである。誰に対して、何を知られないようにするのか。Signalの答えは「Signalサーバーに対して、支払いとアカウントの結び付きを」だ。その答えが自分の脅威モデルにとって十分かどうかは、心配している相手がSignalなのか、Googleなのか、通信キャリアなのかによって決まる。

出典: