ニュースの概要
Blueskyは分散型SNSとして設計され、ATProtoというオープンな標準を採用している。しかし実際のユーザーの大半は同社が運営するインフラにそのまま依存しているという分析記事がHabrに掲載された。記事は、理論上は誰でも自分のサーバーを立てて参加できる仕組みであるにもかかわらず、ユーザー発見の仕組みやモデレーション、データの実際の保管先がBluesky社に集中している現状を指摘している。分散型SNSへの関心が再燃する中、この「分散型らしさ」の実態を巡る議論は今後も続きそうだ。
引用元: 分散型SNSの議論が継続、Blueskyの分散性と実利用の乖離を巡る分析記事（Habr）
分析・見解
「誰でもサーバーを立てられる」ことと「実際に立てる人がいる」ことは別問題
ATProto(AT Protocol)の設計自体は、確かに分散型の名に値する。PDS(個人データサーバー、自分のデータを置く場所)を自分でホストし、独自のリレーやApp View(アプリの見た目を組み立てる仕組み)を構築することが技術的には可能だ。しかし現実には、利用者の大多数がBluesky社の提供する既定のPDSをそのまま使い続けている。これはメールの仕組みに似ている。理論上は誰でも自分のメールサーバーを運用できるが、実際にはGmailなど大手サービスに集中している。プロトコルが分散型であることと、エコシステムが実際に分散して運営されることは、まったく別の話だとBlueskyの事例は改めて示している。
ユーザー発見とモデレーションという「見えない中央集権」
記事が指摘する最も重要な点は、データの保存場所以上に、ユーザー発見(誰のアカウントがおすすめ欄に出るか)とモデレーション(何が削除・非表示になるか)という、体験を左右する部分がBluesky社のインフラに依存していることだ。自分でPDSを運営していても、同社が提供する既定のリレーやモデレーションサービスを経由しなければ、他の利用者から見つけてもらうことすら難しい。「技術的には出て行けるが、実際には出て行けない」状態が生まれている。似た構造は、WordPressにおける自己ホスト版とWordPress.comの関係、Mastodonにおける一強インスタンスの存在にも見られ、分散型を掲げるプロジェクトが共通して直面する壁だと言える。
Farcasterとの比較で浮かぶ設計思想の違い
この問題を考える手がかりになるのが、同じく分散型を志向するFarcasterとの比較だ。Farcasterはハブ(Hub)と呼ばれる仕組みで複数の運営者がデータを複製・同期する前提を最初から組み込み、特定の一社への依存を構造的に避けようとしている。一方ATProtoは「誰でも参加できる余地を残す」ことに重点を置き、実際に分散させるインセンティブ設計までは踏み込んでいない。優劣の問題というより、分散の「程度」と「誰が担うか」という思想の違いが、今回指摘された乖離を生む土壌になっている。
データの持ち出しやすさは確保されているが、移行のハードルは依然高い
公平に見れば、ATProtoはアカウントとデータを別のPDSへ移行できる仕組み(アカウントポータビリティ)を標準で備えており、これは多くの中央集権型SNSにはない利点だ。実際に自前でPDSを運用する個人や企業も少しずつ増えている。ただし移行した先でも、ユーザー発見やモデレーションの大部分をBluesky社のインフラに頼らざるを得ない以上、「データは自分のもの、しかし見つけてもらえるかは他人任せ」という不均衡な状態が当面続くとみられる。
ビジネスへの影響
自社でPDSを運用する判断は「今」急ぐ必要はない
Blueskyの活用を検討している企業にとって、今すぐ自前のPDSを構築する優先度は高くない。公式のPDSを使っていてもデータポータビリティという「将来の保険」は確保されているため、まずは標準インフラ上でアカウント運用を始め、ユーザー発見やエンゲージメントの仕組みに慣れることが先決だ。自社インフラへの移行は、法令遵守やデータ主権の要請が具体化した段階で検討すれば十分間に合う。
モデレーション方針の変更リスクは織り込んでおくべきだ
一方で、Bluesky社のモデレーション方針や検索・おすすめアルゴリズムの変更は、事業者の情報到達範囲に直接影響する。これは特定のSNSプラットフォームに依存するリスクと本質的に同じであり、「分散型だから安心」とは言えない。情報発信を一つのチャネルに依存させず、自社サイトやメールマガジンなど、プラットフォームに左右されない接点を並行して維持しておくことが、引き続き有効なリスク分散策となる。
技術部門には「将来の移行コスト」を試算させておく価値がある
エンジニアリング部門には、今のうちにATProtoのデータ構造とPDS移行の手順を把握させておくことを勧めたい。規約変更やサービス終了、独自ドメインでの運用強化など、実際に移行が必要になってから調査を始めると対応が遅れる。コストをかけずに知見だけ蓄積しておくという小さな投資が、将来の選択肢の幅を広げる。