はじめに：約束された自律性の空洞化

Bluesky（AT Protocol）は「分散型ソーシャルメディア」として登場し、独自ドメインを使ったDID（分散型アイデンティティ）によって「プラットフォームに縛られない自由」を約束した。@yourname.comというアイデンティティを手に入れれば、Twitter/Xのような中央集権的プラットフォームから解放される──そう謳われていた。

しかし現実には、カスタムドメインの設定はBluesky Socialへの課金チャネルとなり、ユーザーが得るのは「見た目の独立性」という記号だけである。インフラの支配権は依然としてプラットフォーム側にあり、「所有権」と「利用権」の混同によって、真の自律性は巧妙に隠蔽されている。

本稿では、ATP/Blueskyの三層構造（ユニットA/B/C）を分析し、現状の構造的欺瞞を明らかにしたうえで、WordPressのような「ミニマル自律ユニット」による真の分散化への道筋を提示する。

第一部：三層ユニット構造と「ユニットB不在」の問題

現状のBlueskyエコシステム

ATP/Blueskyのエコシステムは、理論上は以下の三層構造で成立する：

ユニットA（フルスタック統合型）

  • Bluesky Social（PBC）のような事業者が、PDS（個人データサーバー）、Relay（データ配信）、AppView（表示・検索）、Feed Generator（アルゴリズム）、Labeler（モデレーション）のすべてを垂直統合で提供

  • ユーザーは「利用者」として参加し、プラットフォーム体験を享受

ユニットB（部分インフラ提供型）

  • 特定コミュニティや地域が、RelayやAppViewなどの中間レイヤーを独自運営

  • 複数のPDSを束ね、ローカルなソーシャルネットワークを形成

  • 理論上は「日本語圏Relay」「学術研究者向けAppView」などが想定される

ユニットC（PDS単独型）

  • 個人が自前のサーバーでPDSを運用し、データの物理的所有権を確保

  • ただし、RelayやAppViewへの接続なしには、実質的にネットワークから孤立

決定的な問題：ユニットBの不在

現状では、ユニットBがほぼ存在しない。つまり、ユニットAとユニットCの間には巨大なギャップがあり、中間選択肢が欠如している。この構造的欠陥こそが、Blueskyが「分散型」を標榜しながら実質的には集中型プラットフォームとして機能している根本原因である。

WordPressが成功したのは、「共有ホスティング」という中間レイヤーが豊富に存在したからである。技術的知識が乏しい個人でも、月数百円で独自ドメインを持ち、カスタマイズ可能なウェブサイトを運用できる。一方、Blueskyでは「Bluesky Socialを使うか、自分でインフラをすべて構築するか」という二択しかない。

第二部：DIDという「シンボリック自律性」の欺瞞

独自ドメインは何をもたらしたか

ATPの設計思想の核心には、「独自ドメインをDIDとして使用することで、プラットフォーム非依存の永続的アイデンティティを獲得できる」という約束がある。しかし実態を観察すると、以下の構造が見えてくる：

表向きの約束

  • @yourname.comという独自ドメインが分散型アイデンティティとして機能

  • プラットフォームを跨いで移行可能な「ポータブルID」

  • データ所有権のユーザーへの返還

実際の実装

  • カスタムドメイン設定はBluesky Social経由で年額課金（ただし、自前で用意することも可能）

  • ドメインを持っていても、PDS/Relay/AppViewの選択肢は実質的に存在しない

  • bsky.socialから離脱すると、ネットワークから実質的に切断される

  • 移行先のインフラ（ユニットB）が存在しないため、ポータビリティは机上の空論

つまり、ユーザーが購入しているのは「@yourname.comという文字列」というシンボルであり、その背後にあるべき「自律性」「選択の自由」「ポータビリティ」はすべて空約束なのである。

Emailとの決定的な差異

この欺瞞性は、Emailと比較すると一層明確になる：

Email：実質的な分散化

  • 独自ドメイン + MXレコード設定で、自前のメールサーバーを持てる

  • Gmail、自社サーバー、レンタルサーバーなど選択肢は豊富

  • 移行コストは低い（DNS変更のみ）

  • プロバイダ間でメッセージは相互運用可能

Bluesky：名目的な分散化

  • 独自ドメイン + DID設定で、「自律性」を得たように見える

  • しかし実際のRelay/AppView選択肢はゼロ

  • 移行先が存在しないため、実質的にロックイン

  • データの「所有権」はあるが、「利用権」はプラットフォーム依存

