AT Protocol考察1：ActivityPub連合との決定的な違いは何か？

※この記事は「AT Protocol入門：プロトコルの背景にある考えを理解する」の続編です。先に前編および中編を読むことをおすすめします。

• 前編「BlueskyがActivityPubを採用しなかった3つの理由」
• 中編「AT Protocol入門：プロトコルの背景にある考えを理解する」
• 後編1「AT Protocol考察1：ActivityPub連合との決定的な違いは何か？」←イマココ
• 後編2「AT Protocol考察2」

前回までのあらすじ

• AT ProtocolはBig Fedi向けのプロトコルであり、巨大プラットフォームを「スピーチ層」と「リーチ層」に分割した
• 主な構成要素は「PDS」「Relay」「AppView」の3つである

後編1では

1. AT Protocolにおける連合の仕組み
2. ActivityPub連合との4つの相違点

について解説します。

前提：連合とは？

アンミカ「連合って200種類あんねん」

「連合（Federation）」とは、独立した複数のシステムが相互に連携し、全体として1つのまとまりを持ったサービスを提供する仕組みを指します。¹

AT Protocolでは、巨大プラットフォームを役割ごとに分割しました。その結果、ActivityPubとは異なり、エコシステム内に複数の連合関係を内包しています。

AT Protocolにおいて「連合」という言葉を使う際には、アンジャッシュのすれ違いコントにならないように、具体的にどの連合を指しているのかを明確にしたほうがよいでしょう。²

本記事では、主に「AppViewから見た連合」に焦点を当てます。

1. AT Protocolにおける連合の仕組み

中編では、AT Protocolの連合を以下のように紹介しました。

AT Protocolでは、データ（PDS）とサービス（AppView）が分離されています。PDSに保存されたデータ（レコード）は、そのデータを作成したサービス以外のAppViewからも利用可能です。

今回は、この仕組みをさらに深掘りします。

レコードの共有とは？

Atmosphere³のアプリケーションが扱うデータは「レコード」という単位でPDSに保存されます。BlueskyのポストやWhiteWindのブログ記事も、すべてレコードです。

「PDSls」というサードパーティーサービスを使用すると、ブラウザ上からPDSにどのようなレコードが格納されているのかを確認できます。たとえば、この記事のレコードはここから見られます。

図：PDSのデータモデル⁴

異なるアプリケーションには、それぞれに最適なデータ形式が存在します。たとえば、Excelは「.xlsx」、Wordは「.docx」、PowerPointは「.pptx」といった形式でデータを保存します。

AT Protocolの大きな特徴は、各サービスが自由に独自のデータ形式を定義し、そのレコードをPDSに保存できる点です。⁵具体例として、Blueskyのポストは「app.bsky.feed.post」という形式、WhiteWindのブログ記事は「com.whtwnd.blog.entry」という形式で保存されます。⁶

各AppViewは、Relayを通じて受信したデータから自身に必要な情報を選択して利用します。この際、自サービスが定義したレコードだけでなく、他サービスが定義した形式のレコードも利用可能です。⁷

この仕組みによって「AppViewの連合」が実現します。

連合の種類

AppViewの連合は、大きく次の2種類に分類できます。

• a) 全レコードの共有
• b) 一部レコードの共有

それぞれの特徴と具体例について、詳しく見ていきましょう。

a) 全レコードの共有（= 代替アプリケーションの作成）

異なるAppView間ですべてのレコードを共有することで、元のサービスと全く同じ機能を備えた「代替アプリケーション」を構築できます。

上図では「Bluesky」「Greensky」「Redsky」が同じデータを共有しています。そのため、例えば「Redsky」で投稿やフォローをすると、その結果は「Bluesky」や「Greensky」を使用しているユーザーにも反映されます。

このような「代替アプリケーションを作成ができる」という事実は、サービスのメタクソ化に対する抑止力になります。

特徴

• 競合性……オリジナルのAppViewとおおむね同一の機能を提供し、同じユーザーニーズを満たすことを目的とする
• 消極的作用……サービスの改悪に対する代替手段を提供することで、マイナスをゼロに戻す作用を持つ

