“招待スパム”の時代を終わらせる？BlueskyのFind Friendsは何が違うのか

「友達を見つける」——SNSが当たり前のように備えてきたこの機能は、実は長年“厄介者”でもあった。スマホの連絡先を読み取らせ、誰が同じSNSにいるかを突き止め、ついでに未登録の相手へ招待メッセージを飛ばす。ユーザーにとっては再会の近道だが、受け取る側にとっては突然届く“アプリの勧誘SMS”になりがちで、しかも電話番号という強い個人情報が絡む以上、漏えい・濫用のリスクも常に隣り合わせだった。Blueskyが12月、「Find Friends」を“プライバシー重視”として打ち出した背景には、この古い成功パターンをそのまま踏襲しない、という強い意思が透けて見える。 TechCrunch

「招待スパム」をしない、という宣言

TechCrunchが伝えた今回のポイントは明快だ。Blueskyは、連絡先をアップロードしてもアプリ側が自動で招待SMSを送らない。やるとしても“ユーザーが自分の意思で、友人にテキストを送る”という手動アクションに限定する。これまで多くのSNSが、連絡先照合を成長ハック（バイラルの導線）として使い、半ば強制的に招待を飛ばしてきたことを踏まえると、かなり挑戦的な立場表明だ。 TechCrunch

ただし、ここにはトレードオフがある。Blueskyは「個別の電話番号を保存・追跡しない」設計のため、相手がすでにBlueskyにいるかどうかを事前判定できない。その結果、友人が善意で招待テキストを送ってきたとしても、受け取る側が“もう参加済み”でも届いてしまう可能性がある。9to5Macはこれを「欠点」としつつ、プライバシー保護の代償としては小さいと評している。 9to5Mac

仕組み：二重同意（ダブル・オプトイン）＋番号確認

BlueskyのFind Friendsは、次の条件が揃わない限りマッチしない。

• 両者がFind Friendsを有効化している

• お互いを連絡先に登録している（片思いの連絡先登録では成立しない）

• SMSで自分の番号を確認してから連絡先をアップロードする

TechCrunchの説明では、利用時にSMSで届く6桁コードを入力して番号を検証し、ランダムな番号を大量投入して「この番号はBlueskyにいるか？」を釣り上げる“フィッシング”のような悪用を抑える狙いがあるという。さらに、そもそも使わなければ「電話番号で発見される側」にもならない——職場の知人に見つけられたくない人は、機能を使わないという選択が残る。 TechCrunch

提供地域も段階的で、初期はモバイルアプリの一部の国（日本を含む）に限られている。 TechCrunch

「ハッシュペア」＋「別置きのハードウェアキー」—漏えい前提の防御

今回いちばん興味深いのは、Blueskyが“連絡先照合”をセキュリティ設計の問題として正面から扱っている点だろう。TechCrunchおよびBlueskyの公式ブログによれば、アップロードされた電話番号は単純なハッシュ化ではなく、「自分の番号×相手の番号」を組にした“hashed pairs（ハッシュペア）”として保存される。これにより、仮にデータが漏れても逆算（リバースエンジニアリング）を難しくする、という理屈だ。さらに暗号化は、DBとは別に保管されたハードウェアセキュリティキーに紐づけるとしている。ユーザー側は後からデータ削除・オプトアウトもできる。 TechCrunch

またTechCrunchは、この技術的詳細が事前にRFCとしてセキュリティコミュニティへ共有され、フィードバックを募っていた点も伝えている。裏を返せば、Bluesky自身も「連絡先照合は危ない実装が多い」ことを認め、いきなり本番投入するのではなく設計を晒して議論した、ということだ。 TechCrunch

なぜここまでやるのか：「コールドスタート」と“現実の友人”

Blueskyはブログで、SNSが本来「実際に知っている人とつながる場」だったのに、アルゴリズムやエンゲージメント競争のノイズでそれが失われた、と問題提起している。いま改めて“知り合いに会えるSNS”を目指すなら、友達発見は避けて通れない。しかもBlueskyは、RFCの文脈では「ソーシャルグラフの密度を立ち上げるコールドスタート問題」に触れ、ユーザー規模にも言及している。 Bluesky

要するに、Find Friendsは便利機能の追加というより、「分散型（を志向する）SNSが、どうやって人間関係の初動をつくるか」という、サービスの根幹に近いテーマでもある。

SNS（コミュニティ）上の反応：歓迎と懐疑が同居

今回の設計はさっそく議論を呼んだ。ここでは“SNSの反応”として、Hacker NewsとGitHub Discussionsでの声を中心に、傾向を整理する。

1) 「Private Set Intersectionみたいな発想」—より暗号寄りの解決を示唆

Hacker Newsでは、関連する技術領域としてPrivate Set Intersection（集合の共通部分だけを秘匿のまま求める発想）を挙げ、「電話番号を平文で共有しないことで攻撃クラスを丸ごと避けられる」といった方向性が話題になった。一方で「スケール面では過剰かもしれない」と現実的な線引きをするコメントもある。 Hacker News

2) 「セキュリティは書いてあるが、結局サーバーを信頼するのでは？」という指摘

同じくHacker Newsでは、RFCが“セキュリティ”を扱っている一方で「最終的にはサーバー／インスタンスを信頼する構図に見える」と懐疑的な見方も出た。番号検証（スプーフィング対策）と、サーバーに番号を渡さない設計は両立しにくい、という現場感のあるコメントだ。 Hacker News

3) 「電話番号はハッシュでも危ない」—番号空間の小ささ問題

別のコメントでは「電話番号はユニークさが足りず、ハッシュはルックアップテーブルで対応され得る」と、いわゆる“番号空間が狭い”問題を突く声もある。Blueskyが「ハッシュ“ペア”」にして逆算難度を上げる狙いはここにあるが、ユーザー側の不安としては根強い。 Hacker News

4) GitHubでは「仕様をもっと明確に」「そもそも連絡先＝ソーシャルではない」

GitHubのディスカッションでは、設計の細部に踏み込んだフィードバックが目立つ。たとえば**電話番号リサイクル（番号の再割り当て）**に関する説明が分かりにくいので、擬似コードを早めに示したほうがよい、といった建設的な指摘がある。 GitHub

また別のコメントでは「自分の電話帳はソーシャルグラフと一致しないから、この機能は使わない」と述べつつ、オプトインのまま／余計な“名寄せ用の付加情報”を保存しない限りは懸念しない、という距離感が示された。 GitHub

まとめ：Find Friendsは“機能”というより「約束」の形

BlueskyのFind Friendsは、表面的には「ようやく友達検索が来た」というアップデートだ。しかし中身は、(1) 自動招待で伸ばす誘惑を断ち切り、(2) 二重同意で“見つかる側”にも選択権を残し、(3) 漏えい前提で設計を固め、(4) 事前にRFCを公開して外部レビューを受ける——という、プライバシーと成長のバランスに対する“約束”を実装したものに見える。 TechCrunch

もちろん、電話番号という素材そのものが強力すぎる以上、完全に論争が消えることはない。Hacker NewsやGitHubの反応が示すように、サーバー信頼や番号空間の問題、そして「連絡先＝友達ではない」という根本論も残る。 Hacker News

それでも、連絡先照合を“成長装置”ではなく“安全設計の課題”として扱う姿勢は、これから同種の機能を実装するSNSにとって、ひとつの基準点になるかもしれない。 Bluesky