私がActivityPubよりAT Protocolに惹かれた理由

おひとりさまMisskeyを自前で立てていた時期がありました。(いまは「みすほわいと」に間借り中です) このサーバーは実験などして遊んだ末に、うまく動かなくなったため廃止されてしまいました。

インスタンスは攻撃にも弱いし（一時期荒らしなどが湧いていた）、管理者が(自分が)疲れてサーバーを畳めばそこでおしまいです。ハンドルや投稿、いいね、つながり、そういったものが「インスタンス」に強く結びついている世界では、どうしてもその場所の寿命が自分のアカウントの寿命にもなってしまいます。

AT Protocol（atproto）では、自分の中でこの不安が大きく減ったように感じます。 プロトコルそのものの設計のなかに「場所への依存を減らす」工夫が入っていて、無理のないセルフホストと、万が一落ちても“世界から消えない”仕組みが用意されていたからです。

この記事では、ActivityPub（AP）と比べたときに、なぜ自分は AT Protocol に惹かれたのかを、いくつかの観点から書きだしてみます。

この記事は Bluesky / ATProtocol Advent Calendar 2025 の10日目です。

1. アカウントポータビリティ

どんなによくできたサーバーでも、いつかは終わります。

ActivityPubの世界でも、Mastodon/Misskeyには「アカウントの引っ越し機能」があります。ただ、現状それは主に

• フォロワーを新しいアカウントに転送してもらう

といった「誘導」が中心で、過去の投稿やいいねなどの履歴は、基本的に古いインスタンスに置き去り になります。引っ越した先からは、昔の自分の発言をそのまま持ってくることはできません。

AT Protocolでは、設計のかなり根っこの部分から発想が違います。

• Identity（誰か）: DID（分散型識別子）で表現される
• Data（その人のデータ）: Repositoryとしてまとまって管理される
• Server（場所）: それらをホストするPDS（Personal Data Server）

この3つがきれいに分離されていて、「同じIDのまま、データを引き連れて別のPDSへ移る」 ことが前提になっています。

言い換えると、

• サーバーは「自分の荷物（Repository）を置いてある場所」のひとつに過ぎず
• そこがダメになったら「別の置き場所に移す」という発想が自然にできる

ようになっています。

この「サーバーが死んだら終わり」ではなく「サーバーを変えればいいだけ」という感覚は、メンタル的にかなり大きいです。インスタンスの寿命と、自分のアカウントの寿命をある程度切り離せる。これが、自分が atproto に惹かれた一番大きな理由です。

（引っ越しの具体的な流れなどは、5日目の記事で詳しく書いています。）

2. モノリスからの脱却

ActivityPubの多くは（少なくともMisskeyは）、一つのサーバーが

• 投稿の保存
• 投稿の配信
• タイムラインの構築と表示

といった機能をまるっと抱え込むモノリス構造 に近い形になっています。

この構造は挙動としては分かりやすい一方で、

• サーバーが落ちると、何も届かないし、何も見えなくなる
• 設定ミスでDBを壊すと、一気に取り返しがつかない

といった“全部入りゆえのリスク”も背負っています。良くも悪くも「インスタンスという箱」にすべてが詰め込まれているのです。

AT Protocolは、これとはかなり違う哲学を持っています。ざっくりいうと、

• PDS: ユーザーごとのデータを持つ場所（セルフホストも想定）
• Relay: イベントをさばく中継役
• AppView: 表示用のインデックスやタイムライン生成を担う層

といった具合に、機能をいくつかの役割に きれいに分割して、それぞれを組み合わせて使う 形になっています。

「公式のPDSだけを自前に置き換えられる」だけではなく、AppViewやRelayといったそれ以外のコンポーネントも、原理的には全部自分で建てて差し替えられる ように設計されています。 どこまで自前でやるかは人それぞれですが、「公式に全部お任せ」から「全部セルフホスト」までのグラデーションの中から、自分の体力にあった地点を選べる余地がちゃんと用意されています。

個人的に、この構造は「UNIX哲学（Do One Thing and Do It Well）」の再来のように感じます。1つの巨大なサーバーにすべてを背負わせるのではなく、

• データを持つところ
• それを配るところ
• 集積し見せ方を作るところ

に分け、得意なところにだけ集中してもらう。これによって、

PDS（自分のセルフホストサーバー）をうっかり落としてしまっても、AppViewがデータをキャッシュしているので、他者からの閲覧にはそこまで影響しにくい

