Content is user-generated and unverified.

AT Protocol コミュニティシステム - コアコンセプト整理

最終更新: 2025年10月1日
バージョン: 1.0 - コアコンセプト確定版

📍 ビジョン

「世界とつながっている、居心地のいい小さな広場を、インターネット上に無数に作る」

🎯 解決したい課題

背景：3年間のMisskey運営からの実感

Fediverseの構造的問題

小規模サーバー: 過疎化 + 発見されにくい + 宣伝力不足
大規模サーバー: 交流困難 + 運用負荷（連合通信） + 個人運営の限界
ActivityPub: 実装がシステムごとにバラバラ、メンテナンス性が悪い

現代の居場所問題

X（Twitter）: 人が多すぎて安心して話せない、文脈が無視され喧嘩になる
Discord: クローズドすぎて入ることができない、発見されない
求められるもの: オープンだが適度に分割された、安心できる居場所

本質的な課題

「適切なサイズの居場所」が存在しない

コミュニティは人が増えると居心地が悪くなる（Dunbar数の問題）
でも小さすぎると過疎って死ぬ
既存プラットフォームは、この「適切なサイズ」を維持できない

💡 コアバリュー

「適切なサイズの居場所を、動的に維持し続けるコミュニティプラットフォーム」

人が少なすぎる → 自動的に他と統合される（テーマフィードの統廃合）
人が多すぎる → 自然に分かれる（細胞分裂モデル）
常に「ちょうどいい」を保つ

物理空間のメタファー：昔の公共空間の再現

広場・教会・図書館が持っていた特徴

適度な規模: 顔見知りができる程度の人数
オープンだが秩序がある: 誰でも来られるが、暗黙のルールがある
世界とつながっている: そこにいても孤立していない、より大きな何かの一部
目的が多様: 雑談もできるし、真面目な議論もできる

これを失った現代のインターネット

X（Twitter）: 世界最大の広場だが、人が多すぎて怒号が飛び交う
Discord: 快適な個室だが、外から見えない
Mastodon小規模サーバー: 心地よいカフェだが、誰も知らない路地裏にある

🏗️ システムの全体像

ネットワーク化された小さな広場

                   Bluesky（世界）
                        ↓
        ┌───────────────┴───────────────┐
        │                                │
    コミュニティA              コミュニティB
    （プログラミング）          （デザイン）
        │                                │
    ├─ Web開発                      ├─ UI/UX
    ├─ 機械学習                      └─ グラフィック
    └─ ゲーム開発

各コミュニティは：

小さい: 顔が見える規模（50-200人）
オープン: Blueskyユーザーなら誰でも参加できる
つながっている: 親コミュニティや、より大きなBlueskyエコシステムと接続
動的: 人が増えたら分かれ、減ったら統合される

🌟 5つの価値提案

1. 適切なサイズ

顔が見える規模（50-200人）
親密さと活気のバランス

2. 発見可能性

Bluesky経由で誰でも見つけられる
小規模コミュニティも埋もれない

3. 世界とのつながり

孤立しない、外の世界が見える
グローバルとローカルの橋渡し

4. 動的調整

大きくなったら分かれ、小さくなったら統合
常に最適な状態を維持

5. 移動の自由

DIDで複数の広場を行き来できる
コミュニティ移動のコストが低い

🔑 なぜAT Protocolなのか

既存プラットフォームとの比較

プラットフォーム 問題 AT Protocolでの解決
Mastodon小規模サーバー 過疎、発見されない Bluesky母集団から流入、自動統合
Mastodon大規模サーバー 人が多すぎる、運用負荷 自動分割、インフラ共有
Discord クローズド、入れない オープンだが適度に分割
Reddit 分裂が痛い、再集結が必要 DIDで移動コスト0

プラットフォーム	問題	AT Protocolでの解決
Mastodon小規模サーバー	過疎、発見されない	Bluesky母集団から流入、自動統合
Mastodon大規模サーバー	人が多すぎる、運用負荷	自動分割、インフラ共有
Discord	クローズド、入れない	オープンだが適度に分割
Reddit	分裂が痛い、再集結が必要	DIDで移動コスト0

