SNSプラットフォームBlueskyの新CEOに就任したToni Schneider氏（前Automattic CEO）が、AT Protocol（分散型のソーシャルネットワーキング用プロトコル）を軸にした「ATmosphere」というエコシステム構想を語っています。これはSNSアプリの話にとどまらず、分散型プロトコルを自社基盤に採用するかどうかという、SREやインフラ担当者にも関係のある判断材料を含んでいます。
Blueskyというアプリ自体を使うユーザーと、AT Protocol上でサービスを構築する開発者は、必ずしも同じ利害を持ちません。この構図は、標準プロトコルを採用する側と、それを運用・拡張する側の利害が分かれる、という形で多くの分散システムに共通する構造です。今回は「自社のシステムに分散型プロトコルや相互運用オープン標準を採用すべきか」を、可用性設計とインフラ運用の観点から整理します。
どんな場面でこの判断が必要になるか
SNS連携機能を自社サービスに組み込む、あるいは複数ベンダーのシステムを跨いだID・データ連携基盤を設計する場面で、この種の判断は避けて通れません。
たとえば社内SNS的な機能やコミュニティ機能を持つSaaSで、他社サービスとの相互運用（フォロー関係やコンテンツの持ち出し）を求められるケースがあります。あるいはマイクロサービス間の疎結合を進める中で、独自APIではなく標準プロトコルを採用するかどうかの選定に直面するケースもあります。
AT Protocolのように「中央のプラットフォーム企業が管理しつつ、仕様は公開してだれでも実装できる」という設計は、単一ベンダーAPIとフルオープンソースの中間に位置します。この中間的な立ち位置こそが、判断を難しくしている要因です。
判断軸を整理する
運用主体の継続性が1つ目の軸です。プロトコルの仕様策定・リファレンス実装の保守が特定企業に依存している場合、その企業の経営判断（CEO交代、資金調達の失敗、方針転換）がインフラの寿命に直結します。BlueskyもCEOが交代し、収益化の模索が続いている段階です。こうした背景は、プロトコルの長期サポートを保証する主体が誰かを見極める必要性を示しています。
運用コストの構造が2つ目の軸です。分散型プロトコルは、自前でノード（PDS: Personal Data Serverと呼ばれる、ユーザーデータを保持するサーバー）を立てる選択肢と、ホスティング事業者に任せる選択肢があります。自前運用はコンテナ基盤（Kubernetesなど）上での可用性設計・監視体制の構築コストが発生します。委託運用はベンダーロックインのリスクと引き換えにオペレーションコストを下げられます。
オブザーバビリティの成熟度が3つ目の軸です。分散システムでは、ノード間のデータ同期の遅延やファイアウォール外のフェデレーション（相互接続）先の障害切り分けが難しくなります。Prometheus・Grafana・OpenTelemetryといった一般的な監視スタックが、そのプロトコル向けにメトリクスやトレースの標準を持っているかを確認する必要があります。仕様が新しい段階だと、監視のベストプラクティスがコミュニティにまだ蓄積されていないことがあります。
SLO設計のしやすさが4つ目の軸です。SLO（Service Level Objective、サービスが満たすべき品質目標）を定義する際、可用性やレイテンシーの計測点が自社の管理下にあるか、外部の相互運用先に依存するかで難易度が変わります。フェデレーション型のプロトコルでは、自社が制御できない他ノードの遅延が自社のSLIに混入する可能性があります。
選択肢の比較
分散型プロトコルの採用可否を考える際、実務上の選択肢は大きく3つに分かれます。単一ベンダーAPIへの依存、フルセルフホストのオープンソース採用、そしてAT Protocolのようなハイブリッド型の分散プロトコルです。それぞれの特性を整理します。
| 選択肢 | 運用コスト | ロックインリスク | SLO設計の容易さ |
|---|---|---|---|
| 単一ベンダーAPI | 低い（委託前提） | 高い（契約変更に脆弱） | 容易（SLAが明示されやすい） |
| フルセルフホストOSS | 高い（全工程を自社IaCで管理） | 低い（コード資産は手元に残る） | 難しい（自社で計測基盤ごと構築） |
| ハイブリッド型分散プロトコル | 中程度（PDS運用かホスティング委託か選べる） | 中程度（仕様は公開だが主導企業に依存） | 中程度（外部ノード依存分が変動要因） |
この比較からわかるのは、ハイブリッド型は「いいとこ取り」に見えて、実際にはSLO設計の難易度という新しい種類のコストを背負う点です。TerraformなどのIaC（Infrastructure as Code、インフラをコードで定義・管理する手法）で自社ノードの構成を宣言的に管理できても、フェデレーション先の可用性まではコード化できません。
ケース別の推奨
自社サービス内で完結するSNS機能であれば、単一ベンダーAPIかフルセルフホストのオープンソース（Mastodonの基盤であるActivityPubの実装など）を選ぶのが無難です。SLOの計測点が自社インフラ内に収まるため、既存の監視スタックをそのまま流用できます。
他社サービスとのデータ相互運用を製品の差別化ポイントにしたい場合は、AT Protocolのようなハイブリッド型を検討する価値があります。ただしこの場合、SLOは「自社ノードの可用性」と「フェデレーション先との同期遅延」を分けて計測する設計を、導入前に決めておく必要があります。
小規模チームで運用体制がまだ薄い場合は、PDSを自前で立てず、ホスティング事業者（BlueskyのPDSホスティングなど）に委託する形から始めるのが現実的です。運用ノウハウが溜まってから自前運用への移行を検討する順序が、障害対応の仕組み化という観点でも無理がありません。
あえて見送るべき条件
障害対応のオンコール体制がまだ整っていないチームは、分散型プロトコルの自前運用を見送るべきです。フェデレーション由来の障害は原因切り分けに時間がかかり、Runbook（障害対応手順書）の整備が追いつかない状態で本番投入すると、MTTR（平均復旧時間）が読めなくなります。
またコスト最適化を最優先課題としているプロジェクトも、いったん見送る判断が妥当です。仕様が発展途上のプロトコルは、監視ツールやマネージドサービスの選択肢が少なく、結果的に人件費という形で見えないコストが発生しがちです。
プロトコルの主導企業の収益化モデルが定まっていない段階も、リスク要因として認識しておくべきです。今回のCEO交代や広告以外の収益源模索という状況は、方針転換が将来起こり得ることを示唆しています。長期的な可用性の担保を最優先するシステムでは、この不確実性を許容できるかを検討してください。
まとめ
分散型プロトコルの採用判断は、運用主体の継続性・運用コスト・オブザーバビリティの成熟度・SLO設計の容易さという4つの軸で整理すると見通しがよくなります。
まず着手できることとして、候補にしているプロトコルの公式ドキュメントで、監視用のメトリクスエクスポーターやヘルスチェックエンドポイントが用意されているかを確認してみてください。次に、フェデレーション先のノードダウンを自社のSLIからどう切り離すか、SLO定義の段階で決めておくことが後々の障害対応を楽にします。
自社サービスの相互運用が事業上の差別化に直結するかどうかを見極めたうえで、小さく検証してから本番投入する順序を守るのが、可用性を落とさない現実的な進め方です。