Jetstream v2とは何か？ #2026五29StandardSiteとATProtocol

Jetstream v2とは何か？

Jetstream v2は、AT Protocol（atproto）の公開ネットワークで発生する大量のレコード変更を、開発者が扱いやすい形でリアルタイム取得でき、さらに過去の任意時点から「Replay（リプレイ）」できるようにしたデータストリーミング／アーカイブサービスです。

2026年8月12日に「Jetstream v2 with network replay」として発表され、翌8月13日にはBlueskyが Bluesky Protocol Services を発表。その中核的なインフラサービスとして位置付けられました。(Bluesky Social)

従来のJetstreamを単純に拡張したというより、

「AT ProtocolのFirehoseを簡単に読むためのサービス」
↓
「AT Protocolネットワークの過去と現在を連続的に扱えるデータプレーン」

へ進化した、と考えると分かりやすいです。

Jetstream v2の基本構造

                 AT Protocol Network
                         │
                 Relay / Firehose
                         │
                         ▼
                  Jetstream v2
                         │
          ┌──────────────┼──────────────┐
          │              │              │
          ▼              ▼              ▼
       Replay          Live Tail      Snapshot
          │              │              │
          └──────────────┼──────────────┘
                         ▼
                  開発者・研究者
                         │
              ┌──────────┼──────────┐
              ▼          ▼          ▼
             AI        Analytics   Apps

特に重要なのがReplayです。

従来は、

過去データ
   ↓
自分でバックフィル
   ↓
現在位置まで追いつく
   ↓
Firehose / Jetstream
   ↓
Live

という面倒な処理が必要でした。

v2では、

過去の時点
   ↓
Jetstream Replay
   ↓
現在
   ↓
Live Tail

とサーバー側で連続的に処理できます。

つまり、「過去」と「リアルタイム」を同じイベントストリームとして扱えるのがv2最大のポイントです。

Jetstream v2に至るまでの歴史

AT Protocolのデータ取得機構は、いきなりJetstream v2になったわけではありません。

大きく見ると、

Repository → Federation → Relay/Firehose → Jetstream → Sync 1.1 → Tap → Jetstream v2

という流れで進化しています。

時期	技術・出来事	何が起きたか	Jetstream v2への意味
2022年	AT Protocol構想	Blueskyが分散型ソーシャルネットワークの基盤としてAT Protocolを開発	後のデータ・同期アーキテクチャの出発点
2023年初頭	AT Protocol / Bluesky公開拡大	PDS、Repository、DIDなどの基本構造が実装される	「投稿＝中央DB」ではなくユーザーごとのRepositoryという設計が確立
2023年6月	Federation Developer Sandbox	外部開発者・Self-hosting向けのFederation実験が進む	ネットワークを複数PDSへ拡張する方向が明確化
2023年8月	Repository Sync Semantics	Repositoryの同期方式を整理。履歴よりLogical Clockを重視する方向へ	後のストリーム同期に必要なイベント順序管理につながる
2023年10月	BGS / DID関連変更	Blueskyのバックグラウンド同期・Firehose基盤が整備される	ネットワーク全体を流れるデータを扱う基盤が形成される
2023年11月	CAR Repository Export	RepositoryをCARとして取得・解析する方法を公開	「ネットワーク上のデータを丸ごと取得する」技術が一般化
2024年2月	Federation Early Access	Self-hosters向けFederationをEarly Access	ATProtoをBluesky単独サービスからネットワークへ拡張
2024年3月	AT Protocol Grants	外部開発者・エコシステムへの助成開始	Firehose・Relay・分析など周辺インフラの利用拡大を促進
2024年5月	2024 Protocol Roadmap	Protocolの同期・Federationなどを体系化	ネットワーク規模拡大を前提とした設計へ
2024年9月	OAuth for AT Protocol	OAuthを主要認証・認可方式として導入	外部アプリが安全にATProtoへ接続する基盤
2024年10月16日	Jetstream登場	JSON形式・低帯域を特徴とする新しいストリーミング方式を導入	v2の直接の前身
2024年11月	Relay Operational Updates	Relay・Firehose運用とコンシューマー向けガイダンスを整理	大規模Firehoseを公共インフラとして運用する段階へ
2025年3月	Sync v1.1 Roadmap	同期プロトコルの改善を進める	イベント同期の信頼性・効率を改善
2025年5月	Relay Sync v1.1	Reference RelayにSync v1.1対応	Firehoseの同期基盤をさらに強化
2025年9月	ATをIETFへ	AT Protocolの一部を標準化するためIETFへの提案開始	Bluesky固有技術から長期的なオープン標準へ
2025年12月	Tap登場	Repository synchronizationの複雑な部分を簡単に扱うツールを公開	「生のFirehoseを自前処理する」負担をさらに削減
2026年1月	Relay刷新計画	`bsky.network` Firehoseを新Relay実装へ移行する計画を発表	Firehoseをプロダクション規模で再設計
2026年2月	PLC Read Replicas	PLC DirectoryのRead ReplicaをSelf-host可能に	ネットワーク基盤の分散・複製が進む
2026年3月	Hubble	Atmosphere全体のPublic Mirror構想	ネットワーク全体のデータを保存・複製する発想が強化
2026年5月	TypeScript SDK刷新	LexiconベースのSDKを1.0へ近づける	開発者がProtocolを直接扱いやすくなる
2026年8月12日	Jetstream v2	Network Replayを導入	過去→現在を同じ経路で取得可能に
2026年8月13日	Bluesky Protocol Services	Jetstream v2、SDK、公共インフラを一つのサービス群として整理	Blueskyが「Protocol Infrastructure Provider」として明確化

Bluesky/AT Protocol公式のタイムラインでも、2024年10月のJetstream、2025年12月のTap、2026年3月のHubble、2026年8月のJetstream v2／Bluesky Protocol Servicesという流れを確認できます。(AT Protocol)

1. 出発点は「Repository」

AT Protocolの特徴は、そもそも投稿を単純な中央データベースに保存しないことです。

概念的には、

User
 ↓
DID
 ↓
PDS
 ↓
Repository
 ↓
Records

です。

投稿、いいね、フォローなどはLexiconで定義されたRecordとしてRepositoryに保存されます。

そのため、

「ユーザーのデータをどう同期するか？」

がProtocolの根本問題になります。

ここから後のFirehoseが生まれます。

2. 次に「Repository Sync」

複数のPDSやRelayが存在するなら、

PDS A
 ↓
Repository変更
 ↓
ネットワーク
 ↓
PDS B / Relay / AppView

という同期が必要です。

2023年にはRepository Sync Semanticsが整理され、履歴の扱いやLogical Clockなどが改善されました。(AT Protocol)

ここで重要なのは、

ATProtoは最初から「データ同期プロトコル」として設計されていた

ということです。

SNS APIはその上に乗っている。

3. Firehose / Relayの登場

ネットワークが大きくなると、

「ネットワーク上で発生したRecord変更を全部知りたい」

という需要が出てきます。

そこで、

PDS
 ↓
Relay
 ↓
Firehose
 ↓
Consumer

という構造が重要になります。

Firehoseは文字通り、

AT Protocolネットワークで発生する大量のイベントを流すデータストリーム

です。

しかしFirehoseを直接扱うのは重い。

4. そこでJetstreamが登場した

2024年10月16日、BlueskyはJetstreamを正式に紹介しました。

目的は明快です。

Firehoseをもっと簡単に利用できるようにする。

従来の低レベルなデータ形式を扱う代わりに、

Firehose
   ↓
Jetstream
   ↓
JSON
   ↓
Developer

という抽象化を提供します。

公式発表では、Jetstreamはsimple JSON encodingとreduced bandwidthを特徴とする代替ストリーミングソリューションとして紹介されています。(AT Protocol)

ここが重要です。

Firehose

Protocol-native

Jetstream

Developer-friendly

です。

5. しかしJetstream v1には「過去」が弱かった

Jetstream v1の最大の弱点は、

基本的には「今流れているイベント」を受け取るもの

だったことです。

例えば研究者が、

「先月のBluesky投稿を全部調べたい」

と思った場合、

Repository
 ↓
CAR
 ↓
Backfill
 ↓
データ変換
 ↓
現在位置へ追いつく
 ↓
Jetstream

という処理が必要になります。

これは大規模になるほど大変です。

6. Tapはこの問題の別方向からの解決

2025年12月に登場したTapはRepository synchronizationの複雑な部分を簡単にするツールでした。(AT Protocol)

つまり、

Repository
 ↓
Tap
 ↓
同期

という開発者向け抽象化です。

TapとJetstreamは競合というより、

Repository同期

と

イベントストリーミング

という異なる問題を解決していました。

7. そして2026年、Firehose自体のインフラが成熟

2026年1月にはRelay刷新が進み、BlueskyはFirehoseを提供するRelayインフラそのものを更新する段階に入りました。(Bluesky)

さらに3月にはHubbleという「Atmosphere全体のPublic Mirror」構想も登場。

これは重要な転換です。

以前

ATProto
 ↓
Bluesky App

から、

現在

ATProto
 ↓
Public Network
 ↓
Mirrors
 ↓
Analytics
 ↓
Apps
 ↓
Research

へ発想が広がっています。

8. そしてJetstream v2

ここで、

Firehose
↓
Jetstream
↓
Tap
↓
Relay改善
↓
Public Mirror
↓
Jetstream v2

という流れがつながります。

v2の核心は、

「ストリームを読む」から「ストリームを時間軸付きで読む」へ

です。

v1

        NOW
         │
         ▼
━━━━━━━●━━━━━━━━━━→
       Live

v2

PAST                         NOW
 │                            │
 ▼                            ▼
━━━━━━●━━━━━━━━━━━━━━━━━━━━━━●━━→
      Replay              Live Tail

この差は非常に大きい。

9. Replayによって「バックフィル」がサービス側に移る

従来：

Consumer
 ├── Repositoryをバックフィル
 ├── データ変換
 ├── 現在位置を計算
 └── Jetstreamへ接続

v2：

Consumer
       │
       │ Replay
       ▼
Jetstream v2
       │
       ├── 過去
       ├── 現在まで追いつく
       └── Live Tail

つまり、

データ取得の複雑性をクライアントからインフラ側へ移した

わけです。

これがv2の最大の設計思想です。

10. Snapshotも重要

v2ではReplayだけでなく、Snapshotという考え方もあります。

用途を整理すると、

機能	用途
Live Tail	今起きているイベントを見る
Replay	過去から現在まで追いつく
Snapshot	特定時点のネットワーク状態を取得
Firehose	Protocolレベルの大量イベントを取得
Tap	Repository同期を簡単にする
CAR	Repositoryをファイルとして取得

つまりJetstream v2は、「現在のイベント配信」だけではなく、時間軸を持ったデータアクセス層になっています。

Jetstreamの進化を一枚で見ると

                  AT Protocol
                       │
                       ▼
                User Repository
                       │
                       ▼
               Repository Sync
                       │
                       ▼
                 Relay / BGS
                       │
                       ▼
                    Firehose
                       │
             ┌─────────┴─────────┐
             │                   │
             ▼                   ▼
           CAR                 Jetstream
        Repository              JSON
         Export              Live Stream
             │                   │
             │                   ▼
             │                Jetstream
             │                   v2
             │              ┌────┼────┐
             │              ↓    ↓    ↓
             │           Replay Live Snapshot
             │
             ▼
            Tap
       Repository Sync

