DEEP DIVE: AT PROTOCOL

AT Protocol：Blueskyを支える連合型SNSプロトコル

Blueskyというアプリの裏側には、それとは独立して設計されたプロトコル層があります。AT Protocol（Authenticated Transfer Protocol）は「アカウントの移行可能性」と「アプリケーションの分離」を核に据え、署名付きリポジトリとMerkle Search Tree、DIDベースのアイデンティティ、役割の分かれたインフラ群によって、単一事業者に依存しないSNSを目指しています。その設計思想と、実運用が突きつける課題を詳説します。

AT Protocolとは: アカウントの移行可能性とアプリケーションの分離

AT Protocol（Authenticated Transfer Protocol）は、Twitter社内の分散型SNS研究プロジェクトを起源とし、2021年に独立した組織Bluesky PBCが開発を続けている連合型（federated）ソーシャルネットワーキングプロトコルです。同名のアプリ「Bluesky」はこのプロトコルの上に実装されたクライアントの1つに過ぎず、プロトコル自体は他のアプリケーションからも利用できるよう設計されています。設計の中心に据えられているのは、アカウントの移行可能性（account portability）とアプリケーションの分離（application-level decentralization）という大きく2つの理念です。前者は、ユーザーが特定のホスティング事業者に技術的にロックインされず、フォロワーや投稿履歴を保ったまま別のサーバーへ引っ越せることを指します。後者は、同じデータ基盤の上に複数の独立したアプリケーション（タイムラインアプリ、独自フィード、モデレーションツールなど）が競合しながら共存できることを指します。連合型アーキテクチャに共通する「単一の会社がネットワーク全体を止められない」という目標を、AT Protocolはこの2つの理念を通じて実現しようとしています。

アイデンティティ: DIDとDNSベースのhandle

AT Protocolのユーザーは、DID（Decentralized Identifier）という永続的で暗号学的に検証可能な識別子を持ちます。Blueskyがデフォルトで用いるDIDメソッドはdid:plcで、Bluesky社が運営する追記専用かつ監査可能なディレクトリサービス（PLC Directory）が、署名鍵や現在のPDSの所在などを含むDIDドキュメントの更新履歴を保持します。自前のインフラで運用したい場合は、自分のドメイン配下にDIDドキュメントを置くdid:webも選択できます。DIDだけでは扱いづらいため、これとは別に人間可読なhandle（例: @alice.example.com）をDIDに紐付けます。handleはドメイン名そのもの、またはそのサブドメインで表され、DNSのTXTレコード（_atproto.<domain>）やドメイン直下の.well-knownファイルにDIDを記載することでドメインの所有権を証明し、handleとDIDの対応を確立します。この仕組みにより「どのPDSに住んでいるか」と「本人が誰であるか」を分離しつつ、既存のDNSという枯れたインフラを信頼の起点として再利用できます。詳しくはDIDも参照してください。

リポジトリ: 署名付きMerkle Search Tree

各ユーザーのデータ（投稿、いいね、フォロー関係、プロフィールなど）は、そのユーザー専用の署名付きリポジトリにレコードとして格納されます。レコード群はコレクション（Lexiconのスキーマ名、例: app.bsky.feed.post）ごとに整理され、リポジトリ全体はMerkle木のMSTセクションで扱われているMerkle Search Tree（MST）の中に格納されます。ユーザーがレコードを追加・更新・削除するたびに新しいMSTのルートハッシュが計算され、それを含むcommitにユーザーの署名鍵で署名します。この構造により、あるレコードが確かにそのユーザーのリポジトリに存在するという証明を軽量に発行でき、かつ複数のリレー間でリポジトリの差分だけを効率よく同期できます。これはMSTがもともと解決しようとしていた「レプリカ同期」の課題そのものです。署名鍵とは別に、より強い権限を持つrotationキーがDIDドキュメントの更新（署名鍵の入れ替えやPDSの移行先の変更）を担い、署名鍵の危殆化やPDS事業者とのトラブルが起きてもアカウントを保護できるようになっています。

ネットワークを支えるインフラ: PDS・Relay・AppView・Feed Generator・Labeler

AT Protocolは、単一のサーバーがすべてを担う構成ではなく、役割の異なる複数のコンポーネントに機能を分割しています。この分割こそが「アプリケーションの分離」を技術的に可能にしている土台です。