Emailは「各組織が独自サーバーを持ちつつ、相互送信可能」という真の連合型システムを実現している。一方、Blueskyは「データレイヤーの分散」を強調するが、「計算レイヤーの集約」によってユーザーは依然としてプラットフォームに従属している。

「所有権」と「利用権」の混同

ATPの設計における根本的欺瞞は、「所有権」と「利用権」を意図的に混同している点にある：

  • 所有権は名目的：PDSに自分のデータがあっても、Relayを通さなければネットワークに配信されない

  • 利用権はプラットフォーム依存：AppViewがなければデータは「見えない」

  • 移行権は理論上のみ：移行先（ユニットB）が存在しないため、ポータビリティは空文句

これは、「あなたは自分の家を所有していますが、道路と水道と電気は一社独占で、引っ越し先の土地は存在しません」と言われているようなものだ。形式的な所有権は与えられているが、実質的な利用可能性はプラットフォームに握られている。

第三部：真の分散化への道──「WordPress型エコシステム」の構築

ユニットBを成立させる三つの条件

Blueskyが真に「分散型」となるためには、ユニットB（部分インフラ提供型）が実効的なエコシステムとして成立する必要がある。そのためには、以下の三つの条件が不可欠である：

1. 技術的参入障壁の劇的な低減

現状のRelay/AppViewは、企業規模のインフラを前提としている。これを「個人がレンタルサーバーにWordPressを構築する」レベルまで引き下げる必要がある。

具体的には：

  • Docker Compose一発で起動する標準構成：PDS + 軽量Relay + 軽量AppView + リバースプロキシをワンセットに

  • ストレージ肥大化の防止：差分同期 + TTLベースの自動削除（「最近30日 + 自分の投稿 + ピン留め」のみ保持）

  • 段階的スケーリング：初期は10ユーザー対応、必要に応じて拡張可能な設計

  • メモリ2GB、ストレージ20GB、月間転送量100GB以内での運用実証

2. 経済的持続可能性の組み込み

ユニットBが長期的に運営されるためには、適切な収益モデルが必要である。ボランティアベースでは限界がある。

実現可能なモデル：

  • 協同組合型運営：「月100円 × 100人 = 月1万円」で小規模Relay/AppViewを維持

  • マイクロペイメント層：プリペイドクレジット方式（「100円で100GB帯域 + 1万投稿分のインデックス」）

  • パブリックグッズとしての助成：大学図書館、研究機関、NGOが公共インフラとして運営（研究助成金の活用）

  • 専門特化型の課金：「学術論文特化AppView」「写真特化AppView」など、付加価値で差別化

3. 「ローカルファースト + グローバル検索はオプション」の設計思想

すべてのユニットがすべてのデータを持つ必要はない。むしろ、「自分たちのコミュニティ内では完結」しつつ、必要に応じて外部に接続する、というハイブリッドモデルが現実的である。

階層的縮退モデル：

  • レイヤー1：Personal Pod（PDS + ローカルキャッシュ型軽量AppView）

  • レイヤー2：Community Relay（地理的/テーマ的クラスタ単位での部分Relay）

  • レイヤー3：Federated Index（オプトイン型の横断検索）

近傍優先の段階的フェデレーション：

  • デフォルトはローカルファーストタイムライン（同じCommunity Relayに接続する数十〜数百ユニット）

  • 「橋渡しユニット」（voluntary bridge nodes）が異なるクラスタ間を疎結合で接続

  • グローバル検索は「コミュニティ図書館モデル」：信頼できる第三者がインデックスサービスを提供し、個人ユニットは必要に応じてクエリを投げる（push型ではなくpull型）

ユニットBの具体的類型

実装の方向性を具体化するため、ユニットBの類型を以下のように整理できる：

B1: コミュニティRelay + 共有AppView型

  • 特定テーマ/地域コミュニティが運営（例：「日本語圏Relay」「学術研究者向けRelay」）

  • 接続PDS：数十〜数百（メンバーシップ制）

  • 運営形態：協同組合、NPO、大学サークル

B2: マネージドPDS + 軽量AppViewホスティング型

  • 「Bluesky版レンタルサーバー」

  • ユーザーは自分のPDSを持つが、インフラ管理は委託

  • 料金例：「月500円でPDS + 基本AppView + カスタムドメイン」