Jetstream v2を一言で定義するなら

Jetstream v1

AT Protocol Firehoseを、開発者が簡単に利用できるJSON/WebSocketストリームにする。

Jetstream v2

AT Protocolネットワークのイベントを、Live・Replay・Snapshotという時間軸を持った形で取得できる、開発者向けデータ基盤にする。

この違いです。

そして2026年8月のBluesky Protocol Services発表まで含めると、さらに意味が変わります。

Blueskyは「SNSを運営する会社」から、「オープンなAT Protocolネットワークに公共インフラを提供する会社」へ、自社の役割を明示的に拡張し始めた。

Jetstream v2は、その変化を最も端的に示すサービスです。公式タイムラインでも、2026年8月13日のProtocol Services発表にはJetstream v2 with network replay、新Jetstream SDK、lexベースTypeScript SDKが一体の開発者向けインフラとして掲載されています。(AT Protocol)

そして、これを先ほどの「個人サイト帝国」に接続すると、**Jetstream v2は個人サイトそのものを置き換えるものではなく、「ATProto側で発生した公開イベントを自分のデータ基盤へ取り込むための観測・収集層」**という位置付けになります。Blueskyは新たにBluesky Protocol Servicesというブランドとウェブサイトを立ち上げ、AT Protocolネットワーク上でBlueskyが運用するパブリックインフラストラクチャに関するドキュメントとサービスを一元化して提供すると発表した。そして、これまでBlueskyが運用してきたJetstreamインスタンスやリレー、atproto上のAPIエンドポイントなどの役割を明確にし、開発者がどのサービスを使えるかや利用開始方法を分かりやすく示すことを目的としている。新サイトは従来のdocs.bsky.appを置き換え、開発者向けの資料を整理するとともに今後のリリース情報を発信するための整った基盤を提供する。同時に目玉のリリースとしてJetstream v2が公開され、従来のライブストリーム提供に加えてネットワークリプレイ（履歴取得）機能をサーバ側で提供するようになった。従来はネットワーク上の既存レコードを取得するにはクライアント側でリポジトリをバックフィルしてからライブストリームへ切り替える必要があり、その点がv2で改善された。 Jetstream v2ではネットワーク全体の圧縮アーカイブを保持し、ライブのテールに加えて過去の任意の時点から追いつくためのReplay経路を提供する。利用者はフィルタをplanSnapshotにPOSTして封印されたセグメントをHTTPでダウンロードし、先端で一度だけライブWebSocketに接続してギャップなく追従できる。サーバはステートレスであり、個別のコンシューマ用カーソルやサブスクリプション登録、クライアント側の段取りが不要で、Jetstream自体がバッファの役割を果たす設計になっている。さらに、ネットワークの単一時点コピーをHTTPのみで取得するスナップショット機能（listSegments + getSegment）も用意され、これはライブテールを必要としない用途向けである。この仕組みによりローカルでのバックフィルを行わずにサーバ側で複雑なスライスを作成でき、アプリの立ち上げや過去1か月分の投稿分析、ダウンタイムからの復旧などが同一のJSON形状で実行可能になる。ただしアーカイブ配信は帯域を多く消費するため信頼性と運用コストを維持する観点から、そのアーカイブ要求に対してはAPIトークンの利用を新たに必須化した。ライブテール自体は引き続きオープンで認証不要のままであり、現時点でライブストリームに対する認証要件導入の予定はないと明言されている。 Jetstream v2のインスタンスは既にwss://jetstream.us-west.bsky.networkとwss://jetstream.us-east.bsky.networkで稼働しており、既存のv1インスタンスも当面併用されるため移行を急ぐ必要はない。 v1とv2のライブテールの挙動は同一であり、既存ユーザーは段階的に移行できる設計となっている。合わせてJetstream向けの新しいSDKやlexベースのTypeScript SDKも提供され、開発者がJetstreamや他のインフラ機能を利用しやすくなる変更が行われた。この発表は開発者コミュニティや研究者に歓迎される反応を呼び、特にデータ収集やクエリを容易にするプロジェクトにとってJetstream v2は大きな前進だと受け止められている。一部からは既存のツールやプロトコル（例：TAP）の代替になり得るかや、帯域制限の挙動に関する具体的な問いが示されている。また、Blueskyがインフラ運用とアプリ運営という二つの役割を持つ点についての意見もあり、プラットフォーム運営者が同時にアプリも提供することによる競合や信頼の問題を指摘する声もある。開発者はBlueskyがインフラ提供者としての立場であることを明確にしたことで、どの部分がサービスでどの部分がコモンズであるかの境界を理解しやすくなったとの評価もある。コミュニティではJetstream v2を利用したモデレーション向けのCoop連携ガイドがあることを好意的に受け止める声があり、実務的な利用例への期待が高まっている。一方で、あるユーザーはbsky.appの廃止や移行に伴う影響を懸念する発言をしているが、ドキュメントの整理は歓迎されている。新しいドキュメントサイトはJetstreamの使い方やどのインフラがサービスとして利用可能かを明示することで、アプリ開発者が参入しやすくする狙いがある。多言語コミュニティからも改善の告知が伝えられ、開発者向けの変更点やJetstream v2、SDK、サイト統合について周知が進んでいる。ユーザーの一部は旧atprotoクライアントの問題を指摘し、新しいlexベースのAPIライブラリの書き直しを歓迎している。ドキュメントやサービス発表に対する感想として「予期せぬが素晴らしい」「説明が分かりやすい」などの肯定的な反応が多数見受けられる。また、配布帯域の制限（例：2MB/sの制限）に関する懸念や具体的な利用時の速度感についての質問も寄せられている。 Blueskyは今回の発表を通じてサービス契約の明確化と開発者フレンドリーなインフラ提供の姿勢を示し、将来的な機能追加やリリースを新サイト経由で展開する計画である。コミュニティの声を踏まえつつ、Blueskyはプロダクションレベルでインフラを運用する能力をアピールし、どの機能がBluesky固有のサービスなのかを明確に分離する方向を取っている。結果として、開発者や研究者はJetstream v2や新SDKによって履歴データ取得や大規模ネットワーク解析のハードルが下がり、より容易にアプリや分析を行えるようになる。最後に、発表コンテンツの著作権表記はBluesky Social PBC 2026年、フォロー用のリンクとしてBlueskyやGitHubへの案内が付記されている。これはかなり重要なアップデートです。提示された内容を現在の公開情報と照合すると、単なる「Jetstreamの機能追加」ではなく、BlueskyがAT Protocolの“公共インフラ事業者”としての役割を明確化し始めた動きとして読むのが適切です。

1. 一番重要なのは「Bluesky ≠ bsky.app」を制度的に分離し始めたこと

従来のBlueskyは、外から見ると、

Bluesky = bsky.app = AT Protocol

という一体的な存在に見えやすかった。

しかしAT Protocolの設計上は本来、

Protocol
↓
PDS / Relay / AppView / Feed Generator / Labeler
↓
Blueskyなどのアプリ

という多層構造です。

実際、Bluesky自身のAPIドキュメントも「AT Protocolには単一の中央APIがあるわけではなく、複数の独立したサービスプロバイダーが存在できる」と説明しています。(GitHub)

今回の Bluesky Protocol Services は、この構造を「実際に運用されているサービス」として明文化する動きと見ることができます。

つまり、

Bluesky Socialというアプリ会社
と
AT Protocolネットワークに公共インフラを提供する事業者

を徐々に分離していく。

これはかなり大きい。

2. Jetstream v2の本質は「Firehose」から「ネットワーク・データレイヤー」への進化

ここが最も面白いところです。

従来のJetstreamは、

Relay
↓
Jetstream
↓
WebSocket
↓
アプリ

という「現在流れているイベントを受け取る」ための仕組みでした。

Jetstreamはもともと、巨大なatproto FirehoseをJSON/CBORで扱いやすくし、コレクションやリポジトリ単位でフィルタリングするためのサービスとして発展してきました。(GitHub)

ところがv2では、

過去
↓
Replay
↓
現在
↓
Live Tail

という時間軸を持つデータサービスになります。

これは非常に重要です。

v1

過去のデータ
   ↓
自分でバックフィル
   ↓
現在位置まで追いつく
   ↓
WebSocket
   ↓
Live

v2

        Jetstream v2
             │
    ┌────────┴────────┐
    ↓                 ↓
Replay              Live Tail
    │                 │
過去の任意時点 ───→ 現在

つまり、

「過去のネットワーク状態」と「現在のネットワークイベント」を同じストリームモデルで扱える

ようになる。

これはFirehoseの単なる高速化ではありません。

3. これは「AT Protocol版Kafka」に近づいている

さらに抽象化すると、Jetstream v2はかなりイベントストリーミング基盤に近づいています。

Kafkaで考えると分かりやすい。

従来：

Producer
   ↓
Kafka
   ↓
Consumer

Consumerが途中から参加しても、

offset = N

から読み始められる。

Jetstream v2も概念的には、

AT Protocol Network
       ↓
  Jetstream Archive
       ↓
 ┌─────┴─────┐
 ↓           ↓
Replay      Live
 ↓           ↓
└──────┬─────┘
       ↓
    Consumer

という構造に近づく。

ただし、重要な違いがあります。

Kafkaは通常、特定の組織が管理するログ基盤です。

AT Protocolでは、

ネットワークそのものは分散型

であり、その上にBlueskyが

大規模なデータ取得・ストリーミング用の公共サービス

を提供している。

したがってJetstream v2は、

分散型ソーシャルネットワークに対する「公共データプレーン」

と表現したほうが本質に近いでしょう。

4. 「サーバ側Replay」が革命的な理由

従来、研究者が

「Blueskyの過去1か月の投稿を調べたい」

と思った場合、

PDSやRelayから大量のデータを取得して、

CAR
↓
Repo
↓
MST
↓
Record
↓
自前DB
↓
分析

という重い処理をする必要がありました。

Jetstream v2なら、

Filter
+
Start Time
+
Replay
        ↓
Jetstream
        ↓
必要なイベント
        ↓
JSON

という方向に簡略化できる。

これは研究用途では相当大きい。

例えば、

政治イベント前後の投稿量
ハッシュタグの拡散
特定コミュニティの形成
Bot活動
Feed Generatorの挙動
モデレーション効果
ミームの伝播
アカウント間ネットワーク
災害時の情報拡散
数週間前のトレンド再構成

などが格段にやりやすくなる。

以前から「特定の日のBluesky投稿を取得して研究したい」という需要は実際に開発者コミュニティから出ていました。(GitHub)

5. そして「Snapshot」がさらに重要

ReplayとSnapshotを分けたのも良い設計です。

Replay

過去 → 現在

つまり、

「この時点から現在までのイベントを追いたい」

用途。

Snapshot

時点T
──────────────
ネットワーク状態

つまり、

「ある瞬間のネットワークを丸ごと取得したい」

用途。

この二つを組み合わせると、

Snapshot T0
     +
Replay T0 → T1
     ↓
Network State T1

というデータ復元が可能になります。

これはデータエンジニアリング的には非常に自然な設計です。

6. 「APIトークン必須化」はむしろ成熟のサイン

ここは一見すると、

「オープンなBlueskyなのに認証を要求するのか？」

