連合型分散：集中型でも純粋なP2Pでもない、第三の道

SNSやチャットサービスは「1つの企業が全部を運営する集中型」か「サーバーなしで端末同士が直接つながるP2P」のどちらかだと思われがちですが、その中間には、独立した運営者同士が共通プロトコルで緩やかに繋がる「連合型（Federation）」という、実は電子メールと同じくらい長い歴史を持つ第三の道があります。連合というアーキテクチャの仕組みと、Fediverseの実際の姿、そのメリット・課題を詳説します。

集中型・連合型・純分散型：そして連合は新しい発想ではない

インターネット上のサービスは、その運営形態によって大きく3つに分けられます。集中型（Centralized）は単一の組織が単一のサーバー群を運営し、全利用者がそこに接続する方式で、大半のWebサービスがこれにあたります。純分散型（P2P）は中央のサーバーそのものを持たず、利用者の端末同士が直接データをやり取りする方式です。連合型（Federated）はこの中間に位置し、誰でも独立に運営できる複数の「サーバー（インスタンス）」が、共通のプロトコルで相互に通信し合うことで、全体として1つのネットワークを形成します。利用者は特定のインスタンスにアカウントを作りますが、そのインスタンスが他のインスタンスと連合していれば、異なるインスタンスの利用者ともやり取りできます。

連合型の要点は、「単一の巨大なサーバー」でも「サーバーなしの端末間通信」でもなく、複数の自律したサーバーが対等な立場でプロトコルにより相互接続するという点にあります。各インスタンスの管理者は自分のサーバーのポリシー・利用規約・モデレーション方針を独自に定められる一方、外部のインスタンスとメッセージやコンテンツをやり取りするための共通言語（プロトコル）には従う必要があります。

連合というアーキテクチャは、決して目新しい発想ではありません。最も長く運用されてきた連合型システムは、ほかならぬ電子メールです。1982年に標準化されたSMTP（Simple Mail Transfer Protocol、RFC 821）以来、GmailであろうとProtonMailであろうと自前のメールサーバーであろうと、user@domainという宛先さえ分かれば、運営組織の異なるメールサーバー同士がSMTPを介してメッセージを中継し合います。利用者は好きなプロバイダを選んでアカウントを作れますが、メールというサービス自体は特定の1社に属していません。

もう一つの原型がXMPP（Extensible Messaging and Presence Protocol、前身はJabber）です。XMLベースのメッセージングプロトコルとして1999年に開発が始まり、2004年にIETFで標準化されました。2000年代半ばには、Google Talkをはじめとする複数のチャットサービスがXMPPで連合し、異なるサービスの利用者同士が直接メッセージをやり取りできていましたが、Googleは2013年にGoogle Talk（後継のGoogle Hangouts）でのオープンな連合を打ち切っています。この経緯は、連合型システムが技術的に可能であっても、事業者の意思決定ひとつで閉じてしまいうることを示す先例として、しばしば引き合いに出されます。

Fediverse：インスタンスを選び、緩やかに連合する

近年「連合型」という言葉とともに語られるのがFediverse（Federation＋Universeの造語）です。中核となるのが、W3CのSocial Web Working Groupが策定し2018年に勧告として公開したActivityPubというプロトコルです。ActivityPubに対応するソフトウェアであれば、運営組織や実装が異なっていても互いにフォロー・投稿・リアクションをやり取りでき、Mastodon、Misskey、Lemmyなど多様なサービスが1つの緩やかなネットワークを形成しています。

利用者がFediverseに参加する際は、まず1つのインスタンス（サーバー）を選んでアカウントを作ります。アカウントは@user@instance.exampleのように所属インスタンスを含む形式で表され、電子メールアドレスと同じ発想でどのインスタンスの利用者にも到達できます。趣味・言語・モデレーション方針でインスタンスを選べる一方、後から別のインスタンスへ移りたくなることもあり、その場合はアカウント移行の仕組みを使うことになります。

