2026/07/24 3:23
ATProto の構築
RSS: https://news.ycombinator.com/rss
要約▶
日本語翻訳:
ベルリンのローカルファーストカンファレンスにおいて、AI コーディングと ATProto の浸透に関する広範な議論が巻き起こりました。著者は、ATProto を公開でコミュニティ主導の標準に基づく相互運用可能なアプリケーションの基盤として envisioned (構想) していますが、現在の進行方向はこの目標と整合していないと感じています。
主な目的は、Yelp、GoodReads、Letterboxd などのサービスに見られるデータロックインモデルを置き換えるレビュースイートアプリケーションを開発することです。求められる機能には、異なる強みを持つ複数のツール（例：執筆、リストの公開、ウェブサイトでの共有）を可能にする共有で公開的なデータモデルが含まれます。
ユーザーのプライバシーニーズは、3 つのグループに分類されます：インフルエンサー向け（公開のみ）、公的・私的の混合、および完全にプライベート（友人グループまたは自己のみ）。現在、ATProto はすべて「公開のみ」という前提を採っており、この前提はそのストレージシステムおよび出版サービスの構造に組み込まれています。その結果、ユーザーは単一のシステムとして認識しているにも関わらず、開発者は公開データと非公開データの処理のために 2 つの異なるアプリケーション/システムを維持する必要が生じています。
ATProto Personal Data Server (PDS) は直接的なアクセスを提供しますが、git のようなプッシュ/プルではなくプロトコルを「話す」必要があります。オフラインサポートを実現するには、一時的に保存してオンライン時にプッシュするという標準的なベストプラクティスとは異なる、独自ストレージおよび同期システムが必要となります。現在の ATProto の設計は、データ所有権、ネットワーク利用のオプション性、公開/非公開データの統一的な取り扱いうえに関わるローカルファーストの原則と対立しています。
しかしながら、コミュニティは「許可されたデータ」（推奨される用語：「プライベートデータ」）を積極的に設計しており、これには公開プロトコルとは独立した新しいデータ構造および検証方法が追加されています。この設計はまだ初期段階にあるため、コミュニティ内の哲学的な不一致が存在するにもかかわらず、改善の余地があります。ATProto が公開・非公開データの統一的な取り扱いをサポートするように適応すれば、ユーザーに完全な所有権を付与し、ベンダーロックインなしに多様なツールを可能にすることができます。逆に、現状を維持することは、柔軟で真にオフライン対応できるプラットフォームを必要とする開発者を孤立させるリスクがあります。
本文
ATProto への期待と懸念：2026 年ローカルフースト・カンファレンスからのレポート
Bluesky の Atmosphere プロトコル は次世代アプリケーションの基盤となり得ますが、発展方向に予想外の課題が見え、失望を招いています。
ベルリンで開催された「Local First Conference」に参加し、以下の洞察を得ました。
- AI によるコーディングはすでに業界標準になりつつあります。
- ATProto の浸透度は想像以上でした（Bluesky 関係者の多くが現地に出向いています）。
私にとって ATProto が「公共的・コミュニティ主導の標準」への帰還を実現するものだと確信しています。しかし、現状の設計は私の目標を阻害しており、新しいアプローチが必要であると感じています。本稿では、私が作りたいシステムと、ATProto の設計がそれを支えたり阻害したりする点を分析します。
目指すシステム：リビュー（レビュー）アプリスイート
私は最小限のシステムとして、あらゆる分野（飲食店、書籍、映画等）で Yelp や GoodReads などの代替手段となるアプリケーションスイートを構築したいと考えています。
ビジネスモデルの違いによる置換
- 単なる機能面での代替ではなく、ビジネスモデルの違いから既存プラットフォームを置き換えるのが目標です。
- 「データは企業が所有する」という従来の構造には同意しません。
ローカルフースト（Local First）データの必要性
- データの所有権: 企業にデータを閉じ込められたくありません。
- 例：Yelp のブックマークは共有・スクリプト化・バージョン管理ができません。
- ワークフローの柔軟性:
- ツール A でレビューを書く。
- ツール B でベストオブリストを作成する。
- ウェブサイトで公開リストを共有する。
- これらを一つのアプリで完結させる必要はありません。
- プラットフォーム依存からの脱却: プレーンテキストで Hugo を使って自己公開するのは限界があります。データの使い道を自分でコントロールしたいです。
公共と私有：ユーザーの多様なニーズ
現在のアプリケーションは「インフルエンサー志望者」向けですが、以下の層を取り残しています。
ユーザーセグメント
- インフルエンサー志望者: 全世界に向けてレビューを公開し、追随者を集めたい人々（既存アプリは対応）。
- ハイブリッド型（私）: シチュエーションに応じて「公共」と「私有」の両方のレビューを提供したい人々。
- 例：創業者向けの本紹介（特定公開）、個人メモ、家族限定情報。
- 完全非公開型（妻の事例）: 友人グループや自分だけで閲覧するもののみをレビューしたい人々。
現状の問題点
- 多くのアプリは「レビュー＝全公開」という前提しか許しません。
- 「インフルエンサー化」を強いる構造: 「あの人が好きななら私も」という追随ロジックが背景にあります。
- 大半のユーザーはインフルエンサーになりたいと思っていません。
- ネット上の追随者を持つ苦労を理解しています。
- 自分の意見が他者の評判に影響するのを避けたいです。
- 必要な機能: ユーザー自身が**「完全に公開」「完全な私有」「個人ごとの部分共有」**を選択できるシステムが必要です。
ATProto との整合性の問題
優れた点：アイデンティティ解決
- ATProto は大規模なアイデンティティ解決用に設計された最初のプロトコルです。
- 利点: アプリ開発者が独自に認証やソーシャルグラフを実装する必要がありません。
- ATProto アイデンティティを統合すれば、基本機能が即座に利用可能になります。
致命的な欠落：公開専用プロトコル
- 根本的な制約: 現在の ATProto は**「公開専用」**です。
- すべての動作が全世界に公開されることを前提とした設計になっています。
- この概念は保存システムから発行サービスまで全ての要素に組み込まれています。
- 「許可付きデータ（Permissioned Data）」への課題:
- コミュニティは私有データの設計を進めていますが、この名称自体がユーザーの振る舞いを正しく表現していないと批判します（単に「私有データ」と呼ぶべきです）。
- 哲学的な対立: 提案される設計では、「公衆向けブロードキャスト」と「許可付きデータ」は本質的に異なるものとして扱われますが、私は**「実質的には同一であり、アクセス権限だけが違う」**と信じています。
- レストランレビューも、書評クラブ内での共有も、家族間での共有も「レビュー」としての性質は同じです。
- 「全世界公開」は特殊ケース（読み込み権限＝世界中）に過ぎません。
アプリ開発者にとってのジレンマ
- 実質的な二重構造: 開発者は「公共用」と「私有用」の2 つの異なるシステムとプロトコルを書く必要がありますが、ユーザーはそれを 1 つのアプリとして認識しています。
- 混在するリスク:
- 私有投稿を公開に変更したい場合でも、データの修正ではなく「削除＋新規作成」という非効率な処理を強いられる可能性があります。
- 「いいね」やリポスト、リンクがどう扱うか明確ではありません。
- PDS（個人データサーバー）:
- PDS は開発者のデータへの直接アクセスを提供します。
- 複数のアプリが参照するため、すべてのアプリが二つのバージョンを実装する必要が生じ、ユーザーに対して実態を隠さざるを得なくなります。
ローカルフースト原則との衝突
Git レポジトリという誤解から学んだこと
- 過去の認識: PDS が Git リポジトリのように「自分自身のコピーを持ち、変更を加えてプッシュする」と考えていました。
- 現実は異なる:
- PDS は単なるサーバーであり、データはプロトコル経由で通信されます。
- 「データを所有」できるのは、保存場所を変更できる自由度があるためです。
- 完全性の保証（暗号化ベース）もサーバー側限定であり、クライアント側での独立したデータ管理には利用できません。
オフライン機能の欠如
- ATProto は設計原則の一部（アイデンティティなど）を満たしていますが、**「データは指先にある」「ネットワークがオプション」**という点で欠落しています。
- オフライン時の限界:
- リビューを記録したい場合、一時的領域に保存してオンライン復帰時にプッシュする必要があります。
- これは独自の保存・同期システムの実装を強制され、「ローカルフースト」の精神から逸脱します。
複合的な複雑さ
私有データを加えると状況は以下のように悪化します：
- オフラインデータ用のカスタムローカル保存が必要になる。
- 公開用と私有用に異なる同期システムを構築する必要が生じる。
- オンラインアプリでも、プライベート/パブリック両方のデータに対して別々の読み書きロジックを実装し続ける必要がある。
結論として: 「公共か私有かの選択」を許容するアプリケーション開発者にとって、ATProto は現在**「半分逆風」**の状態にあります。
今後の展望と願い
現状の判断
- Permissioned Data の設計はまだ未熟であり、改善の余地があります。
- アイデンティティや語彙システムを部分的に流用しつつ、残りの部分を独自設計することも可能かもしれません。
- しかし、提案された設計を採用しても、私の求める「ローカルフースト」な体験には至らない可能性が高いです。
根本的な願い
私は 1990 年代生まれであり、インターネットをコミュニティと標準化グループが維持する時代に育ちました。その時代の精神を取り戻したいです：
- 大規模で回復力のある標準プロトコル: ユーザーを支援するために設計されたもの。
- ATProto の機会: 数十年後の新しいタイプのプロトコルとして成功することを願います。
- すべてのアプリケーション開発者（特に私のような個人開発者）が構築したいシステムになることを強く期待しています。
現状の設計では哲学が乖離しすぎていると感じますが、コミュニティとの対話を深め、より良い解決策への道筋を見つけられることを願っています。