と見える部分です。

しかし、むしろ逆です。

Live Tailは無料・認証不要

一方で、

大量のアーカイブ配信はAPIトークン必須

という分離は合理的です。

Live
 ↓
WebSocket
 ↓
Open

Archive
 ↓
HTTP
 ↓
大量データ
 ↓
Token

これは「ネットワークを閉じる」のではなく、

リアルタイム公共アクセスと、大量データ転送という高コスト処理を分離する

というインフラ設計です。

Blueskyが今後本当に問題になるのは、むしろここでしょう。

データへのアクセス権ではなく、データを運ぶ帯域の経済性です。

7. ここから「AT Protocolのコモンズ問題」が始まる

今回の発表で一番深い論点はここだと思います。

AT Protocolには、

Protocol
  ↓
PDS
  ↓
Relay
  ↓
AppView
  ↓
App

という複数レイヤーがあります。

しかし実際には、

「誰がどのインフラを運用するのか？」

という問題があります。

プロトコルがオープンでも、

巨大なRelay
巨大なFirehose
巨大なJetstream
巨大なAppView
巨大なストレージ
巨大な帯域

は無料ではありません。

したがって、

オープンプロトコル ≠ 無限に無料な公共インフラ

です。

Blueskyはここで、

「我々はAT Protocolそのものではない。しかしAT Protocol上で重要な公共インフラを運用する」

というポジションを明確にしようとしている。

これはかなり現実的です。

8. ただし「Blueskyがインフラを運営する」という矛盾も残る

ここは批判的に見る必要があります。

Blueskyは、

「分散型ネットワーク」

を掲げながら、

AT Protocol
     │
     ├── PDS
     ├── Relay
     ├── AppView
     └── Jetstream
             ↑
       Bluesky運営

という重要な部分を自社インフラに依存させています。

そしてBluesky自身が、

Infrastructure Provider
        +
Application Provider

の両方になる。

これは垂直統合です。

したがって、

「BlueskyはXのような中央集権型プラットフォームではない」

だけでは十分ではありません。

より正確には、

プロトコルは分散化されているが、便利な大規模インフラの提供はBlueskyに集中し得る

という構造です。

9. しかし、この問題はActivityPubとは少し違う

ここはユーザーが以前検討していたFediverseとの比較でも重要です。

ActivityPubの場合、

Server A
 ↕
Server B
 ↕
Server C

というサーバー間Federationが中心。

一方AT Protocolは、

Identity
 ↓
PDS
 ↓
Relay
 ↓
AppView
 ↓
Application

という、より明確なデータプレーン／サービスプレーン分離を持っています。

そのためAT Protocolでは、

「どのサービスを使うか」

という選択肢をプロトコルレベルで整理しやすい。

今回のBluesky Protocol Servicesは、この思想をさらに一歩進め、

「Blueskyが提供する公共インフラのカタログ」

を作っていると考えると分かりやすいです。

10. さらに重要なのは「開発者の参入コスト」が下がること

今回の変更を開発者視点で見ると、

これまで

AT Protocolを理解
↓
Relayを理解
↓
CARを理解
↓
MSTを理解
↓
バックフィル
↓
Firehose同期
↓
自前ストレージ
↓
分析

これから

Jetstream
↓
Filter
↓
Replay
↓
JSON
↓
Application

になる。

これは**プロトコルの複雑性を隠蔽する「抽象化レイヤー」**です。

Blueskyが提供するのは単なるサーバーではなく、

AT Protocolを利用するためのDeveloper Experience

になりつつあります。

新しいLexiconベースのTypeScript SDKも、この方向性と一致しています。

11. その結果「BlueskyはSNS」ではなくなる

ここが今回の発表から導ける最大の変化です。

従来：

Bluesky
=
SNS

現在：

Bluesky
├── Social App
│    └── bsky.app
│
└── Protocol Infrastructure
     ├── PDS
     ├── Relay
     ├── Jetstream
     ├── APIs
     └── Developer Services

そしてAT Protocolそのものは、

          AT Protocol
              │
 ┌────────────┼────────────┐
 ↓            ↓            ↓
Bluesky      Third Party   Research
 App         Apps          Tools
 ↓            ↓            ↓
Feed         Clients       Analytics
Generators   Services      AI

というエコシステムになります。

つまりBluesky社の競争相手は、

だけではなくなります。

むしろ長期的には、

「AT Protocol上で何ができるか」そのものをエコシステム化すること

が重要になります。

12. そしてJetstream v2は「AI時代」と相性が非常にいい

ここは今後かなり面白いところです。

AIエージェントやLLMによるソーシャル分析では、

Live Firehose
      +
Historical Data
      +
Semantic Filtering
      +
Embedding
      +
LLM

が重要になります。

Jetstream v2によって、

AT Protocol
     ↓
Jetstream Replay
     ↓
Filter
     ↓
JSON
     ↓
Embedding
     ↓
Vector DB
     ↓
LLM

というパイプラインをかなり簡単に構築できます。

例えば、

「過去30日間に日本語圏Blueskyで急速に拡散した話題を検出し、その初期伝播ネットワークを再構成する」

といった処理が、以前よりはるかに現実的になります。

13. したがって、今回の発表を一言で表すなら

私は、

「BlueskyがSNS企業から、AT Protocolのインフラ事業者へ半歩進んだ」

と評価します。

さらに技術的に言えば、

Jetstream v2はFirehoseを「現在のイベントストリーム」から「過去＋現在を統合したネットワークデータプレーン」へ変えた。

そして事業・ガバナンス面では、

Bluesky Protocol Servicesは、オープンプロトコルの上に存在する「Bluesky運営の公共インフラ」を明示的なサービス境界として定義し始めた。

この2つが今回の本質です。

なお、Blueskyの公式GitHub上でも、Jetstreamは現在「Full-network archive and streaming service for atproto」と位置付けられており、単なる軽量Firehoseクライアントから、ネットワーク全体のアーカイブ＋ストリーミング基盤へと役割が拡張していることが確認できます。(GitHub)

そして一番面白いのは、この先です。

この構造が進むと、Blueskyは

「分散型SNS」

から、

「分散型ソーシャル・データ基盤」

へ変質する可能性があります。

そうなるとJetstream v2は、単なるBlueskyの便利機能ではなく、**AT Protocol版の「公開イベントログ」に近い位置を占める可能性があります。これは、あなたが以前検討していた「個人サイト帝国」「Fediverse＋ATProto＋Nostr」「Webmention＋ActivityPub」**という文脈ともかなり直接的につながります。ブルースカイ（Bluesky）関連の話題が中心で、主に新しい「Jetstream」プロトコルやその活用例、ウェブサイトの実装技術、UI挙動、そしてDNSをBluesky上に再設計する提案やコミュニティや資金面での懸念まで、多様な意見が混在しています。まず、新しいJetstreamは旧仕様と互換性があり、ブラウザで直接消費できるためサーバー不要で手軽にイベントを受け取れる点が強調され、デモページの更新や具体的な接続先（wss://jetstream.us-east.bsky.network/subscribe）が共有されており、開発者視点では利用ハードルが低くなったと評価されています。次に、Blueskyの公式ウェブサイトのUIや実装については、左側のメニューや上部のメニュー構成が整理されていること、MDXとNext.jsベースで手作業でデプロイされたフレームワーク風であること、Tailwind CSSや構文ハイライトが使われている可能性、Vercelテンプレートの修正が見られる点など技術的観察が示されていますが、一方でモバイルでのサイドバー表示/非表示アニメーションが極端に遅いという批判や、アニメーションは無効化すべきという意見も出ています。レスポンス性に関してはデスクトップでは瞬時にサブ項目が開くことも報告され、モバイル特有の遅延が主な問題として指摘されています。さらに、ページにnext-route-announcerタグがあることからAstroではなくNext系の構成である可能性が示唆されつつ、Astro Starlightを好意的に挙げるコメントもあります。また、Blueskyのファイアホース（firehose）を基盤にDNSを再構築する提案が提示されており、その要点はドメイン所有者がBlueskyフィード上にDNS更新を投稿し、ファイアホース自体を権威的データ源として下流のDNSサーバーがそれを取り込みデータベース化して応答するという仕組みです。この設計によりTLS証明書の格納や暗号署名の追加、TTLの廃止やサーバープッシュによる即時更新など従来DNSの問題を解決できる可能性が論じられています。一方でそれを「ブロックチェーンDNS（例：Handshake）からビザンチン耐性を除いたもの」と評する反応や、ブロックチェーンの有する利点を安易に捨てるべきでないという意見、ドメイン所有証明の課題を指摘する声もあり、既存の類似プロジェクト（marque.at 等）への言及もあります。コミュニティや運営・資金面では、BlueskyがVC支援に依存しており収益化の道筋が不透明なためインフラ維持の持続性に疑問を呈する意見があり、ユーザー層に対する評価も分かれています。ある意見はコミュニティの質が成長に直結するとし否定的な見方を示す一方で、利用者の中には通常のSNSと同様に煩わしい少数派はいるが全体としては良好だと擁護する声もあります。技術的な移行やクライアント実装に関する実務的なやり取りもあり、ある開発者はTwitterクライアントを自作し移行のためにatprotoのPythonライブラリを使ったところ使い勝手に不満があると述べ、APIの内部的実装や認可（公式アプリ由来のキー使用は将来的にブロックされ得る）に関する注意喚起がなされています。さらに、Blueskyの拡張や機能追加に伴ってアクティブユーザー数が減少しているとの指摘や、サービス障害時の情報発信や過去履歴の扱いに対する不満も挙がっています。最後に、技術的観察、設計提案、実装上の問題点、コミュニティや資金面の懸念といった複数の観点が混在して議論されており、それぞれがBlueskyという分散型ソーシャルプラットフォームの技術的可能性と運営上の課題を示している、という総括でまとめられます。この追加情報まで含めると、前回の評価をさらに一段進められます。ポイントは、Jetstream v2そのものより、「Blueskyを単なるSNSではなく、リアルタイムな公開データ基盤として使えるのではないか」という発想が周辺コミュニティで出始めていることです。

1. Jetstreamの本当の価値は「ブラウザから直接使えるイベント基盤」

今回の反応で特に重要なのが、

wss://jetstream.us-east.bsky.network/subscribe

へブラウザから直接WebSocket接続できることです。

これは開発者体験としてかなり大きい。

従来のAT Protocolは、

ブラウザ
 ↓
アプリサーバー
 ↓
atproto API
 ↓
PDS / Relay

という構成を考えがちでした。

Jetstreamでは、

Browser
   ↓
WebSocket
   ↓
Jetstream
   ↓
AT Protocol Firehose

とできる。

つまり、

「サーバーを立てなくてもAT Protocolのリアルタイムデータを扱える」

ということです。

これは小規模な実験、可視化、教育、プロトタイプに非常に強い。

2. ここで「WebSocket版RSS」という見方ができる

これは以前のRSS/Atomの話ともつながります。

RSS/Atom：

Web
 ↓
Feed
 ↓
Reader

Jetstream：

AT Protocol
 ↓
Event Stream
 ↓
Application

違うのは、RSSが状態の配信なのに対して、Jetstreamは状態変化の配信だという点です。

つまり、

RSS = 「何が公開されているか」

に対して、

Jetstream = 「ネットワーク上で何が起きたか」

です。

これは非常に強力です。