b) 一部レコードの共有

他のサービスが作成したレコードの一部を、自身のサービスに取り入れる方法です。これにより、他サービスのデータを効率的に再利用し、自サービスの価値や利便性を高めることが可能です。

例1：WhiteWind

このブログサービス『WhiteWind』では、右上のプロフィール欄の表示にBlueskyのレコード（app.bsky.actor.profile）を使用しています。また記事下部の「Reactions from everyone」セクションは、BlueskyやFrontpageといったAtmosphere上のサービスで記事が言及された場合に、そのレコードを表示する仕組みです。

図：WhiteWindの記事ページで使用されている外部レコードの例⁸

例2：AT Profile

「AT Profile」は、Vue.jsのテンプレート構文を利用してプロフィールページを作成できるサービスです。このサービスの特徴は、ページ作成時にユーザー自身のPDSに保存されたレコードを直接参照できることです。⁹

図：AT Profileを利用したプロフィール作成例。このプロフィールでは、以下のレコードを使用した

• 「プロフィール」……Blueskyのプロフィール（app.bsky.actor.profile）
• 「最近読んだ本」……Atmosphere上の書籍レビューサイト「Bookhive」に投稿した最新の書評（buzz.bookhive.book）
• 「最新記事」……WhiteWindに投稿した最新のブログ記事（com.whtwnd.blog.entry）

これらのレコードはユーザー自身のPDSから直接取得されているため、仮にサービスのAPIが廃止されたとしても影響を受けません。¹⁰

特徴

• 非競合性……オリジナルのAppViewとは異なるニーズを満たし、相互補完的なサービスを提供する
• 積極的作用……直接的な価値をもたらし、ユーザー体験を向上させる働きを持つ（ゼロからプラスを生む）

主流となる連合はどちらか？

以上の2種類のうち、どちらの連合が主流になるのでしょうか。

現在のAT Protocolをめぐる議論では「代替アプリケーションの作成」が連合のメインであるかのように考える人が多いです。特に、Twitterの改悪が話題になる昨今では、どうしても「競合的な連合」の方が話題に上がりがちです。

しかし、私は「非競合的な連合」こそがAT Protocolにおいて中心的な役割を果たすと考えています。

オープンソースソフトウェアとの類似性

AT Protocolの連合モデルは、オープンソースソフトウェア（OSS）の利用形態とよく似ています。OSSの主な利用形態は以下の3つに分類できます。

1. 依存関係（Dependency）

他者が開発・保守しているOSSをそのまま自分たちのプロジェクトに組み込み利用する方法です。
例：WebアプリケーションがMySQLをデータベースとして使用する、PythonアプリケーションがNumPyなどのライブラリを活用する

2. 非競合フォーク（Non-competitive Fork）

既存プロジェクトのコードを再利用しつつ、元のプロジェクトとは異なる目的や特定用途に特化した新たなソフトウェアを作成する方法です。
例：汎用的ブラウザエンジンを流用してゲーム用ブラウザを開発する

3. 競合フォーク（Competitive Fork）

元プロジェクトのコードを完全にフォーク（分岐）し、元プロジェクトを置き換える競合プロジェクトとして再開発する方法です。
例：MySQLとMariaDBの分裂、OpenOfficeからLibreOfficeへの競合的フォーク

実際のオープンソース利用シーンでは、「依存関係」や「非競合フォーク」が圧倒的に主流です。競合フォークは、プロジェクトの将来像や方向性に関する根本的な対立が発生した場合などに、例外的に行なわれます。¹¹

図：OSS利用形態の頻度

AT Protocolの連合も、同様のことが予想されます。つまり、日常的に行なわれる連合はフィールド拡張¹²や一部レコードの共有といった「非競合的な連合」が中心であり、すべてのレコードを共有するような「競合的な連合」が行なわれるのは、メタクソ化が発生した場合などの例外的状況に限定されると考えられます。

2. ActivityPub連合との4つの相違点

ここからは、ActivityPub（フェディバース）とAT Protocolによる連合モデルの違いを4つの観点から整理します。

a) 連合の仕組み：「メッセージ指向」と「データ指向」

