2026年における分散型ウェブの現在地

ソーシャルネットワークが実務上「分散型」であるといえるのは、ユーザーがアイデンティティ、データ、フォロワーを失うことなくプロバイダーを乗り換えられる場合である。そしてActivityPub、AT Protocol、Solidはそれぞれ、このテストのうち異なる一部にしか合格していない。

サーバーを選んでいくつかのアカウントをフォローするところまでは簡単だ。しかし、これらのネットワークに付随する語彙(PDS、relay、AppView、Pod、WebID)はあっという間に積み上がっていく。そしてそのどれもが、実際に「移行したい」と思う日が来るまではさほど意味を持たない。

本稿は、今日の分散型ウェブにおいて重要な3つのプロトコルに関するステータスレポートである。それぞれがアイデンティティ、データ、オーディエンスをどうモデル化しているかを説明し、採用状況と仕様面での立ち位置を示し、数値では登録アカウント数とアクティブユーザー数を区別し、最後に「午後の数時間で動かせるサービス」を紹介する。

「分散型」とは実務上どういう意味か

分散型とは、アカウントをホストしている相手のもとを離れ、次の3つを損なわずに別の場所へ移れることを意味する。すなわち、アイデンティティ(人々があなたを識別する名前とその背後にある資格情報)、データ(投稿、メディア、フォロー、設定)、オーディエンス(あなたをフォローし、あなたの発信を受け取り続ける人々)である。このうち1つでも失われれば、その乗り換えは「余計な手間つきのやり直し」でしかない。

以下の各プロトコルは、サーバーの数や誰がソフトウェアを書いたかではなく、このテストに照らして評価する。サーバー数が示すのは冗長性である。この3要素テストが示すのはロックインの度合いだ。

ActivityPubはインスタンス間でどのように連合するのか

2018年1月23日よりW3C RecommendationであるActivityPubは、各サーバーがユーザーのアクティビティを、そのユーザーのフォロワーをホストしているサーバーのinboxへ直接配送することで連合する。すべてのユーザーはinboxとoutboxを持つactorであり、投稿は自分のoutboxへの書き込みとなり、サーバーが各フォロワーのinboxへそのアクティビティをPOSTする。中央インデックスは存在せず、サーバー同士が互いにJSONをプッシュし合うだけである。

Mastodon、Pixelfed、Lemmy、PeerTubeはいずれもこれを実装している。MastodonアカウントがPeerTubeチャンネルやLemmyコミュニティをフォローできるのはそのためだ。

テストに落ちるのはアイデンティティの部分である。@user@instance.example のようなハンドルはインスタンスに属するため、サーバー停止前に移行されなかったアカウントはどこでも復元できない。Mastodonのアカウント移動はMoveアクティビティを送信してフォロワーを新アカウントへ切り替えるが、ドキュメントは「投稿したものはすべて元の場所に残る」ことを明記しており、ダウンロードできるアーカイブを別のMastodonアカウントに読み込むこともできない。テストに照らせば、オーディエンスは計画的な移行なら存続し、データはエクスポートとして部分的に残り、アイデンティティはまったく存続しない。

AT Protocol:ポータブルなアイデンティティと集中したインフラ

AT Protocolでは、ユーザーのアイデンティティはどのサーバーも所有しないDIDであり、投稿・フォロー・プロフィールはPersonal Data Server(PDS)に置かれ、DIDを変えずに別のホストへ移動できる。PDSの上位には、すべてのPDSをクロールして単一のfirehoseを出力するrelayと、そのfirehoseをインデックス化してクライアントが描画するプロダクトを構成するAppViewがある。仕様はBluesky Social PBCが公開・維持している。

ポータビリティには限界がある。公式のアカウント移行ガイドは、これらの手順を「プロトコル本体の外側にあり、後に変更されうるもの」として扱っており、アプリ内フローではなく goat CLIやコミュニティ製ツールを案内している。Blueskyのプロトコルエンジニアであるブライアン・ニューボルドは2025年10月に、アカウント移動は2025年初頭から本番ネットワーク上で機能しているが依然として開発者向けの作業であり、Blueskyが運用するPDSホストは移入されるアカウントを受け付けないと述べている。

第2の留保は運用面である。Blueskyの2025 Transparency Reportによれば、同社は他のどの事業者よりも多くのアカウントを保持しており、大半の人はここでサインアップする。ネットワークの残りは数千のPersonal Data Serverに分散しており、その多くは他者が運用している。Blueskyが運用するrelayとAppViewをネットワークのどれだけの割合が経由しているかを定量化した公式数値は存在しない。批判的な論者は、独立系PDSホストやコミュニティのインフラプロジェクトも依然としてBlueskyが運用するコアサービスに依存していると指摘し、実務上このネットワークは分散型ではないと結論づける者もいる。ただしそれは判断であって計測ではない。テストに照らせば、アイデンティティとデータは設計上プロバイダー変更を生き残り、フォローレコードがDIDを参照しているためフォロワーも付いてくる。しかしPDSより上のレイヤーはおおむね1社のものである。