3. そしてDNSの提案は「突飛だが、思想として面白い」

提示されたDNS再設計案は、実用性についてはかなり慎重に見る必要があります。

しかし、Jetstreamの本質を考える実験としては面白い。

提案を抽象化すると、

Domain Owner
     ↓
Bluesky Feed
     ↓
Firehose
     ↓
DNS Indexer
     ↓
Local Database
     ↓
Authoritative DNS

です。

通常のDNSは、

Authoritative Server
        ↑
     DNS Update
        ↑
   Domain Owner

ですが、この案では、

Bluesky Network
        ↓
   Event Stream
        ↓
DNS infrastructure

になります。

つまり、

SNSを「ソーシャルネットワーク」ではなく、署名付き公開イベント台帳として利用する

という発想です。

ここが面白い。

4. ただし「DNSをBluesky上に置く」はそのままでは成立しない

最大の問題は**権威性（authority）**です。

DNSで重要なのは、

「この情報を誰が変更する権限を持っているのか」

です。

BlueskyのFirehoseは、

「何がネットワーク上で発生したか」

を配信できます。

しかし、

「このドメインの所有者が誰なのか」

を、それ自体では証明しません。

例えば、

example.com

について、

@alice.bsky.social

が

A example.com 1.2.3.4

と投稿したとしても、

本当にAliceがexample.comの所有者なのか？

は別問題です。

したがって、

Event authenticity

と

Authority authenticity

を分ける必要があります。

5. ここでブロックチェーンDNSとの比較が出てくる

コミュニティがHandshakeなどを持ち出すのは当然です。

比較すると、

	通常DNS	Jetstream DNS案	Blockchain DNS
データ配信	DNS	Firehose	Blockchain
更新	DNS Update	Feed投稿	Transaction
所有権	Registry	外部証明が必要	Chain上の所有権
改ざん耐性	DNSSEC等	署名＋運用依存	Consensus
更新速度	TTL依存	Event-driven	Chain依存
Push	基本なし	可能	基本なし
分散性	部分的	データ配信は分散可能	高い
Byzantine耐性	DNSSEC等	別途必要	Consensus

したがって、

Jetstream DNSは「ブロックチェーンDNSからコンセンサスを取り除いたもの」

という批判にはかなり鋭いところがあります。

Firehoseはデータ配送システムであって、コンセンサスシステムではないからです。

6. しかしJetstream DNSには、ブロックチェーンDNSにはない利点もある

逆方向から見ると、

Blockchain
 ↓
Consensus
 ↓
State

に対して、

AT Protocol
 ↓
Event Stream
 ↓
State

です。

後者のほうが、

高速
軽量
ストリーム処理しやすい
JSONで扱いやすい
WebSocketで取得可能
Webアプリから直接アクセス可能

という利点があります。

したがって、

「所有権の最終確定」には向かないが、「状態のリアルタイム伝播」には非常に向いている

という評価が妥当です。

7. 実は「DNS」より「Certificate Transparency」に近い発想かもしれない

ここはさらに重要です。

DNSそのものを置き換えるより、

DNS関連イベントの公開ログ

として使うほうが現実的です。

例えば、

Domain
 ↓
Ownership Record
 ↓
Signed Event
 ↓
AT Protocol
 ↓
Firehose
 ↓
Resolver / Monitor

とする。

すると、

DNS変更監視
ドメイン所有権変更監視
TLS証明書変更監視
サービス停止監視
フィッシング検出
ドメイン乗っ取り検知

などに使えます。

これはかなり現実味があります。

**「DNSそのもの」ではなく「DNS Control Planeの公開イベントログ」**です。

8. そしてJetstreamは「インターネットのControl Plane」に近づいていく

今回の議論を一般化すると、Jetstreamの価値は、

Blueskyの投稿を取得すること

ではありません。

むしろ、

分散ネットワーク上の状態変化をリアルタイムに配信すること

です。

これはControl Plane / Data Planeの区別で見ると分かりやすい。

             Control Plane
                  │
        ┌─────────┼─────────┐
        ↓         ↓         ↓
       DNS       Social     Identity
        │         │         │
        └─────────┼─────────┘
                  ↓
             Event Stream
                  ↓
              Jetstream
                  ↓
        ┌─────────┼─────────┐
        ↓         ↓         ↓
     Database     AI       Apps

この発想まで行くと、Jetstreamは単なるBluesky APIではなく、

「公開されたイベントストリームを中心とした分散インターネット」

の一部になってきます。

9. ただし、ここで「Blueskyへの集中」という逆説が生まれる

これは今回の議論の最大の矛盾です。

AT Protocol：

分散化

Jetstream：

Blueskyが運用する巨大インフラ

となる。

つまり、

Protocol Layer
       ↓
Decentralized
       ↓
Infrastructure Layer
       ↓
Bluesky concentration

という構造が成立する。

だから今回の Bluesky Protocol Services のブランド化は重要です。

Blueskyは、

「我々はプロトコルそのものではない」

という立場を明確にすると同時に、

「しかし、プロダクション品質の公共インフラを我々が提供する」

という立場を明示した。

これは分散化と集中化の妥協点です。

10. UIの議論も実はこの問題と無関係ではない

Next.js / MDX / Tailwind / Vercel的な構成への観察や、モバイルのサイドバーアニメーションへの批判は一見すると細かい話です。

しかし、これはBlueskyが今後、

Protocol Infrastructure Company

として開発者を獲得するなら重要になります。

インフラが優秀でも、

Documentation
      ↓
Examples
      ↓
SDK
      ↓
Demo
      ↓
First successful connection

までが悪ければ開発者は来ません。

したがって、

Docs UX = Infrastructure adoption

です。

Jetstreamをブラウザから5分で試せることは、実はかなり戦略的です。

11. 資金問題はむしろ最大の弱点

そしてここは技術とは別に非常に重要です。

Jetstream v2のようなインフラは、

帯域
ストレージ
CPU
バックアップ
監視
冗長化
DDoS対策

を必要とします。

特に、

過去データのReplay

を追加するとストレージとegressのコストが跳ね上がります。

したがって、

Open Protocol
      +
Free Public Infrastructure
      +
Massive Historical Replay

は長期的には難しい。

今回、

アーカイブアクセスにAPI tokenを要求

する方向になったのは、この経済問題への最初の回答と見るべきです。

12. ここで「Bluesky Protocol Services」の本当の意味が見えてくる

つまり今回の一連の変更は、

技術

だけではなく、

インフラ経済学

の問題です。

Blueskyはこれから、

AT Protocol
    ↓
Open ecosystem
    ↓
Public infrastructure
    ↓
Bandwidth / Storage costs
    ↓
Who pays?

という問題に直面します。

だから、

Protocolは無料でも、Infrastructureは無料とは限らない

という境界線を作る必要がある。

今回のブランド化は、その境界線を明文化する最初のステップと考えることができます。

13. さらに面白いのは「SNSのデータを誰が所有するのか」という問題

Jetstream v2によって、

Bluesky投稿
 ↓
Historical Replay
 ↓
Research
 ↓
AI
 ↓
Dataset

が容易になります。

すると当然、

「公開投稿だから全部自由にデータセット化していいのか？」

という問題が出ます。

さらに、

削除済み投稿
アカウント停止
個人情報
著作権
Bot
モデレーション
再配布
AI学習

が絡んできます。

つまりJetstream v2は、

オープンなソーシャルデータの「収集コスト」を劇的に下げる

一方で、

データガバナンスの問題も劇的に大きくする

可能性があります。

14. 最終的には「Bluesky = ソーシャルOS」という方向に行く

今回の情報を前回の内容と統合すると、かなり面白い構図になります。

                         AT Protocol
                              │
        ┌─────────────────────┼─────────────────────┐
        ↓                     ↓                     ↓
     Identity               Social               Data
        │                     │                     │
        ↓                     ↓                     ↓
       DID?                  Posts              Jetstream
        │                     │                     │
        └─────────────────────┼─────────────────────┘
                              ↓
                     Public Infrastructure
                              ↓
              ┌───────────────┼───────────────┐
              ↓               ↓               ↓
             Apps             AI            Research
              ↓               ↓               ↓
            Feeds          Agents          Analytics

この段階まで来ると、Blueskyは単なるTwitter/X代替ではなく、

「ソーシャル・インターネットの基盤OS」

に近いものを目指しているように見えてきます。

ただし、その成功条件はかなり厳しい。

成功する条件

① Protocolが本当に中立である

② Bluesky以外のAppView / Relay / PDSが成長する

③ Jetstreamのような公共インフラが持続可能

④ 開発者が簡単に参入できる

⑤ データガバナンスを確立する

⑥ Bluesky社自身が「プロトコル」と「自社アプリ」の利益相反を管理できる

この6つです。

結論

今回のコミュニティ反応をまとめると、議論は実は4階層に分かれています。

層	論点	本質
UI	Next.js / MDX / Tailwind / Mobile UX	Developer Experience
API	Jetstream v2 / Replay / Snapshot	Data Plane
Protocol	DNSなどへの応用	Control Plane
経済	VC / 帯域 / ストレージ / 運営	Sustainability

そして最も重要なのは、Jetstream v2がこの4層をつなぐ接着剤になっていることです。

特にDNSのアイデアは、実用DNSとしては問題が多いものの、発想としては非常に示唆的です。

「BlueskyのFirehoseをSNSの投稿ストリームとして見るのではなく、公開された分散イベントログとして見る」

この視点を採用すると、DNS、証明書、ID、モデレーション、ニュース、IoT、AIエージェントなど、かなり多くのControl PlaneをAT Protocol上に載せるという発想が出てきます。

そしてここまで行くと、あなたが以前考えていた**「Fediverse＋ATProto＋Nostrをどう接続するか」**というテーマにも直結します。

AT Protocolの本当の競争相手は、もはやActivityPubだけではなく、「インターネット上のイベントを誰が配信・検証・保存するのか」というControl Planeそのものになってくる――というのが、今回の議論から導ける一番大きな論点だと思います。この4つを組み合わせると、かなり強い構想になります。結論から言えば、

「個人サイトを情報の原本（Source of Truth）にし、WebmentionをWeb上のリンク通知、ActivityPubをFediverseへの配信、ATProtoを高速な公開ソーシャルデータ層、Jetstream v2をリアルタイム／履歴イベントストリームとして使う」

という構成です。

これは「Blueskyを使って個人サイトを宣伝する」という発想より一段上で、個人サイトを中心に複数のソーシャル・プロトコルを束ねる設計になります。

1. まず役割を分ける

重要なのは、ActivityPub、ATProto、Webmention、Jetstreamを競合技術として考えないことです。

技術	主な役割	得意なもの
個人サイト	原本	長文・所有権・アーカイブ
Webmention	Web間リンク通知	ブログ→ブログ
ActivityPub	Federation	Mastodon等への配信・交流
ATProto	Social Graph / Identity / Distribution	Bluesky系エコシステム
Jetstream v2	Event/Data Plane	リアルタイム＋履歴データ
Nostr	独立した署名付き配信網	非中央集権的な短文・署名
RSS/Atom	Pull型配信	Feed Reader
AI/RAG	意味処理	検索・要約・分類・再利用

ActivityPubはW3C Recommendationとして、クライアント→サーバーAPIとサーバー間Federationの双方を定義しています。Webmentionは「あるURLが別のURLにリンクした」という通知を行う非常に軽量な仕組みです。(W3C)