B3: 専門AppView + プラグインRelay型

  • 特定用途に特化（学術論文共有、写真SNS、長文投稿など）

  • 既存Relayからデータ取得 + 独自フィルタリング/UI

  • 例：「arXiv風Bluesky」「Instagram風Bluesky」「Medium風Bluesky」

技術的ブレイクスルーの方向性

ユニットBを実現するための技術的課題は、以下のアプローチで解決可能である：

「選択的購読」アーキテクチャ

  • Relayは「フルfirehose購読」ではなく、特定DIDリスト、ハッシュタグ、言語フィルタによる部分購読を標準サポート

  • AppViewは「完全インデックス」ではなく、「部分インデックス + キャッシュ戦略」

協調型インフラシェアリング

  • 複数のユニットBがRelay負荷を分散：地理的ロケーション、時間帯、トピック別に自動ルーティング

  • DHT（分散ハッシュテーブル）的な検索：「投稿ID → どのAppViewが持っているか」を効率的に解決

軽量化のための技術スタック

  • リポジトリの差分同期：ATPのcommitベースの設計を活用し、BitTorrent的なpeer-to-peer chunking

  • Bloom filterによる軽量ルーティング：全データを持たずに確率的インデックス

  • WASMベースのクライアントサイド処理：フィードアルゴリズムやモデレーションロジックをブラウザ側で実行

第四部：実装への段階的ロードマップ

フェーズ1：ユニットB-miniの標準リファレンス実装

目標：技術者コミュニティが「週末プロジェクト」として立ち上げられるレベルの簡易実装

成果物：

  • docker-compose.yml一発で起動する「10ユーザー対応Relay + AppView」

  • 初期設定はconfig.yamlで「購読するPDSリスト」「連携する他ユニットB」を指定

  • メモリ2GB、ストレージ20GB、月間転送量100GB以内での運用実証

  • ドキュメント：「Bluesky Unit B 運営ガイド」（Mastodon adminガイドを参考）

期間：3〜6ヶ月

フェーズ2：ユニットB間連携プロトコルの策定

目標：異なるユニットB同士が相互接続し、「小さな世界の集合体」を形成

技術仕様：

  • サーバー間相互フォロー：ユニットB同士が「お互いのローカルタイムラインを部分共有」

  • Gossipプロトコル：「うちのユニットBにはこんなトピックの投稿が多い」という統計情報を交換し、効率的なルーティングを実現

  • Trust/Reputation システム：スパムやハラスメント対策のための分散型評価機構

期間：6〜12ヶ月

フェーズ3：マネージドサービスとしてのユニットB

目標：非技術者でも参加できる「ホスティングサービス」の立ち上げ

ビジネスモデル：

  • 「Bluesky Hosting Co-op」のような協同組合型サービス

  • 料金例：「月300円でPDS + ローカルタイムライン + カスタムドメイン」

  • オープンソースコードベース（ベンダーロックインの回避）

社会的組織化：

  • 技術者コミュニティによる「ユニットB運営ガイド」の整備

  • 法的・財務的な運営ノウハウの共有（協同組合法、非営利法人化など）

  • 国際的なユニットB連合の形成

期間：12〜24ヶ月

おわりに：「分散化ごっこ」を超えて

現状のBluesky Socialは、「分散型」という看板を掲げながら、実際には集中型プラットフォーム + 名目的DIDという、Twitter/Xと本質的に変わらない構造を構築しつつある。独自ドメインの課金は、その欺瞞を覆い隠すための「分散化ごっこ」の対価に過ぎない。

しかし、これはATP自体の設計思想が根本的に誤っているわけではない。むしろ、ユニットBという中間レイヤーが実装されていないという、エコシステム構築の失敗が問題なのである。

WordPressが「共有ホスティング」という中間選択肢によって爆発的に普及したように、Blueskyも「個人がレンタルサーバーにWordPressを構築するレベル」のミニマルユニットと、それらが接続し合うエコシステムを実現できれば、真の分散型ソーシャルメディアへの道が開ける。

それは技術的には可能である。問題は、経済的持続可能性と社会的組織化である。協同組合型の運営モデル、公共インフラとしての位置づけ、そして何よりも「真の自律性」を求めるユーザーコミュニティの形成──これらが揃ったとき、Blueskyの「約束」は初めて現実のものとなるだろう。

「所有権」と「利用権」を混同させる欺瞞を看破し、真の自律性を実装すること。それこそが、次世代ソーシャルメディアへの挑戦である。