DEEP DIVE: ACTIVITYPUB

ActivityPub：連合型SNSを支えるW3C標準プロトコル

MastodonやMisskeyのような「連合型SNS（フェディバース）」は、単一の中央サーバーではなく、無数の独立したサーバーが互いにメッセージをやり取りすることで1つの巨大なソーシャルネットワークを形作っています。その配送の仕組みを規定しているのがActivityPubです。Actorモデル、inbox/outboxによる配送、HTTP SignaturesとWebFingerによる信頼と発見の仕組み、そして実装間の相互運用の実際までを詳説します。

ActivityPubとは：連合型SNSを支えるW3C勧告

ActivityPubは、2018年1月にW3Cの正式勧告（Recommendation）となった、ソーシャルネットワーキング機能を実装するためのオープンな連合プロトコルです。W3C Social Web Working Groupによって策定され、投稿・フォロー・いいね・共有といった一般的なSNSの振る舞いを、サーバー間で交換可能な標準化されたメッセージとして定義しています。ActivityPub自体はメッセージの「配送」と「アクター間のやり取り」の作法を定める仕様であり、投稿やプロフィールといったデータの語彙は、JSON-LD（JSONにデータ同士の意味的なつながりを付与できる形式）で表現されるActivityStreams 2.0という別のW3C勧告の上に成り立っています。

「連合（federation）」という考え方は電子メールに近く、Mastodonのようなソフトウェアを動かす無数のサーバー（インスタンス）が、それぞれ独立に運用されながら互いに通信し合うことで、全体として1つの巨大なネットワークを形成します。利用者は自分の好みのインスタンスにアカウントを作りつつ、他のインスタンスの利用者ともフォロー・返信・引用といったやり取りができ、この仕組みは連合プロトコル全般の設計思想にも共通する発想です。

Actorモデル：inbox / outbox とActivity / Object

ActivityPubの中心にあるのはActorという概念です。ActorにはPerson（個人）、Group（グループ）、Organization（組織）、Application（アプリケーション）、Service（自動化された機能を持つサービス）といった型があり、いずれも自身のプロフィール情報に加えてinboxとoutboxという2つの特別なURL（エンドポイント）を持ちます。あるActorが何かを投稿すると、それは自分のoutboxに追加されると同時に、フォロワーたちのinboxへ配送されます。逆に、他のActorからのフォロー要求やリアクションは、自分のinboxに届けられます。

Actor同士のやり取りは、すべてActivityというオブジェクトを介して行われます。Activityは「誰が・何を・誰に対して行ったか」を表す動詞的なデータです。代表的なものに、投稿を作成するCreate、更新するUpdate、削除するDelete、フォローするFollowとそれを承認するAccept・拒否するReject、いいねするLike、他人の投稿を自分のフォロワーに再配信するAnnounce（いわゆるブースト・リポスト）、過去のActivityを取り消すUndoなどがあります。Activityが包む対象はObjectと呼ばれ、短文投稿を表すNote、より長い記事のArticle、Image、Video、イベント情報のEventなどがあります。

Actor: Person/Group/Organization/Application/Serviceなどの型を持つ、ネットワーク上で行動する主体。固有のURLで一意に識別され、公開鍵・inbox・outboxなどの情報を持つプロフィールとして表現される。
Activity: Create、Follow、Like、Announce、Undoなど「動詞」にあたるデータ型。誰（actor）が何（object）に対して行った操作かを表す。
Object: Note（投稿）、Article、Image、Video、Eventなど、Activityの対象となる名詞的なデータ。ActivityStreams 2.0語彙で定義される。
inbox: 他のActorから送られてくるActivityを受け取るエンドポイント。フォロー要求や他者の投稿の配送がここにPOSTされる。
outbox: 自分が発行したActivityの履歴が並ぶエンドポイント。クライアントがここに新しいActivityを投稿すると、そのActorの活動として処理される。
Collection: フォロワー一覧やoutboxの中身のように、複数のオブジェクトを順序付きまたは順序なしで束ねる集合型。ページネーションされたOrderedCollectionとして表現されることが多い。

配送の仕組み：サーバー間連合とHTTP Signatures、WebFinger

ActivityPubの仕様は、クライアントとサーバーの間でActivityをやり取りするC2S（Client-to-Server）と、サーバー同士がActivityを配送し合うS2S（Server-to-Server、federation）の2つのプロトコルを定義しています。ただし実際に広く使われているのはS2Sだけで、Mastodonをはじめとする主要な実装の多くは、C2S部分を実装せず、クライアントアプリとの通信には独自のREST APIやストリーミングAPIを用いているのが実情です。

あるユーザーが投稿すると、サーバーはそのユーザーのフォロワー一覧からinbox URLを解決し、ActivityをJSON-LDとしてシリアライズしたうえで、各inboxへHTTP POSTで配送します。同じサーバーに複数のフォロワーがいる場合、1件ずつ個別に送るのは非効率なため、Actorオブジェクトのendpoints.sharedInboxで示される共有inboxへ1回だけ送信し、受け取ったサーバー側でローカルの複数フォロワーに配り直すという最適化がよく用いられます。