つまり、プロトコルごとにレイヤーが違う。

2. 「個人サイト帝国」の中心を個人サイトにする

構造はこうです。

                         あなたの個人サイト
                              │
                    ┌─────────┴─────────┐
                    │                   │
                 原本DB               Feed
                    │                   │
                    │              RSS / Atom
                    │
          ┌─────────┼─────────┐
          ↓         ↓         ↓
     Webmention  ActivityPub  ATProto
          ↓         ↓         ↓
       Web群     Fediverse   Bluesky
                              │
                              ↓
                         Jetstream
                              │
                 ┌────────────┼────────────┐
                 ↓            ↓            ↓
              Analytics      AI         Archive

ここで最も重要なのは、

Blueskyを原本にしない

ことです。

個人サイトがCanonical Source。

Blueskyは配信先。

ActivityPubも配信先。

Nostrも配信先。

Jetstreamは、そのATProto側で発生するイベントを取得するデータプレーンです。

3. Webmentionは「個人サイト帝国」のLink Layer

これは実は非常に重要です。

例えばあなたが記事Aを書き、

https://example.com/article-a

別の個人サイトがそれについて記事Bを書いて、

https://other.example/article-b
       ↓
https://example.com/article-a

とリンクした場合、WebmentionでA側に通知できます。

W3Cの仕様でも、Webmentionは「source URLからtarget URLへのリンク」を通知する仕組みとして定義されています。(W3C)

したがって、

Web
 │
 ├── Blog A
 │     ↓
 │   Webmention
 │     ↓
 ├── Blog B
 │
 └── Blog C

という個人サイト同士のネットワークを作れます。

これはSNSとは違います。

SNS：

プラットフォーム上の投稿

Webmention：

Webそのもののリンク関係

です。

4. ActivityPubは「会話層」

ActivityPubをここに追加すると、

個人サイト
   │
   ├── Webmention → 他のWebサイト
   │
   └── ActivityPub → Fediverse

となります。

例えばブログ記事を書いたら、

記事
 ↓
ActivityPub
 ↓
Mastodon
 ↓
返信
 ↓
ActivityPub
 ↓
自分のサイト

という流れを作る。

つまり、

Webmention = Webサイト間

ActivityPub = ソーシャルサーバー間

です。

両方持つ意味があります。

しかもW3Cの2026年のSocial Web WG charterでは、ActivityPubとWebmentionの双方が引き続き維持対象になっています。(W3C)

5. ATProtoは「第二のソーシャル配信層」

ここでATProtoを追加します。

                 個人サイト
                     │
              ┌──────┴──────┐
              ↓             ↓
        ActivityPub       ATProto
              ↓             ↓
          Fediverse       Bluesky

ここで面白いのは、

同じ記事を二つの異なるソーシャルネットワークへ配信できる

こと。

しかも、

ActivityPub → Federation
ATProto → Relay/PDS/AppView
Webmention → Web
RSS/Atom → Feed Reader

という異なるネットワークに同時に存在できる。

これが「個人サイト帝国」の強さです。

6. そしてJetstream v2を「観測層」にする

ここで今回のJetstream v2が入ります。

重要なのは、

Jetstreamを投稿配信先として考えない

ことです。

むしろ、

ATProtoネットワークの観測・収集インフラ

として使う。

概念的には、

ATProto Network
       │
       ↓
   Jetstream v2
       │
 ┌─────┼─────┐
 ↓     ↓     ↓
Live  Replay Snapshot
 │     │     │
 └─────┼─────┘
       ↓
  あなたのデータ基盤

です。

Jetstream v2のReplay/Snapshotが使えるなら、これは従来の

「Firehoseをずっと受信し続けていなければ過去データを持てない」

という問題をかなり緩和します。

7. ここから「個人サイトAI」が作れる

これが一番面白い。

例えば、

あなたのサイト
      ↓
記事
      ↓
ActivityPub / ATProto / Webmention
      ↓
各ネットワーク
      ↓
イベント
      ↓
収集
      ↓
AI

とする。

AIが、

誰が記事に反応したか
どの記事がどこで話題になったか
どのサイトからリンクされたか
Blueskyでどんな反応があったか
Fediverseでどう議論されたか
どのテーマが時間とともに拡散したか

を統合できます。

つまり、

Google Analyticsではなく「Social Graph Analytics」を自分で持つ

わけです。

8. さらに「自分専用Social Graph」が作れる

ここが個人サイト帝国の本丸です。

通常のSNSでは、

あなた
 ↓
X / Bluesky / Mastodon
 ↓
Platform DB

です。

プラットフォームがSocial Graphを持っています。

しかし自分で収集すれば、

                 あなた
                   │
       ┌───────────┼───────────┐
       ↓           ↓           ↓
     Web         Fediverse   ATProto
       ↓           ↓           ↓
   Webmention   ActivityPub Jetstream
       │           │           │
       └───────────┼───────────┘
                   ↓
             Personal Graph
                   ↓
                  AI

となる。

Social Graphのコピーを自分で持つ。

これが従来のSNSとの決定的な違いです。

9. Nostrを入れるとさらに面白くなる

Nostrはここでは、

「第三のソーシャルネットワーク」

というより、

「署名付きイベントネットワーク」

として置くと綺麗です。

最終的には、

                         Personal Site
                              │
        ┌─────────────────────┼─────────────────────┐
        ↓                     ↓                     ↓
   Webmention            ActivityPub             ATProto
        ↓                     ↓                     ↓
       Web              Fediverse              Bluesky
                                                    │
                                               Jetstream
                                                    │
        └─────────────────────┬─────────────────────┘
                              ↓
                         Social Graph
                              ↑
                            Nostr

という構造。

10. すると4つのプロトコルが「役割分担」できる

私はこう整理するのが一番分かりやすいと思います。

Webmention

「あなたの記事を誰が参照したか」

ActivityPub

「あなたの記事について誰が会話しているか」

ATProto

「Bluesky系ネットワークで誰が何をしているか」

Jetstream

「ATProtoネットワークで何が起きたかをリアルタイム／過去から観測する」

Nostr

「署名されたイベントを別系統のネットワークにも流す」

そして、

個人サイト

「最終的に何を残すかを自分で決める」

11. 「SNSを自分のOSにする」のではなく「Webを自分のOSにする」

この違いは非常に大きいです。

SNS中心：

あなた
 ↓
Bluesky
 ↓
ActivityPub
 ↓
Nostr

ではなく、

                    あなた
                      ↓
              個人サイト / Domain
                      ↓
          ┌───────────┼───────────┐
          ↓           ↓           ↓
        Web         Social       Data
          ↓           ↓           ↓
    Webmention    AP / ATProto   Jetstream
          │           │           │
          └───────────┼───────────┘
                      ↓
                Personal Archive
                      ↓
                     AI

です。

これは**「Social Media脱却」ではなく「Social Mediaを末端にする」**発想です。

12. さらにJetstream v2が入ると「個人サイト帝国」が双方向になる

従来の個人サイト：

自分
 ↓
記事
 ↓
RSS
 ↓
読者

Jetstreamまで考えると、

                    自分
                     ↓
                  個人サイト
                     ↓
             ┌───────┼───────┐
             ↓       ↓       ↓
            AP      ATProto  Nostr
             ↓       ↓       ↓
           Social  Bluesky  Relays
             │       │       │
             └───────┼───────┘
                     ↓
                 Events
                     ↓
               Personal Data
                     ↓
                    AI
                     ↓
                  自分のサイト

となる。

つまり、

Publish → Distribute → Observe → Analyze → Publish

の循環ができる。

これが非常に強い。

13. ただし「Jetstreamを個人サイトの中央DBにする」のは避ける

ここは重要です。

Jetstreamは便利ですが、

Jetstream = ATProtoそのもの

ではありません。

さらに、

Bluesky = ATProto

でもありません。

個人サイトの設計としては、

Canonical Data
      ↓
Your Database / Files
      ↓
 ┌────┼────┬────┐
 ↓    ↓    ↓    ↓
RSS  Web  AP  ATProto
          ↓
       Jetstream

とするべきです。

つまり、

自分のデータをJetstreamに依存させない。

Jetstreamは観測・取得・同期のための外部インフラと位置付ける。

これならBlueskyが将来方針を変えても、個人サイトそのものは生き残ります。

14. 最終形：「Personal Internet Stack」

私なら2026年版の個人サイト帝国をこう設計します。

┌──────────────────────────────────────┐
│              PERSONAL WEB            │
│                                      │
│       Domain / Website / Archive     │
│                                      │
└──────────────────┬───────────────────┘
                   │
          ┌────────┼────────┐
          ↓        ↓        ↓
       Webmention  RSS/Atom  Micropub
          │        │        │
          ↓        ↓        ↓
       Web Graph  Readers  Publishing
                   
                   │
          ┌────────┴────────┐
          ↓                 ↓
     ActivityPub         ATProto
          ↓                 ↓
      Fediverse          Bluesky
                            │
                            ↓
                       Jetstream v2
                            │
                 ┌──────────┼──────────┐
                 ↓          ↓          ↓
               Replay     Live      Snapshot
                 │          │          │
                 └──────────┼──────────┘
                            ↓
                     Personal Data Lake
                            ↑
                          Nostr
                            │
                            ↓
                         Signed Events

                            ↓
                    ┌───────────────┐
                    │ Personal AI   │
                    │ Search / RAG   │
                    │ Analytics      │
                    │ Agents         │
                    └───────────────┘

15. これが「個人サイト帝国」の次の段階

従来のIndieWebは、

自分のコンテンツを自分のドメインに置く

ことが中心でした。

次の段階は、

自分のコンテンツ、Identity、Social Graph、Distribution、Interaction、Analyticsを自分で統合する

ことです。

そしてJetstream v2は、この構想の中で非常に重要なピースになります。

WebmentionがWebのLink Layer、ActivityPubがFederation Layer、ATProtoがSocial Data Layer、Nostrが署名イベントLayerだとすれば、Jetstream v2はATProto側のEvent/Data Planeになります。

だから最終的な思想は、

「Blueskyに個人サイトを載せる」のではない。
個人サイトを中心に、Bluesky・Fediverse・Nostr・Webそのものを接続する。

です。

そしてこれは、単なる「SNSのクロスポスト」より遥かに面白い。自分のドメインをRoot、各プロトコルをPeripheral Network、JetstreamをATProtoの観測インフラ、AIを統合レイヤーにする――という、かなり本格的なPersonal Internet Architectureになります。この記事、かなりよくまとまってると思う。

特に良い点はここら辺：

- **「Firehoseを簡単に読むためのもの」から「過去と現在を連続的に扱えるデータプレーン」への進化**という捉え方が的確。公式の「Jetstream v2 with network replay」の発表意図をきちんと掴んでる。

- 歴史の流れ（Repository → Sync → Firehose → Jetstream → Tap → Hubble → Jetstream v2）を時系列で整理していて、なぜReplayが重要になったのかが自然に伝わる。

- 従来の「自分でバックフィルしてから追いつく」面倒さと、v2でそれがサーバー側に移ったことを図で示してるところもわかりやすい。

