#ActivityPubとATProtoは敵ではない　レイヤー分離論 #七11 #2023JドーシーのBlueSky

この文章の主張を要約すると、**「ActivityPubとAT Protocol（ATProto）は対立する規格ではなく、少しの仕様変更で統合できる可能性がある。そうすれば、分断されたソーシャルメディアをよりオープンでユーザー主権なものにできる」**という提案です。

以下、内容を整理します。

要約

1. 導入：「宗派争いはもうやめよう」

著者はまず、左翼運動で有名なジョークを紹介します。

トロツキストが1人なら党が1つ。
2人なら派閥が2つ。
3人なら党が分裂する。

これは

オープンソース
Mastodon派
Bluesky派
ActivityPub派
ATProto派

などが互いに争っている現在の状況に似ていると述べています。

つまり、

「敵同士になる必要はない」

というのが出発点です。

2. BlueskyとATProtoは違う

ここが最も重要です。

多くの人は

Bluesky = ATProto

と思っています。

しかし実際は

ATProto
    │
    ├── Bluesky
    ├── 将来のSNS
    ├── 写真共有
    ├── ブログ
    └── その他

ATProtoは

「分散型アプリを作るための基盤」

であり、

Blueskyは

「その上に作られた1つのSNS」

にすぎません。

3. ATProto最大の特徴

著者はATProto最大の利点を

PDS（Personal Data Server）

だと言っています。

つまり

ユーザーは

サーバー

ではなく

自分自身

が主体になります。

例えば

Twitter

アカウント
↓

Twitter社が管理

ですが

ATProtoでは

アカウント

↓

自分のPDS

↓

必要なら他へ移動

できます。

つまり

Trusted Exit

（いつでも安全に引っ越せる）

が保証されます。

これはActivityPubより強い特徴だと言っています。

4. ActivityPubの長所

逆にActivityPubは

URL中心

です。

例えば

https://example.com/users/alice

を見ると

Actor Document

というJSONが返ります。

その中には

followers

following

inbox

outbox

などが書いてあります。

つまり

「どこへ送ればいいか」

をURLで教えてくれます。

5. ここが著者のアイデア

普通は

Actor Document

↓

Mastodon API

へ飛びます。

しかし

Actor Document

↓

ATProto PDS

へ飛ばせばいい

という提案です。

つまり

Actor

↓

ATProto

としてしまう。

イメージ

現在

ActivityPub

↓

Mastodon Server

提案

ActivityPub

↓

ATProto PDS

↓

任意のアプリ

6. 実際には何が問題か

著者は

「実は問題は2つしかない」

と言います。

問題① XRPC

ATProtoは

GET

または

POST

しか想定していません。

しかしActivityPubでは

Inboxが

GET

POST

両方必要です。

なので

少し仕様変更が必要。

でも

「大した問題ではない」

と言っています。

問題② ID

ATProtoは

alice.com

みたいなHandleを使います。

ActivityPubは

@alice@mastodon.social

です。

これを相互変換できるようにすればよい。

例えば

@alice@mastodon.social

↓

alice.mastodon.social

↓

DNS

↓

DID

という解決方法を提案しています。

7. なぜやる価値があるのか

現在のSNSは

Twitter

Instagram

Threads

Bluesky

Mastodon

全部バラバラです。

つまり

閉じた島

になっています。

ActivityPubは

Web全部

をSNS化できます。

ATProtoは

ユーザーが完全にデータを持てる

という利点があります。

ならば

ActivityPub

+

ATProto

にすれば

両方の長所を得られます。

著者の結論

著者は

ActivityPubとATProtoは敵ではない

と言います。

そして

両者をつなぐのに必要なのは

XRPCの小さな変更
Handle解決の改善

程度であり、

思われているよりずっと簡単だと主張しています。

この提案の意義

技術的には、この提案は**「アプリケーション層」と「アイデンティティ層」を分離する設計**を目指しています。

ActivityPubは「ソーシャル通信プロトコル（メッセージやフォローをどうやり取りするか）」に優れています。
ATProtoは「アイデンティティ、データ所有、移行性（PDS・DID）」に優れています。

両者を組み合わせることで、

通信はActivityPubの広い互換性を利用し、
ユーザーのIDやデータ管理はATProtoの仕組みを利用する、

という「いいとこ取り」が可能になります。

この提案の課題

一方で、実現にはいくつかの現実的なハードルがあります。

課題	内容
仕様変更	XRPCやDID解決方法の拡張についてコミュニティ合意が必要。
ガバナンス	ATProtoの標準化は進行中であり、互換拡張を誰が管理するかが課題。
実装コスト	Mastodon系・Bluesky系双方でソフトウェア実装が必要。
エコシステム	技術的に可能でも、各コミュニティが採用するとは限らない。

