Blueskyで認証マークの議論がまた盛り上がっている。定期的に繰り返される話題だ。いくつかの投稿を眺めていたが、毎回同じところで止まるので、少し別の角度から整理しておく。

二つの問題を分ける

認証マークへの不満には、性質の異なる二つの問題が混ざっている。

一つは、非表示機能が知られていないことだ。認証マークはモデレーション設定で非表示にできる。だが、この機能は2025年4月のBluesky公式ブログに英語で一文記載されているだけで、アプリ内での目立った案内や日本語での周知はされていない。わたし自身、他のユーザーのやりとりを見て初めてトグルスイッチの存在を知った。書いてあることと伝わっていることは別の話だ。機能が存在していても、届いていなければ意味がない。

もう一つは、付与プロセスの不透明さだ。Bluesky公式ブログによれば、検証マークの付与には、運営が能動的に著名アカウントを検証して付与する方法、Trusted Verifiers（信頼できる検証者）に認定された組織が自組織のメンバーに付与する方法、そして個人や組織が申請フォームから自ら申請する方法がある。しかし、実際にどういう基準で誰に付与されているのかは外から見えにくく、特に日本語圏では運営からの能動的付与が目立つ一方で、申請プロセスの存在や手続きが十分に知られていない。仕組みはあっても、その運用が不透明であれば、疑問が出るのは当然だ。

どちらも運営側の問題だ。議論が毎回空転するのは、この二つが区別されないまま語られるからだ。

なお、本稿は運営に対する運用改善の要求を否定するものではない。ガイドラインと実際の運用が一致していないという指摘が出ているなら、それは運営が応えるべき問題だ。本稿が書いているのは、その先にある選択肢についてだ。

「認証」という言葉が運ぶもの

そもそも、Blueskyの公式な用語はverificationであり、これは「検証」だ。「認証」ではない。検証とは、ある事実が正しいかどうかを確かめる行為であり、権威が資格を与える「認証」とは意味が異なる。

だが日本語圏では、この機能は最初から「認証マーク」と呼ばれている。この言葉の選択自体が、Xの青バッジ——「運営が公式と認めた証」——というフレームをそのまま密輸している。Blueskyがいくら「これは検証です」と説明しても、「認証」という語で受け取った時点で、ユーザーの頭の中では「運営のお墨付き」として処理される。

言葉が認知の枠組みを決める。verificationの適切な訳語が日本語に定着していないことが、この議論を不必要にこじらせている一因だ。

「上から与える」構造の限界

言葉の問題に加えて、構造の問題もある。

付与基準を明確にすれば、不透明さの問題はある程度解消される。だが、もう少し根本的なことを考えたい。

検証マークは、プラットフォーム運営が特定のアカウントを選んで付与するものだ。この構造では、どれだけ基準を整備しても「なぜあの人にはあって、この人にはないのか」という問いが消えない。選定という行為そのものが、選ばれた側と選ばれなかった側の非対称を生むからだ。

Blueskyは「ドメインは分散型の検証手段だ」という思想で始まったプラットフォームだ。にもかかわらず、検証マークの付与は運営が一方的に判定する仕組みになっている。ここに設計上の矛盾がある。

信頼はどこから来るか

人間は他者のことを完全には理解できない。自分の視点から想像するしかない。それでも、「わたしはこの人に会った」「わたしはこの人を知っている」という個別の確認が積み重なるとき、そこに信頼の網ができる。完全な理解ではなく、不完全な確認の重なりがコミュニティの輪郭をつくる。

重要なのは、プラットフォームのアーキテクチャがこの重なりをどう整えるかだ。

運営が上から判定する設計は、個々の関係を無視して一つの権威的な基準を押しつける。ユーザー同士が相互に確認する設計なら、信頼は個々の関係の中から立ち上がる。

後者の設計は、既に存在している。

相互検証という選択肢

Blueskyのエコシステムには、cred.blueというサービスがある。ATProtoエコシステム向けのツールを複数開発している独立開発者dame（@dame.is）が、自身のプロジェクトatpota.toの一環として作ったものだ。Bluesky運営とは無関係の、サードパーティによる取り組みだ。cred.blueはアカウントの信頼度スコアリングやATProtoデータの可視化に加え、ピア検証（peer verification）——ユーザー同士による相互検証の機能を提供している。

運営が「この人は本物だ」と判定するのではなく、ユーザー同士が「この人に会ったことがある」「この人を知っている」と相互に検証する。信頼の根拠が運営の判断ではなく、個人同士の関係に置かれる。

Blueskyはもともとドメイン認証という分散型の本人確認を基盤にしていた。自分のドメインをハンドルに設定することで、運営を介さずに所有者であることを証明する。しかし現実には、大多数のユーザーがbsky.socialのハンドルのまま利用しており、ドメイン認証は広く浸透しているとは言いがたい。その状態で運営が別途検証マークを付与し始めれば、ドメイン認証の存在意義はさらに薄れる。本来の理念を運営自身が形骸化させている構図だ。

相互検証は、このドメイン認証の延長線上にある発想だ。ドメイン認証が「わたしはこのドメインの所有者だ」という自己証明なら、相互検証は「わたしはこの人を知っている」という関係の証明だ。どちらも運営の介在を必要としない。

わたしは実際にcred.blueで、会ったことのある人を検証した。語っているだけでは仕組みは変わらない。

議論に足りなかったもの

検証マークの議論は、いつも「賛成か反対か」で止まる。だが本当に必要なのは、「認証」という言葉に引きずられた枠組みから離れることと、「上から与えられる認証」以外の選択肢を知ることだ。

ドメイン認証も相互検証も、既にある。技術は揃っている。足りないのは、それを使うという選択だ。

不満を表明するのは自由だ。だが、その前に自分にできることを試してみてもいいだろう。