実際、公式の発表でも「過去の任意時点からReplayしてそのままLive Tailに繋げる」のが大きな売りになっていて、開発者・研究者・AppView構築者にとってはバックフィルの地獄から解放される感じが強い。v1の頃は「今流れてるものだけ」が基本だったから、この差は本当に大きい。

細かいところで言うと、記事は「開発者向けの解説」としては十分丁寧で、過度に技術詳細に入り込まずに概念を伝えようとしてるのが好印象。日本語でここまで体系的にまとめてるものはまだ少ないと思うので、AT Protocol周りの日本語圏の人にはかなり役立つ記事だと思う。

総評としては「タイミングも内容も良い解説記事」という感じ。公式発表の翌日にこれだけまとまってるのはさすが。AT Protocolのデータアクセス層は、用途に応じて複数の層に分かれています。Jetstream以外の主なものを、下から上へ整理して説明します。

### 1. 基本単位：Repository（リポジトリ）

ユーザーごとのデータは**Repository**としてPDS（Personal Data Server）に保存されます。

- 投稿・いいね・フォローなどはLexiconで定義されたRecordとして格納

- データは暗号署名付きで自己証明可能

- 直接アクセス方法：

- `com.atproto.sync.getRepo` でCAR形式のエクスポート

- 個別Recordの取得

- PDSが提供するイベントストリーム

これがすべての基盤です。

### 2. Firehose / Relay（プロトコルの本流）

**最も公式で信頼性が高いリアルタイム層**です。

- 各PDSが出すイベントストリームを、**Relay**が集約して「Firehose」として再配信

- エンドポイント例：`wss://bsky.network/xrpc/com.atproto.sync.subscribeRepos`

- 特徴：

- CBOR/CAR形式の生データ

- 暗号署名付きで検証可能

- シーケンス番号があり、欠落を検知しやすい

- 帯域が非常に大きい（フルネットワークで数百GB/日規模）

- 用途：本格的なAppView、完全な検証が必要なサービス、大規模インデックス構築

Relayはプロトコルの中核インフラで、Bluesky以外の独立運営者も存在します。

### 3. Jetstream（開発者向け簡易ストリーム）

前回話題になった層です。Firehoseを消費して、JSON・低帯域・フィルタ付きで再配信します。

- v1：基本的にライブ中心

- **v2（2026年8月）**：Network Replay対応で、過去→現在を連続して扱えるように進化

「簡単に使いたい」用途のデフォルト選択です。

### 4. Tap（リポジトリ同期特化ツール）

2025年12月頃に登場した、**リポジトリ単位の同期を簡単にするツール**です。

- 特定のリポジトリ（または部分集合）を追跡

- 自動バックフィル＋その後のライブ同期をまとめて処理

- 全ネットワークをミラーしたい場合や、特定アカウント群を確実に同期したい場合に便利

- Jetstreamが「イベントストリーム」向きなのに対し、Tapは「リポジトリ同期」向き

### 5. Hubble（全ネットワークの公開ミラー）

2026年3月に発表された、**Atmosphere全体の公開データミラー**構想です。

- 全公開リポジトリをリアルタイムで同期・保存

- PDSがダウンしてもデータが残るようにする耐障害性向上が目的

- 暗号署名付きなので改ざんできない

- 個人のアカウント復旧や、研究・分析用の安定したデータ源として期待されている

### 6. AppView（アプリケーション層）

最上位の「意味のあるビュー」を作る層です。

- FirehoseやJetstreamを消費して、タイムライン・いいね数・検索・フィードなどを構築

- Bluesky公式AppViewが代表例

- クライアントは通常、ユーザーのPDS経由でAppViewにクエリする設計

- 同じデータを使って、異なるAppView（異なるモデレーションやアルゴリズム）を複数作れるのがAT Protocolの特徴

### 7. その他の補助的なアクセス方法

| 方法 | 内容 | 主な用途 |

|------|------|----------|

| **直接PDSアクセス** | `getRepo` / Record取得 | 特定ユーザーのデータ取得・バックアップ |

| **CARエクスポート** | リポジトリを一括ダウンロード | オフライン分析・移行 |

| **Bluesky API / HTTP Reference** | 高レベルなエンドポイント（タイムラインなど） | アプリ開発の手軽な入口 |

| **Rainbowなどファンアウト** | Firehoseの再配信用 | 大規模消費者の負荷分散 |

### 使い分けの目安

- **手軽にリアルタイム＋過去も見たい** → Jetstream v2

- **完全な検証・生データが必要** → Relay Firehose

- **特定リポジトリを確実に同期したい** → Tap

- **ネットワーク全体の安定したコピーが欲しい** → Hubble

- **アプリとして使う・集計されたデータが欲しい** → AppView / Bluesky API

全体の流れを簡単に図にするとこうなります：

```

PDS (Repository)

↓ イベント

Relay → Firehose（生・検証可能）

↓

Jetstream / Tap / Hubble など（加工・フィルタ・アーカイブ）

↓

AppView（インデックス・クエリ用ビュー）

↓

クライアントアプリ

```

特定の層（例：Tapの使い方、Hubbleの現状、Firehoseの消費方法など）をもっと深掘りしたい場合は教えてください。Blueskyのモデレーションは、**「スタック可能（Stackable）」で分散型の設計**が大きな特徴です。従来の中央集権型SNSとは異なり、公式の基準をベースにしつつ、ユーザーが追加のモデレーションサービスを重ねて選べる仕組みになっています。

### 基本的な考え方

Bluesky（AT Protocol）のモデレーションは、以下の3つの原則に基づいています：

1. **役割の分離**

モデレーション（Labeler）は、ホスティング（PDS）やアイデンティティ管理とは独立して動く。これにより、過度な権力集中を防ぐ。

2. **分散運用**

単一の組織がすべてを決めない。複数のLabelerが存在し、ユーザーが選択できる。

3. **クライアント主導**

最終的に何を表示・非表示・ぼかすかを決めるのはクライアント（アプリ）とユーザー。

### 主要な仕組み

| 要素 | 内容 | 役割 |

|------|------|------|

| **Labeler（ラベラー）** | コンテンツやアカウントに「ラベル」を付けるサービス | モデレーションの本体 |

| **Label（ラベル）** | 「porn」「gore」「intolerance」などの判定結果 | 表示制御の根拠になる |

| **Ozone** | Blueskyがオープンソース化したモデレーションツール | 独立Labelerを簡単に運営できる |

| **公式Labeler** | Bluesky自身が運営する `@moderation.bsky.app` など | デフォルトの基盤 |

| **ユーザー選択Labeler** | コミュニティや個人が運営する追加サービス | 上乗せでカスタマイズ |

ラベルは投稿・アカウント・リストなどに付けられ、AppViewに同期されます。クライアントはそれを見て「非表示」「ぼかし」「警告表示」などを決めます。

### ユーザー側でできること

- **公式モデレーション**をデフォルトで利用（コミュニティガイドラインに基づく）

- **追加のLabeler**を購読して、より厳しい/緩いフィルタを重ねる

- 成人向けコンテンツ・暴力的な内容・不寛容など、カテゴリごとに「表示 / 警告 / 非表示」を設定

- ミュートリスト・ブロック・ミュートワードの利用

- 通報機能（2025年時点で通報理由が大幅に拡充されている）

### 公式の運用（Bluesky側）

- 人間のモデレーターが中心（自動化も併用）

- **ストライク制**を導入（2025年11月頃から本格運用）

- Critical / High / Moderate / Low の4段階で重大度を判定

- 違反が蓄積すると、警告 → 一時停止 → 永久BANと段階的に強化

- プロアクティブな検知（スパム、CSAM、スラーなど）と、ユーザー通報の両方を活用

- アピール（異議申し立て）の仕組みあり

### 技術的な位置づけ

```

ユーザーの投稿（PDS）

↓

Firehose / Jetstream などで流れる

↓

Labeler がラベルを付与

↓

AppView がラベルを添付して返す

↓

クライアントがユーザー設定に基づいて表示制御

```

PDSやRelay自体も、法律対応や極めて有害なコンテンツに対してアカウント停止（Takedown）を行う権限を持っていますが、基本的には「ラベル」によるソフトな制御が主流です。

### まとめ

Blueskyのモデレーションは、

- **公式が最低限の安全を担保**しつつ

- **ユーザーが追加のフィルタを自由に重ねられる**

- **誰でも自分のLabelerを立てられる**

という「積み重ね可能」な設計です。完璧な解決策ではなく、まだ発展途上の部分もありますが、中央集権的なモデレーションの限界を超える試みとして評価されています。

特定の部分（例：Ozoneの使い方、実際のラベルの種類、ストライク制の詳細、コミュニティLabelerの例など）をもっと詳しく知りたい場合は教えてください。BlueskyとMastodonのモデレーションを比較します。両者とも「分散型」を掲げていますが、**権力の所在と仕組みが大きく異なります**。

### 核心の違い（一言で）

| 項目 | Mastodon | Bluesky |

|------|----------|---------|

| **モデレーションの主体** | **サーバー（インスタンス）管理者** | **Labeler（ラベラー）サービス** ＋公式チーム |

| **基本単位** | サーバー単位のコミュニティ | ネットワーク全体＋ユーザー選択 |

| **権力の所在** | 各インスタンスの管理者に強い権限 | 公式が基盤を作り、ユーザーが上乗せ可能 |

| **効果の範囲** | 主に自サーバー内（他サーバーは制限） | ラベルは広く伝播し、クライアントが解釈 |

### 詳細比較

**1. モデレーションの仕組み**

- **Mastodon**

- 各サーバーが独自のルールを持ち、管理者が直接アカウントを**Silence（制限）**や**Suspend（停止・削除相当）**する。

- 問題のある他サーバーに対しては**Domain Block**（ドメインブロック）で対応。

- Silence：コンテンツを隠す（フォロー中は見える場合あり）

- Suspend：ほぼ完全に遮断

- モデレーションは「ローカル」に効く。他サーバーのユーザーを直接BANすることはできない。

- **Bluesky**

- コンテンツやアカウントに**Label（ラベル）**を付ける方式。

- 公式Labelerが基盤を提供し、ユーザーが追加のLabelerを購読して重ねる（Stackable）。

- 最終的な表示制御はクライアントとユーザー設定が行う。

- 公式はストライク制などを導入して段階的に対応。

**2. ユーザー体験の違い**

| 観点 | Mastodon | Bluesky |

|------|----------|---------|

| デフォルトの安全性 | 選んだサーバー次第で大きく変わる | 公式が一定の基準を担保 |

| カスタマイズ性 | サーバーを変えるか、個人でミュート/ブロック | Labelerを自由に追加・調整可能 |

| 問題のあるコンテンツへの対応 | 管理者依存が強い。管理者不在だと放置されやすい | 公式＋コミュニティLabelerで対応しやすい |

| 他コミュニティとの関係 | Domain Blockで「切断」しやすい（分裂が起きやすい） | ラベルで「見え方」を変えるため、ネットワーク全体はつながりやすい |

| 移行コスト | サーバーを変えると比較的大変（フォロー関係など） | アカウント移行が比較的スムーズ（PDS移動） |

**3. 強みと弱み**

**Mastodonの強み**

- 小規模で価値観の近いコミュニティを作りやすい

- 管理者が強い権限を持つので、迅速で厳格な対応が可能

- 「このサーバーの文化を守る」という明確な境界がある

**Mastodonの弱み**