AT Protocolの3つの強み

1. Blueskyという母集団（30M+ユーザー）

世界とのつながりを保証
小規模コミュニティでも発見される
Misskeyの小規模サーバー問題を解決する鍵

2. DID（分散ID）

アカウントがコミュニティから独立
サーバー移行のコストがない
複数コミュニティに同時所属できる
分裂しても「また集まればいい」が簡単

3. Custom Feedsの柔軟性

同じインフラ上で複数の「居場所」を作れる
テーマごとに動的にフィルタリング
過疎ったら統合、盛り上がったら分離が容易

4. ActivityPubの問題を回避

実装が統一されている
連合通信の負荷が軽い
メンテナンス性が高い

🌊 「世界とつながっている」の実現方法

浸透膜としてのコミュニティ

完全にクローズドでもなく、完全にオープンでもない。外の世界が適度に見える仕組み。

1. レイヤー構造

Layer 3: Blueskyグローバル（世界）
    ↓ 重要な話題が浸透
Layer 2: 親コミュニティ（プログラミング全般）
    ↓ 関連する投稿が浸透
Layer 1: サブコミュニティ（Web開発）
    ↓ メンバーの投稿
Layer 0: あなたのフィード

各コミュニティのフィード構成

80%: コミュニティ内の投稿
15%: 親コミュニティや関連コミュニティからの「おすすめ」
5%: Blueskyグローバルからの「話題」

→ 孤立しない。常に世界の息吹が感じられる。

2. 「広場の窓」機能

各コミュニティに「窓」を設置：

「今、Blueskyで話題になっていること」
「親コミュニティの最新投稿」
「関連コミュニティのハイライト」

→ 物理的な広場で、窓から外の通りが見えるように

3. クロスポストの再定義

単なる「同じ投稿を複数箇所に」ではなく：

「この投稿は世界に共有する価値がある」というシグナル
コミュニティ内部から、外の世界への「発信」

→ 広場から通りへ声をかけるような感覚

🔄 細胞分裂モデル（成長の4段階）

全体像

Phase 0: テーマフィード（親の一部）
    ↓ 人が集まる（15人、2週間、30投稿）
Phase 1: サブコミュニティ（半独立）
    ↓ 独自文化が形成（50人、2ヶ月）
Phase 2: 準独立コミュニティ（技術的独立、緩い連携）
    ↓ 完全に別方向（100人、4ヶ月）
Phase 3: 完全独立 or 決裂

基本思想

分裂は成長の証

コミュニティは大規模化すると、なじめない人が出てくる
そこから自然に派生して新しいコミュニティが生まれる
これを「ネガティブ」ではなく「ポジティブ」な成長として支援

常に最適なサイズを維持

Phase 0-3を通じて、「ちょうどいい」規模を保つ
過疎ったら統合（自動アーカイブ）
盛り上がったら分離（昇格）

🎨 ユーザー体験の例

ケース1: 新規ユーザー

1. Blueskyで「プログラミング」と検索 → 「プログラミング全般コミュニティ」が見つかる

2. Starter Packから参加 → 自動的にフォローすべき人、見るべきフィードが設定される

3. テーマフィードを眺める

「Web開発の話題」が面白そう
でも「機械学習」も気になる → 両方を気軽にフォロー

4. 居心地がいいと感じたら → サブコミュニティに正式参加

ケース2: コミュニティの成長

1. 「Web開発」テーマフィードが盛り上がる

15人が興味を示す
2週間で30投稿

2. システムが昇格を提案 → 「サブコミュニティに昇格しますか？」

3. サブコミュニティとして独立

メンバーシップが発生
独自のモデレーターを設置

4. さらに成長

50人を超える
「React」「Vue」で意見が分かれ始める

5. 自然な分裂 → 「React開発」「Vue開発」に分かれる → でも親の「Web開発」とはつながっている

ケース3: 世界とのつながり

1. サブコミュニティ内で議論

「Next.jsの新機能について」

2. フィードの20%は外の世界

親コミュニティから：「TypeScript 5.0リリース」
Blueskyグローバルから：「Vercelが新サービス発表」