まず、両者は連合を実現する仕組みに根本的な違いがあります。

ActivityPub：メッセージ指向

ActivityPubでは、インスタンス間でアクティビティを配送することで連合を実現します。このようなメッセージ送信を基盤とする連携方式は「メッセージパッシング」と呼ばれます。

メッセージパッシングでは、データを各インスタンスに個別配送します。そのため、相手ごとの細かなアクセス制御を得意とします。

AT Protocol：データ指向

これに対してAT Protocolでは、各ユーザーがPDSに保存したデータ（=レコード）を複数のAppView間で共有することによって連合を実現しています。この方式は特に決まった呼び方があるわけではありませんが「共有ヒープ」と呼ばれることが多いです。

共有ヒープでは、すべての更新データがRelayに集約されます。¹³そのため、中編で述べたような「グローバルビューの提供」や「スケーラビリティ」の面でメリットがあります。

LSUDsとしての特性

「データをどこで情報に変換するのか」という観点からも比較してみましょう。情報処理の世界では「データ（Data）」と「情報（Information）」は異なる用語として扱われます。「データ」は単なる事実の値であり、データを加工して意味のある目的を持たせたものが「情報」です。

AT ProtocolではRelayにデータを一元的に集約するため、利用者側でデータから情報への変換が行ないやすいです。たとえば、WhiteWindでは記事の投稿データ（com.whtwnd.blog.entry）とBlueskyの投稿データ（app.bsky.feed.post）を組み合わせて「記事に対するリアクション」という新たな情報に変換しています。

開発者向けにWeb APIの設計で例えると、AT Protocolのほうがより「LSUDs (Large Set of Unknown Developers)」¹⁴としての特性が強いといえるでしょう。

b) 非中央集権性の獲得手段：「分散」と「敵対的相互運用性」

フェディバース¹⁵とAT Protocolでは、非中央集権性（Political Decentralization）¹⁶を得るために異なるアプローチを採用しています。

Fediverse：アプリケーションの分散

フェディバースでは、アプリケーションの水平分散によって非中央集権性の獲得を目指します。

一言でいうと「普段からプラットフォームを分散しておく」のがフェディバースの戦略です。

Atmosphere：アプリケーションの相互運用

一方AT Protocolでは、データのホスティングは普段から分散しますが、アプリケーションは分散しません。その代わり、アプリケーションを相互運用可能にすることで非中央集権性の獲得を目指します。

一言でいうと「有事の際に代替プラットフォームを作成できるようにしておく」のがAT Protocolの戦略です。

まとめると

• フェディバースはアプリケーションを水平に分散する
• AT Protocolはアプリケーションを垂直に分割し、それぞれに敵対的相互運用性をもたせる

といえます。

c) 連合目的：「コミュニティ群の形成」と「エコシステムの構築」

連合の目的も大きく異なります。

Fediverse：コミュニティ群の形成

フェディバースでは、主に似た機能性を持つサービス同士が連合し、1つの抽象的なソーシャルネットワーク空間を構築します。各プラットフォーム（インスタンス）には所属の概念があり、ユーザーは自身の価値観に合ったコミュニティを選んで参加できます。

フェディバースの主目的はコミュニティの形成であり、サービス間の差別化は「運営ポリシー」や「コミュニティの文化」といった人的側面を重視することが多いです。そのため、まったく同じソフトウェアを使用したインスタンスが複数存在することも珍しくありません。たとえば、Mastodonを運用するサーバーは2025年3月時点で8000以上存在します。¹⁷

Atmosphere：オープンエコシステムの構築

これに対してAT Protocolでは、主に異なる機能性を持つサービス同士が連合し、データ共有を通じてエコシステムを形成します。プラットフォーム（AppView）には所属の概念はなく、1つのIDで複数のサービスを利用します。

AT Protocolの主目的はオープンエコシステムの構築であり、サービス間の差別化は「機能性」などのソフトウェア的な特性に基づくことが多いです。そのため、まったく同種のソフトウェアを用いた複数サービスを併存することが一般的ではありません。たとえば、2024年に登場したAppViewは、ブログプラットフォームの「WhiteWind」リンクアグリゲーターの「Frontpage」お絵描き掲示板の「PinkSea」など、それぞれ異なる機能を提供しています。

