ハクソク

世界を動かす技術を、日本語で。

ATProtoにはインスタンスが存在しません

2026年6月20日原文(overreacted.io)

概要

  • atproto にはMastodonのような「インスタンス」は存在しない
  • インスタンス概念はMastodon特有のものであり、atprotoではホスティングとアプリが分離
  • atprotoはRSSやGoogle Readerのような集約モデルを採用
  • ユーザーはホスティングやアプリを自由に選択・変更可能
  • インスタンス数ではなく「分散化の質」が本質

atprotoとインスタンスの誤解

  • Hacker News などで頻出する「Blueskyのインスタンスはどこ？」という質問はカテゴリエラー
  • Mastodon的な「インスタンス」はatprotoには存在しない
  • インスタンスは「ホスティング＋アプリ」が一体化したMastodon特有の仕組み

RSSとGoogle Readerのモデル

  • RSS時代 は各自が自分のブログを持ち、Google ReaderやFeedlyなどのアプリが投稿を集約
  • ホスティング（ブログ）と集約（リーダーアプリ）は完全に分離
  • 投稿はアプリ内に「存在」せず、アプリはあくまで外部の集合体を投影する役割
  • この分離モデルがatprotoの思想の根底

中央集権型SNSの問題点

  • Facebookなどは「全員が同じ箱（プラットフォーム）」に閉じ込められる構造
  • アプリとホスティングが一体化し、広告やネットワーク効果による中央集権化
  • 分散化ニーズの高まり

Mastodonのインスタンス構造

  • Mastodonでは各コミュニティが独自の「インスタンス（小国）」を運営
  • ユーザーはどのインスタンスに所属するかを選択し、その管理者を信頼する必要
  • 異なるインスタンス間では「連合（フェデレーション）」によって投稿を転送
  • インスタンス間の分断、管理者同士の対立、インスタンス停止時のアイデンティティ消失などの課題
  • インスタンス間通信のスケール問題（O(n²)）

atprotoのモデル

  • atprotoは「ホスティング」と「アプリ」をネットワークレベルで分離
  • 各ユーザーのデータは独立したホスティングに存在し、複数のアプリがそれを集約
  • RSS＋Google Readerの構造をSNS全体に応用
  • ホスティングの切り替えや自分自身での運用も容易
  • 新しいアプリの開発や利用も自由

Blueskyとインスタンス数について

  • Blueskyやatprotoには「インスタンス」という概念自体が存在しない
  • Mastodonのような「インスタンス数」で分散化を測るのは誤り
  • atprotoでは「ホスティング」と「アプリ」が独立しており、ユーザーは自由に選択・移動可能
  • 複数のアプリやホスティングが同時に存在し、ユーザーが主導で分散化を実現

分散化の本質と自由度

  • atprotoでは「ホスティングの移動」や「新規アプリの開発・利用」が分散化の本質
  • Mastodonのような「箱を増やす」分散化とは異なる
  • アプリはBlogosphereのリーダーのように「全体の投影」として機能
  • 必要に応じて独自のホスティングやキャッシュ、リレーインフラも構築可能

結論：インスタンス脳からの解放

  • Mastodon的な「インスタンス数＝分散化」という発想はatprotoには当てはまらない
  • 本当に重要なのは「ユーザーが自由にホスティングやアプリを選べること」
  • ホスティングとアプリの分離が分散SNSの健全な発展の鍵
  • RSSやGoogle Reader のように、データはアプリの外に置き、アプリはそれを集約するだけの存在
  • atprotoの分散化は「多様な選択肢」と「自由度の高さ」にこそ価値

Hackerたちの意見

リレーがさらっと触れられただけで、ネットワークとの関わりについて詳しく説明されなかったのはなんでだろう？もしかしたら、それを説明するとatprotoに「インスタンス」が実際に存在することがわかっちゃうからかな？でも、どうなんだろうね？

└

リレーを調べてみたんだけど、リレーってアナロジーで言うとフィーダーみたいな感じ？別に必要ないのかな？欲しい場合は、1つ（いくつか？）選ぶか、自分で運営する感じ？

└

ほとんどの人が認めたくないけど、大きな中央集権的なファイアホースリレーはあまり分散してないからね。

└

ここで書いてるのは私だよ！リレーは最適化の一環で、ネットワークの形には必須じゃないから、あんまり触れなかったんだ。PDS（ホスティング）やアプリビュー（アプリサーバー）みたいな基本的な要素ではないから。エンジニアがアプリを作りやすくするために追加する「次の合理的なもの」って感じかな。リレーなしでもアプリは動くよ（例えば https://reddwarf.app/ みたいに）。直接クエリできるキャッシュもあるし、例えばコンステレーション（https://constellation.microcosm.blue/）とかね。リレーは意味のある「インスタンス」ではなくて、ただの再送信装置だから。運営コストも安いし、複数のアプリ間でプールするのも簡単。 （オタク向けの豆知識：リレーのサブスクリプションAPIは、単一サーバーのと全く同じだから、リレーは「たくさんのサーバー」のファサードみたいなもんで、イベントをまとめて聞けるんだ。）最初の頃（1年以上前）は、リレーを運営するのがもっと高かったけど、どのリレーもネットワークの全アーカイブを保存することが期待されてたんだ。今はその契約の一部じゃないけど、まだ多くの議論でそれが参照されたり前提にされてる。自分のリレーを運営するコストは（誰ともプールしたくない場合）月約30ドルだよ。コミュニティ運営のリレーもあるし、例えば https://firehose.network/ も使えるよ。

