ローレンスが認証（検証）バッジとコミュニティの自律性について書いた。

On verification and coordination authority（Connected Places, 2026年4月14日）

ATProto開発者コミュニティの中で発言力のある書き手だ。以下、論点を紹介しつつ、わたしの視点を加える。

ローレンスの問い

ローレンスの記事の核は一文に集約できる。「ATProto開発者コミュニティを検証しているのはBlueskyだ。なぜコミュニティ自身がそれをできないのか。」

BlueskyのTrusted Verifier制度は、独立した組織が自分たちのメンバーに検証バッジを発行できる仕組みだ。技術的には、開発者コミュニティが自前の検証者になることは可能である。だが実際にはそうなっていない。

ローレンスはここにブートストラップ問題を見ている。コミュニティが自前の検証者を立てるには、運営主体、選定基準、正統性の三つが同時に必要になる。だが三つは相互に依存している。基準がなければ運営主体に権威がない。権威がなければコミュニティの支持が得られない。支持がなければ基準に信頼性がない。鶏と卵が三重に絡まっている。

Blueskyはプロトコルの開発元としての正統性をすでに持っているから、この問題をまるごと迂回できる。だからBlueskyが検証する。合理的ではある。

快適な依存

ローレンスの記事でもっとも鋭いのは、ここから先の分析だ。

コミュニティがBlueskyと良好な関係にあること。信頼していること。Blueskyがコミュニティに好意的に関与していること。これらの条件が、独立した制度を作る動機を抑制している。

対立があれば、独立の必要性は自明になる。だが対立がない。Blueskyがうまくやってくれているから、自分たちでやる理由がない。これが依存を一段ずつ深くする。ローレンスの表現を借りれば、「一つずつ積み重なる快適な依存」だ。

ローレンスはこれを危機とは呼ばない。今日解決すべき問題だとも言わない。だが、将来コミュニティが本当の独立を必要としたとき、coordination authority——意思決定を行い、それが通る力——を自前で持っていなければ動けない、と指摘している。

認証はcoordination authorityの影

わたしは2月に「"認証"マークの議論に足りないもの——相互検証という選択肢」を書いた。認証バッジの付与構造が「上から与える」設計であること、相互検証（cred.blue）という代替が既に存在すること、ドメイン認証の理念が形骸化していること。これらを指摘した。

ローレンスの記事を読んで、わたしの2月の記事が扱っていたのは氷山の水面上の部分だったとわかる。

認証バッジは制度の一つにすぎない。その背後にあるのは、「誰がコミュニティにとって重要な判断を下せるか」という問いだ。検証バッジの付与。イベントの承認。エコシステム内の優先順位づけ。これらを束ねているのがcoordination authorityであり、現状それはBluesky PBCが握っている。

「Decentralization Recurses」で書いた二重拘束テーゼと地続きだ。分散化を理念に掲げるプラットフォームが、運営上は中央集権的に機能せざるを得ない。認証バッジの付与構造は、この矛盾が制度の末端に現れた一例にすぎない。

日本コミュニティの追加層

ここからはローレンスの記事が扱っていない論点に入る。

ローレンスが描くのは英語圏のATProto開発者コミュニティだ。Blueskyと開発者の距離が近く、ATmosphereConfで顔を合わせ、互いに名前を知っている。小さなシーンだ。そのシーンの中でBlueskyがcoordination authorityを担っている。

日本語圏には、この構造にもう一つの層が入る。Country Managerだ。

Blueskyの日本におけるCountry Managerは、認証バッジの推薦権限を持つ。直接付与するわけではないが、日本語圏で誰がバッジを得るかに影響力を持つ中間ノードとして機能している。

英語圏では「Bluesky → コミュニティ」の一段構造だ。日本語圏では「Bluesky → Country Manager → コミュニティ」の二段構造になる。ローレンスが指摘したcoordination authorityの集中が、もう一つの結節点を経由して伝わる。

これは依存を二重化する。コミュニティはBlueskyに依存し、同時にCountry Managerという中間層にも依存する。Blueskyの判断が直接届くのではなく、中間層のフィルターを通る。なお、現在この中間層の運用はCM独自のキュレーションから申請性を重視する方向にシフトしつつある。改善の動きはある。だが、依存の経路にもう一つ結節点が挟まっている事実は変わらない。

「快適な依存」は英語圏の話

ローレンスの「快適な依存」テーゼには、もう一つ死角がある。

英語圏の開発者コミュニティがBlueskyと「良好な関係」にあるのは事実だ。ATmosphereConfの空気を知っている者なら異論はないだろう。

だが日本語圏では、依存を快適だと感じている層と、そもそも依存構造を認識していない層が混在している。認証バッジに対する不満が定期的に噴出するのはその証拠だ。不満は出るが、それがcoordination authorityの問題として言語化されることはほぼない。「バッジが欲しい/欲しくない」という表層で議論が止まる。

わたしの2月の記事は、その表層を一枚めくる試みだった。ローレンスの記事は、さらにその下にある地盤を見せている。

coordination authorityは技術の問題ではない

ローレンスが最後に書いていることが重要だ。coordination authorityの獲得は社会的な課題であり、技術的な課題ではない。オープンプロトコルのコミュニティは歴史的に、ソフトウェアを書くことよりもこちらのほうがはるかに難しいと証明してきた。

わたしも同じ認識だ。Trusted Verifier制度も、ドメイン認証も、相互検証も、技術としては存在している。足りないのは技術ではない。「誰が旗を立てるか」だ。

ローレンスの記事は、この問いを英語圏のATProto開発者コミュニティに向けて置いた。わたしはこの紹介を通じて、同じ問いを日本語圏に置く。

答えはまだない。だが問いが置かれていない場所では、答えは絶対に生まれない。