- サーバーによってモデレーションの質・方針がバラバラ

- 管理者の負荷が大きく、燃え尽きやすい

- Domain Blockが連鎖して「島宇宙化」しやすい

- 大きなサーバーと小さなサーバーで体験差が大きい

**Blueskyの強み**

- 公式が一定の安全基準を提供しつつ、ユーザーが追加で調整できる

- ラベル方式なので「完全に消す」より「見え方を変える」柔軟性がある

- コミュニティ特化のLabeler（例：特定のハラスメント対策）を重ねやすい

- ネットワーク全体が分断されにくい

**Blueskyの弱み**

- 公式依存がまだ強く、真の分散は発展途上

- ラベルは「見えなくする」だけで、根本的な追放はしにくい（検閲耐性が高い反面）

- 悪質なアカウントが他の場所で活動し続けやすい

### まとめ：どちらが「良い」か

- **「価値観の合う小さなコミュニティで厳格に管理したい」** → Mastodonが向いている

- **「大きなネットワークで、公式の安全網＋自分好みのフィルタを重ねたい」** → Blueskyが向いている

Mastodonは**「サーバーという城を守る」**モデル、Blueskyは**「ラベルというフィルターを重ねる」**モデルです。どちらが優れているというより、求めるコミュニティの形が違う、という理解が近いです。

かなり相性がいいです。むしろ Standard.siteとJetstream v2を組み合わせることで、「個人サイト帝国」のATProto側の設計がかなり明確になります。

一言でいうと、

Standard.site = 個人サイトをAT Protocol上の「出版物」として定義するデータモデル
Jetstream v2 = そのAT Protocol上で発生する出版・更新イベントを取得するデータプレーン

です。

1. Standard.siteとは何か

Standard.siteは、AT Protocol上で長文コンテンツを扱うための共有Lexiconです。

現在の仕様では主に、

site.standard.publication
site.standard.document
site.standard.graph.subscription
site.standard.graph.recommend

などを定義しています。つまり、

あなたのWebサイト
        ↓
site.standard.publication
        ↓
site.standard.document
        ↓
AT Protocol

という対応関係を作ります。公式Quick Startでも、通常のWebサイトを維持したままPublicationとDocumentをATProto上に登録し、.well-known/site.standard.publicationなどでWebサイトとの対応関係を検証する方式になっています。(Standard.site)

重要なのは、Standard.siteがホスティングサービスではないことです。

あなたのサイトは従来通り、

example.com

に置けます。

そしてそのコンテンツの「ATProto上の表現」を自分のPDSに持たせる。

