0.はじめに：2025年10月の分析から何が変わったか
2025年10月、筆者は「Blueskyの『分散化』は本物か？──DIDの"空"約束とWordPress型エコシステムへの道」と題し、AT Protocolのエコシステムにおける構造的問題を分析した。当時の結論は、ユニットA（Bluesky Socialによるフルスタック統合）とユニットC（個人によるPDS単独運用）の間に位置する「ユニットB」（部分インフラ提供型）が不在であり、これが「分散型」を標榜しながら実質的には集中型として機能する根本原因であるというものであった。
前稿執筆から約3ヶ月が経過した。本稿では、その後の動向を踏まえ、前稿の分析を検証・更新する。結論を先取りすれば、ユニットBの萌芽は明確に確認される。ただし「分散が成就した」とは言い難く、現状は過渡期にある。
1.ユニットBの実現──Blackskyの事例
1.1 独自インフラの構築
前稿では「リレーは企業規模のインフラを前提としている」と述べた。この認識は修正を要する。
Blackskyは、Bluesky PBCに依存しない独自インフラを段階的に構築してきた。Rudy Fraserによる投稿によれば、Blackskyは独自のフルネットワークリレー（atproto.africa）を運用している。これは「from-scratch, full-network relays」として、Sync v1.1準拠で構築されたものである。
出典：https://bsky.app/profile/rude1.blacksky.team/post/3lo7xk2szvs2b
2025年8月のNew_ Publicの記事は、Blackskyの独自インフラをより詳細に報告している。同記事によれば、Blackskyは以下のインフラを独自運用している：
独自リレー（atproto.africa）：毎日数百ギガバイトのデータを同期し、3600万以上のアカウントを追跡する。加えて「moderation relay」を開発し、ネットワーク全体のモデレーション決定を監視している。
独自PDS（blacksky.app）：ユーザーデータをBlacksky独自のサーバーでホストする。ユーザーはBluesky PBCではなくBlackskyの利用規約に同意する。
独自モデレーションサービス：Ozoneの自己ホスト、rsky-labelerによる自動ラベリング、SAFEskiesによるフィード管理を含む。
独自アプリ（blacksky.community）：Blackskyのモデレーションとフィードをデフォルトで提供する。
出典：https://newpublic.substack.com/p/how-blacksky-grew-to-millions-of
1.2 AppViewの独立に向けて
Bluesky公式ブログ（2025年10月）によれば、Blackskyは「full-network Bluesky appview」の開発に取り組んでいる。また、「Cypher」という独自AppViewプロジェクトも進行中であり、「local-only posts」機能の実装が計画されている。
出典：https://docs.bsky.app/blog/protocol-checkin-fall-2025
AppViewが完成すれば、BlackskyはPDS・リレー・AppView・モデレーションのすべてを独自運用することになる。これは前稿で述べた「ユニットB」の完全な実現である。
1.3 rsky：RustによるAT Protocol実装
Blackskyの技術的基盤は「rsky」（/ˈrɪski/）と呼ばれるRust実装である。GitHubリポジトリによれば、rskyはAT Protocolのフル実装を目指しており、以下のコンポーネントを含む：
rsky-relay：フルネットワークリレー
rsky-pds：PostgreSQLベースのPDS（公式TypeScript実装とは異なる設計）
rsky-feedgen：Blackskyコミュニティ向けフィードジェネレータ
出典：https://github.com/blacksky-algorithms/rsky
rskyの存在は、AT Protocolの実装がBluesky PBCの公式実装に依存しないことを実証している。
1.4 前稿の修正
前稿では「ユニットBがほぼ存在しない」と述べた。これは2025年10月時点では正確であったが、2026年1月現在、BlackskyはユニットBの具体的実装として機能している。
ただし注意すべき点がある。Blackskyの成功は、Rudy Fraserを中心とする開発者コミュニティの献身的な努力と、ボランティアモデレーターの存在に依存している。また、Bluesky PBCのプロトコルエンジニアであるBryan NewboldがBlackskyおよびEuroskyの独立インフラ構築に技術協力していることも、筆者がNewbold本人から直接確認した事実である。
つまり、Blackskyの独立は「Bluesky PBCに対抗して」実現したものではなく、「Bluesky PBCの支援のもとで」実現しつつあるものである。この点は、AT Protocolの分散化がプロトコル設計上の意図的な目標であることを示唆している。
2.ガバナンスの進展
2.1 PLC Directoryの独立組織化
前稿では、did:plc方式の単一障害点としてPLC Directoryの集中性を指摘した。この問題に対し、Bluesky PBCは2025年9月、PLC Directoryを独立組織に移管する計画を発表した。
同発表によれば、新組織はスイス協会（Swiss Association）として設立される。スイスが選択された理由は「国際的不確実性の時代において、信頼性があり中立的かつ安定したグローバルな拠点」を提供するためである。
出典：https://docs.bsky.app/blog/plc-directory-org
2025年10月のプロトコルチェックインによれば、Bluesky PBCは弁護士と協力してスイス協会の設立を進めている。また、PLC Directoryのミラーリングを容易にするWebSocket APIの導入も計画されている。
出典：https://docs.bsky.app/blog/protocol-checkin-fall-2025
2.2 IETFへの標準化プロセス
2025年8月、AT Protocolの一部がIETF（Internet Engineering Task Force）にBirds of a Feather提案として提出された。2025年9月には、プロトコルのリポジトリ形式とデータ同期プロセス、およびアーキテクチャ概要に関するInternet Draftsが提出された。
出典：Wikipedia "AT Protocol"（2026年1月16日更新）
標準化プロセスの進展は、AT ProtocolがBluesky PBCの私的プロジェクトから公共財への移行を目指していることを示している。
3.Euroskyと地域主権
3.1 欧州独自インフラの構想
2025年7月、欧州の技術起業家グループは「Eurosky」イニシアチブを発表した。これは政府支援のもと、ソーシャルメディア向けインフラを欧州内に構築し、米国テック企業への依存を低減することを目的としている。
出典：https://www.eurosky.social/
Euroskyの最初の優先事項は「CoCoMo」（Commons for Content Moderation）の構築である。これはATProto上でアプリケーションを構築する開発者やスタートアップ向けの共有モデレーションシステムである。
Open Futureの分析によれば、独立したモデレーションインフラなしには、Euroskyが構築するものはBluesky Social PBCの内部モデレーションシステムに依存し続けることになる。CoCoMoはこの依存を解消するための基盤である。
出典：https://openfuture.eu/blog/eurosky-dawns-building-infrastructure-for-sovereign-social-media/
3.2 前稿の枠組みとの対応
前稿では「ユニットB1：コミュニティRelay + 共有AppView型」の例として「日本語圏Relay」「学術研究者向けRelay」を想定した。EuroskyはこのユニットB1の地域版として位置づけられる。
ただし、Euroskyは2026年1月時点では構想段階にあり、Blackskyのような具体的インフラ運用には至っていない。今後の進展を注視する必要がある。
4.残された課題
4.1 ユーザー分布の偏り
Bluesky公式ブログ（2025年10月）によれば、「99.99%のユーザーはBluesky PBC運営のインフラを使用」している。独立PDSへの移行は技術者コミュニティを中心に進んでいるが、一般ユーザーへの普及には至っていない。
mackuba.euの分析（2025年8月）によれば、サードパーティPDSは約2000存在するが、そのほとんどは小規模である。
出典：https://mackuba.eu/2025/08/20/introduction-to-atproto/
4.2 AppViewの集中
現時点で、フルネットワークAppViewを運用しているのはBluesky PBCのみである。Blackskyが開発中のAppViewが完成すれば状況は変わるが、2026年1月時点では「AppViewの独占」は継続している。
Futurプロジェクトが運用していたZeppelinは、フルネットワークAppViewとして機能していたが、現在は運用を終了している。
4.3 経済的持続可能性
前稿で指摘した経済的持続可能性の問題は未解決である。Blackskyはクラウドファンディングに依存しており、Euroskyは公的資金を期待している。「WordPress型エコシステム」で想定したような商業的ホスティングサービスは、まだ本格的には成立していない。
ただし、Blackskyは2025年12月のアニバーサリー投稿で「blacksky.tech」（ワンクリックインフラデプロイ）の計画を発表しており、PDSやモデレーションサービスのホスティング事業への参入を示唆している。
出典：https://blackskyweb.xyz/anniversary/
5.結論：「萌芽段階」から「過渡期」へ
前稿では、Blueskyの分散化を「分散化ごっこ」と批判した。この評価は部分的に修正を要する。
2026年1月時点で確認される事実は以下の通りである：
ユニットBは実現しつつある：Blackskyは独自リレー・PDS・モデレーション・アプリを運用しており、AppViewも開発中である。
ガバナンスの独立が進んでいる：PLC DirectoryのSwiss Association化、IETFへの標準化プロセスが進行中である。
地域主権の動きが始まった：Euroskyは欧州独自インフラの構築を目指している。
Bluesky PBC自身が分散化を支援している：Bryan NewboldらによるBlacksky・Euroskyへの技術協力は、分散化がプロトコル設計上の意図的目標であることを示している。
他方、以下の課題は残されている：
ユーザーの99%以上がBluesky PBCに依存：技術的可能性と実際の利用状況には大きな乖離がある。
AppViewの独占：フルネットワークAppViewはBluesky PBCのみが運用している。
経済的持続可能性：独立インフラの商業的モデルは未確立である。
総合的に評価すれば、AT Protocolの分散化は「萌芽段階」から「過渡期」に移行しつつある。「分散が成就した」とは言えないが、「分散化ごっこ」という評価も現状には適合しない。
前稿で提示した「WordPress型エコシステム」への道筋は、Blackskyの実践によって部分的に検証された。技術的参入障壁の低減（rsky、Sync v1.1）、コミュニティ主導の運営（Blackskyモデレーションチーム）、そして「ローカルファースト + グローバル接続はオプション」という設計思想（blacksky.communityアプリ）は、いずれも前稿で提案した方向性と合致している。
今後の焦点は、この過渡期がどのような形で収束するかである。Blacksky・Euroskyに続く独立インフラが出現し、ユーザーの選択肢が実質的に拡大するか。あるいは、技術的可能性にもかかわらず、ネットワーク効果によってBluesky PBCへの集中が固定化するか。この問いへの回答は、今後1〜2年の動向によって決まるであろう。