このように、AT Protocolでは1つのAppViewでサービスを完結するのが原則であり、完全に同一機能のAppViewが複数同時に存在するのは例外的な状況と言えます。

余談：AT Protocolにおけるコミュニティ形成

AT Protocolは「コミュニティの形成」を直接的な目的としているわけではありませんが、ユーザーの棲み分けを補助する仕組みが備わっています。それが中編で紹介した「フィードジェネレーター」と「ラベラー」です。これらを活用することで、ユーザーは自分の好みや価値観に応じたコンテンツの閲覧環境を構築できます。

d) 連合参加のインセンティブ：「直接ネットワーク効果」と「間接ネットワーク効果」

開発者が連合へ参加する動機も異なります。

Fediverse：直接ネットワーク効果

直接ネットワーク効果とは、利用者数の増加に伴い、そのサービス自体の価値が直接的に高まることを指します。電話やSNSが代表例で、ユーザーが増えるほど連絡を取れる相手が増加し、コミュニケーションや情報共有の価値が向上します。

フェディバースでは、インスタンスの枠を超えたコミュニケーションを可能にすることで、この直接ネットワーク効果の最大化を目指します。

Atmosphere：間接ネットワーク効果

間接ネットワーク効果は、補完的なサービスの価値が増えることで間接的にそのプラットフォームの価値も向上する現象のことを指します。典型的な例はゲーム機であり、ゲームタイトルが増えるほどゲーム機本体の価値が高まります。

AT Protocolでは、レコード単位の共有を可能にすることで補完的なサービスの創造を促し、プラットフォーム全体の価値を間接的に高めることを意図しています。

後編1のまとめ

以上がActivityPubとAT Protocolの違いです。両者は「連合」という共通の用語を使用していますが、その設計思想には明確な違いがあります。²¹⁸

ここで1つの疑問が浮かびます。なぜAT Protocolは、サーバーの境界がそのままコミュニティの境界となるような「フェディバース型の連合モデル」を採用しなかったのでしょうか？

次回の後編2では

• フェディバース型の連合が抱える課題
• AT Protocol型の連合がもたらすメリット
• AT Protocolの欠点

について考察し、AT Protocolがフェディバース型の連合を採用しなかった理由を解明します。

後編2につづく……

---

※この記事は2025年3月21日に書かれました。内容は執筆当時のものであり、現在の情報と異なる場合があります。

Footnotes

1. https://datatracker.ietf.org/doc/rfc9518/
   > federation, i.e., designing a function in a way that uses independent instances that maintain connectivity and interoperability to provide a single cohesive service（フェデレーション、つまり、接続性と相互運用性を維持する独立したインスタンスを使用して、単一の統合されたサービスを提供するように機能を設計すること） ↩

2. 「Federation」という用語はActivityPub型のネットワークモデルと混同され誤解を招く恐れがあるため、別の表現を用いるべきではないかという議論があります。BlueskyチームのPaul氏は「インターネクション（Internection）」という造語を提唱していましたが、記事執筆時点（2025/3/21）で公式採用には至っていません。 ↩ ↩²

3. AT ProtocolによるエコシステムをAtmosphereと呼びます。カタカナで「アトモスフィア」と書くとニンジャスレイヤー感がスゴイタカイので、この記事では"Atmosphere"表記で統一します。 ↩

4. リレーショナルデータベースに例えると、PDSはデータサーバー、Repositoryはユーザーごとのデータベース、Collectionはテーブル、そしてRecordはレコードに相当します。 ↩

5. このデータ形式を定義するスキーマ言語を「Lexicon」と呼びます。Lexiconでは、レコードだけではなくHTTP API（XRPC）のエンドポイントも定義できます。また@atproto/lex-cliのパッケージを使用することでLexiconからのコード生成も可能です。 ↩

6. Lexiconの識別には、リバースドメイン形式のNSIDを使用します。 ↩

