Misskeyの今とFediverseのこれからを考える
Misskey、ご存知でしょうか。
MisskeyとFediverseについて
Misskey（ミスキー）はフリーでオープンソースのSNS作成ソフトウェアです。
MisskeyはFediverseというActivityPubを介したSNSネットワークに接続できるプラットフォームの一つです。フリーかつオープンソース(AGPL)で、サーバー運用に関するある程度の知識があれば比較的簡単に構築することができます。
近いところの有名どころはMastodonなどがあります。日本では2017~2019年ごろに中央集権型でなく分散型の新しいSNSの形として有名になり、かつてはドワンゴやPixivなども独自で運営していました（今は閉鎖や事業譲渡済み）
Mastodonは今でも生まれ故郷のヨーロッパ圏を中心に大手企業に依存しない民主化されたSNSとして多く運用されている印象ですが、全体的に体験が旧来のTwitterを想起させるものであり現在となっては設計が古く正直言うと物足りない感じはあります。
それに対してMisskeyはUIデザインもモダンな感じでMFMや絵文字リアクションなどコミュニケーションや表現を強化する独自の要素を持ち、ActivityPubでFediverseへの接続も対応しているというPost Mastodonという感じで特に日本のユーザーにウケがよい感じになっています。
Misskeyの影響を受けてか(ソース無し)、Fedibird(Mastodonフォーク)、Pleroma/Akkoma などの他のFediverse対応プロダクトも絵文字リアクションを標準機能として実装してきてたりもします。(Slack, Discordなどもあるので絵文字リアクションはもうかなり一般的な感じはありますが）
Misskeyの立ち位置の変化
Misskey.ioが登録者60万人を超える
Misskeyのサーバーで一番有名であるMisskey.ioが登録者60万人を超えました。
※2025/09/23時点で登録677360ユーザー
登録者が爆発したタイミングは様々な理由でXから避難してきた人たちが多かった印象ですが、運営者の村上さんの影響もあるのかだんだんと古のオタクインターネットカルチャー的な独特の文化圏になってきています。個人的にはなんとなく昔のニコニコ動画文化を思い出すような感じです。
しかしながら登録者は増えてはいるもののアクティブユーザーはここしばらくは横ばいかむしろ微減という感じです。アクティブユーザーは1万を前後しておりXになにか異変があったときにアクセスがスパイクしてまた減っていくような印象でです。
また後で書きますが、Misskey文化圏のサーバーはio含めユーザーの支援ベースで運用されており収益化モデルは不安定です。ioも村上さんの個人の影響力にかなり依存しており、事業としてやっていくにはかなり大変そうです。
国内サービスとしての mixi2 の登場
2017~2019のMastodon運営の盛り上がりから消失までの流れを見てか、Misskey.ioの法人化を除き企業運営マイクロブログ系SNSは空白地帯になっていましたが、老舗かつモンストで資本力もあるmixiが突如mixi2として参入してきました。
さすがの認知度と資本力で登録ユーザー数は発表5日で120万人を超えたとのことで、現在はもっと増えていることは間違いありませんがアクティブユーザーとして現在どれぐらい定着したのかは謎です。
mixi由来のコミュニティ機能と昨今の流行りの絵文字リアクション、Misskey的な文字装飾といろいろとモダンな感じの国内SNSという感じです。自分はちょっと住みつきはしませんでしたが、国内企業運営サービスとして安心して使えるというユーザーも多いのではないかとは思います。
少なくともMisskeyに流れそうなライト層は軒並み吸われてしまった感じはあります。
Threads の ActivityPub 連携開始
ThreadsはMetaが運営しているマイクロブログタイプの新興SNSです。Instagramとアカウント連携でユーザー登録でき現在4億人のユーザー数を抱えているとのことです。
ちょっとXとはユーザー層が異なる感じはあり、Instagramでキラキラを投稿している人の闇が出ている裏Instagramと揶揄されているところはありますが、Xに並ぶ圧倒的なユーザー数なのは確かです。
ActivityPubとの連携が少しずつ進められており相互に投稿をフォローしてみることができます。Fediverseとの完全な連合ではありませんが接続していることにはまちがいなく、最大手のActivityPub対応プラットフォームと言えます。
Misskeyへの影響としては、コミュニティ運営ではなく単にFediverseへの広報を想定した企業広報は独自にサーバーを建てずにThreadsにアカウントを作るのが安牌となる可能性が高くなるとも言えます。
Bluesky と AT Protocol の連合開始
Xの対抗としてはThreadsだけではなくBlueskyが有名です。2025年6月時点で3,500万人の登録ユーザーがいるとのことでXやThreadsまではいかないもののマイクロブログ系の代表的なサービスの一つです。
BlueskyはActivityPubではなくAT Protocolという独自プロトコルを提供しています。とはいえ公表はしているものの長らくBlueskyとの接続は実現していませんでした。
2024年2月22日にやっとAT Protocolでの連合が可能になることが発表されました。
これによりActivityPub以外の分散型SNSを実現する手段が増えた形になります。まだ多くはありませんがPDSと呼ばれる本家以外のサーバーも少しずつ増えているようです。（とはいえまだトップがActivityPubとのブリッジサーバーなのでまあそういう感じです）
ドキュメントも公開されていますので今後は実装されるシステムも増えていくかもしれません。
現在のMisskeyの課題
Misskeyのソースコードはオープンソースで公開されています。
私も3年間運用してフォークやカスタマイズをしてきたなかで思う課題をまとめます。
小規模運用に最適化された設計
Misskeyは小規模インスタンス(AU50人程度まで)は快適に利用できます。管理機能も一通りそろっており特に困ることもないです。これはかなりいいところです。
ただしAU100人などになってくるとローカルタイムラインの速度が速くなりすぎて破綻します。タイムラインを間引く機能やおすすめ機能などもないので単純に速度が上がるだけになり読むのが追い付きません。また全取得の関係でクライアントの負荷も高くバッテリーの減りも速いです。
そうなるとフォロー機能を使って好きなユーザーのみをホームタイムラインでみる形になりますが、これだと同一サーバーにいる意味があまりなくなってしまいます。
チャンネル機能もありますが、アクセスがいまいち悪くio規模でも過疎になっているチャンネルが多いです。そのため中～大規模運用には現状だと設計があっていない部分があります。
AGPLという縛りの強いライセンス
MisskeyはAGPLにより運用されています。AGPLはGPLの特徴に加えてネットワークを介して利用されることも配布となりその際にもソースコードの提供義務が生じます。つまりWebサービスにも厳格に適用されるGPL系ライセンスです。
GPL系のライセンスは功罪がある感じはあり、ソースコードの権利を守るための強力な手段になりますが、ビジネスで利用しようとした際に秘匿が必要なコードを組み込むことが難しくなります。(もちろんトークンやパスワードなどの公開義務はありませんが、非公開APIの利用やセキュリティ系の対策など公開したくないコードの種類はいろいろとあります）
Misskey.ioでも一部機能をCloudflare Workersで実装することによりこの制限を回避するような対応をしていることのことです(Cloudflare Workers Tech Talkより)
こういうプロダクトでよくあるのはオープンソース版はAGPLだが、有料のコマーシャル版は専用の非公開化可能なライセンスで提供するみたいなパターンですがMisskeyはそういった運用はされていないのでAPGLを回避する手段は限られます。
コア部分のActivityPubへの密結合
ユーザー数が少ないうちはいいですが、ユーザー数の増加に伴いリモートユーザー（ActiviyPubにより接続された外部サーバーのユーザー）が増えてくると投稿の配信・受信(Pub/Sub)がどんどんと増えていきます。
これには2つの大きな問題があります。
1つはメッセージキューがさばききれなくなることです。MisskeyはRedis + Bull MQにて内部のタスクを順次処理していますが、ユーザー数が多くなるとRedisがさばききれなくなって詰まります。RedisはTLのキャッシュなど他の機能でも利用しているのでいろいろとよろしくありません。
2つめはリモートユーザーが増えてもコストばかり増え収益にならないことです。上にも書きましたがほとんどのMisskeyサーバーは支援ベースで運営されています。そのため内部ユーザーが増えないと支援額は増えないのです。
リモートユーザーのPub/Subの通信負荷、およびDBの容量圧迫は長期運用時の課題ですが基本機能としては足りていないというのが正直なところです。
そこらへんは別の記事でも書いたのでここら辺にしておきます。
モデレーションの問題
MisskeyというかFediverse全体の問題としてスパムにかなり脆弱です。
2024年2月ごろにbot対策が甘いサーバーに大量にbotアカウントが作られてそこからスパムメッセージをFediverse全体に大量に送り付ける攻撃がありました。
各サーバーはメンション数での制限だったりホワイトリストだったり内部ユーザーがフォローしているかで判定したりといろいろと対策はしましたが、Fediverseの利便性とされていたサーバー同士が緩く連合する設計思想の穴を突かれた形になりました。現在でも条件付きで完全な解決はしていません。
また法律の問題もあります。リモートサーバーでポルノやその他法律違反のコンテンツが投稿された場合意図せず運営しているサーバーに流れてくる可能性があります。この際にリモートサーバーの画像などを運営しているオブジェクトストレージに保存してしまうなどするとかなり危ないです。
Misskeyはリモートサーバーのコンテンツをキャッシュするかの切り替えオプションがありますが、上記問題によりこちらは基本的に有効化できないと考えています。
最近だとオンライン安全法などがヨーロッパ圏で成立しており、逆に日本のサーバーから海外サーバーへ配信してしまう可能性もあります。そこらへんは個別に対策が必要になってきます。
Post Misskeyとしては何が必要か
Misskeyはかなり好きなプロダクトではありますが、いろいろとまだ改善できる余地があるとは考えています。またSNSを取り巻く状況も変化しており、次世代の分散SNSプラットフォームも必要なのではとは考えています。
オープンかつ適度にクローズドな環境
Xは拡散力は魅力的ですがオープンすぎて諍いも多く安全に意見を発信できるとはいえません。とはいえDiscordなどのクローズドすぎるのもコミュニティの広がりがなくなってしまいます。Mastodon, MisskeyなどのLTLは魅力的ですが人数の増加に耐えられる設計になっていません。
チャット的なコミュニケーションができる状態を保ちつつ人数を増やす、またコミュニティ内でさらに分化できるような仕組みをあらかじめ組み込む必要があります。
またコミュニティ間も分断せず移動がシームレスにできるようにしたいところです。
ActivityPub と AT Protocol の両対応
いいとこどりといってはなんですが、せっかくなので(すくなくともReadだけでも)両方の世界に接続したいところではあります。ブリッジではない実現方法も考えたいところです。
またこれらがコア機能から分離されており内部に必要以上に干渉しないようにしたいところです。
収益化モデルの確立、または支援ベースでも成立するコスト最適化
どうしても外部接続というのはコストがかかるので難しいところではありますが、どうにも収支バランスが安定しないのがネックです。長期的なサーバー運用をしていく上で必要以上にコストが増大しないように設計段階から想定する必要があります。
まとめ
MisskeyとFediverseについての今と今後について簡単にですが記載しました。
ちょっと個人的に新しいプラットフォームのプロトタイプを作っていこうと動いているところですがまだ構想段階なので実現するかはちょっとわかりません……。なんにせよちょっとFediverseには停滞感があるのは否めないのでなにかしらやっていけたらなと考えています。
以上です。ありがとうございました。
Discussion