Solid:コンシューマー市場を欠いたデータPod

Solidは、ユーザーのデータをユーザー自身が管理するPodに保存し、各アプリケーションにアクセス要求を義務づける。WebIDが人物を識別し、PodはRDFリソースを保持するHTTPサーバーであり、認可ルールが許可した時点でアプリがそれらのリソースを読み書きする。プロバイダー変更テストに関して言えば、Solidは3つの中で最もクリーンな設計である。アイデンティティ、データ、アクセスルールのすべてがユーザーの手元にあり、アプリは単なるクライアントに過ぎない。

しかし採用状況は設計に見合っていない。Solid ProtocolはW3C Community Groupのドラフト(v0.11.0、2024年5月12日)であってW3C標準ではなく、TRインデックスを見てもそれ以降新バージョンは公開されていない。それ以前のリリースは0.9.0(2021年12月)と0.10.0(2022年12月)であり、0.12.0の作業はエディターズドラフトに留まっている。アプリが依存する拡張仕様(WebID Profile、Type Indexes、Application Interoperability)もいまだドラフトであり、仕様はWACとACPという互換性のない2つの認可システムを許容していて、サーバーはどちらを実装しても構わない。ツーリングとドキュメントは他の2プロトコルに後れを取っている。

実務上のボトルネックは「どこでサインアップするか」である。solidproject.orgには約15のホスティング型Podサービスが掲載されているが、その多くは小規模ないし実験的なものであり、ティム・バーナーズ=リーが共同創業したInruptは現在、企業向けにエンタープライズ・ウォレット基盤を販売している。Solidアプリ開発者のNoel De Martinは2024年に、コンシューマー向けPod市場の不在こそSolidの最大の足枷だと指摘している。「Solidでログインして」と頼めば、相手はまずプロバイダー探しに送り出され、大半はそこで止まってしまうからだ。

BlueskyとMastodonのユーザー数は?

Blueskyの2025 Transparency Report(2026年1月29日)は、2025年末時点でBlueskyホストおよび独立PDSを合わせて4,141万アカウント(前年の2,594万から増加)を計上している。同社は月間アクティブユーザー数を追跡してはいるが公表していない。同レポートはモデレーションデータを月間アクティブユーザー1,000人あたりで正規化しているが、その分母は示していない。

Mastodonはjoinmastodon.orgのserversページで独自のネットワーク全体の数値を公開しており、インスタンスの統計APIをポーリングするサードパーティのトラッカーもそれぞれの数値を公開している。両者の数字は一致しない。TechCrunchが2026年2月に報じたところでは、Mastodon自身のサイトは月間アクティブ約78万5,000を示す一方、トラッカーは参照先によって約75万から100万までばらついていた。それらのトラッカーは登録アカウント数を約1万サーバーにわたり1,000万前後としているが、休眠サーバーの扱い方の違いによって、トラッカー間で総計が100万以上動くこともある。

Mastodonでは登録数とアクティブ数が一桁違い、Blueskyについてはその比率が不明である。一方のネットワークの登録数と他方のアクティブ数を並べる比較は、異なる量を比べていることになる。

ActivityPub、Solid、Blueskyで何が作れるか

3つのプロトコルはいずれも素のHTTPであり、だからこそターミナルだけで中身を確認できる。

# ActivityPub: resolve a handle with WebFinger, then fetch the actor document
curl -s 'https://mastodon.social/.well-known/webfinger?resource=acct:Mastodon@mastodon.social'
curl -s -H 'Accept: application/activity+json' https://mastodon.social/users/Mastodon

# Solid: read an RDF resource from a pod as Turtle (replace with a real pod URL)
curl -s -H 'Accept: text/turtle' https://alice.example.org/profile/card

WebFingerはRFC 7033でありMastodonエコシステムの慣行であって、ActivityPub自体の一部ではない。Solidサーバーは要求に応じてRDFリソースをTurtleまたはJSON-LDで提供しなければならない。

最も取り組みやすいプロジェクトはBlueskyのカスタムフィードである。Blueskyのカスタムフィードとは、順序付けされた投稿URIのリストを返すHTTPサービスだ。投稿の取得とレンダリングはAppView側が行うため、フィードサービスが投稿コンテンツを保存したり配信したりする必要はまったくない。必要なXRPCルートは2つで、getFeedSkeleton lexiconがパラメータ(feed、最大100のlimit、cursor)とUnknownFeedエラーを定義している。

// feedgen.mjs — run with: node feedgen.mjs
import { createServer } from 'node:http';

const SERVICE_DID = 'did:web:feeds.example.com';
const FEED_URI = 'at://did:plc:yourpublisherdid/app.bsky.feed.generator/weekend';

// A real generator fills this from a firehose consumer or a database.
const POSTS = [
  'at://did:plc:ragtjsm2j2vknwkz3zp4oxrd/app.bsky.feed.post/3jux6xlrdb42v',
  'at://did:plc:ragtjsm2j2vknwkz3zp4oxrd/app.bsky.feed.post/3jux7x2uvip2v',
];