PDS（Personal Data Server）: ユーザーのリポジトリを実際にホストするサーバー。認証やレコードの読み書きを受け持つ。Bluesky社の運営するPDSに置くことも、自分でホストすることもできる。
Relay（firehose）: 多数のPDSを巡回・購読し、ネットワーク全体のリポジトリ更新イベントを1本のストリーム（firehose、subscribeRepos）に集約して再配信する。Bluesky社は大規模なデフォルトRelayを運営している。
AppView: firehoseを消費し、特定のアプリケーション向けにデータを集約・インデックス化するサービス。ソーシャルグラフの構築、タイムラインの生成、通知の作成などはここで行われる。
Feed Generator: 独自のアルゴリズムでフィードを組み立てる、AppViewからは独立した小さなサービス。投稿URIのリスト（スケルトン）だけを返し、実際の投稿内容はAppViewが肉付けする。
Labeler: モデレーション用のラベルをコンテンツやアカウントに付与する、AppViewからも独立したサービス。ユーザーは複数のLabelerを自分の意思で個別に購読できる。

ここで誤解しやすいのが、リポジトリが複数のRelay・AppViewへ複製されるからといって、データそのものが（理念としては）分散しているわけではないという点です。正本（source of truth）はあくまでユーザーが署名したPDS上のリポジトリであり、RelayやAppViewが保持するのはfirehoseから受信したコピー・索引に過ぎません。PDSがレコードを削除すればその削除がfirehose経由でネットワークに伝播し、下流のコピーも追随することが期待されています。この「正本は1箇所」という設計は、違法なコンテンツに対する法的責任の所在を明確にする役割も担っています。各国の法律は一般にホスティング事業者に違法データの削除を求めており、AT Protocolでは正本を保持するPDSの運営者がその要求に応える立場になります。

これらのコンポーネント間のやり取りは、Lexiconというスキーマ定義言語で厳密に型付けされています。Lexiconは各レコード型やAPIエンドポイントを、逆ドメイン記法のNSID（例: app.bsky.feed.post）で名前空間化して定義し、そのスキーマに基づいてHTTP上のシンプルなRPC規約であるXRPC（クエリはGET、プロシージャはPOST）が生成されます。異なる開発者が実装したPDS・AppView・クライアントは、Lexiconという共通の「契約」さえ守っていれば互いに相互運用できます。これがこの分離設計の狙いです。

設計思想の実践と残る課題

この役割分離は、2つの理念的な主張を裏付けています。1つはアルゴリズムの選択（algorithmic choice）です。タイムラインをどのアルゴリズムで並べるかはプロトコルが決めるのではなく、ユーザーが好きなFeed Generatorを選んで購読できます。もう1つはモデレーションの積み重ね（stackable moderation）です。「何を不適切とするか」の判断を単一の運営者に独占させず、複数のLabelerのラベルを個々のユーザーが自分の基準で組み合わせて使えます。どちらも、機能をプロトコルの外に切り出したからこそ可能になっています。

Relay・AppViewの運用コストの偏り: firehoseはネットワーク全体の更新を扱うため、必要な帯域・ストレージ・処理能力は決して小さくない。結果として、実際のトラフィックの大半はBluesky社が運営するデフォルトのRelayとAppViewに集中しがちで、「連合型」を掲げながら事実上の中央集権に近いとの指摘がある。PDSの自己ホストは比較的手軽になってきた一方、独自にRelayやAppViewを運用する事業者はまだ少数にとどまる。
連合の実運用はまだ成熟途上: 複数の独立したAppViewが競合しながら共存する世界観は理念としては語られているが、実際に広く使われているAppViewは現状ほぼBluesky社が提供するものに限られる。
ActivityPubとの直接的な相互運用性はない: データモデルもプロトコルもActivityPubとは異なるため、MastodonなどFediverseとBlueskyは直接連合できない。Bridgy Fedのようなブリッジサービスが両者のメッセージを変換・中継することで、限定的な相互乗り入れを実現している。詳しくはActivityPubを参照。

もっとも、こうした集中への懸念だけがATProtoの実態というわけではありません。2026年4月、Bluesky PBCのサーバーがDDoS攻撃を受けて十数時間にわたり応答不能になった際、公式アプリの停止とプロトコルそのものの停止は別物であることが実地で示されました。Bluesky社のインフラが止まった間も、自前でRelay・AppViewを運営するBlackskyやEuroskyのような互換ネットワークは影響を受けずに稼働を続け、行き場を失ったユーザーの受け皿になったと報告されています。この一件は、PDSは個人でも運用できるほど分散しやすい一方、Relay・AppViewは相応の運用体制を要するため集中しやすいという、AT Protocolの分散性が層ごとに非対称であることを浮き彫りにしました。

こうした特徴は、同じ「非中央集権的なSNS」を志向する他プロトコルと比べると輪郭がはっきりします。