Notation
この記事の執筆にはLLM(Claude Sonnet 4.6)を全面的に利用しています。
三つのプロトコルの現状
AT Proto、ActivityPub（MastodonやMisskeyなどを含む）、Nostrという現在比較的マシな3つの分散型SNSについて、結局どれが一番使われていて今後の発展が期待できますか？変に期待を持たせず、正直にお願いします。
AT Proto（Bluesky）が現時点でリードしています。ただし楽観視は禁物です。
利用者数で見ると、Blueskyは2025年に約60%成長し4,300万アカウントに達しました。ActivityPubはFediverse全体で1,000万超ですが、アクティブユーザーは全体の10〜20%程度とゴーストタウン感が強く、日本ではMisskey系が比較的活発です。Nostrは数百万の鍵ペアが生成されているものの、継続的なアクティブユーザーは数十万以下とみられ、利用者の大半が暗号資産コミュニティに偏っています。
各プロトコルの問題点を整理すると：
| AT Proto | ActivityPub | Nostr | |
|---|---|---|---|
| 実質的な支配 | Bluesky社が握っている | 比較的分散 | 中継サーバーに依存 |
| UX | 良い | サーバー選択が難しい | 悪い |
| モデレーション | 中央頼み | バラバラで一貫性なし | ほぼない |
| 開発の勢い | 現状最も活発 | 停滞気味 | 細々と続いている |
「どれか一つが覇権を握る」未来はおそらく来ないでしょう。Threadsなど大手がActivityPubを部分採用しつつ、Blueskyが手軽な選択肢として共存し、Nostrは暗号資産クラスタの中で生き続ける——という群雄割拠かつ全体として小規模な状態が続く可能性が高いです。「Twitterの代替になる分散SNS」を期待しているなら、今のところ正直どれも力不足というのが現実です。
Nostrの普及可能性
Nostrがこっから一般に普及するのは正直厳しいと思うのですが、どう思いますか？賛成と反対の両方から、同じくらいの重要さの意見を並べてください。
厳しいとの見方が多数派です。反論も含めて整理します。
厳しいと思う理由として、まず秘密鍵管理という根本的なUX問題があります。秘密鍵をユーザー自身が管理するモデルは、一般人には「難しい」どころか「意味がわからない」レベルです。失くしたら終わり、漏れたら終わりという設計は銀行口座より厳しく、これを解決するサービスが出ても、それは結局中央集権化を意味します。
スパム・荒らしへの構造的な無防備さも深刻です。アカウント作成コストがほぼゼロなうえ、グローバルなBANの仕組みがなく、中継サーバーごとにモデレーションがバラバラです。ユーザー獲得の起点もなく、MastodonはTwitter騒動、BlueskyはTwitter難民と明確な流入イベントがありましたが、Nostrにはそれがありません。開発リソースも小さく、クライアントの品質でBlueskyに大きく劣ります。
可能性がある点としては、各国で言論規制が強化されるシナリオでの需要や、SNS以外のインフラ用途（認証・メッセージング等）への転用があります。
結局検閲という点で見ても、いま一番分散が進んでいるのはActivityPub系に思います。SNS以外の用途として見るにも、今度はNostrを経由する通信という技術的な輻輳や信頼性とのバランスが難しいように思います。つまり中央サーバーやP2P・STUNサーバーを超える技術的メリットは薄いように思います。
概ね同意します。検閲耐性という観点では、ActivityPubが現時点で最も成熟した分散インフラを持っています。Nostrが「検閲耐性」を売りにしていても、リレーサーバーへの依存という点では構造的にそれほど変わらず、かつエコシステムの厚みで大きく劣ります。
インフラ用途についても概ね正確な指摘です。「アカウントがどのサーバーにも紐づかない」という点はNostr固有の性質ではありますが、それを実現するための技術的手段として特別に優れているわけではなく、AT ProtoのDIDも同様の問題意識から設計されています。リレーサーバーへの依存という構造はActivityPubと大差なく、かつエコシステムの厚みで大きく劣るという現実は変わりません。
結局アカウントの移行性もNostrに比べてAT Protoの方が一枚上手な気がします。
そうですね。AT ProtoのDID（Decentralized Identifier）をアカウントの根拠に置き、PDS（Personal Data Server）を自分でホストしたり移行したりできる設計は、ActivityPubの「サーバーが消えたらアカウントも消える」問題をより根本的に解こうとしています。Nostrの「秘密鍵がアイデンティティ」というアプローチと目指す方向は似ていますが、UXと実用性のバランスという点ではAT Protoの方が現実的な落とし所を見つけています。
ただし一点留保すると、AT ProtoのPDS移行は設計上は優れていますが、実際に使っているユーザーのほぼ全員がBluesky社のPDSに乗ったままです。現状はBluesky社への集中という点でActivityPubの分散実態に負けています。
つまり：
- 設計思想・移行性の洗練度 → AT Proto
- 現実の分散度・検閲耐性の実態 → ActivityPub
であり、Nostrはどちらの観点でも両者を上回れていない
という整理が正直なところです。
AT ProtoとActivityPubの詳細比較
つまりこの3つの規格争いではAT ProtoとActivityPub系の2つが熱い勝負になりそうですね。両プロトコルの問題点を様々な角度から詳細に列挙した上で、どちらが優勢か教えてください。なお、モデレーション基準がサーバーごとに異なる点はメリットだと考えます。自分に合ったサーバーを選べばいいので。逆にAT Protoは一極集中によって特定のモデレーション基準に従わされるという事件もあり、これはデメリットです。
AT Protoの問題点
Bluesky社への実質的な一極集中が最大の構造的問題です。設計上は分散していますが、現実にはほぼ全ユーザーがBluesky社のPDS・リレー・AppViewに集中しています。
モデレーションの一極集中も深刻です。2025年3月、トルコ政府がBluesky社にアカウントの制限を要求し、Bluesky社が地理的ラベラーを通じて対応しました。トルコ国内ユーザーには63アカウントが非表示になりましたが、公式アプリユーザーにはオプトアウト手段が一切ありませんでした。ActivityPubでは同様の一括要求がかけにくい点と比較すると明確な劣位です。
資金リスクもあります。2025年4月に1億ドルのシリーズBを調達し当面の安定性はありますが、VCから資金を受けているということは将来的な収益化圧力・売却・方針変更のリスクを内包します。プロトコルの標準化も途上で、ActivityPubがW3C標準として長年確立されているのと比べ、IETFワーキンググループのチャーターが公開されたのは2026年1月のことです。(注：現在のActivityPub実装で使われているプロトコルは、W3C標準で確立されたものから、互換性を保ちながらもかなり多くの機能を独自で追加しているという点に留意が必要です。)
AT Protoの強みとしては、アカウント移行性の設計（DIDベース）、アルゴリズム選択の自由（カスタムフィードジェネレーター）、開発速度の速さが挙げられます。
ActivityPubの問題点
アカウント移行性の根本的な弱さがあります。サーバーが消えるとアカウントも実質消え、投稿履歴の移行もできません。LOLAというデータポータビリティの取り組みが2026年時点で主要プラットフォームの50%以上に採用されましたが、まだ発展途上です。
実装の断片化も深刻で、引用投稿・リアクション・投票といった基本機能でさえ実装がバラバラで、真の「相互運用」にはほど遠い面があります。Threadsとの連携も期待外れに終わりました。2025年末にThreadsのFediverse統合は事実上メンテナンスモードに入り、実際に利用したユーザーは極めて少数でした。大手の参入がエコシステムを拡大するという期待が一度大きく裏切られた形です。
ActivityPubの強みは、真の分散の実態と特定企業リスクのなさです。何千ものサーバーが世界中で動いており、一社の倒産・買収でネットワーク全体が消えるリスクがありません。
総合判断
「設計思想・使いやすさ」はAT Proto、「現実の分散度・特定企業リスクのなさ」はActivityPubという構図です。Bluesky社が方針転換・買収・経営悪化した場合、AT Protoのエコシステムは大きなダメージを受けます。ActivityPubにそのような単一障害点はありません。この非対称性は長期的に見て小さくありません。
AT Protoのアーキテクチャと負荷の実態
今私はMisskeyにて自分を含めた少人数が参加する自鯖を建て、運営しています。AT ProtoについてもPDSやリレーを建てるのは面白い行為でしょうか？PDSならともかくリレーを立ててもあまり意味がなかったりしますか？私が建てたリレーって私とは無関係の第三者用に使われたりするんでしょうか？PDSやリレーを建てるのってMisskeyの自鯖ほど面白い行為ではなかったりしますか？
この問いに答えるには、まずAT Protoのアーキテクチャを正確に理解する必要があります。ActivityPubとは根本的に構造が違うからです。
データフローの全体像
ActivityPubは各サーバーが直接通信し合うメッシュ構造です。Misskeyの自鯖が「全部入り」であるのに対し、AT Protoは役割を明確に分離したハブ＆スポーク構造をとっています。
PDS（Personal Data Server）
└─ アカウント管理・投稿データの保存
↓ rawデータをストリーム送信
リレー
└─ 全PDSからデータを集約・署名検証
↓ firehose（1本のストリーム）
Rainbow（fan-outデーモン）
└─ firehoseを多数のコンシューマーに多重配信
↓
AppView・フィードジェネレーター・ラベラー等
└─ タイムライン構築・検索索引・モデレーション判定
PDSを建てると、自分（や招待した人）のアカウントデータを自分のサーバーで管理できます。Blueskyアプリから普通に使えつつ、データの主権が自分にあるという状態になります。ただしMisskeyの自鯖のようにUIをカスタマイズしたり、ローカルタイムラインでメンバーと交流したりという運営の楽しみはなく、あくまで「データの置き場」としての性格が強いです。
リレーについては、正直なところ個人・少人数用途ではほぼ意味がありません。リレーは全PDSのデータを集約してAppViewに流すためのインフラであり、Bluesky社のリレーが事実上ネットワーク全体をカバーしている現状では、あなたのリレーに誰かが能動的に切り替える動機がほぼありません。
リレーの負荷
ふと思ったんですがAT Protoのリレーってかなり負荷が大きくないですか？Misskey.ioはActivityPubから見ればそんなに大した割合を占めてはいませんが、連合処理にかなりの負荷が掛かって問題になっています。AT Protoのリレーの分散って将来的に見込めますか？ActivityPubの連合の仕組みが良くないだけだったりするのでしょうか？
Misskey.ioで連合処理が問題になる理由はActivityPubのメッシュ構造にあります。サーバー同士が直接通信し合うため、規模が大きいサーバーほど全方位から通信が集中します。AT ProtoはリレーというハブにPDSが集約する設計なので、PDS単体の運用コストはActivityPubより低く抑えられます。ただしその分、リレーへの負荷集中という別の問題があります。
2024年11月のブラジルTwitter難民流入時、firehoseのトラフィックは平常時の24GB/日から232GB/日へ約1,300%増加しました。毎秒2,000イベントを超える持続的なトラフィックと、数百の同時接続コンシューマーへの配信が重なり、1台では処理しきれなくなりました。
この問題への対処として導入されたのがRainbow（fan-outデーモン）です。リレーのボトルネックは「全PDSからの入力（集約側）」ではなく「多数のコンシューマーへの出力（配信側）」にありました。Rainbowがリレーからの1本のfirehoseを受け取り、多重配信を担うことで、リレー本体の負荷を分離できるようになりました。
Sync v1.1（2025年5月）ではリレーが全ネットワークのリポジトリデータをミラーする必要がなくなり（non-archival化）、ディスクI/Oの要件が大幅に改善されました。この変更を受けて「月34ドルのVPSでフルネットワークリレーが動く」という情報が広まりましたが、これには重要な文脈があります。
毎秒2000投稿の通信にかかる処理性能や通信量を大雑把に計算してみてください。月間数千円のVPSに収まるとは到底思えません。
「月34ドルのVPSで動く」という数字は2025年8月にBluesky社エンジニアが実験的に試した最小構成の話で、かつその時点のネットワーク規模は現在より大幅に小さかったという文脈があります。
30Mbpsで600イベント/秒なら1イベントあたり約6KBという計算になります。これは投稿テキスト・メタデータ・Merkle treeのノードを含むCBORエンコードデータとして妥当なオーダーです。しかし「30Mbpsの帯域」という数字はリレーからRainbowへの1接続あたりの数字です。リレーはRainbowに1本だけfirehoseを渡し、数百のコンシューマーへの多重配信はRainbowが担います。コンシューマー数×イベントレートに比例してRainbowの帯域が必要になります。
Bluesky社の本番リレーの実際のインフラコストは公開されていませんが、4,300万ユーザー規模を支えるためのコストは実験値と桁が違うはずです。
AppViewが最も重い
最も重いコンポーネントはAppViewです。全18.5億レコードの索引構築・タイムライン計算・いいね集計・フォロー関係処理・検索インデックスを担います。TypeScript実装では90レコード/秒しか出ず、Blackskyが独自のRust実装（wintermute）で10,000レコード/秒以上を目標にしているという規模感です。
AppViewって鯖を立てた後の投稿じゃなくて過去まで遡った全投稿を扱うの？
そうです。AppViewは「タイムラインを組み立てる・いいね数を返す・検索する」機能を提供するために、過去の全投稿を索引化している必要があります。たとえ自分のフォロイー100人分のタイムラインしか必要なくても、firehoseは全ネットワークの全投稿が流れてくるので、その中から必要な分だけ選別するための受信・処理コストは全量に比例します。
新規AppView立ち上げ時には、既存の全PDSから過去データを遡って取り込む「バックフィル」という処理が必要です。Tapのフィルタ機能を使えば特定DIDリストや特定コレクション型のイベントだけ受け取ることもできますが、全ネットワーク対象のフルAppViewを個人で運用するのは現実的ではありません。
これらを踏まえた上で、全部自鯖っていうのはどうなんでしょう。環境は一般的なデスクトップパソコンで、回線は平均100Mbps程度です。いやー世界規模のリレーをやって全投稿を見るのは明らかに厳しそうですね。
| コンポーネント | 個人自鯖の現実性 |
|---|---|
| PDS | ✅ 少人数なら十分可能。Misskeyの自鯖と同程度かそれ以下 |
| フルネットワークリレー | ❌ 常時30Mbps以上の持続帯域が必要。100Mbps回線でも他用途との兼用は困難 |
| Rainbow（fan-out） | ❌ フルリレーが前提なので同様 |
| フルAppView | ❌ 18.5億レコードの索引が必要。論外 |
| 部分的AppView（Tapフィルタ） | ⚠️ 特定用途なら検討の余地あり |
| ラベラー | ✅ 比較的軽量。独自コミュニティのモデレーション用途なら現実的 |
PDSだけが個人・小規模コミュニティ向けとして現実的です。AT Protoは役割分担によってPDSの運用コストを下げた代わりに、ネットワーク全体の重い処理を少数の大規模インフラ運営者に依存する構造になっています。Misskeyの自鯖が「全部入りで運営の実感がある」のと対照的に、AT ProtoのPDSは「データを置く場所」としての性格が強く、コミュニティの場としての楽しさはMisskeyの自鯖に遠く及びません。
モデレーション・言論の自由・そして「ユーザー主権」の限界
モデレーションが行われているレイヤーはどこですか？
AT Protoのモデレーションは複数のレイヤーにまたがっています。
PDSのレイヤーでは、アカウントの停止・削除をPDS管理者が実施できます。自前のPDSであれば自分でコントロールできます。リレーのレイヤーでは、PDSレベルでのアカウントban・ドメイン遮断が可能です。ただし現実にはBluesky社のリレーが事実上ネットワーク全体をカバーしており、トルコ政府要請への対応もここで行われました。AppViewのレイヤーでは、ラベラーの判定を受けて実際に非表示・警告表示等を実施します。ユーザーの画面に最終的に反映されるのはここです。
つまりBluesky社はリレーとAppViewの両方を実質的に掌握しているため、モデレーションの影響力がネットワーク全体に及ぶ構造になっています。
ラベラーの仕組みと限界
AT Protoにはラベラーという仕組みがあり、第三者がOzoneというソフトウェアを使って独自ラベラーを運用でき、ユーザーは最大20個のラベラーを購読できます。技術的には分散しており、ゲーム業界ラベラー・Blackskyのラベラーなど複数の独立ラベラーが実際に存在します。
しかし公式アプリ（bsky.app）ではBluesky社のラベラーがハードコードされており、ユーザーはこれをオプトアウトできません。さらにAppViewがBluesky社に一極集中しているため、ラベラーが分散していてもBluesky社の判断が実質的に支配的です。
ラベラーの分散って行われていますか？もし行われていなければ、言論的にかなり厳しいですよね。簡単に言論封鎖ができてしまいます。
ラベラー自体の分散は技術的には起きています。ただし構造的な問題が二層あります。
第一層として、Bluesky公式アプリではBluesky社のラベラーが強制されます。ユーザーはこれをオプトアウトできません。トルコ政府要請の件はその典型例です。サードパーティアプリ（Deer.socialなど）はこの地理的ラベラーに従う義務がなく回避手段を提供しましたが、それはごく少数のユーザーが使う非公式クライアントの話です。
第二層として、AppViewがBluesky社に一極集中しているため、ラベラーが分散していても最終的なフィルタリングはBluesky社の管理するAppViewで行われます。
「データは残るが誰にも見えない」という状態は、実用上は封鎖と変わりません。
「ユーザー主権」の実像
結局守れるのは今までの投稿データだけで、一回制裁を喰らえば、分散したリレー・AppView・ラベラーを使い公式とは異なるクライアントを利用するごく少数のユーザーとしかやり取りできなくなり、実質的にアカウントが使えないということですよね？（他にもフィードの自由度の高さなどの利点はありますが）。そう思うと分散型で特定の権威に集中しないと銘打っておきながら、結局単一の企業が全てを管理している感じが否めません。これって将来的に解決されるのでしょうか？
正確な整理です。「データの主権」という言葉は正確ですが、ネットワーク効果の主権はBluesky社が握っています。データが手元に残っても誰にも届かなければ意味がありません。
ActivityPubと比較すると、ActivityPubはサーバー管理者がモデレーション権限を持ち分散しているためBluesky社のような単一主体による一括制御は構造的に難しく、言論の分散耐性が高いと言えます。
将来的な解決については、改善が見込める部分と構造的に困難な部分が混在しています。リレーの分散は少しずつ現実になっており（microcosm・Blacksky・firehose.networkなど複数の独立リレーが稼働）、PLC directoryの独立組織への移管方針も発表されています。しかしネットワーク効果の集中は技術では解決できません。ユーザーが公式アプリに集中している限り、Bluesky社のAppView・ラベラーが実質的に支配的であり続けます。
統制への対抗と整ったモデレーションの両立はそもそも構造的に相反します。統制に対抗できるということは、悪意ある投稿・スパム・違法コンテンツも止めにくいということだからです。Nostrがその極端な例で、検閲耐性が高い代わりにモデレーションがほぼ機能しません。AT Protoは今後数年にわたってBluesky社のモデレーションに寄った状態が続くと考えられます。2025年9月のチャーリー・カーク氏暗殺後の言及をめぐるモデレーション問題があれほど炎上したのも、Bluesky社の判断がネットワーク全体に直接影響する一極集中ゆえです。
ActivityPubが15年かけても「真の分散」を一般に普及させられていない現実を見ると、AT Protoがより速くその理想に近づけるかは楽観視できません。
PLC directoryについて調べましたが日本語の情報が一切見つかりませんでした。本当に存在するものですか？
実在します。PLC（Public Ledger of Credentials）directoryは did:plc Directory で稼働しているサービスで、AT Protoネットワーク上のほぼ全アカウントのDID情報（どのPDSにいるか・ハンドル・公開鍵等）を管理する中央サーバーです。Bluesky社が独自開発したDID方式で、2024年10月時点で1,200万以上のDIDが登録されていました。日本語情報がほぼ存在しないのは単純に日本での認知度が低いためです。AT Protoの根幹インフラとして実在し、2025年9月にBluesky社はこの運用をスイス法人の独立組織に移管する方針を発表しましたが、現時点では移行途中です。
自分のブリッジアカウントを確認してみたら
ActivityPubの自鯖のメインアカウントのbrid.gyによるブリッジ先（AT Proto側）のアカウントをbsky.appで見たところ「見つかりません・アカウントは停止されています」と出ています。このアカウントの状態を詳しく見られるサイトはありますか？
bsky.app以外に登録不要でアカウントの状態を確認できるサイトがいくつかあります。
atproto.at：ハンドルかDIDを入れると、PDSに保存されている生のリポジトリデータが見られます。Bluesky社のAppViewを通さないのでラベラーによる停止状態に関係なく、データの存在自体を確認できます。plc.directory/[DID]：DIDの情報（どのPDSにいるか、ハンドル等）が確認できます。internect.info：ハンドルかDIDで検索できます。
もしatproto.atでデータが見えれば「データは存在するがBluesky社のAppView・ラベラーによって公式クライアントから隠されている」という状態の確認になります。
このようなラベルが付いていました。
!takedown Active by @moderation.bsky.app・Created 2025年11月30日・System label bridgy Active by @profile-labels.bossett.social・Created 2025年8月28日 time-machine-accident-past Active by @oracle.posters.rip・Created 2025年9月11日 link-account-x-com Active by @dymo.blue・Created 2026年4月3日 general-spam Removed by @labeler.hailey.at・Created 2026年2月8日 needs-review Expired by @moderation.bsky.app・Created 2025年12月18日
!takedown by @moderation.bsky.app（2025年11月30日）が「アカウントは停止されています」の原因です。moderation.bsky.appはBluesky社公式のラベラーで、!takedownはシステムラベルの中でも最も強い停止処分です。公式アプリからは完全に見えなくなります。
bridgy by @profile-labels.bossett.social はBridgy Fedによるブリッジアカウントであることを示す情報ラベルです。これ自体は制裁ではなく識別用です。
general-spam が一度付いて削除されているという履歴は、自動スパム検知に引っかかった可能性を示しています。Bluesky社の自動モデレーションは短期間での大量フォロー獲得・新規アカウントの大量投稿などをスパムと誤検知することが知られており、ブリッジアカウントはその挙動と似た特徴を持ちやすいです。
Bridgy Fed全体をBluesky社が方針として遮断しているという根拠は見当たりません。Bridgy FedのGitHub issueには、ブリッジアカウントが!takedownを受けたが理由が不明で、Bluesky社に問い合わせても「アプリ内で異議申し立てを」と言われるだけで詰んでいるという報告が複数あります。ブリッジアカウントはログイン手段がないため、異議申し立ても実質できません。
なお複数の第三者ラベラー（bossett.social・oracle.posters.rip・dymo.blue等）が独自にラベルを付けていることは、ラベラーの分散が技術的には機能していることの証明でもあります。ただしBluesky社の!takedownという最強ラベルの前では、それらの第三者ラベルは公式アプリ上での可視性回復には何の効力もありません。
別にBluesky側で発信しても昔から反響は無かった（brid.gyを経由するとリプやリアクションが通知されない）ので問題は無いんですが、やっぱ良い気にはなりませんね〜。
実害がないとはいえ、気分は良くないですよね。
「データの主権を持てる」「ユーザーが自由」と言われるAT Protoにおいて、何も悪いことをしていないのに自動システムに引っかかって停止され、ログイン手段もないので異議申し立ても実質できないという状態になっています。Bridgy Fed経由だとリプやリアクションができないという制約もあって、ActivityPub側をメインに使っている場合はBluesky側は実質的に「存在するだけ」の状態だったわけです。その「存在するだけ」のアカウントすら止められているというのは、ここまで話してきたAT Protoの分散の実態を象徴しています。