7. 今後の改善として「User Intents」の導入が検討されています。これは、検索エンジンのクローラーにおけるrobots.txtのように、ユーザーが自身のレコード再利用に関する意思表示を宣言できる仕様です。例えば、自分の公開データが生成AIのトレーニングに使用されることを望まない場合、アプリケーションからそのような意向（インテント）を設定できるようになります。 ↩

8. WhiteWindの仕様・レイアウトは記事執筆時点（2025/3/21）のものあり、今後変更される可能性があります。 ↩

9. AT Profileは、この記事執筆時点（2025/3/21）ではBeta版となっており、仕様は今後変更される可能性があります。 ↩

10. 厳密な話をすると、画像や動画などのメディアファイルはレコードではなくBlobに保存されます。Blobはセキュリティやパフォーマンス上の理由からWebアプリケーションからの直接アクセスが推奨されておらず、代わりにCDNを介したプロキシを利用することが一般的です。現在、多くのAppViewはBluesky社のCDNを利用していますが、お絵かき掲示板のPinkSeaのように独自のCDNを運用しているケースも存在します。 ↩

11. http://hdl.handle.net/10138/153135 論文内で指摘されているように、競合フォークと非競合フォークは明確に二分されるものではなく、連続的な尺度であることには注意が必要です。 ↩

12. レコードには、Lexiconで定義されていないフィールドを自由に追加可能です。たとえば「TOKIMEKI」など一部のBlueskyクライアントでは、Postレコードに独自のviaフィールドを追加し、投稿者がどのサードパーティークライアントを使用したのかを判別できるようにしています。なおフィールド名には他のものと衝突しないようにNSIDの使用が推奨されています。 ↩

13. 厳密な話をすると、AppViewはPDSを個別に直接購読できます。そのため、Relayを使用したデータの集約が必須ではありません。 ↩

14. https://thenextweb.com/news/future-api-design-orchestration-layer ↩

15. フェディバースという用語には、以下の3つの異なる解釈があります。

    • 狭義の立場……フェディバースは、ActivityPubプロトコルを使用する連合型ソーシャルプラットフォームのみを指します。この見解では、ActivityPub以外を使用するプラットフォームはフェディバースに含まれません
    • 広義の立場……フェディバースは、共通のプロトコルを介して通信するすべての連合型ソーシャルプラットフォームを指します。この場合、ActivityPub以外のプロトコルであっても、ソーシャル機能があればフェディバースに含まれます
    • 最広義の立場……フェディバースは、フェデレーションを行なうすべてのものを指します。この見解では、XMPPや電子メールなどもフェディバースの一部と見なされます
      
      前編と中編に引き続き、本記事では「狭義の立場」に基づき、フェディバースという用語を「ActivityPubを使用した連合型プラットフォームのみ」を指すものとして使用します。
    ↩

16. あのちゃん「Decentralizationはさすがに1種類ですよね？」アンミカ「Decentralizationは300種類ある」
    前編と中編に引き続き、この記事における「非中央集権」と「分散」という用語は、イーサリアム創設者であるVitalik Buterin氏の記事「The Meaning of Decentralization」を参考に、以下の定義で使用します。

    • 非中央集権（Decentralization）…… "Political decentralization" の意味、つまり、システムを構成するコンピュータを何人の個人や組織がコントロールしているかという観点で使用します
    • 分散（Distribution）……"Architectural decentralization" の意味、つまり、システムが何台の物理的なコンピュータで構成されているかという観点で使用します
      
      よく見かける、Paul Baran氏の1964年の論文で使用された定義には従わないので注意してください。
    ↩

17. https://fedidb.org/software/mastodon ↩

18. これは、フェディバースとAtmosphereで異なる連合の定義を採用しているのが原因です。Mastodonのドキュメントでは、Federationという用語をBaran氏の例の図における「（B）DECENTRALIZED」の意味で使用しています。一方Blueskyのドキュメントでは、Federationを「anyone can run the parts that make up the AT Protocol themselves, such as their own server.（AT Protocolを構成するパーツを誰でも自分のサーバーなどで実行できること）」としており、より広義的で原義に近い解釈が採用されています。 ↩