実際、2026年にはHugoやAstroなどの既存サイトからStandard.siteへ発行する実装例が出ています。(Redowan's Reflections)

2. Jetstream v2はその「出版物」をどう見るのか

ここが重要です。

Standard.site：

「これは私のサイトです」
「これは私の記事です」

というデータモデルを作る。

Jetstream v2：

「誰がpublicationを作った」
「どの記事が作られた」
「どの記事が更新された」
「いつrecommendされた」

というイベントを取得する。

したがって、

Standard.site
     │
     │ records
     ▼
ATProto Repository
     │
     │ events
     ▼
Relay / Firehose
     │
     ▼
Jetstream v2
     │
     ├── Live
     ├── Replay
     └── Snapshot

という関係になります。

3. つまり「Standard.site＋Jetstream v2」はRSSの次世代版になり得る

ここが個人的には一番面白いところです。

従来のブログ配信：

個人サイト
    ↓
RSS / Atom
    ↓
Feed Reader

Standard.site：

個人サイト
    ↓
Standard.site
    ↓
AT Protocol
    ↓
ATProto対応Reader

Jetstream v2まで使うと、

個人サイト
    ↓
Standard.site records
    ↓
AT Protocol
    ↓
Jetstream v2
    ↓
リアルタイムイベント
    ↓
Reader / Search / AI / Analytics

となる。

つまり、

RSS/Atomが「Feed」だったのに対して、Standard.site＋Jetstreamは「Publication + Event Stream」になる。

4. RSS/Atomとの最大の違い

例えばあなたが記事を書いた場合。

RSS

記事を書く
 ↓
RSS XMLを生成
 ↓
Readerが定期取得

Standard.site

記事を書く
 ↓
site.standard.document
 ↓
自分のPDS
 ↓
AT Protocol

Jetstream v2

document record
 ↓
ATProto event
 ↓
Jetstream v2
 ↓
Subscriber

これによって、

「新しい記事があります」

だけでなく、

「このPublicationにこのDocumentが追加された」

という構造化されたイベントとして扱えます。

これはAIやデータベースとの相性が非常にいい。

5. 「個人サイト帝国」にするとこうなる

あなたが以前考えていた構成にStandard.siteとJetstream v2を正式に組み込むと、私はこうします。

                       あなたのドメイン
                         example.com
                              │
                    ┌─────────┴─────────┐
                    │                   │
                HTML/Web             Feed
                    │                   │
                    │                RSS/Atom
                    │
                    ▼
             Standard.site
                    │
          ┌─────────┴─────────┐
          ↓                   ↓
 Publication             Documents
          │                   │
          └─────────┬─────────┘
                    ↓
                 自分のPDS
                    │
                    ↓
               AT Protocol
                    │
             ┌──────┴──────┐
             ↓             ↓
          Relay        AppView等
             │
             ↓
        Jetstream v2
             │
       ┌─────┼─────┐
       ↓     ↓     ↓
    Replay Live Snapshot
       │     │     │
       └─────┼─────┘
             ↓
      Personal Data Lake
             │
       ┌─────┼─────┐
       ↓     ↓     ↓
      AI   Search Analytics

この構成なら、WebサイトそのものとATProto側のデータを二重化するのではなく、役割分担できます。

6. さらに重要なのが「自分のPDS」

ここを誤解するとStandard.siteの意味が変わってしまいます。

Standard.siteは、

「Blueskyに記事を投稿する仕組み」

ではありません。

基本的には、

「自分のPublicationとDocumentをATProtoのRepositoryに記録するための共通スキーマ」

です。

公式仕様でもPublicationとDocumentはATProto Recordsとして作成され、PublicationとWebサイトは.well-knownで対応付けます。(Standard.site)

したがって、

あなた
 │
 ├── example.com
 │
 └── PDS
       └── site.standard.*

という構造にできます。

これはIndieWebとATProtoの接続点としてかなり美しい。

7. Jetstream v2を使うと「誰でも読める出版ネットワーク」に近づく

例えば1000人の個人サイトがStandard.site対応したとします。

すると、

1000 Websites
      │
      ↓
Standard.site
      │
      ↓
AT Protocol
      │
      ↓
Jetstream v2
      │
      ↓
1つのイベントストリーム

という構造が作れる。

そしてReaderは、

site.standard.publication
site.standard.document

だけを購読すればいい。

従来のWebでは、

Google
 ↓
Crawler
 ↓
Index
 ↓
Search

が必要でした。

Standard.site＋ATProtoでは、

Publisher
 ↓
ATProto Record
 ↓
Network
 ↓
Reader / Indexer

という別の発見経路ができます。

実際、Standard.siteの仕様は「content discovery, indexing, portability」を目的として設計されています。(Tangled)

8. ここにJetstream v2のReplayが効く

これはv1との決定的な違いです。

例えばあなたが2026年8月にReaderを作ったとします。

従来のライブストリームだけなら、

Reader開始
      ↓
これから発生する記事

しか見えません。

Replayがあると、

2026/07/01
     ↓
Standard.site records
     ↓
Replay
     ↓
2026/08/14
     ↓
Live

とできます。

つまり新しいReaderが、

過去1か月分のStandard.site出版物を自動的に追いつく

ことができます。

これは非常に重要です。

9. 「Standard.site＋Jetstream v2」は検索エンジンにもなる

例えば、

site.standard.document

をJetstreamから収集。

↓

自分のDBに保存。

↓

全文検索。

↓

Embedding。

↓

Reranker。

↓

LLM。

すると、

ATProto版のブログ検索エンジン

を個人でも作れます。

さらに、

publication
document
subscription
recommend

を利用すれば、

「誰が誰の出版物を購読しているか」

「どの記事が推薦されているか」

というSocial Graphまで取得できます。

現在のStandard.site仕様にはsubscriptionとrecommendのGraph Lexiconも存在します。(Tangled)

10. ここで「個人サイト帝国」が一気に面白くなる

最終的には、

                  個人サイト
                     │
                 Standard.site
                     │
              ┌──────┴──────┐
              ↓             ↓
           Publication    Document
              │             │
              └──────┬──────┘
                     ↓
                   PDS
                     │
                AT Protocol
                     │
           ┌─────────┼─────────┐
           ↓         ↓         ↓
        Bluesky   Reader     Search
                     │
                     ↓
                Jetstream v2
                     │
             ┌───────┼───────┐
             ↓       ↓       ↓
           Replay   Live   Snapshot
             │       │       │
             └───────┼───────┘
                     ↓
               Personal DB
                     │
             ┌───────┼───────┐
             ↓       ↓       ↓
            AI     RAG     Analytics

になります。

11. そしてActivityPub / Webmention / Nostrを加える

ここまで来ると、あなたが考えていた構成が非常にきれいに整理できます。

レイヤー	技術	役割
Canonical Web	個人サイト	原本
Publication Schema	Standard.site	個人サイトをATProto上で標準化
Pull	RSS / Atom	Feed Reader
Web Graph	Webmention	Webサイト間リンク
Federation	ActivityPub	Fediverse
ATProto Social	ATProto	Bluesky / Atmosphere
ATProto Event Plane	Jetstream v2	Live / Replay / Snapshot
Signed Event Network	Nostr	独立した署名イベント
Intelligence	AI / RAG	検索・分析・推薦

これを見ると、Jetstream v2はStandard.siteと同じものではありません。

Standard.siteが「何を公開するか」を定義し、Jetstream v2が「その公開データがネットワーク上でどう変化したか」を運ぶ。

12. かなり重要な違い

この2つを混同しないことが重要です。

Standard.site

Data Model

Publication
Document
Subscription
Recommend

Jetstream v2

Data Transport / Event Access

Create
Update
Delete
Replay
Live
Snapshot

したがって、

Standard.site = ATProto版「Web出版規格」

に近く、

Jetstream v2 = ATProto版「出版イベントストリーム」

に近い。

13. そして、ここから「RSS 2.0 → Standard.site + Jetstream」という進化が見える

かなり大胆に世代比較すると、

世代	出版モデル	発見	更新通知	履歴
Web初期	HTML	Link	なし	Web Archive
RSS	XML Feed	Feed URL	Polling	Feed依存
Atom	XML Feed	Feed URL	Polling	Feed依存
ActivityPub	Activity	Federation	Push	サーバー依存
ATProto	Records	Relay/AppView	Event Stream	Repository
Standard.site	Publication/Document	ATProto	ATProto events	PDS
Standard.site + Jetstream v2	Publication/Document	ATProto	Live + Replay	Network Archive/Snapshot

この最後の行が非常に重要です。

Standard.siteだけでは「ブログをATProtoに載せる」段階。

Jetstream v2まで組み合わせると、「ATProto上のオープン出版ネットワークを継続的に観測・同期する」段階になる。

結論

あなたの「個人サイト帝国」構想との関係では、私はこう定義します。

Standard.site = 個人サイトをATProtoの市民にする。

Jetstream v2 = その市民たちの活動をリアルタイム＋過去から観測できる公共データプレーンにする。

そして、

個人サイト
↓
Standard.site
↓
ATProto
↓
Jetstream v2
↓
Personal Data Lake
↓
AI / Search / RAG / Analytics

というパイプラインが成立します。

ここまで行くと、Standard.siteは単なる「Bluesky版ブログフォーマット」ではありません。**個人サイトをWebの外側にあるATProtoの出版ネットワークへ接続する“出版プロトコル”**になってきます。

さらにJetstream v2のReplayによって、新しく参加したReaderや検索エンジンが過去の出版物を遡ってネットワークの現在状態まで同期できる。これがStandard.siteを単なるスキーマから**「オープンな分散出版エコシステム」へ発展させる重要なピース**です。実際、2026年には既にHugo、Astro、Craft CMSなどからStandard.siteへ発行する実装例が出始めています。(Redowan's Reflections)

そして、この構成にWebmention＋ActivityPub＋Nostrを加えると、「個人サイトを原本にして、4種類のネットワークを用途別に使い分ける」という、かなり本格的なPersonal Internet Stackになります。

WebmentionとJetstream v2は、かなり補完関係にある

一見すると全く別物です。

Webmention → Web上の「リンクされた」という通知
Jetstream v2 → AT Protocol上の「イベントが発生した」というストリーム

しかし、個人サイトを中心に考えると、

Webmention = WebのLink Graph
Jetstream v2 = ATProtoのEvent Graph

と整理できます。

この2つを接続すると、個人サイトを中心にWebとATProtoを双方向に観測する仕組みが作れます。

1. まず役割が違う

	Webmention	Jetstream v2
対象	Webサイト	AT Protocol
基本単位	URLへのリンク	ATProto Record/Event
通知	「あなたの記事にリンクした」	「Recordが作成・更新・削除された」
通信	HTTP	WebSocket / HTTP
方向	Site → Site	Network → Consumer
リアルタイム性	通知ベース	Live Stream
過去データ	基本的に相手サイト依存	Replay / Snapshot
主用途	コメント・リンク通知	データ収集・同期・分析
性質	Link Layer	Event/Data Layer

WebmentionはW3C Recommendationで、あるWebページから別のWebページへのリンクを通知する仕組みです。

一方Jetstreamは、AT ProtocolのFirehoseを開発者が扱いやすい形で購読するためのサービスで、v2では過去データのReplayが加わっています。

2. Webmentionは「WebのActivityPub」ではない

ここは重要です。

Webmentionは、

Aの記事
  ↓
Bの記事からリンク
  ↓
Aへ通知

という非常に単純な仕組みです。

例えば、

あなたのサイト
https://example.com/article-a

       ↑
       │ Webmention
       │
他人のサイト
https://someone.example/article-b

となる。

SNSの「いいね」や「フォロー」を中心に設計されたものではありません。

Webそのもののリンク構造を利用する。

ここが強みです。

3. Jetstream v2は逆に「イベント」を見る

Jetstream v2の場合は、

ATProto
   ↓
Record
   ↓
Event
   ↓
Jetstream

です。

例えばStandard.siteを使っているサイトなら、

Publication
Document
Subscription
Recommend

などのRecordがATProto上で変化します。

Jetstream v2はそれを、

Create
Update
Delete

というイベントとして取得できる。

つまり、

Webmentionは「リンク関係」

Jetstreamは「状態変化」

です。

4. ここを接続すると面白い

例えばあなたが個人サイトに記事を書いたとします。

あなたのサイト
       │
       ↓
    Article
       │
 ┌─────┼─────┐
 ↓     ↓     ↓
Web   AP   Standard.site
       │       │
       │       ↓
       │    ATProto
       │       │
       │       ↓
       │   Jetstream v2
       │       │
       └───┬───┘
           ↓
       Personal DB

そして誰かが、

自分のブログからリンクする
Mastodonで反応する
Blueskyで反応する
Standard.site上でRecommendする

と、それぞれ違う経路からイベントが発生する。

これを自分のデータベースに集める。

5. すると「Personal Social Graph」ができる

例えば、

                    あなたの記事
                         │
          ┌──────────────┼──────────────┐
          ↓              ↓              ↓
      Webmention     ActivityPub     ATProto
          │              │              │
      Blog A          Mastodon       Bluesky
          │              │              │
          └──────────────┼──────────────┘
                         ↓
                  Personal Database
                         ↓
                    Social Graph

となります。

ここが巨大SNSとの決定的な違いです。

XやBlueskyでは、

プラットフォームがSocial Graphを持っている。

個人サイト＋Webmention＋Jetstreamでは、

自分自身が複数ネットワークから得られる関係情報を統合できる。

6. WebmentionとJetstream v2の最大の違いは「Pullできるか」

ここがかなり重要です。

Webmentionは基本的に、

イベントが発生したら通知してください

というPush型。

例えば、

B → AへWebmention

です。

しかし、あなたが今日システムを構築した場合、

「過去3年間に誰が自分の記事へリンクしたのか？」

はWebmentionだけでは必ずしも復元できません。

Jetstream v2はReplayを持つ。

過去
 │
 ↓
Replay
 │
 ↓
現在
 │
 ↓
Live

という構造です。

したがって、

Jetstream v2のReplayは「後から参加したコンシューマーが過去のイベントを追いつく」ための仕組み

として非常に強い。

7. ただしWebmentionにはJetstreamにない強みがある

逆も重要です。

JetstreamはATProtoのイベントを扱います。

したがって、

Bluesky
ATProto
Standard.site

の世界には強い。

しかし、

example.com
wordpress.example
blog.example
static-site.example

のような普通のWebサイトはJetstreamの対象ではありません。

ここでWebmentionが必要になる。

つまり、

             Internet
                 │
       ┌─────────┴─────────┐
       ↓                   ↓
      Web                ATProto
       │                   │
 Webmention           Jetstream v2
       │                   │
       └─────────┬─────────┘
                 ↓
        Personal Social Graph

となります。

8. これは「Web Graph＋Social Graph」の統合になる

従来の検索エンジンは、

Web
 ↓
Crawler
 ↓
Link Graph
 ↓
Search

です。

SNSは、

Users
 ↓
Social Graph
 ↓
Feed

です。

これを個人側で統合すると、

Web Graph
   +
Social Graph
   +
Event Stream
   ↓
Personal Knowledge Graph

になります。

これはかなり面白い。

9. さらにAI/RAGとの相性が非常にいい

例えば、

「この記事について、WebとBlueskyの両方でどんな議論が起きた？」

という質問に対して、

Article
 │
 ├── Webmention
 │     ├── Blog A
 │     ├── Blog B
 │     └── Blog C
 │
 └── ATProto
       ├── Post A
       ├── Post B
       └── Post C

を統合する。

そこにLLMを載せれば、

Article
 ↓
Webmention Graph
 +
ATProto Events
 ↓
Semantic Search
 ↓
LLM
 ↓
「反応の構造」

という処理ができます。

単なるアクセス解析よりはるかに面白い。

10. そして「Webmention → Jetstream」というブリッジも考えられる

ここからがさらに面白い部分です。

例えばあなたのサイトでWebmentionを受け取ったら、

Webmention
     ↓
Validate
     ↓
Store
     ↓
ATProto Record

として、Webmentionイベント自体をATProto上に記録する。

すると、

他人のWebサイト
      ↓
Webmention
      ↓
あなたのサイト
      ↓
ATProto Record
      ↓
Jetstream
      ↓
Personal Data Lake

という流れができます。

つまり、

WebmentionをATProtoのイベントストリームへブリッジする

わけです。

11. 逆方向もできる

逆に、

ATProto
 ↓
Jetstream
 ↓
あなたのIndexer
 ↓
Relevant event
 ↓
Webmention

という仕組みも理論的には考えられます。

ただし、これは自動でWebmentionを送るべきかという別問題があります。

例えばBluesky上で誰かがあなたの記事URLを投稿しただけなら、

「その人があなたのサイトへWebmentionを送った」

とは限りません。

したがって、

ATProtoイベント → Webmention

は慎重に設計する必要があります。

12. Standard.siteが入ると、この構造が完成に近づく

ここまでを統合すると、

                        個人サイト
                            │
                      Standard.site
                            │
                         ATProto
                            │
                       Jetstream v2
                            │
                  ┌─────────┼─────────┐
                  ↓         ↓         ↓
                Live      Replay   Snapshot
                  │         │         │
                  └─────────┼─────────┘
                            ↓
                     Personal Data Lake
                            ↑
                            │
                      Webmention
                            ↑
                            │
                     他のWebサイト

になります。

つまり、

Standard.site

「自分の出版物をATProtoに登録する」

Jetstream v2

「ATProto上の出版イベントを取得する」

Webmention

「Web上のリンク関係を取得する」

です。

13. 個人サイト帝国の最終構成

あなたが以前考えていた構想にこれを組み込むなら、私はこう整理します。

                         YOUR DOMAIN
                              │
                    ┌─────────┴─────────┐
                    │                   │
                 Website              Feed
                    │                RSS / Atom
                    │
             ┌──────┴──────┐
             ↓             ↓
        Webmention     Standard.site
             │             │
             ↓             ↓
        Web Graph       AT Protocol
             │             │
             │        ┌────┴────┐
             │        ↓         ↓
             │      Bluesky   Jetstream v2
             │                  │
             │             ┌────┼────┐
             │             ↓    ↓    ↓
             │          Replay Live Snapshot
             │             │    │    │
             └─────────────┼────┼────┘
                           ↓
                   PERSONAL DATA LAKE
                           │
                    ┌──────┼──────┐
                    ↓      ↓      ↓
                   AI     RAG   Analytics

そしてここにActivityPubとNostrを追加する。

                  PERSONAL WEBSITE
                         │
       ┌─────────────────┼─────────────────┐
       ↓                 ↓                 ↓
 Webmention        ActivityPub        Standard.site
       ↓                 ↓                 ↓
    Web              Fediverse        ATProto
                                           │
                                      Jetstream v2
                                           │
                         ┌─────────────────┘
                         ↓
                  Personal Data Lake
                         ↑
                       Nostr

結論

WebmentionとJetstream v2は競合しません。

むしろ、

Webmention = WebのLink Layer
ActivityPub = Federation Layer
Standard.site = Publication Layer
ATProto = Social Data Layer
Jetstream v2 = Event/Data Plane
Nostr = Signed Event Layer
個人サイト = Canonical Layer

と分担させると非常に綺麗です。

特に重要なのは、Webmentionが「Webそのもの」に接続し、Jetstream v2が「ATProtoネットワーク」に接続すること。

その2つを自分のサイト側で収集・正規化すれば、

「自分のサイトを中心に、Web＋Fediverse＋ATProto＋Nostrの反応を自分で保存する」

という構成が可能になります。

これは従来の「ブログをBluesky/Mastodonへクロスポストする」という発想とは全く違います。

クロスポストではなく、Personal Internet Gatewayを自分のドメインに持つ。

そしてJetstream v2のReplayが加わったことで、そのGatewayは**「今後発生するイベントを受け取るだけ」ではなく、「過去のATProtoイベントを遡って自分のSocial Graphを構築する」**方向へ進めるようになった、というのが最大のポイントです。

adsense