• ローカルタイムライン: 自分が所属するインスタンス内の利用者による投稿だけを表示するタイムライン。
• 連合タイムライン: 自インスタンスの利用者に加え、連合している他インスタンスから届いた投稿もあわせて表示するタイムライン。あくまで自インスタンスに「見えている」範囲の投稿の集合であり、Fediverse全体を横断検索できるわけではない。
• defederation（連合の切断）: インスタンス管理者は、スパムや有害なコンテンツの温床になっている他インスタンスとの通信を個別に遮断できる。これによりコミュニティ単位で望まない相手とのやり取りを拒否できる一方、切断されたインスタンス側の利用者は連合の外に置かれてしまう。

連合型のメリット

• 運営コストの分散: 単一の組織が全利用者分のサーバー費用・運用負荷を負う必要がなく、有志やコミュニティ単位の小規模インスタンスが数多く並び立つことで、全体としてのインフラコストが分散される。
• コミュニティ単位の自治的モデレーション: 各インスタンスの管理者が、自分たちのコミュニティに合ったルールとモデレーション方針を独自に定められる。全利用者に画一的なポリシーを押し付ける中央集権的なプラットフォームとは対照的なアプローチ。
• 単一障害点・単一検閲点の緩和: 1つのインスタンスが停止・閉鎖・特定の国での遮断対象になっても、他のインスタンスとそこに所属する利用者は影響を受けずに存在し続けられる。特定の1企業や1政府がネットワーク全体を停止・検閲することは、集中型サービスに比べて難しい。

連合型の課題

• インスタンス管理者への依存: インスタンスの存続は、多くの場合ボランティアの管理者の善意と資金力に依存している。管理者が運営をやめればインスタンスごとアカウントも投稿も失われるリスクがあり、大企業が提供する集中型サービスの高い可用性とはトレードオフの関係にある。
• defederationによる分断: 前述のdefederationは有害なインスタンスを排除する自治の手段である一方、行き過ぎれば特定のインスタンス同士が事実上の「島」に分かれてしまい、利用者が意図せず一部のコミュニティから隔離される場合もある。
• アカウント・データのポータビリティの限界: 多くの実装はフォロワー関係の移行機能を備えているが、過去の投稿履歴やダイレクトメッセージまで含めた完全な移行は一般に難しく、インスタンスを移るコストは軽視できない。
• 大手インスタンスへの再集中: 誰でもインスタンスを立てられる建前にもかかわらず、実際には利用者数の多い一部の大規模インスタンスにアカウントが集まりやすく、ネットワーク効果によって「連合型のはずが実質的に中央集権に近づく」傾向が指摘されている。この問題への異なるアプローチとして、参加者全体でデータを保持するDHTベースの純粋なP2P設計や、リレーを介して連合するNostr、署名付きリポジトリで自己主権的なデータを扱うAT Protocolなども登場している。

実例と比較：Mastodon・Misskey・Lemmy・Matrix、そして電子メール

Fediverseの代表格であるMastodon（2016年公開、開発者Eugen Rochko）はTwitter的なマイクロブログを、日本発のMisskeyは独自のUIと絵文字リアクション文化を特徴とするマイクロブログを、LemmyはReddit的なリンク集約・掲示板サービスを、それぞれActivityPubで連合する形で提供しています。テキストチャットの領域ではMatrixが、ActivityPubとは異なる独自の連合プロトコル（各ホームサーバーがイベントの追記型グラフを同期し、分散合意に通じる状態解決アルゴリズムで食い違いを解消する方式）によって、複数のクライアント・サーバー実装を横断したやり取りを実現しています。そして電子メールは、これらすべてに先立つ、最も息の長い連合型システムであり続けています。

こうした個別の実装を離れ、アーキテクチャそのものを比較すると、集中型・連合型・純分散型（P2P）の違いは次のように整理できます。

関連ページ

連合型アーキテクチャの考え方は、このサイトで扱う他の技術とも多くの接点があります。Fediverseの共通言語であるActivityPubは、この記事で触れた「共通プロトコルによる相互接続」を具体的なメッセージ形式にまで落とし込んだものです。連合型が抱える再集中の課題に対し、独自の署名付きリポジトリと選択可能なリレーで応じるのがAT Protocolであり、サーバーという単位そのものを持たずリレーの集合だけで成り立つのがNostrです。より純粋な分散型の対極として、中央サーバーなしに参加者全員でデータを保持するDHTも参照してください。また、複数のインスタンス間で矛盾なく状態を一致させる仕組みは分散合意の考え方とも通じています。