3. 投稿をクロスポスト

「これは世界に共有したい」 → 親コミュニティやBlueskyグローバルに流れる

4. 新しい人が流入 → コミュニティが成長

🔍 次に詰めるべき論点

1. 浸透膜の設計

どの程度、外の世界を見せるべきか？（80-15-5%は適切？）
ノイズと情報のバランス
ユーザーがカスタマイズできるべきか？

2. 発見可能性の具体化

Blueskyユーザーが、コミュニティをどう見つけるのか？
Custom Feedとしてリストされるだけで十分？
おすすめアルゴリズムは必要？

3. 「居心地の良さ」の定義

具体的に何が「居心地」を作るのか？
モデレーション？規模？文化？活動頻度？
これを測定・維持する方法は？

4. 適切なサイズの検証

50-200人という数字は妥当か？
文脈依存？（雑談=小、専門的議論=大？）
Dunbar数との関係

5. 自動調整の受容性

統合や分割を「システムが提案する」のは押し付けがましくないか？
ユーザーは自分の居場所が変化することをどう感じるか？
どの程度、ユーザーの同意が必要？

📊 既存コミュニティとの差別化まとめ

要素 Reddit Discord Mastodon このシステム
規模の最適化 ✗ 大規模化が放置 ✗ 分裂は手動 △ サーバー単位 ✓ 自動調整
発見可能性 ✓ 高い ✗ 低い ✗ 低い ✓ 高い（Bluesky経由）
世界とのつながり △ 部分的 ✗ クローズド △ 連合のみ ✓ レイヤー構造
移動コスト ✗ 高い ✗ 高い △ 中程度 ✓ 低い（DID）
運用負荷 - 企業運営 △ 個人負荷大 ✗ 連合負荷大 ✓ 軽い
柔軟性 △ サブレディット △ チャンネル ✗ 硬直的 ✓ Custom Feeds

要素	Reddit	Discord	Mastodon	このシステム
規模の最適化	✗ 大規模化が放置	✗ 分裂は手動	△ サーバー単位	✓ 自動調整
発見可能性	✓ 高い	✗ 低い	✗ 低い	✓ 高い（Bluesky経由）
世界とのつながり	△ 部分的	✗ クローズド	△ 連合のみ	✓ レイヤー構造
移動コスト	✗ 高い	✗ 高い	△ 中程度	✓ 低い（DID）
運用負荷	- 企業運営	△ 個人負荷大	✗ 連合負荷大	✓ 軽い
柔軟性	△ サブレディット	△ チャンネル	✗ 硬直的	✓ Custom Feeds

🚀 このコンセプトの新規性と魅力

新規性

動的サイズ調整: 既存プラットフォームにない「適切なサイズを保つ」自動化
浸透膜モデル: オープンとクローズドの中間を、レイヤー構造で実現
細胞分裂の構造化: 自然発生的な分裂を、システムが支援・管理
AT Protocol活用: DIDとCustom Feedsの組み合わせによる独自の価値

魅力（ユーザー視点）

安心して話せる: 人が多すぎず、少なすぎず
孤立しない: 世界とつながっている感覚
発見される: 小規模でも埋もれない
自由に移動: コミュニティ間を気軽に行き来

魅力（運営者視点）

運用負荷が軽い: インフラ共有、連合負荷なし
過疎対策不要: 自動統合で解決
成長が簡単: Blueskyからの流入

📝 結論

このコンセプトは、単なる「コミュニティ管理システム」ではなく、

「インターネット上に、昔の公共空間（広場・教会・図書館）を再現する試み」

である。

AT Protocolの特性（DID、Custom Feeds、Bluesky母集団）を活かすことで、既存プラットフォームでは実現できなかった「適切なサイズの、世界とつながった居場所」を作ることができる。

これは、3年間のMisskey運営で直面した構造的な問題を解決するものであり、同時に現代のインターネットが失った「居場所」を取り戻す挑戦でもある。

次のステップ

浸透膜の設計を具体化
発見可能性の仕組みを詰める
適切なサイズの仮説検証
プロトタイプ開発（Phase 0から）

Content is user-generated and unverified.