└

もしかしたら、それを説明するとatprotoに「インスタンス」が実際に存在することがわかっちゃうからかな？でも、どうなんだろうね？ なんでここであいまいなこと言ってるの？自分の立場をはっきり言えばいいのに。間違ってるって見せられるのが怖いのかな？でも、どうなんだろうね？

私が見る限り、リレーはATProtoがうまく動くための接着剤みたいなもんだと思う。コンテンツに依存しないはずで、データをただ通すだけだから、各アプリビューが気にしなきゃいけないサービスの数を減らしてくれるんだよね。ブログにも書いてあるけど、Mastodonとの大きな違いは、リレー、アプリビュー、PDSがそれぞれ独立したサービスで、スケーリングの要求が異なるってこと。システム設計の問題に対する美しい解決策だと思う。

└

彼らはリレーからコンテンツを直接削除することもあるよ。違法なコンテンツだけを削除すると主張してるけど、どれだけ本当かはわからないし、将来的に変わるリスクもあるからね。

└

そうだね、リレーはその一つの方法だよ。私は主に見過ごしてたけど、目に見えない最適化だし、他にも戦略があるからね。例えば、今の多くの小さなアプリは自分たちのデータベースインデックスを作る代わりに、コンステレーション（https://constellation.microcosm.blue/）に頼ってるから、リレーを全く使ってないんだ。

ATprotoは、本当の分散化を犠牲にして一貫性を重視してるけど、MastodonやAPはその逆で、もっとアクセスしやすい分散化のために一貫性を犠牲にしてるって感じかな。少なくとも、俺はそう理解してる。APノードを運営するのは、ATのコンテンツリレーを運営するよりも、普通のセルフホスティングの人にはずっと簡単だからね。だから、ATで「分散化」されるのは自分のデータだけで、ネットワークの一部を共同で所有するってより、自分のデータを所有することに重点が置かれてるってことだよね。これについては、HNでも何度も話したことがあるし。

└

「真の」分散化ってあるのかな？ :) 自分の中では、単一のスライドスケールというより、トレードオフのビュッフェって感じだよ。参考までに、APの世界では、いくつかの個人や小さなチームがリレーやミラー、キャッシュ、AppViewsなどを運営してるけど、確かに、物事が大きくなるにつれてコストがかかる可能性があるね。

└

これは面白い見解だね。AtProtoは、今の僕の考え方だと、もっとアクセスしやすくて、かつ分散型に感じる。ActivityPubだと、インスタンスを運営するにはデータやアプリをホスティングして、スケーリングの課題にも対処しなきゃいけないから、アクティブな運用責任を引き受けるか、他の誰かのインスタンスに縛られるかのどちらかを選ばなきゃいけない。もし選んだインスタンスが気に入らなくなって移動したくなっても、（状況が変わらない限り）最初からやり直しになる感じ。AtProtoだと、別のアプリプラットフォームに簡単に移行できて、同じアイデンティティを使い続けられるのが楽だよ。プラットフォームからデータをエクスポートして自己ホスティングするのはちょっとUXの課題だけど、少なくとも可能だしね。例えば、最近初めてTangledを使い始めたんだけど、既存のbskyバックのドメイン（h14h.com）でログインできた。新しいアカウントを作ったり、新しいユーザー名を選んだりする必要もなくて、まるで最初からそこにいるみたいだったよ。それから、VPSで自分のgitリポジトリを自己ホスティングするのも、せいぜい午後の作業で済んだし、ほとんど考えなくていいバックエンドサービスが動いてるだけ。最悪でも、tangled.orgで「あなたのリポジトリは古くなっていて、最新のTangledと互換性がないかもしれません」ってバナーが出るくらいで、それは最新のバージョンでdockerイメージを再構築＆再デプロイすれば解決できる。確かに、AtProtoはアーキテクチャ的には理解するのが難しいけど、実際にユーザーとインターフェースするのはずっとシンプルだと思う。

└

それは一部の理由だと思うけど、全てを言い表してるわけじゃないね。ATは単に一貫性を提供するだけじゃなくて、アプリ間で共有されるデータモデルを持ってる。だから、アプリは他のアプリからコンテンツを参照したり表示したりできるんだ。まるで型付きJSONのウェブみたいな感じ。異なるアプリは同じネットワークを通して見るレンズみたいなもので、誰でも古いデータの上に新しい体験を作れる。APにはそれに相当するものは全くないよ。APはデータをアプリに結びつけてるけど、ATでは、全アプリがクエリできる世界中のデータを持つ一つのグローバルデータベースがあるような感じ。なんでこの議論がいつもRelayにぶつかるのか理解できないな。今の時代、Relayを運営するのはそんなに高くないし（$30/月くらい）、無料で使える既存のもの（Blueskyやコミュニティのもの）がいくつもあるよ。それに、多くのアプリは全くRelayを使わず、Constellationみたいなコミュニティインデックスに頼ってる。中には自分のサーバーやデータベースすら持ってないところもあるし。

Hacker Newsで議論の続きを見る