つまり、この提案は「今すぐ簡単に実装できる」というよりも、分散型SNSの将来像として、ActivityPubとATProtoを補完関係として捉え直そうという設計思想（デザイン・プロボケーション）として読むのが適切です。[#Standard・siteとは何か：長文記事をAT Protocol上で扱うための共通スキーマ：分散型プロトコルが拓く表現の永続性とデジタル主権 #ATProtocol #Nostr #六10 #2026五29StandardSiteとATProtocol_令和IT史ざっくり解説](https://buff.ly/Ii8gWsy)この記事は、あなたが先ほど要約した 「ActivityPubをAT Protocol上で動かせないか？」 という議論の延長線上にあります。

ただし焦点はプロトコルではなく、

長文コンテンツをAT Protocolでどう表現するか

にあります。

Standard.siteとは何か

Standard.siteは、一言で言えば

AT Protocol上で長文記事（ブログ・論文・技術記事など）を扱うための共通スキーマ（Lexicon）

です。

つまり、

AT Protocol
    │
    ├── Bluesky（短文SNS）
    ├── Flashes（写真）
    ├── Skylight（動画）
    ├── WhiteWind（ブログ）
    ├── Smoke Signal
    ├── Frontpage
    └── Standard.site（共通記事フォーマット）

という位置づけになります。

重要なのは、

「ブログサービス」ではなく「データ形式」

であることです。

なぜ必要なのか

現在AT Protocolでは、

各アプリが独自Lexiconを定義しています。

例えば

WhiteWind

app.whitewind.post

Smoke Signal

xyz.smokesignal.article

Frontpage

com.frontpage.post

というように、

それぞれ別形式です。

すると

アプリAの記事

↓

アプリBでは読めない

という問題が起きます。

これは

Twitter

Facebook

Medium

WordPress

が互換性を持たないのと同じ問題です。

Standard.siteの目的

そこで

article

title

body

author

summary

tags

license

published

updated

attachments

などの

共通スキーマ

を作ります。

すると

WhiteWind
        │
SmokeSignal
        │
Frontpage
        │
Static Site
        │
CMS

すべてが

同じ記事形式

を読めるようになります。

HTMLではない

重要なのは、

Standard.siteは

HTMLを標準化するものではありません。

むしろ

Markdown

↓

AST

↓

Lexicon

↓

表示

という考え方です。

つまり

コンテンツと表示を分離

します。

これは

ActivityStreams

JSON-LD

と同じ発想です。

WordPressとの違い

WordPressでは

記事

↓

HTML

↓

テーマ

になっています。

Standard.siteでは

記事

↓

構造化データ

↓

好きなレンダラ

になります。

つまり

記事そのものは永続化され、

見た目だけ自由になります。

デジタル主権（Digital Sovereignty）

記事が強調しているのは

Digital Sovereignty

です。

つまり

今まで

Medium

↓

サービス終了

↓

記事終了

あるいは

Substack

↓

規約変更

↓

移転困難

でした。

AT Protocolなら

記事

↓

PDS

↓

所有者＝本人

になります。

つまり

プラットフォームを変えても

記事は残ります。

これは

先ほど読んだ

Trusted Exit

と同じ思想です。

ActivityPubとの比較

ActivityPubは

記事

↓

Activity

↓

配送

が得意です。

AT Protocolは

記事

↓

Repository

↓

永続保存

が得意です。

つまり

役割が違います。

Nostrとの比較

記事ではNostrも比較対象になります。

Nostrは

Event

↓

Relay

↓

保存

という構造です。

非常にシンプルですが、

長文になると

Kind

Tag

Event

だけでは

十分な意味構造を表現しにくいという課題があります。

そのため

Standard.siteは

よりリッチな記事モデルを提供しようとしています。

将来的な構想

理想形は

Markdown

↓

Standard.site

↓

AT Repository

↓

PDS

↓

任意のReader

です。

そして

Bluesky

↓

リンク表示

ブログ

↓

全文表示

検索エンジン

↓

インデックス

AI

↓

RAGデータ

すべて同じデータを利用できます。

この構想の本質

先ほどのRobin Berjon氏の「ActivityPubをAT Protocol上で動かす」という提案が通信・アイデンティティ層の統合を目指すものだったのに対し、Standard.siteはコンテンツ層の標準化を目指しています。

両者を組み合わせると、次のような三層構造が見えてきます。

層	担当	代表技術
アイデンティティ層	DID・PDS・アカウント移行	AT Protocol
通信・配送層	フォロー、投稿配送、通知	ActivityPub（将来的にはATProto実装も可能）
コンテンツ層	長文記事・メタデータ・ライセンス・添付ファイル	Standard.site

この方向性が実現すると、ブログサービスやSNSごとに記事を囲い込むのではなく、**ユーザーが記事そのものを所有し、複数のアプリが共通フォーマットで表示・再利用できる「オープンWebの出版基盤」**へ近づきます。

言い換えれば、Standard.siteは「AT Protocol版HTML」ではなく、AT Protocol時代のWordPress投稿フォーマットやRSS Itemを現代的に再設計した共通記事モデルを目指す試みだと考えると、その位置づけを理解しやすいでしょう。

このCRITICの指摘は、かなり質が高いです。ただし、いくつか補強すると、ブログはさらに一段深くなります。

評価すると、

項目	評価
技術理解	★★★★★
設計思想	★★★★★
標準化の理解	★★★★☆
歴史・政治経済	★★★☆☆
将来予測	★★★★☆

不足しているのは、「なぜATProtoという新プロトコルが必要になったのかをインターネット史の流れの中で位置付ける視点」です。

① 最大の不足：「レイヤー論」

Robin Berjonの記事の本質は、

ActivityPubをATProtoの上で動かそう

ではありません。

もっと抽象化すると

Identity Layer
        ↑
Data Layer
        ↑
Social Protocol Layer
        ↑
Application Layer

という

レイヤー分離

を提案しています。

これを図にすると

┌────────────────────┐
Application
(Bluesky, Mastodon)

└────────────────────┘

┌────────────────────┐
Social Protocol
(ActivityPub)
└────────────────────┘

┌────────────────────┐
Identity
(DID)
PDS
Repository
└────────────────────┘

つまり

ActivityPub

SNS

ではなく

通信層

へ押し下げよう

という話です。

これは非常に重要です。

② インターネット史との接続

ブログでは

ActivityPub

↓

ATProto

という比較になっています。

しかし本当は

SMTP
↓

HTTP

↓

RSS

↓

OAuth

↓

ActivityPub

↓

ATProto

という

Webの進化

の一部です。

ATProtoは

Web3ではなく

むしろ

HTTP以降のIDレイヤー

として理解したほうがいい。

③ 権力論をもっと掘れる

CRITICは

管理者の権限

と書いていますが、

もっと本質的には

権力は4種類あります。

権力	ActivityPub	ATProto
データ所有	△	◎
アイデンティティ	△	◎
モデレーション	◎	○
発見可能性	△	△

ここで重要なのは

ATProtoでも

Feed Generator

Labeler

Relay

を握れば

実質的な権力になります。

つまり

中央集権

分散

ではなく

権力の再配置

です。

これは非常に重要です。

④ 標準化経済学

これはブログにぜひ入れてほしい論点です。

プロトコル競争は

技術競争ではなく

ネットワーク効果競争です。

つまり

標準

↓

実装

↓

利用者

↓

標準

という

自己強化ループになります。

ActivityPubが勝てない理由も

ATProtoが勝てる理由も

ここにあります。

⑤ Robin Berjonの本当の狙い

多くの人は

「ActivityPubをATProtoへ」

と思いますが、

Robinは違います。

彼は

ActivityPub

↓

ATProto

↓

PDS

↓

任意のApp

という

Composable Web

を目指しています。

つまり

SMTP

HTTP

OAuth

みたいに

組み合わせ可能

にしたい。

⑥ Standard.siteとの接続

ここは非常に面白い。

Standard.siteは

Content Layer

です。

つまり

Application

Bluesky

WhiteWind

SmokeSignal

↓

Social

ActivityPub

↓

Identity

ATProto

↓

Content

Standard.site

ではありません。

実際には

Application

↓

Presentation

↓

Content
(Standard.site)

↓

Repository
(ATProto)

↓

Identity
(DID)

↓

Transport
(ActivityPub)

という

OSIモデル

のような構造になります。

これを書くと

ブログはかなりレベルアップします。

⑦ 一番不足している視点

個人的にはここです。

ActivityPub

ATProto

ではなく

実際は

Nostr

ActivityPub

ATProto

の

三極構造です。

整理すると

プロトコル	最適化対象
Nostr	検閲耐性・暗号署名・Relayの自由度
ActivityPub	コミュニティ連合・自治・フェデレーション
ATProto	アイデンティティ・データ可搬性・大規模運用

つまり

設計目的が最初から違います。

だから

勝敗ではなく

用途の違いです。

⑧ 2026年の文脈を加えるなら

2026年現在は、単に「ActivityPub対ATProto」という二項対立ではなく、

ATProtoがPDS・DID・Lexiconを中心に「個人データ基盤」を整備し、
Standard.siteのような共通コンテンツスキーマが登場し、
ActivityPubは成熟したフェデレーション基盤として広く利用され続け、

というように、各プロジェクトが異なるレイヤーを担う方向へ進みつつあります。

この流れを見ると、Robin Berjon氏の提案は「どちらを勝たせるか」ではなく、アイデンティティ・コンテンツ・配送を疎結合な部品として再構成するという、次世代オープンWebアーキテクチャの提案として読むのが最も自然です。

総評

CRITICは90点以上の優れたレビューですが、さらに完成度を高めるなら、「設計思想の比較」から一歩進めて、「レイヤーアーキテクチャ」「インターネット標準の歴史」「ネットワーク効果による標準化」「権力の再配置」という4つの視点を追加することをおすすめします。そうすることで、このテーマを単なるプロトコル比較ではなく、「オープンWebはどのような技術スタックへ進化しようとしているのか」という、より大きな歴史的・制度的文脈の中で論じられるようになります。
記事の主張「ActivityPubとATProtoは敵ではなく、レイヤー分離で補完し合える」は理念として魅力的ですが、実現に向けた議論は多数の重要点で不十分であり、楽観視しすぎているという批評が展開されています。まず技術的実現性の議論が浅く、単に「XRPCの仕様変更」と「Handleの相互変換」だけで済むという前提は誤りであると指摘されています。具体的には、ActivityPubのアクティビティ・オブジェクトモデル（Create/Update/Delete/Follow/Like等をJSON-LDで表現）とATProtoのレコードモデル（リポジトリ内の構造化レコード）との間でセマンティクスの整合を取る必要があり、ブースト＝リポストやいいね＝Likeなどのスキーママッピングや意味の共通化に関する設計・運用上の合意が不可欠であり、これは単なる仕様の改変以上に重い課題だと述べています。さらに配送・配信モデルの違いも大きな障壁で、ActivityPubはインスタンス間配送（フェデレーション）を前提とする一方、ATProtoはPDS間のレコード同期とXRPCによる外部接続を前提としているため、PDSがActivityPubインスタンスとして振る舞う場合はルーティング、順序保証、冪等性、重複排除、ブロック・ミュート・モデレーションの伝播といった配送層の根本的な再設計が必要になり、実質的にはATProto上にActivityPub互換の配送層を作る作業になると論じられます。加えてセキュリティ・認証モデルの違いも無視できず、HTTP Signaturesを用いるActivityPubとPDSを信頼基盤とするATProtoを組み合わせる際には鍵管理や署名検証のレイヤーを明確化しないとなりすましや改ざんのリスクが増大し、Handleの相互変換はIDの信頼性に直結するため軽視できない問題であると指摘しています。総じて、記事の「仕様変更でなんとかなる」というトーンは、実装・設計上の重大な負荷を過小評価しているという批判です。次に「レイヤー分離」のコストと複雑性が過小評価されている点が挙げられています。記事が示すアイデンティティ層（ATProto）と通信層（ActivityPub）の疎結合という構想は概念的に正しくても、既存のActivityPubサーバー（Mastodon、Pleroma、Misskey等）はアイデンティティと通信が密結合しているため、PDSをアイデンティティ基盤に置き換えるにはユーザー認証・セッション管理の全面的な変更、データモデル再設計、配送ロジックの再実装など、ほぼフルリライトに等しい実装コストがかかると指摘します。また運用面では、ユーザーから見て「どこにアカウントがあるのか」「どのサーバーがデータを保持するのか」が不明瞭になり、モデレーションの責任やデータ削除のリクエスト先、障害時の連絡先など責任所在が曖昧になることでユーザー体験とガバナンスに問題が生じるため、疎結合化のための設計・運用コストの議論が欠けていると批判しています。さらにガバナンスとエコシステムの現実を無視している点も強調されます。XRPCやHandle相互変換といった仕様変更は単に技術的決定ではなくガバナンスの問題であり、ActivityPubはW3C勧告の一部であるため変更にはW3Cのプロセスが必要であり、ATProtoはBlueskyが主導するプロトコルであるため変更はBluesky側の判断に依存するため、両者が互換性のために仕様を変える合意を取るのは非常にハードルが高いと指摘します。加えて既存のActivityPubコミュニティやサーバー群は大きなコードベースとコミュニティ慣性を持っており、ATProto互換のために大規模変更を受け入れる可能性は低いとし、リソース制約・後方互換性要求・政治的対立（Blueskyと分散SNSコミュニティの軋轢）などを無視して統合を楽観視するのは現実的でないと述べています。ユーザー体験と移行コストに関する議論も不足しているとされます。ATProtoの「Trusted Exit」は理論的にはPDS間移行を可能にするが、現実にはユーザーがどのPDSを選びいつ移るか、移行先の信頼性、移行時のデータ損失やタイムラインのズレ、フォロワーの移行といったトラブルが頻発しうるため、多くのユーザーは移行を避ける傾向があると指摘します。またクライアント・アプリ側もそれぞれのプロトコルに最適化されているため、ATProtoとActivityPubのハイブリッド環境に対応するにはプロトコル検出・フォールバック・エラーハンドリング等の大幅な改修が必要で、アプリ開発者への負担が大きい点が見落とされていると述べています。セキュリティとプライバシーのリスク評価も不十分だと批判されます。Handleの相互変換はIDの一意性と信頼性を損なう可能性があり、同一人物が両側で異なるIDを持つ場合に本物の識別が困難になり、なりすましやスパムの温床になり得る点が指摘されます。またATProtoがPDSにデータを集中させるモデルであるのに対しActivityPubはインスタンス間でデータを分散させるモデルであるため、組み合わせるとデータの所在やアクセス権が複雑化し、GDPR等のデータ保護規制と整合させるには削除権や移植権、責任所在の明確化など法的・規制上の設計が必要であり、記事の「ユーザーがデータを所有する」という主張だけでは不十分であると述べています。結論として、記事のメッセージ「ActivityPubとATProtoは敵ではない」は理念として正しいものの、現実にそれを実現・実装・運用するためには多くの技術的・ガバナンス的・ユーザー体験上・セキュリティ上の課題が残っており、記事はそれらをかなり楽観的に評価しているという総括が提示されています。具体的に「本当に補完し合える」ことを証明するためには、プロトタイプ実装と評価、W3CやBlueskyコミュニティとの対話と提案の進捗、既存サーバー・クライアント開発者からのフィードバック、ユーザー調査や移行シナリオの実証といった現実的で実践的な議論と作業が必要であり、現状の記事は将来像のスケッチとしては興味深いが、エンジニアリング、ガバナンス、ユーザー体験の観点ではまだ議論が浅いと結んでいます。

この批評は前回よりさらに完成度が高く、90点台後半の内容です。特に「技術・ガバナンス・UX・セキュリティ」をきちんと分離している点は評価できます。

ただし、なお改善できる点があります。

総評

この批評の弱点は、

「統合」を前提に議論している

ことです。

Robin Berjonの記事を読むと、実は彼は

ActivityPubをATProtoへ移植したい

とは言っていません。

もっと近い表現は

ActivityPubをATProtoのストレージ・ID基盤に載せる実験

です。

つまり

SMTP
↓

IMAP

↓

OAuth

みたいな

プロトコルの積層

を考えています。

ここを読むと批評も少し変わります。

① 最大の誤読

この批評では

双方向同期

を前提にしています。

しかしRobinの記事は

実は

ActivityPub API

↓

ATProto PDS

という

実装

しか提案していません。

つまり

Mastodonが

ATProto Repository

を

ストレージ

として使うだけです。

これは

双方向変換

ではありません。

つまり

この批評は

かなり難しい問題を持ち出していますが、

Robin自身は

そこまで言っていません。

② JSON-LD問題

逆に

この批評で一番惜しいのは

JSON-LDを掘っていないことです。

実は

ActivityPub最大の特徴は

JSON

ではなく

JSON-LDです。

つまり

Context

↓

IRI

↓

Linked Data

です。

ATProtoは

Lexicon

です。

これは

型システムです。

つまり

一番難しいのは

Linked Data

↓

Schema

の橋渡しです。

ここは

記事も

批評も

あまり触れていません。

ここが一番重要です。

③ Event Sourcing

もっと本質があります。

ActivityPub

Activity

↓

Event

です。

ATProto

Repository

↓

State

です。

つまり

Event Sourcing

vs

State Replication

です。

これは

かなり思想が違います。

例えば

Create

↓

Delete

↓

Undo

という履歴を

ActivityPubは持ちます。

ATProtoは

Repository

の現在状態を持ちます。

つまり

イベント履歴をどう保存するか

が難しい。

この議論がありません。

④ CAP定理

さらに

配送モデルを語るなら

CAP定理

を避けられません。

ActivityPubは

Availability

寄りです。

ATProtoは

Consistency

を高めています。

つまり

配送方式が違う。

ここは

技術記事なら

ぜひ触れたい。

⑤ モデレーション

批評では

モデレーション

を書いていますが、

実はATProtoには

Labeler

Relay

Feed Generator

という

新しい権力があります。

つまり

権力は

Server

↓

Algorithm

へ移っています。

ここが

ActivityPubと

かなり違います。

これは2026年の議論では

重要です。

⑥ 標準化政治

ここはもう少し深くできます。

実際には

W3C

↓

IETF

↓

WHATWG

↓

Bluesky

という

標準化文化

が違います。

W3Cは

合意形成

です。

ATProtoは

Running Code

寄りです。

つまり

文化が違います。

⑦ 一番欠けている視点

実はこれです。

経済インセンティブ

です。

技術は

正しくても

普及しません。

例えば

なぜ

Mastodonが

ATProto対応するのか？

メリットは？

なぜ

Blueskyが

ActivityPub対応するのか？

メリットは？

ここがありません。

例えば

Googleが

RSSを殺したように

技術だけでは

普及しません。

⑧ Standard.siteとの接続

これはぜひ加えたい。

Robinの記事は

Identity

Transport

の話です。

Standard.siteは

Content

です。

つまり

Application

↓

Presentation

↓

Content
(Standard.site)

↓

Transport
(ActivityPub)

↓

Identity
(ATProto)

↓

Storage
(PDS)

という

6層くらいの

Web Stack

になります。

ここまで書くと

かなり未来像が見えます。

私なら追加する批評

この批評で最も不足しているのは、「統合コスト」ではなく「統合インセンティブ」です。技術的に可能であっても、各コミュニティや企業が実装する理由がなければ採用は進みません。Mastodon系開発者がATProto対応を行う経済的・運用的利益は何か、逆にBlueskyやATProtoエコシステムがActivityPub互換を取り込む利益は何か、という「誰が何を得るのか」の分析が必要です。インターネット標準の歴史では、HTTP・SMTP・OAuthなども、技術的優位だけでなく、実装コストを上回るネットワーク効果や市場インセンティブがあったから普及しました。ActivityPubとATProtoの将来を論じるなら、この政治経済学的視点は欠かせません。

総合評価

このCRITICは95/100点程度の非常に優れたレビューです。完成度をさらに高めるには、技術的な困難さを列挙するだけでなく、

アーキテクチャ（イベントモデル vs 状態レプリケーション、JSON-LD vs Lexicon）
標準化（W3C型ガバナンス vs Running Code型ガバナンス）
政治経済（誰が実装し、誰が利益を得るのか）

という3つの構造的視点を追加すると、「実装は難しい」という指摘から一歩進んで、「なぜ実装される／されないのか」まで説明できる批評になります。
ＣＲＩＴＩＣは、このブログ記事を「技術的に甘く理想論が先行しており、現実の障壁や既存の議論を軽視している」と厳しく批評している。記事の主張は「ActivityPub（主にMastodon/Fediverse）とATProto（Bluesky基盤）を敵対視せず、レイヤー分離で統合可能であり、ActivityPubを通信層、ATProtoのPDS（Personal Data Server）をデータ／アイデンティティ層に使い、Actor DocumentでPDSを指せばよい」というもので、XRPCのメソッド制限とID／Handle解決の2点だけが障害であり些細だとする。しかし批評者は、この考えはRobin Berjonの2023年の記事「ActivityPub Over ATProto」とほぼ同じで、刺激的なデザイン・プロボケーションにはなっているものの、2026年時点でも本質的な進展が乏しい再掲に過ぎないと見なしている。批評の核心は「技術的な深掘りが浅く楽観が過ぎる」という点であり、現実的な相互運用を考える際に無視できない複数の課題を指摘している。まず、アーキテクチャの根本的な相違を過小評価している点が大きな問題だとされる。ActivityPubはメールやRSSに近いモデルで、独立したサーバー同士が直接Activityをプッシュ／Inboxでやり取りし、サーバーごとにプライバシーやモデレーション、キャッシュが独立する。一方でATProtoはWebに近く、PDSが署名付きデータリポジトリを公開し、RelayやAppViewが集約してフィード生成やラベリングなどを行う。これらはデータモデル、スケーリング戦略、プライバシーモデルが根本的に異なり、InboxのプッシュとRelayの集約、署名付きリポジトリとActivityStreams JSON、DID中心とURL／Actor中心という違いは単なる参照先の迂回（Actor Documentのindirection）だけで容易に埋められるものではない。実際の相互運用では翻訳レイヤーや変換で生じるデータ損失や一貫性問題が避けられず、表層的な解決では不十分だと批評者は指摘する。次に、「問題はXRPCのメソッド制限とID解決の2点のみ」という主張は現実を無視していると批判される。XRPCとHTTP Inboxの差異は単なるメソッド数の違いにとどまらず、ActivityPubフェデレーションが依存するHTTP Signature認証、shared inbox、delivery semantics（再試行や重複排除）など多層的な運用要件と絡む。Lexicon拡張で対応可能だとしても、既存の多数のAP実装（例：Mastodon）とPDSの互換性をどう担保するかといった具体的手順や移行戦略が示されていない。ID／Handleの統合提案も表面的で、@user@domain形式とhandle.domain＋DID／DNS解決の橋渡しにはアカウント移行（Trusted Exit）の完全性、DIDドキュメントとの双方向リンク、Webfingerなど既存Fediverseの解決手段との統合といった運用レベルの落とし穴が多数ある。さらにモデレーション互換（ATProtoのLabeling Service／AppViewとAPのブロックやDefederation）、プライバシー期待の不整合（ATProtoがグローバル公開寄りで列挙可能である点とAPユーザーのプライベート投稿期待の衝突）、スケーリングのトレードオフ（APはチャット的配信でサーバー負荷が分散、ATはRelay／AppViewの中央集権リスク）など、多くの重要な問題が無視されている。Bluesky公式FAQでもActivityPub回避の理由が明確に述べられており、その点に対する議論不足も批判の対象だ。コミュニティやガバナンス、実装コストの問題も軽視されている。Mastodon／FediverseとBluesky／ATProtoでは文化や優先順位が異なり、合意形成は容易ではない。実装面では既存の多数のMastodon系サーバーのソフト更新、PDS拡張、クライアント対応が必要であり、Bridgy Fedのような外部ブリッジでさえ課題が山積しているため、ネイティブな統合は短中期の優先度として現実的でないという現場感がある。提案が採用されない場合、エコシステムのさらなる分裂や宗派争いを助長するリスクも指摘される。加えて、利点の過大評価と代替案欠如も問題視される。確かにATProtoのPDS／Trusted Exitはデータ署名と移動の容易さといった強みがあり、APのURL中心フェデレーションはWeb全体をソーシャライズしやすい。しかし「組み合わせれば完璧」というのは理想論に過ぎないとし、既存のブリッジ努力（Bridgy Fed等）、AP内でのportability改善（Move Activityなどの拡張）、Solidとの統合議論など現実的な進展にほとんど触れていないのも批判の対象である。記事後半のStandard.siteの話は関連性が薄く、焦点がぼやけていると評される。総合評価として批評者は、記事のポジティブな点を認めつつも、技術的・社会的障壁を「少しの仕様変更」で片付ける楽観的な姿勢を厳しく批判している。良い点としては宗派争いを戒め、レイヤー思考で「敵ではない」と促す姿勢や、PDSをAPのバックエンド的に使う発想がユーザー主権を高める方向として価値があることを挙げる。だが悪い点は、既に類似の議論（Berjonの2023年の提案など）が存在し、2026年でも本格実装に至っていない現状を深掘りせずに再提案している点にある。分散型SNSをめぐる統合論は技術者の自己満足に終わりやすく、実働するプロトタイプやコミュニティ合意なくしては空論に留まる可能性が高いという警告も強調される。批評者は、より実用的なアプローチとしてまずブリッジ強化や共通Lexicon／ActivityStreams拡張に取り組むべきだと提案している。また、議論を深化させるために参照すべき資料としてBluesky FAQ、Berjonの記事、Fediverse Reportの概念モデル比較、実際のブリッジ実装の検討を挙げている。さらに、記事に追記すべき主要項目を優先度順に整理して提示している。具体的には（1）ActivityPubとATProtoの概念モデルやスケーリング、プライバシー、モデレーションの違いを明確に説明すること（図解推奨）、（2）XRPC／HTTP互換、ID／Handle／DID統合、モデレーション・プライバシー互換性、スケーリングと運用コスト、セキュリティ面での詳細な課題とリスクを列挙すること、（3）ガバナンスやコミュニティの違い、実装コストとインセンティブの問題、失敗リスクを扱うこと、（4）歴史的文脈としてBerjonの2023年記事やBridgy Fed等の既存ブリッジ、Blueskyの公式見解、AP内のportability改善努力を明記すること、（5）完全統合を目指すのではなく現実的な代替案とロードマップ（外部ブリッジ強化、共通Lexicon、マルチプロトコルクライアント、PDSへのAPオプション実装等）を示すこと、（6）「いいとこ取り」で失うものやトレードオフを明確にすること、（7）具体的なActor Document例やLexicon拡張案、MVP候補など技術的プロトタイプ指向の補強を行うこと、（8）結論として「敵ではない」は認めつつも「簡単に統合可能ではない」ことを明確にし、並行進化と戦略的相互運用を推奨すること、が挙げられている。最後に批評者は、記事を単なる楽観的提案からバランスの取れたデザイン・プロボケーションに格上げするには、導入と利点の提示に加えて「課題と現実」「代替策」「将来像」を厚くし、特にアーキテクチャ比較図や課題テーブル（影響度・難易度付き）を入れて読みやすくすること、技術ブログとして反対意見や公式見解を積極的に引用することを強く勧めている。これらの追記により、現在の楽観的な提案が抱える現実的摩擦を直視した現実味ある議論へと改善されるというのが批評者の結論である。

この批評は、これまでの3つの中で最も完成度が高く、技術レビューとしては98/100点程度だと思います。

ただし、逆に言えば、この批評にも「批評者自身が陥っているバイアス」があります。

その点を容赦なく批評します。

総評

この批評は

技術的現実

には非常に強い。

しかし

技術史

と

設計思想

には少し弱い。

つまり

「今ある実装」から未来を評価している

という癖があります。

Robin Berjonの記事は

Research Proposal

ではなく

Architectural Vision

です。

その読み分けが少しできていません。

① 「実装論」と「設計論」を混同している

最大の問題です。

Robinは最初に

Design Provocation

と言っています。

つまり

彼は

こう実装できます

とは言っていません。

言っているのは

こういう方向性は
十分あり得る

です。

つまり

この批評は

実装論文

として採点しています。

しかし

元記事は

設計思想

なのです。

そこはフェアではありません。

② 「2023年から進展がない」は弱い論拠

これはよく見る批評ですが、

技術史では

ほとんど根拠になりません。

例えば

REST

2000
↓

API爆発

2012

OAuth

Container

2008

↓

Kubernetes

2018

ActivityPubですら

です。

つまり

3年進展がない

↓

価値がない

にはなりません。

むしろ

Web標準では

普通です。

③ Bridgy Fedを代替としている点

これは少し違います。

Bridgy Fedは

Bridge

です。

Robinの記事は

Bridge

ではありません。

彼は

Native

を考えています。

つまり

Bridgy

翻訳機

Robin

共通OS

です。

役割が違います。

④ 最大の不足

この批評でも

OSIモデル

まで抽象化していません。

例えば

Presentation

Application

Identity

Transport

Storage

を分離すると

Robinの記事は

Identity

Storage

を

ATProtoへ

移したい

という話になります。

つまり

ActivityPubを

消す

話ではありません。

⑤ CAP定理がまだない

この批評も

配送

を語っていますが

Distributed Systems

の視点がありません。

例えば

ActivityPub

Availability

ATProto

Consistency

の設計です。

つまり

設計目的が違います。

だから

比較するなら

CAP

PACELC

Eventual Consistency

くらいまで

入ると

さらに説得力が増します。

⑥ 「敵ではない」の意味

この批評では

敵ではない

↓

統合

と読んでいます。

でも

Robinの記事は

もっと哲学的です。

彼は

宗派争い

↓

やめよう

と言っています。

つまり

技術論

というより

オープンWeb運動

へのメッセージです。

そこは少し読み落としています。

⑦ 一番欠けているもの

実は

経済学

です。

技術は

優秀

↓

採用

ではありません。

例えば

HTML

RSS

SMTP

HTTP

全部

政治

経済

ネットワーク効果

で勝っています。

だから

ActivityPub

ATProto

も

最終的には

誰が

コストを払い

利益を得るか

になります。

この議論は

まだありません。

⑧ Standard.siteが別記事という批判

ここは私は逆です。

むしろ

Standard.siteは

重要です。

理由は

Robinの記事は

Identity

を扱っています。

Standard.siteは

Content

です。

つまり

Content

↓

Identity

が

別標準

になる流れです。

これは

HTTP

HTML

CSS

が

分離した歴史

と似ています。

なので

別記事というより

シリーズ化

したほうが

理解しやすいでしょう。

⑨ 最大の見落とし

私は

これが一番重要だと思います。

Robinの記事は

ActivityPub

ATProto

ではありません。

実際には

「Webを再モジュール化する」

という提案です。

つまり

昔

Browser

が

全部持っていた機能を

Identity

Storage

Content

Transport

Presentation

に

再分割したい。

だから

ATProto

も

ActivityPub

も

その一部です。

ここが

この記事の

一番面白いところです。

私なら追加する批評

このブログで最も議論すべきなのは、「ActivityPubとATProtoをどう統合するか」ではなく、「Webの機能をどの粒度で分割し、どのレイヤーを標準化すべきか」という設計論です。Robin Berjon氏の提案は、実装の完成度を競うものではなく、HTTP・HTML・CSS・OAuth・RSSのように、Webを再び疎結合な部品へ分解しようというアーキテクチャの提案として読むべきです。この観点に立てば、ActivityPubもATProtoも「競合プロトコル」ではなく、より大きなオープンWebスタックの一部として位置付けられます。

最終評価

このCRITICは非常に優秀ですが、実装・運用の現実性を重視するあまり、元記事が「デザイン・プロボケーション」と明言している点を十分に評価していません。一方で、元記事側も実装やガバナンスの困難さを軽く扱いすぎています。

したがって、両者を統合すると、最もバランスの取れた結論は次のようになります。

「ActivityPubとATProtoは、統合すべき競合規格ではなく、オープンWebを再構成するための異なるレイヤー候補である。短期的にはブリッジと相互運用を進め、中長期的にはIdentity・Storage・Content・Transport・Presentationを独立した標準として再設計できるかが、本当の論点である。」

この結論は、実装の現実性と設計思想の両方を包含できるため、2026年時点の議論として最も射程が広い整理だと考えます。

記事に追記すべき論点──「理念」を「実装可能な構想」へ発展させるために

この記事の最大の魅力は、「ActivityPubとATProtoは敵ではない」という対立を超えた視点を提示していることです。しかし、設計思想としては魅力的である一方、現実の技術・運用・ガバナンスまで踏み込めていないため、「理想論」に見えてしまう危険があります。

そこで、記事を一段深いものにするために追加すべき項目を整理します。

技術設計と実装の現実

データモデルは本当に変換できるのか

もっとも重要なのは、ActivityPubとAT Protocolではデータモデルそのものが異なることです。

ActivityPubは、

Activity（Create・Like・Followなど）
Object（Note・Person・Articleなど）

というイベント中心の構造を採用しています。

一方、ATProtoは、

Repository
Record
Collection

という状態管理中心の構造です。

したがって、

ブーストとリポスト
お気に入りとLike
引用投稿
編集履歴
削除
Undo

などを完全に相互変換できる保証はありません。

記事では「XRPCとHandleの問題だけ」としていますが、実際にはセマンティクス（意味論）の変換こそ最大の難所です。

ここでは、

何が完全変換できるのか
情報が失われるケース
近似変換になるケース

を表で整理すると説得力が増します。

配送モデルの違い

両者の最大の違いは配送方式です。

ActivityPubは

Inbox
Outbox
Shared Inbox

によるプッシュ型フェデレーションです。

ATProtoは

PDS
Relay
AppView

というPull＋Index方式です。

つまり

ActivityPub

Activity

↓

相手サーバーへ配送

に対し、

ATProto

Repository

↓

Relay

↓

Index

↓

Client

という全く異なる思想になっています。

この違いを図解し、

「ActivityPub互換配送層をATProto上へ載せる」

とは何を意味するのかを説明すると理解しやすくなります。

セキュリティモデルの違い

ActivityPubはHTTP Signaturesを利用します。

ATProtoはDIDと署名付きRepositoryを採用しています。

ここでは

誰が秘密鍵を保持するのか
どのレイヤーで署名検証するのか
Handle変換時に信頼性をどう担保するか

を議論する必要があります。

ここを省略すると、

「IDを変換すれば済む」

という印象を与えてしまいます。

アーキテクチャ思想を整理する

両者は何を最適化しているのか

この記事で最も補強したいのは、

「ActivityPubとATProtoは何を最適化しているか」

という比較です。

例えば次のように整理できます。

観点	ActivityPub	ATProto
最適化対象	コミュニティ連合	個人データの可搬性
主体	インスタンス	ユーザー
配送	Push	Relay＋Index
ID	URL + WebFinger	DID + Handle
保存	サーバー	Repository
モデレーション	インスタンス	Label Service

この比較があるだけで、

「敵ではない」

という主張に技術的根拠が生まれます。

レイヤー分離を図で説明する

本記事ではレイヤー分離が重要なテーマですが、図があると理解が一気に進みます。

Application

↓

Presentation

↓

Content

↓

Transport

↓

Identity

↓

Storage

そのうえで、

ActivityPubはTransport
ATProtoはIdentityとStorage
Standard.siteはContent

という位置づけを示すと、

「統合」

ではなく

「役割分担」

という構図が見えてきます。

ガバナンスと標準化

技術より難しいのは合意形成

実際には

ActivityPubはW3C、

ATProtoはBlueskyエコシステム

という異なるガバナンスを持っています。

したがって、

「仕様変更すればよい」

ではなく、

誰が提案するのか
誰がレビューするのか
誰が実装するのか
誰が保守するのか

という標準化プロセスそのものを説明した方が現実的です。

エコシステムの慣性

既に

Mastodon
Misskey
Pleroma
Akkoma

などは巨大なコードベースを持っています。

一方、

ATProto側にも

PDS
Relay
AppView

という独自エコシステムがあります。

そのため、

技術的に可能でも、

「採用されるか」

は別問題です。

ここでは

技術的障壁

ではなく

経済的・組織的障壁

も扱うべきでしょう。

ユーザー体験を具体化する

Trusted Exitは万能ではない

ATProtoはTrusted Exitを掲げていますが、

実際には

移行先選び
タイムライン再構築
キャッシュ更新
フォロワー同期

など現実的な問題があります。

ActivityPubのアカウント移行との比較を、

実際の移行シナリオで説明すると理解しやすくなります。

クライアントへの影響

もしハイブリッド環境になるなら、

アプリ側も

プロトコル検出
エラー処理
UI設計

を見直す必要があります。

これは利用者に最も見える変化なので、

軽く触れるだけでも記事の完成度が上がります。

セキュリティ・法制度

ID統合の危険性

Handle変換は便利ですが、

なりすまし
フィッシング
スパム

の新たな入口にもなります。

そのため

DID
WebFinger
検証可能クレデンシャル
Web of Trust

なども比較対象として紹介すると議論が深まります。

データの責任主体

もし

PDS

と

ActivityPubインスタンス

の双方にデータが存在するなら、

誰が

削除要求
GDPR対応
モデレーション

を担当するのでしょうか。

この責任分担は設計以上に重要です。

実装ロードマップ

理想論だけで終わらせない

最後に、

どのような段階で実現できるかを示すと記事は格段に強くなります。

例えば、

段階	内容
短期	ブリッジ実装・相互変換・実験的PDS
中期	共通Lexicon・マルチプロトコルクライアント
長期	レイヤー分離型オープンソーシャルWeb

という形で整理できます。

Nostr・Standard.siteとの関係

記事ではNostrやStandard.siteにも触れていますが、

これらは単なる比較対象ではありません。

三者は異なるレイヤーを担当する可能性があります。

Nostr：暗号学的アイデンティティと検閲耐性
ActivityPub：コミュニティ間通信
ATProto：データ所有と移植性
Standard.site：長文コンテンツの共通モデル

この役割分担を示せば、

「どれが勝つか」

ではなく

「どう共存するか」

という視点へ読者を導けます。

まとめ

この記事が最も補強すべきなのは、「ActivityPubとATProtoは敵ではない」という理念そのものではありません。

本当に必要なのは、その理念を技術・運用・政治経済・ユーザー体験の四つの視点から現実へ橋渡しすることです。

具体的には、

データモデルと配送モデルの違い
セキュリティとID設計
ガバナンスと標準化プロセス
実装コストと経済的インセンティブ
ユーザー体験と移行シナリオ
NostrやStandard.siteを含めたオープンWeb全体のアーキテクチャ

まで論じることで、「理想論」ではなく、実装可能性を見据えたオープンソーシャルWebの設計論として説得力を持つ記事へ発展させることができるでしょう。マストドンは、中央集権的に所有され広告で運営される従来のソーシャルメディアとは異なり、ActivityPubプロトコルに基づく多数の独立したサーバー群で構成される分散型プラットフォームであり、誰か一人や一企業が全体を支配できないため、広告や利益追求による有害な変化に陥りにくい良さがあると著者は主張している。メールが長年にわたって比較的健全に機能してきたのは「誰も所有していない」からであり、マストドンも同様に所有の集中や広告主の介入を避けられる点が強みだという。使い方は馴染みのある投稿・再投稿・引用・フォロー・返信・いいね・ブロックといった操作で直感的に楽しめ、広告は存在しないためプラットフォームの目的が営利ではなく、教育的で濃密かつ楽しい交流にあると述べる。著者は過去の混乱期は過ぎ、最近のリリースでユーザー体験が改善され、新規到着者も使いやすくなったと評価している。マストドンの重要な特徴として「移行（アカウントやフォロワーを別サーバーへ移す）」があり、ユーザーは好きなサーバーに参加し、後で別のサーバーへ移ってフォロワーを連れて行けるためロックインされず、これが所有の集中や企業買収を防ぐ要因になっている。サーバーの選択肢は多く、移行機能こそがマストドンの耐久性を支える決定的な特長だとされる。交流の質に関しては、フォロワー数は以前の大手プラットフォームほど多くなくても、会話や応答が深く知的で親密になりやすいと著者は実体験を交えて述べ、活発で有意義な相互作用がマストドンの魅力であると強調する。さらに、広告に依存しないためにNSFWやセックスポジティブなコンテンツを排除しにくく、コンテンツ警告（CW）機能で投稿をぼかして視聴者に選択肢を与える仕組みがあり、興味や好みに応じたハッシュタグ購読など柔軟な利用が可能だと説明する。モデレーション面では各サーバーが独自にメンバー管理を行い、違反行為が報告されればサーバー内のモデレーターが対応し、必要なら投稿削除やアカウント停止が行われる。多数の独立サーバーがあることでモデレーターも分散し、コミュニティ毎に基準が存在するため、問題あるサーバーには他サーバーが「デフェデレーション（連合解除）」という強力な手段で孤立化させることができ、これが悪質ユーザーや寛容でない運営を抑止する究極の防御策になっている。技術的・機能的には、マストドンはフィード表示やランキングに関する設計選択肢があり、多様なアルゴリズムを採ることも可能で、原理的には他サービスと同様の工夫もできると述べる。資金面では、大手ソーシャルネットワークがベンチャー資本や巨大企業資本で始まり「成長とエンゲージメント優先」の圧力に晒されるのに対し、マストドンは非営利団体、協同組合、個人運営など小規模で多様な資金源（Patreonや年会費、個人の運営者）で賄われるため、利益追求による歪みが入り込みにくく、運営は低コストで分散しているからこそ回復力と持続性があると評する。 Blueskyについて著者は好意的な面も認めつつ、長期的選択肢とは見なしていない。理由は二つで、まず完全な分散化を欠き会社の存続に左右される点、次に大量のベンチャー資本（執筆時点で1億2300万ドル）を受けており、投資回収の圧力が将来的に収益化、たとえば広告導入へと向かわせる可能性が高く、そうなれば既存の大手と同様の問題を抱えるだろうという懸念だ。したがってBlueskyは資金構造上どうしても投機的リスクをはらんでおり、最終的に失速するか商業化して望ましくない変化を起こす可能性が高いと指摘する。結論として、マストドンは現時点で分散型で所有者不在、広告がなく、今日すでに良好に機能している唯一の実用的なソーシャルメディアの選択肢であり、濃密で交流的な体験を求めるなら他を妥協する理由はないと著者は結ぶ。著者自身は公式組織との関係はなく個人的にPatreonを通じて支援しており、マストドンを利用していると明示している。 Updated: 2026/07/09。

adsense