という構造が実現できます。

もちろん、ActivityPubの世界でも各サーバーがキャッシュを持っているかぎり、元インスタンスが落ちても過去の投稿を閲覧できるケースは多いです。それでも「プロフィールに辿り着けない／新しい投稿が配信されない」といった形で、存在感が大きく削がれてしまう場面はどうしても出てきます。

その点で、PDSが落ちてもAppView側がプロフィールや投稿一覧をある程度保持し続けてくれるという構造は、セルフホスト勢にとってかなり心理的に楽だと感じています。

3. できる範囲のセルフホスト

個人運営のインスタンスは、美しい文化だと思います。でも同時に、

• 管理者の献身とモチベーション
• お金（サーバー代）
• 時間（障害対応やメンテナンス）

に強く依存していて、「永遠に動き続けてくれるとは限らない」という危うさも抱えています。自分自身が鯖缶をやるとしても、いつかは興味や生活状況が変わる時は来るものです。

また、ActivityPub系のサーバーは、ユーザー数が増えると丸ごと重くなる 傾向があります。タイムラインの構築も配信も全部そのサーバーに乗っているので、シンプルに「サーバーに負荷が集中する」わけです。 (Misskey.ioなどはワーカーを増やすなどの工夫をしているそうですが)

AT ProtocolのPDSはもう少し割り切っていて、

• PDSは「その人のデータ」をきちんと持つことに専念する
• タイムラインの生成や検索などの重い処理は、別のコンポーネント（AppViewなど）に任せる

という分業が前提になっています。

5日目の検証用に建てた tmp-pds では、メモリ消費が 100MB強 に収まっていました。これは、ラズパイや安価なVPSでも無理なく動かせそうな数字です。

大きなサーバーを一発で頑張るのではなく、

• 自分が扱えるサイズのPDSを、自分のペースで運用する人たちがたくさんいて
• それがゆるやかにつながって、全体としてひとつのネットワークになっている

という姿のほうが、「継続可能なインターネット」として健全なんじゃないか、そんなふうに思います。

4. アルゴリズムを「選べる」こと

もうひとつ、地味に大きいと感じているのが フィードアルゴリズムの扱い です。

ActivityPubの世界でも、実際にユーザーがよく見るのはホームタイムラインや自分で作ったリストで、「自分がフォローした人の投稿が時系列で流れてくる」という、とても素直な構造が基本です。 ただ、どのサーバーと連合するか・連合TLを出すかどうか・外部からの投稿をどこまで受け入れるかといった“外枠のポリシー”は、どうしてもサーバーソフトウェアとその管理者の判断に大きく依存します。

AT Protocolでは、タイムラインの生成ロジックを

• 誰かが(あるいは自分が) AppView や Feed Generator として公開し
• ユーザーはそれを 選んで購読する

という発想に寄せています。

現時点では、

• PDSの環境変数にAppViewのエンドポイントなどが埋め込まれがち
• 完全に自由にコンポーネントを差し替えるUIやエコシステムは、まだ発展途上

といった制約もありますが、それでもFeed Generatorや自前AppViewをセルフホストして、公式とは違うアルゴリズム一式を自分で用意する ことは十分可能です。構造として「タイムラインをつくる点」と「それを選んで使う点」を分離できる余地があるのが、個人的にはとても好きなポイントです。

自分の見たい世界を、自分である程度選べる。そして、その余地が最初からプロトコルに組み込まれている、というのは、あとから仕様追加で頑張るよりずっと心強いと感じます。

5. おわりに

AT Protocolは、まだまだ発展途上のプロトコルです。実装も仕様も動き続けていますし、「ここからどう転ぶか」は誰にも分かりません。

それでもこのアーキテクチャには、

• 個人の力や主体性を信じるながら
• 個人の「荷物（責任や運用負荷）」をできるだけ軽くしようとする

そんな思想が宿っているように感じます。

大きなサーバーを一手に抱えて、みんなの生活を背負い込むのではなく、

• 自分のデータは自分で持ちつつ
• 「場所」や「方法」はいつでも変えられるようにしておく

そんな気楽さとしなやかさが、AT Protocolにはあります。

だから自分は、ActivityPubを嫌いになるというよりは、「こうあってほしいインターネット像」により近いものとして、 AT Protocol に賭けることに惹かれていて、自分の欲しい環境をこの上に少しずつ作っていきたいな、と思っています。