HTTP Signatures: 送信元のサーバーは、ActorのプロフィールにひもづくRSA公開鍵と対になる秘密鍵で、POSTリクエストのヘッダーに署名する。受信側は公開鍵を取得して署名を検証することで、なりすましを防ぎ、送信元Actorの真正性を確認できる。仕様書としてはIETFの草案（draft-cavage-http-signatures）をベースにしており、ActivityPub本体の仕様には含まれていないが、Mastodonをはじめ主要な実装が「署名なしのActivityは受理しない」運用（authorized fetch／secure mode）を取っているため、事実上の必須要素になっている。
WebFinger（RFC 7033）: メールアドレスに似た@user@example.comという見慣れた形式のハンドルから、example.comの/.well-known/webfingerエンドポイントに問い合わせることで、そのユーザーに対応するActivityPubのプロフィールURL（Actorオブジェクト）を解決できる。異なるサーバー間でユーザーを発見する際の入口として機能する。

実装エコシステム：異なるサービス同士が相互フォローできる世界

ActivityPubを共通言語とすることで、用途の異なる多様なサービスが互いに連合し、ユーザーはサービスの垣根を越えてフォローや返信ができます。

実装	分野	特徴
Mastodon	マイクロブログ	フェディバースで最も広く使われるTwitter/X的なサービス。C2Sの代わりに独自APIを提供する
Misskey	マイクロブログ	日本発。独自の絵文字リアクションなど拡張機能が豊富で、派生実装も多い
Pixelfed	写真共有	Instagramに近いUIを持つ画像中心のSNS
PeerTube	動画共有	ActivityPubで動画のメタデータやコメントを連合し、配信自体はWebTorrentなどのP2P技術と組み合わせる
Lemmy	掲示板・リンク共有	Redditに近いコミュニティ型の掲示板サービス
WordPress（ActivityPubプラグイン）	ブログ	既存のブログ記事をActivityPub経由でフォロー・購読できるようにする
Threads（Meta）	マイクロブログ	2024年以降、段階的に一部地域・アカウントでActivityPub連合への対応を進めている大規模サービス

このようにActor・Activity・Objectという共通の語彙とinbox/outboxという共通の配送経路さえ実装していれば、動画共有サービスの投稿に掲示板サービスのユーザーがコメントする、といった異種サービス間のやり取りが原理上可能になります。

課題と限界

配送のファンアウトコスト: 数万〜数十万フォロワーを持つ人気アカウントが投稿すると、フォロワーが分散する数千のサーバーそれぞれへ個別にHTTP POSTを送る必要がある。sharedInboxによって同一サーバー宛ての重複はまとめられるものの、サーバーの多様性が増すほど配送処理の負荷は増大する。
スパムとモデレーション: 誰でもサーバーを立てて連合に参加できるオープンさは、スパムや有害コンテンツの発生源にもなりうる。多くのインスタンス管理者は、特定サーバーからの受信を一括で拒否する「defederation（連合解除）」やブロックリストで対処しているが、これはネットワーク全体を分断する副作用も伴う。
実装間の方言・互換性問題: ActivityStreams 2.0語彙は拡張可能な設計ゆえに、リアクション機能や引用投稿のような独自拡張が実装ごとにばらばらに追加され、ある実装の機能が別の実装では正しく表示されない、という相互運用性の問題がしばしば起こる。
削除・プライバシー伝播の保証がない: Delete Activityを配送しても、それを受け取ったリモートサーバーが実際にデータを消去するかどうかは相手の実装・運用次第であり、プロトコルレベルでの強制力はない。フォロワー限定投稿のような可視性の制御も、受信側サーバーの善意の実装に依存する。
アカウント移行の弱さ: MoveアクティビティとalsoKnownAs／movedToプロパティを使うことで、旧アカウントから新アカウントへフォロワーを引き継ぐ移行機能は用意されているが、多くの実装では過去の投稿そのものは新アカウントへ移行されず、旧サーバーに残ったままになる。

他の連合型プロトコルとの比較

ActivityPubと似た目的を持つプロトコルとして、Blueskyが採用するAT Protocolと、リレーサーバーを介するシンプルな設計のNostrが挙げられます。ATProtocolはユーザーのデータを本人のPDS（Personal Data Server）にリポジトリとして保持し、アカウントごとポータブルに移行できる点でActivityPubより移行性に優れますが、代わりにアーキテクチャはより複雑です。Nostrは公開鍵ベースの分散型ID的な発想に近い形でActorの同一性を暗号鍵に持たせ、サーバーの代わりに軽量なリレーが中継役を担う、より最小主義な設計を取っています。それぞれの詳細な比較は各ページに譲ります。