const json = (res, status, body) => {
  res.writeHead(status, { 'content-type': 'application/json' });
  res.end(JSON.stringify(body));
};

createServer((req, res) => {
  const { pathname, searchParams } = new URL(req.url, 'http://localhost');

  if (pathname === '/xrpc/app.bsky.feed.describeFeedGenerator') {
    return json(res, 200, { did: SERVICE_DID, feeds: [{ uri: FEED_URI }] });
  }

  if (pathname === '/xrpc/app.bsky.feed.getFeedSkeleton') {
    if (searchParams.get('feed') !== FEED_URI) {
      return json(res, 400, { error: 'UnknownFeed', message: 'Feed not found' });
    }
    // Requests may carry a JWT signed by the user's key. A feed that is
    // identical for every user can ignore it, as this one does.
    const limit = Math.min(Number(searchParams.get('limit') ?? 50), 100);
    const start = Number(searchParams.get('cursor') ?? 0);
    const page = POSTS.slice(start, start + limit);
    const cursor = start + limit < POSTS.length ? String(start + limit) : undefined;
    return json(res, 200, { feed: page.map((post) => ({ post })), cursor });
  }

  json(res, 404, { error: 'NotFound' });
}).listen(3000);

cursorはAppViewにとっては不透明な値であり、完全にあなた自身のものである。固定リストであれば位置インデックスで十分だが、公式チュートリアルは、投稿がライブインデックス由来になった時点でタイムスタンプ+CIDの複合カーソルを推奨している。本番稼働させるには、HTTPSでデプロイし、ホストを指すDIDドキュメントを公開し(スターターキットはこれをデフォルトでdid:webとして設定する)、そのpublishFeedGen.tsスクリプトを実行して自分のリポジトリにapp.bsky.feed.generatorレコードを作成する。それ以降、フィードは他のフィードと同様にBlueskyアプリ上に表示される。

現在地

プロバイダー変更テストに照らすと、ActivityPubはフォロワーを運べるがアイデンティティは運べず、AT Protocolは書面上は3つすべてを運べるものの、ネットワークの大半は依然として1社のrelayとAppViewを経由しており、Solidは原理的にはすべてを運べるがそれを担うコンシューマー市場が存在しない。自分が許容できる失敗モードを持つプロトコルを選び、そのうえで週末を上記のフィードジェネレーターに費やしてみてほしい。分散型ウェブについて「読む」段階から、その一部を実際に「動かす」段階へ至る最短経路である。

FAQ

BlueskyとMastodonのユーザーは互いにフォローできますか?

ネイティブにはできません。ActivityPubとAT Protocolは相互運用しないため、ネットワークをまたぐフォローはブリッジ経由になります。非営利団体A New Socialが運用するBridgy Fedはオプトイン方式で、Blueskyユーザーは @ap.brid.gy を、Fediverseユーザーは @bsky.brid.gy@bsky.brid.gy をフォローします。ブリッジされたアカウントはBluesky上では user.instance.ap.brid.gy として、Fediverse上では handle@bsky.brid.gy として表示されます。ブリッジされるのは完全公開の投稿のみで、300文字を超えるFediverseの投稿はBluesky側で切り詰められます。

AT Protocolにおける did:plc と did:web の違いは何ですか?

AT Protocolがサポートするのは2つのDIDメソッドのみです。Bluesky Social PBCが開発した did:plc は識別子をPLCディレクトリに登録し、鍵のローテーションとリカバリーをサポートします。公式PDSインストーラーが新規アカウントに対して作成するのもこれです。did:web は自分が管理するホスト名から識別子を導出しますが、パスを含まないホスト名レベルの識別子しか使えず、ドメインを失った場合のリカバリー手段もないため、フィードジェネレーターのようなサービス向けです。

PDSをホストせずに、自分のドメインをBlueskyのハンドルとして使えますか?

使えます。ハンドルはDIDと双方向にリンクされたDNSホスト名であり、そのリンクはデータをどのPDSが保存しているかとは独立しています。DIDは次の2箇所のいずれかで公開します。_atproto.yourdomain という名前のDNS TXTレコードに did= に続けて完全なDIDを記述するか、https://yourdomain/.well-known/atproto-did でプレーンテキストのレスポンスを返すかです。仕様は個人にはDNS方式を推奨しており、HTTPS方式は大規模サービス向けです。

Personal Data Serverを自前でホストしても、Blueskyアプリは使えますか?

使えます。公式PDSは、パブリックなIPv4アドレス、ワイルドカードDNSレコード、80番および443番ポートの開放を備えたVPS向けのDockerイメージとして提供されています。Blueskyは1〜20ユーザーに対してRAM 1GB、ストレージ20GBを推奨しています。アプリで自分のPDSのURLを入力してサインインします。デフォルト設定はBlueskyのAppView、relay、PLCディレクトリを指すため、データレイヤーより上位ではPDSは依然としてBlueskyが運用するサービスに依存します。